Tribeau에서 CTO를 맡고 있는 오비(@obiyuta)입니다.

저희 회사는 2026년 7월, 미용 의료 앱 「Tribeau」에 AI 상담 기능을 출시했습니다. 고민 사항에 대한 히어링(Hearing)부터 시작하여, 사용자의 희망 조건에 따라 시술이나 클리닉, 메뉴 후보를 검색·정리하여 제시하고, 그대로 예약까지 진행할 수 있는 AI 채팅 기능입니다.

이 기사는 의료 도메인에서 사용자 대상의 AI 기능을 제공함에 있어, 안전성이나 비용을 희생하지 않고 최상의 경험을 제공하기 위한 설계와 그 과정에서의 실패 사례를 전달해 드리고자 합니다.

AI 상담이란

기능으로는 고민의 히어링과 정리를 시작으로, 시술의 이해·비교부터 희망 조건에 따른 클리닉·메뉴 후보 검색·정리 및 제시, 관련 리뷰(口コミ) 검색, 예약까지 서포트합니다. 답변에는 텍스트뿐만 아니라 시술 정보 비교 카드, 메뉴, 리뷰, 예약 버튼 등 앱에서 제공하는 정보와 기능이 나열됩니다.

이 대화는 즉흥적으로 진행되는 것이 아니라, 「1. 고민을 언어화하기」, 「2. 시술 결정하기」, 「3. 클리닉·닥터·메뉴 선택하기」의 3단계로 설계되어 있습니다. 사용자가 사고를 정리하면서 단계적으로 예약까지 나아갈 수 있도록 지원합니다.

기능의 위치 설정에 대해서도 적어두겠습니다. AI 상담은 Tribeau에 게재된 공개 정보를 사용자의 희망 조건으로 검색·정리하여 표시하는 「정보 검색 보조 도구」입니다. 진단이나 치료의 필요 여부·적합 여부의 판단은 수행하지 않으며, 시술을 받을지 여부는 의료 기관에서 의사에게 확인받는 것을 전제로, 그 취지와 면책 사항을 채팅 화면에 상시 표시하고 있습니다. 기능의 범위 또한 법령·가이드라인을 준수하여 제공할 수 있다고 확인된 것들로 한정하여 출시했습니다.

프로젝트의 요건과 역할 분담

「대화를 통해 사용자의 의사결정에 동행하면, 검색이나 추천(Recommend)으로는 전달할 수 없는 경험을 만들 수 있다」라는 가설을 검증하기 위해, 구현 시 처음부터 5가지 요건을 설정했습니다. 이 요건을 백엔드(Backend)와 프론트엔드(Frontend)에서 다음과 같이 분담하여 실현했습니다.

이 기사에서는 주로 표의 오른쪽 열인 프론트엔드 영역을 다루겠습니다. (백엔드는 별도로 소개할 예정입니다)

경험·안전·비용도 🙅이었던 프로토타입

개발 당초에는 우선 동작하는 것을 만드는 것을 우선시하여, 답변 카드 UI도 LLM이 HTML로서 직접 출력하게 했습니다. 프롬프트(Prompt)로 마크업 작성 방식을 지시하고, 답변마다 카드의 HTML을 생성하게 하는 구현 방식이었습니다.

출력 품질의 불안정함에 더해, 법령·가이드라인 등의 안전 측면에서도 기준을 충족하지 못했으며, 특히 비용 측면에서는 스케일링(Scaling) 시의 추산치를 본 관계자 전원의 「어...? 🥹」 하는 표정이 잊히지 않습니다.

무언가를 트레이드오프(Trade-off)하는 것이 아니라, 경험도, 안전도, 비용도 높은 수준으로 실현하기 위해 접근 방식을 대폭 재검토했습니다.

프론트엔드와 백엔드의 책임을 분리

수행한 작업은 매우 심플하며, 책임을 분리하여 다시 설계했습니다. LLM은 비즈니스 로직 측의 한 컴포넌트(Component)로 취급하여 「무엇을 보여줄 것인가」의 결정은 LLM이, 「어떻게 보여줄 것인가」는 프론트엔드에 완전히 맡겼습니다.

