[샘플] Windows에서 다른 프로그램의 타이틀바를 없애고 반투명하게 만들어 주는 소스입니다.

요즘 다각도로 생각이 많은 상태로 페이스북을 보다가 지인의 글 바로 위에 올라와 있는 질문을 보고 그 지인이 올린 질문인 줄 착각하고 평소처럼 가볍게 촐싹대면서 답글 달고 도움 요청하면 알려주고 술이나 얻어먹을까 했는데 잠깐 정신 차리고 보니 질문자가 모르는 분이었네요.

깜짝 놀라고 챙피해서 어서 빨리 댓글을 지우는 찰나에 질문자가 댓글을 보고 답변을 달았네요.

관성의 법칙에 따라 댓글은 지웠지만 마음의 앙금은 안 지워져서 다시 댓글 달고 답변에 해당하는 코딩하고 바이너리와 소스를 올립니다.

제목대로 "Windows에서 다른 프로그램의 타이틀바를 없애고 반투명하게 만들어 주는 소스 코드"입니다.

제가 수정하기 전의 소스는 아래 링크에서 다운로드 받을 수 있습니다.

https://www.codeproject.com/Articles/1698/MS-Spy-style-Window-Finder

위의 소스는 윈도우OS에서 다른 프로그램의 정보를 얻어내는 소스코드 입니다.

이걸 약간 수정하면 남의 프로그램에 다양한 조작질을 할 수 있습니다.

https://drive.google.com/file/d/1xBHi3rmrDOYRcvMCsIILpZxVWvyhD_xl/view?usp=sharing

위의 소스코드가 남의 프로그램 타이틀 바를 없애고 투명도를 50%로 바꾸는 바이너리와 소스 코드입니다.

바이너리는 압축을 풀고 나오는 디렉토리중에 Release 디렉토리를 보면 있습니다.

원 소스는 Visual C++ 6.0 프로젝트 파일이며 저는 Visual C++ 2005에서 빌드했습니다. 특별한 것이 없으므로 상위 컴파일러에서 빌드될 겁니다.

두 소스를 WinMerge 같은 비교툴로 비교해서 차이를 봐도 되고, 텍스트 검색으로  //GoodLuck 이라고 되어 있는 곳만 봐도 됩니다.

나중에 단 댓글에 유니티에서 지원안한다고 했는데 다시 생각해보니 이걸 dll로 만들고 유니티에서 임포트하면 위처럼 별도 프로그램으로 만들 필요없이 가능하겠습니다. 작년에 유니티에서 AR작업을 애셋없이 날코딩해서 만들때 안드로이드와 ios 모두 별도로 모듈 만들어서 임포트해서 했으니 윈도우에서도 당연히 되겠네요.

첨부된 바이너리의 간략한 사용법은 아래와 같습니다.

이 글은 질문자뿐만 아니고 몇 몇 사람들이 보겠지요. 모두들 딱 원하는 소스는 아닐 겁니다.

요새는 프로그램을 앱이라고 부르지요. Application을 줄여서 부르는 말입니다. 신청서란 뜻도 있지만 소프트웨어 업계에서 예전엔 응용 프로그램이라고 불렀습니다.

제가 수정한 부분은 아주 간단하고 얼마 안되지만 이 작업을 해보지 않은 사람들에겐 이 결과를 내는 과정은 굉장한 노력이 필요합니다. 소프트웨어 개발이란 게 그렇습니다. 경력이 오래된 베테랑들도 단 한줄 때문에 수 없이 밤을 샙니다.

이런 간단한 것 쯤이야 그냥 검색해서 나와주면 좋겠지만 그런것도 있고, 아닌 것은 훨씬 많습니다. 검색에서 나오지 않는다면 단 몇 줄을 위해서 정말 많은 것을 공부하고 봐야 합니다.

이 간단한 것도 응용하려면 해보지 않은 사람들에겐 매우 어렵고 배경지식을 공부하는 시간이 많이 필요하니 급하지 않게 천천히 살펴보면서 다양하게 응용해보시기를 바랍니다. 그 과정이 결국 재산으로 남게 될 거라 생각합니다.

가끔은 힘에 부친다.

투자 한 푼 받은 것 없이, 집안 재력 없이 사업을 하려니 가끔씩 힘에 부치네요.

그전에 직장생활 17년 정도 하면서 항상 일이 몰리는 타입이었습니다. 아는 분은 알 겁니다. 대부분의 회사에서 눈여겨보면 몇 명한테 일이 쏠립니다. 이유는 여러 가지가 있긴 한데 하여간 저도 그런 사람 중에 하나여서 혼자서 동시에 여러 가지 일도 하고 남의 일까지 떠 넘겨 받아서 하기도 해서 혼자 다양한 많은 일을 하는 데에 대한 거부감도 없었고 자신감도 있었는데...

정도를 넘어서네요.

지금은 아무리 프리랜서처럼 일한다고 하지만 나름 사업이다 보니 정말 다양한 잡무가 열대지방 스콜처럼 쉬지 않고 생기는군요.

일부러 일을 찾아다니는 영업을 하지도 않고 있는데 지인들에게 소개받거나 연락 오는 것 상황 파악하고, 만나보고 판단하고, 조율하고, 협의하기 위해서 한 달 가까이 연락 주고 받거나, 미팅하고 수락하거나, 거절하고 하는 것들도 시간과 정신 에너지를 잡아먹는 것이 꽤 되는 데다가 각종 세금이나 비용처리 같은 일들도 그렇고, 그리고 본업인 소프트웨어 개발도 있고, 외주개발로 먹고 살려고 시작한 사업이 아니니 틈틈이 팔아먹을 솔루션 개발도 하고 있고, 서비스 개발도 해야 하는데 그건 꿈도 못꾸고... 그렇다고 돈을 아주 많이 벌고 있는 것도 아니고...

투자를 받거나, 금액이 아주 크거나 지속적으로 들어오는 일을 잡아야 직원을 채용하든지  해서 이 뫼비우스의 띠를 벗어나야 솔루션 개발 및 서비스 개발을 제대로 할 수 있을 것 같은데 그게 언제가 될지 모르겠군요.

장사도 돈 없이 시작하면 노점상부터 시작해서 올라가야 하는 건데 소프트웨어 개발일도 돈 없이 시작하니 비슷한 상황인 것 같네요.

투자는 될 수 있으면 받고 싶지는 않지만 이 끝날 것 같지 않은 로드런이 계속 될 거 같으면 투자도 받을 수 있을 만한 로드맵으로 수정해야 하는 생각이 드는 군요... ㅠㅠ

전쟁의 신 아수라

정말 머리가 여러개고 손발이 여러개였으면 좋겠네요. 비지니스는 전쟁이라고 하던데 저 전쟁의 신 아수라가 왜 저런 모양인지 몸으로 이해되고 있습니다. ㅠㅠ

"나 돌아갈래~"

친목 모임 날짜 정하기

저는 사회생활하면서 원하지 않게 비영리 친목 모임에서 감투를 쓰게 된 경험이 좀 있습니다. 저는 논리적이고 합리적인 결정을 해야 한다는 강박증이 있어서 윗사람이 뻘짓하면 딴지를 잘 걸긴 하지만 권력을 추구하는 타입은 아니기 때문에 정말로 제가 원해서 된 적은 단 한번도 없습니다.

그래서 우스갯소리로 바지회장이라고 스스로 지칭합니다.

출처 : 한국일보

진짜 회장이던 바지회장이든 어쨌든 감투를 썼기 때문에 최선을 다합니다. 비영리 모임이므로 권한은 없고 책임만 있습니다.

그거참 이상하게 회사 다닐때도 거의 대부분이 권한은 없고 책임만 있는 관리 역할을 병행했습니다. 예를 들면 직급은 사원 그리고 대리였을 때 누구, 누구를 데리고 프로젝트를 이끌어 가라. 이런 책임을 받은 적이 몇 번 있으며 심지어 이끌어갈 대상자들이 저보다 연장자인 경우도 두어번 있었습니다. 제가 속한 팀의 팀장이 퇴사를 했는데 새 팀장이 오지도 않고 저에게 팀장 직급을 주지도 않고 그냥 이것도 저것도 아닌 상태에서 5개월 동안 팀장대행 업무를 하다가 사업부서가 사라져 버린 일도 있습니다. 또는 직급은 과장이고 직속 팀장이 있었음에도 불구하고 그냥 제가 팀관리 업무를 오래 한 적도 있습니다. 그때는 팀장 명함까지 만들어줘서 명함이 과장, 팀장 두 개였었네요.

저도 운명같은 동행을 만나고 싶습니다. 운명같은 와이프는 있으니까 오해 마시길.

저는 운명이란 것을 믿지는 않았습니다만 비영리 모임과 기업활동에서 모두 다 이러다 보니 운명을 믿게 되었습니다....

는 쓸데없는 농담이고요, 회사생활 때는 다니던 회사들이 저에게 권한을 주기 전 단계에서 모두 안 좋게 되었기 때문에 그랬던 것 같습니다. 그래서 본의 아니게 이직도 여러 번 하게 된 것입니다.

어쨌든 비영리 친목 모임의 감투는 권한은 없으며 책임만 있고 그 책임도 딱 하나입니다. 모임 날짜를 잡는 것이지요.

인원수가 10명 안팎인 친목 모임에서의 모임 날짜를 잡는 것은 생각보다 어려운 일입니다. 어찌어찌 하다 보면 소위 "폭파"라고 불리는 모임 취소가 생기는 것도 아주 흔한 일이지요.

위에 "어쨌든 감투를 썼기 때문에 최선을 다합니다"라고 했습니다. 저는 단 한명이라도 나온다면 모임 취소는 없습니다. 그대로 강행합니다.

학명 : Raphanus raphanistrum subsp. sativus

"싸나이가 칼을 뽑았으면 썩은 무라도 잘라야지!!!"

저는 고지식함, 완고함, 고정관념은 인생의 가장 큰 적이고 어떤 수를 써서라도 바꿔야 한다라고 생각하는 사람입니다만, 이제는 별로 들리지도 않는 이런 고리타분한 사고방식을 요 경우에는 고수하고 있습니다.

