박종명의 아름다운 개발 since 2010.06

이 글은  제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=480

---

사람들끼리 모여서 일을 하다 보면 갈등은 피할 수 없는 주제이다
개개인의 성향과 기질이 다른 것은 차치하고서라도 업무의 우선순위, 맡은 역할, 일정 준수 등
프로젝트를 완료하기 위한 하나하나의 과정들에서 갈등은 발생할 수 있다

이번 시간에는 이러한 갈들을 PMI에서는 어떻게 정의하고 관리하는지에 대해 알보도록 하자

프로젝트 수행 중 발생되는 많은 갈등의 원인은 일정과 업무우선순위,자원에 있다
일정을 준수하지 못하거나 일정을 오버하거나 일정 변경 없이 범위가 변경하거나 특정 리소스의 결핍으로 인한
일정 위험을 느낄때, 또한 업무에 대한 우선순위 결정등에서 갈등이 많이 발생하게 된다

프로젝트 초기에 갈등의 원인은 다음의 순위라 할 수 있다
업무우선순위 > 일정 > ...

그리고 보편적인 경우, 그리고 프로젝트가 중반 이후로 갈 수록 갈등의 원인은 다음의 순위로 바뀐다
일정 > 업무우선순위 > 자원 > ....


프로젝트 수행 중 이러한 이슈들은 각 개인들의 견해차이를 발생시키고 결국 사람간 갈등으로 번지게 될 수 있다
PMI에서는 갈등의 당사자는 갈등해결에 1차적 책임이 있으며 갈등 해결에 반드시 참여해야 한다고 말한다
PMP에서 갈등을 해결하는 순서를 다음과 같이 제시한다

갈등 당사자간 사적으로 해결 => PM의 중재 => 공식적 절차

즉 당사자간 해결이 최선이며 이것이 힘들 경우 PM이 중재할 수 있다
만일 PM의 중재에도 갈등의 해결되지 않고 프로젝트에 악영향을 미칠 수 있다면 종국에는 징계와 같은
공식적인 절차를 사용할 필요가 있는 것이다


* 갈등을 바라보는 관점의 변화
현대에 와서 갈등의 평가는 과거와는 달라 졌다

과거의 전통적인 관점에서 갈등은,
특정 문제 유발자 때문이며 갈등 자체가 나쁜것이며, 웬만하면 피하거나 억압하여 갈등이 발생하지 않도록
하는 것이 최선이라 생각했다

그러나 현대의 관점은,
갈등은 피할 수 없는 것이며 변화에 따른 자연적 현상이며 관리할 수 있으며 관리해야 하는 것 그리고
갈등이 꼭 나쁜 것만은 아니며 가끔 이익이 된다는 관점으로 변화하고 있다

* 갈등 해결의 5가지 방법
갈등을 해결하기 위해서는 일방적으로 자기 주장만 할 수 없다
때로는 타협이 필요하며 한발 물러서거나 한발 나가거나 하는 융통성이 필요하다
갈등을 해결하는 5가지 방법에 대해 알아보자

1.철수/회피 (Withdrawal)
자기 주장도 하지 않고 타협도 하지 않고 그냥 회피하는 방법이다
낮은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 회피를 사용할 만 하다
- 이슈가 사소한 것일 때
- 추가적인 정보가 필요 할 때
- 자기의 의견이 관철될 가능성이 매우 낮을 때

이 방법은 일시적으로 상황을 진정시키는 효과는 있지만 가장 피해야 할 갈등해결 방법이라 하겠다

2. 양보/수용 (Smoothing)
자기의 주장은 낮추고 타협을 중시하는 방법이다
낮은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 양보를 사용할 만 하다
- 나중을 위하여 신용을 얻고자 할 때
- 조화와 안정이 매우 중요할 때(분위기가 우선일  때)
- 이슈가 갈등 상대방에게 보다 중요한 사안일 때

이 방법은 분위기를 중시하고 좋은 인상을 줄 수는 있지만 갈등의 근본적인 해결 방법은 아니라 하겠다

3. 타협 (Compromising)
자기의 주장도 적당히 하고 타협점도 찾는 방법이다
중간 주장, 중간 협력으로 다음과 같은 상황에서 이러한 타협을 사용할 만 하다
- 목표는 중요하나 더 이상 설득이 힘들 때
- 비슷한 파워를 가진 집단들 끼리의 갈등일 때
- 양측이 어느정도 만족할 수 있는 합의점을 도출할 때

이 방법은 양 당사자간 타협점을 찾는 좋은 방법이긴 하지만 만족도는 다소 떨어질 수 있다 하겠다

4. 강요 (Forcing)
자기의 주장을 강하게 고집하고 타협은 하지 않는 방법이다
높은 주장, 낮은 협력으로 다음과 같은 상황에서 이러한 강요를 사용할 만 하다
- 인기 없는 정책이지만 꼭 필요한 정책을 집행할 때
- 긴급한 사안을 결정해야 할 때
- 갈등 상대방보다 경쟁우위에 있을 때

이 방법은 자신의 주장을 관철시킬 수는 있지만 부작용이 따를 수 있다 하겠다

5. 문제해결/대면 (Problem Solving/Confrontation)
자신의 주장도 강하게 어필하면서 타협점도 적극적으로 찾는 방법이다
높은 주장, 높은 협력으로 다음과 같은 상황에서 이러한 문제해결을 사용할 만 하다
- 매우 중요한 통합된 의견을 도출하고자 할 때
- 공감대를 형성해 지속적인 관계유지가 필요할 때

이 방법은 시간이 오래 걸리는 단점이 있지만 갈등해결을 위한 가장 효과적인 방법이며 근본적인 갈등해결
방법이라 하겠다

이 글은  제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=479

---

프로젝트를 수행하기 위한 인적자원을 획득하고 관리하는 것에 대해 알아보자

* 팀 획득
팀 획득이란 말 그대로 팀원을 모집하는 것이다. 아래와 같은 방법으로 팀원을 셋팅하게 된다

