Claude Code, 그리고 600GB의 인덱스: UI가 사라지는 시대의 데이터 탐험

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

개발자로서, 혹은 기술 리더로서 가장 막막할 때가 언제인가요? 저는 회사의 데이터가 기하급수적으로 쌓이는데, 그 데이터를 유의미한 정보로 가공해 줄 '도구'를 만들 시간이 없을 때 가장 답답함을 느낍니다. 보통 우리는 이럴 때 어드민 페이지를 만들거나, 복잡한 대시보드를 구축하곤 하죠. 그런데 최근 해커뉴스(Hacker News)에 올라온 흥미로운 프로젝트 하나가 제 뒤통수를 세게 때리는 듯한 영감을 주었습니다. 오늘은 그 이야기를 좀 해볼까 합니다.

"UI를 만들지 마세요. 그냥 Claude에게 SQL 권한을 주면 됩니다."

ExoPriors라는 곳에서 공개한 'Scry'라는 프로젝트 이야기입니다. 이들은 정렬(Alignment) 연구, 즉 AI 안전성이나 지능 폭발과 관련된 문서들을 인덱싱했는데, 그 양이 무려 600GB에 달합니다. 아카이브(arXiv) 논문, 해커뉴스 토론, LessWrong 포스트 등 6,000만 개의 문서가 포함되어 있죠.

보통 이런 서비스를 만든다면 우리는 무엇부터 고민할까요? 아마도 검색창이 달린 웹사이트, 필터링 기능, 그리고 결과를 예쁘게 보여줄 UI 컴포넌트를 생각할 겁니다. 하지만 이들은 전혀 다른 접근을 취했습니다. 그들은 그저 "Claude Code에게 줄 프롬프트" 하나를 던져주었습니다.

방식은 충격적일 정도로 심플합니다. 사용자는 터미널에서 Claude Code를 실행하고, 이들이 제공한 프롬프트와 API 키를 입력합니다. 그러면 Claude는 그 순간부터 600GB 데이터베이스를 자유자재로 탐색하는 '데이터 분석가'가 됩니다.

왜 이것이 혁신적인가: SQL과 벡터 연산의 결합

단순히 챗봇에게 "이거 찾아줘"라고 하는 수준이 아닙니다. 이 도구의 핵심은 LLM이 직접 데이터베이스의 스키마를 이해하고, SQL과 벡터 연산(Vector Algebra)을 조합해 질의한다는 점입니다.

예를 들어, "Mesa Optimization(메사 최적화)에 대한 논문을 찾고, 그 논문들이 인용된 해커뉴스 댓글 중 점수가 높은 것들의 여론을 분석해 줘"라고 자연어로 명령했다고 칩시다.

과거의 방식이라면 개발자가 ElasticSearch 쿼리를 짜거나, 복잡한 조인(Join) 문을 작성해야 했습니다. 하지만 이 모델에서는 Claude가 스스로 판단합니다. 1. alignment.search('mesa optimization') 함수를 호출해 텍스트 검색을 수행하고, 2. mv_hackernews_comments (Materialized View)와 조인하여 평판이 높은 댓글을 필터링하고, 3. 필요하다면 벡터 임베딩 간의 거리(<=>)를 계산해 의미론적으로 유사한 문서를 찾아냅니다.

개발자는 그저 거들 뿐, 실제 쿼리 실행 계획은 AI 에이전트가 수립하는 것입니다.

풀링포레스트에서 우리가 고민하는 지점

저희 풀링포레스트 팀에서도 최근 사내 지식 관리 시스템을 고도화하며 비슷한 고민을 했습니다. 노션, 슬랙, 지라, 그리고 코드 저장소에 흩어진 정보들을 어떻게 연결할 것인가. 처음에는 통합 검색 UI를 만들려고 했지만, 이내 그것이 얼마나 비효율적인지 깨달았습니다. UI는 필연적으로 사용자의 의도를 제한하기 때문입니다.

ExoPriors의 사례는 우리에게 중요한 힌트를 줍니다. "가장 좋은 UI는 UI가 없는 것(No UI)"일 수 있다는 점입니다.

특히 인상 깊었던 부분은 '도구의 위험성'을 대하는 태도였습니다. 원문 작성자는 "Claude Code와 Codex는 사실상 AGI에 가깝다"고 언급하며, 개발자가 아니더라도 이 도구에 익숙해져야 한다고 강조합니다. 심지어 편의성을 위해 보안 확인 절차를 건너뛰는 --dangerously-skip-permissions 옵션을 언급하기도 하죠. 물론 보안상 위험하지만, 그만큼 '속도'와 '탐색의 자유'를 중요시한다는 방증입니다.

앞으로의 엔지니어링: 코딩보다 '질의'하는 능력

이 프로젝트가 시사하는 바는 명확합니다. 앞으로의 백엔드 엔지니어링은 API를 예쁘게 포장해서 프론트엔드에 전달하는 것을 넘어, AI 에이전트가 이해하고 실행할 수 있는 명확한 스키마와 도구(Tooling)를 설계하는 것으로 진화할 것입니다.

ExoPriors가 p_<8 hex>_<name> 같은 형태로 공개 핸들(Handle) 네이밍 규칙을 정하고, mv_arxiv_papers 같은 Materialized View를 미리 준비해 둔 것처럼 말이죠. 이것은 인간을 위한 스키마가 아니라, AI가 효율적으로 탐색하기 위한 '지도'를 그려준 셈입니다.

솔직히 말해, 저도 처음엔 반신반의했습니다. "과연 LLM이 복잡한 SQL 조인 순서를 최적화할 수 있을까?" 하지만 Postgres가 조인 순서를 정하게 두거나, 타임아웃이 발생하면 클라이언트 사이드에서 교집합을 구하는 방식으로 우회하는 전략을 프롬프트에 명시한 것을 보고 무릎을 쳤습니다. 이것은 단순한 자동화가 아니라, AI와 데이터베이스 엔진의 특성을 완벽하게 이해한 엔지니어링입니다.

마치며

독자 여러분, 혹시 지금도 사내 어드민 페이지에 검색 필터 하나 더 추가해달라는 요청 때문에 야근하고 계신가요? 아니면 방대한 로그 데이터 속에서 원인을 찾지 못해 grep만 하염없이 치고 계신가요?

관점을 조금만 바꿔보세요. 데이터를 보여주는 화면을 만드는 대신, 데이터에 접근할 수 있는 권한을 가진 똑똑한 에이전트를 동료들에게 선물하는 건 어떨까요? 물론 프롬프트 인젝션 같은 보안 이슈는 철저히 대비해야겠지만, 그 너머에 있는 생산성의 폭발은 우리가 상상하는 그 이상일 것입니다.

기술은 결국 도구일 뿐입니다. 하지만 그 도구를 쥐는 방식이 바뀌면, 우리가 해결할 수 있는 문제의 크기도 달라집니다. 저도 오늘 밤엔 터미널을 열고 우리 팀의 레거시 데이터베이스에 Claude를 한번 초대해 봐야겠습니다. 어떤 통찰을 줄지 벌써 기대가 되네요.