CSV ↔ JSON 변환기

CSV와 JSON을 양방향으로 변환합니다. RFC 4180을 따르므로 따옴표나 줄바꿈이 들어간 필드도 처리하며, 구분자와 헤더 옵션도 조절할 수 있습니다.

Loading…

모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.

사용법

방향(CSV → JSON 또는 JSON → CSV)을 고르고 왼쪽에 데이터를 붙여 넣으면 오른쪽에 변환 결과가 표시됩니다. 구분자 선택지는 콤마·탭·세미콜론·파이프입니다. 세미콜론은 유럽 Excel 익스포트, 탭은 스프레드시트 복사·붙여 넣기, 파이프는 옛 메인프레임 덤프에서 쓰입니다. Has-header 체크박스는 첫 줄이 컬럼명인지 파서에 알려 줍니다. 헤더 없는 데이터에서는 끄세요. CSV → JSON에는 추가로 "As objects" 토글이 있습니다. 켜면 `[{"col": "val"}]`을, 끄면 `[["val", ...]]`(원시 행 매트릭스)을 출력합니다.

선호 포맷이 다른 도구 사이에서 데이터를 옮길 때 사용하세요. DB 쿼리 결과를 CSV로 내보냈는데 API 호출에 JSON이 필요하거나, 공유받은 스프레드시트를 스크립트에 넣어야 하거나, JSON 로그 덤프를 Excel용으로 다듬어야 할 때입니다. 파서는 RFC 4180을 충실히 구현하므로 따옴표 필드에 콤마, 이중 따옴표 이스케이프, 심지어 줄바꿈까지 포함될 수 있습니다. 처리는 모두 브라우저 안에서 끝나므로 고객 리스트나 사내 데이터도 기기 밖으로 나가지 않습니다.

예제

따옴표 안에 콤마가 있는 CSV → JSON

입력
name,age,city
Alice,30,Seoul
Bob,25,"Tokyo, Shibuya"
Carol,35,New York
출력
[
  { "name": "Alice", "age": "30", "city": "Seoul" },
  { "name": "Bob", "age": "25", "city": "Tokyo, Shibuya" },
  { "name": "Carol", "age": "35", "city": "New York" }
]

`"Tokyo, Shibuya"` 안의 콤마는 따옴표 필드라서 보존됩니다. `age`가 `"30"`(문자열)으로 들어가는 점에 주의하세요. CSV에는 타입 시스템이 없어 JSON 출력에서도 모든 셀이 문자열입니다. 숫자가 필요하다면 각 셀을 `JSON.parse`로 후처리하거나, 결과를 타입화 단계에 통과시키세요.

객체 배열 JSON → CSV(키 합집합)

입력
[
  {"name":"Alice","age":30,"city":"Seoul"},
  {"name":"Bob","age":25,"country":"JP"},
  {"name":"Carol","city":"NYC","country":"US"}
]
출력
name,age,city,country
Alice,30,Seoul,
Bob,25,,JP
Carol,,NYC,US

헤더는 모든 행에서 본 키의 합집합으로, 처음 등장한 순서대로 나열됩니다. 1행에서 `name`·`age`·`city`, 2행에서 `country`가 처음 보이면 그때 끝에 추가되는 식입니다. 값이 빠진 셀은 빈 칸이 됩니다. 행마다 모양이 다른 JSON(흔한 API 익스포트 패턴)에서 중요한 동작입니다.

줄바꿈을 포함한 셀(RFC 4180)

입력
id,note
1,"Line one
Line two"
2,"Single line"
출력
[
  { "id": "1", "note": "Line one\nLine two" },
  { "id": "2", "note": "Single line" }
]

큰따옴표 안의 줄바꿈은 셀의 일부이지 행 구분자가 아닙니다 — RFC 4180 §2.6에 정의되어 있습니다. 대부분의 스프레드시트는 셀에 다중 줄 텍스트가 들어 있을 때 이 형식으로 출력합니다. 손으로 짠 CSV 파서는 모든 `\n`을 행 구분으로 보고 데이터를 조용히 망가뜨리기 쉽지만, 이 도구의 RFC 4180 파서는 구조를 그대로 유지합니다.

자주 묻는 질문

CSV의 숫자가 JSON에서 문자열로 나오는 이유는?

CSV는 타입이 없습니다. 각 셀은 구분자 사이의 바이트열이며 숫자·불리언·null 구분이 없습니다. 파싱 단계의 자동 타입화는 휴리스틱이 정당한 문자열을 잘못 분류하기 쉬워 위험합니다. `"01234"`는 미국 우편번호로, 숫자로 다루면 앞의 0이 사라집니다. `"NaN"`은 국가 약어인데 특수 값이 됩니다. `"007"`은 사용자명인데 숫자 7이 됩니다. 본 변환기는 조용한 손상을 피하기 위해 모두 문자열로 유지합니다. 소비 측 코드에서 명시적으로 캐스팅하세요.

왜 Excel은 UTF-8 CSV를 망가뜨리나요?

Windows판 Excel은 CSV를 시스템 코드페이지(보통 Windows-1252나 Shift_JIS)로 읽습니다. BOM(`EF BB BF`)으로 시작하지 않는 UTF-8 파일은 한국어·일본어 텍스트가 모자이크처럼 깨집니다. 우회 방법은 3가지입니다. BOM과 함께 저장하기, Data → From Text / CSV로 열어 인코딩을 지정하기, 파일명을 `.txt`로 바꿔 가져오기 마법사를 통하게 하기입니다. Mac판 Excel은 2016년 이후 UTF-8을 직접 다룹니다. 본 변환기는 기본적으로 BOM 없는 UTF-8을 출력합니다. Excel이 소비 측이라면 복사 후 BOM을 앞에 덧붙이세요.

