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

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다. 원본 글은 2008년 5월에 작성되었습니다.

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

『 배열 인덱싱의 메커니즘 』

 배열은 다수개의 요소를 가진다.
특정 요소에 접근하기 위해서는 Sequence 한 인덱싱을 사용한다.

예를 들어, int arr[] = {1,2,3} 으로 정의된 배열의 요소에 접근하기 위해서 arr[0] , arr[1], arr[2] 로 접근할 수 있다.

앞서 우리는 배열 변수는 결국 배열의 첫 번째 요소를 포인팅 하고 있는 포인터라고 배웠다.
이전 그림을 다시 보자.

이전 아티클 보기 -> 배열과 포인터의 상관관계

 그렇다면 arr[2] 와 같은 인덱싱은 어떤 처리과정을 통해 3번째 메모리 값을 가져올 수 있는 것일까?

 가장 먼저 알아야 할 중요한 내용이 있다. 

“배열은 연속된 메모리 공간에 순차적으로 저장된다”

위의 예에서 제시된 int 형 배열 arr 은 0x20 번지부터 4byte 씩 증가하는 연속된 메모리 공간에 값이 저장되는
것이다

즉, 아래 그림과 같이 저장된다.

그 다음으로 알아야 할 중요한 내용이다.

“배열은 포인터이다. 배열을 인덱싱은 포인터 연산으로 이루어 진다.”

일단, 배열을 알아보기 이전에 포인터 연산 중 포인터의 주소를 이동 시키는 예제를 살펴 보자.

포인터 변수 p 에 1을 더한다.

이 의미는 주소 값인 p 에 1을 더한다는 의미로,
메모리 주소를 한 블럭 증가시키게 된다. 이때 p는 int 형이기 때문에 1 증가는 4byte 단위(블럭)의 증가를 의미한

포인터가 가지는 값은 자신이 포인팅 하고 있는 대상 메모리의 주소 값을 가지고 있다.
따라서 이 포인터의 값을 변경한다는 것은 대상 메모리 주소를 변경한다는 것과 같은 의미이다.

주의해야 할 것은 포인터 값을 증가 시킬 경우에는 포인터의 타입에 따라 자동으로 크기만큼 곱해 진다는 것
을 알아야 한다

이 경우 p 는 int 형 포인터이기 때문에 p + 1 = p + 1 * 4 가 된다. 즉 내부적으로 4(byte) 가 곱해 지는 것이다.

당연하겠지만 4byte 길이 int 형 메모리 공간을 한 칸 이동 한다는 것은 4byte 만큼 이동한다는 것이기 때문이다.
(만일 자동으로 곱해지는 데이터 길이가 헷갈린다면 간편한 이해를 위해서는 그냥 메모리 한 칸 이동한다고 생각하자)

자. 이제 위의 샘플을 실행한 결과를 보자.

포인터의 값이 4 만큼 증가된 것을 보여준다
결론적으로 포인터가 포인팅하는 주소 값이 변경된 것이다.

p 의 변경 전,변경 후 의 실제 포인팅 대상의 값을 보자.

포인팅 주소를 변경하기 전에는 int i =1 이었던 놈을 여전히 포인팅 하고 있고 변경 후에는 이상한 값이 나왔다.

이제 배열로 말해 보자.
다시 말하지만, 배열은 포인터 이며 위와 같은 포인터 연산으로 배열 각 요소를 인덱싱 하는 것이 가능하다

int arr[] = {1,2,3}  라고 정의된 배열이 있으며 이의 메모리 구조는 아래와 같다고 했다.

배열 변수인 arr 은 배열의 첫 번째 요소를 포인팅 하는 (상수) 포인터이다.

arr[1] 를 풀이해 보면,
arr 의 값을 1 증가시키고 그 값이 포인팅 하는 대상 메모리의 값을 가져온다.

1. arr 값 1 증가 (int 형 배열일 경우)

arr + 1 = arr + 1 * (4byte) 

사실 * 4byte는 생략해도 무방하다
arr 타입에 따라 메모리 블럭 증가는 해당 타입의 메모리 블럭만큼 되는 것은 당연하기 때문이다

2. arr 의 포인팅 하고 있는 대상 메모리 값 참조

*(arr + 1)

결국 arr[1] = *(arr + 1)  이다.

( *(p + 1) 의 식은 p[1] 과 동일하다)

 위의 예에서는 arr 을 한 칸 이동하면 0x24가 되고 이 메모리 주소의 값은 2가 되는 것이다.

지금까지의 내용을 그림으로 담아 보았다.

너무 장황하게 설명했지만, 배열의 인덱싱 메커니즘을 한마디로 한 마디로 요약하자면 다음과 같이 할 수 있겠다

“연속된 메모리 공간을 포인터 연산으로 찾아가는 일련의 과정” 

배열과 포인터에 관한 중요한 아래의 연산식을 기억하자
arr[i] == *(arr+i)

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다. 원본 글은 2008년 5월일에 작성되었습니다.

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

『 배열과 포인터(Pointer) 의 상관관계 』 

배열은 포인터이다

대부분의 프로그래밍 언어에서는 배열이라는 복합 값을 다룰 수 있는 자료구조를 제공한다.
배열과 포인터는 내부적인 처리 방식이 거의 동일하다. 단 배열변수는 ‘상수 포인터’ 이다

일단 포인터의 내부 구조를 살펴 보자.
아래 샘플 코드는 int 형 변수를 가리키는 포인터를 생성해서 포인터를 통해서 i 의 값을 변경하는 예제이다.

 시스템은 내부적으로 변수를 메모리에 저장하고 참조하기 위한 key-value 와 유사한 형태의 Symbol Table 라는 것을 관리한다. 이 Symbol Table 에는 변수명과 값이 저장된 메모리 주소 그리고 타입정보를 저장한다.

이것은 포인터도 마찬가지이다.

단, Symbol Table 에서 포인터는 자신의 타입정보 뿐만 아니라 포인팅하고 있는 대상의 타입정보도 같이 저장한다.

편의상 Symbol Table 가 다음과 같이 구성된다고 가정하자.

위의 예제를 Symbol Table 과 메모리 구조로 표현하면 다음과 같다.

int 형 변수 i 에 1을 저장했으므로 4byte 메모리 공간에 1을 저장하고 그 주소 값인 0x10 번지를 가리킨다.

그리고 i 의 주소 값을 포인팅 하는 포인터 변수 p 는 역시나 4byte 메모리 공간에 i 의 주소값인 0x10 을 저장하고
있는 0x100 번지를 가리킨다

즉 포인터 변수가 가리키는 메로리 공간에는  i 의 메모리 주소가 저장되어 있는 것이다(32 bit 시스템에서 메모리 주소 값은 4byte 로 표현되므로 포인터 p 는 4byte 의 메모리 공간을 차지하게
되는 것이다)

 
자.. 그럼 이제 배열을 알아 보자. 다음과 같이 선언된 배열이 있다고 가정하자.

 이 배열을 Symbol Table 과 메모리 구조로 표현하면 다음과 같다.

배열 변수인 arr 은 배열의 첫 번째 요소(arr[0]) 를 포인팅 하는 별도의 상수형 메모리 공간인 것이다.

