개인 AI 워크플로가 팀 규칙이 되는 순간

혼자 쓸 때는 AI 코딩 에이전트(사람 대신 코드를 읽고 짜는 자동화 프로그램)가 실수해도 내가 바로 본다. 이상하면 되돌리고 다시 시키면 그만이다. 그런데 같은 워크플로(작업 순서와 방식)를 팀에 그대로 옮기면 이상한 일이 생긴다. 누가 뭘 승인했는지 아무도 모르고, 사고가 나도 누구 책임인지 불분명하다. 개인 습관과 팀 규칙(거버넌스, governance)은 다른 물건이다.

이 글은 개인의 AI 에이전트 워크플로가 팀 전체의 규칙으로 확장될 때 무엇이 달라져야 하는지를 다룬다. 도구를 더 붙이는 게 도입이 아니다. 누가 어떤 위험을 어떤 증거로 승인하는지 정하는 게 도입이다.

혼자 쓰던 습관이 왜 팀에서는 사고가 되나

혼자 일할 때는 규칙이 머릿속에만 있어도 된다. "이건 손대지 말자", "이건 커밋 전에 한 번 더 보자" 같은 판단을 매번 스스로 내리고 스스로 지킨다. 실수해도 피해 범위가 내 작업 하나로 끝난다.

팀으로 넘어가면 전제가 깨진다. 같은 에이전트를 쓰는 사람이 다섯 명, 열 명으로 늘면 각자 머릿속 규칙이 조금씩 다르다. 어떤 사람은 프로덕션(실제 서비스 중인 환경) 코드도 에이전트에게 맡기고, 어떤 사람은 로컬 스크립트에만 쓴다. 완료됐다고 판단하는 기준도 사람마다 다르다. 이 차이가 쌓이면 같은 저장소 안에서 품질 편차가 커진다.

더 근본적인 문제도 있다. 개인 작업에서는 결과물을 사람이 안 읽고 넘어가도 다음 날 내가 다시 보게 된다. 팀에서는 그 결과물을 다른 사람이 그대로 병합(merge)하거나 배포(deploy)할 수 있다. 검토 없이 넘어간 실수가 내 컴퓨터가 아니라 서비스 전체에 닿는다. 개인 습관을 팀 규칙으로 승격시키는 작업은 그래서 필요하다 — 편의를 위한 절차가 아니라 사고 반경을 좁히는 장치다.

한 팀에서 이 전환점을 가늠하는 체크포인트로 삼을 만한 항목이 있다. 공용 규칙 문서(예: AGENTS.md처럼 에이전트가 지킬 규칙을 적은 파일)가 존재하는지, 작업 유형별로 허용 범위와 금지 범위가 명시돼 있는지, PR(변경 제안) 설명·리뷰 규칙·CI(자동 검증 파이프라인)·배포 확인이 하나의 흐름으로 이어지는지, 비밀값(API 키 같은 민감 정보)·프로덕션·결제·데이터 삭제처럼 되돌리기 어려운 작업에 별도 승인선이 있는지, 반복되는 실패와 잘된 사례가 템플릿이나 운영 지침(runbook)으로 쌓이는지. 이 다섯 개 중 두세 개 이상이 "없다"면 아직 개인 습관 단계에 머물러 있다는 신호로 볼 수 있다.

네 가지 역할을 먼저 나눈다

팀 도입에서 제일 먼저 손대야 하는 건 도구가 아니라 역할이다. 누가 요청하고, 누가 실행하고, 누가 검토하고, 누가 최종 책임을 지는지를 나누지 않으면 에이전트가 잘못을 저질렀을 때 "누구 잘못인지" 자체가 안 정해진다. 이 글에서는 원자료의 프레임을 실전 적용 관점으로 정리해 아래처럼 네 역할로 나눠 볼 것을 제안한다.

역할	책임
요청자	목표, 근거 자료(source of truth), 완료 기준(acceptance criteria)을 제공한다
에이전트	정해진 범위 안에서만 실행하고 실행 근거를 남긴다
리뷰어	요구사항 해석이 맞는지, 위험은 없는지, 변경분(diff)과 검증 방식이 적절한지 확인한다
운영 책임자	배포, 권한, 비밀값, 비용, 감사 흔적(audit trail)을 관리한다

네 역할이 한 사람에게 몰리면 이 표는 장식일 뿐이다. 특히 요청자와 리뷰어가 같은 사람이면 자기가 시킨 일을 자기가 검토하는 구도가 된다. 이건 코드 자체를 AI가 자기 검증하는 문제와 똑같은 함정이다. 검토는 요청한 사람이 아닌 다른 사람이 맡아야 실제로 걸러진다. 팀이 작을수록 역할을 겸직하기 쉬운데, 최소한 리뷰어만큼은 요청자와 분리하는 것을 원칙으로 둘 만하다.

도입은 순서가 있다

규칙을 한 번에 다 만들려고 하면 아무도 안 지킨다. 문서만 늘고 실제 작업 방식은 그대로인 경우가 흔하다. 순서를 지키면 이 함정을 피할 수 있다.

