대화형 UX와 앱 발견성 설계

UX의 출발점은 화면이 아니라 의도다

ChatGPT 앱을 설계할 때 가장 먼저 버려야 할 생각은 "사용자를 우리 화면으로 데려오자"는 방식이다. 일반 웹앱에서는 홈 화면, 메뉴, 검색창, 상세 페이지가 경험의 중심이다. 하지만 ChatGPT 앱에서는 사용자의 말과 대화 맥락이 진입점이다.

사용자는 "호텔 앱 열어줘"라고 말할 수도 있지만, 더 자주 이렇게 말한다.

"다음 주 금요일 부산에서 묵을 만한 숙소 찾아줘."
"이 장바구니에서 배송비 줄일 방법 있어?"
"이 동네에서 아이랑 갈 만한 식당 예약해줘."

이때 좋은 앱은 자기 존재를 과하게 드러내지 않는다. 사용자의 목적을 이해하고, 필요한 순간에만 적절한 도구와 UI를 제공한다. OpenAI의 Apps SDK UX 원칙도 ChatGPT 앱의 목표를 "ChatGPT 안에서 자연스럽고 집중된 대화형 경험을 제공하는 것"으로 설명한다.¹ 결국 ChatGPT 앱 UX는 탐색 경로를 설계하는 일이 아니라, 의도 → 호출 → 확인 → 실행 → 요약의 흐름을 설계하는 일이다.

명시적 호출과 암묵적 발견을 함께 설계하기

ChatGPT 앱은 크게 두 방식으로 발견된다.

첫째는 명시적 호출이다. 사용자가 앱 이름을 직접 부른다.

"TravelMate로 제주도 숙소 찾아줘."
"우리 쇼핑 앱에서 지난번 주문 상태 확인해줘."

이 경우 앱 이름, 브랜드명, 대표 기능이 분명해야 한다. 사용자가 기억하기 어려운 이름이거나 기능이 너무 넓게 설명되어 있으면 호출이 줄어든다. "여행을 도와주는 앱"보다 "항공권·숙소·일정 후보를 비교하는 여행 계획 앱"이 낫다.

둘째는 암묵적 발견이다. 사용자가 앱 이름을 말하지 않아도, 모델이 대화 맥락을 보고 관련 앱을 제안하거나 호출한다. 예를 들어 사용자가 "예산 30만 원으로 서울 근교 1박 여행을 짜줘"라고 말하면, 숙소 조회 앱이나 지도 앱이 후보가 될 수 있다. Apps SDK 예제 저장소도 ChatGPT 앱이 대화 중 관련 요청을 통해 호출될 수 있음을 보여준다.²

암묵적 발견을 설계할 때는 "모델이 언제 이 앱을 써야 하는가"를 명확히 알려야 한다. 여기서 중요한 단서는 앱 설명, 도구 이름, 도구 설명, 입력 스키마, 결과 문구다. 이 정보는 사용자를 위한 문구이면서 동시에 모델을 위한 안내문이다.

나쁜 설명은 넓고 추상적이다.

"사용자의 쇼핑 경험을 향상합니다."

좋은 설명은 과업과 제약을 드러낸다.

"사용자의 장바구니 상품, 배송비, 쿠폰 적용 가능 여부를 조회하고 결제 전 주문 요약을 생성합니다. 결제 실행은 사용자의 명시적 확인 후에만 수행합니다."

이렇게 쓰면 모델은 이 앱이 상품 추천, 재고 조회, 쿠폰 적용, 주문 확인에 적합하다는 것을 이해한다. 반대로 의료 진단, 법률 판단, 무관한 일반 상담에는 쓰지 말아야 한다는 경계도 생긴다.

모델이 이해하는 도구 설명 작성하기

도구 설명은 마케팅 문구가 아니다. 모델이 호출 여부를 판단하는 계약서에 가깝다. 따라서 세 가지를 분명히 적어야 한다.

첫째, 해결하는 사용자 과업이다. "일정을 관리합니다"보다 "사용자의 캘린더에서 가능한 시간을 조회하고 회의 후보 시간을 제안합니다"가 낫다.

둘째, 필요한 입력이다. 위치, 날짜, 인원, 예산, 상품 ID, 계정 연결 여부처럼 실행에 필요한 정보를 구체적으로 드러낸다. 입력이 빠졌을 때는 바로 실패하지 말고, 대화로 추가 질문을 하도록 설계한다.

