Blog

Blog

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

최근 꿀단지(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)나 방화벽 등을 꿀단지 기법으로 구현해 내부 직원에게는 비밀 하에 설치하며 실제 서비스처럼 운영해 볼 수 있을 것이다. 꿀단지의 로그 데이터 분석을 통해 사내 네트워크에 취약점 및 자료 유출 실태를 분석할 수 있을 뿐만 아니라 나아가서는 취약점 보완에 기여할 수 있을 것이다.


References

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


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

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)을 보고

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

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

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

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

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

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

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

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

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

Labels:

해커는 화가를 닮지마라

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

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

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

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

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

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

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

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


의도를 파악하라

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

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

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

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

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

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

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

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


Software의 Accessibility

얼마 전 편의점에서 커피를 사먹었던 적이 있었는데 놀라운 것을 발견하였다. 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가 강조된 소프트웨어는 그렇지 않은 소프트웨어보다 더욱 안정적인 발전을 이룰 수 있으리라 생각한다.


References

[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


'영화는 영화다'를 보고

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

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

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

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

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

Labels:

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

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

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

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

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

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

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

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

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


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

나는 버스로 퇴근 하는 것이 좋다. 출근 시간에는 시간여유가 없고 교통체증이 어떨지 모르기 때문에 버스를 이용하지는 않지만 늦은 시간 퇴근할 때는 주로 버스를 이용하는 편이다. 버스를 이용하는 것이 지하철을 이용하는 것보다 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와 프로젝트 현실


오늘 소공동 롯데 호텔에서 열리는 '성공적인 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도 좋지만 그것들의 장점을 살릴 수 없는 중소형 프로젝트들과 만약 장점을 살릴 수 있는 길이 있다고 하더라도 그것들을 관리자에게 제대로 이해시키지 못하는 나 같은 개발자에게는 그저 공허한 울림이 될 수 밖에 없다. 보다 풍부한 경험이 있었더라면 더 좋은 방향을 제시할 수도 있을 거라 생각을 하면서 나에게 있어서 여러 가지 상황의 경험과 그에 맞는 기술적 조합이 부족함을 절실히 느낀다.


구글 브라우저(Chrome)와 웹 제국

이제 구글도 웹 브라우저(Web browser)를 만든다. 9월 2일 출시되는 '크롬(Chrome)'이 그것이다. MS진영과 Firefox로 대변되는 오픈 소스 기반의 웹 브라우저와의 싸움의 시작을 예견 하는 목소리가 이곳 저곳에서 흘러나오는 것 같다. 하지만 나는 이것은 단순히 싸움에서 그칠 것으로 생각되지 않는다. 이 뉴스를 접할 때 왠지 영화 속 터미네이터(Terminator)가 등장할 때 나오는 음악이 내 귀에 들리는 것 같았고 긴장되면서 한편으로 기분 좋은 느낌이었다. 내가 그렇게 생각한 이유는 다음과 같다.

구글은 지금까지 웹 기반 어플리케이션으로 인한 사업을 추진하고 있었다. 구글 검색(Google Search), 구글 닥스(Google Docs), 그리고 iRow를 인수해 구글이 갖게 된 스프레드시트(Google Spreadsheets), 구글 캘린더(Google Calendar) 등이 그 예가 될 수 있겠다. Ajax (Asynchronous Javascript And XML)의 등장과 구글의 노력으로 많이 개선되기는 했지만 하지만 이런 웹 기반 오피스들을 사용해본 사람은 이미 조금은 느꼈겠지만 데스크톱(Desktop) 어플리케이션에 비해 약간 2% 부족하고 답답함을 느꼈을 것이다. 마치 MS와 선대 프로그래머들이 가둬놓은 웹 브라우저라는 올가미에 걸린 거대한 드래곤(Dragon)처럼 말이다.

그것은 바로 W3C에서 1999년에 발표되었지만 아직까지 쓰고 있는 구시대 프로토콜인 HTTP/1.1와 IE(Internet Explorer)와 Netscape의 싸움으로 브라우저 시장의 잠식만 중요시 했던 시대의 결과물인 현재 웹 브라우저의 성능한계 때문이 직접적인 원인이라고 말할 수 있겠다. 쉽게 말해서 웹 브라우저가 벤더들이 원하는 기능을 그만큼 소화하지 못하는 것이다. 때문에 불행하지만 우리나라에선 ActiveX로 만들어진 지저분한 웹사이트들도 나타나게 된 것이다.

하지만 그와 별개로 웹 기반 소프트웨어에 대한 관심이 집중되고 있다. web2.0이 이슈가 되었던 것처럼 웹 기반 소프트웨어는 단순하며 사용하기 쉽고, OS(Operating system)에 상관없이 웹 브라우저만 있으면 사용할 수 있고, 특정 소프트웨어가 설치되어야 할 필요도 없기 때문에 장소에도 구애 받지 않는다. 이러한 웹 기반 소프트웨어대 대한 관심 집중 현상은 앞으로 데스크톱 어플리케이션의 새로운 패러다임이 나오기 전까지는 바뀌지 않을 거라 생각한다.

여기서 구글이 웹 브라우저 시장에 진출한 이유를 다시 생각해 봤으면 좋겠다. 단순히 IE와 Firefox의 시장을 나눠먹기 위해서 진출하지는 않았을 것이다. 구글은 웹 기반 소프트웨어에 대해 또 다른 야심을 가지고 있는 것이라 생각되고 이제 단지 그것의 발톱을 약간 드러냈을 뿐이다. 나는 심지어 구글 브라우저에서 일반적인 웹 브라우저와 달라진 탭(Tab) 위치에서도 구글이 갖는 웹 기반 소프트웨어에 대한 야심을 느낄 수 있었다. 구글이 완전히 이빨을 다 들어냈을 때 구글 브라우저 위에서 구동되는 구글의 웹 기반 소프트웨어들이 어떤 모습이 될지 기대되는 바이다. 또한 구글은 한발 짝식 구글 제국(?)을 건설하기 위해 도전적으로 전진하는 모습이 부럽다. 우리나라에도 이와 같이 좀더 원대한 목표를 갖고 전진하는 소프트웨어 개발사들이 많아졌으면 하는 바램이다.


소프트웨어의 요구사항

소프트웨어 개발자(software developer)로써 일을 하다 보면 기획자와 많은 시간을 보내게 된다. 여기서 기획자란 말은 소프트웨어의 요구사항을 만들어내는 사람이라고 봐도 좋겠다. 혹은 드물겠지만 기획자라고 부를 만한 사람이 없다면 소프트웨어를 사용하는 사용자를 떠올리기 바란다. 요구사항을 만들어내는 사람들은 개발자를 곤혹스럽게 하곤 한다. 그것은 근본적으로 개발자가 하고 싶지 않은 일을 시키기 때문이라고 생각한다. 개발자는 성능을 중시하고 코드가 얼마나 간결한지를 중시하곤 하는데 복잡한 요구사항들은 이런 코드를 지저분하고 복잡하고 느린 모습으로 바꾸곤 하기 때문이다. 하지만 자신의 소프트웨어가 살아 있는 한, 자신의 소프트웨어를 사용해주는 사용자가 있는 한, 요구사항이 있는 한 이러한 일은 끊이지 않을 것이다.

같은 요구사항이라도 기획자에 손을 어떻게 거치느냐에 따라 어렵고 시간이 오래 걸리는 것이 있는 반면 간단하면서 빨리 끝낼 수 있는 일도 있었던 것을 많이 보아왔다. '실력 있는 개발자라면 오래 걸리는 개발도 쉽게 끝낼 수 있을 않느냐?' 라고 반문하실 지도 모르겠다. 하지만 이건 실력하고는 별개의 문제라고 생각한다. 나의 경험을 비춰 봤을 때 똑같은 기능이라도 어떤 기획서는 작업하기 쉬웠던 반면에 어떤 기획서는 작업하기 힘들었던 적이 분명히 있었기 때문이다. 이것은 기능의 많고 적음을 얘기하는 것은 결코 아니다.

어려운 기획서의 가장 큰 부분은 기존에 이미 요구돼있던 기능의 기본적인 틀의 변경이 여러 번 번복되어서 가해지는 부분이다. 한번 이렇게 바꿔보고 또 아니다 싶으면 다르게 바꿔보는 식이다.

이것이 어려운 이유는 간단해 보이는 요구사항일지라도 소프트웨어 설계 전체에 대한 수정이 가해져야만 적용될 수 있는 부분이 있기 때문이다. 웹 어플리케이션을 예로 들면 대부분 데이터베이스와 밀접한 관계를 가지고 그것의 설계에 기초 하는 것들이 많기 때문에 데이터베이스의 설계가 심하게 변경 되어야만 했을 때 데이터베이스 레이어(Database layer)부터 프레젠테이션 레이어(Presentation layer)까지 수 많은 부분들이 변경되어야만 한다. 기획자는 기존 요구사항에 대한 수정 또는 요구사항 번복에 대해 충분히 신중해야 할 것이다. 사실 이것이 내가 실제로 일을 하면서 기획자들에게 가장 불만을 갖고 있는 부분 이기도 하다.

사실 기획자들이 이런 변경에 대한 요구를 끊임없이 해오는 이유는 고객의 요구사항을 제대로 파악하지 못해서 생긴 일이 대부분 이라고 생각한다. 일반 고객들이 바로 요구사항을 만들어내는 상황의 소프트웨어라면 이런 잦은 요구사항 수정에 책임은 요구사항을 제대로 파악하지 못한 개발자에게 있다 것이다. 또 기획자에 의도를 제대로 파악하지 못해 엉뚱한 것을 만들어 내고 있었다면 이것 역시 개발자 책임일 것이다. 그냥 한번 만들어보고 그게 아니면 또 바꾸는 식의 해결방법은 곤란하다. 하지만 이런 문제를 해결할 수 있는 방법은 얼마든지 있다.

프로토타입(Prototype)을 이용해 해결할 수 있다. 프로토타입이란 어떤 구조물이나 장비에 대하여, 형상이나 설계, 적합성 또는 성능 등을 평가하기 위해 만든 실물 크기의 모형을 말한다.(http://terms.co.kr) 즉, 기획자가(고객이) 무엇을 원하는지 제대로 모를 때 프로토타입을 빠르게 만들어서 보여주고 ‘이게 맞습니까?’ ,’이 정도면 되겠습니까?’ 이렇게 물어볼 수 있는 것이다. 요구사항이 명확히 파악된다면 그걸 기반으로 더 잘된 설계를 이끌어 낼 수 있을 것이다.

또는 그 소프트웨어를 가지고 일하는 사람들과 같이 지내 봄으로써도 해결할 수 있다. 요구사항을 제대로 파악하지 못하는 이유 중에 하나가 자신의 소프트웨어를 자신이 실제로 써보지 않아서 어떤 것이 어떻게 불편한지 제대로 알지 못해서 일 것이라고 나는 확신한다. 웹 메일 서비스라면 자신이 직접 웹 메일을 써봐야 어떤 점이 업무를 불편하게 하는지 알 수 있을 것이고 게임을 만든다면 직접 그 게임을 해봐야 어떤 점이 재미없는지도 알지 않겠는가?

나는 개발자들이 개발에만 열중할 것이 아니라 고객(또는 요구사항을 만들어내는 기획자)과 소통하는데 더 노력을 기울일 것을 권하고 싶다. 이것이 바로 자신의 소프트웨어를 성공 시킬 수 있는 진정한 one way 인 것이다. 코드가 깔끔한 소프트웨어라고 성공하는가? 자신의 소프트웨어가 사용하기 불편한 대신 코드가 깔끔하다고 광고할 생각인가? 심지어는 버그가 많은 소프트웨어가 다른 경쟁 업체들을 제치고 성공하기까지 하는 이유는 바로 요구사항을 다른 경쟁 업체들 보다 제대로 파악했기 때문이 아닐까?


프로그래머의 Break Point

프로그래밍 작업은 고통스럽다. 사실 프로그래밍하는 작업이 고통스러운 건 아니다. 그건 즐거운 일이며 나에게 있어 생각만으로도 아드레난린(Adrenaline)을 분비시켜 힘을 나게 한다. 하지만 그것이 일과 연관 되어있을 때는 마냥 즐거운 일일 수만은 없다. 프로그래머는 일할 때는 초현실적인 UI(User Interface: 사용자 인터페이스)를 만들어내는 기획자도 설득해야만 하고 자꾸 모호한 말만 하는 애매한 디자이너도 상대해야 하기 때문이다. 하지만 프로그래밍을 하는 사람으로써 마냥 고통스럽게 있을 수만은 없다. 고통의 연속이라면 더 이상 생산성을 떨어뜨릴 뿐만 아니라 회사의 월급도둑 역할만 하는 일은 그만두고 다른 직업을 찾아보는 것이 본인에게도 좋을 것이다. 그럼 항상 즐거울 수만 없는 이런 일들을 어떻게 즐기며 일할 수 있을 것인가?

먼저 '잘 쉬어야 한다.' 일하는 모든 사람들에게 적용되는 말이다. 잘 일하기 위해서는 잘 쉬어야 한다. 하지만 이 말을 오해하는 사람들이 있다. 쉬라는 말이 집에 누워서 아무것도 하지 않은 채로 시체놀이 만으로 주말을 보내라는 그런 말은 아니다. 쉬는 것은 일 외에 다른 곳에 관심을 돌리는 것을 쉬는 것이라고 말할 수 있다. 예를 들면, 회사에서 가상 파일시스템을 개발하는 사람이 남는 시간을 통해 웹 메일 클라이언트를 만들어 오픈 소스 커뮤니티에 올리는 일을 했다라고 한다면 그 사람은 쉬었다 라고 말할 수 있다. 또는, 남는 시간을 통해 새로운 언어(Python, Perl, Lisp …) 공부하는 것도 마찬가지다. 잠시 짜증나는 업무에서 벗어나 생각을 리프레시(refresh) 함으로써 일을 더 즐겁고 잘할 수 있는 것들이 여기에 포함될 것이다.

'원인을 분석해야 한다.' 일이 힘들어 졌을 때는 왜 일이 힘들어 졌는지 어떤 일 때문에 즐겁지 않은지 원인을 분석해야 할 필요가 있다. 노트에 하나씩 적어보자. 예를 들면 이런 것들이 있을 수 있다. '기획자가 보내온 기획서가 너무 엉망이다.', '요구사항이 너무 수시로 바뀐다.', 또는 '상사가 나를 싫어한다.' 등등.. 하나씩 적어보자. 만약 하나도 적을 것이 없거나 납득할만한 내용을 적을 수 없는데 일이 힘들어졌다면 그건 자신에게 문제가 있는 것이다. 모두 적었다면 하나씩 해결하려고 노력해볼 필요가 있다. 기획서가 너무 엉망이라면 왜 엉망인 기획서인지 기획자에게 알려주고 다음부터 보완하도록 얘기해볼 수 있을 것이다. 요구사항이 너무 수시로 바뀐다면 경험적으로 바뀌는 요구사항에 맞게 어느 정도 유연한 설계를 할 필요가 있을 것이고, 상사가 나를 싫어한다면 그 원인을 알고자 상사와 대화해야 할 것이다.

'커피를 마셔라.' 여기서 커피는 자판기 커피나 커피 믹스는 제외한 것이다. 1994년 일본 교린 대학의 연구결과에 따르면 커피 향은 뇌의 혈액량을 증가시키고 뇌파를 변화시켜서 집중력과 쾌감 기능을 높여 준다고 밝혀졌다. 자판기 커피나 커피믹스는 향이 적고 그다지 좋지 않으므로 에스프레소(Espresso)를 마실 것을 권하고 싶다. 난 카페라떼(Latte), 카푸치노(Cappuccino)를 좋아한다. 예전에 홍대 앞에서 근무할 당시 매일 한잔씩 마시던 카페라떼 향은 아직도 잊을 수 없다. 그때 회사가 참 힘들었었는데 생각해보면 그때 힘들었던 일들을 커피 덕에 조금이라도 덜 힘들게 일할 수 있지 않았나 싶다. 커피 한 모금처럼 본인에게 더 맞는 리프레시 수단이 있다면 그것을 찾을 것을 권하고 싶다.

하나씩 고통의 원인을 제거해 보면 프로그래머로써 일하는 것은 고통스러운 일이 결코 아닐 것이다. 고통은 대게 나 자신에게서 시작되고 있고 그게 해결되지 않은 채로 지속되고 있을 땐 결국엔 지쳐 쓰러지게 된다. 그때는 어떤 원인 때문에 내가 힘들어 하는지도 모르고 아무리 쉬어도 회복될 수 없는 상태가 되고 말 것이다. 프로그래밍 작업만 분석적으로 할 것이 아니라 자신의 생활도 디버깅 하듯이 혹은 '커피' 같은 툴의 도움을 받아 고통의 원인을 하나씩 찾아서 해결해 보는 것은 어떨까?


웹 기반 서비스의 업그레이드

나는 지금 웹을 기반으로 하는 서비스를 개발하고 있다. 프로젝트의 모든 부분이 웹 어플리케이션은 아니지만 프로젝트를 실행하고 사용 하는데 있어 웹은 필수적이고 실제로 프로젝트의 많은 부분을 차지하는 하고 있다. 몇 일 전에 이런 프로젝트의 버전 업그레이드가 있었다. 웹을 기반으로 하는 서비스의 업그레이드 버전을 출시한 것이다. 웹 기반 서비스의 업그레이드 버전의 출시가 생소한 일일지도 모르지만 우리는 고객에게 변화하는 모습을 보여주고 그 효과를 극대화 하고자 빌드 버전(Build Version)을 사용하고 있고 버전을 업그레이드 하면서 지금까지 계속 제품을 출시했고 이런 대대적인 업그레이드 작업 2번에 걸쳐 현재 버전 2.5에 이르렀다. 하지만 이번 업그레이드 작업을 하는 동안 몇 가지 의문이 생겼다.

'왜 장시간 서비스 중지를 하면서 업그레이드를 진행해야만 하는가?' 대대적인 업그레이드 라는 것은 그만큼 바뀌는 부분이 많다는 것이다. 따라서 해야할 일도 많이 때문에 다른 점검 시간(정기 점검 등 간단한 점검 시간)과 달리 상대적으로 오랜 시간 동안 서비스를 중지해야만 한다. 하지만 고객은 서비스가 항상 온라인 상태이기를 원할 것이다. 이른 새벽부터 중요한 업무를 보기 위해 서비스에 접속했을 때 정검 페이지가 나온다면 얼마나 절망적일까? 이게 만약 웹 메일 서비스라면 상사가 보낸 메일을 제시간에 확인하지 못해 곤욕을 치를 것이고 항공권 발매 서비스라면 제시간에 비행기 티켓 발권을 못하는 일도 있을 수 있을 것이다. 마치 사막에서 힘들게 오아시스를 찾았는데 썩은 물만 고여있는 것을 본 것과 같고 뒷모습이 예쁜 분을 쫓아가 말을 걸었는데 알고보니 남자인 걸 알았을 때의 그런 심정과 같을 것이다. 사실 웹 기반 서비스는 사실 이런 고민을 할 필요가 없다. 웹은 실시간으로 업데이트가 가능하기 때문이다.

'대대적 업그레이드를 하면 안정성이 떨어진다.' 내가 다니는 회사에서는 제품 출시 이전에 QA(Quality Assurance) 팀의 테스트를 거치고 나서 출시하도록 되어있다. 보통 QA팀의 테스트를 마치고 나면 제품의 퀄리티(Quality)가 테스트 이전보다 훨씬 높아져 안정성을 확보할 수 있었다. 하지만 이번처럼 대대적인 개편의 경우 여러 번의 테스트를 거쳤지만 업데이트 이후 이전에 발견하지 못한 혹은 예상치 못한 작은 문제들을 발견할 수 있었다. 마치 싸인(Sign)곡선처럼 업데이트 후 겨우 안정화된 서비스를 다시 업데이트하여 안정성을 떨어뜨리는 현상이 일어나게 되는데 이건 서비스로써 매우 바람직한 현상이 아닐 것이다. 대대적인 업그레이드가 필요한 이유가 고객 홍보화 그 효과의 극대화라 한다면 잦은 업데이트 여러 번으로 기능을 이미 적용해 놓은 상태에서 혹은 기능만 가려놓은 상태에서 마케팅 전략에 따라 언제든지 필요할 때 기능 오픈과 홍보가 가능할 것이다. 이는 웹 기반 서비스 이기 때문에 가능한 장점이다.

웹 기반 서비스는 실제로 사용자에게나 개발자에게 많은 장점이 있다. 사용자는 별도의 소프트웨어 설치 없이 언제 어디서나 같은 소프트웨어를 사용할 수 있다는 장점이 있다. 개발자에게는 소프트웨어의 버그가 있을 때 또는 기능 추가가 있을 때 사용자들에게 새 버전이 나왔으니 새로 설치해달라고 애원하지 않아도 된다. 이것은 서비스의 안정성과도 연관 되어 있는데 이렇게 잦은 업데이트 및 버그 패치를 통해 어떤 종류의 데스크 탑 소프트웨어보다 퀄리티 높은 제품을 만들어 낼 수 있는 것이 바로 웹 기반 서비스라고 생각한다. 구글(Google)의 성장이 말해 주듯이 전 세계적으로 웹 기반 소프트웨어는 현재 소프트웨어 산업의 흐름을 주도하고 있다고 생각한다. 하지만 상대적으로 부족한 우리 나라의 웹 기반 서비스에 대한 안타까운 마음과 함께 우리나라에서 더 많은 웹 기반 Killer Software 서비스들이 나와줄 것을 기대하는 바이다.


나의 프로그래밍 철학은 뭘까?

나는 이른바 코딩 해서 먹고 살고 있는 프로그래머라 불리는 사람 중 한 명이다. 하루 종일 코딩 하기 위해 애쓰는 그런 사람 중 한 명이란 말이다. 그런데 요즘 들어 문득 오픈 소스 커뮤니티를 돌아다니다 나보다 뛰어난 수많은(개인적으로 우리나라 프로그래머 중에 80%이상은 나보다 뛰어날 거라 생각한다) 프로그래머를 만나면서 나의 작은 존재감에 다시 한번 생각하게 되었고 그럼 과연 내 프로그래밍 철학은 무엇인지 생각해 보게 되었다.

프로그래밍 철학이란 다시 말해서 내가 프로그래밍을 하면서 추구하는 궁극적인 목표라고도 말할 수 있을 것이다. 그렇게 말할 수 있는 이유는 철학이 행동을 만들고 그 행동은 그 사람의 삶의 목표와 맞다 아 있다고 생각하기 때문이다. 그럼 내가 프로그래머 직업을 가지면서 궁극인 목표로 삶고 있는 것이 무엇일까? 한참을 생각해 봤지만 부끄럽게도 목표라고 내세울만한 건 없었다. 지금 하는 프로젝트 대박 내는 것? 아니면 열심히 해서 회사 잘 키워보는 것? 물론 이것들도 중요하지만 아무래도 이런 것들은 철학, 목표라고 하기에는 너무 근시안적인 것뿐이다.

난 웹(web) 프로그래머라 불리는 사람이다. 닷넷(.net)을 이용해 개발하고 있고 주로 사용하는 언어는 C#이다. 그렇다고 아직 C#전문가라 불릴만할 정도로 그 부분에 대해 권위가 있는 수준은 아니다. 또 어느 한 플랫폼에 집중돼서 전문가라 불리는 것도 원하지 않는다. 플랫폼에 집중된 노력을 쏟는 것은 멀리 볼 때 발전가능성을 더디게 한다고 생각해서이다. 하지만 웹 프로그래머들은 상대적으로 그런 부분이 취약하다. 자신의 플랫폼 이외의 플랫폼에는 관심이 덜하거나 관심이 전혀 없는 실정이다. 주위에 php하는 프로그래머와 닷넷 프로그래머와 대화해 보라. 쉽게 알 수 있을 것이다. 과연 웹 프로그래머로써의 나의 철학은 뭘까?

난 웹 사이트와 윈도우 어플리케이션을 비교해서 말하는 것이 싫다. 그것보다 어플리케이션 이라는 말이 윈도우 프로그램을 대표하는 단어가 됐다는 게 싫은 것이다. 웹은 어플리케이션이 아니고 윈도우 UI를 가진 프로그램만이 어플리케이션이란 말인가? 익숙해져서 인지 주위에 그렇게 말하는 사람들을 많이 볼 수 있다. 실제로 그런 말을 들을 때마다 웹 어플리케이션, 윈도우 어플리케이션 이렇게 말해야 맞는다고 정정해 주고 싶은 심정이다. 내부를 들여다 보면 더 다르지 않다는 것을 볼 수 있다. 단지 웹은 웹API를 이용할 뿐이고 웹 브라우저를 이용할 뿐인데 말이다.

다시 처음으로 돌아가면 프로그래밍 철학이란 결국 플랫폼이나 개발언어에 국한되지 않은 목표가 되어야 하고 근시안적인 목표가 아닌 인생전체를 걸고 추구해야 할 목표였으면 하는 것이다. 올림픽에서 매달을 딴 선수가 자신의 목표한 것을 이뤘기 때문에 기쁨과 감격의 눈물을 흘리듯이 내가 세운 프로그래밍 철학을 내가 이뤘을 때 감격할 수 있는 그럼 목표를 세웠으면 하는 것이 나의 바램인 것이다. 이 글을 쓰면서 한 문장으로 정리된 목표는 아직 말할 수 없지만 어떤 방향인지는 대충 정리가 된 느낌이다. 그걸 이루기 위해 계속 긴장을 늦추지 않고 노력해야 할 것이다. 또, 그럼 목표를 이룰 수 있는 지금 나의 상황들 모두가 감사할 뿐이다.


비즈하드 소개 대본

비즈하드는 중소 규모의 기업, 조직, 단체를 대상으로 하는 웹 스토리지 기반의 통합 전산 업무 환경을 제공하는 서비스 입니다.

비즈하드를 이용하게 되면 회사별 독립적인 웹사이트와 2차 도메인인 회사도메인.bizhard.com 를 제공 받을 수 있고, 회사마다의 독립적인 스토리지 서비스를 이용할 수 있습니다. 회사 내 팀별 조직 별 마다 따로 파일 공유가 필요한 경우가 있는데 팀별 조직 별 파일공유가 가능하도록 하는 그룹디스크를 제공하고 있으며, 비회원과의 파일공유를 위한 게스트 폴더를 제공하고 있습니다. 그룹디스크와 게스트 폴더에는 관리자 또는 디스크 생성자가 폴더마다의 읽기, 쓰기, 삭제의 권한을 부여할 수 있어서 사용자 권한을 제한하는 등의 다양한 고객의 요구에 대응하고 있습니다.

또한 중요한 파일의 안전한 저장을 위해 국가 표준 알고리즘이고, 128비트 블록 암호화 알고리즘인 ARIA를 이용해 사용자가 저장하는 파일이 암호화되어 안전하게 저장되는 보안폴더를 제공하고 있습니다. 또, 보통 대용량인 시디 이미지의 빠르고 편리한 사용과 조직 내 공유를 위해 다운로드 하는 않고 바로 스토리지의 파일을 CD-ROM 처럼 사용할 수 있게 하는 가상 CD드라이브 기능도 제공하고 있습니다.

이제 비즈하드에 사용된 핵심 기술인 ‘웹 스토리지의 분산 파일 관리 시스템 및 파일 관리 방법’에 대해서 말씀 드리겠습니다. 보통 인터넷을 통해 파일을 업로드 할 때는 해당 파일의 중복여부 및 해당 스토리지의 트래픽과 상관없이 순차적으로 업로드 하는 방식으로 되어있습니다. 다운로드도 마찬가지로 지정된 하나의 스토리지 내에서만 진행 되게 됩니다.

하지만 이런 식의 동작은 전체적인 네트워크 트래픽에는 여유가 있음에도 불구하고 해당 스토리지에 트래픽이 몰려 다운받지 못하는 경우가 생겨나게 됩니다. 이 경우 정상적인 서비스를 위해 지속적으로 모니터링을 해야 하기 때문에 비용적인 측면이나 파일 서버의 관리 측면에도 비효율적이고 서비스 또한 안정적이지 못하게 됩니다.
비즈하드의 적용된 파일 관리 방법에는 기존의 비효율적이고 안정적이지 못한 방법을 해결하고 있는데, 파일 업로드 시에는 대역폭의 여유가 있는 스토리지에 파일을 분산하여 저장하므로 써 파일 송수신 속도를 가장 빠르게 낼 수 있도록 합니다.

또한, 업로드 시 파일을 고유하게 식별할 수 있는 식별 자를 생성하여 이미 서버에 같은 파일이 있는지를 확인하고 같은 파일이 존재할 경우 그 파일의 사용 빈도를 분석해서 해당 파일을 서버에 여러 군데 분산하여 저장할 것인지 아니면 디스크 공간을 절약하기 위해 기존에 파일만 남겨둘 것인지를 결정하게 됩니다.

파일 다운로드 시에는 다운로드 요청 시 물론 가장 빠르게 받을 수 있는 서버에서 다운로드 하게 되며 대용량의 파일일, 즉 장시간에 걸쳐서 다운로드 받게 되는 경우에는 다운로드 중에도 서버의 트래픽의 변화가 있을 수 있게 됩니다.

다운로드 받고 있는 중에라도 지금보다 더 빠르게 받을 수 있는 서버를 찾아서 다운로드 하고 있는 사용자와 연결 시켜 줌으로써 사용자는 더 빠르게 다운로드 받게 됩니다.
또한 스토리지의 파일들의 상태를 주기적으로 체크해서 다운로드가 많이 일어나는 파일은 분산시키고, 다운로드가 적은 분산된 파일은 분산 정도를 줄여 서버의 속도 와 용량을 효율적으로 관리할 수 있게 합니다.

관리의 효율성을 높이기 위해서 업로드 및 다운로드 시 트래픽과 서버의 상태를 체크를 하지만 그래도 한쪽 서버에 몰리는 현상이 발생 될 수 있는데 이런 경우 자동으로 해당서버의 파일들을 다른 서버와 적절하게 재배치 하는 부하를 분산하는 기능을 갖고 있습니다.
이와 같은 비즈하드의 기능과 비즈하드의 핵심 기능인 ‘웹 스토리지의 분산 파일 관리 시스템 및 파일 관리 방법’으로 데이터의 저장, 공유, 활용 및 보안, 관리 효율성의 향상이 예상되고 있습니다.

시장성으로는 기존의 저장매체인(odd, fdd, flash memory…) 가 필요없는 100% 네트워크를 이용하는 저장방식으로 개인의 중요한 자료의 저장 기능과 기업, 조직 단체 등의 업무상 파일 저장 및 공유 기능으로의 사용이 예상되고 있습니다.

현재 웹 스토리지 서비스 시장에서의 무료 용량 제공 등의 경쟁 상황으로 서비스 운영비 절감이 큰 이슈가 됨에 따라서 본 제품에 적용된 핵심 기술과 같은 트래픽을 분산 하고 효율적인 파일 관리 방법을 개발하기 위한 투자가 예상되고 있습니다.


아키텍트 이야기

아키텍트는 '책임 설계자'로 달리 말할 수 있다. 아키텍트의 역할이 어플리케이션의 설계와 구현 전체를 책임지고 개발팀을 이끄는 것이기 때문이다. 아키텍트는 스페셜리스트인 동시에 제너럴리스트의 역할을 해야한다. 10년 후에도 기술자로 확약하기 위해서는 아키텍트가 아키텍처와 프레임워크로 프로젝트를 이끄는 위치가 되어야 한다.

아키텍트가 만들어 놓은 프레임워크를 사용함으로써 공통 부분 설계를 재사용 할 수 있어 비용이 절감되고, 공통부분을 반복적으로 사용해왔기 때문에 안정적이고 신뢰도 높은 구현을 할 수 있고, 옵션으로 된 부분의 범용적인 개발과 높은 기술 수준을 필요로 하지 않으므로 비교적 낮은 수준의 개발자에게 개발을 맡기더라도 전체 시스템을 망가뜨릴 염려가 적다는 것이다.

아키텍트는 요구사항 정의 작업부터 참여한다. 보통 개발자들은 요구사항 분석 단계에서 빠져있기 마련이고 요구사항, 설계, 구현, 테스트로 보통 이뤄지는 개발 프로세스에서 빠르면 설계단계부터 어떤 개발자는 실제 구현단계부터 참여하기도 하지만 아키텍트는 초기단계부터 참여하여 개발자와 사용자 모두가 원하는 계획을 세우는 역할을 한다.
아키텍트의 주 업무는 당연히 아키텍처 설계가 될 것이다. 아키텍처란 건축분야에서 나온 용어이지만 소프웨어 분야에서 '어플리케이션의 설계와 구현의 지침'이란 의미로 많이 쓰고 있다. 즉, 아키텍트들은 소프트웨어의 설계와 구현의 지침을 담당하기 때문에 어플리케이션의 가장 깊은 부분과 가장 넓은 부분을 알아야 한다.

아직 난 아키텍트가 아니기에 아키텍트가 되었을 때 지금 개발하는 즐거움보다 얼마나 많은 즐거움을 나에게 줄지 알 수가 없다. 하지만 전체시스템을 아우르고 프레임웍에 대해 고민한다는 부분은 분명 매력적이다. 국내 기업들도 코딩만 잘하는 개발자 보다는 아키텍트를 많이 확보하는 것이 개발사의 경쟁력이 될 거라 생각한다.


로지컬 씽킹

어떻게 하면 논리적으로 상대방에게 내 생각을 전달할 수 있을까? 커뮤니케이션의 가장 중요한점은 논리적인 메시지를 전달하는 것이라고 말할 수 있겠다. 어떠한 비즈하스도 커뮤니케이션 없이 성립하는 비즈니스는 없을 것이다.  우리가 처한 다양한 비즈니스 환경속에서 상사, 부하, 동료 들을 자신이 생각했던 것과 같이 이해시키고 설득시켜 원하는 바를 이루고 또 이런 결과를 성과와 연결 시켜야만 한다. 이것들을 가능하게하는 ‘논리적인 메시지를 전달함으로써 상대방을 설득하고 자신이 생각한 반응을 상대방으로부터 이끌어내는 기술’을 바로 ‘로지컬 커뮤니케이션’이라고 한다.

상대방에게 전달하는 것은 상호간의 응답이 있어야 한다. 나만이 알고있는 ‘자신밖에 모르는 병’, ‘얼치기 독심술’에 빠져 ‘전달할 내용을 갑작스럽게 전달’ 하지는 않는지 주의할 필요가 있다 결론은 '과제에 대한 답변의 요약'이지, '자신이 말하고 싶은 것의 요약'이 아니다. 또한, 상대방이 납득하지 못하는 전달자의 답변에 핵심을 이루는 ‘결론’과 그러한 결론이 어떻게 이르게 되었는지에 대한 이유인 ‘근거’, 결론이 액션인 경우, 상대가 그 액션을 취하도록 구체적인 방식을 제시하는 ‘방법’이 제대로 전달되지 않았나 살펴보아야 한다. 전달하려는 메시지의 목표와 근거를 명확히하고 무엇을 말해야 답변이 될 수 있을지를 생각하며, 상대방의 반응을 전달하기 전에 미리 생각해봄으로써 제대로 전달 할 수 있을 것이다.

전달하는 내용을 논리적으로 사고를 정리하기 위해서는 중복, 누락, 착오를 막고 이야기의 비약을 없애는 기술이 필요하다. ‘MECE(Mutually Exclusive and Collectively Exhaustive)’ 기술은 ‘어떤 사항과 개념을 중복없이, 그리고 누락없는 부분으로 전체를 파악하는 것’이다. 전체집합을 누락도, 중복도 없는 부분집합으로 나누어 전달함으로써 상대방이 이해하기 쉽고, 또 알고 싶어하는 것을 간결하게 제시할 수 있다. MECE프레임웍 으로는 ‘기업의 업계 환경을 전체 집합으로 했을 때 3개 혹은 4개의 C로 시작하는 요소를 파악’하는 3C/4C(Customer, Competitor, Company, Channel)와  ‘어떤 고객층을 설정하고 그 고객에 대해 어떤 상품을 어떻게 판매 할 것인가 하는 마케팅을 생각할때 활용’하는 4P(Product, Price, Place, Promotion)가 활용될 수 있을 것이다. 또한 많은 정보 속에 MECE기준을 발견하고, 전체상을 파악하기 쉽도록 몇 개의 근거를 뒷바침 해줄 수 있는 그룹으로 분류하는 것이 도움이 될 것이다.

So What? (왜 이런 얘기를 하는 것인가?)/Why So? (구체적으로 무엇인가?)를 활용하여 메시지를 전달 하는 방법을 사용하여 비약되어 이야기가 엉뚱한 방양으로 흘러가는 것을 막을 수 있다. So What? 은 ‘갖고 있는 데이터 전체 혹은 그룹핑된 데이터 중에서 과제에 비추어보아 대답할 수 있는 엑기스를 추출하는 작업’이고, Why So?는 ‘So What?한 요소의 타당성이, 갖고 있는 데이터 전체 혹은 그룹핑된 요소에 의하여 증명된다는 것을 검증하는 작업’이다. 어떤 정보가 나타내는 사실을 내가 해석한 것과 상대방도 똑같이 결론을 명시하는 것이 중요하다. 현상이나 사실의 포인트를 정확하게 설명하는 ‘관찰’의 So What? /Why So?과 현상이나 사실에 입각하여 그것들의 공통 항목이나 메커니즘을 포착하는 ‘통찰’의 So What? /Why So?으로 나눠 볼 수가 있다.

뛰어난 커뮤니케이터란 누구도 생각해낼 수 없는 참신한 아이디어를 누구나 쉽게 이해할 수있도록 설명할 수 있는 사람일 것이다. 이런 사람은 정확한 관찰의 So what?/Why So? 위에 새로운 MECE의 개념으로 전체상을 부여하여 통찰의 So What?/Why So?를 하는 ‘로지컬 커뮤니케이션’을 할때 탄생할 가능성이 높을 것이다.

Labels:

이기는 습관

인생도 비즈니스도 습관을 통해 결정 짓게 된다. 동사 형 조직, 프로 사관학교, 지독한 프로세스, 채화된 마케팅적 사고, 규범이 있는 조직문화, 집요한 실행력을 통해 이기는 습관을 가질 수 있다.

‘동사형’ 이란 단순한 움직임을 일컫는 것은 아니다. 목적도 체계도 없는 것은 진정한 동사 형 행동이 아니다. 내가 지금 무엇을 하고 있는지 어디로 가고 있는지를 뚜렷하게 인식하고 주도적으로, 실질적으로 수행하는 것이 참다운 동사 형 행동인 것이다. 내가 맡은 일에는 할 수 있는 한 최선을 다하고 항상 뜨거운 열정을 가지며 시간을 아끼고 효율적으로 사용하기를 노력하고 변화와 혁신을 위해 노력하는 것이 동사 형이라고 할 수 있겠다.

세상은 절대적으로 잘하는 사람 보다는 남들보다 조금만 더 잘하는 사람을 원한다. 남들보다 더 잘하기 위해서는 남들보다 더 노력해야 하는데 여기에는 약간의 괴로움이 추가된다. 한 뼘 차이는 사소해 보이지만, 그것이 바로 인생의 커브를 바꾸어놓는다. 인생도 비즈니스도 자신을 어떻게 마케팅 하느냐에 달려있다. 운이 없어 성공을 못한다는 변명 보다는 끊임없이 내 몸값을 올리기 위해서 노력하는 자에게 성공할 수 있는 기회가 주어지는 것이다. 간단한 제안서일지라도 내가 만들 때 스페셜 제안서가 탄생해야 하고 회사를 일하면서 배울 수 있는 그런 공간으로 재 탄생시켜 항상 자기 자신의 능력을 향상 시키도록 노력해야 한다.
프로세스, 룰, 시스템이 확실히 구축되어 있다면, 그 어떤 사람이 들어오더라도, 또 어떤 위기상황에 맞닥뜨리더라도 흔들림 없이 일관성을 유지할 수 있다. 1+1=2가 아니라 10이나 20이 될 수 있는 것이 바로 프로세스의 힘이다. 프로세스는 누구나 보고 쉽게 이해할 수 있어야 하고 그로 인해 지식이 공유되고 역량이 상향 평준화를 이룰 수 있도록 되어야 한다. 목표는 원대하게 정하고 평가는 냉혹하게 할 수 있는 프로세스도 필요하고, 현상들을 잘게 쪼개서 분석할 수 있는 능력과 실패를 가장 좋은 교재로 삼을 수 있게 하는 실패노트를 작성하는 것도 도움이 될 것이다.

개발이나 기획을 담당하는 사람이든, 인사와 관리를 담당하는 사람이든, 재무를 담당하는 사람이든, 누구라도 모든 생각과 의사결정의 채널을 고객감동의 주파수에 맞추어야 할 것이다. 마케팅 부서가 기업 전체는 아니지만, 기업 전체가 마케팅 부서가 되어야 한다. 탁상공론 보다는 항상 현장에서 문제를 찾고자 하는 행동이 있어야 하고, 고객의 작은 소리에 귀를 기울일 수 있는 조직이 성공하는 조직이 될 것이다.

규율이 없는 자유는 방종에 불과하고, 책임이 없는 창의는 방만함에 불과하다. 인간이란 누구든 자기중심적인 사고방식을 가지고 있어서 규칙이나 규범이 없으면 제 편한 대로 하려는 본성이 튀어나오기 마련이다. 항상 즐거운 마음을 가지면서 회사에 규율을 잘 지키고 짧게는 하루, 일주일 길게는 한달, 일년을 전략적으로 살아감으로써 성과를 달성할 수 있는 조직이 될 수 있을 것인지도 결정 될 것이다.

마지막으로 이기는 습관에서 가장 중요한 항목은 바로 ‘집요함’이다. 똑 같은 정보를 접하더라도 전혀 다른 산출물을 만들어 낼 수 있는가가 바로 집요함의 차이인 것이다. 성실함과 겸손함으로 자신을 낮출 줄 알아야 하며 잘하는 사람을 무조건 따라 하든 배움을 청하고자 하는 집요함이 필요하다. 모든 이에게 하루 24시간은 모두 동일하겠지만 어떤 사람은 50%만 향유하는 사람이 있는 반면에 어떤 사람은 300%, 500%향유하는 사람이 있다. 이것이 바로 집요함의 차이인 것이다. 집요한 만큼 보이는 삶의 이 끈질긴 법칙을 자기자신의 것으로 만드는 것이 중요하다.

Labels:

바보들은 매일 회의만한다

수 십 년간 세상은 많이 변하고 변화 속도 또한 빨라졌지만 정작 의사 결정의 중요한 역할을 하는 회의 진행 방식은 바뀌지 않고 있다. 현상 유지만 급급한 회의, 의견 수렴의 수단이 아니라 처음부터 결론이 나있는 회의 등이 그것이다. 우리는 어느새 회의의 의미보다는 회의에 참석하는데 더 큰 의미를 갖고 있진 않았는가? 회의의 겉모습 보다는 정말 필요한 회의인지, 목적과 의제는 분명한지, 결론을 명확히 했는지, 사전 준비는 철저히 했는지, 회의 시간을 지켰는지, 회의록은 작성했는지, 창조적인 활동의 장이라는 마음가짐을 가졌는지를 먼저 살펴야 할 것이다.

창조적인 회의를 가능케 하는 사람을 퍼실리테이터(Facilitator) 라고 부른다. 즉, ‘회의를 수월하고 부드럽게 이끌어가는 사람’이라는 의미이다. 퍼실리테이터가 되기 위해서는 다음의 7가지 조건을 만족해야 한다. 첫째, 누구나 스스럼 없이 발언할 수 있도록 회의를 컨트롤 해야 한다. 둘째, 회의 전에 충분히 준비 되어 있어야 한다. 셋째, 회의 중 한 사람의 일방적인 발언이 되지 않도록 조율할 수 있는 능력이 필요하다. 넷째, 회의가 목표에 도달할 수 있도록 회의 프로세스를 정확히 밟아 갈 수 있어야 한다. 다섯째, 비주얼한 도해를 통해 정보를 공유할 수 있어야 한다. 여섯째, 회의 시간을 정하고 배분하고 그 시간 내에 최대한 성과를 낼 수 있어야 한다. 일곱째, 회의에서 중립적인 입장을 지켜야 한다.

회의에 있어 참가자의 발언을 이끌어 내기 위한 방법은 회의 참석자들이 편안한 기분을 느끼게 하고 회의 시 상하관계를 의식하지 않도록 하여 일방적인 정보 전달 방식이 아닌 많은 사람에게 정보 전달을 효율적으로 하기 위함이 목적이 되는 회의가 될 때 가능한 것이다. 일방적으로 자신이 하고 싶은 말만 하는 회의 보다는 다른 사람의 말에 귀 기울여 주는 자세가 요구된다. 퍼실리테이터는 이런 회의장의 분위기를 잘 파악하여 참석자 전원을 리드해 가는 자세를 보여 주는 것이 중요하다.
이렇게 이끌어낸 발언들을 토대로 회의 참석자들이 논리적으로 생각하게 하기 위해서는 먼저 회의 진행과정과 결론을 도출하는 과정 전체가 합리적 이어야 한다. 논리적으로 설명하게 되면 상대를 납득 시킬 수 있고 동의하는 사람이 많을수록 회의 운영도 유연해 지는 것 이다. 중요한 부분을 빼먹지 않기 위해서 거시적인 시각과 미시적인 시각 둘 다 요구되며 매트릭스를 통해 정리해 보거나 계층적으로 나눠 정보를 정리하는 것도 도움이 될 것이다.

마지막으로 회의에 결론은 참석들이 결론을 납득하고 마음에 의구심을 품지 않도록 하기 위해서는 회의 프로세스를 제대로 밟아 나가는 것이 필요하다. 서로간의 갈등을 해소해 가면서 더 나은 해결책을 찾아야 하겠고, 서로를 이해하고 공감함으로써 윈윈(Win-Win)이 되는 결론에 도달할 수 있는 것이다. 대안들의 합의를 이끌어가는 가치를 정량, 정성 평가를 통해 장단점을 구분할 수 있을 것이고, 조해리 창을 활용하면 서로의 대한 이해도를 넓혀가는데 도움이 될 것이다.

Labels:



Subscribe to: Posts (Atom)