[지디넷코리아]먼저 글을 시작하기에 앞서 ‘고급 개발자’라는 말의 의미를 정리하고 시작해야 할 것 같다. 왜냐면 SI 업계에 종사하는 사람이 고급 개발자라고 들으면 보통 정보통신부에서 정한 기준으로 기술 등급이 ‘고급’에 해당하는 사람을 떠올릴 것이기 때문이다.

그러나 이번 글에서 말하려는 고급 개발자는 개발 경험이 풍부해 기술적으로나 인간적으로나 노련미가 넘치는 개발자를 의미한다. 특히 이번 글에서는 자바 개발자로 시작해서 고급 개발자로 도약하기 위한 첫 걸음으로, 프로젝트 진행에 대한 의미, 특징, 종류, 문화, 역할, 진행과정 등을 살펴보고, 이를 토대로 프로젝트를 성공으로 이끌기 위한 기술적?관리적 요소에 대해서 알아보도록 하겠다.

프로젝트란 무엇인가?
필자가 여러 곳의 프로젝트를 수행해본 경험에 비춰볼 때 프로젝트란 다음의 네 가지 의미를 내포하는 것이 보통이다.

첫 번째로 프로젝트는 명확한 목표가 존재한다. 특히 대형 프로젝트에 들어가면 사무실 내에 큰 현수막에다가 ‘Go Live D-100(100일 후에 시스템 가동)’이나 ‘에러율 0% 시스템 완성’ 등의 구호를 걸어놓은 경우가 많다. 또한 프로젝트를 진행할 때 발생되는(작성해야 하는) 각종 산출물로 프로젝트의 범위와 목표를 명확히 한다. 그래서 프로젝트에 투입되는 처음 며칠 또는 몇 주는 프로젝트에서 팀원들이 공유 파일 서버에 있는 각 단계별 산출물을 파악함으로써 프로젝트의 목표와 범위 외에 그 동안의 이력과 향후 계획을 파악한다.

두 번째로는 그 목표를 어떻게 추진해나갈 것인가의 기술적?관리적 해결 방법이 있어야 한다. 이는 프로젝트를 발주하는 측에서 해당 프로젝트에 입찰하는 업체를 선정하기 위한 기준으로 우선적으로 검토하는 사항이다. 그래서 신규 프로젝트에 대한 입찰공고가 나면 해당 프로젝트에 대한 기술 및 추진력을 가진 업체에서는 그 프로젝트를 어떻게 기술적, 관리적으로 해결해나갈 것인지를 제안서에 상세히 기술한다. 여기에는 프로젝트에 대한 목표와 범위를 비롯해 이에 대한 기술적 해결책 및 프로젝트 관리 방안이 수십여 페이지에 걸쳐 쓰여 있다.

세 번째로는 그 목표를 추진해서 실현해나갈 사람들의 구성, 즉 팀이 있어야 한다. 이것 또한 프로젝트 제안서에 어떤 기술력을 가진 인력들을 어떻게 투입해 관리할 것인지를 명시하고 있다. 그리고 대체로 관련 프로젝트에 대한 경험이 있는 사람들이나 업체를 중심으로 프로젝트 팀원을 구성하는 경우가 많다.

네 번째로는 프로젝트에는 목표 시스템을 구성하기 위한 하드웨어 및 소프트웨어가 있다. 규모가 큰 프로젝트일수록 고급 서버가 도입되고, 이를 논리적, 물리적으로 구성하는 방안도 복잡해진다. 이를 구성하는 사람을 ‘시스템 아키텍처러’라 하고 프로젝트 초반에 주로 굵직한 골격을 만들어 줌으로써 향후 개발시에 무리가 없도록 시스템을 구축한다. 앞에서 말한 4가지 사항을 종합하면 프로젝트는 다음과 같은 정의를 내릴 수 있겠다.


프로젝트의 정의에서 봤듯이 프로젝트의 성패 요소는 팀과 프로젝트 기간, 그리고 목표를 이루기 위한 추진 방법, 하드웨어 및 소프트웨어가 큰 관건이다. 그래서 프로젝트에는 항상 리더들이 있고, 이들은 팀을 이끌어 정해진 기간에 목표를 달성할 수 있도록 안간힘을 다한다. 또한 프로젝트는 그러한 요소로 구성되어 있기 때문에 팀웍과 프로젝트 추진 기술력, 그리고 시간이 항상 문제가 된다는 사실을 잊지 말아야 한다. 지금까지 프로젝트의 정의를 살펴봄으로써 대충 프로젝트가 어떠하다는 것을 알게 됐을 것이다. 그럼 본격적으로 자바 프로젝트들에 대해서 알아보도록 하자.

자바 프로젝트의 모든 것
‘자바 프로젝트’는 기술 관점에서 자바 기술이 핵심 비즈니스 로직을 구성하는 경우이다. 실제로 회사에서 수행하는 프로젝트 이름을 얘기할 때는 ‘자바 프로젝트’라고 말하지는 않는다. 다만 글에서 자바 기술 중심의 프로젝트를 얘기하기 위해 여기에서는 편의상 ‘자바 프로젝트’라는 말을 쓰고 있는 것이다. 자바 기술이 해당 프로젝트의 핵심적인 업무를 구현하는 프로젝트가 이 글에서 주로 다뤄질 것이며, 한편으로는 초대형 프로젝트에서는 자바 기술이 어떻게 사용되는지도 살펴볼 것이다.

프로젝트 이름에 관한 얘기
보통은 고객 회사명을 사용해 만든 프로젝트명을 정한다. 물론 기술 중심으로 명명하는 경우라면 기술 이름을 붙인 프로젝트명으로 불러도 무방하지만 일반적으로는 기술보다 비즈니스 중심적으로 나가는 경우가 많다.

프로젝트에 들어가기 전에 프로젝트 추진 업체 관리자가 기술 면접을 실시하는 경우가 종종 있다. 이때에 경력사항을 보면서 무슨 프로젝트를 해봤냐고 물어본다. 여기서 한 가지 중요한 것을 말하자면 기술 면접시에 질문의 요지가 무엇인지를 정확이 파악해야 한다는 것이다. 질문이 그 프로젝트의 기술을 묻는 것일 수도 있고, 프로젝트를 치룬 회사(발주사)가 어떤 곳인지를 묻는 것일 수도 있고, 어떤 업무를 다루는 프로젝트를 했는지를 물을 수도 있다.

