팀 도입

팀에서 Codex를 도입한다는 말은 “모두가 AI를 쓰게 한다”가 아닙니다. 같은 저장소에서 같은 승인선, 같은 리뷰 증거, 같은 인수인계 규칙을 쓰게 만드는 것입니다.

이 문서를 읽으면

• 팀 공용 AGENTS.md와 개인 설정의 차이를 이해합니다.
• Codex가 만든 변경을 리뷰 가능한 상태로 받는 기준을 세웁니다.
• 온보딩, 보안, 지표를 도입 초기에 잡습니다.

오늘 바로 해볼 일

팀 저장소 하나를 골라 “Codex가 만든 PR은 어떤 증거를 포함해야 하는가?”를 5줄로 정리하세요. 그 기준이 없으면 도입은 개인 요령으로 흩어집니다.

팀 도입의 첫 기준

영역	정해야 할 것
작업 규칙	팀 공용 AGENTS.md, 금지 파일, 실행 명령
리뷰 규칙	PR 설명, 위험 표시, 테스트 증거
보안	비밀값, 네트워크 접근, 운영 환경 접근, 감사 기록
온보딩	첫 패치, 첫 리뷰, 첫 클라우드 작업
지표	생성량보다 재작업률, 검증률, 리뷰 품질

운영 원칙

• 개인 설정과 팀 규칙을 분리합니다.
• 운영(production), 데이터베이스, 결제, 인증, 보안 영역은 별도 승인선을 둡니다.
• Codex가 만든 PR은 사람이 리뷰할 위험 목록을 포함해야 합니다.
• 온보딩은 설치가 아니라 첫 리뷰 가능한 패치로 끝냅니다.
• 지표는 생성량이 아니라 검증과 재작업 감소를 봅니다.

30일 도입 로드맵

팀 도입은 한 번에 전면 적용하면 흔들리기 쉽습니다. 아래 순서처럼 “작은 저장소 하나에서 리뷰 가능한 결과를 반복”하는 쪽이 안전합니다.

기간	목표	산출물
1주차	파일 수정 없이 Codex 실행 표면과 읽기 범위만 정합니다.	팀 공용 금지선, 첫 작업 요청서 3개
2주차	작은 문서 수정이나 테스트 보강으로 첫 PR을 만듭니다.	PR 템플릿, 검증 명령, review note (리뷰 메모)
3주차	버그 수정, CI 실패, 문서 최신화 중 하나를 실제로 맡깁니다.	diff (변경점), test evidence (테스트 증거), handoff (인수인계)
4주차	반복되는 검증을 스크립트나 CI로 고정합니다.	check script, 실패 기준, 알림 또는 담당자

30일이 지나도 “누가 얼마나 많이 썼는가”보다 “AI 변경을 사람이 더 빨리 믿을 수 있게 되었는가”를 먼저 봅니다.

승인선 매트릭스

팀마다 위험 기준이 다르면 리뷰가 감정 싸움이 됩니다. 아래 표를 저장소 상황에 맞게 바꾸어 PR 템플릿이나 AGENTS.md에 옮깁니다.

작업 유형	기본 허용	별도 승인 필요
문서, 예시, 주석	작은 diff (변경점), 링크 검사, 용어 기준 확인	공식 기능 사실 변경, 가격·법무·보안 표현
UI/CSS	관련 페이지와 스타일 파일, 데스크톱/모바일 화면 확인	디자인 시스템 교체, 접근성 기준 완화
테스트/빌드	실패 재현, 좁은 수정, 검증 명령 기록	테스트 삭제, CI 완화, lockfile 큰 변경
앱 코드	관련 모듈과 테스트, 롤백 가능한 patch	인증, 결제, 데이터 삭제, migration
자동화/MCP	읽기 전용 조회, 요약, 사람이 볼 로그	외부 서비스 쓰기, 상태 변경, secret (비밀값) 접근

PR 템플릿에 넣을 최소 증거

Codex가 만든 PR도 사람이 만든 PR처럼 검토되어야 합니다. 템플릿은 길 필요가 없지만, 리뷰어가 위험을 바로 볼 수 있어야 합니다.

목표:
변경 범위:
Codex가 사용한 실행 표면:
수정하지 않은 범위:
검증 명령과 결과:
스크린샷 또는 CI 링크:
승인 필요했던 작업:
남은 위험:
인수인계:

