10월 13일 화요일
AI를 일에 넣는 순간 중요한 것은 더 많은 자동화가 아니라, 현업의 판단을 옮기는 책임 구조와 가능성을 제품으로 검증하는 실험 구조다.
현업이 에이전트를 만들 때, 사람의 일은 사라지지 않고 재배치된다
재무 설계사의 사례는 AI 도입의 출발점이 도구 선택이 아니라 반복 업무, 판단 기준, 질문할 순간, 넘지 말아야 할 선을 함께 정하는 일임을 보여 준다.

책임이 큰 업무에서 현업 주도 에이전트는 무엇을 맡고, 사람은 무엇을 끝까지 지켜야 하는가?
Range의 재무 설계사들이 바꾼 것은 문장을 더 빨리 쓰는 방법이 아니었다. 한 설계사가 고객과 통화하는 동안 에이전트가 다른 고객의 현금흐름이나 보험 분석 초안을 준비하게 해, 사람의 시간을 순차 작업에서 검토와 판단으로 옮겼다. 여기서 에이전트는 고객에게 아무것도 직접 보내지 않는다. 설계사가 모든 추천을 검토하고 조정한 뒤 전송을 결정한다. 생산성은 책임자를 제거해서가 아니라 첫 초안과 최종 판단을 분리해 동시성을 만든 데서 나온다. 그래서 도입 질문도 ‘모델이 무엇을 할 수 있는가’보다 ‘어떤 반복 업무를 초안으로 넘기고, 어느 지점에서 반드시 사람이 멈춰 확인할 것인가’가 먼저다.
- 01
업무를 고르는 기준
첫 대상은 가장 복잡하고 화려한 일이 아니라, 자주 반복되고 수작업이 많으며 좋은 결과와 나쁜 결과를 현업이 빠르게 가려낼 수 있는 일이다. Range가 현금흐름 분석과 보험 검토를 택한 이유도 여기에 있다. 품질을 판별할 수 없는 업무는 에이전트를 시험할 수도 신뢰할 수도 없다. 도입 범위를 좁히는 일은 소극적인 선택이 아니라 검증 가능한 출발선을 만드는 결정이다.
- 02
절차보다 판단을 기록한다
현업 전문가는 완료된 실제 사례를 처음부터 끝까지 되짚으며 무엇을 클릭했는지뿐 아니라 왜 그렇게 했는지, 무엇을 찾았는지, 정보가 부족할 때 언제 질문해야 하는지를 설명했다. 이 설명을 ‘스킬’, 곧 조직이 특정 업무를 수행하는 방식을 적은 업무 레시피로 묶었다. 절차만 적으면 혼자 계속 실행하는 자동화가 되지만, 시작 전 질문과 추측 금지 조건, 절대로 혼자 하지 않을 행동까지 적으면 통제 가능한 협업자가 된다.
- 03
팀 자산에는 소유권이 붙는다
초기 스킬은 실제 사례에서 5~10회 실행하며 빠진 질문, 예상 밖 사례, 자신 있게 틀린 지점을 찾아 고친 뒤 공유했다. 배포 뒤에는 작성자와 다른 리뷰어가 확인하고, 프로세스나 규정이 바뀔 때 최신 상태를 책임질 소유자를 둔다. 개인의 편리한 단축키가 여러 사람이 의존하는 기반으로 바뀌는 순간, 품질 검토와 유지 책임도 함께 커진다. Range에서는 이런 방식으로 6개월 만에 24개 스킬이 생겼고 그중 17개가 플래닝 업무에 속했다.
이 사례가 제시하는 운영 조건은 분명하다. 에이전트는 반복적인 첫 초안을 맡고, 현업은 예외 판단과 품질 검토, 고객에게 전달할 최종 결정권을 가진다. 업무를 실제로 아는 사람이 판단 기준과 중단 조건을 쓰고, 실제 사례로 반복 검증하며, 별도 리뷰어와 소유자가 변경을 관리해야 한다. AI 도입의 병목은 초안 생성 능력에서 조직의 지식을 누가 명시하고 검증하며 책임질지로 이동한다. 현업의 역할은 줄어드는 것이 아니라, 작성자에서 설계자·검토자·책임자로 다시 정의된다. 초안이 늘수록 사람이 확인할 기준과 검토 작업량도 함께 설계해야 한다. 처리량이 커져도 고객이 보는 결과에 대한 책임이 자동으로 이전되지는 않는다. 도입 성과는 몇 분을 줄였는지가 아니라, 책임 경계를 지키며 동시에 진행할 수 있는 일이 늘었는지로 판단해야 한다.
AI 제품의 속도는 더 긴 계획이 아니라 더 짧은 판단 주기에서 나온다
구글 랩스의 운영법은 빠르게 바뀌는 기술을 모두 좇는 대신, 작은 팀이 사용자 반응을 확인하고 틀린 가설을 버리며 될 만한 실험만 확장하는 구조를 제안한다.
가능성을 발견하는 팀과 본업의 집중을 함께 지킨다
AI의 가능성이 자주 바뀌면 전 직원이 매주 새 도구를 좇게 하거나, 반대로 기존 계획 때문에 새 신호를 놓치기 쉽다. Google Labs가 제시한 답은 최전선을 살피는 소수 팀에 탐색 권한을 주고 나머지 조직의 집중력을 보호하는 것이다. 이 팀은 ‘거의 가능한 것’의 목록을 관리하고, 새 능력이 실제로 가능해지는 순간 사용자 문제와 연결한다. 다만 신기한 기술만으로는 제품 후보가 되지 않는다. 48시간이 지나도 계속 생각나는 데모인지, 반복되는 필요와 이어지는지, 누군가 없어서는 안 된다고 느끼고 비용을 지불할 가치가 있는지를 함께 본다. 독립성은 실험을 지키지만, 발견을 기존 회사의 사용자와 제품으로 옮기는 다리가 없으면 랩스는 고립된다.
초기 판단은 대시보드보다 사람의 반응에서 시작한다
아직 사용자가 적은 0→1 단계에서 큰 조직의 지표를 그대로 적용하면 약한 숫자만 남는다. 그래서 초기 프로토타입을 실제 사람에게 보여 주고 눈이 밝아지는지, 몸이 앞으로 기우는지, 더 묻는지, ‘이걸 원한다’고 말하는지를 관찰한다. 이 반응은 최종 증명이 아니라 다음 실험에 투자할 첫 신호다. 반응이 없으면 특정 해법을 지키기보다 사용자의 문제로 돌아가 세 번에서 다섯 번 피벗할 수 있어야 한다. 팀이 열정을 잃고 가능한 시도를 다 했다고 느낄 때는 리더보다 먼저 실패를 감지할 수도 있다. 담당자가 출시 직전 멈추자고 말해도 비난하지 않는 문화가 있어야 불필요한 확장을 막는다.
실험과 확장은 서로 다른 운영 언어를 쓴다
작은 Labs 프로젝트의 인원은 과거 5~7명에서 2~4명으로 줄어드는 추세이며, 좋은 팀은 아이디어에서 의미 있는 진전까지 50~100일을 목표로 한다. 장기 비전은 유지하되 실제 계획 창은 약 6개월로 짧게 두고, 20~30개 실험을 각자의 마일스톤과 시즌으로 운영한다. 반응을 찾는 0→1, 반복 가능한 성장을 만드는 1→10, 큰 규모에서 전환과 효율을 관리하는 10→100은 같은 성공 기준을 쓸 수 없다. 검증 전에 사람을 늘리는 것은 성과가 아니며, 30명의 엔지니어와 비전이 있어도 제품-시장 적합성이 없으면 확장은 실패를 크게 만들 뿐이다.
도입 결정은 기술보다 운영 조건을 먼저 묻는다
기업이 가져갈 핵심은 ‘랩스’라는 이름이 아니라 판단 구조다. 누가 새 가능성을 살피고, 어떤 사용자 문제와 연결하며, 언제 실험을 멈추고, 어떤 증거가 생겼을 때 본사업으로 넘길지를 정해야 한다. 모두가 빌더가 되더라도 제품·디자인·엔지니어링·마케팅의 전문성은 각자의 중심으로 남는다. 빠른 제작은 전문성을 없애는 대신 서로의 판단을 더 자주 제품으로 시험하게 한다. 동시에 전력 질주 뒤에는 탐색과 회복의 시간을 두어 다음 아이디어의 씨앗을 만들고, 틀린 가설을 빨리 버리는 ‘비학습’ 능력을 보상해야 속도와 지속성을 함께 얻을 수 있다. 실험 포트폴리오의 목적은 많은 프로젝트를 오래 유지하는 데 있지 않다. 사용자 신호가 약한 선택은 빨리 닫고 강한 신호가 확인된 곳으로 사람과 운영을 옮겨야 한다. 무엇을 시작했는지만큼 무엇을 멈췄는지도 제품 조직의 속도를 결정한다.
아직 못 읽은 북마크
북마크를 고르는 중…