포트폴리오

정산 엔진 - 여기가 이 프로젝트의 심장입니다.

• 이중 트리 조직 구조 - 추천라인(1:N) + 후원라인(바이너리 LEFT/RIGHT)을 동시에 관리
• 마감 최대 4종(일/주/15일/월)과 수당 최대 13종 자동 계산을 트랜잭션으로 원자성 보장
• 정산 원장 7종·회원 상태를 스냅샷으로 보존해 마감 취소 시 이전 상태로 복원
• 마감 사전 검증·미리보기 지원

"최대"인 이유가 이 프로젝트의 핵심입니다. 마감 유형과 수당 종류를 코드가 아니라 설정으로 켜고 끕니다. 업체마다 보상플랜이 다르기 때문에, 만들어둔 것을 업체별로 필요한 것만 활성화합니다. 새 수당이 필요해지면 종류가 늘어나는 구조입니다. 데모에서 직접 확인하실 수 있습니다 - 마감에는 일/15일/월 3종만 떠 있는데, 주 마감을 시스템 설정에서 비활성화했기 때문입니다. 일 마감 화면 상단에도 "데일리수당, 추천수당, 후원수당, 롤업수당이 활성화되어 있습니다. 마감 시 해당 수당들이 계산됩니다"라고 현재 활성 수당이 표시되고, 비율 구간표 아래에는 "비율 변경은 시스템 설정 → 보상플랜 → 데일리수당에서 가능합니다"라고 설정 경로가 안내됩니다.

쇼핑몰 - 설정으로 켜는 옵션이고, 정산 로직은 건드리지 않고 붙였습니다.

• 장바구니 → 주문 → 결제완료 때만 매출 생성 → 기존 마감으로 연결. 입금대기 주문은 정산에 닿지 않음
• 무통장입금(관리자 입금확인, 금액 불일치 시 재확인)·쇼핑포인트 결제, 결제 기록을 주문과 분리해 PG 추가에 대비
• 같은 회원의 주문·결제·취소를 DB 잠금(advisory lock)으로 직렬화해 포인트 이중 차감·중복 매출 차단
• 관리자 주문 관리 - 입금기한 경과 자동취소, 송장 엑셀 일괄 등록(행별 미리 검증 후 통과 행만 등록), 반품. 마감 후 반품은 기록하고 정산 보정 경고
• 상품 이미지 S3 저장(EC2 IAM 역할, 액세스 키 없음)·썸네일 자동 생성, 전자상거래법 고지 항목(사업자 정보·구매 안내·약관) 설정값 관리

동적 시스템 설정 엔진

• 281개 설정값을 21개 카테고리로 DB 중앙 관리, 관리자 UI 변경이 즉시 반영
• 설정 타입별 입력 폼 자동 생성 및 설정 간 의존성 관리(부모 → 자식 조건부 표시)

멀티테넌트 아키텍처

• 단일 코드베이스로 복수 고객사 운영, 초기 설정값 덮어쓰기로 업체별 정책 분리
• EC2 한 대에 업체별 백엔드를 Docker 컨테이너로 함께 띄우고 Nginx가 api.{도메인}으로 라우팅
• RDS 한 대를 공용으로 쓰되 Database만 업체별로 분리, 프론트엔드는 업체별 Vercel 프로젝트
• 업체별 GitHub Actions 파이프라인 독립 운영 (신규 구축·초기화 재배포 등 다중 배포 모드)

백엔드·회원 시스템

• NestJS 23개 모듈 · 340여 개 REST API
• JWT + Passport 인증, 4단계 RBAC
• 다국어(i18n) - nestjs-i18n 한·영 응답 분기 + 메뉴 영문명을 DB 컬럼으로 관리해 운영자가 직접 수정, d3-org-chart 조직도 시각화, 포인트 이중 시스템(Cash/Shop)·CPV 관리
• 조직도 미니맵 - 화면보다 큰 트리에서 전체를 축소해 띄우고 현재 보이는 영역을 사각형으로 표시, 클릭·드래그로 그 위치까지 바로 이동

AI 활용 - 개발

구현만 AI에게 맡기지 않고 검증까지 맡겼습니다. 대신 합격 기준은 코드로 고정했습니다.

