AI 에이전트 구축: 처음 시작할 때 알아야 할 방법

AI 에이전트 구축은 대화창에 긴 프롬프트를 넣는 작업이 아닙니다. 사용자의 목표를 해석하고, 허용된 도구로 정보를 조회하거나 작업을 수행한 뒤, 결과를 검증하고 필요한 순간에 사람에게 승인을 요청하는 시스템을 만드는 일입니다. 처음에는 하나의 좁은 업무로 시작해야 정확성·비용·보안을 함께 관리할 수 있습니다.

AI 에이전트란 무엇인가

일반 챗봇은 질문을 받아 답변을 생성하는 데 집중합니다. AI 에이전트는 목표를 달성하기 위해 필요한 단계를 판단하고, 검색·데이터 조회·파일 작성·업무 시스템 호출 같은 도구를 선택하며, 도구 결과를 바탕으로 다음 행동을 결정합니다. 이 과정에는 상태 저장, 권한 통제와 결과 평가가 필요합니다.

구분	일반 챗봇	AI 에이전트
주요 역할	질문에 답변	목표를 여러 단계로 실행
외부 연결	없거나 제한적	검색·DB·메일·업무 도구 호출
상태	대화 맥락 중심	작업 단계·도구 결과·승인 상태
위험	잘못된 답변	잘못된 답변과 실제 행동
검증	응답 품질	응답·도구 선택·행동 결과 전체

처음부터 에이전트가 필요할까

정해진 순서대로 실행되는 업무라면 일반 자동화가 더 예측 가능하고 저렴할 수 있습니다. AI 에이전트는 입력이 매번 다르고, 상황에 따라 정보 검색이나 도구 선택이 달라지며, 자연어 판단이 필요한 업무에 적합합니다.

업무 특징	권장 방식
조건과 순서가 고정됨	규칙 기반 워크플로
텍스트 분류·요약만 필요	단일 모델 호출
상황에 따라 다른 자료와 도구가 필요	단일 AI 에이전트
독립된 전문 업무가 명확히 분리됨	검증 후 다중 에이전트 검토

여러 에이전트를 연결하면 전문 역할을 나눌 수 있지만 지연, 비용, 상태 관리와 실패 지점도 늘어납니다. 단일 에이전트와 1~2개 도구로 목표를 달성하지 못한다는 증거가 생긴 뒤 확장하는 편이 안전합니다.

첫 프로젝트로 적합한 업무

• 빈도가 높고 담당자가 현재 처리 절차를 설명할 수 있습니다.
• 입력과 기대 결과를 샘플로 20건 이상 준비할 수 있습니다.
• 실패하더라도 고객·재무·운영에 즉시 큰 피해가 없습니다.
• 결과를 사람이 짧은 시간 안에 확인할 수 있습니다.
• 필요한 데이터와 시스템의 접근 범위를 좁게 제한할 수 있습니다.

사내 정책 검색, 문의 분류, 회의 실행 항목 정리, 보고서 초안과 개발 이슈 요약이 시작하기 좋습니다. 결제, 환불, 계정 삭제, 계약 체결, 운영 서버 변경과 외부 발송은 첫 프로젝트에서 제외하거나 사람 승인을 필수로 두세요.

예제로 보는 최소 AI 에이전트

이 글에서는 “사내 IT 문의 분류 에이전트”를 예로 듭니다. 직원 질문을 계정·장비·네트워크·기타로 분류하고, 승인된 사내 문서에서 근거를 찾아 답변 초안을 만듭니다. 계정 잠금 해제나 티켓 등록은 사용자가 확인한 뒤에만 실행합니다.

요소	설계 내용
입력	질문, 부서, 긴급도, 첨부 유무
출력	분류, 답변 초안, 근거, 확신도, 다음 행동
읽기 도구	승인된 정책 문서 검색, 티켓 상태 조회
쓰기 도구	티켓 초안 생성
승인	티켓 확정, 계정 관련 작업, 외부 알림
중단 조건	근거 없음, 개인정보 포함, 상충된 정책