어떤 기술을 쓰는 프로젝트를 해봤냐고 물으면 JSP 프로젝트, SWING 프로젝트, EJB 프로젝트 등 자바 기술이 중심이 되는 프로젝트를 답하는 것이 낫고, 어디서 프로젝트를 했냐고 물으면 XX은행 프로젝트, OO보험 프로젝트 등 그 회사명이 들어간 프로젝트 이름을 얘기하는 것이 좋다. 이런 것이 햇갈린다면 XX은행의 인터넷뱅킹 구축 프로젝트를 했다는 식으로 얘기하면 될 것이다.

자바 기술에 따른 프로젝트의 종류
자바 프로젝트는 어떤 기술을 사용하느냐에 따라서 분류할 수가 있다. 자바 기술은 크게 J2ME, J2SE, J2EE 세 가지로 나눠볼 수 있다. 이는 기술 관점에서 바라본 자바 프로젝트의 분류이다.


기타 프로젝트의 종류
한편으로는 어떤 업무를 주로 다뤘느냐에 따라서 제조 부문, 공공 부문, 금융 부문 등의 프로젝트로 나눠볼 수도 있다. 그리고 더 세 분류로 들어가서 인사, 급여, 회계, 영업, 재고 등의 프로젝트로 나눌 수 있다. 그리고 프로젝트를 회사 내에서 하느냐에 따라 사내 프로젝트, 사외 프로젝트(파견)로 나뉘어 진다. 일반적인 SI 프로젝트는 고객회사에 파견을 가서 직접 구축해 주는 경우가 대부분이고, 회사 내의 솔루션 개발 및 자체 시스템 구축은 사내 프로젝트로 주로 이뤄진다.

한편으로는 프로젝트의 기간에 따라서 단기 프로젝트, 중기 프로젝트, 장기 프로젝트로 나뉜다. 단기 프로젝트는 보통 3개월 미만의 프로젝트들이 해당하며, 중기 프로젝트는 3개월에서 1년 이하의 프로젝트이며, 그 이상의 프로젝트는 장기 프로젝트이다. 프로젝트에 있어서 개발 기간은 그만큼 많은 사람들이 참여함을 의미하고 이는 곧 프로젝트 비용이 기간만큼 커진다는 것이다. 그래서 프로젝트의 규모도 이에 비례해서 소형, 중형, 대형 프로젝트로 구분해 볼 수 있다. 예전에는 1년 이상의 대형 프로젝트들이 많았었는데 최근에는 그 기간이 줄어들어 2년 이상의 대형 프로젝트는 찾아보기 힘들고 6개월에서 1년 반 정도가 대형 프로젝트의 구축 기간이 된다.

아무리 소형 프로젝트라고 하더라도 1인이 모든 시스템에 대한 밑그림을 정확하게 알고 구축하는 경우가 아닌 이상은 최소한 1개월 이상은 걸린다. 이는 프로젝트라는 것이 대부분 자기를 위한 프로젝트가 아니라 누군가의 요구에 응해 이뤄지는 것이기 때문에 그 사람이 정확히 원하는 시스템이 무엇인지를 파악하는 데만 몇 주에서 몇 개월이 걸리기 마련이다. 대형 프로젝트인 경우는 시스템이 복잡할 뿐만 아니라 요구사항도 복잡하기 때문에 해당 업무에 대한 전문가들이 몇 개월에 걸쳐서 이를 분석하는 시간이 있어 그 기간이 중장기로 가게 된다.

자바 언어의 특징
자바 프로젝트의 특징을 살펴보기 전에 자바라는 언어가 다른 언어와 다른 점을 파악해야 한다. 그렇게 함으로써 자바 프로젝트를 실행할 때 관심을 기울여야 할 사항들이 무엇인지가 분명해지기 때문이다.

[1] 객체지향적 : 자바가 클래스로 표현되는 객체의 특징을 갖고 있다는 것이다. 객체지향 개념은 소프트웨어로 만들어질 대상들을 하나의 객체로 보고, 객체의 속성과 동작으로 그 대상을 클래스로 추상화해 소프트웨어로 구현하려는 것이다. 객체 또는 다른 프로그램과의 통신을 위해서 인터페이스 클래스가 따로 존재하며 이를 구현함으로써 프로그램간의 상호연동이 이뤄진다. 그래서 자바는 기존 프로그램의 데이터와 프로세스 위주의 소프트웨어 설계 및 개발 방식과는 기본적으로 다른 프로그래밍 언어이다.

[2] 자바 가상머신에 의한 실행 : 자바는 처음에 나올 때 ‘Write Once Run Anywhere’라는 푯말을 내세웠다. 즉 어떤 플랫폼에서 작성했던 코드라도 자바 가상머신이 설치된 플랫폼이라면 실행된다는 것을 보장한다. 이는 자바 가상머신이 있기 때문에 가능한 것이다. 자바가 실행되기 위해서는 소스코드를 클래스로 컴파일하고, 이 클래스는 자바 가상머신의 클래스로더에 의해서 로딩되어 바이트코드로 인터프리팅됨으로써 실행이 이뤄진다. 그리고 자바 프로그램은 운영체제의 메모리에서 실행되는 것이 아니라 자바 가상머신이 관장하는 메모리 영역에서 실행된다는 점에 주의를 해야 한다.

[3] 간단하고 쉬운 코드 : 자바는 자체적으로 메모리 관리를 하지 않는다. 이는 자동적으로 코드가 사용하지(메모리에서 참조되지) 않는 메모리를 찾아서 메모리를 다시 수거해가는 가비지 컬렉션이 있어 가능한 것이다. 그래서 자바 프로그램을 작성할 때 메모리에 대해서는 크게 신경을 쓰지 않고 코딩을 해도 되는 편리함이 있다. 메모리 관리는 코드 레벨에서 이뤄지지 않고 자동으로 되기 때문에 메모리간 연산인 포인터 연산 기능이 없어 코드의 복잡성을 줄였다. 또한 다중 상속을 제거해 여러 클래스의 상속을 하지 못하게 하는 대신에 인터페이스를 도입해 다중 상속에서 발생하는 부모와 자식 클래스간의 메쏘드 및 속성 호출 문제를 없앴다. 그리고 쓰레드 관리를 자체에서 지원하기 때문에 운영체제에 독립적이고 사용하기 쉬운 멀티쓰레드 프로그래밍이 가능하다.

자바 프로젝트는 이렇게 다르다
프로젝트의 경험이 많은 사람이든 적은 사람이든 자바 프로젝트에는 분명 뭔가 다른 게 있다. 앞에서 살펴봤듯이 자바 언어의 특성을 유심히 살펴본 독자들 또는 자바 프로젝트를 많이 해 본 독자들은 그러한 특성들이 자바 프로젝트에서 어떤 이점이나 문제점으로 연결될 지를 금방 눈치챘을 것이다.

