S/W 개발자들이 사는 이야기 - 식스맨++

<DELL XPS M1330 NVIDIA GPU 문제 발생시 대표적인 증상>

2008년 5월 중순 델 XPS M1330 노트북을 구매했습니다. 현재 보증기간이 정확하게 한달 반 지난 상태입니다.
결국 보증기간이 지난 상태인데 XPS M1330의 골치거리인 GPU 문제가 발생했습니다.
워낙 많이 알려진 문제라서 증상은 간단히 설명드리겠습니다.

먼저 3일전에 화면이 잠시 깜빡이기 시작했습니다.
그러다 2일전에 막 깜빡이더군요. 그러다가 블루스크린으로 노트북이 멈추었습니다.
다시 부팅하니, 세로줄이 생기면서 화면이 보이지 않았습니다.
이것을 카메라로 여러장 찍었습니다. 동영상으로도 찍었습니다.

다음날 델 신도림 서비스센타로 통화를 시도했는데, 전화를 받지 않더군요.
그래서 구글링 검색으로 델 XPS 노트북 지원센타 전화를 찾아 전화를 했습니다.
카페 어느 분이 A/S 점검비를 받았다고 해서 A/S점검비에 대해 자세히 물어봤습니다.
상담원은 GPU 문제(메인보드 교체 필요)에 한해서는 구매일로 2년동안은 A/S 점검비가 없다고 하더군요. 만약 다른 문제라면 A/S 점검비 별도라고 합니다.

그래서 전화를 끊고 신도림 델 A/S 센타를 갔습니다.
가지고 간 노트북이 당장 재현이 되지는 않는 상태라서(아마 재현하려면 10분 정도 컴퓨터를 사용하면 발생할 겁니다) 하는 수 없이 이미 사진으로 찍어 놓고 동영상으로 찍어 놓은 것이 있어, 보여주었습니다.

그래서 GPU문제임을 확인 받았습니다. (꼭 사진이나 동영상 찍어서 가져가십시오)
그리고, 처음엔 신도림 A/S 담당자가 GPU 문제라도 A/S 점검비는 내야한다고 하더군요. (잘 모르고 계셨던 거 같습니다)
분명 델 기술지원팀에 GPU문제는 2년동안 A/S 점검비는 무료라는 것을 이미 확인한 결과라고 얘기하니, 아무 비용도 받지 않고 메인보드 교체를 완료했습니다.

여기까진 참 좋았는데, 메인보드 교체하고 난 후 다른 문제가 발생했습니다.
먼저 잘 사용하던 무선 인터넷 스위치쪽 문제로 다시 한번 메인보드를 뜯고 케이블을 교체 했습니다.
그 후에 잘 작동되던 지문인식 장비가 작동되지 않았습니다.(OS문제가 아닌 하드웨어 문제는 확실했습니다)
그래서 그 다음날 또 확인하러 갔는데, 결국 신도림 서비스 센타에서는 메인보드 교체 중 문제가 발생했더라도 지문인식기에 영향을 주는 일을 하지 않았다고하면서 지문인식 하드웨어 고장에 대해서는 고쳐줄 수 없다고 하더군요.

사실 잘 사용하던 것을 메인보드 교체 후 사용 못하게 되어 황당한데 본인들은 책임없다고만 하니 도저히 이해할 수 없는 상황이었습니다. 담당자 얘기는 하필 메인보드 교체되는 순간 지문인식기가 고장난 것이다라고만 합니다.
A/S 담당자는 권한이 없다고 해서, 결국 주중에 델 기술지원팀에 직접 전화로 문의해 보기로한 상태입니다.


