더 쉬워진 프레임워크 선택, 더 무거워진 아키텍처 책임

지난 1년 동안 AI 이니셔티브를 시작하는 거의 모든 팀과 같은 대화를 나눴다. 시맨틱 커널(Semantic Kernel), 오토젠(AutoGen), 파운드리(Foundry) 중 무엇을 기반으로 구축해야 하는가?

당시에는 프로젝트 전체의 향방을 좌우할 중요한 결정이라고 생각했다. 각 프레임워크는 저마다의 철학을 내세웠고, 엔터프라이즈 AI의 기반이 되겠다고 자처했다. 잘못된 선택은 값비싼 실수로 이어질 것 같았다. 필자는 팀이 득실을 따져볼 수 있도록 많은 시간을 쏟았다.

돌이켜보면, 우리가 잘못된 질문을 하고 있었다. 필자 역시 마찬가지였다.

SDK 논쟁에 몇 달씩 매달리는 팀도 있었다. 정작 애플리케이션이 프로덕션 환경에서 살아남을 수 있는지를 결정하는 요인은 검토조차 되지 않았다. 몇 가지 결정론적 함수로 충분했을 워크플로에 정교한 오케스트레이션 레이어를 구축한 팀도 있었다. 반대로 에이전트 프레임워크를 아예 배제했다가 나중에야 설계가 발목을 잡는 구조적 한계에 부딪혔음을 깨달은 팀도 있었다.

그 무렵 마이크로소프트가 결론을 내려줬다. 통합 에이전트 프레임워크를 도입하면서 시맨틱 커널과 오토젠을 조용히 유지 보수 모드로 전환했고, 몇 달을 소비했던 논쟁은 순식간에 끝났다. “셋 중 무엇을 택할 것인가”라는 질문의 답은 결국 “셋 다 아니다, 네 번째 선택지가 있다”는 것이었다. 프레임워크는 2026년 4월 버전 1.0 정식 출시와 함께 .NET과 파이썬 양쪽에서 안정적으로 동작하는 단계에 이르렀다.

놀라운 것은 그 결정 자체가 아니었다. 그토록 많은 관심을 소비했던 논쟁이 얼마나 빠르게 무의미해졌는가 하는 점이었다. 마이크로소프트는 메뉴를 바꿨다.

하지만 식사는 달라지지 않았다.

프레임워크 너머의 진짜 과제

프레임워크 선택은 엔터프라이즈 에이전트에 관한 초기 대화의 거의 전부를 차지했다. 어떤 SDK를 표준으로 삼을 것인가? 어떤 오케스트레이션 모델이 가장 높은 유연성을 주는가? 마이크로소프트가 실제로 베팅하는 프레임워크는 무엇인가?

합당한 질문이었다. 하지만 이 프로젝트가 실제로 어떻게 흘러가는지 1년 동안 지켜본 뒤, 필자는 다른 시각을 갖게 됐다. 아무것도 가르치지 못하는 질문이었던 것이다.

지금 필자가 품은 질문은 훨씬 단순하다. 이 시스템에 정말 에이전트가 필요한가?

답이 자명한 것처럼 들리지만, 가장 자주 목격하는 실수이기도 하다. 한 프로젝트에서 어느 팀은 매번 동일한 4단계 프로세스를 수행하는 업무에 멀티 에이전트 워크플로를 설계하는 데 몇 주를 보냈다. 문서를 읽고, 검증하고, API를 호출하고, 알림을 발송하는 단계였다. 다이어그램은 훌륭해 보였다. 프로덕션에 올라간 시스템은 그렇지 않았다. 잘 테스트된 함수 몇 개가 구축하기도, 유지 보수하기도, 신뢰하기도 훨씬 쉬웠을 것이다.

원인 중 하나는 ‘에이전트’라는 단어가 누구나 손을 뻗는 표현으로 자리 잡은 데 있다. 때로는 올바른 선택이다. 때로는 더 새로운 이름표를 달았을 뿐, 이미 구축할 줄 아는 워크플로다. 에이전트가 복잡성을 정당화하는 경우는, 미리 결정할 수 없는 것들을 실제로 판단해야 할 때다. 툴 사이에서 선택하고, 발견한 것에 맞게 적응하며, 스스로 다음 단계를 찾아내야 하는 상황이 그것이다. 모든 단계를 이미 알고 있다면, 그것은 워크플로다. 그리고 워크플로는 대개 더 나은 엔지니어링 선택이다. 이번 통합이 그 사실을 바꾸지는 않았다. 다만 그것을 더 명확히 보게 해줬을 뿐이다.

