우아한공방의 새로운 동료, 시스템 맥락을 가진 챗봇서비스 개발기(feat. RAG)

AI로 생성한 이미지

디자인시스템플랫폼팀은 코어(Core, 토큰/아이콘 과 같은 디자인 리소스, 베이스 컴포넌트 등 공통 기반을 정의하는 계층), 클레이(Clay, 코어 토큰을 기반으로 Base 컴포넌트에 테마를 적용해 사용 가능한 컴포넌트 라이브러리를 제공하는 계층), 몰드(Mold, Clay/Base컴포넌트를 기반으로 각 도메인/비즈니스 요구사항에 맞는 패턴을 라이브러리화한 계층)와 같은 계층 구조를 기반으로, 모든 플랫폼에서 일관된 사용자 경험을 제공하는 디자인시스템인 우아한공방을 만들고 있습니다. (자세한 내용은 디자인 가이드를 넘어 비로소 시스템으로, 우아한공방 코어시스템 영상을 참고해 주세요.)

우리는 단순히 컴포넌트를 “제공”하는 것에 그치지 않고, 사용자가 우아한공방의 설계 의도와 사용 맥락을 더 쉽게 이해할 수 있도록 AI 기반인 디자인시스템 플랫폼을 만들고 있습니다. 나아가 여러 문서와 가이드를 직접 탐색하지 않아도, 디자인 가이드만으로 우아한공방의 패턴과 규칙이 반영된 UI 코드를 빠르게 생성할 수 있는 환경을 만드는 것을 목표로 하고 있습니다.

하지만 이를 위해서는 우아한공방의 방대한 문서와 가이드, 코드베이스 속에서 필요한 맥락을 빠르게 찾고 이해할 수 있어야 했습니다. 특히 우아한공방처럼 문서와 가이드, 코드베이스, 디자인 자산이 함께 존재하는 환경에서는 “필요한 정보를 얼마나 빠르게 찾을 수 있는가” 자체가 중요한 사용자 경험이 되었습니다.

그래서 저희는 사용자가 필요한 맥락을 자연어로 바로 질문하고, 우아한공방의 지식과 히스토리를 기반으로 답변을 받을 수 있는 환경이 필요하다고 생각했습니다.

작년에는 IDE 안에서 디자인 가이드와 코드베이스를 더 쉽게 활용할 수 있도록 우아한공방 MCP를 제공했습니다. MCP에 이은 우리의 다음 여정은 개발자뿐 아니라 누구나 동일한 맥락의 도움을 받을 수 있는 서비스인 우아한공방 챗봇 서비스입니다.

아래 영상은 2025년에 우아콘에서 발표한 세션입니다. 세션에서 설명하는 것처럼 우아한공방은 다양한 문서와 디자인 가이드, 코드베이스를 통해 사용처에 디자인시스템 경험을 제공하고 있습니다.

당연해진 디자인시스템, 그다음 이야기: AST와 MCP로 여는 미래

하지만 자료가 많아질수록, 필요한 정보를 빠르게 찾는 일은 점점 어려워졌습니다.

예를 들어 특정 컴포넌트의 사용 방법을 찾고 싶거나, 과거에 어떤 이슈가 있었는지 확인하고 싶을 때 사용자는 자연스럽게 슬랙의 우아한공방 서포트 채널에 질문을 남기게 됩니다. 문제는 같은 질문이 반복되더라도 이전 히스토리를 찾기 어렵고, 특정 버그가 어떤 배경에서 해결되었는지 한 번에 파악하기도 쉽지 않았다는 점입니다. 서포트 채널 특성상 답변을 기다리는 시간도 필요했습니다.

이런 문의가 쌓일수록 사용처는 필요한 정보를 얻기까지 더 많은 시간을 써야 했고, 우아한공방 개발자 역시 반복되는 질문과 지원 요청을 계속해서 처리해야 했습니다.

