라떼군 이야기

Honeypot을 이용한 사내 보안 솔루션 구축

라떼군 — Mon, 21 Sep 2009 00:54:07 +0900

최근 꿀단지(Honeypots) 이론이 주목을 받은 적이 있었으며 이를 이용한 침입자 유인방법 및 관련 기능을 포함한 솔루션들이 출시되고 있는 추세이다. 이에 따라 간단히 Honeypots에 대해 알아보고 사내 보안 솔루션 구축에 대한 대안을 제시 하고자 한다. (아래 글 부터는 Honeypots 대신 꿀단지로 번역해 사용할 것이다.)

꿀단지를 이용해 실제 서비스하는 호스트인 것처럼 속이거나 공격자나 침입자를 유인할 수 있다. 하지만, 이 방법으로 구성하려면 침입자가 꿀단지 호스트를 통해 실제 서비스에 영향을 줄 수 있지 않도록 네트워크 구성을 분리해야 하고 안전한 망 구축을 위해 스위치 및 방화벽 장비의 추가 투입이 불가피한 것으로 보인다. 인적 자원 및 물적 자원의 투자가 불가피함에 따라 구성에 상당한 규모의 서비스 및 기업에서만 가능한 방법이라고 생각한다.

가상 기계(Virtual Machines) 또는 가상 꿀단지(Virtual Honeypots)의 방법도 물리적인 네트워크를 구성해야 하는 부담은 적지만 침입자를 온전히 속이려면 가상화를 지원하는 VMware, MS의 Virtual PC, Sun의 Virtual Box같은 소프트웨어(windows 2008의 가상화 기능도 마찬가지이다.)를 사용해야 하므로 해당 호스트의 성능에 따라 가용성의 차이가 커지므로 제대로 된 침입자 유인 서비스를 구성하려면 고 가용성의 호스트 장비가 필요하게 질 것이다.

이와 같은 이유 때문에 중소기업에서 꿀단지 기법을 이용해 다수 또는 가상의 침입자를 유인하는 시스템을 구성하여 침입자를 유인하고 지속적으로 살핀다는 것은 실제적인 여건상 힘들 수 있다. 실제 서비스에 대해 침입자를 유인하여 분석하는 대신 실제 서비스 네트워크와 분리된 내부 네트워크에서 일어나는 정보유출에 오히려 더 신경 쓰는 것이 더 효율적이다. 이런 기업들은 작은 정보 유출에도 회사 존립에 문제가 될 수 있기 때문에 내부자료 보안에 더 신경 쓰는 것이 현명할 것이다.

Honeynet 은 공격자가 시스템에 침입하기 위해 사용하는 방법으로 침입 도구에 대해 연구하기 위해사용 되고 있다. 이는 일부러 공격당하도록 구성된 시스템들로 이루어진 네트워크를 말하는데 방화벽 시스템(Firewall)이나 모든 incoming/outgoing 연결을 로깅하기 위한 NAT 서비스를 제공할 수도 있고 침입탐지 시스템(IDS)을 이용해 때로는 방화벽이 설치된 시스템에 함께 설치하기도 한다. 모든 네트워크 트래픽을 로깅하며, 알려진 공격을 감시할 수도 있다.

기존의 Honeynet은 꿀단지를 이용해 침입자를 유인하는 쪽에 치중해 있다고 한다면 거꾸로 꿀단지를 이용해 사내 또는 비밀이나 보안이 필요한 네트워크에 비밀자료 유출방지 및 사용패턴의 시스템 분석을 위한 꿀단지의 운영할 것을 제안하고 싶다.

기존 구성된 내부 네트워크에 설치된 웹 서비스나 SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol)나 방화벽 등을 꿀단지 기법으로 구현해 내부 직원에게는 비밀 하에 설치하며 실제 서비스처럼 운영해 볼 수 있을 것이다. 꿀단지의 로그 데이터 분석을 통해 사내 네트워크에 취약점 및 자료 유출 실태를 분석할 수 있을 뿐만 아니라 나아가서는 취약점 보완에 기여할 수 있을 것이다.@

참고자료
http://technet.microsoft.com/ko-kr/library/cc700732.aspx
http://www.honeynet.org/

스티브 잡스(Steven Jobs)의 우주관

라떼군 — Mon, 21 Sep 2009 00:51:58 +0900

'I want to put a dent in the universe.'

위에 '나는 우주에 영향을 미치고 싶다.'라는 말은 스티브 잡스(Steven Jobs)가 최초의 GUI 환경 개인용 컴퓨터인 '리사(Lisa)'프로젝트에 돌입하면서 개발팀에게 한 말이다. 정말이지 스티브 잡스의 업적은 우주에서도 알고 있지 않을까? 하는 생각이 들 정도로 놀랍고 위대하다. 그는 때로는 돌출적인 행동을 하기도 하였지만 일할 때에는 원리원칙주의자이고 때로는 가벼운 티셔츠와 청바지를 입고 프레젠테이션을 할 만큼 개성적이며 권위주의 타파에 힘쓰기도 하였다.

스티브 잡스는 너무나 잘 알려진 대로 굴곡 많고 화려한 인생을 살고 있다. 그는 애플컴퓨터(Apple)의 설립자이지만 그가 추진한 리사(Lisa)프로젝트의 실패 이후 해고당하게 된다. 그 후 넥스트(Next)사를 설립하였고 비록 성공하지는 못했지만, 세계 최초의 객체지향 운영체제를 만들었다는 업적을 세웠다. 그는 또 한 번의 실패에 포기하지 않고 픽사(Pixar)를 설립하였고 그 유명한 최초의 장편 3D 애니메이션인 '토이 스토리(Toy Story)'를 탄생시켜 영화계에 일대 충격을 가한다. 결국에 그는 성공한 것이다. 이런 그의 성공은 여기에서 멈추지 않는다. 그는 결국에 해고당한 지 12년 만에 애플 CEO로 다시 복귀하게 되었고 혁신적인 상품인 아이맥(iMac)을 개발해 현재 애플을 적자에서 흑자로 바꾸어 놓았다. 아직도 그는 iPod 과 iTunes를 통해 아직도 애플을 꾸준히 성장시키고 있다.

