SW개발자....3

<SW개발자....3>

Taekkyung Lee2011. 11. 14.에 수정  -  공개

이택경
twitter :@kyung88
email : taekkyung{앳}primer.kr

* 이글은 주관적이고 일반화의 오류가 있을수 있다는 점, 그리고 1995년~2003년 기간에 치중되어 현재는 상황이 다를수 있다는점 참고하시고 보시기 바랍니다.

4. 다음에서 SW개발이란..

1) 다음에서 개발자로서의 개인적인 꿈

앞의 1편에서도 이야기했듯이, 개인적으로는 프로그래밍이 좋아서 시작했고 전산학을 전공하고 다시 개발자로서 일을 하게 되었습니다.
프로그래밍이나 컴퓨터업계의 특징은, 끊임없이 새로운 기술이 나오기에 잘 질리지 않다는 점이 또다른 매력이기도 하지요.
반면에, 이러한것이 정신없이 바쁜 현업에서는 큰 압박으로 다가오기도 했습니다. 
쏟아져 나오는 새로운 플랫폼/아키텍쳐, 새로운 언어, 기타 새로운 기술을 끊임없이 익혀야했는데 인터넷 시대와 더불어 이전과 달리 더욱 폭발적으로 증가했기 때문이죠.

더불어 매니징에 대한 업무부하도 컸기 때문에 결국 1998년도를 끝으로 실제 프로그래밍 업무에서는 손을 떼게 됩니다.
그전에도 프로그래밍 비중을 줄여왔었지만, 실제 프로그래밍을 완전히 손뗐을때는 참 어색한 느낌이 들더군요. 웬지 프로그래밍을 안하면 마치 일을 안하는것 같은 느낌이랄까요?
물론 이것도 시간이 지나면서 새로운 역할에 적응하면서 서서히 사라져갔습니다만, 한동안 뭐랄까 환상통처럼 잔재가 남긴 했었습니다.

그뒤 개발팀장과 CTO로서의 업무는 개발자들에 대한 매니징, 그리고 매니징을 넘어 개발자/엔지니어에 대한 비젼제시, 프로그래밍할때처럼 디테일한 수준은 아니더라도 새로운 기술동향을 파악하고 관련된 기술전략수립과 의사결정, 그리고 회사의 경영진으로서 기술적인부분과 별개로 서비스/비즈니스방향을 캐치하고 관련하여 기술업무를 진행하는 부분들이었습니다.

다음창업전에 저의 개발자로서의 소위 로망은 패키지 쪽이었습니다.
그당시 SW패키지 개발회사들이라면 한글과 컴퓨터, 한메소프트가 생각나네요. 
아무래도 SW패키지 개발이 "웬지 기술적으로 완성도높은 SW"라는 생각에서 비롯된것 같습니다.
다음에서 SI개발/패키지개발/온라인서비스개발/ASP개발등 게임쪽 개발을 제외하고는 다해본것 같은데, 개인적인 경험은 다음과 같습니다.

- SI(System Integration) 용역개발은 우리의 제품/서비스가 아니고 지속성도 없기에, 아무래도 크게 애착이 가지는 못했습니다. 
회사의 초기 미션도 SI는 본질적인 목표보다는 캐쉬카우성격이 강했었고, 특히 국내시장의 사정상 제값을 받기도 쉽지는 않으니깐요. 
1995년 여름의 데이콤 첫 프로젝트(정확하지는 않지만 관련SI로는 거의 국내최초가 아니었나 생각합니다)이후 2년정도는, 그래도 인트라넷이나 홈페이지구축이 희소가치성이 나름있고 다음이 관련초기기업으로 경쟁력도 있어 고부가가치시장이었으나, 이후 훌륭한 플랫폼/툴들의 등장으로 진입장벽도 낮아졌고 경쟁사들도 범람하면서 저부가가치시장이 되어갔습니다. 

- 패키지개발은 다음초기의 광의의 비젼인 "인터넷관련된 솔루션/서비스 전문" 중의 하나이기도 했었고, 위에서도 이야기했듯이 개인적으로도 로망이었던 부분이었습니다. 
인트라넷 SI에서 쌓은경험들을 기반으로 패키지화하고 협력사들을 구축해서 관련된 커스터마이징도 진행해보자는 비젼으로 "IntraWorks"란 이름으로 그당시 버추얼아이오(현 버추얼텍)과 같이 작업했었습니다.
하지만 역시 다양한 툴들과 함께 값싼 SI용역시장에서 버티기란 힘들다는 판단하에 애착은 갔었지만 결국 드랍했습니다.
기술적으로는 SI보다는 완성도가 높은 아키텍쳐에 기반해 개발했었지만, 비교적 단기간에 개발한 관계로 어느정도 한계는 있었던것으로 기억합니다.

