Glean ADLC 공개, 에이전트도 SDLC가 필요해졌다

AI 요약

• 무슨 일: Glean이 5월 12일 Agent Development Lifecycle을 공개하고 Work AI 플랫폼에 직접 통합한다고 발표했습니다.
  • ADLC는 Opportunity, Design, Performance, Context, Develop, Launch, Monitor & Improve의 7단계로 에이전트를 소프트웨어처럼 다룹니다.
• 의미: 기업 AI의 경쟁 축이 "더 똑똑한 챗봇"에서 ROI, 권한, 테스트, 출시, 관측을 갖춘 운영 체계로 이동하고 있습니다.
• 실무 영향: Auto-mode, trace view, sub-agent, sandbox, access policy는 에이전트 빌더보다 플랫폼 운영자의 언어에 가깝습니다.
• 주의점: Glean의 ROI 수치는 공식 주장입니다. 독립 검증보다 중요한 질문은 각 조직이 같은 방식으로 성공 기준을 정의할 수 있느냐입니다.

Glean이 2026년 5월 12일 공식 블로그에서 Agent Development Lifecycle, 줄여서 ADLC를 공개했습니다. 이름만 보면 또 하나의 프레임워크처럼 보입니다. 하지만 이 발표가 흥미로운 이유는 따로 있습니다. Glean은 에이전트를 "똑똑한 챗봇"이나 "자동화 데모"가 아니라, 소프트웨어 제품처럼 기획하고, 테스트하고, 출시하고, 모니터링하고, 개선해야 한다고 말합니다.

이 관점은 최근 기업 AI 시장의 흐름과 잘 맞물립니다. 지난 며칠 사이 Microsoft는 Agent 365를 일반 제공으로 밀고, ServiceNow는 AI Control Tower를 확장하고, SAP은 Joule 에이전트를 ERP 프로세스 안으로 넣고, Cursor는 Teams 통합을 통해 코딩 에이전트를 협업 채널에 붙였습니다. 모두 같은 문제를 향합니다. 에이전트는 더 이상 개인이 한 번 실행해 보는 도구가 아니라, 조직 안에서 권한을 갖고, 업무 시스템을 읽고, 때로는 쓰기까지 하는 실행 단위가 되고 있습니다.

그 순간 질문이 바뀝니다. "어떤 모델이 더 똑똑한가"보다 "이 에이전트를 누가 승인했는가", "무엇을 바꾸도록 허용했는가", "실패했을 때 어디서 멈추는가", "투입 대비 성과를 어떻게 측정하는가"가 더 중요해집니다. Glean ADLC는 바로 이 지점에 꽂힌 발표입니다.

Glean이 말한 핵심, 에이전트를 소프트웨어처럼 다뤄라

Glean의 공식 발표는 CIO들이 이미 생산성 도구나 각 사업부 안에서 에이전트를 쓰고 있지만, 전체 ROI를 물으면 여전히 숫자를 정리하지 못하는 경우가 많다고 진단합니다. 에이전트가 여기저기 생기지만 전략이 없고, 서로 다른 팀이 제각각의 방식으로 만들며, 누가 책임지는지 모호해지는 현상을 Glean은 AI sprawl로 봅니다.

그래서 Glean은 에이전트를 소프트웨어처럼 다루자고 말합니다. 소프트웨어 시스템에는 요구사항, 권한, 데이터 의존성, 테스트, 배포, 운영, 장애 대응, 폐기 절차가 있습니다. 기업용 에이전트도 마찬가지입니다. 문서와 티켓을 읽고, 캘린더를 조정하고, CRM 필드를 업데이트하고, 슬랙이나 이메일로 메시지를 보내는 순간, 에이전트는 단순한 답변 생성기가 아닙니다. 사내 시스템의 실행 경로가 됩니다.

Glean이 제시한 ADLC는 7단계입니다.

이 표를 보면 Glean의 방향이 분명해집니다. ADLC는 개발자에게 "에이전트를 이렇게 코딩하라"는 튜토리얼이 아닙니다. 오히려 제품 리더, 보안 팀, IT 관리자, 현업 담당자, 데이터 소유자가 같은 화면을 보게 만드는 운영 언어에 가깝습니다. 에이전트가 업무 시스템을 건드리기 시작하면, 프롬프트 한 줄보다 책임 경계가 더 중요해집니다.

새 기능은 모두 이 수명주기에 붙어 있습니다

이번 발표에서 Glean은 ADLC를 추상 개념으로만 두지 않았습니다. Work AI 플랫폼에 기능을 붙였습니다. Auto-mode agents는 일반 제공으로 전환됐고, debug and trace views, sub-agents, agent sandbox, agent library, access policies, agent insights가 함께 공개됐습니다.

