매달 정산일이 오면 관리자 한 명이 한나절을 갇혀있었습니다. 팔로워 84만+ 인스타 매거진 하나의 정산을, 100% 수작업으로 처리해야 했기 때문입니다.
> 고객사와 계정은 A사로 익명 처리했습니다. 아래 수치는 해당 플래그십 계정의 구축 당시 운영 조건과 실행 기록을 설명한 값이며, 다른 프로젝트의 결과를 보장하지 않습니다.
왜 이 이야기가 당신 회사와 관계 있나
- •월 수백 건의 반복 데이터 처리를 사람이 손으로 하고 있다
- •매달 며칠씩 정산·집계·리포트 작업에 시간이 갇힌다
- •실수 하나가 곧 클라이언트 클레임 또는 지급 오류로 이어진다
- •"자동화하고 싶긴 한데 우리 회사엔 개발자가 없다"
A사의 문제도 정확히 이 자리에 있었습니다. 그리고 이 문제는 개발자를 뽑는 게 아니라 워크플로우 자동화 도구로 해결됐습니다.
A사의 상황 — 스케일이 문제였다
A사는 국내 인스타그램 매거진(특정 카테고리를 정하지 않고 다양한 이슈를 큐레이션해 발행하는 인스타 채널)을 100개 이상 운영하는 콘텐츠 그룹입니다. 소속 에디터도 20명을 훌쩍 넘습니다.
이번 자동화 대상은 그중 플래그십 계정 하나, 팔로워 84만+ 규모입니다.
- •계정 팔로워: 84만+
- •월 발행 콘텐츠: 600건+ (카드뉴스 + 릴스)
- •콘텐츠 올리는 에디터: 20명 이상
- •정산 대상 (계약 명단 등록자): 13명
- •나머지: 명단 외 (인턴·외부 기고자·미등록자·미지정)
정산 구조는 좋아요 수 구간별 4단계 단가제이고, 에디터 그룹(A·B·C·D 4개)마다 단가가 다르며 카드뉴스와 릴스 단가도 별도입니다. 그룹 × 콘텐츠 타입 × 좋아요 구간의 매트릭스로 계산됩니다.
문제는 이 계산이 100% 수작업이었다는 점입니다.
- •매월 정산 며칠 전, 에디터가 각자 자기 게시물의 좋아요 수를 인스타에서 확인
- •확인한 좋아요 수를 구글시트에 수동 기입
- •관리자가 4단계 단가표에 맞춰 개별 정산 금액 계산
- •삭제·비공개된 게시물 별도 확인
- •명단 외 에디터 게시물을 정산 대상에서 수동 분류·제외
- •명단 에디터 13명 합산 후 지급 시트 반영
매월 정산일마다 한나절이 통째로 갇혔습니다. 특히 5번(명단 외 분류)에서 실수하면 곧바로 지급 오류로 이어집니다.
자동화 요구사항
첫째, 반복 입력 지점을 줄이기. 좋아요 확인부터 정산 리포트 발송까지 반복 처리 단계를 자동화.
둘째, 명단 관리 실수를 시스템 레벨에서 차단. 20명+ 게시물이 섞여 올라오는 상황에서, 코드가 자동으로 명단 대조 → 등록자만 정산 대상으로 분류.
셋째, 관리자는 검증만 5분. 결과가 슬랙으로 자동 보고 → 관리자는 짧게 눈으로 확인 후 지급 승인.
왜 n8n이었나 — 도구 선택 근거
자동화 도구 선택지는 크게 세 갈래였습니다.
- •직접 코딩 (Python + Airflow 등): 유연성 최고, 하지만 개발·유지보수 비용 큼
- •Zapier / Make: 진입 장벽 낮음, 하지만 복잡한 조건 분기·데이터 병합에 한계
- •n8n (오픈소스 워크플로우 엔진): 시각적 노드 + JS 코드 노드 병용, 셀프호스팅 가능, Zapier보다 강력하고 코딩보다 빠름
A사의 요구사항은 그룹·타입·구간이 얽힌 조건 분기 + 다중 데이터 소스 병합 + 명단 매칭 + 커스텀 계산 로직이 핵심이었기에, n8n이 가장 균형 잡힌 선택이었습니다.
여기에 크롤링은 Apify(인스타그램 전문 스크래퍼), 저장소는 Google Sheets, 알림은 Slack을 조합했습니다.
시스템 아키텍처 — 46개 노드, 트리거 2개
전체 시스템은 단일 워크플로우 안에서 트리거 2개로 구동됩니다.
Trigger 1 · 매일 09:00 — 신규 게시물 감지 (5분 미만)
- •Apify 메인 크롤링 + 릴스 크롤링 → 합집합·중복 제거
- •캡션에서 `EDITOR | 이름` 패턴 자동 추출
- •카드뉴스 / 릴스 자동 구분
- •명단 대조 → 등록 / 명단 외 / 미지정 3단계 자동 분류
- •시트 신규 append + Slack 알림
Trigger 2 · 매월 06일 10:00 — 월간 정산 (15분 미만)
- •전월 대기 게시물만 필터 (당월 폴백 로직 완전 제거)
- •Apify 메인 800건 + 릴스 300건 풀스캔 (비동기 + 30초 폴링)
- •좋아요 수 → 그룹·타입·구간 매칭 → 단가 자동 계산
- •삭제·좋아요 숨김 게시물 자동 감지 → 기본 단가 처리
- •에디터별 집계 (누적 모드: 이전 월 데이터 100% 보존)
- •개별 정산 탭 갱신 (13개) + 월간 정산 요약 시트 + Slack 정산 리포트
Error Workflow · 항시 감시
- •어느 노드에서든 실패 → 즉시 Slack 알림 (어느 노드에서 왜 실패했는지 자동 리포트)
이 프로젝트가 어려웠던 진짜 이유
기술적 챌린지가 5가지 있었습니다. 각각 시스템 설계에 결정적 영향을 줬습니다.
챌린지 1. 인스타 릴스가 그리드에 잘 안 잡힌다
인스타 스크래핑은 기본적으로 "포스트 그리드"를 훑는데, 릴스는 별도 탭으로 분리되어 있어 그리드 크롤링에서 종종 누락됩니다.
실제로 초기 운영 중 한 달 릴스 86건이 통째로 누락되는 사건이 있었고, 발견 후 릴스 전용 스크래퍼를 별도로 붙이고 두 응답을 `shortCode` 기준으로 합집합·중복 제거하는 노드를 추가했습니다.
챌린지 2. 명단 외 에디터를 "그냥 제외"로 두지 않기
명단 등록 13명 외에도 인턴·외부 기고자·미등록자가 언제든 게시물을 올릴 수 있는 환경. 가장 쉬운 해결책은 "명단 외는 무시"였지만, 그렇게 하면 관리자가 어떤 사람이 얼마나 활동 중인지 파악할 수 없게 됩니다.
그래서 3단계 자동 분류 + 이름별 게시물 수 집계로 재설계했습니다.
- •등록 에디터: 자동 정산
- •명단 외 에디터 (EDITOR 표기는 있지만 명단에 없음): 정산 제외 + 이름별 게시물 수 자동 카운트
- •미지정 (EDITOR 표기 없음): 별도 시트로 자동 격리 + 카운트
이 시스템 덕에 관리자는 매월 "이번 달 명단 외 활동자 리스트 + 게시물 수"를 자동으로 받아보게 됐습니다. 정식 등록 여부를 데이터 기반으로 판단할 수 있는 인사이트가 부수적으로 생긴 셈입니다.
챌린지 3. 크롤링 API의 300초 hard limit
Apify의 즉시 응답 방식(`run-sync`)은 300초 안에 결과를 못 받으면 강제 종료됩니다. 대량 크롤링에 부족했기 때문에, 비동기 실행 후 결과를 30초마다 확인하는 방식(`run-async` + 폴링 루프)으로 재설계했습니다. 이제 크롤링에 15분이 걸려도 안정적으로 완료됩니다.
이후 발견한 부수 이슈: 폴링 상태확인 노드의 timeout이 30초라 단발 지연에 정산 전체가 중단되던 것 → 60초 + onError continueRegularOutput로 강화.
챌린지 4. "당월 폴백" 함정 — 조용한 실패는 가장 위험하다
초기 설계에는 "이번 달 대상 데이터가 없으면 다음 달 데이터로 대체"라는 안전장치가 있었습니다. 그런데 이게 오히려 정산 오작동의 원인이 됐습니다.
5월 데이터 수집이 늦어졌을 때 6월 데이터로 5월 정산이 나가버릴 뻔한 사건 이후, 폴백 로직을 관련 노드 3개에서 통째로 제거하고 명시적 월 필터로만 동작하도록 재구성했습니다.
> "안전한 실패가 조용한 성공보다 낫다."
이 원칙을 시스템에 새긴 순간이었습니다.
챌린지 5. "로직은 정상인데 정산금이 다르다" — 사람 개입 지점의 오류
정산 결과가 예상과 다르게 나오는 사건이 있었습니다. 로직을 처음부터 검토했지만 우리 쪽 문제는 없었습니다. 원인은 사람 쪽에 있었습니다.
정확한 메커니즘은 이랬습니다:
- •매일 09시 크롤링 시점에는 해당 게시물 캡션에 `EDITOR | 이름` 표기가 아직 없음
- •우리 시스템은 정상 로직대로 → "에디터 미기입"으로 분류 → 정산 제외
- •에디터는 나중에 캡션에 자기 이름을 추가 (후기입)
- •하지만 시트에는 이미 "정산 제외"로 기록돼 있음
- •→ 에디터 본인이 예상한 정산금과 실제 정산금이 달라짐
이 사건을 처음 겪었을 때는 우리 로직이 버그일 거라 의심하고 수동으로 데이터를 하나씩 비교 분석하는 데 여러 시간이 걸렸습니다. 원인이 크롤링과 후기입의 시점 차이라는 걸 알기까지가 가장 오래 걸렸습니다.
같은 원리로, 좋아요 수와 삭제 여부도 시점 문제가 있습니다.
- •매일 크롤링 시점: 게시물 실존 → 시트에 정상 기록
- •월간 정산 시점: 게시물이 이미 삭제되어 있으면 → 좋아요 수 재크롤링 응답에서 사라짐 → 자동 삭제 처리 + 기본 단가 정산
- •좋아요 숨김 처리한 게시물도 동일 정책 → 자동 기본 단가
시스템은 다음 원칙으로 재정비됐습니다.
- •크롤링 시점 기록 (`특정 일시` 컬럼)
- •좋아요 수 변동 스냅샷 (정산 시점 기준으로 고정, 이후 변동 무시)
- •삭제·숨김 게시물 = 기본 단가 (일관 정책으로 명문화)
- •에디터 표기 후수정 감지 (다음 정산 시 diff 자동 탐지, 로드맵)
이 이슈로 우리가 배운 것: 자동화는 사람이 개입하는 지점을 없애는 것이 아니라, 그 지점의 오류를 시스템이 감지할 수 있게 만드는 것에 가깝다.
결과 — 숫자로 보는 Before / After
| 지표 | Before (수작업) | After (자동화) | |---|---|---| | 월 정산 소요 시간 | 매월 한나절 이상 | 5분 (검증만) | | 매일 신규 수집 | 사람이 개별 확인 | 자동, 5분 미만 | | 좋아요 오기입 실수 | 월 평균 3~5건 | 0건 | | 명단 외 에디터 분류 | 수동 (실수 위험) | 자동 감지 + 이름별 카운트 | | 삭제·좋아요 숨김 게시물 | 놓침 발생 | 자동 감지 → 기본 단가 | | 릴스 누락 | 한 달 86건 사건 발생 | 이중 크롤링 방지 | | 다중 계정 확장 | 계정당 추가 인력 | 시트 1행 추가만 | | 관리자 인사이트 | 없음 | 명단 외 활동자 자동 리포트 |
정산일 부담이 크게 해소됐다는 피드백을 받았고, 이후 더 큰 스케일의 확장 논의로 이어졌습니다. A사 전체 계정(100개+) 연동과 자체 통합 대시보드 구축까지 검토됐습니다. 현 시점에서는 이번 프로젝트 시스템의 안정 운영에 집중하며 지속적인 유지보수를 이어가고 있습니다.
운영 안정성 — 만드는 것보다 안전하게 돌리는 것이 어렵다
- •누적 모드: 매월 정산 시 이전 월 데이터 100% 보존, 이번 월만 갱신
- •크롤링 실패 방어: Apify 응답이 임계치 미만이면 자동 대기 (부분 데이터로 잘못된 정산 X)
- •에러 알림 자동화: 어느 노드에서 왜 실패했는지 Slack으로 즉시 알림
- •Credential 만료 대응: OAuth 토큰 만료 시 즉시 감지 + 재인증 프로세스
- •지속 유지보수: 시스템 구축 후에도 정기 점검 및 이슈 대응으로 안정 운영 지원
프로젝트 진행 요약
- •초기 구축: 약 14일 (요구사항 정리, 워크플로우 설계, 테스트 포함)
- •안정화: 실전 운영 후 발견 이슈 반영, 약 2개월 (v3까지)
- •운영 방식: 완전 자동 실행 + 정기 유지보수
- •확장 가능성: 계정 추가·통합 대시보드 확장 논의 진행
초기 구축 비용과 월 운영·유지보수 비용은 프로젝트 규모와 요구사항에 따라 상이합니다. 문의 주시면 무료 진단과 함께 견적 안내드리겠습니다.
이 이야기가 당신 회사에 시사하는 것
A사 케이스는 특수해 보이지만, 본질은 이겁니다.
> "매달 반복되는 데이터 확인·집계·정산 업무가 있고, 그게 사람 손으로 굴러가고 있다면 — 자동화 후보다."
이런 업무가 있는 회사라면 데이터 출처, 권한과 예외 규칙을 확인한 뒤 유사한 구조를 검토할 수 있습니다.
- •크리에이터·프리랜서 정산이 있는 회사
- •여러 채널에서 데이터 모아서 집계하는 회사
- •고객사별 리포트 매달 만드는 회사
- •매출·재고·수수료 정산 수작업 하는 회사
- •명단·리스트 대조로 분류 작업이 있는 회사
워크플로우 도구와 API 조합으로 구축 가능한 범위를 먼저 확인하는 방식입니다.
마치며
이 프로젝트는 단순히 "정산을 자동화했다"가 아니라, 반복 입력을 줄이면서 매달 결과를 검증할 수 있는 시스템을 어떻게 만들 것인가의 실전 기록이었습니다.
- •실패 시나리오를 먼저 그리고, 그다음 성공 시나리오를 짠 것
- •"조용한 성공"보다 "시끄러운 실패"를 우선한 것
- •사람 개입 지점의 오류를 시스템이 감지하도록 안전장치를 설계한 것
- •초기 구축뿐 아니라 지속 유지보수까지 함께 책임지는 서비스로 이어간 것
이 네 가지가 A사 프로젝트가 안정 운영에 도달한 진짜 이유입니다.