Full-stack Developer

업무를 이해하고, 현장에서 사용하는 시스템으로 풉니다.

팀원들과 요구사항과 제약을 맞추고, 문제의 원인을 먼저 정리합니다. 그 다음엔 현업 흐름에 맞춰 설계→구현→배포까지 이어갑니다. 기능을 ‘만드는 것’보다, 실제 업무 흐름에 정착시키는 데 집중합니다.

View selected work

Primary Case Study

Inventory Management & Reorder Recommendation

재고 관리 및 추천 발주 시스템

Excel에 묶여 있던 재고와 발주 판단을, 물류·마케팅팀이 매일 여는 내부 시스템으로 옮겼습니다.

Context

업무가 파일 안에 있었습니다

기존에는 Excel 함수로 재고와 비용을 관리했습니다. 숫자는 있었지만, 그 숫자로 일하는 방식은 파일과 담당자에게 묶여 있었습니다.

  • 접근 권한과 보안을 체계적으로 다루기 어려움
  • 데이터와 업무 프로세스가 Excel에 강하게 의존
  • 재고 판단과 발주량 결정이 담당자 경험에 크게 의존
  • 같은 작업을 반복하는 수작업이 매일 발생

Role

요구사항부터 운영 피드백까지

이 시스템은 사내 물류팀과 마케팅팀을 위한 내부 도구입니다. 요구사항을 정리하고, 설계·구현·배포, 사용 중 피드백 반영까지 한 흐름으로 진행했습니다.


Problem Discovery

채널마다 업무가 달랐습니다

판매 채널이 다양했고, 물류와 마케팅이 원하는 것도 같지 않았습니다. 처음부터 하나의 고정된 요구사항을 구현하지 않았습니다.

실무 담당자와 반복해서 만나며 기존 업무를 보고, 공통점과 예외를 나눈 뒤 범위를 조정했습니다. 만든 뒤에는 실제 사용 피드백을 다시 반영했습니다.

  1. 01기존 업무 프로세스 파악
  2. 02채널별 차이점 확인
  3. 03공통 업무와 예외 업무 구분
  4. 04요구사항 조정
  5. 05실제 사용 피드백 반영

Solution

판단을 대체하지 않고, 데이터로 보조합니다

Next.js로 내부 업무 시스템을 만들었습니다. 재고와 판매 데이터를 기준으로 추천 발주량을 계산합니다.

추천 로직은 판매량, 재고 회전량, 상품 단가 등 실제 발주에 쓰이는 변수로 구성했습니다. 담당자의 경험을 없애는 기능이 아니라, 매일의 판단을 데이터로 받쳐 주기 위한 기능입니다.

  1. 01

    Business Process

    기존 업무가 흘러가던 방식

  2. 02

    Inventory / Sales Data

    재고와 판매 데이터

  3. 03

    Calculation & Reorder Logic

    비즈니스 변수 기반 추천 발주

  4. 04

    Cached Result

    업무 주기에 맞춘 캐시 정책

  5. 05

    Internal Web Application

    Next.js 내부 업무 시스템

  6. 06

    Logistics / Marketing Team

    매일 사용하는 현업 팀

재고와 판매 데이터가 추천 발주로 계산되고, 캐시를 거쳐 현업 화면에 도달합니다.

Performance

캐시 수명이 아니라, 업무가 값을 필요로 하는 시점을 기준으로 정했습니다

추천 발주량은 담당자가 화면을 열 때마다 달라져야 하는 값이 아니었습니다. 재고·판매 데이터가 갱신된 뒤에야 판단 기준이 바뀌므로, 캐시도 그 업무 흐름에 맞춰 설계했습니다.

  1. 01 Process

    물류·마케팅팀이 발주를 확인하는 ‘작업 시점’과, 원본 데이터가 갱신되는 ‘데이터 유효 주기’를 먼저 맞췄습니다. 그 기준에 따라 계산은 필요한 순간에만 재생성되게 설계했습니다.

  2. 02 Policy

    캐시를 무작정 짧게 두지 않았습니다. 데이터가 유효한 동안은 계산 결과를 유지하고, 원본이 갱신되면 만료 대기 없이 무효화했습니다.

  3. 03 Outcome

    계산은 요청 수가 아니라 데이터 갱신에 묶이게 했고, 담당자는 같은 입력 버전 기준의 추천을 일관되게 사용했습니다.