필자가 처음 자바 프로젝트를 할 때는 백지상태였기 때문에 자바 프로젝트에서 발생하는 모든 것을 스펀지처럼 그대로 수용할 수 있었지만 자바 외의 프로젝트 경험이 많은 사람들은 지금까지 그 사람들이 해왔던 것이 있기 때문에 그렇지 못하다. 그러한 것들을 자바 언어의 특성과 연관지어서 살펴보면 다음과 같다.

[1] 프로세스 중심에서 객체 중심으로 생각을 바꾸어야 한다 : 프로세스 중심의 사고는 기존의 프로그래밍 방식에서 하나의 처리를 한 페이지의 행 번호 순으로 차례대로 처리해나가도록 코딩하는 방식이다. <그림 1>은 절차적 프로그램과 객체지향적 프로그램의 처리 순서를 예로 나타낸 것이다. 그림에서 보듯이 절차적 프로그램은 하나의 프로그램 안에서 순차적으로 처리가 이뤄지지만, 객체지향 프로그램은 하나의 클래스에서 다른 클래스의 메쏘드를 호출하고, 그것이 또 다른 클래스의 메쏘드를 호출하는 식이다.

여기서 절차적으로 코딩하는 사람은 의문이 생길 것이다. <그림 1>을 보면 분명히 절차적으로 코딩하는 것이 간단해 보이고, 객체지향적인 코드는 메쏘드 호출이 왔다갔다하니 햇갈릴 것이다. 객체지향적 프로그래밍은 우선 코드의 재사용을 중시한다. <그림 1>의 객체지향 코드 부분에서 진하게 표시된 클래스들이 이미 완성되어 있다면 문제는 달라진다. 코딩할 때 완전 백지상태에서 할 필요가 없게 되어 있는 것을 가져다 쓰면 될 것이고 이것이 객체 중심 사고의 출발점이다.

<그림 1> 절차적 프로그램 vs. 객체지향적 프로그램

[2] 객체지향 설계 사상으로 프로젝트를 진행해야 한다 : ??단락에서 그렇게 가져와서 사용할 클래스가 없으면 어떻게 해야 할까? 처음 자바 프로젝트를 하는 사람들은 대부분 이렇게 의문을 가질 것이다. 이렇게 다음에도 쓸 수 있도록 클래스들을 만들고, 이들 클래스들간의 상관 관계를 만드는 것이 객체지향 설계의 과정이다. 우선 눈에 띄게 드러나는 것은 프로젝트의 설계, 구축 단계에 있어 기존의 설계, 구축 방법과는 다른 객체지향적인 설계와 이에 따른 프로그램 개발이 이뤄지게 된다.

그래서 설계와 개발에 필요한 툴도 객체지향 개념을 지원하는 툴을 사용한다. 그리고 프로젝트 전체 구축 관점에서 적용하는 개발방법론 자체가 객체지향적 방법론이 되며, 이에 따른 설계 및 개발 과정에서 나오는 객체들의 상관관계를 표현하는 산출물도 발생한다는 것이다. 또한 객체들은 소프트웨어 재사용을 위해 컴포넌트화될 수가 있어, 거의 백지상태에서 새롭게 구축하거나 기존의 소스코드나 라이브러리를 갖고서 구축하는 방법과는 달리 획기적으로 컴포넌트의 조립만으로도 시스템을 구축할 수 있는 프로젝트가 가능하다.

[3] 자바의 실행코드는 자바 가상머신이 구동해 줌을 주지하라 : 자바 프로젝트를 시작하면 그냥 아무 생각 없이 JDK만 설치하고 그 후로는 아무 관심을 갖지 않는데, 자바 가상머신은 자바의 바이트 코드가 실행되는 환경이고, 메모리도 자바 가상머신이 관장하는 메모리를 사용한다. 그래서 프로젝트 테스트 단계에서 많은 에러가 자바 가상머신의 메모리와 관련된 문제를 야기한다. 또한 튜닝 작업을 할 때, 튜닝 포인트가 되는 부분이 자바 가상머신 영역이다. 또한 프로그램 개발에 있어 자바 가상머신의 버전도 일치시킴으로써 기존 버전과 신규 버전 사이의 Deprecated 메쏘드 호출과 같은 코드 문제가 없도록 해야 한다.

[4] 코드의 성능은 코딩의 습관에서 나온다 : 자바 언어는 코드가 간결하고 쉽게 하기 위해 메모리 관리를 하지 않는다. 이것은 장점이 됨과 동시에 단점도 된다. 즉, 개발하는 입장에서 메모리 관리 코드와 포인트 연산의 필요가 없기 때문에 코드는 간단하지만 개발하는 프로그램이 메모리를 얼마나 쓰는지 파악하면서 개발하는 게 쉽지 않으므로 코드의 성능 저하가 뒤따르기 마련이다.

자바 언어적 특성에 따른 문제 외에도 프로젝트를 진행할 때 발생하는 문제가 여러 가지 있는데 이는 프로젝트의 성패 요소에서 자세히 살펴보기로 하고, 이제는 자바 프로젝트가 처음부터 끝까지 어떻게 진행되는지 그 단계별로 일어나는 상황과 이에 어떻게 대처해야 하는지를 살펴보도록 하자.

자바 프로젝트의 진행 단계 파헤치기
프로젝트의 진행 단계는 프로젝트의 기간 및 규모에 비례한다. 그래서 프로젝트의 구축 범위가 소규모일수록 개발기간이 짧으며, 그 프로젝트에 투입되는 인원수 또한 적기 때문에 해당 프로젝트의 진행 단계 또한 간단하다. 반대로 프로젝트의 규모가 매우 크면 시스템의 구축 범위 또한 매우 크고, 이에 따라 개발기간 또한 길어진다. 그리고 프로젝트가 소규모이면 프로젝트 내에서 맡은 역할도 몇몇 사람이 겸해서 진행하게 되지만, 대규모 프로젝트일 경우는 역할이 매우 세분화되어 있을 뿐 아니라 프로젝트에 투입된 인력에 대한 자체 관리팀(조직)도 구성해서 운영한다.

그 역할이 세분화되어 있기 때문에 일반적으로 프로젝트 매니저를 제외하고는 프로젝트의 전체 진행 단계를 전부 거치는 사람은 별로 없다. 그래서 컨설팅 및 설계자들은 주로 프로젝트 초반기에 투입됐다가 개발자들이 들어오는 시점에 프로젝트에서 철수한다.

