기술 도입비용 을 매출 로 환산 하기 — 비동기 인프라 5개 질문
“가입 하면 메일 을 보낸다.” 이 한 줄 을 두고 어떤 팀 은 카프카 를 얹고, 어떤 팀 은 크론 한 줄 로 끝낸다. 둘 다 돌아간다. 그런데 비용 은 10배 차이 난다.
기술 도입비용 은 “화려한 기술 을 쓰는 비용” 이 아니다. “필요 이상 으로 쓴 비용” 이다. 그리고 이 과잉 은 대개 매출 이 아니라 엔지니어 의 자기만족 에서 나온다. 이 글 은 위 그림 의 5개 질문 을 기술 관점 과 매출 관점 둘 다 로 뜯어, 비동기 인프라 를 어떻게 right-size 하는지 정리한다.
도입비용 이란 무엇 인가 — 빙산 의 아랫부분
먼저 “도입비용” 을 제대로 정의 하자. 대부분 은 구축 비용 만 본다. 실제 비용 은 이렇다:
도입비용 = 구축(1회) + 운영(매일) + 학습(팀 전체) + 장애대응(새벽 3시) + 인지부하(영원히)
카프카 를 “며칠 이면 붙인다” 는 건 구축 만 본 것 이다. 진짜 청구서 는 운영·학습·장애대응 에서 매달 날아온다. 그래서 판단 기준 은 하나 여야 한다:
이 기술 이 만드는 매출·안정성 이, 그 총비용 보다 큰가?
크면 도입, 작으면 과잉. 아래 5개 질문 이 이 저울 을 각 축 으로 나눠서 재는 도구 다.
Q1. 실시간 이 필요 한가? — SLA 를 매출 로 환산
기술: “가입 후 몇 초 안 에” 냐 “하루 1번 이면 OK” 냐. 초 단위 면 이벤트 기반(큐), 일 단위 면 배치(크론) 로 충분 하다.
매출: 실시간성 은 돈 이다 — 단, 어떤 기능 이냐 에 따라. 결제 승인 이 5초 늦으면 이탈 이지만, 웰컴 메일 이 5분 늦는다고 이탈 하지 않는다. 실시간성 의 매출 기여 가 0 에 가까운데 실시간 인프라 를 까는 건, 안 팔리는 기능 에 투자 하는 것. 그림 의 사례 는 “1분 안 에” → 분 단위 OK → 초 단위 인프라 불필요.
Q2. 실패 하면 재시도 가 필요 한가? — 누락 의 비용
기술: 메일 서비스 가 30초 다운 됐을 때, 그 메일 이 영영 누락 돼도 되나? 안 되면 재시도(큐 + 재처리) 가 필요 하다. 되면 fire-and-forget 로 충분.
매출: 재시도 인프라 의 값어치 = 누락 1건 의 비용 × 누락 빈도. 결제 웹훅 누락 은 정산 이 틀어져 직접 손실 이지만, 마케팅 메일 누락 은 손실 이 거의 0 이다. 사례 는 “실패 시 3회 재시도 — 필요” → 재시도 는 사되, 카프카 급 은 아님. 관리형 큐 의 기본 재시도·DLQ 로 충분.
Q3. 응답 을 막아도 되는가? — 동기 결합 의 전환율 비용
기술: 메일 전송 2초 가 가입 API 응답 에 그대로 노출 돼도 되나? 안 되면 비동기 로 떼어내야(큐) 한다. 사용자 응답 경로 에서 느린 외부 호출 을 분리 하는 것 — 이게 큐 의 가장 흔한 정당한 이유 다.
매출: 가입·결제 같은 전환 경로 의 응답 지연 은 이탈률 로 직결 된다. 2초 가 붙으면 전환 이 눈 에 띄게 빠진다. 여기선 비동기 분리 가 매출 방어 다. 사례 는 “메일 3초 가 가입 응답 에 묻히면 안 됨” → 비동기 필요. 이 Q3 가 사실상 “큐 로 가야” 를 확정 짓는다.
Q4. 건수 는 얼마나 되는가? — 규모 가 기술 을 정한다
기술: 하루 50건 과 5만건 은 답 이 다르다. 초당 수천 건 · 재처리 · 스트림 조인 이면 카프카 가 값 을 한다. 하루 수백 건 이면 카프카 는 파리 잡는 데 대포.
매출: 여기가 과잉투자 가 가장 자주 터지는 지점 이다. 5만건/일 을 처리 하려 카프카 를 깔았는데 실트래픽 이 500건 이면, 차액 만큼 이 순수 매몰비용 이다 — 브로커 3대, 주키퍼(또는 KRaft), 모니터링, 그 모든 걸 배운 팀 시간. 사례 는 “하루 ~500건 — 작음” → 카프카 의 처리량 이 필요 없음. 미래 확장 을 이유 로 대는 순간, YAGNI 를 의심 하자.
Q5. 팀 이 운영 할 수 있나? — 새벽 3시 의 비용
기술: 큐 시스템 이 장애 나면 새벽 3시 에 누가 보나? 카프카 는 강력 하지만, 컨슈머 랙·리밸런싱·파티션 설계·브로커 장애 를 운영 할 사람 이 없으면 그건 자산 이 아니라 부채 다.
매출: 운영 못 하는 기술 은 장애 시간 = 매출 손실 로 돌아온다. 그리고 그 손실 은 하필 트래픽 이 몰리는 순간 에 난다. 전담 인력 이 없으면 관리형(SQS · SNS · EventBridge) 이 거의 항상 정답 이다 — 운영 을 클라우드 에 아웃소싱 하고, 팀 은 도메인 에 집중. 사례 는 “전담 인력 없음 — 관리형 선호”. 이건 백엔드 와 DevOps 에서 말한 운영 을 소유 하는 비용 과 같은 얘기 다.
사례 의 결론 — 크론 X · 카프카 X · 관리형 큐 + Lambda 1개
다섯 질문 의 답 을 겹쳐 보면 결론 이 저절 로 나온다:
| 질문 | 답 | 방향 |
|---|---|---|
| Q1 실시간 | 분 단위 OK | 초 단위 인프라 X |
| Q2 재시도 | 3회 필요 | 큐 기본 재시도 O |
| Q3 응답 분리 | 가입 응답 에 묻히면 안 됨 | 비동기 필요 → 큐 O |
| Q4 건수 | ~500건/일 | 카프카 X |
| Q5 운영 | 전담 없음 | 관리형 O |
- Q1~Q3 는 “큐 로 가야” 라고 말한다 (응답 분리 + 재시도 때문).
- Q4~Q5 는 “카프카 까지는 가지 마” 라고 말한다 (규모 작음 + 운영 인력 없음).
→ 정답 은 크론 X, 카프카 X, 관리형 큐(SQS) + Lambda 1개. 큐 는 쓰되, 운영 비용 이 큰 큐 는 안 쓴다. 이게 도입비용 을 매출 로 환산 한 결론 이다.
마무리 — 적정 기술 은 겸손 이 아니라 계산 이다
“카프카 안 씀” 이 부끄러운 게 아니다. 트래픽 이 카프카 를 요구 하지 않는데 까는 게 부끄러운 것 이다. 반대 로, 진짜 로 필요 한데 크론 으로 버티는 것 도 똑같이 틀렸다.
내 홈랩 K3s 에도 카프카 는 있다. 하지만 모든 비동기 를 카프카 로 밀지 않는다 — 어떤 도메인 은 Outbox 패턴 으로, 어떤 건 관리형·경량 큐 로 충분 하다. 축 마다 다르게 재는 것, 그게 5개 질문 의 요지 다.
좋은 아키텍트 는 가장 강한 기술 을 고르는 사람 이 아니라, 매출 대비 총비용 이 가장 낮은 기술 을 고르는 사람 이다.
다음 에 “이거 카프카 로 할까요?” 라는 말 이 나오면, 화이트보드 에 다섯 줄 을 먼저 적자 — 실시간성 · 재시도 · 응답성 · 건수 · 운영성. 답 은 대개 거기서 이미 정해져 있다.