Server Developer

게임 서비스를 처음부터 라이브까지 가져가면서,
나는 게임 서버 개발과 운영툴 개발을 함께 맡아 시작했다.
이후 후임 한 명을 더 채용해 둘이서 개발을 마무리했고, 오픈 이후에는 두 명이 서버를 전담하며 라이브 대응을 하고 있다.

운영툴을 직접 만들면서 가장 크게 느낀 건,
이 작업의 어려움이 기술적인 난이도에 있지 않다는 점이었다.

오히려 더 힘들었던 건
운영툴을 어떻게 바라보고, 어디까지를 기대하는지에 대한 인식의 차이였다.

운영툴은 항상 우선순위에서 밀린다

운영툴 이야기를 꺼내면 흔히 이런 말이 따라온다.

“서버 먼저 만들고, 운영툴은 필요해지면 붙이면 되죠.”

나 역시 개발 초반에는 비슷하게 생각했다.
게임 서버가 핵심이고, 운영툴은 그걸 보조하는 도구라고 여겼다.

하지만 문제는 운영툴이 실제로 사용되기 시작하는 순간부터였다.

개발 단계에서는 잘 보이지 않던 요구사항들이 운영 단계에 들어서면서 갑자기 명확해지기 시작한다.

• 운영자가 매일 눌러야 하는 버튼
• 반복되는 수동 작업
• 실수하면 바로 장애로 이어지는 기능들

이 시점부터 운영툴은 더 이상 ‘곁다리’가 아니게 된다.

지표 요청은 기술 문제가 아니었다

오픈이 가까워졌을 무렵, 운영 쪽에서 지표를 보고 싶다는 요청이 들어왔다.
다행히 막연한 요청은 아니었고, 나는 먼저 구체적인 질문을 던졌다.

• 어떤 데이터를 보고 싶은지
• 실시간 지표인지, 누적 지표인지
• 운영툴에서 어떤 형태로 확인하고 싶은지

그 답을 바탕으로 InfluxDB를 검토했고, 게임 서버와 운영툴 양쪽에 지표 시스템을 붙였다.

기술 선택 자체는 지금도 크게 틀렸다고 생각하지 않는다.
문제는 역시 시간과 리소스였다.

• 서버 개발은 계속 진행 중이었고
• 오픈 일정은 고정돼 있었고
• 운영툴 UI까지 함께 만들어야 했다

결국 지표는 “동작은 하는” 상태로 들어갔다.
지금 돌아보면 지표 정의도, 구조도 더 다듬고 싶다는 아쉬움이 많이 남는다.
하지만 라이브 대응과 콘텐츠 개발을 병행하는 상황에서, 그 아쉬움은 계속 뒤로 밀리게 된다.

운영툴 UI를 고민하게 되는 백엔드 개발자

운영툴을 만들다 보면, 예상하지 못했던 이야기가 나온다.
바로 UI와 디자인이다.

개인적으로 보기 불편한 화면을 좋아하지 않아 무료 템플릿을 가져와 운영툴에 적용했다.
프론트엔드 내부 구조까지 신경 쓸 여유는 없었고,
“운영자가 쓰기만 하면 된다”는 기준으로 최소한의 정리는 해두었다.

개인적인 욕심으로 다크/화이트 테마도 함께 넣었다.

그런데 이후 이런 요청이 들어왔다.

“UI를 조금만 이렇게 바꿀 수 없을까요?”

그 순간 든 생각은 단순했다.

운영툴은 운영자만 보는 화면인데,
이 정도까지 백엔드 개발자가 책임져야 할까?

요청 자체가 문제라기보다는,
어디까지가 기대치인지에 대한 합의가 없었다는 점이 가장 크게 느껴졌다.

개발 중엔 괜찮다더니, 운영 중엔 불편하다는 말

비슷한 일은 기능 추가에서도 반복됐다.

개발 중간중간 나는 계속 물었다.

