모든 응답을 200 OK로 내리는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-11-14

200명이 넘는 백엔드 개발자들을 멘토링하며 포트폴리오 코드를 열어보면 흔히 마주치는 구조가 있습니다. 모든 컨트롤러 메서드가 ResponseEntity.ok()를 반환합니다. 데이터가 없거나 조회가 실패해도, 심지어 널 포인터 예외가 터져도 HTTP 상태 코드는 200 OK입니다. 응답 바디에 {"success": false, "code": "USER_NOT_FOUND"} 같은 JSON을 채워 넣었으니 문제없다고 여깁니다.

이유를 물어보면 답은 대개 비슷합니다. "프론트엔드 개발자가 그렇게 요청했어요." 혹은 "바디 안에 상태 코드가 들어있어서 파싱하기 편하잖아요." 편리함처럼 보이는 이 선택은 실무 환경에서 심각한 장애를 부릅니다.

네트워크 장비와 인프라는 바디를 읽지 않습니다

HTTP 상태 코드는 백엔드와 프론트엔드 둘만의 귓속말이 아닙니다. 클라이언트와 서버 사이에는 API 게이트웨이, 로드밸런서(ALB), CDN, 웹 방화벽 같은 인프라 장비가 존재합니다. 이 장비들은 패킷의 본문을 열어 JSON을 파싱하지 않습니다. HTTP 헤더의 상태 코드 3자리를 보고 요청의 성패를 판단합니다.

서버가 에러로 뻗어도 200 OK를 던지면 로드밸런서는 정상으로 판단해 트래픽을 계속 보냅니다. CDN은 에러 안내를 정상 응답으로 여겨 캐시에 저장합니다. 다른 사용자가 접속했을 때 서버는 멀쩡한데도 캐시된 에러 창을 보게 됩니다. 상태 코드를 무시하는 순간 인프라의 방어선이 무너집니다.

모니터링 대시보드는 침묵합니다

실무 운영에서 가장 위험한 순간은 장애가 났는데 아무 알람도 울리지 않을 때입니다. Datadog이나 Sentry 같은 APM 도구들은 HTTP 5xx 에러율을 기준으로 장애 알람을 울립니다. 하지만 모든 에러 응답을 200으로 내리면 대시보드의 에러율 그래프는 완벽한 0%를 가리킵니다.

실제 결제는 실패하고 사용자는 에러 화면을 보는데 온콜 담당자는 알람을 받지 못합니다. 고객 센터로 문의가 쏟아진 뒤에야 허겁지겁 로그를 뒤집니다. 모니터링 시스템을 눈멀게 만든 주범이 바로 편리하다고 선택했던 200 OK 응답입니다.

프로토콜의 약속을 지키는 것이 기본입니다

HTTP는 수십 년 동안 합의해 만든 표준 규약입니다. 400은 요청 오류, 401은 인증 필요, 403은 권한 없음, 404는 리소스 없음, 500은 서버 오류로 이미 명확합니다. 상태 코드가 4xx나 5xx로 내려와야 프론트엔드의 axios나 fetch도 catch 블록으로 자연스럽게 분기합니다.

백엔드 개발자의 실력은 라이브러리를 많이 아는 데서 나오지 않습니다. 프로토콜의 표준 약속을 존중하고, 내가 만든 API가 네트워크 인프라와 어떻게 상호작용하는지 이해하는 감각에서 시작합니다. 오늘 작성한 코드에서 습관처럼 ok()를 호출하고 있다면, 그 응답이 지나갈 네트워크 경로를 다시 바라보아야 합니다.