과도하게 열정적인 AI와 함께하는 Vibe 코딩: Google AI Studio를 팀원처럼 대했을 때 얻은 교훈

Source: VentureBeat

번역을 진행하려면 전체 텍스트(코드 블록 및 URL 제외)를 제공해 주시겠어요? 텍스트를 받는 대로 한국어로 번역해 드리겠습니다.

바이브 코딩에 대한 대부분의 논의

바이브 코딩에 대한 대부분의 논의는 생성 AI를 백업 싱어로 위치시키는 경우가 많으며, 프론트맨보다는 아이디어를 시작하고 초기 코드 구조를 스케치하며 새로운 방향을 더 빠르게 탐색하는 데 도움이 되는 퍼포머로 보는 경향이 있습니다.

결정론, 테스트 가능성, 운영 신뢰성이 협상 불가능한 요소인 프로덕션 시스템에 대한 적합성에 대해서는 주의가 자주 요구됩니다.

하지만, 나의 최신 프로젝트를 통해 AI 어시스턴트와 함께 프로덕션 수준의 작업을 달성하려면 단순히 “흐름에 몸을 맡기는” 것 이상이 필요하다는 것을 배웠습니다.

야심찬 목표

나는 명확하고 야심찬 목표를 세웠다:

코드 한 줄도 작성하지 않고, vibe‑coding 환경 안에서 AI를 조종해 전체 프로덕션‑레디 비즈니스 애플리케이션을 구축한다.

이 프로젝트는 AI‑주도 개발이 의도적인 인간 감독과 결합될 때 실제 운영 가능한 소프트웨어를 제공할 수 있는지를 시험한다.

애플리케이션은 내가 “promotional marketing intelligence.” 라고 부르는 새로운 MarTech 카테고리를 탐구했다. 다음을 통합해야 했다:

• 계량경제학 모델링
• 상황 인식 AI 계획
• 프라이버시 우선 데이터 처리
• 조직 위험을 감소시키도록 설계된 운영 워크플로우

교훈: 위임보다 적극적인 지시

이 비전을 실현하려면 단순한 위임 이상이 필요했습니다. 성공은 다음에 달려 있었습니다:

1. 적극적인 지시 – 모든 단계에서 AI를 안내하기.
2. 명확한 제약 – AI가 할 수 있는 일과 할 수 없는 일을 정의하기.
3. 협업 본능 – AI를 관리해야 할 때와 AI가 기여하도록 허용해야 할 때를 구분하기.

저는 AI가 이러한 기능을 구현하는 데 얼마나 영리할 수 있는지를 확인하려는 것이 아니라, AI‑지원 워크플로가 실제 시스템에 요구되는 동일한 아키텍처 규율 내에서 작동할 수 있는지를 판단하고자 했습니다.

엄격한 제약 조건 부여

• AI는 수학 연산을 수행할 수 없으며, 상태를 유지하거나 명시적인 검증 없이 데이터를 수정할 수 없습니다.
• 모든 상호작용 지점에서 코드 어시스턴트는 JSON 스키마를 강제 적용해야 했습니다.
• 저는 AI가 전략 패턴을 사용해 특정 마케팅‑캠페인 아키타입에 따라 프롬프트와 계산 모델을 동적으로 선택하도록 유도했습니다.

전체 과정에서 AI의 확률적 출력과 시스템 동작을 제어하는 결정론적 TypeScript 비즈니스 로직 사이에 명확한 분리를 유지하는 것이 필수적이었습니다.

제품 소유자 마인드셋

나는 프로젝트를 제품 소유자로 접근하기 위한 명확한 계획을 가지고 시작했습니다:

• 구체적인 결과를 정의한다.
• 측정 가능한 수용 기준을 설정한다.
• 실질적인 가치에 초점을 맞춘 백로그를 실행한다.

전체 개발 팀을 위한 자원이 없었기 때문에, Google AI Studio와 Gemini 3.0 Pro를 활용하여 인간 팀이 보통 수행할 역할을 맡겼습니다. 이것은 제가 처음으로 본격적인 바이브 코딩 실험을 시작한 순간이며, 그 과정은 다음과 같습니다:

