Testors.Net

트윗에서 지인 프로그래머들 사이에 최근 C/C++ 프로그래머들이 로우레벨을 너무 모른다는 한탄이 오간걸 보니 예전에 MSDN Magazine 에서 본 기사가 떠오른다.

...

 

다음 질문은 많은 사람이 어려워하는 포인터에 대한 것입니다.

Q : 아직도 포인터(var, object, functional)를 잘 이해하지 못했습니다. 설명을 해 주시거나 공부할 자료를 보내 주실 수 있나요?

C++를 처음 배우고 있으며 포인터가 무엇이고 어떻게 사용되는지 궁금합니다. 많은 책을 보았지만 너무 복잡하게 설명되어 있습니다. 포인터란 특정한 메모리 위치를 가리키는 것으로 알고 있는데 이런 개념이 왜 필요한지 모르겠습니다. 아마도 컴퓨터가 각 위치를 자동으로 추적하려는 것일까요? 답변 부탁드립니다.

필자는 이 질문을 동료 필자인 Matt Pietrek과 John Robbins에게 보내어 조언을 구했습니다. Matt는 이렇게 말하더군요. "그 사람의 생각이 맞다. 포인터는 오래되어 불필요한 개념이며 이제는 배울 필요가 없다." John은 한술 더 뜨더군요. "포인터는 개 이름인줄 알았다. 뭔가 다른 의미가 있나?"

from http://msdn.microsoft.com/ko-kr/magazine/cc163484.aspx (꽤 읽을만 하니 일독을 권한다.)

* 코어는 미친듯이 늘어나고 있고, 메모리는 물값만큼이나 싸졌다.

* 해서, 서버 설계에 특별한 문제가 없다면 (특별한 문제가 없도록 만들 수 있으려면 한 10년정도 죽어라 삽질해 봐야 하지만..) , 이상적인 상황일 경우 결국 동접의 병목은 DB 가 결정하게 된다.

* 그런데 안타깝게도 DB 분야에서 혁신적인 성능 향상을 기대하긴 힘들다.

* 메모리 증설이나 중간에 이것저것 트릭을 써서 DB 부하를 경감할 수 있지만, 서버 시동 후 대량으로 몰리는 순간 로그인 요청은 결국 디스크 긁어야 한다.

* 아무리 비싸고 빠른 스토리지라 해도 일반적인 사용 환경에서 하드 디스크 수배 이상의 성능을 내기는 힘들다. 돈이 모든걸 해결해 주지는 않는다...

요새 업계에서는 너티독 얘기가 한창이다. 다들 판타지를 품는것을 보니 처음 PD 를 달고서 고군분투했던 생각이 난다.

프로젝트를 맡고 나서 한동안 불타올라서 구현하고자 했던것이 있었으니 "개발자 모두가 스스로 즐기면서 게임 개발에 참여/관여하는 팀을 만드는 것" 이라는 아주 단순하고도 이상적인 목표였다. 저런 로망을 갖게 된것은 필드에 입문하고서 스스로가 직군에 한정되지 않고 게임 개발에 전방위 적으로 관여할 수 있는 환경을 절실히 원했기 때문이었다. 당시의 나는 우리도 할 수 있다는 확신을 가지고 있었다.

지금은 그후로 3년이 지났다.

,

얼마전 @henjeon 님 트위터에서 재미난 글귀를 보았다.

사람은 자연성, 가연성, 불연성의 세 부류가 있다. 최소한 가연성 이상은 되어야 조직에서 일할 수 있다.

참 재미나게 표현한것 같다. 아마 창의적인 조직을 오래 매니징 해본분이 쓴 글일거라고 생각한다. 스스로가 3년간 좌충우돌 하면서 절실하게 느낀점은, 생각보다 많은 사람들이자기 자신이 무엇을 원하고 있는지 여전히 모르고 있다는 것이고, 우리 주변에서 가연성 타입의 사람을 찾기도 그리 쉬운일이 아니라는 것이다.

