에이전트 엔지니어링 입문｜40만 세션이 보여 준 「맡기는 방식」의 설계

안녕하세요, 주식회사 TIMEWELL의 하마모토 류타입니다.

AI가 코드를 쓸 수 있는데, 왜 일부 엔지니어의 시장 가치는 오히려 올라가는가. 이 질문에 데이터로 답한 연구가 나왔습니다.

Anthropic이 2026년 6월 16일에 공개한 「Agentic coding and persistent returns to expertise」입니다. 약 23만 5,000명이 만든 약 40만 세션을, 2025년 10월부터 2026년 4월까지 7개월분, 프라이버시를 보호한 형태로 분석했습니다¹. 벤치마크가 아니라 실제 이용 데이터라는 점이 중요합니다.

읽고 나니, 제가 갖고 있던 전제가 몇 개 무너졌습니다. 순서대로 씁니다.

40만 세션이 보여 준 분업

가장 분명한 발견은 여기입니다. 원문의 표현을 가져옵니다.

people make about 70% of the planning decisions but only 20% of the execution decisions¹

사람은 계획 의사결정의 약 70%를 하고, 실행 의사결정은 약 20%밖에 하지 않는다. 뒤집으면, 어떻게 할지의 약 80%는 AI가 정하고 있습니다.

이 숫자가 좋은 이유는, 「AI가 사람 대신 코드를 쓴다」는 거친 이해를 깨 주기 때문입니다. 역할이 교체된 것이 아니라, 층으로 갈라진 것입니다. 사람은 건축가로 남고, AI가 시공을 맡는다. 그런 구조가, 누군가의 호령이 아니라 자연스럽게 생겨 있었습니다.

세션의 내용도 나와 있습니다¹.

용도	비율
코드의 작성·수정·테스트	약 56%(작성 25%, 수정 26%)
소프트웨어 조작	17%
계획·탐색	14%
분석·문서 작성	13%

절반 가까이가 코드를 쓰는 일 이외라는 점은 의외였습니다.

그리고 시계열의 변화가 더 재미있습니다. 7개월 사이에 디버깅용 세션은 33%에서 19%로 거의 반감했습니다. 한편 세션당 추정 가치는 27% 상승했습니다. 종류별로 보면 구축이 43%, 조작이 34%, 수정이 32% 상승¹.

고장난 것을 고치기 위해 쓰는 도구에서, 만들기 위해 쓰는 도구로 옮기고 있다고 읽을 수 있습니다.

전문성은 사라지지 않는다. 증폭된다

여기가 최대의 발견이라고 생각합니다.

「AI가 퍼지면 전문 지식은 필요 없어진다」는 이야기를 자주 듣습니다. 이 데이터는 반대를 보여 주었습니다.

검증된 성공, 즉 테스트가 통과했다, 커밋되었다는 식으로 확인할 수 있는 증거를 동반한 성공의 비율은 이렇습니다¹.

• 초심자로 평가된 세션: 15%
• 중급 이상: 28%에서 33%

Sessions rated expert reach verified success more than twice as often as those rated novice¹

전문가 세션은, 초심자보다 두 배 이상 자주 검증된 성공에 도달한다.

산출량이 더 알기 쉽습니다. 세션당 초심자가 약 600단어, 전문가가 약 3,200단어. 약 5배의 차이가 있습니다¹. 같은 AI에게, 같아 보이는 방식으로 말하고 있는데도 그렇습니다.

문제가 생겼을 때의 차이는 더 벌어집니다. 초심자 4%, 전문가 15%¹. 잘 안 되기 시작한 뒤의 수습에, 전문성이 분명히 먹고 있습니다.

왜인가. 전문성이 높은 사람은 일을 잘 잘라 내는 방법과 올바른 성공 조건의 정의를 할 수 있기 때문이라고 봅니다. AI는 지시의 질을 충실히 증폭합니다. 모호한 지시는 모호한 성과로, 정밀한 지시는 큰 성과로 이어집니다.

