자동화를 맡길 때, "지금 하는 대로"는 요구사항이 아닙니다

자동화를 요청하는 문장은 대개 짧습니다. "매일 하는 이 집계, 지금 하는 대로 자동으로 되게 해 주세요." 그런데 이렇게 만들어진 자동화가 현장에서 첫 달을 버티지 못하는 경우가 적지 않습니다. 만든 사람의 실력 문제라기보다 출발점이 된 요구사항에 업무의 절반이 빠져 있었기 때문입니다.

이 글은 자동화 요구사항에서 무엇이 빠지는지, 왜 빠지는지, 그리고 만들기 전에 무엇을 먼저 확인하면 그 빈칸을 줄일 수 있는지를 정리합니다. 사내 개발이든 외주든, 직접 만드는 자동화든 같은 구조로 적용됩니다.

"지금 하는 대로"가 요구사항이 못 되는 이유

"지금 하는 대로"라는 말에는 전제가 하나 숨어 있습니다. 지금 하는 방식이 하나로 정해져 있다는 전제입니다. 실제로 확인해 보면 그렇지 않은 경우가 많습니다.

첫째, 같은 업무라도 사람마다 절차가 다릅니다. 오전 담당자는 거래처 코드 순으로 정리하고, 오후 담당자는 납기 순으로 정리합니다. 둘 다 결과는 맞습니다. 하지만 자동화는 둘 중 하나만 따라 할 수 있고, 요청서에는 보통 요청한 사람의 방식만 적힙니다.

둘째, 업무의 핵심 판단은 머릿속에 있습니다. "이 거래처는 수량이 이상하면 한 번 전화해 본다", "월말에는 전날 것까지 합친다" 같은 규칙은 담당자에게는 너무 당연해서 설명할 생각조차 하지 않습니다. 문서로 남아 있지 않으니 요청서에도 들어가지 않습니다.

정리하면, 요청서에 적힌 업무는 실제 업무의 윗부분입니다. 그 아래에 사람별 차이와 머릿속 규칙이 깔려 있고, 자동화가 틀어지는 지점은 대부분 그 아래층입니다.

요청서에 적히는 것은 업무의 윗부분뿐입니다

요청서에서 가장 자주 빠지는 두 가지

아래층이 요청서에 남기는 흔적은 두 가지로 나타납니다. 예외 케이스와 입력 데이터의 실물입니다. 두 가지 모두 같은 순서로 보겠습니다.

빠지는 것 1: 예외 케이스

1. 증상: 평소에는 잘 돌다가 특정 날에만 멈추거나, 멈추지 않고 틀린 결과를 냅니다. 월말 마감, 분기 결산, 거래처 신규 등록, 반품이 섞인 날이 대표적입니다.

2. 원인: 요청하는 사람은 "평소 업무"를 떠올리며 설명합니다. 한 달에 한 번, 1년에 한두 번 생기는 처리는 요청 시점에 떠오르지 않습니다. 떠오르더라도 "그건 그때 제가 손으로 하면 된다"고 넘기는 경우가 많습니다.

3. 처방: 예외를 모두 자동화할 필요는 없습니다. 다만 자동화가 처리할 것과 사람에게 넘길 것의 경계는 요구사항에 적혀 있어야 합니다. 경계가 없으면 자동화는 예외를 정상 건처럼 처리해 버립니다.

빠지는 것 2: 입력 데이터의 실물

1. 증상: 테스트에서는 잘 되던 자동화가 실제 파일을 넣으면 오류가 납니다. 열 순서가 다르거나, 날짜가 글자로 들어가 있거나, 병합된 셀이 있습니다.

2. 원인: 입력 데이터를 말로만 설명했기 때문입니다. "거래처에서 오는 엑셀 파일"이라는 설명은 하나지만, 실제 파일은 거래처마다, 달마다 모양이 조금씩 다릅니다.

3. 처방: 설명 대신 파일을 받습니다. 한 달치가 아니라 여러 달치를 받아야 변형이 보입니다.

말로 들은 설명	실제 파일에서 자주 발견되는 것
"거래처에서 엑셀로 옵니다"	거래처마다 열 순서·시트 이름이 다름
"날짜 열이 있습니다"	날짜 형식과 글자 형식이 섞여 있음
"수량을 합치면 됩니다"	소계 행, 병합 셀, 메모 행이 중간에 끼어 있음
"매일 한 파일입니다"	정정본이 같은 날 한 번 더 오는 경우가 있음

표의 항목은 흔히 나타나는 유형을 정리한 것이며, 어떤 변형이 나올지는 회사와 거래처마다 다릅니다. 그래서 목록을 외우기보다 실제 파일을 보는 편이 확실합니다.

요구사항을 정리하기 전에 먼저 하는 네 가지

요구사항 정의서 양식을 펼치기 전에, 아래 네 가지를 이 순서로 합니다. 앞 단계에서 얻은 것이 다음 단계의 재료가 됩니다.

