지난 제5회 「AI는 『답을 가지지 않은 상사』를 구할 수 없다」에서는, 최신 추론 AI에 「1%의 명확한 목표와 의도」를 부여함으로써 수천 번의 추론을 통한 막대한 복리 효과가 발생한다는 점과, AI 활용이란 「최소 부서의 매니지먼트」라는 점을 해설했습니다.

하지만 AI가 아무리 훌륭한 제안이나 구성안을 뇌내에서 구축하더라도, 그것을 「인간이 다루기 쉬운 형태」로 현실 세계에 출력할 수 없다면, 결국 복사 붙여넣기와 미세 조정의 지옥이 기다리고 있습니다.

이번에는 AI의 1만 번의 추론을 낭비하지 않기 위한 「출력 프로세스의 구조화」와, 제가 현장에서 도달한 「탈 파워포인트(PowerPoint)·탈 Mermaid」 생존 전략에 대해 해설합니다.

이 기사에서는 AI가 생성한 고품질 텍스트를 불필요한 레이아웃 작업 없이 최종적인 자료(매뉴얼이나 설계서)로 떨어뜨리기 위한 「프로세스 분할」과 「Web 기술의 활용」에 대해 해설합니다.

대상 독자: AI를 사용하여 업무 자료, 요구 정의서, 매뉴얼 등을 작성하는 모든 엔지니어, PM
다루는 기술 스코프: 프롬프트 분할(Chain), Markdown, Notion, HTML/SVG/Tailwind CSS
전제 지식: 기본적인 HTML 구조를 알고 있을 것. AI의 Canvas(또는 Artifacts) 기능을 사용해 본 적이 있을 것.

AI에게 갑자기 「완성된 레이아웃의 자료」를 만들게 해서는 안 된다. 문장의 퇴고(추론)와 장식(디자인) 프로세스를 완전히 분할하여, AI의 뇌 메모리(토큰)를 절약하라.

「이 업무 플로우를 바탕으로, 초보자용 완벽한 매뉴얼을 HTML로 만들어줘!」

AI에게 일을 시킬 때 가장 저지르기 쉬운 「한 번에 끝내려고 하는」 프롬프트입니다. 하지만 이에 대한 AI의 출력은 종종 「문장이 얕다」, 「중요한 설명이 빠져 있다」와 같은 결과로 이어집니다.

왜일까요? 그것은 AI가 「제목의 HTML 태그는 어떻게 할까」, 「CSS 클래스 이름은 무엇을 적용할까」와 같은 레이아웃 계산에 사고 리소스(토큰)를 빼앗겨, 정작 중요한 「문장을 알기 쉽게 만드는 추론」에 힘을 쓸 수 없게 되기 때문입니다. 인간도 디자인 도구를 만지면서 완벽한 문장을 생각하는 것은 매우 어려운 일이죠.

AI의 사고 리소스를 최대화하기 위한 출력 프로세스의 의사결정입니다.

선택지 A: 프롬프트로 「문장의 질」과 「디자인 규칙」을 모두 상세히 지정한다 (기각)-
이유: 한 번의 프롬프트로 지시하는 요구사항이 너무 많으면 AI의 컨텍스트(문맥)가 산만해져서, 둘 다 어중간한 퀄리티가 되기 때문.

채택안: 「의도 공유·구성안 (평문)」 작성과 「디자인 (장식)」 프로세스를 2단계로 분할한다-
이유: 첫 번째 단계에서 AI를 「문장의 내용 (추론)」에만 집중시킨다. 내용에 대한 합의가 이루어진 후, 다음 단계로서 「단순한 변환 작업 (디자인)」을 시킴으로써 최고 품질의 성과물을 최단 시간에 얻을 수 있기 때문.

한 번에 출력하게 하는 것이 아니라, 대화를 통해 프로세스를 분할하는 예시입니다.

// ❌ 나쁜 예 (AI의 토큰을 디자인에 낭비하게 함)
「다음 메모를 바탕으로, 멋진 디자인의 HTML 매뉴얼을 한꺼번에 작성해줘.」
// ⭕ 좋은 예 (Step1: 우선 평문으로 내용에만 집중하게 함)
...

🔰

초보자용 해설: 토큰과 추론의 트레이드오프(Trade-off)란?

초일류 프랑스 셰프(AI)에게 「최고의 풀코스를 만들어줘」라고 부탁하는 것이 평문 지시입니다. 반면, 「최고의 풀코스를 만들면서, 다이닝 테이블도 나무를 깎아서 직접 만들어줘」라고 부탁하는 것이 갑자기 HTML을 만들게 하는 지시입니다. 셰프에게 목공 일(태그 계산)을 시키면 요리(문장)의 맛이 떨어지는 것은 당연하겠죠.

AI와 인간이 「내용에 대한 합의」를 이루기 위한 중간 포맷으로서 Markdown(평문)은 최적이다. 그리고 그것을 압도적으로 보기 쉽게 관리할 수 있는 도구가 Notion이다.

