코딩을 배우지 않고 11일 만에 앱을 만들었습니다. 저를 멈춰 세운 건 코딩이 아니었습니다
11일 동안 74커밋, 혼자서 앱을 만들었습니다. 코딩 학습 비용은 0으로 가도 됩니다. 그러나 앱이 깨져 멈춰 선 다섯 번은 전부 코딩이 아니라 판단이었습니다. 배울 것이 없어진 게 아니라 바뀌었습니다.
코딩을 배우는 데 쓸 시간과 돈은, 이제 AI 툴에 쓰는 편이 낫습니다. 요즘 자주 나오는 말이고, 저도 같은 생각입니다. 직접 해봤기 때문입니다.
다만 이 말은 절반만 맞습니다. 나머지 절반이 이 글의 전부입니다.
먼저 숫자부터
지난 11일 동안 러닝 레이스 플래닝 앱을 만들었습니다. 정확히는 10일 18시간입니다. GPX 코스 파일을 올리면 구간별 페이스와 보급 타임라인을 계산해 주는 앱입니다. 혼자 만들었고, 브랜치를 전부 합친 커밋이 74개입니다. 병합 커밋 13개를 빼면 실제 작업은 61개입니다.
기록은 이렇습니다.
| 시각 | 커밋 |
|---|---|
| 07-06 23:42 | chore: init raceplanner repo |
| 07-09 09:42 | feat(mobile): W2 core loop (GPX 업로드에서 페이스 표·보급 타임라인까지) |
| 07-09 11:51 | feat(mobile): W3 backend integrated onto W2 core loop |
빈 폴더에서 동작하는 코어 루프까지 2일 반이 걸렸습니다. 그로부터 두 시간 뒤에는 로그인과 저장이 붙었습니다. 일주일 안에 커머스 카드와 한국어·영어 전환까지 들어갔습니다.

2일 반이 만든 결과물이 이겁니다. GPX를 읽어 코스를 자르고, 오르막과 내리막을 보정해 1km 단위로 페이스를 계산합니다.

