3. Jeong Jaeyun
정재윤
#Android #Kotlin, #Java, #Python
항상 Why?에 초점을 두고 How?를 같이
고민할 수 있는 개발자가 되고 싶습니다.
다양한 프로젝트와 기술 적용을 위한 코드들
CS지식과 Android 공부 기록을 위한 벨로그
저에게 더 궁금하시다면 연락은 언제나 환영입니다
Notion을 활용한 포트폴리오
나를 표현하는 또 다른 방법들(아이콘을 클릭해주세요)
내가 관심가지는 기술!
내가 추구하는 개발자는?
기술적인 발전을 위한 도전을 하는 개발자
저는 여러 프로젝트를 찾아다니며 늘 새로운 상황에 도전하여 새로운 요구사항에 맞춰
경험해보지 못한 기술적인 도전을 하며 이를 통한 발전을 추구합니다.
협업을 잘하는 개발자
개발자간 소통 뿐 아니라 기획, 디자이너와의 소통은 매우 중요합니다.
기획자와 디자이너와의 소통을 통해 직면한 문제를 해결해나가는 과정에서 더 나은 협업을 항상 고민합니다.
MVVM, RxJava, LiveData, Databinding을 사용하여 다수의 프로젝트를 해본 경험이 있습니다.
데이터를 중점으로하여 변경 이벤트에 따라 반응하는 어플을 만들어보면서 비동기성과 반응성의 중요성을 알게되고
Reactive Programming에 대해 더 많은 관심을 가지고 공부하고 있습니다.
4. PickupBox
배송을 원하는 소비자와 배송을 하고싶은 배송자를 매칭시켜주는 플랫폼
대학교 졸업 작품으로 진행한 [무인택배함을 이용한 근거리 배송 플랫폼] 프로젝트
매칭은 비대면 (무인택배함), 거리는 근거리(사람이 직접 배송)
서비스 소개
사용 기술
- Java
- ViewPager, Glide, Google Maps API
팀 내 역할
- 홈 화면 / 지도 화면 개발
- Firebase Realtime-database, Storage, Auth, Messaging
- 소비자/배송자 매칭 및 채팅 서비스 개발
- 물품 등록 서비스 개발
(19.12~20.03)
5. MonoPad
영화 리뷰 다이어리
최신 인기 영화, 개봉 예정 영화 등을 조회할 수 있으며
영화를 검색하여 영화 포스터 카드를 사용하여
캘린더 형태로 자신만의 영화 다이어리를 만들 수 있는 어플
(20.09~20.11)
7. Specification
- Kotlin
- Architecture : MVVM
- Koin, Retrofit2, OkHttp3, RxJava2, DataBinding, LiveData
- Github, GitFlow
My Role
- Koin을 사용하여 의존성 주입
- ViewPager2, Glide, Room
- Repository Pattern 구성을 위한 Local & Remote Data Access 로직 개발
- 영화 배우 필모그라피 서비스 화면 개발
MonoPad
영화 리뷰 다이어리
Team
Android 4
- MVVM 아키텍쳐를 활용하여 프로젝트 구성
프로젝트 목표
“안드로이드에서 적용되는 아키텍쳐와 의존성 주입을 사용하여
컴포넌트 간 영향이 적어 확장이 쉬운 어플을 만들자"
8. MonoPad
영화 리뷰 다이어리
아키텍처의 가장 큰 장점은 테스트와 유지보수 용이성이라고 생각합니다.
이는, 독립적으로 존재할 수 있고 결합도가 높지 않기에 가능한 일이라고 생각합니다.
제가 프로젝트를 진행하면서 역할 분리, 모듈화를 통해 다른 파트 개발자가 개발을 하더라도 유연하게 확장하고 그러한 확장이 다른 부분에 영향이 없는 형태를 만들고 싶었습니다.
뷰모델을 특정 뷰에서만 사용하기보다 다른 뷰에서 재사용할 수 있는 형태를 만들면서 뷰모델이 뷰에 종속되지 않는 부분이 왜 필요한지 알게 되었습니다.
MVVM Architecture를 사용하여 프로젝트 구성
Koin을 사용하여 의존성 주입
의존성 주입을 선택한 첫 번째 이유는 코드의 재사용성입니다.
MVVM 아키텍쳐를 사용하여 프로젝트를 진행하면서 뷰에서는 데이터를 관찰 할 뷰모델 클래스가 필요하였고
이는 뷰에서 뷰모델을 매번 생성하여야 하는 형식적인 코드들이 작성되어야 했습니다.
이를 외부 생성을 통해 주입을 하게 될 경우, 형식적인 코드를 줄일 수 있음에 선택하여 사용하였습니다.
의존성 주입을 사용한 또 다른 이유는 클래스 간 결합도를 낮추기 위해서입니다. 아키텍처를 적용하여 뷰, 뷰모델, 모델을 나누었지만
서로가 서로에게 의존하고 있게 된다면 이는 특정 클래스 변경 사항에 대해 결합된 컴포넌트가 영향을 받을 수 있음을 의미합니다.
컴포넌트 간 영향이 적은 어플을 만드는 것이 초반의 목표이었기에 Koin을 통한 의존성 주입이 필요하였습니다.
프로젝트 내 나의 역할과 사용한 기술
Repository Pattern 구성을 위한 Local & Remote Data Access 로직 개발
Local, Remote 데이터 접근을 추상화하여 비즈니스 로직과 모델을 분리한다는 점, 확장이 쉽다는 점이 Repository Pattern을 선택한 이유입니다.
실제로 개발을 진행하면서 모델에서의 데이터 접근에 대한 부분의 수정을 하더라도 일관된 인터페이스를 제공하기에 뷰모델에서의 수정없이 지속 확장이 가능하다는 점을 배웠습니다.
그러나 내부 데이터에 대한 접근이 필요 없을 경우, 사용 여부가 궁금하였지만 Repository 패턴은 추상화를 통해 테스트를 용이하게 하기에 굳이 내부 접근이 없더라도 진행하면
좋다는 것을 알게 되었습니다.
9. MonoPad
영화 리뷰 다이어리
What I learn ?
Git Process
Repository Pattern
Reference Share
여러 명의 개발자 간 협업을 잘하기 위해서 GitFlow 전략을 참고하여 Feature 별로
Branch를 생성하여 담당한 부분을 개발한 이후, 최소 2명의 코드리뷰를 통해 PR을 수행하였습니다.
개인 개발을 주로 하던 이전과 다르게 여러 명의 스타일이 다른 개발자들과의 협업을 통해 하나의 어플리케이션이기능 별로 개발되어
통합되는 전반적인 과정을 배우고 버전 관리를 통해 이슈가 생긴 부분에 대해서 쉽게 원인을 찾을 수 있어 매우 효율적인 프로세스를 배울 수 있었습니다.
Remote(TMDB API)와 Local(Room)을 모두 사용하여야 하는 구조를 설계해야 했습니다.
영화 상세 화면에서 다이어리 작성 화면으로 넘어가는 경우, Local에 저장된 다이어리가 있는지 확인하고 없을 경우 Remote에서 가져오는 구조였기에
Remote, Local 모두를 Access 하면서 이를 뷰 모델에서 알지 못하도록 하는 Repository Pattern을 처음으로 적용해보았습니다.
뷰모델에서 Local, Remote 중 어느 곳에서 데이터를 가져오는 지 알 필요가 없고 데이터만 요청하면 되기에 ViewModel - Model 간 독립성을 높이는 방식을 구현할 수 있었습니다.
Notion과 Issue탭을 활용하여 본인이 맡은 기능에 대한 개발 이슈 및 개발 과정에서의 참고를 공유함으로써
자신이 담당한 기능만 개발하는 것 뿐 아니라 여러 기능에 대한 관심을 갖고 서로 해답을 찾아서 공유하는 등의 활동을 통해
개발자 간 협업에서 명확한 근거를 통한 설득에 대해서 배울 수 있었습니다.
10. HEAR & THERE
외국인을 위한 오디오 가이드 큐레이션 어플
북촌을 관광지로 하여 실제 외국인을 대상으로
오디오 가이드 콘텐츠 및 기능의 만족도를 파악하기 위한
테스트용 어플리케이션 제작
(20.08~20.09)
12. Specification
- Kotlin
- Architecture : MVVM
- AndroidX, Retrofit2, OkHttp3, RxJava, DataBinding, LiveData
- MediaPlayer
- ViewPager2, Glide
- Naver Maps API
My Role
- MediaPlayer & Service를 사용하여 백그라운드 오디오 스트리밍 서비스 개발
- Naver Maps API를 사용하여 위치 추적 및 화면 구성
- ViewPager2를 사용하여 오디오 가이드 내 상세 화면 구성
HEAR & THERE
외국인을 위한 오디오 가이드 큐레이션 어플
Team
Android 2, Server 1, Design 2, Service 2
프로젝트 목표
“ 지도 위에서 동작하는 오디오 어플이지만 버벅임과 끊김없게 만들자.”
13. HEAR & THERE
외국인을 위한 오디오 가이드 큐레이션 어플
What I learn ?
Singleton 패턴
Service를 사용한 백그라운드 재생
지도 화면에서 오디오를 재생하면 현재 재생 중인 오디오의 시간과 Seekbar를 사용하여
진행상황을 표시해주어야 했습니다. 이때, 지도 화면에서 MediaPlayer 객체에 접근하여
재생 중인 상태 및 현재 재생 중인 오디오의 정보를 알아내야 했습니다. 또한 백그라운드에서
오디오가 재생될 수 있도록 Service를 사용하여 MediaPlayer 객체에 접근하였습니다.
Seekbar를 통해 현재 상태를 지속적으로 업데이트 해줘야 하기에 스레드를 새로 생성하여
작업하였고 서로 다른 스레드에서 동일한 객체에 접근하기에 MediaPlayer 객체를
싱글톤으로 생성하여 사용하였습니다. 이 과정에서 평소에 알고있던 싱글톤 생성 방법 및
Best Practice를 연습해보며 더 효율적인 싱글톤 생성 방법을 공부할 수 있게 되었습니다.
백그라운드 오디오 재생을 위해 Service를 사용하여 개발을 진행하다가
Service내에 MediaPlayer의 상태 변경으로 UI 업데이트 작업을 하였을 때,
오류가 발생하였고 Service의 생명주기 메서드는 UI 스레드에서 실행되기에
UI 이벤트가 지연될 수 있다는 위험이 있어서 BroadCast를 사용하여 UI 변경을 전달하고
변경 알림을 받게 되면 별도의 스레드 처리를 하여 화면을 업데이트 시켜주었습니다.
특정 컴포넌트와 기능을 사용할 때, 어떤 스레드에서 동작을 하는지 또 그 동작하는 스레드가
다른 컴포넌트에 영향을 끼치지 않는 등의 생각을 할 수 있게 되었습니다.
프로젝트 내 나의 역할과 사용한 기술
MediaPlayer
지도 어플 위에서 위치 추적을 하면서 동작하기에 배터리 효율을 생각하여야 하였고
ExoPlayer와 비교해서 배터리 효율이 더 좋기에 선택하였습니다.
다양한 UI 구성 없이 하단 재생 바를 통해 작동하기에 커스텀이 필요하지 않았고
외부에서 생성된 MediaPlayer 객체를 주입 받아 사용하여 MediaPlayer 객체의
상태에 따라 처리하는 방법을 구현하였습니다.
Naver Maps API를 사용하여 위치 추적 및 화면 구성
단말기에 설정된 언어에 따라 지도에 다양한 언어를 보여주기에 외국인 대상으로
테스트를 하는데에 있어서 외국인들이 한국 지도를 영어로 볼 수 있어 Naver 지도로
선택하였습니다.
minSdkVersion을 23으로 설정하여 어플 설치 시에 권한 체크가 아닌
권한이 필요한 동작을 수행할 때 권한 체크를 하게 되어 위치 추적에 대한
권한 여부를 통해 지도 화면 진입 여부를 판단하여 진입하도록 기능을 개발하였습니다.
14. Hear story
외국인 및 내국인을 위한 오디오 가이드 큐레이션 어플
한국의 관광지를 오디오 가이드를 활용한 관광을 도와주는 어플!
외국인 및 내국인 모두 사용 가능하도록 한/영 버전을 모두 제공!
직접 제작 및 선정한 오디오 가이드 내용과 관광 스팟!
현재 대략 30개 정도의 서울 오디오 가이드 버전 제공 중
(20.07~20.12) & 사이드 프로젝트 참여
16. - Kotlin
- Architecture : MVVM
- AndroidX, Retrofit2, OkHttp3, RxJava, DataBinding, LiveData
- ExoPlayer2
- ExoPlayer & Service를 사용하여 백그라운드 오디오 스트리밍 서비스 개발
- ViewPager2, Glide, Room
- 한글/영어 콘텐츠 분리를 위한 한/영 전환 기능 개발
- 지도 탭 내의 서비스 개발
Hear story
외국인 및 내국인을 위한 오디오 가이드 큐레이션 어플
Specification
Team
My Role
Android 2, Server 1, Design 2, Service 2
- 오디오 콘텐츠 관련 메인 및 상세 페이지 개발
“유지 보수가 잘 될 수 있도록 구성”
프로젝트 목표
“UI의 끊김이 없고 버벅임이 없는 어플”
17. Hear story
외국인 및 내국인을 위한 오디오 가이드 큐레이션 어플
What I learn ?
MediaPlayer보단 ExoPlayer
Koin을 사용한 의존성 주입
이전에 테스트 어플의 경우, MediaPlayer를 사용하여 오디오를 재생하였습니다.
그 이유가 ExoPlayer가 가진 단점 (많은 배터리 소모)이였는데 지도 화면 위에서
지속적으로 위치를 추적하면서 재생해야 하기에 배터리 소모가 더 적은 MediaPlayer를
선택하였지만 Thread-safe하지 않다는 점과 ExoPlayer에서 제공해주는 기능들이
MediaPlayer에 비해 훨씬 이점을 가지고 있다는 점에서 선택하였습니다.
MediaPlayer와 동일하게 UI Thread에서 동작하지만 내부적으로 playback thread를
생성하여 다중 스레드에서 생기는 문제점을 방지한다는 점을 배웠습니다.
이전의 프로젝트들에서 의존성 주입을 Injection Object를 만들어서 필요할 때마다 생성하여
사용하였지만 Koin이라는 라이브러리를 사용해봄으로써 편하게 의존성 주입을 하였습니다.
객체의 생성과 사용을 분리함으로써 코드 재사용성을 높이고 훨씬 간결하게 만들어주었으며
이를 통해 객체 간 영향을 줄여주고 개발의 편리성이 높아짐을 배웠습니다.
프로젝트 내 나의 역할과 사용한 기술
ExoPlayer
테스트 어플 개발 시에 ExoPlayer가 MediaPlayer보다 배터리 효율이 좋지 않기에
사용하지 않았지만 베타 어플을 개발하면서 MediaPlayer는 Local Media를 재생하는데
더 적합하고 서버로부터 스트리밍을 하는데에는 ExoPlayer가 더 적합하다고 판단하여
선택하였습니다.
MVVM Architecture
해당 프로젝트의 첫 번째 목표는 유지보수가 잘 될 수 있도록 만드는 것이었으며
이를 달성하기 위해서는 아키텍처 적용이 필수라고 판단하였습니다.
이전의 프로젝트에선 뷰모델을 화면 단위로 나누게 되면서 재사용을 많이 하지 못하였는데
이번 프로젝트에선 뷰모델을 기능 단위로 나눠보면서 뷰모델 재사용을 효과적으로 하였습니다.
Reactive Programming
데이터를 서버로부터 읽어오는 스레드와 가공하여 반영하는 스레드를 적절히 관리하여야
하였고 읽어온 데이터를 뷰에 반영함에 있어서 데이터의 흐름을 기반으로 변경에 따른
처리를 하고자 RxJava, LiveData, Databinding을 조합하여 사용하였습니다.
스레드 전환을 효율적으로 할 뿐 아니라 뷰에서도 여러 상호 작용을 함에 있어서
Rx를 사용하여 옵저버 패턴을 구현하여 작업하였습니다.
Context를 생성하는 과정에서의 언어 설정
Activity가 생성될 때마다 Context를 구현한 ContextImpl이 생성되고
단 한 번의 Context 생성을 보장하는 attachBaseContext()를 Override하여
액티비티내에서 언어 설정을 변경할 수 있도록 구현하였습니다.
이 과정에서 변경된 언어를 저장하기 위해 SharedPreference를 사용하였고
싱글 액티비티 멀티 프레그먼트 구조이기에 싱글 액티비티 생성 시점에만 언어 설정을
지정해주어 기능을 구현하였습니다.
18. ForKids
Z/알파 세대 금융 교육 플랫폼
[NH 온라인 해커톤 본선]
Z/알파 세대의 소비 패턴 분석을 통한
금융 교육 추천 플랫폼 프로젝트
(20.12~20.12)
20. - Kotlin
- Architecture : MVVM
- AndroidX, Retrofit2, RxJava, DataBinding
- ViewPager2, MPAndroidChart
- 회원가입/로그인 및 간편 비밀번호 화면 구현
- Koin을 통한 의존성 주입
- 홈(단일 계좌 조회 & 소비 패턴 그래프), 계좌 조회 서비스 구현
- 간편 계좌 송금 서비스 구현
ForKids
Z/알파 세대 금융 교육 플랫폼
Specification
Team
Android 1 Server 2 Service 1
My Role
프로젝트 목표
“빠른 시간안에 개발이 가능하도록 미리 아키텍처 구축”
“데이터 변경에 따른 빠른 처리”
21. ForKids
Z/알파 세대 금융 교육 플랫폼
What I learn ?
Base-Abstract Class의 확장성
SharedPreference를 사용한 token 관리
빠른 시간 내에 작업물을 보여야 하는 해커톤이였기에 기획 회의를 통해 미리 구조를 잡아두었습니다.
여러 개의 화면으로 구성되었기에 Fragment가 여러 개 존재하였고 이 과정에서 중복된 코드들이
많이 있었습니다. 이를 BaseFragment Abstract Class로 만들어서 특정 생명주기에서
데이터 바인딩과 뷰모델 주입을 하는 과정을 통해 여러 Fragment에서 코드를 줄일 수 있었고
공통 코드를 기반으로 하여 각 화면마다 가지게 되는 기능들을 구현함으로써
추상 클래스가 가지는 확장성을 실제로 경험해보았습니다.
SharedPreference에 대한 개념을 알고 있었지만 실제로 제대로 써본 적이 없었습니다.
핀테크 프로젝트 특성 상 계좌 조회, 입출금 내역 조회, 송금 가능 조회 등의 기능을 사용할 때 마다
개인이 가지고 있는 토큰을 사용하여 조회하여야 했고 이는 처음 어플 진입시 발급받게 되었습니다.
어플리케이션이 동작하고 있는 동안 전역적으로 저장할 공간이 필요하였고 타 어플을 사용하다가
돌아오더라도 사용 가능 하도록 하는 기능이 필요하였습니다.
Property에 저장할 수 없고 Room에는 저장하기에는 비용이 너무 많이 드는 작업이기에
SharedPreference를 통해 값을 저장하였고 조회 시점마다 업데이트를 하게 되면서
적합한 상황에 SharedPreference를 사용하는 방법을 배웠습니다.
프로젝트 내 나의 역할과 사용한 기술
MVVM Architecture
해당 프로젝트는 미리 주제를 공지하고 API의 연결만 4일동안 진행되는 해커톤
이었기에 미리 프로젝트를 구성할 수 있었습니다. 이전 여러 차례 프로젝트를
통해 아키텍처 적용 시에 결합도가 높지 않기에 훨씬 빠르게 확장할 수 있다는 점
을 느껴 해당 프로젝트에서도 그점을 생각하여 적용하였습니다.
Observer Pattern
메인 화면에서 계좌의 잔액이 보여지고 화면을 넘길 경우, 지출 내역 그래프가
보이는 구조에서 송금을 하고 메인 화면에 올 경우, 잔액과 그래프가 동시에 모두
갱신 되었어야 하며 이를 구현하기 위해 옵저버 패턴을 사용하여 변경 사항을
적용시켜 빠르게 보여줄 수 있었습니다.
