호스트와 청소자가 '청소 완료'를 두고 다투지 않는 서비스를 설계했습니다.
에어비앤비 호스트와 청소자를 잇는 청소 매칭 서비스 루미클린 (외주)
- 기간
- 2025.11 – 외주 완료
- 역할
- PM · 프론트엔드 · 디자인 (3인 팀)
- 상태
- 외주 완료
요약
외주로 맡은 에어비앤비 청소 매칭 서비스입니다. 서로 모르는 호스트와 청소자가 다투지 않으려면 완료 기준이 서비스 안에 있어야 해서, 청소 작업의 상태 흐름 5단계를 먼저 확정하고 전·후 사진 5장을 완료 조건으로 정했습니다. 청소자 화면 전체를 직접 개발해 배포한 뒤 외주를 마무리했습니다.
성과
- 청소 완료 인증 조건 · 전·후 사진
- 사진 5장
- 청소자 화면을 도출한 작업 흐름
- 상태 5단계
- 기획부터 배포까지 · 결제 연동 전 마무리
- 외주 완료
배경
- 에어비앤비 호스트는 믿을 만한 청소 인력을 구하기 어렵고, 청소자는 일감을 안정적으로 받기 어렵습니다. 둘을 연결하는 매칭 서비스를 실제 사용자를 받을 수 있는 수준까지 만드는 것을 목표로 잡았습니다. (외주 · 2025.11 기획·디자인 시작 ~ 외주 완료, 3인 팀 — 서비스명 루미클린(RumiClean), www.rumiclean.com)
- 전체 PM으로 기획·디자인·릴리스 우선순위를 잡고, 청소자용 화면 전체를 직접 개발했습니다.
실행
PM — 우선순위와 배포 의사결정
- 기능 개발부터 배포까지의 우선순위를 정하고, PR 170개가 넘는 저장소의 코드 리뷰·릴리스 머지·QA 프로세스를 관리했습니다.
- 3인 팀 규모에 맞춰 배포를 k3s/ArgoCD에서 Docker Compose + Caddy로 단순화해 유지보수 부담을 줄였고, 배포 중에도 화면이 유지되도록 정적 파일을 CDN(CloudFront)으로 분리했습니다.
프로세스 기반 화면 설계
- 청소 작업의 생애주기를 '수락 대기 → 진행 예정 → 진행 중 → 검수 대기 → 정산 대기' 상태 머신으로 정의하고, 각 상태에서 화면과 입력을 도출했습니다.
- 완료 인증에 전·후 사진 최소 5장 규칙을 두어, 청소 상태를 두고 분쟁이 생기면 서비스에 남은 사진을 근거로 확인할 수 있도록 설계했습니다.
- 카카오맵 지도 검색, Firebase 웹 푸시 등 운영에 필요한 연동을 구현하고, 아토믹 디자인·data-testid QA 규칙으로 팀 코드 일관성을 유지했습니다.
수락 대기
작업 요청 목록 — 숙소·일정·옵션·보수 확인 후 수락/거절
진행 예정
작업 상세 + 캘린더 — 출입 방법·숙소 정보 안내
진행 중
진행 상태 표시 — 작업 중에는 추가 입력을 요구하지 않음
검수 대기
전·후 사진 최소 5장 + 특이사항으로 완료 인증
정산 대기
정산 상태 노출 — 청소자가 지급 시점을 화면에서 확인
기능 목록보다 상태 흐름을 먼저 확정했고, 각 상태에서 필요한 화면과 입력만 남겼습니다. 개발·QA 범위도 이 흐름을 기준으로 나눴습니다.
결과
- GitHub Actions 자동 배포로 www.rumiclean.com에 배포한 뒤 외주를 마무리했습니다. 토스 결제 연동 전에 마무리해 실사용자는 받지 않았습니다. 기획·디자인·개발·배포·QA까지 서비스의 전 과정을 처음으로 맡아 끝낸 외주 프로젝트입니다.
배운 점
- 3인 팀이 k3s를 유지하는 데 시간이 많이 들어 기능 개발이 늦어졌고, 배포 구성을 Docker Compose와 Caddy로 단순화했습니다. 기능을 더하는 것보다 인프라를 팀 크기에 맞게 줄인 쪽이 서비스를 더 안정적으로 만들었습니다.
- 기능 목록부터 쓰면 화면 수만 늘어나기 쉽습니다. 청소 작업의 상태 흐름을 먼저 확정하자 필요한 화면과 입력이 추려졌고, 개발·QA 범위도 이 흐름을 기준으로 나눴습니다.