그리고 여기가 중요한데, 그 전문성은 소프트웨어 공학의 경험일 필요가 없습니다. 직종별 검증 성공률은 소프트웨어 관련직이 30%, 그 외 직종이 26%였습니다¹.

Every one of the ten largest occupations in our dataset lands within seven points of software engineers¹

데이터셋 상위 10개 직종 전부가, 소프트웨어 엔지니어에서 7포인트 이내에 들어와 있다. 먹고 있는 것은 코드를 쓸 수 있는지가 아니라, 자기 영역을 깊게 알고 있는지입니다.

자사의 AI 활용이 지금 어느 단계에 있는지를 한 번 정리해 두면, 이 뒤의 숫자가 남의 이야기가 아니게 됩니다.

측정해야 할 것은 「얼마나 오래 맡길 수 있는가」

모델 비교라고 하면 벤치마크 점수가 되기 쉽지만, 실무에서 알고 싶은 것은 다른 것입니다.

AI 안전 연구 기관 METR은 이런 질문을 세웠습니다. 「인간 전문가라면 몇 시간 걸리는 작업을, 어느 정도의 성공률로 완수할 수 있는가」. 이를 태스크 호라이즌이라고 부릅니다. 「50% 태스크 호라이즌이 1시간」이면, 사람이 1시간 걸리는 작업을 50% 확률로 성공시킬 수 있다는 뜻입니다².

METR은 약 230개의 작업으로 측정했습니다. 결과는 이렇습니다².

모델	50% 태스크 호라이즌
GPT-2	2초
Claude 3.7 Sonnet	50분
o3	약 2시간
Opus 4.6	약 12시간

2019년의 4초에서 2026년에는 16시간 초과. 장기의 평균으로 약 7개월마다 배가되고 있습니다².

다만, 여기는 소재로 삼은 자료보다 새로운 이야기가 있습니다. 최근은 가속하고 있습니다. 2024년에서 2025년에 걸쳐서는 약 4개월마다 배가되고 있으며, 이 속도가 이어지면 2027년에는 1개월 규모의 작업에 닿는다는 계산이 됩니다².

이 지표가 좋은 점은, 질문의 세우는 방식을 바꿔 준다는 것입니다. 「이 AI는 코드를 쓸 수 있는가」가 아니라, 「얼마나 큰 덩어리를, 중간을 감시하지 않고 맡길 수 있는가」.

그리고 맡기는 방식을 설계하는 기술의 가치는 복리로 늘어납니다. 오늘 3시간분밖에 맡기지 못해도, 배가 이어지면 내년은 9시간분, 그다음은 일 단위입니다. 설계의 손은 그대로여도, 맡겨 둘 수 있는 일의 양만 늘어갑니다. 지금 이 기술을 익혀야 하는 이유라고 생각합니다.

긴 작업에서 깨지는 것은 모델 탓이 아니다

그렇다면 크게 맡기면 되는가 하면, 그렇게 단순하지 않습니다.

Anthropic은 여러 컨텍스트 윈도우를 가로질러 프로덕션 품질의 웹 앱을 만들게 하는 실험을 했고, 그 실패를 공개했습니다³.

용어를 하나. 컨텍스트 윈도우란, AI가 한 번에 붙들고 있을 수 있는 정보량의 상한입니다. 대화나 코드가 이를 넘으면 오래된 것부터 사라집니다. 긴 작업에서는 반드시 부딪히므로, 일은 여러 세션으로 갈라집니다.

결과, 최첨단 모델에서도 시스템은 무너졌습니다. 원인은 모델의 지능이 아니라 환경 설계입니다. 깨지는 방식은 두 가지.

한 번에 전부 하려고 한다. 작업 전체를 한 세션에서 끝내려고 하다가, 어중간한 채로 힘이 빠진다.

기억이 끊긴다. 새 세션의 에이전트는, 직전에 무슨 일이 있었는지 전혀 모릅니다. 매번 제로에서 시작해 버립니다.

