품질을 떨어뜨리지 않고 AI로 두 배 빠르게 일하는 법

"두 배 빠르다"를 비즈니스 기준으로 정의하기

직원이 초안을 60분이 아니라 15분 만에 썼더라도 데이터가 틀려서 세 번을 더 고쳐야 했다면, 그 일은 조금도 빨라지지 않았습니다. 시간을 잴 구간은 일을 받은 순간부터 고객이 결과물을 받을 때까지이고, 자리에 앉아 입력하는 시간은 그중 일부일 뿐입니다.

많은 팀이 AI가 몇 초 만에 글을 만들어 내니 아주 빠르다고 느낍니다. 하지만 그 뒤에 사실관계를 확인하고, 어조를 고치고, 맞는 파일을 찾고, 승인을 여러 번 받느라 시간을 잃을 수 있습니다. 초안 작성 시간만 재면 회사는 실제로는 없는 성과를 보게 됩니다. 요청을 받은 때부터 받는 사람이 결과를 받아들일 때까지의 리드 타임(Lead Time)을 재고, 여기에 대기 시간, 수정 작업, 반려되어 돌아온 작업을 모두 넣으십시오.

먼저 작업 단위를 분명히 정하십시오. "승인된 견적서", "팀장이 의사결정에 쓸 수 있는 보고서", "고객 문의를 종결한 답변" 같은 식입니다. 그다음 적어도 20~30건으로 기준선(Baseline)을 잡고 쉬운 건, 보통 건, 어려운 건으로 나누십시오. AI는 표준적인 건에는 강하지만, 예외 건의 처리 시간까지 같은 비율로 줄여 주지는 못하기 때문입니다.

사라진 시간이 어디로 갔는지 찾기

다섯 단계 작업 라인 설계하기: Frame, Gather, Create, Check, Act

업무 한 건을 과제 이해, 정보 수집, 작업, 검토, 전달로 이어지는 컨베이어 벨트로 생각해 보십시오. AI가 큰 도움이 되는 단계가 있고, 전혀 도움이 안 되는 단계도 있습니다. 어느 단계가 어느 쪽인지 알아야 실제로 빨라집니다.

Frame 단계에서 과제를 좁혀 받는 사람, 목표, 범위, 완료 기준(Definition of Done)을 정하고, Gather 단계에서 믿을 수 있는 출처의 데이터를 가져옵니다. Create 단계에서는 AI가 요약하거나, 선택지를 만들거나, 초안을 씁니다. Check 단계의 검토 기준은 규칙, 근거, 그리고 권한을 가진 사람의 판단입니다. Act 단계에서 결과를 보내거나, 시스템을 업데이트하거나, 다음 업무를 엽니다. 단계를 다섯으로 나눠 두면 "AI 답변이 별로"라고 뭉뚱그리지 않고 문제가 어디서 생기는지 짚을 수 있습니다.

수정 횟수를 줄이는 브리프

브리프는 일곱 가지 질문에 답해야 합니다. 어떤 결과가 필요한지, 누가 쓰는지, 그 사람이 이미 아는 것은 무엇인지, 입력 자료는 어디서 오는지, 금지 사항은 무엇인지, 어떤 형식으로 넘겨야 하는지, 합격 기준은 무엇인지입니다. 잘된 예시 하나와 통과하지 못한 예시 하나도 붙이십시오. 프롬프트에 형용사를 잔뜩 붙이는 것보다 이렇게 분명히 적는 편이 효과가 훨씬 큽니다.

중요한 정보를 AI가 짐작하게 두지 마십시오. 출처 자료가 부족하면 "멈추고 자료를 요청하라"고 지시하고, 숫자가 정확해야 하면 모델 밖의 공식이나 계산 시스템을 쓰십시오. 정책을 인용해야 한다면 버전과 날짜를 붙입니다. 이런 제약을 워크플로에 넣어 두면 안전이 사용자 한 사람 한 사람의 기억력에 기대지 않게 됩니다.

뒷단에 부담을 넘기지 않고 속도를 높인 예

영업팀: Meeting-to-Proposal

운영팀: Ticket-to-Resolution

AI가 티켓을 읽고 유형을 분류한 뒤 이력을 불러오고, 지식 베이스에서 점검 절차를 추천합니다. 신뢰도(Confidence)가 낮거나 위험한 표현이 보이면 시스템이 곧바로 선임 담당자에게 넘깁니다. 표준적인 건은 더 빨리 답변을 받고, 전문가는 예외 건만 맥락과 함께 봅니다. 그래서 팀은 안전을 희생하지 않고도 처리 용량을 늘릴 수 있습니다. 처리 완료까지 걸린 시간, 1차 해결률(First-contact Resolution), 다시 열린 건수를 재십시오.

