레몬베이스
레몬베이스 백엔드 개발자
2022.11 - 2025.05
목표 제품 관리
  • 목표 승인 기능을 개발하고, QA에 사용할 승인권자 미리보기 내부 툴 페이지를 구현하여 정책 논의와 테스트 효율을 높임
  • 목표 관리 엑셀 업로드 기능의 성능을 대폭 개선하고, n+1 쿼리 실행을 제거하여 대규모 데이터 처리 속도를 획기적으로 향상
  • 목표 조회 기능 최적화를 통해 처리량과 처리 속도를 크게 개선, 30초 → 0.5초(83% 개선)로 단축. 위계/세부 정보 조회방식을 전면 개편하고 속도 저하 원인 중 하나인 라이브러리 사용을 제거하여 확장성과 유지보수성을 높임.
  • 목표 이벤트 알림 기능을 추가하고, 목표 체크인을 슬랙에서 바로 할 수 있도록 부가기능을 구현하여 접근성과 편의성을 강화.
  • sqs와 celery beat를 도입하여 스케쥴 처리에 대한 인프라 구성
  • 모바일 환경 개선작업으로 목표 간편 체크인 기능 구현하여 목표 제품 접근성을 높이는데 기여
AWS 인프라 비용 절감 TF 참여
  • 파편화 되어 운영되던 ECS 서비스를 도메인 단위로 묶어 하나의 서비스로 구성하여 비용 절감
  • celery 워커를 구성하고 비동기 서비스를 통폐합 하여 인프라 리소스를 정리
  • 작업 시점 기준 월 3,445달러(약 473만 원), 연간 약 41,340달러(약 5,642만 원) 절감
다양한 PoC 작성 및 공유
  • 목표 생성 시 조직도 기반으로 담당자/조직을 선택할 수 있도록 PoC를 React로 구현하여 공유하였으며 제품 반영 진행됨
  • 삭제된 목표 복구, 목표 이동 등 반복 VOC를 반영한 기능을 PoC로 구현하여 제안하였으며 제품 반영까지 진행됨
  • 목표 임시저장, 체크인 시 파일 첨부 등 실사용자 니즈를 반영한 기능을 PoC로 구현하고 제안하였으며 제품 반영까지 진행됨
  • 전체 목표를 한눈에 볼 수 있는 Tree view를 React flow를 사용하여 PoC로 구현하여 제안하였으며, 로드맵에 추가되어 이후 제품에 반영됨
개인별 리포트 분석 기능 개발
  • 데이터팀이 작성했던 기존 R 코드를 분석하고 Python으로 변환하여 개인별 리포트 기능을 구현
  • 제출 완료된 리뷰 데이터를 활용하여 개개인의 질문별 강약점, 자기객관화, 장단점 분석이 가능한 기능 개발
  • RDS 기반의 분석 대기열 구조를 설계하여 개인별 리포트 생성시 리소스 부담이 최소화 될 수 있도록 개선
  • 분석 결과를 정적파일로 생성하는 발행기능을 개발하였으며 제품 변경과 무관하게 결과의 일관성을 보장하였음
야놀자 FNB Solution, 스포카
도도포인트 백엔드 개발자
2021.03 - 2022.10
도도포인트 전체 서비스 도메인 교체
  • 안정적인 도메인 교체를 위해 ELB를 추가하여 도메인 이중화 구성
  • Route53, ACM, LoadBalancer, k8s secret, DB에서 도메인 사용 현황 전수 조사
  • 서비스에서 사용중인 도메인 전체 변경
개인정보 제 3자 동의 정책 반영
  • 개인정보 제3자 동의 여부 갱신 기능 구현
  • 백오피스에서 동의 여부 수정 가능 및 수정 후 사용자에게 알림 기능 구현
  • 매장의 광고 메시지 발신시 동의 사용자에게만 발신되도록 메시지 발신 로직 수정
도도포인트 앱 서버 푸시 기능 구현
  • 도도포인트 서버에서 포인트 활동 이벤트 생성 시 메세지 발신되도록 설계
  • PyFCM 패키지를 사용하여 푸시 기능 구현
  • DocumentDB를 사용하여 푸시 메시지 보관
