자동화가 해결할 수 없는 나머지 20%가 당신의 가치를 결정한다

한 독자가 이번 달 제가 본 질문 중 가장 날카로운 질문을 던졌습니다.

어떤 종류의 문제들이 여전히 시니어(Senior)를 필요로 하는 그 20%에 속하나요?

대부분의 자동화(Automation) 제안은 그 반대의 답을 내놓습니다. 그들은 항상 해결될 예정이었던 80%를 판매하며, 커리어를 망가뜨릴 수 있는 부분에 대해서는 침묵합니다.

그래서 제가 DACH 지역의 자동화 배포 전반에 걸쳐 감사(Audit)하는 엔터프라이즈 스택(Enterprise stacks)을 바탕으로 솔직한 답변을 드리고자 합니다.

80%는 쉬운 약속입니다. 20%가 전체 업무(Engagement)의 핵심입니다.

80%의 실체

80%는 형태가 있는 작업입니다.

명확한 입력(Input), 알려진 규칙(Rule), 예측 가능한 출력(Output). 송장(Invoice)이 들어오면 품목(Line items)이 나오고, 리드(Lead)가 들어오면 정보 보강(Enrichment)이 되고, 티켓(Ticket)이 들어오면 라우팅된 티켓이 나옵니다.

이러한 작업은 사과할 필요 없이 자동화되어야 합니다. 이는 반복적이고, 잘 이해되어 있으며, 사람이 수동으로 하는 것은 낭비입니다.

만약 어떤 벤더(Vendor)가 여전히 80%의 자동화를 어려운 부분인 것처럼 당신에게 팔고 있다면, 그들은 쉬운 것을 어려운 것의 가격으로 팔고 있는 것입니다.

20%에 포함된 것들

20%는 80%의 축소판이 아닙니다. 그것은 다른 종류의 문제입니다. 모든 감사(Audit)에서 이는 네 가지 클래스로 나뉩니다.

• 모호함 속에서의 판단(Judgment under ambiguity). 상황이 새롭기 때문에 규칙이 존재하지 않습니다. 시스템이 전달받지 못한 트레이드오프(Trade-offs)를 누군가는 저울질해야 합니다.
• 실제적인 결과가 따르는 예외 사항(Exceptions with real consequences). 돈, 규제 기관, 또는 구축하는 데 수년이 걸린 고객 관계와 직결된 엣지 케이스(Edge case)입니다.
• 데이터베이스가 아닌 머릿속에 존재하는 맥락(Context). 이 고객이 왜 예외를 적용받는지에 대한 이유, 아무도 기록하지 않은 이력, 팀원 모두는 알고 있지만 어떤 필드(Field)로도 포착할 수 없는 것들입니다.
• 책임 소재가 명확해야 하는 결정(Decisions that need a name on them). 문제가 발생했을 때, 책임(Accountability)은 워크플로(Workflow)가 아닌 사람에게 귀속되어야 합니다.

자동화 관점에서 이 모든 것들은 정상적인 작업(Normal task)으로 보고됩니다. 하지만 이 중 그 어느 것도 정상적인 작업이 아닙니다.

그럼에도 팀들이 20%를 자동화하려는 이유

압박은 실재하며, 저도 그 마음을 이해합니다.

80%가 자동화되면 비용 절감 효과가 눈에 보이고, 자연스럽게 나머지 부분까지 밀어붙이려는 요구가 뒤따릅니다. 20%에 대한 데모는 항상 괜찮아 보입니다. 왜냐하면 데모는 해피 패스 (Happy Path)를 실행하며, 그 해피 패스는 80%와 유사하게 동작하는 20%의 일부분이기 때문입니다.

그래서 팀은 이를 배포합니다. 그러다 돈이 걸린 진짜 예외 상황이 발생하면, 자동화 시스템은 송장을 처리할 때와 똑같은 자신감으로 그 상황을 처리해 버립니다.

그 순간이 바로 시니어 (Senior)가 의사결정을 붙잡고 있어야 했음에도 그러지 못했던 바로 그 시점입니다.

그 실패의 대가

80%가 실패하면 개발 시간 (Developer hours)을 잃습니다.

20%가 실패하면, 재시도 (Retry)를 한다고 해서 다시 돌아오지 않는 것을 잃게 됩니다.

검토 없이 내려진 규제 대상 의사결정. 일상적인 티켓 (Ticket)처럼 처리된 핵심 고객 계정. 시스템이 결코 내릴 자격이 없었음에도 불구하고, 아무도 알아차리기 전에 대규모로 실행되어 버린 판단 (Judgment call).

비용은 오류의 횟수에 있지 않습니다. 어떤 종류의 오류인가에 달려 있습니다.

정직한 태도

80%는 무자비하게 자동화하십시오. 시니어들을 그 업무로부터 완전히 해방시키십시오.

그다음 더 어려운 일을 하십시오. 20%가 시작되는 경계선을 찾고, 정확히 그 경계선에서 이미 맥락 (Context)이 수집되고 의사결정 프레임이 짜여진 상태로 인간을 호출하도록 스택 (Stack)을 구축하십시오.

목표는 시니어를 자동화로 없애는 것이 아닙니다. 시니어가 실제로 자신의 몫인 20%에만 집중하게 하고, 그 과정에서 결코 건너뛰어지지 않도록 보장하는 것입니다.

이를 제대로 수행하는 팀은 조직도상으로는 더 느려 보이지만, 프로덕션 (Production) 환경에서는 훨씬 안전합니다. 완전히 자율적인 것처럼 보이기 위해 20%까지 자동화하는 팀은, 단 하나의 예외 상황만으로도 프로젝트를 끝장낼 사고 (Incident)를 맞이하게 됩니다.

이 글이 당신에게 제공하지 않는 것

저는 고객 프로젝트에서 이러한 '경계선 버전'을 실행합니다. 특정 스택에서 20%가 정확히 어디서 시작되는지, 워크플로우가 판단의 영역으로 넘어갔음을 어떻게 강제로 인식하게 할 것인지, 그리고 적절한 시니어가 적절한 의사결정에 투입되도록 하는 에스컬레이션 (Escalation) 방법이 제가 감사 (Audit)를 통해 제공하는 핵심입니다.

저는 그것들을 여기에 붙여넣지 않을 것이며, 그 이유는 솔직합니다. 그 경계선은 각 회사의 리스크(Risk)에 따라 구체적으로 달라지며, 복사된 레시피는 팀이 경계선을 올바르게 그었음에도 불구하고 그렇지 않다는 잘못된 자신감을 심어줄 수 있기 때문입니다.

그 경계선을 잘못 긋는 것이 실패입니다. 규율(Discipline)은 그것을 올바르게 긋는 데 있습니다.

당신을 위한 질문 하나

당신의 자동화(Automation)를 살펴보십시오.

자동화가 인간에게 묻는 것을 멈추고 스스로 결정을 내리기 시작하는 지점을 찾아, 그 경계선이 의도적으로 그어진 것인지 아니면 우연히 그어진 것인지 자문해 보십시오.

만약 그것이 우연히 그어진 것이라면, 어떤 종류의 결정이 잘못된 쪽에 놓여 있는지 댓글로 알려주십시오. 그 결정이 당신의 80%에 속하는지 아니면 20%에 속하는지 확인하기 위해 제가 가장 먼저 던질 질문을 답글로 남겨드리겠습니다.