작업 규모 적응형 AI 개발 프로세스
아홉 단계라고 하면 관료적으로 들리는데, 실제론 반대예요. 크고 위험하면 절차를 늘리고, 작고 명확하면 접어서 한 번에 갑니다.
제 AI 개발 프로세스는 아홉 단계예요. …라고 하면 꽤 관료적으로 들리죠. 실제로는 반대입니다. 크고 위험한 작업일수록 절차를 늘리고, 작고 명확하면 접어서 한 번에 처리해요.
그리고 이 프로세스의 절반은 사실 컨텍스트 관리 규칙이에요. 앞 글에서 쓴 대로 병목은 컨텍스트 무결성이거든요. AI에게 무엇을 어떤 형태로 주입하고, 무엇을 기록으로 남길지 — 그 규칙이 프로세스 안에 녹아 있습니다.
(1년 넘게 굴리면서 자리 잡은 버전이에요.)
아홉 단계, 흐름은 이래요
1–2 · 목적과 성공 조건은 사람이 정한다
무엇을 만들지, 어떤 문제를 풀려는 건지, 최종적으로 어떤 동작을 원하는지. 이건 사람이 정해요. 그리고 완료 판정 기준을 같이 적습니다. 필요한 동작과 허용되지 않는 동작, 기존 구조와의 호환성, 성능·보안·일정 제한, 건드리면 안 되는 기존 기능까지.
방향과 최종 판단은 처음부터 끝까지 사람 몫이에요.
3–5 · 대안을 받고, 반문하고, 고른다
정의한 목적과 제약을 AI에게 주고 구현 방향을 요청해요. 포인트는 정답 하나를 바로 고르지 않는 것. 여러 접근법과 각각의 장단점을 받습니다.
그다음이 제가 가장 공들이는 구간인데요. 모르는 기술과 불확실한 부분을 집요하게 질문합니다. 왜 필요한지, 기존 방식보다 뭐가 나은지, 단점과 실패 조건은 뭔지, 더 단순한 방법은 없는지. 답을 검토하다 새 제약을 발견하면 다시 던지고 수정된 설계를 받아요. 반문하다 보면 처음 정의한 문제 자체가 틀렸다는 걸 발견하기도 하고요.
(가장 오래 걸리는 단계이자, 가장 아깝지 않은 단계예요.)
선택은 사람이 해요. 제안을 그대로 채택하기도 하고, 프로젝트 상황과 선호에 맞게 변형하기도 합니다. 기준은 기존 프로젝트와의 적합성, 구현 복잡도, 유지보수성, 확장 가능성, 작업 범위, 예상 위험이에요.
6–7 · 테스트 기준을 먼저, 구현은 작게
구현 전에 정상 동작·예외 상황·실패 조건·기존 기능 영향·테스트 범위·구현 단계·필요 문서를 정리해요. 큰 작업일수록 이 단계 비중을 키우고, 간단한 작업은 범위와 검증 기준만 확인하고 넘어갑니다.
구현은 AI와 같이 하되, 큰 작업은 기능·책임 단위로 잘라서 작게 바이브 코딩해요. 요구사항이 명확하고 영향 범위가 작으면? 한 번의 요청과 수정으로 끝냅니다.
8 · 실행·테스트·리뷰를 반복한다
구현 결과를 실행하고 테스트하며 반복 수정해요. 이때 정상 동작만 보는 게 아니라 다섯 가지를 같이 봅니다.
- 회귀 안정성 — 새 변경이 기존 기능을 깨뜨리지 않았는가
- 프로젝트 컨벤션 — 코드를 간단하게 만들려다 기존 구조·패턴·네이밍·책임 분리를 어기지 않았는가
- 적절한 확장 가능성 — 단순화하면서 예상되는 변경을 놓치지 않았는가, 반대로 필요 이상으로 복잡하게 설계하지 않았는가
- 오류 가시성 — 에러를 숨기는 기본값, 빈 예외 처리, silent fallback으로 실제 실패가 안 보이게 되지 않았는가
- 실패 지점 파악 — 코드 전체를 머릿속에 넣을 필요는 없다. 이 코드가 어떤 입력에서 깨질 수 있는지, 실패하면 어디서 보이는지, 바꿔야 할 때 어디를 열어야 하는지를 확인한다. "왜 이렇게 했는지"는 머리가 아니라 문서가 기억한다
문제가 보이면 AI에게 리뷰와 반론, 다른 해법을 다시 요청해서 고쳐요. 이해에 쓰는 깊이는 작업 위험도에 비례시킵니다. 조용히 틀리면 큰일 나는 코드는 리뷰 시점에 깊게 파고, 영향 범위가 좁은 코드는 계약 수준 확인으로 충분해요.
9 · 문서로 남긴다
최종 테스트와 리뷰를 거친 뒤 필요한 문서를 정리해요. 큰 작업은 설계·테스트·제약조건·구현 구조를 문서로 남기고 — 이게 앞 글에서 말한 중앙 정리본에 쌓여요 — 간단한 작업은 커밋과 PR 기록 정도로 끝냅니다.
규모에 따라 접었다 폅니다
| 규모 | 흐름 |
|---|---|
| 간단한 작업 | 목적 정의 → 제약 확인 → 구현 요청 → 검토·수정 → 실행·테스트 → 완료 |
| 중간 규모 | 목적·성공 조건 정의 → 대안 검토 → 기술 질문과 반론 → 방향 선택 → 구현 → 테스트·리뷰 → 리팩터링 → 필요 문서 정리 |
| 큰 작업 | 성공 조건 상세화 → 여러 방향 탐색 → 반복적 반문과 설계 재정립 → 방향 선택·변형 → 테스트·예외·문서 계획 → 작은 단위 구현 → 실행·테스트·리뷰·리팩터링 반복 → 최종 검증·문서화 |
결국 역할 분담이에요
AI는 방향 탐색, 대안 제시, 구현, 리뷰를 맡아요. 사람은 목적 정의, 제약 설정, 기술 선택, 코드 판단, 최종 품질 책임을 집니다.
도구가 Cursor에서 Claude로, Codex로 바뀌는 동안에도 이 분담은 한 번도 바뀐 적이 없어요. 그리고 바뀌지 않았기 때문에, 도구를 바꿀 수 있었습니다.
