같은 JSON이라도 개발 시에는 Code Review가 쉬운 2칸 들여쓰기, 배포 시에는 대역폭을 아끼는 minify——포맷팅 전략을 잘못 고르면 diff가 읽기 어렵거나 응답 본문이 불필요하게 커집니다.
이 글은 프론트엔드, 백엔드, 테스트 엔지니어를 대상으로 JSON 포맷팅의 목적, 개발/프로덕션별 전략, 5단계 권장 워크플로, 검증·키 정렬·JSON5 등 흔한 오해를 설명합니다. 읽은 후 JSON Toolbox로 브라우저에서 로컬로 포맷팅과 압축을 할 수 있습니다——데이터는 업로드되지 않습니다.
포맷팅 전략이 중요한 이유
포맷팅은 '표현 방식'만 바꾸며 데이터 의미는 변하지 않습니다. 하지만 표현 방식은 Git diff 가독성, 로그 grep, HTTP 응답 크기와 Time-to-First-Byte에 직접 영향을 줍니다.
minify JSON을 저장소에 커밋해 PR을 리뷰할 수 없게 되는 팀도 있고, 프로덕션 API가 500KB 미압축 예쁜 JSON을 반환해 모바일 약한 네트워크를 느리게 하는 사례도 있습니다. 시나리오별로 나눠 처리하는 것이 기본입니다.
JSON 포맷팅이란
JSON 포맷팅(Pretty Print)은 데이터를 바꾸지 않고 들여쓰기와 줄바꿈을 넣어 구조 계층을 한눈에 보이게 합니다. 압축(Minify)은 불필요한 공백을 모두 제거해 한 줄 또는 최단 표현을 만듭니다.
포맷팅 vs 압축
| 작업 | 공백 / 줄바꿈 | 전형적 용도 |
|---|---|---|
| 포맷팅 | 유지 및 정규화 | 개발, 디버깅, 문서 샘플 |
| 압축 | 제거 | 프로덕션 API, 메시지 큐, 로그 아카이브 |
| 검증 | 구조는 변경하지 않고 구문만 확인 | 포맷팅 전 필수 |
개발 환경 vs 프로덕션
| 차원 | 개발 / 테스트 | 프로덕션 / 전송 |
|---|---|---|
| 들여쓰기 | 2 또는 4칸, 팀 통일 | 압축, 들여쓰기 없음 |
| 키 정렬 | 선택, diff용 | 보통 정렬하지 않음, 의미적 순서 유지 |
| 파일 구성 | 큰 JSON은 모듈별 분할 | 단일 payload는 작게 |
| 저장소 커밋 | 포맷 후 커밋 | minify 산출물은 커밋하지 않음(빌드 단계 제외) |
포맷 규범을 신경 써야 하는 사람
| 역할 | 관심사 | 권장 |
|---|---|---|
| 프론트엔드 | mock 데이터, API 연동 샘플 | 2칸, Prettier와 일치 |
| 백엔드 | API 문서 예시, 로그 출력 | 문서는 예쁘게, API 응답은 압축 |
| 테스트 | fixture, 기대 JSON | 포맷 + 키 정렬, 안정적 diff |
| DevOps | 설정 JSON, 내보내기 데이터 | 저장소 내 가독, 배포 전 필요 시 압축 |
권장 워크플로: 5단계
- 원본 JSON 붙여넣기 또는 가져오기(로그, API 복사 등)
- 구문 검증: 후행 쉼표, 작은따옴표, 주석 등 불법 내용 제외
- 들여쓰기 선택: 2칸(프론트엔드 일반) 또는 4칸(일부 백엔드 규범)
- 선택적 키 정렬: 구조가 같은 두 JSON 비교 용이
- 결과를 에디터에 복사하거나 프로덕션 샘플용 압축 모드로 전환
예: 포맷팅 전후
압축 한 줄:
{"user":{"id":1,"name":"Alice"},"tags":["dev","json"]}포맷 후(2칸):
{
"user": {
"id": 1,
"name": "Alice"
},
"tags": ["dev", "json"]
}흔한 실수와 모범 사례
검증 없이 포맷팅
구문 오류가 있는 텍스트는 올바르게 포맷되지 않습니다. 권장 흐름: 붙여넣기 → 검증 → 포맷 → 복사.
JSON5 구문 혼용
이 도구는 표준 JSON만 지원: 따옴표 없는 키, 후행 쉼표, 주석 불가. JS 객체에서 복사했다면 먼저 유효한 JSON으로 변환하세요.
대용량 파일 처리
2MB를 넘는 JSON은 브라우저 포맷팅이 느려질 수 있습니다. CLI(jq) 또는 서브트리 분할을 권장합니다.
포맷팅과 다른 도구 연동
| 다음 단계 | 도구 | 목적 |
|---|---|---|
| 변경 비교 | JSON Diff | 필드 추가·삭제·수정 확인 |
| 필드 추출 | JSONPath | 경로와 값 확인 |
| 다른 형식 변환 | JSON → YAML 등 | 운영·설정 시스템용 |
| 구조 제약 | JSON Schema(외부) | 릴리스 전 계약 검증 |
자주 묻는 질문 (FAQ)
포맷팅이 데이터 내용을 바꾸나요?
아니요. 공백과 줄바꿈만 바뀌며, 파싱 후 객체는 압축 전과 의미적으로 동일합니다.
2칸과 4칸 들여쓰기 중 무엇을 선택하나요?
절대적 기준은 없습니다. 프론트엔드는 Prettier 기본 2칸이 많고, Java 등 백엔드는 4칸이 흔합니다. 팀 내에서 통일하세요.
키 정렬은 무엇에 유용한가요?
내용은 같지만 키 순서가 다른 두 JSON을 비교할 때 정렬 후 diff가 더 명확합니다. 순서가 중요한 업무 배열은 변경하지 마세요.
압축된 JSON을 다시 읽기 쉬운 형식으로 복원할 수 있나요?
예. minify 결과에 다시 포맷팅을 실행하면 되며 데이터는 손실되지 않습니다.
데이터가 서버에 업로드되나요?
아니요. JSON Toolbox는 순수 프론트엔드 처리로 내부 필드가 포함된 샘플 붙여넣기에도 적합합니다(민감 정보는 여전히 마스킹 권장).
포맷팅이 구문 오류로 실패하는 이유는?
흔한 원인: 후행 쉼표, 작은따옴표 문자열, 이스케이프되지 않은 줄바꿈, JSON이 지원하지 않는 주석. 먼저 검증 도구로 행 번호를 확인하세요.
정리 및 다음 단계
포맷팅은 협업 효율을 높이는 저비용 수단입니다: 개발은 가독, 프로덕션은 간결, 작업 전 반드시 검증. '검증 → 포맷 → 사용'을 팀 습관으로 만들면 저장소나 프로덕션의 단순 JSON 오류를 줄일 수 있습니다.
에디터에 저장 시 포맷을 설정하고, CI에서 핵심 fixture JSON 구문 검사를 하며, 메이저 릴리스 전 Diff 도구로 API 샘플 변경을 검토하는 것을 권장합니다.