LLM은 서로 다른 방식으로 상호 작용합니다. LLM은 스키마에 대해 데이터를 확인하는 대신 도구나 다른 시스템이 수행할 수 있는 작업에 대한 설명을 일반 언어로 읽습니다. 개발자는 호출하는 LLM이 읽고, 사용하고, 궁극적으로 내 인터페이스 작동 방법을 이해하는 데 사용할 수 있는 정보를 노출해야 합니다. LLM에 엄격한 스키마를 제공하지 않습니다. 대신 도구의 목적, 입력 및 예상 결과를 포함한 설명을 제공하면 됩니다.
LLM은 언어 이해력을 사용하여 이 설명을 기반으로 도구 사용 방법을 파악합니다. 딱딱한 양식을 확인하는 것에서 구두 지침을 이해하는 것과 같습니다. 이는 특히 덜 구조화된 작업의 경우 더 유연하지만 상호 작용이 해석에 따라 달라지므로 엄격한 형식보다 예측하기 어려울 수 있습니다. 이 방법론은 지난 블로그에서 언급했듯이 모델 컨텍스트 프로토콜(MCP)부터 Google의 오픈 소스 에이전트 개발 키트에 이르기까지 다양한 분야에서 사용되고 있습니다.
프롬프트는 새로운 "API 문서"입니다.
따라서 LLM의 경우 'API 계약' 또는 문서는 기본적으로 도구나 기능을 설명하기 위해 작성하는 프롬프트입니다. 이제 개발자는 코드 주석이나 스키마 파일을 작성하는 대신 LLM에 명확하고 자세한 설명을 작성합니다:
- 기능: 도구의 주요 기능.
- 필요한 정보: 예제 또는 형식 힌트와 함께 입력이 필요합니다.
- 반환되는 내용: 예상되는 결과물 또는 조치입니다.
- 모든 규칙: 중요한 제약 조건 또는 가이드라인입니다.
즉, 신속한 엔지니어링이 중요한 기술이 되고 있습니다. 이러한 시스템이 제대로 작동하려면 개발 팀이 LLM이 안정적으로 이해하고 실행할 수 있는 지침을 작성할 수 있어야 합니다.
간단한 예시: LLM을 위한 '캘린더 도우미' 도구
캘린더 어시스턴트와 같은 좀 더 동적인 도구를 상상해보고 이를 LLM에 대해 설명해 보겠습니다:
전체 도구 설명: "캘린더 보조 도구입니다. 새 미팅을 예약하고 그룹을 위해 사용 가능한 시간대를 찾을 수 있습니다."
기능 1: CreateMeeting 프롬프트: 도구 이름: CreateMeeting. 설명: 캘린더에서 새 미팅을 예약합니다. 필수 입력입니다: attendees (이메일 주소 목록), subject (미팅 제목의 텍스트), startTime (회의가 시작될 날짜와 시간, '내일 오후 3시' 또는 '다음 월요일 오전'과 같이 상대적인 시간으로 해석하세요. duration (길이를 설명하는 텍스트(예: '1시간', '30분'). 선택 입력: 위치(예: '회의실 B' 또는 영상 통화 링크 등의 텍스트). 최종 회의 세부 정보를 포함한 확인 메시지 또는 예약에 실패한 경우 오류(예: 시간 충돌, 잘못된 참석자)를 표시합니다. 시작 시간이나 시간이 모호한 경우 계속 진행하기 전에 사용자에게 설명을 요청합니다. 시간은 달리 명시되지 않는 한 사용자의 현지 표준 시간대로 가정합니다.
LLM이 이를 사용하는 방법(사용자 요청을 해석한 후): CreateMeeting(참석자=["alice@example.com", "bob@example.com"], subject="Project Sync", startTime="2025-05-02T15:00:00", duration="45 minutes", location="Video Call")
기능 2: 무료 시간 찾기 프롬프트: 도구 이름: FindFreeTime. 설명: 지정된 기간 내에 사용자 그룹이 공통으로 사용할 수 있는 시간대를 찾습니다. 필수 입력입니다: attendees (이메일 주소 목록) 및 duration (원하는 미팅 시간을 설명하는 텍스트, 예: '1시간'). 선택적 입력입니다: timeWindow ('다음 주', '이번 주 금요일 오후', '향후 3일 이내' 등 검색 시기를 설명하는 텍스트, 지정하지 않으면 현재 근무 주를 기본값으로 함). 사용 가능한 시작 시간(날짜 및 시간) 목록 또는 공통 슬롯을 찾을 수 없다는 메시지와 함께 응답합니다. '다음 주'와 같은 상대적인 기간을 사용하는 경우 검색 중인 날짜 범위를 구체적으로 명시하세요. 별도로 지정하지 않는 한 시간은 사용자의 현지 시간대라고 가정합니다.
LLM이 이를 사용하는 방법(사용자 요청을 해석한 후): FindFreeTime(참석자=["alice@example.com", "bob@example.com", "charlie@example.com"], duration="1 hour", timeWindow="next Tuesday")
여기서 프롬프트는 목록을 처리하는 방법, 날짜 및 기간과 같이 모호할 수 있는 입력을 해석하는 방법, 심지어 언제 설명을 요청해야 하는지에 대해 LLM을 안내합니다. 이는 실제 LLM 도구의 상호 작용 방식에 더 가깝습니다.
도전 과제: 모호성과 신속한 정확성(이 시리즈의 3부 무대 설정)
개발자로서 이런 도구를 처음 만들면 '정말 대단하다'고 생각하게 됩니다. 이 에이전트를 작성하는 것은 정말 쉬워요'라고 생각했죠. 하지만 개발자의 삶에서 흔히 그렇듯이 현실에 부딪히게 되죠...
캘린더 도우미 프롬프트는 "내일 오후 3시"와 같이 모호한 부분을 처리하려고 노력하지만, 자연어 설명에 의존하면 소프트웨어가 예상하지 못했던 새롭고 흥미로운 방법을 도입할 수 있습니다.
다음 예시를 살펴보세요:
- 충돌하는 CreateMeeting 요청:
- 사용자: "이번 금요일 오후에 저와 찰리를 위한 2시간 미팅을 예약하되, 오후 2시 이전이어야 합니다."
- 문제: "금요일 오후"는 일반적으로 오후 12시 또는 오후 1시 이후의 시간을 의미합니다. "오후 2시 이전"은 잠재적인 충돌이 발생하거나 매우 좁은 창(예: 오후 1시~오후 2시)을 의미합니다. 이 프롬프트는 시간과 같은 단일 매개변수 내에서 충돌하는 제약 조건을 처리하는 방법을 LLM에 명시적으로 알려주지 않습니다. "오후" 또는 "오후 2시 이전"을 우선시해야 할까요? 사용자에게 충돌을 표시해야 하나요?
- 모호한 FindFreeTime 요청:
- 사용자: "다음 주에 Dave와 간단히 채팅할 시간을 찾아보세요."
- 문제: "빠른 채팅"이란 무엇인가요? 지속 시간 매개변수에는 "15분" 또는 "30분"과 같이 좀 더 구체적인 내용이 필요합니다. 현재 프롬프트는 기간을 요구하며 기본값이나 '빠른 채팅'과 같은 모호한 용어를 처리하는 방법을 지정하지 않습니다. LLM이 실패하거나 추측해야 할 수도 있습니다.
- FindFreeTime의 암시적 가정:
- 사용자: "다음 주 수요일 팀 회의 시간을 찾아보세요."
- 문제: '팀'이란 누구인가요? LLM은 참석자 목록(이메일 주소)이 필요합니다. 프롬프트에는 이 정보가 필요하지만 사용자 요청은 '팀'의 컨텍스트를 알고 있는 LLM에 의존합니다. 참석자 목록이 제공되지 않거나 대화 기록을 통해 유추할 수 없는 경우 LLM이 "팀에 누가 있나요?"라고 묻는 것이 좋은 상호작용 흐름일 수 있습니다. 이 경우 통화 상담원이 다른 상담원에게 전화하여 누가 '팀'인지 알아낼 수 있습니다.
- 지정되지 않은 시간대:
- 사용자(런던에 있음): "내일 오전 9시에 프리야(뉴욕에 있음)와 미팅을 예약하세요."
- 문제: 런던 시간으로 오전 9시인가요, 아니면 뉴욕 시간으로 오전 9시인가요? 현재 프롬프트에는 기본 가정("별도로 지정하지 않는 한 시간은 사용자의 현지 시간대로 가정")이 포함되어 있지만 시간대를 올바르게 처리하는 것은 복잡합니다. 사용자가 지정하지 않고 참석자들이 서로 다른 시간대에 있는 경우에는 어떻게 해야 할까요? 이 도구는 시간대를 처리하기 위한 정교한 백엔드 로직이 필요하거나, 여러 위치가 관련된 경우 시간대 정보를 요청하고 확인하는 방법에 대한 훨씬 더 명확한 지침을 프롬프트에 표시해야 합니다. 단순한 가정은 일정 예약 오류로 이어질 수 있습니다.
이러한 예는 적절한 프롬프트가 있더라도 사용자 요청의 모호성, 상충되는 정보 또는 명시되지 않은 가정(예: 시간대)으로 인해 오류, 잘못된 작업 또는 답답한 설명 루프가 발생할 수 있음을 보여줍니다. LLM-API 상호작용의 효과는 도구의 기능과 한계를 설명하는 프롬프트의 품질과 완성도에 직접적으로 달려 있습니다. 프롬프트에는 행복한 경로뿐만 아니라 모호한 정보, 누락된 정보, 잠재적인 충돌, 시간대와 같은 상황별 세부 사항을 처리하는 방법도 포함되어야 합니다.
복잡해지기: 여러 AI 에이전트가 대화할 때(보다 심층적인 문제로 전환)
하나의 도구를 정확하게 설명하는 것도 문제지만, 여러 AI 에이전트가 함께 작업해야 하는 경우에는 훨씬 더 까다로워집니다. 에이전트 A가 에이전트 B가 할 수 있는 일과 할 수 없는 일, 그리고 에이전트 B가 모호한 상황을 처리하는 방법을 명확하게 이해할 수 있도록 프롬프트를 작성하려면 어떻게 해야 할까요? 어떻게 조율하나요? 서로의 지시를 해석하는 방식에 따라 예상치 못한 문제가 발생하지 않고 안정적으로 협력할 수 있도록 하려면 어떻게 해야 할까요? 이러한 상호작용을 언어를 사용하여 명확하고 안정적으로 정의하는 방법을 알아내는 것은 이러한 시스템이 진화함에 따라 우리가 직면하고 있는 큰 과제입니다.
Akamai가 어떻게 대규모 AI 워크로드를 지원하는지 알아보세요. 지금 바로 전문가와 상담하세요.
내용