실제로 시스템(또는 시스템을 구성하는 일부의 기능)을 구현하는 단계에서 이러한 내용을 숙지하고 있는 기획자와 프로그래머가 함께 일하는 것이 유연한 시스템을 만들 수 있느냐의 척도인 것 같습니다.

가능하다면 양자가 모두 이러한 내용을 숙지하고 있고 또 상응하는 시스템 구축경험을 갖추고 있어서 시스템 설계 시 서로 피드백을 주고 받으며 이상적인 모델을 도출하는 것이 가장 최선.

하지만 그것이 어렵다면 한쪽이라도 베테랑을 투입하여야 하며 이 경우 시스템 설계의 주도권은 베테랑이 갖는 것이 좋을 것입니다.

이 경우 아무래도 기획자보다는 프로그래머가 베테랑이어서 유연한 시스템을 구현할 수 있게 리드하는 것이 더 낫겠죠.

최악의 경우가 시스템 구조에 대한 지식과 경험이 부족한 (그것도 직급이 높은)기획자가 결과물만을 요구하며 발주한 기능을 초급 프로그래머가 아무 생각 없이 순응하여 하드코딩해 주는 케이스일 것입니다.

자바 버추얼 머신같은걸 말씀하시는건가요.. 음..

글의 요지는 어떠한 데이타 내용이 만들어지면 다른 데이타 포맷(object)의 이동함에 있어서 translator의 역할을 좀더 증대 시켜서
데이타의 포맷을 되도록 변동성이 적어지게 해야 한다는 내용인데...
개발자(기획자,프로그래머) 입장에서는 별다른 내용은 없군요...

아...너무어려운 글이다

쉽게 설명하자면... 객체의 설정값을 스크립트로부터 읽어들이는 서브시스템을 설계하여 개발팀에게 넘기는 경우겠죠. 그 경우 각 객체별로 어떤 스크립트 파일이 필요한지 정확히 알아야 사용할 수 있는데...
이런 객체와 각각의 설정파일이 갯수가 많아지면... 아무리 문서화를 잘 해놔도 개발팀에게 전달될 땐 빠지는 것이 꼭 생기거든요.
이러면 해당 서브시스템을 활용하기 위해 모든 스크립트 세트를 관리하고 그 전체 구조를 학습하느라 불필요한 업무가 발생. 이걸 필요한 파일만 신경쓸 수 있도록 하는 것이 필요하겠죠.
그런 경우 스크립트로부터 직접적으로 데이터를 읽는 구현보다는, 스크립트가 있으면 읽고 없으면 default behaviour 가 적재되도록 하는 translator 를 두면 편하겠죠

그리고 이 글의 요지대로 설명한다면 만약에 스크립트에서 특정 변수명이 적절치 못해 바뀐다거나 구조가 변경될 경우 변경된 항목을 참조하는 프로그램 코드 역시 변경되는 경우가 발생하는데...
그런 경우는 스크립트에서 변경이 발생한 symbol을 프로그램의 코어로직이 직접적으로 다루도록 구현된 경우죠.

예컨데 스크립트에서 원래 c_delay_max 라는 symbol 을 export 했는데 코어로직에서 해당 이름으로써 그대로 import 하는 경우,
스크립트에서 c_delay_max 가 무의미해져서 이걸 c_delay_min 으로 변경한다면 이를 참조하는 프로그램 코드가 그 로직과 import name 을 변경해야 하는 안구 스콜이 발생하겠죠.
(어쩌다 한두번이라면 모르지만... 애초에 스크립트라는 것 자체도 그 구조가 고정적이지 못해서 기획자 아줌마가 마법에 걸리는 주기에 맞춰 변경되는지라 ㅋ)
뭣보다 이런 경우 각 변수명이나 함수명을 참조하는 프로그램 코드가 코어로직의 여기저기에 분산되는 것이 보통인지라... 스크립트 일부가 변경될 때마다 수정해야 할 프로그램 코드를 확인하려면 복잡해지니...

결국 스크립트를 한번 추상화시킨 translator class 를 둬서 스크립트의 변경이 코어로직에 직접 영향을 끼치는 것을 방지하고,
스크립트 변경시 수정할 프로그램 코드를 translator class에 집중시켜 유지보수의 편의를 도모하자는 얘기인데...

그 현실은 translator class 가 delay_max 나 min 형식으로 export 하는 형식이 아니라 코어로직이 delay 를 요구하는 시점에 맞춰 적절히 계산해주는 형식의 인터페이스를 갖도록 해서
delay의 max, min, avg 타입따위에 코어로직이 종속되지 않도록 추상화를, 설계를 잘~ 해야 한다는 결론이 나오죠.

근데... 이건 사실 말은 쉬운데... 건달이 오더 받아 누구 칼침 먹이면서 나중에 변호사가 과실치사로 변호할 수 있게끔 적당한 부위를 살짜꿍 잘 찌르고 병원 도착 전에 출혈과다로 죽게끔 하는 것만큼이나 어려운 얘기거든요 ㅋ
개발 과정에 발생할 요구사항의 변덕을 예측할 정도의 짬밥이 없는 사람에겐 다룰 수 있는 문제가 아닐듯 하네요.
추상화의 동음이의어가 바로 예측인데, 치킨집 사장 클래스로 전직하기 직전의 개발자에게도 사실 그 예측이란 것이 쉽지 않은지라.

아무튼 저걸 잘 할 능력이 없는 인간들이 모여서 저런걸 꿈꾸다간... 그걸 잘~ 하느라 한세월을 보낼 가능성도 있답니다.
능력 되면 시도하고 능력 안되면 그냥 기획자 아줌마가 마법에 걸릴 때마다 하드코딩 주구장창 뜯어고치는 것이 더 효율적일 가능성도 있어요.

미디블 2 어쩌구의 경우도 사실 보면 스크립트로 뺄만한 몇몇 변수값이 하드코딩 되어있는데, 잘 보면 그걸 왜 하드코딩을 했을지 그 고뇌가 느껴지는 것들도 있더군요. 꺼내면 기획자가 찝적댈테니 아예 안꺼냈다고 느껴지는 ㅋ
결론은... 고객 지갑에서 돈을 훔쳐 개발자 주머니에 쑤셔박아주는 사장이란 인간은 개발기간을 무한대로 잡아줄 천사가 절대 아니니까... 그 냥반이 무슨 김수한무 어쩔씨구리도 아닌 이상...
개발기간과 내 꼬라지를 종합적으로 검토해서 단순무식과 스마트삐까뻔쩍 사이에 적당한 선택을 하자 정도가 되려나?

근데 내가 왜 이 쓸모 없는 잡소릴 하고 있는지... 훔...