Field's Nest

직교성의 말 풀이

직교란 말은 중학교 수학에서 봤듯이 90도의 각도로 두 선분이 만나는 것을 말한다.
이때 한 선분을 x, 다른 선분을 y라고 본다면 한 선분이 늘어나든 줄어들든 접점 자체에서 떨어지지 않는다면 두 선분이 직교한다는 사실 자체에는 변화가 발생하지 않는다...

아니다. 이런식으로 설명하면 더 헷갈릴테니 간단히 답부터 말하자. :-p

그러니까.....
 


서로간에 별로 큰 영향력이 없는 관계를 의미한다.

어떤 팀에서 뭘 잘못먹었는지 특정 퀘스트 수행 여부에 따라 공격력 수준이 큰 폭으로 변경되는 MMORPG를 하나 만들고 있다 치자.

이 게임에서 두 명의 기획자들이 별도로 작업을 들어가 한 명은 몹 컨텐츠를 맡아서 만들고, 한 명은 퀘스트 컨텐츠를 맡아서 제작을 하기 시작했다.

"이 퀘스트는 한 일주일 뒤 쯤에 자연히 다들 하게 되는 퀘스트야. 보통은 XX 레벨이 되면 하게 될 퀘스트니까 이 때쯤에 맞춰 몹들의 HP가 큰 폭으로 늘어나면 공격력이 늘어난 효과에 맞춰질거야!"

최초의 계획은 이랬고, 작업 자체는 별거 아니므로 프로그래머가 '갑자기 공격력이 퀘스트 하나 했다고 팍 늘어나면 뭐가 재미있는 거지?' 하면서도 그 기능을 때려 넣어 주었다.

근데 오픈베타 테스트 후 어느날 사장님이 잔뜩 찌푸린 얼굴로 담배를 피시다가 그 중 한명에게 말한다.

"..... A(기획자 중 한 명. 몹 컨텐츠 담당자 측)야. 아무래도 xx 마을(배치된 중요 퀘스트가 있는 곳) 주변에 좀 쎈 녀석들이 배치되어야 할거 같다. 애들이 주변이 다 똑같으니 심심하데."

A는 사장님 말씀이니까 가는 길에 그냥 지나칠 수 없을만큼 강한 몹을 때려 넣고 레벨 디자이너와 상의해 길의 배치도 조금 고쳐 두었다.
그러나 이미 B(퀘스트 컨텐츠 담당자)가 어느새 '이 중요한 퀘스트를 그냥 깨면 재미 없으니까 길찾기 노가다라도 좀 시키자!'는 말을 들어 두 지역 사이를 왔다가게 하는 동선을 추가한 뒤였고, 그들의 관리자는 '뭐든지 OK'의 부류였다.

결과물은?
마을로 갈 수도 없이 난이도가 올라간 곳을 두 번 거쳐 지나가야 하는 사태가 발생하게 된다.
퀘스트의 수행 여부가 강함의 지표가 되는데 지표가 될 퀘스트가 강한놈들에 방해를 받게 되는 상태 그대로 업데이트가 되어 버려 게시판은 폭주, 퀘스트 못깨먹겠다면서 동접 감소, 사장님이 불러서 '지금 대드는 거냐!' 훈계. :-p



물론 예시는 병맛 나긴 하지만......

좀 더 현실적인 예시는 뒤에 들겠지만, 직교적이지 못한 설계를 극단적인 형태로 보여주면 저런 형태가 된다.

전의 포스트에서 관리자가 세심한 부류일 경우의 내용을 언급했는데 이 경우도 마찬가지다. 두 사람을 붙잡아 놓고 갑자기 '회의'를 하게 된다. 결과물은 어쨌든 뭔가 여러가지를 고쳐야 하므로  제대로 나오긴 나오지만 3사람이 묶여버리고 세상에서 가장 불필요한 '회의'라는 놈을 하게 되는 과정에서 타임 루즈가 발생하고 앞으로 이런 사태가 오지 않게 하기 위해 '테스트'가 강조된다.(나중에 회의의 불필요함과 무작위 테스트의 문제점을 강조한 다른 포스트를 남기겠다.)

이런 식으로 상호 작용하는 내용이 많은 결정사항을, 우리는 '직교적이지 않다'고 말한다.

