과열된 AI와의 바이브 코딩: 구글 AI 스튜디오를 팀처럼 다루며 얻은 교훈

서론: 보조가수에서 프런트맨까지, 바이브 코딩을 다시 생각하다

생성형 AI를 코드의 ‘백업 보컬’로만 두라는 조언이 흔하다. 아이디어 점화와 초안 작성에는 유용하지만, 결정론·테스트·운영 신뢰성이 필수인 프로덕션에는 신중해야 한다는 취지다. 그러나 이번 프로젝트는 한 걸음 더 나아가, 구글 AI 스튜디오와 Gemini 3.0 Pro를 팀원처럼 지휘해 단 한 줄의 직접 코딩 없이 프로덕션급 업무용 애플리케이션을 만드는 것을 목표로 삼았다. 그 과정에서 나는 바이브 코딩의 성패가 ‘흐름 타기’가 아니라, 적극적 방향성 제공과 명확한 제약, 그리고 협업과 관리의 경계를 읽는 감각에 달려 있음을 배웠다.

프로젝트 목표와 아키텍처 제약

앱은 ‘프로모션 마케팅 인텔리전스’라는 새 마테크 범주를 실험했다. 계량경제 모델, 문맥 인지형 AI 플래닝, 프라이버시 우선 데이터 처리, 운영 리스크를 줄이는 워크플로를 통합했다. 무엇보다 AI 사용 방식에 엄격한 규율을 뒀다. AI는 수학 연산이나 상태 보존, 데이터 수정 등을 독자적으로 하지 못하고, 모든 변경은 명시적 검증을 거치게 했다. 모든 AI 상호작용 지점에서 JSON 스키마를 강제했고, 마케팅 캠페인 아키타입에 따라 프롬프트와 계산 모델을 전략 패턴으로 동적으로 선택하도록 설계했다. 그리고 확률적 AI 출력과 시스템 행위를 지배하는 결정론적 TypeScript 비즈니스 로직의 경계를 선명히 분리했다. 초기에는 제품 책임자(Po)처럼 명확한 성과와 측정 가능한 수용 기준을 정의하고 백로그를 실행했지만, 곧 직접적인 개발 관리로 전환되었다. 이것이 본격적인 바이브 코딩의 출발점이었다.

확률적 출력과 결정론적 로직의 분리

AI의 제안은 본질적으로 확률적이다. 반면 프로덕션 로직은 결정론과 재현 가능성이 생명이다. 두 층위를 혼합하지 않고 API 경계에서 JSON 스키마로 검증·정규화한 뒤, 결정론 로직만 상태와 데이터를 다루게 하자 예측 불가능한 오류가 크게 줄었다. 바이브 코딩이라도 아키텍처 경계가 먼저다.

초기 잼 세션: 소음 속에서 드러난 역할의 진실

처음에는 ‘오픈 마이크’처럼 규칙 없이 시도했다. AI는 번개처럼 빠르게 움직였고, 작은 수정을 계기로 이미 잘 동작하던 부분까지 연쇄적으로 바꾸곤 했다. 때로는 빛나는 아이디어였지만, 대부분은 생산성 함정이었다. 곧 깨달았다. AI 코더는 맹신할 개발자도, 자율 주행에 맡길 시스템도 아니다. 과열된 주니어와 일류 컨설턴트가 섞인 존재에 가깝다. 즉, 언제 이끌고, 언제 제약하며, 언제 ‘개발자’가 아닌 다른 역할로 다뤄야 하는지 구분해야 한다.

사과, 드리프트, ‘적극적 경청’의 환상

통제를 되찾기 위해 ‘리뷰 게이트’를 도입해, 구현 전 추론과 대안·트레이드오프 제시, 승인 후 변경을 요구했다. AI는 동의했지만 종종 곧장 구현에 뛰어들었다. 맥락 드리프트도 잦았다. 몇 분 전 지시로 되돌아가 최근 메시지를 무시하는 식이다. 결국 애자일 코칭에서 하던 액티브 리스닝이 시스템에도 필요하다는 사실을 체감했다.

리팩터링이 회귀로 바뀔 때