- 온라인서비스개발은 다음창업시부터 서비스한 "버추얼갤러리"와 함께 다음의 비젼중 또 다른축이었습니다. 
결국 SI/패키지/ASP 모두 그만둔 다음에서 최종적으로 남은부분이자 가장 핵심인 부분이 되었죠
서비스개발은 기술적인 측면에서 패키지개발만큼 기술적으로 완성도가 높지는 않습니다만, 우리의 서비스이고 또한 사용자들에 맞추어 지속적으로 업데이트해나간다는 측면에서 애정이 가는 개발이었습니다.
사실 온라인서비스의 특성상, 기본적인 최소 아키텍쳐만 갖추고 나머지는 업데이트에 맞추어 계속 개발하다가 어느 시점에 갈아엎고 하기에, 아트적인 코딩과는 거리가 있지만요. 

- ASP(Application Service Provider 요즘으로 보면 일종의 SaaS)쪽은 SI에서 패키지가 파생되었듯이, 온라인서비스에서 파생되었습니다.
다른부분보다 한메일서비스를 커스터마이징해서 해외 스페인어권의 믹스메일과 이탈리아어권의 포스타웹, 국내 한겨레신문과 SBS쪽 메일등을 서비스했었습니다.
특별한 다른 기능이 장점이었다기보다는, 그당시 한때 세계 Top7에 랭킹되었던 대용량 트래픽으로 검증된 한메일서비스가 가장 큰 경쟁력이었습니다.
실제 마이너한 커스터마이징이 비해 상당히 고부가가치 비즈니스였었죠. 그당시 100만이상 대용량 웹메일서비스를 ASP했던곳은 세계적으로 다음외에 해외의 전문업체인 Critical Path 한곳밖에 없었으니 역시 희소가치와 진입장벽이 있었기때문이죠. (그당시 핫메일등은 ASP를 하지 않았으니깐요)
이후 자회사인 다음솔루션에서 SOHO대상으로 진행을 했습니다만, 역시나 그쪽 경쟁력과 대용량 한메일 경쟁력은 별개이기에 실패로 끝납니다.
기술적인 측면에서는 일반 온라인서비스 개발과 비슷하고 실제 소스코드를 공유했다고 보면 되겠습니다.

2) 다음에서 온라인서비스 개발사

초기엔 지금처럼 Linux가 서버로 보편화되기 이전이었습니다. 데스크탑용으로는 몰라도 서버로 쓰기에는 무리였었죠.
인트라넷 SI 용역개발시 Sun, SGI, HP, Digital(DEC) 등 각종 서버를 이용했었는데, 다음 최초인 온라인서비스인 "버추얼갤러리"를 비롯해 이후 각종 온라인서비스와 "한메일" 까지 Sun계열 서버를 이용했었습니다.
한메일 서비스 경우 오픈뒤 트래픽이 급격히 증가하였기에, 당시 SGI서버가 상대적으로 앞서가는 플랫폼이어서 Sun에서 SGI서버로 교체해서 이용했었죠.

그후 첫번째로 기존시스템을 뒤엎는 큰 리모델링 작업은 프론트엔드와 백엔드 분리외에 1998년도경에 사용자별로 분산시스템을 만드는것이었는데, 당시 폭발적으로 증가하는 사용자는 CPU카드/메모리/RAID등을 늘려가면서 버티고 (소위 돈으로 때운거죠) 100만 근처에 가서야 완성되게 되었습니다.
사실 그당시 시스템으로 아무리 고성능 서버를 쓰더라도 한서버가 버틸수 있는 한계가 100만 정도였기에 그 이후는 돈으로 때울수도 없이 기술적으로 해결해야하는 시점이었죠.
이후 계속 늘어가는 한메일서비스와 새로 폭발적으로 증가하는 카페서비스는 새롭게 Sun계열 서버들로 확충하였습니다.
그당시 Sun서버의 솔라리스가 업그레이드되면서 상대적으로 SGI서버와의 격차는 줄었기에 "성능차이가 크게 나지 않는다면 보다 대중적인 기술을 이용하자"는 개인적인 철학에 입각하여 진행했던겁니다.

