길드 시스템 기획서 2편: 통신 방식(Socket)과 길드 직급, 권한 테이블 설계

 안녕하세요. 호랭이 물어갈 기획놈들입니다. 

지난 프롤로그에서 길드 시스템을 도대체 왜 만들어야 하는지, 그 거대한 의도에 대해 다루어 보았습니다. 

오늘은 기획서의 본편으로 들어가, 길드 시스템을 게임 속에 실제로 구현하기 위한 가장 뼈대가 되는 기술적, 구조적 설계에 대해 이야기해 보겠습니다.

지난 시간에 길드를 '왜' 만드는지, 그 역할에 대해 진지하게 고민해 보았습니다. 결론적으로 길드는 게임 내의 '작은 사회'입니다. 이 사회가 삐그덕거리지 않고 원활하게 돌아가려면 명확한 시스템(규칙)이 필요합니다.

우선 이 작은 사회를 어떠한 방식으로 설계하고 만들지(서버 타입을 웹 방식으로 할지 소켓으로 할지) 생각하고 그 다음으로 '작은 사회'라고 했는데 이때 구성원은 어떻게 나눠야 할지 마지막으로 그렇게 나눈 구성원의 권한은 어떻게 되는지 알아보겠습니다.

1. 퀄리티를 가르는 보이지 않는 손: 웹(Web) vs 소켓(Socket)

길드 시스템 기획에 들어가기 앞서, 기획자가 개발팀과 가장 먼저 합의해야 할 중대한 사안이 바로 '서버 동기화 방식'입니다. 

이 선택이 우리가 아는 '진짜 살아 숨 쉬는 길드'를 만들지, 아니면 '껍데기만 길드인 웹 게시판'을 만들지를 결정합니다.

그럼 간략하게 웹 방식과 소켓 방식에 대해 이야기 드리겠습니다.

<그림 1. 추방을 당했지만 추방 당한 줄 모르는 유저>

웹(Web) 방식 (비동기화) 

흔히 네이버 카페나 게시판을 생각하시면 됩니다. 

클라이언트가 서버에 패킷(요청)을 쏠 때만 데이터를 받아옵니다. 

만약 이 방식으로 길드를 만들면 치명적인 UX 붕괴가 발생합니다. 

길드장 또는 부길드장이 나를 길드에서 강퇴시켰더라도, 내가 화면을 새로고침하거나 재접속하기 전까지는 내 화면에 여전히 길드원으로 나오는 '유령 상태'가 유지됩니다. 

강퇴당한 줄도 모르고 길드 채팅을 치는 대참사가 벌어지는 것이죠.

더 슬픈 건, 한참 길드 채팅을 치고 전송 버튼을 누르는 순간 그제야 '길드에서 추방되었습니다.'라는 메시지가 출력된다는 것입니다. 뒤늦게 강퇴 사실을 깨달은 유저는 깊은 분노를 느끼며 적대 길드로 넘어가거나, 최악의 경우 게임을 삭제해버리는 참사가 벌어집니다.

<그림 2. 추방 당한 것을 바로 알아챈 유저>

소켓(Socket) 방식 (실시간 동기화) 

카카오톡 채팅처럼 클라이언트와 서버가 항상 파이프라인을 연결해 두고 실시간으로 데이터를 주고받는 방식입니다. 

누군가 길드에 가입하거나 강퇴당하면, 즉시 서버에서 패킷을 쏴주어 내 화면과 채팅창에 시스템 메시지가 뜹니다. 

서버 리소스는 더 많이 소모되겠지만, 유저가 끊김 없는 채팅을 하며 커뮤니티 활동을 하는데 불편함 없이 좋은 경험을 주기 위해선 개발 단계에서 서버 구축 시 길드 같은 핵심 시스템은 무조건 소켓 방식으로 개발되는 것이 장점이 많습니다!

과거에 단 한번 웹 서버 기반으로 작업했다가 QA 테스트 단계에서 진짜 돌이킬 수 없는 아픈 상처를 받았기에 저처럼 아픈 상처를 받고 싶지 않다면 꼭 소켓 방식으로 작업을 시작하시길 적극 권장 합니다.

2. 길드 직급의 설계: 게임의 장르와 BM에 따라 달라야 한다

그 다음으로 흔히 발생되는 실수가 다른 게임의 길드 시스템을 생각없이 그대로 복사해 오는 것입니다. 길드의 직급(등급) 체계는 우리 게임이 '어떤 장르이며, 최종 BM(수익 모델)과 엔드 콘텐츠가 무엇이냐'에 따라 완전히 다르게 설계되어야 합니다.

