'적자' 생존

'시'를 보고

weekyear — Sun, 30 Oct 2022 20:18:44 +0900

영화 전체적인 분위기가 어렸을 적의 느꼈던 동네 분위기처럼 굉장히 현실적으로 느꼈다. 이런 분위기 조성을 통해 이후 영화의 내용을 받아들이는 데 마치 실제 있는 일을 받아들이게 끔 하였다
60대 중반의 여성, 양미자의 삶을 참으로 현실적으로 담아내었다. 단 하루의 시간에도 사람은 여러 개의 모습을 드러낸다. 양미자의 경우 알츠하이머 병에 걸린 모습, 철딱서니 없는 중학생의 보호자로서의 모습, 파출부로서의 모습, 시인이 되고 싶은 모습, 투신한 여중생의 아픔을 공감하는 모습, 가해자 보호자로서 종욱이의 장래를 지키고 싶은 모습, 누군가에게든 위로받고 싶은 모습이 있다. 그 어떤 모습에서도 힘들고 괴로워하지만, 의지할 곳은 마땅히 없는 모습에서 먹먹함을 느꼈다.
많은 영화를 보지는 못 했지만, 이런 차분한 류의 영화의 끝은 항상 주인공에게 어떤 결단을 내리면서 마무리가 되는 것 같다. 양미자에게는 성폭행 사건을 경찰에 신고하고 본인 또한 사라지는 결단을 내리게 되었다. 왜 이런 결단을 내리게 되었을까? 생각해보니 양미자는 시의 시상을 성폭행 사건에서 찾게 되었고 그 과정에서 피해 학생과 본인을 동일시하고 있지 않았을까? 라는 생각을 하였다. 마지막, 시를 낭송하는 화자가 중간에 피해 학생으로 바뀌게 된 것도 그런 연출이지 않았을까 싶다.
양미자의 있는 그대로의 삶을 시로 승화하는 과정이 담긴 영화였다.

'무간도 1'을 보고

weekyear — Sun, 30 Oct 2022 20:18:09 +0900

액션이 많이 나오는 부류의 영화일 줄 알았으나 오히려 등장인물들의 치열한 신경전을 벌이면서 느껴지는 감정의 변화가 더 눈에 띄는 영화였다.
영화 초중반동안 이어지는 팽팽한 신경전은 황국장의 죽음으로 인해 커다란 국면을 맞이한다. 황국자의 죽음은 진영인에게든 유건영에게든 결단을 내리게 만드는 계기가 되고 결국 마피아 보스를 잡을 수 있게 되었다.
여기서 끝났다면 장팀장님이 추천하지 않았으리라 생각한다. 이 영화의 진면목은 진영인이 유건영의 정체를 깨닫고 유건영도 진영인이 본인이 스파이임을 알았다는 사실을 깨닫는 것에서 시작한다.
실제로 개과천선하여 경찰로 살기로 한 유건영과 착하게 살기로 마음 먹은 사실은 알 길이 없고 설사 알았다고 한들 황국장을 죽음으로 내몬 것을 용서할 수 있을리 없는 진영인… 둘의 상황이 모두 납득이 가지만 꼬일대로 꼬였고 풀 길이 없었다.
복잡한 상황은 삼합회의 또 다른 스파이의 돌발 행동으로 일단락나고 말았다. 유건영에게는 더할 나위 없이 좋은 상황이 되었겠지만, 유건영도 진영인과 원활하게 풀고 싶지 않았을까?
요즘은 영화를 다 보고나서 내 감상을 언어로 쉽게 풀지 못 하는 순간을 즐기고 있는 것 같다. 천천히 곱씹으면서 글로 풀어갈 때 재미가 있다. 무간도는 그런 영화였다.

[Kotlin] Scope function 제대로 쓰자!

weekyear — Sun, 30 Oct 2022 20:16:53 +0900

Kotlin을 써온지 이제 1년 조금 넘은 시점에서 다시 코드를 돌아보고 있자니 Scope function을 많이 활용을 하지만 적절하게 활용하고 있다는 생각이 들지 않았다. 모호한 기준으로 Scope function을 활용하고 있다고 느꼈다. 이번 Kotlin의 Scope function은 Context object와 Return value가 아닌 각 Scope function이 어디에 쓰이는지 위주로 짚어볼 예정이다.

더 자세히 들어감에 앞서서 간단한 사용 가이드는 다음과 같다.

let (1) : Non-Nullable 객체에서 람다 함수를 수행할 때
let (2) : 식을 로컬범위의 변수로 사용할 때 (오역 가능성 높음)
apply : 객체 구성할 때
run (extension) : 객체 구성과 결과값을 계산할 때
run (non-extension) : expression(식)이 필요한 statement(문)을 동작시킬 때
also : 추가로 effect가 필요할 때
with : 객체의 함수 호출을 그룹핑할 때