즉 arr 은 0x200 을 가리키고 여기에는 배열의 첫 번째 요소(arr[0]) 의 메모리 주소를 포인팅
하고 있는 것이다. 이 구조는 포인터와 완전히 동일한 구조이다.

실제로 이 배열을 정수형 포인터에 대입하면 포인터를 배열처럼 사용할 수 있다.

단, int *p = arr 은 가능하지만 arr = p 는 성립하지 않는다.
앞서 말했듯이 arr은 상수이기 때문이다. 상수를 변경할 수는 없는 것이다.

 또 하나, 일반적인 포인터에서 *p = 10 하면 p 가 포인팅 하고 있는 곳이 변경된다.

그렇다면 위의 배열 변수를 가지고 *arr = 10 하면 어떻게 되겠는가?
arr 은 배열의 첫 번째 요소를 포인팅하는 포인터이기 때문에 위의 식은 배열의 첫 번째 요소의 값을 변경하게 된다.

이로써 배열은 포인터 이다 라는 명제를 풀어 보았다.

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다. 원본 글은 2008년 5월에 작성되었습니다.

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

상수란 변수와는 달리 값을 변경할 수 없는 데이터를 의미한다.
 
즉 아래와 같은 코드에서
int i = 10
 
 i   : 정수형 변수
10 :  상수
 
라고 한다.
 
i 의 현재 값은 10으로 할당되었지만 프로그램 수행 과정중에 다른 정수값으로 변경이 가능하므로 i 를 (정수형) 변수라 한다.
반면, 10 은 값을 변경할 수 없기 때문에 상수인 것이다.
 
그렇다면 위의 코드의 실행 순서를 살펴보자.
대입연산자의 실행 우선순위는 우측의 결과가 먼저 실행되고 좌측으로 값이 복사된다(이 과정을 값이 변수로 assign 된다고 한다)
즉 10 이라는 것이 먼저 실행되고 i 에 10이 복사된다는 것이다.
 
그럼 우측이 실행된다는 의미는 무엇일까?
연산자의 우측에는 10이라는 숫자가 있을 뿐이다.
 
이 말은 10 이 먼저 메모리에 올라간다는 뜻이다.
컴퓨터의 CPU 는 메모리에 존재하는 데이터들만 연산할 수 있다.
(우리가 작성하는 응용프로그램 역시 실행시에는 메모리에 로드 된다는 것을 알고 있다)
따라서 10 이라는 숫자가 내부적으로 먼저 메모리에 로드되고 난 후 i 라는 변수에 복사가 되는 것이다.
 
이렇게 특정 메모리에 10 이라는 정수값이 할당이 되었지만 이 메모리 공간의 이름은 부여되지 않았다.
즉, 메모리할당이 되어 상수가 저장되었으나 그 공간에 이름이 없는 상수를 리터럴(literal) 상수라고 한다.

그림에서 보면 위의 10이라는 메모리 공간은 i 라고 이름이 부여되었다. 그러나 아래쪽의 메모리 공간은 10이라는
값을 저장하고는 있지만 이 공간에 대한 이름은 부여되지 않았다.  단지 숫자 10 이 메모리에 저장된것 뿐이다. 
이렇듯 이름이 없는 상수를 가리켜 리터럴(literal) 상수라 한다.

이와 반대로 이름이 부여된 상수는 심볼릭(Symbolic) 상수라 한다.
아래의 코드를 보자
const int i = 10;
 
const 라는 키워드를 사용하여 상수를 정의하고 있다.
이것은 상수이지만 이름이 있으므로 심볼릭(Symbolic) 상수라 한다.

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다. 원본 글은 2008년 5월에 작성되었습니다.

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

ASCII 정의
미국 정보 교환 표준 부호(American Standard Code for Information Interchange) 의 약자인 ASCII 는 영문 알파벳을 사용하는 대표적인 문자 인코딩(Encoding) 이다.

컴퓨터는 0과 1 로 구성된 진수밖에 인식하지 못한다.
이 말은 곧 컴퓨터는 숫자밖에 인식하지 못한다는 의미인 것이다.

그렇다면 컴퓨터에게 문자를 인식하도록 할려면???

그렇다. 숫자밖에 인식하지 못하는 컴퓨터에게 인간의 언어인 문자를 인식하도록 하려면 여전히 숫자를 사용할 수 밖에 없다.

그렇다면 숫자를 이용해서 문자를 표현하는 규칙이 있어야 한다.
즉 숫자  N 은 문자 X 와 일디일 매핑(mapping) 시키는 개념을 규칙화 시켜야 한다.
이러한 매핑 규칙을 정의해 놓은 것이 바로 ASCII 코드표 이다.

 아래와 같은 코드를 보자

char c = ‘A’

내부적으로 c 에는 65 라는 정수가 저장된다.

ASCII 구성
총 128 개 (7비트로 표현 가능한 범위 , 2의 7승 = 128) 로 구성

33 개 : 출력 불가능한 제어 문자들
95 개 : 출력 가능한 문자(공백 포함)
           52개 : 영문 알파벳 대소문자, 10개의 숫자, 32개의 특수문자, 1개의 공백문자

출력 가능한 95개 문자 (32 번 ~ 126 번)

ASCII 코드표

 인쇄 불 가능한 제어 문자 
33개에 해당하는 인쇄 불가능 아스키 문자는 프린터와 같은 일부 제어 주변장치를 제어하는데 사용되는 제어 문자이다.

확장 ASCII 인쇄 문자

위의 7 Bit 로는 128개의 문자만을 표현할 수 있다.

더 많은 문자의 표현을 위해 확장 ASCII 라는 것이 있는데 이것은 비트(bit) 를 하나 더 늘려 총 8 Bit 로 표현하게 되어 총 259 개를 표현할 수 있다.

즉 128 ~ 255 까지 문자를 추가적으로 표현할 수 있다
(확장 문자 집합은 ASCII 문자 집합과 128개의 그래픽과 선 그리기용 문자를 포함하며 종종 "IBM 문자 집합"이라고도 합니다)

이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다. 원본 글은 2008년 5월에 작성되었습니다.

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

정보의 최소 단위는 비트(bit)입니다.
보통 프로그램을 작성할때 int,long 등 바이트(byte) 단위롤 연산하도록 프로그램을 작성합니다.
 
그러나 비트 단위로 연산을 하게 되면 메모리 공간을 줄이고 성능을 향상 시킬 수 있습니다.
주로 하드웨어 프로그래밍에서 자주 사용되는 연산이라 할 수 있습니다.

그러나 의지만 있으면 우리가 작성하는 일반적인(?) 프로그램도 비트 단위 연산을 하면 성능에 아주 좋은 영향을
줍니다. 지금부터 비트 단위로 연산을 하는 방법을 알아 봅니다.
 
비트 단위 연산에는 아래와 같은 연산자가 있습니다.
&   : 비트 단위 AND
|    : 비트 단위 OR
^   : 비트 단위 XOR
~   : 비트 단위 NOT
<< : 왼쪽으로 이동
>> : 오른쪽으로 이동
 