* 이 과정에서 제 노트북 전체 해체가 4번 있었습니다 ㅜㅡ
* 암튼 초기엔 가격대비 좋은 스펙이라 구매했는데, 나중엔 여간 신경쓰이는 게 아니네요.
* 참고로 2008년 구매 기준 델 노트북 메인보드 보증기간은 3년입니다. 델의 메인보드 보증기간 3년이라고 해서 국내 다른 업체같이 점검비(공임)가 공짜가 아닙니다.여기서 3년 보증기간 공짜는 메인보드를 구매하는 것이 공짜라는 것입니다. 국내 가전 제품 A/S와 다르니 참고하시기 바랍니다.단지 GPU 문제는 이미 널리 알려진 결함이라 A/S 점검비를 2년동안 받지 않는다고 합니다
* 다시 이 모델과 델 제품을 사라고 하면 안타까운 일이지만, 전 절대 다시 구매하고 싶지 않습니다.
*델은 국내에서 제대로 팔려면 좀더 A/S 지점에 권한많은 분을 배치해서 직접 결정할 수 있게 하는게 필요하지 않을까 싶습니다. 어디 번거로워서 제품 구매하고 싶겠습니까?

새로운 프로젝트를 하게되면, 아래와 같은 프로세스를 거친다.
1. SRS작성
2. SRS에서 요구하는 기능 구현
3. SDS작성
4. 개발
5. QA
6. 릴리즈
당연히 2번을 하다가 1번을 고치기도 하고, 3번을 하다가 1번을 고치기도 하고,4번을 하다가 1번을 고치기도 한다.

5번을 하다가 고치기도 할까?

당연히 SRS를 작성할 때나, SDS를 작성할 때나, 개발을 할때 안나오던 버그가 발견되어서 SRS에 이런 경우에는 non bug로 처리한다고 SRS를 반영한다.

이번 프로젝트도 역시나 QA하는 동안 버그를 발견했다. 발견된 시기는 QA를 시작하는 시점이었고, 관련 이슈를 검토한 시점은 베타 기간이었다. 큰 프로젝트가 아니라 짧은 베타기간중 3일이라는 긴 시간을 잡아 먹었다.
 QA에서 제품의 기능을 검증하는 PC에서 특정 UI를 실행하면, "아주 느리게 나오는 버그"였다. QA 알파에  느려지는 이슈가 올라왔을 때는, 당장 "아 내가 실수했구나'하는 버그들이 많아서 그 이슈를 처리한다고 관심을 가질 여유가 없었다.
 "아 내가 실수했구나"라는 버그는이 내 pc에서도 같은 재현 스텝을 하면 그대로 발생하는 이슈들이다. "아주 느리게 나오는 버그" 내가 가지고 있는 어떤 머신을 이용해도 발생하지 않아서 특정 pc에서만 발생하는 이슈겠지 하고 미루어 놓았다.
 베타가 시작되고, 본격적으로 관련 이슈를 검토해 보기 위해서, QA용 pc를 공수했다. pc 구하기가 어려워서.. 라는 말로 시작을 했는데,.. QA pc 대부분에서 느려지는 현상이 발생한다고 하면서 여러 pc 중에 한대를 빌려주었다.
 글로만 보던 버그를 눈 앞에서 재현을 해보니, 어처구니가 없었다. 이런 현상이 QA를 하는 모든 pc에서 발생한다고 하니. 마음이 조급해졌다. 우선 어떤 기능 때문에 느려지는 현상이 발생하는지 체크하기로 했다. 아래와 같은 순서로 체크해 보았다.
 1. 특정 UI만 따로 분리해서 프로그램을 만들어서 실행해본다.
 2. 특정 UI와 동시에 실행되는 기능들을 모두 off 해본다.
 3. 특정 UI와 동시에 실행되는 기능들을 하나씩 키면서 실행 해본다.
