경력기술서 — 길현준

여러 게임이 공유하도록 멀티테넌트 실시간 채팅 서버를 설계하고, 6,000 동시접속·18,000 RPS 목표를 산정해 dev 부하 시험 20,002 동시접속 900초 유지까지 검증

• •여러 게임이 공유하는 채팅 인프라의 용량 산정 기준이 없어 서버 사이징·SLO 목표를 정할 수 없음 — 추측 기반 산정 대신 상용 게임 채팅 솔루션의 공식 rate limit·PCU 기준을 채택해 멀티테넌트 통합 서버 1대 frame 용량 산정식 수립, 6,000 동시접속·18,000 RPS·버스트 90,000 RPS 목표를 분기 OKR에 반영하고 dev 부하 시험에서 20,002 동시접속 900초 유지
• •Redis Streams 기반 WAL이 6K msg/s 부하에서 싱글스레드 쓰기 병목(EngineCPU 99.9%, ack p95 767ms) — WAL 스트림을 4-shard 클러스터로 분산하고 엔트리를 native field로 compact(Lua 직렬화 제거) — 싱글스레드 Redis는 쓰기를 순차 처리해 수직 확장으로 병목 해소 불가, 수직 확장 대신 샤딩 채택, ack p95 767ms→6.6ms(약 116배 단축), WAL 적체 80,000→2,838건 해소, 수용률 99.99% 달성
• •다중 테넌트 동시 부하에서 스코프 키 누락으로 메시지가 100% reject됨 — 5개 테넌트 동시 부하 측정 환경을 구성하고 hot-path 로그 제거·메시지 스코프 키 도입으로 reject 제거, 5분간 29.9만 메시지 sustained에서 ack p95 42ms(목표 <100ms)·에러율 0.04%(목표 <0.1%) 달성
• •outbox 후속 처리 Lambda가 Throttle 0인데도 동시 실행 2(예약 100의 2%)·IteratorAge 11분에 고착 — batching 조정 대신 하루치 쓰기를 한 파티션에 몰던 tenant#날짜 파티션 키를 원인으로 추적해 0~9 shard suffix로 10개 파티션에 분산, sandbox 부하에서 IteratorAge 658s→35s(-95%), Lambda 동시 실행 2→8
• •hot-channel fanout 전환 후 병목이 Redis 서버 Lua, gateway event-loop, 단일 command queue, topology 중 어디인지 분리되지 않음 — 변경 전 attribution 계측을 먼저 추가하고 Valkey serverless SSUBSCRIBE, 채널별 구독, logicalChannelId sticky connection pool을 단계적으로 검증, sandbox 검증 통과, 연결 풀 크기 4의 단독 측정에서 명령 대기열 5,940→716 감소·878,205 메시지 처리 중 유실 0건 확인
• •오프라인 DM, 미확인수, 참여방 목록, 그룹 fanout을 지원할 유저 단위 영속 상태가 없어 채팅 기능 확장 시 서버·게임 도메인 책임이 섞일 위험 — per-user room index를 기준 모델로 수렴시키고, 채팅 서버는 mechanics/characterId까지만 책임지며 프로필 보강과 그룹 도메인 액션은 게임 서버가 소유하도록 경계 정리, DM·미확인수·참여방 목록·그룹 fanout 서버 기능을 하나의 인덱스 모델로 정리하고 Unity 연동 전 서버/sandbox QA 완료
• •성능 개선 후 gateway task OOM kill이 반복되었으나 outbound queue 누적, 관측 스택, heap cap 중 원인이 불명확 — egress budget 가설을 선등록해 기각하고 heap snapshot·진단 로그·AB 측정으로 retained heap 누적과 heap cap 정합성 문제를 분리, 관측 스택 수정 후 검증에서 OOM 0건 관측, 원복 대상 인프라 변경 계획의 구성 차이 0건 확인

마케팅 전용 DB 분리 기반 위에 Google Ads/Meta/TikTok 캠페인·소재·지표를 단일 시스템에서 관리하는 통합 마케팅 플랫폼

