임동현 Java / Spring Backend Developer

시스템 지도 / Living System Map

LIVE COMMERCE / SOLO BUILT & OPERATED

고운맘은 지금 운영 중입니다.

고객이 실제로 접속할 수 있는 커머스 서비스를 기획부터 배포·운영까지 혼자 책임졌습니다.

서비스
고운맘 gowoonmom.kr
개발 방식
1인 개발
운영 상태
공개 운영 LIVE
현재 실무
Java 웹 개발·운영
비즈니스 흐름COMMERCE FLOW
01

주문

장바구니
주문 생성
주문 내역

02

결제

결제 요청
승인 처리
결제 내역

03

재고

재고 차감
예약 복원
재고 이력

04

배송

배송지 관리
배송 처리
배송 추적

05

환불

환불 신청
부분 환불
환불 이력

시스템 구성SYSTEM ARCHITECTURE

Spring Boot · Spring Security · MyBatis / JPA · JWT / OAuth · Next.js · MariaDB · PortOne

데이터 계층DATA LAYER
MariaDB50개 이상의 테이블

회원 · 인증 · 상품 · 재고 · 장바구니 · 주문 · 결제 · 배송 · 환불 · 알림 · 이미지 · 감사 이력

인프라 & 배포INFRASTRUCTURE
AWS LightsailDocker ComposeNginx · HTTPSMariaDBS3 · CloudFront
운영 증거EVIDENCE

2025.12 → 현재개발부터 운영까지 직접 수행

설계 · 개발 · 배포 · 운영요구사항부터 장애 대응까지 전 과정

주문 → 결제 → 재고 → 배송 → 환불전체 커머스 흐름을 직접 설계

50개 이상의 테이블도메인별 데이터 모델과 정합성

지속적인 운영 & 개선버그 수정, 기능 개선, 성능 최적화

서비스 직접 확인 경력과 문제 해결 보기

$ whoami

임동현 | Java / Spring Backend Developer

$ cat system_status

고운맘은 지금 공개 운영 중입니다.

개인 프로젝트 · 공개 운영 중

고운맘

고객 쇼핑몰과 관리자 운영 시스템을 혼자 만들고, 공개 환경에서 직접 운영하고 있습니다.

1인 개발 공개 운영

쇼핑 화면보다 운영 흐름에 더 많은 시간을 썼습니다.

고객의 옵션 선택·장바구니·주문·결제와 관리자의 상품·재고·배송·환불 업무가 같은 주문과 결제 상태를 사용하도록 만들었습니다. 결제 지연, 중복 webhook, 재고 복구, 인증 세션과 이미지 처리 실패도 별도의 운영 상태로 다룹니다.

고객 흐름
상품 탐색·상세·장바구니·회원/비회원 주문·결제·주문 조회
관리자 흐름
상품·카테고리·메인진열·주문·결제·환불·배송·재고·회원 관리
데이터 모델
회원·인증·상품·재고·주문·결제·배송·알림·이미지 등 50개 이상의 테이블
플랫폼
Spring Security, JWT·OAuth 인증, MyBatis/JPA 데이터 처리, 공통 API 계약
배포
AWS Lightsail, Docker Compose, Nginx, HTTPS, MariaDB, S3·CloudFront 기반 공개 환경

Java 17Spring Boot 3.5.16Next.js 16.2React 19.2 TypeScriptMariaDBPortOneAWS

gowoonmom.kr 열기 문제 해결 사례 보기

실사용 고객을 받기 전 단계이며, 면접관이 전체 기능을 직접 확인할 수 있도록 공개한 운영 검증 환경입니다.

AWS Lightsail에서 Docker Compose로 실행 중인 현재 공개 배포 구성

경력

회사 실무 경험

현재는 공공기관 웹 시스템의 개발과 운영을 맡고 있습니다.

엔소프트웨어 · 2025.07.01 - 재직 중

사내 메일 시스템 개발·운영

단독 담당

기능만 개발한 구성원이 아니라 시스템 담당자로서 개발부터 운영 환경의 문제 해결까지 전 범위를 책임졌습니다.

  • 기존 시스템 유지보수와 신규 요구사항 반영
  • 타 시스템 연계 API 개발 및 유지보수
  • 운영 배포와 실제 서버 관리
  • 운영 중 발생한 오류 확인 및 수정

담당 범위 기능 개발 · 배포 · 서버 관리 · 오류 대응

Spring LegacyJSPOracle DB연계 API

인사·노무 업무 시스템

유지보수·신규 기능 개발

3인 팀

3인 팀의 구성원으로 기존 업무를 안정적으로 유지하면서 신규 기능과 시스템 연계 기능을 함께 개발했습니다.

  • 기존 기능 유지보수와 신규 기능 개발
  • 시스템 연계 API와 스케줄러 기반 API 개발
  • 개발한 기능의 운영 배포와 실제 서버 관리
  • 운영 중 발생한 오류 확인 및 수정

담당 범위 유지보수 · 신규 기능 · 연계 API · 운영 반영

