비하인드

AI 에이전트를 기초부터 만들어가며 이해해보기

이전글 AI 에이전트에서의 토큰 절약 팁에서 당장 토큰을 절약할 수 있는 몇 가지 사례들을 알아보았다면, 이번에는 어째서 그런가에 관한 원리 이해의 포스팅입니다.

이 포스팅에서는 하나의 자동화된 AI 에이전트를 단계별로 만들어 본다고 상상하면서 구조를 이해해 보겠습니다. 자동차의 구동 구조를 알면 더 효율적으로 관리할 수 있듯, 단순히 사용하는 것을 넘어 원리를 이해하면 토큰과 비용을 더 효율적으로 관리하는 데 도움이 됩니다.

아래의 예시는 거래처 미팅을 준비해 주는 업무 비서 에이전트입니다. 비개발자를 위한 생략이 많으므로 전문적인 영역에서 거슬림이 있더라도 너그러이 양해 바랍니다.

요청과 응답

가장 단순한 1차원적인 형태입니다. 질문을 보내고 답변을 받는 구조입니다. 가장 기초적이지만 가장 빈번하게 반복되는 패턴입니다.

나 : 다음 주 A사와의 미팅 준비 좀 해 줘.
답 : 무슨 미팅을 말하는 건지?

AI 모델은 문장을 연산할 수 있는 작은 단위인 토큰들의 순서로 바꿉니다. 지금까지의 입력과 이미 생성한 토큰을 바탕으로 다음에 올 가능성이 높은 토큰을 고르고, 이를 반복해 텍스트를 만듭니다.

이 한 문장만으로는 A사가 어느 회사인지, 어떤 미팅인지 알 수 없습니다. 현재 날짜를 함께 알려주지 않았다면 ‘다음 주’의 정확한 날짜도 계산할 수 없습니다.

역할과 기본 규칙

이제 여기서 한 단계 더 유의미하게 발전시킬 수 있습니다. 우리는 AI에게 이 서비스에서 맡길 역할과 지켜야 할 기준을 미리 알려 줍니다. 보통 시스템 프롬프트라고 부르는 부분입니다.

시스템 : 비서 역할, 정중한 답변, 업무에 필요한 정보 사전 파악
나 : 다음 주 A사와의 미팅 준비 좀 해 줘.
답 : 알겠습니다, 업무를 도와드리겠습니다. 보다 구체적인 정보를 제가 어떻게 확인할까요?

아직 유의미한 업무는 하지 못하지만, 역할과 기타 원하는 사안들을 시스템 프롬프트에 넣었습니다. 시스템 프롬프트는 보통 서비스가 매 요청에 함께 보내는 상위 수준의 지시문입니다. 서비스는 이를 통해 역할, 응답 형식, 기본 규칙을 일관되게 적용할 수 있습니다.

대화가 길어질수록 중심을 잡아 주는 시스템 프롬프트는 다른, 더 중요한 의미를 가집니다. 사용자의 말이나 이전 대화에는 틀린 정보가 섞일 수 있어도, 서비스는 시스템 프롬프트를 통해 지켜야 할 역할과 규칙을 계속 적용할 수 있기 때문입니다.

이 예제에서는 업무 에이전트를 만드느라 이 정도 수준에서 할 수 있는 게 별로 없지만, 만약 단순한 서비스를 만든다면 이 구조만으로도 독립된 앱을 만들 수 있습니다. 예를 들어 "맞춤법 검사기", "번역기" 같은 류를 만들 수 있습니다. 시스템 프롬프트에서 "너는 전문 번역가로 사용자가 입력한 텍스트를 개발 전문용어를 쓰는 영어로 응답해. 산문체로 하고 독자는 1년차 주니어라고 가정해."를 설정하고, 사용자에게 전달받은 메시지를 넣어 AI를 호출하면 번역기처럼 보이게 할 수도 있습니다.

맥락 유지

단순한 앱이라면 시스템 프롬프트만 잘 만져서 한 번 요청하고 한 번 응답받으면 끝날 수도 있습니다. 하지만 에이전트는 업무의 목적이 달성될 때까지 여러 제반 정보를 끌어모으고 계속 판단하고 계속 수정하게 됩니다. 즉, 초기부터 지금까지 어떤 대화를 했느냐가 다음 대화의 기반이 되는 셈입니다.

