게임듀오
DEV팀 Platform Part Leader 2026.04 — 현재
DEV팀 Server Developer 2025.01 — 2026.03
2025.01 — 현재
모바일 게임 개발 및 퍼블리싱 회사. 12개 라이브 서비스 공통 백엔드 플랫폼 설계, 데이터 파이프라인 구축, 공통 패키지 체계 운영
주요 성과
DEV팀 Platform Part Leader
- Platform Part 신설로 작업 추적·점수 측정 기준 부재 — 7단계 워크플로우(BACKLOG→SIZE REVIEW→DONE), 4가지 작업 유형별 처리 방식, 상태 전환 검증 로직 및 티켓 템플릿 라이브러리 정립, 파트 신설 직후 즉시 가동 가능한 운영 체계 확립 — 작업 유형별 처리 기준·의사결정 체계 동시 수립
- Claude Code 활용으로 개발 소요 시간이 단축되었으나 기존 점수 기준이 AI 활용도 미반영 — 범위·복잡도·불확실성·협업·검증 5기준 사이즈 체계 + Claude Code 영역별 시간 차감 기준(테스트 ~80%, 패턴 복제 ~70%) 수립, 팀 합의 기반 AI 시간 차감 기준 수립으로 Claude Code 도입 전·후 공정한 성과 측정 체계 확립
- Claude Code 등 AI 에이전트 활용도 팀원별 격차 + 개인이 발견한 컨텍스트·노하우가 팀 전체에 전파되지 않아 동일한 시행착오 반복 — 개인 노하우 문서화 기각 후 shared-config-as-code 채택 (AI 런타임 직결로 자동 적용) — 팀 원칙·코딩 표준·도메인 지식·전문 에이전트·자동화 훅을 단일 git repo로 통합한 GameDuo Platform Harness 설계, git pull만으로 팀원 전원이 동일한 AI 세션 컨텍스트로 시작 — 개인 지식의 팀 자산화 및 AI 활용 격차 해소 (구축 약 2주 만에 397개 도메인 지식 누적)
DEV팀 Server Developer
- 마케팅 데이터 조회 비용 급증(전체 스캔 과금 구조) — 파티셔닝 튜닝 분석 후 Write IOPS 증가 문제로 기각, gRPC 기반 분산 읽기(Storage Read API) 전환, 비용 82% 절감(TB당 $6.25→$1.1)
- 배치 처리의 수집 기간 한계(60일) — 배치 일괄 처리 대비 EDA 기반 온디맨드 처리로 전환 — 피크 부하 분산 및 처리량 확장, 수집 범위 6배 확장(60일→360일), 처리 시간 2시간→5분 단축
- 7개 프로젝트 간 코드 중복과 컨벤션 불일치 — 수동 코드 동기화 대신 공통 NestJS 패키지 체계 도입 (유틸 10모듈 + 게임서버 Kit 자동 배포), 업그레이드 자동화로 배포 시간 3시간→15분 단축
- 3개 광고 플랫폼 데이터 분산에 따른 마케팅 조회 지연(18초) — 100개 컬럼 전체 스캔 회피를 위해 읽기 경로 정규화 + 인덱스 튜닝, 조회 성능 97% 개선(18초→0.5초)
- 게임 확률 공시 의무화 규제 리스크 — DynamicModule 기반 확률 패키지를 다중 게임에 통합 + CDK 기반 감사 로그 파이프라인, 통합 테스트 커버리지 94%+ 확보(12 suites, 115 tests)
프로젝트
마케팅 플랫폼 Audit Log 시스템
2025.01 ~ 2025.04게임 운영 중 데이터 변경 이력 추적 불가로 인한 밸런스 문제 대응 지연 해결
- 6개 게임 간 데이터 변경 이력 추적 불가 — UUID 기반 크로스 환경/프로젝트 엔티티 추적 Git-like 버전 관리 시스템 정립, 6개 게임 간 데이터 일관성 보장
- 엔티티 변경 기록의 수동 관리 부담 — Auditable 데코레이터 + TypeORM Subscriber 패턴으로 이벤트 소싱 기반 변경 자동 기록 파이프라인 설계, 엔티티 변경 이력 자동 추적 체계 구축
- 다중 환경 간 엔티티 충돌 감지 및 병합 부재 — 상위/하위 엔티티 충돌 감지와 유니크 제약조건을 고려한 3-Way Merge 엔진 구현, 6개 게임 다중 환경 간 버전 병합 자동화
- 버전 간 변경 사항 비교 비효율 — Base Audit 유무에 따른 증분 비교와 스냅샷 비교의 이중 전략 Diff 엔진 설계, 비용 효율적 버전 비교 체계 확립
- PK 의존 엔티티 추적의 환경 간 불일치 — 공유 식별자 기반 크로스 환경 엔티티 추적 체계 설계로 PK 의존 탈피, 마이그레이션/비교/병합 시 정확한 엔티티 추적 보장
기술 선택 이유
TypeORM EntitySubscriberInterface 동작과 제약을 별도 분석 후 채택. Auditable 데코레이터 + Subscriber 조합으로 엔티티 변경을 표준화된 Audit 파이프라인으로 자동 수집하는 AOP 방식 설계.
마케팅 통합 플랫폼
2025.02 ~ 현재마케팅 전용 DB 분리 기반 위에 Google Ads/Meta/TikTok 캠페인·소재·지표를 단일 시스템에서 관리하는 통합 마케팅 플랫폼
- 3개 광고 플랫폼 캠페인 관리 분산 — Google Ads/Meta/TikTok 캠페인 생성·배포·수정과 리텐션 지표 관리를 단일 플랫폼에서 처리하는 API 개발, 통합 캠페인 자동화 체계 마련
- Meta 에셋 동기화 성능 병목 — ORM 단건 저장을 벌크 처리로 전환, Image 동기화 72% 단축(25.7s→7.1s), DB 트랜잭션 95% 단축(10~16s→0.3~0.5s)
- 소재 처리 Lambda 비용 부담 — Graviton2 ARM64 아키텍처 전환, 소재 처리 Lambda 비용 20% 절감
- 마케팅 데이터 조회 비용 급증 — BigQuery Storage Read API 도입으로 gRPC 스트리밍 기반 고성능 데이터 읽기 전환, BigQuery 비용 82% 절감(TB당 $6.25→$1.1)
- 100+ 컬럼 테이블 조회 성능 저하(18초) — 테이블 3개(메인/시계열/예측) 정규화, 인덱스+커서 페이지네이션 적용, 조회 성능 97% 개선(18s→0.5s)
- 마케팅 RCP 데이터 엑셀 전용 + BigQuery 통합 테이블이 복수 소스 조합 구조라 콘솔 통합 조회 불가 — BigQuery를 단일 소스 테이블로 전환 + Criteria-Result 패턴 field-metadata API 신설, FE 멀티셀렉트 필터·TOTAL 집계, 콘솔 내 RCP 통합 조회 내장, 하드코딩 currency/소수점 표시를 BE metadata 기반으로 대체
기술 선택 이유
BigQuery Storage Read API로 비용 82% 절감. GCP Pub/Sub → AWS Lambda/SQS 하이브리드 파이프라인으로 이벤트 기반 처리 전환, Outbox 패턴으로 API 비차단 비동기 발행 설계.
AWS Lambda 마이그레이션 & Event-Driven Architecture
2025.06 ~ 2025.08마케팅 지표 60일 → 360일 확장에 따른 배치 작업 한계 해결 및 배치 처리 서버리스 전환
- 전체 서버리스 전환 시 운영 안정성 리스크 — API 서버(EC2)는 유지하고 배치/Job 처리만 Lambda로 분리하는 하이브리드 아키텍처 설계, 워크로드별 최적 리소스 활용 달성
- 배치 처리의 수집 기간 한계(60일) 및 처리 시간 2시간 — SQS+Lambda+EventBridge 기반 Event-Driven 비동기 처리 전환, 처리 시간 2h→5m 단축, 수집 범위 6배 확장(60일→360일)
- 비동기 전환 시 데이터 정합성 보장 필요 — 예약·지연 발행 기반 트랜잭션 아웃박스 패턴 적용, 이벤트 기반 아키텍처에서 데이터 정합성 보장
- Lambda 스로틀링, CloudWatch 비용 증가, 빌드 OOM 발생 — Batch Size 벌크 처리, CloudWatch 로그 경량화, 빌드 OOM 조치, Lambda 운영 안정화 및 비용 절감
- Lambda 대량 실행 시 DB 커넥션 고갈 — RDS Proxy 풀링 기반 커넥션 관리 도입, DB 커넥션 고갈 문제 해결
기술 선택 이유
배치·이벤트성 작업이 서버 본체에 묶여 독립 배포 불가한 제약 해소를 위해 Lambda 선택. SQS로 비동기화하여 트래픽 변동 시 처리 지연과 확장성 한계 해결.
Cloud Data 동기화 시스템
2025.08 ~ 현재환경 간 동적 게임 데이터 불일치 문제를 해결하기 위한 S3 기반 동기화 및 DDL 자동 관리 시스템
- 환경 간 동적 게임 데이터 불일치 — S3 기반 개발/스테이징/프로덕션 환경 간 동기화 시스템 구축, 환경 간 데이터 일관성 보장
- 환경 간 스키마 불일치 수동 관리 부담 — PK 컬럼 타입 동적 결정, 컬럼 타입 불일치 감지·MODIFY, 인덱스 자동 생성·RENAME DDL 자동 관리 엔진 구현, 스키마 동기화 자동화
- Cloud Data 적재 및 S3 업로드 성능 병목 — 병목 구간 분석 및 저장/업로드 최적화, 대용량 처리 지연 해소
- 동기화 작업 불안정(타임아웃, 스케줄링 충돌) — job 분리, 스케줄링 방식 전환, timeout 조정, non-blocking 처리 적용, 운영 안정성 개선
- CloudData 운영 장애 4건(캐시, 메타데이터, 키, 옵션 누락) — Redis 캐시 무효화, DDL SKIP 메타데이터, 복사 키 삭제, excludeCloudData 전달 누락 수정, CloudData 안정화
- 시트 마이그레이션 시 excludeCloudData 옵션 미전파로 전체 삭제 리스크 — POST 경로 4곳에 excludeCloudData 옵션 전달 보강, Cloud Data 전체 삭제 리스크 차단
기술 선택 이유
S3 Lifecycle 정책(30일 Glacier IR, 90일 만료)으로 비용 최적화. 이벤트성 실행에서 스케줄링 방식으로 전환하여 동기화 누락 위험 감소.
사내 공통 라이브러리 체계
2025.07 ~ 현재NestJS 유틸 10개 모듈 + 게임서버 Kit 2개 패키지 개발·운영으로 다중 프로젝트 코드 일관성 달성
- 서비스 간 공통 코드 중복 및 유지보수 비용 증가 — core, repository, cache, lock, slack, crypto, smb, hash, type, iac 10개 모듈 라이브러리 체계 설계, 7개 프로젝트 공통 코드 일원화 및 의존성 관리 표준화
- Repository 계층 코드 비대화(2000+줄) 및 타입 안전성 부족 — Bulk·Audit Log·TypeORM 타입 좁히기 지원, 함수 오버로딩+TypeScript 제네릭 적용, SRP 분리, Repository 모듈 코드 품질 및 재사용성 향상
- 멀티 인스턴스 환경의 동시성 제어 부재 — ElastiCache (Redis) 기반 분산 락 데코레이터 설계, 멀티 인스턴스 환경 동시성 제어 체계 구축
- 7개 프로젝트 패키지 업그레이드 수작업(3시간) — workflow_dispatch+matrix 병렬 실행, 변경 패키지 CI 테스트 자동화(GitHub Packages), 업그레이드 배포 시간 3h→15m 단축
- CI 테스트 실행 시간 과다(15m47s) — ts-jest isolatedModules+Entity 타입 명시 적용, CI 61% 단축(15m47s→6m06s), 81 suites 978 tests 통과
- 게임서버 공통 코드가 5개 브랜치로 분산 + 한 게임은 sheet 모듈 17개가 외부 패키지와 2년+ diverged — 시트+5개 서브모듈을 독립 패키지로 추출 후, 한 게임에 610 파일/310+ import 일괄 마이그레이션 + config 주입·인터페이스 누락 등 9건 hotfix, 패키지 체계 확립 및 첫 게임 적용 — 9건 hotfix 무사고, 이후 sheet 업데이트는 npm 버전 bump 1건으로 자동 통합(수동 마이그레이션 610 파일→0)
기술 선택 이유
ElastiCache(Redis) 기반 분산 락을 AOP 데코레이터로 구현하여 비즈니스 로직에서 락 코드 분리. Jest 30 VM 격리 대응 시 5가지 옵션 검토 후 poolSize=2 채택.
게임 인앱 다국어 번역 시스템
2026.02 ~ 현재게임 내 알림/공지 다국어 번역 체계의 도메인 모델 재설계 — AI 번역과 라이브러리 기반 변환을 3단계 파이프라인으로 분리
- 간체는 AI 지원 언어가 아님에도 AI 번역 설정 도메인 내부 옵션으로 모델링되어 도메인 의미 왜곡, 설정 저장·조회가 번체 AI 번역 상태에 의존하여 breaking change 없이 독립 on/off 불가 — 파생 변환 모듈을 AI 번역 모듈에서 독립 분리(9개 use case + 전용 entity/repository/scheduler), effective 설정 글로벌 상속 패턴 적용, 도메인 경계 명확화 및 파생 변환 규칙 독립 on/off 가능
- 설정 decoupling 과정에서 breaking API change 필요 — FE/BE/Gateway 동시 배포 전략과 역할 권한 마이그레이션으로 무중단 전환, breaking API change 장애 없이 전환 완료, effective 설정 DB 쿼리 50% 감소(4→2)
- detect 크론의 버전 우선순위 부재로 최신 버전 변환 지연 + 30초 주기 응답 지연 — detect SQL에 버전 ID 기반 우선순위 정렬 추가, 처리 주기 30초→10초, 배치 limit 100→200 최적화, 최신 버전 변환 지연 해소, 진행률 UI와 총 건수 캐시로 사용자 가시성 확보
- detect 스케줄러가 159개 버전을 한 번에 스캔(3.27M rows full scan) → RDS IOPS 포화로 사용자 로그인 60초 장애 — AI detect 모듈의 per-version loop 이식 + 분산락 timeout/recovery + NOT EXISTS full scan을 인덱스 staged lookup으로 대체, 쿼리 260× 단축(전체스캔→39ms 인덱스 lookup), driving filesort 제거, 사용자 로그인 latency 정상 복원
기술 선택 이유
AI 번역 도메인과 라이브러리 기반 파생 변환의 책임 경계를 코드 구조에 실체화. Detection→Processing(AI)→Conversion(라이브러리) 3단계 파이프라인을 독립 모듈로 분리하고, 2단계 race guard와 pessimistic write lock으로 동시 요청 정합성 확보
확률 계산 및 감사 로그 분석 파이프라인
2026.02 ~ 현재게임 확률 검증 체계 부재에 따른 규제 리스크 해소를 위한 확률 계산 패키지와 CDK 기반 감사 로그 분석 인프라 개발
- 12개 게임 확률 계산 로직 분산 및 규제 대응 부재 — NestJS DynamicModule 기반 5개 확률 함수+Kinesis 로깅을 확률 계산 공통 패키지로 분리, 12개 게임 확률 패키지 통합
- 확률 감사 로그 분석 인프라 부재 — Kinesis→Firehose(Dynamic Partitioning+Parquet)→S3→Glue→Athena E2E 파이프라인 CDK 코드화, 확률 감사 로그 분석 인프라 조성
- 모킹 기반 테스트의 회귀 신뢰도 부족 — 모킹 삭제, LocalStack+Testcontainers 기반 통합 테스트 교체, 회귀 신뢰도 강화, 12 suites 115 tests 커버리지 94%+ 확보
기술 선택 이유
Kinesis → Firehose(Dynamic Partitioning + Parquet) → S3 → Glue → Athena 파이프라인을 CDK로 코드화. Parquet 컬럼형 포맷으로 Athena SQL 분석 비용 최적화, LocalStack Testcontainers로 모킹 기반 테스트 제거.