바이브 코딩으로 어디까지 개발할 수 있을까?

(github.com/delos-cresco)

36P by sungmin330 2일전 | ★ favorite | 댓글 6개

프로덕트 자체보다 기술 및 구현 사이드에서 느낀 점을 회고한 내용입니다.

완벽히 개인적인 생각입니다.

대학교 4학년 학기중에 배우면서 개발한 프로젝트임을 감안해서 봐 주세요!

왜 이 프로젝트를 시작하게 되었는가

스타트업을 차린다는 마인드로 프로덕트 개발. PM/PO 관점에서
Claude Code로 진짜 풀스택 MVP 개발이 가능한지 검토
주식 투자에서의 종목 발굴 문제를 해결
상용 프로덕트를 적극 도입해 그 과정에서 인사이트 도출

프로젝트 타임라인 및 추가 정보

기획+개발: 1달
배포: 1주
운영: 2달
투자 금액
- 클로드코드: 100USD
- 애플 개발자 계정: 100USD
- AWS: 약 220USD
- Managed DB: 약 300USD
- 프리티어: Datadog, Langfuse, Posthog
- 광고: 4만원
- 총합: 약 100만원(내돈..)

개발 과정

프론트엔드

디자인 토큰 정의
Figma로 핵심 페이지 3개 구현
Expo에 디자인 토큰 적용, Figma MCP 활용해 구현
Expo MCP 사용을 시도했지만 안정적이지 않아 직접 결과물을 보며 디버깅
“디자인 토큰을 사용하고, 다른 페이지의 디자인 컨셉을 차용해서…” 의 프롬프트로 Figma 와이어프레임 없이 신규 페이지 생성

백엔드

요구사항을 바탕으로 API 개발해 달라고 요청
프론트엔드 요구사항을 바탕으로 필요한 엔드포인트를 같이 만들어 달라고 요청
범용적인 스택 Django를 이용해 구현 자체에는 병목 없이 Claude Code로 개발 가능

AI

멀티 에이전트 아키텍처를 정의하고 이를 바탕으로 구현해 달라고 요청
최신 LangChain 및 LLMOps 스펙 대응을 위해 웹 링크를 첨부하여 참고하도록 함
LLM 서비스의 프롬프트를 LLM이 생성하여 활용

Observability

ClickStack 기반 구축 후 Datadog으로 마이그레이션
전체 시스템 개발 후 로깅 및 Analytics 적용

Infra

Pulumi를 초반에 사용하려고 했으나 Claude Code가 잘 못해서 AWS CLI 기반 스크립트 생성으로 배포파일 작성
비용 관계로 CI/CD 및 Dev Server 미 구축

도입 기술 리스트

서비스: 구독/결제, 소셜 로그인, 다크모드
데이터: API 기반 데이터 수집, CDC, ETL
AI: 멀티 에이전트, Text-to-SQL, Agentic RAG, SSE 스트리밍, 세션 관리, Retry, Rate Limit
LLMOps: AB Test, Cloud Based Prompt Management(OTA Update), Synthetic Dataset, Evaluation

인사이트

구현

약 1달간 클로드 코드 100USD플랜이 있으면 이정도 볼륨의 프로덕트를 혼자서 만들 수 있었다
디자인 토큰 규격만 정의해 UI를 구현했고, 만약 디자인 시스템까지 구현해 Claude.md에 녹였다면 더 빠르고 안정한 프론트엔드를 개발할 수 있을 것이다
디자인 시스템의 중요성. 프론트엔드 개발 생산성을 매우 향상시킨다. Figma를 만드는 것 보다 일단 구현하고 수정하는게 더 빠르다. 실제로 구현이 되어 있지만 Figma에 없는 페이지가 있다.
예외 케이스 정의. 모바일 앱과 AI 시스템에서 더욱 중요하다. 시스템 전반적인 Timeout 관리, Background 정책, 스트리밍 복구, 단순 에러 등 해피패스가 아닌 케이스에 대해 기획하고 구현해야 한다. Claude Code가 알아서 에러 처리를 구현하는 경우가 있지만, 프론트엔드와 백엔드 통합적으로 Nice하게 해결하지는 않는다. 따라서, 이런 부분에 대해 추가로 Claude Code에 요구하여 해결해야 한다.
대규모 리팩터링은 금지. 초기에 프론트엔드 파일 1개에 React, CSS 코드를 모두 넣었고 이를 분리하고자 리팩토링을 진행하였다. 결과적으로 실패했다. 분리가 되었지만 기존 UI와 달라진 형태를 가지게 되었고 결국 조금씩 분리하는 과정을 걸쳐야 했다. 개발 초기부터 코드 아키텍처에 대해 고민, 컴포넌트를 활용할 경우 관련된 내용을 프롬프트에 추가하여 잘 활용하도록 해야 할 것으로 보인다.
Claude.md를 활용. 기능 개발을 한 후, 그 내용을 바탕으로 Claude.md에 저장하면 좋을 내용을 추가해 달라고 Claude Code에 요청. 점점 파일이 커져 여기서 꼭 필요한 내용만 남기고 나머지는 제거해 달라고 요구. readme와 claude.md를 적절히 활용하어 LLM 컨텍스트 조절해 활용. (skills 없었던 시절)
서브에이전트는 활용하지 않음. 없어도 잘 만들어서 사용하지 않음. 단순히 Plan 모드로 개발 기획이 구체화 될 때 까지 요청하다 충분한 경우 Agent에게 자율로 개발하도록 함.
패키지 및 기술은 사전에 정의해서 알려주는게 좋다. Claude.md나 Readme나 특정 스펙을 정확히 명시해서 작업해야 중복된 코드를 만들지 않거나 다른 스택을 사용하는 상황을 방지(Skills?)