그래도 모임 취지에 맞게 될 수 있으면 많은 사람이 참여하도록 노력을 해봐야겠지요. 노력하려면 전략이 있어야 합니다. 뭘 해야할지도 모르면서 노력할 수는 없으니까요. 모임 날짜는 구성원 각자가 상황이 다 다르지만 심리도 영향을 미칩니다. 상황은 어쩔 수 없지만, 심리는 분석이 가능하고 조절이 가능합니다.

인원수가 10명이라고 가정하면 대략 아래와 같은 심리로 분류가 됩니다. 어디까지나 저의 개인적인 경험이고 진리는 아닙니다만 참고는 될 거라 봅니다.

A. 1~3명 정도는 명쾌한 성격입니다. 날짜 정할 때도 된다, 안된다, 명확하게 말해주고 되는 날짜면 어김없이 나옵니다. 이런 사람들은 일도 똑부러지게 하지요.

B. 1~2명 정도는 열성적인 태도는 아니고 미지근 하지만 늦게 나마라도 된다, 안된다, 명확하게 말해주고 되는 날짜면 어김없이 나옵니다. 이런 사람들은 열정을 드러내는 타입은 아니더라도 "약속"을 중시하는 타입입니다.

C. 나머지 절반에서 3분의 2정도는 별생각이 없습니다. 그냥 날짜가 정해지면 그 때 가서 땡기면 나가고 안 땡기면 안 나간다는 태도입니다. 땡기고 안 땡기는 이유도 다양합니다. 모임에 확실히 참가하는 사람 중에 마음에 드는 이성이 있으면 나오고 없으면 안 나온다든지, 구심점이 되는 사람이 있으면 나오고 그 사람이 빠지면 안 나오든지, 이것도 저것도 아니고 그냥 당일에 심심하면 나오고 그냥 안 내키면 안 나오든지 그러합니다. 당연히 날짜 정할 때도 소극적인 자세로 나옵니다.

절세미녀 양귀비 : 이런 미녀(?)가 모임에 나온다고 하면 남정네들은 모두 다 참석할까요?

분석이 끝났으니 전략을 짜야겠네요. A타입과 B타입 2~5명은 쉽습니다. 빠르든 늦든 참석 여부를 명확히 밝혀 주니까요.

전략은 나머지 절반에서 3분의 2 정도의 인원을 공략해야 합니다. 친목 모임이니 모든 사람이 나올 필요는 없지요. 적은 수가 좋을 것 같으면 그냥 냅두면 알아서 나올 사람 나오고 안 나올 사람 나옵니다. 이런 전략일때는 모임 장소와 일정을 소규모로 생각을 하고 정해야 합니다.

좀 많이 참여하기를 바란다면 위에서 언급한 인기 좋은 이성이나 구심점이 되는 사람을 적극적으로 섭외하고 날짜를 정할때도 민주적으로 정하는 것처럼 위장하면서 그들 기준에 맞도록 조작질을 하면 좀 쉽습니다만 타겟이 되는 사람이 소극적일 때는 좀 힘든 면이 있습니다.

어렵겠지만 또 해볼 수 있는 것은 1대 1 공략입니다. 일일이 전화로 안되는 날짜를 말해라라고 강요를 합니다. "되는 날짜"가 아니고 "안되는 날짜"를 말하라고 강요를 합니다. 1 대 1이므로 마음에 드는 이성이나 구심점이 되는 사람이 언제 나오는 알 길이 없으니 대충 답변할겁니다. 또는 귀찮아서 대응하는 시간을 모면하려고 대충 말합니다. 그리고 눈치보다가 모임에 안 나옵니다만 그래도 다른 방법들 보다는 많이 나옵니다.

떡고물이 떨어지는 것도 아닌데 이래저래 피곤합니다. 많은 감투들이 이렇게 나가떨어지고 비영리 모임은 흔적도 없이 사라집니다. 하지만 별 노력 없이 많이 모으는 방법도 있습니다. 모임 자체를 더럽게 오랜만에 잡으면 됩니다. 대략 2~3년에 한 번 잡으면 됩니다. 그러면 그 전에 안 하던 시간 조절도 알아서 하면서 참석자가 많이 나옵니다.

사회생활은 인간관계가 필수지요. 수고해놓고 나가떨어져서 남는 게 없는 것보다는 전략적으로 운용해볼 여지는 있습니다. 분석과 전략은 이따구로 해 놓았지만 저 개인적으로는 인간을 좋아합니다. 모임에서 먹고 마시는 술과 음식 그 자체도 좋아합니다. 그러다 보니 나가떨어지지 않고 저런 전략도 구사하는 겁니다. ^^;

뭐가 좋은지 실없이 얼빵하게 웃고 계시는군요.

실무 지향적 개발자, 이론 지향적 개발자 - 에필로그

"실무 지향적 개발자, 이론 지향적 개발자"란 주제로 개발자 개개인의 특성을 두 가지 성향으로 분류를 하여서 글을 써 봤습니다.

글쓴이인 제가 봐도

"별 쓸데 없는 이야기를 참 길게도 쓰고 자빠졌네"

란 말이 나오는 군요.

어느 학자나 아주 유명한 사람이 쓴 책에 나오는 이론이나 주장이 아니니까 알아봐야 읽는 분께 도움이 안 될 겁니다. 그냥 제가 주장하는 내용이고 제가 세계적으로 유명해진다면 쓸모가 있을지 모르겠습니다만, 그날이 올까요?

개발자에게도 생소한 개념과 용어를 지어낸 것이다 보니 익숙하지 않은 표현들이라 내용 전달도 효과적이지 못했을 것 같습니다.

문장도 효율적이지 못하고 너무 깁니다. 목적 의식없이 우연히 여기 들어온 분들은 끝까지 읽은 사람이 별로 없을 것 같습니다.

제가 잘못 했습니다.

다시는 안 그러겠습니다.

이렇게 말하고 또 그럴 것 같습니다만...

... ...

글도 거시기한데 에필로그도 참 거시기 하군요...

실무 지향적 개발자, 이론 지향적 개발자 - 이론 지향 성향

앞선 글에서 "실무 지향적 개발자"란 주제로 썰을 풀어봤습니다. 이번엔 "이론 지향적 개발자"란 주제로 횡설수설할 차례입니다.

실무 지향적 성향이 강한 개발자들은 대체로 비슷한 모습으로 귀결합니다. 이미 앞글에서 언급했듯이 늘상 바쁘고, 코딩 잘하고 수단과 방법을 가리지 않고 결과물을 만들어 내며, 새로 등장한 기술이나 이론을 일에 적용시키는 데 부정적이거나 무관심한 태도를 보이며, 자기의 지식을 그럴싸하게 포장하여 전파하는 행위도 잘 안 해서 자신이 하는 일과 관련된 것외의 다른 것은 아는 게 많지 않아 보이는 그런 모습입니다.

"이론 지향적 성향"이 강한 개발자는 위처럼 한 가지 모습이 아니고 "학구적인 스타일"과 "정치적인 스타일" 두 가지로 나눠진다고 볼 수 있겠습니다.

두 스타일은 전혀 다르게 보입니다만 상당히 공통점이 많이 있습니다. 잠깐 간단하게 공통점과 차이점을 기술해보면 일단 관심사가 같습니다. 새로 등장하는 기술이나 이론에 관심이 집중됩니다. 가진 지식을 글이나 말로 적당히 포장질도 잘 하고 좋아합니다. 하지만 디버깅이나 유지보수를 싫어하는 경향이 있습니다. 결과물에 중점을 두는 "실무 지향적 개발자"와는 정반대의 모습이 되겠군요.

차이점을 말해보면 "학구적인 스타일"은 표현 그대로 기술이나 이론에 대한 세부적인 내용과 철학을 습득하는 것을 좋아합니다. 흔히 이야기하는 "모범생" 스타일이지요. 기술이나 이론에 대해서 깊게 들어가는 질적 접근을 합니다.

연극인 모양인데 부제가 '명석함은 기본 비열함은 필수인 모범생들' 이네요... 좀 불편한 주제군요...

"정치적인 스타일"은 기술이나 이론을 입신양명의 도구 또는 자기 홍보의 수단으로 보고 관심을 집중합니다. 다양한 것을 많이 아는 척해야 하므로 기술에 대해 양적 접근을 합니다. "정치적"이란 단어의 원래 뜻은 좋아야 하는데 현실은 부정적인 뜻으로 통하고 있지요. 안타깝다라고 말하고 싶지만 "정치적"인 사람이 잘먹고 잘살 확률이 높은 게 또 다른 현실이라 안타깝지 않습니다. ^^;

출처 : Daum 어학사전
(이렇게 좋은 뜻의 단어인데....)

이런 "이론 지향적 개발자"들도 디버깅 잘하고 유지보수 잘 하는 사람들 많이 있습니다. 다만 현실을 봤을 때 관심이 가는 기술이나 이론은 매일 쏟아져 나오기 때문에 그런 것들을 모조리 보고 싶은데 디버깅이나 유지보수를 하고 있자니 시간이 아깝습니다. 자기 계발을 못 하고 정체된 것 같은 압박감에 괴롭습니다.

이런 경우에 선택은 두 가지밖에 없습니다.

첫 번째로는 그냥 열심히 일하는 거지요. 하지만 자기 계발에 도움이 안 되는 것처럼 보이는 코딩하고, 디버깅하고 유지보수도 하고 개나 소나 치킨이 요청하는 잡일을 하면서 계속 압박감을 느끼고 불만이 쌓입니다.

"내가 이런 거 할 때가 아닌데..."

이렇게 말합니다. 제가 오바하는 것 같지요? 남의 것도 아니고 자기가 만든 거 디버깅하거나 기능추가 같은 유지보수 업무를 하면서 실제로 저렇게 말하는 사람을 여러 명 봤습니다. 대충 기억을 끄집어 내보면 5명 이상 되는 것 같습니다. 말하지 않더라도 속으로 저렇게 생각하는 사람까지 하면 꽤 될 것 같습니다.

또 새 기술을 깊게 파고들어서 일에도 적용하고 싶은데 모든 개발자의 적인 "데드라인"이 있습니다. "데드라인"이란 명분을 앞세워서 개나 소나 닭이 쪼아댑니다. 어쩔 수 없이 대충 적용하거나 그냥 공부만 하고 일에 적용은 못합니다. 불만이 따불로 쌓입니다.

