Make.com에서 n8n으로 갈아타기 2 - Code를 추가할 수 있어 행복합니다.

지난주엔 Make로 구현한 제 카톡봇의 기능 중 Youtube/Web 요약 기능을 n8n으로 이식했습니다.

다음 타겟은 번역기 기능이었습니다.

이 번역기, Make.com - Tasker 조합으로 사용할 때는 좀... 기형적으로 만들어져 있었습니다. 😅

Make.com - Tasker 사용하던 시절의 기형적인 구조

당시 번역기는 이렇게 작동했어요:

카톡 입력: . 안녕하세요
→ Tasker가 "."를 감지
→ webhook 1번으로 전송
→ Make 시나리오 1번 실행 (한영 번역)
→ 결과 받기

구분자는 총 5가지였습니다:

  • . → 한영 번역

  • , → 한중 번역

  • → 한폴 번역

  • * → 문법 수정

  • ? → AI에게 질문

그리고 각 구분자마다 별도의 webhook이 있었고, Make.com에도 5개의 시나리오가 따로 돌아가고 있었습니다.

그렇다 보니 Tasker에서는 20개가 넘는 Action이 연결되어 하나의 Task를 구성하고 있었습니다.

항목 목록을 보여주는 휴대전화 화면의 스크린샷

Make에는 아주 단순한 시나리오 5개가 구성되어 있었고요.

계정 설정 페이지 스크린샷
다양한 유형의 애드워즈를 보여주는 다이어그램

"왜 이렇게 복잡하게 만들었냐고요?"

비용 구조가 만들어낸 괴물

Make.com은 Module이 실행될 때마다 사용량을 카운트합니다.

예를 들어 하나의 시나리오에서 If 분기를 쓰면:

Webhook(1) → If 조건 체크(1) → 번역 API(1) → Webhook Response(1) = 4 Operations

만약 5가지 번역을 하나의 시나리오로 만들면:

Webhook(1) → If(1) → If(1) → If(1) → If(1) → 번역(1) → Webhook Response(1) = 7 Operations

하지만 Tasker에서 미리 구분자를 확인하고, 해당하는 webhook으로만 보내면:

Webhook(1) → 번역 API(1) → Webhook Response(1)= 3 Operations

Module 수를 최소화하기 위해 Tasker에 분기 로직을 다 떠넘긴 거죠.

결과적으로:

  • Tasker: If문으로 5개 분기 체크

  • Make: webhook 5개, 시나리오 5개

  • 관리 포인트: 10개...

"이거 유지보수하기 진짜 힘들겠는데?" 싶었지만, 비용 때문에 이와 같은 접근 방법이 최적이라고 생각했습니다.

n8n으로 이식: 하나의 Webhook으로 통합

n8n으로 옮기면서 생각했어요.

"n8n은 노드 단위가 아니라 하나의 워크 플로우를 실행하는 단위로 비용이 책정되니 노드수를 줄이기 위한 기형적인 구조가 아니라, 제대로 된 구조로 만들어보자."

새로운 구조

카톡 입력: . 안녕하세요
→ Tasker가 webhook 1개로 전송 (구분자 포함)
→ n8n의 JavaScript 노드가 구분자 파싱
→ 해당하는 번역 API 호출
→ 결과 반환

핵심은 JavaScript 코드로 분기를 처리하는 것이었습니다.

아무래도 Code 작성이 가능하다는 그 강력한 기능을 썩히는 것은 너무 아까우니까요.

Claude에게 코드 작성 부탁

그나마 가장 난이도가 높게 느껴질 수 있는 코드 작성도 우리의 친구 Claude에게 부탁하면...

결과적으로 아래와 같은 코드를 만들어 줬습니다.

javascript

// 입력값 가져오기
const inputText = $input.first().json.chatInput|| $input.first().json.body.message;

// 1. 앞 2글자와 나머지 분리
const firstChar = inputText.charAt(0);
const prefix = inputText.substring(0, 2);
const mainText = inputText.substring(2);

// 3. 케이스별 프롬프트 생성
let prompt = '';
let translationType = '';

