devsisters

문제게임 회사 클라이언트 프로그래머의 실제 업무는 "눈에 보이는 게임 구현" 으로만 알려져 있지만, 현업에서는 협업·툴 개발·리소스 관리·엔진 사용 등 훨씬 다양하다.

접근쿠키런 킹덤 4년차 클라이언트 프로그래머가 실제 구현한 컨텐츠를 예시로 컨텐츠 개발 흐름을 따라간다. 직군 구성 → 기획·아트와의 협업 → 데이터 / 리소스 관리 → 엔진 작업 순으로 책임 범위를 풀어낸다.

결과게임 클라이언트 프로그래머를 준비하는 사람에게 직무 전반의 그림을 구체적으로 제시한다. 회사·팀·컨텐츠 종류에 따라 달라지는 부분도 함께 명시.

문제같은 입력이 매번 다른 결과를 내면 리플레이·디버깅·네트워크 동기화·결정적 시뮬레이션 같은 핵심 기능을 안전하게 구현할 수 없다. 게임에서 시간·난수·프레임 처리는 결정성을 깨뜨리기 쉬운 요소다.

접근고정 프레임 게임 루프로 프레임 처리 시간을 일정하게 만들고 게임 로직 수행 횟수를 고정. 시간 의존 코드 대신 프레임 카운트 기반 표현, 시드 고정 난수, 정수 연산 같은 결정성 친화 기법을 함께 적용한다.

결과같은 입력이 항상 같은 결과를 내는 결정론적 알고리즘이 가능해진다. 리플레이·동기화·자동화 테스트 같은 응용을 안정적으로 받쳐주는 기반이 된다.

문제장애 발생 시 조직 전체가 일관된 원칙과 절차 없이 대응.

접근티어 기반 알람 분류 + 역할 분담(지휘자/기록가) + Datadog Incident 채널화 + 포스트모템 체계 도입으로 표준화.

결과Tier 0 은 15분 내, Tier 1 은 업무시간 15분 / 야간 12시간 내 대응 SLO. 구성원 간 맥락 전파와 신뢰 기반 팀 빌딩 달성.

문제게임 플레이어들이 여러 디바이스에서 게임 데이터를 잃어버리거나 크로스 게임 프로모션 혜택을 받을 수 없음.

접근DevPlay 계정 연동 시스템 — Member-Player 구조로 하나의 계정으로 다중 게임 관리 + 토큰 갱신 메커니즘 구현.

결과새 기기로 바꾸어도 기존 게임 데이터 그대로 플레이 가능. 게임 간 보상 시스템 운영 + 리세마라 방지 로직 구현.

문제쿠키런:킹덤 서버 Scala 프로젝트가 커지면서 typeclass implicit 검색과 매크로로 컴파일이 느려져 개발 생산성이 떨어졌다.

접근`-Vstatistics:typer`와 scala-profiling 플레임그래프로 병목을 측정하고, typeclass 인스턴스를 companion object에 정의해 implicit 검색 범위를 줄인다. `ThisBuild / usePipelining := true`로 빌드 파이프라이닝을 켜 서브프로젝트를 병렬 컴파일한다.

결과typer 페이즈 비중이 67.1%에서 52.8%로, 컴파일 시간이 65초에서 45초로 1.44배 빨라졌다. 파이프라이닝까지 더해 전체 빌드가 1.22배 추가 개선됐다.

문제게임 서비스의 품질 기준이 불명확하고 "QA는 단순 버그 찾기"라는 인식 탓에 개발진과 유저 사이 피드백 루프가 끊겨 있다.

접근기획서 기반 테스트 케이스로 내부 품질 기준을 세우고 라이브 서비스 전후로 모니터링과 유저 피드백을 지속 수집한다. QA를 종합 품질보증 활동으로 재정의한다.

결과좋은 QA 활동이 좋은 유저 피드백을 만들고 다시 개발 품질로 이어지는 선순환 구조가 만들어진다. 개발 리소스 낭비와 방향성 오류가 줄어든다.

