구성된 에이전트 vs 엔지니어링된 에이전트: 코드로 AI 에이전트를 구축할 때 무엇이 달라지는가

저는 Microsoft 생태계에서 약 10년을 보냈고, 가장 최근에는 Copilot Studio에서 에이전트를 구축하고 관리하는 데 많은 시간을 할애했습니다. 그 세계에서 에이전트는 사용자가 구성하는 무언가입니다. 사용자는 지침을 설명하고, 지식과 도구를 연결하며, 채널을 선택하고, 플랫폼은 그 아래의 모든 것을 제공합니다.

그러다 한 가지 간단한 질문이 저를 괴롭히기 시작했습니다. 실제로 그 아래에는 무엇이 있는 걸까요? 제가 그것에 답할 수 없다면, 저는 다른 곳에서 구축된 에이전트를 정직하게 평가할 수 없습니다. 그리고 제가 일하는 대부분의 기업에서는 에이전트가 다른 곳에서 구축되고 있습니다. 데이터 팀은 오픈 소스 프레임워크를 사용하고, 비즈니스 유닛은 Google Cloud에서 파일럿을 진행하며, 중앙 플랫폼 팀은 여전히 하나의 인벤토리와 하나의 위험 그림을 만들어야 하는 기대를 받습니다.

그래서 저는 Google의 Agent Development Kit (ADK)과 Gemini를 사용하여 코드로 에이전트를 구축하기 시작했습니다. 이 게시물은 단계별 설정 과정이 아니며, 그것은 별도의 더 긴 워크스루입니다. 이것은 제가 첫날에 가졌으면 좋았을 정신 모델이며, 개발자 및 개발자가 무엇을 구축하는지 관리해야 하는 모든 사람들을 위해 작성되었습니다.

에이전트를 얻는 두 가지 방법
조직이 AI 에이전트를 갖게 되는 방식은 크게 두 가지가 있습니다.
첫 번째는 관리형 플랫폼에서 구성하는 것입니다. Microsoft는 Copilot Studio를 에이전트와 워크플로우를 구축하고 관리하기 위한 그래픽적이고 로우코드(low-code) 스튜디오로 설명합니다. 여기에는 분석, 평가 및 인벤토리, 역할 기반 액세스, 비용 관리를 위한 관리 계층이 포함됩니다 (Copilot Studio 개요). 사용자는 동작에 대한 결정을 내립니다. 플랫폼은 런타임, 호스팅, ID 통합에 대한 대부분의 결정을 처리합니다.

두 번째는 프레임워크로 엔지니어링하는 것입니다. Google은 ADK를 모델 비종속적(model-agnostic)이고 배포 비종속적인(deployment-agnostic) 오픈 소스 코드 우선 Python 프레임워크로 설명합니다 (PyPI의 google-adk). 사용자는 에이전트를 소프트웨어로 작성합니다. 이 프레임워크는 런타임과 규칙을 제공하지만, 어디서 실행될지, 사용자가 어떻게 로그인할지, 그리고 어떻게 모니터링될지는 이제 사용자의 아키텍처 결정 사항입니다.

추상적으로 볼 때 어느 쪽이 더 낫다고 말할 수는 없습니다. 이 둘을 비교하는 유용한 방법은 책임(responsibility)이 어디에 위치하느냐를 물어보는 것입니다.

제가 계속 주목하는 것은 마지막 행입니다. 로우코드(low-code) 에이전트는 적어도 관리자 센터(admin center)에 나타납니다. 반면, 코드 우선(code-first) 에이전트는 리포지토리와 노트북에 무기한으로 존재할 수 있으며, 작동하는 API 키가 있고 그 존재를 기록하는 곳이 없습니다.

로컬 에이전트, 원격 모델

저에게 가장 먼저 와닿은 개념은 '에이전트'와 '모델'이 서로 다른 장소에 있다는 것이었습니다.

