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

집에서 사용하는 가전 제품중에 5년 이상 사용한 가전 제품들이 몇가지 있다.

그 가전제품들은 모두 주 기능이 잘 작동하고 있다.

예를 들면 선풍기같은 경우 시원 바람을 나에게 선사해준다.
외장형 수신기로 모니터를 이용해서 TV를 잘 보고 있다.

그런데 이 두 제품 모두 전자식 push 버튼을 가지고 있는데 버튼을 누르면 오동작을 한다.
선풍기 같은 경우 회전을 할려고 회전 버튼을 누르면
바로 옆에 있는 버튼인 시간 조절 버튼의 기능을 해 버린다.

사실 선풍기를 혼자 사용하기 때문에 회전 버튼을 사용하지 않으면 되므로 그냥 계속 사용하였다.

그런데, 최근에 외장형 수신기의 전원 버튼이 나를 힘들게 한다.
전원을 off 하려고 전원 버튼을 꾹 누르고 있으면, 채널이 바뀌거나 소리가 조정이 되면서 전원이 꺼지지 않는다.

오늘 도저히 인내심의 한계를 느껴서 고치거나 버리기로 맘 먹었다.

우선 학교 다닐 때 PCB를 지우개로 지우면 접전 문제가 해결 된다는 기억이 떠올라서
우선 외장형 TV 수신기를 분해했다.

분해를 해서 PCB를 확인해 보니 아래 사진과 같이 군대 군대 끈적끈적한 무언가가 달라 붙어 있었다.

이것만 제거하면 되겠구나 하는 생각으로 집에 있는 지우개로 열심히 기판을 문질렀다. 그런데 기판에 납땜 된 부분이 뾰족하게 올라와서 잘지워지지 않았다.

그냥 포기할까 하다가.. 

올해 초에 Cortex-M3로 라인트레인스를 만들때 사용하던 플럭스 펜이 눈에 들어왔다.
플럭스(flux)라 함은 송진과 같이 기판에 납이 잘 뭍도록 도와주는 것을 말한다.
Cortex-M3 CPU같이 핀도 많고 촘촘한 것은 송진을 사용하는 것보다는 수용성 플럭스를 사용하는 것이 좋다고 해서 사두었던 펜이다.

혹시나 싶어서 이 펜을 열어보니 알코올 냄새가 내 꼬 끝을 자극했다.
아! 이거다는 생각이 들어서 집에 있는 못 쓰는 칫솔을 가지고 왔다.
우선 플럭스 펜을 이용해서 오염부위를 딱으니 끈적한 부분이 흐느적 거렸다.
이때 칫솔을 이용해서 끈적한 부분을 딱아 내니 표면이 깨끗해 졌다.


한 3분정도 기판의 모든 부분을 딱아내고 조립을 해서 전원 버튼을 눌러 보았다.

오 브라보! 정상적으로 동작했다.

혹시나 그 외에 정상적으로 동작하지 않는 버튼이 정상 동작하는지 확인해 보았지만 여전히 동작을 하지 잘하지 않았다. 하지만 청소하기 전 보다는 동작을 잘 되었다.

원래는 PCB 납땜 후에 기판에 뭍어 있는 플럭스를 제거하기 위해서 플럭스 제거제를 사용해야 하는데 집에는 없어서 아쉬웠다.

아마도 플럭스 제거제를 사용하면 모든 버튼이 정상동작했을 텐데라는 아쉬움은 남지만 나를 짜증나게 했던 전원 버튼이 정상 동작하여 스스로 만족하고 작업을 마쳤다.

혹시 집에서 PCB에 붙어 있던 push 버튼이 동작하지 않을 때 다들 어떻게 하세요? ㅎㅎ

 Google의 NexusOne을 사용한지 한 달이 조금 넘었다. 좀 더 기다리면 아이폰 4G를 만날 수 있다는 주변의 강한 권유에도 불구하고 늘 비주류의 길을 걷길 원하는 자유 영혼의 소유자로서 당당하게 넥서스원을 선택하였다. TT  다른 스마트폰은 써보지 않은터라 다른 것들과의 비교는 나의 능력 밖이고, 난 스마트폰이 이기나 내가 이기나 마구마구 그를 시험하는 성향이 없는지라 그저 블러그상에 떠도는 몇몇 어플들 설치해 가면서 잘 쓰고 있다.
 근데 그 와중에 이 기기에 대해 나도 슬슬 짜증을 낼 수 밖에 없는 치명적인 단점을 가지고 있었으니, 바로 터치스크린 오류다. 이미 인터넷 여기저기에 이 문제를 지적하는 글들을 보았으나, 직접 겪어 보니 생각보다 불편함이 컸다. 좀 더 자세히 얘기하자면, 가끔.. 총 사용하는 횟수의 1/4쯤... 이놈이 내가 터치하는 부분이 아닌 다른 지점에 터치를 한다고 인식한다. 어떤 블로그의 글을 보니 터치를 테스트하는 프로그램을 깔고 봤더니 한 지점을 터치함에도 불구하고 또 다른 한 지점이 더 인식되면서, 두 지점이 찍히는 것처럼 동작한다는 분석도 있었다. 아무튼... 이게 문자를 보내려고 자판을 터치할 때 엉뚱한 글자가 찍히는가 하면, 구글맵에서 지역 이동을 하려고 하면, 지 맘대로 확대가 되고 축소가 되서 불편할 때가 많았다.
 그러던 차에 한 번 공식적인 문제 재기를 해보고자 KT 서비스 센터에 문의를 하니 넥서스원의 단말기에 대한 고객서비스를 하고 있는 TGS에 문의하라는 답변을 받았다. TGS에 문의했더니 HTC 담당 직원인듯한 사람의 답변으로는 문제를 정확히 파악할 수 없으니 가까운 서비스센터로 가라고 했다. 이런 문제로 문의하는 사람들이 꽤 있을 것 같은데... 잘 모르겠단다. 불행히도 회사 업무상 직접 고객센터를 방문하는 시간을 못 내고,  혹시나 하는 마음에 Google의 NexusOne truobleshooting site를 찾아보았다. 마침 이런 문제에 대한 항목이 있었다. 뭔가 해결의 실마리를 잡을 수 있을까 기대감에 부풀어 카테고리를 따라가니... 다음과 같은 해결책이 제시되어 있었다.


음... 원인에 대한 설명도 한 마디 없고, 한마디로 문제 생기면 껐다 켜라...TT

새로운 프로젝트를 하게되면, 아래와 같은 프로세스를 거친다.
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 연산 등의 수학적 수식을 기반으로 한다는 차이점을 들 수 있다.

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

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