<div id="readability-page-1" class="page"><article><img src="data:image/webp;base64,UklGRjINAABXRUJQVlA4ICYNAADQhgCdASq3AswBPpFIoEylpCMloPB4WLASCWlu9vRINl4WjiRjchkb85ltlji6J/lWgZnrtP+xuebuBld/pb3pq1yUGeX9o55PVEF6RJjVmLjfU1ATGIXG+pqAmMQuN9TUBMYhcb6moCYxC431NQExiFxvqagJjELjfU1ATGIXG+pqAmMQuN9TUBMYhcb6moCYxC431NQExiFxvqagJjELjfU1ATGIXG49NeUC5zcBJiolDl4hcb6moCYxC431NQExk6RdHEWjsZWfSBvzSwyH+P6y9JjELjfYNndTUBMYhcb6cQ43BMOIb5YQ0WK+fvWlnLI9x1gIfWAJjELjfU1ATK5whaL5Dl1CZH6+kkO2JwRinBF0czejGIXG+46MT80Ldg2d88Q/6epqCHrRBOCLo31XupH1NSe0X/9wmd1NPPEco87qahAzhTLzZrD0C1HaoQs1iEdLL61E0lZbw3X6d1NQE3dATGEEMXNEvANJzCqGy2a6wlfYoJkrfqSbZCO4lWiZXCUOJh5ZrJNi4TUi7LTiIPYh2S1W+pqAm7oCbupzQb/7Vh/BmLnjTzJM1GYV3j1FnguzOvzzOVjM9fYKqm7w8uNg+xzI/uMo4ZjZ+s6qqqYj1M8PcdYAmMQuN9TY9noG3zHUoV27YcnPKmrNqQ2uLhgEgVy4mAXO8N/l/t0l4OqOp8t4Kl77Xc9KVdeIXJigBxswkqIYI71NgJJpL4RqAJo8Uusuy1EPQzNm/drj+3ixvTiL9lAGA2ndfJ8blQ8d5HMWtqPO6moIfWAAR5sIboHh5lFbMhy8jb4BfA/hSmmO4LXYyusSWQTbz6ZPMXG/26vScqUFXgLlmzNG7/llai3qWRk0NRAuN/tmg5hLc+OcHTiu2pPHp8j84JOS8QuN13WczSOF7sYkGLKK3jpVTEMq0IEOMFZLDo9voGJBXur81En1i1qWO3v8JQJKmUSHUniImfCaPdnI7tUbXqjzupqCM6hj/qE35SyKmrh5ZhuLDeiGbe6P1iISFgEmrSw5SCjg1M76ZUGYCNh1un/llRV16RRRF7lvQTvy+r8P0jfU1ATIL9BoTKIZVVPVe7g8gD7bRakrFfgOWDmbxq4303wZC7J7QlVM2xbKdnrGONGfM8hQTtewkPzbJAXkMLjq29jvlAHDSPkAiz4Lq91hbIOl2tHgCk7/AV9GvJEQ0exNJzu4AEPrAExiFxzN9rrCp97A3SUJgfCdSEZJ9UsD9jMSejfVHndTUBN3IsiSXtOVIdO5+uuVu+ha6j30j07qagJkFwl7W02Ml3E5qY33cdYA0OIXG+pqAmM15LPRDlgC62KgTxC431NQExk6XWw7mMQuN9TjLAJjELjfU1ATKuLjfU31OZzOZpF3iFxvqagJjELjfU1ATGIXG+pqAmMQuN9TUBMYhcb6moCYxC431NQExiFxvqagJjBwAP7/KsAAAAAAAAAAmvcujHnWfAu1N3X7yr8zOZgq/OIbC4mbbO8Oy0Dyw7KaHLjHtbdJgPESKjoRMrUQKTjf13tatgn0bNNXfv8+t9mzwpZVPd0kj+99A0qKYLzcJtFFQ51vBqDvCXBJCdzTD7n0MizV5GDgTKTeq5cGWc58fCJgrfrz/irAJ608ZU796Z1ZZGl3eCbr0tKXliiZXifx6cuahOC2FfSqZykFOYIh8Yitd6PBac7akWZ+O6Qz7DDazEzLVoGaRAUEvIJHI3xlm/fCFe2L6UIHw10E99GKn8e0jq+xTeQntZALEoUHzO7hsrAxYDcZlpYTAxVrhuIPXDt//nh6e9j3PsPJSmBQMAEpstUSvNzmEFEeW0x9N06+MhyCo3pgnSGp31be+36j1qprJLNY5vq8pE6HWv4GljWwe9SfYsChWMPgMjPB00B2kzCL4rqFCD+Hd9pz9ISBCkyVLPRRHkd3tTft8SoibAEIe8EXM+zJQCgeyQNu85vFpU9VjpPTUsQIyoVpXAZtAiQ/tKQXOlkbQortOSMsH2wIi9oVaoHevNZVTLl45ogiFFb93OjcjPVQ7YqFdlZHn9SMmiRCIJKgQfNWcr6Z+MoXbfThciWdwAJ7KCAvMa+OIxN0LKcEBCaSrJbOsZXvWBJBz55hFjKbPDYn4qBuX3TkZDRnjegTLG6RxRmp+CAAxlnQx0wny0VE36SnxS6ogrRKLUOZpWBg7z63t7zhzbIq8lRNyvX1Y3mBdDQ06jNoPyBKhWzeCHf+yLcS5WADXbEvWEHqaOtmbsvXLpmmWmfoF7Rxa93HWEiHfoZfCm/g1VXBtXgI70JXlCETRkTIITblm+1FfyKdNTtJrIpH+Zh/UV19PTSrRDTlZvOrXuwWNebiz0C078t7tDflx3RktSth2w0RJj8h+sGPmF380Z3xKDdP7KTOeP0aL7avFiiarKJX7CASXazFtPvekCdEDgadAo7yIC99Bon5ck2GVA/8s10W/7rfoPO4R4RkeKcHUHvneGMDiSIvwFh7rXs6uPIzIjU88wUAMQC8epDxWgPUnDLGLv+vql9NuZpDd3AghdwiwH07fNK7VcbewhnA8HmFXcyF0iOzDSO+0xMZcnKCy1vlVCbRY//kKxuWn4smub3v0MUygs3VzonzBq5lGA7PqNNd032oK0LddcKPxJMbpb+8kpfgIx6RSxuJi5KUjZeg0YPSPWD2IPfTI/W4tK+3uLAzX+DNWpmYZU+CJngrljlQLgjK5/IbbqFngpXBfr4X7vBZ2MSgQLM8+MHYFgUYUVhdL5qQ4qBKbvh6nXElV+1STWHvhwERWF5lTDh1vWFaeHdK1aaGOs+ZewkiZIBnViMiEmyrhLnFZJ0Va4auPjVMcRhqJ/DBhSz3mvJSSFDSSF5t/SpKIVsb9ZbNa8y85DCCzZs3HJ3pPBQW8qpQm2KDLEGSFEn59SZHODn3MbuRty00Kh1hmZ6NUYwb+tRy/SVjyOD4+I0MnWADDs+qB8I22pgZ3WfxMH/kSLoQ7nZZ0vgnJvbZlIuKsACVIBL9CxGnpmw+WlzccUSwZ3lQbclbGl/997Kl3zUFIhsZ8V68nvNr83cnwrUXVkAGI3xjeZh9Vmi3TtBAxjc75lc8fcO/esNmlJ5NM4OH+LXPB2ZmRaHkS6OQZ98nIkokirIBvkvxqtKFRAIYQPu+QjsOHX4aE1p+pq+jtL+VHrK9Kyc7pr/1cs09Ij+Cte0coAWss9RGCplMgkY6FqP5g02NHISimlM5WSdl73IdiFH8Iv6kt6HXDzGZVNHRuSWc+Zvndvs8xnCn17GSxAK083v45GyUGRqbGVP9US2c1K/mFlTH7Kc5Ytke/Hgo9TQMeRg1AX9FKhI7LFEHUhekLzdkgqVDX31fWdKsb9QWfUDF327hTCOyN1EGZ/SKg5zMZKM1HN72WuCzcrjGPab+ARbRO2ZlRhK22yjxJZjMh9soTAJe5zNDbpUMihacc4hWlcOpVyQYT2cTExRuRhOB64y0YQqYAdGsKGtye+1ys2HkobDPV8yyQT/5IFTm7PgQRbKn4lJ/FzqtVZZ2tUcpYxm133/yO+TjR5POBeuhq9Yg5ySVXGNgWXe/EuaAGb/42oa6jqwybFpVxtKSFdJSKr+gW8mZMGMYLzuGTiYoc8rrodNvvFd0f5v1Uhw4alzPj+G52/S/AbqsjXi5qAoWa+ikPgJsW7K2AZJd89nOPm6uSfucL8/ZW/skQ3h/kiSI/ABLmlJEN6yVi5vXScLRszFQDp608FONQVKCfV4imH7ksMjvhyhUCVNfCpPsN0YAAHHG2bpaVmzI3icXFKceEFD+CFg+87Fm8zuZbeyBAa/7Qt1qWbpFWoR9j4JDQh864XHCjDAsV4FEK9ib/0Su/ZQERv4Z0R7DLhj2/wt1ojFfFJ72uN6LfT9oJDbcT/n0ExbrUi6L7JQc2CKkrLU2mWV4VT0bbuu4F8sOL3zOijuZZ7ZCcYYc3aq4ExreW8mTgxm09NpYQCbiJy3WoNyQ10886VcOpENqoYJEanDYpD3shBEX4xrwitKwwekOGxM70vgilE4YBglJ0+pZA9CpFMNfOdRxQBaNeAOXGSDoBIU+RtdjUv3fRc8ydgWsyPE3/ZCT9D+e4bhtH0N76WqU4e5uFbcWvpV+AzjCQVqScwyyHfBnD5LraOtYO/Bz86opiQtulMVFGaK3uD9Jt6iE5O7zxRA5h3x43eg1LggA1a/MJnFIhZBDCgj5a71SPZAPliwoGqql9r6Mv3TxqcoDdLqJfA+MTsn5/5UAGqGkLNV9v4EtlAkj7lt7ncO2FCuGrNPrpzUBCrUtiKwY9AsehFhxaeKVMIndk6ryXusy0shL+KpARdT3RONa308mzAdpmQda/avW/9acV4S/NzDL5j1ahG1wg9AA7xJbNCHnWrjv//Cemu8LGQwN7/QhdGExtDKFMEgvLd7VxCY28CBf2S9JRb3YrjV09FUB4BGd6oRMgCyeJ6w4iAeNECU2QDpxsAAAAAAAAAA=" alt="photo by Julia Margeth Theuer(https://unsplash.com/@juliatheuer?utm_source=templater_proxy&amp;utm_medium=referral) on Unsplash">
소프트웨어 개발을 하다 보면 한 부분을 변경했더니 다른 곳이 모두 깨지는 경험을 누구나 한 번쯤 해봤을 거예요. 
이는 ==높은 결합도(Coupling)==의 전형적인 문제죠. 유지보수가 어려워지고, 기능 변경에 따른 위험이 커져요. 
그렇다면 우리는 어떻게 커플링을 줄이고 구조적인 설계를 적용할 수 있을까요?
<h3 id="커플링이란">커플링이란?<a href="#커플링이란">#</a></h3>
커플링(Coupling)이란 모듈이나 클래스가 서로 얼마나 강하게 의존하는지를 나타내는 결합도를 말해요
<ul>
<li>높은 결합도: 상호 의존성이 크고, 하나를 바꾸면 다른 부분에 연쇄적인 영향</li>
<li>낮은 결합도: 역할과 책임이 잘 분리되어 있어 변경이 영향을 최소화</li>
</ul>
결국 우리가 추구해야 하는 방향은 "높은 응집도, 낮은 결합도"를 가진 코드를 작성하는 거예요. 
응집도는 클래스나 모듈 내부의 구성 요소들이 하나의 목적에만 집중하는 정도를 의미하고 있어요.
커플링의 문제점
<ul>
<li>유지보수 난이도 상승</li>
<li>변경 범위 확대</li>
<li>테스트와 배포에서 불안정성 증가</li>
</ul>
이 문제를 해결하기 위해 아키텍처를 도입하는 이유가 생겨요. 
아키텍처는 단순히 코드 구조를 예쁘게 만드는 것이 아니라, 변경에 강한 시스템을 만들기 위한 약속이니까요.
<h3 id="커플링-확인-방법">커플링 확인 방법<a href="#커플링-확인-방법">#</a></h3>
<ul>
<li>의존성 그래프 분석: 클래스나 모듈 간 연결성을 시각화</li>
<li>코드 리뷰 &amp; 정적 분석 도구 활용</li>
<li>디미터 법칙(Law of Demeter) 점검: 객체 내부 구조를 외부에 노출하지 않고 캡슐화 유지</li>
</ul>
<hr>
<h2 id="solid-원칙과-di">SOLID 원칙과 DI<a href="#solid-원칙과-di">#</a></h2>
아키텍처의 근간에는 SOLID 원칙이 있어요. 
그 중 **SRP(단일 책임 원칙)**과 IoC(제어 역전), **DI(의존성 주입)**은 결합도를 낮추는 핵심 요소예요.
DI에는 세 가지 방법이 있어요:
<ul>
<li>생성자 주입(DI via Constructor) – 가장 안전하고 선호되는 방식</li>
<li>Setter 메서드 주입 – 런타임 시 오류 가능성 존재</li>
<li>필드 주입(Class field) – 테스트와 유지보수에 어려움</li>
</ul>
생성자 DI 예시
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="dart" data-theme="github-dark-dimmed"><code data-language="dart" data-theme="github-dark-dimmed">class SomeService {
 final SomeDependency dependency;
 
 SomeService(this.dependency);
}</code></pre></figure>
Setter DI
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="dart" data-theme="github-dark-dimmed"><code data-language="dart" data-theme="github-dark-dimmed">class SomeService {
 SomeDependency? dependency;
 set setDependency(SomeDependency value) =&gt; dependency = value;
}</code></pre></figure>
ServiceLocator (get_it 패키지 예시)
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="dart" data-theme="github-dark-dimmed"><code data-language="dart" data-theme="github-dark-dimmed">import 'package:get_it/get_it.dart';
 
