라떼군 이야기

Unique Visitor에 대해

2011-05-13T22:54:00.000-07:00

요즘 흔히 인터넷 서비스의 사용을 평가하기 위해 Unique Visitor(이하 UV)를 사용하는 것을 자주 보았을 것이다. UV는 순 방문자 수를 뜻한다. 즉, 한 사람이 여러 번 같은 사이트를 방문했더라고 한 명으로 측정되는 기준을 말한다. UV는 Page View(PV), 트래픽(traffic), 대역폭(bandwidth)과 더불어 해당 서비스의 사용자 분석 및 마케팅 자료로 널리 사용되고 있다. 하지만 connection-less의 웹 환경에서 UV를 정확하게 계산하는 것은 여간 어려운 일이 아니다. 현재 여러 가지 시도를 통해 더 정확한 UV를 계산하기 위한 노력이 이뤄지고 있다.

UV를 계산하는 방식은 크게 사이트 중심(site centric) 방법과 사용자 중심(user centric) 방법으로 나눈다[1]. 두 가지 방법 중 가장 많이 사용되고 있는 방법은 사이트 중심 방법이다. 사이트 중심 방법의 대표적인 것은 수집된 로그를 분석하는 것이다. 다시 말해서 수집된 로그에서 유효한 데이터를 추출하여 UV를 계산하는 것이다. 수집된 로그에서 사용되는 속성으로 IP가 많이 사용된다. 하지만 이는 공유 IP 환경에서 문제가 될 수 있다. 같은 IP 주소로 기록된 로그라도 실제 다른 사용자 일 수 있고 DHCP(Dynamic Host Configuration Protocol)를 기반을 사용하는 ISP 업체의 서비스 종류에 따라 IP는 요청 시 변경될 수 있다. 개선된 방법으로 IP와 User-Agent를 동시에 확인하는 방법이 제안되었다. 하지만 이 방법 또한 IP와 User-Agent 모두 같은 환경에서 사용자를 구분해 낼 수는 없다.

사이트 중심 방법 중 비교적 정확하다고 알려진 방법은 첫째로 로그인 기반 정보를 이용하는 방법이다. 이 경우 특정 시간대별로 사용자를 구분해 낼 수 있다. 두 번째로 쿠키(cookie)를 이용해서 계산하는 방법이다. 처음 방문할 때 해당 서비스에 대해 쿠키가 생성되고 쿠키가 만료되기 전까지는 여러 번 방문하더라도 같은 사용자로 인식한다. 구글(Google)의 Analytics 서비스도 이 방법을 사용한다[2]. 하지만 첫 번째 경우 한 사용자가 중복된 계정을 통해서 같은 서비스를 이용할 경우 오차가 발생하게 되고 두 번째 경우는 같은 컴퓨터를 여러 명이 사용하는 공공 환경에서의 통계는 활용할 수 없다는 문제점이 있다. I/Pro, NetCravity, MachLogic가 사이트 중심 방법을 채택하고 있다.

사용자 중심 방법은 표본 추출에 기초한 패널을 구성한 뒤 데이터 수집 소프트웨어를 설치해 행동을 추적한다. TV 시청률 조사 방법인 피플미터(people meter) 방식과 유사하다. 사용자 중심 방법의 전제 조건으로 독립적이고 객관적인 제3의 기관에 의해 측정됨으로써 객관성이 확보되어야 한다. 패널 기반으로 하고 있기 때문에 인구 통계학적 특성 및 시간 경과에 따른 사용 누적 통계 파악이 가능하다. 하지만 사용자의 요청들과 행위들을 모두 수집하는 데 어려움이 있고 데이터를 수집하는 소프트웨어에 따라 정확도와 신뢰성이 크게 좌우될 수 있다. ComScoreMatrix, Nielsen/NetRations, 코리안 클릭 등이 사용자 중심 방식을 채택하고 있다.

코리안 클릭은 iTrack이란 소프트웨어를 사용하고 1만 명 가량의 패널을 사용하여 인구 비례에 맞추어 전체 인터넷 사용자의 패턴을 역산한다[3]. iTrack의 특성상 윈도우(Windows)의 인터넷 익스플로어 사용자로 범위가 제한된다. 패널에 설치된 iTrack을 이용해 방문한 사이트 정보를 실시간으로 전송받아 패널이 속한 고객 세그먼트에 따라 통계적 기법을 적용하고 추정한다.

Fig.1 Count on Confusion[4]

상이한 수집방법과 오차들로 때문에 통계 수집기관마다 결과가 달라질 수 있다. 2008년 월스트리트 저널에 실린 한 기사[4](Fig.1 참고)에 따르면 닐슨(Nielson)이 수집한 UV 데이터와 comScore의 데이터가 서도 다름을 알 수 있다. 아직 마땅한 대안이 없어 많은 마케터들이 광고비 지출에 대해서는 comScore나 닐슨, iTrack같은 웹 측정 회사에 의존하고 있는데 이러한 결과의 맹목적인 신뢰는 잘못된 의사결정으로 이어질 수 있는 문제점이 있다. 심지어 “인터넷에 진실은 없다.”라는 말도 이 있다. 이것은 보는 관점에 따라 무엇이든 진실이 될 수 있다는 의미로 생각한다. 국내에서는 통계 수집기관이 다양하지 않음으로 인해 그 결과의 완전히 신뢰하는 것은 의사판단에 위험이 너무 크다. 따라서 의사 결정에서 이러한 통계는 참고자료로만 활용해야 하고 실제로 정확한 통계를 필요할 경우 가지고 있는 인프라나 다른 신뢰할 수 있는 채널을 통해 정보를 얻는 것이 바람직하다고 생각한다.@

