포트폴리오

• Jira, Wiki, Codebase, Markup을 기반으로 프론트엔드 개발 워크플로우
  • Jira, Wiki, Codebase, Markup을 기반으로 요구사항 분석부터 화면 구현, 검증까지 단계별 프롬프트와 산출물 전달 방식을 정의해 기존 프로젝트 구조에 맞는 프론트엔드 개발 워크플로우 구성
• Jira 기반 QA 1차 검증 자동화
  • Jira 요구사항을 기준으로 구현 범위를 추적하고 Playwright E2E 테스트, Screenshot, Video 결과와 대시보드를 연계해 이슈 단위 1차 QA 자동화
• 프론트엔드 개발 진입장벽 완화
  • 프론트엔드 경험이 없는 백엔드 개발자도 기존 코드와 화면 산출물을 기준으로 Next.js, React 개발에 참여할 수 있는 프로세스 구축

• 공식 Design System이 없는 상태에서 AI Agent가 화면을 구현하면서 컴포넌트 구조, 스타일, 인터랙션을 일관되게 판단할 기준이 부족
• UX 디자이너의 Figma와 퍼블리셔 산출물은 존재했지만 기획, 기존 코드, 화면 결과물이 서로 다른 형태로 관리되어 AI가 전체 요구사항을 한 번에 파악하기 어려운 환경
• 프론트엔드 경험이 없는 팀원이 AI Agent를 활용하더라도 구현 결과가 실제 요구사항과 일치하는지 직접 검증하기 어려운 문제 존재

• 퍼블리셔 산출물을 UI 구현 기준으로 활용
  • 퍼블리셔와 디자이너가 협의해 완성한 HTML/CSS 마크업과 화면 결과물을 기준으로 Next.js, React 컴포넌트를 구현하도록 개발 흐름 구성
• Jira, Wiki, Codebase, Markup 통합 컨텍스트 구성
  • AI Agent가 화면을 구현할 때 Jira의 요구사항, Wiki의 업무 정책, 기존 Codebase의 구현 패턴, 이미지 및 정적 Mockup의 화면 기준을 함께 참고하도록 구성
  • Jira: 기능 요구사항 및 Acceptance Criteria
  • Wiki: 업무 규칙과 화면 동작에 필요한 도메인 정보
  • Codebase: 기존 컴포넌트 구조, API 연동 방식, 프로젝트 구현 패턴
  • Mockup: 이미지 및 퍼블리셔 HTML/CSS 기반 실제 화면 구현 기준
• 기존 프로젝트 패턴 우선 적용
  • AI가 임의의 컴포넌트나 구조를 새로 생성하기보다 기존 프로젝트의 컴포넌트, API 호출 방식, 상태 관리 패턴을 우선 재사용하도록 개발 기준 구성
• Jira 기반 QA 자동화 파이프라인 구축
  • Jira 티켓을 기준으로 요구사항 분석 및 구현 태스크 분해
  • Jira, Confluence, GitHub에서 구현 근거 확인
  • Playwright E2E 테스트 생성 및 실행
  • Screenshot, Video 결과를 대시보드에서 1차 검증
  • PR Review를 통해 최종 구현 결과 확인

프로젝트 개요: 제휴마케팅 팀 합류 후 유입→주문→정산 흐름을 직접 분석하고, 이기종 데이터 저장소 5종에 걸친 추적을 AI 에이전트가 자연어로 수행하는 MCP 서버 설계, 구축

핵심 성과

• 장애 디버깅 수십 분 → 자연어 한 줄: 여러 DB 클라이언트와 SQL을 오가던 추적 과정을 유입부터 정산까지 연결된 단일 리포트로 전환
• 19개 핵심 플로우 카탈로그 구축: 6개 서브프로젝트의 엔트리포인트 1,000+개 분석, 미분류 엔트리포인트에서 누락 후보를 다시 찾는 검증 루프 구성
• PCS 비정상 유입 역추산 내재화: 담당자 경험에 의존하던 혼종, 위조 토큰, 봇 판정 절차를 팀 전체가 같은 순서로 재현 가능한 추적 흐름으로 전환

문제 상황

• 클릭 유입부터 주문, 정산까지의 귀속 체인이 Oracle, MongoDB, MSSQL, Redis, Databricks에 분산
• 장애 발생 시 여러 DB 클라이언트에서 SQL을 직접 작성하고 결과를 수동 대조 → 원인 추적에 수십 분 소요
• 이벤트와 저장 위치를 연결하는 구조적 문서 부재 → 신규 담당자의 도메인 파악이 개인 인수인계에 의존

