JSON과 CSV 차이: 표와 중첩 데이터에 맞는 형식

파일을 내보낼 때 CSV와 JSON 중 하나를 고르라는 화면을 자주 만납니다. CSV는 엑셀에서 열 수 있고 JSON은 개발자가 쓰는 형식이라고만 이해하면, 내보낸 뒤 주문 항목이 사라지거나 회원번호 앞의 0이 없어지는 이유를 놓칠 수 있습니다. 선택 기준은 누가 파일을 열 것인가와 함께 데이터가 어떤 구조를 갖는가입니다. 이 글은 작은 주문 자료를 설명용으로 만들고, 형식 선택부터 변환 후 점검까지 이어지는 방법을 다룹니다.

1. 표의 한 줄과 중첩 구조의 차이를 먼저 본다

CSV는 행과 필드로 이루어진 표 형태를 표현하기에 알맞습니다. 예를 들어 한 행이 한 회원이고 열이 회원번호, 이름, 가입일이라면 구조가 단순합니다. 반면 주문 하나에 배송지 객체가 있고 상품 항목이 여러 개 들어 있다면 JSON의 객체와 배열로 관계를 표현할 수 있습니다. JSON 객체는 이름과 값의 묶음이며, 배열은 순서가 있는 값의 목록입니다. 배열의 순서와 객체 항목의 표시 순서를 같은 것으로 취급하지 않는 것이 좋습니다.

JSON에는 문자열, 숫자, 참·거짓, null, 객체, 배열이 있습니다. 전체 문서가 반드시 중괄호로 시작해야 하는 것은 아닙니다. 값 하나나 배열도 JSON 문서가 될 수 있지만, 실제로 읽는 프로그램이 특정 구조만 받는지는 별도로 확인해야 합니다. 형식 자체가 허용하는 문법과 특정 서비스가 요구하는 입력 규격은 다릅니다. 파일 확장자가 맞는 것만으로 업로드 호환성이 보장되지는 않습니다.

비교 질문	CSV	JSON
기본 구조	행과 필드 중심의 표	객체와 배열로 중첩 관계 표현
값의 종류	읽는 도구와 별도 규칙으로 해석	문자열·숫자·불리언·null 등 구분
여러 상품을 가진 주문	항목 행으로 펼치거나 별도 표로 분리	주문 안의 항목 배열로 표현
사람이 검토할 때	표 편집 도구에서 행·열 비교가 편함	계층과 값의 종류를 확인하기 편함
반드시 합의할 내용	구분자·인코딩·빈 값·열 의미	필드 의미·필수 값·중복 이름 처리

2. 같은 주문을 두 가지 형식으로 표현한다

아래 자료는 실제 고객 정보가 아닌 설명용 예시입니다. 주문번호는 숫자로 계산할 값이 아니라 문자를 보존해야 할 식별자이므로 문자열로 적었습니다. 상품이 두 개 들어 있어 항목 배열에는 두 객체가 있습니다. 금액과 결제 정보는 넣지 않았습니다. 형식의 차이를 확인하는 데 필요하지 않은 항목을 줄이면 어떤 정보가 변환 과정에서 사라졌는지 읽기 쉽습니다.

{
  "order_id": "0012",
  "customer": "김예시",
  "items": [
    {"sku": "A01", "quantity": 2},
    {"sku": "B02", "quantity": 1}
  ],
  "memo": null
}

이 구조를 하나의 CSV로 펼치면 상품 항목마다 한 행을 만들 수 있습니다. 주문번호와 고객명이 반복되지만 그 반복이 곧 중복 주문을 뜻하지는 않습니다. 한 행의 의미를 ‘주문’에서 ‘주문 안의 상품 항목’으로 바꾼 결과입니다. 주문 수를 셀 때 행 수를 그대로 쓰면 주문 하나를 두 건으로 계산하게 됩니다. 변환 전후에 무엇을 한 건으로 세는지 먼저 정해야 합니다.

order_id,customer,sku,quantity
0012,김예시,A01,2
0012,김예시,B02,1

위 CSV 예시는 항목 구조를 보여주기 위해 memo를 생략했으므로 전체 JSON을 손실 없이 변환한 결과가 아닙니다. 주문 수준의 메모와 상품 수준의 정보를 모두 유지하려면 주문 표와 상품 항목 표를 분리할 수도 있습니다. 주문 표에는 주문번호가 한 번 나오고, 항목 표에는 같은 주문번호가 여러 번 나옵니다. 두 표를 연결하는 키가 주문번호입니다. 이는 이 글에서 제안하는 설계 예시이며 CSV가 자동으로 관계를 관리해 준다는 뜻은 아닙니다. 파일 두 개를 전달한다면 연결 규칙과 누락된 키 처리도 함께 설명해야 합니다.

