소셜 미디어 스케줄러를 자체 호스팅 n8n 워크플로로 바꿨습니다

채널당 월 5달러. 갱신 화면에서 계속 들여다보게 되는 숫자였습니다. 내가 몇 군데에 올릴 수 있는지를 조용히 결정하고 있었으니까요. 채널 네 개면 5달러의 네 배입니다. 나중에 두 번째 브랜드를 더하면, 내가 직접 쓰는 똑같은 예약 게시물을 두고 청구액이 또 올라갑니다.

원래 별개의 자동화 두 건 때문에 VPS에서 n8n을 돌리고 있었기에, 주말 하나를 들여 이걸 X, LinkedIn, Instagram, Facebook용 n8n 소셜 미디어 스케줄러로 바꿀 수 있을지 시험해 봤습니다. 지금까지 넉 달째 돌아가고 있습니다. 이 전환에 실제로 얼마가 들었는지, 무엇이 망가졌는지, 그리고 여전히 권하지 않는 경우는 어디인지 정리했습니다.

요약

• X, LinkedIn, Facebook, Instagram 게시를 같은 워크플로에서 처리하게 만들었지만, 네 분기에 들어간 작업량은 같지 않았습니다.
• 문제는 Instagram이었습니다. 프로페셔널 계정 요구 조건, 미디어 규칙, 게시 한도, 토큰 수명 주기가 모두 Buffer에서는 없던 유지보수를 만들어 냈습니다.
• TikTok은 제외했습니다. n8n의 기본 제공 앱 노드 카탈로그에 없고, 커스텀이나 커뮤니티 통합을 게시 일정의 일부로 삼고 싶지 않았기 때문입니다.
• Community Edition이 없앤 것은 소프트웨어 비용이지 전체 비용이 아닙니다. 호스팅 비용은 그대로 냈고, 업데이트와 자격 증명, 백업, 모니터링, 실패한 게시물 복구는 제 몫이었습니다.
• 제 결론은 이렇습니다. 초안 작성과 게시를 하나의 파이프라인에 두고 싶었기 때문에 전환할 가치가 있었습니다. 시각적 캘린더와 믿을 만한 큐만 원했다면 그대로 남았을 겁니다.

무엇에 돈을 내고 있었는가, 그리고 결국 무엇이 결정적이었는가

Buffer의 현재 요금 에는 연간 결제 시 Essentials가 채널당 월 5 $로 표시되고, 무료 플랜은 최대 3개 채널과 채널당 10건의 예약 게시물을 지원합니다. 따라서 유료 채널 4개는 연간 결제 기준 월 20 $였습니다. 잘 다듬어진 스케줄러를 파는 방식으로는 합리적이지만, 정작 제가 넓히고 싶었던 부분에 요금을 매기고 있었습니다. 하나의 아이디어를 여러 곳에 맞게 동시에 다시 빚는 일 말입니다.

결국 저를 움직인 건 가격이 아니었습니다. 저는 이미 별도 창에서 모델로 게시물을 초안 잡고, 그걸 손으로 스케줄러에 붙여 넣고 있었습니다. 두 도구가 누가 봐도 하나인 파이프라인을 나눠 하고 있었던 겁니다. 원하는 워크플로가 눈에 들어온 순간, 초안 작성과 게시를 굳이 두 조각으로 갈라 두려고 구독료를 내는 일이 저에게는 말이 되지 않았습니다.

제 워크플로가 하는 일

제 워크플로는 일부러 지루하게 만들었습니다. Schedule Trigger가 하루에 몇 번 실행되어 Google Sheet에서 다음 승인 행을 읽고, 플랫폼별로 문구를 다듬고, 각 버전을 저마다의 게시 분기로 보낸 뒤 결과를 기록합니다. 사람이 승인하는 상태는 시트에 두고, 제가 승인한 행만 게시합니다. 실패한 분기는 n8n 바깥으로 알림을 보내기 때문에, 망가진 자격 증명이 실행 로그 속으로 사라질 일이 없습니다.

