문서가 안 열린다고 없다고 쓰면 안 됩니다 — 최근 네 번 다 제 잘못이었습니다

확인의 기술 · 실패 사례 다섯

"안 열린다"는
"없다"가 아닙니다.

최근 다섯 번 중 네 번은 원인이 제 쪽이었습니다. 도메인이 옮겨갔거나, 이름을 잘못 알았거나, 안 열어본 페이지에 있었습니다.

AI 서비스를 확인하다 보면 문서가 안 열리는 일이 자주 생깁니다. 이때 "아, 서비스가 없어졌구나" 하고 넘어가기 쉬운데, 최근에 저는 그걸 네 번 연속으로 틀렸습니다. 다행히 "없다"고 안 쓴 덕에 네 번 다 정정만으로 끝났습니다. 그 사례들을 그대로 공개합니다.

📌 30초 요약

• 401이 두 번 — 하나는 모델 이름을 잘못 안 것, 하나는 도메인 이전이었습니다.
• 403이 한 번 — 주소가 옮겨간 것이었습니다. 리다이렉트를 따라가니 열렸습니다.
• "문서에 없음"이 한 번 — 네 번째 페이지에 있었습니다. 세 곳만 보고 판단했었죠.
• 다섯 번째는 세 경로를 다 시도해도 못 찾았습니다. 그건 그대로 "못 찾았다"로 남겼습니다.
• ⚠️ 핵심은 "없다"로 쓰면 되돌리기 어렵고 "못 찾았다"로 쓰면 정정으로 끝난다는 것입니다.

① 네 번의 오판을 표로

무엇을 확인하다	막힌 방식	진짜 원인
오픈 모델의 라이선스 파일	401	모델 이름을 정확히 몰랐음
무료 플랜의 월 한도 숫자	문서에 없음	네 번째 페이지에 있었음
무료 API의 종료 여부	401	도메인이 통째로 이전
한 회사의 API 가격표	403	주소 이전(301)
크레딧 한 개의 정의	404 · 무응답	세 경로 실패 → 그대로 보류

2026년 8월 중순, 닷새 사이에 겪은 다섯 건 · 마지막 줄만 아직 미해결입니다

응답 코드가 원인을 안 알려줍니다. 401이 두 번 나왔는데 원인이 서로 달랐고, 403도 차단이 아니라 이사였습니다. 코드를 원인으로 번역하면 거기서부터 틀립니다.

② 사례 넷 — 무엇을 놓쳤나

A. 이름을 정확히 몰랐던 경우

오픈 모델 라이선스를 비교하면서 한 저장소를 열려다 401을 받았습니다. 표에 "확인 못 함"으로 적었는데, 알고 보니 제가 저장소 주소를 어림짐작으로 만들었던 것이었습니다. 검색으로 정확한 이름을 확인하고 다시 여니 열렸습니다. → 주소를 추측으로 조립했으면 그것부터 의심하세요.

B. 세 곳만 보고 판단한 경우

한 달 전 글을 다시 점검하면서 무료 플랜의 월 한도 숫자를 찾다가 문서 세 곳에서 못 찾았습니다. "없어진 것 같다"고 적었는데 네 번째 페이지에 그대로 있었습니다. → 같은 사이트 안에서도 그 정보가 사는 페이지가 따로 있습니다. 요금 얘기는 요금 문서에, 플랜 얘기는 플랜 문서에요.

C·D. 도메인이 옮겨간 경우 — 두 번

무료 API가 아직 있는지 두 번 확인했는데 두 번 다 401이라 판정을 미뤘습니다. 세 번째에 문서 주소가 다른 도메인으로 옮겨간 것을 봤습니다. 새 주소는 그냥 열렸습니다.

며칠 뒤 다른 회사 가격표를 비교할 때도 403을 받고 "접근 차단"이라 적었는데, 역시 301 이전이었습니다. 따라가니 열렸고, 그 글의 비교표에 한 회사를 추가할 수 있었습니다. → 같은 실수를 나흘 만에 반복했습니다.

🔍 네 번의 공통점

전부 서버가 아니라 제가 문제였습니다. 그런데 화면에 뜨는 건 서버가 보낸 숫자라서, 자연스럽게 "저쪽 문제"로 읽게 됩니다.

특히 403은 "금지"라는 뜻이라 더 그럽습니다. 실제로는 옛 주소가 새 주소로 넘기는 과정에서 나온 응답이었는데, 단어만 보면 "막혔다"로 읽히거든요. 응답 코드는 증상이지 진단이 아닙니다.

③ 그래서 만든 순서 세 가지

✅ "없다"고 쓰기 전에

1. 리다이렉트를 따라갔나. 301·302가 오면 그건 안내입니다. 브라우저는 자동으로 따라가지만, 도구로 열면 거기서 멈추는 경우가 있습니다.
2. 주소를 추측으로 만들었나. 이름·버전·계정명을 짐작해 조립했다면 검색으로 실제 주소를 먼저 확인하세요.
3. 같은 사이트의 다른 페이지를 봤나. 한 사이트 안에서도 정보마다 사는 곳이 다릅니다. 문서 색인이 있으면 그것부터 훑으세요.

셋 다 해봤는데도 안 나오면? 그때는 "없다"가 아니라 "세 경로에서 못 찾았다"고 적습니다. 실제로 무료 한도의 단위를 비교하던 글에서 한 항목이 그렇게 남아 있습니다 — 크레딧 한 개가 무엇인지를 세 경로로 찾다 실패했고, 그대로 "못 찾았다"로 적어뒀습니다.

✅ 이게 왜 중요하냐면

