<div id="readability-page-1" class="page"><div aria-label="Content">
<article itemscope="" itemtype="http://schema.org/BlogPosting">

<div itemprop="articleBody">
<p>프로그래밍은 제대로 동작하는 소프트웨어를 효율적으로 만들어내는 일이고, 그걸 잘하려면 유지 보수가 쉬운 코드를 만들어야 한다. 그리고 유지 보수하기 좋은 코드를 만드는 매우 효과적인 방법은 객체를 느슨하게 결합(loose coupling)하는 것이다. Gang of Four는 <a href="https://en.wikipedia.org/wiki/Design_Patterns">디자인 패턴</a>에서 다음과 같이 말했다.</p>
<div><pre><code>Program to an interface, not an implementation.
</code></pre></div>
<p>구현에 의존하지 않고 인터페이스에 의존하는 결합 관계를 느슨하다고 한다. 느슨하게 결합된 코드는 확장이 용이하고 유지보수하기 훨씬 수월하다. 프로그램이 커지고 복잡해져도 관리할 수 있다.</p>
<p>느슨하게 결합된 코드를 짤 수 있게 해주는 소프트웨어 디자인 원칙이자 패턴을 의존성 주입이라고 한다. 강하게 결합된(tightly coupled) 코드에는 없는 요소기 때문에 이런 추가적인 요소가 왜 필요한지 납득하려면 느슨하게 결합된 코드의 장점을 먼저 이해해야 한다.</p>
<h3 id="1-늦은-연결late-binding이-가능하다">1. 늦은 연결(Late Binding)이 가능하다.</h3>
<p>코드를 다시 컴파일하지 않고도 구현체를 갈아 끼울 수 있다. 딱 맞아 떨어지는 예시는 아니지만 모바일 앱 관점에서 보면 운영체제가 업데이트되거나 애플/안드로이드가 제공하는 프레임워크가 업데이트됐을 때 굳이 앱을 새로 배포하지 않아도 유저들은 새로운 기능을 경험할 수 있는 원리와 비슷하다.</p>
<p>하지만 이건 모바일 앱 개발자 입장에서는 와닿지 않는다. 왜냐하면 앱은 개발자가 정의하고 구현한 환경에서만 실행되기 때문에 사실상 구현체를 갈아끼울 일이 없다. 가령 데이터베이스가 필요한 앱을 만들때 앱 개발자 본인이 도입한 데이터베이스 외의 다른 데이터베이스를 쓰는 환경에서 내 앱이 실행될 거라는 가정과 고려 자체를 할 필요가 없다. 따라서 늦은 연결은 모바일 개발자가 누릴 수 있는 이점이라고 보기 어렵다. 하지만 느슨한 결합의 장점은 이게 전부가 아니다.</p>
<h3 id="2-확장과-재사용이-쉽다">2. 확장과 재사용이 쉽다.</h3>
<p>앱은 유저에 맞춰 요구사항이 바뀌고 사업에 맞춰 계속 진화한다. 클래스/모듈을 느슨하게 결합하면 새로운 기능을 개발하거나 기존 기능을 수정하고 확장하는게 쉬워진다. 느슨하게 결합된 코드는 확장에는 열려있고 수정에는 닫혀있게 된다. 느슨하게 결합된 코드에서는 객체를 조립하는 지점(composition root)이 따로 있고 여기서 실제 구현체를 생성해서 주입하기 때문에 인터페이스를 사용하고 있는 쪽 코드는 바뀔 필요가 없다.</p>
<p>예를 들어 앱에 결제 기능이 있을 때, 상품 쪽 코드가 결제 관련 인터페이스에 의존하고 있다면 결제 플로우를 개선하거나 개편해야할 때 결제 기능을 가져다 쓰는 상품 쪽 코드는 아예 건드릴 필요가 없다. 좀 더 일반화해서 A/B 테스팅을 생각해볼 수 있다. 동일한 기능을 여러 종류의 방식으로 제공해야할 때, 그 기능을 호출하는 쪽의 코드 수정 없이도 새 기능을 추가하거나 뺄 수 있다.</p>
<h3 id="3-병렬로-개발-할-수-있다">3. 병렬로 개발 할 수 있다.</h3>
<p>프로젝트와 팀이 커지면 한 코드베이스에 여러 개발자가 병렬적으로 일하게 된다. 코드가 느슨하게 결합되어 있으면 개발자들이 여러 모듈을 동시에 개발하기 쉽다.</p>
<p>그랩 모바일 개발 팀은 100+명의 iOS 개발자가 모빌리티, 푸드, 페이먼트, CX 등 10개 미만의 큰 TF(Tech Family)로 나뉘어져 있다. 각 팀은 다른 팀이 만드는 기능(실시간 채팅, 결제, 잔액 조회, 리워드 포인트, 유저 정보/인증 등등)을 활용하면서도 느슨하게 결합된 코드 덕분에 ‘슈퍼앱’을 동시에 개발할 수 있다.</p>
<h3 id="4-유지-보수가-쉽다">4. 유지 보수가 쉽다.</h3>
<p>클래스와 모듈의 경계와 역할이 명확하게 구분되어 있는 코드는 유지 보수하기 쉽다. 신규 기능을 개발할 때 어디를 수정하면 될지 빨리 파악할 수 있고 영향 범위를 쉽게 볼 수 있다. 하나의 역할만 하는 클래스나 모듈로 결합된 코드에선 디버깅도 덜 힘들다. 역할과 범위가 잘 분리되어 있으면 버그를 일으켰을 만한 지점을 비교적 잘 좁힐 수 있기 때문이다.</p>
<h3 id="5-테스트가-용이하다">5. 테스트가 용이하다.</h3>
<p>정확히 말하면 유닛 테스트가 용이하다. 유닛 테스트를 하려면 테스트 대상을 의존성으로부터 고립시킬 수 있어야 한다. 객체끼리 느슨하게 결합되어 있으면 테스트 대역으로 치환하기가 쉽다.</p>
<p>유닛 테스트의 필요성이나 코드 구조의 테스트 용이성을 높게 평가하지 않는 사람도 있을거다. Jetbrain의 <a href="https://www.jetbrains.com/lp/devecosystem-2021/swift-objc/">2021년 개발자 설문</a>을 보면 62%의 스위프트/Obj-C 개발자가 유닛 테스트를 작성하지 않는다고 한다. 그러나 자동화된 테스트의 이점을 한번이라도 경험해보면 (과장 조금 보태서) 테스트 코드를 안짜던 시절로 돌아갈 수 없다.</p>
<p>유닛 테스트는 상당한 테스트 업무를 자동화할 수 있게 해준다. 그랩에선 100+ 여 명의 개발자가 한달에도 수십 만 줄의 앱 코드를 생산하고 있는데, 유닛 테스트 없이 새로운 코드와 기존 코드의 동작을 전부 수동으로 검사하기란 실질적으로 불가능하다. 그랩에서 우리 팀이 새로 만들어졌을 때 만해도 코드 커버리지가 낮았지만, 1년 넘게 테스트를 추가한 결과 실제로 회귀 버그와 중대 버그의 수가 눈에 띄게 줄었다.</p>
<h2 id="마무리">마무리</h2>
<p>엉클밥에 의하면 객체 지향 언어가 개발자에게 쥐어준 가장 강력한 무기는 다형성을 안전하게 쓸 수 있게 된 것이라고 한다. 다형성이 안전해진 덕분에 개발자는 본인의 시스템이 의존하고 있는 모든 구현체(implementation detail)를 교체 가능한 플러그인으로 만들어 버릴 수 있다. 시스템 사이, 모듈 사이의 결합을 느슨하게 만들 수 있게 된거다. 엉클밥은 더 나아가, <code>이렇게 할 방법이 있다는걸 알면서 시스템을 이런식으로 디자인하지 않을 이유가 대체 무엇이겠냐</code>고 반문한다. (<a href="https://youtu.be/ya1xDCCMh7g?t=4728">The Future of Programming Languages 강연 중</a>)</p>

