충격적으로 짧은 ELI5 스킬을 보고, 내가 쓰던 워크플로우를 다시 생각했다

반가움 다음에 찾아온 충격#

출처를 따라가 보니 내가 본 eli5는 anthropics/claude-plugins-community에 등록된 Claude용 커뮤니티 플러그인이었다. manifest에 표시된 작성자는 Thariq Shihipar이고 최초 커밋 날짜는 2026년 8월 21일이다.

Thariq가 후속 글에서 든 사용 예도 낯설지 않았다. 그는 설명 자료를 만들거나 문제를 깊게 파고들 때 eli5를 쓴다며 모듈의 작동 방식, 트레이드오프를 택한 이유, 장애 원인을 묻는 예를 들었다. 내가 PR과 리뷰 요청을 이해하려고 사이드 챗을 쓰던 방식과 비슷했다.

이 저장소는 이름에 anthropics가 들어가지만 Anthropic이 직접 유지하는 공식 플러그인 모음은 아니다. README는 이곳을 심사를 통과한 커뮤니티 플러그인의 읽기 전용 미러라고 설명하며 공식 플러그인 저장소를 따로 안내한다. 그래서 이 글에서는 eli5를 Anthropic 공식 스킬이라고 부르지 않고 Claude용 커뮤니티 스킬로 표현한다.

막상 SKILL.md를 열어 보니 생각보다 훨씬 짧았다. 한국어로 요약하면 이 정도다.

1
이 주제를 아무것도 모르는 사람에게 설명한다.
2
큰 그림과 적은 글을 사용한 HTML 설명 자료로 만든다.

원본에는 내가 스킬을 만들려고 생각했던 단계와 규칙이 거의 없었다. 용어를 소개할 순서나 시각화할 대상, 설명이 이해하기 쉬운지 판단할 기준도 정하지 않았다. 나라면 예외와 출력 형식을 더 붙였을 것 같았다.

그러자 질문이 생겼다.

요즘 모델이라면 이렇게 짧게 의도만 전달하는 편이 더 나은 걸까?

Claude용 스킬을 Codex에서 실행해 보니#

직접 Codex에서 eli5를 실행해 보니 채팅 내부에 인터랙티브 HTML 설명 페이지가 렌더됐다. 버튼을 누르면 서로 다른 선택지와 설명이 나타났다.

실행 과정에서는 Codex에 번들로 포함된 visualize 스킬이 함께 선택됐다. 다만 원본 eli5가 visualize를 직접 호출한다는 근거는 없다. 원본은 Claude용으로 작성됐고 지시문에도 visualize라는 이름은 없다. 내가 확인한 건 Codex에서 HTML 설명 자료를 요구했을 때 시각화 기능이 사용됐다는 것뿐이다.

HTML artifact라는 표현이 Codex의 시각화 기능과 맞아떨어진 것 같다. 실행 결과를 보고 추측한 것이며, Claude에서도 같은 구성과 상호작용이 만들어지는지는 비교하지 않았다.

이 점을 보고 eli5가 짧은 이유를 다시 생각했다.

처음에는 최신 모델이 알아서 잘하니 지시가 짧다고 생각했다. 그런데 내가 본 실행에서는 스킬이 세부사항을 모두 정하지 않아도 실행 환경이 상당 부분을 맡고 있었다.

eli5는 설명 대상과 결과의 방향만 정한다. Codex에서는 번들 스킬이 시각화의 구체적인 구성과 상호작용을 맡았다. 짧은 지침이 실행 환경의 기존 기능을 사용하도록 연결한 셈이다.

같은 SKILL.md라도 실행하는 모델과 호스트, 설치된 도구와 스킬에 따라 결과가 달라질 수 있겠다고 생각했다.

그렇다면 내 워크플로우에는 무엇을 남겨야 할까#

처음에는 설명에 현재 상황, 문제, 해결 방법과 영향을 항상 넣고 싶었다. PR과 리뷰 코멘트를 이해할 때 자주 확인하던 항목이기 때문이다.

코드 리뷰에만 쓰려던 건 아니었다. 기술 문서와 기사, 논문, 정책이나 기획 문서에도 쓰고 싶었다. 모든 글에 문제와 해결 방법이 있는 건 아니다. 목차를 고정하면 모델이 원문의 구조보다 틀을 채우는 데 맞춰 설명하거나, 원문에 없는 해결책을 만들어낼 수 있다.

하나씩 걷어낸 끝에 세 가지만 남겼다.

1. 독자에게 관련 맥락과 배경지식이 없다고 전제한다.
2. 전문 용어가 등장하면 본문보다 먼저 짧은 용어집을 보여 준다.
3. 시각화가 실제로 이해를 쉽게 만들 때 Codex의 visualize를 사용한다.

