지난 6개월간 6개의 에이전트 하네스를 만들었는데, 전부 데이터베이스가 필요하네요
I built 6 agent harnesses in the last 6 months, they all need a database
핵심 요약
에이전트의 상태 관리와 지속성을 위해 마크다운 파일 대신 별도의 데이터베이스를 구축하는 방법에 대한 논의입니다.
- 에이전트 데이터베이스 — 에이전트의 실행 로그와 상태를 기록하는 전용 DB 구축
- 데이터 구조 설계 — 제어 상태, 불변 이벤트 로그, 파생 지식으로 구분하여 관리
- SQLite의 한계 — 병렬 작업 및 동시 쓰기 환경에서 발생하는 성능 문제
- 상태 관리 전략 — 외부 호출 전 의도 기록을 통해 재시작 시 중복 실행 방지
에이전트 데이터베이스를 어떻게 설계하시나요?
지난 6개월 동안 6개의 에이전트 하네스를 만들었습니다. 이유는 묻지 마세요. 에이전시에서는 고객이 원하는 대로 해야 하니까요.
Ramp, Stripe, WorkOS, OpenAI, Anthropic, HumanLayer, Deepset 등의 기사에서 작업하며 얻은 모범 사례 중 일부는 다음과 같습니다:
- 작은 에이전트 프롬프트 사용.
- 에이전트가 스스로 처리하게 두기.
- 결정론적 게이트 사용.
- 평가하고 에이전트가 모든 것을 성찰하게 하기.
- 상태 관리.
- 격리된 환경 사용.
- 결정론적 정책 사용.
여기에 잘 언급되지 않는 몇 가지 관행이 더 있는데, 그중 하나는 에이전트를 위한 데이터베이스, 일종의 agent.db를 갖는 것입니다.
여기서 말하는 건 Lovable이나 Bolt가 Supabase 통합을 통해 제공하는 애플리케이션 데이터베이스가 아닙니다. 에이전트가 무엇을 하는지에 대한 데이터베이스를 의미합니다.
처음에는 간단한 실행 로그로 시작했습니다. 작업 할당, 평가 실행, 결과 기록 등 에이전트 하네스의 이벤트를 기록했죠.
거창한 걸 만들 의도는 없었기에 기본적인 WAL이 포함된 SQLite를 사용했습니다. 사용하다 보니 성찰과 학습, 사후 기능 요청 생성, 일시 중지된 실행 재개, 그리고 에이전트에게 빠르고 쉽게 검색할 수 있는 상태를 제공하는 데 유용하다는 것을 알게 되었습니다(Obsidian으로 이 글을 쓰면서 마크다운 파일은 그렇지 않다는 걸 느끼네요).
혹시 에이전트가 하는 일을 추적하기 위해 데이터베이스를 사용하는 분이 계신지 궁금합니다. 물론 Phoenix, LangFuse나 에이전트 추적을 저장하는 수많은 도구 같은 에이전트 관측 가능성 도구에 대해서는 알고 있습니다. 그것들도 중요하지만 제가 생각하는 전부는 아닙니다.
에이전트가 연속성을 가지고 시간이 지남에 따라 성장할 수 있도록 영구 저장소에 큐, 실행, 작업, 이벤트, 학습 내용을 담는 것에 대한 이야기입니다.
마크다운 파일 외에 이 문제를 어떻게 해결하시나요?
