docs: add project docs and test updates

docs/결정_필요한_사항들/01-DB_및_도메인_구조.md

@@ -0,0 +1,69 @@
+# 결정 필요: DB 및 도메인 구조
+
+> 자료에 **테이블·스키마 정의가 없어** 설계 결정이 필요한 항목.
+
+---
+
+## 1. 지자체 저장 방식
+
+**상황**: 기능목록에는 "지자체별 단가", "지자체별 담당자", "소속 지자체 설정" 등 **지자체 단위** 관리가 나오나, **지자체를 저장하는 테이블/키**에 대한 기술이 없음.
+
+**결정 필요**:
+- [ ] **지자체**를 별도 테이블(`local_government` 또는 `organization` 등)로 두고 PK(예: `lg_idx`)로 관리할지, 아니면 **코드(구/군 코드)만** 쓰고 테이블은 두지 않을지.
+- [ ] 지자체 테이블을 둔다면 **컬럼**: 지자체명, 시/도, 구/군, 사용 여부 등 어떤 항목을 넣을지.
+- [ ] **다중 지자체**를 한 시스템에서 관리하는지(멀티테넌트), 아니면 **1개 지자체 1 인스턴스**로 배포할지.
+
+**참고**: 발주·단가·지정판매소 조회 등에서 "구/군 코드", "동 코드"가 등장. 지자체 = 시/도·구/군 레벨로 해석 가능.
+
+---
+
+## 2. 지정판매소 테이블 및 지자체 연결
+
+**상황**: 웹 기능목록에 지정판매소 **등록 항목**(상호명, 사업자번호, 주소, 구코드, 가상계좌 등)은 나오나 **테이블명·전체 컬럼·DDL**은 없음.
+
+**결정 필요**:
+- [ ] **테이블명**: 예) `designated_shop`, `shop` 등. PK 컬럼명(예: `ds_idx`, `shop_idx`).
+- [ ] **지자체(또는 구/군)와의 연결**: 지정판매소가 **어느 지자체(구/군) 소속인지** 저장할 컬럼 — 지자체 PK FK, 또는 구코드/동코드만 저장할지.
+- [ ] **판매소번호** 규칙: "기본코드 B, C, D + 판매소 일련번호" — 기본코드 B/C/D는 어디서 오는지(기본코드 테이블? 지자체별?).  
+  - **결정됨**: **일련번호는 지자체별**로 부여. → [22-판매소번호_일련번호_결정.md](../기본%20개발계획/22-판매소번호_일련번호_결정.md)
+- [ ] **구코드**: "판매소 주소를 바탕으로 기본코드 C 할당" — 기본코드 테이블이 있는지, 코드 체계(시/도/구/군/동)를 어떻게 저장할지.
+
+---
+
+## 3. 사용자(member)와 지자체·지정판매소 연결
+
+**상황**: 지자체관리자는 "각 지자체에서" 접속, 지정판매소는 "지자체에 주문" — **member가 어느 지자체/지정판매소에 소속되는지** 자료에 명시 없음.
+
+**결정 필요**:
+- [ ] **지자체관리자(mb_level=3)**: 담당 **지자체**를 어떻게 저장할지.  
+  - 예: `member`에 `mb_lg_idx`(지자체 FK) 추가, 또는 `member.mb_group`에 지자체 코드 저장 등.
+- [ ] **지정판매소(mb_level=2)**: 담당 **지정판매소** 1개와 1:1 연결할지.  
+  - 예: `member`에 `mb_shop_idx`(지정판매소 FK) 추가, 또는 지정판매소 테이블에 `mb_idx`(로그인 회원 FK) 추가.
+- [ ] **일반 사용자(mb_level=1)**: 지자체/지정판매소 연결 필요 여부(앱 바코드 확인만 쓰는 경우 연결 없을 수 있음).
+
+---
+
+## 4. 그 외 엔티티 테이블
+
+**상황**: 담당자, 업체, 판매 대행소, 무료용 대상자, 발주, 단가, 포장단위 등 **지자체별** 데이터가 나오나, 전부 **테이블 구조 미정**.
+
+**결정 필요**:
+- [ ] **담당자**: 테이블 유무, 지자체 FK, 소속 종류(구/군/대행소/제작업체) 저장 방식.
+- [ ] **업체**(협회, 제작업체, 회수업체): 테이블 1개에 업체종류 구분할지, 테이블 분리할지. 지자체 FK.
+- [ ] **판매 대행소**: 테이블 정의, "소속 지자체 설정" 시 지자체 FK.
+- [ ] **발주**: 기능목록의 "발주 저장 테이블 컬럼"을 기준으로 **테이블명·PK·타입** 확정. 구/군 코드·동 코드는 어느 테이블(기본코드?)과 연결할지.
+- [ ] **단가·포장단위**: "지역별 봉투 코드" — 지역=지자체인지 구/군인지, 봉투 종류 테이블과의 관계.
+
+---
+
+## 5. 기본코드(기본코드 종류·세부 코드)
+
+**상황**: "기본코드 종류" 시트 참고, "세부 기본코드" 시트 참고라고만 되어 있고, **테이블 구조·코드 체계**는 자료에 없음.
+
+**결정 필요**:
+- [ ] 기본코드용 테이블 개수(종류 1개 + 세부 1개 등), PK/코드 컬럼 설계.
+- [ ] 판매소번호·구코드에서 말하는 "기본코드 B, C, D"가 이 테이블과 동일한지, 코드 값 정의 주체(초기 데이터·마이그레이션).
+
+---
+
+**정리**: 지자체·지정판매소·사용자 연결·그 외 엔티티·기본코드까지 **DB 구조를 한 번에 설계할지**, 아니면 **기능 단위(예: 지정판매소 관리 먼저)** 로 테이블을 정해 나갈지도 결정이 필요함.

