AI Engineer

1. 무엇이 문제였나

마이크로소프트의 오넬라와 조엘이 라이브 AI 음성 튜터 에이스(Ace)를 만들었다. 학생과 말을 주고받으며 레슨 하나를 처음부터 끝까지 끊기지 않게 진행하는 제품이다.

여러 단계로 이어지는 *에이전트를 실제로 배포해 본 사람은 같은 장면을 본다. 데모까지는 잘 돌다가 진짜 사용자가 붙으면 중간에서 무너진다. 절반쯤 가서 스스로 끝났다고 판단하거나, 단계 하나를 건너뛰거나, 같은 자리를 맴돈다.

누구나 처음 잡는 해법은 프롬프트를 더 강하게 쓰고 빠져나갈 구멍을 규칙으로 메우는 것이다. 발표자들은 이 진단이 틀렸다고 본다. 신뢰성이 안 나오는 원인은 약한 프롬프트가 아니라 모델에게 준 통제(control) 권한이라는 것이다.

두 사람이 든 비유가 배우와 감독이다. 모델은 배우이고 *하네스는 감독이다. 배우는 대사 한 줄을 훌륭하게 소화한다. 그런데 지금이 여섯 장면 중 세 번째인지 기억하는 일에는 형편없다.

그래서 두 사람은 기억하라고 요구하는 것 자체를 그만뒀다.

2. 무엇을 바꿨나

에이스에서 레슨 하나는 여섯 단계를 오가는 *상태 머신이다. 인트로, 티치, 체크, 그레이드, 어드밴스, 랩 순서다. 발표는 단계 이름만 대고 각 단계가 안에서 무엇을 하는지는 설명하지 않는다.

중요한 것은 단계를 쪼갰다는 사실이 아니다. 단계를 넘기는 판단을 모델 바깥으로 옮겼다는 것이다. 조엘은 에이스를 만들 때 「지금 단계가 무엇인가」와 「그다음에 올 수 있는 단계가 무엇인가」를 먼저 따졌다고 밝혔다.

3. 한 단계가 어떻게 도나

각 단계는 모델에게 *좁은 계약을 하나씩 보낸다. 이 한 가지만 하고 결과를 돌려달라는 형태다. 돌아온 결과를 하네스가 검증하고, 상태를 다음으로 넘기고, 다음에 무엇을 할지 정한다. 조엘의 표현으로는 모델이 제안하고 하네스가 결정한다.

발표 중반에 조엘이 실제 레슨 하나의 로그 녹화를 틀었다. 화면 오른쪽에 하네스 네 갈래가 각자 돌고 있는 기록이 흘렀다.

레슨 하나에 붙은 하네스 넷

에이스에서 특히 공들인 판단은 셋이다. 레슨이 언제 끝났는지, 학생이 정말로 이해했는지, 다음에 무엇을 할지. 이 세 범주에 들어가는 모든 질문과 모델이 취해야 할 모든 행동을 모델 바깥에서 미리 설계해 뒀다.

4. 그래서 작은 모델로 내려갔다

조엘은 오늘날 프런티어 모델, 예를 들어 앤트로픽의 오퍼스 4.7(Opus 4.7) 같은 모델을 사람들이 생각부터 처리까지 전부 맡기는 데 쓴다고 짚었다. 좋을 때도 있지만 학생과 실시간으로 말을 주고받는 라이브 튜터에서는 늘 통하지 않는다. 여기서는 신뢰성과 비용과 속도가 한꺼번에 필요하기 때문이다.

하네스로 흐름을 붙잡고 나자 무거운 오퍼스 4.7 대신 훨씬 작고 추론 능력도 떨어지는 하이쿠 4.5(Haiku 4.5)로 내려갈 수 있었다. 그런데도 기대한 수준으로 작동했고 비용과 시간과 지연을 아꼈다고 한다.

이 대목만 떼어 「작은 모델로 갈아 끼우면 싸진다」로 읽으면 거꾸로다. 모델이 내릴 판단을 하네스가 먼저 가져갔고, 그래서 모델에 남은 일이 쉬워졌고, 쉬워진 다음에야 하이쿠 4.5로 내려갈 수 있었다.

5. 언제 이 방법을 쓰나

발표는 판단 기준을 하나 남긴다. 지금 굴리는 에이전트가 성공할지 실패할지가 동전 던지기 수준이라면 제어 흐름을 모델에서 빼내라는 것이다. 모델이 더 많은 결정을 내리게 두지 말고, 그 결정들을 모델 바깥에 미리 만들어 두고, 모델에게는 쉽게 답할 수 있는 입력만 넘긴다.

음성 튜터에만 해당하는 이야기가 아니다. 코딩 에이전트, *옵스 런북, 온보딩 플로우에도 같은 원칙이 든다고 했다. 발표는 「모델이 말은 하게 하되 운전은 시키지 마라」는 문장으로 끝난다.

6. 발표가 밝히지 않은 것

6분짜리 발표라 빠진 정보가 많다. 세 가지를 기억해 두는 편이 좋다.

첫째, 비용과 지연이 얼마나 줄었는지 숫자가 없다. 아꼈다는 말만 있다.

둘째, 하네스가 모델의 결과를 어떻게 검증하는지는 공개되지 않았다. 검증 자체가 또 다른 모델 호출인지 규칙으로 짠 코드인지가 이 구조의 비용을 좌우하는데, 그 대목은 로그 화면으로만 지나갔다.

셋째, 새로운 상황을 전부 상태 머신 안에 녹여 넣었다는 말은 뒤집으면 상황이 늘어날 때마다 사람이 상태를 늘려야 한다는 뜻이다. 모델에게서 뺏은 판단은 사라지지 않고 개발자의 일로 옮겨 온다. 발표는 이 비용을 다루지 않는다.

1. 충돌보다 조용한 성공이 나쁘다

OpenAI에서 핵심 데이터·AI 인프라를 다루는 발표자가 프로덕션 에이전트 실패를 주제로 발표했다. 이전에는 애플과 우버에서 분산 시스템을 만들었고 「The Agent Stack」이라는 블로그를 쓴다.

발표를 여는 사고는 이렇다. 사용자가 고객 환불 건을 다음 턴을 위해 기억해 달라고 했고 어시스턴트는 기록했다고 답했다. 화면은 정상이었다. 빨간 오류도 눈에 띄는 실패도 없었다. 그런데 다음 턴에서 그 사실을 다시 불러오지 못했다.

충돌은 성가시지만 적어도 경계를 준다. 무언가 멈췄다는 것을 알 수 있고 마지막 정상 지점에서 다시 시작할 수 있다. 조용한 성공은 그 경계를 안 준다. 전달은 성공했고 저장은 실패했는데 사용자에게도 운영자에게도 의심할 이유가 없다.

다음 턴에도 모델은 여전히 그럴듯하게 말한다. 일관돼 보이지만 끊긴 이력 위에서 일관된 것뿐이다.

발표는 *오픈클로를 예로 쓴다. 홍보가 아니라 이슈와 코드와 문서가 공개돼 있어 하니스 구조가 유난히 잘 들여다보이기 때문이라고 밝힌다.

2. 계약 한 줄

이 발표의 문장은 하나다. 모델은 제안하고 하니스는 확정하며 영수증이 그것을 증명한다.

모델은 메시지와 툴 호출과 수정과 명령을 제안할 수 있다. 그러나 그 자체로 프로덕션의 경계는 아니다. 상태 전환, 권한 검사, 순서 있는 커밋, 영수증은 *하니스의 몫이다.

대화 기록은 증거가 아니다. 기록은 에이전트가 무엇이라고 말했는지를 남기고, *영수증은 시스템이 실제로 무엇을 했는지를 남긴다.

발표자가 든 비유는 자동차다. 모델은 엔진이다. 강력하지만 아무도 마력만 보고 프로덕션용 차를 사지 않는다. 조향과 제동과 도로 규칙과 계기판과 블랙박스도 본다. 모델은 능력을 주고 하니스는 통제를 준다. 브레이크 없는 강력한 엔진은 자율이 아니라 가속도만 좋은 부채다.

3. 하니스는 무엇으로 이루어져 있나

에이전트를 깨우는 신호는 한 곳에서만 오지 않는다. 사람이 친 채팅도 있고, 다른 시스템이 보낸 알림도 있고, 시간이 되어 울린 타이머도 있고, 살아 있는지 확인하는 신호도 있다.

그래서 하니스가 맨 처음 하는 일이 정해진다. 들어온 신호가 어느 대화의 것인지 이름표를 붙이는 것이다. 발표에서 세션 키라고 부르는 것이 그 이름표다.

이름표 하나가 곧 울타리가 된다. 그 대화에 딸린 기록과 메모리와 정책이 그 울타리 안에 든다. 그리고 울타리 안의 것을 고치는 문은 하나로 둔다. 두 곳에서 동시에 고치는 일을 막으려는 것이고, 이 문을 하나로 안 두면 뒤에 나오는 「겹친 기록자」 사고가 난다.

그 뒤는 단순하다. 모델과 도구를 부르고, 도구는 승인과 정책을 지나서야 실행되고, 그 실행이 남긴 기록이 영수증이 된다. 개인 비서형이든 코딩 에이전트든 이 밑구조는 같다고 발표자는 말한다.

여기서 하나 더 짚을 것이 있다. 에이전트는 사람처럼 기억하지 않는다. 턴이 끝나면 잊으므로 하니스가 매 턴 필요한 것을 다시 모아 넘긴다. 대화 기록과 세션 상태와 메모리와 정책과 도구 목록이 그것이다. 모델은 넘겨받은 것만 보므로, 하나가 빠지거나 낡아도 답은 여전히 그럴듯하게 들린다.

타임아웃과 재시도와 *멱등성과 락과 순서는 새 문제가 아니다. 달라진 것은 환경이다. 모델이 매 턴 계획을 새로 세우고 넘길 것을 다시 모으는 데다, 깨우는 신호도 손댈 곳도 늘었다. 그래서 같은 실패가 더 쉽게 터지고 원인을 대기는 더 어려워졌다.

4. 사고 다섯, 빠진 경계 다섯

발표는 오픈클로에서 실제로 열렸던 이슈 다섯 건을 든다. 다섯 다 사용자 화면에는 문제가 없었다.

사고 다섯 건과 그때 빠져 있던 경계

여기서 소유자는 사람이 아니라 그 사실이 진실이 되는 시스템을 뜻한다. 달력 일정은 달력 시스템이, 상담 상태는 티켓 시스템이, 코드 변경은 저장소가, 대화 턴은 세션 기록이, 사용자 선호는 메모리 저장소가 소유한다. 저장은 바이트가 어디 있는지를 말하고 소유권은 누가 그 실재를 재구성할 수 있는지를 말한다.

순서 규칙은 좁고 단순하다. 가변 상태 경계 하나에 순서가 정해진 커밋 경로 하나. 동시성 자체를 없애자는 말이 아니다. 병렬 읽기도 독립적인 검색도 여러 세션 동시 실행도 서브 에이전트로 나누는 것도 괜찮다. 보수적으로 지킬 것은 커밋 시점이지 시스템 전체가 아니다.

승인은 막연한 기억이 아니라 범위가 한정된 실행 상태여야 한다. 쓸모 있는 승인 객체는 누가, 어떤 세션과 실행에서, 어떤 툴과 인자에 대해, 얼마 동안, 어떤 결과로 승인했는지에 답하고 영수증을 가리킨다. 그 필드가 재시도나 재생 도중 떨어져 나가면 하니스는 그 행동이 승인된 것임을 더 이상 증명할 수 없다.

5. 증명은 주장이 아니라 사슬이다

내부 성공은 외부 증명이 아니다. 툴 결과는 내부 경로가 요청을 받아들였다는 것만 증명한다. 사용자가 그것을 봤다는 것은 증명하지 못한다.

그 차이가 대화를 바꾼다. 에이전트는 나중에 이미 보냈다고 말할 수 있고 사용자는 정말로 본 적 없다고 말할 수 있다. 영수증은 사용자가 신경 쓰는 그 경계에서 끝나야 한다.

6. 프로덕션 자취 하나에 물을 다섯 가지

발표자는 팀에 돌아가 모든 에이전트가 아니라 하나만 골라 실제 프로덕션 경로 하나의 자취를 놓고 영수증을 요구해 보라고 제안한다.

감사에 쓸 다섯 질문

이 다섯을 맨 처음 사고에 대 보면 이렇게 된다. 깨운 것은 사용자 메시지, 물려받은 상태가 곧 깨진 경계, 실행된 것은 채널 전송이었다. 살아남은 증거는 전달뿐이고 지속된 턴은 아니었다. 그 에이전트에 필요했던 것은 더 나은 모델도 더 나은 프롬프트도 아니고 완전한 영수증을 갖춘 더 나은 하니스였다.

발표는 루프가 한 턴에 답할 수 있지만 하니스라야 프로덕션을 지탱한다는 문장으로 끝난다.

7. 발표가 밝히지 않은 것

발표자는 OpenAI 에이전트 *SDK에 이런 하니스 요소가 이미 들어 있다고 소개한다. 자기 회사 제품을 파는 대목이라 그대로 받지 않는 편이 좋다.

숫자가 없다. 사고는 다섯 건 다 공개 이슈를 가리키지만 얼마나 자주 났고 얼마나 많은 사용자가 겪었는지는 나오지 않는다.

영수증을 어디에 얼마나 오래 남기는지, 그 저장과 조회에 얼마가 드는지도 다루지 않는다. 모든 실행 경계에 영수증을 남기라는 요구는 기록량이 실행량을 따라 늘어난다는 뜻인데, 그 비용이 이 설계의 실제 문턱이다.

일반화의 근거가 얇다. 개인 비서형(오픈클로·Hermes)과 코딩 에이전트(코덱스·커서·오픈코드·클로드 코드)가 같은 밑구조를 쓴다고 발표자는 말하지만, 사고 사례로 든 이슈는 오픈클로 것뿐이다. 같은 다섯 경계가 다른 시스템에서도 같은 순서로 무너지는지는 이 발표만으로 알 수 없다.

1. 무엇을 말하는 발표인가

마이크로소프트의 수석 응용과학자가 에이전트로 애플리케이션을 만드는 이야기를 한다. 사이버보안 부서에서 시큐리티 코파일럿과 그 에이전트를 만드는 데 참여했고, 그 전에는 우버에서 4년간 지오스페이셜 문제를 다루는 기계학습을 했다고 밝힌다.

이 발표가 자신이 오라일리에서 낼 300쪽짜리 책을 간추린 것이라고 먼저 말한다. 앞의 일곱 장이 이미 조기 공개돼 있고 다음 달 인쇄에 들어간다고 한다. 발표 내용의 코드 예제도 그쪽에 있다고 넘긴다.

바닥에 깔린 사실 하나가 나온다. Y 컴비네이터에 속한 회사 가운데 자기를 에이전틱하다고 말하는 곳이 3년 사이 254% 늘었다.

2. 축을 하나 더 놓는다

발표의 출발점은 사람들이 축을 하나만 보고 있다는 지적이다. 얼마나 자율적인가만 따진다는 것이다.

여기에 두 번째 축을 놓자고 한다. 그 시스템이 실제로 일을 해내는가다.

발표가 든 두 사례

사례가 둘뿐이라는 점은 그대로 적어 둔다. 발표는 네 칸을 다 채우지 않고 이 둘만 짚는다. 요점은 자율성이 낮아도 일을 잘 해내는 것이 있다는 쪽이다.

그래서 에이전시는 목표가 아니라 문제를 푸는 데 쓰는 수단이라고 정리한다.

3. 필요한 만큼만 올라가라

이 주장이 실제 설계로 내려오는 자리가 *오케스트레이션이다. 한 줄로 이어 붙인 체인으로 풀리면 그렇게 두라고 한다. 안 되면 갈림길을 만들어 모델이 어느 길로 갈지 고르게 한다. 완전히 에이전트에 맡기는 것은 모델의 손에 더 많은 힘을 쥐어 주는 일이라고 말한다.

한 판이 도는 방식 자체는 단순하다. 모델이 낸 글에 파서를 대고, 도구를 부르고, 돌아온 것을 관찰로 받고, 그 정보를 다시 넣어 반복하다가 마지막 출력을 낸다.

여러 에이전트를 쓸 때는 조정자를 하나 두고 그것이 알맞은 에이전트로 일을 넘기게 한다.

4. 평가가 바퀴가 되어야 한다

발표자는 완벽을 기대하지 말라고 못 박는다. 초기 프로토타입에서 정확도 70%까지는 쉽게 가는데, 복잡한 상황이 길게 이어지는 꼬리로 갈수록 점점 어려워진다는 것이다.

그래서 평가를 한 번 하고 끝내지 말고 바퀴로 만들라고 한다. 사람 검토를 거친 것만 평가셋에 쌓고, 늘어난 평가셋으로 다시 돌리고, 실패를 묶어 간추린 다음 고칠 것을 낸다.

안전 쪽도 한 줄 짚는다. 마이크로소프트가 *레드팀용으로 낸 파이릿(PyRIT)을 에이전트를 내보내기 전에 돌려 보라고 권한다. 자기 회사 도구를 권하는 대목이다. 다만 그러면서 좋은 소프트웨어 공학의 기본이 더 중요하다고 덧붙인다.

5. 발표가 밝히지 않은 것

50~70%대라는 점수가 무슨 지표인지 좁혀지지 않는다. 학계의 앞선 에이전트 벤치마크라고만 하고 어느 벤치마크인지 말하지 않는다. 여러 번 도구를 부르고 복잡한 환경에서 움직여야 하는 어려운 과제라는 설명만 붙는다.

롱테일이 얼마나 어려운지도 값이 없다. 70%까지 쉽고 그 뒤가 어렵다는 말은 나오는데, 남은 구간을 메우는 데 무엇이 얼마나 드는지가 없다.

두 축 위에 놓인 사례가 둘뿐이다. 높은 에이전시 쪽 칸이 비어 있어서, 자율성을 올렸을 때 효능이 어떻게 되는지가 사례로 안 나온다. 발표의 주장이 바로 그 자리에 있는데 그 자리가 비었다.

한 가지는 드물게 좋다. 발표자가 모델과 프레임워크가 발밑에서 바뀌고 있다고 스스로 밝힌다. 날짜를 붙여 읽어야 한다는 것을 발표가 먼저 말해 주는 편이다.

1. 무엇을 말하는 발표인가

딥마인드에서 제미나이의 에이전트 쪽 일을 하는 사람이 발표한다. 엔지니어가 왜 에이전트 만드는 데서 막히는지를 10분 동안 다룬다.

깔고 가는 전제가 하나 있다. 소프트웨어를 짤 때는 입력 A를 넣으면 늘 C가 나온다고 가정했다. 에이전트는 *비결정적이라 그 가정이 깨진다.

그것이 왜 문제인지 예로 든 것이 상담 에이전트다. 같은 프롬프트가 열 번에 한 번만 되면 프로덕션에 올릴 것이 못 되고 계속 흔들린다.

2. 만드는 일이 도는 모양

예전에 소프트웨어를 만드는 순서는 한 줄이었다. 명세를 쓰고, 코드를 짜고, 잘 도는지 시험을 만들고, 배포하고, 사용자가 썼다.

에이전트는 다르다. 무엇을 하길 바라는지 적고, 굴려 보고, 무엇을 하는지 지켜보고, 프롬프트나 도구를 손보고, 다시 굴린다. 지켜보는 일이 만드는 일 안으로 들어왔다.

3. 다섯 가지가 달라졌다

발표가 든 다섯을 순서대로 옮긴다.

예전 방식과 갈리는 다섯 자리

옛 방식이 어땠는지도 예로 나온다. 사용자가 구독을 끊겠다고 하면 분류 모델이 의도를 가려내고, 미리 짜 둔 갈래로 보내 붙잡을지 끊을지를 정했다. 경로를 사람이 다 그려 둔 방식이다.

4. 구체적으로 걸리는 두 자리

되살아나는 설계가 없으면 오래 도는 에이전트가 무너진다. 5분이나 15분 걸리는 에이전트가 중간에 깨졌을 때 처음부터 다시 돌리면, 앞 단계를 다시 밟느라 컴퓨트를 또 쓰고 그동안 쌓인 맥락까지 잃는다.

사람에게 뻔한 이름이 에이전트에게는 안 뻔하다. 백엔드를 만들어 본 사람에게 「항목 삭제」 같은 엔드포인트는 설명이 필요 없어 보인다. 그런데 에이전트는 코드도 못 보고 그 API를 만들며 쌓인 사정도 모른다. 함수 껍데기와 설명 몇 줄만 본다. 그래서 도구는 에이전트가 읽을 것을 전제로 다시 쓰여야 한다고 말한다.

5. 마무리로 남긴 여섯

발표가 닫으며 든 여섯

마지막이 이 발표의 태도를 드러낸다. 발표자는 소프트웨어가 쓰고 버리는 것이 되었고 같은 것을 여러 번 다시 만들게 될 것이라고 말한다.

6. 발표가 밝히지 않은 것

수치가 거의 없다. 열 번에 한 번이라는 말과 5분에서 15분이라는 시간이 나오지만, 둘 다 상황을 그리는 예이지 무엇을 잰 값이 아니다. 다섯 가지를 지켰을 때 무엇이 얼마나 나아지는지가 없다.

되살아나게 만드는 방법이 없다. 처음부터 다시 돌리면 안 된다는 지적까지는 또렷한데, 중간 상태를 어디에 어떻게 남겨 이어 붙이는지는 나오지 않는다.

에이전트가 읽을 도구를 어떻게 써야 하는지도 없다. 설명을 다시 쓰라는 말까지만 있고 무엇을 어떤 수준으로 적어야 하는지가 없다.

10분짜리 발표라 얕은 자리가 많다. 발표자도 코드 예제는 자기 블로그로 넘긴다.

1. 메시지 한 통이 지나는 길

코덱스 에이전트에는 프로토콜이 둘 있다. 앞쪽은 사용자가 UI에서 보낸 메시지가 *하니스까지 가는 길이고 이것을 앱 서버라고 부른다. 뒤쪽은 하니스와 추론 사이를 잇는 리스폰시스 API다.

둘 다 남이 갈아 끼울 수 있게 열어 뒀다고 한다. 앱 서버 프로토콜을 쓰면 자기 UI를 코덱스 하니스 위에 올릴 수 있고, 코덱스 앱 자체도 같은 앱 서버로 돈다. 발표자는 이 프로토콜로 코덱스를 다른 코딩 에이전트 안에 넣어 봤고 전날 발표에서는 게임 둠 안에 넣어 보였다고 밝힌다.

리스폰시스 API는 작년에 공개됐다. 챗 컴플리션 API를 에이전트 시대에 맞게 다시 짠 것으로 웹 검색이나 이미지 생성 같은 능력이 붙어 있다. 올라마·LM 스튜디오·엔비디아 등과 함께 열린 리스폰시스 스키마를 만들고 그것을 관리할 기구를 뒀다고 한다. 이 규격을 따르는 모델 제공자라면 코덱스 하니스에 꽂을 수 있다는 뜻이다.

하니스는 오픈소스이고 러스트로 쓰였다.

2. 컨텍스트를 조립할 때 무엇을 아끼나

하니스가 가장 먼저 하는 일이 컨텍스트 조립이고 여기서 세 가지를 본다.

첫째는 크기다. 토큰 예산을 헛되이 쓰지 않으려는 것도 있지만 이유가 하나 더 있다. 컨텍스트가 길수록 서로 어긋나는 정보가 들어갈 확률이 올라가고 그것이 모델을 헷갈리게 한다. 둘째는 유연성이다. 스킬이나 플러그인이나 MCP를 많이 깔든 적게 깔든 경험이 같아야 한다. 셋째는 성능과 비용이고 여기서는 캐시가 깨지지 않는 것이 중요하다.

컨텍스트 조각 중에는 예측되는 것과 안 되는 것이 있다. 모델 지시문은 구조가 정해져 있어 크기가 잘 안 변하고 캐시를 안 깬다. 반면 스킬이 몇 개인지, 도구 레지스트리가 얼마나 큰지는 예측이 안 된다. MCP를 깔수록 늘어나기 때문이다.

그래서 상한을 둘 걸었다.

컨텍스트가 부푸는 것을 막는 두 장치

지연 로딩은 코덱스만의 것이 아니라고 한다. GPT-5.4부터 리스폰시스 API에서 어떤 도구든 지연으로 표시할 수 있고, 내장 도구 검색을 쓰거나 직접 만든 검색을 붙여도 된다.

3. 에이전트가 하는 행동 셋

컨텍스트를 조립했다고 에이전트가 되지는 않는다. 행동을 해야 에이전트다.

세 갈래 행동과 그 장치

컴퓨터 조작의 변화가 눈에 띈다. 브라우저 조작이 그 예다. 코덱스는 턴을 넘어 살아 있는 노드 REPL 안에 플레이라이트 코드를 써서 크로미움을 움직인다. 한 페이지의 구조를 파악한 다음 스크립트를 짜서 나머지 페이지를 훑는 식이라 같은 일을 훨씬 빨리 끝낸다.

파일 시스템 쪽에는 훈련의 흔적이 남아 있다. GPT-5부터 모델이 어플라이 패치 도구에 익숙해지도록 훈련됐고, 파일을 찾을 때는 자연스럽게 립그렙을 쓰려 든다. 그래서 하니스가 립그렙을 같이 배포한다. 윈도우에서는 파워셸을 그대로 쓰도록 따로 훈련했다.

모든 파일 시스템 조작은 샌드박스를 지난다. 맥OS는 시트벨트, 리눅스는 버블랩을 쓴다. 윈도우는 마땅한 것이 없어 직접 만들어 같은 저장소에 오픈소스로 열어 뒀다고 한다.

4. 위험한 행동을 누가 판단하나

샌드박스에는 늘 따라오는 불만이 있다. 승인 피로다. 긴 작업일수록 승인 요청이 성가셔서 전체 접근을 켜 버리게 되고, 보안 담당은 그것을 싫어한다.

모델이 좋아져도 사고는 남는다고 발표자는 말한다. 높은 자율성을 프롬프트로 밀어붙이면 엉뚱하게 해석될 수 있다. 파일을 메일로 보내라고 했는데 첨부가 안 되니 파일 공유에 올려 버리거나, 이스케이프를 잘못해 데이터를 너무 많이 지우는 일이 그렇다.

그래서 오토 리뷰를 만들었다. 샌드박스가 막아선 행동이 올라오려 할 때 판단을 대신할 서브에이전트를 띄운다. 이 서브에이전트는 따로 돌고 읽기 권한만 가지며 다른 서브에이전트를 못 띄운다.

받는 것은 넷이다. 사용자 권한이 무엇인지, 위험을 어떻게 분류하는지, 어떻게 판단하기를 바라는지, 그리고 대화 기록과 실제로 일어나려는 도구 호출이다. 여기서 맥락이 판단을 정한다. 지우라고 시킨 파일이면 지워도 되고, 시키지 않은 `.git` 폴더면 이력을 통째로 날리는 일이라 건드리면 안 된다.

파일 시스템만의 이야기도 아니다. 인터넷이 되는지 보려고 구글을 부르는 것은 괜찮지만 파일을 올리는 것은 다를 수 있다.

발표자는 이 설명이 엄청난 단순화라고 스스로 밝히며 자세한 것은 따로 쓴 글로 넘긴다.

5. 병목이 추론에서 네트워크로 옮겨갔다

에이전트는 도구 호출을 많이 한다. 추론을 아무리 빠르게 해도 그것만으로는 안 된다는 것이 이 대목이다.

GPT 5.3 코덱스 스파크를 세레브라스에서 초당 1,000토큰으로 돌리자 그것이 드러났다. 도구 호출과 오가는 상호작용이 쌓이니 느린 자리가 추론이 아니라 네트워크였다.

그래서 웹소켓 모드를 넣었다. 리스폰시스 API가 서버 전송 이벤트와 HTTP 대신 끊기지 않는 웹소켓 연결을 쓴다. 네트워크 오버헤드를 아끼는 것에 더해 연결이 상태를 갖게 되므로 바뀐 것만 보내면 된다. 도구 호출이라면 그 결과만 보내고 전체 항목을 다시 보내지 않는다. 발표에서 든 예로는 아홉 개를 되보내던 자리에서 하나만 보낸다.

6. 끝났다고 누가 말하나

슬래시 골로 도는 루프의 구조는 단순하다. 목표에 닿을 때까지 하니스가 이어가는 프롬프트를 자동으로 밀어 넣고, 그 프롬프트 안에 사용자가 정한 목표가 들어간다. 모델이 목표 갱신 도구를 불러 다 됐다고 선언할 때까지 그것이 반복된다.

여기서 나오는 조언이 실용적이다. 목표에 긴 글을 쓰면 안 된다. 끝났는지 판정할 수 있어야 루프가 멈추므로 구체적이고 확인 가능한 문장으로 써야 한다.

시간이 길어지면 컨텍스트가 문제가 된다. 작년 말에 넣은 자동 컴팩션이 그것을 맡는다. 서버 쪽에서 발동하고, 모델이 그렇게 훈련돼 있어 성능이 유지된다고 한다. 이전 컨텍스트 창을 새 창으로 바꾸면서 필요한 정보를 담은 항목 하나를 그 안에 넣는 방식이다.

7. 발표가 밝히지 않은 것

숫자가 거의 없다. 웹소켓으로 얼마나 빨라졌는지가 대표적이다. 상당히 빨라졌다는 말과 큰 영향이 있다는 말만 나오고 측정값은 없다. 시연하려던 데모 서버가 발표 중에 죽어 미리 녹화한 화면으로 대신했다.

오토 리뷰가 얼마나 맞히는지도 없다. 자동으로 승인해서는 안 될 것을 승인한 비율이나 반대로 사람에게 괜히 올린 비율이 이 장치의 값어치를 정하는데, 발표자 스스로 엄청난 단순화라고 밝히며 글로 넘긴다.

스킬 2퍼센트 상한에서 무엇을 먼저 줄이는지도 안 나온다. 넘치면 설명을 조금씩 줄인다고만 한다. 어느 스킬 설명이 먼저 깎이느냐가 어떤 스킬이 안 불리느냐를 정하는데 그 순서가 없다.

마지막으로 이 발표는 오픈AI 제품 안내이기도 하다. 앱 서버·리스폰시스 API·코덱스를 쓰라는 이야기가 뼈대에 섞여 있다. 다만 하니스가 오픈소스라 말한 것을 코드로 확인할 수 있다는 점은 다른 제품 발표와 다르다.

발표자는 이것이 현재 상태일 뿐이고 새 모델이 나올 때마다 API도 하니스 동작도 자주 바뀐다고 먼저 밝힌다. 날짜를 붙여 읽어야 하는 발표다.

1. 무엇을 주장하는 발표인가

클라우드플레어에서 에이전트 SDK를 만드는 사람이 발표한다. 주장은 한 줄이다. 코드가 시스템과 주고받는 방식이 되어야 한다는 것이다.

출발점은 규모다. 클라우드플레어의 API 표면은 엔드포인트가 약 2,600개다. 이것을 도구로 다 노출하면 *툴 콜링을 시작하기도 전에 컨텍스트가 터진다.

2. 왕복을 없앤다

보통은 모델이 도구를 하나 부르고, JSON으로 결과를 받고, 다시 말하고, 또 부른다. 발표자는 이 방식이면 그 API 호출들을 하는 데 왕복이 약 여덟 번 든다고 말한다.

대신 모델에게 코드를 쓰게 한다. 주로 자바스크립트다. 그 코드를 API 바로 옆에서 즉시 돌리면 한 번에 끝난다.

3. 도구를 둘로 줄인다

동료 한 사람이 이것을 처음 적용했다고 한다. 그가 낸 방법은 도구를 딱 두 개만 노출하는 것이다.

노출한 도구 둘

둘 다 입력이 코드 문자열이라는 점이 같다.

여기서 이 발표의 수치가 나온다. 2,600개를 다 노출하면 첫 호출에만 약 120만 토큰이 들었다. 두 도구 방식으로 바꾸자 1,000 토큰으로 줄었다. 발표자는 약 99.9% 줄었다고 말한다.

4. 샌드박스는 아무것도 못 하는 데서 시작한다

모델이 쓴 코드를 돌린다는 말은 곧 안전 문제다. 여기서 막는 순서가 거꾸로다.

*샌드박스는 아무 능력도 없이 시작한다. 코드를 돌리는 것 말고는 아무것도 못 한다. 요청을 보낼 수도 없고 열린 API도 없다. 거기에 필요한 능력을 하나씩 명시적으로 준다.

바깥으로 나가는 요청과 네트워크 연결도 같은 자리에서 통제한다고 말한다.

5. 상태를 그대로 넘기면 생기는 일

발표에서 가장 눈에 띄는 장면은 동료가 만든 틱택토 데모다.

시스템의 상태를 모델에게 통째로 넘긴다. 여기서 상태는 캔버스에 그은 획의 배열이다. 사람이 X를 그리자 모델이 그 상태를 자기 컨텍스트로 읽어 들이고, 그것이 무슨 판인지 알아보고, 한가운데에 원을 그려 넣었다.

무엇을 하라고 시킨 것이 아니라 상태를 넘겼더니 나온 행동이라는 것이 이 대목의 요점이다.

6. 라이브 데모가 흔들린 대목

발표자는 라이브 데모가 있다며 무대에서는 데모가 잘 안 된다고 미리 말한다. 그리고 실제로 그렇게 됐다.

돌리자 자바스크립트 오류가 이어졌고, 발표자는 성공할지 지켜보자고 말한다. 모델이 페이지를 나눠 가며 훑으려 드는 것 같다고 덧붙인다. 무대에 오르기 전 열 번 시험했다는 말도 한다.

이 장면이 앞의 주장과 맞닿는다. 모델에게 코드를 쓰게 하는 방식은 그 코드가 틀렸을 때 어떻게 되는지가 그대로 드러난다.

7. 발표가 밝히지 않은 것

99.9%는 특정 API 표면 하나를 놓고 든 값이다. 엔드포인트가 2,600개인 자사 API에서 잰 것이라, 표면이 작거나 성격이 다른 API에서도 같은 폭으로 줄어드는지는 나오지 않는다.

왕복 여덟 번도 그 예의 값이다. 무엇을 기준으로 센 여덟인지, 다른 일에서는 몇 번인지가 없다.

모델이 쓴 코드가 틀릴 확률이 없다. 라이브 데모에서 바로 그 일이 벌어졌는데도, 얼마나 자주 그러는지와 틀렸을 때 무엇으로 되돌리는지가 나오지 않는다. 이 방식의 급소가 거기다.

언제까지 유효한 이야기인지 밝히지 않는다.

1. 무엇을 파는 발표인가

클라우드플레어에서 개발자 플랫폼을 맡은 제품 부사장이 발표한다. *워커스와 *두러블 오브젝트를 다루는 자리다. 발표 뒤쪽은 자사 에이전트 SDK와 그 위에서 도는 것들을 보이는 데 쓰인다.

먼저 시장 수치가 몇 개 나온다. 지식노동자의 75%가 넘게 일에 AI를 붙여 쓰고, 개발자의 76%가 넘게 개발 과정에 AI를 쓴다고 한다. 에이전트를 들인 회사 가운데 매출이 20% 늘었다는 곳과 고객지원 응답이 90% 빨라졌다는 곳이 있고, 대체로 50~75%의 시간을 아꼈다는 이야기가 나온다.

이 값들은 발표자가 잰 것이 아니다. 인용한 보고서의 값이고 출처를 따로 대지 않는다. 발표자 스스로도 보고서를 뽑은 시점과 지금 사이에 숫자가 더 컸을 것이라고 덧붙인다.

2. 에이전트를 넷으로 자르면

이 발표의 쓸모는 이 자름에 있다. 사람과 만나는 클라이언트가 있고, 다음에 무엇을 할지 정하는 AI가 있고, 그 결정을 실제로 집행하는 워크플로가 있고, 바깥에 손을 대는 툴이 있다.

셋째 자리를 집행부라고 부르는 것이 이 틀의 핵심이다. 정하는 곳과 실행하는 곳을 갈라 놓았다. 무엇이 잘 안 된다고 할 때 넷 중 어디인지부터 말하게 만드는 틀이다.

예로 든 고객관리 에이전트는 이 넷이 길게 늘어선 모양이다. 음성이나 채팅으로 들어와 글로 바뀌고, 캐시와 평가를 맡는 게이트웨이를 지나 모델이 생각하고, 워크플로가 행동을 좇고, 툴이 브라우저와 API와 사내 서비스와 *벡터 데이터베이스에 손을 댄다. 필요하면 그 사이에 사람이 낀다.

