테스트와 AI 개발 품질

세금 계산 함수의 경계값은 unit test가 빠르게 확인할 수 있지만, JSON에서 금액 단위가 잘못 직렬화되거나 migration이 column을 누락한 문제는 integration 경계에서만 드러납니다. Browser E2E는 사용자가 버튼을 눌러 최종 결과를 보는 전체 경로를 확인하지만 실패 원인을 좁히는 비용이 큽니다. 같은 결함을 모든 층에 복제하기보다 가장 싸게 발견할 층과 반드시 지켜야 할 핵심 journey를 나눕니다.

검사 층을 설계할 때는 “몇 퍼센트가 unit인가”보다 최근 사고가 어디에서 빠져나갔는지 봅니다. Type은 맞았지만 authorization이 빠졌다면 contract와 abuse test가 필요하고, API는 맞았지만 keyboard로 제출하지 못했다면 browser test가 필요합니다. 결함 분류를 정기적으로 갱신해야 suite가 실제 risk를 따라갑니다.

현재 시간을 직접 읽는 만료 함수는 test 실행 시점마다 결과가 달라집니다. Clock을 입력 dependency로 전달하면 만료 직전, 정확한 경계와 만료 후를 같은 값으로 반복할 수 있습니다. Random ID, environment variable과 global cache도 같은 방식으로 제어해야 실패가 code 때문인지 환경 때문인지 분리됩니다.

Mock은 외부 결제 호출을 막는 데 유용하지만 내부 helper가 몇 번 불렸는지만 검사하면 구현을 그대로 복제합니다. 입력과 반환된 업무 결과, 저장된 state처럼 사용자가 관찰할 계약을 우선 확인하고 adapter 자체는 실제 protocol에 가까운 contract test로 보완합니다. Mutation을 넣었는데 test가 계속 통과한다면 coverage 숫자와 관계없이 중요한 assertion이 빠진 것입니다.

Consumer가 `status: "paid"`를 기대하는데 provider가 enum을 `completed`로 바꾸면 JSON schema가 각각 유효해도 함께 실행할 때 실패합니다. Contract test는 실제 consumer 기대와 provider 응답을 version별로 비교해야 합니다. Error status, retry header, pagination과 authorization도 정상 response만큼 계약의 일부입니다.

Database 변경은 특히 시간축을 포함합니다. 먼저 nullable column을 추가한 뒤 old code와 new code가 함께 읽고 쓸 수 있는지 확인하고, backfill이 끝난 뒤에만 not-null을 강제하는 방식이 필요할 수 있습니다. Migration test는 빈 database뿐 아니라 대표 크기의 기존 data, 중단 후 재실행과 rollback 조건을 검증해야 운영 배포를 설명할 수 있습니다.

Playwright에서 `button`의 CSS class를 찾는 test는 디자인 refactor에 쉽게 깨지면서도 사용자가 인식할 label이 사라진 문제는 놓칠 수 있습니다. `getByRole("button", { name: "주문 제출" })`처럼 접근 가능한 role과 이름으로 찾고, 클릭 뒤 주문 번호와 상태가 보이는지 확인하면 test가 사용자 계약에 가까워집니다.

Browser test의 기다림도 업무 신호를 따라야 합니다. 3초 sleep은 빠른 환경을 낭비하고 느린 환경에서는 여전히 실패하지만, 성공 message나 network response와 연결된 assertion은 조건이 충족되는 순간 끝납니다. 각 test에 독립 account와 order를 만들고 완료 후 정리하면 병렬 실행과 재시도에서도 이전 state가 결과를 오염시키지 않습니다.

AI가 production 오류를 고칠 때는 먼저 사용자가 관찰한 실패를 자동 test로 옮기고 그 test가 기존 revision에서 실패하는지 확인해야 합니다. Agent가 code와 test 기대값을 동시에 바꾸면 잘못된 결과를 새로운 정답으로 만들 수 있으므로 issue의 acceptance criterion이나 독립 oracle과 diff를 대조합니다.

Release gate에는 성공한 명령 이름만이 아니라 실행한 source revision, dependency lock, build artifact digest와 결과 파일이 연결되어야 합니다. 간헐 실패를 재시도로 감추거나 영향 test를 임의로 제외하면 green 표시의 의미가 사라집니다. 배포 뒤에는 같은 대표 journey와 운영 metric으로 regression이 없는지 확인하고 임계값을 넘으면 자동 중단하거나 rollback합니다.

교육용 배송비 정책은 할인 후 상품 합계가 30,000원 이상이면 무료라고 가정합니다. 원가 32,000원에 할인 3,000원이 적용되면 비교 대상은 29,000원입니다. 원가로 무료 배송을 판정하는 구현과 그 구현을 복사한 테스트는 함께 통과할 수 있습니다. 배송비 금액 자체는 별도 정책값으로 두어 무료 조건과 요금표 변경을 혼동하지 않게 합니다.

검토자는 정책 문장의 할인 후라는 조건을 계산표에 표시하고 배송비가 부과되는 기대값을 직접 정합니다. 개발자는 그 표의 식별자를 테스트 이름에 연결합니다. 코드 수정자가 정책도 바꿨다면 동작 수정과 요구 변경을 같은 것으로 취급하지 않고 별도 검토합니다. 표의 승인 날짜도 남겨 나중에 정책 개정으로 기대값이 바뀐 경우를 회귀 결함과 구분합니다.

