생각해보니 기존 계정이 놀고 있어서

이글루스에서 개인 계정으로 옮깁니다.

http://ckh0618.cafe24.co.kr 입니다.

인간은 자기가 보고 싶어하는 것만 보려하고, 그렇게 볼수 밖에 없다.

-율리우스 카이사르

이번주 토요일에 올만에 교보 나가서 책 찾다가 눈에 띄어 본 책이다. 원래 책으려는책은 .net Remoting 기술에 대한 책이었는데 막상 책을 들춰보니 뻘건책들이 다 그렇듯이 뜬 구름 잡는 이야기를 하길래 그냥 덮어버렸다. 강컴에서 지를려는 책이었는데 질렀으면 돈아까워 죽을뻔해따. 이래서 가끔 교보에 나와줘야 ... :)

그래도 집에 갈라면 길도 먼데 그냥 멀뚱히 서서 가기는 그래서 다른 쪽을 여기저기 돌아다니다가 이책을 발견해서 말 그대로 "그냥" 사봤다. 꽤 오래전에 나온책이라 좀 쌀줄 알았더니 드럽게 비싸더라. 그래도 따른 영양가 없는 처세따위 책 사느니 이게 그래도 낫지 않겠나 하는 생각에 질러서 읽고 있다.

유시민이라는 개인의 평가가 어떻게 되던지를 차치하고, "거꾸로 읽는 세계사"에서 보여준 그의 글은 매우 유쾌하고 날카로왔다. 몇년이 지난 후에 쓰여진 이 책에서도 여전히 매서운 필력을 자랑하고 있으니 참으로 부러운 사람이다. 말과 글은 참 잘 하는 사람이다.

미시경제부터 거시 경제까지 아울러 다루고 있는데 현재까지 읽은 바로는 "돈 안아깝다"이다. 기존의 경제상식을 뒤집는 여러가지 반례들 및 여러 이론들을 정리하여 보여주는데 각각의 반론들과 사회정세에 대한 비판이 그 답게 적나라하고 날카롭다. "저축은 선인가 악인가?" 라는 등의 물음들에 대해 여러상황들을 제시하고 해당 상황에 대한 내용을 제시한다.

마지막으로 이책에서 나한테 던졌다고 생각 하는 화두 공식(?)에 대해 논하자면...

만족 =   만족을 위하여 지출한 금액 / 인간의 욕망

이라는 공식인데... 잼나다. 역시 그래서 나는 언제나 행복하다.

체크박스 인터페이스는 단순히 Y/N을 묻는 용도에서부터, 사용자가 여러 개의 값을 선택하고 싶을 때 사용되는 인터페이스이다. 예를 들면  “여기에 체크하시면 메일을 보낼 거야 당신은 스팸 동의 한 것이니까 나중에 딴말하기 없기” 에서부터, “여길 어떻게 알고 왔어~  알려 줘. 중복 입력 가능함” 과 같은 경우를 처리하기 위해 고안된 인터페이스로서 대부분의 GUI 시스템에서 기본적으로 구현하고 있다. 그 만큼 매우 자주 쓰는 인터페이스 이다.

이어지는 내용

 SQL Server에서 제공되는 COALSCE 라는 함수명을 우리말로 풀이하면 “병합하다, 합치다” 라고 한다. 이 함수는 적절하게 사용될 경우 SQL 작성자의 노고를 획기적으로 줄여준다. 

이어지는 내용

오늘 마소가 와서 글을 읽다가 정원혁님이 쓴 SQL Server에서 날짜형을 저장할때 varchar 나 char 형태를 지양하고, datetime 이나 smalldatetime 형을 잡아 써야한다라는 기사를 읽게 되었습니다. SQL Server의 우리나라 대표적인 컨설트이고, 여러 강의나 집필활동을 활발하게 하시는 매우 능력 있으신 분의 말씀이라 물론 옮은 말을 하셨겠지만, 그래도 조금 의심가는 바가 있어 조심스럽게 제 생각을 적어봅니다.


거의 대부분의 SI 프로젝트들이 그렇듯이 사용자 조회화면에서 날짜라는 속성은 매우 중요합니다. 모든 조회화면에 포함되어있고 (예를 들면 언제부터 언제까지의 발주 목록을 보고 싶다라던가, 언제부터 언제까지 입고 잡은 내역을 보고 싶다라는등의 요구를 충족시키는...), 이 날짜조건을 저는 사용자의 조회 Rows 수를 감소시키는 가장 중요한 팩터로 사용하고 있습니다. 이 중요한 팩터로써 사용한다는 뜻은 해당 컬럼의 인덱스가 매우 중요하게 사용된다라는 뜻도 됩니다.

