함수 포인터

2007/10/14 19:34
15-2.함수 포인터
  가.정의
  나.함수 포인터 타입
  다.포인터로 함수 호출하기
  라.함수 포인터 인수
  마.함수 포인터 리턴

출처 : http://winapi.co.kr/

이올린에 북마크하기

코딩하던 노인

2007/06/23 09:43
왠지 요즘 이 글이 읽고 싶네요.

원작 : 尹五榮의 '방망이 깎던 노인'

코딩하던 노인

벌써 3-4년 전이다. 내가 갓 취업 한 지 얼마 안 돼서 구로공단에서 일 하던 때다.
이른 아침. 찜질방에서 잔 뒤 출근 하러가는 길에, 게임한판 하고 가기위해 근처 PC방으로 향했다.

리듬안마 맞은편 PC방에 구석에 앉아 비쥬얼 스튜디오를 들여다 보는 노인이 있었다.
밤새 잡히지 않는 버그에 대한 조언도 구할겸 소스를 봐달라고 부탁을 했다.
값을 굉장히 비싸게 부르는 것 같았다.

“좀 싸게 해줄 수 없습니까?”했더니,

“소스 하나 고쳐주는걸 가지고 에누리 하겠소? 비싸거든 자네가 고쳐.”

대단히 무뚝뚝한 노인이었다. 더 값을 흥정하지도 못하고 버그나 잡아달라고 부탁했다.

그는 잠자코 열심히 들여다 보고 잇었다. 처음에는 대충 보는 것 같더니, 저물도록 이리 스크롤해 보고 저리 스크롤 해보고 굼뜨기 시작하더니, 마냥 늑장이다. 내가 보기에는 그만하면 다 고친것 같은데, 자꾸만 더 고치고 있었다.
인제 잘 돌아는 가는것 같으니 그냥 달라고 해도 통 못 들은 척 대꾸가 없다. 사실 출근 시간이 빠듯해 왔다.
갑갑하고 지루하고 인제는 초조할 지경이었다.

“더 고치지 않아도 좋으니 그만 주십시오.”

라고 했더니, 화를 버럭 내며,

“끓을 만큼 끓어야 밥이 되지, 생쌀이 재촉한다고 밥 되나.”

한다. 나도 기가 막혀서,

“맡긴 사람이 좋다는데 무얼 더 고친다는 말이오? 노인장, 외고집이시구먼, 출근 시간 늦었다니까요.”

노인은 퉁명스럽게.

“다른 데 가 고치우. 난 소스 지우겠소.”

하고 내뱉는다. 지금까지 기다리고 있다가 그냥 갈 수도 없고, 출근 시간은 어차피 틀린 것 같고 해서, 될 대로 되라고 체념할 수밖에 없었다.

“그럼, 마음대로 고쳐 보시오.”

“글쎄, 재촉을 하면 점점 지저분해지고 늦어진다니까. 코드란 제대로 짜야지, 짜다가 놓치면 되나.”

좀 누그러진 말씨다. 이번에는 고치던 것을 숫제 새로 처음부터 태연스럽게 곰방대에 담배를 담아 피우며 짜고 있지 않은가.

나도 그만 지쳐 버려 구경꾼이 되고 말았다. 얼마 후에야 단축기를 눌러 이렇게 저렇게 컴파일 하고 돌려 보더니 다 됐다고 내준다. 다 되기는 아까부터 다 돼 있던 코드다.

출근 놓치고 지각 해야 하는 나는 불쾌하기 짝이 없었다. ‘그 따위로 코딩을 해 가지고는 장사가 될 턱이 없다. 손님 본위가 아니고 제 본위다. 그래 가지고 값만 되게 부른다. 상도덕도 모르고 불친절하고 무뚝뚝한 노인이다.’

생각할수록 화증이 났다. 그러다가 뒤를 돌아보니 노인은 태연히 허리를 펴고 리듬안마 지붕 추녀를 바라보고 섰다. 그때, 그 바라보고 섰는 옆 모습이 어딘지 모르게 노인다워 보이고, 부드러운 눈매와 흰 수염에 내 마음은 약간 누그러졌다. 노인에 대한 멸시와 증오도 감쇄된 셈이다.