• 이렇게 사용해도 괜찮은지
• 더 필요한 기능은 없는지
• 불편한 부분은 없는지

대부분의 답은 이랬다.

“일단 괜찮아요.”

하지만 운영이 시작되자 이야기가 달라졌다.

• “이 화면은 좀 헷갈려요”
• “여기서 자주 실수해요”
• “이 기능이 없어서 불편해요”

그때 느낀 감정은 화라기보다는 허탈함에 가까웠다.

개발 단계에서는 실제 운영 흐름을 체감하기 어렵다.
매일 써보기 전까지는, 어떤 불편이 반복되는지도 알기 힘들다.

기획안이나 명확한 요구사항 문서가 있었다면,
“이건 합의된 범위를 벗어난 요청”이라고 말할 수 있었겠지만
모든 판단이 다시 개발자에게 돌아오게 됐다.

운영툴은 기술보다 ‘합의’가 먼저다

이 경험들을 겪으면서 느낀 건 분명했다.

운영툴의 가장 큰 문제는 기술이나 구현 난이도가 아니라 기대와 역할에 대한 합의의 부재였다.

• 운영툴이 책임지는 범위는 어디까지인지
• 개발자의 역할은 어디까지인지
• UI/UX 수정 요청은 어느 수준까지 수용할지
• 반드시 있어야 하는 기능은 무엇인지

이 기준이 정리되지 않으면, 운영툴은 계속해서 “왜 이건 안 되나요?”라는 질문을 받게 된다.

그리고 그 질문의 대부분은
백엔드 개발자에게 향한다.

마무리

운영툴을 만들면서 나는 기술보다 사람 사이의 간극에서 더 많이 흔들렸다.

누군가의 잘못이라기보다는, 정리되지 않은 상태에서 기대만 쌓여왔던 구조에 가깝다.

이 글은 “운영툴은 백엔드 개발자가 다 책임져야 한다”는 이야기가 아니다.
그렇게 흘러가게 되는 상황과 구조를 한 번 돌아보고 싶어서 정리한 기록이다.

만약 지금 운영툴을 만들고 있거나, 앞으로 만들어야 한다면
기술적인 구현보다 먼저 역할과 기대치를 함께 정리하는 대화부터 해보길 권하고 싶다.

그 대화가, 운영툴 개발에서 가장 강력한 안전장치가 되어줄 것이다.

그리고 왜 그 기준에는 백엔드 관점이 필요했는가

운영툴 이야기를 꺼내면 종종 이런 반응을 듣는다.

“운영툴이요? 그냥 운영팀 요구사항 받아서 만들면 되는 거 아닌가요?”

틀린 말은 아니다.

실제로 많은 운영툴은 그렇게 시작한다. 나 역시 처음에는 그렇게 생각했다.

하지만 막상 설계를 시작하고 나면, 생각보다 훨씬 구조적인 질문들과 마주하게 된다.

‘무엇을 먼저 만들 것인가’는 단순히 요구사항을 정리하는 문제가 아니었다.

서비스의 구조를 이해하고, 그 안에 숨어 있는 리스크를 인지한 상태에서만 내릴 수 있는 판단이 필요했다.

그래서 나는 운영툴을 설계할 때마다 항상 같은 질문부터 던졌다.

이 서비스에서 가장 위험한 작업은 무엇인가?
그리고 그 위험을 시스템으로 어떻게 줄일 수 있는가?

이번 글에서는 내가 실제로 운영툴을 만들면서 가장 먼저 넣었던 기능들과,

그 기준을 잡을 때 어떤 생각을 했는지를 정리해보려고 한다.

운영툴 설계의 기준은 ‘편의’가 아니라 ‘리스크’였다

운영툴을 처음 설계할 때, 일부러 “이 기능이 있으면 편하겠다”라는 생각은 뒤로 미뤘다.

대신 아래 세 가지 질문을 기준으로 삼았다.

