밀피유의 이야기

사실은 이건 명백한 기획자의 실수입니다. 기획자라고 하면 두리뭉실하니까, 제 실수라고 정확히 해 두고 시작하죠. 개발팀 안의 여러 작은 팀들은 각기 일하는 방식이 다릅니다. 프로그램을 담당한 사람들과 그래픽 리소스를 담당한 사람들 사이의 일하는 방식은 완전히 다릅니다. 또, 각 팀 내에 소속된 사람들 한명 한명의 작업방식도 모두 다릅니다. 하지만 이 사람들은 모두 모여서 하나의 작업물을 만들어내지 않으면 안되고, 그 틈바구니에 기획자들이 끼어서 다른 팀의 각기 다른 작업방식에서 생기는 여러 가지 일들을 해결합니다.

이번 비공개 테스트에 들어가는 요소 중 하나에 대한 기획이 늦었습니다. 기획이야 언제부터 개발팀 전체에 구전으로 떠돌고 있었지만, 문서화를 하지는 않았습니다. 모두가 그런 요소에 대한 계획이 있다는 사실을 알고 있었지만 다른 요소를 구현하는 것이 먼저라는 판단에 따라, 사실은 핑계에 따라 이리 저리 밀리고 있었던 것인데요, 이 요소는 클라이언트, 서버, 이팩트, 비주얼 코디네이션, 스케줄링 데이터, 이팩트 사운드 등의 다양한 요소에 걸쳐 있는 것이었습니다. 즉, 이 요소를 구현하기 위해서는 여러명의 프로그래머가 필요하다는 이야기이지요.

기획이 일정에 치여도, 최종적으로 문제가 생겼을 때 개발팀에서 처음으로 욕을 먹는 것이 기획이라고 해도, - 사실 일차는 운영자, 이차는 QA부서, 삼차가 기획자 - 프로그래머들도 뒤가 찜찜한 것이 사실. 그러니까, 문서를 통해 교통정리가 되기 이전에 각기 각자가 전해들은 대로 구현을 하기 시작했습니다. 문제는 이 구현도 어쩌다 짬을 내서 진행하다 보니 구현에 해당되는 프로그래머들 조차도 의사소통이 잘 안 되어 있었다는 것.

문제는 아침에 일어났습니다. 클라이언트 동네 파티션이 시끌시끌합니다. 당연히, 기획 담당자가 불려가서 시끌시끌한 장터 한복판에 떨어진 다음 이야기는 시작되었습니다. 이야기인즉슨, 각자 구현한 방법이 달랐기 때문에 기획서에 적힌 교통정리 방법대로 구현하기 위해서는 구현을 담당한 프로그래머들 중 일부는 대대적으로 코드를 고치지 않으면 안 된다는 것. 하필이면 결정에 따라 코드를 고쳐야 하는 프로그래머 수의 비율이 어떤 방법을 선택하더라도 1:1이 되었기 때문에 힘싸움은 기획자와 이팩트 담당자, 그리고 비주얼 코디네이션 담당자의 결정에 따르는 형국이 되었습니다.

하지만, 모두가 코드를 대규모로 뜯는 일은 피하고 싶었기 때문에, 중간에 누군가의 제안에 의해 '그럼 각자의 방법을 연결해줄 수 있는 변환 테이블을 만들자'는 의견이 나왔습니다. 테이블 데이터야 기획 담당자가 입력하는 거지만 별 불만은 없었습니다. 하지만 프로그래머 입장에서 별로 깔끔한 방법은 아니었고, 경우에 따라서는 이미 작업되어 있는 이팩트를 수정해야 할 가능성도 있었기 때문에 논란을 잠재우지는 못했습니다. 그렇게 한참을 더 사무실을 시끄럽게 만들었지만 별다른 획기적인 방법을 찾아내지는 못했고, 단지 각기 다른 구현 방식의 간극을 해결하기 위한 용도로 만들어질뻔한 변환 테이블은 별로 깔끔한 방법이 아니라는 대세에 따라 이 문제에 해당되는 몇 명의 프로그래머 모두가 각자 조금씩, 각자의 코드를 코드 레벨에서 수정해 문제를 해결하는 것으로 마무리되었습니다.

사실은, 구전으로 떠돌아다니는 요소에 대한 계획은 웬만하면 구전으로 떠돌게 두지 말고, 그런 떠도는 이야기가 있다는 사실을 알자마자 확실하게 문서화하거나, 확실하게 보류하거나, 확실하게 파기해야 한다는 교훈을 얻은 이야기입니다만, 프로그래머들이 각자 자신의 구현 방법이 더 효율적이라거나, 다른 구현 방법보다 낫지 않느냐고 다른 사람들을 설득하는 것을 시도하는 모습은 흥미로웠습니다. 물론, 프로그래머들이 잠시나마 그렇게 분열된 모습을 보였다고 해도 모두가 입을 모아 '기획이 이러면 어떻게 해요!'라고 말하는 순간만큼은 한마음 한뜻이었습니다.

... 나도 인정한다구요. ㅜ_ㅜ