천 리 길도 한 걸음부터 RSS FEED

facebook용 어플을 개발하느라 계속 facebook과 놀고 있는데 하루가 보통 다음처럼 진행된다.

1. 문서대로 작동하지 않는 기능 발견
2. 포럼 검색
3. 버그 트랙커에 이미 이 버그가 등록되어 있음을 찾아냄
4. 제발 버그 좀 고쳐주세요에 vote
5. 정신 차리고 다른 기능을 손보다가 다시 1번으로

젠장...

AWS를 사용하면서 더 편하게 소스코드(PHP)를 만지기 위한 삽질을 기록(참고로 난 10년간 윈도우 프로그래밍만 했다).

첫번째 방법이 이전 글에서 시도했던 PuTTY 터미널로 접속해서 vi로 직접 편집. 기본적인 vi 단축키를 외우고 시작했지만 이건 내 방식이 아니야라는 생각에 다른 방법을 찾기 시작.

두번째 방법이 UltraEditor의 via ftp 옵션을 통해서 편집하는 방법. UltraEditor가 PHP syntax highlight 기능을 지원해 소스 코드 작성에는 불편함이 없었지만 평가판이라 등록의 압박이 있었던데다가 디렉터리 탐색이 은근 불편했다.

그래서 무작정 eclipse를 설치. Help -> Install New Software... 아래 그림처럼 Work with:를 galileo로 바꾸고

Remote System Explorer를 선택해서 설치한다.

설치 후 Window -> Show view -> Other...에서 Remote Systems의 Remote Systems를 선택하면 윈도우가 하나 열린다. 여기 오른쪽 마우스 클릭 후 New connection을 선택해서 Remote System의 정보를 입력하면 된다.


여기서부터가 삽질. AWS는 SSH 접속이 private key로만 가능한데 키를 지정할 수가 없다. 이거 안되는건가 하다가 엉뚱한데서 메뉴를 찾았다. Window -> Preferences에 보면 키를 선택할 수 있다. Remote Systems와는 아무런 관계도 없어보이는 이런데다가 숨겨 두다니ㅠㅠ

Private key를 SSH2 home 디렉터리에 복사한 후 Add Private Key.



Remote Systems 창에서 접속을 하면 이렇게 목록이 보인다.

윈도에서 SSH 터미널 접속에 PuTTY를 많이 사용하는데, PuTTY의 보안키와 AWS에서 사용하는 키가 호환이 안된다. 그래서 변환이 필요하다. PuTTY 다운로드 페이지에 가보면 PuTTY Key Generator(PuTTYgen)를 다운로드 할 수 있다.

필요한건 변환이니까 Conversions 되겠다. Conversions -> import -> Save private key를 통해서 PuTTY에서 쓰는 *.ppk형태의 개인키를 얻을 수 있다(passphrase 경고가 나오는데 무시해도 된다).

실제 접속은 아래 그림의 메뉴에서 개인키를 지정하고 그냥 접속하면 된다.

자기 계발 혹은 팀 관리에 관한 책을 보면 크고 중요한 일을 먼저하라고 한다. 틀린 소리도 아니고 대부분의 경우에 맞는 것도 사실인데 항상 옳지는 않다. 그래서 사는게 재밌기도 하고.

대부분의 사람은 크고 중요한 일에 집착해 소소한 일들을 무시하는 경향이 있다. 출처가 생각나지 않는데 사람의 걱정은 일어나지 않을 일에 대한 것이 대부분이고, 그 나머지는 자기 힘으로 해결할 수 없는 일이라고 한다. 실제로 자기가 할 수 있는 일은 얼마되지 않는 일인데 크고 중요한(?) 일을 걱정하느라 자기가 할 수 있는 일도 안하게 된다.

크고 중요한 일이 있다고 해도 내 지침은 항상 "지금 할 수 있는 일을 해라." 한 가지다. 아무리 중요한 일이 닥쳤다고 해도 지금 할 수 있는 일이 없다면 - 걱정이나 관심을 갖는건 할 수 있는 일이 아니다 - 관심 끄고 소소한 일을 하는게 맞다는 것이다.