1. 사전 배정
프로젝트 수행하기 전에 이미 일부 인원이 사전에 배정된 경우가 있다
예를 들어 경쟁 입찰 과정에서 특정 인원 투입이 약속되어 있는 경우, 프로젝트가 특정 개인의 전문성에 달려 있는
경우, 조직에서 사전에 배치 하기를 원하는 경우 등이다

2. 협상
다른 부서 혹은 다른 프로젝트 팀의 인원을 팀원으로 영입할 수 있다
이럴 경우 각 부서장 및 PM과의 협상을 통해 인원을 공급받도록 한다

3. 획득(조달)
조직 내부에 가용할 수 있는 인력이 없거나 부족한 경우, 외부에서 조달할 수 있다
보통의 직원 채용을 예로 들 수 있겠다

* 가상팀(Virtual Team)
보통의 팀은 같은 사무실에 같은 시간에 상주하며 일을 하게 된다
그러나 경우에 따라서는 원격에서 그것도 서로 다른 시간대에 일을 하게 될수 있다
원격으로 떨어져 전자우편이나 화상회의 등을 통해 프로젝트를 수행하는 팀을 가상팀(Virtual Team)이라 한다

다음과 같은 상황일 경우 가상팀으로 팀을 셋팅하게 된다
- 지역적으로 사람들이 프로젝트를 수행할 때
- 재택근무를 하는 사람들이 프로젝트를 수행할 때
- 근무시간이 다른 사람들이 프로젝트를 수행할 때

이러한 가상팀에서는 중요한 것은 의사소통이다
같은 장소에 같은 시간에 얼굴을 마주보며 일을 하지 않기 때문에 의사소통에 더욱 많은 신경을 써야 한다
또한 팀원들 간의 신뢰가 바탕이 되어야 원할한 프로젝트 수행이 가능하다
그리고 지역적으로 나아가 국가적으로 떨어진 사람들끼리 일을 하기 때문에 각 지역,국가의 문화(culture)를
알고 이해하고 배려하는 것이 필요하다

이러한 가상팀은 출장비 및 시,공에 제약을 받지 않는 장점이 있지만
PM이 팀의 통제가 어렵다는 점과 팀원 사이에 분쟁이 발생할 가능성이 높다는 점, 의사소통이 쉽지 않다는 점이
단점으로 작용할 수 있다

이러한 가상팀과 반대되는 개념이 공동 배치(Co-location) 이다
팀의 업무 수행능력을 향상하기 위해 물리적으로 동일한 장소에 배치하도록 한다
나아가 War room 과 같이 마치 전쟁터에서 중앙 상황실과 같은 개념을 도입해 프로젝트 진행 상황을
보다 적극이지고 직접적으로 팀원들과 공유할 수 도 있다


* 킥 오프 미팅(Kick-off meeting)
프로젝트를 본격적으로 수행하기 전에 하는 일종의 착수 회의이다
킥 오프 미팅은 프로젝트 초반에 수행하는 중요한 팀 형성 활동이며
프로젝트의 목표, 팀원의 역할과 책임을 정의하고 공유하는 자리이다
다만 킥 오프 미팅에서는 예산 및 비용, 계약과 관련된 내용은 토의하지 않는 것이 원칙이다

* 팀원들의 동기 부여
팀원들의 동기를 자극하기 위해서는 포상과 같은 직접적인 방법이 있을 수 있으며
기획과정에 팀원을 참여 시키는 방법 등과 같이 간접적으로 동기부여를 할 수 있다

포상 및 보상
- 반드시 성과에 근거해야 한다
- 분명하고 명확하고 실현가능해야 한다
- 상대 평가, 우수 사원 포상과 같은 개념은 제로섬(zero sum) 혹은 윈-로즈(Win-lose) 보상이라 하며
  팀 결속력을 해칠 가능성이 있으므로 주의해야 한다
- 팀원들이 각기 다른 문화권일 경우 보상 방식에 문화를 고려해야 한다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=477

---

프로젝트의 3대 제약사항인 범위,시간,원가가 충족되었을 때 비로써 프로젝트의 품질이 보장된다고 하였다

이러한 제약사항 속에 프로젝트를 원활히 수행하는 것은 다름아닌 사람이다
결국 어떤 사람이 어떤 역할과 책임으로 무엇을 어떤 방식으로 수행할지를 관리하는 것이 바로
인적자원관리(Human Resource Management)이다

그리고 인적자원관리 측면에서 인적 자원이란 범위는 프로젝트를 직접 수행하는 구성원 이외에도
고객, 오너, 스폰서, 외부 관계자, 프로젝트 연관자 등 모든 이해관계자가 포함된다

* 인적자원관리 프로세스
인적자원관리는 다음의 과정으로 이루어 진다
인적자원 기획 -> 프로젝트 팀 획득 -> 프로젝트 팀 개발 -> 프로젝트 팀 관리

1) 인적자원 기획
인적자원과 관련해 제일 처음 수행하게 된다
어떤 사람이 필요할지를 계획하고 이에 대한 인력 조달 계획을 수립하며
프로젝트의 R&R(역할 및 책임)을 정의하고 의사소통 관계 및 보고관계를 식별하는 과정이다

2) 프로젝트 팀 획득
말 그대로 사람을 뽑는 것이다. 프로젝트 수행을 위한 적절한 인적 자원을 효과적으로 획득하도록 한다

3) 프로젝트 팀 개발
사람만 뽑아 놓고 일만 시켜 놓았다고 해서 다 되는 것이 아니다
팀원들의 의지를 고취 시키고 역량을 꾸준히 개발 시킨다

4) 프로젝트 팀 관리
개개인의 성과를 파악하고 개선시킨다
사람대 사람간 발생한 갈등을 파악하고 해소시키며 인력의 변경 사항에 대해 관리하는 과정이다

* 조직 구조
조직이 어떠한 보고체계를 가지고 있으며 어떤 구성으로 조직되어 있는지 PM의 권한은 얼마정도 인지,
의사결정의 핵은 누가 쥐고 있는지 등의 조직의 고유 특성 및 구조가 인적자원에 있어 고려사항, 즉 제약사항이
될 수 있다

