WSDL 프레임워크로 자동화할 일을 고르는 법

자동화의 첫 번째 적은 '귀찮음'이 아니다

자동화를 시작하는 사람은 대개 이렇게 말한다.

"이 일 너무 귀찮은데 자동화할 수 없을까?"

틀린 출발은 아니다. 귀찮음은 좋은 신호다. 반복되고 있다는 뜻이고, 에너지를 갉아먹고 있다는 뜻이다. 하지만 귀찮다는 이유만으로 자동화하면 금방 함정에 빠진다. 하루에 3분 걸리는 일을 자동화하겠다며 5시간을 쓰고, 정작 매출에 영향을 주는 일은 계속 수작업으로 남겨두는 식이다.

1인 기업에서 자동화는 장난감이 아니다. 시간을 아껴주는 편리한 도구이기도 하지만, 더 근본적으로는 회사를 굴러가게 하는 운영 체계다. 그래서 질문을 바꿔야 한다.

"이 일을 자동화할 수 있을까?"가 아니라 "이 일을 자동화할 가치가 있을까?"

이 장에서 다룰 WSDL 프레임워크는 바로 이 질문에 답하기 위한 도구다. WSDL은 다음 네 가지 기준의 앞글자를 딴 것이다.

• Worth: 이 일이 자동화할 만큼 가치 있는가?

• Stable: 이 일의 패턴은 충분히 안정적인가?

• Defined: 입력, 출력, 예외, 성공 조건이 명확한가?

• Leverage: 한 번 만들면 여러 번, 여러 곳에 재사용되는가?

n8n을 잘 쓰는 사람과 그렇지 않은 사람의 차이는 노드를 얼마나 많이 아느냐가 아니다. 무엇을 자동화하고 무엇을 그냥 둘지 판단하는 능력에서 갈린다. 자동화의 실패는 대부분 기술 부족에서 시작되지 않는다. 자동화하면 안 되는 일을 너무 일찍 자동화하는 데서 시작된다.

자동화하면 안 되는 일을 먼저 자동화할 때 벌어지는 일

상상해보자. 당신은 새로 만든 SaaS의 고객 온보딩 과정을 자동화하려고 한다. 신규 가입자가 들어오면 환영 메일을 보내고, 3일 뒤 기능 소개 메일을 보내고, 7일 뒤 사용 여부를 확인해 슬랙으로 알림을 받는 구조를 n8n으로 만들었다. 꽤 멋지다.

그런데 문제가 생긴다. 아직 고객이 어떤 기능에서 가치를 느끼는지 모른다. 가입자는 많지 않고, 온보딩 메시지도 매주 바뀐다. 어떤 고객은 무료 체험을 신청하고, 어떤 고객은 데모 상담을 원하고, 어떤 고객은 그냥 가격표만 보고 나간다. 이 상태에서 복잡한 자동화부터 만들어버리면 어떻게 될까?

며칠 뒤 당신은 자동화를 고치는 데 더 많은 시간을 쓰게 된다. 메일 문구가 바뀔 때마다 워크플로우를 수정하고, 조건 분기가 늘어나고, 예외 상황이 쌓인다. 자동화는 시간을 줄여주는 대신 새로운 관리 업무가 된다.

이것이 '너무 이른 자동화'의 전형적인 모습이다.

반대로 자동화가 늦어도 문제다. 매일 아침 결제 내역을 확인하고, 고객 이메일을 복사해 스프레드시트에 붙여넣고, 환영 메일을 직접 보내고, 슬랙에 알림을 남긴다. 이 일은 이미 패턴이 고정되어 있고, 실수하면 고객 경험에 영향을 준다. 그런데도 "나중에 자동화해야지"라고 미루면 당신의 하루는 점점 운영 잡무에 잠식된다.

