AI 에이전트 입문

먼저 뜻을 이해하기

처음에 알아두면 좋은 점은, 그저 답만 돌려주는 AI와의 차이입니다. 보통 대화형 AI는 질문을 받으면 글로 답하는 것이 중심입니다. 반면 이번에 다루는 주인공은, 필요하면 바깥 도구도 쓰면서 일을 앞으로 진행하는 방식입니다.

예를 들어, 사내 안내문을 찾아 답하기, 부족한 자료가 있으면 다시 찾기, 답하기 전에 내용이 맞는지 다시 확인하기 같은 일입니다. 이렇게 한 걸음 더 나아간 움직임이 들어가면, 단순히 답만 하는 역할이 아니게 됩니다. 우선은 이 차이만 이해해도 충분합니다.

출발점

AIエージェント라는 말은, 답만 하는 것이 아니라 필요한 작업을 골라 진행하는 구조라는 뜻으로 쓰입니다.

도구를 나누어 써 가며 진행하는 AI

• 질문에 답하는 것에 그치지 않고, 필요한 작업을 스스로 고른다
• 상황이 바뀌어도, 다음 행동을 조정하기 쉽다

가까운 비유로는, 새로 들어온 사람에게 일을 맡기는 장면과 비슷합니다. “이 문의에 답해 줘”로 끝나는 사람도 있고, “먼저 지난번 사례를 찾고, 부족하면 담당표를 보고, 필요하면 확인한 뒤 답한다”는 사람도 있습니다. 뒤의 방식이 이 구조와 가깝습니다.

무엇이 다를까?

기존 자동화와 비교해 보면, 가장 큰 차이는 처음부터 모든 절차를 다 정해 놓지 않아도 된다는 점입니다. 지금까지의 자동화는 인수인계 문서대로 진행하는 데는 강했습니다. 하지만 중간에 예상 밖의 일이 생기면 멈추기 쉬운 약점도 있었습니다.

앞으로의 방식은 목적을 보고 방법을 바꿉니다. 자료를 찾지 못하면 다른 찾는 방법으로 바꾸고, 질문이 모호하면 표현을 바꾸는 식의 움직임이 가능합니다. 사람이 매번 세세하게 지정하지 않아도 진행되기 쉬운 것이 특징입니다.

‘에이전트적’이라는 말의 뜻

사람 손을 어디까지 줄일 수 있는지를 보는 말입니다. 대단한 이름처럼 들리지만, 핵심은 “다음에 무엇을 할지 매번 사람이 정하지 않아도 되는가”입니다.

스스로 진행한다

상황을 보고, 다음 작업을 고르기 쉬운 형태입니다. 자료를 찾을지, 바로 답할지를 매번 사람이 지시하지 않아도 정하기 쉬워집니다.

중간에 고칠 수 있다

잘되지 않을 때 다른 절차로 바꾸기 쉬운 것도 중요합니다. 한 번 실패로 끝나지 않고, 다시 찾거나 다시 물을 수 있습니다.

맡길 수 있는 범위가 넓다

사람이 매번 자세히 지시하지 않아도 진행되기 쉬우므로, 맡길 수 있는 범위가 넓어집니다. 다만 무엇이든 전부 맡겨도 된다는 뜻은 아닙니다. 뒤에서 나오는 경계 기준이 중요합니다.

최소한의 3가지 역할

구조는 이 세 가지로 보면 정리하기 쉽습니다. 어렵게 생각하지 말고, 회사 안의 역할 나누기라고 생각하면 됩니다.

생각하는 역할

질문을 읽고, 무엇을 할지 정합니다. 먼저 검색이 필요한지, 바로 답할 수 있는지를 봅니다.

도구를 쓰는 역할

검색이나 계산처럼 바깥 작업을 불러옵니다. 사람으로 치면, 필요한 장부나 안내문을 가지러 가는 역할입니다.

기억하는 역할

방금 전 이야기나 지난 대화를 유지합니다. 이것이 약하면, 조금 전에 정한 일을 잊은 것 같은 부자연스러운 움직임이 됩니다.

설계는 어떻게 고를까

이제부터는 어떻게 짤지에 대한 이야기입니다. 혼자서 돌릴지, 역할을 나눌지. 우선은 이 관점만 알아도 충분합니다.

처음부터 크게 만들면, 왜 그렇게 움직였는지 따라가기 어려워집니다. 아직 익숙하지 않을 때는, 작게 시작해서 어디서 헷갈리는지 보면서 넓혀 가는 것이 안전합니다.

먼저 두 가지 선택