회사에 와서 소스를 내놨더니, 팀장은 완벽하게 코딩했다고 야단이다. 퇴사한 박대리(주1)가 코딩한 것보다 참 좋다는 것이다. 그러나 나는 전의 것이나 별로 다른 것 같지가 않았다. 그런데 팀장의 설명을 들어 보니, 코드가 너무 지저분하면 버그가 생기기 쉽고 같은 코드라도 성능이 떨어지며, 변수 이름이 제멋대로이면 다른 사람에게 코드를 넘겨주어도 쪽팔리기 쉽단다. 요렇게 꼭 알맞은 소스는 좀체로 만나기가 어렵다는 것이다. 나는 비로소 마음이 확 풀렸다. 그리고 노인에 대한 내 태도를 뉘우쳤다. 참으로 미안했다.

옛날부터 내려오는 開作(개작-Open Source)은 혹 컴파일이 안되면 자료형을 바꿔 컴파일 하고 파일이 누락되어 있으면 구글에서 찾아 넣고 컴파일 하면 좀체로 에러를 내지 않는다. 그러나 요새 소스는 에러가 한번 튀어나오기 시작하면 걷잡을 수가 없다. 예전에는 오래된 開作(개작-Open Source)코드를 갈아엎을때, 깔끔한 최신 배포판으로 잘 받아서 갈아치우기만 해도 컴파일이 되었다. 이것을 최신 리빌드라고 한다. 이렇게 하기를 세 번 한 뒤에 비로소 배포한다. 이것을 '최신 버전을 릴리즈 한다'라고 한다. 물론 날짜가 걸린다. 그러나 요새는 소스코드를 그냥 통채로 복사해서 붙여넣는다. 금방 붙는다. 그러나 왠지 찝찝하다. 그렇지만 요새 남이 보지도 않는 것을 며칠씩 걸려 가며 리빌드 할 사람이 있을 것 같지 않다.

外注(외주)만 해도 그렇다. 옛날에는 복사한 코드(Copy&Paste Code)는 얼마, 직접 짠 코드는 얼마, 값으로 구별했고, 구디구빌(NDNB:Nine-Debug, Nine-Build)한 것은 세 배 이상 비싸다. '구디구빌(NDNB)'란 아홉 번 디버깅하고 아홉번 리빌드 한 것이다. 눈으로 봐서는 다섯 번을 했는지 열 번을 했는지 알 수가 없다. 단지 말을 믿고 사는 것이다. 신용이다. 지금은 그런 말조차 없다. 어느 누가 남이 클레임 걸지도 않는데 아홉 번씩 디버깅 하고 리빌드 할 이도 없고, 또 그것을 믿고 세 배씩 값을 줄 사람도 없다.

옛날 사람들은 코딩은 코딩이요, 생계는 생계지만, 코드를 만드는 그 순간만은 오직 아름다운 코드를 만든다는 그것에만 열중했다. 그리고 스스로 보람을 느꼈다. 그렇게 순수하게 심혈을 기울여 어플리케이션을 만들어 냈다.

이 소스코드도 그런 심정에서 만들었을 것이다. 나는 그 노인에 대해서 죄를 지은 것 같은 괴로움을 느꼈다. “그 따위로 해서 무슨 코더를 해 먹는담.”하던 말은 “그런 노인이 나 같은 젊은이에게 멸시와 증오를 받는 세상에서, 어떻게 아름다운 코드가 탄생할 수 있담.”하는 말로 바뀌어졌다.

나는 그 노인을 찾아가서 삼겹살에 소주라도 대접하며 진심으로 사과해야겠다고 생각했다. 그래서 그 다음 월요일에 퇴근하는 길로 그 노인을 찾았다. 그러나 그 노인이 앉았던 자리에 노인은 있지 아니했다. 나는 그 노인이 앉았던 자리에 멍하니 서 있었다. 허전하고 서운했다. 내 마음은 사과드릴 길이 없어 안타까웠다. 맞은편 리듬안마의 지붕 추녀를 바라다보았다. 푸른 창공에 날아갈 듯한 추녀 끝으로 섹시한 포스터가 걸려있었다. 아, 그때 그 노인이 저 포스터를 보고 있었구나. 열심히 코딩 하다가 우연히 추녀 끝의 포스터를 바라보던 노인의 거룩한 모습이 떠올랐다. 나는 무심히 ‘採菊東籬不(채국동리불)다가 悠然見南山(유연견남산)!’ 도연명의 시구가 새어 나왔다.