Spring LegacyJSPOracle DBScheduler API

감프정보기술 · 2024.11 - 2025.05

제약 생산관리 시스템 유지보수·QA 지원

MES·WMS·Smart EBR의 C#/.NET WinForms 화면 수정, SQL Server 데이터 검증, 단위 테스트와 사용자 지침서 작성을 담당했습니다.

고객 기관명과 내부 URL·서버·API·DB·운영 데이터는 공개하지 않았습니다. 회사명과 근무 기간만 공개합니다.

데이터 모델

50개 이상의 테이블을 도메인 경계로 나눴습니다.

테이블 수 자체보다 주문을 중심으로 회원·상품·결제·배송·알림이 어떻게 연결되고, 어떤 상태와 이력을 별도로 보존하는지 보여주는 핵심 ERD입니다.

DOMAIN MAP

업무 수명주기에 따라 데이터 경계를 분리했습니다.

schema.sql 기준
01회원 · 인증사용자·세션·동의·OAuth
02상품 · 재고옵션 마스터·실시간 재고·변동 이력
03장바구니 · 주문주문 스냅샷·멱등 시도
04결제 · 환불결제 원장·취소·수동 검토
05배송 · 알림운송장·감사 이력·outbox
06이미지 자산업로드·활성화·보관·삭제
CORE COMMERCE ERD

주문·결제·재고·배송의 핵심 관계

1 하나 0..1 선택적 하나 N 여러 개
회원usersPK user_id
10..N
주문 헤더ordersPK order_id · FK user_id
11..N
주문 스냅샷order_itemFK order_id · option_id
N1
옵션 마스터product_optionPK option_id · master version
11
실시간 재고inventory_option_balancePK/FK option_id · inventory version
주문 헤더ordersPK order_id
10..N
결제 원장paymentFK order_id · 결제 상태
10..N
취소·환불 요청payment_cancellationFK order_id · payment_id
10..N
부분환불 배분payment_cancellation_itemFK cancellation_id · order_item_id
주문 헤더ordersPK order_id
10..1
결제 관측payment_attemptUNIQUE order_id · 복구 상태

주문마다 하나의 결제 시도만 두고, 지연 승인·보상 환불·수동 검토 상태를 별도로 관측합니다.

주문 헤더ordersPK order_id
10..1
현재 배송shipmentUNIQUE order_id · 운송장
10..N
배송 감사 이력shipment_historyFK shipment_id · order_id
주문 헤더ordersPK order_id
10..N
고객 알림 작업notification_outboxFK order_id · 상태·재시도

결제 완료와 배송 시작 이후의 외부 알림도 주문 트랜잭션과 분리해 재시도 가능한 작업으로 남깁니다.

01 · Snapshot

과거 주문을 현재 상품 정보로 다시 계산하지 않습니다.

상품명·옵션·단가·배송지·배송비 정책은 주문과 주문상품에 당시 값으로 보존합니다.

02 · Consistency

옵션 마스터와 실시간 재고의 충돌 경계를 분리했습니다.

상품 편집은 master version, 주문·결제·재고 조정은 inventory version만 변경해 서로의 작업을 방해하지 않습니다.

03 · Operations

실패와 수동 판단도 데이터로 남깁니다.

결제·환불 수동 검토, 배송 변경, 알림 재시도와 이미지 outbox를 운영 이력으로 추적합니다.

공개 포트폴리오에는 핵심 관계와 대표 컬럼만 표시했습니다. 정확한 제약조건·인덱스·전체 테이블은 docs/schema.sql을 기준으로 관리하며 실제 회원·주문 데이터는 포함하지 않습니다.

문제 해결

데이터 흐름으로 설명하는 문제 해결

이력서에는 결론만 적고, 여기서는 데이터가 이동하는 순서와 판단 기준을 함께 정리했습니다.

01

결제 상태 수렴

SDK 성공보다 서버에 남은 주문·결제 상태를 최종 기준으로 사용합니다.

문제

결제창 응답과 webhook은 순서가 다르고 같은 이벤트가 다시 올 수 있습니다. 화면, 주문, 결제 원장이 서로 다른 결론을 내리면 출고와 환불도 잘못됩니다.

해결

webhook 검증 후 결제사 API를 다시 조회하고 저장된 식별자와 대조했습니다. 주문과 결제 시도를 정해진 순서로 잠그고, 늦은 승인은 자동 환불 또는 수동 검토로 분리했습니다.

결과

중복 완료, 지연 승인, 결제 상세 불일치와 webhook·reconciliation 경합을 테스트했습니다. 프론트도 서버 주문 상태가 확정된 뒤 완료 화면을 표시합니다.

02

실시간 재고 동시성 제어

원자적 UPDATE, 낙관적 락, 비관적 락을 쓰기 경로의 성격에 맞게 조합합니다.

문제