스티브 잡스가 성공한 이유는 그가 자신의 처한 상황을 받아들이고 그것을 이겨내려고 노력한 것에서부터 시작한다. 실제로 그의 명연설 중 하나로 꼽히는 스탠퍼드 대학(Stanford University) 졸업식 연설에서 '당시에는 몰랐지만, 애플에서 해고당한 것은 제 인생 최고의 사건임을 깨닫게 됐습니다.'라고 회상하고 있다. 그뿐만 아니라 그는 '그 시기가 자유를 만끽하며 내 인생의 최고의 창의력을 발휘할 수 있는 시기였다.'라고 덧붙여 말함으로써 오히려 그런 상황을 잘 이겨냈을 뿐 아니라 그것을 넘어 그런 상황을 즐겼음을 알 수 있게 해준다.

대부분 사람이 실패나 어려움이 닥쳤을 때 쉽게 포기하는 이유는 그런 어려움 속에서 자신이 얼마나 더 강해질 수 있는지 알지 못하기 때문이다. 어떤 일이든지 아무 어려움 없이 얻어지는 것은 없다. 처음으로 자전거 탔을 때를 생각해보라. 당신은 균형을 잡지 못해 뒤에서 잡아주지 않는다면 도저히 자전거를 타지 못할 것 같다고 생각했을 것이고 어떤 사람들은 그런 시기에 아예 자전거 타는 것을 포기하기도 하였을지도 모른다. 하지만, 결국 이겨낸 사람들은 이내 머지않아 능숙하게 탈 수 있을 뿐 아니라 만약 누군가 또다시 뒤에서 잡아주려고 한다면 귀찮고 거치적거려서 오히려 타는데 방해만 될 뿐이라고 생각할 것이다. 결국, 어려움을 이겨낼 때 처음에는 불가능해 보였던 그것을 해내는 강해진 자신을 확인하게 되는 것이다.

기업도 마찬가지라고 생각한다. 맥킨지(mckinsey) 컨설팅의 조사를 따르면 기업평균수명은 점차 감소해 현재 15년 정도까지 줄어들었다고 한다. 하지만, 그와 상반되게 신기하게도 기업이 30년 이상 지속한다면 경영성과는 월등하게 좋아진다는 결과도 있다. 즉, 기업이 지속한 이후 20년 정도에 가장 낮은 경영성과를 이루다가 30년 이후에 다시 성과가 좋아지는 '스마일 커브(Smile Curve)' 현상을 볼 수 있다고 한다. 기업도 사람과 마찬가지로 어려움을 이겨낼 때 더욱 뿌리가 단단한 기업으로 성장할 수 있는 것이다.

수년 전 지금 회사로 이직하기 이전 조그만 소프트웨어 회사에 다녔었다. 처음 몇 달간은 회사 상황이 나쁘지 않았으나 점차 경영 악화로 상황이 안 좋아지기 시작했고 나는 그런 모습을 가까이서 끝까지 지켜봐야만 했었다. 이윤 추구를 목적으로 하는 회사라는 조직이 원래 목적을 이루지 못했을 때 주위 사람들을 얼마나 힘들게 할 수 있다는 것을 확인하고 몸소 체험한 시기였다. 그 당시 상황이 나를 너무 힘들게 해 두 번 다시 겪고 싶지 않지만 나에게 약이 되었던 소중한 경험에 감사하고 있다.@

영화 클릭(Click)

라떼군 — Mon, 21 Sep 2009 00:49:21 +0900

2006년도에 개봉했던 영화 중에 클릭(Click)이라는 영화가 있었다. 아담 샌들러(Adam Sandler)가 주연으로 나오는 코미디 영화다. 나는 다른 남자들처럼 SF나 전쟁영화도 즐겨 보기는 하지만 특히 코미디 영화를 더 좋아하는 편이다. 그러나 그냥 단순히 웃기기만 하는 영화는 좋아하지 않는다. 나는 그 이면에 영화가 전하고자 하는 메시지가 있는 영화가 좋다. 클릭이란 영화는 바로 그런 영화이다.

주인공인 마이클 뉴먼(아담 샌들러)은 건축가이고 아내와 아이들과 같이 살아가고 있다. 그는 건축가이며 모두가 부러워할 만한 아름다운 아내와 아이들과 같이 살아가고 있음에도 항상 만족하지 못한다. 그는 더 나은 삶을 원하고 그것을 위해 건축가로 더 높은 성공을 원한다. 그러던 어느 날 우연히 특별한 리모컨을 갖게 된다. 인생을 빨리 돌릴 수 있는 그런 만능 리모컨이다. 하지만, 성공에 너무 집착한 그는 리모컨을 오용해 결국엔 가장 소중한 아내와 아이와 자신의 건강까지 모든 것을 잃어버리게 되고 그때가 돼서야 비로소 그것들의 진정 소중함을 깨 닳게 되는 내용이다.

대부분 사람은 자신에게 주어진 환경들에 대해 만족하지 못하고 살아간다. 좀 더 나은 직장을 원하고 좀 더 높은 봉급을 원하고 좀 더 넓고 비싼 집에서 살기를 원한다. 때로는 남이 가진 것을 부러워하기도 한다. 내가 타는 차보다 더 좋은 차를 타고 싶어하고 더 좋은 집에서 살기를 원하고 좀 더 나은 직업도 갖기를 원한다. 하지만, 이렇게 부러워하기 전에 자신이 얼마나 많은 것을 이미 가졌는지 돌아보는 것이 바람직하다. 이 모든 것이 영화에서 말하는 것처럼 자신에게 주어진 것에 대해 만족하지 못하는 마음에서부터 생겨난 것일 수도 있기 때문이다.

사실 인간의 능력은 제한적이다. 뭐든 잘해내는 만능 인간은 아마 이 세상에 없을 것이다. 그래서 이런 제한적인 능력으로 짧은 인생을 살아가려면 어느 정도 선택이 따르기 나름이다. 인생을 성공에 바칠 것인가 아니면 또 다른 중요한 무엇에 집중할 것인가는 지극히 선택적인 문제이다. 미국 문화와 성공한 CEO의 상징인 스티븐 잡스(Steven Paul Jobs)의 '주 90시간, 즐기면서 일하자!' 처럼 일에 집중한 사람은 그만큼 일에 대한 보상을 받을 것이지만 다른 한편으로 잃는 부분이 분명히 생길 수밖에 없다.

