【Skill 배포 있음】 중간 표기 패턴(MNP)에 관하여 — 어떤 도구든 간단·초고속·안정적으로 AI화하는 내부 구현 방법

3줄 요약

1. 일본의 디자이너·리서처 なつ(@Dia_Nexus)가 자기 업무용 인하우스 웹 앱을 AI화하는 새 패턴으로 정리한 *중간 표기 패턴(Middle Notation Pattern, MNP)*의 소개·구현·고찰 글이다.
2. 핵심 발상은 단순하다 — AI에게 GUI를 직접 조작시키는 대신, GUI 상태와 동등한 텍스트 DSL을 두고 AI가 그 DSL을 양방향으로 읽고 쓰게 한다. Mermaid가 텍스트로 도형을 그리던 것과 같은 결의 응용이다.
3. 결과적으로 출력이 안정되고, 처리가 빨라지고, API 비용은 4~8배 떨어지고, HTML 한 장으로 배포된다. 다만 상태가 비대화되면 컨텍스트 한계에 부딪힌다.

글의 청중 — 자기 업무 도구를 굴리는 사람

본문에 들어가기 전에 한 가지 자리잡아 두면 글이 또렷해진다. 글에서 말하는 자작 도구가 다소 추상적으로 들리지만, 저자가 보여 주는 사례들을 보면 의미는 분명하다. 서비스 에코시스템 에디터, 디렉터를 위한 게임형 사내 연수, 노션에 글을 쓰면 곧장 기사가 되는 CMS, ‘세계에서 가장 빠른 태스크 관리 툴’ — 전부 디자이너·리서처가 자기 메서드와 업무 일부를 굳혀 둔 인하우스 웹 앱이다.

그래서 이 글의 청중은 풀스택 개발자가 아니라, 자기 방법론·업무를 가벼운 웹 도구로 만들어 쓰는 사람이다. 그 도구에 AI를 얹어 동료에게도 돌리고 싶은데, 사내 보안·배포 절차·풀스택 인력이 발목을 잡는 자리에 있는 사람. 어떤 도구든 간단·초고속·안정적으로 AI화한다는 부제도 그 자리에서 읽힌다 — 대규모 SaaS가 아니라, 소수가 만들어 소수가 쓰는 인하우스 도구의 AI화. 이어지는 기존 AI 도구화 시도 평가도 모두 이 시선에서 이뤄진다.

출발: 기존 AI 도구화 방식의 한계

자기 업무용 인하우스 웹 앱을 AI화하려는 시도는 그동안 네 갈래로 나뉘어 있었다.

저자는 네 갈래가 모두 일정한 한계에서 막힌다고 본다. 그래서 다섯 번째 길을 찾는다.

핵심 발상: GUI가 아니라 의미 상태를 다루게 하라

대전제 한 줄. LLM은 GUI에 약하고 텍스트에 강하다. 그러니 ‘AI에게 GUI를 잘 조작시키는 방법’을 찾는 노력 자체가 방향이 틀린 노력이다.

저자의 발상은 이렇다 — 기존 도구를 AI에게 조작시키지 말고, 애초에 AI가 조작하기 쉬운 도구를 만들자. 화면 뒤의 의미 상태를 AI가 읽고 쓰기 쉬운 텍스트 표현(DSL)으로 두고, AI와 애플리케이션 사이에 가벼운 상태 조작 프로토콜을 끼워 넣는다. 새로운 기술이 아니라 낡은 기술들의 조합이지만, LLM 맥락에서 이걸 명시적으로 한 사례가 드물다고 한다.

Mermaid의 교훈

Mermaid가 최근 몇 년간 AI 업계에서 폭발적으로 쓰인 건 우연이 아니다.

graph LR
  A[유저] --> B[서비스]
  B --> C[결제]

이런 텍스트로 도형을 그릴 수 있는 도구다. SVG·Canvas 좌표를 직접 쓰게 하는 것보다 ‘graph LR / A –> B’ 같은 텍스트 DSL을 쓰게 하는 쪽이 압도적으로 빠르고 안정적이기 때문에 AI와 잘 맞는다. 구문이 단순하고 출력이 일의적이라는 게 핵심 — AI에게 다루기 쉬운 중간 표현이 있으면 출력이 안정된다.

