77단계마지막 버튼은 사람이 누른다

걸리는 시간 · 읽기 약 10분 · 따라 하기 약 40분 · 난이도 ★★★ 심화

이 단계를 마치면

• 흐름에서 되돌릴 수 없는 단계를 찾아 그 앞에 승인 단계를 둘 수 있습니다.
• 승인하는 사람이 무엇을 보고 누르는지 알림 문구에 담을 수 있습니다.
• 승인이 형식으로 흐르지 않게 막는 장치를 만들 수 있습니다.

자동화가 잘 돌기 시작하면 마지막 단계까지 기계에 넘기고 싶어집니다. 초안이 대부분 맞는데 그냥 보내도 되지 않을까요? 여기서 멈춰야 합니다. 밖으로 나가는 일, 돈이 움직이는 일, 지우는 일은 틀렸을 때 되돌릴 수 없습니다. 그 앞에 사람이 누르는 버튼 하나를 둡니다.

왜 "대부분 맞는다"로는 안 되는가

손으로 하다 틀리는 것과 자동화가 틀리는 것은 무게가 다릅니다. 사람이 하루에 보내는 메일은 많지 않고, 틀린 한 통은 보낸 사람이 곧 알아챕니다. 자동화는 많이, 빠르게, 아무도 모르게 틀립니다. 가끔 틀리는 흐름도 한 달이면 여러 번 틀립니다. 그중 한 번이 금액이 잘못된 발주이거나 엉뚱한 사람에게 간 메일이라면, 그동안 아낀 품을 다 합쳐도 그 한 번을 수습하는 품보다 작을 수 있습니다.

승인 단계를 두면 느려지지 않느냐는 반론이 나옵니다. 맞습니다. 다만 느려지는 곳은 마지막 단계 하나뿐입니다. 요청서를 읽고, 초안을 쓰고, 받는 곳을 찾는 일은 여전히 기계가 합니다. 사람은 다 된 것을 보고 누르기만 합니다. 반대로 승인 단계가 없는 흐름은 사고가 한 번 나면 흐름 전체를 꺼야 합니다. 윗사람이 "그 자동화, 믿어도 되나?"라고 묻기 시작하면 다시 켜기 어렵습니다. 승인 단계는 속도를 조금 내주고 자동화를 오래 살리는 대가입니다.

어느 단계 앞에 두는가

모든 단계 앞에 승인을 두면 더는 자동화라 부르기 어렵습니다. 단계마다 세 가지를 차례로 묻습니다.

첫째, 이 단계의 결과가 팀 밖 사람에게 닿습니까. 고객이나 거래처에 가는 메일, 여러 부서가 보는 공지가 여기에 듭니다. 둘째, 돈이나 권리가 움직입니까. 결제, 발주, 환불, 계약서 발송, 권한 부여가 여기에 듭니다. 셋째, 틀렸을 때 원래대로 돌릴 수 있습니까. 시트에 행 하나를 더하는 일은 지우면 그만입니다. 하지만 원본 파일을 덮어쓰거나 지우는 일, 이미 보낸 메일은 돌이킬 수 없습니다.

하나라도 "그렇다"면 승인 단계를 둡니다. 셋 다 해당하지 않으면 승인 없이 흘려보내도 됩니다. 76단계의 시트 기록이 그런 경우입니다. 잘못 들어간 행은 사람이 나중에 고치면 됩니다.

흔한 오해가 하나 있습니다. 사내 채널에 올리는 일은 안에서 도는 일이니 괜찮다는 생각입니다. 받는 사람이 우리 팀 몇 명이라면 맞는 말입니다. 하지만 전 직원 채널이나 다른 부서 채널이라면 이미 밖으로 나간 것과 다름없습니다. 한번 읽힌 공지는 지워도 읽은 사람의 기억에 남습니다.

승인 단계의 모양

승인 단계는 거창할 필요가 없습니다. 사람이 결과를 보고 판단한 뒤에야 다음 단계가 움직이면 됩니다.

외부 자동화 도구에는 이런 대기·승인 단계를 만드는 기능이 있습니다. 도구마다 이름과 방식이 다르니 도움말에서 찾습니다. 어떤 방식이든 핵심은 하나입니다. 사람이 누르기 전에는 밖으로 아무것도 나가지 않습니다.

무엇을 보고 누르는지 적는다

