에이전트를 붙이면 코드가 늘어나는 게 아니다. 팀이 상대해야 하는 운영 표면적이 늘어난다. PR은 더 자주 올라오고, 스레드는 더 길어지고, “한 번만 더”라는 재시도는 습관이 되고, 토큰/링크/권한은 수명이 생긴다. 이게 섞이기 시작하면, 생산성 얘기 전에 피곤함이 먼저 온다.
최근 일주일 동안 에이전트 PR을 몇 번 겪어보면, 결국 같은 데서 터진다. 한 방에 터지는 사고는 드물다. 별 것 아닌 신호가 겹칠 때 문제가 ‘사건’이 된다. (Cloudflare가 말한 toxic combinations이 딱 이거다.)
내가 팀 위키 상단에 박아두는 문장부터 꺼내보겠다. 에이전트 잘 쓰는 법 말고, 팀이 덜 망가지는 법. 멋있는 원칙 말고, 나중에 누가 봐도 “이 규칙 때문에 살았다/망했다”라고 말할 수 있는 것들.
에이전트가 늘리는 건 코드가 아니라 ‘결정해야 할 것’이다
GitHub Copilot CLI의 ‘아이디어 → 계획 → 검증 → PR’ 흐름을 보면, 도구가 지향하는 건 단순 생성이 아니다. 의도(Plan)와 변화(Diff)를 먼저 놓고, 사람이 승인한 뒤 실행하는 운영 흐름이다. 이게 좋다. 하지만 동시에 팀이 관리해야 하는 표면이 늘어난다.
계획/디프/승인 흐름은 분명 좋아 보인다. 문제는 그 다음이다. 계획이 틀렸을 때 되돌리는 루트, 늘어난 PR을 삼키는 리뷰 큐, “누가 뭘 승인했나”를 남기는 로그까지—운영할 게 같이 따라온다.
첫 단추는 단순하다.
기본값을 “실행”으로 둘지 “제안”으로 둘지부터 정해야 한다. - 제안 기본(Plan/Diff만): 속도는 느리지만 사고가 줄어든다. - 실행 기본(명령 자동 수행): 빨라 보이지만 “작은 실수의 누적”이 빨리 온다.
팀이 강한 규율이 있거나, 변경이 작고 테스트가 빠른 레포가 아니라면 ‘제안 기본’에서 시작하는 편이 덜 아프다.
“라우팅”은 사람 시간을 되찾는 가장 싼 자동화
Vercel이 커뮤니티 운영에서 에이전트를 쓰는 방식이 흥미로웠던 건, 에이전트가 ‘답변을 대신한다’가 아니라 ‘사람이 답할 곳을 만든다’에 가깝다는 점이다.
핵심은 “답변을 대신”이 아니라 “사람이 답할 자리로 라우팅”이다.
개발팀에선 이렇게 바꿔 쓴다: “/auth touched면 @security-oncall”, “/payments touched면 @billing-owner”, “docs-only면 라운드로빈” 같은 룰을 먼저 만든다. 에이전트에게 “코드를 고쳐”라고 시키기 전에, 리뷰와 triage를 라우팅하는 편이 싸고 확실하다.
여기서 팀이 갈린다. “누가 볼지”를 자동 추천으로 돌릴지, 사람이 매번 정할지. - 자동 라우팅을 쓰면, 기준이 필요하다(경로, 컴포넌트, 위험도). - 사람이 정하면, 병목이 생긴다(특히 PR이 늘어나는 순간).
도입 초반엔 자동 라우팅을 100% 믿지 말고, “추천 → 사람 확정” 형태로 시작하는 게 안전하다.
보안은 단일 이벤트가 아니라 조합으로 터진다
Cloudflare가 말한 toxic combinations은, ‘작은 신호가 겹치면 사고가 된다’는 뜻이다.
에이전트 운영에서도 비슷한 조합이 자주 나온다.
- 밤늦게 올라온 PR(리뷰어 판단력 ↓)
- 작은 변경처럼 보이는 diff(경계심 ↓)
- 하지만 위험 경로를 건드림(auth/billing)
- 재시도 로그가 쌓임(원인 불명)
- 링크/토큰 수명이 길어 누가 봤는지 모름(감사 불가)
개별로 보면 “그럴 수 있지”인데, 묶이면 사고다. 그래서 규칙은 기능별이 아니라 조합을 끊는 방향으로 박아야 한다.
금요일 밤에 터지는 조합(그리고 내가 박아둔 규칙)
아래는 내가 실제로 위키 상단에 박아둔 규칙들이다.
장면 1) PR이 쌓이기 시작하면: 누가 볼지부터 자동 추천
- 우리 팀은 PR이 48시간 멈춰 있으면(일단 이 값으로 시작했다),
needs-attention라벨을 달고 리뷰어를 한 명 더 붙인다. (커뮤니티 운영에서 “48h 재할당”이 실제로 먹힌다.) - 변경 파일이 15개를 넘으면, PR은 쪼개서 다시 올린다. (리뷰어 30분 룰: 30분 안에 끝내기 어려우면 크기부터 줄인다.)
장면 2) 커밋이 8개를 넘어가면: 여기서 멈춘다
8개는 시작값이다. PR을 열었을 때 “이건 내가 오늘 끝내겠네”라는 감이 사라지는 지점이 보통 여기쯤이었다. - 테스트 1회 실패 → 여기서 멈춘다. 실패 원인/마지막 실행/다음 액션만 3줄로 남기고 사람을 태그한다. - 동일 실패 3회 → 강제 중단. 더 이상 커밋을 쌓지 말고 상태만 업데이트한다.
PR 코멘트는 길게 쓰지 말고, 딱 이 3줄만 남겨라.
- 실패 원인(한 줄):
- 마지막 실행(한 줄):
- 다음 액션(한 줄):
장면 3) 링크가 새기 시작하면: 수명과 로그를 같이 박는다
- 토큰 TTL은 24시간으로 시작하고 연장은 수동 승인
- 공유 링크는 7일 만료를 기본으로, 만료 후 자동 재발급 금지(사람 호출)
- 최소 로그 4필드(주체/리소스/시간/권한) 고정 + 위험 경로 touched면 Draft+승인2명
이 정도면 “에이전트가 뭘 했는지”보다 먼저, “사람이 언제 끼어들어야 하는지”가 명확해진다.
참고자료
- GitHub Blog — From idea to pull request: A practical guide to building with GitHub Copilot CLI
- https://github.blog/ai-and-ml/github-copilot/from-idea-to-pull-request-a-practical-guide-to-building-with-github-copilot-cli/
- Vercel Blog — Keeping community human while scaling with agents
- https://vercel.com/blog/keeping-community-human-while-scaling-with-agents
- Cloudflare Blog — Toxic combinations: when small signals add up to a security incident
- https://blog.cloudflare.com/toxic-combinations-security/
- AWS(비용 프레임 보조로만 사용) — 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/
댓글
댓글 쓰기