핵심 요약 (Key Takeaways)

Rippling은 방대한 온톨로지 (Ontology) 전반에서 추론할 수 있는 AI가 필요했습니다. Rippling의 데이터 모델은 HR, IT, 급여(Payroll), 재무(Finance), 글로벌 운영 전반에 걸쳐 수천 개의 테이블과 중복되는 개념들을 포괄합니다.
Deep Agents는 Rippling AI의 멀티 에이전트 (Multi-agent) 아키텍처를 구동합니다. 감독 에이전트 (Supervisor agent)가 질문 답변, 컨텍스트 검색, 워크플로 실행을 위해 특화된 읽기(Read), RAG, 액션(Action) 에이전트들을 조정합니다.
LangSmith는 프로덕션 디버깅 및 평가를 지원합니다. Rippling은 트레이스(Traces), 계층적 평가(Layered evals), 그리고 반자동화된 셀프 힐링 루프(Semi-automated self-healing loop)를 사용하여 회귀(Regressions)를 포착하고 시간이 지남에 따라 시스템 품질을 개선합니다.

Rippling은 온보딩(Onboarding)과 복리후생부터 기기 프로비저닝(Device provisioning) 및 지출 관리까지 모든 것을 관리하는 인력 관리 플랫폼입니다. 이들의 데이터 모델은 HR, IT, 급여, 재무 및 글로벌 운영에 걸쳐 수천 개의 테이블, 수십만 개의 필드, 그리고 도메인 전반에 걸쳐 이름을 공유하는 개념들을 포함합니다. 이 모든 것을 가로질러 추론할 수 있는 AI 레이어를 구축하려면 새로운 아키텍처가 필요했습니다.

현재 전 세계 수백만 명의 사용자에게 프로덕션 환경으로 제공되고 있는 Rippling AI는 LangChain Deep Agents와 LangSmith를 기반으로 작동합니다. 팀은 이를 약 6개월 만에 출시했습니다.

문제: 방대한 온톨로지 상에서의 교차 도메인 AI (Cross-Domain AI)

Rippling 사용자들은 많은 도메인에 걸쳐 매우 다양한 질문을 던집니다. “내 잔액이 얼마인가요?”라는 질문은 건강 저축 계좌(HSA), 신용카드, 계약자 지급 계좌, 심지어 휴가 정책과도 관련될 수 있습니다. 관리자는 인원수(Headcount)에 대해 묻다가, 지출 분석으로 전환한 뒤, 신규 입사자의 기기 프로비저닝 상태를 확인할 수도 있습니다. Rippling의 AI 레이어는 거대하고 무정형인 표면 위에서 모호함을 해소하고 효과적으로 추론할 수 있어야 합니다.

데이터 모델이 이를 어렵게 만들었습니다. 수천 개의 테이블과 도메인 전반에 걸친 중복되는 엔티티(Entity) 이름들 때문에, 스키마 청크(Schema chunks)를 LLM에 전달하는 방식은 작동하지 않았습니다. 팀은 컨텍스트(Context)에 매몰되지 않고 도메인 간을 빠르게 추론할 수 있는 아키텍처가 필요했습니다.

개별 제품에 AI를 내장하면서, 고립된 수직적 특화 모델(vertical-specific models)로는 확장할 수 없다는 점이 명확해졌습니다. Rippling의 데이터 모델은 HR, IT, 재무 및 글로벌 운영 전반에 걸쳐 수천 개의 테이블에 걸쳐 있으며, 컨텍스트에 따라 완전히 다른 의미를 갖는 중복된 엔티티(entities)와 공유된 개념들을 포함하고 있습니다. 우리는 단순히 하나의 도메인을 최적화하는 것이 아니라, 그 전체 온톨로지(ontology)를 가로질러 모호성을 제거하고 작동할 수 있는 AI 네이티브 추론 계층(AI-native reasoning layer)이 필요했습니다.

— Laks Srini, Rippling AI 제품 소유자(Product Owner)

Rippling AI: Deep Agents + LangSmith 기반 구축

Rippling이 AI 에이전트(agents)를 통합한 속도가 가능했던 이유는 팀이 처음부터 LangChain을 사용하여 결합 가능한 에이전트 프리미티브(agent primitives)와 LangSmith의 공유 관측성 계층(observability layer)을 활용했기 때문입니다. Deep Agents가 출시되었을 때, 그들은 이를 Rippling AI의 핵심 추론 루프(reasoning loop)에 채택했습니다.

