마소잡지에 좋은 글이 있더라구요_ 같이 나누고 싶어서 가져옴.  출처: www.imaso.co.kr

박경훈 hoonsbara@hotmail.com|닷넷 개발자 커뮤니티로 잘 알려진 ‘HOONS닷넷’을 8년간 운영해 왔으며, 지난 5년간 마이크로소프트의 Visual C# MVP로 활동해왔다. 10여권의 IT서적의 집필 및 번역은 물론, 기독교 극동방송에서의 라디오 진행자로 활동하기도 했다. 지금은 ‘캠든소프트’라는 벤처를 창업, 영국 내 모바일서비스를 운영 중이며, 국내에서도 모바일 서비스 런칭을 준비하고 있다.

 

글을 시작하기 전에 이 글은 필자의 지극히 개인적인 생각들과 주관적인 생각을 바탕으로 작성됐다는 점을 감안하고 읽어주면 좋겠다.

 

한국에서의 개발자

필자는 20살이라는 철없던 나이에 사회에 뛰어들어 서른 가까운 나이가 될 때까지 개발에 몰두해왔다. 다른 개발자들에 비해 대학에 진학하지 않고, 바로 일을 시작했다는 것이 조금은 이례적이라고 할 수 있겠다. 커뮤니티와 대외 활동도 많이 진행하기는 했지만 모두 개발과 관련된 일들이었다. 그래서일까. 짧지 않은 기간 동안 개발자 일을 해오며 머릿속에 갖고 있던 생각들과 목표, 그리고 미래의 방향들은 시간이 흐르면서 계속해서 변해왔다.

먼저 처음 개발 일을 시작하면서 3년차 정도가 되기까지는 그저 개발이 재미있게 느껴졌고, 배움에 대한 갈망이 컸다. 때문에 나의 미래에 대해서 구체적으로 생각해 볼 여유가 크지 않았다. 하지만 그 3년이 지나자, 그때가 돼서야 정체성에 대해서 생각해 볼 여유가 생겼다. 분명 친구들은 소위 말하는 SKY라는 타이틀을 가지고 사회에서 경쟁을 하게 될 것이 분명한데, 그에 반해 내가 가지고 있는 경력은 너무나 초라해 보였기 때문이다.

IT 프리랜서로 활동하면서 몇 년 동안 프로젝트를 진행해 본 것이 전부였던 필자는 이력서에 한줄이라도 넣을 수 있는 것들을 찾으며 수년을 보내게 됐다. 개발자 커뮤니티 운영을 시작으로 책을 쓰기도 하고, 번역을 하기도 했으며, 교육이나 세미나 행사에서 강사의 기회가 있으면 놓치지 않았다. 이러한 노력들이 결실로 다가오기 시작할 때 즈음해서 필자에게는 안정과 모험 사이에서 인생의 방향을 다시 생각해야 하는 갈림길이 다가왔다.

두 가지 도전 과제 중 하나는 먼저 해외로 나가서 외국회사에 들어가 일을 해보는 것이었다. 이민을 가고 싶었던 것 보다는 글로벌 감각을 키우고 싶은 욕심이었다. 두 번째 과제는 세계 명문 대학교에서 공부를 하고 싶다는 것이었다. 공부라고 해 봤자 고3때 누구나 다 하는 수능공부와 4년 동안 온라인으로 강의를 들으며 간신히 졸업한 사이버 대학교가 고작이었다. 그래서 필자는 지난 2009년, 그 동안 모아온 돈을 털어서 영국으로 어학연수를 떠났다.

어학연수를 떠난 이유는 바로 첫 번째와 두 번째 도전에 대한 공통분모는 바로 언어의 장벽을 허물어야 한다는 것이었다. 미국이 아닌 영국을 선택한 이유는 간단하다. 남녀 비율에서 여자 비율이 높았던 곳이 영국이었기 때문이었다. 다들 영국에는 젠틀맨이 자신을 기다리고 있을 거라는 환상과 착각으로 각국의 여자들이 영국행을 택하지 않던가. 그와 비슷한 맥락이라고 할 수 있으리라. 

 
영국과의 인연

어학연수를 가기 전까지만 하더라도 필자는 1년간 어학연수 코스를 이수하면 저절로 영어에 능숙해질 수 있을 것으로 착각했었다. 영화를 볼 때 당연히 자막 없이 볼 수 있는 정도의 어휘력이 될 줄 알았던 것이다. 하지만 1년 이라는 시간은 고작 어린 아이처럼 의사소통 정도만 가능하게 된다는 것을 알게 되었을 때 정말 수단과 방법을 가리지 않고는 시간만 낭비하게 될 것 같았다. 때문에 필자는 어떻게 하면 영어가 빨리 늘 수 있을까라는 것을 고민했고, 수단과 방법을 가리지 않고 영어를 연습했다.

영어를 하는데 있어서 가장 큰 도움을 받은 것은 매일 오후 영국인 가족이 살고 있는 이웃집에 가서 2~3시간씩 성경공부를 한 것이었다. 물론 영국에 오기 전부터 시작한 영어공부의 효과도 있었겠지만, 이 시간을 통해서 정말 빠르게 늘어나는 영어실력을 보게 됐고, 인생의 철학까지도 배울 수 있는 너무나 소중한 시간이었다. 이렇게 3개월이나 지날 즈음에 회사에 이력서를 내도 면접을 볼 수 있겠다는 자신감이 붙게 되었다.

그래서 필자는 여러 IT회사에 면접을 보게 되었고 비자문제로 정직원은 아니었지만 계약직 자리를 얻어내서 일을 시작하게 되었다. 드디어 목표했던 외국 회사의 문화를 체험해 볼 수 있는 좋은 기회가 찾아오게 된 것이다. 외국회사 문화에 대해서 하고 싶은 이야기들은 가득하지만 지면상 생략하도록 하겠다.

이렇게 시작한 영국에서의 인연은 영어뿐만 아니라 회사의 문화와 많은 인맥까지 만들 수 있었던 좋은 시간이었다. 그렇게 6개월을 근무하고 한국에 돌아오게 되었다. 그리고 다음 갈림길에서 필자는 사업을 진행할지, 대학원을 갈지 이 두 갈래 길에서 고민하다가 결국 사업을 선택하게 됐다.

당시에 지원했던 대학원과 인연이 닿지 않았던 것도 있었고 자금을 투자할 여유가 되는 동업자가 마침 다른 일 때문에 한국에 입국해 있는 상황이었다. 필자는 사업기획서를 작성해 지인을 설득했고, 동시에 당장 회사를 그만두고 사업에 바로 참여할 수 있는 주변의 개발자들을 모아서 사업을 시작하게 됐다.

이렇게 필자와 동업자들이 함께 만든 모바일 서비스는 바로 ‘AppCookr’다. 이 서비스 모델은 웹에서 사용자가 직접 앱을 개발할 수 있는 템플릿을 제공해주고 사용자 자신이 직접 만들고 싶은 앱을 원하는 대로 만들게 해준다. 그리고 배포를 요청하면 우리가 앱을 심사한 뒤에 자체적으로 개발한 자동 배포 도구를 이용해서 앱을 등록시켜주는 주는 간단한 방식으로 이뤄져있다.

