룰북으로서의 프롬프트 - 기본 지침을 넘어서는 LLM 에이전트 가이드

대규모 언어 모델(LLM)을 기존 API와 통합하는 과정에서 프롬프트가 도구의 기능을 설명하는 새로운 'API 문서'가 되는 과정을 보았습니다. 이 모든 것이 처음에는 놀랍도록 간단하게 들립니다. LLM에 몇 가지 도구에 대한 액세스 권한을 부여하고 이를 설명하기만 하면 지능형 에이전트가 탄생합니다! 하지만 많은 사람들이 발견하고 있듯이, 도구를 사용할 수 있는 LLM과 도구를 더 넓은 맥락에서 현명하고 효과적으로 사용하는 LLM에는 중요한 차이가 있습니다. 이는 단순한 캘린더 어시스턴트에서 보았던 문제를 직접적으로 해결해 줍니다.

여기서 흔히 '열정적인 인턴' 신드롬이 발생합니다. 열의는 있지만 경험이 부족한 인턴처럼 툴에 대한 명시적인 지침을 성실히 따르는 LLM 에이전트. 그러나 명시되지 않은 규칙, 미묘한 인적 요소 또는 "전반적인 최상의 결과"를 직관적으로 고려하는 숙련된 직원의 노련한 판단력이 부족할 수 있습니다. 현재의 LLM은 주어진 텍스트에 따라 이해하고 실행하는 데는 매우 능숙하지만, 진정한 성공을 좌우하는 작업 뒤에 숨겨진 무언의 맥락이나 미묘한 '이유'를 본질적으로 파악하지 못합니다.

이는 개발자로서 우리의 역할이 진화하고 있음을 의미합니다. 더 이상 도구 기능만 설명하는 것이 아니라 프롬프트 내에서 세심하게 룰북을 만들어 복잡한 의사 결정 과정을 통해 LLM을 안내하고 있습니다.

사례 연구: "사려 깊은" 캘린더 도우미

2부의 '캘린더 어시스턴트' 도구를 다시 살펴봅시다. 기본 LLM 에이전트가 우리가 정의한 두 가지 주요 기능에 액세스할 수 있다고 가정해 보겠습니다:

1. CreateMeeting(attendees, subject, startTime, duration, location): 미팅을 예약합니다.
2. FindFreeTime(attendees, duration, timeWindow): 사용 가능한 슬롯을 찾습니다.

이러한 도구의 초기 프롬프트는 기본적인 통역을 처리하며 각 직원의 표준 근무 시간(예: 월~금, 현지 시간 오전 8시~오후 6시)을 준수하도록 구성되어 있습니다.

런던에 있는 팀 리더인 한 사용자가 다음과 같은 요청을 합니다: "다음 주 초에 Project Atlas에 대한 중요한 전략 세션을 1시간 동안 진행해야 합니다. 참석자는 저와 Maria(역시 런던에 거주), Ben(에든버러에 거주)입니다. 모든 참석자의 상당한 준비가 필요합니다. 런던 본사로 일정을 잡아주세요."

'열정적인 인턴' 상담원이 출근합니다. FindFreeTime을 사용하여 캘린더를 조회한 결과 월요일 오전 8시 30분(GMT) 이 정해진 표준 근무 시간 내에 있는 모든 사람에게 기술적으로 '자유 시간'이라는 사실을 알게 됩니다.

• 통화가 진행됩니다: CreateMeeting(attendees=["lead@example.com", "maria@example.com", "ben@example.com"], subject="Project Atlas Strategy Session", startTime="<Next Monday @ 08:30 GMT>", duration="1 hour", location="London HQ").

엄밀히 말하면 회의가 예정되어 있습니다. 하지만 좋은 결과일까요? 그 의미를 생각해 보세요:

1. 여행 고려 사항 무시: 에든버러에 거주하는 벤의 경우 런던에서 오전 8시 30분에 대면 미팅을 해야 합니다. 월요일 아침에 매우 일찍 출발해야 하거나 일요일 저녁에 출발해야 할 가능성이 높기 때문입니다. 이 상담원은 달력의 '8-6 근무 가능 시간'만 보고 상당한 이동이 필요한 이른 아침 회의의 물류적 비현실성과 개인적인 영향을 완전히 고려하지 못했습니다. 현지 참석자를 위한 오전 8시 30분 슬롯과 물리적으로 참석해야 하는 원격 참석자를 위한 슬롯을 구분하지 않았습니다.
2. 준비 시간을 간과했습니다: 사용자는 이 세션이 "상당한 준비"가 필요한 "중요한 전략 세션"이라고 명시적으로 언급했습니다. 월요일 아침(오전 8시 30분)에 가장 먼저 일정을 잡는 것은 참석자들이 이른 시간부터 준비하려면 주말 개인 시간을 사용하여 준비해야 한다는 암묵적인 압박을 줍니다.

개발자로서 에이전트가 명시적인 일정 가용성에 따라 작업을 수행했지만 중요한 암묵적인 인적 요소와 실질적인 고려 사항을 놓쳤다는 것을 깨닫는 순간입니다. 진정으로 효과적이고 사려 깊은 결과를 보장할 수 있는 판단력이 부족했던 것입니다.

'경험' 및 '고려 사항'을 프롬프트에 인코딩하기

'인턴'을 '숙련된 어시스턴트'로 승격하려면 더 정교한 논리를 주 상담원의 안내 메시지 (또는 도구를 오케스트레이션할 때 따르는 중요한 지침). 이는 단순히 FindFreeTime 또는 CreateMeeting 도구 자체에 대해 설명합니다. 상담원에게 다음과 같이 알려야 합니다. 더 사려 깊게 행동하는 방법.

여기에는 종종 상담원에게 '제3의 도구' 또는 추가적인 정보 및 논리 계층으로 생각할 수 있는 것을 찾아서 사용하도록 지시하는 것이 포함됩니다. 이 경우에는 다음과 같습니다. 참석자 위치, 여행 상황, 미팅의 성격 등을 고려합니다. 에이전트가 암시적으로(또는 다음과 같은 다른 도구를 통해 명시적으로) 다음과 같이 요청해야 할 수 있습니다. GetUserProfile(email)) 액세스하거나 추론합니다:

• 각 참석자의 기본 근무 위치.
• 미팅 유형(예: 대면 대 가상).
• 회의 중요도 및 시기의 의미(예: "중요한 월요일 아침 회의").

이 '컨텍스트 데이터'에 액세스한 다음 상담원의 마스터 프롬프트에 "만약...그러면..." 스타일의 안내 목록을 추가해야 합니다:

수정된 상담원 프롬프트 로직 스니펫(개념):

"...회의 일정을 잡아야 하는 경우:

1. 향상된 컨텍스트 수집: 각 참석자에 대해 해당 참석자가 있을 가능성이 있는 위치를 파악합니다(예 GetUserProfile(attendee_email)). 미팅이 '대면'으로 지정되어 있고 참석자가 원격에 있는 경우 참고하세요.
2. 대면 회의를 위한 이동을 고려하세요:
   • 만약 회의는 대면으로 진행됩니다, 그리고 참석자가 원격에 있는 경우 그리고 제안된 이른 아침 시간대(예: 미팅 장소의 현지 시간으로 오전 10시 이전)가 확인됩니다:
     • 그런 다음 요청자에게 플래그를 지정합니다. 예를 들어 '벤이 이 대면 회의에 참석하기 위해 에든버러에서 여행할 예정입니다. 월요일에 편안하게 이동할 수 있도록 오전 10시 30분 이후에 회의를 시작하시겠습니까, 아니면 가상 옵션을 살펴봐야 하나요?'
3. 중요한 회의를 위한 준비 시간을 고려하세요:
   • 만약 회의가 '긴급', '중요' 또는 '상당한 준비'가 필요한 것으로 설명됩니다. 그리고 월요일(또는 휴일 직후)의 이른 시간대에 예약되어 있습니다:
     • 그런 다음 요청자에게 확인을 요청하세요. 예를 들어 '준비가 필요한 이 중요한 월요일 세션의 경우, 월요일 오전 8시 30분에 시작하면 모든 사람이 월요일 아침 자체에 충분한 시간을 가질 수 있을까요, 아니면 당일 준비를 위해 오전 10시 전후의 슬롯이 더 적합할까요'라고 질문하세요.