과장이 아니라 오히려 보수적인 숫자입니다.
미리 밝혀 두겠습니다. 저는 시러큐스 대학에서 창업(Entrepreneurship)을 전공했고, IT 컨설팅을 4년, IT 스타트업에서 4년 가까이 근무했습니다. 이력만 보면 코딩을 알고 있는 사람 같을지도 모릅니다.
그런데 저 중에 코드를 짜는 일은 하나도 없었습니다. IT 컨설팅은 전략을 그리는 일이었고, 스타트업에서 제가 한 일은 영업과 운영이었습니다. 코딩을 시도해 본 적은 있습니다. 그러나 저는 프로그래밍을 할 줄 모릅니다. 지금도 모릅니다.
오해가 없도록 이 앱을 만든 방식을 그대로 말씀드리겠습니다. 저는 한국어로 지시했고, 코드는 클로드가 썼습니다. 저는 한 줄도 직접 쓰지 않았습니다. 74개 커밋 안에 제 손으로 타이핑한 코드는 없습니다. 제가 할 줄 아는 건 바이브코딩뿐입니다.
다만 그거라도 놀면서 익힌 건 아닙니다. 프로그래밍 대신 AI 툴과 바이브코딩을 공부해 왔습니다. KAIST에서 CAIO(Chief AI Officer) 과정을 마쳤고, 거기서 AI 제품을 PM으로 직접 만들어 기수 우수상을 받았습니다. 코드를 짜는 법이 아니라 AI로 무엇을 만들지 정하는 법을 배운 셈입니다.
이 구분이 이 글의 전부입니다.
그러니 질문은 자연스럽습니다. 이제 코딩을 배울 필요가 없어지는 것 아닌가. 2~3년 뒤에 이 도구들이 더 빨라지고 쉬워진다면, 문법을 배우는 데 쓸 몇 백 시간은 그냥 낭비 아닌가.
저도 그렇게 생각했습니다. 그런데 11일치 기록을 다시 읽어 보니 이상한 게 보였습니다.
저를 멈춰 세운 다섯 번
커밋 74개 중 fix로 시작하는 것이 11개입니다. 그중 5개는 대회 정보를 모으는 크롤러와 문서 인식을 고친 것이라 빼고, 1개는 온보딩 화면의 문구와 시간 선택기를 다듬은 것이라 뺍니다. 앱이 실제로 깨져서 멈춰 선 건 다섯 번입니다. 커밋 메시지를 자르지 않고 그대로 옮기겠습니다. 원문에 있던 대시 하나만 이 글의 표기 규칙에 맞춰 쉼표로 바꿨고, 나머지는 손대지 않았습니다.
07-07 · fix(build): clear TS6 ignoreDeprecations carry + stale tsbuildinfo
빌드가 안 됐습니다. 원인은 제 코드가 아니라 설정 파일에 남아 있던 예전 버전의 잔재와, 지워지지 않은 캐시였습니다.
07-08 · fix(engine): align buildCourse distanceKm after coord filter + expand goldens
좌표를 걸러낸 뒤에 거리가 어긋났습니다. 화면은 멀쩡했습니다. 앱은 아무 불평도 하지 않았습니다. 이건 미리 만들어 둔 정답 테스트가 없었으면 영영 몰랐을 버그입니다. 42.195km를 달리는 사람에게 잘못된 페이스를 주는 앱이 될 뻔했습니다.
07-16 · fix(mobile): GPX read on SDK 54+ filesystem + open saved plans
잘 되던 파일 읽기가 어느 날 안 됐습니다. 제가 건드린 게 아니라 플랫폼이 API를 바꿨습니다.
07-17 · fix(engine): hybrid CP fueling, keep interval consumption + add CP restock
보급 지점을 코스의 급수대에 맞췄더니, 이번에는 급수대 사이에서 먹는 양이 사라졌습니다. 하나를 고치자 다른 하나가 틀어진 겁니다.
07-17 · fix(engine): fueling totals converge to target×hours + critic fixes
보급 총량이 목표치에 수렴하지 않았습니다. 코드는 잘 돌아갔습니다. 숫자가 틀렸을 뿐입니다. 커밋 메시지 끝의 critic fixes는 제가 찾은 게 아니라 따로 붙여 둔 검증자가 찾았다는 뜻입니다.
여기에 커밋으로 남지 않은 것도 있습니다. 웹뷰 모듈을 하나 추가했더니 앱이 켜지자마자 죽었습니다. 자바스크립트는 바뀌었는데 네이티브 바이너리에는 그 모듈이 없어서였습니다. 화면에는 알 수 없는 에러만 떴고, 진짜 원인은 터미널 로그 한 줄에 있었습니다. could not be found ... registered in the native binary. 이걸 읽고 “아, 새 네이티브 모듈이 붙었으니 다시 빌드해야 하는구나”까지 가는 데 시간이 걸렸습니다.
이 목록에서 문법 때문에 막힌 건 하나도 없습니다.
남아 있는 fix 커밋 열한 개 어디에도 문법 오류를 고친 것이 없습니다. 물론 커밋으로 남지 않은 시행착오까지 git이 기억하지는 않습니다. 그래도 저를 멈춰 세우고 기록에 남을 만큼 아팠던 것 중에 문법은 없었습니다. AI가 그건 완벽하게 합니다. 저를 멈춰 세운 건 전부 다른 종류였습니다. 도구가 거짓말하는 지점, 숫자가 틀리는 지점, 어제 되던 게 오늘 안 되는 이유, 그리고 에러 메시지가 가리키는 곳과 진짜 원인이 다른 순간입니다.
그래서 결론은 바뀌지 않습니다. 다만 정확해집니다
문법을 배우는 데 쓸 시간과 돈은 이제 AI 툴에 쓰는 게 맞습니다. 저는 이 판단을 유지합니다. 2~3년 뒤에는 더 그럴 겁니다.
배울 것이 없어진 게 아니라 바뀌었습니다.
AI는 코드를 씁니다. 그것도 아주 잘 씁니다. 그런데 AI는 자기가 쓴 코드가 틀렸다는 걸 알려주지 않습니다. 알려줄 수가 없습니다. 그건 아는 문제가 아니라 확인하는 문제이고, 확인은 아직 사람의 일입니다.
이 앱의 보급 화면 맨 아래에는 이런 문장이 있습니다.
국제 가이드라인(ISSN/IOC/ACSM) 기반입니다. 한국인 데이터는 아직 없어 개인 측정값으로 보정하세요.

