마지막 줄에서 예외 종류 확인하기
Python 프로그램이 실패하면 긴 traceback을 보고 맨 위의 파일부터 고치기 쉽습니다. 먼저 마지막에 표시되는 예외 종류와 메시지를 읽어 보세요. 파일을 못 찾은 문제인지, 없는 키를 조회한 문제인지, 예상하지 못한 타입을 연산에 사용한 문제인지에 따라 확인할 조건이 달라집니다. traceback의 호출 목록은 일반적으로 바깥 호출에서 예외가 발생한 안쪽으로 이어집니다. 마지막 위치에서 실제 실패한 연산을 확인한 뒤 자신의 코드 쪽으로 돌아오며 값의 출처를 찾으면 됩니다. 예외가 연결되어 여러 묶음이 출력된 경우에는 각 묶음 사이의 원인 설명도 함께 읽어야 합니다.
메시지보다 실패한 표현을 작게 나누기
한 줄에서 여러 인덱싱과 함수 호출을 하면 어떤 부분에서 예외가 났는지 바로 알기 어려울 수 있습니다. 예를 들어 응답에서 사용자 목록을 꺼낸 뒤 첫 원소의 이름을 읽는 코드는 응답 구조, 목록 길이, 원소 타입 중 어느 조건이 틀려도 실패할 수 있습니다. 조사할 때 각 단계를 임시 변수로 나눠 값과 타입을 확인하세요. 이름만 보고 목록이라 가정하지 말고 실제로 list인지 dict인지 None인지 봅니다. 오류 메시지를 문자열로 검색하는 것보다 실패 직전의 실제 입력을 확인하는 편이 원인을 직접 설명할 수 있습니다. 로그에는 민감한 원문을 그대로 남기지 않도록 주의합니다.
예외를 넓게 삼키지 않기
일단 실행되게 하려고 모든 코드를 try와 except Exception으로 감싸고 빈 값을 반환하면 실패가 다음 단계로 이동할 수 있습니다. 예외를 처리하려면 해당 실패가 예상 가능한 상황인지, 다시 시도하거나 사용자에게 알려야 하는지 먼저 정해야 합니다. 파일이 없을 때 기본값을 쓰는 정책과 데이터 형식이 망가졌는데 무시하는 처리는 다릅니다. 조사 중에는 원래 traceback을 보존하고 필요한 문맥만 덧붙이는 편이 좋습니다. 잘못된 입력이 어디서 처음 들어왔는지 찾은 뒤 그 경계에서 검증과 오류 처리를 설계하면 내부 곳곳에 임의의 예외 처리를 추가하는 일을 줄일 수 있습니다.
네이티브 디버거와 역할 나누기
DBG Desk는 GDB를 통해 네이티브 프로세스를 관찰하는 도구이며 Python 소스용 디버거 UI가 아닙니다. 일반적인 Python 예외는 traceback과 pdb 같은 언어 수준의 도구로 조사하는 편이 직접적입니다. Python 인터프리터가 운영체제 신호로 충돌하거나 C 확장 모듈 내부를 조사해야 할 때 네이티브 디버거가 필요할 수 있지만, 이 경우 인터프리터와 확장의 심볼 등 추가 조건이 있습니다. 단순한 KeyError를 보려고 먼저 기계어를 따라갈 필요는 없습니다. 예외를 재현하는 작은 Python 입력과 호출 경로를 확보하고 해당 수준에서 설명되지 않는 충돌인지 구분하세요.
KeyError를 좁히는 예
설정 객체에서 timeout을 읽는 줄이 KeyError로 실패했다면 먼저 설정 전체가 어디서 만들어졌는지 봅니다. 오타가 있는 키인지, 특정 환경에서 그 항목을 생성하지 않는지, 읽기 전에 다른 코드가 제거하는지 구분합니다. 무조건 get으로 바꾸고 기본값 0을 넣으면 시간 제한 정책이 의도와 달라질 수 있습니다. 필수 설정이라면 시작할 때 형식을 검증해 필요한 항목을 분명히 알리는 편이 낫습니다. 선택 설정이라면 기본값의 의미를 정하고 값이 없는 입력도 정상 사례로 검사하세요. 예외 종류를 확인한 뒤 데이터 계약으로 돌아가면 단순히 오류 문구만 사라지는 수정을 피할 수 있습니다.