에이전트 도입이 어렵다는 말의 진짜 뜻: ‘사고로 변하는 조합’을 끊는 운영 설계

thumbnail

에이전트를 붙이고 일주일만 굴려보면, 사람들 입에서 같은 불평이 나온다. “결과는 나오는데, 일이 더 늘었다.”

코드는 더 빨리 생기는데, 팀이 바빠지는 지점은 따로 있다. PR이 늘고, 리뷰가 밀리고, 재시도가 습관이 되고, 토큰과 공유 링크가 여기저기 흩어진다. 그리고 어느 날은 “왜 이렇게 됐는지”를 아무도 설명 못 한다. 그게 불편한 진짜 이유다.

뉴스 요약은 빼고, 첫 주에 사고를 만드는 조합을 끊는 얘기만 적는다. 여기서 말하는 조합은 거창한 해킹이 아니다. 작은 신호들이 겹치는 순간, 평소엔 무해하던 자동화가 사고가 되는 패턴이다. (이 관점이 딱 좋았던 사례가 Cloudflare의 ‘toxic combinations’였다. 참고자료)

자동화는 답변이 아니라 라우팅에서 돈이 난다

Vercel이 커뮤니티를 운영하면서 에이전트를 붙인 이야기를 보면, 에이전트가 ‘답변을 대신’하는 역할로 쓰이지 않는다. 오히려 사람이 답할 자리를 만들어준다.

  • 비슷한 글을 묶어서 중복을 줄이고
  • 어디로 보내야 하는지(담당/채널/스레드)를 추천하고
  • 한동안 아무도 안 보면 다시 건드린다(재할당/리마인더)

개발팀으로 번역하면 금방 나온다. “코드를 고쳐”를 시키기 전에, “누가 볼지”를 먼저 정한다.

예를 들면 이런 식이다.

  • /auth touched면 @security-oncall
  • /payments touched면 @billing-owner
  • 문서만 바뀌면 라운드로빈
  • PR이 48시간 멈춰 있으면 needs-attention 붙이고 리뷰어를 한 명 더 붙인다

이걸 자동으로 100% 실행하겠다는 게 아니다. 처음엔 ‘추천’으로만 돌려도 효과가 있다. 사람은 생각보다 “어디에 집중해야 하는지”가 정리되는 순간부터 편해진다.

작은 신호가 겹치면 사고가 된다

Cloudflare가 말한 toxic combinations을 운영 언어로 풀면 이렇다. 단일 원인보다, 하찮아 보이는 신호가 겹칠 때 문제가 ‘사건’이 된다.

에이전트 운영에서 자주 보는 조합도 비슷하다.

  • 밤늦게 올라온 PR(리뷰어 판단력 ↓)
  • “작아 보이는” diff(경계심 ↓)
  • 근데 위험 경로를 건드림(/auth, /billing)
  • 테스트가 깨져서 재시도 커밋이 쌓임
  • 공유 링크/토큰은 남아 있는데, 누가 봤는지 로그가 없음

개별로 보면 다 그럴 수 있다. 묶이면 사고다. 그래서 첫 주에는 기능보다 조합을 끊는 규칙이 먼저 들어가야 한다.

그리고 이건 개발자만의 문제가 아니다. 보안 UI도 운영 비용이다.

Cloudflare가 Turnstile/Challenge 페이지를 다시 손본 이야기에서 재미있는 지점은, “사용자가 보게 되는 UI”가 오탐/이탈/지원 티켓으로 직결된다는 감각이다. 자동화가 늘수록 ‘사람이 보는 마찰’이 늘고, 그 마찰이 운영 비용으로 돌아온다. 에이전트가 만든 변화가 사용자에게 닿는 순간부터는, 코드가 아니라 UX가 장애를 만든다. (참고자료)

“실행”을 기본값으로 둘지 말지, 딱 세 가지만 본다

GitHub Copilot CLI의 흐름은 의도→/plan→검증→diff→PR로 이어진다. 중요한 포인트는 “승인 후 실행”이라는 운영 습관이다. (참고자료)

기본값 정할 때는 말 길게 하지 않는다. 아래 세 개로만 자른다.

1) 되돌리기 비용 - 되돌리기 쉽다(포맷팅, 문서, 테스트 추가) → 실행 기본도 가능 - 되돌리기 어렵다(DB 마이그레이션, 결제/권한 로직) → 제안 기본

2) 권한 경로가 섞이는지 - 위험 경로가 껴 있으면(예: /auth, /billing) 실행 기본은 금지 - “승인 2명” 같은 조건을 자동으로 걸 수 있을 때만 전진

3) 관측 가능성(증거가 남는지) - 마지막 실행/근거/반복 횟수가 남는다 → 실행을 조금 더 허용 - 증거가 안 남는다 → 제안 기본으로 두고, 사람 호출을 빠르게

이렇게 정하면, ‘모델 선택’보다 먼저 운영 안전장치가 잡힌다.

내가 위키 상단에 박아두는 것(딱 이 정도만)

아래는 팀 위키 상단에 그대로 박아두는 버전이다. 숫자는 팀 사정에 맞게 바꾸면 된다.

  • PR이 48시간 멈춰 있으면(24h는 너무 잦고 72h는 너무 늦어서 여기로 시작) needs-attention 붙이고 리뷰어 1명 추가
  • 변경 파일 15개 넘으면 PR은 쪼개서 다시(리뷰어 30분 룰로 시작)
  • 위험 경로(/auth, /billing, /payments) touched면 Draft 고정 + 승인 2명
  • 테스트 1회 실패면 멈춘다(재시도 금지). PR에 “원인/마지막 실행/다음 액션” 3줄만 남기고 사람 태그
  • 동일 실패 3회면 강제 중단(커밋 금지, 상태만 업데이트)
  • 토큰 TTL 24h로 시작(보통은 더 짧게 가는 게 맞다), 연장은 수동 승인
  • 공유 링크 7일 만료 기본 + 만료 후 자동 재발급 금지(사람 호출)
  • 최소 로그 4필드(주체/리소스/시간/권한) 고정
  • 사용자 마찰이 생기는 자동화(UI/Challenge)는 지표만 보지 말고, 지원 티켓/이탈까지 같이 본다

이게 완벽한 체크리스트는 아니다. 완벽하진 않아도, 금요일 밤에 터질 조합을 끊는 데는 이게 제일 싸다.

참고자료

  • 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/
  • Cloudflare Blog — The most-seen UI on the Internet? Redesigning Turnstile and Challenge Pages
    • https://blog.cloudflare.com/the-most-seen-ui-on-the-internet-redesigning-turnstile-and-challenge-pages/

댓글

댓글 쓰기