그래서 작년에는 우아한공방 MCP를 제공했습니다. 사용자가 구현하려는 UI의 피그마 가이드 링크를 전달하면, 우아한공방의 컴포넌트와 패턴이 반영된 코드를 제안하거나, 질의를 통해 디자인 가이드와 코드베이스의 맥락을 보다 쉽게 확인할 수 있도록 지원했습니다.

하지만 MCP만으로는 한계도 있었습니다. 우선 개발자가 아닌 다른 직군이 IDE나 CLI 환경에서 MCP를 사용하는 데에는 진입 장벽이 있었습니다. 또한 어떤 질문이 반복적으로 들어오는지, 응답 품질은 어떤지와 같은 데이터를 서비스 관점에서 수집하고 개선하기 어려웠습니다. 검색 범위나 권한 정책, 응답 품질, 운영 방식 역시 우리의 서비스 요구사항에 맞게 직접 통제하기 어려운 부분이 있었습니다.

반복되는 서포트 문의를 줄이고, 사용자가 필요한 맥락을 스스로 찾게 하기 위해서는 단순한 검색 이상의 시스템이 필요했습니다. 다시 말하면 단순히 문서를 찾아주는 AI가 아니라, 우아한공방의 설계 의도와 컴포넌트 히스토리, 디자인 가이드와 코드베이스의 맥락까지 이해한 상태에서 답변할 수 있는 시스템입니다. 그래서 저희는 AWS Bedrock Knowledge Bases를 활용한 RAG 기반 챗봇 서비스를 구축하게 되었습니다.

이제부터 AWS Bedrock 기반의 RAG 시스템을 구성해 우아한공방 챗봇 서비스를 구현한 과정을 소개하겠습니다.

서비스 구성

서비스는 크게 챗봇 UI를 제공하는 웹 애플리케이션과 챗봇 요청을 처리하는 API 서버로 구성했습니다. API 서버에서는 AWS Bedrock Knowledge Bases를 기반으로 RAG 체인을 수행하고, DynamoDB를 통해 채팅 히스토리를 관리합니다.

특히 Knowledge Bases의 벡터 스토어로는 Amazon OpenSearch Serverless(AOSS)를 선택했습니다. 단순히 문서를 임베딩해 저장하는 것을 넘어, 메타데이터 기반 필터링을 통해 컴포넌트 단위로 검색 범위를 제어하고 싶었기 때문입니다. 단순 키워드 검색이 아니라, 여러 문서를 함께 검색하고 메타데이터 기반 필터링을 적용할 수 있는 구조가 필요했습니다.

서버 구현

1. 스트리밍 응답

서버에서는 LangChain 을 활용해 Bedrock 기반의 RAG 체인을 구성합니다. 사용자 질문을 받아 관련 문서를 먼저 검색(Retrieval)한 뒤, 검색된 문맥(context)과 함께 LLM에 전달해 응답을 생성하는 역할을 합니다. LLM의 응답은 SSE(Server-Sent Events) 기반 스트리밍 방식으로 전달했습니다.

여기서 Retrieval은 단순 키워드 검색이라기보다, 사용자의 질문과 의미적으로 연관된 문서 조각들을 찾아오는 과정에 가깝습니다. 예를 들어 FilledButton 사용법 알려줘 와 같은 질문이 들어오면, 관련 컴포넌트 문서나 가이드 일부를 먼저 검색한 뒤 이를 기반으로 LLM이 답변을 생성하게 됩니다.

// 응답 형식 예시 data: {"text": "# FilledButton 사용 가이드"} data: {"text": "FilledButton은 ..."} ... data: [DONE]

이렇듯 초기에는 사용자의 질문만으로 Retrieval을 수행했습니다.

2. 시스템 프롬프트 설정

