Localhost는 거짓이다: Happy Path 오류
Source: Dev.to
Happy Path 오류론
우리는 모두 그런 경험을 해봤습니다. 새로운 기능을 만들면서 완벽한 시나리오를 상상하죠: API가 언제나 20 ms 안에 응답하고, 사용자는 항상 올바른 이메일 주소를 입력하고, 데이터베이스는 절대 타임아웃되지 않으며, JSON은 언제나 올바르게 포맷된다고 생각합니다. 그 영화를 그대로 구현한 코드를 작성하고, 로컬 머신에서 실행해 보니 완벽히 동작합니다. 커밋하고, 푸시하고, 집에 갑니다.
그런데 새벽 3시, 휴대폰이 울립니다. 프로덕션 서버가 API가 평문 “502 Bad Gateway” HTML 페이지를 반환했기 때문에 다운되었습니다. 여러분의 코드는 이를 JSON으로 파싱하려다 오류가 발생했고, 전체 애플리케이션이 중단되었습니다.
이것이 Happy Path 오류론—주니어 개발자들이 PagerDuty 알림에 깨어나는 가장 큰 이유입니다. 위험한 환상은 다음과 같습니다:
“로컬에서 동작하면 프로덕션에서도 동작한다.”
코더는 모든 것이 순조롭게 진행될 때 동작하는 소프트웨어를 작성합니다. 전문가는 문제가 발생했을 때도 살아남는 소프트웨어를 작성합니다. 해피 패스만 코딩한다면 애플리케이션은 부서지기 쉽습니다.
“‘조심히 운전할 거니까’ 에어백 없이 차를 만드는 것과 같다.”
낙관주의는 우리가 감당할 수 없는 사치입니다. 네트워크는 혼잡해지고, 서드파티 서비스는 다운되며, 사용자는 예상치 못한 행동을 합니다. 코더에서 전문가로 성장하려면 낙관주의를 편집증으로 바꿔야 합니다: 입력은 악의적일 수 있고, 네트워크는 혼잡하고, 데이터베이스는 고갈될 수 있다고 가정하세요.
- 주니어 사고방식: “데이터를 받아올 거야.”
- 시니어 사고방식: “데이터를 못 받아오면 어떻게 하지?”
JSON 신뢰하기: 흔한 함정
우리는 모두 API 응답이 유효한 JSON이라고 가정하고 코드를 작성한 적이 있습니다. 99 %의 경우엔 잘 동작하지만, 그 1 %가 가동 시간을 파괴할 수 있습니다.
이전: “낙관적인” 접근법
// 네트워크가 완벽하고 API가 우리의 친구라고 가정합니다.
// 'apiResponse'가 "502 Bad Gateway"(문자열)인 경우, 앱이 크래시됩니다.
const parsedResponse = JSON.parse(apiResponse);
// 바로 데이터를 사용하려고 합니다.
// 이전 줄이 실패하면 여기까지 오지 않습니다.
updateUI(parsedResponse.user);이후: “편집증적인” 접근법
let parsedResponse;
try {
// 위험한 작업을 시도합니다
parsedResponse = JSON.parse(apiResponse);
} catch (error) {
// 혼돈 감지: API가 우리를 속였습니다.
// 크래시 대신 우아하게 처리합니다.
console.error('API returned malformed JSON:', error);
// 앱이 살아 있도록 기본 설정을 로드합니다
parsedResponse = DEFAULT_CONFIG;
}
// API가 실패했지만, 애플리케이션은 살아남았습니다.
updateUI(parsedResponse);두 번째 예시에서는 API가 실패했지만 애플리케이션이 살아남았습니다. 사용자는 일반적인 오류 메시지나 캐시된 데이터를 보게 되겠지만, 하얀 화면이 나타나지는 않을 것입니다.
방어적 코딩 원칙
- 네트워크를 믿지 마라.
- 사용자 입력을 믿지 마라.
- 데이터베이스를 믿지 마라.
방어적으로 코딩하세요. 새벽 3시에 서버가 불타고 있을 때 “내 머신에서는 동작했어”는 변명이 될 수 없습니다. 컴파일러를 만족시키기 위해서만 코드를 작성하는 것을 멈추세요.
추가 읽을거리
이 글은 제 핸드북 The Professional Junior: Writing Code that Matters의 발췌본이며, 쓰여지지 않은 엔지니어링 규칙들을 다루는 전술적인 현장 가이드입니다.