앤트로픽 클로드 코드 개발자 강연: 컨텍스트 엔지니어링과 플러그인으로 대규모 코드베이스 다루기

핵심 메시지

• 모델 능력은 급격히 좋아졌지만 컨텍스트 창은 2024년 말 100만 토큰 수준에서 사실상 멈춰 있어, 그 유한한 공간에 무엇을 넣을지 고르는 일이 새로운 엔지니어링 과제가 됐다.
• 커스터마이징의 목표는 '클로드가 당신이 할 수 있는 일을 전부 할 수 없다면 당신의 일을 함께 할 수도 없다'는 문장으로 요약된다. 소스 코드 바깥의 팀 채팅·CI·대시보드·설계 문서까지 접근할 수 있어야 한다.
• 가중치는 출시 시점에 고정되고 파인튜닝 인터페이스는 오히려 줄고 있어, 실질적인 커스터마이징은 거의 전부 텍스트 공간에서 일어난다. 발표자는 이를 '결국 텍스트 파일'이라고 표현했다.
• 플러그인 구성요소 중 훅(hook)만이 제대로 확장된다. 관련 없을 때는 컨텍스트에 아무것도 넣지 않고, 필요할 때만 결과를 끼워 넣기 때문이다.
• 발표자는 2025년이 모델에 정보를 넣는 해였다면 2026년은 모델이 하고 있는 일을 사용자에게 빠르게 전달하는 해가 될 것이라고 전망했다.

쉽게 이해하기

NDC 코펜하겐 마지막 순서에 선 데이지 홀먼은 앤트로픽에서 클로드 코드의 플러그인과 에이전트 팀 기능을 설계·구현한 엔지니어다. 그는 자신이 합류하기 직전까지 이 도구가 사내에서 '클로드 CLI'로 불렸다고 소개하며, 배경이 C++ 표준위원회와 슈퍼컴퓨터용 병렬·분산 프로그래밍 모델이었다고 밝혔다. 강연의 목표는 제품 홍보가 아니라 '에이전트형 소프트웨어 엔지니어링'이라는 분야를 학술적으로 정리하는 것이라고 못박았다.

그는 챗봇과 에이전트의 차이를 도구 호출 횟수로 설명했다. 2024년 도구 호출이 등장하면서 모델이 한 번, 두 번, 여러 번 연속으로 컴퓨터에 일을 시킬 수 있게 됐고, 자율성이 일정 수준을 넘자 우리가 그것을 에이전트라 부르기 시작했다는 것이다. 실제 구조는 놀랄 만큼 단순해서, 모델이 특정한 JSON을 쓰면 하네스가 그 명령을 실행하고 결과를 컨텍스트에 도로 붙여 넣는 것이 전부다. 코딩 에이전트를 굴러가게 하는 주력 도구인 편집 도구 역시 파일명·기존 문자열·새 문자열을 받는 바이트 단위 찾아 바꾸기에 불과하다.

그럼에도 성능은 빠르게 올라왔다. 그는 메타(METR)가 만든 그래프를 인용해 모델이 50% 성공률로 처리할 수 있는 작업의 시간 길이가 약 4개월마다 두 배가 돼 왔다고 소개했다. 다만 이 그래프는 올해 초에서 멈췄는데, '16시간짜리 작업'이 무엇인지에 대한 오차 범위가 너무 커졌기 때문이라고 설명했다. 실제 효과의 사례로는 모질라 재단이 최신 모델을 쓴 4월 한 달 동안 고친 보안 취약점이 직전 15개월 동안 고친 것보다 많았다는 발표를 들었다.

왜 굳이 모델을 커스터마이징해야 하느냐는 질문에 그는 세 가지를 들었다. 일하는 데 필요한 것들에 접근할 수 있어야 하고, 회사 내부에 축적된 지식을 알아야 하며, 그 정보를 컨텍스트 창에 제대로 밀어 넣을 도구가 있어야 한다는 것이다. 기본 상태의 클로드는 저장소 하나와 셸만 보는데, 전문 소프트웨어 엔지니어 중 하루 종일 그 폴더 밖을 한 번도 보지 않는 사람은 없다. 그는 '터미널을 벗어나지 않고 하루치 업무를 해 보라'는 실험을 권하며, 그렇게 해서 일이 안 된다면 클로드도 그 일을 같이 할 수 없다고 말했다.

