예전에 NSIS를 이용 할 경우 대용량 파일을 배포 할때 오류가 나는 문제에 대해서 포스팅을 한 적이 있다. (자세한 내용은 http://www.yuno.org/295 을 참고)

이 때, 해결 했던 방법 중에서 일반적으로 쓰인 방법이 인스톨러와 데이터 파일을 배포해서 2개 이상의 파일을 이용한 배포였다. 그런데, NSIS 자체에서 압축 기능을 지원하고는 있지만, 별도의 압축 파일을 처리 하는 모듈은 없기 때문에 NSIS의 EXCUTE SCRIPT 를 이용해서 COMMAND로 실행 가능한 7Z 압축 바이너리에 압축 풀 파일을 넘겨주어 압축을 푸는 방식을 이용했다.

즉, INSTALL.EXE 와 DATA.7Z 이렇게 2개의 파일을 배포 하지만 INSTALL.EXE 는 설치 능력은 있지만 DATA.7Z 파일의 압축을 풀 능력이 없기 때문에 INSTALL.EXE 자체에 7Z.EXE 를 함께 넣어서 설치 과정중에 7Z.EXE를 별도의 프로세스로 실행해서 DATA.7Z 를 압축 푸는 방식을 이용했다.

하지만, 이 방식이 조금 문제가 있는 것이.. 표준 스트림 버퍼를 이용을 하고는 있지만 7Z.EXE 에서 출력 되는 메세지가 이유를 알 수 없게 버퍼링이 되어서 현재 상태를 바로 보여 줄 수 없다는 문제가 있다. 다시 말하면, 100개의 파일을 압축 푸는데, 어떤 파일을 압축을 풀었다 라고 100번의 메세지가 DETAIL LOG에 나와야 하지만 어떠한 이유에서 이 출력될 LOG가 버퍼링 되어서 뭉쳐서 나오는 문제가 생긴 것이다.

따라서 설치 시간이 오래 걸리는 대용량 설치의 경우 유저들은 이게 설치가 되는건가? 하는 의구심을 품게 된다. 또한 현재 설치가 어느 정도 진행 됐는지 알 수가 없어서 답답함을 가질 수 밖에 없었다.

우리 회사에서도 NSIS를 이용한 배포를 하는데 항상 저 문제가 마음에 걸렸다. 언젠가 시간이 나면 NSIS용 7Z PLUG-IN을 만들어야겠다! 라고 생각하고 있었는데, 최근에 제작 할 시간이 생겨서 작업을 시작하고 보니.. 이런! 이미 나와있다. -_-

Nsis7z plug-in ( 참고 : http://nsis.sourceforge.net/Nsis7z_plug-in ) 을 이용할 경우 NSIS 인스톨러를 이용해서 압축을 풀 수 있게 된다. 대용량 파일을 압축 풀더라도 버퍼링으로 인한 메세지가 밀려서 나오는 문제도 해결 할 수 있을 뿐만 아니라, 현재 설치 상태를 % 로도 표시를 할 수 있다.

사용법도 매우 간단해서, 기존의 처럼 7Z.EXE 를 더 이상 인스톨러에 포함하지 않아도 된다. 플러그인을 다운 받아서 NSIS7Z.DLL 파일은 NSIS의 PLUGIN 폴더에 넣어주면 준비 끝. 그 다음에는 인스톨 스크립트에 몇줄만 추가 하면 완료다.

이 플러그인을 이용 할 경우 2가지 배포 방법을 이용 할 수 있다.

NSIS는 인스톨러 컴파일을 할때 설치 데이터를 인스톨러에 함께 묶는데, 1) 이때 데이터 파일을 함께 묶는 방법, 그리고 2) 데이터 파일을 인스톨러와 별도로 배포 하는 방법으로 나뉘어 진다

1)의 경우는 작은 용량의 배포에 알맞다.
2)의 경우는 대용량 파일을 배포 할때 알맞다. NSIS가 단일 파일을 2GB 이상 지원 하지 않기 때문에 2GB 이상의 데이터를 배포 한다면 별개의 데이터 파일로 배포 하는 것이 좋다.

또한 비스타에서 실행 파일의 용량이 대용량일 경우 실행 시간이 매우 오래 걸리는 문제가 있는데, 이 문제 역시 별도의 데이터 파일을 이용 할 경우 해결 된다.


