Reflexion은 앞 편의 Reflection을 확장한 것이다. 이름에 "X" 하나가 더 붙은 정도의 차이가 아니다. Reflection이 의견을 다듬는 데 그쳤다면, Reflexion은 외부 도구(웹 검색)로 최신 정보를 끌어오고, 인용·출처를 붙여 답을 검증 가능하게 만든다. 학습 이후에 나온 새 정보까지 반영해 스스로 개선하는 셈이다.

 

1. Reflection과 무엇이 다른가

Reflexion 에이전트의 강점은 넷이다.

  • 자기개선 — 한 번 반영하고 끝이 아니라, 매 반복마다 성능을 분석하며 나아진다.
  • 약점 발견·수정 — 실행 후 무엇이 잘못됐는지 돌아보고 추론·전략을 고친다.
  • 외부 정보 통합 — 웹 검색·API 같은 도구로 실시간 데이터를 가져와 정확도를 높인다.
  • 근거 제시 — 반영 과정을 통해 인용·출처로 답을 뒷받침한다.

 

2. 핵심 장치 — 구조화된 출력(스키마)

Reflexion이 도구·비평·질의를 섞어 쓰려면, LLM이 정해진 형식으로 출력해야 한다. 자유 텍스트 대신 Pydantic 스키마(클래스)를 정의하고 bind_tools로 묶으면, LLM은 그 클래스를 함수처럼 취급해 필드가 채워진 JSON 객체를 내놓는다. 그래야 응답·비평·검색어를 헷갈리지 않고 구분해 다음 단계로 넘길 수 있다.

 

 

3. Reflexion의 흐름 — Responder → 검색 → Revisor

동작은 세 요소가 돌린다. Responder(응답자)가 초기 답과 자기비평, 검색어를 구조화해 내놓는다. 그 검색어로 도구(예: Tavily 웹 검색)가 실제 정보를 가져온다. Revisor(수정자)가 검색 결과와 비평을 반영해 답을 고치고 인용·references를 붙인다. 이 과정을 response_list에 쌓으며 정해진 횟수만큼 반복한다.

그림 1. Reflexion 흐름. Responder가 검색어를 만들고, 도구가 정보를 가져오면 Revisor가 인용을 붙여 고친다.

 

 

4. LangGraph로 구현하기

Revisor는 Responder와 같은 필드에 인용(references)을 더한 스키마를 쓴다. 상속으로 간단히 만든다.

노드는 셋이다. respond(초기 응답), execute_tools(검색어로 도구 실행), revisor(검색 결과·비평 반영해 수정). 엣지로 respond → execute_tools → revisor를 잇고, revisor 뒤에는 반복 여부를 정하는 조건부 엣지를 둔다. event_loop는 지금까지의 도구 호출 수를 세어 정해진 횟수(예: 4회)를 넘으면 종료, 아니면 다시 검색으로 보낸다.

그림 2. Reflexion의 LangGraph 그래프. respond→execute_tools→revisor를 돌며, 정해진 반복 수에 도달하면 END로.

 

실행하면 초기 응답자가 일반적 답을 내놓고, 검색을 거쳐 Revisor가 과학적 인용과 측정 가능한 지표를 더해 답을 정교하게 만든다. 반복이 쌓일수록 근거가 탄탄해진다. (물론 이는 의학적 조언이 아니라 파이프라인 예시다.)

 

다음 글부터는 여러 에이전트가 협력하는 세계로 넘어간다. 단일 에이전트에서 멀티 에이전트 시스템으로 왜, 어떻게 확장하는지 다룬다.

+ Recent posts