PMI에서는 조직구조를 다음과 같이 3가지로 구분하고 있다

1. 기능(Functional) 조직
기능조직은 한국 사회에서 가장 많이 볼 수 있는 조직 구조이다
특히 자체 솔루션을 개발하는 조직에서 가장 많이 보이는 구조인데 각각의 고유한 부서가 이미 존재하며
(이러한 부서를 기능부서라 한다) 프로젝트 수행을 위해 각 부서의 특정 인력이 배정되어 프로젝트가 수행되는
조직구조이다.
이러한 조직 구조에서의 PM의 권한은 아주 미미할 수 있다
즉 각 (기능)부서의 부서장이 이미 존재하기 때문에 PM의 의사결정권이 약하며 팀원들 역시 기능 부서장과
PM에 각각 보고해야 하며 프로젝트 수행을 위한 조직구조보다 기존 기능구조의 인식이 더 강해 기능 부서에
소속감이 더욱 강하다

2. 프로젝트화된(Projectized) 조직
기능 조직과 정 반대되는 개념이다
프로젝트 수행을 위해 똘똘 뭉친(?) 조직이며 이 조직의 목표 자체가 프로젝트 성공이 된다
즉 프로젝트를 위해서 조직이 존재하며 프로젝트를 위한 결속력 역시 강하다
이러한 조직 구조에서는 PM의 권한이 막강하다
팀 목표 자체가 프로젝트 성공이기 때문에 PM의 모든 의사결정권을 가지고 있으며 전사적 지원이 이루어 진다
기능 부서 처럼 각 부서의 이해관계에 얽매일 필요가 없어 프로젝트 수행에 효과적인 특성을 보인다
보통 외주를 받아 프로젝트를 수행하는 SI 조직에서 많이 찾아 볼 수 있는 구조이다

3. 매트릭스(Matrix) 조직
기능조직과 프로젝트조직의 중간정도의 특징을 가지고 있다
이러한 조직 구조에서의 PM의 권한은 역시 중간정도라 할 수 있다
PMI에서는 보다 매트릭스 조직을 보다 세분화 하고 있는데,
약한(Weak) 매트릭스, 균형(Balanced) 매트릭스, 강한(Strong) 매트릭스가 그것이다

약한 매트릭스 조직에서의 PM은 촉진자(expeditor) 역할을 하며 기능조직 부서장의 권한보다 적다고 할 수 있다
균형 매트릭스 조직에서의 PM은 기능조직 부서장과 유사한 권한을 행사할 수 있다
강한 매트릭스 조직에서의 PM은 매트릭즈 조직 상 가장 강한 권한을 가지며 기능조직 부서장보다 우위의
결정권을 가질 수 있는 구조이다

그러나 이러한 매트릭스 조직 구조에서도 대표적인 갈등의 주 요인이 권한 관계라 할 수 있다
완전히 프로젝트화 된 조직이 아니면 각 부서의 이해관계가 얽혀 있으며 이에 따른 관계가 갈등이 될 수 있다
PMI 에서는 이중 보고 및 애매한 권한 관계로 갈등이 발생하게 되면 PM이 해결하라고 권고하고 있다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=475

---

일정 개발의 기법 중 CCM(Critical Chain Method)라는 것이 있다

이는 각 활동 사이의 여유시간을 별도로 관리하여 일정을 타이트하게 운영하는 기법이다
이전에 살펴 봤던 CPM(Critical Path Method)을 통한 네트워크 및 일정 산출 방식은 동일하지만,
각 활동 사이의 여유 시간은 별도로 떼 내어서 필요시 여유시간을 적절히 공급하겠다는 원칙이다


다음과 같이 전체 일정안에서 각 활동을 수행하는 기간에 여유시간이 포함되어 있을 경우

여유시간을 각 활동사이에서 제거하여 별도로 모아서 관리하도록 하는 기법이다
이렇게 하여 불필요하게 노는시간(?)을 없애 프로젝트를 보다 타이트하게 운영하고자 하는 기법이다

눈치챘겠지만 이 기법은 관리자들이 만든 가장 최근에 등장한 기법이다
결론적으로 쉴 팀을 주지 않고 빡빡하게 일을 시키겠다로 해석될 수 있는데
이 기법에는 다음과 같은 이론이 뒷 받침 하고 있다

1) 학생 증후군(Student syndrome)
보통 학생들은 시험기간이 코 앞에 다가와야 벼략치기를 해서 최대의 집중을 발휘 한다
이렇듯 일이 닥치기 전에는 느긋함을 피우는 비효율적인 것을 예방하기 위해 CCM 기법이 만들어 졌다
그러나 이는 잘못하다가는 프로젝트를 지연시킬 수 있는 위험도 내포하고 있다

2) 파킨슨 법칙(Parkinson's Law)
모든 작업은 납기일을 준수한다. 역설적으로 말하자면 빨리 끝낼 수 있는 일이라도 납기일이 남았다면
천천히 수행하여 납기일만 맞춘다는 법칙이다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=474

---

지금까지 프로젝트 일정을 산출하기 위한 사전 프로세스들에 대해 알아 보았다

활동정의, 활동 순서 부여, 활동 자원 산정, 활동 지속 기간 산정이 그 프로세스 들이다
이러한 사전 프로세스를 거치며 어떤 활동이 필요하며 이를 수행하기 위해 어떤 자원이 언제 필요하며
각 활동들간의 연관관계 및 개발 활동들의 소요 기간을 산정하였다

이제 이를 종합적으로 통합하여 프로젝트를 수행하기 위한 전체 일정을 산출하는 방법에 대해 알아보도록 하자

* CPM (Critical Path Method), 핵심 경로법
개별 활동들을 연결하여 '순방향 분석' 과 '역방향 분석'을 수행하여 각 활동의 시작일과 종료일 그리고 여유시간 및 전체 프로젝트 수행 기간을 산출하는 기법이다

* CP(Critical Path)
CPM에서 CP(Critical Path)는 핵심 주요 구간(경로)로써 각 활동들을 연결했을 때 수행 기간이 가장 긴 경로를 
나타내는데 이 구간은 여유시간이 0 이며 전체 프로젝트 소요 기간을 나타내므로 프로젝트 매니저가 가장
신경을 써야 하는 구간이다

다음의 그림을 보자
아래 표는 각 활동과 활동의 연관관계 그리고 개별 활동의 수행 기간까지 산정된 결과를 나타낸다

각 경로별로 수행기간을 계산 해 보면 다음과 같다
Path 1) start -> A -> C -> F -> end : 8일
Path 2) start -> B -> D -> F -> end : 6일
Path 3) start -> B -> D -> G -> end : 10일
Path 4) start -> B -> E -> G -> end : 13일

