나는 내 제품들을 위한 리스팅 생성 워크플로우 (listing-creation workflow)를 구축하는 데 한 달의 대부분을 보냈고, 실제 문제가 무엇인지 인정하기 전까지 네 번이나 다시 만들었다. 문제는 내 리스팅 형식이 매주 바뀌고 있었다는 것이다. 나는 프로세스를 자동화하고 있었던 것이 아니다. 나는 움직이는 목표 (moving target)를 자동화하고 있었으며, 이는 자동화가 실행될 때마다 사후에 별도의 수동 수정이 필요함을 의미했다. 이는 애초에 그냥 손으로 직접 하는 것보다 더 나쁜 상황이었다. 나는 결국 그 워크플로우를 폐기했고, 형식이 진정으로 바뀌지 않을 때까지 6주 동안 리스팅을 수동으로 진행했다. 그 후에야 비로소 자동화할 수 있는 안정적인 무언가가 생겼기에, 단 한 오후 만에 제대로 된 워크플로우를 다시 구축할 수 있었다.

직원 대신 에이전트 (agents)를 사용하여 회사를 운영하면 자동화가 공짜처럼 느껴진다. 하지만 그렇지 않다. 당신이 구축하는 모든 워크플로우는 이제 당신이 소유하게 된 작은 시스템이다. 그것은 고장 날 수 있고, 표류할 수 있으며, 조용히 당신을 잘못된 길로 인도할 수 있다. 그리고 그것이 발생했을 때 누군가는 알아차려야 한다. 그 누군가는 여전히 당신이다. 진짜 기술은 자동화할 것을 찾는 것이 아니다. 어떤 것이 수동으로 하는 것보다 자동화하는 데 더 많은 비용이 들지 일찍 알아차리는 것이다. 여기 계속해서 나타나는 6가지 구체적인 형태가 있다.

1. 반복 작업의 가면을 쓴 일회성 작업

어떤 작업들은 실제로 다시 발생할 것이기 때문이 아니라, 단지 짜증스럽기 때문에 다시 일어날 것처럼 느껴진다. 나 자신도 돌이켜보면 단 한두 번만 하면 될 일들—특정한 일회성 서류 제출, 단 한 번의 공급업체 협상, 딱 한 번의 특정 대상에게만 필요한 보고서—에 대해 워크플로우를 구축하기 시작하는 것을 발견하곤 했다. 판단 기준은 스스로에게 솔직하게

어떤 작업들은 실행(execution)처럼 보이지만, 실제로는 실행의 옷을 입고 있는 판단(judgment)인 경우가 있다. 내가 가진 가장 명확한 예시는 최종적인 창의적 취향(creative taste)의 결정이다. 브랜드 보이스의 변질(Brand voice drift)은 누적되며 개별적인 결정 하나하나에서는 거의 보이지 않는다. 약간 어긋난 캡션 하나, 약간은 평범한 제품 설명 하나가 쌓여, 결국 브랜드가 더 이상 브랜드답지 않게 들릴 때까지 소리 없이 복리로 쌓인다. 에이전트(Agent)가 열 가지 변형안을 초안으로 작성하고 명시된 루브릭(rubric)에 따라 순위를 매길 수는 있지만, "이것이 바로 우리다운 것이다"라고 결정하는 실제 과정은 업무의 전 단계가 아니라 업무 그 자체이다. 그 단계를 자동화하는 것은 실제 업무 시간을 절약해 주는 것이 아니라, 실제 업무를 그것과 닮은 무언가로 대체해 버리는 것이다.

내가 겪은 함정: 나는 파트너 이메일의 반자동(semi-automated) 버전을 발송한 적이 있는데, 사실관계는 완벽했지만 관계 측면에서는 눈치가 없었다(relationally tone-deaf). 이메일의 모든 사실은 정확했지만, 이를 복구하기 위해 소모된 신뢰(goodwill)의 비용이 그 분기에 완전 자동화된 수백 개의 작업을 통해 절약한 시간보다 더 컸다. 이 경험을 통해 관계의 중요성(relationship weight)은 사후 고려 사항이 아니라, 최우선적인 필터 질문(first-class filter question)이 되어야 한다는 확신을 얻었다.

