● 예약 서버 (2020.08 ~ 2022.01)
모바일 앱에서 기존 모놀리식 메인 서버를 통해 들어오는 예약을 처리하고,
해당 예약을 B2B 프로덕트인 사장님 솔루션으로 전달하며 푸시 서버로 관련 데이터를 발송하는 역할을 합니다.
단독 개발 및 유지 보수를 진행하였고, 1년 정도 운영 후 새로 합류하신 백엔드 팀원 분들과 협업하며 프로젝트를 진행했습니다.

기술 스택 : Node.js(Express, NestJS), WebSocket(Socket.IO), Redis, AWS(ECS, ECR, RDS, SQS)

잦은 변경이 일어나는 예약 관련 코드에 휴먼 에러 등으로 문제가 생겨 반복적인 전체 서비스 장애 발생

해결 과정

모놀리식 형태의 메인 서버에서 다수의 팀원이 코드 수정을 하다보니,
변경 추적과 수정 시 영향도 파악이 어려워 발생하는 문제라 판단
이를 해결하고자 MSA를 도입해 기존 메인 서버에서 예약 도메인을 분리하여 개발 진행

성과

예약 기능에 장애가 발생해도 다른 서비스로의 장애 전파 방지
다른 도메인 의존성 없이 개별 배포 가능 및 빌드 속도 감소로 인한 배포 속도 상승
예약 수가 약 3배 이상 상승하는 주말에 예약 서버만 Scale-Out하여 대처 가능
각종 알림이 많은 예약 도메인 특성상 비동기 처리가 용이한 Node.js 기술 스택으로 전환

MSA로 분리된 예약 서버가 다운되어 있을 시, 예약 데이터가 유실되는 문제 발생

해결 과정

메인 서버에서 예약 서버로 예약 데이터를 전송 시, 예약 서버가 다운되어 있으면 데이터가 유실되는 현상 발견
예약 서버를 MSA로 분리하여 생긴 문제라 판단, Message Queue를 도입
AWS 기반 인프라에서 비용 효율과 목적에 부합하는 가벼운 Message Queue인 SQS를 선택
메인 서버(Producer) - SQS - 예약 서버(Consumer) 아키텍처 구축

성과

탄력성과 보장성이 확보되어 예약 데이터가 유실되는 크리티컬한 문제 해결
메인 서버와 예약 서버를 디커플링함으로써, 다양한 예약 형태(즉시확정예약, 할인예약, 이벤트 등)의 확장과 같은
비즈니스 요구사항에 유연하게 대응 및 애플리케이션단의 코드 변경 감소로 인한 신속한 개발 가능

예약이 접수되는 사장님 측 B2B 프로덕트와 실제 고객이 예약한 시각의 딜레이로 인한 CS 인입

해결 과정

앱을 통해 접수된 예약을 사장님 측 B2B 프로덕트로 전달하고 확정하는 과정에서,
예약 확인을 위해 10초 주기의 Polling 방식을 사용 중인 것이 문제의 원인임을 확인
양방향 통신이 필요하다 판단, 기존의 Polling 방식 대신 Socket 방식을 도입
Node.js 기반의 웹 프레임워크를 사용 중이었기에 Socket.IO 라이브러리를 사용한 WebSocket을 적용하여 실시간 예약 구현

성과

고객의 예약 후 바로 취소 등과 같은 상황에서 기존 시스템의 데이터 동기화 문제 해결
예약처리담당자 분들의 중복 확인 전화 사장님 측 불만 해결
실시간 예약 처리로 빠른 예약 결과를 원하는 유저 경험 및 서비스 품질 개선
WebSocket을 활용한 다양한 실시간성 기능 구현(사장님 접속 현황, 예약 응대중인 사람 수 현황 등)

빠른 개발 속도를 지향하며 쌓여가는 기술 부채로, 신규 피처 개발이나 팀원 합류 시 높은 허들 발생

해결 과정

초기 스타트업 특성 상 한정된 인적 자원 속 빠른 개발을 지향하여,
정립되지 않은 컨벤션, 아키텍처 등 기술 부채가 계속 쌓여감
기존 프레임워크가 Node.js 기반의 Express였기에, 같은 Node.js 기반의 프레임워크 중
컨벤션과 아키텍처가 정립되어 있는 NestJS로 마이그레이션 진행
비즈니스 로직 리팩토링과 동시에 강타입 기반의 TS를 활용한 인터페이스 정리

