노코드 라이브러리에서 얻은 교훈: 스펙 주도 개발, 방정식이 아닌 삼각형이다
(dbreunig.com)AI 코딩 에이전트 시대에서 스펙 주도 개발(Spec-Driven Development) 을 단순히 “스펙 → 코드”라는 직선 방정식으로 보는 건 잘못된 관점이라는 내용.
핵심 주장
스펙 주도 개발은 정적인 방정식이 아니라 동적인 삼각형.
세 축이 끊임없이 서로 영향을 주고받는 피드백 루프:
- 스펙 (Spec)
- 코드 (Code)
- 테스트 (Tests)
이 세 요소가 서로 동기화(sync)되어야만 제대로 작동.
주요 사례와 실험
- Drew Breunig이 만든 코드 없는 라이브러리 whenwords
→ 코드 없이 스펙(Markdown) + 750개 테스트(YAML)만 올려놓고 AI 에이전트가 코드를 생성하게 함
→ Andrej Karpathy 관심 + GitHub 1k+ 스타 + 활발한 기여 발생
하지만 이런 실험들에서 반복되는 문제:
- 구현은 빠른데, 복잡도가 조금만 올라가면 한 부분 고치면 다른 부분 깨짐
- 결국 대부분 프로젝트가 미완성으로 사장됨
- 스펙이 아무리 좋아도 구현 방식 논쟁이 계속됨
왜 삼각형인가?
코드를 만들다 보면 → 스펙의 모호함/오류 발견 → 스펙 수정 → 새로운 테스트 필요 → 코드 다시 수정 → …
→ 이 과정이 끊임없이 반복되는 루프이기 때문.
해결 방향 제안: Plumb 도구
Drew가 만든 CLI 도구 Plumb
- Git 커밋할 때마다 에이전트 대화 로그 + 코드 변경 분석
- 에이전트가 암묵적으로 내린 결정들을 추출 → 개발자가 승인
- 승인된 결정 → 스펙 자동 업데이트
- 스펙/테스트 커버리지 갭 리포트 제공
→ “커밋 실패 모드”로 중요한 결정은 무조건 사람 검토하게 강제
역사적 맥락
지금은 1960년대 ‘소프트웨어 위기’를 다시 겪는 중.
당시는 코드가 너무 커져서 머릿속에 못 담음 → 워터폴·애자일·CI/CD 탄생
지금은 코드 읽기조차 불가능해짐 → 새로운 프로세스 필요
→ Plumb 같은 도구가 그 방향성을 제시한다는 주장.
결론 한 줄
AI가 코드를 엄청 빠르게 뽑아내는 시대지만,
진짜 어려운 건 스펙-코드-테스트 삼각형을 계속 동기화하는 일이다.