자바 프로그래머에서 개발자로

 

예전 직장에서 개발자 대상의 뉴스레터에 기고한 글입니다.

글 작성일: 2004년 7월
---

자바 프로그래머에서 개발자로

우리는 개발자와 프로그래머라는 말을 뚜렷하게 구분하여 사용하고 있지는 않다. 하지만, 썬에서 발급하는 자바 자격증을 보면, SCJP, SCJD, SCAJ 등으로 구분하여, 프로그래머(Programmer), 개발자(Developer), 아키텍트(Architect)의 3단계로 구분하고 있다. 이 순서대로 경력과 능력이 올라가야 그 수준을 달성하게 된다. 즉, 개발자와 프로그래머 사이에서는 개발자가 좀 더 놓은 수준의 능력을 갖춘 사람이 된다. 이 둘 사이에는 무슨 차이가 있을까? 공식적으로는 뚜렷하게 차이점이 정의되어 있지는 않다. 필자는 최소한 다음을 잘 이해하고 있는 사람은 개발자로서 프로그래머와의 구분을 가져오는 차이가 있다고 생각한다.

개발 방법론

개발 방법론은 프로젝트 초기에 선택되어야 할 가장 최우선적인 항목의 하나다. 많은 프로젝트에서 Waterfall에 근간을 둔, 정보 공학적인 방법론을 사용한다. 요즘에는 CBD나 XP (eXtreme Programming)이 많은 프로젝트에서 사용된다. 하지만, 아직까지는 CBD의 성공적인 적용이나, XP를 기가 막히게 사용해서 좋은 효과를 얻었다는 얘기를 그다지 많이 듣지 못했다. 필자의 판단으로는 현재 가장 쓸만한 방법론은 UP(Unified Process)며, 현실적인 프로젝트에서는 UP를 간단화 시킨 UP-Lite를 사용하는 것이 좋다고 판단된다. UP는 Rational사(현재는 IBM으로 합병됨)에서 RUP라는 이름으로 널리 알려진 개발 방법론이다.
필자의 판단으로 가장 가슴에 와 닿는 UP의 주장이나 개념은 시스템이나 고객의 requirement는 초기에 결정되지 않는다는 점이며, 이 때문에 많은 workflow들이 칼로 무를 자르듯 뚜렷하게 구분되지 않는다는 것이다. 얼마나 많은 프로젝트에서, “언제 설계가 끝나나요?”, “설계서는 언제 나오나요?” 등의 waterfall적인 질문을 고객들이 해대는가? 프로젝트의 본질적인 특성상 모든 일은 프로젝트가 매우 많은 시간이 지나야만 결정됨에도 불구하고…
프로젝트에서 채택하는 방법론은, 단순히 좋다고 결정될 만한 것은 아니며, 프로젝트의 규모, 난이도, 팀의 크기 등에 따라서 달라진다. 가장 작은 규모의 개발에서 유용한 방법은 XP(eXtreme Programming)이며, 중간 규모이거나 조금 규모가 큰 경우에는 UP-Lite나 UP를, 수백 명이 넘는 개발에서는 Waterfall 방식을 사용한다.
UP-Lite는 공식적인 용어는 아니지만, UP의 가장 중요한 몇 가지 특성을 프로젝트에 맞추어서 적용한다고 생각하면 되겠다.

아키텍처

아키텍처는 방법론인 UP에서도 강조하는 부분이나, 썬에서는 더욱 더 강조하는 부분이다. 모든 시스템의 결과물은 그것이 다양한 프로그램의 집합이던, 하드웨어에 COTS를 올려 놓은 것이던 그 시스템의 품질(quality)로 평가된다는 것이며, 그 품질에 가장 많은 영향을 주는 요소는 아키텍처라는 것이다. 많은 사람들이, 단일 프로그램의 버그보다는 설계상의 오류를 수정하기가 몇 십 배 어려우며(혹은 비용이 많이 소요되며), 설계상의 오류의 수정보다는 잘못된 아키텍처 구성의 변경이 몇 십 배 어려운 일이다라고 말하고 있다.

아키텍처는 그만큼 중요하다. 하지만, 필자가 경험한 프로젝트들에서 보면, 좋은 아키텍처는 그 가치를 인정 받기가 쉽지 않다. 반면에, 나쁜 아키텍처는 그 잘못됨으로 인하여 프로젝트 중이거나 끝난 직후에 비난의 화살을 면하기가 어려운 경우가 많다.