총 4가지 경로 중 가장 긴 수행 기간을 가지는 구간은 Path 4 가 된다
즉 Path 4 가 CP(Critical Path)가 되며 이는 곧 프로젝트를 수행하기 위한 총 소요시간이 되는 것이다
물론 프로젝트 매니저가 가장 신경을 써야 하는 구간이된다

참고로 위 표에서는 CP 가 1개 였지만, CP 는 경우에 따라 여러개가 될 수 도 있다
즉 최장기간이 동일한 구간이 여러개가 될 수 있다는 것이다
이렇게 CP가 많아지게 되면 프로젝트의 위험(Risk)이 올라간다

그리고 각 활동들의 수행 기간이 일부 변경되는 경우가 발생한다면 CP도 변경될 수 있으므로 주의깊에
살펴 봐야 한다
예를 들어 활동 D의 수행기간이 기존 2일에서 7일로 변경된다면
Path 3 일정이 총 15일이 되어 CP가 Path4 에서 Path3으로 바뀌게 된다

CP는 프로젝트 일정에 주의를 요하는 구간인 만틈 CP의 변경사항을 잘 파악하여 적절히 상황에 맞도록
프로젝트를 수행하여야 할 것이다


이제 순방향 분석과 역방향 분석을 통해 각 활동의 시작일과 종료일 그리고 여유시간을 산출해 보도록 하자

* 순방향 분석(Forward Scheduling)
Start 시점으로 부터 왼쪽 -> 오른쪽으로 계산하는 방식이다
ES(Early Start date): 빠른 착수라 해석하며 바로 앞 활동을 마친 후 착수 할 수 있는 가장 빠른 시점이다
EF(Early Finish date): 빠른 종료라 해석하며 ES 이후 활동이 완료되는 시점이다 

다음과 같이 활동(Activity)에 대한 기간 및 ES,EF를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 ES 와 EF를 계산한 예시이다

1일 부터 시작하여 각 활동이 소요되는 기간을 더해 나가는 방식이다
활동 B의 경우를 보면, A 활동을 마친 후 빠르게 착수 할 수 있는 시점(ES)은 4일이 되겠다
그리고 4일, 시작 이후 B 활동을 마칠 수 있는 시점(EF)은 7일이 되겠다

이렇듯 '순방향 분석'을 통해 각 활동의 ES, EF를 계산할 수 있는 것이다
참고로 위 표에서 CP는 A->D->E->F->G 이며 프로젝트 총 소요시간은 18일이 된다


* 역방향 분석(Backward Scheduling)
순방향 분석과 반대로, End 시점으로 부터 오른쪽 -> 왼쪽으로 계산하는 방식이다
LF(Late Finish): 늦은 종료라 해석하며 바로 뒤 활동을 제때 시작하기 위해 본 활동이 종료되어야 하는 가장
                      늦은 시점을 말한다
LS(Late Start): 늦은 착수라 해석하며 LF 시점에 활동이 완료되기 위해 시작되어야 하는 시점을 말한다

다음과 같이 활동(Activity)에 대한 기간 및 LF,LS를 표기하도록 한다

아래 그림은 각 활동들을 연결하여 LF와 LS를 계산한 예시이다

End 일인 18일 부터 시작하여 활동이 소요되는 기간을 빼 나가는 방식이다
활동 F의 경우를 보면 G활동을 제때 시작하도록 하기 위해 종료되어야 하는 시점(LF)가 13일이 되겠다
그리고 13일에 활동이 종료되기 위해 이 활동이 시작되어야 하는 시점(LS)은 12일이 되겠다

이렇듯 '역방향 분석'을 통해 각 활동의 LF, LS를 계산할 수 있는 것이다

* 여유 시간
여유 시간은 말 그대로 프로젝트 수행 기간 동안 여유를 부릴 수 있는 시간을 말한다
CP 구간은 여유 시간이 0, 즉 여유가 하나도 없는 구간이라 했다
그러나 CP 구간을 제외한 경로에서는 여유 시간이 나올 수 있다

여유 시간은 다음과 같이 두 가지가 존재한다

1) Total Float (TF)
Slack Time 이라고도 하며, 프로젝트 납기일을 지연시키지 않으면서 각 활동이 가질수 있는 여유시간을 말한다
공식: TF = Min {LS-ES , LF - EF}. 즉 LS-EF 와 LF-EF 값 중 작은 값이 TF가 된다
CP(Critical Path) 구간은 은 TF가 0인 구간이다

TF > 0 경우에는 일정에 여유가 있는 것이며 TF = 0 은 일정 여유가 없는 CP 구간임을 의미한다

2) Free Float (FF)
후행(직후) 활동의 착수일(ES)를 지연시키지 않으면서 선행(직전) 활동이 가잘수 있는 여유시간을 말한다
공식: FF = EF - 직후 ES


TF와 FF는 다음과 같이 표기한다

TF와 FF 의 계산 공식을 도식화 해 보면 다음과 같다

아래 그림은 위에서 계산해 왔던 일정을 토대로 TF와 FF를 계산한 결과이다

지금까지 CPM(핵심경로법)을 통해 프로젝트 전체 일정은 물론이고 각 활동의 시작일/종료일을 산출할 수 있었으며
CP구간을 파악하고 프로젝트 수행 중 여유시간(TF,FF)를 도출하는 방법에 대해 알아 보았다