전장에서 「우선 평문(Markdown)으로 만들게 하라」고 말씀드렸지만, AI 채팅 화면에 흘러나오는 방대한 텍스트는 읽기 어렵고, 인간이 「이 부분을 조금 고치고 싶다」고 생각했을 때 손대기가 어렵다는 문제가 있습니다.

Word나 Google Docs에 붙여넣으면, 이번에는 Markdown 기호(#나 *)가 그대로 표시되어 버려, 보기 좋게 정리하기 위해 다시 수작업으로 「제목 설정」이나 「굵게 설정」을 해야 합니다. 이는 본말전도입니다.

인간이 AI의 출력 결과(중간 생성물)를 빠르게 리뷰하고 수정하기 위한 환경 선택입니다.

선택지 A: 출력된 Markdown을 전용 에디터(VS Code 등)로 관리한다 (보류)
이유: 엔지니어에게는 좋아도, 비엔지니어 멤버(PM이나 디렉터)에게는 진입 장벽이 높고, 팀 전체의 공유나 공동 편집에는 적합하지 않기 때문.

채택안: AI에게 Canvas로 출력하게 하고, 리뷰 후에는 「Notion」으로 복사/붙여넣기 한다
이유: 친구가 사용해보고 편리하다고 알려준 「Notion」은 Markdown과의 궁합이 이상할 정도로 좋은 툴입니다. AI가 출력한 Markdown을 그대로 복사/붙여넣기 하는 것만으로, 순식간에 아름다운 제목(Heading)이나 표로 변환됩니다. 인간 측에서의 미세 수정도 매우 간단하여, 「AI와의 협업」에 최적화된 캔버스가 됩니다.

제가 일상적으로 사용하고 있는, Notion을 전제로 한 AI와의 대화 플로우입니다.

// 1. AI에게 지시 (먼저 Markdown으로 뼈대와 내용을 다진다)
「신규 시스템의 요구사항 정의 초안을 작성합니다.
상세하고 구체적으로 .md 형식으로 출력해줘! Canvas에 출력해줘!」
...

🔰

초보자를 위한 해설: Markdown과 Notion의 관계란?

Markdown은 「레고 블록의 설계도」와 같습니다 (여기는 제목, 여기는 리스트라고 글자 옆에 기호를 쓰기만 하면 됩니다). 그리고 Notion은 그 설계도를 흘려 넣으면 순식간에 「알록달록한 레고 성」을 자동으로 조립해 주는 마법의 테이블입니다.

내용이 확정된 후의 최종적인 자료화 단계에서, 파워포인트(PowerPoint)나 Mermaid는 「불필요한 요구사항」이나 「호환성의 함정」을 낳습니다. Web의 힘을 빌린 「HTML + Tailwind CSS + SVG」로의 출력이 가장 안정적이며 유지보수성이 높습니다.

Notion에서 내용이 확정되었습니다. 「좋아, 이걸 고객 제출용(혹은 전사 공유용)의 깔끔한 자료로 만들자」라고 되었을 때, 많은 사람이 직면하는 지옥이 있습니다.

「파워포인트(슬라이드) 지옥」

A4나 슬라이드 틀에 예쁘게 맞추기 위해, 글자 크기를 0.5pt씩 깎거나 도형을 밀리미터 단위로 움직이는 무의미한 시간.

「Mermaid(도해 생성)의 함정」

AI에게 「플로우차트를 Mermaid 형식으로 써줘」라고 부탁하면 편리하지만, 막상 프리뷰어(Previewer)나 다른 툴에 붙여넣으면 「버전 차이로 인해 렌더링 (Rendering) 에러가 발생하여 화면이 하얗게 변해버리는」 호환성 문제가 빈번하게 발생합니다.

내용이 확정된 후의 「최종 디자인·포맷」에 대한 기술 선정입니다.

선택지 A: PowerPoint로 출력하게 하거나 (매크로 등), 또는 Mermaid를 사용한다 (보류)
이유: 파워포인트는 「틀에 맞추기」라는 AI가 가장 어려워하는 공간 인식이 필요하며, 인간 측의 수정 비용이 높습니다. Mermaid는 환경 의존도가 높아, 몇 년 후에 볼 수 없게 될 리스크가 있습니다.

채택안: 최종 출력은 「HTML 파일 (Tailwind CSS + SVG)」 한 길뿐이다
이유: Web에 강한 멤버와 이야기하며 깨달았습니다. HTML이라면 틀의 제한이 없고, 어떤 OS·브라우저에서도 안정적으로 읽을 수 있으며, 글자 확대/축소도 자유자재입니다. 게다가 PDF화도 간단합니다. 그리고 무엇보다 Tailwind CSS와 SVG의 조합이라면, AI는 환경 의존성 없는 그래픽적이고 아름다운 도표나 레이아웃을 매우 안정적으로 작성해 줍니다.

Notion(또는 Canvas)에서 내용이 확정된 후에, AI에게 던지는 「마무리 프롬프트」입니다.

// 내용(추론)에 대한 합의가 이루어진 후, 마지막으로 던지는 프롬프트
「내용은 이쪽에서 수정하여 완성했습니다.
이 내용을 HTML 형식의 자료로 만들어줘!
...

🔰

초보자를 위한 해설: 왜 HTML과 Tailwind인가?

파워포인트 자료가 「얼음 조각」이라면, HTML은 「물」입니다. 얼음은 글자가 조금만 늘어나도 틀(컵) 밖으로 넘쳐서 다시 깎아야 하지만, 물(HTML)은 스마트폰이든 거대 모니터든 그릇에 맞춰 자동으로 유동합니다. Tailwind는 그 물에 순식간에 예쁜 색을 입히는 마법의 입욕제 같은 것입니다.

이번에 소개해 드린 것과 같은 「AI에게 지시를 내리기 위한 짧은 프롬프트」 속에는, 사실 무수한 「아키텍처 선정 이유」가 담겨 있습니다.

왜 Markdown인가? 왜 Notion인가? 왜 Mermaid를 금지하고 Tailwind CSS를 선택하는가?

그것은 우리가 지금까지 직면해 온 「AI의 한계와 이면의 구조」를 알고 있기 때문입니다.

돌이켜보면, 지금까지의 연재에서 이야기해 온 진흙탕 같은 고생은 모두 지금의 프롬프트나 기술 선정의 근간으로 이어져 있습니다.

제4회 「Attention 메커니즘 (Attention Mechanism)과 토큰 (Token)의 제약」

AI가 어떻게 문맥을 파악하고 메모리(토큰)를 소비하는지 알고 있었기에, 디자인과 추론 프로세스를 분리하기로 결정할 수 있었습니다.

제3회 「왜 AI 개발은 지옥인가?」 - 「끝없는 데이터 클렌징 (Data Cleansing)」
AI의 답변 정밀도는 RAG의 「청크 분할 (Chunking)」에서 9할이 결정됩니다. PDF 텍스트 추출 등, 투박한 정규 표현식과 파서 (Parser) 튜닝으로부터 도망치지 않고 격투했던 경험이 깨끗한 정보를 전달하는 것의 중요성을 가르쳐 주었습니다.

제3회 「왜 AI 개발은 지옥인가?」 - 「인프라 비용의 최적화」

모든 것을 고성능 추론 AI에 통째로 맡기는 것이 아니라, 저렴한 모델이나 캐시 (Cache)를 조합하는 「AI에게 생각하게 하지 않는 아키텍처 (Architecture)」 설계 사상은 이번 출력 프로세스 최적화와 완전히 동일합니다.

최신 추론 모델은 주어진 정보로부터 수천, 수만 번 자문자답을 반복하며 최선의 답을 찾아냅니다. 하지만 그 출발점이 되는 「1%의 확실한 정보」나 「의도」는 AI 스스로는 절대로 만들어낼 수 없습니다.

현장의 친구나 Web 멤버들과의 대화에서 얻은 지견.

인프라 담당자로부터 들은, 절대로 시스템을 멈춰서는 안 된다는 투박한 배경.

그리고 데이터를 깨끗하게 만들기 위한 엔지니어의 집념.

그러한 「인간의 발밑 작업」을 통해 확보한 정보와 기술 선정이야말로, AI의 1만 번의 추론과 맞물려 우리의 업무를 다음 차원으로 끌어올려 줍니다.

AI가 아무리 진화하고 편리해진다 해도, 최대한의 효과를 내기 위해서는 「뒷단의 구조」를 이해하고 올바른 정보를 제공해야 하는 책임이 따릅니다. 최종 체크를 하고 세상을 향해 결과물을 제출하는 「최소 부서의 장」은 언제나 우리 인간이니까요.

총 6회에 걸쳐 AI의 뒷모습과 현장의 리얼리티를 전달해 드렸습니다. 이 연재 시리즈가 여러분과 AI 사이의 새로운 협업을 위한 힌트가 되기를 바랍니다. 끝까지 읽어주셔서 정말 감사합니다!

토큰 (Token): AI가 한 번에 처리할 수 있는 정보의 단위. AI의 「뇌의 메모리·체력」과 같은 것으로, 레이아웃 계산 등 불필요한 곳에 사용하게 하면 문장을 생각하기 위한 추론 토큰이 줄어든다.

Markdown (마크다운): 제목이나 글머리 기호 등을 간단한 기호(# 등)로 표현하는 텍스트 작성 방식. AI에게도 인간에게도 노이즈가 가장 적고 읽고 쓰기 쉽다.

Notion (노션): 문서 관리부터 태스크 관리까지 수행하는 만능 도구. Markdown을 붙여넣는 것만으로 아름다운 문서로 변환되기 때문에 AI와의 궁합이 매우 좋다.

Tailwind CSS (테일윈드 CSS): HTML 태그에 직접 「글자를 크게」, 「여백을 비움」과 같은 지시(클래스)를 작성하는 것만으로 모던한 디자인을 만들 수 있는 Web 기술. AI가 잘 다룬다.

청크 분할 (Chunking): 긴 문장을 AI가 이해하기 쉬운 의미 단위(청크)로 나누는 것. RAG에서 이 정밀도가 AI의 지능을 좌우한다.