클로드 코드로 B2C 서비스 개발하기
현실은 POC와 다르더라
최근 앤트로픽의 클로드 코드(Claude Code)를 사용해서 실제 B2C 상용 서비스를 개발하고 있다. 바이브 코딩이 대세라고 하길래 나도 한번 제대로 써보자 싶어서 시작했는데, 이거... 생각보다 만만치 않더라.
POC는 쉽다, 하지만 상용은...
요즘 주변을 보면 바이브 코딩으로 간단한 기능이나 POC 만들어보고는 "와, 이거 완전 혁명이다!"라고 하는 사람들이 많다. 솔직히 나도 처음엔 그랬다. 근데 실제 서비스로 가니까 완전 다른 이야기더라.
서비스가 복잡해지고 코드량이 늘어날수록, 그리고 디테일한 부분이 필요할수록 바이브 코딩의 한계가 드러나기 시작했다. 새로운 기능을 추가할 때마다 뭔가 다 커버가 안 되는 느낌? 실수도 하고 로직에도 구멍이 생기고...
그걸 하나씩 테스트하면서 고쳐나가는 게 또 엄청난 일이었다. 게다가 코드가 많아지니까 기본적으로 사용하는 토큰도 늘어나서 시간도 오래 걸리고, 토큰 리밋에 금방 도달해서 그냥 손 놓고 기다려야 하는 상황도 자주 발생했다.
더 큰 문제는 이미 코드를 안 보고 말로만 개발하는 데 익숙해져서, 막상 직접 코드를 고쳐야 할 때 손을 못 대는 거다. 완전 악순환이더라.
컨텍스트 관리의 중요성
Claude Code를 사용하다 보면 입력창 아래에 "Context left until auto-compact: 5%" 같은 메시지가 뜬다. 이게 바로 컨텍스트 윈도우가 거의 다 찼으니 압축하겠다는 신호다. 5%밖에 안 남았다는 건 95%나 찼다는 뜻이거든. 압축하면 아무래도 디테일한 부분이 부족해진다. 즉, 개발의 정확도가 떨어진다는 거다.
이때는 memorize 명령어로 중요한 내용을 CLAUDE.md 파일에 저장하고, 새 세션을 시작하는 게 좋다. 그런데 이것도 은근 번거롭다. 작업 흐름이 끊기고, 뭘 기억시켜야 할지 판단해야 하고...
CLAUDE.md 파일도 계속 커지면 성능이 느려지는 걸 체감하게 된다. 파일이 클수록 더 많은 토큰을 사용하고, 초기 로딩 시간도 길어진다. 그래서 주기적으로 백업하고 최적화하는 작업이 필요하더라.
DB 스키마 변경 = 지옥의 시작
진짜 최악은 개발 도중에 DB 스키마를 변경할 때다. Claude Code가 한번 기억한 테이블명이나 컬럼명을 계속 사용하는 바람에... 아무리 "테이블 이름 바뀌었다"고 말해도 계속 옛날 스키마로 코드를 생성한다.
특히 인증 모듈처럼 여러 단계가 연결된 경우는 더 심각했다.
"DB에서 사용자 정보 조회 → JWT 생성 → 캐시 저장" 이런 플로우에서 첫 단계(DB)가 문제인데, Claude Code는 자꾸 JWT 로직을 의심하면서 엉뚱한 곳을 고치더라.
결국 하드코딩으로 임시 해결하려고 하고, 캐시 때문에 더 꼬이고... 정말 고생했다.
해결책: 명확한 가이드라인 설정
이런 경험을 통해 깨달은 건, CLAUDE.md 파일에 명확한 가이드라인을 설정하는 게 중요하다는 거다.
최신 DB 스키마 섹션을 만들고 "DB 관련 코드 작성 시 반드시 이 스키마 확인할 것!" 명시
"하드코딩으로 우회하지 말고 문제의 본질을 해결하라" 같은 개발 원칙 추가
임시 해결책 사용 시 반드시 TODO 주석 남기기
이렇게 했더니 확실히 문제를 제대로 잡더라.
외부 서비스 연동의 어려움
SMTP 메일 서버 같은 외부 서비스 연동은 또 다른 난관이었다. Claude Code가 로컬에서 직접 테스트할 수 없으니까 "메일 전송 성공!"이라고 하면서 코드 짜놨는데, 막상 실행하면 인증 실패나 타임아웃...
이런 외부 연동 부분은 바이브 코딩의 명확한 한계다. 실제 환경에서만 테스트 가능한 것들은 AI가 아무리 똑똑해도 검증하기 어렵더라. 곧 MCP가 좀 더 보편화 되면, 이런것들도 다 해결될거라 본다.
편리한 기능들
입력창 아래 "auto-accept edits on" 같은 편집 모드 설정은 꽤 유용하다. shift+tab으로 on/off 전환할 수 있는데
on: Claude가 제안하는 변경사항을 자동 수락
off: 변경사항을 먼저 확인하고 수락/거절 가능
처음엔 auto-accept가 편하지만, 중요한 코드 작업할 때는 off로 해놓고 하나하나 확인하는 게 안전하다.
미래에 대한 생각
바이브 코딩을 사용하면서 든 생각인데, 예전엔 사람이 이해하기 어려운 언어나 프레임워크는 성능과 상관없이 사장되는 경우가 많았다. 마치 소니의 기술처럼... 하지만 AI가 중간에서 다 해주는 시대가 오면, 굳이 사람이 이해하는 언어가 필요할까?
어쩌면 가장 효율적인 언어나 프레임워크가 자리 잡을지도 모른다. 어셈블리어처럼 효율적이지만 사람이 직접 쓰기 어려운 언어들이 다시 부활할 수도 있고...
마무리
바이브 코딩은 분명 혁명적이지만, 아직은 상용 서비스에 적용하기엔 주의해야 할 점이 많다. POC나 프로토타입에는 최고지만, 실제 서비스로 갈수록 여러 한계가 드러난다.
그래도 이런 경험들을 쌓아가면서 더 나은 방법을 찾아가는 중이다. 프로젝트 초기에 명확한 가이드라인을 설정하고, 컨텍스트 관리를 잘하고, 외부 연동 부분은 직접 검증하면서... 초반에 이런것들을 프롬프트로 명시해주는게 나같은 아키텍트의 역할이 되지 않을까도 생각해 본다.
결국 도구는 도구일 뿐, 어떻게 활용하느냐가 중요한 것 같다. 독자분들도 바이브 코딩 사용하실 때 이런 점들 참고하시면 삽질을 줄일 수 있을거라 믿어 의심치 않는다.
