📣 23기 AI 스터디 대기자 모집 중!

에이전트 / 노코드 자동화
둘둘
둘둘
·에이전트 / 노코드 자동화에 게시됨

기획자를 위한 AI Wiki를 만들고, LLM Wiki 흐름을 다시 보게 됐다

소개  

AI 관련 개념은 계속 쏟아지는데, 기획자 입장에서 보기 좋은 흐름은 잘 보이지 않았습니다.
RAG, 에이전트, 메모리, 평가, 운영, 거버넌스 같은 단어를 각각 따로 공부할 수는 있었습니다.
하지만 제가 더 궁금했던 건 단어의 뜻 하나하나보다 이런 질문이었습니다.

“그래서 이 개념은 AI 시스템을 만들고 운영하는 과정에서 어디에 놓이는 걸까?”

기획자에게는 개념을 많이 아는 것도 중요하지만, 그 개념들이 어떤 흐름으로 연결되는지 이해하는 게 더 중요하다고 생각했습니다. 그래서 제가 공부한 문서와 메모들을 모아, 기획자 관점에서 다시 정리한 AI 위키를 만들어보기로 했습니다.

그렇게 만든 것이 **AI Wiki for Planner**입니다.
- 결과물: https://ai-wiki-for-planner.vercel.app
- 한 줄 소개: 기획자를 위한 AI 개념 위키 + AI 직무 역량 자가진단

이 위키는 AI 시스템의 흐름을 8단계로 나누고, 그 안에 AI 개념들을 배치한 한국어 AI 위키입니다.
여기에 자가진단을 붙여서, 사용자가 자신의 AI 직무 역량을 레이더차트로 확인할 수 있게 만들었습니다.
처음에는 단순히 제 공부를 정리하려는 목적이 컸습니다.

그런데 만들고 나서 보니, 요즘 이야기되는 LLM Wiki 흐름과도 연결해서 생각해볼 수 있겠다는 생각이 들었습니다. 완전히 같은 것은 아니지만, 둘 다 흩어진 지식을 그냥 쌓아두는 것이 아니라 다시 찾고, 연결하고, 이해하고, 활용할 수 있는 구조로 바꾸려는 시도라는 점에서 닮아 있다고 느꼈습니다.

진행 방법

1. AI 개념을 8단계 흐름으로 나누기
가장 먼저 한 일은 제가 공부했던 AI 개념들을 모으는 것이었습니다.
다만 개념을 가나다순으로 정리하거나, 단순 목록으로 쌓고 싶지는 않았습니다.
기획자 입장에서 중요한 건 “이 개념이 전체 흐름에서 어디에 있는가”였기 때문입니다.

그래서 AI 시스템의 일생을 기준으로 8단계 구조를 만들었습니다.

0. 기초 이해

1. 전략·설계

2. 데이터·지식

3. 구축·연결

4. 컨텍스트·기억

5. 평가·검증

6. 운영·관측

7. 거버넌스·안전

이 구조를 통해 AI 개념을 단어 단위로 외우는 것이 아니라,
AI 시스템이 기획되고, 만들어지고, 운영되고, 책임져지는 흐름 안에서 이해할 수 있게 하고 싶었습니다.

특히 3번과 4번 단계는 분리해서 보았습니다.

  • 3번 구축·연결: 시스템을 만들고 도구와 데이터를 연결하는 영역

  • 4번 컨텍스트·기억: AI에게 맥락을 주고, 기억과 역할을 설계하는 영역

둘은 연결되어 있지만, 실무에서는 다른 사고방식이 필요하다고 느꼈습니다.
그래서 두 단계를 하나로 뭉치기보다, 서로 루프를 도는 관계로 정리했습니다.

이 부분이 이 위키의 가장 중요한 포지셔닝이었습니다.
기획자가 AI를 단순히 “사용하는 사람”으로만 보는 것이 아니라, AI 시스템이 만들어지고 운영되는 흐름 전체를 볼 수 있게 하고 싶었습니다.

2. 위키 본문은 마크다운으로 관리하기

콘텐츠는 마크다운으로 작성했습니다.

각 개념 페이지는 최대한 같은 흐름으로 읽히도록 템플릿을 맞췄습니다.

1. 왜 이 개념이 필요한가
2. 개념의 기본 단위와 구조
3. 실무에서 복잡해지는 지점
4. 생각하는 절차
5. 자주 빠지는 함정
6. 다음으로 읽으면 좋은 글
7. 키워드 색인

이렇게 템플릿을 맞춘 이유는, 40개가 넘는 개념을 다루더라도 읽는 사람이 매번 새로운 구조에 적응하지 않게 하기 위해서였습니다.

