안녕하세요, 2022 신입 공채를 통해 카카오에 입사한 뉴크루 톡안드로이드O셀 ian, 비즈앱개발파트 silvio입니다. 지난 6주 동안 진행된 Android 직무 기술 온보딩에서 어떤 경험을 했는지 이야기해 보고자 합니다.

온보딩 과정

입사 후 3주간의 프리 온보딩과 1주간의 공통 온보딩을 거치고 마침내 직무별 기술 온보딩이 시작되었습니다. Andorid 직무를 선택한 뉴크루들이 처음으로 한자리에 모이게 되었습니다.

기술 온보딩 강의는 오준석 님(John)이 진행해 주셨습니다. 6주 동안 매일 오전 John의 강의와 코드 리뷰가 진행되었습니다. 강의에서 새로운 개념들을 배우고 과제 설명을 들은 후 각자 개인과제를 진행, Github에 하루 동안 작성한 내용을 Pull Request로 올려서 코드 리뷰를 받았습니다.

[caption id=“attachment_15902” align=“aligncenter” width=“576”] 기술 온보딩 일정표[/caption]

온보딩 기간 동안 코틀린 기초를 비롯해서 약 1주일에 하나씩, 총 4개의 앱을 구현하는 과제를 받게 됩니다.

To Do 앱

1, 2주 차에는 할 일을 추가, 수정, 삭제하고 완료 상태를 간단히 표시할 수 있는 To Do 앱을 만들었습니다. 이를 위해 리스트를 구현하는 legacy 한 방법인 ListView부터 현재 사용하는 RecyclerView 및 ListAdapter를 자세히 배우고, 화면 회전 시 액티비티가 재생성되면서 기존의 데이터가 사라지는 문제를 해결하기 위해 savedInstanceState를 활용했습니다. 또한 앱 종료 후에도 데이터를 유지하기 위해 모바일 데이터베이스인 Room을 사용했습니다. 기능 구현을 모두 완료한 후에는 build flavor를 설정해 하나의 프로젝트에서 여러 버전의 앱을 만드는 법도 배웠습니다.

첫 과제이다 보니 코드 리뷰에 코멘트가 가장 많이 달렸던 과제입니다. 지금까지 각자 개발해 오던 스타일과 사용하던 기술들이 달랐기 때문에 서로의 코드를 보면서 많이 배울 수 있었으며, 이 때문에 기존의 커리큘럼과 달리 view 의존성을 낮추기 위해 LiveData, ViewModel을 사용하고 clean architecture에 따라 presentation, data, domain layer를 분리하는 등의 개념들을 빠르게 배우고 적용하게 되었습니다.

노트 앱

3주 차에는 노트를 추가, 수정, 삭제하고 제목, 날짜 등을 기준으로 정렬할 수 있는 노트 앱을 구현했습니다. 1, 2주 차에 진행한 To Do 앱과 비슷한 과제였기 때문에 새로운 기능을 하는 기술들을 배우기보다는 코드 퀄리티를 높일 수 있는 개념들을 배웠습니다. 우선 Use Case를 사용해 ViewModel의 복잡한 로직을 분리할 수 있었습니다. 또한 unit test와 android test에 대해 배우고 테스트 코드를 작성해 앞서 작성한 use case를 간단히 테스트해 볼 수 있었습니다.

네트워크 통신

4주 차에는 네트워크 통신을 진행했습니다. 이때는 하나의 앱에서 총 3개의 다른 주제의 화면들을 만들었습니다. 첫 번째는 서버에서 간단한 데이터를 조회해오는 화면으로, http 통신을 해보는 것이 목표였습니다. 두 번째는 컨퍼런스 정보 리스트를 조회하고 각 컨퍼런스 아이템을 클릭했을 때 상세 정보를 보여주고 해당 컨퍼런스 웹사이트로 이동할 수 있는 화면이었습니다. 이를 위해 암시적 인텐트를 사용해 인터넷 앱으로 이동할 수 있도록 했습니다.

세 번째는 서버에서 전체 데이터를 한 번에 조회하는 것이 아니라 일부만 조회한 후에 추가로 데이터를 조회해오는 Pagination을 구현하는 과제였습니다. 이를 위해 Paging3 라이브러리를 사용해 데이터가 추가로 필요할 때 다음 페이지의 데이터를 요청하도록 했습니다.

