복잡한 제품 요구사항을 데이터 모델, API, 캐시, 배치 구조로 풀어 운영 가능한 백엔드로 구현해 온 엔지니어입니다.

Node.js/NestJS 기반 API 서버를 주로 개발해 왔고, 위치 기반 리워드, AI 글래스, SaaS 권한 모델, 외부 회원 연동, 결제/환불 콜백, 데이터 리포트 API처럼 서로 다른 도메인의 요구사항을 API, DB, 캐시, 배치, 외부 API 호출 정책으로 정리해 왔습니다.

제가 잘하는 일은 애매한 요구사항에서 기준이 되는 데이터를 찾고, 즉시 처리해야 할 흐름과 뒤로 미룰 수 있는 흐름을 나누는 것입니다. "통행세 리워드"라는 아이디어를 타일 방문 기록, 소유권 후보 산정, 보상 발생, 정산 배치, 응답 시간 개선으로 나누고, "AI 글래스 도보 안내"라는 요구를 경로 좌표, 허용 영역, 현재 위치, 목적지 거리 변화로 풀어내는 방식입니다.

기술을 선택할 때는 제품의 현재 상태를 먼저 봅니다. 트래픽 규모, 데이터 증가 방식, 조회 패턴, 외부 API 비용, 운영 복잡도를 함께 보고 지금 필요한 구조를 선택하려고 합니다. 비개발자와 협업할 때도 단순히 가능/불가능을 말하기보다, 구현 가능한 범위와 줄여야 할 운영 리스크를 함께 정리하는 편입니다.

제출용 이력서에 담기 어려운 프로젝트 맥락과 기술 판단을 정리했습니다.

• 경력: 6년 10개월
• 주요 기술: Node.js, TypeScript, NestJS, Express, MySQL, MongoDB, Redis, Kafka, ORM/ODM
• 관심 포지션: Node.js/NestJS 기반 백엔드, 제품 백엔드, 운영 서비스 백엔드
• 강점 영역: 도메인 모델링, 위치/이동 데이터 처리, API/DB 병목 개선, 외부 연동, 운영 가능한 구조 설계
• 연락처: feelsky665@naver.com

• 비즈니스에서 제안한 기능을 그대로 API 목록으로 옮기기보다, 어떤 데이터가 기준점이 되는지 먼저 찾습니다.
• 사용자 응답에 꼭 필요한 처리와 후속 처리를 나누고, 제품 경험과 운영 비용 사이에서 구현 범위를 조율합니다.
• 위치, 권한, 회원 연동, 결제/환불처럼 규칙이 다른 도메인을 서버가 처리 가능한 상태와 흐름으로 정리해 왔습니다.

• 트래픽 규모, 데이터 증가 방식, 조회 패턴, 외부 API 비용, 운영 복잡도를 함께 보고 기술 선택을 합니다.
• 타일 획득 로그가 계속 증가하는 구조에서 MySQL 파티셔닝과 MongoDB Sharding을 비교했고, 유저별 조회 패턴을 기준으로 user_id 샤딩 키 구조를 설계하고 테스트했습니다.
• AI 글래스 서버에서는 초기 판매 규모와 리전 상황을 고려해 Pub/Sub보다 REST와 단방향 SSE 기반 구조가 더 적합하다고 판단했습니다.

• 타일 밟기 API에서 사용자 응답 경로와 후속 처리 경로를 분리해, 3초 이상 걸리던 응답 시간을 300ms 이내로 낮췄습니다.
• 세무사 SaaS의 고객사 목록 API에서 Full Scan이 발생하던 Join 조건과 인덱스 구조를 개선해 응답 시간을 13초에서 1초 이내로 줄였습니다.
• 운영 MySQL의 인덱스/컬럼 변경 시 dev DB에서 ALTER 구문을 검증하고, pt-online-schema-change를 활용해 서비스 중단 없이 반영했습니다.