성과

주말 기준 예약 서버 평균 응답 속도 0.14초에서 0.02초로 약 90% 개선
ECS 예약 클러스터 상시 컨테이너 수 절반으로 감소, 서버 비용 50% 절감
협업하는데 들어가는 의사소통 비용 감소(새로 합류하는 팀원 온보딩, 코드 리뷰 등)

기능이 확장되며 스케줄, 배치 작업들이 추가됨에 따라 Scale-Out이 불가능한 이슈 발생

해결 과정

스케줄, 배치 작업(서비스에 밀린 예약 수 일정 수준 초과 알림 등)이 추가되어 Scale-Out이 불가
예약 서버 내에서 도메인 별로 서비스를 분리하여 Application, Scheduler, Worker의 형태로 멀티 모듈 구성
수동으로 배포 하기엔 절차가 복잡해져 Jenkins를 도입해 CI/CD 파이프라인을 구축
도커 이미지 빌드 시 환경 변수를 주입해 필요한 모듈만 빌드 시점에 불러오도록 구성

성과

모듈 분리로 인한 스케줄, 배치 작업 중복 실행 방지
Application, Worker의 선택적 Scale-Out 가능
작업들의 상태와 실행 결과를 모니터링 할 수 있는 어드민 시스템 구축

● 푸시 서버 (2020.12 ~ 2022.01)
MSA로 구성된 여러 서버들에 푸시 발송 로직이 파편화되어 있는 문제를 발견하여,
비즈니스적, 개발적인 비효율을 개선하고자 CTO님께 바텀업으로 건의해 시작한 프로젝트입니다.
단독 개발을 진행했으며, 추후 푸시뿐 아니라 카카오 알림톡, SMS/LMS 메시지 발송 기능까지 확장되었습니다.
또한, 마케터 팀원분들이 각종 알림을 GUI 기반으로 편하게 발송하고 결과를 확인하실 수 있도록 어드민 사이트를 개발했습니다.

기술 스택 : Node.js(Express), gRPC, AWS(ECS, ECR, DynamoDB), React

푸시 발송 로직이 서버마다 파편화되어 있어, 변경 및 추가 시 모든 서버를 재배포 해야됨

해결 과정

MSA 환경에서 각기 다른 언어와 프레임워크로 분리된 서버들에,
푸시 발송 로직이 파편화되어 있어 생기는 문제라 판단
이를 해결하고자 도메인을 분리하여 푸시 서버 개발 및 기존 서버들에서 푸시 발송 로직 제거

성과

푸시 관련 로직이 변경되거나 추가될 때마다 모든 서버를 재배포 해야하는 문제 해결
하드 코딩되어 서버별로 파편화 되어 있던 메시지 문자열들의 DB 베이스 템플릿화
각종 알림 서비스의 중앙 제어가 가능해짐에따라 휴먼 에러로 인한 메시지 오타 및 오발송 방지
업무 유관 부서의 비즈니스 요구사항(광고성 푸시 알림 시간 제한, 카카오 알림톡, SMS/LMS 추가 등)에 유연하고 신속한 대응 가능

발송 결과 로그를 DB에 적재하기 시작하면서, RDS Master DB의 Write 부하 증대

해결 과정

문자열 기반 메시지 템플릿들과 단순 로그 성 데이터들은 레코드 간의 관계가 없으므로,
문서 데이터 모델이 적합하다 판단되어 기존에 사용하던 RDBMS DB인 RDS를 사용하지 않고,
운영중인 AWS 기반의 인프라 중 NoSQL DB인 DynamoDB를 도입 및 적용

성과

푸시 서버의 로그를 분리 적재 함으로써 RDS Master DB의 Write 부하 감소
잦은 변경이 일어나는 메시지 템플릿들에 대해 스키마 수정 없이 유연한 대처 가능

각기 다른 언어와 프레임워크로 작성된 서비스 별 클라이언트들의 푸시 서버 호출 로직 파편화

해결 과정

푸시 서버를 분리하여 비즈니스 로직의 일원화는 되었지만, 호출 로직은 여전히 클라이언트 별로 파편화됨
MSA 환경에서 인터널 통신을 효율적으로 하는 레퍼런스를 찾아보다 gRPC 도입
IDL을 작성 및 관리하여, 서비스들이 언어에 따라 쉽게 호출할 수 있도록 라이브러리 형태로 제공

