Hamlet의 CEO Sunil Rajaraman, 엔지니어 Erich Douglass, Jeff Hui와의 대화
작성자: Sara Steffen
지방 정부의 의사 결정 과정을 누구나 쉽게 검색하고 접근할 수 있도록 지원하는 AI 기반 플랫폼인 Hamlet은 Databricks Lakebase Postgres를 활용해 모든 풀 리퀘스트에 운영 데이터의 자체 브랜치를 부여합니다. 엔지니어와 AI 코딩 에이전트는 운영 환경에 영향을 주지 않고 실제 데이터를 대상으로 변경 사항을 테스트 할 수 있으며, 모든 병합(merge)은 여전히 사람이 최종 승인합니다.
CEO인 Sunil Rajaraman, 리드 개발자인 Erich Douglass, 수석 AI 엔지니어인 Jeff Hui와 함께 이들이 일하는 방식에 대해 이야기를 나누었습니다.
Hamlet은 지방 정부의 의사 결정 과정을 쉽게 검색하고 접근할 수 있게 해주는 AI 기반 기술 플랫폼입니다. Hamlet은 미국 전역의 수천 개 시의회, 계획 위원회, 구역 지정 위원회 회의를 색인화하고 전사(transcribe)하여, 부동산 개발업자, 언론인, 연구원, 시민들이 회의록을 즉시 검색하고 지역 정책 동향을 추적하며 특정 주제, 주소, 기업에 대한 실시간 알림을 설정할 수 있도록 지원합니다.
Sara Steffen: Hamlet은 모든 주에 걸쳐 7,200개 이상의 행정 기관 회의를 색인화합니다. 데이터 환경은 어떤 모습이며, 이를 이해하고 분석하는 것이 왜 그렇게 어려운가요?
Sunil Rajaraman: 미국에는 19,000개의 시 정부, 3,000개의 카운티 정부, 그리고 약 80,000개의 특수 구역이 있습니다. 이 중 두 웹사이트를 아무렇게나 골라보아도 서로 비슷하지 않을 것입니다. 이것이 지방 정부의 원죄입니다. 소수의 CMS 제공업체가 모든 사이트를 다르게 만들어야 한다고 결정했고, 그 결과 정부 인터넷 환경이 완전히 파편화되었습니다. Hamlet은 이 모든 것을 하나로 모아 표준화합니다.
Sara: Hamlet은 스스로를 시민 인텔리전스 플랫폼으로 정의합니다. 이것이 단순 전사 도구와 어떻게 다르며, 왜 이러한 구분이 중요한가요?
Sunil: 많은 거브텍(govtech) 기업들이 지방 자치 단체 데이터를 단순히 중개(arbitrage)합니다. 1998년 스타일의 웹사이트에 대한 불안정한 스크래퍼를 작성하고 그 위에 현대적인 디자인을 살짝 입힙니다. 데이터를 스크래핑하고 저장하는 것 자체만으로는 큰 가치를 더하지 못합니다. 유의미한 이야기를 들려주어야 하며, 이는 사실에 기반해야 합니다. 즉, 누구의 발언인지, 그리고 특정 안건에 대해 어떤 입장인지 알아야 합니다. 당신이 개발자라면 의회 의원이 주택 개발 프로젝트를 승인할지 여부와 그 이유, 그리고 도시가 망설일 만한 과거 전례가 있는지 알고 싶을 것입니다.
인허가 과정을 예로 들어보겠습니다. 인허가 데이터에 수많은 벤처 자금이 투입되었음에도 지난 10년간 인허가 소요 시간은 오히려 악화되었습니다. 많은 기업들이 근본적 원인이 아닌 증상만을 해결하려 했습니다. 우리는 근본적인 문제인 '사람을 이해하는 것'에 접근하고자 합니다. 우리가 답을 찾고자 하는 질문은 '도시가 근본적으로 어떻게 작동하는가'입니다.
Sara Steffen: 지방 정부 데이터를 다루기가 그토록 어려운 이유는 무엇인가요?
Sunil Rajaraman: 어떤 웹사이트 두 개를 선택해도 서로 다르게 생겼습니다. Hamlet은 이를 하나로 모아 표준화합니다.
Erich Douglass: 단 하나의 제공업체와만 연동할 수 없습니다. 7~8개 업체가 시장의 약 75%를 점유하고 있으며, 나머지는 맞춤형 설정으로 구성된 엄청난 롱테일 시장입니다. 때로는 서기가 안건의 PDF를 업로드하고, 때로는 종이 사본을 스캔하여 업로드하기도 합니다. 이로 인해 정말 이상한 형 태의 데이터 부산물이 생성되곤 합니다.
Sara: 고객들은 해당 데이터에서 어떤 정보를 얻고자 하나요?
Sunil: 우리의 고객은 부동산 개발업체, 데이터 센터 개발업체, 소매업체와 같은 민간 기업들입니다. 이들 중 거의 대부분은 프로젝트 승인을 더 빠르게 받거나 새로운 기회를 찾고자 합니다. Hamlet이 없다면 직원이 몇 시간 동안 회의에 참석해 자사 프로젝트 관련 안건이 나오기를 기다리며 공무원들의 제스처와 반응을 지켜봐야 합니다. 우리는 발언자가 누구인지 식별하고 해당 타임스탬프로 바로 이동해 증거를 정확히 보여줍니다.
Erich: 그들은 선례(precedent)도 알고 싶어 합니다. 자신들과 유사한 프로젝트가 이전에 승인되었는지, 아니면 거부되었는지, 그 이유는 무엇인지, 의회가 어떤 변경 사항을 요구했는지 등입니다. 실제로 무슨 일이 일어나고 있는지 보여줄 수 있다면 이는 매우 큰 가치를 제공합니다.
Sara: 고객이 도출된 인사이트를 신뢰할 수 있도록 어떻게 돕고 있나요?
Jeff Hui: 우리는 프로세스의 거의 모든 부분에서 AI를 활용합니다. 초기에는 Hamlet이 이 작업을 수작업으로 진행했지만, 수천 개 지역으로 확장하기에는 한계가 있었습니다. 많은 지방 정부의 경우 비디오 영상이 핵심적인 신뢰할 수 있는 단일 출처(source of truth)입니다. 이를 활용 가능한 정형 데이터 형태로 변환하는 것이 가장 중요한 작업입니다. 평균 회의 시간은 약 3시간 반에 달하며, 누구도 이를 처음부터 끝까지 다 보고 싶어 하지 않습니다. AI는 시간을 투자할 만한 가치가 있는 부분을 짚어주며, 해당 비디오 영상이 이를 항상 뒷받침해 줍니다. 우리는 무슨 말이 전달되었는지 정확하게 보여줄 수 있으며, 이는 많은 AI 시스템이 어려움을 겪는 부분입니다.
Sara: 수천 개의 회의에서 발언자를 어떻게 정확하게 식별하나요?
Jeff: 문맥(Context)이 가장 큰 차이를 만듭니다. 발언자 식별을 위해 우리는 어떤 의회나 위원회가 회의 중인지, 그리고 당시 위원이 누구였는지 파악합니다. 이를 통해 녹음 내용을 직접 듣는 사람조차 정확히 파악하기 어려운 이름 구별에 도움을 받습니다. 단순히 모델에 비디오 영상을 제공하고 알아서 잘 처리해주기를 바랄 수는 없습니다. 정확한 판단을 내릴 수 있도록 주변의 모든 관련 정보를 수집해야 합니다. 이는 끝없는 도전 과제입니다.
Sara: 공무원 발언에 대한 AI의 해석을 어떻게 검증하나요?
Sunil: 정확한 전사(transcription)가 첫 번째 단계입니다. 감정 분석(sentiment)의 경우, 여러 AI 모델을 사용하여 특정 코멘트가 데이터 센터와 같은 특정 주제에 관한 것인지 먼저 확인합니다. 그런 다음 주변 문맥을 분석하여 찬성인지 반대인지 판단합니다.
또한 질의하기 전에 '찬성'과 '반대'의 의미를 명확히 정의해야 합니다. 예를 들어 치안 유지 정책을 들 수 있습니다. '찬성'한다는 것이 정확히 무엇을 의미할까요? 우리는 이러한 질문 설정에 많은 세심한 주의를 기울입니다. 현재 여러 모델이 게시 전 모든 감정 분석 데이터를 검토하며, 우리는 높은 신뢰도를 요구합니다.
Lakebase는 Hamlet이 각 풀 리 퀘스트에 운영 데이터의 자체 브랜치를 부여하기 위해 사용하는 관리형 Postgres 데이터베이스입니다. 엔지니어는 운영 환경을 건드리지 않고 버그를 유발한 데이터를 대상으로 변경 사항을 테스트할 수 있으며, AI 코딩 에이전트는 사람이 병합을 승인하기 전에 파이프라인을 실행하고 작업을 검증합니다. 팀에 따르면 이전의 테스트 데이터 구축 방식은 엔지니어 1인당 매주 수시간이 소요되었다고 합니다.
Sara: Lakebase를 선택한 이유는 무엇이며, 팀에는 어떤 변화가 있었나요?
Erich: 우리는 AWS RDS 기반의 일반적인 환경을 구성하여 1개의 운영 인스턴스와 1개의 스테이징 인스턴스를 운영하고 있었습니다. 저희 작업의 상당 부분은 매우 특정 데이터에 대해 데이터 파이프라인을 튜닝하는 일입니다. 그래서 모든 풀 리퀘스트마다 검증을 실행하기 전 스테이징을 적절한 상태로 맞추는 데 15분에서 30분이 걸렸습니다. 소규모 팀인 저희에게 개발 속도는 무엇보다 중요했습니다.
데이터 브랜칭이 바로 저희의 마음을 사로잡은 기능이었습니다. 이제 모든 풀 리퀘스트는 미리보기(preview) 환경에 연결된 자체적인 운영 데이터 브랜치를 갖게 됩니다. 미리보기가 배포되면 바로 준비가 끝납니다. 운영 환경에는 아무런 영향을 주지 않으면서 운영 데이터를 대상으로 테스트하고 데이터를 기록할 수도 있습니다.
오토스케일링도 큰 도움이 됩니다. RDS에서는 더 큰 인스턴스로 전환하려면 몇 시간이 걸리는 마이그레이션이 필요했습니다. 이제는 슬라이더만 조정하면 인스턴스 용량을 두 배로 쉽게 늘릴 수 있습니다.
Jeff: 15분에서 30분이라는 시간도 정확히 필요한 데이터를 제대로 복사했을 때의 최상의 시나리오였습니다. 엔지니어마다 문제를 추적하기 위해 운영 데이터 일부를 로컬에 복제하는 등 테스트 데이터를 최신 상태로 유지하는 데 매주 수시간을 소비하곤 했습니다. 이제는 버그가 발생하면 버그를 유발한 원인 데이터를 즉시 확보하여 동일한 데이터를 기반으로 수정 사항을 확인할 수 있습니다.
Sara: Lakebase는 AI 코딩 에이전트의 작동 방식을 어떻게 바꾸어 놓았나요?
Jeff: 브랜치 덕분에 저희의 워크플로우가 AI 코딩 에이전트에 훨씬 더 잘 적합해졌습니다. 각 풀 리퀘스트는 운영 환경과 완전히 격리됩니다. Claude나 Codex 같은 에이전트에 해당 브랜치에 대한 접근 권한을 주고 스스로 검증을 수행하도록 합니다. 에이전트는 데이터 파이프라인을 끝까지 실행하고 변경 사항이 의도대로 동작하는지 확인합니다. 모든 풀 리퀘스트는 에이전트의 1차 검토를 거치게 되며, 사람이 직접 검토하는 시점에는 이미 정상 작동에 대한 상당한 확신을 갖게 됩니다. 사람이 최종 병합을 승인하며, 그 외의 부분은 점차 자동화되고 있습니다. Lakebase는 이를 가능하게 만든 핵심 요소입니다.
Sara: Lakebase를 통해 다음으로 시도하고 계신 것은 무엇인가요?
Erich: 현재 대부분의 데이터는 관계형 데이터베이스에 저장되어 있으며, 검색은 별도의 벡터 데이터베이스에서 실행됩니다. 이로 인해 두 데이터베이스 간 동기화가 어긋나는 현상이 발생합니다. 이 경우 검색 테스트는 다시 예전의 스테이징 문제로 돌아가게 됩니다. 최근 Postgres에서 벡터 검색과 텍스트 검색을 결합한 Lakebase Search를 시도해보았는데, 모든 것을 한곳에서 처리할 수 있어 매우 유용했습니다.
Sara: 검색 외에 다음에 단순화하고 싶은 작업은 무엇인가요?
Erich: 브랜칭 기능이 매우 효과적이었기 때문에 개체 스토리지(object storage)에 보관된 대용량 파일에도 동일한 기능을 적용할 수 있으면 좋겠습니다. 모든 개발자가 하나의 공유 운영 버킷 옆에 테스트 버킷을 두고 사용하고 있어 이들 간의 상태 관리 방식이 까다롭기 때문입니다.
Jeff: 또한 시간이 오래 걸리는 에이전틱(agentic) 작업을 어디에서 실행할지 검토하고 있습니다. 데이터 수집 절차 중 일부는 AI를 활용해 웹 브라우저를 제어하고 정부 사이트에서 적절한 콘텐츠를 검색합니다. 일부 작업은 몇 분 정도 걸리지만, 어떤 작업은 30분이나 40분이 걸리기도 하여 현재 15분 제한이 있는 AWS Lambda 환경에서는 한계가 있습니다.
Hamlet의 작업은 원본 회의 녹음에서 시작되므로 고객은 AI 인사이트를 관계자의 발언까지 거슬러 올라가 추적할 수 있습니다. Lakebase는 이러한 경험을 뒷받침하는 엔지니어링 워크플로를 지원합니다. 운영 데이터의 브랜치를 통해 개발자와 코딩 에이전트가 운영 환경에 영향을 주지 않고 변경 사항을 테스트할 수 있으며, 최종 병합은 사람이 승인합니다. 수천 개의 의결 기관을 대상으로 작업하는 소규모 팀의 경우, 이는 테스트 데이터 준비 시간을 줄이고 제품 개선에 더 많은 시간을 할애할 수 있음을 의미합니다.
풀 리퀘스트마다 Lakebase 브랜치를 생성하고 자동으로 삭제하려면 어떻게 해야 하나요?
지속적 통합(CI) 파이프라인에 두 가지 단계를 추가하세요. 풀 리퀘스트(PR)가 열릴 때 운영 환경에서 브랜치를 생성하고 PR이 병합되거나 닫힐 때 이를 삭제합니다. Databricks CLI로 두 단계를 모두 스크립트화하고 GitHub Actions와 같은 도구에서 실행할 수 있습니다. 브랜치를 생성할 때 만료 시간(TTL)을 설정하면 정리 단계가 실행되지 않더라도 자동으로 삭제됩니다. 전체 예시는 브랜치 기반 개발 워크플로 튜토리얼을 참조하세요.
Postgres에서 데이터베이스 브랜칭은 어떻게 작동하나요?
Lakebase 브랜치는 부모의 스키마 및 데이터로 시작하고 기록 시 복사(copy-on-write)를 통해 부모와 스토리지를 공유하는 독립적인 Postgres 환경입니다. 브랜치에서 변경된 사항만 별도로 기록되므로, 브랜치 생성 속도는 데이터베이스 크기에 영향을 받지 않습니다. 표준 Postgres는 기존 데이터베이스를 복사하여 새 데이터베이스를 생성하므로 데이터가 중복됩니다. Lakebase 데이터베이스 브랜치는 이러한 복사를 방지하며, 자식 브랜치에서의 변경 사항은 부모 브랜치에 전혀 영향을 주지 않습니다.
개발 팀에 데이터베이스 브랜칭을 적용하려면 어떻게 해야 하나요?
Hamlet이 사용하는 패턴인 풀 리퀘스트당 하나의 브랜치로 시작한 다음, 나머지 워크플로로 브랜칭을 확장하세요. 각 패턴은 공유 스테이징 데이터베이스를 격리된 환경으로 대체합니다.
Lakebase 브랜치 비용은 얼마인가요?
비용은 컴퓨팅 및 스토리지에 따라 달라집니다. 각 브랜치는 유휴 상태일 때 0으로 스케일링되는 전용 컴퓨팅을 가지므로 활성 컴퓨팅 시간에 대해서만 비용을 지불합니다. 스토리지의 경우 만료되는 브랜치는 브랜치에서 변경된 데이터에 대해서만 청구되는 반면, 만료 기간이 없는 영구 브랜치는 전체 데이터 크기에 대해 청구됩니다. 수명이 짧은 브랜치에는 만료 시간을 설정하세요. 옵션에 대해서는 브랜치 만료를 참조하세요.
AI 코딩 에이전트가 운영 환경에 영향을 주지 않고 Lakebase 브랜치에서 테스트할 수 있나요?
예, 가능합니다. 각 브랜치는 운영 환경과 격리되어 있으므로 에이전트가 마이그레이션을 적용하고 테스트를 실행한 후 작업이 끝나면 브랜치를 폐기할 수 있습니다. 최종 병합 승인은 여전히 사람이 진행하며, 스키마 변경 사항은 브랜치 병합이 아닌 코드 내 마이그레이션을 통해 부모 브랜치로 이동합니다.
Lakebase에 대해 자세히 알아보려면 Lakebase Postgres 제품 페이지를 방문하세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.