eli5 — 복잡한 주제를 그림 한 장으로 바꾸는 Claude Code 플러그인

eli5가 무엇인가

eli5는 Claude Code에 끼워 쓰는 플러그인이다. 안에 스킬이 하나 들어 있고, 그 스킬 이름도 eli5다.

이름부터 풀면 Explain Like I am 5의 줄임말이다. 영어권에서 오래 쓰인 관용구로, 다섯 살짜리한테 설명하듯 쉽게 말해 달라는 뜻이다. 레딧 같은 커뮤니티에서 질문 앞에 붙이던 표현이 그대로 스킬 이름이 됐다.

하는 일은 한 줄로 정리된다. 프롬프트 창에 /eli5 를 치고 한 칸 띄운 뒤 주제를 적으면, 답이 평소처럼 긴 글로 오지 않고 그림 위주의 HTML 한 장으로 만들어진다.

여기서 스킬이라는 말이 낯설 수 있다. Claude Code에서 스킬은 특정 상황에 모델이 따라야 할 지시문을 파일 하나에 적어 둔 것이다. 프로그램이 아니라 글이다. 슬래시 명령으로 부르면 그 지시문이 대화에 실려 들어가고, 모델이 그 지시를 따라 답을 만든다.

플러그인은 그 스킬을 배포하는 포장 단위다. 스킬 하나짜리 플러그인도 있고 여러 개를 묶은 것도 있는데, eli5는 스킬 하나만 들어 있는 아주 작은 플러그인이다.

이 스킬이 건드리는 문제

모르는 주제를 AI에게 물으면 답은 대개 긴 문단과 블릿으로 돌아온다. 내용이 틀린 것은 아니다. 문제는 눈높이다.

모델은 질문한 사람이 그 분야 용어를 이미 안다고 가정하고 설명한다. 그래서 답 안에 모르는 단어가 또 나오고, 그게 뭔데 하고 되묻는 왕복이 시작된다. 두세 번 왕복하다 보면 처음 궁금했던 것이 무엇이었는지 흐려지고, 읽다가 지친다.

형식도 매번 달라진다. 쉽게 설명해 줘라는 문장을 손으로 적어 넣어도, 어떤 날은 표가 나오고 어떤 날은 열 문단이 나온다. 같은 문구를 써도 결과가 복불복이다.

eli5는 이 두 가지를 지시문 안에 못박아 둔다. 눈높이는 아무것도 모르는 사람으로 고정하고, 형식은 그림 크게 글자 적게 HTML로 고정한다. 매번 손으로 적을 필요가 없어지고, 결과의 편차도 줄어든다.

바꿔 말하면 이 스킬은 읽는 설명을 보는 설명으로 옮기는 장치다. 그리고 그 일을 코드 한 줄 없이 지시문 한 장으로 한다.

설치 — 두 줄이면 끝난다

위 두 줄을 순서대로 실행하면 된다. 첫 줄은 커뮤니티 마켓플레이스를 등록하는 것이고, 둘째 줄은 그 마켓플레이스에서 eli5 플러그인을 설치하는 것이다.

Claude Code 안에서 실행해도 되고 터미널에서 claude 명령으로 실행해도 된다. 설치가 끝나면 프롬프트 창에 /eli5 를 치기 시작할 때 자동완성 목록에 뜬다. 탭을 눌러 넣으면 된다.

여기서 한 번 걸리는 지점이 마켓플레이스다. Claude Code에는 공식 마켓플레이스가 기본으로 등록돼 있는데, eli5는 거기 있는 것이 아니라 커뮤니티 마켓플레이스에 있다. 그래서 첫 줄로 직접 추가해 줘야 한다.

claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install eli5@claude-community

공식 마켓과 커뮤니티 마켓의 차이

둘 다 anthropics 계정의 저장소라 헷갈리기 쉽다. 그런데 성격이 다르다.

공식 쪽은 Anthropic이 직접 관리하는 플러그인 모음이고, Claude Code에 기본으로 등록돼 있어 별도 추가 없이 설치할 수 있다.

