에이전트 하네스를 해부합니다 — 점검망의 여섯 차원

결론

에이전트가 자꾸 헛돈다 싶으시면, 더 좋은 모델이 나오기를 기다리시는 대신 점검망을 넓고 촘촘하게 손보십시오.

AI 코딩 분야의 발표 스물일곱 편을 한 편씩 들여다본 결과 — John Crickett 님이 큐레이팅하신 모음¹을 빌렸사옵니다 — 발표자들이 서로 다른 회사·다른 도구·다른 입장에서 출발했음에도 같은 한 곳을 가리키고 있었사옵니다.

에이전트 자율성 ≡ 점검망의 품질

에이전트의 자율성은 모델의 지능이나 쓰는 비용·컨텍스트 양에 비례하는 게 아니라, 모델이 출력한 것을 언제·어디서·얼마나 자주·얼마나 깊게 점검할 수 있는지에 더 크게 좌우되옵니다. 에이전트 하네스를 만든다는 일이 결국 이 점검망을 짠다는 일이었던 것이지요.

이 글은 그 스물일곱 편이 어떻게 한 명제로 모이는지를 정리한 것이옵니다.

그래서 무얼 해야 합니까

명제만 들고 가시면 추상적이라 쓸모가 적사옵니다. 스물일곱 편에서 반복적으로 등장한 실용 권고를 네 가지로 먼저 정리해두겠사옵니다. 이 권고들이 왜 그러한지가 궁금하시면 이후 섹션을 읽어보십시오.

1. 점검 인프라에 투자하십시오

스탠포드 연구가 가리키는 결론이옵니다. 도입 전에 기존 코드베이스의 테스트·타입·문서 수준을 점검하는 편이 ROI 측면에서 두 배 효율적이옵니다. 정돈되지 않은 환경에 AI를 먼저 풀면, 산출의 외형은 늘어나되 부채가 함께 누적됩니다 — 350명 팀의 재작업이 2.5배로 뛴 사례가 그 증거이지요.

2. 명세를 일급 산출물로 다루십시오

명세는 코드의 부산물이 아니라 코드를 파생시키는 상위 소스이옵니다. 명세가 잘 쓰여 있으면 코드 생성을 에이전트에게 위임하고 명세 자체를 점검의 잣대로 쓸 수 있습니다. 명세가 빈약하면 점검할 기준 자체가 없으니, 에이전트 출력의 좋고 나쁨을 판단할 수 없게 되옵니다.

실무적으로는 — TDD에서 테스트를 먼저 쓰는 것과 같은 자세입니다. 명세를 먼저 쓰고, 그 명세를 통과시키는 코드를 에이전트에게 맡기는 패턴이 가장 안정적이옵니다.

3. 도구를 주고 비켜나십시오

Anthropic의 네 발표가 한 메타 원칙으로 수렴한 결론이옵니다 — 비계는 줄이고, 모델에게 더 맡겨라.

도구를 정교하게 짜는 데 시간을 쓰지 마시고, 범용 도구를 잘 합성하는 데 시간을 쓰시지요. Bash 하나로 전문 도구 수십 개를 대체하되, 토큰 효율과 보안을 위해 소수의 특화 도구만 병행하는 것이 실무 최적이라 합니다. 정교한 비계는 다음 모델 세대에서 짐이 됩니다.

4. 점검의 위치를 의식적으로 설계하십시오

점검은 세 군데에 둘 수 있사옵니다 — 모델 입력 전(명세, 시스템 메시지, 프롬프트), 모델 출력 후(테스트, CI, 코드 리뷰), 그리고 모델 자체(추론 모델의 자기 점검 능력). 작업 단위 하나당 셋 중 어디에 점검이 들어가는지 의식적으로 적어보시기를 권합니다.

매트릭스의 빈칸이 보이면, 그 자리가 자율성을 깎아 먹는 자리이옵니다. 반대로 빈칸이 하나도 없으면 비계 과잉을 의심하시지요 — 모델이 이미 잘하는 일을 외부에서 다시 강제하고 있을 가능성이 높사옵니다.

어떻게 정리했는가