이렇게 산출된 일정이라 할 지라도, 일정을 단축해야 하는 이슈가 발생할 수 있다
PMI 에서는 프로젝트의 스펙(범위)를 변경하지 않고 프로젝트 일정을 단축하기 위한 방법으로 다음과 같은 기법이
제시된다

* 일정 단축 기법
1) Crashing
크래싱이라 발음하며 자원과 비용을 더 투입하여 일정을 단축시키는 기법이다
Crashing 는 프로젝트 전체 구간 중 CP(Critical Path) 구간에 자원을 먼저 할당하여 프로젝트 전체 일정을 줄이는
기법이다. 단 이 기법은 프로젝트 원가가 상승한다는 단점이 존재한다

2) Fast tracking
순차적으로 진행되는 활동들의 연관관계를 병렬로 작업함으로써 일정을 단축시키는 기법이다
통산 소프트웨어 프로젝트에 많이 사용되는 기법(밤샘?)이며 이는 프로젝트위 리스크가 증가할 수 있으며
재 작업 해야 하는 가능성이 있다는 단점이 있다

이 글은 제가 과거에 운영했던 사이트인 http://mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=473

---

이전 글에서 일정관리를 위한 두 가지 프로세스를 정리 했었다

간략히 요약하자면,
범위관리에서 범위기술서를 분할한 WBS(WBS Package)를 다시 분할하여 활동(Activity)을 정의하고
이렇게 정의된 활동들의 연관관계 및 의존성을 식별하여 Project Schedule Network Diagram을 도출하였다

이 다이어그램의 표기방식으로는 PDM(Precedence Diagramming Method), ADM(Arrow Diagramming Method),
CDM(Conditional Diagramming Method)의 3가지 종류가 있었다. 이 중 많이 사용되는 기법이 PDM이다

이제 이 글에서는 하나의 활동(Activity)를 수행하기 위해 소요되는 기간(일정)을 산출하는 방법에 대해 알아 보자

그에 앞서 어떤 작업을 수행하기 위해 어떤 사람이 몇 명이나 필요할까? 또는 어떤 자원이 투입되어야 하는가?
에 대한 정의를 해야 할 것이다. 이러한 자원에 대해 정의하는 프로세스가 '활동 자원 산정' 이다

활동 자원 산정(Activity Resource Estimating)
각 활동 수행에 필요한 자원의 유형과 양(어떤 자원을 언제, 얼만큼 사용 할 것인지)을 산정한다

이 과정에서는 어떤 자원이 언제 필요하다라고 명시한 '활동 자원 요구사항'을 도출하고 '자원 달력'을 수정,
갱신하게 된다. 자원 달력은 근무일/휴일, 각 일자별 특정 인적/물적 자원의 가용현황을 결정 및 표시하는 수단이다

활동이 정의되고 활동에 필요한 자원이 산정되면 이제 본격적으로 개별 활동에 대한 소요 기간을 산정하게 된다

활동 지속 기간 산정(Activity Duration Estimating)
개별 활동들의 작업기간을 산정한다. 이 과정에서 정량적인 기간 값이 결정된다
기간을 산정, 추정하기 위해 여러 기법이 도입될 수 있는데, 통상 모든 추정의 기법이 되는
전문가 판단, 하향식 추정, 상향식  추정, 유추 추정, 모수 추정 기법이 사용될 수 있다

이러한 추정 기법에 대한 내용은 다음에 차근차근 알아 보도록 하고,
여기서는 일정 관리 분야에서 널리 알려진 PERT에 대해 알아 보자 

* PERT (Program Evaluation Review Technique)
'퍼트'라고 발음한다
3가지 추정치를 이용해 일정을 산정한다고 하여 3점 추정치(Three-point Estimating)라고도 한다
3가지 추정치란 비관치(p),최빈치(m),낙관치(o) 를 말한다

p (Pessimistic) : 비관치, 비관적 추정치, 최악의 일정(일정을 최악으로 길게 잡는다)
m (Most likely) : 최빈치, 가장 가능성이 높은 일정
o (Optimistic)  : 낙관치, 가장 좋은 일정, 가장 짧은 일정

이 세가지 값이 추정되면 다음의 공식으로 Mean(평균) 값과 Sigma(표준편차)를 계산한다
Mean(평균)        = (p + 4m + o) / 6
Sigma(표준편차) = (p - o) / 6

이렇게 계산된 Mean(평균)값으로 활동의 소요기간을 도출할 수 있으며,
이렇게 도출 된 평균과 Sigma(표준편차)를 이용하면 달성 확률을 계산 할 수 있게 된다

Sigma(표준편차)는 평균값으로부터 벗어난 정도를 보여주는데,
다음과 같이 신뢰도를 평가하게 된다. 신뢰도란 정규분포에서 표준편차에 따른 확률값을 말한다
Mean +- 1sigma = 68%
Mean +- 2sigma = 95%
Mean +- 3sigma = 99%


공식만 봐서는 이게 무신 말인고 싶다. 간단한 예를 보도록 하자

문) 어떤 작업의 수행기간을 PERT 기법을 이용해 기간을 산정하고 있다.
이 작업에 대한 3가지 추정치는 다음과 같다
p: 36일
m: 21일
o: 6일
이때 이 작업의 수행기간은?

답) 공식에 대입해 보면,
Mean = (36 + 4*21 + 6) / 6 = 21 , 즉 수행기간은 21일이 되겠다

문) 위 작업이 11일에서 31일 내에 끝마칠 수 있는 확률은 얼마나 되는가?

답) 달성확률을 알기 위해서는 Sigma(표준편차)를 계산해야 한다
Sigma = (36 - 6) / 6 = 5, 표준편차는 5일이 된다

이제 신되로 공식에 의거하여, 평균과 표준편차를 이용해 11일에서 31일 내에 마칠 수 있는 확률을 계산해 보자
Mean : 21일
Sigma: 5일

