코딩 에이전트 업무 배치와 설정 이식성 설계

도구가 아니라 작업 속성으로 에이전트를 배치한다

2026년의 코딩 에이전트 시장에서는 Claude Code, Codex CLI, GitHub Copilot CLI, Antigravity CLI가 서로 다른 영역에서 강점을 보인다. 추론 깊이, 샌드박스 안전성, GitHub 네이티브 통합, 대용량 컨텍스트 윈도우가 동시에 경쟁 기준이 되면서 하나의 도구로 모든 개발 업무를 통일하는 방식은 구조적인 손해를 만들 수 있다.

업무의 성격에 맞춰 에이전트를 배치하고, 도구가 바뀌어도 팀 규칙과 산출물 기준을 옮길 수 있도록 설계해야 한다. 이 구조는 개발 방법론, 형상 관리, 비용 관리의 관점에서 함께 다뤄야 한다.

작업 성격과 도구의 강점을 연결하는 기준

각 도구는 다음과 같은 업무에 맞는다.

도구	핵심 강점	적합 업무 유형	규칙 파일
Claude Code	추론 깊이, 병렬 서브에이전트	복잡한 다중 파일 리팩터링, TDD, 아키텍처 설계	CLAUDE.md
Codex CLI	샌드박스 격리·승인 기반 안전성	프로덕션 인접 자동화, 신뢰 경계가 낮은 반복 작업	AGENTS.md
GitHub Copilot CLI	GitHub 네이티브 통합(이슈·PR·리뷰)	이슈 트리아지, PR 리뷰, 저장소 운영성 작업	.github/copilot-instructions.md
Antigravity CLI	초대형 컨텍스트 윈도우, 서브에이전트 오케스트레이션	대규모 코드베이스 일괄 분석, 레거시 마이그레이션	GEMINI.md(과도기)
OpenCode	프로바이더 종속 없음, 로컬 모델 포함 75+	비용 민감 실험, 벤더 종속 회피가 우선인 파일럿	AGENTS.md 호환

Claude Code는 멀티스텝 에이전트 루프와 전담 컨텍스트를 갖는 병렬 서브에이전트, 의존성을 추적하는 공유 태스크 리스트를 지원한다. 다중 파일 리팩터링이나 TDD 성격의 작업에 맞는 이유다.

Codex CLI의 핵심은 안전성이다. macOS에서는 Seatbelt를 사용하고, Windows에서는 제한 토큰·합성 SID·ACL·방화벽 규칙을 조합한 4계층 격리 아키텍처와 명령 단위 승인 레이어를 제공한다.

GitHub Copilot CLI는 GitHub 네이티브 /mcp 통합을 통해 이슈·라벨·활동 이력을 그대로 활용한다. gh copilot이 별도 확장 없이 GitHub CLI에 내장되어 있어 이슈, PR, 코드리뷰 중심의 흐름과 잘 맞는다.

Antigravity CLI(구 Gemini CLI 후속, 실행 명령어 agy)는 최대 1M 토큰 컨텍스트 윈도우를 제공한다. 메인 컨텍스트를 오염시키지 않으면서 서브에이전트를 즉석 생성해 병렬 작업을 처리하는 구조도 대규모 분석과 레거시 마이그레이션에 유리하다.

티켓이 지나갈 경로를 먼저 정한다

배치의 출발점은 도구 선택이 아니라 판정 규칙이다. 코드베이스 규모, 신뢰 경계, GitHub 연동 밀도, 리스크 허용도를 기준으로 티켓을 분류한 다음 에이전트를 연결한다.

⤢✕

판정은 다음 질문으로 좁힐 수 있다.

이 작업이 요구하는 컨텍스트가 단일 세션 한도를 넘는가?
실행 결과가 프로덕션에 직접 영향을 주는가?
GitHub 이슈·PR 메타데이터 의존도가 높은가?

이 규칙은 정적인 비교표에 머물면 안 된다. 형상관리 워크플로의 앞단에서 티켓에 코드베이스 규모, 리스크 등급, GitHub 연동 여부 같은 태그를 부여하고, 사용 도구 메타데이터를 커밋 메시지나 PR 템플릿에 남겨야 한다. 그래야 배치 결과를 나중에 추적하고 조정할 수 있다.

공통 규칙은 한곳에 두고 차이만 분리한다

