티맥스의 씁쓸한 개발환경

오늘 티맥스에 대한 글이 워낙 많아서 글 쓰기 망설였지만, 소프트웨어 개발자분들과 공감대를 느끼며 힘을 얻고자 용기 내어 씁니다.

예, 저 역시 소프트웨어 개발자 중 한 사람으로서 티맥스 이벤트에 대해 큰 관심을 가졌습니다.
무엇보다 티맥스 개발자분들, 정말 고생 많이 하셨습니다.
운영체제, 브라우저, 워드, 엑셀, 파워포인트 어느 것 하나 만만한 것이 없는데 윗선에서 통보하는 개발일정 맞추느라 고생하신게 눈에 선했습니다. 오픈소스 라이센스 등의 법적인 문제는 차치 하고서라도 4-5년 안에 저것들을 모두 만들었다는 점에서 개발자분들이 얼마나 열심히 일하셨는지 누구도 의심하지 못할 것입니다. (물론 오픈소스를 사용한 부분은 명확히 밝히고 라이센스를 따라야겠지요.)

하지만, 그것과 관계없이 이벤트를 보는 내내 씁쓸했습니다. 이 글을 통해 "왜 남의 일 가지고 내 기분이 씁쓸한 거지?" 라는 질문에 대해 제 스스로 대답을 정리해보고자 합니다.

결론은, "이건 남의 일이 아니다" 정도로 정리할 수 있을 것 같네요. 아니면 이렇게 정리해도 될 것 같습니다.

* 성숙하지 않은 소프트웨어 개발환경

실시간 중계를 보니 중간에 티맥스 오에스 개발 에피소드를 말씀하시더군요.

"얼마 전에 오에스 개발 도중 아키텍처에 심각한 문제가 있는 것을 발견했습니다. 하지만 저희는 기업용 소프트웨어를 개발한 노하우가 있기 때문에, 아케텍처 설계에 능한 개발자를 긴급 투입하여 문제를 훌륭히 고쳐냈습니다." - 발표내용 중 일부 -(기억을 더듬어 쓴 거라 정확하지는 않습니다)

아키텍처 문제를 발견했는데 개발자 누구누구를 "긴급" 투입하여 해결했다는 이야기에서 전 가슴이 탁 막혔습니다. 단순한 코딩에 문제가 있다면 모르겠지만, 정말로 사람들이 말하는 소프트웨어 아키텍처에 문제가 있는 것을 알았다면, "긴급"히 아키텍처를 뜯어 고치는 것이 아니라 관련된 아키텍처 설계자 모두 모여서 아키텍처 리뷰를 통해 신중히 수정방향을 정했어야 하겠죠.

게다가 아키텍처 수준의 문제는 소프트웨어 개발 한 지 몇 년이 지난 다음에 발견하는 것이 아니라 초기 아키텍처 설계 단계에서 충분한 시간을 가지고 오류를 찾았어야 할 것입니다.

올 11월에 배타버전 공개할 것으로 들었습니다. 그렇다면 지금은 테스트 팀에서 열심히 regression test 를 진행하며 숨어있는 버그를 잡아야 할 시기인데, 테스트 잘 하고 계신지 여쭤보고 싶습니다.

MS 개발자인 Eric Lippert의 지난 6월 22일자 블로그를 보면 성숙한 소프트웨어 개발프로세스가 무엇인지 힌트를 얻을 수 있습니다. stackoverflow.com서 누군가 이런 질문을 했습니다.

"왜 C#은 C++처럼 non-member function을 지원하지 않는거죠?"

http://stackoverflow.com/questions/1024171/why-c-is-not-allowing-non-member-functions-like-c/1027853#1027853

그에 대한 대답은 이랬습니다.

"왜냐하면 아무도 그 기능을 디자인한 적도 없고, 스펙을 만들지도 않았으며, 구현, 테스트, 문서작업 하여 제공(ship)한 적이 없기 때문입니다. 어떤 기능 한 가지를 만들어내기 위해서는 이 여섯 가지 절차를 거쳐야 해요. 그것들 모두 어마어마한 시간과 노력, 돈이 들죠. 어떤 기능이라도 값싸게 만들어 내지는 못합니다. 저희는 주어진 제한시간과 한정된 노력, 제한된 예산 안에서, 저희 사용자들에게 최대한 이익이 되는 기능만을 제공한다는 확신을 갖기 위해 정말 열심히 노력합니다.

because no one ever designed, specified, implemented, tested, documented and shipped that feature. All six of those things are necessary to make a feature happen. All of them cost huge amounts of time, effort and money. Features are not cheap, and we try very hard to make sure that we are only shipping those features which give the best possible benefits to our users given our constrained time, effort and money budgets."

http://blogs.msdn.com/ericlippert/archive/2009/06/22/why-doesn-t-c-implement-top-level-methods.aspx

제가 주목한 점은 질문이 아니라 그에 대한 대답이었습니다. non-member function 이라고 간단히 언급하는 기능 하나를 만들지 않은 이유가 여섯 단계 절차를 거친 적이 없기 때문이라고 당당히 말할 수 있는 환경, 이것이 성숙한 개발문화 아닐까요?

우리 개발자들이 이혼당하지 않고 정시에 출퇴근하며 훌륭한 소프트웨어를 만들어 내는 성숙한 개발문화가 어서 오기를 간절히 바랍니다.

ps. (제목을 수정했습니다.)