11장 LLM 에이전트의 계획(Planning)과 피드백 완전 정리

개요

LLM 기반 에이전트에서 '계획(Planning)'은 단순한 대화 기능을 넘어서, 목표를 스스로 쪼개고 순서대로 실행하게 만드는 핵심 능력이다. 계획이 없는 모델은 사용자의 질문에 그때그때 답만 하는 챗봇에 가깝지만, 계획이 있는 에이전트는 목표를 분석하고 필요한 단계들을 설계한 뒤 도구를 사용해 실제 작업을 수행할 수 있다.

이 노트에서는 계획 기능이 왜 중요한지, 계획 능력이 없는 LLM과 에이전트의 차이가 무엇인지, Nexus와 Gradio를 이용해 에이전트를 실습하는 방법의 큰 흐름, 도구(액션)를 어떻게 설계·제한해야 하는지, 도구 사용 시 발생할 수 있는 위험 요소와 안전/보안 관점의 주의점, 마지막으로 위키피디아 검색·다운로드·파일 저장을 예시로 계획과 도구 사용이 어떻게 결합되는지를 정리한다. 또한 계획만큼 중요한 피드백(Feedback) 메커니즘이 에이전트의 성능과 안전성에 어떤 역할을 하는지도 함께 살펴본다.

계획(Planning)이 에이전트/어시스턴트에서 갖는 핵심적 역할

LLM 에이전트에서 계획은 "목표를 달성하기 위한 일련의 단계들을 설계하고 실행 순서를 잡는 능력"을 의미한다. 사용자가 단순히 질문을 던지는 것이 아니라, "이 목표를 대신 해결해줘"라고 요청했을 때, 에이전트가 해야 할 일은 질문에 답변하는 것을 넘어, 목표를 달성하기 위해 어떤 작업들을 어떤 순서로 수행해야 하는지 스스로 정리하는 것이다.

예를 들어 "위키피디아에서 특정 주제 문서를 찾아서 모두 다운로드하고, 하나의 파일로 저장해줘"라는 요구는 자연어로는 한 문장이지만, 실제로는 여러 단계의 하위 작업으로 나눠야만 수행할 수 있다. 계획을 잘하는 에이전트는 이 목표를 받아들고 "검색 → 페이지 ID 수집 → 각 페이지 내용 다운로드 → 파일로 저장"과 같이 단계별 계획을 세운 뒤, 각 단계에 맞는 도구를 호출해 실행한다.

이처럼 계획은 에이전트가 도구를 "언제, 어떤 순서로, 어떤 입력으로" 사용할지를 결정하는 상위 레벨의 두뇌 역할을 한다. 도구 사용 능력만 있고 계획이 없으면, 에이전트는 제공된 함수들을 그때그때 떠올리는 수준에 그치고, 복잡한 목표를 끝까지 완수하지 못한다. 반대로 계획이 있으면, 도구들을 조합해 하나의 긴 작업 파이프라인을 스스로 구성할 수 있다.

계획 능력이 없는 단순 챗봇 vs 목표를 해결하는 에이전트

계획 능력이 없는 단순 챗봇은 사용자의 입력에 대해 "한 번의 응답"을 생성하는 데 최적화되어 있다. 이들은 도구를 쓸 수 있더라도, 각 호출을 서로 독립적인 행동처럼 다루며, 이전 행동 결과를 바탕으로 다음 행동을 설계하는 구조적인 계획을 세우지 못한다. 흔히 "병렬(Parallel) 액션은 되지만, 순차(Sequential) 액션은 못하는" 상태라고 볼 수 있다.

예를 들어 단순 챗봇에 다음과 같은 목표를 주었다고 하자.

• "위키피디아에서 'Calgary'를 검색하고, 검색 결과 페이지들을 모두 다운로드한 뒤, Wikipedia_Calgary.txt라는 파일로 저장해줘."