eli5와 내가 생각한 첫 버전을 나란히 놓으면 차이가 보인다.

퀴즈나 확인 질문까지 강제할 생각은 없었다. 주어진 글을 이해하기 쉽게 설명하고 끝나면 충분하다. 사용자가 아는 내용을 장기적으로 기억하거나 다음 실행에서 자동으로 생략하는 기능도 첫 버전에는 필요하지 않다.

이렇게 줄이고 나니 지침은 eli5에 가까울 만큼 짧아졌다.

1
주어진 글을 배경지식이 없는 사람도 이해할 수 있게 설명한다.
2

3
전문 용어가 나오면 본문에 앞서 짧은 용어집을 제공한다.
4
시각화가 이해를 실질적으로 개선할 때는 $visualize를 사용한다.
5
설명이 끝난 뒤 사용자에게 별도의 이해 확인을 요구하지 않는다.

시각화의 개수나 출력 목차는 고정하지 않는다. 설명에 필요한 단어를 먼저 알려 주고, 글만으로 전달하기 어려운 관계를 보여 주면 된다. 비유와 설명 순서, Mermaid와 인터랙티브 HTML 중 무엇을 선택할지는 모델과 visualize에 맡긴다.

긴 지침보다 evaluation으로 키우기#

사이드 챗에 프롬프트를 매번 다시 쓰면서 입력을 줄이는 것만으로는 부족하다고 느꼈다. 표현이 조금만 달라져도 설명의 깊이가 달라졌기 때문이다. 반복해서 좋은 결과를 낸 지침을 한곳에 모으고, 평가하면서 고쳐 나가고 싶었다.

가능한 실패를 처음부터 모두 예상해 규칙으로 적다 보면 프롬프트는 다시 길어진다. 작은 버전으로 시작해 실제 사례에서 반복되는 실패만 지침에 반영하는 편이 낫다고 봤다.

먼저 내가 자주 마주치는 입력을 평가 사례로 삼는다.

• 맥락이 압축된 PR 본문
• 한 문장 안에 도메인 용어가 몰린 리뷰 코멘트
• 구조와 상태 변화가 복잡한 기술 문서
• 시각화가 필요하지 않은 일반적인 글
• 그림이나 상호작용이 글보다 이해를 크게 돕는 설명

결과를 볼 때는 어려운 용어를 먼저 설명했는지부터 확인한다. 필요한 시각화가 빠졌는지, 단순한 글에 시각화를 억지로 붙였는지도 살핀다. 원문에 없는 맥락을 사실처럼 설명하지 않았는지도 확인한다.

실패가 반복될 때만 규칙을 추가한다. 배경 설명이 자주 빠지면 어떤 내용을 설명해야 하는지 구체화하고, 시각화를 남용하면 사용 조건을 좁힌다. 모든 상황에 대비하기보다 실제로 확인한 실패가 되풀이되지 않도록 지침을 고치려 한다.

OpenAI 공식 스킬 문서도 하나의 작업에 집중하라고 안내한다. 동작이 항상 일정해야 하거나 외부 도구가 필요한 경우를 제외하면 스크립트보다 지침을 우선하고, 프롬프트가 스킬 설명에 맞게 호출을 유도하는지 시험하라는 조언도 있다. 작은 워크플로우를 만들고 검증하면서 다듬으려는 방향과 맞는다.

단순함은 생략이 아니라 위임일지도 모른다#

나만의 임시방편이라고 생각했던 사이드 챗 사용법이 다른 사람에게는 이미 스킬로 정리되어 있어 반가웠다.

중요하다고 생각한 규칙이 거의 없어 당황했지만, Codex에서는 그 짧은 지침으로도 내가 쓰던 대화 안의 인터랙티브 설명이 나왔다.

스킬에서 모든 과정을 일일이 지시할 필요는 없을 것 같다. 모델과 실행 환경에 맡겨도 되는 부분과 실패가 반복되지 않도록 규칙을 남길 부분을 구분하면 되지 않을까.

아직 내 스킬을 완성하지는 않았다. 일단 배경지식이 없는 독자라는 전제, 선행 용어집, 선택적 시각화만 남긴 버전으로 시작하려고 한다. 나머지는 실제 글과 PR, 리뷰 코멘트를 설명해 보고 평가하면서 결정할 생각이다.

eli5를 그대로 옮기거나 예전처럼 모든 절차를 먼저 적지는 않으려 한다.

단순하게 시작하되, 내가 중요하게 여기는 이해의 조건까지 모델의 우연에 맡기지는 않는다.

참고#

• Thariq Shihipar의 ELI5 소개 X 게시물
• Claude Plugins Community의 eli5
• OpenAI 공식 문서: Build skills