• 사업부의 아이디어를 그대로 구현하기보다, 현재 제품에서 가능한 범위와 운영 리스크를 함께 논의하며 구현 방향을 조율했습니다.
• "안 된다"보다 왜 필요한지, 어떤 지원이 필요한지, 어떤 선택지가 있는지를 설명하며 합의점을 만드는 편입니다.
• 레거시 코드를 볼 때도 구현 세부보다 먼저 비즈니스 플로우와 당시의 의사결정 이유를 이해하려고 합니다.

• 위치 기반 리워드 기능 출시 후 별도 마케팅/이벤트 없이 DAU는 약 5배, MAU는 약 3배, 일 광고 수익은 10배 이상 증가했습니다.
• 월 600만 건 이상 발생하는 타일 획득 로그를 기준으로 통행세 정산과 주간 소유권 후보 산정 배치를 구성했습니다.
• 타일 밟기 API의 사용자 응답 경로와 후속 처리 경로를 분리해 응답 시간을 3초 이상에서 300ms 이내로 개선했습니다.
• 고객사 목록 API의 Join/Index 구조를 재설계해 응답 시간을 13초에서 1초 이내로 개선했습니다.
• AI 글래스 도보 내비게이션에서 TMap API 호출을 최초 1회로 제한하고, 이후 경로 이탈 판단을 자체 좌표 계산으로 처리했습니다.

글로벌 위치 기반 리워드 플랫폼
2024.07 - 2025.11
Node.js Express MySQL TypeORM MongoDB Sharding Mongoose migrate-mongo Redis Kubernetes

StepEarth에서는 서버 개발을 단독으로 담당하며 기능 개발, 배포, 운영 대응을 수행했습니다. 사업부가 제안한 기능 방향을 바탕으로 실제 서비스에서 구현 가능한 정책과 데이터 처리 구조를 함께 논의했고, 통행세 리워드 기능의 백엔드 설계와 개발 전체를 맡았습니다.

문제
StepEarth는 사용자의 이동을 기반으로 리워드를 제공하는 서비스였고, 사용자가 반복적으로 앱을 실행하고 이동 로그를 남길 동기가 필요했습니다. 통행세 리워드는 "타일의 주인에게 다른 사용자의 방문이 보상으로 이어지는 구조"였지만, 실제 제품으로 만들기 위해서는 타일 방문, 소유권, 보상, 정산, API 성능을 함께 설계해야 했습니다.

판단
기능의 기준점은 "사용자가 타일을 정상적으로 밟았다는 기록"이었습니다. 이 기록이 있어야 캐시박스 증가, 통행세 발생, 소유권 후보 산정, 정산이 모두 파생될 수 있었기 때문에, 타일 밟기 API에서는 방문 저장만 즉시 응답에 필요한 핵심 처리로 두고 나머지 파생 처리는 비동기로 분리했습니다.

구현
GPS 좌표를 100m2 타일 단위로 처리하고, 타일 방문 로그를 기준으로 전주에 가장 많이 방문한 사용자를 소유권 후보자로 산정했습니다. 동점자는 먼저 해당 점수에 도달한 사용자를 우선하도록 했고, 매주 월요일 UTC 02시에 전주 순위를 계산하는 배치를 구성했습니다. 월 600만 건 이상 발생하는 타일 획득 로그를 기준으로 일별 통행세 통계와 정산 데이터도 계산했습니다.

임팩트
통행세 기능 출시 후 별도 마케팅이나 이벤트 없이 DAU는 약 5배, MAU는 약 3배, 일 광고 수익은 10배 이상 증가했습니다. 제품 관점에서는 사용자가 앱을 다시 켜고 이동 로그를 남길 동기를 강화한 기능이었고, 서버 관점에서는 위치 로그, 리워드, 소유권, 정산을 운영 가능한 흐름으로 나누는 작업이었습니다.