교대제 팀인데 인수인계가 전혀 없고, 매 시프트마다 신입이 백지로 출근해 오는 상태입니다.

해결책은, 허탈할 만큼 평범했습니다. 인간 팀이 오래전부터 해 온 일을, 그대로 하게 하는 것³.

초기화를 맡는 에이전트가 작업 전체를 이해하고 기능 단위로 분해한다. 코딩을 맡는 에이전트는 한 번에 기능 하나만 구현하고, 테스트를 돌리고, 커밋하고, 진행 파일을 갱신한다. 다음 세션은 먼저 진행 파일을 읽고 이어서 시작한다.

요컨대, 기억을 에이전트의 머리속이 아니라 바깥에 둔다는 것입니다. git 이력, 진행 메모, 테스트 결과. 이들은 컨텍스트가 바뀌어도 사라지지 않습니다. 에이전트는 전부 기억하고 있을 필요가 없고, 남겨 둔 것에서 상태를 복원할 수 있으면 됩니다.

돌아가는 시스템을 가르는 세 가지 원칙

이 실험에서 만들어진 하네스(에이전트를 둘러싼 발판과 제어 환경)의 핵심에 있는 생각은, 모델이나 도구를 가리지 않고 쓸 수 있습니다.

원칙 1. 기본값을 불합격으로 둔다.

모든 성공 기준을 처음에는 「미달성」에서 시작합니다. 에이전트가 「끝났습니다」라고 선언하는 것만으로는 완료가 되지 않습니다. 충족했음을 보여 주는 증거가 필요합니다.

이것이 없으면, 에이전트는 자기 숙제를 스스로 채점하고, 언제나 만점을 줍니다. 「테스트는 통과했습니다(실제로는 돌리지 않았다)」가 평범하게 일어납니다. 지나친 자신감을, 구조로 막는다는 발상입니다.

원칙 2. 평가하는 인격을 나눈다.

합격 여부의 판정은, 작업한 에이전트와는 별개의, 새하얀 맥락을 가진 평가 역할이 합니다. 이 평가 역할은 수정할 수 없습니다. 할 수 있는 것은 합부와 이유를 돌려주는 것뿐입니다.

사람 팀에서 코드를 쓴 본인이 리뷰하지 않는 것과 같은 이치입니다. 쓴 본인은 산출물에 너무 가까워 결함이 보이지 않습니다.

Anthropic의 글에는 이 지점에 강한 표현이 있습니다. 평가 역할이 없는 하네스는, 최첨단 모델이 평범한 출력을 내고 있을 때 조용히 실패한다³. 에러가 나지 않는 만큼, 눈치채지 못합니다. 여기가 무서운 지점입니다.

원칙 3. 인수인계 메모를 스스로 쓰게 한다.

커밋할 때마다 진행 파일을 갱신시킨다. 무엇을 했는지, 무엇이 남았는지, 다음이 알아 두어야 할 것은 무엇인지. 이 습관 하나로, 매번 리셋되는 시스템이 쌓이는 시스템으로 바뀝니다.

에이전트에게 무엇을 읽히고, 그 결과를 누구에게 넘길 것인가라는 통제의 설계는, Cloudflare OS는 왜 오픈소스인가에서도 다루었습니다. 권한을 제로에서 시작한다, 읽은 것을 기록한다. 발상은 같은 방향을 향하고 있습니다.

다만, 무엇이든 에이전트화하지는 않는다

반대쪽의 발견도 놓아 둡니다.

「Agentless」라는 연구에서는, 자율 에이전트를 쓰지 않고 문제 지점의 특정, 수정, 패치의 검증이라는 3단계 파이프라인만으로, 낮은 비용 그대로 높은 성과를 낼 수 있음이 보여졌습니다⁴.

여기서 배워야 할 것은 「에이전트가 언제나 우수하다」가 아닙니다. 복잡함은 작업에 맞춘다는 것입니다. 단순한 문제라면 단순한 장치가 이기고, 복잡하고 장기인 문제에서야 비로소 복잡한 에이전트가 수지가 맞습니다.