[1] 넬슨코리안클릭

[2] Unique Visitors (or Absolute Unique Visitors)

[3] 인터넷 포털에서의 과학 토픽 검색에 관한 연구 / 송대섭 / 2009

[4] Agencies Know the Score on Web Tracking

클라우드 컴퓨팅 (Cloud Computing)

2011-02-10T20:00:00.000-08:00

http://www.flickr.com/photos/pagedooley/4340727578/

세상이 달라졌다. 얼마 전까지만 해도 아이디어를 실현하는 일은 쉽지 않았다. Facebook과 같은 아주 좋은 아이디어가 있다고 해도 그 아이디어를 실현하기 위해서는 많은 자본, 설비, 네트워크 비용, 운영을 위한 전담 팀이 필요했었다. 이 많은 것들을 준비하기 위해서는 많은 돈이 필요했었다. 결국, 회사나 개인은 아이디어를 실현하는 데 있어서 소극적일 수밖에 없고 그러는 사이에 경쟁에서 뒤처지게 된다. 하지만, 이제는 아니다. 소셜 네트워크 서비스들을 살펴보라. 누구나 한 번쯤은 생각했던 서비스들이 하루가 멀다 하고 쏟아져 나오고 있다. 이들의 숨은 원동력은 무엇일까?

구글(Google) 서비스를 예를 들어서 한번 생각해 보자. 지메일(Gmail)을 쓸 때 네트워크 비용이 얼마나 들지 고민하면서 사용하는가? 피카사(Picasa) 웹 앨범에 파일을 올릴 때 스토리지 가용성 얼마나 되는지 파일의 신뢰도는 얼마나 되는지를 고민하는 사람이 있을까? 그냥 단순히 우리는 사용하기만 할 뿐이다. 필요할 때 용량을 구매하고 필요할 때 네트워크 비용을 추가 지불한다. 이것이 바로 클라우드(Cloud)인 것이다

그리드(Grid) 컴퓨팅이라고 들어봤는가? 이전에 유행하던 그리드 컴퓨팅을 클라우드와 같은 것으로 생각해서는 안 된다. 그리드 컴퓨팅은 인터넷상에 연결되어 있는 서버와 클라이언트 PC 등의 비어 있는 컴퓨팅 파워를 합하여 하나의 컴퓨터로 인식하는 것을 말하지만 클라우드는 더 넓은 범위의 데이터센터를 하나의 자원으로 보이게 한다는 점에서 이와 확실히 구별된다.

이처럼 놀라운 클라우드는 그 발전가능성에 많은 주목을 받고 있다. 구글의 CEO인 에릭 슈미트(Eric Emerson Schmidt)는 한 포럼에서 웹 3.0이란 구름 속에 있는 웹 애플리케이션들의 조합이 될 것이라고 답한 적도 있다. 구글이 이렇게 얘기했다니 그대로 실현될 것만 같은 느낌이 든다. 사실 다른 선진국으로 눈을 돌려보면 클라우드는 이제 막 시작되는 우리나라에서와는 다르게 이미 이슈가 되어왔고 상당히 보편적으로 사용하는 서비스가 되어가고 있다. 우리나라는 클라우드 선진국과 비교할 때 약 4년 정도의 격차가 존재한다고 하지만 분명히 우리도 클라우드 영역에 들어섰고 앞으로의 미래도 이와 같은 형태로 발전할 것임은 믿어 의심치 않다.

소프트웨어의 클라우드는 다음과 같은 세 단계로 발전해왔다. on-premise 방식으로 즉, 회사, 파트너, 고객 스스로 데이터 센터를 구축하고 완전히 컨트롤하고 100% 책임지는 방법에서부터 시작해서 지난 10년간 가지고 있는 하드웨어를 임대하여 사용하는 host 환경이 유행하였고 최근에 돈을 주고 컴퓨팅 리소스 풀을 사용하는 클라우드 컴퓨팅이 나타나고 있다. 클라우드 컴퓨팅은 리소스 풀을 필요에 따라 줄이거나 늘릴 수 있다. 따라서 우리가 원하는 공급 곡선과 유사하게 클라우드 자원을 늘이거나 줄일 수 있다는 말이고 비용도 공급과 비례하게 합리적으로 지불하면 되는 것이다.

클라우드는 모바일과 더불어 하나의 큰 패러다임(paradigm)으로 우리에게 다가오고 있다. 이를 어떻게 활용하는가에 따라 큰 기회가 될 수 있음을 이런 변화를 통해 상기해야 한다. 지금까지는 아이디어를 실현하는 것이 성공의 열쇠였다면 앞으로는 그 아이디어 자체와 아이디어를 실현하는 속도가 성공의 열쇠가 될 것이고 바로 클라우드가 이런 기회를 제공하게 될 것이다.@

알고리즘의 선택과 활용

2010-12-26T19:46:00.000-08:00

Algorithms

컴퓨터 공학(Computer Science)에서는 다음과 같은 3가지 기본적인 계층(Layer)으로 구성되어 있다고 말할 수 있다. 수학과 통계 그리고 이를 이용한 알고리즘(Algorithm)[1]과 데이터 구조, 그리고 이것들을 가공하여 네트워크(Network), 데이터베이스(Database), 그래픽스(Graphics)를 통해서 표현하는 계층으로 나눌 수 있다. 각 계층은 하위 계층을 바탕으로 상위 계층의 문제들을 풀어갈 수 있다. 때문에 하위 계층일수록 그 역할이 아주 중요하다. 이런 계층 중 수학적 이론에 기반을 두고 이를 통해 실 세계 문제들 풀어갈 수 있는 알고리즘 대해 얘기해보고자 한다.

