프로그래머로 살기: 2006

2006년 12월 19일 화요일

"2006 강컴 어워드 선정도서" 클릭하세요 C# 2.0 프로그래밍 외.

<클릭하세요 C# 2.0 프로그래밍>이 강컴 어워드 선정 도서로 뽑혔습니다. 그동안 많이 읽어주시고, 공부해 주신 독자분들께 진심으로 감사드립니다. T-T

아울러, 새로 출간된 <클릭하세요 비주얼 C++ 2005>가 "강컴 강력 추천"도서로 선정되었습니다. 모두모두 감사드립니다~

2006년 12월 18일 월요일

"클릭하세요 비주얼 C++ 2005" 출간.

두두둥~ 드디어 출간됐습니다. 사실, 지난주에 출간되긴 했지만 이제야 온라인/오프라인 서점으로의 입고가 끝난 것 같습니다. 많이 많이 사랑해 주세요~~

예스24
강컴
교보문고
인터파크

2006년 12월 11일 월요일

The 2nd Puberty

사춘기에 하던 고민을 요즘 다시 하고 있습니다. 가령 "난 아직도 크고 있는 걸까? 더 자랄 수 있을까?"같은 것 말입니다. 물론, 이것은 제 키에 관한 것이 아닙니다. 제 전문성에 관한 것이지요. 이에 관련해서 다음 질문들도 떠오릅니다.

"뭘 해야 할까?"
"지금 하고 있는 공부가 내 미래에 얼마나 도움이 될까? 차라리 쉬는 게 낫지 않을까?"

옛날 같으면 어렸을 때부터 가업을 배워(우리나라의 경우에는 대부분 농사) 18세 정도가 되면 더 이상 평생동안 전문성에 관한한 더 배우지 않아도 됐지만, 현대 사회에서 그런 평생 밥그릇이 되어 줄만한 지식은 사라졌습니다. 지식 자체가 자신을 혁신하면서 변화하기 때문입니다. 열심히 쫓아가서 따라 잡았다 싶으면 세상은 이미 변화하고 있습니다.

제 예상이 맞다면, 아마 평생동안 이런 질문들에 답을 해 나가야 할 것 같습니다.

2006년 12월 7일 목요일

클릭하세요 C# 2.0프로그래밍 246p의 고양시 그림에 대한 저작권 공지

246p 예제의 다음 고양이 그림은 "라하늬(cat0084)"님의 저작물임을 알려드립니다.

2006년 12월 1일 금요일

MONO 1.2가 발표됐습니다. .NET Framework 1.1과의 호환을 지원하는 이 멀티플랫폼 닷넷 환경은 이제 닷넷 프레임워크 2.0과의 호환을 위해 발길을 나섭니다.
하지만 아쉽게도 MONO는 WCF, WPF, WWF와 같은 Windows Vista API를 포함하는 .NET Framework 3.0하고는 방향을 같이할 것 같진 않습니다. 만약 .NET Framework 3.0도 지원하게 된다면 Roadmap을 수정해줘야 개발자들도 안심하고 따라갈텐데요. (정작 저는 MONO로 개발하지 않습니다만. 헤헤)

p.s1 : 오늘부터 회사 워크샵이 있어서 1박 2일 일정으로 태안에 다녀옵니다.

신제품 아이디어 발표와 같은 시간도 있지만, 그 3시간을 제외하고는 다 노는 스케줄이라 그 시간을 때울 거리를 준비하는 게 저에겐 더 큰일입니다. 그래서 책을 한권 챙겨 갑니다. 화장실 갈 때마다 읽던 책인데 이번에 끝을 내려고요.

p.s2 : 탁상용 2007년 달력을 협력 업체가 보내왔습니다. 달력을 받으면 제일 먼저 하는 일 있죠? 휴일 확인하는 것. 2007년은 까---맣습니다. 까매요. 특히 구정이 압권인데, 토, 일, 월 휴일이더군요. 이 기쁜 소식을 저만 알고 있어서는 안될 것 같아 제 블로그를 찾아오시는 분들께 알려드립니다.

모두들 즐거운 주말 되세요.

2006년 11월 28일 화요일

투덜 투덜

어제는 아내와 함께 교보문고에 다녀왔습니다. 특별히 어떤 책을 사야겠다는 생각을 가진건 아니었지만, 서점에 도착하니 아내와 전 자연스럽게 각자의 관심사를 따라 각자 책을 둘러보게 됐습니다.

청소년 단체에서 일하는 아내는 역시 관심사가 아동/교육 도서와 수필집 쪽에 있더군요. 전 물론 컴퓨터 과학과 사회 과학 코너 쪽으로 발길이 향했지요. 하지만 다행히도 우리의 공동 관심사가 아주 없던 건 아니었습니다. 만화책 코너는 우리 부부를 하나로 묶어주는 큐피트였습니다.

한가지 재미있는 사실을 발견했는데, 세계화는 여행자의 짐가방의 무게를 줄여준다는 것입니다. 얼마전 뉴욕 맨해튼에 있는 (비교적)대형 서점에 갔다가 책을 많이 사오지
못하고 나와 미련이 많았었는데, 우리나라 서점에서도 그대로 그 책들이 다 있는 것이었습니다. 가격 차도 1~2불 정도밖에 안하니, 만약 그 때 그 책들을 모두 사 왔다면 애꿎은 짐가방 무게만 늘렸을 겁니다.

이 생각을 하며 외국 서적의 컴퓨터 과학 코너와 우리나라 서적의 컴퓨터 과학 코너를 비교해 보니 약간의 섬찟함을 느꼈습니다. 단단한 기초에서부터 고급 응용 분야에 이르는 책을 구비해 놓고 있는 미국과는 달리 우리 나라는 기초서 또는 바이블류의 사전 외에는 없었기 때문입니다. 기초서나 바이블류가 다를 바가 없는 것은 양이 아닌 그 내용의 깊이입니다.

전담 편집자와 해당 분야의 전문 감수팀이 개발자의 집필을 돕는 미국과는 달리, 한국은 개발자 혼자 컨텐츠의 구성부터 집필, 감수, 검증까지 하는 1인 특공대 체제로 일을 합니다.
잘 짜여진 축구 팀처럼 공격수는 저자가 맡고, 편집자는 미드 필더, 감수팀과 기타 디자이너, 마케터들이 수비수와 골키퍼를 맡으며 팀이 경기를 하는 것과 혼자서 수비수부터 공격수까지 하는 경기는 결과가 다를 수 밖에 없습니다.

그러고보니 소프트웨어 개발도 마찬가지군요. 아키텍트, 개발자, QA 등의 역할이 잘 정리되어 있는 서구의 소프트웨어 개발 문화와는 달리 한국의 대부분 업체에선 이 모든 것을 개발자 혼자 처리를 하는 분위기입니다. 아키텍트와 QA 역할에 대한 개념이 거의 없으므로 대부분은 개발자 역할 말고는 이들 역할에 소홀할 수 밖에 없습니다. 일이 많은 것이 문제가 아니라, 자신의 역할에 집중을 못하는 것이 문제입니다.

이야기가 좀 번졌네요. 잘 데이트를 해놓고 괜히 속이 상했네요. ^^
세상이 어찌 돼도 전 저대로 즐프하렵니다~

2006년 11월 23일 목요일

돌아왔습니다.

험한 뉴욕에서의 12일을 보내고 돌아왔습니다. ^^

지갑, mp3, 전화기 등등이 들어있는 가방을 JFK 공항에서 잃어버리는 사고를 당했음에도
잘 살아 돌아 왔습니다. 다행히 여권은 다른 가방에 챙겨놔서 더 큰 사고는 나지 않았습니다.

돌아와보니 쌓인 일이 장난이 아니군요. ^^ 이제 또 열심히 일을 해야겠습니다.
모두들 즐거운 하루 되세요~

2006년 11월 9일 목요일

다녀오겠습니다

내일(10일) 저녁 8시 비행기로 뉴욕으로 가서 22일 새벽에 돌아옵니다.
무슨 여행이냐고요? 일이 바빠서 신혼 여행을 짧게 다녀왔는데, 이제야 일이 어느 정도
정리돼서 제대로 다녀오려고 합니다.

제가 없는 동안 열심히 공부하시고, 그 사이 주시는 질문들은 제가 돌아와서 답해드리겠습니다.
가을이 늦게 온다 싶더니 갑자기 겨울이 찾아왔습니다. 건강 유의하시고, 돌아와서 뵙겠습니다.

- 박상현.

2006년 10월 30일 월요일

책 제목 : Visual C++ 2005 프로그래밍

책 제목이 결정 됐습니다. "Visual C++ 2005 프로그래밍"입니다. 분량은 약 550페이지가 조금 안될 겁니다. Visual C++ 서적 치고는 상당히 얇죠? 왜 이렇게 구성되었는지는 책을 보면 아시게 됩니다. ^^

집에 돌아가면 <Visual C++ 2005 프로그래밍>의 최종 교정본이 기다리고 있는데 퇴근하기가 싫군요. 교정에 대한 스트레스가 이만 저만이 아닙니다. (원래 인간공학적으로 사람은 search나 inspection과 같은 작업을 할 때 스트레스를 가장 많이 받게 되어 있긴 합니다.)

아무튼 이 가을에 또 하나의 열매를 맺게 됐습니다. 이 열매의 맛과 영양이 사람들을 유익하게 해야 할텐데, 어찌될지 궁금합니다. ^^

2006년 10월 25일 수요일

YES24에 등록된 서평입니다.

YES24에 등록된 서평입니다. 자세하고 진지하게 써주셨고, 게다가 아주 후~한 점수를 주셨습니다. ^^
그 밑에는 제목과 내용이 다른 또 하나의 서평이 있던데... 제목과 내용이 서로 다릅니다. ㅠㅠ(그 서평은 퍼오지 않았습니다.)

C# 으로 처음 프로그램 개발을 하고자 하는 분들에게 추천합니다.
꼬미 님 \| 2006-10-24 \| 책내용 책상태

C# 으로 처음 프로그램 개발을 하고자 하는 분들에게 추천해 드립니다.

지난 여름에 뜻하지 않은 일거리를 맡게 되었는데, 어떤 개발툴로 개발을 할까 고민하다가 선뜻 선택한 것은 C# 이었습니다. 그 동은 C# 은 이름만 들어보기만 했을 뿐(저는 PHP 웹 프로그램을 직업으로 하고 있습니다.), C++ 과 비슷한 프로그래밍 언어가 아닐까 생각하고 있었습니다. 해서 초보라는 자세에서 시작하기 위해 적당한 서적을 고르던 중 최근에 발간된 이 책을 접하게 되었습니다.

내용은 프로그래밍 초보가 읽기에 정말 적당한 수준으로 씌여져 있습니다. 기존에 C++ 이나 다른 언어를 해 봤던 경험이 있는 분이라도 이 책을 읽으므로 처음부터 다시 시작할 수 있습니다.

객체지향언어의 기본인 클래스라는 개념을 이해하고 계신 분이라면 책을 읽기가 훨씬 더 수월하지만, 그런 개념이 없는 분들이라도 충분히 이해하고 진행할 수 있는 내용으로 꾸며져 있습니다.

저는 이 책과 Visual Studio 2005 Express 버전의 공짜 개발툴 그리고 MSDN의 관련 자료를 참고하여 훌량한 어플리케이션을 2개월만에 작성을 하였습니다.

물론 개발 기반 도중에 막히는 부분이 많이 있었는데, 그 때 마자 책을 쓰신분에게 메일로 도움을 요청하였습니다. 메일 받으실 때 마다 친철하 답변 메일을 보내 주셨고, 또 관련 참고 자료도 알려 주시더군요.

C# 언어는 개발 향상성이 무척이나 띄어난 언어였습니다. 그런 언어의 진정한 맛을 아주 처음부터 느끼고자 하시는 분들께 추천해 드립니다