좋은 아키텍처는 프로젝트의 시스템적인 요구 사항에 따라서 다르겠지만, 일반적으로 가용성(availability), 확장성(scalability), 개발용이성 (easy to development), 성능(performance), 표준성(standard) 등등에 대하여 얼마나 잘 수용하는가에 달려있는 경우가 많다. 많은 프로젝트가 MVC라는, 자바를 서버측에 적용하고 웹 브라우저를 클라이언트로 사용할 때의 가장 기본적인 아키텍처 구성을 무시하는가? 기능별로 티어(tier)와 레이어(layer)로 구분하여 구성하지 않고 통째로 구성하는 오류를 범하고 있는가? 그래서, 나중에 확장을 하거나 서버를 분리하고자 할 때, 그 난이도와 복잡성에 한탄을 하는가? 필자는 DB 시스템에 Entity Bean을 deployment하는 경우도 사례로 알고 있다.

프로토타입 (Prototyping)

이 세상에서 처음 해보는 일을 잘할 수 있는 사람은 없다고 한다. 프로젝트도 마찬가지다. 개발자가 수행하는 모든 프로젝트가 내가 잘 알고 있는 기술만으로 진행되지는 않는다. 심지어 경험이 매우 풍부한 개발자도 전혀 새로운 시스템 구성을 해야만 하는 경우도 그리 드물지 않다. 프로토타입은 이점에서 매우 유용한 결과물이다. 프로젝트의 초기에, 요구 사항에 대한 이해, 시스템 구성, 프로그램 구조, 서버의 성능 등에 대하여 미심쩍었던 부분을 확인하기에는 이처럼 좋은 도구나 제도는 없다.

프로토타입은 설계 초기에 진행을 하는 것을 원칙으로 한다. 또한, 마케팅의 요구가 아닌 시스템적인 요구 사항이 많이 반영되어야 한다. 하지만, 많은 프로젝트에서 기술 분야를 전혀 모르는 stakeholder들, 소위 높은 사람들에게 데모할 목적으로 프로토타입을 만드는 경우가 많다. 이 경우는 지양되어야 마땅하며 실제 프로젝트에 거의 도움을 주지 않는 경우가 많다.

프로토타입은 아낌없이 버릴 수 있어야 한다. 오죽했으면, “The Mythical Man Month”라는 글을 쓴 Brooks라는 사람은 “Plan one to throw away”라는 말로 표현했을까.

프레임웍 (Framework)

프레임웍의 정의를 아는가? 일반적으로 인정 받고 있는 프레임웍의 정의는 “연관된 문제를 해결하기 위한 추상화된 설계를 포함하는 상호 관련 있는 클래스의 집합”이라는 다소 난해한 의미다. Ralph Johnson이라는 프레임웍에 대한 많은 논문을 쓴 사람은 프레임웍을 "A framework is a set of classes that embodies an abstract design for solutions to a family of related problems."이라고 정의하고 있다.
최근에 많이 사용되는 buzz word인 CBD(Component Based Development)에서의 핵심 단어인 컴포넌트의 정의만큼이나 애매 모호하며 별로 도움이 안 된다. 여기에서 프레임웍의 정의를 따지는 것은 무의미하며 그냥 일반적으로 많이 사용되는 STRUTS, Log4J, ANT나 JUnit 등을 지칭한다고 이해하자. 이들의 사용 목적은 이건 완전히 개인적인 생각이지만, 프로그램의 일관된 품질(quality)을 얻는 것과 그 유지 보수의 편리성에 목적을 두고 있다.

어떤 프로젝트건 어느 정도의 프레임웍을 사용하는 것은 보편화되어 있으며, 개발자라면 여러 프레임웍에 대한 경험과 통찰력을 지니고 있어야 한다. 어떤 프로젝트에서 좋은 프레임웍이 또 다른 프로젝트에서 좋다고는 할 수 없다. 서로 다른 기술을 사용하는 경우에서도 그렇고, 그걸 받아들이고 수용하는 사람들의 능력과 선호도가 달라서 더욱 더 그렇기 때문이다.

디자인 패턴 (Design Pattern)

요즘에는, 디자인 패턴은 이제는 프로그래머라는 당연히 알아야 하는 것으로 여겨지고 있다. 또한, 많은 사람들이 여러 개의 디자인 패턴을 프로젝트에 적용하고 있으며, 얘기를 해보면 많은 수의 패턴을 알고 있다. 하지만, 실제로 깊은 대화를 나눠보면, 피상적으로 패턴을 이해하고 있는 경우가 있으며, 심지어는 잘못된 곳에 잘못되게 사용하는 경우도 비일비재하다. 내가 몇 개의 패턴을 말할 수 있는가 보다는 단 한 개라도 정확하게 이해하고 사용할 수 있는 편이 더 낫지 않을까 생각한다. 이런 전제 하에, 다자인 패턴은 단위 설계나 프로그래밍에서 매우 유용한 도구가 아닐 수 없다.

기타

정확하게 출처는 생각나지 않지만, 비교적 최근에 어느 글에서 본 내용이다. 우리나라의 개발자는 코딩은 열심히 하면서 테스트를 해 보는데, 그 기본 동작 원리에 대해서는 별로 관심을 두지 않는다는 내용이었다. 필자도 매우 동감하는 내용이다. EJB 프로그램은 잘 하지만, 그 동작 원리에 대해서는 잘 모르는 개발자를 심심치 않게 목격할 수 있다. 기타 다른 자바 기술 분야도 이와 유사한 경우가 흔하다. 우리나라 개발자들은 일단 손이 먼저 움직이는 경향이 강해서 그렇다고 필자는 믿고 있다. 하지만, 이제는 그 습관을 조금은 바꾸어야 할지 않을까 생각한다.

그리고, 책을 많이 읽을 것을 권한다. “J2EE 1.4 따라잡기”와 같은 자바 기술에 대한 직접적인 내용도 읽어야 하지만, language 또는 spec이라는 개념에서 조금은 벗어난 기술 관련 문서들도 많이 읽어 볼 것을 권한다. 왜 그런 책들을 읽어야 하냐고 묻는다면, 내가 알고 있는 얘기 하나를 할까 한다.

“당신이 강을 건너야 한다고 생각하자. 단, 그 강물을 건너면서 돌로 징검다리를 만들면서 가야 한다. 그때, 당신은 자신의 발에 딱 맞는 돌로만 징검다리를 만들 것인가 아니면 조금 큰 돌을 사용할 것인가? 당신의 발 보다 조금 큰 돌의 남는 부분이 당신이 지금 당장 필요로 하지 않는 부분일지라도 그 돌은 당신이 강을 건너는데 도움을 줄 것이다. 그 강이 바로 인생이다.” 이 얘기도 출처는 생각나지 않지만, 원 제목은 “왜 (고등학교) 문과에서 화학을 배워야 하는가”로 알고 있으며, 우리나라의 얘기나 글은 아니다.

마지막으로, 같은 코끼리를 만지고도 서로 이해하고 있는 바가 다른 경우도 있듯이, 같은 문제나 상황에 대하여 해석을 달리하는 경우도 많다. 이와 해결하기 위한 상호 의사 소통은 매주 중요한 기술(skill)에 해당한다. 더불어서 필요한 기술은, 발표력, 문서 작성 능력, 문제 해결 능력 등이 있다. 개발자와 프로그래머의 가장 큰 차이는 코딩이 자신이 가진 능력의 전부가 아니라는 것이며, 프로젝트는 코딩이라는 이름으로 대표되는, 시스템을 대상으로 진행하는 식의 활동(activity)으로만 구성된 일이 아니다라는 점이다. 프로젝트에서의 대부분의 활동은 사람을 대상으로 진행된다. 심지어 코딩도 단순히 시스템과 프로그래머와의 대화라고 단정하기도 어렵다. 왜냐하면, 많은 프로그램은 사람과의 대화를 수행하기 때문이다. 따라서, 클래스 간의 Interface만 잘 정의하는 것이 중요한 것이 아니라, 팀원들 간의 그리고 사람들 사이의 Interface를 잘 정립하는 것도 중요하다.

두서 없는 얘기를 여기까지 읽어 주셔서 감사합니다. 즐코딩하시길. 아니 즐개발하시길….