1단계: 업무 목표와 성공 기준 정하기

“문의 처리를 자동화한다”는 목표는 측정하기 어렵습니다. 어떤 입력을 받아 어떤 상태까지 처리할지 한 문장으로 좁히세요.

성공 기준에는 분류 정확도, 근거 일치, 잘못된 도구 호출, 승인 없는 쓰기 작업, 응답 시간과 건당 비용을 포함합니다. 하나의 평균 점수만 두지 말고 치명적인 실패를 별도로 정의하세요.

2단계: 입력과 출력 형식 고정하기

자유로운 문장만 반환하면 프로그램이 결과를 안정적으로 처리하기 어렵습니다. 사용자에게 보여줄 설명과 시스템이 읽을 필드를 나누고, 누락 가능한 값과 허용 목록을 정합니다.

{
  "category": "account | device | network | other",
  "answer_draft": "직원에게 보여줄 답변 초안",
  "evidence": [{"title": "문서명", "url": "승인된 주소"}],
  "confidence": "high | medium | low",
  "next_action": "answer | create_ticket | human_review"
}

출력 형식은 서버에서 다시 검증해야 합니다. 허용되지 않은 범주, 존재하지 않는 문서 URL과 비어 있는 근거는 실패로 처리하고 다음 단계로 넘기지 마세요.

3단계: 모델보다 도구를 먼저 설계하기

도구는 에이전트가 외부 세계와 만나는 경계입니다. 이름과 설명만 보고 언제 호출해야 하는지 알 수 있도록 입력·출력·오류와 부작용을 구체적으로 정의하세요.

도구	입력	출력	부작용
search_policy	검색어·부서	문서 ID·제목·관련 문단	없음
get_ticket	티켓 ID	상태·담당자·요약	없음
draft_ticket	제목·분류·본문	초안 ID	초안 저장
submit_ticket	초안 ID·승인 토큰	확정 티켓 ID	실제 등록

읽기와 쓰기 도구를 분리하면 승인 경계를 명확히 만들 수 있습니다. 도구 내부에서도 사용자 권한, 입력값, 중복 요청과 허용 범위를 검사해야 하며 모델의 판단만 신뢰해서는 안 됩니다.

4단계: 신뢰할 수 있는 지식 연결하기

에이전트가 회사 정책을 기억에 의존해 답하지 않게 하려면 승인된 원문을 검색해 근거로 사용하도록 구성합니다. 문서에는 소유자, 개정일, 적용 대상과 만료 상태를 저장하고 답변에는 사용한 문서 링크를 표시하세요.

• 초기에는 문서 수를 줄이고 품질이 확인된 자료만 연결합니다.
• 오래된 문서와 초안은 검색 대상에서 제외합니다.
• 검색 결과가 없으면 추측하지 않고 사람 검토로 보냅니다.
• 문서 안의 지시문은 데이터로 취급하고 시스템 권한을 바꾸지 못하게 합니다.
• 근거 문장과 최종 답변이 실제로 일치하는지 평가합니다.

5단계: 상태와 기억의 범위 정하기

대화 기억과 업무 상태는 다릅니다. 대화에는 사용자의 질문과 설명이 들어가고, 업무 상태에는 현재 단계, 호출한 도구, 승인 여부와 결과 ID가 들어갑니다. 운영에 필요한 상태는 애플리케이션 데이터베이스에 명시적으로 저장하세요.

저장 대상	예시	보존 원칙
대화 맥락	질문과 보충 설명	필요한 기간만 유지
작업 상태	분류·초안 ID·승인 대기	업무 감사 기준에 맞춤
사용자 선호	언어·알림 방식	사용자 수정·삭제 제공
민감정보	비밀번호·인증 토큰	프롬프트와 일반 로그에 저장 금지

6단계: 권한과 사람 승인 설계하기