주요 판단

• 정해진 화면만 제공하는 별도 어드민 대신, AI 에이전트가 현재 추적 맥락에 맞춰 여러 조회 기능을 조합할 수 있는 MCP 선택
• 개발 장비가 필요한 코드 구조 분석과 컨테이너에서 실행 가능한 운영 데이터 추적을 분리 → 배포 환경에서도 핵심 추적 기능 유지
• 기존 서비스의 접속 설정과 시크릿 체계를 그대로 사용 → 별도 데이터 복제 없이 실제 운영 맥락에서 교차검증

해결 방법

• 비즈니스 플로우 카탈로그: HTTP 1,002개, Batch 24개, Kafka 7개, Scheduled 9개 엔트리포인트 분석 → 19개 핵심 흐름과 연관 테이블 구조화
• 코드 구조 분석 계층: 요청, 배치, 이벤트 진입점에서 호출 흐름과 접근 테이블을 추출해 추적의 시작점 제공
• 운영 데이터 추적 계층: 유입, 주문, 정산 데이터를 동일 식별자로 연결해 단계별 상태와 누락 구간 확인
• Databricks 교차검증 계층: 개발 환경에서 직접 조회하기 어려운 IM 유입, 옥션 주문, 정산 미러를 silver 레이어에서 동일 키로 대조
• 비정상 유입 판정 흐름: 제휴사 조합 검증, 토큰 역추산, 사용자 에이전트 대조 절차를 재현 가능한 순서로 고정

프로젝트 개요: 정적 분석에서 추출한 코드 구조를 DB, GitHub, Jira, Confluence 근거와 교차검증하고, 아키텍처와 비즈니스 흐름을 출처가 남는 위키로 변환하는 로컬 우선 생성 엔진 설계, 개발

프로젝트 링크: Landing Page, GitHub

핵심 성과

• 코드 팩트에서 비즈니스 문서로 변환: 호출 구조에 실제 DB 스키마와 프로시저, 변경 이력과 운영 정책을 결합 → 배치 순서, 실패와 재처리, 데이터 흐름, 도메인 규칙까지 문서화
• 페이지 단위 출처 추적: 코드, 그래프, DB, GitHub, Jira, Confluence 근거의 경로, 조회 시점, 발췌 내용을 기록 → 생성된 설명을 원문까지 추적 가능한 구조 확보
• 개발 환경 의존성 제거: FastAPI, Next.js, Go 에이전트를 Electron 앱으로 패키징 → 별도 런타임 설치 없이 실행 가능한 macOS 배포물 구성
• 271개 자동화 테스트 통과: Python 194개, TypeScript 53개, Electron 15개, Go 9개로 생성 파이프라인과 데스크탑 실행 경로 검증

문제 상황

• Private 저장소, On-prem DB, Jira, Confluence를 사용하는 조직 환경 → 외부 인덱싱 SaaS에 코드와 운영 정보 전송 불가
• 코드만 읽으면 저장 프로시저 분기, 배치 실행 의도, 정산 규칙 등 비즈니스 맥락 누락
• 초기 실행에 Node.js, Python, Poetry 등 전체 개발 도구 필요 → 개발자가 아닌 사용자의 독립 실행 어려움

주요 판단

• 소스 전체를 LLM에 전달하지 않고 클래스, 함수, 의존성, 호출 관계와 연관 파일을 먼저 추출 → 문서 목차와 페이지별 검색 범위를 코드 구조로 제한
• DB와 협업 문서를 광범위하게 검색하면 노이즈와 정보 노출이 커짐 → 코드에서 발견한 테이블, 저장 프로시저, 서비스명을 외부 근거 조회 키로 사용
• 코드는 시스템이 어떻게 동작하는지, DB는 실제 데이터 구조가 무엇인지, GitHub와 Jira, Confluence는 왜 바뀌었고 어떤 정책을 따르는지 설명 → 서로 다른 근거의 역할을 분리해 조합
• 웹 UI를 유지하면서 로컬 파일시스템 접근과 백엔드 프로세스 실행이 필요 → Electron을 배포 경계로 선택

해결 방법