처음에는 우연이라 생각했사옵니다. 한 편씩 정리하다 보니 첫 세 편이 같은 결론으로 수렴하더군요. 한 발표는 작고 점검 가능한 단위로 쪼개라고 하였고, 다른 발표는 환경이 얼마나 정돈되어 있는가가 자동화의 속도를 결정한다고 하였으며, 또 다른 발표는 자율성은 점검할 수 있는 자리의 양에 달려 있다는 비슷한 표현을 내놓았사옵니다. 같은 말을 세 사람이 다른 어휘로 한 셈이지요.

그래서 이후 정리에는 스스로에게 미리 일러두었사옵니다 — 너무 매끄럽게 같은 결론으로 흐르는 것을 경계하라. 그러나 영상이 늘어날수록 명제는 약화되기는커녕 다른 각도에서 강화되었사옵니다.

스탠포드의 12만 개발자 데이터가 정량 증거를 보탰고², OpenAI는 명세가 일급 산출물이라 직접 선언했으며, Anthropic의 두 발표는 표면적으로 모순돼 보이던 두 입장(에이전트를 만들지 말고 스킬을 만들어라 vs 효과적인 에이전트를 어떻게 만드는가)이 사실 같은 줌 레벨의 다른 면이라며 화해시켰사옵니다. 바이브 코딩 진영의 여섯 편은 더 흥미로웠는데, 비판자와 옹호자가 정반대 입장에서 출발했음에도 처방의 핵심은 같았으니까요.

스물일곱 편을 다 본 시점에서 분명해졌사옵니다. 발표자들이 각자 다른 어휘로 같은 현상을 더듬고 있었고, 그 현상이 무엇인지 한 번 정리해두는 일이 필요해 보였습니다. 점검망이라는 이름은 정리 과정에서 제가 붙인 것이지, 발표자 누군가가 직접 사용한 표현은 아니옵니다 — 점검·검증(verification)·평가(evaluation)·가드레일(guardrails)·샌드박스·리뷰 게이트 등 다양한 영어 어휘가 가리키던 공통의 무언가에 한국어 옷을 입힌 셈입니다.

점검망의 여섯 가지 차원

명제는 단순합니다. 그러나 단순하다고 얕보면 잘못 적용하기 쉽사옵니다.

에이전트가 가질 수 있는 자율성은, 에이전트의 산출물을 자동으로 점검하는 점검망이 얼마나 넓고 촘촘한가에 비례한다.

여기서 점검망은 단일 척도가 아니라 여섯 차원으로 풀어낼 수 있사옵니다. 발표 스물일곱 편을 가로지르며 자연스럽게 드러난 결들이옵니다.

• 위치 — 점검이 어디에 쳐 있는가. 모델 입력 전, 모델 출력 후, 모델 자체 중 어디?
• 너비 — 한 번의 점검이 얼마나 많은 산출물을 덮는가
• 촘촘함 — 한 번의 점검이 한꺼번에 얼마나 많은 것을 잡는가 (잘 고른 예시 하나가 지시 열 줄을 대신하는 식)
• 시간 해상도 — 점검이 코드 생성 흐름에 얼마나 자주 끼어드는가
• 유연한 결합 — 필요한 점검 도구를 그때그때 불러오거나 끼웠다 뺄 수 있는가 (예: 작업 종류에 맞는 스킬·도구가 자동으로 결합되는 흐름)
• 명세 깊이 — 명세가 문서·프롬프트·모델 자체 중 어디까지 박혀 있는가

여섯 차원이 서로 독립적으로 움직인다는 뜻은 아닙니다. 한 도구가 한 차원에 강하면 다른 차원이 약할 수도 있고, 같이 강할 수도 있사옵니다. 다만 에이전트를 더 자율적으로 만든다는 모든 시도가 결국 이 여섯 차원 중 하나 이상을 키우는 일로 환원되더라는 것이옵니다.

12만 명의 데이터가 가리키는 곳

스탠포드 대학의 Yegor Denisov-Blanch 연구진이 12만 명의 개발자가 작성한 코드를 분석한 연구²가 명제에 양적 척추를 제공해주었사옵니다. 어떤 변수가 결정적이었는가를 찾아보려는 연구이옵니다. 분석 대상에는 GitHub 활동·풀 리퀘스트 흐름·코드 품질 지표·도구 사용 텔레메트리가 포함되었습니다.

