MCP 앱: 모델에 데이터, 사용자에게 UI — Indeed

URL: https://www.youtube.com/watch?v=lbaXnx0KLA8 날짜: 2026-09-10 채널: AI Engineer (aiDotEngineer) 원본 게시일: 2026-09-09 재생 시간: 15분 34초

📌 핵심 질문 / 이 발표가 다루는 핵심 논점

==MCP 앱의 품질은 UI를 얼마나 예쁘게 붙였는지가 아니라 모델이 다룰 데이터를 얼마나 잘 설계하고, 그 데이터 탐색 결과에 맞춰 UI를 선택적으로 렌더링하는지로 결정된다.==

• 사용자에게 보이는 모든 정보는 모델에도 구조화된 데이터로 제공해야 한다.
• 도구 설명에는 UI가 자동으로 표시된다는 사실을 명시해 모델의 중복 텍스트 출력을 줄여야 한다.
• 데이터 처리와 UI 렌더링을 분리해야 모델이 여러 번 검색하고 필터링한 뒤 필요한 결과만 렌더링할 수 있다.

Indeed의 채용 검색과 Career Scout를 비롯한 MCP 앱 구현 경험은 대화형 호스트 안에서 브랜딩·링크·상호작용을 보존하면서도 모델의 탐색 능력을 약화시키지 않는 설계 원칙을 제시한다. 모델을 단순 API 호출기로 취급하지 말고, 탐색할 데이터와 렌더링을 호출할 시점을 판단하는 주체로 설계해야 한다.

1. Indeed의 MCP 앱이 해결하려는 문제

Indeed의 AI 플랫폼·가드레일 경험은 채용 검색을 대화형 제품 안으로 가져오면서 발생하는 실제 제약을 드러낸다.

1.1. 발표자와 적용 범위

1. Indeed의 제품 맥락

   1. Indeed는 세계 1위 채용 검색 사이트이며, 채용 검색 서비스를 만든다.
   2. Dustin Mihalik은 AI 플랫폼 팀에서 AI 안전장치(AI safeguards), 게이트웨이(gateways), 컴플라이언스(compliance)를 담당한다.
   3. 벤더와의 파트너십을 통해 MCP 프로그램과 MCP 커넥터 같은 실험적 프로젝트를 진행한다.

2. 실전 사례의 범위

   1. Claude, ChatGPT, Indeed 내부 구직 에이전트인 Career Scout를 위한 MCP와 MCP 앱을 구축하며 얻은 교훈을 다룬다.
   2. 화면 예시는 대부분 채용 검색이며, 채팅 기반 인터페이스에서 구직자가 결과를 탐색하는 흐름을 기준으로 삼는다.
   3. 발표 시작 시 감기에서 회복 중이라 목소리가 좋지 않다고 양해를 구하고, 발표가 끝난 뒤 별도 부스 없이 복도에 머물며 질문을 받겠다고 안내한다.

1.2. 텍스트 응답만으로는 부족한 이유

1. Austin 바리스타 검색의 장점과 한계

   1. “Austin의 바리스타 일자리”를 검색하면 Claude가 Austin과 교외의 채용 공고를 텍스트 목록으로 반환하며, 기본 검색 자체는 꽤 잘 작동한다.
   2. 텍스트 목록에는 Indeed 브랜딩이 없고, 호스트 모델이 결과를 단순 목록으로 재구성하므로 회사가 어떤 정보를 강조할지 통제하기 어렵다.

2. 외부 링크를 보존하기 어려운 호스트 환경

   1. Claude나 ChatGPT는 사용자가 호스트 환경을 떠나는 것을 원하지 않기 때문에 외부 링크를 일관되게 붙이지 않는다.
   2. 인터넷에서 찾은 채용 공고 5개를 보여주면서 링크를 하나도 제공하지 않으면 사용자는 실제 공고로 이동할 수 없어 경험이 크게 나빠진다.
   3. Claude가 매번 링크를 붙이도록 만들기 위해 Indeed는 상당한 시간과 평가(evaluation)·검증 과정을 투입했다.

