포트폴리오

프로젝트 개요 디자인 시스템이 부재한 AIDC 통합 광고센터 환경에서, 프론트엔드 비경험 팀원도 Next.js, React 개발에 참여할 수 있도록 AI Agent 워크플로우와 Playwright E2E QA 파이프라인을 구축한 프로젝트

핵심 성과

• 공식 디자인 시스템이 부재한 환경에서 기획, 디자인 산출물 연계 기반의 AI 개발 체계 확립
• Jira 요구사항과 Playwright E2E 테스트, 화면 녹화 비디오를 연계해 이슈 단위 1차 QA 자동화 달성
• 프론트엔드 비경험 백엔드 개발자도 고품질 UI 개발과 검증에 주도적으로 참여할 수 있는 협업 파이프라인 구축

문제 상황

• 공식 디자인 시스템(Design System)이나 컴포넌트 라이브러리가 없어, AI Agent가 화면을 구현할 때 구조, 스타일, 인터랙션 기준이 흔들리는 문제 발생
• UX 디자이너의 Figma, 퍼블리셔의 마크업, 기획서의 비즈니스 정책이 서로 분산되어 AI가 전체 요구사항 맥락을 한 번에 파악하기 어려운 환경
• 프론트엔드 개발 경험이 부족한 팀원이 AI 생성 코드를 수령하더라도 실제 기획 의도와 일치하는지 신속하게 검증하기 어려운 한계

핵심 설계 판단

• 기획, 디자인 산출물 연계를 통한 UI 임의 생성 방지
  • 모호한 자연어 프롬프트만으로는 공식 가이드가 없어 스타일과 컴포넌트 구조가 임의로 왜곡되는 한계
  • 퍼블리셔 마크업(HTML/CSS), 화면 시안, Jira 명세, 기존 코드 패턴을 프롬프트 근거로 정제 주입하여 프로젝트 규격에 부합하는 코드 생성 유도
• Jira Evidence 기반 Playwright E2E 1차 자동 검증 체계 구축
  • 프론트엔드 비전문가가 AI 생성 코드를 육안으로만 디버깅하기 어려운 비효율
  • 기능 명세와 1:1 대응되는 Playwright E2E 테스트를 자동 실행하고 스크린샷과 비디오를 기록하여 비전문가도 즉시 합격 여부를 판정하도록 설계

기술적 접근 및 구현

• 퍼블리셔 산출물 기반 Next.js 컴포넌트 포팅 체계 구성
  • 디자이너와 퍼블리셔가 완성한 HTML/CSS 마크업을 비공식 디자인 토큰으로 활용하여 리액트 컴포넌트로 규격화
• 통합 컨텍스트 엔지니어링
  • Jira: 기능 요구사항 및 수용 기준 (Acceptance Criteria)
  • Wiki: 비즈니스 운영 규칙 및 도메인 제약사항
  • Codebase: 기존 프로젝트의 상태 관리 및 API 통신 컨벤션
  • Mockup: 시각적 렌더링 검증을 위한 레퍼런스 이미지
• Playwright E2E 자동화 및 2단계 검증 파이프라인
  • Jira 티켓 분석 → AI 태스크 분해 → 컴포넌트 구현 → Playwright E2E 테스트 및 비디오 녹화 → 대시보드 1차 자동 검증 → PR Review 2차 사람 검증으로 이어지는 무결성 워크플로우 완성

프로젝트 개요 제휴마케팅 도메인의 유입→주문→정산 전 흐름에 걸쳐, 이기종 저장소 5종의 데이터 추적과 이상 유입 진단을 자연어로 수행하는 MCP 서버를 설계 및 구축한 프로젝트

핵심 성과

• 장애 디버깅 시간 단축 (수십 분 → 단일 질의 리포트 생성) 여러 DB 클라이언트와 수기 SQL을 오가던 번거로운 추적 과정을 유입부터 정산까지 연결된 단일 리포트로 전환
• 핵심 비즈니스 플로우 카탈로그 구축 분산된 서비스의 엔트리포인트를 전수 분석하고, 미분류 진입점에서 누락 후보를 재귀적으로 발굴하는 검증 루프 확립
• PCS 비정상 유입 역추산 절차 내재화 담당자 개인 경험에 의존하던 혼종, 위조 토큰, 봇 판정 절차를 팀 전체가 동일한 순서로 재현 가능한 도구화 추적 체계로 정착

문제 상황

• 클릭 유입부터 주문, 정산까지 이어지는 데이터 귀속 체인이 Oracle, MongoDB, MSSQL, Redis, Databricks 5개 이기종 저장소에 분산
• 운영 CS 및 장애 발생 시 여러 DB 클라이언트에서 각기 다른 SQL을 실행하고 결과를 사람이 수동 대조하느라 원인 규명에 수십 분 소요
• 비즈니스 이벤트와 물리적 저장 위치를 매핑한 구조적 문서가 없어 신규 담당자 도메인 온보딩이 구두 인수인계에만 의존하는 병목 상존

