써니의 一生牛步行

밸리를 잠시 돌다가 인상적인 글을 봤습니다.

꼭 그래야만 하는 걸까요?

가장 인상 깊고, 공감하는 부분을 인용해 보겠습니다.

과연 진정한 프로그래머의 길은 구글 이나 MS 입사시험(?)에나 나온다는 이상무쌍한 알고리즘 찾기나... 수수께끼 풀이에만 있는 걸까요?

그렇게 자기가 정한 기준에 맞지 않는 다른 사람들을 무시하는 풍토가 IT 업종의 3D화를 이뤄냈다고는 생각해본적 없으신가요?

그리고, 트랙백에 걸린 다음과 같은 글도 읽었습니다.

꼭 그래야만 하는 이유

역시 중요한 문구를 인용해 보겠습니다.

IT 바닥에 Coder는 많은데 처음부터 Software를 Design할 Programmer는 적은 것 같다.
왜 Programmer가 Design을 먼저하지 않고 Coding을 먼저하는 걸까?

첫번째 글에 대한 제 생각은 이렇습니다. 일단, 이와 같은 글을 쓰시게 된 이유가 어쩌면 아직 아키텍트라는 위치에 근접해보지 못한채 설익은 설계 경험을 가지고, 소프트웨어 디자인에 대해서 이런저런 기준을 제시한 제 부족한 글들이 그 원인이 되지는 않았을지 생각했습니다. 어쩌면 그저 제 망상에 불과 할지도 모르겠습니다.

하지만, 분명하게 이야기 하고 싶은 것은 제가 매일 하고 있는 일은 코딩이지 설계가 아니라는 것입니다. 그 근거로서 말씀드리지요. 저희 회사에 개발자가 저 혼자 뿐입니다. 누구에게 지시를 내리고 할 위치가 아니라는 것입니다. 또한 코더와 아키텍트, 고수와 하수를 나누고 그들 사이에 편가르기를 시도하려고 하지도 않습니다. 편가르기를 하려면 어느 한 편에 서야만 하는데 저는 양쪽 위치에 다 서 있는 입장입니다. 개발을 하면서 프로젝트 매니저의 역할을 맡은 적도 몇번 있지만 그런 상황에서도 한번도 코딩을 손에서 놓은 적이 없습니다. 그러니까 지금도 코딩을 할 수 있는 것이죠.

만약에라도 저의 글이나, 저의 주장들이 개발자를 고수와 하수로 나누고 서로가 반목하게 만드는 황당한 기준선을 정당화 하기 위해서 쓰일지도 모른다는 우려 때문에 확실히 밝히고 싶습니다. 물론 제가 그런 오해를 살만한 글을 써 올린 적이 있다는 점에 대해서는 과오를 인정을 하는 바입니다. 하지만, 그것은 자신이 처한 위치에서 나아가려는 노력을 전혀 하지 않고 모든 문제의 원인을 외적인 요소에서 찾고, 자신의 안이함에 지나치게 관대한 일부 개발자들을  비판하려는 목적에서 시도된 것입니다.

제가 스스로를 코더라고 말하는 또 하나의 근거는 좀 더 명확합니다. 저 역시 설계하기 보다는 코딩을 앞서 하는 사람입니다. 설계가 중요하다고 말하면서도 아직 실천을 못하고 있습니다. 다음 주 세미나에 Spring 기반의 게시판 구현을 발표하겠다고 떵떵거려 놓고서 지금 제작해 놓은 소스를 보면 한숨만 나옵니다. fragile base class 문제의 심각성을 제시하고도 제 코드는 fragile base class 만으로 짜여져 있습니다. 10년 넘게 설계보다 코딩을 우선하고 그렇게 문제들을 해결해 왔기 때문에 익숙해진 습관을 어찌하지 못하는 것입니다. 이걸 감추어야 할까요? 그저, 자백하고 있는 그대로 보여줄 예정입니다. 그리고, 최대한 이후에 발표할 기회가 있다면 좀 더 나은 기법을 적용해볼 요량입니다.

일상에서는 실천하지도 못하면서 왜 저는 매일 올리는 글에서는 MS의 고릴라, 스티브 발머 - 디벨로퍼도 아니면서 맨날 연설 때마다 디벨로퍼, 디벨로퍼, 디벨로퍼를 외치는 모양이 꼭 고릴라 같습니다 -처럼 똑같은 목소리를 외치는 것일까요? 작심삼일이라고 해도 삼일마다 다시 결심하면 언젠가는 실천할 날이 올 것이라고 믿기 때문입니다.

두번째 글에 대한 제 생각을 밝히고자 합니다.