알고리즘의 목표는 무엇일까? 그것은 어떤 문제를 남들보다 효과적으로 빠르게 해결하고자 하는 것이다. 알고리즘을 잘 만들기 위해서는 잘된 디자인(Design)과 좋은 분석(Analysis)과정이 필요하다. 다시 말해서 어떻게 문제를 풀어나갈지 디자인하는 것과 그것이 다른 방법보다 우수한지 분석할 수 있는 능력이 필요하다는 것이다. 이 과정의 기술은 하루아침에 이루어지는 것이 아니라 어떤 문제가 주어졌을 때 그 문제에 접근(Approach)하는 습관을 꾸준히 길러야만 가능하다.

실제로 많은 개발자들이 프로그램을 만들다 보면 앞으로 증가할 데이터의 양과는 상관없이 현재 테스트 되는 데이터를 가지고 결과가 어느 정도 만족할 수준의 속도라면 그냥 넘어가는 경향이 있다. 10건일 때 결과가 0.1초가 나와서 만족했지만 100만 건 1,000만 건일 때 10시간 100시간 이상이 걸릴 수도 있다. 보통 이런 문제들은 개발 단계에서 나타나기보다는 실제 시스템을 운용할 때 나타나고 그에 따른 손실은 개발 비용과 비교할 수 없을 만큼 크다. 이 때문에 설계 단계부터 알고리즘의 선택은 설계단계부터 아주 신중하게 고려되어야 한다.

아주 간단한 예를 들어 살펴보면 1부터 10까지 숫자가 무작위로 나열되어 있는데 이를 정렬하는 문제를 풀어야 한다고 생각해보자. 모든 문제가 그렇듯이 무한정 시간과 자원이 주어진다고 가정하고 하나씩 정렬하다 보면 언젠가는 답이 나오기 마련이다. 다시 말해 Brute-Force[2] 방식을 통해 하나하나 모두 나열해 가면 복잡한 디자인 과정 없이도 우리는 이 문제를 풀 수는 있다. 이는 시간복잡도로 표현하면 O(n^2)로 나타낼 수 있다. 작은 양의 데이터의 문제에서는 꽤 좋은 방법이라고 생각될 수도 있겠지만, 대용량 데이터의 문제에서는 그것이 과연 좋은 접근 방법인지는 다시 생각해볼 필요가 있다.

다른 방법으로 큰 집합은 한번에 정렬하기 어려우니 1부터 5까지 그리고 6부터 10까지 나누는 등 작게 쪼개어 부분집합을 정렬하는 방식인 Divide and Conquer[3]를 생각해볼 수도 있겠다. 결국, 그 유명한 Quick Sort[4]를 적용하는 것이 되는데 위에 Brute-Force 방식보다는 확실히 빨라진다. O(log n) 정보의 시간복잡도가 나올 것으로 예상된다. 하지만, 이것이 최적의 방법일까? 더 나은 방법이 없을지 계속 고민해봐야 한다.

상황에 따라 다르겠지만, 직관적인 방법이 빠를 때도 있다. 10Kg 가방에 넘치지 않게 제한적인 보석을 넣는 0-1 Knapsack[5] 문제를 생각해 보자. 이 문제를 Brute-Force 방식이나 Divide and Conquer를 이용해 풀기는 어려울 수 있다. 다른 방법으로 현재 취할 수 있는 최선의 결과를 미래에 줄 영향을 고려하지 않은 채 선택하는 Greedy를 생각해 볼 수 있을 것이다. 문제에 따라 Greedy가 위 두 가지 문제보다 훨씬 더 빠른 해답을 줄 수 있다. 하지만, 이 방법이 항상 Global optima 결과를 반환해 줄지는 생각해봐야 한다. 하지만, 이 경우에서 Greedy는 Local optima이라는 문제가 있다.

그럼 Global optima를 구하기 위해서는 어떻게 해야 할까? 0-1 Knapsack 문제에서는 가방에 보석을 담을 수 있는 모든 경우를 생각해보면 Global optima를 구할 수 있다. 트리를 이용해 해당 보석을 담을 경우와 담지 않을 경우를 나누어 모두 탐색하면 최적의 해를 구할 수 있다. 트리를 탐색하다 보면 leaf 노드에 다다랐을 때 잘못된 경로를 통해서 왔는지를 깨 닳은 경우가 있는데 이럴 땐 Backtrack 해 다른 노드를 탐색하게 하는 방법이 Backtracking[6]이다. 또한, 미래의 데이터를 예측해 더는 자식 노드를 탐색하지 않아도 된다고 판단하는 방법이 Branch and Bound[7] 방법이다.

이 외에 Hill climbing, Genetic algorithm 등등 수많은 많은 알고리즘이 존재한다. 모든 경우를 설명할 수 없지만 잊지 말아야 할 것은 풀어야 할 어떤 문제에 대해서 여러 방법으로 풀 수 있는 경우가 항상 존재하고 그 중에 어떤것이 가장 좋은지 그 솔루션을 분석해 더 좋은 것을 취할 수 있는 선택이 주어진다는 것이다.

어떤 알고리즘을 선택하느냐는 문제의 종류와 프로그램을 사용하는 고객이 원하는 결과 수준에 따라 달라질 수 있다. 하지만, 개발자들은 항상 지금 해결해야 할 문제보다 더 좋은 다른 방법이 있을 수 있다는 것을 인지하고 어떻게 풀어갈지를 설계(Design), 분석(Analysis)해 최적의 방법을 적용할 수 있는 능력을 꾸준히 길러야 할 것이다.@