단순히 문서를 Retrieval하는 것만으로는 우아한공방의 설계 규칙과 패키지 구조를 충분히 설명하기 어려웠기 때문에, 시스템 프롬프트를 통해 디자인시스템의 핵심 규칙과 답변 정책도 함께 주입했습니다. 시스템 프롬프트에는 우아한공방의 패키지 구조, 주요 컴포넌트 카테고리, 핵심 규칙, 답변 규칙등을 정의했습니다.

export const SYSTEM_PROMPT = `당신은 우아한형제들의 디자인시스템인 우아한공방(Atelier)의 전문가입니다. 컴포넌트 사용법을 안내하고 필요 시 관련 코드나 문서를 제공해주는 AI 어시스턴트로서 답변을 해야 합니다. ## 패키지 구조 ... ## 주요 컴포넌트 카테고리 ... ## 핵심 규칙 ... ## 답변 규칙 ... `

3. Retrieval 품질 개선

사용자 질문만으로 Retrieval을 수행하니 특정 질문에서 하나의 문서만 참고하거나, 관련 없는 컴포넌트 문서까지 함께 검색되는 문제가 있었습니다.

예를 들어 Button을 검색했을 때 IconButton 관련 문서까지 함께 검색되면서 응답 품질이 흔들리는 경우가 있었습니다.

이를 해결하기 위해 Retrieval 이전에 사용자 질문에서 컴포넌트 정보를 먼저 추출하고, 이를 메타데이터 필터로 변환하는 구조를 적용했습니다.

3.1 컴포넌트 추출

먼저 컴포넌트 추출하는 프롬프트는 다음과 같이 설정했습니다. 특히 사용자의 질문에는 오타가 포함되는 경우가 많았기 때문에, 버턴 → 버튼 → Button 과 같은 보정 규칙도 함께 적용했습니다.

export const EXTRACT_SYSTEM_PROMPT = ` 당신은 사용자의 질문에서 UI 컴포넌트 이름을 추출하는 분류기입니다. ... `

위 프롬프트로 LLM을 활용해 사용자의 질문에서 관련 컴포넌트 이름을 추출합니다. 예를 들면 다음과 같습니다.

질문1: FilledButton 사용법 알려줘 -> ["FilledButton"] 질문2: 우아한공방의 버튼 컴포넌트에는 어떤 것들이 있어? -> ["FilledButton", "OutlinedButton", "TextButton", "FilledIconButton", "OutlinedIconButton"]

3.2 메타데이터 기반 Retrieval

추출된 컴포넌트는 Knowledge Base의 메타데이터 필터로 변환됩니다. Knowledge Base 에 각 문서를 추가할 때는 아래와 같은 메타데이터 json을 함께 저장했습니다.

{ ..., "components": "|FilledButton|" }

이후 Retrieval 단계에서 stringContains 기반 필터를 적용해 관련 문서만 검색하도록 구성했습니다. 단순 문자열 검색만 사용할 경우 Button 과 IconButton 이 함께 매칭되는 문제가 있었기 때문에, |FilledButton| 처럼 구분자를 포함한 형태로 저장했습니다.

const filters = components.map((name) => ({ stringContains: { key: METADATA_KEY, value: `|${name}|`, }, }));

3.3 Retrieval 구성

최종적으로는 LangChain 기반 RAG 체인을 구성해 아래 4가지 과정을 LangChain의 RunnableSequence를 통해 전체 흐름을 체인 형태로 구성했습니다.

1. 사용자 질문 분석
2. 관련 문서 Retrieval
3. Prompt 구성
4. LLM 응답 생성