초안 작성 단계는 호스팅형 모델 API를 호출합니다. 같은 서버에서 모델을 돌릴까 잠깐 고민했지만, 한 달에 수십 건 정도의 게시물이라면 모델을 자체 호스팅할 때의 비용 요인 가 제 API 요금보다 컸습니다. 사용량이나 프라이버시, 지연 시간에 따라 판단이 달라질 수는 있지만, 소셜 게시물을 다시 쓰겠다고 인프라를 하나 더 운영할 이유는 없었습니다. 이 워크플로는 영리하지 않습니다. 제가 믿을 수 있었던 이유 중 하나가 바로 그것입니다.

플랫폼별 실제 상황 (문제는 Instagram)

네 분기 중 셋은 대체로 조용했습니다. Instagram만 나머지 프로젝트 전체를 합친 것보다 많은 시간을 잡아먹었고, 게시가 빠졌을 때 제가 가장 넘기기 어려운 플랫폼이기도 했습니다. 아래 표는 제가 쓰거나 검토한 경로이고, 그 밑의 설명이 실제로 제 구성에 영향을 준 부분입니다.

LinkedIn의 경우, LinkedIn 노드 문서 는 개인과 조직 명의의 게시물 작성을 다루고, n8n의 LinkedIn 자격 증명 가이드 는 조직 명의로 게시하려면 앱을 LinkedIn의 Community Management App Review에 통과시켜야 한다고 밝히고 있습니다. 제 필요는 그것으로 충분했습니다. X 자격 증명 문서 에는 X가 개발자 액세스 플랜 등급에 따라 엔드포인트별로 시간 기반 요청 한도를 적용한다고 나옵니다. 제 게시량으로는 천장에 닿은 적이 없지만, 여전히 n8n의 약속이 아니라 X가 언제든 바꿀 수 있는 한도로 여깁니다.

Meta의 콘텐츠 게시 가이드 는 지원되는 이미지 형식이 JPEG뿐이라는 점과, 문서화된 경로에서 이동하는 24시간 동안 API로 게시할 수 있는 글이 100건이라는 한도를 명시합니다. 이 JPEG 규칙에 저녁 하나를 날렸습니다. 내보내기 기본값이 PNG였고, n8n 안에서는 실패 원인이 잘 드러나지 않았기 때문입니다. 이 게시 한도는 영구적인 것이 아니라 현재 API 경로와 버전에 묶인 값으로 봅니다.

넉 달 동안 두 번 망가졌습니다. 두 번 다 Instagram이었습니다. 장기 액세스 토큰은 영구적이지 않으며, Meta의 토큰 갱신 레퍼런스 에는 토큰을 갱신할 수 있는 건 만료되지 않았고 발급된 지 24시간 이상 지났을 때뿐이라고 나옵니다. 그 창을 놓치면 갱신은 더 이상 복구 수단이 아닙니다. 제 실수는 인증을 지속적인 유지보수가 아니라 초기 설정 작업으로 취급한 것이었습니다. 게시 워크플로에는 만료 모니터링, 이른 갱신, 그리고 갱신 실패 시의 알림이 필요합니다.

TikTok은 애초에 이번 대체 대상이 아니었습니다. 기본 제공 앱 노드 카탈로그 에는 없습니다. HTTP Request 노드나 커스텀 노드, 커뮤니티 노드를 쓸 수도 있었지만, 그러면 자격 증명 관리와 고장이 더 늘어납니다. 저는 스케줄러를 대체하던 것이지, 플랫폼 연동을 하나 더 떠맡겠다고 나선 게 아니었습니다.

내 시간까지 포함한 비용 계산

기준으로는 채널 4개짜리 Buffer Essentials를 썼습니다. 아래 공개 가격은 연간 결제 기준이며 2026년 8월에 확인했습니다. 달러와 유로 금액은 서로 곧바로 같은 값인 척하지 않고, 각자 공개된 통화 그대로 두었습니다.