관리자: Data-to-Decision

AI에게 보고서를 처음부터 쓰게 하는 대신, 정의가 고정된 KPI를 시스템이 가져와 변화를 짚고 질문을 만들게 하십시오. 관리자는 현장에서 원인을 확인하고, 결정을 내리고, 그 결정의 가정을 기록합니다. 다음 주기에 시스템은 실제 결과를 예상과 비교합니다. 이렇게 하면 서식을 다듬는 시간은 줄고 생각할 시간은 늘어나며, 의사결정은 모델에 넘어가지 않습니다.

시범 적용할 때는 같은 기간에 AI를 쓴 작업과 기존 방식의 작업을 무작위로 배정하십시오. 그래야 계절, 업무량, 사람 사이의 실력 차이가 결과에 끼어들지 않습니다. 일반적인 작업은 중앙값(Median)을, 오래 걸리는 건은 P90을 재십시오. 고객은 평균보다 유난히 느린 건을 더 크게 체감하기 때문입니다.

개인의 성공을 팀의 표준으로 만들기

스스로를 속이지 않는 대시보드

중단 규칙(Stop Rule)을 미리 정해 두십시오. 예를 들어 오류가 2주 동안 기준을 넘으면 초안 모드로 돌아갑니다. 검토 시간이 절약한 시간보다 길면 브리프를 고치거나 그 활용 사례(Use Case)를 중단합니다. 팀이 쓰지 않는다면 원인이 UX인지, 신뢰 부족인지, 실제 업무와 맞지 않아서인지, KPI끼리 충돌해서인지 확인하십시오. 모든 문제를 교육을 더 하는 것으로 풀려고 하지 마십시오.

두 배 빨라지는 효과가 AI에서만 나오지는 않습니다. 아무도 읽지 않는 보고서를 없애거나, 승인자 수를 줄이거나, 공용 데이터를 바로잡는 일이 AI보다 효과가 클 때도 있습니다. 큰 효과를 보는 회사는 AI를 업무를 새로 설계하는 과정의 일부로 보고, 기존 프로세스 위에 덧붙이는 별도의 층으로 다루지 않습니다.

TECHNIQUE · 대충 하지 않고 빠르게

Two-pass 방식: 첫 번째는 넓게 찾고, 두 번째는 정확하게 좁히기

AI에게 한 번에 최종 답을 만들게 하려고 하지 마십시오. 첫 번째 단계에서는 과제를 쪼개고, 빠진 정보를 짚고, 접근 방식 3가지를 제안하게 합니다. 사람이 방향을 고르고 사실을 채워 넣은 다음에야 두 번째 단계에서 템플릿과 체크리스트에 맞춰 결과물을 만들게 합니다. 단계가 하나 늘어난 것처럼 보이지만, 특히 제안서, 보고서, 여러 부서를 거쳐야 하는 콘텐츠에서는 뒷단의 수정을 크게 줄여 줍니다.

가상 사례: 한 영업팀은 제안서 하나를 만드는 데 90분을 썼고, 평균 두 번 수정을 거쳤습니다. Two-pass 방식을 쓴 뒤로는 내러티브를 고르는 데 15분, 시스템이 초안을 조립하는 데 25분, 가격과 범위를 확인하는 데 20분이 걸립니다. 전체 시간은 한 시간을 넘지 않습니다. 더 중요한 변화는 수정 횟수가 줄었다는 점인데, AI가 길게 쓰기 전에 사람이 방향을 먼저 정했기 때문입니다.

20-60-20 규칙

시간의 20%는 브리프 작성에, 60%는 AI와 사람이 함께 만드는 데, 나머지 20%는 검토하고 받는 사람에게 맞게 다듬는 데 쓰십시오. 검토 단계가 계속 20%를 넘는다면 입력 자료, 템플릿, 업무 범위 중 어딘가에 아직 문제가 있다는 뜻입니다. 검토자를 재촉해서 해결하려 하지 마십시오.

팁: 템플릿 이름은 "Proposal-SME-v3"처럼 결과물을 기준으로 붙이고, "제일 잘 먹힌 최신 프롬프트" 같은 이름은 피하십시오. 통과하지 못한 예시도 함께 보관하십시오. 틀린 예시가 긴 설명보다 범위를 더 분명하게 그어 줍니다.