const retriever = new AmazonKnowledgeBaseRetriever( this.buildRetrieverArgs(components), // 컴포넌트 메타데이터 기반 Retrieval 구성 ); const formatContext = RunnableLambda.from( (docs: { pageContent: string }[]) => this.formatDocs(docs), ); return RunnableSequence.from([ RunnableParallel.from({ context: retriever.pipe(formatContext), // 검색된 문서를 Prompt context로 변환 question: new RunnablePassthrough(), // 원본 사용자 질문 유지 }), this.ragPrompt, this.model, // Prompt와 context를 기반으로 LLM 응답 생성 new StringOutputParser(), ]);

4. topK 튜닝

Retrieval 품질에서 중요했던 요소 중 하나는 topK 값이었습니다. topK는 Knowledge Base에서 사용자 질문과 관련성이 높다고 판단한 문서 조각(chunk)을 몇 개까지 가져올지를 결정하는 값입니다. 예를 들어 topK를 5로 설정하면, 질문과 가장 관련성이 높은 문서 조각 5개를 검색해 LLM에 context로 전달합니다.

이 값은 응답 품질과 비용에 직접적인 영향을 줍니다. topK를 낮게 설정하면 입력 토큰 사용량이 줄어들고 관련성이 높은 문서 위주로 답변할 수 있지만, 필요한 맥락이 충분히 포함되지 않아 답변이 편향되거나 불완전해질 수 있습니다. 반대로 topK를 높이면 여러 문서를 함께 참고할 수 있어 답변에 필요한 맥락을 더 많이 제공할 수 있지만, 관련 없는 문서까지 함께 포함되어 LLM이 혼란스러워지거나 입력 토큰 사용량과 비용이 증가할 수 있습니다.

초기에는 모든 질문에 동일한 topK 값을 적용했습니다. 하지만 실제 테스트 과정에서 질문의 성격에 따라 필요한 문서의 범위가 다르다는 것을 확인했습니다. 예를 들어 특정 컴포넌트의 사용 방법을 묻는 질문은 관련 문서 범위가 비교적 좁기 때문에 topK를 낮게 설정해도 충분했습니다. 반면 접근성 정책, 디자인 토큰 적용 기준, 컴포넌트 설계 히스토리처럼 여러 문서를 함께 참고해야 하는 질문은 더 넓은 맥락이 필요했기 때문에 topK를 높이는 편이 더 안정적이었습니다.

그래서 현재는 질문 유형과 문서 특성을 고려해 적절한 topK 값을 적용하고 있습니다. 컴포넌트 단위의 명확한 질문은 검색 범위를 좁혀 정확도를 높이고, 정책이나 히스토리처럼 여러 문서의 맥락이 필요한 질문은 더 많은 chunk를 참고하도록 조정해 응답 품질을 개선하고 있습니다. 특히 topK의 적절한 값은 문서의 chunk 크기나 메타데이터 구조, 데이터 소스를 어떻게 분리했는지에 따라서도 Retrieval 결과가 달라질 수 있기 때문에 지속적으로 실험과 튜닝을 진행하고 있습니다.

5. Guardrail 설정

챗봇을 베타 배포한 뒤, 예상보다 다양한 방식으로 서비스를 사용하는 사례들을 확인할 수 있었습니다.

왼쪽 예시처럼 디자인시스템과 무관한 질문을 하거나, 오른쪽 예시처럼 특정 인물에 대한 평가를 요청하는 질의들이 들어오기 시작했습니다. 문제는 이러한 응답이 단순한 재미 요소를 넘어, 우아한공방 챗봇이 의도한 서비스 범주 밖의 답변까지 생성하고 있었다는 점입니다. 서비스의 역할과 무관한 응답이 계속 생성될 경우 사용자 경험과 응답 신뢰도에도 영향을 줄 수 있었기 때문에, 답변 범위를 명확히 제한할 필요가 있었습니다.

그래서 저희는 AWS Bedrock Guardrails를 도입했습니다. Guardrail을 통해 부적절한 입력과 응답을 제한하고, 우아한공방과 관련된 주제에만 집중된 챗봇 경험을 제공하고자 했습니다.

5.1 기본 Guardrail 설정

우선 Bedrock에서 제공하는 기본 Guardrail 기능들을 활성화했습니다.

기본 기능

• Harmful categories
  • Hate filter for prompts
  • Insults filter for prompts
  • Sexual filter for prompts
  • Violence filter for prompts
  • Misconduct filter for prompts
• Prompt attacks

5.2 추가 Guardrail 설정

• 정책 이름: person-related queries
  • 특정 개인(직원, 사용자, 외부 인물 포함)에 대한 정보 요청이나 평가를 제한하는 정책입니다. 예를 들어 아래와 같은 질문을 차단하도록 구성했습니다.
  • 특정 인물의 이름, 역할, 연락처 요청
  • 특정 개인에 대한 평가나 의견 요청
  • 내부 구성원에 대한 불필요한 질의
• 정책 이름: non-design-system queries
  • 우아한공방과 무관한 질문을 제한하는 정책입니다. 컴포넌트, UI 패턴, UX Writing, 디자인 토큰, 스타일 가이드, 접근성, 인터랙션 등 디자인시스템과 직접적으로 관련된 주제에 대해서만 응답하도록 제한했습니다. 이를 통해 일반 상식 질문이나 외부 서비스에 대한 질문처럼 우아한공방과 관련 없는 질의는 응답하지 않도록 구성했습니다.

5.3 적절한 응답 설정

위와 같은 이유로 제한된 응답이 필요할 때에는 다음의 응답이 반환되도록 설정했습니다.

해당 요청은 정책에 따라 답변할 수 없어요. 다른 내용에 대해 질문해주시면 도와드리겠습니다 :)