docs/결정_필요한_사항들/02-사용자_및_수집정보.md

@@ -0,0 +1,53 @@
+# 결정 필요: 사용자 및 수집 정보
+
+> 회원(사용자) 관련해 **자료에 명시되지 않아 결정이 필요한** 항목.
+
+---
+
+## 1. 회원가입 시 수집 항목
+
+**상황**: 웹 기능목록에는 "사용자 등록/수정/삭제"만 있고, **가입·등록 시 어떤 항목을 필수/선택으로 수집할지** 목록이 없음. 개인정보처리에서는 "이름", "개인 휴대전화" 비식별화 표시만 언급됨.
+
+**결정 필요**:
+- [ ] **필수 수집 항목**: 아이디, 비밀번호, 이름 외에 **이메일·전화번호**를 필수로 할지. (현재 구현은 이메일/연락처 선택)
+- [ ] **지정판매소·지자체관리자** 가입 시 추가 수집 항목: 사업자번호, 소속 지자체/판매소 등 — 회원가입 폼에 넣을지, 승인 후 관리자가 입력할지.
+- [ ] **개인정보보호법**·내부 정책에 맞는 최소 수집 항목 정리 후, 기능목록·화면에 반영할지.
+
+**참고**: 지정판매소·담당자·업체의 "등록 항목"은 CSV에 있으나, 이는 **회원(로그인 계정)** 과는 별개 주체일 수 있음. "지정판매소 사용자"가 지정판매소 1곳과 연결되는 구조라면, 회원 수집 항목과 지정판매소 등록 항목을 구분해 정의하는 것이 좋음.
+
+---
+
+## 2. 사용자 권한 승인 플로우
+
+**상황**: "사용자가 브라우저에서 사용자 등록했을 때, 요청 권한을 확인 후 승인하는 루틴 구현" — **어떤 권한을 요청 가능한지, 승인 시 어떤 데이터를 넣는지** 미정.
+
+**결정 필요**:
+- [ ] **요청 가능 권한**: 일반(1), 지정판매소(2), 지자체관리자(3) 전부 허용할지. 지정판매소/지자체는 **승인 전용**으로 할지.
+- [ ] **승인 대기 저장**: 승인 대기 건을 저장할 **테이블** (예: `member_approval_request`) — 저장 필드: 요청자 mb_idx, 요청 mb_level, 요청 시각, 승인/반려 여부, 승인자 등.
+- [ ] **지정판매소 승인 시**: "어느 지정판매소와 연결할지"를 승인 단계에서 선택하게 할지, 지정판매소는 미리 등록되어 있고 회원가입 시 지정판매소 코드를 입력하게 할지.
+- [ ] **지자체관리자 승인 시**: 담당 지자체(또는 구/군)를 승인 시 지정할지.
+
+---
+
+## 3. 삭제(탈퇴) 후 5년 유지
+
+**상황**: "삭제 상태로 관리, 5년 유지" — **5년 경과 후 처리**는 기능목록에 없음.
+
+**결정 필요**:
+- [ ] 5년이 지난 삭제(탈퇴) 데이터를 **물리 삭제**할지, **별도 아카이브**로 옮길지.
+- [ ] 5년 정책을 **배치(스케줄)** 로 수행할지, 수동 점검으로 할지.
+- [ ] "5년" 기준: `mb_leavedate` 기준 5년인지, 별도 정책일지.
+
+---
+
+## 4. 로그인 실패 lock·2차 인증
+
+**상황**: "5회 이상 로그인 실패 시 lock", "2차인증 적용" — **lock 해제 방법, 2차 인증 방식** 미정.
+
+**결정 필요**:
+- [ ] **Lock 해제**: 시간 경과(예: 30분) 자동 해제, 관리자만 해제, 비밀번호 찾기로 해제 등.
+- [ ] **2차 인증**: SMS/이메일 OTP, TOTP(앱), 없음 등. 적용 대상(전체/지자체관리자 이상만 등).
+
+---
+
+**정리**: 회원 수집 항목·권한 승인 플로우·5년 유지·로그인 lock/2차인증은 **보안·개인정보·운영**과 직결되므로, 결정 후 개발 규칙·완료된 개발 내역에 반영하는 것이 좋음.

