요즘 화제인 모기기와 모사에 대해

뭐가 안되고 또 뭐가 안되고로 까는 걸 많이 봤는데,

어떤 제품을 기획 및 개발하면서 어떤 기능을 빼내는 것은 어떤 기능을 추가하는 것보다 훨씬 어렵다.
오죽하면 Feature Creep이라는 말까지 있을까?

하지만 Feature Creep에 휘말리면 제품은 산으로 가버린다.

생떽쥐뻬리가 하고 에릭 레이먼드가 인용한 경구 "설계에 있어 완벽함이란 더 이상 추가할 것이 없을 때가 아니라 더 이상 뺄 것이 없을 때 이루어진다"가 있다.  그리고 레이먼드는 "하나의 목적에 완벽한 도구는 전혀 다른 목적의 일에도 유용히 쓸 수 있다"는 말도 했다. 

모사의 기기들에 대해 없는 것을 이유로 까는 걸 보면 그래서 한심하다는 생각마저 들 때가 있다.

PS. 그게 과연 맞는지라면 몰라도
PS'. 개발자의 본분은 키배가 아닌데, 아침 일찍 이게 뭔 짓인지.

by Corund | 2010/02/04 07:19 | 트랙백 | 덧글(1)

애플까에 대하여.


위 글은 '나는 애플이 싫다'라는 게 주 메시지인 것 같다. 그건 뭐 인정해 줄 수 있는 메시지인데, 문제인 것은 그 근거로 든 것들이 맞지 않는 말들이라는 거다.

아이튠즈가 윈도우에서 얼마나 지랄같은지 나는 모르겠다. 그리고 아이튠즈를 대신할 수 있는 대안이 있는지 없는지 나는 모르겠다. 그러니 여기에 관해서는 내가 할 말이 없다. 그렇지만 개발자의 입장을 이야기하는 곳을 보면 도저히 동의하지 못하겠다.

아이폰 개발 도구로 애플이 지원하는 프로그램이 OSX에서만 돌아가는 게 그렇게 욕먹을 일인가? Xcode for Windows가 나온다면야 박수를 치면 되는 일이고 안 된다면 "윈도우까지 지원하기엔 역량이 모자라나 봐? 쯧쯧" 하던가 "거참 윈도우 지원없이도 성공이 가능하다 생각하는 배짱 한번 대단하군"하면 될 일이다. 반대로 Visual Studio for Linux나 Visual Studio for OSX이 있는 것도 아니지 않는가? 아이폰 개발이 유행이어서 자연히 시장 논리대로 서드 파티 개발사들이 윈도우 기반 개발 도구를 만드는 걸 애플이 또 막는다면 모를까?

정 아이폰 앱을 개발하고 싶으면 맥을 사면 될 일이다. 요즘이야 오픈 소스 영향으로 개발툴 무료로 배포하는 것도 많지만 엄연히 상용 개발툴도 많다. 상용 개발툴 사는 거와 뭐가 다른가? 소프트웨어 사는 거나 하드웨어 사는 거나. 소프트웨어는 상용이라도 무료로 구할 수 있는 길이 있지만 하드웨어는 그렇지 못해서? 

OSX을 일반 PC에다 설치하지 못한다고 까는 것은 정말 까기 위해 까는 거로밖에 보이지 않는다. 원래 하드웨어와 소프트웨어 일체로 만들던 회사 아닌가? 정책이 바뀌어 X86 기반으로 바뀌어 PC와 비슷해졌지만 원래 바탕이 다른 건데(PC용이 나오면 나야 좋겠지만). 지금에야 PC + Windows 조합으로 개인용 컴퓨터 시장이 평정되어 맥의 경우가 특이해 보이지만 예전엔 하드웨어 OS 일체로 되어 있던 경우도 많이 있었다. 그러면 Solaris, AIX, IRIX 등등도 다 PC에 설치되어야 하게?(Solaris는 되는구나 ㅡ.ㅡ;)

맥이 개발자의 개발 도구 선택에 제한을 주는가? 글쎄, 나는 윈도우나 닷넷 개발을 안 해봐서 그쪽은 모르겠다. 그렇지만 윈도우 외의 또 다른 영역에서 맥은 아주 좋은 개발용 머신이다(나도 그것 때문에 맥북을 샀다). Common LISP이나 Perl 개발 환경을 윈도우에서 꾸미려면? 안되지는 않지만 지랄 같은 경우가 있다. 맥에서는? 별다른 삽질이 필요없다. asdf-install, cpan 모두 그냥 작동된다. ruby는? java는? 그리고 수많은 오픈 소스 개발 도구들은? 윈도우에선 cygwin이라는 번거로운 기반 위에서 돌려야 하는 것들이 모두 그냥 된다.  그건 오픈 소스의 힘이지 애플의 힘은 아니지 않냐고? 글쎄, 나는 맥을 쓰게 되면 사과마크 목줄이 걸린다는 거에 대해 아니라고 말하는 거다. 오픈 소스의 힘이 먹히는 곳 아닌가? 그런 식으로 말한다면 이쪽에서 보자면 그쪽이야말로 MS의 목줄이 걸린 거로 밖에 보이지 않는다(이 말을 한다고 윈도우 계열 프로그래머를 비하하는 건 아니다. 어디까지나 비유하자면이다).

