느린 걸음으로 살아가기

최근에는 웹 구축을 위한 최신 트렌드 정보를 수집하기 위해 스프링, 스트럿츠, iBatis 등 외국에서 많이 각광받고 있다는 오픈소스 프레임워크들에 대한 자료를 수집하고 있다. 금융권 차세대 프로젝트를 수행하면서 필요한 요소 기술을 확보하기 위함인데, 아무래도 시간도 부족해서 한글로 작성되거나 번역된 자료를 찾으려고 했는데 정말 눈을 씻고 찾아봐도 아주 단순한 단서 외에는 얻기 힘들다. 국내 저자가 발간한 서적을 읽다가 실천 가이드는 될지언정 설계 개념을 파악할 수 없어 다시 번역서를 찾아서 보게 된다.

어차피 최신 기술은 외국 사이트에서 찾아봐야 한다는 결론에 도달하게 되지만, 대학 시절 하이텔 게시판에 접속하여 화면을 갈무리하고 도트 프린터의 헤드가 뜨거워질대로 뜨거워져 결국 망가질 때까지 프린트 해대며 읽던 설레임을 되찾을 수는 없는 것일까? 

오히려 예전보다 외국의 최신 기술을 찾기 쉬워졌지만 외국의 기술을 찾는 도구도 구글이고, 외국 기술을 가져다 쓰기는 하지만 결국 그것보다 낫거나 비슷한 기술을 만들 수도 없다는 한계를 절감한다. 15년 전에는 그래도 한국 토종 기술로 제작되는 툴과 잘팔리지 않아도 외산 솔루션으로 대체할 수 없는 한국 제품만의 매력을 지니고 있는 제품들이 있었다. 하지만, 지금은 외산 솔루션도 금새 한글화 되기 때문에 국산이 발붙일 틈이 없다.

더욱 심각한 문제는 외국의 오픈소스 개발 커뮤니티를 보면 굉장한 열정과 파괴력으로 거대 기업들을 무릎 꿇게 하고 있는 것을 보게된다. EJB를 대체하고 보완하는 기술이 오픈소스 커뮤니티를 통해 나오고 있다는 것 자체로도 놀라운 일이 아닐 수 없다. 스포츠에 비교한다면 아마추어들이 프로를 이기고 있는 것이다. (물론 그들이 낮에는 프로로 돌변하지만....)

나를 포함해서 한국 엔지니어들은 외국의 트렌드를 쫒아가기에 급급하다. 아니, 아예 쫒아가지고 못하고 있는 부류들이 더 많다는 것이 현실이다. 이번 차세대 프로젝트를 하면서 극단의 최신 기술과 10년도 더 된 기술들이 하나의 시스템에 혼재되어 있는 것을 보고 경악하고 있는 형편이다.

그럼에도 불구하고 계속 기술의 공유와 커뮤니티의 활성화를 기대하는 것이 나을 것인가? 아니면, 그저 외국의 기술 발전을 꾸준히 따라가는게 충실할 것인가? 어려운 딜레마 이기는 하지만, 결국 외국 기술을 국내에 도입하기 위해서는 국내 환경에 적응을 시키기 위한 가공이 필수적이다. 혼자서 하기는 어려운 일이니 쉽지 않겠지만 커뮤니티가 있을 법한 곳을 계속 기웃거릴 필요가 있다.

이런 말을 하면서도 프로젝트들을 통해 학습한 것들을 온라인 상에 내놓는 것에 대해 망설이게 될 때가 많다. 나 말고도 무수한 사람들이 이런 기술들을 체득했는데 왜 다들 공유하지 않는 것일까? 밥그릇을 지키기 위한 본능 때문일까? 아니면 귀찮기 때문일까? 혹은 너무 바빠서...? 고백하자면 온라인 상에 자료를 올리려다가 나 역시 첫번째 이유로 망설이게 된다. 굳이 변명하자면 제목 그대로 한국 IT 시장이 너무 좁아서 그렇다고 말하고 싶다. 밥그릇 수가 너무 적다. 하지만, 파이를 키우기 위해서는 기술의 가치를 알고 도입하고자 하는 사람이 많아야 한다. 오픈 커뮤니티의 활성화가 어려운 진짜 이유는 이런게 아닐까?