[0] http://ai.cau.ac.kr (Daewon Kim)
[1] http://en.wikipedia.org/wiki/Algorithm
[2] http://en.wikipedia.org/wiki/Brute-force_search
[3] http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm
[4] http://en.wikipedia.org/wiki/Quicksort
[5] http://en.wikipedia.org/wiki/Knapsack_problem
[6] http://en.wikipedia.org/wiki/Backtracking
[7] http://en.wikipedia.org/wiki/Branch_and_bound

왜 버전 관리 시스템을 사용해야 할까?

2010-12-19T07:29:00.000-08:00

Revision

왜 버전 관리 시스템(version control, revision control)을 사용해야 할까? 성공한 프로젝트 개발자에게는 너무나 당연한 명제로 생각 되고 있기 때문에 오히려 왜 사용하지 않으면 안된지를 말하는 것이 쉬울지도 모르겠다. 버전 관리 시스템을 사용해야 하는 이유를 ‘협업’과 ‘변화’에서 찾아야 한다고 생각한다.

소프트웨어 개발에 있어서 항상 일정의 문제와 요구사항의 변화는 개발의 역사와 함께 지금까지도 가장 풀기 어려운 문제로 여겨지고 있다. 일정 관리와 요구사항 변화만 뺀다면 소프트웨어 개발은 지금보다 훨씬 쉬워질지 모른다. 하지만 이 두 가지 사항을 배제한 성공한 프로젝트는 아직까지 없다 라고 확신할 수 있다. 어떤 형태든 고객을 빠르게 만족시켜야 하는 것이 소프트웨어 성공을 결정 짓는 열쇠가 되기 때문이다. 우리는 이런 문제를 해결하는데 있어서 버전관리 시스템을 통해 얻을 수 있는 장점은 다음과 같다.

첫째로, 버전 관리 시스템을 사용함으로써 현재 개발중인 버전과 릴리즈 된 버전을 분리할 수 있다. 같은 소스의 여러 리비전(revision)을 관리할 수도 있다. 리비전을 관리한다는 말은 현재 작업한 버전과 어제 완료하여 출시한 버전으로 따로 구분할 수 있다는 말이다. 이것이 가능함으로써 버전관리 시스템 이전에 우리가 해왔던 일일이 소스를 복사해 보관하고 다른 리비전과 현재 리비전을 수동으로 비교해가며 힘들게 병합(merge) 했던 일들이 손쉽게 해결됐다. 또한 새로운 릴리즈 버전을 준비하면서도 이전 버전의 버그 수정, 적용도 손쉽게 되었다.

두 번째로, history 관리 기능이 강력하다. 공동 작업을 하다 보면 누가 어떤 부분을 수정해 문제가 되었는지 언제 수정되었는지 알 수 없는 경우가 많았다. 다른 사람이 수정한 코드를 제대로 알지 못해서 중복된 코드를 생산해 내거나 알 수 없는 버그를 만들어 내기도 했다. 버전 관리 시스템은 막강한 history기능을 제공함으로써 소스의 추가, 수정, 삭제 등을 모두 추적할 수 있고, 혹시 누가 잘못 수정한 내용이 있다 하더라도 손쉽게 이전으로 돌릴 수 있는 기능을 제공한다.

세 번째로 중앙 집중적 소스관리이다. 버전 관리 시스템 이전에는 개발자 PC에만 존재하는 소스가 있고 여러 가지 이유로 소스가 유실되는 경우도 많았다. 또, 소스 저장소가 여러 군데로 분산되어 있었기 때문에 백업 및 관리하기도 어려웠었다. 개발사에서 가장 큰 자산이 되는 것을 꼽으라면 사람 이외 소스코드를 생각할 수 있을 것이다. 소스코드야 말로 회사가 투자한 결과물의 결정체라고 생각할 수 있다. 이런 결정체를 버전 관리 시스템을 사용함으로써 소스코드를 안전하게 보관할 수 있게 해준다.

국내에는 아직 개발사라고 하면서도 아직 버전 관리 시스템을 사용하지 않는 회사들이 상당히 많은 것으로 알고 있다. 이름만 대면 알만한 회사들도 사용하지 않고 있는 곳도 실제로 알고 있다. 버전 관리 시스템을 도입하는 초기에는 오히려 불편한 것이라고 생각되어 반발이 있을 수 있지만 장기적으로 봤을 때 회사에 분명한 이익을 가져다 줄 것이므로 반드시 도입되어야 한다.

현재 CVS(Concurrent Versioning System)를 시작해서 Subversion, 머큐리얼(Mercurial), Git(분산 버전 관리 시스템) 등 수많은 버전 관리 시스템들이 존재하지만 각각의 장단점이 존재하기 때문에 상황에 맞게 어떤 것을 써도 상관없다. 기능은 약간씩 다르지만 이것들의 공통적인 목표는 ‘협업’과 ‘변화’에 잘 대응하는 개발 환경 구축을 도와주는데 있다. 협업을 통한 일정 통제와 요구사항 변화에 대응에 성공한다면 그 프로젝트는 거의 절반의 성공은 이루고 시작하는 것과 다름 없을 것이다.

http://ko.wikipedia.org/wiki/버전_관리

디자인 패턴(design pattern)은 언제 적용해야 할까?

2010-11-25T06:37:00.000-08:00

소프트웨어 설계 시 자주 나는 미래의 변화를 좀더 쉽게 수용하기 위해 지금 당장 디자인 패턴을 적용할 것인지에 대해 고민한다. 프로젝트의 성격과 조직의 특성에 따라 선택의 결과가 때로는 좋았을 수도 그렇지 않았던 경우도 있었다. 그러면 도대체 언제 디자인 패턴을 적용하는 것이 좋을까? 패턴을 적용하는 것이 과연 항상 좋은 결과를 가져다 주는 것일까? 고민에 빠지게 된다.