역시, 첫번째, 두번째에서는 이상없이 실행이 되었다.
그런데 세번째에 기능을 하나씩 키면서 실행을 해보는데, 특정 UI가 발생할때
알파 값을 먹인 윈도우를 배경으로 까는 기능이 있는데 그 기능을 키니깐 늦어 졌다.
 어떤 기능 때문에 늦어 졌는지를 파악했으니깐 실제 어떤 함수에서 이런 현상을 발생시키는 지 확인하면 되기 때문에 그 기능 내부에 함수를 하나씩 제거 해보면서 체크해 보았다. 
 조금만 더하면 된다는 생각에 퇴근 시간이 되었지만, 끝까지 찾아보았다. 그런데.. 왠걸 모든 함수를 다 빼 보았지만, 여전히 느려지는 현상이 발생하는 것이다.
 결국 포기하고 다음날 아침에 와서 다시 확인해 본다는 생각으로 어제 찾은 기능을 on하는 것은 제일 마지막으로 미루고, 처음부터 다시 해보았다.역시나 알파값을 가진 배경을 그리는 윈도우 때문이었다.
 혹시나 하는 마음에 내가 만든 함수가 아닌 윈도우에서 제공해주는 함수인 "setlayerattribute"를 제거해 보았다. 그런데 UI가 정상적인 속도로 동작을 했다. 찾기는 찾았는데 해결책을 제시할 수 없는 상황이 발생한 것이다.
 이 함수를 선택한 이유가 가장 쉬우면서 GDI, GDI++ 비해서 훨씬 속도가 빠르다고 해서 사용한 함수인데. 너무 어처구니가 없었다. 내가 만든 함수가 아니기 때문에 어쩔 수 없다라고 하면, 그러면 다른 프로그램들은 어떻게 유사한 기능들을 사용하고 있냐는 질문에 답을 할 수 없기 때문에 더 파보기로 했다.
 1. 디버그를 이용해서 윈도우 내부 함수를 하나씩 off 해본다.
 2. 그래픽 연산 문제이기 때문에 그래픽 드라이버를 업그레이드 해본다.
 위와 같은 2가지 방법이 있는데 1번을 하기에는 시간적으로 촉박하여 2번을 해보기로 했다. 업그레이드를 해보았지만, 관련 현상을 여전히 발생하였다. 그래서 같은 회사의 같은 계열 그래픽 가드중 상위 그래픽 카드를 구해서 실행해 보았다. 여전히 마찬가지로 느렸다. 혹시나 하는 마음에 다시 최신 드라이버로 업그레이드를 해보았다.
 그런데, 업그레이드를 한 이후에는 UI 느려지는 현상이 발생하지 않았다. 드라이버 버젼을 확인하는 2009년 2월이었다. 다시 원래 그래픽 장치를 꼽고 드라이버 버젼을 보니 2006년 버젼이 최신이었다.
 흠 여기서, 그냥 그래픽 드라이버 문제라고 결론 지을 수 있지만, 우리 제품 쓰는 사람이 똑같은 현상이 발생했을때 '그래픽 장치를 바꾸세요.' 라고 할수 없기 때문에 해결책을 제시해주기로 마음 먹었다.
 그런데 릴리즈 날자는 다가오고 다른 버그들도 있는데.. 걱정이다.

대학에서 운영체제 시간에 Deadlock에 대해서 배울 때, 많이 거론되는 것이 Dijkstra의 '식사하는 철학자' 일 것이다.
멀티 쓰레딩 프로그래밍을 하다 보면 아주 많은 주의를 기울여야 할 Deadlock 문제.
다양한 deadlock 문제 중에 윈도우 프로그래밍의 critical section에서 야기될 수 있는 deadlock을 WinDBG를 사용해서 발견하는 방법을 설명하려고 한다.
멀티쓰레딩 프로그램에서 hang이 발생하면 우선 deadlock을 의심해볼 수 있다.
처음으로 할 일은 hang dump를 수집하는 것이다.
windbg의 attach process 기능을 사용하던지, ADPlus나 UserDump 프로그램을 사용해서 응답하지 않는 프로그램의 hang dump를 수집한다.
hang dump는 약간의 시차(한 10초 정도)를 두고 3번 정도 반복해서 만드는 것이 좋다.
dump가 생성되면 windbg를 사용해서 디버깅을 시작한다.
dump 파일을 open 하고 난 뒤, command line에 '!locks'라고 친다.
user mode 디버깅에서는 locks는 ntsdexts.locks와 동일한 명령이다.
이 명령은 ntdll.dll에 있는 RtlInitializeCriticalSection에 의해서 초기화된 critical section 객체의 정보를 쭉 보여준다.

=====================================================

0:000> !locks

CritSec w3svc!g_pWamDictator+a0 at 68C2C298
LockCount          0
RecursionCount     1
OwningThread       d1
EntryCount         1
ContentionCount    0
*** Locked

CritSec SMTPSVC+66a30 at 67906A30
LockCount          0
RecursionCount     1
OwningThread       d0
EntryCount         1
ContentionCount    0
*** Locked