코틀린의 Scope Function에 대해서 빠삭하다면 위 서술로도 충분히 파악이 가능하리라 생각이 들지만 나는 그렇지 않기에 아래에 공식문서의 예시와 함께 설명해보려고 한다.

1. let : Non-Nullable 객체에서 람다 함수를 수행할 때

코틀린은 Null-Safety 언어로 Non-Nullable과 Nullabe 변수를 구분하여 사용하면서 Null-Exception 오류를 방지하고 있다. 그리고 Nullable 변수가 Null일 때 해당 객체를 사용하지 않고자 ? 연산자를 활용하고 있는데 이 때, let과 같이 활용하면 코드를 줄일 수 있다.

val str: String? = "Hello"   
//processNonNullString(str)       // compilation error: str can be null
val length = str?.let { 
    println("let() called on $it")        
    processNonNullString(it)      // OK: 'it' is not null inside '?.let { }'
    it.length
}

?.let { } 을 활용하면 코드 블록 내부에서는 str을 Non-Nullable 객체로 활용할 수 있게 된다.

2. let : 식을 로컬범위의 변수로 사용할 때

Introducing an expression as a variable in local scope 을 위와 같이 ‘식을 로컬 범위의 변수로 사용할 때’ 라고 번역하였는데 만약 틀렸다면 댓글을 달아주기 바랍니다.

코딩을 하다보면 expression(식)이 길어지게 마련이다. 해당 식으로 도출된 결과값을 여러 함수에서 활용해야할 때 let을 활용해도 좋다.

val numbers = listOf("one", "two", "three", "four")
val modifiedFirstItem = numbers.first().let { firstItem ->
    println("The first item of the list is '$firstItem'")
    if (firstItem.length >= 5) firstItem else "!" + firstItem + "!"
}.uppercase()
println("First item after modifications: '$modifiedFirstItem'")

위 코드의 2번째 줄에 있는 식(numbers.first())을 총 3군데에서 활용하는데 따로 변수로 빼놓는게 아니라 위와 같이 하나의 코드 블록에서 활용하고 결과값을 반환해서 활용할 수 있다.

3. apply : 객체를 구성할 때

기존에 활용하던 Scope function 중에서 가장 제대로 활용하고 있던 함수인 것 같다. 생성한 객체값의 필드를 바로 수정해야 할 때 활용하였다.

val adam = Person("Adam").apply {
    age = 32
    city = "London"        
}
println(adam)

4. run (extension) : 객체 구성과 결과값을 계산할 때

apply와는 반대로 공식문서에서 적어놓은 것과 가장 어긋나게 활용하고 있던 함수이다. 공식문서를 번역하자면 객체 구성과 결과값을 반환해야할 때 잘 활용된다고 한다.

val service = MultiportService("<https://example.kotlinlang.org>", 80)

val result = service.run {
    port = 8080
    query(prepareRequest() + " to port $port")
}

5. run (non-extension) : expression(식)이 필요한 statement(문)을 동작시킬 때

run은 비확장함수로 쓰일 때도 있다. 이 경우에는 여러 식이 필요한 문을 동작시킬 때 활용된다.

val hexNumberRegex = run {
    val digits = "0-9"
    val hexDigits = "A-Fa-f"
    val sign = "+-"

    Regex("[$sign]?[$digits$hexDigits]+")
}

for (match in hexNumberRegex.findAll("+123 -FFFF !%*& 88 XYZ")) {
    println(match.value)
}

6. also : 추가로 effect가 필요할 때

문맥 객체(it)를 인자로 취하는 작업에 활용하면 좋다.
문맥 객체의 프로퍼티나 함수가 아닌 그 자체의 참조가 필요한 작업에 좋다.
이 참조를 외부 Scope로 부터 감쳐놓지 않고 싶을 때 좋다.

val numbers = mutableListOf("one", "two", "three")
numbers
    .also { println("The list elements before adding new one: $it") }
    .add("four")

7. with : 객체의 함수 호출을 그룹핑할 때

람다 결과값의 반환이 필요없고 문맥 객체(this)의 함수를 호출하고 싶을 때 with를 활용하면 좋다.

val numbers = mutableListOf("one", "two", "three")
with(numbers) {
    println("'with' is called with argument $this")
    println("It contains $size elements")
}

요약

이제 각 Scope function들을 어떻게 활용해야 될지 감이 어느 정도 잡혔다.

Nullable 체크하고 싶을 때 → let
길다란 식을 로컬변수로 활용하고 싶을 때 → let
객체를 구성할 때 → apply
구성한 객체를 바로 활용한 결과값을 얻을 때 → run
여러 식을 활용한 문을 결과값으로 쓸 때 → run (non-extension)
추가적인 효과를 내야할 때 → also (나는 로그 찍을 때 활용할 것 같다.)
한 객체의 함수를 여럿 써야할 때 → with