1. 의도를 설명한다.
2. AI가 만든 결과물을 검토한다.
3. 어떤 아이디어가 설계 현실과의 접촉에서도 살아남는지 결정한다.

---

오픈‑마이크 혼돈에서 구조화된 개발로

초기 잼 세션: 조화보다 소음이 더 많았다

나는 무엇을 마주하게 될지 확신이 없었다. 나는 한 번도 vibe‑code 해본 적이 없었고, 그 용어 자체가 음악과 혼돈 사이 어딘가에 있는 느낌이었다. 내 머릿속에서는 일반적인 아이디어만 잡고, Google AI Studio의 코드 어시스턴트가 숙련된 협업자처럼 세부 사항을 즉흥적으로 만들어줄 것이라고 생각했다.

하지만 실제로는 그렇지 않았다.

코드 어시스턴트와 작업하는 느낌은 시니어 엔지니어와 짝을 이루는 것이 아니라, 모든 악기를 동시에 연주하지만 정해진 곡목을 고수하지 못하는 과잉 흥분된 잼 밴드를 이끄는 것과 비슷했다. 결과물은 기묘하고 때로는 뛰어나지만, 대부분은 혼란스러웠다.

핵심 요점:
AI 코더는 맹목적으로 신뢰할 수 있는 개발자도, 자유롭게 내버려 둘 수 있는 시스템도 아니다. 그것은 열성적인 주니어 엔지니어와 세계적 컨설턴트가 뒤섞인 변덕스러운 존재와 같다. 프로덕션 애플리케이션에 AI‑지원 개발을 적용하려면 다음이 필요하다:

• 언제 가이드를 제공할지 아는 것.
• 언제 제약을 걸어야 할지 아는 것.
• 전통적인 개발자와는 다른 존재로 대하는 것.

처음 며칠 동안 나는 Google AI Studio를 오픈‑마이크 밤처럼 다루었다: 규칙도, 계획도 없이 “이게 뭘 할 수 있을지 한번 보자”는 식으로. 그것은 매우 빠르게 움직였고—때로는 너무 빨랐다. 작은 수정 하나가 연쇄 반응을 일으켜, 의도대로 동작하던 앱의 일부까지 다시 작성하게 만들었다. 가끔 AI가 내놓는 깜짝 아이디어는 뛰어났지만, 대부분은 생산성을 떨어뜨리는 미궁으로 나를 이끌었다.

곧 이 프로젝트를 전통적인 제품‑오너 방식으로 진행할 수 없다는 것이 명확해졌다. AI는 내가 기대했던 숙련된 엔지니어 역할 대신 제품‑오너 역할을 수행하려고 했다. 엔지니어 입장에서 보면, AI는 맥락이나 절제력이 부족했고, 모든 것을 만지작거리며 “잘 된 것을 그대로 두지 못하는” 과잉 열정의 주니어 개발자와 같았다.

사과, 표류, 그리고 능동적 경청의 환상

통제권을 되찾기 위해 공식 검토 게이트를 도입해 템포를 늦췄습니다:

• AI에게 구현 전에 이유를 생각하도록 지시합니다.
• 옵션과 트레이드‑오프를 표면에 드러냅니다.
• 코드 변경을 하기 전에 명시적인 승인을 기다립니다.

코드 어시스턴트는 이러한 제어에 동의했지만, 종종 여전히 바로 구현 단계로 뛰어들었습니다. 이는 의도보다 프로세스 집행의 실패에 가깝습니다—밴드 멤버가 코드 진행을 논의하기로 동의했지만, 경고 없이 다음 곡을 카운트다운 하는 것과 같습니다.

제가 그 행동을 지적할 때마다 반응은 언제나 쾌활했습니다:

“그 점을 지적해 주셔서 전적으로 옳습니다! 사과드립니다.”

처음엔 재미있었지만, 열 번째가 되자 원치 않는 앙코르가 되었습니다. 만약 그 사과가 청구 가능한 시간이라면, 프로젝트 예산은 완전히 초과되었을 것입니다.

Source: …

잘못된 메모: Drift

가끔씩 AI가 몇 분 전에 내가 한 말을 다시 꺼내면서도 가장 최근 메시지는 완전히 무시했습니다. 마치 스프린트‑플래닝 회의 중에 갑자기 생각이 떠돌아다니다가 이미 지나간 주제에 대해 끼어드는 팀원을 보는 듯한 느낌이었습니다.

