IT 파트너로 리트머스를 선택한 이유

클라이언트는 구인구직 플랫폼을 기획하면서, 단순 채용 게시판이 아니라
중개·전자계약·과금·수수료 모델까지 연결되는 운영형 제품을 만들고자 했습니다.

특히 이번 프로젝트는 개발 비용보다 “확실한 기능 구현”과 “약 1.5개월의 짧은 소요기간”의 안정적인 준수가 더 중요했습니다.

– 구인/구직 기본 기능은 물론, 구직 차별화와 전자서명 계약 자동화까지 한 흐름으로 완성해야 함
– 모두싸인/도큐싸인 등 전자서명 API 연동은 심사·절차·정책 이슈가 있어, 기획 단계에서부터 기술 검토와 리스크 관리가 필요
– 충전식 과금 + 건단위 수수료 등 BM이 명확해 결제/정산/어드민까지 함께 설계돼야 함
– 광고 배너, KPI 대시보드, 기업 승인/계정 활성화 등 운영 어드민까지 포함된 ‘런칭 가능한 구조’가 요구됨

리트머스는 기획(화면 구조도/기능명세)부터 디자인·개발·PM/QA까지 한 번에 묶어,
기간과 품질을 동시에 통제하는 방식으로 프로젝트를 진행했습니다.

mGPT가 직면한 문제들

1. “구인구직”이 아니라 “알선 거래”로 확장되는 구조의 복잡성

– 알선 영역은 업종/거래 종류에 따라 팀·카테고리·템플릿이 바뀌어, 게시판(CRUD)을 ‘확장 가능한 구조’로 설계해야 함
– 공고 UX는 잡코리아 레퍼런스 수준을 요구하면서도, 향후 카테고리 확장을 고려한 표준 컴포넌트화가 필요

2. 전자서명 API 연동의 절차·정책 리스크

– 전자계약/서명 기능은 단순 기능 추가가 아니라, 서명 전/후 상태 변화가 서비스 운영과 정산 흐름을 좌우
– API 심사 등 외부 절차가 존재해 클라이언트 협조/일정 변수를 전제로 한 기획·개발이 필요
– 계약(소개/중개) 구조에 따라 법적 이슈 검토 포인트가 생길 수 있어 초기에 리스크를 분리해야 함

3. BM을 실제 운영 기능으로 구현해야 하는 난이도

– 월 구독이 아니라 건단위 수수료/충전식 결제라서, 결제는 UI보다 충전·차감·정산에 대한 정책 정의가 먼저 필요
– PG 연동과 심사 대행을 포함해, 런칭 일정 내에 결제–계약–어드민 지표(KPI)가 연결되어야 함

4. “비용”보다 “기간/구현 확실성”이 중요한 일정 제약

– 예상 기간이 1.5개월로 짧아, 요구사항을 넓히기보다 필수 기능 우선순위와 구현 범위를 명확히 해야 함
– PC/MOB 반응형 여부 등 논의 포인트가 있어, 디자인/개발 범위를 초기부터 정합성 있게 고정할 필요가 있었음

계약·과금까지 이어지는 알선형 HR 플랫폼의 운영 구조 정의

리트머스는 상담/견적 단계에서 요구사항을 다음 3가지 축으로 정리했습니다.

1. 기본 HR 플랫폼 완성도

– 구인/구직 공고 등록, 리스트/상세, 공고 활성화, 커뮤니티형 게시판 등 기본 기능을 안정적으로 완성

2. 중개 프로세스의 “계약 체결” 자동화

– 중개/소개 기반 거래 흐름에서 핵심이 되는 전자계약서 작성/열람/서명을 API 연동으로 구현
– API 심사/절차 및 법률 이슈(계약 구조)는 초기부터 리스크로 관리

3. BM을 바로 실험할 수 있는 과금 구조