3. 틀렸을 때 비용이 많이 들고 쉽게 확인할 수 없는 모든 것

이것은 조용한 실패다. 왜냐하면 요란하게 실패하지 않기 때문이다. 나는 한때 데이터 입력(data-entry) 작업을 자동화하면서 그 결과물을 점검(spot-check)할 빠른 방법을 구축하지 않았다. 오류는 내가 알아차리기 전까지 한 달 동안 보이지 않게 쌓였다. 여기서 얻은 교훈은 다음과 같다: 만약 결과물을 검증하는 것이 직접 작업을 수행하는 것보다 빠르지 않다면, 당신은 작업을 자동화한 것이 아니라 리스크(risk)를 자동화한 것이다. 저렴한 검증(cheap verification)이 없는 자동화는 지름길이 아니라, 금액을 알 수 없는 청구서가 나중에 날아오는 것과 같다.

이제 내가 명시적으로 던지는 필터 질문은 다음과 같다: "이 결과물을 직접 수행하는 것보다 유의미하게 적은 시간 안에 확인할 수 있는가?" 만약 확인하는 데 걸리는 시간이 직접 수행하는 시간과 같다면, 자동화는 절약이 아니라 단계를 하나 더 추가하는 것에 불과하다.

4. 관계에 결정적인 커뮤니케이션

일부 거래 상대방은 그것이 정말 당신이 아니라는 것을 알아차릴 수 있으며, 그들에게는 반드시 당신이어야 한다는 점이 매우 중요합니다. 도매 파트너는 알아차립니다. 오래된 고객은 알아차립니다. 이것들은 단순히 내용이 정확해야 하는 작업이 아닙니다. 메시지의 출처 (source) 자체가 메시지의 일부가 되는 경우입니다. 저는 이러한 이유로 명시적인 "의도적인 수동 작업 (manual on purpose)" 목록을 작성해 두며, 주요 관계 형성 대화는 이 목록에 영구적으로 포함되어 있습니다. 이는 에이전트 (agent)가 설득력 있는 텍스트를 초안할 수 없어서가 아니라, 상호작용의 가치 중 일부가 "이 사람이 시간을 들였다"는 점에 있기 때문입니다. 그리고 그 가치는, 실제로 인위적으로 만들어졌는지 여부와 상관없이 인위적인 것으로 감지되는 순간 증발해 버립니다.

5. 수행할 때마다 입력값의 형태가 변하는 모든 것

자동화는 입력값의 형태가 안정적이고 반복 가능하다고 가정합니다. 근본적인 프로세스가 여전히 진화 중일 때 — 필드가 바뀌는 양식, 여전히 반복 개선 중인 리스팅 형식, 지난 세 번 동안 매번 다르게 수행했던 워크플로우 (workflow) — 이를 자동화한다는 것은 끊임없이 재구축해야 함을 의미하며, 매번 재구축하는 비용이 수동으로 처리하는 비용보다 더 많이 듭니다. 저의 현재 규칙은 이렇습니다: 지루해질 때까지 작업을 수동으로 수행하십시오. 지루하다는 것은 안정적이라는 뜻입니다. 만약 수동으로 네 번째 실행을 하면서도 여전히 새로운 예외 케이스 (edge cases)를 발견하고 있다면, 당신은 아직 프로세스를 가진 것이 아니라 실험을 하고 있는 것입니다. 그리고 실험은 자동화하는 것이 아니라, 먼저 결론을 내야 하는 것입니다.

6. 실제로 읽지도 않는 허영심을 위한 자동화

이것은 가장 창피한 이유입니다. 왜냐하면 이는 작업에 대한 판단의 실패가 아니라, 자동화가 더 이상 제 역할을 하지 못하고 있다는 사실을 알아차리지 못한 실패이기 때문입니다. "변화 없음"과 "새로운 내용"을 구분하지 않고 매일 똑같은 40개의 항목을 보고하는 루틴은, 불과 몇 주 안에 당신이 그 보고서를 읽지 않도록 길들입니다. 그 시점에서는 아무것도 자동화하고 있는 것이 아닙니다. 그것은 실제로 아무것도 관찰되지 않는데도 불구하고, 무언가가 모니터링되고 있다는 기분을 느끼게 하기 위해 존재하는 보고서를 생성하고 있을 뿐입니다. 왜냐하면 그것을 읽어야 할 유일한 사람이 읽기를 그만두었기 때문입니다.

