설정 파일 형식은 이미 넘칠 만큼 많지만, 실무에서 하나를 고를 때마다 불편함이 따라붙는다. JSON은 틀리지 않게 쓸 수는 있어도 사람이 손으로 쓰기엔 번거롭고, YAML은 쓰기 편한 대신 읽을 때 의미가 흔들린다. 새로 공개된 SOML(Sindre's Objectively Marvelous Language)은 바로 이 틈을 겨냥한다. 이름은 다소 장난스럽지만, 지향점은 분명하다. "사람이 쓰고 읽는 파일"을 위한 형식으로, JSON의 엄격함은 유지하되 그 소음을 걷어내겠다는 것이다.
타입은 내용이 아니라 문법에서 나온다
SOML 설계의 핵심은 단 하나의 규칙으로 요약된다. 값의 타입은 그 값의 문법에서 결정되며, 내용을 들여다봐서 추측하지 않는다는 것이다. 예를 들어 '123'처럼 따옴표가 붙으면 문자열이고, 123은 정수다. 파서가 값을 보고 나중에 타입을 다시 판단하는 일이 없다. 이 규칙이 왜 중요한지는 YAML을 써 본 사람이라면 금방 안다. YAML에서는 country: no라고 쓰면 문자열 "no"가 아니라 불리언 false가 되고, version: 3.10은 3.1이라는 숫자로 해석된다. 값의 내용이 타입을 결정하기 때문에 생기는 함정이다. SOML에서는 no가 문자열, 3.10이 float, 2가 int로 어떤 구현에서든 동일하게 읽힌다.
겉모습 역시 YAML에서 편했던 부분을 가져왔다. 파일 전체를 중괄호로 감쌀 필요가 없고, 줄 끝마다 쉼표를 찍지 않아도 되며, 키에 따옴표를 붙이지 않아도 된다. 줄바꿈이 쉼표의 역할을 대신하고, 주석은 거의 어디에나 넣을 수 있다. 다만 YAML의 아픈 부분, 즉 암묵적 타입 추론과 들여쓰기가 구조를 결정하는 방식, 앵커와 태그 같은 기능은 의도적으로 뺐다.
시간과 기간을 값으로 다룬다
실무에서 자주 부딪히는 또 하나의 모호함은 날짜와 시간, 그리고 기간의 단위다. timeout: 30이라고 적혀 있을 때 이것이 30초인지 30밀리초인지 설정 파일만 보고는 알 수 없는 경우가 흔하다. SOML은 2026-09-19 같은 날짜, 2026-09-19T14:00:00Z 같은 시점(instant), 30s 같은 기간(duration)을 문자열이나 숫자가 아닌 실제 값 타입으로 취급한다. 단위를 추측할 필요 없이 형식 자체가 의미를 담는다. 여기에 더해 경로나 정규식처럼 역슬래시가 많은 문자열은 이스케이프 없이 쓸 수 있고, 긴 산문은 블록 문자열로 넣는다.
TOML에서 좋았던 점도 흡수했다. 예측 가능한 타입, 리터럴 문자열, 의미 없는 들여쓰기(즉 들여쓰기가 구조에 영향을 주지 않는 것), 그리고 중복 키를 오류로 처리하는 엄격함이다. 반면 TOML의 테이블 규칙처럼 키의 의미가 앞서 나온 내용에 따라 달라지는 방식, 파서가 조용히 반올림하거나 잘라내는 값 처리는 배제했다. 대신 최상위 레벨에 배열을 둘 수 있게 했고, 테이블 헤더나 점으로 이어 쓰는 dotted key는 없앴다. 요점은 SOML 파일이 어느 줄에 놓이든, 어떤 파서로 읽든 하나의 의미만 갖는다는 것이다.
실무에서 어떻게 볼 것인가
SOML이 내세우는 또 하나의 장점은 하나의 정규형(canonical form)과 공유되는 적합성 테스트 스위트다. 구현이 여러 개 생기더라도 모두 같은 파일을 같은 방식으로 읽도록 보장하겠다는 의도다. 설정 형식에서 가장 골치 아픈 문제가 "같은 파일인데 환경마다 다르게 해석되는" 상황임을 생각하면, 이 부분은 단순한 문법적 편의보다 오히려 중요한 약속이다. 형식의 세부 규칙과 각 설계 결정의 이유는 별도 명세에 정리돼 있고, int와 float를 왜 나눴는지, 왜 기간 타입을 두었는지 같은 질문은 FAQ에서 다룬다. 도구 측면에서는 eslint-soml을 eslint-plugin-unicorn과 함께 쓸 수 있으며, unicorn은 recommended-soml 프리셋을 제공한다. 명세 자체는 MIT 라이선스로, 라이선스를 포함하거나 참조하지 않고도 자유롭게 구현할 수 있다.
현실적으로 보면 SOML이 당장 기존 형식을 대체할 가능성은 크지 않다. JSON과 YAML은 수많은 도구와 생태계에 깊숙이 박혀 있고, 새 형식이 이를 넘어서려면 파서 구현체와 에디터 지원, 그리고 실제 프로젝트의 채택이 축적되어야 한다. 현재 공개된 것은 명세와 lint 연동 정도이며, 언어별 성숙한 라이브러리가 얼마나 갖춰졌는지는 도입 전에 직접 확인할 부분이다. 그럼에도 SOML이 던지는 질문, 즉 "왜 설정 파일의 타입이 내용이 아니라 문법에서 나와야 하는가"는 YAML의 country: no 함정에 한 번이라도 당해 본 사람에게는 충분히 설득력 있다. 새 형식을 바로 채택하지 않더라도, 기존 설정에서 타입 모호성이 어디에 숨어 있는지 되짚어 보게 만드는 것만으로도 참고할 가치가 있다.