docs/결정_필요한_사항들/03-기능_명세_보완.md

@@ -0,0 +1,74 @@
+# 결정 필요: 기능 명세 보완
+
+> 회의 내용 참고·기능목록에서 **"확인 필요"·"조합"·"구청마다"** 등으로 남은 사항.
+
+---
+
+## 1. 전화 주문·구청별 기본 단위 (회의 내용 참고)
+
+**자료**: `종량제_개발목록_20260127(회의 내용 참고).csv`
+
+- "**주문시 구청마다 기본 단위가 달리 설정** 될 수 있어야 함"
+- "**조합 방식 확인 필요** - 전화 주문 관리"
+
+**결정 필요**:
+- [ ] "기본 단위" 의미: 주문 수량 입력 시 **박스/팩/낱장** 중 기본 선택 단위를 구청(지자체)별로 다르게 둘지.
+- [ ] 해당 설정을 저장할 **테이블·컬럼**: 지자체(또는 구/군)별 설정 1행에 "기본 주문 단위" 등.
+- [ ] "조합 방식": 전화 주문과 웹/앱 주문의 **처리 흐름 통합** 여부, 조합(패키지) 상품 존재 여부 등 — 요구사항 구체화 필요.
+
+---
+
+## 2. 봉투 단가 (회의 내용 참고)
+
+- "**봉투단가는 지자체마다 정해져있지는 않음**"
+- "현재는 구청으로 부터 7원 받음" 등
+
+**결정 필요**:
+- [ ] 단가 테이블 구조: **지자체별**로 다를 수 있게 할지, **공통 단가 + 지자체별 오버라이드** 구조로 할지.
+- [ ] "지자체마다 정해져있지는 않음"을 **기능으로 어떻게 반영**할지(기본 단가만 사용, 지자체별 단가 선택 사용 등).
+
+---
+
+## 3. 대행소·권한 (회의·기능목록)
+
+- "**대행소 : ex 달성군은 읍, 면에서 판매**"
+- "**권한별 메뉴 접근 제어 필요**"
+- 재고 현황은 "**로그인 한 구/군과 대행소**의 봉투 및 스티커 종류별 재고량 표시"
+
+**결정 필요**:
+- [ ] **대행소**가 지자체(구/군)와 동급인지, 하위인지(구/군 소속 대행소). 재고·판매 단위가 "구/군"과 "대행소" 둘 다 필요한지.
+- [ ] 메뉴 접근 제어: **메뉴별로** super admin / 지자체관리자 / 지정판매소 / 일반 **노출 여부**를 DB(메뉴·권한 테이블)로 관리할지, 코드로만 제어할지.
+
+---
+
+## 4. 접수·배달일·수령 (회의 내용 참고)
+
+- "**접수는 당일, 배달일은 익일로 표시**"
+- "**창구 수령인 경우 '수령' 처리** 가능해야함"
+
+**결정 필요**:
+- [ ] 주문(전화 접수) 테이블에 **접수일**, **배달일**, **수령 구분**(배달/창구수령) 등 컬럼 정의.
+- [ ] "수령" 처리 시 재고·정산 반영 방식 일치 여부.
+
+---
+
+## 5. 가상계좌·입금 조회 (회의·기능목록)
+
+- "**가상계좌 입금 실시간 조회** 가능해야함 - **헥토파이낸셜 연계?**"
+- 지정판매소마다 할당된 가상계좌 표시
+
+**결정 필요**:
+- [ ] 가상계좌·입금 조회를 **헥토파이낸셜(또는 특정 PG사)** API로 할지, 수동 입력만 할지.
+- [ ] 가상계좌를 **지정판매소별**로 저장할지(기능목록에는 "지정판매소마다 할당된 가상계좌"로 나옴).
+
+---
+
+## 6. 기타
+
+- **무료용 불출**: "구청 있는 구청 없는 구청 있기 때문에 구분 필요" — 구청 유무에 따른 **화면/프로세스 분기** 정의 필요.
+- **인쇄 시 결재란**: "인쇄 시 결재란 출력되어야 함" — 어떤 메뉴/리포트에 적용할지, 레이아웃 정의.
+- **블록 해싱·블록 저장**: 발주에 "블록 해싱값", "블록에는 … 저장" — **블록**을 별도 테이블로 둘지, 발주 테이블 컬럼만으로 둘지, Phase 1에서 제외할지.
+
+---
+
+**정리**: 위 항목은 **업무·정책·외부 연동** 쪽 결정이 필요하므로, 실무·발주처와 정리 후 기능 명세·DB 설계에 반영하는 것이 좋음.

