제이제이랩

최근에 kotlin + aac 로 안드 개발을 하였고, 개발 도중 여러가지 드는 생각과 질문들을 이곳에 우선 적어볼까한다. 내가 직접 실험하고 비교분석할 순있지만 이미 kotlin + aac 개발을 많이 해온 사람들이 충분히 있다고 생각되기에 검색으로 쉽게 해답을 얻기를 기대해 본다.

- UI가 top, middle, bottom으로 분리되어 있고 ViewModel이 monolithic하게 되는걸 방지하고자 1 Fragment, 3 ViewModel을 만들경우 Fragment는 3개의 ViewModel에 의존성이 생기게 되는데. top, middle, bottom에 대응하는 UIModel을 제공하는 ViewModel 3개를 만들고 이 세개의 ViewModel을 field로 갖고 View(Acitivity, Fragment)에는 이 ViewModel하나에만 의존하도록 하는건 어떨까? 그러면 View는 ViewModel 하나에만 의존하게 되고 ViewModel 3개와 이를 field로 같는 ViewModel은 parent-child 계층 구조로 설계하면 View 입장에서는 interface가 간편해지고 ViewModel을 선택해서 특정 요청을 해야할지 고민할 필요가 없을것 같다. 간단한 코드 샘플로 비교해 보면 좀더 명확해 질거 같은데? 근데 ViewModel builder function이 Fragment, Activity에 있네;;;;
- liveData() extension function으로 LiveData<T> 를 만들고 emit(), emitSource(), LiveData<T>.switchMap() 를 활용하는 방법이 코드 라인을 몇줄더 절약 가능한 방법인거 같은데. 아직 liveData() 함수 사용에 대한 이해도가 낮으니 좀더 공부해 봐야겠다.
  # LiveData.switchMap() 을 사용하는 예제
    https://gist.github.com/JoseAlcerreca/f2f2743ccd933f701a93beb00973e679#file-myviewmodel-kt

  # LiveData.switchMap() 을 사용하지 않고 Flow을 사용하는 예제. Flow가 더 많은 operation을 제공하고 코드도 간결해 보인다.
    https://gist.github.com/JoseAlcerreca/9a17b1faf1c76bd9ba35e15901f964c5#file-myviewmodel-kt

- kotlin에 Pair<T, V>, Triple<A, B, C>는 있는데, 4, 5, 6 field를 같는 data class가 필요하면 naming 규칙 만들어서 팀원들과 쓰자고 해야겠다.
- 

요즘 우주 관련 유튜브를 많이 보게 되는데, 이 광할한 우주에서 지구, 인간은 정말 큰 의미가 없겠다란 생각에 약간의 허무함이 밀려왔다.

빅뱅으로부터의 우주의 탄생 지구 그리고 인간으로서의 짧은 삶등에 대해 곱씹게 되었고, 인간 중심적인 사고방식이 많이 허물어 졌다.

엄청난 세월의 걸친 우리가 파악하지도 못한 원자들의 상호작용에 의한 여러 현상과 그 엄청난 에너지를 보고 인간이란 건 무수히 다양한 우주 환경에서 원자들의 무수히 다양한 형태의 결합의 과정중에 그 환경에서 운이 좋게 생성된거라는 생각이 든다. 

10대 때는 지구과학, 물리, 화학, 생물 분야에 흥미가 없었는데, 요즘엔 근본적인 물음들이 생각이 나서 위키피디아의 백과 사전에서 원자, 전기, 자성을 시간 날때 조금씩 보고있다. 수학도 근본적으로 제대로 기초가 안잡혀 있다고 보고 있어서, 다시 틀을 잡고 있는데. 이런 기초 지식들이 새롭고 이런게 있었구나 이런 의미였구나를 많이 느끼게 되어 좋은 시간을 갖고 있다. 

9월에 Java9이 공식 배포되었군요;;; 9이라서 9월에 했나;;

Jigsaw Project가 SDK를 모듈별로 관리해서 rt.jar의 용량을 줄이는 것 같은데, 대충 봐서 정확히 확인해봐야 겠네요;;;

https://docs.oracle.com/javase/9/whatsnew/toc.htm#JSNEW-GUID-C23AFD78-C777-460B-8ACE-58BE5EA681F6

저에게 눈에 띄는 주요한 변화는 아래와 같습니다.

https://docs.oracle.com/javase/specs/index.html

jvm spec for 9 도 올라 왔군요. 나중에 또 한번 훑어봐야 겠습니다;;

오랜만에 블로그에 글을 씁니다.

