JSON: 웹 데이터의 핵심

제가 처음 웹 개발에 발을 들였을 때, 서버에서 내려준 데이터를 처음 마주했던 순간을 아직도 잊기 힘들어요. 알아보기 힘든 기호들로 가득 찬 한 줄짜리 문자열을 보고 “이걸 대체 어떻게 써먹지?” 싶어서 멍해졌거든요. 그런데 그 복잡한 암호문 같던 데이터가, 어느 순간부터는 잘 정리된 명함처럼 딱 들어오더라고요. 제 사수가
> “이게 바로 JSON이야. 웹의 언어 같은 거지.”
라고 하면서 깔끔하게 정돈된 JSON을 보여줬던 게 시작이었습니다.

요즘 우리가 쓰는 수많은 웹 서비스와 앱 데이터는 대부분 JSON(JavaScript Object Notation)이라는 형식으로 주고받고 저장합니다. 2001년에 더글러스 크록퍼드(Douglas Crockford)가 소개한 뒤로, 사람이 읽고 쓰기 쉽고 기계도 다루기 편한 텍스트 기반 포맷이라는 장점 덕분에 웹 표준급으로 쭉 자리 잡았어요. 그리고 JSON의 진짜 매력은 특정 언어에 묶이지 않는 유연함입니다. 거의 모든 현대 언어에서 기본 지원한다고 봐도 됩니다.

JSON, 어떻게 이해하고 파일에 접근하나요?

JSON이 대충 어떤 느낌인지는 알겠는데, 그래서 이게 파일로는 어떻게 생겼고 우리는 그걸 어떻게 열어보냐가 다음 고민이죠. 데이터는 “있다”로 끝나면 의미가 없고, 제대로 읽고 구조를 파악해야 값이 생깁니다.

여기서는 JSON 데이터가 담기는 .json 파일이 어떤 특징이 있는지랑, 제가 실무에서 은근히 자주 강조하는 보안 포인트도 같이 짚어볼게요. 그리고 중첩된 JSON을 사람 눈에 잘 보이게 풀어주는 JSON 뷰어도 같이 봅니다.

json 파일이란 무엇인가요?

JSON 파일은 말 그대로 .json 확장자를 가진 텍스트 파일이고, JSON 형식으로 구조화된 데이터를 저장할 때 씁니다. 보통 UTF-8 인코딩을 쓰니까 한글이든 뭐든 전 세계 문자 표현도 무난하고요.

파일 안에는 기본적으로 객체(object)랑 배열(array)이 있고, 객체는 key-value 한 쌍으로 굴러갑니다. 이걸 겹겹이 쌓으면 계층 구조가 만들어져요. 예를 들면 사용자 객체 안에 주소 객체를 넣고, 취미는 배열로 넣고 이런 게 자연스럽게 됩니다.

이 유연함 때문에 JSON은 진짜 여기저기서 씁니다. 제가 매일 보는 Node.js의 package.json, TypeScript의 tsconfig.json 같은 애들이 대표적이죠. 예전에 XML 많이 쓰던 시절이 있었는데, 그거랑 비교하면 JSON은 불필요한 태그가 없어서 훨씬 간결합니다. 파일 크기도 작아지고요. 네트워크로 왔다 갔다 할 때 이 차이가 은근히 큽니다.

기술적으로 .json 파일은 application/jsonCopy MIME 타입을 가집니다. 소포에 “이건 JSON 데이터입니다” 스티커 붙여주는 느낌이라, 서버가 브라우저나 클라이언트에게 데이터 정체를 알려주는 역할을 해요.

보안 쪽도 한 번만 짚고 갈게요. JSON 자체는 그냥 텍스트라서 실행 코드가 들어가는 건 아니고, 그래서 비교적 안전하다고들 합니다. 근데 문제는 “어떻게 처리하느냐”에서 터져요. 외부에서 받은 JSON을 무조건 믿고 처리하면 JSON Injection 같은 공격에 걸릴 수 있습니다. 귀찮아도 입력 데이터 검증은 습관처럼 가져가시는 걸 권장합니다.