아무리 큰 일이 닥쳤다고해도 결국 폭풍은 사라지고 다시 일상으로 돌아가게 되는데 이때 폭풍에 휘말려 날아가버린 시간이 돌아오는 것은 아니다. 대부분의 경우에 진짜 심각한 일은 폭풍이 가라앉은 다음에 모자란 시간을 채우면서 발생한다. 물리적인 시간을 보충하는 일은 내가 겪어본 일중에 가장 힘들고 큰 일이었다.

주변에 아랑곳하지 않고 소소한 일을 계속 해 나가는 일이 결코 쉽지는 않다. 그러나 정신차리고 하나씩 소소한 일을 해결해 나가다보면 어느새 큰 일도 해결되어 있는 것을 발견할 수 있다. 길지 않은 삶을 살았지만 이게 내가 발견한 인생의 진리다.

P.S.
마음을 가다듬고 정신차리기 위해서 뜬금없는 글을 써봤다.

며칠전 iPAD 출시로 온갖 미디어에서 혁신만 있다면 당장 놀라운 일이 벌어질 것처럼 떠들고 우리에게는 혁신이 없다고 스스로 난리치고, FT는 혁신적이지 않아서 삼성전자의 장기적 전망이 부정적이라는 헛소리까지 하고 있다(삼성전자가 영국보다는 혁신적이며 장기적으로도 긍정적이지 싶다). 혁신이 중요하지만 혁신만으로 세상이 변하진 않는다.

내가 볼 때, 우리에게 진정으로 부족한 것은 혁신이 아니라 상생 혹은 동업자 정신이다. 애플에게 이 상생과 친구들이 없었다면 지금처럼 세상을 바꾸지는 못했을 것이다.

물론 혁신도 중요하다. 구글 검색엔진은 혁신이라는 표현에 딱 맞는 예중 하나다. 그래서 부와 명예를 거머 줘었다. (이견이 있을지도 모르겠지만) 그러나, 세상을 바꾸진 못했다. 구글이전에도 사람들은 검색을 했고 구글 이후에도 아마 계속 검색을 하게 될 것이다. 단지 사람들의 시간을 아껴주고 있을 뿐이다(이것도 물론 매우 중요하다).

그에 반해 음악 듣는 방식자체를 바꾼 애플은 제품 자체도 혁신적이었지만, 상생(혹은 동업자 정신 이도 아니면 아무거나)으로 세상을 바꿨다고 할 수 있다. CD 판매량이 지속적으로 감소하고 있었던 대형 음반 업체들에게 애플이 제시한 곡당 가격은 상당히 매력적이었고, 애플이 떼어가는 마진도 합리적 수준이다. 그렇게 애플과 친구들이 음악을 소비하는 방법을 바꿨다.

혁신이 세상을 바꾸려면 세상이 그 혁신을 받아 들일 준비가 되어 있어야한다. 세상이 깜짝 놀랄만한 무엇인가를 만든다면 초대박으로 성공하리라 생각하겠지만 실제는 그렇지 않다. 그냥 비운의 제품이 될 뿐이다.

한마디로 지원 사격을 해 줄 친구들이 옆에 자리하고 있어야한다는 말이다. 얼마전에 구글이 넥서스1을 발매했는데 결과는 대실패로 수렴하고 있다(에 사실 넥서스1은 혁신적이도 않다). 한참 주가를 올리고 있는 안드로이드 탑재, 잘나가는 스마트폰 제조 업체인 HTC가 제조하고 안드로이드의 창조자인 구글이 직접 디자인한 결과 치고는 처참하다.

실패에는 여러 이유가 있겠지만 내가 보는 가장 큰 실패의 원인은 옆에서 북치고 장구치면서 응원해 줄 친구들이 없었다는 점이다. 최소한 carrier중 하나는 응원군으로 포섭해야했지만, 구글은 오만한 모습을 보였고 그 결과가 지금의 판매량이다. 모토로라를 통해서 벌써 넥서스1의 다음 세대를 만들고 있다는데 이번에도 똑같이 독불장군이 된다면 또 실패한다에 500원 건다.

