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/Backend/Asynchronous_Messaging.md

@@ -0,0 +1,28 @@
+---
+category: Computer_Science_and_Theory
+tags: [auto-wikified, technical-documentation, computer_science_and_theory]
+title: Asynchronous Messaging
+description: "비동기 메시징(Asynchronous Messaging)은 메일, 알림, 로깅, 보관(Archiving) 등의 작업을 처리할 때 시스템이 대기하지 않도록 하는 논블로킹(Non-blocking) 통신 방식이다 [1]."
+last_updated: 2026-05-04
+---
+
+# Asynchronous Messaging
+
+## 📌 Brief Summary
+비동기 메시징(Asynchronous Messaging)은 메일, 알림, 로깅, 보관(Archiving) 등의 작업을 처리할 때 시스템이 대기하지 않도록 하는 논블로킹(Non-blocking) 통신 방식이다 [1]. 동기식 프로토콜인 HTTP가 고트래픽 시스템에서 병목 지점이 될 수 있는 한계를 극복하기 위해 사용되며, 자동 백프레셔(Back pressure) 기능을 갖춘 비동기 통신을 도입하는 것이 권장된다 [1]. 현대 소프트웨어 프레임워크에서는 내장된 전송 계층이나 외부 메시지 큐를 활용해 이러한 비동기 패턴을 실전에 적용하고 있다 [2, 3].
+
+## 📖 Core Content
+*   **비동기 메시징의 역할 및 도입 시기:** 
+    개발자 규모가 작은 조직에서 모놀리식(Monolith) 아키텍처로 프로젝트를 시작하더라도, 메일 전송, 알림, 로깅, 데이터 보관과 같은 작업을 처리하기 위해 가능한 한 빨리 비동기 메시징을 시스템에 내장하는 것이 좋다 [1]. HTTP 통신의 동기적 제약을 우려하여 대안적인 논블로킹 통신 패턴으로 활용된다 [1].
+*   **프레임워크별 실전 패턴 및 지원:**
+    *   **NestJS:** 마이크로서비스 아키텍처를 위한 전송 계층을 내장하고 있으며, Redis, NATS, Kafka, RabbitMQ와 같은 메시지 브로커를 기본적으로 지원한다 [2, 4-6]. NestJS 환경에서는 요청-응답(Request-response) 패턴뿐만 아니라 이벤트 기반(Event-based) 메시지 패턴을 모두 유연하게 처리할 수 있다 [2].
+    *   **Spring Boot:** 대규모 엔터프라이즈 환경에 널리 쓰이는 Spring Boot는 메시지 큐 연동을 위해 Spring AMQP, Spring Kafka 등을 지원한다 [7].
+    *   **Django:** Django 환경에서 복잡한 비동기 작업은 전통적으로 Celery와 같은 외부 큐를 결합하여 처리하는 패턴이 주로 사용된다 [3]. 아울러 최신 버전(Django 6.0 등)에서는 요청-응답 주기(Request-response cycle) 외부에서 비동기 데이터를 처리하거나 이메일을 전송할 수 있도록 백그라운드 처리를 위한 'Tasks Framework'가 기본 도입되었다 [8].
+
+## ⚖️ Trade-offs & Caveats
+*   **도입 및 운영 복잡성 증가:** 비동기 메시징 처리를 위해 Celery와 같은 외부 큐 기반 시스템을 도입하는 것은 애플리케이션을 과도하게 복잡하게 만들고 잦은 실수를 유발하는 요인(footguns)이 될 수 있다는 강력한 비판이 존재한다 [9]. 이에 대한 대안으로 Dramatiq을 사용하거나, 최근 프레임워크 자체에 내장된 백그라운드 태스크 기능을 활용하여 복잡도를 낮추려는 시도가 권장된다 [9, 10].
+*   **데이터 검증 및 스키마 관리 문제:** 비동기 작업이나 메시지 큐를 통해 데이터를 전달할 때, 타입이 지정되지 않은 원시 딕셔너리(untyped dicts)를 코드 전반에 남용하는 것은 유지보수를 어렵게 하는 코드 악취(Code smell)로 간주된다 [9]. 비동기 외부 큐를 사용할 때는 데이터 무결성을 위해 Pydantic과 같은 라이브러리를 활용하여 전달되는 데이터 스키마를 엄격히 검증하고 관리하는 패턴이 필수적이다 [3, 9].
+
+
+---
+*Last updated: 2026-05-03*