그래서 필요한 것이 기준이다. 자동화는 감으로 결정하면 안 된다. 특히 혼자 일하는 사람은 더 그렇다. 당신의 하루 1시간은 단순한 1시간이 아니다. 제품을 개선할 시간이고, 고객을 만날 시간이며, 콘텐츠를 만들 시간이고, 다음 매출을 여는 시간이다.

WSDL: 자동화 후보를 걸러내는 네 개의 문

WSDL은 자동화 후보가 통과해야 할 네 개의 문이다. 네 문을 모두 높은 점수로 통과하는 일은 우선 자동화해야 한다. 반대로 하나라도 심하게 낮은 일은 당장 자동화하지 않는 편이 낫다.

이 프레임워크의 장점은 단순하다. 복잡한 기술 지식이 없어도 업무를 평가할 수 있다. "이 노드를 써야 하나?"라고 묻기 전에 "이 업무는 자동화할 만한가?"를 먼저 판단하게 해준다.

아래 네 가지 기준을 하나씩 살펴보자.

Worth: 자동화할 만큼 가치 있는 일인가

Worth는 자동화의 경제성을 묻는 기준이다. 이 일이 자동화되면 무엇이 좋아지는가? 시간이 줄어드는가? 매출이 늘어나는가? 비용이 줄어드는가? 고객 경험이 좋아지는가? 의사결정이 빨라지는가?

여기서 중요한 점은 '시간 절약'만 보지 않는 것이다. 많은 사람이 자동화를 시간 절약 도구로만 생각한다. 물론 시간은 중요하다. 하지만 1인 회사에서 더 중요한 자동화도 있다. 당장 시간이 크게 줄지는 않아도 매출 기회를 놓치지 않게 해주는 자동화, 고객 불만을 줄이는 자동화, 늦은 의사결정을 빠르게 바꾸는 자동화가 그렇다.

예를 들어 결제 실패 고객에게 자동으로 안내 메일을 보내는 워크플로우를 생각해보자. 수작업으로 해도 하루에 10분이면 될 수 있다. 시간 절약만 보면 크지 않다. 하지만 결제 실패를 방치하면 매출이 새어나간다. 이 자동화의 Worth는 시간 절약이 아니라 매출 회복에 있다.

고객 문의 자동 분류도 마찬가지다. 처음에는 문의 수가 많지 않아 보일 수 있다. 하지만 중요한 고객의 불만이 받은편지함 아래쪽에 묻힌다면 비용은 훨씬 커진다. 단순 반복 업무처럼 보이지 않아도 고객 경험에 직접 연결된다면 Worth는 높다.

Worth를 판단할 때는 다음 네 축을 보면 된다.

• 매출 영향: 더 많은 리드, 더 높은 전환율, 이탈 방지, 결제 회복에 연결되는가?

• 비용 절감: 외주비, 도구 비용, 반복 노동 시간을 줄이는가?

• 고객 경험: 응답 속도, 정확성, 개인화, 신뢰도에 영향을 주는가?

• 의사결정 속도: 중요한 데이터를 더 빨리 보고 판단하게 해주는가?

여기서 흔한 실수는 '내가 하기 싫은 일'과 '회사가 좋아지는 일'을 혼동하는 것이다. 하기 싫은 일이라고 해서 모두 가치 있는 자동화는 아니다. 반대로 별로 귀찮지 않은 일이라도 회사의 병목이라면 자동화할 가치가 크다.

예를 들어 매주 금요일에 매출, 가입자 수, 활성 사용자, 광고비, 서버 비용을 모아 보는 일은 귀찮지만 참을 만할 수 있다. 그러나 이 숫자들이 늦게 보이면 의사결정도 늦어진다. 광고비가 새고 있어도 일주일 뒤에야 알아차리고, 특정 콘텐츠에서 가입자가 몰려와도 다음 액션이 늦어진다. 이 경우 대시보드 자동화의 Worth는 매우 높다.

Worth 점수를 매길 때는 이렇게 생각하면 쉽다.