내가 고등학교 다닐 때에 시험기간만 되면 공부 잘하는 애들이 공통으로 하는 말이 있다. 어제 공부하려고 했는데 일찍 잠들어 버렸다느니 티브이를 보다가 공부를 하나도 못했다느니 하는 말이다. 그렇다면, 시험 성적은 분명히 나빠야 하지만 결과는 절대 그렇지 않다. 그들이 정말 공부 하나도 하지 않았는데 성적이 좋은 것일까? 처음에는 나도 그런 줄만 알았다. 하지만, 우연한 기회에 그것들이 거짓말인 것을 알게 되었다. 그들은 다른 아이들보다 평소에 많은 것을 포기하고 공부를 하고 있었다. 만약 시험 전날 일찍 잠들었다면 평소에 다른 사람들보다 훨씬 더 많은 노력을 해왔던 것이고 티브이를 보았다면 이미 공부를 끝낸 상태였을 것이다.

비록 드라마의 내용이긴 하지만 베토벤 바이러스에서도 이런 비슷한 내용을 볼 수 있다. 정명환이라는 강마에(건우) 친구가 등장하는데 그는 천재여서 모든 것을 큰 노력 없이 잘할 수 있는 것처럼 다른 사람들에게는 보이긴 하지만 사실은 그 뒤에 보이지 않는 곳에서 항상 강마에에게 지지 않으려고 부단히 노력했다는 것을 볼 수 있었다.

드라마의 내용을 조금 더 빌리자면 천재라고 불리던 모차르트(Mozart, Wolfgang Amadeus, 1756~1791)마저도 작곡하면서 놀았다고는 생각하지는 않을 것이다. 놀면서 작곡했다면 그런 곡이 나올 수 없기 때문이다. 그의 짧은 35년생에의 600여 곡을 작곡한 것을 생각해보면 경제적으로 어려웠던 환경과 순탄치 않았던 가정생활 그리고 짧은 생애가 얼마나 많은 것을 포기하고 작곡에 매달렸는지 감히 짐작해 보게 한다.

누구나 자신의 삶에 대해 선택을 해나가고 있고 각자 주어진 시간에 대해 나름대로 가치를 찾아가고 있기 때문에 어떤 것이 더 가치 있는 삶이라고 절대로 단정 지어 말해서는 안 된다. 내가 한 시간 공부하는 이 시간에 다른 누군가는 잠을 잔다거나 티브이를 보고 있거나 게임을 하고 있다고 하더라도 공부하는 시간이 더 가치 있게 보낸 시간이고 다른 시간은 헛되이 보낸 시간이라고 단정 지어서 말해서는 안 된다는 뜻이다. 모두에게 공평하게 주어지는 시간에 대해 각자 자신에게 필요한 가치를 찾았다면 그것이 진정 가치 있게 시간을 보낸 것으로 생각해야 할 것이다.

나는 인생을 살아가는 시간보다는 죽음에 초점을 맞춰서 살아가고 싶다. 죽음이 내 앞에 닥쳤을 때 영화 클릭에서 보았던 리모컨으로 내 과거를 회상해 보고 잘살았노라 회상하고 싶다. 코미디 영화임에도 주인공이 죽음에 닥쳐 이미 잃어버린 아내와 자식들에게 잘못을 뉘우치고 과거를 회상하는 장면에서 나도 모르게 눈물이 났던 이유는 어쩌면 누구나 공감하는 내용 때문이었는지 모른다.@

해커는 화가를 닮지마라

라떼군 — Mon, 21 Sep 2009 00:46:39 +0900

폴 그레이엄 (Paul Graham)의 해커와 화가라는 책을 읽고 난 후부터 얼마 전까지만 해도 나는 프로그래머와 예술을 하는 화가가 예술적인 작품을 만들어간다는 점에서 매우 닮아있다고 생각했었다. 사실 더욱더 그렇게 믿고 있었던 까닭은 아마 폴 그레이엄뿐만 아니라 그에게 영향을 받은 많은 사람이 비유를 통해서 프로그래머와 화가의 예술적 공통점 찾고자 했었기 때문에 지금까지 그렇게 내가 믿고 있었는지도 모르겠다.

그러나 얼마 전 미술전을 다녀오고 나서 생각이 바뀌게 되었다. 많은 천재적이었던 화가들이 다시금 칭송받는 이 시대에 프로그래머들이 자신의 활동들을 예술적 경지로 끌어올리기 위한 마음을 전혀 이해하지 못하는 것은 아니지만 그렇다고 해서 예술적인 부분과 동일시하는 데에는 문제가 있어 보인다는 다고 생각하게 되었다. 프로그래머와 화가는 그 근본부터가 전혀 다른 것이다. 프로그래머와 화가가 닮은 부분은 어떤 작품을 만들어가는 그 정신일 뿐이지 그것에 대한 모든 활동과 과정들이 닮아있다고 생각하는 것은 문제가 있다.

예전에 베트남으로 출장을 갔을 때의 일이다. 베트남 개발자들이 어떻게 일하는지는 가까이서 볼 기회가 있었는데 놀라운 것은 자신의 실력에 상관없이 소프트웨어를 개발하고 있다는 자부심이 굉장히 강하다는 사실이다. 그들은 창조적인 작업을 하고 있다고 생각하고 있었고 그만큼 대우받아야 한다고 생각하는 듯이 행동하는 것을 볼 수 있었다. 민족적인 차이를 고려하고 보았을 때에도 나로서는 받아들이기 어려운 일이었다. 나는 이것들이 모두 소프트웨어와 예술작품을 만들어가는 과정을 동일시하는 데에서 오는 착각이라고 생각한다.

프로그래머는 화가들처럼 창조적이지 않다. 소프트웨어는 먼저 요구 사항에서부터 시작된다. 요구를 만들어내는 사람(제품 기획자, 고객 또는 프로그래머 자신일 수도 있다.)있고 그 요구에 맞추어 작성되는 것이 소프트웨어이다. 요구에 맞고 그 기능에 문제가 없다면 좋다고 말할 수 있고 요구에 맞지 않는다면 그냥 간단히 Shift+Del 키를 눌러서 그냥 삭제해버릴 뿐이다.

