JSON 파일과 CSV 파일이란? 초보자를 위한 두 포맷 완전 가이드 (2026 가이드)

짧은 답변

JSON 파일과 CSV 파일이란 무엇일까요? 이 둘은 구조화된 데이터를 저장하는 가장 흔한 일반 텍스트 포맷으로, 정보를 완전히 다른 모양으로 담아요. JSON(JavaScript Object Notation)은 중첩된 트리 모양 데이터용으로 설계됐어요. 이름 있는 필드를 가진 객체, 배열, 그리고 타입을 유지하는 값들, 예를 들어 텍스트, 숫자, true/false, null로 이루어져요. CSV(comma-separated values)는 평평한 표용으로 설계됐어요. 컬럼 이름을 적은 헤더 행 뒤에 레코드마다 한 줄씩 값을 적고, 모든 것은 텍스트로 저장돼요. JSON을 CSV로 변환한다는 건 트리를 표에 투영하는 일이에요. 중첩 객체는 address.city 같은 점 표기법 컬럼이 되고, 목록은 구분자로 이어진 하나의 셀이 되며, 모든 값은 텍스트가 돼요. 변환은 모든 말단 값을 유지해요. 유지하지 못하는 건 모양이에요. 타입, 중첩 구조, 중복 키는 이 여정을 살아남지 못해요. 그래서 JSON은 원본으로 보관하고, CSV는 데이터의 작업용 화면으로 쓰는 게 좋아요.

JSON 파일은 이렇게 생겼어요

실제 JSON 파일 하나를 볼게요. 고객 레코드 두 개예요. 한 번 천천히 읽어보세요. 이 가이드의 모든 개념은 결국 이 파일로 돌아오거든요. 샘플은 일부러 현실적인 모양으로 만들었어요. API 응답이나 앱 내보내기에서 흔히 보는 형태, 즉 레코드 목록 안에 중첩 객체와 배열이 섞인 구조예요. 각 줄이 어떤 역할을 하는지 파악해두면, 뒤에 나오는 평탄화 규칙이 훨씬 쉽게 읽혀요.

파일 전체는 대괄호 [ ]로 표시된 배열이고, 그 안에 객체 두 개가 들어 있어요. 중괄호 { }로 표시된 각 객체가 레코드 하나예요. 객체 안에서는 데이터가 키-값 쌍으로 살아요. "id": 101은 키 "id"가 값 101을 가진다는 뜻이고, 키는 항상 따옴표로 감싼 문자열이에요. 초보자가 가장 자주 만나는 오류가 바로 여기에 있어요. 마지막 키-값 쌍 뒤에 콤마를 찍으면 JSON 전체가 무효가 돼요. 자바스크립트 객체 리터럴에서는 허용되는 trailing comma가 JSON에서는 금지라서, 코드를 복사해서 붙여넣을 때 특히 조심해야 해요.

값은 타입을 유지해요. 이게 JSON의 슈퍼파워 중 하나예요. "Amelia Chen"은 문자열(텍스트, 따옴표 안)이에요. 101, 2023, 4는 숫자(따옴표 없음)예요. true와 false는 불리언이에요. null은 명시적인 "값 없음"인데, 빈 문자열과는 달라요. Amelia의 lastNote는 null이라서 필드는 있지만 값이 없다는 뜻이고, Bruno의 lastNote는 "Call, don't email"이라는 텍스트를 가지고 있어요.

그다음은 중첩, JSON이 존재하는 이유예요. "address"는 고객 객체 안의 객체로, city와 state라는 자기 키를 가지고 있어요. "tags"는 고객 객체 안의 배열로, 문자열 두 개를 담고 있어요. JSON은 원하는 만큼 깊이 중첩돼요. 객체 안의 배열 안의 객체, 데이터가 가는 데까지요. 공백은 의미가 없어서, 위에 예쁘게 출력된 버전과 한 줄로 압축된 버전은 같은 데이터예요. 알아두면 좋은 특이점 하나: 한 객체에 같은 키가 두 번 나오면 마지막 값이 이기고 첫 번째는 조용히 사라져요. 빌드 머신의 JSON.parse로 검증했어요. {"a":1,"a":2}는 2로 파싱돼요. 실제로는 드물지만, 일어나면 아무도 경고해주지 않아요.

customers.json: 레코드 2개, 중첩 구조

