AI 파일럿은 시작하기 쉽습니다. 문제는 그다음입니다. 각 팀이 Slack 봇, 문서 검색 봇, 권한 신청 봇을 따로 만들기 시작하면, 어느 순간 회사에는 "AI 도입"이 아니라 "관리되지 않는 자동화 더미"가 남습니다.
AutoScout24의 사례가 흥미로운 이유는 AI를 잘 썼다는 데 있지 않습니다. 이 회사는 AI-powered workflows를 엔지니어링 생산성 확장의 수단으로 다루면서, 개별 챗봇이 아니라 재사용 가능한 내부 "Bot Factory"를 설계하는 방향으로 움직였습니다.1 AWS와 공개한 아키텍처 설명에 따르면, AutoScout24는 내부 개발자 지원 업무를 첫 대상로 삼았고, AI 플랫폼 엔지니어들이 반복 지원 업무에 최대 30%의 시간을 쓰고 있었다고 밝혔습니다.2
진짜 문제는 봇을 만드는 능력이 아니라 봇 난립을 막는 능력이다
AutoScout24가 처음부터 거대한 AI 플랫폼을 만든 것은 아닙니다. 여러 엔지니어링 팀이 각자 생성형 AI 도구와 프레임워크를 실험했고, 그 실험을 표준화된 개발·운영 방식으로 묶는 쪽으로 방향을 잡았습니다.2
여기서 핵심은 "AI를 어디에 붙일까"가 아닙니다. 더 중요한 질문은 이것입니다.
"모든 팀이 각자 비슷한 봇을 만들 때, 보안·권한·관측·장애 처리는 누가 책임지는가?"
AutoScout24의 첫 사용 사례는 내부 개발자 지원 봇이었습니다. 문서를 찾아 답하는 RAG와 GitHub Copilot 라이선스를 부여하는 도구 실행을 함께 검증했습니다.2 이는 좋은 출발점입니다. 반복적이고, 내부 사용자 대상이며, 실패했을 때 사람이 개입할 수 있고, 업무 절감 효과도 측정하기 쉽기 때문입니다.
실무적으로는 이런 조건이 맞을 때 "챗봇 하나"보다 "AI 워크플로우 플랫폼"을 고민할 만합니다.
여러 팀에서 같은 유형의 요청이 반복된다
답변뿐 아니라 권한 부여, 티켓 생성, API 호출 같은 실행이 필요하다
민감한 내부 문서나 계정 권한을 다룬다
누가 무엇을 요청했고, 에이전트가 어떤 판단을 했는지 추적해야 한다
성공·실패·비용·응답 지연을 운영 지표로 봐야 한다
표준화된 AI 워크플로우는 더 많은 자유가 아니라 더 적은 선택에서 나온다
AutoScout24의 구조는 전형적인 "엔터프라이즈용 안전장치"를 갖고 있습니다. Slack 요청은 API Gateway와 Lambda를 거치며 서명 검증을 하고, SQS FIFO 큐로 비동기 처리됩니다. 이후 Amazon Bedrock AgentCore에서 에이전트가 실행되고, Strands Agents 기반 오케스트레이터가 문서 검색 에이전트나 GitHub 작업 에이전트로 요청을 넘깁니다.2
눈에 띄는 부분은 화려한 모델보다 운영 패턴입니다. Slack 스레드마다 채널 ID와 타임스탬프를 조합한 sessionId를 만들고, 이를 통해 대화 맥락을 유지하면서도 세션 간 상태가 섞이지 않게 합니다. X-Ray로 요청 흐름을 추적할 수 있도록 한 점도 중요합니다.2
이 사례의 교훈은 역설적입니다. AI 도입 속도는 선택지를 무한히 열어둘 때가 아니라, 검증된 경로를 좁혀줄 때 빨라집니다.
모델 선택, 권한 모델, 로그 형식, 세션 격리, 시크릿 관리, 장애 처리 방식을 매번 새로 정하면 팀은 빠르게 시작하지만 느리게 운영합니다. 반대로 공통 런타임, 승인된 모델, 재사용 가능한 통합, 공통 관측 체계를 제공하면 개별 팀은 비즈니스 로직에 집중할 수 있습니다.
다만 대가도 있습니다. 표준화는 유연성을 줄입니다. 특정 클라우드와 관리형 서비스에 더 강하게 묶일 수 있고, 단순한 실험에도 플랫폼 규칙을 따라야 합니다. 모든 AI 아이디어를 "팩토리"로 밀어 넣는 것도 낭비입니다. 한 번 쓰고 말 개인 생산성 도구라면 중앙 플랫폼보다 가벼운 실험이 낫습니다.
내 조직에 AI 팩토리가 필요한지 판단하는 체크리스트
AutoScout24의 배경을 보면 이 회사는 생성형 AI를 무작정 제품에 붙이기보다, 내부 도구와 사용자-facing 기능을 구분해 접근했습니다. 자체 기술 블로그에서도 LLM의 환각, 비용, 지연 시간, 잘못된 정보의 위험을 언급하며 사용 사례를 좁히는 전략을 설명한 바 있습니다.3
따라서 이 모델을 따라 하기 전에 먼저 물어야 할 질문은 "우리도 Bedrock이나 AgentCore를 써야 하나?"가 아닙니다. 더 앞선 질문은 "우리에게 반복 가능한 AI 운영 문제가 이미 생겼는가?"입니다.
다음 항목 중 절반 이상이 해당된다면 내부 AI 워크플로우 표준화를 검토할 시점입니다.
AI 봇이 여러 팀에서 중복 개발되고 있다
내부 문서 검색과 시스템 실행이 결합된 요청이 많다
권한·시크릿·감사 로그를 중앙에서 관리해야 한다
실패 시 사람이 이어받는 절차가 정의돼 있다
응답 품질, 처리 시간, 비용을 측정할 수 있다
에이전트가 접근 가능한 데이터 범위를 제한할 수 있다
직원들이 결과를 검증하고 피드백할 습관이 있다
반대로 데이터 접근 권한이 정리되지 않았고, 문서 품질이 낮으며, 워크플로우 소유자가 불분명하다면 AI 에이전트는 문제를 해결하기보다 혼란을 자동화할 가능성이 큽니다.
AutoScout24 사례를 "AI 성공담"으로만 읽으면 놓치는 것이 있습니다. 진짜 변화는 챗봇이 똑똑해졌다는 점이 아니라, 기업이 AI를 소프트웨어 인프라처럼 다루기 시작했다는 점입니다. 엔지니어링 리더, 플랫폼 팀, 보안·운영 책임자가 지금 봐야 할 것은 어떤 봇을 만들지보다 어떤 봇을 만들지 말아야 하는지, 그리고 만들기로 한 봇을 어떤 공통 규칙 안에서 운영할지입니다.
참고
1AutoScout24 scales engineering with AI-powered workflows
2How AutoScout24 built a Bot Factory to standardize AI agent development with Amazon Bedrock
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.