오늘, 회사에 출근했더니 후배가 MFC(Microsoft Foundation Classes)와 리소스 편집기로 코딩을 하고 있었다. 전에 커맨드라인과 배치파일로 힘겹게 코딩하고 컴파일 하던 생각이 난다. 도스를 구경한 지도 참 오래다. 요새는 까만 화면은 볼 수도 없다. '왓콤씨' 이니, '어셈블러'이니 애수를 자아내던 그 개발툴들도 사라진지 이미 오래다. 문득 3-4년 전 코딩 하던 노인의 모습이 떠오른다.


주1) "퇴사한 박대리" - 필자가 자기자신을 희화한 인물.
이올린에 북마크하기

[펌]프로그래밍에 대한 생각

2007/06/23 09:41
얼마전 3층 발코니에 나가서 커피 한잔 마시면서 좀 쉬고 있는데 저희 팀장님이신 동욱님이 마침 나오시더군요.. 그냥 이런저런 얘기 하면서 머리를 식히다가 나온 얘기가, 누구나 기억할 만한 중학교 국어책에서 배운 윤오영님의 수필 “방망이 깎던 노인”이야기가 나왔습니다. 투철한 장인정신과, 책임감, 서두르지 않는 여유로움의 미덕 등을 강조하는 내용이라고 참고서에는 나와있죠^^
프로그래머에게 있어 장인정신이란 무엇일까요? 우리는 방망이를 깎아야 하는 걸까요?

버그 없는 프로그램을 만드는 것, 완전 무결한 에러율 0%의 로직을 구현해 내는 것, 누구나 언제든지 필요한 기능을 손쉽게 추가하고 개선해 나갈수 있도록 이해하기 좋게 코딩하는 것, 최소의 자원으로 최고의 퍼포먼스를 내는 최적의 프로그램을 짜는 것, 발생가능한 모든 상황을 미리 예상하고 대안을 보유하고 있도록 작성하는 것… 조금씩 말만 다르지 프로그래밍 분야에서 말하는 장인정신이란 대충 비슷합니다.
그런데 정말이지 이런것들이 개발자가 갖춰야할 장인정신일까요?

일단은 맞다고 하고 싶습니다. 완벽한 제품을 만드는 것이 장인의 정신이죠.. 하지만 반드시 장인정신의 덕목을 엄수해야 한다고 생각하지는 않습니다. 이건 제조업이 아닙니다. 제조업과는 다른 잣대로 생산물을 평가해야 하죠..
게다가, 사실.. 먹고 살자고 하는 짓이지 않습니까.. 주어진 시간 안에(정말이지 모호한 표현입니다만..) 계획된 목표물(역시 모호합니다.)을 만들어야 하는 것이 비지니스의 원리죠.. 시장경제가 어쩌니 하는 말들을 굳이 꺼내지 않아도 누구나 알고 있을 겁니다. 프로그래머는 엔지니어지 사이언티스트가 아니지 않습니까? 실용성이 있는 무언가를 만들어야 하는 것이지요.. 실용성을 생각한다면 비용와 이윤의 트레이드 오프가 무시할수 없는 변수로 등장 하게 되구요..

제 결론을 말할까요? 고쳐야 되는 버그를 찾아서 고치자 하는 겁니다. 물론 자원이 허락하는한 모든 버그를 고쳐야 하죠. 개선의 여지가 있는 모든 로직을 개선해야 하구요.. 하지만 때로는 포기할 줄도, 기약없지만 미룰 줄도 알아야 한다는 겁니다.

