AWS GameLift와 Serverless로 구현하는 매칭 백엔드 아키텍처 (3부) — FlexMatch Rule Set을 구성해보자

Jong Ha Shin
8 min readJan 13, 2025

--

AWS GameLift와 Serverless로 구현하는 매칭 백엔드 아키텍처 (2부) — WSS연결로 매칭 요청/취소 처리하기에서 이어집니다.

들어가며

GameLift FlexMatchAWS GameLift에서 제공하는 매칭 관리형 서비스로, 별도의 매칭 서버를 직접 구성하지 않고도 매칭 로직을 손쉽게 적용할 수 있다는 장점이 있습니다.
WILD BOWL : ZOOPORTS 프로젝트에서는 베타 단계에 빠르게 매칭 기능을 구축해야 했기 때문에, 유저풀(플레이어 수)이 적은 초기 상태에서도 간단하게 동작하는 매칭 Rule Set을 마련하고, 향후 필요에 따라 확장 가능한 구조를 갖추고자 했습니다.

이번 글에서는 3vs3 대전을 기준으로 작성된 Rule Set 예시를 공유하며, FlexMatch가 어떻게 팀 구성 및 조건을 맞춰주는지 알아보겠습니다.

왜 FlexMatch를 선택했는가?

  • 라이브 서비스 초기부터 직접 매칭 서버를 구현하는 경우, 매칭 로직 개발과 서버 운영에 상당한 리소스가 소요됩니다. 저희 팀은 작은 팀이어서 여기에 많은 리소스를 추가하기는 쉽지 않았습니다.
  • GameLift FlexMatch를 활용하면, StartMatchmaking 호출로 큐에 유저를 넣고, FlexMatch가 팀 편성과 매칭 규칙 적용을 알아서 해줍니다.
  • 게임 초기에는 디테일한 매칭 규칙(예: 레벨이나 스킬 기반의 정교한 매칭)까지 필요치 않았고, “3명씩 두 팀을 꾸려서 빠르게 매칭”이 목표였습니다. 이후 유저풀이 늘어나면 Rule Set에 새 규칙(예: 레벨 차이 제한)을 추가하거나 수정할 수 있습니다.

FlexMatch Rule Set 구성 요소

아래 예시는 실제 프로젝트에서 사용했던 3vs3 매칭용 Rule Set입니다. JSON 형식으로 작성하며, GameLift 콘솔이나 AWS CLI를 통해 업로드/등록할 수 있습니다.

{
"name": "zooports_3on3",
"ruleLanguageVersion": "1.0",
"playerAttributes": [
{
"name": "level",
"type": "number"
},
{
"name": "position",
"type": "string"
}
],
"teams": [
{
"name": "HOME",
"minPlayers": 3,
"maxPlayers": 3
},
{
"name": "AWAY",
"minPlayers": 3,
"maxPlayers": 3
}
],
"rules": [
{
"name": "HomeUniquePositions",
"description": "Each player in a team must have a unique position",
"type": "comparison",
"measurements": [
"teams[HOME].players.attributes[position]"
],
"operation": "!="
},
{
"name": "AwayUniquePositions",
"description": "Each player in a team must have a unique position",
"type": "comparison",
"measurements": [
"teams[AWAY].players.attributes[position]"
],
"operation": "!="
}
],
"expansions": [
{
"target": "teams[HOME].minPlayers",
"steps": [
{
"waitTimeSeconds": 2,
"value": 2
},
{
"waitTimeSeconds": 4,
"value": 1
}
]
},
{
"target": "teams[AWAY].minPlayers",
"steps": [
{
"waitTimeSeconds": 2,
"value": 2
},
{
"waitTimeSeconds": 4,
"value": 1
},
{
"waitTimeSeconds": 6,
"value": 0
}
]
}
]
}

Rule Set 살펴보기

기본 정보

"name": "zooports_3on3",
"ruleLanguageVersion": "1.0",
  • name: Rule Set의 이름입니다.
  • ruleLanguageVersion: 현재는 1.0 버전을 주로 사용합니다. (추후 AWS가 새 버전을 릴리스할 수 있으니 문서를 참고해야 합니다.)