그렇기 때문에 누구나 무엇이든 할 수 있을 거라고 믿는 사람이 있을까? 가능성이 곧 능력이라는 논리는 성립하는가? 하늘에서 돈이 떨어질 가능성이 아예 없는 것은 아니나 그럴 가능성이 아주 낮다면 무시할만한 것이 된다. 즉, 거의 zero에 가까운 수(어려운 말로 zero에 수렴하는 값)은 그냥 zero(0)라고 표현하는 것과 같다.

살아오면 무수한 갈등을 겪어 왔지만 가장 오래되고 그치지 않는 갈등이 바로 '가능성'에 대한 문제다. 부모, 친구, 직장상사, 스승 심지어 거의 관계없는 타인까지 '무한한 가능성'이라는 상투적인 표현을 들이대며 그들의 요구이거나 혹은 희망, 부당한 의무, 강요된 책임감을 주입하려 든다. 해보면 어떻겠는가의 제의 수준을 넘어 왜 못하는가? 시도하려 하지 않는 것도 죄는 아닌가? 하는 우회적인 비난을 전가할 때가 많다.

여기서 문제는 두가지로 요약된다.

첫째, 이런 책임(의지)를 강요하는 사람들은 상대가 요구(책임)을 수용할 능력이나 가능성이 얼마나 되는지 감안하지 않는다. 즉, 자신의 욕망을 상대에게 무조건적으로 투영하려고 든다는 것이다. 바위에 금칠을 한다고 해서 그게 금덩이가 되는게 아니다.

둘째, 강요를 당하는 대상에게 능력이 존재한다고 한들 그에게 문제를 해결할 필요가 있는지를 따지지 않는다. 우리가 밥을 먹는 이유는 배가 고프기 때문이고, 돈을 버는 것은 돈이 주는 안락함 때문이다. 사자는 배가 고프지 않으면 사냥하지 않는다. 사자에게 사냥을 강요할 수는 없는 것이다. 인간도 다르지 않다. 의욕을 느끼지 못한다면 능력이 있어도 도달하지 못하고 만다.

첫번째 문제의 원인은 설득을 하려는 사람이 비이성적인 판단을 한다는 것이고, 두번째 문제의 원인은 설득 대상에 대한 감정적 이해가 부족하다는 것이다. 무언가를 타인을 통해 실현하고자 사람은 이성적이며, 동시에 감성적이어야 한다. 어느 한 쪽에 치우치면 원하는 것을 이룰 수 없다. 너무 공부를 많이 한 사람들이 성공하지 못하는 이유는 남을 지나치게 계산적으로 바라보기 때문이고, 너무 열정적이어서 실패하는 사람은 상대의 능력을 측정하지 못하기 때문이다.

고래는 좁은 강에서 살 수 없다. 이런 명제를 뒤집어 생각해 보면 고래 새끼를 작은 수조에서 키운다면 제대로 크지 못하거나, 사는 환경이 열악해서 오래 살지 못하게 될 것이다. IT 개발자는 10년이면 정년이라고 하는데, 은행 차세대 프로젝트에 참여해보니 내가 큰 착각을 하고 있었다는 것을 깨닫게 된다. 이곳에서는 아예 20대를 찾아 볼 수 없다. 40대 아저씨들까지 실무를 뛰고 있고, 가장 최신의 기술을 도입하는 것을 너무나 당연히 생각하며 제대로 설계하기 위해 무려 5개월의 기간을 투자한다. 한국에서 가장 비싼 땅에 위치한 빌딩 전체를 IT 개발자들이 독차지 하고 있고, 2년에 걸쳐 프로젝트를 진행하는 것이다.