이로써 다음과 같은 질문에는 저희가 설정한 응답이 반환되었습니다.

5.4 Guardrail 트러블슈팅

하지만 단순히 Guardrail 규칙만 적용했을 때는, 의도하지 않은 방식으로 동작하는 이슈가 있었습니다.

저희가 원했던 것은 사용자의 입력(input)에 대해서만 Guardrail을 적용하는 것이었습니다. 하지만 실제로는 모델의 출력(output)까지 함께 검사되고 있었고, 이로 인해 정상적인 응답까지 필터링 되는 문제가 발생했습니다.

예를 들어 아래와 같은 경우입니다.

• 질의: 권현아가 누구야? → person-related queries 정책에 의해 차단되어야 하는 정상적인 케이스
• 응답: 이 컴포넌트의 이슈는 권현아가 mm/dd에 해결했어요 → 단순히 문서 맥락을 설명하는 응답이었지만, 출력 단계에서도 person-related queries 정책이 적용되며 함께 필터링 되는 문제 발생

또한 Guardrail의 출력 검사가 활성화된 상태에서는 스트리밍 응답도 예상과 다르게 동작했습니다. 응답이 chunk 단위로 바로 전달되는 것이 아니라, 일정량이 누적된 뒤 Guardrail 검사를 거쳐 전달되는 방식으로 동작했던 것입니다.

이로 인해 SSE 기반 스트리밍 응답이 자연스럽게 이어지지 않았고, 응답 지연도 함께 발생했습니다. 그래서 아래의 두 가지 작업을 통해 문제를 해결했습니다.

1) Output 검사 비활성화
아래 이미지와 같이 Guardrail의 output 검사 정책을 비활성화해, 입력(input)에 대해서만 Guardrail이 동작하도록 조정했습니다.

2) 비동기 스트리밍 처리
추가로 streamProcessingMode: 'async' 옵션을 활성화해 스트리밍 응답이 즉시 전달될 수 있도록 구성했습니다. 다만 Langchain 사용 시, ChatBedrockConverse 타입에서는 streamProcessingMode 옵션을 직접 다루기 어려웠기 때문에 AWS SDK의 ConverseStreamCommand를 직접 호출하는 방식으로 우회했습니다.

import { ConverseStreamCommand, } from '@aws-sdk/client-bedrock-runtime'; const command = new ConverseStreamCommand({ ... ...(this.guardrailId && { guardrailConfig: { ... streamProcessingMode: 'async', }, }), });