• •마케팅 지표 아카이브 대용량 백필 중 Lambda 실행 63초·RDS CPU 99.8% 포화로 처리 ETA 15시간 — 근본 원인을 N+1 쿼리와 비SARGable 날짜 조건(DATE() 인덱스 미스)으로 규명 후 제거 — 행별 조회가 RDS를 포화시켜, 행별 조회 대신 30일치를 단일 배치 쿼리로 모아 in-memory에서 최신 버전만 dedup, 처리량 26배 개선(9.3→247건/분), Lambda 실행 63s→1.36s
• •MKT Sheet의 BigQuery 조회 — Storage Read API로 전환, 적용 완료
• •100+ 컬럼 테이블 조회 성능 저하 — 테이블 3개(메인/시계열/예측) 정규화, 인덱스+커서 페이지네이션 적용, 조회 성능 97% 개선(18초→0.5초)
• •Meta 에셋 동기화 성능 병목 — 행별 ORM 단건 저장이 트랜잭션 오버헤드를 유발해, 단건 저장 대신 벌크 INSERT·일괄 삭제로 전환, Image 동기화 72% 단축(25.7s→7.1s), DB 트랜잭션 95% 단축(10~16s→0.3~0.5s)
• •TikTok 배포가 외부 API 부분 성공 후 내부 저장 전에 실패하면 재시도 시 고아 campaign/adgroup/ad가 누적되거나 배포 가드에 막힘 — Smart+ V2는 campaign/adgroup/ad 레벨별 get-or-create와 즉시 영속화, v1은 campaign-level 재사용, regular는 ad-level 플래그로 경로별 멱등성 통일, 부분 실패 재시도 경로 단위 테스트 31건 통과, 기존 고아 campaign 2개·adgroup 2개 재발 방지 정책 적용
• •2,637만 행/27GB audit log 테이블에서 parent_id 조건 인덱스 부재로 화면 조회가 대량 풀스캔과 장시간 IO 포화를 유발 — 엔티티 인덱스 선언으로 재-drift를 막고, 저부하 윈도에 online DDL을 선적용한 뒤 중복 인덱스 no-op 마이그레이션과 실제 DDL 통합 테스트 보강, 최장 36분간 지속되던 풀스캔 쿼리를 제거하고 EXPLAIN 예상 스캔 3행으로 축소해 audit log 조회 장애 해소
• •Lambda handler 빌드 대기와 격리된 테스트 스위트로 마케팅 플랫폼의 CI 피드백 지연·회귀 검증 공백 발생 — handler 빌드 샤딩과 기대 산출물 누락 검증을 적용하고, 격리 스위트를 복구해 FULL 8-shard CI로 검증, 워크플로 수동 실행 비교 실험에서 1→6-shard 빌드 wall time 1,041→451초(58개 handler 누락 0); 총 빌드 작업 시간은 1,006→1,801초 증가. 별도로 격리 83개 스위트 전부 복구 후 FULL CI 통과
• •Meta 광고와 로컬 소재의 연결 누락으로 같은 UI 필터에서 소재 미연결 광고 2,235건 조회 — Meta 계정 15개·캠페인 292개를 순회해 소재 연결을 백필하고 같은 UI 조건으로 전후 비교, 소재 미연결 광고 2,235→430건, 1,805건(80.8%) 감소; 잔여 430건은 현재 Meta 응답에 로컬 광고 ID와 일치하는 소재가 없는 건

NestJS 유틸 10개 모듈 + 게임서버 Kit 2개 패키지 개발·운영으로 다중 프로젝트 코드 일관성 달성

• •CI TEST job 평균 실행 시간 15m47s로 피드백 지연 — @swc/jest는 decorator 메타데이터 호환성이 낮아 @swc/jest 대신 tsc 네이티브 transpiler 기반 ts-jest isolatedModules + Entity 타입 명시 채택, CI TEST job 평균 실행 시간 61% 단축(15m47s→6m06s), 81 suites 978 tests 통과
• •게임서버 공통 코드가 5개 브랜치로 분산 + 한 게임은 게임 데이터 정의 모듈 17개가 외부 패키지와 2년+ diverged — 게임 데이터 정의 모듈+5개 서브모듈을 독립 패키지로 추출 후, 한 게임에 610 파일/310+ import 일괄 마이그레이션, 이후 하드코딩 전수 감사·config 주입 전환·회귀 guard 추가, 데이터 모듈 업데이트를 npm 버전 bump 1건으로 통합(수동 마이그레이션 610 파일→0), 이관 회귀로 난 라이브 500 오류는 보고 82분 만에 hotfix 배포
• •앱마다 static-data LRU 캐시를 따로 주입해 live 게임 서버 부팅 시 데이터 워밍에 수 분 소요 — static-data 저장소를 공통 키트 소유로 옮겨 앱의 LRU 주입을 제거하고 negative caching·preloadAll 추가, live 게임 서버 부팅 워밍 138.1~199.5초→25.8~37.8초, 앱 워머를 preloadAll로 전환한 뒤 0.82~1.08초
• •7개 프로젝트 패키지 업그레이드 수작업(3시간) — workflow_dispatch+matrix 병렬 실행, 변경 패키지 CI 테스트 자동화(GitHub Packages), 업그레이드 배포 시간 3h→15m 단축
• •서비스 간 공통 코드 중복 및 유지보수 비용 증가 — core, repository, cache, lock, slack, crypto, smb, hash, type, iac 10개 모듈 라이브러리 체계 설계, 7개 프로젝트 공통 코드 일원화 및 의존성 관리 표준화
• •Repository 계층 코드 비대화(2000+줄) 및 타입 안전성 부족 — 동시 쓰기에서 중복 키 충돌을 일으킨 read-then-write를 atomic upsert로 교체하고 감사 로그를 자동 분기. 오버로딩·제네릭으로 타입을 좁히고 SRP에 따라 Repository를 목적별 모듈로 분리, 2000+줄 코드 정리 후 공용 Repository 계층 도입으로 CRUD 중복 제거 및 데이터 접근 표준화
• •게임 서버 공통 캐시 로직이 프로젝트마다 중복 구현되어 정합성·유지보수 부담 — 순수 분산 캐시의 네트워크 왕복과 순수 로컬 캐시의 인스턴스 간 불일치를 줄이려 로컬 LRU·분산 캐시를 결합한 Hybrid AOP 라이브러리 구현. 데코레이터로 적용하고 SRP에 따라 태그 인덱스·single-flight를 분리, 캐시 라이브러리 v0.5.0 릴리스 — 28 스위트 262 테스트 통과

