AI 에이전트는 하나의 도구가 열 가지보다 낫기 때문에 성공할 것입니다.

Three years after Pandora’s box of LLMs was thrown open, companies are no longer talking about chatbots. Instead, every podcast pitch I get mentions AI agents. It’s the new hotness, sure, but people creating tech see a lot of opportunity to build the next level of fundamental computer science concerns: abstraction and automation.

Part of what agents address is something we’ve talked about here on the blog for a while: context switching. 개발자들은 좋은 흐름 상태를 좋아하지만, 방대한 도구와 알림, 빨간색 원과 번쩍이는 앱이 우리의 주의를 산만하게 하고 우리가 하고 있는 작업에서 멀어지게 만듭니다. 이든[–>the AI industry is a bubble 버스트 설정은 아직 알려지지 않았지만 팝 여부에 관계없이 AI(및 일반적인 지식/기술 작업)에 대한 사고 방식으로서의 AI 에이전트는 지속될 것이라고 생각합니다.

AI 붐 초기에 Isaac Lyman은 다음과 같이 내 생각의 많은 부분을 안내하는 매우 날카로운 견해를 썼습니다.[–>AI isn’t the app, it’s the UI. AI 에이전트는 여기서 한 단계 더 나아갑니다. AI 에이전트는 작업 흐름의 모든 소프트웨어를 사용하기 위한 자연어 인터페이스입니다. 하나의 인터페이스에서 채팅하고, 도구를 사용하고, 새 코드를 작성할 수 있습니다. 그리고 전체 생산 생활에 대한 단일 진입점이 되는 단일 인터페이스가 상담원이 지속되는 이유가 될 것입니다.

컴퓨터의 사용자 인터페이스는 기존 MS-DOS 및 Unix 기반 시스템의 순수 텍스트 터미널에서 특정 소프트웨어 및 기능과만 상호 작용하는 고도로 최적화되고 구성된 그래픽 인터페이스로 바뀌었습니다. LLM(대형 언어 모델)은 우리를 순수한 텍스트 인터페이스로 되돌립니다. 단, 이번에는 환경을 최대한 활용하기 위해 난해하고 난해한 강력한 단어를 알 필요가 없습니다.[–>prisoners of Vim). 모국어로 말하거나 입력하면 응답을 받을 수 있습니다. 비밀 지식은 필요하지 않습니다.[–>prompt engineers 동의하지 않을 수도 있음)

AI 에이전트는 해당 언어를 인터페이스로 사용하고 도구 사용을 추가합니다. 한동안 애플리케이션 간 API와 해결 방법이 있었지만 에이전트가 API를 사용하고 기존 소프트웨어를 중심으로 MCP(모델 컨텍스트 프로토콜) 서버를 구축하도록 하는 현재 푸시를 통해 해당 액세스가 표준화되고 있습니다. 이제 AI의 경쟁 공간은 기본 모델이 아닙니다. 에이전트 오케스트레이터입니다. 도구를 사용하는 자연어는 전체 도구, 기술 및 SaaS 제품 제품군에 대한 단일 진입점이 있을 수 있음을 의미합니다.

현대 소프트웨어 기업에서 개발자는 수많은 도구에 액세스할 수 있지만 이를 효과적으로 사용하는 방법을 반드시 아는 것은 아닙니다. 최신 스택의 모든 인프라, CI/CD, 테스트, 오픈 소스 종속성, 보안, 관찰 가능성, 데이터 관리 등 도구를 고려하십시오. 개발자는 다음을 수행할 수 있습니다.[–>waste up to four hours 일주일 동안 이러한 도구를 전환하면서 작업합니다. 생성 AI 기능을 구축하는 경우 이는 복잡하고 새로운 도구 더미입니다.[–>Maryam Ashoori, Head of Product for watsonx.ai IBM에서 설문 조사를 실시한 결과 개발자가 GenAI 시스템을 구축하는 데 5~15개의 도구를 사용하는 것으로 나타났습니다. “그들 중 대다수는 새로운 도구를 배우는 데 2시간 이상을 투자할 여유가 없다고 말했습니다.”라고 그녀는 결론지었습니다.

이러한 모든 도구에 대한 전문 지식을 유지하는 것은(그 도구가 존재한다는 사실을 아는 것은 말할 것도 없고) 많은 두뇌 공간을 차지할 수 있습니다. 소프트웨어 시스템이나 기능을 구축하는 방법과 같은 문제에 직면할 때 이 기능이 다루는 도구와 기술의 폭을 이해하지 못할 수도 있습니다. “대규모 회사에서 근무하는 경우 수백 대는 아니더라도 수십 대의 시스템이 있을 수 있습니다.”라고 말했습니다.[–>Christophe Coenraets, SVP of Developer Relations at Salesforce. “에이전트는 사용자가 무엇을 하고 싶은지 간단히 말할 수 있는 대화형 인터페이스를 제공합니다. 에이전트는 이를 올바르게 수행하는 방법을 알아낼 것입니다.”

그렇다고 해서 모든 infosec 및 DevOps 검토를 건너뛰거나 아키텍처 문서를 넘어서는 분위기 코드를 건너뛸 수 있다는 의미는 아닙니다. 여전히 시스템을 계획하고 모든 이해관계자가 이를 검토하도록 해야 하지만 에이전트적 첫 번째 단계는 도중에 방해가 될 수 있는 모든 작은 부분을 식별할 수 있습니다. 시스템 설계에 집중하고 작은 로봇 인턴이 모든 OSS 종속성에 대한 문서를 읽도록 할 수 있습니다.

이것이 어떻게 하나의 창에 머무르는 것을 쉽게 만드는지 알 수 있습니다. 어쨌든 많은 개발자가 자신의 터미널이나 IDE에 살고 있으므로 자연어를 사용하여 해당 터미널 외부의 소프트웨어에 액세스하는 자동화된 방법을 제공하면 해당 개발자가 더 깊은 곳에 내장될 것입니다.[–>their favorite terminal or IDE (“저는 죄수가 아닙니다. 저는 선택적으로 Vim에 살고 있습니다!”).

도구 사용을 허용하는 텍스트 인터페이스인 터미널은 미래의 개발자를 위한 하나의 인터페이스가 될 수 있습니다. “터미널은 이미 장기 실행 작업 개념이 있는 곳입니다.”라고 말했습니다.[–>Zach Lloyd, founder and CEO of Warp 에이전트 터미널 애플리케이션입니다. “이미 멀티태스킹이 가능합니다. 에이전트의 미래를 위한 많은 기본 요소가 터미널에 있습니다. 사람들이 거기서 끝난다면 미친 전체 주기가 될 것입니다. 그런 일이 일어날지는 모르겠지만 현재 터미널의 이러한 에이전트 기능에서 사용자가 얻는 많은 가치와 많은 일이 일어날 것입니다.”

물론 모든 애플리케이션(모든 개발자 애플리케이션도 아님)이 순수 자연어를 사용하여 실행될 수 있는 것은 아닙니다. 마법 에이전트의 미래에도 손잡이를 조작하고 차트를 가리킬 수 있도록 사용자 인터페이스가 여전히 필요할 가능성이 꽤 높습니다. 일부[–>folks point to Star Trek 이 시스템을 상상한 선구자: 주로 특수 작업을 위한 그래픽과 음성 인터페이스입니다. 그러나 현재 구성 또는 고급 설정이 존재하는 방식과 마찬가지로 즐겨 사용하는 단일 응용 프로그램에서 인스턴스화된 대화 상자로 존재할 수 있습니다.

생성된 코드를 사용하여 에이전트가 더 많은 기능, 인터페이스 및 에이전트를 구축하도록 하면 상황이 조금 더 이상해집니다. 필요한 모든 기능을 프롬프트와 함께 실시간으로 추가할 수 있는 사용 사례와 요구 사항에 맞게 조정되는 사용자 지정 UI를 상상해 보세요.[–>Google has a research demo 이를 위해 현재 구현이 약간 버벅거리는 반면 가능성은 방대하고 미지의 것입니다. “다른 모든 것은 이미 AI에 의해 개발될 것이기 때문에 지금은 마지막 기술 시대입니다.”[–>Illia Polosukhin, 원본 “Attention Is All You Need” Transformers 논문의 공동 저자이자 NEAR의 공동 창립자입니다.

좋아, 브레이크를 밟아보자. 여기에는 약간 별이 빛나는 눈과 기술 낙관주의자가 많이 있습니다. 당신이 싫어하는 모든 멍청한 작업을 수행하는 수많은 작은 에이전트를 실행하는 이 멋진 단일 인터페이스의 새로운 세계가 결실을 맺기 위해서는 누군가가 그것을 구축하기 위해 엄청난 작업을 수행해야 할 것입니다. 미래의 우리가 회전하는 금을 갖게 될 모든 에이전트에는 많은 프로그래밍, 테스트 및 인프라가 필요합니다.

플랫폼 엔지니어링 팀은 지난 10년 동안 엔지니어링 조직에서 더욱 중요한 부분이 되었습니다. 그들은 프로덕션에서 코드를 관리하는 DevOps 팀에서 성장했습니다. 프로덕션의 코드가 클라우드 네이티브 환경에서 실행되는 마이크로서비스를 점점 더 의미하게 되면서 사람들은 이를 치료하기 시작했습니다.[–>DevOps as a product 점점 더 분산되는 코드를 더 쉽게 실행할 수 있는 기능을 구축합니다. 결국 이는 개발자 경험 영역으로 확대되어 개발자는 인프라, 상호 연결성, 장애 예방 및 관리에 신경 쓰지 않고 비즈니스 논리만 작성할 수 있게 되었습니다.

“우리는 인프라 자체, 인프라를 프로비저닝하는 방법, 인프라와 상호 작용하는 방법, 그리고 실제로 현재 코드를 개발하는 방법에 대한 많은 정보를 제공합니다.”라고 말했습니다.[–>Caitlin Weaver, senior engineering manager at CLEAR. “따라서 코드가 어디로 가는지뿐만 아니라 그 안에 무엇이 있는지, 코드 작업과 관련된 프로세스도 있습니다. 우리가 안전하게 제공할 수 있는 추상화가 많이 있고 개발자의 복잡성 수준을 줄이기 위해 안전하게 숨길 수 있는 세부 사항도 많습니다.”

프로덕션 소프트웨어의 경우 이는 공유 종속성, 인프라 및 트래픽 조정, 측정항목 및 관찰 가능성, 보안, 배포 등을 의미합니다. 자체 인프라에서 실행되거나 유료 SaaS 제품으로 실행되는 도구를 사내에서 실행하는 에이전트에는 이 중 많은 부분이 필요하지만 추가적인 우려 사항도 있습니다. 비용 효율성과 효율성을 위해 일련의 모델을 실행하고 싶을 수도 있습니다.[–>evaluation purposes—라우팅 인프라가 필요합니다. 프롬프트와 응답의 가드레일과 거버넌스를 구현하려면 코드가 필요합니다. 올바른 구조화된 호출과 적절한 인증을 통해 도구 호출을 올바른 위치로 라우팅하는 프레임워크가 필요합니다. 몇 개의 MCP 서버를 가동해야 할 수도 있습니다.

이 에이전트 인프라는 프로덕션 인프라와 동일한 목적으로 사용됩니다. 개발자는 에이전트 로직을 구현하는 방법만 생각하면 됩니다. 대부분의 플랫폼 엔지니어링 작업은 시스템을 DRYer로 만드는 역할을 합니다. 모든 사람이 프로덕션에서 이러한 작업을 수행해야 하지만 모든 사람이 작업을 반복하는 것을 원하지는 않습니다. “우리는 개발자가 에이전트를 구축할 때마다 바퀴를 다시 발명하는 것을 원하지 않습니다.”라고 말했습니다.[–>Marco Palladino, CTO of Kong. “모든 에이전트가 갖춰야 할 크로스커팅 요구 사항이 많이 있습니다. 플랫폼 팀 – 이제 공은 코트에 있습니다. 모든 개발자가 기본적으로 안전하고 관찰 가능하며 관리 가능한 에이전트를 구축하는 데 도움이 될 수 있는 플랫폼을 생각해 보세요.”

사람들이 에이전트와 함께 수행하게 될 많은 작업에는 데이터가 포함되며, 이는 종종 독점적이고 비즈니스에 민감한 데이터입니다. 현실을 직시하자: 많은 앱이 단지 화려할 뿐입니다.[–>CRUD 인터페이스이므로 일반적인 에이전트 관련 문제 중 상당수는 데이터 액세스 및 관리에 관한 것입니다. 에이전트는 데이터 처리에 탁월합니다(예: 지난 3개월 간의 트래픽 로그 분석). 따라서 에이전트 시스템은 데이터 소스에 안전하게 연결하고 이를 사용할 수 있는 애플리케이션에 연결해야 합니다. 올바른 방향으로 나아가려면 상당한 계획이 필요합니다. “올바른 데이터를 어떻게 연결하나요?” 물었다[–>Jeff Hollan, director of product at Snowflake. “데이터를 어떻게 정리합니까? 데이터를 표시 가능하게 만들려면 어떻게 해야 합니까? 데이터 과학자, 데이터 엔지니어, 데이터 분석가가 수행하는 모든 작업을 하루에 완료할 수 있는 작업을 한 시간 안에 수행하도록 도울 수 있습니까?”

그러나 플랫폼 엔지니어링 팀이 할 수 있는 가장 간단한 일 중 하나는 시스템 및 엔지니어링 조직 내의 기능과 연결을 가시화하는 것입니다. 기업이 규모를 확장하면 엔지니어링 조직에서 구축한 소프트웨어 측면에서조차 사용 가능한 항목을 파악하기가 매우 쉽습니다. 특정 애플리케이션에 대해 몇 개의 시트가 있습니까? 어떤 용도로 사용할 수 있는 좌석이 있나요? 어떤 MCP 서버를 실행하고 있나요? 때로는 도구 레지스트리를 갖는 것만으로도 사람들이 도구를 연결하는 방법을 알아내도록 영감을 줄 수 있습니다.

소비자를 위해 주요 AI 제공업체는 이러한 기능을 자사 제품에 구축하고 있습니다. 6개월 전에 챗봇 프런트엔드가 있었던 모든 LLM에는 이제 플러그인으로 사용할 수 있는 에이전트 워크플로가 있습니다. 거기에서 자신만의 작업 흐름을 구축할 수 있지만 결국에는 비용을 지불하게 될 수도 있습니다. 이미 네트워크에 번성하는 도구 생태계가 있다면 전문가가 에이전트에 연결하기 위한 도구용 플랫폼을 구축하도록 요청하고 싶을 것입니다.

시간을 절약해 주는 모든 자동화와 마찬가지로 단일 에이전트 인터페이스를 구현하려면 작업이 필요합니다. 아, 하지만 정말 멋진 세상이 될 수 있습니다. 많은 조직에서 도구에 연결하는 데 도움이 되는 접착제와 시스템을 구축하고 있지만 조직이 내부에서 실행하는 모든 항목에 연결하려면 플랫폼이 필요합니다.

다른 것이 없다면 아마도 열려 있는 수백 개의 탭 중 몇 개를 닫을 수 있을 것입니다. 소년은 꿈을 꿀 수 있습니다.