어바웃피싱 8월 통합 서비스 — 9/9 론칭 전환 준비서

00한눈에 보기

체크 상태·담당자·메모는 입력 즉시 저장되어 다른 사람의 화면에도 반영됩니다.

01핵심 판단

지금 놓치면 되돌릴 수 없는 세 가지

나머지 항목은 순서를 바꿔도 되지만, 이 셋은 특정 날짜를 지나면 선택지가 사라집니다.

8/10은 공지 게시일이 아니라 약관 재공고의 법정 마감일입니다

약관·개인정보 처리방침 11차는 현재 공고 2026-07-19 / 시행 2026-08-19로 3문서가 확정돼 있습니다. 론칭이 9/9로 밀렸는데 시행일을 그대로 두면, 8/19~9/8 3주 동안 신약관은 시행됐지만 그 약관이 전제하는 화면(D-3 취소요청 접수·머니 환불 신청)이 앱에 없는 상태가 됩니다.

시행일을 9/9로 옮기려면 이용자 불리 변경의 30일 사전 고지를 다시 채워야 하고, 9/9에서 30일을 역산하면 정확히 2026-08-10입니다.

2026-08-14 기준 — 이 날짜는 나흘 지났습니다. 따라서 지금 필요한 건 “언제까지 공고할까”가 아니라 8/10까지 재공고가 실제로 나갔는지 확인하고, 그 결과에 따라 시행일을 다시 계산하는 것입니다.

재공고가 나갔다면 — 공고일 + 30일이 시행 가능일입니다. 8/10 공고 기준이면 9/9 시행이 성립합니다(초일 산입 여부는 법무 확인 필수)
재공고가 나가지 않았다면 — “9/9로 이동”은 이미 소멸한 선택지입니다. 오늘 공고해도 시행 가능일은 9/13 이후라 론칭일을 넘깁니다. 남은 길은 ①8/19 시행을 그대로 두고 3주 공백을 운영으로 감당하거나, ②9/9 시점에 약관 변경이 필요한 안건을 12차 개정으로 분리하는 둘뿐입니다
현황판은 이미 “취소·환불 규정 변경 포함, 전부 12차로 넘어간다”고 ②를 기정사실로 적고 있지만, 같은 파일의 작업표는 아직 “3중 택일”로 열려 있습니다. 둘 중 어느 쪽이 결정본인지부터 오늘 문서로 닫아야 합니다 — 12차도 불리 변경이면 다시 30일 사전고지라, 안건 목록을 8월 말까지 닫지 않으면 10월 시행도 놓칩니다 (B-10 · B-13)
CPO 성명 공란은 여전히 “시행 자체가 불가”한 정지조건입니다. 다만 지정 방식은 이미 결정됐고 성명·직책·부서 3필드 회신만 남았습니다 — 판단이 아니라 독촉 항목입니다 (B-03)

딥링크는 “원링크를 고치는 문제”가 아니라 앱 빌드에 물린 문제입니다

고객앱은 전체 웹뷰 + 앱패킹(네이티브 화면 없음) 구조라 웹 URL이 곧 딥링크입니다. 따라서 통합에서 라우트가 바뀌면 기존 원링크가 통째로 무효가 됩니다.

AppsFlyer OneLink는 앱이 이미 아는 키·값이면 대시보드 수정만으로 충분하지만, 새 키를 도입하면 앱 코드 수정 = 재배포가 필요합니다 → 9/9 빌드에 반드시 포함돼야 하고, 그러면 마감이 Feature Freeze 8/19로 당겨집니다
iOS AASA는 이미 설치된 기기가 주 1회만 갱신본을 확인 → 반영에 최대 7일. 9/1까지 올라가 있어야 합니다
Android 14 이하는 App Links 주기 재검증이 없어서, 경로가 바뀌면 앱 업데이트를 받기 전까지 딥링크가 깨진 채로 남습니다
부수 확인 — Firebase Dynamic Links는 2025-08-25 완전 종료되어 남아 있으면 404. 원링크의 pid·c 파라미터 미부착은 7/28부터 사흘 연속 P0로 올라온 미해결 건으로, 이대로면 론칭 유입 전량이 오가닉으로 집계됩니다

SEO는 9/9에 켜면 이미 늦습니다 — 지금 켤 수 있는 것부터 분리하세요

구글 공식 기준으로 중소 규모 사이트도 색인 이전에 수 주가 걸립니다. 9~10월이 피크인데 9/9에 한꺼번에 켜면 피크의 검색 유입을 통째로 포기하는 셈입니다. 지금 URL 구조를 바꾸지 않고도 선반영 가능한 항목이 있습니다.