이때 챗봇이 도구를 쓸 수는 있으니 search_wikipedia("Calgary") 정도는 호출할 수 있다. 하지만 그 다음에 해야 하는 "검색 결과에서 페이지 ID를 꺼내고 → 각 페이지를 다운로드하고 → 하나의 파일로 정리해 저장하는" 일련의 단계는, 모델 스스로가 명시적인 계획을 세우지 않는 한 자연스럽게 이어지지 않는다. 그 결과, 첫 번째 도구 호출만 하고 멈추거나, 다음 단계로 제대로 넘어가지 못하는 상황이 자주 발생한다.

반면 계획 능력이 있는 에이전트는 목표를 먼저 분석하여 하위 작업 목록(서브태스크)을 만든 뒤, 각 작업에 적절한 도구를 할당하고, "1단계가 끝나야 2단계를 할 수 있는" 순차 실행을 수행할 수 있다. OpenAI Assistants나 Anthropic Claude와 같이 내부에 기본적인 플래너가 내장된 시스템은 이러한 순차적 도구 사용을 자동으로 처리해, 사용자는 최종 결과만 받아보게 된다. 즉, 둘의 차이는 "대화 중심 vs 목표 달성 중심"이라고 정리할 수 있다.

Nexus와 Gradio를 활용한 에이전트 실습 환경 개요

Nexus는 여러 LLM 엔진(OpenAI, Azure OpenAI, Groq 등)을 묶어서 에이전트를 구성하고 실험해 볼 수 있는 프레임워크다. Gradio는 Python 기반 머신러닝/AI 데모를 웹 인터페이스로 쉽게 띄우게 해주는 도구이며, Nexus는 이를 이용해 GUI 환경에서 에이전트를 만들고 실행하는 경험을 제공한다.

Nexus 환경에서는 대략 다음과 같은 흐름으로 실습을 진행한다.

1. nexus run gradio 명령으로 Gradio 기반 Nexus 웹 인터페이스를 실행한다.

2. 웹 페이지에서 새로운 에이전트를 생성하고, 사용할 LLM 엔진(OpenAI, Azure, Groq 등)을 선택한다.

3. 에이전트가 사용할 도구(액션)를 등록·선택한다. 예: search_wikipedia, get_wikipedia_page, save_file 등.

4. 에이전트에 플래너(Planner)를 쓸지 여부를 선택한다. (예: Planner를 None으로 하면 계획 없이 동작, 별도 플래너를 연결하면 계획 기반 동작)

5. 사용자 목표(goal)를 입력하고 스레드를 생성한 뒤, 에이전트의 행동을 관찰한다.

이 과정에서 중요한 점은, 동일한 도구 세트를 주더라도 "플래너가 없는 경우"와 "플래너가 있는 경우"에 에이전트의 행동 양상이 완전히 달라진다는 것이다. 따라서 Nexus + Gradio 조합은 계획 기능의 유무에 따른 차이를 시각적으로 체험하기에 좋은 실습 환경이다.

도구(액션)를 제한적으로 제공해야 하는 이유

에이전트에 도구를 연결할 때 "쓸 수 있는 건 다 연결해 두면 편하지 않을까?"라는 생각이 들기 쉽지만, 실제로는 도구를 많이 넣을수록 문제가 발생하기 쉽다. 대표적인 이유는 다음과 같다.

첫째, 도구가 많아질수록 에이전트의 의사결정이 어려워진다. LLM은 각 도구 설명을 보고 "현재 단계에 어느 도구를 쓰는 것이 목표 달성에 가장 적절한가?"를 판단해야 하는데, 후보가 많을수록 혼란이 커지고, 엉뚱한 도구를 선택하거나 불필요한 호출이 늘어날 수 있다. 즉, 도구 수가 많아질수록 계획 과정이 복잡해지고, 오류 가능성도 커진다.