11일 에서 31일은 Mean += X*sigma 공식에 Mean 값과 Sigma 값을 대입해 보면 
11일 = 21 - X * 5 => X는 2가 된다
31일 = 21 + X * 5 => 역시 X는 2가 된다

결과적으로 Mean +- 2sigma 영역에 있으므로 95% 라는 확률 값을 얻을 수 있다
작업을 즉 11일에서 31일 사이에 달성할 수 있는 확률은 95%가 된다

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=472

---

프로젝트 수행에 있어 아주 중요한 부분이 시간 즉 일정관리 일 것이다

PMI에서도 프로젝트의 3대 제약사항으로 범위,시간(일정),원가(비용)을 꼽고 있다
이 세가지가 만족했을때 프로젝트 결과물에 대한 품질이 보장된다고 하였다

그럼 지금부터 PMI에서 정의한 시간관리의 프로세스를 살펴보도록 하자

활동(Activity) 정의
프로젝트를 착수할 때 '예비프로젝트 범위 기술서'를 정의해야 한다
이 말은 구체적인 프로젝트 스펙을 처음부터 다 정의할 수는 없지만 무슨 일을 해야 한다는 정도의
추상적인 스펙이 나와야 하는데 이를 정의하는 것이 '예비프로젝트 범위 기술서'라 한다

그리고 난 후, 실질적인 프로젝트 범위에 대한 기획단계에서 스펙을 기획,정의하여 범위기술서를 정의하며
이를 더욱 분할,구체화시킨 것이 WBS명세서이다.
또한 WBS를 다시 한번 세세하게 분할한 것이 WBS Package 라 한다

당연하겠지만, 시간관리 즉 일정을 산출할때 가장 중요한 근간이 되는 것이 바로 프로젝트 범위이기 때문에
범위관리에서 산출된 범위기술서,WBS,WBS Package 가 일정산출에 중요 근간 자료가 된다

범위를 구체적으로 정의하고 세부적으로 분할한 WBS(WBS Package)를 더욱 분할하여 '활동(Activity)'을 정의한다
WBS에서 정의된 각각의 세부 범위를 수행하기 위한 활동을 파악하고 정의하는 것이다

지금까지 이야기한 내용을 그림으로 나타내면 다음과 같다

활동 순서 부여
이렇게 하여 활동이 정의되면, 각 활동들 간의 연관관계를 파악해야 한다
이를 '활동순서부여'라 하는데 정의된 활동들간의 관계를 파악하고 각 활동의 순서를 부여하는 것이다

이때 사용되는 기법이 Project Schedule Network Diagram 인데 이는 다음과 같이 나우어 진다
각 활동을 표현하고 활동들간의 연관관계(의존성)을 표현한 다이어그램 표기 기법이라 할 수 있다

1) PDM(선후행 도형법, Precedence Diagramming Method)
각 활동을 노드(node) 위에 표시하고 화살표로 각 활동의 의존관계를 표현한다
노드에 표현된다고 하여  AON(Activity-on-node)라고도 한다
PDM을 이용하면 각 활동들간의 연관관계를 4가지 형태로 표현할 수 있다
- FS(Finish-to-start)
  말그대로, 앞의 작업이 끝나야 뒤 작업을 시작할 수 있는 개념
- FF(Finish-to-finish)
  앞으 작업을 마쳐야 뒤 작업도 마칠 수 있는 개념
- SF(Start-to-finish)
  앞의 작업을 착수해야 뒤 작업을 마칠 수 있는 개념
- SS(Start-to-start)
  앞의 작업을 착수해야 뒤 작업을 시작 할 수 있는 개념

2) ADM(연결선 도형법, Arrow Diagramming Method)
각 활동을 노드가 아닌 화살표(arrow)위에 표현한다
화살표에 표현된다고 하여 AOA(Activity-on-arrow)라고도 한다
ADM으로는 각 활동들의 연관관계 중 FS(Finish-to-start)만 표현 가능하다
기타 연관관계가 필요하면 Dummy Activity(점선)으로 표현할 수 있다

3) CDM(조건부 도형법,Conditional Diagramming Method)
이는 마치 각 활동의 관계를 프로그래밍 처럼 조건에 의해 순환(loop),분기(if)되는 구조를 표현한다


아래 그림은 소프트웨어 프로젝트에서 Project Schedule Network Diagram를 표현한 예시인데,
PDM으로 표현한 것이다.

중요한 것은 Project Schedule Netowrk Diagram 에서는 활동과 활동들간의 연관관계만 표시하지,
소요되는 시간 및 기간정보는 표현하지 않는다는 점이다.

프로젝트의 일정개발은 각 활동을 수행하기 위해 소요되는 자원(리소스)를 산정하고 개별 활동의 기간을 개개별로
산정하여 일을 통합함으로써 완성된다

경우에 따라서는 각 활동들의 연관관계를 보다 세밀하게 정의하기 위해서 선도 및 지연을 정의할 수 있다

Lead(선도)는 FS(Finish-to-start)관계, 즉 앞의 활동이 완료되어야 뒤의 활동을 시작할 수 있는 관계를
조정하여 앞의 활동이 진행 중일때 뒤의 활동을 시작하여 일정을 단축시키는 개념이다

Lag(지연)은 반대로 FS관계에서 앞의 활동이 끝난 후에 일정기간이 지난 뒤 뒤의 활동을 시작하는 개념이다

이 글은  제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=449

---

프로젝트 관리에서,
주어진 일정과 오픈 예정일은 아주 민감한 부분이죠.

'인간사'에서도 약속을 잘 지켜야 하듯이,
프로젝트도 약속을 잘 지켜 적시 완료를 보장해야 기본을 한 것 이겠죠 

PMBOK 의 프로젝트 관리 9대 지식영역 중, '6.1 시간관리'에 대해 정리합니다.
내용이 방대하지만 나름 핵심만 정리해 봅니다

6.0 시간관리 

* 프로세스 매핑표

 * 일정기획(계획)은 ‘4.0통합영역’ 기획 프로세스그룹의 ‘4.3 프로젝트관리계획개발’ 프로세스에 선행됨

* 시간관리 도식화