주의 할 점은 비트 단위 연산에서의 피 연산자, 즉 연산의 대상은 반드시 정수이어야 합니다.
실수의 비트 연산은 불가능 합니다.
 
& (비트 단위 AND) 연산자
두 비트의 값이 모두 1일때 1을 반환합니다.
 0 & 0 = 0
 0 & 1 = 0
 1 & 0 = 0
 1 & 1 = 1
 
 ex> 15 & 20 연산은 아래와 같이 수행 됩니다.
        00001111
    &  00010100
    -----------------
        00000100 = 4 가 됩니다.
 
| (비트 단위 OR) 연산자
두 비트 중 하나만 1이면 1을 반환합니다.
 0 | 0 = 0
 0 | 1 = 1
 1 | 0 = 1
 1 | 1 = 1  
 
ex> 15 | 20 연산은 아래와 같이 수행 됩니다.
        00001111
    |   00010100
    -----------------
        00011111 = 31 가 됩니다.
 
^ (비트 단위 XOR) 연산자
두 비트가 서로 다를 경우 1을 반환 합니다.
 0 ^ 0 = 0
 0 ^ 1 = 1
 1 ^ 0 = 1
 1 ^ 1 = 0
 
ex> 15 ^ 20 연산은 아래와 같이 수행 됩니다.
        00001111
    ^ 00010100
    -----------------
        00011011 = 27가 됩니다.
 
~ (비트 단위 NOT) 연산자
비트를 반전 시킵니다(비트 값의 보수)
 ~ 0 = 1
 ~ 1 = 0
 
ex > ~15 연산은 아래와 같이 수행 됩니다.
      NOT  00000000 00000000 00000000 00001111
-------------------------------------------------------------------
               11111111 11111111 11111111 11110000 가 됩니다.
               부호 비트 까지 반전이 되었으므로 음의 정수 값이 됩니다. (15의 1의 보수가 됩니다)
               그리고 1을 더하면(결국 15의 2의 보수) -15가 됩니다 
 
<< 왼쪽 쉬프트 (비트 단위 이동) 연산자
    a << b => a의 비트들을 b만큼 왼쪽으로 이동합니다.
 
ex> 15 << 2 연산은 아래와 같이 수행 됩니다.
       00000000 00000000 00000000 00001111 을 왼쪽으로 2칸씩 이동 시킵니다.
   00000000 00000000 00000000 00001111      데이터 범위를 넘어서 이동한 비트들은 버려집니다(빨간색 부분)
       00000000 00000000 00000000 00111100  이동한 만큼 비어 있는 오른쪽 비트는 0으로 채우게 됩니다(빨간색 부분)
       따라서 결과는 60 이 됩니다.
 
   주의 할 점은 맨 앞의 부호 비트 까지 이동하므로 데이터의 부호가 바뀔수 있습니다(양/음이 바뀐다)
 
>> 오른쪽 쉬프트 (비트 단위 이동) 연산자
    a << b => a의 비트들을 b만큼 오른쪽으로 이동합니다.
 
ex>
위의 식에서 a가 양수이면(부호 비트 0) 위의 왼쪽 쉬프트 연산과 완전 동일합니다. 오른쪽으로 넘어간 비트들은 여전히 버려질 것이며 이동한 만큼 비어 있는 왼쪽 비트는 0으로 채우게 될 것입니다. 
그러나 a가 음수라면 예기는 좀 달라 집니다.
      
       -10 >> 2 연산은 아래와 같이 수행 됩니다. (2바이트로 표현한다고 가정 합니다)
       11111111 11110110 (-10의 2진수 표현) 을 오른쪽으로 2칸씩 이동 시킵니다
           11111111 11110110  데이터 범위를 넘어서 이동한 비트들은 버려집니다(빨간색 부분)
       ??111111 11111101      이동한 만큼 비어 있는 왼쪽 비트는 0 또는 1로 채워 집니다.
 
       시스템에 따라 ?? 부분이 0으로 채워질 수도 1로 채워질 수도 있습니다.
       음수를 유지하기 위해 1로 채우기도 하고, 양수의 비트 연산처럼 0으로 채우기도 합니다.
       해당하는 시스템을 확인 할 필요가 있습니다. 

 
Tip>>
<< (왼쪽 쉬프트) 연산을 사용하면 주어진 값의 배수를 쉽게(빠르게) 구할 수 있다.
    << 연산자를 이용하여 1칸씩 왼쪽으로 이동하면 계속해서 값의 2배가 된다.
    ex> 15 << 1 = 30 , 15 << 2 = 60 .....
 
   같은 의미로 >> (오른쪽 쉬프트) 연산을 사용하면 주어진 값을 2로 나눈 결과가 나온다.
   >> 연산자를 이용하여 1칸씩 오른쪽으로이동하면 계속해서 값을 2로 나눈 결과가 나온다
   단, 나눈 결과가 실수 이면 소수점 부분은 제외(절사) 된다.
   ex> 30 >> 1 = 15 , 30 >> 2 = 7 , 30 >> 3 = 3 
 
정수값의 부호를 바꾸고 싶으면 2의 보수를 사용하면 된다.
    즉, 이 말은 정수값의 ~(NOT) : 1의 보수 값을 구해서 1을 더하면 2의 보수가 되는 원리를 이용하면 된다.
    ex> (~-100) + 1 = 100 

나의 경우, 지금까지 살면서 총 3번의 금연시도가 있었다.

첫 번째는 20대 초반 대학생일 때, 9일간 금연을 했었다.
담배를 피운지 몇 년 되지 않은 시기이기도 했고 딱히 금연에 대한 동기가 그리 크지 않았던 탓인지 얼마 지속되지 못했었다.

두 번째는 40대에 3개월간 금연을 했었다.
하루 하루 날짜를 세어 가며, 금연 앱도 깔면서 동기부여 해 가며 3개월을 버텼다.
담배를 피운지 꽤 오랜 시간이 지나서인지, 금연 후 바로 나오는 증상은 가슴이 텅 빈 듯한 느낌이었다.
텅빈 가슴이 속이 간지럽다는 느낌마저 들어서 커피와 술로 달래 주곤 했었다.

그렇게 3개월을 버텨 오다가 기분이 심히 좋지 않던 어느 날,
'1대만 피고 다시 안피면 되지 '라고 스스로 정당화 하면서 1대를 폈다. 
3개월을 안 했으니 아마 머리가 띵~ 할 것이야.. 하는 생각과는 달리 너무나도 자연스러웠다.

그 1대가 심리적 장벽을 무너뜨려서인지, 2대가 되고 10대가 되고.. 그렇게 무너졌었다.

세 번째, 즉 마지막 금연 시도는 작년 8월, 근속휴가로 10일간 쉬면서 시작되었다.
그리고 지금까지 이어져 오고 있다.

이제는 금연앱도 깔지 않고, 하루하루 날을 세어 보지도 않는다. 그냥 안피운다.
아직 주위에선 1년 정도 밖에 안지났으니, 아직 확신할 수 없다고는 하지만 난 이대로 쭉 이어갈것 같은 느낌이다.

그런데 금연 초반에는 역시 참기가 쉽지 않았었다. 특히 밥을 먹거나 기름진 음식을 먹거나 할 때와 기분이 아주 좋거나 반대로 아주 안좋거나 할 때 담배 생각이 많이 났었다.