저자는 여기서 한 걸음 더 나간다. 내 기법에 맞춘 내 DSL과, 그 DSL을 읽고 그림을 그려 주는 파서를 직접 구현하면, Mermaid와 같은 일을 내 도구에서도 할 수 있지 않을까. 게다가 흥미로운 자기 고백 한 줄이 따라온다 — 나는 DSL을 설계하지도 작성하지도 않는다. DSL 설계도 AI가, DSL 작성도 AI가 한다. 사람은 도메인 개념만 설명한다. 저자 본인도 자기 도구의 DSL 내부 구문 절차를 다 모른다고 한다.

MNP의 구조 — 4요소 + 양방향 루프

MNP의 기본 구조는 네 가지 요소로 정리된다.

1. DSL (記法) — 해당 도메인 고유의 텍스트 표현. 예를 들어 서비스 에코시스템에서는:

   actor USER "유저" teal person
   actor SVC "서비스" violet platform
   
   USER -> SVC "이용"
   SVC --> USER "가치 제공"
   

   이런 식이다.

2. 파서(parse) — 표기 텍스트 → 내부 데이터 구조 변환. parseNota(text) 같은 함수.

3. 시리얼라이저(serialize) — 내부 데이터 구조 → 표기 텍스트 역변환. GUI에서 편집한 뒤 표기로 되돌리는 데 필요.

4. 시스템 프롬프트 — AI에게 DSL의 구문 규칙과 기법의 판단축(좋은 결과물의 기준)을 알려 주는 지시문. 여기에 ‘도구의 혼’이 담긴다.

그리고 이 네 요소를 묶어 도는 한 줄짜리 루프가 MNP의 핵심이다.

serialize() → 시스템 프롬프트에 현재 상태 임베드 → AI가 상태를 알고 응답 → <notation>을 포함한 구조화 응답 반환 → parseNota() → applyParsed() → 재렌더 → 다시 serialize()

GUI를 사람이 직접 만져도 시리얼라이저가 곧장 텍스트로 환원하므로 자동으로 양방향 동기가 보장된다. ‘AI가 항상 지금의 상태를 알고 대화하는’ 감각이 여기서 나온다.

안정성과 비용이 어디서 나오는가

저자는 AI 응답의 한 토막을 직접 보여 준다. 사용자가 ‘행정이라는 노드를 추가했습니다. 다른 필요한 노드도 생각해서 도입해 주세요’라고 지시하면 AI가 자연어 응답에 더해 <notation> 블록으로 도면 전체를 다시 써서 돌려준다.

<notation>
# Service Ecosystem

actor O "고양이 카페 운영" teal store
  role: 카페 운영·관리·고양이 케어
...

O -> C "치유 공간 / 음료·간식"
C -> O "이용 요금"
...

layout
O 400 200
C 946 296
...
</notation>

여기서 두 가지 관찰이 떨어진다.

(1) MNP는 사실상 ‘AI가 다루기 쉬운 임베디드 DB’다. 텍스트가 곧 스키마이자 데이터다. 읽기 = parseNota, 쓰기 = serialize(). 사람도 읽을 수 있는 텍스트 스키마라서 AI는 자연어의 연장선에서 조작할 수 있다. 충분히 가벼우니 프롬프트에 통째로 실어 보낼 수 있다.

(2) 안 만진 부분은 좌표까지 그대로 보존된다. AI는 자연어·HTML 같은 자유 형식의 조작에는 약하지만 ‘이미 정해진 표기의 일부만 손대기’는 잘한다. 매 호출마다 전체 상태를 받아서 통째로 다시 출력하는 구조이기 때문에, 손대지 않은 노드는 정확히 같은 자리에 남는다. ‘작업한 부분만 바뀌고 나머지는 안 바뀌는’ 자연스러운 편집감이 여기서 나온다.

비용 측면에서도 차이가 크다. AI API는 보통 출력 토큰이 입력 토큰보다 5배가량 비싸다. MNP는 매번 HTML 통째로 다시 쓰는 방식 대비 출력이 5,000~10,000 토큰에서 약 900 토큰 수준으로 줄어든다. Sonnet 4.6 기준 회당 12~22엔 → 3엔 수준. 통상 4~8배 저렴해진다.

저자는 3월에 10달러 크레딧을 넣고 200회 가까이 도면을 생성했는데도 다 못 썼다고 한다. (참고로 프롬프트 캐시는 노트 글 기준 일정 크기 이하라 적용되지 않는다고 한다.)

3가지 구현 패턴

MNP는 세 형태로 구현할 수 있다.

