이번 테마

Markdown이나 Mermaid와 같은 「그림이 되는 문자」를 LLM과의 공통 언어로 바라본다.

현장 메모

자연어뿐만 아니라 사람에게도 LLM에게도 다루기 쉬운 형태로 전달하면, 보이는 세계가 조금 변한다.

지난번에는 AI 시대의 문자 입력에 대해 썼습니다.

처음부터 깔끔한 문장을 쓰려고 하면 힘듭니다.

하지만 음성 입력으로 생각난 것을 대략적으로 내놓고, 나중에 AI와 함께 정리하면 입력 그 자체의 허들은 상당히 낮아진다는 이야기였습니다.

그 후, 저는 숙달을 위해 AI와의 상호작용을 계속해 왔습니다.

그러자 또 다른 의문이 생겼습니다.

우리는 평소 일본어나 영어와 같은 자연어로 AI에게 말을 겁니다.

하지만 AI와 인간 사이에 있는 표현 방법은 그것뿐일까요?

어쩌면 자연어 이외로도 가능하지 않을까.

아니, 오히려 자연어만으로 힘쓰는 것보다 AI에게도 인간에게도 다루기 쉬운 「문자의 형태」가 있는 것은 아닐까.

이번에는 그런 시행착오 속에서 발견한 「그림이 되는 문자」 이야기입니다.

최근에는 무엇이든 묶어서 AI라고 부르기 쉽지만, 이번 이야기에서는 대상을 조금 좁히겠습니다.

여기서 다루는 것은 ChatGPT, Claude, Gemini, Copilot과 같은 LLM입니다.

LLM은 Large Language Model, 일본어로는 대규모 언어 모델이라 불리는 것입니다.

대략 말하자면, 문장을 읽거나, 다음 내용을 생각하거나, 다른 형태로 바꿔 쓰는 메커니즘으로서 이해하고 있습니다.

지금은 이것을 「AI」로 인지하고 계시는 분들이 일반적이지 않을까요.

Language라고 하면 일본어나 영어를 떠올립니다.

그런데 실제로는 Markdown, JSON, Mermaid와 같은 정해진 형태의 문자열도 상당히 능숙하게 다룹니다.

인터넷상에도 이러한 형식의 데이터가 많기 때문에 학습도 진행되고 있는 것일지도 모릅니다.

특히 현재 AI와의 인터페이스의 주축인 Chat형 화면에서도, Markdown 표기법의 은혜를 자신도 모르는 사이에 입고 있는 경우가 있습니다.

제목, 글머리 기호, 표, 코드 블록.

어느샌가 AI의 답변은 상당히 Markdown스러운 형태로 정리되어 있습니다.

그렇다면 그중에서도 이번의 주인공이 될 Mermaid 표기법이란 도대체 어떤 것을 할 수 있는 것일까요?

어느 날, 업무 흐름을 정리하고 싶어져서 LLM에게 이렇게 부탁했습니다.

이 흐름을 그림으로 그려주세요.
접수 → 확인 → 답변

그런데 돌아온 것은 이미지가 아니었습니다.

돌아온 것은 다음과 같은 문자열이었습니다.

flowchart TD
A[접수] --> B[확인]
B --> C[답변]

처음에는 조금 당황했습니다.
그림을 부탁한 셈인데, 돌아온 것은 문자입니다.
「아니, 그림을 부탁했는데요……」라며 화면을 향해 작은 목소리로 중얼거렸습니다.
사무실에서 하면 조금 위험한 사람처럼 보일 수 있으니, 마음속으로 말하는 것을 추천합니다.
하지만 대응하는 프리뷰 환경에서 표시하면, 이것이 제대로 플로차트(flowchart)가 됩니다.

flowchart TD
A[접수] --> B[확인]
B --> C[답변]

기술자에게 확인하니, LLM이 그림 그 자체를 그리고 있다기보다, 그림으로 변환할 수 있는 텍스트를 출력하고 있다고 생각하는 편이 가까운 것 같습니다.

여기서 조금 즐거워졌습니다.

