비즈니스 시스템(HRMS, ERP 등) 위에 에이전트를 배포하는 경우, 고객이 실제로 원하는 것과 현실적인 기대치는 무엇인가요?

제 생각엔 고객들은 시스템이 얼마나 '에이전트답게' 느껴지는지보다, 답변을 신뢰할 수 있는지, 그리고 그 답변이 어디서 나왔는지 이해할 수 있는지를 훨씬 중요하게 생각할 것 같습니다. 급여나 초과 근무 같은 문제라면 자율성보다는 신뢰성과 추적 가능성이 더 중요하겠죠.

좋은 답변이네요. 특정 애플리케이션은 에이전트의 결과물을 검증하기가 다른 것보다 쉽습니다. 그런 문제들이 가장 먼저 해결되어야 할 유형이죠.

작성자님께 질문 하나 드립니다. 저는 평생 엔터프라이즈 기업에서 일해왔는데, SMB(중소기업)들이 자동화에 기꺼이 지불할 의사가 있는 금액은 어느 정도라고 보시나요?

아키텍처 측면에서는 에이전트가 플랫폼 API를 직접 호출하게 하지 말고, 에이전트와 HRMS 사이에 직접 제어할 수 있는 데이터 계층을 두세요. 원본 시스템은 지저분하고 언제든 바뀔 수 있으니, 이미 검증된 깔끔한 수치를 에이전트가 읽게 하는 것이 좋습니다.

출석 데이터는 어디서 오나요? 타임카드인가요, 아니면 생체 인식 시스템인가요?

네

저는 요즘 Databricks Genie로 이 작업을 하고 있는데, 가장 큰 장점은 사람들이 실제로 시간을 보내는 곳(Teams, Slack, 모바일)에 배포할 수 있다는 점이었습니다. 그 이후로는 사용하기가 정말 간단했죠.

WhatsApp을 추가하기 전에, 소유자가 30일 동안 묻는 모든 급여 관련 질문을 기록하고 반복되는 질문들만 먼저 만드세요. 그래야 LLM을 도입하기 전에 쿼리 세트, 예상 답변, 그리고 실패 비용을 파악할 수 있습니다.

실질적인 가치는 결국 깔끔한 데이터와 단순한 질문에서 시작되는 것 같네요. 기반이 탄탄해진 후에 에이전트 계층을 추가하면 편리함이 더해지겠죠.

네, 전적으로 동의합니다.

저는 단열재 시공업체(5~50명 규모의 소규모 사업체)를 위한 소프트웨어를 만드는데, 패턴은 항상 똑같습니다. 소유자들은 실제로 질문을 하고 싶어 하지 않고, 그냥 보고받기를 원합니다. WhatsApp 쿼리 데모를 보여주면 다들 열광하지만, 2주만 지나면 아무도 아무것도 입력하지 않게 되죠. 결국 살아남는 건 매일 아침 어제의 근무 시간, 결근자, 초과 근무 임계값 초과 여부를 알려주는 지루한 고정 푸시 알림입니다. 그들 쪽에서 노력을 전혀 안 들이게 하는 것, 그게 핵심 비결이라고 봅니다.

아키텍처 측면에서는 별도의...