Talent

Super.init(version=6) 발표 후기

Thu, 27 Mar 2025 16:40:17 GMT

개요

"문휘님, Super.init이라고 주니어 컨퍼런스가 있어요. 발표 도전해보세요"

GDG에서 여는 DevFest에 우연히 갔다가, 우연히 운영진 회식 자리에 참석하게 되고, 또 우연히 네이버 부스트캠프 멘토님을 만나 들었던 이야기이다. (운명인가)

네이버 부스트캠프에서 발표를 여러번 하고 난 후 발표에 대해 자신감이 붙고 있었는데, 저 이야기를 들으니 하고싶은 마음이 들었다.

"부스트 캠프에서 컨퍼런스로 확장할 수 있는 기회다."

다른 개발자의 앞에 나서서 공유할 수 있는 기회는 많지 않다. 그래서 네이버 부스트캠프에서도 열심히 발표를 했었는데, 이 것을 더 확장할 수 있는 기회였다.

이후 연사자 모집 공고가 떴을 때, 내 프로젝트에 발표 내용이 있는지 뒤지기 시작했다.

준비

사람들에게 도움이 될 만한, 뻔하지 않은 주제를 발표하자.

내가 갔었던 안드로이드 컨퍼런스에는 Modularization, Clean Architecture의 발표가 항상 있었던 것 같다. 아주 좋은 주제이기도 하고 각자 조금씩은 다른 생각을 가지고 있는거 같아서 매번 흥미롭게 들었다.

이전에 부스트 캠프 내부에서 모듈화와 아키텍쳐 관련 발표를 했기 때문에 이것을 좀 더 고쳐서 발표하려했지만, 난 아직 주니어이기 때문에 구조와 같이 중요하고 되돌리기 힘든 것을 잘못 알렸다간 민폐가 될 것 같았다.

결국 이것을 엎고 다른 주제로 발표하게 되었는데, 바로바로

이것을 발표하게 된 계기가 있었는데,

게임 제작 경험을 Android에도 적용할 수 있었다.

Unity로 게임 제작을 할 때, 수학으로 별의 별것을 다 직접 구현해야 한다.

게임은 일반적으로 정해진 UI나 가이드가 없고, 각자의 요구사항이 천차만별이다. 무슨 UI 요구사항이 있을지 알 수 없기 때문에 어떤 것이든 구현할 수 있도록 준비해야 한다.

그 중에 중요한 것은 수학이다. 캐릭터의 이동, 물리적인 충돌 등 게임에 필요한 요구사항들은 대부분 움직임에 초점이 맞춰져 있는데, 이 때 여러 수학 계산이 들어간다.

난 Android도 다르지 않다고 생각한다. 권장 가이드라인이 있지만, 항상 따를 수 없고 벗어난 UI가 있을 수 있다.

그리고 그런 요구사항이 왔을 때, "싫어요. 바꿔주세요." 보다는 구현할 수 있는 사람이 되고 싶었다.

그래서 여러 요구사항들을 게임 만들듯이 해결하곤 했는데, 이런 경험을 공유하면 재미있을 것 같다고 생각했다.

"특이하지만 유용한 내용이었으면 좋겠다."

많이 나오는 주제의 발표는 나보다 더욱 잘하는 사람이 있을 것이기에, 내가 해본 경험중에서 가장 특이하고 유용한 "수학으로 UI 요구사항 만족시키기" 주제로 발표를 하였다.

발표

장소는 우아한 테크살롱에서 진행되었다.

이전에 GDG DevFesta에 참여한 적이 있어 익숙한 장소였다. (여기서 발표를 듣기만 했는데 내가 할 줄이야...)

내가 발표할 때는 워크샵 때문에 사람들이 빠져나갔지만, 그럼에도 굉장히 많은 인원이 남아계셔서 긴장했었다.

나의 주제가 수학이라, 반응이 별로 안좋았던 부분들이 있었다... ㅎㅎ

그 중에 표정이 안좋았던 파트는 역시 제 2코사인 법칙과 외적부분이 아니었을까...? ㅎㅎ

"여러 발표를 들었지만, 이런 발표는 처음인 것 같아요"

옆에서 진행해주시는 오거나이저분이 말씀해주셨던 말이다. 특이하고 유용한 발표를 하는게 목표였던 만큼, 가장 뿌듯했던 말이었다!

느낀점

가장 좋았던 것은 역시 여러 개발자들과 만남을 가지는 것이었다.

발표가 모두 끝나고 나서 소통 시간을 가졌는데, 처음 만나는 개발자분들과 각자의 회사 사정 이야기도 들을 수 있었고, 여러 개발 방식, 요즘 트렌드도 들을 수 있었다.

개발 대화만 해도 즐거운데, 유용한 트렌드도 잘 알 수 있으니 역시 커뮤니케이션을 하는 것이 개발자로서 가장 빨리 성장하는 방법이라는 것을 다시 한번 느낄 수 있는 시간이었다.

"이후에도 계속 발표를 해보자"

이번에는 운좋게 제안해주셔서 했지만, 다음에는 하지 않으려고 했었다. 나는 내가 작성한 코드도, 내가 공부했던 내용들도 모두 불신하는 사람이기 때문이다...

아직 주니어이기도 하고, 공부할 것도 많은데 사람들 앞에서 잘못된 내용을 발표할까봐 두려움이 앞서기도 한다.

그러나 생각을 좀 고쳐먹었다.

"틀린 내용도 사람들에게 공개해야 틀리다는 것을 알 수 있다." "공개의 두려움보단 발전을 위하는 마음으로"

회사라는 작은 공간에서도 누군가에게 내가 코드를 작성한 이유, 기술을 사용한 이유를 공유하지 않으면 틀렸는지 맞았는지 알 수 없다.

그래서 코드 리뷰도 하고, 같이 회의도 하면서 안정적으로 서비스를 만들어나가는 것이다.

이것을 조금 확장한다 생각한다면, 결국 발표도 나의 코드를 리뷰받을 수 있는 환경이 되는 것이다.

이제 계속 좋은 내용을 발표하는 개발자가 되어야겠다!

Kotlin - Flow Back Pressure

Thu, 20 Feb 2025 17:53:04 GMT

개요

A: "Flow에서 back pressure현상이 일어났을 때 어떻게 처리해야하나요?" 나: "...그게 뭐에요...?"

어디선가 이런 질문을 받았는데, back pressure라는 키워드를 들어 본 적도 없어서 대답하지 못했다.

질문 해주셨던 분이 대략적으로 설명을 해 주셔서 그나마 나의 생각을 말했는데...

긴장해서 잘 기억은 안나지만, "SharedFlow에 버퍼 있으니 버퍼를 이용해서 오래된 것들을 버리면 되지 않을까요...?"라는 애매한 대답을 한 것 같다. ~~(근데 또 대충 맞았던 것도 신기하다.)~~

Back Pressure에 대한 트러블 경험이 없어서 오히려 아무 생각 없이 개발했다는 생각이 든다.

이번 글에서는 데이터의 발행 속도가 소비 속도보다 빠를 때 생기는 문제인 Back Pressure에 대해 알아보자!

Back Pressure

Back Pressure는 데이터의 소비 속도가 공급 속도보다 느릴 때 일어나는 현상이다. 데이터가 소비되지 않고 계속 뒤에서 쌓이게 되면 데이터가 처리되지 않아 OutOfMemory가 일어날 수 있다.

아래의 예시 코드를 보자.

val backPressureFlow = flow {
    while(true) {
        delay(100L) // 100ms 간격으로 방출
        emit("emit data")
    }
}

launch {
    backPressureFlow.collect {
        delay(1000L)// 1000ms 간격으로 소비
        println(it)
    }
}

데이터의 발행

먼저 데이터의 발행을 담당하는 backPressureFlow는 100ms 주기로 무한히 String데이터를 발행하고 있다.

Android App으로 예시로 들자면 앱을 켜놓는 동안에 주기적으로 데이터를 방출하거나 갱신시키는 정도로 생각할 수 있다.

이는 평소에도 잘 일어날 수 있는 시나리오인 "앱 오래 켜두기"로 볼 수 있다.

데이터의 소비

데이터를 소비하는 쪽은 collect로 소비를 하고 있다.

그리고 소비의 주기는 1000ms간격이다. 1초에 한 번씩 처리를 하고 있는 셈이다. 이는 데이터의 발행보다 10배는 느린 상황이다.

Android App을 예시로 보자면, 데이터를 통해 화면을 그리는 행위에 해당할 수 있다. 보통 데이터를 생성해 발행하는 것 보다 데이터로 화면을 그리는 행위가 더 오래걸릴 것으로 예상한다.

문제점

문제점은 데이터의 발행보다 데이터의 소비가 10배는 느리다는 것이다.

데이터를 발행하는 쪽에서는 0.1초 마다 데이터를 발행하지만, 소비하는 쪽은 1초에 하나씩 소비하기 때문에 1초 간격으로 9개의 데이터가 쌓이게 된다.

이런 상황에서 앱을 오래 켜두게 되면 1초에 9개씩 계속 데이터가 쌓이게 때문에 언젠가 OOM(OutOfMemory) Exception으로 앱이 비정상 종료될 수 있다.

해결 방법

이 문제의 해결 방법은 매우 가까이에 있었다. 그리고 다들 한번씩은 사용해보았을 것이다.

여기서 키워드는 다량의 데이터를 잘못 소비하면 OOM이 발생한다는 점인데, 이와 똑같은 문제를 해결하기 위해 사용하는 방법이 있다. 바로 파일을 읽어올 때 쓰는 방식이다.

파일 읽기?

파일을 읽어올 때, 한번에 읽어올 수 있다. 아래처럼 readText()를 사용하면 파일의 텍스트를 한번에 읽어오게 된다.

fun main() {
    val file = File("file/path")
    println(file.readText())
}

하지만 이는 파일의 크기가 작을 때만 가능하다. 만약 한번에 읽어올 파일의 크기가 크다면 메모리 영역을 가득 채울 것이고, OOM을 발생시켜 프로세스가 종료될 것이다.

파일의 크기가 얼마나 될 지는 보통 알 수 없기 때문에 한번에 불러오지 않고, Buffer를 두어 그 크기 만큼 나눠 읽는 경우가 일반적이다.

fun main() {
    val file = File("file/path")
    file.bufferedReader().use { reader ->
        reader.forEachLine {
            println(it)
        }
    }
}

만약 읽어올 단위를 정하고 싶다면 buffueredReader()에 값을 정하면 된다.

fun main() {
    val file = File("file/path")
    file.bufferedReader(bufferSize = 512).use { reader ->
        reader.forEachLine {
            println(it)
        }
    }
}

위의 방식에 buffer를 넘는 데이터에 대해 처리하는 적절한 정책까지 정해진다면, Flow에도 적용시킬 수 있을 것이다!

Buffer를 통한 Back Pressure 해결

Flow에도 buffer()라는 Extension이 존재한다. 그래서 얼마만큼의 데이터만을 다룰 것인지 결정할 수 있다.

val backPressureFlow = flow {
    while (true) { //매우 많은 양의 데이터 방출
        delay(100L) // 100ms 간격으로 방출
        emit("emit data")
    }
}

//...중략

launch {
    backPressureFlow.buffer(capacity = 100).collect { //최대 100개만 처리하자.
        delay(1000L)// 1000ms 간격으로 소비
        println(it)
    }
}

backPressureFlow에 buffer라는 Extension을 달아주고, capacity를 100으로 설정하였다.

이렇게 하면 버퍼 값인 100개 만큼의 데이터만 다루게 된다.

만약 버퍼 값이 가득 찬 상태에서 데이터가 발행되면 어떻게 될까?

이럴 때 사용할 수 있는 정책이 3가지가 있는데, 코드를 직접 살펴보면 아래와 같다.

SUSPEND: buffer의 값이 가득 찬 상태에서 새로운 값이 들어올 경우, 발행을 잠시 중단(SUSPEND)한다.
DROP_OLDEST: buffer의 값이 가득 찬 상태에서 새로운 값이 들어올 경우, 가장 오래된 값을 버리고, 새로운 값을 buffer에 저장한다.
DROP_LATEST: buffer의 값이 가득 찬 상태에서 새로운 값이 들어올 경우, 가장 최신 값을 버리고, 새로운 값을 buffer에 저장한다.

위 세 개가 buffer가 가득찼을 경우 설정할 수 있는 정책이다.

만약 최신 값을 반영하고 싶다면 DROP_OLDEST를 아래와 같이 설정하면 된다...!!

val backPressureFlow = flow {
    while (true) { //매우 많은 양의 데이터 방출
        delay(100L) // 100ms 간격으로 방출
        emit("emit data")
    }
}

//...중략

launch {
//오래된 값 버리기
    backPressureFlow.buffer(capacity = 100, onBufferOverflow = BufferOverflow.DROP_OLDEST) 
        .collect {
            delay(1000L)// 1000ms 간격으로 소비
            println(it)
        }
}

어디서 많이 보지 않았나...?

그렇다. SharedFlow에서도 위와 같이 버퍼와 버퍼를 비우는 정책을 설정할 수 있다...!

val sharedFlow = MutableSharedFlow(extraBufferCapacity = 100, onBufferOverflow = BufferOverflow.DROP_OLDEST)