프로젝트의 진행 단계는 보는 사람과 개발방법론 등에 따라 다양한 이름으로 단계가 불려진다. 하지만 프로젝트에서 중요한 성패 요소인 개발 프로세스, 기술력, 프로젝트 관리의 관점에서 단계를 나누어서 각 단계별로 발행하는 상황과 대처방법을 살펴보도록 하자.

개발 프로세스에 따른 자바 프로젝트 진행 단계별 고려사항
이는 시스템이 어떻게 완성되어 가는가의 관점에서 단계를 나눈 것으로 가장 보편적인 프로젝트의 진행 단계이다. 크게 <그림 2>와 같이 분석-설계-구축-테스트의 4단계로 볼 수가 있다.

<그림 2> 개발 프로세스에 따른 자바 프로젝트의 진행 단계

[1] 분석 단계에서는 사용자와 사물들(객체)을 가려내어야 한다 : 분석 단계는 시스템 구축을 원하는 고객과의 접촉을 통해서 고객이 원하는 시스템이 어떠한지를 파악해 프로젝트에서 구축해야 하는 시스템의 범위를 정의하는 단계이다. 이 시스템의 범위를 정의한다는 것은 어떤 사용자가 어떤 것을 어떻게 움직이는지를 상세히 기술하는 것을 의미한다. 이러한 정의 없이 막연히 기능 위주로 나열한다면 기존의 프로젝트 방식과 크게 다를 바가 없고, 설계 단계에서는 이를 객체화하기가 어려워진다. 객체지향 개발 방법론(RUP)에서는 이것은 유스케이스 다이어그램으로 나타난다.

만약 소규모 프로젝트라면 구축 범위가 명확히 드러나 있으므로 해당 단계를 생략하고 바로 설계와 같이 진행할 수도 있다. 또한 중요한 것은 이 단계에서의 말 한마디가 뒷단계로 가면 갈수록 눈덩이가 불어나듯이 일이 커질 수도 있고 아니면 일이 팍 줄어들 수도 있다는 것을 명심해야 한다. 설계 단계에서는 분석 단계에서 나온 객체들을 설계 사상에 반영하라 : 설계 단계는 분석 단계에서 나온 객체들의 관계와 사용하는 방법을 설계문서로 만들어내는 과정이다. 여기서의 객체는 자바 프로그램의 클래스가 되기도 하고, 데이터의 보존을 위한 데이터베이스의 엔티티가 된다.

이 단계에서는 분석 단계에서 나온 객체들이 고객의 요구사항(유스케이스)과 비교해 누락되었는지를 확인하는 것이 중요하다. 만약 객체가 빠지게 되면 뒤에 구축 단계에서 새롭게 설계를 하여 코딩해야 하는 번거로움이 있다는 것을 명심하라.

[2] 구축 단계는 코딩의 표준과 코드에 대한 로직을 명확히 해야 한다 : 구축 단계는 설계가 끝나 실제로 프로그래밍 언어를 이용해 설계된 대로 코딩하는 단계이므로 코딩에 대한 표준을 정확히 해두어야 나중에 다른 사람이 그 코드를 고치더라도 고생하지 않는다. 실제로 필자가 참여했던 프로젝트에 개발자가 3명이었는데 표준 없이 그냥 구현해 보라고 했더니, 소스가 3인3색으로 나와서 나중에 다시 고치는 데 무척 애를 먹었었다.

그리고 후에 테스트 단계에서 디버깅을 위해 그러한 코딩을 왜했는지를 명확히 해주는 코멘트를 달아놓는 것을 습관화하는 게 중요하다. 자신이 아무리 로직을 정확히 기억하더라도 작성하는 프로그램의 수가 증가하면 결국에는 햇갈리기 마련이다.

또한 분석 및 설계 단계에서 다루지 못했던 부분이 생기는 경우가 많다. 이는 고객이 실제로 구현되는 모습을 보지 못한 상태에서 고객의 요구사항을 분석하는 게 일반적이기 때문에 실제로 구현되는 모습을 본 후 “이렇게 바꿔 달라” 혹은 “저것도 추가해 달라”는 식의 요구사항이 더 발생하기 때문이다. 그래서 아무리 기간을 넉넉히 잡은 프로젝트일지라도 구축 단계에 들어서면 시간이 늘 부족하기 마련이다.

[3] 테스트 단계는 개발자의 입장이 아니라 사용자 입장에서 테스트하라 : 구축이 끝나면 시스템이 제대로 작동되는 지를 테스트하게 된다. 단순한 시스템인 경우는 간단히 테스트할 수 있으나 복잡한 시스템의 경우는 테스트를 어떻게 하겠다는 테스트 시나리오를 토대로 테스트를 하게 된다. 그리고 복잡한 시스템은 프로그램이 매우 많고, 서로 복잡하게 연결되어 있으므로 프로그램 낱개별로 테스트를 한 다음(단위 테스트), 상호 관련 있는 프로그램의 테스트(통합 테스트)를 하게 된다.

테스트 단계에서 그냥 개발하는 사람의 입장에서 정확한 값에 정확한 액션을 취하기 때문에 일반 사용자들의 예기치 못했던 상황에 대처하지 못하고 의외의 에러가 많이 발생한다. 그래서 초기 분석 단계의 유스케이스 다이어그램을 토대로 모든 케이스별로 테스트해야 한다.

기술적 관점에서 바라본 자바 프로젝트 진행 단계별 고려 사항
이 부분은 시스템이 기술적인 관점에서 구현되어 가는 모습을 단계별로 나누어서 고려할 사항을 정리하는 부분이다. 기술적인 관점이라 함은 실제로 작동하는 코드를 만들고 구동하는 소프트웨어와 이 소프트웨어가 설치될 하드웨어를 의미한다.

<그림 3> 기술적 관점에서 바라본 자바 프로젝트의 진행 단계

[1] 시스템 아키텍처 구성은 물리적, 논리적으로 타당하도록 한다 : 먼저 시스템 아키텍처 구성 단계는 시스템의 하드웨어와 소프트웨어를 어떻게 구성할 것인가를 결정하는 단계이다. 하드웨어와 소프트웨어는 구성하려는 시스템이 프로젝트에서 원하는 방향으로 구축될 수 있도록 논리적?물리적으로 타당해야 한다. 논리적으로 타당하다는 것은 웹 사이트를 구축함에 있어 브라우저에서 보내는 정보가 웹 서버를 타고 웹 애플리케이션 서버를 거쳐 데이터베이스에서 원하는 결과를 다시 역순으로 리턴해나가는 과정이 정확히 표현된다는 것이다.