수익 모델도 복잡하지 않았다. 앱을 만들기 위해서 최소 3,000만원에서 몇 억 이상의 돈을 거액을 지불해야 하는데 우리의 서비스는 템플릿이 제한되어있는 반면 500파운드(한화 약 100만원)라는 경쟁력 있는 금액을 통해서 앱을 제공해주는 방식을 선택했다.

<화면 1> 2010년 10월에 오픈한 AppCookr 서비스, 한국에도 2011년 1월에 정식 서비스 될 예정이다.

사업을 진행하기로 결정하고 난 뒤에는 비즈니스와 수익 모델에 대한 큰 그림을 그렸다. 그 뒤에는 어디서 서비스를 시작할지 정해야 했다. 하지만 고민할 것도 없이 바로 영국 시장의 문을 먼저 두드려 보기로 결정했다.

왜 영국을 먼저 타깃으로 잡았는가. 가장 큰 이유는 서비스가 해외 정서를 고려하지 않은 채 만들어지는 것을 막아보자는 데 있었다.

싸이월드도 미국에서 시작한 페이스북이나 마이스페이스보다 더 먼저 국내에서 성공한 SNS 서비스였지만 결국 세계의 벽을 넘지 못했다. 싸이월드가 해외에서 자리를 잡을 수 없었던 이유가 바로 ‘세계 정서를 고려하지 않게 설계되어 있다’는 의견이 대부분이었기 때문이다.

두 번째 이유는 한국에서는 보다 안정된 서비스를 선보이고 싶었다. 국내 시장은 확실히 준비만 되면 이 서비스는 확실히 성공할 수 있다는 자신감이 있었다. 그만큼 이미 시행착오를 거쳐서 잘 다듬어진 서비스를 오픈하고 싶었던 이유가 컸던 것이다.

세 번째 이유로 영국에는 이미 다져진 네트워크가 있었다. 마냥 황폐한 황무지가 아니었다는 점에서 망설임 없이 미국이 아닌 영국을 선택했던 것이다. 그리고 영국에서 서비스가 성공하게 되면 유럽 전역으로 서비스가 자연스럽게 확장되어 간다는 것이 거의 공식이었다. 그리고 마지막 이유는 한국에서 사업을 시작하게 되면 결코 해외로 눈을 돌리기가 결코 쉽지 않을 것이 분명했기 때문이다. 한국에서는 다른 서비스를 카피해서 새로운 서비스를 오픈하는 것이 결코 어려운 일이 아니다. 
 

영국의 IT와 모바일

필자가 영국을 접했을 때 여기는 분명 기회의 땅이 될 수 있다고 생각했다. 왜냐하면 한국에 비해서 IT 인프라가 너무 열악하다는 점 때문이었다. 예를 들면, 부동산과 같은 오피스를 운영하는 곳은 자체 프로그램이 아닌 엑셀을 이용하고 있을 뿐만 아니라 좋은 레스토랑에 가더라도 POS시스템을 이용하는 곳은 거의 없었다. 그래서 필자는 영국에서는 어떤 IT 사업을 하더라도 성공할 수 있겠다는 자신감을 가졌다.

하지만 영국은 하나의 서비스를 개발한다고 하더라도 정말 높은 품질로 확실하게 만드는 것이 한국과 다른 큰 차이점이다. 가장 감탄한 것이 영국 버스검색 서비스다.

국내 서울의 버스 검색 사이트는 사이트자체가 무거울 뿐더러 원하는 목적지를 찾는 UI 자체도 굉장히 복잡하다. 하지만 영국의 버스 검색 사이트는 정말 군더더기 없는 UI로 원하는 기능을 정확하게 제공해 주고 있었다. 단순히 출발지와 목적지를 검색해서 입력하게 되면 가지고 있는 경우의 수의 루트를 찾아서 보여주게 되는 것이다.

<화면 2> 영국의 버스 검색 서비스

한국은 굉장히 다양한 IT 기업들이 존재하고 있으며 그 서비스의 양도 엄청나다. 하지만 각 서비스를 이용하는데 있어서 만족도나 퀄리티는 떨어지기 마련이다. 반면에 영국 서비스는 다양하지는 않지만 제공되고 있는 서비스가 만족도가 굉장히 높고 그 퀄리티도 뛰어난 것이 큰 차이점이다. 

이런 차이가 나는 이유는 간단하다. 국내는 초급개발자가 많다. 한국의 개발 팀을 살펴보면 10년차 정도 되는 개발자가 개발을 주도하고 그 아래 개발자들은 모두 2~3년차 정도 되는 초급자가 팀을 이루는 구조가 일반화 되어있다. 그러나 영국은 기본 7년이 넘어가는 고급 개발자의 비중이 높다.

이외에도 영국에서 아이폰의 위상은 다른 나라보다 대단했다. 스마트폰 점유율을 보면 당연히 전세계 사용률처럼 노키아가 1위를 차지하고 있지만, 다른 나라보다 아이폰의 사용률이 높았다. 무엇보다도 굉장히 보수적인 영국 사람들이 그만큼 선택했다는 것에서 많은 점수를 줘야 할 것이다.

영국은 앞에서 언급했던 것처럼 IT 인프라가 좋지 못하다. 지하철 안에는 기지국이 설치되어 있지 않기 때문에 3G 인터넷은 커녕 전화를 받는 것조차 힘든 것이 사실이다. 그렇기 때문에 아이폰 앱들의 다운로드 순위가 우리나라와 상당히 다르다는 것을 느낄 수 있다. 우리나라는 주로 IT 서비스 관련 앱들은 주로 상위권을 차지하고 있는 반면 영국은 게임 앱들이 많이 차지하고 있었다. 우리나라처럼 네이트, 네이버, 다음과 같은 다양한 서비스가 존재하지 않았고 또한 좋지 못한 통신망 때문이기도 했다.

필자는 이렇게 IT 인프라가 황폐한 땅인 만큼 충분히 경쟁력이 있을 거라고 생각했다. 하지만 시간이 흐르며 들었던 의구심은 오히려 사람들이 IT에 관심이 없어서 이렇게 된 것은 아닐까라는 생각이었다. 왜냐하면 런던만 보더라도 주변에 항상 공원이 있고 그들의 여가활동은 컴퓨터와 같은 디지털이 아닌 공원에서 운동을 하거나 가족들과 쉼을 나누는 것이 그들의 문화였기 때문이다.

 

보수적인 영국 문화의 벽

영국서 필자는 서비스기획과 아이폰 개발 분야, 그리고 전체적인 일정관리 부분에 대해 진행했다.

서비스 목표와 비즈니스 프로세스가 어느 정도 분명했기 때문일까. 3개월 정도 지나자, 서비스에 대한 전반적인 윤곽이 나타나기 시작했다. 그리고 비로소 마케팅과 영업에 대한 고민이 시작되었다. 무엇보다도 우리 서비스를 통해서 만들어진 인지도 있는 기업의 사례들이 필요했다. 어떤 쇼케이스 없이 이 보수적인 문화가 팽배한 영국에서 신뢰를 챙겨가기가 힘들기 때문이다.

그래서 먼저 섭외할 10개의 기업들을 뽑아 리스팅했다. 리스팅 우선순위로는 이미 만든 앱이 없고, 우리 템플릿이 가지고 있는 기능을 최대한 활용할 수 있는 RSS나 트위터, 맵과 같은 데이터를 가지고 있는 기업들이 1순위였다.

