OpenAI Codex가 하루 만에 사용자 100만 명을 추가해 800만 명을 돌파했다. 샘 알트먼은 이 성장세를 두고 'insane'이라는 단어를 썼다. 숫자가 증명하듯, 코딩 에이전트는 이미 팀 안에 들어와 있다. 문제는 '도입 여부'가 아니라 '어떻게 써야 3-5배 생산성이 나오는가'다.
McKinsey 2025년 조사에서 AI를 도입한 조직은 88%였지만 실제 bottom-line 임팩트를 본 곳은 6%에 불과했다. 82포인트 격차. 그런데 같은 맥락의 2026년 보고서는 다른 이야기를 꺼냈다. 선도 조직들은 에이전트가 밤새 요구사항을 분석하고, 코드를 생성하고, PR까지 패키징한 상태로 아침 9시를 맞이한다. '24시간 스프린트'다. 60% 더 작은 팀으로 3-5배 생산성을 달성한다는 수치가 붙는다. 이 격차를 만드는 건 도구가 아니다. 에이전트가 최대 성능을 내도록 설계된 내부 구조가 다르다.
에이전트의 작업 조건이 성능을 결정한다
.NET 생태계의 오픈소스 프로젝트 Wolverine을 만든 Jeremy D. Miller는 2026년 6월 이렇게 썼다. "코드베이스의 구조는 이제 사실상 프롬프트의 일부다." 직설적으로 읽으면, 팀이 코드를 어떻게 조직했느냐가 에이전트 출력물의 품질을 좌우한다는 뜻이다.
기존 수평 플랫폼 아키텍처에서 에이전트에게 기능 하나를 구현하라고 지시하면 어떻게 되는가? 컨트롤러, 요청 타입, 비즈니스 로직, DB 접근이 각기 다른 폴더에 흩어져 있다. 에이전트는 그 파일들을 전부 열고, 컨텍스트 윈도우에 로딩하고, 어느 부분이 실제로 필요한지 추론해야 한다. 로딩된 대부분은 노이즈다. 집 전체 배선도를 읽어야 전구 하나를 교체할 수 있는 구조다. dev.to의 기고 'I've Been Building Platforms First for 25 Years'는 이 구조가 에이전트에게 "최악의 작업 조건"이라고 단언한다.
더 심각한 건 스케일 문제다. 2026년의 한 실증 가이드는 "중간급 모델 + 잘 정리된 컨텍스트가 프런티어 모델 + 엉성한 컨텍스트를 이긴다"고 결론 냈다. 컨텍스트 윈도우가 커질수록 신호가 아니라 노이즈가 늘어난다는 의미다. FDA 규제를 받는 의료기기 소프트웨어를 개발하는 Medtronic의 수석 시스템 엔지니어도 같은 관찰을 공유했다. 경계가 불명확한 구조에서 에이전트는 "그럴듯하고, 잘 구조화되어 있지만, 잘못된" 코드를 생성한다. 그 잘못됨이 감지하기 어렵다는 점이 진짜 위험이다.
수직 슬라이스: 에이전트가 필요한 유일한 경계
Jimmy Bogard가 제안한 수직 슬라이스 아키텍처는 기술 레이어가 아니라 기능 단위로 코드를 조직한다. 'create-shipment' 폴더 하나 안에 요청, 유효성 검사, 비즈니스 로직, DB 접근, 응답이 모두 들어간다. 에이전트는 폴더 하나를 열면 끝이다. 필요한 것만 있고, 불필요한 것은 없다. 경계가 명확하다.
이 구조가 24시간 스프린트와 맞물리면 어떻게 작동하는가. 아침에 팀 리드가 로그인하면 에이전트가 밤새 완성한 슬라이스 A가 PR에 올라와 있다. 테스트가 통과한 상태다. 리드는 스펙의 섹션 번호 기준으로 10초짜리 검증을 하고, 슬라이스 B 스펙을 에이전트에 넘긴다. 오후에는 슬라이스 A를 실제 사용자 앞에 내놓는다. 에이전트는 슬라이스 B를 동시에 빌드 중이다. 저녁에는 사용자 피드백을 바탕으로 슬라이스 C 스펙을 쓰고 퇴근한다. 병렬이 가능한 건 핸드오프가 대화가 아니라 아티팩트(스펙)이기 때문이다.
문서 구조도 에이전트 기준으로 재설계해야 한다
코드 구조를 바꾼다고 끝이 아니다. 에이전트는 매 세션 시작마다 컨텍스트를 새로 로딩한다. 어제 무슨 일이 있었는지 기억하지 못한다. 인간을 위해 쓴 산문형 문서는 이 리더에게 작동하지 않는다.
dev.to의 기고 'My Project Docs Aren't For Humans Anymore'는 이 문제를 실제 버그로 경험한 사례를 공유한다. key_facts.md에 오래된 토큰 스코프 정보가 남아 있었다. 인간은 맥락으로 읽어 넘길 수 있는 문장이었지만, 에이전트는 그 줄을 사실로 받아들이고 그대로 실행했다. 6주 후 동일한 403 에러가 재발했다. 버그는 codebase에 수정되어 있었다. 에이전트가 실제로 읽는 파일에 반영되지 않았을 뿐이었다.
이 경험이 만들어낸 문서 설계 원칙은 세 가지다. 첫째, 사실과 근거는 분리된 파일에 둔다. key_facts.md는 현재 상태만. decisions.md는 append-only ADR. bugs.md는 증상-원인-해결 형태. 하나의 파일에 세 가지를 섞으면 에이전트의 검색 쿼리가 엉뚱한 정보를 끌어온다. 둘째, 모든 사실에 만료 트리거를 붙인다. 수정된 내용은 관련 사실 줄 바로 옆에 인시던트 링크를 단다. 에이전트가 다음 번에 읽을 때 원래 기록으로 한 번에 도달할 수 있게. 셋째, 프로토콜 블록이 실제 인터페이스다. '에러 발생 시 bugs.md를 먼저 확인'같은 조건부 지시는 if/else 로직이다. 해설 문장이 아니라 라우팅 규칙으로 설계해야 한다.
문서 한 줄을 추가하기 전에 저자는 이 질문을 던진다고 했다. "에이전트가 이 줄만, 컨텍스트 없이, 후속 질문 기회 없이 읽는다면, 올바르게 행동할 수 있는가?" 이건 API 계약을 쓰는 규율이지, 위키 페이지를 쓰는 규율이 아니다.
팀 리드가 설계해야 할 것
이 모든 것이 가리키는 결론은 하나다. 코딩 에이전트의 생산성은 에이전트 자체의 성능보다 팀이 설계한 작업 조건에 더 강하게 의존한다. Codex가 하루 100만 명씩 사용자를 늘린다는 건, 그 에이전트를 쓰는 팀들이 지금 같은 코드 구조, 같은 문서 구조 위에서 실험하고 있다는 뜻이기도 하다.
팀 리드가 내일 당장 시작할 수 있는 것은 두 가지다. 기존 레포에서 가장 자주 수정되는 기능 하나를 골라 수직 슬라이스로 분리해보는 것. 그리고 팀의 핵심 문서 하나를 열고 에이전트가 읽는다는 가정 하에 모든 문장을 검토하는 것. 그 두 가지 실험이 주는 피드백이 팀의 AI-First 전환 속도를 결정한다.
Anthropics의 2026년 보고서는 개발자가 AI를 전체 업무의 60%에서 활용하지만 '완전 위임'할 수 있는 작업은 0-20%에 그친다고 밝혔다. 에이전트는 실행 시간을 압축하지만 모호함과 책임은 압축하지 못한다. 구조를 설계하는 일은, 여전히 사람의 몫이다.