프로젝트 기획!

프로젝트 타당성 분석

프로젝트 선정기법

• 화폐의 시간적 가치 미고려 시: 회계적 이익률법, 회수기간법 등
• 화폐의 시간적 가치 고려 시: 순현재가치법(NPV), 내부수익률법, 편익/비용 비율, 경제적 부가가치, EVA 등 

프로젝트관리란?
앞서서 프로젝트에 대한 정의를 살펴봤다. 그렇다면 이 프로젝트를 관리한다는 것은 무엇을 의미하는가? 이 지점에서 관리라는 용어도 살펴보고 가자. 관리란 흔히 사람을 통제하고 지휘 감독하는 것이나 여러 시설이나 물건의 유지·개량 따위를 꾀하는 것을 말한다. 이를 프로젝트에 대입해 보면 목표를 세우고 계획을 짜며 일들을 수행하고 목표를 달성해 가는 과정에서 필요한 수많은 자원과 시간 그리고 노력은 프로젝트의 관리 측면이다. 이는 매우 필수적이고 중요하며 프로젝트와 관리가 별개가 아닌 하나로서 인식해야 할 필요성을 느낀다.

그래서 프로젝트관리는 “프로젝트 요구를 만족시키기 위해 지식, 기술, 도구 및 기법들을 프로젝트 활동 중에 사용하는 것“이라 할 수 있다. 다시 말해 프로젝트 요구사항을 충족시키고 만족시키는 것, 이를 위한 모든 요소를 잘 이해하고 관리하여 목적한 바를 달성해 나아가고 더 나아가 프로젝트의 성공적 완료를 가능케 한 자원, 특히 조직의 역량을 확보하고 강화하는 것이 그 이면이라고 본다.

그러면 이러한 프로젝트의 성공률은 얼마나 될까? 다소 오래된 자료이긴 하나 지금까지도 유효한 Standish Group의 2010년 Chaos Summary를 보면 30% 정도의 프로젝트만 성공한다고 한다. 그렇다면 나머지 70%는 실패한다는 이야기인데 그 원인은 주로 1) 요구사항의 부정확성 2) 사용자 환경의 이해 부족 3) 불충분한 자원 4) 비현실적인 사용자 기대치 5) 관리지원의 부족 6) 변경 관리의 미흡 7) 프로젝트 계획의 미비 등이라고 한다. 이는 곧 관리 부재의 결과이고 특정 몇몇 사람이 아닌 조직 전체의 문제로 비친다. 특히 관리의 제약 측면에서 살펴보면 다음과 같다.

프로젝트 관리의 3대 제약
프로젝트는 아래 3가지에서 절대 벗어나지 않는다. 이는 프로젝트의 성공과 실패를 구분하는 기준이며 모든 단계의 품질을 좌지우지한다.

● 범위
: 프로젝트에 존재하는 필요와 기대 사이의 요구사항이다. 프로젝트 초반 고객의 요구사항을 제대로 파악하지 못하면 범위는 계속 흔들린다. 상세한 요구사항은 프로젝트의 첫 단추다. 이를 위해 요구사항관리라는 별도의 프로세스를 만들어 놓고 있으며 이를 통해 유기적인 범위관리에 신경을 쓴다.

● 일정
: 프로젝트의 시작과 끝, 그 기간이다. 프로젝트계획 시 범위에 기반한 일정을 수립하지만 철저한 관리가 되지 않는다면 일정은 자연스럽게 지연이 된다. 프로젝트관리자는 일정에 민감해야 한다. 전체 일정과 하루 일정. 진척도는 관리되어야 하며 이슈가 발생하면 전파하고 해결책을 찾아야 한다.

● 원가
: 프로젝트에 할당된 예산은 타당한가? 제대로 된 수요조사와 시장조사를 통해 원하는 사양에 충족한 것들을 선별, 구매했는가? 특히 인건비는 제대로 평가받고 있는가? 예산이 부족하다고 제일 먼저 인건비에 손을 대지는 않았는가? 그래서 실력 있는 개발자들을 외면하고 있지는 않은가? 아니면 한 사람에게 너무 의존하는 것은 아닌가?