UI 구현

지금까지 응답을 받을 수 있는 서버를 만들었습니다. 이제 이 응답을 직관적으로 확인하고 대화할 수 있는 챗봇 UI를 구성할 차례입니다.

디자인시스템플랫폼 팀에서는 사용자가 별도의 문서를 찾아보는 수고를 덜고, ‘내가 궁금한 사항’을 즉시 해결할 수 있도록 컴포넌트 명세가 모여있는 스토리북 내에 챗봇을 추가하기로 결정했습니다.

스토리북에 챗봇 추가

기존 우아한공방1.0에서는 코어/클레이 민트/클레이 블루/몰드 스토리북이 각각의 url로 존재하다 보니 문서와 맥락이 흩어져 한 눈에 보기 어려웠던 단점이 있었습니다. 클레이민트2.0을 개편하면서 해당 문제를 해결하기 위해 Storybook Composition을 활용하게 되었고, 아래 왼쪽 이미지와 같이 두 스토리북을 한 url에서 제공하고 있습니다. 이에 따라 오른쪽 이미지와 같이 iframe이 두개로 나뉘어 있습니다.

이 때문에 챗봇 UI가 민트/코어 한 쪽의 스토리북에 종속되면 해당 iframe에만 element가 추가되어 특정 스토리에서는 챗봇이 보이지 않을 수 있는 문제가 생겼습니다. 이를 해결하기 위해 단순히 스토리북의 config 파일인 preview-body.html, preview.tsx 에 추가하는 것이 아니라, 전체 문서의 최상단에 독립적으로 떠 있는 전역 UI를 구성해야만 했습니다.

preview.tsx 활용

React의 컴포넌트를 사용하면서 모든 문서에 예외없이 챗봇을 표시하기 위해 preview.tsx가 Storybook 렌더링 전에 실행된다는 점을 이용했습니다. 이는 Google Analytics 같이 전역으로 스크립트를 심는 로직과 유사합니다.
preview.tsx로 실행하는 코드의 동작 방식은 아래와 같습니다.

• 최상단(document)에 숨겨진 div를 생성합니다.
• 해당 div를 React.createRoot를 통해 리액트의 Root로 만듭니다.
• Root에 챗봇 컴포넌트를 주입합니다.

// preview.tsx // 1. 스토리북이 렌더링되기 전, 전역(iframe)에 챗봇을 주입 mountComponentAtRoot(ChatbotWidget, 'chatbot-widget') // mountComponentAtRoot.ts export const mountComponentAtRoot = (Component: React.FC, anchorId: string) => { // 2. 최상단 document에 숨겨진 div(앵커) 생성 및 주입 const anchor = document.createElement('div') anchor.hidden = true document.body.appendChild(anchor) // 3. 해당 앵커를 리액트 루트로 만들어 컴포넌트 렌더링 const root = createRoot(anchor) root.render(<Component />) }

챗봇 UI 추가된 스토리북

이로써 챗봇 UI가 스토리북의 최상단에 위치하도록 구현할 수 있었고, Storybook Composition으로 여러 스토리북을 연결해도 어느 스토리에서나 챗봇 UI를 유지할 수 있습니다.

챗봇 패키지화

디자인시스템플랫폼 팀은 이렇게 만든 챗봇을 스토리북에 직접 추가하지 않고 독립적인 npm 패키지로 분리하기로 결정했습니다. 전사에 패키지를 쉽게 배포할 수 있는 디자인시스템플랫폼 팀의 인프라적인 강점을 살려 배포하면, 다른 서비스를 운영하는 사용처에서도 각자의 도메인 지식을 가진 AI 서비스를 만들 때 도움을 줄 수 있을 거라 판단했기 때문입니다.