Deployment

매일 사용하는 시스템이라 배포가 업무를 끊으면 안 됐습니다

내부 사용자가 하루에도 여러 번 여는 도구입니다. 배포 중에 화면이 멈추면 그 시간 동안 업무가 멈춥니다.

Docker 이미지로 빌드한 뒤 Blue-Green으로 전환하고, CI/CD로 그 과정을 반복할 수 있게 만들었습니다. 목표는 신기술 도입이 아니라, 업무가 끊기지 않는 배포였습니다.

  1. 01

    CI/CD

    검증 후 배포 가능한 상태로 만듭니다

  2. 02

    Docker Image

    같은 환경으로 반복 배포합니다

  3. 03

    Blue Environment

    현재 트래픽을 받는 환경

    04

    Green Environment

    새 버전을 올리는 환경

  4. 05

    Traffic Switch

    준비되면 전환하고, 업무 중단을 줄입니다

새 버전을 반대 환경에 올린 뒤 트래픽만 옮겨, 배포 중 업무 중단을 줄입니다.

Result

일상 업무에 자리를 잡았습니다

물류팀과 마케팅팀이 매일 사용하는 시스템으로 정착했습니다.

발주 준비에 걸리던 시간은 대략 2시간에서 10분 안팎으로 줄었고, 매일 약 30명이 사용합니다. 숫자보다 중요한 것은, 더 이상 Excel을 우회하지 않고 이 시스템으로 일하게 됐다는 점입니다.

Secondary Project

Commerce Intelligence & Marketing Automation

커머스 인텔리전스 및 마케팅 자동화

여러 커머스 플랫폼에 흩어진 데이터를 모아, 마케팅팀이 의사결정에 쓸 수 있는 정보로 바꿨습니다.

마케팅팀이 필요한 정보는 한곳에 있지 않았습니다. 검색 순위, 가격, 리뷰가 플랫폼마다 달랐고, 매번 직접 확인하는 방식으로는 비교가 어려웠습니다.

크롤링 자체가 목적이 아니었습니다. 외부에서 수집한 데이터를 구조화하고, 팀이 반복해서 볼 수 있는 화면과 자동화로 연결했습니다.

React · FastAPI · Python/쿠팡 · 에이블리 · 오늘의집 · 네이버 · 1688

Search & Ranking Tracking

판매 플랫폼의 검색 결과와 상품 순위를 모아 시간에 따라 추적합니다.

Enhanced Search

플랫폼이 충분한 필터를 주지 않는 경우, 수집한 데이터로 더 세밀한 내부 검색을 제공합니다.

Competitive Analysis

자사 상품과 경쟁 상품의 가격 변화를 비교하고, 그래프로 확인합니다.

Review Intelligence

상품 리뷰를 수집하고, AI로 요약해 많은 리뷰를 빠르게 파악할 수 있게 합니다.


Secondary Project

Order & Inventory Reconciliation Pipeline

주문·재고 데이터 연동 시스템

수십 가지 플랫폼의 주문·재고·택배 흐름을 수집·정규화해, 하나의 운영 관점으로 묶었습니다.

  1. 01

    Marketplace / Platform

    수십 플랫폼의 주문 데이터 수집

  2. 02

    Normalization & Mapping

    상품/주문 상태 정의를 통일

  3. 03

    Order Ingestion

    주문 누락·중복을 줄이는 적재 흐름

  4. 04

    Carrier Integration

    택배사 연동으로 배송 상태 추적

  5. 05

    Inventory Sync

    재고 연동으로 운영 데이터 일치

  6. 06

    Unified System

    운영 관점에서 한곳으로 조회

수집된 데이터는 통일된 형태로 적재되고, 주문·배송·재고 흐름이 한 관점에서 이어집니다.

Throughput

하루 1,000~3,000건 주문을 안정적으로 수집했습니다.

