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가 함께 사용 된 비교를 통해 효과 검증이 된다면 훨씬 더 많은 공감을 받을 수 있을 것으로 생각 됩니다.
추가 개인 의견으로, SDD 목적 하나만을 위해 IDE 변경(KIRO)이 강요되는것은 다소 과한 요구라 생각 됩니다.
개인적으로는 보조 도구로서 IDE extension, 보조 어플리케이션 혹은 cli 정도의 형태가 적당하지 않을까 싶은데요.
여러분들이 알고 계시는 SDD 도구 정보들을 공유 해 주시는 것도 참고 하시는 분들께 큰 도움이 되지 않을까 싶습니다.
방금 spec-kit이라는 SDD 툴킷을 보고 왔는데 여기서도 SDD를 접하네요. https://github.com/github/spec-kit