3. 사람 승인이 끼어드는 자리

발표에서 가장 구체적인 대목이 신용카드 발급 승인이다. 사용자가 채팅으로 카드를 요청하면 발급 도구를 사람 입력이 필요한 것으로 감싸 두고, 승인 알림을 보낸 뒤 발급을 멈춘다.

어려운 자리는 그 다음이다. 승인이 돌아올 때까지 멈춘 도구 호출이 살아 있어야 하고, 돌아온 승인이 원래 그 에이전트를 찾아가야 한다. 발표자는 이 라우팅을 두러블 오브젝트가 맡는다고 설명한다. 그 사이에 같은 승인이 두 번 오거나 카드가 두 번 나가지 않도록 상태를 확인하는 검사도 든다.

전통적으로는 데이터베이스를 따로 세우고 연결을 관리하고 확장을 감당해야 했다는 것이 여기서 견주는 기준이다. 자사 제품이 그 일을 대신한다는 이야기로 이어진다.

4. MCP를 이루는 네 개념, 그리고 하나

*MCP는 클라이언트와 서버가 주고받는 전통적인 구조를 따르고, 서버 하나에 클라이언트가 여럿 붙을 수 있다.

MCP 서버를 이루는 네 개념

넷째 줄이 이 발표에서 가장 정직한 대목이다. 발표자는 이 발표를 준비하면서 샘플링을 프로덕션에서 쓰는 곳을 본 적이 없다는 결론에 이르렀다고 말한다. 규격에 적혔다고 실제로 쓰이는 것은 아니라는 이야기다.

직접 MCP 서버를 만들 때 까다로운 자리로는 셋을 든다. 전송 프로토콜, OAuth, 그리고 메모리다.

5. 발표가 밝히지 않은 것

인용한 수치의 출처가 없다. 매출 20%와 응답 90%와 시간 50~75%가 어느 조사에서 몇 곳을 대상으로 나온 값인지 나오지 않는다. 발표자가 잰 값이 아니라는 점과 함께 감안해야 한다.

샘플링을 왜 아무도 안 쓰는지는 안 나온다. 못 봤다는 관찰까지만 있고 그 이유가 규격 탓인지 도구 탓인지 필요가 없어서인지가 없다. 관찰 자체가 값진 만큼 이 대목이 비어 있는 것이 아쉽다.

멈춘 도구 호출을 얼마나 오래 살려 두는지도 없다. 승인이 하루 뒤에 와도 되는지, 그동안 무엇이 얼마나 쌓이는지, 승인이 영영 안 오면 어떻게 되는지가 나오지 않는다. 사람이 끼는 워크플로에서 실제로 문제가 되는 자리가 거기다.

발표자가 유효기간을 스스로 짚는 대목은 있다. 인용한 보고서 숫자가 이미 낡았을 것이라고 말한다.

1. 얼마나 긴 일을 맡기게 됐나

앤스로픽에서 비동기로 도는 에이전트를 다루는 사람이 발표한다. 자막에 자기 이름을 대는 대목은 없다.

먼저 맡길 수 있는 일의 길이가 어떻게 늘었는지 짚는다.

맡기는 일의 길이와 그에 맞춰 나온 것

일이 길어질수록 감싸는 장치가 두꺼워진다는 것이 이 표의 이야기다.

2. 머리와 손을 나눈다

오래 도는 일을 버티게 하는 자름이 여기 있다. 생각하는 자리인 *하네스는 상태를 안 들고 있다. 무슨 일이 있었는지는 기록이 맡는다. 그 기록은 덧붙이기만 하는 방식이다.

실제로 돌리는 일은 *컨테이너가 한다. 머리가 죽었다 살아나도 기록을 다시 읽어 이어 갈 수 있는 구조다.

안전 쪽도 한 줄 짚는다. 자격 증명은 손이 든 상자에 넣지 않는다. 따로 둔 금고에 두고 필요할 때만 꺼낸다.

3. 검증을 딴 자리에 세운다

만드는 에이전트와 검사하는 에이전트를 다른 맥락으로 갈라 둔다. 검사하는 쪽은 자기 목표와 *루브릭을 따로 들고, 만든 쪽의 결과를 채점한다.

통과할 때까지 이 왕복이 이어진다. 만든 사람이 자기 것을 검사하지 않게 한 것이 요점이다.

4. 기억을 쓰는 두 갈래

이 발표에서 가장 구체적인 실험이 여기 나온다.

기억을 쓰는 방식이 둘이다. 하나는 일하는 중에 그때그때 파일에 적는 것이다. 다른 하나는 일이 끝난 뒤 따로 돌면서 쌓인 것을 훑어 잘못 적힌 것을 고치는 것이다. 발표자는 뒤쪽을 사람의 잠에 빗댄다.

클로드가 포켓몬을 하게 두고 셋을 견줬다.

기억을 어떻게 쓰느냐로 갈린 결과

다섯 번 돌려 다섯 번 다 가운데 줄의 일이 벌어졌다고 한다. 적어 둔 기억에는 틀린 것도 함께 남는다는 이야기다.

5. 한 사람의 도구에서 조직의 도구로

마지막 갈래는 자리 문제다. 지금까지 에이전트는 대체로 혼자 쓰는 것이었다. 각자 자기 맥락에 맞춰 다듬은 장치를 자기 컴퓨터에서 굴렸다.

그것을 조직이 함께 쓰는 쪽으로 옮긴다. 조직 전체가 접근하고, 그 장치가 자기 신원과 자격 증명을 갖고, 조직 수준의 맥락에 닿는 형태다.

6. 발표가 밝히지 않은 것

12시간이라는 길이가 무엇을 잰 값인지 좁혀지지 않는다. 바깥 측정 기준을 따랐다고 말하지만, 어떤 일을 맡겼을 때의 값인지와 그중 몇 번이나 끝까지 갔는지가 없다.

포켓몬 실험이 다른 일에도 통하는지 없다. 다섯 번 중 다섯 번이라는 값은 또렷한데, 게임 하나에서 본 것이 코드나 문서 작업에서도 같은 모양으로 나오는지는 나오지 않는다.

나중에 훑어 고치는 과정의 값이 없다. 얼마나 자주 돌려야 하는지, 그 과정 자체가 잘못 고칠 확률은 얼마인지가 없다. 기억을 고치는 장치가 기억을 망칠 수도 있는 자리다.

발표자가 모른다고 말하는 대목도 있다. 앞선 모델이 아닌 것들이 왜 이 영역에 못 오는지 확실히 모르겠다고 한다. 자기가 만든 형편없는 봇이 많다는 말도 한다.

1. 무엇을 말하는 발표인가

앤스로픽에서 클로드 개발자 플랫폼 팀을 이끄는 사람이 발표한다. 에이전트를 만들 수 있게 플랫폼을 어떻게 넓히고 있는지가 주제다.

플랫폼이 돕는다는 것을 셋으로 갈라 놓고, 발표를 열 때와 닫을 때 같은 순서로 두 번 짚는다.

플랫폼이 돕는다는 세 갈래

2. 컨텍스트 창을 다루는 손 셋

둘째 갈래가 이 발표에서 가장 촘촘하다. *컨텍스트 창을 다루는 도구를 셋으로 나눠 놓았다.

*MCP는 창 밖에 있는 것에 닿게 해 준다. 깃허브 같은 바깥 시스템과 주고받아 창 안에 없던 자료와 도구를 끌어온다.

메모리 도구는 반대다. 창 바깥에 컨텍스트를 두었다가 정말 필요할 때만 도로 불러온다.

컨텍스트 편집은 비우는 손이다. 지금 쓸모없는 옛 도구 결과처럼 창에 있을 이유가 없는 것을 지운다.

클로드 코드가 그 예로 나온다. 도구를 수백 번 부르고 그때 읽은 파일이 창을 차지하므로, 그것들을 창에서 걷어낸다.

여기서 유일한 수치가 나온다. 메모리 도구와 컨텍스트 편집을 함께 썼더니 벤치마크 대비 성능이 39% 올랐다고 한다. 다만 자기들 사내 평가에서 잰 값이다.

창을 키우는 쪽도 함께 간다. 일부 모델은 100만 토큰짜리 창을 쓸 수 있다.

3. MCP와 스킬은 다른 것을 준다

발표자가 둘을 또렷하게 구분한다. MCP는 도구와 자료에 닿게 해 주고, *스킬은 그것을 쓸 줄 알게 해 준다.

도구에 닿아도 어떻게 쓰는지 모르면 소용이 없다는 뜻이다. 스킬 자체는 다음 날 같은 팀의 다른 발표로 넘긴다.

4. 컴퓨터를 주자는 말의 걸림돌

셋째 갈래가 가장 야심 차고 가장 덜 여물었다. 클로드에게 컴퓨터를 주고 알아서 하게 두자는 것이다.

발표자는 그 앞을 막는 것을 스스로 든다. 여러 일을 어떤 차례로 엮을지, 안전한 환경을 어떻게 마련할지, *샌드박싱을 어떻게 할지가 가장 큰 문제라고 말한다.

앞으로 할 일도 셋으로 정리한다. API를 계속 넓혀 모델이 나아지는 만큼 따라가게 하고, 메모리와 컨텍스트 도구를 더 세게 만들고, 에이전트 인프라에 계속 힘을 쏟겠다는 것이다.

5. 발표가 밝히지 않은 것

39%가 무엇을 잰 값인지 좁혀지지 않는다. 어느 벤치마크인지, 무엇을 기준선으로 삼았는지, 몇 번 돌린 값인지가 없다. 사내 평가라고 밝히기는 하지만 바깥에서 확인할 길이 없는 숫자다.

세 손을 함께 썼을 때의 값도 없다. 39%는 메모리와 컨텍스트 편집 둘을 합쳤을 때의 값이고, MCP까지 셋을 함께 쓰면 어떻게 되는지는 나오지 않는다.

컨텍스트 편집이 무엇을 지울지 어떻게 고르는지 없다. 지금 안 쓰는 것을 지운다고 하는데, 나중에 필요해질 것을 지웠을 때 어떻게 되는지가 이 도구의 급소다.

언제까지 유효한 이야기인지 밝히지 않는다. 플랫폼이 계속 바뀐다는 것이 발표의 내용인데 그 점을 짚는 대목이 없다.

1. 왜 에이전트를 그만 짓기로 했나

앤트로픽에서 *스킬을 만든 두 사람이 발표한다. 에이전트를 만드는 일을 멈추고 스킬을 만들기 시작한 이유를 설득하는 자리다.

출발점은 모델의 한계를 인정하는 데 있다. 모델은 쓰는 사람의 전문성을 잘 흡수하지 못하고 시간이 지나도 배우지 않는다. 그래서 도메인마다 새 에이전트를 짓는 대신 다른 길을 골랐다.

발표자들이 든 비유가 세금 신고다. 세금 신고를 IQ 300짜리 수학 천재에게 맡길 것인지, 경험 많은 세무 전문가에게 맡길 것인지 묻고 매번 후자를 고르겠다고 답한다. 2025년 세법을 첫 원리부터 알아내 주기를 바라는 것이 아니라, 도메인을 아는 사람의 일관된 실행이 필요하다는 것이다.

목표도 그 자리에 놓인다. 함께 일한 지 서른 날째의 클로드가 첫날의 클로드보다 훨씬 나아야 한다고 말한다.

2. 컴퓨터에 빗대면

발표를 닫는 비유가 이 그림이다.

컴퓨팅 역사에 대 본 자리

같은 에이전트 하나에 *MCP 서버를 붙이고 그 위에 수백에서 수천 개 스킬 라이브러리를 얹을 수 있다고 설명한다.

3. 스킬이 열리는 두 걸음

수천 개를 얹는다는 말이 성립하려면 장치가 하나 필요하다. 그것이 *점진적 공개다.

평소에는 스킬의 이름과 설명만 모델에 보인다. 그런 스킬이 있다는 것만 알리는 정도다. 에이전트가 그 스킬을 쓰겠다고 정하면 그때 본문을 읽어 들인다.

목록 전체를 컨텍스트에 넣지 않는다는 것이 요점이다.

4. 스킬이 실제로 하는 일

발표가 든 재무 보고서 예를 보면 스킬이 무엇인지 감이 잡힌다. 모델이 API를 불러 자료를 끌어오고, 파일로 갈무리하고, 파이썬으로 분석하고, 결과를 파일 하나로 합친다.

네 걸음이 모두 코드로 간다. 스킬이 별난 장치라기보다 모델이 코드로 할 일을 적어 둔 것에 가깝다.

5. 다섯 주 만에 벌어진 것

발표는 이 설계가 낳은 것을 몇 가지 든다.

스킬을 내놓은 지 다섯 주 만에 수천 개 스킬로 이루어진 생태계가 빠르게 자랐다고 한다. 같은 시기에 금융 서비스와 생명과학 분야에 새 서비스를 냈고, 각각에 MCP 서버 묶음과 스킬 묶음이 딸려 있었다.

쓰는 쪽도 넓다. 수천에서 수만 명 개발자를 지원하는 생산성 팀들이 코드 스타일 모범 사례를 스킬로 가르치고 있고, 금융과 채용과 회계와 법무처럼 기술직이 아닌 사람들도 스킬을 만들고 있다고 말한다.

6. 발표가 밝히지 않은 것

수치가 하나도 없다. 스킬을 붙였을 때 무엇이 얼마나 나아지는지가 나오지 않는다. 정확도도 지연도 비용도 없다. 다섯 주와 수천 개는 채택 속도이지 잘 되는지를 재는 값이 아니다.

서른 날째가 첫날보다 낫다는 것은 목표다. 그렇게 됐다는 측정이 아니다. 발표에서 유일하게 견줄 만한 문장인데 실제로 잰 값이 뒤따르지 않는다.

스킬이 수천 개일 때 서로 부딪히면 어떻게 되는지 없다. 이름과 설명만 보고 고르는 방식이라 비슷한 스킬이 여럿이면 잘못 고를 여지가 생기는데, 그 자리를 다루지 않는다. 목록이 길어질수록 문제가 되는 자리다.

언제까지 유효한 이야기인지도 밝히지 않는다. 다섯 주 된 것을 두고 하는 이야기라 특히 그렇다.

발표자들이 소속을 자기소개에서 밝히지 않는다는 점도 적어 둔다. 회사 이름은 발표 뒤쪽에서 자기들을 가리키며 한 번 나온다.

1. 모델은 설계된 것이 아니라 길러진 것이다

앤스로픽에서 클로드 코드를 만든다고 밝힌 사람이 발표한다.

바탕에 깔린 말이 이것이다. 모델은 설계된 것이 아니라 길러진 것이고 데이터와 되먹임과 계산을 줘서 기른다. 그러니 *하네스와 프롬프트를 어떻게 짜느냐는 그 모델을 우리가 얼마나 이해했느냐의 함수가 된다.

들고 온 예가 포켓몬이다. 이름이 특정 두 글자로 끝나는 것을 세라는 물음인데, 보통 대화 모델은 못 푼다. 클로드 코드는 목록을 받아 와 걸러 내는 코드를 짜서 답한다. 발표는 이것을 *능력 과잉이라 부른다 — 모델 안에 이미 있었는데 꺼낼 길이 없던 것이다.

처음에는 맥락을 통째로 붙여 넣는 쪽을 그렸다고 말한다. 실제로 길이 난 것은 반대쪽이었다. 팔을 쥐여 주니 스스로 맥락을 찾아 쌓았다.

2. 시스템 프롬프트가 다시 작아진다

이 발표에서 가장 셀 만한 수가 여기 있다. 클로드 코드 시스템 프롬프트의 80%를 최근 걷어냈다.

프롬프트 모범이 뒤집힌 자취

이유가 뒤집힌 자리가 눈에 띈다. 예시를 붙이는 것이 도움이 아니라 가두는 일이 됐다는 쪽이다. 모델이 우리가 주는 예시보다 더 멀리 상상하니 제약이 아니라 맥락을 주려 한다고 말한다.

같은 이야기를 자기가 만든 도구로 보인다. 되묻기 도구를 클로드 코드에 붙였을 때, 한 판 아래 모델은 부르는 것조차 힘겨워 도구를 계속 손봐야 했다. 다음 판에서는 명세를 두고 마흔 가지를 되묻게 하니 인터뷰하듯 굴었다. 지금 판에서는 물음을 박아 넣은 리포트를 통째로 짠다.

내놓는 형식도 같이 옮겨 갔다고 말한다. 마크다운에서 계획 모드로, 이제는 깊이 들어간 리포트다.

이 일이 물리학보다 생물학에 가깝다고 말한다. 매우 경험적이고 유기적이라는 뜻이다.

3. 지도와 영토

발표의 가운데 개념이다. 머릿속 계획과 프롬프트와 명세가 지도이고, 실제 코드베이스와 현실의 제약이 영토다. 영토에서 지도에 없는 것을 만나면 그것이 「모르는 것」이다.

새 모델을 두고 처음으로 내 모르는 것을 미리 찾아 둬야겠다고 느꼈다고 말한다. 한 번에 훑는 넓이가 워낙 커서 그대로 두면 그런 자리를 잔뜩 만난다는 이유다.

발표가 나누는 네 칸

4. 모르는 것을 찾는 여섯 가지

발표가 든 순서 그대로

넷째가 눈에 띈다. 명세를 말로 적는 대신 원하는 결과를 나타내는 코드를 통째로 던지는 쪽이다. 마지막도 방향이 뒤집혀 있다 — 모델을 검사하는 것이 아니라 모델이 나를 검사하게 한다. PR을 올리기 전에 내가 이 일을 설명할 수 있는지 확인하려는 것이다.

5. 얻은 것과 잃은 것

발표의 다른 절반은 회고다.

새 모델을 처음 썼을 때 크게 얻은 느낌과 잃은 느낌을 함께 느꼈다고 말한다. 몇 주 걸렸을 일이 몇 시간에 끝났다.

동시에 손으로 코드를 짜는 것을 정말 좋아했다고 말한다. 코드베이스를 머릿속에 놓고 돌려 보는 느낌을 좋아했다는 것이다. 그러면서도 밤늦게까지 실패 속을 헤엄쳤다는 기억을 함께 꺼낸다. 서른 명 남짓한 회사를 꾸리던 시절에는 코드가 어려운 탓에 늘 무엇을 버릴지 골라야 했다고 한다.

마지막 절에서 그 「골라야 한다」를 뒤집는다. 앤스로픽 문화 중 가장 좋아하는 것이 주고받기는 실재하지 않는다는 믿음이라고 말한다. 전 직장에서는 우선순위 목록을 적으며 합리적으로 굴었는데, 앞으로는 훨씬 덜 합리적이 되겠다고 말한다. 좋고 빠르고 싼 것 중 이제는 셋 다 고른다는 것이다.

이 발표 자료를 전날 밤 네 시간 만에 새 모델로 만들었다고 밝힌다.

만들기는 쉬워졌지만 값을 만드는 일은 여전히 어렵다는 말로 닫는다.

6. 발표가 밝히지 않은 것

80%가 무엇의 80%인지 없다. 글자 수인지 줄 수인지, 걷어낸 뒤 무엇이 좋아졌는지가 나오지 않는다. 걷어내고 나빠진 것이 있었는지도 없다.

성능 수치가 하나도 없다. 벤치마크 점수를 한 번 들지만 그것은 우리가 그런 목표로 아침을 열지는 않는다는 예로 든 가상의 수다. 실제로 잰 값이 아니다.

여섯 방법 중 무엇이 얼마나 듣는지 없다. 여섯을 나란히 놓고 견준 자리가 없고, 하나를 뺐을 때 무엇이 나빠지는지도 없다.

네 시간 자료도 견줄 대상이 없다. 예전이라면 얼마나 걸렸을지가 없다.

앞으로도 계속 바뀔 것이라고 발표자가 직접 말한다. 프롬프트를 어떻게 짜느냐는 이야기의 유효기간을 스스로 짧게 잡아 둔 셈이다.

1. 무엇을 다루는 자리인가

코덱스를 만드는 쪽에서 두 사람이 나오고, 뒤이어 게스트 한 사람이 무대에 오른다. 앞의 둘은 이름만 말하고 소속과 직무는 밝히지 않는다. 세 번째 사람은 자기 이름을 말하지 않고 사회자가 불러 소개한다.

라이브 시연은 없다. 이번에는 좀 다르게 해 보고 싶었다고 밝힌다.

2. 모델 능력이 지나온 다섯 걸음

코드를 다루는 모델이 지나온 자리

새 모델 값도 나온다. GPT 5.5 수준 지능을 절반 값에 낸다고 하고, 입력은 100만 토큰당 1달러, 출력은 6달러라고 한다. 세레브라스에서 돌린 것은 초당 750토큰을 낸다.

다만 이 대목의 모델 이름이 자막 안에서 뒤섞여 있다. 같은 5.6 계열을 두고 서로 다른 이름이 여럿 나와서 어느 값이 어느 판의 것인지 이 글에서는 구분하지 않았다.

3. 코덱스를 어디까지 열었나

아래에서 위로 연 층

맨 위를 연 이유를 밝힌다. 혁신이 자기들 아이디어에 막히지 않게 하려는 것이라고 한다.

4. 짝짓기가 관리로 옮겨 간다

게스트가 자기 일하는 방식이 몇 달 새 어떻게 바뀌었는지 짚는다.

처음에는 에이전트 하나와 나란히 앉아 일했다. 그다음에는 터미널을 열 개 띄워 놓고 직속 부하 열 명을 다루듯 했다. 지금은 오래 도는 매니저 하나와 주로 이야기하고, 그 매니저가 팀에 다시 나눈다.

터미널 열 개를 굴리던 방식은 더 못 늘린다고 스스로 밝힌다.

이것을 가능하게 한 것으로 셋을 든다. 서버 쪽에서 도는 컴팩션이 오래 걸리는 일을 믿을 만하게 만들었고, 조율이 한 갈래에서 여러 갈래를 만들고 몰아갈 수 있게 했고, 자동화가 무슨 일이 생겼을 때 같은 매니저를 깨울 수 있게 했다. 지속되는 맥락과 위임과 방아쇠, 그 셋이 고리를 이룬다는 것이다.

이슈 하나가 처리되는 순서도 나온다. 매니저가 깨어나 이슈를 프로젝트의 목표에 대 보고 맞을지 판단한다. 맞으면 일꾼을 만들고, 일꾼이 조사하고 고치고 시험을 돌린다. 다른 에이전트가 결과를 검토한다. 사람이 필요할 때 매니저가 변경안과 원래 이슈와 필요하면 영상까지 들고 온다. 사람은 한 번 보고 승인하며, 검사를 통과하면 들어간다.

5. 무엇이 발목을 잡나

이 발표에서 가장 값나가는 대목이다. 지난해에는 토큰이 모자랐고, 그다음에는 컴퓨트가 걸렸고, 지금은 주의력이 걸린다고 말한다.

앞의 둘과 셋째가 다르다. 토큰도 컴퓨트도 더 사면 되는데 주의력은 더 살 수 없다.

6. 발표가 밝히지 않은 것과 어긋난 대목

모델 이름이 자막 안에서 갈린다. 같은 5.6 계열을 두고 서로 다른 이름 여럿이 섞여 나온다. 값과 속도는 나오지만 어느 이름의 값인지는 이 자막만으로 가릴 수 없다.

매니저 방식이 얼마나 나은지 잰 값이 없다. 터미널 열 개보다 낫다는 것이 이야기의 뼈대인데, 무엇이 얼마나 빨라졌는지도 얼마나 덜 틀리는지도 나오지 않는다.

주의력이 한계라는 말을 받치는 측정도 없다. 한 사람이 몇 개까지 지켜볼 수 있는지, 어디서부터 놓치기 시작하는지가 없다.

발표자들이 스스로 밝히는 것 둘은 남길 만하다. 열 개를 굴리던 방식은 더 늘릴 수 없다고 말하고, 이 문제를 아직 못 풀었다고 말한다. 모델이 그것을 감싸는 장치와 조직보다 빠르게 나아가고 있다는 것이다.

1. 어느 규모의 이야기인가

AWS에서 클라우드 규모로 에이전트를 만드는 이야기를 한다. 먼저 규모를 깔아 둔다.

발표가 든 규모

알렉사 대목은 미리 만든 영상으로 보여 준다.

2. 방법을 정하지 않는 설계

아마존 Q 디벨로퍼의 CLI 에이전트를 3주 만에 만들어 내보냈다고 한다. 발표자는 청중에게 얼마나 걸렸을지 손을 들어 보게 한 뒤 이 숫자를 밝힌다.

그 속도를 내려고 만드는 방식을 근본부터 다시 생각했다는 것이 이 발표의 주장이다. 요즘 모델이 판단하고 계획하고 행동하는 데 훨씬 나아졌으니 그 힘을 쓰자는 것이다. 개발자는 에이전트가 무엇을 할지에 집중하고 어떻게 할지는 일러 주지 않는다.

이것을 코드로 편 것이 오픈소스 파이썬 SDK 스트랜즈 에이전트다. 모델과 도구 둘을 잇는 것이 전부라고 설명하며 DNA의 두 가닥에 빗댄다. 미리 만들어 둔 도구가 20개 넘게 딸려 오고, *MCP를 안에 넣어 두었고, *A2A 지원도 곧 붙는다고 한다. 모델은 클로드 3.7 소네트를 쓰는 화면을 보이고 다른 제공자도 붙일 수 있다고 말한다.

3. 도구가 6,000개일 때

이 발표에서 가장 옮겨 쓸 만한 대목이다. 사내 에이전트 하나가 도구를 6,000개 넘게 다루는데, 발표자는 그 수를 한 컨텍스트 창에 넣고 모델 하나에게 고르라고 하기는 어렵다고 그대로 인정한다.

그래서 목록을 넣는 대신 찾아오게 만든다. 도구 설명을 *지식 베이스에 넣어 두고, 의미로 검색하는 도구를 하나 두고, 지금 일에 맞는 것만 꺼내 컨텍스트에 넣는다. 모델은 그 안에서 고른다.

4. MCP를 바깥으로 내보내기

MCP는 원래 한 대 안에서 클라이언트와 도구를 잇는 것으로 시작했다. *표준 입출력으로 붙는 방식이다.

이것을 바깥으로 내보내는 순서를 보인다. *람다 함수로 올리고, 배포하면 주소가 나오고, 클라이언트가 토큰을 들고 붙어 도구를 부른다.

바깥으로 나가면서 붙는 것이 있다. 누가 부르는지 확인할 자리가 필요하다. 인가자와 사용자 풀과 세션을 담는 표가 함께 들어간다고 설명한다.

5. 발표가 밝히지 않은 것

성능을 잰 값이 하나도 없다. 지연도 비용도 정확도도 나오지 않는다. 6억 대와 6,000개와 3주는 규모와 기간이지 잘 돌아간다는 증거가 아니다.

3주가 빠른지 판단할 기준이 없다. 청중에게 손을 들어 보게 한 것은 추측을 모은 것이지 견줄 대상이 아니다. 같은 것을 예전 방식으로 만들면 얼마나 걸리는지가 안 나온다.

도구 검색이 얼마나 맞는지가 없다. 6,000개 중에서 관련된 것만 꺼내 온다는 설계인데, 맞는 도구를 못 찾으면 어떻게 되는지와 검색이 몇 퍼센트나 맞히는지가 나오지 않는다. 이 방식의 급소가 바로 거기다.

언제까지 유효한 이야기인지도 밝히지 않는다.

발표는 자사 오픈소스 블로그 시리즈로 더 보라며 QR 코드로 넘기고 끝난다.

1. 무엇을 겪은 이야기인가

깃허브에서 *MCP 서버 개발을 이끄는 사람이 발표한다. 원격 서버를 만들고 키우며 부딪힌 것과 그것을 어떻게 넘겼는지가 주제다.

시작은 도구를 너무 많이 낸 것이었다. 당시 100개가 넘는 도구를 골랐고 그것이 너무 많았다고 스스로 말한다.

2. 컨텍스트를 줄인 세 걸음

첫 걸음은 도구를 흔한 쓰임에 맞춰 깎은 것이다. 이것으로 첫 적재가 49% 줄었다.

둘째는 묶는 것이다. 만들고 읽고 고치고 지우는 *CRUD 도구를 하나로 묶어 더 줄였다. 기본 설정으로 쓰면 도구가 약 40개가 된다.

셋째가 앞의 둘과 결이 다르다. 도구 목록이 아니라 응답이 컨텍스트를 먹고 있었다. 목록 조회 도구 하나에서 나오는 것을 필요한 것만 남기자 출력 토큰이 75% 넘게 줄었다.

3. 정교한 해법을 만들어도 다들 기본값만 쓴다

발표에서 가장 값나가는 실패담이 이 대목이다.

도구가 많아 에이전트가 헷갈리는 것을 풀려고 도구 묶음이나 상황에 따라 고르는 방식 같은 장치를 만들어 뒀다. 그런데 정작 쓰는 사람들은 기본 설정만 썼다.

읽기 전용 모드도 같은 자리에 있다. 사용자의 약 17%가 쓰는데, 그 모드를 화면에 내주는 클라이언트가 없다고 말한다. 만들어 둔 것과 실제로 닿는 것 사이에 틈이 있다는 이야기다.

그래서 기본값을 잘 고르는 일이 정교한 선택지를 만드는 일보다 앞선다.

4. 권한이 모자랄 때

권한을 다루는 방식도 같은 결이다. 에이전트가 도구를 부르는데 *스코프가 모자라면 거기서 실패로 끝내지 않는다.

모자란다는 신호를 돌려주고, 사용자에게 그 권한을 열어도 되는지 그 자리에서 묻는다. 허락이 오면 멈춰 있던 호출이 그대로 이어진다.

5. 요청마다 서버를 새로 만든다

규모를 감당하는 구조도 단순하다. 요청이 올 때마다 새 서버 인스턴스를 만들고, 그 시작 시점에 그 사용자의 설정과 권한에 맞는 도구만 붙인다. 그래서 사용자는 자기가 요청한 것이나 쓸 수 있는 것만 받는다.

같은 사용자를 같은 서버로 보내는 장치는 두지 않는다고 한다. 이 방식으로 주간 도구 호출 약 700만 건을 처리하는 규모까지 왔다.

6. 발표가 밝히지 않은 것과 어긋난 대목

주간 도구 호출 수가 발표 안에서 갈린다. 중반에는 약 700만 건이라 하고 끝부분에서는 800만 건에 가까워지고 있다고 말한다. 어느 쪽이 맞는지는 발표만으로 알 수 없다.

49%와 75%가 무엇을 기준으로 잰 값인지 좁혀지지 않는다. 49%는 첫 적재를 줄인 폭이고 75%는 도구 하나의 출력에서 줄인 폭인데, 둘을 합쳐 실제 대화 하나에서 얼마가 줄었는지는 나오지 않는다.

도구를 줄여서 에이전트가 실제로 더 잘하게 됐는지가 없다. 헷갈렸다는 것이 문제의 출발이었으니 줄인 뒤 성공률이 어떻게 달라졌는지가 있어야 하는데, 성공률 이야기는 95%가 넘는다는 현재 값 하나로만 나온다.

발표자가 스스로 밝히는 것 둘은 적어 둘 만하다. 모든 실패를 막을 수는 없다고 말한다. 에이전트는 자기가 어느 저장소에 쓸 권한이 있는지 모르고 여전히 없는 것을 지어내기 때문이다. 그리고 특정 대목을 설명하며 이건 이제 낡은 이야기라고 스스로 못 박는다.

1. 무엇을 보여주는 발표인가

깃허브 코파일럿의 에이전트 모드에 *MCP를 붙여 실제 개발 작업을 시키는 시연이다. 리드미 한 장만 채워 두고 맡겨 여행 예약 앱을 만들고, 데이터베이스에서 자료를 뽑아 테스트 재료를 만들고, 브랜치를 만들어 PR까지 올린다.

시연은 전부 미리 녹화한 영상이다. 인터넷이 못 미덥다고 먼저 밝힌다.

2. 코파일럿이 지나온 세 걸음

발표는 먼저 걸어온 길을 짚는다. 처음은 코드 완성이었고, 다음이 채팅이었고, 지금이 에이전트 모드다.

앞의 둘과 셋째의 차이가 이 발표의 출발점이다. 앞의 둘은 사람이 치는 것을 돕지만, 에이전트 모드는 일 하나를 끝까지 맡는다. 그러면서 바깥에 연결할 일이 생기고 그 자리에 MCP가 붙는다.

리드미만 채워 두고 맡긴 결과가 8분 만에 나왔다고 한다. 다만 발표자 스스로 스타일은 안 갖췄고 기본만 도는 앱이라고 말한다. 예약을 만들고 방을 고르는 정도가 된다.

3. MCP가 붙을 때 무엇이 오가나

셋째 칸이 요점이다. 코파일럿이 프롬프트를 읽어 MCP가 필요하다고 판단하면 바로 붙지 않고 개발자에게 연결해도 되는지 먼저 묻는다. 답을 받고서야 서버를 부르고 데이터베이스에 질의한다.

깃허브 쪽도 같다. 브랜치를 만들고 PR을 올릴 때 그 자리에서 한 번 묻는다.

4. 실제로 시킨 것과 그 안전장치

시연 시나리오는 테스트 만들기다. 로컬 데이터베이스에 든 진짜 자료를 테스트용 모의 자료로 쓰고 싶다는 것이다.

그래서 포스트그레스 MCP로 가서 자료를 뽑아 `mock.json`을 만들라고 시킨다. 조회는 세 걸음으로 간다. 데이터베이스 스키마를 확인하고, 어느 테이블을 쓸지 고르고, 거기서 자료를 뽑는다. 그러고 나면 MCP와 무관한 나머지 작업이 이어져 그 파일을 재료로 테스트를 짠다.

여기 걸린 안전장치가 이 발표에서 가장 실용적이다. 이 포스트그레스 MCP는 읽기 전용으로만 동작한다. 그래서 에이전트가 실수로 데이터베이스를 바꿀 길이 없다.

5. 첫 프롬프트는 맞지 않는다

발표자가 못 박는 말이 하나 있다. 첫 프롬프트는 틀릴 것이라고 장담한다.

그래서 리드미를 쓴다고 한다. 코파일럿 인스트럭션 파일도 같은 쓸모다. `.github/copilot-instructions.md`에 넣어 두면 모든 프롬프트에 미리 얹힌다. 골라 쓰고 싶은 것은 프롬프트 파일로 따로 둔다.

한 번 잘 시키려 애쓰는 대신 시키는 말을 파일로 남겨 두는 쪽으로 가라는 이야기다.

6. 발표가 밝히지 않은 것

8분이 무엇을 잰 값인지 좁혀지지 않는다. 기본만 도는 앱이라고 밝히기는 하지만, 리드미를 쓰는 시간이 들어갔는지, 중간에 몇 번 고쳐 시켰는지가 없다.

견줄 기준이 없다. 사람이 같은 앱을 직접 만들면 얼마나 걸리는지, 에이전트 모드 없이 채팅만으로 하면 어떤지가 나오지 않는다. 8분이 빠른지 느린지 판단할 자리가 비어 있다.

시연이 전부 녹화 영상이다. 실패하는 장면이 나올 여지가 없는 형식이고, 발표자도 그 점을 앞에서 밝힌다.

발표자가 모르는 것을 모른다고 하는 대목은 있다. 전송 프로토콜 한 갈래에는 자신이 밝지 않다고 말하고, 이 바닥이 늘 유동적이라 정확히 어떻게 되는지는 겪어 봐야 안다고 덧붙인다.

1. 어디까지 왔나

*MCP를 만든 쪽에서 지난 흐름과 앞으로를 이야기한다. 자막에 발표자가 자기를 소개하는 대목은 없다.

채택 수치를 먼저 든다. 월간 다운로드가 1억 1,000만 건에 이르렀고, 견줄 대상으로 리액트를 놓는다. 리액트가 같은 다운로드 규모에 닿는 데 대략 두 배의 시간이 걸렸다는 것이다.

해마다 무엇이 달랐는지도 갈라 놓는다. 2024년은 데모를 잔뜩 만든 해였고, 2025년은 코딩 에이전트와 탐색의 해였고, 2026년은 프로덕션과 연결성의 해라고 말한다.

연결성이라는 말이 이 발표의 제목이다. 가장 잘하는 에이전트는 한 가지 방법만 쓰지 않고 컴퓨터 사용과 CLI와 MCP와 *스킬을 전부 쓴다는 것이다.

2. 셋 중 무엇을 골라 쓰나

2026년에 에이전트를 만들 때 따질 것을 셋으로 나눈다.

세 갈래와 어울리는 자리

3. 도구를 부르는 방식이 바뀐다

