Codex 실습에서 배운 것 — AI 개발은 명령보다 작업 흐름 설계가 중요하다
요약
AI 코딩의 핵심은 빠른 코드 생성이 아니라, AI가 어느 단계까지 일하고 어디서 멈춰야 하는지를 사람이 설계하는 데 있다.
AI가 너무 빨리, 너무 많이 진행한다
Codex 실습을 하면서 가장 먼저 확인한 건, AI 코딩이 생각보다 빠르다는 사실이었다.
정적 웹앱, 랜딩페이지, 회의록 MVP, ERP 휴가관리 기능까지 — 생각보다 빠르게 만들어졌다. 그런데 실습을 진행할수록 더 중요한 문제가 보이기 시작했다. AI가 너무 빨리, 너무 많이 진행한다는 것이다.
$pdca 실습에서 의도한 흐름은 이랬다.
- Plan 작성
- Design 작성
- DESIGN.md 반영
- AGENTS.md 작성
- Do 구현
- Check 검증
- Act 개선
그런데 실제로는 한 번의 넓은 지시로 전체 흐름이 자동 진행됐다. 결과물만 보면 성공처럼 보이지만, 중간 판단을 통째로 건너뛴 것이다.
AI에게는 목표뿐 아니라 멈춤 조건을 함께 줘야 한다
이 경험에서 알게 된 것은 하나다. AI에게는 목표뿐 아니라 멈춤 조건을 함께 줘야 한다.
- “이번 단계만 수행하라”
- “다음 단계로 넘어가지 마라”
- “설계 문서만 만들고 멈춰라”
- “구현은 승인 후 진행하라”
이런 지시가 없으면, AI는 선의로 더 많은 일을 해버린다.
Figma MCP vs DESIGN.md — 도구 선택의 기준
Figma MCP 실습도 비슷한 교훈을 줬다. 디자인 파일을 직접 생성하는 연동 과정은 인상적이었지만, 무료 플랜 호출 한도에 금방 걸렸다. 도구가 강력하더라도 비용·제한·반복 가능성까지 함께 봐야 실전에서 쓸 수 있다.
반면 DESIGN.md 방식은 훨씬 실용적이었다. 외부 호출 없이 디자인 기준을 코드에 반영할 수 있었고, 반복 수정에도 안정적이었다.
두 방식의 차이는 이렇게 정리된다.
- Figma MCP: 시각 디자인 초안 생성에 강함
- DESIGN.md: 코드 기반 UI 개선과 반복 작업에 강함
현재 운영 환경에서는 DESIGN.md 방식이 더 실전적이다.
Codex를 쓸 때 적용할 운영 원칙
이번 실습을 바탕으로 앞으로 Codex를 쓸 때 적용할 원칙을 정리했다.
- 새 실습은 반드시 별도 폴더에서 시작한다.
- Plan과 Design은 구현 전에 확인한다.
- DESIGN.md와 AGENTS.md를 먼저 만든다.
- Do 단계는 승인 후 진행한다.
- Check 결과를 보고 Act 여부를 결정한다.
- 플러그인과 MCP는 실험 도구로 먼저 검증한다.
- 실제 운영 프로젝트에는 처음부터 Full access를 주지 않는다.
이번 인사이트의 핵심
AI 개발 역량은 프롬프트를 잘 쓰는 능력만이 아니다. AI가 일하는 순서와 권한을 설계하는 운영 능력이다.
Codex는 강력하다. 그리고 강력한 만큼, 사람이 더 명확한 운영자가 되어야 한다.