값을 넣을 때 쓴 방법과 같은 방법으로 다시 읽어서 확인합니다.
AI에게 작업을 맡길 때 생기는 실패는 대부분 오류 메시지로 오지 않습니다. 도구는 정상으로 끝났다고 말하고 확인 단계까지 통과합니다. 그런데 나중에 보면 값이 들어가 있지 않거나, 반대로 멀쩡히 들어간 값을 없다고 판정한 경우가 나옵니다. 제가 쓰는 개발 운영 규칙의 현장 부록은 이 문제를 결과의 문제가 아니라 확인 방법의 문제로 봅니다. 부록에는 실패가 세 유형으로 나뉘어 있고, 그중 한 묶음이 확인하는 코드 자체가 틀린 경우입니다. 규칙 자체는 한 줄로 짧습니다. 값을 넣을 때 쓴 선택자와 경로와 방식을 그대로 써서 다시 읽으라는 것입니다. 다른 방법으로 읽으면 없는 문제를 만들어 내고, 있는 문제는 조용히 놓칩니다.
확인하는 방법이 왜 결과를 바꾸나
부록에는 실패가 세 유형으로 정리돼 있습니다. 종료 코드는 0인데 결과물이 없는 조용한 실패, 지금 화면이 어떤 상태인지 읽지 않고 다음 동작을 시킨 상태 가정 오류, 그리고 확인하는 코드의 조건이 틀린 검증 도구 자체의 결함입니다.
세 번째가 가장 다루기 까다롭습니다. 앞의 둘은 결과물을 열어 보면 드러나지만, 확인 코드가 틀린 경우에는 잘못된 판정이 그대로 기록으로 남기 때문입니다.
판정이 틀리면 그 뒤에 오는 일이 전부 어긋납니다. 없는 문제를 고치느라 멀쩡한 부분을 건드리고, 실제로 있는 문제는 통과 표시를 달고 다음 단계로 넘어갑니다.
- 값이 없다고 오판하면 — 멀쩡한 값을 다시 넣어 덮어쓴다
- 값이 있다고 오판하면 — 빠진 값을 모른 채 다음 단계로 간다
- 형식이 틀렸다고 오판하면 — 기준을 고쳐 실제 규격이 흔들린다
- 판정을 못 했는데 성공으로 적으면 — 나중에 전부 다시 봐야 한다
넣을 때와 같은 방법으로 읽는다는 게 무슨 뜻인가
값을 저장할 때는 어떤 경로나 화면 요소를 하나 고릅니다. 확인할 때 다른 경로나 다른 요소를 고르면, 두 방법이 같은 자리를 가리킨다는 보장이 사라집니다.
이름이 비슷하다는 이유로 짝을 지으면 특히 잘 어긋납니다. 목록에 보이는 값과 상세 화면에 저장되는 값이 다른 자리에 있는 경우가 흔합니다.
그래서 확인 단계에서는 새로 방법을 고르지 않습니다. 넣을 때 쓴 그 방법을 그대로 복사해 읽기만 바꿉니다.
| 값을 넣은 방법 | 확인할 때 쓸 방법 | 다른 방법으로 읽으면 |
|---|---|---|
| 특정 입력 칸을 지정해 입력 | 같은 입력 칸을 지정해 읽기 | 빈 칸으로 보여 없다고 판정 |
| 지정한 파일 경로에 저장 | 같은 경로를 그대로 열기 | 비슷한 이름의 옛 파일을 읽음 |
| 공식 인터페이스로 등록 | 같은 인터페이스로 조회 | 화면 표시 규칙에 가려짐 |
| 설정 화면에서 항목 저장 | 설정 화면을 다시 열어 확인 | 겉 화면에 안 나와 누락 오판 |
화면에 안 보이면 값이 없는 것인가
부록에는 공개된 화면에 없다는 것이 데이터가 없다는 뜻은 아니라고 적혀 있습니다. 화면을 그리는 규칙이 그 값을 표시하지 않도록 돼 있을 수 있기 때문입니다.
이 경우 값은 멀쩡히 저장돼 있는데도 확인 단계에서 실패로 기록됩니다. 그러면 같은 값을 다시 넣게 되고, 중복이나 덮어쓰기가 뒤따릅니다.
그래서 보이지 않는 값은 관리 화면에서 한 번 더 봅니다. 겉 화면은 표시 여부만 알려 주고, 저장 여부는 알려 주지 않습니다.
- 겉 화면에서 안 보임 — 표시되지 않았다는 사실만 확인된 상태
- 관리 화면에서도 없음 — 저장되지 않았다고 판정할 수 있는 상태
- 관리 화면에는 있음 — 저장은 됐고 표시 규칙 문제로 좁혀지는 상태
- 둘 다 확인 못 함 — 실패가 아니라 미확인으로 적어야 하는 상태
확인 코드가 틀렸는지 어떻게 알 수 있나
확인 코드도 코드입니다. 그런데 확인 코드는 시험을 거치지 않은 채 판정 권한만 갖는 경우가 많습니다.
부록은 걸러 낸 결과가 비어 있으면 그것을 성공이 아니라 모름으로 적으라고 합니다. 조건이 맞는지 먼저 원문 한 건을 눈으로 보고 나서 조건을 적용하라는 순서도 함께 적혀 있습니다.
확인 코드를 시험하는 방법은 단순합니다. 값이 확실히 있는 것 하나와 확실히 없는 것 하나를 넣어 봅니다. 두 경우가 서로 다르게 나오지 않으면 그 확인 코드는 아무것도 판정하지 못하고 있는 것입니다.
이 시험을 한 번 해 두면 뒤의 판정을 믿을 수 있게 됩니다. 반대로 이 시험 없이 쌓인 통과 기록은 나중에 전부 다시 봐야 합니다.
- 먼저 볼 것 — 걸러 내기 전의 원문 한 건
- 그다음 볼 것 — 같은 조건에서 있는 건과 없는 건의 차이
- 적어 둘 것 — 이 조건이 무엇을 골라내려는 것인지 한 줄
- 다시 볼 때 — 화면 구조나 저장 위치가 바뀐 뒤
결과가 비었을 때 무엇이라고 적나
판정 문구를 뭉뚱그리면 나중에 읽는 사람이 무엇을 다시 봐야 하는지 알 수 없습니다. 그래서 확인 결과는 세 갈래로 갈라 적습니다.
| 확인 결과 | 적을 말 | 다음 행동 |
|---|---|---|
| 같은 방법으로 읽어 값이 나옴 | 확인함 | 다음 단계로 진행 |
| 같은 방법으로 읽었는데 비어 있음 | 실패 | 원인을 찾고 다시 넣기 |
| 다른 방법으로 읽어 비어 있음 | 미확인 | 같은 방법으로 다시 확인 |
| 조건에 걸러진 결과가 비어 있음 | 미확인 | 원문을 통째로 열어 보기 |
확인 방법을 맞추고 달라진 것
| 맞추기 전 | 맞춘 뒤 |
|---|---|
| 확인 방법을 그때그때 새로 고름 | 넣을 때 쓴 방법을 그대로 복사 |
| 빈 결과를 전부 실패로 적음 | 실패와 미확인을 나눠 적음 |
| 겉 화면만 보고 없다고 판정 | 관리 화면까지 보고 판정 |
| 확인 코드는 시험하지 않음 | 있는 것과 없는 것으로 시험 |
자주 묻는 질문
Q. 확인은 다른 방법으로 하는 편이 더 객관적이지 않나요?
A. 사람이 눈으로 볼 때는 그렇습니다. 그러나 자동으로 판정할 때는 두 방법이 같은 자리를 가리킨다는 보장이 없어서, 다름이 곧 오판이 됩니다. 방법을 맞춘 뒤에 눈으로 한 번 더 보는 순서가 안전합니다.
Q. 걸러 낸 결과가 비면 왜 성공이 아닌가요?
A. 조건이 맞아서 비었는지, 조건이 틀려서 비었는지 구분되지 않기 때문입니다. 구분되지 않는 상태는 성공이 아니라 모름이고, 기록에도 미확인으로 남겨야 합니다.
Q. 화면에 값이 안 보이면 무엇부터 보나요?
A. 관리 화면을 먼저 봅니다. 거기에 값이 있으면 저장은 된 것이고 표시 규칙 문제로 좁혀집니다. 거기에도 없을 때만 저장 실패로 판정합니다.
Q. 확인 코드는 어떻게 시험하나요?
A. 값이 확실히 있는 건과 확실히 없는 건을 하나씩 넣어 봅니다. 두 결과가 다르게 나와야 그 코드가 판정 기능을 갖고 있다고 볼 수 있습니다.
확인 자료
- AI 개발 운영 규칙 현장 부록 v1.3 — 1장 실패의 세 유형, 2.3 검증은 설정과 같은 방법으로, 2.8 공개된 화면과 데이터의 구분 (확인 2026-09-09)
- AI 개발 운영 규칙 문서 v1.3 — 13장 작업 종료 문장 중 확인한 결과와 확인하지 못한 결과의 구분 (확인 2026-09-09)
이 글은 직접 겪은 작업 기록을 정리한 것입니다. 확인하지 못한 항목은 본문에 쓰지 않았습니다. 대표 이미지는 이해를 돕기 위한 참고용 이미지입니다.