둘째, API 측면에서 도구 수에는 한계가 있다. 상용 LLM API들은 한 번의 호출에 붙일 수 있는 도구 개수에 제한을 두는 경우가 많으며, 이 제한을 넘지 않아도 도구 정의가 지나치게 길어지면 토큰 비용이 커지고 응답 속도도 느려진다. 실무적으로는 "해당 목표를 달성하는 데 반드시 필요한 최소한의 도구만 제공하는 것"이 토큰 비용과 안정성 측면에서 유리하다.

셋째, 도구가 많아질수록 에이전트가 도구를 예상치 못한 방식으로 사용하는 위험이 커진다. 예를 들어, 파일 삭제, 코드 실행, 외부 네트워크 호출 등의 도구가 모두 연결되어 있으면, 모델이 의도치 않게 민감한 파일을 삭제하거나 무한 루프 형태로 API를 호출하는 등의 행동을 할 수 있다. 따라서 에이전트 설계 시 목표에 맞는 도구만, 가능한 좁은 범위로 제공하는 것이 안전하다.

도구 사용 시 예상치 못한 행동과 안전·보안상 주의점

도구를 사용할 수 있는 에이전트는 단순 텍스트 응답을 넘어서 실제 환경에 영향을 주는 행동을 할 수 있다. 여기서 "실제 환경"이란 파일 시스템, 데이터베이스, 외부 API, 코드 실행 환경 등이다. 이러한 능력이 에이전트의 활용도를 크게 높이지만, 동시에 안전·보안 측면에서 새로운 위험을 만들어낸다.

실제 도구 기반 에이전트를 개발하다 보면 다음과 같은 상황을 만날 수 있다.

• 의도하지 않았는데 파일을 다운로드하거나, 특정 폴더에 연속해서 파일을 저장함.

• 코드 실행 도구가 있을 경우, 불필요한 코드(혹은 잘못된 코드)를 만들어 반복적으로 실행함.

• 여러 도구 사이를 "계속 왔다 갔다" 하며, 목표와 상관없는 반복 작업을 수행함.

• 삭제 관련 도구가 있을 경우, 중요 파일을 지우거나 로그 파일을 대량 삭제하는 등 예측하지 못한 삭제 작업을 수행함.

이러한 위험을 줄이기 위해서는 다음과 같은 설계 원칙이 필요하다.

1. 최소 권한 원칙: 에이전트가 사용할 수 있는 도구와 자원 범위를 최소화한다. 예를 들어, 파일 도구는 특정 작업 폴더 이외에는 접근할 수 없게 제한한다.

2. 안전 장치 추가: 파괴적인 도구(삭제, 대량 전송, 결제 등)는 이중 확인 절차를 넣거나, 사람이 "승인"해야만 실행되도록 한다.

3. 도구 사용 로깅: 모든 도구 호출과 결과를 로그로 남겨, 에이전트가 어떤 결정을 내렸는지 추적 가능하게 만든다.

4. 제한된 반복: 동일한 도구를 일정 횟수 이상 반복 사용하면 경고 또는 중단하도록 설계한다.

요약하면, 도구를 사용할 수 있는 에이전트는 강력한 동시에 위험할 수 있으므로, 설계 단계에서부터 보수적인 권한 설정과 모니터링 체계를 갖추는 것이 필수적이다.

위키피디아 검색·다운로드·파일 저장 예시로 보는 계획과 도구 사용

계획과 도구 사용을 이해하기 좋은 대표적인 예시가 "위키피디아 검색 → 페이지 다운로드 → 파일 저장" 시나리오다. 이 예시는 목표와 도구, 계획 구조가 명확하게 드러나기 때문에 학습용으로 자주 사용된다.

1. 목표(Goal)

사용자 목표는 다음과 같이 정의할 수 있다.

"위키피디아에서 {topic}에 대한 페이지를 검색하고, 각 페이지를 다운로드한 뒤, Wikipedia_{topic}.txt라는 파일로 저장해줘."

여기서 {topic}은 사용자가 지정하는 검색 주제(예: "Calgary")다. 이 목표는 자연어로는 한 문장이지만, 실행 관점에서는 여러 단계로 분해해야 한다.