그럴때 마다 내가 자주 쓰던 방법이 하나 있었다.
이 방법은, 그야 말로 흡연의 욕구를 즉시 사라지게 만드는 은총알(Silver Bullet) 같은 것이라 감히 말할 수 있다.

그것은 바로 '계단 오르기' 이다.

금연 초기 몇 달간 내가 아주 효과적으로 흡연의 욕구를 떨쳐 버린 방법이 바로 계단오르기 였다.

일하던 중에 담배 생각이 날 때 마다, 즉시 1층으로 내려가 사무실까지 계단을 올랐다.
계단을 오르면 숨이 턱 밑 까지 차 오른다. 숨이 차면 담배 생각이 전혀 나지 않는다. 담배 근처도 가기 싫어 진다.

흡연의 욕구를 떨쳐 버리는 가장 강력한 방법은 숨을 차게 만드는 것이다.
계단 오르기도 좋고, 달리기도 좋고 다 좋다. 다만 숨이 좀 많이 차야 한다.
어슬프게 헬스 조금 하고 나서의 약간의 숨찬 상태는 오히려 담배 생각이 더 나게 만든다.
운동을 했다는 일종의 성취감이 흡연 욕구를 불러 일으킨다.

난 금연 초기에는 하루에도 몇 차례 계단 오르기를 했었다. 건강이 좋아 지는 것은 덤이다. 

지금은 담배 생각이 간절하지 않아서 계단 오르기를 더 이상 (금연의 목적으로는) 하고 있지는 않지만 내 금연의 좋은 보조제 역할을 톡톡히 한 것이 계단 오르기였다.

이 글을 금연 중에 보시는 분은, 지금 당장 계단을 올라 보기 바란다. 그것도 숨치 많이 찰 때 까지.
담배 생각이 싹 ~ 사라질 것이다 !

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

---

전문가 책임

‘프로젝트관리전문가’ 인증 프로그램인 PMP(Project Management Professional)는

PMI(Project Management Institute)라는 국제 협회에서 관리하는 인증, 자격 제도이다.

PMI는 전 세계적으로 프로젝트 관리에 관한 전문 지식을 보급하고 전문가를 양성하기 위해 PMP라는 자격제도를
운영하고 있으며 더불어 업무적, 기술적인 평가를 비롯하여 프로젝트관리전문가로써의 직무상 책임과 합법적, 윤리적 그리고 전문가다운 행동 양식에 대해서도 연구, 정의하고 이를 PMP 학습과정에 포함시켰다.

* PM의 직업 의무

1. 전문성의 지속적인 향상

공인 프로젝트 관리자로서 전문성 향상과 개인 역량 강화에 지속적인 노력을 기울여야 한다

이를 위해 다음과 같은 행동 양식이 요구된다

- 자신의 강점과 약점을 파악한다

- 자신의 전문성 향상을 위한 개발 계획을 수립한다

- 회사 또는 프로젝트에 도움이 될 새로운 정보와 사례를 수집한다

- 현업 관련 전문 지식을 지속적으로 배운다

2. 완전성과 전문성 준수

공인 프로젝트 관리자로서 완전성(integrity)과 전문성(professionalism)을 준수하고 이해당사자들과 관련조직을
보호해야 한다. 이를 위해 다음과 같은 행동 양식이 요구된다

- 보고서, 대화 등의 의사소통 시에는 진실(truth)을 말한다

- 법률준수 및 지적 재산권을 보호하고 위반사항을 발견하면 반드시 이를 알린다

- 기업 정보를 외부에 유출하지 않는다

- 프로젝트 관리 시 개인의 이익을 부가하지 않으며 뇌물을 주고 받지 않는다

- 이해관계의 충돌을 파악하고 발생할 경우 이를 적극적으로 처리한다

- 모든 사람을 존중하고 옳은 일과 정확한 프로세스를 따른다

3. 이해당사자 간의 갈등 해소

공인 프로젝트 관리자로서 이해당사자들의 충돌되는 요구 및 목적을 만족시키기 위해 해결 방안을 제시하고
이해관계의 균형을 유지 시킨다. 이를 위해 다음과 같은 행동 양식이 요구된다

- 이해당사자들의 요구 및 목적을 명확히 규정하고 이해한다

- 충돌되는 요구 및 목적을 적극적으로 찾아 공정한 해결 방안을 찾는다

- Crashing, Fast Tracking, Brainstorming, 재산정 등의 기법과 갈등해소, 의사소통, 협상, 정보배포,

 팀 빌딩 및 문제해결 기법을 활용하여 해결하며 회의, 인터뷰 및 토론을 진행한다

- 해결할 수 없는 갈등은 경영층을 개입시킨다

- 프로젝트 헌장과 관련된 변경은 경영진의 승인을 요청한다

4. 문화적 차이의 이해

프로젝트는 다양한 환경 및 다양한 사람들이 모여서 수행하게 되는 경우가 많다

지역이 다르거나 나라가 다를 경우 발생할 수 있는 문화적 차이와 배경을 이해하고 있어야 한다

- 문화적 차이에 대한 다양성을 받아 들이다

- 문화적 차이를 사전에 학습하여 문화적 충격을 방지한다

- 법률을 위반하지 않을 경우에는 다른 나라의 관례를 따른다

5. 프로젝트 관리 지식 공유

프로젝트를 수행하여 얻게 된 지식과 경험을 공유하여 조직과 팀의 전문성을 향상시킬 수 있도록 해야 한다.

- 다른 프로젝트 관리자와 Lesson learned를 공유한다

- 필요한 사람들에게 교육을 실시하고 코치 및 멘토링을 제공한다

- 프로젝트 성공 사례를 발굴하고 연구 하여 이를 공유한다

* PMI 직무 윤리 규정

국제 프로젝트 관리 협회인 PMI 에서는 프로젝트 관리자의 직무 윤리 규정을 정의하고 있다

이 규정은 PMP 취득자는 물론 PMI 회원 그리고 PMI와 직접적인 관계가 없는 일반적인 관리자를 대상으로 나누고
윤리 규정을 정의하고 있다. 규정집의 구성과 내용을 간략히 살펴보자

∥PMI 회원 및 기타 관련자들에게 적용되는 규정

PMI 윤리 및 직무 행위 규정(PMI Code of Ethics and Professional Conduct)

1장) 비전 및 적용 (Vision and Applicability)

2장) 책임감(Responsibility)

3장) 존중심(Respect)

4장) 공정성(Fairness)

5장) 정직성(Honesty)

∥PMI 회원들에게 적용되는 규정

1. PMI 회원 윤리 규정(PMI Member Code of Ethics)

1) 서언(Preamble)

팀원, 동료, 고용인, 고용주, 고객, 대중 및 국제 사회의 존중심을 획득하고 유지하기 위해서는 PMI 회원들이
윤리적으로 직무를 수행하는 것이 대단히 중요하다

2) 회원 윤리 규정(Member Code of Ethics)

- 나는 충직성 및 직무상 높은 표준을 유지한다

- 나는 나의 행동에 대한 책임을 받아 들인다