~~(내가 완전히 틀린 대답을 한 것이 아니었다.)~~

이렇게 버퍼를 두고 값을 버리거나 발행을 중지하면서 Back Pressure를 예방할 수 있다.

collectLatest를 통한 Back Pressure 해결

collect는 값을 소비하고 lambda 안에 있는 코드를 반드시 실행시킨다. 이는 실행하는 코드가 매우 느릴 경우(앞선 코드의 delay) Back Pressure를 발생시키는 원인이 된다.

collectLatest는 새로운 값이 발행되었을 때, 이전 작업을 취소시키고 현재 방출된 값으로 다시 코드를 실행시킨다.

val backPressureFlow = flow {
    while (true) { //매우 많은 양의 데이터 방출
        delay(100L) // 100ms 간격으로 방출
        emit("emit data")
    }
}

//...중략

launch {
    backPressureFlow.collectLatest { //새로운 값이 들어오면 이전 작업을 취소시킨다.
        delay(1000L)// 1000ms 간격으로 소비
        println(it)
    }
}

매우 간단하게 Back Pressure를 해결할 수 있다!

collectLatest VS collect + buffer

Back Pressure를 해결하는 두 가지 방법을 보았는데 두 코드를 비교해 보면 collectLatest가 가장 간단하게 보인다. 이것만 쓰면 될까?

상황에 따라 다르다고 할 수 있다.

collectLatest는 이전 작업을 취소시키기 때문에 곤란한 경우가 있을 수 있다.

"데이터가 들어온 이상 무조건 실행"해야 하고 Back Pressure를 예방하려면 buffer 방법을, "취소되어도 괜찮은 코드"라면 collectLatest가 좋은 것 같다.

데이터가 들어올 경우 무조건 실행: buffer
취소되어도 괜찮은 실행: collectLatest

의문점: collectLatest는 그럼 Hot Flow처럼 동작하나?

답은 X 이다.

이전 작업은 취소시키고 "항상 최신 값만 반영"한다는 특성때문에 자칫 오해하기 쉽지만, collectLatest를 쓴다고 Hot Flow가 되는 것은 아니다. (하지만 매우 유사해지긴 한다.)

Cold Flow에서 collectLatest를 사용하는 것과 Hot Flow에서 collectLatest를 사용하는 것의 차이점들을 정리해 보면 아래와 같다.

새로운 구독자가 생겼을 때 Cold Flow는 첫 번째 값 부터 취소되어가며 처리, Hot Flow는 최신 값만 처리한다.
구독자가 없다면 Cold Flow는 값을 방출하지 않기 때문에 어차피 취소될 데이터가 쌓이지만, Hot Flow는 최신 값만 유지하기 때문에 취소될 데이터가 없다.

마치며

Android에서는 UI 업데이트에 collectLatest를 사용할 것을 권장하고 있다.

UI를 업데이트 할 때에 성능을 위해 이전 값을 취소시키는 collectLatest가 적절한 것 같다.

하지만 꼭 실행시켜야 하는 UI 업데이트 작업이 있거나, 무한히 방출되는 값에 의해 계속 취소되는 상황이라면 collect와 buffer, conflate와 같이 쓰는 방법으로collectLatest를 대체할 수 있을 것이다.

이제 두 가지를 잘 알았으니 적절한 곳에 사용해보아야 겠다!

CS 다시 공부하기 - CS는 왜 필요할까?

Tue, 11 Feb 2025 09:10:47 GMT

개요

"진짜 CS 마스터 해야지..." "아 다음엔 진짜 날 잡아서 CS 공부 빡세게 한다..."

매번 이렇게 다짐하지만 막상 CS 공부하는게 쉽지 않다.

안드로이드 개발 공부할 것도 너무 많은데... (가입해야 하나...)

CS가 실제 개발에서 중요할까?

난 안드로이드 개발하면서 알고리즘, OS는 조금 필요하다는 것을 느낀다.

RecyclerView에 표현할 리스트를 다룰 때는 삽입 정렬, 해쉬를 고려하는 경우가 많고,

아주 가끔 "앱이 언제 꺼질까?"를 생각할 때, OS 책에서 배운 프로세스와 메모리 구조를 떠올리긴 한다.

하지만..

이 상황 외에는 CS지식이 필요한 적은 없었던 것 같다.

특히 공룡책과 같은 수많은 페이지의 전공 서적을 볼 때면, "이정도 까지 필요하나?"라는 생각이 많이 든다.

또 안드로이드에선 네트워크 지식이 필요한 경우가 거의 없어 매번 했갈리고 까먹고는 한다.

그럼에도 많은 기업들은 CS 지식을 물어보곤 한다.

사실 나도 CS를 공부하고 나서 까먹을 뿐이지, 다시 공부하다 보면 내가 작성한 코드들에는 CS지식이 기반이 되는 것들이 많다는 것을 느낀다.

그 만큼 작은 부분 곳곳에 CS지식이 들어가곤 한다.

그래서 이번 기회에 다시 한번 왜 우리는 CS를 공부해야 하는가에 대해 알아보자!!

"기초가 탄탄해진다." "최적화할 수 있다."
이런 뻔한 것들 말고, 나의 경험을 토대로!

짧고 효율적인 코드를 작성할 수 있다.

가게에 재료가 없거나, 가게 자리가 없거나, 영업일이 아니라면 "예약 불가합니다."를, 그 반대라면 "예약 시도중..."라는 문구를 띄워 주세요.

위의 요구사항을 구현하려 한다.

가장 먼저 떠오르는 것은 위의 말을 그대로 코드로 옮겨 적는 것이다. 가장 빠르고 쉽게 떠올릴 수 있는 방법이다.

if(!isStoreOpen && !isIngredientExist && !isTableExist) {
    println("예약이 불가능합니다.")
}else{
    println("예약 시도중...")
}

위의 코드는 문제가 없지만 단점이 있는데, !(NOT)이 3번이나 들어가 읽기 불편하다는 것이다.

!(NOT)은 정말 좋은 도구이지만, 변수의 앞에 적어야 한다. 그렇기 때문에 변수를 읽고 눈을 다시 앞으로 되돌려야 한다. ~~(NOT이 한국식으로 뒤에 왔다면 더 읽기 편했을 것이다.)~~

읽는 과정을 보자면 아래와 같다.

isStoreOpen의 의미를 이해한다. -> !(NOT)이 앞에 있으니 다시 앞으로 눈길을 옮긴다. -> isStoreOpen을 반대로 이해한다. -> 다음 변수를 읽기 위해 isStoreOpen을 뛰어 넘어 다음 변수를 읽는다.

코드의 조건을 이해하려면 위의 과정을 3번 반복한 후, AND까지 시켜야 한다. 이는 컴퓨터도 마찬가지(NOT 연산을 3번 함)여서 성능에 조금 영향을 미친다.

CS를 공부했다면 이를 해소시킬 수 있는 방법들이 몇 가지 있다.

드모르간 법칙 이용하기

드모르간의 법칙을 이용하면 !(NOT)을 한 개로 줄일 수 있다.

//드모르간의 법칙으로 바꾸기!
if (!(isStoreOpen || isIngredientExist || isTableExist)) {
    println("예약이 불가능합니다.")
} else {
    println("예약 시도중...")
}

공통으로 들어가는 !(NOT)을 앞으로 뺀 후, 괄호로 묶고 모든 AND를 OR로 바꾸면 된다.

!(NOT)이 3개에서 하나로 줄었기 때문에 읽는 과정이 줄어들고 더욱 빠르게 조건을 파악할 수 있을 것이다.

else의 원리를 이용하기

내가 가장 애용하는 방식이다.

else는 기본적으로 !(NOT)의 의미를 내포하고 있다.

그렇기 때문에 중괄호 안의 코드 순서를 바꾼 후, NOT을 추가하거나 빼는 방법으로 코드를 더욱 이해하기 쉽게 바꿀 수 있다.

위의 드모르간의 법칙을 사용한 코드에서 더욱 줄일 수 있게 되는 것이다!

if(isStoreOpen || isIngredientExist || isTableExist){
    println("예약 시도중...")
} else{
    println("예약이 불가능합니다.")
}

~~(예시 조건이 좀 이상하지만 넘어가자...)~~

if, else의 중괄호에 넣는 결과 코드를 뒤집으면 NOT을 하나 더 줄일 수 있다. 처음 코드와 비교하면 읽기 너무너무 편리해 졌다.

객체지향을 이용하기

만약 다른 곳에서 계산을 끝마쳤는데, 다시 구분해서 출력을 해야 하는 상황이 있을 수 있다. 아래와 같이 이미 계산을 끝마친 후, 다른 곳에서 사용한다고 가정해 보자.

fun canReserve(): Boolean {
    if (isStoreOpen || isIngredientExist || isTableExist) {
        return true
    } else {
        return false
    }
}

fun printMessage() {
    if (canReserve()) {
        println("예약이 불가능합니다.")
    } else {
        println("예약 시도중...")
    }
}

이렇게 되면 또 한번 canReserve의 결과 값을 if에 넣어 판단해야 한다.

하지만 하나의 객체를 선언한 후, 상속받는 여러 구현체를 이용한다면 불필요한 if를 줄일 수 있다.

객체 선언

interface PrintReserveUseCase{
    fun print()
}

class CanReserveUseCase:PrintReserveUseCase{
    override fun print() {
        println("예약 시도중...")
    }
}

class CanNotReserveUseCase:PrintReserveUseCase{
    override fun print() {
        println("예약이 불가능합니다.")
    }
}

객체 사용

fun canReserve(): PrintReserveUseCase {
    if (isStoreOpen || isIngredientExist || isTableExist) {
        return CanReserveUseCase()
    } else {
        return CanNotReserveUseCase()
    }
}

fun printMessage() {
    canReserve().print()
}

if를 사용하지 않고 추상화된 객체를 이용, print 함수를 호출하게 되어 더욱 편리한 코드가 될 수 있다.

이렇게 객체지향의 원리를 이용한 코드를 작성하면 추후에 여러 조건들이 추가되었을 때 더욱 빛을 발할 것이다.

극한의 성능 추구하기

만약 극한으로 성능을 생각해야 하는 로봇, 임베디드 분야라면 비트 마스크를 통해 코드의 양을 줄이고 성능을 올릴 수 있다.

주의할 점은 "프로그래머 끼리 약속"되어있어야 한다는 점이다.

1의 자리 수는 조건 A, 2의 자리 수는 조건 B, 4의 자리 수는 조건 C를 나타낸다.

위의 가정대로 프로그래머 끼리 약속했다면, 동시에 만족하는 수를 빠르게 찾을 수 있다.

a, c만 만족하는 경우를 찾는다.: (maskValue and 0b101)!=0
b, c만 만족하는 경우를 찾는다.: (maskValue and 0b110)!=0
a, b만 만족하는 경우를 찾는다.: (maskValue and 0b011)!=0

"월, 수, 금 중에 한 요일이라도 영업하는 가게를 필터링해서 보여주세요"

실제 내가 앱을 개발하면서 받았던 요구사항인데, 비트마스크를 통해 해결한 경험이 있다.

먼저 월화수목금토일을 자리수에 맞게 비트로 변환한다.

예시를 몇가지 두자면 아래처럼 요일이 비트로 바뀌게 된다.

"월수금" -> 1010100
"화수목일" -> 0111001
"월화목금토" -> 1101110

이제 원래 조건인 월수금을 비트로 바꾼 후 논리곱 AND를 하면 조건에 맞는 가게를 쉽게 찾을 수 있다.

data class Store(
    //...생략
    val dayOfWeekMask: Int
    //...생략
)

fun filterStore(storeList: List) {
    //월, 수, 금 비트 마스크
    val condition = 0b1010100

    //월, 수, 금 중에 하나라도 없으면 제거
    storeList.filterNot { (it.dayOfWeekMask and condition) == 0 }
}

이렇게 하면 여러 조건 중에 동시에 만족할 수 있는 조건들을 빠르게 찾을 수 있다.

이를 이용하여, 위의 가게 예시를 구현한다면 아래와 같이 할 수 있을 것이다.

//condition이 가게 상태의 비트마스크라면...
if (condition != 0) {
    println("예약 시도중...")
} else {
    println("예약이 불가능합니다.")
}

약속이 미리 되어있기 때문에, 코드를 파악하는데 문제가 되지 않고 더욱 짧아졌다.

또한 단 한번의 비교연산으로 조건을 탐색할 수 있다.

이처럼 CS는 코드의 성능을 높이고, 간결하고 읽기 쉽게 만들어준다.

새로운 기술을 판단할 수 있게 된다.

예전 네이버 신입 공채에서는 "트렌드에 휘말리지 않는 탄탄한 기본기"가 중요하다고 말했다.

트랜드, 정말 많이 바뀐다.

Android의 Jetpack Compose, iOS의 Swift UI처럼 명령형 UI에서 선언형 UI로 많이 바뀌고 있고, 이에 따라 MVVM에서 MVI를 고려해야 하는 경우도 생긴다.

더 큰 FrameWork 관점에서는 Flutter, ReactNative의 파이가 점점 커져 "다시 공부해야 하나"하는 마음도 든다.

개발자들도 이런데, 개발자가 아닌 사람들이 개발자를 구할 때는 더욱 곤란할 것이다.

