SlideOps 소개
문서를 쓰는 일은 더 이상 병목이 아닙니다. SlideOps를 만든 Gleb Lukicov는 저장소 하나를 코딩 에이전트에게 넘기면 정확한 온보딩 자료 스무 페이지를 10분 안에 얻을 수 있게 됐다고 말합니다. 문제는 그 다음입니다. 생성된 문서는 만들어진 순간부터 현실과 어긋나기 시작하는데, 파이프라인 어디에도 그 사실을 알려주는 장치가 없습니다. 저자는 이 상황을 "이제 우리는 누구도 읽어낼 수 없는 속도로 자신 있게 틀린 자료를 만들어낼 수 있게 됐다" 라고 적었습니다. 데이터베이스 마이그레이션을 두 번 실행한다고 설명해 둔 덱이, 실제로는 열 번씩 실행하게 된 1년 뒤에도 여전히 두 번이라고 말하고 있는 상황이 그 예입니다.
SlideOps는 생성된 문서를 빌드 산출물(build artifact) 로 취급합니다. 저자는 저장소의 다른 빌드 산출물이 모두 자기 출처를 알고 있다는 점을 지적합니다. 컴파일된 바이너리에는 소스가 있고, 락파일(lockfile)에는 매니페스트가 있으며 둘이 어긋나면 빌드가 실패합니다. 반면 코드에서 생성한 문서에는 출처(provenance)도, 다시 만들 계기도, 그것을 검사할 테스트도 없습니다. SlideOps는 그 세 가지를 인용(citation) 하나로 채웁니다. 슬라이드에 인용한 코드 조각마다 파일 경로와 줄 범위, 그리고 빌드 시점에 그 줄들이 어떤 내용이었는지를 나타내는 해시를 함께 기록하고, 덱 전체에는 어느 커밋에서 만들어졌는지를 남깁니다.
SlideOps는 Claude Code와 호환 코딩 에이전트가 읽는 에이전트 스킬(Agent Skill) 두 개로 배포됩니다. 저장소에는 슬라이드를 만드는 slideops 스킬과 URL 해시로 슬라이드를 넘기는 HTML 덱을 검증된 PDF로 내보내는 slides-to-pdf 스킬이 함께 들어 있고, 함께 실리는 파이썬 스크립트 두 개는 표준 라이브러리만 사용합니다. Claude Code 외에 Codex, Copilot CLI, OpenCode에서도 같은 SKILL.md를 그대로 읽으므로 에이전트별로 옮겨 적을 것이 없습니다.
SlideOps가 기존 슬라이드 생성 도구와 다른 점
저자는 시각 디자인에서는 frontend-slides가 훨씬 낫다고 스스로 적어 두었습니다. Star 28,000여 개에 템플릿 시스템 46종을 갖춘 저장소이고, 저장소의 Credits 절에서도 시각 우선 테마 선택의 선행 사례로 꼽혀 있습니다. 두 프로젝트가 나누어 가진 역할은 다음과 같습니다:
| 항목 | SlideOps | frontend-slides |
|---|---|---|
| 슬라이드 콘텐츠 | 저장소의 코드에서 인용해 채웁니다 | 사용자가 콘텐츠를 준비한다고 전제합니다 |
| 템플릿과 테마 | 슬라이드 패턴 13종, 테마 4종 | 템플릿 시스템 46종 |
| 저자가 밝힌 각자의 강점 | 슬라이드를 콘텐츠와 계속 맞춰 두는 것 | 시각 디자인 |
저자는 또 하나의 선행 사례로 presentation-skills를 들면서, 렌더링한 뒤 눈으로 확인하는 시각 품질 검사 루프를 그 프로젝트가 먼저 개척했고 SlideOps도 같은 루프에 의존한다고 밝힙니다. SlideOps의 몫으로 남겨 둔 부분은 이름의 뒷절반인 Ops, 즉 저장소에 근거한 콘텐츠와 그것이 여전히 성립하는지를 나중에 값싸게 물어보는 방법입니다.
PyTorchKR에도 코딩 에이전트로 HTML 슬라이드를 만드는 도구와 스킬 소개가 여러 편 올라와 있습니다. 테마 36종과 레이아웃 31종을 갖춘 html-ppt, 편집기까지 HTML 파일 하나에 담은 Bento, 만든 슬라이드를 드래그로 고치는 slides-grab이 그런 예입니다. SlideOps가 이들과 다른 점은 덱을 만든 다음의 문제, 즉 그 덱이 코드와 계속 맞는지를 스킬의 절반으로 삼았다는 것입니다.
SlideOps의 인용 기반 신선도 검사
SlideOps가 슬라이드에 남기는 표시는 HTML 속성 두 개입니다. 인용한 조각을 담은 요소에 다음과 같이 붙습니다:
<pre class="code" data-src="backend/app/main.py:40-58" data-sha256="a1b2c3d4e5f6">…</pre>
그리고 덱마다 한 번, <head>에 빌드 지점을 남깁니다:
<meta name="slideops-build" content="commit=077a837 date=2026-08-26 repo=slideops">
data-src는 저장소 기준 상대 경로에 1부터 세는 줄 범위를 붙인 값이고, 범위를 생략하면 파일 전체가 인용 대상이 됩니다. data-sha256은 빌드 시점의 그 소스 줄들을 개행으로 이어 구한 SHA-256의 앞 12자입니다. 해시 대상이 슬라이드에 보이는 조각이 아니라 원본 소스 줄이라는 점이 중요합니다. 슬라이드에 올리는 조각은 보통 …로 줄여 담기 때문에, 조각과 파일이 바이트 단위로 같아지는 일은 애초에 없습니다.
빌드 커밋을 함께 남기는 이유는 따로 있습니다. check는 그 커밋에서 원래 줄들을 git show로 꺼내 와 지금 파일과 대조하기 때문에, 커밋이 없으면 CURRENT와 CHANGED만 남고 차이 표시, 이동 감지, 누가 바꿨는지가 모두 사라집니다. 덱을 다 만든 뒤 --stamp를 한 번 실행하는 것이 나머지 기능 전체의 전제 조건인 셈입니다.
이 속성들을 사람이 손으로 계산하지 않는 이유도 문서에 적혀 있습니다. 틀린 해시는 없는 해시보다 나쁩니다. 몇 달 뒤 CHANGED 상태로 드러나는데, 그때는 코드가 움직인 것인지 빌드가 엉성했던 것인지 아무도 구분할 수 없습니다. 그래서 cite.py가 두 속성을 만들어 주고, 저장소의 실제 HEAD와 오늘 날짜로 빌드 지점까지 찍어 줍니다:
$ python3 skills/slideops/scripts/cite.py app/main.py:40-58 --repo .
data-src="app/main.py:40-58" data-sha256="a1b2c3d4e5f6"
cite.py는 인용할 줄이 슬라이드 패턴에 비해 너무 길 때도 함께 경고합니다. 코드 블록은 넘치는 부분을 조용히 잘라내기 때문에, 두 칼럼 패턴의 절반 폭은 한 줄 약 65자, 전체 폭은 약 95자가 예산으로 정해져 있습니다. 조각을 줄일 때는 …로 줄 단위를 덜어내고, 줄 안에서 고쳐 쓰는 것은 인용을 바꾸는 것으로 봅니다.
몇 달 뒤에 할 일은 덱 폴더를 한 번 훑는 것뿐입니다. 디렉토리를 주면 하위까지 재귀로 훑고, 인용이 없는 HTML은 건너뜁니다:
$ python3 check.py docs/slides/ --repo .
slide 7 PIPELINE backend/app/main.py:40-58 CURRENT
slide 12 MIGRATIONS backend/alembic/env.py:18-31 MOVED same content, now at lines 22-35
slide 15 RATE-LIMIT backend/app/middleware/rate.py CHANGED 4 line(s) differ
1 current, 2 stale, 3 cited in total.
상태는 다섯 가지이고, skills/slideops/references/freshness.md에 정의되어 있습니다:
| 상태 | 의미 | 해야 할 일 |
|---|---|---|
CURRENT |
인용한 줄이 바이트 단위로 같습니다 | 없습니다 |
MOVED |
내용은 같고 줄 번호만 달라졌습니다 | data-src를 갱신하고 슬라이드의 글은 그대로 둡니다 |
CHANGED |
인용한 줄의 내용이 달라졌습니다 | 차이를 읽고 슬라이드의 주장이 여전히 성립하는지 판단한 뒤 다시 인용합니다 |
MISSING |
파일이 사라졌습니다 | 슬라이드가 더는 유효하지 않을 수 있으므로 파일이 어디로 갔는지 찾아본 뒤, 사용자에게 묻고 지웁니다 |
UNVERIFIED |
해시가 없거나 빌드 커밋이 이 저장소에 없습니다 | 어긋남이 아니라 빌드 결함이므로 다시 인용합니다 |
저자가 가장 중요하게 꼽는 것은 MOVED와 CHANGED의 구분이고, 파일 하나를 통째로 비교하는 방식으로는 얻을 수 없는 정보라고 강조합니다. 파일 위쪽에 import 몇 줄이 추가되어 인용의 줄 번호만 밀린 경우가 MOVED이며, 코드 자체는 바이트 단위로 같습니다. check는 빌드 커밋에서 꺼낸 원래 블록이 지금 파일 안에 그대로 남아 있는지를 찾아 이 둘을 가릅니다. MOVED에서는 속성 두 개만 갱신하면 끝이고, 산문을 건드리거나 다시 렌더링하거나 토큰을 쓸 이유가 없습니다. 반면 CHANGED는 로직이 달라진 경우라, 그 조각 옆의 문장이 여전히 참인 문장인지를 사람 또는 판단을 위임받은 에이전트가 결정해야 합니다. 이 구분이 없는 도구는 코드가 서른 줄 아래로 밀렸을 뿐인 상황까지 경고로 올려서, 사람들이 무시하는 법을 배우게 되는 잡음을 만듭니다.
SlideOps가 감지와 수리의 비용을 나누는 방식
SlideOps의 설계 전체를 결정한 제약은 비용입니다. 저자는 코드가 빠르게 움직이므로 변경마다 토큰을 쓰는 유지 장치는 결국 꺼진다고 봅니다. 문서를 맞춰 두는 일이 커밋마다 에이전트가 저장소를 다시 읽는 것을 뜻한다면, 실제로 돈이 들고 모두의 작업 흐름에 지연이 붙으며 한 달 안에 비활성화되는 장치를 만든 셈입니다. 그래서 SlideOps는 비용선을 따라 두 갈래로 뚜렷하게 나뉩니다:
| 명령 | 비용 | |
|---|---|---|
| 감지 | check.py docs/slides/ --repo . |
표준 라이브러리만 사용하고, 모델도 네트워크도 토큰도 쓰지 않습니다 |
| 수리 | check.py --json 결과를 에이전트에게 넘김 |
토큰과 리뷰가 들고, 어긋난 슬라이드로 범위가 한정됩니다 |
감지는 해시 비교와 git show 한 번이라 사실상 공짜입니다. 그래서 풀 리퀘스트마다, 세션이 시작될 때마다, 예정된 일괄 점검마다, 문서 100개를 가진 저장소에서도 원하는 만큼 실행할 수 있습니다. 수리는 비싼 쪽이므로 사람이 일부러 내리는 결정으로 남습니다. 그리고 토큰을 쓰는 순간이 오면, 검사가 이미 어느 슬라이드 세 장을 봐야 하고 각각 무엇이 바뀌었는지를 에이전트에게 알려 둔 상태입니다. 저장소를 읽어 무엇이 달라졌는지 알아내는 작업에는 비용을 내지 않습니다.
--json이 만드는 것은 완전한 수리 지시서입니다. 어긋난 인용마다 상태, 통합 형식 차이(unified diff), 갱신된 data-src와 data-sha256, 현재 소스, 그리고 그 어긋남을 일으킨 커밋들이 함께 나옵니다. 저자는 마지막 항목이 왜 필요한지를 따로 설명합니다. 차이만 보면 세 줄이 바뀌었다는 사실까지만 알 수 있지만, 커밋 제목은 그것이 rename helper for clarity였는지 drop the retry branch였는지를 알려주고, 거의 같은 차이라도 필요한 문서 작업은 완전히 달라집니다. 아래는 저자가 제시한 위임 예시입니다:
claude -p "Refresh the stale slides in docs/slides/. $(cat drift.json)
For each: read the diff and the commit subjects, decide whether the slide's CLAIM is still
true, then either re-quote (MOVED) or rewrite the slide (CHANGED)..." \
--allowedTools "Read,Edit,Bash"
자동화를 어디에 둘지도 저자가 따로 정해 둔 부분입니다. 눈에 먼저 들어오는 자리는 pre-commit 훅인데, 여기서 문서 검사가 커밋을 막으면 급하지 않은 문제 때문에 모든 커밋에 세금을 매기는 셈이고 결국 모두가 --no-verify를 붙이는 법을 배웁니다. 문제는 위치가 아니라 차단이어서, 경고만 찍고 항상 0으로 끝나는 pre-commit 훅은 저자가 권장 예시로 함께 실어 두었습니다. 실제로 게이트를 세울 자리는 main으로 향하는 풀 리퀘스트이고, 보고 전용으로 시작하기를 권합니다:
- name: Are the decks still true?
run: python3 tools/slideops-check.py docs/slides/ --repo . --suggest --exit-zero
| tee -a "$GITHUB_STEP_SUMMARY"
무엇이든 낡았으면 종료 코드가 1이 되고, --exit-zero는 그것을 0으로 눌러 아무도 막히지 않게 합니다. 어긋남과 그 해결책은 풀 리퀘스트 요약에 남고, 나중에 다른 작업이 문서 전체를 다시 맞출 수 있습니다. check.py는 의존성 없는 단일 파일이므로, 기여자 모두가 스킬을 설치했기를 기대하는 대신 이 파일을 저장소의 tools/에 직접 넣어 두라는 권고가 함께 적혀 있습니다.
자동화 단계는 references/automation.md에 네 개로 정리되어 있습니다. 필요할 때 직접 실행하는 것이 기본이고 대부분의 덱은 여기서 끝납니다. 그다음이 위의 풀 리퀘스트 검사이며, 보고가 한동안 조용해진 뒤에 팀이 실제로 의존하는 덱 한두 개에서만 --exit-zero를 떼라고 권합니다. 세 번째는 에이전트에게 수리를 맡기는 예정 작업인데, 토큰을 쓰기 전에 공짜인 쪽으로 한 번 걸러 두면 조용한 달은 비용이 0입니다:
python3 tools/slideops-check.py docs/slides/ --repo . --quiet || refresh_decks
마지막 단계가 에이전트 훅이고, 여기서는 알림 이상을 하지 않습니다. 막는 훅은 꺼지는 훅이기 때문입니다. SessionStart에서 --quiet로 실행하면 전부 최신일 때는 아무것도 출력하지 않고 아닐 때만 한 줄을 찍습니다. 그리고 에이전트가 슬라이드를 고쳤으면 곧장 푸시하지 않고 풀 리퀘스트를 여는 것을 권하는데, 문서 갱신도 그것을 유발한 코드와 같은 수준의 리뷰를 받아야 하는 내용 변경이라는 이유입니다.
모든 덱이 이런 검사를 받을 만한 것은 아닙니다. 어떤 덱을 자동화하고 어떤 덱을 그냥 낡게 둘지도 표로 갈라 두었습니다:
| 덱 | 자동화할 것인가 |
|---|---|
| 온보딩, 아키텍처, README에서 링크한 문서 | 풀 리퀘스트 검사와 예정된 갱신까지 |
| 팀이 계속 돌아와 보는 하위 시스템 심층 덱 | 풀 리퀘스트 검사, 보고 전용으로 |
| 스프린트 업데이트, "3월에 나간 것" | 하지 않습니다. 한 시점의 기록이고 원래 멈춰 있어야 하는 문서입니다 |
| 한 번 발표하고 끝난 콘퍼런스 발표 자료 | 하지 않습니다 |
신선도 검사는 지금 상태를 설명한다고 주장하는 문서에만 쓰인다는 것이 이 표의 판정 기준입니다.
SlideOps가 만드는 덱의 구조와 테마
덱 하나가 자기 완결적인 HTML 파일 한 개입니다. 한 화면에 1280×720 슬라이드 한 장이 들어가고, 빌드 단계도 CDN도 없어서 오프라인에서 열립니다. 탐색은 방향키와 클릭, URL 해시 딥링크, Esc로 켜고 끄는 개요 그리드(#overview로 직접 링크됩니다), N 키로 여는 발표자 노트로 이루어지며 진행 막대와 슬라이드 번호가 함께 표시됩니다. 발표자 노트는 화면과 내보낸 파일에는 나타나지 않습니다. 슬라이드 패턴은 13종으로, 표지, 목차, 섹션 구분, 산문과 카드, 참조 표, 전후 코드 비교, 주석 달린 코드 조각(절반 폭과 전체 폭), 흐름 다이어그램, 레인 비교, 이미지와 캡션, 대화 말풍선, 마무리가 준비되어 있습니다.
이메일에 첨부해 돌릴 수 있다는 것도 단일 파일의 이점인데, 여기에는 조건이 하나 있습니다. 이미지는 기본적으로 상대 경로로 참조되므로, 덱만 떼어 내 배포할 때는 이미지를 data:image/png;base64,…로 파일 안에 심어야 자기 완결성이 유지됩니다. 이미지 바이트가 3분의 1쯤 늘어나므로, 그런 덱은 이미지를 몇 장으로 제한하는 편이 좋습니다.
테마는 네 가지이고, 한 덱의 모든 색이 :root 토큰 한 블록에서 color-mix()로 파생됩니다. 그래서 테마를 바꾸는 일이 블록 하나를 치환하는 일과 같습니다. 기본값인 Ledger Light는 따뜻한 종이 톤 표면에 짙은 올리브 강조색을 써서 밝은 방과 프로젝터, 인쇄물에서 잘 읽히고, Ledger Dark는 같은 계열을 유지한 채 에스프레소 톤 표면과 부드러운 금색 강조색으로 뒤집은 짝입니다. Midnight는 짙은 네이비에 하늘색 강조색을 얹은 차분한 다크이고, Graphite는 검정에 가까운 중성색에 앰버 강조색으로 대비가 가장 높아 프로젝터에 안전합니다. 브랜드 색을 쓰려면 사이트나 스타일 가이드를 실제로 받아 와 그 안의 값을 토큰 역할에 매핑하며, 설명만 듣고 색을 짐작해 넣지 않습니다. 아래 두 장은 같은 덱, 같은 마크업, 같은 콘텐츠를 :root 블록 하나만 바꿔 렌더링한 결과입니다:
Mermaid 다이어그램은 런타임(runtime)에 불러오지 않고 빌드 시점에 인라인 SVG로 미리 렌더링한 뒤 덱 자체의 토큰으로 테마를 입힙니다. 덱이 단일 파일이자 네트워크 없이 열리는 상태를 유지해야 하기 때문입니다. 박스가 6개 이하인 선형 파이프라인은 템플릿에 들어 있는 흐름 박스로 충분하고, 시퀀스 다이어그램이나 분기 그래프, 스키마 관계처럼 흐름 박스로는 그릴 수 없는 그림에만 Mermaid를 씁니다.
SlideOps가 덱을 넘기기 전에 검증하는 방법
SlideOps는 덱이 완성됐다고 선언하기 전에 모든 슬라이드를 헤드리스 Chrome으로 이미지로 렌더링해 한 장씩 눈으로 확인하는 단계를 필수로 둡니다. 저자는 이 단계를 처음 실행하는 덱마다 실제 버그가 잡힌다고 적으면서, 매번 걸리는 항목을 references/verification.md에 나열해 두었습니다. 하단 탐색 막대에 글자나 이미지가 겹치는 경우, 카드 그리드가 남은 세로 공간을 채우려고 늘어나는 경우, 표와 코드 블록이 카드 밖으로 넘치는 경우, 그리고 원래 폴더에서는 열리지만 HTML을 다른 곳으로 복사하는 순간 깨지는 상대 경로 이미지입니다.
같은 단계에서 인용도 함께 확인합니다. 덱을 넘기기 전에 check.py가 모든 인용을 CURRENT로 보고해야 하고, 그 밖의 상태는 미래의 문제가 아니라 빌드 결함입니다. CHANGED가 나오면 인용한 뒤 코드가 움직였거나 해시를 손으로 계산한 것이고, UNVERIFIED는 조각에 해시가 아예 없는 상태입니다. 만든 날에 이미 낡은 덱을 넘기지 않겠다는 것이 이 확인의 목적입니다.
PDF는 slides-to-pdf 스킬이 맡습니다. 슬라이드를 URL 해시로 넘기는 덱에는 브라우저의 인쇄 기능이 통하지 않는데, 인쇄하면 화면에 보이는 슬라이드 한 장만 잡히기 때문입니다. 그래서 모든 슬라이드를 2배 크기로 스크린샷하고, 그것을 페이지 단위로 나눈 문서에 담아 PDF로 인쇄한 뒤, 완성된 PDF를 pypdfium2로 다시 이미지로 렌더링해 확인합니다. 헤드리스 Chrome은 로컬 PDF를 래스터화할 수 없고, PDF는 페이지 수가 맞으면서 이미지 페이지만 조용히 비어 있을 수 있습니다.
SlideOps가 슬라이드에 올리지 않는 것
덱은 저장소 밖으로 나가는 자료이므로, SlideOps는 슬라이드 위의 모든 것을 공개 정보로 취급합니다. 비밀값과 키, 자격증명 파일, 운영 로그, 실제 고객 데이터는 슬라이드 내용을 위해 읽지 않습니다. 인용한 내용에서는 토큰과 사설 호스트명, 개인정보를 가려내고, 민감해 보이는 항목은 포함하기 전에 묻고, 검증 단계의 끝에서 HTML과 PDF, 발표자 노트, 삽입된 모든 이미지에 가림 검사를 한 번 실행합니다. 인테이크에서 누가 이 덱을 볼 것인지 묻는 이유도 여기 있습니다. 사내 스탠드업과 외부 콘퍼런스 발표는 요구 수준이 다릅니다.
가림 검사에는 정규식으로 훑는 부분과 눈으로 봐야 하는 부분이 나뉘어 있습니다. 정규식은 그물이지 판정이 아니라서, tokenized 같은 단어에 걸리는 것은 넘기고 실제 키에 걸리는 것은 전부 멈춥니다. 눈으로 볼 항목으로는 삽입한 모든 이미지의 창 제목과 파일 트리, 브랜치 이름, 티켓 번호, 알림 배너, HTML 주석, 그리고 발표자 노트가 지정되어 있습니다. 노트는 화면과 내보낸 파일에서는 보이지 않지만 HTML 안에 그대로 실려 나가므로, 파일을 여는 사람은 누구나 읽을 수 있습니다. PDF도 HTML과 별개의 산출물이라 따로 한 번 더 봅니다. 슬라이드에서 잘라낸 텍스트가 그것을 렌더링한 페이지에는 남아 있을 수 있기 때문입니다. 덱이 조직 밖으로 나간다면 보내기 전에 사용자가 산출물을 직접 확인하게 하라는 지시까지 들어 있는데, 이유는 한 줄입니다. 이미 공유한 덱은 되돌릴 수 없습니다.
실행 환경의 기본값도 같은 방향입니다. 저장소 내용으로 만든 페이지를 렌더링하는 일이므로 Chrome 샌드박스를 켠 상태로 두고 어디에서도 --no-sandbox를 넘기지 않으며, --no-sandbox가 넘어가는 경로를 발견하면 그것을 버그로 신고해 달라고 SECURITY.md에 적어 두었습니다. 프로젝트 자신의 CI가 이 규칙을 지키는 방식이 그 예입니다. Ubuntu 24.04 러너는 Chrome 샌드박스가 필요로 하는 권한 없는 사용자 네임스페이스를 AppArmor로 막는데, 문서에 남겨 둔 예외를 쓰는 대신 러너의 sysctl 값을 되돌려 샌드박스를 살려 둡니다.
내려받는 것도 최소로 묶여 있습니다. Mermaid CLI는 버전을 11.4.2로 고정하고 이미 설치돼 있으면 건너뛰며, PDF 검증기는 기존 pypdfium2 설치본을 먼저 찾습니다. 이 둘은 선택 사항이라 덱을 만드는 데는 필요하지 않습니다. 반면 시각 검증에 쓰는 헤드리스 Chrome은 필요한 쪽이어서, 기존 설치본을 찾지 못하면 Chromium을 설치하는 경로로 넘어갑니다.
어긋남 검사가 의미를 가지려면 덱이 만들어진 날에는 그 내용이 참이었어야 합니다. SlideOps가 정확성 계약이라고 부르는 규칙이 그 자리를 맡습니다:
| 항상 하는 것 | 절대 하지 않는 것 |
|---|---|
| 실제 파일의 코드 조각을 그대로 복사한 뒤 HTML 이스케이프 | 캡션을 채우려고 차트를 만들거나 수치를 지어내기 |
| 집계 수치를 원본 데이터에서 다시 계산 | 슬라이드에 맞추려고 인용한 줄을 고쳐 쓰기 |
출시했다는 주장을 git log의 실제 커밋에 근거 |
계획 단계의 작업에 완료 표시를 붙이기 |
| 다이어그램을 실제 import와 호출 지점을 따라 그리기 | 코드가 반박하는 문서를 신뢰하기 |
저장소의 문서가 자기 코드와 어긋날 때는 코드를 따르고, 그 불일치 자체를 슬라이드의 메모로 남깁니다. 다만 검사가 전부 통과한 덱이 곧 옳은 덱은 아니라는 단서도 저자가 직접 달아 두었습니다. check는 인용한 소스가 코드와 여전히 같은지만 확인하므로, 조각 주변의 산문이 조용히 틀리게 됐는지, 지난 분기에 추가된 하위 시스템이 슬라이드에서 빠졌는지, 아키텍처 그림이 이미 허구가 됐는지는 보지 못합니다.
SlideOps 설치와 사용 방법
저장소 이름과 플러그인 식별자는 프로젝트 이름과 달리 slideops이므로, 아래 명령에서는 그 이름을 그대로 씁니다. Claude Code에서는 저장소 자체가 마켓플레이스라 두 줄이 설치의 전부이고, 네 가지 설치 경로 중에서 스스로 최신 상태를 유지하는 유일한 경로입니다:
/plugin marketplace add glukicov/slideops
/plugin install slideops@slideops
한 번은 손이 가는 설정이 있습니다. 서드파티 마켓플레이스는 자동 갱신이 기본으로 꺼져 있으므로, /plugin의 Marketplaces에서 한 번 켜 두지 않으면 /plugin marketplace update slideops를 직접 실행할 때만 새 버전이 도착합니다.
Codex와 Copilot CLI, OpenCode를 쓰거나 그냥 체크아웃해서 쓰려면 설치 스크립트 한 줄입니다:
git clone https://github.com/glukicov/slideops && cd slideops
./install.sh
~/.agents/skills가 공용 관례로 굳어져서 목적지 두 곳이면 에이전트 네 개를 모두 지원할 수 있습니다. 기본 동작은 심볼릭 링크이고, 고정된 스냅샷이 필요하면 --copy, 무엇이 바뀔지 먼저 보려면 --dry-run, 특정 디렉토리에만 넣으려면 --dest를 씁니다. 스킬의 frontmatter에 쓰인 name, description, license, compatibility, metadata는 네 에이전트가 모두 받아들이는 공통 부분집합이고, allowed-tools는 선언하지 않아 셸 명령에 대해서는 각 에이전트가 자기 확인 규칙을 적용합니다. 설치 경로별 갱신 방법과 에이전트별 탐색 위치는 저장소의 docs/install.md에 표로 정리되어 있습니다.
준비물은 많지 않습니다. 시각 검증과 PDF 내보내기에는 헤드리스(headless) Chrome이 필요하고, Playwright Chromium 캐시나 시스템 Chrome 설치본이면 됩니다. Mermaid 다이어그램을 원할 때만 네트워크에 접근하는 npx가 추가로 필요하며, Chrome이 이미 있으면 나머지는 오프라인에서 동작합니다. 함께 실린 스크립트는 표준 라이브러리만 import하므로 파이썬 인터프리터 하나면 충분하고, PDF까지 만들 때만 검증에 쓰는 pypdfium2가 하나 더 필요합니다. 이미 설치돼 있으면 그대로 쓰고, 없으면 버리는 가상환경에 버전을 고정해 한 번 내려받습니다.
파이썬 버전은 두 갈래로 봐야 합니다. 저장소를 직접 개발하려면 3.14가 필요하지만, 배포되는 스크립트 두 개는 argparse만 쓰고 문법을 보수적으로 유지해 3.14보다 훨씬 낮은 인터프리터에서도 실행됩니다. 개발용 스크립트가 쓰는 typer 같은 서드파티 의존성은 배포본에 절대 들어가지 않는다는 규칙이 저장소의 docs/development.md에 명시돼 있습니다.
사용은 저장소를 열고 말을 건네는 것으로 시작합니다. make slides about this repo 라고 하면 SlideOps가 2분쯤 저장소를 훑은 뒤, 여섯 개를 넘지 않는 질문을 한 번에 던집니다. 주제(찾아낸 구체적 후보 3~4개를 각각 왜 지금인지와 함께 제안합니다), 청중과 발표 자리, 길이, 디자인, 덱이 참고해도 되는 범위와 볼 사람, 그리고 PDF 내보내기와 Mermaid 다이어그램, 출력 경로 세 가지 토글입니다. 출력 폴더에 이미 있는 덱은 후보에서 빠지고, 그 덱 이후로 의미 있는 커밋이 쌓였으면 기존 덱을 업데이트하는 안이 따로 후보로 올라옵니다.
길이를 고를 때 기준이 되는 표는 다음과 같습니다:
| 덱 종류 | 발표 시간 | 슬라이드 수 | 섹션 구분 슬라이드 |
|---|---|---|---|
| 라이트닝 업데이트 (한 주제, 한 회의) | 약 5분 | 8~15장 | 없이 바로 본문으로 |
| 심층 덱 (하위 시스템이나 기능 하나) | 약 20분 | 12~20장 | 하위 주제가 2개 이상일 때만 |
| 전반 개요와 온보딩 | 약 45분 | 20~35장 | 주요 섹션마다 한 장 |
밀도 기준은 슬라이드 한 장에 아이디어 하나이고, 장수를 아끼려고 두 아이디어를 한 장에 몰지 않습니다. HTML을 쓰기 전에 승인할 개요가 먼저 나오는데, 저자는 이 지점을 가장 레버리지가 큰 체크포인트로 꼽습니다. 30초짜리 검토가 엉뚱한 주제 여섯 개를 둘러싸고 만든 슬라이드 25장을 다시 만드는 것보다 훨씬 싸기 때문입니다. 원하는 것이 이미 정해져 있으면 deep dive on the auth subsystem, Ledger Dark theme, 15 slides, with a PDF 처럼 한 줄로 인테이크를 건너뛸 수 있습니다.
몇 달 뒤 같은 저장소에서 is the architecture deck still accurate? 라고 물으면, 에이전트가 덱 폴더를 훑어 상태별로 분류합니다. 단순히 이동한 것은 다시 인용하고, 주장이 더는 성립하지 않을 수 있는 슬라이드를 표시합니다. 덱을 다시 만들지 않고 어긋난 부분을 고치므로, 처음에 승인한 진행 속도와 서사가 그대로 남습니다. 보고할 때는 고친 슬라이드와 어긋남을 일으킨 커밋을 이름으로 적고, 차이가 났지만 여전히 참이라고 판단한 항목을 따로 밝히도록 되어 있습니다. 사람이 다르게 볼 수 있는 자리이기 때문입니다.
SlideOps는 누구에게 유용한가
저장소를 근거로 온보딩 자료나 아키텍처 리뷰, 스프린트 업데이트 덱을 반복해서 만들고 그 덱을 몇 달 뒤에도 다시 쓰는 팀에게 SlideOps가 잘 맞습니다. 산출물이 HTML 파일 한 개라 사내 위키나 이메일로 공유하기 쉽고, 감지 쪽 비용이 0이라 문서를 수십 개 가진 저장소에서도 CI에 걸어 두는 부담이 없습니다.
PowerPoint나 Google Slides 파일이 최종 산출물이어야 하는 조직에서는 SlideOps가 적절한 선택지가 아닙니다. 나오는 것은 HTML 덱과 그것을 렌더링한 PDF뿐입니다. 시각 디자인이 이번 발표에서 가장 중요하다면 템플릿 수가 더 많은 도구를 고르는 편이 낫고, 이것은 저자 본인이 밝혀 둔 한계입니다. 성숙도 면에서는 1.0.0이 첫 공개 릴리스라는 점을 감안해 살펴보는 것이 좋습니다. 저자는 독립 에이전트들이 스킬을 그대로 따라 실행하며 마찰 보고서를 제출하게 하는 과정을 세 차례 반복하고, 실제 저장소를 상대로 덱 일곱 개를 만들어 본 뒤에 공개했다고 CHANGELOG에 적었습니다.
운영 쪽에서 함께 볼 것이 하나 더 있습니다. SECURITY.md에 미리 밝혀 둔 대로 이 프로젝트는 1인 프로젝트이고, 보안 신고에 대한 첫 응답은 시간 단위가 아니라 날 단위입니다. 지원 범위도 최신 릴리스 하나뿐이라 유지보수 브랜치 없이 수정이 새 버전으로 나갑니다. 백포트가 가능한 지원 창구를 도입 심사에서 요구하는 조직이라면 SlideOps는 아직 그 요건을 채우지 못합니다.
테스트 쪽 근거도 함께 볼 만합니다. tests/에는 인용 파서와 상태 분류, JSON 수리 지시서를 확인하는 검사가 들어 있고, 일회용 git 저장소를 만들어 코드를 옮기고 고치고 지운 뒤 도구가 실제로 어떤 상태를 보고하는지 확인하는 종단 검사도 있습니다. CI에는 이식성 작업이 따로 있어서, 사용자가 설치하는 것과 같은 방식으로 스킬을 복사한 뒤 두 스크립트를 아무것도 설치하지 않은 파이썬에서 실행합니다. ./install.sh --copy가 ~/.claude/skills와 ~/.agents/skills 양쪽에 두 스킬을 실제로 놓는지까지 확인하므로, 스크립트가 의존성을 하나라도 얻으면 누군가 그것을 배포하기 전에 이 작업이 실패합니다. 스모크 작업은 모든 슬라이드를 렌더링하고 검증된 PDF까지 내보내며, 실패하면 렌더링 결과를 산출물로 올립니다. 저장소에 들어 있는 데모 덱 자신의 인용도 푸시와 풀 리퀘스트마다 검사합니다.
SlideOps의 라이선스
SlideOps는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다. 저작자 표시가 유일한 조건이며, 생성한 덱은 어느 쪽이든 사용자 자신의 콘텐츠입니다.
SlideOps로 SlideOps를 소개한 17장 데모 덱 (PDF)
https://github.com/glukicov/slideops/releases/latest/download/skill-demo.pdf
SlideOps를 만든 배경을 정리한 저자 Gleb Lukicov의 글
SlideOps 문서 (설치, 신선도 검사, 개발)
SlideOps 프로젝트 GitHub 저장소
더 읽어보기
-
slides-grab: HTML 슬라이드를 Claude Code와 Codex로 만들고 드래그로 편집하는 도구
-
Presenton: Gamma, Decktopus 등을 대체하는 것을 목표로 하는 오픈소스 AI 프레젠테이션 생성기
-
Anthropic, Claude에 업무 방식과 조직 환경에 맞게 직접 커스터마이징할 수 있는 Claude Agent용 Skills 기능 출시
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 도구를 직접 설치해 사용해보셨다면, 
파이토치 한국 사용자 모임
회원들을 위해 경험이나 팁을 댓글로 남겨주세요! 
