class Cafe {
fun buyCoffee(cc: CreditCard): Coffee {
val cup = Coffee()
cc.charge(cup.price)
return cup
}
}
class CreditCard {
fun charge(price: Int) {
TODO("신용카드사에 결제 요청")
}
}
data class Coffee(val price: Int = 4500)
buyCoffee 메소드는 커피를 만들고 신용카드사에 결제를 요청하고, 커피를 반환한다.
카드를 통해 결제하면 카드사의 외부시스템으로 요청을 보내야한다. 여기서 부수효과가 발생한다. 이 코드로 테스트를 한다면 매번 실제 외부 시스템의 요청을 해야하므로, 테스트 하기가 어려워진다.
설계를 바꿔 테스트 성을 높일 수 있다. CreditCard가 신용카드사에 접속해 비용을 청구하는 방법을 모르게 하면 된다.
class Cafe {
fun buyCoffee(cc: CreditCard, p: Payments): Coffee {
val cup = Coffee()
p.charge(cc, cup.price)
return cup
}
}
class Payments {
fun charge(creditCard: CreditCard, price: Int) {
TODO("신용카드사에 결제 요청")
}
}
data class CreditCard(val serial: String, val company: String)
data class Coffee(val price: Int = 4500)
Payments라는 클래스를 새로 추가해서, 비용을 청구하는 방법은 Payments 클래스가 알고있도록 변경했다. Payments를 인터페이스로 만들고 Mock Payments를 만들어서 테스트를 할 수 있다.
하지만 여전히 p.charge를 통해 외부 세계와 상호작용하고 있기 때문에 부수효과는 존재한다
그리고 Mock을 작성하는 것도 이상적이지는 않다. 구체화된 클래스 하나로 충분할 수도 있는데 불필요하게 인터페이스를 만들어야한다.
Mock 구현도 불편한 부분이 있다. 예를 들어 charge를 호출 한 후 이 상태가 제대로 변경되었는지를 검사해야하는 로직이 필요하기도 하고, buyCoffee를 호출하고 이를 살펴볼 수 있는 내부 상태가 필요할 수도 있다.
이런 세부 사항들을 프레임워크를 통해 처리하게 할 수 있지만 비용 청구 테스트만을 위해 프레임워크까지 사용하는 것은 오버일 수 있다.
그리고 재사용하기도 어렵다.
여러잔의 커피를 구매하면, 개수만큼 신용카드사에 요청이 발생한다. 각 요청마다 수수료가 있다면 모든 주문을 모아 한 번만 요청하는 것이 이상적이다.
1.1.2 부수효과 제거하기
부수효과가 있는 상황
부수효과가 없는 상황
buyCoffee 안에서 청구를 하는 게 아니라 청구 정보를 커피와 같이 리턴하여 청구 정보는 다른 곳에서 처리하도록 바꾼 것이다.
class Cafe {
fun buyCoffee(cc: CreditCard): Pair<Coffee, Charge> {
val cup = Coffee()
return cup to Charge(cc, cup.price)
}
}
data class Charge(val cc: CreditCard, val amount: Int) {
fun combine(other: Charge): Charge = if (cc == other.cc) Charge(
cc,
amount + other.amount
) else throw Exception("Cannot combine charges to different cards")
}
data class CreditCard(val serial: String, val company: String)
data class Coffee(val price: Int = 4500)
이렇게 금액 청구를 만드는 관심사와 청구를 처리하는 관심사를 분리했다.
같은 CreditCard의 청구 정보를 하나로 만들 때 편리하게 쓸 수 있는 combine 함수도 정의하였다.
val charge1 = cafe.buyCoffee(cc)
val charge2 = cafe.buyCoffee(cc)
charge1.combine(charge2)
이런식으로 사용할 수 있다.
이제 커피 n잔을 주문할 수 있는 buyCoffees를 만들어보자.
class Cafe {
fun buyCoffee(cc: CreditCard): Pair<Coffee, Charge> {
val cup = Coffee()
return cup to Charge(cc, cup.price)
}
fun buyCoffees(cc: CreditCard, n: Int): Pair<List<Coffee>, Charge> {
val purchases = List(n) { buyCoffee(cc) }
val (coffees, charges) = purchases.unzip()
return coffees to charges.reduce { c1, c2 -> c1.combine(c2) }
}
}
이렇게 작성할 수 있다.
List(n) { buyCoffee(cc) }를 하면 List<Pair<Coffee, Charge>>가 만들어진다.
unzip()를 하면 Pair<List<Coffee>, List<Charge>> 가 반환된다.
그리고 구조분해를 통해 coffees => List<Coffee>, charges => List<Charge>가 각각 할당된다.
그 다음 reduce를 통해 charges의 값들을 combine한다.
이제 buyCoffees를 정의할 때 buyCoffee를 재사용할 수 있었고, 관심사를 분리하였기 때문에 굳이 Payments 인터페이스와 mock 을 정의하지 않아도 쉽게 테스트할 수 있다.
실제 금액 청구는 Payments 같은 클래스가 필요하겠지만 Cafe 클래스는 Payments를 몰라도 된다.
우리는 Charge를 일급 객체(First-class value)로 만들었다. 일급 객체로 만들면 청구 금액을 처리하는 비지니스 로직을 더 쉽게 조립할 수 있다는 장점이 생긴다.
➤ 일급 객체란 다음 3가지 조건을 만족하는 객체이다.
다른 변수나 데이터에 담을 수 있어야한다.
함수의 파라미터로 전달될 수 있어야한다.
함수의 반환값으로 사용될 수 있어야한다.
일급 객체이기 때문에 일련의 Charge List가 있을 때 같은 카드에 청구하는 금액을 모두 합치는 로직을 쉽게 작성할 수 있다.
이렇게 하여 사용한 신용카드에 따라 그룹으로 나누고 각 그룹의 청구금액을 하나로 합친 Charge List를 만들어낸다.
fun main() {
val cc1 = CreditCard("1234", "K")
val cc2 = CreditCard("2345", "H")
val cc3 = CreditCard("3456", "W")
val chargeList = listOf(
Charge(cc1, 3000),
Charge(cc2, 4000),
Charge(cc3, 5000),
Charge(cc2, 3800),
Charge(cc2, 4500),
Charge(cc1, 4000),
Charge(cc1, 5500)
)
val result: List<Charge> = chargeList.coalesce()
}
이런식으로 사용할 수 있고 그림으로 보면 다음과 같다.
1.2 순수 함수란?
정확하게 순수함수를 정의해보자. 형식적(제한된 단어를 사용해서 엄격하고 정확하게 기술)인 정의이다.
앞에서 함수형 프로그래밍은 순수함수를 이용해 프로그래밍 하는 것이라 했다. 그리고 순수함수란 부수효과가 없는 함수라고도 했다.
입력이 A이고 출력이 B인 함수 f가 있다고 하자. 코틀린에서는 (A) -> B 이렇게 쓴다.
A 타입이 될 수 있는 모든 값 a 를 B 타입이 될 수 있는 모든 값 b에 매핑해주는 계산이다. b값은 a값에 의해서만 결정이된다. f(a) = b의 식에서 내부, 외부의 상태 변경은 결과에 영향을 끼치지 못한다.
*의문점 내부의 상태 변경은 영향을 끼칠 수 있는 것 아닌가? a값과 연관이 없는 내부의 상태변화를 이야기 하는 것인가?
이러한 정의에 따른 순수함수의 예시는 +(plus)연산과 String.length() 연산이 있다. plus의 경우 두 정수가 주어지면 항상 같은 결과값을 반환한다. Java, Kotlin의 String은 불변 객체이기 때문에 주어진 문자열에 대해 "string".length()를 호출하면 항상 같은 결과가 반환된다. "string"라는 리터럴은 변할 수 없기 때문이다.
불변 객체란? 객체의 내부 프로퍼티를 변경할 수 없는 객체이다. 예를 들어
var str = "Hello"
str = "World"
이렇게 변수를 변경한다고 해도, Hello라는 String 인스턴스의 값이 World로 변경된 것이 아니라.
Hello라는 인스턴스는 그대로 있는 상태에서 World라는 인스턴스가 새로 생성되고, str의 참조값이 바뀌는 것이다.
순수함수의 개념을 참조 투명성(RT; Referential Transparency)의 개념을 이용해 형식화 할 수 있다.
참조 투명성이란?
예를 들어 2+3 이라는 식이 있을 때, 프로그램 안에서 2+3이라는 식을 모두 5로 치환할 수 있고, 그렇게 해도 프로그램의 의미가 전혀 변하지 않는다.
어떤 식이 "참조 투명하다"라고 말하는 것은 프로그램의 의미를 변경하지 않으면서 식을 그 결과값으로 치환할 수 있다는 것이다.
참조 투명한 인자를 사용해 호출한 함수의 결과가 참조 투명하다면 이 함수도 참조 투명하다.
형식화된 정의
어떤 식 e에 대해, 모든 프로그램 p에서 e를 e의 결과값으로 치환해도 p의 의미에 변화가 없다면 e는 참조 투명하다. 어떤 함수 f가 있을 때, 참조 투명한 x에 대해 f(x)가 참조 투명하다면 함수 f도 참조 투명하다.
∴ 참조 투명한 함수를 순수함수라고 한다.
1.3 참조 투명성, 순수성, 치환 모델
어떤 함수가 참조 투명하다면, 함수를 함수의 결과값(반환값)과 치환할 수 있다고 했다.
우리가 가장 처음에 봤던 부수효과가 있는 buyCoffee 함수를보자.
fun buyCoffee(cc: CreditCard): Coffee {
val cup = Coffee()
c.charge(cup.price)
return cup
}
이 함수는 cc.charge()의 결과와는 상관없이 cup을 반환한다.
참조 투명성에 정의에 의해 buyCoffee가 순수함수가 되려면 모든 프로그램 p에 대해서 buyCoffee를 Coffee()로 치환할 수 있어야한다. 하지만 p(buyCoffee())는 p(Coffee())와 같지 않다. charge를 하지 않기 때문이다.
이렇게 단순히 치환된다고 참조 투명성이 있는 것이 아니다.
함수가 수행하는 모든 일이 함수의 반환 값에 의해 표현되어야 한다.
이런 제약이 있을 때 참조 투명성이 있다고 할 수 있고, 치환 모델을 통해 프로그램 추론이 쉬워진다. * 치환 모델을 사용한다는 건 함수를 함수의 결과값으로 치환해서 계산한다는 것이다.
참조 투명성이 확보되면 우리가 대수 방정식을 푸는 것처럼 코드를 읽을 수 있다.
* 대수방정식은 미지수(x, y..)가 포함된 식을 말한다. 4x - 6 = 10 ⇢ ⓵ 2y + 3x = 16 ⇢ ⓶ 1번 식을 통해 x=4라는 답이 나왔다. 그럼 2번 계산에서 x를 4로 치환해서 계산해도 전혀 문제가 없다.
코드를 통해 치환 모델의 예시를 살펴보자.
1. 참조 투명한 식에 치환 모델 적용
위에서 말한대로 코틀린의 String은 불변객체이다. 문자열에 +를 하거나, reversed()를 하거나 문자열은 변경되지 않는다. 새로운 문자열 인스턴스가 할당될 뿐.
val x = "Hello, World"
val r1 = x.reversed() // dlroW ,olleH
val r2 = x.reversed() // dlroW ,olleH
치환 모델을 사용해보자. 즉, x를 "Hello, World"로 치환해보자는 뜻이다.
val r1 = "Hello, World".reversed() // dlroW ,olleH
val r2 = "Hello, World".reversed() // dlroW ,olleH
프로그램에 아무 영향이 없다. x가 참조 투명하기 때문이다. 그리고 x가 참조 투명하기 때문에 r1, r2 도 참조 투명하다.
2. 참조 투명하지 않은 시에 치환 모델 적용
val x = StringBuilder("Hello")
val y = x.append(", World")
val r1 = y.toString() // Hello, World
val r2 = y.toString() // Hello, World
StringBuilder는 String과 달리 객체 내부의 상태를 변경한다.
현재 코드에서는 r1, r2가 같다 하지만, y를 치환한다면 어떻게 될까?
val x = StringBuilder("Hello")
val r1 = x.append(", World").toString() // Hello, World
val r2 = x.append(", World").toString() // Hello, World, World
r2의 값이 할당되는 시점에 x의 값이 변경되었기 때문에 다른 결과가 나왔다. 따라서 append는 순수함수가 아니라고 할 수 있다. 그리고 이런 코드는 추론하기가 힘들다.
치환 모델을 사용하면 식이나 코드를 추론하기 더 쉬워진다. "x가 여기선 어떻게 변경되고 다음 상태에선 어떻게 되겠지" 이런 시뮬레이션을 안해도 된다.
지속 가능한 열정을 만들 수 있기 때문입니다. 평소 호기심이 많은 편이라 디자인, 공예, 패션, 심리학 등 여러 분야에 관심이 많습니다. 그중에서도 개발은 5년 이상 지속할 수 있던 취미이자 일이었습니다.
개발은 즐거움도 있었지만, 정신적인 피로와 많은 공부량 등 힘든 점도 많습니다. 그럼에도 지속할 수 있었던 이유는 성취감입니다.
"CPU는 0과 1만을 처리하는데 어떻게 화면을 표시하는 걸까", "내가 보낸 메시지는 어떻게 미국까지 가는 걸까" 같은 막연한, 마법 같던 지식의 안개가 걷히는 순간에 성취감과 이렇게 얻은 지식을 다른 사람들에게 설명하고 공유함으로써 나오는 성취감이 열정을 다시 만들어주었습니다. 또한 오류가 발생했을 때, 발생 원인을 파악하고 레거시 코드는 왜 이렇게 작성했을까 생각하며 기술적인 해결에 도달했을 때의 성취감 역시 이 일을 지속 가능하게 만들어 주었습니다.
그리고 이렇게 성취한 지식이 저의 궁극적인 성장에 도움이 된다는 점이 좋았습니다. 기술적인 지식뿐만 아니라 팀원들과 대화하는 능력, 설명하는 능력 그리고 코드에 담긴 의미와 속 뜻을 알아내는 과정이 소프트 스킬 향상에도 도움이 되었습니다.
팀 네이버에서는 레거시 코드를 분석하고 개선하는 경험을 통해 그리고 동료들과의 협업을 통해 성장하고 싶습니다. 네이버는 24년간 많은 사용자를 대상으로 서비스해 온 기업입니다. 그 간의 경험이 들어있는 코드를 통해 과거의 기술과 현재 기술 차이점을 배우고, 더 좋은 방향으로 개선하면서 성장하고 싶습니다. 그리고 적극적인 개발자들이 많은 환경이 큰 성장 동력입니다. 동료들과의 활발한 협업 및 스터디, DEVIEW 같은 콘퍼런스에서 발표하는 경험을 통해 성장하고 싶습니다.
2번 문항
네이버 커넥트재단 부스트캠프에서 했던 RightWeight라는 프로젝트가 있습니다. 운동 루틴을 생성하고, 기록하고, 공유할 수 있는 안드로이드 어플입니다.
데이터 구조를 보면 특정 날에 여러 가지 운동, 한 운동에 여러 세트 수가 중첩되어 있는 구조입니다. Json으로 보면 다음과 같습니다. "routine" : { "day1" : {...}, "day2" : {...}, "day3" : { "exercise1" : {...}, "exercise2" : { "set1": {} } } }
이런 복잡한 데이터 구조 때문에 몇 가지 문제가 발생하였습니다.
1. 데이터 저장소 선택 파이어 베이스의 Realtime DB와 Firestore 중에 무엇을 선택할지 문제였습니다. Realtime DB를 사용하면 간단히 데이터 저장이 가능하지만, 데이터가 커질 수 있고, depth가 깊어진다는 문제가 있었습니다. 또한 Recycler View에서 제목 정도만 보여주려 해도 모든 정보를 가져와야 했습니다. 이에 반해 Firestore는 NoSql로 document 컬렉션으로 저장되기 때문에 필요한 정보만 컬렉션 단위로 가져올 수 있고, Paging 처리를 위한 인덱싱도 지원하기 때문에 Firestore를 선택했습니다.
2. 트랜잭션 처리 팀에서 Firebase를 SDK가 아니라 REST API 방식으로 사용했습니다. 운동 루틴 하나를 삭제하려면, 루틴 안에 있는 모든 day, exercise, set에 대한 삭제 쿼리를 요청해야 했습니다. 루틴이 커질수록 쿼리가 많아지고, 중간에 네트워크가 끊긴다면 데이터의 일부만 남아있는 상태가 될 수도 있습니다. REST API 방식의 Transaction 처리에 관한 문서의 부재로 해결하지 못했습니다. 최종적으로는 runQuery라는 쿼리를 모아서 요청하는 방식을 사용했지만, 이 역시 네트워크가 끊길 시 같은 문제가 발생합니다. SDK를 사용하거나, 별도의 서버를 두었다면 이러한 문제에 더 쉽게 대응할 수 있지 않았을까 아쉬움이 남았습니다.
3번 문항
Android
사용자에게 가장 가까운 분야이고 클라이언트 분야 중에서도 휴대폰의 성능과, 디자인, 터치 인터페이스의 사용성까지 고려해야 한다는 점에서 흥미를 느꼈습니다. 또한 자바, 코틀린 언어를 사용하여 객체지향적인 코드를 작성할 수 있다는 점도 매력적이었습니다.
Java에 대한 이해도가 높습니다. Java에 대한 스터디를 진행하며 객체 지향의 장정, 특징은 무엇인지, 컴퓨터에서는 어떻게 자원이 할당되고 실행되는지 등 지식이 언어에 한정되지 않도록 했습니다. 언어와 함께 JVM도 공부하며, 자바 코드가 어떻게 바이트코드로 변환되어 어느 메모리에 할당되고, 어떻게 실행되는지와 Garbage Collection도 함께 공부하였습니다. 안드로이드 OS도 JVM 기반의 ART를 사용하기 때문에 Java에 대한 지식이 안드로이드를 더 쉽게 이해할 수 있게 도와주었습니다. 이런 추상적인 사고방식 덕분에 자바에서 코틀린으로 빠르게 전환할 수 있었습니다.
'지역 XR 챌린지'라는 공모전에서 AR 내비게이션 앱으로 수상한 경험이 있습니다. 해당 프로젝트에서는 Lane Detection 을 하기 위해 OpenCV를 사용해야 했습니다. 카메라 정보를 서버로 보내면 레이턴시가 생기기 때문에 Android NDK로 C++을 사용하여 기기 안에서 처리하도록 구현했습니다. 완성한 프로젝트는 플레이스토어를 통해 배포하였습니다.
네이버 커넥트재단 부스트캠프 웹・모바일 7기 과정, 안드로이드 분야를 수료하였습니다. 부스트캠프의 팀 프로젝트에서 1주일 단위로 스프린트 계획을 세우고, 매일 스크럼을 통해 진행 상황을 공유하고, 페어 프로그래밍을 하며 문제를 해결해보는 경험을 했습니다. 프로젝트는 MVVM 아키텍처로 앱을 구성하였고, 서버에서 가져오는 정보는 Paging과, Room을 사용해 로컬 데이터베이스에 캐싱하여 네트워크 사용량을 줄이고 오프라인 사용성을 높였습니다. 그리고 Retrofit을 사용한 네트워크 처리, Coroutine을 사용한 비동기 처리 등의 경험을 했습니다.
4번 문항
RightWeight / 안드로이드 어플 개발 / https://github.com/boostcampwm-2022/android09-RightWeight 운동 루틴을 기록, 관리, 공유할 수 있는 서비스 역할: MVVM, Repository 패턴 적용 Toolbar, Navigation 관련 설정 타이머 Service 알림 표시 및 딥링크 설정 Room에 저장된 데이터 RecyclerView로 표시 Retrofit으로 Firebase와 통신
