AI로 구현하기

마인크래프트 BE 도구 품질 시스템은 어떻게 원하는 조건으로 바로 테스트할 수 있을까?

도안 2026. 9. 28. 16:52

 

앞선 글에서는 두 번의 실패와 세 번째 수정 끝에 공격력, 공격력 비율, 치명타 같은 도구 특성이 실제 전투에 정상적으로 적용되도록 만드는 과정을 정리했습니다.

 

전투 계산 자체는 이제 원하는 방향으로 작동하기 시작했습니다. 하지만 개발을 계속하려고 하니 다른 불편함이 눈에 들어왔습니다.

이번에는 기능 자체의 오류가 아니라 기능을 테스트하는 과정이 너무 번거롭다는 문제였습니다.

 

도구 품질 시스템은 제작했을 때 품질과 특성이 무작위로 결정되는 구조였습니다. 실제 플레이에서는 필요한 구조지만, 개발 중 특정 조건만 확인하고 싶을 때는 오히려 방해가 됐습니다.

 

그래서 원하는 특성과 수치를 직접 입력해 즉시 테스트할 수 있는 별도의 디버그 기능을 만들어보기로 했습니다.

 

 

두 번의 실패 끝에 마인크래프트 BE 도구 품질 시스템은 어떻게 정상 작동하게 됐을까?

앞선 글에서는 공격력 특성이 실제 전투에 적용되지 않는 문제를 해결하기 위해 두 번의 수정과 테스트를 반복한 과정을 정리했습니다. 처음에는 계산식 자체가 문제라고 생각했지만, 디버그를

buildtheidea.tistory.com

 

 

 

 

 

무작위 특성은 실제 플레이에는 좋지만 테스트에는 불편했다

품질 시스템에서는 도구를 만들면 품질뿐 아니라 여러 특성도 무작위로 결정됩니다.

 

예를 들어 어떤 검에는 공격력 증가가 붙을 수 있고, 다른 검에는 공격력 비율이나 치명타 확률이 붙을 수 있습니다.

 

실제 플레이에서는 같은 재료의 도구라도 서로 다른 결과가 나오는 것이 이 시스템의 중요한 특징입니다.

하지만 테스트할 때는 이야기가 달라졌습니다.

 

예를 들어 공격력 +100 인 검이 실제로 어떻게 작동하는지 확인하거나,

치명타 확률 +100% 상태에서 모든 공격이 치명타로 처리되는지를 확인하고 싶다고 가정해봤습니다.

 

 

기존 방식이라면 원하는 특성과 수치가 붙은 도구가 나올 때까지 계속 제작해야 합니다.

 

공격력 비율만 시험하고 싶은데 다른 특성이 함께 붙을 수도 있고, 원하는 수치가 바로 나오지 않을 수도 있습니다.

즉 테스트하려는 기능은 하나인데 테스트 조건을 만드는 데 불필요한 시간이 계속 들어가는 구조였습니다.

 

앞선 전투 시스템 수정에서도 치명타 확률을 크게 올려 확실하게 기능을 검증하는 방식이 필요했습니다.

그렇다면 아예 테스트할 때만 원하는 수치를 직접 넣을 수 있게 만드는 편이 더 효율적이라고 생각했습니다.

 

 

 

 

현재 들고 있는 도구의 특성을 직접 바꿀 수 있게 했다

그래서 별도의 테스트용 설정 기능을 추가했습니다.

방식은 단순하게 잡았습니다.

 

먼저 테스트할 도구를 손에 든 뒤 채팅창에 /toolq:debug를 입력합니다.

 

그러면 현재 들고 있는 도구의 특성을 직접 조정할 수 있는 도구 품질 테스트 설정 창이 열립니다.

 

 

 

설정창에서는 당시 테스트가 필요했던 주요 수치를 직접 조정할 수 있도록 했습니다.

고정 공격력,
공격력 비율,
치명타 확률,
치명타 피해,
이동 속도,
작업 속도

 

까지 총 여섯 가지입니다.

 

 