Worth가 낮은 일은 미뤄도 된다. 멋진 자동화가 될 수는 있어도 지금 필요한 자동화는 아닐 가능성이 높다.

Stable: 반복 패턴이 안정적인가

Stable은 업무의 형태가 얼마나 고정되어 있는지 보는 기준이다. 자동화는 반복되는 패턴 위에서 힘을 발휘한다. 반대로 패턴이 계속 바뀌는 일은 자동화할수록 유지보수 비용이 커진다.

예를 들어 매일 오전 9시에 전날의 신규 가입자 수, 결제 수, 취소 수를 가져와 슬랙에 요약하는 일은 안정적이다. 데이터 출처가 정해져 있고, 실행 시간도 정해져 있으며, 결과 형식도 크게 바뀌지 않는다.

반면 아직 실험 중인 영업 프로세스는 안정적이지 않을 수 있다. 오늘은 무료 상담으로 유도하고, 다음 주에는 웨비나 신청으로 바꾸고, 그다음 주에는 가격 할인 캠페인을 테스트한다면 자동화보다 수동 운영이 낫다. 이 단계에서는 빠르게 배우는 것이 목적이지, 흐름을 고정하는 것이 목적이 아니기 때문이다.

많은 1인 창업자가 여기서 실수한다. 실험해야 할 일을 시스템화하려 한다. 아직 답을 찾지 못한 상태에서 워크플로우를 만들면, 자동화는 학습 속도를 높이는 대신 변화를 막는 족쇄가 된다. 버튼 하나로 바꿀 수 있는 것처럼 보여도, 조건 분기와 데이터 구조와 알림 문구가 얽히기 시작하면 수정이 부담스러워진다.

Stable을 판단할 때는 '최근 2주 동안 이 업무가 얼마나 바뀌었는가'를 보면 좋다. 매일 방식이 바뀐다면 낮은 점수다. 가끔 문구나 세부 조건은 바뀌지만 큰 흐름이 유지된다면 중간 점수다. 몇 주째 같은 방식으로 반복되고 있다면 높은 점수다.

Stable 점수는 이렇게 매길 수 있다.

여기서 중요한 원칙이 있다. 불안정한 업무는 자동화하지 말고 기록하라.

업무가 아직 흔들리고 있다면 n8n 워크플로우를 만들기 전에 체크리스트, 스프레드시트, 간단한 문서로 먼저 정리하자. 수동으로 5번, 10번 반복해보면 패턴이 보인다. 그때 자동화해도 늦지 않다. 오히려 그때가 가장 빠른 길이다.

Defined: 입력, 출력, 예외, 성공 조건이 명확한가

Defined는 자동화 설계의 선명도를 묻는 기준이다. 컴퓨터는 애매한 지시를 싫어한다. AI가 들어와도 마찬가지다. AI는 애매한 일을 그럴듯하게 처리할 수는 있지만, 운영 시스템에서는 '그럴듯함'이 위험이 되기도 한다.

자동화할 업무는 최소한 네 가지가 분명해야 한다.

• 입력: 무엇을 받아서 시작하는가?

• 출력: 어떤 결과물을 만들어야 하는가?

• 예외: 어떤 경우에 멈추거나 사람에게 넘겨야 하는가?

• 성공 조건: 제대로 처리되었는지 어떻게 판단하는가?

예를 들어 "고객 문의를 자동화하고 싶다"는 Defined가 낮은 표현이다. 무엇을 자동화한다는 뜻인지 불명확하다. 문의를 읽는 것인가, 분류하는 것인가, 답변 초안을 쓰는 것인가, 실제 발송까지 하는 것인가?

이를 Defined가 높은 형태로 바꾸면 이렇게 된다.

