Codex CLI 첫 커밋 가이드: 1인 개발자를 위한 터미널 온보딩
Codex CLI를 처음 쓰는 1인 개발자가 설치, 로그인, 프로젝트 연결, 첫 작업 지시, 커밋 전 검토까지 따라갈 수 있는 실전 가이드입니다.
왜 CLI부터 익히면 좋은가
1인 개발자는 기획, 코드, 배포, 운영을 혼자 오가야 합니다. Codex CLI 같은 터미널 기반 AI 코딩 도구는 IDE 안의 자동완성과 조금 다릅니다. 파일을 읽고, 명령을 실행하고, 변경 사항을 설명받는 흐름을 한 자리에서 다룰 수 있어 작은 제품을 빠르게 정리하는 데 유용합니다.
다만 처음부터 “앱 하나 만들어줘”처럼 크게 맡기면 결과를 검토하기 어렵습니다. 첫날의 목표는 대단한 기능 완성이 아니라, 내 프로젝트에서 안전하게 한 가지 변경을 만들고 커밋 직전까지 확인하는 감각을 얻는 것입니다.
1. 설치 전에 확인할 것

터미널이 낯설다면 먼저 세 가지만 확인하세요.
- Node.js 또는 사용하는 런타임이 설치되어 있는가
- Git 저장소로 프로젝트가 관리되고 있는가
- 현재 작업물이 커밋되었거나 백업되어 있는가
Codex CLI 설치 방식은 환경과 배포 방식에 따라 달라질 수 있으므로, 실제 명령은 공식 문서의 최신 안내를 따르는 편이 안전합니다. 중요한 것은 설치 명령 자체보다 “어느 폴더에서 실행하는가”입니다. 사이드 프로젝트 폴더로 이동한 뒤 시작해야 Codex가 엉뚱한 파일을 읽지 않습니다.
cd my-side-project
git status
git status에서 변경 파일이 너무 많다면 먼저 정리하세요. AI에게 일을 맡기기 전 기준점을 깨끗하게 만드는 습관이 이후 검토 시간을 줄입니다.
2. 로그인과 권한은 작게 시작하기
로그인 후에는 Codex가 프로젝트 파일을 읽고 명령을 실행할 수 있는 범위를 이해해야 합니다. 처음에는 작은 저장소, 개인 토이 프로젝트, 별도 브랜치에서 연습하는 것이 좋습니다.
권한을 줄 때는 다음 질문을 스스로에게 던져보세요.
| 질문 | 이유 |
|---|---|
| 이 저장소에 민감한 키가 들어 있는가 | .env나 인증 정보 노출을 피하기 위해 |
| 명령 실행 결과를 내가 이해할 수 있는가 | 테스트와 빌드 실패를 판단하기 위해 |
| 변경 범위를 한 문장으로 말할 수 있는가 | 작업 지시가 흐려지는 것을 막기 위해 |
Codex는 협업자처럼 다루는 편이 좋습니다. 모든 맥락을 알고 있다고 가정하기보다, 필요한 배경을 짧게 제공하고 확인 가능한 목표를 주는 방식이 안정적입니다.
3. 프로젝트 연결 후 첫 지시 만들기

첫 작업은 “작고 되돌리기 쉬운 변경”이 적합합니다. 예를 들면 README 문구 정리, 빈 상태 UI 개선, 테스트 하나 추가, 타입 오류 하나 수정처럼 결과가 눈에 보이는 작업입니다.
좋은 첫 지시는 보통 네 요소를 포함합니다.
- 목표: 무엇을 바꿀지
- 범위: 어떤 파일 또는 화면에 한정할지
- 기준: 완료 여부를 어떻게 확인할지
- 제약: 건드리지 말아야 할 것
예시는 다음과 같습니다.
README의 설치 섹션을 처음 온보딩하는 사용자 기준으로 정리해줘.
패키지 매니저는 현재 repo 설정을 따라가고, 새 도구는 추가하지 마.
변경 후 markdown 문법이 깨지지 않았는지 확인해줘.
이 정도면 Codex가 먼저 파일을 읽고, 기존 패턴을 파악한 뒤, 제한된 변경을 제안하기 쉽습니다.
4. 결과 검토는 diff에서 시작한다

작업이 끝났다고 바로 커밋하지 마세요. 1인 개발자에게 가장 중요한 습관은 결과물을 “내가 설명할 수 있는 변경”으로 만드는 것입니다.
먼저 변경 목록을 봅니다.
git status
git diff
검토할 때는 예쁜 코드보다 다음을 먼저 봅니다.
- 요청하지 않은 파일이 바뀌었는가
- 설정, lockfile, 마이그레이션이 불필요하게 수정되었는가
- 기존 UX 문구나 비즈니스 규칙이 바뀌었는가
- 테스트나 빌드로 확인 가능한가
모르는 변경이 있다면 Codex에게 “이 diff를 파일별로 설명하고, 의도하지 않은 변경 후보를 짚어줘”라고 물어보세요. 설명을 듣고도 납득되지 않으면 그 부분은 커밋에 넣지 않는 편이 낫습니다.
5. 첫 커밋은 작게 남긴다
확인 가능한 명령을 실행한 뒤 커밋합니다. 프로젝트마다 다르지만 보통은 타입 체크, 린트, 테스트, 빌드 중 하나 이상을 실행합니다.
npm test
npm run lint
git add README.md
git commit -m "docs: improve onboarding guide"
처음부터 완벽한 자동화 흐름을 만들 필요는 없습니다. 대신 매번 같은 순서를 반복하세요.
- 작업 전
git status - 작은 지시 하나
- 변경 diff 검토
- 확인 명령 실행
- 의미 있는 커밋 메시지 작성
이 루틴이 잡히면 Codex CLI는 “코드를 대신 쓰는 도구”보다 “작은 변경을 빠르게 실험하고 검토하는 작업 파트너”에 가까워집니다. 인디 메이커에게 중요한 것은 속도 자체가 아니라, 혼자서도 변경의 이유와 결과를 추적할 수 있는 리듬입니다.