<div id="readability-page-1" class="page"><div>
 <div id="SE-1dfa2b59-8018-11f0-8864-4526f30f07b1">
 <a href="#" onclick="return false;" data-linktype="img" data-linkdata="{&quot;id&quot; : &quot;SE-1dfa2b59-8018-11f0-8864-4526f30f07b1&quot;, &quot;src&quot; : &quot;https://mblogthumb-phinf.pstatic.net/MjAyNTA4MjNfMTQ5/MDAxNzU1OTUwMzcwNDY4.1IZZz_21JdrsN8twHpW_Y9xo8nCSFh4fqrg_vH41x1Mg.sxw74hBbLBvqlfMJT9IjnJVmm_sF5JXSQoa_rCKG3Jsg.JPEG/SE-1dfa2b59-8018-11f0-8864-4526f30f07b1.jpg&quot;, &quot;originalWidth&quot; : &quot;711&quot;, &quot;originalHeight&quot; : &quot;844&quot;, &quot;linkUse&quot; : &quot;false&quot;, &quot;link&quot; : &quot;&quot;}">
 <img src="https://mblogthumb-phinf.pstatic.net/MjAyNTA4MjNfMTQ5/MDAxNzU1OTUwMzcwNDY4.1IZZz_21JdrsN8twHpW_Y9xo8nCSFh4fqrg_vH41x1Mg.sxw74hBbLBvqlfMJT9IjnJVmm_sF5JXSQoa_rCKG3Jsg.JPEG/SE-1dfa2b59-8018-11f0-8864-4526f30f07b1.jpg?type=w800" data-width="265" data-height="314" alt="">
 </a>
 
 </div>
 <div id="SE-8a062b96-da18-412d-8e21-00f10054d4a4">
 흔히 개발자들이 말하는 거짓말이 있다."지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때는 생산성이 낮아진다." 실제로 이 말은 나의 지인에게서도 들었던 말이기도 하다. 이미 구조가 망가져있는 상태에서 기능 추가를 하게 되니, 그 망가진 구조의 원인의 배경과 동작 방식을 파악하고 그 구조에 맞게 슬쩍 기능을 이어다 붙이는 것이다. 전체를 바꾸는 것의 부담과 책임이 미뤄지면서 구조는 점점 더 망가진다. 그러나 진실은 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다는 것이다.​아키텍처는 기능을 빨리 내는 것이 아니라, 변화 비용을 낮추는 구조를 설계하는 일이다. 소프트웨어는 부드러워야(Soft) 한다. 이 말은 다시 말해 변경하기 쉬워야 한다. 업무 관리자의 눈에는 기능이 동작하기만 하면 되겠지만, 프로그래밍을 하는 입장에서는 그들의 태도에 반기를 들어야 한다. 완벽하게 동작하지만 수정이 매우 어려운 프로그램을 받고 싶은가, 동작은 하지 않지만 변경이 쉬운 프로그램을 받고 싶은가? 물론 업무 관리자도 변경이 가능한 시스템을 원한다고 할 것이다. 하지만 현재 기능의 동작 여부가 더 중요하다는 입장일 것이다. 우리가 개발자로서 현재 기능을 만드는 데 급급하다가, 미래의 요구사항에 "변경 비용이 너무 커서 현실적으로 적용이 불가능합니다."라는 말을 하게 된다면 억울하게도 우리의 역량을 의심받을 지도 모른다. 그러니 개발자에게 필요한 역량으로, 언제든 변경하기 쉬운 코드를 짜야만 한다.​이 책은 개발자가 어떤 관점에서 코드를 바라봐야하는지 제시해준다. 흔히 알고 있는 SOLID에 대한 내용도, 컴포넌트 원칙에 대한 내용도 물론 나온다. 그리고 아키텍처 설계에 대한 저자의 주장들이 나오는데, 중간중간 난해한 내용들이 있어서 완벽하게 공감하기는 어려웠다. 다만 영감을 받았던 내용은 6부의 세부사항이었다. 운영체제, DB나 웹, GUI, 프레임워크 모두 세부사항이라는 것이다. 이러한 세부사항을 아키텍처랑 결합하지 말라는 것이다. 아키텍처의 가장 바깥쪽에 해당하는 것들을 핵심 코드에 묶이도록 하지 말라는 것이다. 심지어 저자는 프레임 워크가 제공하는 클래스에서 파생된 코드를 업무 객체에 쓰지 말라고 한다. 예를 들어 Spring 처럼 훌륭한 DI Framework에서 업무 객체에 @Autowired 같은 것으로 스프링 객체를 주입시키지 말라고 한다. 나조차도 고민을 꽤나 하던 부분인데 Spring에서 제공하는 객체는 최대한 Config 방식으로 따로 분리하고는 있지만, 모든 걸 지키기는 어려운 것 같다. 그러나 계속 고민해보며 더 좋은 방식을 찾아갈 것이다.​조건 분기 지옥을 경험해본 적이 있었을 것이다. 심지어 사람들이 많이 사용하는 라이브러리 몇 개의 코드를 뜯어봐도 if ~ if ~ if ~ 지옥을 심심찮게 볼 수 있다. if 분기문의 예제를 가져왔으니 한 번 살펴보도록 하자.​만약 E-Commerce에서 고객 등급에 따라서 할인율을 다르게 적용해준다고 가정을 해보자.가장 쉽게는 고객 등급을 보고 if문이나 when 절로 다음과 같이 구현할 것이다.
 </div> <div id="SE-8f206bcf-ef33-4969-a7f9-72ddcd6a8c58">
 fun calculateDiscount(customerType: String, amount: Double): Double {
 return when (customerType) {
 "REGULAR" -&gt; amount * 0.05 // 5% 할인
 "VIP" -&gt; amount * 0.15 // 15% 할인
 else -&gt; 0.0
 }
}
 </div> <div id="SE-2ac321c4-71fd-4fa4-9a61-6455329756f8">
 이번에 기획자로부터 새로운 요구사항이 들어왔다."개발자님, 여름 이벤트를 시작할 거예요. 일반 유저는 8%할인, VIP는 20%할인을 추가해주세요. 아, VIP는 10만원 이상 구매 이벤트로 18% 할인을 추가해주세요. 그리고 새로운 등급도 추가하기로 했습니다. PREMIUM 등급인데, 여름 이벤트로 25% 할인, 5만원 이상 구매시 22% 할인, 기본적으로는 20% 할인을 해주세요."
 </div> <div id="SE-0d6fc227-3ba3-48eb-9137-da098b21e49f">
 fun calculateDiscount(customerType: String, amount: Double, seasonalEvent: String? = null): Double {
 return when (customerType) {
 "REGULAR" -&gt; {
 if (seasonalEvent == "SUMMER") {
 amount * 0.08 // 여름 이벤트 8% 할인
 } else {
 amount * 0.05 // 기본 5% 할인
 }
 }
 "VIP" -&gt; {
 when {
 seasonalEvent == "SUMMER" -&gt; amount * 0.20 // VIP 여름 이벤트 20% 할인
 amount &gt; 100000 -&gt; amount * 0.18 // 고액 구매시 18% 할인
 else -&gt; amount * 0.15 // 기본 15% 할인
 }
 }
 "PREMIUM" -&gt; { // 새로운 등급 추가
 when {
 seasonalEvent == "SUMMER" -&gt; amount * 0.25
 amount &gt; 50000 -&gt; amount * 0.22
 else -&gt; amount * 0.20
 }
 }
 else -&gt; 0.0
 }
}
 </div> <div id="SE-5d4a9ec4-ea82-48ca-861f-27253356a769">
 개발자는 기존 코드에 위와 같이 붙여나갈 것이다. 함수가 엄청 복잡해지기 시작한다. 각 등급별로 적용되는 정책들도 제각각인 경우도 흔하다. 이는 새로운 조건 추가시에 기존 코드 수정이 필요하여 개방-폐쇄 원칙을 위반하기도 하고, 함수가 복잡해져서 가독성도 해치고, 테스트도 점점 어렵고 복잡해진다.​우리는 이럴 때 전략 패턴을 적용한다.​<ol><li>전략 인터페이스 정의</li></ol>
 </div> <div id="SE-1f02821b-2df2-4bc5-98dc-2e64cf6cd231">
 interface DiscountStrategy {
 fun calculate(amount: Double, isSummer: Boolean = false): Double
}
 </div> <div id="SE-a3817253-5313-414b-916a-02a1ea1a4ff6">
 class RegularDiscount : DiscountStrategy {
 override fun calculate(amount: Double, isSummer: Boolean): Double {
 return if (isSummer) amount * 0.08 else amount * 0.05
 }
}