결론부터 말하자면 나는 처음의 목표를 구현하겠다는 생각은 접었다. 지금은 목표를 '모두가 개발에 관여하도록 하자' 에서 '관여 하고 싶은 사람이 그럴 수 있는 창구를 만들어 주자' 로 수정한 상태다. 해외의 B 모사나 너티독같은 곳에서는 그것을 이미 이루어내지 않았는가? 라는 의문이 있을 수도 있겠다. 그런데 나는 '해외' 라는 단어를 쉽게 흘려버리지 말라고 얘기하고 싶다.

현재 나의 일터는 전 세계에 지사를 두고 있는 다국적 그룹에 속해있는 회사이고, 그룹 회장님은 서로간의 커뮤니케이션을 굉장히 중시한다. 해서 해마다 지사의 주요 인사들을 오키나와라던가 뉴질랜드같은곳에 모두 모아서 캠프를 열기도 하고 혹은 본인이 지사를 돌아다니면서 강연을 하기도 하신다.

그분이 회사에 오셔서 팀장급들을 모두 소집해 리더쉽 트레이닝 세미나를 했을때의 일이다. PT 가 끝나고 Q&A 시간이 되었는데 아무런 질문도 없었다. 그러자 세계 투어 하면서 PT 뒤에 QA 시간을 가지면 영/미권 회사에는 질문/건의가 쏟아지고 일본/한국에서는 침묵만이 흐른다는 얘기를 하셨다. 농담조로 얘기하셨지만 난 그 얘기를 그렇게 가볍게 흘려버릴 수 없었다.

글쎄, 나는 지금 '씨바 우린 안돼..' 같은 패배주의적인 얘기를 하려는 것이 아니다. 다만 나는 지금까지 '우리에게 맞지 않는 옷' 을 낭만에 취해 무리하게 입으려 했던게 아닌가 싶은 생각이 드는 것이다. 국내의 유명 스튜디오들의 개발 문화와 PD분들의 이미지에 대한 들여오는 이야기들은 그런 나의 생각을 더욱 확고하게 만드는 것 같다.

자연성인 사람들에게 기운 빠지는 애기를 쓴 것 같아 조금은 미안하지만, 부디 누군가 나의 이런 생각이 틀렸음을 증명해 주면 질투가 나면서도 한편으로는 참 기분이 좋을것 같다.

나는 TDD 의 장점이 두 가지가 있다고 생각한다.

 

우선 첫 번째는… 살다 보면 예전에 만들어둔 코드가 이후의 수정 때문에 문제가 생기는 경우가 가끔 있다. 그런데 TDD 로 개발해 왔다면 이전에 작성해 둔 테스트를 활용 할 수 있기 때문에 이런 문제 발견이 쉬워진다. 대신, 코드 인터페이스 변경 시에는 기존의 테스트들도 고쳐주는 수고를 감수해야 할 것이다.

 

두 번째로, TDD 는 결합도(coupling) 낮은 디자인을 유도한다. 코드를 테스트 가능하게 만들려면 인터페이스가 명확해야 하고 어떻게든 다른 모듈과의 관계를 제거하거나 줄여야만 한다. 일반적으로 결합도가 낮은 코드는 좋은 디자인일 확률이 높기 때문에 모든 코드를 테스트 가능하게 유지하다 보면 전체적인 코드 수준도 좋아진다.

 

위와 같은 이유로, 기존의 프로젝트에 TDD 를 적용하는 것은 불가능하다고 본다. TDD 는 좋은 디자인을 ‘유도’ 할 뿐이지 이미 존재하는 나쁜 디자인을 좋은 디자인으로 ‘변화’ 시키지는 않기 때문이다. 켄트 벡은 기존 프로젝트에 TDD 를 어떻게 적용하냐는 질문에 책에서 ‘그것은 책 한권으로 설명해야 하는 분량이다’ 라는 답을 한것 같은데 내 생각에 기존 코드를 테스트 가능하게 만드는 방법은 없다. 그냥 새로 짜는게 빠르고 효율적일거다.

 

