아주 개인적인 개발자론

이 글은 어떤 분이 댓글로 올린 글에 대한 의견으로 작성하였습니다. 댓글이 무슨 논쟁이 아니라 개인적인 내용이라 저도 그동안 만났던 개발자와 함께 일하면서 느낀 단상입니다.

1.
 대학에서 제어계측공학과를 다녔지만 전공을 전공답게 공부하지 않았습니다. 지나고 보면 프로세서를 이용하여 회로도를 구성, 실험하였던 기억은 납니다. 그렇지만 이런 실험이 직간접적으로 컴퓨터와 연관된다는 생각을 해보지 않았습니다. 관심사가 아니었기때문입니다. IMF이전에 소프트웨어개발사업을 시작하였던 저는 비전공자이면서 비개발자로 그리고  대표로써, PM으로 다양한 개발자를 만났습니다.

 저는 개발자를  Before IMF, After IMF세대로 나눕니다. 이유는 순전히 개인적인 경험입니다. 92년 바른정보를 만들었을 때 구로동에서 청년문화단체에서 일하던 후배한 명과 같이 시작하였습니다. 저는 공학이지만 후배는 인문계열이었습니다. 소프트웨어로 무엇을 해보자고 했지만 직접 할 수 있는 방법은 없었습니다. 그래서 만난 그룹이 풀빛컴퓨팅(Fullbit)입니다. Before IMF세대의 특징을 갖게끔 한 분들입니다. 경력이 오래된 개발자의 글을 읽다 보면 어릴 때부터 프로그래밍에 관심을 갖고 애플등으로 개발한 매니어들이 많더군요. 풀빛컴퓨팅으로 만나서 나중에 같은 회사를 하였던 개발자들도 역시 프로그래밍이 좋아서 모인 사람들이었습니다. 보통은 한두명이 일을 했습니다. 이 시절 가장 큰 프로젝트였던 코스콤 HTS프로젝트도 클라이언트/서버 합쳐서 6명전후정도가 팀을 이루었습니다.  이 보다 두 해 앞서 기술습득을 위해 나우콤 프로젝트에 참여할 때도 전체팀이 10명이 넘지 않았던 것으로 기억합니다.

 Before IMF세대는 이런 특징을 가집니다.
 첫째 프로그래밍을 너무너무 좋아합니다. 누가 가르쳐주지 않아도 스스로 프로그래밍 기술을 습득하여 직업으로서 개발자의 길을 걸었습니다.
 둘째 자력갱생(?)했기 때문에 문제 해결능력은 뛰어납니다.프로그래밍을 하다 발생하는 다양한 난관을 극복할 능력을 가지고 있었습니다.
 셋째 프로그래밍적인 해결능력은 있지만  분석,설계능력을 키울 기회가 없었습니다. 아키텍처라는 말도 별로 없었고 분석,설계프로세스를 명확히 경험하지 못했습니다.
 넷째 프로젝트가 크지 않고 한두명으로 처리할 수 있는 일이 많았기때문에 팀작업을 하는데 익숙하지 않았습니다.

시대적인 한계가 있었습니다.

2.
IMF는 두가지 변화를 소프트웨어산업에 가져옵니다.
첫째는 인터넷혁명 – 나중엔 버블이라고 하지만 – 이 본격화하면서 대대적인 IT투자가 이루어집니다. 아마도 우리나라 역사상 가장 대규모적인 IT투자가 이루어진 시기가 아닐까 합니다. 이 때문에 소프트웨어개발에 대한 수요가 급증합니다. 프로젝트의 규모도 점점 커집니다. 5명전후가 10명이 넘어서고 20명이 넘어서기 시작합니다.

둘째는 산업구조적인 변화, 정치적인 충격(IMF,정권교체)로 소프트웨어개발자를 공급하는 재교육기관이 우후죽순처럼 등장합니다. 그 시절 교육과정은 단순합니다. 기본적인 전산교육을 하고 바로 프로그래밍언어교육, 곧 코딩교육을 합니다. 이런 소프트웨어개발자가 – 대학에서 전산전공인지 아닌지에 상관없이 – 사회에 공급됩니다.