• 위키 생성 엔진: 저장소 해석 → AST와 호출 그래프 생성 → 15~30개 페이지 목차와 연관 파일 계획 → 페이지별 컨텍스트 구성 → Markdown, Confluence 게시 흐름 설계
• 페이지별 컨텍스트 선별: 문서 주제와 연관 파일을 기준으로 AST 요약과 다이어그램을 선택하고, 그래프 인덱스와 원문 코드를 단계적으로 보강 → 전체 저장소 주입 없이 필요한 근거만 사용
• 엔티티 기반 MCP 역조회: 코드에서 추출한 테이블과 실제 DB 객체의 교집합을 구해 스키마와 프로시저 원문을 조회하고, 서비스명과 문서 주제로 GitHub, Jira, Confluence 근거 검색
• 교차검증과 출처 기록: 코드의 SQL 참조를 실제 DB 스키마와 대조하고 소스 경로를 GitHub에서 재검증 → 근거 유형, 경로, 조회 시점, 발췌 내용을 페이지에 함께 기록
• 장시간 AI 작업의 백엔드화: 생성 작업 수명주기, 공급자별 동시성 제한, 실시간 이벤트 스트리밍, 중단과 재개, 캐시 재사용을 FastAPI에서 관리
• 결정론적 다이어그램: 코드에서 추출한 관계를 Mermaid로 변환 → 모델 응답과 다이어그램 구조 분리
• 로컬 배포 안정화: Electron 프로세스가 API와 에이전트 생명주기를 관리하고, 제한된 재시작과 crash-loop 차단으로 반복 장애 격리
• 실행 경로 통합: UI, CLI, Docker가 같은 위키 생성 파이프라인을 공유하고 생성 결과를 Markdown 또는 Confluence로 전달

• 랭킹 갱신 시간 최대 4시간 → 3분 이내
• p99.9 기준 랭킹 조회 응답 10ms 이내
• 랭킹 반영 지연으로 발생하던 광고주 CS 및 환불 문제 해소
• 피크 타임 TPS 30,000 수준의 트래픽에서 랭킹 갱신 안정적 처리

• 광고주의 입찰가 변경, 예산 소진 등 랭킹 갱신 이벤트 발생 후 실제 랭킹에 반영되기까지 최대 4시간이 소요
  • 랭킹 반영 지연으로 광고주 CS 및 환불 발생
• .NET, MS-SQL 기반 동기식 처리 구조에서 피크 타임 TPS 30,000 구간의 처리 지연 발생
• 수백만 건의 랭킹 데이터를 처리하면서 DB I/O 대기와 반복 연산이 누적되어 CPU 사용률 급증
  • 레거시 코드에 다수의 블로킹 처리 구간 존재
  • 실제 처리량에 비해 불필요한 조회와 반복 연산이 수행되는 병목 구간 존재

• 기존 시스템 부분 최적화의 한계
  • 피크 타임 MSSQL CPU Usage가 90% 수준까지 상승해 기존 DB와 처리 구조를 유지한 상태의 튜닝만으로는 개선에 한계가 있다고 판단
• MongoDB에 맞는 데이터 모델 재설계
  • 기존 RDB 스키마를 그대로 이전하지 않고 실제 랭킹 조회 패턴을 기준으로 Document 구조를 새로 설계
  • 레거시 시스템의 블로킹 지점과 병목 구간을 먼저 분석한 후 MongoDB 모델링에 반영
  • 단일 SP에서 6개 테이블을 대상으로 수행하던 다중 JOIN 구조 제거
  • 과도하게 정규화된 데이터를 조회 단위에 맞게 역정규화하여 조회 과정의 연산과 DB 접근을 축소

• 랭킹 처리 구조 비동기화
  • 기존 동기, 블로킹 처리 구간을 Spring WebFlux, Reactor Flux/Mono 기반으로 전환
  • DB I/O 대기 중에도 다른 랭킹 갱신 작업을 처리할 수 있도록 실행 흐름 재구성
• MongoDB 조회 중심 모델링
  • 기존 MSSQL의 다중 테이블 JOIN 구조를 제거하고 랭킹 조회 단위에 맞춰 데이터를 하나의 Document로 구성
  • 주요 조회 조건을 기준으로 복합 인덱스를 구성하고 Explain Plan과 성능 테스트를 통해 조회 성능 검증