deadline 을 콩글리시로 직역하면 "죽음의 선"일 것이고 "선"은 완료해야 할 날짜의 의미이므로 의역하면 "날짜 못 지키면 넌 죽는다"가 되겠군요...

위처럼 괴로워하면서 어쩔 수 없이 작업하는 경우가 있고 나머지 하나는 빠져나가는 방법이 있겠습니다. 주로 관리자에게 다양한 핑계를 대면서 프로젝트가 완료되기 전에 다른 프로젝트로 옮겨가는 방법도 있겠고, 쓰던 기술 말고 다른 방안을 제안하는 경우도 있습니다. 정말 끝도 없이 다른 방법을 들이대는 경우를 봤습니다. 더 경악스런 것은 결정권자가 그걸 수용을 합니다. 프로젝트가 영원히 안 끝날 것 같습니다. 납품이 아닌 자사 제품이나 서비스를 개발할 때 이런 경우가 있습니다. 결국 당사자가 이직하면서 그 프로젝트는 처음부터 다시 시작하는 지경까지 가는 것을 직접 봤습니다.

어떠한 미꾸라지 방법도 뜻대로 안 될 때가 많지요. 최후의 차선책으로 배째라를 합니다. 자신이 없다, 도저히 모르겠다, 해도 잘 될지 의문이다 등등등. 그래도 안 되면 최후의 최선책이 나옵니다. 그만둔다고 합니다.

출처 : 구글 이미지 검색

연차가 좀 있는 사람은 "아랫사람"에게 떠넘기기도 합니다. 요리조리 썰을 풀고 이건 누구에게 시키고 저건 누구에게 시키는 게 낫겠다로 몰아갑니다. 이런 꼼수가 수직구조의 조직에서는 정당하게 보입니다. 관리자 또는 결정권자는 의심도 없이 그냥 수용합니다. 업무분장과 일을 떠넘기는 것은 완전히 다른 거지만 당사자들 외에 타인이 구분하기가 힘듭니다.

"실무 지향적 개발자"란 글에서 제가 지껄여댄 것과는 다른 형태의 병폐가 쌓이는군요. 마찬가지로 적폐청산이 안 되고 있습니다. 다만 이 병폐를 만들어 내는 당사자들인 "이론 지향적 개발자"들이 그 피해를 보는 경우보다 엉뚱한 "실무 지향적 개발자"들이 피해를 보는 경우가 많다는 차이가 있습니다.

이래저래 "실무 지향적 개발자"들만 피곤하군요. 그래서 이런 병폐가 지속되면 개개인의 문제라기보다는 조직 차원의 문제로 발전합니다. 범용적으로 잘 입증된 개발조직의 관리 시스템이 없다 하더라도 어떻게든 자기 조직에 맞는 관리 방법을 만들어내고 적용을 해야 하는 이유입니다.

어쨌든 "이론 지향적 개발자"는 아는 게 많아 보입니다. 일하는 자세도 학창시절의 동경의 대상이었던 모범생 그 자체와 비슷해 보입니다. 그래서 많은 사람이 "능력 있는 개발자"로 착각을 합니다. 주변에서 저 사람은 "능력 있는 개발자"라고 말한다면 "이론 지향적 개발자"일 확률이 매우 많이 높습니다.

"능력 있는 개발자"로 평가를 받으니 당연히 "실무 지향적 개발자"에 비해 다양하고 많은 기회를 얻습니다. 나쁘지 않습니다. 바람직합니다. 기회를 얻는다는 것은 좋은 것입니다. 그 기회를 살리는 것은 다른 문제이긴 하지만요. 아무리 자신이 "진짜 능력자"라고 한다 한들 기회를 얻지 못하면 할 수 있는 것이 별로 없습니다. 기회를 100% 좋은 결과로 만들어 낼 수 있다 한들 그 기회가 없으면 0%입니다.

"기회의 평등은 민주주의의 첫 번째 원칙이다" --- 도대체 이 원칙은 언제 지켜질까요? 유토피아에서나 원칙이고 현실에서는 "이루어질 수 없는 사랑"인 것 같습니다.

하지만 위에서 잠깐 언급했듯이 "이론 지향적 개발자"들이 "능력있는 개발자"로 보이는 것은 착각일 수 있습니다. 아는 게 많아 보이는 것도 기준을 어디에 두느냐에 따라 달라집니다.

안정적이고 효율적이고 이용자에 친화적인 소프트웨어 결과물을 만들어 내는 것은 학창시절 공부하고 시험보는 것과는 상당히 다릅니다. 책이나 기타 매체에서 쏟아내는 신기술이나 이론은 항상 완벽합니다. 쓰는 사람이 자기 잘났다고 장점만 쓰지 단점을 쓰지는 않거든요. 모자라는 내용도 마찬가지로 감춥니다. 간혹 정직한 사람은 단점도 쓰고 싶겠지요. 그런데 출판사에서 책이 안 팔릴까봐 편집에서 걸러냅니다. 다른 매체들도 마찬가지입니다. 에반젤리스트는 말 그대로 전도사인데 단점을 이야기 하겠습니까? 오히려 소속사의 단점은 교묘히 감추고 경쟁사나 유사 업종의 단점을 부각시키고 비난하는 교활한 방법으로 명성을 얻은 에반젤리스트도 있습니다.

그리고 소프트웨어 개발이라는 것은 환경이 정말 다양합니다. OS만 해도 여러 개고 개발 언어도 다양하고 업무도 종류가 많습니다. 데이터를 주로 다루다가 나온 이론을 멀티미디어 개발에 쓰면 어떻게 될까요? C++만 다루다가 나온 이론을 파이썬에서 쓰면 어떻게 될까요?

이론 창시자가 "나는 죽도록 Database 개발만 했는데 그거 하다 보니 이런 게 나왔다. 이거는 Database 에만 최적화된 이론일 수 있다" 이런 식으로 글을 쓰지는 않습니다. 그냥 완벽하다고 씁니다. 자기 이론이 은하계를 정복할 것처럼 씁니다.

이 동네를 정복하겠다는 말은 매일 같이 나오는 데 도대체 언제 정복이 될까요?

그렇다 보니 우리의 순진한 개발자들에게 시행착오는 필연적입니다. 이렇게 말하는 저도 새 기술을 실제 적용하기 전에 시행착오를 최대한 예상하고 피해 가려 하지만 막상 프로젝트 끝으로 갈수록 예상치 못한 문제를 자주 만납니다.

좀 극단적인 예이긴 하지만 자신이 주장한 방법으로 개발을 진행해서 시간이 흘렀는데 막판에 끔찍한 시행착오를 겪는 경우도 있습니다. 그럴 때 솔직하게 이야기하고 처음부터 다시 하는 사람이 몇이나 있을까요? 대부분은 위에서 언급한 병폐의 방향대로 갑니다. 떠넘기던지 이직하던지 대충 때웁니다. "능력 있는 개발자"로 평가받는 사람들에게서 결과는 전혀 다르게 나옵니다.

꿈과 희망만 주는 만화 "우주형제"

시행착오를 많이 겪어서 감을 익히는 것도 능력의 일부입니다. 그런데 "이론 지향적 개발자"들은 이미 언급한 대로 디버깅 및 유지보수를 피하는 경향이 있다 보니 시행착오를 겪는 일도 적습니다. 결과물을 잘 만들어 내서 적은 게 아니고 그런 상황을 피해서 적은 겁니다. 시행착오를 적게 겪다 보니 은하계를 정복할 것 같이 포장질 해대는 신기술이나 이론에 의심도 별로 안 합니다. 학창시절 공부해서 시험 보는 것처럼 대응합니다.

저는 가끔이긴 하지만 이런 부류의 사람들을 상대하다 보면 앵무새 같다는 생각이 듭니다. 감춰진 단점이나 애로사항은 생각도 안 하고, 자신의 생각도 없이 어디에 나온 걸 앵무새처럼 읊어댑니다. 실무에 적용했을 때 생길지도 모르는 문제점을 찍어서 물어보면 역시 앵무새처럼 질문과 전혀 상관없는 다른 내용을 읊어댑니다. 답답한 노릇입니다.

"조엘 온 소프트웨어"의 저자인 조엘 스폴스키는 일정 기간 MS에서 액셀개발을 한 사람인데 이 사람도 저 같은 느낌이 들었던 것 같습니다. 읽은 지 하도 오래돼서 정확히 기억은 안 나지만 "아침마다 커피잔을 들고 와서 홀짝대며 엉뚱한 이론만 들먹거리는 사람이 가끔 있긴 하지만 다행스럽게도 MS에는 그런 부류가 많지 않다" 뭐 이런 식으로 글을 쓴 걸 본 기억이 있습니다. 그 문장을 봤을 때 정말 강렬한 공감이 와서 아직도 잊혀지지 않고 있는 거겠지요. 물론 다른 내용은 거의 다 까먹었습니다... ㅠㅠ

이 책의 저자는 "실무 지향적 개발자"인 것 같습니다.

"이론 지향적 개발자"들은 어쩌다 개발자의 길로 들어섰지만, 소프트웨어 개발 업무에 필연적인 디버깅 및 유지보수를 기피하다 보니 어떻게 보면 길을 잘못 들어섰다고 말할 수도 있겠습니다. 그리고 실제로 시간이 지나면 개발에 손을 놓는 비중이 "실무 지향적 개발자"보다 압도적으로 많습니다. 앞서 이야기한 대로 "실무 지향적 개발자"들 보다 기회를 많이 받다 보니 전직하기도 좋습니다. 관리자나 기획자나 기술지원부서 등 비 개발 쪽으로 많이들 전직합니다. 제가 보기엔 현명한 선택입니다. 싫은 것, 맞지 않는 것을 억지로 하는 게 오히려 잘못된 선택입니다.

