저자 : 한국썬마이크로시스템즈 차장 김영남
나는 프로그래머가 알아야 할 것들을 돼지 삼형제에게서 배웠다.
내겐 29개월된 딸아이가 하나 있다. 이제 겨우 말하기에 흥미를 갖게된 딸아이를 위해서 아주 가끔씩(?) 동화책을 읽어주곤 하는데, 다 아는 그저그런 얘기들이지만 실감나게 얘기를 들려주기위한 나의 처절한 노력은 정말 가상하기 그지 없을 정도이다. 그 중에서도 우리 딸아이가 가장 좋아하는 동화중 하나가 바로 돼지 삼형제이다. 이 이야기의 하이라이트는 바로 늑대의 집부수기 이벤트인데, 온 힘을 다해서 입으로 바람을 일으키며 집을 날려버리는 장면을 재현할라치면 우리 딸아이는 너무나 좋아하면서, “또 또 ((주) 다시 해달라는 표현) “ 를 연발한다.
왜 내가 자바 프로그래머의 Career Path를 얘기하기전, 돼지 삼형제를 얘기하는 지 의아해 하는 사람들이 있을 터인데.... 바로 그 곳에 Java 프로그래머로가 가장 먼저 무엇을 염두해야 하는 가에 대한 나의 생각이 숨어있기 때문이다.
자, 돼지 삼형제의 집짓기 프로젝트를 훔쳐보자.
어떤 집을 지을까 : 고객이 원하는 것을 만든다
무엇을 만들든지 간에, 가장 중요한 성공 포인트는 그 물건을 사용하게 될 사람의 맘에 쏘~ 옥 드는 물건을 만드는 것이라 할 수 있다. 우리가 프로젝트를 수행함에 있어서, 가장 많은 시간과 노력을 투자해서, 고객의 생각을 도출해 내고, 또 우리가 이해한 바가 고객의 생각과 일치하는 지 끊임없이 확인하는 작업을 하는 이유가 바로 여기에 있다고 생각한다. 여기서 “사용자의 마음에 든다는 것”은 여러 차원에서 얘기가 될 수 있다. 이를 좀더 전문용어로 설명을 해 본다면 바로 시스템의 품질(Quality)을 만족하는 것이다. 품질을 만족하기 위해서는 고객의 요구사항을 잘 정의해야 하는데, 요구사항에는 크게 기능(functional)과 비기능(non-functional)요구사항이 있다. 기능 요구사항을 집짓기를 예를 들자면, 모든 방에는 창문이 있을것, 부엌과 욕실에는 수도장치가 되어있을 것 등이 될 것이다. 비기능 요구사항은 같은 기능이라 해도 서로 다른 품질(성능)을 요구하게 되는 것인데, 예를 들자면 모든 방의 창은 방음 및 방열기능을 최대(실제 프로젝트에는 이렇게 애매하게 정의해서는 안되겠지만)로 보장할 것, 최소 늑대 두 마리의 입김(초속 XX Km)에도 절대 지붕이 날아가지 말 것 등이 될 수 있겠다. 소프트웨어 개발 방법론의 입장에서 이러한 요구사항을 도출해 내는 과정을 분석(Analysis)이라고 하는 것 쯤은 다 알고 있을터이지만, 대부분의 프로그래머 혹은 개발자들은 이러한 분석 과정은 분석가들의 전유물인양 다소 등한시 하는 경우가 있는 듯하다. 그러나 요즘의 추세를 보면 프로그래머가 갖추어할 소양 중에서, 기술적인 능력은 물론이고 의사소통능력, 문서작성능력, 프리젠테이션 능력 등 커뮤니케이션과 관련된 스킬을 요구하고있는데, 이 중의 한 면이 바로 고객과의 의사소통을 통해서 요구사항을 잘 이해하고 고객의 생각, 고객의 만족을 이끌어내는 시스템을 만들 수 있는 프로그래머를 원하기 때문이라고 해도 과언이 아닐 것이다.
여기에 하나 더 중요한 것은 도메인 지식을 쌓으라는 것이다. 고객과 아무리 의사소통이 잘 된다해도 고객의 비즈니스에 대한 지식이 없다면, 올바른 시스템을 구축하기란 하늘에 별따기보다 더 어려운일이 되고 말것이기 때문이다. 따라서, 프로그래머들도 금융, 국방, 공공 등 가능한한 전문 영역에 대한 비지니스 지식을 다지는데 노력할 필요가 있다.
늑대의 바람을 이겨내자 : 튼튼한 집의 핵심, 아키텍처를 이해하자
자 다시 돼지 삼형제에게로 돌아가보자. 삼형제 모두 기능면에서 자신들이 원하는 집을 지었다고 한다면, 막내만이 집의 안정도면에서 만족할 만한 집을 지었다고 할 수 있다. 이것을 시스템 구축과 한 번 비교해보자. 아키텍처라함은 앞에서도 얘기했듯이 시스템의 기능은 물론 시스템의 성능을 보장할 수 있는 전체 시스템 구조의 근간을 구축하는 것을 말한다. 좋은 아키텍처를 구축하기 위해서는 무엇보다 아키텍처를 좌우하는 비기능요건을 잘 파악하는 것이 중요하다. 막내돼지가 첫 번째 아키텍처 요소를 늑대의 바람에도 견딜 수 있는 것으로 식별했듯이 말이다. 그렇게 일단 아키텍처에 대한 요건들을 파악하고 난 후에는 어떤 재료들을 선택해서, 어떤 방식으로 집을 만드는 것이 좋은가에 따라서 집의 틀을 만들어야 하는 것이다. 이때, 아키텍트는 자신의 경험, 축적된 설계 패턴 등 기존의 자산을 십분발휘하여 가능하면 검증된 방식으로 집을 구축할 것이다. 또한 검증되지 않는 솔루션에 대해서는 Mokup작업이나 모형작업등을 해가면서 솔루션 선택에 대한 검증 과정을 거쳐 아키텍처를 구축할 것이다. 일단 아키텍처가 구축되었다면 나머지 집을 짓는 일꾼들은 아키텍트가 선택한 설계방식이나 재료의 특성에 대한 충분한 이해를 바탕으로 최고의 기술을 발휘하여 멋지고, 튼튼한 집을 짓게 될 것이다. 막내 돼지가 집을 짓는 재료로 벽돌을 선택했지만 벽돌로 집을 짓는 방법을 잘 몰랐다면 벽돌은 그저 좋은 재료일뿐, 늑대의 바람을 이겨낼 수 있는 집을 만들 수는 없었을 것이다. 따라서 여전히 프로젝트 팀을 구성할 때, 프로그램을 잘 할 수 있는 프로그래머의 역할이 중요하고 또 뛰어난 프로그래머와 함께 일하는 기쁨을 얻을 수 있는 이유가 여기에 있다고 하겠다. 즉, 아키텍처가 중요하긴 하지만, 좋은 프로그래머 없이 좋은 시스템은 구축될 수 없는 것이다. 프로그래머들은 이러한 시각에서 아키텍처에 대한 이해를 할 수 있는 능력을 갖추어야 한다. 아키텍처를 이해하기 위해서는 무엇보다 기존의 좋은 아키텍처들을 많이 볼 필요가 있다. 소위 말하는 참조 아키텍처(Reference Architecture)나 Sun에서 발표하고 있는 J2EE, Web Service 아키텍처, 기술 스펙등을 충분히 숙지하고 이해 할 수 있는 능력을 갖추어야 한다. 좋은 아키텍처를 많이 보고 경험한 사람만이 언젠가 좋은 아키텍처를 만들 수 있을테니까 말이다.
에이 !!! 벽돌이 뭐야? : 변화의 흐름을 파악해라.
돼지 삼형제 중에서 첫째와 두째는 각각 지푸라기와 나무로 자신만만하게 자신들의 집을 지었다. 그러면서 벽돌로 어렵게 집을 짓는 세째를 나무랬다. 너무 힘들게 쓸데없는 시도를 한다고. 자 우리 자신을 돌아보자. 이미 알고 있고, 또한 너무 익숙한 나머지 새로운 기술 변화나 시도는 외면한 채, 현재에만 너무 안주하려고 하는 것은 아닌지. 거기에 더하여 새로운 기술을 습득하고 적용하는 사람들을 향해 비난과 배척의 눈길을 주지는 않았는지. 그러나 분명한 것은 새로운 기술 동행에 대한 시각을 반드시 가져야 한다는 것이다. 어찌보면 이미 여러분은 Java라는 훌률한 도구를 선택하는 눈을 가지고 있다고 볼 수 있다. 과거를 돌아보면 Java가 처음 국내 도입 될 시점에 지금의 전성기를 예상하는 사람은 그리 흔치 않았으니 말이다. 그래서 프로그래머는 Java 자체에 대한 기술 수준 향상도 중요하지만, 전반적인 IT 기술의 흐름을 항상 주시하고 있어야 한다. 정기적인 세미나나(요즘은 webinar 형태로 진행되는 것들도 많이 있는 것으로 안다) 커뮤니티 활동 등을 통해서 최신 정보를 교환하고 새로운 기술에 대한 예측을 놓고 토론도하고 평가도 하는 그런 활동이 분명하게 값진 경험이 될 것이다.
예전 보다 빨리 더 좋은 벽돌집을 다시 지을 수 있을까? : 항상 개발 프로세스를 염두하라.
셋째 돼지는 첫째나 둘째 돼지에게 예전보다 더 빨리 그리고 튼튼한 벽돌집을 다시 짓도록 도와 줄 수 있을까? 이러한 면에서, 필자의 마음속에서 일관되게 떠오르는 실타래 같은 이야기의 핵심이 있다. 그것은 바로 “프로세스”이다. 앞에서 설명한 모든 것들이 한 번을 수행하나 열번을 수행하나 어느 수준 이상의 품질을 보장할 수 있는 것은 바로 경험을 기반으로 정립된 프로세스를 기반으로 수행되기 때문이라고 생각한다. 그렇기 때문에 처음보다는 두번째, 세번째에 개선된 방식(프로세스)으로 고객이 원하는 품질의 시스템을 보다 빠르게 구축할 수 있는 것이다. 이러한 개발 프로세스를 가장 잘 보여주고 있는 것이 바로 소프트웨어개발방법론이라고 할 수 있겠다. 몇 몇 프로그래머들은 방법론이라는 소리만 들어도 두드러기 반응을 보이는 사람들도 있다. 방법론은 프로젝트 비용을 받기 위한 개발 문서 작성 도구 정도로 생각을 하니 말이다. 그러나 방법론은 문서화만을 강요하는 것이 아니다. 앞에서 말했던 분석, 설계 상의 과정은 물론, 아키텍처 수립 과정, 어떻게 프로젝트의 위험을 관리해야 하는가에 대한 가이드라인을 제시하는 등 프로젝트의 성공을 위한 베스트프렉티스를 담고 있다. 좋은 프로그래머로서, 고객의 감동을 이끌어 낼 수 있는 프로젝트를 수행하고자 한다면, 한 번 쯤은(아니 그 이상) 본인이 속해있는 회사나 조직의 개발방법론을 이해해서 프로젝트에 적용할 수 있는 능력을 갖추어야 한다고 생각한다. 개발방법론을 시간을 내어 보게된다면, 다음 내용을 주의깊게 살펴보기 바란다. 가장 먼저 정의되어있는 것이 당연히 개발 프로세스이고(언제, 무엇을 입력물로, 어떤 활동을 순서로 수행하며, 그 결과로 어떤 결과물을 산출하는지)그 중에 또 하나 관심있게 봐야 할 것이 프로세스를 수행하는 역할(Role)에 대한 정의이다. 역할은 특정 개발 활동을 수행하는 논리적인 수행주체를 말하는 것으로서, 일반적으로 프로그래머라고 하면, 한 프로젝트에서 구현자(Implementer)로서의 역할을 수행하게 된다. 지난 호에 게재된 글에서도 언급을 했지만 프로그래머와 개발자를 구분하는 하나의 요소가 바로 “설계”능력이 된다. 설계서를 이해하여 올바르게 구현을 할 수 있다면 프로그래머로, 구현은 물론이고 자신의 구현경험을 바탕으로 시스템의 특정 부분을 설계할 수 있다면 개발자로 구분을 하는 경우도 있다. 또한 향후 개발자에서 시스템 전체의 성능(품질)을 고려한 시스템의 아키텍처를 설계할 수 있게 되었다고 하면 그런 사람은 이제 아키텍트(Architect)로서의 능력을 갖추었다고 한다.
자, 마지막으로, 이 시점에서 주변을 한 번 둘러보자. 그대의 주변엔 어떠한 역할을 수행하는 사람들로 프로젝트가 구성되는가를. 앞에서 언급한 Implementer, Designer, Architect외에 Project Manager, Quality Assurance 담당자 등이 있음을 알 수 있을 것이다. 시간을 내어서 다양한 역할을 수행하고 있는 주변 동료나 선배들과 이야기를 해보라. 공통점을 찾을 수 있을 것이다. 그것은 바로 개발 언어가 무엇이 되었든, 프로그래머로서의 경험을 보유하고 있다는 사실일 것이다. 그것이 의미하는 바가 무엇일까? 자바 프로그래머로서 시작을 했다면, 앞으로 본인의 career path는 굉장히 다양하다는 것이다. IT업계의 선배로서 가장 하고 싶은 말은 , 프로그래머서로서 기술 습득을 게을리하지 않음은 물론, 내가 무엇이 되고 싶은가에 대한 최종career path 목표를 항상 생각하고, 그것을 정하라는 것이다. 그런 후에 여러분의 목표가 Architect이든, Project Manager이든 본인의 career path를 한 번 그려보는 시간을 가져보면 어떨까?
출처 : http://kr.sun.com/developers/pages/career_03.html