10월 25일 일요일

AI 중심 재설계는 제품과 업무의 판단·절차·책임을 어떻게 바꾸는가?

오늘의 자료는 AI를 발전소·전력망·가전제품에 비유하며 모델, 인프라, 프로토콜, 에이전트의 관계를 설명하고, 제품·업무·조직을 AI 중심으로 다시 설계하는 원칙과 사례를 407쪽 핸드북에 담았다고 전한다. 이 비유에서 업무 독자가 먼저 볼 것은 기술 이름이 아니라 역할의 분리다. 전기를 쓰는 사람이 발전소를 직접 운영하지 않듯, 모든 구성원이 AI의 내부 작동을 알아야 하는 것은 아니다. 그러나 어떤 힘을 어디에 연결하고, 누가 사용 조건을 정하며, 이상이 생겼을 때 누가 차단하고 복구할지는 정해져 있어야 한다. 따라서 AI 중심이라는 말은 기존 절차 끝에 자동 생성 버튼을 붙이는 것보다 넓다. 일이 들어오는 순간부터 필요한 자료를 모으고, 초안을 만들고, 사람이 확인하고, 고객에게 전달하고, 결과를 기록하는 흐름 전체에서 기계와 사람의 몫을 다시 나누는 일에 가깝다. 여기서 중요한 변화는 속도 자체보다 판단의 위치다. 사람이 매 단계 직접 처리하던 조직은 무엇을 맡길지 결정해야 하고, 이미 자동화를 쓰는 조직은 언제 사람이 다시 들어와야 하는지 정해야 한다. 제품팀도 AI 기능의 수보다 사용자가 결과를 믿고 수정하고 거절할 수 있는 경험을 먼저 설계해야 한다. 다만 자료는 핸드북의 개별 사례나 성과 수치를 풀어놓지 않는다. 그러므로 AI 중심 재설계가 언제나 더 낫다고 단정할 수는 없고, 오늘 확인할 수 있는 것은 재설계의 질문과 이를 둘러싼 운영 조건이다. 주변 사례는 재설계가 화면 위 기능만의 일이 아님을 보탠다. 비정상 종료된 헤드리스 Chrome의 앱 복제본 37,856개가 쌓여 macOS 부팅이 최대 40분 동안 5%에서 멈춘 사례는 자동화가 남기는 부산물도 운영 대상임을 보여준다. 반면 Claude Code 옆 TODO 패널은 작업 중 생긴 할 일을 세션 너머 보존하고 전역·프로젝트별 목록으로 관리한다. 하나는 자동화가 누적시킨 부담이고, 다른 하나는 사람이 다음 세션에서 판단을 이어가도록 맥락을 남기는 장치다. AI 중심 업무에서도 결과만 볼 것이 아니라, 실행 뒤 무엇이 남는지와 다음 사람이 어디서 이어받는지를 설계해야 한다. 삭제·정리·보존 기준, 비정상 종료 뒤 복구 절차가 없으면 자동화가 오히려 다음 업무의 지연으로 돌아올 수 있다. 다만 사례 자체가 AI 조직의 성과를 입증하는 것은 아니다. 재설계 범위를 산출물에서 운영의 잔여물과 연속성까지 넓혀 보라는 신호로 읽는 편이 안전하다.

1. 01

   출발점을 기능이 아니라 업무로 옮기기

   AI를 먼저 고르고 쓸 곳을 찾으면 도입의 성공 기준이 기능 사용량으로 좁아지기 쉽다. 반대로 제품·업무·조직을 함께 다시 설계한다는 관점은 일이 시작되는 이유와 끝났다고 판단하는 조건부터 묻게 한다. 어떤 입력이 필요하고, 어떤 중간 결과를 사람이 검토하며, 최종 결정은 누가 내리는지를 먼저 그린 뒤 AI가 맡을 구간을 정하는 방식이다. 이때 자동화하지 않는 구간도 명시적인 선택이 된다. 고객에게 설명해야 하는 판단, 되돌리기 어려운 승인, 자료가 부족한 예외처럼 사람의 책임이 남아야 할 지점을 제품 흐름 안에 보이게 해야 한다. AI 도입안은 그래서 기능 목록보다 업무의 전후 관계와 책임자를 보여주는 문서에 가까워져야 한다.

