실제로 작동하는 Vibe 코딩 방법

Source: Dev.to

Source: …

📍 엔지니어링 현황

이미 여러 번 들어보셨겠지만, 소프트웨어 엔지니어가 AI 시스템, 에이전트, 도구들에 의해 대체될 것이라는 이야기가 있습니다.

이 주제에 대해 너무 많이 언급하진 않겠습니다. 아직 명확히 정리된 것이 없기 때문이죠. 하지만 업계에서는 이미 몇 가지 예측·현상이 나타나고 있습니다:

1️⃣ 작은 팀이 매우, 매우 효율적·생산적으로 변하고 있습니다.
2️⃣ 단순히 기술이 뛰어나거나 똑똑한 사람보다 주도권과 의도를 가진 사람이 선호됩니다.
3️⃣ 기업은 이전보다 훨씬 빠르게 움직일 것입니다.
4️⃣ 소프트웨어가 스스로 만들어지고 있습니다.

😳 사례

• Claude Code 은 Claude를 사용해 구축되고 있습니다.
• Traycer 은 Traycer AI를 사용해 구축되고 있습니다.

모든 조직에 공통적으로 관계 없는 것이 하나 있습니다:

❓ AI를 사용할 것인가?
중요한 것은 어떻게 AI를 사용할 것인가입니다.

많은 사람들이 자신이 ‘바이브 코딩’(Vibe Coding)을 하고 있는지, AI‑보조 코딩(AI‑Assisted Coding)을 하고 있는지 모릅니다. 바이브 코딩과 AI‑보조 코딩 사이에는 큰 차이가 있습니다.

📍 일반적인 바이브 코딩 방식

Vibe‑coding 워크플로우는 일반적으로 다음과 같습니다:

• 에이전시 기능을 갖춘 IDE(예: Cursor, Windsurf) 또는 Claude Code, Gemini CLI와 같은 CLI 에이전트가 있습니다.
• 채팅 창에 프롬프트를 입력합니다.
• 에이전트가 프롬프트를 읽고, 계획을 세운 뒤 코드를 생성하기 시작합니다.

이 방법은 매우 작은 기능을 구현하거나 처음부터 시작할 때 효과적입니다. 그 이유는 다음과 같습니다:

• 에이전트를 새 컨텍스트/인스턴스로 시작하면 일정 시간 동안 잘 작동합니다.
• 코드를 계속 생성하면 에이전트가 처음에 제시한 의도에서 점점 벗어나기 시작합니다.
• 작고 단순한 기능은 Claude, Grok 등 대부분의 LLM 모델로 구현할 수 있습니다.

📍 실제로 문제가 발생할 때는?

누군가 더 큰 코드베이스, 복잡한 기능, 혹은 엔드‑투‑엔드 제품 작업을 시작하면, 에이전트가 어려움을 겪는 이유는 다음과 같습니다:

• 인간이 제공한 프롬프트나 의도에서 벗어나게 됩니다.
• 컨텍스트 윈도우가 가득 차면서 성능이 저하됩니다.
• 검증 루프 없이 자신감 있게 환상이 나타납니다.

👉 이 때문에 사용자는 수천 줄의 코드를 생성하지만 아무 것도 동작하지 않음을 깨닫게 됩니다. 해당 코드베이스를 리팩터링하는 일은 매우 번거로운 작업이 되어 많은 반복을 초래합니다.

이러한 고군분투는 겉보이는 생산성 향상, 많은 반복, 그리고 두통을 만들어냅니다.

그렇다면 우리는 코딩을 어떻게 접근해야 할까요?

아니요, 위 그림은 여러분이 코딩하는 방식을 의미하는 것이 아닙니다 🤪

코딩은 여전히 구조가 승리하는 기본적인 문제 해결 방법이며, 많은 코드‑생성 LLM이 등장한 이후에도 마찬가지입니다. 기본 원칙을 사용한 과정은 다음과 같습니다:

1. PRD(제품/기능 요구사항 문서)를 작성합니다.
2. PRD를 사양으로 나눕니다.
3. 기술 문서를 만들고 하위 작업을 정의합니다.
4. 하위 작업을 팀에 할당하여 실제 코딩을 진행하게 합니다.
5. 구현을 검증합니다.

여기서 내부 루프가 문제를 해결합니다: 코드 생성.

하지만 놓친 부분이 있다는 것을 눈치채셨나요?

네, 바로 그 부분입니다 – 외부 루프.

📍 The Outer Loop

LLM이 완전하게 코딩을 수행하지 못하게 하는 빠진 조각들은 다음과 같습니다:

1️⃣ PRD 작성하기.
2️⃣ PRD를 스펙으로 나누기.
3️⃣ 기술 문서를 만들고 그에 따라 서브‑태스크를 생성하기.
⚠️ 서브‑태스크를 팀에 할당하기 (inner loop 또는 LLM 사용).
4️⃣ 구현을 검증하기.

여기서 새로운 분야가 빛을 발합니다 – Spec‑Driven Development.

많은 제품들이 스펙‑드리븐 개발을 해결하려 하고 있으며, 이는 PRD를 생성하고, 계획을 잘 세우며, 각 에이전트의 코드 단계를 검증하고, 에이전트가 사용자의 의도에서 벗어나지 않도록 방지합니다. 이 분야의 제품으로는 Traycer, Kiro, Spec‑kit 등이 있습니다.

내 친구들은 Traycer 의 EPIC 모드와 같은 기능이 매우 직관적이라서 열광하고 있습니다.

Traycer가 아직 다른 어떤 제품도 해결하지 못한 문제들

• 일반적인 간단 프롬프트만으로 인간의 의도를 포착합니다.
• 에이전트가 의도에서 벗어나는 것을 방지합니다.
• 토큰 사용량을 줄이고 컨텍스트 부풀림을 방지합니다.
• 각 변경 사항을 검증하여 자신 있게 환상을(허위 코드를) 배포하지 않게 합니다.

Traycer AI EPIC 모드가 어떻게 보이는지 살짝 엿보기

Traycer AI는 이제 제 파트너입니다. 단순한 에이전트가 아니라 제 시니어 엔지니어처럼 행동하기 때문이죠. 몇 가지 주요 기능을 강조하면:

• 간단한 프롬프트로 시작합니다.
• 그런 다음 문제 상황에 대해 인터뷰를 진행합니다.

개요

• 고수준 질문 – 제품 비전, 목표 청중, 시장 적합성, 기술 스택, 엣지 케이스 및 기타 전략적 고려사항.

• 생성된 산출물 – PRD, 사양서, 기술 흐름도, 와이어프레임, 시퀀스 다이어그램 및 사용자 흐름 다이어그램.

• 티켓 분해 – 계획을 더 작은 티켓으로 나누어 어떤 AI 에이전트(예: Claude, Grok, Cursor IDE 등)에게도 전달할 수 있습니다.

• 검증 – 각 변경 사항을 검증하여 에이전트가 잘못된 방향으로 흐르거나 벗어나지 않도록 합니다.

📍 최근에 출시한 제품 예시:

• 자체 Redis 구축.
• 메시지 전체에 대한 의미 검색을 지원하는 나만의 WhatsApp 구축.
• 그리고 우리가 구축하고 있는 더 많은 프로젝트들, EPIC 모드에 빠져 사랑하고 있습니다 ❤️