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