🤖
1211 in / 4109 out / 5320 total tokens
Simon Willison이 Luke Curley의 Claude 관련 인사이트를 인용하면서, Claude가 에이전트 워크플로우에서 어떤 위치에 있는지, 그리고 개발자가 이걸 어떻게 써먹어야 하는지를 날카롭게 짚어냈다. 단순히 "Claude가 좋다"가 아니라, 실제 개발자가 겪는 문제 상황과 맞물려 있어서 주목할 만하다.
🔥 핫 토픽
Simon Willison, Luke Curley 인용 — Claude의 "Everything" 접근 방식
Simon Willison이 자신의 블로그에서 Luke Curley의 발언을 인용하며 Claude의 아키텍처적 접근에 대해 논했다. 핵심은 Claude가 단순한 챗봇이 아니라, 에이전트 루프 안에서 "모든 것(everything)"을 처리하려는 방향으로 진화하고 있다는 점이다. 이는 Anthropic이 Claude를 설계할 때 일관되게 밀고 있는 철학과 맞닿아 있다. 툴 사용(tool use), 컴퓨터 사용(computer use), 확장된 컨텍스트 윈도우 — 이 모든 게 "하나의 모델이 다 한다"는 전제 위에 있다.
왜 이게 중요하냐. 경쟁 구도를 보면 알 수 있다. OpenAI는 GPT 시리즈와 별도로 DALL-E, Whisper, Codex 같은 특화 모델들을 따로 운영하면서 결국엔 통합하려고 한다. 반면 Anthropic은 처음부터 Claude 하나로 범용성을 밀어붙이고 있다. Luke Curley가 지적한 것은 바로 이 전략의 실무적 함의다. 개발자 입장에서는 API 엔드포인트 하나로 텍스트 생성, 코드 분석, 툴 호출, 파일 조작까지 다 처리할 수 있다는 게 엄청난 이점이다. 서버 아키텍처를 짤 때 모델 라우팅 로직을 복잡하게 짤 필요가 없어진다.
게임 개발에 비유하자면, 언리얼 엔진의 블루프린트처럼 하나의 시스템 안에서 모든 걸 해결하려는 접근이냐, 아니면 유니티처럼 여러 에셋 스토어 플러그인을 조합하는 방식이냐의 차이다. 물론 각각 장단점이 있다. 단일 모델 접근은 디버깅이 쉽고 일관된 동작을 보장하지만, 특정 태스크에서는 특화 모델보다 성능이 떨어질 수 있다. 실제로 코드 생성만 놓고 보면 여전히 전용 모델들이 더 낫다는 평가도 있다.
개발자에게 미치는 영향을 구체적으로 말하면 이렇다. Claude API를 쓰는 사이드프로젝트에서 툴 호출과 응답 생성을 하나의 스트림으로 처리할 수 있다. 이전에는 텍스트 생성 API 호출 → 결과 파싱 → 툴 실행 → 결과 재전송이라는 멀티스텝 파이프라인을 직접 구현해야 했다. 지금은 Claude가 알아서 툴을 호출하고 결과를 통합해서 응답한다. 백엔드 개발자 입장에서 상태 관리(state management) 코드가 절반 이상 줄어든다. UE5 C++ 프로젝트에서 게임 로직과 AI 서버 통신을 연동할 때도, API 호출 횟수와 레이턴시 관리가 훨씬 단순해진다.
기술적 배경을 조금 더 설명하면, Claude의 툴 사용은 JSON Schema 기반으로 툴을 정의하고, 모델이 필요할 때 자동으로 툴 호출을 생성하는 방식이다. 이건 Function Calling과 비슷하지만, Anthropic의 구현은 컨텍스트 내에서 여러 툴을 연속으로 호출하는 멀티스텝 에이전트 동작을 더 자연스럽게 지원한다. 예를 들어, "이 파일 읽어서 버그 찾아줘"라고 하면 Claude가 파일 읽기 툴 호출 → 코드 분석 → 결과 정리까지 한 시퀀스 안에서 처리한다. 중간에 개발자가 개입할 필요 없다.
Simon Willison이 이걸 인용한 이유도 명확하다. 그는 오랫동안 LLM을 실제 도구로 활용하는 방법에 집중해왔다. 단순한 벤치마크 스코어가 아니라, 실제 워크플로우에 녹여냈을 때 어떤 차이가 나는지. 그 관점에서 Luke Curley의 Claude 평가는 실효성 있는 인사이트를 담고 있다. 특히 에이전트 루프를 구현하는 개발자들에게는 Claude의 "everything" 접근이 DX(Developer Experience) 측면에서 상당한 이점이다.
출처: Simon Willison - Quoting Luke Curley
📊 분석: Claude의 범용성 전략이 갖는 의미
Luke Curley의 인사이트를 통해 드러나는 건 Anthropic의 장기 전략이다. Claude를 "만능 도구"로 만들겠다는 거다. 이건 모델 성능 경쟁이 한계에 다다랐다는 판단과도 관련 있다. GPT-4와 Claude 3.5 Sonnet의 성능 차이가 체감상 크지 않아진 지금, 차별화 포인트는 "얼마나 자연스럽게 에이전트 역할을 수행하느냐"로 옮겨가고 있다.
게임 서버 아키텍처에 비유하면 이해가 쉽다. 예전에는 게임 로직 서버, 채팅 서버, 매치메이킹 서버를 각각 따로 뒀다. 지금은 마이크로서비스로 분리하면서도 하나의 오케스트레이션 레이어에서 다 관리한다. Claude의 접근도 비슷하다. 모델 자체가 오케스트레이터 역할을 하면서, 필요한 툴을 호출하고 결과를 종합한다. 개발자는 개별 툴만 정의하면 된다. 중간 조정 로직은 Claude가 알아서 한다.
실무적으로 체감하는 차이는 이렇다. 이전에 AI 에이전트를 만들 때, 모델이 언제 툴을 호출해야 하는지, 호출 결과를 어떻게 후처리해야 하는지, 에러가 나면 어떻게 복구해야 하는지 — 이 모든 걸 직접 코드로 짜야 했다. 지금은 시스템 프롬프트와 툴 정의만 잘 해놓으면 Claude가 대부분 알아서 처리한다. 당연히 엣지 케이스에서는 여전히 개발자 개입이 필요하지만, 80%의 케이스는 코드 없이 해결된다.
이런 흐름은 앞서 언급한 "everything" 접근과 맞물려 있다. 하나의 모델이 다양한 역할을 수행하면, 개발자는 모델 선택 로직을 짤 필요가 없다. "이 태스크는 코드 생성이니까 Codex로, 이 태스크는 텍스트 요약이니까 GPT-4로" 같은 라우팅이 필요 없어진다. Claude 하나로 다 덮는다. 물론 비용 문제는 별개다. Claude 3.5 Sonnet은 여전히 저렴한 모델은 아니다. 하지만 개발 생산성과 인프라 복잡도를 고려하면 충분히 가치 있는 트레이드오프다.
앞으로 주목해야 할 건 Claude의 컴퓨터 사용(Computer Use) 기능이 어떻게 발전하느냐다. 현재는 베타 단계지만, 이게 안정화되면 Claude가 직접 브라우저를 조작하고, 파일 시스템에 접근하고, 애플리케이션을 제어할 수 있다. 게임 개발에서는 에디터 스크립트를 Claude가 직접 실행하는 것도 가능해진다. "이 씬에 라이트 10개 추가해줘"라고 하면 Claude가 언리얼 에디터의 Python API를 호출해서 직접 처리하는 미래가 그리 멀지 않았다.
출처: Simon Willison - Quoting Luke Curley
⭐ 실무 관점: 어떻게 활용할 것인가
Simon Willison이 주목한 Luke Curley의 발언에서 실무적으로 건질 수 있는 건, Claude를 "만능 에이전트"로 활용할 때의 설계 패턴이다. 단순히 API를 호출해서 응답을 받는 1-turn 구조가 아니라, Claude가 스스로 판단해서 여러 단계를 거치는 agentic loop를 어떻게 구현하느냐가 핵심이다.
구체적인 패턴을 하나 소개하면 이렇다. 시스템 프롬프트에 명확한 역할과 제약 조건을 정의한다. 툴 정의는 JSON Schema로, 입력값과 출력값의 타입을 엄격하게 명시한다. 그리고 Claude에게 "필요하면 툴을 여러 번 호출해도 된다"는 권한을 준다. 이렇게 하면 Claude가 스스로 판단해서 툴을 호출하고, 중간 결과를 바탕으로 다음 행동을 결정한다. 개발자는 이 루프를 모니터링하고, 필요할 때 개입하는 역할만 하면 된다.
UE5 프로젝트에 적용해보면 이렇다. 게임 내 NPC의 대화 시스템을 Claude로 구현한다고 가정하자. NPC의 성격, 세계관, 현재 퀘스트 상태를 컨텍스트로 넘긴다. 툴로는 "퀘스트 상태 업데이트", "인벤토리 아이템 추가", "다른 NPC와의 관계 변경" 같은 게임 로직 트리거를 정의한다. 플레이어가 NPC와 대화하면, Claude가 대화 내용을 분석해서 필요한 게임 로직 트리거를 자동으로 실행한다. "도적 NPC에게 충분히 호감도를 쌓으면 숨겨진 상점에 접근할 수 있다" 같은 복잡한 조건도 Claude가 컨텍스트를 바탕으로 자연스럽게 판단한다.
물론 주의할 점도 있다. 에이전트 루프가 무한히 돌면 비용이 폭발한다. max_tokens 설정, 반복 횟수 제한, 타임아웃 처리 — 이런 세이프가드는 반드시 걸어야 한다. 또한 Claude가 툴 호출 파라미터를 잘못 넘길 수도 있다. 입력값 검증 로직은 서버 측에서 반드시 구현해야 한다. 모델을 믿되 검증은 시스템이 하는 구조다.
결론적으로, Luke Curley가 지적하고 Simon Willison이 공감한 Claude의 강점은 "개발자가 에이전트 로직을 직접 짜는 수고를 줄여준다"는 데 있다. 물론 완전히 없어지는 건 아니다. 하지만 보일러플레이트 코드가 크게 줄어들고, 개발자는 비즈니스 로직과 툴 설계에 집중할 수 있게 된다. 이건 프로그래밍 패러다임의 변화라 봐도 과언이 아니다.
출처: Simon Willison - Quoting Luke Curley
Claude의 "everything" 접근은 만능 해결책이 아니라, 에이전트 개발의 복잡도를 모델 쪽으로 옮겨주는 전략이다. 개발자는 툴을 잘 설계하고, 모델은 그 툴을 언제 어떻게 쓸지 판단한다. 이 분업이 앞으로 AI 에이전트 개발의 표준이 될 것이다.