성공과 실패
모든 프로젝트는 성공하여야 한다. 그 끝을 위해서 모든 이해당사자는 서로 협력한다. 하지만 성공과 실패의 기준이 무엇인가에 대해서는 의견이 분분하다. 알고는 있지만 서로 상대적인 개념 사이에서 위의 3가지 제약은 훌륭한 기준을 마련해준다. 이를 바탕으로 프로젝트를 관리하고 관리의 성공과 실패 여부는 핵심 이해당사자들에게 달려있다.

이해당사자. 이들은 프로젝트와 밀접한 경영진, 개발자, 관리자, 고객 등이 있다. 이 중에서 고객의 요구사항에 얼마나 잘 부응했는가가 성공을 가늠한다. 3가지 기준에 충실한 관리, 그러면서 고객 요구사항의 충족. 성공은 멀리 있지 않다. 그만큼 실패도 성공의 반대편 가까운 곳에 서 있다. 부정확한 요구사항, 사용자의 몰이해, 충분하지 못한 자원들, 비현실적인 기대치와 무관심, 변화무쌍한 상황들의 관리 부재, 이들을 아우르는 계획의 미비. 그렇다고 유명하단 프로세스나 방법론이 모든 문제를 해결해 줄 수는 없다.

프로젝트는 요리와도 같다. 여러 좋은 재료들을 모아 정해진 레시피대로 정성껏 요리하면 맛 좋은 음식 맛을 볼 수 있다. 이 요리에 있어 요리사는 전체적으로 볼 수 있어야 하고 집중하여 관리하며 문제가 발생했을 때 이를 개선하는 노력을 통한 최적화! 나에게 맛 좋은 음식도 중요하지만, 고객의 입맛에 맞게, 원하는 사항들을 충족시키고 더 나아가 미처 모르던 맛까지 제공한다면 프로젝트는 성공이라 말해도 부족하지 않다.

이해당사자
프로젝트에는 수많은 이해당사자가 존재하며 이들은 프로젝트의 성공 여부를 결정짓는 매우 중요한 개인 혹은 조직이다. 영어로는 stakeholder. ‘지주를 붙잡는 사람’이라는 뜻처럼 각각의 역할과 책임이 막중하다.

  º 프로젝트관리자: 프로젝트 수행 전반의 책임자
  º 고객: 프로젝트 결과물을 사용하게 될 개인 혹은 조직
  º 기능부서 관리자: 프로젝트팀원이 속한 부서의 관리자
  º 경영진: 프로젝트를 수행하는 조직의 최고 관리자
  º 프로젝트부서: 프로젝트를 수행하는 사람 혹은 조직

이들은 그 특성과 영향력 수준에 따라 분류할 수 있고 각자의 이해 분야가 다르기 때문에 여러 갈등의 양상을 보일 수 있다. 이에 프로젝트관리자는 갈등 당사자 간의 이해의 합의를 구하고 해결책을 제시해야 하고 고객의 입장에서 움직여야 한다. 그래서 조직적인 대응으로 PMO를 구성하기도 하고 프로젝트 조직을 프로젝트 상황, 기업조직구조, 방침 등에 따라 기능 조직, 매트릭스 조직, 프로젝트 조직 등으로 나누어 사전에 결정하고 깊게 운영하여야 한다.

※ 너는 너, 나는 나
얽히고 섥힌 사람들로 북적이는 프로젝트에서 프로젝트관리자는 너무나도 중요하다. 그런데 요즘은 이런 부담을 떠안기 싫어 도망가는 사람들로 PM을 할만한 사람 찾기가 하늘의 별 따기 수준이다. 저는 개발만 하고 싶어요! 라는 사람들도 업무를 알아야 개발이 될 텐데 하물며 PM은 어떠할까? 세상은 바뀌어도 PM은 가치는 영원하다.

프로젝트란?