내가 생각한 결론은 다음과 같다. 디자인 패턴을 적용한 설계가 올바른 설계일 경우도 있고 그렇지 않을 경우도 있다는 것이다. 다음과 같은 3가지 측면에서 생각해 볼 수 있다. 첫 번째로 코드 재사용 측면이다. 디자인 패턴을 적용하게 되면 중복인 코드는 제거되고 코드 재사용 가능한 구조로 바뀌게 된다. 중복된 코드를 제거한다는 것은 그만큼 오류를 줄인다는 것으로 생각할 수도 있다. 결국 많은 부분에서의 코드 커버리지(Code Coverage)를 할 수 있다는 것을 의미한다. 코드 커버리지란 소프트웨어 테스트 시 사용되는 측정 기준 중 하나고, 얼마만큼 그 소프트웨어가 테스트되었는지를 나타낸다. 따라서 코드 커버리지를 증가시킬 수록 그 만큼 테스트가 많이 되었다는 것을 의미한다. 실제로 중복코드와 오류밀도의 관계에 대한 내용이 알려진바 있었다.[1][2]

두 번째는 성능 측면이다. 디자인 패턴을 이용하게 되면 그렇지 않을 때보다 코드는 간결해 지지만 많은 상속(inheritance)과 구현, 컴포지션(composition) 등으로 인해 복잡한 구조를 갖게 될 수 있었다. 이러한 복잡한 구조는 객체 생성에 필요한 오버헤드가 필요하므로 성능저하의 원인이 된다. 실제로 같은 코드를 class와 상속 구조로 만들어 필요할 때마다 새로운 객체를 생성한 코드보다 그렇지 않은 코드가 빠르다는 것을 확인 할 수 있다.[3] 성능이 아주 중요한 소프트웨어라면 복잡한 패턴 적용은 신중히 생각해야 한다.

세 번째는 생산성 측면이다. 디자인 패턴에서 말하는 "확장 가능하고 유지보수하기 수월한" 코드라는 것은 코드 작성시 미래를 염두 해 작성한다는 것을 의미한다. 이는 현재에는 필요 없는 코드라 할지라도 미래에 변경될 것을 예측하여 수정한다는 것을 의미하는데 이것은 엄밀히 따지면 현재 불필요한 일을 하게 되므로 생산성을 저해하게 된다. XP(Extreme Programming)[4] 에서는 생산성 향상을 위해서는 두 번까지의 코드 중복이 일어나기 전까지는 기존 방식을 유지하고 세 번째 중복이 발생할 때 구조를 변경해 보는 것이 생산성 향상에 도움이 된다고 말하고 있다.@

Head First - Design pattern[5]

[1] http://www.wired.com/software/coolapps/news/2004/12/66022

[2] http://www.ibm.com/developerworks/kr/library/tutorial/j-lessismore/section2.html
[3] http://shootout.alioth.debian.org/
[4] http://c2.com/cgi/wiki?ExtremeProgramming
[5] http://kangcom.com/sub/view.asp?sku=200508240010

규칙기반 전문가 시스템 (Rule-based expert system)

2010-09-22T06:52:00.000-07:00

컴퓨터로 어떤 일을 시킬 때 보통은 명확한 규칙에 따라서 처리하게 된다. 그 이유는 아직 컴퓨터는 인공지능을 갖지 못하였다. 인간처럼 여러 가지 지식과 현상을 조합해 사고하지 못한다는 말이다. 그 때문에 사람이 컴퓨터의 능력을 이용해 어떤 일을 처리할 때는 일련의 규칙이 필요했다. 예를 들면 IF … Then … Else로 표현되는 규칙을 적용하는 것이다.

하지만, 실생활의 문제들은 이것들도 표현할 수 없는 것들이 너무 많다. 인간이 생각하는 거의 모든 것들이 이런 모호함의 집합이다. “오늘 날씨 너무 덥다. 시원하게 에러컨좀 틀어!”라고 했을 때 “너무 덥다.”, “시원하게” 등의 말들은 컴퓨터가 처리할 수 없는 것들이다. 몇 도로 온도를 유지했을 때 시원하다고 느끼는지 컴퓨터 자체만으로는 알 수가 없다. 컴퓨터는 정확히 수치화된 데이터만 가지고 처리하는 기계이기 때문이다. 이런 문제들을 처리하는 여러 방법의 하나인 규칙기반 전문가 시스템(Rule-based expert system)에 대해 얘기해 보겠다.

이처럼 컴퓨터가 처리해야 하는 문제들은 어떤 분야의 전문가가 처리하던 것을 컴퓨터가 대신하는데 의미가 있다. 나는 이것을 전문가의 지식을 처리한다고 정리한다. 그리고 전문가라고 불리는 사람들은 어떤 지식에 대해 규칙을 만들 수 있는 사람이고 규칙이란 앞서 얘기했던 대로 IF … Then … Else 형태로 표현할 수 있는 것을 말한다.

규칙기반 전문가 시스템은 관련주제에 지식이 풍부하고 관련 문제를 푸는데 능숙한 주제 전문가(domain expert), 전문가 시스템을 테스트하고 규칙을 추론할 수 있는 지식공학자(knowledge expert), 전문가 시스템의 개발 리더인 프로젝트 관리자(project manager), 프로그래머(programmer) 그리고 최종사용자(end-user)로 구성되어 있다.

또한, 규칙기반 전문가는 기반지식(knowledge base), 데이터베이스(Database), 추론 엔진(Interface engine), 해설설비(explain facilities), 사용자 인터페이스(User interface), 외부 인터페이스(External interface), 개발자 인터페이스(Developer interface), 디버깅 보조도구(Debugging aid)로 구성되어 있다.