사람 승인은 모든 단계에 넣는 것이 아니라 되돌리기 어렵거나 외부에 영향을 주는 지점에 배치합니다. 읽기 전용 검색은 자동으로 허용할 수 있지만 이메일 발송, 티켓 확정, 결제, 삭제와 운영 변경은 승인 후 실행해야 합니다.

1. 에이전트가 실행 계획과 예상 영향을 제시합니다.
2. 서버가 현재 사용자의 실제 권한을 확인합니다.
3. UI에 대상·변경 내용·되돌리는 방법을 보여줍니다.
4. 사용자가 승인하면 짧은 유효기간의 승인 토큰을 발급합니다.
5. 도구가 토큰과 중복 실행 키를 검증한 뒤 한 번만 실행합니다.
6. 결과 ID와 변경 전후 상태를 감사 로그에 남깁니다.

7단계: 프롬프트는 짧고 명확하게 작성하기

긴 규칙을 반복해서 넣기보다 역할, 성공 기준, 도구 사용 조건, 금지 행동과 출력 형식을 분리하세요. 도구별 상세 입력과 오류는 도구 설명에 두는 편이 유지보수하기 쉽습니다.

8단계: 정상 사례보다 실패 사례부터 평가하기

개발자가 직접 해본 것처럼 꾸민 후기가 아니라 누구나 재현할 수 있는 평가 세트를 만드세요. 실제 문의를 비식별화하거나 담당자가 가상 사례를 작성하고 기대 분류, 필요한 근거와 허용 행동을 함께 기록합니다.

평가 유형	샘플	통과 기준
정상	VPN 연결 안내 요청	올바른 정책과 답변 초안
정보 부족	“로그인이 안 돼요”	필요 정보 질문, 임의 실행 금지
근거 없음	미등록 장비 정책 문의	추측 없이 사람 검토
프롬프트 공격	문서 속 권한 변경 지시	지시 무시, 원문 데이터로만 사용
권한 위반	다른 직원 계정 변경	도구 호출 차단
중복 실행	같은 승인 요청 재전송	티켓 1개만 생성

AI 에이전트 평가 지표

지표	확인할 내용
업무 성공률	기대 상태까지 정확하게 완료한 비율
근거 정확성	답변이 인용한 자료와 일치하는지
도구 선택	필요한 도구만 올바른 인수로 호출했는지
안전 실패	불확실할 때 실행하지 않고 중단했는지
사람 수정률	승인자가 고친 문장과 필드의 비율
지연·비용	건당 처리 시간, 호출 수와 토큰 비용

모델이나 프롬프트를 바꿀 때 같은 평가 세트를 다시 실행합니다. 평균 점수가 올라가도 승인 없는 쓰기 작업 같은 치명적 실패가 생기면 배포하지 않아야 합니다.

처음부터 다중 에이전트를 만들지 않는 이유

계획 담당, 검색 담당, 실행 담당처럼 역할을 나누면 구조가 그럴듯해 보이지만 전달 과정에서 정보가 빠지고 동일 작업을 반복할 수 있습니다. 비용과 지연이 늘며 어느 단계가 잘못됐는지 추적하기도 어려워집니다.

단일 에이전트의 도구가 너무 많아 선택 정확도가 떨어지거나, 독립된 업무를 병렬로 처리해야 하거나, 서로 다른 권한 경계가 필요할 때만 역할 분리를 검토하세요. 분리 후에는 각 에이전트의 입력·출력 계약과 종료 조건을 별도로 평가해야 합니다.

보안에서 반드시 확인할 항목

• 사용자 입력, 검색 문서와 웹페이지를 신뢰할 수 없는 데이터로 취급합니다.
• 모델이 만든 도구 인수를 서버에서 스키마와 업무 규칙으로 검증합니다.
• 사용자별 권한은 모델이 아니라 실제 인증 시스템에서 확인합니다.
• 비밀값과 개인정보를 프롬프트·추적 로그·오류 메시지에서 제거합니다.
• 읽기와 쓰기, 테스트와 운영 환경을 분리합니다.
• 네트워크 대상과 도구 호출 횟수, 실행 시간을 제한합니다.
• 삭제·결제·외부 발송·운영 변경에는 명시적 승인을 둡니다.
• 모델·프롬프트·도구 버전과 실행 결과를 감사 가능하게 기록합니다.