[
  {
    "id": 101,
    "name": "Amelia Chen",
    "email": "amelia@example.com",
    "vip": true,
    "signupYear": 2023,
    "address": { "city": "Austin", "state": "TX" },
    "orders": 4,
    "tags": ["newsletter", "referral"],
    "lastNote": null
  },
  {
    "id": 102,
    "name": "Bruno Almeida",
    "email": "bruno@example.com",
    "vip": false,
    "signupYear": 2024,
    "address": { "city": "São Paulo", "state": "SP" },
    "orders": 1,
    "tags": ["newsletter"],
    "lastNote": "Call, don't email"
  }
]

CSV 파일은 이렇게 생겼어요

이제 같은 두 레코드를 CSV로 볼게요. 이 출력은 위 JSON을 이 페이지의 변환기로, 평탄화 켜기로 변환한 결과예요. 그러니까 지금 보는 건 변환이 실제로 하는 일이지, 예시용 그림이 아니에요. 헤더의 컬럼 순서는 JSON의 키 순서에서 나왔고, address.city 같은 점 표기법 컬럼은 중첩 객체를 펼친 결과예요. 변환 옵션을 바꾸면 이 표의 모양도 바뀌니, 각 규칙이 셀 하나하나에 어떤 영향을 주는지 직접 눈으로 확인해보세요.

첫 줄은 헤더 행, 컬럼 이름들이에요. 그 뒤의 모든 줄이 레코드 하나씩, 같은 순서로 값을 콤마로 구분해서 적어요. 이게 포맷의 전부예요. 헤더, 행, 구분자. 컬럼 10개, 행 2개, 중첩은 어디에도 없어요.

이제는 모든 것이 텍스트예요. 이게 CSV의 결정적인 특징이에요. 101, true, 2023은 숫자나 불리언처럼 보이지만, 파일은 그걸 몰라요. 그냥 문자일 뿐이고, 파일을 여는 쪽이 의미를 정해요. Amelia 행 끝의 빈 셀은 null이었던 lastNote예요. null은 아무것도 아닌 게 됐어요. 두 개의 태그는 "newsletter; referral"이라는 하나의 셀이 됐고, "; "로 이어졌어요. Bruno의 메모는 따옴표로 감싸져 있어요. "Call, don't email"처럼요. 콤마를 포함하고 있기 때문이에요. 구분자를 포함한 값을 보호하는 방법이 바로 따옴표예요.

주소 객체는 address.city와 address.state라는 두 컬럼이 됐어요. 이 점 표기법 평탄화가 바로 변환기가 하는 일이고, 우리 평탄화 가이드에서 이 토글의 뒷이야기를 전부 설명해요. 주목할 점은 CSV가 더 이상 말할 수 없는 것들이에요. city와 state가 하나의 주소 객체에 속했다는 것, newsletter와 referral이 세미콜론이 들어간 문자열 하나가 아니라 별개의 태그 두 개였다는 것. 모양은 사라졌어요. 값은 남아 있어요. 반대로 말하면, CSV의 헤더 행이 곧 스키마예요. 컬럼 이름만 봐도 어떤 데이터가 들어 있는지 알 수 있어서, 처음 보는 파일도 금방 파악할 수 있어요. JSON은 각 레코드를 열어봐야 알 수 있는 정보가, CSV에서는 헤더 한 줄로 정리되는 거예요.

같은 두 레코드의 CSV 버전 (실제 변환기 출력)

id,name,email,vip,signupYear,address.city,address.state,orders,tags,lastNote
101,Amelia Chen,amelia@example.com,true,2023,Austin,TX,4,newsletter; referral,
102,Bruno Almeida,bruno@example.com,false,2024,São Paulo,SP,1,newsletter,"Call, don't email"

JSON 파일과 CSV 파일이란 무엇인가: 결정적인 5가지 차이

같은 데이터, 다른 철학이에요. 5가지 차이가 어떤 포맷을 집을지 정하고, 앞으로 듣게 될 "뭘 써야 하냐" 논쟁의 거의 전부를 설명해줘요.