- 나는 나의 직무 역량의 향상을 꾸준히 추구한다

- 나는 공정하고 정직하게 실무를 수행한다

- 나는 동종 직무에 종사하는 타인의 윤리 규정 준수를 고무한다

2. PMI 회원 행위 표준(PMI Member Standard of Conduct)

1) 직무상 의무

a. 직무상 행위

- 직무 관련 이해 상충의 완전/정확/적시 공개

- 반대 급부의 여지가 있는 대가/보상/혜택의 수수 금지

- 타인의 지적 소유권의 존중과 보호

- 타인의 기여에 대한 공개와 인정

b. 고객, 의뢰인 및 고용주와의 관계

- 고객, 의뢰인, 고용주 및 유사 업무 관련 정보의 기밀 유지

- 기밀 정보 및 사적 정보의 부당한 이용 및 제공의 금지

c. 공공 및 국제 사회와의 관계

- 직무 수행 지역의 법규/규칙/고객 관련 의무의 존중 및 충족

2) PMI에 대한 의무

a. PMI 회원의 의무

- PMI 정관/정책/규정/요건/절차 준수

- PMI 권익을 손상시키는 활동의 의도적 참여 금지

- PMI에 정확/완전/진실한 정보 진술

∥PMP들에게 적용되는 규정

1. PMP 윤리 규정(PMP Code of Ethics)

1) Article 1 (사적 및 직무상 행위에 있어 높은 표준 유지)

- 훈련, 경험 또는 관련 자격이 적합한 경우에만 프로젝트 수행

- 동료들에게 윤리 규정 준수 격려

- 업무 수행 국가의 법률 준수

- 직무 스킬을 최고 수준으로 유지

- 품위 있는 직무 수행을 통한 충직성과 신의 진작

2) Article 2 (PMP의 업무 수행)

- 프로젝트 팀 멤버를 육체적, 정신적 피해로부터 보호

- 비판의 수용과 타인의 공로 인정

- 프로젝트 팀원, 동료의 전문성 개발 지원

- 최신의 프로젝트 관리 도구와 기법의 적용

- 인종, 종교, 성별, 연령, 출신에 관계 없이 공평하게 대우

3) Article 3 (고용주, 고객 관계)

- 이해 상충으로 발전 가능한 상황은 고용주 또는 고객에게 통보

- 고용주나 고객들로부터 선물이나 대가 수수 금지

- 품질, 원가, 시간 보고 시 정직한 보고

- 고용주와 고객의 사업 또는 기술 관련 기밀 유지

4) Article 4 (지역 사회에 대한 책임 완수)

- 공중의 보건과 복지의 보호, 공익 침해 사안의 적극적 반대

2. PMP 직무 행위 규정(PMP Code of Professional Conduct)

1) 직무상 책임(Responsibilities to the profession)

A. 조직의 모든 규칙 및 정책의 준수

B. 응시자 및 자격 보유자로서의 직무 수행

C. 전문 분야의 촉진

- 타인의 저작권을 인정하고 존중할 책임

- 다른 PMI 자격 보유자가 PMP 직무 행위 규정을 준수하도록 지원하고 전파할 책임

2) 고객 및 공공에 대한 책임(Responsibilities to customers & public)

A. 전문 서비스의 자격, 경험 및 수행

- 원가, 서비스 및 기대 결과에 대해 공공에게 정확하고 진실하게 진술할 책임

- 전문 서비스의 범위와 목적을 유지하고 민족 시킬 책임

- 직무 활동 과정에서 획득한 민감한 정보의 기밀 유지 및 존중할 책임

B. 이해 상충 상황 및 기타 금지된 직무상 행위

- 고객/의뢰인의 권익 침해 및 전문가로서의 판단력 손상을 피해야 할 책임

- 개인 이득을 위한 부적절한 대가, 선물 및 기타 형태의 보상을 피해야 할 책임

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

---

지금까지 PMI에서 정의한 프로젝트 관리를 위한 9개의 지식 영역과 각 영역에 해당하는 43개의 개별 프로세스에
대해 살펴 보았다

이러한 프로세스들은 '착수/기획/실행/감시및통제/종료'라는 5개의 프로세스 그룹으로 나눌수 있다

아래표는 각 지식 영역과 프로세스 그룹을 매핑한 표이다 

* 9대 지식영역 / 4대 프로세스그룹 매핑표

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

---

통합 관리

 지금까지 범위, 시간, 원가, 품질, 인적자원, 의사소통, 위험, 조달 등 프로젝트 수행에 필요한 지식영역에 대해
알아보았다. 프로젝트는 이와 같이 다양한 영역과 과정을 통해 수행된다

통합관리는 말 그대로 프로젝트의 시작부터 종료까지 전 과정에 대한 통합을 원활히 하기 위한 방법론을 다룬다.
프로젝트 수행을 공식적으로 승인 받고 목적과 요구를 확인하고 작업을 지시하고 각 영역의 진행 및 변경 사항을
통합하여 전체 프로젝트에 대한 흐름을 조절하고 프로젝트의 공식적인 종료절차를 밟는 등 프로젝트 수행 전 과정
에 대한 통합적 관리를 다룬다

통합 관리는 PM이 직접 수행해야 하는 아주 중요한 임무이자 의무라 할 수 있겠다.

PM은 통합관리만큼은 다른 (하위) 관리자에게 위임해서는 안 된다. 직접 프로젝트 전반적인 통합관리를 적극적으로 수행해야 한다

통합관리는 다음과 같은 프로세스로 이루어져 있다

프로젝트헌장 개발 -> 예비 프로젝트 범위명세서 개발 -> 프로젝트관리 계획 개발 -> 프로젝트 실행지시 및 관리 -> 프로젝트 작업감시 및 통제 -> 통합변경 통제 -> 프로젝트 종료

* 프로젝트 헌장 개발

프로젝트 헌장은 프로젝트 수행을 승인 받는 공식적인 승인문서이다

PM에게 조직 자원에 대한 사용 및 관리를 공식적으로 승인하고 프로젝트 수행과 관련된 책임과 권한을 명시한다.
보통 프로젝트 수행을 위해 PM이 조기에 임명되는 것이 좋으며 되도록이면 프로젝트 헌장이 작성될 때 임명되는
것이 좋다.

프로젝트 헌장을 만들기 위해 다음과 같은 투입물이 요구된다

1) 계약

외부 고객이 의뢰한 프로젝트 인 경우. 또는 필요한 경우

2) 프로젝트 작업 명세서

프로젝트에 의해 제공되는 제품이나 서비스를 설명한 문서이다

기타 사업적 요구, 제품 범위 명세서, 전략 계획을 포함시킨다

3) 기업 환경 요인

해당 기업의 문화 및 특성, 인적자원, 시장조건 등 기업 환경요인은 프로젝트 성공에 필수적이다

4) 조직 프로세스 자산(OPA)

조직의 표준 프로세스, 가이드, 템플릿, 기준, 절차, 정보시스템 및 과거 프로젝트 경험과 지식 및 학습을 총괄한
조직 프로세스 자산 역시 프로젝트 성공에 중요한 요인으로 작용한다

프로젝트 헌장에는 다음과 같은 것들이 명시된다

