10월 15일 목요일

작동하는 AI를 사용자가 더 큰 일까지 맡기는 운영 주체로 바꾸려면 무엇을 먼저 설계해야 하는가?

사용자의 부탁을 해석해 브라우저 같은 외부 시스템에서 실제 행동까지 수행하는 AI 에이전트는 답변 도구와 다른 긴장을 만든다. Meta Muse의 출발점도 무엇이든 해내는 완성품이 아니라 자주 고장 나는 시제품이었다. 팀은 일곱 달 동안 추상적인 범용성을 좇기보다 사용자가 맡길 행동을 잘게 나누고, 각 행동의 평가와 첫 사용 경험을 반복해서 살폈다. 이메일 발송이나 구매처럼 바깥에 결과를 남기는 순간에는 확인을 요청하고, 접근할 앱도 사용자가 정하게 했다. 여기서 신뢰는 높은 평균 점수가 아니라 다음 부탁을 맡길 수 있다는 경험으로 만들어진다. 기업의 핵심 업무에서는 이 원칙이 더 엄격해진다. 네 주 동안 에이전트 초안이 분석가 보고서와 한 줄씩 맞았어도 그것은 기능이 작동한다는 증거일 뿐이다. 실제 투입 전에는 어떤 가치를 만들지, 누가 결과를 책임질지, 더 큰 자율성을 허용할 증거가 무엇인지 정해야 한다. 제품의 온보딩과 조직의 거버넌스는 결국 같은 질문을 다룬다. AI가 어디까지 준비하고, 어느 지점에서 인간이 판단하며, 실패하면 누가 멈출 것인가.

1. 01

   출시 기준은 평균 점수가 아니다

   Muse 팀의 평가표에서 행동의 80%가 초록색이어도 20%가 빨간색이면 충분하지 않았다. 평균이 좋아 보여도 사용자가 우연히 실패 항목을 만나는 순간 전체 신뢰가 무너질 수 있기 때문이다. 팀은 행동별 평가와 함께 처음 쓰는 사람이 무엇을 부탁하고, 결과를 본 뒤 다음 일을 맡기는지도 관찰했다. 출시 기준은 기능 개수보다 치명적인 실패가 줄었는지, 작은 성공이 다음 사용으로 이어지는지에 가까웠다.

2. 02

   첫 경험은 기능 안내가 아니라 신뢰 실험이다

   사용자는 처음부터 큰 권한을 넘기지 않는다. 작은 일을 맡기고 결과를 확인한 뒤 조금 더 복잡한 부탁으로 이동한다. 그래서 제품팀은 첫 화면에서 가능한 일을 많이 나열하기보다 성공 가능성이 높은 첫 행동을 고르게 하고, 결과와 다음 단계를 분명히 보여줘야 한다. 이메일이나 구매 전 승인은 편의를 늦추는 장벽이 아니라 사용자가 통제권을 잃지 않은 채 신뢰의 사다리를 오르게 하는 장치다.

3. 03

   사람의 결정선과 기록을 먼저 고정한다

   기업 업무에서는 에이전트가 분석을 준비하는 일과 사람이 결정을 소유하는 일을 분리해야 한다. 인수 통합 사례에서 보고서 작성이 빨라져도 수치의 의미를 판단하고, 현금 부족을 시정하고, 위험 상태를 선언하는 권한은 서로 다른 인간 역할에 남는다. 원시 데이터, 사용한 도구, 프롬프트와 모델 버전, 생성 결과, 인간 승인을 남겨야 결과를 다시 구성할 수 있다. 책임자가 없는 결정은 자동화 대상에서 빼는 편이 안전하다.

4. 04

   자율성은 성과와 통제 증거로 승급한다

   자율성은 선언이 아니라 단계별 허가다. 먼저 기존 업무 옆에서 결과를 비교하고, 다음에는 사람이 모든 항목을 검토하며, 이후 예외와 무작위 표본을 함께 확인하고, 마지막에 고위험 예외 중심으로 검토 범위를 줄인다. 이때도 독립 표본검사를 남겨야 에이전트가 놓친 문제를 찾을 수 있다. 오버라이드가 줄었다는 사실만으로 성능 향상을 단정할 수 없는 이유는 검토가 느슨해졌을 가능성도 있기 때문이다.

도입 순서는 분명하다. 먼저 맡길 행동을 이름 붙이고 성공과 실패를 관찰한다. 외부에 영향을 주는 순간의 승인과 중단 권한을 남긴다. 그다음 속도나 절약된 시간 같은 가치 지표와 누락·오류·인간 수정 같은 통제 지표를 함께 본다. 이 증거가 쌓일 때만 더 큰 일을 맡긴다. AI가 사람을 대신한다는 문장보다 중요한 것은 사람이 어떤 판단을 계속 소유하고, 제품과 조직이 그 경계를 사용자에게 얼마나 이해 가능하게 보여주는가다. 신뢰는 한 번의 데모가 아니라 권한을 천천히 넓혀도 된다는 반복 가능한 증거다.

AI로 맞춤 소프트웨어를 빠르게 만들 수 있을 때 조직은 무엇을 근거로 임대와 직접 소유 사이를 선택해야 하는가?