AI는 저 문장을 쓰지 않았습니다. 제가 넣었습니다. AI는 요청받은 계산을 훌륭하게 해냈지만, 그 계산의 근거가 서양인 데이터라는 것과 그 사실을 사용자에게 알려야 한다는 것은 판단의 영역이었습니다. 자기가 무엇을 모르는지 아는 것, 그리고 그걸 숨기지 않기로 정하는 것 말입니다.
그러니 사야 할 것은 두 가지입니다. 하나는 AI 툴 비용이고, 다른 하나는 틀렸다는 걸 알아채는 능력입니다.
앞의 것은 카드로 살 수 있습니다. 이 앱을 만드는 11일 동안 제가 쓴 도구 비용은 클로드 구독료 월 200달러가 전부입니다. 도메인 값은 따로 냈고, 나머지는 전부 무료 티어로 해결했습니다. 사람은 쓰지 않았습니다.
뒤의 것은 카드로 사지 못합니다.
브랜드를 하시는 분들께
여기까지는 제 이야기였습니다. 이제 대표님 회사 이야기를 하겠습니다.
개발자를 뽑으신다면, 비싼 최고급 개발자를 뽑을 필요가 없습니다.
대신 이런 사람을 찾으십시오. 혼자서 프론트엔드도 백엔드도 기획도 QA도 할 줄 아는 사람입니다. 그리고 무엇보다 AI를 잘 써서 혼자 열 명 몫을 하는 사람입니다. 한 분야를 아주 깊게 파는 것보다 지금은 이런 사람이 필요합니다.
사내에서 시키신다면, AI를 잘 다루고 개발 도구를 한 번쯤 만져 본 사람에게 맡기십시오.
전공을 보지 마시고 손에 익은 도구를 보십시오. 깃허브, 클로드 코드 CLI, 버셀 정도를 한 번이라도 열어 본 적 있는 사람이면 충분합니다.
여기서 진짜 기준은 그 사람이 코드를 아는가가 아닙니다. 우리 일의 정답을 아는가입니다. 제가 보급 화면에 “한국인 데이터는 아직 없다”를 넣을 수 있었던 건 코딩을 알아서가 아닙니다. 제가 마라톤을 뛰고 스포츠 영양을 팔기 때문입니다. 그 문장은 코드에서 나오지 않고 현장에서 나옵니다.
무엇부터 만드느냐. 작은 것부터입니다.
회사 홈페이지를 외주에 맡기지 마시고 직접 만들어 보십시오. 그러면 유지보수와 수정을 우리가 합니다. 문구 하나 바꾸려고 메일을 쓰고 견적을 받고 2주를 기다리는 일이 사라집니다. 이게 생각보다 큽니다.
말리고 싶은 것도 있습니다.
디자인이 중심인 서비스는 아직 권하지 않습니다. AI는 화려한 디자인을 아직 잘 못합니다. 돌아가는 것과 아름다운 것은 다른 문제이고, 지금 도구들이 잘하는 쪽은 앞의 것입니다. 브랜드의 얼굴이 곧 제품인 서비스라면 아직 사람이 필요합니다.
정리
11일, 74개 커밋, 혼자. 이건 사실입니다. 코딩을 배우는 데 쓸 돈은 AI 툴에 쓰는 게 낫다는 것도 사실입니다.
다만 그 11일 동안 저를 멈춰 세운 다섯 번은 전부 문법이 아니라 판단이었습니다. 그리고 그 판단은 앞으로 도구가 아무리 좋아져도 제 몫으로 남을 겁니다. 도구가 좋아질수록 오히려 더 그럴 겁니다. 틀린 코드는 눈에 보이지만, 틀린 숫자는 조용하기 때문입니다.
앱은 아직 만드는 중입니다.