테스트

1. 테스트 계획

이 프로젝트에는 사람 리뷰 게이트가 없다. 2026. 08. 28. 개정으로 사전 확인을 없앴고, 09. 04.부터는 브랜치 → PR → 자체 머지다 — 승인자가 없고 자기 PR 을 자기가 머지한다. 그리고 main 머지 = 2분 후 프로덕션 배포(서버 systemd timer 자동 CD)다. 사람이 빠진 자리에 무엇을 놓을지가 이 장의 전제였고, 답은 CI 초록 하나였다. 규약에 그대로 적혀 있다 — "CI 빨간불인 PR 은 머지하지 않는다. main 이 빨간불이면 다른 작업보다 우선 수정."

계기는 사고다. 2026. 09. 01. 하루에 깨진 main 을 두 번 발견했고 둘 다 우연이었다 (d7fdd10 · d96749e). 그래서 CI 를 넣을 때의 목적을 "게이트"가 아니라 "깨졌다는 사실만 즉시 보이게"로 잡았다 — 우정 B 가 09. 02. 게이트(09. 04.)를 앞두고 먼저 올렸고, 파일 소유는 인프라 도메인이라 사후 공지로 처리했다.

층위 — 무엇을 어느 시점에 재는가

안 한 것도 적는다. 프론트엔드에는 테스트 코드가 없다 — tsc -b 가 사실상의 회귀 그물이고, 그 이상은 남은 기간에 넣지 않기로 했다. AI 면접 서버에도 린트를 아직 붙이지 않았다: 기존 오류 5건(analyze_file · app · deception_vit · interview_ws · test_interview_ws)이 남아 있어 지금 붙이면 아무도 안 보는 빨간 CI 가 되기 때문이다. 다음 ai/ 변경 때 정리한 뒤 붙인다.

2. 단위 및 통합 테스트

CI(.github/workflows/ci.yml)는 잡 5개다. 같은 브랜치에 연달아 push 하면 앞의 실행을 취소한다(concurrency + cancel-in-progress) — 무료 러너 분을 아끼기 위해서다. 아래 표의 칩은 그 잡을 실제로 올린 사람이다 — 파일 자체는 인프라 도메인이라, 남이 올린 경우는 사후 공지로 처리했다.

백엔드 — 목 DB 를 안 쓴다

테스트 DB 를 흉내로 대체하지 않았다. CI 는 pgvector/pgvector:pg16 서비스 컨테이너를 띄운다 — 순정 postgres 를 쓰면 vector 확장이 없어 conftest 가 application_embeddings 를 건너뛰고, 그러면 임베딩 경로가 CI 에서 통째로 안 돈다. 로컬 docker-compose 와 같은 이미지를 쓰는 이유가 그것이다. 격리는 트랜잭션으로 한다 — db fixture 가 각 테스트를 트랜잭션으로 감싸고 끝나면 롤백해서 DB 에 흔적이 남지 않는다.

파일 52개에 def test_ 가 1,084개이고, parametrize 확장까지 포함해 1,165건이 통과한다(커밋 a650123 — 같은 실행에서 55건은 skip, 그 로컬에 pgvector 가 없어서다). 09. 02. 실측 기준으로는 486건에 CI 14.5초 · 로컬 88.6초였다 — 로컬이 느린 것은 WSL 이 /mnt/c 를 읽는 속도 탓이지 테스트 탓이 아니다. 백엔드 로드맵의 W5 완료 기준("uv run pytest 30초 내")은 러너에서는 이미 만족한다.

CI 가 잡은 것 — pytest 만으로는 안 보이던 두 종류

회귀 하네스 — 기본 스위트 밖에 둔 이유

소연 D 도메인의 에이전트는 "되냐"가 아니라 "얼마나 잘 되냐"를 재야 한다. 그래서 backend/tests/prompt_regression/ 는 실 백엔드 (localhost:8000)에 실호출하고, @pytest.mark.regression 이 붙어 기본 pytest -q 에서 자동으로 제외된다 — 시나리오 하나당 5~40초라 CI 기본 스위트에 끼면 매 PR 이 몇 분씩 밀린다. -m regression 을 명시해야만 돈다.

