"선배님, 설정 파일은 그냥 JSON으로 하면 안 되나요? 왜 굳이 YAML을 쓰라고 하시는 거죠?"
갓 입사한 신입 개발자가 눈을 동그랗게 뜨고 물었을 때, 저는 잠시 말문이 막혔습니다. 사실 저도 주니어 시절에는 그렇게 생각했거든요. "괄호 몇 개 더 있는 게 뭐가 중요해? 그냥 파싱 잘 되면 그만이지."
하지만 밤샘 배포 작업을 하다가 콤마(,) 하나 때문에 수천 라인의 설정 파일이 깨져서 시스템이 셧다운 되는 경험을 하고 나면, 이 지루해 보이는 '데이터 형식(Data Format)'이 얼마나 무서운 존재인지 뼈저리게 깨닫게 됩니다.
데이터 형식은 단순히 데이터를 담는 그릇이 아닙니다. 그것은 개발팀의 소통 방식이자, 시스템의 효율성을 결정짓는 설계 도면입니다. 오늘은 교과서적인 비교를 넘어, 실전에서 겪은 피, 땀, 눈물이 섞인 각 포맷의 장단점을 아주 솔직하게 털어놓으려 합니다.
1. JSON (JavaScript Object Notation): 웹의 절대 군주
2000년대 초반, XML의 장황함에 지친 개발자들에게 JSON은 그야말로 구세주였습니다.
"심플함이 곧 무기다"
JSON의 가장 큰 매력은 **'직관성'**입니다. 중괄호 {}와 대괄호 []만으로 모든 데이터를 표현합니다. 자바스크립트 객체와 1:1로 매칭되기 때문에, 프론트엔드 개발자에게는 모국어처럼 편안하죠.
실제로 제가 진행했던 모바일 앱 프로젝트에서 XML 기반의 SOAP API를 RESTful JSON API로 교체했을 때, 데이터 전송량이 1/3로 줄어드는 기적을 맛봤습니다. 속도는 빨라지고, 배터리 소모는 줄어들었죠.
치명적인 약점: "주석을 달 수 없다니!"
하지만 JSON에는 치명적인 단점이 있습니다. 바로 주석(Comment)을 공식적으로 지원하지 않는다는 점입니다.
서버 설정 파일로 JSON을 썼다가 낭패를 본 적이 있습니다.
"timeout": 5000
이 값이 왜 5000인지, 3000으로 바꾸면 무슨 일이 생기는지 설명할 방법이 없었습니다. 결국 우리는 별도의 문서 파일을 뒤져야 했죠. **"설명 없는 코드는 레거시(Legacy)"**라는 말이 있듯, 주석 없는 설정 파일은 시한폭탄과 다름없습니다.
2. XML (eXtensible Markup Language): 잊혀진 제국의 영광
"요즘 누가 촌스럽게 XML을 써요?" 라고 묻는다면, 당신은 아직 금융권이나 공공기관 프로젝트를 안 해본 겁니다.
"신뢰라는 이름의 무거움"
XML은 닫는 태그(</name>)가 반드시 있어야 하고, 문법이 매우 엄격합니다. 이 엄격함이 바로 XML이 아직 죽지 않은 이유입니다.
D2D나 XSD 같은 스키마(Schema)를 통해 데이터가 유효한지 기계적으로 완벽하게 검증할 수 있습니다. 은행 송금 데이터나 의료 기록처럼, 데이터 하나라도 잘못되면 큰일 나는 시스템에서는 JSON의 자유분방함보다는 XML의 깐깐함이 훨씬 안전합니다.
하지만 너무나 수다스럽다
문제는 가독성과 용량입니다. 태그 이름이 데이터를 감싸고 있다 보니, 실제 데이터보다 태그가 차지하는 용량이 더 클 때도 있습니다. 모바일 시대에 네트워크 대역폭을 낭비하는 주범으로 몰려 웹에서는 거의 퇴출당했습니다.
3. YAML (YAML Ain't Markup Language): 인간을 위한 언어
최근 데브옵스(DevOps), 쿠버네티스(Kubernetes), 깃허브 액션(GitHub Actions) 설정 파일은 약속이나 한 듯 YAML을 씁니다. 왜일까요?
"가독성의 끝판왕"
YAML은 괄호도, 태그도 없습니다. 오직 **들여쓰기(Indentation)**만으로 구조를 표현합니다.
server:
port: 8080
# 개발 서버 포트입니다 (주석 가능!)
JSON과 달리 주석을 자유롭게 달 수 있습니다. 이게 정말 큽니다. 설정 파일 자체가 문서 역할을 하니까요.
들여쓰기 지옥 (The Indentation Hell)
하지만 YAML을 쓰면서 "아..." 하고 탄식해 보지 않은 개발자는 없을 겁니다. 탭(Tab) 대신 스페이스바를 써야 하고, 들여쓰기가 한 칸이라도 어긋나면 파싱 에러가 납니다. 눈으로는 층이 맞아 보이는데 런타임에 에러가 터지는 그 순간의 허탈함이란... 그래서 저는 팀원들에게 항상 말합니다. "YAML 린터(Linter) 없이 코드를 커밋하는 건 범죄다."
4. 그래서 뭘 써야 하나요? (시니어의 가이드)
프로젝트 초기에 데이터 형식을 정하는 건 결혼 상대를 고르는 것만큼 중요합니다. 한번 정하면 바꾸기가 너무 힘들거든요. 제 경험에 비추어 명확한 기준을 드립니다.
- 웹/모바일 API 통신이다? -> 고민하지 말고 JSON입니다. 생태계 자체가 JSON을 위해 최적화되어 있습니다.
- 설정 파일(Configuration)이다? -> YAML을 강력 추천합니다. 주석 기능 하나만으로도 그만한 가치가 있습니다. 단, 들여쓰기 자동 검사 도구는 필수입니다.
- 데이터 무결성이 생명인 엔터프라이즈 연동이다? -> 욕먹을 각오 하고 XML을 고려하세요. 10년 뒤에 후임자가 감사해할 수도 있습니다.
기술에 정답은 없습니다. 상황에 맞는 최선을 선택할 뿐이죠. 저는 요즘 신규 프로젝트에서는 API는 JSON, 내부 설정은 YAML이라는 하이브리드 전략을 주로 씁니다. 각 기술이 탄생한 목적을 정확히 이해하고 적재적소에 배치하는 것, 그것이 바로 '아키텍처'의 시작이 아닐까요?
여러분의 프로젝트에서는 어떤 형식이 메인인가요? 혹시 콤마 하나 때문에 야근하고 있다면, 오늘 팀 회의에서 "우리 포맷 한번 바꿔볼까요?"라고 용기 있게 제안해 보세요. 물론 그 뒷감당은... 여러분의 몫이지만요! 화이팅입니다.