각 항목은 슬라이더 형식으로 조절할 수 있게 했습니다.

 

중요한 점은 설정창을 열었을 때 현재 들고 있는 아이템의 값이 먼저 표시된다는 것입니다.

아무 값도 없는 상태에서 처음부터 다시 입력하는 것이 아니라, 현재 아이템의 상태를 확인하면서 필요한 부분만 바꿀 수 있습니다.

 

 

 

 

 

 

테스트용이라 수치 범위도 넓게 잡았다

일반적인 플레이에서 공격력 +100이나 이동 속도 +100% 같은 값이 붙을 필요는 없습니다.

하지만 이 기능의 목적은 밸런스가 아니라 기능이 실제로 작동하는지를 빠르게 확인하는 것입니다.

 

그래서 테스트용 설정에서는 일반적인 특성 범위보다 훨씬 넓은 값을 입력할 수 있도록 했습니다.

 

예를 들어 공격력은 -100 ~ 100처럼 넓게 조정할 수 있게 했고, 공격력 비율이나 치명타 피해는 일반적인 게임 플레이에서는 사용할 일이 없는 수준까지 시험할 수 있게 했습니다.

이렇게 하면 작은 차이를 여러 번 비교하지 않아도 됩니다.

 

공격력 증가가 실제 피해에 연결되는지 확인하고 싶다면 값을 크게 올린 뒤 바로 공격해보면 되고,

치명타 확률이 정상인지 확인하려면 100%로 설정해 모든 공격에서 치명타가 발생하는지 보면 됩니다.

반대로 음수 값도 사용할 수 있기 때문에 불이익 특성이 제대로 작동하는지도 같은 방식으로 확인할 수 있습니다.

 

정상적인 밸런스 범위를 일부러 벗어난 값을 사용하면서 기능의 작동 여부를 먼저 확실하게 확인하는 테스트 도구로 만든 것입니다.

 

 

 

 

 

 

적용하면 현재 아이템에 바로 반영되도록 했다

설정창에서 값을 바꾼 뒤 적용하면 새 아이템을 다시 제작할 필요가 없습니다.

현재 손에 들고 있는 아이템에 변경한 값이 바로 저장되도록 했습니다.

 

테스트 중에는 일반 도구와 혼동하지 않도록 아이템 이름도 테스트 도구로 구분했고, Lore에서는 직접 설정한 특성 값을 확인할 수 있게 했습니다.

 

예를 들어 공격력을 크게 올리고 치명타 확률을 추가하면 테스트 도구의 Lore에서도 해당 값이 표시됩니다.

 

 

이 상태에서 바로 몹을 공격하면 됩니다.

 

 

그러면

설정창에서 입력한 값,
아이템 Lore에 표시된 값,
디버그에서 계산되는 값,
실제로 몹이 받는 피해

 

를 한 번에 비교할 수 있습니다.

이전처럼 원하는 조합이 나올 때까지 계속 도구를 제작할 필요가 없어졌습니다.

 

 

 

 

 

 

테스트 도구가 다시 무작위로 바뀌지 않게 하는 것도 필요했다

여기서 한 가지 더 고려해야 할 부분이 있었습니다.

기존 품질 시스템에는 품질이 없는 일반 도구를 감지하면 자동으로 품질과 특성을 부여하는 구조가 있었습니다.

그렇다면 테스트 설정으로 값을 직접 바꾼 뒤에도 기존 자동 판정이 다시 실행되면 문제가 생길 수 있습니다.

 

방금 직접 설정한 값이 다시 무작위 특성으로 덮어써질 수도 있기 때문입니다.

그래서 테스트용으로 직접 수정한 아이템에는 내부적으로  테스트 진행중이라는 상태 표시를 남겨, 기존 자동 품질 부여 시스템이 다시 덮어 쓰지 않도록했습니다.

 

이 기능은 단순히 설정창만 만드는 것으로 끝나는 문제가 아니었습니다.

기존 랜덤 품질 시스템은 그대로 유지하면서도, 테스트 모드에서 직접 바꾼 아이템만 예외로 처리해야 했습니다.

 

