“PR이 먼저 올라온다”는 팀에서 벌어지는 일: 코딩 에이전트를 운영으로 바꾸는 최소 설계

아침에 이슈 하나 올려두고 회의 갔다 왔더니, 내가 한 건 “리뷰 시작” 버튼 누르는 일이었다. PR은 이미 와 있었고, 커밋도, 테스트 로그도, 실패 흔적도 다 남아 있었다. 누가 했냐고? ‘사람’이 아니라 에이전트였다.

처음 며칠은 다들 웃는다. “이제 잡무 좀 사라지겠네.”

그런데 도입 초반이 진짜로 좋은 시기는 거기까지다. PR이 꾸준히 들어오기 시작하면, 팀이 부딪히는 건 모델 성능이 아니라 리뷰 큐·로그·비용·권한이다. ‘코드를 잘 뽑는가’보다 ‘PR을 운영할 수 있는가’가 더 빨리 문제로 올라온다.

내가 이 글에서 우기는 건 딱 두 가지다. Copilot coding agent는 ‘채팅 도우미’라기보다 PR을 생산하는 워커로 움직이고(업데이트로 자체 리뷰/보안 스캔도 앞당겨졌다), 에이전트는 운영에 올리기 전엔 어떤 모양으로 실패할지 알기 어렵다. 그래서 PR이 들어오기 시작한 팀은, 생성보다 운영에서 먼저 삐끗한다. (참고: GitHub 문서/블로그, LangChain 글)

PR이 들어오기 시작한 주에 벌어지는 일

Copilot coding agent는 대화창에서 끝나는 도구라기보다, 백그라운드에서 작업을 마치고 PR로 던지는 쪽에 가깝다. 결국 사람은 채팅에서 말로 싸우기보다, PR 화면에서 커밋/체크/코멘트로 방향을 꺾게 된다. (참고: GitHub 문서)

여기서부터 리뷰어의 하루가 바뀐다. PR이 하나둘 쌓이는 게 아니라, ‘작업 단위’가 PR로 고정된 채로 유입된다.

내가 본 패턴은 좀 뻔하다. 에이전트 PR은 시작은 작게 들어온다. “오, 괜찮네.” 하고 열어보면, 중간부터 욕심이 붙는다. “여기 리팩터링도 할까요?” 같은 한 문장이 커밋을 부풀리고, 파일이 20개가 넘어가며, 리뷰 시간이 훅 늘어난다.

나는 이런 PR이 오면 일단 두 가지만 본다. (1) 변경 파일 수, (2) 위험 경로를 건드렸는지. 그 다음에야 코드로 들어간다. 안 그러면 금방 피곤해진다.

그렇게 몇 번 지나면 팀이 묘하게 갈린다. 빨리 머지하자는 쪽과, 더 엄격하게 보자는 쪽. 둘 다 오래 못 간다. 결국 싸움은 하나다. “PR 크기부터 줄이자”를 팀이 받아들이느냐.

내가 강하게 남기는 것

규칙을 문장으로 쓰면 새나간다. 그래서 그냥 네 줄로 박아둔다.

  • 테스트 실패면 종료(재시도 금지, 실패 원인 3줄만 남기고 사람 호출)
  • /auth·/billing touched면 Draft 고정 + 승인 2명
  • 변경 파일 15개 넘으면 PR 쪼개서 다시
  • 동일 실패 3회면 중단 + 사람 호출

이 네 줄은 멋있어 보이려고 만든 게 아니라, 리뷰어 체력을 지키려고 만든 문장이다.

‘종료’는 구호로 두면 항상 실패한다. 그래서 “테스트 실패 1회면 멈추고 요약”, “동일 실패 3회면 강제 중단”처럼 아예 구현으로 박아둔다.

  • 동일 실패 3회 → 에이전트 중단, PR 코멘트에 실패 원인/마지막 실행 명령/다음 액션 제안 남김, @oncall 태그
  • 리뷰어가 /stop 코멘트 → 에이전트는 커밋 금지, 상태 요약만 업데이트
  • Draft 고정 PR에서 Ready 전환 조건 → CI green + 승인2명 + ‘검증 방법’ 채움