2. 제공되는 세 가지 액션(도구)

이 목표를 달성하기 위해 에이전트에게 세 가지 도구를 제공한다고 가정하자.

1. search_wikipedia(topic)

   • 입력: 검색어 topic

   • 기능: 해당 검색어로 위키피디아를 검색하고, 관련 페이지들의 ID 목록을 반환한다.

2. get_wikipedia_page(page_id)

   • 입력: 위키피디아 페이지 ID

   • 기능: 지정된 페이지 ID의 실제 문서 내용을 다운로드하여 텍스트로 반환한다.

3. save_file(filename, content) (이름은 예시)

   • 입력: 파일 이름과 저장할 내용

   • 기능: 주어진 내용을 지정한 파일 이름으로 저장한다.

이 세 가지 도구만 있으면, 에이전트는 "검색 → 다운로드 → 저장"이라는 기본 파이프라인을 구성할 수 있다.

3. 계획이 없는 경우의 동작

플래너를 사용하지 않도록 설정(예: Nexus에서 Planner를 None으로 설정)하면, 에이전트는 목표를 텍스트로 이해하긴 해도 구체적인 실행 계획을 구조적으로 세우지 않는다. 이때 흔히 발생하는 패턴은 다음과 같다.

• 첫 단계인 search_wikipedia(topic)는 비교적 잘 호출한다.

• 그러나 그 결과로 나온 페이지 ID 목록을 기반으로 get_wikipedia_page를 여러 번 호출하고, 그 텍스트들을 모아 하나의 문자열로 합치는 작업은 별도의 구조적 계획이 필요하다.

• 또한 최종적으로 save_file("Wikipedia_{topic}.txt", 전체_내용) 형태로 호출해야 하는데, 이 역시 "여러 단계의 결과를 하나로 모아 파일에 저장한다"는 설계가 필요하다.

계획이 없는 에이전트는 이런 순차적 스텝을 따라가다 중간에서 멈추거나, 특정 도구만 반복 호출하고, 혹은 최종 파일 저장에까지 도달하지 못하는 경우가 많다. 즉, 목표를 "끝까지" 달성하기보다는, 목표와 관련된 몇 가지 도구 호출만 하고 답변을 종료해 버릴 가능성이 크다.

4. 계획이 있는 경우의 동작

반대로, OpenAI Assistants처럼 내부에 플래너가 포함된 환경에서 같은 목표와 도구를 제공하면, 에이전트는 다음과 같은 단계적 계획을 세우고 실행한다.

1. 하위 목표 분해

   • 서브태스크 1: 주제 {topic}으로 위키피디아를 검색해 관련 페이지 ID들을 수집한다.

   • 서브태스크 2: 각 페이지 ID에 대해 페이지 내용을 다운로드한다.

   • 서브태스크 3: 모든 페이지 내용을 하나의 문자열로 합친다.

   • 서브태스크 4: 합쳐진 내용을 Wikipedia_{topic}.txt 파일에 저장한다.

2. 도구 매핑

   • 서브태스크 1 → search_wikipedia

   • 서브태스크 2 → get_wikipedia_page (반복 호출)

   • 서브태스크 4 → save_file

3. 순차 실행

   • 먼저 search_wikipedia를 호출하고 결과를 내부 메모리에 저장한다.

   • 이후 각 ID에 대해 get_wikipedia_page를 순차 혹은 병렬로 호출해 내용을 수집한다.

   • 수집된 텍스트를 합치고, 최종적으로 save_file을 호출해 결과 파일을 생성한다.

이 모든 과정은 사용자가 "중간 단계마다 따로 명령하지 않아도" 에이전트가 스스로 수행한다. 사용자는 최종적으로 "원하는 이름의 파일이 만들어졌다"는 결과만 확인하면 된다. 계획 기능 덕분에 에이전트가 도구를 "목표 중심으로 조직화하여" 사용할 수 있게 되는 것이다.

