JSONL 포맷터

여기에 JSONL 또는 NDJSON을 붙여넣으세요. 빈 줄은 자동으로 무시되며, 각 데이터 줄은 하나의 완전한 JSON 객체여야 합니다.

포맷 결과가 여기에 표시됩니다.

빈 줄이 아닌 각 줄은 완전한 JSON 객체여야 합니다.

전체 줄 수: 1비어 있지 않은 줄: 0유효한 줄: 0잘못된 줄: 0

JSONL을 붙여넣으면 바로 포맷이 시작됩니다.

로그, 세션 아카이브, 스트리밍 내보내기를 위한 가벼운 JSONL 정렬 페이지입니다. 왼쪽에 줄바꿈으로 구분된 JSON 객체를 붙여넣으면 오른쪽에 각 레코드의 정렬 결과가 즉시 표시되고, 어느 줄이 깨졌는지 바로 보입니다.

JSONL 정렬이란 무엇인가요?

JSONL(JSON Lines)은 JSON 레코드를 줄 단위로 구성하는 텍스트 형식입니다. 핵심은 'JSON처럼 보이는 것'이 아니라 '각 레코드가 한 줄을 차지하는 것'입니다. 실무에서는 이것이 거의 항상 '비어 있지 않은 각 줄이 완전한 JSON 객체'로 나타나며, 객체는 줄바꿈으로 구분되고 바깥을 `[{...},{...}]` 같은 큰 배열로 추가로 감싸지 않습니다.

이 구성은 로그, 이벤트 스트림, 세션 아카이브, 대량 내보내기, 스트림 처리에 특히 알맞습니다. 프로그램이 파일 전체를 메모리에 올리지 않고 줄을 읽으며 레코드를 하나씩 소비할 수 있기 때문입니다. 한 줄이 깨져도 해당 줄 번호로 바로 갈 수 있어, 아주 긴 JSON 배열 안에서 막연히 괄호를 세고 쉼표를 찾을 필요가 없습니다.

JSONL 정렬은 일반 JSON 정렬과 다릅니다. 일반 포맷터는 입력이 하나의 완전한 JSON 문서라고 가정하지만, JSONL 포맷터는 줄별로 파싱하고 줄별로 검증하고 줄별로 오류를 내면서 줄바꿈 구분 레코드 의미를 유지해야 합니다. 로그와 내보내기 파일에서 이 차이는 매우 중요합니다.

이 페이지는 바로 그 실제 의미를 중심으로 설계됐습니다. 왼쪽에 줄바꿈으로 구분된 객체 레코드를 입력하면 오른쪽에 레코드별 정렬 결과가 표시되고, 깨진 줄·잘린 줄·객체가 아닌 줄이 바로 지적됩니다. 그래서 `.jsonl` 파일을 점검할 때 막연한 `SyntaxError`가 아니라 '어느 레코드에 문제가 있는지' 보게 됩니다.

사용 사례

앱 로그에서 내보낸 JSONL을 레코드별로 정렬한 뒤 필드를 하나씩 점검. 한 줄로 뭉개진 긴 객체 나열을 오래 쳐다볼 필요가 없습니다
한 줄이 하나의 이벤트 객체인 세션 아카이브 파일을 검사해 모든 레코드가 온전하고 읽히는지 확인
데이터 파이프라인, 트래킹 플랫폼, Elasticsearch bulk 내보내기가 실패할 때 어느 줄의 JSON 객체가 잘못됐는지 빠르게 찾기
스트리밍 인터페이스를 디버깅할 때 서버가 정말 '한 줄에 하나의 객체'로 계속 내보내는지, 절반짜리 객체를 먼저 흘리지는 않는지 확인
터미널, 모니터링 대시보드, 클라우드 로그 플랫폼에서 복사한 NDJSON을 붙여넣고 먼저 구조를 정리한 뒤 조사 계속하기
AI가 생성한 줄별 객체 결과 어딘가에 배열, 문자열, 불완전한 JSON이 섞이지 않았는지 확인
ClickHouse, BigQuery, Kafka Connect처럼 줄 단위 레코드에 의존하는 흐름으로 가져오기 전에 JSONL 내용을 사람이 먼저 재확인
감사 로그, 리스크 이벤트, 트래킹 이벤트 스트림을 검토할 때 객체 구조가 안정적이고 일관되는지 레코드별로 확인
JSONL 파일이 잘렸거나 다운로드가 불완전할 때 마지막 어느 객체가 닫히지 않았는지 즉시 확인
내부 도구가 내보낸 줄 구분 JSON을 먼저 정렬한 뒤 코드 리뷰나 데이터 대조용으로 동료에게 전달
JSONL을 파싱하는 스크립트를 쓰기 전에 필드 계층, 중첩 객체, 배열 위치를 사람이 먼저 확인해 스크립트 디버깅 시간 단축
빈 줄과 깨진 줄이 뒤섞인 과거 내보내기 파일을 다룰 때 먼저 구조 문제를 걸러낸 뒤 CSV 변환이나 DB 임포트 여부 결정