작은 프로젝트를 하고, 단기간에 끝내야 하는 일들을 맡으면서 후배들에게 분석설계와 최신 기술, 훌륭한 아키텍쳐의 중요성을 떠드는 일은 고단한 일이다. 객체지향에 대한 제대로 된 개념을 가진 사람을 만나는 것도 운이 따라야 하는 일이었다. 하지만 거대한 차세대 프로젝트를 컨설팅하는 업무를 맡게 되자 상황이 급반전한다. 남들보다 한발자국 앞서 나가고 있다고 생각했으나, 나와 같거나 더 나은 수준인 사람들이 즐비한 것이다. 내가 도입해야 한다고 주장하던 진보가 이 곳에서는 이미 당연한 현실이 되어 버렸다.

사람이 처한 환경이 좁아서 어쩔 수 없다라는 생각을 가지고 상황에 적응을 하게 되면 커나갈 수가 없게 된다. 내가 만일 작은 프로젝트들을 전전하면서 남들보다 조금 더 잘 하는 수준에 만족하고, 노력을 게을리 했다면 지금의 프로젝트에 참여할 수 있었을까? 우월한 의식에 젖거나, 불평만을 늘어놓거나, 체념해 버린다면 호랑이 새끼라고 할지라도 결국 고양이로 살아가게 될지 모른다.

내가 뛰쳐 나가려 애썼기 때문에, 상황이 나아지기를 기다리는 것보다 더 나은 상황으로 뛰어들고자 애썼기 때문에 지금의 기회를 얻게 된 것이다. 기회는 잡으려고 하는 자에게 주어지는 것이다. 그저 기다리는 자에게는 변함없는 현실만이 존재할 뿐이다. 현실에 적응하던가, 아니면 좁은 벽에 부딪치다 고통스럽게 살다 사라지던가.

앞선 글에서 단지 프로그램을 작성할줄만 아는 개발자는 코더일 뿐이다라고 비판했지만, 사실 좋은 아키텍트로 성장하기 위해서는 가장 먼저 착한 코더가 되어야 한다. 일단 돌아가기만 하면 된다라는 자세로 코딩을 수행하는 개발자는 절대로 좋은 개발자가 될 수 없고 단명하기 마련이다. 거대한 피라미드를 짓는데 모래로 쌓을 수는 없지 않은가? 가장 단단한 돌을 고르고 골라 하나씩 하나씩 깍아내고 쌓고 또 쌓는 아주 단순하고 기본적인 일들이 반복되어야 하는 것이다. 물론 아키텍트가 직접 모든 코드를 작성하는 것은 아니겠지만, 아키텍트 자신은 성실한 자세를 견지하지 못하면서 남에게 요구할 수 있겠는가? 한번 더 다른 시각으로 보자면 어떤 방식으로 코딩하는 것이 올바른 것인지 모르는 사람이 시스템의 완성도를 검증할 수도 없게 되는 것이다.

아파치 재단에서 개발된 소스나 썬에서 개발된 자바 API 코드를 들여다 보면 소스 코드의 길이보다 주석의 양이 10배가 넘는다는 것을 보게 된다. 코드 한 줄, 한 줄 작성하는데 있어서 철두철미하게 세세한 설정에 신경을 쓰고, 줄맞추기도 게을리 하지 않았다는 것을 알 수 있다. 만일 국제적으로 프로그램 작성 능력에 대한 나라별 순위를 따진다면 우리나라는 능히 꼴찌를 놓치지 않을 것이다.