자, 그러면 플러그인에서 지원하는 명령어들을 확인해 보자. 이 플러그인은 총 3개의 명령어를 지원한다.

위의 3개 함수를 이용하면 각 현재 진행 상태를 안정적으로 표시 할 수 있다. 다만, 이 플러그인의 조금 아쉬운 점은 압축 풀고 있는 파일명을 표시 안해주는 것이다. 하지만, 이 플러그인은 코드가 공개 되어 있으므로 조금만 수정하면 현재 압축 해제 파일명을 DetailPrint 를 이용하여 표시하는 것은 큰 문제가 되지 않을 것이라 생각된다.

몇년 전에 읽었던 "조엘 온 소프트웨어"라는 책이 있습니다. 혹시 아직 안보신 개발자 또는 개발자와 함께 일하시는 분들은 한번 읽어 보시기를 추천합니다 ; 이 책의 22장에 보면 " 테스터를 두지 않는 (잘못된) 다섯가지 이유 " 라는 부분이 있습니다. 

다섯가지 이유를 저자는  1)  버그는 프로그래머가 게을러서 생기니까요.  2) 우리 소프트웨어는 웹에 올려놓아서 버그는 금방 고쳐질 수 있으니까요. 3) 고객이 소프트웨어를 테스트해줄 테니까요. 4) 우수한 테스터는 테스터로 일하려고 하지 않거든요. 5) 테스터를 고용할 돈이 없으니까요. 로 들고 있습니다.

이러한 이유를 들어서 테스터를 두지 않는 다면 멍청한 짓이다! 라고 저자는 이야기 하고 있습니다. 저 역시 이 부분을 상당 부분 동감합니다. 제가 지금까지 보고, 겪은 거의 모든 회사는 출시 전날까지 작업을 합니다. 심지어는 패키징 하기 직전까지 코드 작업을 하는 경우가 있습니다. 그나마 그 작업이 버그 수정이라면 다행이지만, 기능 추가와 같은 신규 코드 작업도 있습니다. 그리고는 그냥 업로드 해버립니다. 가끔은 그럴때, 그런데 이거 테스트 없이 그냥 풀어도되나요? 라고 물었을때 거의 모든 사람의 경우 (심지어 나 역시) "테스트 서버(베타 서버)에 올릴 것이니까 괜찮아, 버그 테스트는 유저들이 해줄테고 리포트 들어온거 수정해서 다시 패치 하면 되지" 라는 말을 합니다. (반성중)

바른 자세일까요? 네. 마치 이건 도덕 시험 같습니다. 누구나 저런 자세가 옳다고는 생각하지 않습니다만 "현실"을 생각하면 어쩔 수 없다는 거죠. 네. 저도 현실을 생각해서 저렇게 행동하고 답 했습니다. 그런데, 왜 현실을 고려 할 수 밖에 없는 것일까요? "테스터를 고용할 돈이 없으니까요" 라고 말합니다. 와우! 다섯가지 이유를 하나씩 정말 다 따라갑니다! 

버그가 없이 프로그램을 작성 할 수 있는 프로그래머는 세상에 없습니다. 버그는 프로그래머가 미처 생각하지 못하고 지나친 부분에서 발생합니다. 버그는 프로그램에게는 필연적인 존재입니다. 어떻게 해서든지 출시전에 그 문제점을 찾아서 프로그래머에게 전달을 해야 합니다.

기업에게 있어서 "이미지"라는 것은 매우 중요한 요소입니다. 유저(고객)에게 각인 되는 이미지 중에서 제일 강한 녀석은 바로 첫 인상이죠. 사람과 마찬가지 이지만 말이죠. 어쨋든, 고객이 다운로드 받은 프로그램을 실행 했는데 어처구니 없는 버그가 나온다? ... 그 엄청난 이미지 훼손을 회복하는데 걸리는 시간은 예상을 뛰어 넘습니다. 또한 만약에 그것이 이미 시장에서 어느 정도의 점유율을 차지 하고 있는 제품이 아닌 신규로 릴리즈 된 녀석이라면 시장의 기대 값은 정말 순식간에 0점까지 치닫게 됩니다. 고생은 고생대로 하고, 욕은 욕대로 먹고.. 한 국가에만 릴리즈 되는 것이라면 그나마 이정도 선이지만 해외 파트너사로 릴리즈 했을때는 ... 이거 참 난감해집니다.

이러한 문제는 테스터 조직을 갖추게 된다면 상당 부분 해결이 되지 않을까요?

