테스트는 전부 통과했는데 고객 화면에는 프로젝트 목록이 비어 있었습니다 — 화면 수정은 「통과」가 아니라 실제 기기에서 눌러 보고 끝내기로 했습니다

2026년 9월, 저희가 운영하는 앱 하나에서 프로젝트 목록 화면이 운영 환경에서 통째로 보이지 않았습니다.
자동 테스트는 그 시점에도 전부 통과 상태였습니다.

개발 보고서에 적히는 「통과」는 이런 날에도 똑같이 적힙니다.
그래서 화면 작업은 완료 판정 기준 자체를 바꿨습니다.

이 글은 테스트를 버리자는 얘기가 아닙니다.
어떤 작업에 어떤 검사를 붙여야 「끝났다」가 참이 되는지만 다룹니다.

원인은 서버 주소였습니다.
앱이 서버에 목록을 달라고 부르는 주소 앞부분이 두 번 붙어 있었습니다.

「/api/v1/api/v1/…」처럼 생긴 주소는 서버에 없는 주소입니다.
그래서 목록이 한 건도 오지 않았고, 화면은 빈 채로 떴습니다.

이상한 건 테스트였습니다.
테스트는 앱이 「어떤 주소를 부르는지」를 확인하고 있었는데, 그 기대값에 두 번 붙은 틀린 주소가 적혀 있었습니다.

틀린 코드와 틀린 기대값이 서로를 맞다고 확인해 준 셈입니다.
누가 주소를 바르게 고쳤다면 오히려 테스트가 빨간불을 켰을 겁니다.

테스트는 적힌 정답과 같은지만 봅니다. 그 정답이 맞는지는 보지 않습니다.

원인을 확인한 날, 대표가 AI 개발 에이전트에게 보낸 지시는 한 줄이었습니다.

TDD 는 테스트를 먼저 쓰고 그 테스트를 통과하도록 코드를 짜는 방식입니다.
기능 로직에는 잘 맞습니다. 계산이 맞는지, 조건에 따라 분기하는지는 기계가 사람보다 정확히 봅니다.

화면 작업은 다릅니다.
버튼 위치, 목록이 실제로 채워지는지, 글자가 잘리지 않는지는 테스트 코드로 적기 어렵고, 적어도 이번처럼 틀린 정답을 지키기 쉽습니다.

그 전에도 비슷한 지시가 있었습니다.
작업 중에 전체 테스트를 돌리지 말라는 것이었습니다.

전체 테스트는 10분 넘게 걸리고 작업 컴퓨터의 부하를 끌어올렸습니다.
시간은 쓰는데 화면이 맞는지는 여전히 모릅니다.

화면 작업의 증거는 초록불이 아니라 고객이 보게 될 화면 그 자체입니다.

바뀐 규칙은 작업 기록에 이렇게 남았습니다.

1단계는 기계 확인입니다.
바뀐 파일만 골라 문법과 타입이 맞는지, 앱이 빌드되는지만 봅니다. 몇 초면 끝납니다.

2단계는 설치입니다.
개발용 컴퓨터에 연결된 실제 폰에 방금 고친 앱을 올립니다. 화면 속 가상 기기는 쓰지 않고, 고객이 쓰는 것과 같은 종류의 폰을 씁니다.

3단계는 사람 순서대로 누르기입니다.
로그인하고, 목록을 열고, 항목 하나를 눌러 들어가는 식으로 고객이 실제로 지나가는 길을 따라갑니다. 화면마다 스크린샷을 남기고, 화면별로 되는지 안 되는지를 적어 보고합니다.

이번 사고였다면 2단계에서 바로 걸렸습니다.
목록 화면을 여는 순간 빈 화면이 보이기 때문입니다.

스크린샷이 붙은 보고는 대표가 직접 열어 볼 수 있는 증거입니다.

개발 코드를 읽을 필요는 없습니다.
보고서 한 장에서 세 칸만 확인하면 됩니다.

검사 칸.
「통과」가 기계 검사입니까, 실제 화면 확인입니까. 둘 중 무엇인지 보고서에 적혀 있어야 합니다.

증거 칸.
화면이 바뀐 작업이라면 실제 기기 스크린샷이 붙어 있습니까. 화면 이름별로 되는지 안 되는지 적혀 있습니까.