3. MCP 앱이 제공하는 제품 제어

   1. MCP 앱과 SDK를 사용하면 회사가 지원(Apply) 버튼을 넣을지 결정할 수 있다.
   2. 상단에 어떤 핵심 정보를 강조할지 직접 정할 수 있다.
   3. 자세히 보기(View details) 링크를 누르면 팝업 또는 모달에서 채용 공고의 전체 세부 정보를 보여주므로 사용자가 대화 환경을 떠나지 않아도 된다.
   4. 채용 서비스는 브랜딩·전환 흐름을 보존하고, 호스트는 사용자를 외부 페이지로 내보내지 않으면서 유용한 정보를 제공하므로 양쪽 모두에 이익이 된다.

2. 규칙 1: 사용자에게 보여주는 모든 것을 모델에도 데이터로 제공하라

화면에만 존재하는 정보는 모델에게 블랙 박스가 되며, 후속 질문과 추론을 끊는다.

2.1. 단순 API 호출이 만드는 블랙 박스

1. 데이터와 표시의 단절

   1. 기존 API를 호출해 데이터를 로드하고 HTML만 화면에 주입하는 방식은 구현하기 쉽지만, 모델은 어떤 결과가 실제로 표시됐는지 알지 못한다.
   2. 사용자가 “첫 번째 결과를 알려줘” 또는 “이 회사 목록의 순위를 매겨줘”라고 물어도 모델은 화면 속 항목·순서·선택 상태를 확인할 수 없다.

2. 후속 질문의 실패 원인

   1. 모델은 도구를 호출해 “무언가를 보여줬다”는 사실만 알고, 그 무언가의 내용은 알지 못한다.
   2. 화면에 출력된 정보와 모델 컨텍스트의 정보가 다르면 모델은 질문을 회피하거나, 이미 표시된 내용을 다시 추측해 설명한다.
   3. 사용자에게는 결과가 보이는데 모델에게는 거대한 빈 상자만 남는 구조가 후속 작업을 망친다.

2.2. 구조화된 콘텐츠와 리소스 URI의 동기화

1. 두 가지 반환값

   1. 구조화된 콘텐츠(structured content)는 텍스트 전용 MCP를 사용할 때 이미 모델에 반환하던 데이터다.
   2. 리소스 URI(resource URI)는 HTML이 저장된 위치를 가리키며, MCP 앱이 사용자에게 렌더링할 화면을 연결한다.
   3. MCP 사양과 MCP 앱 사양은 구조화된 콘텐츠와 HTML 리소스 URI를 함께 반환하는 방식을 지원한다.

2. 동기화 불변식

   1. 사용자 화면에 새 항목을 추가하면 같은 항목을 모델에 반환하는 구조화된 데이터에도 추가해야 한다.
   2. API가 바뀔 때 UI만 수정하거나 모델 데이터만 수정하면 두 표현이 다시 어긋나므로, API·구조화 데이터·HTML 렌더링을 하나의 변경 단위로 관리해야 한다.
   3. 핵심 불변식은 “사용자에게 보이는 모든 정보가 모델이 사용할 수 있는 정보이기도 해야 한다”는 것이다.

3. 규칙 2: 도구 설명에 UI의 존재를 명시하라

모델이 데이터를 받았다는 사실만으로는 충분하지 않으며, 그 데이터를 MCP 앱이 사용자에게 자동으로 보여준다는 사용법까지 도구 설명에 적어야 한다.

3.1. 모델의 기본 텍스트 출력과 UI의 충돌

1. UI를 모르는 모델의 습관

   1. 모델은 데이터를 받으면 평소처럼 결과를 설명하고, 목록·간단한 개요·링크를 텍스트로 다시 출력하려 한다.
   2. 그러면 화면에는 이미 예쁜 결과 목록이 있는데 대화 아래에 같은 결과가 중복되어 표시된다.