If(kakao) 2021

대망의 마지막 과제! 5, 6주 차는 지금까지 배운 모든 것들을 적용해 if(kakao) 2021 웹 사이트(https://if.kakao.com/)를 앱으로 구현했습니다. 첫 화면의 하이라이트 세션들부터 전체 세션, 세션 상세 화면을 구성했을 뿐만 아니라 카카오톡 채널 연결 등도 구현했습니다. 웹사이트와 완전히 똑같이 만들면 재미가 없겠죠? 웹사이트와 달리 안드로이드 앱만의 특징으로 drawer layout에서 전체 세션과 좋아요 한 세션들 화면으로 이동할 수 있도록 했으며, 상세 화면의 세션 설명과 댓글을 ViewPager로 구현했습니다. 또한 전체 세션의 각 day 별 세션들도 웹사이트에서는 팝업 다이얼로그에서 선택해서 데이터를 변경한 것과 달리 안드로이드 앱에서는 ViewPager로 각 day 별 세션들을 쉽게 확인할 수 있도록 했습니다.

<시연 연상>

ViewPager를 사용하면서 화면 구현에 어려움이 있기도 했습니다. ViewPager는 화면을 슬라이드 형식으로 보여주는 방법으로, 높이가 고정된 영역 안에 여러 가지 화면을 추가하게 됩니다. 이 때문에 ViewPager를 스크롤 할 때 하나의 Fragment의 높이에 맞춰져서 다른 Fragment 화면의 일부가 가려지게 되는 문제가 발생했습니다. 이는 각 Fragment의 onResume()에서 view의 크기 측정부터 다시 실행하도록 하는 requestLayout()을 호출해 Fragment가 화면에 보일 때마다 다시 높이를 조정하도록 해결했습니다.

Peer pressure

전공도, 배경도 모두 다양한 안드로이드 뉴크루들이 모였습니다. 매일같이 과제를 진행하고, 함께 코드 리뷰를 하며 서로에게 준 영향이 적지 않았는데, 그 과정에서 커리큘럼에 없던 공부를 하게 된 경우도 있었습니다. 그런 에피소드들을 소개해 보려고 합니다.

클린 아키텍처 부터 DI (Hilt, Koin) & unit test 까지

안드로이드에는 Hilt 나 Koin 과 같은 의존성 주입 도구들이 있습니다. 기존 이런 도구들을 다뤄보지 않았던 크루도 적지 않았는데, 이번 기술온보딩 과정에서 전원 이와 같은 DI 도구들을 적용해 볼 수 있었습니다.

의존성 주입은 적절히 사용하게 되면 의존성/종속성을 해소할 수 있으며, 결합도를 느슨하게 할 수 있고, 단위 테스트가 편리해지는 등 다양한 이점을 가지게 됩니다. Hilt 등의 의존성 주입 도구를 활용하게 되면 의존성 주입이 클래스가 아닌 별도의 주입자를 통해 이루어져 객체 생성 책임을 클래스로부터 분리할 수 있게 됩니다.

초반에는 생성자나 필드를 통해 수동으로 의존성을 주입하는 것부터 시작하였습니다. 그러던 중 불필요한 코드의 중복이 발생하는 점, 작은 코드 수정을 위해 여러 개의 클래스를 수정해야 하는 점, 클래스 간의 종속성 등의 부분에서 서로가 비슷한 문제의식을 느꼈습니다. 그리고 의존성 주입 도구를 도입하기 시작했습니다.

Before

[gallery ids=“15909”]

[caption id=“attachment_15910” align=“aligncenter” width=“547”] Repository는 물론, DataSource 에 대한 종속성도 갖고 있는 ViewModel[/caption]

서로 시행착오를 겪고, 적극적으로 피드백을 나눴습니다. 클린 아키텍처에 대해 토론하던 중 화상 미팅에 칠판이 등장하기도 했습니다. 이 과정에서 돋보였던 점은 커뮤니케이션 과정에서 효율을 추구했다는 점과 아래 깔려 있는 믿음이었습니다. 막혔던 부분을 얘기하기 부끄러워하지 않았고, 상대방이 이해하기 쉽게 설명하려고 노력했습니다. 새로운 요소들을 빠르게 습득하고 적용한 결과 전원, 커리큘럼에 없었던 의존성 주입 도구에 익숙해질 수 있었으며 일부는 unit test에도 의존성 주입 도구를 적용해 볼 수 있었습니다.

After

[caption id=“attachment_15911” align=“aligncenter” width=“497”] Usecase 분리[/caption][caption id=“attachment_15912” align=“aligncenter” width=“504”] 테스트 모듈[/caption]

Unit test 부터 TDD(테스트 주도 개발) 까지

DI에 대한 유행이 정착될 때쯤, 잠깐이지만 TDD 열풍이 분 적이 있었습니다. 모두 생소했던 unit test에 조금씩 적응해갈 때쯤, unit test를 더 적극적으로 활용할 수 있는 방법이 무엇인지 고민하던 silvio가 TDD를 소개했습니다. 모든 public 메소드에 대한 테스트 코드를 작성한다는 기본적인 원칙만 학습했던 크루들은 Red, Green, Refactor라는 기본적인 프로세스를 빠르게 습득하고 나름의 방법대로 적용해 보기 시작했습니다.

TDD는 크게 3 단계로 이루어진 프로그래밍 방법론입니다.

Red: 테스트 설계(이 시점에서 테스트 통과 실패)
Green: 테스트를 통과하도록 실제 코드 작성
Refactor: 테스트 코드와 테스트를 모두 정돈/리팩토링

TDD를 적용해 보는 과정에서 가장 어려웠던 부분은 체득하고 있던 개발 순서와 다르게 코드를 작성해야 했다는 점입니다. 의식적으로 테스트 코드부터 작성하도록 개발 순서를 조정하는 것이 마치 한글 자음을 거꾸로 발음하는 것처럼 쉽지 않았습니다. 필요하다고 생각할 때에만 테스트 코드를 작성하던 기존과 달리 거의 모든 클래스마다 테스트 코드를 작성해 줘야 하니 작업해야 하는 양도 늘어났습니다. 실제 코드를 리팩토링할 때 테스트 코드도 함께 리팩토링해 줘야 했습니다.

TDD를 적용해 본 크루들은 예외 없이 위에 나열한 작업량 증가, 수정 비용 증가 등 개발 속도가 느려지는 부작용을 겪었습니다. 그리고 대부분이 기술온보딩 과정의 핵심은 설계와 개발 경험, 미션을 완수해 보는 경험이라고 판단하였습니다. 결과적으로 TDD를 즐거운 경험으로 뒤로하게 되었습니다. 하지만 unit test에서 시작하여 새로운 프로그래밍 방법론까지 탐구하고 적용해 보는 과정이 크루들의 기질을 잘 보여준다고 생각해 소개하게 되었습니다.

마치며

그리 길지 않은 여정이었습니다. 그래서 아쉬운 점도 많았습니다. 함께 더 깊이 다뤄보고 싶었던 주제들이 있었고, 편하게 커뮤니케이션할 수 있는 티타임과 같은 시간이 더 있었으면 싶기도 했습니다. 비대면으로 진행되어 크루들이 다 함께 실제로 만나 커피 한잔해보지 못한 부분도 아쉽습니다.

하지만 코드에 대한 고민을 함께하고, 실무와 유사한 경험을 같이 하며, 서로에게 선한 영향력을 주고받으며 성장한 시간은 값지게 남을 것 같습니다. 온보딩 이후 각자 부서로 돌아간 후에도 티타임을 가지며 근황을 공유하기도 하고 안드로이드 개발 관련 정보도 공유하는 등 연락을 이어가고 있습니다.

온보딩을 함께한 fac, iryk, ian, shy, evan, peter, silvio 2022 안드로이드 뉴크루들 앞으로 각자 부서에서 잘 성장할 수 있기를 기원하며, 또 좋은 프로그램 만들어주신 온보딩TF, 긴 온보딩 기간동안 뉴크루를 기다려주신 파트분들께도 감사드리며 이 글을 마치도록 하겠습니다. 감사합니다.

2022 신입 공채 Android 직무 기술 온보딩 회고