playerAttributes (플레이어 속성 정의)

"playerAttributes": [
{
"name": "level",
"type": "number"
},
{
"name": "position",
"type": "string"
}
],
  • 매칭에 고려할 유저 속성들을 정의합니다.
  • 예) level: 숫자 타입(유저 레벨), position: 문자열(유저 역할군).
  • 이 속성 정보는 StartMatchmaking을 호출할 때 PlayerAttributes로 전달되어, FlexMatch가 매칭 규칙에 반영하게 됩니다.

teams (팀 설정)

"teams": [
{
"name": "HOME",
"minPlayers": 3,
"maxPlayers": 3
},
{
"name": "AWAY",
"minPlayers": 3,
"maxPlayers": 3
}
],
  • HOME 팀과 AWAY 팀을 각각 정의하고, 필요한 플레이어 수(최소/최대)를 설정합니다.
  • 이 예시에서는 3명씩 두 팀, 즉 “3vs3” 구성을 전제로 합니다.

rules (매칭 규칙)

"rules": [
{
"name": "HomeUniquePositions",
"description": "Each player in a team must have a unique position",
"type": "comparison",
"measurements": [
"teams[HOME].players.attributes[position]"
],
"operation": "!="
},
{
"name": "AwayUniquePositions",
"description": "Each player in a team must have a unique position",
"type": "comparison",
"measurements": [
"teams[AWAY].players.attributes[position]"
],
"operation": "!="
}
],
  • Rule Set이 어떤 로직으로 매칭을 구성할지를 지정합니다.
  • 여기서는 팀 내에서 position 값이 겹치지 않도록(예: 라인맨, 쿼터백, 러닝백) 하는 규칙만 두었습니다.
  • 유저풀이 적기 때문에, 레벨(강한 vs 약한 플레이어 차이)을 아직 고려하지 않았고, 추후 필요해지면 규칙에 추가할 계획이었습니다.

expansions (확장 단계)

"expansions": [
{
"target": "teams[HOME].minPlayers",
"steps": [
{
"waitTimeSeconds": 2,
"value": 2
},
{
"waitTimeSeconds": 4,
"value": 1
}
]
},
...
]
  • 매칭 대기 시간이 길어질수록, 해당 값들을 단계적으로 완화합니다.
  • 예를 들어 HOME 팀의 minPlayers를 3명에서 2명, 더 나아가 1명으로 줄이는 식입니다.
  • 최종적으로는 AI를 투입하거나, 여러 조건(예: 레벨 차이, 포지션 규칙 등)을 완화해 매칭을 성사시키기 위함입니다.
  • 실제로 유저풀이 많을 때는 확장 설정을 보수적으로 적용하거나, 아예 끄기도 합니다.

마치며

FlexMatch를 이용하면 간단한 JSON Rule Set만 작성해도 팀 구성 규칙과 확장 단계를 쉽게 설정할 수 있습니다. 직접 매칭 서버를 만들 필요가 없기 때문에, 빠른 개발이 필요한 베타 단계나 소규모 인디 프로젝트에 매우 유용합니다.

다만 본 예시처럼 단순한 규칙(포지션 겹치지 않기, 3 vs 3 팀 구분)만 다룬 경우, 유저 풀이 많지 않으면 공정성이 떨어질 수 있습니다. 또한 게임이 성장해 더 정교한 매칭 로직(레벨 차이 제한, MMR 기반 등)이 필요해지면, Rule Set에 새로운 규칙을 추가하거나 여러 단계로 확장해 나갈 수 있습니다.

다음 포스팅에서는 FlexMatch가 매칭에 성공하거나 실패했을 때 발생하는 이벤트를 백엔드가 어떻게 받고, 클라이언트에게 알리는지 다룰 예정입니다. 궁금한 점이 있으시다면 편하게 댓글이나 문의를 남겨주세요.

감사합니다!

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

No responses yet

Write a response