승인이 형식이 되면 소용없습니다. 그래서 승인 단계에는 무엇을 보고 누르는지를 함께 적습니다. "수량과 단위를 원본 요청과 대조한다", "받는 사람 주소를 확인한다" 정도의 짧은 문장이면 됩니다. 초안을 만들 때 Claude에게 확인이 필요한 부분을 따로 표시하게 하면 사람이 볼 곳이 좁아집니다. 모든 것을 다 읽으라고 하면 결국 아무것도 읽지 않습니다.

알림 문구 두 가지를 나란히 놓아 봅시다.

• 느슨한 알림: "새 발주 초안이 있습니다. 승인해 주세요."
• 좁힌 알림: "발주 초안 1건. 확인할 것: 수량 120, 단위 박스(원 요청서: 박스). 받는 곳: ○○물산 구매 담당. 확신 낮음 표시 1곳: 납기일."

앞의 알림을 받은 사람은 초안 전체를 읽어야 합니다. 바쁘면 읽지 않고 누릅니다. 뒤의 알림은 볼 것이 세 가지뿐입니다. 아무리 바빠도 그 세 가지는 봅니다.

누가 누르는가

승인하는 사람도 정해 둡니다. 담당자 한 명이 휴가를 가면 흐름이 멈추는지, 대신 누를 사람이 있는지. 승인이 쌓이기 시작했다면 그것도 신호입니다. 승인 단계가 병목이라면 자동화의 범위를 다시 봅니다. 확신이 높은 건은 묶어서 한 번에 보고, 확신이 낮은 건만 한 건씩 보도록 나누는 것도 방법입니다. 다만 밖으로 나가는 일을 승인 없이 내보내는 쪽으로 풀어서는 안 됩니다.

부서마다 승인이 필요한 곳

영업팀은 견적서와 고객 회신입니다. 단가, 할인 표기, 받는 회사 이름을 봅니다. 재무팀은 지급과 세금계산서 발행입니다. 금액, 계좌, 거래처 이름을 원장과 대조합니다. 인사팀은 합격·불합격 통보와 급여 명세입니다. 이름과 대상자가 뒤섞이지 않았는지부터 봅니다. 고객지원팀은 답변을 보내는 단계입니다. 환불이나 보상, 기한을 약속하는 문장이 들어갔는지 봅니다. 약속은 한번 나가면 회사가 지켜야 합니다.

직급에 따라서도 다릅니다. 실무자는 건마다 승인하는 편이 맞습니다. 팀장은 금액이 일정 선을 넘는 건만 따로 보는 편이 맞습니다. 그 선은 회사의 전결 규정을 따릅니다. 새 기준을 만들 필요는 없습니다. 이미 있는 결재 기준을 자동화에 옮기면 됩니다.

현장 장면

한 유통사 구매팀은 발주 메일 초안을 자동으로 만들고 담당자가 승인해 보내게 했습니다. 현장 요청서가 공유 폴더에 올라오면 Claude가 발주 메일 초안을 쓰고, 담당자 채널에 "새 발주 초안이 있습니다"라는 알림이 갑니다. 담당자가 확인을 누르면 메일이 나갑니다.

처음 몇 주 동안 담당자는 초안을 꼼꼼히 읽었습니다. 틀린 곳이 거의 없었습니다. 그러자 읽는 시간이 조금씩 줄었고, 어느새 알림이 오면 반사적으로 누르게 됐습니다. 그리고 그날이 왔습니다. 현장 요청서에는 "박스"라고 적혀 있었는데 초안에는 "개"로 들어간 발주가 그대로 나갔습니다. 승인은 있었지만 확인은 없었습니다.

팀은 세 가지를 고쳤습니다. 첫째, Claude 단계의 지시문에 "수량·단위·납기는 원 요청서의 표기를 그대로 옮기고, 요청서에서 읽기 어려웠던 값은 [확인 필요]로 표시한다"를 넣었습니다. 둘째, 알림 문구를 위의 좁힌 알림처럼 바꿔 수량·단위·받는 곳이 알림에 바로 보이게 했습니다. 셋째, 승인자를 담당자와 대리 한 명, 두 사람으로 정했습니다. 담당자가 없는 날에도 흐름이 멈추지 않았고, 대충 누르는 일도 줄었습니다. 그 뒤로 단위 오류는 승인 단계에서 걸러졌습니다.

