PDF로 저장 → 대상 “PDF로 저장”, 여백 없음, 배경 그래픽 켜기
야리끼리
COMPANY PROFILE
도메인은 다릅니다.
구조는 같습니다.
저희는 산지직송 커머스 플랫폼 「함께팜」을 기획부터 개발·운영까지 직접 하는 팀입니다.
그런데 저희가 가진 것은 농산물에 대한 지식이 아니라, 거래 플랫폼의 구조입니다. 예약·B2B 도매·가맹점 발주·인력 매칭·구독 — 이름만 다를 뿐 같은 뼈대 위에 서 있습니다.
01
기획부터 저희가 했습니다수수료·정산 정책, 회원 등급, 반품 규칙처럼 나중에 반드시 터지는 결정을 착수 전에 짚어드립니다.
02
실제로 남의 돈을 다뤄봤습니다카드·간편결제·가상계좌·펌뱅킹 출금·전자세금계산서·PG 자동 대사까지 매일 정산이 도는 시스템을 운영 중입니다.
03
웹·앱·ERP를 한 팀이 합니다고객 화면부터 공급자용 현장 앱, 본사 관리자까지 네 개의 사용자 표면을 동시에 설계·운영합니다.
04
납품 후에도 깜깜해지지 않습니다무중단 배포, 통합 모니터링, 오류 추적, 사용자 행동 분석이 옵션이 아니라 기본 구성입니다.
01저희가 파는 것은 도메인이 아닙니다
06대표 레퍼런스 — 「함께팜」
02구조 해부 — 거래 플랫폼의 6층
07결제 · 정산 · 자금 흐름
03수행 가능 도메인 지도
08기술 스택 · 운영 가시성
04지금 시장이 요구하는 것
09기획 역량과 일하는 방식
05수행 범위
10진행 절차 및 산출물
케이엠에스대한민국산지직송(주)admin@k-p2c.com
※ 담당자·연락처·주소는 배포 전 채워 넣으세요
※ 담당자·연락처·주소는 배포 전 채워 넣으세요
수탁 개발 역량 소개서
2026
2026
01
저희가 파는 것은 도메인이 아닙니다
이식 가능한 구조"농산물 플랫폼 만든 회사가 우리 예약 시스템을 할 수 있나요?" — 가장 많이 받는 질문입니다.
답은 "그래서 더 잘합니다"입니다. 저희가 4년 가까이 만든 것은 농산물을 파는 법이 아니라 여러 참여자가 얽힌 거래를 안전하게 처리하고, 남의 돈을 정확히 나눠 보내고, 그 과정을 현장에서 운영 가능하게 만드는 구조이기 때문입니다.
답은 "그래서 더 잘합니다"입니다. 저희가 4년 가까이 만든 것은 농산물을 파는 법이 아니라 여러 참여자가 얽힌 거래를 안전하게 처리하고, 남의 돈을 정확히 나눠 보내고, 그 과정을 현장에서 운영 가능하게 만드는 구조이기 때문입니다.
이름만 바뀝니다
| 함께팜에서는 | 다른 도메인에서는 |
|---|---|
| 상품 | 객실 · 시술 · 강의 · 일감 · 좌석 · 구독 플랜 · 렌탈 품목 · 중고 매물 |
| 판매자(생산자) | 호스트 · 원장 · 강사 · 기사 · 가맹점주 · 크리에이터 · 거래처 · 셀러 |
| 주문 | 예약 · 발주 · 수강신청 · 매칭 · 계약 · 구독 · 대여 · 티켓 |
| 배송 | 체크인 · 시술 · 수강 · 작업 완료 · 출고 · 회수 · 입장 |
| 취소·반품 | 노쇼 · 예약 취소 · 환불 · 중도 해지 · 반품 · 계약 해지 |
| 정산 | 정산. 이건 이름조차 안 바뀝니다. 수수료를 떼고, 부담 주체를 가르고, 조정 내역을 남기고, 실제로 돈을 보내는 일 — 도메인이 무엇이든 완전히 동일한 문제입니다. |
그래서 저희의 강점은 이렇게 옮겨집니다
산업 지식은 발주처가 가지고 있습니다
병원 원장님이 진료를 저희보다 잘 아는 건 당연합니다. 저희가 필요한 이유는 그게 아닙니다. "예약금을 미리 받으면 그 돈은 언제 매출이 되는가", "노쇼 위약금은 누가 부담하는가" 같은, 업계 사람은 당연하다고 생각해서 말해주지 않지만 시스템에서는 반드시 정해야 하는 것을 저희가 묻습니다.
구조 경험은 발주처가 가질 수 없습니다
부분 취소 정산 역산, 중복 결제 방지, 외부 API 장애 격리, 권한 경계 설계 — 이건 한 번 겪어보지 않으면 설계할 수 없고, 겪을 때는 이미 사고가 난 뒤입니다. 저희는 그 사고를 저희 서비스에서 이미 겪고 해결해뒀습니다.
거꾸로 말하면 이런 뜻이기도 합니다. 저희는 거래·정산·운영이 없는 프로젝트에는 특별히 유리하지 않습니다. 단순 홍보 사이트, 사내 게시판, 콘텐츠 뷰어 같은 일은 저희보다 저렴하게 잘하는 곳이 많습니다. 돈이 오가고, 여러 주체가 얽히고, 현장에서 매일 운영되는 시스템 — 저희를 쓰실 이유는 여기에 있습니다.
한 문장으로
"업종을 배우는 데는 2주면 됩니다.
정산이 틀어졌을 때 복구되는 구조를 만드는 데는 2년이 걸립니다."
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서01
02
구조 해부 — 거래 플랫폼의 6층
왜 다 비슷한가업종이 달라도, 사람과 돈이 오가는 플랫폼은 예외 없이 아래 여섯 층으로 이루어집니다. 화면 디자인과 용어는 매번 달라지지만 이 여섯 층의 설계 문제는 매번 똑같습니다. 그리고 프로젝트가 실패할 때는 대부분 3층과 6층에서 무너집니다.
LAYER 1참여자와
권한 경계
권한 경계
누가 무엇을 볼 수 있고 고칠 수 있는가. 공급자·수요자·중개자·운영자가 한 시스템 안에 공존합니다. 함께팜: 고객·판매자·파트너·관리자 4개 표면 → 예약: 고객·업주·직원·본사 / B2B: 구매처·영업사원·본사 “자기 데이터만 본다”의 경계를 어디에 긋느냐가 DB 설계를 결정합니다.
LAYER 2거래 원장과
상태 기계
상태 기계
주문·예약·계약은 상태를 옮겨다니는 객체입니다. 대기→확정→이행→완료, 그리고 어느 지점에서든 취소. 이름만 다를 뿐 상태 전이도(diagram)는 거의 겹칩니다. 상태를 몇 개로 쪼갤지, 되돌릴 수 있는지, 부분 이행을 허용할지가 뒤에 오는 모든 것을 좌우합니다.
LAYER 3정산 —
남의 돈
남의 돈
가장 어렵고, 가장 늦게 발견되고, 되돌릴 수 없는 층. 수수료를 얼마나 떼는가, 할인은 누가 부담하는가, 언제 얼마를 실제로 보내는가, 틀렸을 때 어떻게 조정하는가. 도메인 무관 — 완전히 동일한 문제입니다. 여기가 저희의 핵심 경쟁력입니다 (→ 07장).
LAYER 4외부 연동과
장애 격리
장애 격리
결제·물류·세무·인증·알림 — 내 서버 밖의 시스템에 의존합니다. 남의 시스템은 반드시 느려지고 반드시 죽습니다. 그때 우리 서비스 전체가 같이 멈추지 않게 만드는 것이 설계의 본질이고, 이건 업종과 무관하게 똑같이 필요합니다.
LAYER 5현장 운영
도구
도구
고객 화면은 예쁘게 만들면서 운영자 화면은 대충 만드는 것이 가장 흔한 실패입니다. 실제로 하루 200번 쓰는 건 관리자 화면입니다. 웹 백오피스 + 현장용 모바일 앱을 함께 설계해야 사람이 엑셀로 도망가지 않습니다.
LAYER 6증빙과
규제
규제
세금계산서·현금영수증, 전자상거래법 고지 의무, 개인정보 보관·파기, 정산 기한·자금 별도관리 규제(→ 04장). “나중에 붙이면 되지”가 통하지 않는 유일한 층 — 데이터를 처음부터 그 형태로 쌓아두지 않으면 소급이 불가능합니다.
이 6층을 전부 통과해본 팀은 생각보다 적습니다. 화면을 잘 만드는 회사는 많고, API를 잘 짜는 회사도 많습니다. 그런데 3층(정산)과 6층(증빙·규제)까지 실제 운영으로 통과해본 팀은 드뭅니다. 대부분의 외주사는 그 지점에 도달하기 전에 프로젝트가 끝나고, 그 뒤의 고통은 발주처가 떠안기 때문입니다. 저희는 저희 서비스라서 도망갈 수 없었고, 그래서 끝까지 갔습니다.
같은 구조, 다른 옷 — 세 도메인을 6층에 대입해보면
| 층 | 함께팜 (산지직송) | 병원·클리닉 예약 | B2B 식자재 도매 |
|---|---|---|---|
| ① 참여자 | 고객 · 생산자 · 파트너 · 본사 | 환자 · 의료진 · 데스크 · 본사 | 구매처 · 영업사원 · 물류 · 본사 |
| ② 거래 원장 | 주문 | 예약 · 진료 | 발주 |
| ③ 정산 | 생산자 월 정산 · 출금 | 수납 · 시술자 인센티브 배분 | 외상 미수 · 여신 한도 관리 |
| ④ 외부 연동 | PG · 택배사 · 주소 API | PG · 알림톡 · EMR | PG · 전자세금계산서 · WMS |
| ⑤ 운영 도구 | 생산자 모바일 ERP 앱 | 데스크 접수·대기 화면 | 영업사원 모바일 수주 |
| ⑥ 증빙·규제 | 전자상거래법 · 세금계산서 | 민감정보 · 의료광고 규제 | 세금계산서 · 여신 관리 |
화면은 전부 새로 만듭니다. 용어도 전부 바뀝니다.
그러나 이 표의 여섯 행을 설계하는 방법은 이미 알고 있습니다.
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서02
03
수행 가능 도메인 지도
함께팜의 무엇과 같은가아래는 "할 수 있을 것 같다"가 아니라, 함께팜에서 이미 만들어 운영 중인 기능이 그대로 대응되는 도메인들입니다. 오른쪽 칸은 그 도메인에만 있는 추가 난점이며, 이것까지 미리 말씀드릴 수 있다는 것이 저희의 준비도입니다.
| 도메인 | 함께팜의 무엇과 같은가 | 그 도메인 고유의 난점 |
|---|---|---|
| 예약 플랫폼 숙박·레저·병원·미용 | 상품=객실/시술, 재고=날짜별 잔여, 주문=예약, 판매자 입점·심사, 업주별 정산·출금, 현장용 모바일 앱 | 노쇼·위약금 정책, 시간대 중복 예약 방지, 예약금의 매출 인식 시점 |
| B2B 도매·식자재 | 거래처=판매자, 발주=주문, 출고·배송, 거래명세서·전자세금계산서, 관리자 ERP | 거래처별 단가표, 여신 한도·미수금 관리, 외상 대사 |
| 프랜차이즈 가맹점 발주 | 가맹점=판매자 표면, 발주=주문, 본사 물류 출고, 가맹점별 정산·차감, 승인 워크플로 | 본사 직영창고 vs 3PL 연동 분기, 가맹점·창고 재고 분리 |
| 물류·풀필먼트 3PL · WMS | 택배사 API 실연동, 송장 일괄 생성·택배사별 양식, 배송 추적 자동 수집, 주소 정규화 | 로케이션·피킹 동선, 입출고 실사 대조, 화주별 요금표 |
| 인력·용역 매칭 | 기사/작업자=판매자, 일감=상품, 매칭=주문, 지급 요청·승인·펌뱅킹 실지급 | 3.3% 원천징수·지급명세서, 근로자성 이슈, 보험·자격 검증 |
| 교육·강의 | 강사=판매자, 강의=상품, 수강신청=주문, 강사별 수익 배분 정산, 구독·멤버십 | 중도 해지 환불 규정(학원법), 진도율 기반 정산 |
| 크리에이터·콘텐츠 | 창작자=판매자, 수익 배분(RS) 정산·출금, 예치금 지갑, 숏폼·라이브 스트리밍 | 다중 권리자 분배, 해외 지급·환율 |
| 구독·렌탈·정기배송 | 정기구독·멤버십 이미 운영 중, 정기 결제, 배송 스케줄, 해지·일시정지 | 결제 실패 재시도·연체 정책, 렌탈 자산 회수, PG 빌링 심사 2~3주 |
| 리커머스·중고 | 개인 판매자 입점, 안전결제(에스크로)형 대금 보관·조건부 지급, 채팅, 신고·비속어 필터 | 정산 보류(hold) 기간 설계, 분쟁 중재, 본인확인 |
| 지역·공공 플랫폼 | 지역 생산자 입점, 지역화폐형 예치금·충전·거래원장, 통계 리포트, 관리자 권한 체계 | 선불업 등록 요건, 공공 보안 요구, 감사 대응 문서 |
| 헬스케어·비대면 | 병·의원=판매자 표면, 예약·결제·수납, 병원 직접 등록·정산 3자 검증 구조 경험 | 의료광고·개인정보(민감정보) 규제, EMR 연동 |
| 티켓·이벤트 | 주최=판매자, 좌석=재고, 예매=주문, 취소·환불 수수료 차등, 주최별 정산 | 대기열·동시 접속 폭주, 좌석 선점 경합 |
공통적으로 저희가 즉시 재사용하는 것
결제 수단 통합 처리 · 부분취소 정산 역산 · 정산 조정 원장 · 펌뱅킹 지급 · 전자세금계산서 · 권한 4중 방어 · 무중단 배포 · 통합 모니터링 · 관리자 프레임 · 모바일 앱 기반 구조. 매번 처음부터 만들지 않기 때문에 일정과 비용이 줄어듭니다.
여기 없는 도메인이라면
먼저 30분 통화로 6층 구조에 대입해보고 솔직하게 말씀드립니다. 잘 맞으면 이유를 설명드리고, 안 맞으면 안 맞는다고 말씀드립니다. 받아놓고 일정이 무너지는 것이 서로에게 최악이기 때문입니다.
"우리 업종을 모르잖아요" — 그래서 첫 2주를 이렇게 씁니다
| 1주차 · 관찰 | 담당자 옆에서 지금 쓰는 엑셀·카톡·수기 장부를 그대로 받습니다. 업계 용어가 아니라 실제 데이터의 생김새를 봅니다 — 여기서 대부분의 예외 규칙이 드러납니다. |
| 1주차 · 질문 | 6층 체크리스트를 순서대로 짚습니다. "이럴 땐 어떻게 하세요?"를 30~50개 여쭙고, 답이 사람마다 다른 항목을 표시합니다 — 그게 진짜 정해야 할 것입니다. |
| 2주차 · 되돌려드림 | 이해한 업무를 흐름도와 기능 목록으로 정리해 다시 보여드립니다. "이게 맞나요?"를 확인받는 순간 도메인 격차는 사실상 사라집니다. |
※ 업종 지식이 필요 없다는 뜻이 아닙니다. 업종 지식은 발주처에서 가져오고, 그것을 시스템으로 옮기는 절차를 저희가 갖고 있다는 뜻입니다.
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서03
04
지금 시장이 요구하는 것
2026년 기준 · 규제와 동향최근 몇 년 사이 플랫폼의 "정산"은 선택이 아니라 규제 대상이 되었습니다. 예전에는 "돈만 잘 나가면 되는" 영역이었지만, 지금은 기한·보관 비율·증빙을 법이 정하는 쪽으로 움직이고 있습니다. 저희가 강한 영역이 마침 시장이 가장 급하게 손봐야 하는 영역이 된 셈입니다.
① 정산 기한과 판매대금 별도관리 — 규제가 강화되는 방향
| 대규모유통업법 개정 추진 | 중개거래액 1,000억원 이상 온라인 중개 플랫폼은 구매확정 후 20일 이내 판매대금 지급, 판매대금의 50% 이상 금융기관 예치(별도관리 비율 30%→50% 상향) 방향으로 논의 중. 공포 후 1년 유예 예정. ※ 2026년 8월 현재 국회 정무위 심사 단계로, 아직 시행 전입니다. |
| 전자금융거래법 (선불충전금) | 선불업자는 선불충전금 100% 별도관리(신탁·예치 등). 외부관리 비율은 1년차 60% → 2년차 80% → 3년차 100%로 단계 확대. 등록 요건도 확대(업종 1개 이상·가맹점 2개 이상)되었고, 발행잔액 30억원 미만 또는 연간 총발행잔액 500억원 미만은 등록 의무 면제. |
| 전자상거래법 | 2026년 1월 개정, 2026년 7월 21일 시행. 통신판매중개자는 “자신이 거래 당사자가 아니라는 사실”을 소비자가 쉽게 알 수 있도록 미리 고지해야 함. |
발주처 입장에서 이게 무슨 뜻이냐면 — ① 예치금·포인트를 운영한다면 그 돈을 자기 운영자금과 섞어 쓸 수 없고, 잔액을 항상 증명할 수 있어야 합니다. ② 판매자 대금을 보관한다면 기한 내 지급과 별도 보관을 시스템이 증명해야 합니다. ③ 이건 화면 몇 개 추가가 아니라 거래 원장 설계 자체의 문제입니다. 나중에 소급이 안 됩니다.
저희는 예치금 거래원장, 정산 조정 이력, 지급 거래번호 추적을 이미 그 형태로 운영하고 있습니다.
저희는 예치금 거래원장, 정산 조정 이력, 지급 거래번호 추적을 이미 그 형태로 운영하고 있습니다.
② 시장 동향 — 저희가 이미 만들어 둔 것들
| 라이브·숏폼 커머스 | 국내 라이브커머스는 2025년 약 4.7조원(전년 대비 +35%), 2026년 6조원 돌파 전망. 방송 수는 줄고 방송당 평균 매출이 998만원(+61.6%)으로 “질” 중심으로 재편. → 저희는 HLS 라이브·숏폼을 이미 운영 중입니다. |
| 예약 플랫폼의 탈(脫)OTA | 국내 펜션·숙박 운영자의 70% 이상이 OTA에 의존, 평균 수수료 건당 15~25%. → 자체 예약·결제 시스템 구축 수요가 계속 나오는 배경이며, 구조는 함께팜과 동일합니다. |
| B2B 식자재 유통 | 국내 시장 약 50조원 규모. 현장의 핵심 고통은 여전히 외상 미수금 대사와 수기 거래명세서. → 저희의 정산·명세·세금계산서 구조가 그대로 대응됩니다. |
| AI 도입 | PoC 로 끝나는 도입이 대부분이고, 실제 업무에 얹히는 단계에서 무너집니다. → 저희는 RAG 상담 에이전트와 비정형 주문 자동 추출을 실서비스로 운영 중이라 PoC가 아니라 운영 가능한 형태로 만들어 드릴 수 있습니다. |
③ 그래서 저희가 드릴 수 있는 것 — 정산 구조 무상 진단
진단 항목 (문서로 드립니다)
- 현재 자금 흐름도를 한 장으로 정리 (누구 돈이 어디에 얼마나 머무는가)
- 규제 적용 대상 여부 판별 — 중개거래액·발행잔액 기준선 대입
- 지금 데이터 구조에서 소급이 불가능한 항목 목록
- 우선순위별 개선안과 개략 공수·비용
이렇게 진행합니다
30분 통화로 현재 운영 방식을 듣고, 1주 안에 진단 문서를 무상으로 보내드립니다. 이미 시스템이 있으시면 화면과 정산 명세를 보는 것만으로도 상당 부분 파악됩니다.
진단만 받으시고 구축은 다른 곳에 맡기셔도 괜찮습니다.
출처 — 공정위 대규모유통업법 개정 논의(시사저널·더페어·inews24), 금융위 선불전자지급수단 관련 보도자료 및 전자금융거래법 개정, 국가법령정보센터 전자상거래법, 대한경제·다음뉴스 라이브커머스 시장 집계, 비젠소프트 숙박 OTA 수수료 자료, 바이라인네트워크·마켓보로 식자재 유통 자료, TreeSoop AI 개발 외주 단가 자료. 수치는 인용 시점 기준이며 변동될 수 있습니다.
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서04
05
수행 범위
지금 운영 중인 것만 적었습니다아래는 소개용 목록이 아니라 저희가 자사 서비스에서 실제로 만들어 운영 중인 기능들입니다. "할 수 있습니다"가 아니라 "지금 돌리고 있습니다"라고 말할 수 있는 범위만 적었습니다.
| 영역 | 세부 수행 범위 |
|---|---|
| 거래 | 상품·옵션(SKU)·재고 / 장바구니 / 주문·부분취소·반품·교환 클레임 / 쿠폰·할인·프로모션 / 포인트(동시성 제어) / 멤버십·정기구독 / 선물하기 / 리뷰·평점 / 위시리스트·팔로우 / 검색·자동완성·인기검색어 / 랭킹·큐레이션 / 배너·기획전 |
| 결제·정산 | 카드(PG)·간편결제·가상계좌·실시간 계좌이체·VAN 카드(오프라인)·문자 청구서 결제·자사 예치금 / 공급자별 월 정산·명세서·조정 이력 / 펌뱅킹 실지급·자동이체 배치 / 전자세금계산서 / PG 자동 대사 (→ 07장 상세) |
| 물류·배송 | 택배사 표준 API 연동 / 송장 일괄 생성·택배사별 엑셀 양식 / 배송 추적 자동 수집 / 도로명주소 API 및 주소·우편번호 자동 정규화 / 묶음배송·배송비 정책 / 반품 회수 |
| 공급자·파트너 | 입점 신청·심사·승인 워크플로 / 상품 등록·일괄 가격 변경 / 주문·발송 관리 / 정산 조회·출금 신청 / 전용 모바일 ERP 앱 / 영업망·리워드 관리 / 등급·배지 |
| 관리자(ERP) | 주문·배송·정산·회원·상품 통합 관리 / 통계 대시보드(일별 집계·실시간 스냅샷) / 검색→구매 전환 기여도 분석 / CS 문의·신고 처리 / 공지·배너·이벤트 / 앱 버전 강제 업데이트 / 권한 체계(RBAC)·변경 승인 |
| 모바일 앱 | Flutter iOS·Android 동시 개발 / 카카오·애플 소셜 로그인 / 푸시 알림 / 딥링크·설치 추적 / 인앱 웹뷰 / 영수증·명세서 PDF 생성 / 이미지 업로드 / 음성 입력·읽어주기 / 스토어 심사 대응·배포 |
| 실시간·미디어 | 라이브 커머스 스트리밍(HLS) / 숏폼 영상 / 실시간 알림 / 공급자-고객 1:1 채팅(WebSocket) / 관리자 CS 인박스 실시간 수신 / 비속어 자동 필터 |
| AI | 사내 문서 기반 RAG 챗봇(벡터 검색·근거 제시·대화 학습) / 역할별 AI 에이전트 / 비정형 텍스트·이미지에서 주문 자동 추출(카톡·문자 주문을 구조화된 주문서로) / LLM 연동 설계·비용 최적화 |
| 인프라·운영 | 클라우드 구축 / Docker / 블루-그린 무중단 배포 / CI/CD 자동화 / 위험한 DB 변경 자동 차단 / 통합 모니터링·로그·알림 / 오류 추적 / 사용자 행동 분석 / 운영 인수인계·교육 |
협업 형태 — 원하시는 방식에 맞춥니다
| 턴키 (도급) | 요구사항 정리부터 설계·개발·검수·배포·이관까지 전 과정을 책임집니다. 고정가 계약, 마일스톤별 대금 지급. |
| 개발 파트너 | 기획·디자인이 이미 있는 곳에 개발 리소스로 상시 협업. 작은 건부터 시작 가능. |
| 운영·유지보수 | 구축 이후 월 정액으로 장애 대응·기능 개선·모니터링 운영. 저희가 만들지 않은 시스템도 인수 가능합니다. |
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서05
06
대표 레퍼런스 — 「함께팜」
산지직송 커머스 플랫폼 · 운영 중산지 생산자와 소비자를 직접 잇는 커머스 플랫폼입니다. 외주로 받은 프로젝트가 아니라 저희 회사의 서비스이며, 기획·개발·운영을 전부 자체 수행하고 현재도 실제 주문과 정산이 발생하는 운영 환경입니다. 그래서 "만들어봤다"가 아니라 "매일 지키고 있다"고 말씀드릴 수 있습니다.
하나의 플랫폼, 네 개의 사용자 표면
| 표면 | 제공 기능 |
|---|---|
| 고객 | 탐색·검색·상품 상세·장바구니·주문·결제·선물하기·리뷰·구독·라이브/숏폼 시청·AI 쇼핑 상담·1:1 문의·마이페이지·알림 |
| 판매자(생산자) | 입점 신청·심사, 상품·재고 등록, 주문·발송 처리, 정산 조회·출금 신청, 커뮤니티, 전용 모바일 ERP 앱, AI 판매 도우미 |
| 파트너(영업망) | 판매자 유치·심사 연계, 리워드 산정·지급 요청, 실적 조회 |
| 본사 관리자 | 주문·배송·정산·회원·상품 통합 관리, 통계·리포트, CS·신고 처리, 콘텐츠 운영, 앱 버전 관리, 권한·승인 체계 |
함께 운영 중인 주변 시스템
| AI 상담 서비스 | 지식베이스를 벡터화해 근거 기반으로 답하는 별도 검색 서비스. 이 서비스가 죽어도 본 서비스는 정상 동작하도록 폴백 설계 — 장애 격리의 실제 사례입니다. |
| 주문 자동화 앱 | 카톡·문자·밴드로 들어온 비정형 주문 텍스트와 스크린샷을 AI로 구조화해 주문서·송장 엑셀까지 만들어주는 독립 앱. 주소·우편번호 자동 보정 포함. |
| 배송 추적 수집기 | 택배사 배송 상태를 주기적으로 수집해 주문 상태에 자동 반영하는 배치 시스템. |
| 통합 관측 스택 | 여러 서비스·서버의 지표와 로그를 하나의 대시보드로 통합 (→ 08장). |
기술적으로 풀어낸 것 — 실제 운영에서 나온 해법
무중단 배포와 안전한 DB 변경
신·구 버전이 잠시 공존하는 블루-그린 배포에서 컬럼 삭제 한 줄이 장애를 만듭니다. 스키마 변경을 2단계로 쪼개는 규칙을 세우고, 위험한 변경은 CI가 배포를 자동 차단하도록 만들었습니다.
외부 연동 장애가 번지지 않게
외부 API 하나가 응답을 안 주면 요청이 쌓여 무관한 화면까지 함께 멈춥니다. 전역 타임아웃 상한과 트랜잭션 경계 분리로 "한 곳의 지연이 전체 장애가 되는" 구조를 끊었습니다.
권한은 4중으로 막습니다
판매자가 남의 상품·정산을 보거나 고칠 수 없도록 진입 차단 → 화면 재확인 → 서버 소유권 검증 → DB 행 단위 정책까지 겹으로 방어합니다. 한 겹이 뚫려도 데이터는 지켜집니다.
검색과 통계를 실제로 씁니다
전문 검색엔진 기반 상품 검색에 더해, 어떤 검색어가 실제 구매로 이어졌는지를 집계해 관리자 화면에서 바로 봅니다. 만들어두고 안 보는 통계가 아닙니다.
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서06
07
결제 · 정산 · 자금 흐름
저희가 가장 강한 영역거래 플랫폼에서 가장 사고가 잦고, 가장 늦게 발견되는 곳이 결제와 정산입니다.
결제는 "성공 / 실패" 두 가지가 아닙니다. 승인 대기, 웹훅 지연, 중복 승인, 망 취소, 부분 취소, 결제창만 닫고 이탈… 상태가 십수 가지입니다. 정산은 더 위험합니다 — 한 번 잘못 쌓이면 되돌릴 수 없고, 상대에게 돈이 잘못 나간 뒤에야 발견됩니다.
결제를 붙여본 팀은 많습니다. 하지만 부분취소 정산 역산 · 할인 부담 주체 · 펌뱅킹 실지급 · PG 자동 대사까지 운영해본 팀은 드뭅니다.
결제는 "성공 / 실패" 두 가지가 아닙니다. 승인 대기, 웹훅 지연, 중복 승인, 망 취소, 부분 취소, 결제창만 닫고 이탈… 상태가 십수 가지입니다. 정산은 더 위험합니다 — 한 번 잘못 쌓이면 되돌릴 수 없고, 상대에게 돈이 잘못 나간 뒤에야 발견됩니다.
결제를 붙여본 팀은 많습니다. 하지만 부분취소 정산 역산 · 할인 부담 주체 · 펌뱅킹 실지급 · PG 자동 대사까지 운영해본 팀은 드뭅니다.
| 영역 | 운영 중인 범위와 그것이 어려운 이유 |
|---|---|
| 결제 수단 | 카드(온라인 PG) · 간편결제 · 가상계좌 · 실시간 계좌이체 · VAN 카드(오프라인 단말) · 문자 청구서 결제 · 자사 예치금(충전·잔액·거래원장). ▸ 수단마다 승인·취소·입금 시점·정산 주기가 전부 다릅니다. 이걸 하나의 거래 상태로 통합하지 않으면 운영자가 수단별로 다른 화면을 봐야 하고, 정산은 영원히 안 맞습니다. |
| 결제 안정성 | 승인 재시도 + 멱등 처리(같은 요청이 두 번 들어와도 중복 결제 없음) · 웹훅 수신·라우팅 · 웹/앱 리다이렉트 분기 · 외부 연동 타임아웃과 DB 트랜잭션 경계 분리 · 미완료 결제 자동 정리 스케줄러 · 결제-재고(좌석·시간) 예약 연동. ▸ 사용자가 결제창만 닫고 나가면 그 건이 재고를 계속 붙잡고 있습니다. 품절이 아닌데 품절로 보이는 현상의 대부분이 이것입니다. |
| 취소·환불 | 전체 취소 / 부분 취소·부분 환불 / 환불 매출 원장 분리 기록 / 할인 부담 주체(플랫폼·공급자·프로모션)에 따른 환불액 재계산. ▸ 3개 중 1개만 반품하면 쿠폰 할인은 어떻게 나눠야 할까요? 단순 차감으로 처리하면 그 순간엔 맞아 보이지만 월말 정산에서 반드시 어긋납니다. |
| 정산 | 공급자별 월 정산 마감 · 명세서 발행 · 정산 항목 및 조정(adjustment) 이력·감사 로그 · 멱등키로 중복 정산 차단 · 월 단위 유일성 보장 · 보류(on-hold) 상태 · 미수·차감 관리. ▸ 정산의 본질은 계산이 아니라 "왜 이 금액인지 설명 가능한가"입니다. 근거를 못 대면 매달 엑셀 수기 대조가 시작됩니다. |
| 지급(출금) | 펌뱅킹 REST API 실지급 · 자동이체(출금이체) 배치 파일 규격 대응 · 셀프 출금 · 관리자 일괄 출금 · 지급 요청 승인/반려 워크플로 · 리워드·당첨금 지급 · 지급 거래번호 추적. ▸ 여기서부터는 실수가 곧 돈입니다. 승인 절차·중복 지급 차단·실패 재처리·이력 추적이 없으면 사고가 납니다. |
| 세무 | 전자세금계산서 발행 데이터 생성 · 항목별 부가세 분리 · 과세/면세 혼재 처리. ▸ 한 주문에 과세와 면세가 섞여 있습니다. 처음부터 항목별로 분리해두지 않으면 나중에 전체를 다시 계산해야 합니다. |
| 대사(정합성) | PG 거래 내역과 내부 원장의 정기 자동 대사 · 불일치 탐지 · 실패 시 백오프 재시도 · 지표·알림 연동. ▸ 장부가 맞는지 시스템이 매일 스스로 검사합니다. 대부분의 서비스는 월말에 사람이 발견하고, 그때는 이미 늦습니다. |
결제·정산이 포함된 프로젝트라면, 착수 전에 이것부터 여쭙습니다
돈의 흐름
- 대금은 플랫폼 계좌를 거치는가, 공급자에게 직접 가는가
- 정산 주기와 마감 기준일 (거래일? 확정일?)
- 수수료는 어느 금액에 붙는가 (배송비 포함? 할인 전·후?)
- 출금은 신청제인가, 자동 지급인가
예외 상황
- 부분 취소 시 할인과 부대비용은 어떻게 나누는가
- 정산 후 환불이 발생하면 다음 달에서 차감하는가
- 공급자 잔액이 마이너스가 되면 어떻게 하는가
- 과세·면세가 한 건에 섞이면 어떻게 처리하는가
※ 이 질문들에 답이 없는 상태로 개발을 시작하면 거의 예외 없이 오픈 두세 달 뒤 정산 재작업이 발생합니다. 저희가 착수 전에 시간을 쓰는 이유입니다.
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서07
08
기술 스택 · 운영 가시성
터지고 나서 아는 일을 없앱니다기술 스택
| 백엔드 | Java 17 · Spring Boot 3.5 · JPA / QueryDSL · Spring Security + JWT · Gradle 멀티모듈(API / 배치 워커 / 도메인 코어 분리) |
| 데이터 | PostgreSQL 16 · Flyway 스키마 버전 관리 · Redis · OpenSearch(전문 검색) · pgvector(벡터 검색) |
| 웹 | Next.js 15 (App Router) · TypeScript · Tailwind CSS v4 · TanStack Query · Zustand · React Hook Form + Zod · Radix UI · Storybook 디자인 시스템 |
| 모바일 | Flutter (iOS · Android 동시) · Riverpod · go_router · Firebase · FCM |
| AI | FastAPI (Python 3.12) · pgvector 시맨틱 검색 · Gemini / OpenAI · RAG 파이프라인 · 대화 학습·피드백 루프 |
| 인프라 | AWS 다중 계정 운영 · Docker · Nginx · 블루-그린 무중단 배포 · GitHub Actions CI/CD |
| 품질 | JUnit · Testcontainers · Vitest · Playwright · Flutter 골든(픽셀) 테스트 · Spotless 포맷 강제 · 브랜치 보호 + 코드오너 릴리스 승인 |
대부분의 외주 결과물은 납품 시점엔 잘 돌지만, 운영에 들어가면 무슨 일이 일어나는지 아무도 모르는 상태가 됩니다. 장애는 고객이 전화해서 알게 되고, 원인은 "재현이 안 돼서" 못 찾습니다. 저희는 관측 체계를 나중에 붙이는 옵션이 아니라 기본 구성으로 넣습니다.
운영 가시성 — 5개 층으로 봅니다
| ① 인프라 지표 Prometheus + Grafana | CPU·메모리·디스크·응답시간·처리량·에러율 수집. 여러 서비스와 서버를 하나의 Grafana로 통합합니다 — 서비스마다 대시보드를 따로 두면 관리도 배로 늘고 교차 분석이 불가능해집니다. |
| ② 로그 Loki | 전 서비스 로그를 한곳에 수집하고 요청 추적 ID를 부여합니다. "이 고객의 이 건"이 어느 서버 어느 로그를 거쳐 어디서 실패했는지를 한 번에 추적합니다. |
| ③ 알림 Alertmanager | 임계치 초과 시 자동 통보 + 외형 감시. 사람이 대시보드를 계속 보고 있을 필요가 없어야 관측 체계가 유지됩니다. |
| ④ 오류 추적 Sentry | 웹과 모바일 앱에서 실제 사용자에게 발생한 오류를 스택 트레이스·기기·OS·재현 경로와 함께 수집. 사용자가 문의하기 전에 개발팀이 먼저 압니다. |
| ⑤ 사용자 행동 PostHog | 웹·고객 앱·공급자 앱의 접속·화면 이동·이탈을 동일 사용자 기준으로 통합 계측하고, 관리자 화면 안에서 바로 조회되도록 연결합니다 — 담당자가 별도 도구에 로그인하지 않아도 되게. |
그래서 장애가 났을 때 이렇게 흘러갑니다
| ① 탐지 | 지표 이상 또는 오류 급증을 시스템이 먼저 감지합니다. 고객 전화가 첫 신호가 아닙니다. |
| ② 통보 | 임계치 초과 시 담당자에게 자동 알림. 야간·주말에도 사람이 화면을 지킬 필요가 없습니다. |
| ③ 추적 | 요청 추적 ID로 어느 서비스의 어느 지점에서 실패했는지를 즉시 좁힙니다. |
| ④ 조치 | 수정 후 무중단 배포로 반영. 심각하면 이전 버전으로 즉시 되돌립니다. |
| ⑤ 재발 방지 | 같은 유형이 다시 나지 않도록 자동 검사나 알림 규칙을 추가합니다. |
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서08
09
기획 역량과 일하는 방식
받아 적는 팀이 아닙니다대부분의 개발 외주는 "주신 기획서대로 만들어드립니다"에서 시작합니다. 그런데 실패하는 프로젝트의 대부분은 개발이 아니라 기획의 빈칸에서 무너집니다. 저희는 플랫폼을 직접 기획해서 만들고, 그 결정의 결과를 운영으로 감당해본 팀입니다. 그래서 기획서를 받으면 "여기 정하지 않으면 나중에 반드시 문제가 됩니다"를 먼저 말씀드립니다.
착수 전에 저희가 반드시 짚는 것들
| 돈 | 수수료율은 누가 부담하는가 / 할인은 플랫폼·공급자 중 누가 부담하는가 / 부분 취소 시 할인과 부대비용은 어떻게 나누는가 / 정산 주기와 마감 기준일 / 미수는 어떻게 회수하는가 |
| 회원 | 탈퇴하면 거래·리뷰·정산 데이터는 어떻게 되는가 / 등급은 무엇으로 산정하고 언제 갱신되는가 / 사업자 회원과 개인 회원의 차이 / 휴면 처리 기준 |
| 거래 | 어디까지 취소 가능한가 / 부분 취소를 허용하는가 / 재고 소진 시 자동 취소인가 부분 이행인가 / 위약금·수수료 차등 규칙 |
| 권한 | 공급자는 자기 데이터만 본다 — 그 "자기"의 경계는 어디인가 / 본사 권한을 몇 단계로 나눌 것인가 / 중요한 변경에 승인 절차가 필요한가 |
| 운영 | 이 화면을 하루에 몇 번 쓰는가 / 담당자가 몇 명인가 / 지금 엑셀로 하고 있는 일 중 무엇을 자동화할 것인가 / 성수기 물량은 평소의 몇 배인가 |
"일단 만들고 나중에 정하죠"가 가장 비쌉니다. 정산 정책은 거래 데이터 구조를 결정하고, 권한 경계는 DB 설계를 결정합니다. 개발이 절반 지난 뒤에 바꾸면 바꾸는 비용이 처음부터 만드는 비용보다 큽니다.
일하는 방식 4원칙
① 범위를 문서로 고정합니다
착수 전 화면 단위·API 단위로 과업 범위를 확정하고 포함/불포함을 명시합니다. 범위 밖 요청은 즉시 별도 견적으로 회신 — 거절이 아니라 가격과 일정으로 답합니다.
② 매주 문서로 보고합니다
진척률 · 이번 주 완료 · 다음 주 계획 · 블로커와 확인 필요 사항을 공유합니다. 개발 서버를 상시 공개해 언제든 직접 눌러보실 수 있게 합니다.
③ 배포와 장애를 전제로 설계합니다
무중단 배포, 위험한 DB 변경 자동 차단, 지표·로그·오류추적을 처음부터 넣습니다. 오픈 전에 문제가 보이게 만드는 구조입니다.
④ 인수인계까지가 납품입니다
코드·API 문서·운영 매뉴얼·배포 절차를 넘기고 담당자 교육을 진행합니다. 저희 없이도 돌아가는 상태를 만드는 것이 완료 기준입니다.
이런 경우에 특히 잘 맞습니다
- 기획이 아직 정리되지 않은 경우 — 요구사항 정의부터 함께 시작합니다. 기획서가 없어도 괜찮습니다.
- 거래·정산·운영이 얽힌 서비스 — 업종과 무관하게 놓치기 쉬운 예외 케이스를 먼저 짚습니다.
- 현장 운영 도구(ERP·백오피스)가 필요한 곳 — 웹 관리자와 현장용 모바일 앱을 함께 설계해본 팀입니다.
- 기존 서비스가 느리거나 자주 죽는 경우 — 원인 진단부터 배포·모니터링 체계 수립까지 정리해드립니다.
- 이미 기획·디자인이 준비된 경우 — 개발 파트너로 붙되, 기획의 빈칸이 보이면 반드시 짚어드립니다.
케이엠에스대한민국산지직송(주) — 수탁 개발 역량 소개서09
10
진행 절차 및 산출물
프로젝트 규모별같은 절차를 모든 프로젝트에 똑같이 적용하지 않습니다. 규모가 작으면 절차가 비용이 되고, 규모가 크면 절차가 없어서 실패합니다.
| 구분 | 기간 | 대표적인 경우 |
|---|---|---|
| A · 소규모 | 4~8주 | 단일 목적 웹, 기존 서비스 기능 추가·개편, 관리자 도구 단독 구축, 외부 API 연동 건 |
| B · 중규모 | 2~4개월 | 예약·커머스·회원제 서비스 신규 구축, 모바일 앱 1종, 결제 연동 포함 |
| C · 대규모 | 4~8개월 | 다중 사용자 표면 + 결제·정산 + 앱 + ERP + 외부 연동 다수, 기존 데이터 이관 |
A · 소규모 — 가볍고 빠르게
| 요구사항 확정 | 2~3일 | 화면 목록·기능 정의 확정 → 과업범위확정서(SOW), 확정 견적 |
| 설계 | 3~5일 | 화면 흐름, 데이터 구조 → 화면 목록, API 명세 |
| 개발 | 3~6주 | 개발 서버 상시 공개 · 주 1회 서면 보고 |
| 검수·배포 | 1주 | QA·수정 → 운영 배포, 간이 운영 매뉴얼 |
| 하자보수 | 3개월 | 계약 범위 내 결함 무상 수정 |
※ 설계 문서를 최소화하고 동작하는 화면으로 합의합니다.
B · 중규모 — 스프린트 + 격주 데모
| 요구사항·기획 | 1~2주 | 이해관계자 인터뷰, 기획 보완 및 정책·예외 케이스 정의 포함 → SOW, 기능정의서, 화면 목록, 확정 견적 |
| 설계 | 2~3주 | DB 스키마(ERD), API 명세(Swagger), 아키텍처 구성도, 화면 설계 |
| 개발 | 6~10주 | 2주 스프린트 · 격주 데모 · 주간 리포트 · 개발 서버 상시 공개 |
| 통합·검수 | 2~3주 | 외부 연동 실검증(결제·물류·소셜·알림), QA 시나리오 수행 → QA 결과서, 성능·보안 점검 |
| 배포·이관 | 1주 | 운영 환경, CI/CD, 모니터링·오류추적 연결 → 운영 매뉴얼, 배포 절차서, 담당자 교육 |
| 하자보수 | 6개월 | 계약 범위 내 결함 무상 수정 (이후 유지보수 계약 전환 가능) |
C · 대규모 — 전담 PM + 단계별 오픈
| 착수·현행 분석 | 2~3주 | 현행 업무·데이터 조사, 부서별 인터뷰 → 현행 분석서, 요구사항 정의서, WBS, 전담 PM 배정 |
| 아키텍처·정책 | 3~4주 | 도메인 분리, 권한 체계, 정산·수수료·환불 정책 확정 → 아키텍처 설계서, ERD, API 명세, 업무 정책 정의서 |
| 개발(2~3 페이즈) | 12~24주 | 페이즈별 부분 오픈(예: 1차 고객·거래 → 2차 정산·ERP → 3차 앱) · 격주 데모 · 월간 운영 보고 |
| 데이터 이관 | 3~4주 | 기존 데이터 정제·이관·검증, 리허설 2회 이상 → 이관 계획서, 검증 결과서, 롤백 절차 |
| 검수·안정화 | 3~4주 | 통합 테스트, 부하 테스트, 보안 점검, 파일럿 운영 → 성능·보안 보고서 |
| 오픈·이관 | 2주 | 무중단 배포 체계, 관측 대시보드·알림 구성, 운영 매뉴얼, 담당자 교육 2회 이상 |
| 하자보수 | 6~12개월 | 결함 무상 수정 + 월 정액 유지보수 전환 권장 |
전 구간 공통 산출물
과업범위확정서(SOW, 포함/불포함 명시) · 기능정의서 · 화면 목록 · DB 설계서(ERD) · API 명세 · QA 시나리오 및 결과서 · 배포 절차서 · 운영 매뉴얼 · 주간 진행 리포트 · 전체 소스코드 및 저작권 이전 · 담당자 교육
대금 지급 — 마일스톤 연동
A 착수 50 / 검수 후 잔금 50
B 착수 30 / 설계 완료 40 / 검수 후 잔금 30
C 착수 20 / 페이즈별 분할 60 / 최종 검수 후 잔금 20
각 회차는 마일스톤 산출물 인도 시점에 청구. 검수는 서면 10영업일 기준. 모든 금액 VAT 별도.
먼저 30분만 이야기해보셔도 좋습니다.
업종이 무엇이든, 현재 운영 방식을 듣고 기능 목록 · 예상 일정 · 개략 견적을 문서로 정리해 무상으로 보내드립니다.
그 문서만 가져가시고 다른 업체와 비교하셔도 괜찮습니다.
admin@k-p2c.com
업종이 무엇이든, 현재 운영 방식을 듣고 기능 목록 · 예상 일정 · 개략 견적을 문서로 정리해 무상으로 보내드립니다.
그 문서만 가져가시고 다른 업체와 비교하셔도 괜찮습니다.
admin@k-p2c.com
케이엠에스대한민국산지직송(주) · admin@k-p2c.com10