게임 운영 고객 상담(CS)용 채팅 서버를 공유 배포 환경에서 ECS로 완전 분리하고, 인증·보안·부하 한계를 검증

• •고객 상담(CS) 채팅이 공유 배포 환경에 묶여 자원 경합·배포 결합 발생 — ECS Fargate로 서비스를 완전 분리하고 Terraform IaC(S3 state)·GitHub Actions OIDC·관측 sidecar로 배포 자동화 — 게임별 분산 토큰 검증 대신 중앙집중 game token 검증 경로 채택, 독립 서비스 cutover 및 Terraform 모듈화, Grafana 11-panel 대시보드·8 알림 구성
• •신규 CS 채팅 도메인이 계층 결합·임의 토큰 수명으로 보안·유지보수 리스크 — Clean Architecture 4계층으로 책임 분리하고 OAuth2 access(5분)/refresh(1시간) 토큰과 ETag/304 폴링을 도입 — 매 폴링마다 전량 응답하는 대신 변경분만 전송, 12 스위트 39 테스트 통과, IaC plan +10 리소스 무사고 적용
• •1.0 vCPU 한계·cold start 40~90초·이미지 비대로 스파이크 트래픽 대응 불가 — task 자원·ALB RPS 오토스케일 정책을 재설계하고 ARM64 native 빌드 + Dockerfile 경량화·마이그레이션 분리로 cold start 단축, 이미지 381→254MB(-127MB)·빌드 5→2분·cold start 30% 단축, k6 500 VU 스파이크 0% 실패
• •프로젝트 간 데이터 격리·요청 rate 제한·첨부 접근 제어 부재 — cross-project 격리(삼중 검증 헬퍼)와 Redis 저장소 기반 rate limit(인증 5/분·refresh 10/분·메시지 30/분), 첨부 FK 정합 마이그레이션을 도입 — 인메모리 throttler는 다중 인스턴스 우회 가능성으로 기각, 보안 통합 머지, 타입 검사 0 에러, cross-org/project 격리 spec 정립
• •CS 채팅방 하나에 여러 문의가 섞여 문의별 건수·처리시간 집계가 어렵고, 버그 문의 동영상 첨부도 지원하지 않음 — 메시지 불변성을 유지하는 답변 링크 테이블, 유저 단위 채팅 리스트, 동영상 업로드 전용 MIME/크기/TTL/일일 제한 경로를 additive API로 설계, 메시지 단위 답변·대상 변경, 유저 단위 리스트, 동영상 문의 열람, 문의 건수·처리시간 집계 기반 구축(20MB·10건/일·15분 TTL)

마케팅 지표 60일 → 360일 확장에 따른 배치 작업 한계 해결 및 배치 처리 서버리스 전환

