노코드 라이브러리에서 얻은 교훈: 스펙 주도 개발, 방정식이 아닌 삼각형이다

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가 코드를 엄청 빠르게 뽑아내는 시대지만, 진짜 어려운 건 스펙-코드-테스트 삼각형을 계속 동기화 하는 일이다. https://aisparkup.com/posts/9837