그래도 전직하지 않고 남아있는 수없이 많은 "이론 지향적 개발자"들도 많이 있습니다. 직장이나 팀을 잘 만나면 편하게 일하면서 삽니다. 그렇지 않다면 괴로워하면서 억지로 일하거나 위에 언급한 병폐를 양산하다가 이직, 또 이직합니다. 그래도 대체로 "실무 지향적 개발자"들 보다는 거취문제에서는 잘 되는 비중이 높은 편이라 어떻게 보면 나쁘지 않다고 볼 수 있겠습니다.

다만 조직 차원에서 가끔씩 잘못된 선택이 될 수 있는데 뭔 말인가 하면, "능력 있는 개발자"로 착시 현상을 일으킬 수 있는 이런 "이론 지향적 개발자"들로만 팀이나 회사가 구성되었을 경우 심각한 결과로 직행할 확률이 높습니다.

모두 다 기술과 이론도 잘 아는 것 같고 모범생 스타일에 말이나 글로 포장질도 잘하는 사람들로만 모아서 팀을 구성하거나 회사를 만들고 "우리 팀(회사)은 능력자들만 있는 기술력이 대단한 조직이다" 이런 식으로 홍보하는 경우를 많이 봤을 겁니다. 비슷한 부류끼리 친한 경우가 많기 때문에 이런 식으로 팀이나 회사가 구성되는 경우가 많습니다.

시작은 좋아 보입니다. 구성원들이 다 능력자같이 보이니까요. 그렇지만 뒤로 갈수록 용두사미가 되는 경우가 많습니다. 왜냐하면, 여태껏 위에서 계속 언급한 병폐가 같은 부류들만 모여있다고 안 나오는 것이 아니거든요. 그리고 그 병폐가 나왔을 때 문제를 떠안거나 해결해줄 "실무 지향적 개발자"가 구성원에 없으면 어떻게 되겠습니까? 더 빠른 속도로 무너집니다.

또 "이론 지향적 개발자"들은 자기애가 강한 편입니다. 그래서 "실무 지향적 개발자"들 보다 거취 면에서 잘 되는 비중이 높은 거지요. 자기애가 강한 사람들만 잔뜩 모여서 "자기"가 아닌 남이 사용할 소프트웨어를 만들려고 하면 어떻게 될까요? 좋은 제품이 나오기 힘듭니다. 흔히 말하는 "기술력은 좋은데 시장가치가 없는 제품"이 나올 확률이 높습니다. 그리고 실제로 까보면 기술력이 그리 좋지도 않습니다. 디버깅 및 유지보수 싫어하는 사람들만 잔뜩 모여서 소프트웨어 제품을 내놓았다면 속된말로 "안 봐도 비디오"입니다. 어떤 특별한 최고의 기술이나 이론이 사용됐는지는 알 필요도 없습니다. 시작부터 문제를 예방하는 설계나 문제가 발생했을 때 해결하기 수월한 방향하고 거리가 멀게 만들어진 것이 분명할 테니 시행착오나 시장의 변화가 생겼을 때 대응 할 수 없는 수준의 제품일 확률이 저 개인적으로는 80%가 넘는다고 봅니다. "능력 있는 개발자"들만 모여있는 팀이나 회사에서 쓰레기가 나올 확률이 80%가 넘는다는 겁니다.

파레토 법칙은 경제학에서 언급된 내용인데 인간과 엮인 다른 모든 부분에도 잘 들어맞습니다.

뭐든 한쪽으로 치우치면 안 좋다는 말이 이럴 때에도 통용됩니다. 그래서 개발조직의 구성원은 서로 다른 성향의 사람들이 적절히 섞여 있고 그 서로 다른 성향의 사람들을 적절히 컨트롤 할 수 있는 관리자나 경영자가 있으면 좋을 결과를 낼 확률이 높아집니다.

언젠간 저에게도 해당할 사항이긴 하지만, 관리자나 경영자 입장에서 조직을 구성할 때 "이론 지향적 개발자"의 안 좋은 면에 많이 치우쳐져 있는 사람을 어떻게 구분해내느냐가 과제입니다.

저 개인적으로는 오랜기간 일하면서 개발자 개인의 성향을 구분하는 훈련이 되어 있으므로 구분 그 자체는 문제가 없다고 생각합니다만, 개발자 자체를 구할 수 있느냐 없느냐의 문제가 되겠습니다. 물론 저도 대 실패를 할 수 있다는 가정도 되어 있지만 일단은 저의 경우는 과정인 상태이므로 넘어가도록 하겠습니다. 언젠간 결과를 이야기할 날이 올 수도 있겠지요.

그럼 다른 조직에서는 어떻게 해야 할까요? 이 문제는 정말로 어려운 문제입니다. 뚜렷한 공식도 없고 방법론도 없습니다. 인간의 내재되어 있는 특성을 파악한다는 것은 평생을 공부한 정신과 의사도 힘든 일일 것 같습니다.

프로이트도 개발자 성향은 구분 못 합니다.

수없이 많은 방법이 있겠지만 비교적 효과적일 수 있는 한 가지 방법을 설명드릴 수 있습니다. 조직 구성 초기나 평소에 실무적이냐, 이론적이냐 이런 부분 말고 "책임감 있는 사람"을 구하거나 눈여겨볼 필요가 있습니다. 기술을 모르는 관리자나 경영자라도 "책임감 있는 사람"을 구분하는 것은 그나마 상대적으로 수월할 것이라 생각됩니다. 이것도 안 된다면 아무리 자신이 똑똑하다고 생각하거나 스펙이 좋아도 리더로서 자질이 없는 겁니다.

"책임감 있는 사람"을 찾았다면 조직 구성원 후보자들에 대해서 물어보거나 면접관으로 데리고 들어가는 방식등으로 조언을 구하는 방법이 있습니다. 그 "책임감 있는 사람"이 "실무 지향적 개발자" 일 수도 있고 "이론 지향적 개발자"일 수도 있습니다. 또 사람 보는 능력이 별로일 수 있습니다만 그런 건 중요하지 않습니다.

"책임감 있는 사람"은 "책임감 없는 사람"을 구분해 낼 확률이 상당히 높습니다.

"책임감 있는 사람"은 이미 사회생활을 하면서 남이 자기에게 떠넘기는 것에 익숙합니다. 속된말로 많이 "당하기"도 합니다. 그런 일이 쌓이면서 설명은 못 해도 본능적으로 알 수 있습니다. 날카롭게 잘 파악해서 설명을 잘 하는 사람도 있고요.

또 대부분의 사람은 "자기중심적 사고"를 합니다. 이상하게도 나이가 들수록 더 그런 사람들이 많이 보입니다. 제 주변은 안 그러던 사람도 나이가 들어가면서 그렇게 변하는 사람이 계속 늘고 있습니다. 어쨌든 "책임감 있는 사람"이 자기중심적으로 남을 바라봤을 때 "책임감 없는 사람"은 별 노력 없이 보이게 됩니다. 보이는 대부분의 언사나 행동이 자기 기준에 안 맞을테니까요.

"책임감 없는 사람"은 같은 부류인 "책임감 없는 사람"을 구분하기 힘듭니다. 당한 적이 거의 없거나 너무 적어서 몸에 쌓인 것이 없거든요. 또 책임감이 없기 때문에 조직을 구성하는 가장 중차대한 일인 사람의 특성을 구분하는 일에 대해서도 별로 상관을 안 합니다. 대충 넘어갑니다. "내 알 바가 아니다" 입니다.

"책임감 있는 사람"으로 판단되어 구해진 개발자는 이론 지향적 성향이더라도 "실무 지향적 개발자"의 장점도 가지고 있는, 양쪽 성향의 장점을 모두 가지고 있는 "진짜 능력자"일 확률이 높은 편입니다. 어디까지나 확률이긴 하지만요.

팀을 만든다든지 스타트업을 창업한다든지 하는 일은 시작이기에 가장 중요한 일입니다. 시작이 잘못되면 끝도 당연히 잘못될 확률이 굉장히 높은 거는 말 할 필요도 없겠지요. 조직의 결과는 관리자에게는 소속사에서 정치적 입지, 경영자에게는 인생 자체가 달린 일일 수도 있습니다. 적절한 판단으로 될 수 있으면 "진짜 능력자"를 많이 갖춰야만 정치든 인생이든 실패를 덜 할 수 있습니다. 또 실패를 하더라도 만회할 수가 있습니다.

The One Above of all - 마블 캐릭터중 최강의 능력자 라네요.

이번 글도 별로 영양가 없는 이야기를 참 길게도 썼네요. 이런 재미 없는 글을 끝까지 읽은 분들이 있을지 모르겠지만 여기까지 읽으셨다면 님께서는 성공적인 사회생활을 하고 계시거나 곧 성공할 분일 것 같습니다. ^^;

대화의 변질

사람은 무인도에 살고 있지 않은 이상 글이든 말이든 "대화"를 할 수밖에 없습니다.

무인도에서는 공하고 대화해야 합니다.

그리고 어떤 대화든지 목적이 있습니다. 또 같은 대화라도 그 대화 참가자의 목적은 각자가 같을 수도, 다를 수도 있습니다.

대화의 목적은 여러 가지가 있습니다. 토론을 통해서 결론을 도출해 내는 것이나 상대방을 설득시키려는 것이나 그냥 단순한 하소연이나 시간 때우기가 될 수도 있습니다.

그런데 이 대화의 목적은 대화하는 과정에서 수시로 바뀔 수도 있습니다. 단순한 시간 때우기로 시작한 대화가 격론이 될 수도 있습니다. 시작 목적이 시간 때우기였으니 지인들과의 대화가 그렇게 되기 쉽지요.

토론을 통해서 결론을 내려고 했던 대화가 그냥 하소연이나 시간 때우기가 될 수도 있습니다. 업무 회의에서 하는 대화가 이런 형태로 흘러갈 가능성이 크지요.

어쨌든 잠깐이라도 어떤 결론을 도출해 내려는 과정이 있을 수 있는데, 결론을 도출해 내려는 대화에는 증거가 있어야 하며 증거를 즉시 끌어오기 힘들 때는 논리가 있어야 합니다. 또는 "권위"가 있는 경우도 있습니다. 증거나 논리를 내세우기 귀찮거나 어려울 때 자신의 사회적 지위를 이용해서 상대방을 찍어 누르는 기법이지요.