• •전체 서버리스 이관 시 운영 안정성 리스크 — API 서버(EC2)는 유지하고 배치/Job 처리만 Lambda로 분리하는 하이브리드 아키텍처 설계, API 가용성 무영향 보장, 배치 워크로드만 격리 이관해 운영 리스크 차단
• •배치 처리의 수집 기간 한계(60일) 및 처리 시간 2시간 — SQS+Lambda+EventBridge 기반 Event-Driven 비동기 처리 전환, 처리 시간 2h→5m 단축, 수집 범위 6배 확장(60일→360일)
• •비동기 전환 시 데이터 정합성 보장 필요 — 예약·지연 발행 기반 트랜잭션 아웃박스 패턴 적용, 이벤트 기반 아키텍처에서 데이터 정합성 보장
• •CDK deploy workflow에서 cache disk full 이후 Lambda handler webpack build V8 OOM이 재현되어 배포 속도 저하와 재발 방지 부재가 동시에 발생 — runtime transform 의존을 generate 산출물로 분리하고, 기본 handler batch는 키우되 실패 batch만 8→4→2→1로 adaptive split 재시도하도록 build 경로 개선, Lambda handler build OOM 원인 제거와 CI 재발 방지 게이트 정리, 3개 CI run 통과로 배포 경로 검증
• •Lambda 대량 실행 시 DB 커넥션 고갈 — RDS Proxy 풀링 기반 커넥션 관리 도입, DB 커넥션 고갈 문제 해결

게임 내 알림/공지 다국어 번역 체계의 도메인 모델 재설계 — AI 번역과 라이브러리 기반 변환을 3단계 파이프라인으로 분리

• •간체는 AI 지원 언어가 아님에도 AI 번역 설정 도메인 내부 옵션으로 모델링되어 도메인 의미 왜곡, 설정 저장·조회가 번체 AI 번역 상태에 의존하여 breaking change 없이 독립 on/off 불가 — 파생 변환 모듈을 AI 번역 모듈에서 독립 분리(9개 use case + 전용 entity/repository/scheduler), effective 설정 글로벌 상속 패턴 적용, 9개 use case 분리로 도메인 경계 명확화, 파생 변환 규칙 독립 토글 지원
• •설정 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와 총 건수 캐시로 사용자 가시성 확보
• •sandbox에서 detect 스케줄러가 159개 버전을 한 번에 조회(live 기준 3.27M행 full scan)해 Read IOPS 190~470/s 포화, 일부 사용자 60초 로그인 불가 — AI detect 모듈의 per-version loop 이식 + 분산락 timeout/recovery + NOT EXISTS full scan을 인덱스 staged lookup으로 대체, 버전별 단일 쿼리로 분할(Live EXPLAIN 버전 1개 기준 39ms)하고 페이지네이션·실행당 상한으로 한 실행의 길이를 제한
• •AI 번역 스케줄러가 Vertex AI 429 quota 초과로 막혀 처리되지 못한 요청이 live에 83,796건 누적 — 재시도 경로를 추적해 배치 내 재시도와 복구 재시도가 겹친 실효 9회 시도, 13개 스케줄러 인스턴스의 backoff·jitter 부재를 확인, 원인 2가지(160개 버전×4개 언어 소급 백필, 13개 인스턴스 동시 retry storm) 규명, 멈춘 요청 83,796건 삭제 후 후속 과제 4건 분리

게임 운영 중 데이터 변경 이력 추적 불가로 인한 밸런스 문제 대응 지연 해결

• •6개 게임 간 데이터 변경 이력 추적 불가 — UUID 기반 크로스 환경/프로젝트 엔티티 추적 Git-like 버전 관리 시스템 정립, 6개 게임 간 데이터 일관성 보장
• •엔티티 변경 기록의 수동 관리 부담 — Auditable 데코레이터 + TypeORM Subscriber 패턴으로 이벤트 소싱 기반 변경 자동 기록 파이프라인 설계, 엔티티 변경 이력을 자동 추적하고 모든 게임 환경에서 데이터 변경을 일관되게 기록
• •다중 환경 간 엔티티 충돌 감지 및 병합 부재 — 상위/하위 엔티티 충돌 감지와 유니크 제약조건을 고려한 3-Way Merge 엔진 구현, 6개 게임 다중 환경 간 버전 병합 자동화
• •버전 간 변경 사항 비교 비효율 — Base Audit 유무에 따른 증분 비교와 스냅샷 비교의 이중 전략 Diff 엔진 설계, 증분 및 스냅샷 이중 전략으로 버전 비교 성능 최적화
• •PK 의존 엔티티 추적의 환경 간 불일치 — 공유 식별자 기반 크로스 환경 엔티티 추적 체계 설계로 PK 의존 탈피, 마이그레이션/비교/병합 시 정확한 엔티티 추적 보장

환경 간 동적 게임 데이터 불일치 문제를 해결하기 위한 S3 기반 동기화 및 DDL 자동 관리 시스템

