요즘 AI Agent에 대한 이야기가 많다. 툴을 붙이고 모델이 판단하고 다음 행동을 고르고 필요하면 다시 도구를 호출한다. 마치 소프트웨어가 스스로 다음 단계를 정하는 것처럼 보인다.
이 변화는 생각보다 낯설지 않다. 오히려 오래된 소프트웨어의 역사 위에 아주 자연스럽게 이어진 흐름에 가깝다.
과거에도 소프트웨어를 개발할 땐 플로우차트를 그려서 개발을 했었다. 입력이 들어오고, 어떤 판단을 거쳐서 다음 단계로 가고 결과를 내놓는 구조 자체가 이미 하나의 그래프였다.
이 관점에서 접목하면 Agent는 마법이 아니라, 소프트웨어가 흐름을 다루는 방식이 바뀌는 과정에 가깝다.
소프트웨어의 시작은 결국 "순서"였다.
아주 초창기 소프트웨어 개발은 지금처럼 거대하지 않았다. 해야 할 일도 비교적 단순했다. 입력을 받고, 계싼하고, 출력하면 끝이었다. 프로그램은 일종의 절차였다. 한 줄을 실행하고, 그 다음 줄을 실행하고... 조건이 맞으면 분기하고 아니면 다음으로 넘어간다.
이걸 가장 직관적으로 보여주는 것이 플로우차트다. 네모 상자 안에 해야할 작업을 넣고 화살표로 다음 작업을 연결한다. 이 방식은 단순한 시각화 도구가 아니라, 소프트웨어의 본질을 꽤 정확하게 보여준다.
프로그램은 결국 "어디에서 어디로 흘러가는가?"의 문제였기 때문이다.
쉽게 설명하면,
- 어떤 작업이 있다.
- 그 다음에 올 수 있는 작업이 있다.
- 특정 조건이면 다른 경로로 간다.
- 마지막에는 종료된다.
이 자체가 이미 그래프다. 노드가 있고, 노드 사이를 잇는 방향으로 연결되어 있다.
이 관점은 중요하다. Agent도 결국 이 틀을 벗어나지 않기 때문이다. Agent가 새로워보여도 여전히 무언가를 보고, 다음 행동을 정하고 그 결과를 바탕으로 다시 다음 행동을 정한다. 즉, 여전히 그래프 위에서 움직인다.
시스템이 커질수록 사람은 흐름을 더 엄격하게 통제한다.
처음에는 단순한 절차 프로그램이면 충분했지만, 시간이 지나면서 처리해야 할 작업이 폭발적으로 늘었다. 데이터 파이프라인, 배치 작업, ETL, 머신러닝 학습 파이프라인처럼 순서와 의존성이 중요한 일이 많아졌다.
여기서 등장한 것이 DAG(Directed Acyclic Graph)이다. 방향이 있고, 순환이 없는 그래프라는 의미이다. 즉, 작업 순서와 실행 조건을 명시하는 구조라고 이해하면 된다.
예를 들어 원천 데이터를 일고 -> 정제하고 -> 집계하고 -> 리포트를 만든다와 같은 흐름은 전형적인 DAG다. 하나의 작업이 끝나야 다음 작업이 시작된다. 보통 반대로 되돌아가지 않는다.
소프트웨어가 복잡해질수록 우리는 로직 자체외에 흐름의 관리를 소프트웨어로 만들게 된다. 단순히 기능을 만드는 것이 아니라, 어떤 기능이 언제 어떤 조건에서 어떤 순서로 움직여야 하는지를 정교하게 설계하게된다.
DAG의 본질은 사람이 모든 경로를 설계하는데 있다.
DAG 기반 시스템은 강력하다. 실행 순서를 통제할 수 있고, 실패 지점을 추적할 수 있고, 어느 작업이 어떤 작업에 의존하는지 명확하게 알 수 있다. 장애가 발생하면 어디서 실패를 했는지 찾기도 좋다.
하지만 이 구조는 필요한 전제가 있다. 사람이 경로를 안다는 전제다.
즉, 누군가는 미리 이런 경로를 만들어두어야 한다.
- 먼저 무엇을 실행할지
- 실패하면 어디로 갈지
- 특정 조건이면 어떤 가지로 분기할지
- 어떤 작업이 끝나야 다음 작업을 실행할지
위에 언급한 내용은 상당히 익숙한 개발 방식이다. 모든 경우의 수를 코드와 규칙으로 먼저 정의하는 방싱이다. 이게 잘 설계된 소프트웨어가 안정적인 이유도 여기에 있다. 컴퓨터는 미리 정해놓은 규칙을 가장 잘 따르기 때문이다.
문제는 현실이 점점 이런 방식에 딱 맞춰서 되지 않는다는 점이다. 우리가 다루는 일 중에는 사전에 모든 경로를 정의하기 어려운 것이 많기 때문이다. 예를 들면 아래와 같은 것들이다.
- 사용자의 질문 의도를 먼저 해석해야 한다.
- 문서를 읽고 다음 행동을 정해야 한다.
- 오류 메시지를 보고 어떤 도구를 쓸지 선택해야 한다.
- 중간 결과를 보고 계획 자체를 수정해야 한다.
물론, 이런 것들은 전통적인 DAG로 만들 수 있다. 그러나 코드가 길어지고, 조건문도 많아지게 된다. 여기서 의문이 생긴다.
"정말 사람이 모든 경로를 미리 정해야 할까?"
Agent는 경로를 사람이 전부 정하지 않아도 된다라는 발상에서 시작된다.
LangGraph는 워크플로우와 Agent를 구분한다. 워크플로우는 미리 정해진 코드 경로를 따르지만 에이전트는 스스로 프로세스와 도구 사용을 정의하는 동적 구조라고 설명한다.
즉, 워크플로우는 다음 단계가 이미 정해져 있는 시스템이고, 에이전트는 지금 상태를 보고 다음 단계를 고르는 시스템이다.
둘 간의 차이는 생각보다 크다. 워크플로우 방식에서는 사람이 경로를 먼저 정해놓아야 한다. 에이전트 방식에서는 사람이 할 수 있는 행동들과 목표를 정의하고, 실제 경로 선택은 모델에게 맡기는 구조다.
예를 들면,
워크플로우:
- 질문이 들어온다.
- FAQ를 찾는다.
- 없으면 상담원에게 넘긴다.
현실 세계의 문제가 위 정도로 깔끔하다면 가능하다.
에이전트:
- 질문이 들어온다.
- 모델이 질문 의도를 해석한다.
- 지식베이스 검색이 맞는지, 다른 요청인지 판단한다.
- 필요한 도구를 호출한다.
- 결과를 보고 다음 행동을 정한다.
즉, 전체 흐름은 그대로인데, 그때그때 어떤 선을 탈지 여부를 모델이 고른다. 그래서 에이전트는 그래프를 버린 새로운 개념이라기보다 그래프 위에서 의사결정 주체가 바뀐 구조라고 보는 쪽이 이해하기 쉽다.
에이전트 시대라기보다, 소프트웨어의 무게중심 이동에 가깝다.
많은 에이전트에 대한 이야기들이 마치 기존 소프트웨어가 끝나고 완전히 다른 무언가가 시작된 것처럼 보이게 만든다.하지만 실제로는 무게중심의 이동에 더 가깝다.
예전에는 사람이 경로를 정의하고, 컴퓨터는 정해진 경로를 빠르고 정확하게 실행했다.
지금은 사람은 목표, 제약, 도구, 상태등의 구조를 정의하고 모델은 현재 상태를 보고 다음 행동을 고른다. 시스템은 그 선택을 안전하게 실행한다.
LangGraph가 스스로를 long-running, stateful agents를 위한 오케스트레이션이라고 설명하는 것도 같은 맥락이다. 에이전트가 오래 실행되고, 상태를 갖고, 디버깅과 배포를 고려해야 한다는 말은 결국 에이전트도 소프트웨어 엔지니어링 대상이라는 뜻이다.
AI가 판단을 돕는다고 해서 시스템 설계가 덜 중요해지는 것은 아니다. 오히려 더 중요해진다. 예전에는 정해진 것만 실행하는 시스템을 만들면 됐지만, 지금은 상황에 따라 다르게 움직일 수 있는 시스템을 다뤄야 하기 때문이다.
이걸 가장 쉽게 비유하면 자동차 네비게이션과 비슷하다. 예전에는 종이 지도에 가까웠다. 출발 전 미리 경로를 다 그린다. 어디서 좌회전할지, 어디서 직진할지, 어디서 우회전할지 사람이 먼저 정한다. 이게 전통적인 워크플로우와 비슷하다.
에이전트 방식은 실시간 네비게이션에 가깝다.
목적지는 정해져 있지만, 막히는 길이 있으면 우회하고, 사고가 있으면 다른 길을 추천하고, 현재 상황을 반영해서 경로를 계속 수정한다.
여기서 중요한 것은 목적지가 사라진게 아니라는 점이다. 그리고 차량 제어가 없어지는 것도 아니다. 브레이크와 핸들, 도로 규칙, 제한속도는 여전히 필요하다. 단지 길을 고르는 방식이 달라진 것이다.
에이전트 관점에서는 목적지는 목표고, 지도는 컨텍스트고, 갈 수 있는 길은 도구들이고, 네비에기션 엔진은 LLM이고, 차량의 안전장치는 소프트웨어 시스템이다.
이 비유로 보면 에이전트가 왜 신기하지만 결국 소프트웨어 문제인지 이해하기 쉬워진다.
그래서 좋은 에이전트는 LLM이 똑똑해서보다 단단한 시스템으로 감싸면 잘 동작한다.
모델만 좋으면 에이전트가 잘 것이라고 생각하는 분들이 많다. 하지만 실제 운영 관점에서는 대개 반대다. 좋은 모델도 중요하지만 시스템 설계가 부실하면 에이전트는 효율적이지 못하다.
그 이유는 에이전트는 본질적으로 불확실성을 지니고 있기 때문이다. 모델이 잘못 이해할 수 있고, 같은 요청에도 판단이 달라질 수 있고, 도구 호출 순서가 비효율적일 수 있고, 중간 결과를 잘못 해석할 수 있다.
그래서 에이전트가 현장에서 쓰이려면, 밖에서 이를 잡아주는 구조가 필요하다. 대략 이런 것들이 필요하다.
- 상태를 어디에 저장할지
- 어떤 도구를 허용할지
- 실패 시 어디까지 되돌릴지
- 사람 승인 단계를 어디에 둘지
- 로그와 추적을 어떻게 남길지
즉, 에이전트는 신비한 존재가 아니라 신뢰성 있는 소프트웨어 시스템으로 다뤄야 한다는 문제인식을 가져야 한다. 에이전트를 잘 만든다는 것은 프롬프트 몇 줄을 잘 쓰는 일이 아니라, 모델이 들어간 소프트웨어를 어떻게 운영 가능한 구조로 만들 것인가의 문제이기 때문이다.
재미있는건 이 변화가 특정 분야에만 머무르지 않는다는 점이다. 데이터쪽에서는 Airflow나 Prefect같은 워크플로우 도구가 여전히 중요하다. 정해진 파이프라인을 안정적으로 돌리는 일은 앞으로도 사라지지 않는다.
반면, LLM이 들어오는 영역에서는 에이전트 오케스트레이션을 전면에 내세운다. 이는 에이전트도 결국 흐름의 문제이고, 따라서 그래프로 모델링 하는것이 유효하다는 의미다.
즉, 세상은 기존 워크플로우를 버리고 에이전트로 완전히 갈아타는 방향으로 움직이기보다는, 정해진 흐름은 계속 워크플로우에 두고, 불확실한 구간만 에이전트로 다루는 혼합형 구조로 가고 있다고 생각하는 것이 현실적이다.
에이전트를 이해하는 가장 좋은 방법은 개발 혁명보다 설계 방식의 진화로 보는 것이다.
에이전트를 둘러싼 담론은 종종 너무 크다. 개발자를 대체한다. 소프트웨어를 새로 쓴다. 사람 없이 돌아가는 회사를 만든다. 같은 이야기가 많다.
에이전트는 소프트웨어를 없애는 기술이 아니다. 소프트웨어 안에서 판단이 들어가는 부분을 다루는 새로운 방법이다.
예전에는 그런 판단을 사람이 미리 규칙으로 넣었다. 이제는 판단을 모델에게 맡길 수 있게 되었다. 그래서 우리는 더 많이 고민해야 한다.
- 어디까지 맡길 것인가?
- 어떤 도구를 줄 것인가?
- 어떤 상태를 기억시킬 것인가?
- 언제 사람을 개입시킬 것인가?
- 어떤 실패는 허용하고, 어떤 실패는 막을 것인가?
중요한 것은 AI가 뭘 할 수 있나보다 우리가 어떤 구조를 만들 것인가다.
에이전트는 갑자기 하늘에서 떨어진 개념이 아니다. 플로우에서 시작해, DAG로 정교해지고, 이제는 경로 선택을 모델에게 넘기는 방향으로 진화해온 소프트웨어 역사다.
그래서 생각도 진화해야 한다.
"어떤 모델이 제일 똑똑한가?" 보다,
"우리는 어떤 일을 결정론적으로 둘 것이고, 어떤 일을 동적으로 맡길 것인가?"가 더 중요하다.
"에이전트를 붙일까? 말까?"보다,
"이 시스템 안에서 판단이 필요한 지점은 어디인가?"가 더 중요하다.
이렇게 보면 에이전트는 덜 신비롭지만, 훨씬 실용적으로 보인다.
마무리
어쩌면 우리가 에이전트를 새롭다고 느끼는 이유는, 기술이 갑자기 낯선 방향으로 튄 것처럼 보여서가 아니다. 사실은 오래전부터 이어져 온 소프트웨어의 흐름이 드러났기 때문일지도 모른다.
지금 우리가 만들고 있는 작은 시스템 하나, 작은 판단 하나, 작은 흐름 하나를 설계하는 과정에서 변화는 시작될 것이다. 거대한 선언이나 유행이 아니라...
References:
