시나리오가 늘면 비슷한 작업을 여러 곳에서 관리하게 되고, 어디를 고쳐야 할지 찾기 어려워질 수 있습니다. 그렇다고 모든 흐름을 한 시나리오에 넣으면 시작 조건이나 오류 처리 방식이 달라 오히려 복잡해질 수 있습니다. 그래서 합치기 전에 시나리오별 역할과 시작 조건을 나누고, 함께 처리할 작업과 따로 둘 작업을 정해야 합니다. 이 글에서는 한 흐름으로 모으는 방법과 시나리오 호출로 연결하는 방법, 데이터와 오류 처리 기준을 다룹니다. 마지막으로 작은 단위로 옮겨 실행 결과를 비교하는 절차까지 이어서 정리합니다.
합치기 전에 시나리오 역할 나누기
- 시나리오별 시작 조건과 실행 주기를 적습니다.
- 공통으로 하는 작업과 서로 다른 작업을 구분합니다.
- 합치는 목적이 관리 편의인지, 데이터 공유인지 확인합니다.
쉽게 설명하면, 먼저 시나리오마다 맡은 일을 적어보세요. 학교에서 여러 학생이 각자 다른 일을 맡듯, 어떤 시나리오는 정보를 받고 다른 시나리오는 내용을 정리하거나 결과를 보낼 수 있습니다. 맡은 일을 나눠 보면 서로 겹치는 작업과 따로 남겨야 할 작업이 보입니다.
그다음에는 각 시나리오가 언제, 무엇을 계기로 시작하는지 비교합니다. 서로 다른 시간이나 사건에 맞춰 움직인다면, 합친 뒤에도 원래처럼 작동하게 할 방법을 생각해야 합니다. Make에서는 시작 모듈과 실행 방식을 기준으로 흐름을 설계하므로, 사용 중인 트리거와 기능에 따라 가능한 구성이 달라질 수 있습니다.
이렇게 합치는 목적을 먼저 정하면 필요하지 않은 시나리오까지 한곳에 모으는 일을 줄일 수 있습니다. 반대로 서로 다른 작업을 하나로 묶으면 나중에 고칠 때 영향을 받는 부분이 늘어날 수 있으니, 합친 뒤에도 관리하기 쉬울지 함께 생각해 보세요. 역할을 나눴다면 이제 실제로 한 흐름에 모을 작업이 무엇인지 정할 수 있습니다.
한 시나리오 안에 흐름 모으기
- 시작 조건이 같거나 함께 처리해도 되는 작업을 하나의 시나리오에 둡니다.
- 조건에 따라 경로를 나누고, 공통 작업은 가능한 한 재사용합니다.
- 실행 순서와 각 경로의 종료 지점을 확인합니다.
풀어서 설명하면, 시작 조건이 비슷한 시나리오라면 한 흐름으로 모을 수 있습니다. 예를 들어 학교에 들어온 신청서를 받은 뒤, 내용에 따라 담당 선생님에게 보내거나 따로 확인하는 것처럼 조건에 따라 길을 나눌 수 있습니다. 여러 길에서 같은 정리 작업을 한다면, 그 작업을 한곳에 모을 수 있는지도 확인해 보세요.
그런데 갈림길이 많아지면 전체 흐름을 한눈에 보기 어려워질 수 있습니다. 한 길에서 문제가 생겼을 때 다른 길도 멈추는지, 문제가 생긴 작업만 다시 할 수 있는지도 확인해야 합니다.
그래서 시나리오가 너무 길어 보인다면 공통으로 쓰는 시작 단계만 함께 두고, 그다음 작업은 나누는 편이 더 읽기 쉬울 수 있습니다. 어떤 구성이 알맞은지는 작업의 수와 오류 처리 방식에 따라 달라질 수 있으니, 실제 흐름을 그려보고 정하면 좋습니다. 한 흐름으로 모으기 어려운 작업은 기존 시나리오를 유지하면서 서로 연결하는 방법을 검토할 수 있습니다.
호출 구조로 기존 시나리오 연결하기
- 각 시나리오를 독립된 작업 단위로 유지할지 결정합니다.
- 앞단 시나리오가 다음 작업에 전달할 입력값을 정합니다.
- 호출 방식과 지원 조건은 사용 중인 Make 기능에서 확인합니다.
다르게 말하면, 시나리오가 서로 다른 시간이나 사건에 시작된다면 모두 한 흐름에 넣지 않고 따로 유지할 수도 있습니다. 이때 한 시나리오가 다음 시나리오에 일을 부탁하는 방식으로 연결할 수 있습니다. 마치 한 사람이 필요한 내용을 정리해 다른 사람에게 넘기고, 다음 사람이 그 내용을 받아 자기 일을 하는 것과 비슷합니다.
연결하기 전에는 앞 시나리오가 어떤 값을 넘길지, 다음 시나리오가 어떤 결과를 돌려줄지 정해두세요. 그래야 각 시나리오가 맡은 일이 분명해집니다. Make에서 시나리오 간 호출이나 입력·출력을 활용할 수 있는지는 계정 환경과 사용하려는 기능에 따라 확인이 필요합니다.
또한 API를 이용하는 방식은 보통 유료 플랜이 필요할 수 있으므로, 원하는 연결 기능을 사용할 수 있는지와 플랜 조건을 먼저 확인하는 편이 좋습니다. 바로 큰 비용을 들이기보다는 필요한 기능이 포함된 가장 작은 요금제를 선택해 시험해보고, 원하는 결과가 나오는지 확인한 다음 그 솔루션을 사용할지 결정할 수 있습니다. 플랜에 따라 이용할 수 있는 기능이나 사용 한도가 다를 수 있으니, 테스트 전에 해당 조건도 살펴보세요.
필요한 기능을 사용할 수 없다면 웹훅 같은 다른 연결 방식을 검토할 수 있습니다. 다만 연결 방식에 따라 실행되는 시점이나 전달되는 데이터가 달라질 수 있으니, 실제 환경에서 확인하는 편이 좋습니다. 시나리오를 여러 단계로 연결하면 실행 흐름을 찾기 어려워질 수도 있으므로 입력과 출력, 문제가 생겼을 때 확인할 위치를 기록해두세요. 이렇게 연결 방식을 정한 다음에는 주고받는 데이터와 오류 처리 기준도 함께 맞춰야 합니다.
데이터와 오류 처리 정리하기
- 각 단계에서 주고받는 데이터의 이름과 형식을 맞춥니다.
- 값이 비어 있거나 예상과 다를 때의 처리 방식을 정합니다.
- 오류가 발생한 위치와 재실행 범위를 확인합니다.
일상에 빗대어 보면, 시나리오를 연결할 때는 데이터의 이름과 모양도 맞춰야 합니다. 여러 사람이 같은 재료를 요리할 때 재료 이름과 양을 같은 방식으로 적어야 헷갈리지 않는 것과 같습니다. 같은 뜻의 값에 서로 다른 이름을 썼다면, 연결하는 곳에서 어떤 이름을 사용할지 정해두세요.
또 필수값이 비어 있거나 예상과 다른 값이 들어왔을 때 어떻게 할지도 생각해야 합니다. 작업을 멈출지, 대신 쓸 값을 넣을지, 별도의 경로로 보낼지 정하면 다음에 문제가 생겼을 때 어디를 살펴볼지 알기 쉬워집니다.
처음부터 일어날 수 있는 모든 경우를 처리하려고 하면 구조가 복잡해질 수 있습니다. 실제로 들어오는 데이터를 살펴보고 자주 생길 수 있는 상황부터 다루면 시작하기가 수월합니다. 다만 예상하지 못한 형식의 데이터가 들어올 가능성도 있으니, 중요한 작업은 예외가 생겼을 때의 처리 방법을 따로 확인해두면 좋습니다. 데이터와 오류 기준을 정했다면 이제 새 구조를 작은 단위로 옮겨 결과를 비교할 차례입니다.
작은 단위로 옮겨 검증하기
- 원본 시나리오의 실행 결과와 설정을 먼저 확인합니다.
- 공통 작업 한 부분부터 새 구조에 옮깁니다.
- 테스트 후 기존 흐름과 결과를 비교하고, 안정된 다음 전환합니다.
좀 더 쉽게 말하면, 여러 시나리오를 한 번에 바꾸기보다 먼저 공통 작업 하나만 옮겨서 확인해보세요. 한 번에 한 부분씩 옮기면 문제가 생겼을 때 원인을 찾기 쉽습니다. 기존 시나리오를 바로 지우지 않고 남겨두면 새 흐름과 결과를 비교할 수도 있습니다.
그다음에는 정상적인 입력뿐 아니라 값이 빠진 경우나 중간 작업에서 실패하는 경우도 살펴보세요. 실행 결과가 달라지거나 같은 일이 두 번 처리되는지 확인하면, 새 구조가 의도한 대로 움직이는지 판단하는 데 도움이 됩니다.
다만 테스트 데이터가 실제 대상에 반영될 수 있습니다. 특히 정보를 전송하거나 게시하는 작업은 되돌리기 어려울 수 있으니 실행 전에 연결 대상과 설정을 확인하세요. 환경에 따라 테스트 결과가 실제 작업과 다를 수도 있으므로, 전환하기 전에는 실제로 사용할 조건에서도 확인하는 편이 안전합니다. 이런 점검을 마치면 작업에 맞는 구조를 선택하고, 변경 뒤 생길 수 있는 문제를 줄이는 데 도움이 됩니다.
역할에 맞게 나누면 변경이 쉬워집니다
- 먼저 합칠 목적과 시나리오별 역할을 구분합니다.
- 시작 조건이 맞으면 한 흐름으로, 다르면 호출 구조를 검토합니다.
- 데이터 형식과 오류 처리 기준을 정한 뒤 작은 단위로 옮깁니다.
이 기준을 따라가면 모든 시나리오를 무리하게 합치지 않고, 작업에 맞는 구조를 정해 변경 결과를 확인할 수 있습니다. 다음 글에서는 시나리오 사이에 전달할 입력값과 출력값을 정리하는 방법을 다룹니다.