콘텐츠는 총 40개가 넘는 마크다운 파일로 관리했고, 사이트에서는 이 마크다운을 불러와 화면에 렌더링하도록 만들었습니다.

기술적으로는 복잡한 CMS를 붙이기보다, 우선 정적 사이트 구조를 선택했습니다.
콘텐츠를 수정할 때 마크다운만 바꾸면 되도록 하고 싶었기 때문입니다.

3. 읽는 위키에서 끝나지 않게 자가진단 붙이기

위키만 있으면 “읽는 자료”로 끝날 수 있다고 생각했습니다.

그래서 사용자가 자기 위치를 확인할 수 있도록 자가진단을 붙였습니다.

AI 개념에 맞춰 문항을 만들고, 결과는 레이더차트로 보여주었습니다.

단순히 총점만 보여주기보다는,

  • 내가 어느 단계에 강한지

  • 어느 단계가 비어 있는지

  • 다음에 무엇을 공부하면 좋을지

를 한눈에 볼 수 있게 만들고 싶었습니다.

자가진단 결과는 강점과 학습 영역을 함께 보여주고, 약한 단계의 학습 페이지로 이어지도록 구성했습니다.

기술적으로는 Chart.js를 사용해 레이더차트를 그렸고, 결과 이미지를 저장할 수 있도록 html2canvas도 붙였습니다.

자가진단 문항 응답
→ 단계별 점수 계산
→ 레이더차트 시각화
→ 강점 / 학습 영역 표시
→ 추천 학습 페이지 연결
→ 결과 이미지 캡처

이 기능을 넣으면서 위키가 단순한 읽기 자료가 아니라,
사용자가 자신의 현재 위치를 확인하고 다음 학습으로 넘어가는 도구에 가까워졌습니다.

4. 정적 SPA로 빠르게 구현하기

전체 사이트는 백엔드 없이 정적 SPA 형태로 만들었습니다.

사용한 구성은 대략 이렇습니다.

콘텐츠: Markdown
프론트엔드: HTML + 순수 JavaScript
마크다운 렌더링: marked.js
차트: Chart.js
캡처: html2canvas
호스팅: Vercel
분석: Google Analytics 4
백엔드: 없음

처음부터 서버와 데이터베이스까지 붙인 큰 서비스를 만들기보다는,
콘텐츠를 빠르게 수정하고 배포할 수 있는 구조를 우선했습니다.

그래서 마크다운 파일을 런타임에 불러오고, marked.js로 HTML로 변환해 보여주는 방식을 선택했습니다.

사용자가 위키 페이지 클릭
→ 해당 Markdown 파일 로드
→ marked.js로 HTML 변환
→ 본문 영역에 렌더링

이 방식의 장점은 빠르게 만들 수 있다는 점이었습니다.
콘텐츠를 고치고 싶으면 마크다운만 수정하면 되었습니다.

다만 단점도 있었습니다.

SPA 구조라서 처음에는 페이지별 SEO나 공유 미리보기가 약했습니다.
어떤 페이지를 공유해도 같은 미리보기가 뜨는 문제가 있었고, 검색엔진이 각 페이지를 독립된 콘텐츠로 이해하기 어렵다는 한계도 있었습니다.

이 부분은 이후에 별도 OG 페이지를 생성하는 방식으로 보완했습니다.

5. 검색과 공유 기능 추가하기

위키는 내용이 많아질수록 “다시 찾기”가 중요해집니다.

그래서 본문 전체 검색 기능을 추가했습니다.

검색은 처음 사용할 때 마크다운 파일들을 불러와 간단히 인덱싱하고,
제목과 본문에서 검색어가 포함된 페이지를 찾아주는 방식으로 만들었습니다.

검색창 열기
→ 마크다운 파일 일괄 로드
→ 텍스트로 변환
→ 제목 / 본문 검색
→ 매칭된 부분 하이라이트
→ 해당 페이지로 이동

헤더에는 검색 버튼을 두고, ⌘K 또는 Ctrl+K 단축키로도 열 수 있게 했습니다.

공유 기능도 붙였습니다.
특히 자가진단 결과는 URL에 점수를 담아 공유할 수 있게 만들었습니다.

자가진단 완료
→ 점수 배열 생성
→ URL에 점수 인코딩
→ 공유 링크 생성
→ 받은 사람은 결과 페이지 확인
→ “나도 진단해보기” CTA 클릭

백엔드에 저장하지 않고도 공유가 가능하도록 URL 자체에 데이터를 담은 방식입니다.
작게 만들었지만, 공유 루프를 만들 수 있다는 점에서 재미있는 기능이었습니다.

6. SPA에서 OG 미리보기 문제 해결하기

만들면서 가장 기억에 남는 기술적 이슈 중 하나는 OG 미리보기였습니다.