옵션 정보와 재고가 하나의 version을 공유하면 고객 주문이 관리자 상품 편집까지 충돌시킵니다. 사전 조회만으로 재고를 판단하면 동시 주문에서 초과 예약이 발생하고, 중복 결제 webhook은 재고를 두 번 차감할 수 있습니다.

해결

옵션 마스터와 실시간 재고의 테이블·version을 분리했습니다. 주문 예약은 가용 수량 조건을 포함한 원자적 bulk UPDATE, 관리자 수정은 version CAS, 결제 확정은 주문·결제 시도와 optionId 오름차순 재고 행을 FOR UPDATE로 잠근 뒤 movement까지 한 트랜잭션으로 처리했습니다.

결과

실제 MariaDB 동시 실행에서 재고 1개를 요청한 두 주문 중 한 건만 성공했고, 동일 PAID 요청이 겹쳐도 결제 원장·재고 차감·movement가 한 번만 반영됐습니다. 고객 주문 뒤에도 상품 설명과 이미지는 재고를 덮어쓰지 않고 저장됩니다.

03

MariaDB 기반 Public API Rate Limiter

공개 API의 요청 횟수를 IP와 사용자 식별자 범위로 나눠 관리합니다.

문제

IP만 제한하면 분산 공격에 약하고 식별자만 제한하면 공격자가 임의 값으로 버킷을 계속 만들 수 있습니다. 메모리 방식은 재시작과 다중 인스턴스에서 횟수가 초기화됩니다.

해결

IP를 먼저 검사하고 통과한 요청만 IP+식별자와 식별자 버킷을 확인합니다. 원문은 HMAC으로 보호하고, MariaDB 행 잠금과 독립 트랜잭션으로 동시 요청과 rollback에서도 횟수를 유지합니다.

결과

정확한 허용 횟수, Retry-After, 시간 창 초기화, 동시 요청, DB 장애와 제한된 배치 삭제를 검증했습니다. DB 부하나 hot-row 대기가 커지면 Redis로 옮길 기준도 정했습니다.

추가 문제 해결 사례 2개 보기 추가 문제 해결 사례 접기
04

안전한 소셜 계정 연결

같은 이메일이라는 이유만으로 기존 회원과 소셜 계정을 연결하지 않습니다.

문제

제공자마다 이메일 신뢰 수준이 다르고 이메일은 변경될 수 있습니다. 이메일 일치만 믿으면 기존 주문과 주소가 다른 로그인 수단에 노출될 수 있습니다.

해결

비밀번호, 현재 로그인 세션 또는 고운맘 이메일 인증으로 본인을 다시 확인합니다. OAuth 연결은 사용자와 refresh session에 묶인 5분짜리 일회성 grant로 처리합니다.

결과

동시 callback, grant 재사용, 다른 세션 사용, 연결 도중 로그아웃과 마지막 로그인 수단 해제를 검증했습니다. 현재 로컬 구현·검증 상태이며 실제 제공자 E2E와 dev 배포는 남아 있습니다.

05

S3 이미지 처리의 재시도와 복구

DB와 외부 저장소를 한 트랜잭션으로 묶을 수 없는 문제를 상태로 추적합니다.

문제

S3 작업은 DB commit과 함께 rollback할 수 없습니다. 응답 유실이나 worker 중단이 발생하면 파일은 존재하지만 DB 상태는 실패로 남을 수 있습니다.

해결

DB에는 자산과 outbox 상태를 먼저 남기고 외부 I/O는 트랜잭션 밖에서 수행합니다. worker는 lease로 구분하고 timeout 뒤에는 S3 HEAD로 실제 결과를 다시 확인합니다.

결과

commit·rollback, 응답 유실, worker 재시작, 동시 lease와 활성화 순서 역전을 테스트했습니다. 삭제 전에는 보관 기간과 현재 상품 참조를 다시 확인합니다.

기술

실제로 사용한 기술 스택

회사 실무와 현재 코드·설정에서 확인되는 기술만 역할별로 정리했습니다.

실무 시스템

Spring Legacy · JSP · Oracle DB · Scheduler · System Integration API

백엔드

Java 17 · Spring Boot 3.5.16 · Spring Security · MyBatis · Spring Data JPA · AWS SDK for Java

프론트엔드

Next.js 16.2.11 · React 19.2.4 · TypeScript 5 · Tailwind CSS 4 · Zustand · React Hook Form

데이터베이스 · 연동

MariaDB · H2(test) · PortOne Payment/Webhook · OAuth · S3

인증 · 보안

JWT · Refresh Token Rotation · OAuth Account Linking · API Rate Limiting · HMAC-SHA256 · HttpOnly Cookie · CORS · CSP

인프라 · 검증

Docker Compose · Nginx · HTTPS/Let's Encrypt · AWS Lightsail · CloudFront · JUnit 5 · MockMvc · Testing Library · ESLint · Browser QA

이력서 · 연락

이력서와 연락처

전화번호와 주소를 제외한 공개용 이력서와 개발 기록을 확인할 수 있습니다.

고운맘 서비스: gowoonmom.kr