프로세스 없이 시스템을 넣으면 시스템이 프로세스가 됩니다

지난 글에서 업무마다 수준을 판정하는 방식을 이야기했습니다. 그 계단에서 프로세스 정립이 시스템 사용보다 앞에 있었습니다. 이번에는 그 순서를 지키지 않으면 어떻게 되는지 써보겠습니다.

프로세스 없이 시스템을 넣으면

흔히 이렇게 생각합니다. "시스템을 넣으면 프로세스가 정리되겠지."

실제로는 반대로 일어납니다. 프로세스를 정의하지 않은 상태에서 시스리 업무를 얹으면, 맞는 부분은 그냥 쓰고 안 맞는 부분은 우회하게 됩니다.

우회의 결과가 엑셀과 메일입니다. 시스템에 안 맞는 일이 밖으로 나가고, 밖으로 나간 일은 기록에 안 남습니다.

그리고 아무도 이 프로세스를 설계하지 않았습니다. 패키지가 절반, 우회 관행이 절반을 만들었습니다. 몇 년 지나면 왜 이렇게 하는지 아는 사람이 없어집니다. "원래 이렇게 해왔다"는 답만 남습니다.

그런데 순서를 지키기가 비쌌습니다

순서를 지킨다는 것은 이런 뜻입니다. 먼저 우리 업무를 정의하고, 그다음에 그 업무에 맞는 시스템을 만드는 것.

이 방식이 옳다는 것은 오래전부터 알려져 있었습니다. 그런데 실제로는 거의 하지 못했습니다. 비용 때문입니다.

우리 프로세스에 맞춰 시스템을 만들려면 개발이 필요했고, 개발은 비쌌습니다. 사람과 기간이 들어가고, 만든 다음에도 유지보수가 따라옵니다. 반면 패키지는 이미 만들어져 있습니다.

그래서 대부분 패키지를 사고 업무를 거기에 맞췄습니다. 합리적인 선택이었습니다. 프로세스에 시스템을 맞추는 것보다 시스템에 프로세스를 맞추는 것이 훨씬 쌌기 때문입니다.

그 비용 구조가 바뀌고 있습니다

지금 달라지고 있는 것은 개발 비용입니다. AI가 코드를 만들면서 무언가를 새로 만드는 데 드는 시간과 비용이 크게 줄었습니다.

그러면 계산이 뒤집힙니다. 업무 하나에 맞는 도구를 만드는 일이 패키지를 도입하고 커스터마이징하는 것보다 빠르고 싸질 수 있습니다.

여기서 중요한 결론이 나옵니다. 병목이 개발에서 프로세스 정의로 옮겨갔습니다.

예전에는 무엇을 만들지 알아도 만들 여력이 없었습니다. 지금은 만들 수는 있는데 무엇을 만들지가 정해지지 않아 멈춥니다. 그래서 프로세스 정의가 이제 가장 값비싼 작업이 되었습니다. 코드가 싸질수록 그렇습니다.

프로세스를 정의한다는 것

업무 흐름도를 그리는 일로 오해하기 쉽습니다. 화살표로 이어진 상자들을 그려놓고 정의했다고 하는 경우가 많습니다.

정작 필요한 것은 네 가지입니다.

• 입력과 출력 — 이 업무는 무엇을 받아서 무엇을 내놓는가. 앞 업무와 뒤 업무가 여기서 연결됩니다.
• 판단 기준 — 이 일에서 사람이 판단하는 것은 무엇이고, 그 판단의 근거는 무엇인가. 숙련자의 머릿속에 있는 것을 밖으로 꺼내는 작업입니다.
• 예외 처리 — 정상 흐름에서 벗어났을 때 어떻게 하는가.
• 확정과 변경 — 언제 확정으로 보고, 바뀌면 누가 어떻게 반영하는가.

이 중에서 예외가 가장 중요하고 가장 자주 빠집니다.

정상 흐름은 누구나 그릴 수 있습니다. 그런데 실제 업무 시간의 상당 부분은 예외를 처리하는 데 쓰입니다. 고객이 사양을 바꾸고, 자재가 늦고, 설계가 틀립니다. 예외를 정의하지 않고 만든 시스템은 정상일 때만 작동하고, 현장은 정상인 날이 드뭅니다.

그래서 프로세스를 정의할 때 물어야 할 질문은 "어떻게 하십니까"가 아니라 "안 맞을 때는 어떻게 하십니까"입니다. 이 질문에서 진짜 업무가 나옵니다.

작게 시작하는 이유

전사 프로세스를 다 정의하고 시작하려 하면 시작하지 못합니다. 몇 년이 걸리고 그 사이에 상황이 바뀝니다.

대신 업무 하나를 고릅니다. 앞선 글에서 업무를 쪼갠다고 했는데, 그 쪼갠 단위 하나입니다. 고르는 기준은 이렇습니다.

• 지금 엑셀이나 수작업으로 버티고 있다
• 담당자가 그 불편을 분명히 느끼고 있다
• 앞뒤 연결이 비교적 단순하다
• 틀렸을 때 되돌릴 수 있다

마지막 조건이 특히 중요합니다. 처음부터 발주나 재고처럼 틀리면 실물이 움직이는 업무를 고르면 안 됩니다.

이렇게 하나를 만들어 실제로 쓰이게 되면 그다음이 쉬워집니다. 사람들이 "우리 일에 맞는 도구"라는 것을 경험하기 때문입니다. 그 경험이 있으면 프로세스를 정의하는 일에 협조가 붙습니다. 없으면 또 하나의 전산 프로젝트로 받아들여집니다.

빨라진 만큼 조심할 것

만들기 쉬워졌다는 것이 아무거나 만들어도 된다는 뜻은 아닙니다. 오히려 새 문제가 생깁니다.

난립합니다. 만들기 쉬우면 여기저기서 만듭니다. 부서마다 비슷한 것을 각자 만들고, 몇 달 뒤에는 무엇이 있는지 아무도 모릅니다. 이것은 부서별 Agent가 늘어날 때 생기는 문제와 같은 구조입니다.

유지보수가 남습니다. 만드는 시간이 줄어도 고치는 책임은 그대로입니다. 만든 사람이 부서를 옮기면 그 도구는 방치됩니다. 누가 무엇을 만들었고 누가 책임지는지가 기록되어야 합니다.

데이터가 갈라집니다. 각자 만든 도구가 각자 데이터를 들고 있으면, 나중에 합치는 것이 원래 문제보다 커집니다.

그래서 만들기 시작할 때 함께 정해야 하는 것이 있습니다. 무엇을 만들었는지 등록하는 자리, 데이터를 어디에 둘지에 대한 원칙, 그리고 책임자입니다. 이것을 나중에 하려고 하면 정리하는 것 자체가 프로젝트가 됩니다.

정리

프로세스를 정의하지 않고 시스템을 넣으면 시스템이 프로세스가 됩니다. 오래 알려진 이야기지만 지키기 어려웠던 이유는 개발이 비쌌기 때문입니다.

그 제약이 풀리고 있습니다. 그래서 이제 진짜 병목은 우리가 무슨 일을 어떻게 하는지 스스로 아는 것입니다. 이것은 AI가 대신해줄 수 없는 부분입니다.

다음 글에서는 이렇게 만들어진 것들을 어떻게 한눈에 보면서 관리할지, 즉 전체를 관제한다는 것이 무엇인지 써보겠습니다.