final getIt = GetIt.instance;
 
void setup() {
 getIt.registerSingleton&lt;SomeService&gt;(SomeService(SomeDependency()));
}
 
// 사용
final service = getIt&lt;SomeService&gt;();</code></pre></figure>
생성자 DI를 우선 사용하고, 필요에 따라 Setter나 ServiceLocator를 사용할 수 있어요. 
외부 객체를 직접 생성하지 않고, 외부에서 받아 쓰는 습관만으로도 커플링이 크게 줄어들어요.
<hr>
<h3 id="역할과-책임의-분리">역할과 책임의 분리<a href="#역할과-책임의-분리">#</a></h3>
아키텍처 적용의 핵심은 **역할(Role)**과 **책임(Responsibility)**을 구분하는 거예요.
<ul>
<li>역할: 무엇을 해야 하는가 (추상화)</li>
<li>책임: 어떻게 할 것인가 (구체화)</li>
</ul>
역할을 나누지 않고 모든 책임을 한 클래스에 담아버리면, 변경 영향이 커지고 재사용성도 떨어져요.
<h3 id="좋은-협력과-나쁜-협력">좋은 협력과 나쁜 협력<a href="#좋은-협력과-나쁜-협력">#</a></h3>
코드상에선 협력 방식에서도 결합도 차이가 생겨요.
<ul>
<li>좋은 협력: Tell, Undirectional, Weak
<ul>
<li>상태를 가져오지 말고 명령하라 (Tell)</li>
<li>단방향 의존성 유지</li>
<li>변경에 영향을 최소화하는 약한 의존성</li>
</ul>
</li>
<li>나쁜 협력: Ask, Bidirectional, Strong
<ul>
<li>상태를 직접 접근(Ask) → 캡슐화 깨짐</li>
<li>양방향 의존 → 스파게티 코드 유발</li>
<li>강한 의존성 → 변경 시 연쇄 오류 발생</li>
</ul>
</li>
</ul>
<hr>
<h2 id="flutter에서-아키텍처-적용">Flutter에서 아키텍처 적용<a href="#flutter에서-아키텍처-적용">#</a></h2>
Flutter 개발에서는 관심사 분리를 통해 주요 영역을 Presentation, Business Logic, Data Layer로 구분하기도 해요.
<ul>
<li>Presentation: 화면(UI)과 사용자 입력 처리</li>
<li>Business Logic: 계산과 도메인 규칙 적용</li>
<li>Data Layer: API, DB, 캐싱 등의 데이터 저장·조회</li>
</ul>
예를 들어 Controller 클래스에 입력 처리와 데이터 로딩을 모두 넣으면 거대한 클래스가 되어 커플링이 심해지죠. 
이를 쪼개서 레이어 역할별로 분리하는 것이 Feature-First 아키텍처의 핵심이다.
<h3 id="feature-first-아키텍처-예시">Feature-First 아키텍처 예시<a href="#feature-first-아키텍처-예시">#</a></h3>
각 기능마다 아래와 같이 계층 분리를 적용해요.
<figure data-rehype-pretty-code-figure=""><pre tabindex="0" data-language="plaintext" data-theme="github-dark-dimmed"><code data-language="plaintext" data-theme="github-dark-dimmed">lib/
├── features/
│ └── product/
│ ├── domain/
│ │ ├── entities/
│ │ └── usecases/
│ ├── data/
│ │ ├── models/
│ │ └── repositories/
│ ├── presentation/
│ │ ├── screens/
│ │ └── widgets/</code></pre></figure>
이렇게 분리하면 각 기능별로 독립적인 개발·테스트가 가능해요.
<hr>
<h3 id="데이터-전달-패턴">데이터 전달 패턴<a href="#데이터-전달-패턴">#</a></h3>
Flutter에서 페이지 간 데이터 전달 시 두 가지 방식이 있어요.
<ol>
<li>extra로 객체 전달 – 화면 전환 시 바로 데이터를 넘김
<ul>
<li>장점: 즉시 사용 가능</li>
<li>단점: 없거나 빈 값일 때 예외 처리 필요</li>
</ul>
</li>
<li>식별값 전달 후 데이터 조회 – 다음 페이지에서 ID로 다시 가져옴
<ul>
<li>장점: 흐름이 명확하고 무결성 확보</li>
<li>단점: 추가 API 호출 필요</li>
</ul>
</li>
</ol>
<hr>
<h2 id="아키텍처-평가-c4-모델">아키텍처 평가: C4 모델<a href="#아키텍처-평가-c4-모델">#</a></h2>
C4 모델은 시스템을 네 가지 수준으로 나눠 시각적으로 분석한다.
<ol>
<li>Context – 시스템과 외부 환경의 상호작용</li>
<li>Container – 실행 가능한 단위로 분리</li>
<li>Component – 컨테이너 내부 구성 요소</li>
<li>Code – 실제 클래스와 함수 수준</li>
</ol>
이를 통해 의존성, 책임 범위를 시각적으로 분석하면서 아키텍처 품질을 정량적으로 평가할 수 있어요.
<hr>
<h2 id="anemic-domain-model-탈출">Anemic Domain Model 탈출<a href="#anemic-domain-model-탈출">#</a></h2>
비즈니스 로직이 없는 객체는 빈약한 도메인 모델이에요. 이를 방지하려면:
<ul>
<li>Domain 계층: Entity, Value Object, Domain Event 등 개념과 규칙 정의</li>
<li>Application 계층: 유스케이스 실행, 도메인과 외부를 연결</li>
<li>Persistence 계층: DB 저장과 조회</li>
<li>Infrastructure 계층: 외부 SDK, 메시징, 오류보고</li>
</ul>
이렇게 수평적(역할별)·수직적(기능별) 분리를 병행하면 클린 아키텍처를 유지할 수 있어요.
<hr>
<blockquote><div>Wisdom is knowing what to do next; Skill is knowing how ot do it, and Virtue is doing it.</div>— David Jordan</blockquote></article></div>

이때의 나

sunhwang

Flutter 개발에서 커플링을 줄이고 아키텍처를 점진적으로 적용하기

Flutter 개발에서 커플링을 줄이고 아키텍처를 점진적으로 적용하기

댓글