커뮤니티 쪽은 외부에서 제출한 플러그인이 모이는 곳이다. 저장소 설명에 따르면 이 저장소는 읽기 전용 거울이고, 실제 목록은 Anthropic 내부 검토 파이프라인에서 매일 밤 동기화된다. 여기에 올라온 플러그인은 제출 후 자동 보안 검사를 통과하고 배포 승인을 받은 것들이다. 이 저장소에 직접 올린 풀 리퀘스트는 자동으로 닫힌다.

그래서 정리하면 이렇다. eli5는 Anthropic 계정의 저장소에 있고 Anthropic 사람이 만들었지만, 기본 등록된 공식 마켓의 물건은 아니다. 설치할 때 기억할 것은 식별자 두 개뿐이다. eli5 그리고 claude-community.

저장소의 별 수도 이 차이를 보여 준다. 2026년 8월 29일 기준 공식 저장소가 약 3만 5천, 커뮤니티 저장소가 약 2천 5백이다. 커뮤니티 쪽 숫자가 작다고 해서 비공식 유출물이라는 뜻은 아니다. 등록 경로가 다를 뿐이다.

실제로 써 보면

슬래시 명령을 넣고 한 칸 띄운 다음, 궁금한 것을 평소 말하듯 적으면 된다. 뒤에 적은 문장이 그대로 스킬의 주제로 넘어간다.

비교를 위해 스킬 없이 같은 질문을 던져 보면 답이 이렇게 온다. 에이전트 루프, 모델, 권한, 컨텍스트 관리 같은 항목이 문단으로 나열되고, 설명은 자세하지만 처음 보는 용어가 그 안에 다시 섞여 있다. 배드락이나 버텍스 같은 이름이 나오면 클라우드를 모르는 사람은 거기서 또 막힌다.

eli5를 붙이면 응답이 HTML 파일 하나를 만드는 쪽으로 흐른다. 대화창에는 다섯 살 버전 요약이 짧게 뜨고, 옆에 HTML 파일이 생성된다. 그 파일을 열면 글자는 최소한으로 줄고 그림이 화면을 채운다.

예를 들어 에이전트 루프는 문단 대신 그림 네 개로 나뉘어 흐름이 보이고, 도구와 권한 같은 항목도 각각 한 덩어리로 배치된다. 구조를 모르는 사람이 전체 모양을 먼저 잡는 데는 이쪽이 빠르다.

차이를 한 문장으로 줄이면, 왼쪽은 다 읽어야 이해되고 오른쪽은 보기만 해도 얼개가 잡힌다는 것이다.

/eli5 클로드 코드가 어떤 식으로 동작하는지 알려줘

스킬 본문 열 줄을 뜯어보면

위가 파일 전문이다. 잘라 온 것이 아니라 이게 전부다. 열 줄, 321바이트.

맨 위 대시 세 개 사이는 프론트매터라고 부르는 머리말이다. name은 스킬 이름이고, description은 이 스킬을 언제 써야 하는지 모델에게 알려 주는 설명이다. 슬래시 명령으로 직접 부를 수도 있고, 사용자가 쉬운 그림 설명을 원한다고 말했을 때 모델이 스스로 이 스킬을 고를 수도 있다.

본문은 문장 두 개다. 첫째, 이 주제를 아무것도 모르는 사람에게 설명하듯 설명하라. 둘째, 설명할 때 HTML 아티팩트를 쓰되 그림은 크게 글자는 적게 하라. 앞 문장이 눈높이를 정하고 뒤 문장이 형식을 정한다.

마지막 줄의 $ARGUMENTS는 자리 표시자다. 슬래시 명령 뒤에 적은 문장이 이 자리에 그대로 채워져 모델에게 전달된다. 클로드 코드가 어떤 식으로 동작하는지 알려줘라고 적었다면 그 문장이 Topic 뒤에 들어간다.

이 파일은 Anthropic의 Claude Code 팀 소속 Thariq Shihipar가 2026년 8월 21일에 올렸다. 커밋 기록을 보면 플러그인을 추가하고, HTML 아티팩트라는 표현으로 문구를 고치고, 라이선스 항목을 정리하는 과정이 남아 있다. 라이선스는 MIT다.