"앱을 만들어 사업하려고 해요. 어떤 개발자를 구해서 앱을 만들어야 할까요?"

지인 중에 사업을 하고 계신 분이 있는데, 이런 질문을 받은 적이 있다.

어떻게 대답해야 할까 잠시 고민을 하다가 대답했다.

"어떤 앱을 만드시는데요? 비용은 얼마나 가지고 있죠?"

앱을 만드는 방법은 Android, iOS 네이티브 이외에도 생각보다 많다.

비용과 개발 속도를 생각한다면 Flutter, ReactNative도 아주 좋은 선택지가 될 수 있고, 심지어 Unity, Unreal로 게임 뿐 아니라 네이티브 못지 않은 상용 앱을 만들 수 있다. (크로스 플랫폼 처럼 하나의 코드로 Android, iOS 둘다 빌드 까지 가능하다.)

또한 Kotlin MultiPlatform으로도 만들 수 있으며 이미 지원 종료되었지만 저 질문을 받았을 때는 Xamarin으로도 앱을 만들 수 있었다.

이렇게 수많은 프레임워크 중에서 좋은 대답을 하려면 각각의 플랫폼을 사용해본 경험과 장, 단점을 알아야 한다. 이런 경험과 장단점을 자세히, 모두 알고 있는 개발자는 얼마나 될까... ~~(하나 공부하기도 벅차다)~~

하지만 모두 경험 하지 않아도, 판단할 수 있는 방법이 있다.

공통점. CS 지식이다.

위 플랫폼들의 공통점은 사용자에게 보여주는 그래픽이 있다는 것이다.

그럼 판단할 수 있는 기준이 한 가지 생기게 되는데, 어떤 그래픽을 사용자에게 보여 줘서 서비스를 사용하게 만들지를 들으면 된다.

"3D로 보여줘야 하는 앱이에요."

3D 그래픽을 사용하는 앱이라면 Unity, Unreal을 추천하겠다.

Android, Flutter에서 사용하는 Skia Engine은 기본적으로 2D 그래픽 엔진이어서 3D를 구현하기 쉽지 않다.

Unity, Unreal은 3D로 개발하기 쉽고, 빌드 설정에서 OpenGL, DirectX로 설정하여 플랫폼에 최적화된 그래픽 라이브러리를 직접 설정할 수 있다. 또 설정을 통해 똑같은 코드로 Android, iOS로 빌드 가능해서 여러 플랫폼을 지원하기 쉽다.

"2D인데 화려한 애니메이션이 들어가요."

이렇다면 두 가지중에 선택해서 말할 것 같다.

물리적인 계산이 들어가는 엔터테인먼트가 있다면 Unreal, Unity를 추천한다. 3D 뿐만 아니라 2D도 쉽게 지원할 수 있고, 물리 계산이 편하다.
물리적인 계산이 없고, 상용앱이라면 Flutter, KMP를 추천한다. 플랫폼에 매칭되는 UI Component로 변환시키는 ReactNative에 반해 Flutter는 Skia Engine, KMP는 각각의 그래픽 엔진을 사용하여 픽셀을 직접 그리기 때문에 성능이 좋다.

"상용 앱인데 화려한 애니메이션은 없고, 숙련된 개발자를 구하고 싶어요."

그럼 ReactNative를 추천하겠다.

JavaScript의 개발자 풀은 굉장히 많고, 또 뛰어난 개발자들이 많다. 그리고 ReactNative로 빠르게 좋은 앱을 만들 수 있다. 이는 개발비용 측에서 좋은 효율을 보여줄 것이다.

"상용 앱인데, 화려한 애니메이션이 들어가요."

그럼 Flutter를 추천한다.

Skia Engine으로 픽셀 하나하나 직접 그리기 때문에 화려한 애니메이션을 성능 좋게 구현할 수 있다.

"네이티브 기술을 사용하는 앱을 만들어야 해요"

Android, iOS 개발자를 추천하면 된다.

위 처럼 기본적인 CS지식이 바탕이 된다면 여러 기술을 판단할 수 있게 된다.

개발자에게는 어떻게 도움이 될까?

요즘 공고를 보면, Flutter, React Native 개발자를 찾는 공고를 많이 볼 수 있다.

그만큼 멀티플랫폼 는 굉장히 많은 발전을 하고 있으며 사용중인 개발자들, 그리고 예시 코드들이 많이 늘어나고 있다.

만약 시간이 지난 후.. 갑자기 구글에서 이렇게 발표를 한다면...?

"Android의 모든 기능은 이제 Flutter로 구현할 수 있게 되었습니다. 따라서 Android는 이제 지원하지 않겠습니다."

난 노숙자가 되지 않으려면, 어떤 개발자로 전향해야 할 지 판단해야 할 것이다...

이 때 CS 지식이 어느 프레임워크를 새로 공부할 지 기준점이 될 수 있다.

일례로 iOS는 13 버전부터 OpenGL이 아닌 자체 그래픽 라이브러리 Metal을 사용하여 화면을 그리게 되었다. (Android에는 Vulkan이라는 친구가 생겼다.)
Flutter를 개발하는 개발자들은 OpenGL로 된 하나의 코드를 이용해서 여러 플랫폼을 지원하고 있었는데, iOS만 Metal로 개발해야 하는 상황이 온것이다.
이는 Google이 Flutter를 개발하는데 비용이 증가했다는 것으로 연결되며, Flutter나 ReactNative나 개발 유지비용이 똑같아(혹은 Flutter가 더 많아짐) 조금 불안해졌다는 것이다.
~~(Google은 끄떡 없지만 혹...시 모르니까...)~~

물론 프레임워크를 바꿔야 하는 상황은 잘 일어나지 않는다.

하지만 이보다 작은 단위인 라이브러리, API를 바꾸는 상황은 평소에도 자주 일어난다.

극단적인 상황이 아니더라도, 잘 사용했던 라이브러리가 Deprecated 되는 일은 많이 경험해 보았을 것이다.

기존에 잘 사용했던 라이브러리가 치명적인 결함으로 갑자기 Deprecated 되었다면 새로운 라이브러리를 찾아야 한다. ~~(안 그러면 서비스가 망한다)~~

이 때는 여러 검증되지 않은 라이브러리가 있어서 다른 개발자들도 뭘 사용해야 할 지 모르는 상황이 올 것이다.

이 때 CS 지식이 라이브러리를 선택하는데 도움을 줄 수 있다.

여러 조건을 토대로 서칭해야 하는 라이브러리를 새로 찾아야 한다면 조건을 하나하나 비교하여 서칭하는 라이브러리와 비트마스크를 AND시켜 서칭하는 라이브러리의 성능은 다를 것이며, 이를 판단하기 위해서는 알고리즘을 열심히 공부해야 할 것이다.

어떤 기술이 어떤 장단점을 가지고 있는 지 판단하는 근거는 CS 지식에서 나온다.

회사에서 원한다.

현실적인 이유인데, 회사에서 다른 개발자가 되길 원하는 경우가 꽤 많은 것 같다.

"원래 안드로이드 개발자가 아니었는데, 회사에서 원해서 안드로이드 개발자가 되었어요."

GDG DevFest 안드로이드 개발자 컨퍼런스에서 20년차가 넘은 개발자분께 들었던 이야기이다.

원래는 C/C++ 개발자였는데, 회사에서 앱을 만들기를 원해 전향하게 되었고, 처음에는 당황스럽고 부담스러웠는데 지금은 만족한다고 하셨다.

또 내가 자주 보는 개발자 유튜버는 iOS 개발자로 취업했다가 백엔드 개발자가 되었다고 한다.

나 또한 회사에서 이런 이야기를 들은 적이 있다.

"문휘님, 혹시 플러터 가능하세요? 저희 한번 플러터 해볼까요?"

처음에는 달갑지 않았다. 안드로이드 개발자인데 커리어가 꼬이게 되지 않을까 걱정도 많이 했었다.

하지만 회사에서 하라면 해야지... 수 개월동안 플러터를 개발했는데...

"Flutter는 신이야"

너무 재밌었다.

처음에는 어색했던 선언형 UI도 생산성에서 놀랐고, Web, iOS, Android, 심지어는 데스크톱 앱까지 한 코드로 빌드되는 것에 신기함을 느꼈다.

또 Web에서는 기본인 반응형 UI로 앱을 개발하면 UI가 깨지지 않고 모든 환경에서 일관된 UI를 보여주었다.

그리고 언젠가는 내가 Android 개발자가 아닌 Flutter 개발자가 될 지도 모르겠다는 생각이 들었다.

Flutter에서도 CS는 중요했다.

Flutter를 개발할 때 화면이 바뀌지 않는 문제가 있었는데, 이는 Widget의 Key가 바뀌지 않을 때 일어난다고 하였다.

그래서 Key를 데이터에 따라 수동으로 바꾸는 코드를 작성하면서, Flutter가 화면을 그리는 방식을 공부했다.

"Flutter는 화면을 그릴 때 Widget Tree를 DFS로 순회하며 Widget의 Key가 바뀐 것만 다시 그립니다."

DFS는 깊이 우선 탐색이다. 그렇기 때문에 자신의 형제 노드를 먼저 탐색하는 것이 아닌 자신의 자식 노드를 먼저 탐색한다.

Flutter 뿐만 아니라 Android에서도 DFS를 사용하는데, 그 이유는 부모의 크기가 정해 진 후, 그 크기 안에서 자식의 크기를 정해야 하기 때문이다.

BFS를 통해 A Widget보다 B Widget이 먼저 검사되어 크기가 정해졌다면, C Widget의 크기를 정할 때 다시 A Widget의 크기를 가져오는 등, 불편한 부분이 있을 것이다.

DFS는 이런 과정이 자식부터 되기 때문에 크기 계산이 자연스럽다.

또한 DFS 순서로 그리게 되면 먼저 그려진 A, C Widget이 나중에 그려지는 B Widget에 의해 자연스럽게 가려지게 된다.

내가 만약 CS 알고리즘을 공부하지 않았다면 위의 말을 이해하지 못했을 것이다.

조금 딴길로 샜는데, 회사는 다른 기술로 개발할 때 또 새로운 직원을 뽑는 것 보다 기존 직원을 활용해서 서비스를 만들고 싶어한다. 그리고 CS가 탄탄하면 기술 스택 전환이 빠르다.
-> 회사는 기본기가 탄탄한 개발자를 원한다!

회사는 새로운 직원을 뽑는 것 보다 기존 직원의 연봉을 높여 다른 기술을 개발하는 것이 시간적 측면에서도, 비용적 측면에서도 효율적이다.

연차가 높은 개발자분들의 생생한 전환 경험담을 들은 만큼, 나도 CS공부로 탄탄히 준비해놓아야 한다.

마치며...

글을 쓰다 보니 너무 알고리즘에만 치우친 느낌이 든다.

내가 백엔드 개발자가 아니라서 네트워크 부분이 부족한 것도 있고, 다른 개발자분들은 공감하지 못할 것도 많을 것 같다.

그럼에도 최대한 나의 경험을 토대로 작성하려고 노력했다. 내가 더 많은 경험을 쌓게 되면 다른 상황에서 CS 지식을 이용한 문제 해결 경험을 적고 싶다.

Android Music 앱 만들기 (3) - ExoPlayer 커스텀하기

Thu, 06 Feb 2025 19:32:02 GMT

개요

이전에는 MediaLibraryService를 이용하여 간단하게 음악을 실행해보았다. 이제 음악 플레이어를 만들기 위해 ExoPlayer를 커스텀 해야 한다.

ExoPlayer는 Player라는 인터페이스를 상속 받아 구현하는 구현체이다. 그러니 사실상 Player에 기본적인 기능들은 다 들어가 있다.

그래서 똑같이 Player를 상속 받는 MediaController만으로 ExoPlayer의 기능들을 모두 사용할 수 있는 것이다.

그러니 "ExoPlayer 커스텀하기"보다는 "Player 커스텀하기"가 좀 더 맞는 것 같다.

이제 Player를 커스텀 해 보자.

Interface 작성

내가 만들고 싶은 기능을 먼저 Interface로 작성하고, 그 다음 상속받아 구현체를 작성하는 편이다. SOLID 원칙 중에 의존 역전 원칙을 잘 지키는 방법이기도 하다.

그러니 일단 필요한 것들을 생각 없이 작성해 보자.

나는 아래와 같은 필드들이 필요하다고 생각해서 작성하였다.

interface MediaPlayer {
    val isPlayingFlow: StateFlow //현재 음악 플레이 중인지
    val currentPositionFlow: Flow //현재 음악의 몇초를 플레이했는지
    val durationFlow: StateFlow //지금 음악의 총 길이는 몇 ms인지
    val currentMusicFlow: StateFlow //현재 음악은 무엇인지
    val musicCountFlow: StateFlow//총 음악 갯수는 무엇인지
    val errorFlow: SharedFlow//ExoPlayer 에러가 무엇인지
    val currentMusicIndexFlow: StateFlow//현재 음악의 index가 무엇인지
    val repeatModeFlow: StateFlow//현재 반복모드는 무엇인지
    val isShuffleFlow: StateFlow//셔플 모드인지
    fun play()//재생
    fun pause()//멈춤
    fun next()//다음
    fun previous()//이전
    fun seekTo(positionMillis: Long)//음악 재생바 넘김
    fun seekMusicByIndex(index: Int)//음악을 넘김
    fun addMusic(music: Music)//음악 추가
    fun addMusic(index: Int, music: Music)//음악 index에 추가
    fun addMusics(musics: List)//음악 여러개 추가
    fun addMusics(index: Int, musics: List)// 음악 여러개 index에 추가
    fun getMusic(index: Int): Music?//음악 가져오기
    fun setRepeatMode(repeatMode: RepeatMode)//반복모드 설정
    fun setShuffle(isShuffle: Boolean)// 셔플 모드 설정
}