반대로 출력 전체를 고정한 화면 스냅샷은 날짜 문구가 바뀔 때도 실패할 수 있습니다. 배송비 규칙을 검증하려는 목적이라면 금액과 적용 이유를 직접 확인하는 편이 원인을 좁힙니다. 문구와 배치가 요구인 경우에만 해당 스냅샷을 별도 근거로 유지합니다. 관련 없는 화면 변화가 검사 실패를 반복하면 담당자가 진짜 금액 오류까지 무시할 수 있습니다.

검증을 마치려면 비교 연산을 의도적으로 바꾼 후보가 경계 테스트에서 실패하는지 확인합니다. 30,000원과 29,999원을 함께 넣으면 이상과 초과를 혼동한 결함을 구분할 수 있습니다. 이 실패 기록을 남겨야 테스트가 단순 실행 확인을 넘어 정책을 감시한다는 근거가 생깁니다. 경계 안팎의 결과를 함께 보아야 테스트가 항상 같은 값만 반환하는 가짜 구현도 거부합니다.

교육용 계정 설정 테스트 두 개가 같은 사용자의 표시 이름을 바꾼다고 가정합니다. 각각은 저장 완료를 기다리지만 병렬 실행에서는 상대 테스트가 마지막 값을 덮어씁니다. 버튼 대기 시간을 늘려도 공유된 데이터 소유권은 달라지지 않습니다. 공유 계정을 단독 실행할 때는 충돌이 없으므로 로컬 성공이 병렬 실행 안전성을 입증하지 못합니다.

실패한 실행의 요청 본문과 응답 뒤 조회값을 비교하면 두 개의 다른 이름이 같은 사용자 식별자로 기록됩니다. 별도 계정으로 바꾼 뒤 같은 병렬도와 응답 지연을 유지합니다. 저장 성공 안내와 새로고침 후 이름이 모두 맞으면 경쟁 조건을 제거했다는 근거가 됩니다. 각 요청의 소유 계정까지 기록하면 다른 테스트의 저장 결과를 성공으로 읽는 경우도 구분합니다.

반례로 외부 서비스가 테스트 시간에 실제로 중단됐다면 계정 격리만으로는 복구되지 않습니다. 내부 화면 동작 검사는 통제된 오류 응답으로 고정하고 외부 연결 검사는 별도 계약으로 나눕니다. 그래야 외부 장애와 앱의 잘못된 오류 안내가 같은 실패 이름에 섞이지 않습니다. 외부 대역의 오류 코드와 본문은 앱이 처리해야 하는 실제 계약에 맞춰야 진단 가치가 있습니다.

마지막에는 실패했던 병렬 조건을 다시 실행하고 최초 실패 기록과 수정 후 기록을 나란히 둡니다. 재시도 없이 성공한 결과와 데이터 충돌이 사라진 관찰을 함께 남깁니다. 실행 횟수만 늘린 결과는 원인 제거의 대체 증거가 아닙니다. 격리한 데이터가 실행 뒤 정리되는지도 확인해 다음 실행에 남는 상태가 다시 원인이 되지 않게 합니다.

교육용 도서 검색에서 먼저 입력한 바다의 응답을 보류하고 나중에 입력한 산의 응답을 먼저 반환합니다. 산 목록이 나타난 뒤 바다 응답을 풀어 줍니다. 최종 입력과 결과가 모두 산이면 오래된 성공 응답을 무시한 것입니다. 두 결과의 제목과 항목을 다르게 만들어 입력만 바뀌고 목록은 그대로인 거짓 통과도 구분합니다.

반례는 성공 응답만 제어하는 테스트입니다. 이전 바다 요청을 오류로 끝내면 현재 산 결과가 사라질 수도 있습니다. 이전 성공과 이전 실패 두 경로를 별도 실행해야 응답 상태에 관계없이 최신 선택을 지킨다는 근거가 생깁니다. 오류 안내가 최신 요청 식별자에 묶이지 않았다면 성공 목록을 지켜도 잘못된 경고가 남을 수 있습니다.

접근성 관찰도 같은 흐름에 포함합니다. 결과 수 안내가 오래된 목록의 수를 읽거나 로딩 표시가 영원히 남으면 시각적 목록만 맞아도 완료가 아닙니다. 현재 요청의 목록, 로딩 종료와 보조기술 안내를 함께 확인합니다. 화면에 나타난 상태와 보조기술이 읽는 상태가 같은 요청을 설명하는지 확인하는 것이 목적입니다.

검증 자료에는 요청을 잡은 순서, 풀어 준 순서와 각 시점의 기대 상태를 적습니다. 임의의 긴 대기 시간 대신 제어한 응답과 화면 조건을 연결합니다. 실패를 수정한 뒤에도 응답 순서를 그대로 유지해야 회귀 방지 여부를 비교할 수 있습니다. 새 화면으로 이동한 뒤 보류 응답을 풀어 주는 추가 경로는 화면 수명 경계까지 확인하게 합니다.