Vibe Thinking - 생각만큼 빠르게 코딩하는 개발자

Source: Dev.to

팀의 AI 코딩 도구가 실서비스에 적용되었습니다. 첫 주에 나온 결과는 정말 인상적이었습니다. PR 수가 늘었고, 모두가 흥분하고 있었습니다.
스프린트 리뷰에서 보드 모습은 그대로였습니다.
절반에 달하는 PR이 아직 리뷰를 기다리고 있었고, 몇몇은 QA 플래그가 달렸으며, 몇 개는 아무도 답변하지 않은 요구사항 질문 때문에 차단되었습니다. 코드는 빨라졌지만, 스프린트는 그렇지 않았습니다.

이것이 대부분의 Vibe 코딩 도입이 멈추는 지점입니다. 도구가 작동하지 않아서가 아니라—도구는 제대로 작동합니다—하지만 개발자가 일하는 방식을 바꾸었고, 개발자를 둘러싼 모든 것이 그대로였기 때문입니다. 이 글은 개발자 수준에서 실제로 바뀌어야 하는 점과 그 과정에서 주의해야 할 함정에 대해 다룹니다.

이 글은 Vibe Thinking 시리즈의 Post 1입니다. 아직 소개 글을 읽지 않았다면 먼저 읽어보세요—그 글은 왜 개발자만의 변화만으로는 스프린트를 움직일 수 없는지를 설명합니다.

가장 눈에 띄는 변화는 당연한 것입니다: 직접 코드를 쓰는 양이 줄어든다는 점입니다. 이제 의도를 설명하고, 출력물을 조정하고, 검토하고 검증합니다. 모든 라인을 직접 타이핑하는 대신 AI에게 지시를 내리는 것이죠.

하지만 이런 표현만으로는 실제 변화가 무엇인지 충분히 전달하지 못합니다.

개발자의 역할 변화

개발자는 작성자(author) 에서 설계자·검토자(architect‑and‑reviewer) 로 역할이 이동합니다. 이는 업무 요구사항이 의미 있게 바뀐다는 뜻이며, 겉보기보다 훨씬 인지적으로 복잡한 전환입니다.

• 작성(authoring) 은 생성적입니다. 처음부터 무언가를 만들면서 순차적으로 결정을 내립니다.
• 검토 및 지시(reviewing & directing) 은 평가적입니다. 전체 그림을 머릿속에 그리면서 출력물이 그와 일치하는지 판단하고, 잘못된 부분을 찾아 왜 틀렸는지 이해하며, 올바른 방향으로 이끕니다.

이러한 사고 모델을 유지하는 것은 “노력이 더 든다”는 의미가 아니라, 진정한 전문성이 요구된다는 의미입니다.

또 바뀌는 것들: 업무 하루의 형태

• 긴 집중 코딩 구간 대신 짧고 반복적인 피드백 루프(프롬프트 → 검토 → 검증 → 반복 → 다시 프롬프트) 로 작업합니다.
• 리듬이 달라지고, 중단이 잦으며, 선형적이지 않습니다.

하지만 근무 시간, 산출물 품질에 대한 책임, 프로덕션에서의 나쁜 코드 비용 등은 변하지 않습니다.

책임은 변하지 않는다
누가—또는 무엇이—코드를 작성했든, 병합되는 모든 라인에 대해 개발자는 책임을 집니다. AI가 만든 코드가 프로덕션 사고를 일으킨다면, 그 코드를 검토·승인한 개발자가 책임을 집니다. 이는 처벌이 아니라 전문 엔지니어링의 기본 원칙입니다.

기술 부채 비용도 마찬가지입니다. 리뷰 단계가 약하면 Vibe 코딩은 전통적인 개발보다 부채를 더 빨리 쌓을 수 있습니다. 출력량이 많아지고 패턴을 파악하기 어려워지기 때문이죠. 동일하거나 더 약한 검증으로 더 많은 코드가 빠르게 들어오면 상황은 악화됩니다.

또한 배포하는 코드를 깊이 이해해야 한다는 요구도 변하지 않습니다. 코드가 왜 동작하는지 설명할 수 없으면, 오류가 발생했을 때 디버깅도, 확장도, 리뷰 방어도 할 수 없습니다. “이해하지 못하는 코드는 절대 병합하지 않는다”는 규칙은 AI가 코드를 생성할수록 더욱 중요해집니다.

놀라운 사실: 리뷰 작업량은 오히려 증가한다

코드 생산량이 늘어납니다. 각 라인은 병합 전에 이해·검증·소유가 필요합니다. 만약 3배의 코드량을 만든다면, 3배의 리뷰 엄격함이 필요합니다—그렇지 않으면 위험이 3배로 쌓이게 됩니다.

리뷰 단계는 Vibe 코딩 워크플로우에서 가치가 창출되거나 파괴되는 핵심 지점입니다. 빠르게 코드를 만들고 부주의하게 리뷰한다면, 생산적인 개발자가 아니라 위험을 만드는 존재가 됩니다.

