업무 규칙이 바뀌면 자동화는 어떻게 되나

자동화를 검토하실 때 대부분 "지금 이 업무를 어떻게 처리하는가"를 기준으로 이야기합니다.

그런데 실제로 운영해 보면 더 자주 마주치는 질문은 이겁니다.

"규칙이 바뀌었는데 이건 어디서 고치나요."

수수료율이 바뀌고, 세법이 바뀌고, 거래처가 양식을 바꾸고, 배송비 기준이 바뀝니다. 업무 규칙은 생각보다 자주 바뀝니다. 그리고 자동화는 규칙 위에 서 있습니다.

세 가지 자리가 있습니다

같은 「규칙 변경」이라도 어디에 들어 있느냐에 따라 대응이 완전히 다릅니다.

1. 화면에서 바꿀 수 있는 것

관리자 화면에 수수료율, 기준일, 상태 이름, 알림 문구가 입력칸으로 있으면 담당자가 직접 바꿉니다.

비용 0원, 소요 1분. 이게 가장 좋은 상태입니다.

2. 업체에 요청해야 하는 것

규칙이 코드 안에 적혀 있으면 매번 업체를 불러야 합니다.

작은 변경이라도 요청하고, 견적받고, 작업하고, 확인하는 과정이 붙습니다. 숫자 하나 바꾸는 데 며칠과 비용이 듭니다.

그리고 더 큰 문제가 있습니다. 번거로우니까 안 바꾸게 됩니다. 규칙이 현실과 어긋난 채로 몇 달이 갑니다.

3. 아예 못 바꾸는 것

설계 자체가 그 변화를 전제하지 않은 경우입니다.

예를 들어 수수료를 한 가지 방식으로만 계산하도록 만들어 두면, 나중에 거래처마다 다른 방식이 생겼을 때 화면에서도 코드에서도 손댈 수 없습니다. 구조를 다시 짜야 합니다.

무엇이 바뀔 수 있는지 미리 세어보십시오

어렵지 않습니다. 최근 2~3년을 돌아보면서 실제로 바뀐 것을 적어보시면 됩니다.

대부분 이 정도가 나옵니다.

「예고 없이」가 붙은 줄이 가장 위험합니다. 상대가 양식을 바꾸면 우리 자동화는 조용히 틀린 값을 읽기 시작합니다.

요구사항에 넣을 한 줄

견적 단계에서 이 한 줄을 넣으시면 대부분 정리됩니다.

"운영 중 변경될 수 있는 값은 관리자 화면에서 담당자가 직접 수정할 수 있어야 한다. 해당 항목 목록을 제안서에 적어달라."

뒷부분이 중요합니다. 업체가 그 목록을 적으면 무엇을 화면으로 뺐고 무엇을 코드에 남겼는지가 드러납니다. 그게 비교 기준이 됩니다.

그리고 한 가지 더 있습니다.

"규칙이 바뀌었을 때, 바뀌기 전에 처리된 건은 어떻게 되는가."

이게 자주 빠집니다. 수수료율이 3월에 바뀌었다면 2월 건은 옛 요율로, 3월 건은 새 요율로 계산돼야 합니다. 그냥 값만 바꾸면 과거 건까지 새 요율로 다시 계산되어 장부가 어긋납니다.

규칙에도 적용 시작일이 있어야 합니다. 이건 나중에 붙이기 어려운 종류입니다.

외부 양식 변경에 대비하는 법

거래처 정산서나 마켓 화면이 바뀌는 것은 막을 수 없습니다. 대신 빨리 알아채는 것은 가능합니다.

• 들어오는 파일의 형태를 매번 확인하게 합니다. 열 개수가 다르거나 머리글이 바뀌면 처리하지 않고 알립니다
• 확인 없이 처리하면 엉뚱한 열을 금액으로 읽습니다. 그러면 숫자가 그럴듯하게 틀립니다
• 이건 개발 비용이 거의 안 드는 장치인데, 요구하지 않으면 대개 안 들어갑니다

정리

• 규칙은 바뀝니다. 문제는 바뀌는 게 아니라 바꿀 수 없는 것입니다
• 세 자리를 구분하십시오. 화면에서 바꾸는 것 / 업체를 불러야 하는 것 / 아예 못 바꾸는 것
• 도입할 때 정할 것은 「어떤 규칙을 쓸까」가 아니라 「어떤 규칙이 바뀔 수 있을까」입니다
• 요구사항 한 줄: "운영 중 변경될 수 있는 값의 목록을 제안서에 적어달라"
• 잊지 마실 것: 규칙에는 적용 시작일이 있어야 합니다. 과거 건이 다시 계산되면 안 됩니다

사내에 개발자가 안 계시다면 이 항목이 비용에 가장 크게 영향을 줍니다. 화면에서 바꿀 수 있는 것이 많을수록 도입 후 지출이 줄어듭니다.

여기까지 읽으셨다면 지금 이 업무에 월 몇 시간이 들어가는지 계산해 보실 수 있습니다. 가입도 이메일도 필요 없습니다.