호스트 권위 기반 WebSocket 협동 릴레이 서버

이 서버의 철학을 한 문장으로 줄이면 “서버는 단순하게, 판단은 호스트가”입니다. 서버가 게임 규칙을 모르기 때문에, 게임 밸런스가 바뀌어도 서버를 다시 배포할 필요가 없습니다. 유지보수가 그만큼 쉽습니다.

• 호스트 권위(host-authoritative) 모델 — 방을 만든 사람이 게임 진행의 “주인”이고, 서버는 심부름꾼(전달자)입니다.
• MonoServer27의 고성능 코어를 그대로 이식 — 네트워크 전송 부분은 이미 성능 검증이 끝난 프로토타입 코드를 글자 하나 안 바꾸고(byte-identical) 가져왔습니다.
• Shared Project 구조 — 공용 코드(DefenceG 등)는 라이브러리(DLL)가 아니라 소스 코드째로 여러 서버에 포함됩니다.

프로세스 하나가 귀(리스너)를 두 개 열어둡니다. 하나는 게임 트래픽을 받는 WebSocket 서버(8023 포트), 다른 하나는 운영자가 상태를 확인하는 HTTP 서버(26677 포트)입니다. 정작 우리 코드는 얇고, 무거운 일은 전부 공용 라이브러리 DefenceG가 처리합니다.

부팅 순서 (Program.Main)

부팅은 비밀정보 → 설정 → 로깅 → 암호키 → 서버 시작 순서로 꼼꼼히 정해져 있습니다. 중간에 하나라도 실패하면 치명적 로그를 남기고 종료합니다.

// 1) AWS 금고(SecretsManager)에서 DB 접속정보 꺼내기
var accessKey = AccessKey.Load(Const.AwsAccessKey, Const.AwsEncryptionKey);
await SecretsManager.InitializeAsync(accessKey);
TblConnectionString.Initialize(SecretsManager.Get("CommonDB"));

// 2) 설정/데이터 핫리로드, Snowflake 로깅, Ip2Country, Redis 연결확인
await RefreshManager.InitializeAsync();

// 3) 프로세스 전체가 쓸 AES 키 확정 (이후 실행 중 교체 없음)
KeyIvChain.SetKey(Global.Shared.Key);

// 4) WebSocket 서버 시작 → 5) HTTP 호스트 실행(여기서 blocking)
var server = new Server();
Global.Shared.SocketServer = server;
server.Start(config.Port);
CreateHostBuilder(args).Build().Run();

연결은 두 단계 시한폭탄과 암호화 준비 과정으로 보호됩니다. 접속 직후엔 30초 안에 인사(핸드셰이크)를 안 하면 끊어버리는 TimeBomb이 걸리고, 인증을 마치면 180초 유휴 타임아웃으로 느슨해집니다. 그동안 7초마다 AliveTimer가 생존 신호를 주고받습니다.

데이터를 선으로 보내기 전에 세 번 가공합니다: MessagePack(작게 만들기) → LZ4(압축) → AES-CBC(암호화). 포장을 풀 때 어떤 열쇠(IV)를 써야 하는지는, 메시지 앞에 붙는 1바이트짜리 꼬리표(keyIndex)가 알려줍니다.

여러 종류의 메시지를 하나의 타입처럼 다루기 위해 MessagePack의 [Union](다형성)을 씁니다. 모든 메시지는 Protocol을 상속하고, KeyIndex 값으로 “나는 어떤 암호 채널에 속한다”를 스스로 선언합니다(기본값 Remote).

private static readonly MessagePackSerializerOptions _options =
    MessagePackSerializerOptions.Standard.WithCompression(MessagePackCompression.Lz4BlockArray);

// 스레드마다 버퍼 1개를 계속 재사용 → 평소엔 메모리 새로 안 만듦(할당 0)
private static readonly ThreadLocal<ArrayBufferWriter<byte>> _writerPool =
    new(() => new ArrayBufferWriter<byte>(256));