n8n의 클라우드 요금 은 Starter를 제 Buffer Essentials 채널 4개와 사실상 같은 시작 가격대에 두고 있었습니다. 그것으로 제 상황에서는 관리형 옵션이 탈락했습니다. 워크플로 엔진에 비슷한 월 요금을 내면서, 더 편한 게시 인터페이스는 잃게 되니까요. Community Edition 비교 문서 를 보고 기본 자체 호스팅 에디션을 소프트웨어 비용 없이 쓸 수 있다는 점은 확인했습니다. 하지만 그렇다고 서버나 제 시간이 공짜가 되지는 않았습니다.

제 서버 사양을 4 GB RAM과 2 vCPU라는 보편적인 프로덕션 하한선으로 삼을 생각도 없습니다. n8n의 배포 사전 요구 사항 은 폭넓은 리소스 범위를 제시합니다. 제 부하는 작지만, 다른 구성이라면 동시 실행, 미디어 페이로드, 코드 단계, 데이터베이스 부하, 길어진 실행 이력 때문에 상황이 금세 달라질 수 있습니다. 정직한 답은 워크로드에서 출발해 메모리와 CPU를 지켜보라는 것입니다.

SQLite는 n8n의 기본값 이며, 트래픽이 적은 단일 인스턴스 구성이라면 그것으로 충분할 수 있습니다. 그래도 실행 이력이 중요해지거나 배포 규모가 커질 예정이라면 저는 PostgreSQL을 택합니다. 분산 큐 모드 구성 에 필요한 것이기도 합니다. n8n이 그 아키텍처를 SQLite 위에서는 지원하지 않기 때문입니다. 워크플로가 중요해진 뒤에 데이터베이스를 옮기느니, 저는 설치 단계에서 그 결정을 내리는 쪽을 택합니다.

비싼 쪽은 한 번도 VPS가 아니었습니다. 제 주말이었죠. 거기에 JPEG로 날린 저녁, 토큰 장애, 그리고 글이 정말 나갔는지 매번 확인하는 일이 얹힙니다. 제 시간에 조금이라도 값을 매기면 절감액은 금세 줄고 마이너스로 돌아설 수도 있습니다. 바로 그 지점이 자체 호스팅이 더 이상 저렴하지 않게 되는 지점입니다. 전환은 지금도 가치가 있었다고 생각하지만, 첫 주에는 그렇게 말하지 못했을 겁니다.

읽기

인디 해커를 위한 셀프 호스팅 스택: 막대한 SaaS 청구서를 대체하는 최선의 방법

무엇이 망가졌고, 무엇을 바꿨나

눈에 보인 장애 두 건은 모두 Instagram 토큰 실패였지만, 더 깊은 문제는 침묵이었습니다. 구독형 스케줄러에는 계정 문제를 드러내도록 설계된 제품 화면이 있습니다. 반면 제 첫 워크플로는 n8n 안에서 실패해도 바깥에 드러나는 증상은 그날 게시물이 없다는 것뿐이었습니다. 여기서 배운 건, 자체 호스팅 게시 시스템은 요란하게 실패하고 중복 없이 복구되어야 한다는 것입니다.

• 실패 알림은 n8n 바깥의 채널로 보내고, 플랫폼 응답과 워크플로 실행 ID를 함께 담습니다. 고장 사실을 알려 줄 주체가 고장 난 그 시스템이 되지 않도록 말입니다.
• 토큰 만료일과 앱 심사 상태를 추적하고, 예약된 게시물이 첫 경고가 되기 전에 재인증을 마칠 수 있도록 갱신을 충분히 일찍 시험합니다.
• 게시 전에 고유한 콘텐츠 ID를 기록해 둡니다. 덕분에 실패한 플랫폼 분기만 다시 시도하고, 이미 성공한 분기에 중복 게시하는 일이 없습니다.
• n8n의 데이터 볼륨과 데이터베이스를 백업하고, 복원 테스트까지를 백업의 일부로 봅니다. 복사해 둔 파일이 알아서 저를 구해 주리라 가정하지 않습니다.
• 제공자가 허용하는 곳에서는 API 버전을 고정하고, 변경 로그를 읽고, n8n이나 제공자 쪽에 변경이 있을 때마다 모든 플랫폼 분기를 테스트합니다.
• 실행 이력과 미디어 파일은 제가 실제로 필요한 보존 기간에 맞춰 정리합니다. 소셜용 자산은 아주 작은 자동화를 쓸데없이 큰 백업으로 만들어 버리기 때문입니다.

