안녕하세요, HEDVION 입니다

우리가 블로그를 여는 진짜 이유: 지식 부채는 기술 부채만큼 위험하다

세 명이 회사를 만들면서 가장 먼저 한 일은 블로그를 여는 게 아니었습니다. 첫 번째는 결제 모듈 하나를 오류 없이 돌리는 것이었고, 두 번째는 정산 마감을 원 단위까지 맞추는 것이었습니다. 블로그는 훨씬 나중에 왔습니다. 그런데 막상 "왜 블로그를 여는가"를 팀 안에서 정리하고 보니, 그 이유가 의외로 실용적이었습니다. 지식 부채(knowledge debt)를 더 이상 개인 슬랙 히스토리에 묻어두지 않기 위해서.

결제·정산 도메인에서 일하는 사람들은 압니다. 이 분야의 암묵지는 놀라울 만큼 공유가 안 됩니다. PG사마다 다른 웹훅 전송 타이밍, 가상계좌 채번 방식의 미묘한 차이, 다층 가맹점 구조에서 수수료를 분배하는 방법 — 이것들을 어디서 배우셨나요? 아마 전임자의 말, 오래된 컨플루언스 문서, 아니면 직접 오류를 내면서 배웠을 겁니다. 우리도 그렇게 배웠습니다. 그 과정에서 쌓인 "이건 왜 이렇게 하는가"의 맥락이 팀 밖으로 나간 적이 거의 없습니다. HEDVION 기술 블로그는 그 맥락을 바깥으로 꺼내는 실험입니다.

HEDVION이라는 이름, 그리고 우리가 선택한 좁은 영역

HEDVION은 Hedgehog(고슴도치)에서 따왔습니다. 이사야 벌린의 유명한 비유에서 여우는 여러 가지를 알고, 고슴도치는 하나의 큰 것을 압니다. 우리는 고슴도치 쪽을 선택했습니다. 결제·정산·자동화라는 좁은 영역에서, 매뉴얼이 없는 문제의 매뉴얼을 직접 쓰는 팀.

팀 멤버 중 하나는 연간 거래액 100억 원 규모의 티켓 플랫폼(티켓나라)을 총괄한 경험이 있습니다. 이 규모면 단순 PG 연동으로는 버틸 수 없습니다. 공연 취소가 집중되는 시즌에는 하루 수천 건의 부분 취소 요청이 동시에 들어옵니다. 각 건마다 원 결제 수단별 환불 가능 여부, 포인트 혼합 결제 처리, 부분 취소 시 수수료 재계산이 맞물립니다. 이 경험에서 나온 실제 문제들 — 코드로 풀었던 것, 정책으로 우회했던 것, 끝내 해결 못 한 것 — 이 앞으로 이 블로그의 주된 글감입니다.

FIFO 차감 로직의 현실: 단순해 보이는 것이 가장 자주 틀린다

정산 로직 중 가장 간단해 보이지만 가장 많이 틀리는 것이 FIFO(선입선출) 차감입니다. 개념은 명확합니다: 먼저 들어온 매출을 먼저 정산에 씁니다. 그러나 현장에서는 이게 단순하지 않습니다.

예시를 하나 들겠습니다. 가맹점 A가 하루 500건의 주문을 받습니다. 이 중 30%가 취소됩니다. 그런데 취소 건의 결제 수단 분포는 원 결제 분포와 다릅니다. 카드 취소가 계좌이체 취소보다 빠르게 처리되기 때문입니다. 결과적으로 FIFO 스택에서 특정 날짜 구간의 홀드 금액이 비대해지고, 이것이 D+1·D+2 정산 주기와 맞물리면 가맹점이 받아야 할 금액이 실제보다 며칠 늦게 도달합니다. 우리 팀이 직접 계측한 케이스에서는 D+2 정산 기준으로 전체 금액의 약 2.3%가 평균 1.7일 추가 지연됐습니다. 숫자가 작아 보이지만, 월 정산 총액이 수억 원이면 수백만 원이 며칠 동안 공중에 뜨는 셈입니다. 가맹점 클레임이 들어오기 전까지 아무도 모릅니다.

이 문제의 해결책은 "FIFO를 버린다"가 아닙니다. 취소 건의 결제 수단 분포를 별도 추적하고, 홀드 계산에 가중치를 부여하는 방식으로 보완했습니다. 이 트레이드오프 — 단순한 FIFO의 유지보수 편의 vs. 결제 수단별 취소 속도 차이로 인한 오차 — 를 명시적으로 기록하는 것이 이 블로그가 하려는 일의 핵심입니다. 6개월 뒤 우리 자신이 다시 읽었을 때 납득할 수 있게.

n8n + LLM으로 운영 업무를 실제로 어떻게 줄였나

자동화는 세 명이 운영까지 감당하기 위한 필수 조건입니다. 사람 손이 닿아야 하는 루틴이 하나 생길 때마다, 그 루틴을 없앨 방법을 먼저 고민합니다.

