Spec Driven Development - 바이브 코딩을 더욱 강력하게
(ainativedev.io)들어가기 앞서
Kiro 라는 IDE는 이미 GeekNews에서 다루어 진 적이 있습니다.
다만, 이 Kiro가 지향하는 개발 방법론의 사상인 Spec Driven Development(SDD) 관점으로의 소개가 없었고,
Spec Driven Development를 이해하기 좋은 영상이 게시되어 이를 소개합니다.
Kiro
-
에이전트형 IDE: 자연어로 개발을 돕되, “스펙을 1급 아티팩트”로 두는 편향을 가진 IDE.
-
기존 에이전트 IDE의 “바이브 코딩(vibe coding)” 속도를 살리면서도 결정·가정·제약을 스펙 문서로 정의.
-
워크플로우: 아이디어를 입력하면 곧바로 requirements / design / tasks 3개 파일을 생성 하여 출발. 에디터는 Code OSS 포크 위에 “Specs / Hooks / Steering” 탭을 얹은 형태.
- Specs: 요구사항을 구조화하고(사용자 스토리 + EAR 포맷의 수용 기준), 이후 구현·테스트·변경을 스펙과 연결.
- Hooks: 파일/코드 변화를 감시해 스펙 워크플로우를 트리거.
- Steering: 저장소 루트의 .kiro/에 규칙(markdown)으로 팀 가이드를 체크인—예: TDD 규칙을 넣어 에이전트 동작을 일관화.
Spec Driven의 필요성
-
바이브 코딩의 한계 보완: 채팅 왕복으로 빠르게 코드를 만들면 결정 근거가 채팅 스트림에 묻혀 나중에 “무엇을 왜 만들었는지”가 흐려짐. SDD는 행동(behavior) 중심의 명세를 먼저 세워 안정된 나침반으로 삼게 함.
-
스펙의 정의(행동, 속성, 불변식): 구현이 아니라 시스템이 어떻게 행동해야 하는지를 서술—안전(safety)/진전(liveness) 속성, 불변식 개념을 가져오되, 개발자 친화적 문법으로 접근 가능하게 하려는 철학.
SDD의 장점
-
의사결정 가시화 & 재사용: 스펙이 코드 변경의 “출처”가 되어 리뷰·합의가 쉬워지고, 기능이 바뀌어도 의도(behaviors) 가 남겨짐.
-
조합 가능한 살아있는 스펙: 사용자 시나리오·수용 기준·인터페이스/데이터 계약·성능/SLAs 등을 모듈화해 재사용·합성 가능(서비스→시스템 레벨).
-
SDLC 전반 적용: 요구·설계 앞단 정렬, 배포 후 이슈의 피드백 루프까지—AI 시대 코드 생성 속도 속에서도 리뷰/품질/일관성을 챙기자는 문제의식.
SDD 데모
- Main link 에 게시 된 Video의 데모 시작 시점 Link는 이 url을 참고 : https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085
SDD 흐름
A. 초기 설정
- Project 설정 - Hooks, Steering, MCP
- TDD 설정 (권장)
- Spec 설정 - EAR 형식 기반(권장) Spec 작성 (AI를 통해 기존 프로젝트 분석으로부터 자동 생성 가능)
B. 기능 구현
- Spec 파생 - 새로운 요구사항을 Spec에 반영/갱신
- 가드레일 설정 (권장) - 테스트 스텁, 규칙 작성
- 구현 <-> 테스트 - 이 구간은 대부분 AI를 통해 반복 수행되며, AI가 잘 수정하지 못하는 작은 코드의 수정 정도만 개발자가 개입
- 프로젝트 구성이 완료 된 이후, 'B. 기능구현' 단계의 반복으로 기능 확장
주의 사항
- Spec 문서 품질이 기준 수준에 미치지 못하는 경우 동작 하지 않음.
- 영상 내 Spec 문서 기준 규칙은 자세하게 설명되진 않음. (참고: https://kiro.dev/docs/specs/)
- TDD 사용은 권장이나, TDD가 적용되지 않은 프로젝트들은 대부분 이 방법론으로부터 효과를 느끼지 못했다고 함.
개인 평
- AI를 잘 활용하기 위한 또 다른 시각으로부터 제안 된 방법론 중 하나.
- 항상 '잘' 작성 된 문서는 매우 많은 장점을 가집니다. 단, 상당히 많은 문서들의 유지보수가 잘 되지 못한다는 현실적인 경험에서, 얼마나 많은 사람들로부터의 공감대를 이끌어 낼 수 있는지가 관건인 듯 합니다.
- 현 시점, AI + TDD 개발 전략은 많은 개발자들이 공감하는, 어느정도 검증 된 방법론 입니다. TDD만 독립적으로 사용 된 경우와 SDD가 함께 사용 된 비교를 통해 효과 검증이 된다면 훨씬 더 많은 공감을 받을 수 있을 것으로 생각 됩니다.
방금 spec-kit이라는 SDD 툴킷을 보고 왔는데 여기서도 SDD를 접하네요. https://github.com/github/spec-kit
오 그렇네요. Spec Driven 방법론도 아직 걸음마 단계로 생각이 되고, 그 Spec 또한 발전 해야 할 내용들이 많아 보입니다.
이런 형태의 도구들, 문서들의 공유가 현 시점에 매우 중요 해 보이네요.