간식 한 박스의 험난한 여정

위펀을 처음 알게 되는 분들은 보통 "사무실에 간식 채워주는 회사"로 기억해요. 틀린 말은 아니에요. 위펀은 기업 간식 구독 서비스에서 시작했고, 지금도 가장 많은 고객이 스낵24로 위펀을 만나니까요.

그런데 개발 부문 시각에서 시스템 안쪽을 들여다보면 이야기가 조금 달라집니다.

간식 한 박스가 사무실에 무사히 도착하기 위해서는

원하는 상품들이 올바르게 담기고,

발주와 출고가 착오없이 이어지고,

신속하게 결제 금액이 확정되고,

거래명세서가 빠짐없이 쌓이고,

정확한 정산 데이터가 만들어지고,

고객에게 제때 알림이 나가야 해요.

어떤 서비스는 모바일 주문과 연결되고, 어떤 서비스는 포털의 예산 정책과 맞물려요. 어떤 서비스는 매장 POS와 연결되고, 어떤 서비스는 배송과 정산, 세금계산서 발행까지 이어지고요.

간식은 위펀이 다루는 수많은 도메인 중 하나일 뿐이에요. 개발부문이 하는 일은 이 복잡한 도메인들을 하나의 운영 흐름으로 연결하는 것이에요.

위펀은 기업 운영에 필요한 여러 서비스를 소프트웨어로 연결하는 BaaS(Business as a Service) 플랫폼이에요. 겉으로는 간식, 조식, 커피, 선물, 화환, 스마트냉장고가 각각 다른 서비스로 보이지만, 그 안에서는 반복되는 흐름이 있어요. 주문이 들어오고, 결제가 확정되고, 배송이나 출고 상태가 바뀌고, 정산 데이터가 만들어지고, 고객에게 알림이 가는 흐름이요. 서비스가 달라도 이 구조는 계속 등장합니다.

과정은 비슷해 보여도, 매일 발생하는 이슈와 과제들은 천차만별이에요. 오늘은 위펀 시스템의 뒤에서는 어떤 문제들이 일어나며, 개발 부문은 어떻게 이를 헤쳐나가는지 조금 솔직하게 풀어보려 해요.

간식 너머의 수많은 도메인

위펀은 기업 운영에 필요한 여러 업무를 서비스로 만들고 있어요. 간식, 조식, 커피, 선물, 화환, 스마트냉장고처럼 이름만 보면 모두 복지나 총무 서비스처럼 보이지만, 개발 관점에서 보면 성격이 꽤 다릅니다. 몇 개만 소개해 볼게요.

물류·창고: 정기배송 서비스는 고객사의 예산과 구성 기준에 맞춰 상품을 고르고, 그 결과가 발주와 피킹, 출고로 이어져요. 상품이 부족하면 대체 흐름도 필요하고요. "무엇을 누구에게 언제 보낼지"가 매번 데이터로 결정됩니다.

결제: 서비스 성격에 따라 정기결제, 가상계좌, 매장 결제처럼 결제 방식이 달라요. 결제는 주문 화면에서 끝나지 않아요. 취소와 환불, 정산, 회계 기준까지 이어지는데, 한 건이 어긋나면 뒤의 데이터도 같이 흔들립니다.

정산·세금계산서: 주문은 거래명세서가 되고, 거래명세서는 월별 청구 흐름으로 묶여요. 고객사마다 확인해야 하는 기준이 다르고, 운영자가 설명할 수 있어야 하는 정보도 달라요. 돈이 오가는 영역이기 때문에 작은 차이도 바로 드러납니다.

하드웨어·IoT: 스마트냉장고나 POS처럼 화면 너머의 실제 기기와 맞물리는 영역도 있어요. 결제 단말, 출입 장치, 영수증, 재고 상태처럼 소프트웨어 밖의 상태를 함께 봐야 합니다.