위에서도 얘기했듯이 우리 나라의 비극은 혁신이 없다는게 아니라 상생 혹은 동업자 정신이 없다는 점이다. 뒷일 보다는 일단 이기는게 중요하고 을은 무조건 달달 복아야 제맛이라는 생각이 머리 속에 꼭 박혀있는게 문제다. 수많은 갑-을의 관계나 대기업-중소기업의 관계를 봐도 그렇다.

물론 이 방법으로도 계속 승승장구할테고 꾸준히 이익을 낼 것이다. 그러나 난 대기업 하청업체로 시작해 세계적인 기업 된 후 대기업이 없었다면 이 자리에 설 수 없었을 것이라는 기사를 보고 싶다. 그때가 우리가 진정한 선진국의 문턱을 넘어 서고 혁신에 대한 집착이 사라질 것이라고 생각한다.

한국 MS 온라인 스토어에서 ESD 판매 - 다운로드 판매 방식 - 를 정식으로 시작했다. 패키지 없이 판매하면 얼마나 싼가 궁금해서 돌아 보는데 왼쪽과 같다.

만우절도 아니고, 이걸 어떻게 해석해야할지 참...

며칠 전 가트너에서 2012년에 안드로이드 폰이 아이폰을 꺽고 2위 스마트폰 플랫폼이 될거라 예측했다. 요즘처럼 개나소나 다 안드로이드 폰 출시에 열을 올리는 걸 보면 틀린 말은 아닐 듯. 그러나, 휴대폰 제조업체들이 이런 말도 안되는 안드로이드 러시를 감행하는 이유를 도저히 모르겠다. 결국 자기 손핸데 말이다. 내가 왜 이렇게 생각하는지 같이 한 번 알아보자.

지금이야 애플하면 아이팟과 아이폰이 먼저 떠오르지만 사실 애플은 컴퓨터 제조업체다. 선도 업체로 피씨 시장을 개척하고 열었다고해도 과언이 아닌 위대한 회사였다. 녹색 커서가 점멸하던 Apple II가 컴퓨터라는 말과 동의어에 가까웠던 시절이 있었으니까. 이런 애플의 독주를 막아선 곳이 IBM이였다. 당시 IBM은 빠른 시장 진입을 위해서 다양한 H/W를 직접 만들지 않고 상호 운용을 도울 표준(ISA, Industry Standard Architecture)을 공개해 다양한 업체가 시장에 뛰어 들도록 만든다. 물론 S/W도 직접 만들지 않고 라이센싱을 선택해서 세계 최대의 SW업체가 탄생하도록 도와(?)준다.

중간과정을 다 건너뛰고 결과만 보면 IBM은 그들의 열망처럼 Personal Computer 시장을 휩쓴다. 단 주인공은 IBM이 아닌 Microsoft와 IBM 호환 컴퓨터 생산업체들이었다. IBM이 뛰어난 제품을 만든 건 분명하지만 호환 업체들은 더 싸고 좋은 제품을 만들어 시장을 잠식했고 그 과정에서 MS는 절대적인 영역을 구축한다(왜냐하면 누가 만들든 MS DOS를 사용했으니까). 더 뒷 얘기를 하면 IBM 호환 업체들은 계속해서 더 싸고 더 싸고 또 싼 제품을 만들어 내다가 결국에는 이익도 안남는 금액으로 제품을 만들고 원가를 줄이기 위해서 중국으로 공장을 옮기고 유통과 재고를 줄이는 혁신을 통해서 또 가격을 줄이고... (너무나 처참해서 생략)

원래 얘기로 돌아가도 애플은 선도 업체로 또 등장한다(아 진짜 위대한 회사다). 통신 시장의 헤게모니 주인은 망 사업자였는데,  아이팟의 인기를 등에 엎은 애플은 아이폰+앱스토어로 이 역학 구조를 뒤집는다. 그러니까 스마트폰 시장이라는 한정된 영역이기는 하지만 망 사업자를 그림자로 만들어 버렸다. 애플이 주인공이고 망 사업자와 앱스토어의 수많은 개발자들은 모조리 들러리다.