Deep Agents가 출시되자마자, 우리는 매우 강력한 에이전트 추론 루프(agentic reasoning loop)를 갖는 것이 우리에게 얼마나 도움이 될지 확인하기 위해 이를 사용하고 싶었습니다. 그것은 우리가 맺어온 관계와 우리가 신뢰하는 기술의 연속이었습니다.

— Sahin Olut, Rippling AI 수석 엔지니어(Principal Engineer)

그들이 정착한 아키텍처는 5~7개의 특화된 하위 에이전트(subagents)를 조정하는 감독 에이전트(supervisor agent)이며, LangSmith가 트레이싱(tracing), 평가(evaluations) 및 프로덕션 모니터링(production monitoring)을 담당합니다.

작동 방식: Deep Agents의 멀티 에이전트 시스템(Multi-Agent System)

고객은 Rippling 포털 및 모바일 앱 내의 채팅 인터페이스를 통해 Rippling AI와 상호작용하지만, 이는 단순한 텍스트 박스 그 이상입니다. 구조화된 데이터는 정렬 및 필터링이 가능한 테이블로 렌더링됩니다. 다중 선택형 명확화(clarifications)는 선택 UI로 나타납니다. 작업 확인(Action confirmations)에는 전용 상호작용 패턴이 적용됩니다.

내부적으로 Rippling AI는 멀티 에이전트 시스템입니다. 감독 에이전트 아래에는 세 가지 유형의 특화된 Deep Agents가 배치되어 있습니다:

**Read agents (읽기 에이전트)**는 Rippling의 모든 제품 영역(HR, 급여(payroll), IT, 재무(finance)) 및 Salesforce, Carta, GitHub와 같은 연결된 플랫폼 전반에 걸쳐 구조화된 데이터(structured data)를 쿼리합니다.

**RAG agents (RAG 에이전트)**는 비구조화된 소스, 즉 Rippling에 호스팅된 고객 센터 문서, 회사 핸드북, HR 정책 문서 등에서 정보를 검색(retrieve)합니다.

**Action agents (액션 에이전트)**는 Rippling 내에서 쓰기 작업(write operations)을 실행합니다. 예를 들어, 보너스 업로드, 직함 및 레벨링 구조의 정규화(normalizing), 또는 이전 직원 프로필로부터 사전 채워진(pre-populated) 신규 입사자 처리 등을 수행합니다.

**supervisor agent (감독 에이전트)**는 최상단에 위치하여 들어오는 쿼리를 분석하고 어떤 특화된 에이전트(또는 에이전트 조합)를 호출할지 결정하는 기본 추론 루프(reasoning loop)를 운영합니다.

Context Engineering (컨텍스트 엔지니어링): 가장 어려운 문제

Rippling의 복잡성과 규모를 고려할 때, 컨텍스트 엔지니어링(context engineering)은 핵심적인 기술적 과제였습니다. 팀은 이를 해결하기 위해 세 가지 패턴을 개발했습니다.

Dynamic skill injection (동적 기술 주입)

Rippling은 컨텍스트 팽창(context bloat)을 줄이기 위해 Deep Agents 미들웨어를 사용합니다. 사용자가 질문을 하면, 검색 단계에서 Rippling의 시맨틱 레이어(semantic layer)를 사용하여 관련 도메인을 먼저 식별한 다음, 해당 도메인(급여, 기기, ATS, 지출 등)에 범위가 지정된 기술(skill)을 주입합니다. 리랭커(Re-rankers)가 공격적으로 가지치기(prune)를 수행하여 컨텍스트 크기를 100배에서 500배까지 줄입니다.

"전체 내용을 컨텍스트에 넣으려고 하면, 심지어 그 일부(chunk)만 넣으려고 해도 상충하는 엔티티(entities)가 너무 많아서 Rippling 고객들이 기대하는 시간 내에 컨텍스트 창(context window)에 다 담을 수가 없습니다."

— Sahin Olut, Principal Engineer

Code execution for write operations (쓰기 작업을 위한 코드 실행)

LLM에게 데이터를 직접 조작하도록 요청하는 대신, Rippling의 액션 에이전트는 샌드박스화된 코드 실행(sandboxed code execution)을 사용하여 입력값(예: 클라이언트로부터 받은 CSV)을 Rippling의 내부 도구가 기대하는 형식으로 정규화합니다. 이는 "무엇을 할 것인가"(LLM 추론)와 "어떻게 형식을 맞출 것인가"(결정론적 코드, deterministic code)를 분리하여, 데이터 정규화를 신뢰할 수 있고 감사 가능(auditable)하게 유지합니다.

