바이브 코딩 · 실전편 02

나흘, 직접 친 코드 0줄 —

실패하며 시작하는
바이브 코딩 실전편

중1 아들의 학습앱을 AI와 만든 나흘 — 판단과 실패의 전 기록

AI로 뭔가 만들어 보고 싶지만 "막상 하면 무슨 일이 벌어질지" 몰라 망설이는 비개발자를 위한 책입니다. 성공 장면이 아니라, 뒤집힌 판단과 깨진 화면을 그대로 보여 드립니다.

혹시 이런 상태 아니신가요

영상 속 시연은 늘 매끄럽죠.
내가 하면 어디서 막히는지는 아무도 안 보여 줘요.

AI가 코딩을 다 해 준다는데, 그래서 시작을 못 하고 계셨을 거예요. 막히면 무슨 일이 벌어지는지, 그때 뭘 해야 하는지 본 적이 없으니까요.

한 번 해 보신 분이라면 다른 벽을 아실 거예요.
AI가 "다 됐습니다"라고 하는데, 이걸 믿어도 되는 건지.
확인할 방법을 모르니 찜찜한 채로 넘어가고, 나중에 엉뚱한 데서 터지고요.

이 책이 나온 이유

그래서 프로젝트 하나를
처음부터 끝까지 기록하며 만들었습니다.

저는 코딩을 모르는 50대입니다. 지난 책 마지막 장에서 약속을 하나 했어요. 다음 책에서는 실패의 실제 사례를, 문제가 난 순간부터 검수 결과까지 다루겠다고. 이 책이 그 약속입니다.

만든 것은 중학교 1학년 아들이 쓰는 학습앱 셀프스터디(SelfStudy) — 교과서를 찍으면 암기카드를 만들어 주고, 수학 문제를 찍으면 답 대신 단계별 힌트를 주는 앱입니다.

7월 24일아침에 만들기 시작 — 그날 저녁 "계속 만들 가치가 있나"를 놓고 스스로와 논쟁

7월 25일밤 9시 58분, 앱이 인터넷에 섰다 — 그리고 두 번 깨졌다

7월 26일폰으로 써 보다 부서지는 것을 봤다 — 벽은 세 겹이었다

7월 27일고쳐서 다시 올렸다 — 마지막 결함들은 폰을 손에 쥔 30분이 찾았다

코드는 AI가 썼고, 저는 판단만 했습니다. 날짜·시각·수치·깨진 화면까지 전부 그 순간의 기록에서 옮겼습니다. 밤 9시 58분이라고 쓴 건 멋이 아니라 기록에 그렇게 남아 있어서예요.

읽고 나면 달라지는 것

"다 됐습니다" 앞에서
무엇을 확인할지 알게 됩니다.

읽기 전

AI의 "다 됐습니다"를 믿을지 말지 감으로 정합니다. 문제가 나면 어디부터 봐야 할지 몰라 "고쳐 줘"만 반복하고요.

읽고 나면

• 검사를 전부 통과한 코드에서도 결함이 나온다는 걸 알고, 무엇을 더 확인해야 하는지 압니다. 나흘간 교차 검수가 잡은 결함 스무 건이 전부 자동 검사를 통과한 코드에서 나왔거든요.

• "느린 것 같은데" 같은 막연한 불평을 측정으로 바꾸는 법을 압니다.

• 마지막 결함은 검사가 아니라 폰을 손에 쥔 30분이 찾았습니다. 기계 검증이 못 보는 층이 어디인지 알고 시작합니다.

장마다 실패 장면 하나와, 자기 프로젝트에 가져갈 기준 하나가 있습니다. 12개 장의 「독자의 기준」만 이어 읽어도 뼈대가 손에 들어옵니다.

구매하시면 받는 것

본문 한 권과 특전 둘,
그리고 실명 도구 목록.

본문 PDF

73쪽

나흘의 기록 12장. 문제가 난 그 순간의 실화면 수십 장 — 재연 촬영이 아니라 고치기 전 깨진 화면 그대로입니다. 되살릴 수 없어 다시 찍은 2장만 "재현"으로 표시했습니다.

