안녕하세요! 다나입니다
2023년 동안 업무를 효율적으로 진행하기 위해 다양한 일감들을 진행했습니다. 그 중 몇 가지 주요 일감들을 소개하고자 합니다.
저는 네이티브셀의 Android 개발자로, 주로 네이티브 및 Android 관련된 내용인 점 참고 부탁드립니다
1. Firebase 활용
Crashlytics 연동 및 Slack 연동
1.
AS-IS
•
CS / VOC를 통해서만 이슈 발생 파악 가능했습니다.
•
이슈 발생 시 정보 부족으로 발생 원인 및 해결 방안 모색이 쉽지 않았습니다.
2.
TO-BE
•
Crashlytics 연동
◦
안정성 향상 및 빠른 이슈 해결
앱이 비정상적으로 종료되거나 충돌할 때 해당 이유와 관련된 자세한 정보를 수집하며, 앱의 이슈와 충돌에 대해 거의 실시간으로 리포트 제공합니다.
이를 통해, 사용자가 어떤 조건에서 이슈가 발생하는지 빠르게 파악이 가능하며, 이를 해결함으로써 사용자에게 더 나은 경험을 제공하고자 했습니다.
◦
버그 식별 및 우선순위 지정
우선순위에 따라 정렬하여 가능하여 가장 심각한 이슈를 빠르게 식별하고 해결할 수 있었습니다.
◦
사용자 영향도 파악
어떤 사용자에게서 얼마나 자주 이슈가 발생하는지, 특정 기기나 운영체제에서 이슈가 발생하는 지 등 파악이 가능했습니다.
•
이슈 발생 시 빠른 대응을 위해 Slack을 함께 연동
◦
실시간 알림
앱에서 비정상 종료나 충돌이 감지되면 실시간으로 Slack으로 알림이 전송되도록 설정했습니다.
이모지를 통해
▪
누가 이슈를 대응하고 있는지(이슈를 확인 했는지), ▪
해결되었는지, ▪
지금 당장 처리 할 필요 없는 이슈인지 구분을 하였습니다.또한, 해당 이슈의 담당자를 지정함으로써, 중복으로 대응하는 현상을 줄일 수 있었습니다.
즉, 이슈 발생 즉시 인지하고 신속하게 대응할 수 있었습니다.
◦
로그 및 이슈 공유
전송된 알림을 바탕으로 Crashlytics에서 수집된 로그나 정보를 쉽게 공유가 가능했습니다.
이를 통해, 셀원들이 동일한 정보를 기반으로 이슈를 해결할 수 있었습니다.
Performace 연동
•
실시간 성능 감지
◦
앱 성능에 관련되어 중요한 부분에 맞춤 설정하여 메일로 즉각 받아볼 수 있도록 알림을 설정했습니다.
◦
해당 이슈가 사용자에게 큰 영향을 주기 전에 성능 이슈를 발견하여 대응할 수 있었습니다.
•
앱 시작 시간 / 네트워크 요청 등 측정
◦
어떤 요소가 앱 시작을 지연시키고 있는지 확인이 가능했습니다.
◦
서버와의 통신에 대한 지연이나 오류를 식별하여 최적화가 가능했습니다.
Remote Config 도입
1.
AS-IS
•
앱에서 기능을 변경할 시에는 앱 업데이트가 필요했었습니다.
•
업데이트를 줄이기 위해, 자주 변경되는 문구나 화면일 경우에는 웹뷰로 구현하거나 API에서 Data를 받아서 직접 구현했었습니다.
2.
TO-BE
•
웹프론트, 백엔드의 의존성을 줄이기 위해 Remote Config 도입하였습니다.
•
앱의 설정이나 콘텐츠를 앱 업데이트 없이도 실시간으로 반영 가능하여, 사용자에게 즉각적으로 변경사항을 제공할 수 있었습니다.
•
네이티브 인력만으로도 간단한 기능 구현이 가능해졌습니다.
•
Remote Config로 만든 메뉴 배너
Remote Config Value
메뉴 배너로 문구, 링크, 노출 여부를 Remote Config에 따라 적용되어 있음
(현재: 공비서 추천하고 혜택받기!)
App Distribution
공비서 CRM은 내부 테스트가 용이하도록 이미 App Distribution을 활용하고 있었는데요.
7월에 출시한 공비서 비즈콜도 마찬가지로 App Distribution을 활용하여 내부 테스트 시 직접 수기 배포하는 등의 번거로움을 줄였습니다.
자세한 내용은 다음 블로그 글을 참고해주세요!
2. Mono Repo
흩어져 있는 공비서 관련 프로젝트를 하나의 repo에서 관리하도록 적용했습니다.
Android의 Mono repo 적용기는 다음 글에서 더욱 자세히 다루도록 하겠습니다. (기대해주세요)
)1.
AS-IS
•
각 앱(프로젝트)별로 repo 존재했습니다.
◦
공비서 b2b Android repo
◦
공비서 b2c Android repo
◦
공비서 bizcall Android repo
•
repo가 각각 존재하므로,
◦
다른 프로젝트 관리가 소홀해졌습니다.
◦
프로젝트 간의 코드 공유가 어려워 코드 중복 위험이 증가하며, 프로젝트 마다 컨벤션 유지가 어려웠습니다.
◦
공통 로직/의존성 분산되어 관리가 어렵웠습니다.
◦
프로젝트 생성 시 마다 개발 환경 세팅을 매번 새로 해주어야하는 번거로움이 있었습니다.
2.
TO-BE
•
공비서 Android repo (하나의 repo에 multi-module 로 구성)
◦
common
◦
network
◦
buildSrc
◦
공비서 b2b
◦
공비서 b2c
◦
공비서 bizcall
•
한 번에 여러 프로젝트 작업이 가능해졌습니다.
◦
특히, 다른 앱들을 빌드 할 경우 해당 프로젝트를 열지 않아서 편리했습니다.
•
프로젝트 간에 코드를 쉽게 공유할 수 있어 보다 효율적인 코드 재사용이 가능했습니다.
◦
수정이 필요한 경우에도 한 곳(Network Module)에 있기 때문에 유지보수에 용이했습니다.
◦
b2b와 bizcall은 같은 API를 사용하는데 중복으로 구현하지 않아서 편리했습니다.
•
모든 프로젝트에서 동일한 버전의 종속성을 사용하여 호환성 문제와 잠재적인 버그를 줄일 수 있었습니다.
◦
Android Target Api 수준이 바뀌어 version을 33으로 올리는 경우에 정말 용이했습니다!
3. 서버 / 웹서버 변경 화면 구현
공비서는 스크럼 조직마다 다른 서버 환경(dev1 ~ dev5)을 가지고 있습니다.
가끔은 자체 테스트를 하기 위해 로컬 서버 환경으로 설정해야하는 경우도 있습니다.
1.
AS-IS
•
QA나 기타 확인 사항이 있을 경우 해당 서버 조건대로 프로젝트에서 서버 수정 후 앱 빌드 및 배포 했습니다.
2.
TO-BE
•
서버/웹 서버를 변경할 수 있는 화면을 구현했습니다.
◦
debug mode에서만 서버 변경 화면 진입이 가능한 버튼을 구현했습니다.
▪
로그인 우측 상단: 로그아웃 상태일 때 변경 가능하도록
▪
메뉴 최하단: 로그인 상태일 때 변경 가능하도록
◦
자주 사용하는 서버는 쉽게 선택할 수 있도록 라디오 버튼으로 구현했습니다.
◦
로컬 빌드 및 예외 서버를 직접 입력할 수 있도록 직접 입력 가능한 필드도 추가했습니다.
•
하나의 앱으로 다양한 서버에 접근 가능하므로,
각 스크럼마다 요청하는 앱을 따로 빌드 및 배포하는 시간이 감소되었습니다.
4. 회의 방식 도입
1.
AS-IS
•
즉각적인 회의 시작과 명확하지 않은 아젠다
◦
참여자들의 아젠다에 대한 이해도가 각각 다를 수 있어, 관계 없는 이야기로 흘러가는 경우가 발생했습니다.
◦
결정(다음액션)을 해야하는 시점에서 아젠다 파악에 소요되는 시간이 증가했습니다.
◦
대안이 필요한 안건은 그 자리에서 생각하다보니, 시간이 오래 걸렸습니다.
◦
이 부분이 회의가 길어지는 요소 중 하나였으며, 결론이 나지 않은 이유였습니다.
•
무제한 회의 시간
◦
종료 시간이 정해져 있지 않은 회의는 지나치게 길어져 참여자들의 피로도를 증가시켰습니다.
◦
많은 시간을 할애하는 회의로 인한 업무 효율성이 저하되는 경우도 있었습니다.
•
분산된 회의록
◦
하나의 회의록 보다 각각 일감 문서에 작성하다보니, 회의 내용이 파편화되어있는 경우가 있었습니다.
◦
파편화된 회의 내용으로 찾기가 힘들거나, 다시 회의 하는 경우가 발생했습니다.
2.
TO-BE
•
계획된 회의 시작과 명확한 아젠다 설정
◦
회의 시작 적어도 2시간 전에는 회의의 목적, 다뤄야할 아젠다가 담겨있는 회의록을 작성하여 참여자들에게 사전 공유를 했습니다.
◦
미리 작성된 회의록을 보면서 각자 필요한 부분, 더 추가해야 하는 부분을 정리했습니다.
◦
회의 중 주제에 상관없는 다른 예외나 논점에 벗어나는 의견은 우선 중단하고(큰 주제는미리 작성) 관련된 다음 회의로 연기했습니다.
◦
이를 통해, 아젠다에 대한 이해도 향상 및 회의 시작 시 효율적으로 진행 가능했습니다.
◦
특히 무언가를 결정해야하는 회의인 경우 현재의 상황과, 대안 여러개를 미리 작성해 놓으면 시간을 많이 단축 할 수 있었습니다.
예시) 비즈콜 예외 사항 논의 중 case3
•
제한된 회의 시간
◦
회의 시간은 최대 1시간을 넘기지 않도록 했습니다.
◦
회의를 자주하게 되는 경우가 있었으나, 시간이 짧아 피로도가 덜 했습니니다.
오히려, 빠르고 잦은 회의로 개발이나 기획 중 이슈를 빠르게 대응 할 수 있었습니다.
◦
만약 결론이 나지 않을 경우에는 쉬는 시간(생각을 정리하는 시간)을 가지기 위해 다음 회의를 예약하여 생산성을 높였습니다.
•
일원화된 회의록 관리
◦
회의 중에는 미리 작성된 회의록에 추가 정보를 작성하였습니다.
◦
회의 종료 후에는 문서관리를 한 곳으로 하기 위해 정책 관련은 기획/디자인 팀에서 회의록을 참고하여 최신화하였습니다. (동기화를 활용하면 아주 편리합니다!)
◦
회의록과 정책 문서 관리를 잘해 레거시로 인한 UI, 로직이 다른 세 플랫폼이 동일하게 구현할 수 있었습니다.
•
요즘은 회의자체를 줄이기 위해 Q&A 형식으로 작성후 끝내는 경우도 있습니다
예시) B2C 디자인 시스템 논의 중 일부
5. Mock API 개발
1.
AS-IS
•
디자인 기반으로 UI를 먼저 구현하고 실제 API가 완성될 때까지 기다린 후 연결하는 식으로 작업을 진행했습니다.
•
프로젝트 중간에 텀이 생겨 몰입도가 깨지거나, 프로젝트 끝 무렵에 급하게 작업하는 경우가 많이 있었습니다.
2.
TO-BE
•
기획 및 디자인 단계에서 백엔드 셀과의 협의를 통해 Mock API나 데이터를 미리 얻을 수 있었습니다.
◦
미리 나오는 end-point와 resquest param / respons Json을 활용해 Mock API를 구현했습니다.
•
백엔드 셀에서 실제 API를 개발하는 동안 네이티브셀은 이미 디자인과 Mock API를 활용하여 화면의 초기 버전을 만들어 놓을 수 있었습니다.
•
나중에 실제 API가 완성되면 해당 API로 간단히 교체하여 최종 화면을 완성할 수 있었습니다.
이러한 일감들을 통해, 효율적인 업무 진행 및 협업 환경 개선에 크게 기여하고자 노력했습니다.
더 나은 결과를 위해 노력하고자 하니, 피드백이나 추가 질문이 있으면 언제든지 말씀해주세요!
앞으로도 더 나은 방법과 기술을 찾아 적용하여 발전해 나가겠습니다.
앞으로도 더 나은 방법과 기술을 찾아 적용하여 발전해 나가겠습니다. 감사합니다!