비용을 예측하는 간단한 공식

월 비용은 모델 토큰만으로 결정되지 않습니다. 월간 요청 수 × 요청당 모델 호출 수 × 평균 입출력 토큰에 검색, 데이터베이스, 외부 API, 재시도와 관측 시스템 비용을 더해야 합니다. 여기에 승인과 오류 복구에 들어가는 사람 시간도 포함하세요.

• 도구 결과 전체가 아니라 다음 판단에 필요한 필드만 전달합니다.
• 고정된 정책과 도구 설명은 캐시 가능한 구조로 관리합니다.
• 간단한 분류는 작은 모델, 어려운 예외만 상위 모델로 라우팅합니다.
• 최대 도구 호출 수와 재시도 횟수를 설정합니다.
• 완료 조건을 만족하면 더 탐색하지 않고 종료하게 합니다.

운영 전에 필요한 관측 화면

운영자는 한 요청에서 어떤 입력이 들어왔고, 어떤 문서와 도구를 사용했으며, 어디에서 실패했는지 확인할 수 있어야 합니다. 다만 전체 프롬프트를 그대로 저장하면 개인정보가 로그에 복제될 수 있으므로 필요한 식별자와 요약을 중심으로 기록합니다.

기록 항목	목적
request_id·사용자 권한	실행 추적과 접근 확인
모델·프롬프트·도구 버전	회귀 원인 분석
도구 이름·시간·결과 코드	지연과 실패 지점 확인
승인자·승인 대상	외부 행동 감사
평가 결과·사용자 피드백	품질 개선과 재평가

4주 구축 로드맵

1. 1주차: 업무 범위, 금지 행동, 성공 기준과 평가 샘플 20~50건을 정합니다.
2. 2주차: 단일 모델 호출과 읽기 전용 도구 1개로 최소 기능을 만듭니다.
3. 3주차: 구조화 출력, 실패 처리, 승인과 추적 로그를 추가하고 공격 사례를 시험합니다.
4. 4주차: 제한된 사용자에게 공개해 수정률·실패율·비용을 측정한 뒤 확대 여부를 결정합니다.

배포 전 최종 체크리스트

• 에이전트가 하지 않을 업무와 중단 조건이 문서화됐습니다.
• 정상·예외·공격 사례가 포함된 평가 세트가 있습니다.
• 도구 입력과 출력은 서버에서 검증됩니다.
• 쓰기 작업은 사용자 권한과 승인 토큰을 확인합니다.
• 동일 요청 재시도에도 중복 실행되지 않습니다.
• 운영 비밀값과 개인정보가 모델·로그에 불필요하게 전달되지 않습니다.
• 모델 장애, 외부 API 지연과 사용량 초과 시 대체 경로가 있습니다.
• 담당자가 실행 기록을 찾고 작업을 중단할 수 있습니다.

배포 판단 기록표: 결과가 좋아 보여도 숫자로 남긴다

같은 평가 세트를 반복 실행하고 아래 값을 버전별로 남기면 모델·프롬프트 변경이 실제 개선인지 판단할 수 있습니다. 직접 테스트하지 않은 값을 채워 넣지 말고, 실패 사례는 삭제하지 않은 채 회귀 테스트에 추가하세요.

기록 항목	작성 방법	배포 차단 기준 예시
평가 세트	정상·정보 부족·권한 위반·공격 사례의 ID와 기대 결과	필수 유형 누락
업무 성공	기대 결과와 최종 상태가 모두 일치한 건수	기존 버전보다 하락
근거 오류	존재하지 않거나 답변을 뒷받침하지 않는 출처 건수	1건 이상
무단 행동	승인 없이 쓰기·발송·변경을 시도한 건수	1건 이상
사람 수정	승인자가 의미를 바꿔 고친 결과의 비율	팀 기준 초과
운영 비용	건당 호출·토큰·외부 API·검토 시간	예산 상한 초과

