숲나들e 접속하면 https://www.foresttrip.go.kr/ 계속된 오류 계속 error.do로 튕기는 현상 완벽 해결기 (원인은 크롬 언어 설정?) - 클로드에게 해결 요청
웹 서핑을 하다 보면 온갖 기상천외한 오류를 마주하게 됩니다. 하지만 이번에 겪은 오류는 제 IT 문제 해결 역사상 가장 황당하고, 동시에 가장 허탈한 원인을 가진 사례였습니다.
다른 사람 PC에서는 잘만 들어가지고, 내 PC에서도 '게스트 모드'나 '시크릿 모드'에서는 정상적으로 접속되는데, 유독 내가 평소에 쓰는 메인 크롬 프로필에서만 특정 사이트(숲나들e 등 .go.kr 계열) 접속 시 무조건 error.do 페이지로 튕기는 현상이 발생했습니다. 캐시를 지워보고, 쿠키를 날려봐도 소용이 없었습니다. 귀신이 곡할 노릇이었죠.
오늘은 이 기괴한 현상의 정확한 원인을 추적해 나간 눈물겨운(?) 디버깅 과정과, 허탈할 정도로 간단했던 최종 해결 방법을 공유하고자 합니다. 바쁘신 분들을 위해 결론부터 말씀드리자면, 범인은 브라우저 캐시도, 악성코드도 아닌 바로 '크롬의 언어 설정'과 '서버의 어이없는 버그'의 환장할 콜라보레이션이었습니다.
💡 요약: 에러 해결 방법 (10초 컷)
만약 특정 웹사이트(특히 공공기관이나 예약 사이트) 접속 시 주소창이 .../com/error.do 로 강제 이동하며 오류 페이지가 뜬다면 아래 방법을 즉시 적용해 보세요.
- 크롬 브라우저 우측 상단 점 세 개(⋮) 클릭 → [설정] 이동
- 좌측 메뉴에서 [언어] 클릭
- '기본 언어' 목록을 확인합니다. 만약 '한국어'가 맨 위에 있다면 이것이 원인입니다.
- '한국어(대한민국)' 항목을 찾아 우측 점 세 개를 누르고 [맨 위로 이동]을 클릭합니다.
- 크롬을 종료하고 다시 접속해 봅니다. 정상적으로 열릴 것입니다.
단순히 '한국어'냐, '한국어(대한민국)'이냐의 차이가 사이트 접속 전체를 가로막고 있었다는 사실, 믿어지시나요? 지금부터 왜 이런 말도 안 되는 일이 벌어졌는지 그 심연을 파헤쳐 보겠습니다.
🕵️♂️ 1단계: 유력한 용의자들을 색출하다 (가설과 실패)
처음 문제가 발생했을 때 증상은 아주 명확했습니다. 홈페이지 메인 주소([https://www.foresttrip.go.kr/](https://www.foresttrip.go.kr/))를 치고 들어가면, 찰나의 순간에 서버가 접속을 거부하고 [https://www.foresttrip.go.kr/com/error.do](https://www.foresttrip.go.kr/com/error.do) 로 리다이렉트 시켜버렸습니다. 흥미로운 점은 깊은 주소(예: index.jsp)를 직접 치고 들어가면 멀쩡하게 작동한다는 것이었죠. 메인 페이지 진입 시점에만 무언가 강력한 문지기가 앞을 가로막고 있었습니다.
가설 1: 브라우저에 남은 낡은 세션(쿠키) 문제일 것이다? 가장 흔한 원인입니다. 게스트 모드나 시크릿 창에서는 쿠키가 없기 때문에 새 세션을 받아 정상 접속이 되는 반면, 기존 프로필은 몇 달 전 접속했던 낡은 세션 쿠키를 서버에 던졌고, 서버가 이를 '잘못된 접근'으로 판단해 에러 페이지로 보냈을 것이라 추측했습니다.
그래서 크롬 설정에 들어가 해당 사이트와 관련된 모든 데이터(쿠키, 로컬 스토리지, IndexedDB)를 정밀하게 삭제했습니다. 완벽하게 청소했다고 자부하며 다시 주소창에 메인 URL을 입력하고 엔터를 쳤습니다.
결과는? 여전히 error.do 였습니다. 무참한 실패였죠.
가설 2: 주소창 자동완성의 농간일 것이다? 쿠키 문제가 아니라면, 혹시 과거에 에러 페이지로 갔던 기록이 크롬 구글 계정에 동기화되어 있어서, 내가 메인 주소를 칠 때 크롬이 알아서 뒤에 /com/error.do를 붙여버리는 건 아닐까 의심했습니다.
이를 검증하기 위해 주소창 뒤에 자동완성이 개입할 수 없도록 임의의 파라미터(?a=1)를 붙여서 접속해 보았습니다. 하지만 여전히 자비 없이 에러 페이지로 튕겼습니다. 자동완성도 무죄였습니다.
🔬 2단계: 네트워크의 심연을 들여다보다 (헤드리스 크롬과 Net-log)
일반적인 얕은 수준의 조치로는 해결이 불가능하다는 것을 깨달았습니다. 이제 개발자 도구와 네트워크 로그(net-log)를 동원해 트래픽을 해부해야 할 시간이었습니다.
터미널을 열고 curl 명령어를 통해 서버에 직접 HTTP 요청을 보내보았습니다. 그런데 웬걸? curl로 접속하면 에러 없이 정상적으로 200 OK 응답이 떨어지는 것이 아닙니까?
이 말은 즉, 서버 자체가 죽은 것이 아니라, 내 크롬 브라우저가 접속할 때만 무언가 특별한 짓을 하고 있다는 뜻이었습니다. 결국 크롬을 '헤드리스(Headless, 화면 없이 백그라운드에서 실행하는 모드)'로 띄워 네트워크 패킷 전체를 덤프(dump) 떴습니다. 방대한 로그 파일을 한 줄 한 줄 분석한 끝에 결정적인 단서를 포착했습니다.
로그 안에는 이런 기록이 남아있었습니다.
Location: [https://www.foresttrip.go.kr/com/error.do](https://www.foresttrip.go.kr/com/error.do) (HTTP 302 리다이렉트)
메인 페이지를 호출하는 과정에서 거치는 /com/index.do 라는 요청을 서버가 받자마자, 서버 측에서 강제로 에러 페이지로 튕겨버린 것입니다. 그렇다면 도대체 내 크롬은 /com/index.do를 호출할 때 어떤 정보를 서버에 넘겼길래 서버가 기겁을 하고 에러를 뱉어낸 것일까요?
🧩 3단계: 쿠키의 환영에 속다
로그를 더 깊이 파고들자, 에러를 유발한 요청 헤더에서 의심스러운 쿠키 하나를 발견했습니다. 바로 WMONID=HongGilDong-123(임의의 마스킹 값) 이라는 쿠키였습니다. 이 쿠키만 덩그러니 전송되고, 정상적인 로그인을 유지하는 JSESSIONID 같은 세션 쿠키는 빠져 있었습니다.
"아하! 서버가 이 특정 WMONID 값을 악성 혹은 만료된 상태로 차단(Flag)해 두었고, 내 브라우저는 좀비처럼 계속 이 쿠키를 뱉어내고 있어서 차단당하는구나!"
완벽한 논리였습니다. 파이썬(Python)의 sqlite3 라이브러리를 사용해 크롬의 내부 쿠키 데이터베이스(DB) 파일에 직접 접근했습니다. 그리고 다른 사이트의 로그인 정보는 건드리지 않은 채, 오직 해당 사이트의 WMONID 쿠키만 외과 수술처럼 정밀하게 도려냈습니다.
이제 모든 문제가 끝났을 거라 확신하며 콧노래를 부르고 브라우저를 다시 열었습니다. 그리고 접속 화면을 본 순간, 저는 제 눈을 의심했습니다.
또 다시 error.do가 떠 있었습니다.
쿠키를 완전히 비운 백지상태에서 접속했는데도 서버는 보란 듯이 에러를 뱉어내고, 심지어 응답 헤더에 새로운 WMONID를 발급해서 제 브라우저에 심어주고 있었습니다. 쿠키는 범인이 아니었습니다. 그저 억울하게 용의 선상에 오른 목격자일 뿐이었죠. 정말 미칠 노릇이었습니다.
🎯 4단계: 진범은 상상도 못한 곳에 있었다 (유레카!)
쿠키가 없다면, 브라우저가 서버에 보내는 정보는 오직 'HTTP 요청 헤더(Request Header)' 뿐입니다. 다시 처음으로 돌아가, 정상 접속이 되는 curl 요청과 에러가 나는 크롬 브라우저의 요청 헤더를 나란히 두고 하나씩 비교하기 시작했습니다.
헤더를 하나씩 넣고 빼며 서버의 반응을 살피는 지루한 테스트가 이어졌습니다. 그러다 특정 헤더를 조작하는 순간, 에러가 마법처럼 사라지고 정상 페이지가 로드되는 것을 발견했습니다.
그 범인은 바로... Accept-Language 헤더였습니다.
브라우저는 서버에 접속할 때 "나는 이런 언어를 쓰는 사용자니까, 웬만하면 이 언어로 된 페이지를 보여줘"라고 자신의 언어 설정 값을 보냅니다. 당시 제 크롬 프로필이 서버에 보낸 값은 다음과 같았습니다.
Accept-Language: ko
이게 전부였습니다. 한국어를 의미하는 ko. 너무나 평범하고 당연한 값입니다. 그런데 서버에 다양한 형태로 테스트를 해본 결과, 믿을 수 없는 규칙이 발견되었습니다.
- Accept-Language: ko → 에러 발생 (error.do 리다이렉트 ❌)
- Accept-Language: ko-KR → 정상 접속 ✅
- Accept-Language: ko-KR,ko;q=0.9 → 정상 접속 ✅
- Accept-Language: en-US → 정상 접속 ✅
그렇습니다. 원인은 서버의 황당한 버그였습니다. 해당 사이트의 서버 로직 어딘가에 언어 코드를 파싱(Parsing)하거나 검증하는 과정에서, 오직 지역 코드가 빠진 단독 ko 값만 들어왔을 때 처리를 제대로 하지 못하고 예외(Exception)를 냅다 던져버리도록 코딩이 되어 있었던 것입니다. 그리고 그 예외 처리의 종착지가 바로 /com/error.do 였던 것이죠.
🤯 5단계: 왜 하필 내 크롬에서만 그랬을까? (사건의 재구성)
서버의 버그는 확인했습니다. 그런데 왜 유독 제 메인 프로필에서만 이 버그가 발동했을까요? 다른 사람들은 다 멀쩡하게 접속하고 있는데 말이죠.
여기에는 '사용자 설정'과 '최신 브라우저의 프라이버시 정책'이라는 두 가지 톱니바퀴가 치명적으로 맞물려 있었습니다.
첫째, 크롬 언어 우선순위 설정의 문제 제 크롬 브라우저 설정에 들어가 보니 언어 목록이 [한국어, 영어(미국)] 순으로 되어 있었습니다. 대부분의 사용자들은 윈도우 설치 기본값 등에 의해 [한국어(대한민국)] 즉, ko-KR이 최상단에 잡혀 있습니다. 하지만 저는 어떤 이유에서인지 지역 코드가 없는 범용 한국어(ko)를 대표 언어로 설정해 두고 있었던 것입니다.
게스트 모드로 열었을 때 정상 접속이 되었던 이유도 이 때문입니다. 게스트 모드는 아무 설정이 없는 깡통 상태이므로, 시스템의 기본값인 ko-KR을 뱉어냈고, 서버의 멍청한 검증 로직을 무사히 통과할 수 있었던 것입니다. 반면 제 프로필과 이를 그대로 복사해 쓰는 시크릿 모드는 ko를 뱉어내어 여지없이 차단당했습니다.
둘째, 최신 크롬의 'Accept-Language 축소(Reduction)' 기능 과거에는 브라우저가 접속할 때 Accept-Language: ko,en-US;q=0.9,en;q=0.8 처럼 자신이 아는 모든 언어와 선호도 비율을 구구절절 길게 서버에 보냈습니다. 하지만 최근 구글은 사용자를 추적하는 '브라우저 핑거프린팅(특정 정보를 조합해 개인을 식별하는 기술)'을 방지하기 위해 프라이버시 정책을 강화했습니다. 그 일환으로 첫 접속 시에는 사용자의 가장 대표 언어 단 하나만 깔끔하게 잘라서 보내도록 패치했습니다.
즉, 예전 같았으면 제 설정이 ko라도 뒤에 영어나 다른 코드가 붙어 나가서 서버의 ko 단독 검사 조건을 교묘하게 빗겨 나갔을 텐데, 브라우저가 업데이트되면서 오직 ko 딱 한 글자만 정직하게 서버에 제출하게 된 것입니다.
결국 ① 단독 ko를 받으면 뻗어버리는 낡은 서버의 버그와 ② 프라이버시를 위해 단독 ko만 보내게 된 최신 크롬의 정책, 그리고 ③ 우연히 대표 언어가 ko로 설정되어 있던 나의 환경이라는 세 가지 우주적 타이밍이 만나 발생한 환장의 콜라보레이션이었습니다.
🛠 결론: 개발자와 사용자 모두를 위한 교훈
원인을 알고 나니 고치는 것은 허탈할 정도로 쉬웠습니다. 글 서두에 남긴 요약처럼, 크롬 설정에 들어가 언어 목록 중 한국어(대한민국)을 찾아 순서를 맨 위로 올려준 것이 전부입니다. 이후 크롬이 Accept-Language: ko-KR을 전송하게 되면서 해당 사이트의 메인 페이지는 거짓말처럼 활짝 열렸습니다. 몇 시간에 걸친 네트워크 덤프 분석과 파이썬 쿠키 삭제 삽질이 무색해지는 순간이었죠.
이 황당한 사건은 웹 생태계에서 일어날 수 있는 아주 흥미로운 시사점을 던져줍니다.
개발자들을 위한 팁: 서버에서 클라이언트의 헤더 값을 파싱할 때는 항상 방어적으로 코딩해야 합니다. Accept-Language는 ko-KR 일 수도, ko 일 수도, 혹은 아예 없을 수도 있습니다. 예상치 못한 규격이 들어왔다고 해서 시스템 전체를 error.do로 던져버려서는 안 됩니다. 적절한 기본값(Default) 폴백(Fallback) 처리가 반드시 필요합니다.
일반 사용자를 위한 팁: 웹 서핑 중 유독 특정 관공서, 예약 사이트, 쇼핑몰 등에서만 알 수 없는 이유로 접속이 거부되거나 에러 페이지로 무한 루프를 도는 경험을 하신 적이 있나요? 캐시를 지우고 브라우저를 초기화하기 전에, 가장 먼저 브라우저의 언어 설정을 확인해 보시기 바랍니다. 당신의 브라우저가 서버에게 너무 '정직하고 짧은' 한국어(ko)를 외치고 있어서 문전박대를 당하고 있는 것일지도 모릅니다.
눈에 보이지 않는 ko와 ko-KR의 2바이트 차이가 예약과 같은 중요한 작업을 가로막을 수 있다는 사실, 부디 이 글이 저와 같은 황당한 오류로 모니터 앞에서 머리를 쥐어뜯고 계실 누군가에게 구원의 빛이 되기를 바랍니다.