계획과 함께 중요한 피드백(Feedback) 메커니즘

계획이 에이전트의 "앞으로 할 일"을 설계하는 능력이라면, 피드백은 "지금까지 한 일이 잘 되고 있는지"를 평가하고 수정하는 능력이다. LLM 에이전트에서는 두 가지 수준의 피드백이 중요하다.

1. 내부 피드백(자기 평가)

   • 에이전트가 각 단계의 결과를 보고 "이게 목표에 부합하는가?", "오류는 없는가?"를 스스로 점검한다.

   • 예를 들어, 위키피디아 페이지를 다운로드했는데 내용이 비어 있거나, 검색 결과가 너무 적으면 "다시 검색어를 바꿔 시도할지"를 스스로 판단할 수 있다.

2. 외부 피드백(사용자·시스템 평가)

   • 사람이 결과를 보고 "요약이 너무 길다", "이 부분은 잘못되었다"와 같은 코멘트를 주면, 에이전트는 이를 바탕으로 계획을 수정하거나 후속 작업을 수행한다.

   • 또는 별도의 평가 모델(리뷰어 LLM)을 두어, 생성된 계획이나 결과물을 자동으로 검토하게 할 수도 있다.

고급 에이전트 시스템에서는 플래너에 피드백 루프를 통합하기도 한다. 예를 들어 "계획 → 실행 → 평가(피드백) → 필요 시 계획 수정"의 사이클을 여러 번 돌면서 점점 더 나은 결과를 만들어낸다. 이런 구조는 복잡한 작업이나 장기 목표에서 특히 중요하다. 처음 계획이 완벽할 수 없기 때문에, 실행 결과를 바탕으로 스스로 계획을 조정할 수 있어야 한다.

피드백을 잘 활용하면 다음과 같은 효과를 기대할 수 있다.

• 잘못된 도구 사용을 조기에 감지하고 중단할 수 있다.

• 결과 품질이 높아진다(예: 요약의 정확도, 코드의 버그 감소).

• 반복 작업이나 무의미한 행동 패턴을 스스로 줄일 수 있다.

결국, 안정적이고 신뢰할 수 있는 에이전트를 만들기 위해서는 "계획 + 피드백"을 함께 설계해야 하며, 계획만 있는 시스템은 쉽게 오동작하거나 목표에서 벗어날 수 있다는 점을 기억해야 한다.

마무리: 실전 설계 시 기억해야 할 포인트

정리하면, LLM 에이전트를 설계할 때 다음과 같은 원칙을 기억해 두면 도움이 된다.

1. 계획은 필수

   • 목표를 스스로 분석하고 하위 작업을 구성하는 플래너가 있어야 복잡한 작업을 안정적으로 수행할 수 있다.

2. 단순 챗봇과 에이전트는 다르다

   • 챗봇은 "해당 질문에 대한 답변"을 중심으로, 에이전트는 "전체 목표 달성"을 중심으로 설계된다.

3. Nexus + Gradio로 실습

   • Planner 유무, 도구 구성을 바꿔 보면서 에이전트의 행동 차이를 실험해 보면 이해가 빨라진다.

4. 도구는 최소한으로, 목적에 맞게

   • 도구가 많을수록 혼란과 위험이 증가한다. 필요한 것만, 최소 권한으로 제공하자.

5. 안전과 보안을 항상 고려

   • 파일, 코드, 외부 API를 다루는 도구는 특히 조심해야 하며, 로그와 제한, 승인 절차 등을 설계해야 한다.

6. 피드백 루프 통합

   • 계획 → 실행 → 피드백 → 계획 수정의 사이클을 통해 에이전트의 품질과 안정성을 지속적으로 높일 수 있다.

이 노트를 바탕으로, 위키피디아 예시처럼 목표·도구·계획·피드백이 어떻게 연결되는지를 직접 실습해 보면, LLM 에이전트 설계에 대한 감각을 훨씬 빠르게 익힐 수 있을 것이다.