2006년 10월 23일 월요일

[공지]오타를 찾아주신 분들께 선물을 드립니다.

<비주얼 C# 2005 익스프레스로 배우는 C# 2.0 프로그래밍>오탈자 찾기 이벤트(?)에 함께 해주신 분들께 약속대로 소정의 선물을 보내드리겠습니다.

선물은 11월 말/12월 초에 출간될 <C++부터 시작하는 비주얼 C++ 2005>입니다. 홍보가 덜 된 때문인지 많은 분들이 함께해 주시진 못했지만, 오타를 열심히 찾아주신 두 분(현송님, 명준님)께 감사의 뜻으로 책을 보내드리겠습니다.

현송님의 연락처는 제가 알고 있으니, 명준님께서는 가장 마지막 오타 글을 수정하시어 이메일 주소를 남겨주시면, 제가 그 메일 주소로 연락을 드리겠습니다.^^

2006년 10월 19일 목요일

코드를 작성할 때에는...

"코드를 작성할 때에는 지금 작성하고 있는 코드를 당신의 연락처를 알고 있는 난폭한 살인마 프로그래머가 물려받을것이라고 생각하라."

이 말을 어디서 읽었는지는 기억이 나지 않는데, 요즘 들어 다시 생각하게 됩니다.

개발자의 성과물은 실행파일 바이너리가 아닌, 문서와 소스코드입니다. 바이너리는 소스코드를 이용해 뽑아내는 부가적인 산출물일 뿐입니다. 운동 선수가 몸을 제대로 만들지 못하면 경기 결과가 좋을 수 없는 것처럼, 좋은 소스코드 없이 좋은 소프트웨어가 나올 수는 없는 것입니다.

좋은 소프트웨어란, 사용자를 만족시키며 안전하게 돌아가는 소프트웨어입니다. 당장 키보드를 잡고 씨름하기 전에, 내가 구현할 내용을 정리해 보고 소스 코드가 어떻게 읽기 좋은 구조로 구성될 수 있는지를 생각해 보세요. 그리고 내 소스 코드를 물려받는 살인마 개발자가 기분 좋게 나를 다른 프로젝트로 보내줄 수 있을지도 생각해 보시기 바랍니다. ^^

2006년 10월 2일 월요일

즐거운 추석 보내세요 ^^

어떤가요, 새 디자인이?

추석을 맞아 새 스킨을 깔아봤는데 느낌이 좋네요(ㅋㅋ). 사실 스팸 댓글 방지 플로그인을 설치하려고
태터(제 블로그 소프트웨어입니다.)를 업그레이드 했는데 떡 본 김에 제사 지낸다고,
스킨도 새로 깔았습니다. ^^

드디어 추석 연휴의 시작입니다. 다들 가족들 만나뵐 기대에 차 계시겠네요 ^^
푹~~~ 쉬시고, 몸도 마음도 가득 충전해서 돌아오시길 바랍니다.

2006년 9월 28일 목요일

비교에 대하여.

오랜만입니다. 이 핑계 저 핑계로 약속했던 연재가 늦어졌습니다. 이번엔 "비교"에 대해 이야기해 보죠. 수(數)의 비교에 대해선 우린 이미 잘 알고 있으니 문자열의 비교에 대해 이야기해 보겠습니다.

C#에서 문자열을 다루는 자료형인 string 클래스가 제공하는 문자열을 비교하는 방법에는 크게 다음 세가지가 있습니다. (더 있긴 하지만 이 세 가지를 이해하면 문자열의 비교에 관한 거의 모든 것을 할 수 있기 때문에 이 정도로 제한하겠습니다.)

1. Equals() 메쏘드
2. 비교 ( ==, != ) 연산자
3. Compare() 몌쏘드 (정적 메쏘드)

위 세가지 메쏘드가 비슷한 일을 하긴 합니다만, 각자 적절한 용도가 따로 있습니다.

Equals() 메쏘드도 두 문자열이 같은가/다른가를 비교해서 true/false를 반환합니다만, 옵션을 조금 줄수 있습니다. 예를 들어 대/소문자를 무시하고 비교할 것인지, 어떤 문화권의 문자열 비교를 수행할지 등을 옵션으로 넣어 사용할 수 있습니다.

string A = "ABC";
string B = "abc";

Console.WriteLine(A.Equals(B)); // false
Console.WriteLine(A.Equals(B, StringComparison.OrdinalIgnoreCase)); // true

다음은 비교 연산자를 이용한 비교입니다. C/C++ 프로그래밍 경험이 있던 분들은 뭔가 이상하다고 생각할 것입니다. "어떻게 비교 연산자가 문자열을 비교하는데 사용될 수 있지?"하고 말이죠. 여기에 무슨 마법이 있는 것은 아닙니다. 비교 연산자들을 오버로딩해서 문자열이 위치하는 메모리 주소가 아닌 "값"을 비교하도록 한 것뿐이니까요.

== 연산자는 문자열의 같은가/다른가를 단순 비교합니다. 같으면 true를 반환하고 다르면 false를 반환하지요. 예는 다음과 같습니다.

string a = "ABC";
strinb b = "CDE";

Console.WriteLine(a == b); // false

!= 연산자는 == 연산자의 반대 값을 반환한다는 것은 우리 모두 알고 있죠? 위 코드에서 a==b 대신 a!=b 를 입력하면 true가 출력됩니다.

Equals() 메쏘드와 비교 연산자를 이용한 문자열의 비교에 대해서는 이 정도로 마무리 하려 합니다. 제가 이야기 하고 싶은 부분은 사실 이 두 방법이 아니라 마지막 방법인 Compare() 메쏘드입니다. 그래도 마음이 동하는 분들은 코드를 직접 짜서 테스트를 하면서 더 연구해 보세요. :

Compare() 메쏘드는 다양한 비교 옵션을 제공하며, 비교 결과 또한 같다/다르다를 넘어서 작다/크다/같다로 세분화 됩니다. 그래서 반환형도 int 형이죠. string 클래스의 인스턴스보다 비교할 문자열이 크면 0보다 큰 값을, 같으면 0을, 그리고 작으면 0보다 작은 값을 반환합니다. 단, 이 메쏘드는 static으로 선언되었기 때문에 인스턴스 레벨에서 사용할 순 없고 클래스 레벨에서 호출해야 합니다. (인스턴스 레벨에서 제공하는 CompareTo() 메쏘드가 있습니다만, 이것과 Compare() 메쏘드는 다릅니다. CompareTo() 메쏘드는 작다/크다/같다의 결과를 반환하긴 하지만 기능 자체는 앞에서 소개한 두 메쏘드와 큰 차이가 없습니다.)

호오, 문자열 사이에 작다/크다의 개념이 있을 수 있나? 그럼 "abcde"가 "abc"보다 크다고 할 수 있는 걸까? 이것은 사실 문자열의 길이나 크기 따위의 문제가 아닙니다. 사전적 순서가 앞에 오느냐 또는 뒤에 오느냐에 따라 결정되는 문제죠. 사전적 순서로 따져서 앞에 오면 작다라고 판정되고 뒤에 오면 크다라고 판정되는 것입니다. 예를 들어 "abc"는 "abcde"보다 사전적으로 앞에 오므로 작다고 판정됩니다. 다음과 같이 말이죠.

string A = "abc";
string B = "abcde";

Console.WriteLine(String.Compare(A, B)); // -1 출력, 즉 "abc"는 "abcde"보다 작다.

이해 되시죠? 이러한 문자열의 사전적 순서에 근거한 비교를 사전적 비교(Lexical Comparison) 이라고 합니다.

이렇게 해서 Equals() 메쏘드, 비교 연산자, Compare() 메쏘드 세가지 방법을 이용한 문자열의 비교에 대해 알아봤습니다. 이 정도를 알면 C# 프로그래머가 알아야할 문자열의 비교는 안다고 할 수 있습니다.

하지만 여기에서 조금만 더 같이 생각해 보죠. 유럽 언어들은 대부분 로마자(Roman Alphabet)에 기반안 언어 체계를 갖고 있습니다. 얼핏보면 "어, 다 알파벳이네?"하는 생각이 들 정도로 비슷하지요. 하지만 각 나라마다 차이가 다 있습니다.

예를 들어 ch가 영어에서는 두 글자지만, 체코에서 ch는 한 글자로 사용됩니다. 헝가리어에서는 CS, DZ, DZS … 등 두 문자 이상이 합쳐져 한 문자를 이루기도 합니다. 이런 경우 문제가 생기기도 합니다.

예를 들어 헝가리에서 SI 프로젝트를 수주 받아 개발을 진행하고 있다고해 봅시다. 시스템 설계를 하다가 코드 테이블을 만들어야 할 필요가 생겼고, 그래서 두 글자의 약자로 이루어지는 코드 시스템을 만들고 이를 데이터베이스에 넣었습니다. 가령 Computer Science는 CS, Communication Technology는 CT 와 같이 말이죠.

그래서 만들어진 코드는 다음과 같습니다.

AT, BT, CS, CT, IE

GUI에서는 이 값을 읽어 정렬한 후 화면에 사용자에게 표시하는데, 한가지 이상한 점이 발견됐습니다.

AT, BT, CT, CS, IE 로 정렬이 되는 겁니다. 왜 CT와 CS가 바뀌는 걸까요? 우리는 영어를 기준으로 코드를 만들었지만 CS는 헝가리어에서 C 다음에 오는 단일 문자이기 때문입니다. 그래서 CT가 CS보다 작다고 판단돼서 CS보다 앞에 오는 것이죠.

이 문제를 위해 .NET 프레임워크는 String.Compare() 메쏘드에 CultureInfo 클래스를 매개 변수로 받도록 설계했습니다. CultureInfo 클래스는 생성자의 매개 변수로 문화 이름(Culture Name)을 문자열을 받습니다. 이 문화 이름은 RFC 1766 에 따라 명명 되며, <언어-국가>의 형식으로 되어 있습니다. 언어-국가의 형식으로 이름이 구성되는 것은 한 언어를 여러 나라에서 사용하는 경우가 많기 때문입니다. 스페인어는 스페인 뿐 아니라 남미의 아르헨티나, 파라과이, 페루, 멕시코 등에서 사용하고 있지요. 독일어도 독일 뿐 아니라 스위스, 오스트리아에서 사용합니다. 영어 또한 마찬가지고요. 국가별 영어의 문화 이름 예는 다음과 같습니다.

en-US : 영어-미국
en-GT : 영어-영국(Great Briton)
en-PH : 영어-필리핀

우리가 앞에서 예로 들었던 헝가리-헝가리어의 CultureInfo 이름은 <hu-Hu>입니다. 아래의 코드를 실행해 보면 String.Compare() 메쏘드가 반환하는 값이 다름을 알 수 있습니다.(한번 해보세요!)

string a = "CS";
string b = "CT";
Console.WriteLine(String.Compare(a, b, false, new CultureInfo("en-US"))); // 미국-영어
Console.WriteLine(String.Compare(a, b, false, new CultureInfo("hu-HU"))); // 헝가리-헝가리어

참고로, CultureInfo 클래스는 문자열의 비교 뿐 아니라, 날짜, 주소, 통화, 숫자의 Formatting에도 사용됩니다. 잘 알아 두세요.

오늘의 이야기는 여기서 끝입니다. 조금은 도움이 되었기를 바랍니다.
다음에는 Endian에 대해 이야기 해보겠습니다. 다음이 언제가 될진 모르겠지만요 ^^;

2006년 9월 14일 목요일

"비교에 대한 이야기"를 삭제했습니다. 다시 올릴 예정입니다.

블로그는 가볍게 글을 올릴 수 있다는 장점도 있지만, 출판물에 실리는 글에 비해 오랜 기간 검증을 하지 않기 때문에 조금 내용이 가벼운 면이 있습니다.

