데이터 수집 후
위키 구성
관심 주제의 지식을 AI와 함께 수집·정리해, 여러 페이지가 서로 링크로 연결된 위키 사이트로 만들고 배포·제출한다. 이 실습이 끝나면 항목 20~30개짜리 나만의 위키가 .pages.dev 주소로 살아서 돌아간다. 핵심 리듬은 세 박자다 — 수집 → 구조화 → 생성.
무엇을 만드나
앱이 "기능" 중심이었다면 위키는 "데이터" 중심이다. 그래서 만들기 전에 데이터를 모으고 구조화하는 단계가 추가된다 — 수집 → 구조화 → 생성.
항목 20~30개가 서로 연결된 위키 사이트
목표는 한 주제를 다루는 항목 20~30개짜리 위키다. 색인(첫 화면) + 항목 페이지들 + 항목 간 상호 링크 + 간단한 검색, 이 네 가지가 갖춰지면 완성이다.
프로젝트 1과의 차이가 이 실습의 핵심이다. 앱은 "기능"이 중심이었다면 위키는 "데이터"가 중심이다. 화면을 만들기 전에 데이터를 모으고 구조화하는 단계가 추가된다. 그래서 이 프로젝트는 세 박자로 진행된다.
주제는 무엇으로 하나
| 갈래 | 예시 |
|---|---|
| 업무 도메인 용어집 | 반도체 공정 용어, 금융 파생상품 용어 |
| 취미 | 위스키, 보드게임 룰 |
| 사내 지식 | 온보딩에 필요한 사내 지식 정리 |
예시는 갈래 안내일 뿐이다. 자기 업무·관심사에서 고르는 것이 가장 좋다 — 뒤의 검수 단계에서 자기가 아는 도메인일수록 틀린 항목이 눈에 잘 띄기 때문이기도 하다. 실습과제 갤러리에는 실제 수강생이 제출한 '퀀트 위키' 같은 사례도 올라와 있으니 감을 잡는 데 참고할 수 있다.
메인 흐름(00_flow)의 여섯 단계는 이 프로젝트에서도 그대로 반복된다: 클로드 앱 설치 → Cloudflare 연결 → AI와 기획 → 진행 그래프를 보며 구현 → 업로드 → 갤러리 제출. 이 페이지는 그중 "구현" 부분이 수집·구조화·생성 세 박자로 확장된 버전이라고 생각하면 된다. 시작할 때 progress.html(진행 상황 보드)부터 만들게 하는 원칙도 동일하다 — 수집·구조화·생성·배포가 각각 노드가 되면 딱 좋은 크기다.
데이터 수집 — AI 리서치
AI에게 항목을 뽑게 하되, 만들어진 데이터는 반드시 사람이 훑어본다. AI가 만든 데이터는 검수가 필수다 — 이것이 이 단계의 결론이다.
핵심 항목 30개를 구조화된 데이터로
첫 단계는 페이지가 아니라 데이터다. AI에게 주제의 핵심 항목을 뽑아 json 파일로 저장하게 한다. 처음부터 "이름·정의·설명·관련 항목"이라는 구조를 지정하는 것이 요령이다 — 이 구조가 다음 단계의 페이지 생성을 자동화해 준다.
'[주제]' 위키를 만들려고 해. 먼저 데이터를 수집하자. - 이 주제에서 꼭 다뤄야 할 핵심 항목 30개를 뽑아줘 - 각 항목마다: 이름, 한 줄 정의, 상세 설명(3~5문장), 관련 항목 이름 2~4개 - 결과를 data/wiki_data.json 파일로 저장해줘 - 항목 간 '관련 항목'은 실제로 목록에 있는 항목만 가리키게 해줘
[주제] 자리에 자기 주제를 넣는다. 마지막 줄이 중요하다 — 관련 항목이 목록에 없는 이름을 가리키면 나중에 깨진 링크가 된다. 처음부터 데이터 수준에서 막아 둔다.
검수 원칙 — AI 데이터는 반드시 훑어본다
- AI가 만든 데이터는 반드시 훑어본다. 자기가 아는 도메인일수록 틀린 항목이 눈에 띈다.
- 틀린 것은 말로 고친다: "[항목] 설명이 틀렸어. ~로 고쳐줘".
- 사실 확인이 필요한 주제(수치·연도)는 출처를 함께 수집하게 한다.
AI는 데이터를 빠르게 만들어 주지만, 그 데이터의 품질을 보증하지는 않는다. AI가 만든 데이터는 검수가 필수다. 검수를 거치지 않은 위키는 그럴듯해 보이는 오답 모음이 될 수 있다.
실제 웹 데이터가 필요하면 크롤링을 시킬 수도 있다(09_briefing의 RSS 수집 참고). 단, 이번 프로젝트는 AI 지식 기반 수집으로도 충분하다 — 수집의 스케일을 키우는 것보다 수집→구조화→생성의 리듬을 몸에 익히는 것이 목표이기 때문이다.
생각해보기
내 주제에서 AI가 틀리기 쉬운 항목은 어떤 종류일까? 최신 정보인가, 세부 수치인가, 아니면 우리 조직에서만 통용되는 용례인가? 그 부분부터 우선 검수하면 효율이 높다.
위키 구조 설계와 생성
데이터(json)와 표현(html)을 분리한다. 그러면 항목 수정·추가가 "데이터만 고치고 재생성"으로 끝난다.
json 하나에서 위키 사이트 전체를 생성한다
검수를 마친 wiki_data.json이 준비되면, 거기서 사이트 전체를 생성하게 한다. 색인·항목 페이지·상호 링크·검색까지 한 번의 요청에 담는다.
data/wiki_data.json으로 정적 위키 사이트를 만들어줘. - index.html: 전체 항목을 가나다순 색인 + 카테고리별 그룹으로 보여주는 첫 화면, 상단에 검색창 - 항목마다 별도 HTML 페이지 (pages/항목명.html): 정의, 상세 설명, 관련 항목 링크 - 관련 항목 링크를 클릭하면 해당 항목 페이지로 이동 - 검색창에 입력하면 항목 이름과 정의에서 즉시 필터링 (JS, 외부 라이브러리 없이) - 모든 페이지 상단에 위키 이름과 '색인으로' 링크 - 전체 페이지를 build 스크립트 하나로 다시 생성할 수 있게 해줘 (데이터 수정 → 재생성) progress.html도 함께 갱신해줘.
구조 포인트 — 왜 build 스크립트인가
데이터(json)와 표현(html 생성)을 분리하면 항목 수정·추가가 쉬워진다. 항목 하나를 고치려고 페이지 30개를 손대는 것이 아니라, 데이터만 고치고 재생성하면 끝이다. 검수에서 틀린 항목이 나와도 같은 방식으로 고친다 — json 수정 → build 한 번.
다듬기 — 배포 전 확인
- 대표 항목 3개를 열어 관련 링크가 실제로 이어지는지 확인한다
- 검색창에 입력해 필터링이 동작하는지 확인한다
- 모바일 화면에서 깨지지 않는지 확인한다
여기서도 마음에 안 드는 부분은 코드를 직접 고치지 말고 말로 지시한다. "색인에서 카테고리 제목이 잘 안 보여. 더 굵고 크게 해줘"처럼. 그리고 단계가 끝날 때마다 progress.html 갱신을 함께 요청하는 습관을 유지한다 — 개발 과정 자체가 제출물의 일부가 된다.
배포와 제출
페이지 수가 많아도 배포는 똑같다 — 폴더째 올리면 끝. 배포 주소가 있어야 제출이 된다.
Pages 배포, 그리고 갤러리 제출
위키는 정적 파일 묶음이므로 프로젝트 1과 배포 방법이 완전히 같다. 페이지가 30개여도 폴더째 배포하면 끝이다.
- Pages 배포. 커넥터를 연결했다면 대화로 "완성된 폴더를 Cloudflare Pages 프로젝트 [이름]으로 배포해줘"라고 지시한다. 커스텀 토큰이라면 wrangler 명령으로 배포한다. 상세 절차는 부록 11_deploy 참고.
npx wrangler pages deploy ./폴더 --project-name 프로젝트이름 --branch main
- 갤러리 제출. 실습과제 갤러리 접속 → [과제 제출] → 분반·회차 선택 → 제목·작성자 입력 → 결과물 링크에 배포된 .pages.dev 주소 → 설명 → 비밀번호(수정·삭제용) → 제출. 설명에는 항목 수와 어떻게 수집·검수했는지를 함께 적으면 좋다 — 이 프로젝트의 핵심이 바로 그 과정이기 때문이다.
- 배포 주소가 열리고 색인 → 항목 → 관련 항목 이동이 된다
- 스마트폰에서도 열린다
- 갤러리에 내 카드가 보인다
제출 후에는 동료들의 결과물을 구경하고 좋아요·의견을 남겨 보자. 같은 "위키"라도 주제와 구조가 제각각이라, 다른 사람의 색인 구성을 보는 것만으로 배우는 게 많다.
핵심 정리
데이터 중심 사고: 수집 → 구조화 → 생성. 그리고 AI가 만든 데이터는 검수가 필수다.
핵심 정리와 다음 프로젝트
하나. 위키는 데이터 중심 사고의 실습이다. 수집 → 구조화 → 생성의 3박자를 지키면, 내용 수정은 언제나 "데이터만 고치고 재생성"으로 끝난다.
둘. AI가 만든 데이터는 검수가 필수다. AI는 빠르게 채워 주지만 맞음을 보증하지 않는다. 자기가 아는 도메인을 골라, 틀린 것은 말로 고치고, 수치·연도는 출처를 함께 수집하게 한다.
셋. 데이터(json)와 표현(html)의 분리가 구조의 전부다. build 스크립트 하나가 30페이지를 다시 만들어 준다.
실습 체크리스트
- wiki_data.json에 항목 20~30개 수집 완료
- 데이터를 직접 훑어보고 틀린 항목을 고쳤다 (검수)
- 색인·항목 페이지·상호 링크·검색이 모두 동작한다
- Pages 배포 → 갤러리 제출 완료
더 나아가기
- 지금의 검색은 글자 일치 필터링이다. 검색을 의미 기반으로 바꾸고 싶다면 07_secrag의 임베딩·벡터 검색을 참고하라.
- 실제 웹에서 데이터를 자동 수집하고 싶다면 09_briefing의 RSS 수집이 출발점이다.
다음 프로젝트 예고 — 위키는 정적이다. 만들어 둔 페이지를 보여줄 뿐, 사용자의 말에 반응하지는 않는다. 다음은 LLM이 실시간으로 화면을 움직이는 대시보드다.
참고 실습과제 갤러리(제출·사례 확인): cf-board.juhonov.workers.dev
이 자료는 단일 HTML 파일로 배포된다. 프롬프트 블록의 [대괄호] 부분은 자기 주제·상황에 맞게 바꿔 쓴다.