하네스의 assert 는 최소한만 건다. 대신 구조적 기준 두 가지는 깨지면 채택 불가로 못 박았다 — ① 렌더된 답변에 시드 밖 이름이 없어야 한다(도구 결과 창작 차단) ② change_stage 확인 카드는 기대한 지원자를 가리켜야 한다 (다른 레코드 차단). 성공률 · 응답 시간은 results/*.jsonl 에 append 로 쌓여, 프롬프트를 고친 뒤 다시 돌리면 같은 파일의 diff 로 개선이 보인다. 쓰기 의도는 확인 카드까지만 만들고 실행하지 않으므로 하네스가 DB 를 바꾸지 않는다.

계약과 구조도 스크립트로 잰다

check_public_contract.py 는 배포본 /openapi.json 에서 GET 을 전부 뽑아 토큰 없이 한 번씩 때려 본다. 경로 목록을 코드에 박지 않은 이유는 명시적이다 — 박아두면 새로 생긴 엔드포인트가 대조에서 빠져 무의미해진다. 경로 변수에는 존재하지 않는 값을 넣어 실지원자 데이터에 닿지 않고, 읽기만 한다. 실측은 08. 31. 경로 35/35 · 스키마 62/62, 09. 02. 경로 55/55 · 스키마 75/75 · 필드 불일치 0 이다.

check_architecture.py 는 ADR-0035 헥사고날 적용 상태를 AST 로 센다. 이유를 스크립트가 직접 적고 있다 — "포트 · 어댑터로 바꿨다"는 말은 폴더를 만든 것만으로도 참이 되어 버린다. 2026. 09. 12. 실측값을 기준선으로 박아 --strict 는 원시 DB 접근이 늘면 실패한다. 그때 판정은 "구조는 갖췄지만 실질은 절반"이었고, 그 숫자를 남겨 뒀다.

3. 사용자 인수 테스트

인수 기준은 docs/00_overview/qa-scenarios.md 한 곳이다. 2026. 08. 24. 작성했고, 그 시점에 화면이 아직 없어서 05-design 의 화면 지도를 기준으로 썼다 — 확정되지 않은 UI 디테일은 "(화면 확정 후 갱신)" 으로 표시해 둔다. 각 시나리오는 전제 → 절차 → 기대 결과 세 줄이다: 어떤 상태에서, 누가 무엇을 클릭 · 입력하고, 무엇이 보이면 성공인가.

시나리오는 결정이 바뀌면 같이 고친다. A3 "면접관은 배정된 지원자만 조회"는 08. 31. ADR-0017(등급 이분화)로 폐지됐고, 확인할 것이 "무엇이 열렸는가 · 무엇이 남았는가"로 바뀌어 세 갈래로 쪼갰다 — A3-1 조회는 전원 열려 있다(미배정 10명 포함 12명 전원이 보인다), A3-2 멤버는 배정된 건만 평가를 쓴다(그 외 403), A3-3 면접관 배정 · 남의 가용 시간은 관리자만(단 본인 가용 시간은 멤버도 가능). 시나리오가 낡은 채 남아 있으면 인수 기준이 아니라 오해의 근거가 된다.

1차 게이트 (09. 04.) — 09. 02. 수직 슬라이스 실측

게이트 판정은 문장이 아니라 실데이터 한 번 관통으로 했다. 공개 지원 폼 제출 → DB 저장 → 담당자 확인까지다. 게이트 4항목 중 마지막까지 미충족이던 것이 이 수직 슬라이스였고, 판정일(09. 04.)보다 이틀 앞선 09. 02.에 관통해 닫았다 — 코드 변경 없이 브라우저로 실제 경로를 한 번 통과한 것이다. 기존 공고를 쓰지 않고 검증용 공고(id 3)를 새로 만들어 관통한 뒤 closed 로 내렸다: C6 의 UNIQUE(job_posting_id, email) 에 걸릴 수 있고, 공개 링크 발급이 재발급이라 그 공고의 기존 토큰을 즉시 무효화하기 때문이다.

검증 방법 자체를 기록으로 남겼다. 첨부를 눌러도 브라우저에서 아무 일이 없어 보일 수 있는데, 그것이 기능 실패인지 환경 탓인지 구분하려면 같은 URL 을 iframe 으로 불러 렌더되는지 본다(iframe 로드는 CORS 검사를 안 받는다). 오류 표시와 콘솔이 비어 있는데 화면만 안 바뀌면 환경 쪽이다. 실제로 버킷 CORS 의 AllowedMethods 가 PUT 뿐이라 브라우저 fetch GET 은 막히고, 이 판별법 없이는 서버가 멀쩡하고 로그에도 안 남는 함정에 다시 빠진다.

2차 게이트 (09. 30.) — 아직 안 돌았다

조건은 필수 27개 기능 전부 프로덕션 동작 · 에이전트와 앱도 데모 가능 · QA 시나리오 전 항목 통합 리허설 2회 · 09. 28.~30. 전 도메인 공통 버퍼(코드 프리즈와 잔여 버그)다. 통합 리허설은 W5(09. 21.~25.)에 프로덕션 URL 과 실기기에서 도는 일정이고, 09. 22. 현재 아직 수행 전이다 예정.

외부 인수 — 멘토링이 실질적인 수용 심사였다

내부 QA 와 별개로 IBM 강사 멘토링이 사실상의 인수 창구였다. 09. 10. 멘토가 21개 항목을 짚었고(서류 · AI 요약 6 · 면접 7 · 지원자 쪽 4 · 화면 · 앱 · 학습 4), 팀이 항목마다 현황과 대조해 "이미 동작 / 결정 필요 / 실측 필요"로 갈랐다. 09. 11. 숙제는 "지원자 · 관리자 입장에서 각각 시연 가능하도록 준비"였다 — 두 역할로 갈라 시연한다는 인수 기준이 여기서 나왔다. 09. 18. 피드백의 "모델 비교를 정량적으로"는 09. 22. 같은 채점기 기반 정량 보고서로 반영됐다 — 같은 날짜의 나머지 세 항목은 트래커에서 아직 doing 이다.

4. 결함 추적 및 조치

추적 창구는 셋이다. 하나는 GitHub 이슈 · PR, 하나는 피드백 트래커, 하나는 사람이 아니라 기계다.

도메인 밖 결함은 고치지 않고 넘긴다

다른 도메인에서 문제를 발견하면 직접 고치지 않고 이슈로 오너에게 넘긴다. 실례 — 백엔드가 앱 쪽 프레임 전송 문제를 09. 16.에 이슈 #260 으로 넘기면서 PR #154 를 닫고 살아 있는 항목 둘만 추렸다. 같은 건에서 "얼굴 114/114 no_face" 추적은 앱이 안 보내는 것과 서버가 못 찾는 것을 가르려면 양쪽을 같이 봐야 해서 서버 로그 대조를 백엔드가 맡기로 나눴다. 경계를 넘는 수정보다 경계를 넘는 정보 교환이 싸다.

사고 하나에 장치 하나 — 재발 방지 규칙으로 승격된 것

대조가 잡아낸 결함, 실측이 뒤집은 판정

닫지 못한 것

안 된 것은 안 됐다고 적는다. 09. 15. 세션 75 에서 CPU 전사가 180초 상한을 넘겨 답변이 [전사 지연] 자리표시자로 저장됐다. 전사 속도 자체는 OpenAI API 전환으로 풀렸지만 이미 자리표시자로 남은 답변을 되살리는 경로는 없다 미해결 — 기능 미비가 아니라 지원자 데이터 손실이라 백엔드 큐 23번으로 남은 기간 맨 위에 뒀다. AI 면접 서버 린트 5건도 아직 CI 에 안 붙어 있다 대기. 이 둘은 초록을 만들어 가리지 않고 빨간 채로 문서에 남긴다 — 그것이 "테스트를 통과시키려고 우회하지 않는다"는 규칙의 실제 모습이다.