심사 요청 및 접수
심사 요청 및 접수는 TQS 인증 절차의 2단계로, 프로젝트 팀이 사전 검토를 완료한 후 정식 심사를 신청하는 과정입니다. 본 장은 제출해야 하는 산출물, 산출물 작성 가이드, 접수 절차, 심사 비용, 일정 조율에 대해 정의합니다.
31.3.1. 제출 산출물
프로젝트 팀은 심사 요청 시 다음의 산출물을 제출해야 합니다. 산출물은 필수와 권장으로 구분되며, 필수 산출물이 누락된 경우 접수가 반려됩니다.
| 번호 | 산출물 | 설명 | 필수 여부 |
|---|---|---|---|
| 1 | 자체 점검 체크리스트 | 항목별 충족 여부 및 근거 (스크린샷/링크 포함) | 필수 |
| 2 | 프로젝트 저장소 접근 권한 | 소스코드 리뷰를 위한 읽기 권한 (GitHub) | 필수 |
| 3 | CI/CD 파이프라인 결과 | 최근 5회 빌드/테스트 통과 이력 (CircleCI) | 필수 |
| 4 | 테스트 커버리지 리포트 | JaCoCo (백엔드) + Vitest coverage (프론트엔드) | 필수 |
| 5 | 의존성 보안 스캔 리포트 | OWASP Dependency-Check 결과 | 권장 |
| 6 | Lighthouse 리포트 | 성능/접근성 점수 (프론트엔드 포함 프로젝트) | 권장 |
| 7 | 프로젝트 아키텍처 문서 | 시스템 구성도, 기술 스택 설명, 주요 설계 결정 사항 | 권장 |
필수 산출물은 TQS 위원회가 심사를 수행하기 위한 최소한의 자료입니다. 권장 산출물은 심사의 효율성을 높이고 프로젝트에 대한 심사위원의 이해도를 향상시키는 보조 자료입니다. 권장 산출물을 제출하지 않아도 심사는 진행되지만, 해당 영역의 심사에 더 많은 시간이 소요될 수 있습니다.
우수 또는 최우수 등급을 목표로 하는 프로젝트는 권장 산출물을 모두 제출하는 것을 권장합니다. 권장 항목의 충족 여부를 증명하는 근거 자료로 활용되기 때문입니다.
31.3.2. 산출물 작성 가이드
각 산출물의 구체적인 작성 방법과 형식을 안내합니다. 산출물은 정해진 형식에 맞추어 작성해야 하며, 형식이 맞지 않는 경우 보완 요청을 받을 수 있습니다.
31.3.2.1. 자체 점검 체크리스트
자체 점검 체크리스트는 TQS 인증 체크리스트(32장)의 모든 항목에 대해 충족 여부를 기록한 문서입니다.
| 작성 항목 | 작성 방법 |
|---|---|
| 항목 번호 | 체크리스트 원본의 항목 번호를 그대로 사용 |
| 충족 여부 | 충족(O), 부분 충족(△), 미충족(X)으로 표기 |
| 근거 자료 | 충족의 경우: 설정 파일 경로, 스크린샷, CI 로그 링크 |
| 부분 충족의 경우: 현재 수치와 목표 수치 명시 | |
| 미충족의 경우: 미충족 사유 기재 | |
| 비고 | 해당 항목에 대한 추가 설명 또는 특이사항 |
자체 점검 체크리스트는 심사의 출발점이 됩니다. 정확하고 솔직하게 작성해야 하며, 실제 상태와 다르게 기재할 경우 심사 과정에서 신뢰성 문제가 발생할 수 있습니다.
31.3.2.2. 프로젝트 저장소 접근 권한
TQS 위원회가 소스코드를 직접 확인할 수 있도록 GitHub 저장소의 읽기 권한을 부여해야 합니다.
- 저장소가 private인 경우, TQS 위원회의 GitHub 조직 계정 또는 심사위원 개인 계정에 Collaborator 권한(Read)을 부여합니다.
- 저장소가 organization 소속인 경우, 해당 organization의 team에 TQS 위원회 계정을 추가합니다.
- 접근 권한은 심사 기간 동안 유지되어야 하며, 심사 완료 후 해제할 수 있습니다.
- 저장소의 기본 브랜치(main 또는 master)가 심사 대상 버전의 최신 상태를 반영해야 합니다.
31.3.2.3. CI/CD 파이프라인 결과
CI/CD 파이프라인 결과는 프로젝트의 빌드, 테스트, 린트 검증이 지속적으로 통과하고 있음을 증명하는 자료입니다.
| 제출 항목 | 상세 요건 |
|---|---|
| 최근 5회 빌드 이력 | CircleCI 대시보드 스크린샷 또는 빌드 URL |
| 각 빌드의 단계별 결과 | 린트, 테스트, 빌드 각 단계의 성공/실패 상태 |
| 실패 이력 포함 여부 | 최근 5회 중 실패가 있는 경우 실패 사유와 해결 내역 포함 |
| 파이프라인 설정 파일 | .circleci/config.yml 파일 경로 확인 가능 상태 |
최근 5회 빌드가 모두 성공 상태여야 합니다. 5회 중 실패가 포함된 경우, 해당 실패의 원인과 해결 과정을 명시해야 합니다. 반복적인 빌드 실패 이력은 심사 시 부정적 요소로 작용할 수 있습니다.
31.3.2.4. 테스트 커버리지 리포트
테스트 커버리지 리포트는 프로젝트의 테스트 충분성을 정량적으로 증명하는 자료입니다.
백엔드 (JaCoCo):
mvn test jacoco:report실행 후 생성되는 HTML 리포트를 제출합니다.- 리포트 경로:
target/site/jacoco/index.html - 라인 커버리지 80% 이상, 브랜치 커버리지 70% 이상을 충족해야 합니다.
- 전체 프로젝트 수준의 커버리지와 패키지별 커버리지를 모두 확인할 수 있어야 합니다.
프론트엔드 (Vitest):
npx vitest run --coverage실행 후 생성되는 커버리지 리포트를 제출합니다.- 라인 커버리지 80% 이상, 브랜치 커버리지 70% 이상을 충족해야 합니다.
- 컴포넌트 테스트, 컴포저블 테스트, 스토어 테스트의 커버리지를 모두 포함해야 합니다.
31.3.2.5. 의존성 보안 스캔 리포트
OWASP Dependency-Check를 실행하여 생성된 보안 스캔 리포트를 제출합니다. 이 산출물은 권장 사항이지만, 우수 또는 최우수 등급을 목표로 하는 경우 제출해야 합니다.
mvn dependency-check:check실행 후 생성되는 HTML 리포트를 제출합니다.- CVSS (Common Vulnerability Scoring System) 7 이상의 취약점이 없어야 합니다.
- 취약점이 존재하는 경우, 대응 계획(버전 업그레이드 일정 등)을 함께 제출합니다.
31.3.2.6. Lighthouse 리포트
프론트엔드를 포함하는 프로젝트는 Lighthouse 리포트를 제출하는 것을 권장합니다.
- Chrome DevTools의 Lighthouse 탭 또는 Lighthouse CLI를 사용하여 리포트를 생성합니다.
- 주요 페이지(로그인, 대시보드, 주요 기능 페이지) 각각에 대한 리포트를 제출합니다.
- 성능 점수 90점 이상을 충족해야 합니다.
- 접근성, 권장 사항(Best Practices), SEO 점수도 참고 자료로 포함합니다.
31.3.2.7. 프로젝트 아키텍처 문서
프로젝트의 전체적인 기술 구조를 설명하는 문서입니다. 심사위원이 프로젝트를 빠르게 이해하는 데 도움을 줍니다.
- 시스템 구성도 (백엔드, 프론트엔드, 데이터베이스, 외부 연동 구성)
- 기술 스택 목록 및 선정 사유
- 주요 설계 패턴 및 아키텍처 결정 사항
- 디렉토리 구조 설명
31.3.3. 접수 절차
심사 요청의 접수 절차는 다음의 4단계로 진행됩니다.
31.3.3.1. 절차 흐름
각 단계의 상세 내용은 다음과 같습니다.
| 단계 | 수행 주체 | 활동 | 소요 기간 |
|---|---|---|---|
| 제출 | 프로젝트 팀 | 산출물 일체를 TQS 위원회에 제출 | — |
| 서류 확인 | TQS 위원회 | 필수 산출물 포함 여부, 형식 적합성 확인 | 1영업일 |
| 접수 통보 | TQS 위원회 | 접수 완료 또는 보완 요청 통보 | 1영업일 |
| 심사 일정 확정 | TQS 위원회 | 심사 시작일, 심사위원 배정 통보 | 2영업일 |
31.3.3.2. 서류 확인 기준
TQS 위원회는 제출된 산출물에 대해 다음 사항을 확인합니다.
- 필수 산출물 4종이 모두 포함되어 있는지 확인합니다.
- 각 산출물의 형식이 본 장에서 정의한 기준에 부합하는지 확인합니다.
- 프로젝트 저장소에 대한 접근 권한이 정상적으로 부여되었는지 확인합니다.
- 자체 점검 체크리스트가 전체 항목을 포함하고 있는지 확인합니다.
서류 확인 결과 미비 사항이 있는 경우, TQS 위원회는 프로젝트 팀에 보완 요청을 통보합니다. 보완 요청에는 미비 사항의 구체적인 내용과 보완 기한이 포함됩니다. 보완 기한은 통보일로부터 3영업일 이내입니다.
31.3.3.3. 접수 반려 사유
다음에 해당하는 경우 심사 요청이 반려됩니다.
- 필수 산출물이 누락된 경우
- 자체 점검 체크리스트에서 필수 항목의 미충족이 명백한 경우 (미충족 필수 항목이 5건 이상)
- 프로젝트 저장소 접근이 불가능한 경우
- 보완 요청에 대해 기한 내 보완이 이루어지지 않은 경우
접수가 반려된 경우, 프로젝트 팀은 반려 사유를 해소한 후 다시 심사를 요청할 수 있습니다. 재요청에 대한 횟수 제한은 없습니다.
31.3.4. 심사 비용
TQS 인증은 티에니피아 내부 인증 제도입니다. 따라서 별도의 심사 비용은 발생하지 않습니다.
TQS 위원회의 심사 수행은 위원회 업무의 일환으로 처리됩니다. 프로젝트 팀은 심사 요청 시 별도의 비용을 부담하지 않으며, 심사 결과에 따른 추가 비용도 발생하지 않습니다.
다만, 보완 작업에 소요되는 개발 리소스는 프로젝트 팀의 부담입니다. 사전 검토 단계에서 충분한 준비를 통해 보완 작업을 최소화하는 것이 효율적입니다.
외부 자문이 필요한 경우, 해당 비용은 TQS 위원회 운영 예산에서 집행됩니다. 프로젝트 팀에 별도 비용이 청구되지 않습니다.
31.3.5. 일정 조율
심사 일정은 TQS 위원회와 프로젝트 팀이 협의하여 확정합니다. 프로젝트의 릴리즈 일정과 심사 일정이 충돌하지 않도록 사전에 조율해야 합니다.
31.3.5.1. 심사 시작 기한
심사 요청 접수일로부터 5영업일 이내에 심사를 시작해야 합니다. TQS 위원회는 접수 통보 시 심사 시작 예정일을 함께 안내합니다.
5영업일 이내 심사 시작이 어려운 경우(위원회 일정, 동시 심사 건수 초과 등), TQS 위원회는 프로젝트 팀에 지연 사유와 변경된 심사 시작 예정일을 통보해야 합니다.
31.3.5.2. 릴리즈 일정 고려
프로젝트 팀은 심사 요청 시 다음 릴리즈 일정을 함께 제출하는 것을 권장합니다. TQS 위원회는 프로젝트의 릴리즈 일정을 고려하여 심사를 진행합니다.
- 릴리즈 예정일이 임박한 경우, 우선 심사를 요청할 수 있습니다.
- 우선 심사는 TQS 위원회의 판단에 따라 수용 여부가 결정됩니다.
- 우선 심사가 수용된 경우에도 심사 기준은 동일하게 적용됩니다.
31.3.5.3. 심사 일정 변경
접수 확정 후 심사 일정의 변경이 필요한 경우, 심사 시작 예정일의 2영업일 전까지 변경을 요청해야 합니다. 심사 시작일 이후의 일정 변경은 원칙적으로 허용하지 않습니다.
심사 진행 중 프로젝트 측의 사유로 심사가 중단되는 경우, 해당 심사는 취소 처리되며, 추후 새로운 심사 요청을 통해 다시 진행해야 합니다.