실패 19건 중 에러가 난 것은 3건이었습니다. 나머지 16건은 정상 종료 코드로 끝났습니다.
이틀치 작업을 되짚으며 실패한 것만 모아 봤더니 19건이었습니다. 그중 도구가 에러 메시지를 보여 준 것은 3건뿐이었고, 16건은 종료 코드 0으로 끝났습니다. 화면에는 아무 문제가 없었고 로그도 평범했습니다. 그래서 실패를 알아챈 시점은 대부분 한참 뒤, 결과물을 다시 열어 봤을 때였습니다. 19건을 다시 읽어 보니 원인이 제각각인 것 같아도 세 갈래로 묶였습니다. 결과가 비어 있는데 성공으로 읽은 것, 지금 상태를 확인하지 않고 다음 동작으로 넘어간 것, 확인하는 코드 자체가 틀린 것입니다. 유형이 나뉘자 잡는 방법도 달라졌습니다. 첫째 유형은 개수를 세면 잡히고, 둘째 유형은 동작 전후의 상태를 읽으면 잡히고, 셋째 유형은 값을 넣을 때 쓴 방법으로 다시 읽으면 잡힙니다.
에러가 없다는 말은 성공했다는 말이 아니다
작업이 끝나면 보통 두 가지를 봅니다. 에러 메시지가 떴는지, 그리고 프로그램이 몇 번으로 끝났는지입니다. 둘 다 이상이 없으면 다음으로 넘어갑니다.
그런데 이번에 모은 19건은 대부분 그 두 가지를 통과한 실패였습니다. 종료 코드는 0이고 화면에는 붉은 글씨가 없었습니다.
이런 실패는 발견이 늦습니다. 실패한 자리에서는 아무 신호가 없고, 며칠 뒤 결과물을 열어 봤을 때 비로소 드러납니다. 그사이에 같은 방식으로 만든 것이 더 쌓입니다.
그래서 완료를 판정하는 기준을 에러 유무에서 다른 것으로 옮겨야 했습니다. 무엇을 만들려고 했고 실제로 몇 개가 만들어졌는지를 비교하는 쪽입니다.
| 확인 방식 | 이번 19건에서의 결과 |
|---|---|
| 에러 메시지가 떴는가 | 3건만 떴습니다 |
| 종료 코드가 0인가 | 16건이 0으로 끝났습니다 |
| 기대 개수와 실제 개수가 같은가 | 여기서 대부분 걸립니다 |
유형 1. 조용한 실패 11건
가장 많았던 유형입니다. 도구는 정상적으로 끝났고 출력도 그럴듯한데, 실제로 만들어진 것이 없거나 모자란 경우입니다.
전형적인 모양은 이렇습니다. 여러 건을 한 번에 처리하는 스크립트가 실패한 건수를 세기만 하고 마지막에 그냥 0으로 끝납니다. 실패를 세었으면 그 숫자로 멈춰야 하는데, 세어 놓고 아무 데도 쓰지 않은 것입니다.
다른 모양은 결과를 걸러 보는 경우입니다. 출력에서 특정 문구만 뽑아 보려고 필터를 걸었는데 아무것도 안 나옵니다. 이때 나온 빈 화면은 문제가 없다는 뜻이 아니라 모르겠다는 뜻입니다. 필터가 틀렸을 수도 있기 때문입니다.
그래서 두 가지를 규칙으로 정했습니다. 여러 건을 처리하면 끝에 실제 성공 수와 목표 수를 함께 찍고, 모자라면 실패로 끝냅니다. 필터를 걸기 전에 원문 한 건을 눈으로 먼저 확인합니다.
유형 2. 상태 가정 오류 4건
화면이 지금 어떤 상태인지 확인하지 않고 다음 동작을 한 경우입니다. 눌렀다고 생각한 버튼이 아직 나타나지 않았거나, 이미 다른 화면으로 넘어가 있었습니다.
특히 문제가 됐던 것은 시간이 걸리는 동작입니다. 어떤 서비스는 버튼을 누르면 1~2분짜리 검사를 돌립니다. 그 사이에 화면을 옮기면 검사가 취소됩니다. 클릭은 분명히 했지만 요청은 접수되지 않은 상태로 남습니다.
고친 방법은 단순합니다. 누른 다음에 완료를 알리는 문구를 실제로 본 뒤에만 다음으로 넘어갑니다. 그 문구가 무엇인지는 첫 한 건에서 누르기 전과 후의 화면 글자를 비교해 미리 찾아 둡니다.
진행 표시가 있는 화면은 두 단계로 봅니다. 표시가 나타나는 것을 먼저 확인하고, 그다음에 사라지기를 기다립니다. 사라진 것만 보면 아직 시작하지 않은 상태와 다 끝난 상태를 구분할 수 없습니다.
유형 3. 검증 도구 자체의 결함 4건
가장 억울한 유형입니다. 작업은 제대로 됐는데 확인하는 코드가 틀려서 실패로 보였습니다. 반대로 실제 문제를 놓친 경우도 있었습니다.
원인은 대개 같았습니다. 값을 넣을 때 쓴 경로와 확인할 때 쓴 경로가 달랐습니다. 다른 방법으로 읽으면 없는 문제를 만들어 내거나, 있는 문제를 통과시킵니다.
그래서 확인은 설정할 때와 같은 방법으로 합니다. 같은 위치, 같은 경로로 다시 읽습니다.
덧붙여, 겉으로 보이는 화면에 값이 없다고 해서 값이 없는 것은 아닙니다. 표시 설정이나 서식 때문에 그리지 않는 경우가 있으므로 관리 화면에서 한 번 더 봐야 합니다.
| 유형 | 건수 | 잡는 방법 |
|---|---|---|
| 조용한 실패 | 11 | 개수를 센다, 원문을 덤프한다 |
| 상태 가정 오류 | 4 | 동작 전 상태를 읽고 동작 후 변화를 읽는다 |
| 검증 도구의 결함 | 4 | 값을 넣을 때 쓴 방법으로 확인한다 |
세 유형을 가르는 질문
새로 실패를 만나면 세 가지를 순서대로 물어봅니다. 답이 막히는 자리가 유형입니다.
몇 개를 만들려고 했고 몇 개가 만들어졌는지 말할 수 있습니까. 말할 수 없으면 첫째 유형입니다.
동작하기 직전 화면이 어떤 상태였는지 말할 수 있습니까. 말할 수 없으면 둘째 유형입니다.
확인에 쓴 방법이 설정에 쓴 방법과 같습니까. 다르면 셋째 유형입니다.
- 숫자를 못 대면 개수 문제입니다
- 직전 화면을 못 대면 상태 문제입니다
- 읽는 방법이 다르면 검증 문제입니다
완료 보고에 세 줄을 더했다
분류를 마친 뒤 작업 보고 형식에 세 줄을 고정으로 넣었습니다.
첫째, 개수 검증입니다. 기대한 수와 실제 수를 함께 적습니다. 둘째, 완료 문구 확인입니다. 실제로 화면에서 본 문구를 그대로 옮겨 적습니다. 셋째, 미확인 항목입니다. 필터가 비어 있었거나 결과가 불확실했던 것을 남깁니다.
세 줄을 적으려면 세 가지를 실제로 확인해야 합니다. 그래서 보고 형식을 바꾼 것이 곧 확인 절차를 바꾼 것이 됐습니다.
완료라는 말은 이제 에러가 없었다는 뜻이 아니라, 이 세 줄을 채울 수 있다는 뜻으로 씁니다.
자주 묻는 질문
Q. 종료 코드만 보면 안 되나요?
A. 종료 코드 0은 프로그램이 스스로 문제를 신고하지 않았다는 뜻입니다. 만들려던 것이 실제로 만들어졌는지는 별개입니다. 이번 19건 중 16건이 0으로 끝났습니다.
Q. 개수를 세는 게 그렇게 효과가 있나요?
A. 가장 많았던 조용한 실패 11건이 개수 비교 한 줄로 걸립니다. 여러 건을 처리하는 작업은 끝에 성공 수와 목표 수를 함께 찍고, 모자라면 실패로 끝내도록 했습니다.
Q. 필터 결과가 비어 있으면 어떻게 하나요?
A. 성공으로 읽지 않고 모름으로 둡니다. 필터가 맞는지 원문 한 건으로 먼저 확인한 뒤, 그래도 불확실하면 출력 전체를 그대로 저장해 눈으로 봅니다.
확인 자료
- AI 개발루틴 현장 부록 v1.3 — 2026-09-05~06 운영에서 나온 실패 19건 분류 (2026-09-06 정리)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.