ProWith를 운영하면서 정작 시간을 잡아먹는 건 코드가 아니라 운영이라는 걸 알게 됐습니다. 특히 세 가지가 그랬습니다.

정산 검증   수당 최대 13종 × 마감 최대 4종(일/주/15일/월)
신규 업체   DB·GitHub·AWS·Vercel 구성 + 도메인 연결 + 배포를 매번 손으로
보상플랜    업체마다 다른 규칙을 hwp·pptx 문서로 받아 코드로 옮기는 작업

그래서 반복 운영 업무를 재현 가능한 스킬 6종으로 고정했습니다. 매번 같은 결과가 나오는 작업 절차입니다.

무엇을 자동화했나

셋은 체인으로 물려 있습니다 - compose-plan(문서화) → build-seed-plan(설정 반영) → verify-cutoffs(검증). 앞 단계의 산출물 형식을 뒷 단계가 그대로 읽도록 규격을 맞춰 둬서, 새 업체 보상플랜이 들어오면 이 순서로 흘려보내면 됩니다.

검증도 AI가 수행합니다

작업 절차 안에 검사 두 가지를 넣어, AI가 구현을 끝내면 스스로 돌려보고 통과해야 끝나도록 했습니다. 사람이 만든 건 검사 자체가 아니라 무엇을 통과로 볼 것인가입니다.

① 보상플랜 불변식(invariant) 검사 보상플랜이 반드시 지켜야 할 조건을 코드로 박아두고, 계산 결과가 거기서 어긋나는지 봅니다. 이때는 조건을 만족하는 테스트 데이터를 만들어내는 것 자체가 일이었습니다.

② 운영 덤프 재마감 전수 대조 실제 운영 데이터를 그대로 다시 마감시켜, 기존 결과와 전수 비교합니다. 한 건이라도 어긋나면 통과하지 않습니다.

사람이 하는 일과 AI가 하는 일 - AI 코딩 도구가 등장하기 훨씬 전부터 다양한 로직을 직접 구현해 온 경험을 바탕으로 설계 방향과 합격 기준을 정합니다. 구현·테스트·검증 실행은 AI가 맡습니다. 기준이 코드로 박혀 있으니 결과를 눈으로 다시 확인할 필요가 없어졌고, 사람이 판단할 지점만 남았습니다.

구성 - Next.js 15 App Router 풀스택(78개 REST API) + AWS Lambda·EventBridge 수집기 + Python 예측 파이프라인이 하나의 PostgreSQL을 공유하는 구조입니다. 수집기가 매주 토요일 동행복권 회차를 가져와 저장하면, 예측 파이프라인이 다음 회차 예측을 같은 테이블에 써두고, 웹앱이 그걸 읽어 보여줍니다.

성능 최적화 - 세 번에 걸쳐 다른 병목을 잡았습니다

이 프로젝트에서 가장 많은 시간을 쓴 부분입니다. 한 번에 해결한 게 아니라, 병목이 옮겨갈 때마다 다른 방법을 썼습니다.

① 서버 응답이 느리다 → LRU 인메모리 캐시

9개 분석 API가 매 요청마다 전체 회차를 다시 계산하고 있었습니다. 로또는 주 1회 추첨이라 같은 범위의 분석 결과는 일주일 내내 변하지 않는다는 점에 착안해 캐시를 붙였습니다.

966ms → 31ms   (97% 개선)
백테스트 반복 분석 40% 향상 · DB 부하 90% 감소

• TTL 24시간, API당 50 엔트리 LRU - 주 1회 갱신이라 24시간이 안전한 상한
• 범위별 캐시 키 - _full(전체) · _dhl(836회~) · _{fromTurn}_{toTurn}(백테스트). 사용자가 임의 구간을 지정해도 캐시가 듣습니다
• 자동 무효화 - 새 회차가 들어오면 CacheInvalidator.onNewDrawing()이 분석·통계·대시보드 캐시와 최신 회차 값을 한 번에 초기화합니다. 캐시는 넣는 것보다 언제 버릴지가 어렵습니다
• ⚠️ 최신 회차 값은 5분만 캐싱 - 이 값이 toTurn === latestTurn으로 "전체 범위 요청인가"를 판정해 캐시 키를 결정하기 때문에, stale이면 옛 회차 결과가 _full 키에 들어앉습니다. 분석 결과는 24시간, 이 값은 5분으로 나눈 이유입니다
• 개발 환경 HMR에서 캐시가 날아가지 않도록 globalThis 싱글톤으로 보관