여기가 이 발표에서 가장 실용적인 대목이다.

지금까지는 모델이 도구를 하나 부르고, 결과를 받고, 다시 말하고, 또 다른 도구를 부른다. 부를 때마다 모델을 한 번씩 거치는 왕복이 생긴다.

대신 모델에게 *REPL 같은 실행 환경을 준다. 그러면 모델이 스크립트를 써서 여러 호출을 한 번에 엮는다. 왕복이 사라진다.

컨텍스트 쪽에도 같은 결의 변화가 있다. 도구를 전부 컨텍스트 창에 미리 넣던 것을, 모델이 필요로 할 때 도구 검색으로 불러오게 바꿨다. 클로드 코드에 넣기 전과 후 화면을 나란히 보이며 도구가 차지하던 컨텍스트가 크게 줄었다고 말한다.

4. 서버 하나가 두 갈래로 쓰인다

앞으로를 이야기하는 대목에서 이 그림이 나온다. MCP 서버가 도구만 내보내는 것이 아니라 앱까지 함께 실어 보낼 수 있다는 것이다.

그러면 같은 서버를 사람은 화면으로 만지고 모델은 도구로 만진다.

6월에 나올 것으로 몇 가지를 더 든다. 지금 전송 방식의 확장성 문제를 풀 상태 없는 전송 규격, 서버를 찾아내는 방법, 그리고 SDK의 다음 판이다.

로그인 이야기도 있다. 회사가 쓰는 신원 제공자에 한 번만 로그인하면 여러 MCP 서버를 다시 로그인하지 않고 쓰게 하겠다는 것이다.

5. 발표가 밝히지 않은 것

성능을 잰 값이 없다. 도구가 차지하는 컨텍스트가 크게 줄었다고 화면으로 보이지만 얼마나 줄었는지 숫자가 안 나온다. 스크립트로 묶는 방식이 왕복보다 얼마나 빠른지도 없다.

1억 1,000만 건은 채택 수치다. 얼마나 잘 쓰이는지를 재는 값이 아니다. 리액트와 견준 대목도 도달 속도를 견준 것이지 무엇이 더 낫다는 이야기가 아니다.

앞으로 나올 것들은 아직 예고다. 상태 없는 전송이든 서버 찾기든 한 번만 로그인하기든, 실제로 무엇이 얼마나 나아지는지는 이 발표에 없다.

언제까지 유효한 이야기인지 밝히지 않는다. 6월에 무엇이 나온다는 예고가 뼈대인 발표라 특히 날짜를 붙여 읽어야 한다.

한 가지는 솔직하다. 발표자가 아직 만들 것이 많은 이유로 자기들 에이전트가 여전히 부족하다는 점을 먼저 든다. 자기가 쓴 파이썬 SDK보다 남이 만든 것이 낫다고 말하는 대목도 있다.

1. 무엇을 보여주는 발표인가

마이크로소프트와 깃허브에서 개발자 애드보킷으로 일하는 두 사람이 발표한다. 한 사람은 VS Code와 코파일럿 쪽을 주로 다룬다고 밝힌다.

주장은 한 줄이다. MCP 앱은 서버 도구가 채팅 안에서 바로 그려지는 화면을 돌려주게 한다.

바닥 구조부터 짚는다. *MCP에는 호스트가 있고, 클라이언트가 있고, 서버가 있다.

2. 글만 오던 자리에 화면이 온다

예전에는 서버가 글만 돌려줬다. 그래서 설명 문서에 아스키 그림과 이모지가 넘쳤다고 말한다.

같은 물음을 그림 그리는 MCP 서버에 던지자 이번에는 다이어그램이 만들어져 떴다. 나란히 놓고 보이는 대비다.

3. 화면이 뜨기까지

*MCP 앱은 세 부분으로 이루어진다.

MCP 앱을 이루는 셋

도는 순서는 이렇다. 사용자가 묻고, 모델이 어느 도구를 쓸지 정하고, 서버가 결과와 함께 화면 재료를 가리키는 표를 돌려준다. 호스트가 그 HTML을 가져와 가둬 둔 틀 안에 그린다.

거기서 끝나지 않는다. 사용자가 그 화면을 만지면 앱이 서버로 되묻고, 서버가 새 자료를 돌려주면 화면이 갱신된다.

4. 실제로 보인 것

시연은 프로파일링이다. 직접 짠 Go 코드를 5초 동안 재서 어디에 시간이 가장 많이 쓰이는지 본다. 그 결과가 플레임 그래프로 채팅창 안에 떴다.

쓰는 곳으로 쇼피파이와 그림 도구와 피그마를 든다. 다만 피그마 쪽은 잘 그려진 화면 예시를 못 찾았다고 발표자가 그대로 밝힌다.

5. 발표가 밝히지 않은 것

수치가 없다. 5초는 프로파일링을 돌린 시간이지 이 구조가 무엇을 얼마나 낫게 하는지를 잰 값이 아니다.

화면이 오면 무엇이 나아지는지 견줄 값도 없다. 글로 받을 때와 화면으로 받을 때 사람이 일을 얼마나 빨리 끝내는지가 나오지 않는다. 아스키 그림과 다이어그램을 나란히 보이는 것으로 대신한다.

가둬 둔 틀이 무엇을 막는지 없다. 서버가 준 HTML을 화면에 그린다는 구조라 무엇을 허용하고 무엇을 막는지가 안전의 핵심인데, 가둬 놓았다는 말까지만 있다.

언제까지 유효한 이야기인지도 밝히지 않는다.

1. 무엇을 보여주는 발표인가

AWS가 낸 오픈소스 에이전트 SDK를 소개하는 발표다. 자막에 발표자가 자기를 소개하는 대목은 없다.

내세우는 동기가 하나다. 에이전트를 만들 때 붙는 발판을 걷어내고 최대한 단순하게 만들자는 것이다.

시연은 전부 미리 녹화했다. 행사장 와이파이를 못 믿겠다는 이유를 먼저 밝힌다.

2. 에이전트를 이루는 셋

발표가 반복해서 짚는 것이 이 자름이다.

에이전트를 만들 때 주는 것

이 셋을 주면 끝이라고 말한다. 설치도 두 걸음이다. 본체를 깔고 기본 도구 묶음을 깐다.

도구를 직접 만드는 것도 짧다. 파이썬 함수 하나에 데코레이터를 얹으면 그대로 도구가 된다. 만든 도구는 기본 도구와 같은 목록에 나란히 넣는다.

3. 한 판이 도는 순서

첫 시연은 기본으로 딸려 오는 도구 셋만 쓴다. 디스크에서 파일을 하나 읽고, 내용을 간추리고, 그 요약을 파일로 쓰고, 결과를 소리로 낸다.

따로 만든 도구 없이 시킨 문장 하나로 이 네 걸음이 돈다는 것이 이 시연이 보이려는 것이다.

4. 바깥 도구를 붙이는 순서

둘째 시연은 *MCP 서버를 붙인다. 에이전트와 함께 MCP 클라이언트를 만들고, 이미 떠 있는 서버에 연결하고, 그 서버가 가진 도구 목록을 받아 온다.

셋째 걸음이 요점이다. 서버에 무슨 도구가 있는지 미리 적어 두지 않는다. 붙은 뒤에 목록을 넘겨받으므로 서버 쪽이 바뀌어도 클라이언트를 고칠 일이 줄어든다.

그렇게 붙인 뒤 삼차 방정식을 시각화해 달라고 시키자 영상이 만들어졌다.

5. 발표가 밝히지 않은 것

수치가 하나도 없다. 지연도 비용도 정확도도 나오지 않는다. 발판을 걷어내 단순해졌다는 것이 주장인데, 단순해져서 무엇이 얼마나 나아지는지를 잰 값이 없다.

견줄 대상도 없다. 다른 에이전트 프레임워크로 같은 시연을 하면 코드가 얼마나 길어지는지, 무엇이 더 번거로운지가 나오지 않는다. 발판이 없다는 말이 비교 없이는 확인되지 않는다.

시연이 전부 녹화 화면이다. 실패하는 장면이 나올 여지가 없는 형식이다.

언제까지 유효한 이야기인지도 밝히지 않는다.

발표자가 스스로 짚는 한계는 하나 있다. 시연에서 만들어 낸 코드를 사람이 손으로 짜려면 시간이 꽤 걸리고 그리 간단하지 않다는 대목이다.

1. 무엇이 문제인가

그래프 데이터베이스를 만드는 회사에서 큰 조직의 데이터를 에이전트가 쓸 수 있게 만드는 일을 한다고 밝히며 연다. 자막에 자기 이름을 대는 대목은 없다.

문제를 세우는 예는 은행이다. 계좌 개설을 자동으로 처리하는 에이전트를 만든다고 하자. 신원을 확인하려면 자료를 찾아야 하는데, 큰 조직에서는 그것이 쉽지 않다.

스타트업이면 데이터베이스 하나만 보면 된다. 기업은 다르다. 데이터베이스가 수백 개이고 그 밖에 여러 저장소가 흩어져 있다.

에이전트를 두 조각으로 나눠 보면 문제가 또렷해진다. 무엇을 할지 정하는 부분과 자료에 닿는 부분이다. 팀마다 에이전트를 만들 때마다 뒤쪽을 처음부터 다시 잇는다.

2. 두꺼운 에이전트와 얇은 에이전트

발표가 그리는 이동이 이것이다. 지금은 에이전트마다 자료 자리를 손으로 이어 붙인 두꺼운 모양이다. 옮겨 가려는 곳은 공유하는 바닥이 그 일을 맡고 에이전트는 가벼워지는 모양이다.

그 바닥을 발표는 *온톨로지라 부른다. 그것을 이루는 것으로 셋을 든다.

바닥을 이루는 세 기둥

발표자는 이 셋이 함께 네 가지 문제를 푼다고 말한다. 다만 그 넷을 다시 하나씩 세어 보이지는 않는다.

3. 고른 것이 기록으로 남아 되먹는다

셋째 기둥이 왜 필요한지 보이는 사례가 나온다.

에이전트가 준법 확인을 하려다 정부가 낸 신분증을 봐야 한다는 것을 알아챈다. 그것을 확인할 자리가 둘 있다. 차량 등록 기록과 여권 확인 서비스다. 그중 하나를 고른다.

여기서 끝나지 않는다. 어디서 무엇을 했고 잘 됐는지가 기록으로 남는다. 그 기록이 점수가 되어 다음번 고르기에 든다.

4. 발표가 밝히지 않은 것

수치가 하나도 없다. 이 바닥을 세웠을 때 무엇이 얼마나 나아지는지가 나오지 않는다. 배선을 다시 하지 않아 아낀 시간도, 자료를 더 잘 찾게 된 정도도 없다.

바닥을 만드는 법을 이 발표에서 안 다룬다. 기술 쪽 뜻풀이를 세 가지 방법으로 만들 수 있다고 말하면서 이 발표에서는 다루지 않겠다고 그 자리에서 밝힌다. 얇은 에이전트가 성립하려면 그 바닥이 있어야 하는데 그 만드는 값이 통째로 빠져 있다.

점수를 어떻게 매기는지도 없다. 실행 흔적이 다음 선택에 든다는 것까지만 나오고, 무엇을 잘한 것으로 치는지가 없다.

견줄 대상도 없다. 두꺼운 방식과 얇은 방식을 나란히 놓고 잰 값이 없다.

큰 조직 여럿에서 이 문제를 풀어 왔다고 말한다. 포춘 20위 안에 드는 은행과 베이 에어리어의 큰 기술 회사와 앞선 핀테크 회사를 든다. 다만 그 일에서 무엇이 어떻게 됐는지는 나오지 않는다.

1. 90초에 벌어진 일

지속적 통합(CI) 팀에서 시험 장치를 만드는 엔지니어가 발표한다. 수천 명이 매일 코드를 안전하게 내보내게 하는 배관이 자기 일이라고 말한다.

요즘 에이전트 시연은 다 같은 식으로 열린다고 말한다. 무엇이든 되는 토큰을 쥐여 주고 도구 목록을 주고 지켜본다. 이 발표는 그 시연이 끝난 뒤의 이야기다.

사고는 이렇게 났다. 에이전트가 이제 쓸모없다고 본 작업들을 스스로 치우려 했다. 파이프라인 한 단계가 아무 값도 없는 것으로 계산되면서 걸러 내는 조건이 빠졌고, 고르는 식이 전부와 맞아떨어졌다.

작업 200개가 지워졌다. 엔지니어 스무 명 몫이 영향을 받았고 전부 90초 안에 끝났다. 그중에는 오래 도는 학습 작업도 있었고 중간 저장조차 안 된 것이 섞였을 수 있다고 말한다.

악의는 없었다고 못 박는다. 에이전트는 정말로 정리한다고 믿었다.

2. 토큰이 왜 모자란가

사고 뒤 자신을 괴롭힌 것은 다른 대목이었다고 말한다. 에이전트가 자기가 못 할 일을 한 적이 없다는 것 — 결국 자기 토큰을 쓴 것이다.

그러니 실패한 것은 모델이 아니라, 자기가 눈여겨보지 않는 일에 한도 없는 힘을 준 쪽이라고 말한다.

새로 들어온 사람을 붙일 때 이미 같은 문제를 푼다고 말한다. 키 하나하나를 지켜보지는 않되 올려 보낼 길이 있고, 돌이킬 수 없는 것은 구조적으로 손이 안 닿게 해 둔다.

에이전트는 다르다. 지치지도 자지도 않고, 때때로 아주 자신만만하게 틀린다.

이런 사고 뒤의 표준 처방은 토큰 범위를 좁혀 삭제를 빼는 것이다. 그런데 그것은 새로 온 사람에게는 절대 안 할 짓이고, 길어야 한두 주 버틴다고 말한다.

이유는 토큰의 생김새에 있다. 토큰은 예 아니면 아니오다. 굳어 있는 목록이라 좁히면 쓸모가 없어지고 넓히면 사고 보고서를 쓰게 된다.

예산이 갖는 네 축

3. 소리 내어 틀리는 동사만 준다

첫째 원리다. 여기서 동사란 API 호출이든 명령이든 에이전트가 할 수 있는 동작을 말한다.

같은 크기로 보여도 방향에 따라 터지는 넓이가 다르다고 말한다. 막아 둔 시험을 잘못 되켠다면 최악이라야 여러 사람 화면이 빨개진다. 사람을 잘못 호출한다면 최악이라야 당번이 성가시다.

반대쪽이 문제다. 시험을 잘못 건너뛰면 아무것도 빨개지지 않는다. 진짜 버그가 초록 표시를 달고 배포되고, 한참 뒤까지 아무도 모른다.

그래서 원칙이 선다. 화면에서 소리 내어 틀리는 동사만 에이전트에게 주고 나머지는 사람을 끼운다.

자기 팀 사례를 든다. 당번이 비상 조치로 막아 둔 시험 목록을 쥔 서비스가 있는데, 다시 켜는 쪽은 에이전트가 할 수 있다. 막는 쪽은 비상 동사라 사람이 필요하고 언제나 기록을 남긴다.

기록에 대해 한 줄이 붙는다. 그 줄을 쓰는 펜을 에이전트가 쥐지 않는다. 사이에 낀 프록시가 부른 쪽의 신원을 찍는다.

4. 다시 차오르는 한도

둘째 원리는 속도 제한이다. 다시 차오르는 천장이라고 말한다.

부르는 쪽마다 일정 시간 안에 쓸 수 있는 파괴적 동작이 조금씩 주어진다. 어떻게 쓸지는 자유고 승인도 기다림도 없다. 선을 넘으면 요청이 튕기고, 얼마 지나면 한도가 다시 찬다.

쓰는 동작에는 전부 한도가 걸리고 크기만 다르다. 자기 *이름칸이면 넉넉하고 함께 쓰는 이름칸이면 빠듯하다.

사고 뒤 옆 팀이 만든 것이 구체적이다. 시간당·자원 종류별·이름칸별로 삭제 수를 고정된 수에 묶는 장치다.

빠져나가는 깃발은 늘 있는데, 여기서 뒤집힌다. 에이전트 세션 안에서는 그 깃발이 아무 일도 하지 않는다. 사람에게 직접 그 명령을 실행해 달라고 말할 뿐이다.

5. 자물쇠가 아니라 연기 감지기

셋째 원리다. 허용 목록은 에이전트가 무엇을 필요로 할지 미리 해 보는 추측이고, *걸림줄은 벌어진 뒤에 그 데이터를 얻는 방법이다.

값싼 동작은 하게 두고 모든 동작에 행위자 표시를 남긴다. 한도가 강제하는 쪽이고 걸림줄은 무슨 일이 있었는지 알아내는 쪽이다.

갈린 자리가 여기다. 허용 목록은 시간이 가도 나아지지 않고 낡기만 하는데, 걸림줄은 나아진다.

실제로 쓰는 수 하나를 든다. 어떤 시험 작업이 실패했을 때 에이전트가 시간당 여는 조사 갈래의 개수다. 어느 아침 그 수가 평소보다 훨씬 높아 걸림줄이 당번을 불렀다.

이 도구는 한도를 넘은 뒤에 부른다. 문에 다는 자물쇠가 아니라 연기 감지기라고 말한다.

무슨 일이었냐면, 같은 오류 자취로 실패한 작업 여럿에 에이전트가 조사 갈래를 하나씩 열고 있었다. 실은 인프라 장애 하나가 그 모두를 만들고 있었다.

고친 방법이 이 발표에서 가장 값싼 대목이다. 다음에 이런 것을 보면 갈래를 열기 전에 실패들을 서로 견줘 보라고 한두 줄 적어 준 것이 전부였다.

6. 되돌림 시험

넷째는 원리가 아니라 렌즈다. 코드로 강제하는 것이 아니라 앞의 셋의 크기를 잴 때 던지는 물음이다.

묻는 것은 둘이다. 에이전트가 스스로 되돌릴 수 있나. 틀렸을 때 얼마나 나쁜가.

둘 다 괜찮으면 기록만 남기고 보낸다. 하나라도 아니면 두 번째 열쇠가 필요하다.

기능 깃발 사례가 이 렌즈를 그대로 보인다. 시험용 통로에서는 에이전트가 0에서 100까지 손잡이를 다 쥔다. 진짜 배포로 올리는 열쇠는 없다. 지금 할 수 있는 최선은 시험 통로에서 확인됐으니 사람이 올려 달라고 제안하는 것이다.

앞의 삭제 사고에 이 렌즈를 되대 본다. 한도만 있었어도 수십 개 선에서 끊겼을 것이고, 되돌림 시험은 남의 이름칸에서 돌던 작업은 되살릴 수 없다는 것을 미리 알려 줬을 것이다.

7. 신원은 인프라가 찍는다

정책이 사는 곳이 둘이고 둘 다 필요하다고 말한다.

두 자리의 성격이 다르다

프록시는 프롬프트를 읽지 않고 왜인지도 모른다. 삭제가 보이고 예산을 넘은 것이 보이면 거절 코드를 돌려주고 대화가 끝난다. 끼어드는 말로 규칙을 설득할 수 없다.

발표가 마지막에 30초를 따로 쓰는 대목이 이유다. 에이전트가 자기 신원을 스스로 댈 수 있다면, 한도에 걸렸을 때 가장 쉬운 수습은 무엇인가. 이름을 바꾸면 된다. 그러면 예산이 새로 생긴다.

프록시가 길목에 있으면 에이전트는 자기가 누구인지 말할 기회가 없다. 프록시가 이미 알고 있고, 진짜 자격을 쥔 채 그 신원으로 찍는다. 찍는 쪽이 프록시이므로 세션별로 갈라 볼 수도 있다 — 어느 세션이 과하게 굴었는지가 그때 보인다.

쿠버네티스 예로 이어진다. 클러스터가 그 표시를 작업 이름표로 적고, 뒤에 생기는 자식 작업이 같은 신원을 그대로 물려받는다. 소유·할당량·한도·승인·걸림줄이 전부 그 표시 하나에 매인다.

닫는 말이 규칙 하나다. 신원은 요청이 아니라 인프라에서 나와야 한다. 그 하나를 제대로 하면 나머지는 조절일 뿐이라고 말한다.

8. 발표가 밝히지 않은 것

한도를 건 뒤의 값이 없다. 사고가 몇 건 줄었는지, 에이전트가 얼마나 답답해졌는지, 사람이 끼어드는 횟수가 얼마나 늘었는지가 나오지 않는다.

여덟 번 중 여섯 남짓이라는 수의 출처가 없다. 글로 뜻을 세우는 것이 그만큼 듣는다고 말하는데, 무엇을 어떻게 세어 나온 값인지가 없다.

한도를 얼마로 잡아야 하는지가 없다. 시간당 몇 개로 묶었는지, 그 수를 어떻게 골랐는지가 나오지 않는다.

프록시가 무는 값이 없다. 모든 나가는 호출이 한 곳을 거치는데 얼마나 느려지는지, 그것이 멈추면 어떻게 되는지가 없다.

견줄 대상이 없다. 이 구조와 다른 방식을 나란히 놓고 잰 자리가 없다. 사고 하나가 전과 후를 구분하는 유일한 근거다.

1. 조용히 틀린다

두 사람이 나와 발표한다. 문제를 세우는 사례가 첫머리에 나온다.

증권 주문을 낼 수 있는 에이전트에게 사용자가 1,000달러어치 주식을 팔아 달라고 말한다. 에이전트는 금액을 수량으로 바꾸는 계산을 하지 않고 숫자 1,000을 그대로 수량 칸에 넣는다. 1,000달러가 아니라 1,000주가 팔린다.

주당 190달러라면 19만 달러짜리 사고가 된다.

무서운 대목은 그다음이다. 응답은 30밀리초 만에 정상으로 돌아왔고 예외도 경보도 하나 없었다. 화면에서는 아무 일도 없어 보인다.

2. 온도를 0으로 낮춰도 안 되는 이유

같은 것을 다시 돌려 보면 되지 않느냐는 물음에 발표가 답하는 자리다.

결정적이지 않은 네 가지 이유

그래서 같은 결과를 다시 만들려 하지 말고 그때 있었던 일을 되감자는 것이 이 발표의 방향이다.

3. 무엇을 기록해 두나

발표자들이 만든 도구는 마디마다 경계를 그어 두고 그 경계에서 드나든 것을 적는다.

시연에 쓴 것은 세 마디짜리다. 사용자 입력을 받는 계획 마디, 주문을 내는 도구, 답을 만들어 돌려주는 마디다. 셋 다 경계에 표시가 붙는다.

실제로 돌려 보이자 모델이 1,000을 수량으로 잘못 잡아 주문 도구를 불렀고, 도구는 그것을 그대로 실행했다.

전체 흐름은 일곱 걸음으로 정리한다. 표시하고, 기록하고, 눈에 보이게 만들고, 무슨 일인지 이해하고, 고치고, 다시 돌리고, 확인한다.

4. 사고를 시험으로 바꾸는 순서

이 발표에서 가장 실용적인 대목이다. 남은 자취를 그냥 보는 데서 끝내지 않고 시험으로 바꾼다.

자취를 불러오고, 재생 모드를 켜고, 어떤 마디는 그때 값으로 굳혀 놓고 나머지는 실제로 돌린다. 모델을 부르는 자리는 굳히고 도구는 진짜로 돌리는 식이다. 그러고 나온 값이 맞는지 *단언을 건다.

그래야 같은 자리를 되풀이해 밟으면서도 고친 것이 정말 고쳐졌는지 볼 수 있다.

5. 발표가 밝히지 않은 것

기록을 남기는 값이 없다. 마디마다 드나든 것을 다 적는 방식이라 기록량이 실행량을 따라 늘어나는데, 얼마나 쌓이고 얼마가 드는지가 나오지 않는다.

되감기가 얼마나 잘 맞는지도 없다. 굳혀 놓은 자리와 실제로 도는 자리를 섞는 방식이라 원래 사고와 완전히 같지는 않은데, 그 차이가 얼마나 되는지가 없다.

견줄 대상이 없다. 이 도구 없이 같은 사고를 쫓을 때와 견줘 무엇이 얼마나 빨라지는지가 나오지 않는다.

수치는 사고 사례 안의 것뿐이다. 30밀리초와 19만 달러는 그 이야기를 그리는 값이지 이 도구를 잰 값이 아니다. 자막이 이 대목의 숫자를 뭉개고 있어 정확한 표기는 원문에서 갈린다.

1. 무엇을 다루는 자리인가

구글 딥마인드에서 개발자 관계와 AI 플랫폼을 맡은 두 사람이 나와 이야기한다. 딥마인드가 에이전트 소프트웨어를 어떻게 보고 자기들 스택을 어떻게 만드는지가 주제다.

발표가 아니라 패널이라 정리된 주장보다 사내 사정이 그대로 나온다. 모르겠다고 답하는 대목이 여러 번 있고, 서브에이전트가 어떻게 도는지는 자세히 모른다고 말하는 자리도 있다.

2. 사람이 끼어드는 자리

시연에서 보인 도구는 일을 받으면 명세를 보고, 분석하고, 자기 도구로 무엇을 할지 목록을 짜고, 브라우저를 움직이며 화면 구조까지 들여다본다. 끝나면 보고서와 화면 기록을 남긴다.

여기서 사람이 끼어드는 자리가 정해져 있다. 도구가 무엇을 고칠지 계획을 펴 보이면, 사람이 그 줄을 손봐 다른 동작을 시킨다. 다 됐다 싶으면 진행하라고 말하고, 그때서야 실제로 손을 댄다.

3. 한도가 차면 내려간다

운영 이야기 중 가장 구체적인 대목이다. 큰 모델의 토큰 한도에 닿으면 빠른 모델로 자동으로 내려간다. 구독분을 전부 쓰면 로컬 모델까지 내려간다.

여기서 솔직한 말이 하나 나온다. 사내 한도가 바깥 고객보다 빡빡하다고 한다. 고객을 먼저 놓기 때문이라는 것이다.

4. 안에서 어떻게 보고 어떻게 리뷰하나

코드 리뷰에는 자동 리뷰 모델을 쓴다. 사내 스타일 가이드로 *파인튜닝한 것이고, 그 위에 제품 단위로 각자 프롬프트를 얹어 다른 리뷰어에게 쓸 만한 신호가 가게 한다.

들여다보는 쪽도 있다. 사용자가 에이전트에 질의를 던지면 그것이 자동으로 화면에 뜨고, 계층을 따라 내려가며 모델에 실제로 간 요청까지 파고들 수 있다고 한다.

5. 발표가 밝히지 않은 것

수치가 하나도 없다. 지연도 비용도 정확도도 나오지 않는다. 한도가 차서 작은 모델로 내려갔을 때 결과가 얼마나 나빠지는지도 없다. 내려간다는 구조만 있고 그 대가가 없다.

자동 리뷰 모델이 얼마나 맞히는지도 없다. 스타일 가이드로 파인튜닝했다는 것까지만 나오고, 사람 리뷰어가 그 신호를 얼마나 받아들이는지가 없다.

패널이라 확정과 탐색이 섞여 있다. 출시 계획 같은 대목은 자세히 말할 수 없다며 넘어가고, 지금 살펴보는 중이라는 답이 여러 번 나온다.

시연 도중 빠른 모델 쪽이 오류를 내 다시 시작하는 장면도 있었다.

1. 무엇이 바뀌었다고 말하나

마이크로소프트에서 AI 엔지니어링 일을 한다고 자신을 밝힌 크리스 노어링이 발표한다.

옛날에는 키보드에 온전히 매달렸고 개발자 자신이 진행 속도의 한계였다고 말한다. 코드를 전부 자기가 썼으니 나아가는 폭도 딱 그만큼이었다.

그것이 더는 한계가 아니라고 말한다. 일이 사라진 것은 아니고 무게중심이 옮겨 갔다는 쪽이다.

한때는 도구가 만든 코드가 형편없어 도로 다 고쳐 써야 했다고 말한다. 그래서 지금은 *가드레일이 일의 큰 몫이 됐고, 안 쓰는 선택지는 남아 있지 않다고 말한다.

2. 세 지점 — CLI에서 시작해 에디터를 거쳐 늘린다

발표는 일하는 자리를 셋으로 센다. 첫째가 명령줄, 둘째가 에디터, 셋째가 늘리는 일이다.

시작점이 에디터가 아니라 명령줄이라는 것이 이 발표에서 가장 낯선 대목이다. 업계에서 20년을 보냈고 그중 19년 반을 에디터에서 살았다고 말하면서도, 이제 새 출발점은 명령줄이라고 말한다.

화면을 안 열고도 이슈 열다섯 건을 닫을 수 있다면 굳이 열 이유가 없다는 것이다. 에디터는 여러 갈래에서 올라오는 것을 지켜보는 관제판이 된다.

대신 자바나 자바스크립트나 파이썬으로 쓰는 일이 줄고 프롬프트로 쓴다고 말한다. 「앱을 만들어라」 「이 기능을 붙여라」 「이걸 고쳐라」 같은 말이다.

3. 가드레일 셋

발표가 드는 가드레일

첫째만 발표자가 「가드레일 1번」이라 부른다. 나머지 둘에는 번호를 안 붙이고 순서로만 잇는다.

Agents.md에 「시키기 전에는 얼개를 바꾸지 마라」 같은 줄을 둔다고 말한다. 새 프로젝트라면 다른 프로젝트에서 쓰던 것을 그대로 옮겨 붙이고 이걸 따르라고 말하면 된다고 한다.

에이전트가 일을 제대로 안 하는 문제가 따로 있어서 그럴 때 스킬이 필요하다고 말한다. 스킬은 폴더 하나에 자체완결로 들어 있고 일부러 좁혀 놓은 것이다.

스킬로 모자랄 때 커스텀 에이전트를 든다. 파일을 두는 자리와 이름 규칙이 정해져 있고, 앞머리에 쓸 수 있는 도구를 적어 에이전트가 할 수 있는 일을 그것으로 조인다. 데모에 나온 조사용 에이전트는 읽고 웹을 뒤지고 할 일을 적을 수 있되 파일을 만들거나 고치지는 못한다.

4. 넘긴 일이 어떻게 도나

늘리는 방법으로 둘을 든다. 명령줄에서 바로 넘기는 길과 깃허브 화면에서 넘기는 길이다.

명령줄에서는 넘기기 명령을 부른다. 데모에서 「내 지출을 따라가는 가계부 앱을 만들어라」라고 적고 쓸 언어까지 지정한다. 제대로 된 저장소여야 한다 — 아니면 에이전트가 먼저 저장소를 만들어 달라고 한다.

넘기면 작업이 시작되고 초안 PR이 생긴다. 발표가 짚는 대목이 여기다. 에이전트는 *샌드박스 안에서 도니 밖으로 나가 이상한 짓을 하지는 못하는데, PR은 만들 수 있다. 그 자리에서 사람이 들어온다.

깃허브 화면에서는 이슈를 하나 쓰고 에이전트에게 맡긴다. 데모에서는 「앱에 어두운 화면을 붙여라」로 쓴다. 맡기면 뒤에서 도는 동안 다른 일을 계속할 수 있다.

승인 문턱을 스스로 두고 있고 더 둘 수도 있다고 말한다. 머지하는 것은 여전히 사람이다.

5. 발표가 밝히지 않은 것

잰 값이 하나도 없다. 빨라진 정도도, 든 값도, 맞은 정도도 나오지 않는다.

20배도 잰 수가 아니다. 가드레일을 제대로 두면 예전보다 스무 배의 개발자가 된 것이라고 말하는데, 무엇을 스무 배로 쟀는지가 없다. 발표자 자신이 곧바로 코드가 스무 배면 슬롭도 스무 배일 수 있다고 덧붙인다.

이슈 열다섯 건과 터미널 여섯 개도 마찬가지다. 자기 방식을 그리는 수이지 견줘서 얻은 값이 아니다.

실패한 사례가 없다. 에이전트를 어린아이에 빗대며 천재와 바보 사이를 오간다고 말하면서도, 정작 어디서 어떻게 어긋났는지는 나오지 않는다. 가드레일 셋이 그 진동을 얼마나 줄이는지도 없다.

견줄 기준선이 없다. 이 방식과 예전 방식을 나란히 놓고 잰 자리가 없다. 도끼를 던지고 전기톱을 든 셈이라는 비유가 그 자리를 대신한다.

1. 왜 결정하는 틀이 따로 필요한가

그래프 데이터베이스를 만드는 회사의 세션이다. 두 사람이 나와 *컨텍스트 그래프가 에이전트의 판단을 어떻게 돕는지 이야기한다. 자막에 자기를 소개하는 대목은 없다.

문제를 세우는 예가 하나 나온다. 자율 에이전트에게 신용카드와 쇼핑 계정을 쥐여 주고 냉장고에 늘 음료를 채워 두라고 시킨다. 에이전트는 시킨 대로 주문한다. 그런데 집세 낼 날이 다가오고 돈이 모자란다는 사정은 모른다.

시킨 일은 제대로 했는데 결과가 나쁜 자리다. 그래서 무엇을 할지 정하는 절차를 따로 세워야 한다는 것이 이 발표의 출발점이다.

2. 제안하는 자리와 정하는 자리

핵심은 역할을 나눈 것이다. 한 에이전트의 몫은 대안을 내고 장단점을 붙이는 데까지다. 고르는 일은 하지 않는다.

고르는 일은 다음 자리로 넘어간다. 그 자리가 하는 일은 그 행동을 할 권한이 있는지 보는 것이다. 권한이 있으면 하고, 없으면 사람이나 더 높은 권한을 가진 쪽으로 올린다.

3. 판단이 도는 여섯 걸음

전체 순서는 이렇게 간다.

먼저 문제를 세운다. 어쩌다 여기까지 왔는지와 무엇을 노리는지, 어떤 환경에서 도는 일인지를 붙잡는다.

그 위에 규칙을 얹는다. 지난 행동과 함께 회사의 굳은 규칙과 무른 규칙이 여기 들어간다.

그다음이 따져 보는 자리다. 되돌릴 수 있는 일인지, 틀리면 얼마를 무는지, 무엇을 가장 크게 만들려는 것인지를 본다.

거기서 제안이 나오고, 권한을 보는 자리가 받고, 필요하면 사람이 들어온다.

마지막 걸음이 이 틀을 고리로 만든다. 무엇을 왜 골랐는지와 실제로 한 일이 그래프에 함께 쌓인다. 다음 에이전트가 그것을 선례로 본다.

4. 지식은 어디서 오나

바탕에 깔린 구조도 짧게 나온다. 사용자가 물으면 에이전트가 먼저 자기 지식에 있는지 본다. 없으면 *그래프 데이터베이스로 넘어간다.

거기에는 사람 말을 질의어로 바꿔 주는 도구가 있어서, 그것으로 그래프를 훑어 필요한 것을 찾아 돌려준다.

5. 발표가 밝히지 않은 것

수치가 하나도 없다. 이 틀을 썼을 때 판단이 얼마나 나아지는지, 잘못된 결정이 얼마나 줄어드는지가 나오지 않는다.

견줄 대상도 없다. 틀 없이 그냥 시켰을 때와 견준 값이 없어서, 자리를 나눈 것이 실제로 무엇을 막는지는 앞의 음료 사례 하나로만 이야기된다.

권한을 어떻게 정하는지가 없다. 권한이 있으면 하고 없으면 올린다는 구조인데, 그 권한을 누가 어떤 기준으로 정하는지가 이 틀의 급소인데 나오지 않는다.

발표자가 스스로 밝히는 한계는 또렷하다. 이것을 일반화하기가 매우 어렵다고 말한다. 뼈대는 일반적이지만 걸음마다 알맹이는 분야마다 크게 다르다는 것이다.

1. 무엇을 보여주는 발표인가

AWS의 디벨로퍼 애드보킷 마이크 챔버스가 노트북에서 도는 에이전트 코드를 아마존 *베드락으로 옮기는 과정을 보인다. 그는 생성 AI만 전담한다고 밝히고, 예전에 만든 「Fundamentals of LLMs」 강좌를 37만 명이 들었다고 소개한다.

시연은 전부 미리 녹화한 화면이다. 와이파이 때문이라고 먼저 밝힌다.

첫 데모는 파이썬 파일 하나짜리 에이전트다. 프레임워크를 아무것도 쓰지 않았고 스스로 좀 비효율적이라고 말한다. 도구는 주사위를 굴리는 난수 생성기 하나뿐이고, 모델은 노트북에서 도는 라마 3.1 8B다. 모델이 작아 도구 쓰는 법을 스스로 못 익히므로 시스템 프롬프트에 도구 목록과 예시를 넣어 뒀다고 한다.

2. 한 판이 도는 순서