비교 포스트를 삭제한 것은 새로 작성하기 위해서입니다. 비교 연재를 만들다보니 전 연재의 문제가 발견되더군요.
언젠가(?) 다시 글을 수정해서 올리겠습니다. 양해를 부탁드립니다. ^^;;

2006년 9월 4일 월요일

클릭하세요 C# 2.0 프로그래밍 정오표

<비주얼 C# 익스프레스로 배우는 클릭하세요 C# 2.0>의 정오표를 만들었습니다.

본 포스트에 첨부된 파일을 다운 받아 사용하시면 됩니다.

이제 2학기가 시작됐습니다. 모두들 "열공"하시고, 이 가을이 끝날 무렵에는
모두들 보람의 열매를 수확하시길 바랍니다. ^^

그럼 즐프하세요~

2006년 8월 24일 목요일

Phoebe

요즘 또 미친듯이 일하고 있습니다.
또.. 컨디션이 나빠지고 있습니다. 페이스를 잃지 않으려고 노력은 하지만 쉽지 않네요.
(몸이 나빠지는 건 회사 탓도 아니고 순전히 제 탓이죠. 적당히 일을 하든, 근무 환경이 좀 다른 곳으로 옮기든 제가 선택할 수 있는 길이 있음에도 이렇게 하는 거니까요.)

이 와중에도 식사 후 산책은 반드시 하고 있습니다. 근자에는 새벽 시간을 글을 다듬는데 쓰고 있기 때문에 산책 시간이 유일한 사유(思惟)시간이 됐습니다.

지금 진행중인 프로젝트와 출판이 마무리되는 11월이 지나가면 구체적으로 뭘 할 것인지를 생각하고 있는데, 떠오르는 게 없습니다. 막연하게 개인적인 프로그램을 만들고 싶다는 생각만 하고 있죠.

개인적인 업무 프로세스를 처리하는 오피스 프로그램인데, 이름을 지으려 했더니 프로그램의 용도에 피(Personal) 비(Business)라는 단어가 들어가서 그냥 지금은 피비(Phoebe)라고 임시 이름을 붙였습니다.

Phoebe를 만들지 어떨진 모르겠지만, 이렇게 아이디어를 뽑아내고 이걸 기반으로 이것 저것 생각을 하는 것도 꽤 재미있군요.

2006년 8월 17일 목요일

I'm back.

휴가에서 돌아왔습니다.

어제 하루 휴가를 내고 15일 공휴일이랑 붙여 연휴를 만들었는데, 어제 저녁 8시에 사무실에 들어갔습니다. 팀에서는 마침 발생한 "상황"에 대해 대책을 마련중이었습니다. 저는 잠깐 들렀다 나올 계획이었는데 불을 끄고 나오니 10:30이 됐습니다.

숙소에 도착해서는 프린트해 놓은 VC++ 원고를 읽어봤습니다. 여독이 미처 풀리지 않은 상태였지만, 잠은 오지 않고 그걸 읽지 않으면 TV를 킬 것 같아서 어쩔 수 없었죠. 원고를 읽어나가다 보니 빨간 펜을 집어들지 않을 수가 없더군요. 1장를 손보고 나니 잠이 와서 그대로 누웠습니다.
글을 써 놓고 오랫동안 묵혀뒀다가 다시 꺼내보면 새롭게 보인다는 사실을 느끼게 됐습니다. 출판사로 원고를 넘기고 교정본을 받은 후 지금까지 몇주가 지났는데, 각 장의 머리글을 써 넣은 것 말고는 원고를 읽어보는 일은 없었거든요. Stephen King이 On Writing(아주 재미있습니다. 관심 가는 분은 꼭 읽어보세요.) 에서 자신이 쓴 글을 6주간 묵혀놓고 다시 읽어보라는 이야기를 했는데, 의도한 것은 아니었지만 효과가 아주 좋습니다.

일거리가 늘어나긴 했어도 그대로 인쇄되지 않고 내 손에서 다시 한번 더 다듬어질 수 있게 되어 다행입니다.

2006년 8월 14일 월요일

휴가 다녀오겠습니다~

오늘 저녁부터 수요일까지는 조용한 곳에서 쉬고 돌아올 계획입니다.

질문답변란에 답변이 조금 늦어지더라도 양해 부탁드립니다.

일을 하는 것도 스트레스지만, 한참 바쁘게 돌아가는 회사 일을 잠시 쉰다는 것도
또 하나의 스트레스로 다가오네요. 쉬는 데 스트레스를 다 받다니.. "이건 아냐"라는 감이 막 오고 있는 중입니다.(IT 업계 종사자들이 다 이렇게 살아간다고는 하지만, "그래, 이거야"라고 할만한 삶은 또 아닙니다.)

신성한 휴식, 잘 누리고 돌아오겠습니다.

추신 : "비교"는 언젠가 완성할 겁니다. 완성하고 말고요. 그리고 "엔디안"도 그렇게 할겁니다.

2006년 8월 11일 금요일

노래:당신은 사랑받기 위해 태어난 사람.

보이처라는 아카펠라 그룹이 부른 "당신은 사랑받기 위해 태어난 사람"입니다.

교회에서 합창하는 학생들과 함께 연습해서 부르고 싶은 곡이었는데 아직까지 덤비지도 못했습니다. ^^;
어려운 곡이긴 하지만, 너무 화음이 잘 어우러지는 아름다운 노래입니다.

(컨트롤을 활성화 시켜서 재생하면 음악이 나옵니다.)

언젠간 부르고 말겁니다.

2006년 8월 4일 금요일

무지개

작년 이맘때 쯤에 찍었던 무지개입니다.
엄청나게 컸었는데, 카메라 폰의 렌즈 안에 다 들어오지 못하더군요 ^^;

아주 가까이에 크고 예쁘게 뜬 무지개라서 아쉬운대로 핸드폰으로 찍었습니다.
먹구름이 덮고 있는 하늘에서 비가 쏟아지던 중에 잠깐 나타난 무지개라 더 인상이 깊었습니다.
"시련 뒤에 얻는 기쁨에 대한 희망"을 연상케 하는 장면이었습니다. 핸드폰을 정리하다가 발견하게 되어 올립니다. ^^

2006년 8월 2일 수요일

근황.

오늘은 출판사로부터 교정이 끝난 원고를 돌려 받았습니다. 이제 제가 다시 검토를 해서 출판사에 넘기면 책이 예쁘게 편집되기 시작할 겁니다.

VC++ 2005 출판 일정도 지켜야 하고, 결정해야 하는 인생의 사안들도 있어서 그나마 아껴 쓰던 새벽-아침 시간이 남아나질 않네요 ^^;;

과연 다음 연재는 언제 올릴 수 있을런지 ㅋㅋㅋ

2006년 7월 27일 목요일

오타를 수배합니다~

드디어 재고가 소진된 "클릭하세요 C# 2.0 프로그래밍"이 재판에 들어갑니다.

책을 읽으시면서 발견한 오타, 오류등을 이 포스트의 댓글이나 제 메일(steelblue@nate.com)로 보내주시면 이번 재판에 반영하려고 합니다. (댓글에 올려주시면 다른 분들도 보실 수 있으니 메일보다는 가급적 댓글을 이용해 주시기 바랍니다.)

오타를 많이 발견해서 보내주신 분께는 소정의 선물을 보내드리겠습니다. ㅋㅋ

"클릭하세요 C# 2.0 프로그래밍"을 사랑해 주신 모든 독자분들께 감사드립니다.

그럼 즐프~

2006년 7월 25일 화요일

실력 유지 6시간, 실력 향상 10시간.

얼마 전 한국을 방문하신 러시아의 한 피아니스트로부터 이야기를 들었습니다. 쌩 빼쩨르부르크 음악원의 피아노 교수님이신데, 지금도 실력을 유지하려면 6시간, 실력이 늘려면 10시간은 연습해야 한다고 하시더군요.

그래서 아무리 바빠도 최소한의 실력을 유지하기 위한 연습시간은 꼭 지키신답니다. 그 이야기를 듣고 조금 충격을 받았습니다.
그런 "대가"도 실력을 유지하기 위해서 저런 노력을 기울이는데 나는 혹시 멈춰 서 있지는 않는가? 봐야하고 공부해야 할 책도 많은데 왜 이렇게 게으른가? 하는 생각도 좀 들었고요.

요즘 유행하는 말마따나 "열공(열심히 공부하다)" 해야겠습니다. ㅋㅋ

2006년 7월 20일 목요일

C#과 떠다니는 소수점 이야기[3]

오래 기다리셨습니다. 아니, 아무도 안 기다리셨으려나? 뭐, 상관 없습니다. 저는 꿋꿋이 글을 써 나가겠습니다.

이제는 우리가 C# 코드에서 부동 소수점 자료형을 사용할 때 생각해야 하는 부분들에 이야기하려 합니다. 이것들은 C# 뿐 아니라 IEEE 754 규격을 따르는 모든 시스템에 해당 되는 내용입니다.(대체 어떤 이야기길래?)

float a = 0.1f – 0.2f;

위 코드에서 a는 얼마가 될까요? 당연히 -0.1이겠지요? 그럼 다음 코드를 봅시다.

float b = 43.1f - 43.2f;

위 코드에서 b는 얼마가 될까요? 하핫, 여러분을 바보로 아냐고요? 아 죄송합니다. 제가 바보 같은 질문을 했습니다. 그럼 다음 코드를 작성해서 한번 실행해 보시기 바랍니다.

using System;

class FloatEx01