• •환경 간 동적 게임 데이터 불일치 — S3 기반 개발/스테이징/프로덕션 환경 간 동기화 시스템 구축, 환경 간 데이터 일관성 보장
• •환경 간 스키마 불일치 수동 관리 부담 — PK 컬럼 타입 동적 결정, 컬럼 타입 불일치 감지·MODIFY, 인덱스 자동 생성·RENAME DDL 자동 관리 엔진 구현, 데이터베이스 스키마 변경사항 자동 추적 및 동기화
• •Cloud Data 적재 및 S3 업로드 성능 병목 — 병목 구간 분석 및 저장/업로드 최적화, TRUNCATE→DELETE 전환으로 대용량 데이터 처리 시간 77% 단축(57.5초→12.9초)
• •동기화 작업 불안정(타임아웃, 스케줄링 충돌) — job 분리, 스케줄링 방식 전환, timeout 조정, non-blocking 처리 적용, 마이그레이션 및 스키마 최적화로 데이터 계층 안정성 강화
• •데이터 동기화 서비스 운영 장애 4건(캐시 정합·메타데이터·복사 키·데이터 보호 옵션 누락) — Redis 캐시 무효화, DDL SKIP 메타데이터 정리, 복사 키 삭제, 데이터 보호 옵션 전달 누락 수정, 4건 장애 원인 분석·수정으로 데이터 동기화 서비스 안정성 확보
• •데이터 마이그레이션 시 보호 옵션(클라우드 보관 데이터 제외)이 일부 경로에 미전파되어 전체 삭제 리스크 — 누락된 POST 경로 4곳에 보호 옵션 전달 보강, 운영 데이터 전체 삭제 리스크 차단

게임 확률 검증 체계 부재에 따른 규제 리스크 해소를 위한 확률 계산 패키지와 CDK 기반 감사 로그 분석 인프라 개발

• •6개 라이브 게임 환경 (12 브랜치 운영) 확률 계산 로직 분산 및 규제 대응 부재 — NestJS DynamicModule 기반 5개 확률 함수+Kinesis 로깅을 확률 계산 공통 패키지로 분리, 6개 라이브 게임 환경 (12 브랜치 운영) 확률 패키지 통합 (cherry-pick main + 11 branches)
• •확률 감사 로그 분석 인프라 부재 — Kinesis→Firehose(Dynamic Partitioning+Parquet)→S3→Glue→Athena E2E 파이프라인 CDK 코드화, 6개 라이브 게임 환경 (12 브랜치 운영) 프로젝트에 통합하여 확률 공시 감사 로그 파이프라인 구축
• •모킹 기반 테스트의 회귀 신뢰도 부족 — 모킹 삭제, LocalStack+Testcontainers 기반 통합 테스트 교체, 회귀 신뢰도 강화, 12 suites 115 tests 커버리지 94%+ 확보

기여도: 초기 구현체를 패키지 구조로 재설계. P0 버그 수정, 테스트 안정화(94%+ 커버리지), CDK 인프라 구축, 6개 라이브 게임 환경 (12 브랜치 운영) 적용은 단독 수행.

마케팅 지표의 일별 스냅샷 아카이빙(불변성 보장), 4천 행 규모 커스텀 대시보드, 알림 관측성을 구축

• •4천 행 규모 마케팅 메트릭을 단일 대시보드에 표시 시 스크롤 성능 저하·셀 동기화 버그 — BE는 Raw SQL DISTINCT JOIN(ORM hydration 회피)+in-memory 캐시, FE는 가시 행 lazy fetch+200행 단위 청킹(네트워크 왕복과 렌더 지연의 균형점)+pair별 캐싱으로 분리 — 전량 로딩은 응답 크기·렌더 비용으로 기각, 4,458행 중 3,341행 매핑 표시, 응답 cold 573ms/warm 221ms로 안정화
• •동기화 경로가 reference-date cutoff 대신 최신 스냅샷을 사용해 아카이브 불변성 위반(데이터 오염) — cutoff semantics를 준수하도록 usecase·repository를 재설계하고 stale-writer guard를 트랜잭션 처리, 동기화 상태에 tombstone을 도입, live 15,333개 아카이브 재구축(오염 0), 287,020개 archive-date 검증 통과
• •로그 쿼리 스택(Loki) 일시 장애 시 마케팅 알림 16건이 동시 발화해 운영 채널 도배 — 장애 원인을 규명한 뒤 알림 16건을 단일 분석 DB(ClickHouse) 쿼리로 전환하고 대시보드 API로 재작성, 레거시 로그 스택 폐기 정책 수립, 알림 16/16 마이그레이션(25분), 로그 스택 장애 시 알림 도배 재발 방지

Cyan(사내 Node.js 프레임워크) 기반 임상시험 전자 동의서 수집 비효율성과 전자서명 규제 준수 요구사항 해결