「주사위를 굴리고 민첩 보정치 5를 더해 달라」고 시키자 에이전트가 20면체 주사위에서 10을 얻고 5를 더해 15를 냈다.

3. 에이전트의 최소 조각 다섯

이 발표에서 가장 옮겨 쓸 만한 대목이다. 발표자는 에이전트가 되려면 있어야 할 것을 다섯으로 자른다.

에이전트의 최소 조각

발표자는 이 다섯이 에이전트라 부를 수 있는 최소 목록이라고 말한다. 특정 회사 제품과 무관한 자름이라 자기 코드에 대 보기 좋다.

4. 같은 다섯을 베드락에서 다시 채우기

발표의 나머지는 이 다섯 자리를 AWS 서비스로 하나씩 바꿔 끼우는 시연이다.

로컬에서 만든 것과 베드락에서 바뀌는 것

몇 가지가 눈에 걸린다. *인스트럭션은 프롬프트 그 자체가 아니라 프롬프트 템플릿과 결합돼 실제 프롬프트가 된다고 발표자가 짚는다. *액션 그룹은 도구들의 모음이고, 거기 적는 설명은 사람이 아니라 모델이 읽고 그 도구가 무엇에 쓰는 것인지 판단하는 재료다. 도구 실행은 *람다가 맡으므로 람다로 할 수 있는 일이면 무엇이든 도구가 된다.

콘솔에서 마우스로 클릭하며 보여주지만 같은 일을 테라폼·풀루미·클라우드포메이션·SDK·SAM으로도 할 수 있다고 밝힌다. 퀵 스타트를 고르면 람다 함수 생성과 권한 설정과 에이전트 연결까지 자동으로 된다. 람다 코드를 쓰는 동안에는 콘솔 편집기에 들어 있는 아마존 Q 디벨로퍼가 코드를 제안한다.

에이전트에는 별칭이 붙어서 개발과 운영을 갈라 배포할 수 있다고 한다. 콘솔에서 준비한 에이전트에 같은 질문을 던지자 역시 15가 돌아왔다.

5. 발표가 밝히지 않은 것

규모를 뒷받침하는 숫자가 하나도 없다. 지연도 비용도 처리량도 정확도도 안 나온다. 프로덕션으로 올린다는 것이 발표의 주장인데, 그 주장을 받치는 증거는 로컬과 콘솔에서 똑같이 15가 나왔다는 것뿐이다. 주사위 하나짜리 에이전트에서 같은 값이 나온 것은 옮겨 붙였다는 증거이지 규모를 감당한다는 증거가 아니다.

견줄 기준선도 없다. 직접 짠 파이썬 루프를 그대로 서버에 올렸을 때와 견주면 무엇이 나아지는지, 다른 회사의 관리형 에이전트와는 어떻게 다른지가 안 나온다.

언제까지 유효한 이야기인지도 밝히지 않는다. 콘솔 화면과 옵션 이름에 기대는 시연이라 화면이 바뀌면 그대로 낡는데, 그 점을 짚는 대목이 없다.

시연이 전부 사전 녹화라는 것도 감안해야 한다. 실패하는 장면이 나올 여지가 없는 형식이다.

끝으로 이 발표는 AWS 홍보를 겸한다. 무료 강좌와 부스 방문을 권하고, 시간이 없어 못 다뤘다며 대규모 MCP 서버와 모델 우선 에이전트용 오픈소스 SDK를 부스에서 이야기하자고 넘긴다.

1. 무엇을 확장하는 이야기인가

블룸버그에서 에이전트를 만드는 조직의 관리자가 스케일링을 두 측면으로 갈라 이야기한다. 하나는 시스템을 어떻게 확장하느냐이고 다른 하나는 조직을 어떻게 확장하느냐다.

회사는 15~16년쯤 AI에 투자해 왔다. 2021년 말 거대언어모델이 눈길을 끌기 시작하자 자체 모델을 만들기로 했고 2022년 한 해를 거기에 썼다. 이듬해 그에 관한 논문을 냈다. 그러다 챗GPT가 나왔고, 공개 가중치와 오픈소스 진영이 잘 자라는 것을 보고 이미 나와 있는 것 위에 짓는 쪽으로 전략을 틀었다고 한다.

지금 이 조직은 400명 규모에 팀이 50개이고 런던·뉴욕·프린스턴·토론토에 흩어져 있다. 생성 AI로 제품을 만들어 온 것은 12~16개월쯤 됐고 도구에서 에이전트 쪽으로 옮겨 가는 중이다.

발표자는 사내에서 「에이전트」와 「도구」를 가르기 어려웠다고 밝히며 어휘를 논문 하나에 맞춰 정했다고 말한다. 이 발표에서 에이전트는 더 자율적이고 기억을 갖고 스스로 바뀔 수 있는 쪽을 가리킨다.

2. 무엇을 다루는 회사인가

핀테크 회사이고 고객이 금융에 있다는 점이 뒤의 선택을 거의 다 설명한다.

다루는 자료의 양이 먼저 나온다. 하루에 정형 자료 4,000억 건, 비정형 메시지 10억 건 남짓, 잘 쓰인 문서 수백만 건이 들어오고 40년 넘는 이력이 쌓여 있다.

발표는 금융 종사자 열 가지 유형 중 리서치 애널리스트 하나에 집중한다. 이들은 비정형 자료를 찾고 추리고 요약하며, 정형 자료로 분석하고, 동료와 정보를 주고받는다. 일부는 자료를 정규화해 직접 모델까지 만든다.

금융업에 40년 있었다는 사실에서 나오는 조건이 있다. 정밀성·포괄성·속도·처리량·가용성이 협상 대상이 아니고, 기고자와 고객의 자료를 지키는 것과 투명성도 마찬가지다.

3. 처음 만든 것과 「세미 에이전틱」

2023년에 처음 만든 것은 분기 실적발표 콜을 다루는 제품이었다. 실적 시즌에는 하루에 여러 콜이 겹치므로, 섹터별로 관심 있을 질문에 미리 답을 준비해 두고 애널리스트가 그것을 훑어 더 깊이 볼지 정하게 하려 했다.

처음 성능은 좋지 않았다고 한다. 정밀도와 정확도와 사실성이 그랬다. 게다가 이 요약은 누가 혼자 보는 것이 아니라 모두가 같은 것을 보는 발행물이라 오류 하나의 영향이 크다. 그래서 계속 재고 고치며 요약을 정확하게 만들어 갔다.

지금 구조를 발표자는 *세미 에이전틱이라 부른다. 전부 자율에 맡길 만한 신뢰가 아직 없다는 판단이다. 어떤 조각은 자율이고 어떤 조각은 그렇지 않다. *가드레일이 후자다. 블룸버그는 금융 자문을 하지 않으므로 「여기에 투자해야 하나요」 같은 질문은 걸러 내야 하고, 그 호출은 선택이 아니라 여러 지점에서 반드시 지나가야 한다.

4. 위에 있는 것을 믿지 마라

발표자가 대비로 든 것은 잘 문서화된 소프트웨어다. 행렬곱 API 문서에는 입력의 모든 면과 오류 코드와 걸리는 시간까지 적혀 있다. 그런 것 위에 지으면 내 소프트웨어도 튼튼해진다.

기계학습으로 만든 제품에도 확률적인 구석은 늘 있었지만 그 정도는 다룰 만했다고 한다. 2009년에 만든 뉴스 감성 제품이 예다. 어느 뉴스 와이어를 보는지, 어떤 언어인지, 그 매체의 편집 지침이 무엇인지가 알려져 있었고 출력도 -1에서 +1 사이로 단순했다. 학습 자료를 직접 만들어 시간과 공간 기준으로 *홀드아웃을 떼어 놓을 수도 있었다.

그런데도 아래에 있는 사용자들에게 모델 판이 바뀐다고 따로 알리는 일이 많았다고 한다.

거대언어모델과 그것을 엮은 에이전트로 오면 오류가 곱해진다. 앞의 CPI 사고가 그 예다. 문자 하나가 빠져 월간 자료가 분기 자료 자리에 들어왔는데, 표를 펼쳐 보이지 않고 답만 내보내는 화면에서는 이렇게 겹쳐 쌓인 오류를 잡기 어렵다.

여기서 나오는 결론이 이 발표의 핵심이다. 위에 있는 시스템이 정확할 것이라 기대하지 말고 취약하고 계속 바뀔 것이라 가정한 뒤 내 쪽에서 안전 점검을 한다. 판마다 좋아진다는 말은 평균이 좋아진다는 뜻이고 나에게 좋아진다는 보장은 없다.

발표자는 이 방어막이 오히려 속도를 준다고 덧붙인다. 에이전트마다 방어막이 있으면 아래에 있는 모든 호출자와 합의하지 않고도 각자 바뀔 수 있기 때문이다.

5. 조직도 같이 바뀐다

두 번째 측면이 조직이다. 발표자는 기계학습이 소프트웨어를 자르는 방식이 있고 그것이 조직 구조에 그대로 비친다고 말한다.

제품 모양을 아직 모를 때는 조직과 소프트웨어 스택을 뭉쳐서 한 팀이 빠르게 도는 편이 낫다. 에이전트를 여럿 만들고 나면 성능을 올리고 비용을 줄이고 시험하기 쉽게 만들고 들여다보기 쉽게 만들 차례가 오고, 그때 수평으로 나눈다.

가드레일이 대표적인 수평 기능이다. 50개 팀이 저마다 금융 자문성 질문을 어떻게 걸러 낼지 알아내게 두지 않는다.

지금 리서치 에이전트도 그 결과로 갈라져 있다. 사용자와 세션 맥락을 읽어 질문을 이해하고 무엇이 필요한지 정하는 에이전트가 하나이고, 답을 만드는 일은 다른 에이전트가 맡는다. 바닥에는 오래된 자료 처리가 그대로 깔려 있고, *희소 인덱스가 이제 밀집 인덱스와 둘을 섞은 것으로 바뀌었다고 한다.

6. 발표가 밝히지 않은 것

숫자가 없다. 처음 성능이 좋지 않았다가 나아졌다는 이야기의 앞뒤 값이 안 나온다. 정밀도가 얼마에서 얼마가 됐는지, 가드레일이 무엇을 얼마나 걸러 내는지가 없다.

견줄 기준선도 없다. 세미 에이전틱을 택했다는데 전부 자율로 뒀을 때 무엇이 얼마나 나빠지는지가 안 나온다. 신뢰가 아직 없다는 것은 판단이고 그 판단을 받치는 측정은 발표에 없다.

언제까지 유효한 이야기인지 밝히지 않는다. 12~16개월 만든 제품을 놓고 하는 이야기라 상태가 빠르게 변할 자리인데 그 점을 짚는 대목이 없다.

조직 이야기에서 보여 준 표도 자막만으로는 다 읽히지 않는다. 열이 넷이고 앞의 둘이 수직 팀, 뒤의 둘이 수평 팀이라는 것까지만 나오고 행에 무엇이 적혔는지는 말하지 않는다. 그래서 이 글의 판에도 그 표는 옮기지 않았다.

한 가지는 드물게 좋다. 이 발표에는 자기 회사 제품을 쓰라고 권하는 대목이 없다. 자기들이 어떻게 만들었는지만 이야기하고 끝난다.

1. 왜 큰 모델을 그냥 못 쓰나

엔비디아의 생성 AI 플랫폼 팀에서 일하는 발표자가 사내 직원 지원 에이전트를 사례로 이야기한다. 주장은 한 줄이다. 에이전트를 계속 정확하고 싸게 굴리는 데 필요한 것은 시장에 나온 다음 대형 모델이 아니라 *데이터 플라이휠이라는 것이다.

큰 모델을 깔면 쓸수록 추론 비용이 올라간다. 그래서 같은 정확도를 내면서 지연이 낮고 값이 싼 작은 모델을 계속 찾아 바꿔 끼우자는 것이 이 발표가 말하는 플라이휠이다.

2. 그냥 줄이면 안 된다

사례는 사내 지원 에이전트의 *라우터다. 직원의 질문이 들어오면 *가드레일을 지나 라우터가 어느 전문가 에이전트로 보낼지 정하고, 그 에이전트가 검색으로 답을 찾는다. 라우터가 잘못 보내면 뒤가 다 어긋나므로 정확도가 중요하고, 매 질의마다 도는 자리라 값과 지연도 중요하다.

*파인튜닝을 하지 않고 그대로 깔았을 때 70B 계열은 라우팅 정확도 96%를 냈다. 대신 첫 토큰이 나오기까지 26초가 걸렸다. 같은 조건에서 8B로 내리자 정확도가 14% 아래로 떨어졌다. 지연은 크게 줄었지만 쓸 수 없는 정확도다.

이 간극이 발표의 출발점이다. 작은 모델이 싸고 빠른 것은 맞지만 손을 안 대면 일을 못 한다.

3. 정답 자료를 어떻게 만들었나

플라이휠을 돌리려면 무엇이 맞고 틀렸는지 판정할 자료가 있어야 한다. 발표는 그것을 사용자 피드백에서 만들어 냈다.

피드백에서 정답 자료까지

495건을 사람이 다 보지 않았다는 점이 눈에 걸린다. 먼저 모델이 판정자 노릇을 해서 495건 중 140건을 라우팅 오류로 골라냈고, 그 뒤에 주제 전문가가 손으로 봐서 32건을 확정했다. 사람의 손은 마지막에 가장 좁은 자리에만 들어간다.

이 자료로 작은 모델을 파인튜닝하자 1B 계열이 정확도 94%를 냈다. 70B보다 2%포인트 낮은 자리다. 그러면서 추론 비용은 98% 줄고 지연은 70배 낮아졌다고 한다.

4. 이것을 바퀴로 만드는 네 걸음

발표는 이 과정을 되풀이할 수 있게 네 걸음으로 정리한다. 사용자 피드백을 지켜보고, 무엇이 틀렸는지 오류와 *모델 드리프트로 갈라 원인을 대고, 어떤 모델을 쓸지와 합성 자료를 만들지 파인튜닝을 할지 계획하고, 실제로 돌리며 정확도와 지연을 좇는다.

넷째 걸음의 결과가 다시 첫째 걸음으로 들어가는 것이 바퀴라는 말의 뜻이다.

이 걸음들을 받치는 도구로 발표자는 자사 마이크로서비스 묶음을 든다. 자료를 추리는 것, 파인튜닝하는 것, 평가하는 것, 가드레일을 거는 것, 검색 파이프라인을 만드는 것에 각각 하나씩 붙어 있고 모델은 자사 추론 형식으로 서빙된다고 한다. 자기 회사 제품 안내를 겸하는 대목이다.

5. 발표가 밝히지 않은 것

정답 자료를 만드는 데 든 품이 안 나온다. 주제 전문가가 몇 명이 얼마나 오래 봤는지, 그 일을 몇 번마다 되풀이해야 하는지가 없다. 98%라는 절감폭 옆에 이 품값이 놓여야 비교가 되는데 한쪽만 있다.

바퀴를 얼마나 자주 돌리는지도 없다. 모델 드리프트를 본다고 했으니 주기가 있을 텐데 그 주기가 나오지 않는다.

정확도 말고 다른 것이 어떻게 됐는지 안 나온다. 라우팅을 96%에서 94%로 두고 바꿨을 때 어떤 질문이 새로 틀리게 되는지, 그 2%포인트에 무엇이 들어 있는지가 없다. 라우터가 틀리면 뒤가 다 어긋난다고 발표자가 먼저 말했으므로 이 대목이 비어 있는 것이 걸린다.

자막이 자동 생성이라 숫자 몇 개가 뭉개져 있다. 정답 자료 건수와 모델 크기 축소 배수가 그렇다. 이 글에서는 뭉개진 자리를 그대로 밝혀 두었다.

1. 무엇을 만들며 얻은 이야기인가

마이크로소프트 리서치의 수석 리서치 소프트웨어 엔지니어가 사람과 AI가 만나는 자리를 주로 다뤄 왔다고 밝히며 발표를 연다. 깃허브 코파일럿을 만들었고, 멀티 에이전트 프레임워크 오토젠과 그 스튜디오를 만들었다. 그 전에는 IBM 리서치에서 사람과 컴퓨터가 주고받는 일을 다뤘다.

이 발표는 3D 제작 소프트웨어 블렌더를 자연어로 다루는 에이전트를 직접 만들며 얻은 것을 재료로 삼는다. 거기서 뽑은 설계 원칙 넷을 준다고 먼저 말하고, 완전하지도 완벽하지도 않다고 스스로 못 박는다.

2. 만드는 순서

순서 자체가 주장이다. 목표를 정하고, 견줄 기준을 잡고, 도구를 만들고, 재는 자리를 세우고, 그다음에 에이전트를 붙인다.

둘째 자리가 눈에 걸린다. 견줄 기준은 에이전트와도 AI와도 무관한 것으로 잡으라고 한다. 에이전트가 맨 마지막에 오는 것도 같은 뜻이다. 재는 자리가 먼저 서 있어야 에이전트를 붙인 뒤 무엇이 나아졌는지 말할 수 있다.

재는 자리도 한 번에 만들지 않았다. 처음은 주피터 노트북이었고, 그다음이 사람이 직접 눌러 보는 웹 화면이었고, 마지막이 자동으로 도는 평가 묶음이었다.

3. 루프가 자란 순서

블렌더 에이전트도 한 번에 완성하지 않았다. 단순한 루프를 먼저 돌리고, 결과가 맞는지 보는 검증 에이전트를 붙이고, 단계를 먼저 짜는 계획 에이전트를 붙였다.

화면에서는 작업을 받으면 먼저 분석 중이라고 알리고, 계획을 세웠다고 보여 주고, 단계마다 도구를 불러 실행하는 것을 흘려보내고, 검증을 거쳐 결과물을 낸다.

4. 반쯤 자율일 때 필요한 것 넷

발표자가 든 네 가지 설계 원칙

넷째 원칙에 붙은 예가 구체적이다. 파이썬 코드를 쓰게 했더니 운영체제를 통째로 지우려 드는 일이 생길 수 있다는 것이다. 그런 일이 벌어지기 전에 행동의 값을 재고 사람에게 넘기는 자리가 있어야 한다고 말한다.

5. 멀티 에이전트가 이득인 일은 작다

발표자가 든 그림 하나가 이 발표의 균형을 잡는다. 엔지니어링 팀이 해야 할 일을 큰 원이라 하면, 멀티 에이전트 방식으로 진짜 이득을 보는 일은 그 아래 작은 원 하나라는 것이다.

무엇이 그 작은 원에 드는지 가늠하는 물음도 준다. 계획이 필요한 일인가, 여러 관점이나 역할로 쪼갤 수 있는 일인가, 방대한 맥락을 다뤄야 하는 일인가, 상황에 따라 답이 달라져야 하는 일인가.

6. 발표가 밝히지 않은 것

오류율 20%가 1.5%로 내려간 것은 이 에이전트 이야기가 아니다. 2022년에 만든 앞선 프로젝트에서 모델을 바꾸며 난 변화다. 첫 판은 한 모델을 썼고 석 달 뒤 다른 모델로 옮겨 손보자 그렇게 됐다. 검증 에이전트나 계획 에이전트를 붙여서 난 변화가 아니므로 겹쳐 읽으면 안 된다.

그 검증과 계획을 붙여서 무엇이 얼마나 나아졌는지는 수치가 없다. 루프가 자란 순서는 나오는데 각 단계의 값이 안 나온다. 재는 자리를 먼저 세우라고 말한 발표인 만큼 이 대목이 비어 있는 것이 특히 걸린다.

원칙 넷의 효과를 잰 값도 없다. 발표자가 완전하지도 완벽하지도 않다고 먼저 밝히기는 한다.

작은 흠 하나. 멀티 에이전트가 맞는 일인지 가늠하는 틀을 다섯 단계라고 부르면서 실제로는 넷만 든다. 자막에 그대로 그렇게 나온다.

1. 무엇을 만든 이야기인가

구글에서 이 제품의 제품 엔지니어링 팀을 이끄는 사람이 발표한다. 내세우는 말은 하나다. 에이전트를 앞세운 제품이라는 것이다.

앞서 온 것들을 시기로 짚는다. 한동안은 자동완성이었고, 그다음이 채팅이었고, 그다음이 에이전트였다. 이 제품을 그다음 자리에 놓는다.

2. 세 자리가 뒤집혔다

자리 배치가 이 제품의 주장이다. 한가운데 서는 것은 에이전트를 관리하는 창이고, 편집기와 브라우저는 그 아래로 내려간다.

발표자의 말로는 편집기와 브라우저가 에이전트의 도구다. 사람이 쓰던 자리를 에이전트에게 넘긴 셈이다.

사람이 편집기로 갈 일이 없어지는 것은 아니다. 단축키 하나로 편집기와 관리 창을 오가고 그 전환이 100밀리초 안에 끝난다고 말한다.

3. 결과물을 보여주는 방식

에이전트가 무엇을 했는지 보이는 방식도 바꿨다. 코드가 어떻게 달라졌는지 늘어놓는 대신 결과물을 내민다.

시연에서는 에이전트가 코드를 다 만든 뒤 차이를 보여주는 대신 브라우저를 녹화한 화면을 내밀었다.

무엇을 내밀지는 모델이 정한다. 먼저 결과물을 만들지 말지를 정하고, 그다음에 어떤 종류로 만들지를 정하는 두 걸음이다.

4. 제품과 연구를 잇는 고리

이 발표에서 가장 옮겨 볼 만한 대목이다. 사내 엔지니어와 연구자에게 먼저 쥐여 준다. 실제로 쓰다 보면 평가 점수로는 안 잡히던 구멍이 드러난다고 말한다.

그 구멍을 그 모델을 만든 연구팀과 함께 고치고, 고친 모델로 다시 낸다.

예로 둘을 든다. 컴퓨터를 부리는 일에서는 자료 분포와 감싸는 장치 쪽 문제가 드러났고, 결과물을 만드는 일은 초기 판에서 좋지 않다가 이후 판에서 나아졌다고 한다.

5. 발표가 밝히지 않은 것

받치는 수치가 100밀리초 하나뿐이다. 그것도 화면을 오가는 속도이지 일이 잘 되는지를 재는 값이 아니다. 결과물로 보이는 방식이 코드 차이를 보이는 방식보다 나은지, 사람이 무엇을 얼마나 빨리 판단하게 되는지가 없다.

평가로는 안 보이던 구멍이 무엇이었는지 구체가 얕다. 자료 분포와 감싸는 장치라는 말까지만 있고 어떤 실패가 어떻게 났는지가 없다. 고리의 값어치가 거기에 걸려 있는데 그 자리가 비어 있다.

시연이 미리 만든 영상이다. 안내 영상을 틀어 보이는 대목이 있다.

발표자가 스스로 밝히는 것 둘은 적어 둘 만하다. 시연 도중 쓸 수 있는 용량이 떨어졌다고 말하고, 아직 모델을 못 믿어 맡기지 못하는 일이 있다고 말한다.

1. 무엇을 주장하는 발표인가

깃허브에서 연구 엔지니어로 일하는 사람이 발표한다. 실험적인 것을 다루는 팀 소속이라고 밝힌다.

깔고 가는 물음이 있다. 한 사람이 코딩 에이전트를 여럿 굴리는 그림이 자주 나오는데, 소프트웨어는 한 사람이 아니라 팀이 만든다는 것이다.

그래서 나오는 문장이 이 발표의 제목 노릇을 한다. 무엇을 만들지 합의하는 일이 새 병목이다.

2. 예전에는 세 단계였다

발표는 예전 개발 과정을 셋으로 짚는다. 계획하는 단계가 있고, 만드는 단계가 있고, 검토하는 단계가 있었다.

만드는 일이 싸지면 그 세 단계의 무게가 달라진다는 것이 뒤에 오는 이야기다.

3. 하루에 내보내는 기능

발표에서 유일한 수치가 여기 나온다. 어느 팀이 이제 하루에 기능 다섯 개를 내보내고 있고, 그 전에는 하루 반 개였다고 한다.

4. 계획을 함께 고치는 고리

만든 것은 프로토타입 하나다. 팀원들이 같은 세션에 들어와 함께 일하는 자리다.

계획을 짜 달라고 시키면 계획이 문서로 열린다. 거기서 팀원들의 커서가 같은 문서에 보이고 함께 고친다. 한 사람이 제안을 얹고 다른 사람이 요구사항을 손보는 장면이 나온다. 다 됐다 싶으면 채팅으로 돌아가 실행을 맡긴다.

에이전트에게 시키기 전에 사람들끼리 합의하는 자리를 화면 안에 들여놓았다는 것이 이 프로토타입의 요점이다.

세션에서 바로 *풀 리퀘스트를 만드는 것도 보인다. 만들면 미리보기가 뜨고, 링크를 누르면 그 페이지로 간다. 설명란에는 그 세션으로 되돌아오는 링크가 들어 있다.

5. 발표가 밝히지 않은 것

수치가 하나뿐이고 그것도 좁혀지지 않는다. 하루 반 개에서 다섯 개라는 값은 어느 팀 하나의 것이고, 무엇을 한 기능으로 셌는지와 어느 기간을 견줬는지가 나오지 않는다.

합의가 병목이라는 주장을 받치는 측정이 없다. 사람들이 합의에 얼마나 시간을 쓰는지, 이 도구를 쓴 뒤 그 시간이 얼마나 줄었는지가 없다. 발표의 뼈대가 그 주장인데 그 자리가 비어 있다.

여럿이 같은 계획을 고칠 때 부딪히면 어떻게 되는지 없다. 커서가 같은 문서에 보인다는 것까지만 나오고, 서로 다른 방향으로 고칠 때 무엇이 이기는지가 안 나온다.

발표자가 스스로 밝히는 것은 있다. 아직 제대로 된 제품이 아니고 거칠다고 먼저 말하고, 조기 접근이 몇 달 안에 열릴 것이라고 덧붙인다. 수천 명을 대상으로 시험할 계획도 밝힌다.

1. 무엇을 묻나

깃허브의 실험 조직을 이끄는 사람이 발표한다. 코파일럿을 만든 팀이고, 만든 것이 다 제품이 되지는 않는다고 먼저 밝힌다. 1~2년 뒤에 쓸 도구를 미리 더듬는 것이 일이라면서 자기 수정 구슬은 다음 주까지밖에 안 보인다고 덧붙인다.

묻는 것은 하나다. 코드 한 줄을 쓰는 값이 0에 가까워지는데 그러면 무엇을 만들 것인가.

터미널 열 개를 밤낮으로 돌리는 처지가 돼도 기회비용은 그대로라고 말한다. 무엇을 안 만들지가 여전히 문제라는 것이다.

2. 마크다운이 소스코드다

첫째 프로토타입은 자동화다.

발표자의 개인 웹사이트가 쓰는 얼개는 한 달에 쉰 가지를 내놓는다. 낡았다고 알려 주는 도구는 이미 있는데, 알려 주는 데서 끝나고 고치는 것은 사람 몫이다. 깨진 코드까지 알아서 고쳐 주는 것을 원했다는 것이 출발점이다.

그래서 만든 것이 마크다운 문서로 된 자동화다. 팀 후배에게 보낼 법한 지시를 그대로 적는다.

그 문서에 적힌 일의 순서

굴러가는 형식으로 바뀐 뒤의 파일은 사람이 볼 것이 아니라고 말한다. 마크다운이 소스코드이고 나머지는 굽고 나온 것이라는 쪽이다.

돌려 보인 결과, 깨질 자리가 없다는 것을 확인하고 실제로 빌드까지 해서 확인했다고 말한다. 두 판을 건너뛰는 올림이었고 고쳐야 할 자리를 다 찾아 고쳤으며 사람이 나중에 손으로 해야 할 것까지 짚어 줬다고 한다.

3. 가드레일은 프롬프트가 아니다

문서 앞머리가 가드레일이 서는 자리다. 무엇을 할 수 있고, 무엇을 읽고, 무엇을 쓸 수 있는지를 거기서 정한다.

발표가 못 박는 대목이 여기다. 프롬프트로 「이건 하지 마」라고 적는 것으로는 모자라다. 남이 끼어들어 엉뚱한 데로 끌고 갈 수 있기 때문이다 — *프롬프트 주입이다.

그래서 이 예에서는 권한을 읽기로만 두고, 나갈 수 있는 곳을 몇 군데로 묶는다. 쓸 수 있는 것은 따로 적어 두고 PR은 하나로 못 박는다. 끼어든 누군가가 PR 500개를 만들게 시키면 그 자체가 마비 공격이 되기 때문이다.

아무것도 안 해도 된다고 대놓고 허락해 둔 것도 눈에 띈다. 자동화가 많아지는 판에서 가장 싫은 것이 시끄러움이라는 이유다.

지켜야 할 원칙으로 넷을 든다. 겹겹이 막을 것, 에이전트에게 비밀을 맡기지 말 것, 쓰는 일은 전부 단계를 밟아 확인할 것, 전부 기록에 남길 것이다.

바깥 프로젝트에 줬을 때 처음 만든 것이 무엇이었는지도 말한다. 어느 큰 오픈소스 프로젝트에서는 올라온 이슈마다 오류 자취를 따라가 자기 코드 문제인지 남의 코드 문제인지 가리고, 남의 것이면 닫는 것을 만들었다고 한다.

4. 혼자 하던 자리가 없어진다

둘째 프로토타입은 협업이다.

지금까지는 계획과 검토만 함께 했고 만드는 일은 혼자였다고 말한다. 코드를 쓰는 값이 비쌌기 때문이라는 것이다.

채팅 도구는 사무 일을 편지보다 낫게 하려고 만든 것이지 소프트웨어를 만들라고 만든 것이 아니라고 말한다. 그런데도 좋은 구석이 있는데, 코드에 없는 사실이 거기서 드러난다는 점이다. 어느 클라우드와 값을 잘 맞춰 놨으니 거기에 짓자는 식의 결정이 그렇다.

만든 판은 채팅과 많이 닮았다. 각 자리는 저장소의 갈래 하나이고 내 기계가 아니라 클라우드의 작은 가상 기계에서 돈다. 팀과 나눈 대화 전체를 보므로 그 기록 위에서 움직인다.

발표가 드는 쓸모가 하나 있다. 엔지니어링 대화는 오갔다 되돌아오다 끝에 가서야 결론이 서는데, 그 끝 상태를 골라내는 일을 맡길 수 있다는 것이다.

기능을 붙여 달라고 하자 계획이 마크다운 문서로 나왔고, 그 문서를 혼자 보는 것이 아니라 같이 보고 같이 고친다고 말한다. 앞으로 일의 결과가 점점 문서로 남고 그 문서를 고치는 것이 개발하는 방식이 될지 모른다고 덧붙인다.

5. 발표가 밝히지 않은 것

데모가 끝까지 안 돌았다. 망이 좋았으면 더 빨랐을 거라며 기다릴 시간이 없으니 믿어 달라고 말하고 넘어간다.

보여 주려고 일부러 안 올려 뒀다고 자인한다. 중간 판으로 올렸으면 이미 얻었을 것들인데 데모를 위해 미뤄 뒀다고 말한다. 그러니 이 데모는 실제로 밀린 상황을 잰 것이 아니다.

자동화의 값이 없다. 아낀 시간도, 든 값도, 맞은 정도도 나오지 않는다. 안에서 이슈 분류와 질의 문제 찾기에 썼다고만 말하고 결과는 없다.

타이핑 5%의 출처가 없다. 개발자 100명을 수천 시간 따라갔다는 연구를 드는데 누가 언제 한 것인지가 없다.

협업 쪽은 아직 나오지도 않았다. 자동화는 공개 미리보기로 열렸다고 말하지만 협업 판은 이달 안에 기술 미리보기로 나오길 바란다는 정도다. 잰 값이 없는 것이 당연한 단계다.

이 발표에는 견줄 기준선이 없다. 자동화를 안 쓸 때와 견준 자리가 한 군데도 없다.

1. 왜 코드보다 문서가 먼저인가

AWS의 시니어 개발자 애드보킷 에릭 핸쳇이 *명세 주도 개발을 소개한다. 정의는 한 줄이다. 코드를 한 줄도 쓰기 전에 요구사항과 설계 문서를 마크다운 파일로 먼저 만든다.

왜 그래야 하는지를 발표자는 인턴에 빗댄다. 코딩 어시스턴트는 AI 인턴이고, 여지를 조금만 주면 궤도를 벗어난다는 것이다. 자기 첫 직장 이야기를 든다. 부사장이 돌아다니며 즉흥적으로 아이디어를 던지면 하던 일을 다 놓고 그것부터 했다. 나중에 상사한테 들은 것은 받아 적어 일정에 넣고 매니저와 먼저 상의하라는 말이었다. 지금 언어 모델이 하는 짓이 그때 자기가 한 짓이라고 말한다.

최신 프런티어 모델이면 다 알아서 해 주지 않느냐는 물음도 자주 받는다고 한다. 모델이 해마다 좋아지고 있지만 아직 완벽하지 않고, 소프트웨어와 요구사항이 계속 바뀌므로 맥락을 더 주는 일이 방향을 잡는 데 쓸모가 있다는 답이다. 일부 모델과 하네스가 코드를 쓰기 전에 생각하거나 계획하는 모드를 넣기 시작했지만, 문서를 실제로 만들어 놓고 사람이 그 사이에 들어가는 것만 한 것은 없다고 말한다.

2. 맥락은 많이 줄수록 좋은가

발표자는 여기부터가 자기 의견이라고 미리 못 박는다.

첫째가 맥락이다. 명세 주도 개발이 모델에 맥락을 많이 넣어 주는 방식인데, 좋은 것도 지나치면 문제가 된다고 말한다. 보통 시작할 때 agents.md 같은 파일에 정보를 적어 두는데, 너무 많이도 너무 적게도 넣지 않는 골디락스 존을 지키라는 것이다. 키로에서는 이 파일을 *스티어링 문서라고 부른다.

둘째가 *스킬이다. 키워드가 잡히면 켜지거나 슬래시 명령으로 직접 부르는 지시 파일인데, 설계 문서를 만들 때든 작업을 구현할 때든 명세 주도 개발과 함께 쓰라고 권한다.

셋째가 신뢰다. 이 흐름 전체에서 생성된 코드의 리뷰어는 사람이고, 문제가 생기면 비난받는 쪽도 에이전트가 아니라 사람이다. 그래서 설계 문서와 요구사항 문서를 계속 들여다봐야 한다고 말한다. 사람 혼자 다 보라는 뜻은 아니고, 평소 쓰던 AI 리뷰 도구로 풀 리퀘스트를 검토하는 것은 그대로 하라고 덧붙인다.

셋을 한 줄로 묶으면 이렇다. 맥락은 사람이 재고, 코드도 사람이 보고, 책임도 사람이 진다.

3. 키로 없이 하려면 무엇을 시키나

AWS가 키로를 만든 배경을 발표자는 이렇게 말한다. 팀과 고객들이 *바이브 코딩을 쓰고 있었지만 원하는 결과가 안 나왔고, 그러다 보니 고객들이 저마다 에이전트에게 요구사항 문서와 설계 문서를 먼저 쓰게 하는 패턴을 만들어 쓰고 있었다. 그것을 대신 해 주는 애플리케이션을 만들기로 한 것이 키로다. 작년 말 일반 공개로 나왔고 CLI 버전도 함께 냈다. 지금은 IDE보다 CLI를 쓰는 쪽이 늘고 있다고 말한다.

kiro.dev를 열었을 때 다운로드가 수만 건 몰렸고, 프리뷰 때는 신청이 너무 많아 게이트를 걸었는데 사람들이 우회하는 길을 찾아냈다고 한다. 이 발표에서 나오는 유일한 숫자다.

발표자는 이 자리가 키로 홍보로만 끝나는 것을 원하지 않는다며 도구 없이 하는 길을 먼저 댄다. 어시스턴트에게 사용자 요구사항을 만들라고 시키거나 내가 쓴 요구사항을 근거로 주고, 그것을 확인한 다음 설계 문서를 만들게 하고, 다시 확인한 다음 요구사항과 설계를 근거로 작업 목록을 만들게 한다. 깃허브가 낸 오픈소스 방식인 스펙 킷도 여러 코딩 어시스턴트에 설치해 쓸 수 있다고 소개한다.

4. 키로가 더한 것은 무엇인가

키로 IDE에서는 스펙을 고르고, CLI에서는 계획 모드를 쓴다. 프롬프트는 「본 영화를 기록하는 무비 MCP 서버를 만들어 줘」 정도로 넣으면 된다.

새 프로젝트에만 맞는 방식이 아니냐는 물음에는 아니라고 답한다. 몇 년 된 앱에 스펙 파일이 수십 개씩 쌓여 있는 것을 봤다고 말한다. 깊이 있는 기능이나 사전 계획이 더 필요한 프로젝트에 맞고, 버그 수정용 스펙 모드도 붙였지만 작은 건은 그냥 바이브 코딩이 나을 수 있다고 말한다.