{

static void Main(string[] args)

{

float a = 0.1f - 0.2f;

Console.WriteLine(a);

PrintOutInHex(a);

float b = 43.1f - 43.2f;

Console.WriteLine(b);

PrintOutInHex(b);

}

private static void PrintOutInHex(float value)

{

byte[] bytes = BitConverter.GetBytes(value);

foreach (byte b in bytes)

{

Console.Write("{0:X2} ", b);

}

Console.WriteLine();

}

결과 :

-0.1

CD CC CC BD

-0.1000023

00 CE CC BD

“오, 이런. 이게 무슨 일이지! 내가 프로그래밍 언어를 잘못 선택한 게 아닌가?!”. 진정하세요. 이것은 IEEE 754를 따르는 모든 시스템에서 나오는 문제입니다.

앞에서 설명한 것처럼 2진수로는 소수를 모두 표현할 수가 없습니다. 예를 들어 0.1을 이진수로 바꾸면 0.00011001100… 의 순환 소수가 되지요. 게다가 우리는 한정된 비트 안에 이 수를 표현해야 하므로 비트 크기를 벗어나는 나머지 수들은 저장되지 못하게 됩니다. 그렇다고 나머지 수들을 버릴 수도 없기에 이 값들을 “반올림”해서 저장합니다. 따라서 우리가 얻을 수 있는 것은 “정확한”이 아닌 “가까운” 값 뿐입니다. 이로 인해 위와 같은 현상이 나타나는 것이죠. 이것을 “반올림 오류(round off error)”라고 합니다.

이를 어찌해야 할까요? 위 예제 코드에서 float으로 사용된 변수를 double로 바꿔 보면 오차가 훨씬 줄어드는 것을 확인할 수 있습니다.

0.1

9A 99 99 99 99 99 B9 3F

0.100000000000001

00 9A 99 99 99 99 B9 3F

그래도 여전히 오차가 존재합니다만, 이 정도면 그래도 꽤 쓸만해 졌습니다. double 형은 64비트(8바이트)의 자료형으로써 11비트의 지수부와 52비트의 가수부로 이루어져 있기 때문에 float 보다 정확한 값을 나타낼 수 있습니다.

double은 8바이트 자료형이니 float 보다 느려지지 않겠냐구요? 두 자료형의 처리 속도는 거의 차이가 없습니다. 메모리를 두 배나 사용하긴 하지만 여러분의 프로그램이 동작해야 하는 PC가 충분한 메모리를 갖고 있다면 double을 사용하는 것이 정신 건강에 이로울 것입니다.

다만, 여전히 아래의 코드는 여전히 실망스러운 결과를 낳죠. “not equal”을 출력합니다.

double a = 0.2 - 0.1;

double b = 43.2 - 43.1;

if (a == b)

Console.WriteLine("equal");

else

Console.WriteLine("not equal");

부동 소수점 자료형을 직접 비교한다는 것은 위험한 일입니다. 정 비교가 필요하다면 오차 허용치를 이용하여 근사값끼리 비교하는 방법이 있습니다. 아래와 같이 말이죠.

const double EPSILON = 0.0001; // 허용오차

private bool isEqual(double x, double y) // 비교 함수.

{

return (((x - EPSILON) < y) && (y < (x + EPSILON)));

}

// …

if (isEqual(a,b))

Console.WriteLine("equal");

else

Console.WriteLine("not equal");

컴퓨터가 소수 하나도 정확하게 처리를 못한다는 것은 정말 슬픈 일입니다. 그러나 이것은 현재 CPU의 구조상 어쩔 수 없는 일입니다. 우리가 할 수 있는 것은 최대한 정확하게 데이터를 처리하기 위해 float 대신 double을 사용하는 것과, 이 오류와 관련해서 생길 수 있는 프로그램의 영향을 줄이는 것뿐입니다.

하지만 C#은 또 하나의 해결책을 제시합니다. 바로 decimal형입니다. 이 자료형은 부동 소수형이 아니며, 29 자리수의 수를 지원합니다. 소수점은 29자리 안에서 이동합니다. 반올림 오류가 일어나서는 안 되는 재부/금융/회계 분야에 적합한 자료형입니다. 다만 그 크기가 16바이트나 되고 부동 소수점 자료형보다 속도가 훨씬 느리다는 단점이 있습니다. 이러한 Trade-Off는 어쩔 수 없습니다. 정확한 계산을 위해서라면 속도와 메모리는 조금 희생해야죠. ^^;

자, 이렇게 해서 부동 소수점에 대해 이야기를 나눠봤습니다. 역시나 재미가 없죠? 다음에는 비교에 대해 이야기를 해볼까 합니다. 그럼 즐프하세요~

(이 포스트는 추후 수정될 수도 있습니다.)

2006년 7월 13일 목요일

준비해야 할 포스트..

1. 떠다니는 소수점 이야기.. 완결편
2. 비교에 대하여.
3. Endian에 대하여.
4. 그 담은 계속 생각해 보겠음...

... 출판을 목적으로 하고 있진 않지만, "클릭~ C# 2.0" 돌자들이 "내공"을 다질 수 있는 내용으로 하려고 합니다.

외공 중심의 무술은 일단 당장 실전에 사용이 가능하고 빠른 시간 안에 일정 수준까지 올라갈 수 있다는 장점이 있지만, 내공 중심의 무술은 성장이 느린 반면 어느 수준에 이르면 외공 중심의 무술보다 더 강하다죠... (이건 무협영화를 보면서 내린 결론입니다. 믿거나 말거나 ㅋㅋ)

당연히 재미는 별로 없을거라 생각하지만 연재 주기가 일정치 않고 업데이트가 매우 느리므로 공부하는 데에도 부담이 없으리라 봅니다.(음.. 단점을 마치 장점처럼..)

원래 오늘 부동 소수점 이야기를 올리려 했는데 주 초부터 철야를 하는 바람에 늦잠을 자서 못 올렸습니다.
그래서... 쓸데 없는 이야기를 좀 끄적였습니다. ^^;;

좋은 하루 보내세요!

2006년 7월 11일 화요일

MBTI 유형 검사 결과

MBTI 유형 검사를 해봤더니 전 ENTJ형이랍니다. 난 이게 무슨 "혈액형별 성격"같은 건 줄 알았는데, 좀 다르군요. 사람의 성격을 잘 반영하는 것 같습니다.

ENTJ 유형의 사람들은 일반적으로 책임을 받아들이고 문제를 직접적으로 다루며, 특히 혼란이나 비효율성과 관련된 상황에서 직접적으로 문제를 처리한다.

이들은 자신이 속한 조직체에 구조를 제공하며 자신의 개인적인 목표와 자신의 속한 조직의 목표를 달성하기 위해 전략들을 고안해 낸다.

이들은 광범위하고 행동지향적인 계획들을 전개하며, 이러한 계획들이 완성될 때까지 필요한 에너지와 힘을 제공한다. ENTJ 유형의 사람들은 "책임을 지는" 사람들이며 자신 뿐만 아니라 다른 사람들의 외부 환경까지도 조직화하는 사람들이다.

이들은 "아니오"라는 대답을 하지 않는다. 그 대신 이들은 그런 도전을 극복할 수 있는 방식을 찾기 위해 자신이 지니고 있는 모든 정보나 자원들을 활용한다.

이들은 자신이 지닌 분석적이고 전략적이 사고과정을 사용할 수 있는 사용함에서 최상의 능력을 보인다.

단점 역시 존재하는데

* 요구하거나 비판적이거나 협박할 수 있다.
* 일을 삶의 다른 부분에까지 옮겨놓을 수 있다.
* 성급히 결정하느라 중요한 사실과 세부사항을 간과할 수 있다.
* 다른 사람의 투입과 공헌을 요구하거나 허용하지 않을 수 있다.

라는 군요.. -.-; 장점들은 "오, 그렇지. 나랑 일치하잖아"라면서 받아들이면서 단점들은 받아들이기가 힘들군요 ^^;; 단점 역시 그런대로 제가 생각하던 제 단점이랑 일치하는 것으로 보입니다.

이 결과가 실제의 나라고 하더라도 "난 이런 사람이야" 라고 이 검사결과를 받아들이기 보다는 변해가는 과정중에 있는 한 때의 캐릭터로 받아들이려 합니다. 10년 전의 나는 지금의 내가 아니었던 것처럼, 앞으로 5년 후 10년 후엔 지금의 나와는 다른 모습을 가질 수도 있을 것이기 때문입니다.

지금도 한창 클 나이이므로.. ㅋㅋㅋ

2006년 7월 9일 일요일

C#과 떠다니는 소수점 이야기[2]

이제 제가 하고자 하는 이야기를 할 수 있게 됐습니다.

C#이 제공하는 float과 double 부동 소수점 자료형은 IEEE 754 규격을 따릅니다. IEEE 754가 뭔고 하니, 4바이트(32비트) 맟 8바이트(64비트)를 이용하여 부동소수점을 표현하는 방식을 IEEE라는 기관에서 정의한 규격입니다.

이 규격에 따르면 부동소수점은 부호 비트, 지수, 가수로 나누어 표현되며, 4바이트 부동 소수점의 경우 아래의 그림과 같이 부호가 1비트, 지수가 8비트, 가수가 23비트를 사용합니다.

(그림 1 : 32bit 부동 소수점 자료형의 구조)

부호 비트는 수가 음수인지 양수인지를 구분하기 위해 사용합니다. 0이면 양수, 1이면 음수죠. 지수는 소수점의 위치를 가리키기 위해 사용되고, 가수는 정규화된 값이 담깁니다.

좀 어렵죠? (예, 사실 머리에 쏙 들어오는 그런 내용은 아닙니다. 하지만 이 규격을 만든 사람들도 고민을 엄청나게 많이 했습니다. 공부하는 우리는 고생이 덜한 편이라는 것에 위안을 가집시다.)

부호 비트는 명확하니 설명이 더 필요 없을 것 같고, 지수와 가수에 대해 이야기를 좀 해보겠습니다.

우선 가수에 대해 생각해 봅시다. 2진수는 항상 1로 시작합니다. 1001, 11, 1111, 111111 등등… 확실히 2진수는 0으로 시작할 수는 없습니다. 10진수나 16진수라면 경우의 수가 많아지지만 2진수는 0이 아니면 1이기 때문에 항상 1로 시작된다는 것을 확신할 수 있습니다.

그래서 가수부의 비트에는 시작하는 1을 제외한 나머지 값만 저장됩니다. 이것으로 23비트만으로 24비트를 담는 효과를 내게 해 주죠. 한편, 가수는 1.xxxxxxx의 값으로 저장됩니다. 예를 들어 11.11의 2진수는 가수부에 1.111로, 101.01은 1.0101로 저장됩니다.
시작하는 1을 제외한 나머지 값만 담기므로 가수부의 비트에 담기는 값은 11.11의 경우는 .111, 101.01의 경우는 .0101만 담기게 됩니다. 이 과정을 일정한 형식으로 바꾸는 “정규화(normalization)”라고 합니다.

예를 들어 7.25를 정규화하여 가수 비트에 담아봅시다. 7은 2진수로 111, 0.25는 0.01이니 합치면 111.01이 됩니다. 이를 정규화하면 1.1101이 되죠. 시작되는 1은 제거하고 담는다고 했죠? 그럼 1101만 가수 비트에 담으면 됩니다.

(그림 2: 저장된 가수의 모습)

이렇게 해서 가수를 담았습니다. 그런데 소수점의 위치는 상실했습니다. 7.25는 111.01(2진수)인데, 1.1101로 저장됐으니 어떻게 이를 복원하죠? 이 문제를 위해 지수가 사용됩니다. (지수가 여자 이름이 아닙니...... 쿨럭;)

지수는 수의 규모를 파악하는 데 유용하게 사용됩니다. 예를 들어 10진수의 경우 72.18 * 10²은 7218이 되고, 2진수의 경우 1.01 * 2²은 101이 됩니다. 앞서 잃어버린 소수점의 위치는 이러한 지수의 속성을 이용하여 되찾을 수 있습니다.

한편 지수가 담기는 비트 역시 성능을 위한 고민의 산물입니다. 32비트(4바이트) 부동 소수 자료형의 경우 지수는 −126 부터+127 까지의 값을 가질 수 있는데, 2의 보수로 이 값을 표현하면 비교 연산이 엄청 복잡해 집니다(이미 부호가 있는 자료형 안에 또 부호가 들어가 있습니다. 게다가 이 값은 지수라구요.) 연산이 복잡해지면 성능 또한 저하되는 것은 자명하지요.
그래서 지수도 실제 값에 127을 더해 저장하는 바이어싱(biasing)을 사용합니다. 결국 지수부에 담기는 비트에는 0보다 큰 양수만 담깁니다.

조금 전에 7.25의 가수를 비트에 저장했었는데, 이번에는 지수를 담아보겠습니다. 7.25의 2진수 111.01은 1.1101 * 2²로 표현할 수 있으니, 지수는 2입니다. 그런데 실제로 비트에 담을 때는 지수에 127을 더하므로 129를 저장하면 됩니다. 129를 2진수로 변환하면 10000001이 되고 이를 지수 비트에 저장하면 다음과 같습니다

(그림 3: 저장된 지수와 가수의 모습)

7.25의 부호 비트 값은 0이므로 7.25가 float 에 담긴 비트의 모습은 최종적으로 다음과 같습니다.

(그림 4: 7.25가 32비트 부동 소수형 비트에 저장된 모습)

제대로 저장됐는지 확인해 볼까요? 저장된 비트 값을 다음 공식을 이용하여 복원해 보면 됩니다.

(-1)^부호 * 2⁽^지수^–¹²⁷⁾ * (1+가수) = 1 ⁰* 2⁽¹²⁹^–¹²⁷⁾ * (1+0.1101) = 111.01(2진수) = 7.25(10진수)

이렇게 해서 IEEE 754 규격에 대해 알아봤습니다. 아직 C# 코드는 한 줄도 안 나왔는데 엄청 이야기가 길어졌습니다. 남은 이야기는 다음 포스트에 계속됩니다. ^^

( 이 포스트는 추후 수정될 수 있습니다.)

2006년 7월 7일 금요일

우연히 검색하다가...

오늘 뭔 기대를 했는지 몰라도 네이버에서 제 이름 "박상현"으로 검색을 해봤습니다. 밑에 보니 "클릭하세요 C# 2.0 프로그래밍"이 이더군요. 클릭해서 들어가 봤드니 7월 1주 C# 분야 1위에 올라 있더군요. 이런 영광이..ㅠ,ㅠ

원래 순위라는 게 올라갔다가도 얼마든지 내려갈 수 있기 때문에 얼른 캡쳐해서 가져왔습니다. 1위에 랭크된 것 보다도 이런 희귀한(?) 장면을 캡쳐할 수 있었다는 게 너무 기분 좋았습니다. ㅋㅋ

좋은 주말 보내세요~ ^^

2006년 7월 6일 목요일

C#과 떠다니는 소수점 이야기[1]

"C#의 음수 표현 방식에 대한 이야기"를 읽어본 독자들은 1바이트에 담긴 아름다움을 느끼실 수 있었으리라 생각합니다. (안 읽어봤다면 읽어보세요 클릭!)

이번에는 float과 double과 같은 부동 소수점(Floating Point) 자료형이 어떻게 구성되는가와 이들을 사용할 때 생각해야 되는 부분들에 대해 이야기를 나누고자 합니다.

다른 설명을 시작하기에 앞서 여러분이 한가지 알아둬야 할 것이 있습니다. 바로 10진수를 어떻게 2진수로 표현하는가입니다. 사실 이런 내용을 몰라도 프로그래밍을 잘하는 분들이 많습니다만 공부하는 데 돈이 드는 것도 아니니 조금 시간과 노력을 투자해서 알아둡시다. 게다가 별로 어렵지도 않습니다.

우선 정수를 2진수로 변환하는 방법은 수를 2로 나눠 나머지를 기록하고, 2보다 작은 수가 되어 더 이상 나눌 수 없을 때 계산을 종료하여 기록한 나머지를 밑에서부터 읽어나가는 것입니다.

예를 들어 123을 2진수로 표현하면 다음과 같습니다.