나 : 다음 주 A사와의 미팅 준비 좀 해 줘.
답 : 알겠습니다, 업무를 도와드리겠습니다. 미팅 날짜를 제가 어떻게 확인할까요?
나 : 모월 모일에 할 거야.
답 : 이해했습니다. 회의는 무슨 안건일까요?
나 : 지난번에 마무리가 안 된 연간 계획 논의할 거야.
답 : 알겠습니다. 혹시 회의 자료를 제가 볼 수 있을까요?
나 : 하.....

우리가 흔하게 챗봇에서 볼 수 있는 대화의 예시입니다. 에이전트로서 뭔가 시원하게 일을 해결하진 못했지만, 적어도 대화를 하면서 내용은 점점 구체화되고 있습니다.

여기서 비개발자분들은 모르실 수 있는 숨겨진 비밀이 하나 있습니다. 기본적인 무상태 API에서는 새 요청마다 시스템 프롬프트와 지금까지 필요한 대화·도구 결과를 다시 모델에 포함해야 합니다. 얼핏 생각하기에 대화한 내용이 다 있으니까 내가 새로 넣은 채팅만 추가로 들어갈 것 같지만 그렇지 않습니다.

다만 모든 기록을 원문 그대로 항상 보내는 것은 아닙니다. 대화가 길어지면 오래된 내용을 요약하거나, 필요한 기록만 꺼내거나, 서비스가 이전 응답을 참조하도록 만들 수도 있습니다. 모델은 매 호출에서 전달받은 맥락을 바탕으로 새 응답을 만듭니다. 따라서 맥락이 길수록 비용과 응답 시간이 늘어날 수 있지만, 중요한 것은 기록을 무조건 모두 넣는 것이 아니라 현재 판단에 필요한 맥락을 고르는 일입니다.

컴퓨터와 AI의 소통

여기서 잠깐! 지금까지 모델은 사람에게 읽히는 문장으로만 답했습니다. 하지만 에이전트가 일정 조회나 파일 열기처럼 실제 행동을 하게끔 명령을 하려면, 에이전트가 이해할 수 있는 언어로 답해야합니다. 아래와 같은 형식으로요..

에 : 내가 뭘 해야해? 명령어랑 옵션을 말해줘. 나는 aa와 bb와 cc를 실행할 수 있어.
답 : {"tools": ["aa"], "params":{...}}
에 : (실행하고 나서) 결과가 이렇게 나왔어. 그 다음 뭘 해야해? 
답 : {"tools": ["bb"], "params":{...}}

에이전트는 이런식으로 AI 모델에게 할 수 있는 제반 설명을 주고, AI 모델은 그 중에서 어떤 것을 해야하는지 정해진 수단 내에서 정해진 방법으로 호출 명령을 전해줍니다. 물론 AI 모델은 자연어로 사용자에게 전달해야하는 말인지, 에이전트 (니가) 스스로 먼저 실행해야하는지도 결정을 해줍니다.

이는 엄청난 포인트입니다. 우리가 AI 에이전트를 만들거나 혹은 그 수준까지 도달하지 못해도 수많은 작은 문제들을 해결할 수 있는 가능성이 바로 여기에서부터 열리기 때문입니다. 만일 자연어로만 말할 수 있고 자연어로만 답할 수 있다면, 챗봇을 넘어설 수 없었을 겁니다. 하지만 규격화된 답변을 통해서 이제는 컴퓨터와 AI가 대화를 할 수 있게 되었습니다.

※ 저도 개인적으로 쓰는 수많은 내부 도구들이 있는데요. 이전에는 순수 스크립트 언어로써 만들었지만, 이제는 그것조차 귀찮아서 스킬처럼 AI 모델이 명령을 뽑아내고 실행하도록만 만들어둡니다. 호출시마다 비용이 들지만 이 비용이 거의 0에 수렴해가고 있고 이렇게하면 유연하게 상황에 맞게 대응도 되기 때문입니다.

에이전트의 탄생

이제 다시 에이전트 얘기로 돌아가서 완성을 할 타이밍입니다. 에이전트가 모델과 소통하는 방법도 알았으니, 이제 최종의 단계만이 남았습니다. 다시 사용자의 입장으로 돌아가면, 계속 AI 모델과 사용자 간의 직접적인 대화만 있었고 자동화된 느낌은 하나도 없었습니다. 그것은 실제로 대화가 아래와 같이 진행되었기 때문입니다. 에이전트는 전달 외에는 아무 일도 하지 않았습니다.

