구성 언어 선택의 문제가 아니라, 구성 자체를 사용자 인터페이스로 보고 뛰어난 편집 경험을 요구해야 한다는 제안. YAML의 한계와 함께 KSON을 사례로 들어 “configuration is UI” 비전을 소개한다.
우리 모두 한 번쯤 겪어봤다. 소프트웨어가 계속 커지면서 사용자 맞춤 설정이 필요하다는 생각이 든다. 아직 모든 장식과 기능을 갖춘 본격 UI를 만들기에는 이르고, 실용적인 본능은 텍스트 기반 구성 파일을 속삭인다. 그래, 바로 그거야!
버전 관리가 손쉬울 거란 사실에 기쁨이 밀려온다. 실용적 본능도 만족한다. 어차피 나중에 제대로 된 UI를 만들 길은 열려 있으니까. 구성의 구조화된 데이터를 단지 그래픽으로 보여주기만 하면 되니 말이다. 미래는 밝다!
이제, 당신의 찬란한 구성 파일에는 어떤 언어를 고를 것인가? 사용자 친화적이어야 한다. 사람들이 쉽게 들여다보고 수정할 수 있어야 하니까. JSON이 가장 먼저 떠오르지만, 난무하는 괄호와 주석 부재가 마음에 걸린다. TOML은 어떨까? 필요한 기능에 비해 너무 미니멀할까 봐 걱정된다. 직접 언어를 만들자니 너무 비실용적이다.
금단의 불꽃이 머릿속에 번쩍인다. 꺼보려는 모든 시도는 헛수고다. 불꽃은 점점 커지다 마침내 활활 타오르며 따뜻한 유혹을 건넨다. 왜 YAML은 안 될까? 그렇다, YAML. 보기에도 참 곱고 업계 전반에 널리 쓰이지 않는가. 어찌 마다하랴?
등골이 오싹해진다. 지옥에서 온 YAML 문서가 떠오른다. YAML의 기만적인 단순함에 대해 경고를 수도 없이 들었다! 선배들은 그것이 배신의 가면이라 했다. 그 뒤에는 어두운 존재가 도사리고 있으며, 가까이 가면 방심한 순간 당신의 영혼을 집어삼킬 거라고.
그럼에도… 이번만큼은 YAML이 실용적인 해법일 수 있지 않을까? 고작 작은 구성 파일 아닌가. 대체 뭐가 잘못되겠나? 소프트웨어의 신들이 이 대죄를 벌하진 않겠지? 쿠버네티스 같은 유명 프로젝트조차 YAML을 광범위하게 쓰는데, 어째서 거슬러 가라고 하겠는가?
떨리는 손으로 금단의 열매를 따서 한입 베어 문다. 즉각적인 생산성의 풍미가 입안을 가득 채우고, 선택에 대한 확신이 밀려온다. 애초에 왜 의심했지? 코드 몇 줄만 고치니 소프트웨어가 YAML 파일로 구성 가능해졌다. 도파민이 폭발하고, 프로젝트의 readme에 예제 구성까지 얹어 케이크에 아이싱을 바른다.
그러나, 겉보기 만족은 오래가지 않는다. 세월이 흐르며 입안의 달콤함은 쓴맛으로 바뀐다. 소프트웨어는 성장했고, 한때 단순하던 구성 파일은 이제 100줄이 훌쩍 넘는다. 그래, 그 파일은 _보기_에는 즐겁다. 하지만 _수정_하는 일은 참담하기 그지없다. 왜 선대의 지혜를 무시했단 말인가? 침묵 속에 잃어버린 순수와 인류의 타락을 애도한다.
아, 다시 시작할 수만 있다면.
이 이야기에서 당신의 모습을 보았는가? 나는 이 광경이 몇 번이고 되풀이되는 것을 보았고, 우리 업계가 처한 이 비참한 상황을 어느새 당연시하게 된 것 같다는 생각이 든다. 가끔 용감하고 고결한 이가 새로운 구성 언어를 제안하지만, 지금껏 대중적 채택에 성공한 예는 드물다. 대체 무엇이 문제인가?
내 눈에 문제의 핵심은 구성 언어의 선택(YAML 대 대안들)을 넘어선 지점에 있다. 우리는 구성이라는 문제 자체에 잘못된 출발점에서 접근하고 있고, 도구에 대한 기대치를 터무니없이 낮게 잡고 있다. 우리는 구성 파일이 사실상 사용자 인터페이스라는 사실을, 그리고 그렇게 취급해야 한다는 사실을 못 보고 있다.
구성 파일을 사용자 인터페이스로 보기 시작하면, 그것을 다루는 데 탁월한 사용자 경험을 요구하는 것이 비로소 말이 된다. 사용자 인터페이스의 요지는 소프트웨어를 더 접근 가능하게 만들고, 인간의 실수를 방지하며 사용자가 성공의 함정으로 자연스럽게 흘러들게 안내하는 데 있다. 특정 목표를 이루려 컴퓨터와 싸우는 느낌이 들 때 우리는 모두 나쁜 UX를 알아본다. 이상적인 세계에서 컴퓨터는 마음의 자전거처럼 방해하지 않고 인간을 강화해 준다.
“구성은 UI”라는 패러다임에 뿌리내린 도구를 쓴다면, 소프트웨어를 구성하는 일은 어떤 모습일까? 구성 작성과 유지보수가 기쁨인 생태계를 현실적으로 꿈꿀 수 있을까?
이쯤에서, 나는 완벽한 세계에서의 구성 방식에 대한 총론을 펼치고 싶은 유혹을 억누르려 한다. 대신, 내 눈에 “구성은 UI” 비전을 현실에서 훌륭히 구현한 오픈소스 프로젝트 하나를 소개하고 싶다. 바로 KSON이다. 수년의 준비 끝에 첫 공개 베타를 막 발표했다. 웹사이트를 둘러보거나, 곧장 온라인 플레이그라운드로 가도 좋다. 이 글에서 내가 뭐라 길게 쓰는 것보다 훨씬 더 잘 이해될 것이다. 항상 그러지 않던가. 보여줘라, 말하지 말고.
위 링크를 건너뛰고 싶은 분들을 위해, 베타 릴리스 공지에서 몇 문단을 짧게 인용한다.
사람이 YAML/JSON/TOML을 읽거나 편집하는 어디서든, KSON은 그 데이터에 더 효과적인 인터페이스가 될 수 있다.
꽤 대담한 주장이다! 하지만 그럴 만도 하다. 특히 이번 릴리스에 쏟아부은 막대한 작업량을 생각해 보면 더욱 그렇다.
KSON은 검증된 JSON 상위집합이며, 네이티브 JSON Schema 지원을 갖추고, YAML(주석 보존!)로 깔끔하게 트랜스파일되며, 당신이 원할 거의 모든 곳에서 사용할 수 있을 것이다—현재 지원 플랫폼: JS/TS, Python, Rust, JVM, Kotlin Multiplatform.
KSON은 또한 개발자 도구 전반에 널리 제공되며, VS Code, Jetbrains IDEs, 그리고 LSP를 꽂을 수 있는 어디서든 지원된다.
이 글 맨 끝의 부록에서 KSON 문서 예시를 볼 수 있다. 언어가 익숙하게 느껴질 것이고, 처음부터 훌륭한 편집 경험을 제공하도록 설계되었음을 알게 될 것이다. 또한 코드 에디터의 고급 언어 지원은 “구성은 UI” 패러다임의 훌륭한 사례라고 나는 본다. 문서를 죽은 텍스트 파일이 아니라 손끝에서 살아 움직이게 만든다.
정말 신선한 바람이다! KSON이든 다른 무언가이든, 사용자 친화적 구성이라는 비전이 시간이 지나며 계속 펼쳐지길 바란다. 우리 업계는 이제 최상급 구성 편집 경험을 제공하는 것이 정상이고 심지어 당연한 새 기준을 세워야 한다. 가능한 것이 너무도 많다1!
아직 명확하지 않다면, 나는 KSON에 대해 무척 열정적이다. 오픈소스 저장소를 방문하면 아마도 내 이름을 프로젝트의 기여자 목록에서 보게 될 것이다2. KSON의 기술적 공적 외에도, 그 동력에 감명받았다. 소수의 엔지니어 커뮤니티가 각오를 다지고, 인간을 최우선으로 둔 오픈 구성 도구를 빚어내고 있다. 저장소 태그라인에 쓰인 대로, 이는 정말로 “컴퓨터 구성을 유지보수하는 인간들에게 보내는 러브 레터”다.
나에게 KSON은 새로운 언어나 도구 모음 그 이상이다. “구성은 UI” 원칙에 기반한 개발자 운동을 부트스트랩하려는 시도다. 그 말에 공감한다면, 제발 이 노력에 함께해 달라! KSON을 한 번 써 보기만 해도 이미 훌륭한 출발이다. 마음에 든다면, 말이 되는 곳 어디에서든 사용해 보라. 마지막으로, 언제든 Zulip에서 우리와 대화하시길. 그곳에서 만나길 기대한다!
이 블로그 글은 프로젝트 이념에 관한 것이지 KSON 언어 자체에 관한 글은 아니지만, dbt 모델에서 파생한 작은 .kson 파일 예시를 하나 보자.
version: 2
models:
- name: my_transformation
description: 'This model transforms raw data'
columns:
- name: id
description: 'A unique identifier'
- name: name
description: 'The name of the item'
.
database: your_database
schema: your_schema
materialized: table
sql: %sql
SELECT
id,
name
FROM source_data%%
보시다시피 YAML과 맞먹는 가독성을 갖췄다. 내 기준으로도 훌륭한 특징이다! 하지만 더 중요한 점은 KSON이 고전적인 YAML의 지뢰들을 조심스럽게 피해 간다는 것이다. 그중 하나가 들여쓰기 처리다. 위 코드 조각은 문서의 구조가 한눈에 보이도록 들여쓰기를 했다. 그러나, YAML과 달리 “잘못된” 들여쓰기가 구성 파일을 망치지 않는다. 모든 줄의 앞쪽 공백을 지우거나 무작위로 섞더라도, 다음과 같은 일이 벌어진다.
여기서 바로 드러나지 않는 추가 기능 하나는, 내장된 SQL이 실제로 “살아있다”는 점이다. 올바르게 설정된 편집기는 그 부분을 단순한 여러 줄 문자열 이상으로 본다! 그것이 SQL임을 알고, 구문 강조, 검증, 그리고 코드 다룰 때 익숙한 온갖 좋은 기능을 제공해 준다.
더 많은 정보와, 브라우저에서 곧장 KSON을 가지고 놀 수 있는 공간은 공식 웹사이트를 참조하라.