1인 개발자가 문서 천 건을 탐색 도구로 만든 방법

한 명이 혼자 만들었다는 게 핵심이다

재판 기록에서 꺼낸 이메일, 문자, 슬라이드, 법정 증거 문서 — 천 건 이상. Extend의 엔지니어 Bo Lau는 이걸 전부 불러다가 "Elizabeth Holmes의 책상 앞에 앉아 서랍을 뒤지는" 인터페이스로 만들었다. 이메일은 Gmail처럼, 문자는 iOS 말풍선처럼, 슬라이드는 프레젠테이션 뷰어처럼. TechCrunch 기사 제목이 "weirdly detailed(기묘하게 정밀한)"라는 형용사를 쓴 이유다.

처음 봤을 때 반응은 "와, 재밌다"였다. 그 다음 반응은 달랐다. 이걸 혼자서 어떻게 만들었나.

여기서 흥미로운 부분이 시작된다. 2~3년 전이었으면 이 프로젝트는 최소 서너 명이 붙어야 했다. 지금은 한 명의 사이드 프로젝트로 가능한 규모다. AI 도구와 문서 파싱 생태계가 그만큼 올라왔다는 뜻이다.

단, 이걸 "그냥 우리도 따라 하면 되겠네"라고 읽으면 함정이 있다. 법정 문서는 영원히 바뀌지 않지만 팀의 내부 문서는 매일 바뀐다. 그 차이에서 교훈과 주의점이 동시에 나온다.

기술 구조를 뜯어보면 보이는 것

공개된 정보만으로 추정해보면, 이 사이트는 대략 세 층으로 이루어져 있을 가능성이 높다.

문서 파싱·분류 레이어, 메타데이터 기반 UI 렌더링 레이어, 검색·탐색 레이어.

가장 어려운 건 첫 번째다. 이메일, SMS, PDF, PowerPoint — 포맷이 전부 다르다. 각각을 파싱해서 "이건 이메일, 발신자는 누구, 날짜는 언제"라는 구조화된 데이터로 뽑아야 한다. 지금은 이 작업을 LLM에 상당 부분 위임할 수 있다. 문서 한 페이지를 입력하고 "포맷, 발신자, 수신자, 날짜를 JSON으로 꺼내줘"라고 하면 처리된다.

두 번째 레이어, 메타데이터에 따라 다른 UI를 그리는 부분은 공학적으로는 단순하다. 문서 타입 enum 하나에 컴포넌트 몇 개. 그런데 노력 대비 임팩트가 가장 큰 부분이기도 하다. 같은 텍스트를 <pre> 태그로 뿌리는 것과 iOS 말풍선으로 보여주는 것의 체감 차이는 상당하다.

세 번째는 벡터 검색이거나 전문검색(full-text search)일 텐데, RAG 구조가 들어왔을 가능성이 높다. 천 건의 문서를 임베딩해두고 "Holmes가 투자자에게 보낸 이메일"을 질의하는 방식으로.

소규모 팀이 이걸 보고 물어야 할 질문

"우리 팀 내부 문서도 이렇게 쌓여있지 않나."

우리 팀만 해도 ops 레포에 CLAUDE.md 체계, 인시던트 리포트, 배포 절차 문서, 봇별 README까지 텍스트만 수백 건이다. 새 사람이 "이 봇이 왜 이렇게 작동하는지"를 파악하려면 여러 파일을 직접 읽어가야 한다. 컨텍스트가 파일 사이에 흩어져 있다.

Bo Lau가 증명한 건 이 문서 더미를 "탐색 가능한 경험"으로 바꾸는 게 혼자서도 할 수 있는 규모라는 거다. 물론 Theranos 재판 기록처럼 고정된 문서라서 가능한 면도 있다. 살아있는 코드베이스와 운영 문서는 계속 바뀐다. 이 차이가 직접 만들지, 기성 도구를 살지를 가르는 분기점이 된다.

수치로 보는 트레이드오프

Notion AI, Confluence AI 같은 기성 팀 지식 도구는 팀당 월 $15~30 수준이다. 근데 이 도구들은 문서를 "그냥 검색"한다. "이메일은 이메일처럼, 슬라이드는 슬라이드처럼" 보여주는 컨텍스트 레이어가 없다. 기성품의 UX가 밋밋한 이유는 문서 타입을 구분하지 않기 때문이다.

