포트폴리오

프로젝트 개요: AIDC(Ali International Digital Center) 통합 광고센터 프로젝트에서, 프론트엔드 경험이 없는 팀원도 Next.js , React 개발에 참여할 수 있도록 AI Agent 기반 개발 워크플로우와 Playwright E2E QA 자동화 파이프라인을 직접 설계 및 구축

핵심 성과

• 디자인 시스템 없는 환경에서 4-Source 멀티모달 컨텍스트 기반 AI Agent 개발 체계 설계
• Jira Evidence 매핑 + Playwright E2E + 대시보드로 이슈 단위 QA 1차 검증 자동화
• 프론트엔드 비경험 팀원도 개발 참여 가능한 체계 수립

문제 상황

• AI Agent 기반 개발의 전제 조건인 명확한 설계 기준점(Design System) 부재 — 컴포넌트 구조, 스타일, 인터랙션 해석이 흔들리는 문제 발생
• 공식 디자인 시스템 없이 UX 디자이너의 Figma 작업만 존재하여, AI가 참고할 컴포넌트 토큰이나 스타일 가이드 부재

기술적 접근 및 구현

• 비공식 Design Token 활용: 퍼블리셔와 디자이너가 협의해 완성한 HTML/CSS 마크업 산출물을 비공식 Design Token으로 활용, Next.js 포팅 체계 구성
• 4-Source 멀티모달 컨텍스트 제공: AI Agent의 이해도, 정확도 향상을 위해 4가지 소스를 동시 제공
  • Figma MCP 메타데이터 (레이아웃, 컴포넌트 의도), 퍼블리셔 HTML/CSS 산출물 (마크업 기준점), 퍼블리셔 산출물 스크린샷 (시각적 레퍼런스), 정제된 기획 문서 (기능, 인터랙션 정의)
• QA 자동화 파이프라인 구축
  • Jira 티켓 파싱 → AI 이슈 분석 및 태스크 분해 → Evidence 매핑(Jira, Confluence, GitHub 근거 데이터로 AI 작업 범위 제한) → Playwright E2E 테스트 자동 생성(Screenshot, Video Recording) → 대시보드 1차 자동 검증 → PR Review 2차 사람 검증

한계 및 개선 방향

• Visual Regression Testing 미적용: 완료 확인용 스크린샷에서 Expected vs Actual 픽셀 비교를 통한 1차 검증 완전 자동화 필요
• 산출물 동기화 전략 부재: 퍼블리셔 마크업 수정 시 AI 컨텍스트 갱신을 위한 버전 관리 또는 변경 감지 연동 필요
• 테스트 커버리지 미측정: AI 생성 E2E 테스트의 핵심 유저 플로우 커버리지를 위한 Coverage Report 연동 필요

프로젝트 개요: Public Repo만 지원하는 DeepWiki를 사내 환경(Private Repo, On-prem DB, Jira/Confluence)에서 사용할 수 없다는 한계에서 출발해, 1인 오픈소스로 개발한 Private 환경용 DeepWiki 대안 시스템. 코드베이스만 분석하는 기존 도구와 달리, DB(MCP), GitHub MCP, Jira, Confluence 등 다중 데이터 소스를 교차 검증하여 문서의 정확도와 품질을 높인 것이 핵심 차별점

핵심 성과

• 저렴한 모델에서도 문서 품질 편차 축소: 정적 분석으로 추출한 코드 구조 팩트를 LLM에 선주입 → 모델 성능에 따른 품질 편차를 줄이고, 근거 기반 문서 생성 가능
• 코드베이스만으로 파악 불가능한 비즈니스 레이어 분석: DB(MCP), GitHub, Jira, Confluence 다중 소스 교차 검증 → 코드에 드러나지 않는 정산 규칙, 배치 스케줄링 의도, 도메인 정책까지 문서화

문제 상황

• 사내 환경: Private 레포, On-prem MSSQL, Jira/Confluence — 외부 SaaS(DeepWiki 등) 적용 불가
• 담당자 부재 시 전체 비즈니스 맥락 파악에 수 주 소요 — 온보딩 병목이 반복됨
• 기존 도구 한계: Public GitHub 중심, 외부 서버로 코드 전송 필요, 로컬 완결 불가

기술적 접근 및 구현

