<div id="readability-page-1" class="page"><div><figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1400/1*hbpBsCqLydf5iE1jxzEhgA.png" width="700" height="240" loading="lazy" role="presentation"></div></figure>안녕하세요, 왓챠에서 안드로이드 개발을 하고 있는 doro입니다.저는 Browsing 1 스쿼드에 속해있고, 왓챠에서 지원하는 대화면 기기에 대해 사용자들이 좀 더 좋은 UI/UX를 가질 수 있도록 고민하고 있습니다. 이번 스프린트에서는 기존 플레이어 화면의 UI/UX를 개편하고 프로젝트 구조 자체도 리팩토링을 하기로 계획했습니다.<figure><img alt="" src="https://miro.medium.com/max/1200/1*LEE5sIU_HkGdqXq8K_HTlw.gif" width="600" height="338" loading="lazy" role="presentation"><figcaption>기존 안드로이드 TV 플레이어</figcaption></figure>기존 안드로이드 TV 플레이어 화면은 다양한 기능을 제공하지 못했고, UI면에서도 사용자들에게 불편한 점이 많았습니다.그 뿐만이 아니라 프로젝트 구조도 레이어간 결합도가 높다거나 한 객체에 역할이 불확실하게 몰려있었는데요. 때문에 유지보수하는데 어려움이 많았고, 테스트 코드 작성에도 어려움이 있었습니다.이번 포스팅에서는 이런 문제를 해결하기 위해 고려했던 개념들에 대해서 소개해보려고 합니다.<h2 id="f5c6">Object Oriented Programming</h2>코틀린은 객체지향 언어입니다. 객체지향의 3대 요소는 캡슐화, 상속, 다형성입니다. 각 개념을 제공하기 위해 코틀린은 다양한 키워드를 지원하며 여러 가지 형태의 프로그래밍을 할 수 있습니다.그렇다면 객체지향 언어가 추구하고 있는 가치는 무엇일까요? 저는 여러 객체가 역할과 책임을 나누어 서로 협력을 하는 패러다임을 만드는데 있다고 생각합니다.한 객체의 역할을 명확히 정의하는 것은 불필요하게 결합도가 높아지는 것을 막을 수 있고, 응집도를 높혀 관리포인트를 줄일 수 있으며 단위 테스트 코드 작성도 용이하게 하는 등, 여러 가지 실질적인 장점을 가져올 수 있습니다.이에 플레이어 화면을 구성하는 객체의 역할을 정의하는 작업부터 시작했습니다.<h2 id="73a7">역할 분담하기</h2>새로운 플레이어 화면에서 제공하는 기능들을 구현하기 위해서는 많은 상태값을 효율적으로 관리해야만 했습니다.<figure><img alt="" src="https://miro.medium.com/max/1200/1*wuhPbdfL5xN8OGoH87lwQg.gif" width="600" height="338" loading="lazy" role="presentation"><figcaption>개선된 안드로이드 TV 플레이어</figcaption></figure><blockquote>플레이어를 컨트롤할 수 있는 컨트롤러 UI작품의 위치를 변경할 수 있는 썸네일 리스트작품이 시작할 때 나오는 로딩화면</blockquote>이외에도 심의등급 UI, 감상 종료 메뉴, 구간 건너뛰기 버튼 등 수 많은 위젯들의 상태값이 관리되어야 합니다. 이런 상태값들과 관련 비즈니스 로직은 <code>ViewModel</code> 에서 <code>LiveData</code> 나 다른 <code>Model</code>레이어들과의 결합으로 프로젝트 구성을 많이 했었는데요.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1400/1*n2WsvH0gzCVmCj0krzAnQw.png" width="700" height="299" loading="lazy" role="presentation"></div><figcaption>Fat ViewModel</figcaption></figure>벌써 복잡합니다. 문제라고 한다면 플레이어 화면의 기능이 너무 많다는 것인데요. 위의 구조에서 <code>ViewModel</code>이 <code>IntervalSkipButton</code> 관련한 상태값만 3가지를 들고 있고 관련된 비즈니스 로직도 관리를 해야하는 문제가 생기게 되는 것이죠.이는 하나의 객체에게 너무 많은 역할을 할당해서 생긴 문제입니다. <code>ViewModel</code>을 자세히 살펴보면 복잡하게 된 가장 큰 원인은 위젯들이 화면에 나타나는 상태값들입니다.이런 플래그 값들을 관리해주는 객체에게 역할을 분담해준다면 어떨까요? <code>ViewModel</code> 에게 의존하지 않고 각 위젯들별로 상태값을 관리해준다면 객체들끼리 협력하는 패러다임을 만들 수 있습니다.<figure><img alt="" src="https://miro.medium.com/max/1082/1*U3LiaLtOy5P3E_ja44da5g.png" width="541" height="301" loading="lazy" role="presentation"><figcaption>State Delegate</figcaption></figure>각각의 State 객체들은 <code>visible</code> 의 상태값을 가질수도, <code>focused</code> 의 상태값을 가질 수도 있으며 각 객체 독립적으로 해당 기능들의 역할을 수행하게끔 따로 비즈니스 로직도 구성할 수 있습니다.이제 모든 case에 대해서 <code>ViewModel</code> 의 코드를 수정할 일이 없어지게 됩니다. 부가적으로 형상관리에도 매우 용이해지겠군요.<h2 id="9fab">역할 검사하기</h2>이제 나눠진 역할과 책임이 제대로 객체에게 할당되었는지 검사해야겠죠.플레이어 화면에 진입하기 위해서는 이용권이 있어야하며, 심의등급이 18세 이상인 작품일 경우 성인인증을 완료한 유저여야 하는 등 몇 가지 유저의 상태를 확인해야하는 <code>checkPlayable</code>이라는 비즈니스 로직이 있습니다.<pre>fun checkPlayable( playInfo: PlayInfo?, ): TvPlayUnavailableState.State { ... val user = UserHolder.getUser() }</pre>이런식으로 <code>UserHolder</code>라는 싱글톤 객체와의 결합이 생기게 되는데요. 도메인 관점에서는 결합이 생기는것도 나쁘지 않다고 생각이 듭니다. 저 메소드에서의 유저는 항상 <code>getUser()</code> 일테니깐요.하지만 싱글톤 객체를 참조하게 되면 <code>checkPlayable</code> 메소드에 대한 테스트 코드 작성이 어려워집니다.<pre>fun checkPlayable( playInfo: PlayInfo?, user: User ) : TvPlayUnavailableState.State { ... }</pre>위와 같이 수정하여 User객체를 파리미터로 주입받는다면, User의 여러 상태를 <code>checkPlayable</code> 메소드에 주입을 해가면서 이용권이 없는 상태, 성인인증이 안되어있는 상태, 기기 등록수가 넘어있는 상태 등등 여러 가지 상태에 대한 <code>Mock</code> 데이터를 만들어 테스트 코드를 작성할 수 있습니다.한 가지 더 알아볼까요.<figure><div role="button" tabindex="0"><img alt="" src="https://miro.medium.com/max/1400/1*Ugz09UBzB95JUnbTiboP9Q.png" width="700" height="395" loading="lazy" role="presentation"></div><figcaption>플레이어 컨트롤러 UI</figcaption></figure>플레이어 화면에서는 재생, 정지, 다음화 재생, 자막 변경 등 영상 상태와 정보를 제어할 수 있는 컨트롤러라는 UI를 제공하는데요. 이 컨트롤러의 상태를 <code>PlayerControllerState</code>라는 객체에서 관리합니다.<pre>class PlayerControllerState( val playInfo: PlayInfo ) { val title = playInfo.simpleTitle.orEmpty() val description = playInfo.getTvPlayerDescription() val totalDuration = playInfo.duration.toLong() var isFocused by mutableStateOf(false) var isVisible by mutableStateOf(false) ...}</pre>위 코드의 문제는 무엇일까요? <code>PlayerControllerState</code>의 상태를 초기화해주며 <code>playInfo</code>라는 재생 정보를 주입받아 멤버변수를 초기화해주고 있습니다.이 <code>PlayerControllerState</code>가 <code>PlayInfo</code>라는 도메인 클래스를 굳이 알아야 할 필요가 있을까요? 컨트롤러의 상태값은 <code>title</code>, <code>description</code> , <code>totalDuration</code> 만 넘겨받으면 초기화가 가능합니다. 가장 주목해야할 점은<blockquote>PlayerControllerState와 PlayInfo가 공동의 역할을 가지고 있을까?</blockquote>에 대한 질문입니다. 저는 <code>PlayerControllerState</code> 를 작품을 재생할 때, 제목과 설명을 보여주며 유저와의 재생 제어의 상호작용을 책임지는 객체라고 정의했기 때문에, 두 객체의 결합도가 필요 없다고 확정지을 수 있었습니다.<pre>class PlayerControllerState( val title: String, val description: String, val totalDuration: Long ) { var isFocused by mutableStateOf(false) var visible by mutableStateOf(false) var isFocusedOnThumbnail by mutableStateOf(false) var remainingVisibleTime by mutableStateOf(CONTROLLER_VISIBLE_TIME) ... }</pre>위와 같이 수정해준다면 후에 <code>PlayInfo</code> 라는 객체가 수정된다고 한들 <code>PlayerControllerState</code> 는 아무런 영향 없이 필요한 데이터들만 주입받으면 되며, 멀티 모듈의 경우에는 <code>module dependency</code> 관점에서도 좀 더 자유로워 집니다.<h2 id="993b">역할은 스스로</h2>객체들이 각자 역할 수행을 어떻게 하냐도 관점과 방법에 따라서 결합도를 줄일 수 있습니다.왓챠는 작품을 재생할 때 오프닝 건너뛰기라는 기능을 제공합니다. 서버로부터 어느 구간이 오프닝 구간인지 정보를 내려 받는데요.<figure><img alt="" src="https://miro.medium.com/max/1200/1*xG22J_CLHDb8C9me2gdNKQ.gif" width="600" height="338" loading="lazy" role="presentation"><figcaption>오프닝 건너뛰기</figcaption></figure>비슷한 UX로 작품의 감상이 완료되었을 때도 감상 종료 메뉴를 띄워줍니다.<figure><img alt="" src="https://miro.medium.com/max/1200/1*aetq4-Cx9x71xAC5v1eTuQ.gif" width="600" height="338" loading="lazy" role="presentation"><figcaption>감상 종료 메뉴</figcaption></figure>서버로부터 받은 재생정보에 <code>skippableIntervals</code> 라는 필드가 있습니다. 이 필드는 <code>from</code> 과 <code>to</code> 라는 정보가 있고 <code>from = 10, to = 30</code> 이라면, 10초부터 30초 구간은 <code>오프닝 건너뛰기(구간 건너뛰기)</code> 버튼을 노출 시켜줘야 합니다.구현의 가장 간단한 방법은 플레이어에게 물어보는겁니다.<blockquote>지금이 혹시 10초와 30초 사이야?</blockquote><pre>onPlaybackPositionChanged = { position -&gt; intervalSkipButtonState.isInSkipInterval = playInfo.skippableIntervals.find { position in it.from until it.to } }</pre>위 코드는 <code>Player</code>의 <code>position</code>과 <code>playInfo</code>의 <code>skippableIntervals</code>에게 물어보고 있기 때문에 결합도가 생기는데요. 다른 객체에게 물어보지말고 스스로 찾게하면 어떨까요?<pre>onPlaybackPositionChanged = { position -&gt; intervalSkipButtonState.findSkippableInterval(position) }class IntervalSkipButtonState(private val playInfo : PlayInfo) { ... fun findSkippableInterval(position: Long): SkippableInterval? { return playInfo.skippableIntervals?.find { position in it.from until it.to } } }</pre>다음과 같이 <code>findSkippableInterval</code> 라는 메소드를 <code>IntervalSkipButtonState</code> 객체에서 선언해주고, <code>playInfo</code> 객체를 내부에 <code>private</code> 으로 가짐으로써, 캡슐화를 보장해줄 수 있게 되고, 플레이어와 <code>PlayInfo</code>의 결합도를 없앨 수 있습니다.<code>IntervalSkipButtonState</code> 라는 객체의 역할은 구간 건너뛰기 이벤트 관련한 상태값 관리이기 때문에 가능하다면 본인의 역할은 스스로 해결해야 합니다.<h2 id="812e">마치며</h2>객체지향 프로그래밍의 아키텍쳐를 설계하면서 가장 많이 고민했던 포인트는 이 객체가 어떤 역할과 책임을 가지고 무슨 객체들과 협력을 해야하는가? 였습니다.필요없는 도메인 객체와의 결합은 다른 클래스에서의 재사용을 불가능하게 만들고 이는 똑같은 기능을 가진 코드를 두 벌로 작성하게 되는 안타까운 상황을 만들게 됩니다. 테스트 코드 작성도 불가능하게 되니 결과적으로 서비스의 안정성에도 영향을 미친다고 볼 수 있겠습니다.끝으로 같이 플레이어 개편하느라 고생했던 Browsing1 스쿼드원들에게도 감사의 말씀을 올립니다.감사합니다.</div></div>

