실제 파일은 단 하나도 읽지 못할 뻔한 파서(Parser)를 출시할 뻔한 경험

저는 어떤 프레임워크든 데이터를 공급할 수 있도록 제 도구가 표준 형식(OTLP / OpenInference)의 트레이스(trace) 파일을 수용할 수 있어야 했습니다. 저는 명세(spec)를 읽고 JSON 구조를 머릿속으로 그렸으며, 그 정신적 모델(mental model)을 바탕으로 파서(parser)를 작성하려 했습니다. 그러다 먼저 한 가지 귀찮은 일을 스스로에게 시켰습니다. 바로 실제 출력물을 덤프(dump)하여 비교해 보는 것이었습니다.
다행히 그렇게 하길 잘했습니다. 거의 모든 가정이 틀렸기 때문입니다.

저는 명세(spec)에 따라 대문자 16진수(uppercase-hex) 트레이스 ID(trace IDs), UnixNano 문자열 타임스탬프(timestamps), 그리고 중첩된 resourceSpans 구조를 가질 것이라고 가정했습니다. 하지만 실제 SDK 출력물은 0x 접두사가 붙은 ID, ISO datetime, 그리고 평탄한 배열(flat array) 형태였습니다. 제가 설계의 기준으로 삼았던 "표준 OTLP-JSON"은 실제 어떤 도구도 내보내지 않는, 단지 명세(spec)상의 예시일 뿐이었습니다. 만약 제가 제 정신적 모델(mental model)을 바탕으로 파서(parser)를 작성했다면, 제가 직접 만든 테스트용 피스처(fixtures)는 통과했겠지만 실제 파일에서는 모두 실패했을 것입니다. 일반화(generalization)가 가짜였던 셈입니다.

두 번째 덤프(dump)는 저에게 더 큰 교훈을 주었습니다. 저는 사용자들이 디스크에 트레이스(trace) 파일을 보관하고 있다고 가정했습니다. 하지만 대부분 그렇지 않습니다. OpenInference 자체 예시를 보면 스팬(spans)을 HTTP를 통해 대시보드로 전송합니다. 따라서 "트레이스 파일을 보내달라"는 전제 자체가 잘못되었습니다. 이 작업 전체에서 가장 가치 있는 결과물은 파서(parser)가 아니라, 사용자가 애초에 파일을 생성할 수 있게 해주는 3줄짜리 코드 스니펫(snippet)이었습니다. "파일을 만드는 방법"에 대한 가이드가 없는 파서(parser)는 아무도 사용할 수 없는 도구입니다.

따라서 범위가 조용히 변경되었습니다. 실제 SDK 출력이 사용하는 단 하나의 포맷을 지원하고, 다른 포맷들은 조용히 실패하는 대신