Antigravity Agent
9148c358d0
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 폴더 제거.
4.5 KiB
4.5 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | |||
|---|---|---|---|---|---|---|---|
| Architecture |
|
Separation of Concerns | Separation of Concerns(관심사의 분리)는 모듈, 파일, 클래스가 단 하나의 변경 이유만 가지도록 설계하는 소프트웨어 아키텍처의 핵심 원칙입니다 [1]. | 2026-05-04 |
Separation of Concerns
📌 Brief Summary
Separation of Concerns(관심사의 분리)는 모듈, 파일, 클래스가 단 하나의 변경 이유만 가지도록 설계하는 소프트웨어 아키텍처의 핵심 원칙입니다 [1]. 이 원칙은 핵심 비즈니스 로직을 UI, 데이터베이스, 횡단 관심사(Cross-cutting concerns) 등 다른 기술적 세부사항으로부터 완벽히 고립시킴으로써 시스템의 유지보수성과 확장성을 보장합니다 [2, 3]. 현대의 프론트엔드 및 백엔드 프레임워크들은 각자의 고유한 패턴을 통해 이 원칙을 실무에 적용하고 있으며, 비즈니스 로직이 뷰(View) 등 다른 계층으로 누출될 경우 기술 부채가 빠르게 누적되게 됩니다 [3-5].
📖 Core Content
-
프론트엔드 UI와 비즈니스 로직의 분리:
- React: 렌더 프로프(Render Props) 패턴이나 컨테이너/프레젠테이션(Container and Presentational) 패턴을 적용하여 데이터 페칭 등 '동작 논리'를 UI 렌더링과 물리적으로 분리합니다 [6-8]. 이 패턴들은 컴포넌트의 행동 로직은 캡슐화하되, UI 표현은 이를 사용하는 측에 위임함으로써 깔끔한 관심사 분리를 달성합니다 [6].
- Vue 3: Composition API를 활용하여 관련된 상태와 로직을 하나의 블록(Composable)으로 그룹화함으로써 논리적 관심사를 분리합니다 [5]. 이를 통해 비즈니스 로직을 추출하고, 컴포넌트 자체는 순수한 뷰 레이어 기능에 집중하도록 만듭니다 [5].
- Flutter: 대규모 프로젝트의 경우 BLoC(Business Logic Component) 패턴과 같은 스트림 기반의 이벤트 중심 상태 관리 방식을 사용하여 비즈니스 로직과 UI 사이의 엄격한 관심사 분리를 강제합니다 [9].
-
백엔드 아키텍처 수준의 관심사 분리:
- Django의 레이어 분리: 모델(Models)은 오직 데이터의 형태와 저장만을, 뷰(Views)는 HTTP 요청/응답만을, 서비스(Services)는 비즈니스 로직만을 담당하도록 분리하는 것이 실전 권장 사항입니다 [1].
- 클린 / 헥사고날 아키텍처: 핵심 도메인 규칙이 애플리케이션의 여타 부분과 섞이지 않도록 모듈화를 통해 고립시킵니다 [2, 3]. 또한 로깅, 인증, 예외 처리 등 전체 계층을 관통하는 횡단 관심사(Cross-Cutting Concerns)는 비즈니스 로직에 결합되지 않고 미들웨어, AOP, 인터셉터와 같은 인프라스트럭처 계층에서 중앙 집중식으로 분리하여 처리합니다 [2, 10-12].
⚖️ Trade-offs & Caveats
관심사의 분리를 실무 시스템에 구현하기 위해 고도화된 아키텍처 및 디자인 패턴을 도입할 때 다음과 같은 제약 및 반대 급부가 따를 수 있습니다:
- 디버깅 및 코드 추적의 어려움: AOP(관점 지향 프로그래밍)나 인터셉터 도구를 통해 횡단 관심사를 너무 '마법처럼(magical)' 분리할 경우, 코드가 어디서 어떻게 실행되는지 명시적으로 보이지 않게 됩니다 [12, 13]. 이는 새로운 개발자의 온보딩을 어렵게 만들고 예상치 못한 곳에서 에러가 발생할 때 디버깅 난이도를 상승시킵니다 [12, 13].
- 복잡성과 보일러플레이트 코드 증가: 로직과 프레젠테이션을 명확히 나누는 컨테이너 패턴이나 서비스 레이어 등을 강제하면 불가피하게 생성해야 할 파일 개수와 보일러플레이트 코드가 증가합니다 [14, 15].
- 오버엔지니어링 위험: 지나치게 복잡한 분리 패턴이나 의존성 계층(예: 헥사고날 아키텍처의 포트와 어댑터)은 소규모 프로젝트나 1인 개발 환경에서는 오히려 프레임워크 자체의 기능 구축에 과도한 자원을 쓰게 만들어 개발 생산성을 크게 저하시키는 결과를 초래할 수 있습니다 [16-18]. 프론트엔드 환경에서도 렌더 프로프 패턴을 무분별하게 사용할 경우 깊게 중첩된 JSX 래퍼가 생성되는 '래퍼 지옥(Wrapper Hell)' 현상을 유발합니다 [19, 20].
Last updated: 2026-05-03