쓰다보니 처음에 썼던 사용 가이드와 동일하게 적은 것 같지만 수미상관 식으로 되새기듯이 끝내도 좋을 것 같다. 비슷한 효과를 가지고 있는 Scope function이기에 그 활용도를 개발자가 명확하게 인지하고 있어야한다. 일관되게 쓰도록 하자!!

참조 문헌

https://kotlinlang.org/docs/scope-functions.html#function-selectionScope function 제대로 쓰자!

'베스트 오퍼'를 보고

weekyear — Thu, 29 Sep 2022 10:12:52 +0900

미술상이 주인공이고 사기쳐서 미술품 빼돌린 다음에 본인의 방을 장식한다는 얘기가 ‘그레이트 프리텐더’의 한 에피소드와 비슷했다. 실제 전개도 비슷하였지만 그 전개를 보고서 느껴지는 감상은 전혀 달랐다.
솔직히 중반까지는 반전을 예상했다. 하지만 중후반부의 애틋한 전개때문에 그 반전을 잊어버리게 만들었고 평생을 걸쳐 모은 컬렉션이 다 사라진 방의 전체를 보여주는 연출은 입이 벌어졌다. 그때 부터 ‘사랑은 위조가 가능한가?’ 라는 생각이 머릿 속을 지배했다.
‘사랑은 위조가 가능한가?’ 이 의문은 조연들이 올드만에게 끊임없이 던지는 문제이다. 미술품을 빼돌리는데 도움을 주는 친구는 ‘모든 감정은 속일 수 있다.’고 말하는 반면, 수리하는 친구는 ‘사랑은 예술품과 같아서 위조하게 된다면 티가 난다’고 하면서 양쪽에서 올드만을 끊임없이 흔든다. 올드만의 컬렉션을 노린 사기극인 것은 틀림없다. 사기극을 벌이는 동안 클레어는 사랑이라는 예술품을 위조하였다. 작 중에서 올드만은 모든 위조품에는 결국 위조 작가의 자기 표현이 섞여 들어간다고 하였다. 이와 같이 클레어도 사랑이라는 위조품에 사적 감정이 있지 않았을까라는 생각이 들었다. 요양원에서의 올드만도 똑같은 생각을 하였을 것이다. ‘베스트 오퍼로 사들였던 사랑의 위조품에 일말의 자기 표현이 담겨 있기를 바라는 생각.’

'화양연화'를 보고

weekyear — Thu, 29 Sep 2022 10:12:13 +0900

카메라 각도나 빛의 처리를 잘 해서 그런지 아무 때나 일시정지해도 배경화면으로 삼아도 될 것 같았다.
그 당시 홍콩의 분위기에 집중하면서 봤다. 개인을 놓고 보면 옷도 잘 차려입고 세련된 느낌이 드는데 그들이 있는 공간은 디스토피아를 연상시키는 모순되는 느낌이 인상적이었다.
두 주인공의 관계가 진전하거나 변화할 때마다 노래가 반복되서 나오는데 지루한 연출이 될 수도 있을 것 같은데 섬세한 감정의 서사나 배우들의 연기로 오히려 좋은 연출로 승화시킨 것이 신기했다.
양조위의 눈빛이 미쳤다.
그들이 되고 싶지 않았던 이들의 치열한 갈등
헤어질 결심 때와 똑같은 의문이 들었다.
- 이런 류 얘기의 끝은 항상 비극이다. 해피엔딩으로 끝나길 바랐던 건 아니다. 다만, 가정(혹은 연인)이 있는 상황에서 다른 사람을 사랑하게 되면 좋지않게 끝날 수 밖에 없는건가? 아니면 해피엔딩으로 끝났을 경우에 이야기 완성도나 질타 때문에 새드 엔딩으로 끝날 수 밖에 없는건가?

룬샷 (전쟁, 질병, 불황의 위기를 승리로 이끄는 설계의 힘)

weekyear — Sat, 10 Sep 2022 17:20:30 +0900

1차 도중 리뷰 (09.01 ~ 09.10)

