JSON과 CSV 중 무엇을 보낼까? 자료형과 중첩 구조를 지키는 선택

받는 쪽의 열 정의부터 확인하세요

JSON과 CSV 중 어느 쪽이 더 좋은지는 데이터를 받은 사람이 무엇을 해야 하는지에 달려 있습니다. 같은 항목이 반복되는 표를 열어 필터링하거나 검토하려면 CSV가 다루기 쉽습니다. API에 다시 넣을 숫자·불리언·중첩 객체를 보존해야 한다면 JSON이 더 적합할 수 있습니다. 단, 받는 프로그램이 어떤 형식을 허용하는지가 먼저입니다.

JSON 명세 RFC 8259는 문자열, 숫자, 불리언, null, 객체, 배열을 구분합니다. CSV 형식을 설명하는 RFC 4180은 레코드와 필드를 구분하는 규칙을 다룹니다. 일반적인 CSV 파일 하나만으로 각 열의 업무상 자료형과 빈 값의 뜻까지 전달되는 것은 아닙니다.

전달하려는 내용	선택의 출발점	함께 정할 규칙
같은 열로 구성한 목록	CSV	열 이름·순서·구분자·인코딩
자료형이 중요한 API 데이터	JSON	필수 키·허용 값·숫자 범위
주문 안에 여러 상품이 있는 구조	JSON 또는 관계를 나눈 여러 표	주문과 상품을 연결할 식별자
사람에게 보여줄 보고서 표	문서나 표 형식	표시 단위·반올림·각주

예를 들어 고객번호 0007은 계산할 수량이 아니라 식별자입니다. 주문 수량 2는 계산에 사용할 숫자이고, 발송 여부 false는 거짓이라는 값입니다. 세 항목이 화면에서 글자처럼 보인다는 이유로 같은 방식으로 처리하면 받는 쪽에서 뜻이 달라질 수 있습니다.

실제 왕복 변환에서 달라지는 것

다음은 설명을 위해 만든 세 행입니다. Tooliv가 사용하는 변환 함수에 이 JSON을 넣고, 나온 CSV를 다시 JSON으로 변환해 결과를 확인했습니다. Excel에서 열었다가 저장한 실험은 아닙니다.

[
  {"id":"0007","qty":2,"active":false,"note":null,"delivery":{"method":"택배"}},
  {"id":"0008","qty":0,"active":true,"delivery":null},
  {"id":"0009","qty":1,"active":false,"note":"","delivery":{"method":"방문"}}
]

CSV로 바꾸면 아래와 같습니다. delivery의 객체는 별도 열로 나뉘지 않고 한 셀 안의 JSON 문자열로 들어갑니다. 셀 안의 큰따옴표를 두 번 쓰는 것은 CSV의 인용 규칙입니다.

id,qty,active,note,delivery
0007,2,false,"","{""method"":""택배""}"
0008,0,true,"",""
0009,1,false,"","{""method"":""방문""}"

이 CSV를 다시 JSON으로 읽은 첫 행은 다음과 같습니다.

{
  "id": "0007",
  "qty": "2",
  "active": "false",
  "note": "",
  "delivery": "{\"method\":\"택배\"}"
}

확인 항목	원본	CSV를 거친 결과
식별자	문자열 "0007"	문자열 "0007" 유지
수량	숫자 2	문자열 "2"
발송 여부	불리언 false	문자열 "false"
배송 정보	객체	JSON 모양을 가진 문자열
메모 세 행	null / 키 없음 / 빈 문자열	모두 빈 문자열

행은 세 개, 열은 다섯 개로 남지만 자료형과 일부 구분은 바뀝니다. 따라서 행·열 수만 검사해서 “원본이 보존됐다”고 판정할 수 없습니다. 특히 문자열 "false"는 불리언 false와 다릅니다. 받는 코드에서 원래 자료형을 요구한다면 명시적인 변환과 검사가 필요합니다.

빈 칸에 서로 다른 뜻을 넣지 마세요

앞의 예시에서 note: null, note 키 없음, note: ""는 원본 JSON에서 구별됩니다. 하지만 현재 Tooliv의 JSON→CSV는 세 경우를 모두 빈 셀로 만들고, CSV→JSON은 그 셀을 빈 문자열로 읽습니다. 어느 상태였는지 되돌릴 단서가 없습니다.

