서론
목표
- 명세 주도 개발 목표 이해하기
- 명세 주도 개발 장단점 이해하기
- 명세 주도 개발 Java/Springboot Boilerplate 이해하기
마인드 맵
핵심 키워드
| Keyword | Description |
|---|---|
| SSOT(Single Source of Truth) | 명세, 계약과 관련된 문서를 각각 오직 하나만 관리 |
| Specification(명세) | 외부 사용자와의 IF 명세 |
| Contract(계약) | 외부 사용자의 Usecase 문서 |
| OAS(Open API Specification) | API 명세 작성 문법 |
| 통합테스트 | 모듈(Micro Service) 수준에서 다른 모듈과의 IF 테스트 |
| TDD(Test Driven Development) | 구현 작성 전, 테스트를 먼저 작성하여 오류를 방지 |
| SDD(Specification Driven Development) | 코드 작성 전, 명세를 먼저 작성하여 오류를 방지 |
본문
명세 주도 계약 정의
명세 주도 계약(SDD)은 명세와 계약을 SSOT로 사용함으로써 다음 항목들을 보장하는 것을 목표로 합니다.
- 코드 수준의 재작성(Boilerplate)을 최소화
- SSOT의 변경이 코드에 실질적인 제약으로 동작하도록 강제
- Usecase를 벗어나는 과잉 개발 방지
사용 이유
최근의 개발 환경은 Extream Programming(XP)의 방법론을 도입하는 사례가 증가하고 있습니다. 켄트 벡의 XP Explained 2nd에서 확인할 수 있듯 XP는 다음과 같은 개발 주기를 가지고 있습니다.
- 현재 주기의 개발 목표(Story) 수립
- 개발 목표로부터 명세(Specification) 추출
- 명세를 반영하는 설계 변경점(Design) 추출
- 설계 변경점으로부터 세부 항목(Task) 추출
- 세부 항목에 대한 검증 항목(Test) 추출
- 검증 항목으로부터 개발(Code) 수행
- 검증 항목과 개발을 토대로 추가 설계 변경 여부 판단
1-7반복
이러한 주기를 반복하는 것으로 서비스는 적정 수준을 유지하며 성장할 수 있습니다. 그런데, 위의 개발 주기를 반복하여 수행하다보면 몇 가지 개선할 수 있는 부분을 찾을 수 있습니다. 서비스가 도메인 주도 설계의 원칙에 맞춰 개발되고 있다면, 도메인 기능과 외부 연결(API, Event 등) 기능은 독립적으로 유지될 것입니다. 이때 외부 연결 기능은 테스트와 코드에 있어 일정한 패턴을 보이곤 합니다. 예를 들어, Springboot로 API를 개발한다고 하면 다음과 같은 패턴이 발견됩니다.
- API 명세 작성
- API 명세의 사용사례에 맞춰
@SpringbootTest로 통합 테스트 작성 @Controller와ResponseEntity를 사용하는 API IF 작성- API IF에 맞춰 도메인 접근 기능 개발
위 과정 중 2-3 번은 문서로 작성된 명세와 사용사례를 단순히 코드로 옮기는 것에 지나지 않을 가능성이 큽니다. 만약 그런 경우, 이들을 코드로 옮기는 것은 Translator의 도움을 받아 자동화할 수 있습니다. SDD는 바로 이 지점을 해결하기 위한 방법론입니다. SSOT로부터 IF와 테스트를 번역함으로써 불필요한 부가 작업을 없애고, 혹시 모를 누락의 문제를 해결할 수 있습니다.
또한, SSOT로부터 코드와 테스트가 촉발되기 때문에 SSOT의 갱신은 서비스에 즉각적인 피드백으로 동작합니다. 이것은 진화적 아키텍처에서 말하는 Fitness 함수로써 동작할 여지가 있는데, 이 관점에서 이러한 피드백은 명세와 실제 서비스의 간극을 최소화하는 제약으로 동작할 수 있습니다.
마지막으로, 계약이 통합 테스트로 동작하기 때문에 계약의 범위를 넘어선 과잉 개발을 방지하고, 현재 단계의 적정 수준을 유지하도록 유도할 수 있습니다.
장단점
소프트웨어 세상의 모든 것들이 그러하듯, SDD 역시 은탄환은 아닙니다. 따라서 다음의 장단점을 살펴보고, 적정 수준에서 도입하는 것이 필요합니다.
| 장점 | 단점 |
|---|---|
| 이해관계자가 확인 가능한 명세, 계약을 사용 | 추가적인 DSL 계층 도입 - 서비스 소비자가 계약 작성 방법 학습 필요 - 명세, 계약 작성 및 검토 방법 학습 필요 |
| 반복작업 최소화 | 자동 생성된 코드 외 추가 기능이 필요한 경우, 더 복잡 |
| 요구사항과 구현의 정합성 유지 | 개발 속도 저하 가능성 있음(선제적 명세 체계화) |
| 과잉 개발 억제 | 단일 모듈/서비스 수준에서의 적용은 큰 의미 없음 |
Java/Springboot Boilerplate
위의 Github Repository는 SDD를 Java/Springboot로 간단히 구현한 것입니다. 해당 Repository의 README.md에도 작성하였지만, 주요 내용은 다음과 같습니다.
- API 명세는 Open API Specification3로 작성되며, OpenAPI Generator를 통해 API IF로 번역됩니다.
-contracts에 예시를 포함하였습니다../gradlew compileJava실행 시build/generated에 API IF가 생성됩니다.
- 계약은 Spring Cloud Contract로 작성됩니다.
-src/test/java/love/you/babe/contracts와src/test/resources/contracts에 예시를 포함하였습니다../gradlew contractTest실행 시 계약에 대한 통합 테스트가 수행됩니다.
결론
명세 주도 개발은 XP 방법론의 일부를 자동화하기 위한 것으로, 외부 연동을 SSOT를 통해 관리합니다. 그 결과, 반복되는 코드와 테스트를 줄일 수 있고, 핵심 기능에 집중할 수 있습니다. 하지만 다른 모든 것들이 그러하듯 SDD 역시 장단점을 명확히 파악하고 사용해야 합니다.
