AI 결과물 읽는 시간을 줄이는 출력 형식 4단계: 카파시 팁을 직접 실험한 결과

TLDR

• AI가 일을 많이 할수록 사람의 일은 결과물을 이해하고 검수하는 일로 옮겨 갑니다. 그래서 결과물을 어떤 형식으로 받는지가 생산성을 좌우합니다.
• 안드레이 카파시는 출력 형식을 STE 글 → 다이어그램 → HTML 페이지 → 설명 영상 순서로 올려 보라고 제안했습니다. STE(Simplified Technical English)는 항공 정비 매뉴얼용으로 만든 단순한 영어 작성 규칙입니다.
• 저희는 네 단계를 모두 실제 업무에 적용했습니다. STE로 다시 쓴 에이전트 매뉴얼은 사람이 읽기 쉬워졌지만, AI의 이해도 점수는 측정 오차 안에서만 움직였습니다(7.33 → 8.00 / 12점).
• 블로그 글 4개 문단을 개념 애니메이션 영상으로 바꾸는 파이프라인을 만들었습니다. 장면 4개를 AI가 직접 짰고, 4개 모두 첫 시도에 검사를 통과했습니다.
• 바로 쓸 수 있는 요청문 4개와 "어떤 내용에 어떤 형식을 쓸지" 판단표를 정리했습니다.

1. 왜 지금 출력 형식이 중요한가

2026년 10월 2일, 안드레이 카파시(Andrej Karpathy)가 X에 올린 글은 이렇게 시작합니다. "앞으로 우리는 언어 모델의 출력을 이해하는 데 훨씬 많은 시간을 쓰게 될 것이다."

요지는 두 가지입니다.

1. AI가 실무를 더 많이 맡을수록, 사람의 일은 감독과 이해로 올라갑니다.
2. 다행히 그 이해도 AI가 돕습니다. 지능과 코드가 싸졌으니, 예전엔 만들 가치가 없던 일회용 웹앱이나 설명 영상을 그냥 만들어 달라고 하면 됩니다.

이 글은 조회 708만, 북마크 7.79만을 기록했습니다. 북마크가 좋아요(5.27만)보다 많습니다. 읽고 지나가는 글이 아니라 저장해 두고 다시 꺼내 보는 글이라는 뜻입니다.

저희도 같은 문제를 겪고 있었습니다. 에이전트가 하루에 만드는 보고서, 비교 문서, 계획서가 늘수록 그걸 읽는 시간이 병목이 됐습니다. AI 코딩 에이전트에 세팅을 쌓는 방법을 정리한 뒤로 에이전트의 산출물은 빠르게 늘었습니다. 하지만 사람의 읽는 속도는 그대로였습니다.

2. 긴 마크다운 보고서의 한계

AI에게 무언가를 물으면 대부분 마크다운 글로 답합니다. 짧은 답에는 충분합니다. 문제는 길이가 길어질 때입니다.

저희 영상 제작 폴더에는 영상 도구 3종(Remotion, HyperFrames, video-use)을 비교한 문서가 있었습니다. 203줄짜리 마크다운입니다. 결론은 맨 위에 있었지만, 실행 순서는 아래쪽 두 군데에 나뉘어 있었습니다. 데모 영상을 분석한 뒤 결론을 고친 부분은 문서 끝에 따로 붙어 있었습니다. 이 문서를 다시 열 때마다 "그래서 지금 뭘 하기로 했지?"를 찾느라 처음부터 다시 읽어야 했습니다.

글은 순서대로 읽어야 하는 형식입니다. 비교, 구조, 흐름처럼 한눈에 봐야 하는 내용을 글로 받으면 읽는 사람이 머릿속에서 표와 도식을 다시 그려야 합니다.

3. 실전 사례: 네 단계를 모두 적용해 봤습니다

3-1. STE 글: 에이전트 매뉴얼을 항공 정비 문체로 다시 쓰기

상황. 카파시가 첫 단계로 추천한 것은 ASD-STE100(Simplified Technical English)입니다. 항공 정비 매뉴얼을 위해 만든 영어 작성 규격입니다. 절차 문장은 20단어 이하, 설명 문장은 25단어 이하, 한 문장에 지시 하나, 능동태가 핵심 규칙입니다.