핵심 설계 판단

• 정적 어드민 대신 문맥 기반 조회가 가능한 MCP(Model Context Protocol) 선택
  • 고정된 화면만 제공하는 별도 어드민은 다변화하는 트러블슈팅 케이스에 기민하게 대응하기 어려운 한계
  • 문제 상황에 맞춰 필요한 전용 도구를 유연하게 조합해 조회할 수 있는 MCP 서버를 구축하여 운영 효율 극대화
• 운영 서비스 접속 설정 및 인증 체계 재활용을 통한 실시간 직접 검증
  • 별도의 복제 DB나 데이터 동기화 파이프라인 구축은 추가 인프라 비용과 데이터 지연을 수반
  • 기존 운영 서비스의 인증 체계를 그대로 활용하여 실제 운영 데이터 무결성을 실시간 직접 조회하도록 설계
• 경험에 의존하던 이상 유입 판정 절차의 도구화 및 표준화
  • 담당자 개인 경험에 의존하던 위조 토큰, 파트너사 혼종, 봇 유입 등 비정상 패턴 판정이 재현되지 않고 인수인계가 어려운 한계
  • 소유 정합성, 제휴사 일치 여부, 토큰 역산 등 판정 절차를 단계별 전용 도구로 체계화하여 팀 전체가 재현 가능한 디버깅 절차 확립

기술적 접근 및 구현

• 비즈니스 플로우 카탈로그 구축
  • HTTP 라우트, Batch, Kafka 토픽, 스케줄러 등 1,000여 개 엔트리포인트를 분석해 핵심 업무 흐름과 연관 테이블 구조화
• 운영 데이터 추적 도구 구현
  • 유입, 주문, 정산 데이터를 동일 주문/클릭 식별자로 연결해 단계별 상태와 누락 구간 즉시 확인
• Databricks 교차검증 계층 연동
  • 로컬 환경에서 직접 조회가 까다로운 대용량 IM 유입, 옥션 주문, 정산 미러 데이터를 silver 레이어에서 동일 키로 고속 대조
• 비정상 유입 판정 흐름 자동화
  • 제휴사 조합 검증, 토큰 역추산, 사용자 에이전트 대조 절차를 재현 가능한 순서로 고정하여 팀 공통의 표준 트러블슈팅 절차 확립

프로젝트 개요 4시간에 달하던 랭킹 갱신 지연과 피크 병목을 해소하기 위해, C#/ASP.NET 및 MS-SQL(저장 프로시저/테이블) 동기 레거시를 정밀 분석하고 Spring WebFlux 논블로킹 파이프라인 및 MongoDB 역정규화 모델로 전면 재설계한 프로젝트 (2인 주도 수행)

핵심 성과

• 랭킹 갱신 시간 최대 4시간 → 3분 이내 단축 (약 96% 개선)
• p99.9 기준 랭킹 조회 응답 속도 10ms 이내 달성 (기존 평균 100~200ms)
• 랭킹 반영 지연으로 발생하던 광고주 CS 및 환불 이슈 근본적 해소
• 피크 타임 TPS 30,000 트래픽 구간에서도 CPU 사용률 60% 절감 및 안정적 처리 용량 확보

문제 상황

• 광고주의 입찰가 변경 및 예산 소진 이벤트 발생 후 실제 검색 랭킹에 반영되기까지 최대 4시간 소요
• 랭킹 지연 반영으로 인한 비정상 과금, 광고 효율 저하 및 광고주 환불 비용 지속 발생
• .NET, MS-SQL 동기식 블로킹 처리 구조에서 피크 타임(TPS 30,000) 진입 시 처리 지연 및 서비스 불안정 심화
• 단일 갱신 흐름에서 수백만 건 데이터를 처리하며 DB I/O 대기와 반복 연산이 누적되어 MSSQL CPU 사용률 90% 육박

핵심 설계 판단

• 부분 최적화 대신 전면 비동기 아키텍처 전환 선택
  • 단일 SP 내 6개 테이블 다중 JOIN과 동기 블로킹 I/O가 병목의 근본 원인
  • 인덱스 추가나 쿼리 튜닝 등 국소적 개선으로는 피크 동시성 요구를 감당하기 어렵다고 판단하여, 논블로킹 리액티브 스택(Spring WebFlux) 및 Document 지향 저장소(MongoDB)로 전면 전환 결정