만약에 웹 서버와 데이터베이스가 연결되어 있고, 웹 애플리케이션 서버가 다른 응용 서버와 연결된다고 하면 이는 시스템 아키텍처의 논리가 안 맞는 것이다. 한편 물리적으로 타당하다는 것은 앞에서 예로 든 웹 사이트의 경우 웹 서버, 웹 애플리케이션 서버, 데이터베이스 서버를 한 대의 물리적 서버로 둘 것이냐, 각각의 서버로 둘 것이냐, 아니면 서버를 병렬로 클러스터링할 것이냐 등의 문제가 해당된다. 또한 서버간의 물리적 연결 부분(네트워크)에 대한 명시도 물리적 구성에 해당한다. <그림 4>는 물리적인 뷰와 논리적인 뷰의 차이를 보여주고 있다.

<그림 4> 시스템 아키텍처의 물리적, 논리적 뷰의 예시

[2] 하드웨어 & 소프트웨어는 도입시 고려할 사항 : 하드웨어의 경우 네트워크를 구성하는 장비는 대부분 명확한데, 서버의 경우 어느 정도의 성능을 가진 것을 도입해야 하는지 결정하는 것이 문제가 된다. 여기서 서버의 성능은 tpmc라는 수치로 결정되는데 이는 일반 PC CPU의 Hz 단위와 흡사한 개념으로서 CPU의 트랜잭션 처리량을 나타내며, 이것의 수치가 높을수록 성능이 우수하다는 것이다.

일단은 성능이 우수한 서버를 도입하면 서버 도입 비용 외에는 크게 문제될 것이 없지만, 성능이 떨어지는 서버를 도입하게 되면 나중에 문제가 많아지게 되어 결국은 서버를 업그레이드하게 된다. 소프트웨어는 시스템을 구축하기 위해 필요한 개발 툴, 각종 서버 소프트웨어 등이 해당한다. 같은 기능을 하는 소프트웨어가 많으므로 어떤 소프트웨어를 도입할 지를 결정하기 위해 서로 벤치마크 테스트한 결과로 판단하게 된다.

[3] 시스템 환경 구축시 자바 관련 정보는 공유한다 : 하드웨어와 소프트웨어가 도입되면 개발의 서막이 울린다고 보면 된다. 이때는 개발을 위한 제반 환경을 구축하게 되는데, 자바의 경우 자바 가상머신이나 클래스 패스 등의 셋팅이 들어가게 된다. 또한 자바 관련 애플리케이션 서버를 위해서 따로 클래스 패스나 실행 경로를 주기도 하는데, 이때의 각종 자바 관련 설정 정보는 개발자와 공유되어야 한다. 왜냐면 실행시 일어나는 각종 에러 등의 문제에 보다 능동적으로 대처할 수 있도록 하기 위함이다. 그리고 이때 개발을 위한 표준 작업을 통해 코딩 룰을 명확히 하여 개발 및 테스트, 유지보수에 있어 효율성을 가질 수 있도록 해준다.

[4] 시스템 개발은 시스템 아키텍처를 이해한 상태에서 이뤄져야 한다 : 시스템 환경의 구축이 끝나면 이에 따라서 본격적인 프로그램 개발에 들어가게 되는데, 자바의 경우 분산된 환경 하에서 객체간의 통신을 하는 경우가 많다. 또한 서버의 성능을 향상시키기 위해 서버 여러 대를 클러스트링하기도 하는데, 이때 개발자가 이러한 사실을 모르고 코딩을 하게 되면 나중에 심각한 오류를 일으킬 소지가 있다.

[5] 시스템 테스트시에는 자바의 튜닝 포인트를 중심으로 테스트를 해야 한다 : 시스템 개발이 끝나면 각 프로그램별로 테스트를 하게 되는데, 이때 정확히 작동하는 것은 물론 시스템 전체에 부하를 어느 정도 미치는지의 테스트도 같이 병행함으로써 튜닝 대상을 가려낼 수 있도록 한다. 이때 자바 가상머신의 메모리 사용량, 프로파일링 기능이나 각종 테스트 툴을 이용한 메쏘드 사용률 등을 체크함으로써 튜닝 포인트를 찾아내야 안정적인 시스템으로 갈 수 있다.

관리적 관점에서 바라본 자바 프로젝트의 진행 단계별 고려 사항
관리적 관점에서의 프로젝트 진행 단계는 시스템 레벨이 아닌 시간에 따른 인력을 비롯한 제반 요소들에 대한 운용 계획을 나눠본 것이다. 이는 대형 프로젝트에서 인력에 대한 관리적 측면에서 나타낸 진행 단계로 프로젝트 제안 단계는 프로젝트 전체 단계라고 보면 된다.

<그림 5> 관리적 관점에서 바라본 자바 프로젝트의 진행 단계

[1] 프로젝트 제안은 객체지향의 개념을 살리도록 한다 : 프로젝트 제안 작업은 시스템 구축을 원하는 고객사에게 어떻게 시스템을 구축해 나가겠다는 내용의 문서를 수십 페이지에 걸쳐서 작성해 보이는 것이다. 이를 위해서 SI 업체는 몇 달 전부터 사전 자료를 수집하고, 프로젝트에 투입될 가능성이 있는 사람들이 모여서 제안서 제출 마감기일까지 제안 작업을 한다. 자바 기반의 프로젝트면 그 중요한 특성인 객체지향 기술의 장점을 살려서 프로젝트 구축을 하도록 기술해야 한다.

[2] 프로젝트 팀 구성에 클래스 설계 전문가를 포함하라 : 제안 요청이 통과되면 프로젝트를 제안했던 사람들을 주축으로 프로젝트의 팀원을 구성한다(물론 제안서에도 프로젝트의 팀원을 어떻게 구성할 것인가가 명시되어 있다). 이때 객체지향 개념과 클래스의 설계에 대한 개념을 가진 사람이 설계의 중심을 잡아줄 수 있도록 팀을 구성해주는 게 낫다. 그리고 클래스 사용의 효율성을 위해 디자인패턴 전문가가 포함되면 금상첨화이다.

[3] 객체지향 분석 및 설계 전문가들이 클래스를 설계하도록 한다 : 프로젝트가 킥오프되면 컨설턴트와 설계자가 투입되어 시스템에 대한 분석 및 설계 단계를 진행한다. 보통은 데이터베이스의 엔티티 모델을 중심으로 하지만 자바 프로젝트의 경우 객체지향 분석을 통해서 나오는 객체들을 클래스와 데이터베이스의 엔티티 모델로 맵핑할 수 있도록 전문가들을 적절히 활용해야 한다.