‘상전이’라는 과학적 원리를 경영학에 접목하여 혁신적인 아이디어를 내면서 아이디어를 발휘하기 위한 조직을 설명하는게 재밌었다.
- 서로 다른 두 분야가 같이 접목되면서 발휘되는 시너지를 지켜보는 건 즐겁다. ex) 심리학 + 경제학 = 행동경제학
내용 중에 물 분자 하나 혹은 금속 내의 전자 하나를 분석해서 그런 집합적 행동을 설명할 방도는 없다. ... 똑같은 원리가 팀이나 기업에도 적용된다. 어느 개인의 행동을 분석해서 집단의 행동을 설명할 도리는 없다. 는 부분에 대한 고철
1. 처음에는 우리 팀도 룬샷과 프랜차이즈로 나뉜 시스템이 필요할 수도 있겠다는 생각이 들었다.
2. 다시 생각해보니 분자가 10만 단위가 넘어가면 분석하기 어렵겠지만 분자가 7개 정도 밖에 안 되면 그 집단의 행동을 예측하는게 그렇게 안 어렵지 않나 생각이 들었다. 우리 팀과 같이 사람 수가 적은 팀을 룬샷, 프랜차이즈로 나누는 게 아니라 각자가 룬샷 사고 방식과 프랜차이즈 사고 방식을 밸런스있게 가져갈 수 있으면 좋겠다라는 생각이 들었다. (실제로 우리 팀 각자가 어느 한 쪽으로 치우치지 않고 밸런스있는 생각을 갖추고 있다는 생각이 들었음.)
3. 결론적으로 '문화'가 아니라 '구조'의 작은 변화를 통해 경직된 팀을 탈바꿈시킬 수 있다. 라는 룬샷의 교훈에서 ‘구조'도 같이 고민하되 아직 우리처럼 작은 규모의 조직에서는 ‘문화’도 아직은 소홀히 할 부분이 아니라고 생각하였다.
처칠의 “… 대영제국과 영연방이 앞으로 천년을 지속하더라도 사람들이 여전히 ‘그 때가 저들의 가장 멋진 순간이었다.”를 보고 저번주 황지의 “우리 그 때 좀 대단했지.”가 생각났습니다. 황처칠…그는 도대체..
룬샷의 조직은 핵심은 두 상태를 ‘분리'하는 동시에 서로 ‘교류'할 수 있는 상태 = 동적평형 상태
동적평형을 이루는 데 가장 중요한 동력의 핵심은 최고책임자의 지원이다.
- 우리 팀의 성공을 위해 회장님의 역할이 큰 것 같습니다. 그 전에 회장님의 신뢰를 얻을 수 있도록 노력해야지…
아이디어가 좋다고만 해서 살아남을 수 있을 정도로 현실은 그렇게 아름답지 않다. 외부에 의해서든 우연에 의해서든 가짜 실패를 겪는다.
가짜 실패를 극복하는 능력은 실패를 철저히 수사하는 능력이다. 진짜 실패와 가짜 실패를 구분하고 가짜 실패를 보호하는 능력(홍보, 리더 설득, 지원군 확보)도 필요하다.
‘호기심을 갖고 실패에 귀 기울기'
- 뜨끔했다. 나는 과연 이렇게 하고 있는가..? 특히나 요즘 같이 실패를 많이 하고 있는 이 시기에 더 필요한 능력인 거 같다.
- 호기심을 갖는다는 것이 노력으로 가능한 것인가? 라는 생각이 들었다. 당장 드는 생각은 ‘호기심'은 일단 마음에서부터 나와야 함이다. 호기심을 갖기 위해 필요한 것은 실패를 통해 내 프로젝트를 더 발전시킬 수 있다는 ‘기대감’인 것 같다.
- 요즘 나는 나의 실패를 바라볼 때, 나에 대한 ‘실망'과 ‘분노'로 대하고 있었던 것 같다. 이전처럼 ‘기대감'이나 ‘설렘'을 갖고서 내 실패를 바라보는 마인드를 재장착해야겠다.\

딱 이것만 외워두자

룬샷 : 대부분의 과학자나 사업가가 성공하지 못할 거라고 혹은 성공하더라도 돈이 되지 않을 거라고 생각하는 아이디어나 프로젝트
각 조직은 의식적으로든 무의식적으로, 전략이나 제품에 대해 깊숙이 간직한 신념을 발전시키기 마련이다. 룬샷은 그런 신념에 도전하면서 정반대 쪽에 투자하는 일.
부시-베일 법칙 핵심 정리
1. 상태를 분리하라
2. 동적평형을 만들어내라
  1. 기술이 아닌 기술이전을 경영하라
3. 시스템 사고를 퍼뜨려라
  1. 왜 그런 결과가 나왔는지 분석할 것이 아니라 왜 그런 선택을 했는지 ‘이유’를 계속 질문하라
  2. 의사결정 과정을 개선할 수 있는 ‘방법’을 계속 질문하라
4. 매직넘버를 높여라 (나중에 다시 읽을 때 눈여겨 보면 좋을 것 같은 부분)

최종 감상평