해결책은 복잡하지 않습니다. 모든 반복되는 루틴은 차이점 기반 (diff-based)이어야 하며, 새로운 내용이 없을 때는 어제의 목록을 조용히 반복하는 대신 명시적으로 "새로운 내용 없음"이라고 말해야 합니다. "어제 이후 2개 신규"라고 알려주는 루틴은 몇 달 동안 읽힙니다. 매일 아침 똑같은 40개의 행을 쏟아내는 루틴은 2주 안에 무시됩니다. 그리고 무시되는 자동화는 자동화가 없는 것보다 더 나쁩니다. 왜냐하면 아무것도 다뤄지지 않고 있음에도 불구하고 무언가가 처리되고 있다는 잘못된 확신을 심어주기 때문입니다.

영향 (Impact): 무엇인가를 구축하기 전에 정직한 필터를 실행하는 것은, 구축 시간을 단 한 시간도 쓰기 전에 제 자동화 아이디어의 약 3분의 1을 제거합니다. 이는 결국 썩어 없어졌을 워크플로우 (workflow)에 쓰이지 않은 연간 실제 시간이며, 제가 뒤늦게 잡아낸 아슬아슬한 사례들(불안정한 리스팅 재구축, 눈치 없는 파트너 이메일)은 제가 자동화하지 않기로 선택한 것들이 제가 구축한 여러 가지들보다 더 많은 가치를 보호했음을 시사합니다.

필터의 실제 적용

이제 저는 무엇인가를 구축하기 전에, 워크플로우 로직 (workflow logic)을 한 줄이라도 쓰기 전, 다섯 가지 질문을 소리 내어 정직하게 던져봅:

[작업명]에 대한 자동화 결정 검토. 정직하게 답하세요:
1) 향후 12개월 동안 예상되는 반복 횟수는?
2) 지난 3회의 수동 실행 동안 프로세스가 동일했는가?
...

"가장자리만 자동화하라 (automate edges only)"라는 답변은 제가 가장 적게 과소평가하고 가장 가치 있게 여기는 답변입니다. 제가 '의도적으로 수동으로 유지하는 목록'에 있는 대부분의 작업은 실제로 완전히 수동인 것은 아닙니다. 에이전트 (Agent)가 여전히 조사를 취합하고, 초안을 작성하며, 증거를 정리합니다. 하지만 에이전트가 하지 않는 것은 최종 결정을 내리거나, 관계나 법적 결과가 진정으로 '나'인지 여부에 달려 있는 자리에 앉는 것입니다. 법적 분쟁은 이 사례의 가장 명확한 버전입니다. 에이전트가 타임라인을 구축하고, 증거를 수집하며, 수치를 초안할 수는 있지만, 전략과 모든 제출물은 언제나 인간의 몫으로 남습니다.

실행할 가치가 있는 워크플로우 (Workflow)의 수는 "가능한 한 많이"가 아닙니다. 그것은 그 유지보수가 별도의 업무가 되지 않으면서 정기적으로 실제로 감사 (Audit)할 수 있는 수입니다. 그 숫자를 넘어서면 올바른 조치는 추가가 아니라 가지치기 (Pruning)입니다. 그리고 위의 6가지 패턴은 제가 일주일 내내 그것을 구축하기 전에, 어떤 후보가 결국 가지치기 목록에 올라가게 될지를 식별하는 제가 발견한 가장 빠른 방법입니다.

원문 게시지: https://methezone.github.io/solo-operator-playbook/when-not-to-automate.html

30개의 모든 워크플로우는 프롬프트 (Prompt) 및 실패 사례와 함께 작성되었습니다. 5개는 전체 내용을 무료로 제공합니다: 샘플러 (the sampler).