이걸 직교적인 형태로 바꾸려면?



직교적인 구조로 바꾸기 위해서 : 인터페이스를 제한한다.

애초에 양쪽에 대해 결정된 이유가 확실하다면, 서로간에 영향을 줄 부분(인터페이스)을 제한하고 그에 맞춰 구조를 짜면 된다.

위의 얼토당토 않은 예시에서는 몹 컨텐츠 담당자인 A에게 명확한 가이드라인인 'XX 퀘스트 주변에는 적이 너무 쎄면 안된다'나, 퀘스트 컨텐츠 담당자인 B에게 'XX 퀘스트 주변에 너무 강한 놈들이 있으니 피해서 수행하게 만들어야 한다.' 같은 상의를 통해 해결될 수도 있는 일이긴 하지만 양쪽 모두 서로간에 업데이트 할 것이 무엇인지 모르고 있다면 가이드라인을 세울 수가 없는 부분이다.

이런 것들 조차 A가 B의 작업에 종속적인 형태를 가지거나 역으로 B가 A의 작업에 종속적이어야 가능한 작업이며 어느 한 쪽의 작업이 끝나지 않는다면 나머지의 작업이 불가능하다는 것이다.

여기에 제한된 인터페이스의 필요성이 나타난다. 두 작업자에게 각각 다음의 원칙을 전달한 상태를 가정해 보자.
A (몹 컨텐츠) : 퀘스트를 제공하는 마을간의 이동 경로에는 진입 레벨이 된다.
B (퀘스트 컨텐츠) : 마을 진입 경로 외의 구역은 큰 폭의 보상을 주는 퀘스트 완료 후에나 진입이 가능할 수가 있다. 일반적인 퀘스트들은 진입 경로에 동선을 몰아 넣어야만 한다.

처음부터 애초에 이 원칙에 맞춰서 작업하다가 서로간에 맞추어 나가야 하는 경우 (인터페이스)가 발생할 경우에는 상의 후에 결정하게 된다는 규정이 선다면 두 사람은 보통때에는 서로 얼굴 볼 일 없이 제각각 일하며(파이프라인이 두 개) 진행하다가 중요한 몇몇 가지 결정에 대해서만 상의하면 된다. (이런 회의는 명확한 방안을 한쪽에서 마련해 다른 쪽에 제안하는 형태가 되므로 긍정적인 회의가 된다. 위의 예시대로라면 퀘스트 제작자가 '우리 이런 몹 있는 거 어떨까?' 하고 제안하는 것으로 시작되는 회의 같은 걸 생각해 볼 수 있다.)

이런 식으로 상호간의 영향력이 적게. 딱 필요한 순간에만 영향을 미치도록 결정되는 것이 직교적인 형태라 지칭되는 것이다.

Note : 추가로 여기서 사용된 회의록은 그 자체가 특수한 경우에만 적용되는 금칙으로, 관련자들만 볼 필요가 있는 레퍼런스 가이드에 편입시킬 수가 있다. 이것이 후에 두꺼운 레퍼런스 가이드로 발전하는 것이며, 애초에 세워둔 원칙은 '바이블' 기획서에 들어가 모두가 알아둘 사항으로 포함시킬 수가 있다.



직교적인 작업은 원래 알아서 발생하기도 한다.

뭐, 아주 실무 작업을 해 본 적이 없거나 너무 아래에서 일하는 경우가 많았던 경우가 아니라면 사실 여기까지의 내용은 내가 잘난척 하며 설명할 사항이 아니다. 프로그래머들이 읽는 서적을 통해 직접 따로 공부했다면 더 말할 것도 없고.

일부러 내가 말하지 않더라도 이 요령은 경험적으로 알게 모르게 쓰게 되는 경우가 많다. 작업을 나누기 위해 '직교적'이라는 말을 모르는 상태에서도 가능한한 서로 영향을 주는 일이 없는 작업을 배분하려 하며 실제로 본래 영향이 적은 파트(커뮤니티와 스킬시스템이라던지, UI와 성장 체계라던지)에서는 특별히 신경쓸 필요도 없이 알아서 발생하곤 한다.