• Code-Sonar 정적 분석 엔진

  • tree-sitter + regex fallback으로 LSP 없이 8개 언어(Python, TS/JS, Go, Java, Rust, Ruby, C#, PHP) 코드 구조 직접 파싱
  • ASTAnalyzer → CallGraph(Node/Edge 의존성 그래프) → MermaidGen 3단계 파이프라인
  • 연결이 많은 핵심 노드만 우선 표시하고, 나머지는 디렉토리 단위로 묶어 다이어그램 복잡도 제어
  • 매번 반복되는 파싱 단계의 비효율 → 정적 분석 결과 캐싱 도입으로 동일 레포 재분석 시 파싱 비용 제거

• 정적 분석 기반 LLM 품질 균일화

  • 정적 분석으로 추출한 클래스, 함수, 의존성 요약을 프롬프트에 선주입
  • "무엇을 다뤄야 하는지"를 코드 팩트로 고정 → 저성능 로컬 모델에서도 환각 및 누락 없는 균일한 문서 품질 확보
  • 다이어그램은 LLM 개입 없이 정적 분석 결과만으로 렌더링 → 응답 품질에 의존하지 않는 안정적 다이어그램 생성

• DeepResearch 모드 도입

  • 한 번의 질문-답변만으로는 복잡한 로직 파악 불가 → LLM이 스스로 계획을 세우고 코드를 최대 5번까지 반복 탐색하는 DeepResearch 모드 구축
  • 긴 탐색 시간으로 인한 사용자 대기 경험 저하 방지 → WebSocket을 연동해 AI의 분석 과정을 화면에 실시간으로 중계

• 멀티 LLM 추상화

  • Gemini, Claude, OpenAI, OpenRouter, Ollama, LiteLLM 통합
  • CLI subscription 모드: gemini-cli, codex, claude-cli — API 키 없이 구독형 CLI로 사용 가능

프로젝트 개요: .NET, MS-SQL 기반 검색광고 랭킹 갱신 구조를 Spring Webflux, MongoDB 기반으로 재설계 — 기존 담당자와 2인 진행, 레거시 분석부터 모델링, 구현, 성능 검증까지 참여

핵심 성과

• 랭킹 갱신 시간 최대 4시간 → 3분 이내 (96% 단축)
• p99.9 기준 조회 응답 10ms 이내 (기존 평균 100~200ms)
• 검색 광고 랭킹 업데이트 지연으로 인한 광고주 CS 및 환불 비용 발생 문제 해소
• 피크 타임 대규모 트래픽(TPS 30,000) 랭킹 갱신 안정적 처리

문제 상황

• 광고주의 입찰가 변경, 예산 소진 이벤트가 랭킹에 반영되기까지 최대 4시간 소요 → 최신 정보 미반영, 광고주 CS, 환불 발생
• .NET, MS-SQL 기반 동기식 블로킹 처리로 피크 타임 TPS 30,000 구간에서 처리 불안정
• 수백만 건 랭킹 데이터 처리 중 DB 응답 대기와 단일 흐름 계산이 겹치며 CPU 사용률 급증

주요 고민 포인트

• 기존 시스템 부분 최적화 한계: 쿼리, 인덱스, 캐시 개선만으로는 블로킹 I/O 병목 해소가 어려운 구조 → Spring Webflux 기반 논블로킹 처리로 전환
• 랭킹 데이터 모델 전환: 읽기 중심 조회 패턴, 낮은 조인 필요성 → 자주 함께 조회되는 필드를 MongoDB 도큐먼트로 묶어 조회 비용 축소
• 레거시 로직 이관 리스크: 기존 계산 결과를 유지하며 저장소와 실행 모델을 동시 교체 → 랭킹 업데이트 시간 및 성능 테스트 결과 지표(TPS, p99.9)를 이용하여 목표 성능 달성 여부 검증

기술적 접근 및 구현

• 리액티브 처리 전환: Reactor Flux/Mono 기반 비동기 스트림으로 대규모 랭킹 갱신 처리
• MongoDB 모델링 최적화: 역정규화 도큐먼트 설계, 복합 인덱스 구성, 실행 계획 검증으로 조회 성능 튜닝
• 대량건 메시징 처리: 무거운 랭킹 산정 로직은 API 응답 흐름과 분리해 Kafka Consumer에서 별도 처리, API 레이어 부하 집중 완화
• 지표 기반 성능 검증: 성능 테스트 및 Datadog 기반 모니터링을 통해 핵심 지표(p99.9, Latency, RPS, TPS) 기반 병목 추적 및 개선

프로젝트 개요: 검색광고 정산(Bill/Pay) 데이터 및 랭킹 갱신 스냅샷 데이터를 Hue/Hadoop 환경에서 Databricks로 이관 — 파이프라인 설계·구현·검증 주도

핵심 성과: 이관 후 배치 실패 0건 (기존 반복 발생하던 새벽 수동 재실행 완전 해소) / 단계별 검증 구조로 광고 정산 데이터 정확도 확보

문제 상황

• Hue/Hadoop 인프라 리소스 부족으로 배치가 반복 실패 → 담당자가 새벽 시간대 수동 재실행 상시 발생
• 광고 정산(Bill/Pay)과 랭킹 스냅샷 데이터가 서로 다른 처리 환경에 분산
• 정산성 데이터 특성상 누락·중복·금액 불일치 방지가 필수

주요 고민 포인트

• 플랫폼 전환 대응: 전사 차원의 Databricks 도입 결정 → 이에 발맞춰 기존 Hadoop 기반 배치를 마이그레이션하며, 기존의 반복적인 배치 실패 문제까지 동시 해결하는 워크플로우로 이관
• 정산 데이터 검증이 핵심 과제: 금액·건수 단위 오차가 실제 광고주 정산에 직접 영향을 주므로, 이관 결과를 원천(MS-SQL, MongoDB) 데이터와 단계별로 자동 비교하는 검증 구조를 먼저 설계

기술적 접근 및 구현

• 기존 흐름 분석: Hue/Hadoop 기반 Bill/Pay 처리 순서, MS-SQL 원천 정산 데이터 및 MongoDB 랭킹 스냅샷 사용 목적 파악
• Databricks 파이프라인 재구성: 원천 적재 → 중간 집계 테이블 → 최종 정산 결과 테이블 워크플로우로 전환
• 단계별 검증 구조: 중간 집계 기준 건수·금액 합계 자동 비교 → 정산 오류 사전 방지, 실패 구간 추적 가능한 구조 확보
• 원천 데이터 비교: 광고·셀러·기간 단위 주요 키 기준으로 MS-SQL/MongoDB 원천과 이관 결과 정합성 검증

프로젝트 개요: 검색광고 랭킹 시스템의 MS-SQL → MongoDB 전환 과정에서 간헐적 데이터 불일치 문제를 해결하기 위해 3단계 자체 동기화 파이프라인 설계·구현

핵심 성과: 상용 CDC 솔루션 없이 실시간 데이터 정합성 보장 / 실패 트랜잭션 자동 복구 / 광고주 CS 인입 감소 및 운영 효율 개선

문제 상황

• MS-SQL → MongoDB 전환 과정에서 간헐적인 데이터 불일치 발생
• 광고 랭킹 데이터는 비즈니스 핵심 자산으로 실시간 정합성 필수
• 예산·기술 제약으로 상용 CDC(Change Data Capture) 솔루션 도입 불가

주요 고민 포인트

• 초기 접근의 한계: 변경 API 호출 시 두 DB에 동시 쓰는 방식을 고려했으나, 분산 트랜잭션 보장이 불가능하고 한쪽 실패 시 불일치가 심화되는 구조적 문제 존재
• 핵심 고민: 실시간성 + 실패 복구 + 최종 정합성 보장 세 가지를 동시에 달성하는 구조가 필요 → 단일 메커니즘으로는 불가능해 3단계 계층형 아키텍처로 설계

기술적 접근 및 구현 — 3단계 동기화 아키텍처

• 1단계 — 실시간 동기화 (API 레벨): 데이터 변경 요청 시 Spring Webflux 비동기 처리로 MongoDB에 우선 즉시 반영
• 2단계 — 실패 복구 (Kafka): MongoDB 반영 실패 시 동기화 대상을 Kafka 토픽에 발행 → 별도 Sync Consumer가 구독하여 안전하게 재처리 (메시지 키 기반 파티셔닝으로 순서 보장)
• 3단계 — 최종 정합성 (Batch): RDB 변경 히스토리 테이블 기준으로 주기적 비교 후 불일치 데이터 자동 보정하는 Spring Batch 기반 동기화 엔진 개발

프로젝트 개요: 랭킹 시스템 개선 과정에서 발생한 Kafka 파티션 편중 및 Redis 대량 처리 성능 저하 이슈 원인 분석, 해결

핵심 성과

• Redis 대량 처리 속도 4배 향상 (100만 건 기준 240초 → 60초)
• Kafka 메시지 분배 불균형 해소 → 안정적이고 예측 가능한 처리 성능 확보

이슈 1 — Kafka StickyPartitioner 버그로 인한 파티션 편중

• 현상: 특정 파티션에만 메시지가 집중, 나머지 파티션은 거의 비어 있는 비정상 분배
• 원인 분석: Kafka Client 3.3 미만의 파티션 편중 버그와 RoundRobinPartitioner 이중 호출 문제 확인
• 해결: Kafka Client 3.3 이상으로 업그레이드, 버그가 수정된 DefaultPartitioner 사용으로 균등 분배 복원

이슈 2 — RedisTemplate 개별 TCP 연결로 인한 대량 처리 성능 저하

• 현상: 100만 건 Redis SET 배치 처리 시간이 240초(4분) 소요 — 예상 대비 4배 초과
• 원인 분석: Datadog으로 Redis 연결 수를 모니터링하던 중 배치 실행 시 연결 수 폭발적 증가 확인. RedisTemplate 기본 설정이 명령어마다 새로운 TCP 연결을 수립, 해제하는 구조임을 파악
• 해결: Lettuce 네이티브 API로 전환, 커넥션 풀링 + 파이프라이닝(내부 커맨드 큐잉) 활용으로 I/O 오버헤드 제거 → 처리 시간 240초 → 60초(75% 단축)

프로젝트 개요: 이미지 광고 중심의 레거시 .NET 광고 시스템에 외부 써드파티 VOD 솔루션 연동으로 신규 동영상 광고 상품 출시

핵심 성과: 신규 동영상 광고 상품 런칭으로 추가 광고 매출 기여 / 레거시 시스템 안정성 영향 없이 기능 추가 성공

문제 상황

• 이미지 광고만 고려해 설계된 레거시 .NET 광고 시스템에 동영상 광고 기능 추가 필요
• 레거시 코드 변경이 연쇄 장애로 이어질 위험 — 영향 범위 최소화가 핵심 제약
• 외부 써드파티 VOD 솔루션과의 실시간 메타데이터 동기화 필요

주요 고민 포인트

• 웹훅 선택 이유: 레거시 내부를 직접 건드리지 않고, 외부 솔루션의 처리 완료 이벤트를 웹훅으로 수신해 메타데이터를 단방향 동기화하는 방식 채택 — 레거시 침습 최소화가 핵심 제약이었기 때문
• 외부 연동 안정화 고민: 외부 시스템은 실패 가능성이 있으므로 재시도 로직과 함께, 광고 조회 시 외부 실제 처리 상태를 확인해 내부 상태를 최신화하는 이중 안전장치 설계

기술적 접근 및 구현

• 웹훅 기반 동기화: 외부 솔루션 처리 완료 이벤트를 웹훅으로 수신, 메타데이터 단방향 동기화
• 외부 연동 안정화: 연동 실패 시 재시도 로직 + 광고 조회 시 외부 실제 상태 확인으로 내부 상태 최신화 (상태 불일치 방지)
• 레거시 영향 최소화: 동영상 타입 필드 추가, 파일 처리 로직, 후속 API 서버 확장을 최소 변경으로 수행 후 통합 테스트 배포

프로젝트 개요: Loomex 미디어 유통 관리 솔루션의 .NET 모놀리식 → Node.js MSA 전환 과정에서 서비스 간 결합도 해소를 위해 이벤트 기반 아키텍처 설계·도입

핵심 성과: 서비스 간 동기 의존성 제거 및 유연한 확장 구조 확보 / 비동기 서버리스 처리 도입으로 인프라 비용 효율화

문제 상황

• 강하게 결합된 모놀리식에서 서비스 간 동기 호출 → 결합도 증가, 장애 전파
• 미디어 트랜스코딩 등 장시간 실행 작업을 API 동기 처리하던 구조적 한계

주요 고민 포인트

• Command/Event 분리 기준: 단일 처리자가 필요한 작업은 SQS, 여러 서비스가 반응해야 하는 상태 변경은 EventBridge로 분리
• 메시지 처리 안정성 고민: At-Least-Once 특성으로 중복 메시지가 올 수 있으므로 Lambda 처리 로직에 멱등성 키(메시지 ID) 기반 중복 방지 필수 설계. 실패 메시지는 DLQ로 보존해 분석·재처리 지원

기술적 접근 및 구현

• AWS SQS (Command 패턴): VOD 트랜스코딩 요청 등 단일 처리자가 필요한 작업에 사용, Lambda가 큐에서 pull하여 처리
• AWS EventBridge (Event 패턴): 인코딩 완료, 채널 상태 변경 등 여러 서비스가 독립 구독해야 할 이벤트에 사용 — Pub/Sub으로 결합 제거
• 메시지 처리 안정성: DLQ 구성으로 실패 메시지 보존·재처리 / 멱등성 키 적용으로 중복 처리 방지
• 리소스 자동 정리: Lambda + EventBridge 스케줄러로 S3 스트림 청크·썸네일 자동 삭제 (DB 기반 리텐션 정책)
• CloudWatch 모니터링: SQS 큐 깊이, Lambda 오류율 등 핵심 지표 알람 설정

프로젝트 개요: 라이브 스트리밍 플랫폼의 소셜 미디어 동시 송출 기능에서, 고객의 수동 설정 6단계를 1회 인증으로 완전 자동화

핵심 성과: 스트림 키 수동 입력 등 6단계 설정 프로세스 → 1회 인증으로 자동화 / 설정 오류로 인한 CS 대폭 감소 / YouTube, Facebook 동시 송출 완전 자동화 달성

문제 상황

• YouTube, Facebook 동시 송출을 위해 고객이 직접 각 플랫폼에 접속하여 스트림 키 발급 등 6단계 수동 설정 필요
  • 소셜 플랫폼 접속 → 로그인 → 방송하기 → 스트림 키, 서버 주소 발급 → 자사 솔루션에 입력 → 송출 시작
• 기술에 익숙하지 않은 고객이 스트림 키를 직접 입력하면서 오타, 설정 오류로 인한 CS 빈번히 발생
• 플랫폼마다 다른 API 스펙, 인증 방식, 설정 절차를 통합 관리해야 하는 복잡성

기술적 접근 및 구현

• OAuth 2.0 인증 플로우 구현: 플랫폼별 OAuth 2.0 인증 흐름 표준화 → 토큰 저장, 자동 갱신, 재인증 부담 제거
• 플랫폼별 API 모듈 추상화: YouTube, Facebook API 클라이언트를 각각 구현하고 라이브 생성, 스트림 정보 조회 등의 기능을 내부 표준 인터페이스로 추상화 → 신규 플랫폼 추가 용이
• 자동화 워크플로우 구현: 최초 인증 완료 후, 저장된 토큰으로 순차 API 호출 (라이브 생성 → 스트림 정보 획득 → Catenoid 스트리밍 엔진 자동 설정). 각 단계별 성공, 실패 처리 및 롤백
• 보안: 사용자 토큰 정보 DB 암호화 저장

프로젝트 개요: 수 GB 크기의 미디어 파일 업로드 시 발생하던 메모리 부족·타임아웃 문제를 청크 분할 업로드와 이어받기 기능으로 해결

핵심 성과: 대용량 파일 업로드 타임아웃·메모리 부족 문제 완전 해소 / 파일에 문제가 없는 한 업로드 성공률 사실상 100% 확보 / 네트워크 단절 시 중단 지점부터 이어받기 지원

문제 상황

• 수 GB 단일 HTTP 업로드 → 브라우저 메모리 부족, 서버 메모리 초과, 네트워크 타임아웃 빈번 발생
• 업로드 실패 시 처음부터 재시도해야 하는 사용자 불편

주요 고민 포인트

• 이어받기의 정확성 문제: 단순히 마지막 성공 청크 인덱스부터 재전송하면 안 됨 — 네트워크 불안정 상황에서 마지막 청크가 비정상 종료됐을 가능성이 있으므로, 마지막 성공 청크도 재전송하는 방어 로직을 의도적으로 설계
• 서버 측 재조합 신뢰성: 모든 청크를 임시 디렉토리(/tmp/{fileId}/{chunkIndex})에 인덱스 기반으로 저장 → 전체 수신 확인 후 순서대로 병합 → 임시 파일 삭제. 순서 보장과 원자적 완료 처리가 핵심

기술적 접근 및 구현

• 클라이언트 분할·전송: 파일을 고정 크기 청크로 분할, 파일 ID·총 청크 수·청크 인덱스 메타데이터 포함하여 FormData로 전송 (병렬 전송 지원)
• 서버 수신·저장·재조합: 임시 디렉토리에 청크 인덱스 기반 저장 → 전체 수신 완료 시 순서대로 병합 → 임시 파일 삭제
• 이어받기: 업로드 시작 전 서버에 기존 청크 목록 조회 → 마지막 성공 청크부터 재전송 (마지막 청크 비정상 종료 가능성 고려한 방어 로직 포함)

프로젝트 개요: 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 광고 크리에이티브 템플릿 처리 서버, 광고주, 매체사 정산 어드민 개발