하지만, 화가들이 그려내는 예술적인 작품은 그렇지 않다. 돈을 벌려고 고객들의 요구를 들어주기는 하지만 결과물들을 판단하는 우리의 눈에 비치는 그림들은 그런 요구 말고도 하나같이 작가 개개인의 깊은 생각들을 추가로 담아내고 있다. 가장 널려진 ‘레오나르도 다 빈치 (Leonardo da Vinci)’의 작품 ‘모나리자 (Mona Lisa)’도 누군가의 요구로 만들어진 초상이기는 하지만 저자의 의도가 드러나 있다. 그 인물의 눈썹에서부터 미소, 손동작 및 배경까지 그냥 그려졌던 것은 없다. 하지만, 소프트웨어는 좋고 나쁘고 맞고 틀림의 구분이 명백하다. 분명히 예술작품의 그것과는 확실히 다른 부분이다.

또한, 예술작품은 시간이 흘러도 그 작품성을 인정받는 데 반하여 소프트웨어는 그렇지 않다. 예술작품은 500년, 천 년이 흘러도 그것의 감동이 고수라니 사람들에게 전해진다. 1500년대를 살았던 브뤼헐(Pieter Bruegel)이나 1600년대를 살았던 람브란트(Rembrandt van Rijn)이 아직도 사랑받는 이유는 이 때문일 것이다. 하지만, 소프트웨어는 30년은커녕 짧게는 고작 1~2년이 지나고 나서는 언제 그랬느냐는 듯이 그것에 대한 혹평이 이어지는 것이 현실이다. 심지어는 당신은 몇 일전에 개발한 프로그램을 바라보며 지금도 속으로 욕하고 있을지도 모른다.

예술작품은 시간이 흘러도 많이 배운 사람이건 아니건 간에 그것을 보는 이에게 개개인 나름대로 감동을 준다. 각자 해석하는 방법은 다를 수 있지만, 감동 주는 것은 같다고 하겠다. 하지만, 소프트웨어는 전혀 그렇지 않다. 심지어 전혀 감동적이지 않다. 적어도 예술작품과 비교할 정도라고 하면 컴퓨터에 친숙한 사람이건 아니건 간에 그 소프트웨어를 접했을 때 전해져 오는 예술작품과 비견할만한 정도의 감동수준이 있어야 한다고 생각한다. 이것이 소프트웨어 개발을 공학적으로 접근해야 하는 가장 명백한 이유일 것이다.

무작정 예술작품과 동일시하고 자신의 지위를 격상코자 목소리를 내기에 앞서서 그만큼 예술작품을 만드는 정신으로 소프트웨어를 만들었는가부터 자답해보는 것이 바람직하다. 예술작품에 대해 우리가 먼저 배워야 하는 것은 소프트웨어를 개발하는 데 있어서 예술작품을 만들어가는 과정과 같은 많은 노력과 고통과 헌신을 먼저 배워야 하는 것이 아닐까?@

의도를 파악하라

라떼군 — Mon, 21 Sep 2009 00:43:52 +0900

아마 개발자라면 누구나 잘 갖춰진 환경에서 개발 하고 싶을 것이다. 잘 갖춰진 환경이란 개발프로세스 또한 포함할 것이면 그것은 결과적으로 결과물도 좋게 만들리라 생각할 것이다.

어떤 일이든 간에 잘하고 싶다면 나보다 나은 사람에게 배우는 방법이 가장 빠른 방법일 것이다. 특별한 몇몇은 다를 수도 있겠지만 보통 사람이라면 혼자서 어떤 것을 진정 그것이 의미하는 것을 알아가는 것은 많은 시간이 필요하다. 하지만, 어떤 것은 시간을 많이 들여도 불가능한 것도 있다. 그래서 사람들은 더 빨리 잘해지기 위해서 책을 읽는다든지 하는 방법으로 나보다 더 잘하는 사람들에게 배우려고 노력하고 있다.

개발에서도 마찬가지이다. 개발하기 좋은 환경을 갖추고 싶다면 먼저 그런 환경을 겪었던 사람들에게 배우는 것이 가장 효과적이다. 하지만, 일부 사람들같이 맹목적으로 그것을 모두 수용하다가는 오히려 부작용을 낳을 것이다. 가장 중요한 것은 그것들의 ‘의도’를 제대로 파악하는 것이 중요하다.

'의도를 파악하라'라는 말을 그토록 강조해서 처음 들어본 곳은 예전에 개인적으로 참가했던 이봉석님의 세미나에서였다. 이봉석 님은 하제 소프트 대표이사이시고 디바이스 드라이버와 관련해 우리나라에서는 어느 정도 권위 있는 분이다. 그분 세미나는 물론 주제의 내용도 좋았지만, 그것보다 개인적으로 더 좋았던 것은 어떤 것을 보더라도 항상 그것의 의도를 파악하려고 노력해야 한다는 학습방법(?) 같은 것을 깨 닳은 것이다. 책에 그려진 삽화 같은 것이 그런 예가 될 수 있을 것이다. 단순히 그어진 선일지라도 저자가 분명히 말하고 싶은 내용이 있을 것이고 그것을 파악하는 사람만이 그것의 진정한 의미를 알 수 있다.

나는 그 후부터 어떤 그림 하나를 보더라도 저자의 의도를 파악해 보려고 많이 노력하고 있다. 저자의 의도를 이해하려는 노력 없이 내 생각대로만 읽는다면 아마 내용의 오인으로 말미암아 오히려 독이 될 수도 있을 것이다. 핑계이긴 하지만 때문에 요즘 나는 많이 읽기보다는 하나를 봐도 좀 천천히 보는 편이고 기술서적 독서량은 좀 줄은 편이 되었다.

요즘 나는 한참 관심을 두고 있었던 부분은 현재 개발하는 프로젝트의 인지도 향상에 관한 부분이었다. 나는 개발자이기 때문에 개발 이슈에서부터 이런 인지도 향상의 방법을 찾고자 노력했었는데 그것 중 한 가지가 CMMI(Capability Maturity Model Integration, 역량 성숙도 모델 통합)[1]에 대한 부분이었다.

물론 우리 팀이 CMMI 5단계의 인증을 받는다면 하면 인지도 향상 및 프로젝트를 내다 팔 수 있는 시장이 엄청나게 확대될 수도 있을 것이다. 하지만, 실제 프로세스 개선을 위해 만들어진 이것이 프로젝트의 인지도를 향상시키는 데 얼마나 도움이 될 것인지는 의심해볼 만하다. 심지어 그런 의도를 가지고 접근한 기업이 CMMI의 인증을 받기 엄청난 비용(컨설팅 비용까지 1억~1억 5천만 원 정도)의 소요와 CMMI 1.2의 유효기간 3년의 제약조건을 버텨낼 수 있을 지가 의문스럽다. 원래 의도대로 프로세스 개선을 위한 방향 지침 정도로 생각했어야 했다. 이것을 오인해 대박을 내게 해주는 만능 도구로 생각했던 것이 잘못 이였던 것이다.