사실 지금과 같은 저렴한 리눅스와 클라우딩환경이 없던 당시에는 (지금은 훨씬 저렴한 가격에 고성능 서버와 대용량트래픽 인터넷을 이용할수 있는 복받은 시기죠. 물론 경쟁사들도 마찬가지 혜택을 받는다는 문제가 있지만요 ^^) 서버와 인터넷회선비용이 워낙 큰 관계로 이재웅대표님과 종종 다투기도 했었습니다. 
캐쉬카우였던 SI 용역개발로 번돈으로 인건비외에 서버비용까지 분담하기는 힘들었기 때문이었죠. 
당시 회사 부채도 꽤 되었었는데, 결국 베르테스만 투자이후 자금조달에서 풀려서 원할한 투입이 가능했었습니다.

돈을 많이 버는 대기업 전산실도 아니고 사용자수도 1000만을 넘어가는 와중에, 자금조달이 설사 원할해졌다고 하더라도 이런 고가의 서버들을 지속적으로 투입하는것은 분명히 부담이 있었기에 PC서버와 OS는 FreeBSD나 Linux중 한 플랫폼으로 다운사이징을 준비하게 됩니다.

<그림> 2001년 자체 테스트 결과

FreeBSD는 그당시 미국야후가 주로 이용하고 있어 그쪽으로 다운사이징을 고려하던중, 마침 시기적절하게 2001년에 릴리즈된 고성능서버 기능을 제대로 지원하는 Linux Kernel 2.4가 눈에 들어왔고, (사실 이때부터 Linux가 본격적으로 서버용으로 쓸만해졌지요) 몇개월에 걸쳐 벤치마킹해본 결과 FreeBSD와 비슷한 수준이라는 판단하에 역시 "성능차이가 크게 나지 않는다면 보다 대중적인 기술을 이용하자"는 철학에 의해 향후 보다 트렌드가 되리라고 본 Linux쪽으로 방향을 잡았습니다.
그뒤 가칭 "Daum2K" 프로젝트를 추진하면서 두번째로 기존시스템을 뒤엎는 큰 리모델링 작업을 진행했습니다.
작업의 근간은 2000년도까지 기존에 구매된 Sun서버들과 Oracle DB등은 그대로 메인서버로 돌려 재활용하고, 기타 대다수 주요서버들을 Linux와 File System에 기반한 라이브러리 시스템으로 대체하는것이었습니다. 
그와중에 대다수가 Unix, Linux 서버기반이라 Y2K와는 거리가 멀긴 했지만 20세기의 마지막날에 혹시나하고 대기했었던 기억도 나네요. 희대의 사기극인 Y2K 보다는 사실 Year 2038 Problem (32bit 유닉스계열의 날짜문제)이 더 말이 된다고 생각하지만 말이죠 :)

Daum2K이후 어느정도 다음서비스의 기본 시스템 아키텍쳐가 정비가 완료되었습니다.
서버로는 Linux의 PC서버와 Unix의 Sun서버가 주력이고, 일부 컨텐츠서비스는 CP(Contents Provider)와의 호환성을 고려해 Windows 기반의 서버들로, 그리고 주요언어로는 Java를 택했고, Windows쪽은 ASP도 일부, 그리고 성능위주로 low level에서 구현할 일부서버들은 C로 구현하게 됩니다.
DB는 Sun서버에서는 Oracle, PC서버에서는 파일시스템 라이브러리와 ISAM 그리고 이후 MySQL을 쓰게 되었구요.
백업은 초기에는 Sun서버에다 테이프를 고려한적도 있었지만, 다운사이징과 함께 미러링 전략으로 진행되게 됩니다.
물론 이것들은 2000년대 초반의 시스템들이고 지금의 다음 아키텍쳐는 여기에서 또 변화가 있을겁니다.
그당시 장애나 성능저하등 대다수 문제가 디스크쪽이어서 제발 메모리 디스크나 좀 나와라 싶었는데, 최근에 SSD가 나온것을 보면 참 세월이 많이 흐른것 같습니다. 물론 용량대비 가격은 꽤나 비싼게 흠입니다만..