처음에는 SPA라서 어떤 페이지를 공유해도 카카오톡이나 SNS에서 같은 제목과 이미지가 보였습니다.
크롤러는 사용자가 보는 것처럼 JavaScript 라우팅을 따라가서 페이지를 읽어주지 않기 때문입니다.

그래서 페이지별로 OG 메타가 들어간 정적 HTML을 따로 생성했습니다.

사용자가 특정 위키 페이지 공유
→ /og/1-1 같은 OG 전용 URL 복사
→ 카카오톡 크롤러는 정적 HTML의 메타 태그 확인
→ 사용자가 클릭하면 실제 위키 페이지로 리다이렉트

이 방식으로 각 페이지마다 다른 제목과 설명, 미리보기를 보여줄 수 있었습니다.

기술적으로 아주 거창한 해결책은 아니지만,
정적 SPA의 한계를 현실적으로 우회한 방법이었습니다.

7. LLM Wiki 흐름과 연결해서 다시 보기

릴리즈하고 나서 LLM Wiki라는 흐름을 보게 됐습니다.

처음 든 생각은 이랬습니다.

“이게 내가 만든 것과 완전히 같은 건 아니지만, 연결해서 생각해볼 수는 있겠다.”

제가 만든 AI Wiki는 사람이 직접 문서를 모으고, 읽고, 분류하고, 기획자 관점의 흐름에 맞게 수동으로 정리한 위키입니다.

반면 LLM Wiki는 LLM을 활용해 문서나 지식을 더 잘 읽고 활용할 수 있도록 구조화하는 방향에 가까워 보였습니다.

그래서 이렇게 정리해볼 수 있었습니다.

내가 만든 AI Wiki
= 사람이 이해하기 좋게 수동으로 정리한 지식 구조

LLM Wiki
= LLM이 읽고 활용하기 좋게 기술적으로 구조화하는 지식 구조

방식은 다르지만, 둘 다 흩어진 지식을 다시 찾고, 연결하고, 활용할 수 있는 형태로 바꾼다는 점에서는 연결해서 생각해볼 수 있었습니다.

이 지점을 보면서 제가 만든 AI Wiki도 앞으로는 단순히 사람이 읽는 위키를 넘어서,
AI가 읽고 활용하기 좋은 지식 구조로 발전시킬 수 있겠다는 생각을 하게 됐습니다.

결과와 배운 점

1. 가장 어려웠던 건 개발보다 구조 잡기였다

이 프로젝트에서 가장 힘들었던 건 개발 자체보다 구조를 잡는 일이었습니다.

AI 개념은 많고, 서로 연결되어 있고, 보는 사람의 배경지식도 다릅니다.
그래서 단순히 많이 넣는다고 좋은 위키가 되는 것은 아니었습니다.

오히려 중요한 건 이런 질문이었습니다.

“이 많은 개념을 어떤 순서로 보여줘야 이해하기 쉬울까?”

결국 이 프로젝트에서 가장 중요한 일은 개념을 모으는 것이 아니라,
개념 사이에 흐름을 만드는 일이었습니다.

2. 지식 정리에도 IA와 UX가 필요했다

만들면서 느낀 건, AI 개념 정리도 결국 하나의 제품처럼 봐야 한다는 점이었습니다.

사용자가 처음 들어왔을 때 어디서 시작해야 하는지,
어떤 순서로 읽으면 좋은지,
자기 상태를 어떻게 확인할 수 있는지까지 고려해야 했습니다.

그래서 위키 구조뿐 아니라 자가진단, 레이더차트, 추천 링크, 검색, 공유 기능까지 함께 설계했습니다.

단순한 문서 모음이 아니라,
사용자가 자기 위치를 확인하고 다음 학습으로 넘어갈 수 있는 흐름을 만들고 싶었습니다.

3. 정적 사이트도 꽤 많은 것을 할 수 있었다

처음에는 백엔드 없이 어디까지 할 수 있을까 싶었습니다.

그런데 만들어보니 정적 사이트만으로도 꽤 많은 것을 구현할 수 있었습니다.

  • 마크다운 기반 위키

  • 자가진단

  • 레이더차트

  • 결과 이미지 캡처

  • 본문 검색

  • 공유 링크

  • 페이지별 OG 미리보기

  • GA 기반 분석

물론 하트, 조회수, 완료자 카운트처럼 전역 데이터가 필요한 기능은 백엔드가 필요합니다.
하지만 초기 버전에서는 localStorage와 정적 구조만으로도 충분히 작동하는 경험을 만들 수 있었습니다.

이 경험을 통해 “처음부터 큰 시스템을 만들 필요는 없다”는 것도 배웠습니다.
작게 만들고, 실제로 쓰이게 한 다음, 필요한 부분부터 붙여도 충분했습니다.

