AI 엔지니어링 노트
바닐라 상태의 AI 코딩 도구는 백지에서 시작하는 작은 프로젝트에는 충분하다. 그러나 수천 명이 같은 코드를 만지는 거대한 환경에서는 사정이 다르다. Claude Code 팀 엔지니어 데이지 홀먼(Daisy Holman)의 강연을 토대로, 대규모 소프트웨어 엔지니어링에서 AI 에이전트를 길들이는 세 가지 축과 그 밑바탕에 깔린 컨텍스트 윈도우의 경제학을 정리한다.
발표자는 먼저 두 단어를 구분한다. 프로그래밍(programming)은 코드를 쓰는 행위 자체이고, 소프트웨어 엔지니어링(software engineering)은 여러 이해관계자와 누적된 기술 부채, 관습이 얽힌 시스템 안에서 코드를 만들어 가는 일이다. 전자는 점(點)이고 후자는 그 점을 둘러싼 맥락 전체다.
이 구분이 중요한 이유는 단순하다. 갓 시작한 프로젝트, 즉 정해진 관습도 없고 쌓인 부채도 없으며 의존하는 외부 사용자도 없는 이른바 '백지에서 하나로(zero-to-one)' 단계의 코드라면, AI 코딩 도구는 별다른 손질 없이도 잘 작동한다. 도구가 모든 것을 혼자 소유할 수 있을 때는 굳이 외부 정보를 끌어올 필요가 없기 때문이다.
문제는 복잡도가 올라갈 때 생긴다. 누군가 당신의 코드에 의존하고, 외부 이해관계자가 존재하며, 결정의 배경이 코드가 아니라 다른 곳에 흩어져 있는 순간부터 바닐라 에이전트는 한계에 부딪힌다. 전문적인 소프트웨어 엔지니어링에서 정작 중요한 일의 대부분은 소스 코드 안에 살지 않는다. 그것은 설계 문서에, 서로 주고받은 이메일에, 메신저 대화 스레드에 흩어져 있다.
유능한 신입을 채용했다고 하자. 그가 회사 위키와 소스 저장소만 받고 회의에도 못 들어가고 메신저도 못 보는 상태라면, 코드는 짤 수 있어도 "왜 이 결정을 내렸는가"를 알 길이 없다. 바닐라 에이전트가 딱 그 상태다. 똑똑하지만 맥락에서 격리된 신입. 커스터마이징이란 결국 이 신입에게 회사의 신경망을 연결해 주는 일이다.
강연 전체를 관통하는 명제가 하나 있다. 발표자는 이것을 가장 먼저, 가장 강하게 못 박는다.
"에이전트가 당신이 닿는 모든 곳에 닿지 못한다면,
그 에이전트는 당신의 일을 함께할 수 없다."
— 데이지 홀먼, Claude Code 팀
여기서 '닿는 곳'은 소스 코드만을 뜻하지 않는다. 메신저 메시지, 이메일, 그리고 무엇보다 작업의 '왜(why)'까지를 가리킨다. 소스 코드는 무엇을 하는지(what)는 보여 주지만, 왜 그렇게 해야 하는지(why)는 좀처럼 설명하지 않는다. 그리고 그 '왜'를 매번 프롬프트에 손으로 타이핑하고 싶은 사람은 없다. 그 정보는 이미 어딘가에 존재하기 때문이다.
발표자는 오늘날 소프트웨어 엔지니어의 일을 "자기 자신의 작은 분신(clone)을 여럿 만들어 능력을 확장하는 것"으로 규정한다. 여러 에이전트에게 일을 나눠 규모를 키운다는 발상이다. 그런데 그 분신들이 정작 당신이 접근하는 정보에 접근하지 못한다면, 확장은 허상이 된다. 에이전트가 잘못된 방향으로 갈 때 사람들이 답답해하는 이유도 대개 여기 있다. 당신 머릿속에는 어딘가에서 얻은 정보가 있는데, 에이전트는 그 정보에 닿지 못하는 것이다.
그렇다면 무엇을, 어떻게 연결해 주어야 하는가. 발표자는 이를 세 가지 축으로 나눈다.
커스터마이징이 필요한 것은 결국 세 가지다. 첫째는 접근(Access), 곧 정보가 흐르는 통로다. 둘째는 지식(Knowledge), 곧 모델 안에 새겨 넣을 수 없는 당신만의 맥락이다. 셋째는 도구(Tooling), 곧 에이전트가 코드를 다룰 손과 눈이다. 발표자는 특정 제품에 국한된 이야기가 아니라 '에이전트 하니스 일반'을 어떻게 정보·연결·도구로 무장시킬 것인가라는 학술적 질문으로 이 셋을 다룬다.
가장 먼저 연결해야 할 것은 팀 메신저다. 결정은 거기서 내려진다. 어떤 기능을 왜 이렇게 구현하기로 했는지가 담긴 대화 스레드 전체를 에이전트가 볼 수 있다면, 에이전트는 어떤 전략이 통하지 않을지, 무엇이 더 나은지를 스스로 가늠할 수 있다.
두 번째는 CI/CD, 곧 지속적 통합·지속적 배포(Continuous Integration / Continuous Delivery) 파이프라인이다. 발표자는 단호하다. 이 시점에 CI 실패를 사람이 직접 고치고 있어서는 안 된다는 것이다. 에이전트는 그 일을 매우 잘하며 앞으로도 그럴 것이다. 세 번째는 대시보드다. 프로덕션에서 무언가 무너졌을 때, 많은 정보를 빠르게 끌어모아야 한다. 그리고 당신은 이미 이 작업을 에이전트로 처리하는 경쟁자들과 겨루게 될 것이다. 네 번째는 설계 문서, 운영 지침서(runbook) 같은 내부 문서다.
발표자가 던지는 실천 팁이 인상적이다. 하루 동안, AI 도구의 터미널이나 데스크톱 앱을 떠나지 않고 일해 보라는 것이다. 다른 도구로 손이 가거나, 무언가를 복사해 붙여 넣으려 창을 전환할 때마다 그것을 종이에 적어 둔다. 그 하나하나가 에이전트가 보지 못하는 정보다. 하루가 끝나면 그 목록의 모든 것을 에이전트에 연결할 방법을 찾는다. 격차는 직접 메워 보기 전까지 느끼는 것보다 훨씬 크다. 발표자는 회의 직후 녹취록을 에이전트에 먹이고 "여기서 바로 처리할 만한 손쉬운 일이 있는가"를 물어, 회의 한 번에 두세 건의 변경 요청(PR, Pull Request)을 얻는다고 했다.
두 번째 축은 한층 미묘하다. 당신의 코드베이스 관습, 제도적 기억, 지난주에 바뀐 무언가, 사내에서만 통하는 용어와 내부 API(응용 프로그래밍 인터페이스, Application Programming Interface) — 이런 것은 모델의 가중치(weight)에 훈련시켜 넣을 수 없다.
여기서 자연스럽게 떠오르는 질문이 파인튜닝(fine-tuning, 사전학습된 모델을 특정 데이터로 추가 학습시키는 것)이다. 발표자는 이를 두 가지 이유로 권하지 않는다. 첫째, 비용 효율이 나오지 않는다. 프런티어 모델이 워낙 빠르게 교체되기 때문에, 아무리 큰 기업이라도 작은 목적을 위한 파인튜닝을 끝낼 즈음이면 그 모델 자체가 한 세대 뒤처진다. 둘째, 더 근본적인 문제로 환각(hallucination)이 늘어날 수 있다.
이 두 번째 지적은 실제 연구로 뒷받침된다. 한 통제 실험은, 모델이 사전학습 때 보지 못한 새 사실을 파인튜닝으로 가르치면 그 새 지식이 기존 지식과 일치하는 예시보다 훨씬 더 느리게 학습되며, 끝내 학습되는 순간 모델이 사실을 지어내는 경향이 선형적으로 늘어난다는 점을 보였다. 결론은 명확하다. 대형 언어 모델은 사실 지식의 대부분을 사전학습에서 얻으며, 파인튜닝은 그것을 더 효율적으로 쓰는 법을 가르칠 뿐이라는 것이다. 새 사실을 욱여넣는 통로로는 적합하지 않다.
그래서 남는 유일한 손잡이가 맥락 내 학습(ICL, In-Context Learning)이다. 발표자는 이 용어를 두고 농담을 던진다. 똑똑해 보이고 싶을 때 쓰는 멋진 말이지만, 실은 그냥 텍스트 파일을 가리킨다는 것이다. 가중치를 건드리는 대신, 필요한 정보를 컨텍스트 윈도우에 적시에 넣어 주는 방식이다. 좋은 점도 나쁜 점도 있다. 모델 내부를 전혀 이해하지 못해도 행동을 바꿀 수 있어 시작이 쉽다. 그러나 사람들은 대개 "이 정도면 충분하겠지" 하고 거기서 멈추는데, 사실은 훨씬 더 정교한 최적화의 여지가 남아 있다.
새 직원에게 회사 규정을 가르치는 두 가지 방법이 있다. 하나는 몇 달에 걸쳐 모든 규정을 통째로 암기시키는 것(파인튜닝)이고, 다른 하나는 책상 위에 잘 정리된 안내서를 두고 필요할 때 펼쳐 보게 하는 것(맥락 내 학습)이다. 그런데 규정은 분기마다 바뀌고, 암기는 느릴뿐더러 잘못 외우면 없는 규정을 지어내기까지 한다. 빠르게 도는 세계에서는 잘 만든 안내서를 적시에 건네는 편이 거의 언제나 낫다.
이 지점에서 발표자는 리처드 서턴(Richard Sutton)의 '쓰라린 교훈(The Bitter Lesson)'을 끌어온다. 2019년의 짧은 에세이가 70년 AI 연구에서 길어 올린 결론은, 인간의 지식을 끼워 넣는 특화된 방법보다 계산량과 함께 확장되는 일반적 방법이 장기적으로 거의 언제나 압도적으로 이긴다는 것이다. 프런티어 모델에서 이 교훈이 지금 다시 확인되고 있고, 그래서 당신의 업무나 코드베이스에 특화된 무언가를 모델에 현실적으로 훈련시킬 수는 없다. 가진 도구는 스킬, 도구 연결, 지침 파일(에이전트에게 주는 상시 안내 문서) 같은 텍스트뿐이다.
세 번째 축은 발표에서 가장 흥미로운 비유를 낳는다. 발표자는 묻는다. "에이전트를 위한 통합 개발 환경(IDE, Integrated Development Environment)은 어떤 모습이어야 하는가?"
사람을 떠올려 보자. 우리는 코드를 쓸 때 문법 강조(syntax highlighting), 코드 자동 완성, 언어 서버 프로토콜(LSP, Language Server Protocol)의 도움을 받는다. 그런데 에이전트는 기본 상태에서 이런 것이 하나도 없다. 가진 것이라곤 편집 도구 하나뿐인데, 그것도 바꾸려는 문자열을 글자 그대로 적고 새 문자열로 치환하는 방식이다. 발표자의 표현을 빌리면, 이는 비주얼 에디터 이전의 원시적 행 편집기 수준이다. 우리가 만들어 줘야 할 것은 '에이전트판 코드 편집기', '에이전트판 자동 완성', 그리고 무엇보다 '에이전트판 빨간 물결선(red squigglies)'이다.
변수 이름을 잘못 쓰거나 함수에 인자 개수를 틀리게 넘기면 편집기가 그 아래 빨간 물결선을 긋는다. 이 선의 묘미는 작업을 완전히 멈추지 않으면서도 "다시 한번 생각해 보라"고 슬쩍 찌른다는 데 있다. 당신은 "아, 저 변수는 맞아. 함수를 아래에서 정의할 거니까"라며 무시하고 계속 갈 수도 있다. 강제가 아니라 무시 가능한 넛지(nudge)다. 에이전트에게도 바로 이런 장치가 필요하다.
그 역할을 하는 것이 사후 도구 사용 후크(post-tool-use hook)다. 에이전트가 어떤 도구를 쓴 직후에 자동으로 실행되는 짧은 스크립트로, 린터를 돌리거나 LSP의 피드백을 에이전트에게 되돌려 줄 수 있다. 좋은 예가 자동 생성 파일이다. 에이전트가 생성 파일을 편집하지 못하도록 무조건 차단할 수도 있지만, 어쩌면 에이전트는 뭔가를 시험해 보려고 일부러 그 파일을 건드린 것일 수 있다. 그러니 차단하는 대신 "이건 생성 파일이니 저장소에 커밋하면 안 된다"고 일깨워 주면, 에이전트는 대개 변경을 되돌리거나 올바른 위치에 다시 넣는다. 정확히 빨간 물결선이 하는 일이다.
발표자는 도구를 두 종류로 나눈다. 지능의 부족을 메우는 도구와 지능과 함께 확장되는 도구다. 빨간 물결선은 후자다. 무언가 놓쳤을지 모른다고 일깨우되, 특별한 사정을 아는 에이전트는 무시하고 갈 수 있다. 반대로 "정의되지 않은 변수는 절대 못 쓰게" 하드 차단하면 실수는 줄겠지만 에이전트가 코드를 특정 순서로만 쓰도록 강제되어 지능이 좋아져도 가치가 늘지 않는다. 발표자가 에이전트에게 "주면 안 되는 도구"의 예를 물었더니, 에이전트는 "내 도구를 빼앗는 건 싫다"고 답했다고 한다. 모델이 좋아질수록 함께 쓸모가 커지는 도구를 생각하는 것 — 이것이 발표자가 말하는 'AGI를 염두에 둔(AGI-pilled)' 접근이다.
세 가지 축을 모두 연결하기로 했다고 하자. 그런데 그 정보를 다 어디에 넣을 것인가. 모든 커스터마이징은 결국 단 하나의 공간, 컨텍스트 윈도우(context window, 모델이 한 번에 참조할 수 있는 입력 텍스트의 총량)로 들어가야 한다. 그리고 이 방은 생각보다 훨씬 좁다.
발표 시점 기준 최신 모델의 컨텍스트 윈도우는 약 100만(1M) 토큰 수준이다. 흥미로운 점은, 이 숫자가 거의 자라지 않고 있다는 사실이다. 1년 전 선두 프런티어 모델들도 대부분 100만 토큰급이었다. 그사이 모델의 능력은 비교할 수 없이 좋아졌지만, 컨텍스트 윈도우의 한계선만큼은 거의 그대로다.
이것은 역설적으로 다행스러운 면이 있다. 컨텍스트 엔지니어링의 표적이 고정되어 있다는 뜻이기 때문이다. 그러나 동시에 냉정한 제약이기도 하다. 출력 품질을 높이는 유일한 손잡이가 맥락 내 학습인데, 그 맥락을 담을 그릇의 크기가 고정돼 있다면, 코드베이스 전체나 위키 전체를 들이부을 수는 없다. 적절한 정보를 적절한 시점에 넣는 더 영리한 방법을 찾아야만 한다.
발표자는 이 상황을 "아두이노(Arduino)에서 NPM을 돌리는 것" 같다고 표현한다. 메모리가 손바닥만 한 마이크로컨트롤러에 패키지를 닥치는 대로 설치하면, 정작 당신의 코드를 돌릴 공간이 남지 않는다. 무엇을 넣을지 극도로 의도적이어야 하고, 넣더라도 가능한 한 가장 작은 버전으로 넣어 실제 작업을 위한 여유를 남겨야 한다. "쓰지 않는 것에 비용을 지불하지 마라(don't pay for what you don't use)" — C++ 세계의 무오버헤드(zero-overhead) 원칙이 여기서 그대로 적용된다.
발표자는 이를 단순한 권고가 아니라 물리적 한계로 본다. 컨텍스트 윈도우가 더 커지지 않는다면, 정보를 모델에 더 효율적으로 넣는 유일한 길은 '쓰지 않는 것에 값을 치르지 않는' 기술을 갈고닦는 것뿐이다.
여기서 비유가 무너지는 지점이 등장한다. 처음에는 이 문제가 컴퓨터의 캐시 설계와 비슷해 보인다. 1차 캐시(L1 cache)가 메모리 전체를 담지 못하니, 최근에 안 쓴 것을 밀어내고(eviction) 필요한 것을 채우면 되지 않을까. 그런데 그렇게 못 하게 만드는 또 하나의 제약이 있다. 바로 KV 캐시(Key-Value cache, 모델이 앞서 계산한 토큰들의 내부 상태를 저장해 두는 장치)다.
KV 캐시는 다음 토큰을 계산하는 비용을 크게 좌우한다. 핵심은 비대칭성에 있다. 프롬프트의 앞쪽에 있는 무언가를 바꾸면, 그 변경 지점 이후의 모든 토큰이 캐시에서 무효화되어 다시 계산되어야 한다. 그리고 캐시되지 않은 토큰은 캐시된 토큰보다 대략 열 배 비싸다. 따라서 "가장 오래 안 쓴 도구를 하나 빼고 곧 필요한 도구로 교체"하는 식의 최소 적재 캐시(LRU, Least Recently Used) 전략을 도구 정의 블록에 적용하면, 그 블록 뒤의 캐시 전체를 무효화하는 대가를 치른다.
그래서 전략은 분명해진다. 안정적이고 여러 작업에 공유되는 정보는 맨 앞에, 작업마다 바뀌는 휘발성 정보는 뒤쪽 가까이에 둔다. 그래야 휘발성 정보를 큰 비용 없이 밀어낼 수 있다. 발표자는 초기 에이전트 커스터마이징이 LRU 캐시식 접근을 취했던 것을 두고, 컨텍스트가 3만 2천 토큰뿐이고 모든 토큰이 비싸던 시절에는 말이 됐지만 지금은 사정이 다르다고 본다. 이제는 앞쪽 토큰을 '싸게 재사용할 자산', 무효화를 부르는 변경을 '비싼 부채'로 여겨야 한다. 이 제약을 우회하는 일은 어렵고, 발표자는 이 문제가 풀렸다고 보지 않는다. Claude Code 팀이 매일 고민하는 종류의 문제다.
이제 구체적인 커스터마이징 수단으로 들어간다. 발표자가 검토하는 네 가지 플러그인 기본 부품은 MCP, 스킬(Skills), 후크(Hooks), 에이전트(Agents)다. 다만 그는 줄곧 하나의 질문으로 이들을 시험한다. "이것을 1만 개, 10만 개 갖게 되면 무슨 일이 벌어지는가?" 수천에서 수만 명의 엔지니어가 같은 단일 저장소(monorepo)에서 일하는 환경에서, 정보를 컨텍스트를 너무 빨리 채우지 않으면서 효율적으로 퍼뜨리는 것이 관건이기 때문이다. 이미 수만 개의 스킬을 거느린 채 확장 한계에 부딪힌 기업들이 존재한다.
MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 2024년 11월에 공개된, AI 모델을 외부 도구·데이터에 연결하는 개방형 표준이다. 이해의 출발점은 그것이 설계된 시대다. MCP는 본래 훨씬 단순하던 시절, 주로 챗봇을 염두에 두고 설계되었다. 챗봇은 대개 서버리스(serverless)로 돌거나 컨테이너 없이 동작해, 당신 컴퓨터의 파일에 접근하지 못하고 명령을 실행하지 못하며 명령줄 도구(CLI, Command-Line Interface)를 쓸 수 없다. MCP는 그런 환경에 도구를 주입하는 방법이었다.
좋은 속성도 분명하다. 전송 계층에 구애받지 않고(transport-agnostic), 인증(auth)을 대체로 알아서 처리해 준다. 그래서 어떤 회사가 자사 제품과 Claude의 연동을 대중에게 배포하려 한다면, 적어도 처음에는 그 연동이 MCP 서버 형태인 편이 자연스럽다.
그런데 우리가 이야기하는 무대는 대규모 사내 소프트웨어 엔지니어링이다. 여기서는 사정이 다르다. Claude Code는 셸을 가지고 있다. 따라서 이미 CLI가 있다면, 비기술적 외부 고객에게 배포할 것이 아닌 한, 그 CLI를 MCP로 감싸는 것은 큰 의미가 없다. 대개는 "이 CLI를 이렇게 쓰라"고 알려 주는 스킬 한 장을 쓰는 편이 작성하기도 쉽다. 사내 개발자가 사용자라면 그들은 이미 소스 코드 접근 권한이 있어, MCP를 위한 인증 수명주기를 처음부터 다시 세팅할 필요가 없다. 물론 남이 만든 MCP 서버는 여전히 필요하다. 메신저나 이메일에 연결하려면 지금으로선 그쪽 MCP 서버를 써야 한다.
스케일에서 무슨 일이 벌어지는지가 핵심이다. 도구 1만 개를 모두 에이전트가 쓸 수 있게 하려면, 각 도구의 이름·설명·스키마(schema, 도구 호출 형식 명세)를 전부 시스템 프롬프트에 넣어야 한다. 서버 20개에 도구가 각 15개씩만 있어도 컨텍스트의 상당 부분이 도구 정의로 채워진다. 실제로 보고된 한 환경에서는 MCP 서버 7개의 도구 정의가 기본 컨텍스트의 약 33.7%에 해당하는 6만 7천여 토큰을 잡아먹었다. MCP 서버 하나가 50개 이상의 도구를 갖기도 한다. 도움 없이는 확장되지 않는 구조다.
그래서 등장한 것이 Tool Search다. 도구 이름만 시스템 프롬프트에 넣고, "나중에 쓸 도구를 검색할 수 있는 도구가 있다"고 에이전트에게 알려 준다. 검색해 도구를 찾으면 그 시점에 설명과 스키마를 준다. 일종의 게으른 적재다. 다만 공짜 점심은 없다. 메신저처럼 사용자가 명시적으로 언급하는 경우가 아니면, 에이전트는 도구를 검색해야 한다는 사실 자체를 모를 수 있다. 그래서 편집 도구·셸 도구처럼 범용적인 것은 결국 스키마째 시스템 프롬프트에 넣게 된다. 또 설명을 많이 넣을수록 에이전트가 검색할 확률은 높아지지만 그만큼 토큰을 더 쓴다. 약간 더 싼 점심일 뿐이다.
발표자가 스킬을 처음 설명할 때 쓴 표현은 "게으른 시스템 프롬프트(lazy system prompt)"다. 스킬은 본질적으로 폴더 하나다. 그 안에 마크다운 파일이 있고, 그 파일에는 "언제 이 스킬을 읽어야 하는지"를 알려 주는 한 줄짜리 요약이 머리말(front matter)에 붙어 있다. 이 한 줄은 시스템 프롬프트에 들어가고, 에이전트는 필요할 때 전체 스킬 문서와 그 안의 스크립트·자료를 도구로 불러온다.
폴더에 마크다운 한 장이면 되니 저장소에 만들어 두기가 무척 쉽다. 이것은 장점이자 단점이다. 너무 쉽게 만들 수 있기 때문에, 단일 저장소 안에서 스킬의 품질을 어떻게 관리할지를 반드시 고민해야 한다.
스케일 관점에서 보면, 스킬은 본문이 종량제(lazy)라는 점에서 좋다. 그러나 설명은 항상 적재되므로, 그 본문의 작은 일부에 해당하는 값을 시스템 프롬프트에서 늘 치르게 된다. 완전한 무오버헤드는 아니다. 스킬을 안정적으로 발동시키려면 설명이 때때로 300~400 토큰에 이르기도 한다. 그리고 설명을 줄일수록, 사용자가 명시적으로 말하지 않는 한 스킬이 안정적으로 발동될 확률은 낮아진다. 또한 스킬은 아직 계층(hierarchy)을 정의하는 방법이 없다. 하위 스킬을 게으르게 노출하지 못한다. 이는 현재 개선 중인 과제다.
후크는 앞서 도구 축에서 자세히 다룬 '에이전트판 빨간 물결선'이다. 특정 이벤트(예: 도구 사용 직후, 커밋 직전, 특정 파일 편집 시도)에 자동으로 실행되는 결정론적 셸 스크립트로, 모델의 판단에 의존하지 않는다. 컨텍스트 비용이라는 면에서 가장 가볍다. 후크 자체는 토큰을 거의 먹지 않고, 실행 결과 가운데 에이전트에게 되돌려 줄 필요가 있는 것만 주입되기 때문이다. 무엇보다 후크에 필요한 스크립트(린터, 테스트, 검증기)는 이미 사람을 위해 만들어 둔 것을 재활용하면 된다.
네 번째 부품인 (서브)에이전트는 일을 다른 에이전트에게 위임하는 장치다. 발표에서 깊이 파고들지는 않았지만, 스케일 관점의 의의는 분명하다. 위임받은 에이전트는 자신만의 별도 컨텍스트 윈도우를 갖는다. 따라서 큰 작업을 쪼개 각 하위 작업의 맥락을 격리하면, 메인 에이전트의 좁은 방을 잡다한 중간 산물로 채우지 않을 수 있다. 컨텍스트라는 희소 자원을 분산해 다루는 또 하나의 방법인 셈이다.
| 부품 | 핵심 성격 | 컨텍스트 비용 | 대규모에서의 함의 |
|---|---|---|---|
| MCP | 외부 시스템 연결 | 도구 정의 상시 적재 — 무거움 | 남의 서버(메신저·이메일)엔 필요. 사내 CLI 래핑은 비효율. Tool Search로 완화 |
| 스킬 | 게으른 시스템 프롬프트 | 본문은 종량제, 설명은 상시 — 가벼움 | 만들기 쉬워 품질 관리 필요. 계층 미지원 |
| 후크 | 결정론적 넛지 | 거의 없음 — 실행 결과만 주입 | 이미 가진 스크립트를 재활용 |
| 에이전트 | 위임·분업 | 별도 컨텍스트 윈도우 사용 | 맥락 격리로 메인 컨텍스트 절약 |
네 부품을 관통하는 결론은 처음의 명제로 되돌아간다. 에이전트가 당신이 닿는 곳에 닿게 하라. 그리고 그 연결을 좁은 컨텍스트 윈도우의 경제학을 거스르지 않는 방식으로 하라. 발표자가 거듭 강조하는 한 문장이 있다.
에이전트를 코드베이스에 능숙하게 만드는 가장 빠른 길은
더 똑똑한 모델이 아니라, 더 촘촘한 피드백 루프다.
여기서 가장 실용적인 위안은, 그 루프에 필요한 거의 모든 것을 당신이 이미 가지고 있다는 사실이다. 사람 개발자를 위해 환경을 세팅하고 코드를 다룰 길을 마련하면서, 린터·테스트·빌드 스크립트·CLI를 이미 만들어 두었기 때문이다. 바퀴를 다시 발명할 필요는 없다. 그것들을 올바른 방식으로 에이전트에 연결해 주기만 하면 된다.
커스터마이징의 진입 장벽이 낮다는 점도 양면적이다. 모델의 가중치를 전혀 이해하지 못해도, 텍스트 파일만으로 에이전트의 행동을 바꿀 수 있다. 그래서 시작이 쉽고, 그래서 사람들은 "이만하면 됐다" 하고 멈춘다. 그러나 맥락 내 학습에는 정교하게 다듬을 여지가 깊게 남아 있다. 무엇을 넣을지뿐 아니라, 어디에 넣을지(KV 캐시), 언제 불러올지(게으른 적재), 어떻게 발동시킬지(스킬 설명)까지가 모두 최적화의 대상이다.
마지막으로 발표자가 권하는 사고의 방향은 '지능과 함께 자라는 도구'다. 모델이 좋아질수록 가치가 줄어드는 도구(지능의 부족을 메우는 하드 차단)가 아니라, 모델이 좋아질수록 함께 쓸모가 커지는 도구(무시 가능한 넛지)를 설계하라는 것이다. 컨텍스트 윈도우는 한동안 자라지 않을지 모르지만, 그 안에 무엇을 어떻게 담을 것인가라는 질문은 여전히 충분히 열려 있다. 그리고 이 질문에 잘 답하는 일이, 코딩을 소프트웨어 엔지니어링으로 확장하는 실제 작업이 된다.