비개발자의 30일간의 바이브 코딩: 200시간, 7만 줄을 작성하며 배운 교훈

간단한 배경: 난 개발자가 아님. PM 같은 배경을 가지고 있고, 외부에서 아키텍처, 코드, 보안에 대해 어느 정도 파악하고 있지만, 이 전에는 혼자서 뭔가를 출시할 수 없었음. 계속하면서 방법을 찾아가는 중이라 내 방식이 완벽과는 거리가 멀지만, 시작하기 전에 알았더라면 도움이 되었을 내용을 공유하려고 함.

지난 30일 동안 200시간 넘게 바이브 코딩을 했고, 우리 팀이 내부적으로 사용하는 제품을 만들었음. 채팅, 벡터 임베딩, LLM 스크린샷 읽기, 두 가지 모델을 사용한 텍스트 및 이미지 생성, 로그인, 설정, 몇 가지 복잡한 기능들. 약 7만 줄의 코드 중 30%는 테스트 코드임. Sentry, PostHog 등을 구현했음. 꽤 괜찮은 내부 툴이라고 생각함. 멀티 테넌트 지원까지는 몇 주 남았음. 지금은 제 역할을 다하고 팀의 시간을 절약해주고 있어서 만족함.

일찍 알았더라면 좋았을 것들:

• PRD(제품 요구사항 정의서)로 시작하세요. 전반적인 로드맵을 작성하고, 더 작은 단계로 나누고, 무엇을 먼저 집중할지 결정하세요. 마이크로 기능 단위로 하나씩 만드세요. AI가 복잡한 걸 한 번에 해결할 거라 기대하지 마세요. 무조건 실패합니다.
• 모든 것을 한 세션에서 만들지 마세요. 토큰을 너무 빨리 소모하게 됩니다. 새로운 기능마다 새 세션을 열고, /compact focus on <X>를 사용해 컨텍스트를 좁게 유지하세요. 가장 성능이 좋은 모델로 계획하고, 좀 더 가벼운 모델로 코딩하세요. 토큰을 눈에 띄게 절약할 수 있습니다.
• 새로운 기능은 UI부터 만드세요. AI가 당신이 원하는 것을 실제로 이해했는지 확인하는 가장 저렴한 방법입니다. 표면을 다듬고 나서 만족스러우면 백엔드로 넘어가세요.
• AI에게 단위 테스트와 E2E 테스트를 작성하도록 가르치세요. 엄청나게 도움이 됩니다. 코드를 건드릴 때마다 자동으로 회귀 버그를 잡아냅니다. 중요한 부분은 여전히 수동으로 테스트하지만, 자동화된 방식은 빠르게 본전을 뽑습니다.
• 버전 관리를 위해 Git을 사용하세요. 알려진 좋은 버전으로 되돌리는 것이 때로는 가장 빠른 해결책입니다. 1만 6천 줄부터 시작했는데, 더 일찍 시작하지 않은 걸 후회했습니다.
• 적절한 CLAUDE.md(또는 사용하는 도구에 따라 AGENTS.md)를 작성하세요. 계획, 규칙, 피해야 할 함정 등을 적으세요. "컴포넌트를 공격적으로 분리할 것", "컴포넌트에 비즈니스 로직을 넣지 말 것" 같은 규칙을 추가하기 전까지는 컴포넌트가 비대해졌습니다.
• 리팩토링 날을 가지세요. 가끔은 새로운 기능 대신 1~2일 동안 순수하게 정리, 리팩토링, 문서화에 시간을 씁니다. 새로운 기능 출시를 멈추기 어렵다는 건 알지만, 중요합니다. 그렇지 않으면 코드베이스가 걷잡을 수 없이 커지고 품질이 떨어집니다.
• 모든 PR마다 /review와 /security-review를 실행하세요. 지금은 둘 다를 위한 자체 서브 에이전트를 만들었는데, 시간을 조금 절약해주고 나와 LLM이 계속 놓치는 패턴에 맞춰져 있습니다.
• 보안에 신경 쓰세요. 전문가일 필요는 없습니다. 기본은 알아야 합니다: 토큰을 어떻게 처리해야 하는지, 스택의 데이터베이스 권한 부여가 어떻게 작동하는지(Firestore 보안 규칙, Postgres RLS 등), 클라이언트와 서버에 무엇이 노출되는지. 구현하기 전에 AI에게 함정을 설명해달라고 하세요. 작업하면서 가끔 중요한 부분을 점검하세요.
• 여러 모델을 사용하고, 각 모델의 강점을 활용하세요. Claude는 UI/UX에 좋습니다. Codex는 더 복잡한 작업에 더 잘하고 무거운 리팩토링 시 토큰을 덜 소모합니다. PR을 다른 모델로 교차 검증하면 원래 작성자가 놓친 부분을 잡아낼 수 있습니다. Gemini는 코드베이스의 큰 부분을 평가할 때 가끔 사용하는데, 매우 빠르고 때로는 도움이 되는 새로운 관점을 제공하지만, 직접 뭔가를 만들게 하지는 않으며 그 피드백을 Claude나 Codex에 전달해 추론을 확인합니다. 복불복입니다. 다음 Gemini 모델을 기다리는 중입니다.
• 메인 채널 말고 프리뷰 채널을 사용하세요. 배포 스크립트로 라이브로 가기 전에 프리뷰에 배포합니다. 또한 현재 커밋이 내가 프리뷰한 SHA와 일치하지 않으면 승격을 거부하도록 설정해서, 검증하지 않은 버전을 실수로 배포할 수 없게 했습니다. 프리뷰는 깨질 수 있지만, 프로덕션은 그러면 안 됩니다.