대충 대충 프로그램 작성하고 변수명도 a, b, c를 즐겨쓰는 개발자들에게 나름의 변명거리가 있기 마련이다. 시일이 촉박하고 아무도 알아주지도 않고 돈도 적게 받는데 왜 그런 수고를 들여야 하는가라고 반문하기도 할 것이다. 아무도 알아주지 않다가도 그대가 더 나은 회사로 옮기고 싶고, 더 나은 개발자가 되고 싶고, 최고라는 소리를 듣고 싶을 때 남들에게 당신이 작성한 소스를 내어 보여야 하지 않을까? 그럴 때 지금 속으로 뇌까리고 있는 변명이 무슨 소용이 있겠는가? 지금이 아니면 언제 제대로 된 소스를 작성할 수 있을까? 언젠가 좋은 회사에 들어가게 된 후라고 한다면, 마치 로또 당첨된 후에 열심히 살겠다고 말하는 것과 다른게 무얼까?

프로그래밍 언어라는 것은 그리 단순한 시스템이 아니다. 코드 한줄, 문법 하나하나에도 수많은 개발자들, 학자들의 고뇌와 철학이 응축되어 있는 것이다. 가장 유명한 C언어 프로그램을 한번 들여다 보자. 겨우 단 4줄에 불과한 프로그램이지만, C 언어를 창조한 사람의 철학이 담겨 있는 프로그램이다. 제대로 이해하지 못하면 제대로 쓸 수가 없다.

#include <stdio.h>

main()
{
    printf("hello, world\n");
} 

아주 단순한 코드들이지만 그 안에 담겨진 C 언어의 미학을 옅볼 수 있다.

1. 간결하고 단순함

최근에는 C 언어 이전에 나온 언어들을 겪어본 개발자를 거의 볼 수 없게 되었지만, 포트란, 코볼, 심지어 어셈블리 언어를 이용해서 화면에 한 문장을 출력하려면 최소한 A4 한장이 넘는 분량의 코드를 작성해야 했다. (3년 전에 모교에서 어셈블리 과목을 3학기 동안 강의한적 있는데 어셈블리의 난해함과 지루한 코딩에 질린 학생들이 한학기가 끝나도록 화면에 구구단 출력하는 프로그램 정도를 겨우 만들 수 있었다.)