문제
타일 밟기 API는 사용자가 이동할 때 반복적으로 호출되는 핵심 API였지만, 여러 처리가 한 요청 안에 몰리면서 3초 이상 지연되는 구간이 있었습니다. 사용하지 않는 컬럼 조회, 매핑 구조, 인덱스 부재도 응답 지연에 영향을 주고 있었습니다.

판단
사용자에게 즉시 알려야 하는 것은 "타일을 정상적으로 밟았고 기록이 저장됐다"는 사실이라고 판단했습니다. 캐시박스 증가, 통행세 발생, 정산 대상 처리처럼 이 기록에서 파생되는 작업은 응답을 막고 기다릴 필요가 낮다고 보고 후속 처리로 분리했습니다.

구현
방문 저장을 사용자 응답 경로에 남기고, 캐시박스 증가와 통행세 발생 등 파생 처리는 Promise 기반 비동기 흐름으로 분리했습니다. 동시에 사용하지 않는 컬럼 조회와 매핑 구조를 정리하고, 필요한 조회 조건 중심으로 쿼리와 인덱스를 개선했습니다.

임팩트
3초 이상 걸리던 타일 밟기 API 응답 시간을 300ms 이내로 낮췄습니다. 사용자가 가장 자주 만나는 이동/리워드 흐름의 체감 지연을 줄였고, 이후 리워드와 정산 처리는 별도 흐름에서 처리할 수 있게 됐습니다.

문제
타일 획득 로그는 사용자가 이동할수록 계속 증가하는 데이터였습니다. 기존 구조에서는 로그성 데이터를 조회 테이블처럼 함께 사용하고 있었고, 서비스가 성장할수록 유저별 기간 조회와 통행세 계산이 무거워질 가능성이 있었습니다.

판단
처음에는 MySQL 파티셔닝을 검토했습니다. 다만 월별 파티셔닝은 오래된 기록 조회나 유저별 기간 조회에서 불편이 커질 수 있었습니다. 조회 대부분이 user_id와 기간을 기준으로 발생했기 때문에, MongoDB Sharding 구조를 설계하고 테스트하는 쪽이 더 적합하다고 판단했습니다.

구현
타일 획득 로그를 MongoDB로 옮기는 구조를 설계하고, 유저별 기간 조회 패턴을 기준으로 user_id 샤딩 키를 잡았습니다. 통행세 기능에서 필요한 "특정 타일을 기준으로 일정 기간 동안 몇 명이 방문했는지" 조회는 별도 인덱싱으로 대응했습니다.

임팩트
샤딩 이후 유저별 로그 조회 성능 개선은 테스트로 확인했습니다. 다만 제품 방향 변경으로 본격 운영까지 이어지지는 못했습니다. 이 경험을 통해 데이터 증가 방식과 조회 패턴을 기준으로 저장소와 샤딩 전략을 판단하는 기준을 정리할 수 있었습니다.

• 글로벌 리워드 상품 API와 베트남 오프라인 매장 연동 상품 API를 서버 프록시 형태로 연동해 보안과 정책 통제 지점을 서버로 모았습니다.
• 변경 대상 테이블과 ALTER 구문을 dev DB에서 검증한 뒤 pt-online-schema-change를 활용해 운영 MySQL 인덱스/컬럼 변경을 서비스 중단 없이 반영했습니다.

AI 글래스 Agent 연동 서버
2025.12 - 2026.02
Node.js NestJS MongoDB Mongoose migrate-mongo Redis Python

문제
AI Noon은 AI 글래스 제품이었고, STT, LLM, TTS, 도보 내비게이션이 이어지는 흐름에서 사용자가 체감하는 지연이 중요했습니다. 서버는 한국 리전에 있었고 글로벌 사용자도 있었기 때문에, 내부 통신 구조에서 불필요한 지연을 줄일 필요가 있었습니다. 도보 내비게이션에서는 외부 경로 API를 매번 호출할 경우 비용과 응답 의존도가 커지는 문제도 있었습니다.