이용 방법

JSONL 또는 NDJSON 내용을 입력 영역에 붙여넣고, 비어 있지 않은 각 줄이 독립된 JSON 객체인지 확인합니다
오른쪽에 줄별 정렬 결과가 즉시 표시되고, 깨진 줄에는 줄 번호, 오류 메시지, 원본 레코드가 나타납니다
안내에 따라 해당 줄을 고쳐 무효 줄 수가 0이 될 때까지 반복합니다
모두 유효해지면 정렬된 전체 결과를 복사하거나, 데이터를 다운스트림 스크립트·임포터·분석 흐름으로 넘깁니다

주요 기능

JSONL / NDJSON을 줄별로 파싱. `[{...},{...}]` 같은 완전한 JSON 배열로 미리 손으로 감쌀 필요가 없습니다
'비어 있지 않은 모든 줄은 하나의 JSON 객체'라는 실제 파일 의미에 따라 검증해 로그, 이벤트 스트림, 세션 아카이브 등 흔한 데이터 형태에 잘 맞습니다
좌우 분할 레이아웃: 왼쪽 `textarea`에 입력하고 오른쪽에 정렬 결과를 즉시 표시해 고치면서 보기 적합합니다
깨진 줄에 정확한 줄 번호, 파싱 오류, 원본 내용을 바로 표시해 잘린 레코드, 빠진 괄호, 이어붙이기 오류를 빠르게 고칠 수 있습니다
비어 있지 않은 모든 줄이 유효할 때만 복사를 허용해 일부만 성공한 깨진 데이터를 다운스트림으로 넘기지 않습니다
전체 줄, 비어 있지 않은 줄, 유효 줄, 무효 줄 수를 내장 집계해 큰 파일에서 몇 건이 깨졌는지 빠르게 판단합니다
예시 데이터를 내장해 처음 여는 순간부터 JSONL 정렬 효과를 바로 써볼 수 있습니다
모든 처리는 브라우저 로컬에서 완료. 로그, 세션 이벤트, API 내보내기 내용은 업로드되지 않습니다

JSONL 포맷터 vs JSON 포맷터 vs JSON 복구

이 도구들은 이어서 쓰는 경우가 많지만 푸는 문제는 다릅니다. 맞는 입구를 고르면 훨씬 빠릅니다.

도구	가장 적합한 입력	핵심 기능	사용 상황
JSONL 포맷터	한 줄에 하나의 JSON 객체	레코드별 검증 및 정렬	로그, NDJSON, 세션 아카이브, 스트리밍 내보내기
JSON 포맷터	완전한 하나의 JSON 객체 또는 배열	JSON 문서 전체 정렬	API 응답, 설정 파일, 단발성 payload
JSON 복구	문법 오류나 비표준 JSON 텍스트	먼저 문법을 고친 뒤 후속 도구로	마지막 쉼표, 주석, 따옴표 문제, 잘린 JSON

Best Practices

