서로 다른 소프트웨어 시스템이 서로 대화하도록 하는 것은 개발자에게는 고전적인 과제입니다. 수년 동안 우리는 이를 위해 잘 정의된 규칙이 있는 API를 사용했습니다. 하지만 이제 대규모 언어 모델(LLM)은 엄격한 형식뿐만 아니라 언어 이해를 기반으로 시스템이 상호 작용할 수 있는 새로운 방법을 제공하면서 판도를 바꾸고 있습니다. 이는 흥미로운 가능성을 열어주는 동시에 해결해야 할 새로운 문제를 제시하며, 개발자의 작업은 결코 끝나지 않는다는 것을 다시 한 번 증명합니다!
이것이 개발자에게 어떤 의미가 있는지 살펴보겠습니다.
시스템 연결 방식 기존 API
우리가 일반적으로 시스템을 연결하는 방법을 생각해 보세요. 우리는 다음과 같은 것을 사용합니다:
- REST API: 종종 JSON을 사용하거나 OpenAPI(Swagger) 사양을 사용하는 API는 데이터 유형(예: 문자열 또는 숫자)을 포함하여 시스템에서 어떤 데이터가 들어오고 나가는지 정확하게 설명합니다.
- RPC(원격 프로시저 호출): gRPC와 같은 도구를 사용하면 시스템이 프로토콜 버퍼 등을 통해 서로 함수를 호출하여 함수가 필요로 하는 것과 반환하는 것을 정확하게 정의할 수 있습니다.
- SOAP/WSDL: 이 방법은 이전 방법이지만 서비스에 대한 자세한 설명(WSDL)에 의존합니다.
- 메시지 큐(예: 카프카, RabbitMQ): 이러한 시스템은 일반적으로 합의된 특정 형식에 따라 메시지를 주고받습니다.
여기서 중요한 것은 이러한 방법이 명시적인 규칙과 형식에 의존한다는 것입니다. 기계는 데이터가 미리 정의된 구조(스키마 또는 유형 정의)와 일치하는지 확인합니다. 개발자는 문서를 읽고 API의 기능을 이해한 다음 필요한 순서대로 API를 호출하는 코드를 작성하여 반환된 데이터를 처리합니다. 이는 컴퓨팅이 등장한 이래로 개발자들이 해온 일입니다.
새로운 패러다임 MCP, 에이전트 프레임워크 및 프롬프트 증강 API
엄격하게 정의된 기존 API에서 LLM의 유동적인 언어 중심 상호 작용으로 전환하는 과정에서 모든 시스템 구성 요소가 제약 없는 순수한 자연어로 바로 전환되는 것은 아닙니다. 대신, 이러한 격차를 해소하기 위해 설계된 강력한 중간 패러다임과 프레임워크가 등장하여 기존 시스템과 새로운 서비스가 "LLM을 사용할 수 있는" 상태가 될 수 있도록 지원하고 있습니다.
이러한 새로운 접근 방식의 핵심에는 프롬프트 증강 API라는 개념이 있습니다. LLM이 처음부터 기능을 직관하거나 개발자가 복잡한 어댑터 코드를 작성할 필요 없이, 오래된 REST 서비스든 새로운 gRPC 엔드포인트든 상관없이 풍부한 자연어 설명으로 API를 '꾸미거나' '감싸는' 것입니다. 이러한 설명은 API의 목적, 호출 방법, 예상되는 매개변수(및 형식), 반환되는 내용을 설명하는 LLM 전용 사용자 매뉴얼과 같은 역할을 합니다.
예를 들어 모델 컨텍스트 프로토콜(MCP)은 다양한 기능을 LLM 기반 컨트롤 플레인에 노출하는 보다 구조화된 방법의 예시입니다. 시스템은 메타데이터 및 자연어 설명과 함께 서비스 및 지원되는 작업을 선언할 수 있습니다. 그런 다음 LLM은 이 선언된 기능의 '메뉴'를 쿼리하고 사용자 요청 또는 상위 수준의 목표에 따라 이러한 기본 서비스에 대한 호출을 조율하여 선언된 프롬프트와 유사한 인터페이스를 통해 해당 서비스의 기능과 사용 방법을 이해할 수 있습니다.
이는 빠르게 진화하는 에이전트 프레임워크의 세계와 밀접하게 연관되어 있습니다. 이러한 프레임워크는 종종 LLM 기반의 기본 제어 에이전트를 구축하기 위한 스캐폴딩을 제공합니다. 이 중앙 에이전트는 추론, 계획, 작업 위임이 가능한 오케스트레이터 또는 '두뇌' 역할을 합니다. 이 제어 에이전트가 일련의 '도구' 또는 하위 에이전트에 대한 액세스 권한을 부여받을 때 진정한 힘을 발휘합니다.
이러한 하위 에이전트는 매우 다양할 수 있습니다:
- 일부는 복잡한 데이터 분석이나 창의적인 콘텐츠 제작과 같은 특정 작업을 위해 설계된 다른 전문 LLM 기반 에이전트일 수도 있습니다.
- 더 간단한 소프트웨어 모듈이나 결정적으로 기존의 기존 API를 둘러싼 래퍼일 수도 있습니다. 이 시나리오에서는 개발자가 내부 주문 관리 API를 둘러싸는 경량 래퍼를 만듭니다. 이 래퍼는 단순히 기술적인 엔드포인트만 노출하는 것이 아니라 API의 기능을 자연어로 설명하는 세심하게 제작된 프롬프트를 포함합니다: "이 도구를 사용하면 주문 상태를 가져올 수 있습니다. 입력값으로 'order_id'가 필요하며 현재 상태, 예상 배송일, 주문 내 품목을 반환합니다." 등의 자연어 안내가 포함되어 있습니다.
이러한 패러다임의 공통점은 새로운 마이크로서비스이든 래퍼를 통해 노출되는 레거시 시스템이든 API는 더 이상 단순한 기술 계약이 아니라는 점입니다. 설명적인 프롬프트 계층으로 보강됩니다. 이를 통해 소비하는 LLM(일반적으로 제어 에이전트)은 방대한 도구와 기능을 동적으로 검색, 이해 및 활용할 수 있습니다. LLM은 각 도구의 복잡한 구현 세부 사항을 알 필요 없이 프롬프트 기반의 사용 방법 설명만 이해하면 됩니다. 이러한 변화는 시스템 통합에 대한 생각을 근본적으로 바꾸고 이러한 설명 프롬프트의 명확성, 정확성 및 포괄성에 더욱 중점을 두며, 이에 대해서는 앞으로 자세히 살펴보겠습니다.
미래는... 달라집니다
엄격한 형식 기반의 API, 심지어 최근에 등장한 프롬프트 증강 인터페이스에서 LLM과 진정으로 광범위한 언어 기반 상호 작용으로 이동하는 것은 큰 변화입니다. 개발자로서 저는 가능한 입력, 출력 및 오류 메시지에 대한 명확한 정의가 있다는 사실에 익숙해졌습니다. LLM으로 작업하면서 이전에는 없던 엄청난 양의 기능을 사용할 수 있게 되었습니다. 하지만 다른 시스템과 상호 작용하는 방식을 재정의해야 하는 작업이기도 합니다. 개발자로서 기능을 설명하는 정확하고 포괄적인 프롬프트를 작성하는 방법을 이해하는 것은 특히 여러 AI 에이전트가 협업해야 하는 시스템을 구축할 때 점점 더 중요해지고 있습니다.
내용