기대값 칸.
테스트가 확인하는 주소나 문구, 숫자를 누가 무엇을 보고 정했습니까. 코드를 쓴 쪽이 자기 결과를 그대로 정답으로 옮겨 적었다면 그 테스트는 아무것도 증명하지 않습니다.

AI 가 만든 결과물도 같은 원리로 봅니다.
상담에서도 늘 마지막 확인은 사람 몫으로 남겨 두시라고 안내드립니다.

「무엇이 통과했나」보다 「무엇을 증명한 검사인가」를 먼저 묻습니다.

정리

경고 신호

• 화면 작업 완료 보고에 「테스트 통과」만 있고 화면 캡처가 없다

• 테스트의 기대값을 코드를 쓴 쪽이 자기 결과에서 그대로 옮겨 적었다

• 작업할 때마다 전체 테스트를 돌리느라 10분씩 기다린다

• 운영 화면이 이상하다는 걸 고객 문의로 처음 안다

좋은 신호

• 보고서에 기계 검사와 실제 화면 확인이 따로 적혀 있다

• 화면별 스크린샷과 되는지 안 되는지가 한 줄씩 붙어 있다

• 기능 로직은 테스트로, 화면은 실제 기기로 검수한다는 규칙이 있다

• 테스트 기대값의 출처(기획서·서버 문서)를 말할 수 있다

개발 보고를 받기 전 확인할 다섯 가지

1. 이번 작업이 화면 작업입니까, 기능 로직 작업입니까?
   화면이 바뀌었다면 실제 기기 확인이 완료 조건입니다.

2. 「통과」가 어떤 검사의 통과입니까?
   기계 검사인지 실제 화면 확인인지 보고서에 구분돼 있어야 합니다.

3. 실제 폰에서 찍은 화면별 스크린샷이 있습니까?
   고객이 지나가는 순서대로 화면마다 한 장씩입니다.

4. 테스트의 기대값은 누가 무엇을 보고 정했습니까?
   코드 결과를 그대로 옮겨 적은 기대값은 틀린 값도 정답으로 지킵니다.

5. 작업 중에 전체 테스트를 돌리고 있지 않습니까?
   작업 중에는 바뀐 파일만 확인하고, 전체 검증은 합치기 직전에 한 번 합니다.

함께 읽기

• 늘 빨간불인 검사는 검사가 아닙니다: https://agenticworkflows.club/blog/always-failing-check-is-no-check

자주 묻는 질문

Q. 테스트가 전부 통과했는데 왜 화면이 안 나올 수 있습니까?

테스트는 미리 적어 둔 기대값과 결과가 같은지만 확인합니다. 기대값 자체가 틀렸다면 틀린 코드도 통과합니다. 실제 사례에서는 서버 주소 앞부분이 두 번 붙은 틀린 주소를 테스트가 정답으로 고정하고 있어서, 운영 화면의 프로젝트 목록이 비어 있는 동안에도 테스트는 전부 통과했습니다.

Q. 화면 작업은 어떻게 검수합니까?

세 단계입니다. 바뀐 파일만 골라 컴파일과 타입 오류가 없는지 기계로 확인하고, 연결된 실제 폰에 설치한 뒤, 고객이 쓰는 순서대로 눌러 보며 화면별 스크린샷과 결과를 남깁니다.

Q. 그러면 테스트는 쓰지 않아도 됩니까?

아닙니다. 계산·조건 분기·데이터 처리 같은 기능 로직은 테스트가 사람보다 정확합니다. 작업 종류마다 무엇을 증명할 검사인지를 고르자는 뜻이고, 화면 작업의 완료 증거는 실제 기기 화면으로 삼습니다.

Q. 개발사나 AI 가 「테스트 통과」라고 보고하면 무엇을 물어야 합니까?

세 가지를 묻습니다. 그 통과가 기계 검사인지 실제 화면 확인인지, 화면이 바뀐 작업이라면 실제 기기 스크린샷이 붙어 있는지, 테스트의 기대값인 주소·문구·숫자를 누가 무엇을 보고 정했는지입니다.

Q. 작업 중에 전체 테스트를 돌리면 안 됩니까?

작업 중에는 바뀐 파일과 관련 테스트만 확인하는 편이 낫습니다. 저희 환경에서 전체 테스트는 10분 넘게 걸리고 작업 컴퓨터 부하를 올렸습니다. 전체 검증은 합치기 직전이나 필요할 때 한 번 합니다.