디버깅할 때는 원래 JSONL 형태를 유지하고, 이해하려고 손으로 배열로 감싸지 마세요

다운스트림 시스템이 JSONL을 받는다면 원래 '한 줄에 하나의 레코드' 형태로 점검하세요. 배열로 감싸면 일반 포맷터에 넣을 수는 있지만 원래 줄 번호 의미가 사라지고 실제 깨진 줄 위치와 대응하기 어려워집니다.

큰 파일은 마지막 몇 줄부터 보세요

JSONL 파일은 중간 구조가 틀린 게 아니라 스트림 중단, 다운로드 실패, 쓰기 미완료로 마지막 몇 줄이 잘린 경우가 많습니다. 먼저 끝쪽 레코드 몇 건을 보는 편이 처음부터 전체를 넘기는 것보다 대개 빠릅니다.

입력에 홑따옴표·주석·JSON5 스타일이 있으면 먼저 JSON 복구를 거치는 게 빠릅니다

JSONL 페이지는 줄별 객체 검증에 집중합니다. 원본 데이터가 애초에 표준 JSON이 아니라면 긴 파일의 각 줄을 손으로 고치기보다 먼저 복구하고 정렬하는 편이 효율적입니다.

다시 가져올 때는 '한 줄에 하나의 객체' 전송 의미를 반드시 유지하세요

오른쪽의 여러 줄 정렬 블록은 사람이 보기 좋지만, 데이터를 로그 시스템, 메시지 큐, 임포터로 다시 쓸 거라면 미리보기 형태를 최종 전송 형식으로 쓰지 말고 원본 한 줄-한 객체 구조를 유지하세요.

전체 파일을 눈으로 읽지 말고 줄 번호를 주요 단서로 삼으세요

실제 점검에서 가장 빠른 길은 보통 깨진 줄 번호를 먼저 잡고 그 레코드를 이웃한 유효 레코드와 비교하는 것입니다. 괄호·따옴표 누락인지, 필드가 잘렸는지, 객체에 잘못된 타입이 섞였는지 더 빠르게 드러납니다.

자주 묻는 질문

JSON과 JSONL의 차이는 무엇인가요?

일반 JSON은 보통 하나의 객체 또는 배열 전체로, 하나의 완전한 문서로 통째로 파싱해야 합니다. 반면 JSONL(JSON Lines, NDJSON이라고도 함)은 한 줄에 하나의 독립 레코드를 두며, 실무에서는 '한 줄에 하나의 JSON 객체'가 가장 흔합니다. 줄 단위로 읽고 쓰고 오류를 찾을 수 있어 로그, 이벤트 스트림, 스트림 처리, 대량 임포트에 더 적합합니다.

왜 이 페이지는 '한 줄에 하나의 JSON 객체'를 강조하나요?

현실의 JSONL 파일 대부분, 특히 로그, 세션 아카이브, 이벤트 스트림, 내보내기 파일이 그렇게 구성되기 때문입니다. 가지고 계신 아카이브 예시도 전형적인 형태로, 각 줄이 줄바꿈으로 구분된 객체입니다. 임의의 JSON 값을 넓게 받아들이기보다 이 의미로 검증하는 편이 실제 디버깅에 더 맞습니다.

JSONL은 `[{...},{...}]` 같은 JSON 배열과 무엇이 다른가요?

JSON 배열은 하나의 완전한 JSON 문서로 전체를 다 읽은 뒤 파싱해야 합니다. JSONL은 각 객체를 독립된 줄 레코드로 나눠 스트리밍으로 읽을 수 있고, 한 건이 깨져도 해당 줄을 바로 찾기 쉽습니다. 큰 로그 파일과 이벤트 스트림에는 통 배열보다 JSONL이 더 적합합니다.

왜 빈 줄은 무시되나요?

빈 줄은 보통 복사·붙여넣기, 로그 로테이션, 수동 편집에서 비롯되며 실제 데이터 레코드가 아닙니다. 빈 줄을 무시하면 노이즈가 줄고, 내용이 있는 줄은 여전히 엄격히 검사합니다.

