대부분의 Production Bugs는 코드에 있지 않습니다. 시스템 사이에 존재합니다.
Source: Dev.to
왜 가장 어려운 문제는 시스템 사이에 존재하는가
모두가 코드를 작성하는 이야기를 좋아한다—클린 코드, 빠른 코드, AI‑생성 코드, 버그‑프리 코드.
하지만 많은 실제 시스템에서는 가장 어려운 문제들이 지난 주에 작성한 컨트롤러, 저장 프로시저, API 메서드 안에 있지 않는다. 그 문제들은 시스템 사이에 나타난다.
요청은 시스템 A에서는 유효하고, 미들웨어에서 변환되며, 시스템 B에서 부분적으로 보강되고, 시스템 C에서는 조용히 거부된 뒤, 상태 플래그가 잘못된 레이어에서 정상으로 보였기 때문에 비즈니스에는 “완료”된 것으로 보고된다. 이런 종류의 실패는 원인과 결과가 분산된 컴포넌트에 흩어져 있기 때문에 생산 환경 이슈를 설명하기 어렵게 만든다.
가시성 및 분산 추적
OpenTelemetry의 가시성 문서는 복잡한 분산 시스템을 통해 전파되는 요청을 관찰하는 방법으로 분산 추적을 설명한다. 이는 로컬에서 재현하기 어려운 동작을 디버깅하는 데 도움이 된다.
같은 개념이 기업용 통합 플랫폼에서도 나타난다. SAP 문서에서는 Message Processing Log가 처리된 메시지와 개별 처리 단계에 대한 데이터를 저장하고, 메시지 모니터를 통해 테넌트별로 개별 메시지를 검사할 수 있다고 언급한다. 즉, 메시지 흐름을 단계별로 이해하는 것이 필수적이다.
사고 발생 시 물어야 할 핵심 질문
실패가 발생했을 때 고려할 내용:
- 실제로 무슨 일이 일어났는가?
- 어느 시스템이 진실의 원천인가?
- 페이로드가 잘못됐는가, 변환이 잘못됐는가?
- 수신 시스템이 이를 거부했는가, 무시했는가, 아니면 받아들인 뒤 나중에 실패했는가?
- 비즈니스 프로세스 실패인가, 아니면 잘못된 상태 표시인가?
이 질문에 답하려면 다른 사고방식이 필요하다: 잠시 빌더처럼 생각하는 것을 멈추고 조사관처럼 생각해야 한다.
실패 추적에 필요한 핵심 데이터
- 타임스탬프
- 상관 관계 ID
- 페이로드 버전
- 처리 단계
- 재시도 이력
- 부수 효과
- 컨텍스트 전파
OpenTelemetry는 컨텍스트 전파를 분산 경계에서 트레이스, 메트릭, 로그와 같은 신호를 연관시키는 메커니즘이라고 설명한다. 시스템이 컨텍스트를 전달하지 못하면 디버깅이 훨씬 어려워진다.
“내 머신에서는 동작한다”가 충분하지 않은 이유
로컬 환경에서는 보통 다음과 같은 요소가 없다:
- 비동기 재시도
- 미들웨어 변환
- 환경별 인증 정보
- 하위 시스템 검증 규칙
- 시스템 간 레이스 컨디션
- 오래된 참조 데이터
- 예상과 다른 결정을 내리는 워크플로 엔진
실패가 프로덕션에 도달할 때는 코딩 문제라기보다 가시성, 시스템 사고, 혹은 핸드오프 문제인 경우가 많다.
요약
시니어 엔지니어링은 단순히 시스템을 구축하는 것이 아니다. 시스템이 어떻게 실패하는지를 설명하는 것이다.
경계 너머의 실패를 추적할 수 있는 엔지니어는 가장 어려운 인시던트에 찾아가는 사람이 된다—그 이유는 가장 멋진 코드를 작성했기 때문이 아니라, 시스템 경계를 넘어 진실을 따라갈 줄 알기 때문이다.