프로젝트란 무엇인가? 많이 들어보고 흔히 쓰고 있는 말이지만 정확히 어떤 뜻인지 설명할 수 있을까? 이것이 안된다면 사실 모르는 말이라 해도 과언이 아니다. 어떤 일을 하기 전에 반드시 짚고 넘어가야 하는 것 중 하나가 바로 용어의 정의이다. 이것을 간과한 경우엔 많은 혼선과 잡음, 서로 간의 반목과 갈등이 생기기 마련이다.

용어로써의 프로젝트란 사전적 의미로 ‘학습자가 스스로 자기 활동을 선택·계획하고 방향을 설정해 가는, 문제 해결의 학습’을 뜻하기도 하고 ‘연구·사업 등의 계획’으로서 `일감’이나 `연구 과제’를 뜻하기도 한다. 여기선 후자의 뜻인데 다시 말해 프로젝트란 전체적인 목적을 향해서 수행하는 일련의 활동들이나 그 목적의 달성과 관련된 정보의 수집으로서 “유일한 제품, 용역 또는 결과를 창출하기 위해 투입되는 일시적 노력“을 말한다. 즉, 프로젝트는 목적을 가진 사람들의 행위이면서 유한하고 뚜렷한 목표가 있다. 그래서 하나의 프로젝트는 반복되지 않고 일상적이지 않다.

프로젝트의 주요 특징
프로젝트는 위에서 언급했듯이 몇 가지 주요한 특징들이 있다. 이를 좀 더 살펴보면 다음과 같다.

● 명확한 목표와 목적

: 흔히들 크게 신경 쓰지 않고 하는 말 중에 목표와 목적이 있는데 목표와 목적은 전혀 다르다. 목표는 흔히들 goal로 이야기하는 실체가 있는 대상이고 목적은 why, 이유이다. 즉, 목표가 있다는 건 프로젝트의 가장 큰 특징 중 하나다. 그래서 목표를 달성하면 프로젝트는 자연스레 소멸한다. 그렇기 때문에 프로젝트 조직이 별도로 구성되었을 때 그 프로젝트의 목표가 이뤄지면 그 조직은 해체된다. 이런 목표는 성과로 산출되고 평가가 된다. 지속해서 피드백되고 목표를 이루고자 하는 목적의식으로 모든 구성원은 함께 나아가게 된다.

● 한시성

: 시간이 정해지지 않았다면 이것은 프로젝트가 아니다. 우리가 잘 아는 140여 년 전부터 시작된 스페인 바르셀로나의 가우디 성당 프로젝트는 그 끝이 언제인가에 대해서 말이 많았지만 아마도 2026년이 되면 이 프로젝트의 마침표를 찍을 예정이다. 이를 이제 프로젝트라고 말할 수 있는 것은 그 목표 시점이 정해졌기 때문이다. 짧은 단위 프로젝트이던 긴 장기 프로젝트이던 프로젝트라고 불리기 위해선 반드시 시작과 끝이 있어야 한다는 것이다. 이것이 한시성이다.

● 유일성

: 그렇다면 목표와 목적, 명확히 정해진 기간만 있다면 프로젝트가 맞는가? 물론 틀리진 않지만 중요한 또 다른 특징 중의 하나는 세상 어디에도 없는 유일함이다. 이는 그 프로젝트 자체, 즉, 환경, 사람, 행위, 내용, 사건, 결과 모두를 고려한 유일성이라 볼 수 있다. 이 때문에 이 프로젝트가 다른 프로젝트와 다르다고 말할 수 있고 선언할 수 있으며 그래서 이 프로젝트에 참여했던 모든 구성원이 흥미와 보람을 여기서 찾을 수 있는 것이다. 어디 가서 경험할 수 없기 때문이다.

● 상세화

: 프로젝트는 매우 치밀하고 구체적이며 그 면면이 상세하다. 그 상세함은 내용을 중시하며 보다 지속해서 점진적으로 구체화한다. 큰 틀에서 큰 그림을 그리고 페이지를 점점 넘길수록 그 내용의 밀도를 더해가는 상세함이 프로젝트를 어렵게 만드는 이유이기도 하지만 이 상세함이 없이는 프로젝트가 제대로 완성될 수 없다. 그래서 이 부분은 많은 시간이 필요하고 풍부한 경험이 중요하게 된다. 즉, 고객 접점의 수많은 이야기가 하나도 빠지지 않고 제대로 써지는 것을 말한다.

