천 리 길도 한 걸음부터 RSS FEED

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

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

젠장...

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

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

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

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

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

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

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

이제 윈도우와 리눅스의 우열을 가리는 것은 사실상 의미가 없다. 이미 윈도우 서버를 잘 쓰고 있다면, 그걸 리눅스로 바꾸는 행동은 삽질에 가깝다. 그냥 구인하기 쉬운 OS를 도입하면 된다.

그러나, 윈도우 서버에는 큰 단점이 하나 있고 이때문에 도입 불가능한 분야가 실제로 있다. 그게 바로 '윈도우 업데이트'다. 더 정확히 말하면 업데이트 후 리부팅이다. 한달에 두세번씩 강제적으로 하는 리부팅이 분야에 따라서는 치명적일 수 있다. 물론 업데이트따위는 깔끔하게 무시하고 버티는 방법도 있기는한데, 이는 더 큰 문제를 초래할 수도 있으니 가능하면 업데이트는 다 하는게 좋다.

윈도우 서버가 리눅스의 거센 공세를 막고 세를 계속 확장(사실 이미 하향세)하려면 이 업데이트 문제를 반드시 해결해야한다. 실무에서만 10년 가까이 윈도우만 쓴 나도 짜증나서 바꿀까?하는 생각이 들때가 있으니 말이다.

소비자의 품질 요구가 높아졌고 소프트웨어의 복잡도가 증가해서, QA가 어느때보다 더 중요해졌다. 왠만한 조직에는 다 QA 부서가 있고 그들의 목소리도 과거보다 커졌지만 여전히 품질은 개판인 경우가 많다. 물론 독보적인 품질의 제품을 출시하는 회사들도 분명히 있다. 이 차이는 어디서 오는걸까?

여러가지 원인이 있고 조직마다의 특수성도 있겠지만, 나는 QA를 All or Nothing으로 보느냐 아니면 부분으로 떼어 놓고 보느냐 하는 차이에 있다고 생각한다. 보통 QA 과정은 적용에 차이가 있겠지만, 다음과 비슷하다.

1. 테스트
2. 결과 리포트
3. 오류 수정

테스트 과정은 기능별로 자잘하게 잘려서 수천에서 수만개가 넘는 경우도 있다. 그리고 그 중에서 분명히 오류가 발견된다. 1000개중 1개의 오류가 발견됐다고 하자. 그리고 그 한 개의 오류를 수정했다. 그 다음 과정은 뭘까?

만약에 고친 오류 1개만 테스트하고 나머지 999개는 그냥 넘긴다면 그 조직은 탁월한 품질의 소프트웨어를 출시하기보다는 똥을 싸지를 확률이 높다. QA는 All or Nothing의 세계다. 999개 중에 단 1개라도 통과하지 못한다면 그건 전체의 실패이며, 전체가 실패했으니까 1개를 수정한 후에 다시 전체를 테스트하는게 맞다.

그러나, 이러한 전체의 실패 정책을 계속 고수하는 건 쉬운 일이 아니다. 특히나 외부의 압박이 심한 경우에는 더욱 더 그러하다. 게임 오베를 하면서 치명적 버그가 발견되면 그것만 고쳐 패치하고 싶은 마음이 안들면 그게 사람이겠는가? 누구나 그런 생각을 하지만 원칙이 아니라 기억을 더듬어 봐도 그런 경우는 언제나 더 큰 문제를 발생시켰다. 하나 패치했더니 두 개의 버그가 새로 생기는 그 아찔한 경험 말이다. 단 1초도 더 방치할 수 없는 치명적인 문제라면 코드를 최소한으로 건드려 (데이터만 수정해서 그 기능을 무력화 시킬 수 있다면 최고) 그 기능을 차단해서 일단 패치하고, 제대로된 과정을 거쳐 패치하는게 맞다.

이렇게 급한 상황에서 원칙을 지키려면 QA 부서는 절대로 타협을 해서는 안되고, 구성원 모두가 QA 부서를 존중해줘야 한다. 그렇지않다면 위에서 말한데로 똥만 싸지르다가 망하게 된다.

나로호 발사 연기가 사소한 소프트웨어 결함때문었다고 한다. 어제 9시 뉴스를 보니 사소한 소프트웨어 결함이고 이를 고치는데 3일정도가 걸려서 순식간에 다시 발사를 할 수 있다고 한다. 상식적으로 생각해도 우주선 발사 프로세스가 그리 간단할리가 없고 몇 백개의 테스트만 거치면 모두 통과하는 단순한 과정은 절대 아닐 것이라고 믿고 싶다.

첫 번째 우주 발사체 발사에 대한 주변의 압박은 매우 심할 것이다. 5000억 이상이 소요됐고 이미 7년이 걸렸다. 며칠 더 걸리는 것은 문제도 아니다. 압박에 굴복해 성급하고 축소된 QA로 발사를 단행해 진짜 큰 문제를 만들지 않기를 간절히 기원한다.

스크럼을 쓰다보니 그 기저에 깔린 사상은 예전에 도덕인지 윤리인지 모를 과목에 나왔던 북한의 자아비판과 다를게 없다는 생각을 하게 된다(요즘에도 도덕이라는 과목이 있을려나).

공개적인 자리에서 하찮은 이유로 일을 못했음을 알리는 수모와 굴욕은 자아비판과 다를게 없다. 그러나 세상 모든 일에 예외가 있듯이 이 굴욕적인 자아 비판이 대수롭지 않게 변할 수 있는 간단한 방법이 있다.