나 : 다음 주 A사와의 미팅 준비 좀 해 줘.
에 : (AI한테 전달)
답 : 알겠습니다, 업무를 도와드리겠습니다. 미팅 날짜를 제가 어떻게 확인할까요?
에 : (사용자에게 전달)
나 : 모월 모일에 할 거야.
에 : (AI한테 전달)
답 : 이해했습니다. 회의는 무슨 안건일까요?
에 : (사용자에게 전달)
나 : 지난번에 마무리가 안 된 연간 계획 논의할 거야.
에 : (AI한테 전달)
답 : 알겠습니다. 혹시 회의 자료를 제가 볼 수 있을까요?
에 : (사용자에게 전달)
나 : 하.....

이 과정을 조금 더 개선해서 에이전트가 AI 모델과 소통하는 단계까지 넘어봅니다. 에이전트는 모델에게 사용할 수 있는 도구와 각 도구의 입력 형식을 함께 알려 주고, 모델은 필요할 때 자연어 답변 대신 정해진 형식의 도구 호출을 반환합니다.

이런 요청을 받으면 모델은 어떤 정보가 더 필요한지, 이 에이전트가 무엇을 더 실행할 수 있는지 판단해서 다음 행동 지침을 내려줄 수 있습니다.

나 : 다음 주 A사와의 미팅 준비 좀 해 줘.
에 : (AI에게 가용한 도구 목록과 호출 방법도 같이 전달)
답 : {
  "tool": "google_calendar",
  "params": {
    "start_date": "2026-01-05",
    "end_date": "2026-01-11",
    "query": "A사"
  }
}
에 : (google_calendar의 조회 조건을 받아 일정을 확인하고, 자세한 정보를 AI에게 전달)
답 : {
  "tool": "powerpoint",
  "params": {
    "file": "A사 연간 계획 논의.pptx"
  }
}
에 : ("A사 연간 계획 논의.pptx" 파일을 읽고 내용을 AI에게 다시 전달)
답 : 기존 안건을 검토했습니다. 미결 사항과 완료 사항은 아래와 같습니다..
에 : (일반 자연어 답변이므로 바로 사용자에게 전달)
나 : 흠.. 미결은 어쩌고저쩌고..

이제야 좀 업무가 진행됩니다. 저기에서 에이전트와 AI 모델이 대화한 것을 에이전트마다 보여 주는 곳도 있고 숨겨 주는 곳도 있지만, 사용자는 어쨌든 파악한 이후의 답변을 보게 됩니다. AI 모델 자체가 손발을 얻는 것이 아니라, 모델의 판단과 에이전트의 실행기가 결합되어 바깥 정보에 접근하고 정해진 행동을 수행하는 시스템이 되는 셈입니다.

위 예시는 단순한 일정 조회와 업무 파악이지만, 에이전트에 연결하고 권한을 준 도구의 범위 안에서는 컴퓨터로 자동화할 수 있는 여러 일을 수행할 수 있습니다. 파일을 탐색하거나, 결과로 무엇이 있는지 확인하거나, 어디에 접속해 정보를 가져오는 일 등을 에이전트와 정보를 주고받으며 실행할 수 있게 됩니다. 아무리 복잡한 에이전트도 결국은 이런 단순한 구조에서 시작합니다.

마무리

처음에는 AI 모델에 문장 하나를 보내고 문장 하나를 받았습니다. 여기에 역할과 기본 규칙, 지금 필요한 작업 맥락을 더했습니다. 모델이 정해진 형식으로 도구 호출을 요청하면 에이전트가 이를 실행하고, 그 결과를 다시 모델에 전달해 다음 행동을 고릅니다. 이 과정을 목표가 끝날 때까지 반복하면서 바깥 정보와 연결합니다.

그래서 AI 에이전트를 볼 때 "엄청난 지능이 알아서 일을 한다"고 생각할 필요는 없습니다. 매 단계는 생각보다 단순한 장치이고, 그것을 어떤 순서로 연결하는지가 서비스의 품질을 만듭니다.

토큰을 절약하고 싶다면 매번 넣는 쓸모없는 맥락부터 줄여 보면 됩니다. 답이 엉뚱하다면 프롬프트를 길게 쓰기보다 지금 판단에 필요한 정보가 빠지지 않았는지 살펴보면 됩니다. 혹은 반대로 쓸데없는 맥락이 방해하고 있지는 않은지도 확인해 보면 좋습니다.

지금까지 토큰 절약을 위해 AI 에이전트의 구조를 이해해 보았습니다. 토큰을 아끼는 것을 넘어서 이 구조를 잘 활용하면 남들보다 더 정확한 답변을 받는 것도 가능할 수 있습니다. 어떤 주제를 현재 대화에서 계속 다룰지, 언제 새 대화로 분리할지도 판단하기 수월해집니다.