AI Engineer의 행사 운영팀은 네 행사에 연 4만3천 달러를 요구하면서 기능 요청에는 3~6개월 또는 그 이상이 걸리던 SaaS를 직접 대체하는 실험을 열었다. 72개 팀이 결과물을 냈고 다섯 앱이 실제 도입 검토 수준에 도달했다. 이 사례는 도메인 팀이 필요를 말하고 제작 도구가 빠르게 구현하는 새 가능성을 보여준다. 동시에 기능을 만드는 속도가 제품을 운영할 능력과 같지 않다는 사실도 드러냈다. 자동 평가 상위 10개 중 6개는 실제 행사팀에게 약한 제품이었고, 최종 우승작은 자동 평가 19위였다. 복수 사용자 공간, 일정 충돌, 데이터 연결, 장애 대응처럼 업무가 실제로 흘러갈 때만 보이는 결함이 있었기 때문이다. 구매와 직접 구축의 비교도 구독료와 모델 사용료만 나란히 놓아서는 부족하다. 자동화 비율이 어디까지의 일을 뜻하는지, 사람이 검토하고 다시 하는 시간은 얼마인지, 유효한 결과 한 건을 만드는 총비용은 얼마인지 확인해야 한다. 만들기 쉬워질수록 결정의 중심은 제작에서 운영으로 이동한다.

1. 01

   기능 요청 6개월을 몇 분으로 바꾼 실험

   기성 행사 소프트웨어는 실제 사용 기능이 일부뿐이어도 묶음 가격을 받았고, 변경 요청은 3~6개월 뒤나 무기한으로 밀렸다. 공개 도전에서는 제품 설명, 사용 영상, 화면 자료를 바탕으로 72개 팀이 대안을 만들었다. 비기술 행사팀은 어떤 모델과 기술을 썼는지가 아니라 실제로 구매해 쓸 수 있는지를 판단했다. 직접 구축의 장점은 기능 수가 아니라 업무를 아는 사람이 수정 주기와 우선순위를 되찾는 데 있었다.

2. 02

   자동 점수보다 운영팀의 손이 먼저 찾은 것

   자동 평가는 20개 정상 사용 흐름을 돌려 초기 결함을 찾고 빠르게 개선하는 데 유용했다. 그러나 상위 점수와 운영팀의 선택은 크게 달랐다. 행사팀은 하나의 입력 화면과 지속적으로 상태를 관리하는 사용자 공간의 차이, 일정 이동이 저장됐는지 보여주는 상태, 초대 발표자를 별도 절차로 추가하는 흐름을 직접 만지며 발견했다. 다른 자료에서도 자동 채점과 실제 병합 결정 사이에 24%포인트 차이가 나타났다. 자동 통과는 최종 사용자의 수용을 대신하지 않는다.

3. 03

   자동화율을 묻기 전에 끝나는 지점을 정한다

   ‘70% 자동화’는 초안 작성, 사람의 수정, 사람의 승인, 사람 개입 없는 완료 가운데 무엇을 셌는지에 따라 전혀 다른 말이 된다. 업무의 끝을 초안, 승인, 실제 운영 반영 중 어디로 볼지 먼저 정해야 한다. 처리량이 늘면서 검토와 재작업 노동도 함께 커졌다면 노동을 없앤 것이 아니라 보조한 것일 수 있다. 공급사나 내부팀의 숫자를 볼 때는 업무량과 완전부하 인건비를 같은 기간에 놓고, 검토·에스컬레이션·재작업까지 비용에 포함해야 한다.

4. 04

   토큰보다 큰 비용과 더 중요한 분모

   한 관찰에서는 AI 지출이 60배 늘어난 동안 엔지니어 한 명당 병합된 변경 제안이 43% 늘었고, 급여와 AI 비용을 합친 변경 제안 한 건당 비용은 26% 낮아졌다. 하지만 이는 AI가 증가분을 만들었다는 인과관계나 현금 절감을 증명하지 않는다. 결과물 개수도 고객 가치와 같지 않다. 급여, 모델과 도구 비용을 합치고 작업 크기, 검토 부담, 되돌림, 결함, 고객 영향을 함께 보아야 추가 지출이 유효한 산출로 바뀌었는지 판단할 수 있다.

5. 05

   소유는 장애가 난 뒤에도 계속된다

   직접 만든 제품은 기능 요청을 빠르게 반영할 수 있지만 새벽 장애, 데이터 불일치, 사용자 지원도 함께 소유한다. 행사 운영 사례에서는 업로드가 성공해도 공개 화면이 다른 저장 위치를 읽거나, 후원사가 표를 해제하지 못하는 문제가 나왔다. 사용자는 구현 방법보다 다시 깨지지 않는 결과를 원한다. 따라서 직접 구축의 경제성에는 유지보수 인력과 검토 시간, 장기 테스트와 운영 부담을 넣고, 절감액이 실제 사용자 경험을 개선하는 데 다시 쓰이는지도 확인해야 한다.

이제 맞춤 소프트웨어를 만드는 문턱은 낮아졌지만, 구매 결정의 기준은 더 엄격해져야 한다. 임대하면 느린 변경과 불필요한 묶음을 감수할 수 있고, 직접 소유하면 빠른 수정과 도메인 적합성을 얻는 대신 장애와 품질의 최종 책임을 떠안는다. 어느 쪽이든 자동화라는 큰 숫자나 싼 토큰만 보지 말고, 실제 사용자가 받아들인 결과 한 건의 총비용과 실패 뒤의 복구 능력을 비교해야 한다. 직접 만들 수 있다는 사실은 출발 허가일 뿐이다. 계속 운영할 사람, 독립적으로 품질을 확인할 절차, 고객에게 책임을 돌리지 않을 대응 체계가 있을 때 비로소 소유가 더 나은 선택이 된다.