개발 세계에서는 그것의 의도를 파악하지 못해 잘못 해석하고 그 때문에 오류를 발생시키는 일들은 엄청나게 많다. 비단 CMMI에 대한 내 생각에 대해서만 예를 들었지만 이렇게 의도를 파악하지 못하는 곳에서 발생하는 오류는 수없이 많을 수 있다. 기술적으로 가장 기본적인 스킬인 언어 문법의 의도와 API 함수와 클래스의 의도, 시스템 구성의 미들웨어(middleware) 및 각각 프로그램들, 데이터베이스 스키마(schema)의 의도를 먼저 잘 파악하는 것이 가장 중요한 부분이 될 것이다. 더 나아가서는 상사나 동료 직원과의 의사소통이나 기타 업무 처리 능력도 의도를 얼마나 잘 파악했는지에 달렸다고 말할 수 있을 것이다.@

Software의 Accessibility

라떼군 — Mon, 21 Sep 2009 00:42:17 +0900

얼마 전 편의점에서 커피를 사먹었던 적이 있었는데 놀라운 것을 발견하였다. T-money 단말기가 계산대 옆에 있는 것이었다. 하도 신기해 보여 일하시는 분께 T-money로도 계산할 수 있는 거냐고 물어보니 그렇다고 했다. 그 후 며칠간 T-money가 머릿속을 떠나지 않았는데 그날 이후 나의 생활권에서 T-money로 할 수 있는 것들이 참 많이 눈에 들어왔다. 먼저 T-money로 버스, 지하철을 탈 수 있고 심지어 현금이 없을 때는 택시도 탈 수 있다. GS25, 훼미리마트, 세븐일레븐, 바이더웨이, 미니스톱등 거의 모든 편의점에서 사용할 수 있을 뿐 아니라 연말이 되면 구세군 자선냄비에 꾸깃꾸깃 돈을 넣는 대신 T-money를 찍어줄 수도 있다. 상황이 이 정도니 가까운 미래에 부모님이 아이들 용돈 줄 때 잃어버리기 쉬운 현금을 주는 대신 T-money를 충전해 주는 일도 머지않은 것 같다.

T-money는 2004년 7월 서울특별시가 대중교통 체계를 개편하면서 새 교통카드로 도입하면서 사용하게 되었다. 특이한점은 스마트카드(Smart Card)라는 점이다. T-money 이전 교통카드 유패스(Upass)는 저가형 Mifare(MIFARE Standard 1k, Ultralight)기반의 메모리 카드이고 Mifare Ultralight가 암호화 없는 512bit의 작은 저장용량만 지원한다는 것과 달리 T-money는 IC(Integrated Circuit) Chip을 내장하고 있다. 이런 스마트카드인 T-money의 특징은 자체적으로 마이크로프로세서와 운영체제를 가지고 데이터의 자체연상과 암호화(T-DES와 SEED)가 가능하기 때문에 I/O가 없는 작은 컴퓨터라고도 불리고 있다는 것이다. 또한, T-money를 IC Card 국제 규격과 ISO 기준을 준수하고 있다고 한다.[1] (T-DES[2]는 Triple DES를 말하는 것이라고 생각되고 SEED는 정보보호진흥원(KISA) 에서 개발한 SEED 블록 암호화 알고리즘을 말한다.)

현재 상황이 이 정도이다 보니 그동안 통신사들이 하고 싶어하던 지급수단의 결합 즉, 이상적인 결합이었던 신용카드(예: MONETA, 통신 업체의 카드사 인수 등)와 이동통신기기의 통합은 결국 인프라 부족으로 말미암아 사람들의 외면과 대한민국 전 국민의 1/4 이상이 거주하는 서울시 포함 경기도의 정책 탓에 이미 T-money의 승리가 예상되고 있는 것이 아닐까 생각된다. T-money의 승리는 T-money가 대단한 기술력을 바탕으로 한 획기적인 서비스이기 때문이 아니라는 점에서 나는 주목하고 있다. 사람들의 사용이 편리함 즉, Accessibility(접근성)의 승리라고 생각한다.

이와 마찬가지로 소프트웨어 산업에서도 성공하는 소프트웨어가 되려면 Accessibility를 중요시해야 한다고 생각한다. 나는 MSN 메신저와 Windows Live[3]서비스를 사용하고 있다. 개인적인 평가로(주위 몇몇 지인들의 평가 포함) Google 서비스가 Windows Live보다 쓰기 편하고 웹 기발 서비스로는 기술적으로 앞서고 있다고 생각하고는 있으나 MS와 Windows 운영체제 그리고 내가 주로 쓰는 MSN 메신저와 Hotmail과의 연동 부분 등 때문에 옮겨가지 못하는 것이다. 결국, 나는 Accessibility가 사용할 서비스를 결정할 때 가장 중요한 부분을 차지하고 있는 것이다. 싸이월드(Cyworld)와 네이트온(NateOn)과의 결합도 마찬가지로 볼 수 있다. 싸이월드가 먼저인지 네이트온이 먼저인지는 알 수 없으나 싸이월드와 네이트온은 Accessibility의 이유로 서로 기여하고 있음이 틀림없다.

어느 한 소프트웨어를 킬러 소프트웨어(Killer application)[5]로 만들어 사용자들에게 널리 사용되기 위해 노력하고 그것을 성공의 목표로 삶는 것도 좋다. 하지만, 그것만을 목표로 한다면 어떤 다른 소프트웨어가 출시되었을 때 언제든 그 자리를 빼앗길지 모른다고 불안해 매일 밤잠을 설쳐야 할지도 모른다. 이와 반대로 Accessibility가 강조된 소프트웨어는 그렇지 않은 소프트웨어보다 더욱 안정적인 발전을 이룰 수 있으리라 생각한다.@

[1] http://ko.wikipedia.org/wiki/T-money
[2] http://www.answers.com/topic/tdes
[3] http://en.wikipedia.org/wiki/Windows_Live
[4] http://www.liveside.net/main/archive/2007/01/06/google-calendar-catches-msn-s-or-where-oh-where-is-the-wl-calendar.aspx
[5] http://en.wikipedia.org/wiki/Killer_application

