에이전트는 모델이 아니라 상태 기계다

한 줄 요약

에이전트는 모델이 아니라 상태 기계다. 어려운 부분은 모델을 부르는 자리가
아니라, 언제 멈출지·무엇을 들고 다닐지·실패하면 어디로 갈지를 정하는 자리다.

왜 필요한가 — 데모와 제품이 갈리는 곳

에이전트 데모는 대개 잘 돈다. 질문 하나를 넣으면 도구를 부르고 답이 나온다.
그런데 제품이 되는 순간 세 가지가 한꺼번에 터진다.

• 멈추지 않는다. 도구가 원하는 답을 못 주면 계속 다시 시도한다. 토큰

청구서가 그 사실을 알려 준다.

• 모르는 것을 지어낸다. 조회가 빈손으로 돌아왔는데 답을 만들어 낸다.
• 왜 그랬는지 모른다. 같은 질문에 다른 답이 나오는데, 어느 경로를

지났는지 기록이 없다.

셋 다 모델의 문제가 아니다. 그래프의 문제다. 그래서 이 코스는 모델을
부르지 않고 그래프만 다룬다. 모델을 붙이는 것은 노드 하나를 바꾸는 일이고,
그 자리는 어렵지 않다.

상태는 덮어쓰는가, 쌓이는가

LangGraph 에서 노드는 바꿀 부분만 담은 딕셔너리를 돌려준다. 그것을 어떻게
합칠지는 상태 타입이 정한다.

class State(TypedDict):    question: str    steps: Annotated[list, operator.add]   # 쌓인다    tries: int                              # 덮어쓴다

Annotated[list, operator.add] 가 없으면 마지막 노드가 돌려준 값만 남는다.
그러면 "지나온 길" 이 사라지고, 나중에 무슨 일이 있었는지 물어볼 수 없다.
무엇을 쌓고 무엇을 덮어쓸지는 설계 결정이다.

현장에서

면접에서 "에이전트를 만들어 봤나" 를 물으면 실제로 듣고 싶어 하는 것은
프레임워크 이름이 아니라 이 세 가지다 — **끝내는 조건을 무엇으로 두었나,
도구가 실패하면 어디로 보내나, 무엇을 남겨 두었나.**

그리고 이건 에이전트만의 이야기가 아니다. 재시도 상한, 실패 경로, 관측
기록은 백엔드에서 늘 하던 판단이다. LangGraph 는 그 판단을 그래프로 적게
해 줄 뿐이다.