10월 4일 일요일

AI가 업무를 처음부터 끝까지 맡는다면 사람과 조직은 무엇을 계속 책임져야 하는가?

조달 시스템에 남는 것은 흔히 최종 가격과 납기 같은 결과다. 그러나 그 결과를 만드는 동안에는 여러 부서의 회의, 공급업체와의 이메일, 원가 계산, 계약 조건, 배송 변경, 송장 불일치가 이어진다. 기존 소프트웨어가 이 마지막 기록을 저장하는 데 강했다면, AI 기반 업무 제품은 기록 밖에 흩어진 과정을 연결해 결과까지 책임지려 한다. 핵심은 대화창을 하나 더 붙이는 데 있지 않다. 요청을 이해하고, 내부 재고와 공급원을 찾고, 견적을 받아 비교하고, 협상 방식을 고르고, 주문 뒤 배송과 송장 예외까지 추적하는 흐름을 끊김 없이 다루는 데 있다. 이 변화는 조달 담당자를 없앤다는 선언보다 역할을 다시 나누라는 요구에 가깝다. 반복되는 정상 경로는 에이전트가 넓게 맡되, 회사의 원칙을 해석하거나 오래된 공급자 관계와 큰 손실 가능성을 함께 판단해야 하는 지점에는 사람이 남는다.

1. 01

   결과 한 줄 뒤의 노동

   ERP에 적힌 가격 한 줄은 업무의 결론일 뿐이다. 원문은 하나의 조달 결과 뒤에 이해관계자 회의와 수백 통의 이메일, 여러 계산표가 놓일 수 있다고 설명한다. 자동화 대상을 데이터 입력으로만 잡으면 이미 정리된 일부만 빨라진다. 조직이 먼저 그려야 할 것은 누가 어떤 정보를 모으고, 어느 예외에서 판단이 멈추며, 그 판단이 다음 부서와 시스템으로 어떻게 넘어가는지다.

2. 02

   정상 경로보다 어려운 예외

   문서를 읽어 시스템에 넣는 정상 송장 처리는 비교적 명확하다. 더 큰 비용은 사기 가능성, 납품과 문서의 불일치, 예기치 않은 변경처럼 규칙만으로 닫히지 않는 경우에서 생긴다. 원문은 정상 경로가 전체 문제의 일부에 불과하다고 지적한다. 따라서 도입 성과도 처리 건수만 보면 안 된다. 예외가 발견됐는지, 적절한 사람에게 전달됐는지, 해결 뒤 같은 맥락이 다음 거래에 남았는지를 함께 봐야 한다.

3. 03

   자율성은 거래마다 달라야 한다

   사람을 계속 둘 것인가, 완전히 맡길 것인가라는 양자택일은 실제 업무와 맞지 않는다. 과거에 아예 협상하지 못했던 작은 거래는 에이전트가 먼저 시도할 수 있지만, 금액이 크거나 기술 도면과 장기 관계가 얽힌 거래는 전문가가 승인해야 한다. 같은 금액이라도 실패의 영향과 관계의 중요도가 다르다. 그래서 자율화 정책은 직무 전체가 아니라 위험·복잡도·되돌릴 수 있는 정도에 따라 잘게 설계되어야 한다.

4. 04

   도입팀의 새로운 운영 과제

   시범 기능이 그럴듯하다는 사실과 운영 업무가 실제로 줄었다는 사실은 다르다. 결과의 상당 부분을 사람이 다시 전수 확인한다면 자동화율은 낮고 검토 작업만 추가될 수 있다. 고객 현장에 들어간 인력도 예외를 대신 처리하는 상시 컨설턴트로 남기보다, 반복되는 차이를 제품의 설정·평가·학습 루프로 바꿔야 한다. 내부 구축과 구매의 판단 기준 역시 첫 데모의 정확도가 아니라 통합, 권한, 예외, 유지보수까지 포함한 전체 책임 범위가 되어야 한다.

업무 중심 AI의 도입 순서는 분명하다. 먼저 시스템에 기록되지 않는 예외와 부서 간 인계를 찾고, 실패 비용에 따라 자동 실행·사람 승인·전문가 판단의 경계를 나눈다. 이어 처리량보다 예외 해결과 전수 재검토 감소를 측정하고, 작은 성공을 반복해 신뢰 범위를 넓힌다. 끝까지 자동화한다는 말은 사람을 없앤다는 뜻이 아니라, 사람이 반드시 판단해야 할 순간을 더 선명하게 만드는 일이어야 한다.

코드 생산이 인간의 검토 속도를 앞지른 팀은 신뢰와 책임을 어디에 배치해야 하는가?