그리고 지금 자신이 어느 쪽에 있는지를 가리는 일 자체가, 기술의 대부분입니다. 못을 하나 박는 데 로봇 팔을 조립할 필요는 없습니다.

한편 환경의 중요성을 뒷받침하는 연구도 있습니다. 프린스턴 대학의 SWE-agent는, 모델은 새로운 종류의 컴퓨터 이용자이며, 전용으로 설계된 인터페이스를 필요로 한다는 통찰을 보여 주었습니다. 사람용 에디터를 그대로 쓰게 하는 것이 아니라, 에이전트의 움직임에 맞게 최적화한 도구를 주었더니, 모델은 아무것도 바꾸지 않았는데 성능이 올라갔습니다⁵.

하네스는 모델의 부속품이 아니라, 시스템의 절반입니다.

무엇부터 시작할 것인가

길어졌으니 정리합니다.

사람이 계획의 70%를 정하고, AI가 실행의 80%를 정한다. 전문성은 무가치해지지 않고, 산출량에서 5배의 차이로 나타난다. 맡길 수 있는 작업의 길이는 계속 배가되고, 최근은 4개월에 한 배. 그리고 차이를 만드는 것은 모델이 아니라, 그 주위에 두는 환경입니다.

실무로는, 이 순서라고 생각합니다.

첫째. 완결되는 작은 작업을 하나 맡기고 관찰한다. 「함수를 써」가 아니라 「이 버그를 고치고, 고쳤음을 증명하는 테스트를 쓰고, 둘 다 커밋해」. 시작과 중간과 끝이 있는 단위로 넘긴다. 그리고 지시와 성과가 어디서 어긋났는지를 본다.

둘째. 두 번 이상 설명한 규약을 파일에 적어 낸다. 기술 스택, 손대면 안 되는 곳, 테스트 쓰는 법, 커밋의 버릇. 한 번 쓰면 매번 읽힙니다. 같은 설명을 반복하는 시간이 사라집니다.

셋째. 진행 파일을 도입하고, 같은 작업을 두 번 돌린다. 인수인계가 있는 경우와 없는 경우로, 두 번째 첫머리에 무엇이 일어나는지를 비교한다. 외부 기억의 효과는, 체감하지 않으면 믿기 어렵습니다.

넷째. 평가 역할을 나눈다. 쓰기 권한 없음, 작업 이력의 지식 없음. 일은 산출물을 읽고 합부와 이유를 돌려주는 것뿐. 교정은 간단해서, 실패할 줄 아는 작업과 성공할 줄 아는 작업 양쪽에 건다. 전자를 떨어뜨리고 후자를 통과시키면 믿을 수 있습니다.

코드베이스를 구조로 갖게 하는 이야기는 그래프 엔지니어링이란 무엇인가에, Claude Code의 구체적인 기능은 Claude Code 완전 가이드에 정리했습니다.

솔직히, 이 연구에서 가장 힘을 얻은 것은 직종 이야기입니다. 상위 10개 직종 전부가 소프트웨어 엔지니어에서 7포인트 이내. 프로그래밍을 할 수 있는지가 아니라, 자기 일을 깊게 알고 있는지가 먹고 있습니다.

경리 베테랑이 월말 결산을 맡길 때도, 영업 에이스가 제안서를 맡길 때도, 승부를 가르는 것은 같은 세 원칙입니다. 증거로 확인한다. 다른 눈으로 본다. 넘길 수 있는 형태로 남긴다. 에이전트 엔지니어링은, 엔지니어만의 이야기가 아니라고 생각합니다.

AI 활용의 설계나, 사내에서 어떻게 맡기는 장치를 만들지 상담하고 싶은 분은 WARP의 생각이 참고가 될 수 있습니다. 개별 상담은 여기로 연락 주십시오.

---

Footnotes

