미리보기

• 기상 API 서비스 개발

  • 클라이언트에서 API 요청을 통해 비 구름 위성 영상을 다운로드 받을 수 있는 API 개발

• 어드민 페이지 고도화

  • 기존에 개발되어 있는 어드민 페이지를 현재 상황과 요구사항에 맞게 고도화 작업 진행

• 헬리오스 모바일 앱
  • 기존 React Native 로 개발된 앱을 Flutter 로 전환
• 알림톡 전송 서버 개발
  • 자사 솔루션 내에서 개별적으로 사용 중인 카카오 알림톡 전송을 통합적으로 관리하기 위한 API 서버 개발
• 화재 감지 기능 개발
  • 케이스 분석을 통한 화재 감지 기능 개발
• 기존 솔루션 레거시 코드 개선
  • 웹 URL 변경
  • 코드 단에서 관리 중이던 정보 DB로 이관
• 팀 내 개발 안정화를 위한 테스트 서버 도입
  • 운영 서버와 동일한 환경의 테스트 서버를 도입하여, 운영 서버 배포 전 테스트를 통한 개발 안정성 상승
• 테스트 코드 도입
  • 팀 내 테스트 코드가 전무한 상황에서 테스트 코드 도입을 위한 테스트 코드 중요성 공유 및 도입 시도
• 팀 내 Git을 통한 버전 관리 정착
  • 팀 내 Git 사용법 및 컨벤션 공유 및 정착
  • Git flow 지점브랜치 전략 공유 및 정착
• 개발 문화 만들기
  • 깃 헌깃헙 PR을 통한 코드 리뷰 도입 시도
  • Jira, Slack 등 협업 도구 도입 시도

기상 API

• 클라이언트에서 API 요청을 통해 기상 영상을 다운로드 받을 수 있는 API 서비스 개발

기술 스택

• Kotlin

• Spring Webflux

• Google Cloud Run

어드민 페이지 고도화

• 기존에 API 로만 존재하던 어드민 페이지를 프론트엔드와 연동 및 현재상황과 추가 요구사항에 맞도록 고도화 작업 진행

기술 스택

• Kotlin

• Spring Webflux

• Google Cloud Run

헬리오스 모바일 앱 기술 전환

기존 React Native 로 개발되어 있던 모바일 앱을 Flutter 로 전환하는 작업을 진행

• React Native 로 개발되어 있던 기존 어플이 잘 괸리 되지 않아 의존성 문제 등 이 지속적으로 발생하여, 지속 관리를 위한 정리가 필요한 상황 발생
• Flutter 전환 이유: React Native 보다. 접근성 측면에서 러닝커브가 낮았고, 지속적으로 라이브러리들이 관리되고 있는점 그리고 React Native 기술보다 Flutter 에 더 많은 사람들이 관심을 가지고 있다는 점으로 인하여 Flutter 로 의 전환을 결정
• 고객의 요청에 따라 지속적으로 화면이 변경되어야 하는 솔루션의 특성상 WebView 를 사용하여 전반적이 화면을 개발
• FCM 알람, 로그인 처리, 알람 on/off 등 필수적으로 flutter 단 에서 처리해야하는 내용에 대해 개발을 진행
• 기존 관리가 어려웠던 라이브러리에 대한 문제 발생으로, 최소한의 라이브러리를 사용하여 개발을 진행하였고, 사용하더라도 공식적으로 개발어 관리되고 있는 라이브러리를 사용
• 상태 관리에 (Bloc 등) 필요한 기술은 학습 곡선 및 프로젝트 크기를 생각하여, 사용하지 않고 직접 상태 관리를 진행
• API 요청을 처리하는 백엔드 서버 쪽 작업도 함께 진행

기술 스택

• Dart
• Flutter
• FireBase
• DRF(Django REST framework)

알림톡 전송을 위한 Rest API 서버 개발

레거시 코드에서 초당 500건 이상의 알림톡 전송 요청이 발생하는 경우 알림톡 전송을 하지 못하는 문제 발생, 문제 해결 및 알림톡 전송 통합 관리를 위한 API 서버 개발

• 개발 기술선정 부터 아키텍처 설계 및 개발까지 프로젝트 전 과정 리드로 참여
• 알림톡 처리 방식 변경
  • 개별 솔루션의 프로세스에서 알림톡 처리 -> API 요청을 통한 처리