Variable pinning via a REPL (REPL을 통한 변수 고정)

팀의 가장 날카로운 통찰 중 하나는 LLM(Large Language Models)이 긴 영숫자 ID(alphanumeric IDs)를 암송할 때 환각(hallucinate)을 일으키는 것을 관찰하는 데서 나왔습니다. 이들의 해결책은 REPL을 통해 에이전트 단계(agent steps) 사이에 런타임 변수 저장소(runtime variable store)를 유지하는 것이었습니다. 에이전트는 도구 호출(tool calls) 시 원시 엔티티 문자열(raw entity strings)을 전달하는 대신 이름이 지정된 변수(named variables)를 참조합니다.

LangSmith를 통한 관측 가능성(Observability) 및 평가(Evals)

모든 엔지니어가 단일 AI 시스템에서 작업함에 따라, 팀이 협업하는 방식에 있어 공유되고 쿼리 가능한 트레이스 저장소(trace store)는 필수적입니다.

모든 대화를 대규모로 추출하고 분석할 수 있는 능력… LangSmith가 그것을 가능하게 합니다. 우리는 그 위에서 실행되는 일련의 자동화된 분석 도구들을 보유하고 있습니다.

— Laks Srini, Product Owner

자가 치유 평가 루프 (Self-Healing Eval Loop)

팀은 회귀(regressions)를 포착하고 이를 해결하는 반자동 루프를 구축했습니다. 먼저, LangSmith에서 실패한 프로덕션 트레이스(production traces)를 가져옵니다. 에이전트가 실패 원인을 분석하고, 수정안을 제안하며, 개선 사항을 확인하기 위해 평가(evals)를 재실행하며, 회귀 문제가 해결될 때까지 반복합니다. 마지막으로, 사람이 결과물인 PR(Pull Requests)을 검토하고 병합합니다.

우리는 실패한 트레이스를 가져와서, 에이전트가 무슨 일이 일어나고 있는지 이해하게 하고, 몇 가지 해결책을 제안하게 한 뒤, 개선되었는지 확인하기 위해 평가를 다시 실행하며, 완료될 때까지 루프를 돌립니다. 시스템의 모든 지점에 API가 있기 때문에 LangSmith가 이를 가능하게 합니다.

— Sahin Olut, Principal Engineer

평가 파이프라인 (The Eval Pipeline)

팀은 계층화된 평가 시스템을 운영하며, 모든 결과는 LangSmith에 업로드됩니다:

오프라인 평가 (Offline evals): 외부 의존성 없이 모든 커밋(commit) 시 로컬에서 실행되는 사전 기록된 모의 데이터(mocks) 및 픽스처(fixtures).

병합 후 통합 평가 (Post-merge integration evals, 온라인): 배포 전 시스템 상태를 검증하기 위해 전체 Rippling 샌드박스(라이브 API 호출)를 대상으로 수행하는 300~400개의 쿼리.

배포 차단 평가 (Deploy-blocking evals, 온라인): 모든 배포를 제어하기 위해 실제 시스템을 대상으로 수행하는 약 30개의 핵심 시나리오.

지속적 평가 (Continuous evals, 온라인): 라이브 시스템 상태를 모니터링하기 위해 매일 여러 차례 프로덕션 데이터를 대상으로 예약 실행되는 작업.

다음 단계: LangSmith를 통한 지속적인 개선

전 세계적으로 100만 명 이상의 사용자가 Rippling AI를 사용하고 있습니다. 모든 대화는 LangSmith를 통해 흐르며, 품질 추적(quality tracking), 사용자 피드백, 그리고 개선의 지속적인 루프(continuous loop)를 형성합니다.

복잡하고 권한에 민감한 플랫폼에서 AI를 구축하는 팀들을 위해, Rippling 팀은 다음과 같이 명확한 조언을 건넵니다:

LLM(Large Language Models)이 이미 익숙한 시스템을 구축하십시오. 에이전트(agents)를 여러분의 동료라고 생각하고, 그들이 성공할 수 있도록 최고의 도구를 만들어 주어야 합니다. 코드 실행(code execution)을 가능하게 하고, SQL 작성을 가능하게 하며, LLM으로부터 세부 사항을 숨기지 마십시오. 그리고 긴밀한 자체 디버깅 루프(self-debugging loop)를 갖추어야 합니다.

— Sahin Olut, Principal Engineer

*Deep Agents는 Rippling AI의 추론 프레임워크(reasoning framework)입니다. 작동 방식 보기 | *문서 읽기