각종 삽질 끝에 작업의 파이프라인이 완성된 프로젝트들은 알아서 직교적인 형태를 갖추고 있는 경우가 많고 스스로 '작업을 배분하기 위해서는 이렇게 해야 하는구나'하고 깨우치는 경우가 많다.

그런데 왜 이걸 구태여 강조하고 있을까?



혼자 하는 작업에서의 직교성

사실, 직교적인 것은 생산성에 대해 파이프라인 동결을 막는 것 이상의 의미를 가지고 있다. 

문제가 발생하면 고치기 쉽다는 사실이다.

이 부분이 많이 간과되는 부분인데 (애초에 직교적인 구조로 짠다는 것의 의미를 스스로 제대로 파악하지 못한 상태에서 사용하다 보니 정확한 효과를 제대로 느끼지 못하고 진행하게 되는 경우가 있다.) 이로 인해 '혼자 작업할 내역'들은 직교적이지 못한 형태로 작업 진행을 들어가는 경우가 많다.

클래스와 스킬에서 밸런스의 예를 한번 들어 보자. (쉽게 시작하기 위해 성장 부분은 일단 배제하고 베스트 상태만을 가정한다.)

각각의 클래스와 각 클래스가 사용하는 스킬의 경우에 밸런스 처리를 한다면 클래스와 스킬이 서로 밀접한 관계를 가지고 있어야 한다는 사고방식으로 출발해 한 사람이 작업을 떠맡게 되는 경우가 많다.

이 경우 작업자가 배분되어 있지 않으므로 직교적이지 못한 형태로 짜는 경우가 많은데, 무슨 소리인고 하니 일반 공격과 스킬의 효과를 그저 하나하나 직접 고치고 있는 경우가 많아 특정 클래스가 '사냥 속도가 딴 애들에 비해 너무 떨어집니다. 올려 주세요!'하는 요청이 왔을 경우 이를 수용하기 위해 모든 스킬 하나하나를 다 고쳐야만 하는 경우가 있다는 소리다.

이건 또 다시 특정 스킬은 강하고, 특정 스킬은 필요 이상으로 약한 문제를 다시 초래할 수가 있으며 한 클래스에 대해 정밀하게 짜 둔 게임플레이를 일부러 망가뜨리고 다시 고치느라 많은 시간을 투자하게 되는 것으로 연결된다는 의미이다.