2. 02

   추천을 결정으로 착각하지 않기

   자료에 소개된 서비스는 뉴스·연구·특허·기업 공시·고객 불만에서 사업 기회를 찾고, 창업 비용과 경쟁 위험, 시장 진입 기간, 첫 90일 실행 계획을 개인 조건에 맞춰 제안한다. 이는 AI가 정보 수집과 선택지 정리, 실행 순서 제안까지 넓어질 수 있음을 보여준다. 동시에 제안이 곧 결정은 아니라는 경계도 만든다. 비용과 위험을 어떤 기준으로 비교할지, 개인 조건이 제대로 반영됐는지, 계획을 중단하거나 바꿀 신호는 무엇인지는 사용자가 판단해야 한다. 제품은 결과를 단정적으로 내놓는 대신 근거가 된 조건과 바꿀 수 있는 가정을 드러내야 하고, 조직은 추천을 승인하는 사람과 실행 결과를 되돌아보는 사람을 분리하지 말아야 한다.

3. 03

   검증을 마지막 관문이 아니라 일의 일부로 만들기

   데이터 분석의 질문 설정부터 수집·가공, 통계, 시각화, 결론 전달까지 누락값, 잘못된 결합, 생존자 편향 같은 오류를 찾고 근거와 수정 방법을 제시하는 도구가 함께 소개됐다. AI가 초안과 분석을 빠르게 만들수록 검증은 마지막에 한 번 확인하는 절차로는 부족해진다. 입력이 적절했는지, 가공 과정에서 의미가 달라지지 않았는지, 결론이 자료보다 강하지 않은지를 각 단계에서 확인해야 한다. 이 원칙은 사람의 역할을 단순 승인자로 줄이지 않는다. 오히려 질문을 바로 세우고 오류 유형을 알아보며 수정 이유를 남기는 쪽으로 옮긴다. 조직은 산출량만 세기보다 어느 단계에서 어떤 오류를 발견했고 어떻게 고쳤는지를 운영 기록으로 다뤄야 한다.

4. 04

   신뢰를 선언이 아니라 반복되는 운영으로 보기

   Cloudflare의 한국 ISMS 인증 소식은 80개 통제 항목 심사, 국내 가입 흐름의 필수 동의와 자체 가입 양식, 3년 인증 기간 중 매년 유지 감사를 함께 전한다. 다른 소식에서는 보안 점검과 패치로 서비스 재개가 연기됐고, 운영사는 로그 확인 결과 실제 피해가 없었다고 밝혔다. 두 사례가 보여주는 것은 신뢰가 출시 시점의 문구로 끝나지 않는다는 점이다. AI를 제품과 업무의 중심에 둘수록 동의 절차, 점검 항목, 기록 확인, 정기 감사, 문제가 생겼을 때 일정을 미루는 판단까지 평상시 운영에 포함해야 한다. 빠른 출시와 자동화 범위 확대만 목표로 삼으면 이런 책임은 사고 뒤의 대응으로 밀린다. 책임 있는 재설계는 누가 멈출 수 있는지도 미리 정한다.

AI 중심 재설계의 실무 질문은 세 가지로 모인다. 첫째, 지금의 업무 흐름에서 기계가 맡을 부분과 사람이 끝까지 책임질 부분은 어디인가. 둘째, AI의 추천을 사용자가 검토·수정·거절할 수 있도록 제품이 어떤 조건과 근거를 보여줘야 하는가. 셋째, 오류와 보안 문제를 출시 뒤에 처리하지 않도록 어떤 점검과 기록을 반복할 것인가. 오늘 자료는 특정 조직의 정답이나 성과를 제시하지 않으므로, 전면 전환을 서두를 근거는 아니다. 대신 작은 업무 하나를 골라 입력, 초안, 검토, 승인, 전달, 사후 확인의 순서를 그리고 각 단계의 책임자와 중단 조건을 적어보는 출발점을 준다. AI가 일을 대신하는 범위보다 사람이 판단을 회수할 수 있는 경계가 먼저 선명해야 한다. 그 경계가 제품 경험과 조직 운영에 동시에 반영될 때에만 AI 중심이라는 구호가 실제 일의 방식으로 바뀐다.