AI 시스템

ReAct는 느리다. UX가 꽝이다. 멀티에이전트를 병렬로 실행하도록 구성 하였음에도 너무 느리다.
UX. 느린 답변을 해결하기 위해 멀티에이전트 step을 보여주는 UX, 스트리밍, 애니메이션, 동적 마크다운 랜더링 등을 도입했다. 하지만 답변에 1분씩 걸린다면 무슨 의미가 있지?…(B2C 앱)
클라우드 기반 프롬프트 및 툴 스키마 관리. Online 환경에서 적용할 수 있다는 점이 좋다. 이제는 필수라고 생각하고 Langfuse 사랑해요.
Text-to-SQL에서 프롬프트에 스키마를 넣어야 한다. 이 때 컨텍스트를 너무 잡아 먹는다. fine-tuning혹은 RAG로 해결할 수 있을 것 같다.
평가와 Iteration. 유저 페르소나 별 Synthetic Dataset을 구성하고, LLM-as-a-Judge로 평가했다. 자동화 하고 싶지만 역시 혼자 하기에는 개발 리소스가 부족하다.
평가 메트릭과 루브릭: 생각보다 골치아프다. 범용 메트릭은 DAU와 MAU같은 거라고 생각한다. 이런 메트릭으로는 인사이트를 도출할 수 없다. 케이스 바이 케이스로 메트릭을 정의해서 저품질 사례를 구별하고, 이를 해결하며 Iteration이 필요하다. 결국 커스텀 메트릭을 잘 만들 수 있게 도와주는 시스템이 필요하다. (멀티턴은?..)
생각보다 타이트한 Open AI Tier. 저 티어에서 좋은 모델을 운영으로 사용하지 못한다.

인프라

AWS 비싸다, Managed DB 비싸다. 좋은데 후회된다
Clickhouse는 매우 비싼데 좋다. Managed를 사용하니 편하다. 특히 CDC까지 한번에. (빠르면 뭐해 LLM이 느린데)
Qdrant, Redis Cloud도 나쁘지 않다. 구축하는데 시간이 적게 들고, 비용도 싸다.
Datadog. 너무 좋다. 다만 비쌀 예정이라 프리티어만 사용했다. 특히 발생한 에러를 따로 모아서 알려주는 기능이 너무 좋다. ECS에 에이전트를 사이드카로 넣어서 사용하였다.

서비스

결제 및 구독. 토스페이 사용을 고민했지만 사용하지 않았다. 일단 연회비가 있어야 하고, React Native 문서가 없어서 SDK가 별로다. 실망이 크다. 결과적으로 나이스페이먼츠를 선택했다. 연회비가 없고 개발 서버도 있어 무난하게 개발할 수 있었다.
애플 결제. 나이스페이먼츠를 사용했지만 문제가 있다. 애플 결제 정책이 까다롭다. iOS개발 과정에서 애플의 정책 이슈가 있었고 다양한 문서와 UI적으로 해결이 필요하다. 그냥 애플 내부 결제 시스템을 활용하는 것이 맘 편할 것 같다.
결제와 구독(자동결제)는 다르다. 자동 결제를 구현하기 위해 스케줄링 인프라가 필요하고, 카드키를 저장하기 위한 보안에도 신경을 써야 한다. 결국 구현하긴 했지만 생각보다 까다롭다. Stripe를 사용해 보고 싶다는 생각이 들었다.
푸시알림. Expo에서 편하게 구축할 수 있다. 결국 백오피스가 있어야 메시지를 날릴 수 있지만, 필수적인 기능이라고 생각한다.

생각들

소프트웨어 디자인 패턴과 아키텍처에 대한 중요도가 높아질 것 같다.
코딩 에이전트로 토이 프로젝트를 넘어선 결과물을 만드는 것에 사람들의 관심이 높아지면 좋겠다.
오버스펙을 피하자. 하지만 취업하려면 오버스펙도 알아야 하는거 아닌가? 다음부턴 인스턴스 하나에 docker-compose로 끝내는게 좋을지도…(supabase로?)
1인 창업의 시대가 거의 왔다. 하지만 돈을 버는것과 만드는건 별개라고 생각한다.
혼자 하는건 재미없다
Linear도 Jira 대신 사용하기에 괜찮다. 사용이 처음이라 티켓 위계에 따라 모아서 보는 방법을 잘 모르겠다.