PropTech 플랫폼을 위한 에이전트 기반 오케스트레이션 레이어 구축

Bolt-On LLM 기능의 문제점

대부분의 PropTech 플랫폼은 동일한 방식으로 AI 여정을 시작했습니다. 여기에는 챗봇이 있고, 저기에는 문서 요약기가 있으며, 하나의 워크플로우에 연결된 임대 계약 조항 추출기가 있습니다. 각 기능은 개별적으로 작동하지만, 서로 통신하거나 문맥(Context)을 공유하거나 더 큰 무언가로 구성되지 않습니다. 그 결과, 유지 관리 비용이 많이 들고 거버넌스(Governance)를 구축하는 것이 불가능한 점 단위 솔루션(Point solutions)의 짜깁기 형태가 됩니다.

다음 단계의 성숙도는 **에이전트 기반 오케스트레이션 레이어(Agentic orchestration layer)**입니다. 이는 특화된 AI 에이전트들을 조정하고, 시스템 기록(Systems of record)에 대한 안전한 접근 권한을 부여하며, 다단계 부동산 워크플로우를 엔드 투 엔드(End-to-end)로 실행하는 단일 제어 평면(Control plane)입니다. 이것이 VSBD가 실제 운영 중인 PropTech 플랫폼을 위해 구축한 아키텍처이며, 우리의 PropTech 2026 Awards 후보 지명 뒤에 숨겨진 작업입니다.

여기서 "에이전트 기반(Agentic)"이 실제로 의미하는 것

에이전트란 목표(Goal), 호출할 수 있는 도구 세트, 그리고 어떤 도구를 어떤 순서로 사용할지 결정할 수 있는 자율성을 부여받은 LLM을 말합니다. "에이전트 기반 오케스트레이션(Agentic orchestration)"은 개별 에이전트 상위의 레이어로, 목표를 분해하고, 하위 작업(Sub-tasks)을 적절한 전문 에이전트에게 라우팅하며, 공유 상태(Shared state)와 메모리(Memory)를 관리하고, 경계를 넘나드는 모든 것에 대해 가드레일(Guardrails)을 적용합니다.

이 사고 모델은 단일 메가 프롬프트(Mega-prompt)가 아니라 제어 평면(Control plane)입니다:

(원문 기사의 다이어그램.)

모든 오케스트레이션 레이어에 필요한 5가지 구성 요소

1. 오케스트레이터(The orchestrator). 이것은 목표를 수신하고, 이를 단계별로 나누며, 어떤 에이전트가 각 단계를 처리할지 결정하는 두뇌입니다. 가능한 한 결정론적(Deterministic)으로 유지하십시오. 신뢰성과 감사 가능성(Auditability) 측면에서는 명시적인 라우팅 규칙과 상태 머신(State machines)이 완전히 자율적인 플래너(Planner)보다 뛰어납니다. 개방형 계획(Open-ended planning)은 진정으로 모호한 경우를 위해 남겨두십시오.

2. 전문화된 에이전트 (Specialized agents). 임대차 계약서에서 정보를 분류하고 추출하는 문서 에이전트(Document agent)는 비교 사례(Comparables)를 바탕으로 추론하는 가치 평가 에이전트(Valuation agent)와는 완전히 다른 영역입니다. 집중된 도구 세트(Tool sets)와 정교한 프롬프트(Prompts)를 갖춘 좁은 범위의 에이전트(Narrow agents)가 모든 것을 수행하려는 하나의 범용 에이전트(Generalist agent)보다 더 뛰어난 성능을 발휘합니다. 또한 이들은 개별적으로 평가하고 개선하기가 훨씬 쉽습니다.

3. 타입이 지정된 도구 계약 (Typed tool contracts). 에이전트가 수행할 수 있는 모든 작업 — CRM 조회, 이메일 초안 작성, 계약업체 일정 예약 등 — 은 검증된 입력 및 출력 스키마(Schema)를 가진 도구(Tool)로 노출됩니다. 이는 여러분이 내릴 수 있는 가장 중요한 신뢰성 관련 결정입니다. 타입이 지정된 계약(Typed contracts)은 "모델이 이상한 말을 했다"는 상황을 데이터 오염이 아닌, 포착된 검증 오류(Validation error)로 전환해 줍니다.

4. 공유 메모리 및 상태 (Shared memory and state). 에이전트에게는 현재 작업을 위한 단기 작업 메모리(Short-term working memory)와 더 장기적인 컨텍스트(이 세입자, 이 부동산, 이 포트폴리오)가 필요합니다. 모든 것을 프롬프트(Prompt)에 밀어 넣기보다는, 오케스트레이터(Orchestrator)가 소유한 저장소로 상태(State)를 외부화하십시오. 이를 통해 토큰 비용(Token costs)을 제한하고 실행 과정을 재현(Replayable) 가능하게 유지할 수 있습니다.

5. 가드레일 및 승인 레이어 (The guardrail and approval layer). 에이전트와 기록 시스템(Systems of record) 사이에는 검증, 정책 집행, 그리고 인간 참여(Human-in-the-loop) 게이트로 구성된 띠(Band)가 존재합니다. 결제 전송, 문서 서명, 세입자에게 이메일 발송과 같이 되돌릴 수 없거나 가치가 높은 작업은 인간의 확인을 위해 일시 중지됩니다. 에이전트가 제안하고, 사람이 승인합니다.