"고객 문의 이메일이 들어오면 본문을 읽고 '결제', '버그', '기능 요청', '일반 문의' 중 하나로 분류한다. 결제와 버그는 슬랙의 운영 채널에 알리고, 기능 요청은 Notion 데이터베이스에 저장한다. AI가 답변 초안을 만들되, 실제 발송은 사람이 승인한 뒤 진행한다. 분류 신뢰도가 낮거나 환불, 법적 이슈, 개인정보가 포함된 경우에는 자동 답변하지 않고 사람에게 넘긴다."

이제 워크플로우가 보인다. 트리거는 이메일 수신이다. 입력은 이메일 제목, 본문, 발신자 정보다. 출력은 분류 결과, 저장 기록, 슬랙 알림, 답변 초안이다. 예외는 환불, 법적 이슈, 개인정보, 낮은 신뢰도다. 성공 조건은 문의가 적절한 채널에 기록되고 사람이 검토할 수 있는 상태가 되는 것이다.

Defined가 낮은 자동화는 만들다가 막힌다. 처음에는 간단해 보이지만 중간에 질문이 쏟아진다. "이런 경우는 어떻게 하지?", "결과는 어디에 저장하지?", "실패하면 누가 알지?", "AI 답변이 틀리면 어떻게 하지?" 같은 질문이 뒤늦게 나타난다.

Defined 점수는 이렇게 매긴다.

Defined를 높이는 가장 좋은 방법은 문장을 구체화하는 것이다. "콘텐츠 자동화"라고 쓰지 말고 "블로그 글 URL을 입력하면 핵심 내용을 요약하고, X용 5개 포스트와 링크드인용 1개 게시글 초안을 생성해 검수용 문서에 저장한다"라고 써야 한다. 자동화는 명사가 아니라 동사와 조건으로 정의해야 한다.

Leverage: 한 번 만들면 여러 번 쓰이는가

Leverage는 자동화의 재사용성을 보는 기준이다. 1인 회사에서는 한 번 만든 워크플로우가 여러 고객, 여러 채널, 여러 제품에 쓰일수록 강력하다. 같은 3시간을 들여 자동화를 만들더라도 한 번만 쓰고 끝나는 것과 매일, 매주, 여러 영역에서 반복 사용되는 것은 가치가 완전히 다르다.

예를 들어 특정 캠페인 하나만을 위해 만든 일회성 데이터 정리 워크플로우는 Leverage가 낮다. 물론 필요할 수는 있다. 하지만 우선순위가 높지는 않다. 반면 '폼 제출 → CRM 저장 → 슬랙 알림 → 이메일 발송 → 태그 분류' 구조는 여러 곳에 재사용할 수 있다. 뉴스레터 신청, 웨비나 신청, 무료 상담 신청, 베타테스터 모집에 모두 응용된다.

Leverage가 높은 자동화는 회사의 부품이 된다. 처음에는 하나의 워크플로우였지만, 시간이 지나면 여러 시스템의 기본 모듈처럼 쓰인다. 콘텐츠 요약 모듈, 고객 분류 모듈, 결제 알림 모듈, 리포트 생성 모듈, 에러 알림 모듈이 쌓이면 당신은 매번 처음부터 만들지 않아도 된다. 필요한 곳에 붙이고 조금만 고치면 된다.

n8n에서 Leverage를 높이는 핵심은 '특정 상황에만 맞춘 자동화'보다 '패턴을 재사용할 수 있는 자동화'를 먼저 만드는 것이다. 예를 들어 "5월 할인 이벤트 신청자를 처리하는 워크플로우"보다 "모든 신청 폼 데이터를 받아 태그를 붙이고 후속 액션을 실행하는 워크플로우"가 더 좋은 자산이다.

Leverage 점수는 이렇게 매긴다.

Leverage는 특히 초반 자동화 우선순위를 정할 때 중요하다. 처음부터 거대한 시스템을 만들 필요는 없다. 다만 작은 자동화라도 나중에 다른 자동화의 재료가 되게 만들어야 한다. 이것이 1인 회사가 시간이 갈수록 더 빨라지는 방식이다.

