AI 에이전트 만드는 방법: 기획부터 배포까지 5단계

AI 에이전트 만드는 방법이란?
AI 에이전트를 만드는 일은 모델을 고르는 작업이 아니다. 처리할 업무를 좁게 정의하고 도구와 데이터 접근 권한을 설계한 뒤, 평가 기준을 세워 배포와 운영을 반복하는 5단계 과정이다. 실패는 대부분 모델 성능이 아니라 범위 설정과 평가 체계가 없어서 생긴다.

모델부터 고르면 왜 실패하는가

AI 에이전트 구축 문의를 받으면 열에 아홉은 "어떤 모델을 써야 하나요"로 시작한다. 순서가 뒤집혔다. 모델 선택은 5단계 중 세 번째에 오는 결정이고, 그마저도 나중에 바꾸기 가장 쉬운 항목이다.

에이전트는 챗봇과 다르다. 챗봇은 답변을 생성하고 끝난다. 에이전트는 도구를 호출하고, 외부 시스템의 상태를 바꾸고, 여러 단계를 스스로 이어간다. 잘못된 답변의 비용이 "고객이 불만족한다"에서 "잘못된 환불이 실행됐다"로 바뀐다. 이 차이가 설계 순서를 결정한다.

업계 조사에서 되풀이되는 패턴이 있다. 실험에 착수한 기업은 많지만 파일럿 이후 실제 운영 단계까지 확장한 곳은 소수에 그친다. 2025년 말 기준 조사에서 에이전틱 AI를 어떤 형태로든 시도한 기업이 다수인 반면, 하나라도 파일럿을 넘겨 확장한 곳은 그중 일부에 불과하다고 알려져 있다. 이 격차가 이 글의 출발점이다.

단계별로 무엇을 정하고 무엇을 버리는가

1단계. 업무를 좁힌다

"고객 문의를 처리하는 에이전트"는 기획이 아니다. 범위 정의는 다음 세 문장이 채워질 때 끝난다. 어떤 입력이 들어오는가, 어떤 판단을 대신하는가, 무엇을 하면 절대 안 되는가.

쓸모 있는 첫 후보는 대개 지루하다. 반복 빈도가 높고, 정답이 명확하고, 틀렸을 때 되돌릴 수 있는 업무다. 계약서 검토처럼 화려한 후보는 세 조건을 모두 어긴다. 첫 에이전트로는 부적합하다.

2단계. 도구와 데이터 접근을 설계한다

에이전트의 능력은 모델이 아니라 손에 쥔 도구가 결정한다. 사내 위키를 못 읽는 에이전트는 아무리 좋은 모델을 써도 사내 규정을 답하지 못한다. 반대로 삭제 권한까지 쥔 에이전트는 언젠가 사고를 낸다.

• 읽기와 쓰기를 분리한다. 조회 도구는 넓게 열고, 상태를 바꾸는 도구는 최소한으로 준다
• 되돌릴 수 없는 동작(발송, 결제, 삭제)은 사람 승인 단계를 강제로 끼운다
• 도구 설명문을 API 문서처럼 쓰지 않는다. 언제 쓰고 언제 쓰면 안 되는지를 적는다
• 데이터 접근 로그를 남긴다. 사고가 났을 때 재구성할 수 있어야 한다

최근 기업 도입 흐름은 단일 작업 자동화에서 여러 단계를 잇는 워크플로 쪽으로 옮겨간다. Anthropic이 리서치 기관 Material과 함께 기술 리더 500명 이상을 조사한 결과, 응답 기업의 57%가 다단계 워크플로에 에이전트를 배치한다고 답했다. 단, 이 조사는 에이전트 인프라를 파는 기업이 직접 수행했으므로 도입 속도가 실제보다 낙관적으로 잡혔을 여지를 감안해 읽어야 한다.

SOURCE · 다단계 워크플로 57% | Anthropic·Material 기업 조사 (2025.12) ↗ 원문

3단계. 워크플로를 짜고 모델을 붙인다

여기서야 모델이 등장한다. 그리고 대부분의 업무는 자율 에이전트가 필요 없다. 분기가 정해진 절차라면 규칙 기반 워크플로에 모델을 부분적으로 끼우는 편이 싸고 안정적이다. 자율성은 예외 상황이 많고 경로를 미리 못 그릴 때만 값을 한다.

