Agent의 기본구조에서 한단계 더 나아가 advanced topic에 대해서 다루어 보자.

Contents

• Agent - skills
• Agent - Plug-in
• Agent - subagents system.
• Agent - Planning
• Agent - Reflection
• Agent - Reason and act.

기존 agent의 단순 프로세스에서 더 성능을 높이기 위해, 실제로 사용되는 3가지 reasoning / prompting strategy에 대해서 살펴보도록 하자. 이번 시간에도 Cursor IDE에서 어떻게 사용되는 지 이론과 연결해서 살펴보자. (이 방법들은 LLM model 자체를 개선하는 것이 아니라, prompt를 개선하여 performance를 더 높이는 방법이므로, prompt engineering 이라고 불린다)

Agent planning

에이전트가 바로 답을 뱉지 않고, 목표를 쪼개고(서브태스크), 순서/의존성을 정하고, 필요한 도구/정보를 미리 추정하는 단계. (당연히 user자체가 plan을 먼저 주면, LLM을 더 적게 쓰고, 더 좋은 결과가 나올 수 있음)
- 좋아지는 지점:
- 멀티스텝 작업(“자료 조사 → 요약 → 표 만들기 → 보고서 작성”)에서 누락/중복 감소
- 긴 작업에서 방향성 유지(드리프트 방지)
- 도구 호출을 더 “필요할 때만” 하게 되어 비용/시간 최적화 가능
- 항상 좋은 건 아닌 이유:
- 너무 작은/즉답형 문제에서는 계획 단계가 오버헤드(토큰·지연)만 늘릴 수 있음
- 계획이 “그럴듯하지만 틀린” 방향으로 굳어지면 오히려 악화(잘못된 프레임 고착)

Cursor IDE에 들어가게 되면 plan mode를 먼저 활성화 할 수 있다.(필요에 따라 자동으로 활성화)

(개인적으로는 이렇게 어떤 작업을 진행할때, 나 스스로도 생각을 깊게 하기 위해서 process를 직접 적어놓고, 실행하라고 하는 편이다, 경험상 훨씬 performance가 좋다)

Agent Reflection

에이전트가 자기 결과를 점검하고 고쳐 쓰는 메커니즘. (자기검토, 비평-수정, hindsight/retrospective 등). 즉, LLM호출을 한번만 하는게 아니라 계속해서 생각이 끝날때 까지, 호출을 한다. 생각을 끝내는 기준은 max iteration = 5 (사용자 지정)으로 보통 설정하고 (LangGraph 기준), 그 전에 스스로 끝낼 수 도 있다.
- 좋아지는 지점:
- 논리 오류/사실 불일치/요구사항 누락을 줄임
- 글 품질(일관성, 톤, 구조) 개선
- “정답률”보다 **실무 품질(완성도)**이 중요한 경우 효과 큼
- 항상 좋은 건 아닌 이유:
- 추가 패스 = 비용/지연 증가
- 잘못된 확신을 가진 모델은 “더 그럴듯하게” 합리화할 수도 있음(검토가 사실 검증이 되진 않음)
- 그래서 Reflection은 종종 **외부 근거(툴, 테스트, 검색, 규칙 기반 체크)**와 같이 붙일 때 진짜 강해집니다.

Agent - Reason and Act

생각(Reasoning)과 행동(Act: 도구 호출/환경 상호작용)을 번갈아 수행하면서, 매 단계 도구 결과를 보고 다음 행동을 결정하는 방식. 이전 Reflection은 끊임없이 생각만 진행하지만, Reason and Act는 액션도 같이 진행하여, loop를 돈다. tool
- 좋아지는 지점:
- “정보가 부족하면 검색하고, 계산이 필요하면 실행하고, 확인이 필요하면 테스트”처럼
불확실성을 도구로 해소함 → 환각 감소, 성공률 증가
- 오픈월드 문제(검색/DB/코드실행/워크플로우)에서 특히 강력
- 항상 좋은 건 아닌 이유:
- 툴 호출이 잦으면 비용/지연이 커짐
- 툴이 느리거나 실패/제한이 있으면 전체 성능이 흔들림
- 그래서 보통 “언제 툴을 쓸지”에 대한 **게이팅(조건부 호출)**이 같이 설계됩니다.

Conclusion

이번 글에서는 Agent의 성능을 끌어올리는 대표적인 3가지 방식—Planning, Reflection, ReAct(Reason-and-Act)에 대해서 이야기 해보았습니다. 공통점은 모델 자체를 바꾸는 것이 아니라, 에이전트가 “생각을 조직하고, 결과를 검증하고, 필요한 경우 도구로 불확실성을 해소하도록” 프롬프트/루프 구조를 설계한다는 점.
- Planning은 실행 전에 목표를 서브태스크로 분해하고 순서·의존성을 정해, 멀티스텝 작업에서 누락과 드리프트를 줄입니다.
- Reflection은 산출물을 다시 점검·수정하는 반복 패스로, “정답률”보다 **실무 완성도(요구사항 준수, 일관성, 문장 품질)**가 중요한 상황에서 특히 강합니다.
- ReAct는 “추론 ↔ 행동(도구 호출)”을 번갈아 수행하며, 검색·코드 실행·테스트 같은 외부 근거로 불확실성을 줄여 환각을 낮추고 성공률을 높이는 데 유리합니다.

결국 model 자체의 성능을 올리는 것은 LLM model 제공하는 회사들에서 진행을 하고 있고, 그 이후에 더 좋은 action, response를 어떻게 뽑아낼 수 있을까? 라는 post processing 방식들이 계속해서 계발되고 있고 이를 prompt engineering 이라고 칭한다.
사실 우리가 만들 수 있는 경우의 수는 굉장히 다양하고, 레고 조각 같은 구조이다. 현재 주어진 문제를 풀기 위해서, 레고를 어떻게 조합해야할까? 즉, 적절한 구조와 조합들을 생각해내는 힘이 필요한 생각이 든다.
무엇보다 많은 레고조각을 만들어보고 해체해보고, 여러 경험을 해보는 것이 무엇보다 중요하다라는 생각이 든다.