어떤 줄이 배열·문자열·`null`이면 어떻게 되나요?

이 페이지는 무효 줄로 판정합니다. 목표 형식이 '비어 있지 않은 모든 줄은 JSON 객체'이기 때문입니다. 데이터에 정말 배열이나 원시 값을 줄별로 저장해야 한다면, 이 페이지가 최적화한 전형적인 JSONL 로그 시나리오가 아니라는 뜻입니다.

깨진 줄이 하나라도 있으면 전체 결과를 바로 복사할 수 없는 이유는?

의도적으로 보수적인 동작입니다. 비어 있지 않은 모든 줄이 유효할 때만 복사를 허용해, 일부만 성공한 깨진 결과를 임포터·스크립트·동료에게 넘겨 두 번째 조사 비용이 드는 것을 막습니다.

잘린 로그 파일도 찾아주나요?

네. JSONL 문제는 마지막 몇 줄에 생기곤 합니다. 예를 들어 객체의 `}`가 없거나 문자열 닫는 따옴표가 빠지거나 네트워크 스트림이 중간에 끊기는 경우입니다. 해당 깨진 줄이 그대로 드러나 불완전한 다운로드와 스트림 출력 중단을 찾는 데 특히 유용합니다.

JSONL과 NDJSON은 같은 것인가요?

대부분의 엔지니어링 맥락에서 동의어로 봐도 됩니다. 둘 다 줄바꿈으로 구분된 JSON 레코드를 뜻하고 이름 짓는 습관만 다릅니다.

JSONL 정렬 시 제 데이터가 업로드되나요?

아니요. 파싱·검증·정렬은 모두 브라우저 로컬에서만 실행되며 로그, API 응답, 세션 아카이브, 데이터 내보내기 내용이 서버로 전송되지 않습니다.

언제 일반 JSON 포맷터 대신 JSONL 포맷터를 써야 하나요?

입력 자체가 완전한 JSON 객체나 배열(API 응답 본문, 설정 파일, `[{...},{...}]` 같은 데이터 묶음)이라면 일반 JSON 정렬 페이지를 쓰세요. 입력이 줄바꿈으로 나뉜 건건의 객체 레코드일 때만 이 JSONL 페이지가 더 적합합니다.

용어집

JSONL: JSON 레코드를 줄바꿈으로 구분하는 텍스트 형식. 가장 흔한 엔지니어링 작성법은 비어 있지 않은 각 줄이 완전한 JSON 객체인 형태입니다.
JSON Lines: JSONL의 전체 이름이자 또 다른 흔한 명칭. 보통 JSONL과 동의어로 봅니다.
NDJSON: Newline Delimited JSON의 약자로, 직역하면 '줄바꿈으로 구분된 JSON'. 대부분 로그와 데이터 파이프라인 환경에서 JSONL과 거의 동등합니다.
줄 단위 레코드: 각 줄이 하나의 완전한 레코드를 나타내는 데이터 배치. 스트리밍 쓰기·읽기와 줄 단위 오류 찾기에 적합합니다.
Pretty Print / 보기 좋게 정렬: 한 줄로 압축된 JSON을 들여쓰기와 줄바꿈이 있는 읽기 쉬운 구조로 재배열해 필드 계층을 사람이 보기 편하게 만드는 것.
깨진 줄: 유효한 JSON이 아니거나, 파싱은 되지만 기대한 구조(예: 객체가 아님)에 맞지 않아 유효한 JSONL 레코드가 될 수 없는 줄.
잘린 스트림: 전송·플러시·저장 도중 로그나 내보내기가 중간에 끊겨 마지막 레코드가 완전히 닫히지 않은 상태.
JSON 배열: 표준 JSON에서 `[`와 `]`로 감싼 하나의 묶음, 예를 들어 `[{...},{...}]`. JSONL과 달리 하나의 통 문서로 파싱해야 합니다.

Authoritative References

jsonlines.orgJSON Lines 공식 설명
IETFJSON 공식 규격 RFC 8259