• 대량 랭킹 갱신 워크플로우 분리
  • 대량 랭킹 산정 및 갱신 작업을 API 요청 흐름에서 분리해 Kafka로 전달
  • Consumer에서 비동기로 처리해 API 서버와 랭킹 갱신 작업의 부하를 분리
• 병목 제거 및 성능 검증
  • 레거시 분석에서 확인한 다중 JOIN, 블로킹 I/O, 불필요한 반복 연산 구간 제거
  • 성능 테스트와 Datadog을 통해 p99.9, Latency, RPS, TPS, CPU Usage를 비교하며 개선 결과 검증

프로젝트 개요: 검색광고 정산 Bill/Pay 데이터와 랭킹 갱신 스냅샷 데이터를 기존 Hue, Hadoop, MongoDB 기반 처리 환경에서 Databricks로 이관. 기존 데이터 흐름 분석부터 파이프라인 설계, 구현, 데이터 검증까지 진행

핵심 성과

• 기존 Hadoop 환경에서 반복적으로 발생하던 배치 실패를 이관 이후 0건으로 개선
• 새벽 시간대 담당자가 직접 수행하던 수동 재실행 업무 해소
• 처리 단계별 건수, 금액, 주요 키를 비교하는 검증 구조를 추가해 정산 데이터 검증 체계 확보

문제 상황

• Hue, Hadoop 인프라의 리소스 부족으로 검색광고 정산 배치가 반복적으로 실패
  • 배치 실패 시 담당자가 새벽 시간대에 직접 확인하고 재실행하는 운영 업무 발생
• 광고 정산 Bill/Pay 데이터와 랭킹 스냅샷 데이터가 서로 다른 환경에서 처리되어 데이터 흐름이 분산
• 정산 데이터 특성상 시스템 이관 과정에서도 건수, 금액, 대상 데이터의 정합성 유지 필요

주요 고민 포인트

• 기존 정산 결과 유지
  • 실행 환경을 Databricks로 변경하더라도 기존 배치와 동일한 정산 결과가 나오는 것이 가장 중요한 요구사항
• 이관 데이터 검증
  • 최종 결과만 비교하면 오류 발생 지점을 찾기 어려워 원천, 중간 집계, 최종 결과 단계별 검증이 필요
• 배치 운영 개선
  • 단순히 기존 배치를 옮기는 것이 아니라 반복적인 실패와 수동 재실행 문제까지 함께 해결하는 방향으로 이관

기술적 접근 및 구현

• 기존 데이터 흐름 분석
  • Hue, Hadoop 기반 Bill/Pay 데이터의 생성, 집계, 검증 순서를 분석
  • MS-SQL 원천 정산 데이터와 MongoDB 랭킹 스냅샷의 사용 목적과 연관 관계 정리
• Databricks 기반 파이프라인 재구성
  • 기존 배치 구조를 원천 데이터 적재 → 중간 집계 → 최종 정산 결과 생성 단계로 재구성
  • MongoDB에서 처리하던 랭킹 갱신 스냅샷 데이터도 Databricks 기반으로 이관
• 단계별 데이터 검증
  • 중간 집계 단계에서 처리 건수와 금액 합계를 비교할 수 있도록 검증 구조 구성
  • 광고, 셀러, 기간 단위 주요 키를 기준으로 데이터 누락 및 불일치 여부 확인
• 원천 데이터 교차검증
  • MS-SQL, MongoDB 원천 데이터와 Databricks 처리 결과를 비교해 이관 결과 검증
  • 데이터 차이 발생 시 중간 집계 단계를 기준으로 오류 발생 구간을 추적할 수 있도록 구성

프로젝트 개요: 검색광고 랭킹 시스템의 MS-SQL → MongoDB 전환 과정에서 발생한 데이터 불일치 문제를 해결하기 위해 실시간 반영, Kafka 실패 재처리, Spring Batch 정합성 검증으로 구성된 3단계 동기화 파이프라인 설계 및 구현

핵심 성과

• 상용 CDC 솔루션 없이 MS-SQL → MongoDB 데이터 동기화 구조 구축
• 실시간 반영 실패 건을 Kafka에서 자동 재처리할 수 있는 복구 구조 확보
• 주기적으로 원천 데이터와 비교하고 불일치 데이터를 보정해 일시적인 장애가 장기간 데이터 불일치로 남는 문제 방지

문제 상황