테스터는 꼭 전문가여야 할 필요는 없습니다. 특정 고객층을 목표로 배포 되는 프로그램이 아닌 대부분의 프로그램은 불특정 다수에게 배포 되어 사용이 되어집니다. 테스터 조직을 전문적으로 관리해줄 관리자와 일반 사용자 처럼 해당 프로그램을 사용해줄 테스터만 있어도 충분한 효과를 낼 수 있습니다! 출시가 잦아서 잦은 테스트가 필요한 제품이 아니라면, QA 조직의 대부분을 임시직 (계약직을 비롯한 파트타임 아르바이트)으로도 충분합니다. 오히려 불특정 다수에게 배포 되는 프로그램은 전문적 지식을 갖추지 않은 일반인 파트타임 아르바이트가 더 효과적일 수도 있습니다. 아니면 해당 소프트웨어를 사용하는 사람들 중에 일부를 파트 타임 아르바이트로 고용해서 테스트를 진행 하게 할 수도 있습니다!

버그가 발견 되면 프로그래머는 슬퍼 할 수 밖에 없습니다. 내 자식 같은 코드에서 버그가 .... 가 아닌 한 밤중에 끌려 나올수도 있기 때문입니다!!! 한 밤중에 긴급 점검을 위해서 택시를 타야 하는 경우, 얼마나 가슴이 아픈지 모릅니다.

테스트 조직에 모든걸 다 해결해 주리라고는 믿지 않습니다. 다만, 테스트 조직의 QA 단계를 지나치면서 고객에게 가는 버그의 수를 줄이고, 버그에서 깍아 먹는 회사 이미지를 보호하고, 한 밤중에 긴급 점검으로 끌려 나오는 빈도 수를 줄이기는 해주리라고는 믿습니다.

아, 그렇다고 프로그래머에게 테스트를 맡기면 안됩니다. 프로그래머는 테스트를 싫어합니다. 또한 테스트를 진행해도 일반 테스터 보다 버그 발견률이 낮을 수도 있습니다. 그것은 아이러니 하게도 프로그래머는 정상적인 방법으로만 사용을 하는 경향이 크기 때문입니다. 하지만, 애시당초 정상적인 프로세스 상에서 버그가 발견 되서 출시 되는 경우는 적습니다. 일반 사용자는 정상적은 방법으로만 사용하지 않습니다. =_= 

아 뭐 ..

그냥 테스트 전문 조직이 있었으면 좋겠다는 푸념이었습니다. 버그 없는 게임을 만들어서 유저에게 욕을 그만 먹었으면 좋겠습니다. ㄷㄷ

이제는 청춘불패나 보러 가야겠습니다. ...;

p.s 테스트 조직에게 출시 거부권이 있다면 더 좋겠지만, 현실적으로는 힘들겠군요. 어떤 회사도 출시를 늦출리는 없을테니 프로그래머를 더 쪼아서 ... ... 저도 프로그래머인지라 차마 더 쪼임 당할 수 있는 발언은 차마 할 수가 없군요 ㅋㅋ

종종 이런 이야기를 듣습니다. "프로그래머는 너무 방어적으로 일을 하는 것 같다." 라는 말이죠.

어떤 의미일까요? 예를 들어서 소프트웨어 개발 회사에서 어떤 프로젝트를 진행을 할때 그 프로젝트의 목표를 구현 하는 일을 소위 기획이라고 합니다. 기획자들은 충분한 시간을 가지고 이 프로젝트의 진행 목적 부터 진행 중간 단계의 표현, 기능 들에 대해서 진지하게 고민합니다. 그렇게 해서 (예제로써) 약 버스를 만들기로 했습니다.

그리고 이것에 대한 내용과 스케쥴을 기획서에 작성을 해서 그 기획서를 들고 프로그래밍 조직으로 찾아가서 이야기 합니다. "이것을 언제까지 만들어주세요." 그러면 프로그래머는 기획서를 쭉 살펴보고 기획서가 너무 부실하다고 생각합니다. 기획서에 써 있는 것들이 어떤 목적으로 구현이 되는 것인지, 그리고 또 어떠한 내용인지 확실히 알 수가 없습니다. (물론 아닌 경우도 있습니다.) 그리고 이것 저것 하나씩 묻기 시작하고, 실제 구현 방법에 대해서 하나씩 생각을 해보기 시작하고 나서 대부분은 이렇게 말합니다. "그때까지는 힘들겠는데요.."  라는 말과 함께 협상을 시작합니다.

