개발자 세 명이 같은 저장소에서 각자 다른 코딩 에이전트를 쓰는 장면을 생각해보자. 한 명은 Claude Code로 API 엔드포인트를 작성하고, 다른 한 명은 Cursor로 데이터 모델을 수정하고, 세 번째는 GitHub Copilot으로 테스트 코드를 채운다. 각 도구는 그 순간 자신이 가진 컨텍스트와 내장 판단 기준을 따라 코드를 만든다. 문제는 세 도구 사이에 공유되는 판단 기준이 없다는 것이다.
이 상황에서 PR 리뷰는 점점 피곤해진다. 어떤 에이전트가 어떤 기준으로 무엇을 결정했는지 알 수 없고, 코드 스타일이나 검증 방식이 파일마다 다르다. 속도는 빨라지는 것 같지만 리뷰어의 피로는 누적되고, 합의된 품질 기준은 도구마다 제각각으로 해석된다.
왜 에이전트별 판단이 충돌하는가
코딩 에이전트는 사용자의 요청을 받아 스스로 판단하면서 코드를 만든다. 좋은 에이전트일수록 맥락을 읽고 세부 구현을 자율적으로 결정한다. 그런데 이 자율성이 여러 도구가 혼재할 때 역효과를 낸다.
Claude Code는 시스템 프롬프트와 CLAUDE.md 파일로 동작 방식을 지정받는다. Cursor는 .cursorrules를 읽는다. GitHub Copilot은 VS Code 설정과 확장 구성에 따라 다르게 움직인다. 각 도구의 설정 파일은 서로 다른 경로에 있고, 형식도 다르다. 팀이 통일된 코딩 원칙을 갖고 있더라도, 그것을 도구별로 각각 번역해서 넣지 않으면 에이전트는 그 원칙을 모른다.
더 큰 문제는 검증 단계다. 에이전트가 코드를 생성한 뒤 어느 시점에 사람이 검토하고, 어떤 기준으로 통과 여부를 판단하는지가 도구마다 다르다. 어떤 에이전트는 테스트가 없어도 완료로 판단하고, 어떤 에이전트는 보안 취약점 검토 없이 PR을 만든다. 이 간극이 쌓이면, 에이전트를 여러 개 쓸수록 품질 기준은 오히려 낮아지는 역설이 생긴다.
중앙화된 워크플로 규칙 엔진이 해결하는 것
해결 방향은 에이전트를 하나로 통일하는 것이 아니다. 오히려 팀이 사용하는 어떤 도구를 통해서도 동일한 단계, 동일한 검증 기준, 동일한 승인 게이트를 통과하도록 규칙을 한 곳에서 관리하는 것이다.
AWS가 오픈소스로 공개한 AI-DLC(AI-Driven Development Life Cycle)는 이 접근 방식을 구현한 사례다. 핵심 아이디어는 "하나의 코어, 여러 하네스(harness)"다. 워크플로 규칙은 도구 중립적인 하나의 코어에 정의하고, Claude Code, Cursor, GitHub Copilot, Codex CLI 같은 각 도구에는 그 규칙을 실행하는 어댑터, 즉 하네스만 설치한다. 개발자는 자신이 선호하는 도구를 그대로 사용하되, 에이전트가 따르는 단계와 검증 기준은 팀 전체가 공유하는 규칙 엔진에서 온다.
이 구조에서 어떤 도구를 쓰든 에이전트는 요구사항 수집, 구현, 검토, 승인 게이트를 순서대로 거친다. 사람의 승인 없이 다음 단계로 넘어가지 않는다.
요구사항 정의에서 시작하는 이유
많은 팀이 도구 설정부터 시작한다. 도구를 설치하고, 각자 써보고, 문제가 생기면 그때 규칙을 추가한다. 이 순서는 대부분 실패한다.
워크플로 규칙 엔진 도입은 도구 설정보다 요구사항 정의가 먼저여야 한다. 팀이 코드 품질의 어떤 측면을 에이전트에게 위임할지, 어떤 결정은 반드시 사람이 내릴지, 그리고 각 단계에서 산출물이 무엇인지를 먼저 합의해야 한다.
구체적으로 정해야 할 항목은 세 가지다.
첫째, 승인 게이트 위치다. 요구사항 확정 후, 구현 완료 후, PR 생성 전, 세 지점 중 어디에서 사람이 개입하는지를 도구와 무관하게 정의해야 한다.
둘째, 검증 기준이다. 테스트 커버리지 임계값, 보안 스캔 통과 여부, 코드 스타일 규칙 중 에이전트가 스스로 확인하는 것과 사람이 최종 확인하는 것을 구분해서 기록한다.
셋째, 컨텍스트 공유 방식이다. 에이전트가 작업을 이어받을 때 이전 에이전트의 판단 근거와 중간 산출물을 어떻게 전달받는지, 그 경로가 설정 파일인지 저장소 내 문서인지 결정한다.
이 세 가지가 정해지지 않으면 어떤 도구를 설치해도 충돌은 반복된다.
단계별 구현 순서와 각 단계의 산출물
1단계: 팀 규칙 명세 작성
도구 설치 전에, 팀이 합의한 워크플로 규칙을 버전 관리되는 문서로 작성한다. 이 문서는 에이전트가 읽는 설정 파일의 원본이 된다. 어느 도구에서든 에이전트가 이 문서를 기준으로 동작해야 한다.
산출물: 워크플로 정책 문서 (승인 게이트 위치, 각 단계 담당자, 검증 기준, 컨텍스트 전달 방식 포함)
2단계: 도구별 하네스 설정
규칙 엔진 설치 후, 각 도구에 해당 하네스를 구성한다. AI-DLC 기준으로 설명하면, aidlc config --harness claude와 같이 도구별로 설정 명령을 실행하면 해당 도구가 코어 규칙을 읽어 동작한다. 팀에서 Cursor와 Copilot을 동시에 쓴다면 두 하네스를 모두 설정하되, 코어 규칙 파일은 하나다.
산출물: 각 도구에 적용된 하네스 설정 파일, 의사 결정 근거 기록
3단계: 파일럿 워크플로 검증
실제 기능 개발 태스크 하나를 골라 세 도구를 모두 투입해서 동일한 태스크를 처리하게 한다. 목표는 각 도구가 동일한 단계 순서를 따르는지, 승인 게이트에서 정말 멈추는지, 컨텍스트 전달이 끊기는 지점이 없는지 확인하는 것이다.
이 단계에서 발견되는 불일치가 실제 리스크다. 어떤 도구가 어떤 단계를 건너뛰는지, 판단 기준이 다른 부분이 어디인지를 기록해 1단계 규칙 문서를 보정한다.
산출물: 도구 간 동작 비교 기록, 규칙 문서 개정 이력
4단계: 팀 전체 배포와 운영 기준 수립
파일럿 검증을 통과한 규칙 셋을 저장소에 커밋하고 팀 전체에 배포한다. 이후부터 규칙 변경은 문서 수정과 코드 리뷰를 거쳐야 한다. 에이전트 판단 기준을 개인이 임의로 바꾸지 않도록 규칙 파일에 대한 쓰기 권한을 분리한다.
운영 단계에서 핵심은 에이전트 동작 이력의 추적 가능성이다. 어떤 에이전트가 어떤 단계에서 어떤 판단을 했는지를 나중에 확인할 수 있어야, 문제가 생겼을 때 규칙 문제인지 에이전트 문제인지 구분할 수 있다.
산출물: 배포된 규칙 셋 (버전 관리), 운영 정책 문서 (추적 기준, 변경 절차 포함)
이 구조가 전제하는 조건과 한계
이 접근 방식이 효과를 내려면 전제가 있다. 팀의 워크플로 규칙이 이미 팀 내에서 합의되어 있어야 한다. 에이전트에게 불명확한 규칙을 넣으면, 에이전트는 그 불명확성을 자율적으로 해석해서 채운다. 결국 혼란이 규칙 파일 안으로 들어온다.
또한 이 구조는 에이전트의 코드 생성 품질 자체를 보장하지 않는다. 승인 게이트와 단계 순서를 강제할 뿐, 각 단계에서 에이전트가 만드는 코드의 정확성은 별개 문제다. 규칙 엔진은 프로세스를 제어하는 도구지, 에이전트의 역량을 대체하지 않는다.
모델 선택도 결과에 영향을 미친다. AI-DLC 문서는 Claude Opus 4.8을 현재 권장 모델로 명시하고 있다. 추론 능력이 높은 모델일수록 복잡한 승인 게이트 조건을 정확히 해석하고 멈출 확률이 높다. 팀에서 사용하는 모델이 워크플로 규칙을 얼마나 잘 따르는지는, 파일럿 검증 단계에서 실제로 확인해야 알 수 있다.
제품 관리자가 확인해야 할 것
제품 관리자 입장에서 이 구조를 팀에 도입할 때 먼저 결정해야 하는 것은 도구 선택이 아니다. 어떤 단계에서 사람이 반드시 개입하는지, 그 기준은 무엇인지를 먼저 팀과 합의하는 것이다. 그것이 정해지면 도구별 설정은 기술 작업으로 위임할 수 있다.
점검 순서는 이렇게 정리할 수 있다. 현재 팀이 에이전트별로 각기 다른 규칙 파일을 관리하고 있다면 즉시 통합이 필요하다. 승인 게이트가 도구에 따라 다르게 동작한다면 파일럿 검증부터 시작해야 한다. 워크플로 규칙 자체가 아직 문서화되지 않았다면, 도구 설정보다 그것이 먼저다.