[4] 개발 및 테스트는 유스케이스 중심으로 하도록 하라 : 분석 및 설계 과정이 끝날 즈음이면 이를 실제로 코드로 구현할 개발자들이 투입된다. 이때가 프로젝트에서 가장 많은 인력이 바쁘게 움직이는 시기다. 그런데 ??단계의 분석 설계 전문가들은 이 단계에는 철수하는 경우가 많다. 이때 그 설계 사상을 이어받을 수 있는 끈은 유스케이스가 해당이 된다.

[5] 시스템 운영자 인수 인계 : 개발 및 테스트를 통과하면 운영자들에게 해당 시스템을 운영할 수 있도록 문서 및 교육을 통해서 인수인계해 준다. 이때의 운영자들은 SM(System Management) 조직에 속한 사람들이다.

규모에 따른 프로젝트의 진행 과정
프로젝트의 진행은 소규모의 경우 개발자가 중심이 되어 진행되지만, 규모가 커질수록 프로젝트 매니저가 마치 오케스트라의 지휘를 하듯이 시스템 컨설턴트, 설계자, 개발자 순으로 프로젝트 단계별로 투입하며 진행해나간다. 게다가 대형 프로젝트는 이러한 프로젝트 관리 및 시스템 구현 방법을 정리해놓은 방법론을 적용해 프로젝트의 성공적 수행을 보장한다. 그래서 프로젝트의 진행 단계를 한 번에 파악하자면 그런 방법론에 있는 사항들을 이해하면 되겠다.

하지만 이 글에서는 필자가 겪었던 소규모 프로젝트에서 진행 단계를 설명하고, 규모가 커질수록 어떠한 차이를 보이면서 단계가 복잡해지고, 왜 이런 단계가 있어야 하는지를 얘기하겠다. 그리고 개발방법론에 따른 단계 설명은 너무 이론적이므로 여기서는 간단하게만 짚어 보고, 자세한 정보는 PMP(Project Management Professional; 프로젝트 관리 전문가) 관련 사이트에서 찾아보길 바란다.

소형 프로젝트는 개발 기간 지연의 위험이 크다
소형 프로젝트는 참여하는 사람이 몇 명 안 되기 때문에 관리자, 설계자, 개발자의 구분이 없다. 그래서 프로젝트에 대한 책임감 있는 관리가 있을 수 없고 그에 따라 개발 기간이 지연될 확률이 매우 크다. 실제로 이런 프로젝트는 아르바이트삼아 하는 프로젝트들이 주로 해당되는데, 필자도 그런 일을 몇 번 했었다. 지금 생각해 보면 제때에 끝난 프로젝트가 거의 없었고 대부분 개발이 지연되어 무척이나 고생했던 일이 많았다.

소규모 프로젝트가 더욱 그러한 이유는 관리적 측면 외에 개발 범위 설정에서도 문제가 발생한다. 이는 시스템의 개발 범위를 명확히 설정하는 분석 단계를 거치지 않기 때문에 그 범위가 모호해져서 나중에 추가적인 요구사항이 계속 발생하기 때문이다. 또한 설계 없이 바로 구축해 나감으로써 코드 에러로 인해 개발이 더욱 늦어질 수밖에 없다.

가장 짧은 기간에 끝날 수 있는 소규모 프로젝트는 개발자 소수가 진행하는 프로젝트로 그 사람들이 필요한 모든 역할을 다 하는 것이다. 여기서 말하는 역할이란 어떤 시스템을 만들 것인가와 어떻게 만들어나갈 것인가를 해결해 나가는 역할이다. 그래서 소규모 프로젝트는 보통 요구사항 파악과 구축이란 두 단계로 진행된다.

필자가 JSP 설문조사 시스템을 구축해 준 적이 있었는데, 이 프로젝트는 실제 기간보다 빨리 끝낼 수 있었다. 혼자 진행하는 프로젝트였지만 분석과 설계 단계를 거치면서 시스템의 범위를 명확히 했기 때문이다. 물론 그와 반대로 괜히 아르바이트삼아 사이트를 구축해 준다고 했다가 개발 기간이 지연되면서 결국은 완전히 구축도 못 해주고 돈도 못 받은 적도 몇 번 있었다.

중형 프로젝트에는 리더의 역할이 크다
중형 프로젝트는 대형 프로젝트에 비해 상대적으로 짧지만 분석, 설계, 구축, 테스트의 단계를 거친다. 그래서 프로젝트의 개발 범위가 어느 정도 명확하고, 단계별로 인력의 역할이 명시되어 있어 무난하게 프로젝트가 진행될 수 있다. 그래서 이 경우는 프로젝트 매니저의 역할이 매우 크다.

프로젝트 매니저가 어떻게 하느냐에 따라서 프로젝트의 성패가 좌우된다. 또한 중형 프로젝트는 소형 프로젝트보다 기간도 길고, 여러 명이서 각자의 규칙을 갖고서 진행을 한다. 그리고 프로젝트 매니저 또는 리더가 그 프로젝트를 관리해나갈 뿐만 아니라 분석 및 설계 규칙도 맡아서 하는 경우가 많다. 그래서 개발자들에게 구축 범위를 알려주고 지정된 기간에 완료할 수 있도록 해준다.

필자가 e-비즈니스 사이트를 3개월에 걸쳐 구축한 프로젝트에 참여했었는데, 여기도 다행히 제때 끝낼 수 있었다. 프로젝트 매니저를 비롯해 6명이 투입돼 진행을 했었는데, 역할이 적절히 분배되었고, 프로젝트 매니저가 분석 및 설계를 명확히 해나감으로써 기간 내에 할 수 있는 목표 범위를 설정할 수가 있었고, 개발 기간에는 함께 밤을 새워서라도 목표 부분을 끝내려는 노력이 있었기 때문이다.

반대로 프로젝트 매니저라는 사람이 팀원 출석만 체크하고 다른 것은 아무 것도 안하는 경우가 있다. 이 경우는 팀 내에서 프로젝트 매니저 역할을 하는 사람이 없다면 대부분 개발이 지연되거나 시스템의 구축 방향이 틀어지는 문제가 발생한다.

대형 프로젝트는 조직간의 유기적 관리가 중요하다
6개월 이상의 대형 프로젝트는 중형 프로젝트에 비해서 조직적이고 체계적으로 움직인다. 중소형 프로젝트는 기간이 짧기 때문에 각 단계별로 각각의 역할을 맡은 사람들이 따로 투입되지 않고 한꺼번에 투입되지만, 대형 프로젝트는 명시된 기간에 해당 인력들이 들어와서 각자의 역할을 하게 된다.

일반적으로 개발자들은 프로젝트 중-후반기에 투입된다. 이런 프로젝트는 해당 프로젝트의 피크타임 때라서 고생을 많이 할 것을 감수하게 된다. 필자도 거의 중-후반기에 투입되어 밤늦게 퇴근하고, 휴일에도 일하러 나간 기억이 많이 있다.

