브라우저용 LLM 앱에 S-expression DSL을 선택한 이유

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

브라우저에서 반복 실행 가능한 LLM 생성 mini-app을 만들기 위해 네 가지 실행 형식을 비교한 글입니다. Tool Calling은 turn-by-turn 호출에 묶이고 JSON UI Tree는 조건문을 문자열 템플릿으로 표현해야 하며 Raw JavaScript는 eval, fetch, DOM access 차단 부담이 생깁니다. 작성자는 zero capability에서 허용 기능만 추가하는 S-expressions 기반 Custom DSL을 선택해 UI elements와 loop·condition을 같은 구조에 배치했습니다. verbose JSON보다 token 수가 적어 latency와 cost를 줄일 수 있다고 했지만 구체적인 benchmark 수치는 제시하지 않았습니다.

주요 논점

01찬성소수

S-expressions는 control flow와 UI layout을 한 구조에 담아 LLM이 반복 실행 가능한 mini-app 코드를 만들기 쉽게 하고, verbose JSON보다 token·context 사용량도 줄일 수 있다는 입장입니다.

02찬성소수

zero capability에서 시작하는 Custom DSL은 Raw JavaScript의 전체 host capability를 사후 차단하는 방식보다 허용 동작을 좁게 관리하기 쉬워 보안 경계를 설계하는 데 유리하다는 입장입니다.

03중립소수

S-expressions의 latency·cost 이점은 구체적인 token 수나 benchmark가 제시되지 않아 가능성으로 남아 있으며, 실제 런타임의 안전성과 반복 실행성은 추가 검증이 필요하다는 입장입니다.

합의점 vs 논쟁점

논쟁점

Raw JavaScript의 높은 표현력과 Custom DSL의 제한된 capability 중 어느 쪽이 실제 mini-app 플랫폼에 더 적합한지는 런타임 요구사항과 보안 설계에 따라 달라집니다.
S-expressions가 JSON보다 token과 context를 얼마나 줄이는지는 글에서 정량 수치가 없어 객관적인 우위로 확정하기 어렵습니다.

실용적 조언

브라우저에서 LLM이 생성한 앱을 실행할 때는 전체 host capability를 먼저 제공한 뒤 차단하기보다 zero capability에서 시작해 필요한 동작만 allowlist로 추가하는 구조를 고려할 수 있습니다.
UI layout과 조건문·loop·이벤트를 별도 문자열 필드로 흩뜨리기보다 하나의 AST 또는 S-expression 구조에 통합하면 생성된 코드의 실행 흐름과 화면 요소 사이의 대응을 단순화할 수 있습니다.
Custom DSL을 선택할 때는 JSON schema 대비 실제 token 수, 생성 latency, 실행 반복성, eval·fetch·DOM access 차단 여부를 동일한 앱 사례로 측정해야 합니다.

섹션별 상세

작성자는 브라우저에서 직접 실행하고 반복적으로 생성·실행·공유할 수 있는 mini-app 플랫폼을 만들기 위해 Tool Calling, JSON UI Tree, Raw JavaScript, Custom DSL의 네 가지 실행 형식을 비교했습니다. Tool Calling은 host tool에는 맞지만 실행이 LLM의 turn-by-turn 호출에 묶여 반복 가능한 script에 부적합했습니다. JSON UI Tree는 시각적 구조를 잘 나타내지만 조건문을 문자열 템플릿으로 처리해야 했고, Raw JavaScript는 표현력이 높은 대신 eval, fetch, DOM access 같은 보안 탈출 경로를 차단하는 작업이 필요했습니다.

S-expressions 기반 Custom DSL은 zero capability에서 출발해 허용할 기능만 추가하는 방식으로 런타임의 권한 범위를 제한했습니다. 동시에 control flow와 UI elements를 같은 구조에 넣어 loop와 condition이 그것이 생성하는 시각 요소 옆에 배치되도록 했습니다. 이미지의 TRAID DSL 예시처럼 todo 목록의 필터링, urgent 상태에 따른 class 지정, 클릭 이벤트를 별도의 문자열 템플릿이 아니라 하나의 중첩 표현으로 구성합니다.

작성자는 JSON보다 S-expressions를 선택한 이유로 표현 통합과 token·context 효율을 들었습니다. verbose JSON schema보다 필요한 token 수가 일부에 그쳐 latency와 cost를 낮출 수 있다고 설명했지만, 구체적인 감소율이나 실행 성능 수치는 제시하지 않았습니다. 따라서 이 접근의 핵심 근거는 네 실행 형식의 구현 trade-off와 capability 제한 방식이며, 정량적인 비교 결과까지 확인된 상태는 아닙니다.

이미지 분석

Diagram
왼쪽 JSON UI Tree는 todo 목록의 source와 완료 여부 조건, urgent 상태에 따른 class, 클릭 이벤트를 중첩된 문자열 필드로 표현합니다. 오른쪽 TRAID DSL은 S-expression 안에서 todo 목록 반복, 완료 항목 제외 조건, urgent class, toggle 이벤트, label 출력을 하나의 실행 구조로 묶습니다. 이 비교는 Custom DSL이 UI 구성과 control flow를 동일한 문법으로 결합한다는 글의 핵심 근거와 직접 연결됩니다.
JSON UI Tree와 TRAID DSL의 코드 구조를 나란히 비교한 이미지입니다.

용어 해설

도구 호출(Tool Calling): — LLM이 매 대화 턴마다 호스트 도구를 호출하는 실행 방식입니다. 호출 흐름이 모델의 턴 단위 생성에 묶이므로, 브라우저에서 반복 실행할 mini-app의 독립적인 script 런타임으로 쓰기 어렵다는 한계가 있습니다.
JSON UI 트리(JSON UI Tree): — UI 요소를 JSON 계층 구조로 표현하는 방식입니다. 시각적 트리는 구성하기 쉽지만 조건문과 분기 로직을 문자열 템플릿에 넣어야 하므로, 실행 가능한 앱의 동작을 자연스럽게 표현하기 어렵습니다.
S-expression(S-expressions): — 괄호 기반의 간결한 구조로 데이터와 실행 로직을 함께 표현하는 표기법입니다. 이 글에서는 UI 요소와 loop·condition을 같은 구조 안에 배치하고, 허용된 기능만 추가하는 Custom DSL의 문법으로 사용합니다.
Custom DSL: — 특정 실행 환경에 필요한 기능만 제공하도록 설계한 전용 언어입니다. Raw JavaScript처럼 전체 host capability에서 출발해 보안 취약점을 차단하는 대신, zero capability에서 시작해 허용할 동작을 명시적으로 추가하는 방식입니다.

코드 예제

json

{
  "type": "list",
  "items": {
    "source": "todos",
    "when": "!item.done",
    "child": {
      "type": "row",
      "class": "{{item.urgent
        ? 'hot' : ''}}",
      "onClick": "toggle(item.id)",
      "value": "{{item.label}}"
    }
  }
}

JSON UI Tree에서 todo 목록과 조건부 표시, 긴급 항목의 class, 클릭 동작을 문자열 템플릿으로 표현한 구조입니다.

text

(ul
  (for [t todos
        :when (not (:done t))]
    (li {:class (when (:urgent t) "hot")
         :onclick #(toggle (:id t))}
      (:label t))))

S-expressions 기반 TRAID DSL에서 조건부 loop, UI 요소, class 지정, 클릭 동작을 하나의 코드 구조로 결합한 예시입니다.

언급된 리소스

문서We made the AI write in a language