public static SerializedBuffer Serialize(Protocol protocol){
    var writer = _writerPool.Value; writer.Clear();  // 비우고 다시 씀
    MessagePackSerializer.Serialize<Protocol>(writer, protocol, _options);
    return new SerializedBuffer(writer.WrittenMemory);
}

받은 메시지의 분기 처리는 OnProcessAsync의 switch 하나로 끝납니다. 게임 도중 발생하는 예외(HaeginException)는 붙잡아 Error 메시지로 돌려주고, 연결은 끊지 않습니다.

try{ protocol = ProtocolSerializer.Deserialize(memory); }
catch(Exception){ throw new InvalidProtocolException(); } // 해석 불가 = 연결 차단

switch(protocol.ProtocolId){
    case ProtocolId.AliveQ:
    case ProtocolId.AliveA: TimeBomb?.Reset(); return await ProcessAliveAsync(...);
    case ProtocolId.HandshakeQ: return await ProcessHandshakeAsync((HandshakeQ)protocol);
    case ProtocolId.AuthQ: return await ProcessAuthAsync((AuthQ)protocol);
    // ... CreateRoom / Join / Leave / Close / Relay
}
catch(HaeginException ex){ Send(new Error{ Result = ex.Result }); return true; }

Room은 공용 코어의 Group을 상속해서 멤버 관리와 브로드캐스트를 공짜로 얻고, 거기에 게임 정보(방장, 스테이지, 상태)를 얹은 것입니다. 방 목록 전체는 RoomManager가 LockMan이라는 자물쇠로 안전하게 관리합니다.

Room 상태 머신

방 목록(GetRoomListQ)에는 Waiting 상태의 방만 보입니다. 정원(MemberMax)이 차면 곧바로 Playing이 되어 목록에서 사라집니다.

Relay — 핵심 데이터 통로

중계는 놀랄 만큼 단순합니다. 서버는 Data를 열어보지 않고, 보낸 사람만 빼고 방 전체에 그대로 흘려보냅니다. 이 단순함이 곧 서버의 확장성입니다.

private async Task<bool> ProcessRelayAsync(RelayQ protocol){
    var room = Room;
    if(room == null) return false;
    await room.BroadcastAsync(new RelayA{
        FromSuid = Suid,
        Data     = protocol.Data     // 서버는 내용을 해석하지 않음
    }, excludeSuid: Suid);            // 보낸 사람은 제외
    return true;
}

방 닫기와 “이중 퇴장” 방지

방장이 방을 닫는 CloseRoomQ는 순서가 중요합니다. 전원에게 “닫습니다”를 알린 뒤 방장 본인을 먼저 퇴장시킵니다. 이렇게 안 하면 곧이어 소켓이 끊길 때 OnDisconnect에서 또 한 번 퇴장 처리가 돌아 방장 승계가 꼬입니다.

방장이 갑자기 나가도 방이 무너지면 안 됩니다. 남은 사람 중 가장 먼저 들어온 사람이 새 방장이 됩니다. 놀라운 점은 이 “가장 먼저”를 판단하려고 별도로 정렬하거나 시간을 비교하지 않는다는 것입니다. Group의 멤버 목록이 입장 순서를 그대로 유지하기 때문에 RemoteList[0]이 곧 최초 입장자입니다.

int count = await LeaveAsync(remote.RoomMembership);
if(count < 0) return;

if(remote.Suid == HostSuid && count > 0){         // 나간 사람이 방장이면
    var list = RemoteList;                 // 변하지 않는 스냅샷(사본)
    var newHost = (Remote)list[0];        // [0] = 가장 먼저 들어온 사람
    HostSuid = newHost.Suid; HostNickname = newHost.Nickname;
    await BroadcastAsync(new LeaveRoomNotify{ LeaverSuid = remote.Suid });
    await BroadcastAsync(new HostMigrateNotify{ NewHostSuid = HostSuid, ... });
}
else if(count > 0)  // 게스트가 나감: 방 유지, 알림만
    await BroadcastAsync(new LeaveRoomNotify{ LeaverSuid = remote.Suid });