최종적인 사용자의 상담 시작부터 실제로 답변이 표시되기까지의 흐름은 다음과 같습니다.

답변의 모습은 리치(Rich)하지만, LLM이 화면을 만들고 있는 것은 아닙니다. LLM이 내보내는 것은 「무엇을 보여줄 것인가」에 대한 지시 데이터까지이며, 화면 구성과 데이터 취득은 프론트엔드에서 수행합니다.

템플릿 JSON에 기반하여 프론트에서 UI를 구축

실제로 프론트엔드가 무엇을 표시해야 하는지 알 필요가 있으므로, LLM으로부터는 답변 텍스트와 더불어 다음과 같은 JSON을 반환받습니다.

{
"templates":[
{
...

type이 템플릿의 종류이며, 카드에 맞춰 10개 전후의 종류가 있습니다.

type은 템플릿의 종류이며, 카드에 맞춰 10개 전후의 종류가 있습니다.

스키마는 시스템 프롬프트(System Prompt)로 정의하며, 프론트엔드에는 대응하는 타입(Type)과 type별 컴포넌트가 있습니다. API 서버는 이 JSON을 파싱(Parsing)하지 않고 그대로 클라이언트에게 반환할 뿐입니다. 스키마를 바꾸고 싶을 때는 프롬프트와 프론트엔드만 수정하면 되도록 설계되어 있습니다. React 컴포넌트 측에서 UI 변경이 완결되도록 하여, UI 개선도 훨씬 용이해졌습니다.

다만, 이 JSON도 LLM의 특성상 반드시 지정된 포맷으로 돌아온다는 보장이 없으므로, 파서(Parser)가 결손을 확인한 경우에는 답변 전체를 정형화된 안내 문구로 교체하여 깨진 출력이 화면에 표시되지 않도록 하고 있습니다. 그 외의 텍스트 부분도 새니타이즈(Sanitize)한 후 렌더링하는 등, LLM은 신뢰할 수 없는 존재라는 전제하에 설계했습니다.

실제 데이터 취득도 프론트 측에서

또한, 템플릿 JSON에 담는 데이터는 최소한으로 제한하였으며, 실제 데이터의 취득도 철저하게 프론트엔드 쪽으로 밀어 넣었습니다. JSON에 담기는 것은 ID와 표시용 최소한의 라벨(Label)뿐이며, 프론트엔드가 ID를 바탕으로 기존 API에서 취득한 최신 데이터를 사용하여 최종적인 UI를 구축합니다.

LLM의 출력값만으로는 해당 ID가 실제로 존재하는지 완전히 보장할 수 없다는 안전성 측면도 있으며, 이미지나 리뷰 본문 같은 긴 텍스트를 LLM의 I/O에 싣지 않아도 되기 때문에 비용 측면에서의 이점도 매우 큽니다.

안전성, 거버넌스 측면에서의 이점

실제 데이터를 프론트에서 다시 취득하도록 함으로써, 표시 규칙에 대한 거버넌스(Governance)를 적용하기도 쉬워졌습니다.

미용 의료 정보 표시에는 약기법(薬機法)이나 의료 광고 가이드라인 등 소비자의 안전을 지키기 위한 다양한 규칙이 있습니다. 저희 회사에서도 효과에 대한 언급을 포함한 리뷰 발췌본은 본문을 표시하지 않는 등 규칙을 준수한 서비스 운영을 하고 있으며, 이번에도 이러한 제어를 프론트엔드의 표시 계층(Display Layer)에서 수행하고 있습니다. 예를 들어, 리뷰 발췌를 표시하기 직전에 효과에 대한 언급이 포함되어 있는지 키워드로 판정하여, 포함된 경우 본문을 내보내지 않고 "◯◯님의 리뷰"라는 정적인 문구로 대체하는 등 몇 가지 필터가 작동합니다.

LLM의 출력에 본문이 포함되는 구성에서는 프롬프트로 "효과에 대해 언급하지 마"라고 지시해도 이를 보장할 수 없습니다. 프론트엔드에서 취득 및 판정함으로써 스크립트 기반의 확실한 제어를 구조적으로 실현할 수 있게 되었습니다.

그럼에도 생성형 AI의 특성상 의도하지 않은 표현을 완전히 배제할 수는 없습니다. 대화 로그는 전건 저장하여 지속적으로 모니터링하며, 표시 교체가 발생한 케이스는 이벤트로 측정하여 어떤 시술에서 발생했는지 분석 기반(Analysis Platform)을 통해 파악할 수 있도록 하고 있습니다. 감지되었을 경우에는 신속하게 조정하는 운영 방식입니다. 구조로 방어하고, 관측으로 보완하는 이중 방어 체계를 갖추고 있습니다.

비용: 실측 결과 약 1/10로 감소

남은 것은 비용입니다. 방식 전환 전후를 동일 조건에서 비교했을 때, 답변의 평균 글자 수는 1,041자에서 510자로 약 절반 수준이 되었습니다. 그 후 답변 사양을 풍부하게 만드는 변경을 거듭한 현재의 전체 기간 평균도 638자로, 약 40% 감소를 유지하고 있습니다 (토큰이 아니라 어디까지나 글자 수 비교입니다).

채팅은 매번 과거의 대화 이력을 입력에 포함해야 하므로, 메시지 1개를 줄이는 것은 대화 길이에 따른 승수 효과를 가져옵니다. 글자 수 기반의 개산으로는 몇 차례의 대화만으로 1/8~1/16 수준입니다. 실측 결과, API 이용 비용은 당초 예상의 약 1/10이 되었습니다 (프롬프트 캐시(Prompt Cache)도 동시에 도입했기에 그 효과도 일정 부분 있습니다).

요약

AI 상담의 프론트엔드 설계에서는 LLM의 역할을 최소한으로 한정하고, UI 구축과 실제 데이터 취득을 모두 프론트엔드가 수행함으로써 경험, 안전, 비용을 모두 희생하지 않는 기능 제공을 시작할 수 있었습니다.

경험: 풍부한 UI, 정보의 최신성·정확성, 기능의 유지보수성 실현
안전: 실제 데이터의 프론트 취득과 표시 직전의 통제를 통해, 단순 운영이 아닌 구조로 보호
비용: All LLM 버전 대비 실측 약 1/10

"LLM을 무엇을 위해 사용할 것인가", "사용자에게 어떤 가치를 전달하고 싶은가"를 기점으로 애플리케이션 전체를 설계하고, LLM만이 제공할 수 있는 역할을 맡기는 것이 베스트입니다. 이번 개발에서는 엔지니어가 프로덕트 매니저(PM)나 디자이너와 "최종적으로 사용자에게 무엇을 전달하고 싶은가"를 대화하며 구현을 진행할 수 있었기에, 단기간에 요구사항을 충족하는 기능 개발을 완료할 수 있었습니다.

이번 사례에 국한되지 않고, 경험도 안전도 비용도 트레이드오프(Trade-off) 대상이 아닙니다. 적절하게 설계하고 구현한다면 모든 것을 담보할 수 있을 것입니다. 균형점을 찾는 것이 엔지니어의 역할이며, 향후의 가치이자 존재 의의라고 생각합니다.

작은 공지

마지막으로 공지입니다. 이 기사는 화면에 전달하는 측의 설계에 집중하여 작성했습니다. 애초에 왜 이러한 형태에 도달하게 되었는지, 백엔드의 리뷰 검색 (RAG)이나 데이터 준비를 어떻게 설계했는지는 7/29 이벤트 「RAG × 실서비스 운용의 최전선」에서 이야기할 예정입니다. 관심 있는 분들은 꼭 참여해 주세요. (백엔드 편 기사도 이벤트 후에 다시 소개해 드릴 수 있으면 좋겠습니다.)

Discussion