-          프로젝트 명칭 및 사업 영역

-          사업 후원자

-          프로젝트 관리자

-          착수 일자와 승인된 완료 일자

-          승인된 예산

-          제품 및 프로젝트 설명

-          사업 사례

-          프로젝트 핵심 성공 요인 및 제약 조건과 가정

-          기타 프로젝트 수행에 필요한 항목 명시

* 예비 프로젝트 범위명세서 개발

프로젝트에서 제공해야 할 제품 및 서비스에 대한 상위수준의 범위 명세서를 개발하는 단계이다

예비 프로젝트 범위명세서에는 다음과 같은 내용들이 포함된다

-          프로젝트/제품 목적

-          제품/서비스 요구사항과 성격

-          제품 인수 기준

-          프로젝트 경계(Boundary), 범위

-          프로젝트 요구사항 및 산출물

-          프로젝트 가정 사항

-          일정 이정표

-          초기 WBS

-          프로젝트 규모(비용 예측)

-          요구사항 승인

* 프로젝트 관리 계획 개발

프로젝트의 전 과정에 대한 관리 계획들을 정의, 준비, 통합, 조정하기 위한 계획을 작성하는 단계이다

프로젝트의 목표와 달성 방법에 관한 사항을 포함하고 있는 프로젝트의 기본이 되는 문서로서 작업 시작 전 참여한 모든 사람들과 공통적인 이해를 구하기 위해 작업 내용, 방법, 시기 등을 정의한다. 프로젝트 관리 방법론 및 프로젝트 관리를 위한 정보 시스템을 활용하여 계획서를 작성하며 다음과 같은 내용들이 기술된다

-          프로젝트 범위 관리 계획

-          일정 관리 계획

-          원가 관리 계획

-          품질 관리 계획

-          프로세스 개선 계획

-          직원 충원 관리 계획

-          의사소통 관리 계획

-          위험 관리 계획

-          조달 관리 계획

-          이정표 목록

-          자원 달력

-          일정 기준선

-          원가 기준선

-          품질 기준선

-          위험 등록부

∥ 프로젝트 관리 계획 수립 기법

프로젝트 관리 계획의 수립을 위해 다음과 같은 접근 방식을 활용할 수 있다

1) 하향식(Top-down)

먼저 큰 틀을 만들고 틀에서 그 틀 내에서 세부 계획을 수립하는 방식이다

추상적인 상위 수준의 계획을 수립한다

일정 및 비용을 맞추기 위해 적용할 만 하다

작성하기가 용이하지만 현실적이지 않을 수 있다

2) 상향식(Bottom-up)

상세한 세부 계획들을 만들고 이를 통합하여 전체 계획을 수립하는 방식이다

계획의 신뢰성은 높으나 시간이 많이 걸리는 단점이 있다

3) 점진적 구체화(Rolling-wave)

일정상 가까운 계획 및 식별이 용이한 항목은 상향식으로 수립하고 먼 계획은 하향식으로 수립하는 방식이다.
즉 점진적으로 구체화 시켜나가는 방식으로서 현실적인 계획 수립이 가능하지만 경험을 활용하여 많은 계획 수립
기법을 적용해야 해야 하는 단점이 있다

* 프로젝트 실행 지시 및 관리

본격적으로 프로젝트를 실행하도록 지시하고 관리하는 단계이다

프로젝트 범위 명세서에 정의된 요구사항을 달성하기 위해 프로젝트 관리 계획의 작업들을 수행하도록 관리한다

이 단계의 투입물은 다음과 같다

1) 프로젝트 관리 계획

2) 승인된 예방 조치 및 교정 조치

   이후에 알아볼 프로젝트 통제 단계에서 승인한 예방과 교정 사항이 실행단계에 다시 투입물로 넘어와서 실제
   수정 작업을 하게 한다.
   참고로 예방조치는 잠재적인 원인을 제거하는 활동이며 교정조치는 현존하는 원인을 제거하는 활동이다

3) 기타 승인된 변경 요청, 하자 보수 등

프로젝트 실행 지시 및 관리 프로세스에서는 주기적으로 수행한 작업에 대한 보고 활동이 있어야 한다

* 프로젝트 작업 감시 및 통제

프로젝트 전 과정을 감시하고 통제하는 단계이다

계획대로 성과 목표를 달성하기 위해 프로젝트를 착수, 계획, 실행, 종료하는 과정과 활동들이 잘 수행되고 있는지를 감시하고 통제하도록 한다

이 단계에서는 다음과 같은 활동을 하도록 한다

- 프로젝트 관리 계획 대비 실제 성과를 비교한다

- 예방 및 교정 조치가 필요한지 판단하기 위해 성과를 평가하고 조치가 필요하다면 권고한다

- 프로젝트의 위험을 분석하고 추적, 감시한다

- 프로젝트 현황 정보를 제공한다

- 승인 받은 변경이 적절히 반영되고 있는지 감시한다

- 기타 프로젝트 전반에 대한 감시 및 통제 활동

감시 및 통제를 통해 교정 조치, 예방 조치, 변경 조치 등을 권고하게 된다

이는 다시 이전 프로세스인 ‘프로젝트 실행 지시 및 관리’로 넘어가 실제 수행하도록 한다

* 프로젝트 종료

프로젝트를 공식적으로 종료하는 단계이다 프로젝트 수행과 관련된 모든 활동들을 종료한다.

프로젝트 종료에는 계약종료와 행정종료로 나누어진다

1) 계약 종료

프로젝트에서 체결된 모든 계약들에 대해 검수 및 정산하고 종료하는 활동이다

행정종료 절차를 지원하기 위한 절차이기도 하다

2) 행정 종료

프로젝트의 기록들을 수집하고 성패를 분석하고 교훈을 모아 프로젝트 정보를 보관하는 활동이다

이렇게 축적한 자료들은 기업의 프로젝트 경험 자료 및 교훈 자료로 활용된다

그리고 팀원을 공식적으로 해체하도록 한다

행정종료가 끝나야 비로서 프로젝트는 공식적으로 종료되는 것이다

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

---

* 계약 행정

계약이 성립되고 계약서에 날인 한 다음에는 계약 행정 업무가 이어진다

계약 행정 프로세스에서는 계약 및 공급업자와 관계를 관리하고 성과 검토 및 문서화를 하며

필요 시 계약 관련 변경을 관리하게 된다.

1) 계약 변경

만일 계약 이후 계약과 관련한 변경사항이 발생하면 변경 관리 시스템에 의해 처리하여야 하며

이는 통합 변경 통제 시스템과 통합되어 관리해야 한다.

2) 성과 검토

그리고 계약된 내용대로 공급 활동이 잘 진행되고 있는지 성과 검토가 필요하다.. 즉 과정과 결과에 대한
검사 및 감사를 실시해야 한다

3) 지불 시스템

계약과 관련해 공급자(판매자)에게 계약된 비용을 지불해야 한다

4) 분쟁 관리

계약 활동 중 발생한 분쟁을 관리한다

클레임은 계약 기간 동안 계약 조항에 따라 문서화되고, 처리, 감시, 관리되어야 한다