1. 개인 로컬 작업에서 작은 성공 패턴부터 찾는다. 무엇을 시켰을 때 결과가 안정적이었는지 먼저 확인한다.
2. 반복되는 요청을 템플릿과 공용 규칙 문서로 만든다. 매번 새로 설명하지 않아도 되게 굳힌다.
3. 팀 저장소에 리뷰 규칙과 검증 명령을 고정한다. 사람마다 다르게 확인하던 것을 하나로 통일한다.
4. 민감한 작업에는 승인선과 감사 흔적을 붙인다. 여기서부터는 사람의 명시적 승인 없이 넘어가지 않는다.
5. 반복 업무에는 평가 기준(eval)과 자동화를 붙인다. 사람이 매번 판단하지 않아도 되는 부분을 줄인다.
6. 도구별 기능보다 실패 처리와 소유권을 먼저 점검한다. 새 기능 추가보다 사고 났을 때 누가 책임지는지가 우선이다.

이 순서에서 중요한 건 4번과 5번의 위치다. 자동화는 맨 마지막이 아니라 승인선을 먼저 세운 다음에 온다. 승인선 없이 자동화부터 붙이면 위험한 작업까지 사람 손을 거치지 않고 통과하는 구멍이 생긴다.

비밀값과 배포는 별도 승인선을 둔다

모든 작업을 똑같은 강도로 검토하면 검토 자체가 형식이 된다. 사소한 포맷 수정과 프로덕션 배포를 같은 절차로 통과시키면, 사람은 금방 지쳐서 둘 다 대충 훑고 넘어간다. 위험도가 다른 작업은 승인 강도도 달라야 한다.

비밀값 노출, 프로덕션 변경, 결제 관련 로직, 데이터 삭제, 외부 권한 변경 — 이 다섯 가지는 되돌리기 어렵거나 아예 불가능하다는 공통점이 있다. 일반 작업과 같은 경로로 흘러가게 두면 사고가 났을 때 손쓸 방법이 없다. 이런 작업은 처음부터 별도 승인선을 걸어 두는 편이 안전하다 — 예를 들어 사람이 직접 확인하지 않으면 실행 자체가 안 되는 관문(hook) 같은 장치다.

여기서 프롬프트로 "조심해서 다뤄줘"라고 부탁하는 것과 실행 단계에서 원천 차단하는 것은 전혀 다른 안전 수준이다. 부탁은 에이전트가 지금은 예외라고 판단하면 깨진다. 관문은 판단과 상관없이 막는다. 되돌릴 수 없는 작업일수록 부탁이 아니라 관문 쪽에 무게를 둬야 한다.

위험 신호 체크리스트

팀 도입이 잘못된 방향으로 흘러가고 있는지는 몇 가지 신호로 미리 알아챌 수 있다. 다음 항목 중 하나라도 해당하면 바로 점검이 필요하다.

• 에이전트 결과물을 사람이 읽지 않고 바로 병합하거나 배포한다.
• 팀원마다 요청하는 방식과 완료로 인정하는 기준이 제각각이다.
• 비밀값이나 프로덕션 권한이 일반 작업과 똑같은 경로로 노출돼 있다.
• 실패 사례가 대화 기록에만 남고 저장소 규칙이나 운영 지침에는 반영되지 않는다.
• 리뷰어가 요청자 본인이거나, 검토가 형식적인 승인 클릭으로만 끝난다.
• 고위험 작업(비밀값·배포·결제·삭제)에 별도 승인 단계가 없다.

이 중에서도 첫 번째와 세 번째가 가장 무겁다. 검토 없는 병합과 노출된 프로덕션 권한은 사고가 났을 때 바로 실제 피해로 이어진다. 나머지는 품질 저하로 서서히 드러나지만 이 둘은 한 번의 실수로 즉시 터질 수 있다.

실패를 규칙으로 되먹인다

거버넌스는 한 번 만들고 끝나는 문서가 아니다. 실패가 생겼는데 그 기록이 대화창에만 남고 저장소 규칙으로 이어지지 않으면, 같은 실수가 다른 사람에게서 반복된다. 반대로 실패 하나하나를 템플릿이나 운영 지침에 반영하면 팀 전체의 규칙이 실전에서 검증된 것들로 채워진다. 관련해서 개인 단계에서 에이전트에게 일을 맡기기 전 미리 정해야 할 항목들은 AI 에이전트에게 일 맡기기 전 정해야 할 6가지에서 다뤘다. 그 개인 계약이 팀 규칙으로 확장되는 지점이 이 글에서 다룬 역할 분리와 승인선이다. 개인 단계를 건너뛰고 팀 규칙부터 만들면 현실과 안 맞는 문서가 되기 쉽다.

결국 팀 거버넌스가 하는 일은 단순하다. 누가 무엇을, 어떤 증거로, 어디까지 승인하는지를 명확히 하는 것. 도구는 계속 바뀌지만 이 구조는 바뀌지 않는다. 다음으로 점검해 볼 만한 지점은 승인선을 통과한 뒤에도 남는 문제 — 검증자들 사이에 의견이 갈릴 때 팀 차원에서 누구 판단을 따를지 미리 정해 두는 일이다.