다양한 사례를 만들어야 했기에 다양한 분야의 기업들을 리스팅 했다. 그 당시 대표적인 타깃 기업으로는 런던에서 가장 인기있는 맘마미아 뮤지컬 극장과 Zdnet, TechEye와 같은 영국의 IT미디어 기업들과 스코틀랜드의 에딘버러 페스티벌 등이 대표적인 예다. 

우리는 이 기업들의 홈페이지에서 제공하는 RSS, 트위터, 플리커 등의 데이터들을 바탕으로 앱을 직접 제작했다. 이렇게 이미 제공하고 있는 데이터들만 있으면 자동으로 앱을 생성할 수 있기 때문에 만드는 것은 어렵지 않았다. 그것보다는 어떻게 이 기업들을 만나 승인을 받아내야 할지 고민이었다. 

먼저, 기업 담당자를 찾아가기 전에 회사 메일을 통해서 제안을 하기로 결정했다. 우리가 만든 앱을 보여줄 방법이 메일로는 마땅한 방법이 없었기 때문에 선택한 방식은 결국 동영상 제작이었다. 동영상으로 동작되는 화면을 찍었고 유튜브에 업로드해 그 링크를 공유했다. 물론, 기대를 가지고 메일을 보내지는 않았다. 그 메일을 열어 볼 확률은 반도 되지 않을 것이라는 것도 예상했고, 또 열어본다 하더라도 적절한 업무 담당자에게 전달될 확률도 크지 않을 것이라고 생각했기 때문이다. 그래도 형식상 방문 전에 메일을 보내서 제안을 시도하는 것이 도리라 생각되어 진행한 일이었다.

역시 예상대로 전화가 온다거나 회신이 오지는 않았다. 이 일을 진행하는데 있어서 가장 심사숙고한 부분이 바로 영어였다. 폼나는 글귀를 이용해서 특정 기업에게 제안 메일을 보내도 쉽지 않을 터인데 어리숙한 문장을 이용한다면 당연히 신뢰가 생기지 않을 것이기 때문이었다.

예를 들면 이런 것이다. ‘제안’이라는 표현은 영어에서 무수하다. Suggestion, Offer, Proposal등 여기서 비즈니스적인 제안의 경우 당연히 Proposal을 써야 한다. 하지만 세컨드 랭귀지로 영어를 접했던 사람은 문장에 있어서 어떤 단어가 혹은 어떤 문장이 보다 포멀한지 구분하기 힘든 것이 사실이다. 그래서 현지 직원을 구하기 전까지 주변의 지인을 통해서 확인을 받아서 진행해야만 했다.

그렇게 메일을 보내고 일주일이 지나서 필자는 직접 회사에 찾아가기로 결정했다. 먼저 첫 번째 방문에서는 비즈니스 제안 문서를 만들어서 마케팅 매니저에게 전달하는 것이 첫 번째 목표였다.

물론 같이 이야기도 나누고 싶었지만 선약이 있었던 것도 아니고 불쑥 찾아가는 것이기 때문에 매니저 연락처나 이름을 알아내는 것으로 첫 번째 성과라고 생각했다. 찾아갈 회사들이 모두 런던에만 있었던 것은 아니었다. 그래서 1차적으로는 런던에 있는 회사들만 찾아가서 문서를 전달했다. 이때 방문했던 회사들은 담당자와 선약이 없었기 때문에 로비에서 직접 마케팅 매니저를 직접 연결시켜 주지 않았다. 대신 문서를 전달해 달라고 부탁을 했고 몇 군데 기업에서 매니저의 이름과 연락처를 알아내는 정도로 만족을 해야 했다.

 

<화면 3>  당시 쇼케이스를 위해서 찍어낸 앱들

그리고 일주일이 지났다. 이번에는 내심 작은 기대 정도는 가지고 있었지만 연락이 없었다. 그 뒤에 회사를 재 방문하기로 결정하고 이번에는 추가로 동작되는 앱의 화면을 담은 동영상을 CD로 만들어서 전달했다.

이번 2차 방문에서 역시 큰 수확은 없었지만 이번에는 맘마미아라는 뮤지컬 극단 마케팅 매니저와 미팅을 바로 할 수 있었다. 여기서 회의를 통해서 알게 된 사실이 있었다. 영국 기업들의 입장에서는 지금 우리 회사를 신뢰할 수 없다는 것이다. 왜냐하면 그 당시의 AppCookr 서비스는 베타 수준이었을 뿐더러 보여줄만한 다른 포트폴리오를 가지고 있던 회사도 아니었다. 그리고 가장 중요한 것은 영국에서 연혁이 오래된 회사도 아니었고 그저 한국에서 건너온 미지의 작은 회사였던 것이다.

그리고 돌아와서 한번 기업의 입장에서 생각을 해봤다. 내가 기업주이고 외국인 두 명이 찾아와서 앱을 무료로 만들어 주겠다고 하면, 당연히 의심부터 시작할 것이다. 더군다나 영국은 보수적인 문화로 정평이 나있는 곳이었다. 그래서 그 뒤로 방향을 조금 수정했다. 먼저 서비스를 보다 완벽하게 오픈하고 회사 홈페이지도 잘 갖추고 나서 다시 한번 제안을 넣어 보기로 한 것이다.

그렇게 또다시 한 두 달이 지나서 AppCookr 서비스의 방문자도 늘어갔고 우리 서비스로 만들어진 앱들도 늘어나기 시작했다.

입소문을 통해서 퍼져나가서 어느새 트위터의 팔로우 수도 1800명이 넘어가고 있었으며, 베타 서비스때 없었던 회사 홈페이지도 갖춰졌다. 이처럼 차츰 영국 내에서 서비스 인지도가 쌓여갈 무렵, 다시금 생각하지 못한 열매들을 거두기 시작했다. 바로 3개월 전에 방문해도 꼼짝도 안하던 기업들이 AppCookr의 신뢰가 어느정도 쌓이자 다시 제안을 넣어 달라는 연락이 온 것이었다.

영국뿐만 아니라 해외의 문화가 그렇다. ‘스피드’를 중시하는 한국 문화와는 다르게 작은 비즈니스 계약을 체결한다 하더라도 정말 신중하게 생각하고 최대한의 여유를 가지고 의사결정을 한다는 점이다.

그렇기 때문에 보수적인 마인드가 강제되기도 하고 신뢰 없이는 결코 움직일 수 없게 된다. 번외적인 이야기이지만 영국은 다른 것보다 미술로 잘 알려져 있고, 많은 학생들이 미술을 전공하러 많이 찾는 나라다. 재미있는 것은 유명한 영국의 미술가가 한국에서 인정받았던 한국인의 작품을 보고 이런 말을 했다고 한다.

 

“이 작품은 훌륭하지만 ‘여유’가 느껴지지 않는다”

 

이 말은 필자가 영국에서 사업을 진행하며 철저히 훈련받은 부분은 아무리 유리한 조건의 “딜”이 있다고 하더라도 충분히 검토해보고 진행할 수 있는 ‘여유’가 필요하다는 것을 느께게 하는 말이었다.


신고
Creative Commons License
Creative Commons License
Posted by 준환이형님