4. 일반 시간대/근무 시간 충돌 처리(앞서 설명한 대로):
   • ('핵심 소셜 창구'의 우선순위를 정하고, 이 창구 이외의 시간대를 처리하며, 가상 미팅의 경우에도 해당되는 경우 다른 시간대에 걸쳐 불편한 시간에 대한 확인을 요청하는 논리를 통합하세요).
5. 명시적 사용자 재정의 존중:
   • 사용자가 불편한 일정을 명시적으로 확인한 경우 (예: "예, 벤이 알고 있으며 일요일에 여행할 예정입니다.") , '알겠습니다'라는 최종 확인으로 진행합니다. 확인된 대로 일정을 예약합니다."

프롬프트: 간단한 설명부터 복잡한 알고리즘까지

보시다시피 메인 에이전트의 프롬프트가 크게 진화했습니다. 더 이상 단순히 사용 가능한 도구 목록이 아닙니다. 상세한 조건부 의사 결정 트리입니다. 자연어로 표현된 미니어처 알고리즘입니다. 이러한 "만약...그러면..."이라는 문장은 에이전트의 "추론" 프로세스의 중추가 되어 단순한 솔루션이 아니라 더 나은 솔루션으로 안내합니다.

이러한 잠재적 함정을 예측하고 '경험', '회사 정책' 또는 '일반적인 예의'를 LLM의 지침에 직접 인코딩하는 것이 개발자의 과제이자 새로운 기술로 떠오르고 있습니다. 이는 LLM이 엄청난 힘을 가지고 있지만, 그 힘을 진정으로 유용하고 사려 깊은 애플리케이션으로 유도하는 개발자의 노력이 그 어느 때보다 중요하다는 것을 증명합니다. '열정적인 인턴'을 한 번에 하나씩 세심하게 안내하여 신뢰할 수 있고 경험이 풍부한 디지털 동료로 변화시키는 것이 중요합니다.

앞으로의 목표는 에이전트가 행동의 결과를 통해 진정으로 '학습'할 수 있도록 함으로써 가장 상세한 프롬프트 기반 룰북을 뛰어넘어 진화하는 것입니다. 오늘날에는 경험을 꼼꼼하게 인코딩하지만, 다음 단계에서는 에이전트가 자율적으로 전략을 개선할 수 있어야 합니다. 상담원이 업무를 수행하기 위한 도구와 데이터뿐만 아니라 원하는 비즈니스 성과를 달성하는 데 있어 이러한 작업의 성공 또는 실패에 대한 지속적인 피드백에 액세스할 수 있다고 상상해 보세요. 예를 들어, 특정 사용자가 '점심 외출'이라는 이유로 오후 12:00 미팅 초대를 지속적으로 거부하는 것을 캘린더 어시스턴트가 관찰한다면 개발자가 '사용자 X의 정오 미팅 금지' 규칙을 명시적으로 프로그래밍하지 않아도 시간이 지나면서 해당 사용자의 우선순위를 낮추거나 제안을 피하는 방법을 학습할 수 있습니다.

이제 이 학습 기능을 더 복잡한 비즈니스 프로세스로 확장해 보세요. 예를 들어 고객 온보딩 또는 공급망 물류에 대한 일련의 절차로 처음 프로그래밍된 에이전트는 핵심 성과 지표를 측정하고 실제 결과를 관찰하여 비효율적인 부분을 파악하거나 더 최적의 경로를 발견할 수 있습니다. 시간이 지남에 따라 접근 방식을 미묘하게 조정하거나 단계의 우선순위를 재조정하거나 개발자가 처음 설계한 기본 프로세스에 대한 수정을 제안할 수도 있습니다. 따라서 미래에는 개발자가 이러한 에이전트 행동의 초기 설계자뿐만 아니라 에이전트가 자체 운영 '알고리즘'을 점진적으로 개선하고 최적화하는 시스템을 구축하여 비즈니스 목표를 달성하는 역동적이고 학습적인 파트너로 거듭날 수 있습니다.

Akamai가 어떻게 대규모 AI 워크로드를 지원하는지 알아보세요. 지금 바로 전문가와 상담하세요.