엔지니어링 인력 채용 업체 하우디닷컴(Howdy.com)의 설문조사에서 AI를 사용하는 지식 근로자 3분의 2가 AI 에이전트를 사용하고, 16%는 직접 에이전트를 개발하기 시작한 것으로 나타났습니다. 설문은 직원들이 조직 승인 없이 개발했는지는 묻지 않았지만, 하우디닷컴 창업자 프랭크 리세아(Frank Licea)는 실제로 많은 직원이 승인을 기다리지 않고 만들고 있다고 말했습니다. 그는 직원들이 개발을 중단하지는 않았지만 안전한 개발을 위한 가드레일과 시스템 지침을 마련할 때까지 기다려 달라고 요청한 사례를 들었습니다. 직원들은 지루한 수작업을 자동화하고 싶어 하며, 리세아는 조직마다 기술에 관심이 많고 호기심이 강한 직원이 있다고 설명했습니다.

에이전트 사용자 약 4명 중 1명은 출력이 일관되지 않거나 처음부터 제대로 작동하지 않아 사용하던 에이전트를 비활성화했다고 답했습니다. 지식 근로자 7%는 통제를 벗어난 AI 에이전트를 중단해야 했다고 밝혔습니다. 최근 몇 달 동안 하우디닷컴 직원들은 IT 부서 승인을 기다리지 않고 수작업을 자동화한 방법을 서로 공유했습니다. 기술 담당자는 이 사례를 들으며 어떤 API 키를 썼는지, 암호화된 데이터에 접근하는지, SOC 2 준수에 어떤 영향을 주는지 물었습니다.

소프트웨어 엔지니어링 서비스 업체 싱귤러(Sngular)의 제품 엔지니어링 부사장 루이스 메사스(Luis Mesas)는 직원이 에이전트를 만드는 흐름은 기업의 공식 허용 여부와 관계없이 계속될 것이라고 말했습니다. 그는 개발 진입 장벽이 낮아지고 엔지니어링팀은 더 적은 자원으로 더 많은 일을 하라는 요구를 받는다고 설명했습니다. 메사스는 핵심 관리 과제가 에이전트 개발 자체가 아니라, 일반 소프트웨어에 적용되는 통제 없이 기업 시스템과 데이터에 연결되는 상황이라고 지적했습니다.

메사스는 IT 리더가 직원이 만든 에이전트의 내부 시스템·데이터 연결 방식을 파악해야 한다고 말했습니다. 예를 들어 에이전트가 고객관계관리(CRM) 시스템에서 고객 정보를 가져오거나, 레코드를 수정하거나, 시스템 간 정보를 옮긴다면 그 접근 범위와 직원에게 필요한 권한인지 확인해야 한다는 설명입니다. 메사스는 개인 생산성 도구로 시작한 에이전트가 기업 차원의 기술 관리 문제가 되는 지점이라고 말했습니다.

B2B 커머스 플랫폼 업체 앱다이렉트(AppDirect)의 CTO 앤디 센(Andy Sen)은 직원의 에이전트 개발을 장려하되 명확한 가드레일과 정책 안에서 이뤄져야 한다고 강조했습니다. 센은 섀도 IT가 늘 존재했으며 섀도 에이전트는 그 최신 형태라고 말했습니다. 앱다이렉트는 직원들에게 디지털 실험 환경을 제공하고, 직원 요구에 따라 AI 기반 코딩 서비스 데브스닷AI(Devs.AI)를 개발했습니다. 센에 따르면 이 서비스로 직원들은 자유롭게 개발하고 혁신할 수 있으며 IT 부서는 사용 현황과 비용을 파악하고 기업 데이터가 외부로 유출되지 않는다는 확신을 가질 수 있습니다.

센은 직원이 만든 에이전트 4개 중 1개가 비활성화되는 상황을 IT 리더가 주의 깊게 살펴야 한다고 말했습니다. 실패와 학습은 괜찮지만, 아무도 모르게 실패해서는 안 되며 작은 문제가 심각해지기 전에 에이전트의 동작을 파악해야 한다는 설명입니다. 그는 ‘통제를 벗어난’ 사례라는 보고에는 회의적이었습니다. 에이전트가 지시대로 행동했지만 지시가 잘못된 경우가 대개라며, 책임은 에이전트가 아니라 개발자에게 있다고 주장했습니다.

애자일 방법론 업체 스케일드 애자일(Scaled Agile)의 수석 방법론 전문가 앤드루 세일즈(Andrew Sales)는 많은 에이전트가 비활성화됐다는 점을 IT 리더가 원인을 조사해야 할 신호로 봤습니다. 관리 체계 밖에서 에이전트를 빠르게 만들면 수행할 작업의 범위, 접근 가능한 데이터, 사람의 개입 시점에 경계가 없는 경우가 많다고 설명했습니다. 세일즈는 AI 거버넌스가 부정적 결과 예방에만 머물러서는 안 되며 개인 실험의 좋은 아이디어를 기업 역량으로 발전시키는 경로도 마련해야 한다고 말했습니다. 효과가 있는 사례를 찾아 표준화하고 안전성을 확보한 뒤 여러 팀으로 책임 있게 확산하면 문제 에이전트를 찾아내는 동시에 성공 사례도 조직 전체에 퍼뜨릴 수 있다고 덧붙였습니다.