docs/결정_필요한_사항들/README.md

@@ -0,0 +1,22 @@
+# 결정 필요한 사항들
+
+> 종량제 관련 자료·기능목록에서 **명확하지 않아 결정이 필요한 항목** 정리. 확정 후 개발·DB 설계에 반영.
+
+---
+
+## 문서 목록
+
+| 파일 | 분류 | 요약 |
+|------|------|------|
+| [01-DB_및_도메인_구조.md](01-DB_및_도메인_구조.md) | DB·도메인 | 지자체/지정판매소/사용자 저장 구조, 테이블 설계 |
+| [02-사용자_및_수집정보.md](02-사용자_및_수집정보.md) | 회원·개인정보 | 회원 수집 항목, 권한 승인 플로우 |
+| [03-기능_명세_보완.md](03-기능_명세_보완.md) | 기능·업무 | 회의 참고 사항, 구청별 단위·조합 방식 등 |
+
+---
+
+## 참조 자료
+
+- `docs/종량제 관련 자료/종량제 개발목록/종량제_개발목록_20260127(웹 기능목록) (1).csv`
+- `docs/종량제 관련 자료/종량제 개발목록/종량제_개발목록_20260127(회의 내용 참고).csv`
+- `docs/개발 규칙/06-데이터베이스정리구조.md`
+- `writable/database/login_tables.sql` (현재 정의된 테이블: member, member_log만 존재)