현재 개발자들의 인식 (데이터)

• 84 % — AI 코딩 도구를 사용하거나 도입을 계획 중
• 46 % — AI 출력 정확성을 적극적으로 신뢰하지 않음
• 66 % — “거의 맞지만 완벽하지 않다”는 평가

이제 리뷰가 장인정신이며, 프롬프트 엔지니어링은 초안 수준을 만들 뿐, 실제 전문성은 리뷰에서 발휘됩니다.

AI 도입 전후로 의미가 사라진 개발자 습관

1. 히어로 코더 정체성

   • 모든 라인을 직접 작성하고, 코드베이스 전체를 머릿속에 보유하며, 모든 동작의 유일한 진실 공급원인 개발자.
   • 이 정체성은 과거에 장인 정신이 인정·보상받던 방식이었지만, Vibe 코딩에서는 도구 사용을 억제하거나(정체성 보호) 비판적 리뷰 없이 과도하게 의존하게 만들 위험이 있습니다.
   • 새로운 정체성은 설계자·검토자이며, 핵심 역량은 판단에 있습니다.

2. 타이핑 속도를 생산성 척도로 삼는 관행

   • 이제는 출력 품질과 전달 속도가 중요합니다. 타이핑 속도는 더 이상 의미 있는 대리 지표가 아닙니다.

3. 완전한 요구사항이 있을 때까지 기다리는 습관

   • Vibe 코딩은 시작 비용을 낮추지만, 모호한 작업을 시작하라는 뜻은 아닙니다. 올바른 모델은 먼저 작업을 분해하는 것입니다.

4. 대규모 스프린트 작업

   • 전체 스프린트 동안 큰 기능을 개발하고 한 번에 배포하는 방식은 위험도가 높고 검증이 늦어집니다. 대신 작은 증분을 지속적으로 배포하는 것이 경제적입니다.

5. 출시 전 금도금(gold‑plating)

   • 작업을 완벽히 다듬은 뒤에 병합하는 대신, 작동 가능한 원자적 기능을 병합 → 검증 → 반복하는 흐름이 필요합니다.

Vibe 코딩에서 적절한 작업 단위는?

• 사용자 스토리도, 전체 기능도 아니다.
• 원자적 기능(atomic feature): 독립적으로 명세·구현·테스트·리뷰가 가능한 작업 조각.

좋은 원자적 기능의 조건

• 한 문장으로 결과를 기술할 수 있다.
• 수용 기준이 명확히 구분된다(동작하거나 동작하지 않는다).
• 다른 작업을 기다리지 않고 구축·검증이 가능하다.
• 요구사항이 나중에 바뀌어도 영향을 받는 범위가 이 조각에만 국한된다.

이 분해 단계는 첫 프롬프트를 작성하기 전에 이루어져야 합니다. Vibe 코딩을 이해하는 PM이나 BA는 이미 원자적 기능으로 작업 항목을 나눕니다. 충분한 시스템 컨텍스트를 가진 LLM도 분해를 도울 수 있지만, 개발자는 분해 결과를 검증할 책임이 있습니다. 원자적 기능이 PM이 제시했든 AI가 제안했든, 개발자는 각 조각이 진정으로 독립적인지, 의존성이 명확한지, 통합 지점이 숨은 결합을 만들지 않는지를 확인해야 합니다. 이는 시스템에 대한 진정한 지식이 요구되는 작업이며, Vibe 코딩이 대체할 수 없는 전문성입니다.

예시

“Google OAuth를 이용한 사용자 로그인”은 원자적 기능이 아니라 전체 기능입니다. 하나의 프롬프트로 만들면 얽힌 출력물이 되어 리뷰와 디버깅이 어려워집니다. 이를 적절히 분해하면 다음과 같은 세 개의 독립적인 조각이 됩니다:

1. OAuth 인증 흐름 구현
2. 사용자 계정 매핑 로직 구현
3. 로그인 UI와 연동 구현

각 조각은 단일 세션 내에 구축·명확한 수용 기준으로 검증·전체 단위로 리뷰가 가능합니다. 리뷰·테스트 중 문제가 발생하면 해당 조각에만 영향을 미치므로 전체 로그인 흐름이 위험에 빠지지 않습니다.

이러한 분해의 아키텍처적 가치는 AI가 아니라 개발자가 판단합니다.

Vibe 코딩 워크플로우에서 뛰어난 개발자가 되기 위한 세 가지 핵심 역량

1. 첫 번째 시도에 가까운 결과를 얻도록 AI에 충분한 컨텍스트, 제약, 방향을 제공하는 능력

   • 이는 사소한 기술이 아니라 연습, 도메인 지식, 모델 동작 이해가 필요한 고급 스킬입니다. 흐릿한 프롬프트는 흐릿한 출력물을 만들게 됩니다.

2. **반복적으로 방향을 조정하는 능력