Thoughts2009.12.08 12:35
그런데 한 가지 의문이 생긴다. 과연 앞서 살펴본 구보씨의 사례는 이상적인 사례(ideal case)일까? 

그렇지 않다. 구보씨의 사례는 여러가지 측면에서 비현실적이다. 비현실적으로 만들기 위해 한 가지 중요한 장치를 뺐다. 어떤 장치일까? 아마 '자기개발' 류의 글들에 비판적인 대부분의 독자들은 어떤 장치가 빠졌는지 눈치 채셨으리라. 바로, 구보씨가 관련된 '프로젝트'라는 문맥이다. 

이 문맥이 '프로그래머를 위한 시간 관리의 법칙'에 어떤 영항을 미치는지 살펴보기 전에, 우선 '성공적인 프로그래머'로 대접받기 위한 가장 결정적인 조건이 무엇인지 다시 한 번 생각해 보자.

자기 관리 능력과 자기 개발 능력인가?

아마 아닐 것이다. 

성공적인 프로그래머로 대접받기 위한 가장 결정적인 조건은, 프로젝트가 요구하는 도메인 지식(Domain Knowledge)를 얼마나 재빨리 습득하느냐에 관계되어 있다. 

아마 이 글을 읽는 여러분은 이런 저런 프로젝트를 하나 이상 수행해 본 경험이 있을 것이다. 계약서 상에 '갑'이 되어 프로젝트를 수행한 경험은 아마 드물 것이고, 보통은 '을'로서 참여했을 것이다. '을'은 보통 요구사항을 수렴하여 그것을 물리적인 시스템으로 바꾸는 일을 수행한다. '갑'은 그 물리적인 시스템이 올바르게 구현되었는지 검수할 책임을 지고, 올바른 요구사항을 주어 개발 과정이 정상적으로 진행되도록 하는 일을 맡는다.

올바른 시스템이 만들어지기 위해서는, '을'은 요구사항이 기술하는 시스템이 운용될 문맥에 대해서 올바르게 알아야 한다. 여러분의 시스템이 무선망에서 동작할 것인가? 아니면 유선 망인가? 무선망이라면 장애물이 많은 환경인가 아니면 탁 트인 광활한 공간인가? 여러분의 시스템이 사용자와 직접적으로 대면할 시스템이라면, 여러분의 시스템은 어느 정도의 사용성을 확보해야 하는가? 여러분은 시스템 사용자에 대해서 얼마나 알고 있는가? 시스템 사용자가 가장 많이 사용하게 될 기능은 어떤 기능이 되리라 예상하는가? 그리고 그 기능의 유무는 소비자의 구매 결정에 어떠한 영향을 미치게 될 것인가?

이런 것들이 여러분이 파악해야 할 도메인 지식이다. 물론 다는 아니고, 그저 예를 좀 들어 보았을 뿐이다.

이 프로젝트 저 프로젝트 널뛰기를 하는 SI 업체에 속한 프로그래머라도, 그 프로그래머가 수행하게 되는 일감에는 어느 정도의 일관성이 존재하게 마련이다. 만일 일관성이 존재하지 않는다면, 여러분이 팀에서 수행하는 역할이 무엇인지가 그다지 분명하지 않다는 뜻일지도 모른다. 그러니 다시 한 번 생각해 보라. 그 일감 사이에 어떤 종류의 일관성이 존재하는가?

어떤 사람은 UI 개발자였다는 이유로 사용자 요구사항에 맞추어 이런 저런 인터페이스를 구현하는 일만을 하고 있다. 어떤 사람은 서버 개발자로서의 경력을 이유로 네트워크의 백엔드(back-end)에 존재하는 서버 인터페이스와 그 내부를 구현하는 일만을 주구장창 하고 있다. 이런 현상은, 팀 내에서 혹은 회사 내에서 자신의 역할에 모종의 일관성이 존재함을, 그리고 외부에서 자신에게 기대하는 역할이나 주어지는 일감에 모종의 일관성이 존재함을 암시한다.

그 일관성(consistency)은 무엇을 의미하는가?

그 일관성은 여러분이 거의 일관된 형태의 도메인 지식 위에서 작업하게 되리라는 사실을 의미한다. 물론 이 말에 동의하지 않는 사람도 있을 것이다. UI 에서부터 서버 플랫폼까지 여기 저기를 뛰어다니면서 땜빵 프로그래밍을 수행하는 나같은 사람에게 일관성 같은 것이 있을 리가 있나요? 하고 반문하는 분들도 계실 것이다. 하지만 그렇더라도, 어느 정도의 일관성은 존재하고, 사실 중요한 것은 그 일관성을 찾는 일이다. 