프로덕션 에이전트 구축이 가르쳐준 것들

프레임워크에 대한 집착을 내려놓자, 같은 세 가지 문제가 반복해서 나타났다. SDK와는 전혀 무관한 문제들이었다.

모델 선택보다 중요한 컨텍스트 관리

초기에는 모델 비교에 많은 시간을 쏟았다. 마치 레스토랑 메뉴를 고민하다가 결국 늘 주문하던 것을 시키는 것처럼. 이제는 대다수 시간을 컨텍스트를 생각하는 데 쓴다. 훨씬 재미는 없지만, 훨씬 유용하다.

좋은 모델이 실패하는 장면도 목격했는데, 정보가 너무 적어서가 아니라 너무 많아서였다. 함께 작업한 어느 팀은 더 많은 정보가 더 나은 답변을 낸다는 이론 아래 보유한 내부 문서 거의 전부에 모델이 접근할 수 있도록 했다. 결과는 반대였다. 응답은 느려지고, 일관성은 떨어졌으며, 실제로 중요한 내용을 그냥 지나치는 경우도 있었다. 컨텍스트를 작업에 필요한 것만으로 줄이자 품질은 거의 즉시 높아졌다. 예상치 못한 결과였다. “일단 다 줘버려라”는 접근 방식을 경계하게 된 계기이기도 했다.

필자가 작업한 에이전트 시스템 중 가장 훌륭했던 것들은 가장 큰 컨텍스트 창을 가진 시스템이 아니었다. 모델에 무엇을, 언제 전달할지를 신중하게 결정한 시스템이었다. 프레임워크가 해결해줄 수 있는 문제가 아니다.

실패 처리, 진짜 작업의 시작

대다수 에이전트 데모가 훌륭해 보이는 이유는 정상 경로를 중심으로 구축되기 때문이다. 프로덕션 환경은 그런 친절을 베풀지 않는다.

한 프로젝트에서는 테스트 중 모든 것이 잘 작동했다. 그러다 에이전트가 이미 여러 앞선 단계를 완료한 뒤 다운스트림 API가 타임아웃됐다. 비즈니스 프로세스의 일부가 이미 진행됐기 때문에 단순히 재시작할 수 없었다. 결국 프롬프트에 쏟은 것보다 훨씬 많은 시간을 복구 로직에 써야 했다. 그 프로젝트는 필자가 이 작업을 바라보는 방식을 바꿨다. 어려운 부분은 모델이 결정을 내리도록 하는 것이 아니었다. 현실이 시나리오를 따르지 않을 때 시스템이 무너지지 않도록 하는 것이었다.

툴 호출은 중간에 실패한다. API는 일관성 없는 데이터를 반환한다. 마지막 답이 원하는 결과가 아니어서 모델이 같은 툴을 반복 호출하는 경우도 있다. 이것은 예외가 아니다. 흔한 일상이다. 재시도할 것인지, 롤백할 것인지, 사람의 판단을 기다릴 것인지, 부분적인 결과로 밀고 나갈 것인지는 모두 판단의 문제다. 어떤 프레임워크도 대신 판단해주지 않는다.

실제 보안 경계로서의 아이덴티티

필자에게 가장 의외였던 부분이다. 에이전트가 챗봇에서 벗어나 실제 비즈니스 시스템을 건드리기 시작하는 순간, 아이덴티티는 오케스트레이션보다 중요해진다.

모든 프로젝트는 결국 같은 질문에 이른다. 에이전트는 실제로 누구로서 행동하는가? 개발자의 자격 증명인가? 서비스 계정인가? 요청한 사용자인가? 잘못 설계하면 어느 개인보다 많은 권한을 가진 자율적 존재를 만들게 되는데, 감사가 이뤄지기 전까지는 괜찮아 보이는 유형의 문제다. 에이전트 프레임워크는 대다수 현대적 툴링처럼 모델 컨텍스트 프로토콜(Model Context Protocol) 같은 표준을 통해 에이전트를 툴에 연결하기 쉽게 한다. 그것은 분명 도움이 된다. 그러나 어디에 사람의 승인이 필요한지, 추가 권한 부여가 필요한 작업은 무엇인지, 에이전트에 얼마나 많은 자율성을 부여할지는 여전히 직접 결정해야 한다.