어떻게 구현할 지, 이게 구현 가능할 지 모르지만 서비스에 필요한 기능들을 모아 작성하였다. ~~(다들 ExoPlayer로 뮤직 앱 잘만 만들고 있으니 아마 될것이다.)~~

고수준 모듈이 완성되었으니, 이것을 상속받아 구현하는 저수준 모듈을 만들어 보자.

Player.Listener

Player에는 여러가지 이벤트에 대해 CallBack을 받을 수 있도록 Player.Listener를 제공해 준다.

안드로이드 공식 문서

이 곳에서 보면 여러 Callback을 제공해주는 것을 볼 수 있는데, 우리의 Interface인 MediaPlayer에 필요한 Callback만 설명해보고자 한다.

onMediaItemTransition

override fun onMediaItemTransition(mediaItem: MediaItem?, reason: Int) {
    super.onMediaItemTransition(mediaItem, reason)
}

미디어 아이템이 바뀔 때 호출된다. mediaItem이라는 파라미터가 있어서 어떤 음악을 보고있는지를 가져올 수 있다.

이 곳에는 현재 음악이 무엇인지를 나태내는 currentMusicFlow, 현재 음악이 재생목록의 몇번째인지 Index를 나타내는 currentMusicIndexFlow를 구현할 수 있을 것 같다.

onIsPlayingChanged

override fun onIsPlayingChanged(isPlaying: Boolean) {
    super.onIsPlayingChanged(isPlaying)
}

미디어가 재생되거나 정지되었을 때 호출된다. isPlaying으로 재생인지, 정지인지 알 수 있으니 isPlayingFlow에 emit하기 좋은 장소이다.

또한 음악 스트리밍이기 때문에 실행해보기 전까진 이 음악이 총 몇초인지 알지 못한다.(이것때문에 꽤 고생을 했다...) 그렇기에 현재 음악이 총 몇초인지 나타내는 durationFlow도 이곳에 넣기 좋을 것 같다.

onPlayerError

override fun onPlayerError(error: PlaybackException) {
    super.onPlayerError(error)
}

Player에 Error가 났을 때 호출된다. 어떤 에러인지 알 수 있어서 errorFlow를 갱신하기 좋은 장소이다.

onRepeatModeChanged

override fun onRepeatModeChanged(repeatMode: Int) {
    super.onRepeatModeChanged(repeatMode)
}

반복 모드가 바뀔 때 호출된다. 이름에서 알 수 있듯이 repeatModeFlow를 호출하기에 적합한 곳이다. repeatMode가 Int로 반환되는데, 적절히 Enum으로 변환해주자.

onShuffleModeEnabledChanged

override fun onShuffleModeEnabledChanged(shuffleModeEnabled: Boolean) {
    super.onShuffleModeEnabledChanged(shuffleModeEnabled)
}

셔플 모드가 바뀔 때 호출된다. isShuffleFlow를 갱신하기 좋은 장소이다.

나는 위의 Callback만 필요하기 때문에 다른 것들은 사용하지 않았지만, Player.Listener의 안에는 이외에도 굉장히 많은 Callback이 내부에 준비되어 있기 때문에 입맛대로 골라서 사용하면 될 것 같다.

MediaPlayerImpl 만들기

필요한 Callback을 모두 알았으나, 아직 currentPositoinFlow를 구현하지 않는다.

아쉽게도 현재 재생 시간이 바뀔 때 호출되는 Callback은 없었다. 대체 이유가 무엇일까 생각했는데, ExoPlayer Github에서 비슷한 이슈를 찾을 수 있었다.

ExoPlayer Github

위의 링크로 들어가 보면 성능상의 문제가 있어서 제공하지 않는다는 것을 알 수 있다.

그리고 검색을 해 보면 보통 Handler를 사용하는 경우가 많은 것 같다.

StackOverFlow 답변

우린 Flow를 사용중인데,(물론 변환할 수 있지만) 아쉽지 않은가...!!

그래서 다른 코드를 참고하지 않고 직접 만들어 보기로 하였다.

실시간 재생 시간 가져오기

성능 이슈가 있다는 것을 고려하여 재생 시간을 가져오는 조건은 아래와 같았다.

불필요한 호출을 막기 위해 플레이중일 때만 currentPosition을 가져와야 한다.
음악이 바뀌면 0으로 초기화 해 준다.
delay 를 통해 주기를 완화시키고, Coroutine, While문을 적절히 취소시켜야 한다.

이미 만들 수 있는 currentMusicFlow와 isPlayingFlow를 이용한다면 쉽게 조건을 만족시킬 수 있다.

음악이 바뀔 때 → currentMusicFlow
플레이 중일 때 → isPlayingFlow

그럼 이 두개를 combine하여 조건을 만족할 때만 Flow를 흘려주면 된다!

@OptIn(ExperimentalCoroutinesApi::class)
override val currentPositionFlow = currentMusicFlow
    .combine(isPlayingFlow) { currentMusic, isPlaying ->
        channelFlow {
            while (isPlaying && coroutineContext.isActive) {
                delay(250L)
                val position = withContext(Dispatchers.Main) { player.currentPosition }
                send(position)
            }
        }
    }.flattenMerge().flowOn(Dispatchers.IO) //빠르게 변경되면 이전 flow가 취소되지 않은 상태에서 두 flow가 병렬로 실행될 수 있음.
//그래서 flattenMerge로 병합함.

주의! Main이 아닌 Thread에서 ExoPlayer를 실행시키면 안된다.

위의 코드에서 flowOn(Dispatchers.IO)를 했는데, 내부에서는 withContext(Dispatchers.Main)으로 player의 값을 가져왔다.

만약 Main이 아닌 다른 Thread에서 ExoPlayer를 호출한다면 아래와 같은 Exception이 뜬다.

이제 완성된 코드는 아래와 같다!

완성된 MediaPlayerImple

class MediaPlayerImpl @Inject constructor(
    private val player: Player
) : MediaPlayer {
    override val isPlayingFlow = MutableStateFlow(false)
    override val currentMusicFlow = MutableStateFlow(null)

    @OptIn(ExperimentalCoroutinesApi::class)
    override val currentPositionFlow = currentMusicFlow
        .combine(isPlayingFlow) { currentMusic, isPlaying ->
            channelFlow {
                while (isPlaying && coroutineContext.isActive) {
                    delay(250L)
                    val position = withContext(Dispatchers.Main) { player.currentPosition }
                    send(position)
                }
            }
        }.flattenMerge().flowOn(Dispatchers.IO) //빠르게 변경되면 이전 flow가 취소되지 않은 상태에서 두 flow가 병렬로 실행될 수 있음.
    //그래서 flattenMerge로 병합함.

    override val durationFlow = MutableStateFlow(0L)
    override val errorFlow = MutableSharedFlow(
        replay = 1,
        extraBufferCapacity = 1,
        onBufferOverflow = BufferOverflow.DROP_OLDEST
    )

    override val currentMusicIndexFlow = MutableStateFlow(player.currentMediaItemIndex)
    override val musicCountFlow = MutableStateFlow(0)
    override val repeatModeFlow = MutableStateFlow(RepeatMode.NONE)
    override val isShuffleFlow = MutableStateFlow(false)

    init {
        player.addListener(object : Player.Listener {

            override fun onEvents(player: Player, events: Player.Events) {
                super.onEvents(player, events)
            }

            override fun onMediaItemTransition(mediaItem: MediaItem?, reason: Int) {
                super.onMediaItemTransition(mediaItem, reason)
                currentMusicFlow.value = mediaItem?.toMusic()
                currentMusicIndexFlow.value = player.currentMediaItemIndex
            }


            override fun onIsPlayingChanged(isPlaying: Boolean) {
                super.onIsPlayingChanged(isPlaying)
                isPlayingFlow.value = isPlaying
                durationFlow.value = player.duration
            }

            override fun onPlayerError(error: PlaybackException) {
                super.onPlayerError(error)
                errorFlow.tryEmit(error.toPlayerError())
            }

            override fun onPlaybackStateChanged(playbackState: Int) {
                super.onPlaybackStateChanged(playbackState)
            }

            override fun onRepeatModeChanged(repeatMode: Int) {
                super.onRepeatModeChanged(repeatMode)
                repeatModeFlow.value = getRepeatModeFromMedia(repeatMode)
            }

            override fun onShuffleModeEnabledChanged(shuffleModeEnabled: Boolean) {
                super.onShuffleModeEnabledChanged(shuffleModeEnabled)
                isShuffleFlow.value = shuffleModeEnabled
            }

        })
    }

    override fun play() {
        if (player.playbackState == Player.STATE_IDLE)
            player.prepare()
        player.play()
    }

    override fun pause() {
        player.pause()
    }

    override fun next() {
        if (player.currentMediaItemIndex == player.mediaItemCount - 1) {
            player.seekTo(0, 0L)
            return
        }
        player.seekToNext()
    }

    override fun previous() {
        if (player.currentMediaItemIndex == 0) {
            player.seekTo(player.mediaItemCount - 1, 0L)
            return
        }
        player.seekToPrevious()
    }

    override fun seekTo(positionMillis: Long) {
        player.seekTo(positionMillis)
    }

    override fun seekMusicByIndex(index: Int) {
        player.seekTo(index, 0L)
    }

    override fun addMusic(music: Music) {
        player.addMediaItem(music.toMediaItem())
        updateMusicCount()
    }

    override fun addMusic(index: Int, music: Music) {
        player.addMediaItem(index, music.toMediaItem())
        updateMusicCount()

    }

    override fun addMusics(musics: List) {
        player.addMediaItems(musics.map { it.toMediaItem() })
        updateMusicCount()

    }

    override fun addMusics(index: Int, musics: List) {
        player.addMediaItems(index, musics.map { it.toMediaItem() })
        updateMusicCount()
    }

    override fun getMusic(index: Int): Music? {
        if (player.mediaItemCount <= index) return null
        return player.getMediaItemAt(index).toMusic()
    }

    override fun setRepeatMode(repeatMode: RepeatMode) {
        player.repeatMode = repeatMode.toMediaRepeatModeInt()
    }

    override fun setShuffle(isShuffle: Boolean) {
        player.shuffleModeEnabled = isShuffle
    }

    private fun updateMusicCount() {
        musicCountFlow.value = player.mediaItemCount
    }

    private fun getRepeatModeFromMedia(repeatModeInt: Int) = when (repeatModeInt) {
        Player.REPEAT_MODE_ALL -> RepeatMode.ALL
        Player.REPEAT_MODE_ONE -> RepeatMode.ONE
        Player.REPEAT_MODE_OFF -> RepeatMode.NONE
        else -> {
            RepeatMode.NONE
        }
    }


}

많이 길어졌지만, 아주 좋다..!!

마치며

이번에는 ExoPlayer를 Jetpack Compose에서 쉽게 사용하기 위해 Flow로 변환하는 과정을 거쳤다.

ExoPlayer 내부도 뜯어 보고, 특히 실시간으로 재생 시간 데이터 받아오기에 많은 고민을 쏟은 시간이었다.

다음 포스팅에는 기존 구조를 Multi Module에 맞는 구조로 바꾸어 좀 더 쉽게 사용하도록 할 예정이다.

많은 기대 부탁!

Android Music 앱 만들기 (2) - MediaLibraryService

Thu, 09 Jan 2025 16:42:34 GMT

개요

이전에는 Android Music 앱을 만들 때 필요한 클래스, 타입들과 기본적인 구조에 대해 살펴보았다. 이번에는 살펴본 내용으로 직접 MediaLibraryService 만들어 보자.

MediaLibraryService

MediaLibraryService는 MediaSessionService를 상속받고 있으며 abstract class이다.

그리고 한 메소드를 override 해야 하는데 onGetSession이다.

원래 MediaSessionService에 있는 abstract 함수인데 MediaLibraryService에서는 override되어 MediaLibrarySession을 반환하도록 되어 있다.

MediaLibrarySession은 MediaSession을 상속받고 있기 때문에 abstract 함수를 override를 할 수 있었던 것이고, MediaSession에 있는 음악 조절 기능들도 모두 사용할 수 있다.

그럼 MediaLibrarySession을 상속받아 구현해보자.

class PlayerService : MediaLibraryService() {

    private var mediaLibrarySession: MediaLibrarySession? = null
    private val mediaLibrarySessionCallback = object : MediaLibrarySession.Callback {    }

    override fun onCreate() {
        super.onCreate()
        mediaLibrarySession = MediaLibrarySession.Builder(
            this,
            ExoPlayer.Builder(this).build(),
            mediaLibrarySessionCallback
        ).build()
    }

    override fun onGetSession(controllerInfo: MediaSession.ControllerInfo) =
        mediaLibrarySession

