관리형 에이전트 프레임워크는 속도를 얻는 대신 통제권을 내준다. 그 거래는 어느 날까지는 확실히 가치가 있다. Amazon Bedrock Agents는 추론-행동 루프를 대신 실행해준다: 계획을 세우고, 어떤 도구를 호출할지 결정하고, 호출하고, 결과를 모델에 다시 넣고, 작업이 끝날 때까지 반복한다. 이것은 여러분이 직접 작성하지 않아도 되는 실제 작업이다. 문제는 시간을 절약해주느냐가 아니다. 그것이 감춰주는 부분이 여러분이 안 보고도 넘어갈 수 있는 부분이냐는 것이다.

솔직한 프레이밍은, "직접 만들기"와 "프레임워크 쓰기"가 성숙도의 사다리가 아니라는 것이다. 그것은 루프의 얼마나 많은 부분을 여러분이 통제하느냐와 얼마나 많은 부분을 유지보수하느냐 사이의 트레이드오프다. 어느 쪽이 더 진지하게 들리느냐가 아니라, 여러분의 애플리케이션이 실제로 얼마나 많은 통제를 필요로 하느냐로 선택하라.

관리형 루프가 실제로 해주는 일

에이전트 루프는 보기보다 코드가 많다. 대화 상태 머신을 유지해야 하고, 모델 출력에서 도구 호출 요청을 파싱해야 하고, 그것을 디스패치해야 하고, 잘못된 형식의 호출과 타임아웃을 처리해야 하고, 결과를 올바른 형식으로 다시 넣어야 하고, 작업이 끝났는지 판단해야 하고, 멈추지 않는 모델이 무한 루프에 빠지지 않도록 정지 조건을 강제해야 한다. Bedrock Agents는 이 모든 것을 소유한다. OpenAPI 스키마나 Lambda로 도구를 정의하고, 검색을 위한 knowledge base를 연결하고, 지시문을 설정하면, 서비스가 오케스트레이션을 주도한다.

표준적인 형태, 질문에 답하고, 잘 정의된 몇 개의 도구를 호출하고, knowledge base에서 끌어오는 경우라면, 이것은 여러분이 건너뛸 수 있는 상당량의 차별화되지 않은 배관 작업이다. 에이전트가 흔한 케이스처럼 생겼다면, 프레임워크가 명백히 옳은 선택이다.

프레임워크가 여러분을 소유하기 시작하는 지점

관리형 루프의 대가는, 루프야말로 가장 어려운 요구사항이 사는 곳인데 여러분이 그 안으로 손을 뻗을 수 없다는 것이다.

  • 커스텀 제어 흐름. 프레임워크가 모델링하지 않는 조건 분기, 작업 중간의 사람 승인 게이트, 혹은 "도구 A를 시도하고, 특정 방식으로 실패했을 때만 B로 폴백"이 필요하다면, 여러분은 추상화와 싸우고 있는 것이다. 작업을 덜어주던 그 루프가 이제는 여러분이 필요한 동작과 여러분 사이를 가로막는 것이 된다.
  • 컨텍스트와 토큰 제어. 각 모델 호출에 무엇이 들어가는지를 완전히 소유하지 못한다. 히스토리를 공격적으로 잘라내야 하거나, 정확한 지점에 검색된 컨텍스트를 주입해야 하거나, 단계별 토큰 예산을 관리해야 할 때, 관리형 루프의 선택은 여러분이 바꿀 대상이 아니라 그냥 감수해야 할 대상이다.
  • 추론 과정에 대한 관측 가능성. 에이전트가 왜 특정 도구를 선택했는지 디버깅하려면 정확한 프롬프트, 정확한 도구 출력, 정확한 다음 결정을 봐야 한다. 중간 단계를 감추는 프레임워크는 디버깅 가능한 시스템을 추측 게임으로 바꿔버린다.
  • 지연 시간과 비용 튜닝. 저렴한 단계는 작은 모델로, 어려운 단계는 최상위 모델로 라우팅하고, 공격적으로 캐싱하고, 단계별 출력을 제한하는 것, 이런 것들은 전부 루프 내부에 산다. 루프를 건드릴 수 없다면 그것들을 튜닝할 수도 없다.

탈출구 테스트

어떤 에이전트 프레임워크에 발을 담그기 전에 테스트를 하나 해보라: 탈출구를 찾아라. 전체 프레임워크를 버리지 않고도, 필요한 한 단계만 더 낮은 레벨로 내려갈 수 있는가? 좋은 추상화는 도구 호출 하나를 오버라이드하거나, 원본 프롬프트를 들여다보거나, 나머지는 프레임워크가 처리하는 동안 루프의 한 단계만 직접 작성하도록 허용한다. 나쁜 추상화는 전부 아니면 전무다. 그래서 지원하지 않는 첫 요구사항이 등장하는 순간 전체 재작성을 강요한다.

솔직한 답이 "필요한 걸 하려면 프레임워크를 완전히 벗어나야 한다"라면, 그 프레임워크는 여러분의 작업을 덜어주고 있는 것이 아니다. 재작성을 가장 불편한 순간으로 미루고 있는 것이다. 그것을 인시던트 상황에서가 아니라 첫날에 아는 편이 낫다.

실제로 쓸 수 있는 결정 기준

  • Bedrock Agents를 써라, 에이전트가 표준적인 추론-행동-검색 형태이고, 도구가 잘 정의되어 있고, 오케스트레이션 코드를 소유하기보다 그냥 출시하고 싶을 때. 대부분의 업무용 에이전트가 정확히 이 경우다.
  • 직접 루프를 만들어라, 제어 흐름, 컨텍스트 관리, 단계별 모델 라우팅, 깊은 관측 가능성이 있으면 좋은 것이 아니라 핵심 요구사항일 때. 루프가 여러분의 제품이라면 루프를 소유하라.
  • 어느 쪽이든 경계는 외부에 두어라. 인가와 최소 권한은 누가 루프를 소유하든 에이전트의 추론 내부에 속해서는 안 된다. 이번 달 초부터 정식 출시(GA)된 Amazon Bedrock AgentCore의 Policy는 에이전트 코드 바깥의 규칙에 대해 모든 에이전트-도구 호출을 평가한다. 즉 가드레일을 다시 작성하지 않고도 프레임워크를 바꿀 수 있다는 뜻이다.

핵심 요약

Bedrock Agents는 에이전트 루프를 실행하는 실제적이고 지루한 작업을 없애주며, 흔한 케이스에서는 그것이 옳은 거래다. 여러분의 가장 어려운 요구사항이 그것이 감추고 있는 루프 내부에 살게 되는 순간, 즉 커스텀 제어 흐름, 정밀한 컨텍스트 제어, 깊은 관측 가능성, 단계별 튜닝이 필요해지는 순간, 프레임워크는 여러분을 소유하게 된다. 탈출구를 먼저 찾아서 결정하라. 인가는 외부에 두어서 프레임워크 선택이 되돌릴 수 있는 상태로 남게 하라.

다음으로 읽을 글

프로덕션에서 에이전트를 운영하는 플랫폼과 인프라 관점은 ercan.cloud의 클라우드 필드 노트에 있고, 허브는 ercanermis.com이다.