Software Design은 결코 쉬운 일이 아닙니다. 10년 20년을 개발했다고 해도, UML을 철저히 공부했다고 해도 여전히 어려운 것이 소프트웨어 디자인입니다. 실용주의 프로그래머, GoF의 디자인 패턴, Head First 시리즈, 아무도 가르쳐주지 않는 프로그래밍 설계 기법, XP 방법론, 리팩토링, Test Driven Development... 온갖 좋은 책을 다 읽어도 구구단을 쉽게 설계하는 법은 아무 책에도 나와 있지 않습니다. 즉, 현실 문제는 책에서 다루는 이상과는 달리 그 변화와 종류가 너무나 방대하기 때문에 정답을 얻기가 어려운 것입니다. 앞서 언급한 기술들과 그 기술들을 저술한 분들은 분명히 손꼽히는 대가인데도 말입니다.

하물며 마감 시한에 쫒기는 일개 개발자들이 소프트웨어 설계를 하기가 쉬운데 아닙니다. 그 보다 심각한 것은 개발자들이 설계를 시도해도 아무도 그것을 가치있는 일이라고 인정하지 않는다는 것입니다. 오히려, 그럴 시간에 코드 한 줄이라도 더 작성하라는 잔소리를 듣게 마련이죠.

또, 국내에서 아키텍트라거나 소프트웨어 디자이너 혹은 소프트웨어 설계 전문 컨설턴트라는 명함을 달고 활동하시는 분들의 수가 지나치게 적고, 아키텍트라는 직함을 가지신 분들의 활동 역시 개발자들을 지도하는 역할이 아니라 프로젝트 일정 제시, 리스크 관리, 방법론 제공, 문서 표준화, 표준 프레임워크 구현 등에 머물고 있다는 것입니다. 다들 가기 싫어하고 얻을 게 없다는 군대를 가도 6주동안 훈련을 받습니다. 그런데 도무지 어디에도 소프트웨어 설계를 제대로 가르치는 곳이 없다는 것입니다. 그럴 사람도 없습니다. 그런데, 프로그래머들에게 알아서 설계를 학습하라는 것이 얼마나 가혹한 요구인지 더 이상 말하기도 지겨울 따름입니다.

그럼에도, 그럼에도 불구하고 저는 여전히 코더로 머물러서는 안된다고 주장합니다. 코더를 무시하지 말라는 주장에는 깊이 공감합니다. 그런 태도가 옅보였다면 제가 무릎 꿇고 사죄드려야 할 것입니다. 하지만, 지금 중요한 것은 코더라는 일자리 자체가 앞으로 사라지거나 저임금 직종이 되어버릴 위기에 있다는 것입니다. 지금도 낮은데 더 낮아질 거라는 것이죠. 아무리 아니라고 당장 현장에 있는 개발자들은 바보인거냐고 말씀하시면 이렇게 말씀드리겠습니다. 타이타닉호에 승선하고 있던 사람들에게 배가 침몰할 겁니다라고 말하면 뭐라고 답변 들었을까요?

이제 새벽 4시를 바라보는 시간입니다. 몇시간 전에도 대학생 후배들을 불러다가 같이 스터디를 진행했습니다. 윈도우 어플리케이션을 제작할 때, 설계를 어떤 식으로 해야할 것인가? 클래스와 인터페이스는 왜 만들까 어떻게 나누어야 할까? 가르치는 입장이 아니라 저도 함께 공부하는 입장에서 열띤 토론을 해보았습니다. 아직 부족하지만, 성과가 쌓이고 있습니다. 공허한 방법론들이 아니라 정말 바로 바로 써먹을 수 있는 설계 기법들을 정리해 가고 있습니다. 여전히 구호 뿐이라고 여겨지신다면 거듭 사과 드리며 이만 물러 가겠습니다.

P.S.

1970년대 시절 대한민국 코더는 쉽게 말해서 '타자수(typist)'였습니다. 개발자가 연필로 종이에 작성한 코드를 건네주면 열심히 자판을 두드리고 그 결과 OMR 카드처럼 생긴 종이에 구멍이 뚤립니다. 그걸 차곡차곡 쌓아서 인식기(데크)에 넣으면 프로그램이 실행되는 겁니다. (이건 제 은사님이 대한민국 최초의 프로그래머 중 한 분이시기 때문에 증언을 기억하는 것입니다.)

그런데, 세월이 지나니 개발환경이 좋아져서 개발자가 직접 키보드로 명령을 입력하는 시대가 도래했죠. 코더가 있던 시절에는 개발자 여러명에 코더 한명씩 이었기 때문에 나름 대우를 받았지만 결국 다들 직장을 잃었습니다.

예전에 분명히 발생한 현상이 미래에는 없을 거라고 어떻게 장담하겠습니까?