저는 현재 소프트웨어산업이 갖고 있는 대부분 문제가 이때 태생했다고 생각합니다. After IMF세대는 다양한 성격의 개발자들이 섞여 있습니다. 인터넷혁명, 벤처열풍으로 청운의 꿈을 안고 컴퓨터관련 학과에 입학한 사람들, 전공과 관계없이 취업을 위해 재교육기관에서 언어를 배워 취업한 사람들.

 당시 넥스트웨어 혹은 주변에 있던 회사들에 다녔던 개발자들도 역시 혼재되어 있었습니다. 서로 다른 성격을 가지고 있고 일하는 방식도 다릅니다. 전공으로 공부한 사람들은 시스템을 접근할 때 구조적, 시스템적으로 접근합니다. 전체에 대한 그림을 같이 그리고 그에 따라 하부에 대한 설계를 하면서 협력작업을 합니다. 예를 들어 Java를 이야기할 때 JVM을 이해하고 프레임워크도입, 개발프로세스 정립등에 관심이 많은 사람은 전공자입니다. 물론 비전공자가 모두 그렇지 않고 전공자는 그렇다는 주장은 아닙니다. 비전공자중에서 끊임없는 학습과 노력으로 전공자이상의 지식과 경험을 가진 사람이 많습니다. 이 경우 차이를 가르는 요소는 소프트웨어개발을 코딩으로 이해하느냐, 아니냐가 아닐까 합니다. Coder와 Developer의 차이를 말하면 말장난일 수도 있지만  과정으로 놓고 보면 다릅니다.

Before IMF와 달리 시스템은 규모가 커져서 집단작업, 팀작업을 해야 합니다. 소프트웨어도 단순히 돌아가면 되는 것이 아니라 어떻게 설계로, 어떻게 개발하느냐가 중요합니다. 프로젝트의 종료가 소프트웨어 개발의 끝이 아니라 새로운 시작입니다. Before IBM때 요구되었던 개발자와 다른 개발자상을 요구하고 있다고 생각합니다.

 저는 이런 변화상을 2005년전후쯤 느꼈습니다. IMF이전 서점에서 책을 많이 구했습니다. 주로 Unix 혹은 TCP/IP개발과 관련한 원서들입니다. 2005년쯤엔 서점분위기가 달라졌습니다. 다양한 종류의 번역책들, 특히프로젝트, 소프트웨어개발과 관련된 다양한 책들이 서점에 깔려있었습니다. 계기가 된 책은 ‘Joel On Software’입니다. 회사 개발자가 추천해서 실로 오랜만에 전산관련한 책을 도서관에서 빌려서 읽었습니다. 놀라움이었습니다. 얼마 후 ‘피플웨어’도 빌려읽었습니다. 감동이었고 새로운 세계였습니다.

 “아! 내가 알고 있는 소프트웨어개발은 그냥 일부분이구나”
 “소프트웨어개발회사 대표라지만 너무 소프트웨어개발을 몰랐다..”

후회를 했습니다. 벌써 미국등에서 반세기이상 쌓인 경험을 습득하지 못하고 주먹구구식으로 살아왔기때문입니다.
 
3.
 BI와 AI를 절대적으로 구분할 필요는 없습니다. IT기술이 사회에서 차지하는 비중이 높아지고 기술적으로 진화하면서 사회가 요구하는 개발자상이 변화할 뿐입니다. 그리고 변화에 적응하기 위해 노력을 하면 됩니다.  변화의 전제는 무엇일까요? 저는 소프트웨어 개발이 개인작업이 아니라 팀작업임을 인정하는 것이 출발이라고 생각합니다.