"서비스가 종료됐습니다"라고 쓰면 되돌리기 어렵습니다. 읽은 사람은 그걸 믿고 다른 걸 찾아 떠나고, 나중에 제가 고쳐도 이미 퍼진 문장은 안 돌아옵니다. 반면 "제가 못 찾았습니다"라고 쓰면 나중에 찾았을 때 박스 하나 붙이면 끝입니다. 네 번 다 그렇게 끝났습니다. 표현 하나가 되돌릴 수 있는 실수와 없는 실수를 가릅니다.

④ AI에게 확인시킬 때도 같습니다

요즘은 "이 서비스 아직 있어?"를 AI에게 물어보는 경우가 많습니다. 그런데 AI도 같은 방식으로 틀립니다 — 주소를 열었다가 실패하면 "없는 것 같다"고 요약해버리기 쉽습니다.

# 이렇게 물으면 "없다"는 답을 받기 쉽습니다
"○○ 무료 API 아직 있어?"

# 이렇게 물으면 근거가 같이 옵니다
"○○ 공식 문서에서 확인해줘.
 못 찾으면 어느 주소를 열었고 무슨 응답이 왔는지 알려줘.
 리다이렉트가 있으면 따라가 보고."

둘째 형태의 핵심은 "어느 주소를 열었는지 말해달라"입니다. 그러면 주소가 틀렸는지 내가 눈으로 확인할 수 있습니다. 제 네 번의 실수도 전부 이 한 가지를 확인했으면 그 자리에서 잡혔을 것들입니다.

자주 묻는 것

Q. 그럼 "없다"고는 영영 못 쓰나요?

쓸 수 있습니다. 근거가 다를 때요. 예를 들어 공식 문서에 "2026년 7월 30일부로 완전히 폐지되었습니다"라고 적혀 있으면 그건 "없다"고 써도 됩니다. 못 연 것과 열었더니 없다고 적혀 있는 것은 전혀 다른 근거입니다.

Q. 매번 세 단계를 다 하면 느리지 않나요?

느립니다. 대신 단정을 안 하면 세 단계를 건너뛰어도 됩니다. 급할 때는 "못 찾았다"로 적고 넘어갔다가 나중에 채우는 식으로 해왔습니다. 시간을 아끼는 대신 결론을 아끼는 것이죠.

Q. 다섯 번째는 결국 어떻게 됐나요?

아직 못 찾았습니다. 공식 페이지는 응답이 없고, 문서 경로는 404, 검색으로도 정의가 안 나옵니다. 로그인해서 계정 화면을 보는 경로가 남았는데 거기까지는 안 갔습니다. 그래서 해당 글에는 "못 찾았다"로 남아 있고, 찾으면 박스를 붙일 겁니다.

🔎 이후 확인 — 도구 안에서도 같은 일이 벌어집니다

이 글은 제가 문서를 못 찾은 이야기였는데, 그 뒤 도구 자체가 파일을 덜 찾는 조건이 공식 문서에 적혀 있는 걸 봤습니다. 윈도우에서 리눅스 환경을 얹어 쓰면 검색이 예상보다 적은 결과를 반환합니다.

→ 문제는 그 다음 문장입니다 — "이 경우 점검 명령은 검색을 정상으로 표시한다." 에러도 없고 진단도 통과하는데 결과만 빠집니다. AI가 "그런 코드 없다"고 답해도 그대로 믿으면 안 되는 이유가 하나 더 생긴 셈입니다 → 진단이 정상인데 결과가 빠지는 경우

✨ 정리하면

닷새 사이 다섯 번 막혔는데 네 번은 제 문제였습니다 — 도메인 이전 둘, 잘못된 주소 하나, 안 열어본 페이지 하나.

응답 코드는 증상이지 진단이 아닙니다. 401이 두 번 나왔는데 원인이 서로 달랐고, 403은 차단이 아니라 이사였습니다.

리다이렉트 · 정확한 주소 · 다른 페이지 셋을 확인하고, 그래도 없으면 "없다"가 아니라 "못 찾았다"로 적으세요. 표현 하나가 되돌릴 수 있는 실수와 없는 실수를 가릅니다.

🧭 AI 지출 전체 그림

이 글에 나온 확인들은 대부분 돈이 걸린 사실을 재는 과정에서 나왔습니다. 단계별 지도는 여기입니다 → AI에 쓰는 돈 총정리 — 숨은 비용 7가지

🔗 이 글에 나온 다섯 건

• 오픈 모델 라이선스 배지 옆 파일 — 401, 이름을 몰랐던 경우
• 한 달 뒤 다시 열어본 기록 — 네 번째 페이지에 있었던 숫자
• Kimi 무료 API 추적 — 401, 도메인 이전
• 단가가 같아도 청구는 다릅니다 — 403, 주소 이전
• 무료 한도를 한 표에 못 넣은 이유 — 아직 못 찾은 다섯 번째

---

확인 시점 — 2026년 8월 14일. ✅ 1차 자료 : 이 글의 다섯 사례는 전부 제가 2026년 8월 10~14일 사이에 직접 겪고 각 글에 기록해둔 것입니다. 각 사례의 상세 경위와 정정 내용은 위 링크의 해당 글 본문·박스·각주에 남아 있습니다. 확인하지 않은 것 : 응답 코드가 실제로 어떤 서버 설정에서 나왔는지(제 쪽에서는 코드와 리다이렉트 헤더만 볼 수 있습니다) · 각 서비스가 주소를 옮긴 시점과 사유 · 다섯 번째 항목의 미해결 원인. 범위 한정 : 표본 다섯 건이며 "이런 경우가 대부분이다" 같은 비율을 주장하지 않습니다. 본문의 확인 순서는 제가 쓰는 방법이지 표준 절차가 아닙니다. 제휴·협찬 없습니다.