    override fun onTaskRemoved(rootIntent: Intent?) {
        super.onTaskRemoved(rootIntent)
        val player = mediaLibrarySession?.player!!
        if (!player.playWhenReady
            || player.mediaItemCount == 0
            || player.playbackState == Player.STATE_ENDED) {
            // Stop the service if not playing, continue playing in the background
            // otherwise.
            stopSelf()
        }
    }

    override fun onDestroy() {
        mediaLibrarySession?.run {
            player.release()
            release()
            mediaLibrarySession = null
        }
        super.onDestroy()

    }



}

MediaLibrarySession

미디어를 조작하거나 탐색하기 위한 정보가 들어있다. 생성하려면 Builder로 생성해야 하며, 필요한 파라미터는 Context, Player, MediaLibrarySession.Callback이다.

특히 MediaLibrarySession.Callback이 다른 점인데, 이 곳에 있는 onSearch같은 함수를 override하여 탐색을 구현할 수 있다.

onGetSession

MediaSessionService와 같이 필수로 override 해야하는 abstract function이다. 다만 이전과는 다르게 MediaSession이 아닌 MediaLibrarySession을 반환해야 한다.

onTaskRemoved

앱이 Task에 지워졌을 때 어떻게 할 것인지 결정할 수 있는 함수이다. 우리는 App이 종료되었을 때도 음악은 계속 재생되어야 하기 때문에 유지시켜 주어야 한다.

공식 문서에서는 이 조건을 위와 같이 했는데 뜻은 이러하다.

player.playWhenReady: getPlaybackState() == STATE_READ일 때 음악을 재생할 것인지 아닌지 결정하는 변수이다. 음악 재생이 준비되었을 때 재생할 것인지를 true, false로 결정할 수 있다.
player.mediaItemCount: 현재 플레이리스트에 있는 미디어 아이템 갯수를 반환한다. 위의 코드에서는 갯수가 0일 때 정지하는 것으로 조건을 설정하였다.
player.playbackState: 현재 플레이어의 상태를 나타낸다. 조건에서는 STATE_END일 때 정지한다.

STATE에는 아래의 4가지 상태가 있다.

MediaLibraryService 공식 문서에서는 onTaskRemoved를 override하지 않지만, MediaSessionService 공식 문서에서는 onTaskRemoved를 위와 같이 override한다.

MediaLibraryService로 되면서 뭔가 변화되었기 때문인가 생각했지만 변화된 것은 딱히 없었다.

그래서 MediaSessionService문서와 같이 보면서 작성해야 한다.

STATE_END일 때 종료??

위의 코드에서 보면 player.playbackState == Player.STATE_ENDED의 조건으로 되어 있다. 하지만 Player.STATE_ENDED는 한 곡이 끝나도 호출되기 때문에 한곡 재생이나 반복 재생으로 세팅되어도 꺼지게 된다.

마침 player에 repeatMode를 받을 수 있고, REPEAT_MODE_OFF라는 것도 있어서 공식 문서와는 조건을 다르게 주었다.

override fun onTaskRemoved(rootIntent: Intent?) {
    val player = mediaLibrarySession?.player!!
    if (!player.playWhenReady
        || player.mediaItemCount == 0
        || (player.playbackState == Player.STATE_ENDED
                && player.repeatMode == Player.REPEAT_MODE_OFF) //곡이 끝났고, 반복 재생 모드가 아닐 때
    ) {
        stopSelf()
    }
}

Activity 연결

Media3가 나름 최신 라이브러리이니, 나도 Compose로 UI를 만들어 Activity에 연결해 보려고 한다.

MediaLibraryService가 완성되었으니 이제 연결해보자.

MediaLibraryService는 MediaController, MediaBrowser 둘 다 만들 수 있다.

그러니 MediaController와 MediaBrowser를 Compose 여러곳에서 사용할 수 있도록 CompositionLocal을 만들자.

val LocalMediaController = compositionLocalOf { error("No MediaSession provided") }

val LocalMediaBrowser = compositionLocalOf { error("No LocalMediaBrowser provided") }

그다음 private 필드를 activity에 만들어 놓자. compose에서 CompositionLocal을 사용해야 하니, 이 변수는 mutableState로 만든다.

private var mediaController by mutableStateOf(null)
private var mediaBrowser by mutableStateOf(null)

MediaController와 MediaBrowser는 Future로 받아오게 된다. 만약 Future로 받아오는 중에 앱이 중단되거나 사용자가 끄면 받아오는 것을 중단시켜야 한다. 그래서 onStop에서 중단할 수 있도록 Future도 private Field로 만들어주자.

private lateinit var mediaControllerFuture: ListenableFuture
private lateinit var mediaBrowserFuture: ListenableFuture

이제 이 변수들을 초기화 하는 코드를 작성해 보자.

//MediaService 토큰 받기
val sessionToken = SessionToken(this, ComponentName(this, MediaService::class.java))

//토큰으로 MediaController의 future 생성
mediaControllerFuture = MediaController.Builder(this, sessionToken)
    .buildAsync()

//토큰으로 MediaBrowser의 future 생성
mediaBrowserFuture = MediaBrowser.Builder(this, sessionToken)
    .buildAsync()

//MediaController가 준비되면 저장
mediaControllerFuture.addListener({
    mediaController = mediaControllerFuture.get()
}, MoreExecutors.directExecutor())
//MediaBrowser가 준비되면 저장

mediaBrowserFuture.addListener({
    mediaBrowser = mediaBrowserFuture.get()
}, MoreExecutors.directExecutor())

이제 이것을 CompositionLocalProvider에 넣어주면 된다.

CompositionLocalProvider(
    LocalMediaController.provides(mediaController),
    LocalMediaBrowser.provides(mediaBrowser)
) {
    Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
        MusicScreen(modifier = Modifier.padding(innerPadding))
    }
}

마지막으로 앱이 stop 될 때, MediaController와 MediaBrowser를 해제시켜주고, 앞서 말했듯 Future들도 해제시켜 준다

override fun onStop() {
    super.onStop()
    mediaController?.release()
    mediaBrowser?.release()
    MediaController.releaseFuture(mediaControllerFuture)
    MediaBrowser.releaseFuture(mediaBrowserFuture)
}

위의 내용은 안드로이드 MediaController 공식 문서에서 찾을 수 있다.

Activity전체 코드

class MainActivity : ComponentActivity() {

    private var mediaController by mutableStateOf(null)
    private var mediaBrowser by mutableStateOf(null)

    private lateinit var mediaControllerFuture: ListenableFuture
    private lateinit var mediaBrowserFuture: ListenableFuture

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        //MediaService 토큰 받기
        val sessionToken = SessionToken(this, ComponentName(this, MediaService::class.java))

        //토큰으로 MediaController의 future 생성
        mediaControllerFuture = MediaController.Builder(this, sessionToken)
            .buildAsync()

        //토큰으로 MediaBrowser의 future 생성
        mediaBrowserFuture = MediaBrowser.Builder(this, sessionToken)
            .buildAsync()

        //MediaController가 준비되면 저장
        mediaControllerFuture.addListener({
            mediaController = mediaControllerFuture.get()
        }, MoreExecutors.directExecutor())

        //MediaBrowser가 준비되면 저장
        mediaBrowserFuture.addListener({
            mediaBrowser = mediaBrowserFuture.get()
        }, MoreExecutors.directExecutor())

        enableEdgeToEdge()
        setContent {
            OffLineMusicTheme {
                CompositionLocalProvider(
                    LocalMediaController.provides(mediaController),
                    LocalMediaBrowser.provides(mediaBrowser)
                ) {
                    Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->
                        MusicScreen(modifier = Modifier.padding(innerPadding))
                    }
                }
            }
        }
    }

    override fun onStop() {
        super.onStop()
        mediaController?.release()
        mediaBrowser?.release()
        MediaController.releaseFuture(mediaControllerFuture)
        MediaBrowser.releaseFuture(mediaBrowserFuture)
    }
}

이제 준비는 끝났다. MusicScreen이라는 곳에 LocalMediaController.current를 통해 MediaController를 받아오고 실행시켜 보자.

@Composable
fun MusicScreen(modifier: Modifier = Modifier) {
    val localMediaController = LocalMediaController.current
    val localMediaBrowser = LocalMediaBrowser.current
    localMediaController?.addMediaItem(
        MediaItem.Builder().setMediaId("1")
            .setUri("https://storage.googleapis.com/exoplayer-test-media-0/play.mp3").build()
    )
    localMediaController?.play()
}

결과

앱을 꺼도 백그라운드에서 잘 동작하는 모습을 볼 수 있다.

Android Music 앱 만들기 (1) - 사전지식 및 구조

Android Music 앱 만들기 (1) - 사전 지식 및 구조

Wed, 08 Jan 2025 12:43:11 GMT

개요

나는 음악을 정말 좋아한다. 장르를 가리지 않고 그 날의 기분이나 분위기에 맞는 음악을 버스, 지하철에서 듣는다.

그리고 우연히 모 회사에서 뮤직 스트리밍 앱 개발자를 뽑는다는 공고를 보고 음악 앱을 만드는 방법에 대해 생각했었다.

백그라운드에서 돌아갈 수 있게 Service를 만들고, 음악을 재생하면 되겠지?

그리고 자료를 찾아 봤는데, 생각보다 자료가 많이 나와있지 않았다. 그나마 영어 자료는 많지만 한국어 자료들은 오래된 것들이 대부분이고 최근 것들은 부족했었다.

그래서 내가 한번 Compose로 간단한 음악 스트리밍 앱을 만들어 보기로 했다.

구조 생각해보기

클린 아키텍쳐, MVVM을 이야기 하는 것이 아니다.

백그라운드에서도 음악을 재생하려면 Service에 그 기능이 있어야겠다고 생각했다. 그리고 앱이 ForeGround에 있다면 보여줘야 할 Activity와 Service에서 재생되고 있는 음악이 따로 있어야 할텐데,

두 컴포넌트에서 어떻게 통신해야 할까?

다행히 안드로이드에서는 아래와 같은 구조로 짜라고 가이드를 준다. (역시 친절한 Android...)

Jetpack Media3 공식 문서

처음 보는 단어들이 많이 나온다. 문서에는 저 단어들을 정리한 표를 보여주는데 그 표를 간단히 정리하자면 다음과 같다.

Player는 음악을 재생하는 역할을 담당한다. interface이며 ExoPlayer가 이를 구현하는 구현체이다. 보통 ExoPlayer를 사용한다.
MediaSession은 Player와 상호작용하여 재생, 정지와 같은 명령을 전달한다. 명령을 주는 객체는 뒤에 설명할 MediaController이다.
MediaSessionService는 MediaSession을 사용하는 전용 Service이다. 기본적인 MediaSession관련 기능들을 가지고 있다.
MediaController는 MediaSession에게 명령을 전달하는 역할을 한다. 특이하게 Player를 상속 받아 구현하고 있으며, 미디어를 재생하는 주체가 아님에도 마치 재생하는 것처럼 조작할 수 있다.

크게 본다면 재생하는 주체인 ExoPlayer, 중간다리 역할을 하는 MediaSession, 그리고 재생하는 주체가 아님에도 마치 재생하는 주체처럼 컨트롤 할 수 있게 하는 MediaController가 있다.

MediaLibraryService, MediaBrowser?

/로 구분지어 놓은 MediaLibraryService와 MediaBrowser가 눈에 띈다.

MediaLibraryService는 MediaSessionService를 상속받고 있다.

공식 문서에서는 아래와 같이 설명하는데

MediaLibraryService는 MediaSessionService와 비슷하며 content library를 제공할 수 있게 한다는 것이다.

그리고 이 제공한 것들을 브라우징 할 수 있는 녀석이 MediaBrowser이다.

멜론이나 라인 뮤직과 같은 앱 들은 빅스비, 시리로도 실행이 가능한데 이처럼 다른 앱에서 접근하여 음악 목록들을 탐색할 수 있게 하려면 MediaLibraryService 사용해야 한다!(혹은 아래 설명할 MediaBrowserService)

자세한 내용은 아래 공식 문서에서 확인할 수 있다.

MediaLibraryService 공식 문서

MediaBrowserService?

찾아보니 옛날 문서에는 MediaBrowserService라는 것이 있었다. 이름 그대로 미디어를 브라우징(찾는)역할을 할 수 있는 서비스라는 것인데...

옛날 공식 문서

앨범에 있는 트랙, 혹은 오디오북 처럼 음악을 탐색할 때 사용되는 Service라는 것이다.

두 Service를 비교하는 글이 없어서 어떤 것이 달라졌는지 찾기 힘들었지만, 제미나이의 답변은 아래와 같았다.

보면 MediaLibraryService는 외부 클라이언트가 Service에서 음악을 탐색할 수 있지만, MediaBrowserService는 외부 클라이언트가 Service에서 음악을 탐색할 수 없는 것 같다. (믿을만 한가...?)

정리하면

MediaLibraryService는 미디어 라이브러리를 외부에서 탐색할 수 있도록 제공하는 역할
MediaBrowserService는 미디어 라이브러리를 내부에서 탐색하는 역할

MediaLibraryService와 함께 나오는 키워드들이 Android Auto랑 Google Assistance이니, 아마 Media3로 넘어오면서 이런 기능 연계가 중요해진게 아닐까?

Other App? System Media Controls?