=====================================================

여 기에 아무런 옵션이 없으면 현재 프로세스에 속한 critical section 객체만을 보여주고, 옵션으로 -v를 붙이면 프로세스 밖에 있는 critical section 객체도 보여준다. '-o' 옵션은 Windows XP와 그 이후의 운영체제만 지원하는 것으로 orphaned information(유효하지 않은 critical section을 가르키고 있는 포인터)만을 보여준다.
locks 명령 말고도 비슷한 모양으로 정보를 보여주는 명령어는 !critecs, !cs 등이 있다.

이 위의 출력물에 대한 의미는 다음과 같다.

• Windows XP와 그 이전 것들
• LockCount 필드는 이 critical section으로 진입하기 위한 EnterCriticalSection()을 호출한 thread의 수에서 하나를 뺀 것과 같다. 왜 하나를 빼야 하냐면, 이 필드는 -1을 unlock 상태로 표시하고 EnterCriticalSection()이 호출될 때마다, 하나씩 증가하기 때문이다. 나중에 LeaveCriticalSection()이 호출되면 하나씩 감소시킨다. 예를 들어, 만약 이 값이 3이라면 하나의 thread는 이 critical section에 진입한 상태이고, 3개의 다른 thread들이 이 곳에 진입하기 위해서 기회를 노리고 있다는 의미이다. 
• RecursionCount 필드는 critical section에 진입한 thread가 다시 EnterCriticalSection()을 몇 번 더 호출하고 있는지를 나타낸다. 
• EntryCount 필드는 critical section에 진입하지 못한 thread가 몇 번이나 EnterCriticalSection()을 호출하고 있는지를 나타낸다. 
• CritSec w3svc!g_pWamDictator+a0 at 68C2C298에서 at 다음에 있는 숫자는 critical section의 핸들이다. 
• Owning thread는 말 그대로 이 critical section 객체를 현재 가지고 있는  thread이다.
  

• 그 이후 것들(Windows Server 2003 SP1과 그 이후것들)은 'Debugging Tools for Windows'의 Help에 Display a Critical Section 편을 보면 자세히 나와 있다.

Deadlock에 빠진 것이라면, !locks 명령어를 실행했을 때, LockCount가 1 이상인 것들이 하나 이상 존재해야 한다. 
만약 그렇다면 이 thread들의 call stack을 훑어 봐야 한다.
call stack을 보면 top 언저리에 ntdll!RtlpWaitForCriticalSection+0x132와 비슷하게 보이는 frame이 존재하는데 이 함수의 첫번째 인자가 그 thread가 지금 기다리고 있는 critical section의 핸들이다. 이 핸들을 !locks으로 출력됐던 결과에서 봤을 때, critical section을 가지고 있는 두 놈이 서로의 것을 기다리고 있다면, 100%입니다.

   비밀키 암호기법에 있어서 가장 큰 문제점은 바로 메세지의 전달자와 수신자가 똑같은 비밀키를 다른 사람들이 모르게 공유해야 한다는 점이다.

  특히 메세지의 전달자와 수신자가 물리적으로 서로 떨어져 있다면 그 두사람은 매우 안전한 통신 수단을 이용하여 비밀키를 전달하여야 할 것이다. 만약 공격자가 이 두사람간의 통신경로상에서 비밀키를 얻어낸다면 그 후로부터 메세지의 송신자와 수신자가 그 비밀키를 사용하여 메세지를 암호화한다 하여도 그 공격자는 자신이 훔친 비밀키를 이용하여 모든 메세지를 복호화하여 그 내용을 알 수가 있게 될 것이다. 또한 비밀키 암호기법에 있어서 모든 키들은 그것을 사용하는 두 사람이외에는 아무도 알 수 없도록 비밀리에 보관되어야 하므로 만약 수많은 사람들이 동시에 상호 메세지를 주고 받고자 하는 경우에는 이러한 비밀키의 관리가 매우 어려워진다. 이와 같이 암호화를 위한 키의 생성과 전달 그리고 보관하는 문제 즉, 키의 관리 문제는 암호를 이용한 정보보안에 있어서 중요한 이슈가 되는 문제이다.

  비밀키 암호기법이 갖는 위와 같은 키관리의 문제를 해결하기 위해서 제안된 것이 바로 공개키 암호 기법이다. 이것은 1976년 Whitfield Diffie와 Martin Hellman에 의해 제안되었다. 비밀키는 메세지의 송/수신에 참여하는 모든 사람들이 개인적으로 비밀리에 보관하고 있어야 하고 공개키는 공개키 디렉토리에 보관되어 모든 사람들이 자신이 원하는 공개키를 얻을 수 있어야 한다. 그리하여 송신자가 메세지를 보내기 위해 먼저 공개키 디렉토리에서 메세지 수신자의 공개키를 획득한다(실제로는 공개키를 획득하는 과정에서도 암호기법을 이용한 인증절차가 필요하며 공개키를 보관하는 디렉토리의 안전한 관리를 위해 여러가지 방법이 필요하다). 그리고 송신하려는 메세지를 수신자의 공개키를 이용하여 암호화한 후 발송한다. 암호화된 메세지를 받은 수신자는 자신만이 갖고 있는 비밀키를 이용하여 그 메세지를 복호화하여 메세지를 얻는다. 여기에서 반드시 주목해야 할 사실은 바로 비밀키와 공개키는 키의 길이만 동일하고 서로 다른 값을 갖는 키라는 것이다. 

