튜토리얼은 따라가는데 혼자 설계하려면 손이 멈추는 이유
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 내부 로직일 수도 있다)
이 정도만 명확해져도 혼자서 구조를 잡는 데 큰 도움이 된다.
이전에는 “왜 안 되지?”였다면
지금은 “어디서 나눠야 하지?”를 먼저 본다.
마무리하며
이 글은 정답을 정리한 글이 아니다. (사실 첫 글이라 떨린다)
지금 시점의 내가 어디까지 이해했는지를 기록한 글이다.
나중에 다시 읽었을 때
“아, 이때는 여기까지 왔었구나”라고 느낄 수 있다면 좋겠다.
함께 읽으면 좋은 글
글쓴이 · Plutojoshua
핀테크에서 LLM과 AI 에이전트를 실제 서비스에 적용하는 개발자다. 카카오 AI 앰배서더로 Kanana 모델을 앱에 직접 연동해 검증하고, 비전공자로 시작해 실제 코드와 측정값을 근거로 “왜 그렇게 설계했는지”를 1인칭으로 기록한다. 운영자 소개는 About, 코드는 GitHub에서 볼 수 있다.
“LangChain으로 Agent를 만들 때, 왜 항상 ‘구조’에서 막힐까”에 대한 2개의 생각