이것들은 뭐길래 내 Service에 접근하는 것일까? 우리가 음악 앱을 보통 사용하면 이어폰 버튼으로 음악을 재생하거나 멈추는 행동을 많이 한다.

당연히 외부에서 음악을 조절할 수 있어야 하는 것이다...!

그리고 플레이스토어에서 깔 수 있는 음악 꺼주는 앱들도 있다. 이런 앱들이 음악을 꺼줘야 한다.

기술 결정

대부분의 앱 들은 빅스비, 시리로 실행 가능하다. 또한 여러 상황에 맞는 앱을 구현하려면 역시 MediaLibraryService로 구현하는 것이 알맞다고 생각했다.

그럼 자연스럽게 MediaBrowser로 탐색하여 UI에 제공. 그리고 이 기능을 이용하여 Activity와 Compose를 구현하면 되겠다!

마치며

Android의 4대 컴포넌트인 Activity, Service, Content Provider, BroadCast Reciever는 면접 단골 질문이다. 그래서 단어들은 다들 익숙하지만, 막상 사용한 것은 Activity밖에 없었다.

이번 기회에 Service를 사용하는 방법을 잘 알 수 있을 것 같다.

그래서 다음 번에는 Service를 이용하여 음악을 재생하는 방법을 알아 보자!

Android Music 앱 만들기 (2) - MediaLibraryService

Android - Retrofit 없이 Http 통신하기

Fri, 27 Dec 2024 20:24:23 GMT

Retrofit?

Retrofit이란 Android에서 Http통신을 쉽게 할 수 있도록 만들어진 Library이다. 어노테이션과 함께 Interface를 작성하면, 그 내용을 토대로 객체를 만들어 반환해 준다. 만약, GitHub에서 이슈를 가져오는 코드를 짠 다면, 아래와 같이 짤 수 있다.

internal interface IssueApiRetrofit {
    @GET("issues")
    suspend fun getIssue(
        @Query("page") page: Int,
        @Query("per_page") perPage: Int = 100,
    ): Response>
}

GET, POST, UPDATE, DELETE 어노테이션으로 API 통신 함수를 만들어 주고 error code, body, errorBody를 손 쉽게 가져올 수 있는 Response와 Call 객체를 제공해 준다.

이렇게 손쉽게 만들 수 있는 Retrofit. 하지만 "Retrofit을 왜 사용하는가?" 에 대한 대답을 온전히 할 수 없을 것 같다. 대답을 하려면 Retrofit이 없는 환경을 먼저 알아야 하는게 좋다고 생각했다.

따라서 나는 Retrofit 없이 HttpConnection과 JsonParser를 이용하여 Http통신을 해보려 한다.

HttpConnection 만들기

먼저 HttpConnection을 만드려면 URL을 만들어야 한다. 그럼 URL의 구조에 대해 알아야 하는데, URL의 구조를 위키에서는 아래와 같이 표현하고 있다.

이 구조를 보고 자주 사용하는 패턴으로 바꾼다면

https(또는 http)://authority/path?query

이 정도로 볼 수 있다.

그럼 Retrofit과 비교했을 때, 위의 URL은 어떻게 대응될까?

https와 authority

먼저 https(또는 http)://authority는 Retrofit 객체를 만들 때 들어가는 baseUrl로 볼 수 있다.

이 때 BaseUrl에는 통신 규약(https, http)와 authority가 들어간다.

Path

그 다음 path는 GET, POST, UPDATE, DELETE에 들어가는 값이나

@GET("issues") //Path 값이 들어간다.
suspend fun getIssue(
    @Query("page") page: Int,
    @Query("per_page") perPage: Int = 100,
): Response>

@Path 어노테이션으로 대응될 수 있다.

@PATCH("issues/{issue_number}")
suspend fun updateIssue(
    @Path("issue_number") issueNumber: Long,
    @Body issueBody: IssueBody
): Response

Query

마지막으로 쿼리는 @Query라는 어노테이션으로 대체될 수 있다.

@GET("issues")
suspend fun getIssue(
    @Query("page") page: Int, //query 대체
    @Query("per_page") perPage: Int = 100,
): Response>

즉, GitHub야, Page가 1인, issue를 줘. 라고 해야 한다면

https://github.com/issue?page=1

이렇게 URL을 보내면 된다.

이제 GET, POST와 Header를 붙여 요청하는 함수를 만들어 보자.

HttpConnection함수 작성

위의 내용을 토대로 BaseUrl, Path, Qeury를 받는 함수를 만들자.


const val GITHUB_ACCEPT_KEY = "Accept"
const val GITHUB_ACCEPT_VALUE = "application/vnd.github+json"

const val GITHUB_AUTH_KEY = "Authorization"
const val GITHUB_AUTH_VALUE_BEARER = "Bearer ${BuildConfig.TOKEN}"

const val GITHUB_API_VERSION_KEY = "X-GitHub-Api-Version"
const val GITHUB_API_VERSION_VALUE = "2022-11-28"

private suspend fun getConnection(
    method: String,
    baseUrl: String,
    endPoint: String,
    vararg queries: String
): HttpURLConnection {

    //url 생성
    val urlString = baseUrl + endPoint

    //query 생성
    val queryString = if (queries.isEmpty()) "" else "?${queries.joinToString("&")}"

    //URL을 만들고 Connection 생성
    val url = URL(urlString + queryString)
    val conn = withContext(Dispatchers.IO) {
        url.openConnection()
    } as HttpURLConnection

    //GET, POST, UPDATE, DELETE
    conn.requestMethod = method

    //TIME_OUT 제한 설정
    conn.connectTimeout = TIME_OUT_MILLIS
    conn.readTimeout = TIME_OUT_MILLIS

    //Header 붙이기
    conn.setRequestProperty(Header.GITHUB_AUTH_KEY, Header.GITHUB_AUTH_VALUE_BEARER)
    conn.setRequestProperty(Header.GITHUB_ACCEPT_KEY, Header.GITHUB_ACCEPT_VALUE)
    conn.setRequestProperty(Header.GITHUB_API_VERSION_KEY, Header.GITHUB_API_VERSION_VALUE)
    return conn
}

이제 에러를 핸들링 할 함수를 만들고

private suspend fun  handleResponse(
    connSupplier: suspend () -> HttpURLConnection,
    supplier: (String) -> T
): ApiResult {
    return try {
        val conn = connSupplier()
        if (conn.responseCode == HttpURLConnection.HTTP_OK) {
            val jsonString = getResponseString(conn)
            conn.disconnect()
            val info = supplier(jsonString)
            ApiResult.Succeed(conn.responseCode, info)
        } else {
            ApiResult.Error(conn.responseCode, conn.responseMessage)
        }
    } catch (e: Exception) {
        e.printStackTrace()
        ApiResult.Error(InternalErrorCode.PARSING_FAIL.code, e.message)
    }
}

아래와 같이 호출해 주면 된다.

override suspend fun getIssue(page: Int): ApiResult> {
    return handleResponse({
        getConnection(
            "GET",
            END_POINT_ISSUES,
            "page=$page"
        )
    }) { jsonString ->
        //json parsing하기
    }
}

Json 직접 파싱하기.

Json을 파싱하려면 string을 JsonObject로 만든 후, 필드의 이름을 string으로 넘겨주면 가져올 수 있다.

만약 array형태로 되어있다면, JsonArray를 사용하면 된다.

fun parseIssueDto(jsonObject: JSONObject): IssueDto {

    //label
    val labels = parseLabelDtoList(jsonObject.getJSONArray("labels"))
    val assignees = parseUserDtoList(jsonObject.getJSONArray("assignees"))
    val url = jsonObject.getString("url")
    val repository_url = jsonObject.getString("repository_url")
    val comments_url = jsonObject.getString("comments_url")
    val events_url = jsonObject.getString("events_url")
    val html_url = jsonObject.getString("html_url")
    val id = jsonObject.getLong("id")
    val node_id = jsonObject.getString("node_id")
    val number = jsonObject.getLong("number")
    val title = jsonObject.getString("title")
    val user = parseUserDto(jsonObject.getJSONObject("user"))
    val state = jsonObject.getString("state")
    val locked = jsonObject.getBoolean("locked")
    val body = jsonObject.getString("body")
    val mileStoneDto = jsonObject.optJSONObject("milestone")?.let { parseMileStoneDto(it) }
    val created_at = jsonObject.getString("created_at")
    val closed_at = jsonObject.getString("closed_at")
    val updated_at = jsonObject.getString("updated_at")

    return IssueDto(
        url = url,
        repositoryUrl = repository_url,
        commentsUrl = comments_url,
        eventsUrl = events_url,
        htmlUrl = html_url,
        id = id,
        nodeId = node_id,
        number = number,
        title = title,
        user = user,
        labels = labels,
        state = state,
        locked = locked,
        assignees = assignees,
        body = body,
        milestone = mileStoneDto,
        createdAt = created_at,
        closedAt = closed_at,
        updatedAt = updated_at,
    )

}

이렇게 하면 Retrofit 없이 Http통신을 할 수 있다.

느낀점

이런 노가다를 하며... 느낀점이 있다.

1. 실수할 여지가 많다.

GET, POST, UPDATE, DELETE 메소드를 String으로 넘겨야 하고, 또한 Query도 String으로 넘겨 주어야 한다.

String으로 넘겼을 때 단점은 다들 알다시피 오타가 날 수 있다는 것이다.

따라서 오타가 났는지, 아닌지 조심하며 작성해야 한다.

또한 Query를 넘길 때, Query가 없다면 물음표(?)를 빼줘야 하고, Query가 있을 때는 넣어야 한다는 귀찮음도 있었다.

2. Json Parsing이 어렵다.

이건 HttpConnection으로 데이터를 가져온 후, Kotlin Serialization이나 Gson으로 대체하여 Parsing할 수 있지만, 이번에 Retrofit 사용 안하는 김에 똑같이 사용하지 않고 JsonObject로 해 보았다.

이 때의 단점은 앞선 오타의 단점과, 하나하나 JsonObject로 접근해 String, Int등으로 가져와야 하는 번거로움이 있었다. 실수할 여지도 많았으며, 필드가 많으면 잘못 가져올 수도 있다는 단점도 있었다.

[Python] 프로그래머스(2022카카오 신입 공채) 파괴되지 않은 건물(구간 합)

Sat, 21 Dec 2024 15:22:29 GMT

문제

파괴되지 않은 건물

풀이

정확성 테스트를 통과하는 것은 어렵지 않다. 그저 반복문을 통하여 Skill에 나오는 범위 만큼 더하거나 빼주면 쉽게 풀 수 있다.

하지만 효율성 테스트는 통과하지 못하는데, 어떻게 하면 통과하는 지, 통과하는 이유는 무엇 인지를 기록할 것이다.

아이디어는 "명령어 들을 한번에 하나 씩 처리하는 것이 아니라, 한번에 모아서 처리할 수는 없을까?"이다.

먼저 정확성 테스트만 통과하는 코드를 보자.

def solution(board, skill):
    answer = 0
    for i in skill:
        t,r1,c1,r2,c2,d=i
        if t==1:
            d=-d
        for i in range(r1,r2+1):
            for j in range(c1,c2+1):
                board[i][j]+=d
    for i in range(len(board)):
        for j in range(len(board[0])):
            if board[i][j]>0:
                answer+=1
    return answer

이 코드는 하나의 명령이 떨어질 때 마다, 그 명령의 사각형 범위 만큼 반복문을 통하여 board를 갱신하게 된다.

입출력 예 1번에 비유하면

이 상태에서 r1=0, c1=0, r2=3, c2=4 이니 (0,0)부터 (3,4)까지 4의 피해를 입힌다. 그럼 밑의 그림처럼 된다.

그럼 이번 명령을 처리하기 위해 컴퓨터가 계산한 양은 (r2-r1+1)(c2-c1+1)=45, 20이 된다.

다음 명령을 수행하면 (2,0) 부터 (2,3) 까지 2의 피해를 입히게 되어 밑의 그림처럼 바뀌게 된다.

그럼 이번의 컴퓨터가 계산한 양은 (2-2+1)*(3-0+1)=4가 된다.

그렇다면 가장 많이 계산하는 상황은 무엇일까?

매 명령 마다 표의 모든 요소를 변화 시키는 것이다. 모든 명령이 [1,0,0,3,4,-1] 인 경우이다.

표의 요소는 5*4=20개 이니 명령어 마다 20개의 숫자를 계산할 것이다.

board의 가로의 길이를 n, 세로의 길이를 m, 명령어의 갯수를 c라고 한다면 컴퓨터가 처리해야 할 계산의 횟수는 nmc가 된다. O(nmc)

이제 이것을 개선해 보자.

먼저 간단하게 생각하기 위해 위의 board를 1차원 배열로 생각해 보자. 그럼 밑의 표처럼 된다.

여기서 구간 0~3까지 -1을 하는 명령이 떨어졌다 생각해 보자. 전의 방식은 위의 표에 직접 -1씩 했을 것이다.

하지만 이렇게 하지 말고 각 칸의 변화 만을 저장하는 표를 하나 더 만들어 따로 저장해 보자. 그럼 밑의 그림처럼 될 것이다.

변화를 저장하는 표에 효율성을 통과하지 못하는 코드와 똑같이 4번의 연산이 들어갔다.