• 관계형 정규화 탈피 및 조회 중심 단일 Document 역정규화
  • RDB의 정규화된 테이블 구조를 1:1 이전할 경우 다중 참조로 인한 네트워크 왕복 오버헤드가 지속되는 구조적 한계
  • 읽기 비중이 95% 이상인 랭킹 조회의 특성을 고려해, 연관 필드를 하나의 Document로 통합 역정규화하고 복합 인덱스를 설계하여 단일 쿼리 디스크 I/O 최소화
• 대량 연산 부하의 API-배치 계층 분리
  • 실시간 API 요청 흐름에 대량 랭킹 산정 로직이 묶여있으면 서빙 스레드 고갈 유발
  • 무거운 갱신 작업은 Kafka 메시징으로 즉시 디커플링하여 컨슈머에서 비동기 처리하도록 설계

기술적 접근 및 구현

• 리액티브 스트림 기반 처리 파이프라인 구축
  • Spring WebFlux와 Reactor(Flux/Mono)를 도입해 요청 수신부터 DB 접근까지 전 과정을 논블로킹 비동기 스트림으로 처리
  • 적은 시스템 스레드로도 대량 동시 요청을 대기 없이 스케줄링하도록 구현
• MongoDB 모델링 및 쿼리 실행 계획 최적화
  • 랭킹 조회 조건에 맞춤화된 복합 인덱스(Compound Index)를 설계하고 Explain Plan 분석을 통해 불필요한 컬렉션 스캔 및 디스크 I/O 배제
  • p99.9 응답 시간을 기준으로 인덱스 전략을 지속적으로 튜닝하여 10ms 이내 초저지연 조회 확립
• Kafka 비동기 갱신 큐 구성
  • 랭킹 갱신 트리거 발생 시 가벼운 이벤트 메시지만 발행하고, 무거운 계산은 백그라운드 Consumer 그룹이 분담하도록 부하 격리
• Datadog 실시간 관측성 도입
  • 주요 API 응답 시간, TPS, JVM 리소스, MongoDB 커넥션 풀 지표를 대시보드화하여 병목 구간 지속 추적 및 사전 감지 체계 확립

프로젝트 개요 Hue, Hadoop, MongoDB에 분산되어 있던 검색광고 Bill/Pay 정산 데이터와 랭킹 스냅샷 파이프라인을 Databricks 기반 환경으로 전면 이관한 프로젝트

핵심 성과

• 온프레미스 Hadoop 리소스 부족으로 반복 발생하던 일일 배치 실패율을 0건으로 완전 해소
• 배치 오류 시 담당자가 새벽 시간대에 수동으로 재실행하던 야간 운영 부담 제거
• 원천 데이터와 단계별 집계 데이터를 자동 대조하는 검증 체계를 내재화하여 정산 데이터 신뢰도 및 정합성 대폭 개선

문제 상황

• 사내 레거시 Hue, Hadoop 인프라의 리소스 부족 및 노후화로 정산용 배치가 주기적으로 실패
• 배치 실패 시 새벽 시간대 담당자가 직접 접속해 수동 재실행을 수행해야 하는 운영 부담 가중
• 광고 과차감 정산 데이터(Hadoop)와 랭킹 갱신 스냅샷 데이터(MongoDB)의 처리 환경이 분산되어 데이터 흐름 파악 및 장애 추적 난항
• 광고주 과금 및 정산과 직결된 데이터 특성상, 이관 과정에서 단 1원의 오차나 데이터 누락도 발생해서는 안 되는 엄격한 무결성 요구

핵심 설계 판단

• 단순 1:1 쿼리 포팅이 아닌 3단계(원천→중간집계→최종결과) 파이프라인 재설계
  • 기존 Hadoop 배치는 단일 거대 쿼리로 실행되어 실패 시 오차 발생 구간 추적 불가
  • 원천 적재, 중간 집계, 최종 정산 테이블로 단계를 명확히 분리하고, 단계별 체크포인트를 두어 실패 격리 및 신속한 원인 규명이 가능하도록 아키텍처 재구성
• 분산 환경의 0원 단위 과차감 불일치 방지를 위한 교차검증 체계 구축
  • MS-SQL 원천 데이터와 Databricks 레이어 간 일자별, 셀러별, 광고 키별 합산 금액과 레코드 카운트를 교차검증하는 자동 검증 로직을 결합하여 정산 데이터 정합성 확보

기술적 접근 및 구현

• 기존 데이터 흐름 및 의존성 전수 분석
  • Hadoop 기반 Bill/Pay 데이터의 생성, 집계 순서와 MS-SQL 원천 정산 데이터, MongoDB 랭킹 스냅샷의 연관 관계를 분석해 통합 처리 순서도 도출