WSDL 점수표 만들기

이제 네 기준을 합쳐 점수표를 만들어보자. 각 업무 후보에 대해 Worth, Stable, Defined, Leverage를 1점부터 5점까지 매긴다. 총점은 20점 만점이다.

점수표에서 중요한 것은 총점만이 아니다. 네 기준 중 어디가 낮은지를 봐야 한다. 총점이 15점이어도 Defined가 1점이면 바로 만들면 안 된다. 먼저 입출력과 예외 조건을 정리해야 한다. Worth가 1점인데 다른 점수가 높다면 만들기는 쉽겠지만 사업적 효과가 낮다. Stable이 1점이면 자동화보다 실험이 먼저다.

실무에서는 다음 기준으로 판단하면 충분하다.

다만 예외가 있다. 총점이 낮아도 위험을 줄이기 위한 자동화는 먼저 만들 수 있다. 예를 들어 서버 다운 알림, 결제 오류 알림, 보안 이벤트 알림은 자주 발생하지 않아도 놓쳤을 때 손실이 크다. 이런 자동화는 빈도보다 리스크를 기준으로 판단해야 한다.

자동화 우선순위 매트릭스 그리기

점수표가 후보를 평가하는 도구라면, 우선순위 매트릭스는 실행 순서를 정하는 도구다. WSDL 총점이 높아도 구축 난이도가 너무 높으면 첫 자동화로 적합하지 않을 수 있다. 반대로 점수는 중간이지만 30분 만에 만들 수 있고 즉시 효과가 나는 자동화라면 먼저 해볼 만하다.

매트릭스는 두 축으로 그리면 된다. 세로축은 사업 영향도, 가로축은 구현 난이도다.

처음 n8n을 도입하는 1인 창업자라면 '영향도 높음 · 난이도 낮음' 영역을 먼저 공략해야 한다. 이 영역에서 작은 승리를 경험하면 자동화 감각이 생긴다. 그리고 그 작은 자동화들이 나중에 더 큰 시스템의 기반이 된다.

예를 들어 다음과 같은 자동화는 초반 후보로 좋다.

• 신규 가입자나 문의가 들어오면 슬랙으로 알림 받기

• 결제 성공 또는 실패 이벤트를 스프레드시트나 데이터베이스에 기록하기

• 매일 아침 핵심 지표를 요약해 이메일이나 슬랙으로 받기

• 블로그 글을 입력하면 SNS 게시글 초안을 생성해 검수 문서에 저장하기

• 고객 피드백을 유형별로 분류해 한곳에 모으기

반대로 첫 자동화로 피해야 할 것도 있다. 예를 들어 "고객 문의를 AI가 완전히 처리하고 자동으로 답변 발송까지 하게 만들기"는 매력적이지만 위험하다. 분류, 초안 생성, 사람 승인, 발송 기록, 예외 처리까지 모두 필요하기 때문이다. 처음에는 "AI가 답변 초안만 만들고 사람에게 넘긴다" 정도로 시작하는 편이 좋다.

자동화는 한 번에 회사를 갈아엎는 프로젝트가 아니다. 작은 워크플로우를 만들고, 검증하고, 연결하고, 확장하는 과정이다.

실습: 첫 10개 자동화 후보 정리하기

이제 직접 해보자. 종이나 스프레드시트를 열고, 지금 당신의 업무 중 자동화하고 싶은 후보를 10개 적는다. 너무 거창할 필요는 없다. 오히려 구체적일수록 좋다.

나쁜 예는 이런 식이다.

"마케팅 자동화", "고객관리 자동화", "콘텐츠 자동화", "리포트 자동화".

좋은 예는 이렇게 쓴다.

"뉴스레터 신청자가 생기면 이메일 도구에 구독자로 추가하고 환영 메일을 보낸다."

"Stripe 결제 성공 이벤트가 발생하면 슬랙에 알리고, 고객 정보를 Airtable에 기록한다."

