Make에서 시나리오를 만들다 보면 어떤 모듈을 먼저 놓아야 할지, 비슷한 선택지 가운데 무엇을 골라야 할지 막힐 때가 있습니다. 앞선 글에서는 시나리오의 흐름을 입력·처리·결과로 나누어 설계하는 순서를 정리했습니다. 이번에는 그 흐름을 실제 모듈 선택과 연결 순서로 옮기는 기준을 이어서 다룹니다. 핵심은 앱 이름을 따라 모듈을 놓는 것이 아니라, 각 단계에서 데이터에 어떤 일이 일어나야 하는지부터 확인하는 것입니다. 그렇게 기준을 세우면 시나리오를 처음 만드는 경우에도 필요한 모듈과 불필요한 연결을 구분하기가 한결 수월해집니다.
모듈 이름보다 해야 할 일을 먼저 적는다
- 각 단계가 수행할 작업을 동사로 표현합니다.
- 필요한 데이터와 작업 결과를 함께 확인합니다.
- 한 모듈이 여러 단계를 대신한다고 미리 가정하지 않습니다.
쉽게 설명하면, 모듈을 고르기 전에 그 모듈이 해야 할 일을 먼저 적어 두면 필요한 기능을 찾기가 쉬워집니다. 예를 들어 입력 단계에서는 '새 데이터 감지'나 '데이터 가져오기'처럼, 처리 단계에서는 '값 바꾸기'나 '조건 확인'처럼 적을 수 있습니다. 이렇게 하면 이름이 익숙한 모듈부터 고르는 일을 줄일 수 있습니다.
이어서 그 작업에 필요한 값과 작업이 끝난 뒤 나와야 할 값을 함께 확인합니다. 같은 앱 안에서도 데이터를 읽는 모듈과 새로 만드는 모듈은 역할이 다르고, 필요한 입력값도 달라질 수 있습니다. 그래서 기능 이름만 보지 말고 앞 단계에서 받은 값을 다음 단계로 넘길 수 있는지도 살펴봅니다.
처음부터 모든 작업을 하나의 모듈에 넣으면 각 단계의 책임이 흐려질 수 있습니다. 반대로 작업을 너무 잘게 나누면 연결과 확인이 늘어나니, 데이터가 달라지거나 판단이 필요한 지점에 모듈을 두는 편이 좋습니다. 작업이 정리됐다면 이제 시나리오의 시작점에서 어떤 모듈이 필요한지 결정할 차례입니다.
입력 모듈은 데이터를 가져오는 방식으로 고른다
- 새 데이터가 생겼을 때 감지해야 하는지 정합니다.
- 기존 데이터에서 조건에 맞는 항목을 찾아야 하는지 구분합니다.
- 다음 단계에 필요한 필드가 입력에 포함되는지 확인합니다.
풀어서 설명하면, 입력 모듈은 시나리오가 어디서 어떻게 시작할지를 정하는 첫 단계입니다. 새 데이터가 생기는 순간을 기준으로 삼는다면 그 변화를 감지하는 역할이 필요합니다. 이미 쌓인 데이터 가운데 조건에 맞는 항목을 가져오려면 검색이나 조회 역할이 필요할 수 있습니다.
그런데 두 방식은 시작 시점뿐 아니라 다음 단계에 전달되는 데이터도 달라질 수 있습니다. 원하는 실행 흐름에 맞춰 모듈을 고르고, 가져온 항목이 중복으로 처리되지 않는지와 필요한 범위의 데이터만 다루는지도 확인합니다. 사용할 수 있는 방식은 서비스와 모듈이 제공하는 기능에 따라 달라질 수 있습니다.
이어서 입력 모듈이 돌려주는 값을 미리 살펴보면 뒤에서 필요한 정보를 찾느라 연결을 다시 고치는 일을 줄일 수 있습니다. 결과에 필요한 값이 들어 있지 않다면 추가 조회가 필요할 수 있고, 이미 충분한 정보가 있다면 별도의 조회 모듈을 생략할 수도 있습니다. 다만 실제로 어떤 값이 제공되는지는 사용하는 서비스와 데이터에 따라 달라질 수 있으니, 입력에서 확보할 값을 확인한 뒤 어디서 가공하거나 분기할지 정합니다.
처리 모듈은 데이터가 바뀌는 지점에 둔다
- 입력값을 결과에 맞는 형태로 바꿔야 하는지 확인합니다.
- 조건에 따라 흐름을 나눠야 하는지 판단합니다.
- 분기를 만들 경우 각 경로의 다음 작업을 구분합니다.
다르게 말하면, 처리 모듈은 입력된 데이터를 그대로 보낼지, 필요한 모양으로 바꾸거나 조건을 확인할지 결정하는 단계입니다. 결과에 맞게 값을 다듬어야 한다면 그 일을 맡을 모듈을 둡니다. 반대로 입력값을 그대로 다음 단계에서 쓸 수 있다면 중간 모듈을 굳이 더하지 않아도 됩니다.
그리고 조건에 따라 서로 다른 결과를 만들어야 할 때는 흐름을 나눌 수 있습니다. 예를 들어 어떤 값이 기준에 맞으면 한쪽 작업으로, 맞지 않으면 다른 작업으로 이어지게 할 수 있습니다. 조건이 늘어나면 각 경로가 어떤 데이터를 받고 어디로 이어지는지 알아보기 어려워질 수 있으므로, 나누기 전에 기준이 되는 값과 각 경로의 다음 작업을 적어 두면 점검하기 편합니다.
처리 과정이 길어 보여도 데이터가 달라지는 곳과 판단하는 곳을 나누면 수정할 위치를 찾기 쉬워집니다. 반대로 단순한 흐름에 분기를 먼저 넣으면 확인할 곳만 늘어날 수 있으니, 실제로 다른 결과가 필요한지 살펴본 뒤 적용하는 편이 좋습니다. 처리 흐름이 정리됐다면 마지막 모듈이 어떤 상태를 만들어야 하는지 구체화해야 합니다.
결과 모듈은 원하는 상태 변화로 고른다
- 새 항목을 만들지, 기존 항목을 바꿀지 정합니다.
- 결과 모듈이 요구하는 입력값을 확인합니다.
- 중복 생성이나 잘못된 대상 갱신을 막을 방법을 생각합니다.
일상에 빗대어 보면, 결과 모듈을 고르는 일은 일을 마친 뒤 책상 위에 어떤 상태를 남길지 정하는 것과 비슷합니다. 새 항목을 만들 것인지, 이미 있는 항목을 바꿀 것인지에 따라 필요한 작업이 달라집니다. 목적지에서 원하는 상태를 먼저 정하고, 그 작업에 맞는 모듈과 입력값이 준비되어 있는지 확인합니다.
기존 항목을 수정하려면 어느 항목을 바꿀지 먼저 찾아야 할 수 있습니다. 새 항목을 만드는 경우에도 같은 데이터가 다시 들어오면 중복으로 생성될 가능성이 있습니다. 이런 상황에서는 항목을 찾는 단계나 중복을 구분할 기준이 필요한지 검토해 볼 수 있습니다. 다만 모든 흐름에 조회 단계를 넣을 필요는 없으므로, 실제로 중복이나 대상 혼동이 생길 수 있는지에 따라 선택합니다.
결과 모듈에 필요한 값이 앞 단계에 없다면 그 값을 어디서 얻을지 입력과 처리 단계를 다시 확인해야 합니다. 이런 식으로 결과에서 시작해 앞 단계를 거슬러 살펴볼 수도 있습니다. 필요한 작업이 정해졌다면 이제 모듈을 어떤 순서로 잇고, 연결마다 무엇을 확인할지 살펴봅니다.
연결 순서는 데이터가 흐르는 순서로 잡는다
- 입력 모듈에서 결과 모듈까지 작업 순서대로 연결합니다.
- 앞 모듈의 출력값을 다음 모듈의 필요한 입력에 대응시킵니다.
- 전체 실행 전에 연결 구간별로 값과 결과를 확인합니다.
예를 들어 생각해 보면, 연결 순서를 정하는 일은 재료가 요리 과정을 따라 움직이는 순서를 정하는 것과 같습니다. 모듈을 데이터가 이동하는 순서대로 놓더라도 값이 저절로 알맞게 들어가는 것은 아닙니다. 앞 모듈에서 나온 값 가운데 무엇을 다음 모듈의 어느 입력에 넣을지 짝을 맞춰야 합니다. 이 과정을 건너뛰면 모듈이 연결돼 있어도 필요한 값이 비거나, 생각하지 못한 값이 전달될 수 있습니다.
그래서 처음에는 입력 모듈과 바로 다음 단계의 연결부터 확인하고, 데이터가 예상한 형태로 넘어가는지 살펴본 뒤 다음 모듈을 이어 가면 부담이 적습니다. 확인할 내용은 작업에 따라 달라질 수 있습니다. 값이 들어 있는지뿐 아니라 조건에 따라 기대한 경로로 이동하는지, 결과 모듈이 의도한 상태를 만드는지도 살펴봅니다.
한 번에 전체를 구성하면 문제가 생겼을 때 어느 연결에서 원인이 시작됐는지 찾기 어려울 수 있습니다. 반대로 작은 구간부터 확인하면 원인을 좁히기 쉽지만, 실제 실행 환경에서 들어오는 데이터가 예상과 다를 가능성도 있습니다. 따라서 구성하면서 확인한 내용과 실제로 들어오는 데이터를 나누어 살펴보면 좋습니다. 이런 연결 과정을 통해 각 모듈의 역할이 드러나면, 시나리오 전체의 작업 경계도 더 분명해집니다.
모듈은 작업의 경계에 놓인다
모듈을 기능 목록에서 고르는 대신 데이터가 어디서 들어와 어떤 작업을 거쳐 어떤 상태로 남는지 따라가면, 필요한 연결과 생략할 단계를 스스로 판단할 수 있습니다. 그 결과 시나리오를 수정할 때도 어느 모듈이 어떤 역할을 맡는지 찾기 쉬워집니다. 다음 글에서는 연결한 모듈에 실제 값을 매핑하고 실행 결과를 확인하는 단계로 이어가겠습니다.