4. SPA는 편하지만 SEO와 공유에서 고민이 생겼다

SPA 구조는 빠르게 만들기 좋았습니다.
페이지 전환도 부드럽고, 마크다운을 불러와 보여주는 방식도 구현하기 쉬웠습니다.

하지만 SEO와 공유에서는 한계가 있었습니다.

특히 SNS 공유 미리보기는 사용자가 보는 화면이 아니라,
크롤러가 처음 받아가는 HTML을 기준으로 만들어집니다.

그래서 SPA 내부에서 페이지가 바뀌어도, 크롤러 입장에서는 모든 페이지가 같은 문서처럼 보일 수 있었습니다.

이 문제를 해결하기 위해 페이지별 OG HTML을 따로 만들면서,
“보이는 화면”과 “기계가 읽는 문서”는 다르게 설계해야 할 때가 있다는 걸 배웠습니다.

이 지점은 LLM Wiki 흐름과도 연결해서 생각해볼 수 있었습니다.
사람이 읽기 좋은 구조와 기계가 읽기 좋은 구조는 겹치는 부분도 있지만, 완전히 같지는 않았습니다.

5. 위키는 한 번 만들고 끝나는 문서가 아니었다

릴리즈 이후에도 계속 업데이트가 필요했습니다.

검색 기능, Top 버튼, 페이지 제목 동적 반영, 자가진단 결과 공유, 페이지별 OG 미리보기 등을 차례로 추가했습니다.

또 새로운 AI 개념이 계속 등장하기 때문에,
위키도 고정된 문서가 아니라 계속 자라는 구조여야 한다고 느꼈습니다.

특히 에이전트, 페르소나, Skills, MCP, 멀티에이전트 같은 개념은 시간이 지나면서 의미나 쓰임이 계속 바뀝니다.

그래서 이 위키도 “완성된 문서”라기보다는,
계속 업데이트되는 지식 제품에 가깝게 보고 있습니다.

앞으로의 계획

1. SEO 강화하기

앞으로 가장 먼저 하고 싶은 것은 SEO 강화입니다.

좋은 내용을 만들어도 발견되지 않으면 의미가 줄어듭니다.

지금은 정적 사이트와 해시 기반 URL 구조로 시작했지만,
앞으로는 검색엔진이 각 페이지를 더 잘 인식할 수 있도록 구조를 개선하고 싶습니다.

예를 들면 이런 방향을 생각하고 있습니다.

  • 해시 기반 URL에서 path 기반 URL로 전환

  • 페이지별 메타 정보 강화

  • sitemap 구성

  • 페이지별 title / description 정리

  • 공유 미리보기 구조 개선

2. 새로운 AI 개념 계속 업데이트하기

AI 분야는 개념이 빠르게 바뀝니다.

에이전트, MCP, Skills, 멀티에이전트, 하네스 엔지니어링처럼 새로운 단어들이 계속 등장합니다.

중요한 건 유행어를 그대로 따라가는 것이 아니라,
그 개념이 전체 AI 시스템 흐름 안에서 어디에 놓이는지 정리하는 일이라고 생각합니다.

그래서 앞으로도 새로운 개념이 생기면 위키 안에 자연스럽게 편입시키고,
기획자 관점에서 이해할 수 있는 흐름으로 계속 업데이트해보고 싶습니다.

3. AI가 읽기 좋은 구조로 발전시키기

지금의 AI Wiki는 사람이 읽기 좋은 구조를 먼저 생각하고 만들었습니다.

하지만 LLM Wiki 흐름을 보면서,
앞으로는 AI가 읽고 활용하기 좋은 구조도 함께 고민해볼 수 있겠다고 생각했습니다.

예를 들면 이런 방향입니다.

  • 각 페이지의 요약 정보 구조화

  • 개념 간 관계를 더 명확하게 표시

  • LLM이 참고하기 좋은 목차와 링크 구조 만들기

  • 출처와 레퍼런스 페이지 정리

  • 향후 질의응답이나 검색 보조 기능 연결

처음에는 AI 개념을 정리하기 위해 만든 작은 위키였습니다.

그런데 만들고 나서 보니, 이 프로젝트는 단순한 공부 정리를 넘어
“AI 시대에 지식을 어떻게 구조화할 것인가”라는 질문과도 연결되어 있었습니다.

아직은 사람이 직접 만든 수동형 위키에 가깝지만,
앞으로는 사람이 읽기 좋은 위키이면서 동시에 AI도 활용하기 좋은 지식 구조로 더 발전시켜보고 싶습니다.

도움 받은 글

1
2개의 답글

뉴스레터 무료 구독

신청하기