– 월 구독이 아닌 건단위 수수료/충전형 과금을 전제로 PG 연동과 운영 어드민까지 포함
– 광고 배너 등 부가 수익모델도 함께 탑재

​전자서명 API 연동을 “중개 플로우”에 자연스럽게 결합

전자서명은 붙이기만 하면 끝이 아니라, 서명 전/후 상태 변화가 서비스 운영 전체를 좌우합니다.

리트머스는 계약 작성→열람→서명→완료까지의 상태를 제품 플로우로 정리해 운영 가능한 구조로 만들었습니다.

– 전자계약서 작성/열람/서명/완료 상태 기반 플로우 설계
– Esignon 등 외부 전자서명 API 연동 전제의 기술 검토 포인트 정의
– 심사/절차는 클라이언트 협조 필수로 명확히 범위화

​“충전식 과금 + 건단위 수수료”에 맞는 결제 구조 설계

이번 프로젝트는 월 구독이 아니라, 거래/계약 건 단위 수익이 핵심이었습니다.

그래서 결제는 UI가 아니라 충전/차감/수수료 등 BM의 단위를 먼저 정의하는 방식으로 접근했습니다.

– 업체 고객 대상 충전 기반 과금 모델 전제
– 토스 PG 연동 + 심사 대행 포함 범위 구성

​잡코리아 레퍼런스 수준의 공고 UX를 빠른 기간에 맞춰 표준화

개발 비용보다 확실한 구현/소요기간이 우선이었기 때문에, 핵심 화면을 표준 템플릿으로 정리해 속도를 확보했습니다.

– 공고 리스트 Cell 정보(직무/기업/작성일/D-Day/정원) 표준 컴포넌트화
– 공고 상세/등록 플로우를 반복 개발 없이 확장 가능한 구조로 설계
– 알선 영역 확장을 위해 카테고리/템플릿 기반 게시판 구조(CRUD)로 정리

​구인·구직 및 보험·자동차 분야 양자 계약 플랫폼 기본 기능

이 플랫폼은 구인/구직을 각각 등록하고, 리스트에서 탐색한 뒤 상세에서 확인·문의로 이어지는 기본 HR 플로우를 제공합니다.

– 이메일 회원가입/로그인, 비밀번호 재설정
– 홈 → 팀/카테고리 → 공고 리스트 → 공고 상세
– 공고 등록(or 의뢰) 버튼을 기준으로 핵심 전환 지점 설계
– 관리자 승인 없이 업로드 가능한 커뮤니티형 일반 게시판

​알선 영역 확장형 템플릿 게시판(CRUD)

알선/중개 비즈니스는 업종에 따라 “게시판 구조는 같고 카테고리만 달라지는” 경우가 많습니다.

이를 전제로 운영자가 쉽게 확장할 수 있는 구조를 기본 탑재했습니다.

– 카테고리 구분 기반의 게시판 템플릿
– 등록/수정/삭제 등 CRUD 표준 플로우
– 거래 종류 변경 시 팀/카테고리 기획 확장 가능

​전자서명 기능: 계약서 작성·열람·서명

거래가 성사되는 순간을 제품 안에서 닫기 위해, 전자 계약 기능을 핵심 모듈로 포함했습니다.

– 전자 계약서 작성/열람
– 전자서명 생성 및 서명 기능
– Esignon API 연동

​광고 배너 기반 수익화 영역

플랫폼 수익화를 위해 광고 배너 영역을 포함합니다.

– 배너 노출 영역 확보
– “광고 수익”을 제품 구조에 연결할 수 있도록 기본 틀 구성

​

​​알림 기능: 서명 완료 시점 트리거 메시징

구직 차별화 및 계약 전환율을 위해, 알림 기능을 옵션으로 구성했습니다.

– 알림 시점: 서명 완료 시점
– 카카오톡/이메일/SMS/알림톡 등 채널 연동(NHN 등)
– 알림 서비스 비용/케이스별 비용 구조는 별도(운영 정책에 따라 확장)

​