기존에는 플랫폼별로 흩어진 주문/재고 데이터를 각각 확인해야 했습니다. 비교가 느려지고, 같은 상품이라도 플랫폼마다 상태 정의가 달라 운영 실수가 생기기 쉬웠습니다.

그래서 플랫폼 크롤링을 기반으로 데이터 형태를 통일하고, 주문 수집과 택배사 연동, 재고 동기화를 한 파이프라인으로 연결했습니다.


Result

운영팀이 플랫폼별로 나뉘어 보던 작업을 하나의 시스템에서 처리하도록 전환했습니다.

Engineering

실제로 사용한 기술입니다

기술을 먼저 선택하지 않습니다. 업무와 제약을 이해한 다음, 그 자리에 맞는 도구를 붙입니다.

  1. Understand
  2. Simplify
  3. Build
  4. Observe
  5. Improve

Main

Next.js / React
React는 물론 Next.js의 App Rotuer, Server Components, Image Optimization 등 다양한 기능을 활용할 수 있습니다.
Python / FastAPI
Python과 FastAPI를 활용하여 백엔드 API를 개발하고, 자동화 및 데이터 처리 작업을 수행할 수 있습니다.
Docker / CI/CD
Docker를 사용하여 애플리케이션을 컨테이너화하고, GitHub Actions를 활용하여 CI/CD 파이프라인을 구축하여 배포를 자동화하고 운영 중단을 최소화할 수 있습니다.
AWS
AWS EC2, Lambda, DynamoDB 등 다양한 서비스를 활용하여 프로덕션 서비스와 내부 시스템을 운영할 수 있습니다.
Vercel
정적/서버리스 배포 흐름을 이해하고, 팀이 빠르게 릴리즈할 수 있는 형태로 운영할 수 있습니다.
Supabase
PostgreSQL 기반으로 인증/데이터 연동을 빠르게 구성하고, 초기 제품화 속도를 끌어올립니다.
PostgreSQL / MySQL / DynamoDB
PostgreSQL·MySQL의 스키마 및 관계 설계와 DynamoDB의 Access Pattern 기반 데이터 모델링을 할 수 있습니다.
Redis
Redis를 활용한 캐싱 전략을 설계·적용하여 DB 부하를 줄이고 서비스 응답 성능을 개선했습니다.
Crawling / Automation
Playwright, BeautifulSoup, Selenium 등을 활용하여 웹 크롤링 및 자동화 작업을 수행할 수 있습니다.

Experience

Unity / Game Development
대학시절 게임 개발 프로젝트를 진행하며, 팀 단위 협업에 익숙해지고 웹개발에서는 배울 수 없었던 여러 문제들을 경험할 수 있었습니다.
Flutter
멀티플랫폼 UI 프로토타입을 빠르게 만들며, 제약 조건에서 사용자 흐름을 완성하는 방식에 익숙해졌습니다.
OpenCV
객체 탐지 전처리/파이프라인을 다뤄, 데이터 품질과 처리 비용을 함께 고려하는 관점을 익혔습니다.
IoT
센서/이벤트 기반 데이터의 수집 흐름을 이해하고, 처리 파이프라인으로 연결하는 관점을 익혔습니다.

Background

업무를 배우고, 시스템을 남깁니다

Full-stack Developer로 약 5년간 내부 업무 시스템과 자동화 도구를 만들어 왔습니다.

새로운 도메인이 주어지면 기술부터 고르지 않습니다. 담당자와 이야기하며 업무를 먼저 배우고, 그다음에 필요한 도구를 붙입니다.

프로덕션 관점에서 배포 흐름을 반복해 봤습니다. Vercel·Supabase 연동부터 AWS(EC2/DynamoDB/Lambda) 기반 운영 배포까지, 제약에 맞춰 운영 단계를 정리해 왔습니다.

게임 개발 관련 학과를 졸업했고, 졸업 작품에서 Lead Programmer를 맡았습니다. 게임 도메인에 대한 배경은 이어지고 있습니다. 또한 Flutter/Unity로 멀티플랫폼 구현을 경험했고, OpenCV로 객체 탐지 파이프라인을 다루며 데이터 처리 관점도 확장했습니다.