• Databricks 기반 통합 파이프라인 구축
  • 원천 데이터 적재 → 중간 정제/집계 → 최종 정산 결과 테이블 생성으로 이어지는 정형화된 워크플로우 구성
  • 분산되어 있던 랭킹 스냅샷 데이터도 Databricks 처리 환경으로 통합 수렴
• 단계별 자동 데이터 검증 로직 구현
  • 중간 집계 단계에서 처리 건수와 금액 합계를 상호 비교하고, 차이 발생 시 즉시 원인 구간을 역추적할 수 있도록 모니터링 체크포인트 삽입

프로젝트 개요 광고 랭킹 시스템의 MS-SQL → MongoDB 전환 시 데이터 정합성 보장을 위해 실시간 반영, Kafka 재처리, 배치 보정으로 이어지는 3단계 동기화 파이프라인을 구축한 프로젝트

핵심 성과

• 상용 CDC 솔루션 도입 없이 양방향 최종 정합성(Eventual Consistency) 확보
• 실시간 쓰기 실패가 발생하더라도 Kafka를 통해 유실 위험을 최소화하고 자동 재처리되는 안정적인 파이프라인 구축
• 일시적 네트워크 장애나 지연이 발생하더라도 백그라운드 보정을 통해 최종 데이터 정합성 유지

문제 상황

• RDB(MS-SQL)와 신규 NoSQL(MongoDB) 간 데이터 전환 및 병행 운영 과정에서 간헐적인 데이터 불일치 발생
• 광고주의 입찰가 변경, 소재 수정, 예산 소진 등 랭킹에 직접 영향을 주는 변경 사항이 MongoDB에 즉시 반영되지 않으면 오과금 및 광고 효율 저하 발생
• 인프라 비용 및 아키텍처 제약으로 인해 상용 CDC(Change Data Capture) 솔루션 도입이 불가능한 환경

핵심 설계 판단

• 상용 CDC 도입에 대한 현실적인 제약으로 자체 CDC 파이프라인 구축
  • 고가의 라이선스 비용 및 인프라 제약으로 상용 CDC 솔루션 도입이 불가능한 한계
  • 실시간 반영(API) → 실패 격리 및 재처리(Kafka) → 주기적 데이터 보정(Daemon) 흐름의 3단계 자체 동기화 파이프라인으로 설계하여 비용 없이 무결성 확보
• 변경 히스토리 테이블 기반의 경량 자체 보정 엔진 설계
  • 실시간 스트림 파이프라인만으로는 네트워크 순단 등에 따른 극소수 데이터 누락 방어에 한계
  • 원천 RDB 변경 히스토리의 타임스탬프와 플래그를 주기적으로 대조해 실시간 누락 데이터까지 안전하게 보정하도록 설계

기술적 접근 및 구현

• 1단계: Spring WebFlux 기반 실시간 비동기 반영
  • 광고 어드민에서 변경 요청 인입 시 MS-SQL 트랜잭션 완료와 동시에 리액티브 논블로킹 클라이언트로 MongoDB에 즉각 쓰기 수행
• 2단계: Kafka 기반 실패 격리 및 재처리 Consumer
  • 네트워크 순단 등으로 MongoDB 반영 실패 시 즉시 에러를 반환하지 않고, 변경 이벤트를 Kafka 토픽으로 발행
  • 별도의 Sync Consumer가 실패 이벤트를 구독하여 순차적으로 재반영을 수행하고 모니터링 알림 발행
• 3단계: Spring Batch 정합성 주기적 보정 데몬
  • 일정 시간차를 두고 원천 RDB의 변경 히스토리 테이블과 MongoDB 실데이터를 배치 단위로 비교 검증
  • 불일치 레코드가 발견되면 자동으로 최신 상태로 덮어써 영구적인 불일치 상태 방지

프로젝트 개요 검색광고 랭킹 개선 중 발생한 Redis 대량 처리 지연(100만 건 240초)과 Kafka 파티션 쏠림 이슈를 Client 내부 동작 추적 및 드라이버 최적화로 해결한 트러블슈팅 프로젝트

핵심 성과

• Redis 100만 건 처리 시간 240초 → 60초로 단축 (75% 성능 향상)
• Kafka 특정 파티션으로 집중되던 메시지 분배 불균형 및 컨슈머 지연(Lag) 완전 해소
• 단순 인프라 증설이 아닌 Client 드라이버 레벨의 원인 규명 및 최적화로 시스템 처리 효율 극대화

문제 상황

• Redis 대량 처리 지연 및 커넥션 폭증
  • 랭킹 갱신 시 Redis 100만 건 처리에 약 240초가 소요되어 전체 파이프라인의 핵심 병목으로 작용
  • 배치 실행 시 Datadog에서 Redis Connection 수가 비정상적으로 급증하는 리소스 낭비 확인