'영화는 영화다'를 보고

라떼군 — Mon, 21 Sep 2009 00:39:21 +0900

이번 추석 연휴기간 동안 소지섭, 강지환 주연의 '영화는 영화다'라는 영화를 보게 되었다. 보고 나서 느낀 점은 많았지만 먼저 재미있었는지 추천할만한지를 물어보신다면 나는 추천할만한 영화라고 말하고 싶다.

스포일러(spoiler)가 되고 싶진 않기에 간단하게만 내용을 요약하면 극중 영화배우로 등장하는 강지환(장수타)와 진짜 깡패로 등장하는 소지섭(이강패)이 영화를 찍는 내용이다 실제 깡패로 살아가는 소지섭은 인생 자체가 목숨을 걸만큼 치열한 삶이기에 그런 삶을 흉내만 내는 강지환을 못마땅해 한다. 처음에 강지환은 소지섭의 삶을 이해하지 못했지만 영화를 찍어가며 조금씩 이해해 간다. 하지만 이해한 듯 보였던 소지섭의 삶이 정말로 그 속에서 목숨을 걸만큼 치열한 삶을 살아보지 못한 강지환에게는 결국 결코 이해하지 못한 삶이 된다는 그런 내용이다. (개인적으로 영화 내용을 해석한 것이라 실제 보는 사람과의 이해가 다를 수 있겠다.)

나는 이 영화를 보고 나서 감독이 말하고 싶은 것은 바로 '인생의 치열한 삶' 이라고 생각했다. 극중 강지환처럼 가짜 흉내 내는 것만으로는 실제 그것들을 업(業)으로 삶고 있는 사람들을 결코 이해하지 못할 것이다. 내가 마치 예술 하는 사람들을 이해하려고 들거나 의사나 변호사들의 삶을 이해하려 드는 것과 마찬가지 일 거란 생각을 했다. 겉으로는 그 사람들의 삶이 좋아 보일지 몰라도 그것은 업으로 삶고 있는 사람들에게만 있는 생존과도 연관되어 있기에 그 자리를 지키기 위해서는 남들이 모르는 힘겨운 삶을 살아가고 있는 것이다.

요즘 이곳 저곳에서 치열한 삶을 주제로 하는 책들이 쏟아져 나오고 있다. 그 책들에는 한결같이 치열하게 살아야 한다고들 말하고 있다. 하지만 나는 그렇게 살기를 원하지 않는다. 나는 여유롭고 평화롭고 자유롭게 사는 것을 원한다. 하지만 아이러니 하게도 여유롭고 평화롭고 자유롭게 살기 위해서는 그만큼 치열한 부분이 있어야 할지도 모르겠다.

영화를 통해 여러 가지 삶을 느낄 수 있는데 사람들이 이런 격한 영화를 좋아하는 이유도 좀더 각자가 원하는 삶을 살아가기 위해 절대 그들이 이룰 수 없는 일을 이루고 영화로써 새로운 삶을 느끼고 그로 인해 그들의 실제 삶의 방향이 조금은 좋은 쪽으로 전환될 수 있기 때문이라고 생각한다.@

인터넷이 우리 사회에 미치는 영향

라떼군 — Mon, 21 Sep 2009 00:37:46 +0900

믿기 어렵겠지만 몇 년 전만 해도 간단한 정보를 검색하기 위해선 백과사전이 필요했고 적은 분량의 백과사전에서 찾을 수 없을 땐 도서관에 가야 했고 또 작은 도서관에서 찾을 수 없을 땐 좀더 큰 도서관으로 가야 했었다. 과연 지금의 중학교, 고등학교 학생들은 과연 몇 명이나 이래야만 했던 사정을 이해해줄지 모르겠다.

하지만 이제는 사정이 달라졌다. 인터넷의 등장으로 예전처럼 정보검색에 수많은 시간과 노력을 쏟지 않아도 더 쉽게 더 좋은 자료를 검색할 수 있고 그를 여러 가지 형태의 미디어로 접할 수 있는 시대가 되었다. 예전에 ‘팀 버너스 리(Tim Berners-Lee)’ 가 처음으로 구체적으로 주장했던 하이퍼미디어(Hypermedia)와 그로 이루어진 인터넷으로 인해 우리 생활은 많이 변화했고 또 이제는 없어서는 안될 것으로 멀티미디어 환경으로 진화해 왔다는 사실은 아무도 부인하지 못할 것이다.

사실 인터넷의 등장만으로도 우리에겐 막대한 영향을 끼쳤다. 하지만 여기서 인터넷의 멀티미디어로서의 역할을 배제한다면 그 영향력을 전부 얘기하지는 못할 것이다. 멀티미디어로서의 인터넷은 위에서 얘기한 것처럼 빠른 정보검색은 물론이고 보다 효율적인 방법으로 정보전달의 기능을 가지고 있다.

대학교 1학년 때 처음 컴퓨터를 공부할 때 일이다. 네트웍에 대해 공부하고 있었는데 마침 네트웍을 설명하고 있는 동영상을 인터넷에서 발견했다. ‘The dawn of the Net’ 이라는 동영상 이였는데 네트웍 패킷이나 라우터, 라우터 스위치 등등 전체적인 네트웍에 대해서 알기 쉽게 설명한 동영상이었다. 이 동영상은 너무 쉽고 직관적이어서 누구라도 이것을 본 사람이라면 네트웍에 대해 모두 안 것 같은 착각을 하게 만들 정도였다. 하지만 대략적인 네트웍에 대해서 안다고 해서 전문가가 되었다고 말할 수는 없을 것이다. 간단해 보이는 현상 뒤에 숨겨져 있는 지식들을 모두 이해하고 설명할 수 있을 때 비로소 전문가라 부를 수 있을 것이다.

이런 멀티미디어적인 환경은 대부분에 사람들에게 보다 폭넓은 지식을 요구하는 사회로 변화하게 되었고 이 같은 지식을 강조하게 되었다. 반면에 깊이 있는 지식은 간과하는 사회 분위기를 만들어 가고 있다. 어떤 면에서는 굉장히 비약적인 발전을 이루어 온 것도 사실 이지만 과도기적인 문화를 겪지 못한 한국의 경우에는 이공계, 특히 소프트웨어 발전에 좋은 영향을 끼쳤다고는 볼 수는 없을 것이다.

