사랑과 증오의 편지 do Json
Source: Dev.to
JSON을 설정 형식으로 사용하는 것은 실수이다.
맞다, 실수다. 선호도가 아니다. 스타일 선택도 아니다. 설계상의 실수다.
이 주장은 사람들이 JSON이 작동하기 때문에 불편해한다. 그리고 무언가가 작동하면, 업계는 실제로 그것이 타당한지 의문을 제기하는 것을 멈추는 강한 경향이 있다.
JSON은 전송 형식으로서는 절대적인 성공을 거두었다. 예측 가능하고, 결정적이며, 파싱이 쉽고, 거의 보편적이다. 기계 간에는 훌륭하다. 문제는 우리가 그 동일한 특성들이 인간에 의해 작성·읽기·버전 관리·유지 보수가 가능하다고 판단할 때 시작된다.
그렇지 않다.
JSON은 경직되고, 장황하며, 의도적으로 제한되어 있다. 주석을 허용하지 않고, 의도를 전달하지 않으며, 컨텍스트를 제공하지 않고, 오류를 용인하지 않는다. 이러한 특성은 상호 운용성이 목표일 때는 장점이지만, 규칙·설정·도메인 구조를 표현하는 것이 목표일 때는 순수한 마찰이 된다.
그럼에도 우리는 JSON을 설정 형식으로, 즉석 DSL로, 그리고 인간이 몇 시간씩 읽고 쓰는 시스템의 저작 레이어로 계속 사용한다. 작동하나? 작동한다. 하지만 형편없이 작동한다 — 그리고 이 고통을 정상화했다고 해서 그것이 좋은 엔지니어링으로 마법처럼 바뀌지는 않는다.
이 글은 JSON을 비난하는 것이 아니다. 잘못된 곳에 올바른 도구를 고집해서 사용하고, 그 결과를 겪는 사람들의 경험이 비참해도 놀라는 태도를 비난하는 것이다.
왜 JSON이 승리했는가
JSON이 아름답고, 우아하거나, 표현력이 뛰어나서 승리한 것이 아니다.
JSON이 승리한 이유는 지루하고, 제한적이며, 예측 가능하기 때문이다 — 시스템‑간 통신이라는 문제에서는 이것이 엄청난 장점이다.
- 작고 폐쇄된 형식이며, 의미 있는 구문상의 모호성이 없고 구현이 쉽고 오해하기 어렵다.
- 창의성을 크게 제한하는데, 이는 서로를 알지 못하는 두 프로세스가 의도, 컨텍스트, 혹은 암시적 의미를 협상하지 않고 데이터를 교환해야 할 때 정확히 원하는 바이다.
기계‑대‑기계 통신 관점에서 JSON은 거의 이상적이다. 단순한 구조만을 강제하고, 이상한 단축키를 허용하지 않으며, 암시적 의미를 담고 있지 않고, 영리해지려 하지 않는다. 본질적으로 원시 데이터의 예측 가능한 봉투이다. 기계는 그것을 좋아한다. 컴파일러는 그것을 좋아한다. 인프라스트럭처도 그것을 좋아한다.
누군가 “내 API는 JSON을 사용한다”고 말하면, 모두가 정확히 무슨 뜻인지 안다. 놀라움도 없고, 창의적인 해석도 없으며, “그렇지만 이 경우는…” 같은 이야기도 없다. 계약이 존재한다. 그리고 런타임에 아무것도 협상하고 싶지 않은 상황에서 경직된 계약은 훌륭하다.
전송 포맷으로서 JSON은 받는 모든 존경을 받을 만하다.
모든 것이 잘못되기 시작하는 곳
문제는 누군가가 이 동일한 형식을 — 명백히 기계‑대‑기계 통신을 위해 설계된 — 보고 인간이 작성하기에도 좋은 아이디어라고 판단할 때 시작됩니다.
이는 보통 악의에서 비롯된 것이 아니라, 설계상의 게으름에서 비롯됩니다. 이유는 간단합니다: 시스템이 JSON을 소비한다면 사람도 JSON을 쓰게 하자. 논리적으로 들리지만, 또한 끔찍한 아이디어입니다.
JSON은 가장 작은 의도조차 표현하기 위해 절대적인 구문 정확성을 요구합니다. 쉼표 하나가 잘못되거나, 따옴표 하나가 빠지거나, 괄호가 제대로 닫히지 않으면 모든 것이 깨집니다. “약간 깨졌다” 같은 경우는 없습니다. 파싱 오류가 발생하면 대화는 끝납니다.
그러한 동작은 기계에게는 허용될 수 있습니다. 인간에게는 단순히 적대적이며, 이는 강한 타입과 명시적 계약을 좋아하는 사람에게서 나오는 말입니다.
Source: …
JSON은 구조적으로 인간에게 적대적이다
이것은 취향의 문제가 아니라 구조적인 문제입니다.
- JSON은 주석을 허용하지 않습니다.
- JSON은 정규 형태에서 뒤에 오는 쉼표를 허용하지 않습니다.
- JSON은 단축 표기를 허용하지 않습니다.
- JSON은 구문 완화를 허용하지 않습니다.
- JSON은 컨텍스트를 허용하지 않습니다.
- JSON은 의도를 허용하지 않으며—오직 구조만을 허용합니다.
이 때문에 JSON을 작성하는 사람은 의미보다 구문에 계속 신경을 써야 합니다. 도메인에 대해 사고하기보다는 모든 괄호를 닫았는지, 모든 문자열에 큰따옴표를 사용했는지, 쉼표를 놓치지 않았는지를 정신적으로 검증하게 됩니다. 이는 이미 복잡한 작업에 높은 인지적 부담을 추가합니다.
손으로 직접 작성된 큰 JSON 파일을 보면, 그것은 거의 명료함을 전달하지 못합니다. 오히려 저항을, 누군가가 고생했음을 전달합니다.
JSON 구성은 정규화된 실수
JSON 구성 파일은 아마도 이 기능 장애의 가장 흔한 예일 것입니다. 어디에나 존재하고, 동작하며, 모두가 “그냥 그런 것”이라고 받아들입니다. 그렇다고 해서 좋은 해결책이라는 의미는 아닙니다.
구성은 정의상 인간이 읽고, 쓰고, 검토하고, 버전 관리하며, 논의하는 대상입니다. 의도와 맥락을 담고 있으며, 종종 설명적인 주석이 필요합니다. JSON은 이러한 요소를 전혀 제공하지 않습니다.
그 결과, 풀 리퀘스트에서 검토하기 힘들고, 적절히 주석을 달기 어려우며, “이 키는 선택 사항이지만 특정 상황에서만 허용된다”와 같이 별도의 README에 설명된 외부 규칙으로 가득 찬 장황한 파일이 만들어집니다.
동작합니다. 하지만 그것은 억지로 작동하는 것입니다.
프로‑JSON 논증
“하지만 JSON은 간단합니다. 모두가 알고 있습니다.”
네. 모두가 알고 있습니다. 그렇다고 해서 적절한 것은 아니다.
그것은 약한 주장입니다.
모두가 어셈블리도 알고 있지만, 그렇다고 해서 비즈니스 규칙을 그 안에 작성한다는 의미는 아닙니다.
친숙함은 아니 도구‑선택 기준입니다. 문제에 대한 적합성이 기준입니다.
JSON은 소비하기는 간단하지만, 생성하기는 간단하지 않다.
그 구분은 겉보이는 것보다 훨씬 더 중요합니다.
Authoring formats exist for a reason
TypeScript, YAML, TOML, HCL 또는 어느 정도 합리적인 DSL을 사용해 복잡한 구조를 정의할 때, 차이는 즉각적으로 드러납니다. 이러한 포맷은 사람이 쓰고, 읽고, 유지보수하도록 설계되었습니다.
- 주석을 달 수 있습니다.
- 어느 정도 유연성을 제공합니다.
- 의도를 보다 명확하게 전달합니다.
- 작성에 드는 인지적 비용을 줄여줍니다.
- 가장 중요한 것은, 인간이 먼저 문제를 생각하고 그 다음에 표현 방식을 고민하게 만든다는 점입니다.
많은 경우 이러한 포맷이 내부적으로 JSON으로 변환되는 것은 우연이 아니라 건전한 아키텍처 설계의 결과입니다.
불필요한 고통을 피하는 파이프라인
잘 설계된 시스템에서는 흐름이 보통 간단하고 예측 가능합니다:
- 사람이 작성 표현력이 풍부하고 검증 가능하며 편안한(종종 타입이 지정된) 무언가를 작성합니다.
- 기계가 해당 구조를 검증하고 변환하며 정규화합니다.
- JSON은 시스템 간 계약으로 전송되거나 영구 저장이 필요할 때만 나타납니다.
이 구분은 관료주의가 아니라 인간의 한계에 대한 존중입니다.
- 기계용 강력히 타입이 지정된 구성을 작성한다면 TypeScript가 매우 잘 작동합니다.
- 읽고 유지보수해야 하는 구성 구조를 작성한다면 YAML(또는 유사한 것)이 적합합니다.
- 기계가 다른 기계에 데이터를 보내야 할 경우, JSON이 최적의 선택입니다.
예를 들어 API를 구축할 때는 객체, 타입, 검증 및 추상화와 작업합니다. JSON은 프로세스의 마지막 단계에서 생성되어 네트워크를 통과하고 상대편에서 파싱된 뒤 즉시 인간의 관여가 끝납니다. 그 JSON을 직접 다루는 사람은 없으며, 바로 그것이 핵심입니다.
혐오자인가 팬인가?
나는 여전히 JSON이 의미가 있을 때는 사랑한다: 전송, 계약, 직렬화, 시스템‑간 통신.
나는 누군가가 JSON에 복잡한 구조를 작성하고, 검토하고, 유지보수하길 기대할 때 여전히 싫어한다.
이것은 고집이 아니다.
이것은 트렌드도 아니다.
이것은 기술 엘리트주의도 아니다.
코드를 다루어야 하는 사람들에 대한 기본적인 존중이다.
JSON이 가치 있게 남기 위해 전 세계에 퍼질 필요는 없다. 올바른 위치에만 있으면 되며, 그 위치는 확실히 새벽 두 시에 당신과 키보드 사이에 있는 것이 아니다.
Note: 이 게시물의 모든 이미지는 Nuno Banana가 생성했습니다.