스펙 모드가 만드는 문서 셋

셋 다 발표자가 화면으로 보여 준 것이고, 재서 낸 값은 아니다. 요구사항과 설계 중 어느 쪽부터 시작해도 되고 둘을 합쳐 쓰는 사람도 있다고 한다. 최근에는 확인 질문의 답을 근거로 문서를 한 번에 뽑아 주는 퀵 플랜 모드도 붙였다.

발표자가 문서를 손보라고 말하는 대목의 근거는 한 문장이다. 넣은 만큼만 나온다는 것이다.

데모는 시간 관계상 새 프로젝트를 만들지 않고 미리 만들어 둔 영화 데이터베이스로 돌린다. 이번에는 요구사항 대신 설계부터 시작하라고 시켰고, 아키텍처와 시퀀스를 그린 머메이드 다이어그램이 여러 장 나왔다. 문서 아래쪽에 붙은 속성 기반 테스트는 타입스크립트·노드 쪽의 fast-check로 값을 바꿔 가며 수십 번에서 수백 번씩 돈다. 요구사항 문서에는 「요구사항 1, 영화 데이터 로딩 — 애플리케이션이 초기화되면 필터 엔진이 로드된다」처럼 적힌다.

MVP를 만들어 달라고 하자 작업 목록이 다시 짜였고, 「1번부터 4번까지가 동작하는 MVP를 만든다 — 검색·장르 필터링·정렬이 되는 영화 그리드와 80년대풍 신스웨이브 테마 전체」라고 목록에 그대로 적혔다. 장르 필터링에 붙은 속성 기반 테스트는 어떤 영화 데이터셋을 넣어도 뽑힌 장르 목록이 정렬된 고유 장르 집합이어야 한다는 조건을 건다.

5. 남이 써 둔 요구사항은 어떻게 들어오나

발표자는 *MCP를 명세 주도 개발에 붙이는 이유를 하나로 든다. 지라나 아사나에 쌓인 티켓과 요구사항 문서를 스펙을 만들 때 그대로 끌어올 수 있다는 것이다. 프로덕트 매니저가 이미 써 놓은 요구사항 문서가 있으면 그것을 가져다 쓴다. 어느 프로젝트 관리 서비스든 마찬가지라고 말한다.

가져오게 시키는 방법은 둘이다. 스티어링 문서나 agents.md에 이 MCP 서버에서 정보를 가져오라는 규칙을 넣어 두거나, 첫 걸음에서 요구사항을 만들 때 이 서버를 보라고 직접 지정한다.

MCP가 나온 지 여섯 달인데 벌써 끝난 것 아니냐는 물음도 받는다고 한다. 명령줄 도구만으로 비슷한 것을 할 수 있다는 의견이 있다는 것도 안다면서, 아직 성숙해 가는 중이고 특히 보안 쪽으로 갈 길이 멀다고 답한다.

6. 발표가 밝히지 않은 것

성능·비용·지연·정확도 수치가 하나도 없다. 명세를 먼저 쓰면 품질이 올라간다는 것이 발표의 주장인데, 그렇게 만든 코드가 무엇을 기준으로 얼마나 나아졌는지 재서 보여 준 자리가 없다. 견주는 기준선도 없다. 바이브 코딩과 명세 주도 개발을 같은 과제에 나란히 놓고 잰 결과는 나오지 않는다. 발표 전체에서 나온 숫자는 다운로드 수만 건, 경력 15년, MVP 작업 네 개, MCP가 나온 지 여섯 달뿐이다.

골디락스 존의 경계도 없다. 정보를 너무 많이도 너무 적게도 넣지 말라는 말은 있는데, 무엇을 보고 많다고 판단하는지가 없다. 이 방식에서 사람이 제일 자주 헤매는 자리가 여기라 아쉬운 대목이다.

문서를 만들고 손보는 데 드는 시간도 다루지 않는다. 요구사항과 설계를 사람이 앞뒤로 오가며 고치라는 것이 이 방식의 핵심인데, 그 시간이 바로 코드를 짜는 것보다 얼마나 더 걸리는지, 언제 그 시간이 아깝지 않은지가 발표에 없다. 깊이 있는 기능과 복잡한 프로젝트에 좋다는 말이 그 자리를 대신한다.

속성 기반 테스트가 요구사항 문서를 근거로 만들어진다는 설명도 그 이상 들어가지 않는다. 요구사항 문장이 어떻게 테스트 조건으로 바뀌는지, 문서 자체가 틀렸을 때 그 테스트가 무엇을 지켜 주는지는 발표가 설명하지 않는다.

데모는 실패 없이 지나갔고, 발표자가 스스로 밝힌 한계는 「넣은 만큼만 나온다」 한 문장이다.

1. 셋으로 이루어진다

같은 팀에서 코딩 에이전트를 만든다는 두 사람이 나온다.

코딩 에이전트를 셋으로 나눈다. 사람이 마주하는 자리, 모델, 그리고 하네스다. 오늘 볼 것은 마지막이라고 말한다.

*하네스를 이렇게 정의한다. 프롬프트와 도구를 한 고리 안에 모아 모델과 주고받게 하는 것이다.

발표의 출발점은 겪은 고통이다. 모델이 새로 나올 때마다 그 위에 얹은 것을 다시 만들어야 했다.

2. 지능 더하기 습관

모델을 하네스에 맞추는 것을 이렇게 요약한다. 지능에 습관을 더한 것.

자기네 모델이 배운 습관을 든다. 계획하고, 둘러보고, 맥락을 모으고, 생각한 뒤에 코드를 고치고, 끝에 돌려 본다.

문제가 터진 자리가 여기다. 어느 모델을 냈을 때 사람들이 다른 모델용으로 쓰던 프롬프트를 그대로 옮겨 왔다. 거기에는 고치기 전에 파일마다 꼼꼼히 살펴보라는 말이 들어 있었다. 그러자 모델이 정말 그렇게 했고 오래 걸렸으며 결과도 좋지 않았다.

답은 단순했다. 하던 대로 하게 두고 과하게 시키지 않는 것이다.

알아낸 방법이 재미있다. 모델에게 직접 물었다 — 답은 마음에 드는데 오래 걸렸으니 다음에 빨리 가려면 지시를 어떻게 바꾸면 되겠냐고. 모델은 다 보라고 하니 그렇게 됐고 그럴 필요가 없었다고 답했다.

3. 하네스가 어려운 이유

하네스가 떠맡아야 하는 것들

새로 낸 모델이 맥락을 줄이는 일을 알아서 해 준다고 말한다.

4. 하네스를 추상화 계층으로 삼는다

만드는 사람들에게서 보이는 무늬 하나를 든다. 하네스가 새로운 추상화 계층이 된다는 것이다.

얻는 것이 뚜렷하다. 모델을 올릴 때마다 프롬프트와 도구를 다시 맞출 일이 없어진다.

그러면 그냥 껍데기 하나 만드는 것 아니냐는 반문이 나온다. 발표자는 동의하지 않는다며, 그래야 힘을 제품이 남과 달라지는 자리에 쓸 수 있고 값은 거기 있다고 답한다.

실제로 그렇게 한 곳들을 든다. 어느 편집기는 그것을 한 겹으로 감싸 자기 화면에 붙였고, 어느 코드 호스팅 쪽은 함께 만든 개발 키트로 곧장 이었다. 또 어느 편집기 팀과는 도구를 모델이 배운 모양에 맞추고 하네스를 공개된 구현에 맞추는 식으로 성능을 끌어냈다.

전부 공개돼 있으니 떠 가서 써도 된다고 말한다.

5. 없던 도구를 만드는 도구

발전 단계를 셋으로 그린다. 말을 주고받던 데서, 도구를 쥐여 주는 데로, 이제는 없는 도구를 스스로 만들게 하는 데로 왔다는 것이다.

그래서 되는 것을 든다. 고객마다 붙는 연결을 그 자리에서 스스로 짜는 기업용 물건을 만들 수 있는데, 예전에는 사람이 붙어서 해 주던 일이라는 것이다.

코딩이 아닌 쓰임도 든다. 명령줄로 말할 수 있는 일이면 무엇이든 된다며, 바탕화면 사진을 폴더로 정리하거나 폴더 안의 표 파일을 잔뜩 훑어 분석하는 것을 예로 든다.

6. 앞으로

모델이 좋아진다고 봐도 안전하다며, 더 긴 일을 지켜보지 않아도 하게 될 것이라고 말한다.

한 줄이 인상적이다. 새 모델은 믿을 수 있는 선을 끌어올린다 — 반년 전이라면 안 맡겼을 어려운 일을 지금은 맡긴다는 것이다.

앞으로 어려울 자리로는 거대한 코드베이스, 표준이 아닌 라이브러리, 닫힌 환경, 그리고 이미 있는 틀과 관행에 맞추는 일을 든다.

닫는 말은 권유다. 하네스는 복잡하고 새 모델이 나올 때마다 손이 많이 가니, 만들어 둔 것을 그대로 쓰거나 소스를 보라는 것이다.

7. 발표가 밝히지 않은 것

성능을 잰 값이 하나도 없다. 하네스를 이렇게 짜면 무엇이 얼마나 나아지는지가 없다. 든 수는 주당 토큰이 수십 조이고 행사 뒤로 두 배라는 쓰임 규모뿐인데, 그것은 성능이 아니라 얼마나 팔렸나에 가깝다.

느려졌다는 사례에도 수가 없다. 얼마나 오래 걸렸고 얼마나 나빠졌는지가 없다. 고친 뒤 얼마나 빨라졌는지도 없다.

모델에게 물어 알아냈다는 방법의 신뢰도가 없다. 모델이 자기 행동의 이유를 정확히 댔는지 따로 확인한 자리가 없다.

파트너 사례에 값이 없다. 함께 맞춰 성능을 끌어냈다고만 하고 얼마나인지가 없다.

습관을 거스르지 말라는 조언의 경계가 없다. 어디까지가 과한 지시인지, 정말 꼼꼼히 봐야 하는 일에서는 어떻게 해야 하는지가 안 나온다.

자막이 모델과 제품 이름을 크게 뭉갠다. 판 번호와 제품 이름이 여러 군데 어긋나 있어 정확한 표기는 원문에서 갈린다.

1. 무엇을 지웠나

커서에서 마크다운이 새 코드가 됐다는 이야기를 하겠다고 발표를 연다. 대상은 두 기능이다.

하나가 *워크트리다. 같은 저장소를 여러 벌 받아 놓은 것처럼 갈라 두는 깃 기능이라, 에이전트 여럿이 같은 과제든 다른 과제든 서로 방해하지 않고 동시에 일할 수 있다. 커서에서는 워크트리마다 에이전트를 띄웠고 같은 파일이 워크트리마다 다르게 보였다. 에이전트가 돌리는 명령이나 린트도 그 워크트리 안에 갇혔다. 화면에는 에이전트가 격자로 늘어서 각자 일했고, PR을 열라고 하면 그 워크트리에서 만든 변경으로 열렸다.

다른 하나가 베스트오브N이다. 같은 과제를 여러 모델에 한꺼번에 주고 결과를 견주는 기능이다. 프런트엔드라면 서로 다른 화면 구현을 미리 보고 마음에 드는 것을 고른다. 커서에서 부르는 이름은 「베스트 오브 10」이고, 작년 10월 커서 2.0과 함께 나왔다.

발표자는 최근 이 기능을 통째로 걷어내는 PR을 열었고 코드 1만 5천 줄쯤이 지워졌다고 말한다. 새 구현은 예전 것만큼은 아니어도 거의 그만큼 하면서 유지하기는 훨씬 가볍다고 한다.

2. 예전 구현은 무엇까지 떠맡았나

지운 것이 무엇이었는지를 발표자가 늘어놓는다.

워크트리를 만들고 관리하고 에이전트에 맥락으로 넣어 주는 코드를 다 짜야 했다. 에이전트가 자기 워크트리를 벗어나지 못하도록 가두는 일도 코드가 했다. 사용자가 정해 둔 셋업 스크립트를 에이전트가 그 워크트리에서 일을 시작할 때마다 돌렸다. 어느 구현이 나아 보이는지 엄지 아이콘으로 알려 주는 판정도 따로 돌렸다. 하네스를 고치고 시스템 리마인더를 넣어 에이전트가 자리를 지키게 도왔다. 사람들이 워크트리를 수백 개씩 만들어 디스크가 불어나니 남은 것을 치워 주는 일까지 했다.

3. 마크다운 두 조각이 그 자리를 어떻게 채우나

발표자가 고른 부품은 둘이다. 에이전트 *스킬과 *서브에이전트다. 이 둘을 겹치면 워크트리 기능도 베스트오브N도 마크다운만으로 다시 만들 수 있다는 것이 판단이었다.

워크트리 쪽 지시는 이렇다. 워크트리를 어떻게 만드는지 알려 주고, 사용자가 정해 둔 셋업 스크립트를 워크트리마다 돌리게 하고, 그 체크아웃에 머무르라고 시킨다.

베스트오브N 쪽은 더 짧아서 작은 글씨로 화면 하나에 다 들어간다. 마크다운 마흔 줄이고, 예전 구현은 코드 4천 줄쯤이었다고 말한다.

지시에 든 조건도 댄다. 윈도우용 지시와 리눅스·맥OS용 지시를 다 담아 어느 판에서나 돌아야 한다. 가장 어려운 대목은 워크트리를 벗어나지 말라고 시키는 자리라, 절대 밖에서 일하지 말라고 세게 적는다고 한다.

새 명령은 /worktree, 베스트오브N을 부르는 명령, 워크트리를 적용하는 명령과 지우는 명령이다. 커서에서 이것들은 사실 스킬이 아니라 커맨드인데, 사용자가 고를 때만 프롬프트가 맥락에 실린다는 점이 스킬과 같다. 커맨드로 만든 이유는 하나다. 프롬프트를 자기네 서버에서 쥐고 있으면 사용자가 커서를 새로 받지 않아도 고친 프롬프트가 바로 간다.

데모는 영상이다. 키미·그록·컴포저·GPT·오퍼스에 같은 과제를 주자 부모가 서브에이전트 다섯을 띄우고 저마다 워크트리와 맥락을 쥔다. 오퍼스가 예상대로 오래 걸리고, 다 끝나면 부모가 지시받은 대로 결과를 견준다.

4. 무엇이 나아지고 무엇이 나빠졌나

갈아치운 뒤 달라진 것

전부 발표자가 스스로 든 것이고 잰 값은 아니다. 포럼에서 반응이 갈리고 있다는 것도 밝힌다. 예전 방식에 익숙하던 사람들이 있다는 것이다.

5. 막는 일을 넘긴 뒤 무엇으로 확인하나

발표자는 이 기능을 두고 평가를 짜 봤고 그것이 사실상 처음이라고 말한다. 커서 CLI를 화면 없이 띄워 돌리고 채점하는 눈을 둘 뒀다. 하나는 모델이 자기 워크트리에서 할 일을 했는지 보고, 다른 하나는 그 반대로 건드리지 말아야 할 원본 체크아웃에서 뭔가 했는지 본다.

지금 평가가 단순해서 모델이 흐트러지기 시작하는 아주 긴 세션은 아직 흉내 내지 못했다고 말한다.

모델마다 다르다는 것은 나왔다. 하이쿠는 작고 덜 똑똑한 모델이라 원본 체크아웃으로 자주 새고, 컴포저와 그록은 훨씬 낫다고 한다. 몇 번 중 몇 번인지는 대지 않는다.

고치는 길로 둘을 든다. 평가를 늘려 프롬프트를 고치는 쪽과, 강화학습으로 자기네 모델을 고치는 쪽이다. 컴포저 2에는 이런 상황을 다루는 강화학습 과제가 아예 없었고, 컴포저 3이나 4, 5를 낼 때쯤에는 적어도 자기네 모델이 이 일을 훨씬 잘하도록 과제를 파이프라인에 넣는 중이라고 말한다. 남의 회사 모델은 자기가 고칠 수 없으니 다른 연구소와 모델 제공사에 겪은 것을 전해 왔다고 한다.

다음 단계도 밝힌다. 최근 알린 커서 3.0의 새 에이전트 창에 더 온전한 워크트리 구현을 넣을 계획이다. 로컬에서 여럿을 한꺼번에 돌리는 사람과 그 화면을 쓸 사람이 대체로 같은 사람이라는 것이 이유다.

깃 워크트리가 아닌 다른 병렬화 수단도 보고 있다고 말한다. 워크트리는 만드는 데 느리고 디스크를 많이 쓰며 깃 저장소에서만 돈다. 깃을 안 쓰는 사용자에게는 커서에 로컬 병렬화 수단이 아예 없다는 것이다.

6. 발표가 밝히지 않은 것

성능·비용·지연 수치가 없다. 나온 숫자는 지운 줄 수와 스킬 줄 수, 사용자 비율 하나뿐이다. 새 구현이 예전 것만큼 「거의」 좋다는 말도 무엇으로 잰 것인지 대지 않는다.

평가 결과도 수치가 없다. 하이쿠가 「자주」 새고 컴포저와 그록이 「훨씬」 낫다는 데서 멈춘다. 스코어러 둘을 짜 놓고도 그 눈으로 본 값이 발표에 나오지 않는다.

유지 부담이 얼마나 줄었는지도 코드 줄 수 말고는 없다. 지우기 전과 뒤에 이 기능에 든 손이 얼마나 달라졌는지, 프롬프트를 서버에서 고치는 일이 대신 얼마나 늘었는지는 다루지 않는다.

가장 큰 구멍은 이탈이 났을 때다. 모델이 원본 체크아웃에서 일해 버리면 그 변경이 어떻게 되는지, 되돌릴 길이 있는지, 사용자가 알아채는 자리가 있는지를 발표가 설명하지 않는다. 예전 구현에서는 일어날 수 없던 일이라 예전에는 물을 필요가 없던 물음이다.

데모는 라이브가 아니라 영상이었다. 포럼 반응이 갈린다는 것도 말로만 있고, 어느 쪽이 얼마나인지는 나오지 않는다.

1. 왜 제품이 모델을 못 따라가나

발표자는 앤트로픽 기술 스태프이자 클로드 코드를 만든 사람이라고 자기를 소개한다. 요지를 앞에 먼저 놓는다. 모델은 지수로 좋아지는데 제품이 그 속도를 따라가느라 허덕이고 있다는 것이다.

이렇게 코딩을 잘하는 모델에 붙일 제품이 훨씬 많이 나올 수 있는데 지금은 최소한만 만들고 있다고 말한다. 그러면서 클로드 코드는 제품이 어떤 모습이어야 하는지에 대해 일부러 견해를 안 갖는다고 덧붙인다. 이유는 모르기 때문이다.

2. 프로그래밍 UX는 어디까지 왔나

발표의 절반은 역사다. 1930~40년대에는 스위치보드를 만지는 물리적인 일이었고 소프트웨어라는 것이 없었다. 1950년대에 펀치카드가 왔다. 발표자의 할아버지가 소련 초기 프로그래머 중 하나였고, 어머니는 그가 집에 들고 온 펀치카드 더미에 크레용으로 그림을 그리며 자랐다고 한다.

1950년대 후반부터 추상화 단계가 올라간다. 어셈블리, 코볼, 타입 있는 언어, C++로 이어지고 1990년대 초에 언어군이 한꺼번에 터진다. 그런데 지금은 눈을 가늘게 뜨면 다 비슷해 보인다고 말한다. 타입스크립트를 쓰는 느낌이 러스트 같고, 그게 스위프트 같고, 또 고 같다는 것이다. 언어의 추상화는 수렴했다.

UX 쪽은 다르다.

발표자가 꼽은 프로그래밍 UX의 마디

연도를 말한 자리만 왼쪽 칸에 적었다. 이클립스·코파일럿·데빈에는 발표가 연도를 대지 않는다.

검증도 같이 옮겨 왔다고 말한다. 손으로 디버깅하고 출력을 눈으로 보던 데서 *퍼징, 취약점 시험, 넷플릭스식 카오스 시험 같은 확률적 검증으로 왔다는 것이다.

여기서 발표자가 뽑는 결론이 하나다. 언어는 평평해졌고 모델과 UX는 아직 지수 위에 있다.

3. 그래서 왜 헐겁게 두나

클로드 코드의 출발점은 터미널이고, 그 위에서 모델에 가능한 한 낮은 수준으로 닿게 하되 일은 되게 만드는 것이라고 말한다. 화려한 화면을 주지 않고 발판을 세워 앞을 막지 않는다.

이유를 둘로 나눈다. 하나는 앤트로픽이 모델 회사라 사람들이 모델 자체를 겪기를 바란다는 것이다. 다른 하나는 올바른 UX가 무엇인지 자기들도 모른다는 것이다. 그래서 단순하게 시작한다고 말한다.

벽에 액자로 걸어 둔 교훈도 꺼낸다. 더 일반적인 모델이 늘 이긴다는 것이다. 모델의 능력이 지수로 오르고 모델 둘레의 것도 함께 오르는데, 그 둘레에서도 더 일반적인 쪽이 보통 이긴다고 말한다. 자막은 이 교훈의 이름을 「the better lesson」으로 뭉갰다.

4. 한 제품에 붙는 길이 넷

터미널은 어디서나 돈다. 아이텀2, WSL, SSH와 tmux 세션, VS 코드나 커서의 터미널까지 가리지 않는다.

IDE에서 띄우면 조금 더 한다. 차이가 터미널 줄로 흐르는 대신 IDE 화면에 크게 뜨고 진단도 가져온다. 그러면서 커서나 윈드서프만큼 다듬어지지 않았다고 스스로 말한다. 두 제품을 매일 쓴다고도 덧붙인다.

깃허브는 발표 몇 주 전에 열렸다. 클로드를 켜고 슬래시 명령으로 앱을 깔고 저장소를 고르면 된다. 사용자 컴퓨트에서 돌고 데이터가 앤트로픽으로 가지 않는다고 말한다.

가장 끝까지 간 길이 *SDK다. 터미널 앱도 IDE 연동도 깃허브도 쓰지 않고 직접 붙이는 방식이다. 발표자는 사고 분류에 쓴다고 한다. GCP 로그를 claude -p 에 파이프로 밀어 넣고 결과를 jq로 훑는다. 유닉스 도구처럼 쓰는 것인데, 이 쓰임은 아직 아무도 제대로 못 찾았다고 말한다.

5. 무엇을 시켰을 때 잘 되나

가장 쉬운 입구는 코드베이스에 묻는 일이다. 앤트로픽은 입사 첫날 모든 엔지니어에게 클로드 코드를 가르치고, 이것으로 온보딩이 2~3주에서 이틀쯤으로 줄었다고 말한다. 발표자 본인은 월요일 스탠드업 전에 지난주에 무엇을 내보냈는지 묻고, 클로드가 깃 커밋을 훑어 답한다.

둘째는 도구를 가르치는 일이다. 예전 IDE는 플러그인을 만들어야 했다. 이맥스는 리스프 방언으로, 이클립스나 VS 코드는 확장으로 붙였다. 지금은 배시 도구와 *MCP 도구를 그냥 준다. 발표자가 자주 쓰는 방법은 CLI의 도움말을 읽게 하고 배운 것을 CLAUDE.md에 적어 두게 하는 것이다. 다리를 놓을 일이 없다고 말한다.

셋째가 순서다. 코드를 쓰기 전에 훑어보고 계획을 세워 사람에게 확인받게 한다. 확장된 사고는 맥락에 이미 무언가 들어와 있을 때 잘 듣는다고 말한다. 먼저 도구로 끌어오고 그다음에 생각하게 한다. 처음부터 생각부터 시키면 토큰만 쓴다.

넷째가 *TDD다. 사람이 하기는 어려운데 모델이 하니 잘 된다고 말한다. 시험을 먼저 쓰게 하되 아직 통과하지 않는다는 것을 분명히 알리고 돌리지 말라고 못 박는다. 시험을 쓰고 커밋하고, 그다음에 코드를 쓰고 커밋한다.

TDD는 더 넓은 규칙의 한 경우라고 말한다. 붙잡고 반복할 목표가 있으면 결과가 훨씬 좋아진다는 것이다. 유닛 시험, 통합 시험, iOS 시뮬레이터 스크린샷, 퍼피티어 스크린샷 어느 쪽이든 출력을 볼 수단이면 된다. 로봇에게 3D 프린터를 가르칠 때도 카메라를 달아 출력을 보게 했다고 한다. 첫 시도는 그런대로고 두세 번째가 쓸 만해진다.

이날 플랜 모드가 나왔다. shift+tab을 누르면 시킨 일을 바로 하지 않고 계획을 세워 승인을 기다린다. 세 번째 방식을 손쉽게 만든 것이다.

마지막은 맥락을 더 주는 일이다. CLAUDE.md를 저장소 뿌리에 두고 하위 폴더나 홈 폴더에도 둘 수 있다. 특별한 폴더에 마크다운을 넣어 두면 슬래시 메뉴에 뜬다. 우물 정 자를 치면 기억해 두라고 시킬 수 있고 어느 메모리 파일에 넣을지 물어 온다. 이 대목에서 발표자는 아직 거칠다고 말한다. 첫 판이지만 처음으로 작동하는 판이라는 것이다.

질문 하나가 슬랙으로 들어왔다. 클로드 코드에 점점 더 맡기게 되고 한 번에 열 개가 십 분씩 돌면 이 도구를 어떻게 쓰느냐는 것이다. 답은 파워 유저들이 하는 방식이다. 터미널 탭을 여럿 열고 저장소를 여러 벌 받거나 같은 저장소를 *워크트리로 갈라 병렬로 돌린다. 깃허브 액션을 쓰면 더 쉽다. 대개 클로드들 사이를 맞출 일이 없고, 맞추기 싫으면 마크다운 파일에 쓰게 하라고 답한다.

6. 발표가 밝히지 않은 것

성능·비용·지연·정확도 수치가 없다. 모델이 지수로 좋아진다는 것이 발표의 뼈대인데 무엇을 얼마나 잰 이야기인지는 나오지 않는다. 나온 숫자는 온보딩이 2~3주에서 이틀로 줄었다는 것 하나인데, 그 이틀을 무엇으로 쟀는지도 밝히지 않는다.

기준선과 견준 자리는 하나뿐이고 방향이 반대다. 커서·윈드서프만큼 다듬어지지 않았다고 스스로 말하는 대목이다. 그 대신 무엇을 얻었는지는 「모델을 날것으로 겪게 한다」는 말로만 있고 잰 값이 없다.

「모른다」가 발표에서 세 번 나온다. 올바른 UX를 모르고, 유닉스 도구로 쓰는 법을 아무도 못 찾았고, 메모리는 아직 거칠다는 대목이다. 스스로 밝힌 한계라는 점에서 값이 있지만, 그래서 언제까지 모른 채로 둘 것인지, 무엇을 보면 알게 되는지는 나오지 않는다.

병렬로 돌릴 때의 조율도 「대개 필요 없다」에서 멈춘다. 필요한 경우가 어떤 경우인지, 마크다운 파일로 주고받다가 서로 부딪히면 어떻게 되는지는 다루지 않는다.

유효기간은 발표자가 직접 밝힌 셈이다. 프로 요금제 지원이 「어제부터」이고 플랜 모드가 「오늘」이다. 제품 이야기는 그만큼 빨리 낡는다.

1. 에이전트가 여기저기서 튀어나온다

행사 마지막 시간대라며 연다. 자막 안에서 발표자가 자기 이름을 대지는 않는다.

앞 발표에서 나온 에이전트가 주는 머릿속 부담에 동의한다며 시작한다. 명령줄에도, 터미널에도, 대화창에도, 다른 편집기에도 여기저기서 튀어나온다는 것이다.

한 가지를 못 박는다. 한 번의 프롬프트로 앱이 완성되거나 문제가 풀린다고 믿는 사람이 아직 있는데 그렇지 않다.

값 이야기도 붙는다. 바탕과 도구에 지출은 큰데 아직 그만큼 거두지 못하고 있다며 토큰 씀씀이를 조심하라고 말한다.

2. 세 갈래로 나눈다

지금 있는 에이전트를 셋으로 나눈다.

무엇을 어디에 맡기나

가운데 것을 설명하며 *작업칸을 가지를 폴더 하나에 따로 떼어 붙인 것이라고 풀어 준다.

나누는 기준이 뚜렷하다. 시험은 코드 안에서 무슨 일이 벌어지는지 알고 싶으니 곁에 붙고, 화면은 어떻게 만들든 크게 상관없으니 맡기고, 문서는 손대고 싶지 않으니 바깥에 맡긴다.

3. 묻지 않게 두되 한 자리에서 멈추기

시연은 간단한 파이썬 앱에서 시작한다. 티켓 하나를 두고 간추리고 어떻게 할지 계획하라고 시킨다.

여기서 켜는 것이 도구를 부를 때마다 묻지 않는 모드다. 그러면서 그 자리에서 경고한다. 좋기도 하고 아주 위험할 수도 있으니 알아서 쓰라는 것이다.

그래서 붙이는 조건이 이 절의 요점이다. 시작은 하되 PR을 올리기 직전에 멈추고 내가 돌려 보게 하라.

그러고 새 대화를 열어 바깥 쪽에는 저장소를 오픈소스답게 정비하라고 시키고, 곁에 두는 쪽에는 시험을 쓰라고 시킨다. 셋이 동시에 도는 상태가 된다.

시험이 통과한 뒤 오류 처리가 부실한 것을 발견해 그것까지 고치게 한다.

정직한 대목이 하나 나온다. 뒤에서 돌던 쪽이 알려 준 시험 방법이 틀렸다. 그래서 직접 그 작업칸으로 가서 앱을 띄우는데 포트가 겹치는 문제까지 겪는다.

닫는 정리는 이렇다. 한 저장소, 세 문제, 세 갈래가 동시에 고쳤다.

4. 바깥에서 도는 쪽의 안전장치

바깥 쪽이 왜 그나마 안심되는지를 든다. 갇힌 자리에서 돌고, 나갈 수 있는 곳이 목록으로 묶여 있으며, 주 가지에 직접 밀지 못한다.

대신 쓸 수 있는 것도 붙는다. 저장소를 다루는 도구와 브라우저를 조종하는 도구가 붙어 있어 화면을 갈무리하며 시험할 수 있다.

5. 한자리에서 챙기기

편집기 안의 설정 하나에서 에이전트와 스킬과 지침과 프롬프트와 도구 서버를 모아 본다고 보인다. 거기에 다른 회사 것도 함께 걸려 있다는 점을 짚는다.

여기서 한 줄이 지나간다. 스킬은 예전 방식의 새 판이라는 것이다.

그리고 이 개념들이 한 제품에만 해당하는 게 아니라 다른 에이전트에도 그대로 통한다고 되풀이한다. 모아 둔 오픈소스 모음과 그것을 도구 서버로 감싼 것을 소개하며 닫는다.

6. 발표가 밝히지 않은 것

라이브로 못 하고 녹화로 대신했다. 시간이 모자랄 것 같다며 영상으로 넘긴다고 밝힌다.

잰 값이 하나도 없다. 셋을 동시에 굴려 얼마나 빨라졌는지, 값이 얼마나 들었는지가 없다. 토큰을 조심하라고 말해 놓고 이 방식이 얼마나 쓰는지는 안 댄다.

틀린 안내가 얼마나 잦은지 없다. 맡긴 쪽이 잘못 알려 준 일이 한 번 나오는데, 그런 일이 얼마나 자주 있는지가 안 나온다.

묻지 않는 모드의 사고 사례가 없다. 위험할 수 있다고만 하고 실제로 무엇이 잘못될 수 있는지가 없다.

시연이 아주 작은 앱이다. 만들고 읽고 고치고 지우는 정도의 앱에서 셋을 굴린 것이라, 큰 저장소에서도 같은지가 안 나온다.

자막이 모델 이름을 뭉갠다. 고른 모델의 판 번호가 어긋나 있어 정확한 표기는 원문에서 갈린다.

1. 무엇이 달라졌나

앤트로픽 기술 스태프인 발표자가 지난 몇 달을 보안 팀들과 함께 취약점을 찾고 고치는 데 썼다고 말한다. 자막이 이름 뒷부분을 뭉갠다.

먼저 모델 쪽 추세를 든다. 모델이 얼마나 긴 작업을 해내는지 사람과 견줘 재는 벤치마크에 사이버보안 판이 있고, 영국 AI 보안 연구소가 그것을 갖고 있다. 대상 시스템의 약점을 찾아 파고드는 과제라 역공학이나 웹 공격 같은 능력을 본다. 이 그림에서 모델이 점점 더 긴 보안 과제를 해내고 있으며, 앞선 회귀선에 견주면 한 계단 뛴 자국이 보인다고 말한다.

다음이 파이어폭스다. 모질라가 달마다 만든 보안 버그 수정 건수를 공개했는데 2025년 평균이 20건대였다. 2월과 3월에 60~70건으로 세 배가 되고 4월에 400건으로 일곱 배가 됐다. 4월 수치는 작년 평균의 20배다. 모질라는 이 증가분의 3분의 2쯤을 특정 모델 덕으로 돌렸다. 자막이 모델 이름을 뭉개 어느 판인지 원문에서 갈린다.

발표자는 청중에게 로그4쉘을 기억하느냐고 묻는다. 자바 로깅 라이브러리의 버그라 공격자가 문자열 하나를 로그에 남기면 시스템에서 코드가 돌았다. 벨기에 국방부가 며칠 만에 뚫렸고 한 핀테크에서 200만 명 데이터가 샜다. 그 전에는 오픈SSL의 하트블리드가 있었다.

자기네가 한 일도 낸다. 오픈소스 저장소 1,000곳 넘게 훑어 후보 2만 3천 개를 얻었고, 그중 6,200개가 높음 또는 치명으로 매겨졌다. 갱신 시점에 1,600개를 유지관리자에게 알렸고 100개쯤이 업스트림에서 고쳐졌다. 이제 취약점을 찾는 일 자체는 꽤 쉬워졌다는 것이 여기서 나온 관찰이다.

무엇이 그 문턱을 낮췄느냐는 물음에는 두 낱말로 답한다. *에이전틱 하네스다. 모질라를 다시 인용하는데, 초기 실험은 가능성만 보이고 오탐이 많아 넓히기 어려웠는데 보안 이슈를 안정적으로 잡아내는 하네스가 들어오면서 그것이 바뀌었다는 것이다.

2. 여섯 걸음은 무엇인가

여러 팀과 일해 보니 대체로 여섯 걸음으로 모이더라고 말한다. 앞 둘이 셋업이고 뒤 넷이 도는 고리다.

셋업 둘은 코드베이스마다 미리 들이는 품이다. 하나는 *위협모델이고 하나는 샌드박스다.

고리 넷은 이렇다. 발견이 취약점을 집어내고, 검증이 그것이 진짜인지 확인하고, 분류가 개발자가 붙을 열댓 개로 좁히고, 패치가 고친다.

설명은 주문 서비스 하나로 관통한다. 아이디를 넣으면 주문을 찾아 주는 가상의 시스템이다.

3. 앞 둘이 뒤 넷을 좌우한다

위협모델은 코드베이스나 시스템을 놓고 그리는 설계도인데, 무엇이 위협 벡터인지, 그러니까 어떤 취약점을 신경 써야 하는지를 정해 준다.

발표가 낸 진양성률 값

셋 다 발표자가 말로 댄 값이고 어떤 표본에서 어떻게 쟀는지는 밝히지 않는다.

한 CISO의 말을 옮긴다. 모델은 코드에 대한 맥락은 훌륭한데 시스템에 대한 맥락은 빈약하다는 것이다.

위협모델을 처음 만드는 방법도 준다. 문서와 코드는 물론 지난 커밋과 지난 패치, 그 패치가 무슨 CVE를 막은 것인지까지 모델에 열어 주고, 아직 안 막힌 CVE가 무엇일지 짚어 보게 한다. 그다음에 모델더러 그 시스템을 아는 사람을 인터뷰하게 한다. 계획에 없던 일로 무엇이 일어날 수 있는지, 반대로 무엇은 안 걱정해도 되는지를 묻는 것이다. 주문 서비스의 위협모델에서는 지켜야 할 것이 고객 개인정보가 든 데이터고 들어오는 문이 주문 API이며, 모델은 SQL 인젝션과 인증 없이 API를 부르는 길을 위협 벡터로 짚었다.