공개키 알고리즘 중 RSA 기법은 Rivest, Shamir, Adleman에 의해 개발된 방식으로 지수 승을 가진 수식을 사용하도록 만들어졌다. 평문은 블록으로 암호화된다. 각 블록은 어떤 수 n보다 작은 이진 값을 가진다. 암호와 복호는 평문 블록 M과 암호문 블록 C에 대하여 다음의 형태를 따른다.

 

C = M^e mod n

M = C^d mod n = (M^e)^d mod n

 

여기서 n=pq, p와 q는 솟수, d는 정수(단 d는 Φ(n)에 서로소인 정수), 그리고 e= d-1 mod Φ(n) 이다.

송신자 A와 수신자 B는 n의 값을 알아야 한다. 예를 들어 수신자 B의 공개키 KU는 {e,n}으로 구성되고 수신자 B의 KR은 {d,n}으로 구성되어 있을 때 송신자 A는 수신자 B가 공개한 e의 값을 알고 있으며, 수신자 B만이 d의 값을 알고 있다.

만일 사용자 A가 메시지 M을 사용자 B에게 전송하고자 한다면 A는 C =( M^e mod n )을 계산하여 얻은 C를 전송하고 B는 M = C^d mod n을 계산하여 M을 얻게 된다. 즉 e와 d가 mod n의 곱셈에 대한 역원 관계에 있으므로 공개키로 암호화 한 메시지는 개인키로 복호화되며 개인키로 암호화한 메시지는 공개키로 복호화되게 된다. 공개키는 다른 사람들에게 공개하고 개인키는 자신만이 알고 있다는 점을 생각해보면 상대방의 공개키로 암호화한 내용은 상대방만이 복호화할 수 있으며 나의 개인키로 암호화한 메시지는 모든 사람에 의해서 복호화될 수 있다. 결과적으로 상대방의 공개키를 이용한 암호화는 특정 상대방만이 알아볼 수 있게 하기 위한 방안으로 이해될 수 있으며 자신의 개인키를 이용한 암호화는 자신임을 입증하는 전자서명에 효과적으로 이용될 수 있다.

참고적으로 관용 암호방식과 공개키 암호방식의 알고리즘 상의 구성에 있어서의 차이점을 살펴보면 관용 암호방식의 경우는 평문에 대한 연산의 조합이나 재배치를 기반으로 하는 반면에 공개키 암호방식은 지수승이나 mod 연산 등의 수학적 수식을 기반으로 한다는 차이점을 들 수 있다.

요즘 정신이 산만하네요. 산만한 만큼 생각도 많고 매일 고민에 빠져 살고 있습니다.

마지막으로 노무현 전 대통령님 삼가 명복을 빕니다. 꼭 좋은 곳에서 행복하세요.

고 노무현 전 대통령님의 유서에 대한 김제동씨의 글입니다.