어쩌면 AI와의 교제 방식은 자연어로 「적당히 부탁합니다」라고 요청하는 것만이 아닐지도 모릅니다.

인간에게도 LLM에게도 읽히고, 화면에서는 그림이 되는.

그런 중간 표현이 있는 것은 아닐까, 라고 생각한 것입니다.

Qiita나 GitHub에서 기사를 읽고 계신 분이라면 Markdown은 친숙한 존재라고 생각합니다.

이 기사 자체도 Markdown으로 작성되었습니다.

Markdown에서는 제목, 글머리 기호, 표, 코드 블록 등을 문자로만 표현할 수 있습니다.

만약 Markdown을 단순한 문장 작성법으로만 보고 있다면, 조금 아까운 일일지도 모릅니다.

기술자에게 물어보니, Markdown에는 **코드 펜스 (code fence)**라고 불리는 메커니즘이 있어 그 안에 다른 표기법을 쓸 수 있다고 합니다.

코드 펜스는 백틱(backtick)을 3개 나열한 행으로 둘러싸는 작은 그릇 같은 것입니다.

예를 들어, 서두에 mermaid나 echarts와 같은 종류를 써 두면, 대응하는 애플리케이션에서는 다음과 같은 의미가 됩니다.

이 내용은 해당 표기법으로 읽어주세요.

기재 방법으로는 대체로 다음과 같은 형태입니다.

→``` [식별자 (Identifier)]
→여기에 각 표기법을 작성
→```

→는 행의 시작 위치를 나타냅니다. 이렇게 표현하지 않으면 표시할 수 없으므로 양해 부탁드립니다.

대표적인 식별자를 들자면 다음과 같은 것들이 있습니다.

모든 환경에서 동일하게 표시되는 것은 아니지만, "코드 펜스 (Code Fence)의 맨 앞에 쓰는 라벨"이라고 생각하면 이해하기 쉽습니다.

방금 LLM이 반환한 것은 Mermaid 표기법이라고 불리는, 텍스트로 도표를 그리기 위한 표기법입니다.

Markdown의 코드 펜스에 mermaid라고 지정하여 작성하면, 대응하는 환경에서는 플로우차트 등으로 표시할 수 있습니다.

단, 이용 중인 환경이 Mermaid 표시를 지원하지 않는 경우에는 그대로 텍스트로 표시됩니다.

같은 LLM의 출력이라도, 받는 화면이나 애플리케이션에 따라 "그냥 문자"가 될 수도 있고 "도표"가 될 수도 있다는 뜻입니다.

이 지점에서 저는 조금 생각했습니다.

LLM만 똑똑하면 되는 것이 아니라, LLM의 출력을 어떻게 보여줄지도 중요한 것이 아닐까?

수치 비교를 LLM에 맡기면 리스트 형태로 반환될 때가 있습니다.

A는 10, B는 20, C는 15입니다.

물론 읽을 수 있습니다.

읽을 수는 있지만, 한눈에 어떤 것이 더 큰지는 조금 알기 어렵습니다.

그럴 때, 대응하는 환경이라면 ECharts와 같은 표기법을 사용하여 그래프로 표시할 수 있습니다.

