한국, 일본, 대만, 영문권에서 운영되는 모바일 게임 서버를 맡아 로그인 병목과 랭킹 조회 지연, 결제 오류를 원인부터 찾아 구조를 개선해 해결했습니다.
게임 서버와 백엔드 개발자로 4년간 근무하며, 유지보수와 신규 개발을 넘어 성능 최적화, 운영 인프라 구축, 실시간 서버 설계까지 폭넓은 실무를 경험했습니다. 한국, 일본, 대만, 영문권 4개 권역에서 운영되는 실서비스를 직접 담당하면서 로그인 병목 해소, Redis 기반 랭킹 전환, 채팅 서버 신규 구축, 결제 안정화, DB 마이그레이션 등 서비스 안정성과 성능에 직결되는 문제들을 발견하고 끝까지 해결해 왔습니다.
여러 장애 대응과 구조 개선을 반복하며 얻은 확신은, 표면적인 증상만 처리하는 임시방편보다 원인을 파악하고 구조를 바꾸는 것이 결국 더 안전하고 오래간다는 것입니다. 백엔드는 철저히 무대 뒤에 있지만, 서버가 조용할수록 유저는 끊김 없이 몰입하고 운영팀은 문제 대신 기획에 집중할 수 있습니다. 존재가 드러나지 않을수록 잘 되고 있다는 뜻이라 생각하며, 그 보이지 않는 자리에서 사람들의 경험을 채우는 일에서 보람을 찾습니다.
사용 기간은 실무, 개인 프로젝트, 교육 및 학습 경험을 포함합니다. 막대는 숙련도를 상, 중상, 중, 중하, 하의 5단계로 나타냅니다.
SI 웹 백엔드로 시작해 게임 서버로 옮겨 오며, 요구사항 분석부터 설계, 구현, 테스트, 운영 이슈 대응까지 전 과정을 경험했습니다.
실제 이용자가 겪던 지연과 운영 리스크를 우선순위로 삼아, 증상이 아니라 구조를 고쳤습니다.
화면에 보이는 것은 게임이고, 제가 맡은 것은 그 아래에서 멈추지 않고 돌아가는 서버입니다. 다섯 개 게임의 서버 개발과 라이브 운영을 함께 맡았습니다.
코지 라이프 시뮬레이션 SNS
Go / C# / MySQL / Redis
메타버스형 커뮤니티
Go / C# / BigQuery
4개 권역 라이프스타일 SNG
Java / MySQL / AWS
패션 드레스업 스타일링 게임
Python / MySQL
매치-3 퍼즐
PHP / MySQL
로그인은 기존 구조의 병목을 개선했고, 채널 풀 분산 구조는 새로 설계했습니다.
상황, 과제, 해결 과정, 결과를 순서대로 풀었습니다. 구조가 바뀐 지점은 도식으로 함께 정리했고, 제목을 누르면 접을 수 있습니다.
코지 라이프 시뮬레이션 SNS, 가입자 1만+, 피크 동접 500~1,000명
팀과 역할서버 2명, 클라이언트 5명, UI 1명 구성에서 서버 콘텐츠 개발을 맡았습니다. 개발 중반 서버 팀원이 이탈한 뒤로는 서버를 단독으로 담당했고, 채널 분산과 스케일아웃 같은 주요 기술 방향은 CTO와 검토한 뒤 적용했습니다.
로그인 과정에서 API마다 걸린 락 때문에 요청이 직렬로 처리되는 병목을 확인했습니다. 요청 전체를 막던 락 경합을 줄이고 서로 영향을 주지 않는 작업을 분리해 병렬로 처리했습니다. 남은 병목은 DB 커넥션 풀 확충과 누락된 인덱스 추가로 해소했습니다.
광장과 빌리지에 기본 5개의 채널 풀을 두고, 신규 유저를 인원이 가장 적은 채널에 배치하는 분산 로직을 설계했습니다. 채널별 유저 상태를 격리해 같은 채널의 유저끼리만 상호작용하도록 구성했습니다. 동시 접속 때 채널별 인원 카운터가 꼬이는 경쟁 상태(race condition)는 Go의 sync.Mutex로 보호했습니다.
전체 채널이 정원 30명 중 25명에 가까워지면 채널 5개를 자동으로 일괄 증설하도록 구현했습니다. 증설 직후 유저가 새 채널로 한꺼번에 몰리는 부하 폭주(thundering herd)를 막기 위해 신규 유저는 점진적으로 나눠 배치했습니다. 정원 30명은 실제 플레이 블라인드 테스트로 검증해 확정했습니다.
기획팀과 스펙을 협의한 뒤 코코마인 산리오 캐릭터즈에서 만든 채팅 서버를 코코마인에 맞게 다시 설계했습니다. 빌리지와 지적도 서버는 새로 추가하고, 빌리지 안의 인터랙티브 아이템, 상호작용 모션, 주소 시스템을 함께 만들었습니다.
코코마인 산리오 캐릭터즈에서 Redis로 전환한 랭킹 구조를 바탕으로, 기부 기여도와 패션매치 점수를 Redis에 실시간으로 반영하고 조회는 페이징과 Redis 캐싱으로 처리했습니다.
운영팀 담당자와 필요한 기능을 협의해 요구사항을 확정하고 ASP.NET Core 기반 운영툴을 설계, 개발했습니다. 렉이 생기는 구간에는 인덱싱과 쿼리 최적화를 적용해 아이템과 랭킹처럼 큰 데이터의 조회와 갱신 시간을 5~15초에서 2~6초로 줄였습니다.
막대 길이는 처리 흐름을 설명하기 위한 개념도이며, 실측 수치는 위 결과와 같습니다.
라이프스타일 시뮬레이션 SNG, 한국/일본/대만/영문권 4개 권역 운영, 가입자 20만+, 동접 200~2,000명
네트워크 지연으로 결제가 실패하면 자동으로 재시도하는 로직을 추가했습니다. 재시도 전에는 이전 결제 내역과 지급 내역을 대조해 이미 지급된 건을 다시 지급하지 않도록 했고, 결제는 완료됐지만 아이템이 지급되지 않은 건은 안전하게 복구하도록 구현했습니다.
인증 방식과 GROUP BY 처리처럼 8.0에서 호환성이 깨지는 부분을 찾아 소스 코드를 수정하고, 테스트를 거쳐 배포했습니다. 주요 쿼리에는 인덱싱과 최적화를 함께 적용했습니다.
운영팀과 필요한 지표를 정한 뒤 BigQuery와 Looker Studio로 재화, 토큰, 로그 대시보드를 구축했습니다. 개발팀에 요청하지 않아도 데이터를 바로 확인할 수 있게 됐습니다.
권역마다 다른 콘텐츠에서 생기는 오류를 찾아 수정하고 신규 콘텐츠를 개발했습니다. 다른 개발자도 운영 이력을 빠르게 파악하도록 콘텐츠와 버그 목록을 문서로 정리하고 계속 갱신했습니다.
교육공무직원 인사 행정 시스템, 대상 인원 약 6,400~10,000명
수기와 엑셀로 취합하던 서류 데이터를 항목별로 점수화해 자동으로 집계하고, top-down 정렬로 우선순위를 판별하는 전보 알고리즘을 설계했습니다.
엑셀로는 잡아내기 까다로웠던 동점자와 중복 점수 케이스를 프로그램이 자동으로 구분하는 판별 로직을 별도로 구현했습니다.
문서로 흩어져 있던 인사기록을 하나로 통합해 한 번에 조회할 수 있게 했고, 근무성적평정, 설문조사, 통계 기능을 개발했습니다.
| 버전 | 구조 | 핵심 |
|---|---|---|
| v1 | 단일 스레드 블로킹 | 한 번에 한 접속만 처리, 다른 클라이언트는 연결 대기 |
| v2 | 접속별 스레드 | 접속마다 스레드를 새로 생성 |
| v3 | 고정 스레드 풀 | 정해진 수의 스레드를 재사용 |
| v4 | Linux epoll Reactor | 이벤트 기반으로 다수 접속 처리 |
| v5 | epoll + worker pool | 네트워크 처리와 작업 처리를 분리 |
| v6 | Windows IOCP 비동기 서버 | AcceptEx와 완료 통지 기반 비동기 처리 |
한 번에 한 명만 처리하는 서버에서 시작해 접속마다 스레드를 만드는 방식, 스레드를 재사용하는 방식, Linux epoll과 Windows IOCP까지 구현했습니다. 접속 수가 늘 때 스레드를 효율적으로 쓰고 네트워크 처리와 작업 처리를 나누는 구조를 익혔습니다.
큰 데이터가 한 번에 전송되지 않는 상황을 고려해 남은 데이터를 이어 보내고, 같은 사용자의 메시지 순서가 바뀌지 않도록 송신 큐를 구성했습니다. 접속이 남아 있어도 서버가 안전하게 종료되도록 작업과 스레드의 종료 순서를 구현하고, pending I/O drain을 확인했습니다.
반복 접속과 해제, 서버 종료 상황을 자동으로 테스트하고 메모리 오류가 없는지 검사했습니다.
서버 버전 선택과 실행, 최대 200개 클라이언트 연결, 개별/지연/반복 전송, Echo 응답 집계를 한 화면에서 제어하도록 만들었습니다. 호스트 OS에 맞춰 실행 가능한 버전과 Native/Docker 방식을 판별하고, 실행 파일이 없으면 CMake로 자동 빌드합니다.
| 환경 | 조건 | 결과 |
|---|---|---|
| Linux (Docker 내부 네트워크) | 동시 접속 28,000개 | 메시지 560,000건 모두 처리 |
| Linux (Docker 내부 네트워크) | 30,000개 접속 시도 | 클라이언트의 임시 포트 범위가 먼저 소진, 연결된 28,231개의 메시지는 전부 정상 처리 |
| Windows IOCP (Debug) | 순간 접속 2,000개 | Echo 20,000 / 20,000 |
| Windows IOCP (Debug) | 점진 접속, 동시성 64 제한 | 12,000개 연결 유지, Echo 120,000 / 120,000 |
| Windows IOCP (Debug) | 순간 접속 2,500개 이상 | backlog 128과 pending AcceptEx 16개가 접속 폭주를 다 흡수하지 못해 일부 연결 거부 |
| 공통 | 4 MiB 분할 전송 | 여러 조각으로 나눠 보내도 전체 내용이 정확히 전달됨 |
모든 테스트에서 pending I/O drain과 종료 코드 0을 확인했습니다. 12,000개는 Windows 동적 포트 범위의 영향을 받으므로 서버의 절대 한계로 해석하지 않았고, 대량 로그가 stdout pipe를 막지 않도록 측정 시 출력은 NUL로 보냈습니다.
실서비스에서 실제로 겪은 장애와 데이터 문제를 원인, 조치, 재발 방지 순서로 정리했습니다.
회사와 기간별로 정리했습니다. 회사 이름을 누르면 목록이 펼쳐지고, 프로젝트를 누르면 상세 내용이 열립니다.
장르: 소셜 네트워킹 서비스(SNS), 코지 라이프 시뮬레이션
장르: 소셜 네트워킹 서비스(SNS), 메타버스형 커뮤니티
장르: 스타일링 게임 (패션 드레스업)
장르: 매치-3 퍼즐 게임
장르: SNG(소셜 네트워크 게임), 라이프스타일 시뮬레이션
접속 처리 방식을 v1~v6으로 발전시키고 GUI에서 구조별 차이를 재현하고 비교하는 프로젝트
GitHub
카카오 약관 질문에 답변과 근거 조항을 제공하는 RAG 시스템과 답변 평가 도구 개발
GitHub카카오테크 부트캠프 딥다이브, GPT 아키텍처 직접 구현과 Qwen3 로컬 LLM, RAG/LangChain/LangGraph/Claude API 활용
GitHub
받은 선물과 부조금을 기록하고 답례 시점, 상품, 메시지를 추천하는 AI 관계 관리 서비스
GitHub