나에게 자격증은 일종의 도전이자 동기부여의 한 수단 이었다.

그리고 내 직무/전문분야에 대한 정리이자 증명의 수단이기도 했다.

그래서 나는 (운전면허를 제외하고는) IT 분야 자격증만 취득해 왔다. 

그간 취득한 자격증과 인증을 (취득 날짜 순으로) 정리해 보기로 한다.

인터넷 정보검색사 2급

(발행기관) 한국정보통신진흥협회

(취득일) 2001년 ?월 (몇 월 이었는지 기억도 안남)

군대를 제대하고 복학을 하니, 인터넷이란 것이 유행(?) 했더랬다. 당시 수업도 인터넷과 관련된 새로운 과목도 개강을 하여 들었던 기억이 난다.

사실 이 자격증은, (바로 아래에 있는) 전자상거래관리자 자격증을 준비하면서 재미로(?) 시험을 본 자격증이다.

(꽤 넓은 범위를 다루고 있는) 전자상거래관리사 자격증 공부 영역 중 일부에 해당하기도 했었고, 시험 자체가 집에서 컴퓨터로 온라인 시험을 보고, 결과도 그 자리에서 바로 나와서 아주 쉽게 취득한 자격증이다. 물론 그만큼 가치도 별로 없다.

이 자격증은 내 이력서에서도 제외하곤 하지만, 그래도 내 첫 IT 분야 자격증이니 여기에 기록해 본다.

전자상거래관리자 2급

(발행기관) 대한상공회의소

(취득일) 2001년 7월

대학 졸업반 시절, IT 관련 일을 준비하면서 취득하게 된 자격증이다.
당시 이 자격증의 광고와 홍보가 많이 이루어졌고, 뭔가 그럴싸해 보였다.(돌이켜 보니 광고에 혹했고 내가 순진했다.)

당시 정보처리기사급 정도 되었던 것 같다. (당시 지인이 옆에서 정보처리기사를 공부했더랬다)

1차 필기/2차 실기 시험 이었는데, 1차 필기는 다루는 범위가 꽤나 방대했었고
2차 필기는 직접 컴퓨터를 가지고 각종 작업(IIS 웹서버 셋팅/ASP 등)을 해야 해서 나름 공부 많이 하고 취득한 자격증이다.

OCP(Oracle Certified Professional) 9i

(발행기관) Oracle

(취득일) 2004년 3월

오라클이라는 외국의 유명한 DBMS 회사에서 주최하는 자격 시험이다.

실무에서 DB를 다루기도 하고, 뭔가 있어 보이기도 하고, 학원에 자격반 커리큘럼도 있고 해서 준비하게 되었다.

필기 시험으로만 취득하는 페이퍼 자격증이라는 오명을 벗기 위해, 9i 버전 부터는 일정 시간 이상 실무 교육을 필수로 요구했었다.

그래서 꽤 비싼 수강료를 지불하고 실무 강의도 수강했었다. 매일 저녁 멀리 있는 학원에 가는게 매우 귀찮았던 걸로 기억한다.

MCAD (Microsoft Certified Application Developer)

(발행기관) Microsoft

(취득일) 2005년 1월

부산의 동명정보기술원이라는 기관에서 같이 공부하던 여러 사람들과 같이 준비하고 취득한 자격증이다.

마이크로소프트에서 주최하는 국제 자격증으로 MS 기반 개발자를 위한 자격 인증 시험이다.

당시에는 MCAD, MCSD, MCT 로 이어지는 도전을 생각했으나, 이 자격증 까지만으로 만족(?)해 버렸다.

MS MVP(Microsoft Most Valuable Professional), C# 부문

(발행기관) Microsoft

(취득일) 2008년 7월

이건 자격증이 아니라 인증 프로그램이다. 마이크로소프트에서 자사의 각 기술 분야에 대한 전문가를 인증하는 프로그램으로 별도의 자격 시험을 치루는 게 아니라, 전문가 활동을 한 내역 증명과 심사 통과가 필요하다.

전문가 활동이란, 해당 기술 분야에 대한 책을 쓰기나 강의를 하거나 기술 블로그 등에 글을 작성 하거나 Q&A에 답변을 하는 등 그 활동으로 인해 '해당 기술을 널리(?) 알리고 타인을 (기술적으로) 도와 주었는가?'를 심사한다.

자신의 전문가 활동 내역을 정리해서 영문으로 (제공되는) 포맷에 맞게 제출하면 심사가 이뤄지는데,
'한국 -> 아시아 -> MS 본사' 순으로 심사가 진행되는 것으로 기억한다.

MS 제품과 관련한 다양한 분야의 MVP를 선발하는데, 나는 당시 실무에 주력 언어로 사용하던 C# 부분에 지원 했었다

처음 시도 했을 때, 한번 미끄러지고 두 번째 시도에 통과했었다.

당시 MS MVP는 공신력도 있었고, MS 계열 엔지니어들에게서 꽤 선망의 대상이어서 심사에 통과하고 많이 뿌듯했었다.

PMP(Project Management Professional)

(발행기관) PMI

(취득일) 2009년 6월

2008년부터 팀장 직무를 수행하게 되었는데, 이 때 프로젝트 관리에 관심을 가지게 되었고 이왕 하는거 제대로 해 보자는 마음으로 준비하게 된 자격증이다.

국제적 프로젝트 관리 기관인 PMI(Project Management Institute)에서 프로젝트 관리 전문가에게 부여하는 자격증이다.

이 자격증을 위해 라이지움이라는 학원도 다녔었다. 공부할 내용이 방대하고 복잡한 계산 문제도 있어서 정성을 꽤나 쏟았다.

시험 보는 날이 아직 머리속에 생생하다. 시험은 정해진 시험 장소에 가서 컴퓨터로 치룬다. 시험 결과는 시험 종료 후 최종 제출을 하면 몇 분 기다리다가 바로 나온다. 그 몇 분의 떨림이란...

첫번 째로 응시한 시험에 (운 좋게) 합격하여, 기분 좋게 복귀 했던게 생각난다.

