9월 28일 월요일

에이전트가 유행을 지나 남든 사라지든, 조직은 무엇을 먼저 바꿔야 하는가?

에이전트의 장기적 승패를 예측하는 일보다 중요한 것은 도입 과정이 무엇을 강제로 드러내는지 보는 일이다. 사람이 경험으로 우회하던 불완전한 절차, 서로 뜻이 다른 데이터, 문서에 없는 예외, 애매한 권한은 자동화가 들어오는 순간 실패 지점이 된다. 따라서 성공의 기준을 ‘몇 가지 일을 대신했는가’에만 두면 기반 문제를 가린다. 정보의 뜻과 출처를 설명할 수 있는지, 시스템 사이의 맥락이 끊기지 않는지, 어떤 행동에 사람의 승인이 필요한지를 먼저 점검해야 한다. 모델 선택이나 시연 화면보다 데이터 품질, 공통 인터페이스, 승인 절차를 먼저 다듬어야 이후 도구가 바뀌어도 업무가 흔들리지 않는다. 이 정비는 특정 에이전트가 사라져도 남는 운영 자산이다.

1. 01

   데이터는 양보다 설명 가능성이 먼저다

   정보가 여러 앱과 팀, 파일, 개인의 기억에 흩어져 있으면 에이전트는 맥락을 복원할 수 없다. 접근 가능하게 만드는 것만으로도 부족하다. 각 정보가 무엇을 뜻하고 어디에서 왔으며 지금도 믿을 만한지 설명할 수 있어야 한다. 도입 전 진단은 새 도구 구매가 아니라 사일로, 중복 정의, 낡은 문서, 책임자를 모르는 데이터부터 찾는 작업이어야 한다.

2. 02

   자동화는 업무 절차의 빈칸을 폭로한다

   사람은 익숙한 업무에서 숨은 규칙을 알아서 보완한다. 반면 에이전트는 같은 입력에 다른 결과가 나오는 절차, 문서화되지 않은 예외, 앱 사이의 수동 복사를 그대로 실패로 돌려준다. 그래서 작은 시범 도입은 성능 시연이 아니라 스트레스 테스트로 설계할 필요가 있다. 마찰이 큰 두세 시스템을 연결해 어디에서 맥락과 책임이 끊기는지 확인하는 편이 화려한 기능 목록보다 유용하다.

3. 03

   가능한 행동과 허용할 행동은 다르다

   시스템이 어떤 동작을 지원한다고 해서 에이전트가 자동으로 실행해도 된다는 뜻은 아니다. 조회, 초안 작성, 외부 전송, 금전 거래처럼 위험이 다른 행동을 구분하고 승인 지점과 감사 기록을 정해야 한다. 권한 경계가 선명할수록 실패를 추적하고 되돌리기 쉬워진다. 도입 속도는 모든 권한을 한꺼번에 주는 데서가 아니라 안전하게 위임할 단위를 잘게 나누는 데서 나온다.

4. 04

   사람의 역할은 구현에서 문제 선택으로 이동한다

   구현 장벽이 낮아지면 현장 문제를 잘 아는 의료인, 공급망 운영자, 소상공인도 해결책 제작에 더 직접 참여할 수 있다. 그러나 만들 수 있다는 사실이 만들 가치가 있다는 결론을 대신하지는 않는다. 조직은 현장 전문가가 목표와 기대 결과를 정의하고, 기술 담당자가 출처·권한·안전 조건을 검토하는 협업 구조를 갖춰야 한다. 차별점은 코드 생산량보다 어떤 문제를 왜 풀 것인지 판단하는 능력으로 옮겨 간다.

운영자는 첫 도입의 성과표를 자동화 건수만으로 만들지 말아야 한다. 데이터 출처가 더 선명해졌는지, 앱 사이의 손실이 줄었는지, 승인과 책임이 문서화됐는지, 현장 전문가가 문제 정의에 참여했는지를 함께 측정해야 한다. 이 네 가지가 개선되지 않았다면 에이전트는 낡은 절차 위에 새 인터페이스만 얹었을 가능성이 크다. 반대로 기반이 좋아졌다면 특정 도구의 흥망과 무관하게 다음 기술을 받아들일 준비가 남는다.