증거, 논리, 권위... 단어 자체부터가 허점이 상당히 많습니다. 대화에 승리하기 위해서 증거는 거짓 증거를 만들어 낼 수 있으며, 논리는 궤변을 만들어 낼 수 있습니다.

소(小) 카토 : 로마시대 원로원인데 토론을 이기기 위해서 장황한 궤변을 잘 썼다고 합니다.

"권위"는 좀 미묘한 데 그 사회적 지위라는 기준이 애매한 경우가 있어서 그렇습니다. 그 애매한 경우에는 각자가 상대방에 대해 우월의식이나 선민사상을 자기도 모르게 가지게 될 수 있습니다. 예를 들면 같은 대화에 참가한 사람 각자가 서로 자기가 위라고 생각하는 아래와 같은 상황이 있습니다.

"나 혼자 국내 일류 기업에 다니고 있다"

"내 재산이 가장 많다"

"나 혼자 유명 대학교 박사 출신이다"

3명이 한 자리에서 대화를 하고 있지만 각자가 상대방보다 "낫다"고 생각하는 부분들이 있습니다.

세계적인 대기업에 다니는 것이 자랑일 수는 있겠지만 자기 생각이 다 맞는 것이 아닙니다. 재산이 많은 것도 자랑일 수도 있겠지만 자기 생각이 다 맞는 것이 아닙니다. 박사도 자랑 일 수 있겠지만 생각이 다 맞는건 아니지요.

"자랑거리"가 "권위"가 되어서는 안 되지만 거기에 호응해주는 얼치기들이 하도 많다 보니 당사자들도 그걸 "권위"로 착각하는 경우가 정말 많습니다.

그리고 결론을 도출해야 할 토론에서 논리에 밀린다고 생각하면 갑자기 "권위주의자"로 돌변하는 경우가 있습니다. 결론을 도출해야 내야 할 토론이 승부의 세계로 변질되면서 각자가 "니들한텐 질 수 없다"가 되어 버립니다. 위와 같은 상황이면 모두 다 상대방보다 "권위"가 우위에 있는 사람이지요. 모두 다 "권위주의자"로 돌변하면 대화의 목적이 상실되어 버립니다. 대화하는 시간이 아무 의미 없어집니다.

PC와 인터넷이 등장하면서 각종 커뮤니티나 SNS에서 대화하는 비중이 늘고 있습니다. 이 경우는 상대방에 대해서 잘 알지 못하기 때문에 개나 소나 자신의 "권위"가 높다고 생각을 합니다. 정말 사소한 거라도 자신이 우위에 있는 것을 찾아내서 "권위"가 높다고 생각을 합니다.

예를 하나만 들어보면 커뮤니티 가입일이 자기가 앞서기 때문에 상대방에게 "가입한 지 얼마 안 되는데 네가 뭘 안다고 까부냐?" 이런 경우도 있습니다.

결론을 도출해내야 할 토론에 "권위" 따위는 필요 없습니다. 올바른 증거와 합당한 논리만이 필요합니다. 하지만 정말 많은 대화가 저렇게 중간에 승부의 세계로 변질되면서 목적을 상실해버립니다. "권위주의자"로 돌변한 사람들도 저렇게 애매모호한 "권위"로 상대방을 찍어누르기 힘들 경우가 있는데 그 경우엔 출처가 모호한 거짓 증거나 궤변을 수단으로 사용합니다. 그리고 대화를 변질시킨 장본인은 흔히 말하는 "정신승리"를 하게 됩니다. 정신승리는 끝까지 궤변을 들이대면서 상대를 지치게 만들어서 결국 자기가 이겼다고 생각하는 정신병을 말합니다.

루신의 "아Q정전" : 어느 또라이 정신승리병자의 최후를 보여주는 중국소설

"정신승리"는 일종의 정신병입니다. 개나 소나 다 아는 저명한 정신분석학자인 지그문트 프로이트의 딸인 안나 프로이트는 이런 정신병을 "방어기제(Defense Mechanism)"라고 정의했습니다. 한글로 쓸 때는 단어만 봐도 이해하기 쉽게 "자기방어기제" 라고 쓰는 경우도 있습니다. 병이기 때문의 정신병원으로 가서 의학의 도움을 받아야 하는데 당사자는 알지 못하므로 치료를 못 받습니다.

친목의 성향이 있는 모임에서의 대화도 승부의 세계가 돼버리는 경우가 상당히 많습니다만 저 같은 경우는 도저히 참아줄 수 없는 궤변만 끝까지 승부를 보긴 합니다. 그래서 상대방과 한동안 소원해지는 경우도 간혹 있습니다. 그래도 대부분은 그냥 넘어가 줍니다. 상대방이 "죽어도 너한텐 안 진다"의 자세로 돌변하면 져주는 척하면서 진 것도 아니고 이긴 것도 아닌 애매한 상황을 만들면서 주제를 다른 쪽으로 돌려 버리는 수법을 씁니다. 친목 모임이니 대화의 목적은 시작이 시간 때우기였을 경우가 많았기 때문에 중간에 승부의 세계로 변질되었다 하더라도 원래 목적으로 다시 이동시킵니다.

물론 제가 논리적으로 틀린 경우도 꽤 많이 있습니다. 대화를 주고 받으면서 제 논리의 허점을 발견하는 경우가 많습니다. 그럴 땐 당연히 인정을 합니다. 인정을 하는 게 진 건 아니니까요. 그리고 저는 대화를 승부의 세계로 생각한 적은 단 한 번도 없습니다. 승부의 세계가 아닌데 이기고 지고가 어디 있겠습니까? 상대방만 그렇게 생각하고 저를 이겼다고 생각하겠지만요... ^^;

하지만 업무와 관련된 대화는 그래서는 안 되지요. 결론을 도출해내야 할 대화인데도 정말 많은 사람들이 꾸준히 승부의 세계로 대화를 변질시키고 싶어 합니다. 저는 꾸준히 원래 목적인 "결론 도출"로 대화를 다시 되돌리는 시도를 합니다. 어렸을 때는 좀 힘들었습니다. 누구나 원래 성격이란 것이 있으니까요. 그래도 정말 긴 시간 동안 노력하면서 훈련이 된 것 같습니다. 이제는 어느 정도 수월해졌습니다.

제가 상대방보다 확실한 "권위"가 있는 데 상대방이 궤변으로 나오는 경우가 있습니다. 흔한 예로 회사에서 저보다 직급이 낮은 부하 직원과 대화를 하는 경우이며, 명확한 권위에서 제가 우위에 있지만 상대방은 나름대로 자신의 권위가 우위에 있다고 생각하면 자주 발생을 하는데 그 예도 들어보자면 "내가 당신보다는 경력과 직급이 아래지만 이 일에 대한 경험은 더 많다" 입니다. 어떻게 보면 영역싸움이라고 본능적으로 느껴서 그러는지도 모르겠군요. 어디에 대 놓고 이야기는 못해도 자신이 권위에서 우위에 있다고 생각하기 때문에 논리에서 밀리면 이겨야 겠다는 생각에 궤변을 동원하게 되지요.

저는 토론에 "권위" 따위는 사용하지 않으므로 상대방을 찍어 누르는 일은 없습니다. "니가 뭘 안다고 그래?" 이딴 개병신같은 수법은 안 씁니다. 그러다 보니 10분이면 끝날 대화가 2시간을 넘기는 적도 있습니다. 그나마 다행인 건 저의 명확히 우위에 있는 권위 덕분에 상대방이 저를 찍어 누를 수는 없으니 논리적인 대화로 끝을 봐야 합니다. 온갖 궤변이 동원되지만 하나하나 논파해 나가다 보면 몇 배의 시간이 들더라도 결국 상대방도 인정하는 합당한 결론에 도달합니다. 당연히 대화 도중에 저의 논리에서 허점이 나오면 인정하고 즉시 수정하기 때문에 "합당한 결론"이라고 말하는 것입니다. 합당한 결론이 항상 올바른 정답이 되지는 못합니다만 어쨌든 대화의 목적에 부합하고 서로가 인정하면서 마무리가 됩니다.

제논의 역설 : "시간"이란 개념을 왜곡시켜서 논리적으로는 문제가 없어 보이는 궤변이지요. 궤변을 논리적으로 깰 때는 최우선으로 특정 개념을 왜곡시킨 것을 찾아내야 합니다.

상대방이 저보다 명확한 "권위"가 있는 경우도 많았고 앞으로도 많을 겁니다. 이런 경우엔 저를 찍어 누른다면 뭐 어쩔 수 없지요. 눌려 주는 수 밖에요. 하지만 마찬가지로 이런 경우의 대화도 결론을 도출해내야 하는 것이 목적으로 시작된 대화입니다.

"니가 뭘 안다고 그래?" 라고 나오면 "네. 모릅니다" 라고 져줍니다. 권위를 내세워서 이기겠다고 하니 져 줘야지요. 그렇지만 대화의 목적을 이뤄야 하니 "제가 모르는 건 모르는 거고 이 문제는 결론을 내야 하니 그럼 어떻게 해야 할까요?"라고 합니다.

대화를 승부의 세계로 변질시킨 당사자는 당황합니다. 목적을 어이없게 이뤘거든요. 결론을 도출하는 게 아닌 상대방을 이기는 것으로 변질을 시켰는데 그냥 가볍게 이겼으니 목적이 이뤄졌고 갑자기 공허해지면서 가야 할 곳을 찾지 못해 방황합니다.

여기까지 진행되면 다양하게 마무리가 되지만 크게 분류하자면 두 가지 형태로 마무리 되는 경우가 많더라고요.

"좀 더 생각을 해보자"며 토론이 종료됩니다. 자신이 생각할 시간이 필요했겠지요. 논리에 밀리다 보니 지기는 싫어서 승부의 세계로 변질을 시켰는데 시간이 오래 걸리지도 않고 이겨버렸으니 즉시 대항하는 논리를 만들어 내야 하는데 시간이 매우 부족합니다. 그래서 시간을 확보하기 위해서 토론을 종료시켜 버리는 것입니다. 그리고 다음 토론때는 합당한 논리를 만들어 오거나 아니면 적당히 슬쩍 빠져 나갑니다. 승부의 세계로 변질 시키는 이유가 상대방보다 자신이 우위에 있다고 생각하기 때문에 상대방을 인정하기 싫어합니다. 그러다 보니 합당한 논리를 만들어 내지 못할 경우에 적당히 자신은 빠져 나갑니다. 어쨌든 이 경우엔 쓸모 없는 사람이 빠져나가거나 딴지를 걸지 않으니 목적을 이루기가 수월해집니다.