그렇다면 Testors는 모든 것을 TDD 로 개발하느냐..? 그렇지 않다. 나는 에반젤리스트도, 방법론자도 아니다. 뭔가가 새로 나오면 그것이 필드에서 실제로 동작하는걸 확인하지 않는 이상은 도입을 꺼린다. 좋은 방법론 1~2년쯤 늦게 도입한다 해서 프로젝트가 망하지는 않는다. 구지 리스크를 감수할 필요 없이 나 빼고 남들이 다 써서 긍정적인 효과가 명백히 드러날때에 써도 늦지 않다.

 

만약 내가 엔진이나 라이브러리나 웹, 혹은 비즈니스 로직을 주로 다루는 프로그래머였다면 대부분을 TDD 로 작성했을지 모르겠다. 하지만 나는 온라인 게임 프로그래머이고(였고) 게임에서 발생하는 상황에 대한 테스트 케이스를 작성하는 것은 쉽지 않다. 이건 숫자들의 합을 더하는 수준의 문제가 아니다. 결합도를 없애는 것만이 능사가 아니며 효율을 위해 어느정도의 관계는 분명히 유지시켜야 한다.

 

사실 TDD 라는 용어를 접하기 전부터 길찾기라던가 기타 게임 개발에 필요한 기하 문제들을 풀때는 항상 테스트를 작성했었다. input & output 이 명확한 이런 문제들을 테스트를 작성하지 않고 작업하는 사람이 정말 근성가이라고 본다.

 

3년쯤 전인가 회사의 UI 엔진을 스크립팅 가능하게 리뉴얼 하는 작업을 한 적이 있었다. 기존의 엔진은 폼 디자이너 툴만이 제공되었는데 이걸 기존 C++ 코드 & 리소스들과의 하위호환성을 유지하면서 루아 스크립팅 & 시뮬레이션이 가능하도록 만드게 목표였다. 작업은 순조로워서 엔진과 툴 모두 쓸만한 수준으로 부작용 없이 리뉴얼 할 수 있었다. 이후 UI 들은 자체 테스트를 내장한 채로 개발이 되었었다. 그런데 어떤 경우들은 테스트 작성 비용이 재현 및 디버깅 비용을 넘어서기도 했다.

 

게임 프로그래밍이란게 그렇다. input 과 output 을 명확하게 정의하기 힘들다. 시간의 흐름도 중요하고 타이밍도 중요하다. 몇몇 특정한 상태에 대한 테스트를 작성하고 유지하는것에 대한 비용은 정말이지 엄청나게 커질 수 있다. 내가 취한 방법은 대부분의 UI 들에서 테스트 작성을 포기하고, 런타임에 재현 및 디버깅이 쉽도록 한 것이었다. 키 하나로 스크립트가 모두 reload 되고, UI 가 문제 발생 이전으로 리셋되는 식이었다.

 

요약하자면, TDD 는 사실 패턴과 마찬가지로 이전부터 쓰는 사람은 모두 써왔던 방법이고, 그게 모든 분야에 사용되고 있지 않은 이유는 당연하게도 TDD 모든것에 대한 해답이 될 수 없기 때문이라고 생각한다. (난 사실 TDD 가 적용될 수 있는 분야가 매우 한정적이라고 생각한다) 문제는 이런글 (http://testors.net/tt/625)들이 귀 얇은 친구들을 혹세무민하여 주화입마에 빠지게 하는것에 있다. (이 대목에서 모 군이 찔려할것 같다...)

 

만약 TDD 가 정말로 결함을 줄여주고 개발 기간을 단축시켜 준다면 (참고: 난 이런 개발 효율이 측정 가능하지 않다고 생각한다), TDD 를 도입하지 않은것을 불안해 할 필요가 없다. 그게 사실이라면 어느샌가 당신 주변의 대부분의 개발자들이 TDD 를 사용해 프로젝트를 진행하고 있게 될거다. 그때 관심 가져도 늦지 않을것 같다.