첫째, 모양: JSON은 트리, CSV는 표예요. JSON은 고객을 품은 주문, 그 안에 주소, 그 안에 상품 목록처럼 현실이 가는 만큼 깊이 중첩할 수 있어요. CSV는 정확히 한 단계예요. 행과 컬럼. 더 깊은 건 점 표기법 컬럼으로 펼치거나 텍스트로 직렬화해서 셀에 넣어야 하고, 어느 쪽이든 원래 구조는 사실상 거기 없어요. 특히 객체의 목록은 CSV에 둘 자리가 없어서 JSON 텍스트로 셀에 욱여넣게 되고, 이러면 표로서의 장점이 반쯤 사라져요. 구조가 복잡할수록 CSV는 억지스러워지고, JSON은 자연스러워져요.

둘째, 타입: JSON은 숫자 2023과 텍스트 "2023"을 구분하고, 불리언 true와 문자열 "true"를 구분해요. CSV는 문자를 저장하고, 해석은 나중에 파일을 여는 쪽이 해요. 그래서 "007"이라는 문자열은 이 페이지 변환기의 CSV 출력에서 문자 007 그대로 도착해요(검증 완료). 그런데 파일을 열면 스프레드시트가 7로 보여줄 수 있어요. CSV는 텍스트를 충실히 지켰고, 엑셀이 그 위에 자기 추측을 얹은 거예요. 포맷은 제 할 일을 했고, 뷰어가 의견을 더한 거예요.

셋째, 스키마: JSON은 스스로를 설명해요. 모든 레코드가 자기 키를 들고 다녀서 레코드가 달라도 돼요. 어떤 고객은 다른 고객에겐 없는 "notes" 필드를 가질 수 있고, 파일은 여전히 완벽히 유효해요. CSV의 스키마는 헤더 행에 살고 균일함을 가정해요. 값이 하나 더 많은 행은 그 값을 둘 문서화된 곳이 없고, 행마다 필드가 다른 울퉁불퉁한 데이터는 별일 아닌 게 아니라 컬럼 정렬 퍼즐이 돼요.

넷째, 손편집: JSON은 작은 실수를 시끄럽게 혼내요. 콤마나 따옴표 하나 빠지면 파일 전체가 무효가 돼요. 짜증 나지만 정직하고, 그래서 JSON 검증기가 존재해요. CSV는 작은 실수를 조용히 혼내요. 값 안의 콤마 하나를 따옴표 없이 쓰면 그 뒤의 모든 컬럼이 밀리고, 파일은 여전히 열려요. 그냥 틀리게요. 손으로 고칠 때는 시끄러운 실패가 조용한 손상보다 나아요.

다섯째, 만드는 쪽: 포맷은 만드는 쪽을 따라가요. API, 앱, 데이터베이스, 로그는 중첩 구조와 타입으로 생각하기 때문에 JSON을 내보내요. 스프레드시트, 업무용 내보내기, 이메일 첨부파일은 사람이 표로 생각하기 때문에 CSV예요. 누가 파일을 건네주면, 그 포맷이 보통 어느 세계에서 왔는지 알려줘요. 그리고 변환은 두 세계가 서로 대화하는 방법이에요.

JSON을 CSV로 변환하면 실제로 무슨 일이 일어날까요

변환은 평탄화예요. 트리를 표에 투영하는 거예요. 이 섹션의 모든 주장은 이 페이지가 실제로 돌리는 변환 엔진과 똑같은 엔진을 빌드 머신에서 검증했어요. 그러니까 이상적인 규칙이 아니라 진짜 규칙이에요.

평탄화를 켜면 엔진은 여섯 가지 규칙을 적용해요. 중첩 객체는 점 표기법 컬럼이 돼요. address.city, address.state처럼요. 단순 값의 목록은 "; "로 이어진 하나의 셀이 돼요. newsletter와 referral은 "newsletter; referral"이 됐어요. null은 빈 셀이 돼요. 빈 목록도 빈 셀이 돼서, 변환 후에는 null과 빈 목록을 구분할 수 없어요. 빈 객체는 리터럴 텍스트 {}가 돼요. 숫자와 불리언은 텍스트 형태가 돼요. 2023은 문자 "2023"이 되는 거예요.

여섯 번째 규칙은 까다로운 경우를 다뤄요. 객체의 목록이에요. 객체들을 구분자로 잇는 건 말이 안 돼서, 엔진은 목록을 따옴표가 두 배가 된 JSON 텍스트로 셀 안에 저장해요. 따옴표가 두 배가 되는 이유는 CSV의 이스케이프 규칙 때문이에요. 셀 안에 따옴표가 들어가면 셀 전체를 따옴표로 감싸고, 안의 따옴표는 두 개씩 써서 "이건 내용이지 끝이 아니다"라고 표시해요. 엣지 케이스 표의 g 셀이 바로 그 결과물이에요. 테스트 레코드, 빈 객체, 빈 목록, null, 3단계 중첩, 객체 목록을 돌려보니 정확히 이렇게 나왔어요.