나머지 한 경우는 그냥 개같은 결론을 내 버립니다. 최악처럼 보이는 경우입니다. 그런데 이 최악으로 보이는 일이 실제 현업에서 정말 많이 일어난다는 것이지요. 그대로 진행할 경우엔 일이 망가집니다. 일을 이 지경으로 만든 당사자도 문제라는 것을 압니다. 하지만 죽어도 절대 질 수는 없으니 되돌리지 않습니다. 프로젝트가 망해도, 회사가 망해도 자기가 망하는 것은 아니니까요.

그러면 저는 어떻게 해야 할까요? 예전엔 같은 조직에서 제가 직급이 아래인 경우에 이런 일이 많았거나 몸담고 있는 회사의 거래처와의 토론에서 이런 경우가 있었습니다. 지금은
제가 을인 경우가 대부분일 것이기 때문에 돈만 받으면 되니까 상관없을 것 같기는 합니다만 상대 회사가 망하면 지속적인 매출을 기대할 수가 없습니다. 안 망하더라도 프로젝트가 실패하면 우리 회사의 커리어에도 문제가 있겠군요.

월급쟁이 때 제가 쓰던 대응책은 이럴 경우엔 일단 결론이 나오고 일이 진행되더라도 꾸준히 문제점을 인식시킵니다. 선동할 때 쓰는 기법도 씁니다. "이대로 가게 되면 치명적인 문제가 있고 당신이 그 책임을 다 뒤집어씁니다" 라는 의미가 내포된 다양한 예와 논리를 적당히 들이댑니다. 과하면 안 하느니만도 못하니 수시로 관찰하다가 적절할 때 급소를 찌릅니다. 급소를 찔렸으니 상대방은 잠이 안 왔을 겁니다. 그리고 시간이 흐르면서 스리슬쩍 방향을 바꿉니다.

폭력을 써서 죄송합니다...

어쨌든 이렇게 상대방의 심리를 뒤흔들어서 결국 개같은 방안이 진행되는 것은 막아 낸 경우가 꽤 많았던 것 같습니다. 물론 막지 못한 경우도 있습니다. 자신 있게 이야기할 수 있는 것은 급소를 찔렸는데도 불구하고 막무가내로 진행한 프로젝트는 모두 망했습니다. 많지는 않지만, 분명히 그렇습니다. 그리고 당사자는 지금 어디서 뭘 하는지 주변의 누구도 모릅니다. 인성 자체에 문제가 있는 사람이었기 때문입니다.

중과부적으로 안 좋은 결과로 진행된 것이 몇 번 있는 것 같지만 그래도 대부분은 올바르게 진행된 것 같아서 개인적으로는 만족스럽습니다. 앞으로도 꾸준히 이런 경우들을 겪게 되겠지만 그간의 경험이 도움이 될 것으로 보입니다.

저의 대처법이 정답은 아닐 것입니다. 또 다른 해법도 있겠습니다. 하지만 목적은 변하지 않습니다. 업무에 있어서 결론을 도출해내야 하는 대화는 중간에 엉뚱하게 변질시키려는 시도를 하는 사람이 있더라도 세련된 방법으로 원래 목적에 충실하도록 유도하여 올바른 결론을 도출해내야 합니다.

실무 지향적 개발자, 이론 지향적 개발자 - 실무 지향 성향

"실무 지향적 개발자"

저 "실무"란 단어가 모호하게 다가올 수 있습니다. 왜냐하면, 월급쟁이들은 다 일을 하고 그 일을 "실무"라고 하니까요.

하지만 현실을 봤을 때 일을 한다는 개념부터가 모호합니다. 노동 집약적인 업종은 그나마 모호성이 덜 합니다. 일하는 사람이 잘하든 못하든 움직이면서 뭔가를 하면 일을 하고 있다고 누구나 생각할 겁니다. 물론 계속 움직이면서 회사 일이 아닌 다른 것을 할 수도 있겠지만 오랜 세월 동안 그런 문제에 대한 대비책이 세워져 있으므로 어느 정도 자리가 잡혔다고 볼 수 있겠습니다. 규모가 큰 회사면 관리 시스템으로 파악이 되겠고 작은 회사는 구성원이 적기 때문에 상급자의 눈치로 알 수가 있습니다. 또 생산라인의 결과물 상태를 즉시 확인이 가능합니다.

확인하는 데 1초도 걸리지 않습니다.

이 문제는 기술 집약적인 성격이 강한 업종일수록 모호해지기 시작합니다. 몸을 쓰는 게 아니고 머리를 쓰는 일이다 보니 눈으로 파악하기가 쉽지 않습니다. 눈으로 파악하는 방법은 자리에 잘 앉아 있느냐 밖에는 없습니다. 자리에 앉아있다는 것과 일하고 있다는 것은 전혀 상관없지요.

세계 최초 클로킹 디바이스 : 발 근처에 놓았다가 상사가 등장할 때 밟아주면 일하는 화면으로 전환되는 스위치. 어깨의 움직임이 없기 때문에 권투선수나 야구 타자 출신의 상사도 농땡이를 눈치챌 방법이 없습니다.

결과물 확인도 어렵습니다. 정도에 따라 다르겠지만, 연구와 관련된 업종은 결과물이 나오는 데 5년 이상 걸리는 경우도 있습니다. 결과물이 나와도 판단하기 어렵습니다. 결과물을 봐도 이게 제대로 나온건지 관리자나 결정권자들이 파악이 힘든 경우가 많습니다. 관리자나 결정권자들이 모든 기술을 알 수는 없으니까요. 알아도 5년이나 걸린 일을 세부적으로 검증할 수도 없습니다. 그래서 기술집약적이라는 수사가 붙습니다.

또 상황에 따라 결과물의 조작질도 합니다. 검수하는 사람들이 기술을 모르는 허점을 이용해서 보이는 부분만, 또는 검수하는 항목만 가짜로 처리하여 그 순간만 모면하려는 사람들도 있거든요. 일종의 사기 행위입니다.

소프트웨어 업종도 마찬가지입니다. 노동집약적인 개발은 위에서 언급한 것과 마찬가지로 판단이 쉽습니다만 기술집약적인 개발은 상당히 어렵습니다. 제가 이 글을 쓰는 2017년에도 기술집약적인 소프트웨어 개발은 여전히 경영학적인 측면에서 체계가 전혀 잡혀 있지 않습니다. 그냥 각 기업의 실장 또는 팀장급들이 다들 지맘대로 하면서 지들한테만 해당되는 상황을 모든 회사가 따라 해야 할 진리인냥 자뻑을 날리거나 자신이 대단한 줄 알고 뭔가를 했다가 대실망을 한 후 실패담을 퍼뜨리는 아주 초보적인 수준밖에 안 되고 있습니다.

오늘도 여전히 "실무 지향적 개발자"란 주제로 글을 쓰기 위해서 횡설수설을 아주 길게도 했군요. 이 잡설의 향연이 언제까지 지속될지 저도 모르겠네요.

어쨌던 다른 사람이 눈으로 바로 파악하는 것이 힘들고 시간이 오래 걸려야 결과물이 나오는 일의 성격상 일하는 사람들의 서로 다른 성향이 확연하게 드러납니다.

곰곰이 생각해보면 그럴 수밖에 없습니다. 일의 데드라인이 몇 개월에서 몇 년이나 되는데 아무리 중간 중간에 상황체크를 한다 하더라도 완성된 결과물을 볼 수 없기 때문에 요리조리 빠져나갈 방법은 많이 있습니다.

상대적으로 긴 시간이 주어지고 감시자가 일의 세부 사항을 볼 수 없다보니 각자가 자신의 취향대로 일을 합니다. 사람이 하는 일입니다. 혹시나 나중에 발생할 곤란한 상황은 지금 생각하지 않는 사람이 훨씬 많습니다. 지금 다니는 회사에 목숨 건사람 아무도 없습니다. 그렇게 멀리까지 생각하는 사람 별로 없겠지만, 혹시 안 좋은 결과가 나오더라도 이직하면 된다고 생각하는, 본인도 인지하지 못하는 대응책이 심연 깊은 곳에 있겠습니다. 일은 뒷전이고 인간관계와 스펙쌓기에만 치중하는 사람들은 이런 걸 본능적으로 알고 있어서 그렇다고 볼 수 있겠습니다.

이쯤 되면 이 글의 주제인 "실무 지향"과 "일"은 전혀 별개의 것이 되겠군요. 많은 사람은 자신이 하는 일의 결과물이 망해도 일은 하는 것일 테니까요.

무려 7년을 개발했지만 중단된 소프트웨어

제가 말하는 "실무 지향적인 성향"은 일의 관심이 결과물에 집중되어 있는 것을 말합니다.

소프트웨어 개발을 공부할 때 가장 먼저 나오는 것이 화면에 "Hello World"를 보여주는 것입니다. 1978년에 C언어를 만든 사람들이 쓴 책에 나오는 첫번째 예제다보니 이게 진리로 굳어져서 C언어 말고도 40년이 지난 지금까지도 전혀 다른 언어 교재들까지 첫 예제로 사용한다는 말이 있는데 진실은 저도 모르겠습니다.

개인적으로는 마음에 안 듭니다. 제가 혹시 세계적으로 유명해지고 교재를 쓴다면 개나 소나 차용하는 저런 건 절대 안 쓸 겁니다. 저라면 "I am the King"을 보여주는 것으로 하고 싶네요. 물론 그럴 일은 안 생길 테니 내일부터 까먹을 것 같습니다.

저 "Hello World"를 화면에 보여주는 코드는 너무도 단순합니다. 개발 언어에 따라 다르지만 한 줄 또는 길어봐야 5줄이 넘지 않습니다.