사례들

우리 주변에 보면 정말 많은 프로젝트가 수행되고 있고 끝이 나고 새로 시작되며 혹은 여러 사정으로 마무리를 짓지 못하고 있다. 흔히들 보는 건축이 그렇다. 우리 동네에 어느 날 갑자기 아파트가 들어선다. 그 공사 현장 입구에 가면 조감도를 비롯하여 여러 사항을 확인해 볼 수 있다. 특히 위에서 이야기한 특징들의 면면을 볼 수 있다. 건축은 아마도 프로젝트가 가장 잘 적용되며 실질적으로 다양한 측면의 기법들이 가장 발달한 분야이기도 하다. (특히 IT는 건축에서 왔다고 해도 무방하다)

신제품 개발도 그렇다. 매년 출시되는 S사의 휴대폰을 한번 보자. 주기적으로 서로 다른 제품군을 선보이고 있으며 이는 향후 몇 년 뒤까지 이미 로드맵으로 설정되어 있다. 수많은 예산과 인력이 투입되며 첨단기술의 향연이 펼쳐진다. 엄청난 수의 부품을 짜인 틀에 최적화시키고 기능을 개선하며 멋진 디자인을 입혀 사용자를 만족시키기 위해선 보통의 프로젝트 기술이 아니다. 그런데도 성공하는 모델과 그렇지 않은 모델들로 흥망성쇠를 보며 기뻐하고 슬퍼할 이해당사자들의 노고를 우린 손에 쥔 자그마한 휴대폰으로 보고 있다.

프로젝트는 운영이 아니다. 굳이 비교한다면 가게를 운영한다고 하지 프로젝트라고 부르지 않지 않는가? 물론 제한된 자원으로 계획을 세우고 일하고 관리하는 일련의 과정은 같지만 이야기한 한시적이고 유일하며 목표한 바가 달성되고 종료되는 것이 바로 프로젝트다. 일을 지속하기 위해 끊임없이 반복하는 것은 운영의 영역이다. 이제 프로젝트가 무엇인지 알았으니 프로젝트 속으로 한 발자국을 내디뎌 다음 단계로 나아갈 차례다.

※ 용어의 정의!

같은 시각, 같은 장소에서 똑같은 사안으로 의견을 나누고 결정해도 서로 흩어져 각자의 자리로 돌아가 일하다 보면 그때 나뉘었던 이야기들이 모두 달라서 얼굴을 붉히던 적인 한두 번이 아니다. 결국 서로 다르게 이해한 용어에 관해서 확인하지 않은 죗값이었다. 죄를 묻기 싫다면 아는 용어라도 반드시 확인하자. 미팅이 끝날 때 다시 한번 리뷰하는 그 짧은 시간이 아무것도 아닌 것 같지만 돈과 시간을 아껴준다. 사람 사이를 넉넉하게 해준다.

프로그래밍 – 구현

설계작업들이 끝나면 시작되는 소프트웨어 프로그래밍은 요구사항에 대한 실질적인 구현행위이다. 특히 분리하여 구현할 수 있는 작은 단위로 나눠 작업을 한다. 프로그래밍의 수행이 상세 설계나 사용자 지침에 기술된 내용과 일치되도록 작업하여야 한다. 이 작업에서 가장 중요한 것은 표준을 정하고 준수하고 이에 따라 정확하게 작성하는 것이다. 소프트웨어의 품질은 결국 이를 얼마나 잘 수행하여 원시 코드에 반영하느냐이다. 따라서 프로그래밍에서는 소프트웨어의 기능구현이 급급한 것이 아니라 요구되는 품질에 얼마나 부합하도록 작업하는가에 대한 관심과 끊임없는 노력이 매우 중요하다. 

※ 코딩과 프로그래밍?
이 용어는 모두 컴퓨터와 상호 작용하고 컴퓨터 시스템을 생성하고 유지 관리하는 데 중요한 기술로 종종 같은 의미로 사용되지만, 프로그래밍 과정 중 코드를 작성하는 구체적인 단계를 가리키며, 프로그래밍은 문제 해결을 위한 전체적인 과정을 의미하기에 사실은 서로 다르다.