한 달쯤 지나자 다른 흠이 보였습니다. 월요일 아침이면 주말 동안 쌓인 요청서의 초안 알림이 한꺼번에 몰려왔고, 두 승인자는 다시 빠르게 누르기 시작했습니다. 팀은 알림을 둘로 나눴습니다. 확인 필요 표시가 없는 초안은 오전에 한 번 목록으로 묶어 보내고, 표시가 있는 초안만 한 건씩 알리게 했습니다. 한 건씩 오는 알림이 줄자, 그 알림은 다시 꼼꼼히 읽혔습니다.

그래도 남은 흠이 있었습니다. 요청서 자체가 틀린 경우입니다. 초안은 요청서를 그대로 옮겼으니 대조로는 잡히지 않습니다. 팀은 이것을 현장과 구매팀 사이의 문제로 보았습니다. 자동화를 더 손보는 대신, 분기마다 틀린 요청서 사례를 모아 현장에 돌려주기로 했습니다.

따라 하기

1. 76단계의 흐름에서 밖으로 나가거나 되돌릴 수 없는 단계가 있는지 찾습니다. 지금은 없더라도 나중에 더하고 싶은 단계를 적습니다. 성공 기준: 보내기·결제·삭제에 해당하는 단계가 목록으로 적혔습니다.
2. 그 단계 바로 앞에 승인 단계를 설계합니다. 위 표에서 방식을 고르고, 누가 어디서 무엇을 눌러 승인하는지 적습니다. 성공 기준: 승인 전에는 밖으로 아무것도 나가지 않는다는 것을 흐름 그림에서 확인할 수 있습니다.
3. 승인하는 사람이 확인할 것을 한두 문장으로 적어 알림 문구에 넣습니다. 성공 기준: 알림만 보고도 무엇을 대조할지 압니다.
4. Claude 단계의 지시문에 "확인이 필요한 부분을 따로 표시하라"는 문장을 더합니다. 성공 기준: 샘플을 돌렸을 때 확인할 곳이 초안 안에 표시되어 나옵니다.
5. 담당자가 없을 때 대신 승인할 사람을 정해 적습니다. 성공 기준: 승인자가 두 명 이상입니다.
6. 일부러 틀린 샘플(단위를 바꾼 요청서 등)을 넣어 봅니다. 성공 기준: 승인 단계에서 틀린 곳이 눈에 띕니다.
7. (선택, 심화) 한 달 뒤 승인 기록을 훑습니다. 승인까지 걸린 시간, 승인자가 고친 건수, 그대로 누른 건수를 셉니다. 고친 건이 오래 없다면 둘 중 하나입니다. 초안이 정말 좋아졌거나, 아무도 안 보고 있습니다. 틀린 샘플을 한 번 섞어 어느 쪽인지 확인합니다. 성공 기준: 섞은 틀린 샘플이 승인 단계에서 돌아왔습니다.

복사해 쓰는 프롬프트

아래는 자동화 흐름이 만든 초안이다. 사람이 승인하기 전에 볼 곳을 좁혀 줘.

원 요청: [요청서나 원본 메일]
초안: [흐름이 만든 초안]

할 일:
1. 원 요청과 초안에서 숫자·단위·날짜·받는 사람을 짝지어 표로 보여 준다. 다른 곳이 있으면 "불일치"로 표시한다.
2. 원 요청에서 읽기 어려웠거나 짐작한 값은 "확인 필요"로 표시한다.
3. 승인자가 볼 것을 세 줄 이내로 적는다.
초안을 고치지는 않는다. 표시만 한다.

막히면 이렇게

실습 파일

공개 저장소에 올려 둔 가공 자료와 양식입니다. 회사 자료 대신 먼저 이것으로 해 보세요.

• 채워 쓰는 양식 자동화_설계서.md · 손으로 한 순서와 여섯 줄 설계, 트리거·예약 지시·확인 지점·실패 알림·비용 계산

스스로 점검

• ☐ 흐름의 모든 보내기·결제·삭제 단계 앞에 승인 단계가 있습니까?
• ☐ 알림 문구에 무엇을 대조할지가 적혀 있습니까?
• ☐ 담당자가 없는 날 대신 누를 사람이 정해져 있습니까?

기억할 것

• 되돌릴 수 없는 일 앞에는 승인 단계를 둡니다. 승인 단계에는 무엇을 보고 누르는지 한두 문장을 붙입니다.
• 다 읽으라고 하면 아무것도 안 읽습니다. 볼 곳을 좁혀 주어야 승인이 살아납니다.