</div>


</article>
</div></div>

Soojin Ro

프로그래밍은 제대로 동작하는 소프트웨어를 효율적으로 만들어내는 일이고, 그걸 잘하려면 유지 보수가 쉬운 코드를 만들어야 한다. 그리고 유지 보수하기 좋은 코드를 만드는 매우 효과적인 방법은 객체를 느슨하게 결합(loose coupling)하는 것이다. Gang of Four는 디자인 패턴에서 다음과 같이 말했다.
Program to an interface, not an implementation.
구현에 의존하지 않고 인터페이스에 의존하는 결합 관계를 느슨하다고 한다. 느슨하게 결합된 코드는 확장이 용이하고 유지보수하기 훨씬 수월하다. 프로그램이 커지고 복잡해져도 관리할 수 있다.
느슨하게 결합된 코드를 짤 수 있게 해주는 소프트웨어 디자인 원칙이자 패턴을 의존성 주입이라고 한다. 강하게 결합된(tightly coupled) 코드에는 없는 요소기 때문에 이런 추가적인 요소가 왜 필요한지 납득하려면 느슨하게 결합된 코드의 장점을 먼저 이해해야 한다.
1. 늦은 연결(Late Binding)이 가능하다.
코드를 다시 컴파일하지 않고도 구현체를 갈아 끼울 수 있다. 딱 맞아 떨어지는 예시는 아니지만 모바일 앱 관점에서 보면 운영체제가 업데이트되거나 애플/안드로이드가 제공하는 프레임워크가 업데이트됐을 때 굳이 앱을 새로 배포하지 않아도 유저들은 새로운 기능을 경험할 수 있는 원리와 비슷하다.
하지만 이건 모바일 앱 개발자 입장에서는 와닿지 않는다. 왜냐하면 앱은 개발자가 정의하고 구현한 환경에서만 실행되기 때문에 사실상 구현체를 갈아끼울 일이 없다. 가령 데이터베이스가 필요한 앱을 만들때 앱 개발자 본인이 도입한 데이터베이스 외의 다른 데이터베이스를 쓰는 환경에서 내 앱이 실행될 거라는 가정과 고려 자체를 할 필요가 없다. 따라서 늦은 연결은 모바일 개발자가 누릴 수 있는 이점이라고 보기 어렵다. 하지만 느슨한 결합의 장점은 이게 전부가 아니다.
2. 확장과 재사용이 쉽다.
앱은 유저에 맞춰 요구사항이 바뀌고 사업에 맞춰 계속 진화한다. 클래스/모듈을 느슨하게 결합하면 새로운 기능을 개발하거나 기존 기능을 수정하고 확장하는게 쉬워진다. 느슨하게 결합된 코드는 확장에는 열려있고 수정에는 닫혀있게 된다. 느슨하게 결합된 코드에서는 객체를 조립하는 지점(composition root)이 따로 있고 여기서 실제 구현체를 생성해서 주입하기 때문에 인터페이스를 사용하고 있는 쪽 코드는 바뀔 필요가 없다.
예를 들어 앱에 결제 기능이 있을 때, 상품 쪽 코드가 결제 관련 인터페이스에 의존하고 있다면 결제 플로우를 개선하거나 개편해야할 때 결제 기능을 가져다 쓰는 상품 쪽 코드는 아예 건드릴 필요가 없다. 좀 더 일반화해서 A/B 테스팅을 생각해볼 수 있다. 동일한 기능을 여러 종류의 방식으로 제공해야할 때, 그 기능을 호출하는 쪽의 코드 수정 없이도 새 기능을 추가하거나 뺄 수 있다.
3. 병렬로 개발 할 수 있다.
프로젝트와 팀이 커지면 한 코드베이스에 여러 개발자가 병렬적으로 일하게 된다. 코드가 느슨하게 결합되어 있으면 개발자들이 여러 모듈을 동시에 개발하기 쉽다.
그랩 모바일 개발 팀은 100+명의 iOS 개발자가 모빌리티, 푸드, 페이먼트, CX 등 10개 미만의 큰 TF(Tech Family)로 나뉘어져 있다. 각 팀은 다른 팀이 만드는 기능(실시간 채팅, 결제, 잔액 조회, 리워드 포인트, 유저 정보/인증 등등)을 활용하면서도 느슨하게 결합된 코드 덕분에 ‘슈퍼앱’을 동시에 개발할 수 있다.
4. 유지 보수가 쉽다.
클래스와 모듈의 경계와 역할이 명확하게 구분되어 있는 코드는 유지 보수하기 쉽다. 신규 기능을 개발할 때 어디를 수정하면 될지 빨리 파악할 수 있고 영향 범위를 쉽게 볼 수 있다. 하나의 역할만 하는 클래스나 모듈로 결합된 코드에선 디버깅도 덜 힘들다. 역할과 범위가 잘 분리되어 있으면 버그를 일으켰을 만한 지점을 비교적 잘 좁힐 수 있기 때문이다.
5. 테스트가 용이하다.
정확히 말하면 유닛 테스트가 용이하다. 유닛 테스트를 하려면 테스트 대상을 의존성으로부터 고립시킬 수 있어야 한다. 객체끼리 느슨하게 결합되어 있으면 테스트 대역으로 치환하기가 쉽다.
유닛 테스트의 필요성이나 코드 구조의 테스트 용이성을 높게 평가하지 않는 사람도 있을거다. Jetbrain의 2021년 개발자 설문을 보면 62%의 스위프트/Obj-C 개발자가 유닛 테스트를 작성하지 않는다고 한다. 그러나 자동화된 테스트의 이점을 한번이라도 경험해보면 (과장 조금 보태서) 테스트 코드를 안짜던 시절로 돌아갈 수 없다.
유닛 테스트는 상당한 테스트 업무를 자동화할 수 있게 해준다. 그랩에선 100+ 여 명의 개발자가 한달에도 수십 만 줄의 앱 코드를 생산하고 있는데, 유닛 테스트 없이 새로운 코드와 기존 코드의 동작을 전부 수동으로 검사하기란 실질적으로 불가능하다. 그랩에서 우리 팀이 새로 만들어졌을 때 만해도 코드 커버리지가 낮았지만, 1년 넘게 테스트를 추가한 결과 실제로 회귀 버그와 중대 버그의 수가 눈에 띄게 줄었다.
마무리
엉클밥에 의하면 객체 지향 언어가 개발자에게 쥐어준 가장 강력한 무기는 다형성을 안전하게 쓸 수 있게 된 것이라고 한다. 다형성이 안전해진 덕분에 개발자는 본인의 시스템이 의존하고 있는 모든 구현체(implementation detail)를 교체 가능한 플러그인으로 만들어 버릴 수 있다. 시스템 사이, 모듈 사이의 결합을 느슨하게 만들 수 있게 된거다. 엉클밥은 더 나아가, 이렇게 할 방법이 있다는걸 알면서 시스템을 이런식으로 디자인하지 않을 이유가 대체 무엇이겠냐고 반문한다. (The Future of Programming Languages 강연 중)

모바일 앱의 느슨한 결합

댓글