20% automation은 닫을 수 없으며, 그것이 당신에게 보수를 주는 부분이다

Source: Dev.to

A reader asked the sharpest question I have seen this month:

What kind of problems fall into the 20 percent that still needs a senior?

이번 달에 제가 본 가장 날카로운 질문을 한 독자가 있습니다:

여전히 시니어가 필요한 20 %에 해당하는 문제는 어떤 종류인가요?

Most automation pitches answer the opposite. They sell the 80 percent that was always going to work, and they stay quiet about the part that breaks careers.

대부분의 자동화 영업은 반대 입장을 취합니다. 항상 성공할 수밖에 없었던 80 %만을 팔고, 경력을 무너뜨리는 부분에 대해서는 입을 다물죠.

So here is the honest answer, from the enterprise stacks I audit across DACH automation deployments.

따라서 여기, 제가 DACH 지역의 자동화 도입 현장에서 감사한 기업 스택을 바탕으로 드리는 솔직한 답변이 있습니다.

The 80 percent is the easy promise. The 20 percent is the whole engagement.

80 %는 쉬운 약속이고, 20 %가 바로 전체 업무입니다.

실제 80 percent가 의미하는 것

80 percent는 형태가 있는 작업이다.

• 명확한 입력, 알려진 규칙, 예측 가능한 출력.
  Invoice in → line items out.
  Lead in → enrichment out.
  Ticket in → routed ticket out.

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

벤더가 여전히 80 percent 자동화를 어려운 부분이라고 판매한다면, 그들은 어려운 것의 가격에 쉬운 것을 팔고 있는 것이다.

20 percent에 포함된 내용

• 불확실성 하의 판단 – 상황이 새로워서 규칙이 존재하지 않는다. 시스템이 알지 못한 트레이드‑오프를 누군가가 평가해야 한다.
• 실제 영향을 미치는 예외 – 금전, 규제기관, 혹은 수년간 구축된 고객 관계에 영향을 주는 엣지 케이스.
• 데이터베이스가 아닌 머리 속에 존재하는 컨텍스트 – 고객이 예외를 받는 이유, 아무도 기록하지 않은 이력, 어떤 필드도 포착하지 못하는 암묵적 지식.
• 이름이 붙어야 하는 결정 – 문제가 발생했을 때, 책임은 워크플로가 아니라 사람에게 귀속되어야 한다.

각각은 자동화에 “일반 작업”으로 보고되지만, 실제로는 그렇지 않다.

왜 팀은 20 percent를 자동화할까

압박감은 실제이며, 저는 그것을 이해합니다.

80 percent는 자동화되어 있고, 절감 효과가 눈에 보이며, 다음 자연스러운 요구는 나머지를 추진하는 것입니다. 20 percent의 데모는 항상 괜찮아 보이는데, 이는 데모가 happy path를 실행하고, 그 happy path가 80 percent처럼 동작하는 20 percent의 부분이기 때문입니다.

그래서 팀은 이를 배포합니다. 그러고 나서 실제 예외가 도착합니다—돈이 걸린 예외—그리고 자동화는 인보이스를 처리했던 것과 같은 자신감으로 이를 처리합니다.

그 순간은 시니어가 결정을 내려야 했지만 내리지 않은 순간입니다.

그 실패가 초래하는 비용

• 80 %가 실패할 때, 개발자 시간을 잃게 됩니다.
• 20 %가 실패할 때, 재시도해도 돌아오지 않는 것을 잃게 됩니다: 검토 없이 내려진 규제된 결정, 핵심 계정을 일상 티켓처럼 처리한 것, 시스템이 결코 판단할 자격이 없었던 판단을 대규모로 내린 것, 아무도 눈치채기 전에.

비용은 오류 개수에 있는 것이 아니라, 어떤 오류인지에 있습니다.

정직한 자세

• 80 %를 무자비하게 자동화하라. 시니어들을 완전히 해방시켜라.
• 그 다음 더 어려운 작업을 수행하라: 20 %가 시작되는 경계를 찾고, 스택을 구축하여 정확히 그 경계에서 인간에게 호출하도록 하라. 이미 수집된 컨텍스트와 결정이 정리된 상태에서.

목표는 시니어를 자동화해서 없애는 것이 아니다. 시니어가 실제로 자신에게 해당하는 20 %에만 집중하도록 하고, 그 부분에서 절대 우회되지 않도록 하는 것이다.

이를 제대로 구현한 팀은 조직도 상에서는 느리게 보이지만, 실제 운영에서는 훨씬 안전하다. 20 %를 자동화해 완전 자율적인 것처럼 보이게 하는 팀은 프로젝트를 종결시키는 사고가 한 번 발생할 위험이 있다.

이 글이 제공하지 않는 것

저는 고객 프로젝트에서 이의 경계 버전을 실행합니다: 특정 스택에서 20 %가 시작되는 지점을 정확히 찾아내고, 워크플로우가 판단 영역으로 넘어갔음을 인식하도록 강제하며, 올바른 결정을 내릴 수 있는 적절한 시니어에게 에스컬레이션합니다.

여기에 그 세부 사항을 붙여넣지 않는 이유는 솔직합니다. 경계는 각 기업의 위험에 따라 다르며, 복사한 레시피를 사용하면 팀이 올바르게 선을 그렸다고 잘못된 자신감을 갖게 됩니다.

그 선을 잘못 그리는 것이 실패이며, 올바르게 그리는 것이 바로 규율입니다.

당신에게 한 가지 질문

당신의 자동화를 살펴보세요.

인간에게 묻는 것을 멈추고 스스로 판단하기 시작하는 지점을 찾아, 그 경계선이 의도적으로 그려진 것인지 아니면 우연히 그려진 것인지 물어보세요.

만약 우연히 그려진 것이라면, 그 잘못된 쪽에 어떤 종류의 결정이 놓여 있는지 댓글로 알려 주세요. 저는 그것이 당신의 80 %에 속하는지 20 %에 속하는지 알아내기 위해 먼저 할 질문을 답변하겠습니다.