마인크래프트 BE 품질 시스템을 확장하는 과정에서 어떤 오류가 생겼을까?

앞선 글에서는 검과 작업 도구에만 적용하던 품질 시스템을 활, 석궁, 갑옷까지 확장하기 위해 어떤 규칙을 먼저 정했는지 정리했습니다.

기존에 정상 작동하던 기능은 최대한 유지하면서 활과 석궁의 전투 특성, 갑옷 4부위의 능력치 합산, 네더라이트 장비로의 품질 계승까지 새롭게 기획했습니다.

 

기획 범위가 정리된 뒤에는 다시 구현 담당에게 인수인계 문서를 넘겼습니다.

이번에는 기능 하나를 조금 수정하는 수준이 아니라 기존 품질 시스템의 적용 범위를 크게 넓히는 작업이었습니다.

 

그런데 구현된 확장판을 실제 마인크래프트 BE에서 확인해보니 예상과 다른 문제가 생겼습니다.

새로 추가한 기능을 하나씩 테스트하기도 전에 스크립트 자체가 정상적으로 시작되지 않을 수 있는 오류가 들어가 있었습니다.

 

 

마인크래프트 BE 도구 품질 시스템을 다른 장비까지 확장하려면 무엇을 정해야 할까?

 

 

 

 

 

확장 기능 자체는 코드에 들어가 있었다

구현 담당에게 넘긴 확장 기획에는 추가해야 할 내용이 상당히 많았습니다.

 

활과 석궁에는 기존 검과 비슷한 전투 특성을 적용하고,

화살을 발사한 순간의 장비 정보를 저장해 명중할 때 사용하며,

갑옷에는 방어력과 이동 속도 특성을 추가하고, 착용하고 있는 4부위의 값을 합산해 실제 효과로 연결하도록 했습니다.

 

 

기존 다이아몬드 장비를 네더라이트로 업그레이드했을 때 품질과 특성을 그대로 이어주는 기능도 포함됐습니다.

구현된 코드를 다시 분석해보니 이런 확장 방향 자체가 전부 잘못된 것은 아니었습니다.

 

활과 석궁의 품질 생성과 전투 특성 구조, 화살별 능력치 저장 방식, 갑옷의 방어력과 이동 속도 합산 구조 등은 이미 들어가 있었습니다.

 

즉 이번 문제는 기획한 확장 기능 아예 만들지 구현되지 않은 경우와는 달랐습니다.

 

코드 안에는 상당수 기능이 들어가 있었지만, 그 기능들을 실제 게임에서 제대로 실행하기 전에 더 앞쪽에서 문제가 발생하고 있었습니다.

 

 

 

확장 기능보다 먼저 스크립트 구조를 확인해야 했다

새 기능이 많아지면 처음에는 각각의 기능을 의심하기 쉽습니다.

활 품질 생성이 잘못됐는지
갑옷 감지가 되지 않는지
새 명령어 등록이 문제인지
혹은 기존 시스템과 충돌한 것인지

 

확인해야 할 범위가 넓어집니다.

 

 

하지만 이런 상황에서는 개별 기능을 하나씩 수정하기 전에 스크립트가 정상적으로 로드되고 있는지부터 확인해야 했습니다.

그래서 실제 구현물을 다시 구체화 담당에게 넘겨 문제를 분석했습니다.

 

그 과정에서 가장 먼저 발견된 것은 전투 계산이나 갑옷 합산처럼 복잡한 부분이 아니었습니다.

디버그 설정 기능과 관련된 함수 하나의 구조가 깨져 있었습니다.

 

 

 

기존 디버그 설정 함수의 선언부가 빠져 있었다

이전 글에서 테스트를 편하게 하기 위해 /toolq:debug 명령으로 도구의 특성을 직접 바꿀 수 있는 설정창을 만들었습니다.

확장판에서는 갑옷도 테스트해야 했기 때문에 갑옷용 디버그 설정 기능도 함께 추가됐습니다.

 

문제는 이 과정에서 발생했습니다.

 

갑옷용 디버그 함수가 끝난 뒤 기존 일반 도구용 디버그 코드가 이어졌는데, 그 앞에 있어야 할

function openDebugForm(player)라는 함수 선언이 빠져 있었습니다.

 

원래라면 구조가 대략 다음처럼 되어야 합니다.

openDebugArmorForm(player)와 openDebugForm(player)이 각각 독립된 함수로 존재해야 합니다.

 

그런데 일반 도구용 디버그 코드가 함수 안에 들어가지 못하고 바깥쪽에 놓이면서 문제가 생겼습니다.

 

 

 

 

 

함수 하나가 빠졌는데 왜 전체 시스템이 멈출 수 있었을까?

처음 보면 단순히 디버그 창 하나가 안 열리는 정도의 문제처럼 보일 수 있습니다.

 

하지만 실제로는 그렇지 않았습니다.

함수 내부에서 실행되어야 할 코드에는 player라는 값을 사용하는 부분이 있었습니다.

정상적인 함수라면 openDebugForm(player)를 호출하면서 전달받은 플레이어 정보를 사용하면 됩니다.

 

하지만 함수 선언 자체가 빠지면서 그 코드가 최상위 영역에 놓이게 되면, 그 위치에는 player라는 변수가 존재하지 않습니다.