댓글을 달아 주세요

사로자바님의 권유로 마소홈피에 출근 도장을 찍게 되었지요..; 좋은 글이 있어서 포스팅 해 봅니다. 


IT 벤처 붐이 일었던 시절이 벌써 10년여 전이다. 끝없는 성공으로 이어질 것 같았던 벤처붐의 열기가 식은 후, 프로그래머라는 직업에는 ‘3D 직종’이라는 이름표가 붙었다. 필자는 이러한 현상이 벤처 붐이 일어나기 전에는 ‘프로그래머’만의 일이었던 프로그래밍이, 단순히 노동력을 투자하면 좋은 프로그램이 빠르고 많이 생산될 것이라는 잘못된 발상에서 유래된 것이라고 생각한다. 이러한 현실 속에서 누군가는 세상을 탓하며 이 분야를 떠났고, 또 다른 누군가는 남아서 새로운 성공을 꿈꾸고 있다. 지금 이 글을 읽고 있는 여러분들은 분명 후자일 것이리라. 그럼 또 다른 성공을 위해 필요한 것은 무엇일까?


권용휘 rodream@gmail.com | http://rodream.net에서 악성코드 제거기 울타리와 컴퓨터 최적화 프로그램인 클릭 투 트윅을 배포하고 있다. 2008년부터 Visual C++ 분야에서 Microsoft MVP로 활동하고 있으며 데브피아 Visual C++ 분야의 시삽을 맡고 있다.

3D 프로그래머의 역사
벤처 붐이 일어난 지도 어언 10년이 지났다. 그동안 프로그래머라는 직업은 많은 사람들에게 기피 직종 중의 하나가 되었다. 하지만 이러한 프로그래머가 처음부터 3D 직종으로 사람들에게 인식된 것은 아니었다. 벤처 붐이 한창이던 그 시절에는, 프로그래머라고 하면 ‘젊고 촉망되는 사업가’ 또는 ‘창의적인 발명가’의 이미지가 강했다. 그러나 이러한 이미지가 부정적으로 바뀌는 데에는 프로그래밍에 대한 업무적 이해가 없는 기업과 정부가 적지 않은 역할(?)을 했다. 프로그래밍이라는 일을 단순히 사람을 많이 쓰고, 야근을 해서 시간만 많이 늘린다면, 좋은 프로그램이 빠르게 개발될 것이라는 생각을 가진 기업들이 늘어나면서, 프로그래머를 창의적인 일을 하는 사람이 아니라 단순하고 반복적인 노동을 하는 인력으로 생각하게끔 만들었다. 또한, 정부 정책들도 핵심 기술을 진흥하고 발전시켜 나가는 것이 아니라, 단순히 규모만 큰 IT 업계를 만드는 것에 일조했다. 각 업무 특성에 맞는 인력 평가 시스템이 아니라 실제 업무에 연관성이 낮은 자격증이나 근무 시간만으로 인력을 평가하는 비논리적인 시스템으로 프로그래머라는 직종이 올바르게 대한민국에 정착하지 못하게 만든 것이다.
지금은 예전보다는 잘못된 인식을 가진 회사들이 줄어들었다. 이는 인식이 바뀐 이유도 있겠지만, 더 큰 이유는 프로그래머들이 자진해서 그러한 회사를 떠났기 때문이다. 지금으로부터 딱 1년 전, 2009년 여름을 가장 뜨겁게 장식했던 모 기업의 제품 발표회에서 그 회사 관계자가 그 제품을 만드는 과정에서 자사 직원들의 무수한 야근이 있었고 심지어 어떤 직원들은 이러한 야근으로 인해 이혼까지 했다는 것을 자랑스럽게 발표한 적이 있다. 이는 매우 부끄러운 사실이지만, 이를 부끄럽게 여기지 않는 우리 개발 환경의 현주소는 더 심각하게 느껴졌다. 이렇게 아직까지도 프로그래머에 대한 인식은 바닥을 치고 올라올 줄 모른다. 이러한 악조건 속에서 필자는 이 글을 읽고 있는 여러분들이야말로, 이러한 3D 프로그래머의 역사에 종지부를 찍을 수 있는 프로그래머가 되어야 한다고 생각한다. 여기서 필자가 적은 ‘되어야’ 한다는 것의 의미는 두 가지다. 먼저, 이렇게 단순 잡부(?)로 취급받지 않을 만한 실력을 갖춰야 한다. 다음으로는 그러한 실력을 가지고 자기 혼자만 잘 살 것이 아니라, 모든 프로그래머들이 더 좋은 환경에서 프로그램을 만들 수 있도록, 자신의 지식을 나눠주고 함께 발전해 나가는 프로그래머가 되어야 한다고 생각한다.

실력 있는 프로그래머
앞서 언급한 것과 같이, 실력 있는 프로그래머가 되려면 어떻게 해야 할까? 대답은 매우 간단하다. 실력을 쌓기 위해서는 자기 계발에 충실하면 된다. 하지만 역시 앞서 언급한 대로, 프로그래머에게는 자기 계발에 들이는 시간이 사치라고 느끼는 사람들이 많다. 구글의 전 직원들에게 주어진다는 한 시간의 자기 계발 시간이 각종 언론에 대서특필 된 것을 보면 알 수 있다. 하지만, 결코 하루 한 시간의 자기 계발 시간은 마음씨 좋은 회사가 베풀어야만 생기는 것은 아니다. 구글에서 이러한 제도를 시행하는 것 자체도, 구글의 경영진 입장에서는 좋은 프로그래머를 사용하고 그러한 좋은 인력을 지속적으로 좋은 상태로 유지하기 위해서는 하루 한 시간의 자기 계발 시간이 필수적이라는 생각에서 비롯됐다. 또한 이러한 자기 계발 시간으로 인해 줄어드는 근무 시간이 실제로 업무에 큰 영향을 미치기보다는, 오히려 앞서 말한 자기 계발로 인한 직원들의 능력 향상이 이러한 물리적인 업무 시간의 감소보다 더 큰 이점을 가져온다는 결론에 이르렀을 것이다.

필자가 생각하는 실력 있는 프로그래머는 이러한 자기 계발 시간을 스스로 만들어 낼 수 있어야 한다. 또한 이렇게 만들어 낸 자기 계발 시간에 충실해 더 실력 있는 프로그래머가 될 수 있어야 할 것이다. 물론 자기 계발 시간을 확보하기 위해 일을 하지 말라고 하는 것은 아니다. 이번 8월호 커버스토리의 제목과 같이, 필자가 생각하는 가장 좋은 방법은 효율적으로 일하는 것이다. 대한민국의 수많은 프로그래머들 중에서 스스로 효율적으로 일하고 있다고 생각하는 이는 얼마나 될까? 아직 정확한 통계자료는 나오지 않았지만, 아마도 그리 많은 숫자는 아닐 것이라고 생각한다. 부족한 개발 일정, 시시각각 바뀌는 요구사항, 무능한 프로젝트 관리자의 관리 부실, 기록도 남아 있지 않은 오래된 프로그램에 대한 고객 클레임, 그리고 프로젝트 진행 중에 들어오는 다른 프로젝트의 유지보수 요청. 앞에서 열거한 이러한 것들이 현실의 프로그래머가 처한 환경이다. 이런 것들이 없는 회사라면 하루에 1시간 정도가 아니라, 2~3시간 이상도 자기 계발에 투자할 수 있다. 또한 그런 것들은 회사의 입장에서도 또 다른 추가 수익을 불러오는 요소가 아니라 단순히 유지하기 위한 수단일 뿐이므로 아예 발생하지 않는 것이 이롭다. 예를 들면, 항상 문제가 생겨서 그것을 해결하고 있는 회사보다는 애초에 문제가 생길 것도 없이 좋은 프로그램을 만들어서 직원들이 자기 계발에 시간을 투자하는 회사가 더욱 좋은 회사이며 고객들도 그렇게 느낄 것이다. 그렇다면 이러한 여러 가지 문제들을 해결하기 위해서는 어떻게 해야 할까? 이제부터 소개할 내용이 바로 이러한 문제들을 효율적으로 해결하기 위한 방법들이다.
 
