도구를 다 깔았는데 왜 그대로인가
블록(Block)은 결제 서비스 스퀘어(Square)를 만든 핀테크 기업이다. 이 회사는 개발자 대부분에게 AI 코딩 도구를 쥐여줬다. 규모가 3,500명이고, 교육도 전사 단위로 돌렸다. 도구 활용도만 놓고 보면 업계 최상위권에 해당한다.
그런데 제품이 출시되는 흐름은 기대만큼 빨라지지 않았다. 코드는 분명 더 빨리 나왔는데 제품이 그만큼 빨리 바뀌지 않았다. 도구를 안 써서가 아니었다. 개발자가 AI가 쓴 코드를 어디까지 믿고 그대로 내보낼 것인지에 대한 심리적 허들이 있었고, 그 위에 결재와 승인이라는 절차가 얹혀 있었다.
결국 이 회사가 택한 방법은 3,500명 전원을 더 교육하는 것이 아니었다. 챔피언 50명을 뽑아 그들이 먼저 실제로 된다는 것을 성과로 만들어 보이게 하고, 그 문화가 옆으로 퍼지게 했다. 도구 보급률은 이미 100%에 가까웠으니 남은 변수는 도구가 아니라 사람과 절차였다는 뜻이다.
고속도로를 한 구간 뚫어 놓으면 차가 알아서 다닐 것 같지만 그렇지 않다. 고속도로는 이미 있는데 아무도 그 길로 들어서지 않는 상황, 그것이 실제 병목이다. 조직에 AI 교육을 돌리고도 일이 두 배로 빨라진 경험이 없다면 대개 여기에 걸려 있다.
앤트로픽은 5~6개월을 1~3일로 어떻게 줄였나
같은 문제를 앤트로픽은 반대쪽에서 건드렸다. 이 회사도 원래는 제품을 만들어 출시하기까지 5~6개월이 걸렸다. 지금은 그 주기가 1~3일이다. 개월이 아니라 일 단위다.
방법은 도구를 더 좋은 것으로 바꾸는 것이 아니라 공개하는 단위를 새로 만드는 것이었다. 리서치 프리뷰(Research Preview)가 그것이다. 아직 개발·연구 단계인 기능을 완성될 때까지 감춰 두지 않고, 원하는 사용자가 미리 켜서 써 볼 수 있는 자리에 올려 두는 방식이다. 클로드 데스크톱 앱을 열면 채팅과 코드 탭이 나뉘고 채팅 안에 협업 기능이 들어오는 식으로 화면 구성이 계속 바뀌는데, 그 변화가 이 단위 위에서 돌아간다.
이 단위가 실제로 걷어낸 것은 완성도가 아니라 대기 시간이다. 무엇을 내보낼지 매번 위로 올려 승인을 받고, 다 갖춰질 때까지 기다리는 구간이 사라졌다. 완벽을 기다리는 대신 작게 먼저 공개하고 사용자의 반응으로 배우는 환경을 만든 것이다.
여기서 오해하기 쉬운 지점이 있다. 1~3일이 가능한 이유가 AI로 코딩하기 때문이라고만 보면 절반만 본 것이다. 코딩 속도는 원래도 높았을 것이다. 그것이 급진적인 성과로 바뀐 계기는 판단과 승인의 구조를 다시 설계한 데 있었다. 도구가 만든 속도를 조직이 흘려보낼 수 있도록 파이프를 새로 깐 셈이다.
파레토로 다시 읽기: 80을 100으로 올리는 비용
파레토 법칙은 결과의 80%가 원인의 20%에서 나온다는 경험칙이다. 2대 8 법칙이라고도 부른다. 매출의 80%를 상위 20% 고객이 만든다는 식으로 흔히 쓰인다.
이것을 제품 개발 일정에 대입하면 이렇게 된다. 사람들이 실제로 쓰는 핵심 기능 80%는 전체 개발 기간의 20%면 만들어진다. 그리고 나머지 기간 80%는 그 80을 100으로 끌어올리는 데 쓰인다. 예외 처리, 화면 다듬기, 드문 케이스 대응, 내부 검토와 승인이 이 구간에 들어간다.
핵심 질문은 여기서 나온다. 그 마지막 완성도를 시장이 원한 적이 있는가. 대부분의 프로젝트에서 이 질문은 검증된 적이 없다. 아무도 요구하지 않은 정교함에 기간의 80%를 쓰고, 정작 시장이 원한 다른 20%는 손도 대지 못한 채 출시하는 일이 반복된다.
그래서 순서를 바꾼다. 80%에서 먼저 내보내고, 남은 20%는 시장 반응이 정하게 둔다. 쓰이는 곳은 채우고, 아무도 쓰지 않는 곳은 버린다. 그러면 첫 출시까지 걸리는 기간이 전체의 20%, 즉 5분의 1로 줄어든다. 앤트로픽이 리서치 프리뷰로 한 일이 정확히 이 구조다.
이 방식이 품질을 포기하는 것으로 들린다면 순서를 다시 보면 된다. 100%를 포기하는 것이 아니라, 어느 20%를 100으로 올릴지를 내 추측이 아니라 사용자의 사용 기록으로 고르는 것이다. 완성도의 총량이 아니라 완성도의 배분을 바꾸는 결정이다.
그럼 80%는 어디서 끊는가
80%라는 숫자를 감으로 재면 매번 달라진다. 실무에서 쓸 만한 정의는 이것이다. 핵심 사용자 흐름 하나가 처음부터 끝까지 도는 상태. 요청이 들어와서 결과가 나가고 기록이 남는 한 줄기가 끊기지 않고 굴러가면 80%다. 그 줄기 옆에 붙는 예외 처리, 두 번째 사용자 유형, 관리 화면은 아직 20%에 속한다.
처음 만들 때는 범위를 이렇게 묶는다. 업무는 한 종류만 넣는다. 사용자는 나 혼자 또는 우리 팀만으로 한정한다. 핵심 기능은 한두 개만 남긴다. 데이터는 샘플이나 비식별 데이터로 시작한다. 결과는 반드시 사람이 최종 검수한다. 문제가 생기면 언제든 기존 방식으로 되돌아갈 수 있게 해 둔다.
이 범위보다 커지려고 하면 줄인다. 이왕 만드는 김에 이것도 넣자는 생각이 실패의 씨앗이다. 범위가 커질수록 첫 출시가 뒤로 밀리고, 첫 출시가 밀리면 시장 반응이 도착하기 전에 나머지 20%를 내 추측으로 채우게 된다. 그 순간 A안으로 되돌아간 것이다.
만드는 방법은 이제 큰 장벽이 아니다. 말로 설명하면 AI가 코드를 만들어 주는 시대라, 코딩을 깊이 몰라도 작은 해결책 하나는 직접 만들어 볼 수 있다. 중요한 것은 어떻게 만드느냐가 아니라 무엇을 시험할 것인가다. 코딩부터 배우고 시작할 필요는 없다.
측정하지 않으면 80인지 100인지도 모른다
80%에서 내보내는 방식은 측정을 전제로 한다. 반응을 읽어서 나머지를 정하겠다고 해 놓고 아무것도 재지 않으면, 좋아진 것 같은 느낌만 남는다. 내가 만든 것이라 애착이 붙으면 이 착시는 더 심해진다.
재야 할 숫자는 정해져 있다. 작업 시간, 대기 시간, 오류와 누락 건수, 수정 횟수, 그리고 사용자가 실제로 다시 썼는지 여부다. 이전 방식의 숫자와 나란히 놓고 비교한다. 초안 작성이 40분에서 15분으로, 수정 요청이 세 번에서 한 번으로 줄었다는 식으로 확인되어야 한다.
어디를 재야 할지 모르겠다면 병목 신호 다섯 가지를 먼저 본다. 결재나 회신을 기다리며 일이 멈추는 대기, 같은 자료를 매주 다시 만드는 재작업, 특정 담당자가 자리를 비우면 아무도 못 하는 담당자 의존, 메신저에서 복사해 엑셀에 붙이는 시스템 단절, 정상 케이스보다 예외가 더 많아지는 예외 폭증이다. 이 중 하나에 손이 올라간다면 그곳이 첫 대상이다.
숫자가 오히려 나빠졌을 수도 있다. 그러면 고친다. 고쳐도 안 좋아지면 버린다. 다른 방식으로 다시 설계하고 진단도 다시 하면 된다. 못 버리는 것이 더 큰 낭비다. 앤트로픽의 출시 주기가 1~3일인 이유도 결국 이것이다. 써 보고 안 쓰이면 버릴 수 있으니 짧게 돌릴 수 있는 것이다.
완성 기준을 누가 정하고 있는가
블록의 사례가 알려 주는 것은 조직의 속도가 도구 목록이 아니라 결정 구조에서 나온다는 사실이다. 그래서 점검할 질문은 어떤 AI를 쓰고 있느냐가 아니라, 이 일이 끝났다고 누가 언제 선언하느냐다.
실무에서는 결정을 두 종류로 나누면 정리가 된다. 되돌릴 수 있는 결정은 승인 없이 그냥 내보낸다. 화면 문구, 내부 도구, 시험용 기능처럼 잘못되면 되돌리면 그만인 것들이다. 되돌릴 수 없는 결정은 사람이 승인한다. 고객에게 나가는 발송, 결재, 기록 삭제, 인사와 평가, 기밀과 개인정보가 여기에 해당한다.
이 선을 미리 그어 두면 대기 시간의 대부분이 사라진다. 승인 대기는 대개 되돌릴 수 있는 일까지 전부 위로 올려 보내면서 생긴다. 앤트로픽의 리서치 프리뷰도 결국 되돌릴 수 있는 공개를 승인 절차 밖으로 꺼낸 장치다.
개인 단위에서도 같다. AI에게 일을 맡길 때 무엇을 스스로 처리하게 두고 무엇을 반드시 내가 승인할지 미리 정해 두면, 매번 멈춰 서서 판단하지 않아도 된다. 잘하는 AI보다 멈출 곳을 아는 AI가 실무에서 더 오래 간다.
오늘 할 수 있는 것
지금 진행 중인 일 하나를 골라 문장 하나로 적어 본다. 나는 어떤 업무의 어떤 병목을 어떤 방법으로 바꿔 측정 가능한 결과를 만든다. 네 칸이 다 채워져야 과제다. 우리 팀도 AI를 적극 활용하겠다는 문장은 다짐이지 과제가 아니다.
예를 들면 이렇게 된다. 나는 주간보고 취합 과정의 누락 확인과 반복 수정을 줄이기 위해, 필수 항목 입력과 검수 기준을 포함한 취합 도구를 만들고, 작성 시간과 수정 횟수를 이전 방식과 비교한다.
그다음 그 과제의 80%가 어디까지인지 한 줄로 정한다. 핵심 흐름 하나가 끝까지 도는 지점을 적고, 그 지점에서 실제로 내보낸다. 그리고 최소 일주일은 실제 업무에 쓰면서 숫자를 모은다.
남은 20%는 그때 정하면 된다. 일주일치 사용 기록이 어디를 채워야 할지 알려 준다. 그것이 내 추측보다 정확하고, 무엇보다 기간의 80%를 미리 쓰지 않아도 된다.