단독형과 분담형이 있습니다. 단독형은 하나의 흐름으로 끝까지 진행하는 형태입니다. 작은 일에 잘 맞고, 만들기 쉽고, 움직임도 따라가기 쉽습니다.

분담형은 조사하는 역할, 정리하는 역할, 검토하는 역할처럼 나누는 형태입니다. 복잡한 일에 잘 맞지만, 설계가 무거워지고, 주고받는 일이 많아지는 만큼 느려지기 쉽습니다. 처음 배울 때는 단독형부터 시작하는 편이 덜 막힙니다.

분담형의 기본 3가지 패턴

처음에는 이 세 가지면 충분하다고 생각하면 정리하기 쉽습니다.

동시에 진행하기

서로 다른 작업을 나란히 진행하고, 나중에 모읍니다. 예를 들어 여러 자료를 동시에 확인하는 형태입니다. 빨라 보이지만, 같은 일을 겹쳐 할 가능성도 큽니다.

순서대로 넘기기

앞사람의 결과를 다음 사람에게 넘겨 마무리합니다. 초안을 만드는 사람, 고치는 사람, 최종 확인하는 사람이라는 흐름과 비슷합니다.

입구에서 나누기

질문의 종류에 따라 담당을 나누어 쓸데없는 일을 줄입니다. 요금 질문은 이 흐름, 절차 질문은 다른 흐름으로 나누는 생각입니다.

조직의 형태에 따라서도 달라진다

나란히 가는 방식인가, 리더형인가에 따라서도 설계는 달라집니다. 이것은 실제로 돌렸을 때 얼마나 이해하기 쉬운지와 바로 연결됩니다.

나란히 가는 형식

여럿이 함께 의견을 내는 일에 잘 맞습니다. 다만, 같은 것을 여러 번 찾거나 비슷한 작업이 겹치기 쉽습니다.

리더형

흐름이 분명하고, 단계별 작업에 잘 맞습니다. 누가 다음을 정하는지가 분명하므로, 처음 배울 때 다루기 쉽습니다. 다만 한곳에 판단 부담이 몰리기 쉬워집니다.

현실적인 고르는 방법

처음에는 리더형으로 작게 만들고, 필요하면 넓혀 가는 것을 권합니다. 처음부터 옆으로 넓게 펼치면, 어디서 실패했는지 보기가 어려워집니다.

자동화를 너무 많이 하지 않는 기준

중요한 장면에는 사람을 남겨 둔다. 이 부분은 매우 중요합니다. 편리하다고 해서 모든 것을 자동으로 처리하면 위험한 경우가 있습니다.

사람의 확인을 넣기

개인정보나 중요한 판단 앞에서는 멈추게 해야 합니다. 예를 들어, 보내기 전 확인이나 조건 변경의 최종 판단은 사람이 봐야 합니다.

도구를 함께 쓰는 일에 주의하기

같은 도구를 동시에 쓰면, 충돌이 나서 흐트러지기 쉽습니다. 사람도 하나뿐인 장부를 여러 명이 동시에 고치면 혼란이 생깁니다. 그것과 같습니다.

답의 어긋남에 주의하기

같은 원본 정보라도 보는 방식이 다르면 결론이 갈릴 수 있습니다. 그래서 마지막에 정리하는 역할이나 사람의 확인이 효과를 냅니다. 하면 안 되는 일은, 그럴듯한 글만 보고 그대로 통과시키는 것입니다.

검색 기능이 있는 AI

이제부터는 RAG라고도 불리는, 문서를 찾은 뒤 답하는 방식에 대한 이야기입니다. 사내 안내문, 자주 묻는 질문, 설명문 등을 찾아 그것을 바탕으로 답하기 때문에, 즉흥적인 답이 되기 어렵다는 장점이 있습니다.

업무에 쓴다면, 이 형태가 시작점이 되기 쉽습니다. 이유는 단순합니다. 답의 근거를 손에 있는 문서에 맞추기 쉽기 때문입니다. 특히 표현이 중요한 안내문이나, 정해진 절차를 설명하는 일에 잘 맞습니다.

여기서 실용성이 갈린다

검색 기능이 있는 AI의 핵심은, 한 번 찾고 끝내지 않는 것입니다.

찾기 → 확인하기 → 고쳐서 다시 검색하기

찾은 문서가 약하면, 질문 표현을 바꾸어 다시 찾습니다. 이런 한 번의 왕복이 있으면, 답의 질이 좋아지기 쉽습니다. 사람도 처음 검색에서 원하는 자료가 나오지 않으면, 말을 바꾸어 다시 찾습니다. 그것과 같습니다.