접근법. 저희가 쓰는 에이전트용 작업 매뉴얼(영상 원본 측정 절차, 영어 1,032단어)을 "STE 80% 수준"으로 다시 썼습니다. 그리고 두 버전을 비교했습니다.

• 같은 AI 모델(Claude Haiku)에게 원본과 STE 버전을 각각 주고 같은 과제를 3번씩 풀게 했습니다.
• 과제는 두 가지였습니다. 규칙 12개를 묻는 퀴즈, 그리고 가상의 52분짜리 녹화본으로 작업 계획을 세우는 시나리오입니다.
• 채점은 다른 모델(Claude Sonnet)이 맡았습니다. 어느 버전의 답인지 모르게 무작위 ID를 붙였습니다.

결과 (실측).

사람이 읽기 쉬운 지표는 확실히 좋아졌습니다. AI의 이해도는 퀴즈에서 같았고, 시나리오에서 0.67점 올랐습니다. 3회씩만 돌렸기 때문에 이 차이는 측정 오차 안에 있다고 보는 것이 정직합니다.

오히려 더 큰 발견은 따로 있었습니다. 두 버전 모두 같은 항목을 놓쳤습니다. 놓친 항목은 대부분 절차 단계 안이 아니라 문서 뒤쪽 "규칙" 목록에 있던 것들이었습니다. 문장 스타일보다 규칙을 어디에 두느냐가 AI의 행동에 더 큰 영향을 줬습니다.

참고로 STE를 AI 스킬로 만든 오픈소스 SimpleEnglish는 STE 규칙 위반을 72.9% 줄였다고 보고합니다. 규칙 위반이 줄어드는 것과 읽는 쪽(사람이든 AI든)의 이해가 늘어나는 것은 다른 문제라는 점을 같이 봐야 합니다.

한국어에는 STE 규격이 없습니다. 그래서 저희는 원칙만 가져왔습니다. 한 문장에 정보 하나, 절차는 번호 목록, 같은 대상에는 끝까지 같은 단어, 명사화와 피동 피하기입니다. 이 네 줄을 에이전트 전역 지침에 넣었습니다.

3-2. HTML 페이지: 203줄 비교 문서를 한 장으로

접근법. 앞에서 말한 203줄짜리 비교 문서를 Claude Code에게 HTML 페이지 한 장으로 바꿔 달라고 했습니다.

결과. 페이지는 다섯 블록으로 정리됐습니다.

1. 맨 위 판정 카드 3장: 유지 / 보류 / 실험
2. 각 도구가 파이프라인의 어디에 들어가는지 보여 주는 도식
3. 비교표 (어느 쪽이 나은지 표시)
4. 토큰 비용 숫자 4개
5. 실행 순서 타임라인 (통과 기준 포함)

결론이 첫 화면에 들어오니, 문서를 다시 열 때 처음부터 읽을 필요가 없어졌습니다. 다크 모드와 휴대폰 화면도 따로 요청하지 않았는데 지원됐습니다. 이 경험 이후 저희는 "60줄이 넘거나 비교표, 여러 단계 흐름이 있는 보고서는 HTML 페이지로 받는다"를 에이전트 기본 규칙으로 정했습니다.

Claude가 만든 페이지를 그대로 공개해 두었습니다(Claude 아티팩트). 휴대폰에서 열어 보면 판정 카드가 세로로 쌓이는 것을 직접 확인할 수 있습니다.

완벽한 도구를 기다리지 말고 필요한 도구를 직접 만들라는 이야기를 예전에 썼습니다. 일회용 HTML 페이지는 그 원칙의 가장 작은 단위입니다. 한 번 읽고 버려도 아깝지 않을 만큼 만드는 비용이 낮아졌습니다.

3-3. 설명 영상: 블로그 글을 개념 애니메이션으로

카파시가 가장 기대한다고 한 형식이 3Blue1Brown 스타일의 맞춤 설명 영상입니다. 내레이션에 맞춰 도형과 숫자가 화면에 쌓이고 움직이는 영상입니다.