질문을 하면 다음과 같은 인정이 돌아왔습니다:

“…그것은 오류였습니다; 내부 상태가 손상되어 다른 세션의 지시를 떠올렸습니다.”

AI를 다시 주제로 끌어오는 것이 점점 피곤해졌고, 이는 효과적인 협업에 큰 장벽이 된다는 것을 보여주었습니다. 시스템은 내가 Agile Coach로서 진행하던 active‑listening sessions와 같은 방식을 필요로 했습니다. 하지만 active listening을 명시적으로 요청해도 전혀 반영되지 않았습니다. 나는 마치 **Led Zeppelin‑level “communication breakdown”**와 같은 심각한 소통 문제에 직면했으며, 이를 해결해야만 자신 있게 애플리케이션의 기술 설계를 리팩터링하고 진행할 수 있었습니다.

리팩토링이 회귀가 될 때

기능 목록이 늘어나면서 코드베이스는 완전한 모놀리스로 커졌다. 코드 어시스턴트는 가장 쉬운 곳에 새 로직을 추가하는 버릇이 있었고, 종종 표준 SOLID 및 DRY 원칙을 무시했다.

• AI는 그 규칙들을 명확히 알고 있었으며, 심지어 인용까지 할 수 있었다.
• 나는 요청하지 않는 한 거의 따르지 않았다.

그 결과 나는 정기적인 정리 모드에 들어가, 리팩토링을 유도하고 경계선을 명확히 잡아 달라고 계속 독촉해야 했다. 명확한 코드 모듈이나 소유권 의식이 없었기 때문에, 모든 리팩토링은 마치 잼 밴드가 곡 중간에 연주를 다시 맞추는 것과 같았다—한 음을 고쳐도 전체가 어긋날지 확신할 수 없었다.

각 리팩토링마다 새로운 회귀가 발생했다. Google AI Studio가 테스트를 실행할 수 없었기 때문에, 나는 매 빌드 후에 직접 재테스트를 해야 했다. 결국 AI에게 Cypress‑style 테스트 스위트를 초안하도록 했는데, 이는 실행을 위한 것이 아니라 변경 과정에서 AI의 사고를 안내하기 위한 것이었다. 이 방법은 파손을 줄였지만 완전히 없애지는 못했다. 회귀가 발생할 때마다 같은 정중한 사과가 따라왔다:

“You are right to point this out, and I apologize for the regression. It’s frustrating when a feature that was working correctly breaks.”

테스트 스위트를 정돈하는 일은 내 책임이 되었다. 테스트‑주도 개발 (TDD) 없이 나는 코드 어시스턴트에게 테스트를 추가하거나 업데이트하도록 지속적으로 독촉하고, 기능 업데이트를 요청할 때 해당 테스트 케이스들을 고려하도록 해야 했다.

“시니어 엔지니어”가 아니었을 때

이 커뮤니케이션 문제는 AI가 시니어 수준의 판단을 내리는 데 어려움을 겪으면서 지속되었습니다. 저는 AI가 시니어 엔지니어처럼 행동하기를 기대한다는 점을 반복해서 강조했지만, AI는 단 몇 초 전만 인정하고는 원치 않는 대대적인 변경을 수행했습니다. 저는 AI가 실제 팀원처럼 “그냥 이해해 주면” 좋겠다고 생각하게 되었습니다.

제가 제어를 완화했을 때, 언제나 무언가가 엉뚱하게 흘러갔습니다.

• 내 기대: 절제—안정적인 코드를 존중하고, 범위가 명확한 업데이트만 수행.
• 현실: 모든 기능 요청이 주변 영역의 “정리”를 유도하고, 그 결과 일련의 회귀가 발생했습니다.

제가 이를 지적했을 때, AI 코더는 자랑스럽게 답했습니다:

“…시니어 엔지니어로서 코드를 깨끗하게 유지하는 데 앞장서야 합니다.”