"새 블로그 글 URL을 입력하면 X용 짧은 글 5개와 링크드인 게시글 1개를 생성해 Notion에 저장한다."

"고객 문의 이메일을 읽고 결제, 버그, 기능 요청, 일반 문의로 분류해 각각 다른 채널에 알린다."

아래 표를 복사해 채워보자.

표를 채울 때는 너무 오래 고민하지 말자. 첫 점수는 직감으로 매겨도 된다. 다만 총점이 나온 뒤에는 반드시 낮은 항목을 다시 보아야 한다.

Worth가 낮다면 "이 자동화가 실제로 사업에 어떤 영향을 주는가?"를 묻는다. 대답이 약하면 후순위다.

Stable이 낮다면 "이 업무를 수동으로 몇 번 더 반복해보면 패턴이 보일까?"를 묻는다. 아직 실험 중이면 문서화부터 한다.

Defined가 낮다면 "입력, 출력, 예외, 성공 조건을 한 문단으로 설명할 수 있는가?"를 묻는다. 설명이 안 되면 설계가 덜 된 것이다.

Leverage가 낮다면 "이 구조를 다른 채널, 다른 고객, 다른 제품에도 쓸 수 있게 바꿀 수 있는가?"를 묻는다. 조금만 일반화해도 자동화의 가치가 커진다.

마지막 열의 '다음 행동'에는 네 가지 중 하나를 적는다.

• 자동화: 바로 n8n 워크플로우 설계로 넘어간다.

• 정의 보완: 입출력, 예외, 성공 조건을 더 구체화한다.

• 수동 관찰: 아직 패턴이 불안정하므로 몇 번 더 직접 해본다.

• 보류: 지금은 사업 영향이 작거나 재사용성이 낮다.

이 실습의 목적은 완벽한 계획을 세우는 것이 아니다. 자동화 욕심을 정리하는 것이다. 머릿속에서 "이것도 자동화하고 싶고, 저것도 자동화하고 싶다"가 뒤섞여 있으면 결국 아무것도 제대로 만들지 못한다. 10개를 꺼내놓고 점수를 매기면 무엇부터 해야 할지 보인다.

사례: 콘텐츠 운영자의 WSDL 판단

예를 들어 1인 지식 창업자가 있다고 해보자. 블로그, 뉴스레터, X, 링크드인, 유튜브를 혼자 운영한다. 이 사람의 하루는 콘텐츠 아이디어 찾기, 초안 작성, 편집, 업로드, 댓글 확인, 성과 분석으로 가득하다.

자동화하고 싶은 것은 많다. 하지만 모두 한 번에 자동화하면 실패한다. WSDL로 걸러보자.

"블로그 글을 여러 SNS 형식으로 변환하는 자동화"는 Worth가 높다. 같은 원본 콘텐츠를 여러 채널에 활용하므로 시간 절약과 노출 증가에 모두 연결된다. Stable도 높다. 블로그 글을 쓰고, SNS 글로 변환하고, 검수 후 게시하는 패턴이 반복된다. Defined도 비교적 높다. 입력은 블로그 글 URL 또는 본문이고, 출력은 채널별 초안이다. Leverage도 높다. 모든 글에 반복 적용할 수 있다.

반면 "AI가 완전히 새로운 콘텐츠 전략을 매일 자동으로 결정하는 시스템"은 매력적이지만 당장 만들기 어렵다. Worth는 높을 수 있으나 Stable과 Defined가 낮다. 전략은 아직 사람의 판단과 실험이 많이 필요한 영역이다. 이 경우에는 완전 자동화보다 '검색 트렌드와 경쟁 콘텐츠를 모아 후보 주제를 추천하는 워크플로우'가 더 현실적이다.

