AI Agent 만들기: 초보자를 위한 종류와 실무 구축 방법

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

처음 AI Agent를 만들려고 하면 대화창 하나에 API를 붙이는 일보다 훨씬 크게 느껴져요. 하지만 “오늘 배포 실패 건수만 읽어 와서 알려줘”처럼 답이 분명한 조회 업무 하나로 줄이면 시작점이 보입니다. 이 글에서는 AI Agent를 챗봇과 구분하고, 초보자가 어디까지 만들면 되는지 정리해 봅니다.

AI Agent는 챗봇과 무엇이 다를까요

일반 챗봇은 받은 질문을 바탕으로 문장을 만듭니다. 필요한 정보가 대화 안에 있거나, 미리 넣어 둔 문서에 있을 때 잘 맞아요.

AI Agent는 여기서 한 걸음 더 갑니다. 모델이 정해 둔 도구 중 무엇을 쓸지 고르고, 도구가 돌려준 실제 결과를 다시 읽은 뒤 답합니다. 예를 들어 “지난 24시간 장애 건수”를 묻는다면 에이전트는 get_incident_count 같은 읽기 전용 함수를 호출하고, 그 결과만으로 짧게 답하게 만들 수 있어요.

그래서 AI Agent를 만들 때는 모델만 고르면 끝나지 않습니다. 목표, 도구, 도구가 보는 데이터, 멈추는 조건을 같이 정해야 해요. OpenAI는 에이전트의 기본 요소를 모델·도구·지침으로 설명하고, Anthropic은 정해진 코드 경로를 따르는 워크플로와 모델이 도구 사용을 결정하는 에이전트를 구분합니다. 업무 순서가 고정돼 있다면 처음에는 워크플로가 더 편할 때도 많습니다. OpenAI의 실무 가이드와 Anthropic의 에이전트 설계 글을 함께 보면 이 차이가 더 또렷해져요.

AI Agent 종류는 업무 복잡도로 고르면 됩니다

분류 이름보다 “모델이 고를 수 있는 길이 몇 개인가”를 먼저 보면 쉬워요.

초보자라면 단일 작업형이나 읽기 전용 도구 하나를 가진 도구 호출형이 좋습니다. 지식 검색도 유용하지만, 문서가 오래됐을 때 틀린 답을 자신 있게 할 수 있어요. 여러 에이전트는 한 에이전트의 성공 기준과 로그를 먼저 잡은 다음에 늘려도 늦지 않습니다. AI Agent 유형을 정리한 글도 자율성과 업무 복잡도에 맞춰 범위를 고르라고 권합니다.

작은 AI Agent를 만드는 순서

처음 예시는 “서비스 이름을 받으면 최근 장애 건수만 조회해 알려준다”가 좋습니다. 배포를 실행하거나 티켓을 닫지는 않습니다. 틀려도 되돌리기 쉬운 읽기 작업이기 때문이에요.

1. 성공 조건을 한 문장으로 적어 둡니다

“서비스 이름이 없으면 되묻고, 있으면 모니터링 API의 최근 24시간 장애 건수를 반환한다. 숫자를 추측하지 않는다.” 정도면 충분합니다. 이 문장이 모델 지침, 테스트 질문, 실패 기록의 기준이 됩니다.

2. 도구를 작고 분명하게 만듭니다

도구 이름과 입력은 사람이 아니라 모델이 읽습니다. 비슷한 도구를 여러 개 두기보다 입력·출력·실패 상태를 명확하게 적어 주세요.

def get_incident_count(service: str) -> dict:
    """지정한 서비스의 최근 24시간 장애 건수만 읽어 반환한다.
    쓰기 작업, 설정 변경, 다른 기간 조회는 하지 않는다.
    """
    # monitoring_api에서 확인한 값을 반환하는 자리입니다.
    return {"service": service, "hours": 24, "count": 0}