기술 밖에서 찾아온 예상치 못한 도전

예상하지 못했던 것이 있다. 지난해 가장 어려운 부분은 기술이 아니었다. 기업 문제였다. 팀이 ‘에이전트’라는 단어를 듣는 순간, 모든 이의 기대가 발밑에서 흔들렸다. 비즈니스 관계자들은 완전한 자율성을 기대하기 시작했다. 개발자들은 시스템이 어떤 문제든 스스로 추론해낼 수 있다고 가정했다. 어떤 문제를 풀고 있는지조차 합의하기 전에 유연성을 위한 설계에 착수하는 경우도 생겼다. 어떤 코드보다 그 단어가 먼저 피해를 줬다. 아키텍처를 논의하는 것만큼이나 기대치를 재조정하는 데 시간을 쏟아야 했다.

당장의 정답보다 오래가는 설계

지난해 어려움을 겪은 팀이 잘못된 프레임워크를 선택했다고 생각하지 않는다. 시맨틱 커널은 합리적이었다. 오토젠도 합리적이었다. 파운드리도 많은 경우에 적합했다. 필자라도 셋 중 어느 것이든 승인했을 것이다.

피해를 입은 팀은 프레임워크에 모든 것을 걸었다. 하나의 의존성으로 취급하지 않고 시스템 전체의 기반으로 삼았다. 마이크로소프트는 마이그레이션 경로를 제시했다. 하지만 애플리케이션을 프레임워크 고유의 추상화에 강하게 결합시킨 팀은 마이그레이션과 재작성이 같은 작업이 아님을 깨달았다. 그것은 마이크로소프트가 만든 문제가 아니었다. 아키텍처 자체에서 비롯된 문제였다. 수월하게 전환한 팀은 비즈니스 로직, 프롬프트, 오케스트레이션을 어떤 특정 SDK와도 독립적으로 발전할 수 있을 만큼 느슨하게 유지했다. 그런 팀에게 이번 변화는 전면 재작성이 아닌 관리 가능한 프로젝트였다.

실제로 함께 일하는 팀 중 이번 전환을 비상사태로 받아들이는 곳은 없다. 대부분은 더 작은 워크로드를 먼저 옮기고, 어떻게 작동하는지 지켜본 뒤, 새로운 추상화를 실제로 이해할 때까지 프로덕션 핵심 시스템은 그대로 두고 있다. 올바른 본능이다. 또한 이번이 마지막 통합이라고 생각하지 않는다. 생태계는 아직 젊고, 프레임워크는 서로를 계속 흡수할 것이며, 시간이 지나면 그 차이는 아키텍처적이기보다 운영적인 문제가 될 것이다.

프레임워크 논쟁을 후회하지는 않는다. 당시에는 합당했다. 달라진 것은 마이크로소프트의 로드맵이 아니라 우리의 로드맵이었다. 프로덕션 환경에서 시스템이 실제로 작동하는 모습을 지켜보면서, 프레임워크는 교체하기 가장 쉬운 부분이라는 것을 배웠다. 복구 로직, 컨텍스트 관리, 보안 경계, 비즈니스 워크플로 자체는 오늘의 SDK가 내일의 것으로 교체된 뒤에도 함께한다.

마이크로소프트는 세 개의 프레임워크를 하나로 줄임으로써 한 가지 결정의 부담을 덜어주었다. 5년 후에는 다른 툴을 쓰고 있겠지만 질문은 똑같을 것이다.

이 시스템에 에이전트가 정말 필요한가? 올바른 컨텍스트를 갖추고 있는가? 장애가 발생했을 때 시스템이 회복될 수 있는가—장애는 반드시 발생한다. 올바른 아이덴티티로 행동하고 있는가?

이런 질문은 모든 재작성보다 오래 살아남는다. 이제 필자가 관심을 두는 지점은 바로 여기다.

프레임워크는 오고 간다. 좋은 아키텍처는 그 모든 것에서 살아남아야 한다.
dl-itworldkorea@foundryco.com ...