그런데 날짜를 저장하는 데이터형이  datetime 이나 smalldatetime 으로 되어있으면  SQL 작성하기 피곤해집니다. 예를들어 다음의 프로시저를 생각해봅시다.

CREATE PROC 매출조회 @시작일 datetime, @종료일 datetime
AS
SELECT * FROM 매출 WHERE 매출일자 BETWEEN @시작일 AND @종료일

 
만약 위의 매출이라는 테이블에서 매출일자가 datetime 으로 되어있다면 위의 조회 조건은 틀린 값을 나타냅니다. 제대로된 값을 나타내기 위해서는 다음과 같이 짜야합니다.

CREATE PROC 매출조회 @시작일 datetime, @종료일 datetime
AS
set @종료일 = @종료일 + 1
SELECT * FROM 매출 WHERE 매출일자 >= @시작일 and 매출일자 < @종료일

이유인즉 @종료일 값은 보통 'yyyy-mm-dd' 형식으로 넘어올텐데, 이 인자가 매출일자라는 datetime 형을 만나면 'yyyy-mm-dd 00:00:00' 이런식으로 바뀌어버리기 때문입니다. 결국 하루가 빠지게 되고, 모든 조회목록에서 시작일과 종료일 조건이 들어올때마다 종료일에서 하루씩 더해 그 보다 작은 값들만 가지고 와야합니다. 이는 개발과정에서 상당한 오버헤드로 작용하게 됩니다. (위에서는 날짜조건이 하나이지만 크로스탭 형태의 조회화면을 생각해보면 상당한  노가다 작업이 필요한 것을 알수 있습니다. 예를 들어 상품별 일주간 판매동향과 같은 조회형태를 상상해봅시다.)

하지만 이런 것들은 varchar나 char를 사용할땐 상당히 간편해 집니다. 직관적으로 X일 부터 Y일까지 라면 BETWEEN X AND Y 이렇게 쓰기만 하면 처리됩니다. 훨씬 직관적으로 알아보기도 쉽습니다. 또 개발자들이 실수할 여지도 적어집니다.

또한 개발자들이 다음과 같은 코드를 짜는 것을 막을 수도 있습니다.

 
CREATE PROC 매출조회 @시작일 varchar(10), @종료일 varchar(10)
AS

SELECT * FROM 매출 WHERE CONVERT(VARCHAR(10), 매출일자, 120) BETWEEN @SDATE AND @EDATE
 

위에서 말씀드린것과 같이 일자조건은 사용자의 조회 Rows를 제한할수 있는 가장 확실한 검색 조건이고, 이 조회조건에 인덱스가 걸려 있는 것은 당연합니다. 하지만 위와 같은 코드에서는 인덱스를 타지 않을 것입니다.

날짜의 정합성을 필요로 하여야 하기 때문에 datetime을 쓴다지만 VARCHAR 로 지정할 지라도  CHECK Constraint 에서 막을 수 있습니다. 데이터가 생길때 입력된 날짜가 datetime으로 변환가능한지만 검사하여 보면 됩니다.




여담으로 SQL Server를 사용하면서 참 짜증나기도하고 화도 되는 부분중에 하나가 도무지 "날짜"만 저장하는 데이터형을 만들어놓지 않았다는 것입니다. 왜 오라클처럼 날짜만 따로 저장되는 데이터형식을 만들지 않았는지, 만약 그 데이터형을 지원한다면 SQL Server 의 Cost Effiective 한 이점을 더 살릴 수 있을텐데라는 아쉬움이랄까요.

선유도의 노을 입니다.

2003년 여름에 찍었는데 벌써 시간이 이렇게 흘렀습니다.

얼른 돈 벌어서 EOS 20D 지르고 싶습니다.

강남 캐논프라자에서 한번 눌러봤는데 아주 느낌이 죽음입니다. 아 지르고 싶어라. 냉큼 돈벌어야지

얼마전 교보에서 보고 필 꽃혀서 주문했다는 그 책입니다. 교보는 좀 비싼감이 있어 사무실에서 인터넷으로 주문했는데 참 깔끔하게 오더군요. 예전에는 책을 시키면 모서리부분이 망가져서 오는 경우가 비일비재했는데 요즘은 그런것도 신경써서 보내나 봅니다. 읽은지는 꽤 됐는데 포스팅할 시간이 없어서 아쉬웠는데 오늘 아침에 잠시 짬이 생겨서 번개 포스팅 한번 해봅니다.