1. 작업 옆에서 지켜보기: 설명을 듣는 대신 실제 작업자가 하는 것을 봅니다. 요청한 사람과 작업하는 사람이 다르면 작업하는 사람을 봅니다. 사람마다 절차가 다른 지점, 설명에 없던 확인 동작이 여기서 보입니다.
2. 실제 파일 여러 달치 받기: 지켜보면서 어떤 파일이 들어오는지 알았으니, 그 파일을 몇 달치 받아 변형을 확인합니다. 월말·분기말이 포함되도록 기간을 잡습니다.
3. 지금은 예외를 어떻게 처리하는지 묻기: 파일에서 이상한 건을 찾았으면 그 건을 들고 가서 묻습니다. "이런 건 지금 어떻게 하세요?" 막연히 "예외가 있나요?"라고 물으면 "없다"는 답이 돌아오지만, 실제 건을 보여 주면 머릿속 규칙이 나옵니다.
4. 정답지 확보하기: 같은 기간에 사람이 손으로 만든 결과물을 받아 둡니다. 자동화 결과를 이것과 대조해야 "완성됐다"고 말할 수 있습니다. 결과를 어떤 기준으로 검수할지는 AI가 내놓은 결과, 누가 어떤 기준으로 검수하는가에서 다룬 내용과 같은 구조입니다.

앞 단계가 다음 단계의 재료가 됩니다

네 단계를 거치고 나면 요구사항 문서에 쓸 내용이 이미 대부분 나와 있습니다. 양식은 그 내용을 옮겨 담는 그릇일 뿐입니다.

양식과 "일단 만들고 고치자"의 함정

양식만 채우면 된다

요구사항 정의서 양식에는 기능, 입력, 출력, 예외 같은 칸이 있습니다. 칸을 모두 채우면 빠짐없이 정리한 것처럼 보입니다. 하지만 예외 칸에 "오류 시 알림"이라고 쓰는 것과 "정정본이 같은 날 다시 오면 앞의 것을 버린다"라고 쓰는 것은 전혀 다른 문서입니다. 양식은 무엇을 물어야 할지 알려 줄 뿐, 답을 대신 찾아 주지 않습니다.

일단 만들고 고치면 된다

빠르게 만들어 보고 맞춰 가는 방식 자체가 틀린 것은 아닙니다. 문제는 예외가 발견되는 시점입니다. 만들기 전에 발견한 예외는 요구사항 한 줄을 고치면 되지만, 운영 중에 발견된 예외는 이미 틀린 결과가 다음 업무로 넘어간 뒤입니다. 결과를 되돌리고, 누가 무엇을 받았는지 확인하는 일이 따라붙습니다. 그리고 그 사이 현업은 자동화를 믿지 않게 됩니다. 만들어놓은 자동화가 6개월 뒤 안 쓰이는 이유에서 다룬 이탈은 이 지점에서 시작되는 경우가 많습니다.

같은 예외라도 늦게 발견할수록 고칠 것이 늘어납니다

이 방식이 잘 안 되는 경우

네 단계에도 한계가 있습니다. 가장 흔한 것은 작업자가 시간을 내지 못하는 경우입니다. 지켜보고 묻는 과정은 결국 작업자의 시간을 씁니다. 업무가 몰린 담당자에게 "옆에서 좀 보겠다"는 요청은 부담이 되고, 그러면 관찰은 짧아지고 질문은 형식적이 됩니다. 이럴 때는 범위를 줄이는 편이 낫습니다. 업무 전체가 아니라 가장 반복이 많은 한 구간만 먼저 정리하고, 나머지는 그 구간이 안정된 뒤에 넓힙니다.

또 하나는 작업을 아는 사람이 이미 없는 경우입니다. 담당자가 바뀌었거나 퇴사했다면 머릿속 규칙은 복원하기 어렵습니다. 이 경우에는 과거 결과물을 거꾸로 분석해 규칙을 추정할 수밖에 없고, 추정한 규칙은 반드시 현재 담당자와 확인해야 합니다. 자동화를 만든 사람이 퇴사하면 생기는 일은 이 문제를 자동화 쪽에서 본 글입니다.

자주 묻는 질문

요구사항 정의서 양식은 필요 없나요?

필요합니다. 다만 양식은 네 단계에서 확인한 내용을 정리하는 도구로 쓰는 편이 낫습니다. 양식부터 채우면 확인하지 않은 내용이 확인한 것처럼 적힙니다.

예외가 많으면 자동화하지 않는 편이 낫나요?

예외가 많다는 것만으로 포기할 이유는 없습니다. 자동화가 처리할 건과 사람에게 넘길 건을 명확히 가를 수 있으면 부분 자동화로도 충분히 효과를 봅니다. 그 경계를 가를 수 없을 정도로 판단이 애매한 건이 많다면, 그때는 자동화보다 업무 기준을 먼저 정리해야 합니다.

외주에 맡길 때도 같은 순서가 필요한가요?

외주일수록 더 필요합니다. 외주 개발자는 현장을 지켜볼 기회가 적고, 받은 문서와 샘플 파일만으로 만듭니다. 여러 달치 실제 파일과 정답지를 함께 넘기면 요구사항 문서의 빈칸을 상당 부분 메울 수 있습니다.

정답지는 얼마나 모아야 하나요?

정해진 기준은 없습니다. 다만 월말·분기말처럼 처리가 달라지는 시점이 한 번 이상 포함되어야 대조의 의미가 있습니다.

요구사항을 정리하다 보면 애초에 자동화보다 표준화가 먼저인 업무가 드러나기도 합니다. 그 판단 기준은 제조 현장에서 자동화하면 안 되는 업무 4가지에 정리했습니다.

자동화 이야기에서 한 걸음 옮기면, 바코드처럼 현장 기록을 자동으로 남기는 도구에서도 같은 문제가 생깁니다. 잘 찍히는데도 숫자가 맞지 않는 이유는 바코드를 붙였는데 실적이 안 맞는 이유에 정리했습니다.