실제 플레이 시스템과 개발용 테스트 기능이 서로 방해하지 않도록 분리한 것입니다.

 

 

 

 

 

 

 

액션바 디버그도 필요할 때만 볼 수 있게 했다

앞선 전투 테스트에서는 공격할 때 화면 아래쪽 액션바에 계산 결과를 표시했습니다.

 

예를 들어

기본 피해,
고정 공격력,
공격력 비율,
치명타 확률,
치명타 피해,
치명타 성공 여부,
최종 피해

 

같은 값을 직접 확인할 수 있었습니다.

 

 

이 디버그 정보는 문제를 찾을 때는 매우 유용했습니다.

하지만 전투 시스템이 정상적으로 작동한 뒤에도 항상 화면에 표시되면 실제 플레이를 확인할 때는 오히려 방해가 됩니다.

 

그래서 액션바 디버그 역시 별도의 명령으로 켜고 끌 수 있게 했습니다.
/toolq:debugtoggle을 입력하면 디버그 출력이 ON과OFF 사이에서 전환되도록 했습니다.

 

 

테스트할 때는 켜서 계산 과정을 확인하고,

일반적인 플레이 모습이나 다른 기능을 확인할 때는 꺼둘 수 있게 한 것입니다.

 

 

 

 

 

 

기능을 고치는 것만큼 테스트 환경을 만드는 것도 중요했다

처음 품질 시스템을 구현할 때는 테스트 기능까지 따로 필요할 것이라고 생각하지 않았습니다.

도구를 만들고 직접 사용해보면 충분하다고 생각했습니다.

 

하지만 실제로 여러 번 오류를 수정해보니 테스트해야 할 조건이 점점 세분화됐습니다.

 

  • 공격력 증가만 확인해야 할 때도 있고,
  • 공격력 비율만 확인해야 할 때도 있었고,
  • 치명타 확률과 피해를 각각 따로 시험해야 할 때도 있었습니다.

 

이런 상황에서 모든 조건을 무작위 제작에 의존하면 코드 수정보다 테스트 준비에 더 많은 시간이 들어갈 수 있습니다.

그래서 이번에는 새로운 플레이 기능을 추가하기보다 앞으로의 개발을 더 빠르게 진행하기 위한 테스트 환경 자체를 먼저 개선했습니다.

 

원하는 도구를 손에 들고, /toolq:debug로 필요한 수치를 직접 지정한 뒤,
바로 게임 안에서 결과를 확인하고, 필요하다면 액션바 디버그까지 켜 계산 과정과 실제 결과를 비교할 수 있게 된 것입니다.

 

 

 

 

 

 

 

무작위 시스템일수록 원하는 조건을 재현할 방법이 필요했다

품질 시스템에서 무작위 요소를 없앤 것은 아닙니다.

실제 플레이에서는 여전히 제작할 때 품질과 특성이 무작위로 결정되는 것이 기본입니다.

 

이번에 만든 설정창은 그 규칙을 바꾸기 위한 기능이 아니라 개발 중에 원하는 상황을 빠르게 재현하기 위한 별도의 도구였습니다.

결과적으로 테스트 과정은 원하는 특성이 나올 때까지 반복 제작하는 방식에서 원하는 값을 직접 입력하고 즉시 확인하는 방식으로 바뀌었습니다.

 

전투 시스템을 여러 번 수정하면서 디버그 정보의 필요성을 알게 됐다면, 이번에는 거기에서 한 단계 더 나아가 테스트 조건 자체도 직접 만들 수 있도록 한 것입니다.

기능 하나를 구현하는 것뿐 아니라 그 기능을 반복해서 확인하기 쉬운 환경을 만드는 것도 개발 과정의 중요한 부분이라는 것을 이 단계에서 확인할 수 있었습니다.

이번 작업을 통해 기능을 구현하는 것만큼, 같은 기능을 빠르게 반복 검증할 수 있는 테스트 환경을 만드는 것도 중요하다는 점을 알게됐습니다.