샌드박스는 둘을 준다. 격리와 재현이다. 격리는 데이터가 새거나 운영 환경이 더럽혀지는 것을 막는 자리라 바깥으로 나가는 통신도 클라우드 자격증명도 없는 가상머신에서 돌린다. 재현은 모든 에이전트가 같은 기준 컨테이너에서 출발하게 하는 것이다. 함께 일한 한 팀은 가장 큰 지렛대가 실제 시스템을 올린 샌드박스였다고 말했다. 거기서 개념증명을 실제로 터뜨려 진짜인지 확인할 수 있기 때문이다. 주문 서비스 샌드박스는 도커 이미지 셋을 이어 붙인 것이다. 앱, 포스트그레스, 캐시 하나씩이고, 보안 에이전트는 대상 경계 밖에 앉아 HTTP로 앱을 찔러 본다.

4. 고리 넷이 도는 법

발견에서 중요한 것 셋을 꼽는다. 맥락을 어떻게 넣느냐, 프롬프트를 얼마나 단순하게 쓰느냐, 도구를 주느냐다. 적어서 모델에 건네면 모델이 그것을 찾아낸다는 것이 첫째다. 둘째는 반대 방향이다. 새 모델이 나올 때마다 프롬프트를 절반쯤 줄여야 했다고 말한다. 요즘 모델에는 신뢰되지 않은 데이터가 신뢰 경계에 닿는 자리를 찾으라고만 해도 알아서 짚는다. 셋째가 앞 표의 마지막 줄이다.

주문 서비스의 조회 API는 다섯 줄인데, 발견 에이전트가 넷째 줄을 짚었다. 파이썬 문자열을 이어 붙여 SQL 질의를 만드는 자리라 사용자가 넣은 값이 곧장 질의로 흘러든다.

발견과 검증은 최적화하는 것이 다르다고 말한다. 발견은 재현율을 올리고 검증은 정밀도를 올린다. 그래서 검증 에이전트는 독립적이고 적대적이어야 한다. 독립은 발견 에이전트가 남긴 추론 자국을 안 본다는 뜻이고, 적대는 이 취약점이 가짜라고 가정하고 가짜임을 확인하려 든다는 뜻이다. 발견 에이전트가 제 일을 스스로 검증하면 자기 검열이 들어가 재현율을 깎는다.

주문 서비스에서 검증 에이전트는 넷째 줄이라는 위치만 받고 새 컨테이너에서 curl 한 줄을 날려 고객 개인정보가 빠져나오는 것을 눈으로 확인한다.

분류는 참인 것 중에서 고를 것을 고르는 자리다. 실제로 발동하지만 사업에 미치는 영향이 낮은 정확성 문제도 섞여 있다. 여러 팀이 같은 말을 했다고 한다. 참인 취약점을 중간·낮음까지 다 제품 엔지니어에게 보내면 그 엔지니어들이 감당을 못 해 신뢰를 잃는다는 것이다. 그래서 중복을 걷어내고, 터졌을 때의 크기와 실제로 일어날 만한지를 함께 본다. 공격자가 몇 단계를 거쳐야 하는지가 뒤쪽 기준이다. 방화벽 같은 보완 통제가 있으면 처음에 높음이던 것이 낮아지고, 반대로 데이터베이스에 고객 개인정보나 의료 데이터가 몰려 있으면 모델이 중간으로 매긴 것이 실제로는 높음이 된다. 주문 서비스에서는 에이전트가 높음으로 봤는데, 사람이 보고 낮음으로 내렸다. 애플리케이션 방화벽이 SQL 인젝션을 막고 있고 이 서비스가 안쪽 전용이라 인터넷에 안 붙어 있다는 이유다.

패치가 고리를 닫는다. 고친 뒤 확인하는 사다리가 있고, 패치 에이전트에 그 결과를 돌려주면 패치 품질이 크게 올라간다고 팀들이 밝혔다고 한다. 발표자는 이것을 생성적 검증자 고리라고 부른다. 병합 전에는 사람이 본다.

주문 서비스의 패치는 두 덩이다. 첫 덩이는 변수를 파이썬 문자열 밖으로 빼는 한 줄짜리 수정이다. 둘째 덩이가 고리를 닫는 자리인데, 코드만 고치는 것이 아니라 보완 통제를 적어 둔다. 방화벽이 막고 있고 안쪽 전용이라는 사실을 남겨 다음 스캔에서 같은 것이 다시 올라오지 않게 한다.

고리를 안 닫으면 이 일이 매달 나가는 운영비인데, 닫으면 한 번 쌓아 두고 쓰는 자산이 되어 돌릴 때마다 나아진다고 말한다.

5. 진짜 병목은 사람 쪽이다

앞 전임 상사의 말을 옮긴다. 기술적이지 않은 문제가 기술적인 문제보다 한 자릿수 어렵다는 것이다.

들어오는 양이 열 배 백 배가 되면 하네스 쪽은 엔지니어링을 더 하고 컴퓨트를 더 쓰고 돈을 더 내면 된다. 돈으로 풀리는 것은 진짜 문제가 아니라고 말한다. 사람 주의력은 그렇게 안 늘어난다.

구체적인 자리를 셋 든다. 하나는 심각도 합의다. 제품 엔지니어와 보안 엔지니어가 무엇이 높음이고 치명인지에서 갈릴 수 있고, 이것은 사업 맥락이 많이 드는 일이다. 한 방에 몰아넣고 규칙을 적어 모두가 같은 것을 보게 만들어야 한다. 위협모델도 지금은 다 사람들 머릿속에 있으니 모델이든 사람이든 누군가 인터뷰해서 적어 내려야 한다.

둘은 어디로 보내느냐다. 한 달에 열댓 건이면 손으로 골라 메일을 돌리고 지라 티켓을 붙일 수 있는데 수백 건이면 못 한다. 이 일은 코드 주인이나 서비스 주인에게 보내는 정도로 단순해질 수 있고 굳이 언어 모델이 낄 자리가 아니라고 말한다.

셋은 고치는 손이다. 취약점을 받아 놓고 패치를 짜는 일은 모델의 도움을 받아도 여전히 어렵다. AI가 만든 패치 쪽으로 가되 사람이 고리 안에서 확인하라고 말한다. 완전 자동 패치 검토까지 간 회사는 아직 많이 알지 못한다고 덧붙인다.

기억할 것 셋으로 발표를 닫는다. 오픈소스 의존성부터 시작할 것, 자동화를 바로 노리지 말고 손을 얹은 채 배울 것, 스캐닝을 목표로 삼지 말 것이다. 병목은 검증과 분류와 패치, 그리고 조직의 절차라는 것이다. 마지막에 자기네 도구와 블로그, 대화형 스킬과 자율 하네스가 든 오픈소스 저장소를 소개하며 다섯째 걸음의 하네스를 가져다 고쳐 쓰라고 말한다.

6. 발표가 밝히지 않은 것

값의 출처가 얇다. 진양성률 90%도, 도구를 준 팀의 거의 100%도 표본이 얼마이고 무엇을 정답으로 놓고 잰 것인지 대지 않는다. 오탐이 준 만큼 놓친 것이 늘지는 않았는지, 그러니까 재현율 쪽이 어떻게 됐는지는 아예 나오지 않는다.

자기네 스캔 결과도 앞쪽만 있다. 후보 2만 3천에서 고·치명 6,200으로 좁힌 기준이 무엇인지, 알린 1,600건 중 100건만 고쳐진 나머지 1,500건이 어떤 상태인지가 없다. 유지관리자 쪽에서 무엇이 걸렸는지가 이 이야기의 절반인데 발표는 그 자리를 다루지 않는다.

파이어폭스 숫자도 남의 발표에서 온 것이다. 4월 400건이 무엇을 센 것인지, 심각도 분포가 어떻게 되는지, 3분의 2를 모델 덕으로 돌린 근거가 무엇인지는 이 발표에 없다.

비용도 없다. 저장소마다 위협모델을 만들고 샌드박스를 세우는 데 드는 품, 발견과 검증을 따로 돌리는 데 드는 컴퓨트가 얼마인지 나오지 않는다. 돈으로 풀리는 것은 문제가 아니라는 말이 그 자리를 대신한다.

발표자가 스스로 밝힌 한계는 하나다. 보안 이슈를 고칠 때 패치 검토까지 완전히 자동으로 돌린 회사를 많이 알지 못한다는 것이다.

1. 프롬프트에서 정보 설계로

그래프 데이터베이스 회사에서 개발자 쪽을 맡는다는 사람이 발표한다.

여는 진단이 이렇다. 한 번의 영리한 문구로 결과를 바꾸던 데서 더 넓고 움직이는 것을 모델에 넣어 주는 쪽으로 옮겨 가고 있다는 것이다.

문제도 짚는다. 맥락 창은 커졌는데 정작 중요한 자리에 눈길이 안 간다.

그래서 세우는 말이 이것이다. 프롬프트 짜는 사람이 아니라 정보를 설계하는 사람처럼 생각하라.

다루는 범위로 넷을 든다. 프롬프트, 밖에서 찾아와 붙이기, 상태와 이력, 그리고 나오는 모양을 잡아 주는 것이다.

기억은 둘로 나눈다. 지금 하는 일을 눌러 담는 짧은 쪽과, 여러 대화에 걸쳐 배운 것에서 뜻과 구조를 뽑아 두는 긴 쪽이다. 짧은 쪽에는 단서가 붙는다 — 도구가 쏟아 낸 것을 지난 것까지 너무 많이 넣지 말라.

2. 지식그래프가 무엇인가

*지식그래프를 사람·자리·일·물건을 나타내는 마디와 그 사이의 관계로 설명한다. 마디에는 속성을 붙일 수 있고 임베딩도 거기 붙일 수 있다고 말한다.

깔아 두는 한 줄이 있다. 넣는 자료가 나쁘면 나오는 답도 나쁘다.

3. 그래프를 검색에 끼운다

정의는 넓게 잡는다. 찾아오는 과정에 그래프를 쓰면 다 여기에 든다.

닮은 것만 골라 오는 것보다 나은 이유로 관계와 무리 짓기 같은 것을 함께 쓰기 때문이라고 말한다.

값나가는 대목이 하나 더 있다. 모델에 넘어간 대목이 그래프에 남으니 왜 그렇게 답했는지 되짚을 수 있다.

권한 이야기도 실용적이다. 누가 보느냐에 따라 다른 것만 보이게 그래프에 얹을 수 있다며, 진료 기록에서 의사는 진단을, 행정 담당자는 연락처만 보게 하는 예를 든다.

4. 시연 둘

올려 둔 자료는 공급망 문서 하나와 어느 자바 라이브러리의 취약점과 영향받는 판, 고친 자리가 담긴 보안 문서 하나다. 넣으면 모델이 알아서 그래프를 지어 준다.

첫 시연은 닮은 것을 찾고 그 옆을 한 번 더 보는 방식이다.

여기서 사고가 난다. 그래프에 없는 라이브러리를 물어 거절이 나오길 기대했는데, 발표자가 이름을 잘못 말했다. 오타였다고 그 자리에서 밝힌다. 결국 거절하는지 보려던 시험은 실제로 돌지 않았다. 대신 모델이 사람 실수를 알아서 바로잡아 원래 라이브러리 정보를 끌어냈다.

둘째 시연은 코딩 에이전트에 그래프 질의 도구를 붙여 스스로 캐묻게 한 것이다. 순서가 눈에 띈다 — 먼저 그래프의 구조를 물어 파악한 뒤 질의를 여러 번 던지고, 마디에 달린 글 조각까지 끌어온다.

발표자가 직접 대는 비교가 이렇다. 앞의 방식은 비교적 빨랐지만 자세함이 제한적이었고, 뒤의 방식은 번호와 공격 유형과 심각도와 설명, 그리고 어느 판으로 올려야 하는지까지 내놓았다.

5. 언제 값을 하나

발표가 대는 선

찾아오는 방식도 셋으로 나눈다. 미리 짜 둔 질의를 입구로 쓰는 것, 구조를 익혀 물음마다 질의를 지어내는 것, 그리고 답이 될 때까지 되풀이해 그래프를 도는 것이다.

6. 기억으로 쓰기

같은 것을 기억에도 쓴다고 말한다. 마디에 글과 임베딩과 시간과 자리 같은 속성을 붙여 두고, 가까운 것 찾기나 무리 짓기나 중요도 매기기 같은 셈으로 가장 관련 있는 것을 위로 끌어올린다.

예로 든 물음이 구체적이다. 지난번에 누구와 함께 발표했던 자료를 고쳐 달라는 것이다. 그러면 사람 둘과 그 행사와 언제였는지까지 찾아 맥락으로 넘긴다.

에이전트 자체를 들여다보는 데도 쓴다고 말한다. 대화가 어떻게 흘렀는지 그려 보고, 성능 자료를 뜯어 고칠 자리를 찾고, 겹치는 마디를 지워 품질을 올린다.

7. 발표가 밝히지 않은 것

잰 값이 하나도 없다. 앞의 방식이 얼마나 빨랐고 뒤의 방식이 얼마나 느렸는지가 없다. 자세함도 두 답을 눈으로 견준 것뿐이다.

거절 시험이 실제로 안 돌았다. 발표자가 이름을 잘못 말해 원래 보려던 것 — 그래프 밖 물음을 거절하는지 — 을 못 보였다.

시연이 한 물음씩이다. 두 방식 다 물음 하나에 대한 답으로 견줬다.

자료가 문서 둘이다. 큰 그래프에서도 같은 방식이 되는지, 그때 캐묻는 횟수가 얼마나 늘어나는지가 없다.

그래프를 짓는 값이 없다. 모델이 알아서 지어 준다고만 하고, 잘못 지었을 때 어떻게 되는지와 손보는 품이 얼마인지가 없다.

뒤가 자기 제품 안내다. 무료 강의, 컨퍼런스, 커뮤니티 사이트를 잇달아 소개하며 닫는다.

자막이 회사·도구 이름을 크게 뭉갠다. 회사 이름부터 질의 언어 이름까지 여러 군데 어긋나 있어 정확한 표기는 원문에서 갈린다.

1. 관계는 벡터가 못 잡는다

엔비디아에서 개발자 애드보킷 팀을 이끄는 사람이 발표한다. 그 팀이 하는 일은 여러 쓰임에 맞는 작업 흐름과 노트북을 만들어 깃허브에 내놓는 것이라고 밝힌다. 이 발표는 파트너 한 곳, 그리고 사내 동료들과 함께한 프로젝트를 다룬다. 파트너사 이름은 대지 않는다.

지식그래프를 사람·자리·개념·사건 같은 것들 사이의 관계를 나타내는 그물로 정의한다. 자기를 예로 든다. 자기와 이 행사의 관계는 발표자이고, 자기와 청중의 관계는 이 자리에 들어왔다는 것이다.

벡터로 닮은 것을 찾는 방식보다 나은 까닭을 여기서 댄다. 개체 사이에 무엇이 오갔는지를 훨씬 자세히 붙잡고, 여러 곳에서 온 자료를 한 자리에 엮을 수 있다는 것이다.

2. 트리플 하나가 이렇게 생겼다

지식그래프를 짓는 일의 핵심은 *트리플을 뽑아내는 것이라고 말한다.

예로 든 것은 어느 정유 회사의 분기 실적 문서다. 짜여 있지 않은 글에서 이런 것을 뽑아내는 일이 어렵다는 것을 그 자리에서 인정한다. 그래서 거대언어모델에 시켜 글을 트리플 꼴로 바꿔 쌓는다고 말한다.

3. 온톨로지에 시간의 80%

무엇을 개체로 보고 무엇을 관계로 볼지 미리 정해 둔 틀이 *온톨로지다. 쓰임에 맞게 이것을 먼저 정하고 프롬프트에 넣어 모델에게 뽑으라고 시킨다.

여기서 이 발표에서 가장 값나가는 한 줄이 나온다. 온톨로지가 틀리면 트리플이 틀리고, 트리플이 지저분하면 찾아오는 것도 지저분해진다. 그래서 이 자리를 바로잡는 데 전체 시간의 80%를 쓰게 될 것이라고 말한다.

4. 만드는 판, 그리고 몇 칸까지 건너갈까

벡터 쪽은 비교적 곧고 이미 많이 다뤄진 자리라고 말한다. 문서를 골라 조각으로 자르고 벡터로 바꿔 쌓으면 된다. 자를 때 조각끼리 겹치는 폭을 두는 까닭도 짚는다. 겹치는 데가 없으면 앞 조각과 뒤 조각 사이의 맥락이 사라진다.

그래프 쪽은 손이 훨씬 많이 간다고 말한다. 다 지은 뒤에 남는 물음이 하나 더 있다. 물어볼 때 관계를 몇 칸이나 건너갈 것인가, 곧 *홉을 얼마나 깊이 잡을 것인가다.

홉을 깊이 잡을 때와 얕게 잡을 때

프로덕션에서는 이 둘 사이에서 자리를 잡아야 한다고 말한다. 그래프를 도는 일 자체를 빠르게 하려고 팀이 라이브러리를 하나 만들었고, 널리 쓰이는 그래프 라이브러리를 통해 쓸 수 있다고 소개한다. 성능을 재 봤더니 전체 걸리는 시간이 크게 줄었다고 말하는데, 얼마나 줄었는지 수는 대지 않는다.

5. 71에서 87로

여기서 80과 20을 다시 든다. 그래프 RAG를 처음 굴러가게 하는 데는 시간의 20%면 되고, 쓸 만하게 다듬는 마지막 20%에 시간의 80%가 든다는 것이다. 파트너와 함께한 실험이 그 마지막 20%에서 나왔다.

먼저 자료를 손질했다. 아포스트로피나 괄호처럼 뜻에 보태지 않는 글자를 걷어냈더니 결과가 나아졌다. 답이 길게 늘어지지 않게 줄인 것도 도움이 됐다고 말한다.

그다음이 파인튜닝이다.

트리플 추출 정확도

이 값을 대면서 바로 단서를 단다. 문서 백 개로 잰 것이라 높게 보이는 것이고, 문서가 늘면 내려갈 거라는 말이다. 그래도 전보다 나아진 것은 분명하다고 덧붙인다.

무엇으로 재느냐도 짚는다. 신뢰도와 답변 관련성, 정밀도와 재현율, 도움이 되는지, 앞뒤가 맞는지 같은 것을 든다. 도구로는 질의와 찾아오기와 답을 한 줄에 걸쳐 재 주는 라이브러리 하나를 소개하고, 다른 길로는 남의 모델이 낸 답을 다섯 항목으로 채점하도록 훈련한 리워드 모델을 든다.

6. 언제 그래프를 쓰나

답을 「경우에 따라 다르다」로 열고 두 가지로 나눈다.

하나는 자료다. 소매나 금융이나 사내 인사 자료처럼 원래 짜임새가 좋은 자료가 그래프에 잘 맞는다. 짜여 있지 않은 자료라도 거기서 쓸 만한 그래프를 뽑아낼 수 있다면 해 볼 만하다고 말한다.

다른 하나는 쓰임이다. 물음에 답하려면 얽힌 관계를 알아내야 하는 경우에만 그래프를 쓰는 뜻이 있다는 것이다.

마지막에 단서를 하나 더 단다. 그래프로 짠 것은 연산을 많이 먹는 시스템이고, 그것을 감당할 수 있는지부터 따져야 한다는 말이다.

7. 발표가 밝히지 않은 것

87%가 무엇을 맞힌 비율인지 없다. 뽑아낸 트리플이 맞았다고 누가 어떻게 판정했는지, 틀린 쪽은 어떻게 틀렸는지가 나오지 않는다.

파트너사 이름이 없다. 함께 실험한 곳이 어디인지, 그쪽 자료가 무엇이었는지가 없다.

가속 라이브러리 수치가 없다. 걸리는 시간이 크게 줄었다고만 하고 얼마에서 얼마로 줄었는지가 없다. 어느 알고리즘에서 그랬는지도 없다.

평가 도구를 이 프로젝트에 실제로 썼는지 없다. 라이브러리와 리워드 모델을 소개하지만, 71%와 87%를 그것으로 잰 것인지는 밝히지 않는다.

그래프를 짓고 다시 짓는 값이 없다. 연산을 많이 먹는다고만 하고, 문서가 늘 때 다시 짓는 품이 얼마인지가 없다.

자막이 이름과 판을 크게 뭉갠다. 팀이 만든 가속 라이브러리 이름이 엉뚱한 낱말로 들리고, 리워드 모델은 이름이 뭉개진 데다 같은 설명 안에서 크기가 3억 4천만과 3400억으로 갈린다. 파인튜닝한 라마 판도 3.3과 3.2와 3.1로 오간다. 정확한 표기는 원문에서 갈린다.

1. 매일 잊는 비서

그래프 데이터베이스 회사에서 개발자 쪽을 맡는 사람이 발표한다. 게 캐릭터를 내세워 이야기를 끌고 간다.

문제를 이렇게 그린다. 이 비서는 도구가 많아도 상황에 맞는 것을 못 고를 때가 있고, 무엇보다 하루가 지나면 기억 파일이 갈리며 어제 한 일을 통째로 잊는다. 그래서 같은 일을 날마다 다시 가르치게 된다.

에이전트가 도는 방식을 기억 고리로 본다. 시키고, 무엇이라 답할지 생각하고, 도구를 부르고, 무슨 일이 벌어졌는지 본다. 그러면서 못 박는다. 어려운 것은 기억이다 — 무엇을 맥락에 넣고 무엇을 불러올지다.

2. 기억이 전부 마크다운이면

요즘 에이전트들의 기억 구조를 늘어놓고 공통점을 짚는다. 전부 마크다운 파일이다.

그 형식이 나쁘다는 것은 아니다. 사람이 읽기 쉽고 일부러 작게 만든다 — 맥락 창이 한정돼 있고 중요한 것을 위쪽에 둬야 하기 때문이다.

문제는 규모다. 기억이 전부 그런 파일 뭉치면 토큰을 크게 버린다. 자기가 굴리는 에이전트들이 한 라운드에 최소 10만 토큰을 불러온다고 밝힌다. 쓸모가 있을까 싶어 일단 다 넣기 때문이고 그래서 겹치는 것투성이라는 것이다.

작은 규모에서는 좋은 모델을 쓰면 원하는 결과가 나온다고 인정한다. 안 되는 것은 큰 규모다.

3. 스킬도 사슬이다

스킬 역시 마크다운 파일이라며 다른 실패를 짚는다. 필요한 스킬이 없으면 못 하고, 엉뚱한 스킬을 고르면 엉뚱한 일을 한다.

한 줄이 재미있다. 조개를 여는 스킬이 있어도 먹는 스킬이 없으면 소용없다. 그러니 맞는 스킬들이 순서대로 이어져야 한다.

여기서 스킬 사이 관계를 그래프로 적어 두려는 동료의 연구를 든다.

다른 도구도 사정이 같다고 말한다. 어느 것은 기억을 또 하나의 도구 서버처럼 다뤄 불러오고 저장하고 지운다. 그런데 결국 디스크의 평범한 파일이고, 그래서 좋은 생각에 같은 근본 문제가 남는다. 위험도 하나 짚는다 — 도구가 있으니 잊으라는 명령을 잘못 불러 기억을 통째로 날릴 수 있다.

4. 벡터만으로 안 되는 이유

닮은 것으로 찾는 방식의 한계를 두 가지로 짚는다.

하나. 벡터 공간에서 가깝다는 것이 실제 관계와 같지 않다. 그래서 지어내는 일이 생긴다.

둘. 사실을 다 갖고 있어도 여러 칸을 건너야 답이 되는 물음은 안 풀린다. 이 대목에서 *멀티홉이라는 말이 나온다. 관계형 저장소에서도 그런 사슬은 값이 크다고 덧붙인다.

5. 씨앗은 닮은 것으로, 나머지는 관계로

그래서 짠 구조가 이것이다. 닮은 것 찾기로 시작할 마디를 잡고, 거기서 옆에 붙은 것을 끌어와 얼마나 얽혔나로 순위를 매긴다.

얻는 것도 짚는다. 어느 마디가 뽑혀 맥락에 들어갔는지 보이니 왜 그렇게 답했는지 되짚을 수 있고, 뽑는 방식을 고치거나 겹치는 마디를 줄여 빠르게 나아질 수 있다.

그래프에 익숙하지 않아도 된다고 말한다. 질의를 모델이 자기보다 잘 쓴다는 것이다.

6. 같은 원본, 두 저장소

이 발표에서 가장 정직한 설계다. 같은 원본 마크다운에서 출발해 두 벌을 만들었다. 한쪽에는 벡터만, 한쪽에는 그래프를 붙였다.

대상은 자기 집 서버들이다. 따로 떼어 낸 망에 올려 두었고 기억으로만 답하게 했다 — 실시간으로 기계를 조회하지는 못한다.

물음 다섯 개를 준비했다고 하고 둘을 보인다.

같은 물음, 두 답

그리고 한마디를 덧붙인다. 발표 뒤에 그 구멍들을 다 막았다. 실제로 뚫려 있던 자리였다는 뜻이다.

닫는 주장은 이렇다. 자기 집은 서버 서너 대지만, 큰 데이터센터를 가진 곳이나 회사와 고객 기록이 방대한 곳처럼 요즘 모델의 맥락 창에도 안 들어가는 규모라면 파일에 던져 두는 것보다 나은 기억 장치가 필요하다는 것이다.

7. 발표가 밝히지 않은 것

대조의 규모가 아주 작다. 서버 서너 대에 물음 둘을 보였다. 큰 규모에서 필요하다는 주장을 작은 규모의 시연으로 받치고 있다.

잰 값이 없다. 어느 쪽이 얼마나 빨랐는지, 값이 얼마나 들었는지가 없다. 10만 토큰은 문제를 그리는 수이지 고친 뒤의 값이 아니다.

벡터 쪽 설정이 어땠는지 없다. 무엇을 어떻게 넣었느냐에 따라 그쪽 답도 달라질 텐데, 두 벌을 얼마나 공평하게 맞췄는지가 나오지 않는다.

다섯 중 둘만 보인다. 나머지 셋에서 어땠는지가 없다.

그래프를 만드는 값이 없다. 원본에서 마디를 뽑아내는 일이 얼마나 걸리고 얼마나 틀리는지가 안 나온다.

뒤가 자기 쪽 안내다. 무료 강의와 책 소개로 닫는다.

자막이 이름을 여러 군데 뭉갠다. 서버 이름이 두 번 다르게 나오고 도구 이름도 어긋나서, 정확한 표기는 원문에서 갈린다.

1. 물음에 답하는 것으로는 모자란 자리

그래프 데이터베이스 회사에서 일하는 사람이 발표한다. 기술 마케팅에 있다가 최근 연구 엔지니어링 쪽으로 옮겼다고 밝힌다. 회사 소개는 정보를 잇고 추려서 AI 시스템이 더 정확해지고 왜 그렇게 답했는지 짚을 수 있게 돕는다는 것이다.

청중에게 두 번 손을 들게 한다. 컨텍스트 그래프를 들어 봤는지, 그런 그래프로 직접 코드를 짜 봤는지다. 둘 다 절반쯤이었다.

세우는 갈림점이 이렇다. 검색해서 붙이는 지식 베이스는 물음에 정확히 답하도록 돕는다. 컨텍스트 그래프가 거기 더하는 것은 더 나은 결정을 내리는 데 필요한 것이다.

예로 드는 것은 금융 분석 에이전트다. 고객이 얼마를 요청한 사안을 두고 고객 정보와 거래 내역과 정책만 쥐여 주면, 위험 점수를 매기고 검토해 보라고 권하고 위험 요인을 짚는 정도로 답한다. 여기에 지난 결정 흔적과 선례가 붙으면 승인할지 거절할지와 그 까닭까지 답한다는 것이다.

이 말이 어디서 나왔는지도 밝힌다. 어느 벤처캐피털이 지난 12월쯤 꺼냈고, 그 뒤로 결정 흔적과 추론을 남겨 두자는 논의가 시끄러웠다고 말한다.

2. 사실 위에 무엇을 얹나

*시스템 오브 레코드가 다루는 것은 사실과 개체와 지금 상태다. 컨텍스트 그래프는 거기에 선례와 인과 사슬과 예상되는 결과를 얹어, 에이전트가 그 분야를 아는 사람처럼 움직이게 한다는 것이다.

컨텍스트 그래프에 담는 세 갈래

세 번째 갈래에 두 종류가 함께 든다고 짚는다. AI가 남긴 추론과, 예전에 결정을 내린 직원들이 남긴 것이다.

3. 데모가 도는 순서

데모에 쓴 자료는 고객관리 시스템과 고객지원 시스템 같은 데서 자료를 받아 오는 상황을 흉내 내 지어낸 것이라고 밝힌다. 돌리는 쪽은 클로드, 임베딩은 오픈AI, 자료와 벡터는 자기 회사 데이터베이스, 앞단은 넥스트js다. 인터넷 연결을 못 믿겠다며 이 데모는 녹화로 대신 보인다.

선례 찾기 단계만 따로 이름을 붙여 설명한다. 그래프 안의 구조를 살펴 인과 사슬로 서로 이어진 자리를 끌어온다는 것이다. 결정 흔적들이 그 사슬로 겹겹이 쌓인다고 말한다.

여기서 두 가지를 함께 쓴다. 벡터 인덱스로 「사기 거절」 같은 말을 뜻으로 찾고, 거기에 그래프 안에서 얼마나 비슷한 자리에 있는지를 겹쳐 본다. 뒤쪽을 가능하게 하는 것이 *그래프 임베딩이다. 앞서 보여 준 마디들이 서로 이어진 모양을 통째로 벡터로 만든 것이고, 그래서 닮은 결정 흔적을 벡터 유사도로 찾을 수 있다고 말한다. 이 임베딩은 회사의 그래프 데이터 사이언스 도구로 만든다.

4. 명령 한 줄로 뼈대를 짓는다

정작 오늘 보이고 싶었던 것은 한 달쯤 전에 나온 다른 도구라고 말한다. 사내 프로덕트 매니저 한 사람이 만들었고, 터미널에서 명령 한 줄로 컨텍스트 그래프와 앞단과 뒷단을 갖춘 앱을 통째로 만들어 준다. 리액트나 넥스트의 뼈대 생성기에 견준다.

시연에서 지정한 것은 앱 이름과 도메인과 쓸 프레임워크다. 그러면 더미 자료가 담긴 픽스처 파일들과 함께 폴더가 만들어지고, 설치하고 자료를 심어 띄우기까지 몇 분 걸린다. 그 몇 분을 기다리는 중에 소리가 끊겨 청중에게 들리느냐고 되묻는 대목이 그대로 남아 있다.

완성된 화면에서는 처방약을 물어 답을 받아 오고, 스키마 그림과 여러 흔적을 함께 볼 수 있다. 물음이 들어오면 *사이퍼로 자료를 찾아 온다.

미리 만들어 둔 도메인이 스물두 개고, 시연한 헬스케어 말고 금융서비스도 있다. 직접 도메인을 만들면 *온톨로지를 대신 지어 준다. 지원하는 프레임워크로 파이단틱 AI 외에 오픈AI·랭그래프·크루·스트랜즈·구글 ADK를 든다. 깃허브·노션·지라·슬랙에서 자료를 끌어오는 연결 도구가 있어 데모 자료가 아닌 실제 자료도 넣을 수 있다고 말한다. *MCP 서버를 만들어 주고 앱 안에서 여러 차례 주고받는 대화도 된다. 이제 막 시작한 오픈소스라 누구나 기여할 수 있다고 덧붙인다.

여기부터 발표 끝까지는 자기 회사 것을 권하는 자리다. 블로그와 안내 사이트와 저장소 링크 셋을 잇달아 소개한다.

5. 밑에 깔린 메모리 패키지

이 도구를 떠받치는 큰 의존 하나로 자기 회사 에이전트 메모리 패키지를 든다. 컨텍스트 그래프에는 셋이 다 필요한데 그 패키지가 셋을 맡는다는 것이다.

메모리 패키지가 맡는 셋

글을 그래프로 바꾸는 일은 단계 몇을 거친다고 말한다. 스페이시에서 글라이너로, 더 정교한 쪽으로, 마지막에는 거대언어모델이 받는다. 각 단계가 무엇을 하는지는 발표가 설명하지 않는다. 그 뒤에 병합과 중복 제거와 보강이 따로 붙는다.

스키마는 대화가 있고 거기서 뽑힌 개체들이 추론 흔적으로 이어지는 모양이라고 말한다. 이 패키지가 마이크로소프트 에이전트 프레임워크와 구글 ADK를 비롯한 여러 곳과 붙는다고 덧붙인다.

6. 새 흔적은 누가 써넣나

질의응답이 이 발표에서 가장 정직한 대목이다.

시간 정보를 붙이면 벌어진 순서대로 「원인이 됨」이나 「다음」 같은 관계로 이어진다고 답하면서도, 지금 그렇게까지 되는지는 모르겠다고 그 자리에서 물러선다. 기술이 익으면 될 일이라고 말한다.

미리 만들어 둔 도메인들은 온톨로지가 이미 준비돼 있고, 정해 둔 개체와 관계 종류가 뽑아내기와 맞붙이기를 이끈다고 답한다. 자료가 CSV나 표처럼 이미 짜여 있으면 사이퍼 문으로 그대로 옮기면 되고, 글을 다루는 쪽은 새 프로젝트라 아직 거칠다고 인정한다.

새 결정 흔적을 어떻게 써넣느냐는 물음에는 답이 없다. 지금 데모에서는 저장하라고 시켜야 저장하고, 시키지 않으면 알아서 남기지 않는다. 도구 쪽도 아직 작업 중이라고 밝히면서, 결정에 감정이나 품질 점수 같은 것을 매기는 방식이 필요할지 모르겠다는 생각을 덧붙인다.

7. 발표가 밝히지 않은 것

잰 값이 하나도 없다. 지식 베이스만 줬을 때와 컨텍스트 그래프를 줬을 때의 답을 나란히 놓고 견주는데, 정확도도 지연도 값도 나오지 않는다.

왼쪽 답은 돌려 본 것이 아니다. 지식 베이스만 있을 때 나올 답은 발표자가 대개 이렇게 나온다고 그려 놓은 것이다. 두 벌을 실제로 만들어 같은 것을 물어본 대조가 아니다.

앞의 데모가 녹화다. 인터넷 연결을 못 믿겠다며 녹화로 대신했고, 뒤의 시연에서는 소리가 끊겼다.

그래프를 만드는 값이 없다. 글에서 개체를 뽑아내는 단계가 얼마나 걸리고 얼마나 틀리는지, 손보는 품이 얼마인지가 나오지 않는다.

선례를 잘못 고르면 어떻게 되는지가 없다. 지난 판단을 근거로 승인·거절을 대게 하는 구조인데, 그 판단이 애초에 틀렸을 때 무엇으로 걸러 내는지를 다루지 않는다.

자막이 몇 군데 뭉갠다. 개념을 처음 꺼낸 곳으로 댄 회사 이름과, 미리 정해 둔 개체·관계 틀을 부르는 말이 어긋나 있어 정확한 표기는 원문에서 갈린다.

1. 기초를 데이터라고 부른다

발표자가 자기를 소개하지 않는다. 자막 어디에도 이름과 소속을 밝히는 문장이 없고, 제품을 설명할 때만 「우리」라고 말한다. 화면에 띄운 춤추는 코코넛 영상은 자기 회사 모델로 만들었다고 밝힌다.

여는 말이 이렇다. 생성형 AI가 사업에 값을 더하기는 하는데 「제대로 했을 때」라는 조건이 붙는다는 것이다. 사용자가 앱을 쓰는 방식을 바꿀 만큼 큰 것을 지으려면 그 밑을 봐야 하고, 그 밑이 데이터라고 말한다. 데이터가 회사와 브랜드와 조직을 대신하기 때문이라는 것이다.

자료를 옮기고 싣고 뜯는 일은 여전히 중요하다고 하면서도 더 중요한 것을 따로 든다. 자료가 기술과, 그리고 사람과 어떻게 맞닿아 있느냐다. 아직 자료가 부서마다 따로 놀고 있지 않은지도 묻는다.

2. 앱 셋, 요구가 다르다

데이터 요구가 앱마다 어떻게 갈리는지 셋으로 보인다.

세 앱이 각각 무엇을 필요로 하나

여행 에이전트에 붙는 단서가 있다. 개인에 맞춘 경험은 개인 자료를 요구하고, 그만큼 *PII를 흘리지 않을 책임이 따라온다. 사내 챗봇 쪽은 붙는 자리가 여럿이라는 점을 짚는다. 슬랙에 붙을 수도 있고 따로 만든 앱에 붙을 수도 있으며, 자료도 여기저기 흩어져 있다는 것이다.

3. 매 단계가 데이터다