평탄화를 끄면 엔진은 더 단순하지만 덜 쓸모 있게 동작해요. 모든 중첩 값이 셀 안에 JSON 텍스트로 그대로 남아요. 같은 주소 객체는 {"city":"Austin"}이라는 셀 텍스트가 되고, 따옴표는 두 배가 돼요. 값은 같지만, 표로서는 훨씬 덜 쓸모 있어요. 그럼 언제 끄는 게 맞을까요? 중첩 구조를 나중에 복원해야 할 때예요. 셀 안의 JSON 텍스트는 온전한 JSON이라서, 파싱하면 원래 객체가 그대로 돌아오거든요. 평탄화를 켠 표에서는 이게 불가능해요. 즉, 켜기는 사람이 보는 용도, 끄기는 기계가 다시 읽는 용도에 가까워요. 어떤 설정이 언제 맞는지는 우리 평탄화 가이드에서 다뤄요.

조용한 규칙이 하나 더 있는데, 변환이 시작되기 전에 일어나요. JSON.parse는 키가 반복되면 마지막 값을 유지하기 때문에, {"code":"A1","code":"B2"} 같은 레코드는 B2만 가지고 변환돼요. 첫 번째 값은 변환기가 데이터를 보기도 전에 사라져요. 실제로는 드물지만, 딱 한 번은 알아둘 만해요.

실제 엔진으로 돌린 엣지 케이스 (평탄화 켜기)

a,b,c,d.e.f,g
{},,,1,"[{""h"":1},{""h"":2}]"

JSON 파일과 CSV 파일이란 무엇인가: 변환에서 살아남는 것과 사라지는 것

살아남는 것: 모든 말단 값, 텍스트로서요. 이름, 숫자, 날짜, 메모, 이메일 주소. 전부 CSV에 있고, 전부 정확해요. "내가 입력한 정보가 사라졌나"가 질문이라면 답은 아니에요. 스프레드시트, 가져오기 마법사, 빠른 육안 확인용으로는 필요한 게 빠지지 않아요.

살아남지 못하는 것: 첫째, 타입이에요. 숫자 2023과 텍스트 "2023"은 CSV에서 똑같아요. true와 "true"도 똑같아요. CSV를 읽는 쪽이 추측할 거고, 추측은 제각각이에요. 엑셀은 텍스트 "007"을 숫자 7로, "1-2"를 날짜로 바꿔버리기로 유명해요. 날짜도 마찬가지예요. "2024-01-05"라는 텍스트가 엑셀에서는 날짜로, 구글 시트에서는 텍스트로 보일 수 있어요. 같은 CSV인데 여는 도구에 따라 의미가 달라지는 거예요. 둘째, 중첩된 모양이에요. address.city는 자신이 객체였다는 걸 더 이상 모르고, "newsletter; referral"은 자신이 태그 두 개였다는 걸 더 이상 몰라요. 셋째, 중복 키예요. 마지막 값만 살아남아요. 넷째, null과 빈 목록의 구분이에요. 둘 다 빈 셀이 돼서 "값 없음"과 "비어 있는 목록"이 하나로 합쳐져요.

이게 평탄화 되돌리기 문제를 만들어요. 다시 변환하는 건 추측이에요. "newsletter; referral"은 태그 두 개였을까요, 세미콜론이 들어간 문자열 하나였을까요? address.city는 원래 객체였을까요, 아니면 키가 원래부터 말 그대로 "address.city"였을까요? 변환기가 추측할 수는 있지만, CSV는 기억하지 못해요. 경험칙: JSON을 원본으로 보관하고, 표 화면이 필요할 때마다 CSV를 만들어내세요. 저장 공간은 싸요. 모양을 되살리는 건 그렇지 않아요.

어느 포맷을 써야 할까요?