그외, 그당시 일반기업 전산시스템들이 대부분 낮시간에 운영되는것과 달리 24시간 운영하는 인터넷서비스의 특성상 적은인력으로 구성된 조직에서 개발자/엔지니어/운영자 모두 고생들 참 많이 했던것 같습니다. 
서버장애가 생기면 한밤중에 콜되어서 처리해야하는 경우가 많았으니깐요. 한번은 믹스메일 문제로 갑자기 새벽에 국제전화받아 잠결에 영어도 안되어 고생했었던 기억이 나네요.
지금은 초기보단 조직과 시스템이 갖추어져서 예전보단 나아졌습니다만, 모든 인터넷서비스업체들의 어쩔수 없는 스트레스가 아닌가 싶습니다. 24시간동안 보안/백업/서버장애/인터넷회선장애등에 대응해야하는것 말이죠..

최근의 인터넷 스타트업도 크게는 다음의 포털서비스와 비슷한 단계를 거치게 되는것 같습니다. 아래의 단계들이 반복해서 순환구조가 된다고나 할까요
그래도 예전보다 HW나 SW, 클라우딩기술등이 현재 많이 발달되어, low level에서 새로 만들어야 할 경우보다는 시스템을 잘튜닝하거나 아니면 오픈소스들을 잘 활용하면 비교적 쉽게 대용량 트래픽을 감당하는 성능을 낼수 있을겁니다.

1단계 : 어느정도 서비스가 갖추어질때까지는 큰돈이 안든다면, 다른 우선순위(기능개선등)를 위해 기회비용측면에서 돈으로 막기
2단계 : 사용자가 증가함에 따라 비용도 꽤 증가된다면, 8:2 법칙에 따라 비교적 적은 노력으로 큰 튜닝효과를 낼수있는 부분을 집중해 손보기
3단계 : 아무리 돈이 많아도 막을수 없는 단계 (예 : 본질적으로 분산시스템을 제대로 설계해야할경우)가 되면 전체적으로 크게 시스템을 리모델링하기


3) 다음에서의 개발자구인

현재의 스타트업들도 그렇듯이, 다음초기에는 개발자 구하기가 참 힘들었습니다.
그당시는 벤처열풍도 없을때였고 취업도 잘되던때라, 대기업 들어가려는 친구들을 설득해서 데려오긴란 참 힘들었죠.
그때만해도 버블시대이기도 했기때문이겠지만, 보통 학창시절에 대기업에서 하루잡아서 견학도 시켜주고 놀이공원에서 놀게도 해주고 저녁엔 동문선배들과 함께 회식자리 만들어 스카웃하던 시기니깐요. 
장학금을 받는대신 일정기간 해당 대기업에서 근무해야했었던 장학금제도도 있었습니다. 나중에 장학금과 연계된 의무근무관련된 소송으로 대기업이 졌다는 이야기도 들었던것 같은데.. 확실하지는 않지만요.

어쨌든, 일부는 올뻔했다가 안정적인 대기업을 버리고 왜 중소기업으로 가느냐는 부모님의 반대로 결국 못온 경우도 있었구요. (그당시는 지금만큼 공무원-대기업 선호가 강했던것도 아닌데 말이죠)
결국, 주로 학연으로 후배들을 설득해서 데려왔던것 같습니다. 
그당시 설득했던 논리중 하나가 "인터넷은 IT산업만이 아닌 전산업에 걸쳐 곧 혁신을 가져올것이다. 이런 상황이 일생에 자주오지는 않을테인데, SW가 아닌 HW가 주력인 대기업보다는 인터넷기업에서 젊을때 혁신의 중심에서 일해보는 의미가 있지 않겠느냐?" 였습니다.
단순한 빈말만은 아니었었고 다음에서 초창기에 같이 일한 개발자/엔지니어들이 한국의 인터넷초창기에 각자 중요한 역할들을 수행했다고 생각합니다.

이후 회사가 커지면서 개발자 구인환경은 나아졌고, 특히 코스닥에 상장후에는 (코스닥에 상장했다는것이 중요한것이 아니라) 인터넷버블시기라 풍선효과도 있었고, 또한 전국민 대다수가 이용하는 서비스이다보니 인지도도 높아져서 한때 경쟁률도 "수십 대 1" 까지 갈정도로 초기와는 수요와 공급이 달라지기도 했습니다.
일정시기에 모집하는 공채와 추천으로 수시모집하는 특채 두가지로 구인을 했었는데, 특채가 자질이 항상 좋은것은 아니지만 그래도 추천받은 사람이다 보니 평균적으로 자질이 나은편이라 상대적으로 공채에 비해 구인률은 높았던것 같습니다.