그것은 모든 참여자가 이 공개적인 자아비판을 단순한 과정으로 여기는 것이다. 못한 것도 과정, 그걸 자랑스럽게 말하는 것도 과정 그리고 어색하게 웃으면서 넘어가는 것도 한 과정이 되는 것이다. 모든 것이 이렇게 매너리즘의 한 요소가 돼 버리면 스크럼은 끝이라고 봐야하고, 데일리 미팅은 그저 시간 때우기에 불과하다.

우리가 보는 스크럼 책(애자일 관리서 포함)에는 이런 경우가 없다. 모든 참여자는 다 능력있고 책임감이 넘치며 자신의 무능력과 실수를 부끄럽게 여긴다. 그래서 그들의 스크럼에는 실패가 없지만, 현실은 그렇지가 않다. 처음에는 분명히 자신의 실패를 부끄럽게 여기지만 실패가 반복되면 더 이상 숨길 것도 없고 부끄러울 것도 없다. 그리고 그 과정을 바라보고 있는 동료들에게도 면죄부를 대량으로 발행하게 된다.

팀장(스크럼 마스터든 PM이든 뭐라고 부르든간에)이라면 이러한 과정의 진행을 그냥 바라보고 있어서는 안된다. 실패는 부끄러운 일이고 팀에 큰 악영향을 주고 있다는 사실을 계속해서 팀원들에게 주입 시켜야한다. 물론 이게 너무 공개적이 되면 비난이 되니 그 정도도 관리가 필요하긴하다.

클라이언트 테스터는 전형적인 producer-consumer 구조로 되어 있다. Consumer가 producer보다 몇 배나 빠르도록 설계 되어 있어 producer가 consumer를 압도하는 시나리오는 상상해보지도 않았고, 당연히 그에 대한 처리도 하지 않았다. 그런데 어제 테스트를 하고 있는데 부하가 심해지면 producer가 consumer를 압도하면서 queue를 가득 채워 뻑나는 황당한 경우가 발생했다.

Multi-thread 구조에 문제가 있는건 아닌지, 코드에 오류는 없는지를 하나하나 확인하고 있는데 원인은 황당하게도 printf 에 있었다. Consumer가 자기 할 일을 하고 간단한 정보를 출력하는데 그 일을 하면서 출력을 동기화하고 그 과정이 producer의 속도를 따라가지 못하게 된 것이다. printf를 빼니 모든 문제가 사라졌다-_-;;

(사실 printf로 console에 출력하는 행위 자체가 많이 느리기 때문에 printf에서 사용하는 lock이 문제였는지 출력 자체가 문제였는지는 정확하지 않다. 프로파일링을 해봐야 정확하지만 해서 도움도 안되고 시간만 잡아먹을게 뻔한 짓을 하고 싶지는 않다)

그러고 보니 예전에는 printf를 사용해서 출력하면 동기화가 안되서 출력이 섞이곤 했는데 - 그렇다고 기억이 되는데 정확하진 않음 - 최근에는 본적이 없다. 모르고 있었는데, 좀 황당하네.

결론: printf는 원래 성능이 구린데다가, 동기화하는데 성능이 구리다.
환경: VS2008SP1, Vista64

프로젝트를 진행하다보면 굴곡이 있게 마련이다. 잛게 보면 스프린트(이터레이션), 좀 더 길게 보면 마일스톤마다 작업 진행이 출렁거리게 된다. 바닥인 시작 지점에서 출발한 작업 효율(혹은 양)은 계속해서 상승하다가 대부분 종료 직전에 급강하하게 된다. 일을 정리하다가 그럴 수도 있고 큰 일 하나를 끝내 놓고 멍한 상태가 지속될 수도 있다. 그리고 다시 조이기전까지 그냥 시간을 보내는 경우가 허다하다. 현재 내가 참여하고 있는 있는 프로젝트는 스프린트가 끝나고 다시 시작하기 전의 리뷰/회고/계획 단계가 그렇다.

프로젝트를 진행하면서 낭비를 줄이고 효율을 높이는 다양한 방법을 논의 하지만 이 자투리 시간은 간과하고 넘어가기 쉽다. 그런데 이 시간이 결코 작지 않아서, 효율적으로 일해 번 시간을 여기다 다 날리는 경우도 종종 있다. 새 일을 벌리기에는 어중간하고 놀기에는 긴 이 시간을 어떻게 사용하면 좋을까?

난 스터디를 권한다. 그룹도 좋고 개인적인 공부도 좋다. "난 이 시간을 이용해서 1,000 페이지가 넘는 The C++ Programming Language를 다시 볼거야" 같은 장기적인 계획만 아니면 된다. 논문이나 짧막한 기사 한 두편 집중 공략하는게 가장 효과적이고 결과를 팀과 공유할 수 있다면 더욱 더 좋다.

스프린트에 혼신의 힘을 기울여 꿈틀거릴 힘도 안남아 있다면 모르겠지만 자투리 시간을 잘 활용하면 정말 많은 것들을 할 수 있다. 물론 이렇게 블로그에 글을 올리는 것도 가능하다. 중요한건 절대로 그냥 날려버리면 안된다는 것이다. 회사도 손해지만 결국엔 자기 손해니까.

오늘 코딩을 하다가 우연히 알게 된 사실인데, 템플릿의 파라미터가 템플릿인 경우에 꺾쇠괄호(>)가 두 개 겹쳐도 정상적으로 파싱이 된다. 그러니까

template1<template2<int>> dc;

이게 정상적으로 된다는 말이다. 이거 예전에는 않되서

template1<template2<int> > dc;

처럼 이상하게 중간에 공백을 두고 썼는데, 언제부터 파싱을 제대로 하게 된 건지 알 수 없다. 미리 알았으면 삶이 좀 더 편했을텐데.

ps. VS2008 기준

Design issues - Sending small data segments over TCP with Winsock