WATCHA - Medium

안녕하세요, 왓챠에서 안드로이드 개발을 하고 있는 doro입니다.
저는 Browsing 1 스쿼드에 속해있고, 왓챠에서 지원하는 대화면 기기에 대해 사용자들이 좀 더 좋은 UI/UX를 가질 수 있도록 고민하고 있습니다. 이번 스프린트에서는 기존 플레이어 화면의 UI/UX를 개편하고 프로젝트 구조 자체도 리팩토링을 하기로 계획했습니다.
기존 안드로이드 TV 플레이어 화면은 다양한 기능을 제공하지 못했고, UI면에서도 사용자들에게 불편한 점이 많았습니다.
그 뿐만이 아니라 프로젝트 구조도 레이어간 결합도가 높다거나 한 객체에 역할이 불확실하게 몰려있었는데요. 때문에 유지보수하는데 어려움이 많았고, 테스트 코드 작성에도 어려움이 있었습니다.
이번 포스팅에서는 이런 문제를 해결하기 위해 고려했던 개념들에 대해서 소개해보려고 합니다.
Object Oriented Programming
코틀린은 객체지향 언어입니다. 객체지향의 3대 요소는 캡슐화, 상속, 다형성입니다. 각 개념을 제공하기 위해 코틀린은 다양한 키워드를 지원하며 여러 가지 형태의 프로그래밍을 할 수 있습니다.
그렇다면 객체지향 언어가 추구하고 있는 가치는 무엇일까요? 저는 여러 객체가 역할과 책임을 나누어 서로 협력을 하는 패러다임을 만드는데 있다고 생각합니다.
한 객체의 역할을 명확히 정의하는 것은 불필요하게 결합도가 높아지는 것을 막을 수 있고, 응집도를 높혀 관리포인트를 줄일 수 있으며 단위 테스트 코드 작성도 용이하게 하는 등, 여러 가지 실질적인 장점을 가져올 수 있습니다.
이에 플레이어 화면을 구성하는 객체의 역할을 정의하는 작업부터 시작했습니다.
역할 분담하기
새로운 플레이어 화면에서 제공하는 기능들을 구현하기 위해서는 많은 상태값을 효율적으로 관리해야만 했습니다.
플레이어를 컨트롤할 수 있는 컨트롤러 UI
작품의 위치를 변경할 수 있는 썸네일 리스트
작품이 시작할 때 나오는 로딩화면
이외에도 심의등급 UI, 감상 종료 메뉴, 구간 건너뛰기 버튼 등 수 많은 위젯들의 상태값이 관리되어야 합니다. 이런 상태값들과 관련 비즈니스 로직은 ViewModel 에서 LiveData 나 다른 Model레이어들과의 결합으로 프로젝트 구성을 많이 했었는데요.
벌써 복잡합니다. 문제라고 한다면 플레이어 화면의 기능이 너무 많다는 것인데요. 위의 구조에서 ViewModel이 IntervalSkipButton 관련한 상태값만 3가지를 들고 있고 관련된 비즈니스 로직도 관리를 해야하는 문제가 생기게 되는 것이죠.
이는 하나의 객체에게 너무 많은 역할을 할당해서 생긴 문제입니다. ViewModel을 자세히 살펴보면 복잡하게 된 가장 큰 원인은 위젯들이 화면에 나타나는 상태값들입니다.
이런 플래그 값들을 관리해주는 객체에게 역할을 분담해준다면 어떨까요? ViewModel 에게 의존하지 않고 각 위젯들별로 상태값을 관리해준다면 객체들끼리 협력하는 패러다임을 만들 수 있습니다.
각각의 State 객체들은 visible 의 상태값을 가질수도, focused 의 상태값을 가질 수도 있으며 각 객체 독립적으로 해당 기능들의 역할을 수행하게끔 따로 비즈니스 로직도 구성할 수 있습니다.
이제 모든 case에 대해서 ViewModel 의 코드를 수정할 일이 없어지게 됩니다. 부가적으로 형상관리에도 매우 용이해지겠군요.
역할 검사하기
이제 나눠진 역할과 책임이 제대로 객체에게 할당되었는지 검사해야겠죠.
플레이어 화면에 진입하기 위해서는 이용권이 있어야하며, 심의등급이 18세 이상인 작품일 경우 성인인증을 완료한 유저여야 하는 등 몇 가지 유저의 상태를 확인해야하는 checkPlayable이라는 비즈니스 로직이 있습니다.
fun checkPlayable(
    playInfo: PlayInfo?,
): TvPlayUnavailableState.State {
    ...    
    val user = UserHolder.getUser()
}
이런식으로 UserHolder라는 싱글톤 객체와의 결합이 생기게 되는데요. 도메인 관점에서는 결합이 생기는것도 나쁘지 않다고 생각이 듭니다. 저 메소드에서의 유저는 항상 getUser() 일테니깐요.
하지만 싱글톤 객체를 참조하게 되면 checkPlayable 메소드에 대한 테스트 코드 작성이 어려워집니다.
fun checkPlayable(
   playInfo: PlayInfo?,
   user: User
) : TvPlayUnavailableState.State {
    ...
}
위와 같이 수정하여 User객체를 파리미터로 주입받는다면, User의 여러 상태를 checkPlayable 메소드에 주입을 해가면서 이용권이 없는 상태, 성인인증이 안되어있는 상태, 기기 등록수가 넘어있는 상태 등등 여러 가지 상태에 대한 Mock 데이터를 만들어 테스트 코드를 작성할 수 있습니다.
한 가지 더 알아볼까요.
플레이어 화면에서는 재생, 정지, 다음화 재생, 자막 변경 등 영상 상태와 정보를 제어할 수 있는 컨트롤러라는 UI를 제공하는데요. 이 컨트롤러의 상태를 PlayerControllerState라는 객체에서 관리합니다.
class PlayerControllerState(
    val playInfo: PlayInfo
) {
    val title = playInfo.simpleTitle.orEmpty()
    val description = playInfo.getTvPlayerDescription()
    val totalDuration = playInfo.duration.toLong()
    var isFocused by mutableStateOf(false)
    var isVisible by mutableStateOf(false)
    ...
}
위 코드의 문제는 무엇일까요? PlayerControllerState의 상태를 초기화해주며 playInfo라는 재생 정보를 주입받아 멤버변수를 초기화해주고 있습니다.
이 PlayerControllerState가 PlayInfo라는 도메인 클래스를 굳이 알아야 할 필요가 있을까요? 컨트롤러의 상태값은 title, description , totalDuration 만 넘겨받으면 초기화가 가능합니다. 가장 주목해야할 점은
PlayerControllerState와 PlayInfo가 공동의 역할을 가지고 있을까?
에 대한 질문입니다. 저는 PlayerControllerState 를 작품을 재생할 때, 제목과 설명을 보여주며 유저와의 재생 제어의 상호작용을 책임지는 객체라고 정의했기 때문에, 두 객체의 결합도가 필요 없다고 확정지을 수 있었습니다.
class PlayerControllerState(
    val title: String,
    val description: String,
    val totalDuration: Long
) {
    var isFocused by mutableStateOf(false)
    var visible by mutableStateOf(false)
    var isFocusedOnThumbnail by mutableStateOf(false)
    var remainingVisibleTime by mutableStateOf(CONTROLLER_VISIBLE_TIME)
    ...
}
위와 같이 수정해준다면 후에 PlayInfo 라는 객체가 수정된다고 한들 PlayerControllerState 는 아무런 영향 없이 필요한 데이터들만 주입받으면 되며, 멀티 모듈의 경우에는 module dependency 관점에서도 좀 더 자유로워 집니다.
역할은 스스로
객체들이 각자 역할 수행을 어떻게 하냐도 관점과 방법에 따라서 결합도를 줄일 수 있습니다.
왓챠는 작품을 재생할 때 오프닝 건너뛰기라는 기능을 제공합니다. 서버로부터 어느 구간이 오프닝 구간인지 정보를 내려 받는데요.
비슷한 UX로 작품의 감상이 완료되었을 때도 감상 종료 메뉴를 띄워줍니다.
서버로부터 받은 재생정보에 skippableIntervals 라는 필드가 있습니다. 이 필드는 from 과 to 라는 정보가 있고 from = 10, to = 30 이라면, 10초부터 30초 구간은 오프닝 건너뛰기(구간 건너뛰기) 버튼을 노출 시켜줘야 합니다.
구현의 가장 간단한 방법은 플레이어에게 물어보는겁니다.
지금이 혹시 10초와 30초 사이야?
onPlaybackPositionChanged = { position -> 
    intervalSkipButtonState.isInSkipInterval =       playInfo.skippableIntervals.find {
        position in it.from until it.to
    }
}
위 코드는 Player의 position과 playInfo의 skippableIntervals에게 물어보고 있기 때문에 결합도가 생기는데요. 다른 객체에게 물어보지말고 스스로 찾게하면 어떨까요?
onPlaybackPositionChanged = { position -> 
    intervalSkipButtonState.findSkippableInterval(position)
}
class IntervalSkipButtonState(private val playInfo : PlayInfo) {
    ...
    fun findSkippableInterval(position: Long): SkippableInterval? {
        return playInfo.skippableIntervals?.find {
            position in it.from until it.to
        }
    }
}
다음과 같이 findSkippableInterval 라는 메소드를 IntervalSkipButtonState 객체에서 선언해주고, playInfo 객체를 내부에 private 으로 가짐으로써, 캡슐화를 보장해줄 수 있게 되고, 플레이어와 PlayInfo의 결합도를 없앨 수 있습니다.
IntervalSkipButtonState 라는 객체의 역할은 구간 건너뛰기 이벤트 관련한 상태값 관리이기 때문에 가능하다면 본인의 역할은 스스로 해결해야 합니다.
마치며
객체지향 프로그래밍의 아키텍쳐를 설계하면서 가장 많이 고민했던 포인트는 이 객체가 어떤 역할과 책임을 가지고 무슨 객체들과 협력을 해야하는가? 였습니다.
필요없는 도메인 객체와의 결합은 다른 클래스에서의 재사용을 불가능하게 만들고 이는 똑같은 기능을 가진 코드를 두 벌로 작성하게 되는 안타까운 상황을 만들게 됩니다. 테스트 코드 작성도 불가능하게 되니 결과적으로 서비스의 안정성에도 영향을 미친다고 볼 수 있겠습니다.
끝으로 같이 플레이어 개편하느라 고생했던 Browsing1 스쿼드원들에게도 감사의 말씀을 올립니다.
감사합니다.
안드로이드 TV 플레이어, 책임과 협력으로 was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.

안드로이드 TV 플레이어, 책임과 협력으로

댓글