충격적으로 짧은 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 설명 자료라는 요구가 Codex의 시각화 기능으로 이어졌다는 것뿐이다.

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으로 키우기#

사이드 챗에 프롬프트를 매번 다시 쓰면서 단축키 이상의 필요를 느꼈다. 표현이 조금만 달라져도 결과의 깊이가 흔들렸기 때문이다. 반복해서 발견한 좋은 패턴을 한곳에 모으고 업데이트와 evaluation을 통해 개선하고 싶었다.

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

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

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

결과를 볼 때는 어려운 용어가 예고 없이 본문에 등장하지 않았는지부터 확인한다. 필요한 시각화가 빠지거나 단순한 글에 시각화를 억지로 붙이지 않았는지도 살핀다. 원문에 없는 맥락을 사실처럼 만들지는 않았는지도 함께 확인한다.

실패가 반복될 때만 규칙을 추가한다. 배경 설명이 자주 빠지면 그 경계를 구체화하고 시각화를 남용하면 사용 조건을 좁힌다. 앞으로 일어날 모든 상황을 통제하려고 규칙을 쌓지는 않는다. 실제로 확인한 실패가 되풀이되지 않게 남기는 기록에 가깝다.

OpenAI 공식 스킬 문서는 하나의 작업에 집중하라고 안내한다. 결정적인 동작이 필요하지 않다면 스크립트보다 지침을 우선하고 설명과 실제 호출 결과를 시험하라는 조언도 있다. 모든 세부사항을 먼저 명시하기보다 작은 워크플로우를 반복 가능하게 만들고 검증하면서 다듬는 방향과 잘 맞는다.

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

eli5를 처음 봤을 때는 반가웠다. 나만의 임시방편이라고 생각했던 사이드 챗 패턴이 다른 사람에게는 이미 하나의 스킬로 정리되어 있었다.

파일을 열어 본 순간에는 내가 중요하다고 생각한 규칙이 거의 없어 당황했다. 그런데 직접 실행하자 생각이 또 바뀌었다. Codex는 짧은 지침에 시각화 능력을 더해 내가 좋아했던 대화 안의 인터랙티브 설명을 만들어 냈다.

좋은 스킬이 모든 과정을 일일이 지시할 필요는 없다. 모델과 실행 환경에 맡길 부분, 반복해서 실패해서는 안 되는 부분 사이의 경계를 정하는 장치에 더 가까울지도 모른다.

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

eli5를 그대로 흉내 내거나 예전처럼 모든 절차를 먼저 적는 대신, 지금은 이렇게 정리했다.

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

참고#

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