문제를 대하는 태도 되돌아보기

---

목차

0. 서론

1. 문제의 발생

2. 해결 과정

3. 내 행동 되돌아보기

---

 

---

0. 서론

 

최근에 며칠간 끙끙대던 문제를 여러 도움을 통해 해결할 수 있었다. 해결하고 보니 정말 정말 간단한!!!! 문제였고 조금만 더 꼼꼼했다면, 조금만 더 다르게 생각했다면 충분히 나 혼자 해결할 수 있던 문제였다. 문제를 대하는 나의 부끄러웠던 행동을 정리하며 반성하고, 나중에 같은 실수를 하지 않겠다고 다짐하기 위해 포스팅을 남긴다.

 

---

1. 문제의 발생

 

요즘 나는 우리 서비스의 전체적인 흐름을 파악하고 싶어서 개발 어드민에서 이것저것을 눌러보고 있다. 이 화면에서는 어떤 API를 어떤 순서대로 호출할까, 등을 살펴보기 위해 크롬 개발자 도구를 켜놓고 있었다. 그런데 한 화면에서 이상한 현상을 발견했다.

 

정상적으로 API가 호출되었다면 이런 request를 보냈고 이런 response를 받아왔다~ 라고 개발자 도구에서 다 조회할 수 있다.

github에서 아무 페이지나 들어가 request/response 값을 보았다.

 

그런데 이상한 것이 뜬다. preview, response 같은 것도 전혀 뜨지 않는다. request header에 아래와 같은 경고 문구(?) 같은 게 발생했다.

provisional headers are shown

 

크롬이 안내하는 링크로 이동해보면 이런 내용이 나온다.

The request wasn't sent over the network but was served from a local cache, which doesn't store the original request headers. In this case, you can disable caching to see the full request headers. 

 

대충 번역기를 돌려보면 request가 네트워크를 통해 전송되지는 않았지만 (원본 request header를 저장하지 않는) 로컬 캐시를 통해 제공하였다. 이 경우 캐싱을 비활성화하여 전체 요청 헤더를 볼 수 있다. 이런 내용인데 사실 무슨 소리인지는 잘 못 알아들었다. 대충 키워드를 보고 request 전송에 문제가 있다는 건가? 캐시에 문제가 있나? 라는 추측을 했을 뿐이다.

 

---

2. 해결 과정

해당 현상을 해결해보고자 아래와 같은 시도를 해보았다.

 

-1. API 직접 호출하기 📤

처음에는 해당 API를 브라우저에서가 아닌 swagger를 통해 호출해보았다. 직접 호출할 때는 정상적으로 응답 값을 잘 받아왔다.

 

-2. 코드 분석하기 📃

다음은 API 코드를 째려봤다. 코드를 보니 특정 권한을 가진 유저들만 조회할 수 있도록 하는 로직이 존재했다. 최근에 회사에서 권한 설정을 새로 부여받은 일이 있어서 아! 뭔가 권한 설정이 제대로 안 됐거나 꼬인 건가? 라는 생각에 관련 팀에 문의를 남겼다. 하지만 돌아온 건 권한 설정은 잘 되어있다는 답변이었다.

 

-3. 타계정 이용하기 🧑‍💻

이번에는 다른 사람의 계정을 빌렸다. 사실, 문제를 해결하고자 한 시도는 아니고 회피에 가깝다. 다른 팀에 문의를 남겨놓고 답변이 오기까지의 공백에 가만히 있을 수는 없어서 일단 다른 일이라도 하고자 계정을 빌렸다. 그런데 팀원의 맥북에서는 잘 동작하던 것이 내 맥북으로 시도하니 또다시 문제가 발생했다.

 

-4. 크롬 초기화 🌈

문제가 또다시 재발하자 크롬을 의심했다. 이번에는 시크릿 모드로도 시도해보았다. 시크릿 모드로 시도하고 나서야 빌린 팀원의 계정으로도, 내 계정으로도 문제가 발생하지 않았다. 그래서 이번에는 이거다! 라고 확신하며 쿠키랑 캐시를 초기화했다. 강력 새로고침도 반복했고, 크롬을 아예 제거한 뒤 재설치도 해보았다. 하지만 해당 현상은 지속되었다. 😅

 

-5. 로그 살펴보기 👀

이번에는 프론트 팀의 도움을 받았다. 프론트 팀분이 말씀하시길 요청이 아예 발생하지도 않은 것 같다고 하셨다. 사실 확인을 위해 모니터링 도구 중 하나인 pinpoint를 통해 조회해보았더니 실제로 요청이 서버로 도달하지도 않았다. 다만 내가 pinpoint 사용이 미숙하기 때문에 발견하지 못했을 수도 있겠다는 생각이 들어서 다른 이유를 계속 찾아보았다.

 