우야튼 각설하고...  결론은 참 좋은책이라는 것에 한표 던집니다. 요즘은 책을 참 잘 고르는 것 같아 기분이 뿌듯합니다. 최근 6개월동안 지른 책에 후회한 적이 없으니 이정도면 전적이 좋은거 맞죠 ?  역시 오프라인에서 계속 실사를 해주니 실패율이 점점 떨어지는 것 같습니다.

제목은 암호와 과학, 수학적이고 뭐 그런거 같습니다만은 제목을 좀 잘못 붙인 경향이 있지 않나 싶습니다. 암호의 역사 정도가 맞지 않을까요 ? 인류가 처음에 써왔던 암호부터 현재  컴퓨터를 이용한 암호까지 암호의 태생부터 현재 암호까지의 암호의 발달사를 다루고 있습니다.

저자가 BBC 에서 다큐먼테리를 담당했던 경력이 있어서 그런지 책을 읽는 다는 느낌 보다는  디스커버리 채널을 보고 있다는 생각이 듭니다. 그만큼 구석구석 독자를 위한 여러 장치들이 잘 마련되어있고, 실습을 원하는 독자들을 위한 연습문제까지도 제공합니다.(물론 저는 이런거 절대 안해봅니다. "절대 사서 고생하지 말자"가 저의 삶의 철학입니다. 혹시라도 저한테 답이 뭐라 묻지 마시길 .... )  어쨌던 참 잘 읽히는 책입니다. 퇴근할때 책을 들고 읽기 시작해서 책이 모두 끝날때까지 책을 덮을 수가 없어 그 다음날 출근에 상당한 애로 사항이 있었습니다.

이책에서 저자는 단순히 암호의 발달사만을 논한게 아니라 죽을때까지 자신의 한 일에 대해 비밀을 강조받고 침묵을 강요당한 여러 천재들에 대한 이야기들도 같이 다룹니다. 에그니마를 풀어 연합국에게 승리를 안겨준 튜링은 자신의 업적을 생전에 인정받지 못하고 쓸쓸히 청산가리를 묻힌 독사과를 먹고 자살을 선택하여야 했고,(Apple 의 로고인 한입 베어 먹은 사과가 튜링이 먹은 사과를 뜻한다는 이야기도 있답니다) 최초로 비대칭 암호를 발명하였으나 비밀유지의 법 때문에 미국에 특허를 빼앗겨버린 불운한 천재들의 이야기, 자신들의 언어가 암호로 쓰기에 적합하다는 이유로  전쟁터 나가 싸워야 했던 나바호족 사람들...

결국 RSA 라는 엄청난 암호가 발명되면서 암호 논쟁은 끝을 내리나 했더니 이게 또 테러리스트들에게 사용 되었을때 해독이 불가하다는 엄청난 맹점이 존재하더군요. 결국 국가의 안보를 위해 개인의 암호 사용을 허용하여야 하는것인지에 대해 논란, 개인의 프라이버시가 중요한가 아니면 전체의 이익과 안전이 중요한가에 대해서도 생각 해 봐야하는 숙제를 안겨주는 좋은책입니다.

특히 저같은 전산쟁이에 대한 교양서로는 딱입니다. 기술회의할때 아는체 할 수 있거든요 !  (이책을 읽고 나서야 RSA 가 사람의 이름 첫글자를 딴것 뿐이라는 것을 알게 되었습니다. ㅋㅋ) DES 같은 상당히 좋은 암호화 방법에 대한  설명이 빠져서 아쉽지만, 그래도 매우 만족하면서 읽었습니다.

오늘 집에 가는길에 교보문고를 들렀습니다.
엑셀책도 하나 나오라는 실장님 분부도 있고, 무슨 책들이 나왔는지 궁금하기도 해서요. 사무실에서 한 25분 정도 걸어가는데 진짜 얼어 죽을 것 같았습니다. ㅋㅋ

클래식컬한 캐럴이 나오는게 기분이 좋아지더군요. 먼저 엑셀책을 하나 고르고, 무슨 신간 나왔나하고 이리 저리 한 시간 동안 돌아다니는데 매우 좋았습니다. 일전 시티 문고에 갔을때는 너무 책들이 없어서 좀 그랬는데 역시 교보는 틀리긴 틀리더군요. 여러 재미있어 보이는 책들이 나좀 사가라 하고 재촉하는데 휴우 카드값 또 오바될 뻔했습니다.

