사전 검토
사전 검토는 TQS 인증 절차의 1단계로, 프로젝트 팀이 정식 심사를 요청하기 전에 자체적으로 규격 부합 여부를 진단하는 과정입니다. 본 장은 사전 검토의 목적, 수행 방법, Gap 분석, 보완 계획, 사전 컨설팅 절차를 정의합니다.
31.2.1. 사전 검토 목적
사전 검토의 핵심 목적은 정식 기술 심사에서의 불합격 리스크를 최소화하는 것입니다. 정식 심사에서 불합격 판정을 받으면 보완 작업 후 1단계부터 다시 시작해야 하므로, 최소 3~4주의 추가 기간이 소요됩니다. 사전 검토를 통해 미충족 항목을 사전에 식별하고 보완함으로써, 인증 획득까지의 전체 소요 시간을 단축할 수 있습니다.
사전 검토를 수행하면 다음의 효과를 기대할 수 있습니다.
- 정식 심사 전 프로젝트의 규격 충족 현황을 객관적으로 파악할 수 있습니다.
- 미충족 항목에 대한 보완 우선순위를 명확히 설정할 수 있습니다.
- 팀 내 TQS 규격에 대한 이해도를 높이고, 규격 준수 문화를 내재화할 수 있습니다.
- 불필요한 재심사를 방지하여 TQS 위원회와 프로젝트 팀 양측의 리소스를 절약할 수 있습니다.
사전 검토는 프로젝트 팀의 책임 하에 수행됩니다. 프로젝트 리드가 사전 검토의 총괄 책임을 지며, 개발팀이 실제 점검 작업을 수행합니다. 사전 검토의 소요 기간은 프로젝트 규모와 규격 충족 수준에 따라 1~2주입니다.
31.2.2. 자체 점검 수행
자체 점검은 TQS 인증 체크리스트(32장)를 기준으로 프로젝트의 각 항목별 충족 여부를 확인하는 작업입니다. 자체 점검은 자동화 도구를 활용한 정량적 검증과 수동 확인을 병행하여 수행합니다.
31.2.2.1. 체크리스트 기반 점검
프로젝트 팀은 TQS 인증 체크리스트(32장)의 모든 항목에 대해 충족 여부를 확인해야 합니다. 각 항목에 대해 다음 정보를 기록합니다.
| 기록 항목 | 설명 |
|---|---|
| 항목 번호 | 체크리스트 항목의 고유 번호 |
| 충족 여부 | 충족 / 부분 충족 / 미충족 |
| 근거 자료 | 충족을 증명하는 스크린샷, 설정 파일 경로, 링크 |
| 비고 | 부분 충족 또는 미충족 시 사유 및 보완 계획 |
체크리스트 점검 시 항목의 필수/권장 구분을 명확히 인지해야 합니다. 필수 항목은 100% 충족해야 인증을 획득할 수 있으며, 권장 항목의 충족률은 인증 등급(기본/우수/최우수)에 영향을 미칩니다.
31.2.2.2. 자동화 도구 실행
자체 점검의 정량적 항목은 자동화 도구를 실행하여 검증합니다. 다음 도구들의 실행 결과를 수집하고 기록해야 합니다.
| 도구 | 검증 대상 | 실행 명령 | 기준 |
|---|---|---|---|
| Spotless | 백엔드 코드 포매팅 | mvn spotless:check | 위반 0건 |
| ESLint | 프론트엔드 린트 | npx eslint . | 에러 0건 |
| Prettier | 프론트엔드 포매팅 | npx prettier --check . | 위반 0건 |
| JaCoCo | 백엔드 테스트 커버리지 | mvn test jacoco:report | 라인 80%, 브랜치 70% |
| Vitest | 프론트엔드 테스트 커버리지 | npx vitest run --coverage | 라인 80%, 브랜치 70% |
| Lighthouse | 프론트엔드 성능/접근성 | Chrome DevTools 또는 CLI | 성능 90점 이상 |
| OWASP Dependency-Check | 의존성 보안 취약점 | mvn dependency-check:check | CVSS 7 이상 0건 |
자동화 도구의 실행 결과는 정식 심사 시 제출하는 산출물의 기초 자료가 됩니다. 따라서 실행 결과를 파일로 저장하고, 실행 일시와 환경 정보를 함께 기록하는 것을 권장합니다.
31.2.2.3. 미충족 항목 식별
자체 점검 결과 미충족 또는 부분 충족으로 분류된 항목을 별도로 목록화합니다. 미충족 항목 목록에는 다음 정보를 포함해야 합니다.
- 항목 번호 및 항목명
- 필수/권장 구분
- 현재 상태 (부분 충족 시 충족률 또는 현황 기술)
- 미충족 사유
- 예상 보완 난이도 (상/중/하)
미충족 항목 목록은 Gap 분석과 보완 계획 수립의 입력 자료로 활용됩니다.
31.2.3. Gap 분석
Gap 분석은 프로젝트의 현재 상태와 TQS 요구사항 사이의 차이를 체계적으로 분석하는 과정입니다. 자체 점검에서 식별된 미충족 항목을 기반으로 Gap의 규모, 원인, 영향도를 분석합니다.
31.2.3.1. 비교 매트릭스 작성
Gap 분석의 첫 단계는 현재 상태와 TQS 요구사항의 비교 매트릭스를 작성하는 것입니다. 비교 매트릭스는 각 체크리스트 영역별로 작성하며, 항목별 충족 상태를 시각적으로 파악할 수 있도록 구성합니다.
충족 상태는 다음 3가지로 분류합니다.
| 충족 상태 | 정의 | 조치 |
|---|---|---|
| 충족 | TQS 요구사항을 완전히 만족하는 상태 | 추가 조치 불필요 |
| 부분 충족 | TQS 요구사항의 일부만 만족하는 상태 | 미충족 부분 보완 필요 |
| 미충족 | TQS 요구사항을 전혀 만족하지 않는 상태 | 전면적 보완 또는 신규 구현 필요 |
31.2.3.2. Gap 분석 결과 예시
다음은 Gap 분석 결과 테이블의 작성 예시입니다. 프로젝트 팀은 이 형식을 참고하여 실제 프로젝트의 Gap 분석 결과를 작성합니다.
| 영역 | 항목 | TQS 요구사항 | 현재 상태 | 충족 상태 | Gap 설명 |
|---|---|---|---|---|---|
| 코드 컨벤션 | Spotless 적용 | 빌드 시 포맷 검증 자동화 | spotless-maven-plugin 설정 완료 | 충족 | — |
| 테스트 | 라인 커버리지 | 80% 이상 | 72% | 부분 충족 | 8%p 부족, 서비스 계층 테스트 보강 필요 |
| 보안 | OWASP 스캔 | CVSS 7 이상 취약점 0건 | 미적용 | 미충족 | 플러그인 설정 및 최초 스캔 필요 |
| CI/CD | 보안 스캔 단계 | 파이프라인에 보안 스캔 포함 | 린트/테스트/빌드만 구성 | 미충족 | CircleCI 설정에 보안 스캔 단계 추가 필요 |
| 프론트엔드 | Lighthouse 점수 | 성능 90점 이상 | 85점 | 부분 충족 | 이미지 최적화, 코드 스플리팅 보강 필요 |
Gap 분석 결과에서 필수 항목의 미충족 건수가 전체 필수 항목의 10%를 초과하는 경우, 보완 작업에 상당한 시간이 소요될 수 있으므로 심사 일정을 신중하게 수립해야 합니다.
31.2.4. 보완 계획 수립
Gap 분석 결과를 기반으로 미충족 항목에 대한 구체적인 보완 계획을 수립합니다. 보완 계획은 프로젝트 리드가 총괄하며, 개발팀과 협의하여 실현 가능한 일정으로 수립해야 합니다.
31.2.4.1. 우선순위 결정
미충족 항목의 보완 우선순위는 다음 기준에 따라 결정합니다.
| 우선순위 | 기준 | 예시 |
|---|---|---|
| 1순위 | 필수 항목 중 보안 관련 | Spring Security 설정, SQL 파라미터 바인딩, 시크릿 관리 |
| 2순위 | 필수 항목 중 코드 품질 관련 | 포매터 적용, 네이밍 규칙, 패키지 구조 |
| 3순위 | 필수 항목 중 테스트/CI 관련 | 테스트 커버리지, CI/CD 파이프라인 구성 |
| 4순위 | 권장 항목 (우수/최우수 등급 목표 시) | OWASP 스캔, Lighthouse 최적화, 키보드 네비게이션 |
필수 항목은 반드시 보완해야 하며, 권장 항목은 목표 인증 등급에 따라 보완 여부를 결정합니다. 기본 인증만 목표로 하는 경우 권장 항목의 보완은 선택 사항입니다.
31.2.4.2. 보완 작업 일정 수립
보완 계획에는 각 미충족 항목에 대해 다음 정보를 포함해야 합니다.
- 보완 작업 내용 (구체적인 작업 범위 기술)
- 담당자 (작업을 수행할 개발자 또는 팀)
- 시작일 및 완료 예정일
- 의존 관계 (다른 보완 작업과의 선후 관계)
- 검증 방법 (보완 완료를 어떻게 확인할 것인지)
보완 작업 일정은 프로젝트의 기존 개발 일정과 병행 가능한 수준으로 수립해야 합니다. 인증 준비를 위해 릴리즈 일정이 지연되는 상황은 최소화해야 합니다.
31.2.4.3. 예상 소요 기간 산정
보완 작업의 예상 소요 기간은 미충족 항목의 규모와 난이도에 따라 달라집니다. 다음은 주요 보완 작업 유형별 예상 소요 기간입니다.
| 보완 작업 유형 | 예상 소요 기간 | 비고 |
|---|---|---|
| 포매터/린터 설정 적용 | 1~2일 | 도구 설정 후 일괄 적용 가능 |
| 네이밍 규칙 리팩토링 | 2~5일 | 프로젝트 규모에 비례 |
| 테스트 커버리지 보강 | 3~7일 | 부족분에 비례 |
| CI/CD 파이프라인 구성 | 1~3일 | 기존 파이프라인 유무에 따라 상이 |
| 보안 설정 적용 | 2~5일 | 항목 수와 복잡도에 따라 상이 |
| 프로젝트 구조 리팩토링 | 3~10일 | 프로젝트 규모와 현재 상태에 비례 |
31.2.5. 사전 컨설팅
프로젝트 팀은 사전 검토 과정에서 TQS 위원회에 비공식 사전 컨설팅을 요청할 수 있습니다. 사전 컨설팅은 규격 해석이 불분명하거나 적용 방법에 대한 조언이 필요한 경우에 활용합니다.
31.2.5.1. 컨설팅 요청 방법
사전 컨설팅은 TQS 위원회에 이메일 또는 사내 커뮤니케이션 도구를 통해 비공식적으로 요청합니다. 요청 시 다음 정보를 포함해야 합니다.
- 프로젝트명 및 담당자
- 질의 항목 (체크리스트 번호 또는 규격 조항)
- 구체적인 질의 내용
- 현재 적용 상태 (가능한 경우 코드 또는 설정 예시 포함)
사전 컨설팅 요청은 심사 요청과 독립적으로 이루어지며, 사전 컨설팅을 받지 않아도 심사 요청에는 영향이 없습니다.
31.2.5.2. 컨설팅 범위
사전 컨설팅에서 다루는 범위는 다음과 같습니다.
- TQS 규격의 특정 조항에 대한 해석 질의
- 특정 기술 스택에서의 규격 적용 방법 조언
- 체크리스트 항목의 충족 기준 확인
- 자체 점검 결과에 대한 사전 의견 제공
사전 컨설팅에서 다루지 않는 범위는 다음과 같습니다.
- 구체적인 코드 작성 대행
- 사전 심사 판정 (합격/불합격 예측)
- 정식 심사에서의 판정 결과 보장
31.2.5.3. 컨설팅 결과의 효력
사전 컨설팅에서 제공된 의견은 참고 사항이며, 정식 심사 결과에 직접적인 영향을 미치지 않습니다. 사전 컨설팅에서 "문제없다"는 의견을 받았더라도 정식 심사에서 해당 항목이 미충족으로 판정될 수 있습니다. 이는 사전 컨설팅이 비공식적 성격을 가지며, 정식 심사에서는 더 엄격한 기준이 적용될 수 있기 때문입니다.
다만, 사전 컨설팅에서 제공된 조언을 성실히 이행한 경우, 정식 심사에서의 통과 가능성을 높일 수 있습니다. 프로젝트 팀은 사전 컨설팅 내역을 기록하고, 해당 조언에 따른 조치 결과를 산출물에 포함하는 것을 권장합니다.