하루 만에 만든 것처럼 보이는 제품의 진짜 개발 시간
가끔 “이걸 하루 만에 만들었다”고 말하면 다들 놀란다.
사실 틀린 말은 아니다. 실제로 코드를 집중해서 쓴 시간은 하루였다.
하지만 그 말만으로는 이 제품이 만들어진 과정을 설명하기엔 많이 부족하다.
이 아이디어는 사실 한 달 전부터 내 메모장에 있었다.
메모장에 적혀 있다는 건, 나에게는 단순한 아이디어 이상의 의미다.
한 번 떠올랐다가 사라지는 생각이 아니라, 시간이 지나도 계속 맥락을 유지하는 생각이라는 뜻이다.
나는 이런 메모를 ‘아이디어 노트’라기보다는 개발 대기열에 가깝게 취급한다.
그 한 달 동안 나는 코드를 거의 쓰지 않았다.
대신 계속 구조를 생각했다.
이건 어떤 레이어로 나뉘어야 하는지, 무엇은 자동화해도 되고 무엇은 사람 손에 남겨야 하는지,
엔드포인트와 권한은 어디까지 분리해야 안전한지 같은 것들이다.
특히 AI를 쓰기 시작하면서 이 질문들은 더 중요해졌다.
AI는 똑똑하지만, 맥락이 엉키면 빠르게 무너진다.
그래서 나는 하나의 앱에 모든 걸 엮지 않으려고 한다.
좌우, 상하, 기능, 책임, 시간 흐름까지 전부 나누는 편이다.
코드는 논리이기 전에 공간이고, 잘못된 공간 설계는 반드시 복잡도를 만든다.
본격적인 설계에 들어간 건 약 7일 정도였다.
이 기간 동안 가장 중요했던 건, 설계를 프롬프트로 주지 않았다는 점이다.
프롬프트는 대화고, 대화는 사라진다.
그래서 설계는 반드시 MD 파일로 만들었다.
AI가 작업을 시작할 때마다 읽어야 하는 기준, 일종의 도면 같은 것이다.
이 설계도에는 레이어 구조, 금지 영역, 책임 분리, 자동 실행이 허용되는 구간과 그렇지 않은 구간이 모두 들어 있다.
이걸 한 번에 주지 않으면, AI는 빈칸을 자기 방식으로 채운다.
그 순간부터는 구현이 아니라 다시 설계를 고치는 일이 된다.
설계가 끝나고 나니 구현은 정말 하루면 충분했다.
그날은 고민이 거의 없었다.
결정을 내리는 날이 아니라, 이미 결정된 구조를 조립하는 날이었기 때문이다.
파일을 만들고, 코드를 배치하고, 연결하고, 테스트했다.
이 과정에서 AI는 굉장히 우직한 작업자처럼 움직였다.
물론 모든 게 항상 매끄러운 건 아니다.
맥락이 너무 복잡해지면 AI도 흔들린다.
그럴 땐 과감하게 세션을 끊고 다시 시작한다.
그래도 이해가 안 되는 구조가 나오면, 최후의 수단으로 무한 반복 탐색을 돌린다.
사람에게는 불가능한 방식이지만, AI에게는 가능한 방식이다.
그래서 “하루 만에 만들었다”는 말은 이렇게 정리하는 게 더 정확하다.
한 달 동안 생각했고,
7일 동안 설계했고,
하루 동안 구현했다.
그리고 그 하루를 가능하게 만든 건, 사실 그 이전의 시간이었다.
이 방식의 가장 큰 장점은 속도가 아니다.
재현성이다.
설계도만 남아 있으면, 언어가 바뀌어도, 프레임워크가 바뀌어도, 사용하는 AI가 바뀌어도
다시 하루 만에 같은 구조를 만들 수 있다.
요즘은 “AI로 빠르게 개발한다”는 말이 흔해졌다.
하지만 내가 느끼는 핵심은 조금 다르다.
AI는 생각을 대신해주지 않는다.
다만, 목표와 구조가 명확할 때는 정말 성실하게 구현해준다.
그래서 나는 이렇게 말하고 싶다.
나는 하루 만에 만든 게 아니라, 충분히 생각한 것을 하루에 구현했을 뿐이다.