3. CSV의 쉼표와 따옴표를 정확히 다룬다

RFC 4180은 널리 쓰이는 CSV 표현을 설명하는 정보 문서입니다. 모든 도구가 완전히 동일한 규칙으로 읽는다는 보장은 없습니다. 문서에 설명된 방식에서는 쉼표, 줄바꿈, 큰따옴표가 들어간 필드를 큰따옴표로 감싸고, 필드 안의 큰따옴표는 두 번 써서 표현합니다. 이 규칙을 모르고 쉼표로 문자열을 단순 분리하면 메모 한 칸이 두 열로 갈라질 수 있습니다.

id,memo
01,"회의, 자료 확인"
02,"그는 ""확인""이라고 적었다"

첫 번째 메모 안의 쉼표는 열 구분자가 아니라 메모 내용입니다. 두 번째 메모의 연속된 큰따옴표는 읽어 들일 때 내용의 큰따옴표 하나를 나타냅니다. 인용된 필드 안에는 줄바꿈도 들어갈 수 있으므로 텍스트 파일의 물리적인 줄 수가 항상 데이터 레코드 수와 같지는 않습니다. CSV 전용 읽기 기능으로 레코드를 세고, 단순한 줄 수 계산은 보조 점검으로 사용하세요.

구분자가 세미콜론이나 탭인 파일도 표 자료로 전달되지만, 받는 프로그램의 선택 화면에서 실제 구분자를 맞춰야 합니다. 모든 내용이 첫 번째 열에 붙어 있다면 데이터가 없는 것이 아니라 구분자 해석이 맞지 않은 경우일 수 있습니다. 열이 갑자기 늘어나면 인용 처리나 내용의 쉼표를 확인합니다. 수동으로 쉼표를 지우기 전에 원본 파일을 복사해 보존하는 것이 복구를 쉽게 합니다.

4. 숫자처럼 보이는 식별자를 숫자로 바꾸지 않는다

0012는 주문번호 예시에서는 네 자리 식별자입니다. 표 프로그램이 이를 숫자 12로 추정하면 표시나 내보내기에서 앞의 0이 사라질 수 있습니다. JSON 예시에서는 "0012"처럼 문자열로 적어 종류를 구분할 수 있지만, CSV에서는 해당 열을 텍스트로 읽도록 가져오기 설정이나 별도 열 규격을 전달해야 합니다. CSV의 큰따옴표만으로 모든 프로그램의 숫자 추정을 막을 수 있다고 생각하지 마세요.

전화번호, 우편번호, 상품코드도 같은 판단이 필요합니다. 더하거나 평균을 낼 값인지, 모양을 유지해야 할 식별자인지 구분하세요. 날짜처럼 보이는 코드가 자동으로 날짜로 바뀌는 경우에는 열을 텍스트로 지정하고 원본 값과 비교합니다. 이미 앞의 0이 사라졌다면 원본이나 길이 규칙을 알아야 복구할 수 있습니다. 임의로 0을 덧붙이면 원래 길이가 다른 코드와 구별하기 어렵습니다.

5. 빈 문자열, null, 누락 필드를 구분한다

JSON에서 "memo": ""는 빈 문자열 값이 있는 경우이고, "memo": null은 null이라는 값이 있는 경우입니다. 객체에 memo 항목 자체가 없다면 또 다른 상태입니다. 이 세 상태를 업무에서 같은 뜻으로 쓸 수도 있지만, 형식이 자동으로 같은 의미를 정해 주지는 않습니다. ‘내용 없음’, ‘아직 수집하지 않음’, ‘해당 항목 미지원’을 나누고 싶다면 입력 규칙을 명시해야 합니다.

CSV 빈 칸을 JSON으로 바꿀 때 모두 null로 넣으면 원래 빈 문자열을 의도한 값이 구별되지 않을 수 있습니다. 반대로 JSON의 null을 문자 "null"로 바꾸면 값의 종류가 달라집니다. 변환 전에 열마다 빈 값 처리표를 만드세요. 예를 들어 메모의 빈 칸은 빈 문자열로, 아직 정하지 않은 수량은 오류로, 선택하지 않은 배송일은 null로 처리한다는 식입니다. 이 규칙은 데이터 작성자와 읽는 쪽이 합의해야 합니다.

