🤖
0 in / 0 out / 0 total tokens
Claude 이야기는 이제 성능표보다 판단력으로 옮겨가고 있다.
핫 토픽
Fable's judgement
Simon Willison이 공유한 "Fable's judgement"는 Claude를 단순한 텍스트 생성기가 아니라, 애매한 상황에서 판단을 내리는 시스템으로 봐야 한다는 흐름을 보여준다. 지금까지 LLM 평가는 코딩 벤치마크, 수학 문제, 컨텍스트 길이처럼 숫자로 비교하기 쉬운 항목에 몰려 있었는데, 실제 개발 현장에서는 그보다 더 자주 "이 요구사항을 어떻게 해석할 것인가", "어디까지 자동화할 것인가", "위험한 변경을 멈출 것인가" 같은 판단 문제가 터진다.
개발자 입장에서 중요한 지점은 Claude가 답을 잘 맞히는 모델인가보다, 판단을 맡겨도 되는 경계가 어디인가다. UE5 C++ 프로젝트에서 AI에게 리팩터링을 맡긴다고 치면, 컴파일 에러 하나 고치는 일과 네트워크 복제 구조를 바꾸는 일은 완전히 다른 위험도를 가진다. 전자는 자동 수정이 꽤 쓸모 있지만, 후자는 서버 권위, 지연 보정, 메모리 소유권, 프레임 타임까지 같이 봐야 한다.
이게 왜 중요한지: AI 에이전트의 실전 가치는 "코드를 얼마나 많이 쓰는가"가 아니라 "멈춰야 할 때 멈추는가"에서 갈린다.
출처: Simon Willison
개발자 관점
Claude는 도구에서 협업자로 이동 중이다
Claude/Anthropic 계열 모델을 쓰다 보면 장점은 꽤 분명하다. 긴 문맥을 붙잡고, 요구사항의 뉘앙스를 비교적 오래 유지하고, 위험한 작업에서는 설명을 길게 달려는 성향이 있다. 이게 귀찮을 때도 있지만, 프로덕션 코드에서는 오히려 장점이 된다.
게임 서버나 실시간 시스템에서는 "대충 맞는 코드"가 가장 위험하다. 초당 수십 번 도는 Tick, Replication, RPC, Object lifetime 같은 영역에서는 작은 판단 실수가 성능 문제나 재현 어려운 버그로 번진다. Claude가 이런 맥락에서 더 좋은 파트너가 되려면, 코드를 생성하는 능력보다 변경 범위를 좁히고, 모르는 부분을 모른다고 표시하고, 검증 경로를 제안하는 능력이 중요하다.
나는 AI 사이드프로젝트를 만들 때도 비슷하게 본다. 모델이 기능을 빨리 붙여주는 건 이미 충분히 강력하다. 문제는 기능이 늘어난 뒤다. 데이터 흐름이 꼬이고, 프롬프트가 중복되고, API 비용이 새고, 실패 케이스가 로그에만 쌓인다. 이때 필요한 건 더 많은 생성이 아니라 더 나은 판단이다.
이게 왜 중요한지: 개발자가 AI에게 맡길 수 있는 업무 범위는 모델의 지식량보다 판단 실패 비용에 의해 결정된다.
출처: Simon Willison
Anthropic에게 의미 있는 방향
Constitutional AI 다음은 운영 판단이다
Anthropic은 예전부터 안전성, 정렬, 모델 행동의 일관성을 강하게 밀어온 회사다. 그래서 Claude 관련 논의가 "판단"으로 간다는 건 자연스럽다. 단순히 더 똑똑한 답변을 만드는 경쟁이 아니라, 사용자가 작업을 맡겼을 때 어떤 기준으로 허용하고 거절하고 되묻는지의 경쟁으로 넘어가는 셈이다.
개발 도구로 보면 이 차이는 크다. AI 코딩 도구가 파일을 읽고, 수정하고, 테스트하고, PR까지 만들 수 있다면 모델의 판단 정책은 곧 개발 프로세스의 일부가 된다. 예를 들어 마이그레이션 스크립트를 자동 작성할 때 데이터 삭제 가능성이 있으면 멈춰야 하고, 대규모 리팩터링을 요구받으면 테스트 범위를 먼저 확인해야 한다. 이건 프롬프트 예절이 아니라 운영 안전장치다.
여기서 Anthropic이 잘하면 Claude는 "말 잘하는 챗봇"보다 "리스크를 아는 개발 에이전트"에 가까워진다. 반대로 판단 기준이 흐릿하면, 모델이 아무리 코드를 잘 써도 팀에서는 중요한 작업을 맡기기 어렵다.
이게 왜 중요한지: 앞으로의 AI 개발 도구 경쟁은 생성 속도보다 변경 통제, 감사 가능성, 실패 시 복구 가능성으로 갈 가능성이 크다.
출처: Simon Willison
실전 적용
Claude를 쓸 때 프롬프트보다 작업 경계를 먼저 잡아야 한다
이번 소식을 보고 바로 적용할 수 있는 건 거창한 게 아니다. Claude에게 일을 줄 때 "무엇을 해라"만 쓰지 말고 "어디까지 건드리지 마라", "불확실하면 질문해라", "테스트 없이 완료 처리하지 마라"를 같이 줘야 한다. 특히 코드베이스가 크거나 서버/클라이언트 경계가 있는 프로젝트라면 이 차이가 꽤 크다.
UE5 프로젝트라면 AI에게 Actor 구조 전체를 바꾸라고 던지는 것보다, 특정 컴포넌트의 책임을 분리하고 빌드 에러와 Replication 영향만 확인하게 하는 편이 낫다. AI 사이드프로젝트라면 결제, 인증, 데이터 삭제처럼 실패 비용이 큰 영역은 모델이 제안만 하고 사람이 승인하는 구조가 맞다. 나도 이 부분을 자주 대충 넘기다가 나중에 로그와 마이그레이션에서 고생한 적이 있다.
결국 Claude의 판단력을 잘 쓰려면 사람 쪽에서도 판단 기준을 명시해야 한다. 모델이 알아서 팀의 암묵지를 읽어주길 기대하면 삽질 확률이 올라간다.
이게 왜 중요한지: 좋은 AI 워크플로는 모델 성능이 아니라 작업 권한 설계에서 시작된다.
출처: Simon Willison
Claude의 다음 가치는 더 많은 답을 내는 능력이 아니라, 위험한 답을 보류하는 판단력에 있다.