판단
초기 판매량과 다음 버전 판매 계획을 고려했을 때, Pub/Sub 구조보다 REST와 단방향 SSE 구조가 제품 상황에 더 맞다고 판단했습니다. 도보 내비게이션도 최초 경로 조회에서 얻은 좌표 리스트를 재활용하면 외부 API를 반복 호출하지 않고도 경로 이탈 여부를 판단할 수 있었습니다.

구현
기존 Pub/Sub 기반 응답 흐름을 REST와 단방향 SSE 기반 구조로 단순화했습니다. TMap API는 최초 경로 조회 1회만 호출하고, 이후에는 TMap이 내려준 경로 좌표 리스트를 기준으로 자체 이탈 판단을 수행했습니다. 각 경로 구간은 5m 오차 범위의 사각형 허용 영역으로 만들고, 현재 좌표가 영역 안에 있는지 확인했습니다.

임팩트
사용자가 허용 영역을 벗어나는지와 목적지에 가까워지는지/멀어지는지를 함께 판단해 경로 이탈 안내를 만들었습니다. 내부 테스트에서는 의도한 방식으로 동작하는 것을 확인했고, 경로 안내 중 외부 API를 반복 호출하지 않는 구조로 바꿔 호출 비용 증가 가능성과 응답 의존도를 줄였습니다.

세무사 SaaS 플랫폼
2022.01 - 2024.06
Node.js MySQL Sequelize

문제
WECAKE에서 고객사 목록은 세무사가 로그인 후 가장 먼저 확인하는 핵심 화면이었습니다. 관리 고객사, 담당 직원, 권한, 회사 매핑 정보가 얽힌 N:M 구조에서 목록 조회가 13초까지 지연되었고, 실제 사용자 측에서도 개선 요청이 들어왔습니다.

판단
단순히 인덱스를 추가하기보다, 고객사 목록에 꼭 필요한 컬럼과 조건을 먼저 산출했습니다. 이후 조회 흐름에 맞게 Join 조건과 조건절 구조를 정리하고, 기존 인덱스가 왜 활용되지 않는지 EXPLAIN으로 확인했습니다.

구현
회사, 직원, 직원 권한, 관리 회사 매핑 테이블의 조회 흐름을 재정리하고 인덱스 구조를 개선했습니다. 업무 화면에 필요하지 않은 조회를 줄이고, 필수 조건 중심으로 쿼리와 인덱스가 맞물리도록 변경했습니다.

임팩트
고객사 목록 API 응답 시간을 13초에서 1초 이내로 줄였습니다. 개선 이후 실제 사용자 측에서 체감 속도가 크게 개선됐다는 피드백을 받았고, 로그인 후 바로 사용하는 핵심 업무 화면의 대기 시간을 줄였습니다.

아모레 뷰티 디바이스 회원 연동 서버
2024.12 - 2025.02
Node.js NestJS MongoDB Redis Kafka

문제
아모레 뷰티 디바이스 연동 앱에서는 아모레몰 회원 DB와 서비스 회원 상태가 함께 움직여야 했습니다. 로그인, 회원가입, 회원 정보 수정, 탈퇴, 계정 연동 흐름에서 두 시스템의 상태가 어긋나면 사용자 경험과 운영 리스크가 함께 커질 수 있었습니다.

구현
OAuth 2.0 기반으로 아모레몰 계정을 이용한 로그인, 회원가입, 회원 정보 조회/수정, 로그아웃, 탈퇴, 계정 연동 API를 구현했습니다. 아모레몰 데이터로 서비스 가입이 가능하고, 서비스에서 가입한 경우 아모레몰에도 자동 가입되는 흐름을 처리했습니다. 아모레몰에서 회원 탈퇴가 발생하면 Kafka 이벤트를 통해 서비스 회원 상태도 함께 탈퇴 처리되도록 구현했습니다.