세 패턴 중 저자가 AI-DX 업계의 혁명이라 부르는 건 시스템 프롬프트형이다. 도구가 LLM API를 직접 호출할 필요가 없어, ‘도구는 납품할 테니 시스템 프롬프트는 자사 보안 AI에 붙여 쓰세요’ 식의 전개가 가능하다. API 키도 서버도 IT 심사 레이어도 필요 없다. M365 Copilot만 허용하는 대기업에서도 도입할 수 있고, 단일 HTML로 메일 첨부 배포까지 된다.

권장 구현 절차 — AI화는 마지막에

저자의 경험칙은 *‘AI화는 맨 나중’*으로 요약된다.

1. 만들 도메인의 개념을 AI에게 충분히 이해시킨다. 예: 서비스 에코시스템이 무엇이고, 어떻게 그리고, 무엇이 좋은 결과물인가. Why에 가깝다.
2. 그 개념을 HTML 등으로 재현시킨다. 이 시점에 좋은 결과물이 안 만들어지면 AI화해도 좋아지지 않는다.
3. 사람이 직접 쓸 수 있는 에디터로 다듬는다. AI 없이도 작업이 되는 도구를 먼저 완성한다.
4. 그제야 AI에게 ‘MNP화해 줘’를 부탁한다. 사양 설명까지 일일이 적을 필요 없이, 샘플 HTML과 Claude Skill을 같이 넘기면 AI가 알아서 한다고 한다.¹

좋은 도구가 먼저, AI화는 나중. 좋은 도구가 안 만들어지면 AI화로 좋아지지 않는다는 결론이다.

메리트와 한계

저자가 정리한 7가지 메리트와 2가지 한계.

메리트

• 출력 안정성 — 매번 같은 입력 → 흔들림이 적다.
• 속도 — 브라우저 파싱 즉시 렌더, API 미경유.
• 양방향성 — GUI 편집과 DSL 편집이 자동 동기.
• 스냅샷 — 텍스트 상태이므로 되돌리기/저장/공유가 단순(드라쿠에의 ‘부활의 주문’ 같은 것).
• 배포 — HTML 한 장으로 끝, 서버리스·로그인 불필요, 어떤 AI 프로바이더에도 묶이지 않음.
• 컴플라이언스 — API 키 불필요, 사내 허용 LLM만 있으면 됨, 배포가 IT 심사 없이 통과.
• API 비용 — 일반적인 방식 대비 통상 4~8배 저렴.

한계

• 상태 비대화 — 프롬프트에 임베디드 DB를 통째로 싣는 구조라 도구가 커지면 컨텍스트 윈도우를 넘긴다. 5,000자에서 트림 처리 시작이 권장.
• 기존 제품에 뒤늦게 끼워 넣기 어려움 — 이미 굴러가는 앱에 MNP를 덧대려면 상태 정의부터 다시 해야 해서 사실상 대대적인 개편 작업이 된다. 신규 설계 시 전제하는 게 자연스럽다. 대규모·동시 편집·권한 관리가 본질이라면 보통 SaaS로 가는 게 옳다.

응용과 구현 디테일

응용은 세 갈래다.

• 내부 처리 임베드 — 게임형 연수처럼 AI가 말풍선 UI를 조작하는 게 아니라 말풍선의 표기와 문언을 반환하는 형태. DSL + 파서 + 시스템 프롬프트 3종 세트를 제품 내부에 끼워 넣으면 상당히 많은 제품을 AI화할 수 있다.
• DB 영속화 — 표기 텍스트를 그대로 컬럼에 저장하고, 꺼낼 때 파싱. 백엔드와 붙여도 그대로 쓸 수 있다.
• 다차원 배열 표기 — 현행 MNP는 본질적으로 스칼라형(1 텍스트 = 1 스냅샷). @who[customer] @step[reservation] 같은 다차원 라벨 표기로 확장하면 같은 프롬프트 안에서 표현 가능한 상태 조합이 기하급수적으로 늘어난다. 일괄·횡단 조작도, 스프레드시트 호환도, 공백을 정보로 쓰기도 가능해진다. 다만 표기가 압축될수록 가독성은 떨어진다.

마지막으로 저자가 실패를 정리해 둔 구현 디테일 6가지가 부록처럼 붙어 있다.

