<코드에만 갇히지 않기> 10년차가 되어도 여전히 자주 하는 실수 중 하나는, 문제를 정의하는 것부터 해결하는 흐름을 코드에서만 찾는다는 것입니다. 예를 들어, 웹사이트의 속도가 느리다는 제보가 어디선가 들어옵니다. A. 웹사이트의 속도가 느리대요! B. 어 왜 느리지? 코드 살펴볼게요. B. 코드에 불필요한 코드가 너무 많았네요. 다 제거해볼게요. B. 다 제거해서 배포했습니다. A. 그래도 속도가 여전히 느린 거 같아요! B. 오 이제 최적화할 수 있는 게 없는데...? 일단 이 대화에서 몇 가지 우리가 놓친 게 있어요. 1. 웹 사이트는 지속적으로 항상 느린가? 그 순간에만 느렸는가? 2. 속도가 느리다고 말한 사람의 환경은 어땠는가? 3. 속도 측정 도구 등을 이용해 측정할 수 있는가? 4. 속도가 빠르다 <> 느리다에 대한 기준이 잡혀있는가? 제가 겪었던 이슈 중에서 이런 이슈가 있었어요. 이미지를 업로드하는 데, 이미지 최적화 서버를 제대로 구축하지 않은 상태로 이미지를 업로드해서 이미지가 원본 크기로 올라간거죠. 어떤 이미지는 10MB가 넘는 경우도 있었고 그로 인해 웹 사이트가 전반적으로 느려졌습니다. 또 이런 경우도 있었어요. 웹 사이트 메인에서 비디오를 재생하는데 이걸 최적화 안하고 올려서 30MB가 그대로 올라가버렸네요. 빠르게 최적화해서 4MB까지 줄였었습니다. CSS 코드 한 줄 때문에 IE에서 느렸던 기억도 있어요. 우리는 JS만 계속 원인이라고 생각했고, DOM 갯수가 문제라고 생각했더니 사소한 CSS 한 줄이 문제더라고요. 또 이벤트 서버에 갑자기 사람들이 몰려서, 순간적으로 순단 현상이 발생하고 있는거였는데 그걸 잘 인지하지 못하고 그냥 최적화 해야지! 만 하다가 분산 환경에서 파드 늘리니까 쉽게 해결되었던 적도 있었고요. 그러나 개발자가 가장 쉽게 해결할 수 있는 방법이 코드를 수정하는 데에 있고, 또 코드를 수정했다는 사실이 '내가 할 일은 다 했어!' 라는 자기 위안을 주기 때문에 저를 포함하여 대부분의 개발자가 코드부터 수정하려고 하는 거 같아요. 하지만 코드 바깥쪽에도 다양한 문제가 도사리고 있고, 애초에 문제가 아닌 상황일 수도 있습니다. 그러니 앞으로 어떤 문제가 발생하였을 때에는 '꼭 코드를 수정해야만 해결할 수 있는 문제인가?' 를 체크해보면 좋을 거 같아요. 자기 반성을 담아 작성했습니다.