제 CSV에 콤마가 아닌 세미콜론이 쓰이는 이유는?

유럽 로케일(독일어·프랑스어·이탈리아어·스페인어 등)은 소수점에 콤마를 쓰므로 스프레드시트는 `1,5` 같은 숫자와의 충돌을 피하려고 세미콜론을 구분자로 씁니다. 구분자를 `;`로 바꾸면 동일하게 처리됩니다. 탭도 흔합니다. Excel이나 Google Sheets에서 복사·붙여 넣기를 하면 메뉴가 "CSV"라 해도 탭 구분 데이터가 되는 경우가 많습니다. Excel의 CSV 익스포트는 지역 설정의 "목록 구분 기호"를 따릅니다.

JSON → CSV에서 중첩 객체는 어떻게 되나요?

CSV는 평면 구조이며 모든 셀은 문자열입니다. 중첩된 객체나 배열은 셀 안에서 JSON으로 직렬화됩니다. 예를 들어 `{"a": 1}`은 해당 열에 `{"a":1}`이라는 리터럴 텍스트로 들어갑니다. 왕복은 되지만 스프레드시트 사용자가 기대하는 모양은 아닙니다. 중첩 데이터를 실제 열로 펼쳐야 한다면 `jq 'paths(scalars)'`나 `flat` 같은 라이브러리로 JSON을 먼저 평탄화(예: `address.city`를 `address_city` 열로)하세요.

CSV → JSON에서 행을 객체 대신 배열로 받을 수 있나요?

예. "As objects" 체크박스를 끄세요. 출력은 `[[ "Alice", "30", "Seoul" ], ...]`이라는 문자열 매트릭스가 되어 원래 컬럼 순서를 유지하고 헤더명을 필요로 하지 않습니다. 하류 코드가 키가 아닌 위치(`row[0]`·`row[1]`)로 처리하거나, 헤더 행이 전혀 없는 CSV에 적합합니다.

행 수 제한이 있나요?

엄격한 상한은 없지만 파싱은 브라우저 안에서 동기적으로 일어납니다. 수십만 행을 넘는 파일은 변환 중에 페이지가 잠시 멈춥니다. 그보다 큰 데이터셋에는 `xsv`·`miller` 같은 CLI 도구나 `pandas.read_csv` 스크립트를 쓰세요. 그들은 스트리밍 처리와 적절한 메모리 레이아웃을 제공합니다. 100만 행 CSV는 브라우저 전용 도구의 설계 범위를 완전히 벗어납니다.

관련 개념

CSV(Comma-Separated Values)는 지금도 활발히 쓰이는 가장 오래된 데이터 포맷 중 하나로, 1970년대에 비공식 표준화가 시작되어 2005년에 RFC 4180으로 공식화되었습니다. 명세는 짧습니다. 행은 줄바꿈으로 구분, 필드는 콤마로 구분, 필드 내부의 콤마·줄바꿈·따옴표는 큰따옴표로 감싸고 내부의 `"`는 `""`로 이스케이프합니다. 이름에 "Comma"가 들어 있어도 실환경 CSV 파일은 생성 측 로케일이 자연스럽다고 여기는 구분자를 사용합니다. 유럽의 다수는 세미콜론, 스프레드시트 복사·붙여 넣기는 탭, 옛 메인프레임 출력은 파이프 같은 식이라 상호 운용을 깨뜨리는 세부 동작이 수두룩합니다.

의미론에서 가장 큰 차이는 **타입**입니다. CSV에는 숫자·불리언·null 개념이 없으며 모든 셀이 바이트입니다. 같은 `0123`이 문자열 코드일 수도, 정수의 일부일 수도 있습니다. `true`가 문자열일 수도, 불리언일 수도 있습니다. 소비 측마다 추측이 다릅니다. Excel은 적극적으로 자동 타입화하며 조용히 데이터를 망가뜨리고, Python `pandas`는 컬럼별로 dtype을 추정하며, 이 변환기는 모두 문자열로 유지합니다. JSON은 반대 성질이라 모든 값이 명시 타입을 가집니다. JSON → CSV에서는 타입 정보가 버려지고, CSV → JSON에서는 추측하거나 타입화 문제를 소비 측에 넘기는 선택이 됩니다.

인접한 3 포맷이 스펙트럼의 서로 다른 자리를 차지합니다. **TSV(Tab-Separated Values)**는 구분자가 고정된 CSV로 스프레드시트 복사·붙여 넣기의 사실상 표준입니다. 실제 텍스트에 탭이 드물기 때문에 따옴표 문제가 적습니다. **JSON Lines(NDJSON)**는 한 줄에 하나의 JSON 객체를 쓰는 형식으로, JSON의 타입화와 CSV의 스트리밍 가능한 행 지향 구조를 결합합니다. 로그 전송, 기계학습 데이터셋, `jq -c` 출력에서 인기입니다. **Parquet**는 진짜 대규모(수백만 행 이상) 용도의 컬럼 지향 바이너리 포맷으로, 타입을 유지하고 스키마 진화를 지원하며 저장 공간과 읽기 속도에서 CSV를 10배 이상 앞섭니다. CSV가 지금도 살아남는 이유는 보편적 호환성 때문이지 포맷 자체의 우위 때문이 아닙니다.

관련 글

관련 도구