AI 코딩 에이전트에게 무엇을 맡기고, 어디서 멈출 것인가

AI 코딩 에이전트에게 무엇을 맡기고, 어디서 멈출 것인가

코드 인플레이션, 서브에이전트 생존율 12%, 수동 루프 설계—세 현장이 공통으로 가리키는 건 에이전트의 성능이 아니라 팀이 설계한 제어권의 경계다.

AI 코딩 에이전트 코드 인플레이션 서브에이전트 agentic loop 인간 승인 게이트 Context Architect Claude Code 팀 역할 재정의
광고

AI가 30초 만에 500줄짜리 React 컴포넌트를 뱉어내는 시대에, 팀의 진짜 병목은 '코드를 어떻게 쓰느냐'가 아니라 '이번 주 팀이 생성한 1만 줄을 어떻게 감당하느냐'로 이동했다. 세 개의 현장 보고서가 이 문제를 서로 다른 각도에서 조명하고 있는데, 읽고 나면 결국 같은 질문으로 수렴된다. 에이전트에게 무엇을 위임하고, 어디서 사람이 개입해야 하는가.

코드 인플레이션: 생산성의 역설

dev.to의 Idan Dev는 이 현상을 'AI Code Inflation'이라고 명명한다. 생성 마찰이 제로에 수렴하면서 코드베이스는 지속 불가능한 속도로 비대해지고 있다. 표면상 깔끔해 보이는 AI 생성 PR에는 구조적 결함이 숨어 있고, 시니어 개발자는 그걸 걸러내는 데 업무 시간의 70%를 소진한다. 아이러니하게도, AI가 빠를수록 리뷰어의 부담이 늘어나는 구조다.

그가 제안하는 탈출구는 'Context Architect'로의 역할 전환이다. 핵심은 세 가지다. TypeScript strict 타이핑과 OpenAPI 스키마로 AI가 넘을 수 없는 아키텍처 경계를 만들고, 새 파일을 추가하기 전에 기존 코드베이스를 먼저 리팩터링할 수 있는지 물어보고, 테스트를 먼저 작성한 뒤 AI가 그 테스트를 통과하는 코드를 쓰게 한다. '얼마나 많이 생성할 수 있나'가 아니라 '얼마나 많이 생성되지 않게 막을 수 있나'가 기준이 된다.

서브에이전트 100개 중 12개만 살아남은 이유

Claude Code 서브에이전트 100개를 실제 업무에 돌려본 Suraj Khaitan의 실험은 더 직접적인 메시지를 던진다. 생존율 12%. 나머지 88개는 삭제됐다. 이유는 단순하다. 대부분의 사람이 서브에이전트를 '전문가 페르소나'로 오해했기 때문이다.

서브에이전트의 실제 가치는 컨텍스트 격리다. 테스트 스위트를 돌리거나 대형 모노레포를 grep하면 수천 토큰의 노이즈가 메인 컨텍스트 창에 쏟아진다. 서브에이전트는 그 노이즈를 자신의 독립된 컨텍스트 창 안에 가둬두고 두 줄짜리 요약만 돌려보낸다. '방화벽'이지, 전문가가 아니다.

이 관점에서 실패 패턴도 명확해진다. description 필드가 겹치는 에이전트 열다섯 개를 설치하면 라우터가 엉뚱한 놈을 고르거나 아무것도 고르지 않는다. 병렬 리서치 에이전트 여섯 개가 각자 상세 보고서를 메인 스레드에 토해내면 보호하려던 컨텍스트가 오히려 더 빨리 잠식된다. 결론은 간단하다. 명확한 description을 가진 소수의 에이전트가 모호한 description을 가진 다수보다 낫다. 그리고 model 필드로 비용도 제어할 수 있다. 단순 작업은 Haiku, 심층 추론은 Opus로 라우팅하는 것만으로 비용 구조가 달라진다.

수동 루프를 직접 짜면 보이는 것들

Pavel Espitia는 SDK의 도구 실행기를 쓰는 대신 agentic loop를 손으로 구현했다. 이유는 명쾌하다. 파일 쓰기 같은 파괴적 액션 전에 사람의 승인을 끼워 넣고 싶었기 때문이다.

루프의 구조 자체는 단순하다. 모델이 응답한다. end_turn이면 끝. tool_use면 도구를 실행하고 결과를 다시 모델에 넘긴다. 반복. 도구 실행기는 이 루프를 숨길 뿐이다. 직접 쥐면 '모델이 도구를 호출하기로 결정한 시점'과 '도구가 실제 실행되는 시점' 사이에 원하는 것을 무엇이든 삽입할 수 있다.

그가 설계한 승인 게이트는 단순하다. write_file 호출이 감지되면 사람에게 묻는다. 거절하면 is_error: true와 함께 "사용자가 쓰기를 거부했다. 대안을 제안하라"는 메시지가 모델에게 tool_result로 돌아간다. 모델은 그걸 읽고 다른 경로를 찾는다. 이 외에도 루프를 직접 소유하면 자연스럽게 도출되는 게이트가 있다. 모든 도구 호출 로깅, 턴 제한(무한 루프 방지), 이미 실행한 도구 재실행 방지. 에이전트가 이상한 행동을 할 때 "마법이 고장났다"가 아니라 "내가 처리 못 한 tool_use가 들어왔다"고 진단할 수 있게 된다.

세 현장이 팀 리드에게 주는 시사점

세 보고서를 겹쳐놓으면 구조가 보인다. 코드 인플레이션 문제는 에이전트가 코드를 생성하기 전에 아키텍처 경계를 설계해야 한다고 말한다. 서브에이전트 실험은 에이전트를 많이 두는 게 아니라 적게, 그리고 명확하게 두어야 한다고 말한다. 수동 루프 경험은 에이전트와 도구 실행 사이의 공간을 팀이 직접 설계해야 한다고 말한다.

공통 메시지는 하나다. 에이전트의 자율성은 기본값이 아니라 팀이 명시적으로 설계하는 것이다.

실용적으로 번역하면 이렇다. 먼저 TypeScript strict mode, OpenAPI 스키마 같은 아키텍처 제약을 먼저 설계해 AI가 넘을 수 없는 경계를 만든다. 서브에이전트는 '어떤 전문가를 둘까'가 아니라 '어떤 노이즈를 메인 컨텍스트에서 격리할 것인가'로 설계한다. 파일 쓰기, 외부 API 호출, 삭제처럼 되돌리기 어려운 액션에는 반드시 사람 승인 게이트를 만든다. 에이전트가 무엇을 실행했는지 로깅 없이 자율성을 높이지 않는다.

전망: 제어권 설계가 팀 역량이 된다

AI 코딩 도구의 성숙도가 높아질수록 아이러니하게도 설계해야 할 제어권의 범위도 함께 넓어진다. 에이전트가 더 많은 것을 할 수 있게 될수록, '어디까지 허용하고 어디서 멈출 것인가'를 결정하는 일은 더 정교해진다.

2026년 시니어 개발자의 핵심 역량은 코드를 빠르게 생성하는 능력이 아니다. 에이전트가 생성할 코드의 경계를 설계하고, 에이전트가 넘어서는 안 되는 지점에 게이트를 심고, 에이전트가 토해내는 노이즈를 격리하는 구조를 만드는 능력이다. Context Architect라는 표현이 과장처럼 들릴 수 있지만, 세 현장의 데이터를 보면 그게 정확히 지금 팀에서 벌어지고 있는 역할 전환이다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요