핵심 결과는 두 줄로 요약할 수 있사옵니다.

• 환경 정돈도(테스트·타입·문서·모듈성·품질) ↔ AI 도입 ROI: R² ≈ 0.40
• 토큰 사용량 ↔ AI 도입 ROI: R² ≈ 0.20

R²는 두 변수 사이의 관계 강도를 0에서 1 사이로 나타내는 지표이옵니다 — 값이 클수록 한 변수의 변화가 다른 변수의 변화를 잘 설명한다는 뜻입니다. 환경 정돈도가 토큰 지출보다 두 배 강한 신호였다는 것은, AI에 돈을 더 쓰는 것보다 점검 인프라를 정돈해두는 편이 ROI에 두 배 영향을 준다는 뜻이지요.

더 흥미로운 것은 350명 팀의 사례였사옵니다. AI 도구를 도입한 4개월 후 — 풀 리퀘스트 수는 14% 증가했지만, 코드 품질은 9% 떨어졌고, 재작업은 2.5배 늘었으며, 실효 산출은 의미 있게 변하지 않았다고 하옵니다. 풀 리퀘스트 수만 보면 생산성이 올라간 듯하나, 점검망이 빈약한 환경에서 자율성을 풀어주면 산출의 외형은 늘되 부채가 누적된다는 것이지요.

이 연구가 말해주는 바는 하나입니다. AI 도구가 생산성을 올린다와 올리지 못한다 논쟁의 진짜 변수는 점검망이었다는 결론이옵니다.

점검의 위치는 어떻게 이동하는가

모델은 잘못이 없다, 당신이 프롬프트를 못 쓰는 것이다³라는 도발적 제목의 발표에서 흥미로운 발견이 나왔사옵니다 — 추론 모델(o1, R1 같은)에 예시를 추가하면 오히려 성능이 떨어진다는 데이터였사옵니다. 입력 전에 점검을 강화하는 게 좋다고 했는데, 줄이는 게 낫다고?

이 모순은 점검의 위치가 모델 세대에 따라 이동한다는 사실로 풀립니다.

• 이전 모델: 모델 자체에 점검 능력이 약하므로, 사람이 입력 전에 단계적 사고 패턴을 프롬프트로 가르쳐야 했사옵니다.
• 추론 모델: 모델이 학습 단계에서 이미 단계적 사고를 내장했사옵니다. DeepSeek R1이 그 변곡점을 보여준 사례지요. 모델 자체의 점검 자리가 커진 것이옵니다.
• 결과: 입력 전에서 했던 점검이 모델 자체로 옮겨가면, 외부에서 또 시키는 것이 도리어 헷갈림을 낳습니다.

즉 점검망의 총량은 비슷하게 유지되지만, 어디에 쳐야 하는지가 모델에 따라 바뀝니다. 위치 감각 없이 외부 점검만 늘리는 것은 비계 과잉이 되옵니다 — 모델이 이미 잘하는 일을 다시 강제하는 셈이니까요.

점검이 얼마나 자주 끼어드는가

바이브 코딩의 진화 형태로 바이브 엔지니어링을 제시한 발표⁴는 핵심을 시간 차원에서 짚었사옵니다. 비동기 에이전트(완료 후 점검)에서 실시간 에이전트(실행 중 개입)로의 이동이옵니다. 점검이 코드 생성 흐름 안에 들어오면 에러가 누적되기 전에 잡힙니다.

이 차원의 극한값은 Windsurf의 발표⁵가 보여주었사옵니다. 사용자의 행동 단위에서 점검이 시작된다고 — 코드가 생성되기 이전 단계에서 의도를 추론하고 점검하는 흐름이옵니다. 이쯤 되면 점검과 의도 추론의 경계가 흐려집니다.