class VipDiscount : DiscountStrategy {
 override fun calculate(amount: Double, isSummer: Boolean): Double {
 return when {
 isSummer -&gt; amount * 0.20
 amount &gt; 100_000 -&gt; amount * 0.18
 else -&gt; amount * 0.15
 }
 }
}

class PremiumDiscount : DiscountStrategy {
 override fun calculate(amount: Double, isSummer: Boolean): Double {
 return when {
 isSummer -&gt; amount * 0.25
 amount &gt; 50_000 -&gt; amount * 0.22
 else -&gt; amount * 0.20
 }
 }
}
 </div> <div id="SE-f70782b4-d310-415e-946f-e6fb3ecdc0ae">
 3. 전략 팩토리 구현 (List든 Map이든 핵심은 전략들을 모아둔 컬렉션)
 </div> <div id="SE-db28641b-0929-4213-9374-3784e92746a1">
 object DiscountFactory {
 private val strategies = mapOf(
 "REGULAR" to RegularDiscount(),
 "VIP" to VipDiscount(),
 "PREMIUM" to PremiumDiscount()
 )
 
 fun getStrategy(customerType: String): DiscountStrategy {
 return strategies[customerType] 
 ?: throw IllegalArgumentException("Unknown customer type: $customerType")
 }
}
 </div> <div id="SE-0aef6baf-29a3-4e09-85c3-d64d6856cb43">
 fun calculateDiscount(customerType: String, amount: Double, isSummer: Boolean = false): Double {
 val strategy = DiscountFactory.getStrategy(customerType)
 return strategy.calculate(amount, isSummer)
}

