튜토리얼은 따라가는데 혼자 설계하려면 손이 멈추는 이유
AI 개발자에 입문하면 가장 많이 듣는 툴, LangChain.
LangChain 공식 튜토리얼을 보면 에이전트를 만드는 건 생각보다 쉬워 보인다.
Tool 붙이고,
Memory 추가하고,
Agent를 하나 선언하면 끝이다.
그런데 막상 내 문제를 풀어보려고 하면 손이 멈춘다.
“뭐부터 해야 하지?”
이 글은 에이전트가 무엇인지 설명하려는 글이 아니다.
왜 혼자 설계하려고 하면 항상 구조에서 막히는지
그 이유를 지금 시점의 나 기준으로 정리해본 글이다.
1. 튜토리얼은 되는데, 혼자서는 안 되는 이유
생각해보면 간단하다.
튜토리얼에는 항상 ->
- 문제 정의가 이미 되어 있고
- Tool의 역할이 정해져 있으며
- Agent가 무엇을 해야 하는지도 명확하다.
하지만 실무에서는 이 중 어느 하나도 정해져 있지 않다.
그래서 나는 Agent를 만드는 단계가 아닌 “문제를 쪼개는 단계”에서 계속 멈췄다.
2. LLM과 Agent를 같은 것으로 착각했다
입사 초반에는 LLM이 똑똑하면 Agent도 알아서 잘 돌아갈 거라 생각했다.
사실 지금도 LLM과 Agent를 혼동해서 쓰는 경우를 많이 봤다.
그만큼 급격하게 바뀌는 환경이기도 하고,
개념들이 서로 겹쳐 보이기 때문이라고 생각한다. (머신러닝 안에 딥러닝, 그 안에 AI처럼)
정리하면 LLM은 질문에 답하는 역할에 가깝고 Agent는 일을 나누고 흐름을 관리하는 구조에 가깝다.
이 둘을 구분하지 못하면 계속 “왜 얘가 이걸 했지?” 같은 상황이 반복된다.
3. Tool / Memory / Planner를 다시 정의해보니
이걸 문서 기준이 아니라 내가 실제로 쓰면서 이해한 기준으로 정리해보면 이렇다.
- Tool: 기능 목록이 아니라 선택 가능한 행동들
- Memory: 로그가 아니라 맥락을 유지하기 위한 장치
- Planner: 마법이 아니라 분기 기준
이렇게 나누고 나니 Agent를 “한 덩어리”가 아니라 역할이 있는 구성 요소로 보기 시작했다.
4. 내가 진짜로 몰랐던 건 ‘구조를 나누는 기준’이었다
지금 돌아보면 Agent가 어려웠던 이유는 기술이 아니라 설계 기준이 없었기 때문이다.
- 이 판단은 LLM이 해야 할까?
- 아니면 코드로 분리해야 할까?
- 이 상태는 Memory에 남겨야 할까?
이제 에이전트를 개발하기 전에 항상 이 질문을 던진다.
무작정 만드는 것이 아니라 만들기 전에도, 만들면서도, 다 만들고 QA를 진행할 때도 항상 고민하는 부분이다.
그래야 내가 만들려고 하는 진정한 의미의 에이전트 구현이기 때문이다.
실제로 에이전트를 만들 때 이 질문을 가지고 시작한다면 설계가 훨씬 수월해 질 것이다.
5. 지금 시점에서 정리한 최소 Agent 구조
아직 완벽하진 않지만 나는 Agent를 이렇게 나눈다.
- LLM: 판단 담당
- Tool: 실행 담당
- Memory: 상태 유지
- Orchestrator: 흐름 제어 (실제로는 코드일 수도 있고, LangChain 내부 로직일 수도 있다)
이 정도만 명확해져도 혼자서 구조를 잡는 데 큰 도움이 된다.
이전에는 “왜 안 되지?”였다면
지금은 “어디서 나눠야 하지?”를 먼저 본다.
마무리하며
이 글은 정답을 정리한 글이 아니다. (사실 첫 글이라 떨린다)
지금 시점의 내가 어디까지 이해했는지를 기록한 글이다.
나중에 다시 읽었을 때
“아, 이때는 여기까지 왔었구나”라고 느낄 수 있다면 좋겠다.
