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

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

이 단계를 마치면

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

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

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

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

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

어느 단계 앞에 두는가

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

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

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

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

승인 단계의 모양

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

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

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

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

알림 문구 두 가지를 나란히 놓아 보자.

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

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

누가 누르는가

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

부서마다 승인이 필요한 곳

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

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

현장 장면

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

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

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

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

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

따라 하기

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

복사해 쓰는 프롬프트

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

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

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

막히면 이렇게

실습 파일

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

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

스스로 점검

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

기억할 것

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