클로드코드 SDD 전환기, superpowers·우로보로스 병행이 어려운 이유

바이브 코딩이 만든 빚이 쌓이면서 2026년 AI 코딩 업계는 "명세(스펙)가 코드보다 먼저"라는 말을 약속이나 한 듯 반복하고 있다. GitHub Spec Kit, AWS Kiro, Claude Code 커스텀 워크플로우까지 저마다의 스펙 주도 개발(SDD, Spec-Driven Development) 방식을 내놓았고 오픈소스 진영에서도 superpowers와 우로보로스(Ouroboros) 같은 서드파티 프레임워크가 같은 자리를 두고 갈린다. 클코단에서는 기존 테스트 주도 개발(TDD) 워크플로우가 AI 에이전트에게 오히려 병목이 될 수 있다는 문제의식에서 SDD 전환을 검토하던 중, 이 두 프레임워크를 함께 쓸 수 있는지가 화두로 올랐다. 결론부터 말하면 두 도구는 담당 구간이 겹쳐 동시 사용이 까다롭다는 게 중론이었다.

왜 지금 SDD인가

바이브 코딩은 테스트도, 계획도 없이 "이렇게 만들어줘"라고 던지면 AI가 코드를 뱉고 사람은 눈으로 훑어본 뒤 배포하는 방식이다. 작동할 때는 빠르지만 문제가 생기면 무엇이 왜 깨졌는지 추적할 근거가 없다. 2025년 이후 업계가 지목한 실패 패턴은 크게 세 가지다. 모호한 지시("로그인 추가해줘")에 모델이 임의로 기본값을 채워 넣는 의도 이탈(intent drift), 코드베이스가 커지면서 에이전트가 예전 결정을 잊고 스스로 모순을 만드는 컨텍스트 붕괴, 그리고 이 둘이 누적되며 발생하는 품질 저하다. SDD는 "스펙이 원본이고 코드는 그 표현물"이라는 전제로 이 문제에 대응한다. 요구사항을 먼저 문서화하고 그로부터 설계와 작업 목록을 도출한 뒤에야 코드를 생성한다. 2026년 현재 GitHub Spec Kit, AWS Kiro, Cursor, OpenSpec, BMAD, Tessl, Google Antigravity까지 주요 AI 코딩 도구가 저마다의 SDD 변형을 내놓은 상태다. 다만 TDD가 AI 시대에 무용해졌다는 뜻은 아니다. 오히려 AI 에이전트가 검증되지 않은 구현을 정당화하는 테스트를 스스로 작성해버리는 것을 막는 안전장치로 TDD가 유효하다는 반론도 만만치 않다. 방 논의는 "기존 워크플로우가 AI에게는 병목일 수 있다"는 문제의식에서 출발했는데, 이는 아직 업계에서도 결론이 갈리는 지점이라는 점을 감안할 필요가 있다.

superpowers: 스킬이 스스로 발동하는 방법론

superpowers는 Jesse Vincent(obra)가 만든 에이전틱 스킬 프레임워크로, 현재 깃허브에서 가장 많은 스타를 받은 Claude Code 스킬 저장소로 꼽힌다. 브레인스토밍, TDD, git worktree 활용, 서브에이전트 기반 개발, 코드 리뷰, 스킬 저작까지를 조합 가능한 스킬로 제공하며 공식 Anthropic 플러그인 마켓플레이스(`/plugin install superpowers@claude-plugins-official`)를 통해 설치할 수 있다. 실제 작업 흐름은 브레인스토밍(소크라테스식 질문으로 요구사항을 좁히고 날짜가 찍힌 설계 문서를 만든 뒤 자체 검토와 사용자 검토를 거침) → git worktree 생성 → 플랜 작성 → 서브에이전트가 TDD로 구현 → 별도 에이전트의 코드 리뷰 → 브랜치 마무리 순으로 이어진다. 특징은 각 단계가 스킬로 묶여 있고 별도로 호출하지 않아도 상황에 맞춰 자동으로 발동한다는 점이다. 브레인스토밍 스킬은 코드 작성 전 반드시 거치도록 강제돼 있어, 방 논의에서 언급된 "브레인스토밍 스킬이 발동하면 강제로 쓰인다"는 경험과도 일치한다. 다만 스펙과 플랜 검토는 자동화돼 있지 않다. 저장소 이슈 문서에도 스펙·플랜 리뷰 게이트가 "가장 중요한 사람 체크포인트"로 명시돼 있어, 결국 사람이 직접 승인해야 다음 단계로 넘어간다.

우로보로스: 인터뷰에서 진화까지

우로보로스는 개발자 Q00이 만든 "Agent OS"로, "프롬프팅을 멈추고 명세를 시작하라"는 슬로건을 내건다. 비결정적인 에이전트 작업을 재생 가능하고 관찰 가능한 실행 계약으로 바꾸는 로컬 우선 런타임을 표방하며 워크플로우는 인터뷰(소크라테스식 질문으로 숨은 전제를 드러냄) → 크리스탈라이즈(답변을 모호성 점수까지 매겨 불변의 스펙으로 굳힘) → 실행(더블 다이아몬드 방식으로 작업을 분해해 수행) → 평가(기계적·의미적·합의 3단계 검증) → 진화(평가 결과가 다음 사이클의 입력이 됨)로 이어진다. Claude Code와 Codex CLI, OpenCode, Gemini, Kiro 등 여러 에이전트 하네스에서 동작하도록 설계됐다. 다만 방 논의에서는 이 흐름 중 인터뷰부터 평가까지의 설계는 정교한 반면 실제 구현(코드 생성) 부분은 상대적으로 부실하다는 평가가 나왔는데, 이는 사용자 체감이지 공식적으로 검증된 사실은 아니다. 프로젝트 측이 자체 발표한 Terminal-Bench 2.1 등 벤치마크 성적 역시 제3자 검증을 거치지 않은 자체 보고 수치라는 점은 참고할 필요가 있다.

왜 같이 쓰면 부딪히나

두 프레임워크를 나란히 놓고 보면 겹치는 구간이 뚜렷하다. superpowers의 브레인스토밍과 우로보로스의 인터뷰는 둘 다 "요구사항을 사람에게 캐물어 스펙으로 만드는" 같은 역할을 한다. superpowers의 플랜 작성·리뷰와 우로보로스의 크리스탈라이즈·평가 역시 사실상 같은 자리를 놓고 경쟁한다. Claude Code의 스킬 시스템은 각 스킬에 붙은 설명(description)을 보고 상황에 맞는 스킬을 자동으로 골라 발동하는 구조인데, 두 스킬이 비슷한 트리거 조건을 갖고 있으면 어느 쪽이 먼저 개입할지 예측하기 어려워지고 결과도 들쭉날쭉해진다. 이 문제를 완화하려고 최근 Claude Code에는 스킬을 사람이 직접 호출할지, 에이전트가 알아서 판단해 호출할지를 나누는 옵션이 추가되기도 했지만 애초에 역할이 겹치는 두 방법론을 함께 설치해 쓰는 상황 자체를 근본적으로 해결해주지는 않는다. 방 논의에서도 두 도구를 동시에 쓰면 워크플로우가 충돌한다는 의견이 우세했고 하나만 골라 실제로 써보라는 권고로 정리됐다.

결국 검증은 사람의 몫

프레임워크가 무엇이든 스펙과 플랜을 최종 승인하는 주체는 여전히 사람이라는 점은 공통적이다. GitHub도 Spec Kit 문서에서 "개발자의 역할은 코더가 아니라 각 체크포인트에서 검증하는 관제탑"이라고 못박고 있고 superpowers 역시 스펙·플랜 리뷰를 사람이 직접 하도록 설계돼 있다. AI가 스펙 작성이나 코드 생성 속도를 아무리 끌어올려도, "이 스펙이 내가 원하는 것이 맞는가"를 판단하는 지점만큼은 자동화되지 않은 셈이다. 이런 맥락에서 SDD 전환은 TDD를 버리는 것이라기보다, 사람이 검증해야 할 지점을 "코드 리뷰"에서 "스펙·플랜 리뷰"로 앞당기는 작업에 가깝다.

정리

SDD가 2026년 AI 코딩의 주류로 자리 잡으면서 선택지도 늘었다. 그린필드 프로젝트에는 가이드가 촘촘한 Kiro나 Spec Kit이, 기존 코드베이스를 다루는 브라운필드 작업에는 가볍게 커스터마이즈할 수 있는 Claude Code 스킬 기반 도구가 더 맞는다는 평가가 많다. superpowers와 우로보로스처럼 둘 다 "인터뷰→스펙→검증" 구간을 스스로 처리하려는 프레임워크는 겹치는 순간 워크플로우 충돌로 이어지기 쉬우므로, 함께 설치하기보다 하나를 골라 프로젝트에 맞는지 먼저 검증해보는 편이 실용적이라는 게 방 논의의 결론이었다.