• Kafka 파티션 편중 및 컨슈머 처리 불균형
  • Producer에서 발행한 메시지가 전체 파티션에 균등 분산되지 않고 특정 파티션으로만 집중
  • 파티션별 Consumer 처리량 편차가 극심해지며 특정 컨슈머 인스턴스에만 Lag이 누적되는 문제 발생

핵심 설계 판단

• 추상화 계층(RedisTemplate) 오버헤드 제거 및 Lettuce Native 최적화
  • 단순 서버 리소스 부족이 아닌 RedisTemplate의 반복 커넥션 생성과 높은 추상화 레이어가 I/O 비용을 증가시키는 원인으로 규명
  • 불필요한 계층을 걷어내고 Lettuce Native 비동기 API 및 커넥션 풀링을 활용해 파이프라이닝 효율을 극대화하기로 결정
• 브로커가 아닌 Producer Client 내부 Partitioner 동작 버그 추적
  • 브로커나 컨슈머 구성 문제가 아닌 Producer의 메시지 할당 단계로 범위를 좁혀 원인 국소화
  • 특정 Client 버전의 StickyPartitioner에서 발생하는 배치 편중 버그를 규명하여 최신 Client 업그레이드로 근본 원인 해결

기술적 접근 및 구현

• Lettuce Native API 및 파이프라이닝 전환
  • RedisTemplate 대신 Lettuce 저수준 비동기 인터페이스를 직접 호출하여 드라이버 오버헤드 최소화
  • 커넥션 풀 재사용성과 배치 파이프라이닝을 적용해 네트워크 왕복 비용을 대폭 줄이고 100만 건 처리 시간 60초 확립
• Kafka Client 3.3+ 업그레이드 및 파티션 분배 검증
  • 파티셔너 내부 로직을 역추적해 이전 버전의 StickyPartitioner 동작 결함을 확인하고 안정화된 최신 버전으로 업그레이드
  • 파티션 전반에 걸쳐 레코드가 고르게 분산되는지 모니터링 지표로 확인하고 컨슈머 부하 균등화 달성

프로젝트 개요 정적 이미지 전용이던 레거시 C#/ASP.NET 광고 시스템에 기존 서빙 영향을 최소화하며 외부 VOD 솔루션을 Webhook 기반으로 연동해 동영상 광고 상품을 출시한 프로젝트

핵심 성과

• 기존 이미지 광고 운영 흐름의 수정 없이 동영상 광고 소재 타입 신규 확장
• 외부 VOD 인코딩 및 처리 상태를 내부 시스템과 실시간 연결하는 비동기 Webhook 동기화 구조 구축
• 광고 어드민부터 서빙 API까지 전 구간을 동영상 대응 구조로 확장하여 신규 광고 상품 런칭 지원

문제 상황

• 기존 광고 플랫폼이 오직 정적 이미지 배너만을 전제로 설계되어 동영상 미디어 인코딩 및 스트리밍 상태를 다룰 수 없는 한계
• 신규 동영상 광고 상품 런칭을 위해 외부 전문 VOD 솔루션의 업로드, 트랜스코딩 결과를 광고 시스템과 안정적으로 연결해야 하는 상황
• 장기간 운영된 레거시 C#/ASP.NET 코드베이스 특성상 직접적인 대규모 변경은 기존 이미지 광고 서빙에 장애를 유발할 높은 위험 상존

핵심 설계 판단

• 레거시 코어 침습 최소화를 위한 어댑터 계층 및 Webhook 비동기 연동 채택
  • 기존 이미지 처리 엔진을 직접 수정할 경우 핵심 광고 서빙에 장애를 유발할 높은 위험 상존
  • 외부 VOD 연동 전용 인터페이스로 동영상 로직을 격리하고, 인코딩 완료 이벤트를 Webhook으로 비동기 수신하여 기존 프로세스 영향 차단
• 외부 솔루션 장애 및 웹훅 유실에 대비한 2중 상태 보정 메커니즘 수립
  • 네트워크 순단 등으로 외부 Webhook 수신이 누락될 경우 상태 불일치가 영구화될 위험
  • 광고 상세 조회나 관리자 승인 시점에 외부 VOD API를 온디맨드로 폴링(Polling)해 실제 인코딩 상태를 재동기화하는 방어 로직 설계

기술적 접근 및 구현

• 동영상 광고 데이터 모델 및 어드민 인터페이스 확장
  • 스트리밍 엔드포인트, 썸네일, 재생 시간 등 동영상 메타데이터를 저장할 스키마를 확장하고 어드민 검수 화면 구현
• 보안 검증 기반 Webhook 수신 파이프라인 구축
  • 외부 솔루션에서 전달하는 인코딩 완료 웹훅 요청의 위변조 여부를 검증하고, 광고 상태(인코딩 중, 검수 대기, 게재 가능)를 즉시 동기화
