현재 한계점
SDD Tool의 현실적인 한계와 적정 사용 규모를 정리합니다.
적정 프로젝트 규모
| 규모 | 개발자 | 스펙 수 | 적합도 | 비고 |
|---|---|---|---|---|
| 소규모 | 1-5명 | ~50개 | 최적 | 모든 기능 원활 |
| 중규모 | 5-15명 | 50-150개 | 관리 가능 | 규율 필요 |
| 대규모 | 15명+ | 150개+ | 한계 도달 | 분리 권장 |
구조적 한계
1. 파일 기반 시스템
문제: 모든 작업이 파일 시스템 직접 접근
영향: 스펙 100개 이상에서 성능 저하- 매 명령어 실행 시 전체 스펙 파싱
- 인덱싱/캐싱 메커니즘 없음
- 대규모 검색 시 응답 지연
2. 수동 의존성 관리
yaml
# 현재: 개발자가 직접 명시
---
dependencies:
- user-auth
- data-model
---- 의존성 누락 가능성
- 암시적 참조 자동 감지 제한적
- 복잡한 의존성 그래프에서 관리 어려움
3. 단일 Constitution
.sdd/
└── constitution.md # 프로젝트 전체 단일 파일- 멀티팀 환경에서 도메인별 원칙 분리 불가
- 대규모 프로젝트에서 Constitution 비대화
- 팀별 자율성과 전역 일관성 균형 어려움
4. 버전 관리 한계
- Git 의존적 버전 관리
- 스펙 자체 버전 히스토리 추적 없음
- Breaking change 자동 감지 없음
- 스펙 간 버전 호환성 검증 없음
워크플로우 한계
1. 협업 기능 부재
| 기능 | 현재 상태 |
|---|---|
| 동시 편집 | Git 충돌에 의존 |
| 스펙 잠금 | 미지원 |
| 리뷰 승인 | 미지원 |
| 코멘트/토론 | 미지원 |
2. 외부 도구 연동 없음
- Issue Tracker 연동 없음 (GitHub Issues, Linear, Jira)
- IDE 플러그인 없음
- CI/CD 연동 기본적 수준
- 알림/웹훅 시스템 없음
3. 리포팅 제한
- 실시간 대시보드 없음
- 트렌드 분석 없음
- 팀별/도메인별 통계 제한적
최적의 사용 케이스
적합한 경우
✅ 사이드 프로젝트 / MVP
✅ 소규모 스타트업 초기 제품
✅ 단일 팀이 관리하는 마이크로서비스
✅ AI 페어 프로그래밍 집중 개발
✅ 명확한 범위의 신규 기능 개발주의가 필요한 경우
⚠️ 중규모 SaaS (Phase/도메인 분리 필수)
⚠️ 10명 이하 팀의 주력 제품
⚠️ 여러 마이크로서비스 동시 관리부적합한 경우
❌ 엔터프라이즈 시스템
❌ 멀티팀 대규모 프로젝트
❌ 레거시 시스템 전체 문서화
❌ 규제 산업의 감사 추적 필요 프로젝트
❌ 지리적 분산 팀스케일 한계 징후
프로젝트가 다음 징후를 보이면 한계에 도달한 것입니다:
성능 징후
sdd validate실행 시간 > 10초sdd search응답 지연 체감sdd impact분석 시간 증가
관리 징후
- 의존성 그래프 파악 어려움
- 스펙 중복/충돌 빈번
- Constitution 원칙 해석 불일치
- 리뷰 없이 스펙 변경 발생
협업 징후
- Git 충돌 빈번
- "누가 이 스펙 수정했지?" 질문 증가
- 스펙 상태 파악에 시간 소요
한계 대응 전략
단기 대응
- Phase 분리 철저화: 명확한 Phase 경계
- 명명 규칙 강화: 도메인 접두사 사용 (
auth-,billing-) - 정기 정리: 완료된 스펙 아카이브
중기 대응
- 도메인별 분리: 별도
.sdd/디렉토리 - 자동화 스크립트: 커스텀 검증/리포트
- 외부 도구 병행: 복잡한 협업은 Notion/Linear 활용
장기 대응
- 도구 확장: 스케일업 로드맵 참조
- 프로젝트 분리: 마이크로서비스별 독립 SDD
- 대안 도구 검토: 엔터프라이즈급 요구사항 관리 도구