robots.txt의 Disallow: /_next/static/chunks/ 제거 — 렌더 JS를 스스로 차단 중
sitemap.xml 정상화 — aboutfishing.kr은 404, booking은 파싱 실패 상태
기존 /boats/*에 title·description·JSON-LD 주입 — 현재 head 태그 5개뿐, 전 도메인 JSON-LD 0건(경쟁사 포함 전원 0건 = 선점 여지)
단, 날짜를 고르기 전엔 상품 링크가 0개로 렌더되는 문제는 구조 변경이라 Feature Freeze(8/19) 안에 넣어야 합니다 — 설계서가 지목한 단일 최대 병목

＋

2026-08-07 갱신 — 다른 트랙에서 넘어온 것

같은 날 다른 방에서 나온 결과가 이 문서의 전제를 몇 군데 바꿨습니다. 항목 본문에는 각각 반영해 두었고, 여기서는 판단이 바뀐 지점만 짚습니다.

마감이 8/19가 아니라 8/15·8/13으로 당겨졌습니다 — GA4·GTM 측정 설계서가 확정되면서, 앱 재배포가 필요한 항목(네이티브 브릿지·Consent 신호·딥링크 스킴·ADID 주입)이 Feature Freeze에 물린다는 게 분명해졌습니다. 딥링크 규격·지역 체계 정본은 8/15, user_id 해시·Consent 법무 판정은 8/13이 실질 마감입니다 (C-05 · C-12 · G-12)
머니는 9/9에 돌아오지 않습니다 — 재구축이 15~20주로 잡혀 오픈 예상이 11/20~12/25입니다. 중단일을 언제로 정하든 3~4개월 공백이 생기므로, CS 스크립트에 “머니 재개 시점” 표준답변이 없으면 그 자체가 2차 오고지가 됩니다 (B-06 · H-01)
갭 리포트 v2를 이관 근거로 쓰면 안 됩니다 — v3 재검증에서 P0 4건(딥링크 백지·잘못된 ID 백지·/oauth 백지·배너 결손)이 재현되지 않았습니다. 딥링크 증상도 “백지”가 아니라 쿼리 파라미터 유실 후 상위 폴백으로 정정됐습니다 (F-01 · C-06)
새로 확인된 P0가 5건 들어왔습니다 — 결제 3종(Toss 위젯 중복 마운트·PC 결제창 잘림·유령 예약) / 조과 등록 크래시 / 보안 3종(API 키 하드코딩·토큰 평문·401 인터셉터 부재) / test-platform 크롤링 전면 허용 / 성능(FCP 5,444ms·번들 무압축·캘린더 49개월) (F-11~13 · D-11 · E-17)
론칭 형태는 “조건부 Go + 소프트 런칭”으로 권고됐습니다 — 9/9 오픈은 유지하되 레거시 병행, Exit Criteria 8개 충족 후 단계 종료. 예약 원장이 단일 시퀀스라는 게 실증돼 듀얼런이 성립합니다 (E-12)
약관 쪽에도 두 건이 추가됐습니다 — 처리방침 머니행 이중기재가 실제로 미정정(8/19 전 처리), 머니 차감순서가 §18③2와 §25⑨에서 서로 다름 (B-08)

＋

2026-08-14 전수 검사 — 준비서를 다시 훑어 찾은 것

8개 카테고리를 정본 문서와 한 줄씩 대조했습니다. 항목은 94건 → 126건으로 늘었고, 아래 여섯은 기존 판단이 틀렸거나 전제가 무너진 곳입니다.

쿠폰 실험은 오늘 판정이 끝났고, 결과는 “대조군 대비 유의한 군 없음”(판정 D)입니다 — 보정 전에도 p=0.064, 1차 판정으로 삼으려던 T20 vs C는 p=0.56. 상한을 반영하면 세 군 모두 대조군보다 1인당 거래액이 낮습니다. 8/4의 “T15 ROI 3.6배”는 사라졌고, 이 전제 위에 서 있던 9월 본 캠페인 2,500만과 「고독한 낚시꾼」 프로모션 코드가 동시에 무근거가 됐습니다. 8/18은 “어느 군을 채택할까”가 아니라 집행 여부 자체를 묻는 판정이어야 합니다 (G-06 · G-10 · G-17 · R14)
“빈 캘린더가 최대 매출 리스크”라는 프레임이 틀렸습니다 — 9월 등록 좌석은 이미 128,720석이고 필요량은 6,667석, 19.3배 여유입니다. 병목은 총량이 아니라 소진율(0.65% → 목표 5.2%)과 검색–공급 매칭이고, 콜 대상도 이미 특정돼 있습니다(수요5+ & 판매0 13척, 수요5+ & 9월 미오픈 6척) (G-09)
취소 정책은 “3중 불일치”가 아니었습니다 — 피그마 “출항 3일 전까지 무료취소”와 dev “3일 이내 취소 불가”는 같은 D-4/D-3 규칙의 다른 표현이고 dev 동작이 의도된 사양입니다. 실제 불일치는 환불 소요일 2중(3~5 vs 2~3영업일)뿐입니다. 3중으로 두면 정상 동작을 결함으로 이관하게 됩니다 (F-03)
지역 체계는 새로 만들 게 아니라 이미 있는 안을 승인하는 일입니다 — SEO 설계서가 시도 12(부산·울산 1depth 승격) + 시군구 44 = 색인 URL 56을 확정 결정으로 갖고 있습니다. 8/15에 할 일을 “정본 수립”에서 “채택 승인 + 3계통 동기화 지시”로 줄여야 하루 만에 끝납니다 (C-12)
통합 QA가 스토어 제출보다 뒤에 잡혀 있었습니다 — QA 9/1 vs Play 제출 8/31. 실기기에서 결함이 나와도 바이너리를 못 고칩니다. 8/27~8/30으로 당깁니다. 같은 종류로 롤백 계획(9/2 → 8/26), 미이관 자산 Empty·에러·시스템 메시지 78종(9/2 → 8/19), 강제업데이트 분기(8/26 → 8/19, 코드프리즈일에 신규 기능은 프리즈 규칙 위반), 릴리즈 노트(9/9 → 8/28, 심사 제출 시 입력 항목)가 있었습니다 (E-06 · E-13 · E-15 · E-14 · E-16)
빠져 있던 트랙이 통째로 하나 있었습니다 — 8/13에 확정된 블로거 페이백(회원 쿠폰 20% / 페이백 5% / 즉시 모집)이 한 줄도 없었습니다. 쿠폰 재원을 선주가 부담하려면 선주 약관 명시가 선행돼야 하는데(야놀자 5.4억·여기어때 10억 과징금 선례) 8/10이 지나 11차엔 못 들어갑니다. 부담 주체에 따라 건당 손익이 −44,496원 vs −3,296원, 13배로 갈립니다. 블로그 본문에 박힌 링크는 회수도 안 돼서 9/9 라우트 변경 시 영구 파손됩니다 (B-12 · C-16 · G-16 · D11 · R15)

그 밖에 QA 최종 판정의 P0 5건(쿠폰 발급 무반응·약관 쉐브론 체크 토글·취소규정 미고지·(광고) 표기 누락), GA 서버 측정의 전제인 client_id 예약원장 저장, robots 정본과 ?date= 색인 폭발 차단, 정책카드 86장 재추출, 앱 바이너리 변경 범위 잠금 등 32건을 신규 편입했습니다. 폐기 2건(B-01·B-02)과 사실오인 1건(H-05 슬래시 명령 — 이미 구축 완료)도 표시했습니다.

심사는 8/24에 한 번 넣고 두 번 더 넣을 수 있게 짜야 합니다

반려를 전제로 일찍 넣자는 판단은 맞습니다. 다만 “8/19~8/25 사이에 한 번 넣어본다”가 아니라, 8/24에 넣고 8/28·9/2에 다시 넣을 수 있는 구조를 만드는 것이 핵심입니다. 그러려면 프리즈에서 제출까지가 5일로 압축돼야 하고, 기존 일정(코드프리즈 8/26 → 제출 8/31·9/1)은 통째로 6일 앞당겨집니다.

오늘은 8/18이고 Feature Freeze는 내일입니다. 그래서 이 계획의 성패는 “무엇을 하느냐”가 아니라 “무엇이 내일 안에 들어가야 하고, 무엇은 8/23까지 가도 되는가”에 달려 있습니다. 다행히 전체 웹뷰 구조가 여기서 크게 유리하게 작동합니다 — 심사 요건의 절반 이상이 앱 재배포 없이 웹과 콘솔로 해결됩니다.

내일(8/19)까지 — 바이너리에 갇히는 것

필수: targetSdk 36(I-02) · ATT 프롬프트(I-05) · PrivacyInfo.xcprivacy(I-06) · 오프라인·에러 네이티브 화면(I-08) · Android 권한 선언(I-14) · iOS 용도 문자열(I-15) · 머니 UI 잔재 제거(I-13)
기존: 딥링크 스킴 · 네이티브 브릿지 · Consent 신호 · ADID 주입 · 최소버전 플래그(E-18)
분기점: Sign in with Apple 필요 여부(I-12)는 오늘 안에 판정해야 합니다. “필요”면 네이티브 작업이라 내일 안에 들어가야 하고, 못 들어가면 8/24 제출 자체가 성립하지 않습니다

8/23까지 — 웹·콘솔로 되는 것

웹: 회원탈퇴 화면(I-01) · UGC 신고·차단(I-11) · 취소규정 상시 노출(F-18) · 처리방침 URL(I-03) — 전부 웹뷰 화면이라 프리즈와 무관합니다
콘솔: App Privacy 라벨(I-04) · Play 데이터 보안 양식(I-07) · 심사 노트(I-09) · 데모 계정(I-10) · 스크린샷(I-16) · 연령등급·앱 콘텐츠(I-17) · 릴리즈 노트(E-16)
뜻: 내일 프리즈에 실제로 걸리는 것은 7~8건뿐입니다. 나머지를 프리즈로 끌어오면 오히려 일정이 깨집니다

그리고 이 전략에는 아무도 모르고 있던 마감이 하나 걸려 있습니다 — Google Play는 2026-08-31부터 targetSdk 36(Android 16) 미만의 제출을 받지 않습니다. 8/24 1차 제출은 통과하더라도, 반려되어 9월에 재제출하는 순간 업로드 자체가 막힙니다. “반려를 감안해 일찍 넣는다”는 전략이 정확히 그 지점에서 무력화됩니다. 연장 신청은 정책 경고를 받은 앱만 콘솔에서 할 수 있어 사전 대비책이 못 됩니다.

오늘 첫 작업은 현행 targetSdk 실측입니다 — 이미 36이면 아무 일도 없고, 35 이하인데 내일 안에 못 올리면 8/28이 Play의 마지막 제출 창이 됩니다. 그 경우 “1차 반려 = Play 포기”라는 뜻이므로 일정 자체를 다르게 짜야 합니다 (I-02 · I-20 · R19)
회원탈퇴 미구현은 심사 운의 영역이 아니라 “제출하면 걸리는” 항목입니다 — Apple 5.1.1(v)와 Play 데이터 삭제 요건 양쪽에 걸립니다. 다만 웹으로 만들 수 있으니 8/21까지 가면 되고, 1일 안에 완전 자동 삭제가 어렵다면 접수 → 기간 내 삭제 구조라도 요건은 충족됩니다 (I-01)
ATT(앱 추적 투명성)가 준비서에 한 번도 없었습니다 — 내일 ADID 주입이 들어가는데 ATT 프롬프트가 없으면 5.1.2입니다. 심사자가 네트워크를 보면 바로 잡힙니다 (I-05)
전체 웹뷰 구조는 4.2의 정면 과녁입니다 — 반려 신호 1순위가 “오프라인에서 브라우저 기본 에러”인데, Empty·에러·시스템 메시지 78종이 전부 미이관입니다. 심사자는 비행기모드 한 번으로 확인합니다. 이건 네이티브 레이어라 내일 안입니다 (I-08 · E-15)
1차 제출 빌드는 완성본이 아니라 “심사를 통과할 수 있는 최소 빌드”여야 합니다 — 대신 8/24~9/9의 16일간 바이너리가 얼어붙으므로 “앱 고정 / 웹 가변” 경계표를 8/21까지 공표해야 합니다. 이 표가 없으면 그 16일 내내 “그건 앱이라 안 된다”가 매번 논쟁이 됩니다 (D14 · E-19)
아직도 안 정해진 전제가 하나 있습니다 — 기존 앱 업데이트인지 신규 등록인지(E-01, 13일째 경과). 신규 + 개인 계정이면 클로즈드 테스트 12명 × 14일 + 프로덕션 액세스 심사가 붙어 8/24는 물론 9/9 게시도 불가능합니다. 조직 계정이면 스크린샷 한 장으로 이 리스크가 사라집니다 (E-01 · E-02 · R21)

연기해도 앱은 좋아지지 않습니다 — 그게 9/9 판단의 핵심입니다

“제품이 덜 됐으니 미루자”는 보통 맞는 말인데, 이 프로젝트에서는 절반만 맞습니다. Play가 8/31부터 targetSdk 36 미만의 제출을 받지 않으므로, 그 뒤로는 앱 바이너리를 고칠 수 없습니다. 연기해서 버는 시간으로 고칠 수 있는 것은 웹 화면뿐이고, 앱 결함에 대해서는 연기가 아무것도 사주지 않습니다.

반대로 9/9가 쥐고 있는 것은 셋인데, 셋 다 날짜를 옮기면 사라지는 종류입니다.

앱 재배포 창 — 전체 웹뷰라 FB SDK 브리지·ATT·ADID·딥링크 파라미터는 앱 재배포에만 실립니다. 여기 메타 앱 20백만이 걸려 있어, 포함하면 유효 900건(목표의 75%) · 못 하면 780건(65%) · 게이트까지 놓치면 450건(38%)입니다 (J-01 · E-20)
9/14~18 평일만 비어 있는 재고 — 회의 실측입니다. 9월 1~10일은 자리가 거의 없고, 기획전은 땡처리 성격이라 9/9 이후에만 열 수 있습니다. 1주 연기는 이 창의 절반, 2주 연기는 창 전체를 잃습니다 (G-20)
11/30 손절 게이트까지의 일수 — 9/9면 82일, 9/16이면 75일, 10/1이면 60일. 게이트 5지표 중 「예약자 1인당 커머스 결제액 125,401원」은 9/9 태깅에서만 나오고 지금까지 한 번도 측정된 적이 없습니다. 미룰수록 손절 판단이 데이터에서 추정으로 바뀝니다 (D-17 · F-27)

다만 9/9를 지키는 이유가 “9월 목표를 달성하기 위해서”는 아닙니다. 9월 450백만은 필요 활성 선박이 405척인데 계획은 185척이고 8월 실적이 350척입니다. 10월 427·11월 407도 같아서, 론칭일을 어디로 옮겨도 9·10·11월은 산술적으로 닫히지 않습니다. 모델의 8월 선박당 9.4건이 실적이 아니라 마감 전망이고 원장 실측은 7.9건이라 기준선부터 1.20배 부풀려져 있습니다. 그러니 론칭일은 목표 달성 수단이 아니라 위 세 자산을 지키는 기준으로 정하는 편이 맞습니다 (R25 · D17).

그리고 광고는 이미 늦었습니다. 신규 전환 캠페인은 학습 2주라 9/9 성과를 위한 세팅 마감이 8/26이었습니다. 오늘 세팅해도 안정화는 9/11입니다. 게다가 9/9 자체가 랜딩·딥링크 교체와 리타게팅 모수 재생성으로 재학습을 유발하므로 실제 구조는 D-14 세팅 → D0 재학습 → D+14 재안정의 2단입니다. 9/9는 “광고 성과의 시작일”이 아니라 “측정 기준선의 리셋일”로 잡아야 합니다 (J-04 · R26).

02날짜 의존성

8월 기준으로 박혀 있는 것들

연기하면 자동으로 어긋납니다. “고칠 곳”이 아니라 “안 고치면 사고 나는 곳” 목록으로 읽어주세요.

대상	박혀 있는 날짜	9/9 연기 시 무슨 일이 생기나	연결

0.39/9 최종 점검 — D-2

9/7 저녁 재실측 · 준비서에 없던 항목 13건 · 9/8 00:00 전 확인 순서

론칭 이틀 전에 준비서 전체를 다시 훑었습니다. 결론부터 적으면, 기능보다 「설정값」 쪽에 구멍이 남아 있습니다 — PG 도메인, API 키 허용 도메인, 알림톡 템플릿 링크, 플레어레인 허용 도메인처럼 테스트 도메인에서는 되는데 www에서는 안 되는 것들입니다. 그리고 9/1 실측에서 잡힌 P0 7건이 그 뒤로 닫혔는지 기록이 없습니다.

A. 9/7 저녁 재실측 — 아침과 달라진 것 없음

확인한 것	결과	항목
aboutfishing.kr	여전히 옛 랜딩. canonical·og:url 모두 apex, robots `index, follow`. www로 넘기는 스크립트도 없다. 9/7 회의에서 정한 리다이렉트 index.html은 아직 안 올라갔다	N-04 · N-05
www 사이트맵	`sitemap.xml`이 인덱스 형태로 정상. 하위 12개(static · boat · place · display · catchlog×4 · port · spot · tackle · cctv) 전부 www 기준	D-06 완료 가능
www/map	정상 로드. 제목 「실시간 낚시 지도 \| 어바웃피싱」, robots `index, follow`	P-02 확인 필요
shop.aboutfishing.kr	JS 앱이라 크롤러로는 내용 확인 불가. 9/8 00:00 상품 내림·공지배너는 브라우저로 직접 봐야 한다	N-11
AASA · assetlinks	아침과 동일 — 세 호스트 전부 404	N-07

B. 준비서에 없던 항목 — 13건

248건을 다시 훑어 어디에도 잡히지 않은 것만 뽑았습니다. 카테고리 P로 항목 목록과 실행 순서표에 들어가 있습니다.

구분	항목	왜 지금인가	번호
웹	토스 PG 등록 도메인 · 결제 완료 URL · 웹훅	booking으로 남아 있으면 www에서 결제창이 안 뜨거나 결제 후 구 도메인으로 돌아간다. 9/8 새벽에 발견하면 그 시각에 PG 콘솔을 만져야 한다	P-01
웹	지도·CCTV·정부 API 키의 허용 도메인	키에 booking만 등록돼 있으면 www에서 지도가 빈 화면. 테스트 도메인에서 되던 것이 prod에서 안 되는 전형	P-02
웹	알림톡 템플릿 링크 도메인	카카오 알림톡은 템플릿 변경 시 재검수(1~2영업일). 오늘 등록해야 9/9에 맞는다	P-03
웹	플레어레인 허용 도메인 · 웹푸시	www에 SDK가 안 붙으면 긴급공지 채널 1순위(푸시)가 사라진다	P-04
웹	「서비스 점검 중」 화면 시간 하드코딩	「2025.08.15 02:00~06:00」이 박혀 있다. 9/8 배포 중 점검 화면을 띄우면 1년 전 날짜가 보인다	P-05
웹	9/1 실측 P0 7건 최종 상태	고아 예약 · 결제 약관 빈 화면 · 환불 정보 0 · 쿠폰 개수 불일치 · 개인정보 평문 · 홈 흰 화면 · 야간 차단 기본 OFF — 어느 것이 닫혔는지 기록이 없다	P-06
웹	조황 본문 선장 휴대폰번호 노출	공백 쪼개기로 필터를 우회해 노출. www가 색인 허용이라 검색엔진에도 들어간다	P-07
웹	야간 광고성 푸시 전송 설정	야간 차단 기본 OFF + 알림함 전부 (광고) + 전체회원 on 검토 = 9/9 이후 첫 야간 푸시가 위반	P-08
웹	첫 화면 품질 5건	웰컴 쿠폰팩 문구 3중 불일치 · 테스트 문자열 · 띄어쓰기 · 배너 alt · 부산 탭. 9/8 웹 배포에 같이	P-09
앱	스토어 URL 3종(지원·마케팅·처리방침) www로	콘솔 작업이라 빌드 없이 오늘 가능. Apple은 죽은 지원 URL을 반려 사유로 본다	P-10
운영	롤백 발동 기준·담당	E-13이 기록에 없다. 제안 — 결제·로그인·예약 중 하나라도 30분 이상 다수 불가면 웹을 직전 버전으로	P-11
앱	웹뷰 캐시	구 번들 캐시로 업데이트 뒤에도 옛 화면. 「업데이트했는데 그대로예요」 문의의 원인	P-12
웹	검색결과 keyword 무시 · 카드 button · 캘린더 25개월	9/9 블로커는 아니지만 광고 착지·공유에 직접 닿는다. 9/16 스코프	P-13

C. 9/8 00:00 전에 확인하는 순서

위에서부터 순서대로. 1~4번은 안 되면 9/8 00:00 자체를 미뤄야 하는 것이고, 나머지는 당일 밤 안에 고치면 됩니다.

#	확인	안 되면	항목
1	구버전 앱에 강제 업데이트 로직이 있는가 · 최소버전 값은 어디서 내려오는가	9/9 「강제」를 「권장」으로 바꾸고 공지·CS 문구 수정	N-01
2	심사 통과 빌드의 base URL이 www인가 · targetSdk 값	booking이면 앱 게시 보류, 웹 단독 오픈	M-14
3	www에서 결제창이 뜨고 결제 후 www로 돌아오는가 (PG 도메인·URL·웹훅)	PG 콘솔 수정 후 재확인. 안 되면 00:00 연기	P-01
4	www에서 카카오·애플·휴대폰 로그인이 되는가	IdP 콘솔 리다이렉트 URI 수정	K-10
5	스토어 게시 눌렀는가 · 양 스토어에서 새 버전이 보이는가	전파 대기. 00:00에 안 보이면 「9/8 중」으로 공지 수정	N-02
6	쇼핑 상품 내림 · 공지배너 · 주문내역 · 환불 화면이 같은 시각에 뜨는가	환불 화면이 없으면 상품 내림도 연기	N-11
7	지도·CCTV가 www에서 그려지는가	API 키 허용 도메인 추가	P-02
8	알림톡 템플릿 링크 · 플레어레인 SDK가 www에서 초기화되는가	템플릿 검수 신청 · 허용 도메인 추가	P-03 · P-04
9	점검 화면 문구 · 첫 화면 품질 5건 · 선장 번호 마스킹	9/8 15:00 웹 배포에 포함	P-05 · P-09 · P-07
10	야간 차단 기본값 · 광고성 푸시 시간대 제한	전체회원 on 보류	P-08 · N-10
11	긴급 문구 3종 · 롤백 기준·담당 · 대기조 명단	정해질 때까지 00:00 배포 담당이 직접 판단하지 않는다	N-09 · P-11
12	apex → www 301 (또는 JS 폴백) 올라갔는가 · 광고 파라미터 보존되는가	9/9 오전 컷오버 전까지	N-04 · N-05 · N-06

0.49/7 주간회의 반영

확정된 것 · 바뀐 것 · 회의에서 안 짚인 것

9/7 기획팀 주간회의(서현일·김채린·구범모)에서 9/8 00:00 선택 업데이트, 9/9 강제 업데이트로 배포 순서가 확정됐습니다. 아래 D 블록은 회의에서 나오지 않았지만 이 일정을 성립시키거나 깨뜨리는 항목입니다 — 일부는 오늘 실제로 주소를 열어 확인한 결과입니다.

오늘 안에 확인해야 하는 것 세 가지

1. 강제 업데이트가 되는 상태인가. 강제 업데이트는 지금 스토어에 있는 구버전 앱 안에 최소버전 확인 코드가 이미 들어 있어야 동작합니다. 준비서의 E-14가 8/19 기한이었는데 반영 여부가 기록에 없습니다. 없으면 9/9에 강제할 수단이 없습니다 (N-01).

2. 9/8 00:00에 뜨려면 게시는 오늘입니다. 게시 버튼을 눌러도 양 스토어 모두 사용자에게 보이기까지 시간이 걸립니다 (N-02).

3. 회의에서 정한 변경 중 바이너리가 섞였는지. Firebase 앱 추가는 확실히 새 빌드가 필요합니다. 하나라도 섞이면 이미 통과한 심사가 아니라 새 심사가 되고 9/8~9/9에 끝나지 않습니다 (N-03 · N-16).

A. 회의에서 확정된 것

항목	내용	담당
배포 순서	9/8 00:00 선택 업데이트 → 9/9 강제 업데이트. 쇼핑 상품도 9/8 00:00에 내린다	그룹
대댓글·카운트	대댓글은 노출하지 않고 댓글 중심으로 운영. 카운트 표시 자체를 뺀다. 응원·신고·숨기기와 숫자 반영은 9/9 이후 논의	구범모
리다이렉트	`aboutfishing.kr`·`map.aboutfishing.kr` → `www.aboutfishing.kr`(지도는 `/map`). 루트에서 라우터를 지우고 index.html로 리다이렉트. map은 안내 배너를 거쳐 이동	구범모
GTM·GA	dev/prod 키를 분리. 되는지 여부는 아직 확인 전	구범모
플레어레인	광고 모달은 추가 구현으로 문의해 둔 상태. 푸시 발송 자체는 가능. 타겟 URL 설정 방법 공유 예정	서현일
슬라이더	iOS 메모리 문제로 기획전 슬라이더 최대 10개 (회의록 요약은 10개, 상세는 “10~20개 내외” — 값 확정 필요)	상수
기타	CCTV 화면에 정부 API 콘텐츠 추가 · 토스 최소 결제금액 300원 · 홈페이지 콘텐츠 보완 · 선주 모바일 지정석	서현일·다원

B. 회의에서 안 짚인 것 — 오늘 실측

주소를 직접 열어 확인한 결과입니다. 셋 다 원링크·광고 착지에 바로 영향을 줍니다.

확인한 것	결과	뜻
apex가 옛 랜딩 N-04	`aboutfishing.kr`은 예전 랜딩을 그대로 보여주고 www로 넘어가지 않는다. canonical도 각자 자기를 가리킨다 — apex는 apex, www는 www	원링크 착지가 apex라면 지금도 옛 랜딩으로 떨어지는 중
AASA·assetlinks 없음 N-07	apex · www · booking 세 곳 모두 404. `/.well-known/apple-app-site-association`과 `assetlinks.json`이 아예 없다	우리 도메인 링크는 앱이 아니라 브라우저로 열린다. 원링크 도메인이 어디인지부터 확인
www가 색인 허용 K-05	www가 `index, follow`로 열려 있고 robots.txt도 `Allow: /`에 sitemap까지 걸려 있다. 계획은 “전면 noindex 후 9/9 해제”였다	apex와 www가 같은 내용으로 동시에 색인 가능한 상태

C. 회의 결정에 딸린 함정

회의 결정	같이 봐야 하는 것	항목
JS 리다이렉트	크롤러와 미리보기 봇은 자바스크립트를 실행하지 않는다. 검색 순위가 안 옮겨가고 공유 링크 미리보기가 빈칸으로 뜬다. 정답은 서버 301이고 JS는 차선책이다. 그리고 referrer는 실어 보낼 수 없다 — 리다이렉트를 거치면 referrer는 우리 페이지로 바뀐다. 실제로 넘겨야 하는 건 utm·gclid 같은 광고 파라미터를 원본 그대로 이어붙이는 것이다	N-05 N-06
네이버 URL 정리	네이버 검색광고는 사이트 URL·비즈채널이 검수 대상이라 주소를 바꾸면 재검수가 걸리고 그동안 노출이 멈출 수 있다. 9/9 당일에 바꾸면 그날 네이버 유입이 빈다. prod www가 이미 열려 있으니 지금 등록해 검수를 통과시켜 두는 것이 안전하다	N-08
전체회원 알림 on	서버에서 켜도 OS 알림 권한을 거부한 사용자에게는 안 간다. 그리고 거래·서비스 알림과 광고성 정보는 법적으로 다르다 — 광고성은 별도 수신동의가 필요해서 일괄로 켜면 문제가 된다. 업데이트 안내는 서비스 알림으로 보고, 광고성은 건드리지 않는 쪽이 안전하다	N-10
“긴급공지가 없다”	지금 쓸 수 있는 채널은 셋 — 플레어레인 푸시 · 웹 배포로 올리는 상단 배너 · CS 채널 고정 안내. 문구와 발송 담당을 미리 정해두지 않으면 당일에 못 쓴다	N-09
dev/prod 키 분리	측정 설계서 확정은 「기존 GA4 속성 유지 — 신설 금지」다. 속성을 새로 만들면 앱스크립트 8종·CPO 대시보드·09시 리포트가 같이 끊긴다. GTM 컨테이너를 나누는 것과 GA4 속성을 새로 만드는 것은 다른 얘기다	N-15
쇼핑 00:00 내림	머니 잔액 환불 창구가 같은 시각에 열려야 한다. 약관 부칙이 이미 시행 중이라 “중단기간 전액 환급”이 회사 의무다. 공지배너·주문내역 조회·환불 세 화면이 동시에 떠야 한다	N-11
“광고 언제 끄냐”	기준은 하나 — 301이 서면 끌 필요가 없고, 안 서면 그 구간만 끈다. 껐다 켜는 것 자체가 학습을 흔든다	N-12
PWA 푸시 미지원	웹 랜딩 중심으로 완전히 옮기면 재방문을 부르는 푸시 채널을 잃는다. 앱을 대체하는 문제가 아니라 어디까지 웹으로 받고 어디부터 앱으로 보낼지의 문제가 된다	M-06

D. 9/8~9/9 시간표

시각	할 것	선행 조건
9/7 (오늘)	스토어 게시 · 강제 업데이트 로직 확인 · 바이너리/웹 판정 · 네이버 비즈채널 등록 · 긴급 문구 3종 준비	—
9/7 중	알림 설정 on (서비스 알림만) → 업데이트 안내 푸시 문구 확정	법무 확인
9/8 00:00	선택 업데이트 노출 · 쇼핑 상품 전량 내림 + 공지배너·주문내역·환불 동시 오픈	게시 전파 완료
9/8 새벽	결제·예약 실거래 테스트 (회의 합의)	—
9/8 15:00	웹 배포 (기획 아이디 전달 후)	구범모 전달
9/9 오전	강제 업데이트 적용 · 리다이렉트 전환 · noindex 해제 · 약관 시행 고지	N-01 확인 완료
9/9 이후	차기 앱 릴리즈 (카카오 SDK · Firebase 앱 추가 · 커뮤니티 기능)	M-01 일자 확정

0.59/4 14시 회의 안건

9/9 이후 바로 업데이트할 앱 사항

9/9 앱은 준비가 끝났습니다. AOS·iOS 신규 버전이 심사를 통과했고, 지금은 수동 배포 상태라 스토어에 노출되지 않습니다. 9/9에 게시 버튼만 누르면 됩니다. 그래서 오늘 회의는 론칭 회의가 아니라 다음 앱 업데이트에 무엇을 넣을지 정하는 자리입니다. A~C는 구글챗 채널에서 나온 안건이고, D는 준비서 223건을 다시 훑어 뽑은 앱 관련 미결입니다.

이 페이지의 선택과 메모는 링크를 연 모든 사람에게 실시간으로 공유됩니다. 누가 정했는지 남기려면 이름을 적어 주세요 —

먼저 정할 것 — 다음 업데이트 배포일 (M-01)

iOS 카카오 SDK 수정본이 이미 별도 브랜치에 있고, “9/9 이후 앱 업데이트 버전으로 배포 예정”으로 기록돼 있습니다. 다음 업데이트를 할지 말지는 이미 정해져 있고, 배포일만 비어 있습니다.

날짜부터 정하면 아래 안건들이 “이번에 넣는다 / 다음으로 미룬다”로 바로 갈립니다. 지금 미결 4건은 모두 “오픈 후 개발”이라고만 적혀 있어서, 언제 하는 일인지 알 수 없는 상태입니다.

후보 — ① 9/16 2차 오픈과 함께 · ② 9/23 · ③ 카카오 SDK 수정만 먼저 배포

A. 앱 빌드가 필요한 안건 — 5건

전체 웹뷰라 화면·문구·플로우는 대부분 웹 배포로 나갑니다. 앱을 새로 빌드해야만 되는 건 아래 5건뿐이고, 이것만 배포일에 묶입니다.

#	안건	지금 상태	오늘 정할 것
1	공지·광고 모달 M-02	공지모달은 레거시 연동을 하지 않았다. 플레어레인 인앱 메시지로 가능하지만 아직 한 번도 써본 적이 없다. CMS에서 모달을 만들 필요는 없고, 플레어레인에서 설정한 내용이 서비스에 뜨도록 앱에서 연결해 줘야 한다	① 플레어레인 방식으로 갈지 ② 검토 담당과 기한 ③ 이번 업데이트에 넣을지 검토부터 시작이라 일정 산정이 안 돼 있다
2	푸시 중복 발송 M-03	플레어레인 발송 내역을 웹 알림 내역과 API로 연동할 수 있는지 확인되지 않았다. 연동이 안 되면 같은 알림이 두 번 나가는 것을 막기 위해 앱 푸시를 직접 개발해야 하고, 그러면 작업 규모가 달라진다	결론이 아니라 분기 규칙 — 플레어레인 문의 기한, 그리고 회신이 없으면 어느 쪽으로 갈지
3	iOS 카카오 SDK M-12	AppDelegate의 콜백 누락으로 로딩이 지연되고 로그인 취소 시 오래 로딩되던 문제. 수정 완료, 브랜치 대기 상태다	따로 정할 것 없음 — 다음 업데이트에 자동 포함. 임시 안내 문구(사파리·크롬으로 가입 후 앱 재실행)가 CS 스크립트에 들어갔는지만 확인
4	네이버 쇼핑 외부 도메인 M-08	앱 빌드 없이 연결할 수 있는지 개발이 확인해 보겠다고 한 건. 빌드가 필요하면 아래 B-1 배너도 배포일에 묶인다	확인 기한과 담당
5	공유 링크 미리보기(OG) M-18 · K-07	카카오톡 등에 링크를 붙였을 때 뜨는 이미지·제목. 웹과 앱 두 겹이라 한쪽만 고치면 안 나온다. ① 웹 — OG 태그가 초기 HTML에 있어야 하는데 예약 화면이 CSR이라 비어 있다(지역 검색 노출 0건과 같은 원인). 미리보기 봇은 JS를 실행하지 않는다 ② 앱 — 공유 버튼이 넘기는 URL이 www 정본 주소여야 한다. 이 부분이 바이너리 ③ 도메인이 바뀌니 카카오 캐시를 따로 지워야 한다	공유 URL 규격(앱) · OG 태그 서버 렌더 범위(웹) · 어느 화면까지 개별 이미지를 줄지 화면별로 가면 디자인 작업이 따라온다

B. 앱 빌드 없이 나가는 안건 — 4건

웹·CMS 작업이라 배포일을 기다릴 필요가 없습니다. 오늘 담당과 착수일만 정하면 바로 진행할 수 있습니다.

#	안건	지금 상태	오늘 정할 것
1	외부 링크 배너 모듈 M-04	CPO 최우선 개선건(출조 홈·새소식). 논의는 이미 정리됐다 — 자유 배치는 화면 크기에 따라 이미지가 잘려서 “좌/우 텍스트 또는 이미지 + 버튼” 최소 규칙으로 고정하자는 안. 개발도 “오래 걸리지 않으니 전달만 달라”고 답했다. 남은 건 규격서다	규격서 한 장을 이 자리에서 확정. 이미지 사이즈 · 텍스트/버튼 배치 규칙 · 출조 홈 CMS 작업 범위 새소식은 바로 되지만 출조 홈은 배치 위치에 따라 작업이 늘어난다
2	PWA 설치 유도 M-06 · 오늘 09:10 제기	마케팅 방향을 앱 설치 유도에서 웹 랜딩 중심으로 바꾸자는 안건이다. 앱 업데이트의 우선순위가 달라지는 내용인데 아직 문서에 없다. 요구는 구체적이다 — 설치 강요나 상시 배너 없이, 회원가입 직후 · 쿠폰 다운로드 · 선박 상세 조회 후 · 예약 완료 직후 네 시점에 상황에 맞는 문구로	네 시점의 문구와 노출 규칙 · 재노출 억제 정책 · 착수일 방향이 바뀌는 안건이라 배포일보다 먼저 다루는 편이 낫다
3	낚시대회 기획전 이미지 M-07	display=42로 구현돼 있으나 출조 홈에는 나오지 않는다. 상단 이미지는 출시 직전에 한 번 바꾸고, 문구 겹침은 출시 이후 CMS에서 다시 바꿔야 해결된다 — 9/9에 손이 두 번 필요하다	교체 2회의 담당과 시각 · 출조 홈 노출 여부 놓치면 첫 화면에 문구 겹친 배너가 그대로 나간다
4	회원조과 대댓글·좋아요 M-05	기획과 개발 범위가 “오픈 이후”로만 적혀 있고 기한이 없다	기능 결정이 아니라 기획 착수일과 목표 배포 시점

C. 담당·시각만 정하면 되는 것 — 3건

항목	내용	언제
스토어 게시 해제 M-11	심사는 통과했고 수동 배포 상태라 노출되지 않고 있다. 9/9에 버튼을 누를 담당과 시각만 정하면 된다 — D-Day 절차서 1단계와 같은 항목	9/9
디자인 QA 반영 M-09	오늘 09:00에 우선 처리 요청이 들어왔다. QA 시트와 다른 경로로 온 요청이라 상태 추적에서 빠질 수 있다 — 시트에 넣고 우선순위를 매길 것	즉시
9/9 이후 접수 창구 M-10	접수완료/채택 → 작업중 → 반영완료 → QA 확인 완료 4단계는 자리를 잡았다. 문제는 시트가 “9/9 론칭의 건” 전용이라는 점이다. 9/9 이후 건을 같은 시트에 쌓을지 따로 뺄지 정하지 않으면 “오픈 후” 항목이 어디에도 기록되지 않는다	오늘

D. 구글챗 밖에서 올라온 앱 관련 미결 — 카테고리별

아래는 채널 대화가 아니라 준비서 223건을 다시 훑어 뽑은 것입니다. 이번 심사는 통과했지만 다음 제출에서 다시 걸리거나, 다음 빌드에 반드시 들어가야 하는 것들입니다. 항목 번호는 준비서의 기존 항목이고, 새로 만든 건 M-13~M-17입니다.

먼저 짚을 것 세 가지

1. 같은 결정이 두 군데에 있습니다. 준비서에 E-22 「9/9 이후 앱 릴리즈 1회의 일자·스코프 확정」이 이미 있습니다. M-01과 같은 내용이라, 오늘 날짜를 정하면 E-22는 닫습니다 (M-13).

2. 9/9 이전에 확인해야 하는 게 하나 섞여 있습니다. 앱이 전체 웹뷰라 주소가 바이너리에 구워집니다. 심사를 통과한 그 빌드가 www를 보는지 booking을 보는지 기록이 없습니다. booking이면 9/9에 게시해도 앱만 구 도메인에 남습니다. 이건 다음 업데이트로 미룰 수 없습니다 (M-14 · K-02).

3. 미결 4건만 보면 한 번 뺀 것들이 또 빠집니다. 9/9 스코프에서 탈락한 항목(E-20)이 곧 다음 릴리즈의 출발점인데 목록이 문서로 없습니다 (M-15).

D-1. 다음 제출에서 반려될 수 있는 것

항목	내용	빌드 필요
회원탈퇴 인앱 삭제 경로 I-01 · M-16 · F-24	양 스토어의 확정 반려 사유(Apple 5.1.1(v) · Play 데이터 삭제). 준비서에는 “미구현 — 반려 1순위”로, 검수에는 “탈퇴 버튼 무반응”으로 따로 잡혀 있다. 약관 11차 제17조① 접수형 수정(F-24)과 같은 화면이다	필요
웹뷰 4.2 방어 I-08 · I-09 · I-10	전체 웹뷰 앱의 최대 반려 사유. 네이티브 기능 증빙 세트 · 심사 노트 · 데모 계정이 한 묶음이다. 심사 노트에 허위 경로(새소식 탭→퀵메뉴→쇼핑)가 남아 있는 건 별건으로 삭제해야 한다(I-28)	증빙만
ATT · 개인정보 매니페스트 I-05 · I-06 · I-14	광고 SDK를 넣는 순간 따라오는 항목들이다. iOS는 ATT 프롬프트와 PrivacyInfo.xcprivacy, Android는 AD_ID 선언. 아래 D-3의 SDK 결정에 딸려 온다	필요
머니 잔재 I-13	선불 머니 흔적이 바이너리·화면에 남아 있으면 금융 관련 심사 리스크가 된다. 9/9에 shop 상품을 전량 내리므로 앱 화면에도 잔재가 없는지 확인해야 한다	확인
Sign in with Apple I-12	소셜 로그인을 제공하면 Apple 로그인도 함께 제공해야 한다. 카카오 SDK 수정과 같은 로그인 영역이라 함께 본다	필요
targetSdk 실측 I-25 · I-02	8/31부터 Play는 targetSdk 36이 아니면 받지 않는다. 9/2 제출이 통과했으니 충족한 것으로 보이지만 값이 기록돼 있지 않다. 오늘 개발에게 한 줄로 받아 둘 것	확인
스토어 등록정보 I-26 · I-27 · I-28	앱 이름의 「쇼핑/쇼핑몰」, Play 간단한 설명의 「물반고기반」(상표권), 심사 노트 허위 경로. 전부 콘솔 작업이라 빌드 없이 오늘도 고칠 수 있다	불필요

D-2. 도메인 통합 때문에 앱에 묶인 것

항목	내용	언제
앱 웹뷰 base URL K-02 · M-14	심사를 통과한 빌드가 www를 보는지 booking을 보는지 기록이 없다. booking이면 9/9에 게시해도 앱만 구 도메인에 남고, 앱 안에서 301로 넘겨야 하는데 이건 아래 딥링크 문제와 겹친다	9/9 이전
AASA · assetlinks K-03 · C-08 · C-09	www 기준으로 재발행. 기존 기기는 주 1회만 갱신을 확인하므로 늦게 올리면 딥링크가 최대 7일 깨진다	9/1 경과
딥링크 파라미터 유실 C-06 · C-04 · K-04	라우트별 복원이 아직 미해결이다. 도메인이 바뀌면 스킴도 다시 정의해야 한다(K-04). 광고 링크의 착지 정확도에 직접 영향	차기 릴리즈
최소버전 플래그 강제 업데이트 E-14	구버전 앱이 구 도메인을 계속 보게 두지 않으려면 필요하다. 강제 업데이트 분기가 없으면 다음 업데이트를 내도 구버전 사용자가 남는다	차기 릴리즈

D-3. 측정·광고 SDK — 마케팅 요구인데 빌드가 필요한 것

항목	내용	상태
탑재 SDK 확정 M-17 · J-01 · J-02 · J-03	어떤 SDK를 넣을지가 안 정해져 있다. 대행사는 “앱스플라이어 사용 중”이라 하고 우리 기록은 “MMP 미사용”이라 서로 다르다(J-03). 태그·이벤트 요구목록도 아직 못 받았다(J-02). SDK를 넣기로 하면 D-1의 ATT·매니페스트·AD_ID 3건이 같이 따라온다	미결
FB SDK 브리지 개발 이관 목록	메타 앱 캠페인을 돌리려면 필요하다. 마케터는 앱에 접근할 수 없어 개발 트랙으로만 처리된다. 게이트3(9/10) 이후 메타 앱 20백만 개방과 연결된다(J-11)	미착수
user_id · Consent G-12 · C-15	user_id 해시 전송과 Consent Mode는 법무 판정이 선행이다. af_deeplink_open 이벤트도 미구현	판정 대기

D-4. 앱에서 실제로 터지는 결함

항목	내용	성격
조과 등록 크래시 F-12	제출 시 앱이 죽고 에러 스택이 화면에 노출된다. 회원조과는 D-4 대댓글·좋아요를 얹으려는 바로 그 화면이다 — 기능을 얹기 전에 이것부터다	P0
결제 3종 F-11	Toss 위젯 중복 마운트 · PC 결제창 잘림 · 유령 예약. 매출에 직접 닿는다	P0
보안 4종 개발 이관 목록	API 키 하드코딩 · 토큰 평문 저장 · 401 인터셉터 부재 · booking-api 무인증. 예약상세에 개인정보가 평문으로 실린다는 건도 함께 있다	P0
성능 E-17 · 검수 기록	번들 무압축(gzip·brotli 미적용) · 캘린더 49개월 전량 렌더 · 선박 상세 13,341ms 백지 · /map/ 크래시	P0
하나손보 배지 F-22	보험 게이트가 9/30이라 앱 화면의 보험 배지·문구를 먼저 내려야 한다	P0

D-5. 릴리즈 운영 규칙 — 한 번 정하면 다음부터 안 물어봐도 되는 것

항목	내용	오늘
E-22 중복 정리 M-13	「9/9 이후 앱 릴리즈 1회의 일자·스코프」가 이미 항목으로 있다. M-01과 같은 결정이라 따로 두면 한쪽만 채워진다	M-01로 통합
E-20 탈락분 승계 M-15	9/9 스코프에서 뺀 항목이 다음 릴리즈의 출발점인데 목록이 문서로 없다	목록 받기
핫픽스 창 · 롤백 E-19 · E-13	제출 이후 바꿀 수 있는 것과 없는 것의 경계, 그리고 롤백 트리거. 9/9에 문제가 나면 이 문서를 보고 판단한다	담당 지정
단계적 출시 I-22	Play staged rollout을 쓸지. 쓰면 문제 발생 시 확산을 줄일 수 있지만 지표가 늦게 찬다	결정
인앱 리뷰 요청 I-29	스토어 노출을 올리는 다음 수단은 키워드가 아니라 리뷰 수다. 스펙만 정하면 차기 릴리즈에 넣을 수 있다	스펙 확정

✦

회의 전에 참고할 것

PWA는 나머지와 성격이 다릅니다. 다른 안건이 “기능을 언제 넣을까”라면, 이건 “앱 설치를 미는 방식을 그만둔다”는 방향 이야기입니다. 이게 정해지면 다음 업데이트의 우선순위도 달라지니, 배포일보다 먼저 다루는 편이 낫습니다.
B-1 배너 모듈은 사실상 결론이 나 있습니다. 개발이 오래 걸리지 않는다고 했고 규격안도 나왔습니다. 이 자리에서 규격서를 확정하고 끝내면 됩니다. 다시 검토로 돌리면 최우선 건이 또 한 주 밀립니다.
D는 전부 “다음 업데이트에 넣을지”를 묻는 항목이 아닙니다. D-1의 회원탈퇴와 D-3의 SDK는 넣고 말고가 아니라 넣어야 하는 것이고, D-2의 base URL은 9/9 이전에 확인해야 하는 것입니다. 나머지만 배포일에 배정하면 됩니다.
“오픈 후 개발”이라는 표현 대신 날짜나 릴리즈 번호를 붙이면 좋겠습니다. 지금 미결 4건이 모두 이 표현으로 남아 있어서, 언제 하는 일인지 아무도 모릅니다. 이것만 바꿔도 M-10(접수 창구)이 같이 정리됩니다.

◇

같이 확인하면 좋을 것

준비서에 아직 기록이 없는 항목입니다 — 8/24 1차 제출 결과 · 9/2 밤 심사 제출 결과 · Play 개발자 계정 유형 · 8/19 Feature Freeze 반영 내역 · 9/2 전사 QA 결과 분류. 심사 통과가 확인됐으니 제출 결과 두 건은 사실상 정리된 셈입니다. QA 결과 분류는 아직 비어 있는데, 여기서 나온 건 중 앱 관련은 그대로 다음 업데이트 스코프가 됩니다.

3.0실행 순서

파트별 · 날짜순으로, 할 것만

체크박스를 누르면 미착수 → 진행중 → 완료로 바뀌고 즉시 저장됩니다. 아래 칩으로 파트를 좁혀 담당자별 목록으로 쓰세요. 총 –건.

03준비 필요 항목

사유를 포함한 실행 목록

항목을 누르면 왜 필요한지와 산출물이 펼쳐집니다. 상태·담당자·메모는 자동 저장됩니다.

www 통합의 진짜 마감은 9/9가 아니라 오늘과 내일입니다

도메인을 www.aboutfishing.kr 하나로 모으고, 앱 웹뷰도 www를 가리키게 빌드해 심사에 올린다 — 여기서 기한이 실제로 걸려 있는 항목은 딱 둘이고, 둘 다 론칭일보다 8~9일 앞에 있습니다.

오늘(8/31) — Play targetSdk 36 시행일. 앱이 전체 웹뷰라 base URL이 바이너리에 구워집니다. 오늘 www 빌드를 못 올리면 Play에는 영영 못 올라가고, Android 앱(매출의 60.7%)은 구 도메인을 계속 가리킵니다 — 그러면 통합을 앱 안에서 301로 처리해야 하는데, 이미 미해결인 딥링크 쿼리 파라미터 유실과 겹칩니다. 다행히 Apple은 targetSdk 제약이 없어 오늘·내일 움직일 수 있습니다 (K-01 · K-02 · E-08 · R30)
내일(9/1) — AASA·assetlinks를 www로 게시하는 마감. 기존 설치 기기는 주 1회만 갱신을 확인하므로 9/9에 올리면 딥링크가 9/16까지 깨진 채로 갑니다. 역방향도 같아서, www로 올리는 순간 구 도메인 링크가 최대 7일 깨집니다 (K-03)
그런데 대행사 미팅은 9/2입니다. 도메인 안건을 다루는 자리가 두 마감보다 뒤에 있습니다. 도메인 결정은 미팅을 기다릴 수 없고, 9/2는 “도메인을 정하는 자리”가 아니라 이미 정해진 도메인을 통보하고 광고 자산 영향을 받아 오는 자리로 규정해야 합니다 (K-20 · R29)

미루는 것으로는 이 둘이 해결되지 않습니다. 9/9를 9/16으로 옮겨도 targetSdk 마감과 AASA 전파 시계는 그대로 흐릅니다 — 오히려 “AASA는 www인데 웹은 아직 booking”인 어정쩡한 1주가 생깁니다. 그래서 v3.0의 결론(9/9 유지)은 도메인 통합이 들어와도 바뀌지 않습니다. 대신 조건이 하나 늘었습니다 — URL 체계 동결이 앱 제출보다 앞서야 합니다. 빌드 뒤에 URL을 바꾸면 앱 재배포가 필요한데 그 창이 오늘 닫힙니다.

그리고 “전부 새로 심는다”에서 하나는 빼야 합니다. 측정 설계서의 확정 결정이 「GA4 속성은 기존 295704822 유지 — 신설 금지」입니다. 속성을 새로 파면 앱스크립트 8종 · CPO 대시보드 · 09시 자동 리포트가 동시에 끊기고, 전환 이력 0·잠재고객 모수 0이라 학습이 통상 2주보다 오래 걸립니다. 문서와 정합적인 해석은 “도메인·GTM 컨테이너·태그는 새로, GA4 속성은 유지”입니다 (K-19 · D21).

prod를 미리 띄우면 미완성 화면이 색인됩니다. robots.txt Disallow로는 못 막습니다 — 설계서가 이미 같은 판단을 내려 뒀습니다(“차단하면 noindex를 못 읽는다”). www 전체를 meta noindex로 올리고 9/9에 해제하고, 진입점은 별도 플래그로 막습니다. 해제 후 색인에도 시간이 걸리므로 9/9 당일 검색 유입은 0을 전제로 잡아야 합니다 (K-05 · K-14 · D22).

shop은 9/9에 상품을 전부 내리고 공지배너·주문내역 조회·환불만 남깁니다. 환급률은 이미 정해져 있습니다 — 11차 부칙 §2③ “중단기간엔 60·80% 요건 없이 전액 환급”. 표준약관(90/95%)보다 회사에 불리한 쪽으로 확정된 것이라 낮추면 자기 약관 위반입니다. 환불 자체는 머니 발행인 특정(M-01)이 미결이어도 진행해야 합니다 — 부칙이 이미 시행 중이라 미루는 게 곧 위반이고, 등록면제 기준이 발행잔액 30억 미만이라 환불은 오히려 리스크를 줄입니다. 다만 안내문에 “발행인·수탁사”를 특정하는 문구는 쓰지 않습니다 — 처리방침 위탁표의 이중 기재가 아직 정정되지 않았습니다 (K-15~K-18 · R34).

3.5앱 심사 역산

8/24 1차 제출 · 반려 2회를 흡수하는 구조

2026-08-28 — 8/24 1차 제출 결과가 어디에도 기록되지 않았습니다(4일 경과). 같이 미기록인 것이 더 문제입니다 — 8/15 4대 게이트(13일), 8/18 분기 판정 4건, 8/19 Feature Freeze에 무엇이 들어갔는지, RC #1이 빌드됐는지. 즉 지금 스토어에 무엇이 올라가 있는 상태인지를 아무도 모릅니다. 아래 표는 원래 계획이고, 실제로는 오늘 30분 안에 세 가지 사실부터 확인해야 합니다 — ①8/24 제출 여부·결과 ②현행 targetSdk ③Play 계정 유형 (I-24 · I-25 · E-02 · R24).

날짜	할 일	내용	여유
8/18(화) 오늘	분기 판정 4건	① 릴리즈 형태 — 기존 앱 업데이트인가 신규 등록인가(E-01) ② Play 개발자 계정 유형(E-02) ③ 현행 targetSdk 실측(I-02) ④ Sign in with Apple 필요 여부(I-12). 넷 중 하나라도 “안 된다”가 나오면 아래 일정이 성립하지 않습니다	D-1
8/19(수)	Feature Freeze 바이너리만	targetSdk 36 · ATT 프롬프트 · PrivacyInfo.xcprivacy · 오프라인·에러 네이티브 화면 · Android 권한 선언 · iOS 용도 문자열 · 머니 UI 잔재 · (필요 시) Sign in with Apple + 기존 항목(딥링크 스킴 · 브릿지 · Consent · ADID · 최소버전 플래그). 웹으로 되는 것은 여기 넣지 않습니다	—
8/20(목)	RC 빌드 #1 · 내부 배포	“심사 통과 최소 빌드”로 확정. 버전·빌드 번호 고정. 롤백 계획도 이 날 확정	기존 8/26에서 6일 당김
8/21(금) ~8/23(일)	실기기 QA + 웹·콘솔 작업	회원탈퇴 화면 · UGC 신고/차단 · 처리방침 URL · App Privacy 라벨 · 데이터 보안 양식 · 심사 노트 · 데모 계정 · 스크린샷 · 연령등급을 이 창에서 병렬로 끝냅니다. QA는 Tier1 8대 + 320px 재현 1대. 금요일에 크리티컬 패스를 몰고 주말은 예비. 바이너리 결함만 제출 보류 사유, 웹으로 고칠 수 있는 것은 제출을 막지 않음	3일
8/24(월)	★ 1차 제출	App Store + Play 동시. App Store는 “no earlier than 2026-09-09” 예약, Play는 관리형 게시 ON. 심사 노트·데모 계정·예약 완주 경로 첨부	론칭까지 16일
8/26(수)	1차 결과 확인	Apple은 24~48시간이라 이때면 나와 있어야 함. 반려면 메타데이터 / 바이너리로 즉시 분류 — 메타데이터는 필드만 고쳐 반나절 재제출, 바이너리는 새 빌드 + QA 재실행	—
8/28(금)	2차 제출 마지노선	8/31부터 targetSdk 36 미만은 Play 업로드 불가. I-02를 8/19에 처리했다면 이 제약은 없고, 못 했다면 여기가 Play의 마지막 창	2차
8/31(월)	⚠️ Play API 36 시행	이후 신규·업데이트 제출은 API 36 필수. App Store는 이 제약 없음	—
9/1(화)	AASA · assetlinks 마감	iOS는 기존 설치 기기가 주 1회만 갱신 확인 → 9/9까지 최대 7일 필요. 심사와 별개 트랙	—
9/2(수)	3차 제출 창 (최후)	+ “앱 없이 웹만 여는” 전환 기준 확정. 권고 — 9/5 12시까지 양 스토어 중 하나도 승인되지 않으면 웹 단독 오픈으로 전환하고 앱은 승인 즉시 게시	3차
9/3(목)	게시 리허설	관리형 게시 · 단계적 출시 설정 · 스크린샷/출시 노트를 9/9 문안으로 교체하는 시점 확정	—
9/8(화)	최종 점검	승인 상태 · App Store 릴리즈 예약이 9/9로 살아 있는지(빌드 교체 시 풀릴 수 있음) · Play 관리형 게시 ON · 우회 항목(출시 노트·가격·기기 제외)	D-1
9/9(수)	🚀 게시	웹 배포 → 앱 게시 순서. 롤백 1순위는 웹	—

✦

제출 전 반드시 닫아야 하는 것 — 반려 확정급 6가지

아래는 “운이 나쁘면 걸리는” 항목이 아니라 제출하면 걸리는 항목입니다. 하나라도 열려 있으면 8/24 제출은 반려를 사는 것과 같습니다.

회원탈퇴 — 인앱 삭제 경로 + 웹 삭제 URL + 백엔드 실삭제. Play는 데이터 보안 양식의 삭제 질문 미응답만으로도 업데이트를 거부합니다. 웹으로 만들 수 있어 프리즈와 무관 (I-01, 8/21)
targetSdk 36 — 8/31 이후 재제출을 살려두려면 지금 넣어야 합니다 (I-02, 8/19)
ATT 프롬프트 — ADID를 쓰는데 프롬프트가 없으면 5.1.2 (I-05, 8/19)
개인정보 라벨 ↔ 실제 SDK 일치 — AppsFlyer·GA4·Firebase가 수집하는 값과 라벨이 다르면 5.1.1. 8/19에 ADID가 들어가므로 기존 라벨은 확실히 낡았습니다 (I-04, 8/20)
데모 계정 + 예약 완주 경로 — 로그인 게이트가 있는데 계정이 없으면 2.1. 이 앱은 심사자가 결제까지 완주해봐야 핵심 기능을 보므로, 100% 할인 쿠폰이든 테스트 결제든 경로를 정하고 절차서를 붙여야 합니다 (I-10, 8/22)
조과 등록 UGC 요건 — 신고·차단·24시간 조치·연락처. 신고·차단 UI는 웹으로 붙일 수 있지만, 지금 조과 등록은 제출 시 크래시 상태라 심사자가 시도하면 2.1로도 같이 걸립니다 (I-11 · F-12, 8/21)

3.6론칭일 판단

9/9를 지킬 것인가, 미룰 것인가

결론부터 — 숫자만 놓고 보면 9/9 유지가 우세합니다. 다만 “9월 목표를 지키려고”가 아니라 날짜를 옮기면 사라지는 자산 세 개를 지키려고 입니다. 미룬다면 상한은 9/16입니다.

시나리오	얻는 것	잃는 것	11/30까지
9/9 유지 권고	앱 재배포 창 확보 → 메타 앱 20백만 시나리오 C(유효 900건, 목표 75%) / 기획전 9/14~18 창(유일하게 비어 있는 재고) / 일정변경 기능 착수 / 「고독한 낚시꾼」 10/23 프리즈까지 44일	8/24 제출 결과·프리즈 반영이 미기록이라 바이너리 리스크를 모른 채로 간다 / 실효 P0 24건 + QA P0 5건 + 미이관 자산 78종을 안고 성수기 트래픽을 받는다	82일
9/16 1주	웹 화면 수리 7일 / 회사 홈페이지 전면 교체와 정렬(CPO 판정이 이미 9/16 이후) / 메타 웹 30백만은 9/1 착수라 광고 손실 없음	기획전이 9/14~18 창의 절반만 잡는다 / 메타 앱이 B안으로 이동(780건, 65%) / 앱 바이너리는 8/31 이후 못 고치므로 지연으로 얻는 품질 개선은 웹 한정 — 연기 논거의 가장 큰 구멍	75일
9/23 2주	웹 수리 14일 / 구글 30백만 전환 정의를 여유 있게 확정	기획전이 9/14~18 창을 통째로 놓친다 / 9월 잔여 영업일 8일 / AEO·GEO 효과 측정 개시가 11/18로 밀려 게이트 판정에 12일치만 남는다 / 시나리오 D(450건, 38%) 리스크	68일
10월 초	제품 리스크 최소화 — 단 웹 한정	AEO·GEO 측정 개시가 11/26 = 게이트 4일 전 / 10/23 「고독한 낚시꾼」 예약 퍼널 프리즈까지 3주 미만(통화모달 제거·딥링크 정상화·프로모션 코드 랜딩·P0 13건이 전부 이 창에 있고, 이 넷이 예약 24 → 91건의 3.8배를 만든다) / 10/14 대회 4차와 겹침 / 피크의 3분의 1을 통과한 뒤 여는 셈	60일

✦

미루기 전에 알아야 할 것 — 9월 목표는 어느 날짜에도 닫히지 않습니다

9월 450백만 = 예약 유효 1,877건 = 하루 106건. 현재는 하루 16~21건입니다. 필요 활성 선박이 405척인데 계획은 185척, 8월 실적이 350척입니다 — 등록된 배가 전부 결제를 내도 도달하지 못합니다. 10월 427·11월 407도 같고, 닫히는 달은 12월뿐입니다
기준선부터 부풀려져 있습니다 — 모델의 8월 선박당 9.4건은 실적이 아니라 마감 전망이고 원장 실측은 7.9건(1.20배). 먼저 이 값을 실측으로 바꿔 9~12월을 재역산해야 어떤 날짜 논의든 의미가 생깁니다
광고 CPA가 5.2배 벌어져 있습니다 — 대행사 제시 40,000원 vs 우리 실측 206,195원. 그런데 그 분자인 8월 실제 집행비가 46.6백만인지 1억 2,500만인지도 아직 확정되지 않았습니다(2.7배). 이게 안 닫히면 예산도 목표도 판정 불가입니다 (J-06 · J-07)
못 미루게 만드는 법정 마감은 없습니다. 다만 8/31 targetSdk 36이 연기의 이득을 앱 영역에서 소멸시키고, 10/23 「고독한 낚시꾼」 퍼널 프리즈가 연기 폭의 실질 상한을 만듭니다

3.7prod 컷오버

언제 · 무엇을 · 어떤 순서로 띄우나

9/9는 “서비스 완성 오픈”이 아니라 「웹 전환 + 앱 게시 + 측정 개시」로 스코프를 줄여야 성립합니다. 홈페이지 전면 교체·커머스 딜 오픈·낚시대회는 9/16 2차 오픈으로 보냅니다.

9/9 — 1차 컷오버에 들어가는 것

앱: 스토어 게시(예약 해제 / 관리형 게시 OFF). 바이너리 스코프는 E-20 확정서가 정한다
웹: URL 라우트 교체 · 회원탈퇴 화면 · UGC 신고/차단 · 취소규정 상시 노출 · 처리방침 URL · 결제약관 4기능 · FAQ 시행 전 세트
측정: GA↔예약원장 일일 대사 개시 · 예약→커머스 전환 태깅(11/30 게이트 5지표 중 하나의 유일한 측정 경로) · 리타게팅 모수 재생성
운영: 주간 기획전 오픈(9/14~18 소진 목표) · 쇼핑·머니 중단 발효

9/16 — 2차 오픈으로 보내는 것

홈페이지: 전면 교체. CPO 판정 = 9/9 전 반대 — 9/9 전에는 P0 3장만 선패치. booking·shop이 CSR이라 홈페이지가 유일한 색인 자산이고, 리다이렉트 맵 없이 교체하면 색인 손실이 확정된다
커머스: 딜 오픈. 주문 테이블이 0건이고 홈 모듈 등록처가 미정이며 앱이 완전 종료 후에만 갱신된다. 배송비 불일치는 법정 금지 유형이라 열면 곧 제재 사유
낚시대회: GNB 승격·앱 화면. 정산 산식 오류 수정 전까지 금지가 이미 판정. 유효 티켓 0에 건당 3,639원이 유출되는 상태라 노출을 늘리면 유출도 는다
앱 2차: E-20에서 탈락한 항목 + 낚시대회 웹뷰 권한 + 인앱 리뷰를 합본으로. 이 창을 못 잡으면 10월까지 앱 전환 불가

D-Day 실행 순서 — 어기면 되돌릴 수 없는 것들

#	단계	왜 이 순서인가 · 중단 조건
1	앱 게시 해제	App Store 예약 해제 / Play 관리형 게시 OFF. 웹을 먼저 바꾸면 구버전 앱이 새 URL을 받는다. 스토어 반영에 시차가 있어 이게 먼저다
2	웹 URL 교체	랜딩·딥링크 2단 교체 + 결제약관 4기능 배포. AASA는 9/1에 이미 올라가 있어야 한다 — 기존 기기가 주 1회만 갱신을 확인하므로 9/9에 올리면 딥링크가 9/16까지 깨진다
3	약관 시행 고지	웹 배포 확인 후에만. 부칙 제1조가 4기능 배포 전 시행을 금지한다. 시행은 불소급·비가역이라 4기능이 안 올라갔으면 여기서 중단하고 시행일을 미룬다
4	40% 요율 2요건 확인	결제화면 §3.1 확인란 + §3.2 확정 알림톡. 둘 다여야 성립하고, 하나라도 빠지면 그 기간 예약분은 영구히 상한 20%
5	FAQ 세트 교체	게이트 51문항은 결제약관 시행 후에만 유효
6	기획전 오픈 병렬	대상 업체 선별은 9/8까지 완료. 9/14~18 평일 소진이 목표
7	리타게팅 모수 재생성 병렬	회원 DB 매체 전달의 개인정보 처리 근거 대조가 선행. 재생성하면 학습 2주가 다시 걸린다
8	쇼핑·머니 중단 발효 병렬	공지 `common-164`는 8/10에 이미 게시됨
9	GA↔예약원장 대사 개시	대사 키 = `transaction_id`(예약 원장 ID, 단일 시퀀스). 주기·허용 오차·에스컬레이션은 9/5까지 정의
10	게이트 3 판정	릴리즈 빌드에 측정 항목이 실제로 들어갔는지 실물 확인 → 메타 앱 20백만 개방. 안 들어갔으면 웹·검색으로 재배분. 8/19 프리즈가 미기록으로 지나간 전례가 있어 실물 검증을 따로 세운다

✦

롤백 트리거 — 그리고 되돌릴 수 없는 것들

트리거 — ①앱 게시가 9/5 12시까지 확정 안 되면 「웹 단독 오픈」으로 전환하고 앱은 승인 즉시 게시 ②4기능 중 하나라도 배포 확인 실패 시 약관 시행 보류 ③심사 4.2 반려가 실제로 나면 심사용 플래그로 통합 화면 노출 ④게이트 3 실패 시 메타 앱 예산 재배분 ⑤구좌 알림 이상 시 aaaStop().

되돌릴 수 없는 것 — 스토어 게시 · 앱 이름 변경(구 제목이 인덱스에 수 주 남는다) · 약관 시행(예약 성립 시점 약관으로 고정 + 전문 스냅샷 저장) · 40% 요율 성립 실패 · 공지 발송 · 색인 변경(리다이렉트 맵 없이 교체하면 손실 확정) · 이미 배포된 블로거 링크 · 대회 순위 확정과 정산 지급 · 광고 캠페인 학습 자산(끄면 2주 소실) · 9/9 이전 성과 데이터(이어붙일 수 없음) · 매체에 전달된 회원 DB.

되돌릴 수 있는 것은 웹 배포 · 앱 단계적 출시 비율 · 홈 모듈 노출(단 앱 완전 종료 후에만 갱신) · 광고 캠페인 일시중지(학습은 회복 안 됨) · 구좌 연동 aaaStop() · 홈페이지 P0 3장(정적이라 파일 교체로 원복) · 쿠폰 정책값(발급분은 회수 불가)입니다.

04역산 일정

언제 빌드하고 언제 심사에 올리나

전제 — 기존 앱의 업데이트(신규 앱 등록이 아님). 이 전제가 깨지면 일정표 전체를 다시 짜야 합니다. E-01은 9일, E-02는 8일째 미확정입니다 — 오늘 닫으세요.

App Store · iOS

제출: 8/24(월) 1차 — 심사 제출 + “Automatically release after App Review, no earlier than 2026-09-09” 설정. 반려 시 8/28 2차 · 9/2 3차
근거: 대부분 24~48시간 내 심사 → 8/26이면 결과가 나온다. 9월은 iOS 신버전 시즌 적체가 반복 보고되므로 9월 제출을 피하는 것 자체가 이득. 메타데이터 반려는 빌드 재업로드 없이 콘솔 필드만 고쳐 재제출 가능
주의: 릴리즈 예약은 플랫폼별 적용. 웹뷰 앱은 심사지침 4.2 Minimum Functionality 리스크가 있어 앱다운 기능을 심사 노트에 명시

Google Play · Android

제출: 8/24(월) 1차 — 프로덕션 심사 제출 + 관리형 게시(Managed Publishing) ON → 9/9 수동 “Publish changes”. 2차 마지노선은 8/28
근거: 통상 수일, 성수기·복잡한 앱은 7일 이상. 구글이 제출~게시 사이 최소 1주 버퍼를 권고. ⚠️ 8/31부터 targetSdk 36 미만은 업로드 불가 — 재제출 창이 여기서 닫힌다
주의: 가격·출시 노트·기기 제외 규칙·인앱 상품은 관리형 게시를 우회해 즉시 반영. 단계적 출시는 업데이트에만 가능하고 비율이 자동 증가하지 않음

✦

일정상 안전판 — 웹뷰 구조가 유리하게 작동합니다

실질 릴리즈는 웹 배포이고 앱 바이너리는 최소버전 플래그·딥링크 핸들러·권한·브릿지 정도만 담습니다. 따라서 D-1에 한쪽 스토어가 미승인이어도 웹만 먼저 열고 앱은 승인 즉시 게시하는 컨틴전시가 가능합니다. 같은 이유로 롤백도 웹 롤백이 1순위여야 합니다 — 단계적 출시는 중단해도 이미 설치한 사용자는 그 버전에 남기 때문입니다.

05미결 의사결정

누가, 언제까지

아래가 정해지지 않으면 그 아래 실무가 전부 멈춥니다.

ID	결정 사항	선택지	정하지 않으면	기한 / 주체

06리스크

연기가 만든 것과, 연기로 커진 것

07근거 자료

이 문서가 인용한 것

모든 수치·인용은 아래 자료에서 실제로 확인된 것만 사용했습니다. 추정한 부분은 본문에 그렇게 표기했습니다.

자료	이 문서에서 인용한 내용