사회적인 해결 방법
프로그래머 또한 사회의 한 구성원이기 때문에 가장 근본적이고 큰 문제는 사람과 사람 사이의 갈등일 수밖에 없다. 특히 관리자와 실무자의 갈등이 이러한 나쁜 작업 환경을 만드는 가장 큰 원인이라고 할 수 있는데, 대부분의 회사들이 관리자만 해당 프로젝트의 내용을 알고, 실무자는 그러한 내용을 알리지 않게 하는 제도를 가지고 있다. 이러한 정보의 비대칭성은 결과적으로 관리자가 생각하는 최종 소프트웨어와 실무자가 만들어낸 최종 소프트웨어와의 차이를 더 늘리게 된다. 결과적으로, 프로그램을 다시 원래의 요구사항에 맞추기 위해서 불필요한 수정 작업이 늘어나게 된다. 한때 유명했던 만화인 ‘프로젝트가 실제로 진행되는 과정’(How Projects Really Works, http://www.projectcartoon.com/cartoon/2)에 보면, 실제로 고객이 원했던 내용과 최초의 고객이 설명했던 내용 자체도 큰 차이가 있는 것을 알 수 있다. 이러한 차이점들은 관리자와 실무자 간의 의사소통이 제대로 되지 않는다면 기하급수적으로 커지게 된다. 결국, 이렇게 의사소통을 제대로 하지 못한 상황에서 수많은 시간 동안 고생해 만든 제품은 고객도, 관리자도, 실무자도 만족하지 못한 결과물로 나올 뿐이다. 물론 어떠한 관리자나 고객도 만족시킬 수 있는 이상적인 프로그램을 만들 수도 있겠지만, 그러기에는 실질적으로는 시간이 부족하다. 앞서 언급한 내용들은 일반적인 솔루션 소프트웨어를 만드는 경우를 중심으로 이야기한 것이다. 하지만 이보다 더 악조건인 환경에서 근무하는 SI(System Integration) 업계의 이야기를 빼놓을 수는 없다. 사실 SI라고 하는 것이 무조건 야근하고 죽을지 살지 모르게 일을 해야 하는 직종은 아니다. 다만 대한민국에서 특히 SI 업계가 더 힘든 이유는 그 이름에서도 알 수 있듯이, 시스템 통합을 해야 하기 때문이다. 의사소통을 통한 효율적인 문제 해결이라는 것에 대해 다소 보수적인 한국사회가 SI 업계를 더 힘들게 만드는 것이다. 필자가 SI 프로젝트를 진행하는 과정에서 가장 크게 문제라고 느낀 것은 대부분의 SI 프로그래머들이 현재 자신이 하고 있는 프로젝트의 위치와 중요성을 파악하지 못하고 있다는 것이다. 그렇기 때문에 어떤 일을 끝내도 항상 남은 일이 있는 SI 업계에서 더 이상 버티지 못하고 나오게 되는 것이다. SI 프로젝트를 진행하고 있는 프로젝트의 실무자는 해당 프로젝트의 전체 그림과 회사가 하고 있는 여러 가지 프로젝트들에 대한 전체적인 그림을 그리는 것이 중요하다. 어떤 것이 중요하고 어떤 것이 중요하지 않은지를 파악해 회사의 비전과 생각에 맞는 일의 자체 스케줄링이 필요하다는 것이다. 혹자는 이를 대한민국의 SI 업계가 조건이 극악한 탓에 해야 하는 편법이라고 생각할지 모르지만, 이는 회사를 경영하는 이의 입장에서는 항상 직원들이 가지길 원하는 좋은 조건이며, 어느 사회에서건 실력 있는 자로 인정받고 살아남기 위해서는 반드시 해야 하는 일 중 하나다. 간혹 이러한 사람들을 자신만 편하자고 하는 기회주의자나 이기주의자라고 생각하는 사람들도 있지만, 사실은 이렇게 강약 있게 목표에 맞춰서 일하는 사람이야말로 어디에서나 필요한 고급 인재다. 앞서 프로그래머 스스로가 바꿔야 하는 여러 가지 것들을 알아보았지만 회사 자체에 대한 것들은 알아보지 않았다. 그 이유는 현실적으로 회사를 바꾸는 것보다 스스로 더 나은 회사를 찾아가는 것이 좋기 때문이다. 어느 그룹이건 문제가 있는 그룹은 항상 존재하는 법이기 때문에 모든 상황을 좋게 해결하는 것보다는, 다소 수동적인 자세로 보일 수 있지만 ‘절이 싫으면 중이 떠나는’ 방법이 더 현실적으로 현명한 방법이다. 그렇다면 중요한 것 중 하나인 ‘언제 절을 떠나면 되는가’라는 문제가 남는다. 이는 간략하게 이야기하면, 본인 스스로 효율적인 프로그래밍을 한다는 가정 하에 본인에게 도움이 되지 않는 환경이라고 생각되는 회사라면 떠나야 한다. 이러한 자신의 뚜렷한 기준 없이, 회사가 힘들다고 이직만을 고려하는 사람들도 있다. 물론 힘들면 회사를 옮기고 좀 더 좋은 길을 찾아가는 것은 개인이 추구해야 할 일이고, 그것에 대해 어떠한 나쁜 말도 할 수 없겠지만, 필자가 여기서 꼭 이야기하고 싶은 것은 과연 그렇게 힘든 회사를 만든 것이 바로 나 자신이 아니었을까라는 생각과 반성은 반드시 필요하다는 것이다. 또한 이직한다고 해서 모든 것이 해결되는 것은 아니다. 모든 환경이 완벽하게 좋은 회사는 찾기 힘들기 때문에, 어느 정도 문제가 있는 것들을 스스로 제어할 수 있는 사람이 되어야 원활하게 업무를 처리할 수 있다.

기술적인 해결 방법
지금까지 기술적이지 않은 측면에서의 문제 해결 방법들을 얘기했다. 하지만 프로그래머라는 직업의 특성상, 이러한 것들만 가지고 모든 문제를 해결하는 것은 사실상 어렵다. 앞서 언급한 것처럼 기술적으로도 우수한 프로그래머가 되어야 스케줄링과 같은 것들을 제대로 할 수 있기 때문이다. 회사에서 기술이 필요한 여러 가지 분야가 있겠지만, 필자가 가장 강조하고 싶은 부분은 바로 기술적으로 일을 많이 만들지 않는 프로그래머가 되는 것이다. 생각보다 많은 프로그래머들이 단순히 일을 많이 하게 되면 모든 것이 해결될 것으로 생각한다. 하지만 단순히 일을 많이 하는 것은 오히려 문제만 크게 만들 수 있다. 가장 무서운 사람이 바로 ‘무식하고 부지런한’ 사람이기 때문이다. 많은 프로그래머들이 생각하고 동의하기도 하는 ‘일단 지금 돌아가면 끝이다’라는 생각은 항상 시간이 부족한 프로그래머들에게 어쩔 수 없는 현실적인 선택처럼 보이지만, 실상은 오히려 그러한 것들 때문에 프로그래머들이 아주 오래된 프로그램의 버그를 고치게 되고, 예상치 못한 고객 클레임을 처리하면서 정작 중요한 프로젝트를 진행하지 못하는 결과를 초래한다. 또한 특정 운영체제에서만 잘 돌아가면 된다는 생각도 큰 문제다. 프로그램이 완성되는 시기나 완성도에 따라서 초기의 플랫폼 지원 계획은 바뀔 수 있고, 그러한 것이 빈번하기 때문에 특정 운영체제에서만 동작하는 프로젝트라고 할지라도 반드시 다른 운영체제를 염두에 둬야 한다. 또한 MSDN에 있는 내용을 충실히 지켜서 프로그램을 만든다면 특별히 많은 작업 없이 대부분의 운영체제에서 잘 동작하는 프로그램을 만들 수 있으므로, 특별한 기능이 없는 데에도 불구하고 특정 운영체제에서만 잘 동작하는 프로그램이라면 사실 그 프로그램은 잘 동작하는 것으로 알고 있는 운영체제에서도 불안정하게 동작하고 있을지도 모른다. 마지막으로 가장 중요한 내용이 남아 있다. 바로 Sleep과 MessageBox, OutputDebugString과 같은 로그 관련 함수들이다. 간혹 매우 해결하기 어려운 난제들을 접할 때 어떤 프로그래머들은 Sleep과 MessageBox, OutputDebugString을 코드에 추가했더니 문제가 사라졌다고 말하곤 한다. 하지만 원칙적으로 보면 이러한 것들이 문제를 해결해 주는 경우는 드물다. 특히 OutputDebugString과 같은 로그를 남기는 함수들은 로그를 쓰는 작업을 해야 하기 때문에 더 많은 문제를 생성해 낼 뿐이다.

효율적인 프로그래밍을 위한 지식 - API함수
API(Application Programming Interface)는 효율적인 프로그래밍을 하기 위한 가장 기본적인 지식이다. 모든 애플리케이션은 API를 사용해 시스템과 통신하기 때문에 API의 중요성은 굳이 강조하지 않아도 될 만큼 많은 사람들이 알고 있다. 하지만 그렇다고 해서 그런 모든 사람들이 API를 심각하게 생각하고 있는 것은 아니다. 가장 큰 예로 WinExec 함수를 들 수 있다. 이름에서 알 수 있듯이 이 함수는 다른 프로그램을 실행시키는 함수이다. 대부분의 프로그래머가 여기까지만 알고 있을 뿐 이 함수가 정확하게 어떻게 동작하는지는 잘 모르는 경우가 많다. 특히 이 함수가 언제 정확히 반환하는지에 대해서는 다소 의견이 분분하다. 어떤 사람들은 이 함수가 프로그램의 실행을 요청하자마자 반환한다고 생각한다. 또 다른 사람들은 이 함수가 프로그램을 실행시킨 후, Focus를 받은 직후에 반환한다고 생각한다. 실제로 이 함수를 실행시켜 보면 프로그램 실행이 된 직후에도 반환되지 않는데, 이를 보면 마치 이 함수가 Focus를 받은 직후에 반환하는 것처럼 생각될 수도 있다. 하지만 실제로 이 함수가 반환되는 시점은 다음과 같이 MSDN에 정의되어 있다.

[WinExec 함수가 반환되는 시점]
The WinExec function returns when the started process calls the GetMessage function or a time-out limit is reached. To avoid waiting for the time out delay, call the GetMessage function as soon as possible in any process started by a call to WinExec.

즉, GetMessage 함수가 호출되거나 정해진 시간 이상이 지난 경우에 반환된다는 설명이다. WinExec 함수를 사용자 인터페이스(User Interface)가 없는 프로그램을 실행하는 데 사용하게 되면, 함수가 반환되지 않는 문제가 발생할 수 있다. 사용자 인터페이스가 없는 프로그램은 GetMessage를 사용할 필요가 없기 때문이다. 하지만 이렇게 WinExec가 GetMessage 함수와 관련되어 있다는 사실을 모른다면 이러한 문제를 해결하는 데 많은 시간이 걸릴 수 있다.

또 하나의 좋은 예는 FindWindow 함수다. 이 함수는 주로 다른 프로그램의 HWND를 얻거나 다른 프로그램의 유무를 확인하고 싶은 경우에 많이 사용된다. 이 함수는 매우 많은 프로그래머들이 사용하는 함수 중 하나이며 사용법도 매우 간단하다. 하지만 이 함수가 잠정적으로 문제를 일으킬 수 있다는 사실은 잘 알려져 있지 않다. FindWindow의 문제점은 사실 그 함수 자체가 아니라 FindWindow 내부에서 사용하는 GetWindowText 함수다. 이 함수는 단순히 지정된 창 또는 컨트롤의 Text를 가져오는 작업을 하지만, 실제 내용은 다소 복잡하다. MSDN의 해당 함수에 대한 설명에는 다음과 같은 내용이 있다.

[MSDN의 FindWindow 함수에 대한 설명 중 일부]
If the lpWindowName parameter is not NULL, FindWindow calls the GetWindowText function to retrieve the window name for comparison. For a description of a potential problem that can arise, see the Remarks for GetWindowText

즉, FindWindow 함수는 GetWindowText 함수를 호출하기 때문에 GetWindowText에 있는 내부적인 문제가 함께 발생할 수 있다. MSDN의 내용 중에서는 이렇게 특정 Remarks를 언급하는 내용은 많지 않으므로, 이러한 내용은 반드시 주의 깊게 살펴봐야 한다.

[GetWindowText의 Remarks 부분]
If the target window is owned by the current process, GetWindowText causes a WM_GETTEXT message to be sent to the specified window or control. If the target window is owned by another process and has a caption, GetWindowText retrieves the window caption text. If the window does not have a caption, the return value is a null string. This behavior is by design. It allows applications to call GetWindowText without becoming unresponsive if the process that owns the target window is not responding. However, if the target window is not responding and it belongs to the calling application, GetWindowText will cause the calling application to become unresponsive.

위의 내용을 다시 정리하면 다음과 같다.

[GetWindowText의 Remarks 부분에 대한 정리]
(1) 찾고자 하는 창 또는 컨트롤이 코드가 실행되는 프로세스와 같은 프로세스에 존재한다면, GetWindowText 함수는 WM_GETTEXT를 해당 창 또는 컨트롤에 보내 값을 얻어온다.
(2) 찾고자 하는 창이나 컨트롤이 코드가 실행되는 프로세스에 없다면, 메시지를 보내지 않고 창 또는 컨트롤의 이름이 저장되어 있는 데이터에서 직접 값을 얻어온다.
(3) 창 또는 컨트롤이 이름을 가지지 않는 경우에는 빈 문자열을 반환하며, 이는 의도된 결과다. 즉, 버그가 아니다.
(4) (2)의 내용은 GetWindowText를 호출한 프로세스가 다른 프로세스가 WM_GETTEXT에 대해 응답하지 않음으로 인해 발생할 수 있는 응답 없음 상태를 초래하지 않게 하기 위함이다. 하지만 창 또는 컨트롤이 코드가 실행되는 프로세스에 존재하며 해당 컨트롤이 반응하지 않는다면 해당 프로그램은 응답 없음 상태가 될 수 있다.

하지만 위의 내용을 가지고도 언제 이것이 문제가 되는지를 명확하게 파악하기는 쉽지 않다. 실제로 이것이 문제가 되는 경우는 (4)번의 내용과 다른 프로세스에 코드를 주입하는 DLL Injection과 같은 기능을 사용하는 상황이다. 윈도우98에서 모든 시스템 프로세스에 DLL Injection을 사용하는 경우, 해당 DLL 안에서 FindWindow를 호출하게 되면 (4)의 시나리오가 발생할 수 있다. 여기서 공교롭게도 Kernel 프로세스가 가지고 있는 어떤 한 창이 메시지에 대해 응답하지 않는 경우가 있다. 결국, 이러한 문제들은 윈도우98 시스템 자체가 정지하게 만드는 큰 문제를 발생시키게 된다. 이런 문제를 해결하기 위해서는 GetWindowText 대신 직접 SendMessageTimeout과 같은 함수를 사용한 FindWindow와 관련된 함수를 만들어야 한다.

효율적인 프로그래밍을 위한 지식: 언어 자체에 대한 이해
프로그램을 작성하는 최종 단계는 프로그래밍 언어로 자신의 생각을 표현하는 것이므로, 언어를 이해하는 것은 매우 중요하다. 설계나 비전 공유가 잘 된 팀이라고 할지라도 실제 구현 자체에서 문제가 생기면 결과물이 나올 수 없기 때문이다. 그렇기 때문에 언어 자체에 대한 이해, 특히 잘 놓치기 쉬운 작은 것들까지 세심한 주의를 기울이는 것이 중요하다. 작은 내용들은 놓치기도 쉽지만, 이것들이 발생시키는 문제들을 찾아내기가 어렵기 때문에 찾아서 고치는 과정도 쉽지 않다.

이러한 놓치기 쉬운 실수들 중 가장 잘 알려진 것은 ++ 연산자다. 일반적인 수학식에서는 존재하지 않는 ++ 연산자는 변수의 앞뒤에 올 수 있다. 예를 들어, value라는 변수에서 ++value를 하는 경우에 해당 식이 계산에 쓰이기 전에 value의 값을 1 증가시킨 후 연산이 진행된다. 문제가 되는 경우는 이를 하나의 수식 안에서 여러 번 사용하는 것이다. 즉, result = (++value*5) + (value++*3)과 같은 형태의 식이 문제를 일으킬 수 있는 대표적인 경우다. 이러한 수식이 문제를 일으킬 수 있는 것은 위와 같은 수식이 명확하게 C 언어 표준에 의해 정의되지 않았고, 이러한 코드들의 동작은 컴파일러마다 다를 수 있기 때문이다. 실제로 이러한 코드들에 대한 C 언어 표준의 정의를 이해하기 위해서는 변수의 값이 변경되는 시점을 지정하는 C 언어 정의 내에서의 Sequence point에 대한 정의를 이해할 필요가 있다. Sequence point는 어떤 종속되지 않은 연산 문장의 끝 부분, 지정된 몇 개의 연산자 부분인 ||, &&, ?, :, comma 연산자(,) 등,  그리고 함수의 호출 이전 부분에 정의되어 있다. 다시 말해, 위에서 언급된 3개의 경우(문장의 끝, 지정된 몇 개의 연산자, 함수 호출 이전)에 변수의 값이 변경되어야 한다고 지정하고 있다. 또한 C 언어에서는 이러한 Sequence point에 관련된 정의가 더 존재하는데, 이는 하나의 Sequence point 안에서는 값의 변경이 최대한 한 번까지만 이뤄질 수 있다는 것이다. 다음은 그 정의에 대한 원문이다.

[Sequence point에 대한 정의]
Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored.

그러므로 이렇게 ++ 연산자가 2회 이상 사용된 부분은 표준에서의 정의에 포함되지 않는 내용이며, 실제로 <리스트 1>과 <리스트 2>는 ‘result = (value++ * 2) + (++value * 5)’를 서로 다른 2개의 컴파일러에서 컴파일한 결과를 비교한 것이다.

<리스트 1> result = (value++*2)+(++value*5);에 대한 어셈블리 코드 (컴파일러 1)
MOV EAX,DWORD PTR [ebp-8] ; value++
ADD EAX,1
MOV DWORD PTR [EBP-8],EAX
MOV ECX,DWORD PTR [EBP-8] ; value*5
IMUL ECX,ECX,5
MOV EDX,DWORD PTR [ebp-8] ; ecx(=value*5) + edx(=value)*2
LEA EAX,[ECX+EDX*2]
MOV DWORD PTR [EBP-4],EAX ; result = eax(=위의 계산)
MOV ECX,DWORD PTR [EBP-8] ; value++
ADD ECX,1
MOV DWORD PTR [EBP-8],ECX

<리스트 2> result = (value++*2)+(++value*5);에 대한 어셈블리 코드 (컴파일러 2)
MOV EAX,DWORD PTR SS:[EBP-8] 
LEA ECX,DWORD PTR DS:[EAX+EAX] ; ecx = value * 2
LEA EAX,DWORD PTR SS:[EBP-8]
INC DWORD PTR DS:[EAX]           ; ++value
MOV EDX,DWORD PTR SS:[EBP-8]
MOV EAX,EDX
SHL EAX,2                           ; eax = value * 4
ADD EAX,EDX                        ; eax = eax + value = value * 5
LEA EAX,DWORD PTR DS:[ECX+EAX] ; eax = (value*2)+(++value*5)
MOV DWORD PTR SS:[EBP-4],EAX
LEA EAX,DWORD PTR SS:[EBP-8]
INC DWORD PTR DS:[EAX]           ; value++
MOV EAX,DWORD PTR SS:[EBP-4]
MOV DWORD PTR SS:[ESP+4],EAX

 
이처럼 서로 다른 컴파일러에 대한 계산 결과는 <리스트 1>의 경우에는 (2*2)+(2*5)로 계산되어 14가 나오게 되고, <리스트 2>의 경우에는 (1*2)+(2*5)가 되어 12가 된다. <리스트 1>과 <리스트 2>의 차이의 기본적인 원인은 C 언어에서 이렇게 2회 이상의 단항 연산자에 대한 정확한 정의가 존재하지 않아서 이에 대한 내용을 각 컴파일러마다 다르게 적용할 수 있기 때문이다. 하지만 여기서 더 큰 문제는 같은 컴파일러라고 할지라도 항상 같은 형태로 계산하는 것은 아니라는 점이다. 앞에서 언급한 <리스트 1>의 컴파일러에서도 항상 이렇게 ++ 연산을 수식이 진행되기 전에 2회 모두 실행한 후 연산을 진행하지는 않는다. 일반적으로 위에서 언급한 <리스트 1>과 같은 형태는 특정한 경우라고 할 수 있는데, 이는 lea를 사용해 덧셈과 곱셈을 계산하는 것이 더 빠르기 때문에, 해당 컴파일러가 최적화를 진행한 결과이기 때문이다.
앞서 언급한 내용은, 언어를 이해하지 못해 만들 수 있는 실수와 관련된 부분이었다. 이와는 약간 다르지만, 언어를 정확하게 이해하지 못해 코드를 올바르지 않게 작성하는 예도 있다. 가장 일반적인 오해의 내용은 코드의 길이와 성능이 비례한다고 생각하는 것이다. 이러한 생각을 하게 하는 것은 바로 C나 C++ 언어의 구문들을 컴퓨터가 1줄씩 실행할 것이라고 생각하기 때문이다. 물론 비주얼 베이직과 같은 인터프리터 언어들은 실행 시간에 코드를 직접 분석해 실행하기 때문에, 프로그래머가 코드를 짧게 쓰는 것이 실행 시간을 단축시킬 수 있다. 하지만 대부분의 경우, 심지어는 비주얼 베이직의 경우에도 실제로는 코드의 길이가 실행 시간에 영향을 주는 중요한 원인이 되지 않는다. 특히, 비주얼 베이직이 아닌 많은 언어들은 문장의 끝을 세미콜론(;)으로 나타내게 되는데, 이것은 프로그래머들의 인식과는 달리 컴퓨터는 세미콜론으로 분리된 코드를 한 줄의 코드로 인식하는 차이가 있음을 이해해야 한다. 예를 들어, <리스트 3>과 <리스트 4>의 코드는 프로그래머의 눈에는 다소 다르게 보일 수 있지만 실행하는 컴퓨터의 입장에서는 사실상 동일한 코드이다.

<리스트 3> 변수를 초기화하는 간단한 코드nData = 10;
nIndex = 0;
nTemp = 20;

<리스트 4> <리스트 3>의 코드를 한 줄로 이어 붙인 코드
nData = 10; nIndex = 0; nTemp = 20;

그렇다면 좀 더 복잡한 예를 들어 보자. <리스트 3>과 <리스트 4>의 내용은 쉽다고 생각할 수도 있지만, <리스트 5>과 <리스트 6>의 내용은 생각보다 많은 프로그래머들이 다르다고 혼동하기 쉬운 내용들이다.

<리스트 5> 조건 판단을 위한 단항 연산자nData = nCheck ? 1 : 0;

<리스트 6> 조건 판단을 위한 if 구문
if (nCheck) {
    nData = 1;
} else {
    nData = 0;
}

<리스트 5>와 <리스트 6>은 디버그 모드에서 컴파일한 경우와 릴리즈 모드에서 컴파일해 최적화가 적용된 경우의 소스 코드가 다르다. 디버그 모드로 컴파일한 경우에는 <리스트 5>의 형태가 더 효율적이고, <리스트 6>의 경우에는 실제로는 크게 필요가 없는 분기 구문에 대한 어셈블리 코드가 포함되어 있지만, 릴리즈 모드로 컴파일한 경우에는 <리스트 7>과 같이 2개의 코드가 모두 동일한 어셈블리 코드를 만들어 낸다.

<리스트 7> 릴리즈 모드로 컴파일한 경우의 어셈블리 코드
.
.
00401009  |. 33C0           XOR EAX,EAX
0040100B  |. 85F6           TEST ESI,ESI
0040100D  |. 0F95C0         SETNE AL
.
.
0040101E  |. 33C0           XOR EAX,EAX
00401020  |. 85F6           TEST ESI,ESI
00401022  |. 0F95C0         SETNE AL


.
.

<리스트 7>에서 0x00401009에서 0x0040100D까지의 어셈블리 코드가 단항연산자를 사용한 코드의 부분이며, 0x0040101E에서 0x00401022까지의 어셈블리 코드가 if 구문을 사용한 코드다.

어셈블리 언어와 같이 기계어에 가까운 언어일수록 실제로 코드 길이는 성능에 지대한 영향을 미친다. 어셈블리 언어의 경우에 대해 첨언하자면, 기계어 코드에는 하나의 코드가 실행되는 시간이 있으며 최근의 CPU들은 이러한 명령어들을 병렬로 처리하는 특징이 있으므로 성능을 최대한 최적화한다면 이러한 명령어들의 실행 속도를 생각해 적절히 배열하는 수준까지도 할 수 있다. 이러한 정도의 최적화는 대부분의 프로젝트에는 적용되기 힘들며, 아주 일부분의 성능이 매우 중요한 프로젝트에만 적용된다. 그러나 대부분의 프로그래머들은 이러한 어셈블리 수준의 코드 길이보다 C 언어와 같은 고급 언어의 형태를 가지고 있는 언어들의 코드 길이에 더 민감하다. 그렇지만 C 언어만 해도 성능과 코드 길이는 다소 많이 동떨어져 있다. 대부분의 고급 언어들은 실제 실행 파일이 되기 위해 중간에 코드를 변환하게 된다. 그러므로 프로그래머가 어떻게 코드를 작성하는지보다는 컴파일러가 코드를 어떻게 바꿔주는지가 사실상 성능에 더 큰 영향을 미친다고 볼 수 있다. 앞서 언급한 ‘?’ 연산자와 if 구문이 대표적인 예라고 할 수 있다. 하지만 은근히 ‘?’ 연산자를 더 즐겨 사용하는 프로그래머들이 많다. 이와 같이 짧은 코드를 선택하게 되는 경우에는 성능은 그대로인 경우가 많지만, 가독성은 반드시 떨어진다. 이는 컴파일러와 상관없이 프로그래머가 그렇게 코드를 기술하는 것 자체가 가독성이 떨어지기 때문이다. 즉, 대부분의 짧은 코드들은 성능과 가독성을 교환해야 한다. 하지만 대부분의 경우 앞서 적은 내용과 같이, 실제로 교환되는 게 아니라, 한쪽은 아예 의미 없는 행위가 되는 경우가 많다. 특히, 고급 언어를 사용하는 프로그래머들은 애초에 이러한 것들을 염두에 두는 것이 좋다.

효율적인 프로그래밍
비록 대한민국에서 프로그래머로서의 생활이 아직까지는 모든 사람들에게 좋게 받아들여지고 있지는 않은 게 현실이다. 그러나 필자는 이러한 현실을 그대로 놓아 둘 것인지, 아니면 더 좋게 바꿀 수 있을 것인지에 대한 선택과 능력도 프로그래머 자신에게 있다고 생각한다. 이 글에 이어질 파트에서는 효율적인 프로그래밍을 위한 좀 더 자세한 내용들을 다룰 것으로 기대되며, 다소 어렵거나 원론적인 내용이더라도 실제 실무에 큰 보탬이 될 것으로 생각한다.

 

참고자료
1. Visual C++ 파워풀 개발 테크닉,- 권용휘, 김용현, 신영진 - 웰북

신고
Creative Commons License
Creative Commons License
Posted by 준환이형님

댓글을 달아 주세요

티스토리 툴바