• 실수했을 때 서비스에 치명적인 영향을 줄 수 있는가?
• 수동으로 처리할 경우 반복적으로 발생하는 작업인가?
• 개발자가 직접 개입하지 않으면 안 되는 구조인가?

이 질문들에 YES가 나오는 기능부터 만들었다.

운영툴은 편리함을 위한 도구이기 이전에, 실수를 줄이기 위한 장치여야 한다고 생각했기 때문이다.

1. 유저 조회 기능 - 모든 운영의 출발점

가장 먼저 구현한 기능은 유저 조회였다.

단순히 계정 정보를 나열하는 화면이 아니라, 운영자가 상황을 판단하기 위해 필요한 정보가 한눈에 보이도록 설계했다.

반드시 포함시킨 정보

• 계정 상태 (정지 여부)
• 재화 / 아이템 / 캐릭터 현황
• 최근 접속 기록

이 기능을 1순위로 둔 이유는 단순하다.

운영의 대부분은

“이 유저가 지금 어떤 상태인가”를 파악하는 것에서 시작되기 때문이다.

이 단계가 느려지면 이후의 모든 운영 대응도 함께 느려진다.

CS 문의 대응, 버그 확인, 어뷰징 조사 모두 마찬가지다.

그래서 유저 조회 기능만큼은 속도, 정보의 정확성, UI의 직관성 어느 것도 타협하지 않았다.

2. 계정 제어 기능 - DB 직접 수정을 없애기 위해

두 번째로 만든 기능은 계정 제어였다.

• 계정 정지 / 해제
• 이용 제한 상태 변경
• 운영용 플래그 제어

이 기능의 목적은 분명했다.

개발자가 DB에 직접 접속해 계정을 수정하는 상황을 만들지 않는 것

수동 처리 구조에서는 아무리 조심해도 실수가 발생할 수 있다.

• 쿼리 조건 누락
• 변경 전후 상태 확인 누락
• 작업 이력 미기록
• 캐시 동기화 문제

운영툴을 통해 계정 제어를 하도록 만들면서, 이런 위험 요소들은 시스템 차원에서 차단할 수 있었다.

이건 편의 기능이 아니라, 서비스를 지키기 위한 안전장치에 가깝다.

3. 작업 이력 기록 - “누가, 언제, 왜”

운영툴에서 가장 과소평가되지만,

실제로는 가장 중요한 기능 중 하나가 작업 이력이다.

나는 모든 운영 작업에 대해 아래 정보가 반드시 남도록 설계했다.

• 작업자
• 작업 시간
• 대상 유저
• 변경 전 / 변경 후 값
• 작업 사유

운영을 하다 보면 이런 순간이 반드시 온다.

“무엇이 바뀌었는지”보다 “누가 왜 바꿨는지”

이력이 없다면 원인도, 책임도, 복구도 어려워진다.

그래서 이력은 선택이 아니라 필수였다.

4. 우편 발송 / 유저 상품 관리 – 반복 작업을 시스템으로 옮기다

운영 중 가장 자주 발생하는 요청은 아이템 지급과 회수였다.

이걸 매번 SQL로 직접 처리하는 구조는 비효율을 넘어서 명확한 리스크였다.

그래서 우편 발송 기능을 설계할 때도 ‘쉽게 쓰는 것’보다 아래를 우선했다.

• 대상 유저 명확화
• 지급 / 회수 로그 자동 기록
• 중복 지급 방지
• 사전 확인 절차

이 기능 하나로 운영 요청 대응 속도와 점검 안정성이 눈에 띄게 좋아졌다.

5. 권한 분리 – 운영툴은 누구나 쓰면 안 된다

운영툴은 접근성이 좋아질수록 위험해진다.

그래서 초기부터 권한 분리를 반드시 포함시켰다.

• 읽기 전용
• 일반 운영
• 민감 운영
• 시스템 관리

이건 신뢰의 문제가 아니다. 실수를 시스템으로 막기 위한 구조에 가깝다.

