만드는 것과 변환하는 것은 다릅니다
"CSV를 만든다"와 "JSON을 CSV로 변환한다"를 같은 말처럼 쓰는 분이 많아요. 하지만 다릅니다. 변환은 기계적인 작업이에요. 같은 JSON은 같은 설정에서 항상 같은 CSV를 내놓죠. 만드는 것은 저작이에요. 동료에게 건네거나, 데이터베이스에 넣거나, 분석 도구에 먹이는 파일은 내가 통제할 수 없는 환경에서도 살아남아야 해요. 다른 나라의 엑셀, 규칙이 까다로운 데이터베이스 로더, 모든 걸 더블클릭으로 여는 동료까지요.
"변환됐다"와 "만들어졌다" 사이에는 일곱 가지 결정이 있어요. 건너뛰어도 파일은 변환돼요. 다만 가장 곤란한 순간에, 가장 곤란한 곳에서 깨지죠. 좋은 소식은 각 결정이 몇 초면 끝난다는 거예요. 한 번 이해하면 다시는 못 본 척할 수 없어요. 아래의 모든 예제는 이 사이트의 실제 변환 엔진 — 변환 버튼을 눌렀을 때 돌아가는 그 자바스크립트 그대로 — 로 실행했으니, 보이는 출력이 여러분이 실제로 얻게 될 결과예요.
결정 1: 격자를 만들기 전에 트리부터 펼치세요
중첩된 JSON으로는 컬럼을 만들 수 없어요. CSV는 격자예요. 행과 열, 모든 셀에 하나의 평평한 값만 들어가죠. 중첩된 객체가 들어갈 컬럼은 존재하지 않아요. 그래서 첫 번째 결정은 펼치기예요. 중첩 객체는 점 표기법 컬럼이 되고(customer는 customer.name과 customer.city가 돼요), 단순 값들의 목록은 한 셀에 합쳐지고, null은 빈 셀이 돼요. 이건 기계적인 단계이고, 변환기의 평탄화 토글이 대신 해줘요.
왜 먼저 해야 할까요? 이후의 모든 결정 — 헤더 이름, 구분자, 따옴표 — 이 펼쳐진 결과 위에서 동작하기 때문이에요. 펼치기 전에 헤더 이름을 바꾸면 아직 존재하지도 않는 컬럼에 이름을 붙이는 셈이죠. 이 엔진은 flattenNested라는 옵션 이름으로 기본적으로 펼치기를 켜 두고 있으니, 실제로 이 결정은 이렇게 내려요. 켜 둔 채로 두고, 미리보기를 쓱 보고, 컬럼 이름이 예상대로 나왔는지 확인하세요.
구체적인 예를 들어볼게요. {"order": {"id": 42, "customer": {"name": "Aisha", "city": "Lahore"}}, "items": ["pen", "book"], "paid": true, "note": null} 같은 JSON이 있으면, 펼친 뒤 컬럼은 order.id, order.customer.name, order.customer.city, items, paid, note가 돼요. items 같은 단순 값 목록은 하나의 셀에 합쳐지고, paid 같은 불리언은 true라는 텍스트가 되며, null이었던 note는 빈 셀이 되죠. 이 모양을 미리보기에서 확인하는 습관이 결정 1의 전부예요. 컬럼이 예상과 다르면 원본 JSON의 구조를 먼저 뜯어보세요. 변환기는 추측하지 않아요. 펼쳐진 결과가 곧 여러분이 저작할 격자니까요.
결정 2: 컬럼 이름은 계약서처럼 지으세요
헤더 행의 이름은 이 파일을 앞으로 만질 모든 도구와의 계약이에요. 나쁜 헤더 이름은 CSV를 망치는 가장 조용한 방법이에요. 변환할 때는 절대 실패하지 않고, 3주 뒤 데이터베이스 임포트에서 실패하죠. 네 가지 규칙이면 거의 다 커버돼요:
- 헤더 이름에 공백을 넣지 마세요. "order id"는 여러분 눈엔 읽기 쉽지만 SQL 로더에겐 버그 리포트예요. orderId나 order_id를 쓰세요. 평탄화 엔진이 이미 공백 없는 점 표기 이름(customer.name)을 만들어주니, 손볼 건 최상위 키뿐이에요.
- 중복된 이름을 쓰지 마세요. 헤더가 두 개 똑같으면 많은 임포터에서 두 번째 컬럼이 첫 번째를 조용히 덮어써요. JSON에 "user.name"이라는 리터럴 키와 중첩된 user: { name }이 둘 다 있으면, 펼치면서 하나의 컬럼으로 합쳐져요. 중첩된 값이 이기고 다른 하나는 사라져요. 두 값이 다 중요하면 변환 전에 이름을 바꾸세요.
- 숫자로 시작하지 마세요. "2024-sales" 같은 컬럼 이름은 많은 SQL 방언과 일부 BI 도구에서 깨져요. sales_2024를 쓰세요.
- 안정적이고 풀어서 쓰세요. 헤더는 API예요. "qty" 정도의 약어는 괜찮지만, "q"는 6개월 뒤 누군가를 헷갈리게 해요. 온전한 단어로 한 번 정하고 파일마다 재사용하세요.
두려워하지 않아도 되는 것 하나: 비ASCII 헤더 이름이에요. 컬럼이 product_name이고 "상품명" 같은 일본어 라벨이어도 UTF-8이면 문제없어요(결정 6에서 인코딩을 다뤄요). 엔진은 헤더 셀도 데이터 셀과 같은 따옴표 규칙으로 쓰니, 콤마나 따옴표가 들어간 헤더도 정확히 이스케이프돼요. 소스에서 이스케이프 로직을 검증했어요. 따옴표는 헤더를 포함해 셀마다 적용돼요.
결정 3: 구분자는 의도적으로 고르세요
콤마가 기본 구분자고, 대부분의 파일에선 그게 맞아요. 하지만 구분자는 형식이 아니에요. 파일 전체를 파싱하는 기준 문자죠. 변환기는 콤마, 세미콜론, 탭, 파이프, 사용자 지정을 제공하고, 각각이 제자리를 찾는 순간은 이래요:
- 콤마: 기본값. 반대 이유가 없으면 쓰세요. 모든 도구가 읽어요.
- 세미콜론: 데이터에 콤마가 가득할 때. 유럽에서 내보낸 파일에 이게 많은 건 우연이 아니에요. 유럽 많은 지역에서 소수점 구분자로 콤마를 쓰니 콤마 구분 파일은 모호해지거든요. 텍스트 필드에 콤마가 가득하면 세미콜론이 따옴표에 의존하지 않고 셀을 읽기 쉽게 유지해줘요.
- 탭: 사람이 원본 파일을 직접 읽을 때. 탭 구분 값은 스프레드시트에 바로 붙여넣어지고 텍스트 에디터에서도 읽기 쉬워요. 복사-붙여넣기 워크플로우에 유용해요.
- 파이프: 텍스트에 콤마, 따옴표, 세미콜론이 다 들어 있을 때. 로그 메시지, 주소, 긴 문장 같은 경우요. 파이프는 자연어 텍스트 안에 거의 안 나오니 충돌이 드물어요.
솔직한 단서 하나: 따옴표 처리가 존재하는 이유가 바로 구분자 선택을 버틸 만하게 만들기 위해서예요. 셀에 구분자가 들어 있으면 엔진이 자동으로 따옴표로 감싸주니(결정 4), 콤마가 잔뜩 든 주소도 콤마 구분 파일에서 제대로 파싱돼요. 구분자 선택은 읽기 쉬움과 독자의 습관 문제지, 정확성 문제가 아니에요. 정확성은 따옴표 엔진의 일이죠. 진짜 주의할 점은 하나예요. 미국이나 영국 독자에게 세미콜론 파일을 보낸다면 미리 말하세요. 그들의 엑셀은 기본적으로 콤마를 기대해서 파일을 하나의 긴 컬럼으로 열어버릴 수 있어요.
결정 4: 따옴표는 자동으로 두세요
따옴표는 CSV에서 가장 오해받는 부분이에요. 규칙은 단순해요. 구분자, 따옴표 문자, 줄바꿈 중 하나라도 든 셀은 큰따옴표로 감싸야 하고, 안의 따옴표는 두 개로 늘려 써야 해요. 엔진이 실제로 내놓는 결과는 이렇습니다. 검증된 거예요, 예시용이 아니에요:
name,city,qty
"Say ""hi"", friend",Oslo,3자세히 읽어보세요. 셀 Say "hi", friend가 "Say ""hi"", friend"가 됐어요. 콤마가 들어 있어서 따옴표로 감싸졌고, 안의 따옴표는 두 배가 됐죠. 표준에 맞는 정확한 출력이고, 모든 제대로 된 스프레드시트 프로그램이 원래 텍스트 그대로 다시 파싱해요.
결정 4: 따옴표는 자동으로 두세요 (계속)
구분자를 세미콜론으로 바꾸면 따옴표 처리가 어떻게 적응하는지 보세요:
name;city;qty
"Say ""hi"", friend";Oslo;3콤마는 더 이상 감싸기를 유발하지 않지만, 따옴표 문자는 여전히 유발해요. 엔진은 고정된 "특수 문자" 관념이 아니라 실제로 쓰는 구분자를 기준으로 따옴표를 처리해요. "자동"이 바로 이 뜻이고, 손대지 말고 두어야 할 설정이에요. 엔진은 항상(always)과 절대 안 함(never) 따옴표 모드도 제공하는데, never는 함정이에요. 증거는 여기 있어요:
결정 4: 따옴표는 자동으로 두세요 (계속)
note,code
line1
line2,007따옴표를 끄면, 진짜 줄바꿈이 든 셀은 날것 그대로 남아요. 그리고 그 줄바꿈은 이제 지구상의 모든 파서 눈에 행 경계로 보여요. 2행짜리 파일이 3행으로 읽히고, 그중 하나는 쓰레기예요. 따옴표는 여전히 두 배로 늘려 써요(엔진은 그걸 무조건 하거든요). 하지만 아무것도 감싸지 않아요. "never"는 다운스트림 시스템이 따옴표 없는 출력을 명시적으로 요구하고, 어떤 셀에도 구분자·따옴표·줄바꿈이 없다는 걸 검증했을 때만 쓰세요. 그 외의 모든 경우: 자동으로 두세요.
결정 5: 값은 보이길 원하는 모습 그대로 텍스트로 만드세요
JSON에는 타입이 있어요. 숫자, 불리언, null. CSV의 타입은 딱 하나예요. 텍스트. 변환되는 순간 모든 값이 최종 텍스트 형태가 되는데, 이 결정을 의식적으로 내리는 사람이 가장 적어요. 주목할 값의 모양 세 가지:
첫째, 앞자리 0. "007" 같은 JSON 문자열은 CSV에서도 007 그대로 남아요. 따옴표 없이, 입력한 그대로요. 검증했어요. 하지만 이 파일을 엑셀로 열면 여전히 7로 보여요. 엑셀이 열 때 셀을 재해석하거든요. CSV는 정확하고, 뷰어가 제멋대로인 거예요. 앞자리 0이 엑셀에서도 살아남아야 한다면, 고칠 곳은 받는 쪽(텍스트로 가져오기)이지 파일이 아니에요. 변환기를 탓하기 전에 이걸 아세요.
둘째, 날짜. JSON엔 날짜 타입이 없으니 여러분의 "날짜"는 2026-10-14 같은 문자열이나 1697000000 같은 타임스탬프예요. 어떤 모양으로 변환하든 CSV는 그 모양을 유지하니, 내보내기 전에 사람이 볼 모양으로 고르세요. ISO 2026-10-14는 텍스트로도 정렬이 제대로 돼요. 10/14/2026은 안 되고, 세계 절반이 오독해요. CSV가 생긴 뒤가 아니라 JSON 단계에서 결정하세요.
셋째, 소수와 불리언. 19.99000001 같은 숫자는 정확히 그 텍스트가 되고, 불리언은 true/false가 돼요. 원본 데이터에 부동소수점 노이즈가 있으면 변환 전에 반올림하세요. CSV가 대신 반올림해주지 않아요.
변환 전에 원본에서 정리하면 좋은 세 가지가 있어요. 날짜는 ISO 2026-10-14 형태로 통일하고, 부동소수점 노이즈는 미리 반올림하고(19.99가 19.989999999로 저장된 경우가 흔해요), 불리언은 true/false 그대로 둘지 예/아니요 같은 표현으로 바꿀지 정하세요. CSV는 있는 그대로 옮겨 적을 뿐이라, "예쁘게 보이게 하기"는 변환 전에 끝내야 해요. 원본 JSON을 손보는 1분이 나중에 파일을 고치는 30분을 아껴줘요.
결정 6: UTF-8을 의식적으로 고르세요 — BOM 문제도 알아두세요
인코딩은 깨진 문자를 보기 전까지 아무도 결정하지 않는 항목이에요. 2026년의 답은 UTF-8이에요. 모든 언어를 담고, 모든 최신 도구가 읽어요. 미묘한 건 BOM이에요. 일부 윈도우 도구가 파일 맨 앞에 원한다는 보이지 않는 바이트 순서 표시죠.
이 사이트 변환기에 대한 솔직한 사실 하나: 다운로드되는 파일은 BOM 없는 순수 UTF-8이에요. 다운로드 코드를 직접 읽어봤어요. text/csv Blob을 charset=utf-8로 만들고 앞에 표시를 붙이지 않거든요. 웹 업로드, 데이터베이스, 구글 시트, 파이썬에는 정확한 선택이에요. 딱 한 군데서 물려요. 일부 윈도우 엑셀 버전에서 파일을 더블클릭하면 인코딩을 잘못 추측해서 비ASCII 문자가 깨지는 경우요.
해결책은 변환기에 BOM을 요구하는 게 아니에요. 20초짜리 가져오기예요. 엑셀에서 데이터 → 텍스트/CSV에서 → 인코딩 드롭다운에서 65001(UTF-8)을 고르세요. 문자가 완벽하게 나오고, 파일 자체는 다른 모든 도구에 깨끗하게 유지돼요. 인코딩은 워크플로우마다 한 번 정해서 파일 옆에 적어두세요. 인코딩 사고는 항상 소통의 실패지, 데이터의 실패가 아니에요.
파일을 다른 사람에게 보낼 때는 인코딩과 구분자를 한 줄로 적어서 같이 보내세요. "UTF-8, 콤마 구분" 이 한 줄이면 받는 쪽의 추측 게임이 끝나요. 구글 시트나 리브레오피스 Calc는 BOM 없는 UTF-8을 자동으로 잘 읽으니, 엑셀 더블클릭 문제 하나 때문에 파일 자체를 바꾸지 마세요. 받는 쪽 환경에 맞는 건 가져오기 방법이지, 파일 형식이 아니에요.
결정 7: 완성된 파일은 떠나기 전에 검증하세요
만들기의 끝은 점검이고, 1분도 안 걸려요. 네 단계예요:
- 스프레드시트가 아니라 텍스트 에디터로 먼저 여세요. 텍스트 에디터는 파일을 보여주고, 스프레드시트는 해석을 보여줘요. 헤더 행, 구분자, 따옴표 처리된 셀이 멀쩡한지 확인하세요.
- 행을 세세요. 엔진이 통계에 행과 열 개수를 알려줘요. JSON 배열 길이와 비교하세요. 안 맞으면 파싱 사고예요(보통 quoteMode \"never\"에서의 따옴표 없는 줄바꿈, 또는 입력 JSON이 잘못된 경우).
- 다시 불러들여 보세요. CSV를 붙여넣거나 보낼 도구에 열어보세요. 거기서 제대로 열리면 받는 사람에게도 제대로 열려요.
- 가장자리를 확인하세요. 첫 행, 마지막 행, 그리고 가장 이상한 문자가 든 행 하나. 깨짐은 경계에 몰려요.
"내 CSV가 왜 깨져 보이죠"에 대한 답도 이 체크리스트예요. 경험상 열 번 중 아홉 번은 뷰어나 가져오기 설정 문제고, 파일 자체 문제는 한 번이에요. 텍스트 에디터 먼저 여는 습관이 둘을 몇 초 만에 갈라줘요.
리브레오피스 Calc로 확인하는 것도 좋아요. CSV를 열 때 구분자 미리보기 대화상자가 뜨는데, 거기서 셀이 의도대로 나뉘는지 바로 보여요. 미리보기에서 컬럼이 어긋나 보이면 구분자 선택이 잘못된 거고, 글자가 깨져 보이면 인코딩 문제예요. 원인이 파일 쪽인지 설정 쪽인지 가르는 데 10초면 돼요.
60초 레시피, 일곱 결정을 한 번에
JSON을 변환기에 붙여넣거나 업로드하세요. 평탄화는 켜 둔 채로 컬럼 미리보기를 쓱 보세요. 저 점 표기 이름들이 헤더가 되니, 문제 되는 키는 원본에서 먼저 이름을 바꾸세요. 텍스트에 콤마가 많지 않으면 콤마 구분자를 유지하세요(많으면 세미콜론). 따옴표는 자동으로 두세요. 날짜와 숫자는 변환 전에 보이길 원하는 모습 그대로 일반 텍스트로 만드세요. UTF-8 파일을 다운로드해서 텍스트 에디터로 한 번 열고, 보낼 곳에 다시 불러들이세요. 끝. 단순히 변환된 파일이 아니라, 만들어진 파일이에요. 이 일곱 가지가 손에 익으면 다음 파일부터는 의식하지 않고도 저절로 하게 돼요.
관련 가이드
- JSON을 CSV로 변환하는 방법: 확실한 3가지 방법 (2026 가이드)
- 중첩된 JSON을 CSV로 변환하는 방법: 평탄화 토글이 실제로 하는 일 (2026 가이드)
- JSON CSV 변환 온라인 도구란? 좋은 도구 고르는 법 (2026 가이드)
- VS Code에서 JSON을 CSV로 변환하는 방법: 클릭부터 단축키 한 번까지, 4가지 방법 (2026 가이드)
- how to flatten the JSON data: JSON 데이터를 펼치고, 합치고, 중첩 그대로 두는 방법 (2026 가이드)
- JSON을 CSV로 변환하는 방법이 있나요? 네 — 상황에 맞게 고르는 5가지 방법 (2026 가이드)
- JSON to CSV 온라인 변환 방법: 이 탭에서 30초 만에 끝내는 법 (2026 가이드)
- json to csv converter download: 실제로 다운로드해야 할 것 (2026 가이드)
- Convert Large JSON to CSV Online Free: 대용량 파일, 어디까지 변환할 수 있을까요? (2026 가이드)
- JSON 파일과 CSV 파일이란? 초보자를 위한 두 포맷 완전 가이드 (2026 가이드)
- What does flattening a JSON mean? JSON 평탄화의 의미 해설 (2026 가이드)
- What is JSON to CSV online? 세 단어를 풀이합니다 (2026 가이드)
- what is JSON to CSV converter online? 다섯 단계로 뜯어보는 온라인 변환기의 구조 (2026 가이드)
- JSON을 CSV로 로컬에서 변환하는 방법: 파일을 내 컴퓨터 안에 두는 법 (2026 가이드)
- JSON을 CSV로 로컬에서 변환하는 방법은? 6가지 방법 비교 (2026 가이드)
- CSV가 Excel에서 한 열로 열리는 이유와 해결 방법 (2026 가이드)
- Excel에서 CSV가 깨진 문자로 보이는 이유와 인코딩 해결 방법 (2026 가이드)
- Excel이 CSV 코드의 앞자리 0을 지우는 이유와 이를 지키는 방법 (2026 가이드)
- 엑셀에서 CSV 날짜가 바뀌는 이유와 날짜를 그대로 지키는 방법 (2026 가이드)
- 엑셀에서 CSV를 저장하면 파일이 바뀌는 이유와 원본을 안전하게 지키는 방법 (2026 가이드)
- 엑셀로 열리지 않는 큰 CSV 파일, 원인과 해결 방법 (2026 가이드)
자주 묻는 질문
JSON으로 CSV 파일을 만들려면 어떻게 해야 하나요?
JSON을 변환기에 붙여넣거나 업로드하고, 중첩 데이터를 컬럼으로 펼치고, 헤더 이름과 구분자를 검토한 뒤 다운로드하세요. 전체 체크리스트예요. 먼저 펼치고, 컬럼 이름은 공백 없이 짓고, 데이터에 콤마가 많지 않으면 콤마 구분자를 유지하고, 따옴표는 자동으로 두고, 날짜와 숫자는 보고 싶은 모습 그대로 텍스트로 만들고, UTF-8로 다운로드하고, 파일을 한 번 다시 불러들여 검증하세요.
JSON으로 만든 CSV에 가장 좋은 구분자는 뭔가요?
콤마가 기본값이고 대부분의 파일에 맞는 선택이에요. 텍스트 필드에 콤마가 가득하면 세미콜론을 쓰세요(유럽 내보내기에 흔해요. 거기선 콤마가 소수점 구분자이기도 하거든요). 복사-붙여넣기 가독성엔 탭, 콤마·따옴표·세미콜론이 다 든 텍스트엔 파이프를 쓰세요. 제대로 된 따옴표 처리 덕분에 어느 쪽도 안전하게 파싱돼요. 선택 기준은 정확성이 아니라 독자의 습관이에요.
JSON으로 만든 CSV의 컬럼 이름은 어떻게 지어야 하나요?
헤더 이름을 계약처럼 다루세요. 공백 금지(order_id처럼 쓰세요, "order id" 말고), 중복 금지, 숫자로 시작 금지(sales_2024처럼 쓰세요, 2024-sales 말고), 알 수 없는 약어 대신 온전한 단어. 중첩 키를 펼치면 customer.name 같은 공백 없는 점 표기 이름이 이미 나오니, 보통 손볼 건 최상위 키뿐이에요.
JSON으로 만든 CSV가 엑셀에서 이상하게 열리는 이유는 뭔가요?
열 번 중 아홉 번은 파일이 멀쩡하고 뷰어가 문제예요. 흔한 원인이에요. 엑셀이 구분자를 잘못 추측(콤마로 열린 세미콜론 파일), 비ASCII 텍스트의 인코딩 오추측(데이터 → 텍스트/CSV에서 가져오기로 65001 UTF-8 지정), 엑셀의 셀 재해석(007의 앞자리 0 제거, 날짜 서식 변경). 파일을 텍스트 에디터로 먼저 열어보세요. 거기서 멀쩡하면 파일이 맞는 거예요. 리브레오피스 Calc는 열 때 구분자를 직접 고르게 해주니, 구분자가 의심될 때 대조용으로 열어보세요.
CSV의 모든 셀에 따옴표를 붙여야 하나요?
아니요. 자동(필요할 때만) 따옴표 처리가 정확하고 충분해요. 구분자·따옴표·줄바꿈이 든 셀은 큰따옴표로 감싸지고, 안의 따옴표는 두 배가 돼요. "항상"은 노이즈를 더하고, "안 함"은 위험해요. 따옴표 없는 줄바꿈이 셀 안에 있으면 모든 파서가 행 경계로 보고 행 개수를 조용히 망가뜨려요.
JSON으로 만든 CSV에 BOM이 있어야 하나요?
보통은 아니에요. BOM 없는 UTF-8 파일은 어디서나 통해요. 데이터베이스, 웹 업로드, 구글 시트, 파이썬. 일부 윈도우 엑셀 버전이 더블클릭할 때 BOM 없는 파일을 오독해요. 해결책은 BOM을 추가하는 게 아니라 제대로 가져오기(데이터 → 텍스트/CSV에서, 인코딩 65001)예요. BOM은 다른 도구를 헷갈리게 할 수 있거든요. 이 사이트의 변환기는 BOM 없는 순수 UTF-8로 다운로드돼요. BOM이 도움이 되는 경우도 있긴 해요. 아주 오래된 윈도우 전용 도구가 BOM을 기대하는 경우죠. 하지만 그 경우에도 받는 쪽에만 BOM 버전을 따로 주는 게 낫고, 원본 파일은 BOM 없이 보관하세요.
생성한 CSV가 맞는지 어떻게 확인하나요?
네 단계면 돼요. (스프레드시트가 아니라) 텍스트 에디터로 열어서 실제 파일을 보고, 행 개수를 JSON 배열 길이와 비교하고, 보낼 도구에 다시 불러들이고, 첫 행·마지막 행·가장 이상한 문자가 든 행을 살펴보세요. 깨짐은 경계에 몰려요. 가장자리가 맞으면 파일이 맞는 거예요. JSON 배열 길이와 행 개수가 다르면 따옴표 없는 줄바꿈이나 입력 JSON 오류를 먼저 의심하세요.
지금 CSV를 만드세요 — 평탄화, 따옴표, 헤더까지 처리해 드려요
JSON을 붙여넣거나 파일을 업로드하세요. 중첩 데이터는 깔끔한 컬럼으로 펼쳐지고, 구분자와 따옴표는 자동으로 처리되며, 다운로드는 순수 UTF-8이에요. 무료, 가입 불필요, 전부 브라우저 안에서 돌아가요.
JSON-CSV 변환기 열기