2. 도구 설명을 통한 방향 전환

   1. 도구 설명을 “이 결과는 MCP 앱에서 표시된다”는 내용으로 갱신하면 모델은 결과 자체를 장황하게 나열하는 대신 짧은 개요와 UI를 우선한다.
   2. “결과는 사용자에게 UI 구성 요소로 자동 표시된다” 같은 간단한 문장을 도구 설명 맨 앞에 넣으면 UI와 모델의 텍스트 출력 사이에서 생기는 대부분의 충돌을 줄일 수 있다.
   3. 데이터와 API 접근을 함께 제공하는 순간, 모델이 무엇을 렌더링하는지와 어떤 부분을 텍스트로 남길지를 설명으로 조정해야 한다.

4. 상호작용도 모델 컨텍스트로 되돌려 보내라

정적인 결과를 동기화한 뒤에는 사용자의 클릭·선택·열람 상태도 모델이 알아야 후속 작업을 수행할 수 있다.

4.1. 버튼 클릭 뒤에 생기는 보이지 않는 상태

1. 채용 공고 모달의 예시

   1. 사용자가 지원 버튼을 누르거나 자세히 보기 버튼을 누르면 전체 채용 공고가 큰 모달 창으로 열린다.
   2. 사용자는 열린 공고를 바탕으로 자기소개서를 써달라거나 공고를 빠르게 검토해달라고 요청할 수 있다.

2. 모델이 알 수 없는 선택

   1. 10개의 공고가 API나 동적 로딩으로 화면에 들어온 뒤 사용자가 하나를 클릭해도, 모델은 그 10개 중 어느 공고가 선택됐는지 자동으로 알지 못한다.
   2. 따라서 화면에 표시된 모든 정보뿐 아니라 사용자가 어떤 항목을 클릭했고 어떤 상호작용을 수행했는지도 모델에게 전달해야 한다.

4.2. update model context 메서드

1. 상호작용 전달 방식

   1. MCP 앱에는 update model context 메서드가 있으며, 문자열 하나를 모델 컨텍스트에 전달할 수 있다.
   2. 선택된 채용 공고 ID나 사용자가 연 화면을 문자열로 기록하면 모델은 다음 질문의 대상이 무엇인지 파악할 수 있다.
   3. 시간이 지나며 여러 이벤트를 추적하려면 하나의 문자열에 이벤트 항목을 계속 추가해야 한다.

2. 쇼핑 카트 비유

   1. MCP 앱 문서의 쇼핑 카트 예시는 카트의 항목과 총비용을 합산하고, 사용자가 “내 카트에 담긴 물건들에 대해 알려줘”라고 물을 수 있게 한다.
   2. 카트 상태와 합계가 모델 컨텍스트에 들어가므로 모델은 화면을 직접 보지 않아도 현재 상태를 설명할 수 있다.
   3. 이 방식은 모델이 앱의 상태를 파악하게 하지만, 모델의 복잡한 탐색 능력을 온전히 활용하는 좋은 MCP 앱을 만들려면 추가 설계가 필요하다.

5. 규칙 3: 데이터 처리와 UI 렌더링을 분리하라

UI를 붙이면 모델의 탐색 횟수가 줄어들 수 있으므로, 모델이 데이터를 충분히 검색·필터링한 뒤 선택적으로 렌더링하게 만들어야 한다.

5.1. UI가 복잡한 구직 탐색을 망치는 방식

1. 어려운 문제를 맡기는 이유

   1. 단 한 번의 검색만 필요하면 사용자가 직접 웹사이트에 들어가 검색하는 편이 빠르다.
   2. Claude에게 맡길 가치는 여러 번의 검색, 조건 조합, 비교와 선별처럼 사람이 반복하기 귀찮은 복잡한 작업에 있다.

2. 다중 조건 구직 시나리오

   1. 직함을 정해 검색하고, 이사를 고려해 여러 도시를 동시에 탐색한다.
   2. 가장 높은 급여를 주는 선택지를 찾은 뒤 그중 최고 몇 개만 고른다.
   3. 절대로 일하고 싶지 않은 특정 산업을 제외한다.
   4. Sonata 5가 아직 출시되지 않았다는 농담 섞인 언급처럼 일부 화면은 이틀 전의 스크린샷이라는 시간적 맥락도 가진다.