• •임상시험 동의서 개별 발송의 비효율 — 임상시험별 참여자 그룹 관리 및 일괄 동의서 배치 발송 시스템 구현, 동의서 발송 프로세스 자동화
• •배치+S3 이벤트 기반 아키텍처의 이벤트 흐름 비가시성 — EDA+아웃박스 패턴으로 변경, 이벤트 흐름 가시화 및 로컬 테스트 환경 정비

기여도: EDA 전환 설계, 플러그인 구조 구현, 대상자 일괄 등록 + Signer 테이블 분리 마이그레이션 수행. BE 2명 체제.

임상시험 전자서명 알림에서 발생하는 데이터베이스 Deadlock으로 인한 치명적 알림 누락 해결

• •운영 DB 교착으로 전자서명 자동 처리 간헐적 실패 — 자식 행 INSERT·부모 행 UPDATE의 락 획득 순서를 SQL로 재현하고 INNODB 잠금 테이블로 확인, FK 공유 락·배타 락의 교착 원인 규명, 트랜잭션 순서 보장·SELECT FOR UPDATE 선점 방안 도출
• •동기 처리 방식의 알림 병목 및 장애 전파 — AWS SNS → SQS → Lambda Event-Driven Architecture 설계, 비동기 파이프라인 완성으로 알림 안정성 확보

기여도: Deadlock 재현·분석·해결 방안 도출 단독 수행. DBeaver로 교착 시나리오를 SQL로 재현하고 INNODB 잠금 테이블로 확인.

이메일 발송 시스템의 발송 상태 추적 부족과 데이터 정합성 문제 해결

• •이메일 발송·반송 상태 추적 부재로 실패 사후 인지 — SES 구성세트 → SNS → 이벤트 처리 파이프라인으로 발송/반송 상태 추적, Datadog 로깅 + Slack 실시간 알림 정착, 발송 이벤트 로깅·실패 건 Slack 알림으로 이메일 모니터링 체계 구축

기여도: SES 구성세트 → SNS → 이벤트 처리 파이프라인 설계·구현. 기술 블로그 게재 및 사내 세미나 발표 주도.

기존 1:1 사용자-조직 구조로 인한 사용자 불편과 시스템 확장성 한계 해결

• •1:1 사용자-조직 구조의 확장성 한계 — 1:N 구조로 관계 확장하여 다중 조직 관리 지원, 다중 조직 관리 기능 제공
• •구조 변경 시 기존 API 호환성 단절 리스크 — 기존 API 무중단 마이그레이션 설계, 서비스 연속성 유지

기여도: 스키마 마이그레이션, 인증 흐름 수정, 하위 서비스(Docs/Billing/Mailing) 계정-조직 참조 로직 일괄 수정까지 풀스택 변경.

임상시험 필수 문서(TMF) 관리 시스템의 프론트엔드 신규 개발

• •임상시험 필수 문서(TMF) 관리 시스템 부재로 규제 준수·문서 추적 비효율 — BE 1·FE 2(본인 포함) 팀에 긴급 투입, MVP 범위 정의 후 Admin/Dashboard에 문서 업로드·분류·버전 관리·감사 추적(Audit Trail) 집중 개발, 3개월 내 TMF 관리 프론트엔드 MVP 완성 — 임상시험 필수 문서 체계적 관리 기반 구축

기여도: BE 1명 + FE 2명(본인 포함) 체제에서 FE 담당. Admin/Dashboard 페이지의 문서 업로드·분류·감사 추적 기능 구현.

진행 중이던 VDR 프로젝트의 개발 일정 지연과 MVP 출시 압박 상황에서의 긴급 투입

• •대용량 PDF 변환 동기 처리로 타임아웃 발생 — S3 업로드 트리거 → Lambda 경량 변환 → SNS/SQS 알림 EDA 파이프라인 설계, 동기 변환 타임아웃 해소, 대용량 문서도 비동기 처리로 안정화
• •의료진별 문서 접근 권한 체계 부재 — 역할 기반 문서 접근 및 승인 권한 관리 워크플로우 정의, 역할별 문서 접근·승인 워크플로우 정립
• •VDR 프로젝트 일정 지연 및 MVP 출시 압박 — 3주 긴급 투입, 핵심 기능 우선순위 선정 및 집중 개발, 3주 내 MVP 출시 달성 (BE 2명 + FE 1명 체제)

기여도: BE 2명 중 1명. EDA 기반 문서 처리 파이프라인 설계·구현, 대용량 PDF 비동기 변환 워커 구현. 3주 긴급 투입으로 MVP 출시 달성.

Maven 전체 서비스의 구독/플랜/라이센스 관리 시스템 개발