직접 만드는 쪽을 선택한다면? 우리 팀 규모 기준으로 솔직하게 추산해보면 — 문서 파싱 파이프라인 이틀, UI 컴포넌트 하루, 검색 연동 하루, 정제 배포 하루. 총 5~7일 정도. 유지보수는 새 문서가 들어올 때 자동 인덱싱을 걸어두면 이후 추가 공수는 거의 없다.

핵심 트레이드오프는 이거다. 팀원 5명 미만이면 이 5~7일을 투자할 만한 경우가 많다. 지식이 구전으로 전달되는 비용이 그보다 크기 때문이다. 반대로 팀이 작아도 내부 문서 자체가 적다면 도구가 문제가 아니라 문서화 습관이 문제인 경우가 대부분이다.

직접 내부 도구를 만들어보니 가장 어려운 부분이 "문서 파싱"이 아니라 "팀원이 실제로 쓰게 만드는 것"이었다. 아무리 잘 만들어도 기존 흐름에 자연스럽게 끼어들지 못하면 두 달 후 아무도 안 쓰는 내부 위키가 된다.

우리 팀이라면 이 프로젝트를 어떻게 쓸까

가장 현실적인 시나리오 하나: 배포 인시던트 사후 분석 탐색.

인시던트가 나면 Discord 스레드, 수기 메모, 커밋 히스토리가 흩어진다. 나중에 "6월에 비슷한 문제 있지 않았어?"를 확인하려면 사람이 직접 뒤져야 한다. Bo Lau 방식대로라면 — Discord 스레드는 "사건 카드", 커밋 메시지는 "코드 변경 이력", 수기 메모는 "관찰 노트"로 분류해서 타임라인으로 엮으면 된다.

기술적으로 어렵지 않다. Discord API로 스레드 export, GitHub API로 커밋 로그, 텍스트 파일은 직접 읽기. 여기에 LLM으로 각 항목을 분류하고 태그를 붙이는 단계를 추가하면, Bo Lau가 만든 것의 80% 수준 내부 버전이 나온다.

요즘 ai 개발자 국비지원 과정에서 자주 다루는 RAG 파이프라인이 정확히 이 구조다. 수업에서 배우는 "문서 청크 분할 → 임베딩 → 질의응답" 흐름을 내부 인시던트 아카이브에 그대로 적용하면 실무 도구가 된다. 강의에서 배운 구조를 실제 팀 워크플로에 박아넣는 게 가장 빠른 내재화이기도 하다.

지금 바로 할 수 있는 것

거창한 내부 도구를 만들기 전에, 문서 지옥이 얼마나 심한지부터 측정해라. 기준은 단순하다. 새 팀원이 온보딩 첫 주에 "이게 왜 이렇게 되어 있어요?"라고 하루 3번 이상 묻는다면 — 문서 탐색 문제가 실재하는 거고 도구 투자를 검토할 근거가 된다. 그 미만이면 지금은 Notion 정리에 집중하는 게 낫다.

Bo Lau의 작업에서 가장 저비용으로 가져올 수 있는 아이디어는 포맷 재현이다. 내부 검색 결과를 보여줄 때 모든 걸 똑같은 텍스트 블록으로 뿌리지 않고, 문서 타입에 따라 다른 컴포넌트를 쓰는 것만으로도 "이게 이메일인지 커밋인지 인시던트 노트인지"가 즉각 구분된다. 인지 부하가 눈에 띄게 줄어든다.

이 프로젝트를 사이드 프로젝트로 시작한다면, 가장 자주 "어디 있더라?"가 나오는 문서 유형 하나만 먼저 잡아라. 전체 아카이브를 한 번에 색인하려다가 파싱 예외 케이스에 막히면 첫 주에 포기하게 된다. 이메일만, 또는 인시던트 노트만. 범위를 좁히면 일주일 안에 실제로 팀이 쓰는 프로토타입이 나온다.

원문: AI News & Artificial Intelligence | TechCrunch