위 글은 매우 논쟁적인 글이라 나도 어째 떡밥을 물고 파닥이는 느낌이지만, 다르게 생각하는 개발자도 있다는 걸 알아줬으면 해서 글을 적어본다(퇴근하지 않고 이 늦게까지 뭔 일이야 ㅡ.ㅡ;).

by Corund | 2010/02/01 20:48 | 트랙백 | 덧글(2)

Mac으로 스위칭하고 나니

소프트웨어도 윈도우즈보다 많이 사게 된다. 

윈도우즈에서는 사고 싶게 만드는 상용 프로그램이 별로 없어서 대충 비슷한 기능의 공개 프로그램으로도 버텼다. 하지만 맥에서는 예쁘고 감각있는 - 값도 그다지 비싸지 않은 - 상용 소프트웨어들이 많아서 자꾸만 지름 충동을 불러 일으킨다.

애플 제품은 사용하는 데 즐겁다. 그런데 돈이 많이 든다.

by Corund | 2010/01/22 02:48 | 트랙백 | 덧글(0)

Optimistic이냐 Pessimistic이냐?

동시성 제어(Concurrency Control) 관련하여 Optimistic/Pessimistic이란 용어가 있다. 낙관적/비관적이라고 번역하기도 한다. 자세한 설명은 Wikipedia에서

이야기하고자 하는 건 알고리즘 등이 아니고.

이슈가 되는 몇가지 인터넷 관련 정책 - 인터넷 뱅킹, 본인 확인제, 전자상거래, DDoS 관련 보안, 스마트폰 보안 - 들을 보면 우리나라의 정책들은 Pessimistic 쪽에 많이 치우쳤다는 생각이 든다.

Pessimistic 알고리즘이 구현도 편하고 확실히 처리되는 면이 있다. 그래서 Naive하게 구현하긴 쉽지만 성능상 문제도 있고 심각한 부작용이 있을 수도 있다. 상황을 자세히 분석해야 하긴 하지만 보통은 성능면에서도 우선 Optimistic 알고리즘을 고려해보는 게 나은 걸로 알고 있다.

그렇지만 우리나라 정책들은 왜들 일단 막고 보는 스타일의 Pessimistic 알고리즘에 강하게 치우쳐 있을까? 충돌(Conflict)이 자주 발생하지 않은 경우에는 대다수의 일반 프로세스 처리에 오버헤드가 있고 확장성에 문제도 있는데?

한국인들은 영악하기 때문에 일단 막고 보는 게 필요한 걸까? 아니면 무지하거나 게을러서 그것밖에 생각하지 못하는 걸까? 성향이 그래서 그냥 그걸 더 선호하는 것일까?

by Corund | 2010/01/06 12:14 | 트랙백 | 덧글(1)

CAP Theorem을 보며

고확장성(High Scalable) 분산 데이터베이스 시스템과 관련하여 꼭 등장하는 얘기가 Brewer's CAP Theorem이다.  CAP이란 분산 시스템이 갖추면 좋을 세 가지 특성 즉 Consistency, Availability, Partition Tolerance를 말하며 Brewer's CAP Theorem이란 이 세 가지 특성을 모두 갖춘 시스템은 불가능하며 최대 두 가지 특성만이 가능하다는 얘기다.

요즘 고확장성을 추구하는 분산 시스템이 계속 등장하고 있는데 Partition Tolerance는 기본적으로 만족하는 가운데 Availability에 촛점을 두어 Consistency는 완화된 형태로 추구하는 시스템이 많다. 이 때 등장하는 개념이 Eventual Consistency로 시간이 지남에 따라 결국 데이터가 Consistency를 만족하게 된다는 거다. 그래서 이런 시스템들은 전통적인 RDBMS의 ACID가 아닌 BASE(Basicall Available, Soft state, Eventually Consistent) 특성을 추구한다.

데이터베이스 시스템의 목적이 데이터를 ACID 특성에 따라 관리하는 거로 알고 있었는데 꽤나 쇼킹한 얘기였다. 이건 시스템의 가용성(Availability)를 위해 일시적인 데이터 Inconsistency를 감수한다는 거다. 그런데 여기서 중요한 거는 데이터에 따라 그래도 되는 데이터가 있다는 거고 그런 데이터 종류가 아주 많다는 거다. 유연하며 실용적인 생각이란 건 이런 게 아닐까.

Availability나 Consistency는 알겠는데 Partition Tolerance는 여전히 잘 이해가 안 되는 개념이었다. 이걸 완화된 형태로 추구할 수도 있지 않을까 어렴풋이 생각도 해봤는데 뭔지 잘 모르겠으니 손가락만 빨 노릇이었다. Terrastore라는 시스템이 이런 생각을 실천에 옮기는 듯 하다. "Provides advanced scalability and elasticity features without sacrificing consistency"라니 뭔가 했는데 Partition Tolerance를 다른 방법으로 해결해서 Consistency 특성을 추구할 수 있었다는 설명이 있다. 얼핏 이해하기론 여러 데이터센터에 걸쳐 시스템을 구축할 규모가 아니라면 Partition Tolerance에 큰 비중을 두지 않아도 되지 않나는 생각이 들었다.

CAP Theorem 자체는 별로 재미있지 않은 건데 이에 대처하는 시도들은 대담하면서도 실용이며 재미있는 것들이 많다. 이 분야는 앞으로도 계속 재미있는 시도들이 많을 것 같다.

by Corund | 2010/01/05 12:01 | 트랙백 | 덧글(0)

◀ 이전 페이지다음 페이지 ▶