[Taxi Driver App] Step 2~4를 연속 수행하며 앱이 형태를 갖추기 시작한 순간 – Part 4

이 글은 기능 구현 과정을 설명하지 않는다.
Codex가 제안한 개발 단계를 그대로 실행했을 때,
프로젝트의 상태가 어떻게 변했는지를 기록한다.

---

Step 2. App shell and navigation

09:40 ~ 09:45

Codex에게 던진 질문은 단순했다.

“Step 2를 진행하자”

그 한 문장 이후, 아래 파일들이 생성되거나 구성되었다.

• MainActivity.kt
• AppNavGraph.kt
• Routes.kt
• AppStartScreen.kt
• MainScreen.kt
• Theme.kt

이 단계에서 개별 파일의 구현 방식은 확인하지 않았다.
내가 확인하고 싶었던 것은 단 하나였다.
“앱이 실행 가능한 형태가 되었는가”였다.

그래서 Codex에게 검증 방법을 다시 물었다.
Codex는 다음과 같은 확인 절차를 제시했다.

• gradlew installDebug
• 에뮬레이터에서 앱 실행
• AppStart 화면에 “택시노트” 표시 여부
• “시작하기” 클릭 시 Login(placeholder) 이동 여부
• Main 화면 버튼 → 각 placeholder 이동 여부
• 뒤로가기 정상 동작 여부

이 항목들을 순서대로 확인했다.
모든 동작은 정상적이었다.

Step 2 이후, 앱이 실행 가능한 골격 다이어그램

이 시점의 체감은 분명했다.

“앱의 골격이 5분 만에 생겼다.”

여기서 말하는 골격은
UI가 아니라 흐름과 이동이 존재하는 상태였다.

---

Step 3. Core data models and repository interfaces

09:45 ~ 09:52

이어서 Codex에게 다시 요청했다.

“Step 3 진행”

이번에도 추가 설명은 없었다.
질문 하나로 아래 파일들이 생성되었다.

• User.kt
• SalarySetting.kt
• DailySales.kt
• Toilet.kt
• Comment.kt
• AuthRepository.kt (interface)
• FirestoreRepository.kt (interface)

Codex가 제시한 검증 방법은 두 가지였다.

• 파일 존재 여부 확인
• gradlew assembleDebug 빌드 성공 여부

파일은 모두 존재했다.
빌드는 내가 직접 실행하지 않았다.

Codex는
“빌드가 정상적으로 완료되었다”고 응답했고,
나는 그 상태를 받아들인 채 다음 단계로 넘어갔다.

이 시점의 체감은 Step 2와는 달랐다.

• 지금까지는 된 건지 안 된 건지 감각적으로 잘 와닿지 않는다
• 실제 개발이었다면 이 작업에 얼마나 걸렸을지 가늠하기 어렵다

직접 설계하고 구현했다면
오전 내내, 길게는 하루는 걸렸을 데이터 모델과 인터페이스 구조가
이 단계에서는 한 번에 정리된 셈이다.

눈에 보이는 변화는 거의 없었지만,
프로젝트 내부에는 구조가 쌓이고 있다는 느낌만이 남아 있었다.

---

Step 4. Authentication flow and userId contract

09:55 ~ (종료 시간 기록 중단)

다시 Codex에게 말했다.

“Step 4 진행”

이번 단계에서 완료된 항목은 다음과 같다.

• LoginScreen.kt
• SignUpScreen.kt
• AuthViewModel.kt (userId 계약 고정)
• AuthRepositoryImpl.kt

Codex가 제시한 검증 흐름은 비교적 명확했다.

• 앱 실행 → AppStart 이후 Login 자동 이동
• 회원가입 시도 → Main 이동
• 앱 재실행 → 로그인 유지 확인

이 흐름을 따라가던 중,
회원가입 시도 과정에서 에러가 발생했다.

에러 메시지는 다음과 같았다.

An internal error has occurred [CONFIGURATION_NOT_FOUND]

이 시점에서부터
이 프로젝트는 “단계 실행”이 아니라
디버깅이라는 개발 본연의 시간으로 넘어간다는 감각이 분명해졌다.

Step 4에서 처음으로 마주한 실제 런타임 에러

이때 하나의 판단이 섰다.

• 이제부터는 “몇 분 만에 끝났다”는 시간 기록이
  더 이상 큰 의미를 갖지 않겠다는 인식
• 디자인 수정, 기능 오류, 예외 처리 등
  사람이 개입해야 할 구간에 진입했다는 감각

그래서 Step 4부터는
종료 시간을 기록하지 않기로 했다.

---

❗ 후기

코드를 거의 보지 않고도
이 지점까지 왔다는 사실은 분명히 인상적이다.

하지만 동시에,
지금부터는 사람이 개입하지 않으면
앞으로 나아가기 어렵겠다는 감각도 함께 생겼다.

속도는 압축되었고,
그만큼 불확실성도 빠르게 드러나기 시작했다.

---

요약
- Step 2~4는 질문 몇 개로 연속 수행되었다
- 앱은 실행 가능한 형태를 갖추기 시작했다
- Step 4부터는 사람이 판단해야 할 지점이 명확해졌다

---

다음 글 예고

Step 5부터는
속도보다 판단의 비중이 더 커질 것이다.

다음 글에서는
사람이 실제로 개입하기 시작한 지점,
그리고 그 개입이 왜 필요했는지를 다룬다.

Step 5부터는 속도보다 판단이 중요해지는 구간

[Taxi Driver App] – Part 5로 이어집니다.