도구별 규칙 파일이 제각각 성장하면 같은 팀 컨벤션도 도구마다 다르게 해석될 수 있다. 이를 막기 위한 기준점은 AGENTS.md다.

AGENTS.md는 OpenAI가 2025년 8월 공개한 뒤 리눅스 재단 산하 Agentic AI Foundation(AAIF)으로 이관되었고, 2026년 5월 기준 6만 개 이상의 오픈소스 저장소가 채택했다. Codex CLI는 이를 직접 읽는다. Claude Code는 import 지시문으로 CLAUDE.md에서 AGENTS.md를 참조할 수 있으며, GitHub Copilot CLI는 .github/copilot-instructions.md, Gemini 계열은 GEMINI.md를 사용한다.

설정 이식 경로는 다음처럼 구성할 수 있다.

원본: AGENTS.md에 코딩 컨벤션, 금지 패턴, 테스트 정책 등 프로젝트 전역 규칙을 둔다.
위임: CLAUDE.md와 copilot-instructions.md에는 본문을 중복하지 않고 @AGENTS.md 형태의 import 또는 짧은 참조 문구만 둔다.
델타 최소화: 권한 모드, 샌드박스 정책, MCP 서버 목록처럼 도구에 특화된 설정만 로컬 파일에 남긴다.
만료 규칙: 특정 작업에만 필요한 task brief는 별도 파일로 분리하고 만료 조건을 명시한다.

공통 규칙을 AGENTS.md에 집중하면 팀의 일관성은 높아진다. 반면 Codex CLI의 승인 정책 세부 조정이나 Antigravity CLI의 서브에이전트 분할 전략처럼 도구에 맞춘 최적화는 로컬 델타 파일에서 관리해야 한다.

도구별 규칙을 완전히 분리하면 각 도구의 특성을 최대한 살릴 수 있지만, 규칙이 바뀔 때마다 N개 파일을 동기화해야 한다. 이 부담은 팀 규모에 비례해 커진다. 실무적으로는 공통 규칙 80%, 도구별 델타 20%를 목표로 두는 방식이 유지보수 비용과 최적화 여지 사이의 균형점이 된다.

산출물과 비용을 같은 운영 체계에 넣는다

도구가 달라지면 커밋 메시지, PR 설명, 테스트 리포트의 형식도 흩어지기 쉽다. 이런 산출물 규격은 각 에이전트에 맡기기보다 저장소 템플릿에서 강제해야 한다.

원가 관리는 별도의 설계 대상이다. 도구마다 과금 단위가 다르기 때문이다. Claude Code는 구독형(Pro 월 20달러, Max 월 100200달러)과 API 종량제(Sonnet 5 입력 백만 토큰당 2달러·출력 10달러, Opus 5 입력 5달러·출력 25달러)를 병행한다. Codex CLI는 별도 구독이 없고 ChatGPT 플랜(Free, Go 월 8달러, Plus 월 20달러, Pro 월 100200달러)에 번들된다.

GitHub Copilot CLI는 2026년 6월 1일부터 "GitHub AI Credits" 종량 체계로 전환되어 코드 완성은 무료·무제한이지만, 에이전트와 프리미엄 모델 사용은 좌석당 월간 크레딧 한도 안에서 소진된다.

원가 귀속표는 구독 좌석, 토큰, 크레딧 같은 과금 단위를 업무 유형별 예상 소비량과 연결해 부서·프로젝트 단위로 집계해야 한다. 이후 배치를 바꿀 때 이 데이터가 판단 근거가 된다.

업무 유형 태그와 도구별 과금 로그를 연결한 대시보드도 필요하다. 구독 좌석 비용은 인원수 기준으로, API·크레딧 종량 비용은 실사용량 기준으로 집계해 업무 유형당 단위 원가를 산출한다. 이 지표를 분기별 배치 재검토의 입력값으로 사용하면, 원가에 비해 산출물 품질이 떨어지는 업무 유형을 찾아 판정 규칙을 조정할 수 있다.

도구 전환은 이주 리허설로 검증한다

배치를 바꾸거나 새 도구를 편입할 때는 전환 검증을 체크리스트로 강제해야 한다.