여기까지 해두면, 적어도 “커밋만 쌓이고 아무도 책임지지 않는 PR”이 덜 나온다.

관측 얘기를 거창하게 하고 싶진 않다. 대신, PR이 이상해졌을 때 나는 항상 이 질문 세 개부터 본다.

  • 마지막으로 어떤 도구를 호출했나?
  • 어디를 근거로 삼았나(문서/파일/검색)?
  • 같은 실패를 몇 번 반복했나?

(참고: LangChain 글)

돈 얘기는 생각보다 빨리 온다

비용은 대개 PR 수가 늘고 나서가 아니라, “컨텍스트가 두꺼워진 다음”부터 눈에 들어온다. 레포 구조, 컨벤션, 과거 이슈까지 넣기 시작하면 바로 느껴진다. 어느 순간부터는 PR 하나가 아니라, PR 10개가 하루에 돌아가면서 ‘같은 설명’을 계속 다시 먹이는 느낌이 든다.

여기서 나는 AWS 글의 LMCache 얘기만 남겨두고 싶다. 프롬프트가 길어질수록(토큰이 늘수록) 비용이 함께 올라가는 건 직관인데, 운영에서 더 아픈 건 “반복”이다. 에이전트는 매번 새로 시작하는 것처럼 보이지만, 실제로는 비슷한 컨텍스트(레포 가이드, 컨벤션, 빌드 방법)를 계속 다시 읽는다. LMCache는 이 반복을 ‘프리픽스 한 번’이 아니라 청크 단위 KV 캐시 재사용으로 줄여준다. 그래서 팀 입장에선 ‘모델 선택’보다 먼저, “고정 컨텍스트를 분리해서 재사용 가능한 형태로 만들었나?”가 비용을 가르는 쪽으로 간다. (참고: AWS ML 블로그)

규칙: 고정 컨텍스트는 1개 파일로 두고 PR마다 붙이지 않는다 - 빌드 방법/코딩 규칙/레포 온보딩은 AGENT_GUIDE.md 같은 단일 파일로 유지하고, 에이전트에 “항상 이 파일을 먼저 읽어라”로 지시한다. - PR마다 동일한 긴 설명을 붙이는 건 금지한다.

Figma 연동, 문서/규제 워크플로우, semantic layer 같은 이야기는 분명 중요하지만, 여기까지 쓰기 시작하면 글이 링크 정리처럼 된다. 그건 다음 글에서 제대로 다뤄보겠다.

튜닝 메모(짧게). - 15개/3회/승인 2명은 정답이 아니라 시작값이다. - 나는 “리뷰어 1명이 30분 안에 끝낼 수 있나?”(30분 룰)로 시작해서 숫자를 다시 맞춘다. - 모노레포면 파일 수보다 ‘위험 경로 가중치’가 더 먼저 작동한다. - 테스트가 느리면 ‘3회’만으로는 애매해서, 동일 실패 + 30분 경과 같은 시간 조건을 얹는다. - 이 튜닝은 팀마다 갈리니 다음 글에서 더 자세히 풀겠다.

부록: PR 본문에 붙여두는 메모

  • 목적:
  • 변경 요약(3줄만):
  • 마지막 실행 명령/도구:
  • 참고한 근거(파일/문서/링크):
  • 반복된 실패/횟수:
  • 검증 방법:

마지막으로 내가 실제로 남기는 메모는 이 정도다. - PR은 결국 리뷰어가 먹는다. 그러니 PR 크기부터 줄인다. - 실패는 난다. 대신 3번이면 멈추게 만든다. - 위험 경로는 감이 아니라 규칙으로 박아둔다.

참고자료

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) GitHub Docs — About Copilot coding agent - https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent 3) GitHub Docs — Changing the AI model for Copilot coding agent - https://docs.github.com/en/copilot/how-tos/use-copilot-agents/coding-agent/changing-the-ai-model 4) 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/ 5) 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/ 6) OpenAI — Codex ↔ Figma partnership via MCP - https://openai.com/index/figma-partnership/

댓글

댓글 쓰기