규칙기반 전문가 시스템은 특정영역의 문제를 풀기 위한 심벌을 추론할 수 있는 능력을 갖추며 처리 과정과 지식이 분리돼 있다는 특징이 있다. 처리 과정과 지식이 분리되어 있다는 것은 매우 큰 장점이다. 이는 새로운 지식이 추가되었을 때 시스템을 수정하기 쉽게 만든다. 또 규칙기반 전문가 시스템은 해설설비가 있으므로 고전적인 방법과 달리 점화된 규칙을 추적할 수 있으면 이르는 방법을 설명할 수 있다. 간단히 설명해서 어떤 정렬 알고리즘(sort algorithm)은 그것이 어떤 절차를 통해서 정렬되는지 소스코드를 보기 전까지는 알 수 없다. 하지만, 전문가 시스템은 어떻게 결과에 이르렀는지 해설설비를 통해서 가능하다는 얘기이다. 또 불충분하고 완전하지 않은 데이터를 처리할 수 있는 대신 결과에는 항상 실수가 존재할 수 있다.

추론방법의 종류에는 순방향 연결과 역방향 연결이 있다. 순방향 연결을 data driven이라고 하는데 단순히 하나씩 지식을 점화시켜 나감으로써 결과를 찾는 방식이다. 자연스러운 방법이지만 속도가 느린 방법이다. 역방향 연결 방식은 goal driven 방식이라고 불리고 목표를 거꾸로 추론해 나가는 방식이다. 보통은 순방향 연결을 사용하고 그 결과를 검증할 때 역방향 연결을 사용한다.

시스템이 가진 규칙은 보통 겹치지 않게 설정해야 좋지만 불가피하게 상반된 같은 규칙이 공존하는 예도 생길 수 있다. 예를 들면 “더우면 에어컨을 켠다.”라는 규칙과 “더우면 에어컨을 끈다.”라는 규칙이 공존할 수 있다. 상식적으로 두 번째 규칙이 잘못된 것을 직감할 수 있겠지만, 컴퓨터는 이것을 알지 못한다. 이를 해결하기 위해서는 각 규칙에 대해 우선순위(priority)를 정하는 방식이 있다. 전문가가 제안한 규칙은 일반사람이 제안한 규칙보다 우선순위를 높게 측정해 같은 규칙이 충돌되었을 때 먼저 적용하는 식이다. 또 다른 충돌 해결 방법은 최장 일치 전략(longest matching strategy)이라는 방법도 있다. IF … 에 해당하는 규칙 중 더 많은 규칙을 적용하는 쪽을 더 높은 우선순위로 배정하는 방법이다. 결국, 이런 충돌을 잘 해결하기 위해서는 지식에 대한 지식인 메타지식(knowledge about knowledge)이 필요하다.

이처럼 지식기반 시스템은 자연스러운 지식을 표현할 수 있고 통일된 구조를 가지며 지식과 과정이 분리돼 있고 불확실한 지식을 다룰 수 있다는 장점이 있지만, 규칙과의 불분명한 관계를 해석할 수 없고 순방향 연결처럼 비효율적인 탐색전략을 갖는다는 것과 새로운 지식이 추가되었을 때 전문가(사람)의 도움 없이는 스스로 학습할 수 없다는 단점이 있다.

요즘 나는 모호하고 애매한 것을 어떻게 컴퓨터로 풀어나가는지에 대한 내용을 관심 있게 보고 있다. 아직 이것에 대한 지식이 부족해 깊게 얘기할 수는 없지만 결국 인간이 만들어낸 시스템으로 극히 일부 분야에 전문적인 능력을 나타내는 것이 지금 시대가 말하는 인공지능 시스템이라는 것이다. 결국, 터미네이터에서 나오는 skynet이나 인간의 사고를 하는 능력을 갖춘 로봇이 나오기까지는 아직 갈 길이 멀어 보인다. 하지만, 확실한 것은 이것은 하드웨어 분야에서 풀어야 할 숙제가 아니라 결국 소프트웨어 분야에서 풀어야 할 문제라는 것이다. 인간의 두뇌 기억과 사고에 대한 의학적 기술이 발전하고 그것을 소프트웨어로 효과적으로 옮길 수 있는 능력이 발전하는 언젠가 이것은 이루어지리라 생각한다.@

http://en.wikipedia.org/wiki/Expert_system

http://www.cs.nott.ac.uk/~sxp/ES3/index.htm
http://en.wikipedia.org/wiki/Terminator_3:_Rise_of_the_Machines

생체 정보에서의 보안 대책 필요

2010-08-08T08:02:00.000-07:00

정보사회에서는 디지털로 문서가 작성되고 온라인으로 파일(file)이 교환되면서 전자 거래가 증가 하고 있습니다. 특히 인터넷의 등장으로 누구나 쉽게 전자 거래가 가능하지만 오프라인과 똑같은 안전성과 신뢰성을 보장해 주지는 못하고 있고 전자 거래는 신원확인을 할 수 없고 해킹(hacking)의 위험으로 문서의 진위 여부를 판단할 수 없다는 위험이 있습니다. 이를 보완하기 위해 지금까지 많은 기술(VPN, Firewall, PIN: Personal Identification Number 등)이 개발되고 발전되고 있지만 아직 전자서명만큼의 보안성을 제공하지 못하고 있습니다. 전자서명은 신원확인, 위변조 금지, 기밀성 유지, 부인봉쇄 등에 보안환경을 제공하고 있고 전자거래의 법적 효력을 제공하고 있습니다.