엔지니어링 인력 채용 업체 하우디닷컴(Howdy.com)의 설문조사에서 AI를 사용하는 지식 근로자 3분의 2가 AI 에이전트를 사용하고, 16%는 직접 에이전트를 개발하기 시작한 것으로 나타났습니다. 설문은 직원들이 조직 승인 없이 개발했는지는 묻지 않았지만, 하우디닷컴 창업자 프랭크 리세아(Frank Licea)는 실제로 많은 직원이 승인을 기다리지 않고 만들고 있다고 말했습니다. 그는 직원들이 개발을 중단하지는 않았지만 안전한 개발을 위한 가드레일과 시스템 지침을 마련할 때까지 기다려 달라고 요청한 사례를 들었습니다. 직원들은 지루한 수작업을 자동화하고 싶어 하며, 리세아는 조직마다 기술에 관심이 많고 호기심이 강한 직원이 있다고 설명했습니다.

에이전트 사용자 약 4명 중 1명은 출력이 일관되지 않거나 처음부터 제대로 작동하지 않아 사용하던 에이전트를 비활성화했다고 답했습니다. 지식 근로자 7%는 통제를 벗어난 AI 에이전트를 중단해야 했다고 밝혔습니다. 최근 몇 달 동안 하우디닷컴 직원들은 IT 부서 승인을 기다리지 않고 수작업을 자동화한 방법을 서로 공유했습니다. 기술 담당자는 이 사례를 들으며 어떤 API 키를 썼는지, 암호화된 데이터에 접근하는지, SOC 2 준수에 어떤 영향을 주는지 물었습니다.

소프트웨어 엔지니어링 서비스 업체 싱귤러(Sngular)의 제품 엔지니어링 부사장 루이스 메사스(Luis Mesas)는 직원이 에이전트를 만드는 흐름은 기업의 공식 허용 여부와 관계없이 계속될 것이라고 말했습니다. 그는 개발 진입 장벽이 낮아지고 엔지니어링팀은 더 적은 자원으로 더 많은 일을 하라는 요구를 받는다고 설명했습니다. 메사스는 핵심 관리 과제가 에이전트 개발 자체가 아니라, 일반 소프트웨어에 적용되는 통제 없이 기업 시스템과 데이터에 연결되는 상황이라고 지적했습니다.

메사스는 IT 리더가 직원이 만든 에이전트의 내부 시스템·데이터 연결 방식을 파악해야 한다고 말했습니다. 예를 들어 에이전트가 고객관계관리(CRM) 시스템에서 고객 정보를 가져오거나, 레코드를 수정하거나, 시스템 간 정보를 옮긴다면 그 접근 범위와 직원에게 필요한 권한인지 확인해야 한다는 설명입니다. 메사스는 개인 생산성 도구로 시작한 에이전트가 기업 차원의 기술 관리 문제가 되는 지점이라고 말했습니다.

B2B 커머스 플랫폼 업체 앱다이렉트(AppDirect)의 CTO 앤디 센(Andy Sen)은 직원의 에이전트 개발을 장려하되 명확한 가드레일과 정책 안에서 이뤄져야 한다고 강조했습니다. 센은 섀도 IT가 늘 존재했으며 섀도 에이전트는 그 최신 형태라고 말했습니다. 앱다이렉트는 직원들에게 디지털 실험 환경을 제공하고, 직원 요구에 따라 AI 기반 코딩 서비스 데브스닷AI(Devs.AI)를 개발했습니다. 센에 따르면 이 서비스로 직원들은 자유롭게 개발하고 혁신할 수 있으며 IT 부서는 사용 현황과 비용을 파악하고 기업 데이터가 외부로 유출되지 않는다는 확신을 가질 수 있습니다.

센은 직원이 만든 에이전트 4개 중 1개가 비활성화되는 상황을 IT 리더가 주의 깊게 살펴야 한다고 말했습니다. 실패와 학습은 괜찮지만, 아무도 모르게 실패해서는 안 되며 작은 문제가 심각해지기 전에 에이전트의 동작을 파악해야 한다는 설명입니다. 그는 ‘통제를 벗어난’ 사례라는 보고에는 회의적이었습니다. 에이전트가 지시대로 행동했지만 지시가 잘못된 경우가 대개라며, 책임은 에이전트가 아니라 개발자에게 있다고 주장했습니다.

애자일 방법론 업체 스케일드 애자일(Scaled Agile)의 수석 방법론 전문가 앤드루 세일즈(Andrew Sales)는 많은 에이전트가 비활성화됐다는 점을 IT 리더가 원인을 조사해야 할 신호로 봤습니다. 관리 체계 밖에서 에이전트를 빠르게 만들면 수행할 작업의 범위, 접근 가능한 데이터, 사람의 개입 시점에 경계가 없는 경우가 많다고 설명했습니다. 세일즈는 AI 거버넌스가 부정적 결과 예방에만 머물러서는 안 되며 개인 실험의 좋은 아이디어를 기업 역량으로 발전시키는 경로도 마련해야 한다고 말했습니다. 효과가 있는 사례를 찾아 표준화하고 안전성을 확보한 뒤 여러 팀으로 책임 있게 확산하면 문제 에이전트를 찾아내는 동시에 성공 사례도 조직 전체에 퍼뜨릴 수 있다고 덧붙였습니다.