• 코딩(coding): 프로그래밍의 하위 세트 중 하나로 구체적으로 언어의 문법을 따라 컴퓨터가 이해할 수 있는 명령어를 작성(원시 코드)하는 작업으로, 프로그램 로직을 작성하고 알고리즘을 구현하며 문제를 해결하기 위한 코드를 작성하는 활동
• 프로그래밍(programming): 문제 해결을 위해 컴퓨터에 명령을 전달하는 전체적인 과정으로 문제를 이해, 정의하고 요구사항을 분석하며 그에 따라 적절한 알고리즘과 데이터 구조를 선택한 후 코드를 작성하는 단계와 함께 디버깅, 테스트, 최적화 등의 소프트웨어 개발 과정을 포괄하는 개념으로 컴퓨터 시스템을 생성하고 유지관리하는 프로세스

프로그래밍 원리

앞서 용어 정의와 같이 코딩은 프로그래밍 작업이다. 이러한 구현단계의 목표는 설계 명세에 나타난 대로 사용자 요구를 만족할 수 있도록 프로그래밍을 하는 것이다. 이렇게 하기 위해서는 코딩 단계에서는 전 단계의 문서들을 잘 참조하여야 한다. 특히 무엇보다도 오류가 적은 품질 좋은 프로그램을 작성하는데 그 목표가 있다. 신속성도 중요하지만 견고한 코드를 만들어내는 것에는 많은 연습과 경험이 필요하다. 이를 위하여 수많은 원리와 가이드를 만들고 잘 참고해야 한다.

일반적인 객체지향 코딩에는 다음과 같은 단계가 있다.

• 원시 코드 스타일의 코딩표준 작성
• 아키텍처 설계 결과 프레임워크 패키지와 응용 패키지 결정
• 패키지 내 각 클래스에 대해 요구사항과 상세설계를 반영한 메소드 코딩
• 클래스 구현 후 인스펙션 실시
• 클래스 단위 테스트 진행
• 클래스/패키지를 배포, 통합

이러한 작업을 진행하면서 오류는 프로그래머가 가장 신경 써야 할 부분 중 하나다. 개발과정에서는 특히 많은 시간이 오류를 찾고 해결하는 데 쓰이는데 일정 부분 이상은 흔히 발견되는 오류로 이를 알고 접근한다면 많은 부분의 비용을 절감할 수 있다. 아래는 여러 오류 중 중요한 몇 가지의 예이다.

• 메모리 누수: 이는 메모리가 풀리지 않고 계속 할당하는 현상으로 보통 가비지 컬렉션이 자동으로 되지 않은 언어에서 이러한 오류가 자주 발생한다. 메모리 누수는 규모가 작은 프로그램에서는 영향이 적지만 대규모 환경에서는 시스템에 매우 치명적인 영향을 줄 수 있으므로 반드시 잡아야 한다.
• 중복된 해제 선언: 프로그램 내에서는 자원할당 후 사용 후 해제해야 한다. 그런데 해제된 자원을 또다시 해제하는 경우도 매우 심각할 수 있다. 만약 두 개의 해제문장 사이에 메모리 할당 호출이 있다면 이런 오류의 영향은 예측할 수 없다.
• NULL: null을 포인트하고 있는 곳의 내용에 접근하려고 하면 오류가 난다. 이는 시스템을 다운시키기에 충분하다. 그런데 찾기도 어려운 것이 이것이다.
• 배열 인덱스 오류: 배열 인덱스의 한도를 벗어나면 예외 오류가 발생한다. 그러므로 인덱스가 음수 또는 한도를 벗어나지 않는지 항시 확인하여야 한다.
• 수식 예외: 0으로 나눈다거나 변동 소수점 예외 오류 등이다. 
• 사용자 정의 자료형: 오버플로우나 언더플로우가 특히 많다. 
• 버퍼 오류: 보안결함에서 많이 발견되는 유형으로 해커들의 잠입 루트가 되기도 한다. 
• 동기화: 공통된 자원에 접근하는 다수의 스레드가 있는 병렬 프로그램에서 흔하게 발견된다. 이 또한 쉽게 발견되기가 어려운데 시스템에는 막대한 지장을 줄 수 있다. 흔히 deadlock이 여기에 속한다.