임팩트
외부 회원 DB와 서비스 내부 회원 상태가 어긋나지 않도록 서버에서 상태 변경 흐름을 통제했습니다. 이미 탈퇴된 회원에 대한 이벤트는 멱등하게 처리하고, 재시도가 필요한 실패는 Kafka 소비 흐름에서 다시 처리되도록 구성했습니다.

네이트온 선물하기 서비스/어드민 외주 개발
2026.02 - 2026.03
Express JavaScript OAuth KG Inicis

문제
네이트온 선물하기 서비스에서는 결제/환불 콜백과 상품 구매 흐름이 정확히 연결되어야 했습니다. 결제 상태가 명확히 확인되지 않은 상태에서 상품 구매가 진행되면 주문/결제 상태 불일치가 발생할 수 있었습니다.

구현
사용자 서비스 화면과 어드민 프론트엔드를 개발했고, KG이니시스 결제/환불 콜백과 소셜 로그인 콜백 처리를 위해 Express 서버를 함께 구현했습니다. 결제가 정상적으로 확인되지 않으면 상품 구매 흐름이 진행되지 않도록 검증과 에러 처리를 강화했습니다.

임팩트
결제사 콜백, 서비스 주문 상태, 상품 구매 흐름을 서버에서 연결해 상태 불일치 가능성을 줄였습니다. 정책상 서버 재시도 처리는 두지 않고, 프론트 중심 결제/환불 처리 흐름과 Express 콜백 서버를 연결했습니다.

Backend Engineer
2024.07 - 2026.02

2024.07 - 2025.11
Node.js Express MySQL TypeORM MongoDB Sharding Mongoose migrate-mongo Redis Kubernetes

• 서버 개발을 단독으로 담당하며 기능 개발, 배포, 운영 대응을 수행했습니다.
• 통행세 리워드 기능의 백엔드 설계/개발 전체를 담당했습니다.
• 타일 방문, 소유권 후보, 통행세 발생/획득, 캐시박스 증가, 정산 배치 흐름을 구현했습니다.
• 월 600만 건 이상 발생하는 타일 획득 로그를 기준으로 일별 통행세 통계와 주간 소유권 후보 산정 배치를 구성했습니다.
• 글로벌 리워드 상품 API와 베트남 오프라인 매장 연동 상품 API를 서버 프록시 형태로 연동했습니다.
• pt-online-schema-change를 활용해 운영 MySQL 인덱스/컬럼 변경을 서비스 중단 없이 반영했습니다.

2025.12 - 2026.02
Node.js NestJS MongoDB Mongoose migrate-mongo Redis Python

• STT, LLM, TTS, 도보 내비게이션으로 이어지는 서버 기능 개발과 통신 구조 개선을 담당했습니다.
• 기존 Pub/Sub 기반 응답 흐름을 REST와 단방향 SSE 기반 구조로 단순화했습니다.
• 사용자 정보, 성격, 보이스톤을 AI 응답에 반영하는 페르소나 기능을 개발했습니다.
• TMap 기반 도보 내비게이션에서 경로 조회 API 호출을 1회로 제한하고, 이후 이동 판단은 좌표 계산으로 처리했습니다.
• Agent 개발자와 협업하면서 intent detection에 연결되는 function 단위 설계를 이해하고 구현했습니다.

2024.12 - 2025.02
Node.js NestJS MongoDB Redis Kafka

• OAuth 2.0 기반 아모레몰 회원 연동 영역을 담당했습니다.
• 로그인, 로그아웃, 회원가입, 회원 정보 조회/수정, 탈퇴, 계정 연동 API를 구현했습니다.
• 아모레몰 회원 탈퇴 이벤트를 Kafka로 전달받아 서비스 회원 상태도 함께 갱신되도록 구현했습니다.

Backend Engineer
2020.12 - 2024.07

2022.01 - 2024.06
Node.js MySQL Sequelize