분쟁 당사자간 문제 해결이 되지 않는 경우 계약서에 지적된 분쟁 해결 절차에 따라 진행되어야 한다

이러한 계약행정에 있어 PM의 역할도 중요하다. 아래는 계약 형태에 따른 PM의 역할을 설명한다

잘 협상된 계약 및 계약서를 작성하여도 간혹 이해상충이 발생할 수 있다

예를 들어 계약서에 금액을 기재할 때 어떤 곳에는 숫자로 기입하고 어떤 곳에는 문자로 기입하였을 때는
문자가 우선하게 된다.
즉 숫자로 ‘100,000’ 이라 하고 문자로 ‘백만원정’ 이라고 기재되었다면 ‘백만원’이 인정되는 셈이다

이러한 선, 후 관계와 관련한 계약 유권 해석은 다음과 같다

-          문자 > 숫자

-          신법 > 구법

-          특별 조항 > 일반 조항

-          산업 표준 용어 > 일반 용어

-          계약서 사인 시 손으로 추가한 문구 > 계약서 내 인쇄된 내용

* 계약 종료
 

계약과 관련한 모든 것을 종결하는 프로세스이다

모든 미결 항목들에 대한 해결을 포함하여 각 계약을 완료/정산하고 프로젝트 혹은 프로젝트 단계의 각 계약을
종료한다

∥ 조달 감사

조달과 관련한 전 프로세스에 대한 구조적인 검토를 수행한다

조달 감사의 목적은 다른 프로젝트로 전수해 줄 수 있는 성공과 실패를 식별하기 위함이다

∥ 계약 종료

고객 측 계약 관리 책임자가 판매자에게 계약이 완료되었다는 사실을 문서로 공식 통지한다

1) 제품(산출물) 검증

계약의 대상 제품 또는 서비스에 대해 정확히 그리고 만족스럽게 완료되었는지 검증한다

2) 행정 종료
모든 계약과 관련한 기록을 최종 결과를 반영하여 최신 상태로 수정하고 마지막 잔금을 지불하고 비용과 관련한
기록들을 완성하여 다음에 사용하기 위해 이력 정보로 보관하는 행정적인 종류절차이다

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

---

* 계약 업무 기획

구매 및 획득 계획이 수립되면 본격적으로 계약을 위한 사전 활동인 계약 업무에 대한 계획을 수립해야 한다.
계약 업무 기획 단계에서는 제품, 서비스, 결과물의 요건을 문서화하고 대상 판매자(조달자)를 식별하는 활동을
하게 된다. 계약 업무 기획을 위해 이전 단계에서 산출된 조달 관리 계획과 계약 작업 명세서(SOW)를 참고하게 된다

∥ 조달 문서

조달한 항목이 정해지면 대상 판매자 에게 제안을 하도록 요청해야 한다. 제안 요청을 위한 문서를 조달 문서라 한다. 조달 문서는 판매자가 정확하고 완전한 답변을 할 수 있도록 잘 구조화되어야 한다

조달 문서에는 다음과 같은 사항들이 기술된다

-          제안에 필요한 정보 및 배경
-          표준화된 제안서 양식과 제출 절차 등에 대한 설명
-          제안 평가 기준
-          제안 가격 작성 양식
-          작업 명세서(SOW)
-          계약서 조항

조달문서의 유형으로는 RFP, IFB, RFQ 등이 있다

∥ 평가 기준

판매자가 제안서를 제출하면 등급 및 점수를 부여하기 위한 객관적/주관적 기준을 마련하도록 한다

아래와 같이 평가 기준을 설정할 수 있다

* 판매자 답변 요청

구매 및 획득 기획과 계약 업무 기획을 완료되면 판매자의 답변을 요청하게 된다

즉 조달을 담당하게 될 업체로부터 제안서를 받는 단계이다

∥ 판매자 답변 요청 기법

1) 입찰 설명회

잠재적인 판매자들을 모아놓고 조달과 관련된 설명회 및 회의를 개최하는 방법이다

판매자들이 조달에 대해 분명하고 공통된 이해를 가지도록 해 줘야 한다

이 과정에서 모든 판매자들은 평등한 입장에 있어야 한다

2) 광고

신문이나 저널 등과 같은 간행물에 광고를 실어 판매자를 모으는 방법이다

일부 공공 기관에서는 조달을 할 때 반드시 광고를 하도록 법적으로 요구되기도 한다

3) 적합 판매자 목록 작성

조달에 적합한 판매자를 조직의 경험이나 프로젝트 팀의 경험 혹은 조사 등으로 목록을 작성하는 방법이다.
인터넷, 인명록, 관련협회, 카탈로그와 같은 정보를 활용 할 수 있다

∥ 제안서

‘판매자 답변 요청’ 프로세스의 궁극적인 목적은 업체로부터 제안서를 받는 것이다

제안서는 요청된 제품, 서비스, 결과물을 제공할 수 있는 판매자의 능력과 의지를 판매자가 직접 기술,
작성한 문서이다. 또한 구매자의 요청에 대한 판매자의 대응으로써 공식적이고 법적인 청약(Offer)이다

또한 실제 계약서에서 누락된 항목은 제안서가 기준이 되기도 한다

∥ 비경쟁 조달

보편적으로 조달을 할 때 여러 판매자들을 대상으로 평가하고 검토하여 선정하게 된다

그러나 때로는 이러한 선정과정 없이 한 업체에게 맡겨야 하는 경우가 있을 수 있다

이를 비경쟁 조달이라 하는데 다음과 같은 경우이다

-          일정에 상당한 압박이 있는 경우

-          오직 하나의 판매자만 존재할 경우

-          판매자가 특허를 보유하고 있을 경우

-          기타 판매자에 대한 합리성/신뢰성이 다른 방법에 의해 사전에 보증된 경우

비경쟁 조달의 유형은 다음과 같다

1) Single Source

조달 절차를 거치지 않고 선호하는 단골(지정) 판매자와 직접 계약하는 경우이다

구매자가 선호하는 판매자가 있거나 여러 이유로 해서 다른 판매자를 찾기 원하지 않을 경우이다

2) Sole Source

오직 하나의 판매자만 있거나 판매자가 특허를 보유하고 있는 경우이다

* 판매업자 선정

제안서를 검토하고 판매자를 선정하여 계약 협상을 진행하는 단계이다. 이 단계에서 실질적인 계약서를 작성하게
된다

∥ 판매자 선정 기법

1) 가중치 결정 시스템

선정 과정에 개인적인 선입견을 없애기 위해 정성적 데이터를 계량화하는 방법이다

- 각 평가 기준에 수치적 가중치를 부여함

- 각 기준에 따라 잠재적 판매자의 등급을 부여함

- 가중치와 등급을 곱함

- 곱한 결과들을 합산하여 전체 점수를 계산함

2) 자체 산정(독립 견적)

판매업자의 제안가와 예상했던 예상가를 비교하여 근사치를 찾는다

판매자가 조달 항목에 대해 정확하게 이해했는지 평가하기 위해 미리 내부에서 ‘예가(should cost)’ 를 추정하여 차이가 큰 업체를 제거하는 방법이다

예가와 제안가의 금액 차이가 큰 경우,