핵심 제약은 컨텍스트 창이다. 최초의 100만 토큰 모델이 2024년 말에 나왔고 지금도 최전선 모델은 대체로 100만 토큰인데, 그사이 모델이 감당하는 작업의 길이는 훨씬 빠르게 늘었다. 그는 이 상황을 '아두이노에서 npm을 돌리는 것'에 비유했다. 일반 패키지 매니저라면 의존성 충돌을 두 버전을 함께 설치해 해결할 수 있지만, 컨텍스트에서는 무엇이 더 관련 있는지 골라 하나만 넣고 나머지를 버려야 한다는 뜻이다. 여기에 KV 캐시라는 제약이 더해진다. 앞부분 토큰이 이전과 같아야 예측이 싸지기 때문에, 관련 규칙을 그때그때 갈아 끼우는 방식은 비용이 크게 늘어난다.

그는 플러그인을 이루는 네 가지 구성요소를 확장성 기준으로 하나씩 평가했다. MCP 서버는 도구마다 이름·설명·스키마가 시스템 프롬프트에 상주해서, 서버 20개에 도구가 15개씩만 돼도 컨텍스트가 도구 설명으로 가득 찬다. 최근 도입한 도구 검색은 이름만 먼저 올려 사정을 낫게 하지만 완전한 해법은 아니다. 스킬은 마크다운 파일이 든 폴더로, 본문은 필요할 때만 펼쳐지지만 설명 줄은 항상 로드되므로 개수가 많아지면 같은 문제가 생긴다. 서브에이전트는 별도 컨텍스트에서 일하고 요약만 돌려준다는 점에서 낫지만 역시 설명이 쌓인다. 반면 훅은 이벤트가 발생할 때 스크립트를 돌려 관련 없으면 즉시 빠져나오므로, 쓰지 않는 것에 대해 토큰을 내지 않는다.

그가 훅을 특히 좋아하는 이유는 '에이전트를 위한 빨간 물결선'을 만들 수 있어서다. 사람은 오타를 내면 편집기가 즉시 밑줄을 그어 알려주지만 모델은 원시 텍스트만 받는다. 도구 사용 후 훅으로 타입 검사나 린트 결과를 도구 응답에 덧붙이면, 나중에 컴파일할 때가 아니라 실수한 그 순간에 알려줄 수 있다. 그는 코드베이스에서 에이전트를 빨리 좋아지게 하는 길은 더 똑똑한 모델이 아니라 더 촘촘한 피드백 루프이며, 필요한 스크립트는 대개 이미 갖고 있다고 말했다.

마지막으로 그는 2026년의 방향을 병렬 작업으로 잡았다. 세션마다 다른 깃 워크트리를 두어 서로 밟지 않게 하고, 세션 이름과 색을 지정해 전환 비용을 줄이는 방식이다. 본인은 알파벳 수만큼 상주 워크트리를 두고 각각을 장기간 관리하는 에이전트를 붙여 쓴다고 소개했다. 에이전트끼리 메시지를 주고받는 기능, 일정 간격으로 스스로를 깨우는 반복 실행, 여러 세션을 한 화면에서 보는 관리 도구도 같은 맥락이다. 그는 클로드가 남긴 표현을 빌려 '이 시스템에서 가장 작은 상자는 당신의 주의력'이라고 정리했다.

주요 인사이트

• 모델 성능과 컨텍스트 크기의 성장 속도가 어긋나면서, 병목이 '모델이 얼마나 똑똑한가'에서 '유한한 창에 무엇을 넣을 것인가'로 옮겨 갔다. 발표자가 컨텍스트 엔지니어링과 소프트웨어 엔지니어링을 같은 것이라고 주장하는 근거다.
• 확장되는 추상화와 그렇지 않은 추상화를 가르는 기준은 단순하다. 쓰지 않을 때 비용이 0인가다. 훅이 좋은 예이고, 언제나 통째로 실려 들어가는 설정 문서가 나쁜 예다.
• 플러그인에 프로젝트 설명 문서를 넣는 기능이 없는 것은 누락이 아니라 의도적 설계다. 만드는 쪽에는 비용이 거의 들지 않는데 쓰는 쪽에 항상 비용이 청구되는 구조여서, 그런 기능을 열어두면 플러그인 대여섯 개만 켜도 컨텍스트가 차 버린다.
• 발표자는 모델이 스스로 정리하는 메모리와 사람이 설계하는 컨텍스트 엔지니어링을 의도적으로 구분한다. 둘 다 결국 텍스트 파일이지만, 재사용 가능한 규칙과 자동 축적되는 기록은 다르게 다뤄야 한다는 것이다.
• 도구를 만들 때는 지금의 부족함을 메우는 도구와 능력이 올라갈수록 함께 쓸모가 커지는 도구를 구분하라는 조언이 나왔다. 후자를 골라야 두 세대 뒤 모델에서도 그 투자가 살아남는다.

자주 묻는 질문

관련 AI 소식