업무에서 차이가 중요하다면 보내기 전에 표현 규칙을 정해야 합니다. 예를 들어 “미확인”, “해당 없음”, “내용 없음”을 구분해야 하는 목록이라면 note_status 같은 별도 상태 열을 두는 방법을 생각할 수 있습니다. 이 이름과 상태 값은 예시이며 특정 시스템의 표준이 아닙니다. 받는 쪽과 합의한 값만 사용하세요.

빈 셀에 임의로 NULL이라는 글자를 적는 것도 사전 합의가 없으면 해결책이 아닙니다. 어떤 프로그램은 이를 일반 문자열로 읽고 다른 프로그램은 결측값으로 해석할 수 있습니다. 숫자의 0도 빈 값과 같지 않습니다. 표본에 “수량이 실제로 0인 행”을 넣어 결측 처리 과정에서 사라지지 않는지 확인하는 편이 좋습니다.

중첩 구조는 먼저 한 행의 의미를 정하세요

Tooliv는 중첩 객체와 배열을 customer.name 같은 열로 자동 분리하지 않습니다. 한 셀에 JSON 문자열로 담긴 값은 저장할 수 있지만 스프레드시트에서 바로 필터링할 열로 바뀐 것은 아닙니다. delivery.method만 필요하다면 변환 전 객체를 delivery_method 같은 단순 필드로 정리할 수 있습니다.

배열은 더 신중하게 다뤄야 합니다. 주문 한 건에 상품 세 개가 들어 있다면 한 행을 “주문”으로 볼지 “주문 상품”으로 볼지에 따라 표가 달라집니다. 아래는 형식을 정하기 위한 가상 설계입니다.

표	한 행의 의미	연결 기준
주문 표	주문 한 건	order_id
주문 상품 표	그 주문에 포함된 상품 한 줄	order_id와 상품 행 번호

주문 합계가 30,000원인 주문을 상품 세 행으로 펼치면서 각 행에 합계 30,000원을 그대로 적으면, 그 열을 더할 때 90,000원이 됩니다. 계산이 틀린 것이 아니라 행의 의미와 합계의 범위를 다르게 해석한 것입니다. 주문 합계를 어느 표에 둘지, 상품별 금액을 따로 계산할지 먼저 정하세요. 단순 변환 도구가 이런 업무 규칙을 알아서 선택하지는 않습니다.

앞자리 0은 받는 프로그램에서도 확인하세요

Tooliv의 CSV→JSON은 모든 셀을 문자열로 읽으므로 이 예시의 0007을 유지합니다. 그러나 CSV를 다른 프로그램이 열 때 같은 결과를 보장하지는 않습니다. Microsoft의 안내는 Excel이 숫자로 해석하면서 앞자리 0을 없애거나 큰 숫자를 바꿀 수 있다고 설명합니다. 식별자 열은 가져오기 과정에서 텍스트로 지정하고, 실제 셀 값을 원본과 비교하세요.

이미 0007이 숫자 7로 바뀐 뒤 표시 형식만 바꾸면 원래 코드 길이를 알 수 없는 경우가 있습니다. 긴 식별자를 JSON 숫자로 넣는 일도 피해야 합니다. 현재 Tooliv는 안전하게 표현할 수 없는 정수 입력을 거부하므로 식별자는 처음부터 문자열로 전달하세요. 숫자처럼 보인다는 사실보다 계산 대상인지가 더 중요한 기준입니다.

전달 전 작은 표본으로 계약을 확인하세요

실제 파일을 보내기 전에 앞자리 0, 수량 0, 거짓 값, 빈 값, 중첩 값이 있는 몇 행을 골라 JSON↔CSV 변환기에서 확인하세요. 변환 후에는 실제로 받을 프로그램으로 가져와 자료형과 의미를 점검합니다. 가능하다면 다시 내보낸 결과도 비교하되, 원본 파일은 별도로 남겨 두세요.

열 설명에는 이름, 의미, 단위, 자료형, 빈 값 처리 방식을 적으면 전달 과정의 추측을 줄일 수 있습니다. 한글이 깨지거나 쉼표 뒤에서 열이 갈라진다면 CSV 인코딩·따옴표 문제 해결을 확인하세요. 문서 본문과 표 데이터를 함께 옮기는 작업이라면 문서·데이터 변환의 검수 순서에서 최종 결과를 확인할 기준을 정할 수 있습니다.