제 개발 환경은 그래픽 카드 2GB를 탑재한 Fedora Linux 워크스테이션이며, Gemini 3.1 Flash-Lite로 보낸 첫 테스트 요청에는 유효한 응답이 돌아왔습니다. 그 카드는 최신 대규모 언어 모델(LLM)을 호스팅할 수 없었지만, 그럴 필요도 없었습니다. 에이전트 프로세스는 제 기기에서 실행됩니다: 파이썬 런타임, 지침, 도구 함수, 그리고 대화 상태가 여기서 처리됩니다. 반면, 모델은 Google의 클라우드에서 실행되며 Gemini API를 통해 HTTPS로 접근합니다. 제 워크스테이션에게 필요한 것은 데이터센터 GPU가 아니라 네트워크 연결과 파이썬 인터프리터일 뿐입니다.

대화 한 턴(turn)은 대략 다음과 같이 보입니다:

`사용자 메시지──▶ 에이전트 런타임 (로컬) │ 전송: 사용자 메시지 + 지침 + 도구 스키마 ▼ Gemini API (원격) ──▶

데이터에 적용되는 규칙은 어떻게 비용을 지불하느냐에 따라 달라집니다. Google의 Gemini API 약관은 유료 사용과 비유료 사용을 분리합니다. 비유료 사용 시 제출된 콘텐츠는 Google 제품 개선에 사용될 수 있으며 인간 검토자가 읽을 수도 있지만, 클라우드 프로젝트를 통해 청구되는 유료 사용의 경우 Google은 프롬프트와 응답이 제품 개선에 사용되지 않는다고 명시합니다. 약관에는 민감하거나 기밀적이거나 개인적인 정보를 비유료 서비스로 보내지 말라고 명시되어 있습니다. 학습 프로젝트의 경우, 이는 합성 데이터 및 공개 데이터만 가능하다는 의미입니다. 기업의 경우, 도구를 작성하기 전에 데이터 분류가 이루어져야 한다는 것을 의미합니다.

프레임워크가 추가하는 것과 그렇지 않은 것
단일 SDK 호출만으로 Gemini에 접근할 수 있다면, 굳이 에이전트 프레임워크를 사용해야 할까요?
왜냐하면 순수한 모델 호출은 요청 하나와 응답 하나만을 제공하기 때문입니다. 무언가를 '에이전트'로 만드는 모든 것이 그 호출 주변에 존재합니다. 모델이 도구를 요청하고, 실행하고, 계속 진행할 수 있게 하는 루프 말입니다. 일반 함수로부터 도구 스키마를 생성하는 것. 턴(turn) 사이에 대화 상태를 유지하는 것. 행동이 예상 밖일 때 검사할 수 있는 이벤트 스트림. 평가 명령어와 배포를 위한 패키징 등이 있습니다. 프레임워크가 없다면, 이 모든 것은 사용자가 직접 작성하고 유지해야 하는 코드입니다. ADK는 이를 관례로 제공합니다: 빠른 시작 가이드에서 에이전트는 모델, 지침(instruction), 도구 목록을 정의하는 root_agent를 가진 Python 모듈입니다 (ADK Python quickstart).

어휘를 구분할 가치가 있습니다. 왜냐하면 '에이전트'라는 단어가 여러 역할을 숨기고 있기 때문입니다:
• 모델이 추론합니다. 컨텍스트를 읽고 답변을 하거나 도구를 요청합니다.
• 지침(instructions)은 모든 요청과 함께 전송되는 표준 명령입니다. 이는 행동을 형성하지만, 강제하지는 않습니다.
• 도구(tools)는 사용자의 함수입니다. 모델이 요청할 수만 있고, 런타임(runtime)이 실행 여부를 결정합니다.
• 런타임이 오케스트레이션합니다: 각 요청을 구성하고, 도구를 실행하며, 세션 상태를 유지합니다.

첫 번째 에이전트가 갖지 못한 것 또한 중요합니다. 메모리 서비스를 연결하지 않는 한 장기 기억(long-term memory)을 갖고 있지 않습니다. 턴(turn) 내에서 모델이 수행하는 것을 넘어서는 계획을 세우지 못합니다. 제공된 도구 외에는 아무것도 접근할 수 없습니다. 그리고 기본적으로 엔터프라이즈 보안(enterprise security)도 갖추고 있지 않습니다. ADK 자체의 CLI 참조 문서는 로컬 웹 UI와 API 서버가 인증되지 않은 엔드포인트(unauthenticated endpoints)를 노출하며, 다른 사용자에게 제공하기 전에 자체 인증을 추가하도록 안내합니다 (ADK CLI reference).

작동하는 응답은 파이프라인이 존재한다는 것을 증명할 뿐입니다. 아직 그 파이프라인을 통해 무언가가 흘러가야 한다는 것을 증명하지는 못합니다.

변하지 않는 질문들
여기서 제가 가장 놀란 부분이 있습니다. 구성된 에이전트(configured agents)에서 엔지니어링된 에이전트(engineered agents)로 이동하면서 거의 모든 구현 세부 사항이 바뀌었지만, 거버넌스 관련 질문들은 전혀 변하지 않았습니다.
어떤 신원(identity)을 사용하나요? 모든 에이전트는 결국 무언가를 호출하며, '로그인한 사용자로서'와 '에이전트로서'가 접근할 수 있는 데이터가 무엇인지 결정합니다. 개발 중에는 개인 API 키입니다. 프로덕션 환경에서는 최소 권한 원칙(least privilege)을 가진 전용 서비스 신원이어야 합니다.

어떤 데이터를 볼 수 있으며, 그 데이터는 어디로 가나요? 호스팅된 모델의 경우, 후반부 질문에 대한 답은 항상 '제공자에게'이므로, 전반부에는 분류 결정이 필요합니다.

누가 소유하나요? 명확한 비즈니스 소유자와 기술적 소유자가 없는 에이전트는 작동하는 자격 증명(credential)을 가진 부채입니다.

어떻게 계속해서 올바르게 작동하는지 알 수 있나요? 모델 출력은 결정론적(deterministic)이지 않으며, 모델 식별자는 시간이 지남에 따라 상태가 변경됩니다. 안정적인 버전(stable versions)을 고정하고 반복 가능한 평가 세트(repeatable evaluation set)를 유지해야 합니다.

누가 비용을 지불하며, 누가 감지하나요? 각 도구 호출은 컨텍스트를 다시 전송하는 또 다른 모델 왕복(model round trip)이므로, 비용은 단순히 사용자 수에 비례하는 것이 아니라 에이전트 설계에 따라 증가합니다. 누군가는 토큰, 오류, 지연 시간(latency)을 감시해야 합니다.

Copilot Studio에서는 질문에 대한 답변의 일부가 구축하기 전에 이미 존재합니다. 코드 우선(code-first) 프레임워크를 사용하면, 답변은 코드를 둘러싼 어떤 아키텍처에 존재하는지에 따라 달라집니다. 관리형 ID와 중앙 로깅이 있는 잘 거버넌스된 클라우드 프로젝트로 배포하면 통제가 강력할 수 있습니다. 하지만 개인 키로 노트북에서 실행한다면 사실상 아무런 통제도 없습니다. 프레임워크 자체는 중립적입니다.

이것이 제가 기업들이 벤더별(per vendor) 모델보다는 플랫폼 전반에 걸친 하나의 거버넌스 모델을 필요로 한다고 생각하는 이유입니다. 저는 이 아이디어를 EnterpriseAgentGuard라는 사이드 프로젝트에서 탐구하고 있습니다. 지금은 단지 아이디어와 프로젝트 폴더일 뿐이며, 형태를 갖추면서 계속해서 작성할 예정입니다.

출처
• Microsoft Copilot Studio 개요
• google-adk on PyPI
• ADK Python 퀵스타트
• ADK CLI 레퍼런스
• Gemini API 추가 서비스 약관