아침에 이슈 하나 만들어두고 다른 일 보다가 돌아오면 PR이 올라와 있다. 처음엔 감탄한다. 그리고 금방 현실로 내려앉는다. PR이 ‘결과물’이 되면, 팀에서 먼저 늘어나는 건 코드보다 리뷰 큐 쪽인 경우가 많다. 리뷰가 밀리면 품질은 두 갈래로 무너진다. 빨리 머지하면 사고가 나고, 엄격하게 보면 PR이 묶인다.
GitHub Copilot coding agent 쪽 업데이트를 보면 이 흐름을 꽤 정직하게 따라가고 있다. 작업별 모델 선택, 에이전트가 PR 열기 전에 셀프 리뷰를 한 번 더 돌리는 흐름, 코드/시크릿/의존성 스캔을 워크플로우 안쪽으로 끌어당긴 것, 레포에 “이 에이전트는 이렇게 일해라”를 적어두는 설정 파일까지. 기능 자체가 중요한 게 아니라, 제품이 노리는 운영면의 문제가 뭔지 힌트가 된다. (참고: GitHub 블로그)
이 글은 “에이전트가 얼마나 똑똑한가” 이야기보다, 도입 첫 1~2주에 팀이 안 무너지게 하는 규칙을 몇 줄로 박는 방법에 집중한다. 깔끔한 정책 문서보단, 대충이라도 팀 위키에 복붙해두고 지킬 수 있는 문장을 만들자는 쪽이다.
PR이 쌓이기 시작하면 제일 먼저 터지는 곳
PR이 자동으로 올라오기 시작하면 사람의 일이 바뀐다. 대화창에서 설득하는 일이 줄어드는 대신, PR 화면에서 “이건 머지 가능한가?”를 결정하는 시간이 늘어난다. 여기서 한 번 데인다.
- PR이 커진다. 처음엔 수정 2~3개 파일이었다가, 어느 날은 25개가 된다.
- 실패가 길어진다. 테스트가 깨지고, 에이전트가 고친다고 커밋이 쌓이고, 원인 설명은 얇다.
- 위험 구역이 섞인다. 사소한 리팩터링에 인증/결제 쪽 파일이 같이 묻어 들어오는 순간이 나온다.
이걸 다 “리뷰어가 열심히 보면 된다”로 풀려고 하면, 리뷰어가 먼저 소진된다. 그래서 규칙을 예쁘게 쓰면 안 된다. 짧게, 숫자로, 그리고 “멈춰”가 바로 먹히게. 이게 없으면, 결국 리뷰어가 먼저 퍼진다.
팀 위키에 박아두는 규칙 4줄(그리고 종료 프로토콜)
아래는 내가 실제로 붙여두는 문장에 가깝다. 말투도 일부러 거칠게 둔다. 그래야 지켜진다.
- 테스트 실패면 종료(재시도 금지, 실패 원인 3줄만 남기고 사람 호출)
- /auth·/billing touched면 Draft 고정 + 승인 2명
- 변경 파일 15개 넘으면 PR은 쪼개서 다시 올린다
- 동일 실패 3회면 중단 + 사람 호출
15개는 시작값이다. 우리 팀은 “리뷰어 30분 룰”로 파일 수/LOC 컷을 다시 맞춘다.
여기서 핵심은 ‘중단’이다. 중단을 “마음가짐”으로 두는 순간, 커밋만 늘고 누구도 책임지지 않는 PR이 된다.
중단은 구호가 아니라 프로토콜로 박아둔다.
- 테스트 1회 실패 → 여기서 멈춘다. 실패 원인/마지막 실행/다음 액션만 3줄로 남기고 사람 태그
- 동일 실패 3회 → 강제 중단, 상태만 업데이트
- Draft 고정 PR은 Ready 전환 조건을 명시(CI green + 승인 2명 + ‘검증 방법’ 채움)
이 정도만 해도 PR이 “끝없이 스스로 고치려다 망가지는” 패턴을 꽤 줄일 수 있다.
운영에 올리면 실패 모양이 바뀐다(그래서 남겨야 하는 3가지)
LangChain 글을 읽고 든 결론은 하나였다. 에이전트는 운영에 올리기 전엔 실패 모양이 일정하지 않다. 그래서 관측은 지표보다 “재현 가능한 흔적” 쪽이다. (참고: LangChain 블로그)
그래서 나는 항목을 늘리기보다 질문을 정해둔다. PR이 이상해졌을 때, 아래가 PR 본문이나 코멘트 어딘가에 남아 있으면 사람은 빨리 들어갈 수 있다.
- 마지막으로 어떤 도구/명령을 호출했나?
- 근거로 삼은 파일/문서/검색 결과는 뭐였나?
- 같은 실패를 몇 번 반복했나?
여기에 하나만 더 붙이면 ‘리뷰가 가능한 에이전트’가 된다.
- 라벨링 큐: 헤맨 PR을 주 2~3개만 뽑아 사람이 짧게 태그 달기(왜 헤맸는지, 다음엔 뭘 막을지)
- 온라인 평가: “PR 본문에 3줄 요약이 있나”, “위험 경로 touched면 Draft인가” 같은 규칙 검증을 자동으로 돌리기
완벽한 관측 체계를 만들겠다는 말이 아니다. 일단 ‘사람이 덜 화나게’ 만드는 정보만 남기는 게 목표다.
비용은 모델보다 “같은 안내문을 몇 번 먹이냐”에서 터진다
도입 초반에는 비용이 잘 안 보인다. PR이 2~3개일 땐 그냥 넘어간다. 그런데 어느 순간부터 체감이 온다. 레포 구조, 컨벤션, 과거 이슈 같은 걸 프롬프트에 계속 붙이기 시작하면, “왜 이렇게 느리지?”가 된다.
AWS 글을 보고 든 생각은 이거다. 비용은 결국 “반복”에서 터진다. 운영에서 자주 반복되는 건 ‘매번 새로 시작하는 대화’가 아니라, 사실상 같은 안내문을 계속 다시 먹이는 일이다. LMCache는 프리픽스 한 번 재사용 같은 단순한 캐싱이 아니라, 청크 단위로 KV 캐시를 재사용해 반복 컨텍스트 비용을 줄이는 쪽으로 간다. (참고: AWS ML 블로그)
팀이 할 일은 결국 하나로 좁혀진다.
- 레포 가이드/컨벤션/빌드 방법 같은 고정 컨텍스트를
AGENT_GUIDE.md같은 파일 한 장으로 모으고 - PR마다 장문 설명을 붙이지 말고, “그 파일을 먼저 읽어라”로 통일한다
이걸 해두면 모델 선택을 바꾸기 전에 체감이 먼저 내려간다.
참고자료
1) GitHub Blog — What’s new with GitHub Copilot coding agent - https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/ 2) LangChain Blog — You don’t know what your agent will do until it’s in production - https://blog.langchain.com/you-dont-know-what-your-agent-will-do-until-its-in-production/ 3) AWS ML Blog — Large model inference container – latest capabilities and performance enhancements - https://aws.amazon.com/blogs/machine-learning/large-model-inference-container-latest-capabilities-and-performance-enhancements/
댓글
댓글 쓰기