• 검색광고 랭킹 시스템을 MS-SQL에서 MongoDB로 전환하는 과정에서 간헐적인 데이터 불일치 발생
• 입찰가, 예산 등 랭킹에 영향을 주는 데이터의 변경 사항을 MongoDB에도 빠르게 반영할 필요
• 비용 및 기술적 제약으로 상용 CDC(Change Data Capture) 솔루션 도입 불가

주요 고민 포인트

• 단순 Dual Write의 한계
  • 하나의 API 요청에서 MS-SQL, MongoDB에 동시에 쓰는 구조는 한쪽 저장소 실패 시 두 데이터의 상태가 달라질 가능성 존재
  • 서로 다른 데이터베이스를 하나의 트랜잭션으로 처리하는 방식보다 실패를 전제로 복구할 수 있는 구조가 필요
• 실시간성과 최종 정합성 분리
  • 모든 실패를 실시간 처리 단계에서 해결하기보다 빠른 데이터 반영과 실패 복구, 최종 데이터 검증의 역할을 분리

기술적 접근 및 구현

• 1단계: API 실시간 반영
  • 데이터 변경 요청 발생 시 Spring WebFlux 기반 비동기 처리로 변경 내용을 MongoDB에 즉시 반영
• 2단계: Kafka 실패 재처리
  • MongoDB 반영 실패 시 동기화 대상 데이터를 Kafka Topic으로 전달
  • 별도 Sync Consumer에서 실패 데이터를 다시 처리하고 재처리 대상 모니터링
  • 메시지 키를 기준으로 파티셔닝해 동일 데이터 변경 이벤트의 처리 순서를 유지
• 3단계: 원천 데이터 기준 정합성 검증
  • MS-SQL 변경 이력 테이블을 기준으로 MongoDB 데이터와 주기적으로 비교
  • 불일치가 확인된 데이터를 다시 반영하는 Spring Batch 기반 동기화 작업 구현
• 다단계 복구 구조
  • 실시간 반영 실패를 Kafka에서 재처리하고, 이후 원천 데이터 기준 Batch 검증을 한 번 더 수행하도록 구성

프로젝트 개요: 검색광고 랭킹 시스템 개선 과정에서 발생한 Redis 대량 처리 성능 저하와 Kafka 특정 파티션 메시지 편중 문제를 모니터링 지표와 Client 내부 동작 분석을 통해 원인 파악 및 개선

핵심 성과

• Redis 100만 건 처리 시간 240초 → 60초로 단축
• Kafka 특정 파티션으로 집중되던 메시지 분배 불균형 문제 해결
• 단순 설정 변경이 아닌 Client 동작과 운영 지표를 기반으로 병목 원인을 분석하고 개선

문제 상황

• Redis 대량 처리 지연
  • 랭킹 갱신 과정에서 Redis 100만 건 처리에 약 240초가 소요되어 전체 처리 시간의 주요 병목으로 확인
  • 배치 실행 시 Datadog에서 Redis Connection 수가 급격하게 증가하는 현상 확인
• Kafka 파티션 편중
  • Producer에서 발행한 메시지가 전체 파티션에 분산되지 않고 일부 파티션으로 집중
  • 파티션별 Consumer 처리량 편차가 커지면서 전체 랭킹 갱신 처리에도 영향 발생

주요 고민 포인트

• Redis 호출 구조 분석
  • 단순 쿼리 성능 문제가 아니라 대량 명령 처리 과정의 Connection 사용 방식과 I/O 비용을 확인할 필요
• Kafka Client 내부 동작 분석
  • Broker나 Consumer 문제가 아닌 Producer의 메시지 분배 단계에서 문제가 발생하는 것으로 범위를 좁히고 Client 버전과 Partitioner 동작 확인

기술적 접근 및 구현

• Redis 처리 방식 개선
  • Datadog에서 배치 실행 시 Connection 증가와 처리 시간을 비교하며 병목 구간 확인
  • 기존 RedisTemplate 기반 처리 방식을 Lettuce Native API 기반으로 변경
  • 대량 명령 처리 방식을 개선해 네트워크 I/O 비용을 줄이고 100만 건 처리 시간을 240초 → 60초로 단축
• Kafka 파티션 편중 원인 분석
  • 사용 중인 Kafka Client 버전의 StickyPartitioner, RoundRobinPartitioner 동작을 분석
  • 특정 Client 버전에서 발생하는 파티션 분배 문제를 확인
