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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

출처 : 구글 이미지 검색

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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