기술사(정보관리)

(발행기관) 한국산업인력공단

(취득일) 2016년 5월

이건 매우 비장한 각오로 준비한 자격증이다. 혹독한 준비 과정을 각오했으며 주말도 반납하며 공부 했었다.

1차 논술 시험과 2차 면접 시험으로 구성되어 있다.

1차 시험은 1교시 90분씩 총 4교시 시험을 치르게 되는데, 시험 시간만 자그마치 6시간이다.
이 6시간을 혼신의 힘을 다해 논술해 나가야 한다. 오전 9시에 시작해 오후 6시 조금 전에 시험을 마치는데 시험을 치고 나면 녹초가 되는 기분이었다.

2차 시험은 대학교수/기술사로 구성된 3명의 면접관 앞에서 (외로이?) 질문에 성실히 답해야 한다. 기술적인 답변을 잘 하는 것이 제일 중요하나, 구술시험이다 보니 임기응변과 순발력과 재치도 필요하다.

이 자격증은 1차 시험 합격이 중요한 시험이다. 2차에 비해 1차의 합격률이 매우 낮으며 2차 시험은 1차 합격 이후 4번 정도의 기회가 부여 되기 때문에, 1차 합격하면 기술사가 된 것으로 인정하는 분위기이다. (물론 2차에 고배를 여러차례 마신 분들도 있긴 하다)

나의 경우, 1차 시험 합격 기준으로 총 1년 6개월 정도 걸렸으며 (6개월 마다 있는 시험 일정에) 총 3번의 시험을 치뤘다.

첫번째 시험은 공부 시작한지 얼마 안되서, (기대도 없이) 경험삼아 보게 되었고, 두 번째 시험은 작심하고 봤다.

두 번째 시험에서 살짝 아깝게 떨어지고, 세 번째 시험에 (운좋게) 합격하게 되었다. 면접도 한번에 붙어서 매우 기뻤다.

매우 힘든 과정과 시험이었지만, 뭔가를 (오랜 기간) 제대로 준비하고 모든 것을 쏟아 부어 성취한 느낌을 주게 한 소중한 자격증이다.

2017/12/22 - [자격증] - [기술사] 철지난 합격수기

2016/10/09 - [자격증] - KPC 공개설명회

정보시스템 수석감리원

(발행기관) 정보시스템감리협회

(취득일) 2016년 7월

기술사 자격을 취득하면 (별도의 시험이나 감리 경험 없이) 5일간의 감리교육만 이수하면 수석감리원 자격이 부여된다. 기술자 자격의 혜택 중 하나이다.

실제 감리를 수행하는 과정이 교육 커리큘럼이라 5일간 꽤 낯설고 힘들었던 기억이 난다.

교육 마지막날 소정(?)의 필기 시험이 있는데 교육을 충실히 듣고, 공부 조금 했다면 그리 어렵지 않게 통과할 수 있다. 물론 그 전에 기술사 공부로 어느정도 감이 있어서 도움이 되었다.

데이터 품질인증(DQC-V) 심사원

(발행기관) 한국데이터진흥원

(취득일) 2016년 8월

한국데이터진흥원에서 주최하는 데이터 관련 3종 인증 심사원 중 데이터 품질에 관한 심사원 자격이다.

3일간(2일인가? 기억이 가물)의 교육, 주말 시험으로 취득할 수 있다.

교육은 참신하고 재미있었는데... 이 시험이.. 만만하게 볼 게 아니다.

아무래도 실무 현장에 가서 의뢰 기관의 데이터 품질을 객관적으로 측정하는 일을 해야 되다 보니, 시험에 신경을 꽤 쓴 느낌이었다.

중요한 것은, 다른 심사원 자격보다 보수가 짭짤한 것이 장점이다ㅏ.

2016/09/29 - [자격증] - 데이터 품질(DQC-V) 인증심사원

ISMS-P (정보보호 및 개인정보보호 관리체계 인증)

(발행기관) KISA

(취득일) ISMS: 2016년 10월 / ISMS-P: 2019년 5월

기업(기관)의 정보보호관리체계/개인정보보호관리체계를 점검하고 심사하는 인증 심사원을 양성하기 위한 자격 시험이다.

2016년에 필기 시험 치고, 5일간 실무 교육 받고 ISMS 심사원 자격을 취득했다.

이후 ISMS와 PIMS가 ISMS-P로 통합 되면서 이틀간 전환 교육 받고 필기시험 한번 떨어지고,
재시험에 통과하여 최종적으로 ISMS-P 심사원 자격을 취득했다. 

필기 시험이 쉽지 않다.

과거에는 교육만 받으면 자격이 나왔다고 하는데, 심사원의 전문성과 자질 문제가 불거지면서 필기 시험이 도입되었다.
그 필기가 도입되고 얼마 안되 2016년에 내가 시험을 보게 된 것이다.

문제 수도 많고, 각 문제 지문도 길고, 다지 선다(압권은 모두 고르시오)에.. 

2016년 당시 시험 시간이 턱없이 부족했었던 기억이 난다. 정말 꾸역꾸역 시험을 쳤는데 진짜 운 좋게 합격한 것 같다.

2019년에 ISMS-P 시험은 2016년 당시 시험 보다는 여유롭게 봤지만 쉽지는 않았다.

2016/10/29 - [자격증] - ISMS 인증심사원 자격취득

소프트웨어 보안약점 진단원

(발행기관) KISA

(취득일) 2017년 11월

말 그대로 소프트웨어의 보안 약점을 진단하는 심사원 양성을 위한 자격증이다.

5일간의 교육과 마지막날 필기 시험을 치러야 한다.

필기 시험이 꽤 어렵다.

(ISMS-P도 그렇고) KISA는 시험 난해하게 내기로 작정한 모양이다. ㅋ

물론 심사원 취득 과정이 험난(?)해야 제대로 된 심사를 하니깐 난해함을 존중하는 바이다.

이상..

그간 취득한 자격증을 정리해 봤다.

치열했던 나의 도전에 박수를 보낸다 !!!