• Kafka Client 변경
  • Kafka Client를 3.3 이상으로 업그레이드하고 변경된 Partitioner를 적용
  • 일부 파티션으로 집중되던 메시지가 전체 파티션으로 정상 분배되도록 개선

프로젝트 개요: 이미지 소재만을 기준으로 설계된 레거시 .NET 광고 시스템에 외부 VOD 솔루션을 연동하고 동영상 소재 타입을 추가해 신규 동영상 광고 상품 출시

핵심 성과

• 기존 이미지 광고 운영 구조를 유지하면서 동영상 광고 소재 타입 신규 추가
• 외부 VOD 처리 결과와 광고 시스템 상태를 연결하는 동기화 구조 구축
• 광고 어드민부터 후속 광고 API까지 동영상 소재 처리 범위를 확장해 신규 광고 상품 출시

문제 상황

• 기존 .NET 광고 시스템이 이미지 소재만을 전제로 설계되어 동영상 광고를 처리할 수 없는 구조
• 신규 동영상 광고 상품 출시를 위해 외부 VOD 솔루션의 업로드 및 변환 처리 결과를 기존 광고 시스템과 연결해야 하는 상황
• 장기간 운영된 레거시 광고 시스템 특성상 변경 범위를 넓힐 경우 기존 이미지 광고 기능에 영향을 줄 가능성 존재

주요 고민 포인트

• 레거시 변경 범위 최소화
  • 기존 이미지 광고 처리 흐름은 유지하면서 동영상에 필요한 데이터와 처리 로직만 추가하는 방향으로 설계
• 외부 시스템 상태 동기화
  • 외부 VOD 처리가 비동기로 진행되기 때문에 콘텐츠 생성 요청 성공 여부만으로 실제 처리 완료를 판단할 수 없음
  • 외부 시스템 장애나 상태 갱신 누락이 발생하더라도 내부 광고 상태를 다시 확인할 수 있는 복구 방식 필요

기술적 접근 및 구현

• 동영상 광고 타입 확장
  • 기존 광고 모델과 어드민에 동영상 타입, 파일 처리 기능을 추가
  • 기존 이미지 광고 처리 로직과 동영상 처리 로직의 영향 범위를 분리
• 외부 VOD 솔루션 연동
  • 외부 API를 통해 VOD 콘텐츠 생성 및 처리 상태 조회 기능 구현
  • 외부 처리 완료 이벤트를 Webhook으로 수신해 광고 시스템의 메타데이터와 상태를 갱신
• 상태 불일치 복구
  • 외부 API 호출 실패에 대한 재시도 처리 추가
  • 광고 상세 조회 시 외부 VOD의 실제 처리 상태를 다시 조회하고 내부 상태를 갱신하도록 구성
• 연관 시스템 확장
  • 광고 API 등 후속 시스템에서도 동영상 소재 정보를 처리할 수 있도록 데이터 모델과 응답 로직 확장
  • 기존 이미지 광고 기능을 포함한 통합 테스트 후 서비스 배포

프로젝트 개요: Loomex 미디어 유통 관리 솔루션을 .NET 모놀리식에서 Node.js MSA로 전환하는 과정에서 장시간 미디어 처리와 서비스 간 동기 호출을 AWS SQS, EventBridge, Lambda 기반 이벤트 처리로 분리

핵심 성과

• VOD 인코딩 등 장시간 작업을 API 요청 흐름에서 분리해 비동기 처리 구조로 전환
• 서비스 간 직접 호출을 줄이고 작업 요청과 상태 변경 이벤트의 역할을 구분
• 메시지 중복 처리와 실패 상황에 대응할 수 있는 재처리 구조 구축

문제 상황

• .NET 모놀리식 시스템의 기능 간 의존성이 높아 기능 변경 시 연관 영역의 영향 범위가 큰 구조
• MSA 전환 이후에도 서비스 간 동기 호출을 그대로 사용할 경우 특정 서비스의 지연이나 장애가 다른 서비스까지 전달될 가능성 존재
• VOD 트랜스코딩과 같은 장시간 작업을 API 요청 흐름에서 직접 처리하기 어려움

주요 고민 포인트

• 비동기 메시지 역할 구분
  • 특정 처리자가 수행해야 하는 작업과 여러 서비스가 알아야 하는 상태 변경을 동일한 메시징 방식으로 처리하지 않도록 기준 필요
