인증 성숙도 모델
29.4.1. 성숙도 모델 개요
TQS 성숙도 모델은 CMMI (Capability Maturity Model Integration)의 5단계 성숙도 개념에서 착안하여, 티에니피아의 기술 환경에 맞게 재설계한 자체 성숙도 프레임워크입니다.
CMMI가 조직의 프로세스 성숙도를 측정하는 데 초점을 맞추고 있다면, TQS 성숙도 모델은 프로젝트의 기술 구현 품질 성숙도를 측정합니다. 코드 컨벤션, 테스트, 보안, 빌드 자동화 등 실제 구현 수준을 기반으로 프로젝트의 현재 위치를 진단하고, 다음 단계로 나아가기 위한 구체적인 방향을 제시합니다.
TQS 성숙도 모델의 5단계 구조는 다음과 같습니다.
| 단계 | 명칭 | TQS 인증 등급 | 핵심 특징 |
|---|---|---|---|
| 1단계 | 초기 | 미인증 | 표준 미적용, 개인별 코딩 스타일 |
| 2단계 | 관리 | 미인증 (준비 단계) | 기본 컨벤션 적용, 포매터 설정 완료 |
| 3단계 | 정의 | 기본 인증 | TQS 필수 항목 100% 충족 |
| 4단계 | 정량 | 우수 인증 | 지표 모니터링, 권장 항목 80% 이상 |
| 5단계 | 최적화 | 최우수 인증 | 권장 항목 100%, 지속적 개선 프로세스 |
각 단계는 이전 단계의 요건을 포함합니다. 즉, 3단계에 해당하려면 1단계와 2단계의 요건도 모두 충족해야 합니다. 단계를 건너뛰는 것은 허용되지 않습니다.
성숙도 모델은 TQS 인증과 직접 연계됩니다. 3단계 이상에 도달한 프로젝트만 TQS 인증을 신청할 수 있으며, 4단계와 5단계는 각각 우수 인증과 최우수 인증에 대응합니다.
29.4.2. 단계별 정의
29.4.2.1. 1단계: 초기
1단계는 기술 표준이 적용되지 않은 상태입니다. 개발자 개인의 경험과 선호에 따라 코딩 스타일, 도구 선택, 프로젝트 구조가 결정됩니다.
| 영역 | 1단계 상태 |
|---|---|
| 코드 스타일 | 포매터 미적용, 개인별 상이한 코딩 스타일 |
| 프로젝트 구조 | 비표준 디렉토리 구조, 일관성 없는 패키지 구성 |
| 테스트 | 테스트 미작성 또는 매우 낮은 커버리지 (30% 미만) |
| 형상관리 | 브랜치 전략 미정의, 커밋 메시지 규칙 없음 |
| CI/CD | 파이프라인 미구성 또는 수동 배포 |
| 보안 | 체계적 보안 기준 없음, 시크릿 관리 미흡 |
| 문서화 | API 문서 미작성, 프로젝트 설명 문서 부재 |
1단계에 있는 프로젝트는 기술 부채가 빠르게 누적되며, 팀원 변경이나 요구사항 변경에 취약합니다. 대부분의 신규 프로젝트는 의도적으로 표준을 적용하지 않는 한 1단계에서 시작합니다.
29.4.2.2. 2단계: 관리
2단계는 기본적인 코딩 컨벤션과 도구 설정이 완료된 상태입니다. 표준화의 첫 걸음을 뗀 단계이며, TQS 인증을 위한 준비가 시작됩니다.
| 영역 | 2단계 상태 |
|---|---|
| 코드 스타일 | 포매터 설정 완료 (Google Java Format, Prettier) |
| 프로젝트 구조 | 기본적인 계층 구조 적용 (Controller-Service-Repository) |
| 테스트 | 주요 기능에 대한 테스트 존재 (커버리지 30~60%) |
| 형상관리 | 브랜치 전략 도입, 기본 커밋 규칙 적용 |
| CI/CD | 기본 파이프라인 구성 (빌드 + 테스트) |
| 보안 | 기본 입력 검증 적용, .gitignore 설정 |
| 문서화 | 기본 프로젝트 설명 문서 존재 |
2단계는 TQS 인증 기준에는 미달하지만, 표준화의 기반이 마련된 상태입니다. 이 단계에서 TQS 규격의 필수 항목을 하나씩 충족해 나가면 3단계로 전환할 수 있습니다.
29.4.2.3. 3단계: 정의
3단계는 TQS 규격의 필수 항목을 100% 충족한 상태이며, TQS 기본 인증에 해당합니다.
| 영역 | 3단계 상태 |
|---|---|
| 코드 스타일 | 포매터 + 린터 자동 적용, CI에서 스타일 검증 |
| 프로젝트 구조 | TQS 표준 프로젝트 구조 100% 준수 |
| 테스트 | 라인 커버리지 80% 이상, 브랜치 커버리지 70% 이상 |
| 형상관리 | GitHub Flow, Conventional Commits, PR 리뷰 1인 이상 |
| CI/CD | 린트 + 테스트 + 빌드 파이프라인 완비 |
| 보안 | TLS 1.2 이상, BCrypt 해시, Bean Validation, RBAC |
| 문서화 | API 문서 자동 생성 (SpringDoc), 표준 에러 응답 |
3단계는 TQS 인증의 최소 기준입니다. 필수 항목 100% 충족이 요건이므로, 단 하나의 필수 항목이라도 미충족이면 3단계로 인정되지 않습니다. 3단계에 도달한 프로젝트는 TQS 기본 인증을 신청할 수 있습니다.
29.4.2.4. 4단계: 정량
4단계는 필수 항목 충족에 더하여, 권장 항목의 80% 이상을 충족하고 품질 지표를 정량적으로 모니터링하는 상태입니다. TQS 우수 인증에 해당합니다.
| 영역 | 4단계 상태 |
|---|---|
| 코드 스타일 | 3단계 충족 + 코드 복잡도/중복도 모니터링 |
| 프로젝트 구조 | 3단계 충족 + 권장 설정 항목 80% 이상 적용 |
| 테스트 | 라인 커버리지 85% 이상, 통합 테스트 포함 |
| 형상관리 | 3단계 충족 + Semantic Versioning 엄격 적용 |
| CI/CD | 3단계 충족 + 보안 스캔 단계 포함 |
| 보안 | 3단계 충족 + OWASP Dependency-Check 적용 |
| 문서화 | 3단계 충족 + 아키텍처 문서, 운영 가이드 작성 |
| 모니터링 | 커버리지, 빌드 성공률, 결함 밀도 정기 측정 |
4단계의 핵심은 정량적 관리입니다. 품질 지표를 수치로 측정하고, 추이를 분석하며, 목표 대비 달성률을 관리합니다. 감에 의한 판단이 아니라 데이터에 기반한 품질 관리가 이루어지는 단계입니다.
29.4.2.5. 5단계: 최적화
5단계는 필수 항목과 권장 항목을 모두 100% 충족하고, 지속적 개선 프로세스를 운영하는 상태입니다. TQS 최우수 인증에 해당합니다.
| 영역 | 5단계 상태 |
|---|---|
| 코드 스타일 | 4단계 충족 + 팀 자체 컨벤션 개선 활동 |
| 프로젝트 구조 | 모든 필수/권장 항목 100% 충족 |
| 테스트 | 라인 커버리지 90% 이상, E2E 테스트 포함 |
| 형상관리 | 4단계 충족 + 릴리스 자동화 |
| CI/CD | 4단계 충족 + 무중단 배포, 카나리 배포 |
| 보안 | 4단계 충족 + 정기 보안 감사, 침투 테스트 |
| 문서화 | 4단계 충족 + 기술 결정 기록(ADR) |
| 개선 활동 | 정기 회고, KPI 기반 개선 목표 설정 및 달성 |
5단계의 핵심은 지속적 개선입니다. 현재 수준에 만족하지 않고, 데이터를 기반으로 개선 기회를 탐색하며, 새로운 기술과 방법론을 적극적으로 도입합니다. 5단계 프로젝트는 사내 기술 우수 사례로 등록되어 다른 프로젝트의 벤치마크 대상이 됩니다.
29.4.3. 자체 진단 가이드
프로젝트 팀이 현재 성숙도 단계를 자체적으로 진단할 수 있도록 단계별 진단 기준을 제공합니다.
29.4.3.1. 진단 기준 테이블
다음 테이블의 각 항목에 대해 "충족" 또는 "미충족"을 판정합니다. 해당 단계의 모든 항목을 충족해야 해당 단계로 인정됩니다.
1단계 -> 2단계 전환 진단
| 번호 | 진단 항목 | 충족 기준 |
|---|---|---|
| 1 | 포매터 설정 파일이 프로젝트에 포함되어 있는가 | .editorconfig 또는 포매터 설정 파일 존재 |
| 2 | 기본적인 계층 구조가 적용되어 있는가 | Controller-Service-Repository 분리 |
| 3 | 테스트 코드가 존재하는가 | 최소 1개 이상의 테스트 클래스 존재 |
| 4 | 브랜치 전략이 정의되어 있는가 | main/feature 브랜치 구분 사용 |
| 5 | CI 파이프라인이 구성되어 있는가 | 빌드 자동화 구성 |
| 6 | .gitignore 파일이 적절히 설정되어 있는가 | 빌드 산출물, IDE 설정 파일 제외 |
2단계 -> 3단계 전환 진단
| 번호 | 진단 항목 | 충족 기준 |
|---|---|---|
| 1 | TQS 필수 체크리스트를 모두 통과하는가 | 해당 카테고리 필수 항목 100% 충족 |
| 2 | 포매터/린터가 CI에서 자동 검증되는가 | CI 파이프라인에 린트 단계 포함 |
| 3 | 테스트 커버리지 기준을 충족하는가 | 라인 80%, 브랜치 70% 이상 |
| 4 | Conventional Commits를 적용하는가 | 커밋 메시지 형식 준수 |
| 5 | PR 리뷰 프로세스가 운영되고 있는가 | 최소 1인 리뷰 후 머지 |
| 6 | 보안 기본 항목이 적용되어 있는가 | TLS, BCrypt, Bean Validation, RBAC |
| 7 | API 문서가 자동 생성되는가 | SpringDoc/Swagger UI 구성 완료 |
3단계 -> 4단계 전환 진단
| 번호 | 진단 항목 | 충족 기준 |
|---|---|---|
| 1 | 권장 항목 충족률이 80% 이상인가 | 권장 체크리스트 80% 이상 |
| 2 | 코드 품질 지표를 정기적으로 측정하는가 | 월 1회 이상 측정 |
| 3 | 테스트 커버리지가 85% 이상인가 | 라인 커버리지 85% 이상 |
| 4 | 보안 스캔이 CI에 통합되어 있는가 | OWASP Dependency-Check 또는 동등 도구 |
| 5 | 품질 지표 추이를 추적하고 있는가 | 대시보드 또는 리포트 존재 |
4단계 -> 5단계 전환 진단
| 번호 | 진단 항목 | 충족 기준 |
|---|---|---|
| 1 | 모든 권장 항목을 100% 충족하는가 | 권장 체크리스트 100% |
| 2 | 지속적 개선 프로세스가 운영되고 있는가 | 정기 회고, 개선 목표 수립 |
| 3 | 테스트 커버리지가 90% 이상인가 | 라인 커버리지 90% 이상 |
| 4 | E2E 테스트가 포함되어 있는가 | E2E 테스트 자동화 |
| 5 | 무중단 배포가 구현되어 있는가 | 배포 시 서비스 중단 없음 |
| 6 | KPI 기반 개선 활동 이력이 있는가 | 최소 2건 이상의 개선 사례 |
29.4.3.2. 현재 단계 판별 방법
현재 성숙도 단계를 판별하는 방법은 다음과 같습니다.
- 1단계에서 시작하여 상위 단계로 순차적으로 진단합니다.
- 해당 단계의 모든 진단 항목이 "충족"이면 다음 단계로 이동합니다.
- 하나라도 "미충족"인 항목이 있으면 이전 단계가 현재 단계입니다.
- 예를 들어, 2단계 -> 3단계 진단에서 미충족 항목이 있으면 현재 단계는 2단계입니다.
자체 진단은 TQS 인증 심사 전에 반드시 수행해야 합니다. 자체 진단 결과 3단계 미만인 프로젝트는 인증 심사를 신청할 수 없습니다.
29.4.4. 단계별 전환 로드맵
현재 단계에서 다음 단계로 올라가기 위한 핵심 활동을 정의합니다. 각 전환에는 예상 소요 기간과 우선순위가 높은 활동을 안내합니다.
29.4.4.1. 1단계에서 2단계로
예상 소요 기간: 2~4주
| 우선순위 | 핵심 활동 | 상세 내용 |
|---|---|---|
| 1 | 포매터 설정 | Google Java Format (백엔드), Prettier (프론트엔드) 설정 및 적용 |
| 2 | 프로젝트 구조 정비 | 표준 계층 구조(Controller-Service-Repository)로 패키지 재구성 |
| 3 | CI 파이프라인 구성 | 빌드 + 테스트 자동화 기본 파이프라인 구축 |
| 4 | 브랜치 전략 도입 | GitHub Flow 적용, main/feature 브랜치 운영 시작 |
| 5 | 기본 테스트 작성 | 핵심 비즈니스 로직에 대한 단위 테스트 작성 |
| 6 | .gitignore 정비 | 표준 .gitignore 파일 적용 |
1단계에서 2단계로의 전환은 가장 기본적이지만, 이후 모든 단계의 기반이 됩니다. 포매터 설정부터 시작하는 것을 권장합니다. 포매터 적용만으로도 코드의 일관성이 크게 향상됩니다.
29.4.4.2. 2단계에서 3단계로
예상 소요 기간: 4~8주
| 우선순위 | 핵심 활동 | 상세 내용 |
|---|---|---|
| 1 | TQS 체크리스트 자체 점검 | 필수 항목 전체를 점검하고 미충족 항목 목록 작성 |
| 2 | 테스트 커버리지 확보 | 라인 80%, 브랜치 70% 달성을 위한 테스트 작성 |
| 3 | CI 파이프라인 보강 | 린트 검증 단계 추가, 커버리지 리포트 생성 |
| 4 | 보안 기본 항목 적용 | TLS, BCrypt, Bean Validation, Spring Security 설정 |
| 5 | 형상관리 규칙 적용 | Conventional Commits, PR 템플릿, 리뷰 프로세스 |
| 6 | API 문서 자동화 | SpringDoc(Swagger UI) 구성 |
| 7 | 미충족 항목 보완 | 자체 점검에서 발견된 나머지 필수 항목 충족 |
2단계에서 3단계로의 전환이 가장 노력이 많이 필요한 구간입니다. 테스트 커버리지 확보에 가장 많은 시간이 소요되므로, 가능한 한 조기에 시작하는 것을 권장합니다.
29.4.4.3. 3단계에서 4단계로
예상 소요 기간: 4~6주
| 우선순위 | 핵심 활동 | 상세 내용 |
|---|---|---|
| 1 | 권장 항목 점검 | 권장 체크리스트를 점검하고 충족 가능 항목 우선 적용 |
| 2 | 품질 지표 모니터링 체계 구축 | 커버리지, 빌드 성공률, 결함 밀도 자동 측정 환경 |
| 3 | 보안 스캔 CI 통합 | OWASP Dependency-Check를 CI 파이프라인에 추가 |
| 4 | 테스트 커버리지 향상 | 85% 이상 달성, 통합 테스트 추가 |
| 5 | 운영 문서 작성 | 아키텍처 문서, 운영 가이드, 장애 대응 매뉴얼 |
| 6 | 정기 측정 프로세스 수립 | 월별 품질 지표 측정 및 리포트 체계 |
3단계에서 4단계로의 전환은 "관리"에서 "측정"으로의 전환입니다. 품질을 정량적으로 측정하고 추적하는 체계를 구축하는 것이 핵심입니다.
29.4.4.4. 4단계에서 5단계로
예상 소요 기간: 6~12주
| 우선순위 | 핵심 활동 | 상세 내용 |
|---|---|---|
| 1 | 잔여 권장 항목 충족 | 미충족 권장 항목 100% 달성 |
| 2 | 지속적 개선 프로세스 수립 | 정기 회고, 데이터 기반 개선 목표 수립 |
| 3 | E2E 테스트 구축 | 주요 사용자 시나리오에 대한 E2E 테스트 자동화 |
| 4 | 무중단 배포 구현 | 블루-그린 또는 카나리 배포 전략 적용 |
| 5 | 보안 강화 | 정기 보안 감사, 침투 테스트 수행 |
| 6 | 기술 결정 기록 | ADR (Architecture Decision Records) 작성 시작 |
| 7 | 팀 개선 활동 | 기술 부채 해소 스프린트, 코드 품질 개선 활동 정례화 |
4단계에서 5단계로의 전환은 가장 오랜 시간이 소요되는 구간입니다. 5단계는 단순히 체크리스트를 충족하는 것을 넘어, 지속적으로 개선하는 문화와 프로세스를 갖추어야 달성할 수 있습니다. 이 단계에 도달한 프로젝트는 조직 내 기술 표준의 모범 사례로 인정됩니다.