코덱스 툴 사용법 02: 새 프로젝트 온보딩 | DAKER 커뮤니티

코덱스 툴 사용법 02: 새 프로젝트 온보딩

새 저장소에서 코덱스를 바로 수정 담당자로 쓰면 빠른 것처럼 보이지만, 실제로는 규칙을 모르는 상태에서 손을 대는 셈이다. 좋은 시작은 "수정하지 말고 먼저 읽어줘"다. 코덱스가 AGENTS.md, README, package scripts, 테스트 명령, 배포 표면을 먼저 파악하면 이후 작업의 정확도가 크게 오른다.

1. 첫 요청은 읽기 전용으로 시작한다

처음에는 이렇게 요청한다.

이 저장소를 수정하지 말고 읽기 전용으로 파악해줘.    목표: 게시글 카드의 이미지가 모바일에서 잘리지 않게 한다.
범위: community post card 컴포넌트와 관련 CSS만 수정한다.
완료 기준: 모바일 375px, 데스크톱 1440px에서 이미지 비율 유지.
검증: lint와 Playwright screenshot 확인.   이렇게 쓰면 코덱스가 설계 토론, 구현, 검증 중 어디에 집중해야 하는지 바로 알 수 있다.  3. 저장소 규칙을 작업 계약으로 만든다  AGENTS.md에 "테스트를 먼저 돌려라", "특정 폴더는 건드리지 마라", "커밋 메시지는 이 형식을 써라" 같은 규칙이 있으면 작업 계약이다. 코덱스에게 해당 규칙을 요약하게 한 뒤 그 기준으로 작업을 맡기면, 나중에 리뷰할 때 기준이 흔들리지 않는다.  4. 첫 작업은 작게 고른다  새 프로젝트의 첫 코덱스 작업은 대형 리팩터링보다 작은 버그 수정이나 문서 보강이 좋다. 작은 작업에서 명령, 테스트, 스타일, 배포 흐름을 익히면 두 번째 작업부터 속도가 붙는다.  Senior takeaway: 코덱스 온보딩은 "많이 알려주기"가 아니라 "먼저 읽게 하고, 범위를 닫고, 검증 기준을 고정하는 일"이다. 이 순서를 만들면 AI 코딩이 운에 덜 기대고 팀의 실제 개발 생산성에 가까워진다. 
AGENTS.md, README, package scripts, 테스트 명령, 위험한 변경 영역을 요약해줘.
마지막에 내가 다음 작업을 맡길 때 필요한 정보만 정리해줘.

이 한 문장만으로도 코덱스가 무작정 파일을 열고 바꾸는 흐름을 줄일 수 있다. 특히 여러 프레임워크가 섞인 저장소에서는 "어떤 명령으로 검증할 수 있는지"가 가장 중요한 컨텍스트다.

2. 컨텍스트는 우선순위를 둔다

코덱스에게 긴 설명을 주는 것보다 중요한 것은 순서다. 현재 증상, 프로젝트 규칙, 변경 범위, 완료 기준 순서로 주면 된다.