자주 막히는 장면은 “검색했는데도 답이 어긋난다”는 경우입니다. 원인은 찾은 문서가 질문에 맞지 않거나, 너무 넓은 내용인 경우가 많습니다. 이 부분을 다시 보게 하는 구조가 있으면, 실제 사용에서 차이가 납니다.

움직임은 4단계

검색 기능이 있는 AI의 흐름은 네 단계로 생각하면 이해하기 쉽습니다.

검색이 필요한지 정하기

바로 답할지, 자료를 찾을지를 먼저 나눕니다. 매번 검색하면 느려지고, 반대로 매번 바로 답하면 근거가 약해집니다.

문서를 찾아 모으기

필요한 페이지나 자료만 가져옵니다. 전부 읽는 것이 아니라, 관련이 있어 보이는 부분을 좁히는 것이 목적입니다.

쓸 수 있는 문서인지 확인하기

질문에 맞는지 다시 봅니다. 말이 조금 비슷할 뿐, 사실은 다른 이야기일 수도 있습니다.

약하면 질문 방식을 고치기

질문을 바꾸어 말하고, 한 번 더 찾습니다. 이 부분을 빼면 “찾았지만 못 찾았다”는 식으로 끝나기 쉽습니다.

LangGraph로 만드는 이유

LangGraph는 절차를 선으로 이어 주는 도구입니다. 어려워 보이지만, 생각 자체는 단순합니다. 일의 흐름을 작은 작업으로 나누고, 조건에 따라 다음 갈 곳을 바꿀 수 있게 합니다.

작업 상자

하나하나의 처리를 작은 상자로 나눌 수 있습니다. 예를 들어, 입구에서 판단하는 상자, 검색하는 상자, 답을 정리하는 상자라는 식으로 볼 수 있습니다.

연결선

조건에 따라 다음 상자를 바꿀 수 있습니다. 자료가 약하면 다시 찾기로, 충분하면 답변으로 가는 갈림길을 만들 수 있습니다.

공통 메모

중간 정보를 가지고 다음으로 넘길 수 있습니다. 질문 문장, 찾은 자료, 중간 판단을 이어받을 수 있으므로, 흐름이 끊기기 어려워집니다.

재료를 모으기

앞부분의 절차에서는 먼저 답의 바탕이 되는 글을 모읍니다. 이 부분이 비어 있으면, 검색 기능이 있는 형태로 만들어도 찾을 대상이 없습니다.

OpenAI 사용 준비

OpenAI는 글을 읽거나 정리하기 위한 도구입니다. 이용 키를 불러오고 실행할 수 있는 상태로 만드는 것은, 이 도구를 쓸 수 있게 하기 위한 일입니다. 직접 설정하지 않는 사람이라도 “사용 허가가 제대로 되어 있는지”는 확인할 필요가 있습니다.

WebBaseLoader로 불러오기

WebBaseLoader는 웹페이지 본문을 가져오기 위한 도구입니다. 네 개의 웹페이지를 문서로 가져오는 이유는, 나중에 찾을 재료를 모으기 위해서입니다.

먼저 재료를 갖추기

여기서 중요한 점은, 처음부터 완벽한 양을 모으려 하지 않는 것입니다. 너무 적으면 답할 수 없고, 너무 많아도 찾기 어려워집니다. 우선은 답에 쓰고 싶은 문서만 갖추는 것이 요령입니다.

문서를 찾기 쉬운 형태로 만들기

중간 절차에서는 모은 글을 그대로 두지 않고, 찾기 쉬운 형태로 정리합니다. 긴 문서를 통째로 들고 있기만 하면, 필요한 부분을 찾기 어렵기 때문입니다.

RecursiveCharacterTextSplitter

RecursiveCharacterTextSplitter는 긴 글을 잘게 나누어 다루기 쉽게 하는 도구입니다. 하나의 큰 자료를 필요한 문단 단위로 나누는 느낌입니다.

InMemoryVectorStore에 저장

InMemoryVectorStore는 잘게 나눈 문장을 잠시 저장하고, 비슷한 내용을 찾을 수 있게 하는 보관함입니다. 이름은 어려워 보이지만, 쉽게 말하면 “관련 있어 보이는 문장을 찾기 쉽게 해 주는 저장 장소”입니다.

검색의 바탕 만들기

여기서의 목적은 필요한 조각만 꺼낼 수 있는 상태를 만드는 것입니다. 자주 막히는 부분은, 나누는 단위가 너무 커서 관계없는 문장까지 섞이는 경우와, 반대로 너무 잘게 나누어 뜻이 끊기는 경우입니다. 처음에는 너무 짧지도 너무 길지도 않게 하는 것을 의식하면 됩니다.