데이터에 모양이 있거나 보는 쪽이 프로그램이면 JSON을 고르세요. API, 앱, 데이터베이스를 오가는 데이터. 행마다 생김새가 다른 중첩되거나 울퉁불퉁한 레코드. 타입이 살아남아야 하는 값, 숫자로서의 가격이나 불리언으로서의 플래그처럼요. 로그, 설정, 그리고 코드가 처리할 모든 것. 설정 파일도 좋은 예예요. 앱 설정은 중첩된 옵션들로 이루어지기 때문에 JSON이 자연스럽고, 주석은 못 달지만 구조가 명확해서 사람이 직접 고치기도 어렵지 않아요. 나중에 구조를 되찾아야 할 것 같으면, JSON이 유일하게 안전한 집이에요.

보는 쪽이 사람이거나 표 모양 도구면 CSV를 고르세요. 엑셀이나 구글 시트로 열 사람이 있어요. 비개발자 동료에게 데이터를 이메일로 보내요. 대상 도구가 행과 컬럼을 기대해요. BI 대시보드, 가져오기 마법사, 메일링 리스트 업로더 같은 것들이요. 예를 들어 뉴스레터 발송 도구에 연락처를 올릴 때는 이름, 이메일, 구독 상태 같은 평평한 컬럼이면 충분하고, 이럴 때 CSV만큼 편한 포맷이 없어요. 데이터가 진짜 평평하고 파일을 가장 작게 만들고 싶어요. 빌드 머신에서 측정했더니, 균일한 고객 행 1,000개가 JSON으로는 111,433바이트, CSV로는 48,473바이트였어요. 절반도 안 되는 크기예요. JSON이 모든 행에 키 이름을 반복하기 때문이에요. 중첩 데이터에서는 이 비교가 무너져요. CSV는 우회책 없이는 중첩을 담을 수 없으니까요. 하지만 평평한 표에서는 CSV가 크기에서 매번 이겨요.

대부분의 팀이 정착하는 실용적인 조합: JSON으로 저장하고 교환하고, CSV는 필요할 때 내보내요. 풍부한 원본은 간직하고, 누군가 필요할 때마다 평평한 작업용 사본을 만들어내는 거예요. 이 페이지의 변환기는 정확히 그 두 번째 단계를 위해 존재하고, 우리 방법 가이드에서는 확실한 3가지 방법을 다뤄요. 온라인 변환기, 엑셀 Power Query, 파이썬이에요.

두 포맷을 오가는 방법

JSON에서 CSV로는 이 사이트가 만들어진 여정이에요. 이 페이지 상단의 변환기에 JSON을 붙여넣거나 업로드하세요. 가입 필요 없고, 변환은 전부 브라우저에서 돌아가서 데이터가 기기를 떠나지 않아요. 고객 정보처럼 민감한 데이터를 다룰 때는 이 점이 특히 중요해요. 서버에 업로드되는 방식이라면 개인정보 처리 방침을 따져봐야 하지만, 브라우저 안에서 끝나는 변환은 그런 걱정이 없거든요. 반복하거나 스크립트로 돌릴 일이라면, 우리 변환 가이드에서 엑셀 Power Query와 파이썬으로 같은 작업을 하는 법을 단계별로 설명해요.

CSV에서 JSON으로는 돌아오는 여정이고, 앞 섹션의 정직한 주의사항이 따라와요. 타입은 돌아오는 길에 추측해야 해요. CSV가 타입을 저장한 적이 없으니까요. 우리 역방향 가이드에서 변환 방법을 다루고, 추측이 어디서 빗나갈 수 있는지 보여드려요. 믿기 전에 직접 확인할 수 있게요.

자주 묻는 질문

JSON과 CSV는 같은 건가요?

아니요, 달라요. JSON은 객체와 배열로 중첩된 타입 있는 데이터를 저장하고, CSV는 텍스트 행으로 평평한 표를 저장해요. 둘은 다른 문제를 풀어요. JSON은 프로그램이 주고받는 구조화된 데이터용이고, CSV는 사람이 스프레드시트로 여는 표용이에요. 헷갈리는 이유는 둘 다 메모장으로 열 수 있는 일반 텍스트라서예요. 하지만 텍스트라는 공통점 빼고는 설계 철학이 정반대예요. 데이터에 모양이 있으면 JSON, 표면 CSV라고 외워두면 실수가 줄어요. 둘 사이를 끊임없이 변환하기 때문에 두 포맷 모두 사라지지 않는 거예요.

