1D3Q 개발 일지 - Day N, 그리고 개발
Disclaimer:
이 시리즈는 제가 서비스 "1D3Q"를 개발하면서 생긴 일들과 든 생각들, 그리고 느낀 점들과 통찰들을 적어가는 일종의 일기이며, 작업 일지입니다. 편하게 일기 쓰듯 끄적이는 글이므로, 가독성이 떨어지는 지점들과 비문이 상당수 있을 수 있습니다. 이미지 출처는 이미지 클릭 시 이동합니다.
Disclaimer 2: GPT-5가 나오기 전의 이야기입니다. Claude Opus, Sonnet 4로 작업한 결과물임을 양지해주시길 바랍니다.
이전글: 2025.07.30 - [개발일기/1D3Q] - 1D3Q 개발 일지 - Day 2, Gemesis와 열띤 토론
# 그리고 개발
몇 날 며칠을 Claude Code와 각종 MCP들을 붙여 최대한 바이브하게 개발을 진행해 봤다.
디자인도 해 주고, 레이아웃도 구성하고, 기능도 구현하고, 유닛 테스트와 e2e 테스트도 직접 만들도록 지시하며 일명 자동사냥을 꿈꿨으나, 꿈은 꿈이라 부르는 데 이유가 있다.
우선 결론부터 말하자면- 더 이상 이 방향으로의 진행은 어려울 듯 하다.
Supabase MCP로 데이터베이스는 어느 정도 잡혔으나, Clerk 연결이 죽었다 깨어나도 안 되는 모습을 보였다.
Google OAuth를 이용해 회원가입 후 로그인해도 회원 대시보드로 이동하지 않고 랜딩 페이지로 리다이렉트시키는 문제가 해결되지 않았다. 서버에 세션 정보가 남지 않는 것인지, 로그인엔 성공했으나 서버에서 발행한 세션이 Unauthorized 취급을 받는 것인지 에이전트가 판단하질 못 했다.
이대로는 더 진도를 나갈 수가 없다고 판단, Clerk 관련 부분은 직접 작성하기로 했다.
그런데 공식 Docs대로 진행해도 여전히 로그인이 정상적으로 작동하지 않았다.
방치된 소스코드는 유선 이어폰과 같아서, 나도 모르는 사이에 꼬여 어디서부터 풀어야 할지 막막해진다.
이왕 이렇게 된 것, 이 시점에서 진행 상황을 복기해봤다.
# 복기
- 대강 페이지는 깔끔하게 나온다. 하지만 페이지 내 입력을 받는 부분들에 자잘한 버그들도 적지 않다.
- AI가 한 디자인임이 티가 좀 난다. AI로 웹페이지를 만들어 본 사람이라면 알아챌 수 있는 수준이다.
이는 UI/UX를 더 고려하라고 하거나, 좋은 레퍼런스를 더 투입했으면 나아질 것 같다. - 기능 구현보다 지엽적인 부분에서 너무 많은 최적화를 시도한다. 빠른 기능구현이 가장 중요한 프로토타입 개발에선 독이 된다.
이후 클로드 메모리에 기능구현을 우선하란 내용을 추가해 어느 정도 해결했으나, Zen thinkdeep을 이용한 태스크 설계에서 특히 이런 모습이 많이 나타났다. sequential-thinking 수준에서 먼저 플랜을 짜고, Plan Mode로 계획을 받은 뒤 사용자가 더 깊은 사고를 요구할 지 결정한 뒤 재검토하는 방식이 더 나을 것으로 보인다. - 사용 가능한 MCP Tools를 자주 잊어버리는 모습을 보인다. 이는 복잡한 작업을 진행하며 Context 크기가 너무 커져 발생한 성능 하락의 여파로 보인다.
- 실패한 Test를 성공했다고 말하는 일이 점점 잦아진다.
- 종종 사전 지시한 PRD 등 지시 문서를 어기거나, 프롬프트에 작성한 방법을 그대로 수행하지 못한다. 이는 매 세션 시작마다 Serena로 가져오는 프로젝트 메모리 + 현재 작업 지시 내용 + 코드 작성 가이드라인 + 관련 기능 PRD 등 많은 내용을 가져오다 보니 같은 맥락으로의 Context 크기 문제로 보인다.
- 끊임없이 작업하는 경우 약 90분이면 주어지는 토큰을 전부 소진해 Usage limit에 걸린다. 5시간마다 1시간 반 내외의 작업을 반복하는 것이 썩 유쾌하진 않았다. 이건 이전에 언급한 Context 낭비 문제도 있고, Max Plan으로 변경하는 것도 해결 방법이겠다.
이렇게 복기 내용을 정리하고 보니, 지금의 방임형 바이브 코딩은 '적어도 아직은' 시기상조로 보인다.
거기에 앞으로는 AI를 Pair Programming에 활용하는 것이 확실히 더 좋다는 생각도 함께 들었다.
이번 프로젝트 아닌 프로젝트를 진행하며 느끼고 배운 것들을 정리해보았다.
# 정리
- PRD는 최대한 작게, 많이 만드는 것이 좋아 보인다. 이는 문서의 양을 늘리는 것이 목적이 아니라, 현재 태스크와 무관한 내용까지 함께 세션에 들어가 컨텍스트 메모리를 낭비하지 않는 것이 목적이다.
- 한 세션에선 하나의 기능만 다루고, 주기적으로 세션을 초기화(`/clear`, 새 채팅 시작과 동일)하는 것이 도움이 된다.
- Vibe하게 요청하면 Vibe한 기능이 나온다. 기능이 동작하질 않고 느낌만 난다. 요청 사항의 구체화를 모델에게도 맡기되, 마음에 들 때까지 계속 검토하면서 수정해야 한다. 이는 구현 단계뿐만 아니라, 기획 및 PRD 작성 등 모든 페이즈에 적용된다.
- 테스트 결과를 거짓말하는 경우, 로깅을 위한 포인트를 제대로 잡았는지 검토하고 왜 실패한 테스트를 성공이라고 평가했는지 이유를 물어보는 것도 도움이 된다. 테스트 플로우나 대상이 내가 기대한 것과 다를 수 있다.
- MCP를 무수히 많이 붙인다고 성능이 올라가지 않는다. 오히려 당장 불필요한 Tool까지 호출해 컨텍스트 윈도우와 토큰을 낭비해, 전체적인 성능 하락과 사용량 낭비가 발생할 수 있다.
- 각종 프롬프팅 기법과 여러 바이브 코딩 팁이 만능은 아니다. 체감상 가장 좋은 퍼포먼스는 '작고 명확한 태스크'에서 나온다.
- 형상관리의 중요성은 바이브 코딩에서 더 중요하다. AI가 작성한 코드를 언제든 revert할 수 있게 체크포인트로 사용 가능한 브랜치와 커밋을 찍어두는 것이 좋다. 기존 브랜치에서 계속 작업하는 것보다 완전 정상 작동함이 확인된 것들을 상위 브랜치에 머지해가며 작업하는 것이 훨씬 안정적이다. 여기에 Gemini Code Assistant의 자동 PR 코드 리뷰도 꽤 도움이 된다.
지금 수준에서 Vibe coding을 원한다면, v0.app(구 v0.dev)이나 lovable에서 만들 수 있는 수준이라면 여기에서 먼저 만들고, 이후 AI와 함께 페어로 기능을 수정하고 사람이 보기 편하게 리팩토링하는 것이 빠르고 쉬운 방법이지 않을까.
너무 오래 끌어오기도 했고, 아이디어에 대한 열정이 식은 것도 사실이다. 다음에 새로 무언가를 만든다면 nextjs로 하던가, 그 전에 AI 어시스트 없이 rails로 게시판 같은거라도 만들어봐야겠다.
생각보다 용두사미 형식으로 끝난 것 같다. 뱀의 꼬리같은 결과물이 나왔지만 그 과정에서 용이 되어보고자 이리저리 비틀어본 이무기의 마음은 어딘가에는 남지 않았을까 싶다.