JSON 복구 실전: 오류 위치에서 신뢰할 수 있는 데이터까지

API 로그, JavaScript에서 복사한 객체, 사람이 직접 편집한 설정 파일은 JSON처럼 보이지만 실제로는 유효한 JSON이 아닐 수 있습니다. 복구의 목표는 파서 오류를 없애는 것만이 아닙니다. 비즈니스 의미를 바꾸지 않으면서 검증 가능하고 재현 가능한 데이터를 만드는 것입니다.

1. 원본 입력을 먼저 보관하기

유일한 사본을 덮어쓰지 마세요. 원본 텍스트, 출처, 시간, 요청 ID를 먼저 저장합니다. 로그에는 토큰, 이메일, 내부 URL이 포함될 수 있으므로 도구에 넣기 전에 필요 없는 민감한 필드를 제거하세요. 원본이 남아 있으면 복구 과정에서 의미가 바뀌었는지 비교할 수 있습니다.

2. 첫 번째 오류부터 수정하기

흔한 손상에는 작은따옴표, 속성 사이의 쉼표 누락, True나 None 같은 비표준 리터럴, 마지막 항목 뒤의 쉼표가 있습니다. 파서는 보통 더 이상 진행할 수 없는 첫 위치를 보고합니다. 따라서 전체 문서를 감으로 한 번에 고치지 말고, 문자열과 키를 큰따옴표로 바꾸고, 누락된 쉼표를 추가하고, boolean과 null을 표준 소문자로 바꾸고, 마지막 쉼표를 제거하는 순서로 진행하세요.

후보를 JSON 복구 도구에 넣고, 결과를 JSON 검증기로 다시 확인할 수 있습니다.

3. 주석을 단순 치환으로 제거하지 않기

//와 블록 주석은 JavaScript 문법이며 표준 JSON이 아닙니다. 하지만 같은 문자가 URL 같은 문자열 안에도 나타날 수 있습니다. 신뢰할 수 있는 복구 과정은 먼저 문자열 경계를 인식한 뒤 실제 주석만 처리해야 합니다. 주석이 업무 설명을 담고 있다면 조용히 삭제하지 말고 문서나 명시적인 필드로 옮기세요.

4. 잘린 데이터는 안전하게 추측할 수 없음

네트워크 중단으로 배열의 일부나 완성되지 않은 필드만 남을 수 있습니다. 도구는 닫는 괄호를 추가할 수 있지만 누락된 ID, 객체, 배열 요소는 알 수 없습니다. 문법상 유효해져도 데이터가 완전하다는 뜻은 아닙니다. 원본을 다시 가져오거나 불완전한 기록으로 표시해야 합니다.

중복 키, 앞자리 0, 매우 큰 정수, 날짜 문자열, NaN, Infinity도 사람이 판단해야 합니다. 파서마다 중복 키 처리 방식이 다를 수 있고, JavaScript 안전 정수를 넘는 식별자는 보통 문자열로 전달하는 것이 좋습니다.

5. 네 단계로 검증하기

먼저 브라우저와 백엔드 런타임 모두에서 파싱되는지 확인합니다. 다음으로 루트 타입, 필수 필드, 값 타입을 확인합니다. 그다음 JSON Diff로 복구 전후를 비교하고 금액, 권한, 상태, ID를 중점적으로 검토합니다. 마지막으로 손상 샘플을 회귀 테스트에 추가합니다.

정리

신뢰할 수 있는 JSON 복구는 원본 보관, 첫 오류 수정, 변경 기록, 재검증, 의미 확인의 순서로 진행됩니다. 자동 도구는 구두점, 따옴표, 주석, 표준 리터럴 문제에 유용하지만 누락 데이터와 계약 규칙에 대한 판단을 대체할 수는 없습니다.