백엔드 관점이 필요했던 이유

운영툴은 운영팀이 사용하는 도구다.

그래서 처음에는 “요구사항을 받아서 만들면 되는 것”처럼 보인다.

하지만 설계를 하다 보니 깨달았다.

• 어떤 작업이 위험한지
• 어떤 데이터가 민감한지
• 어떤 실수가 시스템 전체에 영향을 주는지

이 판단에는 서버 구조에 대한 이해가 전제되어야 했다.

그래서 나는 운영툴을 UI 작업이 아니라 서버 설계의 연장선으로 바라보게 되었다.

운영툴은 화면을 통해 접근할 뿐, 본질적으로는 서버의 또 다른 인터페이스이기 때문이다.

마무리

운영툴을 설계하면서 느낀 건, 무엇을 더 많이 만들 것인가보다

"어디까지를 운영툴의 역할로 볼 것인가"를 먼저 정리하는 일이 더 중요하다는 점이었다.

가장 기본적인 구조가 정리되지 않으면, 그 위에 어떤 기능을 얹어도 운영은 쉽게 흔들린다.

이 글에서 정리한 기준들은 누군가의 책임을 더 가져가야 한다는 의미라기보다,

운영과 개발이 서로를 소모하지 않기 위해 필요한 최소한의 합의선에 가깝다.

다음 글에서는 이 기준들이 실제 운영 과정에서 어떤 오해와 갈등으로 이어졌는지,

그리고 운영툴이 기술을 넘어 협업과 역할의 문제로 확장되는 순간에 대해 좀 더 솔직하게 이야기해보려 한다.

소규모 서비스일수록 더 빨리 필요한 이유

운영툴 없이 게임 서비스를 운영해본 적이 있다면,
이 글이 꽤 익숙하게 느껴질지도 모른다.

처음엔 괜찮다.
유저 수가 적고, 문의도 많지 않다.
서버 로그를 직접 보고, DB에 접속해서 데이터를 수정하면 그만이다.

하지만 게임 서버 개발을 계속하다 보면,
서버 구조나 성능보다 더 먼저 한계에 부딪히는 지점이 있다는 걸 알게 된다.
그 지점은 대부분 운영이다.

게임 서버에서 운영툴이 없을 때 가장 먼저 무너지는 것

운영툴이 없는 상태에서 문제가 발생하면 보통 이런 흐름을 거친다.

1. 유저 문의 확인
2. 서버 로그 직접 확인
3. DB 접속 후 데이터 조회
4. 쿼리 수정 또는 수동 처리

이 과정 자체가 잘못된 건 아니다.
문제는 이 모든 과정이 개발자 개인에게 의존한다는 점이다.

실제 문제 해결은 1분이면 끝날 수 있지만,
원인을 찾는 데 20~30분이 걸리는 상황이 반복된다.
결과적으로 장애의 크기와 상관없이
“문제 찾는 시간”이 운영 비용의 대부분을 차지하게 된다.

운영툴이 없으면 개발자는 운영 인력이 된다

운영툴이 없는 환경에서는 다음 작업들이 전부 개발자 업무가 된다.

• 유저 정지 / 해제
• 아이템 지급 및 회수
• 계정 복구
• 재화 수정
• 버그 보상 처리

이쯤 되면 개발자의 역할은 자연스럽게 변한다.

기능 개발자 → 운영 대응 담당자

오전엔 긴급 운영 요청,
오후엔 아이템 회수,
저녁엔 유저 문의 대응.

이 상태가 지속되면 신규 기능 개발은 밀리고,
기술 부채는 쌓이고,
개발자는 지쳐간다.

운영툴의 부재는 단순히 “불편함”의 문제가 아니라
개발 리소스를 지속적으로 잠식하는 구조적인 문제다.

운영툴이 없을수록 실수는 반드시 발생한다

운영툴이 없다는 건 곧 이런 의미다.

