마이크로소프트, Word 문서 내 AI 에이전트 도입해 변호사 신뢰 유도

Microsoft가 Word 내부에 도입한 Legal Agent는 범용 LLM이 아닌 도메인 특화 AI 에이전트의 전형적인 사례다. 일반 ChatGPT 스타일 모델이 자유 형식 프롬프트를 해석해 응답하는 방식과 달리, Legal Agent는 "구조화된 워크플로우(structured workflows)" 기반으로 동작한다. 즉 계약서 조항별 검토, 협상 이력 추적, 플레이북 대조 같은 반복 가능한 법률 업무를 사전 정의된 파이프라인으로 처리한다. 기술적으로는 Word의 tracked changes(변경 내용 추적) 기능과 통합되어 문서 상태 머신을 모델 컨텍스트로 주입하고, RAG 기반 플레이북 검색 + 조항 단위 분류기 + 편집 제안 생성기가 결합된 멀티스텝 에이전트 구조로 추정된다. 환각(hallucination)이 치명적인 법률 도메인에서 신뢰도를 확보하기 위해, 모델의 자유도를 의도적으로 제약하고 워크플로우 안에서만 추론하도록 설계한 점이 핵심이다.

엔지니어 관점에서 이 발표가 시사하는 바는 분명하다. "범용 LLM + 프롬프트 엔지니어링"으로 모든 문제를 풀던 시대에서, 도메인 워크플로우를 코드로 명시하고 LLM은 각 단계의 작은 의사결정 노드로만 사용하는 패턴이 엔터프라이즈 제품의 표준이 되어가고 있다. LangGraph, Microsoft Semantic Kernel, OpenAI Agents SDK 같은 프레임워크들이 모두 이 방향이며, Legal Agent도 같은 사상의 연장선에 있다. 또한 Office 365 생태계 안에서 동작하는 에이전트라는 점은, 사내 SaaS 통합 개발자들이 곧 Microsoft Graph API와 Copilot Studio를 통해 유사한 에이전트를 직접 빌드하거나 확장해야 한다는 것을 의미한다.

한국 개발자가 당장 취해야 할 액션은 두 가지다. 첫째, B2B 제품을 만드는 팀이라면 자사 도메인의 "반복 가능한 워크플로우"를 식별하고 이를 에이전트로 구조화하는 작업을 시작해야 한다. 단순 챗봇 형태의 LLM 래퍼는 빠르게 가치가 떨어지고 있다. 둘째, Microsoft 365를 사용하는 기업 환경에서는 Copilot Studio와 Power Platform 기반 에이전트 개발 역량이 곧 실질적인 수요가 될 가능성이 높으므로, Graph API와 에이전트 SDK 기반의 통합 개발 패턴을 익혀둘 필요가 있다. 특히 법률·금융·의료처럼 규제가 강한 도메인에서는 "결정론적 워크플로우 + LLM 보조"라는 하이브리드 아키텍처가 표준이 될 것이므로, 에이전트의 검증 가능성·감사 로그·롤백 메커니즘 설계 경험을 의식적으로 쌓아두는 것이 경쟁력이 된다.