Auto-mode agents는 사용자가 원하는 목표를 설명하면 Glean이 기업 그래프, 가드레일, 관리형 액션 안에서 계획하고 추론하고 실행하는 방식입니다. 이것은 기존 워크플로 빌더와 다릅니다. 미리 모든 단계를 수동으로 정의하기보다, 의도에서 테스트 가능한 에이전트로 더 빨리 가는 경로를 노립니다.

하지만 Auto-mode가 강해질수록 운영자는 더 많은 가시성을 요구합니다. 그래서 trace view가 중요합니다. 에이전트는 실패할 때 "마지막 답변이 틀렸다" 수준으로만 실패하지 않습니다. 잘못된 입력을 가져왔을 수도 있고, 중간 도구 호출이 엉켰을 수도 있고, 조건 분기가 잘못됐을 수도 있습니다. Glean은 debug view가 입력, 도구 호출, 의사결정 단계를 보여준다고 설명합니다. 이는 에이전트 운영에서 로그와 트레이싱이 기본 인프라가 된다는 뜻입니다.

Sub-agent도 같은 맥락입니다. 하나의 거대한 에이전트가 모든 업무를 처리하는 구조는 유지보수하기 어렵습니다. Glean은 재사용 가능한 하위 에이전트를 호출하는 방식을 제시합니다. 개발자에게 익숙한 모듈화가 에이전트 설계에도 들어오는 셈입니다. 흥미로운 점은 이 기능이 "더 복잡한 에이전트"를 만들기 위한 기능이면서 동시에 "더 관리 가능한 에이전트"를 만들기 위한 기능이라는 점입니다.

Agent sandbox는 더 직접적인 실행 환경입니다. Glean은 각 자율 에이전트에 안전한 비공개 런타임 환경을 제공해, 긴 작업의 중간 산출물을 파일 시스템에 정리하거나 언어 모델 추론만으로는 안정적이지 않은 계산을 코드 인터프리터로 처리할 수 있다고 설명합니다. 이는 코딩 에이전트에서 익숙해진 샌드박스 개념이 업무 에이전트에도 들어오는 흐름입니다.

Agent library와 access policies는 운영 계층입니다. 에이전트 수가 늘어나면 발견 가능성 자체가 문제가 됩니다. 어떤 에이전트가 검증됐는지, 누가 볼 수 있는지, 어떤 범주의 업무에 쓰는지, 너무 최근에 만든 미검증 에이전트가 조직 전체에 노출되는지 관리해야 합니다. Glean은 라이브러리에서 관리자 검증과 큐레이션을 강조합니다. Access policies는 더 민감합니다. 예를 들어 인턴이 에이전트로 system of record에 쓰기 작업을 하지 못하게 하는 식의 조직 전체 가드레일입니다.

이 조합은 Glean이 단순히 "에이전트를 더 쉽게 만들 수 있다"가 아니라 "에이전트 포트폴리오를 운영할 수 있다"고 말하고 있음을 보여줍니다.

왜 지금 ADLC인가

에이전트 시장은 이미 빌더 공급 과잉에 들어갔습니다. OpenAI Agents SDK, LangGraph, CrewAI, Microsoft Copilot Studio, Salesforce Agentforce, SAP Joule Studio, ServiceNow AI Agent Studio, Google Workspace와 Vertex AI 쪽 도구까지 각자 에이전트를 만들 수 있다고 말합니다. 문제는 만드는 능력만으로는 충분하지 않다는 것입니다.

기업 내부에서는 에이전트 하나가 단순한 함수 호출보다 넓은 표면적을 갖습니다. 데이터 권한, SaaS 커넥터, 승인 절차, 사용자 피드백, 감사 로그, 비용, 환각, 프롬프트 인젝션, 업무 KPI가 모두 얽힙니다. 실패도 한 종류가 아닙니다. 틀린 답변, 잘못된 레코드 수정, 과도한 권한 요청, 비용 폭주, 중복 에이전트 난립, 아무도 쓰지 않는 자동화가 모두 실패입니다.

이때 ADLC는 새로운 기술이라기보다 정리된 경고입니다. 에이전트를 많이 만들 수 있게 된 조직일수록, 무엇을 만들지 고르는 체계가 먼저 필요합니다. Glean이 Opportunity와 Performance를 앞단에 놓은 이유도 여기에 있습니다. 에이전트 프로젝트가 실패할 때 가장 흔한 이유는 모델이 부족해서가 아니라, 풀어야 할 업무 문제가 흐리고, 성공 기준이 없고, 실제 사용자 워크플로에 들어가지 못했기 때문입니다.