4단계. 평가 체계를 먼저 만든다

파일럿에서 멈추는 프로젝트의 공통점은 "잘 되는 것 같다"는 감각만 있고 숫자가 없다는 점이다. 데모는 성공 케이스 다섯 개로 만들어진다. 운영은 실패 케이스 오백 개를 견뎌야 한다.

평가셋은 거창할 필요가 없다. 실제 과거 요청 30~50건에 정답과 오답 판정 기준을 붙이면 시작된다. 여기에 세 가지 지표를 얹는다. 과제 완수율, 사람 개입이 필요했던 비율, 건당 토큰 비용. 세 번째를 빼먹으면 성능은 좋은데 단가가 사람보다 비싼 에이전트가 나온다.

5단계. 좁게 배포하고 관측한다

전사 배포는 마지막이다. 한 팀, 한 업무, 한 달. 이 기간에 봐야 하는 건 만족도 설문이 아니라 로그다. 어떤 요청에서 도구 호출이 실패했는지, 어디서 사람이 개입했는지, 어떤 입력이 평가셋에 없던 유형인지.

운영 비용도 이 단계에서 확정된다. 모델 API 요금은 2026년 8월 기준으로도 분기 단위로 바뀌어서, 도입 시점 단가를 고정값으로 두고 짠 ROI 계산은 몇 달 만에 무의미해진다. 계약 전 기준 연월을 문서에 박아두고 재산정 주기를 정해야 한다.

과장된 기대와 실제 사이

시장 전망치는 넘친다. 에이전틱 AI가 2030년까지 수천억 달러 규모의 매출 기회를 만든다는 추정, 엔터프라이즈 애플리케이션 상당수가 2026년 안에 에이전트를 내장한다는 예측이 대표적이다. 이런 수치는 대부분 AI 전환 컨설팅이나 인프라를 파는 조직에서 나온다. 방향은 참고하되 의사결정 근거로 쓰기엔 이해관계가 걸려 있다.

더 조심할 대상은 기업의 자체 성과 발표다. "AI로 생산성 X% 개선"이라는 발표가 공개 재무 지표나 채용 규모와 어긋나는 사례가 되풀이된다. 독립 검증이 없는 수치는 벤치마크가 아니라 마케팅 메시지에 가깝다. 자사 도입 근거로 인용하기 전에 산정 방식이 공개돼 있는지부터 확인하는 편이 안전하다.

투자 판단 자체를 어떻게 계산할지는 별도 주제다. 도입 비용과 회수 기간을 어떤 구조로 봐야 하는지는 AI 전환 ROI: 기업이 알아야 할 경제학에서 따로 다룬다.

더 읽어보기

• AI 전환 ROI: 기업이 알아야 할 경제학

자주 묻는 질문

노코드 도구로 만들어도 되나?

첫 검증에는 적합하다. 1~2단계를 빠르게 돌려보는 용도로 쓰면 기획의 허점이 며칠 만에 드러난다. 다만 사내 인증 연동, 감사 로그, 세밀한 권한 제어가 필요해지는 시점에 대부분 한계에 부딪힌다. 검증용과 운영용을 같은 도구로 끌고 가겠다는 전제만 버리면 된다.

사내 데이터를 학습시켜야 하나?

대부분 아니다. 파인튜닝은 형식과 말투를 고정할 때 값을 하고, 지식을 최신으로 유지하는 문제는 검색 기반 참조로 푸는 편이 낫다. 학습부터 검토하는 조직은 대개 2단계의 데이터 접근 설계를 건너뛴 상태다.

몇 명이 붙어야 하나?

첫 에이전트라면 엔지니어 1~2명과 해당 업무를 실제로 하는 실무자 1명이면 충분하다. 빠지면 안 되는 쪽은 실무자다. 평가 기준의 정답을 판정할 사람이 없으면 4단계가 통째로 비고, 그 상태로는 배포 여부를 결정할 근거가 생기지 않는다.

다음 단계

에이전트 도입 검토를 시작했다면 가장 먼저 할 일은 도구 비교가 아니다. 후보 업무를 다섯 개 적어보고 되돌릴 수 있는 순서로 정렬하는 것이다. 그 목록이 곧 1단계의 산출물이다. AI 전환 설계와 실행 사례는 Nitrox 블로그의 AX 가이드에서 이어서 볼 수 있다.