운영 체크리스트
본 장은 TQS-S/W 인증의 운영 영역에 대한 상세 체크리스트를 정의합니다. 운영 체크리스트는 형상관리, CI/CD, 테스트 표준의 3개 영역으로 구성됩니다. 각 항목의 분류는 필수(O), 권장(R), 선택(S)으로 구분되며, 검증 방법을 함께 명시합니다.
32.4.1. 형상관리
형상관리 체크리스트는 Git 기반의 소스코드 버전 관리, 브랜치 전략, 커밋 규칙, PR 운영의 표준 준수를 검증합니다.
| 번호 | 항목 | 분류 | 검증 방법 |
|---|---|---|---|
| 1 | GitHub Flow 브랜치 전략을 적용한다 | O | 브랜치 목록 및 운영 이력 확인 |
| 2 | Conventional Commits 형식으로 커밋 메시지를 작성한다 | O | 커밋 로그 확인 |
| 3 | PR 템플릿을 프로젝트에 포함한다 | O | .github/PULL_REQUEST_TEMPLATE.md 파일 존재 확인 |
| 4 | PR 리뷰어를 최소 1명 이상 지정한다 | O | PR 이력 확인 |
| 5 | .gitignore 파일이 TQS 표준을 준수한다 | O | .gitignore 파일 내용 확인 |
| 6 | Semantic Versioning (SemVer)을 적용한다 | O | 태그 및 릴리스 이력 확인 |
| 7 | main 브랜치에 보호 규칙을 설정한다 (직접 푸시 금지) | R | GitHub 리포지토리 설정 확인 |
| 8 | 커밋에 GPG 또는 SSH 서명을 적용한다 | S | 커밋 로그의 서명 여부 확인 |
형상관리는 프로젝트의 변경 이력을 체계적으로 관리하는 기반입니다. GitHub Flow 브랜치 전략은 단순하면서도 효과적인 워크플로를 제공하며, Conventional Commits는 자동 변경 로그 생성과 버전 관리의 기반이 됩니다.
32.4.1.1. 형상관리 검증 세부 기준
GitHub Flow 브랜치 전략의 준수 여부는 다음 기준으로 판정합니다.
main브랜치는 항상 배포 가능한 상태를 유지해야 합니다.- 기능 개발은
main에서 분기한 피처 브랜치에서 수행해야 합니다. - 피처 브랜치는 PR을 통해
main에 병합해야 하며, 직접 푸시는 허용하지 않습니다.
Conventional Commits의 준수 여부는 최근 50개 커밋을 기준으로 검증합니다. 커밋 메시지의 90% 이상이 Conventional Commits 형식(feat:, fix:, docs:, refactor: 등)을 따라야 통과로 판정합니다.
32.4.2. CI/CD
CI/CD 체크리스트는 CircleCI 기반의 지속적 통합 및 배포 파이프라인 구성을 검증합니다.
| 번호 | 항목 | 분류 | 검증 방법 |
|---|---|---|---|
| 9 | CircleCI 파이프라인을 구성한다 | O | .circleci/config.yml 파일 존재 확인 |
| 10 | 린트 검증 단계를 파이프라인에 포함한다 | O | CircleCI 설정 파일의 린트 단계 확인 |
| 11 | 테스트 실행 단계를 파이프라인에 포함한다 | O | CircleCI 설정 파일의 테스트 단계 확인 |
| 12 | 빌드 단계를 파이프라인에 포함한다 | O | CircleCI 설정 파일의 빌드 단계 확인 |
| 13 | 최근 5회 빌드가 모두 성공 상태이다 | O | CircleCI 빌드 이력 확인 |
| 14 | 보안 스캔 단계를 파이프라인에 포함한다 | R | CircleCI 설정 파일의 보안 스캔 단계 확인 |
| 15 | 배포 자동화를 구현한다 | R | CircleCI 설정 파일의 배포 단계 확인 |
| 16 | 환경별(dev / staging / prod) 파이프라인을 분리한다 | R | CircleCI 설정 파일의 워크플로 확인 |
CI/CD는 코드 품질을 지속적으로 검증하고 배포 안정성을 보장하는 핵심 인프라입니다. 파이프라인에는 최소한 린트 검증, 테스트 실행, 빌드의 3단계를 필수로 포함해야 합니다.
32.4.2.1. CI/CD 검증 세부 기준
CircleCI 파이프라인의 검증은 다음 기준으로 수행합니다.
.circleci/config.yml파일이 프로젝트 루트에 존재해야 합니다.- 파이프라인의 각 단계(린트, 테스트, 빌드)는 독립적으로 실행 가능해야 합니다.
- 파이프라인 실행 시간은 15분 이내를 권장합니다.
- 빌드 이력은 CircleCI 대시보드 또는 API를 통해 확인합니다.
32.4.3. 테스트 표준
테스트 표준 체크리스트는 백엔드 테스트의 프레임워크, 작성 패턴, 커버리지 기준, 테스트 격리 수준을 검증합니다.
| 번호 | 항목 | 분류 | 검증 방법 |
|---|---|---|---|
| 17 | JUnit 5를 테스트 프레임워크로 사용한다 | O | pom.xml 의존성 확인 |
| 18 | Given-When-Then 패턴으로 테스트를 작성한다 | O | 테스트 코드 리뷰 |
| 19 | 라인 커버리지 80% 이상을 달성한다 | O | JaCoCo 리포트 확인 |
| 20 | 브랜치 커버리지 70% 이상을 달성한다 | O | JaCoCo 리포트 확인 |
| 21 | 각 테스트는 독립적으로 실행 가능하다 (테스트 간 의존성 없음) | O | 테스트 코드 리뷰 |
| 22 | 테스트 메서드명이 테스트 의도를 명확히 표현한다 | O | 테스트 코드 리뷰 |
| 23 | Testcontainers를 활용하여 통합 테스트를 수행한다 | R | pom.xml 의존성 및 테스트 코드 확인 |
| 24 | 테스트 데이터를 테스트별로 독립 관리한다 (공유 데이터 미사용) | R | 테스트 코드 리뷰 |
| 25 | 경계값 테스트를 포함한다 | R | 테스트 코드 리뷰 |
테스트 표준은 코드의 신뢰성과 유지보수성을 보장하는 핵심 영역입니다. JUnit 5와 Given-When-Then 패턴은 테스트의 가독성과 구조화를 보장하며, 커버리지 기준은 테스트의 충분성을 정량적으로 검증합니다.
32.4.3.1. 테스트 검증 세부 기준
테스트 커버리지는 JaCoCo 리포트 기준으로 측정합니다. 커버리지 산정 시 다음 규칙을 적용합니다.
- 자동 생성된 코드(jOOQ codegen 등)는 커버리지 산정에서 제외합니다.
- 설정 클래스(
@Configuration)는 커버리지 산정에서 제외할 수 있습니다. - DTO, VO 등 단순 데이터 객체는 커버리지 산정에서 제외할 수 있습니다.
Given-When-Then 패턴의 준수 여부는 수동 리뷰로 검증합니다. 테스트 메서드의 구조가 명확히 준비(Given), 실행(When), 검증(Then) 단계로 구분되어야 합니다.
32.4.4. 항목 요약
운영 체크리스트의 전체 항목 수와 분류별 분포는 다음과 같습니다.
| 영역 | 필수(O) | 권장(R) | 선택(S) | 합계 |
|---|---|---|---|---|
| 형상관리 | 6 | 1 | 1 | 8 |
| CI/CD | 5 | 3 | 0 | 8 |
| 테스트 표준 | 6 | 3 | 0 | 9 |
| 합계 | 17 | 7 | 1 | 25 |
운영 체크리스트는 총 25개 항목으로 구성됩니다. 필수 항목 17개를 모두 충족해야 기본 인증을 획득할 수 있으며, 권장 항목 7개의 충족률에 따라 우수 또는 최우수 인증 등급이 결정됩니다. 선택 항목 1개는 인증 등급 산정에 포함되지 않습니다.
32.4.5. 운영 검증 시 유의사항
운영 체크리스트의 검증 시 다음 사항을 유의해야 합니다.
- 형상관리 항목은 프로젝트의 GitHub 리포지토리를 직접 확인하여 검증합니다. 비공개 리포지토리의 경우, TQS 위원회에 읽기 권한을 부여해야 합니다.
- CI/CD 항목은 파이프라인 설정 파일과 실행 이력을 함께 확인합니다. 설정 파일만 존재하고 실제 실행 이력이 없는 경우 미충족으로 판정합니다.
- 테스트 표준 항목은 자동 검증(커버리지 수치)과 수동 리뷰(테스트 코드 품질)를 병행하여 검증합니다.
- 커밋 이력과 PR 이력은 최근 3개월 이내의 활동을 기준으로 검증합니다.