1. 중간 표기(MNP) 코드 블록이 아니라 <message>/<notation> 같은 XML 태그로 출력 — 정적 파싱이 훨씬 안정적이다. “이 태그 외에는 출력하지 마” 시스템 프롬프트도 같이.
2. 편집 키워드(“추가/수정/삭제”)는 Sonnet, Q&A는 Haiku로 모델 분기. ‘실패 시 상위 모델 재시도’는 두 번 호출이 되어 70초까지 갔다고 한다.
3. DSL이 5,000자를 넘으면 오래된 부분부터 트림.
4. 타임아웃은 90초 정도가 안전. 큰 DSL은 Sonnet 생성에 60초 가까이 걸린다.
5. 대화 이력은 20건/8,000자를 넘으면 오래된 2건씩 트림.
6. Cmd+Enter 전송 + !e.isComposing으로 IME 변환 중 오송신 방지. 일본어·한국어 사용자에게는 거의 필수에 가까운 디테일.

가장 흥미로운 지점

가장 인상 깊은 건 세 가지였다.

하나는 ‘사람은 도메인 개념만 설명하고, DSL 설계도 작성도 AI에게 맡긴다’는 분업이다. AI 도구화의 통상적인 분업선 — 사람이 형식을 정하고 AI가 내용을 채운다 — 을 한 칸 더 위로 옮긴다. 형식까지 AI에게 위임하고, 사람은 도메인 개념을 잘 설명하는 능력에 집중한다. 저자 본인이 자기 도구의 DSL 내부 구문을 다 모른다는 고백이 이걸 가장 적나라하게 드러낸다.

둘째는 이 분업선이 ‘AI 코딩’ 영역에서 이미 정리되어 있는 통찰과 정확히 같은 결이라는 점이다. *명세-주도 개발(Spec-Driven Development)*이 그 이름이다. Eno Reyes는 코드란 명세의 손실 투영이며 명세야말로 1급 산출물이라 정리했고, Sean Grove는 명세 하나를 모델에 넘기면 TypeScript·Rust·서버·클라이언트·문서가 줄줄이 컴파일된다고 말한다. Brendan Falk의 AI 코딩 10원칙도 같은 줄에 선다 — “You = Architect, Agent = Implementer”, “Specification ≫ Prompt Engineering”. 사람이 의도와 구조를 가지고, AI가 형식과 구현을 만든다는 한 줄이다.

MNP는 이 명제의 도구 제작 차원 변주다. 통상의 spec-driven은 코드 생성 단계의 분업을 말한다. MNP는 거기서 한 칸 더 내려가 도구가 다룰 상태의 표현 형식 자체도 AI에게 맡긴다. 사람은 “서비스 에코시스템이 무엇이고, 어떻게 그리고, 무엇이 좋은 결과물인가"라는 도메인 명세만 또렷이 한다. DSL의 구문은 AI가 빚는다. 그래서 저자의 권장 절차 — 개념 이해 → HTML 재현 → 에디터화 → MNP화 — 가 spec-driven의 결과적 논리와 정확히 같은 모양이 된다. 명세(도구의 본질)가 단단하지 않으면 AI화는 그 위에서 같이 흔들린다.

셋째는 시스템 프롬프트형이 만드는 ‘AI 없는 AI 도구’ 배포 방식이다. 도구 자체는 LLM 호출을 하지 않고, 사용자가 자기 회사 보안 AI에 시스템 프롬프트를 붙여 쓰면 작동한다. API 키도 서버도 IT 심사도 필요 없는 단일 HTML 첨부 배포 — 이건 단순한 비용 절감이 아니라 대기업 컴플라이언스 우회로 자체를 새로 그어 준다. AI-DX 업계의 ‘M365 Copilot만 허용한다’는 벽을 옆구리에서 우회하는 길이다.

물론 본문이 강조하듯 한계도 있다 — 도구가 커지면 컨텍스트가 무너지고, 기존 제품에 뒤늦게 끼워 넣는 일은 사실상 대대적인 개편 작업이 된다. 그러나 개인·소팀이 자기 기법·업무 일부를 AI화하는 규모에서는 비용·속도·배포 셋 다에서 보통의 구현을 압도한다는 저자의 단언은, 사례 영상과 데모 페이지(mnp-demo.vercel.app)를 같이 보면 과장으로 들리지 않는다.

출처

• 저자: なつ (생활자/디자이너/리서처) — note @art_reflection, X @Dia_Nexus
• 게시일: 2026년 5월 24일
• 원문: https://note.com/art_reflection/n/nccfe6cc57073