Glean은 공식 발표에서 ADLC가 Zillow, Ericsson, Motive 같은 고객의 주간 수백만 건 에이전트 실행을 확장하는 데 쓰였다고 말합니다. 또 Glean 내부 엔지니어링 팀의 단일 에이전트가 연간 17,000시간 이상과 170만 달러 이상의 ROI를 회수했다고 주장합니다. 이 수치는 독립적으로 검증된 감사 보고서가 아니라 벤더의 공식 주장입니다. 그래서 그대로 시장 전체의 평균값처럼 받아들이면 안 됩니다. 다만 이 수치가 가리키는 방향은 중요합니다. 기업 AI 판매 언어가 "정확도"에서 "회수 시간과 비용"으로 바뀌고 있습니다.

Glean의 5월 제품 업데이트와 연결되는 지점

ADLC 발표 일주일 전인 5월 5일, Glean은 "enterprise AI coworker"라는 방향의 제품 업데이트를 공개했습니다. 여기에는 personalized activity cards, Skills, write tools, Adaptive Reasoning, voice, Canvas revision view, Library가 포함됐습니다. ADLC는 이 제품 업데이트를 운영 모델로 감싸는 역할을 합니다.

예를 들어 Skills는 반복 가능한 실행 논리를 패키징하는 기능입니다. Glean은 Skills가 개인과 팀의 업무 방식에 맞춰 재사용 가능한 지침, 구조, 도구를 제공한다고 설명합니다. 이는 ADLC의 Develop 단계와 잘 맞습니다. 반복 업무를 매번 프롬프트로 재구성하는 대신, 검증 가능한 실행 단위로 포장하는 것입니다.

Write tools는 더 민감합니다. Glean은 Microsoft 365, Outlook, Teams, Gmail, Google Drive, Slack 같은 여러 애플리케이션에서 데이터를 편집할 수 있고, 실행 전에 명확한 preview를 제공한다고 설명합니다. 에이전트가 읽기 전용 검색에서 쓰기 작업으로 넘어가면 Launch와 access policy가 핵심이 됩니다. 누가 승인해야 하는지, 어떤 시스템에는 쓰기 금지인지, 어떤 데이터 변경은 preview만 하고 자동 실행하지 않을지 정해야 합니다.

Adaptive Reasoning은 각 작업에 필요한 추론 수준과 모델 선택을 자동 조정하는 기본 모드입니다. 이는 비용과 품질의 문제입니다. 모든 업무를 가장 비싼 모델과 긴 추론으로 처리하면 비용이 맞지 않습니다. 반대로 중요한 업무를 가벼운 모드로 처리하면 위험합니다. 이 선택을 플랫폼이 대신한다면, 조직은 그 결정이 어떤 지표로 이루어지는지 관측하고 검증할 필요가 있습니다.

Glean 문서의 에이전트 구조도 이 흐름을 뒷받침합니다. Glean Agents는 trigger, steps, actions, flow, memory로 구성됩니다. Flow에서는 조건 분기와 sub-agent 호출을 지원하고, memory는 실행 중 단계별 산출물을 저장해 후속 단계가 재사용할 수 있게 합니다. 이 구조는 에이전트가 단순한 채팅 세션이 아니라 상태를 가진 업무 프로세스라는 점을 보여줍니다.

경쟁 구도, 관제탑과 수명주기의 차이

최근 기업 AI 발표들을 한 줄로 묶으면 "에이전트의 제어 계층"입니다. Microsoft Agent 365는 에이전트를 사람처럼 식별하고 관리하는 control plane을 말합니다. ServiceNow AI Control Tower는 비즈니스 워크플로 안에서 AI 에이전트를 관측하고 제어하려 합니다. SAP은 Joule Studio와 Business AI Platform으로 ERP 프로세스에 에이전트를 심습니다. UiPath는 코딩 에이전트를 기업 오케스트레이션에 연결한다고 말합니다.

Glean ADLC는 이들과 겹치면서도 초점이 다릅니다. 관제탑이 "이미 움직이는 에이전트를 어떻게 볼 것인가"에 가깝다면, ADLC는 "어떤 에이전트를 왜 만들고 어떻게 제품화할 것인가"에 더 가깝습니다. 물론 Glean도 access policy와 insights를 제공합니다. 하지만 발표의 핵심 단어는 보안 관제가 아니라 수명주기와 ROI입니다.

이 차이는 Glean의 출발점과도 관련이 있습니다. Glean은 기업 검색과 지식 그래프에서 출발했습니다. 따라서 에이전트의 핵심 자산을 모델보다 "회사 맥락"으로 봅니다. Glean의 에이전트가 강해지려면 기업 데이터의 권한 구조, 사람과 프로젝트의 관계, 업무 산출물, SaaS 커넥터가 잘 정리돼 있어야 합니다. ADLC의 Context 단계가 별도 단계로 들어간 것도 우연이 아닙니다.

