Codex Team Config, 팀 설정을 한곳에 모을 때 기준이 선명해지는 이유 | DAKER 커뮤니티
같은 저장소를 열었는데도 누구는 명령을 바로 실행하고, 누구는 승인 대기 화면에서 멈춘다면 문제는 코드보다 설정 계층에 있을 가능성이 큽니다. 팀마다 Codex 답변이 달라지는 이유도 대개 여기서 갈립니다.
이럴 때 필요한 것이 Codex Team Config입니다. 개인 취향은 개인 설정에 남기고, 프로젝트 안전 기준과 반복 절차만 팀이 공유하는 계층에 모아 두면 첫 질문보다 설정 확인에 더 오래 걸리는 상황을 줄이기 좋습니다.
왜 팀마다 Codex 답변이 달라질까요?
한 개발자는 조회 명령을 바로 실행하고, 다른 개발자는 같은 명령에서 승인 대기 화면에 멈춥니다. 누군가는 리뷰 스킬을 알고, 누군가는 매번 긴 프롬프트를 붙여 넣습니다. 코드가 다른 것이 아니라 Codex가 읽는 설정 계층이 달라진 장면입니다.
같은 저장소를 열어도 Codex가 읽는 설정 계층이 다르면 답변과 동작 기준도 달라집니다.
Codex Team Config는 무엇을 모으나요?
Codex Team Config의 핵심은 개인 취향은 개인 설정에 두고, 프로젝트 안전 기준과 반복 절차만 팀이 공유하는 계층에 모으는 것입니다. Codex Team Config란, 팀이 쓰는 설정과 규칙과 스킬을 공통 계층으로 묶어 재사용하는 방식입니다.
중요한 점은 팀 계층이 모든 것을 담는 서랍이 아니라는 것입니다. 인증과 개인 프로필과 알림은 공유 대상이 아니며, 프로젝트가 신뢰된 뒤에만 프로젝트 공통 계층을 읽는다는 전제를 함께 세워야 합니다.
팀 계층에는 프로젝트 안전 기준과 반복 절차만 두고, 개인 취향과 인증 정보는 분리하는 것이 핵심입니다.
무엇을 팀 계층에 넣어야 할까요?
아래 기준은 여러 개발자가 같은 저장소에서 Codex CLI와 IDE 확장을 함께 쓸 때 적용하기 좋습니다. 먼저 팀이 반복해서 설명하는 항목을 설정 기본값, 명령 규칙, 스킬 절차로 나누면 됩니다. 반대로 개인 모델 취향, 알림, 인증, 비밀값, 텔레메트리처럼 사용자나 조직 경계가 있는 항목은 개인 또는 관리자 계층에 남기는 것이 좋습니다.
프로젝트에서 공유해도 되는 기본값만 저장소의 공통 설정 계층에 넣고, 신뢰한 프로젝트에서만 로드되는지 확인하면 됩니다. 또 명령 승인 기준은 rules 계층으로, 반복 작업 순서는 skills 계층으로 분리해 두면 역할이 선명해집니다. 새 설정을 넣은 뒤에는 CLI와 IDE 확장에서 같은 작업을 열어 실제로 같은 기준이 적용되는지 검증하는 과정이 필요합니다.
리뷰 루틴은 어디에 들어갈까요?
예를 들어 팀이 PR 전 리뷰를 항상 같은 방식으로 한다면, 리뷰 전 테스트를 먼저 확인한다는 작업 지침은 AGENTS 파일에 두면 됩니다. 반복 리뷰 절차는 skill로 빼고, 리뷰 중 허용해도 되는 조회 명령은 rules로 분리합니다. 이렇게 나누면 새 팀원이 들어와도 어디를 고쳐야 하는지 보입니다.
| 항목 | 개인 계층에 둘 것 | 팀 계층에 둘 것 |
|---|---|---|
| 설정 기본값 | 개인 모델 취향과 알림 | 프로젝트별 sandbox와 승인 기준 |
| 명령 제어 | 임시 허용 명령 | 반복되는 안전한 조회 명령 |
| 작업 절차 | 개인 습관 | 리뷰, 배포, 검증 같은 반복 스킬 |
| 보안 경계 | 개인 토큰과 비밀값 | 공유 가능한 정책과 제외 규칙 |
개인값과 팀 규칙은 어디서 갈라질까요?
여러 개발자의 책상 위 설정 카드들이 중앙의 Team Config 보드로 모입니다. 왼쪽에는 개인 설정 서랍, 가운데에는 프로젝트 공통 설정, 오른쪽에는 관리자 요구사항 문서가 분리됩니다. 가운데 보드에는 config, rules, skills 세 구역이 색으로 나뉘어 보입니다. 하단에는 분류하기, 공유하기, 신뢰하기, 검증하기 순서가 큰 아이콘으로 남습니다.
공유 설정에서 무엇을 빼야 할까요?
Team Config의 실패는 대개 무엇을 넣을지보다 무엇을 빼야 할지에서 생깁니다. 개인 환경과 팀 정책이 섞이지 않도록 몇 가지 기준을 먼저 잠그는 것이 좋습니다.
- 프로젝트 설정에 인증, provider, 알림, 원격 주소, 비밀값 같은 개인 또는 관리자 항목을 넣지 않았는지 봅니다.
- 저장소 공통 설정은 프로젝트를 신뢰한 뒤에만 로드된다는 전제를 팀 온보딩에 적어 두면 좋습니다.
- Rules는 명령 승인 기준, Skills는 반복 절차, AGENTS는 작업 지침으로 역할을 나눕니다.
- 하위 폴더 설정이 상위 설정을 덮는 경우를 실제 작업 위치에서 확인하면 됩니다.
- 설정 변경 뒤 Codex 상태 화면이나 간단한 테스트 작업으로 적용 여부를 검증하는 것이 좋습니다.
공유 설정의 품질은 무엇을 넣었는가보다 무엇을 제외했는가에서 더 자주 갈립니다.
자주 묻는 질문
Team Config는 AGENTS 파일을 대체하나요?
아닙니다. Team Config는 설정, rules, skills를 표준화하고 AGENTS 파일은 작업 지침과 프로젝트 맥락을 전달하는 역할에 가깝습니다.
개인 설정을 저장소에 넣어도 되나요?
인증, provider, 알림, 텔레메트리, 개인 프로필은 저장소에 넣지 않는 편이 안전합니다. 공유 가능한 프로젝트 기본값만 팀 계층에 둡니다.
프로젝트 설정은 언제 로드되나요?
공식 설명 기준으로 프로젝트가 신뢰된 상태일 때 프로젝트 공통 설정 계층이 로드됩니다.
Rules와 Skills를 왜 나눠야 하나요?
Rules는 명령 승인과 안전 경계를 다루고, Skills는 반복 작업 절차를 다룹니다. 둘을 섞으면 검토자가 위험과 절차를 분리해 보기 어렵습니다.
오늘 바로 적용할 최소 루틴은 무엇인가요?
팀이 반복해서 설명하는 승인 기준 하나와 검증 절차 하나를 골라 rules와 skills 후보로 나누는 것부터 시작하면 됩니다.
참고 자료
여러분의 팀에서는 반복해서 설명하는 Codex 기준 중 무엇을 먼저 개인 설정과 팀 계층으로 나누고 있나요?