셋째, 하지 않는 일이다. "결제는 수행하지 않음", "예약 가능 여부만 조회", "사용자 확인 전 외부 서비스에 변경 사항을 저장하지 않음" 같은 문장은 부적절한 호출을 줄인다.

예를 들어 레스토랑 예약 앱의 도구 설명은 다음처럼 설계할 수 있다.

사용자의 지역, 날짜, 시간, 인원, 선호 음식 종류를 바탕으로 예약 가능한 식당 후보를 조회한다. 예약 확정은 사용자가 특정 식당과 시간을 선택하고 확인한 뒤에만 수행한다.

이 설명은 모델에게 두 가지를 알려준다. 후보 조회는 비교적 가볍게 호출해도 되지만, 예약 확정은 별도 확인 단계가 필요하다는 점이다. 이런 차이가 UX의 신뢰를 만든다.

UI는 대화를 보조해야 한다

Apps SDK UI는 ChatGPT 안에서 실행되는 보조 인터페이스다. 사용자를 완전히 다른 제품 안으로 데려가는 별도 세계가 아니다. 따라서 UI가 해야 할 일과 대화가 해야 할 일을 나눠야 한다.

대화가 잘하는 일은 의도 파악, 조건 정리, 후속 질문, 요약이다. UI가 잘하는 일은 비교, 선택, 수정, 시각적 확인이다. 예를 들어 숙소 검색 앱에서 "아이와 함께 갈 예정이고 수영장이 있으면 좋겠다"는 조건 파악은 대화가 잘한다. 반면 여러 숙소의 가격, 위치, 평점, 사진을 비교하는 일은 카드나 목록 UI가 더 적합하다.

표시 형태도 과업 복잡도에 맞춰 선택해야 한다.

• 인라인 카드: 주문 요약, 배송 상태, 예약 후보처럼 한눈에 확인하고 하나의 행동을 하는 경우에 적합하다.

• 전체 화면: 지도 탐색, 복잡한 필터 조정, 여러 항목 비교처럼 화면 공간이 필요한 경우에 적합하다.

• PiP: 타이머, 실시간 세션, 게임, 라이브 추적처럼 대화와 병행되어야 하는 경우에 적합하다.

중요한 원칙은 "기능이 많으니 전체 화면"이 아니라 "사용자가 지금 비교·조작해야 하는 정보가 많은가"이다. 버튼, 탭, 폼을 많이 넣으면 익숙한 웹앱처럼 보일 수는 있다. 그러나 ChatGPT 안에서는 대화 흐름을 방해할 가능성이 크다. 한 화면에는 하나의 주된 목적을 두고, 나머지는 대화로 넘기는 편이 낫다.

UI 행동은 다시 대화로 돌아와야 한다

ChatGPT 앱의 상호작용은 UI에서 끝나면 안 된다. 사용자가 카드에서 항목을 선택하거나, 폼에서 조건을 수정하거나, 버튼으로 실행을 확정했다면 그 결과가 대화에 다시 반영되어야 한다.

예를 들어 사용자가 숙소 후보 중 하나를 선택했다면 assistant 응답은 이렇게 이어져야 한다.

"선택한 숙소는 해운대 근처의 2인실이며, 5월 24일 1박 기준 총 168,000원입니다. 무료 취소는 5월 22일 18시까지 가능합니다. 예약을 진행하려면 투숙자 이름과 결제 수단 확인이 필요합니다."

이 요약은 단순한 친절이 아니다. 사용자가 앱이 무엇을 이해했는지 검증할 수 있게 해 준다. 특히 외부 서비스에 영향을 주는 작업에서는 이 과정이 필수다. UI에서 클릭한 내용이 대화에 남으면 사용자는 이후에도 "아까 선택한 숙소에서 체크인 시간을 바꿔줘"처럼 자연스럽게 이어 갈 수 있다.

이때 앞 장에서 다룬 상태 동기화 원칙도 함께 적용된다. 위젯 내부 상태만 바꾸지 말고, 모델이 이해할 수 있는 구조화된 결과와 필요한 요약을 함께 제공해야 한다. 그래야 다음 턴에서 모델이 같은 맥락을 잃지 않는다.

신뢰 신호는 실행 직전에 가장 중요하다

예약, 주문, 쇼핑, 지도, 금융, 업무 자동화 앱은 외부 세계에 실제 영향을 준다. 이런 앱에서 UX의 핵심은 빠른 실행이 아니라 예측 가능한 실행이다.