3. 텍스트 MCP의 강점

   1. 텍스트 기반 MCP에서 Claude는 10번 또는 15번의 검색과 쿼리를 수행할 수 있다.
   2. 개별 결과를 필터링하고 추출한 뒤 마지막에 보기 좋은 표를 조립하므로, 여러 조건을 한 번에 다루는 데 적합하다.

4. 렌더링이 탐색을 조기에 끝내는 문제

   1. 검색 도구가 호출될 때마다 UI에 결과가 표시된다고 지정하면 Claude는 첫 호출 뒤 “결과가 이미 화면에 표시됐으니 더 깊이 파고들 필요가 없다”고 판단할 수 있다.
   2. 사용자는 10개의 캐러셀(carousel)을 보고 싶어 하지 않으며, Claude도 이미 화면에 무언가 표시됐다는 신호를 보고 추가 캐러셀 호출을 하지 않는다.
   3. 결과가 보기 좋아졌지만 모델의 반복 검색·필터링·비교 능력이 사라져, 단순 검색보다 어려운 작업을 맡긴 목적이 훼손된다.

5.2. 검색 도구와 렌더링 도구의 분리

1. 표준 텍스트 검색 도구

   1. 구인 검색 기능은 UI를 반환하지 않는 표준 텍스트 기반 MCP 도구로 둔다.
   2. Claude는 이 검색 도구를 원하는 만큼 여러 번 호출해 100개의 관심 공고를 수집하고, 급여·도시·직함·제외 산업 같은 조건으로 필터링할 수 있다.

2. ID 기반 렌더링 위젯

   1. 별도의 렌더링 위젯은 전체 검색 결과가 아니라 선택된 채용 공고 ID 목록을 입력으로 받는다.
   2. 모델이 100개의 결과에서 5개를 추려 ID 목록으로 넘기면 위젯은 그 5개만 사용자에게 보여준다.
   3. 렌더링 도구 설명에는 데이터가 어디에서 오는지, 어떤 형식이어야 하는지, 렌더링 전에 검색 도구 중 하나를 먼저 호출해야 하는지를 명시한다.
   4. “렌더링에 사용할 데이터를 얻으려면 항상 이 세 가지 도구 중 하나를 먼저 호출하라”는 식의 설명만으로도 데이터 흐름을 모델에게 알릴 수 있다.

3. 분리의 일반화

   1. 전자상거래에서는 모델이 여러 상품을 탐색하고 비교한 뒤 선택한 항목만 상품 UI로 렌더링하게 할 수 있다.
   2. 지도 앱에서는 모델이 서로 다른 주소 5개를 찾고, 그 주소만 지도 위젯에 전달하게 할 수 있다.
   3. 어떤 산업이든 “모델이 먼저 탐색할 데이터”와 “사용자가 볼 때 도움이 되는 표시 방식” 사이의 경계를 찾아야 한다.

6. 렌더링 도구에 모델의 판단을 실어라

분리된 UI는 단순히 선택된 결과를 예쁘게 보여주는 데서 끝나지 않고, 모델이 선택한 이유와 중요한 부분까지 전달할 수 있다.

6.1. 선택 이유와 강조점의 활용

1. 추천 근거 보존

   1. 텍스트 기반 작업에서 모델은 특정 항목을 왜 골랐는지, 왜 성공 가능성이 높은지 설명할 수 있다.
   2. 렌더링 위젯이 ID와 함께 “이 결과가 왜 적합한지”를 전달받으면 사용자는 모델의 선별 기준을 UI 안에서 확인할 수 있다.