그리고 프로그래머는 구현해야 하는 기능 중에서 구현이 애매 모호하거나 시간이 오래 걸릴 것 같은 기능들을 구현이 편한 방향으로 변경을 시도합니다. 때로는 이것은 기획자의 의도와는 좀 다른 방향으로의 결과물을 불러오기는 합니다만 이미 대부분의 상황에서 기획자와 프로그래머는 "협상" 단계에 들어가 있기 때문에 기획자도 그것을 받아 들입니다.
그렇게 해서 최초 목표였던 버스는 승합차가 되어 돌아오게 됩니다. 그리고 그것은 출시 됩니다.

지난 몇년간 게임 회사에서 일 하면서 경험하고, 봐왔던 현상입니다. 기존에 다른 회사에서 일 했던 경험을 바탕으로 한다면 다른 회사 역시 대부분은 저런 흐름을 비일비재하게 겪고 있을 것 같습니다.

프로그래머들은 어째서 저런 방어적 입장을 취하는 것일까요?

공식적인 이유로는 이러한 이유들이 있습니다.

1) 기획자가 정말 무리한 일정을 가지고 온 경우, 2) 일정을 아무리 길게 잡아도 아에 불가능한 것을 요구 하는 경우. (예를 들어 기존에 사용 하고 있던 코볼의 코드를 C#으로 완벽하게 포팅 해주는 프로그램을 만들어 주세요. 와 같은), 3) 나의 일을 줄이기 위해서.  4) 기타.. 어떤 것들이 있을까요?

... 어떤 이유일까요? 사실 이런 이유는 중요한게 아닙니다. 위에서 말한 어떤 이유라고 하더라도 그것은 사실상 개별적 해결이 불가능 하기 때문입니다.

저는.. 이런 일이 발생 하는 이유가 바로 '협상' 단계가 생길 수 밖에 없는 업무 흐름 때문일 거라는 생각이 듭니다. 완전한 갑을 관계에서는 '협상' 따위는 없겠죠. (경우에 따라서는 아주 조금 있을지도 모르지만-_-) 그렇다고 해서 갑을 관계를 형성 하라는 것은 아닙니다. 같은 회사안의 조직이기 때문에 그렇게 해봐야 조직간의 분열을 더 초례 할 뿐입니다.

그렇다면 이렇게 해보는건 어떨까요?

기획자는 처음에 기획을 구상 하는 단계에서 이것의 간단한 '목표' 만을 설정합니다. 그리고 기획 회의를 진행할때 실무자 또는 실무자에게 충분한 영향을 줄 수 있는 사람을 함께 하는 겁니다.

뭐야 이게? 라고 생각하는 분들도 있을 것 같습니다만, 실제 기획을 구체화 시킬때 실제 구현자인 프로그래머가 참석해서 함께 회의를 진행한다면 '협상' 단계 따위는 오지 않습니다. 네, 물론 그 '협상' 단계가 기획 회의에서 이루어지게 됩니다. 하지만, 그 수준이 명확하게 다릅니다. 왜냐하면, 기획 회의에서는 간단한 목표만 정해져 있을뿐, 이것의 정확한 기획 결정이 이루어지기 전이기 때문입니다.

기획 회의에 프로그래머가 참여를 한다면 프로그래머는 그 기획 회의에서 내가 어떻게 방어적 입장을 취할까를 고민하지 않습니다. 말 그대로 기술적인 지식을 바탕으로 그 기획에 함께 참여하게 됩니다. 또한 기획 회의에서는 해당 작업을 해야 하는 목적 등에 대한 고민이 이루어지므로 기획서에서는 그냥 지나치는 (또는 아에 나와 있지 않은) 작업의 목적(사실상 동기)를 프로그래머와 함께 공유 할 수 있게 됩니다. 이것은 프로그래머에게 기존의 방식 보다는 조금 더 주인의식(?)을 부여 할 수 있는 방법이 아닐까 싶습니다. 실제 프로그래머들을 참석 시킬 경우 기획자가 생각하지 못하는 기술적인 지식을 이용한 좋은 방향이나 아이디어가 나오기도 합니다. 손해 볼건 없다는거죠.

또한, 프로그래머가 참여 하므로 애시당초 불가능한 기능에 대해서는 기획 회의에서 충분히 걸러 질 수 있습니다. 그리고 결정 되어지는 것들에 대하여 그 자리에서 프로그래머와 함께 스케쥴 임시 계산이 가능하므로 스케쥴 문제 역시 크게 해결 할 수 있습니다. 어차피 스케쥴 협상을 할 거라면 회의 단계에서 미리 하는데 시간을 아끼는 방법이기도 하죠.

그냥 단지 프로그래머가 기획 회의에 참여 하는 것만으로 기존의 '협상' 단계를 없애거나 최소화가 가능해지지 않을까요?

네.

뭐 그냥 그렇다구요.

어떤 음식이던지, 보거나 듣는 것만으로는 도저히 그 맛을 상상 할 수 없다. 딱 이 녀석이 그랬나. 어쩐지, 여행을 갔던 시기에 조개류를 별로 좋아 하지 않았던 나는 이스탄불 곳곳에서 보이는 홍합밥(미디예 돌마/Midye Dolma)를 보면서 그냥 지나치는 것이 당연했다.



그러다가 이스탄불을 떠나서 프랑크푸르트로 가는 비행기를 타기 전날, 이스탄불의 한 시장에서 이왕 온거 맛이나 보자~ 라는 생각에 한개 집어 먹은것이 벌써 7년째 한이 되어버리고야 말았다.


어찌나 맛있던지..

이 말 한마디 밖에 할 수 있는 말이 없다. 그냥 지금까지 지나쳤던, 수북히 쌓여 있던 그 수많은 홍합밥들.. 그냥 무심코 지나쳐 버린 내가 너무도 미웠다. 더군다나 가격도 매우 저렴해서, 당시 화폐 개혁 이전이었던 터키쉬 리라로 약 20~30만리라(약 300원 수준)이었다!!!


여행에서 만났던 분에게 한국 올때 미디예를 사서 박스에 담아와 달라고 부탁까지 할 정도로 (물론 안가져왔다-_-) 간절히 원했지만, 다시는 이 녀석을 맛 볼 수가 없었다.


언젠가, 다시 이스탄불에 간다면...

도착과 함께 이 녀석을 찾으리!, 그때까지 부디 무사히 남아 있어다오...

한 겨울의 터키, 그리고 카파도키아... 예전에 비슷한 글을 쓴 적이 있는 것 같은데, 터키는 중동이고.. 중동은 항상 더운줄 알았다. 내리쬐는 태양, 사막.. 이런 모습을 상상했던 나는 2003년 2월 새로운 중동을 만났다.

앙카라에서 몇시간을 버스르 타고 도착한 카파도키아는 터키에서 이스탄불 만큼이나 유명한 관광지이다. 특이한 모양의 특이한 지형들(독특한 바위들), 바위를 깍아 만든 수 많은 동굴들과 그 동굴을 활용한 숙소들, 박해를 피해서 숨어 지냈던 기독교의 은신처, 그리고 은신처로써 만들어진 지하 도시. 터키를 방문한다면 절대 빠질 수 없는 여행지이다.

하.지.만.

한국에서는 여름, 겨울이 전부 여행 성수기로 여름에 터키를 방문하는 사람들은 쨍쩅한, 바짝 말라버린 카파도키아를 마음껏 만족하고 오지만, 겨울에 터키 여행을 준비 하는 사람들은 하얗게 덮혀 있는 그곳은 상상하지 못했으리다.. 그리하여 하드 디스크를 검색하여 2003년 2월 겨울을 맞이했던 카파도키아의 모습을 기록해둔다. 겨울에 터키로, 그리고 카파도키아로 여행을 준비 하시는 분들은 참고 하시라... 한 여름의 이곳이 궁금하다면 여기!!!를 눌러 보시라 ..

보통 타이페이 101 타워를 밤에 올라가서 타이페이시의 야경을 본다. 야경을 보고 나서는 아래 있는 많은 백화점들에서 저녁 식사를 할 수도 있지만, 가까운 곳에 있는 린랑제 관광 야시장을 찾아 보는것도 나쁘지 않다.

물론 스린 야시장과는 비교 할 수 없겠지만, 그래도 시내에 있는 야시장으로 가볍게 한번 둘러 보는 것은 나쁘지 않다. 하지만 중국계(홍콩, 중국, 대만 등)의 야시장은 사실 거기서 거기라는 것을 꼭 염두에 두고 ;;