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

혼자 쓸 때는 AI 코딩 에이전트(사람 대신 코드를 읽고 짜는 자동화 프로그램)가 실수해도 내가 바로 본다. 이상하면 되돌리고 다시 시킬 수 있다. 그런데 승인자·검증 명령·영향 범위를 작업 기록에 남기지 않은 채 같은 워크플로(작업 순서와 방식)를 팀에 옮기면, 나중에 누가 무엇을 승인했는지 기록만으로 확인하기 어렵다. 개인 습관과 팀 규칙(거버넌스, governance)은 다른 물건이다.

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

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

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

팀으로 넘어가면 전제가 깨진다. 같은 에이전트를 쓰는 사람이 늘면 각자 머릿속 규칙이 조금씩 다를 수 있다. 어떤 사람은 프로덕션(실제 서비스 중인 환경) 코드도 에이전트에게 맡기고, 어떤 사람은 로컬 스크립트에만 쓴다. 완료됐다고 판단하는 기준도 문서로 고정하지 않으면 달라질 수 있다. 이 차이를 그대로 두면 같은 저장소의 작업을 서로 다른 기준으로 승인하게 된다.

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

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

네 가지 역할을 먼저 나눈다

팀 도입에서 제일 먼저 손대야 하는 건 도구가 아니라 역할이다. 누가 요청하고, 누가 실행하고, 누가 검토하고, 누가 최종 책임을 지는지를 나누지 않으면 에이전트가 잘못을 저질렀을 때 "누구 잘못인지" 자체가 안 정해진다. 아래 역할표의 원자료는 이 저장소의 ARTICLE_RULES.md와 HANDOFF.md다. 전자는 작성자와 검증자를 분리하고 실행한 검증만 밝히도록 규정하며, 후자는 각 작업의 변경·실행 증거·미확인 위험을 같은 항목으로 남긴다.

실패 기록도 남아 있다. 2026년 8월 5일 HANDOFF.md에는 전체 vitest가 로컬 포트 권한 오류(EPERM)로 테스트 수집 전에 멈춰 실행된 테스트가 0개였다고 적혀 있다. 같은 기록은 별도로 실행한 단위 테스트와 타입 검사 결과를 구분하고, 전체 322개 테스트는 확인하지 못한 상태라고 남겼다. 검증 명령을 적는 것만으로는 부족하고, 실제로 어디까지 실행됐는지를 승인 상태와 분리해야 한다는 사례다.

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

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

도입은 순서가 있다

처음부터 모든 작업에 같은 규칙을 붙이면서 각 규칙을 어느 단계에서 누가 확인할지 정하지 않으면, 문서 항목은 늘어도 작업 기록에서는 적용 여부를 찾기 어렵다. 그래서 아래 순서는 규칙의 양보다 실행 위치와 책임자를 먼저 고정한다.

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

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

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

모든 작업을 똑같은 강도로 검토하면 위험 차이가 승인 기록에서 사라진다. 사소한 포맷 수정과 프로덕션 배포에 같은 질문과 같은 증거만 요구하는 구성에서는, 승인자가 어느 항목을 더 깊게 확인해야 하는지 알 수 없다. 위험도가 다른 작업은 승인 강도도 달라야 한다.

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

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

위험 신호 체크리스트

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

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

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

실패를 규칙으로 되먹인다

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

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

작업 한 건에 거버넌스를 붙이는 방법

규칙이 실제로 작동하는지는 공용 문서의 분량이 아니라 작업 한 건을 따라가 보면 드러난다. 요청자가 목표와 완료 기준을 적고, 에이전트가 정해진 범위만 바꾸고, 리뷰어가 변경분과 검증 결과를 확인하고, 운영 책임자가 고위험 실행을 승인하는 흐름이 한 작업 기록 안에서 이어져야 한다. 역할 이름만 문서에 있고 각 단계의 증거가 남지 않으면 사고 뒤에 "누가 봤는가"를 복원할 수 없다.

1. 요청자는 바꿀 대상과 손대지 않을 대상을 파일이나 기능 단위로 적는다. "로그인 개선"보다 "로그아웃 뒤 이전 세션으로 비공개 화면에 접근할 수 없는 상태"처럼 완료 여부를 판정할 문장을 함께 둔다.
2. 에이전트는 시작 전에 현재 변경 상태를 확인하고, 자신이 만든 변경 파일과 실행한 검증 명령을 남긴다. 성공 로그만 잘라 붙이지 말고 실패했다가 바꾼 과정도 숨기지 않는다.
3. 리뷰어는 결과 설명보다 실제 변경분을 먼저 본다. 요청 범위를 넘은 파일, 삭제된 방어 코드, 실행하지 않은 검증이 없는지 확인한 뒤 완료 기준과 결과를 대조한다.
4. 비밀값·프로덕션·결제·데이터 삭제·외부 권한 변경이 포함되면 일반 리뷰를 통과했어도 별도 승인선으로 보낸다. 이 단계에서는 무엇을 실행할지, 되돌릴 방법이 있는지, 실행 뒤 무엇을 확인할지를 사람이 다시 적는다.
5. 작업이 끝나면 반복 가능한 교훈만 공용 규칙으로 옮긴다. 한 번의 특수한 상황까지 모두 규칙으로 만들면 문서가 예외 목록으로 불어나므로, 다른 작업에서도 다시 나타날 조건인지 먼저 구분한다.