json viewer

중첩된 JSON을 메모장으로 그대로 열어본 적 있으면, 그 한 줄짜리 지옥이 얼마나 사람을 괴롭히는지 공감하실 거예요. 쉼표, 중괄호, 대괄호가 뒤섞여서 “이게 어디서 닫히는 거지?” 하다가 눈이 풀립니다.

이럴 때 쓰는 게 JSON 뷰어(JSON viewer)고, JSON을 시각적으로 보기 좋게 표시해서 탐색을 쉽게 해주는 도구입니다. 핵심은 트리(tree) 구조로 보여주는 거예요. 객체랑 배열을 나뭇가지처럼 펼쳐주니까, 복잡해도 관계가 눈에 들어옵니다.

작년 여름에 카카오페이 API 연동 프로젝트를 했는데, 그때 뷰어의 소중함을 제대로 느꼈습니다. 결제 실패 응답이 엄청 중첩돼서 터미널에 찍힌 한 줄을 보고는 머리가 지끈했거든요. 근데 Chrome 개발자 도구 내장 뷰어로 열어보니까 구조가 바로 보이더라고요. 제가 찾던 error_code랑 error_message가 어디 박혀 있는지 경로가 딱 나와서, 30분 만에 버그를 정리했습니다.

좋은 뷰어는 예쁘게 보여주는 걸 넘어서 생산성 기능도 꽤 챙겨줍니다.
검색(Search) 기능은 특정 키나 값을 전체에서 빠르게 찾아주고요.

구문 하이라이팅(Syntax highlighting) 기능은 타입별로 색을 달리해서 가독성을 올려줍니다.
접기/펼치기(Collapse/Expand) 기능은 큰 JSON에서 필요한 부분만 보게 해줘요.

이런 도구 덕분에 개발자는 복잡한 데이터를 “잘 정리된 지도”처럼 훑으면서 필요한 정보를 빨리 찾을 수 있습니다.

JSON 처리 및 활용 도구

JSON을 눈으로만 보는 걸 넘어서, 코드에서 실제로 쓰거나 다른 형식으로 바꾸려면 도구들이 필요합니다. 유효성 검증도 해야 하고, 언어가 이해할 수 있는 구조로 바꿔야 하고, 사람이 보기 좋게 정리도 해야 하니까요.

여기서는 JSON 텍스트를 데이터 객체로 바꿔주는 파서(parser), 문법과 구조를 확인하는 검증기(validator), 보기 좋게 정리하는 포맷터(formatter)/뷰티파이어(beautifier), 그리고 CSV로 바꿔주는 변환기까지 한 번에 훑어볼게요.

다음 표는 주요 JSON 처리 및 활용 도구들을 요약한 것입니다.

json parser

JSON 파서(JSON parser)는 JSON 텍스트 문자열을 받아서, 언어가 바로 쓸 수 있는 데이터 구조로 바꿔주는 핵심 부품입니다. 저는 이걸 “외국어 편지를 내가 아는 언어로 번역하는 작업”이라고 자주 비유해요. 번역이 돼야 프로그램이 의미를 이해하고 만질 수 있거든요.

보통은 문법이 맞는지 보는 구문 분석(Syntax Analysis)을 하고, 그다음에 메모리 안에 실제 데이터 구조를 만드는 의미 분석(Semantic Analysis) 단계로 넘어갑니다. JavaScript는 JSON.parse()가 기본으로 있고, Python은 json 모듈의 json.loads()를 많이 씁니다.

제 경험상 대부분은 내장 파서로 충분합니다. 다만 대용량 데이터를 성능 빡세게 챙겨야 할 때는 스트리밍 파서도 고려해볼 만해요. 한 번에 다 읽지 않고 조금씩 흘려보내듯 처리해서 메모리를 아낍니다.