회사에서 모바일팀장으로 일하면서 공부도 하느라 바쁜 시간을 보냈습니다. 비밀리에 진행한 업비트 개발도 점차 안정화 되어가고 조금씩 숨통이 틔어지고 있네요. 개발자로서 현재 구현하고 있는 서비스가 사람들과 여러 미디어에서 뜨거운 관심을 받는다는 것은 너무나도 일의 보람과 기쁨을 주네요. 하루가 다르게 가격이 치솟는 비트코인과 여러 알트코인을 보면 이 서비스 개발 및 리딩에 참여할수 있어서 정말 즐겁습니다.

회사일을 퇴근 후 집에서도 하고 주말에도 하고 추석에도 했어서 숨가쁘게 달려왔지만 틈틈히 공부도 하였습니다. 안드로이드 보안쪽을 좀더 자세히 들여다 보기 위해 Android internal 및 security 관련 서적을 좀 읽었지요. `Android Internals - A Confectioner's Cookbook - Volume I - The Power User's View`, `Android Security Internals An In-Depth Guide to Android’s Security Architecture`, `Embedded Android` 란 책을 읽었습니다. 한번 밖에 아직 읽지 않아서 머리에 많이 남은게 없지만 그래도 여러 보안 이슈에 고민할 때 도움이 좀 되었습니다. 시간날때 2~3번 반복해서 읽어 봐야 겠습니다. 안드로이드 내부 구조도 확인할 수 있어서 응용프로그램 개발이 너무 쉽게 느껴지는 시기인 요즘에 가뭄에 단비 같은 지적 자극이었습니다.

출퇴근 하는 동안 틈나는 대로 RFC 문서들을 반복하여 보고 있습니다. 목적은 인터넷, 네트워크 스펙과 친해져서 좀더 인터넷 기반 서비스를 설계 및 구현할 때 지식을 잘 활용하기 위해서인데 RFC 문서 읽을 때마다 느끼지만 참 미국이라는 나라는 우리 소프트웨어 산업보다 정말 앞서있구나라는걸 절실히 느낍니다.

집에서는 MIT에서 나온 알고리즘 책을 보고 있는데 2번 대충 반복해서 읽었지만 너무나 머리에 남지 않네요. 약 1400페이지 정도이면서 수식 및 알고리즘이 많기도 하고 진짜 머리가 나뻐서 10번은 읽어봐야 할것 같습니다. MIT에서 나온 책만 보는건 학습 효과가 떨어질거 같아서 다른 알고리즘 설계 관련책도 보고 이산수학이나 확률 통계 책도 다시 보고 복습해야할 것 같습니다. 지금은 `The algorithm design by Steven S. Skiena` 책을 봅니다.

2017년에는 제 손으로 서버, 클라이언트 다 구현한 서비스를 만들고자 하는데, 회사일에 상반기에 올인한터라 틈이 없었습니다. SQL 에 관련된 서적을(800페이지 짜리..) 한번 본 후에 바로 랜덤 채팅 서비스라도 만들까 했지만 SQL 서적을 아직 30페이지만 읽다가 홀딩한 상태입니다..ㅎㅎ  

이번해에는 반드시 서비스를 하나 만들어야 할텐데 벌서 10월이라 힘들것 같네요..ㅠ

개발자로서의 미래

나는 현재 안드로이드 개발자로서 일하고 있다. 

안드로이드 개발자로서 필요한 지식은 자료구조, 알고리즘,  HTTP, 안드로이드, OS, 디자인 패턴, 객체지향 프로그래밍, 함수형 프로그래밍, 리액티브 프로그래밍, JAVA, JVM, 컴퓨터 구조에 대한 이해이다. 좀더 나은 안드로이드 개발자가 되기 위해서 위에 열거된 지식의 이해 수준을 한층 높여야 한다.

특히나 현재 나의 최대 약점인 자료구조, 알고리즘에 대한 이해도를 최대한으로 끌어 올려야 한다. 앞으로의 시대는 더욱더 수학, 알고리즘, AI, 머신러닝을 이용한 컴퓨터 과학자의 역할이 부각될 것으로 개인적으로 생각한다. 안드로이드 개발자로서는 상당한 수준에 이르렀으니 자료구조, 알고리즘, 수학에 대한 이해도를 최대로 끌어올려 다가올 미래에 대비해야 한다. 

