갈피노트
Back to Home
iOS Development • 2026년 2월 9일

OPUS 4.6과 스펙 주도 개발

#claude #vibecoding #SDD #스펙주도개발

우당탕탕 AI와 바이브코딩인듯 바이브코딩같은, 아무튼 무언가를 만들어가는 일을 계속하고 있다.

여전히 SDD(Spec Driven Development)는 좋은데, 며칠 전에 Opus 4.6이 나와버렸다.

별 생각이 없었는데, '이거, 저거, 요거 좀 찾아서 비교분석해줘' 라고 Claude code에게 지시했더니만,

이거와 저거와 요거를 각자 Web Search를 하고선 합쳐서 분석한 결과를 내놓는 것이 아닌가.

개발할 때도 비슷했다.

여러가지 수정 사항을 1,2,3,4 붙여서 수정해달라고 하니, 서로 연관성이 없는 이슈를 파악한 뒤

바로 동시 작업.

ㄷㄷㄷ...

정말 SDD가 필요없어지는거 아냐? 해서, OPUS 4.6에게 객관적으로 비교해달라고 해봤다.


  Plan Mode vs Speckit SDD 객관적 비교

                                                                                                                        

  ---                                                                                                                   

  프로세스 비교                          

                                                                                                                        

  Plan Mode (내장)                                                                                                      

  - 단계: 탐색 → 플랜 작성 → 승인 → 구현

  - 산출물: 플랜 파일 1개 (대화 내)

  - 지속성: 대화 종료 시 소멸

  - 가드레일: 없음 (내 판단에 의존)

  - 추적성: 없음

  Speckit SDD

  - 단계: specify → clarify → plan → tasks → analyze → implement

  - 산출물: spec.md, plan.md, research.md, data-model.md, contracts/, tasks.md

  - 지속성: git에 커밋, 영구 보존

  - 가드레일: Constitution으로 원칙 강제

  - 추적성: Task → User Story → Requirement 역추적 가능

  ---

  Plan Mode가 우세한 영역

  - 속도: 탐색~구현까지 한 흐름, 중간 의례(ceremony) 없음

  - 적응성: 구현 중 예상 못한 상황에 즉시 플랜 수정

  - 소규모 작업: 버그 수정, 단일 파일 변경에 Speckit은 과잉

  - 탐색적 작업: "일단 해보고 방향 잡자"는 작업에 적합

  ---

  Speckit이 우세한 영역

  - 요구사항 누락 방지: User Story + Acceptance Criteria가 "뭘 만들어야 하는지" 강제

  - 다중 세션: 대화가 끊어져도 spec.md, tasks.md가 남아있음

  - 일관성 검증: /speckit.analyze로 spec ↔ plan ↔ tasks 간 불일치 자동 탐지

  - 점진적 배포: User Story별 독립 구현/테스트/배포 설계가 템플릿에 내장

  - 의사결정 기록: "왜 이렇게 만들었는가"가 문서로 남음

  - Constitution: 프로젝트 원칙(MVVM, 네이밍 등)이 기능 개발 시 자동으로 체크됨

  ---

  솔직한 약점 비교

  Plan Mode의 약점:

  - 대화가 길어지면 초반 맥락을 잊음 (컨텍스트 압축)

  - 매 세션마다 동일한 아키텍처 결정을 다시 내릴 수 있음

  - "다 했다"의 기준이 모호 → 빠뜨리는 케이스 발생

  Speckit의 약점:

  - 단순한 작업에 과잉 오버헤드 (spec → plan → tasks → 3번 왕복)

  - 템플릿이 범용적이라 iOS 프로젝트에 100% 맞지 않는 부분 있음

  - Constitution이 이미 outdated될 수 있음

  ---

  이번 기능("복수 일정 + 수익화")에 대한 결론

  Speckit SDD가 적합합니다.

  다만 하이브리드가 최선이라고 제안했고, 이후 흐름도 정리했습니다:

  Speckit 담당 (구조화)          나(CLAUDE)의 담당 (실행)

  ────────────        ──────────────

  /speckit.specify

    → spec.md

  /speckit.clarify

    → 모호한 부분 확정

  /speckit.plan

    → plan.md, research.md

  /speckit.tasks

    → tasks.md

                                 tasks.md를 읽고 직접 구현

                                 (plan mode 없이 바로 코딩)

  ---

  /speckit.implement vs 직접 구현의 차이

  /speckit.implement:

  - 태스크 실행: tasks.md를 순서대로 기계적으로 처리

  - 예외 대응: 태스크 단위로 완료/실패 판단

  - 맥락 활용: 태스크 설명에 의존

  직접 구현:

  - 태스크 실행: tasks.md를 참조하되, 상황에 맞게 순서/방법 조정

  - 예외 대응: 구현 중 발견한 이슈를 즉시 반영

  - 맥락 활용: 앞서 나눈 대화(수익화 전략, 템플릿 분리 등)까지 활용

  핵심은 Speckit으로 "뭘 만들지"를 확정하고, "어떻게 만들지"는 유연하게 처리한다는 것.


객관적이라는 느낌이 들었다.

아이디어가 나오면, 아이디어를 구체화해서 만드는 부분은 다시 plan mode로 만들겠다는 것.

1차 결론이 나왔으니, 돌려보러 간다.

Comments