로그를 앞뒤만 보고 넘어갔더니 열여덟 편이 설명 없이 나갔습니다.
글 열여덟 편을 한 번에 처리하는 작업이 있었습니다. 각 글에 검색 설명을 넣고 저장하는 일이었습니다. 작업은 끝났고 에러도 없었습니다. 며칠 뒤 확인해 보니 열여덟 편 모두 설명이 비어 있었습니다. 원인은 설정 화면의 토글 하나가 꺼져 있어 입력란 자체가 저장되지 않는 상태였다는 것인데, 문제는 그것을 그 자리에서 알 수 있었다는 점입니다. 스크립트는 각 글마다 반영된 개수를 찍고 있었고 그 값이 계속 0이었습니다. 다만 로그가 길어서 앞부분과 마지막 줄만 보고 넘어갔고, 0이 찍힌 줄은 가운데에 있었습니다. 로그를 읽는 방식 하나 때문에 열여덟 편이 그대로 나갔습니다.
실패는 마지막 줄에 있지 않았다
긴 출력을 볼 때 습관적으로 하는 일이 있습니다. 앞의 몇 줄과 마지막 몇 줄만 봅니다. 시작이 정상이고 끝이 정상이면 가운데도 정상이라고 생각합니다.
그런데 여러 건을 반복 처리하는 작업에서는 실패가 가운데에 고르게 퍼집니다. 한 건당 몇 줄씩 찍히면 열여덟 건은 금세 수백 줄이 됩니다.
마지막 줄은 대개 종료 문구입니다. 프로그램이 스스로 실패로 끝내지 않는 한 마지막 줄은 언제나 정상으로 보입니다.
이번 경우에도 마지막 줄에는 문제가 없었습니다. 0이라는 숫자는 중간에 열여덟 번 찍혔습니다.
| 보는 위치 | 알 수 있는 것 |
|---|---|
| 앞 몇 줄 | 시작이 됐는지 |
| 마지막 줄 | 프로그램이 스스로 멈추지 않았는지 |
| 가운데 전부 | 각 건이 실제로 처리됐는지 |
0이라는 숫자가 실패였다
스크립트는 글 하나를 저장할 때마다 반영된 항목 수를 찍었습니다. 정상이면 1이고, 안 됐으면 0입니다.
이 값은 명백한 실패 신호였는데도 실패로 취급되지 않았습니다. 숫자를 찍기만 했지 그 숫자로 프로그램을 멈추지 않았기 때문입니다.
그래서 두 가지를 같이 고쳤습니다. 반영 수가 0인 건이 하나라도 있으면 그 자리에서 멈추고, 끝에 성공한 수와 전체 수를 함께 찍습니다.
숫자를 찍는 것과 숫자로 판정하는 것은 다릅니다. 찍기만 하면 사람이 읽어야 하고, 사람은 긴 로그를 끝까지 읽지 않습니다.
덧붙여, 실패 신호를 어떤 값으로 볼지도 미리 정해 둬야 합니다. 이번에는 0이 실패였지만 어떤 작업은 0이 정상입니다. 그 기준을 코드 옆에 한 줄로 적어 두면 다음에 로그를 볼 때 헤매지 않습니다.
바이트로 자르면 글자가 깨진다
로그가 너무 길어서 보기 좋게 자르려는 시도도 문제를 만듭니다. 글자 수가 아니라 바이트 수로 자르는 도구를 쓰면 한글이 중간에서 잘립니다.
한글은 한 글자가 여러 바이트로 저장됩니다. 정해진 바이트에서 끊으면 마지막 글자가 반쪽만 남아 깨진 문자로 바뀝니다.
이렇게 깨진 로그는 나중에 검색해도 걸리지 않습니다. 실패 문구가 로그 안에 있는데도 찾지 못하는 상황이 생깁니다.
그래서 로그를 자를 때는 원문을 그대로 저장해 두고, 화면에 보여 줄 때만 줄 단위로 줄입니다. 저장본을 자르지 않습니다.
요약은 읽는 쪽이 아니라 찍는 쪽이 만든다
긴 로그를 사람이 요약하려니 놓쳤습니다. 그러면 요약을 프로그램이 만들게 하면 됩니다.
작업이 끝날 때 한 줄짜리 정리를 마지막에 다시 찍습니다. 성공 수, 실패 수, 실패한 항목의 이름입니다.
이렇게 하면 마지막 줄만 봐도 되는 상태가 실제로 만들어집니다. 앞뒤만 보는 습관을 고치는 것보다, 앞뒤만 봐도 되게 만드는 편이 빠릅니다.
다만 이 요약을 만들려면 각 건의 성공 여부를 프로그램이 판단할 수 있어야 합니다. 그 판단 기준을 정하는 것이 사실 본체입니다.
| 고치기 전 | 고친 뒤 |
|---|---|
| 건마다 숫자만 찍음 | 숫자가 실패값이면 즉시 중단 |
| 마지막 줄은 종료 문구 | 마지막 줄에 성공 수와 실패 항목 |
| 로그를 바이트로 잘라 저장 | 원문 저장, 화면에서만 줄 단위로 축약 |
설정 화면이 원인일 때가 있다
이번 실패의 뿌리는 코드가 아니라 서비스 설정이었습니다. 검색 설명을 쓰는 기능 자체가 꺼져 있었고, 꺼진 상태에서는 입력란에 값을 넣어도 저장되지 않았습니다.
화면에는 입력란이 보였습니다. 그래서 값을 넣는 동작은 정상적으로 수행됐고, 오류도 나지 않았습니다.
그 뒤로는 값이 저장되지 않을 때 코드부터 보지 않습니다. 그 기능을 켜고 끄는 설정이 있는지 먼저 찾아봅니다.
반대 경우도 있습니다. 화면에 값이 안 보인다고 데이터가 없는 것은 아닙니다. 서식이 그리지 않는 것일 수 있으므로 관리 화면에서 확인합니다.
설정 때문에 저장이 막히는 경우는 오류가 나지 않는 것이 특징입니다. 화면은 입력을 받아 주고 저장 버튼도 눌립니다. 그래서 저장한 값을 곧바로 다시 읽어 확인하는 절차가 없으면 알아챌 방법이 없습니다.
로그를 읽는 순서를 바꿨다
지금은 순서를 이렇게 정해 두고 있습니다.
먼저 마지막의 요약 줄을 봅니다. 성공 수와 전체 수가 같은지 확인합니다. 다르면 실패한 항목 이름을 봅니다.
요약 줄이 없으면 그 작업은 아직 확인된 것이 아니라고 봅니다. 로그를 스크롤하며 훑는 것으로 대신하지 않습니다.
그리고 원문 로그는 파일로 남깁니다. 화면 스크롤은 사라지지만 파일은 나중에 검색할 수 있습니다.
- 요약 줄부터 본다
- 요약 줄이 없으면 확인되지 않은 작업으로 둔다
- 원문 로그는 자르지 않고 파일로 남긴다
자주 묻는 질문
Q. 로그를 전부 읽어야 하나요?
A. 전부 읽는 대신 프로그램이 마지막에 요약을 찍게 했습니다. 성공 수, 실패 수, 실패한 항목 이름입니다. 요약이 없으면 그 작업은 확인되지 않은 것으로 둡니다.
Q. 실패값을 찍는데도 왜 못 봤나요?
A. 숫자를 찍기만 하고 그 숫자로 프로그램을 멈추지 않았기 때문입니다. 긴 로그의 가운데에 있었고 마지막 줄은 정상 종료 문구였습니다.
Q. 로그를 짧게 자르면 안 되나요?
A. 글자 수가 아니라 바이트 수로 자르면 한글이 중간에서 깨집니다. 깨진 로그는 나중에 검색해도 걸리지 않습니다. 원문은 그대로 두고 화면에서만 줄 단위로 줄입니다.
확인 자료
- 본 블로그 운영 중 2026-09-09에 직접 겪은 사례 기록
- AI 개발루틴 현장 부록 v1.3 — 2026-09-05~06 운영에서 나온 실패 19건 분류 (2026-09-06 정리)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.