개념한 문장
명세를 먼저 쓰고 코드를 만든다
SDD는 명세를 먼저 정확히 쓰고, 그 명세로부터 코드를 생성하는 방식입니다. 1-3의 다듬기 루프를 문서 기반으로 확장한 것입니다.
한 문장으로AI에게 두 번 이상 고쳐 시켜야 할 것 같으면, 명세부터 쓰는 편이 결국 빠릅니다.
비교바이브 코딩 vs SDD
우열이 아니라 용도
바이브 코딩(즉흥적으로 시키고 고쳐가는 방식)이 나쁜 건 아닙니다. 빠른 탐색엔 이만한 게 없습니다. 문제는 감당하기 어려운 일에까지 계속 쓰는 것입니다.
| 구분 | 바이브 코딩 | SDD |
|---|---|---|
| 진실의 원천 | 생성된 코드 | 명세 |
| 재현성 | 낮다 | 높다 — 명세로 재생성 |
| 초기 속도 | 매우 빠름 | 느림 (명세 시간) |
| 후반 속도 | 느려짐 | 유지됨 |
| 적합 | 탐색 · 프로토타입 · 한 파일 | 여러 파일 · 팀 · 복잡한 요구 |
갈아탈 신호
| 이런 상황이면 | 해야 할 일 |
|---|---|
| 같은 부분을 세 번째 고치고 있다 | 멈추고 명세부터 |
| "아까 왜 이렇게 했더라?"를 되묻는다 | |
| 다른 사람에게 설명해야 한다 |
명세무엇을 담나
수용 기준과 범위 밖이 핵심
# 기능: 휴가 신청 반려 알림 ## 배경 / 목적 반려 사실을 신청자가 늦게 알아 재신청이 지연된다. ## 사용자 시나리오 - 팀장이 반려하면 신청자는 즉시 알림을 받는다. ## 요구사항 - 반려 시 메신저 + 메일 동시 발송 - 사유 필수 입력 (미입력 시 반려 불가) ## 수용 기준 (완료의 정의) - [ ] 반려 -> 5초 내 알림 도착 - [ ] 사유 없이 반려 시도 시 에러 - [ ] 발송 실패 시 3회 재시도 후 로그 기록 ## 범위 밖 - 알림 수신 설정 화면 (다음 스프린트)
왜 이 둘인가수용 기준은 AI의 멈춤 조건이 되고, 범위 밖은 시키지 않은 것까지 만드는 걸 막습니다.
실습25분
명세부터 쓰고 시키기
아래 기능에 대한 명세를 먼저 작성해줘. 코드는 아직 쓰지 마. - 배경/목적, 사용자 시나리오, 요구사항, 수용 기준, 범위 밖 순서로 - 애매한 부분은 추측하지 말고 질문으로 정리해줘 [기능] (만들 기능을 한 줄로)
질문에 답했어. 반영해 명세를 확정하고, 그 다음 기술 계획을 따로 정리해줘.
확정된 명세와 계획으로 작업을 단위별로 쪼개고, 각 작업에 완료 판단 기준을 한 줄씩 붙여줘.
하이브리드가 현실탐색은 바이브로 빠르게, 방향이 잡히면 명세로 굳힙니다. "지금까지 만든 것을 명세로 거꾸로 정리해줘"가 그때 쓰는 지시입니다.
- 명세에 수용 기준과 범위 밖을 넣었다
- 바이브 코딩과 SDD의 용도 차이를 안다
- 갈아탈 신호 3가지를 말할 수 있다
클로드코드 시작하기트랙 B · 개발자