[플랫폼 · 양면 매칭] 개발자 1명이 3개 플랫폼을 3개월에 만든 법 | 건설인력 매칭 사례
대한건설기계협동조합의 건설현장 인력 매칭 플랫폼은 Android·iOS·Web 3개 플랫폼을 기획 1·디자인 1·개발 1, 3개월 만에 만들었어요. 인원을 늘리지 않고 범위를 좁힌 판단 3가지를 실제 화면으로 짚어봤어요.
미리 요약하면 — 대한건설기계협동조합의 건설현장 인력 매칭 플랫폼은 Android·iOS·Web 세 플랫폼을 기획 1명·디자인 1명·개발 1명이 3개월 만에 만들었어요. 인원을 늘린 게 아니라 화면과 흐름을 좁힌 판단이 먼저 있었어요. 실제 화면 세 장으로 그 판단을 짚어봐요.
“세 플랫폼을 같이 만들어야 하는데 개발자는 한 명뿐이에요.” 이런 요청을 받으면 보통 인원부터 늘리자는 답이 나와요. 그런데 [플랫폼 · 양면 매칭] 대한건설기계협동조합 건설현장 인력 매칭 플랫폼(Android·iOS·Web, 2022.11 출시)은 반대로 풀었어요. 사람을 늘리는 대신 화면과 흐름을 좁혔어요.
1. 문제 — 세 플랫폼, 개발자 한 명, 석 달이 계산에 맞나요
세 플랫폼을 동시에 만드는 프로젝트는 보통 화면마다 사람이 붙어야 일정이 맞아요. 그런데 이 프로젝트는 기획 1명·디자인 1명·개발 1명으로 Android·iOS·Web을 3개월에 열었어요.
| 항목 | 내용 |
|---|---|
| 분류 | 플랫폼 · 양면 매칭 |
| 플랫폼 | Android · iOS · Web |
| 출시 | 2022년 11월 |
| 개발 기간 | 3개월 |
| 투입 | 기획 1 · 디자인 1 · 개발 1 |
발주처는 건설현장과 장비 기사를 잇는 매칭 서비스를 원했어요. 전화와 지인 소개로 돌아가던 연결을 기록이 남는 구조로 옮기는 게 목표였고요. 답은 인원이 아니라 범위에 있었어요.
2. 첫 번째 판단 — 입구를 네 갈래로만 열었어요
실제 메인 화면이에요. 앱을 켜면 일감·발주하기·근로이력·내정보, 딱 네 갈래만 보여요. 매칭 서비스는 검색·필터·리뷰·채팅까지 붙이자면 끝이 없는데, 여기서는 “일을 받는다”와 “일을 맡긴다”라는 두 역할부터 나누고 그 위에 최소한만 얹었어요.
화면 아래에는 그달의 성사된 거래 수와 사용자 수를 숫자로 그대로 보여줘요. 기능을 늘리는 대신, 이 판이 실제로 돌아가고 있다는 증거부터 세운 거예요.
3. 두 번째 판단 — 확정 단계는 빼지 않았어요
화면을 좁혔다고 단계까지 줄인 건 아니에요. 차량을 공차로 등록하는 흐름을 보면, 차량을 고른 다음 “이 차량을 공차로 등록하시겠습니까?”로 한 번 더 확인을 받아요.
이 화면이 빠지면 어떻게 될까요. 잘못 누른 등록이 그대로 진행되고, 취소하려면 결국 전화를 걸어야 해요. 그럼 시스템에 기록이 안 남고 예전 방식으로 되돌아가요. 화면을 줄일 곳과 줄이면 안 되는 곳을 가르는 기준이 이 지점에 있어요.
4. 세 번째 판단 — 이력을 화면에 그대로 보여줬어요
(화면 속 이름·연락처·차량번호는 시연용 임시 데이터예요.)
일감 상세 화면에는 수주 이력과 발주 횟수가 함께 떠요. 처음 보는 상대를 얼마나 믿을 수 있는지가 매칭 서비스의 가장 큰 장벽인데, 이 숫자가 그 판단을 대신해줘요. 리뷰나 평점 같은 기능을 새로 만드는 대신, 시스템에 이미 쌓인 이력을 꺼내 보여준 셈이에요.
5. 그런데 왜 세 플랫폼은 줄이지 않았나요
화면은 좁혔지만 플랫폼 수는 그대로 셋을 유지했어요. 이유는 이용자 쪽에 있었어요. 현장에서 장비를 찾는 기사는 이동 중에 앱을 켜야 해서 Android·iOS 양쪽이 필요했고, 운영 쪽은 관리자 도구가 웹이 편했어요. 플랫폼 수를 줄이는 대신, 세 화면이 같은 데이터를 보게 만드는 쪽으로 방향을 잡았어요.
그렇다고 남은 일이 쉬웠던 건 아니에요. 등록 → 신청 → 매칭으로 이어지는 흐름을 설계하는 일 자체가 가장 까다로웠어요. 누가 언제 확인하고, 어떤 조건이면 다음 단계로 넘어가고, 취소되면 어디로 돌아가는지. 화면 개수와 무관하게 풀어야 하는 문제라서, 인원을 줄인 만큼 이 설계에 시간을 더 썼어요.
인원을 늘리지 않고 범위부터 좁혀야 하는 프로젝트라면, 어디를 좁힐지부터 함께 정리해봐요. 비슷한 프로젝트가 필요하다면 상담받기 →
6. 발주 전에 정리하면 좋은 질문 3가지
범위를 좁히려는 발주자라면 이 순서로 물어보세요.
- 역할이 몇 갈래인가요 — 이용자를 역할별로 나누면 화면 구조가 단순해져요.
- 확인 없이 진행되면 안 되는 지점은 어디인가요 — 그 지점만큼은 줄이지 마세요.
- 신뢰를 새 기능 대신 기존 데이터로 보여줄 수 있나요 — 이력이나 숫자가 이미 있다면 리뷰 기능부터 만들 필요는 없어요.
이 세 질문에 답이 나오면 화면 수보다 견적이 먼저 정리돼요. PoC(개념 검증)와 MVP(최소 기능 제품)의 범위를 가르는 기준은 PoC와 MVP 차이, 예산은 어떻게 잡을까요에서 더 다뤘어요.
7. 자주 묻는 질문
개발자 한 명으로 여러 플랫폼을 만드는 게 항상 가능한가요?
아니요. 화면을 얼마나 좁히느냐에 달렸어요. 화면이 넓으면 인원이 많아도 기간은 늘어나요.
화면을 좁히면 나중에 기능을 추가하기 어렵지 않나요?
처음부터 데이터 구조를 넓게 잡아두면 어렵지 않아요. 화면은 나중에 붙일 수 있어도 데이터 구조를 다시 짜는 건 손이 많이 가서, 발주 단계에서 미리 확인해두는 게 안전해요.
매칭 플랫폼에서 확정 화면은 꼭 필요한가요?
네. 확정 단계가 없으면 잘못 누른 요청이 그대로 진행되고, 결국 전화로 취소를 처리하게 돼요. 확정 화면 하나가 운영 부담을 크게 줄여줘요.
8. 마무리 — 넓히기 전에 좁힐 곳부터
저희는 자체 SaaS 4종을 직접 운영하면서, 기능을 더하는 결정보다 빼는 결정이 더 어렵다는 걸 계속 배워요. 이 프로젝트에서도 화면을 늘리자는 요청보다 “지금 정말 필요한가”를 먼저 물었고, 그 판단이 3개월이라는 기간으로 돌아왔어요.
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요. 플랫폼 개발 범위를 어디까지 좁혀야 할지 고민이라면, 화면을 그리기 전에 함께 정리해봐요. 비슷한 프로젝트가 필요하다면 상담받기 →
관련해서 함께 보면 좋은 글이에요.