소프트웨어 발전에 가장 중요한 역할을 하는 것은 그 나라의 문화라고 생각한다. 지금처럼 한 명의 개발자가 얕은 지식으로 데이터베이스 설계에서부터 개발 관리자의 역할 때에 따라선 컨설턴트의 역할까지 모두 해야만 하는 이러한 우리의 현실은 소프트웨어 발전을 저해하고 있는 것이다. 소프트웨어는 누구나 간단한 교육만으로 진입 가능할 수 있는 일명 청바지산업이 아니라 보다 전문적이고 체계적으로 교육받는 사람만이 가능한 산업이 되어야 할 것이다.

결과 만을 중시하고 넓고 얕은 지식을 필요로 하기 보다는 과정을 중시하고 한 한곳에 깊은 지식을 가질 때 비로소 진정한 IT 강국으로 발전할 수 있을 것이라 생각한다. 이제 우리는 이런 멀티미디어적인 환경을 보다 잘 활용해 전처럼 중국 발 해킹으로 허술하게 뚫려 개인정보가 유출되거나 마땅히 지켜야 할 기본적인 표준 HTML 문법조차 지키지 못해 다른 브라우저를 사용하는 대다수의 외국고객들을 놓치는 일은 이제는 없어야 하겠다.

우리도 이제 38세가 되면 38선을 넘는다느니 퇴직해야 한다느니 하는 우리나라의 분위기보다는 나이가 들면 들수록 좀더 깊은 전문성으로 소프트웨어 개발에 힘쓰는 그런 시대가 오기를 바란다. 백발을 휘날리며 소프트웨어 개발에 힘쓴다거나 한국사람 최초로 ‘튜링상(Turing Prize)’을 수상하는 일도 이미 잘 갖추어진 멀티미디어 환경을 잘 활용하고 발전시켰을 때 이런 일도 우리에게는 꿈 같은 일만은 아니라고 생각한다.@

[참고문헌]
http://www.wikipedia.org/

페이지 랭크(PageRank) 와 링크(Links)

라떼군 — Mon, 21 Sep 2009 00:35:26 +0900

나는 버스로 퇴근 하는 것이 좋다. 출근 시간에는 시간여유가 없고 교통체증이 어떨지 모르기 때문에 버스를 이용하지는 않지만 늦은 시간 퇴근할 때는 주로 버스를 이용하는 편이다. 버스를 이용하는 것이 지하철을 이용하는 것보다 20분 정도 더 걸린다. 하지만 버스를 타고 가는 시간 동안 사람들을 관찰하는 즐거움과 창 밖 저녁 도시 풍경을 볼 수 있는 것은 버스를 탐으로써 지연되는 시간과 충분히 바꿀만한 것들이다.

버스에도 명당 자리는 있다. 가장 편하고 사람들을 잘 관찰할 수 있을 뿐 아니라 운전기사와 주행 시선을 같이 함으로써 오랜 버스 여행의 피로를 덜하게 하는 자리가 바로 운전수 바로 뒷자리이다. 무엇보다 그 자리가 좋은 건 승차하는 사람들을 볼 수 있다는 점이다. 사람들을 관찰하고 있노라면 사람들을 관찰하는 능력이 생기는 것 같다. 퇴근 길에 버스를 탄 사람, 친구 만나러 놀러 가는 사람, 이 버스를 처음 탄 사람 등 사람들의 표정과 행동만 봐도 그 정도는 대충 맞힐 수 있게 된다.

그런데 이런 사람들을 관찰하다가 우연찮게 흥미로운 것들을 발견할 수 있었다. 그것은 버스 안에 대부분 사람들은 다른 사람들이 어떤 옷을 입었는지 어떻게 생겼는지 피곤한 모습인지, 심지어는 옷에 더러운 것이 묻어있는지에 대해서도 생각보다 크게 관심을 두지 않는 다는 점이다. 누구나 사춘기 때 주위사람들이 자신에게 관심을 가질 거라 생각하고 사소한 외모에도 신경 쓰던 것과 너무 대조적인 것이다. 여기서 조금 더 유심히 관찰하면 그 관심의 정도는 다른 사람들과의 친분 정도에 비례한다는 것 까지도 알 수 있다. 가족처럼 매우 친한 관계에서는 다른 사람이 못 보는 사소한 것까지도 관심을 갖지만 버스안에서 만난 사이라면 가족들이 관심을 갖는 대부분의 것들에 무관심할 것이다.

이와 같은 사람과의 관계가 마치 웹(Web)에서 말하는 링크(Links)같다는 생각이 들어 링크의 정의를 찾아 보았다. 우리가 보편적으로 생각하는 링크의 종류인 하이퍼링크(Hyperlink)의 Wikipedia의 정의는 다음과 같았다.

In computing, a hyperlink is a reference or navigation element in a document to another section of the same document or to another document that may be on or part of a (different) domain.

모두 알고 있듯이 다른 어떤 것과 연결됨을 생각하면 될 것이다. 인간 사회에서도 그렇듯이 인터넷에서도 인간관계에서 말하는 친분관계와 같은 의미로 링크가 존재하는 것이다. 어느 한 웹 페이지가 링크를 통해 친분의 정도를 나타내고 있다고 생각할 수 있겠고 이것이 구글(Google)에서 말하는 페이지 랭크(PageRank™)로 관심을 갖는 정도를 표현 하고 있는 것이다.

페이지 랭크라는 것은 구글의 설립자 레리 페이지(Larry Page) 와 세르게이 브린(Sergey Brin)이 스탠포드 대학에서 개발한 시스템이다. 특정 페이지에 대해 더 정규화된 페이지 랭크를 계산하기 위한 여러 복잡한 단계를 거치지만 간단히 요약하면 랜덤 웹 써퍼(Random web surfer)가 웹 써핑을 하다 자신의 페이지를 방문할 확률을 나타내는 것이다. 그렇기 때문에 페이지 랭크를 높이기 위해서는 다른 여러 웹 페이지와의 링크가 많아야 하고 연결된 다른 웹 페이지는 페이지 랭크가 높아야 한다. 그래야 랜덤 써퍼가 자신의 웹 페이지를 방문할 확률이 높기 때문이다.