이전의 언어에서는 불필요한(?) 각종 선언과 길고 긴 예약어들, 그리고 까다로운 제어 문장으로 개발자들에 불필요한 노동을 강요하곤 했다. 하지만, C 언어는 최대한 타이핑을 줄일 수 있도록 영어단어가 아니라 괄호({})와 샾(#) 등을 기호를 언어에 도입하는 파격을 감행했다. 물론 부작용도 있는데 # 문자의 의미에 대해서 제대로 아는 개발자가 몇이나 될까? 우리 회사 개발자 10명에게 물어보면 아마도 9명은 대답을 못할 것이다.

2. 구조적 프로그래밍

여러 줄의 프로그램 코드를 괄호로 묶을 수 있다는 것은 무얼 의미할까? 더 나아가 괄호로 묶은 소스들의 묶음들이 중첩될 수 있고 (이중 루프를 떠올려 보라), 묶음에다가 이름을 붙일 수 있다는 것(함수를 만든다는 것)은 구조적 프로그래밍 시대의 도래를 알린 신호탄 이었다. 이전 언어에는 이런 식의 작성법이 거의 불가능했다.

거창한 표현으로 패러다임의 변화(혹은 진화)라고 하는 것인데, 괜히 어려운 말로 하지 말고 쉽게 말해보자. 인간은 날 수 없다라는 명제가 있다. 아니 왜 못 날아? 그럼 날 수 있게 도와주는 기계를 만들면 되지라고 말하고 실제 그런 기계를 만들어 내는 시도를 통해 세상을 바꾸는 것, 이런 걸 패러다임의 변화라고 한다.

3. API 제공

printf()는 무엇인가? 개발자가 스스로 만들지 않았지만 이미 만들어져 있어서 사용할 수 있는 함수를 의미한다. 그런데 이걸 잘 들여다 보면 고정된 문법이나 명령이 아니라는 것을 알 수 있다. - 언어가 제공하는 작업 도구 중에서 명령문이나 연산자(+, -, *, /, =)는 확장이 불가능한 도구다. - 즉, 추가 확장이 가능하다는 것을 암시하고 있는 것이다. API라는 개념이 널리 쓰이게 된 과정에서도 C언어는 지대한 공헌을 했다. 이전의 언어에서도 서브루틴 호출이라는 개념이 없지는 않았지만, 본격적으로 적용되기 시작한 시점은 아마도 C언어 이후로 알고 있다. C언어에서 함수를 만든다는 것, 코드 블럭을 만드는 작업은 아주 쉽기 때문이다. 단지 앞뒤에 괄호만 넣어주면 된다. 함수를 해체하거나 둘 이상의 함수를 합치고자 할 경우에는 괄호를 빼면 된다. 이토록 단순한 특성 때문에 무수히 많은 오픈 소스와 무료 라이브러리들이 세상에 만발하게 된 것이다.

우리는 이제까지 어쩌면 자신이 다루는 도구에 대해서 너무나 무관심하지는 않았는가 반성해야만 한다. 아주 단순한 코드들에 담긴 여러가지 숨겨진 지식들을 하나씩 파헤치다 보면 오히려 거대한 시스템을 설계하기 위한 영감을 얻을 수 있게 된다. 마치 인간이 존재의 근원을 알기 위해 DNA를 연구하는 것처럼 말이다. 이제 한가지 질문을 남겨 보자. # 문자의 의미는 무얼까? #include의 의미는 그리고 stdio는 무엇의 약자일까?

한동안 미루어 왔던 아키텍쳐 설계에 대한 글쓰기 작업을 다시 해 볼 생각이다. 마침 새롭게 시작되는 프로젝트에서 맡게된 업무가 모 은행 인터넷 시스템 아키텍쳐 설계이다 보니, 업무와 병행해볼 요량이다. 아키텍쳐라는 용어가 주는 부담을 덜고 좀 더 체계적으로 접근할 수 있도록 첫 시작은 미시적인 관점부터 얘기해볼 생각이다. 예전에 써두었던 글들을 다시 재활용하게 될지도 모른다.

소프트웨어 그리고 나아가 소프트웨어 아키텍쳐의 개념을 이해하기 위해서는 그 기반이 되는 하드웨어를 먼저 이해해야 한다. 프로그래머들에게 '컴퓨터(computer)란 무엇인가?'라는 질문을 던졌을 때 아무런 망설임 없이 한 마디로 설명하는 사람은 몇이나 될까? 스스로 전문가라고 자부하고, 컴퓨터를 생계의 수단으로 활용하는 사람들이지만 막상 컴퓨터라는 도구를 제대로 이해하는 사람은 많지 않다. 그저 도구일 뿐이지 잘 쓰면 되지 않는가라고 말할 수 있지만 정말 그런가, 다시 한 번 생각해 볼 문제다. 가정주부에게 진공청소기의 원리를 설명할 수 있느냐고 질문하는 것은 적절치 못하다. 하지만, 더 나은 진공청소기를 만들어보고자 하는 패기 있는 젊은 엔지니어라면 그런 질문에 답할 수 있어야 할 것이다. 이런 상황을 프로그래머에게 대입해보자. 우리는 컴퓨터 하드웨어 그리고 소프트웨어의 구조를 제대로 이해하고 개발하고 있는 것인가? 예전(?)에는 프로그래머 중에서 하드웨어 전공자가 많았고, 컴퓨터공학과에 대한 인기가 높고 저수준의 어셈블리 언어를 접해본 개발자들이 많은 시절에는 이런 질문이 불필요 했다. 하지만, 지금은 프로그래머가 되고자 회사에 입사원서를 낸 직원들 중 많은 수가 머뭇거리며 대답할 말을 찾지 못해 헤매는 표정을 드러내고 만다. 몰라도 프로그램 개발하는데 당장 지장은 없다. 책에 나온 예제대로 키보드를 따닥따닥 눌러대면 손쉽게 누구라도 홈페이지를 만들어 낼 수 있으니까 말이다. 프로그램을 만드는 일이 정말 쉬워진 시대인데 왜 고리타분하게 이런 말을 할까 싶은 사람도 많을 것이다. 질문의 의도는 '원리', '근본'을 이해하고 있어야 한다는 주장이다. 왜 원리와 근본을 알아야 하는 것일까? 더 나아가 얘기해보자.

대학 시절 '어셈블리 언어'라는 과목을 수강하게 되었는데 첫 시간에 학생들에게 던진 교수님 한마디는 '공학(engineering)이란 무엇인가?'라는 질문이었다. 공대에 진학했으나 자연대(순수과학)과의 차이가 무언지도 모르는 학생들을 깨우치고자 하신 것이고, 교수님은 공학의 목표는 '문제를 해결하는 것이다(problem solving)'라고 설파했다. 그렇다면 컴퓨터공학 혹은 프로그램을 제작한다는 것을 앞서의 정의에 따라 다시 설명해보자. 컴퓨터를 이용해서 문제를 해결하는 것이라고 말할 수 있다. 그런데, 프로그래밍 언어를 배우는 책에 나오는 대로, 혹은 인터넷에서 구할 수 있는 예제대로 프로그램을 제작하고 그것을 동작시키는 것이 문제 해결인가? 아니다. 그건 단지 누군가 배운 그대로 컴퓨터를 이용(use)하는 것 뿐이다.

누군가 당신에게 프로그래머인가? 라고 물었다. 당신은 그렇다라고 말할 것이다. 그러면 프로그래머인 그대의 진정한 역할 혹은 사명은 무엇인가? 당신에게 질문을 던진 사람이 제시하는 문제들을 해결하는 것이다. 당신에게 질문하는 상대는 일정하지 않다. 즉, 은행 직원으로서 예금과 대출 업무을 담당하는 사람일 수도 있고, 편리한 동영상 제작 도구를 찾는 방송 관계자일 수도 있다. 그리고 당신은 도구(컴퓨터)를 이용해서 주어진 문제들을 해결해야만 한다. 프로그램 짜는 법을 가르치는 책에 은행 업무에 대한 설명이 나와 있지 않으며, 온라인 게임을 제작하는 방법이나 복잡한 주식거래 과정에 대한 설명도 없다. 그런데 프로그래머는 전혀 생소한 문제들을 해결해야만 한다. 공학도 혹은 문제 해결자로서의 프로그래머가 가져야 할 소양은 단지 프로그래밍 언어를 구사할 줄 안다는 것 이상을 의미하는 것이다. 솔직히 골치 아픈 문제가 아닐 수 없다. 문제가 단지 하나가 아닌 것이다. 도구를 잘 활용해야 한다는 것과 전혀 모르는 비지니스들을 이해해야 한다는 것이다. 후자는 사전에 대비할 수도 없는 문제니 적어도 도구를 잘 이해해야 하지 않을까?

게다가 도구를 단지 사용할 줄만 알아서는 문제를 해결하기 힘들다. 도구를 제대로 이해해야만 그것을 응용하고 개선할 수 있는 것이다. 비유를 들어서 설명하자면 이렇다. 자동차를 개조하기 위해서는 자동차의 구조를 이해해야 한다. 단지, 운전 면허를 가지고 있다는 것만으로 개조는 할 수 없지 않은가? 마찬가지로 컴퓨터 프로그램을 작성할 줄 안다고 해서 고도의 시스템을 설계하고 구축할 수는 없다. (업계 용어로 단지 프로그램을 작성할 줄만 아는 사람을 코더라고 한다.)