2. 부분 강조와 창의적 UI

   1. ID와 함께 채용 공고에서 특히 좋은 부분을 알려달라고 요청해 급여·기술 요건·경력 적합성 같은 문장을 강조할 수 있다.
   2. 모델이 추가한 선택 이유나 강조점을 카드·목록·하이라이트로 렌더링하면 단순 결과 목록보다 나은 사용자 경험을 만들 수 있다.
   3. 모델의 탐색과 판단을 UI의 입력으로 삼으면 시각화 도구가 고정된 장식이 아니라 모델의 reasoning을 사용자에게 전달하는 인터페이스가 된다.

7. 핵심 결론과 설계 시사점

1. 데이터 우선 설계: “ChatGPT에 UI를 어떻게 넣을까?”에서 출발하지 말고 “모델이 어떤 데이터를 다루게 할까?”를 먼저 결정해야 한다.
2. 렌더링의 위치: UI 렌더링은 독립적인 목표가 아니라 모델이 데이터를 탐색한 결과로 선택되는 부수 효과여야 한다.
3. 상태의 완전한 전달: 화면의 구조화 데이터와 클릭·선택 이벤트를 모두 모델 컨텍스트에 보내야 후속 질문과 작업이 이어진다.
4. 작고 조합 가능한 도구: 채용 검색 방식이 두세 가지라면 두세 개의 검색 도구를 만들고, 목록 렌더링 도구 하나와 특정 공고 렌더링 도구 하나를 조합할 수 있다.
5. 단순한 설명과 유연성: 각 도구 설명은 모델을 과부하시키지 않도록 단순하게 유지하면서, 모델이 데이터를 탐색하고 필요한 렌더링을 선택할 여지를 남겨야 한다.
6. 제품 경험의 균형: 브랜딩·지원 버튼·모달·외부 링크 제어는 회사와 사용자에게 가치를 주지만, 모델의 탐색을 한 번의 UI 호출로 제한해서는 안 된다.
7. 현장 적용: Dustin Mihalik은 발표 후 복도에서 질문을 받겠다고 했으며, 소셜 플랫폼에서 성 또는 이름의 첫 글자와 성을 조합한 아이디를 사용한다고 안내했다.

주요 발언 모음

“사용자에게 보여주는 모든 내용은 모델에게도 데이터로 제공해야 한다.”

“데이터 처리와 UI 렌더링을 분리하라.”

“UI에 집중하기 전에 데이터에 먼저 집중해야 한다.”

“모델이 어떤 데이터를 다룰 수 있게 할 것인가를 먼저 살펴봐야 한다. 렌더링은 그 과정의 부수적 효과이거나 모델이 데이터를 탐색한 결과로 나타난다.”

“작고 조합 가능한 도구가 중요하다.”

핵심 데이터 & 수치

• 15분 34초: 발표 전체 재생 시간이다.
• 5개 공고: 링크 없이 채용 결과 5개만 보여주면 사용자가 원문으로 갈 수 없어 나쁜 경험이 된다.
• 10개 공고: 동적으로 로드된 10개 중 사용자가 클릭한 항목을 모델이 자동으로 알 수 없으므로 선택 이벤트 전달이 필요하다.
• 10~15회 검색: 텍스트 기반 MCP에서 Claude가 복잡한 구직 조건을 처리하며 실행할 수 있는 검색·쿼리 횟수다.
• 100개에서 5개: 모델이 100개의 관심 공고를 검색·필터링한 뒤 선택한 5개의 ID만 렌더링 위젯에 넘기는 구조다.
• 2~3개 검색 도구: 여러 방식의 채용 검색을 작은 도구로 나누는 권장 규모다.
• 1~2개 렌더링 도구: 목록 렌더링 하나와 특정 공고 강조·상세 렌더링 하나를 조합할 수 있다.
• 3가지 도구 중 하나 선행 호출: 렌더링에 필요한 데이터를 얻기 위해 모델이 먼저 검색 도구를 호출하도록 설명할 수 있다.

결론 및 시사점

