왜 모델을 먼저 고르면 나중에 다시 돌아오는가
코딩 에이전트 도입을 검토하는 팀 대부분은 비슷한 순서로 시작한다. 어떤 모델이 벤치마크에서 앞서는지 확인하고, 에이전트 툴을 몇 가지 시험해보고, 가장 인상적인 데모를 보여준 벤더와 계약한다. 그런데 수개월 뒤 실제 코드베이스에서 에이전트를 돌려보면 기대했던 생산성 증가가 나타나지 않는다.
이 문제의 원인을 모델 한계나 프롬프트 기술 부족으로 보는 경우가 많다. 그러나 공개적으로 검증 가능한 엔지니어 사례들을 보면 다른 패턴이 보인다. 성과를 낸 팀은 공통적으로 워크플로를 먼저 설계했다. 어떤 모델을 쓰느냐보다 에이전트가 생성한 코드를 언제, 누가, 어떤 방식으로 검토하느냐를 먼저 정했다.
모델을 먼저 고르면 나중에 다시 돌아오는 이유는 간단하다. 검수 체계 없이 에이전트를 운용하면 출력 속도는 빠르지만 리뷰 병목이 생기고, 리뷰 병목을 해소하려고 검수를 줄이면 코드 품질이 떨어진다. 이 사이클에서 빠져나오려면 결국 워크플로부터 다시 설계해야 한다.
1단계: 현재 리뷰 워크플로의 병목을 먼저 지도로 그린다
에이전트를 투입하기 전에 팀이 해야 할 첫 번째 작업은 현재 코드 리뷰가 어디서 느려지는지 확인하는 것이다. 구체적으로는 세 가지 질문에 답해야 한다.
- PR이 열린 뒤 첫 리뷰까지 평균 몇 시간이 걸리는가?
- 어떤 유형의 코드가 리뷰어의 시간을 가장 많이 가져가는가?
- 리뷰어가 실제로 잡아내는 문제와 잡아내지 못하는 문제는 각각 무엇인가?
이 지도를 그리지 않으면 에이전트가 어느 지점에 투입되어야 팀의 실제 병목을 줄이는지 알 수 없다. 에이전트는 코드를 빠르게 생성하지만, 생성 속도를 높이는 것이 팀의 실제 문제가 아닐 수 있다.
이 단계의 산출물: 현재 리뷰 흐름 다이어그램, 단계별 소요 시간, 리뷰어 집중 영역과 누락 패턴 목록.
2단계: 커밋 전 자동 검수 지점을 정의한다
병목 지도가 나왔다면, 에이전트를 가장 먼저 투입할 위치는 커밋 직전이다. 이 시점은 사람이 코드를 검토하기 전에 에이전트가 한 번 걸러주는 역할을 할 수 있어서, 리뷰어가 반복 패턴 오류나 스타일 불일치에 시간을 쓰지 않아도 되게 만든다.
커밋 전 자동 검수를 설계할 때 팀이 정해야 할 것은 세 가지다.
첫째, 에이전트가 검수해야 할 항목의 범위. 스타일, 타입 오류, 보안 패턴, 테스트 커버리지 중 어디까지를 자동화할지 미리 정한다. 범위를 너무 넓게 잡으면 오탐(false positive)이 많아져서 개발자가 검수 결과를 무시하기 시작한다.
둘째, 검수 결과가 블로킹(차단)인지 경고(warning)인지의 구분. 모든 지적이 커밋을 막으면 팀이 에이전트를 우회하는 방법을 찾는다. 블로킹 기준은 처음에는 좁게 잡고 운용하며 넓혀가는 쪽이 낫다.
셋째, 검수 결과의 추적 방식. 에이전트가 무엇을 잡았고 개발자가 어떻게 반응했는지를 기록해야, 나중에 검수 기준이 실제로 유효한지 평가할 수 있다.
이 단계의 산출물: 커밋 전 검수 항목 목록, 블로킹/경고 분류 기준, 결과 추적 방식 명세.
3단계: 다중 모델 리뷰 조합을 실험 단위로 설계한다
공개된 엔지니어 사례에서 반복적으로 나타나는 패턴 중 하나는 단일 모델이 아닌 두 모델을 교차 검토에 사용하는 방식이다. 한 모델이 생성한 코드를 다른 모델이 리뷰하게 하면, 단일 모델의 일관된 맹점을 다른 각도에서 잡을 수 있다는 것이 이 접근의 기대 근거다.
그러나 다중 모델 조합이 항상 단일 모델보다 낫다는 일반 결론은 아직 없다. 조합의 효과는 코드베이스의 성격, 팀이 어떤 유형의 오류를 가장 많이 놓치는가, 두 모델의 출력 형식이 워크플로와 얼마나 잘 맞는가에 따라 달라진다.
실무적으로는 다음 순서로 접근하는 편이 합리적이다.
- 단일 모델로 커밋 전 검수를 먼저 안정화한다.
- 고위험 코드 경로, 즉 인증, 결제, 데이터 마이그레이션처럼 오류 비용이 큰 영역에 한해 두 번째 모델의 교차 리뷰를 시험한다.
- 두 모델이 잡아내는 문제 유형이 실제로 다른지, 아니면 겹치는지를 일정 기간 데이터로 확인한다.
- 효과가 확인되면 범위를 넓히고, 겹치는 지적이 많으면 비용 대비 효익을 다시 계산한다.
다중 모델 조합을 처음부터 전체 코드베이스에 적용하면 비용과 레이턴시가 올라가면서 워크플로 저항이 생긴다. 실험 단위를 작게 유지하는 것이 중요하다.
이 단계의 산출물: 고위험 코드 경로 목록, 교차 리뷰 실험 범위와 평가 기준, 모델별 오류 탐지 유형 비교 로그.
4단계: 에이전트 실수가 워크플로 설계 입력이 되도록 피드백 루프를 만든다
에이전트가 틀리는 것은 시간이 지나도 줄어들지 않는 상수가 아니다. 그러나 실수의 패턴을 기록하지 않으면, 같은 유형의 오류가 반복될 때 개발자는 에이전트 자체를 신뢰하지 않게 된다.
효과적인 팀은 에이전트 실수를 두 가지로 분류한다. 첫 번째는 검수 설정으로 막을 수 있었는데 놓친 것, 두 번째는 현재 검수 범위 밖의 것. 전자는 검수 기준을 조정하는 입력이 되고, 후자는 다음 분기 워크플로 설계의 범위 결정에 반영된다.
이 분류가 없으면 실수 대응이 "프롬프트를 바꿔보자"나 "모델을 교체하자"로만 이어진다. 모델 교체로 해결되는 문제와 워크플로 설계로 해결되는 문제는 다르다.
이 단계의 산출물: 에이전트 오류 유형 분류 로그, 검수 기준 개정 이력, 분기별 워크플로 검토 일정.
벤더 선정 검증 질문: 워크플로 설계가 끝난 뒤에야 물어볼 수 있는 것들
워크플로 설계가 끝났다면 벤더를 평가할 때 물어야 할 질문도 달라진다.
- 커밋 전 검수 단계를 CI/CD 파이프라인에 어떻게 통합하는가? 어떤 훅 방식을 지원하는가?
- 다중 모델을 사용할 때 동일 플랫폼 내에서 교차 리뷰를 설정할 수 있는가, 아니면 별도 오케스트레이션이 필요한가?
- 에이전트 검수 결과와 개발자 반응을 추적하는 로그를 팀이 직접 내보낼 수 있는가?
- 고위험 코드 경로에 대해 검수 강도를 달리 설정하는 것이 가능한가?
이 질문들은 모델 성능 벤치마크보다 팀의 실제 워크플로에 벤더가 맞는지를 더 직접적으로 확인해준다. 벤치마크가 높은 모델이 팀의 CI 환경에 통합되지 않으면 아무 의미가 없다.
