단어 암기 카드를 인터랙티브 HTML로 만들면 무엇이 달라질까

LLM이 만든 단어 데이터가 카드 UI, 그림, 애니메이션, 검토 가능한 학습 산출물로 바뀌는 과정을 standalone HTML 데모로 살펴봅니다.

단어 암기 카드는 보통 단순하다.

앞면에는 단어가 있고, 뒷면에는 뜻이 있다. 조금 더 친절한 카드라면 예문과 그림이 붙는다.

그런데 AI 에이전트 시대에는 이 형식이 조금 달라질 수 있다. 카드는 더 이상 사람이 손으로 하나씩 만드는 정적 자료가 아니다. LLM이 단어, 뜻, 예문, 기억 훅, 그림 설명을 만들고, 렌더러가 그것을 검토 가능한 인터페이스로 바꾼다.

아래 데모는 그 작은 예시다.

Vocabulary Mnemonics 데모 직접 열기

카드는 결과물이 아니라 인터페이스다

이 HTML 데모 안에는 열 개의 단어 카드가 들어 있다.

resilient, gloomy, fragile, generous, persuade, reluctant, meticulous, vivid, awkward, inevitable.

각 카드는 단어, 뜻, 예문, 기억 훅, SVG 그림, 애니메이션 스타일을 가진다. 예를 들어 resilient는 튕겨 오르는 움직임을 쓰고, fragile은 깨지는 느낌의 움직임을 쓴다. gloomy는 가라앉고, march 스타일을 가진 inevitable은 피할 수 없이 앞으로 간다.

여기서 중요한 것은 단어 데이터 자체가 아니다. 중요한 것은 데이터가 학습 가능한 인터페이스로 바뀌었다는 점이다.

LLM이 다음과 같은 구조를 만든다고 생각해보자.

1
2
3
4
5
6
7
{
word: "resilient",
definition: "able to recover",
example: "She bounced back - resilient.",
hook: "a silly ant bounces back",
style: "bounce"
}

이 데이터만 있으면 아직 학습 경험은 아니다. 하지만 여기에 카드 레이아웃, SVG 그림, 글자 단위 스트리밍, 의미에 맞춘 움직임이 붙으면 사용자는 단어를 단순히 읽는 것이 아니라 장면으로 기억한다.

이 관점은 Tool Calling은 함수 호출이 아니라 인터페이스 설계다와 닮아 있다. 도구 호출에서 중요한 것이 함수 이름이 아니라 모델에게 제공하는 행동 표면인 것처럼, 학습 카드에서 중요한 것도 데이터 필드가 아니라 학습자가 만나는 인터페이스다.

LLM Wiki와 다른 방향의 같은 문제

LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다에서는 지식을 어떻게 구조화해야 에이전트가 믿고 사용할 수 있는지 다뤘다. 그 글의 관심사는 문서, 메타데이터, 출처, 신뢰도, 검색 구조였다.

이 데모는 반대쪽에서 같은 문제를 본다.

지식이 이미 있다고 가정했을 때, 그것을 사람에게 어떤 형태로 돌려줄 것인가? 검색 결과를 텍스트 목록으로만 보여줄 것인가? 아니면 학습자가 바로 읽고, 눌러보고, 기억하고, 검토할 수 있는 작은 앱으로 바꿀 것인가?

LLM Wiki가 에이전트를 위한 지식 저장소라면, 이런 인터랙티브 카드는 사람을 위한 지식 렌더러다.

우리의 책 색인, TXT 추출, 청크, SQLite FTS, 인용 후보 추출도 같은 흐름으로 확장할 수 있다. 처음에는 검색 가능한 자료 묶음으로 시작하지만, 그다음 단계는 검색 결과를 사람이 쓸 수 있는 산출물로 바꾸는 것이다.

예를 들면 이런 파이프라인이 가능하다.

1
책 TXT → 청크 → FTS 검색 → 후보 문장 → LLM 요약/카드화 → HTML 학습 인터페이스

여기서 HTML은 부수적인 장식이 아니다. 검색된 지식이 사용자의 기억과 판단으로 넘어가는 마지막 접점이다.

블로그에 붙였을 때 생기는 일

이 데모는 일반 포스트 안에 직접 넣지 않았다. 대신 /files/vocabulary-mnemonics/ 아래에 정적 HTML로 배치했다.

이유는 간단하다. 파일 자체가 완전한 HTML 문서이기 때문이다. <html>, <head>, <body>, bootloader, embedded font, embedded JavaScript가 모두 들어 있다. 이런 파일을 Markdown 포스트 본문에 그대로 넣으면 블로그 테마의 HTML과 충돌할 수 있다.

그래서 구조를 나눴다.

1
2
source/_posts/vocabulary-mnemonics-streaming-cards.md
source/files/vocabulary-mnemonics/index.html

포스트는 설명과 맥락을 담당한다. 정적 HTML은 실제 데모 실행을 담당한다. 블로그 글은 지식 그래프에 들어가고, 데모는 독립 실행 가능한 산출물로 남는다.

이 방식은 바이브코딩 시대의 PKM - 내 노트를 LLM Wiki 하네스로 바꾸는 법과도 연결된다. PKM이 단순 메모장이 아니라 에이전트가 사용할 수 있는 하네스가 되려면, 노트는 저장만 되어서는 부족하다. 노트는 검색되고, 변환되고, 검토되고, 실행 가능한 형태로 렌더링되어야 한다.

에이전트가 만들고 사람이 검토하는 학습물

앞으로 이 패턴은 단어 카드에만 머물 필요가 없다.

책에서 개념을 뽑아 개념 카드로 만들 수 있다. 코드베이스에서 모듈 책임을 뽑아 아키텍처 카드로 만들 수 있다. 회의록에서 결정 사항을 뽑아 의사결정 카드로 만들 수 있다. 이슈 트래커에서 반복되는 버그를 뽑아 디버깅 카드로 만들 수도 있다.

핵심은 LLM이 최종 진실을 말하게 하는 것이 아니다. LLM이 구조화된 초안을 만들고, 사람이 그것을 인터페이스 위에서 검토하게 만드는 것이다.

이 데모의 단어 카드도 그렇게 볼 수 있다. AI가 만든 학습 데이터가 있다. 그 데이터는 사람이 바로 검토할 수 있는 카드 UI로 바뀐다. 카드는 블로그에 연결되고, 블로그 글은 다시 LLM Wiki와 PKM 글에 연결된다.

작은 단어 암기 데모지만, 구조는 꽤 크다.

지식은 저장소에만 있지 않다. 지식은 인터페이스를 만났을 때 비로소 사용된다.

Comments

댓글

GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.