나에게 있어서, 보고 감동한 소스들 중에는 ‘타입리스트’가 항상 들어간다.

참여중인 프로젝트에서 타입리스트를 사용하여 ‘enum’의 사용량을 줄여보려고 시도해본적이 있었다. 그러니까, enum대신에 TL::IndexOf< T_Typlist, MyClass >::value 등의 값을 사용하려고 했었다. 이렇게 하면, 사용하려는 클래스군 - 아마, state 나 strategy pattern 들의 구현클래스들이겠지 - 이 추가될때 마나 T_Typelist 에 추가되는 클래스만 적어주면 된다.

적용을 해봤는데, 다른 분들의 반응이 영 탐탁치 않다. 아마도 익숙한 enum을 나두고 왜 굳이 생소한 타입리스트를 사용하는지에 대한 불만의 표출이었으리라.

곰곰히 자기반성을 해보니, 이건 ‘잘난체’ 외에 아무것도 아니라는걸 느꼈다. 나에게 반문해보니 enum과 class의 중복등록이 정말 나빠서 없애려고 했던것 보다는 타입리스트를 프로젝트에서 써보고 싶었던것이 더 크게 작용한것같다. 이러한 행동은 팀워크를 깨뜨리고 분위기를 싸~ 하게 만드는, 얻는것은 없고 잃는것은 많은 ‘못된’짓이다.

팀은 새로운것을 즐기는 사람, 코딩보다는 결과물을 더 즐기는 사람, 익숙한것들 활용하여 문제를 해결하려는 사람등 다양한 사람들로 구성된다. 그리고 이러한 팀원들의 합동작업으로 최종 결과물이 나온다. 새로운것을 즐기는 사람이 짠 코드를 익숙한 것을 활용하여 문제를 해결하려는 사람이 유지보수를 맡게 되는 경우도 허다하다. 그래서 다른 팀원이 공감할수 없는 코드은 ‘못된’코드다.

다른분들에게 생소한 메타프로그래밍은, 정말로 쓰이면 크게 좋을때, 외부 노출을 최대한 적게 하여 만들어야 한다. 그리고, 메타프로그래밍을 사용했을때의 장점을 충분히 납득시켜야 한다.

결론? 메타프로그래밍은 코드 밑단의, 지하세계를 지키는일에 사용하자.