당시에 뽑은 대다수 개발자/엔지니어들은 전산과외에도 전기/전자를 비롯한 기타 공과대 출신과 수학/물리등 자연과학대 출신들, 그리고 상경대의 응용통계과 출신들이 대다수였는데, 의외로 인문대의 어학과 출신도 있긴 했었습니다.
공채에서 한 개발자경우 제가 어문과네 하고 그냥 서류심사에서 탈락시켰었는데, 그후 그친구가 추천으로 특채로 입사해서 훌륭하게 일을 했던 기억이 나네요. 
저도 위의 과출신들외에는 나름 선입견을 가지고 있었던것이죠 :)

1999년도부터 포털서비스를 하면서, 메신저 서비스등 윈도우개발자들이 필요했었는데 참 구하기가 힘들었습니다.
그당시에 이미 각대학 전산과에서는 자바와 웹기반 프로그래밍 위주로 교육이 되기 시작했었고, 그나마 윈도우즈와 Direct-X 개발 좀 하는 친구들은 게임쪽으로도 많이 빠졌기 때문이죠.
나름 희소가치가 있는 기술영역도 경쟁력을 가질수 있기에 의미가 있는데, 우리나라 특성상 역시나 주로 대세인곳에 모두 몰리는 경향이 좀 강한듯 하더군요. 어느정도 분산될 필요가 있을텐데 말이죠.
우스개 소리로 그당시 미국에서 윈도우즈 개발자는 Unix등 타 시스템에 비해 지저분한 프로그래밍을 감수해야했기에 (MS-Windows 개발 프레임워크가 제대로 안만들어졌다는것을 비꼬는것) 연봉이 타 개발자보다 더 높다는 이야기도 있었습니다.
요즘은 국내뿐만 아니라 미국도 윈도우즈 개발자 수는 줄고, 동유럽에서 주로 그쪽 개발을 맡고 있다는 이야기도 언뜻 들었습니다.

2000년대 들어서 시간이 더 지나니, 다음에 개발자/엔지니어로 지원하는 친구는 늘었지만 평균적인 실력들은 떨어지기 시작했습니다.
결국 이공계 기피현상 문제가 생태계적인 차원에서 기업에게까지 영향을 끼치기 시작한겁니다.
어느순간부터 학생들이 소위 "사"자 돌림을 준비거나 아니면 공무원시험등을 최우선적으로 준비하다 보니, 극단적으로 표현하자면 결국 성적좋은 친구들은 모두다 서울대 의대부터 지방의 잘 모르는 대학의 의대까지 모두 채운후에야 그다음 성적순으로 비로소 서울대 공대로 들어가는 것이었죠.
물론 성적 좋은 학생도 공대로 가긴 하겠지만, 기본적으로 비인기학과가 되면서 상대적으로 평균실력들이 떨어지기 시작한겁니다.
저희때 의대/전자/전산의 입학 커트라인 성적이 크게 차이가 안났던것에 비하면 큰 차이가 생긴것이죠.
그나마 전자가 나은편이고 이에비해 전산은 프로그래밍이 소위 "안좋은 신3D직업"으로 불리면서 더 인기가 떨어졌습니다.
안타까운 현실이지만 국가적인 차원의 경제-산업-교육모두가 물린 문제라 쉽게 해결은 안되겠더군요.
그 와중에도 나름 프로그래밍에 뜻을 둔 뛰어난 친구들은 있긴 했습니다만..

4) 다음에서 느낀 개발자들의 유형과 특징

* 일반화의 오류가 가장 큰 부분일수 있습니다. 요즘추세와는 다를수도 있는 주관적인 의견이니 참고하시기 바랍니다.

물론 사람마다 개인차가 큽니다만, 직업별 그리고 전공별에 따른 확률적인 특성들은 존재한다고 생각합니다. 그 안에서 또 개인차가 크기에 성급한 일반화의 오류는 위험하겠지만요.
다음이라는 한정된 범위에서 예전에 개인적으로 느낀점이지만 개발자들의 특징이라고 생각하는 부분은 다음과 같습니다.

- 타 직종에 비해 상대적으로 연봉이 1순위가 아니다
영업쪽은 제가 직접관리를 해본적은 없지만, 기획자/서비스운영자/개발자/엔지니어/디자이너등을 관리해본 경험에 기반하자면 직종별로 회사에 바라는 기대치의 우선순위가 조금씩 다르다는 것입니다.
그중 연봉이 높은것을 싫어할 사람은 아무도 없겠지만, 타 직종에 비해 개발자/엔지니어의 경우 연봉만이 1차적인 우선순위로 보이지는 않았습니다.

