알래스카 기반 AI 데이터센터 사업 검토라는, 꽤 큰 리서치 과제를 맡게 됐습니다. 전력·송전, 한랭 기후 냉각(free cooling), 수자원, Arctic Fiber 해저 케이블, 서비스 모델, APAC·한국 고객군까지 — 주제가 20개 카테고리를 넘고, 근거 자료는 전부 공개 자료(OSINT)에서 모아야 했습니다.

브라우저 북마크와 스프레드시트로 시작했다가 금방 한계가 왔습니다. “이 주장 근거가 어느 문서 몇 페이지였지?”를 보고서 쓸 때마다 다시 뒤지고 있었거든요. 그래서 리서치 자체를 파이프라인으로 만들었습니다. 그 결과물이 AI Infrastructure Research Portal입니다.

원칙: 모든 주장은 원문 URL까지 추적 가능해야 한다

보고서에 들어가는 문장 하나하나가 “어느 소스에서 왔는지” 즉시 확인 가능해야 한다는 걸 첫 번째 원칙으로 삼았습니다. 그래서 자료 수집을 단계별 CSV 파이프라인으로 쪼갰습니다.

url_candidates.csv   수집 후보 URL (검색 쿼리 기반 수집)
      ↓ 사람이 승인
url_registry.csv     승인된 URL 레지스트리
      ↓ 다운로드
download_manifest.csv  실제 받아진 파일 기록
      ↓ 텍스트 추출
source_index.csv     포털에 노출되는 소스 인덱스
      ↓ 가공
summaries.csv / insights.csv / knowledge_graph.csv

핵심은 후보와 확정 사이에 사람의 승인 단계를 둔 것입니다. 검색으로 긁어온 URL을 그대로 코퍼스에 넣으면 품질이 무너집니다. 후보 목록을 훑고 승인한 것만 다운로드·추출되도록 하니, 코퍼스에 있는 자료는 전부 “누군가 한 번은 눈으로 보고 통과시킨 것”이라는 보장이 생겼습니다.

데이터베이스 대신 CSV를 쓴 이유

메타데이터 저장소로 DB가 아니라 CSV 파일들을 썼습니다. 일부러 선택한 것인데, 리서치 데이터에는 CSV가 의외로 잘 맞았습니다.

• git으로 버전 관리가 됩니다. “이번 주에 어떤 소스가 추가됐나”가 곧 커밋 diff입니다.
• 파이프라인 각 단계가 파일 하나 = 책임 하나로 분리됩니다. 스크립트는 CSV를 읽고 다음 CSV를 쓰는 단순한 변환기가 됩니다.
• 문제가 생기면 스프레드시트로 열어서 바로 고칠 수 있습니다.

물론 공짜는 아닙니다. 참조 무결성을 지켜주는 DB가 없으니 데이터가 조용히 어긋납니다. 그래서 포털에 Data Health Check 페이지를 만들어 URL 누락, 제목 누락, 카테고리 누락을 상시 점검하게 했습니다. 무결성을 스키마로 강제하는 대신, 대시보드로 드러나게 한 셈입니다.

포털: Streamlit으로 하루 만에

수집·가공은 스크립트가 하지만, 열람은 팀이 해야 합니다. UI는 Streamlit으로 만들었습니다. 프론트엔드 코드 없이 파이썬만으로 데이터 앱을 만들 수 있어서, 포털의 첫 버전은 하루 만에 나왔습니다.

• Overview — 전체 소스 수, 신규/최신 업데이트 자료 현황
• Source Index — 카테고리 필터, 신규만 보기, 원문 URL 바로 열기
• Corpus Search — 추출된 전체 텍스트 코퍼스 내부 검색
• Data Health Check — 메타데이터 품질 점검

배포는 systemd + nginx 리버스 프록시로 사내 서버에 상시 구동시켰고, daily_update.sh로 갱신을 돌립니다. 처음엔 Render 같은 외부 호스팅도 검토했지만 내부 자료 특성상 사내 서버로 정리했습니다. 한 가지 삽질 공유: Streamlit 앞에 프록시를 두면서 enableCORS=false를 넣었다가 XSRF 보호와 충돌해서 뺐습니다. 최신 Streamlit은 이 설정을 알아서 처리하니 굳이 만지지 않는 게 낫습니다.

카테고리 설계가 곧 리서치 설계

만들고 보니 가장 공들인 부분은 코드가 아니라 카테고리 체계였습니다. power, cold_climate_cooling, fiber 같은 인프라 축과 korea_ai_demand, korea_dr_backup, apac_customer_target 같은 고객 축을 분리해서 21개 카테고리로 정리했는데, 이 구조가 사실상 보고서의 목차이자 논증 구조가 됐습니다. 카테고리별로 자료가 몇 건인지 보이니 “여기는 근거가 얇다”는 것도 바로 드러나고요.

리서치 도구를 만든다는 건 결국 “무엇을 알아야 하는가”를 데이터 구조로 먼저 써보는 일이라는 걸 배웠습니다.

마치며

이 포털 덕분에 최종 보고서를 쓸 때 Evidence Matrix(주장-근거 매트릭스) 방식으로 작업할 수 있었습니다. 주장마다 소스 인덱스의 ID를 달아두면, 검토자가 “이거 근거 뭐예요?”라고 물을 때 원문 URL까지 두 클릭이면 도달합니다. 테크니컬 라이터로서 가장 만족스러운 부분이 바로 이 지점이었습니다 — 문서의 신뢰도는 문장이 아니라 추적 가능성에서 나온다는 것.