이 글은 기능 구현에 대한 기록이 아니다.
AI(Codex)가 제안한 개발 계획의 첫 단계(Step 1)를 그대로 실행해, 프로젝트를 시작할 수 있는 최소 상태(Minimum Startable State)를 만드는 데 집중한 30분의 기록이다.
코드는 거의 쓰지 않았지만, 빌드 환경·SDK·JDK 기준을 먼저 정리함으로써 이후 구현이 흔들리지 않을 상태를 확보했다.
이 글은 _무엇을 만들었는지_보다 _이제 만들어도 되는 상태가 되었는지_에 대한 판단을 다룬다.
1. 들어가며: “구현을 시작할 수 있는 상태”를 만든 30분
오늘 개발에 쓴 시간은 30분이었다.
08:00에 시작해서 08:30에 종료.
짧다면 짧은 시간인데, 이 시간을 ‘작업량’으로만 보면 설명이 잘 안 된다.
오늘의 목표는 기능(Feature)이 아니라 MSS(Minimum Startable State),
즉 _구현을 시작할 수 있는 최소 상태_를 만드는 것이었기 때문이다.
이 프로젝트는 아직 비어 있다.
그런데도 오늘은 분명히 “시작해도 되는 상태”가 만들어졌다.
무엇을 만들었느냐가 아니라, 이제 만들어도 되는지가 달라진 30분이었다.
2. 전략: 왜 Codex의 제안(Step 1)을 그대로 따랐는가
이 프로젝트는 시작하기 전에 원칙을 하나 정했다.
나는 구현자가 아니라 판단자 역할만 수행한다는 원칙이다.
코드를 어떻게 작성할지, 구조를 어떻게 설계할지에 대해서
내가 직접 개입하지 않기로 했다.
대신 Codex가 제안하는 계획과 순서를 그대로 실행하고,
그 결과가 프로젝트를 “시작 가능한 상태”로 만드는지만 판단한다.
이 전제를 선택한 순간, 개발 계획을 “내가 더 잘 만들기” 위해 고치는 건 의미가 없어졌다.
그건 곧 실험 조건을 깨는 일이 된다. 그래서 Step 1은 수정하지 않았다.
Codex가 제안한 Step 1은 Project and SDK setup.
효율적으로 보여서가 아니라, 역할을 지키기 위해 그대로 수행했다.
3. 실행: 30분 동안 일어난 ‘세 가지 상태 변화’
이 30분 동안 새로운 기능은 하나도 생기지 않았다.
대신 프로젝트의 상태가 세 가지 방향으로 바뀌었다.
1) 프로젝트 뼈대가 “생성된 상태”
프로젝트 뼈대를 만들고, Gradle 래퍼가 정상인지 확인했다.
이 단계가 끝나고 나서야 이 프로젝트는
아이디어가 아니라 실행 가능한 프로젝트가 되었다.
2) 빌드 환경이 “결정된 상태”
Gradle 설정과 SDK 기준을 정리했다.
이 단계의 목적은 설정을 많이 만지는 게 아니라,
환경 기준을 확정하는 것이었다.
빌드 환경이 불분명하면 이후 모든 구현이 흔들린다.
그래서 기능 구현보다 먼저 이 기준을 고정했다.
3) 실행 전제 조건이 “분리된 상태”
로컬 환경과 프로젝트가 요구하는 조건을
같은 문제로 취급하지 않기로 했다.
시스템 전체를 바꾸는 대신,
이 프로젝트에만 필요한 조건을 적용하는 방식으로 전제 조건을 분리했다.
이 단계에서 내가 한 역할은
무엇을 만들지 결정하는 것이 아니라,
이 상태로 다음 단계를 밟아도 되는지를 판단하는 것이었다.
4. 트러블 슈팅: 내 컴퓨터는 Java 21, 프로젝트는 Java 17?
로컬 환경은 기본적으로 JDK 21을 사용 중이었고,
프로젝트는 JDK 17을 기준으로 잡는 편이 합리적이었다.
문제는 간단했다.
시스템 전체를 낮출 것인가, 프로젝트에만 적용할 것인가.
나는 두 번째를 선택했다.
이 프로젝트 하나 때문에 전체 환경을 건드리는 건
불필요한 영향 범위를 만들기 때문이다.
5. 파일들이 갖는 의미와 ‘아직 하지 않은 것’
이번 단계에서 수정한 파일들은
기능 추가가 아니라 기준선 고정을 위한 작업이었다.
- settings.gradle.kts
- build.gradle.kts
- app/build.gradle.kts
- AndroidManifest.xml
- strings.xml / themes.xml
앱 이름과 패키지명은
앞으로 쌓일 모든 코드가 매달릴 좌표이기 때문에
가능한 한 빨리 확정하는 편이 낫다.
반면 google-services.json은 의도적으로 미뤘다.
이 파일은 Firebase 콘솔이라는 외부 선행조건이 필요하고,
지금 해결해도 Step 1의 완성도는 올라가지 않는다.
그래서 이 설정은
“지금 당장 할 일”이 아니라
외부 선행조건으로 분리해 두었다.
6. 정리: 코드는 쓰지 않았지만, 프로젝트는 시작되었다
오늘 30분 동안 기능은 만들지 않았다.
대신 기능 구현을 흔들 수 있는 조건들을 정리했다.
프로젝트는 아직 비어 있다.
하지만 이제는 시작할 수 있는 상태다.
이 시점에서의 판단은 단순했다.
더 준비할 필요는 없고,
이제 다음 단계를 시작해도 된다는 확신이었다.
💬 후기
이번 Step 1을 진행하면서 가장 놀랐던 건,
코드 자체를 한 줄도 직접 보지 않았다는 점이었다.
Codex와의 채팅만으로 프로젝트의 기본 틀이 완성됐다는 게
생각보다 크게 다가왔다.
아직 기능은 아무것도 없다.
그런데도 막막함보다는,
“이제 다음 단계로 가도 되겠다”는 감각이 먼저 들었다.
이 방식으로 어디까지 갈 수 있을지는 모르겠지만,
지금은 앞으로가 꽤 기대된다.
다음 글에서는
다음 글에서는 실제 구현 단계로 들어가며, 앱의 기본 구조와 네비게이션을 어떻게 잡을지를 다룬다.
기능을 붙이기 전에, 코드를 어디에 놓을지부터 결정해야 한다. 그 기준을 잡는 이야기로 이어갈 예정이다.
'AI 개발 기록' 카테고리의 다른 글
| [Taxi Driver App] 계산은 됐지만, 제품은 아니었다 – Part 5 (0) | 2026.06.26 |
|---|---|
| [Taxi Driver App] Step 2~4를 연속 수행하며 앱이 형태를 갖추기 시작한 순간 – Part 4 (1) | 2026.01.28 |
| [Taxi Driver App] 코딩은 AI가, 설계는 내가 한다 – Part 2 (0) | 2026.01.23 |
| [Taxi Driver App] 코딩은 AI가, 설계는 내가 한다 – Part 1.5 (0) | 2026.01.22 |
| [Taxi Driver App] 코딩은 AI가, 설계는 내가 한다 – Part 1 (0) | 2026.01.21 |