• 개발자 2명이 제품 전반의 기능을 나누어 개발하는 환경에서 백엔드 API와 성능 개선을 담당했습니다.
• 세무사가 로그인 후 가장 먼저 확인하는 고객사 목록 API의 응답 지연 문제를 개선했습니다.
• 회사, 직원, 직원 권한, 관리 회사 매핑 테이블의 Join 조건과 인덱스 구조를 재설계했습니다.

2021.01 - 2023.11
Python FastAPI MySQL

• 외부 데이터 기업이 1차 가공한 이커머스 판매 지표, 상품 지표, 광고 이벤트 데이터를 제공하는 분석 리포트 API 서버를 FastAPI 기반으로 구축했습니다.
• 판매, 상품, 광고 클릭/접근/구매 이벤트를 리포트 형태로 조회할 수 있도록 데이터 API를 제공했습니다.
• API 서버 분리에 맞춰 JWT 기반 인증 구조를 적용했습니다.
• 분석 데이터 제공 API를 독립 서버로 분리해 리포트 요구사항 변경과 API 확장을 기존 서비스 흐름과 분리해서 처리할 수 있도록 했습니다.

2026.03 - 현재
NestJS TypeScript Prisma Supabase PostgreSQL Redis Terraform GCP Cloud Run

명리학 데이터를 기반으로 만세력 프로필과 운세 해석을 제공하는 개인 서비스를 개발하고 있습니다. LLM에 의존하면 초기 개발은 쉬워지지만 장기 운영 비용, 외부 장애, 응답 일관성 문제가 커질 수 있다고 판단해 데이터 모델과 문장 생성 규칙 중심으로 설계했습니다.

• NestJS 기반 API 서버를 구축하고 Prisma migration을 기준으로 Supabase PostgreSQL 스키마를 관리했습니다.
• Google OAuth, JWT 토큰 재발급, 로그아웃, 회원탈퇴 등 인증 API와 Redis 기반 세션/토큰 흐름을 구현했습니다.
• 만세력 프로필, 오늘/월별/연별/10년 주기 운세 조회, 공유 스냅샷 API를 구현했습니다.
• 사주 원국, 대운 등 명리학 도메인을 RDB 구조로 모델링하고, 문장형 해석 기능을 고려해 도메인 데이터와 해석 생성 흐름을 분리했습니다.
• 저비용 운영을 기준으로 GCP Cloud Run, Supabase, Redis 인프라를 Terraform 기반 IaC로 구성하고 main 브랜치 기준 CI/CD 흐름을 정리했습니다.

• 먼저 비즈니스 플로우를 이해하고, 어떤 데이터가 기능의 기준점이 되는지 찾습니다.
• 사용자 응답에 꼭 필요한 처리와 후속 처리를 나눠 응답성과 운영 흐름을 함께 봅니다.
• 운영 이슈는 이슈 파악, 로그/메트릭 확인, 구조 확인, 에러 가설 수립, 데이터량/지표 확인, 구조 및 로직 변경 순서로 접근합니다.
• 기술 선택은 제품 규모, 조회 패턴, 외부 의존도, 운영 복잡도를 함께 보고 결정하려고 합니다.
• AI Agent 기반 개발 도구를 활용해 레거시 파악, 반복 구현, 변경 영향 범위 확인을 보조하고 있습니다.

• 디케이이노베이션 Backend Engineer, 2020.01 - 2020.04
  Python Django PostgreSQL
  제조 현장의 이슈 및 일정 관리 시스템을 개발했습니다.

• 에스포엔 Backend Engineer, 2018.08 - 2019.10
  Java Spring MongoDB PostgreSQL
  실시간 웹 모니터링 및 위험 감지 시스템의 로그 적재/통계 조회 기능을 개발했습니다.

• 한국방송통신대학교 컴퓨터과학과 재학, 2025.01 -
• 동아방송예술대학교 음향제작과 중퇴, 2010.03 - 2011.12

Node.js TypeScript NestJS Express MySQL PostgreSQL MongoDB Redis Kafka ORM/ODM Python FastAPI Kubernetes AWS GCP Terraform