이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Harmonic의 AI 제품 엔지니어 Austin Berke가 스타트업 데이터베이스 인터페이스인 Scout를 구축하며 겪은 에이전트 아키텍처 진화 과정을 공유한다. 초기 복잡한 쿼리 파싱 그래프 구조에서 모델, 도구, 미들웨어로 구성된 'Deep Agents' 하네스 구조로 전환하며 사용자 유지율을 4배 높였다. 에이전트의 자율성과 사용자 경험(UX) 사이의 긴장을 해결하기 위해 하네스 계약을 도입하여 모델이 볼 수 있는 정보와 외부 정보를 엄격히 분리하고, 대규모 데이터 처리를 위해 공유 파일 시스템을 활용하는 실무적 설계 원칙을 제시한다.
챕터별 상세
00:00
Harmonic과 Scout 개요
Harmonic은 3,700만 개 기업과 2억 명의 인물 데이터를 추적하는 실시간 데이터베이스이다. Scout는 이 데이터를 자연어로 검색할 수 있는 인터페이스로, 복잡한 쿼리도 처리한다. 사용자가 질문을 입력하면 Scout는 이를 해석하여 데이터베이스에서 정보를 추출하고, 사용자에게 필요한 형태로 가공하여 제공한다. 이 과정은 데이터베이스의 방대한 정보를 사용자가 쉽게 접근할 수 있도록 돕는다.
00:31
Scout의 자연어 인터페이스
Scout는 Deep Agents를 기반으로 작동하며, 간단한 질문부터 복잡한 시장 분석까지 수행한다. 사용자가 질문을 입력하면 백그라운드에서 툴 루프가 실행되고 결과가 사용자에게 렌더링된다. 이 시스템은 자연어 쿼리를 해석하여 적절한 도구를 선택하고, 데이터를 검색한 후 사용자에게 보여준다. 이러한 방식은 사용자가 복잡한 데이터베이스 쿼리를 몰라도 원하는 정보를 얻을 수 있게 한다.
01:24
유지율 지표
Scout 2.0으로 전환한 후, 1주차 대비 4주차 유지율이 4배 증가했다. 정량적 지표뿐만 아니라 사용자들로부터 "천국 같다"는 긍정적인 정성적 피드백도 확보했다. 이는 에이전트의 성능 향상이 실제 사용자 경험 개선으로 이어졌음을 보여준다. 높은 유지율은 Scout가 사용자의 문제를 효과적으로 해결하고 있음을 입증한다.
01:52
Scout 1.0의 한계
Scout 1.0은 쿼리 파서가 복잡한 그래프 구조로 설계되어 있었다. 각 노드마다 모델과 평가 로직이 포함되어 있어 유지보수 비용이 매우 높았다. 이러한 복잡성은 시스템의 유연성을 떨어뜨리고 새로운 기능을 추가하기 어렵게 만들었다. 결국 더 단순하고 확장 가능한 구조가 필요하다는 결론에 도달했다.
02:41
Scout 2.0으로의 전환
Scout 2.0은 모델, 도구, 미들웨어로 구성된 단순한 루프 구조로 변경되었다. 미들웨어는 모델 전후와 에이전트 전후에 배치되어 복잡한 롱 컨텍스트를 관리한다. 이 구조는 시스템을 단순화하고 유지보수를 용이하게 만들었다. 또한, 각 구성 요소가 독립적으로 작동하여 시스템의 안정성을 높였다.
03:42
Deep Agents 하네스 선택 이유
Deep Agents를 하네스로 선택한 이유는 복잡한 롱 컨텍스트 관리와 도구 호출 효율성 때문이다. 50개 이상의 도구를 사용하여 복잡한 복합 작업을 수행할 수 있다. 하네스는 모델이 도구를 선택하고 실행하는 과정을 관리하며, 필요한 컨텍스트를 제공한다. 이를 통해 모델은 더 복잡한 작업을 정확하게 수행할 수 있다.
04:56
컨텍스트 관리
메시지 리스트가 길어지면 모델의 성능이 저하된다. Deep Agents는 메시지 리스트를 압축하고, 대규모 결과는 파일 시스템으로 오프로딩하여 모델의 컨텍스트 오버로드를 방지한다. 이는 모델이 필요한 정보에만 집중할 수 있게 하여 처리 속도와 정확도를 높인다. 결과적으로 더 긴 대화도 안정적으로 처리할 수 있다.
05:33
제품화 과정
에이전트의 기술적 프리미티브를 사용자가 이해할 수 있는 제품으로 변환해야 한다. 채팅 인터페이스와 사용자 정의 UX를 결합하여 자연스러운 워크플로우를 제공한다. 기술적 복잡성을 숨기고 사용자에게는 직관적인 인터페이스를 제공하는 것이 중요하다. 이는 사용자가 에이전트를 더 쉽게 활용할 수 있게 돕는다.
06:47
에이전트와 UX의 긴장
에이전트는 코드와 같은 구조를 선호하지만, 일반 사용자는 코드를 싫어한다. 에이전트의 자율성과 사용자 친화적인 UX 사이의 긴장을 해결하는 것이 핵심이다. 에이전트가 내부적으로는 복잡한 코드를 처리하더라도, 사용자에게는 이해하기 쉬운 형태로 결과를 보여주어야 한다. 이 긴장을 해결하는 것이 제품 성공의 열쇠이다.
07:04
하네스 계약
하네스 계약은 모델이 볼 수 있는 정보와 외부 정보를 엄격히 분리한다. 모델은 메시지 리스트만 볼 수 있고, 하네스는 외부 데이터를 관리하며 모델에게 필요한 정보만 제공한다. 이는 모델이 외부 정보에 의해 혼란을 겪지 않도록 방지한다. 하네스는 모델의 에이전시를 유지하면서도 안전한 환경을 제공한다.
08:47
시각화 문제
사용자는 차트나 시장 지도를 원하지만, 모델은 SVG나 HTML 코드를 출력한다. 이를 직접 렌더링하는 방식은 모델이 결과를 알 수 없게 만들어 블랙박스가 된다. 모델이 결과를 알 수 없으면 수정이나 추가 요청이 어렵다. 따라서 모델이 결과를 이해하고 제어할 수 있는 구조가 필요하다.
11:28
대규모 결과 처리
검색 결과가 수천 건에 달할 때 메시지 리스트에 모두 담으면 모델이 과부하된다. 검색 결과를 별도로 저장하고 모델에게는 결과의 ID와 상태만 제공하여 점진적으로 정보를 노출한다. 이는 모델이 필요한 정보만 선택적으로 가져올 수 있게 한다. 결과적으로 모델의 성능을 최적화하고 사용자 경험을 개선한다.
13:43
공유 파일 시스템 해결책
공유 파일 시스템을 통해 에이전트와 프론트엔드가 데이터를 교환한다. 에이전트는 파일을 쓰고, 프론트엔드는 이를 읽어 렌더링하며, 모델은 파일의 경로를 통해 데이터를 제어한다. 이 방식은 에이전트와 프론트엔드가 독립적으로 작동하면서도 데이터를 공유할 수 있게 한다. 결과적으로 시스템의 유연성과 확장성이 높아진다.
15:22
UX 디자인 스니프 테스트
에이전트 UX 설계 시 하네스와 싸우지 않는 것이 중요하다. 모델이 결과를 직접 렌더링하도록 강요하지 말고, 하네스를 통해 점진적으로 정보를 제공하는 구조를 설계해야 한다. 하네스의 규칙을 이해하고 이를 활용하는 것이 성공적인 에이전트 설계의 핵심이다. 이는 모델과 UX 사이의 조화를 이루는 데 도움이 된다.
용어 해설
- 하네스(Harness)
- — 에이전트의 모델과 외부 도구 사이에서 컨텍스트 관리, 도구 호출, 데이터 오프로딩 등을 수행하는 인프라 계층. 모델의 성능을 유지하고 복잡한 작업을 처리하는 데 필수적이다.
- 컨텍스트 윈도우(Context Window)
- — 모델이 한 번에 처리할 수 있는 정보의 양. 에이전트 설계 시 이를 효율적으로 관리하여 모델의 과부하를 방지하고 성능을 최적화하는 것이 중요하다.
- 점진적 정보 공개(Progressive Disclosure)
- — 대규모 데이터를 한 번에 모델에 전달하지 않고, 필요한 정보만 단계적으로 제공하여 모델의 과부하를 방지하는 설계 방식. 사용자 경험과 모델 성능을 동시에 개선한다.
언급된 리소스
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 07.수집 2026. 08. 07.출처 타입 YOUTUBE
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