조직이 정체되어 있지 않고 지속적으로 혁신을 만들어 내기 위한 원리를 과학적 원리를 비유 삼아 잘 표현한 책이라고 생각하였다.
각 챕터마다 자세하게 예시를 담았다. 좀 심하게 담았다… 그래도 각 챕터 마다 Summary를 잘 정리해준 덕분에 읽기는 쉬웠다.
분리와 동적평형이란 단어는 의식해서 기억해둘 필요가 있을 듯
어떤 제품이나 서비스가 개발될 때 존속적 혁신으로 시작하더라도 파괴적 혁신으로 이어지는 경우가 많다는 것이 인상적.
모세의 함정에 대한 내용이 계속 머리에 맴돌았다. 당장 어쩔 수 없다는 이유로 회장님과의 회의에서 항상 입을 닫고 있지는 않았는지 되돌아 보게 되었다. 회의를 진행하면서 우리 팀이 잃어서는 안 되는 가치는 끝까지 지킬 수 있도록 해야겠다.
나중에 조직이 어느 정도 커지고 나면 꼭 다시 읽어봐야할 것 같은 책이라고 생각든다.

개발 공부 제대로 하는 법! (feat. 엘리 코딩)

weekyear — Tue, 23 Aug 2022 22:49:22 +0900

개발 공부 제대로 하는 법 (정체기에서 성장기로 가보자, 함 해보자!)

개발자로 성공할 수 있는 딱 하나의 기술

이런 사람들이 읽으면 좋다!!

뭔가 배웠긴한데 실력이 정체되어 있는거 같다.
어떻게 동작하는지는 모르겠지만 이것만 하고 다음에 공부하자고 생각한다.
회사는 항상 위기고, 이 프로젝트는 제일 중요하고 긴급하다.
배울건 산더미인데, 갈 길이 멀다
이것만, 이번만이라는 말을 하며 구글링을 통해 본 코드를 컨씨컨브이한다.

위 생각을 하면서도 방치한다면?

하는 것만 계속 하게 되고, 나에게 남는게 없다.
N년차에도, 선배가 되어도 후배에게 나눠줄 노하우라는게 없음.

깨어있기 이론 5가지

0. 조급해하지 않고 꾸준히 해나가는게 중요!!

1. 다음은 오지않는다. ‘이번만, 다음에!’ 하지 않기

지금 문제를 직면했을때! 지금이 가장 최적기!

하지만! 우리가 배울 건 정말 많고 개발하다 보면 배워야 할 것이 산더미처럼 많은데 언제 다 공부하나…?
리팩토링 책에 나오는 3의 법칙 을 적용해보자! → 비슷한 일을 세 번째 하게 되면 그 때 리팩토링하자!!

2. 깨어있기(사고하기)

우리는 업무중에도 제대로 사고하지 않는 경우가 많다! 하루 열심히 일한다고 해도, 내가 실제로 ‘사고’한 시간은 몇분 안 된다.

아래와 같은 생각 등을 꾸준히 의식적으로 스스로에게 되물어보자.

이 코드(또는 기획, 프로젝트)의 궁극적인 목표가 뭐지?
왜 하는 거지?
왜 이렇게 되는거지?
불편하네,, 여기서 비효율 적이네 ⇒ 어떻게 개선할 수 있을까?
내가 여기서 부족하구나 ⇒ 어떻게 개선할까?
왜 이 라이브러리를 쓰는걸까? 더 나은 방법은 없을까?
내가 무얼 하는지, 뭘 복사해서 붙여 넣고 있는지 제대로 알고 있는건가?

3. 메모하기 : 내가 필요한 지식들 정리하기

나에게 필요한 지식들, 부족한 지식들을 디지털 노트나 메모장에 적어본다.
앞서 말한 3의 법칙을 적용해서 공부의 우선순위를 정하기 위해 특정 지식이 필요할 때마다 체크 표시를 하나씩 늘린다.

4. 우선 순위 정하기 (T자로 공략해 나가기)

땅 위에서 자라고 있는 나무를 우리의 개발 실력이라고 생각해보자.
나무는 우리가 업무를 맡은 플랫폼 분야에 해당한다. ex) 안드로이드, 스프링, iOS
내가 안드로이드라는 나무를 키운다면 코틀린이나 자바, Google 공식 라이브러리, Canvas 활용법과 같은 기술이라는 나뭇가지가 늘어나면서 거대한 나무로 성장할 것이다.
이 나무가 잘 자랄 수 있도록 토양이 중요하다! 토양은 나무에 직접적으로 눈에 띄는 영향을 주는 기술(튼튼 토양)이 있고 간접적으로 은은하게 깊이 있는 개발자가 되기 위한 기술(깊은 토양)이 있다.
튼튼 토양 (직접적으로 눈에 띄는 영향을 주는 기술)
- Git 명령어 및 활용법
- 개발툴 효율적
- 터미널 명령어
깊은 토양 (간접적이고 은은하게 깊이 있는 기술)
- 자료구조
- 알고리즘
- 리팩토링