UI 개발자로서 일관되게 일하고 있다는 사실은, 본인이 User-Experience (흔히들 UX라고 부르는 것 같다) 라고 부르는 도메인 영역에서 일하고 있다는 것을 암시한다. 이 일관성은, 본인이 갈고 닦아야 할 도메인 지식이 바로 그 영역에 존재하고 있다는 것을 증거한다. 

서버 개발자로서 일관되게 일하고 있다는 사실은, 본인이 서버에 관계된 여러가지 속성들 (Scalability, Extensibility, Robustness)에 관계된 도메인 지식의 바탕 위에서 일하고 있다는 사실을 일깨운다. 

이 영역 저 영역 널뛰기 하면서 오만가지 땜빵질을 다 하고 다닌다는 사실은, 회사가 그 사람을 올라운드 플레이어, 그러니까 프로그래밍에 관한 한 모든 영역에 능통한 사람으로 보고, 그에 따라 일감을 준다는 것을 의미한다. (물론 사람이 없어서 그렇게 일하게 되는 불행한 경우도 있다.) 이 사람에게 있어서 도메인 지식은 따라서 좀 더 광활하다. 아키텍처의 영역이, 바로 그가 일하고 있는 도메인일 것이다. 

그런데 도메인 지식을 습득하는 것 하고 프로그래머로서 성공하는 것 하고는 대체 무슨 관계가 있나? 

평생 동안 코드 조각을 리팩터링한다는 지엽적인 문제에 매달려 인생을 보내고 싶다면, 아무 관계가 없다고 믿어도 좋을 것이다. 하지만 다른 차원의 꿈을 꾼다면, 도메인 지식은 중요하다.

이렇게 비유해 보자. 

문제를 푸는 능력을 가지고 있는 사람은 솔루션을 설계하고 그 솔루션의 구현은 다른 사람에게 맡길 수 있다. 하지만 문제를 푸는 능력 자체가 없는 사람은 그냥 시키는 대로 구현만 할 밖에 다른 도리가 없다. 

사용자의 사용성을 어떻게 증진시킬 것인지에 대한 문제에 탁월한 식견을 가지고 있는 사람은, 인터페이스 설계에 지대한 영향력을 미칠 수 있다. (근거 자료만 많이 준비해도 말빨은 먹힌다. 근거 자료도 준비해 본 적이 없는 사람은, 투덜대지 않도록 하자.) 그런 식견이 없는 사람은, 제안은 커녕 그냥 시키는 대로 구현할 밖에 다른 도리가 없다. 평생 '을'로 살게 될지도 모른다. 끔찍하지 않은가?

전체 아키텍처에 대한 식견을 가지고 있는 사람은, 아키텍처를 어떻게 가져갈 것인가에 대해 큰 목소리를 낼 수 있다. 하지만 그런 식견이 없는 사람은, 다른 사람이 제안한 아키텍처 위에 코드를 올릴 뿐 다른 도리가 없다. 설사 구현 과정에서 아키텍처가 불합리한 것을 발견하더라도, 스스로 목소리를 내기를 포기했으므로 쓸만한 우회책을 고안해 내는 것 말고는 달리 할 수 있는 일이 없을 것이다. 

결국, 전문가로 나설 수 있게 하는 힘은 도메인 지식에서 나오는 셈이다.

그렇다면 도메인 지식은 어떻게 획득해야 하는가?

도메인 지식을 획득하려면 우선 자신의 일에 존재하는 어떠한 일관성을 탐지해야 하고, 그 일관성이 관통하는 어떤 영역을 식별해 내야 한다. 세상에는 자신과 비슷한 고민을 하는 사람이 많다. 그리고 알고보면 우리가 한 고민은 이미 누군가가 한 고민일 가능성이 높다. 이런 고민들이 쌓이고 쌓이면, 어떠한 패턴(Pattern)이 만들어진다. 도메인 지식의 큰 부분을 구성하는 것이 바로 이 패턴이다. 사용성에도 패턴이 있다. 아키텍처에도 패턴이 있다. 서버 구조에도 패턴이 있다. 이런 패턴은 시스템을 좀 더 아름답게 만들기도 하고, 편리하게 만들기도 하며, 수십배의 성능을 내게 만들어 주기도 한다. 