예를 들어보죠. 김익환씨가 쓴 책이나 글에서 ‘Peer To Peer Review’을 알았습니다. 그 때까지 기억속에서 개발중 그런 과정을 갖지 않았습니다. 버그가 생겨도, 비즈니스논리를 잘못 구현하여도 개발자가 알아서 해결해야 합니다. 그것이 옳을까요? ‘아니다’라는 생각을 하였습니다. 아무리 뛰어난 개발자라 하더라도 오류를 범할 수 있습니다. “어떻게 오류를 팀단위에서 줄여나갈까”라는 고민에서 P2P Review가 나오지 않았나 생각했습니다.  지금 회사에서 P2P Review등을 하라고 이야기하면 – 사실 저는 개발부서가 아니라 기획부서라 직접적인 명령권(^^)은 없습니다 – 고개만 끄덕입니다.

 또하나 성공하는 개발자이려면 끝없는 학습을 할 자세가 있어야 합니다. 그것은 독서일 수도 있고 개인적인 프로젝트 혹은 오픈소스 프로젝트 참여일 수도 있습니다. 하루가 다르게 변화하는 모든 기술을 습득할 필요는 없지만 흐름을 이해할 필요가 있다고 생각합니다.

 지난 몇 년사이 소프트웨어산업은 제품을 개발,생산하는 산업에서  제품을 이용하여 서비스하는 산업으로 변모하고 있습니다. 여기에 스마트혁명(?)이 일어나고 있습니다. 새로운 능력을 요구합니다. 창의성(Creavity)입니다.  인문학적 소양과 소프트웨어적인 지식을 겸비한 창의적인 인재를 요구하고 있습니다. 너무 힘들죠?(^^)

4.
 제가 개발자와 인터뷰할 때 꼭 물어보는 것이 있습니다. “프로젝트를 시작단계부터 마무리단계까지 완주해본 경험이 있는지, 있으면 각 단계별 역할은 무엇인지” 입니다.  시작을 해서 끝을 맺을 수 있는 능력은 매우 중요합니다. 중요한 이유는 단 하나입니다. 능력이 있어서, 문제해결을 할 수 있어서? 아닙니다.

 이유는 어떤 어려움도 회피하지 않고 돌파하려고 하는 의지입니다. 프로젝트는 팀작업입니다. 제품개발도 팀작업입니다. 내가 모르면 동료가 알 수 있고 동료가 모르면 같이 협의해서 찾으면 됩니다. 동료에 대한 믿음이죠. 프로젝트는 그래도 힘든 일이 생깁니다. 도망가고 싶어 합니다.  

 아주 오래전 어떤 선배는 이런 말을 했습니다.

“아침에 일어나기 싫다. 일어나서 출근해서 일을 하고 일을 하면 닥칠 수많은 문제들을 감당할 자신이 없다. 그래서 그냥 누워있다”

 같은 이유입니다. 그냥 사라집니다. 가방끈하고 아무 관련이 없습니다. 그저 사라지는 사람이 살아온 이력과 품성때문입니다. 그래서 책임을 지울 수 없습니다.

 회피하지 않고 도전할 수 있는 끈기와 의지.개발자에게 아주 중요한 덕목입니다. 여기에 자기학습을 통해 좀더 많은 지식과 경험을 쌓으면 가방끈이 짧더라도 훌륭한 개발자가 될 수 있습니다.

참고로 바른정보시절 아주 좋아했던 개발자가 두명 있었습니다. 한명은 고졸입니다. 또 한명은 전문대입니다. 그렇지만 아주 훌륭한 개발자들입니다. 문제 해결능력은 기본입니다. 그렇지만 사물을 체계적으로 보고  익히려고 노력했습니다. 노력만큼 성장하였습니다. 역시 자세가 중요합니다. 직업의식뿐 아니라 학습하고자 하는 의지등등.

5.
 대표시절 수많은 이력서를 받았습니다. 아니 이력서를 찾아 다녔습니다. 볼 때 최종학력은 보지 않습니다. 어떤 경험을 하였고 어떤 기술을 가졌는지를 봅니다. 많은 개발자들의 경우 프로젝트 수행경험과 개인의 경험이 똑같습니다. 프로젝트에 자신을 가둬둡니다. 아니면 직무에 자신을 가둡니다.  

 예전부터 강조합니다. 다양한 경험을 해볼 기회를 만들라고 합니다. 예를 들면 오픈소스프로젝트 참여하는 것도 좋습니다. 아니면 블로그를 통해 자신의 경험을 체계적으로 정리하려는 시도도 좋습니다. 어느 경우든 주어진 조건이상으로 자신이 노력하여 자신을 성장할 수 있는 노력이 필요하다고 생각합니다.

 주어진 조건는 그냥 조건입니다. 그것을 뚫고 일어나는 것은 나의 노력입니다. 인터넷을 보면 내가 참여하고 나를 성장할 수 있는 다양한 공간이 있습니다. 그것이 언젠가는 가방끈보다 더 중요한 나의 경력이 될 수 있습니다.