QA 테스트 백오피스 개발
  • 가상의 사용자 포인트 활동 생성
  • 운영 환경의 매장 데이터 추출하여 개발 환경 매장 데이터로 구성
  • Flask Jinja2를 사용하여 백오피스 페이지 구성
  • 구글 OAuth 적용 하여 접근 제한 구현
도도포인트 앱 API 서버 개발
  • Python 패키지 관리 방식 Poetry로 변경
  • Marshmallow 적용하여 오브젝트의 직렬화, 역직렬화, 데이터 검증
  • 레포지토리 패턴 적용하여 데이터 관리 로직 분리
시티스푸너스
IT 엔지니어
2020.01 - 2021.03
페이스북 광고 비용과 cafe24 매출 데이터 분석을 위한 대시보드 구현
  • Python selenium 패키지를 사용하여 Cafe24 매출 데이터 수집 자동화 기능 구현
  • Google Datastudio를 사용하여 GA 리포트 구성
  • Facebook API로 광고 데이터 수집 자동화 구현 D3.js 사용한 대시보드 구축
사내 ERP 개발
  • AWS EC2 환경에서 Flask와 Nuxt.js를 사용하여 개발
  • Shopify API를 사용하여 주문 수집 자동화
  • Cafe24 API를 사용하여 제품 커스텀 기능 개발 및 주문 수집 자동화
  • 여러 커머스에서 수집된 주문내역을 협력사에 전달 하기 위해 SKU 별 주문수량을 Google API를 사용하여 Gsheet 입력 자동화
마이셀럽스
Data 엔지니어
2018.11 ~ 2020.01
사용자의 얼굴 부위별 색상 추출 모듈 개발
  • Face-alignment, opencv를 사용하여 얼굴 인식 모듈 개발
  • k-means를 사용하여 얼굴 부위별 색상 추출
영화 포스터와 트레일러 영상 전처리
  • k-means를 사용하여 대표 색상 추출 후 색상 검색 모듈 구현
  • yolov3 사용하여 영상의 주요 장면 편집 모듈 개발
이미지 색상을 기반으로한 검색 모듈 개발
  • k-means를 활용한 이미지 색상 추출 모듈 개발
  • 색상 추출 모듈을 사용하여 이미지 색상 추출 후 결과 DB에 저장
  • 색상 검색 결과 최적화를 위해 HSL color space를 활용하여 색상의 계열 구분
  • 색상 계열 구분과 색상 검색 결과를 사용하여 색상 검색 모듈 개발
아라엔지니어링
IT 엔지니어
2015.02 - 2017.12
UnisimDesign, OLGA 제어 프로그램 개발
  • Unisim, Olga, Synergi 프로그램을 제어 할 수 있는 TCP/IP 기반의 프로그램 개발
  • OPC 서버와 통신 하도록 Client 기능 구현
Aveva E3D *.rvm 파일을 *.fbx파일로 변환하는 모듈 개발
  • *.rvm 파일 구조 파악 후 범용 3d 프로그램에서 사용할 수 잇도록 *.fbx로 변환
OTS 제어 프로그램 개발
  • 코드 리펙토링과 메모리 사용 최적화 작업 진행
  • MariaDB를 사용하여 제어 프로그램 현재 상태값 관리
Chart Component 기획 및 개발
  • GDI+를 사용하여 개발 진행 하였으며 Multiple Axis, 드래그를 이용한 Zoom, Mouse tracking 기능 구현
