Karpathy가 AI에게 명령하는 데 사용하도록 추천한 1986년 비행기 매뉴얼

Nokka (นก-กา) 작성 | 2026년 10월 3일

본 기사는 AI(deepseek-v4.1-flash)가 Hermes Agent를 통해 작성했으며, Nokka가 검토 및 정리했습니다.

Andrej Karpathy는 2026년 10월 2일에 짧은 글을 게시했습니다 [1]。

그는 다음과 같은 문장으로 시작했습니다. 제가 읽고 잠시 생각에 머물렀던 문장이었습니다.

우리는 언어 모델의 결과를 이해하는 데 훨씬 더 많은 시간을 할애할 것입니다 [1]。

이 문장은 변화하고 있는 작업에 대해 이야기합니다. 현재 우리는 AI에게 코드를 작성하게 하고, 문서를 요약하게 하며, 데이터를 분석하게 합니다. 그리고 이러한 작업은 모델이 능숙해질수록 계속 늘어날 것입니다.

하지만 AI가 하는 일이 많아짐에 따라 우리가 해야 할 일도 이동합니다.

'직접 실행하는 것(ลงมือทำ)'에서 '기계가 무엇을 했는지 이해할 수 있도록 읽는 것(อ่านให้เข้าใจว่าเครื่องทำอะไรลงไป)'으로 말입니다.

Karpathy는 이 지점을 oversight, 즉 감독 또는 감시라고 부르며 [1], 초보적인 단계부터 그가 가장 신뢰하는 단계까지 AI의 결과물을 읽기 위한 4가지 기술을 제시했습니다.

이 게시물의 수치를 보면 제가 읽은 날짜 기준으로 사람들이 얼마나 관심을 가지는지 알 수 있습니다. 좋아요는 40,417회, 리포스트는 4,457회, 조회수는 430만 회를 넘었습니다 [1]。

하지만 제가 관심 있는 것은 이 수치가 아니라, 비행기 정비 매뉴얼의 기술을 AI에 적용한 그의 첫 번째 단계입니다.

คู่มือซ่อมเครื่องบินเก่าเปิดบนแท่นช่าง มีแสงลอยขึ้นจากหน้ากระดาษกลายเป็นไดอะแกรมโปร่งแสงเหนือจอแล็ปท็อป สื่อการอ่านงาน AI ให้เข้าใจ

개념 이미지: 오래된 비행기 매뉴얼의 지식이 화면에서 읽을 수 있는 다이어그램으로 변환됨

레벨 1: AI에게 비행기 매뉴얼처럼 작성하도록 명령하기

Karpathy는 자신이 시도해 본 방법 중 효과가 있었다고 언급하며, LLM(대규모 언어 모델)에게 어떤 주제에 대해서든 ASD-STE100 표준을 준수하여 설명하도록 명령하는 것입니다 [1]。

ASD는 유럽 항공우주·보안 및 국방 산업 협회(Aerospace, Security and Defence Industries Association of Europe)의 약자로, 이 표준의 공식 문서에서 협회가 자신을 명시한 이름입니다. STE는 Simplified Technical English 또는 '간단 기술 영어'를 의미합니다 [14]。

이것은 통제된 언어(controlled language)로, 단어와 문장 구조가 고정되어 있습니다. 1970년대 유럽 항공사들의 요청으로 탄생했습니다 [2].

당시의 이유는 간단했습니다. 유럽 항공사의 80% 이상이 영어를 모국어로 사용하지 않았습니다[2]. 하지만 비행기 수리 매뉴얼은 영어로 작성되어 있었고, 매뉴얼을 읽어야 하는 정비사들은 영어를 유창하게 구사하는 사람이 아닐 수도 있었습니다.

만약 수리 과정에서 지시 사항을 잘못 읽으면 그 결과는 단순히 작업이 느려지는 정도가 아니었습니다.

따라서 이 내용은 스타일 가이드라인이라기보다는 안전 표준으로 확립되었습니다.

이 표준의 연혁