fun main() {
 println(calculateDiscount("VIP", 150_000.0, true)) // 30,000 (20% 할인)
 println(calculateDiscount("PREMIUM", 80_000.0)) // 17,600 (22% 할인)
}
 </div> <div id="SE-ccde0642-9491-4843-b0a7-f4938057d1b7">
 여기서 새로운 조건을 추가한다면 어떨까? 예를 들어서 기업 고객이 추가되었다고 가정을 해보자.
 </div> <div id="SE-805c6e8a-28c1-4941-ad38-78088e0e5d30">
 // 새로운 기업 고객 전략 추가
class CorporateDiscount : DiscountStrategy {
 override fun calculate(amount: Double, isSummer: Boolean): Double {
 val baseDiscount = if (amount &gt; 500_000) 0.30 else 0.25
 return amount * baseDiscount
 }
}

// 팩토리에만 추가하면 끝!
object DiscountFactory {
 private val strategies = mapOf(
 "REGULAR" to RegularDiscount(),
 "VIP" to VipDiscount(),
 "PREMIUM" to PremiumDiscount(),
 "CORPORATE" to CorporateDiscount() // 새로 추가
 )
}
 </div> <div id="SE-2f8d3b92-7653-4857-a63b-9dd8e60d9241">
 새로운 요구 사항이 들어와도 기존 코드에 대한 수정이 없다. 단지 팩토리에만 추가해주면 되는 일이다.이렇게 때문에 전략 패턴이 단일 책임 원칙도 지키고, 개방-폐쇄 원칙도 지키며, 테스트도 용이하게 한다. 또한 컨텍스트가 고객 등급에 따라 달라지다보니, 코드의 이해도 쉽고 if/when 같은 분기가 적어지기에 가독성도 향상이 된다. 확장성, 유지보수성, 테스트 용이, 가독성 네 마리 토끼를 모두 잡는다.​나는 이 책을 보고나서, 이전에 if/when 처리를 했던 것을 3개 이상인 경우 전략 패턴으로 수정했다. 훨씬 가독성도 나아지고 테스트도 용이해졌으며, 새로운 요구사항이나 변경사항이 들어올 때도 다른 Context에 영향을 주지 않으면서 작업할 수 있어서 사이드 이펙트 걱정도 크게 줄었다. ​위의 예시는 극히 일부이긴 하지만 컴포넌트 관점으로 바라보는 것, 의존 관리를 바라보는 안목이 조금 생긴 듯 하다. 서비스를 컴포넌트화 관점에서 바라보아서 크기와 경계를 신중히 결정하고, 그 컴포넌트끼리의 의존성에 대해 심사숙고하게 만드는 자세를 길러주었다. 시간이 되면 몇 번 더 읽어봐야겠다. ^^​
 </div> </div></div>

require('develop')

흔히 개발자들이 말하는 거짓말이 있다. "지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때는 생산성이 낮아진다." 실제로 이 말은 나의 지인에게서도 들었던 말이기도 하다. 이미 구조가 망가져있는 상태에서 기능 추가를 하게 되니, 그 망가진 구조의 원인의 배경과 동작 방식을 파악하고 그 구조에 맞게 슬쩍 기능을 이어다 붙이는 것이다. 전체를 바꾸는 것의 부담과 책임이 미뤄지면서 구조는 점점 더 망가진다. 그러나 진실은 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다는 것이다. 아키텍처는 기능을 빨리 내는 것이 아니라, 변화 비용을 낮추는 구조를 설계하는 일이다. 소프트웨어는 부.......

[독후감] 클린 아키텍처 - 로버트 C. 마틴

댓글