또 다른 후보로 "댓글에 AI가 자동 답글을 다는 워크플로우"를 생각해보자. 겉보기에는 편하다. 하지만 브랜드 톤, 민감한 질문, 악성 댓글, 구매 문의, 개인정보 이슈가 섞인다. Defined와 예외 처리가 충분하지 않으면 위험하다. 이 경우 첫 단계는 자동 답글 발송이 아니라 '댓글을 수집하고 유형별로 분류한 뒤 답글 초안을 만들어 검수함에 넣는 것'이다.

이처럼 WSDL은 자동화 아이디어를 죽이는 도구가 아니다. 오히려 아이디어를 현실적인 첫 단계로 바꿔준다.

사례: 1인 SaaS 운영자의 WSDL 판단

이번에는 1인 SaaS 운영자를 보자. 이 사람에게 중요한 일은 가입, 활성화, 결제, 고객지원, 장애 대응이다. 하루에 처리할 업무는 많지만, 가장 먼저 자동화해야 할 것은 무엇일까?

"신규 가입자 환영 메일과 7일 후 활성화 체크"는 좋은 후보가 될 가능성이 높다. Worth는 고객 경험과 활성화에 연결된다. Stable은 가입 이벤트와 시간 지연이라는 반복 패턴이 분명하므로 높다. Defined도 비교적 쉽다. 입력은 가입자 정보, 출력은 환영 메일과 7일 후 체크 알림이다. Leverage도 있다. 이후 온보딩 시퀀스, 기능 사용 안내, 결제 전환 캠페인으로 확장할 수 있다.

"이탈 위험 사용자를 자동 감지해 리텐션 캠페인을 실행하는 워크플로우"는 더 고급 자동화다. Worth는 매우 높다. 하지만 Defined가 낮을 수 있다. 무엇을 이탈 위험으로 볼 것인가? 7일 미접속인가, 핵심 기능 미사용인가, 결제 정보 미등록인가, 사용량 급감인가? 이 기준이 없으면 워크플로우를 만들 수 없다. 이 경우 첫 단계는 리텐션 캠페인이 아니라 '이탈 위험 신호를 정의하고 매일 후보 목록을 리포트로 받는 것'이다.

"서버 다운 감지 후 알림"은 어떨까? 빈도는 낮아도 Worth가 높다. 장애를 늦게 알면 신뢰가 무너진다. Stable도 높다. 서비스 상태를 확인하고 실패하면 알림을 보내는 구조는 단순하다. Defined도 명확하다. Leverage는 다른 서비스나 API 모니터링으로 확장할 수 있다. 이런 자동화는 초반에 만들어둘 가치가 크다.

이 사례에서 알 수 있는 것은 분명하다. 같은 SaaS 운영 자동화라도 어떤 것은 바로 만들고, 어떤 것은 기준을 먼저 정의해야 하며, 어떤 것은 아직 수동으로 관찰해야 한다.

자동화 전 반드시 써야 할 한 문장

n8n 캔버스를 열기 전에 반드시 한 문장을 써보자.

"이 워크플로우는 ______가 발생하면, ______를 사용해, ______를 만들고, ______인 경우 사람에게 넘기며, 성공하면 ______ 상태가 된다."

예를 들면 이렇게 된다.

"이 워크플로우는 신규 결제가 발생하면, 결제 이벤트와 고객 정보를 사용해, 슬랙 알림과 고객 DB 기록을 만들고, 금액이 비정상적이거나 고객 이메일이 없을 경우 사람에게 넘기며, 성공하면 결제 내역이 DB에 저장되고 운영 채널에 알림이 남은 상태가 된다."

이 한 문장을 쓸 수 없다면 아직 자동화할 준비가 되지 않은 것이다. 반대로 이 문장이 선명하면 n8n에서 어떤 트리거를 쓰고, 어떤 데이터를 넘기고, 어떤 조건 분기를 만들고, 어디에 결과를 저장해야 할지 자연스럽게 보인다.

