Engineering Leader for Reliable Business Systems

Problem

판매 유형별 정산, 입점비 관리, 부분취소·환불·배송 이슈 등 정산 예외를 운영팀이 엑셀과 스프레드시트로 수동 검수했습니다.

Approach

정산 검증, 예외 처리, 비즈니스 룰 분리, 계산 흐름, export 생성을 하나의 정산 처리 흐름으로 정리했습니다.

My Role

문제 발견, 운영팀 인터뷰, 요구사항 분석, 정산 구조 설계, 개발, 배포, 운영 도입을 리드했습니다.

Architecture Decision

엑셀을 없애는 대신 주문 데이터 → 검증 → 계산 → export generation으로 책임을 나누고, 데이터 일관성을 먼저 확보했습니다.

Problem

광고 신청, 추첨, 선정, 입금 확인, 거래명세서 생성이 스프레드시트와 수작업에 분산되어 있었습니다.

Approach

구글폼과 스프레드시트로 먼저 운영 룰을 검증하고, 반복 가능한 흐름만 콘솔로 확장했습니다.

My Role

광고 운영 프로세스 설계, MVP 검증, 추첨·정산 흐름 구조화, 콘솔 전환과 운영 도입을 리드했습니다.

Architecture Decision

처음부터 플랫폼을 만들지 않고, Google Form과 Spreadsheet로 룰을 검증한 뒤 플랫폼화했습니다.

Problem

가게 관리 기능이 기존 콘솔과 CMS로 나뉘어 같은 정보를 두 번 확인하고 입력해야 했습니다.

Approach

운영자가 실제로 처리하는 merchant workflow를 기준으로 확인, 입력, 수정 흐름을 단일화했습니다.

My Role

운영 동선 분석, 중복 업무 파악, 단일 콘솔 요구사항 정의, 기능 통합과 배포를 담당했습니다.

Architecture Decision

기존 CMS를 확장하기보다 운영자가 자주 쓰는 merchant workflow를 별도 콘솔로 재구성했습니다.

Problem

운영자가 목적에 따라 여러 사이트를 오가며 같은 업무 흐름을 끊어서 처리해야 했습니다.

Approach

분산된 메뉴를 업무 흐름 중심으로 재배치하고, 운영자별 자주 쓰는 메뉴 접근을 단축했습니다.

My Role

콘솔 통합 방향 수립, 메뉴 정보 구조 설계, 개인화 기능 설계, 팀별 도입 흐름을 조율했습니다.

Architecture Decision

모든 기능을 재작성하지 않고, 분산된 시스템의 진입점과 업무 흐름을 중앙화하는 방식을 선택했습니다.

Problem

운영·제휴·기획·경영진이 필요한 데이터를 매번 요청하거나 개별적으로 확인해 개발 리소스가 반복 소모됐습니다.

Approach

조직별 의사결정 주제를 나누고, 매출·주문·시장·시간대·보고 지표를 dashboard로 분리했습니다.

My Role

조직별 데이터 요구를 인터뷰하고, 운영·제휴·기획·경영진이 따로 볼 수 있는 지표 구조를 설계했습니다.

Architecture Decision

하나의 거대한 리포트가 아니라, 의사결정 주제별 dashboard로 분리해 데이터 요청 비용을 낮췄습니다.

Problem

기존 PHP 기반 서비스는 유지보수 비용과 기술 부채가 누적되어 신규 기능 개발 속도와 안정성에 한계가 있었습니다.

Decision

대규모 재작성보다 비즈니스 로직을 재정비하며 Java 기반 구조로 점진 전환하는 전략을 선택했습니다.

Implementation

공통 구조와 개발 표준을 정립하고, 장기 운영 가능한 서비스 구조로 기능을 단계적으로 옮겼습니다.

My Role

전환 방향 수립, 구조 설계, 개발 표준 정리, 리스크 관리, 점진적 도입을 주도했습니다.