이 템플릿의 핵심은 “AI가 했다”가 아니라 어떤 증거로 믿을 수 있는가입니다. 자동 리뷰나 GitHub Action을 붙여도 이 최소 증거는 사람이 읽을 수 있어야 합니다.

팀 규칙과 개인 기억을 분리하기

팀에서 반드시 지켜야 하는 규칙은 AGENTS.md, PR 템플릿, 보안 문서처럼 저장소나 조직 문서에 남깁니다. Memories와 Chronicle은 개인의 반복 맥락을 줄이는 보조층일 뿐, 팀 규칙의 유일한 저장소가 되면 안 됩니다.

항목	팀 기준
AGENTS.md	명령어, 금지 행동, 리뷰 증거, 승인 필요한 작업을 저장소에 고정
Memories	개인 선호, 반복 워크플로, 자주 나오는 함정을 보조 기억으로 사용
Chronicle	화면 맥락을 기억으로 만들 수 있으므로 민감 화면, 회의, 사내 자료 앞에서는 일시 중지 기준을 둠
remote connection (원격 연결)	연결된 컴퓨터(host)의 파일, 로그인, Plugin, MCP, 브라우저 권한이 실제 실행 권한임을 문서화
auto-review (자동 리뷰)	승인 요청을 자동 검토할 때도 sandbox (기술 울타리) 안 작업과 승인 필요 작업을 구분하고, 거절/타임아웃 처리 기준을 남김

검증을 팀 자산으로 고정하기

Codex 도입 초기에 가장 빨리 무너지는 지점은 “지난번에는 확인했는데 이번에는 빠진” 검증입니다. 반복되는 검증은 문장으로 기억하지 말고 저장소 안의 실행 가능한 기준으로 옮깁니다.

반복되는 위험	팀 기준으로 바꾸는 방법
모바일에서 문서 레이아웃이 자주 깨짐	빌드 후 대표 페이지를 모바일 폭으로 확인하고, 스크린샷 이름을 PR 템플릿에 남김
redirect나 내부 링크가 자주 틀어짐	check:redirects, check:links처럼 실패하는 스크립트로 고정
AI 기능 품질이 주관적으로 리뷰됨	작은 eval 샘플과 통과 기준을 만들고, 실패 요약을 PR에 붙임
승인선이 리뷰마다 달라짐	PR 템플릿에 “승인 필요했던 작업”과 “승인하지 않은 작업”을 분리
인수인계가 사람마다 다름	완료 보고 형식을 목표, 변경, 검증, 남은 위험 네 줄로 고정

팀 리드는 모든 것을 자동화하려고 하기보다 “다음 PR에서도 같은 방식으로 확인되는가”를 봐야 합니다. 반복 위험은 문서, 스크립트, eval, CI 중 하나로 남아야 합니다.

워크숍으로 연결되는 이유

팀 도입은 문서만 읽어서는 잘 굳지 않습니다. 실제 저장소에서 작업 요청서를 만들고, Codex가 만든 diff (변경점)를 읽고, review note (리뷰 메모)와 handoff (인수인계)를 남겨봐야 팀 기준이 됩니다.

실패 양상

• 팀마다 다른 프롬프트를 쓰며 결과 품질이 흔들립니다.
• AI 리뷰가 사람 리뷰를 대체한다고 오해합니다.
• 자동화가 실패했을 때 책임자와 알림 경로가 없습니다.
• 빠른 생성량만 보고 유지보수 비용을 놓칩니다.
• 개인 Memories에만 남은 규칙을 팀 표준처럼 믿습니다.
• remote connection (원격 연결)에서 연결된 컴퓨터(host)의 로그인 상태와 권한을 놓칩니다.

남길 증거

• 팀 AGENTS.md 변경 이력
• 리뷰 규칙과 PR 템플릿
• 온보딩 체크리스트
• 승인 로그 또는 정책
• 재작업률, 검증률, 리뷰 지적 유형
• Memories/Chronicle 사용 기준과 민감 정보 예외
• remote connection (원격 연결) 허용 컴퓨터(host)와 회수 절차

공식 문서

• Codex app
• Agent approvals & security
• Auto-review
• Memories
• Chronicle
• Remote connections
• Building an AI-Native Engineering Team
• Codex use cases