AI 업무 흐름, 어디서 사람이 확인할까

자료 받기부터 초안·검토·승인까지 나눕니다. 정보 부족과 재시도 상황을 종이 위에서 시험하고, 업무를 멈추거나 넘기는 기준을 만듭니다.

단계별 따라하기

1. 1

   좋은 초안과 완료된 업무는 다릅니다

   영업 제안 초안이 잘 나왔습니다. 그런데 담당자가 검토하기 전에 고객에게 보내졌다면 문장 품질만으로 성공을 말할 수 없습니다. 반대로 초안은 완성됐지만 검토를 맡은 사람이 누구인지 몰라 멈춰 있어도 업무는 끝나지 않았습니다. 이번 수업은 답변을 더 잘 쓰게 하는 수업 다음 단계입니다. 입력이 어디에서 오고, 누가 무엇을 확인하며, 마지막에 무엇이 실제로 바뀌는지 한 장으로 그립니다.

   워크플로는 일을 어떤 순서와 조건으로 처리할지 정한 절차입니다. '자료를 읽는다 → 제안 초안을 쓴다 → 사람이 확인한다'처럼 다음 행동이 정해져 있으면 먼저 그 절차를 명확하게 만듭니다. 에이전트처럼 다음 행동을 모델이 선택하게 하는 방식은 선택의 범위와 실패 지점도 더 살펴야 합니다. 모든 단계에 AI가 필요한 것은 아닙니다. 빈 필드 확인이나 같은 요청 번호의 중복 확인은 정해진 규칙으로 처리하는 편이 설명하기 쉽습니다.

   Anthropic의 워크플로 설명은 미리 정한 경로와 모델이 행동을 고르는 구조를 구분하고, 필요한 만큼만 복잡하게 만들도록 안내합니다. 여기서는 그 구분을 가상의 영업 제안에 적용합니다. 아래 제품·고객·요청 번호는 모두 연습을 위해 만든 것입니다. 실제 회사가 사용 중인 자동화나 특정 도구의 화면을 재현한 자료가 아니므로 버튼 이름을 따라 외부 시스템을 바꾸지 않습니다.

2. 2

   각 단계의 입력과 나올 것을 적습니다

   

   가상 요청 W1에는 '파일을 내려받을 수 있나요?'라는 고객 질문과 'CSV 내보내기 제공, 기존 시스템 연결은 미확인'이라는 제품 자료가 있습니다. 먼저 자료를 받은 단계에서 문의 번호, 원문, 제품 자료 버전을 남깁니다. 원문을 다듬어 버리면 나중에 관심 표현을 구매 약속으로 바꿨는지 확인하기 어렵습니다. 입력을 보관할 때는 업무에 필요한 범위와 접근 가능한 사람도 정하며, 실제 고객 정보를 이 연습에 복사하지 않습니다.

   다음 단계의 결과는 '답변 한 개'보다 구체적이어야 합니다. 제안 초안, 근거 번호, 미확인 항목 세 칸으로 정하면 검토할 것이 보입니다. 근거가 없는데 제품 연결을 확정한 초안은 검토 대기에서 수정 필요로 돌아갑니다. 검토자는 문장만 받지 않고 원문과 제품 자료를 함께 봅니다. 결과물 옆에 원문을 두는 이유는 AI가 붙인 설명을 다시 믿는 대신 사실을 직접 대조하기 위해서입니다.

   아래 표는 사람이 종이로 실행할 수 있는 최소 절차입니다. 자동화 프로그램을 만들 때도 같은 입력과 결과를 계약처럼 사용할 수 있지만, 이 표 자체가 구현이나 접근 통제를 대신하지는 않습니다. 누가 검토하는지 이름이나 역할을 적고, 담당자가 없을 때 넘길 경로를 정하세요. '사람이 확인한다'는 한 문장만 쓰고 대기 목록을 아무도 보지 않으면 실제로는 확인 단계가 없는 것과 비슷해집니다.

   W1 · 연습용 업무 절차

   단계	입력	완료 시 남길 것
   접수	고객 질문 + 제품 자료 P1	요청 번호 W1 + 원문 + 자료 버전
   초안	접수 기록	제안 문장 + 근거 + 미확인 항목
   검토	초안 + 원문 + 채점표	통과 또는 수정 이유
   승인	통과한 초안의 정확한 버전	승인자 + 승인 시각 + 허용할 행동
   완료 확인	승인된 행동의 실제 처리 기록	처리 결과 또는 확인이 필요한 상태