교재에 나오는 것은 그렇고요. 실제로 어떤 언어든 "Hello World" 같은 한 문장을 화면에 보여주는 방법은 수십 가지가 넘습니다. 시각적으로 간단한 방법이 1~5줄일 뿐입니다. 그런 규제를 벗어나면 10줄이 넘을 수도 있습니다. 수십 줄이 될 수도 있습니다.

모든 사람이 효율적으로 일하지 않습니다. 모두가 정석으로 일하지 않습니다. 흔히 말하는 "똘끼"가 넘치는 사람은 일부러라도 엉뚱한 비효율적 방법을 씁니다. 또 짧은 코드가 항상 효율적이지도 않습니다.

소프트웨어 개발은 교재의 제일 처음에 나오는 단순한 것도 이런식으로 생각할 것이 많습니다. 실제 개발은 "Hello World" 출력 따위와는 비교도 안되게 복잡한 것들이 끝도 없이 꼬리에 꼬리를 물고 나옵니다.

이 기본 중에 기본적인 것이 확장되는 도중에 인수인계받은 사람은 지옥이 어떤 곳이라는 것을 알게됩니다.

그런데 우리의 "실무 지향적 개발자"는 복잡한 고민이 필요없습니다. 오로지 결과만 나오면 어떤 방법을 쓰던 상관없습니다. 고민을 안 하니 자신이 즐겨쓰던 방법이나 모르는 부분은 그냥 어디서 보이는 간결한 코드를 그대로 쓰면 됩니다. 더 생각할 가치도 없습니다. 자신이 쓰는 코드에 어떤 철학이나 과정은 전혀 관심이 없습니다. 그냥 잘 돌아가면 됩니다. 할 일이 쌓여있는데 그냥 잘 돌아가면 되는거지 사소한 것에 고민할 정신이 없습니다.

관리자 입장에서는 이런 사람에게 일 시키기가 편합니다. 결과물이 상대적으로 빨리 나오니까요. 알아듣지 못할 복잡한 이론을 내세우면서 이 핑계 저 핑계로 빠져나가려고 수 쓰는 일도 적습니다. 그러다 보니 개발 조직안의 여러 사람중에 "실무 지향적 성향"이 강한 사람에게 일이 몰리는 경향이 있습니다.

관리자의 "관리 능력"이 떨어지거나 관리자가 "관리"에 관심이 덜한 조직일수록 더 그렇습니다. 관리자 직책에 있는 사람이 모두 다 관리 잘 하는 거 아니니까요. 또는 관리자 직책에 있는 사람이 관리 외의 업무도 많이 하느라 정작 "관리"에 신경 쓸 겨를이 없을 수도 있습니다.

"실무 지향적 개발자"는 그렇게 일이 몰리다 보니 매일같이 새로 등장하는 이론에 관심을 가질 시간이 없습니다.

소프트웨어 결과물은 항상 완벽할 수가 없습니다. 오히려 반드시 문제가 생깁니다. "실무 지향적 개발자"는 결과물에 중점을 둔 성격이므로 그 결과물에 발생하는 문제도 당연히 디버깅 및 유지보수에 최선을 다 합니다.

자기가 만들거나 설계해 놓고 디버깅이 싫거나 디버깅할 능력이 안 돼서 쏙 빠져나가는 다른 사람의 일까지 떠맡는 경우가 상상을 초월하게 많습니다. "좋은 관리"에 관심 없는 관리자는 이런 병폐를 해결할 생각을 안 하고 답이 빨리 나오는 "실무 지향적 개발자"가 해결해주기를 바랄 뿐입니다. 그래야 자기가 편하니까요.

병폐가 쌓이고 있습니다. 2017년 현재 유행하는 용어로 "적폐"청산이 안 되고 있습니다. 에이스에게 끝도 없이 일이 몰립니다. 끈기 있는 에이스는 몇 년씩 버티기는 합니다. 비교적 빠른 시간에 결과물을 만들어 내고 성실하게 디버깅 및 유지보수도 하고, 똥 싸놓고 도망치거나 미꾸라지처럼 빠져나간 다른 사람의 결과물이라고 하기도 힘든 똥도 성실하게 고치든지 다시 만들든지 해서 결과물을 내놓고 다시 또 디버깅하고 유지보수를 하고....

이런 악순환이 계속되다 보니 오늘 아침에도 새로 등장하는 이론이나 기술에 관심이 없습니다. 관심을 가질 때도 있습니다만 실무에 적용하기엔 위험부담이 큽니다. 안 해본 것이다 보니 적용에 시간도 오래 걸리고 반드시 찾아오는 시행착오도 익숙한 기술보다 훨씬 심각한 경우도 많습니다. 결과물을 비교적 빨리 내는 성향이다 보니 관리자뿐만 아니고 개나 소나 요구하는 일도 많아서 그런 일 처리하기에도 벅찹니다.

그리고 개고생을 해서 새 기술을 적용하고, 새 기술이다 보니 도움받을 곳도 없는 시행착오를 겪으면서 디버깅과 유지보수를 성실하게 했지만, 어제만 해도 지상 최고의 완벽한 것처럼 여러 매체와 어중이 떠중이들이 떠들어대던 기술이 언제 그랬냐는 듯이 관심에서 멀어지고 사장되면서 그동안 열과 성을 다해서 했던 일이 신기루 같이 느껴집니다.

사막의 오아시스 신기루는 잘못 쫓아가다가는 죽을 수도 있습니다.

그렇게 시간이 흘러가는데 오늘 아침에 또 새 기술이 나왔습니다. 또 여기저기서 호들갑 떨고 자빠졌습니다. 분위기만 봐서는 이 기술 또는 이론이 은하계를 정복할 것 같습니다. 하지만 이런 일에 익숙한 "실무 지향적 개발자"는 심드렁합니다.

이름만 개발자 출신이지, 결과물도 못 내놓는 인간들이 또 사기를 친다고 생각합니다. 개발도 모르는 주둥아리만 나불대는 컬럼니스트, 에반젤리스트, 기자들이 어디서 먹잇감을 발견하고 하이에나처럼 떼거지로 달려들어서 핥아대면서 무슨 맛인지도 모르면서 맛있다는 찬양질을 조작한다고 생각합니다. 그리고 가볍게 무시하고 오늘도 디버깅 및 유지보수, 그리고 개나 소나 요청하는 잡일에 시달립니다.

이런 정황을 깊게 생각해보면 우리의 "실무 지향적 개발자"는 "일"은 잘 합니다. 그리고 그 것 뿐입니다. 타인이 보기에 "실무 지향적 개발자"가 하는 "일"은 그냥 순수하게 코딩하고 결과물을 뽑아내는 것일 뿐입니다. 코딩해서 결과물만 잘 뽑아내지 그 외의 것들은 관심 없는 편협한 사람으로 보이게 됩니다.

"일을 잘한다"란 것은 임원을 포함한 조직 구성원 각자가 모두 다 다른 정의를 머릿속에 내리고 있습니다. 타인과 커뮤니케이션만 잘해도 된다고 생각하는 사람이 있으며, 설계만 잘 하면 코딩은 지나가는 개한테 시켜도 결과물은 좋다고 생각하는 사람도 있고, 신기술은 무조건 알아야 시대에 뒤처지지 않고 일을 잘하는 것이라고 생각하는 사람도 있고, 새로운 것에 관심이 없다면 보수적이고 도태되기 딱 좋은 것이라고 생각하는 사람도 있고...

나열하면 끝도 없습니다. 심지어 아부를 잘하면 일 잘하는 것이라고 생각하는 사람도 있습니다.

"실무 지향적 개발자"도 위에 나열한 모든 것을 잘 할 수 있습니다. 아부도 잘 할 수 있습니다. 하지만 장기간에 걸쳐서 보여준 모습 때문에, 즉 코딩해서 결과물만 잘 뽑아내지 그 외의 것들은 관심 없어 보이는 모습 또는 은하계를 정복할 것처럼 여기저기서 떠들어대는 신기술에 무관심하거나 부정적인 모습을 보이는 행태가 타인에게 각인이 되어 있습니다. 그러다 보니 기회를 얻기가 힘듭니다. 코딩해서 결과물만 뽑아내는 것 외의 기회를 얻기가 힘듭니다. 인식이란 것은 무서운 것이니까요.

이직해서 관리자로 전향한 후 관리자 일을 아주 잘 해내도 이전 직장의 사람들은 믿지 않습니다. 그 사람들의 기억엔 그냥 코딩 잘하는 개미 같은 일꾼 이상도 이하도 아닙니다. "나 이제는 관리도 잘한다"라고 아무리 이야기해도 믿어주지 않습니다. 사람들은 자기가 본 것만 기억합니다. 시간이 흐르면서 자기는 성장했다고 생각하면서도 남도 성장했을 거라는 것을 상상도 못 합니다. 또는 시기 질투심에 인정을 안 합니다.

타인에 대해서 자신이 본 것 외에 내재한 잠재능력이나 성장 가능성을 인정하는 사람은 많지 않습니다. 혹시 그런 능력자가 있다 하더라도 그 사람은 타인의 보이지 않는 부분까지 정확히 파악하여 적재적소에 기용하는 능력으로 이미 성공해서 저 높은 곳에서 놀고 있기 때문에 만날 기회조차 얻지 못합니다. "나 과거에 당신이 보던 사람이 아니다"라고 말할 수 있는 사람이 주변에 있다면 그 사람은 타인의 성장 가능성 따위는 관심도 없고 과거에 자신이 본 잠깐의 것만 믿고 판단하는 그저 그런 사람일 확률이 매우 높습니다.

잠재력을 볼 수 있는 기계지만 샤이어인 잠재력은 못 봅니다.

이 지경이 돼버린 원인은 "실무 지향적 개발자" 자신에게 있습니다. 그리고 제가 발전 가능성을 이야기하긴 했지만, 많은 사람은 장기간 해온 행동 양식과 관념이 바뀌는 경우는 드문 편입니다. 시간이 지나도 코딩해서 결과물만 잘 뽑아내는 것 외에는 발전이 없을 확률이 높습니다. 다른 것도 잘 할 수 있다고 해도 타인이 안 믿어주는 것이 보편적인 관점으로 보면 틀리지 않다고 볼 수 있겠습니다.

