배경
조직을 나와서 하고 싶었던 것 중 하나인 Fully AI Driven Development(AIDD)를 해보고 있다. Agentic Workflow라고도 하던데, 문제 정의부터 제품의 출시까지 필요한 일련의 사이클을 모두 AI가 수행하는 방법이다. 내 마음대로 붙인 거창한 이름이지만, 그냥 이전보다 더 격렬하게 AI에게 지시하여 제품을 출시하는 방법이라고 봐도 무방하다. 출시까지 도합 8시간 정도 걸렸던 작업 경험을 내 멋대로 공유해볼까 한다.
(참고로 현재는 제품 출시 후 계속 개선해 나가고 있다.)
PRD 작성 - 4시간
처음엔 PRD마저 AI가 모두 쓸 수 있게 간단한 아이디어, 배경 정도를 프롬프팅 해서 대화형 LLM에 질의했지만, 결과는 형편없었다. 시중에 나온 모든 최신 LLM을 가지고 결과물을 얻어봐도 마찬가지였다. 다들 교과서적인 리포트만 그럴듯하게 뱉는데, 영 마음에 들지 않았다. 그러다가 창의적이고 매력적인 결과물을 위해 프롬프트를 긴 시간 깎고 있는 나를 발견했는데, 가만히 보니 내가 깎고 있는 이 프롬프트가 PRD 그 자체라고 볼 수 있었다.
아직까진 프롬프팅이라는 인간의 영역이 존재하는데, 개발자로서 AI 시대의 최전선에서 이것저것 많이 써봐도, 어떤 것이 프롬프팅의 책임이고 어떤 것이 LLM의 책임인지 좀처럼 익숙해지지 않는다. 결과적으로 오랜 짬밥을 이용해서 간단한 1 Pager PRD를 직접 작성했다. 여기서 LLM(Perplexity)이 한 것은 고작 오탈자 수정 정도….
도구 선택 - 2시간
일단 vercel 위에 올라가는 nextjs를 올리는 옵션 말고 다른 것은 상상하지 않았다.
- 일단 가장 최근까지 만져본 스택이어서 내가 편하며
- 풀 스택을 지원해야 하고
- 이 서비스는 웹서비스이기에 SEO가 중요하기 때문이며
무엇보다 이미 많은 생태계가 갖춰진 도구여야 LLM이 알잘딱하게 움직일 수 있을 것이라는 경험적 추론이 있었기 때문이다. 기반이 되는 도구를 선택하면 그것을 돕는 여러 부차적인 도구는 자동적으로 결정될 것이라 생각했다.
옛부터 기술 스택이란것은, 가장 연동이 잘되고 친한애들끼리 모여서 권장되고 회자되어 발전해왔다. 아니나 다를까, vercel 위에 올라가는 nextjs를 결정하니 스타일 관련 기술스택은 shadcn과 tailwind 말곤 더 좋은 대안이 없었다. 이 모든 것을 딸깍으로 운영환경까지 만들어주는 도구가 없나 LLM에 물어보니, 놀랍게도 여러 가지가 있었는데 Replit, Lovable, v0 정도로 대안이 좁혀졌다.
세 가지 다 내가 원하는 서비스를 원하는 기술스택으로 딸깍해서 만들어주기에 무리가 없었다. 여러 특장점을 고민해 본 결과 vercel 생태계라는 점과 무료 크레딧이 제일 많다는 점에서 결과적으로 v0를 선택했다.
곧장 v0 계정을 만들고 무료 크레딧을 소진하여, 좀전에 만든 PRD와 원하는 기술스택을 적절히 정리해서 입력 후 이것을 만들어달라고 했더니, 그토록 원했던 PRD 입력 -> 딸깍 -> 서비스 출시를 실현시켜줄 수 있는 놀라운 도구라는 확신이 바로 듬과 동시에, 십수년 개발하면서 쌓아온 나의 효용가치가 빠르게 무너지는 급격한 현타를 느낄 수 있었다.
개발 환경 설정 - 1시간
v0가 뽑아준 결과물은 PRD 초안 그대로 작성된 프로토타입 수준의 제품이었다. 이것도 감지덕지 했지만 군데군데 더 만져줘야하고 깎아야할 부분이 많아보였다. v0의 결과물은 자동으로 vercel에 배포되고 소스코드 또한 github에 생성해준다. 이런 환경에서 로컬에 개발환경을 만드는것은 나에게 식은 죽을 먹는것보다 쉬웠다. 이후 Cursor에게 모든것을 지시하여 MVP 출시를 위한 바이브코딩을 진행했다.
- 카피 및 타이포 수정
- 랜딩 페이지의 섹션 재배치
- 라우트 구조 개선
- 서비스의 콘텐츠를 지속적으로 추가, 확장할 수 있기 위한 리팩토링
- 이 모든것에 대한 커서룰 작성
바이브코딩한 작업들을 나열해보니 거창해보이지만, 손수 PRD를 작성하는 이전의 노력에 비하면 절반도 안되는 분량이었다. 개인적으로 바이브코딩을 잘 하려면 문제 해결을위해 무엇을 어떤 순서로 해야할지 알아야하고 그 무엇들을 어떻게 부르고 명명하는지 알면된다고 생각한다. 말처럼 쉽지는 않겠지만 이건 엔지니어링을 많이할수록 유리하다고 보기 때문에, 바이브코딩 역시 기존 개발자들이 많이 앞서있다고 생각한다.
출시 - 1시간
로컬에서 진행한 작업들을 모두 커밋 & 푸시하니 얼추 제품을 출시할 준비가 되었다. 출시를 위해선 도메인이 있어야하니 제일싼걸로 가비아에서 하나 감아왔다.
- 그 도메인은 이름하여 https://koopon.kr
이를 vercel 네임서버로 이전해주니 출시가 비로소 끝이 났다. 작업시간을 모두 합쳐보니 도합 8시간만에 제품을 성공적으로 출시한 셈이다.
고도화
배포는 금방이지만 유지보수는 영원하다 했던가, 출시 이후 백로그를 나열해보니 해야할 작업이 산더미였다. 경쟁 서비스를 보니 이미 갖춰놓은것이 많아 최소한 그정도는 도달해야 원했던 트래픽이 만들어질 수 있다고 생각했다. 맨날 들여다보진 않지만 여느 서비스처럼 기능을 추가하고 디버깅을 하다보면 많이 작업하는 날엔 하루 60건의 커밋을한다. 물론 Cursor가 다하지만..
마무리
- "포기하지 않고 계속 제품을 깎다 보면 어느새 경쟁 서비스를 이기고 반열에 오를 수 있겠지"라는 희망을 품으며 지금도 제품을 깎고 있다. 이 프로젝트에 대하여 도통 결과를 알 수 없기에 헛수고하는 것은 아닌지 고민이 되면서도, 얼마 전 퇴사를 했기에 누릴 수 있는 자유라고도 생각하고 있다. 확실한 건 이런 잉여로운 시기는 내 인생에 좀처럼 생기지 않았기 때문에, 해보고 싶은 것 다 해보고 이 시기를 마무리해야겠다.
- 이 과정에서 시중에 유행하는 LLM들을 다 써보고 드는 생각은, 적어도 제품 관점에서 Claude Opus 4.5 보다 Gemini Antigravity가 더 좋네 마느니 하는 이야기들은 Java가 Python 보다 좋네 마네하는하는 것만큼 무용하다고 생각한다. 도구에만 집착하다간 본질과 가치를 놓치기 마련이며 이런 논의에 집착하는 것은 문제를 해결하고 가치를 만드는데 잡음에 가깝다고 생각한다.
백링크를 얻기위해 조심스레 만든 제품을 공개해본다. 😇 https://koopon.kr [쿠우폰]
의견을 남겨주세요