공통 규칙 파일(AGENTS.md)이 새 도구에서 인식·파싱되는지 확인한다.
기존 산출물 규격(커밋 템플릿, PR 템플릿)이 새 도구의 기본 출력과 충돌하지 않는지 검증한다.
샌드박스·권한 모델이 바뀌는 경우 보안 승인 경로를 재구성한다.
원가 귀속 태그(프로젝트, 업무 유형)가 새 도구의 로그·리포트 체계에서도 추출 가능한지 확인한다.
이주 후 2주간 병행 운영 기간을 두고 산출물 품질을 비교한다.

도입 전에는 현재 조직의 업무 구성을 먼저 파악해야 한다. 이슈 트래커와 PR 이력에서 3개월치 표본을 추출해 다중 파일 리팩터링, 프로덕션 인접 자동화, GitHub 운영성 작업, 대규모 코드베이스 분석으로 태깅한다. 각 범주의 비중은 도구별 라이선스 구매량과 시범 배치 규모의 근거가 된다.

시범 배치는 한 팀 또는 한 저장소에서 4~6주간 판정 규칙을 적용하는 방식으로 진행한다. 이 기간에는 산출물 품질, 소요 시간, 이탈률(원래 도구로 되돌아가는 비율)을 측정한다.

AGENTS.md 표준화도 시범 배치와 함께 진행한다. 기존 CLAUDE.md에 집중된 규칙을 프로젝트 전역 규칙과 도구별 델타로 분리하고, 원본 작성부터 위임 파일 생성, 도구별 로컬 설정 분리까지의 절차를 위키나 형상관리 문서에 남긴다. 이 문서는 새 도구가 등장할 때마다 갱신되며, 개정 이력 역시 형상관리 대상이다.

실제 운영 저장소 대신 미러 저장소에서 이주 체크리스트를 모두 실행하는 리허설도 필요하다. 실패 항목이 있으면 편입을 보류한다. 배치 판정 규칙의 소유자, 공통 규칙 파일의 리뷰어, 원가 초과 시 에스컬레이션 경로를 명시적으로 정하는 일은 형상관리 체계의 변경관리위원회(CCB) 역할과 사실상 같다.

병행 배치에서 생기는 선택과 비용

비교 축	업무별 병행 배치	단일 도구 통일
작업 적합도	업무 속성에 맞춰 최적 도구 사용, 강점 축 전부 활용	통일 도구가 약한 업무에서 지속적 손해
관리 복잡도	배치 판정 규칙·다중 규칙 파일 관리 필요, 초기 구축 비용 높음	단순, 그러나 확장 시 예외 처리 누적
원가 구조	도구별 과금 체계가 달라 귀속 설계 필요	단일 과금 체계로 예측 용이
전환 유연성	신규 도구 등장 시 판정 규칙에 추가만 하면 됨	전환 시 전사 마이그레이션 필요

업무별 병행은 판정 규칙 설계와 규칙 파일 표준화라는 초기 비용을 요구한다. 대신 장기적으로 업무 적합도와 전환 유연성에서 우위를 갖는다. 단일 도구 통일은 관리가 단순하다는 이점이 있지만, 약한 업무 유형이 조직에 쌓일수록 손해가 커진다.

설정 이식성을 강하게 요구하면 신규 도구로의 전환 속도와 벤더 종속 회피 측면에서 유리하다. 그 대신 GitHub Copilot CLI의 /mcp 네이티브 통합이나 Claude Code의 병렬 서브에이전트 태스크 의존성 추적처럼 고유 기능을 규칙 파일 수준에서 완전히 활용하기는 어렵다.

반대로 도구별 최적화를 우선하면 기능을 깊이 활용할 수 있지만, 교체나 신규 편입 때 다시 설계해야 한다. OpenCode처럼 프로바이더 종속을 원천 차단하는 접근은 이식성의 극단에 가깝고, 특정 도구의 독점 기능에 깊이 의존하는 설정은 최적화의 극단에 가깝다. 배치 아키텍처는 이 사이에서 업무 유형마다 다른 지점을 선택하는 설계다.

개발 방법론 관점에서 업무 유형 분류와 판정 규칙은 프로세스 표준화에 해당한다. 형상 관리에서는 AGENTS.md와 도구별 델타가 베이스라인과 변경분의 구조를 이룬다. 도구별 원가 귀속표는 활동기준원가(ABC) 방식의 응용으로 볼 수 있다.

2026년의 방향은 도구 단일화가 아니라 판정 규칙, 공통 규칙 파일, 원가 귀속 대시보드를 함께 갖춘 조직이 도구 시장의 분화를 경쟁력으로 바꾸는 쪽에 가깝다.