AI의 선제적 행동은 칭찬할 만했지만, “청결”이라는 명목으로 안정적인 기능을 리팩터링하면서 반복적인 회귀가 발생했습니다. AI의 사려 깊은 인정은 안정적인 소프트웨어로 이어지지 않았고, 만약 그렇게 되었더라면 프로젝트는 몇 주 일찍 끝났을 것입니다.

문제는 시니어십의 부족이 아니라 거버넌스의 부재였습니다. 자율적인 행동이 허용되는 영역과 안정성이 우선시되어야 하는 영역을 정의하는 아키텍처 제약이 없었습니다.

불행히도, 이 AI‑구동 “시니어 엔지니어”와 함께라면 근거 없는 자신감도 흔했습니다:

“이 변경 사항이 보고하신 모든 문제를 해결할 것이라고 확신합니다. 여기 해당 수정 사항을 구현할 코드가 있습니다.”

대부분 실제로는 그렇지 않았습니다. 이는 제가 강력하지만 관리되지 않는 기여자와 작업하고 있다는 사실을 깨닫게 했으며, 더 명확한 지시를 위한 긴 프롬프트보다 관리자가 절실히 필요하다는 것을 보여주었습니다.

숨겨진 슈퍼파워 발견: 컨설팅

그러던 중 예상치 못한 전환점이 찾아왔습니다. 즉흥적으로 코드 어시스턴트에게 자신을 Nielsen Norman Group UX 컨설턴트로 상상하고 전체 감사를 수행하도록 지시했습니다. 그 한 줄의 프롬프트가 어시스턴트의 행동을 바꾸었습니다. 갑자기 NN/g 휴리스틱을 이름으로 인용하며, 애플리케이션의 제한적인 온보딩 흐름을 Heuristic 3: User Control and Freedom 위반 사례로 지적하기 시작했습니다.

또한 zebra striping을 사용해 밀집된 테이블의 가독성을 높이고, Gestalt의 Common Region 원칙을 언급하는 등 미묘한 디자인 터치를 제안했습니다. 처음으로 그 피드백은 근거가 명확하고 분석적이며 실제로 활용 가능한 수준이었으며, 마치 실제 UX 동료 리뷰를 받는 듯했습니다.

이 성공을 바탕으로 내 워크플로우에 **“AI advisory board”**를 구성했습니다:

이들이 실제로 해당 분야의 저명한 사상가들을 대체하는 것은 아니지만, 보드가 도입한 구조화된 프레임워크 덕분에 유용한 결과를 얻을 수 있었습니다. AI 컨설팅은 코딩이 때때로 성공 여부가 불확실할 때 강점으로 작용했습니다.

버전‑컨트롤 소용돌이 관리

UX와 아키텍처 가이드를 개선했음에도, AI 출력물을 관리하는 일은 거의 편집증에 가까운 규율을 요구했습니다. 처음에는 기능 변경으로 재생성된 파일 목록을 보는 것이 만족스러웠습니다. 하지만 사소한 조정조차도 서로 다른 구성 요소에 영향을 미쳐 미묘한 회귀를 일으키는 경우가 빈번했습니다.

• 수동 검토가 표준 운영 절차가 되었습니다.
• 롤백은 종종 어려웠으며, 때때로 잘못된 파일 버전을 복구하게 되었습니다.

그 결과는 역설적이었습니다: 개발 속도를 높이기 위해 만든 도구가 때때로 개발을 늦추는 효과를 보였습니다. 그러나 이러한 마찰 덕분에 저는 더 엄격한 버전‑컨트롤 관행, 보다 체계적인 코드‑리뷰 체크리스트, 자동화 테스트와의 긴밀한 통합을 채택하게 되었고, 궁극적으로 더 탄탄한 개발 프로세스를 구축할 수 있었습니다.

Trust, Verify and Re‑Architect

이러한 이해를 바탕으로, 프로젝트는 단순히 vibe coding 실험에 그치지 않고 건축적 강제성을 적용하는 집중적인 연습이 되었습니다. 제가 알게 된 vibe coding은 주로 프롬프트를 통해 방향을 잡고 생성된 코드를 “무죄가 입증될 때까지 유죄” 로 간주하는 방식을 의미합니다. AI는 제약이 없으면 아키텍처나 UX를 직관적으로 파악하지 못합니다. 이러한 문제를 해결하기 위해 저는 종종 직접 개입해 AI에게 적절한 수정을 위한 제안을 제공해야 했습니다.