• 1970년대 후반: AECMA 워킹그룹은 항공사를 위한 통제된 영어(controlled English)에 대한 연구를 시작했습니다[2][3].
• 1983년: AECMA는 다른 산업에서 이미 사용되고 있는 언어가 무엇인지 조사한 후 자체 표준을 만들기로 결정했습니다[3].
• 1985~1986년: 첫 번째 문서는 'AECMA Simplified English Guide'라는 이름으로 발행되었습니다[2][3].
• 2004년: AECMA는 다른 두 협회와 통합되어 ASD가 되었고, 표준 명칭은 'AECMA Simplified English'에서 'ASD Simplified Technical English'로 바뀌었습니다. 또한 상태가 '매뉴얼(guide)'에서 '규정(requirement)'으로 변경되었으며, 공식 문서 Issue 9에 따르면 새로운 저작권 시작 연도는 2005년입니다[14].
• 2013년: 표준은 Issue 6부터 무료로 다운로드할 수 있게 되었습니다[3].
• 2025년 1월: Issue 9가 발행되었으며, 새로운 상태는 '국제 표준(international standard)'입니다[2]

제가 솔직하게 말씀드려야 할 날짜에 대한 부분이 있습니다.

ASD의 공식 문건에는 첫 번째 문서가 1986년에 발행되었다고 되어 있지만[2], Wikipedia에서는 PSC-85-16598 코드가 1985년에 발행되었다고 합니다[3]. 그리고 이 표준을 AI 맥락에서 언급하는 여러 출처들은 '1983년부터'라고 말합니다[5].

제가 확인한 바로는, 이러한 다른 숫자는 각각 다른 사건에서 비롯된 것입니다. 1979년은 연구가 시작된 해이고, 1983년은 표준을 만들기로 결정한 해이며, 1985년과 1986년은 문서가 발행된 해입니다. 따라서 보고하는 출처마다 1년씩 차이가 납니다.

본 글에서는 ASD의 공식 문서를 기준으로 삼고 다른 연도는 출처를 통해 참고용으로 제시했습니다.

실제로 문장을 읽기 쉽게 만드는 규칙

ASD-STE100은 두 부분으로 구성되어 있습니다[2].

첫 번째 부분은 53개의 작성 규칙으로, 9개 카테고리로 나뉘어 단어 선택, 문법, 문장 구조 및 스타일에 걸쳐 다루고 있습니다[2].

두 번째 부분은 사전(dictionary)으로, 약 900개의 사용 승인된 단어를 포함하고 있으며, 각 단어는 하나의 의미만을 가지며 오직 한 가지의 문법적 기능을 수행합니다[2].

사전에는 또한 사용할 수 없도록 비승인된 단어 목록도 약 1,200개가 있으며, 이에 대한 대체 단어도 제시되어 있습니다[2].

자주 언급되는 예시 중 하나는 이 쌍입니다. 저는 공식 사전을 Issue 9에서 가져와 직접 한 쌍씩 확인했습니다 [14].

• commence: 사용 불가, 대신 start를 사용하세요.
• ensure: 사용 불가, 대신 make sure를 사용하세요.
• prior to: 사용 불가, 대신 before를 사용하세요.
• replenish: 사용 불가, 대신 fill을 사용하세요.
• utilize: 사용 불가, 대신 use를 사용하세요.
• about: 양(quantity)을 의미할 때 사용 불가, 대신 approximately를 사용하세요 (사전 예시: DRAIN APPROXIMATELY 2 LITERS OF FUEL).
• in order to: 사용 불가, 대신 to를 사용하세요.
• close: "가까운"이라는 뜻으로 사용할 때 사용 불가, 대신 near를 사용하세요.

마지막 규칙이 가장 지능적이라고 생각합니다. 단어 'close'는 오직 동사로서의 의미인 "닫다(shut)"로만 허용됩니다. 만약 "가까운"이라는 의미를 전달하려면 near를 사용해야 합니다 [3].

이것은 단순한 슬로건이 아니라 실제로 적용되는 "하나의 단어, 하나의 의미, 하나의 기능" 원칙입니다.

AI 작업에 중요한 문장 규칙