if(count == 0){ State = RoomState.Closed; await RoomManager.Shared.DestroyRoomAsync(RoomId); }

면접에서 가장 깊게 파고들 부분입니다. 이 서버의 전송 코어는 뜨거운 경로(hot path)에서 자물쇠(lock)를 쓰지 않습니다. 왜 그렇게 만들었고, 자물쇠 없이 어떻게 안전을 지키는지 차근차근 풀어보겠습니다.

비교자물쇠 방식 vs Lock-free 방식

그래서 이 서버는 둘을 목적에 맞게 나눠 씁니다. 초고빈도인 메시지 송·수신은 lock-free로, 저빈도지만 복잡한 방 생성/삭제는 자물쇠(LockMan)로. “도구를 상황에 맞게 고른다”가 핵심입니다.

①메시지 보내기 — 우편함(채널)에 넣기

각 연결은 바운디드(크기 제한) 채널이라는 우편함을 하나 갖습니다. 여러 스레드가 이 우편함에 편지(메시지)를 자물쇠 없이 던져 넣고, 전담 배달부(sender task) 한 명이 순서대로 꺼내 실제 소켓으로 보냅니다. 이 구조를 MPSC(여러 명이 넣고, 한 명이 뺀다)라고 합니다.

Channel.CreateBounded<Frame>(new BoundedChannelOptions(SendChannelCapacity){
    SingleReader = true,    // 꺼내는 배달부는 1명 → 순서 보장
    SingleWriter = false,   // 넣는 스레드는 여럿 허용 (MPSC)
    FullMode = BoundedChannelFullMode.Wait,
});
// 편지 봉투 만들기: [길이:4][열쇠번호:1][내용] 을 빌린 버퍼에 그 자리에서 암호화
byte[] rented = ArrayPool<byte>.Shared.Rent(total);  // 버퍼를 새로 안 만들고 빌림
BinaryPrimitives.WriteUInt32LittleEndian(rented.AsSpan(0,4), (uint)total);
rented[4] = (byte)keyIndex;
_sendAes.Value.EncryptCbc(memory.Span, _keyIvChain.GetIv(keyIndex), rented.AsSpan(5, len));
if(ch.Writer.TryWrite(new Frame(rented, total))) handed = true;
else _ = DisconnectAsync(socketId);   // 우편함이 꽉 차면 연결 종료

②멤버 목록 — “사본을 통째로 갈아끼우기”(CAS)

방의 멤버 목록은 절대 그 자리에서 수정하지 않습니다. 대신 “현재 목록을 복사 → 사본에 한 명 추가/삭제 → 원본을 사본으로 통째로 교체”합니다. 이 교체를 CPU의 원자적 명령인 CompareAndSwap(CAS)로 합니다.

이 방식(copy-on-write)의 진짜 이점은 읽는 쪽에 있습니다. 브로드캐스트로 멤버 목록을 훑는 도중 다른 스레드가 입·퇴장을 해도, 내가 손에 든 사본은 변하지 않으므로 안전하게 끝까지 순회할 수 있습니다. (§05의 방장 승계가 정렬 없이 정확한 이유가 바로 이것)

if(gm.SetGroup(this) == false) return -4;   // 한 사람은 한 방에만 (CAS 가드)
while(true){
    var cur = Volatile.Read(ref _snapshot);       // 현재 목록(원본) 읽기
    if(cur.List.Length >= RemoteMax){ gm.ResetGroup(this); return -2; } // 정원 초과
    var next = new Snapshot(cur.List.Add(remote), cur.Set.Add(remote)); // 사본에 추가
    if(Interlocked.CompareExchange(ref _snapshot, next, cur) == cur){  // CAS 성공?
        remote.SetIv(_keyIndex, Iv);          // 입장과 동시에 방 IV 부여
        return next.List.Length;               // 반환값 = 새 멤버 수
    }
    Thread.SpinWait(1 << Math.Min(spinCount, 8));  // 졌으면 잠깐 쉬고 재시도
}

