재개발·재건축 현장 인력 관리 플랫폼
용역이 열리고, 사람을 뽑고, 구역을 나누고, 현장에서 결과를 받아, 등급과 정산으로 닫히기까지의 전 과정입니다. 각 단계마다 누가 · 어느 화면에서 · 무엇이 남는지와, 그렇게 정한 근거 결정을 함께 적었습니다.
오늘 확정 회사는 OS4U 하나입니다. 법인을 나누지 않고 한 회사가 둘 다 운영합니다. 다만 남의 일을 대신 해주는 사업과 우리 사업은 개인정보를 다룰 근거가 서로 달라서, 그 둘을 시스템 안에서 갈라 둡니다. 나누는 것은 법인이 아니라 근거와 권한입니다.
정비업체에게 위탁받아 수행 · OS4U는 수탁자
같은 회사의 자체 사업 · OS4U가 처리 책임자
공통
공통
사업 ②
사업 ①
조직이 이미 둘로 나뉘어 있습니다. 자격 발급·교육·시험은 지도사자격 부문, 현장 투입·수당·이력은 OS사업 부문입니다. 기획·인사·총무와 회계만 공통입니다.
그래서 지도사 이력과 수당은 자격 부문이 아니라 OS사업 부문 소관입니다. 앞서 정한 「지도사 관련은 플랫폼사만」은 그대로 유효합니다 — 두 부문 모두 본사이고, 본부장·팀장은 어느 쪽에도 속하지 않습니다.
※ 「수당 지급 관리」가 조직에 있는 이유가 D86으로 확인됐습니다 — 자금이 OS4U를 경유합니다. OS4U가 용역 인력에게 직접 지급하고, 원천징수 의무자도 OS4U입니다. 다만 실제 이체는 오프라인이고 시스템은 금액 산출까지입니다(D87).
한 회사이므로 회사 사이의 계약은 필요 없습니다. 두 사업은 같은 조직·같은 시스템 안에 있고, 갈라 두는 것은 논리적 격리와 권한입니다 — 별도 법인도, 별도 서버도 아닙니다.
대신 목적 밖으로 넘기지 않습니다. ①의 세대 명부를 ②의 자격·평가에 끌어다 쓰지 않고, ②의 지도사 자격·평가를 발주처 리포트에 넣지 않습니다. 근거가 다른 데이터를 섞으면 어느 쪽 근거로 처리한 것인지 설명할 수 없게 됩니다.
바깥으로 파는 것은 개인정보가 아니라 현장 통계여야 합니다(Q9 답변 방향) — "이 규모·이 조건의 현장은 평균 며칠 걸린다". 여기엔 세대주 이름도 지도사 이름도 필요 없고, 계약이 끝나 개인정보를 다 지워도 통계 자산은 남습니다.
오늘 확정자격증은 회사가 발급합니다. 회원이 요청하면 OS4U가 심사해서 발급합니다 — 밖에서 따온 자격증을 등록받아 대조하는 게 아닙니다.
발급 주체가 우리이므로 자격번호를 우리가 채번하고, 갱신·정지·취소도 우리가 쥡니다. QR 공개 검증이 그제서야 의미를 갖습니다 — 발급자가 확인해주는 것이니까. 교육 이수 → 발급 연동도 자연스러워집니다.
※ 기존 문서의 D62(“발급은 오프라인, 화면은 등록 심사만”)를 뒤집는 결정입니다. 02·04 문서 정정 필요.
앱은 둘, 모드는 넷입니다. 팀장·본부장이 각각 무엇을 하는지, 권한을 어떻게 나눌지에 대한 답입니다.
필요합니다. 단, 현장 모드도 같이 씁니다. 팀장은 담당 구역의 실행 담당이라 현장에 함께 있습니다. 오늘 근무·방문 입력이 매트릭스에 겸직·대행으로 명시돼 있습니다.
그래서 앱을 나누지 않고 역할 메뉴로 갈랐습니다(D15). 나누면 팀장이 앱 두 개를 번갈아 켜야 합니다.
지정과 승인 모드입니다. 본부장만 하는 일이 셋 — 콜 수락, 필요 인원 확정, 팀장 지정. 여기서 운영이 시작됩니다. 선발·배정·교체는 팀장이 지시하고 본부장이 승인합니다.
현장 입력은 예외적으로만 씁니다. 사실상 운영 전용 모드입니다.
같은 앱이 아니라 별도 앱입니다. 백오피스는 독립 Admin API를 쓰는 모노레포 별도 앱이고, 그 안에서 다시 다섯으로 갈립니다.
본사 관리자(전체) · 운영 담당자(정산·설정 제외) · 정산 담당자(2차) · 감사자(읽기 전용) · 세대 찬반 원본 열람자(D22 — 별도 권한 항목이고, 열람 자체가 감사 대상).
권한표를 역할마다 만들지 않습니다. 규칙 하나를 씁니다. 접근권은 배정에서 파생되고 한시적입니다(D23).
갈리는 건 규칙이 아니라 스코프입니다. 역할마다 조건을 따로 쓰기 시작하면 한 곳만 빠뜨려도 조용히 통과합니다.
접근권 = 배정에서 파생 + 한시적 — 세대 주소지는 지도사가 본인 배정분, 팀장이 담당 지도사분, 본부장이 담당 팀장·지도사분을 봅니다. 전부 용역 참여 기간 동안만입니다.
용역이 끝나면 접근이 자동 소멸하고 단말 캐시도 함께 만료됩니다. 메뉴 노출은 서버가 역할·권한으로 결정하고 클라이언트는 렌더만 합니다. 화면에서 버튼을 감추는 건 편의이지 통제가 아닙니다 — 서버가 매번 자격을 다시 봅니다.
오늘 확정지도사에 관한 것은 플랫폼사(OS4U)만 봅니다. 위치 이력 · 근무성실도 평가 · 등급 · 개인정보 — 본부장과 팀장도 볼 수 없습니다.
본부장·팀장은 OS4U 직원이 아니라 개인사업자입니다. 이들에게 지도사의 위치와 평가를 열어주는 것은 또 다른 사업자에게 넘기는 것이라 재위탁 문제가 됩니다(Q6). 세대 주소지와 달리 이건 배정에서 파생되지 않습니다.
그래서 바뀌는 것 — 근무성실도 감사·평가가 팀장 웹에서 빠져 백오피스로 옮겨가고, 평가자가 본사가 됩니다. 팀장은 배정과 진척을 보되 사람은 보지 않습니다.
| 운영 모드 | 누구 | 기기 | 하는 일 |
|---|---|---|---|
| 현장 모드 | 지도사 | Android 앱(주) 웹(보조) |
출퇴근 · 방문 입력 · 내 구역 지도 · 콜함(모집 지원) · 내 실적 |
| 팀장 모드 | 팀장 | 웹(PC·태블릿) + 현장 모드 겸용 |
모집·선발 · 구역배정 · 진행현황 · 교체 지시 · 조직도(담당 구역) 사람은 보지 않는다 — 위치·평가·등급 열람 없음 |
| 본부장 모드 | 본부장 (구역장) |
웹(PC) | 콜 수락 · 필요 인원 확정 · 팀장 지정 / 선발·배정·교체 승인 / 용역 전체 진행현황·조직도 마찬가지로 지도사 위치·평가는 열람 없음 |
| 플랫폼 관리자 | 본사 | 백오피스 (별도 앱) |
용역·현장·명부 · 모집 발송 · 정산(기록) · 모수 제외 승인 · 리포트 · 설정 ＋ 사업② 전부 — 자격 발급·교육·등급·근무성실도 감사·평가 |
오늘 확정 현장 하나가 한 번에 끝나지 않습니다. 같은 대상을 세 번, 매번 다른 기준으로 훑습니다. 구역 배정은 본부장과 팀장의 재량입니다 — 시스템이 정해 주는 것이 아닙니다.
구역 내부에서 건물(물건)을 중심으로 지역을 할당한다. 본부장 또는 팀장이 나눈다.
범위 · 구역 내부
등기부상의 주소를 중심으로 지역을 할당한다. 소유자가 실제로 사는 곳으로 찾아간다.
범위 · 구역 내외부 안 가림
반대자는 집중 설득, 부재지주는 집중 탐색 조사. 구역이 아니라 명단으로 움직인다.
범위 · 제한 없음
이 세 차수가 지금 설계와 정면으로 부딪히는 곳이 있습니다.
① 지오펜스가 2차부터 성립하지 않습니다. 지금 설계는 「활동 가능 영역 = 배정 세대를 감싸는 경계」이고 그 밖으로 나가면 이탈로 잡습니다. 그런데 2차는 구역 밖으로 나가는 것이 정상 업무이고 3차는 아예 제한이 없습니다. 1차 기준을 그대로 두면 2차에서 전원이 이탈자가 됩니다. 차수별로 판정 기준을 달리 가져가야 합니다 — 2·3차는 경계가 아니라 방문 대상지 근접으로 봐야 합니다.
② 세대에 주소가 둘 필요합니다. 물건 주소(1차가 쓰는 것)와 등기부상 주소·현거주지(2차가 쓰는 것). 지금 명부는 물건 주소 하나만 전제하고 있습니다. 2차 버전의 명부 항목(현거주소)이 여기에 맞물립니다.
③ 3차는 배정 단위가 다릅니다. 구역을 나누는 게 아니라 반대자·부재지주 명단을 나눕니다. 지도 위에서 다각형을 그리는 배정 화면으로는 3차를 못 다룹니다.
여섯 단계입니다. 앞 단계가 끝나야 다음이 열립니다 — 계약서가 없으면 명부를 못 올리고, 명부가 없으면 뽑을 인원이 안 나옵니다.
계약서 없는 근거로는 명부를 못 올립니다. 화면 드롭다운이 승인·기간유효·계약서존재 세 조건을 모두 만족한 근거만 읽습니다. 파일은 API 서버를 통과하지 않고 스토리지로 바로 올라가며, DB에는 위치와 해시만 남습니다.
PROCESSING_BASISDOCUMENTLOG_AUDIT위탁 근거 없이는 용역이 생기지 않습니다. 근거 연결이 필수라 데이터 한 행도 근거 없이 적재되지 않습니다.
ENGAGEMENTAI 파싱은 쓰지 않습니다(D43). 명부에 성명·연락처가 있어 외부 전송이 재위탁 문제를 만들고, 무엇보다 같은 파일을 두 번 올렸을 때 결과가 달라지면 계약 목표 판정의 분모가 흔들립니다. 양식을 고정하면 파싱이 결정론적이 됩니다.
헤더를 먼저 검증합니다 — 3,000행을 파싱한 뒤 실패하면 무엇을 고쳐야 할지 알 수 없습니다. 오류행은 셀 단위로 고치고, 원문을 행 단위로 보존하며, 파서 버전을 기록합니다.
ROSTER_TEMPLATEHOUSEHOLD_IMPORTHOUSEHOLD_IMPORT_ROWHOUSEHOLD본사가 상한을 걸고, 실제 확정은 본부장이 합니다. 현장을 아는 쪽이 숫자를 정합니다.
ENGAGEMENT.HEADCOUNT_CAP운영의 시작점입니다. 거절하거나 기한 내 응답이 없으면 다음 후보로 자동 승계됩니다(D45). 본사가 매번 수동 지정하면 착수가 무한정 밀립니다. 무응답과 거절은 구분해 기록하되 처리 결과는 같습니다 — 반복 거절은 재선발 판단 근거가 됩니다.
RECRUITMENT_APPLICATION (SOURCE=DIRECT)통상 배분은 본부장 1 · 팀장 5 · 지도사 200이고, 팀장 한 명이 지도사 40명을 봅니다(D44). 용역 규모에 따라 조정합니다.
ENGAGEMENT.HEADCOUNT_CONFIRMED공고를 내기 전에 아는 사람을 먼저 앉히는 경로입니다. 이 인원만큼 모집 정원에서 빠집니다.
ASSIGNMENT (SELECTION_SOURCE=3)모집 인원 = 직급별 배분 − 사전 배정 인원. 본부장은 이미 찼으니 0, 팀장 5명 중 2명을 지정했으면 3명을 뽑습니다.
RECRUITMENT_QUOTARECRUITMENTNOTIFICATION_CAMPAIGN노출 대상과 발송 대상이 다릅니다(D46). 모집 사실 자체를 감출 이유는 없지만, 자격 없는 회원에게 알림을 보내면 광고성 정보 수신 동의 범위를 넘습니다.
수신동의와 야간(21~08시) 차단은 발송 직전에 확인합니다 — 예약 시점에 동의했어도 그 사이 철회했을 수 있습니다. 차단된 건도 사유와 함께 남깁니다. 안 보낸 것도 기록입니다. 채널은 전부 뿌리지 않고 푸시 → 카톡채널 → 문자 순서대로 폴백합니다(D79).
NOTIFICATION_DISPATCH위치 동의를 가입이 아니라 지원 시점에 받습니다(D53). 용역 단위로 받으므로 참여하지 않는 회원의 동의를 미리 쌓아두지 않습니다 — 과잉수집이 줄어듭니다. 미선정되면 즉시 자동 철회됩니다(D54).
자격이 없으면 공고는 보이되 지원 버튼이 비활성이고 사유를 화면에 적습니다(D48). 다른 공고 지원은 자유이고, 같은 공고 중복 지원만 막습니다.
CONSENT_LEDGERRECRUITMENT_APPLICATION이 화면이 D5의 절충입니다. 요건은 선착순인데 실제 운영은 팀장이 아는 사람을 고릅니다. 그래서 팀장이 먼저 고르고, 남은 정원은 자격충족자 중 접수순으로 자동충원합니다.
자동충원분은 배지로 구분하고 개별 교체할 수 있어야 합니다. 한 명 바꾸려고 전체를 다시 짜게 만들면 안 됩니다. 선착순은 명시적 행 잠금으로 처리합니다 — 낙관적 카운터는 정원 초과를 냅니다. 배정 시점에 급수·등급을 스냅샷으로 굳힙니다(D76) — 이 값이 임금 계산에 쓰입니다.
기간이 겹치는 지원자는 경고만 하고 막지는 않습니다 — 물리적으로 불가능한 건 출근 시점에 막습니다(D79).
RECRUITMENT_APPLICATION.STATUSASSIGNMENT (SOURCE=1/2)LOG_AUDIT한 사람이 두 현장을 동시에 뛸 수 없으니 확정 트랜잭션 안에서 정리합니다. 어느 용역과 겹쳐서 취소됐는지를 남깁니다 — 없으면 "왜 취소됐냐"에 답할 수 없습니다. 본인이 뺀 것과 시스템이 뺀 것은 사유 코드로 구분합니다(D78).
자동 취소 사실을 알려줍니다. 모르고 기다리면 그 기간을 비워둡니다.
CANCEL_REASON_CODECONFLICT_ENGAGEMENT_IDCONSENT_LEDGER참석 여부를 남기는 이유 — OT 불참자가 현장에 나오면 교육 없이 투입된 것입니다. 나중에 사고가 났을 때 "교육을 했는가"에 답해야 합니다.
ENGAGEMENT_EVENTENGAGEMENT_EVENT_ATTENDEE빈 화면과 스피너를 금지합니다(D20). 배정은 전날 밤이나 당일 아침에 이뤄지고, 그때 팀장은 요원들을 모아놓은 상태입니다. 계산을 기다리는 화면을 보여주면 앱을 닫고 다른 수단으로 배정합니다.
생성 중이면 "완료 시 알림"과 함께 직전 용역 배정안을 기본값으로 즉시 편집할 수 있게 둡니다. 실패·타임아웃이면 거리순 단순 분할 대안을 항상 제시합니다 — 추천이 없으면 팀장이 수천 세대를 손으로 못 나눕니다.
각 배정 행에 추천 그대로 / 팀장 수정 / 전면 수동 배지를 남깁니다. 2차에서 자동배정으로 넘어갈지를 이 값으로 판단합니다.
ASSIGNMENT.ZONE_BOUNDARY동의는 지원 시점에 받았지만, 매 근무 시작마다 고지를 다시 띄우고 그 시각을 기록합니다. 담당 구역 밖에서 찍으면 경고만 하고 막지 않습니다 — 대신 승인으로 거릅니다(D81). 출근을 막으면 그날 일이 멈춥니다.
출근 위치를 근태에 남깁니다. 위치 핑은 90일 뒤 파티션째 사라지지만 근태는 정산 근거라 훨씬 오래 남습니다. 핑이 지워진 뒤엔 그날 출근이 현장에서 이뤄졌는지 영영 확인할 수 없습니다. 출근 시점에 임금 조건을 동결합니다.
WORK_SESSIONWORK_WAGE_SNAPSHOT근무 중에는 안드로이드 상단에 "근무 중 위치 수집" 알림이 상시 표시됩니다. 수집 사실이 항상 보이는 것이 곧 투명성 장치입니다. 마지막 동기화 시각과 미전송 건수는 본인 화면에 먼저 보여줍니다.
LOG_LOCATION_PING연락처는 암호화돼 있고 목록 뷰에 넣지 않습니다. 복호화 열람은 목록을 보는 것과 다른 별도의 행위이고 감사 로그에 남습니다.
V_AGENT_HOUSEHOLDLOG_AUDIT (PII_VIEW)탭 한 번이 곧 저장입니다. 저장 버튼을 따로 두면 이동 중에 유실됩니다. GPS를 못 잡아도 저장을 막지 않고 나중에 붙입니다. 원탭이라 오탭이 나므로 정정 경로를 반드시 두되, 원본을 덮어쓰지 않고 정정 이력으로 남깁니다.
동의 여부는 지도사 성과가 아닙니다(D49). 동의·미동의·기타 모두 "의견을 받아온 것"으로 동일하게 셉니다. 동의만 세면 적대적 구역 담당자가 구조적으로 불리해지고, 가중치를 주면 설득을 포기하고 빠른 결론을 받는 유인이 생깁니다.
VISIT_EVENTVISIT_LOCATIONHOUSEHOLD_STATE화면에 "대상 세대에서 빠집니다"라고 쓰지 않습니다. 제외는 팀장·본사 승인 사항이므로 "제외를 요청합니다"로 적어 기대를 맞춥니다. 승인 대기 중에도 그 세대를 계속 담당합니다 — 숨겼다가 반려되면 방문 계획이 꼬입니다.
현장에서 들은 주소·연락처는 명부 원본과 분리 저장하고 "현장확인(미검증)" 배지를 붙입니다.
HOUSEHOLD_FIELD_INFOHOUSEHOLD_CHANGE_REQUEST본인 확인을 우선하고 자정은 방어선으로만 씁니다(D81). 위치 공백 같은 이상은 배치가 따로 잡습니다.
WORK_SESSION.CHECK_OUT_*WORK_ANOMALY대상 세대 수가 곧 동의율의 분모이고, 그 분모가 계약 목표 판정 기준입니다. 지도사가 직접 분모를 줄일 수 있으면 목표 회피가 가능해집니다.
기한이 없으면 큐는 반드시 쌓이고, 승인 지연이 곧 요원의 진척률 하락 → 등급 하락 → 수입 감소로 이어집니다. 그래서 3영업일 SLA를 걸고 경과 영업일을 화면에 띄웁니다(D50).
1차에는 증빙 사진이 없습니다(D30). 대신 위치 대조가 증빙입니다(D84) — 제안한 지도사가 그 집 앞에 실제로 있었는가. 그리고 지도사별 제외 제안률을 감시합니다. 분모를 줄이면 달성률이 올라가는 구조라 남용 유인이 있습니다.
HOUSEHOLD_CHANGE_REQUESTV_PENDING_HOUSEHOLD_CHANGE오늘 변경평가자가 팀장에서 본사로 바뀌었습니다. 지도사의 위치와 평가는 사업②의 데이터이고, 팀장·본부장은 개인사업자라 열람 대상이 아닙니다. 팀장은 배정과 진척만 봅니다.
구역 난이도를 자동 계수가 아니라 사람이 점수로 흡수합니다(D28). 어려운 구역을 맡은 요원이 동의율만으로 불이익받지 않게 하는 장치입니다. 부수 효과로 등급이 위치 데이터로 자동 산정되지 않으므로 자동화된 결정에 대한 거부·설명 요구권 리스크가 줄어듭니다.
대신 평가자·시점·점수·근거를 남깁니다. 용역 단위 평가가 기본이고, 사건 메모를 별도 진입점으로 둡니다.
이 화면을 열었다는 사실 자체가 감사 로그입니다. 감사하는 사람도 감사받습니다.
남은 물음 — 현장을 직접 본 사람은 팀장인데 평가는 본사가 합니다. 본사가 무엇을 근거로 점수를 매길지(위치 이력 + 방문 실적만으로 충분한지, 팀장의 정성 의견을 사람을 특정하지 않는 형태로 받을 방법이 있는지)를 정해야 합니다.
D86 개정등급은 더 이상 돈에 닿지 않습니다. 등급별 지급률(A 95% ~ D 80%)이 폐지됐습니다. 등급은 이제 평가와 선발 판단에만 씁니다.
1차는 수동 부여이지만 무엇을 보고 정했는지가 남아야 합니다(D56) — 평가 점수 · 의견 접수율 · 근태·이탈의 3축. 자동 산정은 2차입니다.
D86 개정자금이 OS4U를 경유합니다. 예전 결정(D25 「정비업체가 지급, OS4U는 자금 미경유」)이 폐기됐습니다. OS4U가 용역 인력에게 직접 지급하고, 따라서 원천징수 의무자도 OS4U입니다. 전자금융거래법 · 수수료 명목(D8) · 근로자성(L6) 판단이 전부 여기에 걸립니다.
계산은 현업 계산표를 그대로 옮겼습니다. 일당 = 표준일당 + 직책수당. 개별 성과에서 수수료를 떼고(FEE_RATE), 그 총수수료가 성과급의 재원이 되며, 실수령액에서 3.3% 원천징수합니다. 요율은 전부 용역 공고 시점에 확정됩니다(D76) — 지원자가 공고에서 본 금액이 나중에 바뀌면 안 되니까요.
임금이 두 층으로 갈립니다. 회차 일당은 매일 굳지만, 성과급은 총수수료가 확정돼야 나눌 수 있어 용역이 끝난 뒤 계산됩니다. 한 테이블에 섞으면 "성과급이 안 나온 회차"가 정산에서 조용히 빠집니다.
성과급은 직책 구분 없이 개별성과에 비례해 나누고, 금액은 전부 원 단위 절사합니다(D88). 균등 분배하면 10일 나온 사람과 20일 나온 사람이 같은 성과급을 받고, 반올림하면 성과급 합계가 재원을 넘어섭니다(지도사 60명에서 3원 초과했습니다).
마감이 명세보다 먼저입니다(D89). 마감 없이 명세를 뽑으면 산출 후에 보정이 들어와 명세와 실제가 어긋나고, 그대로 지급하면 되돌릴 수 없습니다. 마감 전에는 구역 밖 출근 승인 대기가 비어 있어야 합니다 — 남아 있으면 그 회차는 지급에서 빠진 채 구간이 닫힙니다.
실제 이체는 시스템 밖입니다(D87). 플랫폼은 「얼마를 줘야 하는가」까지만 하고, 담당자가 지급 명세서를 받아 은행에서 처리합니다. 발주처 입금 테이블도 만들지 않습니다 — 시스템이 모르는 사실을 붙들면 항상 실제와 어긋난 잔액을 보여줍니다. 다만 상태(산출 → 확정 → 지급완료)는 남깁니다. 없으면 같은 명세를 두 번 지급했는지 알 수 없습니다.
WORK_WAGE_SNAPSHOTWORK_PAYOUTV_PAYOUT_STATEMENT발주처에 나간 집계는 계약 판정 근거이므로 사후 재계산으로 값이 달라지면 안 됩니다. 정정이 필요하면 별도 절차를 거칩니다.
제외 건수와 사유를 리포트에 명시합니다. 숨기면 나중에 분모 다툼이 됩니다. 발주처에는 집계·구역 단위까지만 노출하고 요원별·세대별 원본은 내부 전용입니다.
오늘 확정 한꺼번에 전산화하지 않습니다. 1차는 현재 업무 형태를 그대로 두고 자격과 근태만 시스템으로 가져옵니다.
※ 현재 지도사 업무 형태를 유지한다 — 업무 형태와 업무 보고는 기존 오프라인 그대로.
※ 현거주소가 여기 들어오면서 작업 2차수(등기부 주소 중심)가 비로소 가능해진다.
지금까지 만들어 둔 화면이 실제로는 이 차수에 속합니다. 오늘 시연할 때 이 구분을 같이 말해야 기대가 어긋나지 않습니다.
| 만들어 둔 화면 | 속하는 버전 | 비고 |
|---|---|---|
| 지도사 홈 · 출퇴근 | 1차 | 출퇴근·동선 위치가 1차 범위 |
| 콜함 (모집 지원) | 1차 | 모집 콜이 1차 범위 |
| 내정보 — 자격증 · 수당 | 1차 | 자격증 관리가 1차 중점. 자기 수당 관리 포함 |
| 방문 결과 입력 | 2차 | 1차는 업무 보고가 오프라인 유지 — 1차 시연에서 빼야 한다 |
| 구역 지도 | 1차는 구역명만 | 1차 지도사 앱은 「근무 구역명」까지. 지도 배정 화면은 뒤 |
| 근무성실도 감사 | 1차 (회사 모드) | 동선 위치 관리가 1차 범위. 단 평가·등급 부착은 뒤 |
| 모집·선발 (팀장) | 3차 | 본부장·팀장 모드가 3차. 1·2차에는 팀장 웹이 없다 — 배정·선발은 오프라인 재량 |
| 구역 배정 (팀장) | 3차 |
미결 19건 중 오늘 대화에서 답이 나오면 좋을 것들입니다. ★는 리드타임이 길어 개발과 무관하게 지금 착수해야 하는 항목입니다.
런칭 선결이고 리드타임이 가장 깁니다. 신규 법인 명의로 신고해야 해서 법인 설립이 선행됩니다. 안 하면 위치 기능 자체를 켤 수 없고, 그러면 앱의 핵심이 멈춥니다. 기본값으로 넘길 수 없는 유일한 항목입니다.
본인확인기관 계약·비용, CI 저장 범위, 미성년·외국인 처리, 자격증·통장 사본의 수집 근거와 보관·파기. 자문과 계약이 끝나야 가입 기능을 붙일 수 있습니다.
개인사업자로 정했으나 계약 주체(정비업체)와 지휘 주체(본부장)가 달라 사용자 판정이 다퉈질 수 있습니다. 계약서만이 아니라 운영 방식까지 함께 설계해야 합니다.
정비업체 → OS4U → 본부장 → 지도사가 재위탁인지 제3자 제공인지에 따라 문서 형식이 달라집니다.
급수·등급·거리·과거 참여 중 무엇을 먼저 보여줄지입니다. 3.5 선발 화면에 바로 걸립니다 — 팀장이 41명을 훑을 때 맨 위 열 명이 사실상 선정됩니다.
1차에는 사진이 없고 위치 대조가 증빙입니다(D84). 거리 몇 m 안이면 승인인지, 방문 몇 회 이상이어야 하는지를 정해야 팀장이 매번 감으로 판단하지 않습니다.
1차는 수동입니다. 자동으로 넘길 때 어떤 지표를 어떤 가중치로 볼지 — 그리고 자동화하는 순간 설명 요구권 대응이 다시 문제가 됩니다.
발주처가 실제로 받는 문서 형식입니다. 실물 샘플을 한 부 확보하면 6.5가 바로 설계됩니다.
가장 급합니다. 1차는 구역 경계가 있지만 2차는 구역 밖이 정상이고 3차는 제한이 없습니다. 지금 만든 지오펜스 이탈 감사를 그대로 쓰면 2차에서 전원이 이탈자가 됩니다. 2·3차는 경계 대신 방문 대상지 근접으로 볼지, 아니면 위치 판정을 1차에만 적용할지 정해야 합니다.
D86으로 OS4U가 직접 지급하게 되면서 전제가 셋 흔들렸습니다. 전부 변호사 확인이 필요합니다.
① 전자금융거래법 — 남의 돈을 받아 다시 나눠주는 구조가 규제 대상인가.
② 수수료 명목(D8 「소프트웨어 이용료」) — 자금을 경유하면서도 그 명목이 유지되는가.
③ 근로자성(L6) — 우리가 직접 돈을 주면 사용자 판정이 우리 쪽으로 기웁니다. Q7·Q8이 다시 열립니다.
평가자가 본사로 옮겨졌는데, 현장을 직접 본 사람은 팀장입니다. 위치 이력과 방문 실적만으로 성실도를 판정할 수 있는지, 아니면 팀장의 의견을 지도사를 특정하지 않는 형태로 받을 경로가 필요한지 정해야 합니다. 6.2가 여기 걸립니다.
회사가 발급하기로 했으니 발급 기준이 필요합니다. 교육 이수가 요건인지, 급수(1·2·3급)를 무엇으로 가르는지, 1급 경력은 서류 심사로 갈지. 그리고 자격 사업의 수수료를 받을 것인지도 함께 정해야 합니다.
정산(D89) — 근태 → 마감 → 명세 산출 → 확정 → 명세서 → 지급 확인. 마감이 명세보다 먼저라는 순서가 확정됐습니다.
파기(D89) — 대상이 여섯 갈래(회원 식별정보·재가입 차단·세대 PII·현장 확인 정보·문서·1:1 문의)인데 큐가 하나뿐이라 한 갈래만 빠뜨려도 조용히 안 지워졌습니다. 통합 큐를 신설했습니다. 파기 누락은 에러가 아니라 위반입니다.
아래 둘은 9월 5일 백엔드 작업으로 이미 답이 나왔습니다 — 회의에서 다시 여쭐 필요가 없습니다.
둘 다입니다. D86으로 자금이 OS4U를 경유하고 우리가 직접 지급합니다(D25 폐기). 다만 D87로 실제 이체는 시스템 밖이라, 플랫폼은 금액 산출과 명세서까지 하고 담당자가 은행에서 처리합니다. 원천징수 의무자는 OS4U입니다.
아닙니다. 폐지됐습니다(D86). 등급별 지급률(A 95% ~ D 80%)을 없애고, 등급은 평가·선발 판단에만 씁니다. 이 문서의 이전 판에 「등급이 곧 지급률」이라고 적혀 있던 곳을 전부 고쳤습니다.