그러면 player is not defined 같은 오류가 발생할 수 있습니다.

 

문제 수정 문서에서도 이 구조 때문에 스크립트 초기화 자체가 실패할 가능성을 가장 먼저 지적했습니다.

 

즉 새로 추가한 활이나 갑옷 기능이 잘못돼서 작동하지 않는 것이 아니라, 그 기능까지 도달하기도 전에

스크립트가 정상적으로 시작되지 못할 수 있었던 것입니다.

 

 

 

 

 

복잡한 확장 작업에서도 원인은 의외로 단순할 수 있었다

이번 확장에는 새로운 계산이 많이 들어갔습니다.

 

화살의 발사 시점 데이터를 저장해야 했고,

갑옷 4부위를 계속 확인해야 했으며, 이동 속도와 방어력도 여러 장비의 값을 합산해야 했습니다.

 

그래서 문제가 발생하면 자연스럽게 이런 새로운 시스템부터 의심하게 됩니다.

하지만 실제 첫 번째 원인은 훨씬 단순했습니다.

 

함수 선언 한 줄이 빠지면 원래 함수 안에 있어야 할 코드가 바깥으로 빠져나온 것이었습니다.

기능 수가 많아졌다고 해서 오류의 원인까지 반드시 복잡해지는 것은 아니었습니다.

 

 

오히려 코드가 길어질수록 작은 괄호 위치나 함수 선언 누락처럼 기본적인 구조 오류 하나가 전체 실행을 막을 수도 있었습니다.

 

 

 

 

 

다시 전체를 만드는 대신 문제가 생긴 부분만 수정하기로 했다

오류를 찾았다고 해서 확장판 전체를 다시 만들 필요는 없었습니다.

구체화 담당의 분석에서도 기존 검과 작업 도구 기능뿐 아니라 새로 추가한 활·석궁·갑옷 구조 중 상당 부분은 현재 방향을 유지해야 할 요소로 정리됐습니다.

 

그래서 수정 방향도 명확했습니다.

 

갑옷용 디버그 함수는 별도로 유지하고,

기존 일반 도구용 디버그 코드를 다시 openDebugForm(player) 함수 안에 정확하게 넣고,

두 함수가 서로 잘못 중첩되지 않았는지 확인하는 것입니다.

 

그리고 최상위 코드에서 player를 직접 참조하는 부분이 없는지도 다시 점검해야 했습니다.

수정 후에는 /toolq:debug와 갑옷용 디버그 명령이 각각 정상적으로 호출되는지도 확인하기로 했습니다.

 

핵심은 이미 구현된 확장 기능을 다시 만드는 것이 아니라 스크립트 실행을 막고 있던 구조적 오류부터 제거하는 것이었습니다.

 

 

 

 

 

 

기획 담당과 구현 담당 사이에 구체화 단계가 다시 필요해졌다

이번 과정에서도 이전과 비슷한 작업 흐름이 반복됐습니다.

 

처음에는 현재까지 만든 품질 시스템을 기획 담당에게 다시 넘겨 확장 방향을 정리했습니다.

그 기획을 인수인계 문서로 만들어 구현 담당에게 전달했고, 구현된 결과물을 다시 실제 마인크래프트에 적용해 확인했습니다.

 

문제가 생기자 이번에는 구현 담당에게 곧바로 다시 수정해달라고 하기보다, 결과물을 구체화 담당에게 넘겨 어떤 부분이 잘못됐는지 먼저 분석했습니다.

 

 

그 뒤 분석된 수정 사항을 다시 구현 담당에게 전달하는 방식으로 진행했습니다.

 

정리하면

기획  →  구현 →  실제 테스트  →  문제 분석  →  수정 지시  →  재구현의 흐름입니다.

 

 

한 대화에서 모든 문제를 한 담당에게 계속 이어가기보다, 문제가 생긴 단계에 맞춰 기획·구체화·구현 역할을 다시 나누는 방식이 이번 확장에서도 그대로 사용됐습니다.

 

 

 

 

확장할수록 새 기능보다 기존 구조를 먼저 확인해야 했다

품질 시스템의 적용 범위를 넓히면서 가장 먼저 만난 문제는 활의 피해 계산도, 갑옷의 방어력도 아니었습니다.

기존에 있던 디버그 기능을 확장하는 과정에서 함수 구조가 깨진 것이 첫 번째 문제였습니다.

 

이 경험을 통해 새 기능이 작동하지 않을 때는 그 기능의 계산식부터 고치는 것보다

스크립트가 정상적으로 시작됐는지, 함수와 변수의 범위가 올바른지, 기존 코드 구조가 깨지지 않았는지부터 확인해야한다는 점을 다시 확인할 수 있었습니다.

 

특히 이번처럼 기존 시스템 위에 여러 기능을 한꺼번에 추가할 때는 작은 구조 오류 하나가 새 기능 전체가 실패한 것처럼 보이게 만들 수도 있습니다.

 

우선 실행을 막는 문제는 찾았습니다.

하지만 확장판을 자세히 점검하면서 확인해야 할 부분은 이것 하나로 끝나지 않았습니다.

 

스크립트가 다시 정상적으로 실행되더라도 기존에 만들어둔 품질 아이템과 새로운 확장 시스템이 함께 사용될 때 문제가 생기지 않는지도 확인해야 했습니다.