이를 위해 다양한 사용처에서 커스텀 할 수 있도록 유연한 인터페이스를 설계했습니다. 사용처 자체 챗봇 API를 연결할 수 있도록 비즈니스 로직과 UI를 분리했으며, 여러 라벨을 커스텀하도록 구성했습니다. 이에 따라 챗봇 API는 구축했지만 UI 구현이 어려워 도입을 망설이던 팀들도 우아한공방 챗봇 패키지를 통해 바로 챗봇서비스를 시행할 수 있게 되었습니다.

인터페이스 구성

물론 우아한공방 챗봇이 사용하는 속성도 함께 제공하고 있습니다. 우아한공방 챗봇 서비스를 사용하고 싶은 경우 사용처에선 해당 속성을 불러오면 쉽게 우아한공방 맥락을 가진 챗봇 서비스를 구현할 수 있습니다.

import { createSendChatMessage, Chatbot, WOOWAHAN_CHATBOT_API_ENDPOINT, woowahanChatbotLabels, WoowahanEmptyState, woowahanSendChatMessage, } from "@atelier/chatbot"; // 혹은 endpoint를 불러와서 정의해도 되어요. // const sendMessage = createSendChatMessage({endpoint: WOOWAHAN_CHATBOT_API_ENDPOINT}) const App = () => { return ( <div> <Chatbot emptyState={<WoowahanEmptyState />} sendMessage={woowahanSendChatMessage} labels={woowahanChatbotLabels} /> </div> ); }; export default App;

실시간 스트리밍(SSE) 응답 처리

LLM의 응답이 SSE 기반 스트리밍 방식으로 전달되기 때문에, 응답을 받는 UI에서도 스트리밍 방식으로 대응해야 사용자에게 LLM의 답변을 자연스럽게 보여줄 수 있게 됩니다.

응답이 EventStream 형태로 오는 경우 body.getReader()로 해당 Stream을 읽는 reader를 불러올 수 있습니다. 이 reader의 read 속성을 이용해 완료 신호를 받을 때까지 다음 청크의 정보를 불러옵니다. 이 정보는 문자열이 아니라 바이트 형태이기 때문에 TextDecoder를 이용해 바이트를 문자열로 변환하는 과정이 필요합니다. 이렇게 변환한 청크 단위의 문자열을 개행 문자로 쪼개되, 네트워크 상황에 따라 잘려 들어오는 데이터 버퍼를 안전하게 조합하여 UI에 끊김 없이 글자가 타이핑되도록 구현했습니다.