• •조직별 맞춤 요금제 제공 불가 — ORG별 커스텀 플랜 Internal API 구현, 조직별 맞춤 요금제 제공 체계 구축
• •갱신 불가 플랜의 구독 갱신·재구독 정책 미적용 — 갱신 불가 플랜 구독 갱신·재구독 차단 로직 작성, 비즈니스 정책 정합성 보장

기여도: ORG별 커스텀 플랜, event queue 기반 인벤토리 자동 삭제, 갱신 가능 여부 판별 로직 구현. 다수 PR 직접 기여.

서브도메인 간 세션 충돌 문제를 해결하기 위한 JWT 기반 통합 인증 시스템 신규 개발

• •서브도메인 간 세션 충돌로 인한 인증 불안정 — NestJS + JWT 기반 토큰 인증 시스템 설계 및 구현, 웹(의사/약사/관리자) + 모바일 앱 통합 인증 정립
• •세션 방식의 서브도메인 간 사용자 전환 불가 — 세션→토큰 방식 마이그레이션, 서브도메인 간 원활한 사용자 전환 구현

기여도: 3주간 단독 설계·구현. 웹(의사/약사/관리자 포털) + 모바일 앱 통합 인증 체계 전반.

서비스별 독립 관리로 인한 코드 중복과 일관성 부족 문제를 공통 모듈 통합으로 해결

• •서비스별 권한 검증 로직 중복 및 보안 일관성 부족 — 사용자 권한 확인 미들웨어 공통 모듈화, 보안성 강화 및 권한 검증 일원화

의사·약사용 백오피스 시스템의 실시간 상태 반영 부재와 수동 알림 체계 문제를 Socket.io 및 Web Push 도입으로 해결

• •중복 예약 발생 — 의사ID+시간대 복합 유니크 키 적용, 중복 예약 원천 차단
• •진료·조제·배달 상태 반영 지연(수십 초) — Socket.IO Room 기반 실시간 상태 동기화로 이벤트 즉시 반영, 상태 반영 1초 미만으로 단축, 환자 대기 불만 해소
• •외부 서비스(배달·결제) 장애 전파 리스크 — 배달(후다닥) 및 결제 외부 서비스 통합 API 게이트웨이 설계, Circuit Breaker 패턴 적용, 외부 서비스 장애 전파 차단

기여도: BE 2인 체계에서 Socket.IO 실시간 동기화, Web Push 알림, API 게이트웨이, 진료 예약 중복 방지 전 기능 직접 구현.

약사의 수동 처방전 입력 과정을 OCR 연동으로 자동화

• •처방전 수동 입력 병목 — Naver Clova OCR API 연동으로 처방전 이미지에서 텍스트 자동 추출, 처방전 입력 자동화
• •복약지도 수동 작성 비효율 — 공공데이터(식약처 API) 의약품 정보 활용한 자동 복약지도 생성, 약사 건당 처리 시간 3~5분→30초 단축

기여도: 2개월간 단독 구현. 이미지 수신 → OCR 추출 → 식약처 API 매칭 → 복약지도 생성 파이프라인 전 구간.

Express.js 단일 파일(app.js) 구조에서 NestJS 모듈 아키텍처로 전환

• •Express.js 단일 파일(app.js) 10,000줄 레거시 유지보수 한계 — 3단계 점진적 이관: app.js 단일 파일 → 레이어드 아키텍처(Controller/Service/Repository) → NestJS 프레임워크 도입, 10,000줄 단일 파일을 NestJS 모듈로 이관하고 팀 코드 컨벤션 정립
• •JavaScript 기반 코드의 타입 안정성 부족 — JavaScript → TypeScript 마이그레이션, 타입 안정성 강화
• •테스트 부재로 인한 회귀 리스크 — TDD 도입 및 단위 테스트 작성, 테스트 커버리지 80% 달성

기여도: 단독 주도. 3단계 전환 전 구간, JS→TS 마이그레이션, TDD 도입, 팀 내 코드 컨벤션 확립 모두 직접 수행.

교육 기관의 학습 관리(출석, 수료, 진도율)가 수작업에 의존하여 운영 효율이 낮고 오류가 빈번한 문제 해결

• •출석 관리 수작업 및 중복 출석 발생 — 날짜+사용자ID 복합 유니크 키로 중복 방지하는 QR 기반 실시간 출석 처리 API 구현, 출석 관리 자동화 및 중복 출석 원천 차단
• •수강생 개별 등록의 비효율 — Apache POI 기반 행별 순차 처리로 데이터 정합성을 보장하는 Excel 일괄 등록 시스템 개발, 학기당 300명+ 수강생 일괄 등록 지원
• •수료증 수동 발급 부담 — JasperReports 기반 동적 PDF 수료증 자동 생성 API 구현, 수료증 발급 자동화