계약 작업 명세서를 적절히 만들지 못하여 판매자가 조달 항목을 제대로 이해하지 못하였거나 답을 완벽히 제시하지 못하였거나 또는 시장상황이 바뀐 경우이다

3) 선별 시스템

최소 기준(제약조건)을 제시하는 선별시스템(screening system)을 이용하여 최종 검토대상 업체 리스트를 작성하기 전에 조달 항목 공급에 적합하지 않은 판매자들을 미리 제거하는 방법이다

∥ 계약 협상

본격적인 계약서에 서명하기 전에 계약의 구조와 요구조건을 명확히 하여 상호간에 합의가 이루어지도록 하는
해야 한다. 최종 계약서에는 모든 합의 사항들이 반영되어야 한다

계약 협상의 결론은 판매자와 구매자가 상호 사인한 계약서로 귀결된다

PM이 협상과정에서 선입 협상자가 아닐 수 있으며, 프로젝트 관리자 및 팀은 협상 과정에 참여하여

프로젝트의 기술적, 품질, 관리상의 요구사항을 명확히 제시할 필요가 있다

계약과정에서 PM은 다음과 같은 역할을 해야 한다

-          위험을 식별하여 이에 대한 완화와 분배 조항을 계약서에 포함하도록 한다

-          계약서의 내용이 해당 프로젝트의 요구에 잘 맞도록 계약담당자를 지원한다

-          조달 프로세스의 완료일정이 프로젝트의 공정과 잘 맞아 들어가도록 조치한다

-          계약의 협상과정에 참여한다

-          판매자와의 관계를 보호한다

협상은 공정하고 합리적인 가격을 도출(win-win)해야 하며 판매자와 구매자간 상호 우호적인 관계를 조성하도록
해야 한다

계약을 위한 주요 협상 항목은 다음과 같다

-          책임 및 권한

-          적용 법률 및 조항

-          기술 및 관리 방법

-          기술 솔루션

-          계약 자금 조달

-          일정

-          가격

-          대금 지급

∥ 계약서

판매자 선정과정에서 주요 산출물은 계약서이다

계약서는 판매자에게 명세화된 제품, 서비스, 결과물을 공급할 의무를 지우고, 구매자에게 대가를 지불할 의무를
지우는 상호 구속력 있는 협정이다

∥ 합법적 계약의 조건

계약의 대상인 제품이나 서비스(용역)가 합법적인 것이어야 한다

계약 당사자간에 청약, 승낙, 대가지불과 같은 과정을 거쳐 자발적인 의사표시에 의한 것을 입증할 수 있어야 한다

-          청약(Offer): 상대방에게 계약의 조건을 알리는 의사표시
-          승낙(Acceptance): 상대방이 제시한 청약에 대하여 거래 상대방이 동의한다는 의사표시
-          대가(Consideration): 계약을 체결하여 계약 당사자에게 생기는 이익

계약의 법적 효과는 직접 계약 당사간에만 성립한다

예를 들어 갑과 여러 을이 계약한 경우 을간에는 직접적인 계약관계가 없으므로 반드시 갑을 통하여 의사소통을
수행해야 한다

∥ 계약 관리 조직 유형

조직에 따라 계약 업무를 전담하는 부서가 있을 수도 그렇지 않을 수도 있다

프로젝트에 상관 없이 조직의 계약 업무만을 전담으로 맡아 수행하는 조직 형태를 중앙집권화 계약조직이라 하며
각 프로젝트 별로 계약 업무를 수행하는 분권화 계약조직이 있을 수 있다

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

---

조달 관리

프로젝트를 수행하기 위해 모든 것을 자체적으로 개발, 생산하지는 않는다.

전문 외부업체로부터 솔루션을 구매하거나 기술을 획득하거나 하는 등의 조달이 필요하다

조달관리에서는 이러한 프로젝트 수명주기 동안 발생하는 조달에 관한 전반적인 관리 방법론을

다룬다. 그리고 간과하지 말아야 할 것은 외부로부터의 조달이라 할 지라도 조달 품목, 자원의

품질에 대한 궁극적인 책임은 여전히 프로젝트 수행 조직에 있음이다

조달관리는 다음과 같은 프로세스로 구성되어 있다

구매 및 획득 기획 -> 계약 업무 기획 -> 판매업자 답변 요청 -> 판매업자 선장 -> 계약 행정 -> 계약 종결

* 구매 및 획득 기획

조달이 필요한 자원이 어떤 것이며, 언제 어떤 식으로 조달하겠다는 계획을 수립하는 단계이다

규모 있는 조직 혹은 프로젝트에서는 ‘구매/계약’을 위한 전담 부서가 존재하지만 그렇지 않은 경우도 있다.
이럴 경우 구매활동에 필요한 인력과 전문적 지식은 프로젝트 팀에서 제공해야 한다

∥ 제작/구매 분석

자체 제작이 나은지 외부 조달이 나은지를 여러 측면에서 판단하여야 한다

비용을 비교할 때 구매와 관련한 직접비용 이외에도 구매 프로세스를 관리하기 위한 간접비용까지 고려되어야 한다. 자체제작과 구매의 의사 결정 기준은 다음과 같다

-          비용
-          자체 기술력
-          지적 재산권
-          인적자원 가용성
-          작업 통제에 대한 수준
-          사업 구조에 따른 필요

예를 들어 이미 타 업체에서 특허를 딴 기술이나 지적 재산권이 존재하는 경우 외부 조달이 필요할 것이다.
반대로 핵심 사업 분야일 경우 자체 생산을 해야 한다. 그리고 보편적으로 자체 생산 비용과 조달 비용을 비교하여
결정한다

∥ 계약 유형

외부 조달 시 계약을 체결하게 되는데 비용과 관련해 다음과 같이 계약 유형이 나누어 진다

1) 총액 계약(고정가 계약)

Fixed Price 또는 lump-sum contracts라 한다

말 그대로 고정된 가격으로 계약을 체결하는 유형이다.

보통 완제품 계약에 해당하며 요구사항이 분명하고 변경 가능성이 희박할 때 적절한 계약 유형이다

이 계약 유형에서는 제품결함으로 인한 추가 비용은 판매자가 책임진다. 즉 판매자가 재무적인 위험을지게 된다.

총액 계약 방식의 가장 단순한 계약 형태는 Purchase Order 이다.

보통 계약은 청약->승낙->대가지불의 단계를 가지는데 Purchase Order은 승낙 단계가 없는 형태이다

즉 계약 양 당사자가 모두 사인하는 것이 아니라 한 쪽만의 사인으로 계약이 이루어지는 거래 관행에서 사용되는 형태이다. 예를 들어 수퍼에서 ‘껌 하나 주세요’ 로 계약이 체결되는 것과 같다

총액 계약은 다음과 같이 세분화 된다

- FFP(Firm Fixed Price)

가장 순수한 총액 계약 형태이다.

- FPPEA(Fixed Price Plus Economic Adjustment)

  원칙은 고정가 이지만 환률, 유가와 같은 경제적 요인을 반영해 주는 개념이다

- FPIF(Fixed Price Plus Incentive Fee)

  원칙은 고정가 이지만 판매자 동기부여를 위한 인센티브를 더해 주는 개념이다