전자서명 기술은 첨단정보기술로서 국가의 보안과 경쟁력에 큰 영향을 미치고 있습니다. 전자서명을 이용해 다뤄지는 데이터들이 그만큼 국가 안보에 영향을 미칠 정도의 중요한 것들일 수 있기 때문입니다. 특히 가까운 미래에 그 중요도가 더 높아질 스마트카드, 지문인식, 홍채인식, 얼굴 인식 등의 정보를 다루는 분야에서도 PKI 와의 기술 접목을 고려해서 연구가 진행되어야 한다고 생각합니다.

인간의 생체인식 기술의 경우 의학기술 발전과 더불어 타인의 생체를 이식할 경우 그에 대해 연구는 되고 있지만 실제 적용에 있어 대책이 부족한 실정입니다. 영화 ‘마이너리티 리포트‘를 보면 타인의 홍채를 이식 받아 보안기관의 출입 및 보안정보의 Access까지 가능한 것을 볼 수 있습니다. 비록 영화이지만 이런 대책이 충분히 간구되지 않을 때 아주 실현 불가능 한 얘기도 아닐 것이라 생각합니다.

현재 공개키 기반구조에서의 사용자 인증은 Knowledge Factor(사용자가 알고 있는 것으로 PIN이나 패스워드 등), Possession Factor(사용자가 소유하고 있는 것으로 토큰이나 카드 등), Biometrics Factor(사용자의 유일한 신체적 특징으로 얼굴, 지문, 홍채 등)의 세 가지 방법 중 한 가지 또는 그 이상의 방법을 이용하여 수행될 수 있습니다. Knowledge Factor와 Possession Factor를 사용하는 방법은 현재 가장 많이 쓰이고 있는 방법이지만, 이러한 방법의 단점은 망각 및 유출의 가능성이 있으며, 도난 및 분실에 의한 도용의 위험이 있다는 점입니다. 반면 사용자 인증을 위해 Biometrics factor를 사용하게 되면 소유물이나 현재는 도난, 분실, 위조의 가능성은 낮지만 가까운 미래에 이것들이 보안 위협이 될 수 있습니다.

따라서, 생체 정보와 전자서명이 결합된 정보에 대해 효과적 검증 데이터 생성 방법과 현재 CA들의 생체정보 검증에 대한 기능 확장 및 관련 어플리케이션 개발에 대한 추가 연구가 필요합니다. @

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

2009-09-20T08:54:00.000-07:00

최근 꿀단지(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)의 우주관

2009-09-20T08:51:00.000-07:00

'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)

2009-09-20T08:49:00.000-07:00

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

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

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

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

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

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

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

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

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

해커는 화가를 닮지마라

2009-09-20T08:46:00.000-07:00

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

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

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

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

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

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

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

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

의도를 파악하라

2009-09-20T08:43:00.000-07:00

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

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

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

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

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

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

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

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

Software의 Accessibility

2009-09-20T08:42:00.000-07:00

얼마 전 편의점에서 커피를 사먹었던 적이 있었는데 놀라운 것을 발견하였다. 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

'영화는 영화다'를 보고

2009-09-20T08:39:00.000-07:00

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

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

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

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

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

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

2009-09-20T08:37:00.000-07:00

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

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

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

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

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

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

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

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

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

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

2009-09-20T08:35:00.000-07:00

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

2009-09-20T08:32:00.000-07:00

오늘 소공동 롯데 호텔에서 열리는 '성공적인 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)와 웹 제국

2009-09-20T08:31:00.000-07:00

이제 구글도 웹 브라우저(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) 위치에서도 구글이 갖는 웹 기반 소프트웨어에 대한 야심을 느낄 수 있었다. 구글이 완전히 이빨을 다 들어냈을 때 구글 브라우저 위에서 구동되는 구글의 웹 기반 소프트웨어들이 어떤 모습이 될지 기대되는 바이다. 또한 구글은 한발 짝식 구글 제국(?)을 건설하기 위해 도전적으로 전진하는 모습이 부럽다. 우리나라에도 이와 같이 좀더 원대한 목표를 갖고 전진하는 소프트웨어 개발사들이 많아졌으면 하는 바램이다.@

소프트웨어의 요구사항

2009-09-20T08:29:00.000-07:00

소프트웨어 개발자(software developer)로써 일을 하다 보면 기획자와 많은 시간을 보내게 된다. 여기서 기획자란 말은 소프트웨어의 요구사항을 만들어내는 사람이라고 봐도 좋겠다. 혹은 드물겠지만 기획자라고 부를 만한 사람이 없다면 소프트웨어를 사용하는 사용자를 떠올리기 바란다.

요구사항을 만들어내는 사람들은 개발자를 곤혹스럽게 하곤 한다. 그것은 근본적으로 개발자가 하고 싶지 않은 일을 시키기 때문이라고 생각한다. 개발자는 성능을 중시하고 코드가 얼마나 간결한지를 중시하곤 하는데 복잡한 요구사항들은 이런 코드를 지저분하고 복잡하고 느린 모습으로 바꾸곤 하기 때문이다. 하지만 자신의 소프트웨어가 살아 있는 한, 자신의 소프트웨어를 사용해주는 사용자가 있는 한, 요구사항이 있는 한 이러한 일은 끊이지 않을 것이다.

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

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

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

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

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

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

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

프로그래머의 break time

2009-09-20T08:26:00.000-07:00

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

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

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

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

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

이미지: Stress Qoutes, http://1927cafe.wordpress.com/2007/09/26/stress-qoutes/

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

2009-09-20T08:25:00.000-07:00

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

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

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

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

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

2009-09-20T08:24:00.000-07:00

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

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

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

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

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

[사진] 어거스타 에이다 킹, 러브레이스 백작부인(Augusta Ada King, Countess of Lovelace) : 최초의 프로그래머

포르토벨로의 마녀