• 직접 DB 수정
• 직접 쿼리 실행
• 직접 서버 상태 변경

아무리 조심해도 실수는 발생한다.
특히 야간 대응이나 점검 시간처럼 피로도가 높은 상황에서는 더 그렇다.

WHERE 조건을 빠뜨리거나,
잘못된 유저의 데이터를 수정하는 사고는 개발자라면 한 번쯤 상상해봤을 상황이다.

운영툴이 없다면, 이런 실수를 막아줄 시스템적인 안전장치가 존재하지 않는다.
모든 리스크가 개발자의 집중력에만 의존하게 된다.

소규모 게임 서비스일수록 운영툴은 더 빨리 필요하다

유저도 많지 않은데, 운영툴까지 만들어야 하나요?

현실적인 질문이다. 나 역시 처음에는 그렇게 생각했다.

하지만 실제 경험에서 나온 결론은 정반대다.

소규모일수록 운영툴은 더 빨리 만드는 게 낫다.

이유는 단순하다.

• 규모가 작을 때는 기능도 단순하다
• 요구사항이 명확하다
• 구조를 깔끔하게 잡기 쉽다

서비스가 커진 뒤에 운영툴을 만들려고 하면,
이미 쌓인 데이터 구조와 임시 처리 로직 때문에 구현 난이도는 훨씬 높아진다.

4주 만에 만든 통합 운영툴, 그리고 변화

과거 여러 개의 소규모 게임 프로젝트를 하나의 운영툴로 통합 구축한 경험이 있다.

유저 수는 많지 않았지만, 프로젝트가 여러 개라 운영 요청은 계속 반복됐다.

약 4주 동안 최소한의 운영툴을 구축했고, 다음 기능들을 우선 구현했다.

• 유저 조회 (계정 상태, 재화, 진행 상황)
• 계정 제어 (정지 / 해제)
• 우편 발송 및 유저 상품 관리
• 작업 이력 기록 및 권한 분리

결과는 분명했다.

• 반복 운영 작업 감소
• 실수 리스크 감소
• 개발자의 집중력 회복

운영툴은 사치가 아니라 지속 가능한 개발을 위한 최소한의 안전망이었다.

운영툴을 만들며 마주한 백엔드 개발자의 딜레마

운영툴을 설계하다 보면 자연스럽게 이런 고민이 생긴다.

“나는 백엔드 개발자인데, 왜 관리자 페이지까지 만들고 있지?”

하지만 운영툴은 단순한 UI가 아니다.
운영 흐름과 서버 구조를 가장 잘 이해하는 사람이 설계해야
실제로 ‘쓸 수 있는 도구’가 된다.

그래서 완성도 높은 프론트엔드보다는 운영 흐름이 끊기지 않는 구조에 집중했다.

결국 이 선택은, 백엔드 개발자에게도 가장 효율적인 투자였다.

운영툴은 편의 기능이 아니라 시스템이다

운영툴은 단순한 관리자 페이지가 아니다.
다음 요소들이 포함될 때 비로소 의미를 가진다.

• 권한 관리
• 접근 제어
• 작업 이력 기록
• 로그 조회 구조
• 입력 검증과 확인 절차

즉, 운영툴은
서비스 안정성을 위한 하나의 독립적인 시스템이다.

운영툴을 고민해야 할 시점 체크리스트

아래 항목 중 하나라도 해당된다면,
운영툴을 고민할 시점이다.

• 운영 요청이 개발자에게 직접 들어온다
• DB를 직접 수정하는 일이 잦다
• 장애 원인 분석에 시간이 오래 걸린다

점검 시간에 수동 작업이 많다

운영툴이 없을 때는

운영이 힘들다

운영툴이 있으면

운영이 구조화된다

이 차이는 감정의 문제가 아니라 구조의 차이다.
게임 서버 개발에서 운영툴은 선택이 아니라,
서비스를 오래 굴리기 위한 필수 인프라다.