이번에는 개발자 도구에서 console 탭을 살펴보았다. 아래와 같은 net::ERR_BLOCKED_BY_CLIENT라는 문구가 발생하고 있었다. (아래 사진은 같은 문제가 발생하는 케이스를 캡쳐해온 것으로 회사 코드와는 무관합니다.)

 

-6. 해결 🎉

위 문구를 구글링해보면 많은 사람들이 답변해주고 있다. AdBlock등과 같은 크롬 플러그인에서 브라우저에서 어떤 리소스를 가져오는 것을 차단하기 때문에 발생하는 오류이다. 나도 AdBlock을 사용하고 있었고, 플러그인을 끄니까 더이상 문제가 발생하지 않았다.

+ AdBlock은 어떤 기준으로 리소스를 차단할까?
블로그 같은 광고가 포함된 사이트들을 몇 개 들락날락하며 차단되는 리소스를 확인해보았더니 'ad'라는 키워드가 들어간 경우 차단되는 듯 했다. 나한테 발생했던 문제의 API를 살펴보았더니 역시나 쿼리스트링에 'ad'라는 키워드가 들어갔었다. 

 

 

---

3. 내 행동 되돌아보기

 

 

해결한 소감부터 말해보자면 이렇게 간단한 문제였는데 며칠 동안 삽질한 것이 허무했다. 내 행동들을 돌이켜보니 너무 개발자답지 못한, 막무가내식 시도만 했던 것 같아 부끄러워졌다. 그래서 정리해본다! 나의 어떤 점을 잘했다고 생각하는지, 어떤 점을 부끄럽게 여겼는지 파악해보겠다.

 

😄 잘했다고 생각하는 점

• 도움을 구하는 것을 부끄러워하지 않았다.
• 도움에 완전히 기대지 않고, 스스로 문제점 파악을 위해 노력했다.
• 나의 생각을 100% 신뢰하지 않았다. (내가 틀릴 수 있다는 가정을 계속 열어두었다)

 

😳 부끄럽다고 생각하는 점

• 문제 원인 파악 및 해결 시도를 나의 예측에만 기댔다.
• 공식 문서를 대충 읽고 넘겼다.
• 다른 사람의 말을 100% 신뢰했다.
• 로그를 제대로 파악하지 않았다.

 

오류의 원인을 추적하기 위해서는 로그를 찾아보는 것이 가장 정확하다고 생각한다. 하지만 나는 내가 이미 경험한 것들, 나의 지식들을 몇 가지만 적용하면 금방 해결할 수 있을거란 생각에 로그를 무시해버렸다.

 

해결 과정을 다시 떠올려보자. 문제를 발견했던 시점에 이미 크롬이 '이 요청은 네트워크를 통해 전송되지 않았을 수 있다.'고 힌트를 줬었다. 그렇다면 API가 정상적으로 호출되지 않은 이유에 대해서 생각해 보았어야 했다. swagger를 통해 API가 정상적으로 호출되는지를 확인한 것은 좋았으나, 정상임을 확인한 후에도 코드를 하나하나 분석했다. (swagger에서 API가 정상적으로 호출되었고 나한테서만 발생하는 문제라는 점을 생각해보면 코드에는 문제가 없을텐데도)

 

그리고 여기 저기 조언을 구하면서 이런거 아닐까요? 저런건 아닐까요? 라는 의견에 쉽게 휘둘렸다. 나의 생각은 100% 신뢰하지 않았으면서 다른 사람의 생각에 너무 쉽게 의존해버렸다. 다른 사람의 생각을 부정하거나 의심해야 한다는 의미는 아니다. 다만, 나의 설명이 부족해서 어떤 상황인지 정확히 전달하지 못했을수도 있고 나의 잘못된 가정이 상대에게 편견을 심어주었을 수도 있다. 다른 사람의 말에 의존하기 보다는 내가 한번더 검증을 해봤어야 하는 일이다. 이 부분에 대해서는 아마 신입이라 아직까지는 내 생각에 자신이 없어서 그랬던 것 같기는 하다.

 

기록이 중요하다고 생각해서 블로깅도 열심히 하면서 정작 오류 찾을때는 '로그'라는 기록을 소홀히 했다는 것이 부끄러웠다. 그래도 이번에 문제를 겪으면서 로그를 남기는 중요성, 그리고 로그를 파악하는 중요성에 대해서 리마인드하는 계기가 되었다. 앞으로는 기록에 미친 사람이라 부를 수 있을 정도의 꼼꼼한 개발자가 되도록 노력해보겠다. (연로그라는 닉값을 하자)

 

기록!!