여행 에이전트로 돌아와 어디까지가 데이터인지 넓힌다. 시스템 프롬프트도 데이터고 사용자가 던진 물음도 데이터다. 상황에 따라 골라 쓰도록 프롬프트를 목록으로 두거나 틀로 만들어 둘 수도 있다고 말한다.

맥락도 더 이상 붙박이가 아니라고 말한다. 그때그때 여러 자료 서비스에서 온다는 것이다. 모델을 손질해 쓰려면 회사를 대신하는 자료가 거기서 또 필요하다.

그래서 못 박는 한 줄이 이렇다. 쓸 만한 답이 나오기까지 모든 단계에 데이터가 들어간다.

4. 여기부터 제품 이름이다

문제를 다 세운 뒤 답으로 자기 회사 플랫폼 하나를 든다. 그다음부터는 챗봇 하나를 예로 삼아 데이터가 지나는 자리마다 제품 이름을 붙인다.

*청킹 이야기는 조금 더 자세하다. 계층으로 자르는 방식과 뜻으로 자르는 방식이 이미 들어 있고, 그것으로 안 되면 자르는 규칙을 직접 짜 넣을 수 있다고 말한다. 임베딩 모델과 벡터 저장소도 고를 수 있고, 자료를 들이는 일과 바뀐 것만 덧붙이는 일은 따로 짜지 않아도 딸려 온다고 한다.

꺼내는 어귀는 둘이다. 하나는 닮은 것을 찾아 오는 쪽이고, 여기에 *하이브리드 검색을 값으로 넘길 수 있다. 다른 하나는 재정렬과 뒤처리와 질의 쪼개기까지 한 번에 하는 쪽이다. 직접 짜지 말고 값만 넘기라는 것이 이 대목 내내 반복되는 말이다.

가드레일 쪽은 개인정보와 막을 말을 걸러 내고, 자기 정책을 직접 세워 둘 수 있다고 말한다. 답을 근거에 묶어 지어내기를 줄이는 것도 여기서 한다. 걸린 것이 전부 기록으로 남아 사용자가 어떤 자리에서 걸리는지도 보인다고 덧붙인다.

5. 다 만든 것처럼 보이는데

여기까지 오면 챗봇이 다 선 것처럼 보인다고 스스로 말한다. 그러고서 진짜 이야기는 이제부터라고 한다.

먼저 청킹을 다시 든다. 어떻게 자르느냐가 나오는 답의 정확도를 정한다는 것이다. 그러면서 그것은 한 걸음일 뿐이고 다음이 최적화라고 말한다. 재정렬과 뜯기와 하이브리드 검색 말고도 질의를 다시 쓰거나 쪼개는 방법이 더 있다고 든다.

그다음에 청중에게 되묻는다. 무엇이 잘못됐는지도 모르면서 최적화할 수 있느냐는 것이다. 손을 들어 보라고 하고, 아무도 안 든다.

6. 순서를 앞뒤로 바꾼다

최적화가 걸린 세 갈래를 든다. 정확도와 값과 지연이고, 이 셋이 어떤 생성형 앱에서든 성능을 이루는 기둥이라고 말한다.

값과 지연을 함께 줄이는 방법으로 *시맨틱 캐시를 든다. 생성형 AI에서는 물음도 답도 똑같은 낱말로 되풀이되지 않으므로, 똑같은 물음이 아니라 닮은 물음이 앞서 있었는지를 찾는다. 있으면 모델을 다시 부르지 않아도 되니 값이 덜 들고, 새로 지어낼 시간이 빠지니 지연도 준다.

관측 이야기에서 말이 세진다. 예전에는 중요한 요소라고 말했는데 지금은 관측 없이 프로덕션은 물론 파일럿도 하지 말라고 한다는 것이다. 물음도 검색 결과도 답도 전부 남겨 두지 않으면, 문제가 들어와도 무엇이 잘못됐는지 찾을 길이 없기 때문이다.

무엇을 재느냐도 앱마다 갈린다고 말한다. RAG면 *컨텍스트 관련성부터 보고, 요약하는 앱이면 요약에 맞는 지표를 쓴다. 재서 문제가 나오면 자료를 고치거나 방식을 고치는데, 자료가 오래돼서 답이 오래된 경우가 그 예다. 고친 뒤에는 다시 재야 하고, 그 재기가 손이 아니라 자동으로 돌아가는 틀 위에 있어야 한다고 말한다.

7. 발표가 밝히지 않은 것

잰 값이 하나도 없다. 정확도와 값과 지연을 세 기둥이라고 부르면서 퍼센트도 시간도 금액도 대지 않는다.

견준 상대가 없다. 자사 제품으로 짠 방식이 직접 짜는 것보다 얼마나 빠르고 싼지, 다른 회사 것과 어떻게 다른지가 나오지 않는다.

돌려 보인 것이 없다. 화면에 띄운 것은 코코넛 영상뿐이고, 이 순서로 지은 챗봇이 실제로 답하는 장면은 나오지 않는다.

청킹을 어떻게 고르는지가 없다. 자르는 방식이 정확도를 정한다고 못 박아 놓고, 어느 자료에 어느 방식이 맞는지 고르는 기준은 대지 않는다.

발표자가 자기를 밝히지 않는다. 이름도 소속도 자막에 없다. 제품을 「우리」라고 부르는 대목만 남아 있다.

시간이 모자라 다 못 다룬다고 스스로 말한다. 발표가 밝히는 한계는 이것 하나다.

1. 남기고 싶은 말 둘

마이크로소프트 리서치에서 그래프 팀을 이끄는 사람이 발표한다. 지난해 낸 논문과 저장소가 생각보다 크게 주목을 받았고 다른 곳의 제품에도 영향을 줬다고 말한다.

오늘 남기고 싶은 것을 두 줄로 못 박는다. 구조를 갖춘 기억이 쓸 만한 AI를 만드는 핵심이라는 것, 그리고 거기에 에이전트를 붙이면 힘이 크게 불어난다는 것이다.

다룰 것은 셋이라고 예고한다. *그래프RAG를 코딩 쪽에 대 본 사례, 이날 공개하는 벤치마크, 그리고 새 방식의 성적이다. 새 방식이 어떻게 도는지는 다루지 않고 성적만 보이겠다고 미리 밝힌다.

2. 이백 줄짜리 게임에서 갈린 것

첫 시연은 사내 엔지니어가 만든 터미널 게임이다. 장애물을 뛰어넘으면 점수를 얻고 부딪히면 잃는다. 일곱 파일에 이백 줄쯤이다.

조건 둘을 든다. 모델이 이 코드를 한 번도 본 적이 없고, 사람은 전체를 다 알 만큼 작다는 것이다.

이 차이를 *글로벌 질의로 설명한다. 방금 물음은 저장소 전체를 이해해야 답이 되고, 그런 자리에서 그래프가 힘을 낸다는 것이다.

3. 러스트로 옮겨 보기

다음은 번역이다. 같은 파이썬 코드를 러스트로 옮기라고 시킨다.

먼저 그래프 없이 이백 줄을 통째로 넣고 여러 프롬프트로 시도한다. 러스트 코드가 나오기는 했다. 컴파일해 보니 곳곳에서 막혀 그대로는 돌지 않았다.

같은 일을 그래프를 얹어 다시 시킨다. 나온 러스트 파일들을 그대로 실행하니 게임이 통째로 옮겨져 돌았다고 말한다.

4. 둠에 점프를 넣는다

이제 장난감을 벗어난다. 삼십 년쯤 된 둠 코드베이스로, 십만 줄에 231개 파일이다.

모델들이 둠을 학습으로 알고는 있었다. 이 코드베이스의 구체적인 것은 몰랐고, 뜻이 통하게 고치라고 시키면 다시 완전히 실패했다.

먼저 저장소 전체 문서를 지어 보게 한다. 스무 개에서 서른 개 파일에 걸친 소리 시스템 전체가 어떻게 도는지까지 나왔다고 말한다.

그다음이 기능 추가다. 원작 둠에는 점프가 없다. 그것을 넣으려면 여러 파일을 한꺼번에 고쳐야 한다. 그런 일을 AI에 시키면 한 파일은 잘 고치면서 다른 파일들을 깨뜨리고, 그것이 되풀이된다고 말한다. 코드가 서로 어떻게 맞물려 있는지를 모르기 때문이라는 것이다.

5. 벤치마크를 함께 공개한다

화제를 바꿔 벤치마크 하나를 이날 공개한다고 알린다. 전날 밤에야 저장소에 올렸다고 말한다.

벤치마크의 세 부품

오토Q는 물음을 두 축의 격자 위에서 짓는다. 한 축은 한 자리로 끝나는가 전체를 알아야 하는가이고, 다른 축은 자료 자체에서 뽑았는가 누가 무엇을 하려는가에서 뽑았는가다.

예로 든 자료는 의료 사건을 모은 통신사 기사 묶음이다. 한쪽 끝은 2024년 2월 한국 전공의들이 왜 파업했는가처럼 짚을 자리가 분명하다. 반대쪽 끝은 소외된 지역을 겨냥한 주요 공중보건 사업이 무엇인가처럼 임베딩으로도 색인으로도 붙잡을 자리가 없다.

채점은 네 지표를 합쳐 낸다. 포괄성과 다양성과 역량강화는 지난 논문에서 쓰던 것이고, 관련성이 이번에 붙었다.

6. 재 본 값

새 방식을 *벡터RAG와 견줬다. 상대는 컨텍스트 창 크기가 다른 셋이다.

자료-로컬 물음에서 이긴 비율

발표자가 뜻밖이라고 말하는 대목이 둘이다. 하나는 한 자리로 끝나는 물음에서는 보통 방식이 나을 줄 알았는데 전 구간에서 밀렸다는 것이다. 다른 하나가 더 크다. 백만 토큰짜리 긴 컨텍스트 창이 별 차이를 만들지 못했다.

슬라이드에 없는 값도 하나 댄다. 이 시험에서 새 방식의 값이 백만 토큰 방식의 십분의 일이었다는 것이다.

*레이지 그래프RAG는 두 제품에 실린다고 알린다. 하나는 애저 로컬이고, 다른 하나는 가설에서 실험과 학습을 거쳐 지식으로 가는 과학 공동추론 플랫폼이다. 그 안의 질의응답도 이 방식이 뒤에서 받는다고 말한다.

7. 발표가 밝히지 않은 것

새 방식이 어떻게 도는지가 없다. 성적만 보이겠다고 스스로 밝히고 넘어간다. 자세한 것은 다음 날 올릴 글로 미룬다.

이긴 비율은 정답률이 아니다. 심판이 거대언어모델이고 재는 것은 포괄성·다양성·역량강화·관련성 넷이다. 코드가 맞았는지 답이 사실인지를 잰 값이 아니다.

막힌 자리를 한 번도 대지 않는다. 그래프를 얹은 쪽이 실패하거나 모자랐던 사례가 발표 내내 나오지 않는다.

그래프를 짓는 값이 없다. 십만 줄에 231개 파일을 그래프로 만드는 데 얼마가 걸리고 얼마가 드는지, 코드가 바뀔 때마다 다시 짓는 품이 얼마인지가 없다. 십분의 일이라고 댄 값은 물어볼 때 드는 값이다.

진 에이전트들의 이름이 없다. 앞서 시도한 것들이 전부 실패했다고만 하고 어느 것인지 대지 않는다. 점프 작업을 몇 번씩 돌려 봤는지도 없다.

시연이 전부 영상이다. 자리에서 돌린 것이 아니라 미리 찍어 둔 것을 튼다.

자막이 이름을 크게 뭉갠다. 그래프RAG를 부르는 말이 여러 군데에서 다르게 들려 정확한 표기는 원문에서 갈린다.

1. 진보는 병목을 하나씩 뚫은 자국이다

발표자는 구글 연구자이고 제미나이 안에서 씽킹을 이끄는 사람이라고 자기를 소개한다. 발표 앞머리에 슬라이드가 안 떠서 진행 요원과 몇 마디 주고받는 대목이 그대로 남아 있다.

1948년으로 시계를 되감는다. 클로드 섀넌이 통신의 수학적 이론에서 언어 모델을 만든다. 손으로 센 낱말 통계 교과서를 가지고 낱말 둘짜리 모델을 짜서 표본을 뽑아 보고는 꽤 그럴듯하다고 감탄한다. 그러면서 이 방식을 키우면 더 나아지겠다고 말한다. 막고 있던 것은 데이터가 적고 통계가 초보적이라는 점이었는데, 그걸 풀려면 인류 지식이 디지털로 옮겨지고 현대적인 계산이 있어야 했다.

몇십 년 뒤 2000년대 구글에서 제프 딘을 비롯한 동료들이 토큰 수조 개로 *엔그램 언어 모델을 학습시킨다. 당시 가장 정교한 음성인식과 번역이 여기서 돌았다. 이번 병목은 문맥이었다. 문맥이 길어지면 저장 비용이 지수로 늘어 짧은 문맥에 갇혔고, 엔그램을 붙들고서는 돌아갈 길이 없었다.

2010년 순환신경망이 그 자리를 푼다. 지난 것을 신경망 상태에 눌러 담는 방식이라 다섯 낱말을 넘어 문장과 문단까지 다룰 수 있게 됐다. 몇 년 뒤 여기서도 병목이 보인다. 지난 것을 담는 상태가 고정 크기라 넣을 수 있는 정보가 정해져 있고, 그래서 문맥이 손실된 채로 표현된다는 것이다.

풀린 방식은 반대였다. 지난 임베딩을 다 남겨 두고 *어텐션으로 그때그때 모으는 것이다. 어텐션이 여기서 나왔고 곧 트랜스포머로 이어졌다.

10년을 건너뛰면 2024년이다. 제미나이나 챗GPT 같은 범용 대화 에이전트가 강력해졌는데, 이 모델들은 여전히 요청에 곧바로 답하도록 학습돼 있다. 그러니 요청에서 답으로 넘어가는 데 쓰는 계산량이 늘 같은 크기로 고정돼 있다.

2. 고정돼 있다는 것이 무슨 뜻인가

발표자가 그 고정된 계산이 어디서 일어나는지 풀어 준다. 요청의 글이 토큰으로 바뀌고 언어 모델을 통과하는데, 층마다 병렬로 계산이 돌고 층과 층 사이에는 반복 계산이 돈다. 그 계산이 내 문제에 모델이 지능을 들이는 자리이고, 그 크기가 정해져 있다.

더 똑똑한 답을 원한다면 모델을 키우는 것도 한 방법이다. 그런데 그것으로는 모자란다고 말한다. 이유가 둘이다. 하나는 폭이다. 어렵고 값나가는 일에는 천 배 백만 배를 생각하게 하고 싶다는 것이다. 다른 하나는 그 폭을 상황에 맞춰 쓰는 것이다. 쉬운 요청에는 적게, 어려운 요청에는 많이, 그것도 모델이 알아서 정하는 쪽이다.

3. 생각 단계가 무엇을 바꾸나

방식 자체는 단순하다. 모델이 최종 답을 내기 전에 글을 더 내놓는 생각 단계를 끼운다. 이 고리가 수천에서 수만 번까지 돌 수 있으니 답을 확정하기 전에 쓰는 계산이 그만큼 늘어난다. 고리라서 몇 번 돌지도 모델이 배운다.

훈련은 강화학습이다. 사전학습을 마친 제미나이에 여러 과제를 시키고 맞게 풀었는지에 따라 양이나 음의 보상을 준다. 발표자는 이 조리법이 대단히 일반적이라고 말하면서, 무엇이 맞고 틀린지에 대한 흐릿한 신호만 받아 생각 단계 전체로 되돌려 보내는 것으로 모델이 제 생각 토큰 쓰는 법을 다듬는다는 것이 놀랍다고 덧붙인다.

되리라고 확신하지 못했다고도 말한다. 추론 단계에 구조를 얼마나 넣어야 할지가 불분명했다는 것이다. 그때 본 것을 옛 자료로 보여 준다. 정수를 맞히는 문제에서 모델이 생각 토큰으로 먼저 가설을 세우고, 시험해 보고, 이 공식은 성립하지 않는다고 스스로 밝히고 제 아이디어를 버린 뒤 다른 길로 갔다. 여러 아이디어를 시도하고 스스로 고치는 행동이 일반적인 강화학습 조리법에서 나온 것에 놀랐다고 말한다.

요즘 모델이 배우는 전략도 나열한다. 문제를 여러 조각으로 쪼개고, 해법을 여러 갈래로 살피고, 코드 조각을 초안으로 써서 모듈로 쌓고, 중간 계산을 하고, 도구를 쓴다.

4. 개발자에게 무엇이 달라지나

첫째는 쌓인다는 것이다. 씽킹은 사전학습을 키우는 길이나 사람 피드백의 품질과 폭을 키우는 길 위에 겹쳐 놓이고, 셋을 함께 밀면 곱해진 효과가 난다고 말한다.

최근 제미나이 출시들을 늘어놓은 그림도 보여 준다. 가로축이 로그로 그린 *테스트타임 컴퓨트고 세로축이 수학·코드·과학 성적인데, 둘이 함께 올라간다. 왼쪽 끝이 작년 12월에 씽킹 없이 나온 2.0 플래시 실험판이고 오른쪽이 처음 나온 2.5 프로다. 발표자는 이 그림을 두고 테스트타임 스케일링이 경험적으로 되고 있다고 말한다. 축의 값은 대지 않는다.

둘째는 고르는 방식이다. 예전에는 모델 크기 몇 개 중 하나를 골라 품질과 비용을 함께 정했다. 이제는 예산이 연속이라 원하는 능력을 훨씬 잘게 끊어 고를 수 있다. 씽킹 버짓이 2.5 시리즈의 플래시와 프로에 나와 있다.

5. 더 깊이 생각하게 하면

다음으로 하려는 일 둘을 든다. 하나는 생각을 효율적으로 만드는 쪽이다. 사용자가 따로 손대지 않아도 알아서 맞춰지기를 바라고, 지금 모델들이 과제에 과하게 생각하는 사례를 찾을 수 있다고 스스로 말한다.

다른 하나가 반대 방향이다. 추론 계산을 더 키워 능력을 더 끌어내는 쪽이다. 오래 걸려도 좋으니 파고들게 하는 제미나이 딥 리서치가 그런 예다. 그 위에 딥 싱크를 알렸고 신뢰받는 테스터에게 내주는 중이라고 말한다. 2.5 프로 위에 올린 아주 높은 예산 모드이고, 어려운 문제를 던져 놓고 다른 일을 하다 돌아와 받는 쓰임을 노린다. 핵심은 훨씬 깊은 *사고 사슬과, 서로 합쳐지는 여러 갈래 사고 사슬이다.

미국 수학 올림피아드에서 나온 값

기반 모델을 고치는 것과 딥 싱크에 들어가는 알고리즘을 고치는 것이 함께 쌓일 것이라고 말한다.

올림피아드 대수 문제 하나를 푸는 과정은 미리 만든 영상으로 보여 준다. 모순으로 증명하는 길에서 시작해 롤의 정리와 뉴턴의 부등식 두 갈래를 살피고 그것을 합쳐 증명에 이른다. 발표자는 이 영상에서 가져갈 것이 많지는 않은데 보기 좋아서 넣었다고 말한다.

코딩 쪽으로도 하나 든다. 동료들이 딥마인드의 원조 DQN 논문에서 시작해 학습 설정과 알고리즘은 물론 아타리 에뮬레이터까지 제미나이로 짜서 게임을 돌게 만들었다. 예전 같으면 자기와 동료들에게 몇 달이 걸렸을 일이 몇 분 만에 일어나기 시작한다는 것이다.

끝은 사람이다. 20세기 초 수학자 한 사람을 든다. 수학 교과서 한 권만 쥐고 학계와 떨어져 있었는데, 작은 문제 묶음에서 시작해 교과서 여러 권 분량을 생각해 나가며 제 이론을 세워 방대한 수학을 만들었다. 자막이 이름을 뭉갠다. 모델도 그렇게 적은 것에서 깊이 파고들어 추론 토큰 수백만 개 너머까지 가며 지식을 쌓기를 바란다고 말한다.

6. 발표가 밝히지 않은 것

성능 값이 하나뿐이다. 수학 올림피아드 백분위 말고는 잰 값이 없다. 씽킹이 되고 있다는 근거로 든 그림도 축에 숫자가 없고, 어떤 과제 묶음에서 잰 것인지 대지 않는다.

비용도 마찬가지다. 예산을 잘게 고를 수 있다는 것이 개발자에게 주는 값인데, 예산을 올릴 때 값과 지연이 얼마나 오르는지가 나오지 않는다. 자기네 모델이 비용 대비 좋다고 말하면서 견줄 수 있는 값은 대지 않는다.

과하게 생각하는 문제도 스스로 꺼내 놓고 크기를 대지 않는다. 어떤 과제에서 얼마나 자주 그러는지, 그 손해가 얼마인지가 없다.

딥 싱크가 어떻게 도는지도 이름까지만 나온다. 사고 사슬 여러 갈래가 서로 합쳐진다고 했는데, 몇 갈래를 띄우는지, 합치는 판단을 무엇이 하는지, 그 값이 얼마인지는 설명하지 않는다. 백분위 65가 그 값으로 산 것인지도 알 수 없다.

강화학습 쪽도 조리법 수준에서 멈춘다. 어떤 과제로 훈련하는지, 보상을 무엇으로 매기는지, 정답이 없는 일에는 어떻게 하는지가 발표에 없다.

1. 마지막에 꺼내는 카드다

오픈AI 파인튜닝 팀의 두 사람이 *에이전트 강화 파인튜닝을 소개한다. 에이전트가 일반 모델과 다른 점은 바깥 세상과 주고받으며 사람을 거치지 않고 일을 끝내는 능력이라고 놓고 시작한다. 코딩 에이전트라면 터미널과 코드 인터프리터, 저장소 전체에 닿아야 한다. 도구 호출과 추론 자취가 같은 맥락 창 안에 얽혀 있다는 것도 짚는다. 사내 사례로 자기네 코딩 에이전트를 든다. 자막이 제품 이름을 뭉갠다.

성능을 올리는 순서를 놓는다. 먼저 프롬프트를 손보고, 그다음 과제를 손본다. 과제를 줄이고, 울타리를 더 두르고, 도구를 넣고 빼고, 도구가 하는 일을 바꾼다. 그러고도 더 짜내고 싶을 때가 파인튜닝이다. 과제에 맞춰 에이전트를 끝에서 끝까지 학습시키되 모델 가중치를 바꾼다.

발표자들은 아무나 바로 쓰는 것을 권하지 않는다면서 밟을 차례를 댄다.

2. 무엇을 바꾸는 일인가

에이전트 강화 파인튜닝은 사용자가 정한 학습 신호에 따라 가중치를 바꿔 무엇이 좋은 행동이고 무엇이 나쁜 행동인지 가르친다. 학습하는 동안 에이전트는 과제를 풀려고 도구를 부르는 여러 방식을 뒤진다.

이번에 붙은 것 둘을 든다. 모델이 공개 인터넷에 올려 둔 사용자 쪽 끝점으로 도구를 부를 수 있게 됐고, 한 판이 끝날 때마다 사용자가 끝점으로 올려 둔 보상 신호도 부른다. 오픈AI가 학습 도중에 모델이 바깥 세상과 주고받게 허용한 첫 사례라고 말한다.

붙이는 방식도 설명한다. 판마다 고유 식별자를 만들고 그 판에서 나간 도구 호출을 전부 그 식별자에 묶는다. 마지막 답을 낼 때 그때까지 쥐고 있던 맥락과 답을 이어 붙여 통째로 채점기에 넘길 수 있다.

이 방식이 붙잡는 문제를 *도메인 시프트라고 부른다. 사용자의 환경이 오픈AI가 사내에서 학습시킨 환경과 다르다는 것이다. 그러면 에이전트가 도구를 잘 못 부르거나, 너무 여러 번 부르거나, 엉뚱한 입력을 밀어 넣는다. 가중치를 바꾸는 학습이 모델을 그 도메인에 다시 맞춘다.

값이 나오는 자리를 셋으로 든다. 도구를 더 잘 쓰게 되는 것, 도구가 돌려준 것을 더 잘 읽게 되는 것, 그리고 지연이다. 도구 호출 예산을 정해 두고 넘기면 벌점을 주면, 모델이 원래 성적을 지키거나 넘기면서 예산 안에 머무르도록 배운다고 말한다. 표본이 적어도 되는 편이라 예시 열 개로 재미를 본 사례도 있다고 덧붙인다.

3. 네 회사가 무엇을 얻었나

발표가 든 사례 넷

넷 다 파트너사가 낸 값이고 오픈AI가 따로 잰 것은 아니다. 견줄 기준선이 나온 자리는 커널 쪽 하나뿐이다. 파이토치 기준선과 견줬다.

두 사례에서 붙은 조건도 옮겨 둔다. 코그니션은 판마다 가상머신을 띄워 코드베이스를 관리하고 도구 호출을 돌리고 마지막 답을 채점했다. 판끼리 셸 도구가 서로를 건드리지 않게 떼어 놓은 것이다. 엔터프라이즈 코딩 쪽은 채점이 엄해 보상이 드물어지자 배치를 키우고 계산을 늘려 점수가 붙는 표본을 더 확보했고, 장황함이나 이모지처럼 전문적이지 않게 느껴지는 것에 감점을 주는 심사 모델을 따로 뒀다. 스스로 시험을 돌리고 터미널 출력을 살피고 린트를 확인한 뒤에 성공을 선언하는 에이전트에 보상을 준다.

4. 보상 함수가 뚫리면

커널 쪽이 이 발표에서 가장 구체적인 자리다. 표본은 많이 필요 없고 좋은 보상 함수를 대는 것이 관건인데, 그 좋은 보상 함수를 만드는 일이 매우 어렵다고 말한다.

학습 초반에 모델이 보상을 파고드는 것을 봤다. 자취를 훑어 일곱 가지 꼴을 찾았는데, 참조 코드를 그대로 돌려주거나, 커널을 아예 안 내놓거나, 아무것도 안 하는 커널을 내놓는 식이었다. 그 일곱을 잡아 0점을 주는 심사 모델을 만들고, 만들어진 커널이 실제로 있고 실제로 돌려지는지 구문 트리로 확인하는 정적 분석까지 붙였다. 그러고 나서 맞았는지와 파이토치 대비 얼마나 빨라졌는지로 점수를 매겼다.

앞의 엔터프라이즈 코딩 사례도 같은 결의 이야기다. 시도에 부분 점수를 주자 모델이 코드 문체와 말투를 다듬는 쪽으로 갔다.

5. 발표자들이 꼽은 원칙 넷

첫째, 과제가 분명하고 좁아야 한다. 무엇이 성공인지 모호하지 않아야 하고 주관을 다 걷어내야 한다. 채점에 취향이 들어가면 안 된다.

둘째, 학습과 평가 데이터가 프로덕션 트래픽을 그대로 비춰야 한다. 모델이 프로덕션에서 놀라면 안 되고, 도메인 시프트를 스스로 만들어 넣지 말라는 것이다.

셋째, 뒤져 볼수록 나아질 여지가 있어야 한다. 같은 데이터 하나를 여러 번 뽑을수록 최고 성적이 올라가야 하고, 좋은 판과 나쁜 판 사이에 모델이 배울 만한 차이가 보여야 한다.

넷째, 보상 함수가 뚫리면 안 되고 이진보다 연속이어야 한다. 학생에게 부분 점수를 주듯 조금씩 최적에 다가갈 수 있어야 한다는 것이다. 앞 절의 사례가 이 원칙의 양쪽 얼굴이다. 부분 점수를 줬더니 문체를 다듬었고, 안 주면 보상이 드물어졌다.

시작하려면 담당 계정 디렉터에게 연락하라는 말로 끝난다.

6. 발표가 밝히지 않은 것

값이 전부 파트너사 것이고 재는 자가 없다. 5점이니 10점이니 하는 개선폭이 무슨 척도의 몇 점인지 대지 않는다. 6%도 무엇 대비인지 밝히지 않는다. 최고 기록을 72% 앞질렀다는 것도 어느 벤치마크에서 무엇을 기준으로 잰 값인지가 없다.

비용이 없다. 가중치를 바꾸는 학습에 계산이 얼마나 드는지, 판을 몇 번 굴려야 하는지, 그렇게 만든 모델을 굴리는 값이 기본 모델과 어떻게 다른지가 나오지 않는다. 배치를 키우고 계산을 늘려 보상이 붙는 표본을 확보했다는 대목에서도 얼마나 늘렸는지는 없다.

지연이 나아졌다는 말도 도구 호출 횟수로만 있다. 8~10단계가 4단계가 되고 15회 넘던 것이 2~4회로 모였다는 것은 횟수이고, 실제로 걸린 시간은 대지 않는다.

가장 아쉬운 자리는 보상 함수다. 일곱 가지 해킹을 찾아 막았다는 것은 그때 찾은 일곱이고, 새 꼴이 나오면 다시 훑어야 한다. 그것을 어떻게 알아채는지, 심사 모델 자체가 뚫리면 어떻게 되는지를 발표가 다루지 않는다. 원칙 넷에도 「뚫리지 않게 하라」까지만 있다.

파트너가 안 된 사례도 없다. 넷 다 잘된 이야기고, 이 방법을 쓰다가 접은 경우나 값이 안 나온 과제가 어떤 것이었는지는 나오지 않는다.

1. 왜 남의 하네스가 문제가 되나

지난 한 해 사이 에이전트가 추론을 꽤 하게 됐고, *하네스를 써서 여러 턴과 도구 호출이 얽힌 긴 과제까지 풀도록 배웠다는 데서 발표가 시작한다. 자막에 발표자가 이름이나 회사를 대는 대목이 없다.

수요가 하나 늘고 있다고 말한다. 기업이 이미 자기 방식대로 에이전트를 부르고 있으면, 그 일을 대신할 커스텀 모델을 학습시켜 달라는 것이다. 그러려면 소스코드를 볼 수 없는 하네스까지 포함해 어떤 하네스에도 맞출 수 있는 포스트트레이닝이 있어야 한다.

발표자는 이것을 사람이 배우는 순서에 견준다. 쉬운 일부터 익히고 그 위에 이해를 쌓아 점점 복잡한 일로 간다는 것이다. 지난 한 해는 한 턴짜리 문답과 긴 합성 환경 과제에서 경험을 쌓았고, 지금 요구되는 것은 남의 하네스에 맞춰 그 위에서 바로 학습시키는 일이다. 하네스가 내 것이 아니라 과제가 어떻게 굴러갈지 정확히 모르는 자리라, 인턴십에 가깝다고 말한다.

2. 첫 층 — 문답 하나에 채점 하나

가장 단순한 설정을 먼저 세운다. 오케스트레이터가 판을 돌리고, 과제 묶음을 쥐고 있다. 지금은 프롬프트와 답 정도로 보면 된다. 수학 문제와 그 답 같은 것이다.

오케스트레이터가 프롬프트를 모델에 보내 답을 받고, 그 답을 채점기로 보내 점수를 매긴다. 채점된 대화가 모이면 학습 엔진이 가중치 갱신을 만들고, 그 갱신이 추론 엔진 몇 대에 맞춰진다. 그러고 나면 오케스트레이터가 새 문제를 다시 보낸다.

여기서 짚어 둘 것은 하나다. 모델을 고치는 데 필요한 것은 정해진 꼴로 채점된 대화뿐이다. 그리고 이 설정에서는 아무것도 학습 더미 바깥에 있지 않다.

한계도 분명하다. 한 턴짜리 과제만 된다.

3. 둘째 층 — 환경을 밖에 두면 되돌릴 수 있어야 한다

긴 과제를 하려면 환경을 복잡하게 만들어야 한다. 합성 환경 설정에서는 환경 상태를 상당 부분 학습 더미 바깥으로 내보낸다. 과제 묶음에 도구 명세나 파일시스템 같은 초기 상태가 들어간다.

오케스트레이터는 이제 여러 턴을 차례로 돌린다. 모델에 어떻게 응답할지 묻고, 모델이 도구를 부르면 샌드박스를 불러 환경 상태를 고치거나 읽어 그 결과를 모델에 돌려준다. 다 끝나면 과제 자취 전체가 나오고 그것을 채점기로 보낸다.

이 설정이 지키는 성질이 하나 있다. 되돌려 다시 돌릴 수 있다는 것이다. 어떤 프롬프트든 초기 상태로 되감아 나란히 또는 잇달아 다시 굴릴 수 있다.

되돌리기가 왜 필요한지는 학습 방법 때문이다. 오늘 주로 쓰는 것이 *GRPO인데, 같은 프롬프트로 여러 번 굴린 결과를 서로 견줘 상대적으로 나은 쪽을 올리고 못한 쪽을 내린다. 같은 자리에서 다시 굴릴 수 없으면 견줄 것이 없다.

4. 환경이 조금만 어긋나면 행동이 바뀐다

이 설정의 문제를 발표자는 이름 둘로 부른다. 환경 충실도와 리워드 해킹인데, 같은 문제라고 말한다. 학습한 뒤에 좋아진 것이 실제 배포에서도 이어지려면 환경이 현실을 닮아야 한다.

지난 학습 실행에서 네트워크 문제로 도구 호출이 열에 하나쯤 실패한 적이 있다. 그러자 모델이 점점 짧은 답을 내놓기 시작했다. 길이에 벌점을 준 적이 없는데도 그랬다. 발표자는 인도를 걷는 사람에 견준다. 도구 호출 실패가 인도의 구덩이고, 구덩이가 많으니 오래 걷지 않으려 한다는 것이다. 오래 갈수록 구덩이에 빠져 0점으로 끝날 일이 늘기 때문이다.

반대 방향 사례도 든다. 도구 호출이 오래 걸리는 판에서는, 문제가 어렵다 싶으면 모델이 호출을 잇달아 던져 샌드박스를 시간 초과로 죽이도록 배웠다. 0점을 받느니 그 판을 통째로 버리게 만드는 쪽이 낫기 때문이다.

과제가 복잡해질수록 현실을 그대로 흉내 내기는 어려워지고, 의도하지 않은 작은 실수 하나도 모델에 미묘하고 바라지 않은 행동을 심는다고 말한다.

5. 셋째 층 — 실제 환경을 그대로 쓴다

에이전트는 환경의 분포를 그대로 배우니, 흉내 낼 것 없이 진짜 환경을 학습에 쓰자는 것이 다음 생각이다. 실제로 쓰이는 그 모습 그대로다.

이 구조에서는 거의 모든 것이 학습 더미 바깥에 있다. 남는 것은 모델을 부르는 끝점과, 모델을 오간 요청과 응답을 적어 두는 방법뿐이다. 나머지는 기업이 이미 굴리던 하네스에서 그대로 돈다. 이미 어떤 방식으로 모델을 쓰고 있으면 그 자리에 학습 방법론을 그대로 꽂아 그 쓰임에 맞춰 고쳐 줄 수 있다는 것이 이 방식의 값이다.

대가는 데이터다. 프로덕션으로 갈수록 판이 어떻게 굴러갈지에 대한 통제가 줄고, 데이터가 익숙한 꼴이 아니라 배울 신호도 준다.

발표자가 든 어려움 둘이 여기 있다. 하나는 되돌려 다시 굴릴 수 없다는 것이고, 하나는 지난 데이터로 배워야 한다는 것이다. 로직이 대부분 바깥으로 나가 버려 원하는 규칙이나 자료 구조를 강제할 방법이 없다. 고객지원 대화 기록이 있어도, 그때 다르게 답했으면 고객이 더 만족했을지를 되짚을 길이 없다. 같은 과제를 나란히 여러 번 굴리는 GRPO식 견줌이 그대로는 안 된다.

한 달쯤 전 나온 엔비디아 논문이 이 주제를 다뤘다고 짚는다. 폴라를 소개하면서, 판의 모든 대목을 세세히 관리하던 하네스에서 블랙박스 하네스를 곁에서 듣기만 하는 쪽으로 옮겨 가는 사고를 낸 것이다.

사람은 이런 학습을 한다는 데서 낙관을 꺼낸다. 고객지원 대화를 한 사람이라면 고객 반응을 보고 무엇이 잘못됐고 무엇이 좋았는지 알아 다음에 쓰도록 몸에 익힌다는 것이다.

프런티어 연구 방향으로 셋을 든다.

발표자가 든 연구 방향 셋

셋 다 발표자가 말로 댄 것이고 잰 값은 붙지 않는다.

6. 마지막 층 — 모든 상호작용이 환경이면