문제게임 런칭 당일 매출/동접 지표가 1시간 이상 지연되고 국가/OS/스토어 차원이 빠져 있어 의사결정이 어려웠다.

접근Kafka 토픽을 분리하고 Spark Structured Streaming의 Stream-Stream JOIN과 watermark로 late data를 다룬다. Databricks SQL + Airflow 2분 micro batch로 집계하고 Delta Lake Medallion 구조로 저장한 뒤 Kibana 대시보드로 본다.

결과10분 이내 SLO와 5% 이내 오차를 만족하는 준실시간 지표를 만들었다. 쿠키런:모험의 탑은 출시 일주일에 200만 다운로드, 누적 매출 100억 원을 이 지표로 추적했다.

문제함수형 프로그래밍이 무엇이고 왜 중요한지 배경 지식 없이 책을 읽으면 이해가 어렵다. 순수성과 부수효과의 경계가 모호하면 코드가 추론하기 어려워진다.

접근순수 함수를 추출하는 단계적 리팩토링으로 부수효과를 분리하고, 계산과 액션을 명확히 구분한다. 스칼라 코드 예제로 참조 투명성과 등식적 추론을 실증한다.

결과순수 함수 비중을 늘리면 가독성과 유지보수성, 테스트 용이성이 함께 올라간다. 프로그램 대부분은 순수하게 작성하고 가장 바깥쪽에서 한 번만 비순수하게 실행하는 구조가 권장된다.

문제브라우저가 gRPC 커스텀 헤더를 못 다뤄 Admin Backend가 프록시로 동작했고, gRPC 메서드를 추가할 때마다 REST 엔드포인트를 수기로 늘려야 했다.

접근JavaScript Proxy로 런타임에 클라이언트 메서드를 동적으로 생성해 단일 엔드포인트로 라우팅했다. 코드 생성 산출물을 JS 대신 JSON 메타데이터로 바꿔 직렬화 비용도 줄였다.

결과수동 작성하던 엔드포인트를 제거해 약 100만 줄의 JavaScript 코드를 삭제했고, gRPC 메서드 추가 시 수정 부담이 사라졌다.

문제Zabbix와 CloudWatch 기반 모니터링은 클라우드 환경에서 비효율적이었고, 다중 게임 운영에서 클러스터 장애 전파와 알람 우선순위 혼선이 잦았다.

접근2016년부터 Datadog을 도입해 APM으로 병목을 가시화하고, 게임별 EKS 클러스터를 분리해 장애를 격리했다. Terraform으로 클러스터 모듈을 표준화하고 대응 시간 기준으로 알람을 분류했다.

결과실시간 병목 감지와 빠른 대응이 가능해졌고, 클러스터 관리 일관성과 인시던트 우선순위 체계를 동시에 확보했다.

문제ZIO 기반 애플리케이션을 프로덕션에 올렸을 때 기본 설정만으로는 충분한 성능을 내기 어렵고, 어떤 옵션이 병목으로 작용하는지 가늠하기 까다롭다.

접근런타임 플래그에서 `FiberRoots`를 끄고 `RuntimeMetrics`로 측정 지표를 확보한다. `withParallelism`으로 fiber 수를 제한하고, executor의 자동 블로킹과 `EagerShiftBack` 플래그를 다듬어 블로킹 작업 뒤 기본 executor로 복귀시킨다.

결과극단적인 케이스에서 `FiberRoots` 비활성화만으로 약 2.5배의 처리량 개선을 얻었고, 리소스 낭비를 줄여 운영 환경의 성능 저하를 막을 수 있었다.

문제퍼즐 게임 스테이지의 출시 가능 여부 판단이 소수 작업자의 주관에 의존해, 폴리싱 단계 진행이 느리고 일관성이 떨어진다.

접근강화학습으로 학습한 퍼즐봇이 스테이지를 자동 플레이하도록 하고, 전작 유저 데이터의 EDA와 Grid Search로 평가 지표를 설계한다. 봇 지표와 실제 유저 행동의 상관관계를 검증한다.