안드로이드 기능 개발은 이제 시간만 있으면 그냥 하면 되는 그러한 일이 되어 버렸고 좀더 고차원에서 놀기 위해서는 컴퓨터 공학에 대한 풍부한 이론적 지식을 바탕으로 기술 집약적인 결과물을 도출할 수 있어야 할 것같다. 우선은 자료구조와 알고리즘을 누구보다 더 많은 이해해야 하겠고, 이를 바탕으로 현존하는 컴퓨팅 문제에 대해서 새로운 알고리즘을 도출해 보는 시도도 해봐야 할것 같다. 머리가 정리가 되지 않는 상태이다. 고민해 보며 방향을 잡아보자.

요즘은 통 블로그에 글쓸 기분이 나지 않아 글을 쓰지 않았습니다. 

사실 저는 MVVM+P 아키텍쳐를 이미 회사에 적용하여 사용하고 있는 중입니다. 그리고 팀원들에게 MVVM+P 에 따라 코딩하기를 장려하여 팀원들이 조금씩 받아들이는 중 입니다. 블로그에 이걸 또 말로 풀어 설명하려면 시간을 투자해야하는 부담 때문에 쓰기가 힘들어졌습니다. 그래도 reddit에서 조금 피드백을 받았으니 위안을 얻었네요.(https://www.reddit.com/r/androiddev/comments/5cepb4/mvvmp_what_is_this_what_benefit_can_you_get_by/)

요즘은 출퇴근길에 Gof 책을 보고 있습니다. 이제까지 Gof 책 보기를 미뤄왔는데 디자인 패턴에 관한 책은 더이상 Gof 책외에는 볼게 없어 보게 되었습니다. 역시 제 예상대로 설명 별루네요. 디자인 패턴의 바이블로 여겨지는 유명한 책이지만 이미 디자인 패턴에 대한 지식이 많이 있는 상태를 가정하여 쓴 책이라 책 구성은 제가 본 CS 책 중에 가장 별루인 느낌입니다. 출퇴근 시간에 2~3번 다독하고 컴파일러 책이나 봐야겠습니다;;;

집에 와서는 알고리즘 책을 보고 있네요. 사실 개발자를 하면서 가장 소홀이 했던 부분이 알고리즘 분야라고 느껴져 MIT에서 나온 책 두번째 정독 중입니다. 제 생각엔 5번 정독해야 그나마 알고리즘의 맛을 봤다라고 말할 수 있을 것 같습니다. 이쪽을 한동안 너무 안보기도 했고 개발자로서 기본 베이스를 좀더 탄탄히 해야겠다는 생각이 많이 드는 요즘입니다. 그리고 알고리즘 기본에 대한 해박한 지식을 바탕으로 인공지능, 머신러닝, 패턴분석에도 손을 뻗어볼까 추후에 생각중입니다. 그러면 앱도 만들고 알고리즘을 설계하고 구현하는데 능숙하면 흠 제가 아주 좋은 개발자가 되겠네요.ㅎㅎ. MIT 책만 보면 좀 그래서 다른 유명한 책들 2개도 얻었는데 다행히 800페이지 이하라 MIT 책보다는 빨리 볼수 있을 것 같습니다. 알고리즘에 대한 이해를 최상급으로 끌어올리기 전에는 나대지 않아야 겠습니다;;

현재 회사에서 제가 적용하는 아키텍쳐는 MVP와 MVVM을 섞어서 쓰고 있습니다. 소위 네이밍을 MVVM+P라고 지었는데요.

그림을 그리면 아래와 같이 되는데요.

이 그림 한장이 사람들에게 직관적으로 다가오는지 확인하기 위해 우선 reddit에 글을 올려본 후 어떤 설명을 추가할 지 알아본 후 세번째 글을 써야할 것 같습니다.

잘안보이시면 클릭 하셔서 확대해 보세요.

주말이 되어 오랜만에 어떤 글을 써볼까 하다가 이제 새로운 회사에 입사한지 한달이 살짝 넘은 터라 안드로이드 기능 개발 프로세스에 대해서 고민하는 시간을 갖도록 하겠습니다. (사실 저는 개발 방법론이나 개발 프로세스 자체는 관심이 없긴 한데, 아키텍쳐와 밀접하게 연관이 되어 있기 때문에 살펴봤네요ㅎㅎ;;;) 티몬에 재직할 때에는 사실 개발 프로세스에 대해서는 제가 신경쓰지 않아도 기획자 및 PM유닛에서 관리하기 때문에 고민할 필요가 없었지만, 지금 재직하는 회사는 벤처 회사이기도 하고 좀 더 기민하게 개발할 필요가 있다는 느낌적인 느낌이 들어 필히 개발 과정 동안 발생할 수 있는 상황에 대해 유연하게 대응할 수 있는 개발 방식에 대한 고민이 필요해 보였습니다.

기획서가 성숙단계에 접어들어 안드로이드 개발팀이 개발을 시작한다고 합시다. 기획서만 있고 디자인, 서버 API가 아직 나오지 않는 상태에서 모바일팀에서는 업무를 어떻게 진행해야 할지가 문제입니다. 디자인 시안이 안나와서 기획서대로 xml를 짜놓은 후 액티비티, 프래그먼트 구현을 했는데, 디자인이 기획서와 상당하게 차이가 나도록 변경되는 경우가 생긴다면 액티비티와 프래그먼트의 UI로직도 변경이 필요합니다. 서버에서 mock-up 데이터를 안내려 주거나 힘든 경우 모바일 클라이언트에서는 mock-up만 오기를 기다려야만 하는가? 이런 문제가 있는데요.

사실 서버에서 데이터를 내려주지 않고 디자인 시안이 나오지 않는 상황에서도 할 수 있는게 있습니다. MVVM 아키텍쳐를 채택해서 ViewModel을 미리 만들어서 기획서에 나온 UI를 가지고 xml을 만들어 바인딩하는 정도의 작업을 할 수 있습니다. ViewModel에 대한 테스트까지 해주면 땡큐죠. View에서 사용할 Presenter도 이 단계에서 정의해 줄 수 있습니다. 만약 디자인 시안이나 최종 디자인이 나왔다면 해당 디자인에 따라 xml을 개발하고 기존 ViewModel과 바인딩만 해주면 되고 서버 API 개발이 어느정도 진행되어 mock-up 데이터를 내려줄 수 있게되었다라고 한다면 json2pojo 서비스를 사용해서 5분만에 POJO클래스를 만들고 POJO를 Adapter 패턴을 사용하여 ViewModel에 사용될 수 있도록 적용해 주기만 하면 됩니다. 그리고 Presenter가 model를 사용하도록 하여 서버 연동을 해주면 작업이 완료가 되겠네요.

좀 더 정리해보면, 

1. 기획서를 바탕으로 ViewModel을 만들고, 테스트할 수 있는 기본 UI를 기획서에서 있는대로 최대한 단순한 xml을 구현한다.

2. ViewModel에 대한 테스트를 수행 및 테스트 코드를 작성한다.

3. Activity, Fragment, RecyclerView등의 View는 ViewModel만을 사용하도록 구현 한다. 절대 Model의 data(POJO)와는 디커플링 시킨다.

4. View layer에 대한 테스트 수행 및 테스트 코드를 작성한다.

윗 단계까지 작업하면 디자인, 서버 API의 mock-up이 준비되지 않아도 기획서에서 요구한 요구사항을 만족시키고 실행 가능한 앱이 됩니다. 

그럼 만약에,

- 기획서가 변경되었다면 어떻게 해야 할까요?

기획서가 변경되면... 사실 답없네요ㅎㅎㅎ 그냥 기존 코드 베이스를 싹다 수정해야 한다면 수정 해야겠죠. 허탈하게 웃을 뿐입니다.

- 디자인 작업이 완료 되었다면 어떻게 해야할까요?

UI디자인에 맞게 xml을 수정하고 data binding을 활용해서 ViewModel과 연동하면 됩니다. 문제가 있네요. ViewModel의 수정이 필요하게되면 ViewModel에 대한 테스트 코드 또한 수정해야하고... 

- 그럼, 서버에서 mock-up 데이터를 내려줄 수 있고 통신 프로토콜 방식에 대한 방식이 확정되었으면 어떻게 해야할까요?

data layer가 부재되어 있다면 data layer를 구현해야 하고 앞서 구현한 Presenter에서 API 요청을 보낼 모델을 사용하도록 합니다. json이 응답으로 오는 경우 json2pojo로 POJO 클래스를 뚝딱 만들면 되겠고, POJO와 ViewModel간 Adapter pattern으로 적용하여 기존 UI 로직 수정이 없도록 하면 개발이 끝나겠습니다.

우선 이러한 방식으로 회사에 적용해 볼까?라는 생각이 듭니다. 아직 제가 검증한 방법은 아니고, 이렇게 하면 어떨까 수준에서 나온 아이디어 입니다. 써보니 순수한 mvvm이 아니군요. 사실 click event 처리를 ViewModel에서해야 하나 Presenter를 만들어서 해야하나 현재 아리까리한 상황입니다. 글 보다는 그림으로 설명하는게 좋을것 같아 다음 글에서는 위에 너무 성의없게 작성한 글을 한번 visualization 하고 코드도 작성해서 설명해야겠습니다.