• 네트워크 장애 대응 및 온디맨드 상태 폴링
  • 외부 API 통신 실패 시 지수 백오프 기반 재시도를 적용하고, 웹훅 누락 시에도 어드민 조회 시점에 원천 VOD 상태를 대조해 자동 복구
• 후속 광고 서빙 API 연계 및 무장애 배포
  • 노출 지면에서 동영상 소재를 재생할 수 있도록 응답 스펙을 확장하고, 기존 이미지 광고 기능을 포함한 전수 통합 테스트 후 서비스 배포

프로젝트 개요 온프레미스 단일 서버에 종속된 .NET 모놀리식 미디어 유통 솔루션을 AWS 기반 Node.js 마이크로서비스 아키텍처(MSA)로 전면 재설계 및 신규 개발한 프로젝트

핵심 성과

• 온프레미스 단일 서버 인프라 한계를 탈피해 AWS 클라우드 기반 MSA 아키텍처로 전면 전환 완료
• 강결합되어 있던 레거시 미디어 유통 관리 기능을 도메인별 독립적인 Node.js 마이크로서비스로 분리 및 신규 개발
• 트랜스코딩 등 고부하 미디어 처리 구간을 비동기 이벤트 기반으로 격리하여 서비스 확장성 확보 및 장애 전파(Cascading Failure) 위험 격리
• 실패한 미디어 작업은 DLQ 역할을 하도록 지정된 별도의 실패 재처리 토픽으로 격리하여 장애 격리 및 안정적인 재처리 체계 구축

문제 상황

• 온프레미스 단일 하드웨어 서버에 종속된 .NET 모놀리식 아키텍처로 인해 트래픽 증가 시 수평적 확장(Scale-out) 불가
• 미디어 관리, VOD 트랜스코딩, 사용자 권한, 배포 로직이 하나의 거대 프로세스에 강결합되어 있어 단일 기능 수정이나 장애가 전체 솔루션 중단으로 직결
• 새로운 미디어 처리 엔진 요구나 외부 플랫폼 연동 요구가 발생해도 모놀리식 구조의 복잡도로 인해 신속한 기능 확장이 불가능한 비즈니스 정체 직면

핵심 설계 판단

• 클라우드 단순 이전 대신 Node.js MSA 전면 재설계 및 신규 개발 결정
  • 레거시 .NET 코드를 클라우드 가상머신에 그대로 이전할 경우 유연성을 살리지 못하고 비용과 기술 부채가 지속되는 한계
  • 장기적 확장성과 기민한 B2B 대응을 위해 도메인 경계를 전면 재정의하고 Node.js 기반 마이크로서비스로 전면 신규 개발 결정
• 전체 AWS 클라우드 아키텍처 수립 및 컨테이너 기반 배포 체계 설계
  • 온프레미스 단일 물리 서버 환경의 의존성을 탈피하고 확장성을 확보해야 하는 과제
  • AWS ECS/Docker 기반의 독립 컨테이너 운영 환경을 구성하여 서비스별 독립 배포 및 오토스케일링 확립
• 비동기 이벤트 기반 통신 계층 도입을 통한 고부하 미디어 처리 디커플링
  • 장시간 소요되는 VOD 트랜스코딩과 서비스 간 상태 공유를 REST 동기 호출로 처리 시 스레드 병목과 장애 전파 위험
  • 단일 작업은 AWS SQS 버퍼링 큐로 격리하고, 상태 변경은 AWS EventBridge 이벤트 버스로 분리 발행하여 서비스 간 결합도 대폭 완화
• 작업 고유 ID 기반 멱등성 및 별도 실패 재처리 토픽 운영
  • 네트워크 재시도로 인한 중복 이벤트 인입 시 동일 비디오 처리가 중복 실행될 위험
  • 작업 고유 ID 기반 멱등성 검증을 적용하고, 반복 실패 작업은 본 작업 흐름을 방해하지 않도록 DLQ 역할을 수행하는 별도 지정 실패/재처리 토픽으로 격리하여 안전한 원인 파악 및 재처리 지원

기술적 접근 및 구현

• 온프레미스 .NET 레거시 분석 및 도메인 분리
  • 기존 모놀리식 데이터베이스와 코드 의존성을 전수 분석하여 미디어 자산 관리, 트랜스코딩 작업 제어, 외부 송출 등 핵심 도메인 경계 분리
• Node.js 기반 마이크로서비스 백엔드 신규 구현
  • 각 분리된 서비스별로 Node.js 기반의 고성능 REST API와 비즈니스 로직을 처음부터 새로 작성하고 표준화된 API 규격 수립