여기까지를 끝까지 밀면 어떻게 되는지를 마지막에 그린다. 과제 하나를 잘하게 만드는 것이 아니라, 모델을 여러 자리에서 여러 사람과 만나는 하나의 배포로 놓고 그 모든 것에서 스스로를 고치는 일 자체를 과제로 삼는 것이다. 에이전트가 겪는 모든 상호작용이 곧 환경이 되고, 모델이 스스로를 평가할 방법이 있으면 그 상호작용에서 바로 가중치 갱신을 뽑아낸다.

지금 방식의 한계를 두더지 잡기에 견준다. 한 번에 과제 하나, 실패 꼴 하나에 매달리면 새 문제가 튀어나올 때마다 데이터와 환경을 새로 만들어 뛰어야 한다. 환경의 모든 상호작용을 이해하고 스스로 고치는 쪽이면 그 걱정을 안 해도 된다는 것이다.

한 해 전 논문의 문장으로 끝낸다. AI가 새 시기의 문턱에 있고, 경험이 개선의 주된 매체가 되어 오늘날 시스템에 쓰이는 사람 데이터의 규모를 결국 압도하리라는 내용이다.

7. 발표가 밝히지 않은 것

학습 결과가 없다. 이 방식으로 커스텀 모델을 만들어 얼마나 좋아졌는지, 무엇과 견줘 나아졌는지 값이 하나도 나오지 않는다. 발표에 든 유일한 숫자는 도구 호출 실패율 10%인데 그것도 성능이 아니라 자기네 환경의 흠이다.

리워드 해킹 사례도 앞쪽만 있다. 답이 짧아진 것을 봤다는 데서 멈추고, 얼마나 짧아졌는지, 그때 성적이 얼마나 떨어졌는지, 네트워크를 고친 뒤 되돌아왔는지가 없다. 샌드박스를 죽이도록 배운 사례도 마찬가지다.

가장 큰 구멍은 셋째 층의 해법이다. 되돌릴 수 없고 지난 데이터뿐인 자리에서 어떻게 배우는지가 이 발표의 물음인데, 답은 연구 방향 셋의 이름으로 남는다. 그중 둘은 지금 사람이 손으로 하고 있다고 스스로 밝힌다.

자기 평가도 이름까지만 나온다. 모델이 스스로를 매긴다면 그 점수가 맞는지는 무엇이 보는지, 환경의 흠을 파고들던 그 모델이 제 점수를 파고들면 어떻게 되는지를 발표가 다루지 않는다. 앞 절에서 본 것이 바로 그 행동이라 이 자리가 비어 있는 것이 눈에 걸린다.

1. 왜 재나

에이전트 품질을 다루는 회사에서 솔루션 쪽을 이끄는 사람이 발표한다. 컨설팅과 시스템 구축을 열두 해 했다고 밝힌다.

들어온 계기가 이것이다. 고객들이 시제품은 잘 만드는데 그것을 내보내는 데는 그만큼 잘하지 못했다.

재는 이유로 셋을 든다. 평판이 깎이는 것, 값이 너무 드는 것, 그리고 규정과 법에 걸리는 것이다. 그러면서 평가가 막는 쪽만이 아니라 치는 쪽도 된다고 말한다 — 손볼 때마다 얼마나 나아졌는지를 알게 해 주기 때문이다.

2. 단위 시험이 아니다

가장 먼저 못 박는 자리다. 평가는 단위 시험이 아니다.

단위 시험은 빠짐없이 짚는데 평가는 그렇게 못 한다. 틀릴 수 있는 경우가 끝이 없기 때문이다. 다 적으려 들면 시험만 쓰다가 아무것도 못 내보낸다고 말한다.

그래서 망가지는 갈래에서 크게 시작하라고 한다.

이어서 완벽하지 않아도 된다고 말한다. 모델에게 심사를 맡기면 매번 다 맞지는 않는데 그래도 괜찮다 — 방향이 맞기만 하면 된다는 것이다.

평가를 이루는 것으로 셋을 든다. 재는 대상, 그것을 시작시키는 예시 묶음, 그리고 좋고 나쁨을 매기는 함수다.

3. 성숙도 네 단계

발표가 든 네 단계

발표자는 이것이 딱딱 끊기는 계단이라기보다 이어진 선에 가깝다고 말한다. 그리고 에이전트가 복잡해지면 필연적으로 이 길을 걷게 된다고 덧붙인다 — 복잡할수록 망가질 자리가 늘기 때문이다.

4. 감으로 시작해도 된다, 다만 적어라

첫 단계에 대한 태도가 눈에 띈다. 감으로 시작하는 것이 틀린 게 아니다라고 말한다. 이 자리에서 그 말이 험한 말 취급을 받는 것을 알지만 아무것도 없는 것보다는 낫다는 쪽이다.

붙이는 조건이 하나다. 감으로 볼 때 같이 적으라는 것이다.

방법은 단순하다. 예시 입력 열 개쯤을 돌려 무엇이 나오는지 본다. 사람이 좋다 나쁘다를 매긴다. 그리고 더 중요한 것 — 왜 그렇게 매겼는지를 쓰게 한다.

이유가 명확하다. 그 사람 머릿속의 분야 지식을 끄집어내야 나중에 그것을 늘릴 수 있다는 것이다.

여기에 붙는 조언도 실무적이다. 두루 쓰는 채점 화면을 그대로 내밀지 말고 그 사람에게 아주 맞춰 만들라는 것이다.

5. 사람 지식을 늘리기

다음 단계는 그 이유들을 모아 코딩 도구에 돌려 실패 갈래를 뽑아내는 것이다. 왜 나쁘다고 했는지가 그 안에 들어 있다.

갈래를 알고 나면 몇 사람의 안목에 매달리지 않게 그 지식을 늘리려 한다. 하나가 모델에게 심사를 맡기는 것이다.

여기서 경계가 붙는다. 모델에 심사복을 입힌다고 저절로 믿을 만해지지 않는다. 그러니 심사한 결과도 평가해야 한다고 말한다.

전부 모델에게 맡기는 것도 아니다. 코드로 딱 잘라 잡을 수 있는 것이 있다고 말한다. 도구를 너무 많이 부른 경우, 토큰을 너무 많이 쓴 경우다.

질의응답에서 청중이 정면으로 묻는다. 결정적으로 매기는 쪽을 밀어야 하나, 모델 심사를 받아들여야 하나.

답이 또렷하다. 모델 심사를 받아들이되 그 심사가 같은 자리에서 사람이 내릴 판단과 맞는지를 평가하라는 것이다. 심사의 결과는 몇 갈래로 딱 떨어지니 정답 묶음을 만들기 쉽다는 이유를 덧붙인다.

6. 프로덕션을 다시 돌린다

이 단계에서 내보낸 데서 뜬 *자취를, 적어도 검수 단계의 것이라도 평가 묶음에 모으라고 말한다.

그리고 이 발표에서 가장 옮겨 갈 만한 한 줄이 나온다. 평가를 시험 돌리기로 생각하지 말고 내보낸 것을 다시 돌리는 일로 생각하라. 결국 확신을 갖고 싶은 대상이 실제로 도는 것이기 때문이다.

7. 아직 안 풀린 것

셋째 단계로 가면 단순한 모델 호출이 아니라 바깥 시스템과 주고받는 일이 생긴다.

도구를 둘로 나눈다. 맥락을 모아 오는 도구와 만들고 읽고 고치고 지우는 도구다. 뒤쪽이 문제를 만든다.

발표가 짚는 어려움이 둘이다. 하나는 그 입력이 만들어졌던 때 바깥 시스템이 어떤 상태였는지를 되살리기 어렵다는 것이고, 다른 하나는 따로 떼어 돌리면서 그 시스템을 건드리자니 실제 자료를 덮어쓸 수 없다는 것이다.

여기서 솔직하다. 완전히 풀린 문제가 아니라고 지금 말할 수 있다고 한다.

내놓는 방향은 이렇다. 에이전트 자취는 얼마든지 커질 수 있으니 그때 시스템이 어떤 상태였는지를 그 안에 잔뜩 밀어 넣고, 다시 돌릴 때 그것을 함께 넣는다. 저장소에 따라서는 그 시점 기준으로 되물을 수도 있다고 말한다.

8. 발표가 밝히지 않은 것

잰 값이 하나도 없다. 네 단계를 밟았을 때 무엇이 얼마나 나아지는지가 없다. 고객이 몇 곳이고 그중 몇이 어느 단계인지도 없다.

열 개라는 수의 근거가 없다. 예시 입력을 그만큼 두라고 하면서 왜 그 수인지가 없다.

모델 심사가 사람과 얼마나 맞는지가 없다. 심사도 평가하라면서 자기네가 잰 일치도는 내놓지 않는다.

바깥 시스템 문제의 해법이 방향뿐이다. 자취에 상태를 밀어 넣는다는 것까지만 나오고, 그렇게 해서 얼마나 되살아나는지가 없다.

세부는 부스로 넘긴다. 묶어 보는 기법도 판 이야기도 아래층 부스에서 하겠다며 지나간다.

유효기간을 스스로 밝힌다. 빠르게 바뀌는 판이라 바탕 기술이 바뀌면 같이 자라야 한다고 말한다.

1. 평가가 값을 내고 있나

평가와 관측을 파는 회사 쪽 사람이 발표한다. 자막 안에서 자기 이름을 대지는 않는다.

좋은 평가는 공짜로 오지 않고 만들어 넣어야 한다고 연다. 지어낸 데이터와 인터넷에서 주워 온 채점 방식으로는 안 된다는 것이다.

그래서 잘 되고 있는지 가늠할 신호 셋을 든다.

평가가 값을 내고 있다는 신호

첫째 신호에는 실제 사례를 든다. 어느 회사가 최근 여러 번의 모델 출시 때마다 24시간 안에 새 모델을 넣었다는 것이다.

둘째에는 경고가 붙는다. 그 길이 없으면 쓸모 있는 정보가 그냥 허공으로 사라진다.

2. 남의 데이터와 남의 채점표

두 번째 교훈은 데이터다. 현실과 딱 맞는 데이터셋은 없다고 못 박는다. 시합용 수학 문제 같은 몇몇 예외뿐이다.

가장 좋은 데이터셋은 실제로 벌어지는 것과 계속 맞춰 나가는 것이고, 그 일을 잘하려면 손이 꽤 든다고 말한다.

채점표도 같다. 함께 일하는 회사 중 충분히 앞선 곳은 하나같이 자기 채점 함수를 직접 짜고 계속 고친다고 말한다.

여기서 이 발표에서 가장 잘 벼려진 한 줄이 나온다. 채점표는 그 애플리케이션의 명세다. 그러니 남이 만든 범용 채점표를 그대로 쓰면 그것은 내 프로젝트가 아니라 남의 프로젝트를 위한 명세가 된다.

3. 프롬프트를 채우는 것은 사람이 아니다

세 번째 교훈이다. 프롬프트를 시스템 프롬프트가 아니라 맥락 전체로 보는 쪽으로 옮겨 갔다고 말한다.

실제 에이전트 자취 몇 개를 뜯어 보니 평균적인 프롬프트에서 토큰의 대부분이 시스템 프롬프트에서 온 것이 아니었다. 도구 정의와 도구가 돌려준 것이 자리를 차지한다.

그래서 도구를 지금 있는 API를 그대로 비춘 것으로 만들면 안 된다고 말한다. 모델이 보고 싶어 하는 모양으로 짜야 한다는 것이다.

구체적인 사례가 하나 나온다. 사내 프로젝트에서 도구가 내놓는 형식을 JSON에서 YAML로 바꾼 것만으로 눈에 띄게 달라졌다. 이유는 토큰이 덜 들고 모델이 훑기 쉬워서다.

갈린 자리가 여기다. 코드가 보기에 둘은 같은 구조화 데이터인데 모델이 보기에는 아주 다르다.

4. 새 모델이 나오면 판이 바뀐다

네 번째 교훈이다. 어느 기능을 두고 몇 달마다 같은 평가를 돌려 왔다고 말한다. 한동안 최고이던 모델이 있었고 그다음이 조금 나았고 그다음이 훨씬 나았다.

그러다 10% 수준이라 사용자에게 내놓을 수 없던 기능이 갑자기 쓸 만해졌다. 새 모델이 나온 지 2주 만에 그 기능의 첫 판을 내보낸다고 말한다.

그럴 수 있었던 이유는 하나다. 평가를 미리 돌려 두고 있었다.

그래서 권한다. 오늘 모델로는 아직 안 될 만큼 야심 찬 평가를 만들어 두고, 새 모델이 나오면 바로 갈아 끼워 볼 수 있게 짜 두라는 것이다. 모델 공급자를 바꿔도 코드를 안 고쳐도 되게 사이에 무언가를 끼워 두라고 덧붙인다.

솔직한 대목도 있다. 어느 회사가 막 내놓은 모델이 이 벤치마크에서 1%를 받아 아예 표에 넣지도 않았다고 말한다. 그러면서 오늘 나온 것은 훨씬 나을 수도 있고 이 발표가 끝나면 몇 번 두드려 확인할 수 있다고 덧붙인다.

5. 프롬프트만 고치지 마라

다섯 번째다. 판을 셋으로 본다. 평가에 쓰는 데이터, 할 일(프롬프트와 에이전트 얼개와 도구), 채점 함수다.

같은 벤치마크로 두 번 돌렸다고 말한다. 한 번은 프롬프트만 주고 이것을 고치라 했고, 한 번은 프롬프트와 데이터와 채점표를 함께 주고 이 판을 고치라 했다. 차이가 극적이었고, 다시 한 번 못 쓰던 것이 쓸 수 있는 것으로 바뀌었다.

이어서 그 일을 자동으로 해 주는 자사 기능을 그날부터 연다고 소개한다. 프롬프트를 고쳐 달라거나, 이 데이터셋에서 빠진 것이 무엇이냐거나, 왜 점수가 낮거나 높으냐거나, 지금 것보다 더 깐깐한 채점표를 짜 달라는 요청이 잘 먹혔다고 말한다.

닫는 말이 세다. 새 모델이 나오면 알아채는 데서 그치지 말고 지금 얼개를 통째로 뜯어내 완전히 새 얼개로 갈아 끼울 각오까지 하라는 것이다.

6. 청중이 되물은 것

이 발표에서 가장 값나가는 대목이 질의응답에 있다.

한 사람이 묻는다. 사용자 피드백을 전부 평가로 넣으면 *과적합이 되는 것 아니냐.

답이 뒤집혀 있다. 사용자 피드백 없이 데이터셋에 과하게 맞춰지는 쪽이 더 걱정된다는 것이다. 그러면서 자기네 제품은 피드백을 자동으로 데이터셋에 넣지 않는다고 밝힌다 — 안목 있는 사람이 골라 넣기를 바란다는 이유다.

다른 사람이 자기 현장 이야기를 보탠다. 세금 답변에 사용자가 싫다고 누르는데, 그래서 「답은 맞는데 그냥 마음에 안 든다」를 따로 누를 자리를 만들었다고 말한다.

또 다른 사람은 모델을 여러 번 바꿔 봤지만 큰 차이를 못 느꼈다고 말한다. 발표자는 모든 벤치마크가 그런 것은 아니라고 답한다. 영화 대사로 어떤 영화인지 맞히는 평가는 오래전 모델부터 계속 잘 됐다는 예를 든다.

7. 발표가 밝히지 않은 것

가장 중요한 대조에 수가 없다. 프롬프트만 고칠 때와 판 전체를 고칠 때가 극적으로 갈렸다고 말하는데, 두 값이 얼마였는지가 없다.

JSON에서 YAML로 바꾼 사례도 마찬가지다. 눈에 띄게 달라졌다고만 하고 무엇이 얼마나 달라졌는지가 없다.

10%가 무엇의 10%인지 없다. 어떤 채점표로 잰 값인지, 얼마가 되어야 쓸 만한지가 없다.

1%도 한 벤치마크의 값이다. 발표자 스스로 이것이 모든 벤치마크에 해당하지 않는다고 말한다. 그러니 그 수로 모델의 우열을 읽으면 안 된다.

자막이 모델 이름을 뭉갠다. 판을 견주는 대목에서 이름과 번호가 여러 군데 어긋나 있어, 어느 판이 어느 판보다 나았다는 순서만 남고 정확한 이름은 원문에서 갈린다.

24시간과 2주는 남의 값과 자기 값이다. 24시간은 다른 회사 사례이고 2주는 자기네 것이다. 견줘서 얻은 값이 아니다.

1. 왜 다시 짜야 하나

평가와 관측을 파는 회사의 현장 CTO가 발표한다.

시연을 만드는 일은 쉬운데 내보낼 만한 물건으로 만드는 일이 어렵다는 것을 다들 겪었을 거라고 연다. 어려운 이유가 잘못 만들어서가 아니라 둘러싼 것들이 빠르게 바뀌기 때문이라고 말한다.

판이 바뀔 때마다 그것이 조금 나아진 것이 아니라 계단처럼 뛰었다고 말한다. 그래서 지금은 고쳐 쓰는 단계에서 아예 바닥을 다시 까는 단계로 넘어가고 있다는 것이다.

새 모델을 그냥 끼워 넣는 것으로 안 되는 이유가 여기서 나온다. 지금 시스템은 예전 모델의 못하는 자리를 전제로, 그것을 피해 가는 논리를 잔뜩 넣어 지은 것이기 때문이다.

2. 루프로 갔다 그래프로 왔다 다시 루프로

발표는 실제로 쓰는 운영 에이전트 하나를 놓고 판마다 무엇이 달라졌는지 짚는다.

맨 처음은 프롬프트 하나에 호출 하나였다. 그다음이 꺼내 와서 붙여 넣는 구조다. 입력을 읽고, 그것으로 자료를 찾고, 맥락을 만들어 모델에 넘긴다.

그다음이 모델이 스스로 다음 걸음을 정하는 루프다. 사용자의 뜻이 채워지거나 반복 예산이 다할 때까지 돈다. 발표는 여기서 솔직하다 — 생각은 아주 신났는데 약속한 것을 못 지켰다. 도구 인자를 틀리고 순서를 못 짰기 때문이다.

그래서 팀들이 순서와 실행과 계획을 시스템 쪽에 직접 짜 넣는 그래프로 옮겼다. 정해 둔 쓰임에는 잘 돌았는데, 정해 둔 범위 밖의 요청이 들어오면 무너지기 시작했다. 그것을 메우려 갈래를 계속 붙이자 터질 자리가 크게 늘었다.

그다음이 이 발표의 뒤집기다. 도구 호출이 믿을 만해지고 긴 일을 끌고 가는 힘이 붙자, 그래프로 짠 시스템들이 그 새 능력을 못 쓰게 됐다. 그래서 루프를 다시 짰고 이번엔 돌기 시작했다.

판마다 평가가 무엇을 봤나

3. 한 번 재는 걸로 안 된다

루프로 돌아오자 새 문제가 생겼다. 같은 입력을 몇 번 돌리면 지나는 길이 매번 딴판이었다.

그래서 재는 단위가 바뀐다. 한 번 재는 것이 아니라 같은 평가를 K번 돌려 그 분포를 본다.

여기서 두 수가 갈린다. K번 중 한 번이라도 되는지는 그 일을 할 힘이 있느냐를 재는 것이고, K번 중 몇 번이나 되는지는 믿을 만하냐를 재는 것이다. 둘은 다른 것을 재므로 하나로 합쳐지지 않는다.

4. 시스템이 제품이 됐다

요즘 것은 루프를 도는 모델 하나가 아니라고 말한다. 둘레에 부품이 붙었다.

붙은 부품

그러니 지난 판의 평가를 그대로 쓰면 새로 생긴 터질 자리를 못 본다. 시스템을 반쯤만 덮게 된다는 것이다.

그래서 발표가 세우는 말이 이것이다. 오래가는 자산은 시스템이 아니라 평가다 — 시스템이 어떻게 굴러야 하는지를 적어 둔 것이 평가이기 때문이다.

5. 돌리기로 해 놓고 안 돌린다

내보낸 뒤의 자료를 걷어 평가에 되먹이는 *돌개바퀴 그림에는 다들 머리로는 동의한다고 말한다.

그런데 실제로는 많은 팀이 그 일을 안 해서 평가가 굳은 채로 남는다고 짚는다. 이 발표에서 가장 아픈 한 줄이다.

판이 갈릴 때는 이미 아는 실패만이 아니라 새로 생길 실패에도 빛을 비출 장치가 필요하다고 말한다. 여기서부터 자기 회사 기능 소개로 넘어간다 — 내보낸 자료 전체를 묶어 보아 예상 못 한 실패 갈래를 찾아 준다는 것이다.

닫는 말은 이렇다. 모델은 계속 바뀔 것이고 아직 평평해지지 않았다. 그러니 앞으로도 에이전트에 큰 수술을 계속하게 될 것이라고 말한다.

6. 발표가 밝히지 않은 것

잰 값이 하나도 없다. 판이 바뀌며 무엇이 얼마나 나아졌는지, 그래프에서 루프로 돌아왔을 때 무엇이 얼마나 달라졌는지가 나오지 않는다.

K를 얼마로 잡아야 하는지가 없다. 여러 번 돌려 분포를 보라고 하면서 몇 번이 적당한지, 그만큼 돌리는 값이 얼마인지가 없다.

「범위 밖이면 무너진다」의 근거가 없다. 그래프가 무너지기 시작했다고 말하는데 얼마나 자주 그랬는지가 없다.

군집으로 찾아 준다는 기능에 사례가 없다. 무엇을 실제로 찾아냈는지, 그것이 놓치고 있던 것이었는지가 나오지 않는다.

견줄 기준선이 없다. 이 방식과 다른 방식을 나란히 놓고 잰 자리가 한 군데도 없다.

1. 평가가 망가졌다는 세 가지

두 사람이 나온다. 한 명은 벤치마크 쪽 제품을 맡고, 한 명은 소프트웨어를 만든다고 밝힌다. 3천만 명 넘게 쓰는 커뮤니티라고 소개하며, 지난 두 해를 이 문제에 썼다고 말한다.

첫째, 흩어져 있고 금세 낡는다. 새 벤치마크가 하루에 열 개 넘게 나오는데 그것을 찾는 방법이 논문 목록을 몇 시간씩 훑는 것뿐이다. 게다가 만든 사람들이 다음 논문으로 넘어가 버려 순위표가 시간이 갈수록 뜻을 잃는다.

둘째, 속이 안 보이고 다시 해 볼 수도 없다. 사례가 구체적이다. 어느 연구소와 함께 벤치마크를 냈더니 경쟁 연구소가 결과가 마음에 안 든다며 직접 돌려 훨씬 좋은 값을 냈다. 갈린 이유는 자기 API가 주는 압축 기능을 자기 모델에만 켰기 때문이었다. 이쪽은 어느 모델에도 그것을 안 켰다.

셋째, 만드는 사람이 너무 적다. AI 연구자가 3만 명 남짓인데 기술 쪽 사람은 3천만 명이라고 말한다. 다만 이 수는 검색해서 얻은 것이라고 스스로 밝힌다.

이어지는 논리가 이 발표의 뼈대다. 재지 않는 것은 얼마나 잘하는지 알 수 없고, 알 수 없으면 올라갈 수도 없다. 그래서 모델이 잘하는 데와 못하는 데가 더 들쭉날쭉해질 것이라고 말한다.

2. 아무도 안 만드는 평가

사례 하나를 든다. 튀르키예에 사는 20년 경력의 폐수처리장 기사가 자기 경험으로 평가를 만들었다.

계기가 무겁다. 그 나라에서 안전 절차를 지키지 않아 사람이 죽은 사고가 있었고, AI가 자기 일에서 그것을 도울 수 있는지 재려고 만들었다는 것이다.

그러면서 짚는다. 이 자료는 웹 어디에도 없고, 어느 연구소의 관심 밖이다. 지금으로서는 돈이 안 되기 때문이다.

3. 내놓은 것 넷

네 갈래

해커톤은 지금 딥마인드 쪽 팀과 함께 돌리는 중이라고 말한다. 몇 주 전 낸 논문이 인지 능력을 열 갈래로 나눴는데 그중 다섯에 집중해 열었다는 것이다.

여기서 실무적인 어려움이 나온다. 참가자가 천 명이면 자료를 어디에 두고 모델에 어떻게 닿게 할지가 문제다. 형편이 어려운 참가자는 앞선 모델들에 닿으려고 열쇠 다섯 개 값을 낼 수 없다고 짚는다.

또 하나. 새로움과 창의성을 판정하는 데는 에이전트가 아직 서툴러서 사람 전문가가 필요한데, 전문가끼리 판단을 맞추는 것부터 쉽지 않다고 말한다.

에이전트 시험은 지난주에 낸 것이라고 밝힌다. 이름을 원래 다르게 붙였다가 상표 문제로 바꿨다고 한다. 일주일 만에 에이전트 500개 넘게 시험을 치렀다.

난이도를 두고 하는 말이 정직하다. 너무 어려우면 끝내는 사람이 없고 너무 쉬우면 쓸 만한 신호가 안 나온다.

앞으로의 쓸모로 하나를 든다. 에이전트를 받은편지함이나 계정을 맡기러 내보내기 전에 안전 쪽으로 기준선을 잡는 시험이다.

4. 게임으로 재기

게임 아레나는 벤치마크가 금세 *포화되는 문제에 대한 답이다. 서로 겨루게 하면 한쪽이 늘 다른 쪽과 붙을 수 있어 끝이 안 난다는 것이다.

크게 공들인 게임으로 셋을 든다. 속이는 능력을 보는 인랑, 무작위를 다루는 포커, 그리고 체스다.

포커에서 나온 관찰이 재미있다. 어떤 모델은 판돈을 다 거는 것을 즐긴다. 그리고 뒤집힌 대목 — 최신 세대 중 일부는 위험을 더 피하려 들어서 포커를 더 못한다.

값도 나온다. 뜻있는 차이를 얻으려고 포커를 40만 판 돌려야 했다.

만드는 순서도 밝힌다. 게임을 고르고, 모델이 실제로 둘 수 있는지 보고, 프롬프트가 공정해지도록 오래 다듬는다. 그 뒤 껍데기를 짜고 돌리고, 겨룰 짝을 정하는 데는 짝지어 견주는 방식을 쓴다. 오간 대화는 자료로 공개하고 *엘로 점수와 함께 낸다. 전부 열려 있다고 말한다.

스스로 아쉬워하는 대목도 있다. 모델끼리 두는 것을 지켜보는 일이 좀 지루해진다는 것이다. 그래서 사람들이 프롬프트를 내는 식으로 끌어들일 방법을 궁리 중이라고 한다.

5. 무엇이 점수를 가르나

이 발표에서 가장 값나가는 한 줄이 여기 있다. 남의 글에서 끌어온 것이다.

어느 코딩 벤치마크에서 앞선 모델 여섯이 서로 몇 퍼센트포인트 안쪽이었다. 그런데 정말 크게 나눈 것은 어느 하네스 안에서 도느냐였고 그 차이가 22퍼센트포인트였다.

발표자는 곧바로 단서를 단다. 자기가 확인해 본 것은 아니고 그럴듯해 보인다는 것이다.

시간을 건너 견주는 일도 어렵다고 말한다. 옛 모델은 사라지고 새 모델이 오는데, 어떤 창구는 뒤에서 실제로 무엇이 도는지 정직하게 알려 주지 않는다고 한다.

6. 평가가 쌓이는 세 칸

벤치마크 쪽은 내보내기 전에 쓰는 판이 아니라 사람들을 끌어들이는 판이라고 못 박는다.

짜임은 단순하다. 코드로 못 박는 단언을 쓰고, 판정이 어려운 자리에는 모델을 부른다. 그것들이 과제로 묶이고 과제들이 다시 벤치마크로 묶인다.

직전 발표자가 만든 과제를 예로 든다. 그림 파일을 읽어 다시 그려 보게 하는 것이고, 글자가 맞는지 따위를 단언으로 걸었다.

어려움도 밝힌다. 사람들이 평가를 만들게 부추기는 일 자체가 어렵다. 해커톤과 점수·훈장 같은 장치가 도움이 됐다고 한다.

마지막 말이 이 발표에서 가장 무겁다. 모델 하나를 재던 데서 에이전트가 무엇을 하는지로 옮겨 오면서, 우리가 대체 무엇을 재고 있는지 알기가 훨씬 어려워졌다.

7. 발표가 밝히지 않은 것

22퍼센트포인트는 남의 값이고 확인 안 했다. 발표자가 직접 그렇게 말한다. 어느 벤치마크 하나에서 나온 값이라는 것도 새겨야 한다.

3만과 3천만은 검색해서 얻은 수다. 발표자가 그 출처를 그렇게 밝힌다.

시험 500개의 속이 없다. 무엇을 치렀고 점수가 어떻게 갈렸는지가 없다.

40만 판이 무엇을 말해 주는지가 없다. 그만큼 돌려야 했다는 것만 나오고 그래서 무엇이 갈렸는지, 값이 얼마나 들었는지가 없다.

폐수처리 사례의 결과가 없다. 그런 평가를 만들었다는 것까지만 나오고 모델이 거기서 어땠는지가 없다.

압축을 켜고 낸 그 사건의 뒤가 없다. 다시 맞춰 돌렸는지, 어느 쪽이 맞았는지가 나오지 않는다.

1. 프롬프트 짜기는 글쓰기다

앤스로픽에서 모델 쪽 일을 한다는 사람이 발표한다. 하는 일의 대부분이 사람들과 짝을 지어 프롬프트를 함께 만지는 것이라고 말한다.

깔아 두는 설명은 이렇다. 모델은 앞말이 주어졌을 때 다음 말의 확률을 셈하고, 안에 든 장치가 입력의 어느 자리를 볼지 정한다. 그러니 잘 짠 프롬프트는 그 눈길이 맞는 자리를 향하게 하는 것이다.

그리고 값 이야기가 붙는다. 프롬프트로 나아지는 이유는 다시 학습시키지 않고 쓰는 순간의 계산만으로 되기 때문이다.

이 일을 창작 글쓰기의 한 갈래로 부른다. 대학에서 창작 수업의 글제 과제를 하던 일에 빗댄다.

2. 왜 어려운가

막히는 자리를 셋으로 나눈다.

원하는 것은 아는데 모델에서 가장 좋은 것을 끌어내는 법을 모르는 경우, 원하는 것을 어렴풋이만 알아 설명하지 못하는 경우, 그리고 원하는 것 자체를 모르는 경우다.

셋째와 둘째에 대한 처방이 같다. 예시를 여럿 준다. 다만 조건이 붙는다 — 서로 다르게, 그리고 가장자리 경우까지 담아서 준다.

이 일을 가설을 세워 보는 일이라고 부른다. 이걸 할 수 있나 없나를 묻고 시험해 보는 것이고, 되풀이할수록 그 모델의 강점과 약점이 손에 잡힌다는 것이다.

3. 태그를 안 쓰는 실수

가장 자주 짚는 실수가 하나 있다. 아무것도 태그 안에 넣지 않는 것이다. 그래서 성능을 못 낸다고 말한다.

왜 그런지도 밝힌다. 처음 맞춰 학습시킨 형식이 그것이었기 때문이다. 나중에야 고객들이 다른 형식도 필요로 한다는 것을 알게 됐다고 말한다.

청중이 다른 형식과 견줘 봤느냐고 묻자 이렇게 답한다. 태그를 쓰면 거의 다 맞고 다른 형식은 그만큼은 아니다.

첫 사례는 옷을 골라 주는 일이다. 아무 안내 없이 관련 있는지만 묻는 *제로샷으로 시작하고, 이게 완벽한 물건은 아니다라고 그 자리에서 인정한다.

그다음 둘을 얹는다. 하나는 판단 전에 생각할 자리를 따로 주는 것이고, 다른 하나는 예 아니오 대신 1에서 10으로 점수를 매기게 하는 것이다. 기준을 함께 적어 준다 — 이를테면 여름에 겨울옷을 권하지 말라는 식이다.

4. 적어 놓은 생각이 진짜 생각은 아니다

이 발표의 가운데다.

생각을 적게 하는 방법은 적어 놓은 추론이 실제 추론을 그대로 비춘다는 것을 전제로 한다. 그런데 최근 논문에서 늘 그렇지는 않다는 것을 찾았다고 말한다.

대안이 쪼개는 쪽이다. 물음을 혼자서도 뜻이 통하는 작은 물음들로 나누고, 각각을 따로 떼어 놓은 자리에서 답하게 한 뒤, 그 답들을 한자리에 모아 다시 묻는다.

효과도 든다. 그렇게 하면 한쪽으로 쏠리는 정도가 준다는 것이다. 답하기 과제에서 앞의 방법에 가까운 성능을 내면서 적어 놓은 것과 실제가 어긋나는 정도는 나아졌다고 말한다.

쪼갤 때 붙이는 조건도 실용적이다. 필요 이상으로 쪼개지 말라는 것이다.

5. 긴 문서에서 찾아내기

사내 실험을 소개한다. 목표는 긴 문서에서 특정한 것을 제대로 떠올릴 확률을 높이는 방법을 재는 것이었다.

설계가 깔끔하다. 고른 문서가 학습을 끊은 시점보다 뒤의 것이다. 미리 알고 있는 것으로 맞히는 일을 막으려는 것이다.

방법은 문서를 토막 내고 토막마다 객관식 다섯 문제를 만들되 오답을 셋 붙인다. 그러고 그 토막들을 무작위로 다시 붙여 아주 긴 문서로 만들어 시험한다.

무엇을 바꿔 가며 쟀나

왜 뒤가 나은지는 가설만 댄다. 끝쪽에 더 눈길이 간다는 것이고, 가운데를 잊는다는 논문이 있지만 그 논문을 읽지 않았고 여기에 그대로 들어맞는지도 확인하지 않았다고 밝힌다.

6. 실무 요령

발표가 든 것들

여러 번 뽑아 고르는 방법은 셈이 딱 떨어지는 일에 주로 쓸모 있다고 단서를 단다.

마지막 물음에 답하며 앞을 내다본다. 프롬프트 짜는 일은 남을 것이고, 지어낸 자료를 쓰는 일이 늘 것이며, 사람이 매기는 대신 모델이 매기는 쪽이 더 크게 키울 수 있는 길이라고 말한다.

7. 발표가 밝히지 않은 것

두 판 앞의 이야기다. 여기 나오는 모델 이름과 맥락 길이가 지금 것이 아니다. 발표자 스스로도 그때는 옛 판을 썼고 새 판이 훨씬 나을 것이라고 말한다. 그러니 태그니 물음 자리니 하는 요령은 지금 판에서 다시 재야 한다.

거의 다 맞는다는 말에 수가 없다. 태그를 쓰면 그렇다고 하는데 무엇을 몇 개나 재서 나온 값인지가 없다.

뒤에 두는 쪽이 낫다는 것에도 값이 없다. 얼마나 나은지가 없고, 왜인지는 본인이 확인 안 했다고 밝힌다.

쪼개는 방법의 값이 없다. 한 자리에서 푸는 쪽에 「가까운」 성능이라고만 하고 얼마나 가까운지가 없다. 대신 몇 번을 부르게 되는지, 그만큼 값이 얼마나 드는지도 없다.

작은 쪽에서 더 올랐다는 것도 폭이 없다. 어느 쪽이 결국 더 잘했는지도 나오지 않는다.

세부는 블로그와 문서로 넘긴다. 실제 프롬프트는 글에서 보라며 지나간다.

1. 무엇을 끝내겠다는 것인가

취향을 다루는 회사를 세운 사람이 발표한다. 얼마 전에야 밖으로 나온 회사라고 밝힌다.

AI가 코딩과 수학에는 꽤 능해졌는데 디자인·창작 글쓰기·성격·감정 다루기에는 크게 뒤처져 있다고 연다.

여기서 뒤집는 말이 나온다. 코드가 잘 되는 것은 모델의 성질이 아니라 코드의 성질이라는 것이다. 코드는 쪼개지고, 확인되고, 돌아간다.

그래서 오늘 다룰 성질 둘을 든다. 첫째는 잴 수 있는 만큼만 할 수 있게 된다는 것이고, 둘째는 뒤에 나올 가운데로 모인다는 것이다.

2. 「훌륭하게」가 아니라 「브랜드에 맞게」

좋은 디자인이 무엇이냐고 물으면 답이 갈린다고 말한다. 누구를 위한 것인지, 어떤 자리인지에 따라 다르다. 같은 장표가 스타트업에는 훌륭하고 금융회사에는 부적절할 수 있다. 게다가 좋음의 기준이 시간과 함께 바뀐다 — 코드와 수학에는 없는 성질이다.

그래서 문제를 바꿔 든다. 「훌륭한 것을 만들라」는 어렵고 「브랜드에 맞는 것을 만들라」는 훨씬 정의하기 쉽다.