성과

호출 로직의 라이브러리화를 통한 서비스 별 클라이언트 유지보수 용이성 개선
기존 JSON 기반 REST API 통신 대비 데이터 직렬화로 페이로드 크기 감소

푸시 관련 마케팅 활성화로 인한, 개발팀의 단순 백오피스 성 업무 증가

해결 과정

푸시 관련 마케팅(이벤트, 전체 및 특정 타겟군 발송, 지역별 대량 발송 등)이 활성화되면서,
발송 처리를 개발팀이 담당하고 있는 As-Is 업무 프로세스의 비효율 발생
마케팅 팀에서 직접 접근하여 사용할 수 있는 백오피스 어드민 사이트 개발
기술 스택 일원화를 위해 프론트엔드 파트에서 사용 중인 React 선정

성과

마케팅 팀 혹은 비개발 직군의 팀원들도 GUI 기반으로 쉽게 직접 템플릿 추가, 수정, 삭제 가능
전체 유저, 특정 타겟 발송 및 예약 발송 기능 도입
푸시 발송 결과 추적을 위한 모니터링 대시보드 구축

● 메인 앱, 웹 서버 (2020.12 ~ 2022.01)
김캐디 모바일 앱 API들을 담당하는 메인 모놀리식 서버와, MSA로 분리된 김캐디 웹사이트 API들을 담당하는 서버입니다.
기 개발 및 운영 중인 서버를 인계받아 유지보수와 함께 리팩토링했습니다.

기술 스택 : Django(DRF), Celery, AWS(ECS, ECR, RDS, ElastiCache)

계약 매장 증가로 인해 영업팀에서 정산 업무를 더 이상 수작업으로 하기 어려워짐

해결 과정

영업팀이 수작업으로 매장 하나씩 직접 정산하던 문제를 해결하기 위해
지급 대행 Saas를 연동하여 특정일 주기로 자동 정산되는 주간 정산 Batch 시스템 개발

성과

반복적인 업무 프로세스를 자동화하여 영업팀의 비효율 개선 및 업무 부담 감소
휴먼 에러 없이 약 3,500개 매장의 안정적인 자동 정산 처리

레거시 API들에서 N+1 문제 및 Slow Query가 발견됨

해결 과정

서버 인계 후 코드를 파악하며, 레거시 API들의 N+1 문제와 Slow Query 발견
테이블 Join이 일어나는 ORM에는 Eager Loading을 적용하여 N+1 문제 해결
Slow Query가 발견된 부분에는 DB 인덱싱과 캐싱을 적용하여 응답 속도 개선

성과

상시 RDS Read Replica 개수 감소로 인한 비용 절감
API들의 응답속도 향상으로 인한 고객 경험 및 서비스 품질 개선

● 김캐디 사장님 솔루션 (2020.08 ~ 2020.12)
https://owner.kimcaddie.com
스크린 골프장의 예약 접수 및 스케줄 관리를 사장님들이 편하게 하실 수 있도록 도와주는 B2B 솔루션입니다.
실시간 예약 플로우를 구현하기 위해 WebSocket을 적용했으며,
카운터의 포스기 및 키오스크 환경에서도 원활한 경험을 제공하기 위해 Electron을 기반의 데스크톱 앱을 개발했습니다.

기술 스택 : React, Electron, WebSocket(Socket.IO)

Django Template 기반의 As-Is 레거시 사이트를 React로 마이그레이션

데스크톱 앱 개발을 위해 Electron 도입 및 NSIS 기반의 인스톨러 개발

매장현황, 매장정보, 회원관리, 매출관리, 근무자관리 뷰 개발

● 김캐디 웹사이트 (2021.02 ~ 2021.03)
https://kimcaddie.com
김캐디의 메인 웹사이트입니다.
개발을 담당하던 기존 프론트엔드 팀원이 이직하여, 새로운 프론트엔드 팀원을 구할 때까지 대신 개발을 맡았습니다.

기술 스택 : Next.js, Redux, Redux-Saga

골프레슨 뷰 개발

광고 배너 컴포넌트 리팩토링

모바일 반응형 최적화