const sendChatMessage = async (endpoint, message, onChunk) => { const response = await fetch(endpoint, { method: 'POST', body: JSON.stringify({ message }) }) // 1. 응답 EventStream을 읽는 reader 생성 const reader = response.body.getReader() const decoder = new TextDecoder() let buffer = '' // 2. 완료 신호를 받을 때까지 다음 청크를 연속해서 읽음 while (true) { const { done, value } = await reader.read() if (done) break // 3. 바이트 데이터를 문자열로 변환 후 버퍼에 누적 buffer += decoder.decode(value, { stream: true }) const lines = buffer.split('\n') buffer = lines.pop() ?? '' // 4. 완성된 라인만 정제하여 UI state 업데이트 콜백(onChunk) 실행 for (const line of lines) { if (!line.startsWith('data: ')) continue const payload = line.replace('data: ', '') if (payload === '[DONE]') return // 스트리밍 종료 신호 const chunk = JSON.parse(payload) if (chunk.text) onChunk(chunk.text) } } }

RAG API로 MCP 응답 고도화하기

흥미로웠던 점 중 하나는, 챗봇 서비스를 위해 구축한 RAG API를 MCP에서도 함께 활용할 수 있었다는 점입니다.

예시에서는 사용자의 코드가 우아한공방 디자인 가이드를 잘 따르고 있는지 검사하고 있습니다. 기존 우아한공방 MCP는 디자인 가이드나 컴포넌트 정보를 조회하고, 이를 기반으로 코드를 생성하거나 수정하는 역할에 가까웠습니다. 하지만 Retrieval 기반의 문맥 검색 기능은 제한적이었기 때문에, 사용자의 코드와 우아한공방의 설계 의도 사이의 연결을 충분히 설명하기 어려운 경우도 있었습니다. 하지만 RAG API를 연결한 이후에는 관련 가이드 문서와 이슈 히스토리, 설계 규칙까지 함께 Retrieval한 뒤 이를 기반으로 더 구체적인 개선 방향을 제안할 수 있게 되었습니다.

이를 통해 웹 챗봇과 MCP가 동일한 Retrieval 결과와 설계 맥락을 공유할 수 있게 되었고, IDE 환경에서도 보다 일관되고 정교한 응답 품질을 제공할 수 있었습니다. 특히 하나의 RAG API를 웹과 MCP 양쪽에서 함께 활용하면서, Retrieval 정책이나 응답 품질 개선 작업을 중앙에서 일관되게 관리할 수 있었다는 점도 큰 장점이었습니다.

이번 서비스 개발을 통해 얻은 것

이번 서비스 개발을 통해 가장 크게 달라진 점은, 반복적으로 들어오던 기본적인 사용 문의의 상당 부분을 챗봇 서비스가 대신 처리하게 되었다는 점입니다. 이전에는 컴포넌트 사용 방법이나 설계 의도, 특정 이슈의 히스토리, 디자인 가이드 적용 방법과 같은 질문이 슬랙 서포트 채널로 반복해서 들어왔습니다. 이제는 사용자가 직접 챗봇을 통해 필요한 맥락을 빠르게 찾고, 관련 문서와 코드 예시까지 함께 확인할 수 있게 되었습니다.

덕분에 우아한공방 개발자는 동일한 질문에 반복적으로 대응하기보다, 시스템을 더 견고하게 만들고 사용 경험을 개선하는 일에 더 집중할 수 있게 되었습니다. 단순히 “질문에 답하는 역할”에서 벗어나, 디자인시스템 자체를 어떻게 더 잘 설계하고 확장할지 고민할 수 있는 시간이 생긴 것입니다.

또한 이번 챗봇 서비스와 RAG 서버 구축 경험은, 앞으로 우아한공방이 지향하는 GenUI 플랫폼으로 확장하기 위한 중요한 기반이 되기도 합니다. 저희가 궁극적으로 만들고 싶은 것은 단순히 질문에 답하는 챗봇이 아니라, 사용자가 디자인 없이 아이디어만으로도 UI를 구성할 수 있는 환경입니다. Drag & Drop으로 컴포넌트를 배치하고, AI Agent와의 질의응답을 통해 컴포넌트를 수정하거나 화면을 점진적으로 발전시켜나가는 형태의 플랫폼을 저희 팀은 지향하고 있습니다.

이번에 구축한 Retrieval 구조와 디자인시스템 맥락 이해, 코드 생성 경험들은 이러한 GenUI 경험을 구현하기 위한 중요한 시작점이 되고 있습니다.

마무리

이렇듯 디자인시스템플랫폼팀은 단순히 컴포넌트를 제공하는 것을 넘어, AI를 활용해 디자인시스템의 정보를 더 쉽게 전달하고, 코드를 생성하거나 수정하며, 나아가 사용자의 아이디어 만으로도 서비스 UI를 구현할 수 있는 환경을 만들어가고 있습니다.

앞으로 더 질이 좋은 응답을 제공하고, 더 사용하기 쉬운 툴을 제공하기 위한 고도화 작업이 진행될 예정입니다. 디자인시스템과 AI가 결합해 어떤 사용자 경험을 만들어낼 수 있을지, 우아한공방의 다음 여정도 기대해주세요.

* 함께하고 싶은 분들은 언제나 부담없이 연락 주세요. 두 팔 벌려 기다리고 있습니다.