Make에서 모듈을 하나씩 연결하다 보면 시나리오가 작동하는 것과 흐름을 이해할 수 있는 것이 다르다는 걸 느낄 때가 있습니다. 처음 만들 때는 눈에 보이는 모듈부터 추가하기 쉽지만, 무엇을 받아서 어떤 기준으로 처리하고 어디에 남길지 정하지 않으면 중간에 구조를 다시 손보게 됩니다. 앞선 글에서는 모바일에서도 파악하기 쉬운 구조와 이름 짓기 원칙을 다뤘고, 이번에는 그 원칙을 실제 설계 순서로 이어 보려 합니다. 입력, 처리, 결과를 나눠 생각하면 시나리오의 시작과 끝이 선명해지고, 각 모듈이 맡을 역할도 정하기 쉬워집니다. 처음부터 복잡한 자동화를 만들기보다 이 세 구간을 차례로 정리하는 방법을 살펴봅니다.
자동화의 시작과 끝을 먼저 정하기
- 어떤 상황에서 시나리오가 시작되는지 정합니다.
- 자동화가 끝났을 때 무엇이 달라져야 하는지 적습니다.
- 입력, 처리, 결과를 한 문장으로 연결합니다.
쉽게 설명하면, 자동화할 일을 시작부터 끝까지 한 문장으로 말해 보는 것입니다. 예를 들어 "새로 접수된 정보를 받아 필요한 항목을 정리한 뒤, 정해 둔 곳에 저장한다"라고 적으면 무엇을 받아서 어디에 남길지 한눈에 볼 수 있습니다. 이 문장은 아직 자세한 설계도는 아니지만, 자동화하려는 일이 무엇인지 확인하는 기준이 됩니다.
여기서 시작 조건은 시나리오가 언제 움직이는지를 뜻합니다. 사람이 직접 실행하는지, 새 데이터가 들어올 때 시작하는지처럼 먼저 정할 수 있습니다. 끝점은 작업이 완료됐다고 판단할 수 있는 상태입니다. 결과가 저장되거나 전달되는 것인지, 아니면 특정한 형식으로 정리되는 것인지 적어 두면 다음 단계의 범위도 좁혀집니다.
물론 시작 조건이나 완료 기준이 애매한 작업도 있습니다. 그럴 때는 자동화할 범위를 작게 잡고, 이번 시나리오가 책임질 부분과 사람이 확인할 부분을 나눠 볼 수 있습니다. 이렇게 경계를 정하면 시나리오의 첫 구간에서 실제로 어떤 데이터를 받아야 할지 살피기 쉬워지고, 다음으로 입력에 필요한 항목을 구체화할 수 있습니다.
입력에서 받을 데이터를 구체화하기
- 데이터가 처음 들어오는 위치를 정합니다.
- 처리에 꼭 필요한 항목과 선택 항목을 구분합니다.
- 비어 있거나 예상과 다른 값이 들어오는 경우를 떠올립니다.
풀어서 설명하면, 입력은 시나리오가 일을 시작할 때 처음 손에 쥐는 정보입니다. 시작점을 정했다면 이제 그 지점에서 어떤 정보가 넘어오는지 확인합니다. Make의 첫 모듈은 데이터를 가져오는 역할을 맡는 경우가 많으므로, 모듈 이름뿐 아니라 다음 단계에서 사용할 값도 적어 두면 뒤에서 어떤 값을 연결할지 판단하기 쉽습니다.
이때 모든 항목을 같은 수준으로 취급할 필요는 없습니다. 작업을 진행하는 데 반드시 필요한 값과, 있으면 편리하지만 없어도 되는 값을 나눠 보세요. 필수 항목이 빠졌을 때 시나리오를 멈출지, 해당 데이터를 건너뛸지, 별도로 확인할지에 따라 이후 흐름이 달라집니다. 입력 데이터의 형식도 함께 살펴야 합니다. 사람이 읽는 문장인지, 날짜나 상태처럼 정해진 규칙을 따라야 하는 값인지에 따라 처리 방법이 달라질 수 있습니다.
입력 구조를 아직 확인할 수 없다면 모든 경우를 미리 확정하기보다, 예상하는 항목과 확인이 필요한 항목을 구분해 둘 수 있습니다. 실제 값이 예상과 다르게 들어오면 설계를 조정해야 할 수도 있으니, 적용하기 전에 입력값을 확인할 방법도 생각해 두는 편이 좋습니다. 입력의 윤곽이 잡혔다면 다음에는 이 데이터를 어떤 순서와 기준으로 바꿀지 정해야 합니다.
처리 단계를 역할별로 나누기
- 입력 데이터를 그대로 쓸지, 변환할지 결정합니다.
- 조건에 따라 달라지는 흐름을 구분합니다.
- 각 단계가 맡는 일을 한 가지씩 설명할 수 있게 합니다.
다르게 말하면, 처리는 들어온 정보를 목적에 맞게 다듬거나 다음 행동을 정하는 과정입니다. Make의 모듈은 각각 한 가지 일을 맡는 작은 도구라고 생각할 수 있습니다. 값의 형식을 바꾸거나, 필요한 항목만 골라내거나, 정해 둔 기준에 따라 다음 행동을 선택할 수 있습니다. 이 작업을 한 덩어리로 생각하면 문제가 생긴 지점을 찾기 어려우므로, 처리 목적을 작은 역할로 나누는 편이 좋습니다.
예를 들어 정보를 정리한 뒤 조건에 따라 서로 다른 곳으로 보내야 한다면, 먼저 정리하는 일과 경로를 나누는 일을 따로 생각할 수 있습니다. 조건이 없다면 굳이 흐름을 나누지 않아도 됩니다. 반대로 특정 값이 있을 때만 다음 단계로 넘어가야 한다면, 그 기준을 말로 설명할 수 있도록 적어 두세요. "어떤 값이 있을 때, 어떤 처리를 한다"처럼 써 보면 모호한 조건을 발견하기 쉽습니다.
각 모듈의 이름도 맡은 역할이 드러나도록 붙이면 흐름을 다시 읽을 때 도움이 됩니다. 앞선 글에서 다룬 모바일 화면과 이름 짓기 원칙도 여기서 이어집니다. 모듈 이름만 봐도 처리 목적을 짐작할 수 있으면, 시나리오를 열어 보지 않은 사람도 전체 흐름을 파악하기 쉽습니다. 다만 단계를 지나치게 잘게 나누면 오히려 읽기 어려워질 수 있으니, 실제로 확인하거나 수정할 이유가 있는 단위인지 살펴보는 게 좋습니다. 처리 흐름을 정했다면 마지막으로 결과가 어디에 남고, 성공 여부를 어떻게 확인할지 정해 보겠습니다.
결과와 확인 방법까지 설계하기
- 처리된 데이터가 도착할 위치를 정합니다.
- 완료 상태를 무엇으로 판단할지 정합니다.
- 실패하거나 결과를 확인하기 어려운 경우도 고려합니다.
일상에 빗대어 보면, 결과는 맡은 일을 끝낸 뒤 물건을 정해 둔 자리에 두는 것과 비슷합니다. 시나리오가 마지막으로 수행하는 작업이자, 자동화가 의도대로 끝났는지 확인하는 기준이기도 합니다. 데이터를 저장하는지, 다른 곳으로 전달하는지, 또는 처리된 내용을 갱신하는지 먼저 정하세요. 결과가 남는 위치를 분명히 하면 입력에서 가져온 항목 중 무엇을 마지막 단계까지 전달해야 하는지도 거꾸로 확인할 수 있습니다.
성공 여부를 확인하는 방법도 결과 설계의 일부입니다. 작업이 끝났다는 표시가 필요한지, 처리된 데이터를 사람이 확인할 수 있어야 하는지 생각해 보세요. 결과가 만들어지더라도 어떤 입력에서 나온 것인지 구분하기 어렵다면 나중에 확인하는 데 시간이 걸릴 수 있습니다. 반대로 모든 정보를 결과에 남기려 하면 불필요한 데이터가 늘어날 수 있으므로, 실제 확인에 필요한 범위를 골라야 합니다.
입력 누락이나 처리 조건 불일치처럼 예상 밖의 상황이 생기면, 그 데이터를 멈춰 둘지 별도로 확인할지도 선택할 수 있습니다. 어느 쪽이 나은지는 작업의 성격에 따라 달라지므로, 처음부터 모든 예외를 자동으로 처리하기보다 확인이 필요한 지점을 표시하는 방법도 있습니다. 다만 이 방식으로는 사람이 추가로 확인해야 할 수도 있으니, 확인할 담당자나 시점을 함께 생각해 볼 수 있습니다. 이제 입력부터 결과까지 흐름이 이어졌다면, 모듈을 연결하기 전에 이 설계를 한 번 읽어 보며 각 구간의 역할이 겹치지 않는지 확인할 수 있습니다.
흐름을 나누면 수정도 쉬워진다
입력, 처리, 결과를 먼저 나누면 Make의 모듈을 고르는 일이 단순한 연결 작업에서 설계 과정으로 바뀝니다. 어느 구간에서 데이터가 달라지는지 알 수 있어 수정할 위치를 찾기 쉬워지고, 처음 만드는 시나리오도 한 번에 이해할 수 있는 크기로 시작할 수 있습니다. 다음 글에서는 이렇게 정리한 흐름을 Make의 모듈과 연결할 때 생기는 선택 기준을 이어서 다뤄볼 수 있습니다.