쌩초보 때 JSON 마지막에 쉼표(trailing comma) 하나 남겨놔서 파싱 에러로 몇 시간을 삽질했던 기억이 아직도 생생하네요. 그래도 좋은 파서는 이런 문법 오류를 딱 잡아주고, “몇 번째 줄 몇 번째 글자”처럼 메시지를 구체적으로 줍니다. 그때부터 데이터 형식은 더 꼼꼼히 보게 됐어요.

json validator

JSON 검증기(JSON validator)는 데이터가 표준 문법이랑, 우리가 약속한 구조를 제대로 따르는지 확인하는 도구입니다. 실무에서는 이게 일종의 품질 관리자 역할을 해요.

검증은 보통 두 갈래로 봅니다. 하나는 구문 검증(Syntax Validation)이고, 키는 큰따옴표로 감싸야 한다 같은 기본 문법을 체크합니다. 다른 하나는 스키마 검증(Schema Validation)인데, 이건 설계도 보고 건물 제대로 지었는지 확인하는 느낌이에요. 예를 들어 사용자 정보라면 name은 문자열이어야 하고 age는 0 이상의 숫자여야 한다 같은 규칙을 걸 수 있죠.

팀 프로젝트에서는 API 명세 쓸 때 JSON Schema를 같이 쓰는 걸 저는 꽤 강하게 추천하는 편입니다. 저희 팀도 새 API 만들면 스키마부터 잡고 가는데, 이러면 “필드 빠졌어요”, “타입 틀렸어요” 같은 커뮤니케이션 비용이 확 줄어듭니다. 검증기를 붙여두면 “아마 맞겠지”가 아니라 “맞는 게 확인됐어”로 바뀌어서, 서비스가 훨씬 예측 가능하게 굴러가요.

json formatter

JSON 포맷터(JSON formatter)는 한 줄로 뭉쳐 있거나 들여쓰기가 엉망인 JSON을, 사람이 읽기 좋은 형태로 정리해주는 도구입니다. 중요한 건 내용은 안 바꾸고, 보기만 좋게 만든다는 점이에요.

들여쓰기(indentation)랑 줄바꿈을 넣어서 계층 구조를 드러내주니까 가독성이 확 올라갑니다. VS Code 같은 에디터는 이거 거의 기본으로 해주죠. 단축키 한 번이면 끝납니다.

동료한테 API 응답 예시 공유할 때 포맷 안 된 JSON을 그대로 던지는 건, 저는 솔직히 좀 성의 없어 보이더라고요. 5초만 투자하면 다 같이 편해집니다. JavaScript에서는 JSON.stringify(obj, null, 2)Copy처럼 세 번째 인자에 들여쓰기 칸 수를 주면 pretty printing이 됩니다.

json beautifier

JSON 뷰티파이어(JSON beautifier)는 minified 돼서 읽기 힘든 JSON을 “예쁘게” 다시 펼쳐주는 도구를 말합니다. 사실상 포맷터랑 거의 같은 역할인데, beautifier라는 단어는 결과물이 더 깔끔하고 보기 좋다는 뉘앙스를 좀 더 줘요.

온라인 도구들도 많고, 붙여넣으면 바로 정리해줘서 편하긴 합니다. 다만 온라인 뷰티파이어에 개인정보나 회사 기밀 데이터 붙여넣는 건 진짜 조심하셔야 해요. 가능하면 로컬에서 도는 에디터 플러그인 쓰는 걸 권장합니다.

이렇게 보기 좋게 만드는 동작 자체를 json beautify라고 부르기도 해요. 내부적으로는 토큰 단위로 쪼개고 구조 분석한 다음, 규칙에 맞춰 들여쓰기랑 줄바꿈을 적용해서 결과를 만들어냅니다.

json to csv

JSON to CSV 변환은 계층 구조(JSON)를 엑셀 같은 2차원 테이블(CSV)로 바꾸는 작업입니다. 기획팀에서 “이번 달 신규 가입자 목록 엑셀로 뽑아주세요” 같은 요청 들어오면, 이게 갑자기 빛을 발합니다. DB에서 뽑아온 데이터가 JSON 형태로 오는 경우가 많거든요.