모바일 상품권과 배송: 선물, 생일, 화환, 퀵처럼 사람에게 직접 도착해야 하는 서비스도 있어요. 발송 상태, 수신 방식, 배송 추적, 외부 파트너 연동이 모두 서비스 경험에 영향을 주고요.

물론 한 사람이 이걸 전부 다 수행하지는 않아요. 다만 위펀 안에서는 물류, 결제, 정산, 하드웨어, 상품권, 배송이 전부 살아 움직이는 도메인이에요. 한 회사에 있으면서 이렇게 결이 다른 문제를 옮겨 다니며 깊게 볼 수 있는 곳은 생각보다 많지 않습니다.

보이지 않는 곳에서 함께 돌아가는 것들

BaaS라는 용어가 조금 생소하게 느껴질 수 있는데요. 위펀이 말하는 BaaS는 ‘기업 운영에 필요한 업무를 서비스로 만들고, 그 뒤의 복잡한 운영 흐름을 소프트웨어로 연결하는 모델’이에요.
(위펀 BaaS에 대해 더 알고 싶다면? 위펀 스토리 #2: BaaS, 혁신의 새 물결을 참고해 보세요.)

회사는 정책과 예산을 설정하고, 임직원은 계약된 서비스 안에서 주문하거나 신청해요. 매장과 공급사는 주문과 출고를 처리하고, 운영팀은 배송, 정산, 고객 문의를 관리하고, 고객은 포털과 알림을 통해 처리 결과를 확인해요.

사용자에게 간단한 버튼 하나처럼 보이는 기능도, 그 뒤에서는 정책, 주문, 결제, 정산, 알림, 운영 확인 화면이 함께 움직입니다. 그래서 위펀 개발부문은 기능을 서비스마다 새로 만드는 대신, 공통으로 묶을 수 있는 영역과 서비스별로 달라져야 하는 지점을 나누며 구조를 다듬어가고 있어요.

B2B 운영 도메인을 제대로 다루는 법

B2B 운영 도메인이 유독 어려운 이유는 화면이 많아서가 아니에요. 상태가 많고, 그 상태들이 서로 영향을 주기 때문입니다.

주문 하나를 예로 들어볼게요. 회사 정책이 붙고, 직원별 예산이 확인돼야 하고, 매장이 운영 중인지 봐야 하고, 결제 수단이 유효한지도 확인해야 해요. 포인트나 예산이 정상적으로 차감됐는지, 배송은 어디까지 갔는지, 정산에는 어떻게 반영되는지, 고객에게 어떤 알림이 나가야 하는지도 함께 봐야 하고요.

한 단계가 실패했을 때 "다시 시도해 주세요"로 끝낼 수도 없어요. 돈이 빠졌는지, 주문은 확정됐는지, 배송은 시작됐는지, 정산에는 반영됐는지가 전부 맞아야 하거든요.

그래서 위펀 개발부문은 UI를 만들기 전에 ‘상태 전이’부터 봐요. 어떤 상태에서 어떤 상태로 이동할 수 있는지, 트랜잭션을 어디서 끊을지, 실패하면 어디까지 롤백할지, 롤백이 어렵다면 어떤 보상 로직을 둘지 먼저 확인합니다.

*상태 전이(State Transition): 시스템, 프로세스 또는 객체가 어떤 조건이나 이벤트에 의해 현재 상태에서 다른 상태로 변경되는 과정

그 과정이 화려하진 않아요. 하지만 고객과 운영팀이 매일 안심하고 서비스를 쓰게 만드는 가장 중요한 영역이라고 할 수 있어요.

예를 들면, 청구서 이월 자동화

최근에 했던 ‘청구서 이월 처리 자동화’ 사례가 위펀 개발부문이 일하는 방식을 잘 보여줍니다.

기존에는 청구 기준 이후에 처리 상태가 바뀌거나, 정산에 반영해야 할 항목이 뒤늦게 확인되는 경우가 있었어요. 그러면 운영팀이 추가 확인이 필요한 항목을 수기로 점검해야 했고, 고객에게 청구 금액을 설명할 때도 "이 항목이 왜 이번 청구서에 포함됐는지"를 따로 찾아봐야 했어요.

"확인된 항목을 다음 청구서에 넣으면 되는 거 아닌가?" 싶지만, 막상 들어가 보면 그렇게 간단하지 않습니다.

어떤 항목을 대상으로 할지, 어느 범위까지 자동으로 확인할지, 이미 안내된 청구 정보와 새로 반영할 데이터를 어떻게 구분할지, 포털 응답은 어떻게 바뀌어야 할지, 운영자는 백오피스에서 무엇을 보고 검증해야 할지까지 함께 결정해야 해요.

그래서 이 문제를 단순한 배치 수정으로 보지 않았어요. 정산 안정성을 해치지 않는 범위에서 추가 확인이 필요한 항목을 자동으로 탐지하고, 운영자가 검증할 수 있는 형태로 다음 청구 흐름에 반영했습니다. 데이터 모델을 손보고, 백오피스에서 이월 여부를 확인할 수 있게 했고, 포털 응답도 함께 조정했어요. 고객에게 발송되는 이메일과 알림톡 문구도 바꿨고요.

운영자는 "이 금액이 왜 이번 청구서에 들어왔는지" 확인할 수 있어야 했고, 고객은 "왜 금액이 달라졌는지" 이해할 수 있어야 했으니까요.

완벽한 자동화보다 검증 가능한 자동화

이 작업에서 가장 고민이 컸던 건 자동화의 범위였어요.

자동화 범위를 넓히면 운영팀의 수기 확인은 줄어들어요. 하지만 그만큼 과거 데이터를 다시 해석해야 하고, 예외 케이스도 늘어나요. 이미 고객에게 안내된 청구 정보와 새로 반영되는 데이터 사이의 관계도 복잡해질 수 있고요.

그래서 처음부터 모든 예외를 자동으로 처리하려 하지 않았어요. 내부 정산 기준에 맞는 범위에서 먼저 자동화하고, 운영자가 확인할 수 있는 표시를 남기는 방식을 선택했습니다.

완벽한 자동화는 아니에요. 대신 운영자가 이해하고 검증할 수 있는 자동화였어요.

위펀의 도메인에서는 이런 판단이 중요합니다. 무조건 많은 것을 자동화하는 것보다, 어디까지 시스템이 처리하고 어디서 사람이 확인할 수 있게 둘지를 정하는 일이 더 중요할 때가 많아요. 특히 주문, 결제, 정산, 배송처럼 오류 하나가 돈이나 신뢰에 직접 영향을 주는 영역에서는 더욱 그렇고요.

지금 위펀 개발 부문이 풀고 있는 것들

위펀은 지금 여러 서비스가 각자 자라며 쌓아온 운영 흐름을 더 단단한 구조로 정리하는 중이에요. 서비스마다 주문, 결제, 정산, 배송, 알림을 매번 새로 만들 수는 없으니까요. 공통으로 묶을 것은 운영 코어로 뽑고, 서비스마다 달라야 하는 부분은 확장 지점으로 열어두어야 합니다.

물론 이게 말처럼 쉽지는 않아요.

같은 "주문"이어도 서비스마다 이후 흐름이 다르거든요. 어떤 주문은 배송으로 이어지고, 어떤 주문은 매장 결제로 끝나요. 어떤 주문은 정기 청구 흐름에 들어가고, 어떤 주문은 외부 파트너와 상태를 맞춰야 하고요. 같은 "알림"이어도 고객 담당자에게 나가는 알림과 운영자가 확인해야 하는 알림은 달라요. 이런 규칙을 깨지지 않게 유지하면서 공통 구조로 다시 세우는 일을 하고 있어요.

기존에 운영하면서 쌓였던 레거시를 다루면서 동시에 다음 확장을 설계해야 해요. 이미 돌아가는 서비스는 안정적으로 운영하면서, 다음 서비스가 붙을 때 같은 문제를 반복하지 않도록 구조를 다듬어야 하고요. 추상적인 플랫폼 설계와 매일의 운영 문제가 함께 동반되죠.

위펀이 가장 필요로 하는 개발자

기능을 빨리 만드는 역량은 당연히 중요해요. 다만 돈과 물류가 오가는 도메인에서는 속도만큼 중요한 게 있습니다.

✔️ 문제가 생겼을 때 "왜"부터 좁히는 태도.
✔️ 어떤 데이터가 기준(source of truth)인지 확인하는 습관.
✔️ 실패하면 어디까지 되돌리거나 보상해야 하는지 먼저 생각하는 기준.
✔️ 운영자가 문제를 추적할 수 있게 만드는 감각.

서비스가 잘 돌아가는 것과, 문제가 생겼을 때 운영자가 원인을 찾을 수 있는 건 다른 이야기예요. 고객에게 설명할 수 있는 근거를 남기는 일, 테스트와 운영 로그를 같이 챙기는 일도 여기에 들어가고요.

그래서 위펀 개발 부문은 ‘질문을 잘 하는 사람’을 항상 반겨요.

"이 기능은 왜 필요한가요?"

"이 상태가 실패하면 무슨 일이 생기나요?"

"정산 기준 데이터는 무엇인가요?"

"운영자는 이 케이스를 어디에서 확인하나요?"

"고객에게는 어떤 문구로 설명되나요?"

"같은 흐름이 다른 서비스에서도 반복될 가능성이 있나요?"

개발을 늦추려는 질문이 아니에요. 더 안 깨지게 만들려는 질문입니다.

위펀 개발부문은 단순히 기획서만 보고 구현하지 않아요.

‘운영팀이 반복해서 확인하는 게 무엇인지, 영업과 CS가 고객에게 무엇을 설명해야 하는지, 물류와 정산에서 어떤 데이터가 기준이 되는지’, 기획서 안에 담긴 맥락을 함께 확인해요. 그리고 그 맥락을 시스템이 처리할 수 있는 형태로 번역합니다.

위펀의 과제를 같이 풀어나갈 분을 찾아요

위펀의 개발 업무는 화려하고 거창한 것보다 현실적이고 이성적인 것에 가까워요. BaaS 플랫폼을 설계하면서도, 특정 청구 흐름이 왜 다르게 보이는지 들여다봐야 해요. 큰 그림을 그리면서도, 운영팀이 매일 반복하는 일을 한 줄씩 줄여야 하고요.

대신 그만큼 다양한 도메인을 들여다 볼 수 있어요.

물류, 결제, 정산, 하드웨어, 모바일 상품권, 배송 추적까지, 한 회사 안에서 결이 다른 도메인을 옮겨 다니며 깊게 파볼 수 있어요. 코드 한 줄이 누군가의 반복 업무를 줄이고, 상태 설계 하나가 고객 응대 기준을 바꾸고, 작은 자동화가 운영팀의 하루를 가볍게 만드는 걸 직접 두 눈으로 볼 수 있죠.

복잡한 B2B 운영을 더 단단한 플랫폼으로 바꾸는 일에 관심이 있다면, 그리고 한자리에 머물지 않고 여러 도메인을 깊게 경험해보고 싶다면, 위펀 개발 부문에 문을 두드려 주세요.

위펀은 지금, 기능을 더하는 개발자를 넘어 운영의 흐름을 함께 설계할 개발자를 찾고 있어요.

지금 아래 공고를 확인해 보세요.

📌채용 중인 포지션

• 백엔드 개발 엔지니어 (시니어급/8년↑)

• 백엔드 개발 엔지니어 (미들급/5년↑)

• 백엔드 엔지니어 (운영&보안)

• 프론트엔드 개발 (Frontend/React/5년↑)

• AI Native QA Engineer

Editor: 위펀 브랜드마케팅 하수빈