미리보기

LG비즈니스 클라우드 서비스를 이용하는 개발자들을 위한 개발자 Docs 사이트를 구현중에 있습니다.

React를 사용하고있으며, React-Query를 이용하여 API 송수신을 다루고 있습니다.

Tailwind로 웹, 모바일의 UI를 구현하고 있습니다.

자비스앤빌런즈(삼점쌈)의 CRM 페이지의 프론트엔드 리뉴얼을 처음부터 끝까지 맡아 작업하였습니다. React 와 Typescript를사용하였으며, 캐싱과 애플리케이션의 데이터 관리에 용이하도록 React-Query를 사용하였습니다. 또한 디자인시스템 적용을 통해 기존에 존재하던 UI의 한계를 개선하였습니다.

React Native를 사용하여 차봇모빌리티의 B2B 애플리케이션 '차봇프라임' 리뉴얼을 진행하였습니다.
신규 디자인 UI구현, API 연동 및 앱 필수 기능 작업 뿐아니라 App Store, Play Store에 심사 및 배포를 진행하였습니다. 추가로 codepush 적용을 통해 업데이트를 반영할 수 있게 하였고 deeplink와 FCM Push Notification 기능을 탑재하였습니다.

중고트럭 거래 플랫폼 스타트업에서 프론트 엔드로 입사하여 1년간 웹사이트,어드민사이트(Next.js), 애플리케이션(React-Native) 개발 및 유지보수를 담당하였습니다.
팀내 백엔드 개발자가 공석인 관계로 Node.js로 API 개발을 함께 진행하였으며, Sequelize를 이용한 MySql의 CRUD 또한 익숙해지는 경험을 쌓았습니다.
추가로 개발서버와 테스트 서버를 새로 개설하는 프로젝트를 담당하여 EC2와 Nginx를 통해 구현하였습니다. 신규 서버를 개설 하며 Github Action을 도입하였고 Dev 브랜치,Test 브랜치에 merge시 자동으로 빌드, 배포되는 환경을 구현하였습니다.
재직 기간 동안 10억원의 투자유치를 달성하였고, 신규 BM에 기획단부터 참여 및 개발을 진행, 출시하였습니다.

프로젝트 목표

• 실서버와 동일한 스펙의 개발서버, QA서버 신규 개설
• github action 도입

프로젝트 진행 계기

• 스펙이 다른 두개의 EC2 인스턴스로 실서버와, 개발서버를 운영
• 개발서버에서 QA 까지 진행->개발과 QA 동시에 진행 되는 경우, 원활한 QA 불가 + 실서버와 스펙이 다르기에 QA 결과를 신뢰 할 수 없음
• 개발서버를 운영하는 인스턴스 메모리가 충분하지 않아(2GB) 인스턴스 재부팅을 하는 경우가 빈번하였음
• 매번 인스턴스 접속 후 수동으로 빌드와 배포를 진행

프로젝트 진행 방법

• AWS AMI를 이용하여 실서버와 동일한 스펙의 인스턴스 한개 생성
• Nginx를 이용하여 port를 나눠서 개발서버와 QA서버 운영
• Test, Development branch 생성 후, github action을 위한 yml 코드 작성
• yml 코드 https://alwaysbin.tistory.com/7

프로젝트 결과

• 실서버와 동일한 인스턴스를 한개만 생성하여 두개의 (Dev, QA) 서버를 운영
• 실서버와 동일한 환경으로 QA가 진행 되기에 QA신뢰도 증가
• QA와 개발을 동시에 진행하더라도 서로 영향을 끼치지 않게 되었음
• 메모리가 2GB->32GB로 증가 되었기에, 메모리가 부족하여 인스터스 재부팅하는 일이 없어짐
• Test, Development 브랜치에 merge시, 자동으로 빌드 후 배포 진행 (반복작업 자동화)

느낀점

• 브랜치에 머지시 따로 테스트 코드를 실행하지 않는데, 테스트 코드작성을 통해, 테스트 단계를 추가해야한다고 생각합니다.
  [개발]-[PR Open]-[Test]-[Merge(test성공 여부에 따라)]-[빌드]-[배포] 의 프로세스로 발전 시키면 좋을 것 같습니다.
• 해결방법을 고민 할때 팀원들과 의논 끝에 하나의 인스턴스에서 개발서버와 QA서버를 운영하기로 결정 하였지만, 시니어개발자와 CTO가 없는 환경에서 주니어들끼리 결정한 본 방법이 올바른 것인가에 대한 생각을 하게 되었습니다.

프로젝트 목표

• 어드민 사이트에서 원하는 유저에게 푸시메시지 발송
• 푸시메시지 터치 시 메시지의 내용에 알맞은 앱 내 화면으로 이동
• 어드민 사이트에서 푸시메시지 열람율 확인

프로젝트 진행 계기

• 기존 개발되어 있던 푸시 기능의 오작동(수,발신이 간혹 안됨)->마케팅 및 유저 공지를 위해 푸시 기능의 정상화 필요
• 수신 대상(유저 타입)이 다양해짐에 따라 개선 및 고도화 필요
• 푸시 알림 터치 시 원하는 화면으로의 이동 필요
• 푸시알림에 대한 트래킹이 미진행, 마케팅 전략 수립을 위한 열람율 확인 및 어드민 사이트에 노출 필요

프로젝트 진행 방법

• https://alwaysbin.tistory.com/6

프로젝트 결과

• 원하는 유저에게 이상없이 푸시 메시지 발신 가능 -> 마케팅 경로로 활용 가
• 푸시 메시지 열람율이 확인 가능해짐 -> 마케팅 전략 수립의 근거로 활용
• 유저가 푸시 알림 터치 시 해당 내용에 맞는 스크린으로 이동
• 푸시 메시지를 수신만 하되, 화면에 띄우지 않게끔 설정하여 ghost push로도 활용

느낀점

• 기존에 FCM 토큰이 세팅 되어 있는 상태에서 프로젝트를 진행하기에 기회가 된다면 처음부터 다시 한번 구현해보면 좋을 것 같다고 생각했습니다.
• React-Native로 구현한 애플리케이션이지만, 사측의 결정으로 안드로이드만 배포하였는데, Push Notification과 관련하여 IOS 버전 또한 다뤄봐야 할 것 같습니다.

프로젝트 목표

• 사진 업로드 시간 단축

프로젝트 진행 계기

• 700KB~900KB 용량 사진 20장 업로드 할 때 1분소요

프로젝트 진행 방법

• react-native-image-resizer 라이브러리를 활용하여, 프론트엔드에서 사진 파일 용량 조절 후 백엔드로 전달하는 방식으로 변경

프로젝트 결과

• 1MB~1.5MB 용량 사진 20장 업로드 할 때 약 8초 소요로 약 52초 단축

느낀점

• 프로세스(프론트엔드에서 용량 축소작업)를 추가하는 방식으로 개선하면서 많은 코드를 수정하지 않고 개선한 부분이 만족스러웠습니다. 문제를 해결하는 것에 있어서 더 열린 시각을 갖게 된 경험이었습니다.

리액트 네이티브를 활용하여 앱 개발을 진행하였습니다.
디자이너가 디자인한 UI의 비율을 모든 기기에서 동일하게 맞추기 위하여 간단한 비율 계산 함수를 만들어 프로젝트에 적용하였고, 오픈소스로 배포하면 좋을 것 같아 배포하였습니다.

https://www.npmjs.com/package/react-native-responsive-sizer
https://alwaysbin.tistory.com/3