로그 안 보고 삽질을 시작하게 된 이유
“설마 이게 문제일까?”라는 안일함에서 출발한 사고
로그 안 보고 삽질은 많은 개발자들이 한 번쯤 겪는 실수입니다. 이 문단에서는 그 출발점이 되는 심리와 환경을 이야기해봅니다.
개발을 하다 보면 예상치 못한 오류를 마주하는 순간이 꼭 찾아옵니다. 처음에는 간단한 설정 문제 같아 보였고, 코드 몇 줄만 수정하면 해결될 것처럼 느껴졌습니다. 그래서 저는 그때 로그 안 보고 삽질이라는 가장 위험한 선택을 자연스럽게 하게 되었습니다. 지금 돌이켜보면 이 선택이 이후 며칠을 날려버린 원인이었습니다.
사실 당시 상황은 급박하지도 않았습니다. 배포 일정이 촉박했던 것도 아니었고, 혼자 진행하는 사이드 프로젝트였습니다. 그런데 이상하게도 “일단 코드를 의심해보자”라는 생각이 먼저 들었고, 로그를 확인하는 기본적인 절차는 뒤로 밀려났습니다. 이게 참 아이러니합니다. 개발을 어느 정도 해봤다고 생각할수록, 기본을 건너뛰는 경우가 생기더라고요.
내가 했던 실수
- 최근 수정한 코드부터 하나씩 롤백
- 라이브러리 버전 의심
- IDE 캐시 문제라고 단정
- 서버 환경 문제라고 추측
문제는 이 모든 과정에서 로그 안 보고 삽질을 계속 반복했다는 점입니다. 로그는 이미 답을 알고 있었는데, 저는 그 답을 보지 않으려고 애써 다른 길로만 돌아간 셈이었습니다.
개인적으로 이때 느꼈던 감정은 ‘귀찮음’에 가까웠습니다. 로그를 열고, 필터링하고, 의미 없는 줄들을 건너뛰는 과정이 번거롭게 느껴졌습니다.
하지만 지금 생각해보면, 그 귀찮음을 피하려다 훨씬 더 큰 시간을 낭비했습니다.
객관적으로 보면 로그는 개발자가 사용할 수 있는 가장 정직한 기록입니다. 감정도 없고, 추측도 없습니다. 단순히 “무슨 일이 있었는지”를 그대로 보여줄 뿐입니다. 그럼에도 불구하고 많은 개발자들이 로그를 나중에 보거나, 아예 보지 않습니다. 저 역시 그중 한 명이었습니다.
이 경험을 통해 배운 첫 번째 교훈은 단순합니다. 문제가 생겼을 때, 코드보다 먼저 로그를 봐야 한다는 너무나 기본적인 원칙이었습니다.
로그는 있는데 왜 안 보게 될까
경험이 쌓일수록 생기는 묘한 자신감
로그 안 보고 삽질이 반복되는 이유는 기술보다 심리에 가까운 문제입니다.
개발 경력이 아주 짧을 때는 오히려 로그를 더 열심히 봅니다. 무슨 말인지 몰라도, 일단 봅니다. 그런데 어느 정도 익숙해지면 상황이 달라집니다. “이건 내가 해봤던 유형이야”라는 생각이 먼저 들고, 로그는 참고용 정도로 밀려납니다.
저 역시 그랬습니다. 이전에 비슷한 에러를 해결한 경험이 있었고, 그 기억이 이번에도 통할 거라고 믿었습니다. 이 믿음이 바로 로그 안 보고 삽질의 시작점이었습니다.
이런 행동 패턴은 꽤 공통적입니다.
- 경험에 근거한 추측을 사실처럼 믿음
- 로그를 보기 전에 해결책을 먼저 정함
- 확인보다 수정이 먼저 진행됨
중간중간 “그래도 로그 한 번 볼까?”라는 생각이 들긴 했습니다. 하지만 이미 손은 코드를 고치고 있었고, 수정한 김에 더 손대보자는 흐름으로 넘어갔습니다. 이때 느낀 제 개인적인 생각은 “어차피 로그 봐도 뻔할 거야”였습니다. 지금 생각하면 근거 없는 자신감이었죠.
정보성 관점에서 보자면, 로그는 단순한 에러 메시지 이상의 역할을 합니다.
요즘 대부분의 시스템 로그에는 다음 정보가 포함됩니다.
- 발생 시점의 컨텍스트
- 요청 흐름
- 외부 의존성 상태
- 환경 변수 값
이런 정보들은 코드만 봐서는 절대 알 수 없습니다. 그럼에도 불구하고 개발자들이 로그를 외면하는 이유는, 로그 해석이 “귀찮고 어렵다”는 인식 때문입니다.
하지만 로그 해석 능력은 타고나는 것이 아니라, 반복 경험을 통해 쌓이는 기술입니다. 로그를 안 보면, 이 능력은 절대 성장하지 않습니다. 결국 로그 안 보고 삽질은 장기적으로 더 많은 삽질을 부르는 구조입니다.
이 문단을 쓰면서 느낀 점은 하나입니다. 경험이 많아질수록 겸손해야 한다는 말이, 개발에서는 특히 더 중요하다는 사실입니다.
삽질의 정점, 시간을 태우다
문제는 그대로인데 밤만 깊어갔던 순간
로그 안 보고 삽질이 실제로 어떤 비용을 만들어내는지 경험을 통해 풀어봅니다.
가장 뼈아팠던 건 시간 손실이었습니다. 처음에는 10분이면 끝날 거라고 생각했던 문제가, 어느새 반나절을 넘어 하루를 잡아먹었습니다. 그 사이 저는 수많은 가설을 세웠고, 대부분 틀렸습니다.
이 시점에서도 로그 안 보고 삽질은 계속됐습니다. 이유는 단순했습니다. 이미 너무 많은 시간을 썼기 때문에, “이제 와서 로그 보면 허탈할 것 같아서”였습니다.
이 감정, 생각보다 많은 분들이 공감하실 거라고 생각합니다.
당시 상황을 정리해보면 이렇습니다.
- 코드 수정 → 재빌드 → 실패
- 환경 변수 수정 → 재시작 → 실패
- 버전 다운그레이드 → 실패
이 과정에서 로그는 계속 쌓이고 있었지만, 저는 그 로그를 보지 않았습니다.
개인적으로 이때 제 상태는 꽤 지쳐 있었습니다. 판단력도 흐려졌고, 문제를 객관적으로 보기도 어려웠습니다.
결국 로그를 확인한 건, 거의 포기 상태에 가까웠을 때였습니다. 그리고 놀랍게도 로그에는 문제의 원인이 아주 명확하게 적혀 있었습니다.
외부 API 응답 포맷이 변경되었고, 그로 인해 파싱 에러가 발생하고 있었습니다.
이 순간 깨달았습니다. 로그 안 보고 삽질은 단순한 실수가 아니라, 개발자의 체력과 멘탈까지 소모시키는 행동이라는 것을요.
정보성 측면에서 보면, 이런 삽질은 개인 생산성뿐 아니라 팀 전체에도 영향을 줍니다. 실제로 여러 개발 생산성 관련 자료에서도 “문제 해결 시간의 상당 부분은 원인 파악 단계에서 소모된다”고 이야기합니다. 로그는 이 단계를 가장 빠르게 단축시켜주는 도구입니다.
이 경험 이후로 저는 하나의 원칙을 세웠습니다. 문제가 발생하면, 감정이 개입되기 전에 로그부터 연다. 지금도 완벽하진 않지만, 최소한 예전처럼 무작정 달려들지는 않게 되었습니다.
로그를 보는 습관을 만들기까지
의식적으로 연습해야 생기는 개발 습관
로그 안 보고 삽질을 줄이기 위해 제가 실제로 적용한 방법들을 공유합니다.
습관은 의지로만 바뀌지 않습니다. 그래서 저는 환경부터 바꾸기로 했습니다. 로그를 보기 쉽게 만들고, 안 볼 수 없게 만드는 방향으로요.
내가 적용한 방법들
- 에러 발생 시 로그 자동 팝업 설정
- 로그 레벨별 색상 구분
- 자주 보는 로그 패턴 메모
이렇게 하니 로그가 이전보다 훨씬 친숙해졌습니다. 예전에는 복잡한 텍스트 덩어리로 보였던 로그가, 이제는 “대화”처럼 느껴지기도 합니다.
개인적인 생각을 하나 덧붙이자면, 로그를 잘 보는 개발자는 문제를 두려워하지 않습니다. 왜냐하면 문제를 해결할 수 있는 단서를 항상 가지고 있기 때문입니다. 반대로 로그 안 보고 삽질을 반복하면, 문제 자체가 스트레스가 됩니다.
객관적인 정보로도 이를 뒷받침할 수 있습니다. 여러 개발자 설문 자료를 보면, 숙련 개발자일수록 디버깅 시 로그와 모니터링 도구를 가장 먼저 확인하는 비율이 높습니다. 이는 단순한 성향 문제가 아니라, 효율의 차이입니다.
이 단계에서 제가 배운 가장 큰 교훈은 이겁니다. 로그를 보는 건 선택이 아니라, 개발 과정의 일부라는 점입니다.
반성 기록이 남긴 진짜 가치
삽질도 기록하면 자산이 된다
로그 안 보고 삽질의 경험이 어떻게 자산으로 전환되었는지 정리합니다.
처음에는 이 경험을 기록으로 남길 생각이 없었습니다. 실패가 부끄러웠기 때문입니다. 하지만 시간이 지나고 나니, 이 기록이 누군가에게는 분명 도움이 될 수 있겠다는 생각이 들었습니다.
그래서 이렇게 글로 남기게 되었습니다. 단순한 반성이 아니라, 정보와 경험을 함께 담은 기록으로요. 이 글을 쓰면서 느낀 개인적인 감정은 “그때의 삽질이 헛된 건 아니었구나”라는 안도감이었습니다.
이 경험을 통해 얻은 배운 점을 정리하면 다음과 같습니다.
- 로그는 문제 해결의 출발점이다
- 경험은 추측이 아니라 검증을 돕는 도구다
- 기록은 같은 실수를 줄여준다
결국 로그 안 보고 삽질은 누구나 할 수 있는 실수입니다. 중요한 건 그 이후입니다. 같은 실수를 반복할지, 아니면 교훈으로 남길지의 차이입니다.
이 글을 읽는 분들께도 부담 없이 말씀드리고 싶습니다. 지금 삽질하고 계시다면, 이미 성장하고 계신 겁니다. 다만 로그는 꼭 먼저 확인해보시길 권해드립니다.