   몫    나머지
123 61    1
61    30    1
30    15    0
15    7 1
7 3 1
3 1 1
1 0 1

123(10진수) = 1111011(2진수)

어렵지 않죠? 이번엔 10진수의 소수를 2진수로 바꾸는 방법에 대해 설명하겠습니다.

소수를 2진수로 바꾸려면 해당 소수에 2를 곱해서 그 결과가 0보다 작으면 0을 기록하고, 1보다 크면 1을 기록한 뒤 결과의 정수 부분을 버리고 소수부분에 다시 2를 곱해 나가는 방식으로 계산하면 됩니다. 예로 10진수의 0.25를 2진수로 바꿔보겠습니다.

   결과 0보다큰가? 2진수
0.25 0.5    X 0.0
0.5 1.0    X 0.01 <-- 1.0의 정수 부분 1을 버리면 0만 남으므로 계산끝

또 다른 예를 들어볼까요? 이번에는 0.12를 2진수로 바꿔 보겠습니다.

   결과 1보다큰가?    2진수
0.12 0.24    X 0.0
0.24 0.48    X 0.01
0.48 0.96    X 0.000
0.96 1.92    O 0.0001    <-- 1.92에서 정수 부분 1을 버린다.
0.92 1.84    O 0.00011 <-- 1.84에서 정수 부분 1을 버린다.
0.84 1.68    O 0.000111 <-- 1.68에서 정수 부분 1을 버린다.
0.68 1.36    O 0.0001111 <-- 1.36에서 정수 부분 1을 버린다.
0.36 0.72    X 0.00011110
0.72 1.44    X 0.000111101 <-- 1.44에서 정수 부분 1을 버린다.
....

0.12는 끝이 안나는 군요. ^^; 0.12를 끝까지 계산해보진 않았지만, 만약 결과가 0이 되지 않는다면 끝임없이 2진수 변환을 진행하게 됩니다. 이것은 2진수가 가진 한계 때문입니다. 마치 분수 1/3을 소수로 표현하면 0.33333333333333333333333333333333333333...이 되는 것처럼 말이죠. 다행히도, float는 4byte, double은 8byte안에서 수를 표현해야 하므로 무한대로 계산하지는 않습니다. "부동 소수점 자료형의 "정밀도(Precision)"라는 속성이 어떤 것인지 좀 감이 잡히시죠?

... 다음에 계속 이어집니다. ( 이 포스트는 추후 수정될 수 있습니다.)

2006년 7월 3일 월요일

7월입니다!

벌써 7월달이 됐습니다. 2006년도 이제 꺾이기 시작하는군요.^^

요 근래에 약 8개월 동안 준비해온 BMT도 1위로 잘 끝내서 우리회사가 납품 대상자로 선정되되는 일이 있었고, C++ 원고도 마무리해서 출판사로 넘어갔습니다.
여전히 바쁘긴 하지만 큰 일들이 끝나서 그런지 심리적 여유가 조금은 생겨서 이것 저것 생각을 많이 하고 있습니다. 제일 많이 하는 고민은 "다음 포스트엔 어떤 글을 올릴까"이죠.(다음 C# 포스트는 "C#의 부동 소수점 이야기"가 될 것입니다.) ㅋㅋㅋ
그 다음 고민(?)들은 미리 이야기할 수 있는 것들이 아니라 지금 말씀 드리진 못하지만, 다음에 고민이 정리되는대로(궁금하죠? 별 거 없습니다. ㅋㅋ) 알려드리겠습니다.

어쨌거나 한주가 또 시작됐습니다. 모두들 즐프하세요! ^^

(아래는 글이 썰렁해서 넣어본 그림입니다. 제가 재작년에 슥슥 끄적여 놓은 게 컴터에 있더군요^^)

2006년 6월 29일 목요일

즐거운 주말 보내세요~

휴식이 기다리고 있는 주말이 하루 앞으로 다가 왔습니다.

이번 주말에는 시간을 좀 내서 서점에서 책을 좀 "구경"할까 합니다. 서점을 둘러보면 요즘 사람들이 어떤 것에 관심을 갖는지, 또 어떤 것을 필요로 하는지를 엿볼 수도 있고, 무엇보다 제가 읽을 책을 미리 점찍어둘 수도 있죠. (이젠 꽂아놓을 책장이 없어서 쌓아가고 있기 때문에 함부로 사지는 못합니다. ㅠ.ㅠ 이놈의 사재기병..)

근 몇달 동안 일에 치이느라 토요일도 일요일도 반납하고 살았는데, 모처럼 나들이를 하게 됐습니다. (비도 온다는데 대형 서점은 산책 코스로도 제격이죠 ㅋㅋㅋ)

모두들 남은 하루 화이팅 하시고, 즐거운 주말 맞이하시기 바랍니다. ^^

즐프!

2006년 6월 26일 월요일

C#의 음수 이야기

255

위 값은 C#에서 sbyte 형이 가질 수 있는 최대 값입니다. 이 값을 16진수와 2진수로 각각 변환하면 다음과 같지요. (한번 직접 계산해보세요^^)

16진수 : 7 F
2진수 : 0111 1111

2진수를 한번 봅시다. 첫 번째 자리가 0입니다. 왜 첫 번째 비트가 0으로 비어있을까요? 그 비트를 사용한다면 더 큰 수를 담을 수 있을텐데 말이죠. 이 의문을 품고 다음 수를 16진수와 2진수로 바꿔 봅시다.

-1

16진수 : - 0 1
2진수 : - 0000 0001

간단하네요. ^^ 그런데 이 값을 컴퓨터가 이해하게 하려면 어떻게 하죠? 컴퓨터가 '-' 기호를 이해할 수는 없습니다. 여러분도 잘 알고 있지만 컴퓨터는 0과 1만을 인식할 수 있을 뿐이죠.

컴퓨터 과학자들은 이 문제를 해결하기 위해 부호 비트(Sign Bit)라는 방법을 도입했습니다. 아까 255를 2진수로 변환한 값의 첫 번째 비트가 비어 있는 것을 봤죠? 그 첫 번째 비트가 바로 부호 비트로 사용되는 것입니다.

예를 들어 부호 비트가 1이면 음수, 0이면 양수가 되는 것이죠. 1000 0001 은 -1, 0000 0001은 +1입니다. 오, 훌륭하지 않나요? 이제 아름다운 음수를 비트 조합으로 표현할 수 있게 됐습니다. 그러나 여기에도 한가지 문제점이 존재합니다. 1000 0000 ( -0)과 0000 0000( +0)이 같이 존재한다는 것입니다.

음수를 표현하기 위해 제시된 또 하나의 방법은 1의 보수라는 방법입니다. 비트를 반전시켜 부호를 바꾸는 방식인데, 이 경우에도 -0, +0이 존재하는 문제는 마찬가지로 존재합니다. 앞의 방식보다 좋은 점이라면 0과 1의 비트를 뒤집는 연산은 엄청 빠르기 때문에 음수를 빨리 계산해 낼 수 있다는 것이죠.

컴퓨터 과학자들은 1의 보수가 가지는 단점을 보완하는 2의 보수라는 방법을 고안해 냈습니다. 비트를 반전시킨 다음 1을 더하는 것인데, 이렇게 하면 +와 -의 두가지 0이 존재하는 문제를 제거할 수 있습니다. -1을 2의 보수로 표현하면 다음과 같습니다.

1) 0000 0001 // 1
2) 1111 1110 // 모든 비트 반전
3) 1111 1111 // 반전된 비트에 1을 더하여 -1 표현. 16진수로 표현하면 FF

마지막 3)의 1111 1111이 2의 보수로 표현한 -1인 것입니다. 현대의 모든 컴퓨터는 2의 보수 방식을 이용하여 음수를 표현합니다. 그럼 다음의 코드를 한번 컴파일해서 실행해 보세요.

코드 :

using System;

class MainApp
{
   static void Main(string[] args)
   {
   sbyte a = -1;
   Console.WriteLine("{0}, {0:X2}", a);
   }
}

결과 :

-1, FF

재미있죠? 더 재미있는 이야기를 계속해 보겠습니다. 부호 비트로 사용하는 첫 번째 비트를 사용하면 더 큰 값을 표현할 수 있겠죠? 다음 코드에서 a는 16진수로 표현하면 FF, 2진수로 표현하면 1111 1111입니다.

byte a = 255;

똑같은 1111 1111인데 byte형 변수에 담기면 255가 되고 sbyte형 변수에 담기면 -1이 됩니다. 장난 하나 쳐 봅시다. 1111 1111을 갖는 byte형 변수의 값을 sbyte로 형변환 해서 실제로 -1이 되는 지를 보는 겁니다. 다음 코드를 컴파일하여 실행해 보세요.

코드 :

using System;

class MainApp
{
   static void Main(string[] args)
   {
   byte a = 255;
   Console.WriteLine("{0}, {0:X2}", a);

   sbyte b = (sbyte)a;
   Console.WriteLine("{0}, {0:X2}", b);
   }
}

결과 :

255, FF
-1, FF

위 코드와 결과를 통해 알 수 있듯이, 부호가 있는 자료형과 그렇지 않은 자료형 사이에 값을 교환하는 일에는 주의를 기울여야 합니다.

이렇게 해서 C#에서 음수를 표현하는 방식과 주의해야 할 점에 대해 알아봤습니다. 앞으로도 클릭하세요 C# 2.0 프로그래밍에서는 미처 다루지 못한 이야기들을 종종 나누고자 합니다. 자주 찾아와 주세요. (방명록이 그냥 방치되어 있습니다. 방명록도 자주 이용해 주세요.^^;)

2006년 6월 23일 금요일

훈련 잘 다녀왔습니다.