이 문장은 작지만 강력하다. 자동화의 목적, 재료, 결과, 예외, 성공 조건을 한 번에 묶어주기 때문이다. 앞으로 실전 워크플로우를 만들 때도 이 문장을 계속 사용할 것이다.

자동화하지 말아야 할 일의 특징

좋은 자동화 후보를 아는 것만큼 중요한 것은 나쁜 후보를 알아보는 것이다. 자동화하지 말아야 할 일에는 공통적인 냄새가 있다.

첫째, 아직 답을 모르는 일이다. 고객이 무엇을 원하는지, 어떤 메시지가 통하는지, 어떤 가격이 적절한지 모르는 상태라면 자동화보다 실험이 먼저다. 자동화는 답을 찾은 뒤 반복을 빠르게 만드는 데 강하다. 답을 찾는 과정 자체를 섣불리 고정하면 배움이 느려진다.

둘째, 예외가 본질인 일이다. 매번 고객 상황이 다르고 판단 기준이 섬세하다면 완전 자동화는 위험하다. 이런 일은 AI가 초안을 만들거나 정보를 정리하는 보조 자동화부터 시작해야 한다. 사람의 판단이 필요한 영역을 억지로 제거하면 고객 경험이 망가진다.

셋째, 실패 비용이 큰데 검증 장치가 없는 일이다. 고객에게 자동으로 메일을 보내거나, 결제를 처리하거나, 데이터를 삭제하거나, 외부에 게시물을 발행하는 일은 신중해야 한다. 자동화는 빠르기 때문에 실수도 빠르게 확산된다. 처음에는 사람 승인 단계를 넣는 것이 안전하다.

넷째, 단지 재미있어 보이는 일이다. 자동화 도구를 배우다 보면 신기한 아이디어가 계속 떠오른다. "AI가 내 하루를 전부 관리해주면 어떨까?", "모든 SNS 댓글에 자동으로 답하면 어떨까?", "경쟁사 글을 읽고 매일 전략을 바꾸면 어떨까?" 이런 상상은 좋다. 하지만 사업의 병목과 연결되지 않으면 취미 프로젝트가 된다.

1인 회사의 자동화는 멋있어 보이는 순서가 아니라 병목을 푸는 순서로 진행해야 한다.

WSDL은 속도를 늦추는 도구가 아니라 낭비를 줄이는 도구다

처음에는 WSDL 점수표가 번거롭게 느껴질 수 있다. 그냥 n8n을 열고 노드를 연결하면 될 것 같은데, 왜 굳이 점수를 매겨야 하나 싶을 것이다.

하지만 이 몇 분이 몇 시간을 아껴준다. 더 정확히는 몇 주짜리 헛수고를 막아준다. 자동화는 만들 때보다 만든 뒤가 중요하다. 운영해야 하고, 고쳐야 하고, 예외를 처리해야 하고, 비즈니스가 바뀌면 수정해야 한다. 가치 없는 자동화는 시간이 지나도 자산이 되지 않는다. 오히려 관리해야 할 짐이 된다.

WSDL은 당신에게 네 가지 질문을 반복해서 던진다.

• 이 일은 정말 사업에 영향을 주는가?

• 이 일은 충분히 반복되고 안정적인가?

• 이 일은 워크플로우로 옮길 만큼 명확한가?

• 이 일은 한 번 만들면 계속 재사용되는가?

이 네 질문에 자신 있게 답할 수 있다면 자동화하라. 아직 답이 흐릿하다면 먼저 관찰하고, 문서화하고, 작게 실험하라.

이제 우리는 무엇을 자동화해야 하는지 고르는 기준을 얻었다. 다음 장부터는 실제로 n8n을 열고 첫 워크플로우를 만들기 시작한다. 하지만 기억하자. 좋은 자동화는 캔버스 위의 첫 노드에서 시작되지 않는다. 자동화할 일을 제대로 고르는 순간 이미 절반은 완성된 것이다.