이 연산을 줄이는 방법을 찾아야 하는데, 이 방법은 명령에 의한 숫자 변화를 처음과 끝+1에 표시만 하는 방법이다.

이렇게 하면 연산은 시작 점에 -1, 끝 점의 다음 점에 +1, 총 두 번의 연산을 수행하게 된다. 이 표식을 나중에 풀 때는 이 변화를 저장하는 표를 처음부터 끝 까지 순회하며 누적으로 더해 주면 원래의 표가 나온다.

arr[i]=arr[i]+arr[i-1]

우리는 위의 표시만 하는 방법으로 모든 명령을 처리 할 것이다. 그럼 1차원 배열로 예시(Test Case)를 하나 만들어 보자. 맨 처음 board가 [5,5,5,5,5] 이고, 명령어가 [[1,0,0,0,3,1],[1,0,1,0,4,1],[2,0,2,0,4,1],[1,0,1,0,3,3]] 이라고 가정해 보자.

그럼 우리는 표시만 하는 방법으로 변화 표를 계산하면 밑의 그림처럼 된다.

1번째 명령(0 부터 3 까지 -1, 0번 index에 -1, 3+1번 index에 +1):

2번째 명령(1 부터 4까지 -1, 1번 index에 -1, 4+1번 index에 +1, 하지만 5번 index이면 표의 범위를 벗어나므로 생략.):

3번째 명령(회복, 2번에 +1 맨 끝은 표의 범위를 벗어나므로 생략.):

4번째 명령(1번 index에 -3, 3+1번 index에 +3):

자 이렇게 표식 만을 모두 남겨 놓았다. 이 표식을 남겨 놓은 표를 누적으로 풀게 되면 밑의 표 처럼 되는데,

이 표가 바로 모든 칸의 변화 점이 된다.(의심이 된다면 직접 계산하여 비교해 보면 된다.)

위의 방법은

한 명령어가 얼마나 많은 칸의 요소들을 변화 시키는 명령이든, 단 두 번의 표식만 남기고 넘기기 때문에 한 명령어 당 계산 횟수는 2회가 된다.

또한 마지막에 누적으로 원래의 변화를 계산할 때는 표의 길이 만큼 순회하기 때문에 표의 길이 만큼의 계산 횟수가 들어가게 된다.

따라서 명령의 횟수를 c, 표의 길이를 n이라 할 때, 표식을 남겨 놓은 표를 풀 때 까지의 계산 횟수는 O(c2)(명령어 처리 및 표식)+O(n)(표식이 된 표를 풀기)=O(c2+n)이 된다.

이제 원래의 표에 변화들을 적용 시키면 또 표의 길이 만큼 순회하며 계산이 들어갈 것이다. 따라서 표의 길이 n만큼 계산이 들어간다. O(n)

최종적으로 컴퓨터가 계산한 횟수는 O(c2)+O(n)+O(n) 이므로 O(c2+2n)이 된다.

이는 위의 Test Case의 상황 말고도, 매 명령이 모든 표의 요소를 변화 시키는 명령이라고 해도 매 명령 마다 두 번만 수행하므로 O(2c+2n)이 된다.

정확성만 통과하는 방식은 명령어 마다 모든 요소를 변화 시키므로 O(c*n)이 되는데, c를 10, n을 20으로 가정 하였을 때 정확성 방식은 200, 개선된 방식은 20+40=60이 된다.

아주 훠어어얼씬 빠른 코드가 되는 것이다.(이는 계산 식에 상수가 들어있기 때문이다.)

만약 c와 n이 더욱 큰 숫자라면 이 차이는 더욱 많이 될 것이다.

지금 까지 개선한 방식을 2차원 배열로 확장하면 이 문제에 대입할 수 있다.

1차원 배열에서 변화를 저장하는 표의 arr[i]는 arr[0]부터 arr[i]까지의 합으로 볼 수 있다.

2차원 배열에서 변화를 저장하는 표의 arr[i][j]는 arr[0][0] 부터 arr[i][j]까지의 사각형이 그리는 구간의 누적 합이 된다.

(예시, arr[3][3]은 arr[0][0]과 arr[3][3]이 그리는 사각형의 합.)

그럼 표식은 어떻게 할까?

시작 점 (i,j)(왼쪽 위 모서리)와 끝 점 (k,l)(오른쪽 아래 모서리), 변화 시킬 숫자 d가 주어졌다고 가정했을 때, arr[i][j]에 +d, arr[i][l+1]에 -d arr[k][j+1]에 -d, arr[k+1][l+1]에 +d를 해주면 된다.

(예시, (1,1)과 (3,3), 변화는 -1)

(표가 굉장히 더럽혀 졌다... 요점은 arr[?][?]는 시작점[i][j] 부터 자신의 위치 arr[?][?]까지의 모든 칸의 누적 합이라는 것이다. 누적 했을 때, 원래 의도했던 구간에 모두 -1 할 수 있도록 표식을 해주는 것이 포인트 이다.)

이러한 방식을 문제에 대입하면 효율성 테스트 까지 모두 통과한다.

코드:

def solution(board, skill):
    answer = 0
    change=[[0 for _ in range(len(board[0])+1)]for _ in range(len(board)+1)]
    for i in skill:
        t,r1,c1,r2,c2,d=i
        if t==1:
            d=-d
        change[r1][c1]+=d
        change[r1][c2+1]-=d
        change[r2+1][c1]-=d
        change[r2+1][c2+1]+=d
    for i in range(1,len(change[0])):
        change[0][i]+=change[0][i-1]
    for i in range(1,len(change)):
        change[i][0]+=change[i-1][0]

    for i in range(1,len(change)):
        for j in range(1,len(change[0])):
            change[i][j]=change[i-1][j]+change[i][j-1]+change[i][j]-change[i-1][j-1]


    for i in range(len(board)):
        for j in range(len(board[0])):
            board[i][j]+=change[i][j]
            if board[i][j]>0:
                answer+=1
    return answer

결과:

[객체 지향과 디자인 패턴] SOLID 다섯 가지 설계 원칙

Wed, 13 Apr 2022 16:39:17 GMT

개요

스파게티 코드를 작성하지 않으려면 프로그램을 설계하는 능력이 중요하다.

체계적이고 확장성이 좋으며 변경에 민감하지 않아야 나중에 유연하게 고칠 수 있는 프로그램이 된다고 한다.

하지만 처음부터 좋은 설계를 하는 것은 쉽지 않다. 실패했던 경험이 쌓여야 어느 기능을 분리 시키고, 합쳐야 하는지 직감적으로 알 수 있기 때문이다.

마치 데이터베이스 수업 시간 때 들었던 관계형 데이터베이스 설계가 생각난다.

하지만 감각이나 센스가 중요한 데이터 베이스에도 1차 정규형, 2차 정규형과 같이 "이럴 때는 이렇게 해야 한다."라는 명확한 기준을 제시해 주는 방법이 존재한다.

객체지향에도 위와 같은 기틀인 SOLID 5 가자 설계 원칙이 있다.

SOLID 원칙은 객체 지향 설계를 할 때에 명확한 기준을 제공하는데, 이런 규칙은 경험이 없어도 좋은 프로그램 설계를 할 수 있도록 도와준다.

단일 책임 원칙 (Single responsibility principle; SRP)
개방-폐쇄 원칙 (Open-closed principle; OCP)
리스코프 치환 원칙 (Liskov substitution principle; LSP)
인터페이스 분리 원칙 (Interface segregation principle; ISP)
의존 역전 원칙 (Dependency inversion principle; DIP)

이번에는 이 다섯 가지 원칙들을 공부한 것을 정리해 보자

1. 단일 책임 원칙 (Single responsibility principle; SRP)

첫 번째는단일 책임 원칙이다.

"클래스는 단 한개의 책임을 가져야 한다."

단일 책임 원칙은 다섯 가지 원칙 중에서 가장 중요한 원칙인데, 객체 지향의 기본은 하나의 책임을 객체에게 할당하는 데에 있기 때문이다. 따라서 이 원칙이 지켜지지 않을 경우 다른 원칙을 지켜도 무용지물이 될 수 있다.

단일 책임의 원칙을 지키는지, 지키지 않는 지를 구분하려면 지키지 않았을 때에 일어나는 현상에 대해 알아야 합니다.

만약 하나의 클래스가 하나의 임무를 담당하지 않고 여러 가지의 임무를 담당한다면 어떻게 될까?

먼저 실수할 만한 상황을 가정하여 의도적으로 하나의 클래스에 두 임무를 부여해 보자.

"HTML 프로토콜을 이용하여 데이터를 불러와 화면에 보여주자."

public class DataViewer {

    public void display(){
        String data=getHtmlData();
        updateUi(data);
    }
    public String getHtmlData(){

        HttpClient client=new HttpClient();
        client.connect();
        String string=client.getResponese();
        return string;

    }
    private void updateUi(String data){
        ui.changeData(data);
    }
}

데이터를 화면에 보여주기 위해서는 먼저 데이터를 불러와야 한다.

데이터를 html으로 받아오는 행동이 선행되어야 하기 때문에 무심코 DataViewer 클래스에 데이터를 가져오는 메소드를 작성하는 실수를 할 수 있다. 아직 까진 문제가 되지 않는다.

하지만 이러한 상황에서 http 통신을 socket통신으로 바꾸게 된다면, 또 이 여파로 데이터 타입 또한 byte로 바뀐다면 어떻게 될까?

클래스 내부에는 display와 getHtmlData가 String 타입으로 묶여 있다. 또한 display와 updateUi가 String으로 묶여 있다.

따라서 모든 데이터 타입을 바꿔 주어야 한다.

public class DataViewer {

    public void display(){
        byte[] data=getHtmlData(); //변경 1: 바이트 타입으로 변경
        updateUi(data);
    }
    public byte[] getHtmlData(){

        SocketClient client=new SocketClient(); //변경 2: 소켓으로 변경
        client.connect(server,port);
        byte[] bytes=client.getResponese();//변경 3: 통신 방식 변경의 여파로 byte 타입으로 변경.
        return bytes;

    }

    private void updateUi(byte[] data){//변경 4: 매개변수 타입 변경.
        ui.changeData(data);
    }
}

통신 방식 하나만 달라져도 데이터 타입이 바뀌며 그 여파로 많은 메소드들도 바꾸어야 한다. 더 복잡한 구조로 되어 있다면 바꾸어야 할 코드들이 훨씬 많을 것이다.

따라서 서로 영향을 받지 않아야 할 책임들이 영향을 받게 된다.

이러한 문제점을 고치려면 서로 다른 책임을 다른 클래스에 작성하여 분리하고, 양쪽 모두 데이터의 변화에 유연하게 데이터를 적절한 타입으로 추상화 한다면 해결할 수 있다.

이렇듯 서로 다른 책임이 다른 클래스로 분리 되어 있다면 변경이 일어났을 때 서로 영향을 주지 않게 된다.

하지만 경험이 부족한 프로그래머는 단일 책임 원칙을 처음부터 잘 지키기 어렵다. 이러한 문제점을 잘 파악할 수 있는 방법은 무엇일까?

메소드를 실행시키는 것이 누구인지 파악하면 됩니다.

클래스의 사용자들이 서로 다른 하나의 메소드만을 사용한다면 다른 책임에 속할 가능성이 높다. 따라서 분리를 고려해 볼 대상이 된다.

2. 개방-폐쇄 원칙 (Open-closed principle; OCP)

두 번째는 개방 폐쇄 원칙 이다.

개방 폐쇄 원칙의 설명은 다음과 같은데,

"확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다."

좀 더 쉽게 풀이하자면

기능을 변경하거나 확장할 수 있다.

그 기능을 사용하는 코드는 수정하지 않는다.

말이 조금 어렵지만, 우리는 이미 Interface를 사용하는 이유 에서 이러한 원칙을 해본 적이 있다.

인터페이스를 사용하는 이유

여기서 DataProvider라는 interface를 상속 받은 American과 Chinese는 서로 다른 기능을 하고, 서로 다른 타입이지만 DataProvider라는 같은 타입으로 묶을 수 있다.

따라서 Main에서 사용하는 메소드가 getData()인 것은 바뀌지 않는다

또한 DataProvider를 상속 받아 다른 기능인 Japanese를 확장할 수 있으며, 마찬가지로 Main에서 사용하는 메소드가 getData()인 것은 바뀌지 않는다.

따라서 확장에는 열려 있고, 변경에는 닫혀 있는 상태라고 할 수 있다.

개방 폐쇄 원칙을 지키는 또 다른 방법은 상속을 이용하는 방법이 있다.

"파일을 보내는 기능을 작성해 보자"

파일을 보내는 클래스를 미리 작성했다고 가정해 보자.

public class DataSender {
    private Data data;
    public DataSender(Data data){
        this.data=data;

    }

    protected void sendData(){
        //data sending
    }

}

위의sendData 메소드는 protected로, 확장 가능성이 있다고 명시 되어 있다.

따라서 DataSender 클래스를 상속 받는 클래스는 sendData를 이용하여 기능을 확장할 수 있다.

따라서 압축을 하여 보내는 기능이 필요하다고 느낄 때, 우리는 밑과 같이 클래스를 작성할 수 있다.

public class ZippedDataSender extends DataSender{

    public ZippedDataSender(Data data) {
        super(data);
    }

    @Override
    protected void sendData(){
        //zip data
        super.sendData();

    }
}