동원 훈련 잘 받고 돌아왔습니다.

가서 그냥 아무 생각없이 지내다 와야겠다 하는 생각을 했는데 의외로 배운 것도 많고
좋은 사람들도 만날 수 있었습니다.

사실 통제하기 힘든 예비군들이 그렇게 달가운(?) 존재는 아니었을텐데, 중대장님, 행보관님, 소대장님 그리고 병사들이 정말 열심히 훈련을 도와줬습니다. (모두들 감사드립니다.) 정비 시간도 잘 써서 내무실(이젠 생활관이라고 하더군요)에 꽂혀 있던 책들도 몇 권 읽을 수 있었고, 무엇보다 밥도 맛있었습니다. 다소 투박하긴 하지만 우리 회사 구내식당보다 한 5배 정도는 더 맛있더군요.

병사들하고 이야기를 하면서 진로 이야기도 같이 하고 사회에 나올 것에 대한 준비도 좀 도와줄 수 있었으면 좋았을텐데, 시간이 허락되지 않아 좀 아쉽네요.

소모적인 시간이 될 수도 있었는데 유익하게 사용한 것 같아 뿌듯하네요 ^^

2006년 6월 19일 월요일

나를 채워야 할 때.

요즘 아침에 일어나면 아무것도 "해야 하는 일"이 없다는 사실이 너무 홀가분하고 좋습니다. VC++ 2005 원고를 탈고했기 때문에 새벽에 눈을 떴을 때 뭔가 해야한다는 압박에서 당분간 벗어나 지내게 됐습니다.(물론 회사 일은 회사 일대로 합니다만.)

지금도 자유로운 아침 시간이 잘 적응이 안되서 점심을 먹고 산책을 하면서 아침에 뭘 해야할까.. 하고 생각해 봤습니다. 여러가지가 생각이 나더군요. 몇가지 떠오른 생각은 다음과 같습니다.

- 다른 책을 집필한다.
예) C#/C++ 코드 Recipes, 자료구조, 알고리즘, 데이터베이스 프로그래밍 등등...
- 소프트웨어를 개발한다.
예) EAI용 메시지 버스, 데이터 기반의 워드 프로세서 등등...
- 잠을 잔다.
............ Good!!!!!!!
- 공부 한다.
예) 영어, 메마른 정서를 적셔줄 시나 소설 읽기, 여행 하기,
교양 물리나 사회 과학책 등 읽기.

책을 집필하거나 소프트웨어를 개발하는 것은 지금 시작해도 되긴 하지만, 그러기에는 지난 몇년간(특히 최근 1년간!!) 내 능력을 쏟아내기만 했지 나를 채우는 일은 못했다는 생각이 들더군요. 그래서 공부를 좀 하기로 했습니다.

한 3~4개월 정도가 걸리겠네요. 내 마음을 쉬게 하면서 또한 텅텅 비워진 마음과 머리 속에 지식과 지혜들을 담고자 합니다. 그렇게 공부하다가 새로운 일을 할만한 에너지가 생기고 또 목표가 생기면 일을 벌이려 합니다. 그 목표가 영어 실력이 될지, 새로운 책이 될지, 또는 소프트웨어가 될지는 모르겠지만, 마냥 공부만 하진 않을 것입니다.

공부도 즐거운 일이지만, 새로운 도전에 나서는 것만큼 재미있지는 않거든요 ^^

2006년 6월 17일 토요일

조국의 부름을 받고~~

이번주에는 예비군 훈련이 있어서 월요일과 금요일에는 서울 연구소(원래 제 근무지는 대전입니다.)에서 근무하고 화~목은 예비군 훈련을 받습니다.
조국의 부름을 받는 건 정말 영광스럽고 즐거운 일이 아닐 수 없습니다. ㅋㅋ (컴퓨터를 떠나 몇일을 지낸다는 것이 너무 좋네요)

예비군 훈련 기간동안 올라오는 질문에 대해서는 돌아와서 답변을 드리도록 하겠습니다. 이점 양해 부탁드립니다. ^^;

2006년 6월 12일 월요일

컬쳐 2006으로 오세요~

2005년 한 해 동안 해외에서 봉사활동을 하고 돌아온 사랑스러운 IYF 후배들의 행사입니다.
각국의 문화 공연을 체험할 수 있는 Culture 2006 을 소개합니다. ^^

2006년 6월 10일 토요일

[펌] IT 인재를 관리하기 위한 세 가지 중요 지침

IT 인재를 관리하기 위한 세 가지 중요 지침

류한석(피플웨어 운영자) 2006/05/06

알고 지내는 어떤 회사의 간부가 내게 이런 불평을 했다.

“내가 하고자 하는 바를 부하 직원들이 전혀 이해하지 못하고 있습니다.”

윗사람의 의도는 부하 직원에 의해 ‘자동으로’ 이해되지 않는다. 그 간부는 자신의 부하 직원들이 멍청하다며 내게 하소연한 것이었지만, 사실 그러한 말이야말로 스스로 “나는 부덕하며 리더의 자격이 없다”고 얘기하는 것과 100% 동일한 것이다.

그 간부는 부하 직원이 해당 업무에 익숙하지도 않은 상태에서도, 작은 실수가 있을 경우 무조건 심하게 꾸짖곤 했다. 그는 그러한 자신의 행동에 대해 부하들을 가르치는 것이라고 했다. 하지만 부하 직원은 자신이 익숙하지 않은 일에 질책을 받을 경우 그것을 인정하지 않는다. 이는 손자(孫子)에서도 언급되는 말이다.

현 시대를 살아가는 우리에게 있어 회사의 업무란, 대개의 경우 환경적으로 문제가 있는 경우가 많고 자신의 전문 분야가 아닌 일을 갑작스레 맡아서 해내야 하는 경우도 많다. 즉 우리에게는 상당히 비합리적 상황에서 일을 해야 하는 경우가 빈번하다.

하지만 그러한 환경적인 문제, 교육의 부족, 업무를 제대로 수행할 수 없는 한계는 인정하지 않는 채로, 자신이 원하는 것만 명령하듯이 지시하는 직장 상사들이 많다. 더 나쁜 사실은 그러한 지시가 그 보다 윗사람이 던진 말 한마디에 갑자기 변경되어 버리는 경우도 흔하다는 것이다. 그러한 경우에도 물론 상황의 설명은 없다.

그러한 직장 상사의 밑에서 어떤 부하 직원이 제대로 업무를 해낼 수가 있겠는가? 실제로 그런 상황에서 부하 직원은 자신의 능력 부족으로 일을 제대로 하지 못했을 경우 조차도, 마음 속으로 윗사람에 대한 불평불만을 가질 뿐 자신의 발전 기회로는 삼지 못하는 것이다.

리더는 부하 직원에게 뭔가 못마땅한 점 있다면, 먼저 자신부터 재점검해야 한다. 이제 본론으로 들어가보자.

유능한 리더의 인재관리 철학
유능한 리더가 되려면, 인재를 모으고 유지하는 철학을 가져야 한다. 인재 관리의 지침에 대해 살펴 볼 요소들이 상당히 많지만, 지면의 한계가 있으므로 여기에서는 핵심적인 사항만 세 가지로 정리해 보았다.

첫째, 인재를 모으는 지침이다. 인재를 모으려면, 리더는 자신보다 뛰어난 사람을 찾아서 예(禮)를 다해 정중하게 자신의 일에 참여할 것을 청해야 한다. 인재란 결국 리더에게 없는 능력을 제공하는 사람이다.

혹시 이러한 필자의 주장에 동의하지 않는가? 그렇다면 자신보다 못한 사람들만을 옆에 두고서 자신이 모든 것을 챙겨야 할 것이다. 결국 천하통일의 패업은 커녕 구멍가게를 유지하기에도 벅차다.

리더는 자신에게는 없는 능력을 가진 인재로부터 가르침을 받는다는 생각으로 인재와 신뢰 관계를 맺어야 한다. 그렇게 하면 자신보다 몇 배나 뛰어난 인재를 모을 수 있다. 만일 업무의 사소한 실수를 트집잡아 무조건 꾸짖는다면 그러한 사람의 주변에는 머슴 밖에 모이지 않을 것이다.

중국 격언에 “의심이 들면 등용하지 말고, 등용 했으면 의심하지 말라.”는 말이 있다. 리더는 자신 스스로가 인재의 리더가 될 수 있는 재목인지, 머슴의 리더가 될 수 있는 재목인지 스스로 깨달아야 한다.

둘째, 인재를 유지하는 지침이다. 리더는 논공행상(論功行賞)을 공정하고도 분명하게 행해야 한다. 논공행상이란 ‘공을 논하고 상을 준다’는 말이다. 논공행상을 제대로 하지 못하면, 부하 직원의 신뢰를 잃게 되고 최악의 경우 부하 직원에게 배신을 당해 비참한 결말을 맞이할 수도 있다.

그리고 논공행상의 공정함과 명확함은 부하 직원의 입장에서 판단되어야 한다. 리더가 자신이 논공행상을 했다고 생각하더라도, 부하 직원들이 그것을 인정하지 않는다면 그것은 하지 않은 것과 동일하며 오히려 더 나쁜 결과를 가져올 수도 있다.

사람은 자신을 인정하고 알아준 사람에게 고마움을 느끼며, 그러한 깊은 신뢰로서 어려운 일을 맡아 하는 것이다. 사람은 이해관계로만 움직이지는 않는다.

결국 인재를 모으고 유지하는 핵심은, 인재의 가치를 인정함으로써 그가 그것을 깊이 느낄 수 있게 해주는 것이다. 단순하다. 하지만 자신이 제일 잘났다고 생각하는 사람들이 넘치는 이 세상에서, 그것이 얼마나 힘든 일인가?

셋째, 인재를 대하는 태도의 지침이다. 리더가 가장 조심해야 할 것은 일상에서 부하 직원의 마음에 상처를 주는 언행을 삼가야 한다는 점이다. 어떻게 보면 작은 것이지만 이것 때문에 많은 리더들이 패가망신한다.

논공행상은 커녕 열심히 일한 부하 직원의 작은 실수를 트집잡아 인격적인 모독을 행하는 직장 상사들이 많다. 하지만 사소한 것이라도 마음의 상처를 주면 혹독한 대가를 치르게 된다.

역사는 우리에게 언제나 교훈을 준다. 예를 들면 조조(曹操)는 “인재의 장점을 보고, 단점은 보지 않는다”는 철학으로 중국 삼국시대 위왕조를 만들었고, 뛰어난 업적을 남길 수 있었다. 조조의 인재 철학과 큰 그릇으로 인해 주변에 인재가 끊이지 않았다고 한다.

반면에 삼국지의 유명한 장수로서 병사 만 명에 필적했다던 장비는 부하를 난폭하게 대한 나머지, 잠 자다가 부하의 손에 목이 잘려서 어이없이 죽고 말았다. 장비는 그렇듯 끝이 좋지 않았다.

사실 그러한 일은 작금의 시대에도 흔히 발생하고 있다. 기업인이 부하 직원을 함부로 대한 결과, 해당 부하가 중요한 기밀을 경쟁 기업에 유출하거나 또는 불법적인 행위를 폭로하는 경우를 우리는 종종 목격한다. 왜 많은 리더들이 앞서 기술한 인재 관리의 기본조차 지키지 못하고 있는 것일까?

대개 자신이 가장 똑똑하다고 생각하며 부하 직원은 단지 자신이 명령할 대상이라고 생각하는 사람들에게서 이러한 실수가 흔히 발견된다. 그런 사람은 큰 일을 행할 수도 없을뿐더러, 그런 식으로 행동하다가는 말년을 조심해야 할 것이다.