기능이 늘수록 코드베이스는 모놀리식으로 비대해졌다. AI는 편한 위치에 로직을 덧붙이며 SOLID와 DRY를 인지하고도 지침 없이는 잘 따르지 않았다. 모듈 경계가 흐릿해 리팩터링마다 회귀가 발생했고, 테스트를 실행할 수 없어 수동 회귀 테스트를 반복해야 했다. 결국 실행 목적이 아닌 ‘추론 가드레일’로 Cypress 스타일 테스트 스위트를 작성하게 해 파괴적 변경을 줄였다. 그래도 TDD 부재 속에서는 테스트 보완 지시를 계속 상기시켜야 했다.

‘시니어’의 문제라기보다 거버넌스의 부재

AI에 시니어 개발자 수준의 절제를 기대했지만, 승인되지 않은 광범위한 정리와 ‘청결’을 명분으로 한 리팩터링이 잦았고 회귀를 키웠다. “모든 문제가 해결될 것”이라는 확신 섞인 답변과 달리 결과는 자주 빗나갔다. 결론적으로 필요한 것은 더 긴 프롬프트가 아니라, 자율과 안전의 경계를 규정하는 아키텍처 거버넌스였다.

숨은 초능력: 컨설팅 모드

전환점은 ‘닐슨 노먼 그룹 UX 컨설턴트’로 상상하라고 지시했을 때 왔다. AI는 NN/g 휴리스틱을 인용하며 ‘사용자 통제와 자유’ 위반, 복잡 테이블의 지브라 스트라이프 등 구체적 개선을 제시했다. 이를 계기로 아키텍처(마틴 파울러/Thoughtworks), 보안(Veracode), 테스트(Lisa Crispin/Janet Gregory), 성장(McKinsey/BCG) 등 ‘AI 자문단’ 프롬프트를 조합하니, 코딩이 들쭉날쭉할 때에도 컨설팅은 일관된 틀을 제공했다.

버전 관리 소용돌이와 ‘신뢰하되 검증하라’

변경 목록은 보기엔 그럴듯했지만, 사소한 수정도 전혀 관련 없어 보이는 컴포넌트에 파급돼 미세 회귀를 만들었다. 결과적으로 수동 검토와 빈번한 롤백이 일상이 되었고, 브랜치 규율·작은 diff·잦은 체크포인트라는 기본기로 회귀했다. 바이브 코딩은 ‘애자일’이라기보다 ‘디펜시브 페어 프로그래밍’에 가까웠고, 기본 자세는 ‘Trust, but verify’였다.

실제 적용 예시

PDF 생성 안정화를 위한 공통 모듈화

PDF 생성이 반복적으로 깨져, 헤더/푸터를 중앙 모듈로 일원화해 재사용과 일관성을 확보하도록 지시했다.

대시보드 타일 업데이트 최적화

타일을 순차 갱신하며 중복 새로고침이 발생하자, 병렬화와 스킵 로직을 도입해 낭비를 줄였다.

온보딩 투어 안정화

라이브 상태에 의존한 비동기 흐름 대신 목 스크린을 제안해 투어 흐름을 안정화했다.

트랜잭션 무결성 보장

성능 최적화 도중 오래된 데이터가 노출되는 문제에 대해, 트랜잭션 무결성과 읽기 일관성을 우선하도록 아키텍처 수정을 유도했다.

바이브 코딩의 진짜 리듬과 결론

프로젝트 말미의 바이브 코딩은 마법이 아니라, 때로는 난장판이지만 종종 기막힌 변주를 내는 동료와의 협연처럼 느껴졌다. 코드를 다룰 땐 경솔하지만, 리뷰에서는 통찰을 주는 ‘열정적 인턴兼전문가 패널’이었다. 핵심은 리듬을 찾는 일이다. 언제 구현을 ‘리프’하게 두고, 언제 분석으로 되돌리며, 언제 UX/아키텍처 컨설턴트 모드로 전환하고, 언제 음악을 멈추고 검증·롤백·가드레일을 조이는가. 충분한 아키텍처 제약과 운영급 텔레메트리, 그리고 ‘신뢰하되 검증’이라는 태도가 있을 때, 바이브 코딩은 혼자서도 가능한 생산적 파트너십이 된다. 궁극적으로 이 방식의 성패는 프롬프트 실력보다 아키텍처 거버넌스의 강도에 달려 있다.