왜 프레임워크가 필요한가 — 루프를 계속 손으로 고칠 것인가

한 줄 요약

9~10장에서 에이전트 루프를 직접 구현하며 작동 원리를 살펴봤습니다. 다만 이 방식에서는 기능을 추가할 때마다 루프 코드도 직접 수정해야 합니다. 이번 장에서는 LangChain 프레임워크로 같은 에이전트를 구성하고, 프레임워크가 대신 처리하는 부분과 우리가 직접 구현해야 하는 부분을 확인합니다.

1. 직접 만든 루프의 다음 걸음

guarded_react_loop는 잘 돌아갑니다. 그런데 앞으로 필요한 것을 꼽아 보면 이렇습니다.

앞으로 필요한 것	직접 만든 루프에서는
지난 대화를 기억하고 이어 가기 (16장)	`contents`를 저장하고 불러오는 코드를 새로 짠다
처리 과정을 화면에 실시간으로 보내기 (24장)	루프 곳곳에 내보내는 코드를 끼워 넣는다
에이전트를 여러 개 두기 (21장)	루프를 에이전트 수만큼 복사한다
다른 회사의 모델로 바꿔 보기	호출과 응답을 다루는 코드를 전부 다시 쓴다

하나하나는 할 수 있는 일입니다. 다만 이 일들은 하루마켓에만 필요한 것은 아닙니다. 어느 회사의 어느 에이전트든 똑같이 필요한 부분입니다.

2. 프레임워크란

프레임워크(framework) 는 여러 프로그램에 공통으로 필요한 뼈대를 미리 만들어 둔 것입니다. 우리는 뼈대를 다시 짜지 않고, 그 위에 우리 서비스에만 있는 것을 얹습니다.

LLM 에이전트를 만들 때 널리 쓰이는 프레임워크가 LangChain(랭체인) 입니다. 이 과정은 LangChain v1을 씁니다. 에이전트 루프를 만들어 주는 함수 이름은 create_agent입니다.

3. 왜 직접 만든 다음에 쓰는가

이 과정은 같은 순서를 두 번 밟았습니다.

5장에서 함수 호출의 왕복을 손으로 한 뒤, 6장에서 자동 호출을 썼습니다.
9장에서 루프를 손으로 만든 뒤, 이번 장에서 프레임워크를 씁니다.

create_agent는 몇 줄이면 에이전트를 만들어 줍니다. 그 안에서 무슨 일이 일어나는지 모르면 편리한 상자일 뿐이고, 상자는 이상하게 동작할 때 손댈 곳이 없습니다. 지금 우리는 그 안에 9장의 for 루프와 같은 것이 돌고 있다는 것을 압니다.

4. 이걸 모르면 무엇을 판단하지 못하는가

프레임워크를 쓴 에이전트가 이상한 답을 했을 때 어디를 봐야 하는지 모릅니다. 봐야 할 것은 9장과 똑같습니다. 어떤 도구를 불렀고 무엇을 받았는가.
프레임워크가 해 주는 것과 해 주지 않는 것을 가르지 못합니다. 권한 경계(8장)와 비용 상한(10장)이 자동으로 따라오는지 아닌지.
프레임워크로 옮길 때 지금까지 만든 것 중 무엇을 버리고 무엇을 가져가는지 모릅니다.

5. 이번 장에서 하는 일

순서	하는 일
1	LangChain의 구성 요소와 모델 어댑터를 알아본다
2	9~10장의 부품이 LangChain에서 각각 무엇이 되는지 맞춰 본다
3	`create_agent`로 상담 에이전트를 만들고 실행 과정을 추적한다
4	프레임워크로 옮긴 뒤에도 우리에게 남는 일을 확인한다

이번 장의 산출물은 lesson11_langchain_agent.py입니다. 여기서 만든 구조가 21장 전문 에이전트의 뼈대가 됩니다.

핵심 정리

직접 만든 루프는 기능이 늘 때마다 우리가 고쳐야 합니다. 그 일은 하루마켓과 상관없는 공통 부분입니다.
프레임워크는 공통 뼈대를 미리 만들어 둔 것입니다. 우리는 그 위에 우리 것만 얹습니다.
이번 장에서 쓰는 것은 LangChain v1의 create_agent 입니다.
원리를 알고 쓰는 것이 전제입니다. create_agent 안에는 9장의 루프와 같은 것이 돕니다.