[AI 개발자] "더 이상 레거시로 돌아갈 수 없다" AI 시대의 개발 패러다임, SDD(Spec-Driven Development) 실전 가이드
바이브 코딩(Vibe Coding)을 넘어, 견고한 엔지니어링으로 나아가는 '스펙 주도 개발'의 현장
필자는 현업 개발자입니다. 최근 회사에서 진행하는 신규 프로젝트에 SDD(Spec-Driven Development, 스펙 주도 개발) 방법론을 전격 도입하여 개발을 진행하고 있습니다. 아직은 시작 단계이고 업계 표준이 정립되지 않은 과도기적 시기이지만, 직접 몸으로 부딪치며 체득한 SDD의 강력함과 구체적인 워크플로우를 공유하고자 합니다.
결론부터 말씀드리자면, SDD를 경험한 이후 "이제 다시는 레거시 개발 방식(직접 코드를 처음부터 타이핑하는 방식)으로 돌아갈 수 없다"는 확신을 얻게 되었습니다. 본 기고를 통해 단순히 AI에게 코드를 맡기는 것을 넘어, 어떻게 AI를 '통제'하고 '생산성'을 극대화할 수 있는지, 그 구체적인 방법론을 논해보고자 합니다.
1. 왜 지금 SDD(Spec-Driven Development)인가?
AI 코딩 도구의 발전은 놀랍습니다. 챗GPT(ChatGPT), 클로드(Claude), 깃허브 코파일럿(GitHub Copilot) 등은 이제 주니어 개발자 수준, 혹은 그 이상의 코드를 쏟아냅니다. 초기에는 소위 '바이브 코딩(Vibe Coding)'이라 불리는 방식이 유행했습니다. 기분에 따라, 혹은 즉흥적인 프롬프트 입력으로 코드를 생성하고 실행해 보는 방식입니다.
하지만 프로젝트 규모가 커지고 복잡도가 증가하면 '바이브 코딩'은 한계에 봉착합니다. AI가 맥락(Context)을 잃어버리거나, 기존 코드와 충돌하는 코드를 생성하기 시작하기 때문입니다. 여기서 SDD의 필요성이 대두됩니다.
SDD란 코드 작성 전에 명세서(Spec)를 먼저 작성하고, 이 명세서를 AI와 개발자 간의 '단일 진실 공급원(Single Source of Truth)'으로 삼는 접근 방식입니다. 즉, AI에게 "코드를 짜줘"라고 부탁하는 것이 아니라, "이 명세서(Spec)대로 구현해"라고 명령하는 구조입니다.
2. 실전 SDD 워크플로우: PRD부터 윈드서프(Windsurf)까지
현재 필자가 프로젝트에 적용 중인 SDD 프로세스는 다음과 같습니다. 이 과정은 인간의 기획력과 AI의 구현력을 극대화하는 사이클입니다.
Phase 1: 명세의 구체화 (Human + LLM)
개발의 시작은 코딩이 아닌 '글쓰기'입니다. 구현하고자 하는 기능의 대략적인 요구사항을 정리합니다. 이 초안을 가지고 제미나이(Gemini)나 클로드(Claude)와 같은 고성능 LLM에게 전달하여 상세한 PRD(Product Requirements Document, 제품 요구사항 문서) 생성을 요청합니다. 이때 중요한 것은 AI가 개발자의 의도를 명확히 파악하도록 하는 것입니다. 대충 작성된 프롬프트는 엉성한 PRD를 낳고, 이는 곧 버그 덩어리인 코드로 이어집니다.
Phase 2: Task Master AI와 윈드서프의 결합
잘 작성된 PRD가 준비되었다면, 이제 실행 단계입니다. 필자는 윈드서프(Windsurf)와 같은 AI 특화 IDE(통합 개발 환경)를 활용합니다. 여기서 Task Master AI의 역할이 중요합니다. PRD를 바탕으로 전체 개발 타스크를 쪼개고, 윈드서프 내의 AI 에이전트에게 구체적인 지시를 내립니다.
Phase 3: 무한 생성과 폐기의 사이클 (The Cycle of Creation and Discard)
이 부분이 SDD의 핵심이자, 가장 혁신적인 부분입니다. AI에게 PRD를 던져주고 코드를 생성하게 합니다. 그리고 결과를 확인합니다. 만약 결과물이 의도와 다르거나 버그가 있다면? 코드를 수정하지 않습니다. 코드를 버립니다. 그리고 다시 PRD나 프롬프트를 수정하여 AI에게 다시 코딩을 시킵니다. 인간이 엉킨 스파게티 코드를 디버깅하는 것보다, AI에게 명확한 지시를 다시 내려서 새로 짜게 하는 것이 훨씬 빠르고 효율적이기 때문입니다. 올바른 PRD와 결과물이 나올 때까지 이 사이클을 반복합니다.
Phase 4: 라스트 마일 (The Last 5%)
AI가 95% 정도의 완성도를 보일 때, 비로소 개발자가 직접 코드에 개입합니다. AI가 해결하지 못하는 미세한 디테일, 성능 최적화, 비즈니스 로직의 예외 처리 등은 인간 엔지니어의 몫입니다. 이 5%의 개입으로 프로젝트는 완벽해집니다.
3. SDD가 가져온 변화: 버그 수정의 패러다임 시프트
SDD 환경에서는 유지보수와 버그 수정의 개념도 달라집니다. 기존에는 버그가 발생하면 코드를 열어 로그를 찍고 로직을 수정했습니다. 하지만 SDD에서는 "버그가 발생했다는 것은 명세(Spec)가 불완전하다는 것"을 의미합니다.
따라서 우리는 코드를 바로 고치는 대신, 윈드서프에게 현재 상황을 분석하게 하고 PRD 문서를 업데이트하게 합니다. "이런 버그가 발생했으니, PRD의 예외 처리 항목에 이 내용을 추가해"라고 지시하고, 다시 코드를 생성하게 합니다. 이렇게 하면 명세서와 코드가 항상 동기화(Sync) 되며, 문서가 낡은 유물로 남는 것을 방지할 수 있습니다. 이것이 바로 Spec-Anchored(명세 보존) 방식의 개발입니다.
4. 아직 정답은 없다: 표준을 향한 여정
물론 SDD는 만능열쇠가 아닙니다. 앞서 언급한 참고 자료들(Kiro, Spec-Kit, Tessl 등)에서도 지적하듯이, 작은 버그 수정에 과도한 프로세스가 소요될 수 있고, 마크다운(Markdown) 문서 관리가 코드 관리보다 번거로울 수도 있습니다.
무엇보다 가장 큰 어려움은 "표준 문서(Standard Documentation)의 부재"입니다. 어떻게 PRD를 작성해야 AI가 가장 잘 알아듣는지, 어떤 단위로 Task를 쪼개야 효율적인지에 대한 정답이 아직 없습니다.
필자 역시 프로젝트를 진행하며 무수히 많은 시행착오를 겪고 있습니다. AI가 PRD를 무시하고 환각(Hallucination)을 일으킬 때도 있고, 너무 긴 컨텍스트 때문에 멍해질 때도 있습니다. "이 정도까지 명세를 줬는데 안 된다고?"라며 답답해하는 순간도 있습니다.
하지만 이 과정 자체가 자산이 됩니다. 우리 팀은 프로젝트를 진행하며 우리만의 'SDD 표준 문서'를 만들어가고 있습니다. 이 표준이 정립되면, 다음 프로젝트, 그다음 프로젝트에서는 압도적인 속도로 개발을 진행할 수 있을 것입니다.
5. 결론: 개발자는 이제 '아키텍트'이자 '감독관'이다
SDD 시대에 개발자의 역할은 '코더(Coder)'에서 '아키텍트(Architect)'이자 '감독관(Supervisor)'으로 변모하고 있습니다. 직접 벽돌을 쌓는 일은 AI에게 맡기고, 우리는 건물의 설계도가 올바른지, AI가 설계도대로 시공하고 있는지를 감리해야 합니다.
생산성은 비교할 수 없을 정도로 높아졌습니다. 레거시 방식으로 돌아가는 것은 이제 상상할 수 없습니다. 지금 SDD를 시작하는 것은 단순한 도구의 도입이 아니라, 미래의 개발 문법을 배우는 과정입니다. 비록 지금은 거칠고 다듬어지지 않은 길일지라도, 이 길이 곧 고속도로가 될 것임을 확신합니다.
이제 우리는 AI가 없는 개발 시절로 못돌아간다. 래거시로는 못간다.