다만 이 포지션에는 위험도 있습니다. Microsoft, Google, Salesforce, ServiceNow 같은 대형 플랫폼은 이미 조직의 핵심 업무 시스템을 쥐고 있습니다. 이들이 검색, 메모리, 에이전트 라이브러리, 접근 정책을 빠르게 흡수하면 Glean 같은 독립 Work AI 플랫폼은 "중립적 지식 계층"이라는 차별화를 계속 입증해야 합니다. Reddit과 SaaS 커뮤니티에서 Glean의 장기 생존 가능성을 두고 논쟁이 나오는 이유도 이 때문입니다.

개발자와 AI 팀이 봐야 할 포인트

개발자에게 이번 발표의 의미는 "Glean을 써야 한다"가 아닙니다. 더 중요한 것은 에이전트 프로젝트의 체크리스트가 바뀌고 있다는 점입니다. 지금까지 에이전트를 만들 때는 모델, 도구 호출, 프롬프트, RAG, 메모리 정도가 주요 설계 항목이었습니다. 이제는 여기에 운영 항목이 들어와야 합니다.

첫째, 에이전트마다 명확한 업무 단위가 있어야 합니다. 티켓 하나를 처리하는가, 고객 통화 묶음을 분석하는가, 주간 보고서를 만드는가, 시스템 레코드를 수정하는가를 정해야 합니다. 업무 단위가 흐리면 평가도 흐려집니다.

둘째, 성공 지표를 에이전트 출력 품질만으로 두면 부족합니다. 처리 시간, 사용자 승인율, 되돌림 비율, 오류 유형, 비용, 실제 업무 KPI를 함께 봐야 합니다. Glean이 Performance 단계를 따로 둔 이유가 여기에 있습니다.

셋째, context를 최소 권한으로 설계해야 합니다. 에이전트는 더 많은 데이터를 주면 똑똑해질 수 있지만, 동시에 더 많은 위험 표면을 가집니다. 어떤 문서, 어떤 레코드, 어떤 도구, 어떤 쓰기 권한이 필요한지 좁혀야 합니다.

넷째, trace와 sandbox는 선택 기능이 아니라 운영 기본값이 됩니다. 에이전트가 중간에 어떤 판단을 했는지 볼 수 없으면, 실패를 고칠 수 없습니다. 긴 작업에서 중간 산출물을 다루는 환경이 없다면, 재현성과 감사 가능성도 떨어집니다.

다섯째, 라이브러리와 폐기 정책이 필요합니다. 조직 안에 에이전트가 10개일 때는 검색하지 않아도 됩니다. 100개가 넘으면 아무도 어떤 에이전트가 검증됐는지 모릅니다. 오래된 에이전트, 중복 에이전트, 더 이상 쓰이지 않는 에이전트를 어떻게 숨기거나 폐기할지도 제품 운영의 일부가 됩니다.

데모의 시대에서 운영의 시대로

Glean ADLC 발표는 모델 성능 경쟁처럼 화려하지 않습니다. 하지만 기업 AI 시장에서는 이런 발표가 더 오래 남을 수 있습니다. 에이전트가 실제 업무 시스템을 움직이기 시작하면, 가장 큰 병목은 "한 번 잘 되는 데모"가 아니라 "계속 안전하게 돌아가는 운영 체계"가 됩니다.

Glean이 맞는지, Microsoft나 ServiceNow의 control plane이 맞는지, SAP처럼 업무 애플리케이션 내부에 심는 방식이 맞는지는 조직마다 다를 것입니다. 하지만 방향은 분명해 보입니다. 에이전트는 이제 독립 실행형 챗봇이 아니라, 조직의 소프트웨어 포트폴리오에 들어가는 실행 단위입니다. 그렇다면 에이전트에도 요구사항, 테스트, 배포, 관측, 개선, 폐기가 필요합니다.

ADLC라는 이름이 표준으로 남을지는 알 수 없습니다. 다만 Glean이 던진 질문은 유효합니다. 여러분의 조직에 있는 에이전트는 누가 만들었고, 무엇을 바꾸며, 어떤 기준으로 성공했고, 실패하면 어디서 멈춥니까? 이 질문에 답하지 못한다면 에이전트는 생산성 도구가 아니라 관리되지 않는 그림자 자동화가 됩니다. 2026년의 기업 AI 경쟁은 더 많은 에이전트를 만드는 쪽이 아니라, 더 오래 운영 가능한 에이전트를 만드는 쪽으로 이동하고 있습니다.