WorkOS 스튜디오 사례: LangGraph와 Opus로 만든 사내 데이터 질문 에이전트

핵심 메시지

• WorkOS는 사내 누구나 자연어로 비즈니스 질문을 던지면 에이전트가 데이터를 조회해 답하는 '스튜디오(Studio)'라는 사내 워크스페이스를 직접 만들어 쓴다.
• 스튜디오는 LangGraph 기반 에이전트가 Opus 모델과 Snowflake·Linear·Notion 같은 도구를 묶어, 통합 프록시와 '가이던스 레이어'를 통해 질문에 답하고 결과를 저장한다.
• 한 번 만든 '위젯'은 UI·API·쿼리를 담은 샌드박스 코드라서, 새로고침해도 LLM을 다시 부르지 않고 실제 쿼리만 재실행하는 안정적이고 재사용 가능한 도구가 된다.
• 유용성과 신뢰성의 비결은 시퀀싱(사전 점검과 도구 호출 시점의 맥락 주입), 레이어링(기본 프롬프트+조직 규칙+도구별 맥락), 검증(쿼리를 실제 실행해 데이터가 돌아오는지 확인) 세 가지다.
• RAG 데이터베이스 없이 도구를 직접 호출하고 그 위에 맥락만 얹는 방식으로도 충분히 높은 적중률을 얻었으며, 지원팀이 슬랙에서 일상적으로 자가 해결에 활용한다.

쉽게 이해하기

WorkOS에서 제품을 총괄하는 개럿 갤로우는 자사 제품 자랑 대신, 회사가 내부적으로 더 생산적으로 일하기 위해 만든 도구 이야기를 꺼낸다. 그는 흔한 풍경을 짚는다. 누군가 비즈니스에 대한 질문이 생기지만 직접 답할 만큼 기술적이지 않아, SQL을 다루거나 데이터에 접근할 수 있는 사람에게 질문과 맥락을 설명하고 기다린다. 답이 오면 충분치 않아 다시 한 단계 더 깊은 데이터를 요청하며 슬랙에서 일회성으로 주고받는다. 이런 흐름은 확장되지 않는다는 것이 출발점이다.

그 문제를 풀기 위해 만든 것이 '스튜디오'다. 사람들이 직접 질문에 답하고 작은 앱이나 대시보드를 만들 수 있는 사내 워크스페이스다. 갤로우는 'WorkOS 사이트의 어떤 콘텐츠가 가장 많은 신규 팀 가입으로 이어지는가' 같은 질문을 던지면, 스튜디오가 접근 가능한 자원(Linear·Notion·Snowflake)을 파악하고 스키마와 테이블을 살펴 쿼리를 돌려 답을 가져오는 과정을 시연한다.

동작 구조는 이렇다. 사내 대시보드나 슬랙 봇으로 질문을 던지면 API가 이를 파싱해 LangGraph 기반 에이전트로 넘긴다. 이 에이전트는 Opus 같은 LLM과 도구, 그리고 시스템과 상호작용하는 방법을 정의한 '가이던스 레이어'에 묶여 있다. 통합 프록시가 Snowflake·Linear·Notion에 연결되고, 가이던스 레이어는 데이터를 제대로 쿼리하는 규칙과 맥락(예: 스노플레이크에서 고객을 어떻게 표현하는지, 테이블을 어떻게 조인하는지)을 정의한다. 세션 간 보존을 위해 상태는 Convex에 저장한다.

핵심은 일회성 답변에 그치지 않고 재사용 가능한 도구, 즉 '위젯'을 만드는 것이다. 위젯은 UI·API·쿼리를 모두 담은 샌드박스 코드다. 한 번 만들면 LLM이 더는 개입하지 않고, 새로고침할 때마다 실제 쿼리만 다시 실행한다. 그래서 보안 제품 '레이더'가 특정 사용자를 왜 차단했는지 같은 질문도, 지원팀이 SQL을 공유받아 돌릴 필요 없이 이미 만들어진 위젯에서 자신이 직접 검색해 확인한다. 같은 질문을 자주 받으면 위젯으로 만들어 사내에 공유하는 식으로 도구가 자생적으로 쌓인다.

갤로우는 이 시스템을 쓸 만하고 신뢰할 수 있게 만든 세 가지를 정리한다. 첫째 시퀀싱은 새 질문이 들어왔을 때 사전 점검(도구 연결 확인, 맥락 충분 여부, 부족하면 되묻기)을 거치고, 도구를 호출하기로 결정하는 그 순간에 해당 도구의 사용법 맥락(예: 스노플레이크 스키마)을 주입하는 것이다. 모든 도구 맥락을 미리 채워 컨텍스트 윈도를 터뜨리지 않기 위해서다. 둘째 레이어링은 기본 프롬프트 위에 조직 규칙과 도구별 맥락을 얹고, 빠르게 바뀌는 자사 제품에 대해서는 모델의 기존 지식을 '불신'하고 docs 같은 1차 자료를 찾게 시키는 것이다. 셋째 검증은 쿼리를 항상 실제로 실행해 데이터가 돌아오는지 확인한 뒤에야 위젯에 하드코딩하는 것이며, 개발과 운영 환경 모두에서 동일하게 평가(eval)를 돌린다.

주요 인사이트

• 비기술 직군의 질문이 SQL을 아는 사람에게 의존해 슬랙에서 일회성으로 오가는 병목은, 자연어 질문을 도구 호출로 바꾸는 에이전트와 '재사용 가능한 위젯'으로 구조적으로 풀 수 있다.
• 위젯을 LLM이 매번 실행하는 결과물이 아니라 LLM이 한 번 작성한 '선언적 코드'로 만들면, 이후 조회는 안정적이고 비용도 들지 않으며 사용자 입력도 코드가 정확히 파싱한다.
• 도구별 맥락은 미리 전부 주입하지 말고 도구를 호출하는 시점에 주입해야 컨텍스트 윈도 낭비를 막을 수 있다. RAG 없이 도구 직접 호출 위에 맥락만 얹어도 적중률이 높았다.
• 데이터 정합성 규칙(삭제되지 않은 항목만, 활성 상태만 등)을 맥락에 명시하면 LLM이 흔히 빠뜨리는 필터 누락 오류를 예방할 수 있다. 검증 단계에서 쿼리가 0건을 반환하는지까지 확인하는 것이 신뢰성의 핵심이다.
• 빠르게 바뀌는 제품에 대해서는 모델의 학습된 지식이 낡았을 수 있으므로, 모델에게 자기 지식을 불신하고 사내 문서 같은 1차 자료를 참조하도록 지시하는 것이 정확도를 높인다.

자주 묻는 질문

관련 AI 소식