상황. 저희는 이미 블로그 글을 유튜브 영상으로 바꾸는 자체 파이프라인을 쓰고 있었습니다. 블로그 문단을 대본으로 바꾸고, 음성 합성(TTS)으로 읽고, Remotion으로 자막을 입혀 렌더합니다. 문제는 배경 화면이었습니다. 무료 스톡 영상을 깔다 보니 내용과 상관없는 사무실 장면이 지나갔습니다.

접근법. 스톡 영상 자리를 개념 애니메이션으로 바꿨습니다.

1. 문단마다 TTS가 만든 단어 타이밍을 뽑습니다. "몇 초에 무슨 말을 하는지"가 나옵니다.
2. 그 타이밍과 디자인 규칙을 Claude에게 주고, 문단 하나에 해당하는 애니메이션을 HTML로 짜게 합니다. HTML을 영상으로 렌더하는 오픈소스 HyperFrames를 썼습니다.
3. 자동 검사(lint)를 돌리고, 오류가 있으면 오류 내용을 다시 Claude에게 줘서 고치게 합니다.
4. 문단 길이에 정확히 맞춰 렌더한 뒤, 기존 자막·엔딩 카드와 합칩니다.

디자인 규칙은 한 장짜리 문서로 고정했습니다. 어두운 배경, 지금 말하는 개념만 노란색, 지나간 요소는 흐리게, 화면 아래 400픽셀은 자막 자리, 문장은 쓰지 말고 짧은 단어와 숫자만 쓴다는 내용입니다.

결과 (실측, 2026-10-09). 시리즈 1편 「AI 코딩 에이전트, 대부분이 좌절하는 진짜 이유」의 핵심 문단 4개로 시범 영상을 만들었습니다.

화면은 의도대로 나왔습니다. "팀원에게는 1주 온보딩을 하는데 AI에게는 '이거 해줘'부터 시작했다"는 문단에서는 두 화살표가 AI로 들어가고, 실패한 쪽은 붉게 흐려지고 "세팅" 쪽만 노랗게 남습니다. "30분 세팅이 매일 1~2시간을 아낀다"는 문단에서는 30분짜리 CLAUDE.md 카드가 흐려지고, 옆에 '매일 1~2시간' 블록 5개가 쌓입니다.

시범 영상 전체도 올려 둡니다. 소리가 나오니 재생 전에 볼륨을 확인해 주세요.

솔직한 한계.

• 몇몇 장면은 도식이 화면 왼쪽 위로 쏠려 오른쪽이 비었습니다. 디자인 규칙에 "안전 영역 중앙 정렬, 가로 60% 이상 사용"을 추가했습니다. 다음 실행부터 적용됩니다.
• 첫 실행에서 렌더 결과 경로를 잘못 판단하는 버그가 있었습니다. 영상은 만들어졌지만 파이프라인이 실패로 기록했습니다. 고친 뒤에는 이미 만든 장면을 다시 쓰도록 캐시를 넣었습니다. 사람이 장면 HTML을 직접 고친 뒤 다시 돌리는 것도 가능해졌습니다.
• 본인 목소리로 읽어 주는 로컬 음성 복제(Qwen3-TTS)는 모델 파일만 4GB가 넘습니다. 이번 시범 중 맥 미니 디스크가 꽉 차서 무료 Edge TTS로 바꿨습니다.
• 영상은 아직 사람이 한 번 보고 검수해야 합니다. 이번에도 화면을 프레임 단위로 직접 확인했습니다.

4. 핵심 개념: 무엇을 언제 쓸까

네 형식은 우열이 아니라 용도가 다릅니다. 저희가 정리한 판단 기준은 이렇습니다.

비용도 다릅니다. 글과 다이어그램은 요청문 한 줄이면 됩니다. HTML 페이지도 요청 한 번이면 나옵니다. 설명 영상은 이번 시범 기준으로 3분 32초짜리 하나에 장면 단계만 4분이 걸렸습니다. 그 전에 파이프라인 코드를 만드는 작업이 있었습니다. 새 파일 225줄과 디자인 규칙 2장을 쓰고, 기존 파일 4곳을 고쳤습니다. 반복해서 만드는 콘텐츠일 때만 투자할 가치가 있습니다.

