Sun Developer Network 공식 블로그

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를 잘 정립하는 것도 중요하다.