• 절차(procedure) 명령문은 최대 20단어를 넘지 않아야 하며, 서술적(descriptive) 문장은 최대 25단어를 넘지 않아야 합니다 [3].
• 하나의 단락은 최대 6개의 문장을 포함할 수 있으며, 하나의 주제만 다루어야 합니다 [3].
• 명사구가 중첩될 경우 최대 3개까지만 가능합니다 [8].
• 사용 가능한 동사는 원형부정사(infinitive), 명령형(imperative), 현재 시제(present), 과거 시제(past), 미래 시제(future) 그리고 형용사 역할을 하는 과거분사(past participle) 형태에 한정됩니다 [3].
• 'landing gear'와 같은 기술적 명사를 제외하고는 '-ing' 형태의 동사는 사용해서는 안 됩니다 [3].
• 복잡한 구조를 만들기 위해 조동사(auxiliary verb) 형태를 사용할 수 없습니다 [3].
• 지시문에서는 주어가 행위자(active voice)인 문장을 사용해야 합니다 [3].
• 텍스트를 줄이기 위해 "the", "a", "this"와 같은 관사를 생략해서는 안 됩니다 [3].
• 한 문장에는 하나의 명령이 포함되어야 합니다 (실제로 동시에 수행하는 작업 제외) [3].
• 안전 경고문은 명확한 지시문이나 조건으로 시작해야 합니다 [3].

만약 이 목록을 읽고 이것이 사람들이 AI가 글을 잘 쓰지 못한다고 불평할 때 말하는 그 목록과 같다고 느낀다면, 그것이 바로 핵심입니다.

항공기 정비 표준이 AI 작업에 적용되는 이유

Karpathy는 이 표준이 "깔끔한 작문 스타일에 대한 엄격한 제약"을 동반한다고 간략하게 설명했으며, 그는 이것이 훨씬 읽기 쉽다는 것을 자주 발견했다고 말합니다 [1].

그는 또한 이 표준이 상당히 까다롭다고 언급하며, 때로는 완화된 지시를 내리기도 한다고 합니다. 예를 들어 "ASD-STE100의 80퍼센트"와 같이 요청하는 경우도 있습니다 [1].

누군가 실제로 따라 해 봤는데 비슷한 결과를 얻었다. Kun Chen은 자신이 ASD-STE100의 단어 규칙을 사용해 본 후, 답변의 명확성이 놀라울 정도로 향상되었다고 언급했다. 심지어 HTML 형식의 결과물에서도 말이다. 다만 이 전체 규칙 세트가 너무 과도해서 일부만 선택적으로 사용하는 것이 좋다고 한다 [13].

나는 Karpathy가 말한 '80퍼센트'라는 부분이 이 게시글에서 가장 간과되기 쉬운 부분이라고 생각한다.

이것은 완전한 표준(full standard)이 높은 비용의 오류를 범할 수 있는 상황을 위해 설계되었지, 단순히 독자가 읽기 편하도록 하기 위한 것이 아니라는 인정이다.

내가 더 흥미롭다고 생각하는 부분은 이 표준을 위한 스킬을 별도로 개발한 사람들의 관찰 내용이다.

한 팀은 '다른 에이전트의 결과를 읽는 에이전트'를 위해 스킬을 만들었고, 사람이 아닌 것을 대상으로 했다 [6].

그들이 제시한 이유는 다른 에이전트의 텍스트를 읽고 있는 에이전트는 비행기 정비사 상황과 같기 때문이다. 즉, '작성된 것이 A를 의미하는지 B를 의미하는지' 되물어 물어볼 수 없다 [6].

되묻는 과정도 없고, 추가적인 설명해 줄 사람도 없으며, 오직 정확하게 해석해야 할 텍스트만 존재한다.

이것은 모호성 규칙을 취향의 문제가 아닌 정확성의 문제로 만든다.

레벨 2: 다이어그램 (Diagram)

Karpathy는 이어서, 작성할 필요가 없다면 LLM에게 다이어그램을 그리게 하는 것이 좋다고 했다. 왜냐하면 그것이 '훨씬 더 처리하고, 분석하며, 이해하기 쉽기' 때문이다 [1].

나는 조건부로 동의한다.

다이어그램은 답변에 구조(structure)가 있을 때 텍스트보다 우수하다. 예를 들어 구성 요소와 데이터 흐름, 상태와 전이(transition), 시간 순서 또는 계층적 순서 같은 경우이다 [8].

하지만 답변이 구분해야 할 논쟁(argumentation)일 때는 다이어그램이 훨씬 떨어진다. '상황에 따라 다르다'고 적힌 상자와 화살표는 아무에게도 아무것도 알려주지 못한다 [8].

레벨 3: HTML 화면 (HTML Screen)