여기서 제일 큰 난관은 중첩된 객체랑 배열을 어떻게 평탄화(flatten)하느냐예요. 저는 이걸 “여러 층 인형의 집을 한 장짜리 평면도로 그리는 작업”이라고 비유합니다. 보통은 address.city, address.street처럼 점(.) 표기법으로 상위 구조를 표현하면서 펼쳐요.

복잡한 변환은 도구나 라이브러리 도움 받는 게 정신 건강에 좋습니다. 개인적으로는 Python의 pandas가 이런 쪽에서 진짜 강력하다고 느껴요. json_normalize 하나면 웬만한 중첩 데이터도 표(DataFrame)로 잘 풀립니다.

결국 JSON to CSV는 개발 데이터랑 비즈니스 데이터를 이어주는 다리 같은 역할을 하고, 데이터 활용도를 확 올려줍니다.

—

JSON은 그냥 “데이터 표현 형식” 정도로만 보면 아쉬워요. 실제 개발에서는 데이터를 읽고(뷰어), 코드에서 쓰게 바꾸고(파서), 사고 나기 전에 걸러내고(검증기), 보기 좋게 정리하고(포맷터/뷰티파이어), 필요하면 엑셀로도 넘기고(CSV 변환) 이런 흐름 전체를 받쳐주는 기본 체력 같은 존재입니다.

처음엔 중괄호랑 대괄호만 봐도 어지럽죠. 근데 이건 진짜 손에 익습니다. 삽질 몇 번 하고 나면 “아 이 키는 여기 있겠네” 감이 와요. 막히는 포인트 있으면 언제든 질문 던져주세요. 같이 보면서 정리해보면 금방 넘어갑니다.

FAQ

Q1: JSON과 XML의 가장 큰 차이점은 무엇인가요?
A: 제일 크게는 간결함이랑 가독성입니다. JSON은 XML처럼 여는 태그/닫는 태그를 계속 쓰지 않아서 문법이 훨씬 짧고, 파일 크기도 작아져서 전송에도 유리해요. 그리고 key-value 구조가 JavaScript 객체랑 닮아 있어서 개발자 입장에선 직관적으로 받아들이기 쉽습니다.

Q2: JSON 파일을 열 때 왜 뷰어(viewer)를 사용하는 것이 좋은가요?
A: 한 줄로 압축된 JSON은 일반 텍스트 편집기로 구조 파악이 너무 힘듭니다. 뷰어는 트리 구조로 보여주고 색도 입혀주고, 원하는 부분 접었다 펼 수도 있게 해줘요. 디버깅이랑 분석 속도가 확 달라집니다.

Q3: ‘파싱(Parsing)’이란 정확히 무엇을 의미하나요?
A: JSON 텍스트 문자열을, 프로그래밍 언어가 바로 쓸 수 있는 데이터 구조(객체, 배열 같은)로 바꾸는 과정입니다. 그냥 글자 덩어리였던 게 프로그램 안에서 의미 있는 데이터로 “변환”되는 거라고 보시면 돼요.

Q4: JSON 데이터를 검증(validate)해야 하는 이유는 무엇인가요?
A: 받는 데이터가 약속대로 왔는지 미리 확인하는 겁니다. 오타나 문법 문제(구문 검증)도 잡고, 필요한 필드가 다 있는지/타입이 맞는지(스키마 검증)도 확인해서, 프로그램이 예상 못 한 데서 터지는 걸 줄여줘요.

Q5: 중첩된 JSON 데이터를 CSV로 변환할 때 가장 주의해야 할 점은 무엇인가요?
A: 중첩 구조를 CSV라는 평면에 어떻게 펼칠지 결정하는 게 핵심입니다. 이 과정에서 관계가 뭉개지거나 정보가 일부 손실될 수도 있어요. user.address.cityCopy처럼 한 줄에 다 펼칠지, 아니면 사용자/주소를 CSV로 분리할지 같은 전략을 데이터 성격이랑 최종 목적에 맞춰 잡아야 합니다.