사용자는 다음 질문에 답할 수 있어야 한다.

• 지금 보는 정보가 실시간인가, 캐시된 정보인가?

• 어떤 계정이나 외부 서비스에 연결되는가?

• 어떤 개인정보가 사용되는가?

• 결제, 예약, 전송, 삭제 같은 변경 작업이 실제로 실행되는 시점은 언제인가?

• 실행 후 취소하거나 수정할 수 있는가?

예를 들어 음식 주문 앱이라면 "주문하기" 버튼 앞에 메뉴, 수량, 주소, 예상 도착 시간, 총액, 취소 가능 여부를 보여줘야 한다. 대화에서도 같은 내용을 짧게 확인해야 한다.

"총 32,500원이며, 배달 주소는 서울시 ○○구로 설정되어 있습니다. 지금 주문을 확정할까요?"

여기서 "확정할까요?"는 중요한 경계다. 조회와 실행, 추천과 구매, 초안 작성과 실제 전송을 구분해야 한다. 사용자가 의도하지 않은 외부 작업을 막는 가장 단순하고 강력한 장치다.

오류 문구도 신뢰 신호에 포함된다. "오류가 발생했습니다"는 부족하다. "예약 가능 여부를 확인하는 중 식당 서버 응답이 지연되었습니다. 같은 조건으로 다시 조회하거나 시간을 변경할 수 있습니다"처럼 원인과 다음 행동을 알려야 한다.

접근성과 지역화는 나중 일이 아니다

ChatGPT 앱은 다양한 환경에서 쓰인다. 데스크톱, 모바일, 작은 화면, 느린 네트워크, 키보드만 쓰는 사용자, 스크린 리더 사용자, 여러 언어와 지역 표현을 모두 고려해야 한다.

접근성은 별도의 품질 작업이 아니라 초기 설계 항목이다. 버튼에는 의미 있는 레이블을 붙이고, 아이콘만으로 상태를 전달하지 않는다. 색상 대비를 충분히 확보하고, 키보드로 주요 조작을 완료할 수 있어야 한다. 오류 메시지는 시각적 강조만이 아니라 텍스트로도 전달되어야 한다.

지역화도 단순 번역이 아니다. 날짜, 시간, 통화, 주소, 전화번호, 존댓말 수준, 결제 관습이 모두 다르다. "5/6"은 지역에 따라 5월 6일일 수도 있고 6월 5일일 수도 있다. "내일 저녁" 같은 표현은 사용자의 시간대와 지역 맥락을 기준으로 해석해야 한다.

특히 다국어 앱에서는 도구 스키마와 사용자-facing 문구를 함께 점검해야 한다. 모델이 한국어 요청을 받았는데 입력 스키마 설명이 모호한 영어로만 되어 있으면 잘못된 인자를 만들 가능성이 커진다. 사용자가 보는 문장뿐 아니라 모델이 읽는 설명도 제품 UX의 일부다.

대화형 UX 체크리스트

마지막으로 앱을 출시하기 전 다음 질문에 답해 보자.

• 사용자가 앱 이름을 직접 불렀을 때 무엇을 할 수 있는지 즉시 이해되는가?

• 앱 이름을 말하지 않아도, 어떤 대화 맥락에서 발견되어야 하는지 설명되어 있는가?

• 도구 설명에 과업, 필요 입력, 제약, 실행 전 확인 조건이 포함되어 있는가?

• UI는 대화가 못 하는 일을 보완하고 있는가, 아니면 기존 웹앱을 그대로 옮겨 놓았는가?

• 사용자가 UI에서 선택한 내용이 대화로 요약되어 다음 행동으로 이어지는가?

• 결제, 예약, 전송, 삭제 같은 작업 전에 명확한 확인 단계가 있는가?

• 오류가 났을 때 사용자가 복구 방법을 알 수 있는가?

• 키보드, 스크린 리더, 작은 화면, 다국어 환경에서도 핵심 작업을 완료할 수 있는가?

좋은 ChatGPT 앱은 사용자가 앱 사용법을 배우게 하지 않는다. 사용자의 말을 이해하고, 필요한 순간에 나타나고, 실행 전에는 분명히 확인하고, 실행 후에는 무엇이 바뀌었는지 알려준다. 이 흐름이 자연스러울수록 앱은 화면이 아니라 대화 안에서 발견된다.

참고

¹UX principles - Apps SDK | OpenAI Developers