---
name: eli5
description: Explain a topic like I'm a 5 year old. Use when the user types /eli5 <topic> or asks for a dead-simple picture explainer of how something works.
---

# eli5

Explain like I'm someone who knows nothing about this topic, using a HTML artifact with big pictures and few words.

Topic: $ARGUMENTS

어디에 쓰면 좋은가

쓸 자리를 세 장면으로 정리할 수 있다.

첫째, 비개발 동료에게 설명할 때다. 이번에 도입한 도구가 무엇이냐는 질문이 기획팀에서도 마케팅팀에서도 운영팀에서도 온다. 사람마다 배경 지식의 깊이가 다른데 매번 말로 눈높이를 맞추기는 어렵다. 그림 한 장을 만들어 건네면 준비 시간이 거의 들지 않는다.

둘째, 신입 온보딩 첫날이다. 아키텍처 문서 오십 장을 넘겨 주고 읽어 보라고 하는 관행이 흔한데, 분량이 많다고 이해가 되지는 않는다. 회사마다 쓰는 용어가 달라 첫 주에는 오히려 더 막힌다. 같은 내용을 그림 한 장으로 먼저 보여 주고 문서는 그다음에 읽게 하는 편이 순서로 맞다.

셋째, 장애가 난 다음 날이다. 회고를 써야 하고 타임라인은 복잡한데, 그 자리에 비개발 조직도 함께 앉는다. 무슨 일이 어떤 순서로 일어났고 지금 어디까지 왔는지를 그림으로 그려 두면 회의 시간이 줄어든다.

세 장면의 공통점은 하나다. 듣는 사람의 눈높이를 맞춰야 한다는 것. 어려운 용어로 한 시간을 설명하는 것보다 그림 한 장이 빠를 때가 있다.

알고 써야 할 두 가지

첫째, 이 스킬은 내용이 맞는지 검증하지 않는다. 고정하는 것은 눈높이와 형식이지 사실 여부가 아니다.

그리고 여기에 함정이 있다. 그림이 그럴듯할수록 틀린 내용도 그럴듯해 보인다. 문단으로 적힌 오류는 읽다가 걸리지만, 도식으로 그려진 오류는 이미 검증된 것처럼 읽힌다. 남에게 넘기기 전에 원본과 한 번 대조하는 단계를 절차로 넣어 두는 편이 안전하다. 특히 사내 아키텍처나 장애 타임라인처럼 사실 관계가 중요한 자료라면 더 그렇다.

둘째, 결과물이 HTML 파일이다. 브라우저로 열어 보기에는 좋지만 슬랙이나 노션에 그대로 붙여 넣을 수는 없다. 공유하려면 화면을 캡처하거나 파일을 따로 보내는 단계가 한 번 더 필요하다.

그래서 기대치를 정확히 잡는 편이 낫다. 완성된 공유 문서가 나오는 도구는 아니다. 말로 설명하는 것보다 그림이 낫다는 정도이고, 그 정도로도 충분히 쓸모가 있다.

여기서 가져갈 것

eli5 자체보다 이 스킬이 보여 주는 방식이 더 오래 남는다.

스킬은 특별한 기술 장치가 아니라 지시문이다. 그리고 지시문은 명확하고 간결할수록 결과가 안정적이다. eli5가 하는 일은 큰데 파일은 열 줄이다. 길게 쓴다고 잘 듣는 것이 아니라는 뜻이다.

요즘 도는 스킬들이 대체로 짧은 이유가 여기에 있다. 무엇을 시킬지, 결과를 어떤 형식으로 낼지, 이 두 가지만 분명하면 나머지는 모델이 채운다.

직접 만들 때도 같은 순서로 시작하면 된다. 반복해서 손으로 적고 있는 지시가 무엇인지 찾고, 그것을 두세 문장으로 줄여 파일 하나에 적는다. 눈높이와 형식을 못박는 것만으로도 결과의 편차가 줄어든다.