기여도: 핵심 기능 직접 구현. QR 출석, Excel 일괄 등록, PDF 수료증, 진도율 계산 등. 6인 팀 풀스택 체계에서 백엔드 전담.

산단 관제센터의 회의실 예약·모니터링·SMS 알림이 개별 시스템으로 분산되어 통합 관리가 불가능한 문제 해결

• •회의실 예약 충돌 발생 — 시간+장소 복합 유니크 키로 예약 충돌 방지하는 실시간 예약 API 구현, 예약 충돌 원천 차단
• •예약 확정 알림 동기 처리로 인한 응답 지연 — 비즈뿌리오 SMS API + @Async 비동기 처리 적용, 예약 확정 SMS 알림 비동기 발송 체계 구축

기여도: 백엔드 전담. 예약 API, 대시보드 모니터링 API, SMS 비동기 연동 직접 구현.

기존 PHP 시스템의 확장성 한계로 새로운 기능 추가가 어렵고, 점수 계산과 상담 관리가 체계화되지 않은 문제 해결

• •레거시 PHP 시스템의 확장성 한계 — iframe 기반 Spring Boot 독립 앱을 기존 PHP 시스템에 임베드하여 레거시 영향 최소화, 레거시 시스템 영향 없이 신규 기능 확장
• •다차원 평가 점수 산정 체계 부재 — 가중 평균 기반 다차원 평가 점수 산정 알고리즘 구현, 복합 점수 계산 자동화

기여도: 백엔드 전담. iframe 통합 구조 설계, 가중 평균 알고리즘, postMessage 상태 동기화, 상담사 백오피스 직접 구현.

5개국 분산 웹사이트에서 국가별 개별 로그인이 필요한 통합 인증 부재 문제 해결

• •5개국 분산 웹사이트의 국가별 개별 로그인 필요 — Spring Security + JWT 기반 중앙화된 통합 인증 서버 정립, 5개국 분산 도메인에 단일 인증 적용 완료

기여도: 3주간 단독 구현. 통합 인증 서버 전체.

WordPress 기반 블로그의 호스팅 비용 부담과 수동 배포 문제 해결

• •WordPress 호스팅 비용 부담 및 수동 배포 — WordPress → Jekyll 정적 사이트 마이그레이션, 호스팅 비용 100% 절감

Claude Code·Codex·Kiro·OMP의 프로젝트별 실행 경계를 관리하고, 병렬 작업의 통합 결과를 영속 큐로 순서대로 전달하는 공개 런처

• •AI CLI 전역 상태 공유와 이름·원격 저장소 기반 프로필 추정으로 세션·규칙이 섞이거나 잘못된 작업 경계에서 시작할 위험 — 프로젝트별 런타임 홈을 생성하고 harness-auto가 정규화된 현재 경로의 가장 구체적인 단일 등록 경계만 선택하도록 구현, 경계 밖·심볼릭 링크 이탈·모호한 중복 등록은 시작 전 차단; 공개 contract demo·CI로 경계·원문 SHA-256·관계 무결성 재현
• •검증·push·readback 동안 공용 잠금을 보유해 병렬 작업의 통합 대기가 600초·3,600초 후에도 실패 — 영속 enqueue/wait 분리, pool 간 목적지별 FIFO·중복 접수 방지·worker/test 예산·고정 snapshot·push 후 crash 복구를 구현, 실제 두 pool 작업 모두 첫 시도·exit 0·DELIVERED 확인, 중복 접수는 동일 ID·wait timeout 후 queued 유지; 공개 PR #146에 구현 근거 보존
• •OMP 로컬 fork와 HOME·인증·재개 정보 불일치로 공통 실행·도구 정책 집행이 중단되거나 우회됨 — 로컬 fork 대신 upstream 확장·설정 overlay를 채택하고 실행 환경·인증·재개, URL 읽기, 모델 호출 전 차단, 터미널 프로세스·종료 신호 정책을 통합, v0.77.7에서 native URL 차단 대상 GET 0·print 거부 시 provider 호출 0·Ctrl-C 종료 130 및 잔존 native 프로세스 0 확인; MCP/LSP upstream 활성화·전체 global DB SSOT는 범위 밖

채용 공고를 자동 수집·정제하는 사이드 프로젝트의 배포·스케줄링 인프라 구성

• •무료 호스팅의 cron 미지원과 관리형 DB 무료 티어의 비활성 일시정지로 정기 작업 불가 — 호스팅 cron 대신 자체 Mac mini의 워크플로우 자동화(n8n) 스케줄러를 채택하고 warm-up 엔드포인트와 시크릿을 표준화, DB 일 1회 자동 warm-up으로 무료 티어 유지, manifest 기반 동기화 재구성