[종합 프로젝트] 게임 내 스텟 로직에 관련된 고민

스텟 관련 ERD

 

1. 초기 세팅에 관한 고찰

 

현재 게임 내 스텟은 다음과 같이 설정해놓았다.

 

캐릭터 정보에 있는 스텟(힘,의지,운 등등) 은 우리가 레벨업을 할 때마다 스텟 증가 포인트를 얻고 직접 올릴 수 있는 수치이다.

 

반대로 race_tpye 테이블에 있는 체력, 마나, 물리공격력 등등의 스텟은 유저가 별도로 조작할 수 있는게 아닌 유저가 올린 스텟값

 

의해 계산후 결정되는 값이다.

 

그래서 우리는 계산 값 자체를 DB에 저장할 경우 DB에 저장되는 값도 너무 많아질 뿐더러 게임에서는 벨런스 패치가 빈번하게 발

 

생한다. 만약 DB에 계산된 값을 저장할 경우 계산 로직이 바뀌면 지금까지 저장된 값들을 전부 다시 계산에서 업데이트를 해야하는 

 

불상사가 발생한다.

 

따라서 우리는 TEXT 형식으로 계산 식만 가지고 있고 수치가 필요할 시 캐릭터 정보에서 필요한 값과 식을 가지고 연산하는 방식을

 

채택하였다.

 

 

 

2. 유저수가 많아졌을 경우 문제점

 

이렇게 설계를 하고 스크럼을 진행 중 유저 수가 많아질 경우 매번 연산을 하면 연산 횟수가 너무 많아져서 문제가 생기지 않을까 라

 

는 좋은 지적을 받았다.

 

그래서 DB에 저장하는 방식과 실시간 계산을 하는 방식을 다시 고려해보고 현재 게임 개발에서는 어떠한 방식을 채택하는지 조사해

 

보았다.

 

 

 

3. 실시간 계산 방식 (요청 시 계산)

 

개념: 캐릭터의 기본 스탯(레벨업 시 증가시키는 능력치 등)은 DB에 저장해 두고, 물리공격력/마법공격력/회피율 등의 파생 능력치는 공식만 관리하여 필요할 때 계산하는 방식이다. 예를 들어 게임 시작 시나 스탯 창을 열 때 현재의 기본 스탯과 장비 등을 바탕으로 공격력, 방어력 등을 실시간으로 계산하는 구조이다.

• 장점: 밸런스 공식(수식)을 중앙에서 관리하기 때문에 추후 밸런스 패치 시에도 공식을 수정하기만 하면 전체 게임에 바로 적용됩니다. 개별 캐릭터의 데이터를 일일이 수정할 필요가 없어 유연한 조정이 가능하다.  또한 계산은 필요할 때만 수행되므로, 불필요한 중복 저장을 피할 수 있다. 한 개발자도 “최대 HP 같은 값을 매번 계산할 필요 없이 변경될 때만 업데이트하고 평소에는 저장해둔 값을 참조하면 된다”라고 조언한다. 이처럼 스탯이 변동되는 시점에만 계산하면 되므로, 잘 관리하면 성능 부담이 크지 않는다.
• 단점: 사용자 수가 매우 많아지면 동시에 계산 요청이 늘어날 수 있다. 공식이 복잡하거나 계산 빈도가 높다면 서버 CPU 부하가 증가할 우려도 있다. 다만 일반적으로 간단한 산술 공식의 계산 비용은 크지 않으며, 네트워크나 DB I/O보다 훨씬 저렴한 작업이다. 더욱이 실시간 계산 방식도 최적화를 통해 성능 문제를 완화할 수 있다. 예를 들어 여러 변화가 겹치는 경우 이벤트/더티 플래그를 활용하여 한 번만 일괄 재계산하도록 할 수 있다. 스탯 변화가 있을 때마다 해당 캐릭터의 스탯을 “Dirty” 상태로 표시하고, 필요 시 한 번만 공식 적용해서 업데이트하는 식이다. 이렇게 하면 여러 번의 중복 계산을 방지하여 성능 이슈를 줄일 수 있다.

 

 

 

4. DB 저장 방식 (파생 스탯 사전 저장)

 

개념: 모든 파생 능력치(물리공격력, 마법공격력, 회피율 등)을 미리 계산하여 DB에 저장해 두는 방식이다. 캐릭터가 레벨업을 하거나 장비를 변경할 때마다 해당 캐릭터의 공격력, 방어력 수치를 즉시 재계산해서 DB에 업데이트하고, 게임 내에서는 DB에 저장된 값을 그대로 조회한다.