1. Anthropic「Agentic coding and persistent returns to expertise」(Zoe Hitzig, Maxim Massenkoff, Eva Lyubich, Shaoyi Zhang, Ryan Heller, Peter McCrory, 2026년 6월 16일 공개). 약 23만 5,000명이 만든 약 40만 건의 대화 세션을 2025년 10월부터 2026년 4월에 걸쳐 프라이버시를 보호한 형태로 분석한 것. 「people make about 70% of the planning decisions but only 20% of the execution decisions」, 세션의 내역(코드의 작성·수정·테스트 약 56%(작성 25%, 수정 26%), 소프트웨어 조작 17%, 계획·탐색 14%, 분석·문서 작성 13%), 디버깅 세션 비율이 33%에서 19%로 낮아진 것, 세션당 추정 가치가 27% 상승하고 종류별로 구축 43%·조작 34%·수정 32%였던 것, 검증된 성공률이 초심자 평가 15%·중급 이상 28에서 33%인 것, 「Sessions rated expert reach verified success more than twice as often as those rated novice」, 문제가 생겼을 때의 성공률이 초심자 4%·전문가 15%인 것, 세션당 산출이 초심자 약 600단어·전문가 약 3,200단어인 것, 직종별 검증 성공률이 소프트웨어 관련직 30%·그 외 26%인 것, 그리고 「Every one of the ten largest occupations in our dataset lands within seven points of software engineers」는, 모두 같은 연구에 따른 것. https://www.anthropic.com/research/claude-code-expertise ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰

2. METR「Measuring AI Ability to Complete Long Software Tasks」및 관련 업데이트. 태스크 호라이즌은, 어떤 에이전트가 특정 성공률로 풀 수 있는 작업에 대해, 인간 전문가가 요하는 시간으로 정의된다. 약 230개의 작업(대부분은 코딩, 일부는 일반적 추론)으로 측정되며, 50% 태스크 호라이즌은 2019년의 4초에서 2026년에는 16시간 초과까지 늘었고, 장기에서는 약 7개월마다 배가되고 있다. 다만 2024년에서 2025년에 걸쳐서는 약 4개월마다의 배가였으며, 이 속도가 이어지면 2027년에는 1개월 규모의 작업에 도달할 수 있다고 한다. 모델별로는 GPT-2가 2초, Claude 3.7 Sonnet이 50분, o3가 약 2시간, Opus 4.6이 약 12시간. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/ ／ https://theaidigest.org/time-horizons ↩ ↩² ↩³ ↩⁴

3. Anthropic「Effective harnesses for long-running agents」(엔지니어링 블로그). 에이전트는 기억을 갖지 않는 이산적인 세션에서 작업해야 하며, 컨텍스트 윈도우가 유한하기 때문에 복잡한 프로젝트는 단일 윈도우에서 완료할 수 없다는 과제, 첫 실행 시 환경을 갖추는 초기화 에이전트와 각 세션에서 점진적으로 진척을 만들고 다음 세션을 위해 명확한 산출물을 남기는 코딩 에이전트라는 구성, 그리고 평가 에이전트를 갖지 않는 하네스는 최첨단 모델이 평범한 출력을 내고 있을 때 조용히 실패한다는 지적은, 같은 글에 따른 것. https://anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩ ↩² ↩³

4. Xia et al.「Agentless」(arXiv:2407.01489). 자율 에이전트를 쓰지 않고, 문제 지점의 특정, 수정, 패치의 검증이라는 3단계 파이프라인으로 낮은 비용에 높은 성과를 낼 수 있음을 보여 준 연구. https://arxiv.org/abs/2407.01489 ↩

5. Yang et al.「SWE-agent」(arXiv:2405.15793). 프린스턴 대학의 연구팀에 의한 것으로, AI 모델은 새로운 종류의 컴퓨터 이용자이며 전용으로 설계된 인터페이스를 필요로 한다는 것, 에이전트용으로 최적화한 도구를 줌으로써 모델 자체를 바꾸지 않고 성능이 향상된다는 것을 보여 주었다. https://arxiv.org/abs/2405.15793 ↩