여기에 MS를 꿈꾸는 구글이 등장해 안드로이드라는 플랫폼을 만들어 낸다. 그러니까 ISA를 만들어 냈다. 여기서 웃기는 건 구글이 안드로이드를 만들었지만 정작 자기들은 이 플랫폼으로 제품을 만들지 않는다. 그래서 IBM과 다르고 MS에 가깝다. IBM 호환 제품을 만들던 업체 역할을 해줄 전세계에 산재한 수많은 호구들이 경쟁적으로 제품을 생산하고 있다. 구글로서는 손안대고 코푸는 격인데 여기에 동참해 IBM 호환 제품을 생산하던 업체의 역할을 기꺼이 수행하고 있는 제조업체들을 이해 할 수가 없다.

구글이야 안드로이드 폰을 누가 만들든 상관없다. 어차피 그 폰을 산 사람들은 구글을 이용해서 시장이 점점이 더 커질테니 말이다. 그러나 제조업체는 다르다. 결국 안드로이드 플랫폼으로 만들어진 폰은 제조업체의 특별함이 점점 사라지게 될테고 호환 제품의 하나로 전락할 가능성이 크다.  이런 상황이 되면 사용자들에게 유리한 시장buyer's market이 되겠지만 제조업체들은 죽을 맛일 것다.

내가 보기엔 지금 딱 이 시나리오로 흘러가고 있다. 그리고 이런 시장이 된다면 최후의 승자는 당연히 구글과 가장 저렴하면서 쓸만한 제품을 만들게 될 중국업체가 될 것이다. 근데 이런 시나리오는 제조업체 입장에서 보면 아주 안좋은 상황이라서 여기까지 가도록 방관할 회사는 없을 거다. 내가 안드로이드의 미래를 핑크빛으로 보지 않는 이유이기도 하다.

ps. 대충 일단 마무리. 나중에 시간이 되면 글을 다듬던지 해야지...

신입 직원에게 프로그램 교육을 위해서 과제를 내줬는데, 프로그램이 이해 불가능한 성능을 보여서 같이 원인을 찾아봤다. 프로그램이 죽도록 느린 이유는 다름아닌 rand_s().

내 경우 난수 생성을 할 때 보통은 stdlib의 rand()를 쓰고, 프로젝트에서는 메르센-트위스터를 사용한다. rand()는 정말 빠르고, 메르센-트위스터도 속도로 인해 나를 고민하게 만든 적은 없다. 물론 둘은 안전하지 않다고 알려져 있다. 그러니까 성깔 있는 놈한테 걸리면 다음 난수를 예측당할 수도 있는 것이다. 그러나 MMO 서버의 특성상 동시 다발적으로 나 외의 수 많은 사람들에 의해서 (심지어 NPC도) 난수가 생성되기 때문에 사실상 안전하다고 봐도 된다(온라인 포커 게임이나 릴게임 같은 경우에는 실제로 분석해서 맞추는 성깔 있는 놈들이 진짜 있다).

MSDN에 의하면 rand_s()는 cryptographically secure random numbers를 생성한다고 한다. 물론 그를 위해서 막대한 대가를 치를테고 말이다. rand_s()의 득과 실을 파악하고 상황에 맞게 사용하자. 닭 잡는데 소잡는 칼은 필요 없으니 말이다.

신입 직원에게 내준 프로그램은 보안따위는 전혀 신경 쓸 일이 없었다.

모든 경우에 다 통하는 진리는 당연히 아니지만 그동안의 경험을 볼때 중요한 항목들은 다음과 같다.

1. 전역 변수 사용(접근)을 자제하라.