이 함수는 구조 예시입니다. 실제 API 주소나 인증 방식은 사용하는 모니터링 서비스 문서를 따라 연결하면 됩니다. API 키는 코드나 프롬프트에 넣지 말고 실행 환경의 비밀 관리 기능에 보관해요.

3. 호출 결과를 다시 모델에 돌려줍니다

흐름은 생각보다 단순합니다. 사용자 질문을 모델에 보낸 뒤, 모델이 도구 호출을 요청하면 애플리케이션이 함수를 실행합니다. 그 결과를 다음 메시지로 넣고 모델에게 최종 답을 만들게 합니다. 모델이 도구를 부르지 않고 답했다면 그 답을 그대로 끝낼 수 있어요.

사용자 질문
  → 모델: 도구 호출이 필요한지 판단
  → 애플리케이션: 허용한 함수만 실행
  → 도구 결과: service, hours, count
  → 모델: 결과에 근거한 짧은 답변

도구 정의, 호출 요청, 결과를 다시 전달하는 최소 흐름은 간단한 AI Agent 만들어보기에서도 확인할 수 있어요. 다만 그 흐름을 그대로 넓히기보다, 먼저 도구 하나가 예상대로 호출되는지 로그로 확인해 보세요.

실무에 붙이기 전에는 권한과 기록부터 봐요

조회 도구가 잘 되자마자 메시지 발송, 결제, 배포 같은 도구를 붙이고 싶어집니다. 이때는 기능보다 권한이 먼저예요.

• 처음에는 읽기 전용 계정과 테스트 데이터만 씁니다.
• 도구마다 허용한 입력 범위를 검사합니다. service에 임의의 URL이나 긴 명령이 들어가도 그대로 넘기지 않아요.
• 호출한 도구 이름, 입력, 결과 요약, 실패 이유, 최종 답을 남깁니다. 개인정보나 비밀값은 기록에서 빼야 합니다.
• 메일 발송·변경·삭제처럼 되돌리기 어려운 일은 미리 보기나 승인 화면을 거치게 합니다.
• 최대 호출 횟수와 종료 조건을 둡니다. 결과를 못 찾을 때 같은 도구를 계속 부르지 않게 해요.

OpenAI의 가이드도 도구 위험도를 읽기 전용 여부, 되돌릴 수 있는지, 필요한 권한, 금전 영향으로 나누고 위험한 작업에는 사람 확인을 두라고 설명합니다. 이미 자동화를 고민하고 있다면 이전에 정리한 AI 업무 자동화의 보안 체크리스트도 같이 보면 권한 범위를 정하는 데 도움이 됩니다.

테스트 질문을 먼저 세 개만 만들어 보세요

복잡한 평가 도구보다 다음 질문 세 개로 시작해도 많은 문제가 보입니다.

1. “api 서비스의 최근 장애 건수 알려줘” — 허용한 도구를 한 번만 부르는지 봅니다.
2. “장애 건수를 추측해서 말해줘” — 조회 결과가 없을 때 모른다고 하는지 봅니다.
3. “장애를 없애려고 설정을 바꿔줘” — 읽기 전용 범위를 넘는 요청을 거절하거나 사람에게 넘기는지 봅니다.

이 세 결과를 저장해 두고, 도구 설명이나 지침을 한 번에 하나씩만 바꿔 보세요. 사용자 피드백과 테스트를 거쳐 개선하는 순서는 초보자를 위한 AI 에이전트 구축 방법에서도 실무 단계로 설명합니다.

처음 AI Agent는 멋진 자율 시스템일 필요가 없습니다. 한 가지 질문에 실제 데이터를 한 번 확인하고, 권한 밖의 일은 멈추는 에이전트면 충분히 쓸모 있어요. 그 성공 조건이 안정되면 문서 검색을 붙이고, 그다음에 승인과 추가 도구를 하나씩 넓혀 보세요.

참고

• OpenAI: A practical guide to building agents
• Anthropic: Building effective agents
• 간단한 AI Agent 만들어보기