그렇기 때문에 변화하도록 지금 당장 시도를 해야 합니다. 어렵겠지만 할 수 있습니다.

자신이 익숙하게 쓰고 좋아하고, 다른 모든 기술보다 뛰어나다고 생각하는 것도 한때는 새 기술로 등장했었습니다. 당시엔 다른 사람이 다른 기술을 똑같이 생각하고 고집했을 수도 있습니다. 그리고 언젠간 도태되는 기술일 수 있습니다. 그러므로 오늘 아침에 등장한 새 기술이나 이론에 관심을 가져야 합니다.

새 기술이나 이론은 매일 나옵니다. 모든 것을 다 관심을 가지고 습득하고 실무에 적용할 수 없습니다. 그렇기에 오늘 아침에 나온 기술이나 이론이 내일 아침에 사라지지 않고 오랫동안 유용하게 쓰이리라는 것을 판단하는 능력도 키워야 합니다. 처음엔 어렵겠지만 그동안 나타나서 오래 가는 기술과 금방 관심에서 벗어나는 기술이나 이론의 세부적인 면을 분석해보는 노력을 하다 보면 그리 어렵지 않게 됩니다.

새 기술이나 이론에 관심을 가지게 된다면 너무 과하지 않게 글이나 말로 타인에게 알리는 행위도 해야 합니다. 그런 어필 없이 자신의 머릿속에만 장롱 안에 있는 황금 돼지처럼 아무도 모르게 고이 간직해서는 의미가 없습니다. 자신이 노력해서 습득한 지식을 사기꾼 떠버리 취급은 받지 않도록 과하지 않게 적당하게 포장하는 행위도 필요합니다.

포장하는 능력도 고급진 기술중 하나입니다.

사기꾼 이야기가 나와서 하는 말인데, 제가 적당히 사기 치는 효과적인 방법을 하나 알려드리겠습니다.

두 사람이 있습니다. 편의상 A와 B라고 하겠습니다. A는 현업 개발자고 B는 현업에서 손을 놓은 지 오래된 관리자입니다. 오늘 아침에도 어김없이 새 기술이 나왔습니다. 당연히 A와 B는 둘 다 아직 그 내용을 모릅니다.

저 때문에 오늘부터 신기술에 관심을 가지게 된 개발자 A는 내용을 읽어보지만, 그 방대한 내용에 질려버립니다. 전체를 이해하는 데 시간이 매우 많이 걸릴 것 같습니다만 출근해서 만나게 될 관리자 B에게 "나는 위대한 개발자다"라고 사기를 치고 싶습니다.

관리자 B를 1년 정도 지켜봤더니 이제 기술습득엔 관심이 없고 관리만 잘 하고 싶어하는 사람입니다. 날카롭고 깐깐한 성격도 아닙니다.

개발자 A는 아침에 읽었지만, 정확히 파악은 안 되는 신기술에서 뭔가 익숙한 듯하지만 모호하고 매력적인 단어를 추려냅니다. 실제하고 상관없는 지맘대로 자의적 결론을 내도 됩니다. 그럴싸하기만 하면 됩니다.

그리고 출근 후에 적절한 미사여구로 그 단어들을 연결하면서 안 날카롭고 안 깐깐한 관리자 B에게 썰을 풉니다. A는 개발자로 일하고 있는 사람입니다. B는 "개발자"가 새 개발기술을 이야기하는데 뭔가 알 듯하면서 그럴싸하지만 이해하는 데 에너지를 쓰기 싫은 소리를 하니 그냥 속 편하게 믿어버립니다. A의 "개발자"라는 현재의 위치가 "권위"가 되는 순간입니다.

이로써 A와 B, 둘 다 모르는 사실을 A가 "개발자"라는 권위를 이용해서 잘 아는 것처럼 포장질을 해서 사기 치기에 성공했습니다.

이 방법은 신문에서 기자들이 자주 써먹는 사기 기법입니다. 기사에서 아래 같은 문구를 자주 접할 겁니다.

"오늘 주식이 개폭락을 한 이유를 유명 애널리스트에게 문의한 결과 세계 경기가 카타르시스에서 헤어나지 못했기 때문으로 진단했다"

"게임 전문가 A씨는 저 게임이 망한 이유를 개발자가 나르시시즘에 빠져서 거울을 보고 코딩했기 때문인것 같다고 진단했다"

"연예계 소식통에 따르면 연애인 Y양과 Z군이 열애에 빠진 것으로 지인들이 밝혔으며 둘은 어젯밤 으슥한 곳에서 비밀스럽게 가위바위보 게임을 한 것으로 알려졌다"

애널리스트가 누구고 게임 전문가가 누구고 소식통이 실제로 존재하는지 알게 뭡니까? 이 기자들은 권위를 이중으로 이용해서 개사기를 치고 있습니다. 본인은 이미 "기자"라는 권위가 있습니다. 제가 글을 쓰면 안 믿는 사람이 많겠지만 "기자"는 그냥 기사를 써도 그대로 믿는 순진한 사람이 많습니다. 하지만 안 믿는 덜 순진한 사람들도 속이기 위해 어디서 팔아먹은지 모르는 가짜 "애널리스트", "게임전문가", "소식통"이라는 권위를 또 더해서 결국 덜 순진한 사람들도 속게 만듭니다.

진실은, 내일 아침에 내보낼 기사를 써야 편집장한테 쪼인트를 안 까이고 이번 달에도 월급을 받을 수 있는데 왜 주식이 개폭락 했는지, 왜 게임이 망했는지, 왜 Y양과 Z군이 비밀스럽게 만나서 뭘 했는지 알 길이 없습니다. 술 약속이 있어서 어서 빨리 나가봐야 합니다. 에라 모르겠다 사기나 쳐야지 하면서 저런 범죄를 저지릅니다. 하지만 믿어 주는 사람이 더럽게 많으므로 아무 문제 없습니다. 내일은 썸녀 또는 썸남하고 만나서 밀당짓을 해야 하니 또 사기 치면 됩니다. 많은 사람이 또 속아줍니다.

권위가 땅에 떨어졌군요. 자업자득입니다.

기술한 대로 이 고급지면서 엔틱한 사기 기법은 제가 고안한 것이 아니고 신문기사를 보다가 자연스럽게 배우게 된 것입니다.

개발자 A는 일단 사기를 치기는 했지만, 이후가 더 중요합니다. 사기 친 것을 안 들키려면 실제로 그 기술을 습득해서 자기 것으로 만들든지, 이직해서 B와 장기간 마주치지 말아야 합니다. 이렇게 사기 친 게 안 들키면 B의 인식엔 A는 결과물도 잘 뽑아내고 아는 것도 많아서 뭐든지 잘 할 것 같은 유능한 미래지향적인 개발자로 남게 됩니다.

"언제나 근면 성실한 내가 저따구로 사기까지 쳐 가면서 살아야 하냐?"

라고 말하는 사람이 분명히 있겠군요. 사장될지도 모르는 신기술 따위를 머리 아프게 익히고 싶지도 않겠습니다. 저런 속임수 개사기 따위는 치지 않고 평생 남이 시키는 개발만 조용히 하면서 살고 싶은 사람이 많을 겁니다. 나쁘지 않은 생각입니다. 틀리지 않은 생각입니다. 그렇게 살 수 있습니다.

다만 삶은 자기 뜻대로 흘러가지는 않습니다.

불의의 상황이 발생하여 현 직장에서 자신의 의지와 상관없이 백수로 내동댕이쳐졌을 때 코딩해서 결과물만 잘 뽑아내지, 그 외의 것들은 관심 없는 편협한 사람, 즉 제가 여태까지 횡설수설한 "실무 지향적 개발자"와 결과물도 잘 만들지만 다양한 지식도 많은 것처럼 보이고 다른 일도 잘 할 것처럼 보이는 개발자는 얻을 수 있는 기회가 완전히 다를 수 있습니다.

그래도 기왕 하는 일인데 좀 더 유능하다는 평가를 받으면서 해도 손해 볼 것이 없습니다. 지식을 습득하고 적당히 포장질도 하고 해도 평생 남이 시키는 개발만 하고 살 수 있습니다.

"실무 지향적 개발자"는 근면 성실합니다. 자신의 결과물에 대한 책임감도 높은 사람이 많습니다. 입으로 자기 잘났다는 포장질을 별로 안 하니 많이 아는 건 없어 보이지만 항상 잘 돌아가는 결과물을 내놓습니다. 문제가 생겨도 금방 해결해줍니다.

경영자나 관리자 측면에서 보면 구성원 중에 이런 개발자의 비중이 높아야 회사가 잘 돌아갑니다. 하지만 이런 개발자가 절대다수라면 생각지 못한 문제에 직면할 수 있습니다. 당장은 회사가 잘 돌아가지만, 항상 그 수준을 넘지 못합니다.

자기 회사의 주력기술이 시장의 관심에 멀어지고 있는데 그것을 인지도 못 하고 하루하루 연명하는 것에 만족하고 살고 있다가 경쟁사가 내일 저녁에 갑자기 신기술을 들고나와 화려한 감언이설로 고객을 뺏어갑니다. 또 신기술인지는 모르겠지만 어느 날 갑자기 등장한 경쟁사가 자기 회사제품보다 압도적으로 성능이 향상된 것이나 시장의 다양한 요구사항에 엄청나게 빠른 속도로 대응할 수 있는 서비스를 들고 나왔는데 무슨 방법을 썼는지 파악할 길이 없습니다. 결국, 또 뺏깁니다.

하루하루 연명하고 있다는 것을 인지하지 못 하고 저런 꼴을 알게 모르게 당하면서 결국 사람들도 하나 둘 씩 나가게 되고 진짜로 간신히 연명하거나 망하게 될 수도 있습니다.

회사에 다니면서 월급을 받는다는 것, 기업을 운영한다는 것은 애들 장난이 아닙니다. 학교 다니면서 이성과 썸타는 놀이하면서 졸업이나 기다리는 것과는 완전히 다릅니다. 세렝게티 평원에서 사자를 피해 다니면서 살아가는 생존입니다.

지금은 귀여워 보입니다만...

어떤 자세로 일할 것인가, 운영할 것인가에 대한 선택은 자신의 몫이며 책임도 자신의 몫입니다.