• 메시지 중복 및 실패 처리
  • 비동기 메시지가 중복 전달되거나 처리 도중 실패할 가능성을 전제로 중복 방지와 재처리 구조 필요

기술적 접근 및 구현

• SQS 기반 작업 처리
  • VOD 트랜스코딩 요청처럼 하나의 처리자가 수행해야 하는 작업을 SQS로 전달
  • 실제 트랜스코딩 작업은 별도 Media Consumer에서 수행하고, Lambda는 작업 상태 업데이트나 후속 이벤트 처리 등 경량 작업에 활용
• EventBridge 기반 상태 변경 전달
  • 인코딩 완료, 채널 상태 변경처럼 여러 서비스가 각각 후속 처리를 해야 하는 이벤트를 EventBridge로 발행
  • 각 서비스가 필요한 이벤트만 독립적으로 구독하도록 구성
• 메시지 중복 및 실패 대응
  • 메시지 ID를 기준으로 동일 작업의 중복 실행을 방지하도록 처리
  • 반복적으로 실패한 메시지는 DLQ에 보관해 원인 확인 및 재처리
• 미디어 리소스 정리 자동화
  • Lambda, EventBridge Scheduler를 이용해 S3에 누적되는 라이브 스트림 Chunk와 Thumbnail을 정기적으로 삭제
  • DB의 채널 정보를 기준으로 리소스 보관 기간 적용
• 운영 모니터링
  • CloudWatch에서 SQS Queue 적재량, Lambda 오류 등 주요 비동기 처리 지표 모니터링

프로젝트 개요: 라이브 스트리밍 플랫폼에서 YouTube, Facebook 동시 송출을 위해 고객이 직접 수행하던 설정 과정을 OAuth 2.0과 플랫폼 API 연동을 통해 자동화

핵심 성과

• 기존 6단계 수동 송출 설정 → 최초 OAuth 인증 1회로 단순화
• 고객이 직접 스트림 키와 서버 주소를 발급하고 입력하던 과정 제거
• YouTube, Facebook의 서로 다른 API와 인증 방식을 내부 공통 흐름으로 통합

문제 상황

• 고객이 소셜 미디어로 동시 송출하기 위해 플랫폼별로 직접 방송을 생성하고 스트림 정보를 입력해야 하는 구조
  • 플랫폼 접속 → 로그인 → 방송 생성 → 스트림 키 및 서버 주소 발급 → 자사 솔루션 입력 → 송출 시작
• 기술에 익숙하지 않은 고객이 스트림 키와 서버 정보를 직접 입력하면서 오타와 설정 오류 발생
• YouTube, Facebook마다 서로 다른 API와 인증, 방송 생성 절차를 각각 처리해야 하는 문제

주요 고민 포인트

• 플랫폼별 차이 추상화
  • 사용자에게는 동일한 기능이지만 플랫폼별 API와 요청 방식이 달라 공통된 내부 인터페이스 필요
• OAuth Token 수명주기 관리
  • 최초 인증 이후에도 사용자가 반복적으로 로그인하지 않도록 Access Token 만료와 갱신 처리 필요
• 여러 API 호출의 실패 처리
  • 방송 생성부터 스트리밍 엔진 설정까지 여러 외부 API 호출이 연결되어 있어 중간 단계 실패에 대한 처리 방식 필요

기술적 접근 및 구현

• 플랫폼 API 모듈화
  • YouTube, Facebook별 API Client를 구현
  • 방송 생성, 스트림 정보 조회 등 공통 기능을 내부 인터페이스로 구성
• OAuth 2.0 인증 처리
  • 플랫폼별 Authorization Code Flow를 구현하고 Access Token, Refresh Token 관리
  • Access Token 만료 시 Refresh Token을 이용해 자동 갱신하도록 구성
  • 사용자 Token은 DB에 암호화하여 저장
• 송출 설정 자동화
  • 최초 계정 인증 후 저장된 Token을 이용해 방송 생성 → 스트림 정보 조회 → Catenoid 스트리밍 엔진 설정 순서로 자동 처리
• 외부 API 실패 처리
  • 각 API 호출 단계의 성공 및 실패 상태를 관리
  • 중간 단계에서 오류 발생 시 후속 작업을 중단하고 필요한 복구 또는 사용자 안내를 수행하도록 구성