위의 클래스 DataSender의 입장에서 살펴 보면 확장에는 열려 있고 (protected void sendData is Overrode by ZippedDataSender)

변경에는 닫혀 있는(DataSender를 사용하는 클래스는 변경하지 않아도 된다.) 상태가 된다.

또한 데이터를 압축한 후 보내기는 데이터 보내기이다.이기 때문에 IS-A도 성립하게 된다.

3. 리스코프 치환 원칙 (Liskov substitution principle; LSP)

상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

리스코프 치환 원칙은 개방 폐쇄 원칙을 받쳐 주는 다형성에 관한 원칙을 제공한다.

다형성이란?

한 객체가 다양한 형태를 가질 수 있는 성질을 의미한다.

전 시간에 해 보았던 인터페이스를 상속한 객체가 인터페이스 타입으로 인스턴스 생성이 가능한 추상화나, 부모 클래스의 타입으로 자식 클래스를 생성 가능하게 하는 상속 등이 다형성에 속한다.(또한 오버로딩 등 많은 다형성이 있습니다.)

따라서 상위 타입을 하위 타입으로 치환하는 리스코프 치환 원칙은 상속의 다형성에 관한 것이고, 개방 폐쇄 원칙과 관련하여 이를 보완해 주는 원칙이다.

개방 폐쇄 원칙에서 추상화 또는 상속으로 여러 타입을 가질 수 있게 된 객체는 반드시 상위 타입의 객체를 가지며, 마찬가지로 상위 타입의 객체는 하위 타입의 객체를 가지게 된다.

이러한 상황에 상위 타입의 코드로 이루어진 메소드에서 하위 타입으로 대신해도 메소드에는 아무 문제가 없어야 한다는 의미다.

public class SuperClass {
    public void someMethod(){
        System.out.println("it is SuperClass");
    }
}

위 클래스를 상속받는 subClass를 생성해 보자.

public class SubClass extends SuperClass{
    public void childMethod(){
        System.out.println("it is SubClass");
    }
}

public class Main {
    public static void main(String[] args){

        printing(new SuperClass());

        //인스턴스를 변경해도 printing 메소드는 정상적으로 작동함.
        printing(new SubClass());


    }

    public static void printing(SuperClass instance){

        //이 메소드는 무조건 it is SuperClass를 출력해야 한다.
        instance.someMethod();

    }

}

위의 코드에서 printing 메소드는 SuperClass 타입을 매개변수로 받는다. 또한 printing 메소드의 임무는 무조건 it is SuperClass를 출력해야 한다.

SubClass는 자체적으로 childMethod라는 메소드도 가지고 있지만, SuperClass의 someMethod라는 메소드를 상속 받아 가지고 있기 때문에 부모 타입으로 생성 되어도 someMethod라는 메소드를 실행하는데 아무런 문제가 없다!

따라서 위는 리스코프 치환 원칙을 지키는 코드라고 할 수 있다.

결과:

하지만 위의 상속의 예에는 맞지만 리스코프 치환 원칙을 어기는 상황이 있다.

대표적인 예로 원-타원 문제(Circle-ellipse problem) 가 있다.

이는 리스코프 치환 원칙의 계약에 관한 내용을 잘 설명해 준다.

원-타원 문제?

[객체 지향과 디자인 패턴] 인터페이스를 작성하는 이유

Wed, 13 Apr 2022 16:36:47 GMT

개요

저는 평소에 인터페이스를 자주 사용하지 않습니다. 보통 작은 프로젝트를 만들기 때문에 제가 생각한 대로, 설계한 대로 만들면 콘크리트 클래스만 만들어도 문제가 없기 때문입니다.

또한 기획의 일부가 바뀌게 되어도 별로 큰 타격을 입지 않는데, 클래스를 사용한 위치, 사용하는 이유 등등 명확히 알고 있기 때문이죠.

하지만 여러 사람이 하나의 프로젝트를 만들 때는 이야기가 다른 것 같습니다. "이렇게 만듭시다."라고 모두에게 말하면 모두 똑같이 이해하고 만들기 힘들죠!

혹은 변경 점이 생겼을 때 남이 만든 코드의 변경된 클래스 사용처를 알 수 있을까? 그리고 그것을 잘 고칠 수 있을까? 이런 의문들도 함께 남습니다.

위에서 얘기한 문제점 두 가지는 협업 때의 규약의 부재와 변경의 유연성 부재 라고 생각합니다. 우리는 이 것을 인터페이스로 해결할 수 있죠!

해결하기에 앞서 먼저 한 상황을 가정해 봅시다.

"우리는 서버로부터, 혹은 로컬에서 데이터를 가져오는 시스템을 만들라는 명령을 받았다. 우리 팀에는 미국인과 일본인 동료가 있다. 두 분은 매우 뛰어난 베테랑 프로그래머이지만, 난 불행하게도 일본어, 영어 모두 못한다. 이들에게 각각 로컬 데이터 받아오기, 서버 데이터 받아오기를 시키려고 한다. 어떻게 해야 할까?"

규약의 부재

인터페이스는 내용은 없고 형식만 있는 형태입니다. 그렇기에 다른 클래스로 implement를 하여 내용을 작성해야 완성되죠. 일단 미국인 동료에게 시킬 데이터베이스에서 데이터 가져오기를 interface로 작성해 봅시다.

public interface DataProviderWithDataBase {
    abstract int getDataFromDataBase();
}

자 이제 이 interface를 미국인 동료의 클래스에 implement시켜 봅시다. implement는 한글로 "시행하다" 즉, 무언가를 시행하라고 명령하는 것이기에 인터페이스는 implement를 한 클래스에게 자신에게 정의된 메소드, 필드 껍데기의 구현을 강제하게 됩니다.

(implement를 해 놓고 구현을 하지 않으면 이렇게 에러 메시지를 띄운다.)

이렇게 강제하게 되면 DataProviderWithDataBase 안에 있는 getDataFromDataBase 메소드를 구현해야(재정의 해야) 에러 메시지가 없어 집니다. Implement methods를 누르거나, 혹은 Alt+Shift+Enter를 눌러 메소드를 재정의 해 봅시다.

자 이제 에러는 사라졌으며, interface 안에 있던 구현해야 할 메소드가 보입니다. 베테랑 프로그래머인 미국인 동료는 자신이 해야 할 일을 메소드의 이름을 통해 단번에 알아차렸고, 그는 구현을 시작할 것입니다.

마찬가지로, 일본인 동료도 똑같이 interface를 만들어 줍시다.

public interface DataProviderWithServer {
    abstract int getDataFromServer();

}

자. 이제 그도 일을 시작할 것입니다.

유연성의 부재

자 모두 해결한 것 같습니다. 일단 이들이 구현한 클래스로 데이터를 받아 와 봅시다!

public int getData(Boolean isServer){
    if (isServer){
        American american=new American();
        return american.getDataFromDataBase();
    }
    else{
        Japanese japanese=new Japanese();
        return japanese.getDataFromServer();
    }
}

두 부분을 구분하기 위해 Boolean자료형을 이용하여 구현하였습니다. 하지만 무언가 찜찜 합니다.

마침 위에서 기획을 바꾼다고 지시가 내려왔습니다. 다른 곳에서도 데이터를 받아와야 한다고 하는데, 이번에는 중국인 동료가 있습니다.. 또 인터페이스를 작성해야 할까요..?

곰곰히 생각해 보면 사실 이 세 부분에서 데이터를 받아 오는 것은 공통점이 존재합니다. 바로 "데이터를 받아온다" 라는 것으로 묶을 수 있다는 것이죠! 이 개념적인 것을 interface로 뽑아 봅시다.

public interface DataProvider {
    abstract int getData();
}

각각 DataProviderWithDataBase, DataProviderWithServer로 나누어 졌던 것을 DataProvider로 한 곳으로 모았습니다. 그리고 getData라는 추상 메소드로 통합하였죠. 또한 중국인 동료에게 줄 추가될 인터페이스도 데이터를 가져 온다는 것으로 구현을 할 수 있기 때문에 일맥상통합니다.

자 이제 세 동료 모두에게 이 interface를 implement 시켜 구현하도록 부탁해 봅시다.

자, 다들 자신의 임무에 알맞게 구현을 해왔습니다.

먼저 우리는 각각 다른 interface로 각각 다른 class를 구현하였고, 각각의 class로 instance를 생성하여 method를 실행시켜 return 하였는데요.

하지만 이번엔 하나의 interface로 통합 시킨 후 각각의 class를 구현하였습니다. 제가 자주 까먹는 것이 있는데, 굳이 자신의 class 타입으로 instance를 생성하지 않아도 된다는 겁니다!

implement 혹은 extend를 한 class는 상위 class, 혹은 interface의 타입으로 instance를 생성할 수 있다는 것이죠. 여기서 interface의 장점이 나옵니다.

즉, 위의 DataProvider로 구현한 class 세 개는 DataProvider의 타입으로 통합할 수 있습니다.

public int getData(int flag){

    DataProvider provider = null;
    if(flag==Flag.GET_FROM_SERVER){
        provider=new American();
    }
    else if(flag==Flag.GET_FROM_OTHER_SERVER){
        provider=new Chinese();
    }
    else if(flag==Flag.GET_FROM_DATABASE){
        provider=new Japanese();
    }

    //변하지 않는 곳.
    if(provider!=null){
        return provider.getData();
    }
    else{
        throw new NullPointerException();
    }

}

public class Flag {
    GET_FROM_SERVER, GET_FROM_OTHER_SERVER, GET_FROM_DATABASE
}

3개의 선택지로 바뀌었으니 Boolean으로 구분 하던 것을 int로 바꾸어 주었고, 구분을 쉽게 하기 위해 Flag라는 클래스를 새로 만들어 그 안에 flag를 넣어 주었습니다.

또한 기존에 있던 함수에도 변화가 생겼는데, 데이터를 제공하는 클래스의 타입이 interface인 DataProvider로 변경 되었습니다.

미국인, 일본인, 중국인 동료 각각 메소드의 내용을 따로 작성하였어도, 메소드의 이름이 모두 같기 때문에 interface 타입으로 메소드를 실행 시켜도 아무 문제가 없습니다.

또한 할당한 객체에 따라 같은 타입이어도 다른 행동을 하는 메소드를 실행시킬 수 있게 됩니다!

그리고 변하지 않는 부분이 생겼기 때문에 새로운 방법으로 데이터를 가져오는 로직이 생겨도, 바꾸는 코드는 줄어들게 되었죠!

좀 더 다듬는 방법은 팩토리 메소드 패턴을 이용하여 DataProvider의 생성을 따로 작성할 수 있습니다. 밑과 같이 하면 클래스 간의 연결성이 더욱 떨어집니다.


public class DataProviderFactory {
    private static DataProviderFactory instance;
    private DataProviderFactory(){

    }
    public static DataProviderFactory getInstance(){
        //싱글톤 패턴 적용
        if(instance==null){
            instance=new DataProviderFactory();
        }
        return instance;
    }

    public DataProvider getDataProvider(Flag flag){
        DataProvider provider=null;
        if(flag==Flag.GET_FROM_SERVER){
            provider= new Japanese();
        }
        else if (flag==Flag.GET_FROM_DATABASE){
            provider= new Chinese();
        }
        else if(flag==Flag.GET_FROM_OTHER_SERVER){
            provider= new American();
        }
        return provider;


    }

}

위의 코드의 양 만으로 보아선 간단해 지지 않았습니다. 코드의 양이 더욱 늘었죠. 하지만 더욱 많은 상황을 떠올려 보면 장점이 더욱 부각 됩니다.

만약 DataProvider가 여러 곳에서 참조해야 하는 상황이 생겼다면?

이 전의 구현에서는 객체 타입이 서로 다르기 때문에 참조하는 곳 마다 if, else를 달아 주어야 될 것이고, 새롭게 데이터를 받아오는 로직이 생기면 또 if를 달아 주어 코드의 양이 기하급수적으로 늘어날 것 입니다.

따라서 DataProvider 하나로 통합하면, 각각 다른 경로로 데이터를 받아오는 메소드를 단 하나의 타입으로 모두 수행할 수 있게 되죠!

이 뿐만 아니라, 이 인터페이스 타입을 사용하는 측에서도 이익이 있습니다.

interface가 먼저 구현이 되지 않아도, interface 타입을 사용하는 쪽에서 자신의 로직을 테스트 할 수 있게 됩니다. 하드 코딩을 통해서 임시로 interface를 구현하는 것이죠.

public int process(){
    MockDataProvider mock=new MockDataProvider();
    //test logic
    int data= mock.getData();
    data-=1000;
    return data;
}


class MockDataProvider implements DataProvider{

    @Override
    public int getData() {
        //hard coding
        int itIsTestData=99999;
        return itIsTestData
    }
}

이렇게 모두 생산성에 이익을 보며 같이 작업할 수 있게 됩니다.

이번에는 interface의 사용처에 대해서 알아보았습니다. 큰 프로젝트 경험은 없지만, 이렇게 간접적으로 문제를 해결해 나가며 다음에도 작성해 보겠습니다.

틀린 부분이 있다면 적극 반영하겠습니다. 감사합니다!

(이 포스팅은 책 "객체 지향과 디자인 패턴"을 읽고 재구성한 글 입니다.)