n8n은 오픈소스 워크플로우 자동화 도구입니다. Zapier나 Make와 유사하지만 셀프호스팅이 가능하고, JavaScript 코드 노드를 제약 없이 쓸 수 있다는 점이 결정적이었습니다. 우리는 n8n에 LLM을 연결해 세 가지를 자동화했습니다: 전일 정산 리포트 초안 생성, 이상 거래 알림 1차 분류, CS 이메일 요약 및 라우팅. 이 중 가장 임팩트가 컸던 것은 첫 번째입니다. 기존에는 엔지니어 한 명이 매일 아침 30–40분을 "전일 정산 현황 확인 → DB 쿼리 → 슬랙 공유" 루틴에 썼습니다. 지금은 n8n 워크플로우가 오전 7시에 실행되고, LLM이 수치를 요약해 슬랙에 올립니다. 실제 절약 시간: 주 5일 기준 월 약 11–12시간. 세 명 팀에서 12시간은 기능 하나를 설계하고 구현할 수 있는 스프린트입니다.

이 워크플로우를 나중에 전체 공개할 예정입니다. 단순히 "이렇게 구성하면 됩니다"가 아니라, 어떤 프롬프트 버전이 숫자를 잘못 읽었는지, n8n 웹훅과 Spring Boot 이벤트를 어떻게 연결했는지, LLM 응답의 파싱 오류를 어떻게 방어했는지 포함해서입니다.

iwinv + Cloudflare 조합: 작은 회사의 인프라 선택과 그 한계

"클라우드 네이티브"는 좋은 말이지만 비쌉니다. AWS EC2 + RDS + ElastiCache 기본 조합은 스타트업 초기에도 고정비가 월 수십만 원에서 시작하고, 트래픽이 붙으면 빠르게 수백만 원이 됩니다. 우리는 국내 IDC 기반의 iwinv VM에 Cloudflare를 붙이는 방식으로 시작했습니다.

트레이드오프는 명확합니다. iwinv는 국내 네트워크 레이턴시가 낮고 VM 단가가 AWS 동급 대비 30–40% 저렴하지만, Auto Scaling이 없고 관리형 DB 서비스도 없습니다. Cloudflare는 DDoS 방어와 CDN을 무료-저가로 해결하지만, 오리진 서버가 단일 장애점이 됩니다. 우리가 확인한 것: 결제 집중 시간대와 공연 오픈런처럼 트래픽 스파이크가 예측 가능한 경우, Cloudflare의 캐시 규칙과 Rate Limiting으로 대부분의 부하를 선행 차단하면 VM 한 대로 초당 수백 요청을 감당할 수 있습니다. 단, DB 쿼리가 병목이 되는 순간 이 한계는 무너지고, 그 임계치를 직접 부딪혀 찾는 과정이 다음 인프라 글의 재료가 됩니다.

이 선택이 "틀린" 선택이었는지 "맞는" 선택이었는지는 아직 모릅니다. 그 판단 과정을 중간에 남기는 것, 그게 이 블로그가 존재하는 이유 중 하나입니다.

독자가 바로 써먹을 수 있는 시사점

마지막은 일반론 없이 직접 말하겠습니다.

결제·정산 로직을 짜고 있다면: 지금 FIFO 차감을 쓰고 있다면, 취소 건의 결제 수단 분포가 원 결제 분포와 다른지 먼저 확인하세요. 다르다면 홀드 금액 계산이 이미 틀어져 있을 가능성이 높습니다. 데이터가 없다면, PG 정산 내역에서 취소 건만 필터링해 수단별 처리 시간 분포를 뽑는 것에서 시작하세요.

n8n이나 LLM 자동화를 고려 중이라면: 가장 빠른 첫 번째 시도는 "매일 반복하는 슬랙 메시지 하나를 자동화하는 것"입니다. LLM 요약 노드를 붙이면 프롬프트 20–30줄로 구현할 수 있고, 실패해도 잃는 것이 없습니다. 이것이 성공하면, 그 다음에는 알림 분류와 이상 탐지로 넘어가세요.

인프라 비용을 줄이고 싶다면: Cloudflare의 Cache Rules와 Rate Limiting 설정을 먼저 점검하세요. 오리진 서버에 도달하기 전에 막을 수 있는 요청이 생각보다 많습니다. 우리 설정 기준으로 전체 요청의 35–45%가 캐시에서 처리됩니다. 구체적인 설정값은 다음 인프라 글에서 공개합니다.

앞으로 이 블로그에 올라오는 글 하나마다 이 기준을 지키려 합니다: 수치가 없는 주장은 쓰지 않고, 실패한 시도는 성공 사례만큼 비중 있게 기록하고, 결정의 이유를 6개월 뒤 우리 자신이 읽어도 납득할 수 있게 남깁니다. 기준을 못 지킨 글이 보이면 [email protected]으로 알려주세요. 고치거나 내립니다.

다음 글에서 더 구체적으로 만나겠습니다.

— HEDVION 팀