중요한 것은, 여러분이 탐지한 일관성이 관통하고 있는 바로 그 영역에, 바로 그 패턴을 상호 소통(communication)하기 위한 어떤 메커니즘이 이미 존재하고 있다는 사실이다. 우리는 그것을 보통 커뮤니티(community)라고 부른다. (commun 이라는 동일한 접두어가 쓰이고 있다는 사실을 재미삼아 보도록 하자.) 

여러분이 도메인 지식을 획득하기 위해 할 수 있는 가장 간단한 방법은, 바로 해당 영역에 비슷한 관심사를 가지고 있는 사람들이 모여 이런 저런 이야기를 나누고 있는 그 커뮤니티의 일원이 되는 것이다. 과학자나 엔지니어들이 모이는 커뮤니티는 비교적 체계화가 잘 되어 있는 편이다. 뭔가 좀 인기 있을라치면 커뮤니티가 생기고 (Erlang에 관심이 있는 사람은 아마 대부분 trapexit라는 사이트의 회원일 것이다) 거기에 사람들이 모인다. 그들은 비단 troubleshooting에 대한 지식만을 나누지 않는다. 

이런 커뮤니티로 가장 규모가 큰 것은 아마 학회(conference)일 것이다. 매년 수십 또는 수백만(?)에 달하는 과학자와 엔지니어들이 이런 저런 학회에 참여하여 자신의 연구 결과를 발표하고, 다른 사람들의 평가를 듣는다. 거기서 우리가 발견할 수 있는 것은, "어떤 문제가 어렵고", "그 문제가 왜 중요하며", "나는 그 문제를 이렇게 풀었다"는 단순한 패턴의 반복이다. 이런 커뮤니티에서 오고가는 이야기를 주의깊게 듣고만 있어도, 도메인 지식의 외연은 확대된다. (시스템 관련 이슈에 흥미가 있는 사람이라면, USENIX 관련 학회에서 어떤 활동이 이루어지는 지 살펴볼 것을 권한다.)

그런 커뮤니티에서 배울 수 있는 것은 단순히 문제 해결의 패턴 뿐만이 아니다. 우리는 상상하지 못한 대규모의 문제를 혹은 우리가 일찌기 상상했으나 감히 풀려는 엄두를 내지 못했던 규모의 문제를 다른 사람들은 어떻게 풀어 나갔는지를 배울 수 있다. 

성공적인 프로그래머가 되기 위해, 여러분은 아마 이런 저런 책들을 많이도 보았을 것이다. Ruby, C++, Erlang, C#, 그리고 이런저런 Effective XXX 시리즈들, 그리고 어쩌면 TDD나 Agile 관련 서적을 비롯한 프로젝트 관리 기법에 관한 이런 저런 책들...

하지만 한 번 자문해 보자.

여러분은 성공적인 팀원으로 머무르고 싶은가, 아니면 성공적인 팀을 이끌고 싶은가? 그것도 아니라면, 성공적인 소프트웨어를 만들어, 여러분이 알고 있는 바로 '그 도메인'의 수많은 사람들에게 팔아먹고 싶은가?

그 질문에 답이 어떻게 나오느냐에 따라, 여러분이 알아야 할 도메인 지식의 규모가 달라지고, 방향이 달라진다. 그냥 성공적인 팀원이나 팀 리더로 머무르고 싶다면, 여러분이 알아야 할 도메인 지식의 규모는 그다지 크지 않을지도 모른다. (물론, 실제로는 엄청나게 크다. 궁금하다면 xper.org 같은 사이트에서 무슨 이야기가 오고가는지 한 번 들어보기 바란다.) 하지만 그 이상이라면, 여러분은 그 이상의 목소리를 여러분이 속한 커뮤니티의 사람들로부터 들어야 한다. 

이런 저런 소셜 네트워크 사이트들이 성공하고 있는 것은 그저 단순한 우연만은 아니다.

[다음 글에서 계속...]

신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. RespectedB

    저는 시작하려는 개발자입니다. 저 또한 트러블슈팅을 위한 패턴을 찾다가 이리로 흘러 들어오게 되었는데, 참 많은것을 느끼고 갑니다. 후배 개발자들을 위해 옥석 같은 조언들 써주셔서 감사합니다.

    2014.02.07 09:49 신고 [ ADDR : EDIT/ DEL : REPLY ]