목록을 ImmutableArray(순서 유지)와 ImmutableHashSet(빠른 포함 검사, O(1))로 동시에 관리해, 순서도 지키고 “이미 방에 있나?” 검사도 빠르게 합니다.

③브로드캐스트 — 한 번 만들어 N명이 나눠 쓰기(zero-copy)

4명에게 같은 메시지를 보낼 때, 순진하게 만들면 4번 직렬화 + 4번 암호화 + 4개 버퍼가 됩니다. 이 서버는 딱 한 번만 만들어 버퍼 하나를 4명이 공유합니다.

internal sealed class SharedSendBuffer{
    private readonly byte[] _buffer; private int _refCount;   // 아직 쓰는 사람 수
    public ReadOnlyMemory<byte> Memory => new(_buffer, 0, _length);
    public void Release(){
        if(Interlocked.Decrement(ref _refCount) == 0)  // 내가 마지막이면
            ArrayPool<byte>.Shared.Return(_buffer);       // 불 끄고 반납
    }
}

단, 상대마다 다른 열쇠(Remote IV)로 개별 암호화가 필요할 땐 공유가 불가능해 사람 수만큼 암호화합니다. 그래서 브로드캐스트는 방 공용 IV를 쓰도록 설계된 것입니다.

④복잡한 곳엔 자물쇠 — LockMan

전송은 lock-free지만, 방 목록처럼 여러 단계를 한 덩어리로 처리해야 하는 곳(정원 확인 → 방 생성 → 입장 → 실패 시 되돌리기)은 자물쇠가 더 안전하고 읽기 쉽습니다. LockMan은 같은 흐름 안에서 다시 잠가도 데드락이 안 나는(재진입 가능) 비동기 자물쇠이고, 20초 타임아웃이 있어 영원히 멈추는 일도 막습니다.

private readonly LockMan _lock = new(TimeSpan.FromSeconds(20));

public async Task<Room> CreateRoomAsync(...){
    using(await _lock.LockAsync()){          // 여기부터 임계구역
        if(rooms.Count >= Config.Instance.RoomMax) return null;
        var room = new Room(memberMax);
        rooms[nextRoomId++] = room;
        int count = await room.EnterAsync(remote.RoomMembership);
        // ... 입장 실패하면 방을 다시 삭제(롤백)
    }
}

⑤메모리 재활용 — GC에게 일 안 주기

용어한 번 더 짚고 가기

잠깐 이 서버 밖으로 나와서, Room 기반 실시간 서버가 일반적으로 어떤 형태를 지향하는지 살펴봅니다. 핵심 키워드는 두 개입니다 — 방별 격리(per-room isolation), 그리고 그 격리를 구현하는 대표 패턴인 액터(Actor) 모델.

개념Actor 모델이란?

Room을 하나의 Actor로 만들면, 방마다 전용 우편함 + 처리 루프 + 자기 상태를 갖습니다. 같은 방에 이벤트가 아무리 몰려도 순서대로 하나씩 처리되니, 방 안의 게임 상태를 레이스(race) 걱정 없이 마음껏 바꿀 수 있습니다.

이유왜 게임 방에 잘 맞을까

• 락 없는 안전성 — 직렬 처리라 방 내부 상태 변경에 자물쇠가 필요 없다.
• 장애 격리 & 감독(supervision) — 한 방이 죽어도 그 방만 재시작. Erlang의 “let it crash” 철학.
• 위치 투명성 & 샤딩 — 방은 어느 노드에 있든 주소로 접근 가능하고, 방 단위로 노드에 흩뿌려 수평 확장한다.

사례업계에서 쓰는 것들

비교그래서 DefenceSocketServer는 Actor 모델인가?

절반만 그렇습니다. “방을 독립 상태 단위로 격리한다”는 목표는 공유하지만, 그 방식은 정통 액터 모델과 다릅니다.