- 상대적으로 실리보다는 의리(?)에 강하다
그당시 벤처기업(스타트업)에 있는 개발자들을 보면 회사의 비젼도 중요하지만 일종의 의리로 다니는 경우도 꽤 되더군요.
나름 괜찮아 보이는 개발자인데 본인이 다니는 회사의 비젼은 약해보여 스카웃을 제안해도 안먹히는 경우들이 있었습니다.

- 인정받는것(?)이 중요하다.
연봉의 경우도 금액자체로서의 의미가 있다기 보다는 본인이 이정도 인정도 못받는 개발자/엔지니어 인가? 차원에서의 의미가 더 큰것 같았습니다.
즉 돈외에 본인의 능력을 인정받는 측면이 상당한 우선순위에 있다는 것이죠.

- 관리보다는 개발을 직접하는것을 더 선호한다.
개발팀장으로서 관리하는 능력과 개발을 직접 잘하는 능력은 조금 별개의 능력일수 있는데, 대부분 관리자로 승진하기보다는 개발에 더 집중하는것을 선호했었습니다.
물론 상대적으로 나이가 젊고 아직 한국사회에서 흔히 말하는 "나이가 들면 관리자가 되어야지" 라는 마인드에 덜 물들어서 일수도 있습니다만..

- 새로운 기술을 배우는것을 상당히 중요시한다.
저도 그랬듯이 새로운 기술을 배우는것은 상당히 즐거운 일이기도 합니다만, 사회에서 적절한 신기술을 익히지 못하면 도태될수 있다는 불안감도 있기 때문입니다.
저도 새로운 기술동향이나 서비스들은 지금도 틈틈히 시간날때 짬내서 보긴 합니다만, 실제 개발자가 새로운 플랫폼/언어를 단기간에 짬짬히 공부해서 습득하라는 요구는 무리수가 많죠. 공부할 시간은 별도로 어느정도 줘야합니다.

그다음에 전공별로도 약간의 특성이 존재하는것 같더군요. 당연히 개인차가 더 크며, 특정과를 띄우거나 비하하고자 하는 의도는 아니니 이해바랍니다.

- 전산과
기본적으로 프로그래밍보다는 아키텍쳐를 우선시하는 경향이 강해보입니다.
잘되면 탄탄한 아키텍쳐가 나올수 있지만, 너무 심해지면 목적이 아닌 수단인 아키텍쳐에 너무 집착할수 있습니다.

- 수학과
학창시절엔 다른 이공계에 비해 저를 포함한 전산과 친구들이 완전주의와 디버깅(TV같이 보면서 옥의티 참 잘들 잡았다는..)에 일종의 직업병이 있다고 생각했었는데, 다음에 와서 보니 수학과가 한수위더군요.
깔끔한 프로그래밍과 완전주의가 장점이고 역시 너무 심해지면 프로젝트 진도는 안나가고 역효과가 있습니다.

- 공대와 자연과학대, 응용통계학과
일반적으로 전산이 전공은 아니지만 프로그래밍이 좋아서 즐기면서 시작한 개발자들이 많습니다. 물론 먹고 살자고 시작한 개발자들도 있겠습니다만 ^^;
때론 아트적인 프로그래밍을 하는 친구들도 보입니다.

그외 다음내 개발자들만의 특성이라면 흡연율이 생각보다 그렇게 높지 않은 20~30% 수준이었고, 개인차는 있지만 회사내 타직종에 비해 술을 그렇게 많이 마시지는 않았다 정도가 되겠습니다.
면접볼때 따로 흡연여부를 묻고 뽑은것은 아닌데 생각보다 그당시 평균 흡연율보다 낮았습니다. 
한때 SI 프로젝트로 타 대기업 전산실에 파견나갔을때 마침 파견나간 개발자들중 아무도 담배를 안 피우니 그쪽 전산실장님이 그러시더군요. "아니 프로그래밍하면서 스트레스 받는데 담배도 안 피우고 무슨 낙으로 스트레스 푸나요? 우린 흡연율이 80~90%인데?"
다른 인터넷업체들의 개발자 흡연율은 몰라서 이것은 다음만의 특징인지도 모르겠네요.

여기까지 하고 4편에서 마무리하도록 하겠습니다. 그럼.