개인별 리포트 분석 결과 정적 파일 생성
문제
분석 결과 생성 후에도 제품의 변경이 분석 결과에 영향을 주지 않도록 분석 결과를 정적파일로 다룰 필요성이 있었음 고객은 분석 결과를 분리되고 독립된 내용이라 이해하였음 분석이 추가되거나 분석 방법이 변경되었을대 분석 결과 조회 페이지에 즉시 반영되는 구조였기에 개선이 필요했음 분석이 완료된 결과는 제품 변경에 영향을 받지 않아야 한다는 요구사항을 만족시켜야 했음
해결 과정
정적파일 생서 서버를 추가하려는 방향을 생각하다 팀원들과 여러 논의를 거쳐 FE의 vike 패키지를 활용하여 기존 코드 기반에서 정적 빌드가 가능한것을 확인하였음 새로운 서버를 구성하지 않고 비동기 worker를 추가하여 빌드만 담당하도록 코드를 추가하였음 서브프로세스를 호출하여 정적파일 생성하고 s3에 업로드 하는 방향으로 정적 파일 생성 작업을 진행하였음 정적파일 생성 결과를 한번에 업로드 하기 위해 aws s3 cli를 사용하였음, 이또한 서브프로세스를 호출하는 방식으로 진행했음 s3는 민감정보를 보관하는 비공개 버킷과 assets을 보관하는 공개 버킷을 구분하였고 공개 버킷에 cloudfront와 route 53 레코드를 추가로 설정하여 외부 접근에 대한 캐시를 구성하였음
평가
부득이하게 ECS에 공통으로 사용되는 백엔드 도커 이미지 파일이 커졌으며 배포 시간도 길어졌음, 이는 이후 도커 이미지를 분리하는 방향으로 개선 하려함 분석 요청 트래픽이 많지 않아 빌드 서버를 분리하지 않는 판단을 내렸음, 오버스펙을 우려하였음 제품 사용 규모에 맞는 구조로 설계하여 요구사항을 만족하였으며 제품 개선이 전보다 자유로워 졌음
레몬베이스 목표 제품 최적화
문제
대규모 고객 (약 3,000명 규모)사용이 예정 되어 있었음 관리하게 될 목표 수가 최대 30,000개로 예상되어 현황 점검이 필요했음 테스트 해보니 최적화가 필요 했으며 30,000개 목표 관리가 가능하도록 최적화를 반드시 진행해야 했음
해결 과정
대규모 고객의 사용 환경과 유사한 상황이 필요했음 QA에 사용할 내부 툴을 만들었음 조직, 구성원을 한번에 쉽게 만들수 있는 툴을 먼저 개발 약 3,000명, 30,000개 목표를 생성하고 속도 저하 구간을 파악하고 문제점 정리하였음 목표 조회 요청부터 DB 조회 응답 반환까지 조회 과정의 전 구간을 나누어 속도를 파악하였음 데이터 독, 프로파일링 사용하여 가장 문제되는 구간을 찾아 작업 우선순위를 정하였음 간단하게 print와 자체 구현한 속도 측정 스크립트도 간단히 사용함 위계 데이터 처리 부분이 anytree라는 오픈소스 패키지를 사용하고 있었음 django orm에서 anytree로 변환시 인스턴스를 생성하는 과정이 시간이 오래 걸리는것을 파악, 개수가 워낙 많아 30,000개 변환에 시간이 꽤나 걸렸음 해당 구간만 c, rust 로 변경하여 시도해보았으나 큰 이점이 없었음 anytree 패키지 사용을 제거하고 필요한 내용만 사용할 수 있도록 유틸 코드를 새로 작성하였음 개선 프로젝트 시작전 30초 성능을 2초 대로 개선하였음
평가
페이지네이션을 적용하고 싶었으나 위계정보를 담고 있기에 페이지네이션 기준이 모호했음 이 기준을 정하는 논의 시간을 길게 가질수 없음이 아쉬움 시간을 투자할지 눈 앞의 문제를 해결할지 트레이드 오프를 고민하였음 일을 두번 하더라도 눈앞에 보이는 문제를 못본척 할 수 없기에 현재 상황에서 구조의 큰 변경없이 할수 잇는 최적화를 하기로 진행하였음
도도포인트 앱 프로젝트 구조 리펙토링
문제
기존 API 서버의 코드는 HTTP 처리와 비즈니스 로직, 데이터 조회 및 처리 코드가 한곳에서 처리되는 상태였습니다. PostgreSQL을 사용하여 데이터를 관리하였으며 새로운 기능이 추가되면서 DocumentDB가 추가되어야 했습니다. 코드가 더 복잡해지기 전에 리팩토링이 필요한 상태였습니다.
해결 과정
개발 리소스 부족으로 전체 서비스 코드를 레이어드 아키텍처로 리팩토링할 수 있는 상황은 아니었습니다. 우선 레포지토리 패턴만 적용하여 데이터 관리 코드를 분리하기로 하였습니다. 데이터 조회 부분을 모두 파악하여 레포지토리 패턴으로 정리하였습니다. 앱 API 서버 기본정보를 다루는 레포지토리 선언부를 추가하고 PostgreSQL이 연결되는 구현체를 작성하였고 푸시메시지 보관 목적을 지닌 레포지토리 선언부를 추가하고 DocuemntDB가 연결되는 구현체를 작성하였습니다
평가
각 API에서 사용하는 쿼리를 파악하여 중복 코드를 줄일 수 있었으며 API 테스트 코드에서 데이터 검증 과정이 제거되면서 테스트 코드가 간결해졌습니다.
비즈니스 로직을 분리하여 서비스 레이어로 구현하지 못한 점이 아쉬움으로 남습니다. 레이어드 아키텍처의 일부분을 적용해 볼 수 있는 좋은 시간이었으며 도메인 주도개발, 레이어드 아키텍처 패턴의 중요성에 대해 다시 한번 깨달았습니다. 서비스 구조에 대해 다시 학습을 시작하게 된 계기가 되었습니다.
도도포인트 앱 매장 목록 조회 속도 개선
문제
현재 사용자의 위치정보를 사용하여 사용자와 가까운 매장목록을 조회하여 매장 썸네일 이미지, 매장명, 매장과의 사용자사이 거리를 보여주는 화면에서 로딩 속도가 3초 이상 지연되었습니다.
해결 과정
매장 목록 조회시 구간을 나누어 속도 검사를 하였습니다. API 요청 후 DB에서 매장 목록을 가져오는 구간, 매장 목록 조회 후 직렬화 하는 과정으로 나누어 수행 속도를 확인하였습니다. 매장 목록 조회 후 직렬화 하는 과정에서 속도가 많이 소비되었으며 다시 구간을 나누어 수행 속도를 확인해보니 매장 썸네일 이미지 URL 조회 단계에 시간이 많이 소비되는 문제였습니다.
SQLAlchemy-ImageAttach 패키지를 사용하여 매장 이미지를 S3에서 관리하고 있었으며 s3의 업로드된 url을 db에 저장하는 방식이 아닌 이미지 파일의 메타정보만 db에 저장하고 이미지 url 접근시 메타정보를 s3에 전달하여 url을 확인하여 전달하는 방식이였습니다.
도도포인트 앱에서 사용할 전체 매장의 썸네일 이미지 URL을 미리 확인하여 Redis에 저장하여 빠른 조회가 가능하도록 구조를 수정하였습니다. 이미지 수정보다는 조회 작업 비율이 월등히 많다는 것을 파악하여 캐시에 저장하여 사용하기로 하였습니다. 약 9,000개 매장의 썸네일 이미지 URL을 매일 새벽에 갱신하도록 celery cronjob을 추가하였습니다.
평가
이미지 로딩 속도를 200ms 이하로 단축할 수 있었습니다. SQLAlchemy-ImageAttach 사용 장점을 유지하고 URL 조회의 단점을 구조 변경 없이 해결하였습니다.
도도포인트 QA 테스트를 위한 백오피스 개발
문제
도도포인트 앱 QA에 사용할 더미 데이터를 수동으로 구성해야 하는 문제였습니다. QA 담당자, PM, 디자이너 각각 맡은 QA를 진행하기 위해 가상의 사용자를 수동으로 만들어야 했습니다. 포인트 적립, 사용 등 포인트 활동을 직접 생성해야 했으며 수동으로 생성하기 힘든 포인트 활동도 있었기에 개선이 필요했습니다.
해결 과정
초기 작업으로 약 70,000명의 가상 사용자를 대량으로 미리 생성하였습니다. QA 대상 기능 중 포인트 적립 형태가 비슷한 사용자들이 방문한 매장을 추천해주는 기능이 있었으며 QA를 위해 대량의 포인트 활동 생성 기능 필요했기에 백오피스에서 포인트 활동 내역이 있는 사용자가 몇 명 필요한지, 날짜 기간 범위는 언제로 할지, 활동 지역은 어디인지 선택할 수 있게 하였습니다. 쿠폰 발급 기능도 추가하여 쿠폰 QA도 가능하도록 기능을 추가하였습니다.
평가
백엔드 개발자의 리소스를 사용하지 않고 QA에 필요한 데이터를 준비할 수 있게 되었습니다. QA 팀에게는 QA 준비 시간을 줄이는 데 큰 도움이 되었으며 PM, 디자이너분들께는 간단한 기능 확인 시 여러 상황을 직접 준비할 수 있게 되어 기능의 만족도가 높았습니다.