VSDD: 실제로 가져가도 좋은 AI 코딩 방법론

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, code blocks, and URLs.

개요

오늘 해커 뉴스에서 주목받고 있는 방법론인 Verified Spec‑Driven Development (VSDD) 가 있습니다. 이 방법론은 130점 이상을 얻었고 수십 개의 댓글이 달렸으며, 이번에는 토론이 실제로 유용합니다. 저는 전체 사양을 읽어보았습니다. 여기서 진정으로 좋은 점과, 빠르게 움직이는 개발자들이 즉시 도입해야 할 한 가지를 소개합니다.

VSDD의 핵심 구성 요소

1. Spec‑Driven Development – 코드를 작성하기 전에 계약을 작성합니다. 사양이 진실의 원천입니다.
2. Test‑Driven Development – 구현보다 테스트가 먼저입니다. Red → Green → Refactor.
3. Adversarial Verification – 별도의 AI “리뷰어”가 사양과 코드를 철저히 검토하여 결함을 찾아냅니다.

순차적 게이트

이것은 경쟁적인 철학이 아니라 순차적 게이트입니다:

• 사양이 완벽해질 때까지 테스트로 이동할 수 없습니다.
• 테스트가 존재할 때까지 코딩으로 이동할 수 없습니다.
• 실제 결함을 찾지 못하는 적대적인 검토자가 나타날 때까지 배포할 수 없습니다.

인간과 AI의 역할

• Human – The Architect: 전략적 비전, 도메인 전문 지식 및 최종 권한을 제공합니다.
• AI Builder: 사양과 테스트를 기반으로 코드를 구현합니다.
• AI Adversary: 하이퍼‑비판적인 검토자로 작동하는 두 번째 별도 AI 인스턴스입니다.

왜 사양‑우선이 중요한가

사양‑우선 원칙은 진정한 통찰이다 — 새롭지는 않지만 AI가 이를 새롭게 강제할 수 있게 만들었다.

• 직접 코드를 작성할 때는 뇌가 빈틈을 메워 주기 때문에 애매하게 써도 된다.
• 작업을 AI 에이전트에게 넘길 때는 애매함이 치명적이다: 에이전트가 빈틈을 자신 있게, 빠르게, 그리고 종종 잘못 채워 버린다.

먼저 행동 계약(전제조건, 사후조건, 엣지 케이스, 실패 모드)을 작성하도록 스스로 강요하는 것은 부가 비용이 아니라 작업 자체이다. 그 후 구현은 거의 기계적으로 이루어진다.

이는 최고의 AI‑네이티브 빌더들이 실제로 하는 방식과 일치한다. 그들은 “결제 시스템을 만들어줘”라고 입력하지 않는다. 시스템이 해야 할 일, 절대 해서는 안 될 일, 그리고 실패했을 때 일어나는 일을 설명하는 세 단락을 작성한 뒤 에이전트에 전달한다. 출력 품질 차이는 미미한 것이 아니라 한 단계(한 차원) 차이이다.

실용적인 적용

내가 이전에 공식화된 것을 보지 못했던 부분: 새 컨텍스트를 가진 별도의 AI 인스턴스를 초비판적인 리뷰어로 사용하는 것.

• Builder AI는 결정이 왜 내려졌는지에 대한 컨텍스트를 가지고 있습니다.
• Adversary AI는 전혀 없으며—오직 결과물만을 봅니다. 이는 실제 코드 리뷰와 유사합니다: 동료는 구현 과정이 아니라 결과가 타당한지만 신경 씁니다.

실제 적용

1. Claude(또는 다른 모델)를 사용해 사양과 구현을 작성합니다.

2. 아래 프롬프트와 함께 새 Gemini 세션에 붙여넣습니다:

   You are a hyper‑critical senior engineer. Find every flaw, ambiguity, and missing edge case. Do not be polite.

결과는 실제로 유용합니다. adversary는 당신이 고의적이면서도 정당화되지 않은 선택을 했기 때문에 놓친 사항들을 정확히 잡아냅니다.

전체 VSDD 파이프라인

• 에픽 → 이슈 → 서브‑이슈(“비드”)
• 형식 검증 전략
• 속성에 대한 수학적 증명

이는 실패할 수 없는 프로덕션 시스템을 배포하는 팀을 위해 구축되었습니다.

솔로 창업자를 위한 조언

아이디어를 검증하는 솔로 창업자라면, 그 오버헤드는 당신을 망칠 것입니다. 스펙 규율을 훔치세요. 절차는 건너뛰세요.

대부분의 가치를 포착하기 위한 구체적인 단계

1. AI 코딩 세션을 시작하기 전에, 다음을 포함하는 5‑10문장을 작성하세요:
   • 기능이 하는 일
   • 기능이 절대 하지 않는 일
   • 가장 가능성이 높은 세 가지 실패 모드
2. 그 내용을 AI 에이전트에게 컨텍스트로 전달하세요.
3. 코드가 생성되면, 새 AI 세션에 붙여넣고 가능한 가장 혹독한 비판을 요청하세요.
4. 실제 문제는 수정하고, 순수 이론적인 것은 무시하세요.

이 단계들은 노력의 20 %로 VSDD 가치의 약 80 %를 제공합니다.

마무리 생각

VSDD가 가리키는 것은—전체 방법론이 대부분의 개인 개발자에게는 너무 무겁더라도— “AI가 코드를 작성할 수 있는가”에서 “AI에게 정확히 무엇을 만들지 말할 수 있는가”로의 전환이다. 병목 현상은 이제 구현이 아니라 사양이다.

앞으로 2년 안에 성공할 개발자는 프롬프트를 가장 잘하는 사람이 아니다. 그들은 자신이 실제로 만들고자 하는 것을 가장 명확하게 생각하고—에이전트가 잘못 즉흥적으로 행동할 여지가 없도록 충분히 정확하게 적어낼 수 있는 사람—이다. 이러한 능력은 어떤 프레임워크보다도 더 가치가 있다.

라틴아메리카 중소기업을 위한 AI 제품 구축. 사양‑우선 접근 방식: rooxai.com