switch(firstChar) {
  case '.': // 영어 ↔ 한글
    translationType = '영어-한글';
    prompt = `아래 글의 70% 이상이 한글이면 영어로, 그렇지 않으면 한글로 번역해줘. 번역한 결과만 알려줘:\n\n${mainText}`;    
    break;
    
  case ',': // 중국어 ↔ 한글
    translationType = '중국어-한글';
    prompt = `아래 글의 70% 이상이 한글이면 중국어로, 그렇지 않으면 한글로 번역해줘. 번역한 결과만 알려줘:\n\n${mainText}`;
    break;
    
  case 'ㅍ': // 폴란드어 ↔ 한글
    translationType = '폴란드어-한글';
    prompt = `아래 글의 70% 이상이 한글이면 폴란드어로, 그렇지 않으면 한글로 번역해줘. 번역한 결과만 알려줘:\n\n${mainText}`;
    break;
    
  case '*': // 문법 수정
    translationType = '문법수정';
    prompt = `다음 텍스트에서 문법적으로 어색한 부분을 자연스럽게 수정해주세요. 의미는 유지하되 표현만 개선해주세요. 수정한 결과만 알려주세요.:\n\n${mainText}`;
    break;

  case '?': // 질문
    translationType = '질문';
    prompt = `${mainText}`;
    break;
    
  default:
    throw new Error(`지원하지 않는 구분자입니다: ${firstChar}`);
}

// 4. 결과 반환
return {
  json: {
    original: inputText,
    firstChar: firstChar,
    prefix: prefix,
    mainText: mainText,
    translationType: translationType,
    prompt: prompt
  }
};

조금 길고 복잡하지만...

나머지는 n8n이 알아서 처리해 주겠죠... 그냥 던져 보기로 했습니다.

구성된 n8n workflow 자체는 상당히 심플합니다. (안에 있는 코드가 위의 코드로 좀 구조가 복잡해 보여서 그렇죠...

앱을 만드는 과정을 보여주는 다이어그램

Tasker의 코드 또한 확연히 심플해 졌습니다.

휴대전화의 텍스트 편집기를 보여주는 화면

실제 사용해보니

이식한 번역기를 며칠 써보니 확실히 느껴지는 게 있어요.

1. 유지보수가 편하다

구분자를 추가하고 싶으면? JavaScript 코드에 case 하나만 추가하면 됩니다.

거기에 맞는 프롬프트 추가해 주고요...

Make 시절처럼 시나리오 하나 더 만들고, Tasker에 If문 추가하고, webhook URL 관리하고... 이런 거 안 해도 돼요.

2. 디버깅이 쉽다

문제가 생기면 어디서 생긴 건지 한눈에 보입니다. Make 시절엔 "어느 시나리오에서 문제가 생긴 거지?" 하면서 5개를 다 확인해야 했거든요.

3. 확장성이 좋다

앞으로 "한일 번역", "한베 번역" 같은 걸 추가하고 싶으면 JavaScript 코드만 수정하면 됩니다. 전체 구조는 그대로 유지하면서요.

비용이 설계에 미치는 영향

이번 이식을 하면서 깨달은 게 있습니다.

"비용 구조가 시스템 설계를 왜곡시킨다"

Make.com을 쓸 때는 "Module을 최소화"하는 게 최우선이었어요.

그러다 보니 본래 n8n(혹은 Make)이 해야 할 분기 로직을 Tasker에 떠넘기고, 시나리오를 여러 개로 쪼개는 기형적인 구조가 만들어진 거죠.

n8n으로 오니까 "어떻게 하면 깔끔하게 만들까?"에 집중할 수 있게 되었습니다.

비용 걱정 없이 노드를 추가하고, 코드로 로직을 정리하고, 확장 가능한 구조로 만들 수 있었어요.

이게 n8n의 진짜 장점인 것 같습니다.

다음 목표

번역기 이식이 성공적으로 끝났으니, 이제 남은 마지막 기능도 옮겨볼 계획입니다.

마지막으로 남은 기능은 카톡 대화 내용을 임베딩하고 청킹하여 나중에 분석하여 볼 수 있게 만드는 작업이 되겠습니다.

이 기능도 Make에서는 복잡하게 구현했었는데, n8n에서는 코드 & 바이브 코딩의 힘을 빌린다면 보다 똑똑하고 쉽게 만들 수 있을 것 같거든요.

마치며

Make.com도 좋은 도구지만, 비용 구조 때문에 설계가 제약받는 것, 그리고 코드를 추가할 수 있는 모듈이 없다는것이 너무 아쉬웠습니다.

반면 n8n은 그 제약에서 자유로워지게 해주더라고요.

동글동글한 아이콘이 귀여워서 Make.com을 처음에 익혔었는데...

좀 더 일찍 n8n으로 갈아탈 껄 그랬나봐요.

2
1개의 답글

뉴스레터 무료 구독

👉 이 게시글도 읽어보세요