기존 AI가 "질문하면 답하는" 방식이었다면,
AI 에이전트는 목표를 주면 스스로 계획을 세우고, 도구를 사용하고, 여러 단계를 거쳐 작업을 완수하는 AI이다.
어떻게 스스로 계획을 세우고 작업을 완수할 수 있을까?
에이전트가 어떻게 사고하는지에 대해 찾아보았다.
에이전트 내부 사고 루프 (Cognitive Architecture)
- Planning (계획): 사용자 요청을 분석하여 이를 달성하기 위한 작은 단위의 단계(Step)들로 나눈다.
- Tool Use (도구 사용): 웹 검색, 코드 실행, 데이터베이스 조회 등 외부 API를 호출하여 필요한 정보나 결과를 얻는다.
- Action & Observation (실행 및 관찰): 결과를 확인하고, 확인한 내용을 바탕으로 ReAct 방식으로 계획을 수정하거나 다음 단계로 넘어갈지 결정한다.
- Memory (메모리): 이전 대화 맥락이나 중간 결과물들을 기억하고 참조한다
ReAct
에이전트는 단일 작업을 처리할 때 ReAct(Reason + Act) 패턴이 가장 널리 쓰인다.
ReAct 란 Reason + Act 의 합성어로, 문제를 해결하는 과정에서 추론과 행동을 결합하는 새로운 패러다임이다.
기존의 언어 모델들이 주로 추론이나 행동 중 하나에 집중했던 반면, ReAct는 이 두 가지 기능을 통합하여 시너지 효과를 창출한다.
실행(Act)과 그 결과에 대한 관찰(Observation), 그리고 이를 바탕으로 한 새로운 사고(Thought)를 반복하여 결과를 도출한다.
예시
AI 에이전트에게 "게시판 만들어줘" 라고 요구할 경우
1. Planning (계획 단계)
사용자의 "게시판 만들어줘"라는 추상적인 요청을 실행 가능한 단위로 쪼갠다.
실행 가능한 단위: 에이전트가 한 번의 도구 호출이나 한 번의 추론으로 성공/실패 여부를 확인할 수 있는 최소한의 작업
- 사고(Thought): "게시판을 만들려면 데이터 스키마 정의, API 엔드포인트 구현(CRUD), 프런트엔드 UI 구성이 필요하겠군. 우선 기술 스택을 결정하고 단계별로 진행하자."
- 수립된 계획
- 기술 스택 선정 (예: Spring Boot + JPA)
- 게시글(Post) 엔티티 및 Repository 생성
- CRUD 기능이 담긴 Controller 및 Service 구현
- 동작 확인을 위한 테스트
2. Tool Use (도구 사용 및 실행)
에이전트가 실제로 코드를 작성하거나 파일을 생성하는 도구를 호출한다
- Action (Act): create_file("Post.java", "public class Post { ... }")
- Action (Act): create_file("PostController.java", "...")
- 에이전트는 이 과정에서 개발 환경에 접근하거나 코드 생성 라이브러리를 사용하게 된다
3. Action & Observation (관찰 및 계획 수정)
도구 사용 후 돌아온 결과를 확인하고 다음 행동을 결정한다.
- Observation (관찰): 코드 생성은 완료되었으나, 빌드 도구 실행 중 에러가 발생함을 확인
- Thought (재판단): "아, 빌드 설정 파일(pom.xml 또는 build.gradle)에 의존성을 추가하는 단계를 빠뜨렸구나. 계획에 '의존성 체크' 단계를 추가하고 수정해야겠다."
- Revised Action (수정된 실행)
4. Memory (메모리 참조)
작업 중간중간 이전 단계에서 결정한 사항을 잊지 않고 기억해 불필요하게 비대해지는 설계를 방지한다.
최종적인 에이전트의 흐름 요약
- [Thought] "게시판 제작 시작. 우선 DB 구조부터 잡자."
- [Action] 엔티티 코드 작성 및 파일 저장.
- [Observation] 저장 완료. 문법 오류 없음.
- [Thought] "성공적이야. 이제 이 데이터를 다룰 컨트롤러를 만들 차례군."
- [Action] 컨트롤러 코드 작성.
- [Observation] 작성 중 특정 라이브러리 참조 에러 발생.
- [Thought] "오타가 있었네. 다시 수정해서 저장하자." (ReAct에 의한 계획 수정)
- [Final Output] "게시판 기본 코드 구현이 완료되었습니다. Post, Service, Controller 파일을 확인해 보세요."
자료를 찾다보니 어떤 식으로 요청을 해야 토큰 소모량을 효율적으로 사용하고, 정확한 결괏값을 뽑아낼 수 있을지 감이 잡혔다.
AI 에이전트의 특성을 고려하여 하이브리드 방식이 가장 토큰 효율이 좋다고 판단했다.
- 구조: 디테일 하게 쪼개지 않고 한번의 요청으로 처리한다
- 엔티티 구조와 API 명세서 같은 설계도는 한 번의 요청으로 크게 뽑는다
- 설계도가 이미 존재한다면 설계도를 분석을 요청하여 컨텍스트를 주입(Context Injection) 시킨다
- 구현: "방금 만든 설계를 바탕으로 PostController의 등록 기능만 구현해줘" 식으로 실제 로직은 쪼개서 요청한다
구조를 AI에게 구현하게 시킬 경우, AI가 전체 맥락을 파악한 상태이기 때문에 세부 작업을 수행할 때 일관성도 훨씬 높아진다.