이걸 집에 있는 기기에서 돌리지는 않을 겁니다. 오전 9시로 예약한 게시물은 9시에 워크플로가 살아 있기를 요구하는데, 가정용 전원과 회선, NAT, 인바운드 콜백은 콘텐츠 캘린더에 들이고 싶지 않은 변수들을 더합니다. VPS는 그런 가정 네트워크 변수를 없애 줍니다. 다만 TLS, 백업, 모니터링, 업데이트, 복구에 대한 제 책임까지 없애 주지는 않습니다.

이걸 하지 않는 편이 나은 사람

원하는 것이 스케줄러 그 자체라면 유료 스케줄러에 남으세요. 그건 위로상이 아닙니다. 캘린더, 미리보기, 간단한 승인, 넓은 채널 지원, 최소한의 유지보수가 구독료만큼의 값어치가 있다면, 그걸 사는 게 올바른 결정입니다. 맞춤 자동화가 필요하지 않다면, 그 인터페이스를 워크플로 캔버스로 바꾸는 건 단계만 늘어난 후퇴입니다.

Buffer 같은 형태의 제품을 직접 소유하고 싶다면, n8n보다 먼저 Postiz Postiz를 보겠습니다. 오픈소스 버전은 자기 서버에서 돌릴 수 있고, 지원 채널 30개 이상 가운데 TikTok도 들어 있습니다. 워크플로 캔버스가 아니라 게시 캘린더라서, 유료 스케줄러를 떠나는 많은 사람에게 더 자연스러운 착지점이 됩니다.

제가 이걸 다시 한다면, 이유는 오직 하나입니다. 조사와 초안, 승인, 게시, 기록을 하나의 파이프라인에 두고 싶었기 때문입니다. 제가 받아들인 거래는 이렇습니다. 공짜 예약 발행이 아니라, 주의력으로 값을 치른 통제권. 필요한 게 예약 발행뿐이라면 저는 구독으로 돌아갈 겁니다.

같은 자체 호스팅 경로를 따라가고 싶다면, 저희의 원클릭 n8n 배포 를 쓰면 초기 서버 설치 단계는 사라집니다. 다만 제가 더 중요하다고 느낀 일까지 사라지지는 않습니다. 워크플로 자격 증명, 플랫폼 승인, 업데이트, 백업, 모니터링, 그리고 실패한 게시물 복구 말입니다.

자주 묻는 질문

Buffer의 인증 권한이 n8n으로 이어지나요?

아니요. 제가 Buffer에 부여했던 플랫폼 연결은 Buffer의 앱과 인증 흐름에 속한 것이었습니다. 제 n8n 워크플로에는 자체 자격 증명과 토큰, 스코프, 그리고 해당 계정이나 게시 경로에 필요한 플랫폼 심사가 따로 필요했습니다.

소셜 플랫폼마다 분기를 따로 두어야 하나요?

대개는 그렇습니다. 저는 플랫폼마다 문구와 미디어, 자격 증명, 오류 처리를 다르게 맞추려고 분기를 나눴습니다. 덕분에 Instagram 요청이 실패해도 X나 LinkedIn에서 이미 성공한 게시물을 다시 올리지 않고 재시도할 수 있었습니다.

n8n 워크플로 하나로 여러 고객사 게시를 처리할 수 있나요?

가능합니다. 다만 자격 증명, 콘텐츠 소스, 승인 상태, 로그는 고객사별로 분리하겠습니다. 플랫폼 권한과 할당량은 여전히 해당 앱과 계정에 적용되므로, 연결 하나가 성공했다고 해서 그것을 전방위 접근 권한으로 여겨서는 안 됩니다.

워크플로는 놓친 게시물을 어떻게 복구해야 하나요?

예정 시각이 지난 승인 게시물을 조회한 뒤, 성공 결과가 없는 레코드만 게시합니다. 고유 콘텐츠 ID와 저장해 둔 플랫폼 응답 덕분에, 재시작이나 재시도가 이미 나간 게시물을 중복 발행하는 일은 없습니다.