② 예측 API가 10초 걸린다 → 불필요한 연산 제거 + 병렬화

캐시로 분석 API는 빨라졌는데 하이브리드 예측이 여전히 10초였습니다. 뜯어보니 원인이 둘이었습니다.

순차 API 호출 ~7s  +  백테스트 ~3s   =  약 10초
          ↓                   ↓
병렬 호출 ~2s        조건부 스킵        =  약 2초   (80% 단축)

• 520회 백테스트를 조건부로 걷어냈습니다 - 동적 제약 조건을 쓸 때는 통계가 필요 없는데도 매번 돌고 있었습니다. includeStats=false로 스킵해 800ms~1s를 줄였습니다
• 4개 패턴 분석을 Promise.allSettled()로 병렬화 - all이 아니라 allSettled를 쓴 건 하나가 실패해도 나머지 결과로 예측을 보여주기 위해서입니다. 실패한 것만 로깅합니다

③ 화면 전환이 굼뜨다 → 클라이언트 캐싱과 필터링

서버는 빨라졌는데 탭을 옮길 때마다 같은 데이터를 다시 받아오고 있었습니다. 서버 필터링을 클라이언트 필터링으로 옮기고, 조회한 회차는 Map에 담아 재사용했습니다.

API 호출     105회 → 1회    (99% 감소, 탭 5회 전환 기준)
네트워크     350KB → 50KB   (86% 절감)
탭 전환      1~2초 → 즉시

트레이드오프 - 캐시 TTL을 24시간으로 길게 잡은 대신 무효화 트리거를 정확히 걸어야 했고, 클라이언트로 데이터를 내리는 대신 첫 로딩이 무거워지는 것을 감수했습니다. 도메인 특성(주 1회 갱신, 데이터 크기 수백 KB)을 보고 내린 판단입니다.

로그는 관계형 DB에 넣지 않았습니다

제약 조건 때문에 버렸는데 실제로는 당첨된 조합을 기록해 추적하는 기능이 있습니다. 스키마가 자주 바뀌고 조회보다 적재가 훨씬 많은 데이터라, PostgreSQL 대신 MongoDB Atlas에 Mongoose ODM으로 따로 담았습니다.

• 사용자별·회차별 집계 파이프라인 구현
• 듀얼 로깅 - LOG_TARGET 환경변수로 파일 / MongoDB / 둘 다를 골라 씁니다. 로컬에서는 파일, 운영에서는 MongoDB
• Winston 구조화 로깅과 연동

등급이 3개라 계정 전환기를 만들었습니다

무료·프리미엄·관리자 3등급에 비로그인까지, 화면과 API 분기가 4가지입니다. 등급 하나 고칠 때마다 로그아웃하고 다른 계정으로 다시 로그인하는 게 반복돼서, 개발 모드에서만 뜨는 플로팅 계정 전환기를 붙였습니다.

• 한 번 클릭으로 전환 - 등급별 대표 계정을 자동으로 뽑아 보여주고(role별 1명), 필요하면 전체 계정 목록을 펼칩니다. 로그아웃(비로그인 테스트) 버튼으로 비로그인 화면도 같은 자리에서 확인합니다
• 비밀번호 없이 세션을 바꿉니다 - NextAuth credentials provider에 개발 전용 플래그를 태워 전환하고, 그게 실패하면 /api/dev/force-login이 NextAuth JWT를 직접 발급해 세션 쿠키로 심습니다
• 🔒 프로덕션 차단을 두 겹으로 걸었습니다 - 컴포넌트가 NODE_ENV !== 'development'면 렌더 자체를 하지 않고, /api/dev/* 라우트도 같은 조건으로 403을 돌려줍니다. 화면만 숨기면 엔드포인트는 그대로 열려 있기 때문입니다

인증 및 보안 - NextAuth.js OAuth(Google/Kakao)·이메일 OTP 및 RBAC 등급별 접근 제어, Redis 인증 코드(10분 TTL), AES-256 개인정보 암호화

인프라 - Vercel + Supabase(PostgreSQL) · Upstash Redis · MongoDB Atlas · AWS Lambda·EventBridge · Vercel CI/CD