docs: 문서 오류 수정 2

Author: SOIV

docs/v2_FINANCIAL-LEDGER/architecture/01-decisions.md

@@ -409,47 +409,6 @@ MongoDBProvider는 Query Builder를 MongoDB Query Object로 변환합니다. 예
 
 ---
 
-## 📝 요약표
-
-| 결정 | 선택 | 핵심 이유 | 상태 |
-|------|------|----------|------|
-| #1 Module Loader | 런타임 동적 Import | VSCode 방식 UX | ✅ 확정 |
-| #2 관리자 인증 | 로컬 로그인 우선 + PIN | 간단하면서 안전 | ✅ 확정 |
-| #3 DB 추상화 | Query Builder | 적절한 레벨 | ✅ 확정 |
-| #5 API 네임스페이스 | Internal/External 분리 | 보안 및 AI 연동 최적화 | ✅ 확정 |
-
----
-
-## 🔄 변경 이력
-
-| 날짜 | 버전 | 변경 내용 |
-|------|------|----------|
-| 2025-01-29 | 1.0.0 | 최초 작성 (#1, #2, #3) |
-| 2026-03-05 | 1.1.0 | API 네임스페이스 분리 결정 추가 (#5) |
-
----
-
-## 📌 다음 단계
-
-### 즉시 진행 (Step 1)
-- ✅ 핵심 결정 사항 문서화 완료
-- 🔄 기존 문서에 교차 참조 추가 시작
-
-### 문서 정리 (Step 3)
-1. `architecture/00-overview.md` - Frontend 서빙 로직 명확화
-2. `technical/02-authentication.md` - 로컬 로그인 우선 + 선택 OAuth + PIN으로 수정
-3. `modules/01-development-guide.md` - 교차 참조 추가
-
-### 구현 시작 (Step 2)
-- 문서 정리 완료 후 코어 구현 시작
-
----
-
-> 💡 **중요:**  
-> 이 문서의 결정사항은 프로젝트 전반에 영향을 미칩니다.  
-> 변경이 필요한 경우 반드시 문서를 업데이트하고 버전을 올립니다.
-
-
 ## 결정 #5: API 네임스페이스 분리 (Internal vs. External)
 
 ### ✅ 결정 사항
@@ -502,3 +461,45 @@ Fieldstack은 프라이버시 중심의 개인 시스템이지만, OpenClaw와 
 
 > 📖 **OpenAPI Baseline:**  
 > → `technical/05-openapi-baseline.yaml`
+
+---
+
+## 📝 요약표
+
+| 결정 | 선택 | 핵심 이유 | 상태 |
+|------|------|----------|------|
+| #1 Module Loader | 런타임 동적 Import | VSCode 방식 UX | ✅ 확정 |
+| #2 관리자 인증 | 로컬 로그인 우선 + PIN | 간단하면서 안전 | ✅ 확정 |
+| #3 DB 추상화 | Query Builder | 적절한 레벨 | ✅ 확정 |
+| #5 API 네임스페이스 | Internal/External 분리 | 보안 및 AI 연동 최적화 | ✅ 확정 |
+
+---
+
+## 🔄 변경 이력
+
+| 날짜 | 버전 | 변경 내용 |
+|------|------|----------|
+| 2025-01-29 | 1.0.0 | 최초 작성 (#1, #2, #3) |
+| 2026-03-05 | 1.1.0 | API 네임스페이스 분리 결정 추가 (#5) |
+
+---
+
+## 📌 다음 단계
+
+### 즉시 진행 (Step 1)
+- ✅ 핵심 결정 사항 문서화 완료
+- 🔄 기존 문서에 교차 참조 추가 시작
+
+### 문서 정리 (Step 2)
+1. `architecture/00-overview.md` - Frontend 서빙 로직 명확화
+2. `technical/02-authentication.md` - 로컬 로그인 우선 + 선택 OAuth + PIN으로 수정
+3. `modules/01-development-guide.md` - 교차 참조 추가
+
+### 구현 시작 (Step 3)
+- 문서 정리 완료 후 코어 구현 시작
+
+---
+
+> 💡 **중요:**  
+> 이 문서의 결정사항은 프로젝트 전반에 영향을 미칩니다.  
+> 변경이 필요한 경우 반드시 문서를 업데이트하고 버전을 올립니다.

docs/v2_FINANCIAL-LEDGER/architecture/03-resilience-operations.md

@@ -1,4 +1,6 @@
-## 📄 시스템 탄력성 운영 아키텍처 (System Resilience Operations)
+# 시스템 탄력성 운영 아키텍처 (System Resilience Operations)
+
+## 📄 개요
 
 이 문서는 Fieldstack의 장애 대응 전략을 커널 계층이 아닌 사용자 공간(Ring 3) 기준으로 정의합니다.
 본 설계의 목적은 특권 제어가 아니라 서비스 가용성 유지입니다.

docs/v2_FINANCIAL-LEDGER/deployment/02-setup-wizard.md

@@ -1,16 +1,16 @@
 # 웹 기반 설치 마법사
 
-## 개요
-
-시놀로지 NAS와 같은 직관적인 웹 기반 설치 마법사를 제공하여, 명령줄 없이도 쉽게 설치할 수 있도록 합니다.
-
-> **UX 레퍼런스 (향후 소개 문서/공식 페이지 작성 시 참고):**
-> "Ubuntu와 Synology 설치 마법사를 합친 경험"
->
-> - **Ubuntu의 장점** — 내 환경에 직접 설치하는 자유도, 단계별 진행감
-> - **Synology의 장점** — 브라우저에서 전부 해결, 전문 지식 불필요
-> - **Ubuntu의 단점** (터미널, 전문 지식 요구) → 제거
-> - **Synology의 단점** (전용 하드웨어 종속, 고가) → 제거
+## 개요
+
+시놀로지 NAS와 같은 직관적인 웹 기반 설치 마법사를 제공하여, 명령줄 없이도 쉽게 설치할 수 있도록 합니다.
+
+> **UX 레퍼런스 (향후 소개 문서/공식 페이지 작성 시 참고):**
+> "Ubuntu와 Synology 설치 마법사를 합친 경험"
+>
+> - **Ubuntu의 장점** — 내 환경에 직접 설치하는 자유도, 단계별 진행감
+> - **Synology의 장점** — 브라우저에서 전부 해결, 전문 지식 불필요
+> - **Ubuntu의 단점** (터미널, 전문 지식 요구) → 제거
+> - **Synology의 단점** (전용 하드웨어 종속, 고가) → 제거
 
 ## 설치 플로우
 
@@ -299,7 +299,7 @@
 
 **5단계 — 모듈 설치 (70%):** 설정에서 선택된 모듈 목록이 있으면 각 모듈을 순회하며 `installModule`을 호출합니다.
 
-**6단계 — 관리자 계정 생성 (85%):** `createAdminAccount`를 호출합니다. 비밀번호를 bcrypt으로 해싱하여 `allowedUsers` 테이블에 admin 역할로 저장합니다.
+**6단계 — 관리자 계정 생성 (85%):** `createAdminAccount`를 호출합니다. 비밀번호를 Argon2id로 해싱하여 `allowedUsers` 테이블에 admin 역할로 저장합니다.
 
 **7단계 — 최종 설정 (95%):** `finalizeInstallation`으로 마지막 설정을 적용합니다.
 

docs/v2_FINANCIAL-LEDGER/deployment/05-update-channels.md

@@ -72,7 +72,7 @@ v2.2.0  ← Release로 승격
 ```
 
 **권장 사용자:**
-- 기술에 익숑한 사용자
+- 기술에 익숙한 사용자
 - 피드백 제공 가능한 사람
 - 테스트 환경
 - 새 기능에 관심 있는 사람

docs/v2_FINANCIAL-LEDGER/modules/03-system-design.md

@@ -2,7 +2,7 @@
 
 ## 설계 원칙
 
-### 1. 모듈 간 독립성 (Isolaton)
+### 1. 모듈 간 독립성 (Isolation)
 모듈은 서로 직접적으로 `import` 할 수 없습니다. 이는 순환 참조를 방지하고 모듈의 탈부착을 자유롭게 하기 위함입니다.
 
 ### 2. 느슨한 결합 (Loose Coupling)

docs/v2_FINANCIAL-LEDGER/technical/01-database.md

@@ -1,7 +1,7 @@
 # 데이터베이스 정책
 
 > 📌 **핵심 아키텍처 결정:**  
-> → `architecture/decisions.md § 결정 #3: DB 추상화` - Multi-provider 지원 + 통일된 인터페이스
+> → `architecture/01-decisions.md § 결정 #3: DB 추상화` - Multi-provider 지원 + 통일된 인터페이스
 
 **최종 업데이트:** 2025-01-29
 
@@ -36,7 +36,7 @@ DB_PROVIDER를 'mongodb'로 설정하고, MONGODB_URI에 MongoDB의 연결 주
 ## DB 추상화
 
 > 📌 **설계 결정:**  
-> → `architecture/decisions.md § 결정 #3: DB 추상화`  
+> → `architecture/01-decisions.md § 결정 #3: DB 추상화`  
 > - 단일 인터페이스로 모든 DB 지원  
 > - 모듈은 DB 종류를 신경쓰지 않음  
 > - Provider 패턴으로 확장 가능
@@ -50,7 +50,7 @@ DBProvider 인터페이스를 정의합니다. 모든 DB Provider는 동일하
 ### 모듈에서의 사용
 
 > 📖 **모듈 개발 가이드:**  
-> → `modules/development-guide.md § Backend 개발 § service.ts`
+> → `modules/01-development-guide.md § Backend 개발 § service.ts`
 
 모듈에서는 Core의 db 객체를 가져와 사용합니다. 실제로 뒤에서 어떤 DB가 돌고 있는지와 관계없이 동일한 인터페이스로 쿼리를 실행할 수 있습니다. 예시로는 ledger_entries 테이블에 새 항목을 삽입하는 것을 보여줍니다.
 
@@ -59,7 +59,7 @@ DBProvider 인터페이스를 정의합니다. 모든 DB Provider는 동일하
 ## 모듈별 DB 테이블 격리
 
 > 📖 **모듈 시스템:**  
-> → `modules/system-design.md § 데이터베이스 격리`
+> → `modules/03-system-design.md § 데이터베이스 격리`
 
 ### 원칙
 
@@ -76,7 +76,7 @@ DBProvider 인터페이스를 정의합니다. 모든 DB Provider는 동일하
 ## 마이그레이션 전략 (자동화)
 
 > 📖 **상세 설계:**  
-> → `technical/migrations.md` - 버전 관리 및 전처리기 상세
+> → `technical/06-migrations.md` - 버전 관리 및 전처리기 상세
 
 각 모듈은 `backend/migrations/` 폴더 내에 SQL 파일을 배치하여 자신의 스키마를 독립적으로 관리합니다.
 
@@ -85,7 +85,7 @@ Core는 모든 모듈의 마이그레이션을 자동으로 감지하고 실행
 ---
 
 > 📖 **모듈 구조:**  
-> → `modules/development-guide.md § 프로젝트 구조`
+> → `modules/01-development-guide.md § 프로젝트 구조`
 
 각 모듈은 자체 마이그레이션 파일 관리:
 
@@ -134,7 +134,7 @@ MongoDBProvider는 mongodb 라이브러리의 MongoClient를 사용합니다. co
 ## Provider 팩토리
 
 > 📌 **Provider 선택 로직:**  
-> → `architecture/decisions.md § 결정 #3`
+> → `architecture/01-decisions.md § 결정 #3`
 
 createDBProvider 함수는 환경 변수의 DB_PROVIDER 값에 따라 적절한 Provider 객체를 생성합니다. 기본값은 'sqlite'이며, 'postgres', 'sqlite', 'supabase', 'mongodb' 중 하나를 지정할 수 있습니다. 알 수 없는 Provider 이름이면 에러를 발생시킵니다.
 
@@ -145,7 +145,7 @@ getDB 함수는 전역 DB 인스턴스를 관리합니다. 처음 호출되면 c
 ## 모듈에서의 DB 사용
 
 > 📖 **모듈 개발:**  
-> → `modules/development-guide.md § Backend 개발`
+> → `modules/01-development-guide.md § Backend 개발`
 
 ### 기본 쿼리
 
@@ -160,7 +160,7 @@ transferFunds 함수는 한 계좌에서 다른 계좌로 금액을 이체하는
 ## 스키마 정의
 
 > 📖 **모듈 구조:**  
-> → `modules/development-guide.md § schema.ts`
+> → `modules/01-development-guide.md § schema.ts`
 
 ledger_entries 테이블의 스키마를 정의합니다. 열 구성은 다음과 같습니다: id는 기본키인 UUID, user_id는 필수의 UUID, amount는 소수점 2자리까지 가능한 숫자, category는 최대 100자의 문자열, date는 필수의 날짜, created_at과 updated_at은 자동으로 현재 시간으로 설정됩니다.
 
@@ -229,24 +229,24 @@ checkDatabaseHealth 함수는 간단한 SELECT 1 쿼리를 실행하여 DB 연
 ## 📚 관련 문서
 
 ### 핵심 아키텍처
-- 📌 `architecture/decisions.md § 결정 #3` - DB 추상화 설계 결정
+- 📌 `architecture/01-decisions.md § 결정 #3` - DB 추상화 설계 결정
 - 📖 `architecture/00-overview.md` - 전체 아키텍처
 - 📖 `architecture/04-directory-structure.md` - 디렉터리 구조
 
 ### 모듈 개발
-- 📖 `modules/development-guide.md § Backend 개발` - DB 사용 예시
-- 📖 `modules/system-design.md § 데이터베이스 격리` - 격리 원칙
+- 📖 `modules/01-development-guide.md § Backend 개발` - DB 사용 예시
+- 📖 `modules/03-system-design.md § 데이터베이스 격리` - 격리 원칙
 
 ### 배포
 - 📖 `deployment/01-installation.md` - DB 설정
-- 📖 `deployment/configuration.md § 데이터베이스` - 설정 관리
+- 📖 `deployment/03-configuration.md § 데이터베이스` - 설정 관리
 
 ---
 
 ## 🚀 다음 단계
 
 DB 추상화를 이해했다면:
 
-1. **모듈 개발** → `modules/development-guide.md`
+1. **모듈 개발** → `modules/01-development-guide.md`
 2. **스키마 설계** → 테이블 구조 계획
 3. **마이그레이션** → 버전 관리

docs/v2_FINANCIAL-LEDGER/technical/04-scheduler.md

@@ -2,7 +2,7 @@
 
 > 📖 **관련 아키텍처:**  
 > → `architecture/00-overview.md § Plugin Layer` - Scheduler는 Backend Plugin으로 구현  
-> → `modules/system-design.md § 모듈 생명주기` - initialize() Hook에서 작업 등록
+> → `modules/03-system-design.md § 모듈 생명주기` - initialize() Hook에서 작업 등록
 
 **최종 업데이트:** 2025-01-29
 
@@ -29,8 +29,8 @@ apps/api/src/plugins/scheduler/
 ## 작업 등록 방식
 
 > 📖 **모듈 초기화:**  
-> → `modules/development-guide.md § Backend 개발 § index.ts`  
-> → `modules/system-design.md § 모듈 생명주기`
+> → `modules/01-development-guide.md § Backend 개발 § index.ts`  
+> → `modules/03-system-design.md § 모듈 생명주기`
 
 모듈은 **초기화 시 작업을 등록**:
 
@@ -74,7 +74,7 @@ Core의 scheduler를 가져와 초기화 함수 내에서 작업을 등록합니
 ### 2. 구독 결제일 체크
 
 > 📖 **기본 모듈:**  
-> → `modules/default-modules.md § Subscription`
+> → `modules/00-default-modules.md § Subscription`
 
 작업명은 'subscription-payment-check'이며, 매일 오전 9시에 실행됩니다. 실행되면 오늘 날짜와 결제일이 일치하는 구독 목록을 조회하고, 각각에 대해 결제일 안내 알림을 보냅니다.
 
@@ -85,14 +85,14 @@ Core의 scheduler를 가져와 초기화 함수 내에서 작업을 등록합니
 ### 4. Google Drive 자동 백업
 
 > 📖 **통합 서비스:**  
-> → `modules/integrations.md § Google Drive`
+> → `modules/02-integrations.md § Google Drive`
 
 작업명은 'backup-to-drive'이며, 매일 새벽 2시에 실행됩니다. 실행되면 데이터베이스 백업 파일을 생성한 후 Google Drive에 업로드합니다.
 
 ### 5. Slack 리포트 전송
 
 > 📖 **통합 서비스:**  
-> → `modules/integrations.md § Slack`
+> → `modules/02-integrations.md § Slack`
 
 작업명은 'weekly-slack-report'이며, 매주 월요일 오전 9시에 실행됩니다. 실행되면 주간 통계를 생성한 후 Slack으로 전송합니다.
 
@@ -131,7 +131,7 @@ SchedulerSettings 페이지 컴포넌트입니다. 컴포넌트가 열리면 백
 ## 통합 서비스 연계
 
 > 📖 **외부 서비스 통합:**  
-> → `modules/integrations.md`
+> → `modules/02-integrations.md`
 
 Scheduler는 통합 서비스와 함께 사용하여 강력한 자동화 구현:
 
@@ -184,7 +184,7 @@ GET /tasks/:name/history 엔드포인트는 해당 작업의 실행 로그를 
 ## 모듈 종료 시 정리
 
 > 📖 **모듈 생명주기:**  
-> → `modules/system-design.md § 모듈 생명주기 § shutdown()`
+> → `modules/03-system-design.md § 모듈 생명주기 § shutdown()`
 
 모듈의 shutdown 함수에서 scheduler.unregister를 호출하여 해당 모듈이 등록한 작업을 제거합니다. 예시로 ledger 모듈은 종료 시 'ledger-monthly-summary' 작업을 제거합니다.
 
@@ -230,24 +230,24 @@ runningTasks라는 집합(Set)을 사용하여 현재 실행 중인 작업명을
 
 ### 아키텍처
 - 📖 `architecture/00-overview.md § Plugin Layer` - Scheduler의 위치
-- 📖 `modules/system-design.md § 모듈 생명주기` - 작업 등록 시점
+- 📖 `modules/03-system-design.md § 모듈 생명주기` - 작업 등록 시점
 
 ### 모듈 개발
-- 📖 `modules/development-guide.md § Backend § index.ts` - 초기화 Hook
-- 📖 `modules/default-modules.md § Subscription` - Scheduler 사용 예시
+- 📖 `modules/01-development-guide.md § Backend § index.ts` - 초기화 Hook
+- 📖 `modules/00-default-modules.md § Subscription` - Scheduler 사용 예시
 
 ### 통합 서비스
-- 📖 `modules/integrations.md` - 자동화 워크플로우
+- 📖 `modules/02-integrations.md` - 자동화 워크플로우
 
 ### 배포
-- 📖 `deployment/updates.md § 자동 업데이트` - Scheduler 활용
+- 📖 `deployment/04-updates.md § 자동 업데이트` - Scheduler 활용
 
 ---
 
 ## 🚀 다음 단계
 
 Scheduler를 이해했다면:
 
-1. **모듈 개발** → `modules/development-guide.md`
-2. **통합 서비스** → `modules/integrations.md`
+1. **모듈 개발** → `modules/01-development-guide.md`
+2. **통합 서비스** → `modules/02-integrations.md`
 3. **자동화 구축** → 워크플로우 설계