부동산이 에이전트 기반 워크플로우(Agentic Workflows)에 완벽하게 부합하는 이유

부동산 운영은 단계가 많고, 문서 중심적이며, 시스템 간을 넘나드는 워크플로우로 가득 차 있습니다. 이러한 워크플로우는 하드코딩(Hard-code)하기에는 변동성이 너무 크지만, 수작업으로 계속하기에는 너무 반복적입니다. 세입자 온보딩(Tenant onboarding)을 예로 들어보겠습니다. 신청서 파싱(Parse), 소득 증빙 서류 확인, 제3자 API를 통한 배경 조사 실행, 임대차 계약서 생성, 서명을 위한 경로 지정, 그리고 액세스 권한 부여까지. 이는 5개의 시스템과 4가지 유형의 문서가 관여하는 과정이며, 오케스트레이션 레이어(Orchestration layer)가 단일한 감독 하의 실행(Supervised run)으로 통합할 수 있는 전형적인 워크플로우입니다.

유럽 및 미국의 PropTech 플랫폼 전반에서 확인되는 다른 고가치 대상들은 다음과 같습니다:

• 포트폴리오 규모의 임대차 계약 요약 (Lease abstraction at portfolio scale) — 수천 개의 계약서에서 주요 조건, 날짜, 의무 사항을 추출하여 구조화된 데이터 (structured data)를 자산 관리 시스템 (asset management system)으로 전송합니다.

• 유지보수 분류 및 배정 (Maintenance triage and dispatch) — 유입된 요청을 분류하고, 서비스 수준 협약 (SLA)을 확인하며, 가용 가능한 계약업체를 찾아 일정을 예약합니다. 단, 비용 임계값(cost threshold)을 초과하는 사항은 반드시 인간의 승인을 거칩니다.

• 가치 평가 및 비교 사례 수집 (Valuation and comps assembly) — 시장 데이터를 수집하고, 유사 거래 사례를 검색하며, 분석가가 검토할 수 있도록 방어 가능한 가치 평가 서사 (valuation narrative) 초안을 작성합니다.

• 임차인 커뮤니케이션 (Tenant communication) — 유입되는 임차인 문의에 대해 근거가 확실하고 정책 검토가 완료된 답변 초안을 작성하며, 민감한 사항은 인간에게 에스컬레이션 (escalating) 합니다.

구축(Build)인가, 부가 기능(Bolt-On)인가: 아키텍처 결정

기존 서비스 내부에 LLM 호출을 계속 추가하고 싶은 유혹이 생길 수 있습니다. 이는 두 기능이 컨텍스트 (context)를 공유하거나 협업해야 할 필요가 생기기 전까지는 작동합니다. 하지만 그 시점이 되면 중앙 오케스트레이터 (orchestrator)의 부재가 장벽이 됩니다. 오케스트레이션 레이어 (orchestration layer)에 조기에 투자한다는 것은, 새로 추가되는 모든 에이전트 (agent)가 또 다른 고립된 섬이 되는 대신 기존에 있는 에이전트들과 결합(compose)될 수 있음을 의미합니다.

오케스트레이션 레이어는 거버넌스 (governance)가 구현되는 곳이기도 합니다. 감사인과 컴플라이언스 (compliance) 팀은 "AI가 결정했습니다"라는 말을 듣고 싶어 하지 않습니다. 그들은 추적 기록 (trace)을 원합니다: 무엇이 실행을 트리거했는지, 에이전트가 무엇을 제안했는지, 어떤 데이터에 근거했는지, 누가 해당 작업을 승인했는지, 그리고 무엇이 변경되었는지를 말입니다. 컨트롤 플레인 (control plane)은 이를 무료로 제공하지만, 여기저기 흩어진 LLM 호출은 결코 이를 제공할 수 없습니다.

시작하는 방법

첫날부터 모든 것을 오케스트레이션할 필요는 없습니다. 고통스럽고, 반복적이며, 여러 시스템을 가로지르는 워크플로우를 하나 선택하십시오. 임차인 온보딩 (tenant onboarding)과 임대차 계약 요약 (lease abstraction)이 흔한 첫 번째 성공 사례입니다. 그리고 오직 그 워크플로우를 중심으로 오케스트레이터, 한두 개의 에이전트, 타입이 지정된 도구 계약 (typed tool contracts), 그리고 인간 승인 게이트 (human-approval gate)를 구축하십시오. 첫 실행부터 관측성 (observability)과 평가 (evals) 체계를 갖추어야 합니다. 일단 패턴이 증명되면, 추가되는 모든 에이전트는 점진적인 확장이 됩니다.

VSBD는 유럽과 미국 전역의 PropTech 플랫폼을 위해, 첫 번째 감독된 워크플로우 (supervised workflow)부터 완전한 멀티 에이전트 제어 평면 (multi-agent control plane)에 이르기까지 에이전트 기반 오케스트레이션 레이어 (agentic orchestration layers)를 설계하고 출시합니다. 만약 단순히 또 다른 LLM 기능을 덧붙일지, 아니면 레이어를 제대로 구축할지 고민 중이라면, 저희가 그 결정을 내릴 수 있도록 도와드릴 수 있습니다.

원문은 VSBD 블로그에 게시되었습니다.