3. 3

   승인은 어느 버전의 무엇에 대한 것인가

   검토한 초안이 D1이고 승인 뒤 AI가 문장을 고쳐 D2를 만들었다면 D1의 승인을 그대로 옮기지 않습니다. 바뀐 곳이 인사말인지 기능 약속인지 검토자가 확인해야 하기 때문입니다. 승인 기록에는 문서 버전과 수행할 행동을 연결합니다. 초안 저장 허용, 내부 공유 허용, 고객 발송 허용은 서로 다른 행동입니다. 읽기 권한과 실제 변경 권한을 구분해야 업무의 마지막 단계에서 무엇이 일어날지 설명할 수 있습니다.

   사람의 검토를 뜻하는 휴먼 인 더 루프는 체크 표시 하나로 끝나지 않습니다. 검토자가 원문을 볼 수 있는지, 판단할 시간을 받는지, 거절하거나 수정 요청을 할 수 있는지가 중요합니다. 도장만 누르게 만들면 사실을 확인하는 기능을 하지 못합니다. 정보가 부족한 경우에는 거절과 오류를 한데 묶지 않고 자료 요청 상태로 남깁니다. 그 상태에서 빠진 정보를 누가 가져와야 하는지도 기록합니다.

   디자인에서는 승인한 시안의 파일 버전과 공개 용도를, 마케팅에서는 승인 문구와 적용 채널을, 기획에서는 결정문과 재검토 조건을 연결할 수 있습니다. 연구에서는 요약 승인과 연구 결과의 확정이 다를 수 있고, 개발에서는 코드 제안 승인과 실제 서비스 반영이 다릅니다. 직군마다 마지막 행동은 달라도 승인 대상이 바뀌면 다시 확인한다는 구조는 같습니다. 이 연습에서는 외부 행동을 실제로 실행하지 않고 처리 기록을 종이에 표시합니다.

4. 4

   실패하면 멈출 곳과 돌아갈 곳을 만듭니다

   

   자료가 없는데 다시 요청만 보내면 빈 근거가 채워지지 않습니다. W1에서 시스템 연결 여부가 빠졌다면 담당자에게 제품 자료 확인을 요청하고 답이 올 때까지 해당 약속을 보류합니다. 이처럼 AI가 처리하지 못한 일을 사람의 절차로 넘기는 대체 경로를 폴백이라고 부릅니다. '오류가 났습니다' 대신 무엇이 부족하고 다음에 누가 무엇을 할지 설명해야 사용자가 일을 이어 갈 수 있습니다.

   응답을 기다리다 시간이 초과된 경우는 더 조심해서 상태를 구분합니다. 요청을 받지 못한 것인지, 처리했지만 확인 응답만 놓친 것인지 모르면 곧바로 같은 발송을 반복하지 않습니다. 요청 번호와 처리 기록으로 실제 결과를 먼저 확인합니다. 같은 요청을 여러 번 처리해도 외부 효과가 중복되지 않게 설계하는 성질이 멱등성입니다. 표에 번호를 쓰는 것만으로 보장되지는 않으며 실제 시스템이 중복을 막는 방식이 필요합니다.

   종이 실습에서는 'W1이 이미 완료 기록에 있다'는 카드를 추가하고 다시 들어온 W1을 어디로 보낼지 써 봅니다. 이미 처리된 동일 요청이면 기존 결과를 확인하는 단계로 보냅니다. 내용이 바뀐 새 요청이면 새 버전으로 검토합니다. 정보가 없는 오류와 중복 오류를 모두 '한 번 더 실행'으로 처리하면 해결되지 않거나 새로운 문제가 생깁니다. Google PAIR의 오류 안내도 실패 이유를 구분하고 사용자가 다음 행동을 할 수 있게 만드는 점을 강조합니다.

