스태프급 엔지니어가 전하는 바이브 코딩 가이드

EDIT: 코딩에 관한 글을 썼더니 다들 우리 바이브 마케팅 엔진에 대해 물어보네 ㅋㅋ. 아래 앱들의 마케팅 전체를 운영하는 데 사용하고 있고, 내 프로필에 올려뒀음. 메시지 보내주면 무료로 설정하는 거 도와줄게.

Claude가 줄이라고 애원했지만, 글이 좀 길어짐. 소프트웨어 엔지니어들 사이에서 바이브 코딩에 대한 비관론이 많아서 긍정적인 사례를 보여주고 싶었음.

우리는 작지만 경험이 많은 팀임. 나는 유튜브에서 유명한 대형 VPN 회사에서 스태프 엔지니어 겸 엔지니어링 리드로 일했음. EMEA 전역의 엔지니어링 팀, 제품 엔지니어링, 인프라, 채용을 이끌었음. 그 후 내 스타트업을 세우고 VC 투자도 받았고, 수많은 실패와 성공을 겪었음. 공동 창업자는 가장 성공적인 프랑스 테크 스타트업 중 한 곳의 시니어 엔지니어였음. 우리는 작은 소비자 앱부터 수백만 명을 보호하는 인프라 설정까지 모든 것을 다뤄봤음.

6개월 동안 프로덕션 모노레포에 1만 개 이상의 커밋을 작성했음. 장난감 프로젝트나 보일러플레이트가 아니라, 2천 개의 PR을 통해 리뷰되고 머지된 실제 기능들이었음. 우리는 자체 바이브 배포 엔진을 구축하고 7개의 앱을 출시했음. 5개는 실패했고, 2개는 최소한의 유지보수로 6자리 수익을 올리고 있음. 내가 여기서 쓰는 내용은 전통적인 기업 환경에서는 불가능할 것임. 자기 사업을 하거나 기술 도입 장벽이 낮은 스타트업에 가장 적합함. 문제는 기술 측면이 아님. 기업의 보안 정책, 엔지니어링 가이드라인, 예산과 이를 조율하는 게 극도로 어려움.

처음부터 우리는 바이브 코딩에 매우 적극적이었음. 둘 다 어떻게 돌아가는지 배우는 데 수년을 썼지만, 항상 멋진 것을 만드는 데 집중했음. 내 경험상 훌륭한 엔지니어들은 항상 코드가 아니라 기능과 제품을 출시해왔음. 2025년 10월/11월쯤 시작했는데, 상황이 훨씬 쉬워졌음. 이제 10배에서 100배 더 생산적임.

바이브 코딩은 정말 마인드셋의 전환임. 대부분은 완전히 몰입하지 않아서 잘못하고 있음. 자연스럽게 호기심 많은 비기술직 사람들이 가장 잘 적응하는 것 같음. 그들은 작동 방식에 대한 선입견과 싸울 필요가 없어서 새로운 흐름에 몰입하기 때문임. 바이브 코딩을 조금씩(ChatGPT에 복사 붙여넣기 하는 수준) 기존 방식에 섞는 건 아무것도 얻지 못하는 지름길임. 우리는 에이전트 우선의 세계로 이동하고 있음. 예전 직장에서 쓰던 워크플로우는 거의 다 쓸모없음. 더 이상 인간 엔지니어를 위해 코딩하는 게 아님. 지난 50년 동안 인간 개발을 돕기 위해 코딩 관습을 다듬어왔음. LLM은 여러 면에서 인간의 사고와 비슷해서 여전히 유효한 것도 있지만, 아닌 것도 있음. 일반적으로 인간의 기억력이나 멀티태스킹 한계 때문에 구현했던 것들은 이제 구식임. 여기에 적응하지 못하는 사람들은 2년 안에 일자리를 잃을 거라고 확신함. 내 친구들 대부분은 이걸 이해하지 못하고 뒤처지고 있음.

이건 코드가 결코 병목이 아니었다는 걸 뼈저리게 느끼게 해줌. 대부분의 시간은 자신이 원하는 걸 설명하는 데 쓰게 될 텐데, 막상 조각을 맞춰보면 자기 아이디어가 말이 안 된다는 걸 깨닫게 될 것임. 엣지 케이스가 나타나고, 비즈니스 흐름이 불분명해지고, 범위가 늘어남. 대부분의 시간은 무엇을 만들지 고민하는 데 쓰게 됨. 그러고 나서 제품을 얻게 되면, 유통, 제품 시장 적합성, 판매, 수익화가 훨씬 더 어렵다는 걸 깨닫게 될 것임. 그게 진짜 고생의 시작임(우리가 배포 엔진을 먼저 만들고, 바이럴을 타본 뒤에 다른 걸 만든 이유이기도 함).

효과가 있다고 느낀 것들

첫 답변은 AI에게 맡기기. 대부분의 경우 생각보다 훨씬 잘함. 이상한 디자인 결정을 하거나 위험한 코드를 짤 수도 있으니 항상 의심할 준비는 해야 함. 하지만 깨끗한 컨텍스트를 주고 스스로 적대적 리뷰를 수행하게 하면 문제를 찾아낼 수 있음. 우리의 입력은 점점 덜 중요해지고 있고, 오히려 AI가 더 빨리 올바른 결정을 내리도록 가이드하는 역할임. 버그가 생기면 가장 먼저 Claude에게 파고들어 보라고 함.

AI에게 적절한 도구와 검증 수단을 제공하기. 이건 아무리 강조해도 부족함. 뭔가 작동하지 않을 때 수동으로 고치지 마셈. AI가 접근할 방법을 생각하셈. 직접 고치지 마셈. 도구를 제공하고 AI에게 고치라고 하셈. AI에게 AWS 권한을 주고 서버 로그를 읽게 하셈. 디버깅을 위해 읽기 전용 데이터베이스 접근 권한을 주셈. PostHog나 Mixpanel 접근 권한을 주면 갑자기 분석 데이터가 생김. GitHub 접근 권한을 주면 전체 PR과 커밋 기록을 볼 수 있고, 다른 사람들이 뭘 하는지도 알 수 있음.