① 라이트 RPG 및 키우기 장르 (3단계 스탠다드)

<그림 3. 키우기 게임 예시>

• 구조: 길드장, 부길드장, 길드원 (딱 3단계)

• 특징: 개인의 성장이 중심이 되는 분재 스타일 서브컬처나 방치형/키우기 장르에서는 직급을 세분화할 필요가 없습니다. 길드의 목적이 소속감 부여와 출석/기부 보상을 타 먹는 것에 맞춰져 있기 때문에, 관리자의 피로도를 낮추기 위해 가장 심플한 3단계 구조를 가져가는 것이 훌륭한 밸런스입니다.

② 하드코어 MMORPG 및 4X 중심 장르 (다단계 세분화)

<그림 4. 라오킹 같은 전쟁(4X) 게임>

• 구조: 길드장, 부길드장, 전투/레이드 지휘관, 정예(핵심) 길드원, 일반, 수습(용병) 등 5단계 이상.

• 특징: 길드 단위로 거대한 이권(영지전 세금, 길드 레이드 분배금)이 걸려있고, 하드코어한 과금이 동반되는 게임이라면 이야기가 완전히 다릅니다. 이때는 권한을 극도로 쪼개야 합니다.

  • 창고 접근권: 비싼 아이템이 쌓이는 길드 창고는 최소 '정예' 등급 이상만 접근하게 하여 철새 유저의 '먹튀'를 방지해야 합니다.

  • 전술 권한: 길드 대 길드(GvG) 전투 시 핵심 타이밍에 막대한 재화를 소모해 '길드 무적 버프' 등을 써야 하므로, 이를 전담하는 '전투 지휘관' 직급을 별도로 두어야 합니다.

  • 수습 기간: 가입 직후 바로 권한을 주지 않고 일정 기간(혹은 공헌도 달성 전까지) '수습' 상태로 두어 어뷰징을 막는 시스템이 필수입니다.

결국 기획자는 "우리 게임의 길드가 친목 중심의 동아리인가, 아니면 이권을 다투는 거대한 기업인가?"를 먼저 정의하고 그에 맞춰 직급 테이블을 설계해야 합니다.

3. 권한 매트릭스(GuildMemberAuth) 테이블 설계

대략적인 설명은 모두 드렸고 이번 제가 맡은 프로젝트가 '키우기' 장르라 저 같은 경우엔 3개의 직급으로 나눴습니다.

직급을 나누었다면, 이제 "누가 어떤 행동을 할 수 있는가?"를 클라이언트와 서버가 이해할 수 있는 언어로 정리해 주어야 합니다.

이때 사용하는 것을 'GuildMemberAuth' 테이블 이라고 정의하고 권한 매트릭스라고 제 친구 서버 프로그래머가 알려줬습니다.

[GuildMemberAuth] 테이블 예시

권한 항목 (Action)	길드원 (Type 1)	부길드장 (Type 2)	길드장 (Type 3)
길드 해체	0	0	1
길드장 위임	0	0	1
가입 승인 및 거절	0	1	1
길드원 추방	0	1	1
길드 공지사항 수정	0	1	1
길드 스킬(버프) 사용	0	1	1
일반 채팅 및 기부	1	1	1

프로그래머는 기획서의 복잡한 텍스트를 읽을 필요 없이, 이 테이블의 0과 1 값만 보고 클라이언트 UI 버튼의 활성화/비활성화 처리와 서버의 예외 처리를 깔끔하게 진행할 수 있습니다. 

기획자 역시 추후 권한 변경 요청이 오더라도 테이블 데이터만 수정하면 되므로 유지 보수가 매우 편리해집니다.

<그림 5. 테이블 예시>

참고로 서버 프로그래머들은 이런 권한 매트릭스를 제어할 때 내부적으로 '비트마스크(Bitmask)'라는 방식을 자주 사용합니다. 

하지만 우리는 기획자입니다. 

코드가 어떻게 돌아가는지는 개발팀에 맡겨두고, 우리는 기획서에 각 권한 컬럼을 만들고 0(불가)과 1(가능)로 가장 직관적이고 오해 없이 명시해 주는 것이 최고의 협업 방식입니다.

[다음 화 예고] 

뼈대와 권한을 완벽하게 세웠으니, 이제 길드 입장을 위한 버튼 UI가 어디 있는지 길드 가입과 생성 부분에 대해 이야기 하며 알아보도록 하겠습니다.