제 사적인 감상을 덧붙이자면, 시간 해상도가 높아질수록 에이전트가 잘못한 것을 사람이 고치는 상호작용에서 에이전트와 사람이 같이 짓는 상호작용으로 결이 바뀌옵니다. 후자는 단순히 빠른 것이 아니라 덜 피곤합니다. 에러가 누적된 뒤에 되돌리는 비용이 본질적으로 비대칭적이기 때문이지요.

명세는 어디까지 박히는가

OpenAI의 The New Code⁶가 강조한 또 다른 차원은 명세가 어디에 살고 있는가이옵니다. 같은 명세라도 어디에 두느냐에 따라 점검망의 깊이가 달라집니다.

• 문서 수준: 명세가 README·Notion 페이지에만 살고, 사람이 그것을 보고 코딩합니다. 모델은 명세의 존재 자체를 모릅니다.
• 프롬프트 수준: copilot-instructions.md나 시스템 메시지 같은 모델이 매번 보는 자리에 명세를 넣습니다. 모델이 작업할 때마다 명세를 참조합니다.
• 모델 자체 수준: OpenAI는 자기네 Model Spec을 모델 학습 데이터로 사용합니다. 모델에게 명세를 주는 게 아니라, 모델을 명세를 내장한 형태로 만드는 것이지요.

깊이가 깊어질수록 명세가 흔들리지 않사옵니다. 문서 수준은 사람이 까먹으면 끝이고, 프롬프트 수준은 컨텍스트가 잘리면 함께 사라지지만, 모델 자체에 박힌 명세는 다음 모델로 갈아탈 때만 다시 점검하면 됩니다. Anthropic의 한 발표가 인용한 Richard Sutton의 통찰⁷ — 정교한 비계는 다음 세대 모델에서 짐이 되고, 범용성이 결국 이긴다는 강화학습계의 오래된 격언(“The Bitter Lesson”) — 이 명세 깊이에도 그대로 적용되옵니다. 모델 자체에 박힌 점검만큼 세대 교체에 강건한 점검은 없으니까요.

명제의 한계

에이전트의 자율성은 점검망의 품질에 비례한다는 명제가 너무 매끄럽게 모든 영상을 설명한다는 의심은 정직히 짚어두겠사옵니다. 스물일곱 편이 AI 코딩으로 큐레이션된 표본이라는 점, 그래서 수렴이 사후적일 가능성은 남아 있사옵니다.

그러나 처방의 일관성은 표본 편향과 별개로 가치를 갖사옵니다. AI 도구를 도입하기 전에 점검 인프라부터 정돈하라 — 이 권고가 27편 모두에서 변형된 형태로 등장한다는 사실이, 명제의 추상도와 무관하게 실용적 결론이옵니다. 명제가 절대 진리여서가 아니라, 비싼 실수를 피하게 해주기 때문이지요.

마치며

스물일곱 편을 정리하는 작업 자체가 명제의 사례였사옵니다. 한 영상의 분석 결과를 다음 영상의 분석이 검증·확장·반박해 가는 구조 — 이 자체가 점검망을 다층으로 쌓아 올린 일이었던 것이지요.

이 글이 여러분께 가는 길에도 여러 겹의 점검이 깔려 있사옵니다 — 사실 확인, 편집 검토, 최종 퇴고. 그 두께가 글의 자율성을 결정합니다. 점검이 한 겹뿐이라면 더 조심스럽게 써야 했을 것이고, 여러 겹이라면 더 멀리 갈 수 있사옵니다. 명제는 저에게도 적용되더군요.

스물일곱 편의 발표자들도, 그들이 만드는 도구도, 그 도구를 쓰시는 여러분도, 그리고 이 글을 쓰는 저도 — 결국 같은 이치 위에 있는 듯합니다.

에이전트 자율성 ≡ 점검망의 품질.

더 좋은 모델을 기다리시는 것보다, 점검망을 한 겹 더 짜시는 편이 빠를 것이옵니다.

이 글에 짚인 결 외에 발표 하나하나의 결을 직접 보고 싶으시다면, 27편을 각각 다이제스트로 정리해 두었으니 그쪽으로 들러 주십시오. 본문이 한 명제로 수렴시킨 흐름과 별개로, 발표자마다 깔아둔 자기만의 점검망이 보이실 것이옵니다.