같은 문제가 계속 반복될 때 우리는 흔히 ‘운이 나빴다’거나 ‘재수가 없었다’고 넘기곤 합니다. 하지만 한 걸음만 물러나 보면, 그 반복 속에는 반드시 구조적인 이유가 숨어 있습니다. 이 글에서는 제가 실제로 겪었던 경험과 함께, 왜 같은 에러가 계속 발생했는지, 그리고 어떻게 그 고리를 끊을 수 있었는지 차분하게 풀어보려 합니다.
1. 처음에는 단순한 실수라고 생각했던 반복의 시작
처음 에러가 발생했을 때 저는 그저 ‘이번 한 번의 실수’라고 생각했습니다. 바쁘게 일을 처리하던 와중에 놓친 설정 하나, 무심코 넘긴 로그 한 줄, 급하게 수정한 코드 한 줄이 원인이라고 여겼습니다. 누구나 그럴 수 있다고 스스로를 위로하기도 했습니다. 그런데 이상하게도, 비슷한 유형의 에러가 며칠 간격으로 반복되기 시작했습니다. 그때부터 단순한 실수가 아니라 뭔가 구조적인 문제가 있다는 생각이 들었습니다.
그 당시를 떠올리면, 저는 항상 ‘눈앞의 문제’를 해결하는 데에만 집중하고 있었습니다. 에러가 발생하면 당장 서비스가 멈추지 않도록 조치를 하고, 사용자가 불편하지 않게 빠르게 복구하는 것이 가장 중요하다고 여겼습니다. 그러다 보니 왜 이런 일이 발생했는지 깊게 들여다보는 시간을 거의 갖지 못했습니다. 지금 생각해보면, 바로 그 지점이 반복의 시작이었습니다.
특히 로그를 자세히 보지 않았던 습관이 큰 문제였습니다. 로그에는 이미 여러 차례 같은 경고 메시지가 찍혀 있었지만, 저는 그것을 ‘당장은 문제 없는 경고’ 정도로만 받아들였습니다. 하지만 나중에 알고 보니 그 경고들이 결국 큰 에러로 이어지는 신호였습니다. 사소하게 보였던 신호들을 무시한 것이, 결국 같은 문제를 다시 불러오는 결과를 만들었습니다.
여기서 저는 중요한 깨달음을 얻었습니다. 문제는 항상 ‘갑자기’ 발생하지 않는다는 점입니다. 대부분의 에러는 작은 신호를 여러 번 보내고, 우리가 그것을 놓쳤을 때 비로소 크게 터집니다. 그때부터 저는 단순한 해결이 아니라 원인분석이라는 관점으로 상황을 보기 시작했습니다.
개인적으로 이 시점에서 가장 크게 느낀 점은, 사람은 바쁠수록 더 많은 것을 놓친다는 사실이었습니다. 여유가 없을수록 문제를 더 얕게 보게 된다는 점도 체감했습니다.
객관적인 자료를 찾아보니, 실제로 IT 운영 현장에서 발생하는 장애의 상당수는 ‘이미 알고 있던 경고를 방치한 경우’라고 합니다. 사전에 기록된 로그, 반복된 경고, 유사한 패턴을 무시하는 것이 반복 에러의 주요 원인으로 꼽힌다는 점에서, 제 경험과 크게 다르지 않았습니다.
2. 문제를 해결했지만, 원인을 해결하지 못했던 시간들
에러가 발생할 때마다 저는 꽤 빠르게 대응했습니다. 임시 조치를 하고, 설정을 수정하고, 필요한 경우에는 재배포도 진행했습니다. 겉으로 보면 문제 해결 능력이 좋은 것처럼 보였을지도 모릅니다. 하지만 시간이 지나 돌아보니, 저는 문제를 ‘해결’한 것이 아니라 그저 ‘잠재운’ 것이었습니다.
예를 들어, 특정 기능에서 메모리 사용량이 급격히 증가하는 현상이 있었습니다. 그때마다 서버를 재시작하면 문제가 사라졌기 때문에, 저는 그 방법을 반복적으로 사용했습니다. 당장은 효과가 있었기 때문입니다. 하지만 며칠 후 또 같은 현상이 발생했고, 저는 다시 같은 방법을 사용했습니다. 이 패턴이 여러 번 반복되었습니다.
이 과정에서 저는 점점 익숙해졌습니다. 에러가 나도 당황하지 않았고, 어떻게 처리해야 하는지도 잘 알게 되었습니다. 하지만 그 익숙함이 오히려 더 큰 문제였습니다. ‘왜 이런 현상이 발생하는지’를 묻지 않게 되었기 때문입니다.
이때부터 저는 의식적으로 접근 방식을 바꾸기 시작했습니다. 단순한 조치가 아니라, 기록을 남기고 패턴을 보기 시작했습니다. 언제 발생했는지, 어떤 상황에서 발생했는지, 직전에 어떤 작업을 했는지 하나씩 정리해보니 놀랍게도 일정한 공통점이 보이기 시작했습니다.
그 공통점은 특정 기능을 사용할 때, 특정 시간대에 트래픽이 몰릴 때, 그리고 특정 설정값이 유지된 상태일 때 에러가 발생한다는 점이었습니다. 이 패턴을 확인하면서 저는 비로소 원인분석의 중요성을 실감하게 되었습니다.
제 개인적인 생각으로는, 사람은 눈앞의 불편을 없애는 데에는 능숙하지만, 근본적인 불편을 없애는 데에는 상대적으로 소홀해지는 경향이 있는 것 같습니다.
관련 자료를 찾아보니, 실제로 많은 조직에서 ‘재발 방지 보고서’를 중요하게 다루는 이유가 여기에 있었습니다. 단순한 조치 기록이 아니라, 왜 이런 일이 발생했는지에 대한 체계적인 정리가 있어야 같은 문제가 반복되지 않는다고 합니다.
3. 반복을 끊어낸 결정적인 계기와 배운 점
결정적인 변화는, 어느 날 같은 에러가 또 발생했을 때 찾아왔습니다. 그날은 유난히 바빴고, 저는 평소처럼 빠르게 조치하려다가 문득 이런 생각이 들었습니다. ‘이걸 언제까지 이렇게 반복할 것인가’라는 생각이었습니다. 그 순간 저는 당장의 복구보다, 시간을 조금 더 들여 구조를 들여다보기로 마음먹었습니다.
코드를 다시 읽고, 설정을 하나씩 검토하고, 로그를 시간 순서대로 정리했습니다. 그렇게 몇 시간을 투자한 끝에, 문제의 핵심 원인을 찾아낼 수 있었습니다. 특정 조건에서 예외 처리가 제대로 되지 않아 리소스가 계속 쌓이고 있었던 것입니다. 그 부분을 수정하자, 이후로는 같은 에러가 발생하지 않았습니다.
그 경험 이후 저는 문제를 대하는 태도가 완전히 달라졌습니다. 에러가 발생하면 ‘어떻게 끌 것인가’보다 ‘왜 켜졌는가’를 먼저 생각하게 되었습니다. 이 차이가 생각보다 큽니다. 접근 방식이 달라지면, 해결의 깊이도 달라집니다.
여기서 저는 다시 한 번 원인분석이라는 단어의 의미를 되새기게 되었습니다. 단순히 원인을 찾는 것이 아니라, 반복을 끊는 사고 방식이라는 점을 깨달았습니다.
개인적으로는 이 경험 이후로, 일이 조금 느려지더라도 더 꼼꼼하게 보는 습관이 생겼습니다. 급하게 처리하는 것보다, 한 번 제대로 보는 것이 훨씬 많은 시간을 아껴준다는 것을 몸소 느꼈기 때문입니다.
여러 운영 사례를 찾아보면, 반복되는 에러의 가장 큰 특징은 ‘이미 한 번 겪었던 문제’라는 점이라고 합니다. 하지만 그때 제대로 된 원인분석이 이루어지지 않으면, 같은 문제가 다른 형태로 계속 나타난다고 합니다. 결국 반복을 끊는 열쇠는 기술력이 아니라, 문제를 바라보는 태도에 있다는 점을 알게 되었습니다.
지금도 저는 에러가 발생하면 조금은 차분해집니다. 그리고 스스로에게 묻습니다. ‘이 문제는 무엇을 알려주려고 하는 걸까’라고 말입니다. 이런 질문을 던지는 습관이, 저에게는 가장 큰 변화였습니다.
✅함께 보면 좋은 글✅