AI/AX2026-10-26

AI 에이전트 개발사 선정, 데모 다음에 볼 것

AI 에이전트 개발사는 어떤 기준으로 골라야 할까요? 데모 이후 확인할 업무 범위와 완료 조건, 예외 처리, 운영 역할을 비교표와 질문 목록으로 정리했습니다.

AI 에이전트 개발사 선정, 데모 다음에 볼 것 대표 썸네일

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

  • AI 에이전트 개발사 선정은 우리 업무를 어디까지 맡길지 정하는 데서 시작합니다.

  • 담당자는 같은 입력과 완료 조건으로 제안을 비교해야 합니다.

  • 개발 견적에는 오류 대응과 운영 담당자의 작업 범위도 포함되어야 합니다.


AI가 자료를 찾고 시스템에 내용을 입력하는 시연을 보면 도입 후 모습이 쉽게 그려집니다. 그런데 여러 개발사의 설명을 듣고 나면 실제 업무의 차이를 비교하기는 어려울 수 있는데요. 사용하는 모델이나 도구 이름은 달라도, 어느 제안이 우리 조직에 맞는지 판단할 근거가 부족하기 때문입니다.

개발사를 고를 때는 업무 범위, 완료를 판정할 증거, 운영 담당자의 역할을 같은 조건으로 비교하는 편이 좋습니다. 오늘은 AI 에이전트 개발사 선정 과정에서 데모 이후 무엇을 물어보고 제안서에 남겨야 하는지 알아보겠습니다.

1. 맡길 업무부터 좁혀야 합니다

1. 맡길 업무부터 좁혀야 합니다 — Unsplash 사진 조판

제안 요청의 출발점은 업무의 시작과 끝입니다. 요청을 어디서 받고, 어떤 자료를 읽으며, 무엇을 저장하면 일이 끝나는지 적어 봅니다. 답변 초안을 만드는 것과 업무 시스템에 최종 결과를 등록하는 것은 구현 범위가 다릅니다. 같은 자동화로 묶어 요청하면 개발사마다 다른 업무를 기준으로 견적을 낼 수 있습니다.

업무의 처리 순서가 일정하다면 정해진 절차를 따르는 방식이 맞을 수 있습니다. 반면 입력에 따라 필요한 자료나 도구를 골라야 한다면 에이전트의 판단이 들어갈 여지가 있습니다. Anthropic도 정해진 경로를 따르는 워크플로와 모델이 다음 행동을 정하는 에이전트를 구분합니다. 두 방식의 적용 조건은 에이전트 구축 가이드에서 더 자세히 보실 수 있습니다.

판단을 맡길 이유를 물어야 합니다

개발사에는 AI가 선택할 부분과 규칙으로 처리할 부분을 나눠 설명해 달라고 요청합니다. 모든 단계를 AI가 판단해야 한다는 답변보다, 어느 단계에 판단이 필요하고 왜 그런지를 업무로 설명하는 제안인지 살펴보세요. 판단 횟수가 늘면 확인할 결과와 실패 경로도 함께 늘어납니다.

똑똑한개발자팀은 이때 제외할 업무를 함께 적는 것이 중요하다고 봅니다. 첫 구축에서 다루지 않는 요청, 사람이 처리할 예외를 정하면 데모에서 보여준 기능과 계약에 포함되는 기능을 구분하기 쉬워집니다. 추가 연동이나 새로운 업무는 어떤 조건에서 별도 작업이 되는지도 확인할 수 있고요.

2. 같은 조건으로 결과를 비교해야 합니다

2. 같은 조건으로 결과를 비교해야 합니다 — Unsplash 사진 조판

개발사마다 준비한 성공 화면만 보면 비교 조건이 달라집니다. 평가용 입력, 사용할 자료, 허용된 행동, 완료 조건을 발주 담당자와 개발사가 함께 정하고 같은 묶음으로 확인하는 편이 좋습니다. 실제 자료를 공유하기 어렵다면 민감한 내용을 제거한 검토용 자료를 별도로 준비할 수 있습니다.

평가에는 업무 결과가 남아야 합니다. AI가 처리를 끝냈다고 답한 것과 실제 시스템에 결과가 저장된 것은 다를 수 있는데요. 저장된 항목이나 변경된 상태, 사람이 확인한 기록 중 무엇을 완료의 증거로 삼을지 정합니다. 답변의 말투나 화면의 매끄러움만으로 처리 성공을 판정하지 않는 이유입니다.