프로젝트 개요: 수 GB 규모의 미디어 파일을 단일 HTTP 요청으로 업로드하면서 발생하던 브라우저, 서버 메모리 문제와 네트워크 타임아웃을 Chunk 분할 업로드 및 이어받기 방식으로 개선

핵심 성과

• 대용량 미디어 파일을 Chunk 단위로 분할 업로드하는 구조 구축
• 네트워크 단절 시 전체 파일을 다시 전송하지 단절 중단된 구간부터 이어받기 지원**
• 단일 HTTP 요청에서 발생하던 메모리 사용량 증가와 장시간 전송 타임아웃 문제 개선

문제 상황

• 수 GB 크기의 미디어 파일을 하나의 HTTP 요청으로 업로드하면서 브라우저와 서버의 메모리 사용량 급증
• 장시간 업로드 중 네트워크 상태에 따라 Timeout이 발생하고 업로드 실패
• 전송 중 오류가 발생하면 이미 업로드한 데이터와 관계없이 전체 파일을 처음부터 다시 전송해야 하는 구조

주요 고민 포인트

• 이어받기 기준
  • 단순히 클라이언트가 기억하고 있는 마지막 전송 위치를 신뢰하지 않고 서버에 실제 저장된 Chunk를 기준으로 재개할 필요
  • 네트워크 종료 시 마지막 Chunk가 정상적으로 저장되지 않았을 가능성까지 고려
• 파일 재조합
  • 여러 요청으로 나뉘어 수신되는 Chunk의 순서를 보장하고 모든 데이터가 수신된 시점에만 최종 파일을 생성해야 함

기술적 접근 및 구현

• Chunk 기반 분할 전송
  • 클라이언트에서 파일을 고정 크기의 Chunk로 분할
  • 파일 ID, 전체 Chunk 수, 현재 Chunk Index를 함께 전달해 각 Chunk 파악
• 서버 수신 상태 관리
  • 파일 ID를 기준으로 서버에 수신된 Chunk를 임시 저장
  • Chunk Index를 기준으로 현재까지 정상적으로 수신된 데이터 확인
• 이어받기 업로드
  • 재업로드 시작 시 서버에 기존 Chunk 목록을 조회
  • 이미 정상적으로 저장된 구간을 기준으로 필요한 Chunk부터 다시 전송
  • 마지막 전송 구간의 비정상 종료 가능성을 고려해 경계 구간을 다시 전송하도록 구성
• 최종 파일 재조합
  • 전체 Chunk 수신 여부를 확인한 후 Index 순서에 맞춰 최종 파일 생성
  • 파일 생성이 완료되면 임시 Chunk 데이터 삭제

프로젝트 개요: Gmarket의 외부 디스플레이 광고 네트워크 EDN+(Ebay Display Network AD) 서버를 Node.js 레거시에서 Spring 기반 신규 서빙 API로 새로 개발, 당근마켓 광고 지면 연동까지 구현

핵심 성과

• Node.js 레거시 → Spring 기반 신규 서빙 API 개발 완료
• 당근마켓 광고 지면 연동 구현 — 당근마켓에서 노출되는 배너 광고 API를 직접 서빙
• Google GDN, Criteo AD Choices와 유사한 외부 네트워크 광고 상품의 백엔드 시스템 전반 담당

문제 상황

• EDN+는 외부 디지털 매체에 Gmarket 광고를 노출하는 디스플레이 광고 네트워크 상품
• Node.js 레거시 서버 유지보수 한계와 당근마켓 신규 광고 지면 연동 요구 발생
• 광고 선택, 게재 품질 관리, 크리에이티브 처리, 정산 어드민까지 백엔드 흐름 재구축 필요

기술적 접근 및 구현

• Spring 기반 신규 서빙 API 개발: Node.js 레거시 광고 서버를 Spring 기반으로 재구축 (게재 품질 관리 및 크리에이티브 처리는 제외하고, 제한된 판매자 여부나 상품 품절 여부 등 기본 Validation 수행 후 서빙에 집중)
• 외부 매체 연동: 당근마켓과 API 연동 스펙 협의 및 설계, 지면 요청 시 적절한 광고를 선택해 반환하는 서빙 API 구현
• 운영 백엔드 구현: 외부 매체 광고 게재 품질 관리 API, HTML 광고 크리에이티브 템플릿 처리 서버, 광고주, 매체사 정산 어드민 개발