프롤로그. 왜 지금 다시 에이전트인가

우리는 이미 충분히 놀랐다

처음 대화형 AI를 만났을 때 많은 사람은 비슷한 감정을 느꼈다. 질문을 하면 제법 그럴듯한 답을 하고, 요약을 부탁하면 순식간에 문서를 정리하며, 초안을 써 달라고 하면 사람 손이 덜 가는 수준의 문장을 내놓는다. 한동안 이것만으로도 충분히 혁명처럼 보였다. 컴퓨터가 드디어 말을 알아듣고, 말로 일을 시킬 수 있게 된 듯했기 때문이다.

하지만 신기함은 오래가지 않는다. 어느 순간부터 질문이 바뀌기 시작한다. "답을 잘하는 건 알겠는데, 그래서 이걸 실제 일에 어떻게 연결하지?" "설명은 잘하는데, 왜 끝까지 처리하지는 못하지?" "문서를 읽고 요약하는 건 되는데, 왜 필요한 데이터를 찾아서 정리하고 보고하고 다음 단계까지 넘기지는 못하지?"

바로 그 지점에서 우리는 대화형 AI의 성격을 다시 보게 된다. 지금까지의 AI는 주로 응답하는 존재였다. 물으면 대답하고, 시키면 문장을 만든다. 그러나 실제 업무와 서비스는 대답만으로 끝나지 않는다. 정보를 찾고, 상태를 기억하고, 적절한 도구를 고르고, 여러 단계를 거쳐 작업을 완료해야 한다. 즉, 현실의 일은 대부분 행동의 연쇄다.

이 책이 다루려는 것도 바로 그 전환이다. 똑똑하게 말하는 모델을 넘어, 실제로 일을 진행하는 시스템으로 어떻게 넘어갈 것인가. 왜 지금 다시 에이전트라는 말이 중요해졌는가. 그 질문에서 이 책은 시작한다.

LLM은 강력하지만, 혼자서는 완전하지 않다

대규모 언어 모델, 즉 LLM은 분명 강력하다. 긴 문서를 요약하고, 코드 초안을 만들고, 여러 관점에서 아이디어를 제시하며, 사람의 의도를 꽤 유연하게 해석한다. 과거의 소프트웨어가 정해진 규칙 안에서만 움직였다면, LLM은 애매한 요청도 어느 정도 이해하면서 폭넓게 대응한다. 그래서 많은 사람이 "이제 소프트웨어가 훨씬 더 유연해지겠다"라고 기대했다.

그 기대는 절반쯤 맞았다. 문제는 나머지 절반이다.

LLM은 보통 한 번의 입력을 받아 한 번의 출력을 만드는 데 탁월하다. 그러나 실제 작업은 그렇게 단순하지 않다. 사용자의 요청은 종종 불완전하고, 필요한 정보는 외부 시스템에 흩어져 있으며, 중간 결과를 저장해야 하고, 실패하면 다시 시도해야 하며, 어떤 단계에서는 사람의 승인이 필요하다. 한마디로 말해 현실의 작업은 한 번의 추론이 아니라 여러 번의 판단과 실행으로 이루어진다.

이 차이는 매우 중요하다. 모델이 아무리 똑똑해도 현재 상황을 계속 추적하지 못하면 실수를 반복한다. 외부 도구를 쓸 수 없으면 필요한 정보에 접근하지 못한다. 실행 결과를 확인하지 못하면 틀린 방향으로 계속 달린다. 실패를 복구할 구조가 없으면 데모에서는 멋져 보여도 운영 환경에서는 금세 무너진다.

그래서 오늘날 중요한 질문은 더 이상 "어떤 모델이 더 똑똑한가"에만 머물지 않는다. 오히려 "이 모델을 어떤 구조 속에 넣어야 실제로 안정적으로 일하게 만들 수 있는가"가 더 중요해졌다. 이 질문이 바로 에이전트 시스템 설계의 출발점이다.

워크플로 자동화는 생각보다 덜 똑똑했고, 더 딱딱했다

사실 'AI가 일을 대신한다'는 꿈 자체는 새로운 것이 아니다. 기업용 소프트웨어의 역사에는 늘 자동화가 있었다. 정해진 조건이 만족되면 메일을 보내고, 양식을 접수하면 다음 담당자에게 넘기고, 특정 값이 바뀌면 후속 작업을 실행하는 식이다. 이런 워크플로 자동화는 지금도 매우 유용하다.

하지만 현실의 업무를 조금만 들여다보면, 모든 일이 그렇게 반듯한 규칙으로 정리되지는 않는다. 고객 문의는 매번 표현이 다르고, 문서 형식은 제각각이며, 예외 상황은 생각보다 자주 발생한다. 사람이 중간에서 문맥을 읽고 판단해 주어야만 다음 단계로 넘어가는 일이 많다.

