Change Propagation: SDD’s Central Unsolved Challenge

🖼️ 인포그래픽

Change Propagation: SDD’s Central Unsolved Challenge 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 SDD에서 오래된 문서가 AI 에이전트의 잘못된 코드 생성으로 직결되며, 변경 사항을 관련 스펙 전체로 전파하는 문제가 아직 해결되지 않았다고 주장한다.

📌 핵심 요약

SDD 프레임워크는 요구사항, 아키텍처, 설계 결정이 담긴 문서를 AI 에이전트의 지시서로 사용하지만, 문서가 오래되면 에이전트는 그 오류를 그대로 구현한다.
사람 개발자는 코드와 문서가 어긋난 상황을 감지하고 판단할 수 있지만, AI 에이전트는 스펙을 기준으로 움직이기 때문에 낡은 패턴이나 폐기된 제약을 다시 코드에 반영할 수 있다.
요구사항 변경, 구현 중 발견되는 불필요한 제약, 스펙에 없던 합리적 구현 선택이 장기 문서로 되돌아가지 않으면서 문서와 코드의 드리프트가 누적된다.
BMAD, GSD, Spec Kit, Superpowers, Kiro 같은 도구들은 보정 흐름이나 단계 조정, 스펙 갱신 기능을 제공하지만 실제 변경 전파는 불완전하고 사용자의 수작업 부담이 크다고 설명한다.
글의 결론은 SDD가 단순 프로토타이핑을 넘어 지속 가능한 개발 방식이 되려면 자동 드리프트 감지, 점진적 스펙 업데이트, 구현 결과를 스펙으로 되돌리는 피드백 구조를 프레임워크가 제공해야 한다는 것이다.

🧩 주요 포인트

SDD 프레임워크는 요구사항, 아키텍처, 설계 결정이 담긴 문서를 AI 에이전트의 지시서로 사용하지만, 문서가 오래되면 에이전트는 그 오류를 그대로 구현한다.
사람 개발자는 코드와 문서가 어긋난 상황을 감지하고 판단할 수 있지만, AI 에이전트는 스펙을 기준으로 움직이기 때문에 낡은 패턴이나 폐기된 제약을 다시 코드에 반영할 수 있다.
요구사항 변경, 구현 중 발견되는 불필요한 제약, 스펙에 없던 합리적 구현 선택이 장기 문서로 되돌아가지 않으면서 문서와 코드의 드리프트가 누적된다.
BMAD, GSD, Spec Kit, Superpowers, Kiro 같은 도구들은 보정 흐름이나 단계 조정, 스펙 갱신 기능을 제공하지만 실제 변경 전파는 불완전하고 사용자의 수작업 부담이 크다고 설명한다.
글의 결론은 SDD가 단순 프로토타이핑을 넘어 지속 가능한 개발 방식이 되려면 자동 드리프트 감지, 점진적 스펙 업데이트, 구현 결과를 스펙으로 되돌리는 피드백 구조를 프레임워크가 제공해야 한다는 것이다.

🧠 상세 정리

1. 오래된 문서가 곧 잘못된 코드가 되는 구조

글은 SDD 프레임워크가 명확한 흐름을 따른다고 설명한다. 만들고 싶은 것을 문서로 설명하고, AI 에이전트가 계획과 구현을 수행하며, 결과를 검증한 뒤 다음 단계로 넘어가는 방식이다. 이때 문서는 아키텍처, 요구사항, 설계 결정을 담은 지시서 역할을 한다. 문제는 문서가 정확할 때만 이 구조가 잘 작동한다는 점이다. 문서가 틀리면 에이전트는 그 틀린 내용을 그대로 따라 구현하고, 결과적으로 잘못된 문서가 말 그대로 잘못된 코드를 만든다.

2. 사람 개발자와 AI 에이전트의 차이

저자는 사람 개발자와 AI 에이전트가 오래된 문서를 대하는 방식이 다르다고 강조한다. 사람은 문서가 코드베이스와 맞지 않는다는 신호를 읽고, 최근 변경이나 팀의 실제 방향을 바탕으로 조정할 수 있다. 반면 AI 에이전트는 스펙이 말하는 내용을 중심으로 움직이며, 지난 스프린트의 결정 변화나 문서의 어색함을 스스로 감지하지 못한다. 예를 들어 아키텍처 문서가 이미 버린 패턴을 여전히 설명하면, 에이전트는 그 버린 패턴을 다시 구현한다. 요구사항에 폐기된 제약이 남아 있으면, 에이전트는 그 낡은 제약을 새 코드에 다시 강제한다.

3. 문서 드리프트가 반복적으로 생기는 이유