5. 일정관리 : 균형있게 공부 하기

내가 배워야 하는 기술들을 나무, 튼튼 토양, 깊은 토양으로 분류해보자.
한 달의 일정에서 나무, 튼튼 토양, 깊은 토양을 배울 날을 배치해보자. 현재 나의 부족함, 필요함, 상황에 맞춰서 3가지 부류의 공부의 비중을 조절해가면서 공부하자.
이렇게 공부하면 안드로이드만 공부하다가 깃도 공부해야 될 것 같고 자료 구조도 공부해야 할 것 같고 하는 불안함을 해소할 수 있다. ⇒ 깃을 빨리 공부해야 할 것 같지만 토요일에 하기로 했으니 괜찮아!!
일주일에 하루는 제발 제발 쉬자!!

개발 공부 제대로 하는 법 - 엘리코딩

Android 클린 아키텍처

weekyear — Thu, 16 Sep 2021 14:29:17 +0900

같이 일하시는 분께서 지금 작업하고 있는 프로젝트에 클린 아키텍처 개념을 적용해보면 좋을 것 같다고 말씀해주셔서 과감하게 도전해보기로 하였다.

우선 개발에 공통적으로 적용할 수 있는 클린 아키텍처 개념은 다른 페이지에 따로 정리를 해놨다.

공통적으로 적용되는 클린 아키텍처에 대한 개념은 Entities, Use cases, Interface Adapters, Frameworks & Drivers로 4가지 계층으로 나타나는데 안드로이드에 맞춘 클린 아키텍처는 이를 응용하여 3가지 계층으로 나타낸다. 그림은 다음과 같다.

일반적으로 Presentation, Domain, Data의 총 3개의 계층으로 나눠지게 됩니다.

Presentation

UI(Activity, Fragment), Presenter 및 ViewModel을 포함한다. 즉, 화면과 입력에 대한 처리 등 UI와 직접적으로 관련된 부분을 담당한다. 또한 Presentation 레이어는 Domain과 Data 계층에 대한 의존성을 가지고 있다.

Domain

애플리케이션의 비즈니스 로직에 필요한 UseCase와 Model을 포함하고 있다.

UseCase는 각 개별 기능 또는 비즈니스 논리 단위라고 생각하면된다.

UseCase는 보통 한 개의 행동을 담당하고 UseCase의 이름만 보고 이게 무슨 기능을 가졌을지 짐작하고 구분할 수 있어야한다.

Presentation, Data 계층에 대한 의존성을 가지지 않고 독립적으로 분리되어 있다. 안드로이드의 의존성을 갖지 않고 java 및 kotlin 코드로만 구성하며 다른 애플리케이션에서도 사용할 수 있다. Repository 인터페이스도 포함되어 있다.

Data

Repository 구현체, Cache, Room DB, Dao, Model 서버 API(Retrofit2) 을 포함하고 있으며 로컬 또는 서버 API와 통신하여 데이터를 CRUD하는 역할을 한다. 또한 Mapper 클래스도 포함하고 있는데 DB로 부터 받아온 데이터 모델과 UI에 맞는 데이터 모델간의 변환을 해주는 역할을 한다. 추가로 Domain 계층에 대한 의존성을 가지고 있다.

참조 문헌

[안드로이드] Clean Architecture

Android의 깨끗한 코드 이해

[안드로이드] 클린 아키텍처(Clean Architecture) 정리 및 구현

클린 아키텍처와 함께하는 배민앱 (Android) | 우아한형제들 기술블로그

[Android] Clean Architecture in Android — 꾸준하게

https://www.youtube.com/watch?v=KUEe1tc2CbE

클린 아키텍처

weekyear — Thu, 16 Sep 2021 14:27:46 +0900

클린 아키텍처는 모든 개발자가 관심을 가지고 주목하는 개념이다. 하지만, 다른 개발에 치이고 클린 아키텍처를 구현하는데 들어가는 리소스는 어마한데 비해 앱 사용자 입장에서는 바뀐게 없다고 느끼니 과도하게 시간을 쏟기가 정말 애매한 분야처럼 보인다.

하지만 고객들에게 많은 기능들이 포함된 고품질의 애플리케이션을 제공하기 위해서는 복잡도가 굉장히 높아지게 되고 이에 따라 유지 보수하기 쉬운 코드를 작성할 필요가 생겼습니다. 새로운 기능이 추가되거나 내부 로직이 변경되더라도 유연하게 프로젝트를 관리할 수 있게 구조를 짜야하는 거죠.

클린 아키텍처의 목표

계층을 분리하여 관심사를 분리하는 것!!

클린 아키텍처의 4가지 계층