• 장점: 조회 속도 면에서 이점이 있다. 게임 중에 스탯을 표시하거나 전투 계산을 할 때 DB에서 이미 계산된 값을 읽어오기만 하면 되므로, 별도의 연산 없이 빠르게 사용할 수 있다. 즉, 클라이언트나 서버가 추가 계산을 수행하지 않고도 현재 능력치를 얻을 수 있으므로 구현이 단순해질 수 있다. 또한 한 번 계산한 값을 여러 곳에서 재사용한다는 점에서는, 잘만 구현하면 일종의 캐싱 효과를 얻어 중복 연산을 피하는 장점도 있다.
• 단점: 데이터 일관성 유지와 부하 측면에서 어려움이 있다. 캐릭터의 기본 스탯이 변동될 때마다 관련된 모든 파생 능력치를 즉각 DB에 갱신해야 하므로, 업데이트 작업이 빈번해질 수 있다. 이는 DB 부하로 이어질 수 있으며, 동시 접속자가 많을 경우 실시간 계산보다 오히려 병목이 될 수 있다. 또한 밸런스 공식이 바뀔 경우 문제가 커지는데, 예를 들어 공격력 계산식이 패치로 변경되면 모든 캐릭터의 DB 저장값을 다시 계산해 업데이트해야 한다. 이러한 작업은 매우 번거롭고, 누락 시 데이터 불일치가 발생할 위험도 있다. 게임 업계에서도 중복 데이터 저장은 최소화하는 추세이며, 주요 온라인 게임들은 아이템이나 능력치의 원본 데이터만 관리하고 개별 캐릭터의 최종 능력치는 로그인 시 계산하는 방식을 채택하고 있다. 예를 들어, 어떤 MMO에서 전설 아이템의 공격력 수치는 게임의 공통 데이터로만 관리하고, DB에는 플레이어가 해당 아이템을 장착하고 있다는 정보(ID) 만 저장해 둔다. 캐릭터가 로그인하면 서버가 그 아이템 ID를 참고하여 아이템의 스펙을 불러온 뒤 공격력을 산출하는 식이다. 이렇게 하면 아이템이나 공식이 바뀌어도 DB 데이터를 일일이 수정하지 않고도 모든 캐릭터의 능력치에 변화를 반영할 수 있다.

 

5. GPT 피셜 권장 방안 및 실제 게임 개발 사례

종합하면, 하이브리드 접근 방식을 권장합니다. 기본 스탯과 장비 등의 정보는 DB에 저장하여 영구 보관하되, 파생 능력치는 게임 서버 메모리상에서 관리하는 것입니다. 게임 서버는 플레이어 로그인이나 던전 입장 시 한 번 캐릭터의 현재 능력치를 모두 계산하여 메모리에 저장해 놓을 수 있습니다. 그 이후에는 플레이어 본인 또는 팀원이 스탯을 조회할 때 미리 계산된 값을 바로 보여주면 되므로, 불필요한 반복 계산이 제거됩니다. 현재 질문하신 TRPG 초기 단계처럼 게임 중간에 스탯이 변하지 않는다면, 이러한 초기 1회 계산 + 캐싱 전략으로도 충분합니다. 반대로 레벨업이나 장비 변화 등의 이벤트가 발생하면, 그 시점에만 다시 계산해서 업데이트하면 됩니다. 실제 많은 온라인 게임들이 접속 중인 플레이어의 데이터를 메모리에 유지하고 필요 시에만 DB와 동기화합니다. 예를 들어 온라인 상태에서는 메모리로 빠르게 처리하고 로그아웃 시점에만 DB에 저장함으로써, 게임 진행 중에는 DB 부하를 최소화하는 방식을 취합니다.

요약: 파생 스탯 값을 DB에 모두 저장하는 것은 일반적으로 비효율적입니다. 현재 업계 표준은, DB에는 최소한의 기본 정보만 저장하고 실제 전투나 표시용 능력치는 런타임에 계산하는 방식입니다. 성능 최적화를 위해서는 “스탯이 변할 때만 계산”하는 이벤트 기반 처리와 캐싱을 활용하세요. 이렇게 하면 밸런스 조정의 유연성을 유지하면서도, 많은 유저가 있어도 성능 문제를 피할 수 있을 것입니다.

 

 

 

7. 결론

 

연산 식을 저장해두고 게임 실행 시 캐싱 시스템을 이용해서 최초 1회 연산 이후 스텟에 변경사항이 있을 경우만 재연산을 한다.

 

단 현재 MVP 단계이기 때문에 캐싱 시스템은 추후 구현할 예정