• AWS 클라우드 인프라 및 이벤트 파이프라인 구축
  • 인코딩 요청 인입 시 SQS로 작업을 큐잉하여 트래픽 스파이크 발생 시에도 안정적인 버퍼링 확보
  • 처리가 완료되면 EventBridge 버스를 통해 이벤트를 브로드캐스팅하고, 후속 서비스(알림, CMS 등)가 독립적으로 구독하여 상태 갱신 수행

프로젝트 개요 YouTube, Facebook 라이브 동시 송출 시 매번 반복되던 6단계 수동 설정을 OAuth 2.0 및 플랫폼 API 연동을 통해 원클릭 송출로 자동화한 프로젝트

핵심 성과

• 기존 6단계 수동 송출 설정 절차 → 최초 1회 OAuth 인증으로 대폭 단순화
• 스트림 키와 서버 주소를 직접 복사, 입력하며 발생하던 고객 설정 오타 및 휴먼 에러 원천 제거
• YouTube, Facebook의 상이한 인증 규격과 방송 수명주기를 단일 공통 인터페이스로 표준화

문제 상황

• 고객이 소셜 미디어 동시 송출을 위해 플랫폼 접속 → 로그인 → 방송 생성 → 스트림 키/서버 URL 발급 → 자사 솔루션 입력 → 송출 시작이라는 복잡한 6단계를 매 방송마다 반복
• 스트림 키와 RTMP URL을 수동으로 복사해 붙여넣는 과정에서 오타나 공백 누락으로 인한 방송 송출 실패 빈발
• YouTube와 Facebook의 OAuth 인증 방식, 토큰 만료 주기, 라이브 이벤트 생성 API 규격이 완전히 달라 파편화된 코드 유지보수 난항

핵심 설계 판단

• 플랫폼별 이기종 규격을 단일 인터페이스로 수렴시키는 어댑터 패턴 적용
  • YouTube와 Facebook의 상이한 방송 상태값과 파라미터로 인한 코드 파편화 및 유지보수 난항
  • 플랫폼별 규격을 내부 표준 라이브 도메인 모델로 매핑하여, 신규 플랫폼 추가 시에도 비즈니스 로직 수정 없이 어댑터만 확장 가능한 구조 확립
• 사용자 개입 없는 무중단 토큰 라이프사이클 관리
  • 토큰 만료로 인해 생방송 송출 직전에 인증이 풀리는 방송 장애 위험
  • Access Token 만료 임계 시점에 Refresh Token을 활용한 자동 백그라운드 갱신 파이프라인을 수립하고 DB 레벨 토큰 암호화 저장 적용

기술적 접근 및 구현

• 소셜 플랫폼 API 클라이언트 모듈화 및 공통 인터페이스 수립
  • YouTube Live Streaming API와 Facebook Live Video API를 모듈화하고 방송 생성, 상태 확인, 스트림 바인딩을 동일한 인터페이스로 캡슐화
• OAuth 2.0 Authorization Code Flow 및 보안 토큰 관리
  • 표준 OAuth 플로우를 통해 권한을 획득하고 민감한 토큰 정보를 AES-256으로 암호화하여 저장
  • 토큰 유효성을 사전 검증하고 만료 시 자동 재발급하는 미들웨어 레이어 구축
• 소셜 방송 생성 및 송출 파이프라인 원클릭 자동화
  • 버튼 클릭 한 번으로 소셜 방송 생성 → 스트림 키 획득 → Catenoid 인제스트 서버 설정이 원자적으로 완료되도록 흐름 구성
  • 단계별 에러 핸들링을 적용하여 외부 플랫폼 응답 지연이나 실패 시 안전하게 작업을 중단하고 사용자에게 명확한 가이드 제공

프로젝트 개요 수 GB 대용량 미디어 파일 업로드 시의 메모리 부하와 타임아웃 문제를 해결하기 위해 청크(Chunk) 분할 및 이어받기(Resumable) 엔진을 설계 및 구현한 프로젝트

핵심 성과

• 수 GB 대용량 미디어 파일의 업로드 안정성 증대 및 전송 무결성 개선
• 네트워크 단절 발생 시 전체 파일을 재전송할 필요 없이 실패한 청크 구간부터 자동 이어받기 지원
• 단일 스트림 전송 대비 브라우저 및 서버의 메모리 점유율을 50MB 이내 고정 상태로 안정화

문제 상황

• 수 GB 단위의 고화질 비디오 파일을 단일 HTTP POST 요청으로 업로드하면서 브라우저와 Node.js 서버 프로세스의 메모리 사용량 급증
• 네트워크 환경이 불안정한 환경에서 장시간 업로드 도중 커넥션이 끊기면 전체 파일을 처음부터 다시 올려야 하는 사용자 불편 가중
• 업로드 도중 실패한 임시 데이터가 서버 디스크에 정리되지 않고 남아 디스크 풀(Disk Full) 위험 상존