작업 상태	필수 증거	다음 행동
일반 코드·문서 변경	변경분, 완료 기준, 검증 명령과 결과	분리된 리뷰어가 병합 여부 판단
검증 실패	실패한 명령, 오류 값, 아직 확인 못 한 범위	완료로 표시하지 않고 수정 또는 범위 축소
고위험 작업 포함	실행 대상, 영향 범위, 되돌림 방법, 실행 후 확인값	운영 책임자의 명시적 승인 뒤 실행
같은 실패 재발	이전 사례와 이번 사례의 공통 조건	공용 규칙·템플릿·관문 중 맞는 위치에 반영

작은 팀에서는 네 역할을 네 사람이 각각 맡기 어려울 수 있다. 이때 사람 수를 억지로 늘리기보다 충돌하는 역할을 같은 순간에 겸하지 않는 선을 지킨다. 요청자와 실행자를 한 사람이 맡더라도 리뷰는 다른 사람이 하게 하고, 운영 책임자가 직접 요청한 고위험 변경이라면 최소한 실행 전 확인자를 따로 둔다. 중요한 것은 직함의 개수가 아니라 자신의 해석과 실행을 자신의 클릭 하나로 승인하지 않는 구조다.

반대로 모든 작업에 운영 책임자 승인을 붙이면 사소한 오탈자와 데이터 삭제가 같은 대기열에 들어간다. 두 작업에 같은 승인 항목만 보인다면 데이터 삭제에 필요한 영향 범위와 되돌림 확인이 별도로 드러나지 않아, 승인 기록만으로 검토 강도를 구분할 수 없다. 일반 경로와 별도 승인선을 가르는 기준은 에이전트를 썼는지가 아니라 실패했을 때 영향이 어디까지 퍼지고 되돌릴 수 있는지다. 원상 복구가 쉽고 권한 변화가 없는 변경은 기본 리뷰로, 실제 사용자·비용·비밀값·삭제에 닿는 변경은 별도 승인선으로 보낸다.

마지막으로 "검증 완료"라는 말만 남기지 않는다. 어떤 명령을 어느 변경 상태에서 실행했고 무엇이 통과했는지 적어야 다음 사람이 같은 판정을 재현할 수 있다. 실행하지 못한 검증은 누락이 아니라 미확인 항목으로 드러내야 한다. 거버넌스의 목적은 모든 실패를 막는 것이 아니라, 실패가 조용히 승인으로 바뀌는 경로를 끊고 문제가 생겼을 때 책임과 근거를 빠르게 찾게 하는 데 있다.

리뷰어가 증거를 재현할 수 없거나 영향 범위를 확인하지 못했다면 판정은 승인이 아니라 보류다. 일정이 급하다는 이유로 미확인을 통과로 바꾸지 말고, 확인 가능한 범위로 작업을 줄이거나 필요한 검증 환경을 마련한 뒤 다시 판단한다.

자주 묻는 질문

작은 팀이라면 요청자와 리뷰어가 같은 사람이어도 되는가?

같은 사람이 요청과 검토를 모두 맡으면 자기가 시킨 일을 자기가 승인하는 구도가 된다. 팀이 작아 역할을 겸직하더라도 최소한 리뷰어는 요청자와 분리해 요구사항 해석·위험·변경분·검증 방식을 다른 눈으로 확인해야 한다.

팀에 AI 자동화를 먼저 붙이고 승인선은 나중에 만들어도 되는가?

승인선 없는 자동화는 위험한 작업까지 사람 확인 없이 통과시키는 구멍을 만든다. 공용 규칙과 검증 명령을 고정한 뒤 민감 작업의 승인선과 감사 흔적을 세우고, 그 다음 반복 업무에 평가 기준과 자동화를 붙여야 한다.

사소한 수정과 프로덕션 배포를 같은 절차로 검토해도 되는가?

모든 작업에 같은 질문과 증거를 요구하면 승인 기록에서 위험 차이를 구분하기 어렵다. 비밀값·프로덕션·결제·데이터 삭제·외부 권한 변경은 일반 작업과 분리해 사람의 명시적 승인 없이는 실행되지 않는 관문을 둬야 한다.

실패 사례를 팀 대화 기록에 남기기만 해도 충분한가?

대화에만 남은 실패는 다른 팀원이 같은 실수를 반복하게 만든다. 반복된 실패와 잘된 사례를 공용 규칙, 요청 템플릿, 운영 지침에 반영해야 개인의 경험이 팀 전체가 다시 사용할 수 있는 기준으로 쌓인다.