docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거

Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를
Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류.

- 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로
  자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거,
  동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거.
- 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming,
  Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business,
  Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로,
  나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는
  title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백).
  원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지.
- 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서.
- 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는
  지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지.
- Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경.
- 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.

10_Wiki/Topic_Programming/Architecture/Service_Layer_Pattern.md

@@ -0,0 +1,25 @@
+---
+category: Architecture
+tags: [auto-wikified, technical-documentation, architecture]
+title: Service Layer Pattern
+description: "서비스 레이어 패턴(Service Layer Pattern)은 비즈니스 로직을 모델(Model)이나 뷰(View)에서 분리하여 독립적인 서비스 함수나 클래스에서 관리하는 소프트웨어 아키텍처 설계 방식이다 [1, 2]."
+last_updated: 2026-05-04
+---
+
+# Service Layer Pattern
+
+## 📌 Brief Summary
+서비스 레이어 패턴(Service Layer Pattern)은 비즈니스 로직을 모델(Model)이나 뷰(View)에서 분리하여 독립적인 서비스 함수나 클래스에서 관리하는 소프트웨어 아키텍처 설계 방식이다 [1, 2]. 이 패턴을 적용하면 뷰는 HTTP 요청 및 응답을 처리하는 얇은 어댑터 역할만 수행하고, 실제 데이터의 변경과 핵심 비즈니스 규칙의 적용은 서비스 계층이 전담하게 된다 [2, 3]. 주로 여러 모델에 걸친 복잡한 연산을 캡슐화하거나, 비즈니스 로직의 재사용성 및 유닛 테스트 용이성을 극대화하기 위해 실무에서 도입된다 [2-5].
+
+## 📖 Core Content
+* **비즈니스 로직의 중앙 집중화 및 뷰의 경량화**: 뷰(View)나 컨트롤러 계층에서는 비즈니스 로직을 제거하고, 단순히 입력값을 검증한 뒤 서비스 계층을 호출하는 얇은 HTTP 어댑터로 유지한다 [2, 3]. 이를 통해 핵심 비즈니스 로직은 HTTP 요청 문맥(Context) 없이도 독립적으로 테스트할 수 있으며, 관리 명령어(Management commands), 백그라운드 작업(예: Celery), 또는 다른 서비스 등 여러 진입점에서 재사용할 수 있게 된다 [3].
+* **다중 모델 연산의 캡슐화**: 단일 모델에 종속되는 모델 매니저(Model Manager) 패턴으로는 여러 모델의 상호작용을 처리하기 까다롭다 [4]. 서비스 레이어는 A, B, C 등 여러 개의 연관된 모델을 동시에 초기화하고 이메일 알림 전송과 같은 부수 효과(Side effects)를 안전하게 관리하는 복합적인 연산을 캡슐화하는 데 적합하다 [4, 5].
+* **셀렉터(Selector) 패턴과의 역할 분리 결합**: 데이터의 상태를 변경하는 쓰기(Write) 작업은 서비스(Service) 함수가 담당하고, 데이터 조회 로직을 처리하는 읽기(Read) 작업은 전담 '셀렉터(Selectors)' 계층으로 분리하는 구조가 자주 활용된다 [1, 2, 6]. 이러한 방식은 복잡한 데이터베이스 쿼리 필터링이나 N+1 쿼리 문제 방지를 위한 성능 최적화 로직을 중앙 집중화하여 코드의 책임을 더욱 명확하게 구분한다 [2, 6].
+
+## ⚖️ Trade-offs & Caveats
+서비스 레이어 패턴은 로직의 분리와 테스트 용이성을 제공하지만, 모든 로직을 모델과 뷰에서 억지로 빼내어 거대한 하나의 `services.py` 파일에 수천 줄의 코드로 몰아넣게 되는 관리 상의 최악의 안티 패턴으로 변질될 위험을 내포하고 있다 [7]. 따라서 작고 집중된 서비스와 적절한 도메인 모델 메서드를 혼합하여 사용하는 균형 잡힌 설계가 필수적이다 [7]. 
+
+또한, "뚱뚱한 모델(Fat models)" 접근법을 권장하는 특정 프레임워크(예: Django의 공식 문서 방향) 철학과는 상충될 수 있다 [1]. 프레임워크 자체가 제공하는 데이터베이스 액티브 레코드(Active Record) 패턴의 편의성을 일부 포기해야 하며, 서비스 계층이라는 추가적인 추상화 단계를 도입해야 하므로 단순한 CRUD 수준의 애플리케이션에서는 과도한 엔지니어링(Over-engineering)이 될 수 있다는 반대 의견도 존재한다 [1, 8].
+
+---
+*Last updated: 2026-05-03*