인간 사회에서도 유명한 사람들은 페이지 랭크가 높은 웹 페이지와 같다. 이 사람들은 여러 사람들이 링크로 연결되어 있고 그게 단 방향일 지라도 유명한 사람은 다른 사람들이 아주 사소한 것에도 관심을 가질 정도로 친밀하다. 사회에서 성공하기 위해서는 자신의 웹 페이지의 페이지 랭크를 높이는 것과 비슷하다는 생각이 들었다. 여러 사람과 소통하고 그 사람들로부터 관심의 대상이 되어야 한다는 것이다. 컴퓨팅 시스템들도 사실은 설계자의 사상이 반영된 인간 사회 투영이 아닐까하는 생각이 든다.@

SOA와 프로젝트 현실

라떼군 — Mon, 21 Sep 2009 00:32:50 +0900

오늘 소공동 롯데 호텔에서 열리는 '성공적인 SOA 도입을 위한 IBM 제언 세미나' 에 다녀왔다. (SOA: Service-oriented architecture) 세미나에 참석하게 된 가장 큰 이유는 세미나 아젠다(Agenda) 중에 '웹 서비스 및 XML의 한계와 이의 극복 방안' 이라는 주제가 있어서 기대하며 다녀오게 되었다. 기대가 너무 컸던 탓일까? 발제자들은 많은 것을 알고 있으면서도 잘 알려주려 하지 않는 것 같아 보였고 모든 XML(Extensible Markup Language)과 관련된 문제점들을 자신들의 제품에서만 해답을 찾으려고만 하는 것 같다 좀더 기술적인 내용을 기대하고 참석했던 나로써는 좀 아쉬운 세미나가 된 것 같다.

나는 항상 세미나를 하고 거기서 전달이 가능한 내용들은 발제자가 알고 있는 지식의 25% 정도 밖에 되지 않는다고 개인적으로 생각하고 있다. 발제자의 능력이 100%이라고 한다면 여러 사람의 수준을 맞추는데 50%의 전달능력을 상실되고 자신의 지식을 또 알맞게 포장하는데 또 50%의 전달능력이 상실된다고 생각한다. 그만큼 수준이 다른 여러 사람들을 대상으로 발표하고 그것을 이해시키기가 그만큼 어렵다는 말이다. 그래서 나는 누가 세미나를 들을 때 발제자의 실력이 내가 느끼는 것보다 4배정도 잘하는 사람이라고 미리 생각하고 세미나를 듣는다. 그런데 오늘 첫 번째 세션을 발표하시고 미국 IBM에서 근무하시고 계신다는 '손성익' 이란 분은 세미나를 통해 느껴지는 그분의 내공도 대단했지만 실제 그분이 오랜 기간 대기업에서 소프트웨어 산업에 몸담고 있으면서 겪었던 경험들을 생각할 때 더 대단한 분 일거라는 생각이 들었다.

대기업 개발자들과 만나 볼일은 별로 없지만 가끔 만날 때마다 공통적으로 느끼는 점이 있었다. 오늘도 마찬가지로 그런 느낌을 느낄 수 있었는데 그것은 대기업 개발자와 중소기업 그리고 소기업 개발자와는 확실히 차이가 난다는 것이다. 그 차이는 간단히 말해서 100억짜리 프로젝트를 해본 개발자와 1억짜리 개발을 해본 개발자와 1,000만 원짜리 개발을 해본 개발자로 달리 말할 수 있겠다. 사실 100억짜리 프로젝트라고 해서 뭐가 그렇게 다르겠는가? 그렇게 비싼 프로젝트라도 황금으로 만든 키보드와 마우스로 작업하거나 매일 저녁 야식을 위해 스테이크를 구워먹거나 하지는 않을 것이다. 그냥 똑 같은 프로젝트일 뿐인데 어떤 프로젝트는 여러 회사들의 이해관계가 얽혀(혹은 국가 일지도 모르겠다) 가격이 올라가고 또 그러기에 좀더 중요한 프로젝트라 불려지는 것뿐이다.

그래도 나는 개발자라면 한번쯤은 큰 규모의 프로젝트를 해볼 필요가 있다고 생각한다. 그런 큰 규모의 프로젝트를 해봄으로써 작은 프로젝트에서는 결코 경험할 수 없는 새로운 문제점들을 경험할 수 있게 될 것이라고 확신한다. 그런 문제점들을 해결해 나감으로써 다른 프로젝트를 바라보는 보다 넓은 시각을 갖게 해줄 것이라고 생각한다.

사실 소프트웨어 공학에서 나오는 대부분의 것들이 소규모 프로젝트를 대상으로 하고 있는 것은 없지 않은가? 심지어 오늘 세미나의 주제인 SOA도 그렇지 않은가? “SOA는 기업의 소프트웨어 인프라를 구축하는 방법으로 서로 다른 운영체제와 프로그램에 상관없이 애플리케이션간에 데이터와 프로세스를 교환할 수 있는 아키텍처를 말한다.“라고 IBM사이트에서도 말하고 있듯이 그 내용부터 소규모 프로젝트는 벌써 배제되고 있음을 알 수 있다. SOA 탄생의 궁극 목적도 새로 개발하거나 유지보수에 따르는 비용이 큰 대형 레거시 시스템(Legacy System)들을 어떻게 최소 수정으로 신규 시스템에 통합할 것인가로부터 생각이 출발한 것이 아닐까?

요즘 내가 일하는 부서에서는 소스통합에 대한 이슈가 제기되고 있다. UI와 플래폼(Platform)과 개발언어는 다르지만 기능이 비슷한 두 프로젝트의 소스를 하나로 합쳐 추후 지금보다 낮은 비용으로 개발하고자 하는 것이 그 목적이다. 하지만 물론 가능은 하지만 그 작업으로 인해 앞으로 나타날 험난한 프로젝트의 문제점들과 시행착오들이 나에게는 그저 깜깜하게 보일 뿐이다.

SOA 도 좋고 웹 서비스도 좋고 IBM에서 말하는 하드웨어로 구현된 엄청 빠른 XML파서인 DataPower도 좋지만 그것들의 장점을 살릴 수 없는 중소형 프로젝트들과 만약 장점을 살릴 수 있는 길이 있다고 하더라도 그것들을 관리자에게 제대로 이해시키지 못하는 나 같은 개발자에게는 그저 공허한 울림이 될 수 밖에 없다. 보다 풍부한 경험이 있었더라면 더 좋은 방향을 제시할 수도 있을 거라 생각을 하면서 나에게 있어서 여러 가지 상황의 경험과 그에 맞는 기술적 조합이 부족함을 절실히 느낀다.@