AI를 켠 개발자의 코드 작성량이 크게 늘어도 실제 출시량은 그만큼 따라오지 않는다는 관찰은 병목이 옮겨갔음을 보여준다. 사람은 에이전트 여러 개가 만든 거대한 변경을 예전 방식으로 한 줄씩 읽을 수 없다. 그렇다고 테스트 통과만으로 병합과 배포를 결정할 수도 없다. 테스트는 이미 정의한 동작을 빠르게 확인하지만, 코드 바깥의 사용자와 오래된 운영 작업, 보안 위험, 유지보수성과 조직의 의도를 모두 알지는 못한다. 켄트 벡의 진단처럼 코드를 쌓는 속도가 신뢰를 쌓는 속도보다 빨라진 셈이다. 해법은 인간을 무조건 더 오래 붙잡아 두거나 완전히 빼는 데 있지 않다. 요구를 함께 정의하고, 좋은 변경의 기준을 명시하고, 자동 리뷰와 실제 운영 신호를 연결하며, 위험한 순간에 사람이 개입하는 다층 피드백을 만드는 데 있다.

1. 01

   생산량과 신뢰량을 분리해 보라

   원문에 소개된 추적 연구에서는 자율 에이전트를 켠 개발자의 코드 작성량이 741% 늘었지만 출시된 소프트웨어는 30% 증가하는 데 그쳤다. 숫자의 요지는 더 많은 코드가 곧 더 많은 고객 가치가 아니라는 데 있다. 팀이 생성 줄 수나 완료된 작업 수만 보상하면 검토 대기열과 숨은 위험을 키울 수 있다. 출시까지 걸린 시간, 되돌림, 운영 장애, 사람이 다시 확인한 비율처럼 신뢰를 만드는 비용을 함께 측정해야 한다.

2. 02

   테스트는 증거이지 판결이 아니다

   테스트와 컴파일러는 싸고 반복 가능한 검증 수단이라 AI 개발의 속도를 높였다. 하지만 통과한 변경이 실제 유지관리자의 병합 판단과 어긋나거나, 공개 동작은 맞아도 테스트가 묻지 않은 안전성 주장을 남길 수 있다. 사람의 역할은 테스트를 불신하는 것이 아니라 테스트가 무엇을 보지 못하는지 관리하는 일이다. 범위 일탈, 외부 사용처, 보안, 유지보수성, 실제 사용자 영향까지 서로 다른 검증 층을 겹쳐 한 층의 구멍이 곧 배포 실패가 되지 않게 해야 한다.

3. 03

   리뷰어에서 리뷰 시스템의 설계자로

   자동 리뷰는 이미 대규모로 쓰이고 다중 검토, 도구 호출, 수정 제안으로 확장되고 있다. 그러나 자동 리뷰어도 거짓 경고를 내고, 분석 대상의 문구에 속거나, 조직의 숨은 맥락을 놓칠 수 있다. 그래서 사람의 판단은 사라지지 않고 위로 이동한다. 어떤 변경을 좋은 것으로 볼지 기준표를 만들고, 리뷰어의 제안을 수락·거부한 이유를 남기고, 공격적 사례로 평가자를 다시 시험하며, 배포 뒤 실제 동작을 마지막 검토 층으로 연결하는 일이 새로운 리뷰 업무가 된다.

4. 04

   아무도 모를 때의 조직 방식

   AI 개발에는 아직 오래 검증된 단일 플레이북이 없다. 켄트 벡이 제안하는 출발점은 값싸고 되돌릴 수 있는 실험을 여러 방향으로 시도하고, 작동하는 방식을 발견한 뒤 집중하며, 반복 가능해진 다음에 표준화하는 것이다. 이때 실험 결과는 개인의 요령으로 남아서는 안 된다. 어떤 지침과 검증이 결과를 낫게 했는지, 어느 환경에서는 나빠졌는지를 팀이 공유해야 한다. 선임자의 가치는 과거 정답을 적용하는 데서 새 피드백 규칙을 만드는 데로 이동한다.

5. 05

   소통은 자동화 밖의 부가 업무가 아니다

   사용자가 요청한 기능을 곧바로 생성하는 것과 해결하려는 문제를 함께 정의하는 것은 다르다. 실제 시스템에는 규제, 다른 팀의 의존성, 운영 책임처럼 처음 요청에 드러나지 않은 조건이 있다. 개발자는 질문을 되묻고 가정을 드러내며 결과를 설명할 수 있어야 한다. 공감과 설득, 사고 뒤 책임 있는 학습은 코드 작성과 별개의 소프트 스킬이 아니라, 빠른 생성 결과를 조직이 믿고 사용할 수 있게 만드는 엔지니어링의 일부다.

팀이 바꿔야 할 질문은 ‘사람이 리뷰할 것인가’가 아니라 ‘어떤 위험을 어떤 증거로 확인하고, 누가 그 기준을 책임질 것인가’다. 반복 검사는 자동화하되 사람은 요구 정의, 검증 범위, 예외 승인, 운영 결과의 해석에 집중해야 한다. 그리고 아직 답이 굳지 않은 만큼 작은 실험을 기록하고 되돌릴 수 있어야 한다. 가장 많은 코드를 만든 팀보다 왜 이 변경을 신뢰했는지 설명할 수 있는 팀이 AI의 속도를 실제 성과로 바꿀 가능성이 크다.