5. 5

   정상·빈칸·충돌·중복을 각각 걸어 봅니다

   절차가 완성된 것처럼 보일 때 종이 위에 요청 카드를 놓고 각 칸을 지나가 봅니다. 정상 입력은 CSV 내보내기만 묻는 W1입니다. 두 번째는 제품 자료가 없는 W2, 세 번째는 서로 다른 두 제품 문서가 연결 기능을 다르게 말하는 W3, 네 번째는 이미 완료한 W1의 재접수입니다. 이 네 가지는 연습용 분류이며 실제 업무의 모든 실패를 대표하지는 않습니다. 목적은 다음 상태가 애매한 지점을 찾는 것입니다.

   W2를 초안 단계로 그대로 넘기면 근거 없는 기능 설명이 생길 수 있으므로 접수에서 자료 요청으로 이동합니다. W3는 최신 문서나 권위 있는 자료를 확인하기 전까지 충돌 상태를 표시하고 사람이 판단합니다. 오래된 문서라는 근거 없이 AI가 마음에 드는 쪽을 고르게 하지 않습니다. 중복 W1은 기존 결과 확인으로 이동합니다. 어떤 카드도 담당자 없는 막다른 칸에 남지 않는지 확인하세요.

   작업자가 바뀌어도 같은 흐름을 따라갈 수 있어야 합니다. 화살표마다 조건이 하나도 없거나, '적당히 판단'이라고만 적혀 있다면 어떤 근거를 봐야 하는지 보충합니다. 모든 입력에 확정 답을 내리는 것이 목표는 아닙니다. 모르는 상태를 정확히 남기고 책임 있는 다음 행동으로 넘기는 것도 완료된 처리일 수 있습니다. 다만 '제안 작성 완료'와 '고객 발송 완료'를 같은 완료 표시로 합치지 않습니다.

6. 6

   직접 해 보기: 내 직군의 흐름 한 장

   직군별 프로젝트의 결과물 하나를 골라 접수, 초안, 검토, 승인, 결과 확인의 칸을 그립니다. 각 칸 아래에 입력, 나오는 기록, 담당자, 다음 단계 조건을 적습니다. 칸의 수를 무조건 다섯 개로 맞출 필요는 없습니다. 실제로 필요 없는 단계를 지우거나 자료 확인을 나눠도 됩니다. 다만 결과를 바꾸는 행동 전후의 상태가 드러나고, 실패했을 때 어디로 돌아가는지 설명할 수 있어야 합니다.

   그다음 원문에서 날짜가 빠진 상황, 승인 후 문서가 바뀐 상황, 완료 응답을 받지 못한 상황을 넣습니다. 각각 누가 무엇을 확인해야 재개할지 쓰고 정상 경로와 함께 제출합니다. 코드를 작성하지 않아도 이 정도로 명확한 절차는 개발자나 운영 담당자와 구현 범위를 논의하는 데 쓸 수 있습니다. 실제 권한 설정과 서비스 동작은 구현 뒤 따로 검증해야 하며 이 연습의 도식만으로 운영 안전을 보증하지 않습니다.

   통과 기준은 모든 단계에 담당자가 있고, 근거 없는 약속이 검토를 통과하지 않으며, 승인한 버전과 처리한 버전이 연결되는 것입니다. 시간 초과를 무조건 재실행하는 화살표가 있으면 다시 살펴보세요. 완성한 절차는 다음 수업의 측정 계획에 사용합니다. 검토 시간을 포함한 실제 작업 시간을 재야 자동화가 업무를 줄였는지, 사람에게 다른 일을 더 만든 것인지 판단할 수 있습니다.