• Python UnitTest 를 통한 테스트 코드 작성
  • Test Coverage: 95%

기술스택

• Python
• Fast API
• RabbitMQ

자사 솔루션 레거시 코드 개선 및 추가 기능 개발

• 화재 감지 기능 개발
  • 케이스 분석을 통한 화재 감지 기능 개발
• 알림톡 전송 방식 변경
  • Redis Pub/Sub 을 활용한 알림톡 전송 방식을 API 요청을 통한 전송 방식으로 변경\

기술 스택

• Python
• Django
• MariaDB
• Redis
• WebSocket

자사 솔루션 레거시 코드 개선 및 추가 기능 개발

• 웹 URL 변경
  • URL 에서 각 사이트를 구분하던 부분에 문제가 발생하여, 프로젝트 내에서 사용중이던 모든 URL 변경과 DB PK 값 변경
  • URL 변경 후기
• 코드 단에서 관리 중이던 정보 DB로 이관
  • Python Dictionary 를 사용하여 관리중이던 데이터를 DB 로 이관하고, 데이터 접근 및 처리 방식 변경
• 팀 내 개발 안정화를 위한 테스트 서버 도입
  • 별도의 테스트 서버 없이 운영중이 서비스에 운영 환경과 동일한 환경에서 테스트를 할 수 있도록 테스트 서버를 구성

기술 스택

• Python
• Django
• MariaDB
• Redis
• WebSocket

GitHub Repository의 Issue 관리 시스템 구현

• 협업
  • 프론트엔드 2명 그리고 백엔드 2명 으로 이루어진 팀에서 깃헙과 디스코드를 통한 협업 진행
  • 백엔드 개발 시 도메인 단위로 개발 단위를 쪼개 협업 진행, 문제 발생 시 함께 트러블 슈팅 진행
• 클라우드 서버 구조 구성
  • AWS 클라우드 환경에서 서버 구조 구성
  • 백엔드: EC2 2 대를 활용하여 각각 API 서버와 DB 서버로 구성
  • 프론트엔드: S3 와 Cloud Front 를 활용하여 프론트 서버 구성
  • 공통: Route 53 을 통한 도메인 관리 및 HTTPS 환경 구성
• API 설계
  • 사용자 요구사항에 맞는 CRUD API 설계
• DB 설계
  • 사용자 요구사항에 맞는 DB 설계 및 Mysql(RDB) 사용
  • JWT 의 RefreshToken 관리를 위한 Redis(NoSQL) 사용
• CI/CD 를 통한 생산성 증가
  • 계기
    • 코드 변경 시 매번 배포에 많은 소요 시간 발생
  • 성과
    • GitHub Action-Docker 를 활용한 자동배포 진행
    • 특정 브랜치에 변경사항이 발생할때 마다 자동적으로 배포를 해주어 배포에 소요되는 개발 리소스가 매우 줄어들었다.
• Spring Rest Docs 를 활용한 API 문서화
  • 계기
    • GitHub Wiki 에 수동으로 API를 문서화 하고 있었는데, API 가 변경될때 마다 변경을 해줘야 하는 불편함이 발생
  • 성과
    • Spring Rest Docs 를 사용하여 API 문서화 진행
    • 단순히 문서를 보는것이 아니라 CLI 를 통해 API를 테스트 할 수 있도록 변경되었다.
• 단위 테스트 작성
  • 계기
    • 프로젝트가 점점 커지면서 모든 API 의 대해 검증을 하기 어려움이 발생
  • 성과
    • 테스트 커버리지 Class 88% | Method 78% | Line 78% 달성
    • API의 변경이 있을때 검증을 쉽게 할 수 있게되었다.
• N + 1 쿼리 최적화
  • 계기
    • 모든 이슈 조회 시 N + 1 문제가 발생하면서, 이슈 조회 시 30초 가량의 시간이 소요
  • 성과
    • 모든 이슈 조회 시 발생하던 N + 1 문제를 해결하여, 이슈 조회 시 0.12 초의 시간이 소요되도록 변경되었다.

식약처 공공 빅데이터 유효성 검사와 공공데이터 포털 사이트 관리 및 개선