2009-09-20T08:21:00.000-07:00

한 일주일 간의 출퇴근 시간에 읽고 또 읽어 드디어 다 읽었다. 마지막에는 빨리 결말을 보고 싶어서 한번에 몰아서 읽긴 했지만 대부분 출근시간을 할애 해서 읽었다. 코엘료의 책을 처음 읽어본 나로써는 코엘료와 뭔가 코드가 딱 맞아 떨어지는 것 같은 느낌을 받지는 못했지만 그래도 왠지 모르게 이 책에 몰입하게 되는 느낌을 받았다. 이 책을 다 읽고 코엘료의 다른 책들도 읽어보고 싶은 느낌을 받았다.

읽는 사람에 따라 여러 가지 생각을 가질 수 있을 만한 책인 것 같다. 어떤 이는 이 책을 통해서 현 시대를 살아가는 진취적이고 도전적인 여성의 모습을 느낄 것이고, 또 어떤 이는 인간의 영혼의 이야기라고 느낄지도 모른다. 하지만 이 책을 읽고 내가 느낀 것은 코엘료가 이 책을 통해 아테나를 통해 사랑 받는 여자를 그리고 그 사랑에 대해 얘기하고 싶었던 거라 생각한다. 아테나가 겪게 되는 수많은 일들과 그녀가 느꼈던 모든 것들은 바로 사랑이 있었기에 가능한 것이 아니었을까?@

비즈하드 소개 대본

2009-09-20T08:19:00.000-07:00

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

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

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

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

하지만 이런 식의 동작은 전체적인 네트워크 트래픽에는 여유가 있음에도 불구하고 해당 스토리지에 트래픽이 몰려 다운받지 못하는 경우가 생겨나게 됩니다. 이 경우 정상적인 서비스를 위해 지속적으로 모니터링을 해야 하기 때문에 비용적인 측면이나 파일 서버의 관리 측면에도 비효율적이고 서비스 또한 안정적이지 못하게 됩니다.

비즈하드의 적용된 파일 관리 방법에는 기존의 비효율적이고 안정적이지 못한 방법을 해결하고 있는데, 파일 업로드 시에는 대역폭의 여유가 있는 스토리지에 파일을 분산하여 저장하므로 써 파일 송수신 속도를 가장 빠르게 낼 수 있도록 합니다.

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

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

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

관리의 효율성을 높이기 위해서 업로드 및 다운로드 시 트래픽과 서버의 상태를 체크를 하지만 그래도 한쪽 서버에 몰리는 현상이 발생 될 수 있는데 이런 경우 자동으로 해당서버의 파일들을 다른 서버와 적절하게 재배치 하는 부하를 분산하는 기능을 갖고 있습니다.

이와 같은 비즈하드의 기능과 비즈하드의 핵심 기능인 ‘웹 스토리지의 분산 파일 관리 시스템 및 파일 관리 방법’으로 데이터의 저장, 공유, 활용 및 보안, 관리 효율성의 향상이 예상되고 있습니다.

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

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

HTML5

2009-09-20T08:17:00.000-07:00

W3C에서 HTML5가 표준화 작업을 진행 중에 있다. 첫 번째 Working Draft는 올 8월을 목표로 작업하고 있다고 하고 늦어도 2010년 하반기에 표준 권고안이 만들어질 예정이라고 한다. 예전에 이렇게 표준화 작업이 진행되면 그 진행속도와 실제 웹 브라우저에 적용되는 속도는 너무 느려 이번 표준화 작업을 상당히 부정적으로 바라보는 시각이 많으리라고 생각한다. 하지만, 이미 Firefox2.0과 Opera9.0에 이미 일부 기능이 탑재돼 있고 Firefox3.0에는 많은 기능이 추가로 탑재될 예정이라고 한다. 또한 HTML5의 워킹 그룹 의장을 IE7이후 개발을 총 책임지고 있는 크리스 윌슨(Chris Wilson)이 맞고 있기 때문에 IE8에서 HTML5의 기능들을 바라보는 시각은 긍정적이다.

「HTML 5」를 주목해야 하는 이유

HTML4와 HTML5의 차이점을 보자면 아래 링크를 참고하여 확인할 수 있다. 아직 HTML5가 초안상태라 모든 기능이 작성되었다고 말할 순 없다.

HTML4와 HTML5의 차이점

개인적으로 가장 눈에 띄는 속성은 DOCTYPE에 대한 부분이다. 보통 아무 생각 없이 DOCTYPE을 쓰지 않는 웹 페이지를 자주 볼 수 있었는데 앞으로는 이 부분에 대한 중요도가 높아져 어떻게 설정하느냐에 따라 같은 HTML 태그라도 웹 페이지가 다르게도 보여질 수 도 있을 것이다. 또한, 우리가 많이 쓰는 input 태그에도 datetime이나 email, url 이런 속성들도 추가될 것이라고 한다.

<input type="email" />
<input type="url" />
아마 위와 같이 쓰게 될 것이라고 생각된다. 지금까지는 email이나 url등의 입력을 받을 때 정규식이나 기타 여러 가지 방법을 동원하여 validation check를 수행했었는데, 이런 불필요한 반복적이고 소모적인 작업들이 좀 더 간편해 질 것 같다. 또… 어떤 모습으로 브라우저가 지원해줄지도 기대되는 부분이다.

2차원 그래픽 API에 사용할 수 있는 canvas 요소
추가 API로 위 요소도 지원한다고 한다. canvas는 전에 VRML에서 많이 보던 요소인 것 같은데 HTML5에 VRML 스팩이 포함되지는 않겠지만 이와 같은 2차원 그래픽 API의 공식적인 지원도 함께 기대해본다.@