§06에서 이 서버의 lock-free를, §07에서 Actor(직렬 처리)를 봤습니다. 사실 이 둘은 실무 락 관리의 스펙트럼 양 끝입니다. “락을 최대한 잘게 쪼개기”부터 “아예 락이 필요 없게 만들기”까지, 실시간 서버가 흔히 쓰는 방법들을 한 줄에 세워보겠습니다.

스펙트럼락을 다루는 6가지 층위

함정async 환경 — 일반 lock은 await를 못 넘는다

실무락 관리 황금률 (체크리스트)

• 임계구역은 짧게, 락 잡고 I/O 금지 — 락을 쥔 채 네트워크·DB를 await하면 그 락이 “느린 락”이 되어 전체를 마비시킨다.
• 락 순서를 고정 — 여러 락을 잡을 땐 항상 같은 순서로. 순서가 엇갈리면 데드락.
• 직접 짜기 전에 표준 도구부터 — ConcurrentDictionary·Channels·Immutable*가 이미 검증된 락 관리를 대신해 준다.
• 읽기:쓰기 비율로 고르기 — 읽기가 압도적이면 RW락/불변 스냅샷, 쓰기 경합이 심하면 샤딩/직렬화.
• 최고의 락 관리는 “공유 상태 줄이기” — 상태를 소유자 하나로 격리하면(Actor·샤딩) 락 자체가 사라진다.

종합그래서 이 서버는? — 경로별로 다르게 쓴다

정답은 “한 가지로 통일”이 아니라 “경로마다 특성에 맞는 전략을 섞는 것”입니다. 이 서버가 교과서적으로 그렇게 하고 있습니다.

암호화는 AES-CBC 하나로 통일하되, 용도(스코프)별로 IV를 따로 둡니다. 열쇠(Key)는 프로세스 전체가 공유하는 하나뿐이고, IV는 채널마다 다르게 관리됩니다.

핸드셰이크 응답이 암호 통신의 시작점입니다. 서버가 열쇠와 공용 IV를 평문으로 내려준 뒤부터, 모든 통신이 암호화됩니다.

public class HandshakeA : Protocol{
    public override KeyIndex KeyIndex { get; } = KeyIndex.None;  // 평문으로 보냄
    [Key(1)] public bool   VersionOk { get; set; }
    [Key(2)] public byte[] Key       { get; set; }   // AES 열쇠 전달
    [Key(3)] public byte[] CommonIv  { get; set; }   // 공용 IV 전달
}

게임용 WebSocket과 별도로, HTTP 서버가 운영자용 확인 창구를 제공합니다. 미들웨어 Route가 URL 경로를 IRoute 구현체로 연결합니다.

배포

deploy.sh는 dotnet publish로 런타임 포함 단일 실행파일(self-contained, linux-x64)을 만들어 tar로 묶고 대상 서버로 보냅니다. CI는 Jenkins(Ubuntu 24.04 + .NET SDK 10).

dotnet publish ${PROJ_PATH} \
  --output ${BIN_DIR} --runtime linux-x64 \
  --configuration Release --self-contained \
  --property:PublishSingleFile=true

시니어 면접에서는 “무엇을 잘했나”보다 “무엇을 일부러 포기했나”가 더 중요합니다. 이 서버가 의도적으로 감수한 트레이드오프들입니다.

§11이 “일부러 포기한 것”이라면, 여기는 “지금 코드에서 개선하면 좋을 것”과 “다음 단계로 발전시킬 방향”입니다. 면접에서 “이 서버를 맡으면 뭘 먼저 하겠나?”라는 질문에 그대로 답이 되는 내용입니다.

아쉬운 점 — 지금 코드에서 눈에 밟히는 것들

발전 방향 — 우선순위별 로드맵

위 내용을 근거로, 시니어 레벨에서 나올 법한 질문과 모범 답변 뼈대입니다. 펼쳐서 확인하세요.