전통적인 자동화는 이런 지점에서 자주 멈춘다. 너무 많은 경우의 수를 미리 규칙으로 적어 두어야 하고, 예외 하나가 생기면 흐름 전체가 흔들린다. 반대로, LLM은 이런 애매함을 다루는 데 강하다. 사용자의 말을 이해하고, 비정형 데이터를 읽고, 그럴듯한 다음 행동을 제안할 수 있다.

그렇다고 LLM이 기존 워크플로를 완전히 대체하는 것은 아니다. 오히려 더 정확한 표현은 이렇다. LLM은 워크플로의 빈칸을 메우고, 워크플로는 LLM의 불안정함을 붙잡아 준다.

여기서 에이전트라는 개념이 다시 중요해진다. 에이전트는 단순히 말을 잘하는 모델이 아니다. 모델의 유연함과 소프트웨어의 구조를 결합해, 실제 작업을 끝까지 밀어붙이게 만드는 방식이다. 다시 말해, 에이전트는 '대화'와 '자동화' 사이의 다리다.

왜 하필 지금, 다시 에이전트인가

에이전트라는 말은 사실 오래된 단어다. 과거에도 여러 소프트웨어 시스템은 사용자 대신 행동하는 프로그램을 에이전트라고 불렀다. 하지만 한동안 이 개념은 다소 추상적이거나 과장된 약속처럼 들리기도 했다. 너무 많은 것을 할 수 있다고 말했지만, 실제로는 생각보다 똑똑하지 않았기 때문이다.

그런데 지금은 상황이 달라졌다. 이유는 단순하다. 이제는 자연어를 이해하고, 복잡한 요청을 중간 수준 이상으로 해석하며, 불완전한 정보를 가지고도 다음 행동 후보를 만들어 낼 수 있는 모델이 생겼다. 예전의 에이전트가 규칙 위에 세워진 자동기계였다면, 지금의 에이전트는 추론을 품은 소프트웨어에 가깝다.

이 변화는 아주 크다. 예전에는 사람이 모든 경로를 미리 설계해야 했다면, 이제는 시스템이 일부 경로를 현장에서 결정할 수 있다. 예전에는 입력 형식이 조금만 흔들려도 실패했다면, 이제는 사용자의 의도를 해석해 적당한 절차로 연결할 수 있다. 예전에는 자동화와 유연성 중 하나를 선택해야 했다면, 이제는 두 가지를 꽤 높은 수준에서 동시에 추구할 수 있다.

물론 여기서 오해하면 안 된다. 에이전트가 마법이라는 뜻은 아니다. 오히려 반대다. 에이전트가 주목받는 이유는 무엇이든 알아서 해내기 때문이 아니라, 적절한 경계와 설계가 있을 때 비로소 실용적이기 때문이다. 제대로 설계되지 않은 에이전트는 자율적인 조력자가 아니라, 비용만 많이 들고 실수도 많은 불안정한 자동화 장치가 된다.

그래서 "왜 지금 다시 에이전트인가"라는 질문에는 이런 답이 따라온다. 지금은 에이전트를 꿈꾸기 좋은 시대라서가 아니라, 에이전트를 제대로 설계해야만 하는 시대이기 때문이다.

응답하는 AI에서 행동하는 시스템으로

이 책 전체를 관통하는 핵심 문장은 하나다. 우리는 응답하는 AI를 만드는 데서 멈추지 않고, 행동하는 시스템을 설계해야 한다.

응답하는 AI는 입력에 반응한다. 질문을 받으면 답한다. 행동하는 시스템은 목표를 향해 움직인다. 필요한 정보를 모으고, 중간 상태를 기록하고, 적절한 도구를 선택하고, 결과를 검증하며, 실패하면 다른 경로를 찾는다. 둘의 차이는 단순한 성능 차이가 아니라 구조의 차이다.

예를 들어 사용자가 "이번 주 고객 불만 이슈를 정리해 보고서를 보내 줘"라고 말한다고 해 보자. 응답하는 AI는 아마 좋은 보고서 템플릿을 써 줄 것이다. 반면 행동하는 시스템은 먼저 어떤 데이터 소스가 있는지 확인하고, 최근 문의를 수집하고, 항목별로 분류하고, 중요한 사례를 요약하고, 필요한 경우 담당자에게 확인을 요청한 뒤, 최종 보고서를 생성해 실제 전송 단계까지 이어 갈 수 있다.

두 결과물은 겉으로 보기엔 비슷해 보여도 본질적으로 다르다. 하나는 "어떻게 할지 말해 주는 시스템"이고, 다른 하나는 "실제로 처리해 나가는 시스템"이다. 앞으로 소프트웨어가 바뀌는 지점은 바로 여기에 있다.

이때 중요한 것은 '행동'이 무조건 많아야 한다는 뜻이 아니라는 점이다. 좋은 에이전트는 무작정 돌아다니지 않는다. 필요할 때만 도구를 쓰고, 가능한 경우에는 단순한 경로를 택하며, 위험한 작업에서는 사람에게 물어본다. 행동하는 시스템은 바쁜 시스템이 아니라 목표와 제약을 이해한 시스템이다.

설계가 중요한 이유

