자동화의 역설: 도구가 많을수록 자유가 줄어든다

모든 indie hacker의 꿈은 같다. 전부 자동화하고, 덜 일하고, 더 번다. 실제로 일어나는 일은 이렇다. 2주마다 터지는 취약한 integration 탑을 유지 보수하며 산다.

나도 겪었다. Zapier 15단계 체인. 다른 시나리오를 트리거하는 Make.com 시나리오. 6개 서비스에 흩어진 API 키. webhook 하나 깨지면 재앙.

자동화의 역설은 단순하다. 자동화할수록 유지 보수할 것도 늘어난다.

도구 난립의 숨겨진 비용

새 도구를 추가할 때마다 구독료 외에 추가 비용이 생긴다.

학습 비용: 모든 도구가 다른 멘탈 모델을 요구한다. Zapier는 트리거-액션, Make.com은 비주얼 플로우, n8n은 또 다르다. 이 모든 게 머릿속 공간을 차지한다.

Integration 유지 보수: API는 바뀐다. 서비스는 기능을 deprecated한다. 석 달 전엔 완벽하게 작동하던 자동화가 갑자기 멈춘다. Notion이 또 API를 바꿨기 때문에.

디버깅 지옥: 10단계 자동화에서 뭔가 깨지면 어디서부터 봐야 하나. 에러 메시지는 "7단계에서 실패"라고 하는데 실제 문제는 3단계 출력 형식이다.

수십 개의 자동화를 만들고 절반이 썩어가는 걸 보면서 배운 것들:

표준 인터페이스로 만들어라: webhook과 HTTP API를 써라. 이건 보편적이고 플랫폼보다 오래 산다. Zapier든 bash 스크립트든 curl이든 똑같이 작동해야 한다.

짧게 유지해라: 3단계 자동화는 유지 가능하다. 15단계는 기술 부채다. 너무 복잡하면 별도의 테스트 가능한 조각으로 나눠라.

중요한 경로는 직접 소유해라: 매출과 직결되는 건 코드를 직접 가져라. Zapier가 결제 프로세서와 fulfillment 시스템 사이에 앉아 있게 두지 마라. Node 스크립트 50줄이 낫다.

AI는 이 방정식을 근본적으로 바꾼다. 딱딱한 자동화 체인 대신 의도를 이해하는 agent에게 위임할 수 있다.

예전 방식: "제목에 '긴급'이 포함된 이메일이 오면 빨간 태그 달고, Slack 알림 보내고, Notion 태스크 만들어라."

새로운 방식: "긴급 이메일을 적절히 처리해라."

AI가 문맥상 '긴급'이 뭔지 판단한다. Slack 알림이 필요한지, 기다려도 되는지 결정한다. 이메일 제목을 그대로 복사하는 대신 태스크 설명을 직접 쓴다.

설정하기도 쉽고, 유지 보수하기도 쉽다. 비즈니스가 변하면 instruction만 업데이트하면 된다.

자동화가 목표가 아니다. 자유가 목표다.

최고의 자동화는 설정하고 나서 다시 생각하지 않아도 되는 것이다. 그 말은 이렇다:

한 문장으로 설명할 수 없는 자동화는, 간단하게 고칠 수도 없다.

덜 만들어라. 덜 유지 보수해라. 더 자유로워져라.