인터넷에서 아무리 책을 싸게 팔아도 오프라인 서적에서 책을 사는게 더 좋은 것 같습니다. 여러 제목들만 보고 혹해서 질렀다가 후회한 적이 한두번이 아니라서요. 물론 현명한 소비자들은 오프라인에서 책을 살펴보고 온라인에서 산다고들 하는데..  ㅋㅋ 이넘의 성질이 급해서 하루 이틀을 못기다리니 이게 문제입니다.

그래도 재정의 압박이 있어 오늘 부터 현명한 소비자로 거듭나기로 했습니다. ㅋㅋ

CODE BOOK 이라는 책을 하나 지를 생각입니다. 인터파크에서 찾아보니 적립금이 무려 20% ㅋㅋ

다음부터는 서점갈때는 메모지 들고 다녀야 겠네요 ㅋㅋ  요즘도 카메라폰으로 찍으면 뭐라할라나요 ?

제가 다니는 회사는 SCM/POS 솔루션을 만들고 있습니다. 우리 말로 하면 "공급망 관리" / "판매시점관리"정도 된다는군요. 우리 생활에서 예를 들자면 편의점에서 물건을 사면 컴퓨터로 계산하지요 ? 그게 바로 POS 란 놈입니다. 그걸로 주문도 넣고 하지요. 그럼 본부에서는 시스템에서 그 주문을 받아다가 더 윗단계 있는 공급업체에 또 발주를 넣고 그렇고 그 물건을 소매상 또는 일반 고객에게 납품하고 뭐 그런거죠. 우야튼 뭐 각설하고.

여러지역에서 다중사용자들이 동시에 쓰이는 프로그램이고 사용자의 접근성이 용이하여야 하기 때문에 Web Interface 를 사용하여 개발하고 있는데 뭔가 좀 아닌가 싶다라는 것이 저의 생각입니다.

Web 은 해당 인터페이스가 매우 직관적이고 사용자들이 간단하게 배워 사용할 수 있다는 장점이 있기도 하지만 그만큼 사용자들이 사용할 수 인터페이스의 종류나 편의성 면에서는 기능적 측면에서 떨어집니다. 예를 들어 엑셀파일로 작성된 주문내역을 시스템에 입력한다고 할때를 생각해봅시다. 파일첨부버튼을 눌러 해당 파일이 있는 위치를 찾아 해당 파일을 선택하고 버튼을 눌러 파일을 서버에 업로드하면서 진행과정을 기다려야 합니다. 하지만 일반적인 C/S를 통하여 작성한다면 단순히 해당 파일을 드래그해서 해당 폼에 떨어뜨리면 그만입니다.

여러 상황에 대한 단축키 지원, 비동기통신, 자동 생성 또는 완성기능등을 볼때 실제 사용자들이 더 편리하고 개발자들이 쉽고 간편하게 개발할 수 있는 방법은 아무래도 Windows UI 만큼 제대로 된 것은 없죠.

개발자의 입장에서 생각해봐도 어느정도 CS 형태의 인터페이스를 Web으로 구현하기 위해서는 수많은 자바스크립트 및 DHTML과 싸워야 합니다. VB나 델파이등의 기반이라면 해당 폼에 더블클릭한번하고 해당 처리 코드 몇줄 작성하면 끝날것을 말이죠.

"MS Office 류의 사용자 UI에 길들여진 사람들은 웹을 점점 꺼려하고 있다. Web 시대보다는 다시 Fat Client 들이  창궐하게 될것이다" 라고 어느 누군가 유명한 양반이 쓴 글을 본적이 있는데 어느정도 공감하는 바입니다. 제대로된 개발툴(ASP.NET 빼고)도 없는 바닥에서 같이 일하는 웹개발자가 Javascript 며 css 등을 만지면서 머리 아파하는 모습을 보면 안쓰럽기도 합니다. C/S 환경이라면 코드 몇줄이면 끝날일을 머리 싸매고 짜야되는 ...

물론 전체적으로 모든 인터넷이 다 Fat Client 로 전향하여야 된다는 말은 아닙니다. 업무용 프로그램 제가 만드는 SCM 이나 CRM 솔루션 등등은 CS 로 가는것이 더 맞지 않나라는 생각이 들뿐입니다. 어차피 사람이 편하자고 만든건데 사람이 편하지 못하고 오히려 단순노동을 시키는 웹인터페이스는 더이상 업무용 인터페이스는 아니지 않나라는 생각을 해봅니다.