글은 문서를 최신 상태로 유지하는 일이 단순한 관리 문제가 아니라고 말한다. 소프트웨어를 만드는 과정에서는 이해관계자가 초기 결과를 보고 요구사항을 바꾸거나, 구현 중에 기존 설계가 불필요하다는 사실이 드러나는 일이 자연스럽게 발생한다. 하지만 SDD에서는 하나의 요구사항 변경이 코드 수정에 그치지 않고 아키텍처, 요구사항 문서, 단계 계획, 스토리 파일 등 여러 문서에 동시에 반영되어야 한다. 이 중 하나라도 빠지면 낡은 결정이 다음 작업의 입력으로 살아남는다. 그 결과 이후 에이전트가 오래된 제약을 다시 읽고 구현하면서 드리프트가 점점 커진다.

4. BMAD 사례와 구현 중 발견되는 변화

저자는 BMAD를 사용하며 겪은 비기능 요구사항 사례를 제시한다. 프레임워크는 요청 처리 시간을 몇 밀리초로 제한할지 같은 NFR을 앞에서 정하도록 요구했지만, 실제 구현 중 해당 요청이 성능에 민감하지 않아 그 제약이 필요 없다는 사실을 알게 되었다. 저자가 에이전트에게 그 NFR을 제거하라고 하자 요구사항과 테스트에서는 사라졌지만, 검증 단계에서 다시 누락 요구사항처럼 나타났다. 이는 변경이 한 문서에는 반영되었지만 다른 참조 위치까지 전파되지 않았기 때문이다. 저자는 구현을 해봐야만 확인 가능한 엣지 케이스, 통합 문제, 실제 성능 수치가 있으며, 이런 발견이 대화나 작업 요약에 머물고 장기 문서로 돌아가지 않는다고 지적한다.

5. 기존 SDD 도구들의 전파 기능 한계

글은 주요 SDD 프레임워크들이 문서가 오래될 수 있다는 문제를 알고 있으며 각자 대응 방식을 제공한다고 정리한다. BMAD에는 course-correction workflow가 있고, GSD는 마일스톤 중간에 단계를 넣거나 뺄 수 있으며, Spec Kit은 스펙을 업데이트하고 재생성하라고 안내한다. Superpowers는 단계 전환 시 사람의 체크포인트를 두고, Kiro는 스펙 변경을 하위 작업으로 전파하기 위한 Refine 및 Update Tasks 흐름을 제공한다. 그러나 저자는 실제로는 이런 기능들이 광고처럼 작동하지 않는다고 본다. BMAD는 진짜 문제와 낡은 문제를 섞어 보여주고, Spec Kit은 요구사항 하나만 부분적으로 고치는 대신 전체 재생성을 요구하며, Kiro의 전파도 신뢰하기 어렵다고 설명한다.

6. 사용자 규율이 아니라 프레임워크가 풀어야 할 공학 문제

저자는 변경 전파가 사용자의 문서 관리 습관만으로 해결될 수 없다고 결론짓는다. 도구가 멈추는 지점에서는 사용자가 매 변경 뒤 어떤 문서를 고쳐야 하는지 직접 추적해야 하고, 이를 모든 단계에서 일관되게 수행해야 한다. 그러나 기능은 이미 작동하는데 문서 정리는 시간, 토큰, 정신적 노력을 요구하므로 실제 개발 압박 속에서 뒤로 밀리기 쉽다. 글은 Scott Logic이 Spec Kit을 테스트하며 명세 작성과 검토에는 시간이 오래 걸렸지만 코드 생성은 몇 분이면 끝났다고 한 점도 언급한다. 결국 AI로 코딩 속도는 빨라졌지만 병목은 명세, 검토, 의사결정, 변경 전파로 이동했으며, SDD가 성숙하려면 코드에서 스펙으로 되돌아가는 자동 피드백을 갖춰야 한다고 주장한다.

🧾 핵심 주장 / 시사점

SDD에서 문서는 단순 보조 자료가 아니라 AI 에이전트의 실질적 입력이므로, 문서 드리프트는 생산성 문제가 아니라 정확성 문제로 다뤄져야 한다.
변경 전파를 사용자의 성실함에 맡기면 요구사항과 구현이 계속 어긋나기 때문에, 프레임워크 차원의 자동 드리프트 감지와 점진적 스펙 갱신이 핵심 과제가 된다.
글의 핵심 반전은 SDD가 스펙을 코드로 바꾸는 쉬운 문제는 어느 정도 풀었지만, 구현 결과와 새로 발견한 사실을 다시 스펙으로 되돌리는 어려운 문제는 아직 열려 있다는 점이다.

✅ 액션 아이템

낡은 스펙은 AI 에이전트가 그대로 실행 지침으로 오인하는 경향이 커 문서의 유효기간과 담당 범위를 정해 갱신 주기를 고정한다.
요구사항 변경이나 구현 중 발견된 불필요한 제약, 대체 구현 선택의 근거를 스펙 반영 경로에 즉시 반영해 문서와 코드 간 드리프트 누적을 줄인다.
BMAD·GSD·Spec Kit·Superpowers·Kiro의 보정 흐름을 실행 전후로 비교해 변경 전파가 끊기는 구간을 찾아 최소 자동화 영역부터 순차적으로 강화한다.