구매자 특전 1

부록 원문집 PDF

44쪽

본문이 이야기라면 이쪽은 현장입니다. 요구사항 문서·구현 계약서·의사결정 기록, 대표 다섯 편의 원문 전문.

구매자 특전 2

나흘 기록 자료집

전체

개발 일지 27편, 요구사항 문서 16편 등 나흘 기록 전체를 원문으로 제공합니다.

부록 · 실명 도구 목록

수록

본문에서는 흐름을 위해 일반 명사로 부른 도구들의 실제 이름을 표로 정리했습니다. 따라 해 보실 분은 여기서 시작하면 됩니다.

이렇게 쓰시면 됩니다

읽고, 옮겨 적고, 견본으로 씁니다.

1. 하루 단위로 따라 읽습니다. 첫째 날부터 넷째 날까지 — 판단이 뒤집히는 과정이라 소설처럼 읽힙니다.

2. 각 장 끝의 「독자의 기준」을 내 프로젝트의 말로 한 줄씩 옮겨 적습니다.

3. 내 프로젝트를 시작할 때 특전 원문집의 요구사항 문서와 계약서를 견본 삼아 첫 문서를 씁니다.

자주 묻는 질문

망설여지는 부분, 먼저 답해 둘게요.

코딩을 전혀 모르는데 읽을 수 있나요?

저자가 코딩을 모릅니다. 나흘 동안 코드를 한 줄도 직접 치지 않았고, 책에도 코드가 나오지 않습니다. 이 책이 다루는 건 코드가 아니라 판단 — 무엇을 만들지 정하고, 나온 것을 확인하고, 틀린 방향을 되돌리는 일입니다.

이 책대로 하면 저도 같은 앱을 만들 수 있나요?

버튼 순서를 알려 주는 매뉴얼은 아닙니다. 대신 어떤 프로젝트에든 가져갈 수 있는 기준을 드리고, 실제 사용한 도구 전체를 부록에 실명으로 정리해 두었습니다. 시작점은 충분히 얻어 가실 거예요.

앞선 책(입문편)을 안 읽었는데 괜찮나요?

괜찮습니다. 이 책만으로 읽히도록 썼습니다. 입문편이 "실패 앞에서 생각을 바꾸는 법"이라면, 실전편은 그 생각이 실제 프로젝트에서 어떻게 쓰이는지입니다.

내용이 금방 낡지 않나요?

특정 도구의 화면과 메뉴는 바뀝니다. 그래서 이 책은 도구 사용법 대신, 도구가 바뀌어도 남는 판단 기준을 다룹니다. 기재된 기술 정보의 기준 시점(2026년 7월)은 판권에 명시했습니다.

만든 사람의 말

솔직히 말씀드리면, 나흘 동안 장치를 네 겹 쳤는데도 실패했습니다. 요구사항 문서를 먼저 쓰고, AI 둘로 교차 검수하고, 느낌 대신 측정하고, 순간마다 기록했는데도 — 결함은 장치 바깥에서 나왔어요.

그런데 저는 그게 이 책에서 가장 값진 대목이라고 생각합니다. 준비해도 실패한다는 것. 그래서 실패를 없애는 게 아니라 싸게 만드는 게 목표라는 것. 이건 성공담 백 편보다 실패 기록 한 편이 더 정확하게 가르쳐 줍니다.

이 책을 덮을 때 "나도 저 정도 실패는 감당할 수 있겠는데"라는 생각이 들었으면 합니다. 그게 시작의 전부거든요.

— 다시씀

다음에 AI가 "다 됐습니다"라고 말할 때,
여러분은 뭘 확인해야 하는지 알고 있을 거예요.

쉰이 넘은 비개발자가 나흘 만에 아들의 앱을 인터넷에 올렸습니다. 실패하면서요.
여러분의 나흘은 언제 시작하나요?

F A I L U R E - F I R S T   N O T E S