딥 에이전트 UX 설계 원칙: 하네스 계약과 점진적 공개로 리텐션을 4배로 올린 하모닉 사례

핵심 메시지

• 에이전트는 모델과 하네스의 조합이고 제품은 거기에 UX를 얹은 것이라는 구분에서 발표가 출발한다.
• 노드마다 모델과 평가를 따로 관리하던 질의 파싱 그래프를 버리고 모델·도구·미들웨어로 이뤄진 단순한 도구 호출 루프로 옮긴 뒤 1주차 대비 4주차 리텐션이 4배가 됐다.
• 하네스는 메시지 목록에서 덩치 큰 내용을 덜어내되, 덜어낸 것은 반드시 도구로 다시 꺼내볼 수 있게 해준다는 계약을 지킨다.
• 메시지 목록에도 하네스의 관할에도 없는 화면 요소는 모델에게는 존재하지 않는 것과 같아, 사용자가 그 화면을 두고 질문하면 답할 수 없다.
• 모델에게 '이 도구를 부르면 화면에 그려지니 믿고 답에는 넣지 말라'고 설득하고 있다면 설계가 잘못됐다는 신호라고 본다.

쉽게 이해하기

스타트업 데이터베이스 회사 하모닉의 AI 제품 엔지니어 오스틴 버크가 랭체인 채널에 공개된 발표에서 자사 제품 스카우트를 다시 만든 과정을 공유했다. 하모닉은 기업 3700만 곳, 인물 2억 명, 투자자 22만 곳을 추적하는 실시간 데이터베이스이고, 스카우트는 그 위에 얹은 자연어 인터페이스다. '랭체인 CEO가 누구야' 같은 단순 질의부터 산업 지형도를 그려 달라거나 특정 기준표로 팀을 1~10점으로 매겨 달라는 복잡한 요청까지, 뒤에서 도구 루프를 돌려 처리한 뒤 화면에 그려 준다.

초기 버전은 지금과 전혀 다른 구조였다. '지난 두 달 안에 투자받은 뉴욕의 핀테크 SaaS 기업을 모두 보여줘' 같은 문장을 받아 의미 부분, 지역, 투자 조건으로 쪼개고 각각을 임베딩 검색이나 자체 검색으로 흘려보내는 질의 파싱 그래프였다. 각 노드가 저마다 모델과 평가셋을 갖고 있어서 통과시키려면 끝없이 손을 봐야 했다. 모델이 좋아지고 하네스가 등장하면서 팀은 이 그래프를 걷어내고, 가운데에 도구 호출 루프 하나만 두는 구조로 갈아탔다. 모델 호출 전후와 에이전트 루프 전후에 끼어드는 미들웨어가 나머지를 맡는다.

딥 에이전트를 하네스로 고른 이유는 도구가 50개에 이르고 결과가 지나치게 커지기 때문이다. 기업 검색 하나가 수천 건을 돌려주고 각 기업마다 팀원과 투자 정보가 딸려 오면, 그 응답을 그대로 메시지 목록에 넣는 순간 대화가 순식간에 막힌다. 딥 에이전트는 메시지 목록이 길어지면 압축을 돌려 계속 이어가게 하고, 큰 도구 결과는 파일 시스템으로 옮긴 뒤 그 위치를 가리키는 포인터만 돌려준다. 여기에 스킬과 커스텀 미들웨어로 필요한 프롬프트 정보를 실행 시점에 끌어올 수 있고, 이미 랭스미스 배포 위에 있던 덕분에 사용자에게는 같은 채팅 화면을 유지한 채 조금씩 옮겨 갈 수 있었다.

발표의 중심은 하네스가 모델과 맺는 계약이다. 모델이 보는 것은 언제나 메시지 목록뿐이고, 하네스의 일은 컨텍스트 창이 터지거나 맥락이 썩지 않도록 그 목록에서 무언가를 덜어내는 것이다. 대신 덜어낸 것은 반드시 도구를 통해 다시 접근할 수 있어야 한다. 파일로 옮겼다면 경로를 알려주고 조각 단위로 읽을 도구를 함께 주는 식이다. 버크는 이를 점진적 공개라고 부르면서, 이 두 층 바깥에 있는 것은 아무리 화면에 예쁘게 그려져 있어도 모델에게는 보이지 않는다고 못 박는다.

그가 부딪힌 긴장은 여기서 나온다. 모델은 구조화된 JSON이나 XML, 파일 경로처럼 코드에 가까운 것을 좋아하는데, 스카우트 사용자 대부분은 비개발자다. 모델이 '이 경로에 파일을 썼습니다'라고 말하는 화면을 보여줄 수는 없다. 그래서 하네스의 성능을 그대로 쓰면서도 일반 사용자가 쓸 만한 제품을 만드는 방법을 찾아야 했고, 시각화와 검색 결과라는 두 사례에서 그 답을 정리했다.

주요 인사이트

• 잘못된 방식의 전형은 '이 데이터를 그려라'라는 도구를 만들어 두고 프런트엔드가 그 호출을 가로채 렌더링하는 것이다. 모델은 성공 여부만 돌려받으므로 사용자가 '왜 저 기업이 왼쪽에 있냐'고 물으면 아무 맥락이 없다.
• 시각화처럼 작은 결과물은 아예 메시지 목록 안에 두는 편이 낫다. 모델이 정해진 태그로 HTML을 감싸 출력하면 프런트엔드가 그 부분만 가로채 실시간으로 그리고, 모델은 자기가 그린 것이므로 수정 요청도 그대로 받아낼 수 있다.
• 검색처럼 결과가 수만 건이라 메시지 목록에 넣을 수 없을 때는, 도구가 검색 식별자와 상태와 건수만 돌려주고 '상태 조회'나 '앞의 10건 가져오기' 같은 도구를 함께 주는 방식으로 모델이 필요할 때 맥락을 쌓아 올리게 한다.
• 가장 나은 형태로 제시된 것은 파일 시스템을 공유 저장소로 쓰는 방식이다. 메인 에이전트가 ls·읽기·grep 으로 들여다보는 같은 파일 시스템에 검색 서브에이전트가 결과를 계속 써 넣고, 프런트엔드도 같은 곳을 API로 읽어 화면에 뿌린다.
• 설계가 어긋났는지 가늠하는 기준으로 '모델과 싸우고 있는가'를 제시한다. 도구를 부르면 사용자에게 보이니 믿으라거나 답에 넣지 말라고 프롬프트로 설득하고 있다면, 그건 모델에게 보이지 않는 무언가가 있다는 냄새라는 것이다.

자주 묻는 질문

관련 AI 소식