5. 실행 가이드: 그대로 붙여 넣는 요청문 4개

Claude Code, ChatGPT 어디에나 그대로 쓸 수 있습니다.

글 (STE 원칙)

한 문장에 정보 하나만 넣고, 절차는 번호 목록으로, 같은 대상은 끝까지 같은 단어로 설명해줘.

영어 문서라면 카파시가 쓴 표현을 그대로 쓰면 됩니다.

Explain this 80% of the way to ASD-STE100.

다이어그램

이 흐름을 mermaid 다이어그램으로 그려줘. 박스는 7개 이하로.

HTML 페이지

이 내용을 한 장짜리 HTML 페이지로 만들어줘. 결론을 맨 위에, 숫자는 표로, 휴대폰에서도 읽히게.

설명 영상

이 개념을 3Blue1Brown 스타일 설명 영상으로 만들어줘. HyperFrames로 만들고, 내레이션은 무료 TTS를 써줘.

한 번 효과를 본 형식은 에이전트의 전역 지침(Claude Code라면 CLAUDE.md)에 규칙으로 적어 두세요. 저희는 "60줄이 넘는 보고서는 HTML 페이지로"를 적어 둔 뒤로 매번 요청할 필요가 없어졌습니다. 이렇게 쓸수록 쌓이는 구조가 만들어집니다. 반복하는 형식은 프로젝트나 스킬로 묶어 두면 한 마디로 부를 수 있습니다.

6. 도입할 때 고려할 점

• 형식을 바꿔도 검수는 남습니다. HTML 페이지는 읽기 쉬운 만큼 틀린 숫자도 그럴듯해 보입니다. 숫자의 출처를 페이지에 같이 적게 하세요. AI의 환각과 검증에 대해서는 따로 정리한 글이 있습니다.
• 측정해 보면 기대와 다를 수 있습니다. 저희는 STE가 AI의 이해도까지 크게 올릴 거라고 예상했지만, 측정 결과는 오차 범위 안이었습니다. 형식을 바꿀 때는 작게라도 전후를 비교해 보세요.
• 영상은 반복 콘텐츠에만. 파이프라인을 만드는 비용이 있습니다. 매주 블로그 글을 쓰거나 교육 콘텐츠를 만드는 팀이라면 투자할 가치가 있습니다.
• 장비 여유를 확인하세요. 로컬 음성 모델과 영상 렌더는 디스크와 메모리를 씁니다. 이번 시범에서 저희 디스크가 꽉 찬 것처럼요.

7. 직접 적용해 보고 싶다면

저희 부트캠프에는 이 내용을 40분 실습으로 넣었습니다. 내 업무 주제 하나를 글, 다이어그램, HTML로 각각 받아 보고, 옆 사람이 30초 안에 핵심 3가지를 맞히는지 비교합니다. 비개발자 부트캠프 참가 후기도 참고해 보세요.

📞 AX 도입 상담

• 📧 Contact Form
• 📅 30분 예약

마치며

카파시의 글에서 가장 와닿은 문장은 마지막 부분이었습니다. 예전에는 만들 가치가 없던 크고, 맞춤형이고, 버려도 되는 소프트웨어를 이제는 그냥 만들어 달라고 하라는 것입니다.

해 보니 형식을 바꾸는 일 자체는 쉬웠습니다. 어려운 건 "이 형식이 정말 더 나은가"를 확인하는 일이었습니다. 그리고 그 확인도 AI에게 시킬 수 있었습니다. 저희가 STE를 A/B로 비교한 것처럼요.

📚 더 읽어보기

• AI 코딩 에이전트 세팅 가이드: CLAUDE.md·Skills·MCP·에이전트 위임
• 완벽한 도구를 기다리지 마세요 — AI 시대 나만의 OS 만들기
• AI로 만드는 복리 지식 시스템 — 매 세션이 똑똑해지는 법
• 블로그 글 하나 쓰는 데 2시간? 클로드 프로젝트로 30분에 끝내는 법