결과남은 미션 수 분포 기반 지표가 퍼즐봇 데이터와 사내 테스트 유저 사이에서 0.55~0.65 상관을 보였다. 이를 토대로 객관적인 난이도 판단 기준을 폴리싱 단계에 투입할 수 있게 됐다.

문제cert-manager에 `preferredChain: ISRG Root X1`을 지정했는데도 만료된 DST Root CA X3 체인이 발급되는 인증서 장애가 발생했다.

접근Let's Encrypt의 인증서 체인 구조와 ACME 명세를 다시 읽고, Certbot과 cert-manager 구현을 비교한다. default chain 제외와 중간 인증서 issuer CN 검색 로직에서 두 가지 설계 결함을 찾았다.

결과default chain을 탐색 대상에 포함하도록 cert-manager 본 레포지토리에 PR을 제출해 머지했다. 같은 장애가 다른 사용자에게 재발하지 않게 됐다.

문제반복적인 이미지 관리 같은 업무 자동화를 shell script로 짜기엔 문법 진입장벽이 크고 유지보수가 어렵다.

접근Google이 만든 zx 라이브러리로 JavaScript 안에서 $`` 템플릿으로 shell 명령을 실행한다. async/await 기반으로 대량의 이미지 파일 처리 자동화 스크립트를 작성한다.

결과게임 어드민의 이미지 업데이트 절차가 5단계에서 2단계로 줄어든다. 새 아이템 추가 시에도 동일 스크립트로 대응 가능해 유지보수성이 올라간다.

문제쿠키런: 오븐브레이크의 구매 기록 테이블에 컬럼을 추가해야 했지만 일반 ALTER TABLE은 서비스 중단 위험으로 불가능하다.

접근MySQL inplace algorithm은 중복 키 에러로 실패해 Percona Toolkit으로 전환한다. Staging 복제본, Production 복제본(chunk-size 250), Staging, Production 순으로 다단계 검증한다. 배포 후 CPU 100% 장애는 쿼리 최적화와 분산 캐시를 스케줄러 기반 중앙 캐시로 재설계해 해결한다.

결과online alter는 약 23초 만에 완료된다. CPU 100% 장애의 근본 원인을 파악해 정상화하고 이후 동일 도구로 추가 alter 작업을 안전하게 수행한다.

문제Mode·Databricks로 데이터 적재는 됐지만 시각화 단계에서 callback이 비대해지고, 표현 변경마다 새 쿼리가 필요하며 다중 차트가 순차 실행돼 느렸다.

접근Dash(Plotly·Flask 기반) 를 도입하고 callback을 FetchProvider·TransformProvider·RenderProvider 의 MVC 3계층으로 분리한다. LineChartMixin 등 Mixin으로 차트 패턴을 모듈화한다.

결과브라우저 캐시로 DB 재조회를 제거하고 gzip/br 압축으로 데이터 크기를 1/5로 줄였다. 차트 유지보수성이 올라갔다.

문제게임 사운드 리소스를 웹 드라이브로 주고받다 보니 버전 관리가 무너졌고, 비개발 팀원에게는 Git이 진입장벽이 높았다.

접근push·checkout 두 버튼만 노출하는 WebApp을 Next.js·tRPC로 만든다. 저장소는 S3 Versioning Bucket(파일) + Local Git(메타데이터) 로 분리하고, xxHash32(WASM)로 변경 파일만 골라 Zip Streaming으로 동기화한다.

결과배포 후 8개월간 안정 운영됐고, 사용자는 동기화 비용 없이 리소스 버전을 관리한다.

문제쿠키런 킹덤 길드 업데이트 직후 CockroachDB 특정 Range에 트래픽이 몰리는 Hot Range가 발생해 일부 노드 CPU가 100%까지 치솟았다.

접근Primary Key 포맷 변경과 사전 split 부재가 원인임을 분석하고, 로그인만 차단하는 무중단 대기열과 테이블 단위 백업, 명시적 Range split, 문제 노드 격리를 순차 적용했다.

결과서비스를 정상화하고 분산 DB에서 PK 설계와 신규 테이블 초기 분산 전략이 필수라는 교훈을 정리했다.