그러한 유형의 리더는 잘 나갈 때에는 부하 직원들에게 공포심을 유발함으로써 상당한 권력을 누릴 수도 있겠지만, 한번 무너지기 시작하면 모든 부하 직원들이 등을 돌림으로써 순식간에 나락으로 떨어지게 된다. 역사에는 그러한 반면교사들이 너무도 많다.

IT 업계의 인재 관리에 각성이 필요하다
특히 IT 업계의 사람들은 앞서 기술한 지침들을 명심할 필요가 있다. IT 업계에는 부하 직원보다 나이가 어린 리더들도 많고, 흔히 아이디어로 기업이 창업되고 명운이 결정되곤 한다. 그렇기 때문에 자신의 똑똑함만을 믿은 나머지 부하 직원들을 함부로 대하는 리더들이 많다.

어떤 중소 S/W 업체의 사장은 자신의 회사에서 자신이 프로그래밍을 제일 잘한다고 주장하며 개발자들을 공공연히 무시하였다고 한다. 당연하게도 그는 좋지 않은 결말을 맞이했다.

고백하건대 필자 또한 과거에 유사한 실수를 한 적이 있다. 겪어보지 않은 자가 어찌 이런 글을 쓸 수 있겠는가? 과거에 필자는 부하 직원의 실력을 공공연히 신랄하게 비평한 나머지, 해당 인재가 마음의 상처를 받고 IT 업계를 떠나기도 하였다. 몇 년이 지난 후 깨닫게 되었지만, 지금도 깊은 사죄의 마음을 갖고 있다. 조금 높은 지위에 있다고 해서, 내가 누군가를 재단할 자격이 있는 것은 아닌데 그 때는 그것을 몰랐다.

필자가 적은 내용들이 비난 IT 업계에만 국한되는 내용은 아닐 것이다. 하지만 역사가 짧고 그로 인해 바람직한 전통이 부족한 IT 업계에서는 반드시 지켜야 할 인재 관리의 기본조차 무시되는 경우가 많다. 필자 또한 많은 시행착오를 겪은 부족한 사람이지만, 이 업계에 대한 애정과 안타까움을 갖고서 관련 내용을 정리해 보았다.

필자는 아직 그리 대단한 일을 하고 있지는 못하지만, 인재를 모이고 있으며 가시적인 성과를 맛보고 있다. 그것은 독불장군의 시절과는 비교할 수 없는 대단한 결과를 가져다 준다. 많은 사람들이 그러한 기쁨을 맛보기를 바란다.

2006년 6월 8일 목요일

냠냠~ C#

지금 일하고 있는 회사에서는 C와 Java를 사용하지만, 개인적으로 업무에 필요한 유틸리티가 있으면 C#으로 작업하곤 합니다.

전 C, C++, C#, JAVA, VB 등의 언어를 자유롭게 구사하며, Perl이나 JScript등의 언어를 그럭저럭 다룹니다. 언어를 많이 아는 것과 프로그래밍을 잘 하는 것과는 별개의 문제지만, 적어도 필자 스스로는 언어간의 차이나 장단점에 대해서 이야기할만한 자격이 있다고 생각합니다. ( 이미 한물간 C#과 Java간의 비교 논쟁을 하고 싶은 생각은 없지만 그냥 필자가 수년간 사용해 오면서 느낀 점을 솔직히 얘기하고 싶습니다.)

C#과 비교가 많이 되는 Java 언어는 상당히 장황하고 추상적인 코드를 요구합니다. Java의 팬들이 보면 필자에게 할 말이 많겠지만, 개인적으로는 별로 좋아하지 않습니다. C#은 간결하고 실용적인 코드를 작성할 수 있도록 해주죠. 게다가 조금 익숙해지면 프로그래머가 생각하는대로 바로 로직을 구성할 수 있을 정도로 쉽습니다. 뿐만 아니라, 모든 분야의 소프트웨어 개발이 가능하죠 ^^

Anders Hejlsberg가 볼랜드에서 만들었던 델파이(지금은 사용하지 않지만 필자는 델파이로 프로그래밍을 시작했습니다.)가 그랬듯이, MS에서 그가 만든 작품인 C# 언어 역시 상당히 매력적인 언어입니다. C++ 언어에서 맛볼 수 있는 "프로그래밍 하는 맛"도 느껴지고요.

오늘도 프로그램을 짜다 새삼 C#이 참 멋진 언어라는 생각이 들었습니다. 여러분도 그런가요?

2006년 6월 5일 월요일

아프리카...

약 2년간 진행해 왔던 C++ 원고도 마무리 되었습니다. (편집, 2차, 3차 교정 등의 절차가 남아있긴 하지만 전 "탈고"를 선언했습니다.)

이제 또 다른 도전(집필? 소프트웨어 개발? 혹은 공부? 그건 몇 주 더 생각해 봐야겠습니다.)에 임하기 전에 아프리카를 다녀오고자 합니다. 그들과 섞여 살아보지 않고 그냥 몇주 여행하듯 다녀오는 것만으로는 부족함이 많겠지만, 나이가 들어 제 마음이 더 굳어지기 전에 다른 세계를 마음에 품고 싶습니다. (그렇게 하지 못하면 안되겠다는 두려움도 제 마음 한편에 있습니다.)

(아래는 이디오피아의 남필현 선교사님 사진)

delegate 이야기

"클릭하세요 C# 2.0 프로그래밍"에서 델리게이트에 대한 설명을 했지만 또 다른 방법으로 설명을 시도해 보고자 합니다. 그냥 가볍게 읽어보세요. ^^

-----------------------------------------------------------------------------------

오늘은 철수 아버지 생신입니다. 학교 다녀온 철수는 어머니를 도와 아버지의 생일상을 준비합니다. 온 가족이 아버지의 생일을 깜빡하고 있었기에 준비된 것은 아무것도 없었습니다.

어머니는 늦었지만 아버지의 생신을 위해 맛있는 저녁을 준비하기로 하고, 철수에게 간단한 임무를 부여했습니다. 철수의 임무는 이렇습니다. 어머니가 돈과 메모장을 쥐어주시면 그대로 수퍼마켓으로 가서 메모장에 적힌 대로 물건을 사오면 됩니다. 철수는 수퍼마켓을 오가며 콩나물, 고사리, 삼겹살, 상추, 음료수 등을 어머니가 메모지에 적힌 대로 사왔습니다.

철수는 어머니의 심부름을 훌륭히 수행했고, 온 가족이 즐거운 생일상을 맞이할 수 있었습니다.

자, 생각해 봅시다. 철수는 어머니의 장보는 일을 대신 처리하는 "대리자" 역할을 수행했습니다. C# 언어에서의 delegate(대리자)도 철수가 수행한 것과 같은 심부름꾼 역할을 합니다.

장보는 일을 어머니가 직접해올 수도 있었지만, 어머니는 철수에게 그 일을 맡기고 요리에만 집중했습니다. 철수는 어떤 물건을 사와야 할지 알 수 없었지만 어머니가 메모지와 돈만 손에 쥐어주면 어머니가 원하는 것을 사올 수 있었습니다. 철수는 오늘 장보는 일만 했지만 그 외에도 어머니가 시키는 심부름을 다양하게 해낼 수 있습니다. 예를 들어 강아지를 산책시킨다던가, 세탁소에 바지를 맡기러 간다던가 하는 것 말이죠.

철수의 임무는 사전에 정해지지 않았지만 필요할 때마다 어머니가 임무를 부여할 수 있습니다.

delegate도 철수와 같은 신세입니다. 어떤 일을 할 지에 대해서는 정해지지 않았지만 필요할 때 다른 임무(메쏘드)를 부여받아 실행하도록 되어 있지요.

delegate가 수행하는 심부름의 예에 어떤 것이 있을까요? 이벤트의 이벤트 처리기가 있네요. 이벤트는 자신이 생성될 때 수행되어야 하는 동작을 사전에 정의해 놓은 메쏘드를 갖는 대신, 델리게이트를 가짐으로써 다양한 내용의 이벤트 처리기를 가질 수 있습니다.

즉, 이벤트는 아버지 생신, 이벤트가 가지는 델리게이트는 철수, 그리고 이벤트 처리기(메쏘드)는 메모지와 돈에 해당한다고 할 수 있습니다. 그럼 어머니는 어디에 해당하냐구요? ㅋㅋ 여러분, 바로 프로그래머겠죠?

2006년 6월 2일 금요일

보고픈 Vas~

AIM Systems에서 같이 일하던 Vas와 메신저를 통해 오랜만에 이야기를 나눴습니다. Vas는 인도인으로써, 3년 정도 한국에서 일했는데 올해 초에 고향으로 돌아가서 일하고 있습니다. 일하고 있는 곳이 인도에서 4번째로 큰 방갈로에 있는 IT 회사랍니다.(2만명이 넘는 직원 중에 한국인도 3명 있다더군요. ㅋㅋ)

저보다 2살 더 많은 이 친구하고는 커피(봉지에 담긴 인스턴트 커피)를 무던히 마셨던 것 같습니다. 원래 커피는 마시지 않았는데, 한국에 와서 맛을 들였답니다 ㅋㅋ. 알아듣기 힘든 인도식 영어도 시간이 지나니 적응이 되더군요.

입사하던 날부터 그냥 마음이 맞았습니다. 팀은 달랐지만 개발하다 걸리는 문제들도 서로 도와가며 풀고, 제가 영어로 작성하는 문서는 Vas가 교정을 봐주고, Vas가 갖고 있는 한글 문서는 제가 번역해주고요. Vas가 명절에 가족 선물을 사야되면 제가 도와주고, Vas는 고향에 다녀오면 제가 부탁한 책을 사다주곤 했습니다.(인도가 책이 싸더군요)
저도 그 친구도 술담배를 안하니 스트레스 받을 때는 커피 한잔 타들고 비상구 계단에서 수다를 떨기도 했고요. ( 요즘은 장가를 가야 하는데 부모님께서 적극적으로 신부감을 찾아보지 않으신다고 시무룩해있더군요 ㅋㅋ )

그냥 옛날(?) 생각이 나서 끄적여 봤습니다. 제가 기억하는 좋은 개발자(앞으로도 다시 만나서 같이 일하고 싶은) 중의 한사람이었습니다. 여전히 메신저로 연락을 유지하긴 하지만, 서로 직접 얼굴 볼 수 있을 기회가 생길진 모르겠습니다.

2006년 6월 1일 목요일

힘들지만.. 미소를 띄워보며..

요즘같이 힘든 때에는 다른 팀원들이 안정할 수 있도록 자살 미소 한방씩 날려줘야 합니다..

비록 퀭하고 졸린 눈에, 면도도 제대로 못한 얼굴이긴 하지만요 ㅋㅋㅋ

썩소... ㅋㅋ

2006년 5월 31일 수요일

아~ 피곤한데~

안타깝지만 내일은 제 소중한 한표(아, 이제 여러 표지 ㅋㅋ)를 행사하지 못하게 됐습니다.
KTX를 타고 대전 연구소로 새벽에 달려가야 하거든요..1년 정도 이 생활을 하다보니 솔직히 이젠 좀 지치는군요

그래도 하고 있는 프로젝트는 꼭 성공해야 합니다. 이유는 - 제가 참여하고 있기 때문에.

2006년 5월 26일 금요일

(나만의) Technical Writing 원칙

요즘 재미없는 포스트만 올리네요. 다른 얘기를 좀 해볼까요?

근자에는 새벽마다 C++ 원고 교정을 하고 있습니다. Technical Writing에 대한 철학까지는 아니더라도 원칙정도는 필자에게 있습니다. 그것은 다음과 같습니다.

[1] 글은 내 지식을 자랑하기 위함이 아닌 독자들이 원하는 지식에 쉽게 접근하도록 하기 위함이다.

-> 독자들이 돈을 지불하는 이유는 필자를 좋아해서도, 돈이 남아서도 아닙니다. 책에 들어 있는 정보를 위함입니다. 정보를 쉽게 얻어갈 수 있도록 하는 것은 저자의 책임입니다.