핵심 설계 판단

• 클라이언트 상태가 아닌 서버 검증 기반의 신뢰할 수 있는 이어받기 프로토콜 설계
  • 클라이언트 로컬스토리지에만 의존할 경우 브라우저 캐시 삭제나 멀티 디바이스 환경에서 오차 발생 위험
  • 업로드 재개 시 서버에 현재 파일 ID로 실제 디스크에 저장된 청크 목록을 직접 질의하여 일치하는 지점부터 안전하게 이어받도록 설계
• 경계 구간 무결성을 위한 마지막 청크 재전송 검증
  • 네트워크 비정상 종료 시 마지막 청크가 불완전하게 기록되어 파일이 손상될 위험
  • 직전 완료 청크의 크기 및 해시를 검증하고 필요 시 경계 청크를 안전하게 재수신하는 방어 로직 채택

기술적 접근 및 구현

• Blob Slice 기반 클라이언트 청크 분할 전송
  • 브라우저 File API의 slice()를 활용해 대용량 파일을 메모리에 통째로 올리지 않고 10MB 고정 단위 청크로 스트리밍 전송
  • 각 요청 헤더에 파일 고유 식별자, 총 청크 개수, 현재 청크 인덱스를 명시하여 순서 보장
• Node.js 임시 디렉토리 기반 청크 버퍼링 및 순차 병합
  • 서버에서는 파일 ID별 임시 디렉토리를 생성하여 청크를 개별 수신 및 저장
  • 모든 청크가 결함 없이 수신 완료된 시점에 스트림 파이프라인(fs.createReadStream, createWriteStream)을 통해 단일 미디어 파일로 고속 병합
• 실패 잔여물 정리 가비지 컬렉션(GC) 구현
  • 장기간 완료되지 않고 방치된 미완료 청크 디렉토리를 주기적으로 탐지하여 삭제하는 정리 스케줄러를 적용해 디스크 누수 방지

프로젝트 개요 EDN+(외부 매체 네트워크 광고) 서버를 Spring 기반 서빙 API로 전면 재구축하고, 당근마켓 광고 지면 연동을 구현한 프로젝트

핵심 성과

• 노후화된 Node.js 레거시를 Spring 기반의 고성능 광고 서빙 API로 전면 재개발
• 당근마켓 외부 광고 지면 신규 연동 성공 및 대규모 노출 트래픽의 안정적 서빙
• Google GDN, Criteo와 유사한 외부 네트워크 광고 시스템의 전반적인 백엔드 아키텍처 확립

문제 상황

• 기존 Node.js 기반 EDN+ 레거시 서버의 노후화로 런타임 안정성이 떨어지고 코드 확장이 어려운 한계
• 대규모 활성 사용자를 보유한 당근마켓 지면 연동이 확정됨에 따라 고가용성 서빙 처리 능력 필요
• 외부 매체의 초저지연 광고 요청에 대응하면서도, 판매자 제재 및 상품 품절 상태를 정확히 검증해야 하는 요구사항

핵심 설계 판단

• 초저지연 서빙 엔진과 운영 관리 백엔드의 책임 분리
  • 단일 서버에서 광고 서빙과 운영/정산을 병행할 경우 리소스 경합으로 서빙 지연 발생 위험
  • 광고 선택과 기본 유효성 검사(판매자 상태, 품절 여부)에 집중하는 초경량 서빙 API와, 게재 검수 및 정산 관리를 담당하는 운영 백엔드를 분리하여 서빙 지연 최소화
• 외부 매체 장애 격리 및 대체 광고(Fallback) 서빙 전략
  • 매체사 네트워크 지연이나 광고 선택 실패 시 매체 지면이 공백으로 노출될 위험
  • 기본 추천 광고를 즉시 반환하는 Fallback 메커니즘을 적용해 매체사 파트너십 신뢰도 및 광고 노출 기회 보장

기술적 접근 및 구현

• Spring 기반 신규 광고 서빙 API 개발
  • Node.js 레거시를 Spring 생태계로 전환하여 안정적인 스레드 모델과 모니터링 체계 구축
  • 메모리 캐싱을 활용해 판매자 제재 및 상품 품절 여부를 밀리초(ms) 단위로 고속 검증
• 당근마켓 매체 연동 인터페이스 설계 및 구현
  • 당근마켓 지면 요구사항에 맞춘 REST API 규격을 협의하고, 지면 요청 시 타겟 광고를 실시간 선택해 반환하는 파이프라인 구현
• 통합 운영 백엔드 환경 구축
  • 외부 매체 광고 게재 품질 관리 API, HTML 광고 크리에이티브 템플릿 처리 파이프라인, 광고주 및 매체사 정산 어드민 개발