프로그램을 짜던 중 어떤 버그를 발견했습니다. 참으로 어처구니가 없는 일이었죠. 절대 일어날수 없는 입력값이 입력된겁니다. 심심해서, 또는 테스트 프로그램이 잘못 설정되는 바람에 그런 입력값을 주기도 어려운 입력값을 주게 된 것이죠. 이를테면 106키보드에서 358개의 키가 동시에 눌러졌다던지, 마우스 포인터의 좌표가 (-103.5, -87.3)이 되었다던지.. 웹서버에 전송할 HTTP Request 객체를 생성하고 소켓을 열기도 전에 Ethernet드라이벗로부터 HTTP Response가 수신되었다던지.. 상식적으로 일어나지 않을 거라고 확신이 드는 그런 입력값 말이죠.. 그랬더니 원래 의도했던 다이얼로그가 뜨지 않는겁니다. 물론 다시 버튼을 클릭 한번만 해 주면 이전의 이상한 입력값은 깨끗이 무시되고 의도한 다이얼로그가 뜨긴 합니다. 자.. 이 버그를 고쳐야 할까요? 장인정신이 투철한 개발자라면 예상치 못했던 입력값이 주어졌을 때, 예외상황을 선포하고 적절한 핸들링을 하기 위해서 말도 안되는 입력값을 상상력을 동원하여 재현해 보고 분석하여 몇가지를 무시한 결과로 다이얼로그를 보여주려고 할 겁니다. 유저는 입력이 이상했다는 것(노이즈가 개입되었을 수 있다는 것)은 전혀 느끼지 못한 채로 계속 프로그램을 작동 시킬 겁니다. 3일 밤을 꼬박 세워서 말이죠..

하지만 이런 종류의 버그에 대처하기란 쉽지 않습니다.
전세계에 배포하면 2억명의 고객에게 팔릴 이 제품에 대해, 107명쯤이 이 버그를 경험할텐데, 그중 92명은 버그를 눈치채지 못하고 버튼을 다시 클릭할겁니다. 15명은 뭔가 이상한 작동을 하는것 같다고 생각하지만 재현이 쉽지 않아 포기합니다. 하지만 개발자는 이 버그를 고치기 위해 불가능한 갖은 입력값을 프로그램에 던져보면서 모든 예외상황을 재현하려 애쓰면서 그에 적절한 반응을 보일수 있도록 코드를 수정할 것입니다. 3일 밤을 새면서 말이죠..
(사실 3일이면 다행이죠)
소프트웨어의 완성도는 고객에게 기업에 대한 신뢰를 높여준다지만, 이 버그가 수정된걸 눈치채고 역시 훌륭한 업체라고 생각하는 고객은 전 세계 2억명 고객중에 15명에 불과합니다. 어쩌면 이 15명 조차 못느낄 지도 모르죠..
15명에게 기업의 이미지가 매우 좋아졌지만, 소프트웨어의 신뢰도도 매우 높아졌지만, 15명의 충성도 높은 고객을 확보하였지만, 이 15명의 고객이, 프로그래머가 3일간 밤을 세우며 디버그 하는 바람에 출시가 일주일 늦어져 발생한 16억 3천만원의 매출을 올려주려면 정말 오래 걸릴겁니다.

예시가 적절치 못했을지도 모르겠습니다. 숫자도 제 멋대로 막 갖다 붙인겁니다. 하지만, “반드시 지금 고쳐야 하는 버그”와 “기회가 되면 고쳐야 하는 버그”는 구분할줄 알아야 합니다. 로또 1등을 19회 연속으로 맞아 앞으로 먹고 살 걱정 안하고 소프트웨어 공학의 발전과 자기 만족에만 인생을 쏟아부을 생각이 아니라면 말이죠..

버그대처와 관계되는 프로젝트 관리에 대해 이야기 하자면 끝도 없이 길어지겠지만 이미 스크롤의 압박은 충분히 만들었다고 생각되는군요^^; 다 써놓고 보니 어쩌면 비굴해 보일지도 모르는 글이지만 수정하지 않겠습니다. 비굴해지는 연습도 해봐야죠;;

이 글은 개발자로서의 저의 가치관에 대한 글입니다. 다음이 저희 회사라고 저와 입장이 같지는 않을수도 있습니다. 두달쯤 후엔 DNA에서 루미넌스를 볼수 없을지도 모른다는 말이죠..

ㅎㅎ 농담입니다

이올린에 북마크하기