Entities

엔티티는 비즈니스 규칙을 캡슐화한다. 메서드를 갖는 객체일 수도 있지만 데이터 구조와 함수의 집합일 수도 있다. 가장 일반적이면서 고수준의 규칙을 캡슐화하 게 된다. 외부가 변경되더라도 이러한 규칙이 변경될 가능성이 적다.

Use cases

유스케이스는 Interactor라고도 하며 애플리케이션의 고유 규칙을 캡슐화하며 엔티티로부터의 데이터 흐름을 조합한다. 유스케이스 계층의 변경이 엔티티에 영향을 줘서는 안 되며 데이터베이스, 공통 프레임워크 및 UI에 대한 변경으로부터 격리된다.

Interface Adapters (Presenters)

인터페이스 어댑터는 데이터를 Entity 및 UseCase의 편리한 형식에서 데이터베이스 및 웹에 적용할 수 있는 형식으로 변환한다. 이 계층에는 MVP의 Presenter MVVM의 ViewModel 및 게이트웨이 (=Repository)가 포함된다. 즉, 순수한 비즈니스 로직만을 담당하는 역할을 하게 된다.

Frameworks & Drivers (Web, DB)

프레임워크와 드라이버는 웹 프레임 웤, 데이터베이스, UI, Http Client 등으로 구성된 가장 바깥쪽 계층이다.

계층을 분리하는 이유

계층을 나누는 이유는 위 클린 아키텍처의 목표라고 적은 것과 같이 관심사를 분리시키기 위해서 이런 아키텍처가 동작하기 위해서는 의존성 규칙을 지켜야 한다. 한마디로 각 분리된 클래스가 한가지 역할만 수행하고 서로 의존을 어떻게 할지 규칙을 정하고 지켜야 한다는 말이다.

여기서 의존성 규칙은 모든 소스코드 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야 한다. 안드로이드를 예로 들면 비즈니스 로직을 담당하는 ViewModel과 같은 코드들이 DB 또는 Web과 같이 구체적인 세부 사항에 의존하지 않아야 한다.

클린 아키텍처의 이점

코드 테스트 커버리지 증가
쉽게 패키지 구조 탐색이 가능
집중화된 클래스에 따른 프로젝트 유지 관리 증대
새 기능을 빠르게 적용 가능
이후의 개발에도 안정적인 구현
명확한 규율로 전반적으로 따라야 할 베스트

참조

https://leveloper.tistory.com/205

[Android] Clean Architecture in Android

Clean Architecture란? 고객들에게 제공하는 애플리케이션 같은 경우에는 수많은 기능들이 있기에 복잡도가 굉장히 높습니다. 복잡도가 높은 애플리케이션을 개발할 때 어떻게 하면 유지 보수하기

leveloper.tistory.com

https://youngest-programming.tistory.com/484

[안드로이드] 클린 아키텍처(Clean Architecture) 정리 및 구현

[2021-04-28 업데이트] [프로젝트] github.com/mtjin/mtjin-android-clean-architecture-movieapp mtjin/mtjin-android-clean-architecture-movieapp Clean Architecture 학습 및 구현. Contribute to mtjin/mtjin..

youngest-programming.tistory.com

Delegate 패턴 (feat. Java 코드)

weekyear — Sun, 5 Sep 2021 10:56:04 +0900

도입

오늘 평소대로 코딩을 하던 도중 선배와 코드 리뷰를 하던 도중 델리게이트 패턴이라는 얘기가 나왔다. 선배가 델리게이트 패턴에 대해 대략적인 설명도 해주시고 델리게이트 패턴을 적용하면 코드 재사용성이 좋아지고 유지보수하기가 쉬워진다라고 말씀하셨지만 직접 정리해보는게 도움이 될거라고 생각하면 오랜만에 블로그 글을 작성하기로 하였다.

델리게이트 패턴이란?

Delegate는 위임하다라는 사전적인 의미를 가지고 있는데 이 뜻을 의식하면서 이해해보려고 하였다. 원래 본인이 해야할 작업을 다른 객체에게 자신의 일을 위임하는 패턴이 델리게이트 패턴인 것이다. 그럼 다음 예시를 알아보자!

그럼 어떻게 쓸 것인가?

실생활로 예시를 들어보자. 이제 직장도 구했고 방을 구해야 하는데 전세 대출도 알아봐야 하고 부동산 돌면서 방도 알아봐야 하고 계약서도 꼼꼼히 검토하면서 계약해야 하는 것이 너무 번거롭다. 그래서 나 대신에 방을 구해다 줄 사람, 즉 위임자(대리인)을 구하고자 한다.

우선 나라는 일개 노동자가 본업은 본업대로 하면서 방 계약까지 직접 해야하는 코드는 대략적으로 다음과 같을 것이다.

