요약

한 개발자가 자신의 강아지를 추적하는 Dog Tracker 앱을 AI 와 바이브 코딩으로 만들기 시작했다가 결국 프로젝트를 폐기하고 처음부터 다시 시작했더니 1 시간 만에 완성한 회복 사례. 첫 번째 시도에서 개발자는 작업 도중에 "이 기능도 추가해 주세요", "이건 빼주세요" 같은 요구사항을 수시로 추가·변경 했고, 이를 받은 AI 는 매번 그때그때의 요구를 충족시키기 위해 기술 스택 (사용 라이브러리·프레임워크) 자체를 중간에 바꾸고, 기존에 박은 데이터 구조와 화면 (뷰) 을 동기화하기를 점점 포기 하기 시작했다. 결국 코드는 누덕누덕 덧붙여진 형태가 되었고, 어느 단계부터는 수정할 때마다 다른 부분이 깨지는 concept/context-rot 의 전형이 되어 개발자는 프로젝트 자체를 폐기 했다. 두 번째 시도는 달랐다. 개발자는 처음부터 concept/spec-driven-development 의 4 단계 (헌장 → 명세 → 계획 → 작업) 를 거치고, 모든 요구사항을 시작 전에 한 번에 명세서로 박은 뒤 AI 에 작업을 시켰다. 결과는 — 단 1 시간 만에 같은 앱이 완성 되었다. 본 사례의 핵심 교훈은 단순하다 — "가장 빠른 코딩은 명확한 설계에서 시작된다". 설계에 들이는 30 분이 수 시간의 누덕누덕 덧붙임 을 차단한다.

상세

1차 시도 (실패)

• 패턴: term/requirements-drift (요구사항 표류) + term/code-bloat (코드 부풀리기)
• 진행:
  1. 개발자가 요구사항 수시 변경
  2. AI 가 기술 스택을 중간에 바꿈
  3. 데이터-뷰 레이어 동기화 포기
• 결과: 프로젝트 폐기

2차 시도 (재시작, 성공)

• 방식: 설계 우선 — 마크다운 명세 + 일관된 스택 결정 후 시작
• 결과: 1시간 만에 성공

핵심 인용

"가장 빠른 코딩은 명확한 설계 에서 시작된다."

강의 활용

02 VBC lesson/vbc-failures-and-causes 대조 사례 로:

• 메시지 시퀀스:
  1. "같은 사람이 같은 앱을 두 번 만들었습니다."
  2. "첫 번째: 폐기. 두 번째: 1시간."
  3. "차이는 설계 입니다."
  4. "가장 빠른 코딩은 명확한 설계에서 시작됩니다."
• 다른 사고 사례 (DB 삭제·토큰 유출) 와 다르게 희망 메시지 제공 — 설계가 있을 때 무엇이 가능한가.

주의사항

• 숫자 대비: 폐기 vs 1시간 — 강력한 대조. 슬라이드에 시각화.
• 요구사항 변경이 죄가 아님: 변경 자체가 문제가 아니라 변경을 흡수할 설계가 없을 때 가 문제. 강의에서 짧게 부연.
• 희망 사례의 위치: 다른 사고 6건이 끝난 후 본 사례를 배치 — 공포 → 희망 흐름.
• 출처 정직성: getautonoma.com 1차. 세부 시간(정확히 1시간) 은 대략적 보고 정도로 표기.
• case/crossbeam-hackathon-win 과의 묶음: 두 사례가 설계가 있을 때 무엇이 가능한가 의 작은 버전·큰 버전.