검색 담당을 준비하기

뒷부분의 절차에서는 찾을 수 있는 상태가 된 문서를 실제로 불러 쓸 수 있는 형태로 만듭니다.

retriever tool 만들기

retriever tool은 찾은 문장을 돌려주는 검색 담당입니다. 도구로 불러 쓸 수 있는 형태로 만들어 두면, “필요하면 찾는다”는 흐름 안에 넣을 수 있습니다.

입구의 판단 상자 만들기

그대로 답할지, 검색할지를 정하는 상자를 만듭니다. 이것이 없으면 간단한 질문에도 매번 검색하게 되어 움직임이 무거워집니다.

질문만으로 충분하면 바로 답하기

찾을 필요가 없는 내용은 그 자리에서 답합니다. 예를 들어, 인사말이나 지금 있는 대화만으로 알 수 있는 확인입니다. 무엇이든 검색으로 돌리는 것은 하지 말아야 할 설계 중 하나입니다.

마무리의 3개 상자

답의 품질을 높이는 부분입니다. 검색 기능이 있는 형태가 실제로 쓸 만한지가 여기서 갈리기 쉽습니다.

문서가 맞는지 확인하기

질문에 맞는 문장인지 보고, 쓸지 되돌릴지 정합니다. 찾았다는 사실만으로는 부족합니다. 답하려는 내용에 정말 맞는지가 중요합니다.

약하면 질문을 다시 써 보기

묻는 표현을 바꾸어 다시 찾습니다. 사람도 “신청 조건”으로 찾지 못하면 “이용 조건”이나 “대상자”로 찾는 경우가 있습니다. 그런 같은 요령을 넣는 것입니다.

마지막에 답을 정리하기

쓸 수 있는 문서를 바탕으로 답변을 만듭니다. 이때 문서에 없는 내용을 너무 많이 덧붙이지 않는 것이 요령입니다. 정리하는 역할은, 글을 멋지게 쓰는 것보다 원래 문서에서 벗어나지 않는 것을 더 우선합니다.

완성된 흐름

LangGraph의 구성으로 보면, 흐름은 단순합니다. 시작한 뒤 먼저 입구에서 판단합니다. 바로 답해도 되면 그대로 돌려주고, 필요하면 검색으로 넘어갑니다.

검색 뒤에는 문서 확인을 하고, 맞으면 답변으로 갑니다. 약한 문서라면 질문을 다시 써서 다시 검색으로 돌아갑니다. 이렇게 돌아가는 길이 있다는 점이, 단순 검색과 다른 부분입니다.

업무로 생각해 보면, “접수처에서 나누기”, “자료를 가져오기”, “내용이 맞는지 확인하기”, “부족하면 다시 찾기”, “마지막에 답변 만들기”라는 흐름입니다. 그림이 없어도, 이 순서로 떠올릴 수 있으면 충분합니다.

오늘의 결론

만들기 전에 정해야 할 것은 많지 않습니다. 오히려 처음에는 너무 많이 정하지 않는 편이 더 잘됩니다.

중요한 것은, 도구 선택까지 맡기는 형태인지, 단독형인지 분담형인지, 중요한 판단에 사람을 남길지, 검색 재시도를 넣을지, 그리고 LangGraph로 상자와 선과 공통 메모의 형태로 짤지입니다. 이 뼈대만 정해지면, 세부 설정은 나중에 다듬을 수 있습니다.

마지막으로

AI 도서관

팔로우와 좋아요 부탁드립니다

AI를 일에 활용하는 이야기를, 쉽게 하나씩 소개하고 있습니다. 어려운 말보다, 내일 바로 시험해 볼 수 있는 생각을 더 중요하게 보고 있습니다.

다음 글에서도 여기서 만나요. 우선은 “그냥 답하기”에서 “필요하면 찾고 확인하기”로, 이 한 걸음을 가져가시면 됩니다.

정리

• 우선은, 그냥 답하는 형태와 도구를 써서 진행하는 형태의 차이를 말로 설명할 수 있게 한다
• 자신의 일에서, 검색 기능이 있는 형태에 잘 맞는 문서를 하나 정한다. 안내서, 안내문, 자주 묻는 질문부터 시작해도 된다
• 모든 것을 자동으로 하지 말고, 사람이 확인할 장면을 먼저 정한다. 개인정보와 중요한 판단은 남겨 둔다
• 흐름은 작게 만든다. 입구 판단, 검색, 문서 확인, 답 정리, 이 순서만 먼저 생각한다
• 잘 찾지 못할 때는, 문서가 아니라 묻는 방식을 고쳐 다시 검색한다는 생각을 가진다