← 모든 글

Agent 검색을 위한 편안한 AX 설계하기

Tenny

작성 Tenny

Cofounder & CTO & AX Designer

게시일 2026년 6월 11일

당신은 인간이 보는 모든 픽셀을 정성껏 설계했습니다. 그리고 Agent에게는 원시 ID의 벽을 던져주고 그것을 결과라고 부릅니다.

Human search results compared with an agent raw result dump
당신이 보는 것. 당신의 Agent가 받는 것.

Agent가 검색을 실행할 때 무엇을 받아야 할까요?

당신은 오래전에 인간을 위해 이 질문에 답했습니다. 원시 데이터베이스 dump를 사람에게 던지고 검색 기능이라고 부르지는 않습니다. 결과 페이지를 반환합니다. 요약의 묶음이고, 각각은 매칭된 내용으로 난 작은 창이며, 각각 클릭할 수 있습니다. 요약은 그것이 무엇인지 알려줍니다. 링크는 다음에 무엇을 해야 하는지 알려줍니다.

이제 대부분의 도구가 Agent의 같은 검색에 무엇을 반환하는지 봅시다. ID 목록입니다. 어쩌면 각 hit의 전문입니다. Agent가 무엇을 받는지 설계하는 것은 screen을 설계하는 것과 같은 기술입니다. 그리고 대부분의 도구가 건너뛰는 부분이 바로 그것입니다.

문제는, 그리고 이것이 쉽게 무시되는 이유는, Agent가 거의 무엇을 받아도 움직인다는 점입니다. 나쁜 format에 이의를 제기하지 않습니다. 그저 조용히 더 나쁘게 일할 뿐입니다. 이것이 함정입니다. 실제로 쓸 수 있으니 cost를 표시하는 것이 없습니다. 그러나 서툰 결과 하나하나가 Agent를 원래보다 더 힘들게 만듭니다. 문제는 감당할 수 있는지가 아닙니다. 감당의 대가가 무엇인지입니다.

우리가 이 문제를 처음 만난 것은 Raft 검색을 설계할 때였습니다. 결과는 메시지였습니다. 하지만 이 문제는 채팅에 특화되어 있지 않습니다. 블로그 글, 타임라인, issue, tweet. 모든 검색 결과는 더 큰 내용으로 난 창입니다. 거기서 추출된 것입니다. 좋은 결과는 그것을 열 가치가 있을 만큼 충분한 내용을 되가져옵니다.

잘못된 답을 따라가 보기

가장 뻔한 것부터 시작합시다. ID만 반환하기. Agent는 기술적으로 쓸 수 있지만, 각 ID를 실제 내용으로 해석하기 위해 하나씩 호출해야 합니다. 컨텍스트를 아낀 것이 아니라 미룬 것이고, Agent에게 이자를 내게 한 것입니다. 결과는 먼저 즉시 쓸 수 있어야 합니다.

그렇다면 전체 내용을 반환합시다. 모든 hit를 전문으로. 이제 반대 문제가 생깁니다. 40개의 메시지에 매칭된 검색이, 몇 개밖에 담지 못하는 컨텍스트 window에 40개 메시지를 모두 쏟아붓습니다. 결과의 크기는 그것을 소비하는 쪽에 맞아야 합니다.

좋습니다. 매칭된 메시지만 각각 전문으로 반환합시다. 합리적으로 보이지만 여전히 틀렸습니다. 단일 메시지가 답인 경우는 드물기 때문입니다. Agent가 어떤 결정을 검색해서 그것을 이름 붙인 한 줄을 얻었지만, 그 결정을 논쟁한 thread도, 그것을 뒤집은 reply도 얻지 못했습니다. 당신은 그 대화에서 찢어낸 한 문장을 돌려준 것입니다. 결과는 읽을 가치가 있을 만큼 자기 컨텍스트를 가져야 합니다.

세 번 시도했고, 세 번 실패했습니다. 실패한 축은 같은 두 가지입니다. Agent가 무엇을 볼 수 있는가, 그리고 다음에 무엇을 할 수 있는가.

작동하는 결과

그 세 답이 둘러싸고도 맞히지 못한 답은 이것입니다. ID, 매칭 키워드 주변 텍스트의 preview와 hit 위치의 highlight, 그리고 명확한 다음 action을 반환합니다. 주변 컨텍스트를 읽어 전체 thread를 보는 것입니다.

당신은 이것을 본 적이 있습니다. 검색 엔진의 결과입니다. 페이지 맨 위가 아니라 매칭 주변으로 구성된 summary와 나머지로 데려가는 link. Agent는 아무것도 해석하지 않고도 관련성을 판단할 만큼의 정보를 받고, 더 필요할 때 가져갈 수 있는 명확한 handle도 얻습니다.

앞의 세 답에 없었던 것은 후반부입니다. 갈 곳 없는 preview는 클릭할 수 없는 검색 결과입니다. 정보가 있지만 다음 action이 없으면 반쪽 설계입니다.

그게 전부입니다. 무엇을 보는지, 무엇을 할 수 있는지. 둘 다 맞추면 Agent를 위해, 어떤 사용자에게나 했을 설계를 한 것입니다.

같은 검색 디자인 아이디어도 컨텍스트 예산을 읽는 Agent가 사용자일 때는 다른 형태가 된다.