대형 프로젝트에는 워낙 많은 사람들이 여러 가지 규칙을 갖고 참여하므로 처음 들어가 보면 누가 어떤 일을 하는지 쉽게 파악되지 않는다. 또한 프로젝트 총괄 매니저 휘하에 각 프로젝트 매니저가 있고 그 밑에 각 업무별 리더들이 팀을 이뤄 프로젝트가 진행된다. 또한 현업도 이에 맞춰서 각 업무별로 시스템 구축에 참여한다. 필자가 그런 프로젝트에 다수 참여했지만 아직도 사람 얼굴만 알고 이름은 모르는 사람들이 많으며, 무슨 일을 하는지는 직접 물어보기 전에는 거의 모르는 경우가 허다했다.

대형 프로젝트의 경우 워낙 큰 시스템으로 구축되기 때문에 다른 팀과의 협조가 중요하다. 특히 다른 팀과 데이터를 주고받아야 하는 상황이면 더욱 그러하다. 그래서 시스템 통합 테스트를 하게 되면 다른 팀과 제대로 협조가 되고 있는지가 눈에 드러나게 된다.

자바 프로젝트에 적응하기
지금까지 프로젝트가 어떤 것이고, 자바 프로젝트의 특성, 자바 프로젝트의 진행 과정 등에 대해서 살펴보았다. 이제는 ‘자바 프로젝트에 적응하기’라는 주제를 통해 프로젝트에서 어떻게 하면 더욱 잘 했다는 소리를 들을 수 있는지 살펴보도록 하겠다.

프로젝트 기반 기술력
프로젝트에 있어 기술력은 매우 중요하다. 소형 프로젝트일수록 개발자 소수가 거의 감수를 해야 하므로 기술력이 있어야 한다. 반대로 대형 프로젝트의 경우 관련 지식이 어느 정도 있다면 가서 배우면서 할 수도 있다. 필자도 프로젝트에 가서 해당 기술에 대해 배우면서 한 적이 몇 번 있었다. 자바 프로젝트를 임할 때 필요한 기술력을 정리하면 다음과 같다.

[1] 시스템 아키텍처에 대한 이해 : 구축하려는 시스템이 어떤 서버로 어떻게 구성되어 있는지를 이해해야 한다. 그래야 프로그램에 에러가 발생하더라도 어디서 어떻게 발생했는지를 찾아낼 수 있을 뿐만 아니라 고객과의 업무 협의 때 시스템에 대해서 얘기할 수 있다. 예를 들면 웹 프로젝트의 경우 MVC 모델에 입각한 웹 서버-웹 애플리케이션 서버-데이터베이스 서버가 어떻게 구성되어 있는지를 알고 있어야 하고 이를 설명할 수 있어야 하겠다.

[2] 유닉스 기본 환경에 대한 이해 : 자바 기반의 프로젝트는 대부분 유닉스 환경에서 작업한다. 그래서 유닉스 환경에서 기본적인 작업을 할 수 있어야 한다. 자바 관련 컴파일 및 실행은 두말할 것도 없고, 자바 클래스 패스 설정을 위한 환경 변수 셋팅 방법, 기본적인 파일 조작에 대해서 알아야 한다. 그외에 기초적인 유닉스 명령어를 사용할 수 있어야 하며, VI 편집기에도 어느 정도 익숙해야 한다.

[3] 프로젝트 관련 라이브러리 : 맨땅에 헤딩하듯이 프로젝트를 하는 것보다는 관련 프로젝트에서 써먹었던 라이브러리 정도는 갖고서 프로젝트에 임하면 고생을 덜 하게 된다. 기왕이면 이것들이 프레임워크화되어 있다면 어떤 프로젝트에서라도 유용하게 사용할 수가 있을 것이다.

프로젝트 관련 업무 지식
자바 프로젝트라고 하지만 구현할 대상은 ‘자바’가 아니라 고객이 원하는 업무인 것이다. 우리가 흔히 접하는 웹 사이트들은 일반인이 보더라도 쉽게 알 수 있지만, 인터넷 뱅킹 사이트라고 한다면 겉으로 보는 것 외에 내부적으로 은행 업무가 녹아있는 처리 로직이 어떻게 되는지는 경험자가 아니면 알 수 없다. 해당 분야의 경험이 풍부한 사람이라면 두말 할 것도 없지만 그렇지 않는 경우에는 최소한 다음의 준비는 하고 가는 것이 낫다.

[1]업무 관련 용어에 대한 이해 : 해당 프로젝트에서 사용하는 용어는 기본적인 커뮤니케이션 수단이다. 이는 프로젝트팀에서도 같은 프로젝트를 오래 해보지 못했을 경우 서로 쓰는 용어가 다르고, 그 의미가 달라서 오해를 하는 경우가 종종 있다. 더군다나 현업에 종사하는 사람들이 쓰는 용어를 이해하지 못하면 그들이 원하는 시스템을 만드는 것은 더욱 힘들어진다.

[2] 업무 처리의 흐름 : 업무 처리의 흐름을 이해하는 것은 시스템 전체를 봤을 때 데이터의 흐름과도 대체로 일치한다. 그래서 나중에 데이터를 다른 곳에서 받아 처리할 경우 이러한 업무 처리 흐름을 모른다면 그 데이터가 어디서 어떻게 왔는지를 알 수가 없게 된다.

[3] 고객사에 대한 업무 이해 : 시스템을 구축하려는 고객사가 무엇을 하는 회사인지는 기본적으로 알고 있어야 한다. 그 회사의 제품이 무엇인지 어떻게 만들어지는지 홈페이지 등을 통해서 미리 알고 가면 시스템 구축에 도움이 된다.

프로젝트 문화
프로젝트 문화는 프로젝트를 하고 있는 팀의 사무실 분위기, 회의 방식, 근무 태도, 식생활, 여가생활, 취미 등 프로젝트를 수행함에 있어 업무 외에 접하게 되는 포괄적인 문화적 요소들이다. 그래서 프로젝트 문화는 어떻게 보면 앞에서 말한 기술력, 업무지식보다 훨씬 더 중요하다. 아무리 기술력이 뛰어나고 업무에 대한 이해도가 높다고 하더라고 프로젝트 문화에 적응하지 못한다면 이것은 그 사람에게는 프로젝트 실패의 요인으로 작용한다.