1. MCP 앱의 본질은 대화창에 UI를 추가하는 것이 아니라 모델과 사용자가 같은 데이터 상태를 공유하도록 만드는 데 있다.
2. structured content와 resource URI를 함께 반환하고 동기화하면 화면과 모델 사이의 블랙 박스를 제거할 수 있다.
3. 도구 설명에 자동 UI 표시를 명시하면 모델의 중복 텍스트 출력을 줄일 수 있다.
4. update model context로 사용자의 클릭과 선택을 전달하면 모달·카드·장바구니 같은 동적 상태도 후속 대화의 재료가 된다.
5. 가장 중요한 설계는 데이터 처리와 렌더링의 분리이며, 이를 통해 모델이 충분히 탐색한 뒤 사용자가 필요한 결과만 볼 수 있다.
6. 검색·필터링·선택 이유·강조점을 작은 조합형 도구로 나누면 모델의 자율성과 제품의 시각적 품질을 동시에 확보할 수 있다.

핵심 요약 (20줄)

1. Indeed의 Dustin Mihalik은 AI 플랫폼·가드레일 팀에서 MCP 앱과 커넥터를 구축하며 얻은 실전 교훈을 공유한다.
2. Claude의 Austin 바리스타 검색은 유용하지만 Indeed 브랜딩과 원문 링크가 보이지 않아 제품 경험을 통제하기 어렵다.
3. Claude와 ChatGPT가 사용자를 호스트 환경 밖으로 보내기 싫어해 외부 링크를 일관되게 제공하지 않는 문제가 발생한다.
4. MCP 앱은 지원 버튼과 자세히 보기 모달을 제공해 사용자가 대화 환경을 떠나지 않고 채용 정보를 확인하게 한다.
5. API 결과를 HTML로만 주입하면 모델은 화면에 무엇이 표시됐는지 모르는 블랙 박스와 마주한다.
6. 사용자가 첫 결과 설명이나 회사 순위 지정을 요청해도 모델이 화면 데이터를 모르면 후속 질문을 제대로 처리할 수 없다.
7. 사용자에게 보이는 모든 내용은 모델에도 구조화된 데이터로 전달해야 한다.
8. 구조화된 콘텐츠와 HTML 리소스 URI를 함께 반환하고 API 변경 때 두 표현을 동기화해야 한다.
9. 모델은 데이터를 받아도 평소처럼 텍스트 목록을 재출력하므로 도구 설명에 UI 자동 표시 사실을 명시해야 한다.
10. “결과가 UI 구성 요소로 자동 표시된다”는 문장을 설명 앞부분에 넣으면 텍스트와 UI의 중복이 줄어든다.
11. 사용자가 10개 채용 공고 중 하나를 클릭해도 모델은 선택 항목을 알 수 없으므로 상호작용 상태를 컨텍스트로 보내야 한다.
12. MCP 앱의 update model context 메서드는 선택된 ID와 이벤트를 문자열로 전달하는 간단한 수단이다.
13. 단순 검색보다 여러 도시·급여·제외 산업을 조합하는 복잡한 탐색이 모델을 사용하는 핵심 이유다.
14. 텍스트 MCP의 Claude는 10~15회 검색하고 필터링한 뒤 최종 표를 만들어 복잡한 구직 요청을 처리할 수 있다.
15. 검색 결과를 매번 UI에 렌더링하면 Claude가 첫 호출 후 탐색을 중단하고 사용자는 여러 캐러셀을 보게 된다.
16. 데이터 처리와 UI 렌더링을 분리하면 모델은 100개 공고를 탐색한 뒤 선택한 5개만 위젯에 넘길 수 있다.
17. 렌더링 도구 설명에는 데이터 출처·형식과 선행 검색 도구 호출 조건을 명시해야 한다.
18. 전자상거래 상품이나 지도 주소도 모델이 탐색한 뒤 선택된 항목만 시각화하는 방식으로 일반화할 수 있다.
19. 렌더링 위젯은 결과 ID뿐 아니라 모델이 선택한 이유와 강조할 문장까지 받아 더 풍부한 경험을 만들 수 있다.
20. MCP 앱은 UI보다 데이터를 먼저 설계하고 작고 조합 가능한 도구로 탐색과 렌더링을 분리해야 한다.