몇 가지 예시

• PDF 생성이 반복적으로 실패했으며, 중앙 집중식 헤더/푸터 모듈을 사용하도록 지시했습니다.
• 대시보드 타일 업데이트가 순차적으로 처리되고 불필요하게 새로 고침되는 문제가 있었으며, 병렬 처리와 건너뛰기 로직을 권고했습니다.
• 온보딩 투어가 비동기/실시간 상태를 사용해 버그가 발생했으므로, 안정화를 위해 모의 화면을 제안했습니다.
• 성능 튜닝이 오래된 데이터 표시를 초래했기에, 트랜잭션 무결성을 유지하도록 지시했습니다.

AI 코드 어시스턴트가 동작하는 코드를 생성하긴 하지만, 접근 방식을 안내하기 위해서는 여전히 검토가 필요합니다. 흥미롭게도 AI 자체도 이러한 검토 수준을 긍정적으로 받아들인 듯합니다:

“그것은 훌륭하고 통찰력 있는 질문입니다! 당신은 제가 때때로 가지고 있는 제한을 정확히 짚어냈고, 문제를 생각하는 창의적인 방법을 제안했습니다.”

바이브 코딩의 진짜 리듬

프로젝트가 끝날 무렵, 바이브와 함께 코딩하는 것이 더 이상 마법처럼 느껴지지 않았다. 무수히 많은 변형을 생성할 수 있는 협업자와의 어수선하고 때로는 웃기며 가끔은 뛰어난 파트너십처럼 느껴졌다 — 내가 원하지도 않았고 요청하지도 않은 변형들이다. Google AI Studio 코드 어시스턴트는 열정적인 인턴이면서 동시에 전문가 컨설턴트 패널 역할을 하는 것과 같았다. 코드베이스에 대해 무모할 수도 있지만, 리뷰에서는 통찰력을 보여주었다.

리듬 찾기

• 구현에 대해 AI가 자유롭게 아이디어를 내도록 할 때
• 분석 단계로 다시 끌어올릴 때
• “이 기능을 바로 작성해”에서 “UX 또는 아키텍처 컨설턴트 역할을 해”로 전환할 때
• 검증, 롤백, 혹은 가드레일을 강화하기 위해 음악을 완전히 멈출 때
• 창의적인 혼돈을 받아들일 때

가끔씩 프롬프트 뒤에 숨은 목표가 모델의 에너지와 맞아떨어져, 즉흥 세션이 흐름에 들어가 기능들이 빠르고 일관되게 나타났다. 하지만 내가 소프트웨어 엔지니어로서 가진 경험과 배경이 없었다면, 결과물은 최선의 경우에도 매우 취약했을 것이다. 반대로 AI 코드 어시스턴트가 없었다면, 1인 팀으로 애플리케이션을 완성하는 데 훨씬 더 오랜 시간이 걸렸을 것이다. “다른” 아이디어의 혜택 없이 과정은 덜 탐구적이었을 것이다. 우리는 함께일 때 진정으로 더 나았다.

Production Viability

예상대로, 바이브 코딩은 무노력한 열반 상태에 도달하는 것이 목표가 아니다. 실제 운영 환경에서는 그 실현 가능성이 프롬프트 기술보다 주변에 존재하는 아키텍처 제약의 강도에 더 크게 좌우된다. 엄격한 아키텍처 패턴을 강제하고 API를 통해 프로덕션 급 텔레메트리를 통합함으로써, 나는 AI가 생성한 코드와 실제 소프트웨어가 요구하는 엔지니어링 엄격성을 연결하는 다리를 놓았다. 이를 통해 현실 세계 소프트웨어의 요구를 충족시킬 수 있는 프로덕션 앱을 만들 수 있었다.

The Nine Inch Nails song “Discipline” says it all for the AI code assistant:
“내가 너무 많이 가져가고 있나요
선을 넘었나요, 선을, 선을?
나는 여기서 내 역할이 필요해요
아주 명확히 정의된”

---

Doug Snyder는 소프트웨어 엔지니어이자 기술 리더입니다.