세 번째 레벨은 인터랙티브한 웹페이지를 얻기 위해 결과를 'HTML 형식으로' 보는 것이다 [1].

나는 이전에 이 주제에 대해 글을 쓴 적이 있어서, 배경 설명만 간략하게 한다.

이것은 명확한 출처가 있다. Karpathy가 이번에 게시글을 올리기 전에, 그는 Anthropic의 Claude Code 팀원인 Thariq Shihipar의 게시글을 2026년 5월에 공유했었다 [4].

Shihipar 자신이 작성하고 클로드 블로그에 게재된 전체 기사는 2026년 5월 20일이며, 해당 기사 페이지는 그가 회사 기술 팀원임을 명시한다 [7]

해당 기사는 "Using Claude Code: The unreasonable effectiveness of HTML"이라는 제목으로, Claude Code 팀이 사람과 에이전트 간의 통신에 왜 Markdown 대신 HTML을 사용했는지 설명합니다 [7]

팀에서 제시한 이유는 5가지입니다 [7]:

• 정보 밀도: HTML은 단일 페이지에 표(table), 그래픽 SVG, 코드 및 이미지를 표시할 수 있는 반면, Markdown은 기본적인 문서 구조만 구현 가능합니다 [7]。
• 가독성: "저는 100줄이 넘는 Markdown 파일은 잘 읽지 않으며, 회사 동료들에게도 읽으라고 권유하기 어렵습니다" 라고 합니다 [7]。
• 공유 용이성: Markdown 파일은 브라우저에서 형식이 깨지는 경우가 많아 이메일이나 채팅에 첨부해야 하지만, HTML은 업로드만 하면 바로 열 수 있는 링크를 얻을 수 있습니다 [7]。
• 양방향 상호작용: 슬라이더나 버튼을 추가하여 값을 조정해보고 그 결과를 복사하여 프롬프트에 붙여넣기 할 수 있도록 요청할 수 있습니다 [7]。
• 문맥 정보 흡수: Claude Code는 사용자의 로컬 파일, git 히스토리, 그리고 MCP 도구를 모두 읽을 수 있기 때문입니다 [7]。

이 마지막 항목은 이 내용이 일반적인 채팅 화면의 문제가 아니라 코딩 에이전트(coding agent)에 특화된 문제라는 이유가 됩니다.

레벨 4: 설명 비디오

Karpathy가 가장 자신감을 보인 레벨은 특정 주제로 제작되는 설명 비디오입니다 [1]。

그가 제시한 프롬프트 예시는 'X'라는 주제에 대해 3b1b 스타일의 설명 비디오를 만들고, 음성 해설에는 ElevenLabs 키를 사용하라는 것입니다 [1]。

3b1b는 움직이는 이미지로 수학 영상을 제작하는 채널이며, ElevenLabs는 유료 음성 합성 서비스입니다 [1][4]。

그는 키가 없는 사람들을 위한 대안으로 LLM에게 자체 기기에서 실행할 수 있는 충분히 좋은 무료 도구를 찾도록 지시하는 것으로 마무리합니다 [1]。

그리고 제가 생각하기에 이 레벨에서 가장 중요한 문장은 "이건 실제로 사용 가능해졌다" 입니다 [1]。

실제로 이런 작업을 수행하는 오픈소스 프로젝트가 존재하며, 그 수치는 주목할 만합니다.

프로젝트 이름은 paper2video로, 논문이나 PDF 파일을 받아 2분에서 5분 길이의 설명 비디오로 변환합니다. Manim으로 이미지를 렌더링하고, Kokoro로 음성을 합성한 뒤, ffmpeg으로 합칩니다 [9]。

프로젝트 페이지 예시에는 Karpathy 자신의 지식 기록을 설명하는 3분짜리 비디오가 있는데, 제작에 걸린 시간은 5시간이 채 되지 않았고 비용은 약 5센트였습니다 [9]।

다른 방향의 프로젝트가 하나 더 있습니다. 바로 유료 모델을 전혀 사용하지 않고, Microsoft의 Edge TTS 음성을 사용하며, Chromium으로 창을 표시하지 않고 웹 페이지를 녹화한 후 ffmpeg로 오디오를 합치는 방식입니다 [10]

하지만 말씀드릴 점이 있습니다.

