미리보기

재직 당시 4~5명 규모의 팀에서 Kotlin 기반의 안드로이드 파트를 주도하며 Java 기반 어플리케이션 1개, Kotlin 기반 어플리케이션 3개를 개발하였습니다.
프로젝트에 적용할 아키텍처와 디자인 패턴, DI, 써드파티 라이브러리 도입 등을 통해 안드로이드 개발을 주도적으로 수행했습니다. 어플리케이션의 품질과 사용자 경험 향상을 위한 개발자의 역할을 장기적인 관점에서 학습하고 적용하며, 코드 뿐만 아니라 구조적인 개선점에도 큰 관심을 가지고 있습니다.
지금까지 진행한 모든 프로젝트들에 대해 어플리케이션의 성능 향상과 유지보수성 증가를 위한 여러 디자인 패턴, 아키텍처, 라이브러리 등을 명확한 목적을 가지고 점진적으로 도입하였습니다.

[어려운 문제를 해결한 경험]

1. 4달의 기간 동안 Kotlin 기반의 앱 2개(누도카 & 누도카 파트너스)를 요구사항 분석, 기획, UI/UX 설계, 구현, QA, 배포까지 소프트웨어 생명주기 전반에 걸친 몰입 경험이 있습니다.

2. 파트너스 앱의 경우, 컨슈머와의 상호 작용을 고려한 비즈니스 요구사항 도출부터 배포까지 전 과정을 혼자 도맡아 개발하며 컨슈머 앱과의 연동 작업까지 기간 내에 완료하였습니다.

3. 또한 두 달 간의 개발 이후에 전체 요구사항의 50% 정도가 변경되는 상황에서 4주간의 주 단위 스프린트를 통해 주요 기능의 50% 이상을 꾸준한 리팩토링과 리뉴얼을 통해 요구사항을 맞추며 성능을 개선하였습니다.

<경험 기반의 성취>

1. 좋은 구조가 좋은 코드를 보장한다고 할 순 없지만, 초기에 진행했던 프로젝트들에서는 그것의 장단점/중요성에 대한 인지가 없었습니다.

2. 그 결과 프로젝트가 진행될수록 구조적 개선의 중요성만을 깨달은 상태로 기술 부채가 쌓여가는 것을 경험하였습니다.

3. 디자인 패턴(MVC, MVVM) 이외에는 프로젝트의 특성/확장성/유지보수성을 염두한 아키텍처 설계를 경험해 보지 못하였습니다. 그 당시에 책을 통해 "클린 아키텍처"에 대해 공부하고 있었고, 이상적이라 생각한 구조였기 때문에 프로젝트에 적용하였습니다.
   또한 이를 통해 이상적인 아키텍처에 대해 경험해본다면, 이후 다양한 프로젝트에서 최적의 판단을 하는 데에 도움이 될 것으로 생각하였습니다.

<성취의 성과>

프로젝트란에 작성된 누도카 파트너스와 누도카에 대한 경험을 작성하였습니다.

1. 아키텍처

   1. 아키텍처 설계 단계에 큰 리소스를 투자해서 기술 부채의 바운더리를 크게 감소시켜본 경험이 없었기 때문에, 구조적 개선을 위해 프로젝트의 가장 중요한 특성을 도출해 냈습니다.

   2. 파트너스-컨슈머 앱 간의 상호 작용이 존재하기 때문에 프로젝트 진행 간에 "파트너스/컨슈머의 변경 사항이 컨슈머/파트너스에 전파되는 현상"이 발생할 가능성을 염두에 두었습니다.

   3. "서로 다른 앱 간의 변경 사항 전파"는 서비스 특성 상 배제할 수 없다고 생각하여 파트너스/컨슈머 앱 각각에서 확장성/유지보수성을 최우선 가치로 두고, 변경의 전파를 최소한으로 제한할 수 있는 구조로 설계하였습니다.

      1. 멀티 모듈 구조 + 클린 아키텍처(로버트 마틴)를 적용하였습니다.

      2. Domain 계층은 독립적인 모듈로, Data/Presentation 계층은 모두 Domain 계층 의존적으로 설계하여 저수준 모듈의 변경 사항이 고수준 모듈로 전파되지 않도록 하였습니다.

2. 의존성 주입 및 확장성 증가

   1. 의존성 주입과 Domain-Data 계층 간의 의존성 역전 원칙 적용을 위해 Hilt를 사용하였습니다.(각 모듈 별로 Hilt module 클래스 사용)

3. UI/UX 개선

   1. 사용자의 액션을 끌어내야 하는 화면에 정적인 컨텐츠만 존재하는 상황

      1. Lottie 라이브러리로 CTA 버튼 주변에 동적인 요소들을 배치하여 사용자의 포커스를 이끌었습니다.

   2. 차량 수리 리포트 화면에서 발생하는 1-2초 간의 로딩(다수의 요소/이미지가 존재하는 화면)

      1. Shimmer 라이브러리를 사용한 스켈레톤 로딩을 통해 2초 미만의 지연 시간이 발생하는 요소들의 UX를 개선하였습니다.

   3. 히스토리 백/하이어라키 백 구분

      1. UI/UX 시나리오 내에서 특정 화면들 간의 전환에 대해 화면 전환 전략을 다르게 구성하였습니다.
         ex) 예약 프로세스 중 "주소 검색" 버튼 클릭 시, 외부 개념의 개입이므로 입력 완료 후 화면 전환 시 하이어라키 백 적용

4. 메모리 누수 개선

   1. Debug 모드에서 LeakCanary를 사용하여 메모리 누수를 감지하고, 해당 문제를 모두 개선하였습니다.

   2. RxKotlin의 CompositeDisposable을 사용하여 각 프래그먼트에서 리스너의 할당/해제에 의한 메모리 누수를 방지하고, 보일러플레이트 코드를 감소시켰습니다.

[동료와의 협업]

애자일한 사고를 가지고 스프린트 단위로 목표를 빠르게 달성하는 것을 좋아합니다.
저는 빠르고 정확한 피드백을 기반으로 동료와 함께 문제를 해결해나가며, 팀원들과 목표를 달성하기 위해 협업하는 과정에서 항상 주도적이고 능동적인 자세를 가진 사람입니다.
이런 저의 강점은 업무를 업무 이상의 "풀어야 할 문제"로 바라보는 관점에서 비롯되었습니다. 프로젝트 진행 중에는 제가 가용할 수 있는 모든 리소스를 동원하여 개인적인 공부, 팀 단위로 적용 가능한 개선사항, 더 나은 의사결정을 위한 의견 제시를 하며 완전히 몰입할 수 있기 때문입니다.
그리고 저의 이런 자세는 다른 팀원들에게도 동기부여가 될 수 있다고 생각합니다.