에이전트에 대한 기대가 커질수록, 많은 팀이 같은 함정에 빠진다. 모델 하나를 붙이고 도구 몇 개를 연결한 뒤, "이제 알아서 하겠지"라고 기대하는 것이다. 하지만 현실은 그렇게 흘러가지 않는다.

에이전트가 실제로 일을 하려면 최소한 몇 가지가 필요하다. 지금 무엇을 하고 있는지 기억하는 상태가 있어야 하고, 무엇을 할 수 있는지 정의된 도구가 있어야 하며, 다음 행동을 고르는 실행 루프가 있어야 하고, 잘못되었을 때 멈추거나 복구하는 장치가 있어야 한다. 여기에 평가, 추적, 권한 관리, 비용 통제까지 붙기 시작하면 문제는 단순한 프롬프트 작성이 아니라 시스템 설계가 된다.

이 지점에서 이 책의 문제의식이 분명해진다. 이 책은 "에이전트가 멋지다"를 말하려는 책이 아니다. 오히려 "에이전트는 어디까지 유용하며, 어디서부터 위험해지고, 어떤 조건에서 제품이 되는가"를 묻는 책이다.

즉, 이 책은 가능성의 이야기를 하면서도 동시에 경계의 이야기를 한다. 언제 단일 에이전트로 충분한지, 언제 프롬프트 체이닝이 더 나은지, 언제 멀티에이전트가 필요한지, 언제는 오히려 과한지 같은 질문을 계속 던질 것이다. 좋은 설계는 복잡한 구조를 더하는 데서 나오지 않는다. 문제에 맞는 최소 구조를 고르는 데서 나온다.

이 책이 끝까지 붙드는 질문

앞으로의 장들에서는 모델, 상태, 도구, 실행 루프 같은 최소 구성 요소부터 시작해, 라우팅, 병렬 처리, 오케스트레이션, 평가와 최적화, 메모리, 오류 복구, 사람 승인, 관측 가능성, 보안과 권한 관리까지 차례로 다룰 것이다. 목차만 보면 주제가 넓어 보일 수 있다. 하지만 사실 이 모든 내용은 하나의 질문으로 묶인다.

"AI가 실제 세계에서 믿을 만하게 일하도록 만들려면 무엇이 필요한가?"

이 질문에 답하려면 기술 요소를 따로따로 보는 것으로는 부족하다. 모델은 똑똑한데 시스템이 허술하면 실패한다. 도구는 많은데 상태 관리가 없으면 길을 잃는다. 자동화는 화려한데 평가가 없으면 같은 실수를 반복한다. 보안이 약하면 잘하는 것보다 위험한 것이 더 커진다. 결국 중요한 것은 부품의 성능이 아니라 부품들이 어떤 질서로 엮여 있는가다.

그래서 이 프롤로그는 단지 서문이 아니다. 이후의 모든 장을 읽는 관점을 미리 맞추는 자리다. 앞으로 등장할 설계 패턴과 구현 방법, 운영 원칙은 모두 이 문제의식 위에 서 있다. 우리는 더 그럴듯한 답변을 만드는 법만 배우려는 것이 아니다. 실제 서비스와 업무 환경에서 작동하는 에이전트를 어떻게 만들어야 하는지를 배우려 한다.

다시, 질문으로 돌아가자

왜 지금 다시 에이전트인가.

그 이유는 사람들이 갑자기 새로운 유행어를 찾았기 때문이 아니다. LLM 덕분에 컴퓨터는 드디어 애매한 요청을 어느 정도 이해할 수 있게 되었지만, 그 자체만으로는 일이 끝나지 않는다는 사실이 분명해졌기 때문이다. 동시에 기존의 워크플로 자동화는 여전히 중요하지만, 너무 딱딱해서 현실의 복잡성을 감당하기 어렵다는 한계도 드러났다.

결국 우리는 둘 사이 어딘가가 아니라, 둘을 엮는 새로운 설계 감각을 필요로 하게 되었다. 그 감각의 이름이 지금은 에이전트 시스템 설계다.

이 책은 그 설계를 과장 없이, 그러나 실전적으로 다루려 한다. 어떤 순간에는 단순함이 최고의 해법이고, 어떤 순간에는 루프와 도구, 메모리와 평가가 꼭 필요하다. 어떤 문제는 에이전트가 풀어야 하고, 어떤 문제는 오히려 에이전트를 쓰지 않아야 더 낫다. 중요한 것은 유행을 따르는 것이 아니라, 문제에 맞는 구조를 고르는 눈을 갖는 것이다.

이제 다음 장부터 우리는 그 눈을 함께 만들어 갈 것이다. 챗봇처럼 보이지만 사실은 에이전트가 아닌 것들, 에이전트처럼 말하지만 실제로는 워크플로에 더 가까운 것들, 그리고 진짜로 행동하는 시스템이 되기 위해 필요한 최소 조건들을 하나씩 풀어 볼 차례다.

대화는 이미 시작되었다. 이제 필요한 것은, 그 대화를 일로 바꾸는 설계다.