어쨌거나 해당 프로젝트에 들어가면 반드시 그 사람들이 하는 그대로를 따르라는 것은 아니다. 다만 거기 사람들과 적당히 어울려서 서로 인간적으로 커뮤니케이션하는 것이 중요하다. 단적인 예로 회의시간에 서로 업무 때문에 딱딱하게 얘기를 하다가고 밖에 나와서 담배를 한 대 피우면서 서로 업무에 대한 고충을 얘기하면서 의외로 협조를 쉽게 구할 수도 있는 것이다.

이번 글에는 자바 프로젝트의 특성과 종류, 프로젝트의 규모와 이에 따른 진행 단계에 대해서 알아봤다. 그리고 프로젝트에 적응하기란 주제로 기술, 업무, 문화의 관점으로 살펴봤다. 특히 프로젝트 문화 부분은 간과하기 쉬우면서도 나중에 이 때문에 예기치 않은 문제가 발생할 수 있다. 다음 글에서는 필자 주위에서 있었던 다양한 프로젝트의 경험들을 통해 성공과 실패의 요인을 분석하고 이를 토대로 프로젝트를 성공으로 이끌기 위한 다양한 방안을 살펴보겠다. @

소프트웨어 개발방법론

소프트웨어 개발방법론이란 소프트웨어를 개발하기 위해 개발 조직 환경과 소프트웨어 및 시스템을 사용할 사용자의 환경에 적합한 소프트웨어 개발방법을 의미한다. 소프트웨어 개발방법은 소프트웨어 공학의 대가에 의해 소프트웨어 개발방법론이라는 학문 형태로 자리잡고 있다. 소프트웨어 개발방법론은 크게 구조적 분석 및 설계(Structured A/D), 정보공학(Information Engineering), 그리고 최근에 각광받고 있는 객체지향 방법론(Object_ OrientedMethodology)이 있다. 실제적으로 보면 현재 기업이나 조직에서 사용하는 방법론은 이들을 적절하게 혼합해 구조적 방법론의 프로세스 모델링과 정보공학의 데이터 모델링을 동시에 사용하고 있다. [1] 구조적 분석 및 설계(Structured A/D): 1970년대 중반1980년대 중반 [2] 정보공학(Information Engineering) : 1980년대 후반 1990년대 중반 [3] 객체지향 방법론(Object_ OrientedMethodology): 1990년대 초반 현재 구조적 분석 및 설계 구조적 방법론은 1970년대 이후 현재까지 가장 널리 사용되어오던 방법론으로 구조적 분석, 구조적 설계, 구조적 프로그래밍으로 이뤄져 있다. 구조적 방법론은 하향식 기능 분할(Fuctional Decomposition)에 기반을 둔 프로세스 중심의 방법론으로, 단순한 업무처리 시스템의 개발에는 효과적이지만 데이터 분석 및 설계 부분이 취약하며, 분석, 설계, 구현에서 상이한 모델을 사용하므로 단계간의 변환에 많은 노력이 소요된다. 따라서 대규모의 복잡한 시스템 개발에는 적합하지 않다. 구조적 방법론은 크게 자료구조 중심적 방법론과 자료 흐름 중심적 방법론으로 분류할 수 있다. 데이터 구조적 방법은 업무나 기능에 의한 데이터의 변환에 관점을 둔다. 반면 처리지향 방법은 기능을 분할하는 방법으로 문제를 독립적으로 분해해 재검토한다. 데이터 구조적 방법론이 문제에 관심을 둔 것이라면 처리 지향적 벙법론은 해결에 초점을 맞춘 것이라 할 수 있다. 구조적 방법론을 지원하고 있는 기법은 대표적으로 DFD(Data Flow Diagram), DD(Data Dictionary), Mini- Spec(Mini-Specification)이 있다. 정보공학 방법론 정보공학 방법론은 1980년대 후반 조직 전반에 걸친 정보 모형화 전략을 채택하며 대두되었다. 정보공학 방법론은 전사적인 차원에서 정보시스템 기획을 통해 단위시스템을 식별하고 이를 CASE 도구를 이용해 분석, 설계, 구현하는 방법론으로 기획 단계가 대폭 강화되고 케이스를 이용한 생산성 향상 등의 장점으로 인해 대규모의 시스템 개발에 적합하다. 즉 전체의 계획과 모델 작성을 하고 이에 따라 연관 관계를 갖고 각각의 시스템을 개발한다. 그러나 정보공학 방법론은 복잡한 시스템의 모델링에 부적합해 현재는 객체지향 방법론으로 대체되고 있는 추세이다. 정보공학 방법을 지원하고 있는 기법은 대표적으로 ERD(Entity Relation Diagram), PHD(Process Hierachy Diagram), 프로세스 대 엔티티 Matrix 등이다. 각 기법에 대한 자세한 사항은 기법을 참조한다. 이러한 정보공학의 특징은 다음과 같다(객체지향 소프트웨어공학, 최영근/허계범). 객체지향 방법론 소프트웨어와 관련된 방법론, 도구 등은 우수한 소프트웨어 구현을 위하여 지금까지 많이 연구?개발되어 왔지만 문제점은 수요가 확대되는 반면 공급이 부족하여 소프트웨어 개발이 수요를 따라가지 못하고 있으며, 유지보수 비용의 비약적인 증가로 소프트웨어 개발 비용이 급증하고 있다는 것이다. 이러한 문제점을 해결하기 위해 제안된 방법론이 객체지향적 접근법이다. 객체지향 접근법은 소프트웨어의 확장이나 변화를 용이하게 해줄 뿐만 아니라 기존 소프트웨어의 재사용성을 증가시켜 준다. 객체지향 시스템에서는 데이터를 다루는 프로시저를 하나로 묶어 객체라는 개념을 사용해 실세계를 표현하고 모델링한다. 객체지향의 개념은 객체(object), 메시지(message), 상속(inheritance)의 세 가지 요소가 근간이 된다. 실세계의 엔티티들은 시스템 내에서 객체로 모델링되어 각 엔티티들은 인스턴스로 표현되고 공통된 특성을 가진 인스턴스들이 모여 하나의 클래스로 구성하게 된다. 즉, 객체지향 방법은 시스템을 연산과 데이터를 함께 갖는 객체의 집합체로 보고, 문제 영역에서 데이터와 함수를 분리할 수 없는 것으로 취급한다. 함수들과 함수의 처리 대상이 되는 데이터는 문제 범위 내에 있는 객체로 취급함으로써 문제 영역의 엔티티가 모델 세계로의 객체로 직접 사상이 가능하기 때문에 응용 영역의 구조와 밀접하게 대응해 개발 비용의 감소를 가져오며, 시스템을 쉽게 이해할 수 있다. 객체지향 방법론을 지원하는 대표적인 것에는 RUP가 있다.