[2] 모든 것을 설명하기 위해 하나도 설명하지 못하는 실수는 하지 않는다.

-> "통계를 알면 인생이 달라진다(오오무라 히도시/자음과모음)"라는 책을 읽으면서 얻은 깨달음입니다. 이 책은 300페이지 정도의 얇은 분량으로 베게만큼 두꺼운 통계책보다 더 많은 것을 필자에게 가르쳐줬습니다. 과하면 차라리 없는 것만 못한것이죠.
책을 쓰다보면 자신이 가진 모든 지식을 글에 부어넣고 싶은 욕구가 드는데, 그 때 한걸음 뒤로 물러나서 이 내용이 꼭 필요한 것인가 하는 고민을 합니다. 물론 꼭 필요한 것이 빠지진 않았는가 하는 생각도 함께 말이죠. 그래서 "~~ 바이블"이 되지 않을 수 있었습니다.

[3] 책은 돈을 위해서가 아닌 공헌을 위해서 쓰는 것이다.

-> 책... 들인 시간에 비한다면 금전적으로는 얻어지는 것이 거의 없습니다. 물론, 필자의 글재주가 형편없기때문이기도 하지만, 그 시간에 소위 "알바"라도 뛰었다면 필자, 아마 좋은 차 한 대 샀을겁니다. 필자가 갖고 있는 것을 후배에게 나눠준다는 마음으로 글을 쓴 것이고, 그나마 받는 인세 또한 국제 청소년 연합(Iternational Youth Fellowship)을 위해 사용합니다.

새로 나올 책도 위 원칙에 의해 검토를 쭉 하고 있습니다. (가장 고민되는 것이 문체가 지금 반말로 되어 있다는 것입니다. -.-;; 예를 들어 "int형은 다음과 같은 데이터를 표현할 수 있다."처럼 말이죠. 아무리 봐도 이건 아닌 것 같다는 생각이 드는데.. 의견 있으시면 코멘트 부탁 드리겠습니다~~ )
출판까지는 약 2~3달 정도가 소요되겠네요. ^^

네... 뭐 오늘도 상당히 쓸데없는 글이었습니다. ㅋㅋㅋㅋ
이맘 때쯤이면 진도가 빠른 독자들은 "클릭하세요 C# 2.0 프로그래밍"을 한번 다 봤을 것 같네요. 깊이 있는 주제로 글을 하나씩 쓰려고 합니다. 물론 연재 주기는 규칙적이진 않을 겁니다. ^^;

2006년 5월 25일 목요일

거울과 창

예전에 Good To Great이라는 책을 읽은 적이 있습니다. 우리나라에는 "좋은 기업에서 위대한 기업으로(맞나?)"라는 제목으로 출판된 걸로 알고 있습니다.

모 증권사 CEO로 계시던 분의 이야기를 듣다가 이 책에 대해 듣게 되어서, 저도 구입해 읽게 되었습니다. 이 책의 내용은 제목처럼 그저 괜찮고 좋은 기업의 수준을 넘어 위대한 기업으로 가는 기업들의 특징은 무엇인가에 대해 다루고 있습니다.

그 중 Mirror and Window(거울과 창)에 대한 내용이 많이 마음에 남았습니다. 책에 의하면 위대한 리더(Level 5 Leadership(뭐라 번역해야 할지;;;)을 가진 리더)는 전문가적인 소양 뿐 아니라 겸손한 인격을 갖고 있다고 합니다.

위대한 리더는 잘못된 일에 대해서는 거울을 비춰보며 자신에게서 문제점과 책임을 찾고, 잘된 일에 대해서는 창을 통해 밖을 내다보면 누구에 의해 이 일이 잘되었는지를 찾습니다. 특히 잘못된 일에 대해서는 어떤 외부적인 요인이나 환경 탓도 절대 하지 않는다는 것이 특징이죠.

저도 거울과 창을 가지고 있지만 사용하는 때는 위대한 리더와는 많이 다른 것을 느낍니다. 잘되고 있을 때는 몰랐는데, 문제가 생길 때는 당장 변명거리부터 찾고 있는 나를 발견했습니다. (내가 바뀌겠다고 해서 순식간에 바뀌진 않겠지만, 일단 내 자신을 알면 거기서 문제의 실마리가 풀리기 시작하겠죠? 소크라테스가 말한 것처럼요.)

책이 단순히 지식 역할만 하는 줄 알았는데, 나를 비춰보는 거울 역할도 해주네요. ^^
아니, 지식이 거울 역할을 해주는 건가요? ㅋㅋㅋ

설계문서, 사양서 없이 개발한다는 것.

설계문서, 사양서 없이 개발한다는 것.

건축물이 구축되려면 치밀한 설계도와 그 설계도를 준수하기 위해 필요한 공법까지 사전에 준비가 되어야 합니다. 설계 기술이 좋아져서 요즘은 설계도가 나오면 3차원 영상으로 미리 건물 내/외부를 이리저리 돌아다니면서 실제 건축된 후의 모습을 미리 볼 수도 있습니다.
건축물 뿐 아니라, 싱크대를 하나 짜더라도 어떤 디자인, 어떤 치수, 어느 자재를 사용할지를 사전에 설계를 하지요. 자동차, 기계, 그 어떤 가공물도 - 적어도 "제품"이라면 - 설계 없이 만들어지는 경우는 거의 없습니다.

소프트웨어의 설계 문서란, 소프트웨어의 전체적인 구조에서부터 특정 루틴에 이르는 소프트웨어 구현에 필요한 상세한 청사진을 말합니다(물론, 설계 문서의 종류는 다양합니다만.). 사양서는 설계 문서와는 다르게 소프트웨어가 어떤 역할을 하며 어떤 방식으로 동작한다라는 소프트웨어의 사양을 기술하는 비교적 간단한 문서입니다.

어떤 관리자들은 "바쁘기 때문에", 혹은 "시간이 없기 때문에" 이 문서들을 준비하지 않고 개발자들에게 개발을 시작하라고 합니다. 1~2억이 투자되는 소프트웨어 개발을 말이죠.

이렇게 되면 개발자들은 그야말로 "알아서" 개발을 시작합니다. 열심히 한 개발자는 나중에 열심히 새로 개발해야 하는 상황이 발생하고 얍삽한 개발자들은 어느정도의 결과물이 나오면 일단 소스 코드를 릴리즈를 하고 반응이 오면 고칠 준비를 하고 기다립니다. 자신이 작성한 소프트웨어가 "과연 그렇게 동작해야 하는가"하는 의문이 서기 때문이죠. ( 어느 쪽이든 욕을 먹지만, 후자쪽의 개발자가 욕은 더 많이 먹습니다. ) 결국 결과물은 어떻게 어떻게 해서 나오게 되지만 "이게 우리가 2억을 들여 만든게 맞습니까?" 하는 이야기를 듣게 됩니다.

설계서, 사양서는 개발 하면서도 계속해서 수정되고 릴리즈되어야 합니다. 마치 건축물 설계도가 그러하듯이 말입니다. 그리고 개발자들은 필요하다면 수정된 문서에 의해 자신의 소프트웨어를 변경해야 합니다.

뜬금없이 왠 설계, 사양서 얘기냐구요? 이런 생각을 하게 하는 일들이 있었거든요.
상황이 이랬거나 저랬거나 프로젝트는 완수해야죠. 오늘도 파이팅하면서 시작입니다! 즐프~

2006년 5월 18일 목요일

내 게임.

일을 하다 보면 문득 이 일이 잘 안되면 어떻게 하지, 잘 풀리면 어떻게 할까 하는 공상에 젖어들 때가 있습니다. 그러다 보면 집중이 안되고 그 일의 결과는 실패쪽으로 기울기 마련입니다.

마음을 비우고 "지더라도 내 경기를 하겠다."라는 자세를 가지는 요즘입니다.

2006년 5월 16일 화요일

S > Quark && S < Cosmos

사람이 관찰, 또는 추적할 수 있는 가장 작은 원소가 Quark,
또 가장 넓다고 추정하는 우주의 넓이...
하지만 Quark 보다 더 작은 세계가 분명 있을 것이고,
저 별 너머에는 우리가 보지 못하는 대 우주가 펼쳐져 있겠죠?

우리가 보는 시각은 쿼크에 한참 미치지도 못하고, 저 우주에도 미치지 못하는
극히 좁은 것에 지나지 않는데도 왜 우리는, 아니 나는 이렇게 교만한지 모르겠습니다.
아는 것보다 모르는 게 더 많은 나를 자꾸 잊어버려 큰일입니다.

2006년 5월 13일 토요일

아.. 일하기 싫다~~

이 그림을 그려놓은 건 몇년 전 신입 시절 때였습니다. 이런 그림을 그릴 힘이 있었던 것도
일하는 매 순간이 도전이었고 즐거웠기 때문이었다는 생각이 듭니다.

지금은 일이 미친듯이 많으면 '내 시간'을 뺏긴다는 느낌 때문에 조금 억울(?)하다는 생각이 들기도 합니다.
일로 하는 프로그래밍 때문에 "재미로 하는" 프로그래밍을 할 수 있는 시간이 줄어드는 것 같아 안타깝습니다. ^^;;

언젠쯤 재미로 하는 프로그래밍을 할 시간을 되찾을 수 있을까요?

- 일하기 싫은 놀토에 박상현.

2006년 5월 12일 금요일

비주얼 C# 2005 Express 다운 받기

많은 분들이 아직도 비주얼 C# 2005 Express를 어디서 구할 수 있는지 잘 모르시는 것 같습니다.

책의 뒤에도 나와 있지만 제가 다시 한번 여기에 적어놓겠습니다. ^^

비주얼 C# 2005 Express 아래의 주소에서 받으실 수 있습니다. 물론, 무료입니다!

http://www.microsoft.com/korea/msdn/vstudio/express/visualcsharp/

2006년 4월 25일 화요일

인터파크에 올라온 서평 3개

어제 처음 읽어 봣는데요.. | kt5118 | 2006.04.21 | 평점


	내용 구성 디자인 가격

	어제 빨리 와서 너무 놀랬구요... 내용이 제가 배우고 있는 버전은 차이가 있는데...그래도 몇개 빼 놓고는 제가 배운거라서 다 있었어요...내용이 쉬워서 처음 배웠을때는 잘 몰랐는데 내용을 보고 어느 정도는 이해가 되더라구요 쉽게 되어 있어서 좋더라구요....해설도 잘 해놓으셨고 각 예제에 해설도 써 놓으셔서 좋았어요 저 같은 초보들에는 저만 그런 건지 모르겠지만 이 정도 책이 괜찮은 거 같아요 책 값도 할인 된 가격에 사서 너무 좋았어요...

재미있다. 그러나 가볍지 만은 않다. | einis73 | 2006.04.13 | 평점


	내용 구성 디자인 가격

	무엇보다 딱딱하지 않고 쉽게 접근할 수 있는 책인 것 같습니다. C#을 처음 접하는 독자라면 시작하는데 도움이 될 듯 합니다. 한장한장 차근차근 읽어가면 개념을 파악하고 프로그래밍의 세계로 들어갈 수 있으리라 생각합니다.

대충 훑어보고나서 | rapaelz | 2006.04.11 | 평점


	내용 구성 디자인 가격

	일단 새로운 버전으로 만들어서 VS2005로 C#을 처음 배우는 분들(초보자에게) 볼만한 내용인거 같구요 초보를 벗어나시길 바라는분들은 딴거를 찾아보시는게 나을거 같네요~뭐 다른책을 추천하는데가 아니라 따로 말은 안하겠습니다. 그리고 제목이 C#2.0인데 바뀌면서 추가된 문법등은 자세히 소개가 안되어있습 니다. 하튼 초보가 보기엔 적당한거 같네요