TNC에서 구글로 가게된 이동하님의 글이다. http://kunno.net/
왠지 나와 비슷한 생각을 갖고 계신 분 같다는 생각을 많이 하게됐고, 공감가는 부분이 많아 스크랩 해둔다.
현장중계! 대한민국 개발자의 도전과 희망
3부, 개발자 생활 리포트
“내 소망은 노력하는 개발자로 남고 싶다는 것이다”
이 글을 통해 필자가 개발자로서의 현재 위치까지 어떻게 오게 됐는가를 되돌아보며 개발자로 살아남을 수 있었던 생존전략을 이야기하고자 한다. 그리고 연구를 놓지 않으면서도 개발자가 된 필자의 입장에서, 연구자와 개발자에 대한 생각을 말하려고 한다.
박사 과정 말년차 때 IBM의 홍세준 박사의 수업을 듣고 있었던 기억이 난다. 4~5년이 지나버려 기억이 가물가물하지만, 연구자(researcher), 개발자(developer) 중 어떤 사람이 될 지 자신의 역할을 결정할 필요가 있다는 내용의 얘기였다. 물론 둘 사이에 확실한 경계가 있는 것도 아니고 대부분 연구와 개발을 동시에 수행하게 될 것인데, 어느 쪽에 더 중심을 둘 것인지에 따라 배워야 할 것들과 미래의 목표가 달라진다는 것이 핵심이었다.
이 글을 통해 필자가 개발자로서의 현재 위치까지 어떻게 오게 됐는가를 되돌아보며 개발자로 살아남을 수 있었던 생존전략을 이야기하고자 한다. 그리고 연구를 놓지 않으면서도 개발자가 된 필자의 입장에서, 연구자와 개발자에 대한 생각을 말하려고 한다.
무엇이 날 여기까지…
원고 청탁을 받고 초안을 써서 담당 기자에게 보여줬더니, ‘개발자가 어떻게 해야 한다’, ‘이런 것을 준비해라’라는 내용보다는 ‘나는 어떻게 했다’를 적어달라고 해서 당황했다. ‘어디서부터 시작해야 할까’라는 고민부터, 일대기를 쓰자니 그간 잘했다 싶은 것이 없어서 글로 옮길만한 내용이 없기도 하고, 무엇보다도 개발자로서 살아온 이야기를 하자면 대학 때부터 현재까지 살아왔던 내용을 밝힐 수밖에 없다는 것이 고민이었다. 세상에 널리 알리고 싶을 만큼 치밀하게 살아오지 못했기 때문이다.
필 자는 대학에서 전산과를 졸업했고, 인공지능, 데이터베이스, 데이터 마이닝 분야로 전산학 석사·박사 학위를 국내에서 받았다. 처음부터 의도해서 전산과에 입학했던 것은 아니고 필자가 입학했던 대학은 입학하는 시점에서는 학과를 결정하지 않는 대학이었는데, 대학을 다니다 보니 의도하지 않게 전산과 과목을 많이 듣게 되었고 이수한 학점 수 때문에 졸업하기 위해서는 전산과로 전공을 정할 수밖에 없었다.
전산학이 우스웠던 대학시절
그 당시 필자의 ‘전산’에 대한 생각은 수업시간에 배운 장난 같은 프로그램(복잡해 봤자 장기 게임)에 대한 기술을 배우는 과목으로는 직업으로 삼기에는 곤란한 분야라는 생각이 고작이었다. 전산학이 장난스럽다는 생각 정도였고, 학교에서 충실하게 짜여진 과목들인 알고리즘, 오토마타, 컴파일러, 컴퓨터 구조 등의 주요 과목들이 전혀 관련성이 없는 과목이라고 생각하고 있었다(이런 생각은 순전히 필자의 책임이고 학부 때 교수들에게 감사와 사죄의 말을 이 자리를 빌어 하고 싶다).
대부분의 사람들과 같이(요즘은 달라졌을지도 모르겠다) 필자 또한 대학 때 수업에 그리 충실하지 못했다. 대부분 과목에서 프로그램 실습이 상당히 많았는데 항상 팀원에게 미루거나 엉터리로 해버리곤 했다. Fortran, Pascal, C, 어셈블리, 하드웨어 제어 언어까지 배우고 DBMS나 OS, 컴파일러 등을 직접 만들어보는 잘 짜여진 수업을 거쳤는데도, 그 당시까진 C 언어 기준으로 딸랑 1000라인의 프로그램을 짤 수 있는 정도밖에 안 되는 실력이었다. 수업을 충실히 따라 갔다면 한 사람의 역할을 할 수 있는 개발자가 되었을 텐데 말이다.
석사 과정 진학에도 특별한 동기는 없었다. 주위의 같이 놀던 친구들이 진학하길래 따라 한 것뿐이다. 석사 과정에 입학해서 몸담을 연구실을 결정해야 했었다. 이것은 15년 후인 현재의 필자를 결정한 중요한 사안이었다. 여러 연구실 중 필자는 자유로운 연구실 분위기에 이끌려(선배 누나가 예쁘다는 그런 이유는 절대 아니었다) 인공지능(AI: artificial intelligent) 연구실을 선택했다. 그 연구실은 당시 AI에서 유행하던 전문가 시스템(expert system)이 주된 연구 분야였는데, 뉴럴 네트워크(neural network)도 연구하고 있었다. 대학원 연구실은 지도교수의 왕국이라 할 만큼, 지도교수의 의사에 따라 개개인의 연구 범위가 결정되기도 하고 석사 과정 2년 내내 아주 좁은 분야만을 연구하기도 하는데, 필자가 선택한 연구실은 개개인이 선택할 수 있는 연구 범위와 분야가 매우 자유로운 분위기였다. 석사 과정 사이에 지도교수의 관심 분야, 선배들이 선택한 연구 주제, 연구비를 받기 위한 연구 과제가 변함에 따라 데이터베이스 분야 및 지능 에이전트(intelligent agent) 및 데이터 마이닝 등 여러 분야로 연구 주제가 확대되었고, 연구실 이름은 IIS(intelligent information systems) 연구실로 바뀌게 되었다.
관심과 집중도가 높아져가고 …
새로운 것들을 접하고 주어진 연구과제들을 수행하다가 2년이 금방 지나버리고 석사를 마친 후의 장래를 결정할 시기가 되었다. 이 당시 필자의 전산에 대한 이해는 수업에서 배운 것들이 그림 퍼즐처럼 짜 맞춰지고 있는 정도였다. 이산수학(discrete math), 데이터 구조, 알고리즘이 하나의 프로그램에 어떤 영향을 미칠 수 있는지, 이것이 어떻게 기계어로 바뀌어서 컴퓨터가 동작하는지, 그리고 프로그램들이 시스템에서 어떻게 역할을 하는지 어렴풋이 그려지고 있었다. 하지만 직접 만들어 보라고 하면 만들 자신이 없는 정도였다. 프로그래밍만의 실력이라고 한다면 3000라인 정도라고 할 수 있겠다(참고로 필자는 대졸 신입사원 면접이 있으면, 손으로 직접 작성한 부분이 1만 라인 이상이 되는 프로그램을 짜봤냐고 묻는다).
그때 필자는 생각했다. 전산학 석사로서, 필자가 지금 아는 거로는 할 게 없다(한마디로 쪽팔린다). 학위를 못 받더라도 진학해서 공부를 해야겠다는 순진하다 못해 바보 같은 생각을 하게 된 것이다. 나름대로 결심한 필자는 같은 연구실에서 진학하고 공부와 연구를 계속했다(이 글을 읽는 후배들에게 절대 이런 진학은 권하고 싶지 않다. 박사학위 과정을 밟으려는 학생들에 대한 조언은 이 글의 주제에 벗어나므로 생략하겠지만, 명확한 연구 주제를 가지고 빠른 시간 내 학위를 받는 게 최선이다). 진학해서는 여러 신기술을 접할 기회가 더 많아졌고, 많은 것을 배웠다. 연구실의 지도교수는 다양한 분야에 관심이 많았었고 그것이 연구실 분위기와 합쳐져서 확대되었고, 여러 분야에 대한 지식을 쌓아갈 수 있었다. 문제는 연구의 깊이와 집중도였는데, 그 영향으로 학위 받는 기간이 길어졌다.
박 사 과정 중 개발자의 이력으로서는 중요한 일들이 있었다. 연구 과제 수행 중에 대기업의 정보 시스템을 분석해보는 기회가 있었고, 여러 차례의 강의를 나가는 것이었다. C/C++ 언어 강의와 데이터베이스 강의를 여러 번 했는데, 나름대로 열심히 준비한 탓인지 프로그램과 데이터베이스에 대해 상당히 이해하게 되었다. 수업을 하면서 매번 필자가 그 수업 중에 제일 많이 배우는 사람이었다. 또한 그 당시부터 대학에 주어지는 연구 과제들도 상당히 현실적인 결과물을 요구하게 되어서 완성도가 필요한 시스템을 설계하고 구현하는 일을 하면서 개발에 대해 어느 정도 감을 잡게 되었다.
학위를 받고는 그 연구실의 학생들과 벤처를 시작했다. 벤처 회사를 시작하게 된 주된 동기는 그 당시 유행이었기도 했지만 나름대로 자신도 있어서였다. 여러 분야에 나름대로 자신이 있던 연구실 동기들이었기 때문에 금방 대박날 수 있을 것 같았다(예상 외로 아직은 조금 더 기다려야 할 것 같다). 또한 필자의 학위 연구 주제도 금방 상용화할 수 있을 것이라고 생각했었다(이것도 아직 조금 더 기다려야 한다). 회사에 온 지 3년간 다른 것들을 더 배우게 되었다. 하나는 돈을 받고 팔 수 있는 프로그램은 ‘그냥’ 프로그램과는 다른 것이라는 것이다. 프로그램을 개발해서 버그를 다 잡았다고 하면 완성까지 10~20% 정도인 것 같다. 또 하나 고객들로부터 많은 것을 배웠다. 훌륭한 고객들은 자신이 필요한 것을 요구하는 도중에 연구에 도전할 만한 것들을 주기도 했다. 또한 기존 시스템을 분석하고 요구사항을 구현하고 설계하고 때론 연구하면서 배우는 것이 쌓여갔다.
개발자로 살아 남기 위해 무엇을 했는가?
필자에게 뭐하는 사람이냐고 묻는다면 개발자라고 얘기할 것이다. 대학에서 강의를 하기도 하고 컨설팅을 하기도 하지만 분석과 설계가 주 업무이고, 데이터 마이닝 프로그램 등 필자가 직접 해야 하는 부분이 있고 회사에서 일하는 분야 위주로 연구도 하고 있다. 예전부터 개발자였고 또한 개발자로 남고 싶다. 그런데 막상 지나온 길을 적고 보니 필자가 개발자로 살아남기 위해 무엇을 했는지 명확히 대답할 게 없는 것 같다. 무엇을 했다기 보다는 닥친 상황에 대처하다 보니까 지금 여기까지 오게 된 것 같다.
꼭 짚어야 한다면 한 가지가 있는 것 같다. 그것은 필자가 잘 하고 좋아하는 부분들을 선택하고자 했던 의지가 항상 있었다는 점이다. 프로그래머로서 필자보다 뛰어난 사람은 주위에 항상 있었지만 프로그래밍은 재미있고 자신이 생각한 것을 확실하게 표현하고 검증할 수 있는 도구란 생각을 갖고 손에서 놓지 않고 있다. 프로그램으로 구현되어 충분한 테스트를 거친 아이디어는 검증된 것이며 프로그래머로서 자질은 부족해도 프로그램을 계속 하고 싶다. 또 분석과 설계는 남의 흠을 잘 잡는 성격 탓인지, 나름대로 잘해내고 있는 것 같고 재미도 있다. 기존의 시스템을 분석하는 것은 그 자체로 많은 공부가 된다. 새로운 시스템 설계는 노력을 들인 만큼 완성도가 높아지고, 이전에 없던 것을 현실화한다는 창조의 기쁨을 느끼기도 한다. 연구는 미래를 위해 관심 가지는 부분이기도 하고 떠맡겨진 것이기도 하다.
나는 어떤 개발자?
앞서 프로그래밍, 분석/설계, 연구에 대해서 언급했고, 이런 일들에 조금씩은 개발자도 관여할 것 같다. 그럼 개발자란 무엇을 하는 사람일까?
개 발자라고 하면 참으로 어떤 직종인지 명확하지가 않다. 프로그래머, 코더(coder), 데이터베이스 개발자 등은 분명히 개발자일 것이다. 개발에서 설계가 차지하는 비중은 참으로 높다. 그렇다면 설계자(designer)는 어떨까? 웹 디자이너는? 50만 개의 상품을 5만 개의 카테고리로 관리하는 인터넷 쇼핑몰에서 상품 카테고리를 결정하고 관리하는 사람도 개발자에 속하지 않을까? 이들도 개발자에 포함시키는 것이 자연스러울 것이다.
연구가 개발에서 동떨어져 있지 않은 시대
최근의 IT 기술의 개발 속도는 매우 빠르기 때문에 종종 신기술이 대학이나 연구소보다 기업에서 먼저 개발되는 경우들이 있다. 최근 들어 연구 주제가 상용화 가능한 기술임이 증명되어야 연구비를 얻을 수 있기 때문에 연구 자체만을 위한 연구 주제가 점점 줄어드는 형편이다. 또한 어떤 제품의 기획 단계나 추가적인 업그레이드 과정에서 신기술이 요구되어 연구가 필요한 경우도 종종 있다. 한마디로 연구가 개발에서 동떨어져 있지 않은 시대인 것이다.
필자의 생각으로는 개발의 영역을 구분해 보면 <그림 1>처럼 나눌 수 있을 것 같다. 물론 프로그램 테스터(tester), 기획자 등 보다 넓은 의미의 개발자에 속할 수 있는 부류가 더 있을 수도 있고, 이런 분류 자체에 이의를 제기할 사람이 있을지도 모른다(이 글 전체에서 다루는 분류 등은 개인적인 생각일 뿐이니 개별적으로 항의해주길 바란다).
모든 프로그램의 논리가 완전히 설계되어 주어진 경우에만 구현을 수행할 수 있는 개발자라면, 코더(coder)라고 할 수 있을 것이다. 프로그램에 대한 설계가 주어졌을 때 전체 프로그램의 구조를 파악하기도 하고 좀 더 효과적인 구현 방법을 생각해 낼 수 있는 개발자라면 프로그래머(programmer)라고 할 수 있을 것이다(좁은 의미의 개발자는 프로그래머라고 인식되고 있다). 그리고 개발된 시스템을 다른 OS나 하드웨어에 포팅(porting)하는 작업도 프로그래머의 역할이므로 프로그래머는 운영체제 및 네트워크를 포함하는 프로그램 환경과 익숙해야 한다.
개발에서 설계의 역할은 주어진 문제에 대해 필요한 분석을 수행하고, 현존하는 기술을 이용해 프로그램에 대한 소프트웨어적인 구조를 구성하고, DB 구조를 결정하고, 하드웨어 및 네트워크를 구성하는 등 목표 시스템의 형태를 그려내야(design) 하는 것이다. 설계자는 시스템 크기와 역할에 따라 개괄적 설계를 수행하는 사람과 상세 설계를 수행하는 사람이 있을 수 있다. 빌 게이츠의 직함이 ‘Chief Software Architect’라고 하는데, 개괄적 설계를 수행하는 사람이라는 의미일 것이다.
개발에서 연구의 역할은 현존하는 기술로써 설계가 불가능한 경우 새로운 기술을 찾아내는 것이다. 실행시간이나 이용 가능한 메모리의 양에 제약이 있어서 현재의 기술로는 원하는 기능을 구현할 수 없다면 연구자가 기술을 개발해야 한다. 또는 연구를 통해 좀 더 빠르고 적은 저장 용량으로 구현할 수 있다면 제품의 경쟁력이 높아지는 것이다.
프로그래머가 보병이라면 설계자는 전략가다. 연구자는 군사기술 연구자다. 독일의 V2 로켓이나 원자폭탄이 2차 대전에서 얼마나 큰 역할을 했는지 기억해 보라. 전략 없이는 전투에서 승리하고 전쟁에서는 질 수 있으며, 아무리 전자기술의 역할이 중요해진 현대전에서도 보병 없는 전쟁은 불가능하다. 개발의 각 역할을 정리해 본다면 <그림 2>와 같을 것이다. <그림 2>의 세 가지 모두 매력적인 역할이고, 개발에는 반드시 필요한 것들이다.
학위를 받고 대학원 연구실 동기들과 벤처를 시작한 지 몇 년이 흐른 지금, 필자 자신을 돌아보면 이 세 가지를 조금씩 하고 있는 것 같다. C++를 이용해서 유닉스나 윈도우에서 실행 프로그램을 개발하면서도, CRM, 웹 분석 등의 시스템 설계도 하며 기존 시스템의 분석도 한다. 한편으로는 새로운 CRM 기법, 데이터마이닝 기법, 웹 분석 기법에 대해 연구도 수행하고 있다. 조금씩 다 한다는 것은 어느 하나 특별히 잘 하는 것이 없다는 의미도 되는 것 같다. 특히 프로그래머라면 당연히 알아야 하는 개발 환경이나 디버깅에 대한 명확한 이해가 부족하고, 설계할 수 있는 범위는 DB가 중심적인 역할을 하는 시스템에 한정되어 있고, 연구자로서는 관심 범위가 너무 넓기 때문에 깊이 있는 연구를 지속하지 못하는 상황이다. 하지만 정해진 범위 안에서는 나름대로 역할을 하고 있다고 자부하고는 있다. 필자 각각의 역할에 대한 비중을 생각해본다면, 개발 20%, 연구 15%, 분석/설계 65% 정도인 것 같다.
놀았던 것이 투자로…
이제 개발자가 좋은 직업이며, 즐겁다고 생각하는 필자의 의견을 뒷받침할 이야기를 해보겠다. 필자는 인터넷 1세대에 속해 있었고 기숙사 생활을 오래한 덕분에 여러 놀이(?)에 노출되어 상당한 시간을 보내곤 했다. 웹이 보편화되면서 현재까지도 상당히 많은 시간을 인터넷에서 쓰고, 쇼핑이든 게임이든 인터넷을 많이 쓰는 습관이 몸에 배어 있기에, 시간을 허비하는 습관이 있다고 생각할 때도 있었다. 그런데 몇 년 전부터 필자의 생각이 조금씩 달라졌다.
당신은 관심 분야가 있나요?
인터넷을 통한 보험이 아직 대중화되지 않을 4~5년 전쯤, 필자는 그 당시 새로 생기고 있던 2~3개의 인터넷 보험 사이트를 평소에 유심히 봐둔 경험을 살려 어떤 보험 사이트의 시스템 개선과 관련된 업무 회의에서 기존 시스템을 빠른 시간 내에 이해할 수 있었고, 관련 업체간 회의에서 충분히 잘난 척을 할 수 있었다.
한 2년쯤 전에는 복권 사이트를 설계하게 됐는데, 설계 개념은 즐겁게 게임을 하면서 복권을 판매하는 것이었다. 이때는 대학교 때의 사행성 게임에 익숙했던 경험이 많은 도움이 되었다. 철없는 초등학교 입학 전부터 해오던 따먹기라는 그 심리적 전투가 게임 사이트, 복권 사이트, P2P 사이트로 확장된 것 같다. 상대방의 포인트를 따먹는 재미, 상대방보다 더 많은 포인트를 가지고 있는 재미는 포인트가 실제 현금화되는지의 여부에 상관없이 사람들의 관심을 끌고 사람들을 사이트에 붙잡아두는 요소가 된다. 필자는 이러한 심리적인 부분을 이해하기에 충분한 많은 시간과 돈을 들여서 ‘공부’를 해뒀다. 이런 부분까지도 이해해야만 ‘중독성’ 있는 사이트를 설계할 수 있다고 생각한다.
또 한 요즘은 대부분의 게임 사이트들이 많은 업그레이드 과정을 거치며 게임 규칙을 합리적으로 만들었지만, 개발자가 해당 게임에 익숙했다면 좀 더 빠른 시간에 안정화시킬 수 있었을 것이라는 생각을 한다. 또한 게임 사이트의 Hi-Low 게임의 규칙을 보면 기획자가 어떤 지역 출신인지가 예상되기도 한다.
얼마 전에는 온라인 게임 사이트에 대한 이용자 행동 분석을 하게 되는 경우도 있었다. 온라인 게임이나 디아블로(Diablo) 같은 RPG를 전혀 해보지 않았거나 반지의 제왕을 책으로 접해보지 않았다면, 온라인 게임의 이용자 행동 분석에 대한 설계는 불가능하거나 상당히 오래 걸렸을 것이다.
또 필자는 애니메이션이나 만화에 대해서도 상당한 시간을 투자(?)했기 때문에 그런 종류의 인터넷 컨텐츠를 보았을 때 주인공들 사이의 뒷이야기가 연상이 되어 그 컨텐츠를 잘 이해하는 편이라고 생각한다. 이러한 일과 관련 없는 것들이 실제 개발 대상을 파악하고 설계를 하는 데에 많은 도움을 주는 것은 놀라운 일이 아니다. 예전에 다음과 같은 내용의 연구 결과를 본적이 있다.
◆ 업무를 담당하고 있는 사람에게 프로그래밍을 가르쳐서 시스템을 개발하는 것이 프로그래머에게 업무를 가르쳐서 개발하는 것보다 빠르다.
정말 이 말이 맞는 것이라면 대부분의 개발자는 필요 없는 사람이 될 것이다. 과거에는 충분히 이럴 수도 있었을 것이다. 왜냐하면 프로그래밍할 내용이 현행 업무를 그대로 전산화하는 정도로 단순하고, 그에 비해 업무의 내용이 프로그래머가 이해하기에는 생소했을 것이기 때문이다. 그런데 세상이 많이 변했다. IT 기술이 발달하면서 개발자가 다루어야 하는 지식이 많아졌다. 숙련된 프로그래머라면 자기가 맡은 부분에 대한 설계 능력을 갖추고 있을 뿐만 아니라 효과적으로 구현할 수 있는 알고리즘에 익숙해야 하고, 복잡해진 운영체제와 네트워크, 데이터베이스 등에 익숙해야 한다. 현업을 맡고 있는 사람들이 간단히 프로그래밍을 배워서 개발할 수가 없는 세상이 되어버린 것이다.
또한 달라진 것은 개발의 대상이 되는 시스템이 우리 주변과 관련 있게 된 것이다. 휴대폰이나 인터넷과 관련된 것들이 대부분이고 거의 모든 개발 대상 시스템이 이들과 관련되어 있다. 인터넷과 휴대폰은 우리 주변에 항상 있고 우리가 매일 이용하고 있다. 이들을 사용하면서 시간을 보내는 것이 쓸데없는 시간 낭비가 아니라 보다 좋은 개발자가 될 수 있는 지식을 쌓는 투자의 시간이 되는 세상이 온 것이다.
필자는 성격이 다소 분석적이고 잡생각이 많은 편이다. 게임을 하든 웹 사이트를 이용하든 왜 이렇게 만들었을까, 이건 어떻게 만들었을까 같은 생각을 하는 버릇이 있다(나름대로 자제하는 습관도 있어서 온라인 게임에 필자 자신이 중독될까봐 상당히 두려워하는 성격이 있다). 한편 주위가 산만해서 인지 현재 하는 일과 전혀 관련 없는 분야에 대해서도 관심을 가지는 경우가 있는데, 그것이 도움이 되는 경우도 꽤 있었다. 성격이나 습관으로 보면, 분석·설계가 주 업무가 될 수밖에 없었을 것이기 때문이라고 생각한다. 이렇게 놀이 문화를 가까이 하면서도 분석적인 생각을 계속 하고 있는 것이 개발자로서 또 하나의 생존전략이라고 생각이 든다. 이것만으로 생각해 보면 개발자는 즐겁고 좋은 직업이다.
우리나라에서 살아남는 개발자
우리나라에서 살아남는 개발자라고 하면 거창한 느낌도 있다. 또한 이 시대에 필자가 끝까지 괜찮은 개발자로 살아남을 수 있냐고 묻는다면, ‘괜찮은’이란 단어에 부담이 느껴진다. ‘나름대로’라면 살아남을 수 있을 것 같다.
개 발자가 되려면 관련 학과를 나오거나 학원을 다니거나 기업에 입사해서 개발 관련 일을 하면 될 것이다. 여기에 괜찮은 훈련을 받으면 괜찮은 개발자가 될 것이다. 그런데 연구, 설계, 구현 중 하나만 정말 잘 해도 훌륭한 개발자가 될 수 있을까?
어떻게 내 능력을 높일 것인가?
필자의 생각에는 좋은 프로그래머라면 정말 많은 것을 할 수 있어야 한다고 본다. 더구나 괜찮은 설계자라면 개발자가 할 수 있는 것을 ‘거의’ 할 수 있어야 하며, 제품 기획을 구현 가능한 설계로 바꾸는 특별한 능력이 필요하다. 설계자는 구현 가능한 설계를 할 수 있는 능력이 있어야 하기 때문이다. 괜찮은 연구자는 당연히 신기술을 개발할 능력과 현재 기술 수준을 파악하고 있어야겠다. 각각 어느 정도 독립적인 영역이라 하나만 잘 해도 개발자로서 부족함이 없을 것 같기도 하다.
하지만 현실에서의 상황은 여러 가지 제약이 있다. 프로그래머라고는 하지만 알고리즘에 대해 무지한 경우도 있고 설계자는 구현이 불가능한 설계를 하기도 한다. 구현 내용을 이해 못 하는 설계자는 설계자가 아니고 기획자다. 기획 부서나 영업 부서에서는 프로그램이 마술인 듯 비용과 인력이 투자되면 뭐든지 개발할 수 있을 것으로 생각하는 경우까지 있다.
우리나라 어디를 불문하고 개발 현장도 비능률적이고 불합리한 부분이 많다. 연구·설계·구현의 각 단계에서 효과적으로 일을 나누어 수행하기에는 전문 인력들이 너무 부족한 상태이고, 사업 등 다른 외부 요인의 영향이 너무 많다. 또 이러한 현실에서는 관련된 사람들과 의견을 나누고 같이 일할 수 있는 대화의 기술이 중요하다. 더불어 같이 일하게 된 사람들의 부족함을 채워 줄 수 있는 개인적인 능력이 매우 필요한 부분이 된다.
필자는 프로그래밍 하기를 좋아한다. 하지만 개발 환경에는 익숙하지 않아 프로그래머라고 할 수가 없다고 생각한다. 그래도 상대적으로 외부 모듈을 사용하지 않는 편인 데이터 마이닝 라이브러리와 같은 경우에는 라이브러리 형태로 완성된 프로그램을 만들어 낼 수 있다. 설계자로는 어느 정도 준비가 되어 있지만 문서화 능력이 떨어져서 필자가 만든 문서를 개발자가 해독(?)하는 데 너무 많은 노력이 든다고 불평을 듣는 편이다. 연구자로서도 나름대로 노력을 하고 있는데, 회사에서 개발이나 설계를 하다보면 각종 학회에서의 연구 결과를 충분히 살펴볼 시간이 적고, 필요한 기술 개발에 필요한 시간이 없는 경우가 많은 형편이다. 이런 식으로 여러 가지 역할을 조금씩 맡고는 있지만 도리어 우리나라의 특성상 이렇게 여러 역할을 수행하는 개발자가 필요한 것 같다. 이것이 또 하나 필자의 개발자로서의 생존전략이라고 할 수 있겠다. 기획·연구·분석/설계·구현의 연결고리가 완전하지 않은 현실이기에 한 사람 한 사람의 개발자가 여러 영역을 이해하고 협력해야만 ‘돈을 받고 팔 수 있는’ 프로그램 또는 ‘현장에서 운영할 수 있는’ 시스템이 완성될 수 있을 것이라고 생각한다.
마지막으로 필자가 가끔 강의를 나가면 학생들에게 하는 이야기가 있다. 단지 강의나 교육을 듣는 등 수동적인 방법을 통해서는 필요한 것의 단 10%만 배울 수 있다. 나머지 90% 중 반 이상은 스스로 찾고, 경험하고, 느껴서 얻는 것이고, 그 외의 나머지는 남을 가르치거나 문서를 만들 때 배울 수 있다. 이 비율은 필자의 의견이자 경험이다. 스스로 찾아서 배우는 것이 효과적이라는 것은 다들 알고는 있지만 실천이 안 되는 부분일 것이다. 그렇지만 스스로 찾아서 배우는 습관이 없다면 개발자로 살아남을 수 없다. 배우는 과정을 멈추지 않는 것, 이것이 최후의 생존전략이다. 강의를 하거나, 문서를 만들거나, 자신이 만든 문서를 주위에 발표하고 의견을 들을 때 상상외로 많은 것을 배우고 깨닫게 되는 것에 놀라곤 했다. 스스로 만든 프로그램의 매뉴얼을 만들다가 새롭게 배우고 발견하는 것들도 꽤 있었다.
성실한 개발자로 남고 싶다
개발자로 살아남기 위한 필자의 전략은 잘 하고, 좋아하는 개발의 영역을 찾고, 문화를 가까이 하면서도 개발에 대한 고민을 계속하며, 개발의 여러 영역을 이해하고 여러 팀원과 협력하여 일하는 방법을 익히고, 배우는 과정을 멈추지 않는 것이다. 긴 이야기를 했지만, 아직도 개발자로서 부족한 부분이 많은 것 같다. 성실히 노력하는 개발자로 계속 남고 싶다.