프리[경력] 고객사 프로젝트 매니저 (FDE PM)
3.3 (6)프리그로우
경력근거: 고객 요구를 현장에서 직접 파악하고, 그 현장에 맞는 솔루션을 설계합니다.
52일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
프리그로우의 이 자리는 물류창고와 제철소와 전시장 같은 고객 현장에서 UWB 실내측위 솔루션 구축이 일정·범위·품질에 맞게 굴러가게 하고, 요구가 계속 바뀌어도 우선순위를 다시 세우는 PM 입니다. 현장 실사에서 앵커 설치와 배선과 캘리브레이션과 연동을 거쳐 인수 시험으로 가는 의존 사슬은 UWB 구축 현장이 있어야 성립하는 모양이라, 변경 한 건이 오픈일을 며칠 미는지를 계산하는 이 각도가 프리그로우에서 특히 맞습니다. 기술을 직접 만드는 자리가 아닌 PM 이 변경 요청 앞에서 감으로 답하면 회의마다 결정이 밀리고, 숫자로 답하면 협상이 그 자리에서 끝납니다. 이 포트폴리오가 보여주는 것은 의존관계 날짜 계산과 전후 대조 판정과 원문 실재 대조 가드라는 구현 기술이며 현장 구축 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
요구사항을 정의하고 범위를 설정하며 일정·리스크·품질을 관리하는 자리인데, 구축 중 고객 변경 요청 앞에서 오픈일이 지켜지는지를 감으로 답하면 회의마다 결정이 밀립니다. 이 도구는 요청을 확정된 계획에 얹어 오픈일 지연 일수를 계산해, 변경 협상이 그 자리에서 숫자로 끝나게 합니다.
고객의 말을 개발이 쓸 요구로 옮기는 통역이 이 자리의 핵심 역량이라서, 변경 요청 메일 속 문장을 대상 작업과 변경 종류와 기간이 박힌 변경 스펙 구조로 바꾸는 변환을 3주차에 붙입니다. 작업 이름과 숫자가 원문에 없는 변환은 등록하지 않고 확인 필요로 분리해, 모호한 요청이 수치 계산으로 둔갑하지 않게 막습니다.
현장을 직접 방문해 진행을 점검하는 성향을 공고가 자격요건으로 못박았습니다. 실사에서 앵커 설치와 배선과 캘리브레이션을 거쳐 인수 시험으로 가는 의존 사슬이 이 계산의 뼈대라서, 점검에서 확인한 진행 상태를 계획 파일에 반영하면 오픈일 전망이 바로 다시 계산됩니다.
UWB 실내측위 구축 프로젝트에서 킥오프 때 고객·개발팀과 확정한 작업 계획 파일과 고객 변경 요청 목록을 받아, 의존관계를 따라 작업 시작일과 종료일을 평일 기준으로 전개하고, 요청을 계획에 얹어 다시 계산한 전후를 대조해 요청마다 오픈일 지연 일수와 새 오픈일과 영향이 지나간 작업 사슬을 터미널에 내는 CLI입니다. 여러 요청의 조합마다 오픈일을 비교해 어떤 조합이 오픈일을 지키는지도 수치로 답합니다. 날짜 전개와 지연 계산은 전부 규칙 계산이라 정답이 하나로 정해지고, Claude 는 3주차에 고객 문장을 변경 스펙 구조로 옮기는 변환 보조만 맡으며, 변환 결과의 작업 이름과 숫자가 원문에 실재해야 등록됩니다. 작업 계획은 이미 합의가 끝난 것을 입력으로 받을 뿐이며 이 도구가 계획이나 기준을 새로 정하지 않습니다.
물류창고 UWB 구축을 맡은 PM 입니다. 구축 중에 고객이 앵커 증설이나 연동 범위 확대 같은 변경을 계속 요청하는데, 그때마다 오픈일이 지켜지는지를 엔지니어에게 물어 감으로 답하다가, 회의 자리에서 확답을 못 해 결정이 다음 주로 밀린 기억이 있습니다. 요청을 계획에 얹어 며칠 밀리는지 바로 계산해 그 자리에서 숫자로 답하고 싶은 사람입니다.
확정된 작업 계획과 변경 요청이 있으면 오픈일이 며칠 밀리는지는 감이 아니라 의존관계 날짜 계산으로 정해지고, PM 은 계산이 가리키는 병목 작업의 조율과 고객 협상에만 시간을 쓰면 된다는 가정입니다.
확정된 작업 계획 파일과 구조화된 변경 스펙 파일을 넣고 명령 한 번을 돌리면, 의존관계를 따라 작업 일정이 평일 기준으로 전개되고 요청마다 오픈일 지연 일수와 새 오픈일과 영향 작업 사슬이 나오는 완결품입니다. 만드는 덩어리는 의존관계 날짜 계산 엔진과 변경 적용 전후 대조 판정 둘뿐이고 화면·서버·배포·외부 연동·LLM 호출이 없어 평일 5일에 혼자 끝나는 범위입니다. 변경은 1주차에는 구조화된 스펙 파일로 직접 쓰고 문장 변환은 3주차로 미룹니다.
1주차 엔진을 입력으로, 여러 변경 요청을 받아들이는 조합마다 오픈일을 같은 규칙으로 계산해 어떤 조합이 오픈일을 지키는지와 어느 요청이 지연을 만드는지 수치로 대조합니다. 작업마다 며칠까지 늦어도 오픈일이 안 밀리는지 여유 폭과 여유가 0 인 병목 사슬도 계산해, 고객 회의 전에 어떤 요청을 받아들이고 어떤 요청을 미룰지가 숫자로 정해집니다.
고객 변경 요청 메일 속 문장을 Claude 가 대상 작업과 변경 종류와 기간이 박힌 변경 스펙 구조로 바꾸고, 작업 이름과 숫자가 원문에 실재하는 문자열인지 대조한 뒤 사람 확인을 거쳐 등록합니다. 세 주치 계산을 손계산 정답 회귀 테스트로 묶고 하드 케이스 30종이 판정 불가·확인 필요로 분리되는지 자동으로 확인합니다. 기간계 연동이나 클라우드 구축은 하지 않습니다.
구축 작업 계획 40건과 변경 요청 12건을 넣고 명령 한 번으로, 요청마다 오픈일 지연 일수와 새 오픈일과 영향이 지나간 작업 사슬이 나오는 흐름을 시연합니다.
작업별 시작일·종료일과 요청별 지연 일수와 여유 폭이 손으로 계산한 정답과 100% 일치합니다. 평일 달력 전개와 의존관계 계산은 규칙 계산이라 정답이 하나로 정해지므로 자가채점이어도 정답 자체는 객관적입니다.
일부러 만든 하드 케이스 30종(없는 작업을 가리키는 의존과 요청, 서로를 기다리는 순환 의존, 기간이 정해지지 않은 작업과 요청, 이미 끝난 작업을 바꾸는 요청, 같은 작업에 어긋나는 두 요청, 철회된 요청, 별칭으로 적힌 작업 참조)을 넣어도 계산이 멈추지 않고, 판정할 수 없는 것은 추측 없이 판정 불가·확인 필요로 분리해 결과 끝에 따로 보여줍니다.
위 수치는 작성자가 만든 합성 계획·요청 자가채점이라, 실제 UWB 구축 프로젝트의 작업 기간 분포나 변경 요청 빈도와는 다릅니다. 그 값은 프리그로우의 실제 구축 프로젝트 기록이 있어야 잡히며, 이 도구는 계획·요청 파일만 실제 프로젝트 것으로 바꾸면 그 계산을 바로 돌릴 수 있는 상태로 만듭니다.
이건 고객사와 실제 구축 프로젝트 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 계획과 요청의 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증 준비 상태로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 없는 작업을 가리키는 의존과 순환 의존과 기간 미정과 이미 끝난 작업을 바꾸는 요청과 같은 작업에 어긋나는 두 요청을 더미에 일부러 섞어 두었습니다.
실제 구축 일정에는 자재 입고나 고객 승인 대기처럼 달력 계산 밖의 지연이 많아, 평일 기준 전개는 출발점일 뿐입니다. 작업 기간 기본값과 병행 가능 여부는 도입 단계에서 엔지니어와 함께 실제 프로젝트 기록으로 다시 정해야 합니다.
이 포트폴리오가 보여주는 것은 의존관계 날짜 계산과 전후 대조 판정과 원문 실재 대조 가드라는 구현 기술이고, UWB 앵커 설계나 측위 기술, 물류·제조 현장 운영의 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
계산 결과를 들고 어떤 변경을 받아들일지 고객과 협상하고 확정하는 일은 사람 몫입니다. 도구는 지연 일수와 근거 사슬만 만들고 최종 판단의 책임은 PM 이 집니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
킥오프 때 고객·개발팀과 확정한 UWB 구축 작업 계획입니다. 의존관계와 기간을 따라 일정을 전개하는 계산의 뼈대이고, 이 도구는 이 계획을 입력으로 받을 뿐 새로 정하지 않습니다. 현장 현실대로 기간이 정해지지 않은 작업, 존재하지 않는 작업을 가리키는 의존, 서로를 기다리는 순환 의존 쌍, 이미 끝난 작업, 고객·외주가 맡아 우리가 기간을 통제하지 못하는 작업을 일부러 섞어 쉬운 데이터만 푸는 게 아님을 보입니다. duration_days 는 평일 기준 일수이고 depends_on 은 선행 작업의 task_id 목록입니다.
| task_id | project | site_id | phase | task_name | duration_days | depends_on | owner_side | status | done_at | note |
|---|---|---|---|---|---|---|---|---|---|---|
| T-01 | 부산 물류창고 UWB 구축 | s_wh_busan | survey | 현장 실사와 도면 실측 | 3 | [] | freegrow | done | 2026-07-24 | — |
| T-02 | 부산 물류창고 UWB 구축 | s_wh_busan | survey | 앵커 배치 설계 확정 | 2 | ["T-01"] | freegrow | done | 2026-07-28 | — |
| T-03 | 부산 물류창고 UWB 구축 | s_wh_busan | anchor_install | 앵커 브래킷 설치 | 4 | ["T-02"] | vendor | in_progress | — | 고소 작업대 임차 포함 |
| T-04 | 부산 물류창고 UWB 구축 | s_wh_busan | anchor_install | 앵커 전원 배선 | 3 | ["T-03"] | customer | todo | — | 고객 전기팀 담당 |
| T-05 | 부산 물류창고 UWB 구축 | s_wh_busan | gateway_setup | 게이트웨이 설치 | 2 | ["T-03"] | freegrow | todo | — | — |
아래 JSON Schema 에 맞는 UWB 구축 작업 계획 행을 부산 물류창고와 서울 전시장 두 프로젝트 합쳐 40건 만들어 주세요. phase 는 실사(survey)부터 인수(acceptance)까지의 공정 순서를 따르고, depends_on 은 실제 공정 순서(실사 후 설치, 설치 후 캘리브레이션, 캘리브레이션 후 연동·교육·인수)에 맞게 잇습니다. duration_days 는 평일 기준 1~5일이 대부분이 되게 합니다.
{"type":"object","properties":{"task_id":{"type":"string"},"project":{"type":"string"},"site_id":{"type":"string"},"phase":{"type":"string","enum":["survey","anchor_install","gateway_setup","calibration","integration","training","acceptance"]},"task_name":{"type":"string"},"duration_days":{"type":["integer","null"]},"depends_on":{"type":"array","items":{"type":"string"}},"owner_side":{"type":"string","enum":["freegrow","customer","vendor"]},"status":{"type":"string","enum":["todo","in_progress","done"]},"done_at":{"type":["string","null"]},"note":{"type":["string","null"]}},"required":["task_id","project","site_id","phase","task_name","depends_on","owner_side","status"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 duration_days 가 null 이라 기간이 정해지지 않은 행 3건, 둘째 depends_on 이 존재하지 않는 task_id 를 가리키는 행 2건, 셋째 두 작업이 서로를 의존해 순환이 생기는 쌍 1개, 넷째 status 가 done 인데 done_at 이 null 인 행 1건, 다섯째 의존이 4개 이상 몰리는 병목 작업 1건, 여섯째 duration_days 가 0 인 즉시 완료 작업 1건과 15 처럼 극단으로 긴 작업 1건, 일곱째 owner_side 가 customer 나 vendor 라 우리가 기간을 통제하지 못하는 행을 전체의 3분의 1 정도로 두기. 형식을 깨뜨리는 시도는 3건까지 별도로 만들어 주세요. JSON 배열만 출력합니다.{"type":"object","properties":{"task_id":{"type":"string"},"project":{"type":"string"},"site_id":{"type":"string"},"phase":{"type":"string","enum":["survey","anchor_install","gateway_setup","calibration","integration","training","acceptance"]},"task_name":{"type":"string"},"duration_days":{"type":["integer","null"]},"depends_on":{"type":"array","items":{"type":"string"}},"owner_side":{"type":"string","enum":["freegrow","customer","vendor"]},"status":{"type":"string","enum":["todo","in_progress","done"]},"done_at":{"type":["string","null"]},"note":{"type":["string","null"]}},"required":["task_id","project","site_id","phase","task_name","depends_on","owner_side","status"]}구축 중에 고객이 메일과 회의와 전화로 낸 변경 요청 목록입니다. 계획에 얹어 오픈일 영향을 계산하는 입력으로, 1주차에는 change_kind 와 대상·기간이 채워진 구조화 스펙으로 직접 쓰고 3주차에 request_text 문장 변환을 붙입니다. 현장 현실대로 별칭으로 적혀 대상 작업이 매핑되지 않은 요청, 늘어날 기간이 정해지지 않은 요청, 이미 끝난 작업을 바꾸는 요청, 같은 작업에 어긋나는 두 요청, 철회된 요청, 무엇을 가리키는지 특정되지 않는 모호한 문장을 일부러 섞어, 애매한 요청을 만나면 판정하지 않고 확인 필요로 분리하는지 보입니다.
| cr_id | project | requested_at | channel | request_text | status | change_kind | target_task_raw | target_task_id | extra_days | new_task_name | new_task_duration_days | new_task_depends_on | hold_until |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CR-01 | 부산 물류창고 UWB 구축 | 2026-08-04T10:20:00+09:00 | 출고 검수 항목까지 연동 범위에 넣어 주시면 좋겠습니다. WMS 입출… | approved | extend_task | WMS 입출고 연동 개발 | T-09 | 3 | — | — | [] | — | |
| CR-02 | 부산 물류창고 UWB 구축 | 2026-08-05T14:00:00+09:00 | meeting | 2층 랙 구역에 앵커 4대를 증설해 주세요. 브래킷 설치가 끝난 뒤에… | approved | add_task | — | — | — | 랙 구역 앵커 4대 증설 | 2 | ["T-03"] | — |
| CR-03 | 부산 물류창고 UWB 구축 | 2026-08-05T16:40:00+09:00 | call | 저번에 말씀드린 배선 쪽 작업이 이틀쯤 늦어질 것 같습니다. | proposed | extend_task | 배선 쪽 작업 | — | 2 | — | — | [] | — |
| CR-04 | 부산 물류창고 UWB 구축 | 2026-08-06T09:10:00+09:00 | 앵커 전원 배선은 전기팀 증설 공사와 같이 하기로 해서 일정이 더 필… | proposed | extend_task | 앵커 전원 배선 | T-04 | — | — | — | [] | — | |
| CR-05 | 부산 물류창고 UWB 구축 | 2026-08-06T15:00:00+09:00 | meeting | 현장 관리자 교육은 오픈 뒤에 따로 진행해도 됩니다. 이번 구축 범위… | proposed | remove_task | 현장 관리자 교육 | T-10 | — | — | — | [] | — |
아래 JSON Schema 에 맞는 UWB 구축 변경 요청 행을 25건 더 만들어 주세요. request_text 는 고객 담당자가 메일·회의·전화에서 쓸 법한 한국어 문장으로 쓰되, extend_task 와 add_task 는 기간 숫자가 문장 안에 실재하게 합니다.
{"type":"object","properties":{"cr_id":{"type":"string"},"project":{"type":"string"},"requested_at":{"type":"string"},"channel":{"type":"string","enum":["email","meeting","call"]},"request_text":{"type":"string"},"status":{"type":"string","enum":["proposed","approved","withdrawn"]},"change_kind":{"type":"string","enum":["add_task","extend_task","remove_task","hold_task"]},"target_task_raw":{"type":["string","null"]},"target_task_id":{"type":["string","null"]},"extra_days":{"type":["integer","null"]},"new_task_name":{"type":["string","null"]},"new_task_duration_days":{"type":["integer","null"]},"new_task_depends_on":{"type":"array","items":{"type":"string"}},"hold_until":{"type":["string","null"]}},"required":["cr_id","project","requested_at","channel","request_text","status","change_kind","new_task_depends_on"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 extra_days 나 new_task_duration_days 가 null 이라 늘어날 기간이 정해지지 않은 행 3건(판정하지 않고 확인 필요로 분리돼야 함), 둘째 target_task_raw 가 별칭이나 사내 용어로 적혀 target_task_id 가 null 인 행 2건, 셋째 이미 status 가 done 인 작업을 대상으로 하는 요청 1건, 넷째 같은 작업에 기간 연장과 삭제처럼 어긋나는 두 요청 1쌍, 다섯째 status 가 withdrawn 이라 계산에서 제외돼야 하는 행 1건, 여섯째 new_task_depends_on 이 존재하지 않는 task_id 를 가리키는 행 1건, 일곱째 target 과 기간이 모두 null 이고 request_text 도 무엇을 가리키는지 특정되지 않는 모호한 행 1건, 여덟째 extra_days 0 인 경계 행 1건. 형식을 깨뜨리는 시도는 3건까지 별도로 만들어 주세요. JSON 배열만 출력합니다.{"type":"object","properties":{"cr_id":{"type":"string"},"project":{"type":"string"},"requested_at":{"type":"string"},"channel":{"type":"string","enum":["email","meeting","call"]},"request_text":{"type":"string"},"status":{"type":"string","enum":["proposed","approved","withdrawn"]},"change_kind":{"type":"string","enum":["add_task","extend_task","remove_task","hold_task"]},"target_task_raw":{"type":["string","null"]},"target_task_id":{"type":["string","null"]},"extra_days":{"type":["integer","null"]},"new_task_name":{"type":["string","null"]},"new_task_duration_days":{"type":["integer","null"]},"new_task_depends_on":{"type":"array","items":{"type":"string"}},"hold_until":{"type":["string","null"]}},"required":["cr_id","project","requested_at","channel","request_text","status","change_kind","new_task_depends_on"]}| Python | 의존관계 날짜 계산 엔진과 조합 비교와 손계산 정답 대조 테스트를 구현하는 대표 언어입니다. |
| pytest | 날짜 전개·지연 일수·여유 폭·판정을 손으로 계산한 정답과 대조하는 결정론 회귀 테스트를 돌립니다. |
| JSON Schema 검증 | 작업 계획과 변경 요청 파일이 정한 모양을 지키는지 실행 전에 확인하고, 어긋난 행은 계산에서 빼서 따로 보여줍니다. |
| Claude (LLM) | 3주차에 고객 변경 요청 문장을 변경 스펙 구조로 옮기는 변환 보조입니다. 작업 이름과 숫자가 원문에 실재하는지 대조를 통과하고 사람이 확인해야 등록됩니다. |
| RTLS·UWB 구축 어휘 | 실사·앵커 설치·게이트웨이·캘리브레이션·연동·교육·인수라는 공정 어휘가 작업 계획의 분류 축이자 의존 사슬의 뼈대입니다. |
| ERP·MES·WMS 연동 관리 | 연동은 계획 속 작업 항목으로만 다루고 어댑터를 만들지 않습니다. 연동 작업의 기간 변경이 오픈일에 주는 영향만 계산합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 요청 조합 비교와 여유 폭 계산을 붙입니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 3주차에서 고객 문장 변환과 회귀 테스트 묶음을 붙입니다.
변경 요청 한 건마다 계산 엔진이 내린 오픈일 영향 판정입니다. 기준 오픈일과 새 오픈일과 영향이 지나간 작업 사슬을 숫자로 담아, 지연 판정은 손계산으로 재검산되고 판정할 수 없는 요청은 사람 확인으로 넘어가게 합니다.
{"type":"object","properties":{"cr_id":{"type":"string"},"project":{"type":"string"},"verdict":{"type":"string","enum":["no_delay","open_delayed","cannot_assess","already_done","conflict","unmapped"]},"delay_days":{"type":["integer","null"]},"baseline_open_date":{"type":["string","null"]},"new_open_date":{"type":["string","null"]},"critical_path":{"type":"array","items":{"type":"string"}},"affected_task_ids":{"type":"array","items":{"type":"string"}},"needs_human":{"type":"boolean"},"hedge":{"type":["string","null"]}},"required":["cr_id","project","verdict","needs_human"]}[
{
"cr_id": "CR-01",
"project": "부산 물류창고 UWB 구축",
"verdict": "open_delayed",
"delay_days": 3,
"baseline_open_date": "2026-09-11",
"new_open_date": "2026-09-16",
"critical_path": [
"T-09",
"T-11",
"T-12"
],
"affected_task_ids": [
"T-09",
"T-11",
"T-12"
],
"needs_human": false,
"hedge": "합성 계획 기준의 계산이라 실제 프로젝트 수치가 아닙니다."
},
{
"cr_id": "CR-02",
"project": "부산 물류창고 UWB 구축",
"verdict": "no_delay",
"delay_days": 0,
"baseline_open_date": "2026-09-11",
"new_open_date": "2026-09-11",
"critical_path": [],
"affected_task_ids": [
"T-03"
],
"needs_human": false,
"hedge": "브래킷 설치 뒤 병행 가능한 가지라 여유 폭 안에서 흡수됩니다."
},
{
"cr_id": "CR-04",
"project": "부산 물류창고 UWB 구축",
"verdict": "cannot_assess",
"delay_days": null,
"baseline_open_date": "2026-09-11",
"new_open_date": null,
"critical_path": [],
"affected_task_ids": [
"T-04"
],
"needs_human": true,
"hedge": "늘어날 기간이 정해지지 않아 판정하지 않고 확인 필요로 분리합니다."
},
{
"cr_id": "CR-08",
"project": "부산 물류창고 UWB 구축",
"verdict": "conflict",
"delay_days": null,
"baseline_open_date": "2026-09-11",
"new_open_date": null,
"critical_path": [],
"affected_task_ids": [
"T-09"
],
"needs_human": true,
"hedge": "같은 작업에 기간 연장과 삭제 요청이 함께 있어 어느 쪽이 유효한지 사람이 확정해야 합니다."
}
][자동 검증] 1. 판정 JSON 이 위 스키마를 통과하는지 확인합니다. verdict 가 정해진 여섯 값 밖이면 그 건을 버립니다. 2. verdict 가 open_delayed 나 no_delay 인 건은 baseline_open_date 와 new_open_date 가 모두 있고, delay_days 가 두 날짜 사이의 평일 수와 일치하는지 재계산으로 대조합니다. 지연이 정확히 0 일인 경계는 no_delay 로 처리되는지 봅니다. 3. verdict 가 cannot_assess·already_done·conflict·unmapped 인 건은 needs_human 이 true 인지 확인합니다. 4. critical_path 와 affected_task_ids 의 task_id 가 project_tasks 에 실재하는지 확인합니다. 없는 작업을 근거로 들면 그 건을 버립니다. 5. status 가 withdrawn 인 요청이 판정 목록에 나타나지 않는지 확인합니다. 6. 3주차 문장 변환 결과는 작업 이름과 기간 숫자가 request_text 에 실재하는 문자열인지 대조하고, 어긋나면 등록하지 않습니다. [수동 검증] 1. 판정 5건을 뽑아 의존관계를 따라 손으로 날짜를 전개해 delay_days 와 새 오픈일이 맞는지 확인합니다. 2. 판정 결과로 어떤 변경을 받아들일지 고객과 협상하고 확정하는 일은 항상 사람이 합니다.