에러체크 딱딱딱

코드를 작성하다 보면 밥 먹듯이 에러가 발생하지만, 원인 모를 에러를 마주치면 하루 종일 또는 그 이상이 걸려도 해결하지 못할 때가 있다.
만약 에러를 제대로 체크하지 않는다면 정말 간단한 에러를 해결하지 못하고 시간 낭비할 수 있다.
(그게… 접니다?)

항상 대표님이 에러 로그를 확인하라고 강조하셨는데, 아직 익숙지 않아서 별거 아닌 에러에 삽질하는 상황이 자주 일어났다.

따라서 이러한 실수를 줄이기 위해 에러 조치를 어떻게 하면 잘할 수 있을지에 대해 알아보려 한다.

내가 생각하는 에러 조치 순서

에러를 조치하는 방법과 순서는 다양하지만 내가 생각하는 방법은 다음과 같다.

1. 로그 확인
2. 로그를 복사하여 ChatGPT한테 물어보기
3. 전문가에게 도움 요청하기
4. 삽질하기

삽질하기는 GPT에게 물어보면서 계속 코드 수정 반복하기와 에러 발생 부분 중간중간에 log를 삽입하여 찍어보기로 나누어진다.

우선 부끄럽지만 놀랍게도 최근까지 나는 로그를 잘 확인하지 않았다.
‘로그를 안 보고 해결할 수 있다.’ 라는 근자감이 아니라 로그를 봐도 와 이거 심각한 상황이다를 연상케하는 문장들이 와르르 쏟아지니까 겁을 먹을 수밖에 없었다.

이제는 Chrome devtools의 로그를 확인하고 Sources 탭을 이용하여 코드 중단점을 설정하거나, 변수 값을 확인하는 것에 익숙해져 있다.

위 방법은 JavaScript에서 에러가 발생한 상황이고 파이썬 소스에서 에러가 발생하면 서버에서 로그를 확인하고 조치를 취해야 한다.

나는 파이썬에서 에러가 발생하면 1–2–4–4–4–3 순으로 조치를 취한다.
로그에서 에러가 발생한 소스 위치를 알려주기 때문에 파악하는 것은 어렵지 않다.
(‘파악하는 것’은 어렵지 않다…)

로그에는 Level이 있다

로그 레벨(Log Level) 은 프로그램 또는 애플리케이션에서 로그 메시지의 중요도와 유형을 나타내는데 사용되는 단계를 의미한다.

1. DEBUG: 가장 낮은 로그 레벨로, 디버깅 목적으로 사용한다.
2. INFO: 프로그램의 주요 이벤트를 기록한다.
3. WARNING: 경고 메시지로, 애플리케이션의 정상적인 동작은 보존되지만 잠재적인 문제를 나타낸다.
4. ERROR: 오류 메시지로, 애플리케이션이 기능을 제대로 수행하지 못하거나 중대한 문제가 발생한 경우 기록된다.
5. FATAL (CRITICAL): 가장 높은 로그 레벨로, 치명적인 오류나 심각한 장애 상황을 나타낸다.
6. TRACE: 디버그보다 더 상세한 추적 정보를 기록하며, 주로 디버깅 목적으로 사용된다.

로깅 시스템은 일반적으로 로그 레벨에 따라 설정할 수 있다.
예를 들어 개발 환경에서는 모든 로그 레벨을 활성화하여 디버깅에 유용한 정보를 얻을 수 있다.

또한 운영 환경에서는 ERROR 또는 그 이상의 레벨만 활성화하여 중요한 이벤트 및 문제 상황을 기록할 수 있다.

로그 레벨은 로그 메시지의 중요도와 심각성을 나타내므로, 올바른 로그 레벨을 선택하고 설정해야 애플리케이션의 동작을 모니터링하고 문제를 해결하는 데 도움을 줄 수 있다.

에러를 체크하는 것은 개발자로서 기본이라는 생각이 든다.
에러를 놓치면 예상치 못한 결과와 심각한 문제를 초래할 수 있기 때문이다.

로그를 분석하기 위해서는 우선 로그를 잘 찍는 습관을 들여야 한다고 생각한다.
사소한 것이라도 로그를 찍어가면서 어디서 에러가 나는지, 값이 잘 전달되는지 파악해야 한다.