CSV 파일에 JSON처럼 중첩된 데이터를 담을 수 있나요?

원래는 안 돼요. CSV는 행과 컬럼만 있고 그 아래 깊이는 없어서, 중첩은 평탄화(주소 객체를 address.city, address.state 컬럼으로 펼치기)하거나 하나의 셀에 JSON 텍스트로 넣어야 해요. 두 우회책 모두 원래 모양을 잃어요. 그래서 중첩이 중요하면 JSON 파일을 원본으로 보관하는 게 좋아요. 평탄화 토글이 중첩 데이터에 정확히 뭘 하는지는 평탄화 가이드를 참고하세요.

JSON을 CSV로 변환하면 데이터가 손실되나요?

모양은 잃고 값은 잃지 않아요. 모든 말단 값은 텍스트로 살아남지만, 타입은 무너지고(숫자와 불리언이 텍스트가 됨), 중첩은 점 표기법 컬럼으로 펼쳐지며, 중복 키는 마지막 값만 남고, null과 빈 목록은 모두 빈 셀이 돼요. 다만 "값이 살아남는다"는 말에는 조건이 있어요. 숫자는 텍스트가 되니까, 나중에 다시 숫자로 쓸 거면 변환 과정에서 타입 정보를 따로 메모해두는 게 좋아요. 예를 들어 가격 컬럼은 숫자, 구독 여부는 불리언이었다는 식으로요. 이런 메모가 나중에 역변환할 때 추측을 줄여줘요. 스프레드시트나 가져오기용으로는 필요한 게 빠지지 않아요. JSON으로 되돌릴 계획이라면 원본 JSON 파일을 보관하세요.

JSON 파일과 CSV 파일 중 어느 쪽이 더 가벼운가요?

평평하고 균일한 데이터라면 CSV가 보통 훨씬 가벼워요. 빌드 머신에서 측정한 결과예요. 고객 행 1,000개가 JSON 파일로는 111,433바이트, CSV 파일로는 48,473바이트로 절반도 안 됐어요. JSON이 모든 행에 키 이름을 반복하기 때문이에요. 다만 파일 크기만 보고 포맷을 고르면 안 돼요. 중첩 데이터를 억지로 CSV에 넣으면 중복 행이 늘어나서 오히려 커질 수 있거든요. 중첩 데이터에서는 비교가 무너져요. CSV는 중첩을 복제하거나 직렬화하지 않고는 담을 수 없으니까요. 크기가 아니라 모양으로 고르는 게 결국 가장 작은 파일로 이어져요.

엑셀에서 JSON 파일을 열 수 있나요?

스프레드시트로 바로는 안 열려요. 확실한 방법은 두 가지예요. JSON을 먼저 CSV로 변환해서 여는 방법, 그리고 Power Query(데이터 > 데이터 가져오기 > 파일에서 > JSON에서)를 쓰는 방법이에요. Power Query는 JSON을 엑셀에 제대로 가져와요. 파일 변환 가이드에서 Power Query 경로를 단계별로 설명해요.

JSON은 사람이 읽을 수 있나요?

네, 일반 텍스트이고 작게 예쁘게 출력된 JSON은 잘 읽혀요. 크기와 깊이가 커지면 가독성이 무너져요. 한 줄로 압축된 내보내기는 기술적으로 읽을 수 있지만 실제로는 읽기 힘들어요. 큰 파일은 포매터로 먼저 예쁘게 출력하거나, CSV로 변환해서 표로 훑어보세요.

API는 왜 CSV 대신 JSON을 반환하나요?

API 데이터는 평평한 표인 경우가 드물기 때문이에요. 응답은 중첩되고(사용자에게 주소가 있고 주소에 좌표가 있음), 타입이 섞이고(숫자, 불리언, null), 레코드마다 달라요. 이 모든 걸 JSON은 처리하고 CSV는 못 해요. 데이터가 이미 표이고 사람이 보는 거면 CSV가 빛나고, 데이터에 모양이 있고 프로그램이 보는 거면 JSON이 빛나요.

한 탭에서 JSON을 CSV로 바꾸세요

이제 두 형식을 알았으니 여기서 바로 변환하세요. JSON을 붙여 넣고 CSV를 다운로드합니다. 무료이며, 회원 가입 없이, 브라우저 안에서 전부 실행됩니다.

JSON to CSV 변환기 열기

모든 가이드