6. JSON 오류는 구문과 구조를 나누어 찾는다

일반 JSON 문법에서는 속성 이름과 문자열에 큰따옴표를 쓰며, 마지막 항목 뒤에 쉼표를 추가하지 않습니다. 주석을 넣은 설정 파일이나 작은따옴표를 쓰는 다른 언어의 객체 표현을 그대로 JSON이라고 부르면 읽기 오류가 날 수 있습니다. 먼저 문법 검사로 괄호, 인용부호, 쉼표를 확인하고, 그다음 필수 필드와 값의 종류를 확인합니다. 문법이 맞아도 수량이 음수이거나 주문번호가 빠진 데이터는 업무 규격에 맞지 않을 수 있습니다.

객체의 같은 이름을 반복하는 방식은 피하세요. RFC 8259는 이름을 고유하게 쓰도록 권고하며, 중복 이름을 처리하는 구현은 서로 다를 수 있습니다. quantity가 두 번 등장한 자료를 읽는 도구가 어느 값을 남기는지에 의존하면 변환 결과를 믿기 어렵습니다. 같은 종류의 여러 값은 서로 다른 이름을 억지로 만들기보다 배열이나 별도 항목 구조를 고려합니다.

7. 인코딩과 변환 결과를 단계별로 점검한다

상호 운용되는 JSON 교환에서는 UTF-8 사용이 중요합니다. CSV는 파일을 여는 도구의 인코딩 해석도 확인해야 합니다. 한글이 깨져 보일 때는 데이터를 새로 입력하기보다 가져오기 화면에서 원본 인코딩을 확인하세요. JSON 문법 오류와 문자 깨짐은 서로 다른 문제일 수 있습니다. 정상으로 읽힌 원본을 기준으로 변환하며, 사람이 읽는 이름뿐 아니라 식별자의 글자도 대조합니다.

설명용 주문을 CSV 두 행으로 펼쳤다면 검증값은 ‘주문번호의 고유 개수 1, 항목 개수 2, 수량 합계 3’입니다. 다시 JSON으로 묶을 때 항목이 두 개 들어 있는지 확인합니다. 행 수만 같다고 성공으로 판단하면 하나의 항목이 다른 항목으로 복제된 오류를 놓칠 수 있습니다. 항목코드의 집합, 식별자, 합계, 빈 값 상태를 함께 비교하면 변환에서 잃은 정보를 찾기 쉽습니다.

파일을 전달할 때는 작은 예시와 함께 열 또는 필드 설명서를 남기세요. 항목명, 의미, 값의 종류, 빈 값 규칙, 한 행의 의미를 적는 것으로 시작할 수 있습니다. 데이터 형식을 바꿔도 이 설명이 유지돼야 합니다. CSV를 JSON으로 바꾸는 도구를 고르는 것보다 먼저 보존해야 할 의미를 정하면, 변환 도구의 자동 추정을 검토할 기준이 생깁니다.

8. 형식을 선택하는 최종 체크리스트

• 한 행이 어떤 단위를 뜻하는지 정했는가?
• 한 항목에 여러 하위 항목이 들어가는가?
• 숫자와 식별자를 구별했는가?
• 빈 문자열·null·누락의 의미를 정했는가?
• CSV 구분자와 인용 규칙을 확인했는가?
• 한글 인코딩을 확인했는가?
• 변환 전후의 항목 수와 고유 키를 비교했는가?
• 실제로 받는 프로그램의 입력 규격을 확인했는가?

단순한 표를 사람이 검토하고 교환한다면 CSV가 편할 수 있고, 계층과 값의 종류를 보존하는 교환이라면 JSON이 적합할 수 있습니다. 어느 형식이 항상 우월한 것은 아닙니다. 자료의 관계, 사용 도구, 전달 규칙을 함께 정하고 변환 후 같은 의미가 남아 있는지 확인하는 것이 실질적인 선택 기준입니다.

공식 출처와 작성 기준

• IETF RFC 8259: JSON 형식
• IETF RFC 4180: CSV 형식과 MIME 유형

자료 확인일: 2026-10-10. 실제로 연 공식 자료를 바탕으로 AI가 작성한 설명입니다. 별도 표시한 계산·코드·점검 사례는 설명용이며 사용자 환경을 직접 시험하거나 실측한 결과가 아닙니다. 발행일에는 기능과 자료의 변경 여부를 다시 확인합니다.