후자의 프로젝트는 첫 커밋과 마지막 커밋 날짜가 같은 2026년 5월 27일이라는 것입니다 [10]

즉, 4개월 이상 지났는데도 새로운 커밋이 없습니다. 개발자가 의도적으로 중단했는지 아니면 단순히 돌아오지 않은 것인지 모르겠지만, 19개의 스타 개수는 이 사실을 말해주지 않습니다.

오늘 시도해 볼 수 있는 도구들

Karpathy가 실제로 사용했고 설정하기 가장 쉬운 레벨 1부터 시작하려면 선택할 수 있는 여러 오픈소스 스킬들이 있습니다 [4]。

• SimpleEnglish: AminBlg이 개발했으며, 스타 3,665개, 포크 135개, MIT 라이선스입니다. 2026년 7월 21일에 출시되었고 가장 최근 커밋은 2026년 9월 30일입니다 [5]。
• asd-ste100-skill: danyuchn이 개발했으며, 스타 2,809개, 포크 158개, MIT 라이선스입니다. 2026년 7월 20일에 출시되었고 가장 최근 커밋은 2026년 9월 8일입니다 [6]。

두 스킬 모두 표준 스킬 관리자를 통해 설치할 수 있습니다. AminBlg의 것은 비공식 프로젝트이며 ASD나 STEMG와 관련되거나 인증받지 않았음을 명확히 밝혔습니다. 또한, ASD-STE100은 ASD의 등록 상표입니다 [5]。

danyuchn의 경우는 같은 표현을 사용하지 않았지만, 라이선스 측면에서 Issue 9 표준이 명시된 8개 유형의 조직에 대해서만 복제가 허용되며 이 프로젝트는 해당되지 않는다고 밝혔습니다 [6]。

danyuchn의 것 중 제가 마음에 드는 점은 두 가지 모드로 분리했다는 것입니다 [6]。

명령, 오류 메시지 및 도구 설명을 위한 엄격한 모드와 README, PR 설명 및 서술적 글쓰기를 위한 유연한 모드입니다. 유연한 모드는 문장 구조에 대한 규율은 유지하지만 단어 자체를 고정하지는 않습니다 [6]。

또한 그는 ASD의 900개 어휘집을 포함하지 않았다고 솔직하게 말했습니다. 왜냐하면 라이선스가 명시된 8개 유형의 조직에서만 허용되기 때문이며, 이 프로젝트는 해당되지 않기 때문입니다 [6]。

저는 이러한 정직함이 스킬의 스타 개수보다 더 신뢰감을 준다고 생각합니다.

반드시 읽어야 할 수치들

한 스킬은 100단어당 오류율을 72.9% 감소시켰다고 보고했습니다. 이는 6개 모델과 8가지 유형의 글쓰기를 결합하여 총 96회의 테스트를 거친 평균 결과입니다 [12]。

하지만 프로젝트 소유자가 README 페이지에 다음과 같이 작성했습니다. '이전에 '9개 모델에서 81.3% 감소'라고 보고했던 수치는 규칙 준수율을 측정한 것이지, 독자가 실제로 보는 것을 측정한 것이 아닙니다' [5]

이 문제를 알고 난 후, 그는 다른 데이터 세트를 제시했습니다. 즉, 답변에서 눈에 보이는 결함의 수가 218개에서 11개로 95% 감소했다는 것입니다 [5].

이 수치는 2026년 9월 2일에 진행된 실험을 바탕으로 하며, 당시에는 최대 응답 길이 제한이 5문장인 스킬 버전 2.0.1을 사용했기 때문에, 버전 2.1.0에서는 이 제한이 제거되었습니다 [5].

프로젝트 소유자는 자신이 직접 '버전 2.1.0 또는 그 이후 버전으로 재실험한 결과는 아직 없다'고 언급했습니다 [5].

제가 이 이야기를 전하는 이유는, 단순히 수치를 줄여서 자신의 성과를 축소하려는 것이 아니라, 벤치마크(benchmark)의 수치를 빠짐없이 읽어내는 것의 좋은 예시이기 때문입니다.

프로젝트 소유자가 자신이 홍보했던 수치가 실제로 측정해야 할 내용과 일치하지 않다고 경고하는 것이, 그 수치 자체보다 더 감명 깊습니다.

게시물에서 말해주지 않은 것