{
"title": { "text": "ECharts 입문 예시" },
"tooltip": {},
...

같은 데이터라도 불렛 포인트(Bullet point)로 보는 것과 막대그래프로 보는 것은 받아들이는 방식이 달라집니다.

숫자를 읽는 것에 능숙한 사람이 있는가 하면, 그래프로 보는 것이 한눈에 들어오는 사람도 있습니다.

서포트 센터나 현장 지원 업무에서도 이는 중요합니다.

정보가 올바를 뿐만 아니라, 사람이 이해하기 쉬운 형태로 전달되는가가 중요하기 때문입니다.

단, 여기에서도 주의할 점이 있습니다.

LLM과 받는 쪽의 애플리케이션이 모두 갖춰져야 비로소 이용할 수 있습니다.

같은 LLM을 사용하더라도, 접속하는 애플리케이션이나 표시 환경에 따라 할 수 있는 일이 달라집니다.

이 부분은 생각보다 큰 포인트였습니다.

필자의 환경에서는 사내 서포트 업무에도 관여하고 있는 "연결 AI"를 이용하기로 했습니다.

OSS(Open Source Software) 버전으로는 Dify라는 이름이 잘 알려져 있는 것입니다.

이 환경에서는 Markdown 및 각종 표기법 대응이 잘 되어 있고, 브라우저 상에서 완결되므로 별도의 설치도 필요하지 않았습니다.

물론 어떤 환경에서 무엇을 쓸 수 있는지는 조직이나 설정에 따라 달라집니다.

업무에서 이용할 경우에는 소속 조직의 규칙이나 이용 가능한 서비스 범위를 확인할 필요가 있습니다.

다만, 직접 시도해 보며 느낀 점은 다음과 같습니다.

LLM의 성능뿐만 아니라, LLM과 인간 사이에 있는 화면이나 애플리케이션도 상당히 중요하다.

이것은 현장에서 사용하는 입장에서는 놓칠 수 없는 포인트였습니다.

또 하나, 개인적으로 흥미로웠던 것이 ABC 기보법 (ABC notation) 입니다.

ABC 기보법은 악보를 텍스트로 표현하기 위한 기법입니다.

짧은 멜로디나 전통 음악의 악보를 글자만으로 쓸 수 있습니다.

처음 봤을 때는 솔직히 암호처럼 보였습니다.

C2 C2 G2 G2 | A2 A2 G4 |

"이것은 악보입니다"라고 들어도, 악보를 읽지 못하는 아저씨에게는 거의 고대 문자입니다.

하지만 대응하는 환경에서 열면 오선보로 표시됩니다.

예를 들어, ABC 기보법에서는 곡명, 박자, 키(Key), 음표의 나열 등을 텍스트로 작성합니다. 인간에게는 악보로 보이는 것을 LLM에게는 문자열로 전달할 수 있는 것입니다.

예시로, 이번에는 동요로 친숙한 "반짝반짝 작은 별"을 사용해 보겠습니다. 공개용 기사이므로, 여기서는 설명용 짧은 멜로디 예시로 다룹니다. 처음에는 그저 영숫자의 나열로 보이지만, 대응 환경에서는 악보로 읽을 수 있게 됩니다.

X:1
T:きらきら星
M:4/4
...

인간에게는 악보로 보이는 것을, LLM에게는 문자열로 전달할 수 있는 것입니다.

제 환경에서는 표시뿐만 아니라 재생까지 가능했습니다.

당연히, LLM의 작곡 센스를 이것저것 시험하며 놀아버렸습니다.

"이것은 검증입니다"라고 말하면서, 한동안 놀았습니다.

현장의 아저씨에게도 그런 날이 있습니다.

그 결과, 이렇게 생각하게 되었습니다.

클라이언트가 바뀔 뿐, LLM은 훨씬 더 다양한 것을 할 수 있는 잠재력(Potential)이 있는 것 아닐까?

LLM 활용에서는 GPT-◯◯와 같은 모델의 성능뿐만 아니라, 결과를 받아보는 화면이나 애플리케이션도 중요합니다.

LLM이 내놓은 텍스트를, 단순히 문자로 읽을 것인가.

그림으로 볼 것인가.

표로 볼 것인가.

악보로 볼 것인가.

같은 출력이라도 받아들이는 방식이 바뀌면, 인간에게 전달되는 정보량도 달라집니다.

악보를 읽지 못하는 저에게는 음표나 도레미의 나열을 봐도 곡의 뉘앙스는 알 수 없습니다.

하지만 대응 환경에서 재생할 수 있다면, "아아, 이런 느낌이구나"라고 알 수 있습니다.

즉, LLM과 인간 사이에 있는 표시 환경은 단순한 덤이 아닙니다.

오히려 현장에서 이해하기 쉽게 만들기 위한 중요한 다리(Bridge)라고 생각합니다.

여기까지 시도해 보고 나서야 겨우 조금 납득이 갔습니다.

LLM에게 "그림을 그려줘"라고 부탁했다고 해도, 실제로 돌아오는 것은 그림 그 자체가 아니라 그림이 되는 문자입니다.

인간은 자연어(Natural Language)로 부탁합니다.

LLM은 그 내용을 Mermaid나 ABC 기보법 같은 텍스트 기법으로 변환합니다.

마지막으로, 표시 측 애플리케이션이 그것을 그림이나 악보로 보여줍니다.

즉, 자연어로 주고받을 수 있다는 점은 LLM의 큰 매력입니다.

다만, 그것에만 매달릴 필요는 없을지도 모릅니다.

인간도 읽을 수 있고, LLM도 다루기 쉬우며, 화면에서는 그림이나 악보가 되는 중간 표현.

이것을 활용하지 않을 이유가 없습니다.

전문가에게는 당연한 일일지도 모릅니다.

하지만 현장에서 사용하는 입장에서는 이 관점이 꽤 큰 발견이었습니다.

AI에게 전부 떠넘기기보다, 조금 다가가서 공통 언어로 다루기 쉬운 형태로 전달해 주는 것.

그렇게 하면 훨씬 더 다양한 일을 할 수 있게 될지도 모릅니다.

여기서 중요한 것은, LLM이 대단하다는 이야기만으로 끝내지 않는 것이라고 생각합니다.

LLM이 Mermaid를 쓸 수 있다.

ABC 기보법을 쓸 수 있다.

Markdown 안에 이것저것 넣을 수 있다.

그 자체도 흥미롭지만, 현장에서 중요한 것은 그 결과를 사람이 알기 쉽게 받아들일 수 있느냐입니다.

단순한 문자열로 보면 이해하기 어려운 것이라도, 그림이 되면 흐름이 보입니다.

표가 되면 비교할 수 있습니다.

악보가 되면 소리의 이미지가 떠오릅니다.

LLM의 출력을 사람이 이해하기 쉬운 형태로 변환할 수 있다면, 그것은 현장에 도움이 됩니다.

그 너머에 있는 것은 AI를 돋보이게 하는 것이 아닙니다.

사람이 망설임 없이 사용할 수 있는 것.

업무 속에 자연스럽게 녹아드는 것.

이 연재의 구호로 말하자면, 다음과 같습니다.

AI 좋음: LLM이 텍스트 기법을 만들 수 있음 -
사람 좋음: 사람이 그림이나 표로서 이해하기 쉬워짐 -
현장 좋음: 업무 흐름이나 설명에 얹기 쉬워짐

Markdown이나 Mermaid와 같은 기법은 단순한 잔기술이 아닙니다.

LLM을 현장에 가깝게 만들기 위한 가교 역할도 할 수 있을 것 같습니다.

여기까지 오니 LLM이 꽤 편리해 보입니다.

자연어로 부탁하면 그림이 되는 문자나, 악보가 되는 문자까지 써줍니다.

그렇다면, LLM에게 전부 맡기기만 하면 되는 걸까요?

실제로 계속 사용하다 보면, 다음에는 또 다른 벽에 부딪히게 됩니다.

어제는 잘 되었는데, 오늘은 조금 다르다.

방금 전까지는 알고 있었을 텐데, 전제(Premise)가 어긋난다.

"아니, 방금 말씀드렸잖아요?"라고 화면을 향해 말하고 싶어지는 순간이 생깁니다.

다음 회차에서는 LLM이 의외로 잘 잊어버리는 것처럼 보이는 이유, 즉 스테이트리스 (Stateless)나 컨텍스트 (Context)에 관한 이야기로 넘어갑니다.

• 연재 톱
• 지난 회: 제1화 「AI 시대의 문자 입력은, 『정확하게 질문해야 해!』를 버리는 것부터 시작된다」
• 이번 회: 제2화 「어떤 현장의 아저씨, 그림이 되는 문자를 만나다」
• 다음 회: 제3화 「어떤 현장의 아저씨, LLM은 의외로 건망증이 심하다는 것을 알게 된다」