통념이 먼저 흔들렸다
코딩 에이전트 워크플로우를 설계할 때 팀 리드가 가장 먼저 받는 질문이 있다. "에이전트한테 얼마나 맡길 거야?" 그리고 대부분의 팀은 직감으로 답을 고른다. 중요한 작업엔 사람이 중간에 끼고, 단순한 작업은 자율로 돌린다. 합리적으로 들린다. 문제는 이 직감의 근거가 측정이 아니라 가정이라는 점이다.
ModelRift가 공개한 OpenSCAD Pantheon 벤치마크는 그 가정에 정면으로 충돌한다. 여섯 가지 에이전트 코딩 도구에 동일한 CAD 작업을 던지고, 자율 모드(Autonomous)와 인간 개입 모드(HITL, Human-In-The-Loop)의 결과를 나란히 놓았다. 결과는 예상과 달랐다. 자율 모드의 최고 성적자인 Antigravity 2.0은 품질 점수 4.5/5를 기록했고, HITL 최고 성적자인 ModelRift는 3.8/5에 그쳤다. 더 놀라운 건 시간이다. HITL 쪽이 오히려 10분으로 더 빨랐고, 자율 모드는 12분이 걸렸다. '사람이 개입하면 품질이 올라가고 속도가 느려진다'는 두 가지 통념이 동시에 흔들렸다.
숫자를 곧이곧대로 읽으면 안 되는 이유
여기서 냉정하게 짚고 넘어가야 할 게 있다. 이 벤치마크는 단일 리뷰어가 채점한 단 한 번의 실행이다. 통계적으로 유의미한 결론을 내리기엔 샘플이 너무 작다. 더 결정적인 문제는 자율 모드와 HITL 모드가 서로 다른 모델을 썼다는 점이다. Antigravity 2.0은 Gemini 3.5 Flash High를, ModelRift는 Gemini Flash 3.0을 사용했다. 순수한 제어 방식 비교라기보다는 '그 도구를 실제로 팀이 사용했을 때의 결과물'을 비교한 것에 가깝다.
그럼에도 이 결과가 중요한 이유는, 에이전트 자율성을 결정할 때 측정 기반 판단이 직감 기반 판단보다 훨씬 낫다는 것을 다시 한번 확인시켜주기 때문이다. HITL이 항상 품질을 높인다는 가정, 자율이 항상 빠르다는 가정, 둘 다 맥락 없이는 성립하지 않는다. 명확한 시각적 목표가 있는 태스크에서는 잘 배치된 인간 개입 몇 번이 불필요한 반복 루프를 줄여 오히려 전체 시간을 단축할 수 있다. 반면 에이전트의 자율 루프가 충분히 정교하면, 사람의 중간 개입 없이도 더 높은 품질에 수렴할 수 있다.
자율성 수위를 결정하는 실질 변수
그렇다면 팀 리드는 무엇을 기준으로 에이전트의 자율성 수위를 결정해야 할까. dev.to의 AI 코딩 가드레일 관련 글이 제시하는 프레임이 여기서 유용하다. 핵심은 '바이브 코딩'과 '프로페셔널 AI 코딩'을 구분하는 것이다. 도구는 같다. 달라지는 건 자세(posture)다.
바이브 코딩은 에이전트가 빠르게 달리고 개발자는 감으로 방향을 잡는다. 탐색, 프로토타입, 아이디어 검증 단계에서 강력하다. 하지만 그 결과물이 프로덕션으로 슬며시 올라가는 순간 문제가 시작된다. 기능이 동작한다고 해서 안전한 게 아니다. 에이전트가 생성한 코드는 기능 테스트를 통과하면서도 보안 취약점을 숨기고 있을 수 있고, 아키텍처 문제를 깔끔한 diff 뒤에 가릴 수 있다. 코드를 설명할 수 없다면 배포해서는 안 된다는 원칙이 AI 시대에 더욱 날카로워지는 이유다.
프로페셔널 AI 코딩 모드에서는 에이전트 속도를 유지하되 가드레일을 더한다. 명확한 요구사항, 작은 작업 단위, 테스트, 코드 리뷰, 보안 체크가 그것이다. 특히 에이전트에게 파일을 수정하기 전에 먼저 구현 계획을 제안하게 하는 습관은 단순해 보이지만 효과가 크다. 계획을 보면 에이전트가 코드베이스를 실제로 이해하고 있는지가 바로 드러나기 때문이다.
컨텍스트가 에이전트 품질을 결정한다
자율성 수위 결정만큼 중요한 게 에이전트에게 무엇을 넣어주는가다. SKILL.mk 프로젝트는 이 문제를 흥미로운 각도에서 공략한다. Claude Code나 Copilot 같은 에이전트 코딩 도구에 스킬 문서를 제공할 때, 기존 Markdown 형식은 에이전트가 필요 없는 내용까지 모두 로드한다. 요리책 전체를 읽고 나서 달걀 삶는 법을 찾는 것과 같다.
SKILL.mk는 이 구조를 Makefile 형식으로 바꾼다. 각 스킬을 타깃으로 분리하고 의존성을 명시해, 에이전트가 현재 태스크에 필요한 부분만 로드하게 만든다. Brave Search 스킬 예시에서 온디맨드 로딩은 토큰 사용량을 85% 줄였다. 아직 프로덕션 레디한 솔루션은 아니다. 호환 가능한 로더 툴링이 필요하고 현재는 개념 증명 단계다. 하지만 컨텍스트 윈도우 낭비 문제는 에이전트를 여러 개 굴리는 팀일수록 실제 비용과 직결되기 때문에, 지금 구조 설계 단계에서부터 이 관점을 가져가는 게 맞다.
팀 리드가 지금 내려야 할 실용적 판단
세 가지 신호를 정리하면 이렇다.
첫째, 태스크의 목표 명확성이 자율성 수위를 결정한다. Pantheon 벤치마크에서 자율 에이전트가 더 높은 품질을 냈던 이유 중 하나는 참조 이미지 두 장이라는 명확한 시각적 목표가 있었기 때문이다. 목표가 흐릿하면 에이전트의 반복 루프는 방향 없이 돈다. 태스크 정의가 자율성 결정보다 먼저다.
둘째, 리스크 프로파일이 개입 방식을 결정한다. DB 스키마 변경, 인증 흐름, 결제 연동처럼 실수가 전파 범위가 넓은 작업은 자율 루프가 초반에 잘못된 방향으로 달리면 나중에 되돌리는 비용이 크다. 이런 태스크에는 HITL의 체크포인트가 유효하다. 단순 보일러플레이트나 테스트 생성처럼 롤백 비용이 낮은 작업은 자율로 돌려도 된다.
셋째, 컨텍스트 품질이 에이전트 출력 품질을 결정한다. "이 앱 만들어줘"와 "기존 인증 모듈에 패스워드 리셋 기능을 추가하되, 현재 이메일 서비스 패턴을 따르고, 만료 토큰과 재사용 토큰 테스트를 포함해라"는 완전히 다른 결과를 낳는다. 에이전트의 자율성을 높일수록 컨텍스트 엔지니어링의 정밀도도 같이 올라가야 한다.
전망: '에이전트를 믿는 팀'이 아니라 '에이전트를 설계하는 팀'
OpenSCAD 벤치마크가 시사하는 더 큰 그림은 이거다. 앞으로 에이전트 도구 간 경쟁은 '어느 모델이 더 스마트한가'보다 '어떤 루프 설계가 더 나은 결과를 내는가'로 이동할 것이다. Antigravity 2.0과 ModelRift 모두 Gemini Flash 계열을 썼지만 루프 설계가 달랐고 결과도 달랐다.
팀 리빌딩 관점에서 이 변화가 뜻하는 건 명확하다. 앞으로 필요한 역량은 에이전트를 잘 쓰는 개발자가 아니라 에이전트 워크플로우를 설계하고 검증하는 개발자다. 어느 태스크에 자율을 주고, 어느 지점에 체크포인트를 심고, 어떤 컨텍스트를 어떻게 구조화할지—이 판단을 측정 기반으로 내릴 수 있는 팀이 AI-First 전환에서 실질적인 우위를 갖는다. 벤치마크 하나로 결론을 내리기는 이르다. 하지만 직감이 아니라 실험으로 에이전트 자율성을 결정하는 문화를 지금 심어두는 것, 그게 팀 리드가 할 일이다.