내가 꼽은 성능 저하의 일등 공신은 바로 전역 변수다. 여기서 전역은 문법적인게 아니라 다른 쓰레드에서도 사용할 수 있는 범위를 가진 변수를 말한다. 이 녀석들은 동기화 문제도 있지만 캐쉬에도 큰 영향을 미친다. 아래의 코드는 counter라는 변수의 위치만 다를 뿐이지만 실제로 돌려보면 상상도 못할 큰 차이가 난다(성능을 위해 동기화를 하지 않아도 차이가 많이 난다. 동기화하려고 Interlocked...등을 사용하면 성능차이는 더 크게 벌어진다).
// 1 unsigned counter; unsigned __stdcall Thread(void* param) { for (int i = 0; i < 100000; ++i) { for (int i = 0; i < 30000; ++i) ++counter; } return 0; } // 2 unsigned __stdcall Thread(void* param) { unsigned counter = 0; for (int i = 0; i < 100000; ++i) { for (int i = 0; i < 30000; ++i) ++counter; } return 0; }
(릴리스 모드에서는 for 루프를 한번에 결과 값으로 바꾸기 때문에, 최적화를 하지 않아야 제대로 된 결과를 얻을 수 있다. 간단한 예제로 컴파일러의 최적화를 피해가는건 어려운 일이다. #pragma optimize 문을 사용하는 것이 가장 확실한 차이를 알 수 있다.)

프로그램이 저렇게 덧셈만 있는 경우는 없겠지만 이런 경우라면 로컬(자동) 변수를 이용해서 쓰레드 합을 구하고 나중에 합산하는게 효율적이다.

2. 쓰레드 개수보다는 코드 길이가 더 큰 영향을 미친다.

쓰레드 개수에 목숨거는 사람들이 있는데, 쓰레드가 한 두개 더 있어서 생기는 오버헤드는 없다고 봐도 무방하다. 그러니까 10개를 8개로 줄이는 건 큰 차이가 없다는 뜻이다(물론 100개랑 8개는 적지 않은 차이가 있다). 그보다는 코드가 적당한 길이를 유지하는게 더 중요하다.

윈도우 서버의 타임 슬라이스(aka Quantum)는 상당히 긴 시간이고 이를 충분히 활용해야만 한다. 주어진 quantum을 다 사용하지도 못하고 쓰레드 실행 코드가 종료되면 OS는 스케쥴링을 다시하고 문맥 전환(context switching)을 일으키게 된다. 이런 일이 빈번하면 좋을게 없으니 몇 줄짜리 쓰레드를 생성했다면, 이걸 다른데 통합할 방법이 없을까 고민해야 한다(이런 과정을 거치다보면 자연스럽게 쓰레드 개수가 줄게된다).

예전에는 IOCP worker thread에서 packet을 받으면 저장만하고 바로 GQCS() 상태로 들어갔는데, 최근 작업에서는 그 안에서 별별걸 다 하고 있다. 블럭만 안된다면 워커 쓰레드 안에서 가능한 많은 일을 처리하도록 만드는게 훨씬 더 효율적이다.

3. 락프리 기법은 만능이 아니다.

보통 락프리 기법이라고 말하면 커널 객체를 사용하지 않고 유저 모드에서 동기화하는 방법인데, 이는 만능이 아니다. CS같은 커널 객체에 비하면 가볍지만 아쉽게도 모든 문제를 해결할 순 없다. 잔머리를 잘 굴려서 락이 필요없도록 만드는게 가장 중요하다(말은 쉽지만 대단히 어려운 기술).

캐쉬(cash말고 cache)에는 프로그램 성능의 희노애락이 모두 녹아 있다고해도 과언이 아니다. 락프리를 믿고 쓰레드 경계를 넘나드는 자료형이 있다면 성능의 대재앙으로 돌아오게 돼 있다. 더구나 락프리는 구현도 어렵고 (최근에는 괜찮은 라이브러리들이 나와 있지만) 잘못쓰면 알아차리기 힘든 버그를 만든다.

락프리로 만들면 충분하지라고 생각하지 말고, 그조차도 없앨 수 있는 방법이 뭐가 있을까 잘 고민을 해야한다. 결국에는 서로에게 신경 안쓰고 돌아가는 core 개수만큼의 쓰레드가 가장 이상적이니까 말이다.

그래서...?

사실 위의 3가지를 잘 지키면 최고 성능의 서버 응용프로그램을 만들 수 있나요?라고 물으면 자신있게 "네"라고 대답 할 순 없겠지만, 최소한 나쁘지는 않을 것이라고 확신한다. 그 이상은 끝없이 병목 지점을 찾아서 제거하고 구조를 바꾸는 근성의 영역이라고 하겠다.