구조적 프로그래밍, 이를 위해서 많이 사용하는 제어구조가 있는데 순차, 선택, 반복이다. 이 또한 제대로 된 흐름제어 기준을 정해놔야 한다. 무조건적인 제어의 흐름을 막고 알고리즘을 명확하게 구현할 수 있는 가이드를 제시하고 공유한다. 물론 근래의 프로그래밍 언어들은 이를 고려하여 여러 명령어나 제약을 두고 있으며 필요하다면 비구조적 문형으로 개발을 할 수도 있다.

또한 모든 프로그램에는 항상 도메인에 관한 정보를 다루기 때문에 자료구조가 항시 존재한다. 그래서 특정 정보에 대해서는 정해진 오퍼레이션만 적용된다. 즉 문제 도메인에 있는 아주 작은 정보가 제한된 방법으로만 사용된다는 것이다. 이를 앞서 다뤄본 정보은닉의 원리 적용이다. 정보은닉이란 모듈 사이의 결합을 줄이고 시스템의 유지보수를 쉽게 만드는 장점을 가지고 있고 데이터를 관리하려는 관점과 데이터를 사용하는 관점을 분리할 수 있는 것이다.

코딩 스타일

프로그래밍 스타일이다. 같은 작업을 위하여 여러 사람이 작성한 프로그램들은 문장의 패턴이나 그 구성 등 여러 면에서 다른 스타일을 보인다. 각자의 개성이다. 하지만 이를 방치할 경우 프로젝트는 원하는 목표를 달성하기 어렵다. 그래서 가르치고 학습할 수 있는 공통된 스타일을 만들어야 한다. 물론 여기에서도 기준을 구하기 어려울 수도 있지만 가장 근본은 간결하고 읽기 쉬워야 한다는 것이다. 이를 기준 삼아 코딩 스타일을 만든다.

• 명명 규칙 예
  • 패키지: 타 사용자들을 위해 패키지 이름 앞에 도메인명을 붙인다. 이를 통해 패키지의 용도와 목적을 잘 나타낼 수 있다.
  • 타입: 클래스(명사)와 인터페이스(명사, 형용사) 등의 명칭 첫 글자를 대문자로 한다. 이는 일반 변수와 구별할 수 있다.
  • 메소드: 타입과 달리 첫 글자를 소문자(동사)로 하고 연속되는 단어의 첫 글자는 대문자로 한다. 이는 메소드 호출과 생성자 호출과 구별할 수 있게 해준다.
  • 변수: 메소드와 같은 형식이다.
  • 상수: 보통 대문자로 구성하며 단어 사이는 밑줄로 연결한다.
• 포인터와 레퍼런스: 포인터를 매개변수로 사용하지 않고 레퍼런스 타입으로 한다.
• 자료형: 오브젝트 타임을 돌려보내는 클래스는 특정 타입의 객체를 배출하도록 캐스트 한다.
• 문장과 수식: 반복 문장이나 수식은 메소드나 클래스로 패키지화하여 사용한다.
• 오류처리: 오류 데이터 타입 제한, 입력 처리 전 데이터 소스와 인터페이스 하여 사전 확인 등의 방법이 필요하다.
• 들여쓰기: 코드 블록의 계층 구조를 명확하게 표현할 수 있게 공백 문자나 탭을 사용한다.
• 주석: 코드 설명을 부가적으로 추가한다. 양의 문제보다는 내용을 정확히 전달하는 것이 중요하다.
• 코드 문서화: 다른 사람들이 정확하게 사용할 수 있도록 주석을 명확히 하고 문서화도 병행한다.
• 포맷 도구 사용: 개발 환경 편집기에 있는 기능으로 스타일가이드를 바탕으로 세팅하여 사용할 수 있다. 이를 통해 일관된 스타일 유지가 가능하다.