역으로 스킬 하나의 성격만 고치려다가 '워, 이 클래스 쩌네염. 혼자 다잡아요.' 같은 문제가 발생할 수도 있다. 어느쪽이던 여러가지로 괴로운 문제인 건 사실이다. :-(

아시다시피, 이런 형태는 직교적이지 못한 형태이며 여기서 혼자 하는 작업에서 직교적인 설계를 할 경우 얻게 되는 이점의 효과가 나타난다. 바로 '문제가 발생한 부분을 고칠 때에는 딱 그 부분만 고치면 된다'는 효과 말이다.

당연히 전신 마취(서버 내리고 수정사항 다 확인한 뒤 다시 올려!) 보다는 국부 마취(이 패치만 올리면 되니까 요것만 테스트 하고 다음 패치에 적용)이 낫다는 거다. 수정사항이 줄어들기 때문에 자연히 집중 QA도 매번 패치할 때 마다 '전부 다해봐!'일 필요가 없고 '요것만 제대로 되는지 확인합시다?'가 된다.



이런건 도대체 어떻게 직교적인 구조로 바꾸는가?

위의 예시를 가지고 말해 보자면 사냥 속도에 영향을 미치는 DPS(Damage Per Sec)와 다운타임(사냥 후 회복시간)을 별도의 팩터로 빼고 각각의 스킬에 대해서는 DPS와 다운타임에 대한 Portion 값 형태로 동적으로 계산되도록 지정하는 방안이 있다.
해당 클래스의 전체적인 공격력을 올린다는 결정이 떨어지면 추상적인 스테이터스인 DPS 값을 올리고 각각의 스킬은 자신의 Portion에 따라 DPS 값을 나눠 가지게 된다. 진짜 데미지 값은 추상적인 스테이터스를 조절함으로써 알아서 결정된다는 의미이다. (이건 과거에 작성했던 '망할놈의 밸런스' 포스트와도 일맥상통한다.)
 
여전히 추상적이므로 구체적인 예시를 쓰자면 다음과 같은 형상이다.

전사 클래스의 DPS는 100. 이 클래스는 일반 공격과 하드 히트이라는 스킬 하나를 가지고 있다고 치자. 편의를 위해 다운 타임은 배제한다.

일반 공격의 Portion 값은 1.
성격 : 공격 딜레이는 1초당 1회.

하드 히트의 Portion 값은 2.
성격 : 쿨다운 타임 30초.

각각 전체 포션에 대해 성능을 나누어 가지도록 되므로 총 합 값인 3을 기준으로 나누어 배치하는 형상이 된다.

[일반 공격]
1/3 * DPS = 33 * 타임(1초) = 33

[하드 히트]
2/3 * DPS = 66 * 타임(30초) = 1980

Oops, 하드 히트의 데미지가 일반 공격에 비해 너무 쎈 듯 하다. 포션을 고쳐볼까?

[일반 공격]
2/3 * DPS = 66 * 타임(1초) = 66

[하드 히트]
1/3 * DPS = 33 * 타임(30초) = 990

위에서 보듯이 Portion을 어떻게 고치든 이 클래스가 가지는 전체 공격 능력은 여전히 100으로 고정된다.(해당 클래스가 가지는 단위 시간 당 데미지 값이 균일하다.) 역으로 DPS를 고친다 쳐도 전체 Portion값이 고정되어 있으므로 스킬간의 성능은 유지된다.

이런 형태로 수정하는 것은 물론 csv로도 가능하지만 문법형 스크립트의 경우에 더 좋은 점이 많은데....... 요건 좀 뒤에.

어쨌든 이 과정에서의 인터페이스는 'DPS라는 추상화 된 값으로 성능을 통제한다'는 규정 까지이며 각각의 스킬이 가진 성격 등등을 추가하면서 인터페이스가 증가하게 된다. 이를테면 메즈 능력 같은 것을 추가하면 이를 '특수능력이라는 추상화된 값으로 성능을 통제한다'는 인터페이스가 추가 되는 것으로 봐도 된다. 이로 인해 메즈에 대한 Portion을 할당한다던가 클래스 성능에 대해 메즈 값이 추가 된다던가 하는 등의 작업이 있겠지만 한정적인 규모이며 이 역시 기존의 작업 사항에 대해서는 직교적인 형태를 유지하게 된다.



직교성을 유지한다는 것은 작업을 파트화 한다는 것을 의미한다.

위에서 봤듯이, 직교화를 제대로 이루었다면 사장님이 '전사 클래스가 너무 쎄니 좀 줄여라'라고 했을 때 괜히 스킬들 하나하나 다 고치다가 그동안 잘 작동하던 스킬간의 사용 빈도 밸런스도 망가뜨린다던지 하는 사태를 미연에 방지할 수가 있다.

또, 당연한 이야기지만 혼자 작업 하던 부분이라도 작업자가 충원되어 이 작업을 두 명이 나누어 작업하려 할 때에도 특별한 사전 준비나 갑자기 늘어나는 금칙 규정 없이 몇몇 가지 작업 주의사항만을 알려 주고 작업의 인수인계가 가능하다는 효과도 있다.

이 외에도 작업을 직교화 하기 위해 고민하는 도중 정말로 필요한 개념이 어디서부터 어디까지인지 재 체크하는 효과도 가질 수 있으며 이는 즉시 좋은 바이블 - 레퍼런스 가이드 구조를 완성하는데에도 크게 도움이 될 수 있다. (요건 진짜로 나중에)

그리고 중요한 점 중 하나. 생산성과 직교성의 원칙(1) 의 포스트로 다시 되돌아가 툴 만들 때 '핸들'이 직교화된 구조에서 다시 파생된다는 점이 있다. 무언가를 직교적으로 꾸며 보면 툴 자체에 정확한 제약을 발견해 잘 정리해 둘 수도 있고, 문법형 스크립트 구조를 짤 수도 있으며 업데이트 시점에 테스트 규모를 확실하게 미리 알아 두는 것도 가능하다.



2009년 4월 15일 수정 : 용어를 이상한 걸 사용한 부분을 제대로 고침