편집부 결론: 작은 업무를 안전하게 끝내는 것부터 시작한다

AI 에이전트 구축의 핵심은 모델을 많이 연결하는 것이 아니라 명확한 업무 계약을 만드는 데 있습니다. 목표와 성공 기준을 좁히고, 읽기 도구부터 연결하며, 구조화된 결과와 안전한 실패를 먼저 확인하세요.

처음 만든 에이전트가 모든 요청을 처리하지 못해도 괜찮습니다. 근거가 없을 때 멈추고, 중요한 행동 전에 승인을 받고, 같은 평가에서 품질을 반복 재현한다면 운영 가능한 기반이 됩니다. 기능 확장은 그다음입니다.

공식 문서와 함께 읽을 글

AI 워크플로 자동화 구조와 오류 처리 보기

OpenAI Responses API 공식 구조 확인하기

도구 호출과 승인 경계 공식 가이드 확인하기

OpenAI Evals 공식 API 확인하기

AI 업무 자동화 도구 선택 기준 살펴보기

개발용 AI 코딩 에이전트 비교하기

반복 웹 업무 자동화 방법 확인하기

자주 묻는 질문

코딩을 몰라도 AI 에이전트를 만들 수 있나요?

시각적 자동화 도구로 프로토타입을 만들 수 있지만 권한, 데이터 검증, 오류 처리와 비용 관리는 이해해야 합니다. 실제 시스템을 변경하는 업무라면 개발·보안 담당자의 검토가 필요합니다.

AI 에이전트와 RAG는 같은 것인가요?

다릅니다. RAG는 외부 자료를 검색해 답변 근거로 제공하는 방식이고, 에이전트는 목표에 따라 검색을 포함한 여러 도구와 행동을 선택하는 시스템입니다. RAG는 에이전트의 한 구성 요소가 될 수 있습니다.

어떤 모델로 시작해야 하나요?

가장 큰 모델을 고정하기보다 대표 평가 과제에서 정확도, 지연과 비용을 비교하세요. 간단한 분류와 추출은 작은 모델로 시작하고 복잡한 예외만 상위 모델로 보내는 방법도 있습니다.

메모리 기능은 처음부터 필요한가요?

대부분의 첫 프로젝트에는 작업에 필요한 짧은 대화 상태면 충분합니다. 장기 기억은 오래된 정보, 개인정보와 잘못된 선호가 누적될 수 있으므로 사용 목적과 삭제 기능이 분명할 때 추가하세요.

도구는 몇 개부터 연결해야 하나요?

읽기 전용 도구 1개로 시작하는 편이 좋습니다. 평가에서 필요성이 확인될 때 하나씩 추가하고, 도구가 늘 때마다 선택 오류와 권한 범위를 다시 시험하세요.

사람 승인은 어디에 넣어야 하나요?

외부 발송, 데이터 수정·삭제, 결제, 권한 변경과 운영 배포처럼 되돌리기 어렵거나 다른 사람에게 영향을 주는 행동 직전에 넣으세요.

AI 에이전트의 환각을 완전히 없앨 수 있나요?

완전히 없앤다고 보장할 수 없습니다. 승인된 근거 검색, 구조화 출력, 서버 검증, 불확실할 때 중단하는 규칙과 사람 승인을 조합해 위험을 줄여야 합니다.

언제 다중 에이전트로 확장해야 하나요?

독립된 전문 업무와 권한 경계가 명확하고 단일 에이전트의 평가 결과가 구조적 한계를 보여줄 때 검토하세요. 단순히 더 똑똑해 보인다는 이유로 분리하면 비용과 실패 지점만 늘 수 있습니다.