방법론이 중요하다

바이브 코딩이 나온 지 좀 되니까 이제 슬슬 패턴이 보이기 시작하네.

이 패턴들을 보면 우리가 결과를 최적화하려면 뭘 어떻게 바꿔야 할지 답이 나와.

가장 눈에 띄는 패턴 하나는 방식과 과정이 결과물에 엄청난 영향을 준다는 거야. 그냥 한 줄짜리 프롬프트나 툭 던지는 사람보다, 처음에 시간 좀 들여서 계획 짜고 들어가는 바이브 코더들이 훨씬 결과가 좋아.

그럼 어느 정도의 과정이 최적일까? 당연히 폭포수(waterfall) 모델 시절로 돌아가고 싶진 않겠지. 그 방식은 10년 전 SaaS한테도 너무 느렸고, 지금은 그냥 고대 유물이야. 애자일(Agile) 방법론도 마찬가지야. 그건 엔지니어링 자원이 부족해서 그걸 최적화해야 한다는 전제하에 만들어진 거거든. 근데 지금은 엔지니어가 아니라 토큰이 부족한 시대잖아.

근데 상황이 그렇게 단순하지만은 않아.

애자일 시절엔 속도(velocity)를 최적화하는 게 핵심이었어. 소프트웨어 개발은 느렸고 엔지니어링 자원은 귀했으니까, 노동력을 줄이는 게 중요했거든. 그래서 속도가 가장 중요한 지표였지. 잘나가는 소프트웨어 팀은 딱 두 가지만 따졌어. 속도와 품질. 속도 빠르고 품질 좋은 팀이 무조건 다 씹어 먹었지.

지금은 어떨까?

음, 지금은 속도가 거의 공짜나 다름없어. 웬만한 사람이면 웹사이트 하나 뚝딱 만드는 건 일도 아니고, 프롬프트만 잘 넣으면 알아서 잘 돌아가거든. 그러니까 속도는 이미 기본으로 깔고 가는 거야. 굳이 속도 높이려고 애쓸 필요가 없어. 도구들이 이미 충분히 빠르니까.

그럼 이제 바이브 코딩에서 잘하는 놈이랑 못하는 놈을 가르는 결정적인 요소는 뭘까?

**품질(Quality)**이야.

이제 결과물의 급을 나누는 유일한 차이는 품질밖에 없어.

그러니까 앞으로 바이브 코딩 프로젝트를 할 때는 속도 관리보다는 품질 관리에 집중해야 한다는 거지.

그게 바로 방법론으로 이어지는 거고.

업계의 모범 사례나 배운 점들을 프로젝트에 녹여내는 게 바로 방법론이야. 그렇다고 엄청 무겁고 빡빡한 개발 주기를 도입하라는 게 아니야. 그냥 작업의 품질을 확실하게 높여줄 수 있는 행동들을 하라는 거지.

내가 프로젝트 할 때 쓰는 몇 가지 예시를 들어볼게.

1. 목표 설정. 나는 성공적인 프로젝트의 모습을 먼저 그려놓고 시작하는 걸 좋아해. 쉽게 말해서 "끝을 생각하고 시작하라"는 거지. 이런 식의 계획은 AI 툴체인을 쓸 때 특히 유용한데, AI한테 최종 목표를 명확하게 전달할 수 있거든. 아마존의 PR/FAQ 같은 문서들이 이런 식으로 접근하기 딱 좋아.

2. 반복(Iteration). 애자일에서 배운 것 중 지금도 여전히 유효한 게 바로 반복이야. 우리는 하면서 배우는 거니까, 반복을 많이 할수록 결과물 퀄리티가 올라가. AI가 사이클 타임을 확 줄여주니까 우리는 더 많이 반복할 수 있어. 이걸 피하지 말고 즐겨. 어차피 한 번에 끝낼 생각 말고 여러 번 만든다고 생각하고, 처음부터 세세한 거에 목숨 걸지 마. 처음엔 어차피 틀릴 테니까, 그래도 괜찮아.

3. 테스트. 이건 진짜 옛날 방식인데, 절대 포기할 수 없는 게 하나 있어. 바로 테스트야. 그냥 대충 하는 게 아니라 진짜 빡세게 하는 거 말이야. 풀 유닛 테스트, 풀 e2e 테스트, 스모크 테스트, 보안 스캔까지. 다 해야 돼. AI 이전에는 테스트 인프라 구축하는 게 인건비 측면에서 너무 비싸서 항상 고민이었거든. 개발자한테 기능을 만들게 할지, 테스트를 짜게 할지 선택해야 했으니까. 테스트 하나 짤 때마다 기회비용이 엄청났지. 근데 지금은 아니야. AI가 이 작업을 엄청나게 빨리 해치우거든. 그래서 이제는 테스트 쪽으로 완전히 무게중심을 옮겨야 해.

4. 감사(Audits). 테스트의 단짝은 바로 감사야. 감사는 외부에서 정한 표준에 맞춰 네 작업물을 검토하는 걸 말해. AI가 나오기 전 애자일 환경에서는 이게 진짜 골치 아픈 일이었거든. 감사 한 번 돌리느라 스프린트 전체를 날려 먹는 경우도 허다했으니까. 그래서 웬만하면 꼭 필요한 경우가 아니면 다들 감사 같은 건 안 했지. 근데 지금은 어떠냐고? 그냥 프롬프트 하나면 끝이야. "이 프로젝트 유형에 맞는 업계 모범 사례에 따라 내 코드를 감사해 줘" 같은 식으로 말이지. 주요 마일스톤을 넘길 때마다 전체 감사 과정을 거쳐서 진행 상황을 체크하는 게 좋아. GA(정식 출시) 때 보안 감사 딱 한 번 하는 걸로는 부족해. 상황은 계속 변하니까 정기적으로 감사를 돌려야 한다고.