실패한 입력도 확인해야 합니다

일반적인 요청 외에 정보가 부족한 요청이나 도구가 응답하지 않는 상황을 넣어 봅니다. 이때 추가 정보를 묻는지, 작업을 멈추는지, 담당자에게 넘기는지 확인합니다. 한 번의 실패를 곧바로 업체 탈락 사유로 삼기보다는, 실패를 어떻게 발견하고 수정할 수 있는지를 함께 보자는 뜻입니다.

실제 제품을 평가하는 방식도 참고할 만합니다. Anthropic은 Claude Code를 개선하면서 간결한 응답과 파일 편집 같은 좁은 항목에서 시작해 평가 범위를 넓혔다고 설명합니다. 에이전트 평가 글은 실행 과정과 최종 결과를 구분하는 방법도 소개합니다.

업체별 답변은 아래처럼 같은 표에 남기면 미확인 부분이 드러납니다. 가능하다는 설명만 적기보다 무엇으로 확인했는지, 아직 확인하지 못했다면 다음 검증에 무엇이 필요한지도 기록합니다.

비교할 항목

개발사에 물을 질문

남길 자료

업무 범위

어디부터 어디까지 자동으로 처리하나요?

포함·제외 업무 목록

완료 조건

실제 처리가 끝났다는 것을 어떻게 확인하나요?

결과 화면과 검증 기록

예외 처리

정보가 부족하거나 도구가 실패하면 어떻게 되나요?

중단·재시도·이관 방식

변경 대응

업무 규칙이 바뀌면 누가 무엇을 수정하나요?

수정 범위와 재검증 방법

3. 운영할 사람의 일까지 정해야 합니다

3. 운영할 사람의 일까지 정해야 합니다 — Unsplash 사진 조판

구축 후에는 현업 담당자가 중단된 작업을 확인하고 처리할 수 있어야 합니다. 오류를 수정하는 개발사와 예외를 판단하는 운영자의 역할을 나눠 보세요. 담당자가 오류 내용을 볼 수 없거나 재처리 방법을 모른다면, 자동화가 멈출 때마다 개발사에 상황을 전달해야 합니다.

견적에서는 운영 화면과 기록이 포함되는지 확인합니다. 실패 목록, 처리 이력, 승인 대기 항목처럼 현업이 쓰는 기능이 시연 화면과 별도로 필요할 수 있기 때문입니다. 누가 자동화를 일시 중지할 수 있고 재개 전에 무엇을 확인하는지도 함께 정하면 운영 중 판단이 쉬워집니다.

변경 후 확인 범위를 정해야 합니다

업무 규칙이나 연결 시스템이 바뀔 때는 수정 후 검증도 작업에 포함합니다. 무엇을 바꿨고 어떤 입력으로 다시 확인했는지 전달받아야 다음 담당자가 변경 이유를 이해할 수 있습니다. 모델 사용료와 시스템 운영비, 개발사의 수정 작업비가 각각 어떻게 발생하는지도 구분해 두면 제안 금액을 비교할 때 도움이 됩니다.

최종 미팅에는 남아 있는 질문을 가져가 보세요. 답변이 명확하지 않은 항목은 계약 후에 확인할 것으로 넘기지 말고, 범위를 확정하기 위한 추가 점검으로 남깁니다.

  • 담당자가 개입해야 하는 상황과 화면을 볼 수 있나요?

  • 오류 수정 후 같은 업무를 다시 확인하는 절차가 있나요?

  • 업무가 추가될 때 기존 기능 수정과 신규 개발을 어떻게 구분하나요?


업무 이해부터 운영까지 연결해야 합니다

교육·컨설팅·개발을 연결한 통합 서비스를 소개하는 똑똑한개발자 AX 소개서 원본

똑똑한개발자는 업무 분석부터 시스템 개발·운영 개선까지 하나의 팀에서 진행합니다. 내부 시스템 똑빌더를 구축하고 영업·프로젝트 관리·콘텐츠 제작에 AI와 자동화를 적용해 왔으며, 사람이 최종 판단하는 방식도 실제 업무에서 사용하고 있습니다.

개발사 제안은 받았지만 어디까지 맡겨야 할지 고민되시나요? 아래 똑똑한개발자 링크로 문의해 주시면 업무 범위와 운영 조건을 함께 살펴보겠습니다.

감사합니다. :)


📚 이어서 읽어보세요

클립보드에 복사되었어요 ✓
이 글을 공유해보세요!