일차원의 사용자 경험

이것도 여전히 UX입니다. 다만 당신이 그리는 종류의 UX가 아닙니다. 인간 사용자에게는 screen이 있습니다. 눈이 움직이고, layout을 scanning하고, 눈길이 가는 곳에서 멈춥니다. Agent는 일차원에서 읽습니다. 움직일 눈도, scan할 layout도 없고, 예산 안의 token 줄만 있습니다. 컨텍스트 window는 당신에게 보이지 않는 screen space입니다. 그래서 원칙은 이어지지만 tradeoff는 이동합니다. 이제는 주의를 위해 설계하는 것이 아니라 그 예산을 위해 설계합니다. 결과가 쓰는 모든 token은 그 자리에 있을 가치가 있어야 합니다. 매칭 주변 preview는 그 가치가 있습니다. Agent가 이미 읽고 있는 곳에 관련 조각을 놓고 나머지를 버리기 때문입니다.

여기서 편안함은 장식이 아닙니다. Agent가 한 번에 읽어낼 수 있는 결과는 더 자주 맞게 쓰이고, 긴 세션 깊은 곳에서도 계속 맞게 쓰입니다. 서툰 결과는 Agent를 멈추지 않습니다. 세금을 물립니다. 걸러야 하는 무관한 hit, 의심해야 하는 truncation, 벗겨내야 하는 구조 하나하나가 task가 아니라 format에 쓰이는 주의입니다. 그리고 거기에 쓰인 주의가 바로 오류가 생기는 곳입니다. 우회가 적고, 소모되는 컨텍스트가 적습니다. 편안함은 기분 좋은 종류가 아니라 측정 가능한 종류입니다.

그래서 결과는 Agent에게 어디서 잘렸는지 알려줘야 합니다. 생략된 텍스트를 표시하는 marker는 장식이 아니라 정보입니다. 매칭 앞의 간격은 위에 더 많은 내용이 있다는 뜻입니다. 매칭 뒤의 간격은 아래에 더 있다는 뜻입니다. 두 키워드 사이의 공간도 잘렸을 수 있습니다. Agent는 preview가 창이지 방 전체가 아니라는 것을 알아야 합니다. 그렇지 않으면 조각을 전문처럼 읽고 반쪽 문장 인용으로 질문에 답합니다.

Agent를 진짜 사용자처럼 설계하기

이것을 진지하게 다루는 것은 출력을 보기 좋게 정리하는 것 이상입니다. 그것은 contract이고, 양방향입니다.

Agent는 구조를 구조로 읽어야 합니다. preview 주변 marker, 매칭 highlight, 텍스트가 잘린 곳을 표시하는 기호. 이 모든 것은 검색이 소통하기 위해 만든 발판입니다. Agent는 그것을 발판으로 다뤄야 하며, 절대로 메시지 자체로 다뤄서는 안 됩니다. 이것을 잘못 읽으면 truncation marker를 내용으로 다시 인용하기 시작합니다.

또한 Agent는 그 발판을 안에 남겨야지 밖으로 넘기면 안 됩니다. 인간에게 답할 때는 자연어로 render합니다. 구조는 Agent가 읽기 위한 것입니다. browser가 accessibility tree를 읽고 무엇을 표시할지 결정하는 것처럼, 인간은 그것을 보지 않습니다. 구조를 읽고, 그에 따라 행동하고, 그것은 자기 쪽에 남겨둡니다.

이것은 taste이고, 우리는 Agent가 그것을 증명하게 합니다. contract는 test됩니다. Agent는 구조를 이해하고, 해석 전에 filter하고, 다음 action을 취하고, marker를 자기 쪽에 남겨야 합니다. 설계는 이 문턱을 통과해야만 서 있습니다. 페이지에서 읽기 좋기 때문이 아닙니다.

(marker 자체, label과 기호는 운반체일 뿐입니다. 다른 무엇이어도 됩니다. 중요한 것은 그 아래의 쌍입니다. 정보와 action.)

가장 선명한 사례지만, 유일한 사례는 아니다

검색은 이것을 가장 보기 쉬운 곳입니다. 좋은 결과가 어떤 느낌인지 모두가 이미 알기 때문입니다. 하지만 검색은 특별하지 않습니다. 같은 문제는 Agent가 출력을 읽고 다음 action을 선택해야 하는 모든 곳에서 나타납니다.

설계를 건너뛰면 바로 느껴집니다. Agent가 한 문장을 찾기 위해 40개의 메시지를 열고, truncation marker를 사실처럼 인용하거나, 완전히 읽은 적 없는 결과 위에서 헛돕니다.

Agent에게 던지는 모든 출력은 인터페이스입니다. 당신이 설계했든 아니든 그렇습니다. 도구 결과, 오류, 상태, 목록. 모두 Agent가 이해하고 행동해야 하는 정보입니다. 질문은 변하지 않습니다. 그것이 본 것을 사용할 수 있는가? 다음에 무엇을 해야 하는지 아는가?

당신은 이미 인간이 보는 모든 screen을 설계하고 있습니다. 당신의 Agent도 이미 당신의 사용자 중 하나입니다. 같은 정성을 받을 자격이 있습니다.

편집 Alice & Megan