델리게이트 패턴을 사용하지 않을 때 코드

public class Worker {
    private String name;

    Person(String name) {
        this.name = name;
    }

    void 본업() {
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
    }

    void 전세 대출() {
        대출되는 은행 탐방~~
        ...
    };
    void 부동산 돌기() {
        부동산 10곳 찾기
        ...
    };
    void 계약 하기() {
        계약서 꼼꼼히 검토
        ...
    };
}

위 예시는 정말 간략하게 나타냈지만 실제 코드 같은 경우에는 훠어어얼씬 더 길어질 것이다. 그리고 나 뿐만 아니라 나와 동일한 처지의 친구도 본업만 다를 뿐이지 방을 구하기 위해 필요한 행위는 같을 것이다. 그렇다면 방 계약만을 따로 도와줄 수 있는 위임자가 있다면 그 분에게 나와 친구의 방 계약을 맡긴다면 훨씬 효율적일 것이다.

델리게이트의 타입 선언(인터페이스)

그렇다면 RoomGetter라는 인터페이스를 만들어보는 것으로 시작해보자. 인터페이스에는 방을 구하는 사람이 해야하는 일을 선언할 것이다. 그리고 RoomGetter라는 인터페이스를 구현하는 FirstRoomGetter 클래스를 구현할 것이다.

public interface RoomGetter {
    void 전세 대출();
    void 부동산 돌기();
    void 계약하기();
}

본래 코드에 델리게이트 변수 생성

델리게이트 패턴을 사용하기 위한 Worker 클래스의 코드는 다음과 같이 변경될 것이다. 이제 Worker는 방 계약과 관련된 코드를 직접 수행하지 않고 RoomGetter 타입을 가진 delegate 객체에게 시키면 된다.

public class Worker {
    private String name;
    private RoomGetter delegate;

    Person(String name) {
        this.name = name;
    }

    void 본업() {
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
        수없이 많은일~~~~~
    }

    void 방 계약() {
        delegate.전세 대출();
        delegate.부동산 돌기();
        delegate.계약하기();
    }
}

델리게이트 타입을 구현하는 클래스

그럼 실제 RoomGeter를 구현하는 FirstRoomGetter라는 클래스를 구현해보자. 생성할 때 Worker를 인자로 받아 인자에 자기 자신을 등록해줘야 한다. 그리고 실제 방을 계약하기 위해 필요한 함수를 구현한다.

public class FirstRoomGetter implements RoomGetter {
    FirstRoomGetter(Worker: worker) {
        worker.delegate = this;
    }

    void 전세 대출() {
        대출되는 은행 탐방~~
        ...
    };
    void 부동산 돌기() {
        부동산 10곳 찾기
        ...
    };
    void 계약 하기() {
        계약서 꼼꼼히 검토
        ...
    };
}

델리게이트 사용 코드

그리고 다음과 같이 사용하면 되는 것이다.

Worker me = new Worker();

RoomGetter roomGetter = new FirstRoomGetter(me);
me.방 계약();

델리게이트 패턴 왜 사용할까?

지금은 적용해보기 전에 글을 통해 내용을 정리하는 단계라서 직접 델리게이트 패턴의 유용함을 체감한 것은 아니다. 하지만, 지금 당장 어렴풋이 느껴지는 장점을 요약하자면 다음과 같다.

코드의 분리를 통해서 다른 클래스에서도 사용이 가능해져 코드의 재사용성이 좋아진다.
하나의 파일에 과도하게 쓰여지던 코드를 분리하여 유지보수가 편해진다.
인터페이스를 통해 어떤 일을 해야하는지 정해놓았지만 세세한 구현이 조금씩 다르더라도 각 클래스에서 따로 구현을 하고 가져다 쓰는 것은 인터페이스에서 정의한 함수를 가져다 쓰기만 하면 된다.
작업을 전달해야 할 경우가 있을 때 처리해야 하는 부분만을 전달할 수 있다.

공부하면서 느낀 점

델리게이트 패턴을 찾아보았을 뿐인데 iOS와 관련된 내용이 저엉어어엉엉말 많았다. iOS에서는 흔히들 쓰는 패턴인가보다. 하지만 iOS의 Swift 같은 경우에는 델리게이트 패턴을 쉽게 구현할 수 있도록 언어적인 지원이 되는 것 같은데 Java에는 그런 역할을 하는 예약어가 없는 듯하다. 얼마 안 있다가 코틀린으로 안드로이드 앱을 작업해야 할 일이 생긴 것 같은데 코틀린의 by라는 예약어를 통해 델리게이트 패턴의 적용이 된다는 것 같다. 나중에 코틀린에서도 델리게이트 패턴을 적극 적용해봐야겠다.