오제이 튜브(유튜브)에서 인터뷰한 동영상(인터뷰#1)이 올라 왔습니다. 리눅스 커널이 오픈 소스로 어떻게 진행되는지 궁금하신 분은 참고하세요.



https://youtu.be/jP4a99YhOj8

-것
-있는
-있다
-있었다
-에게 있어
-함에 있어
-에 대해
-에 대한
<출처: 내 문장이 그렇게 이상한가요?, 37 페이지>
 
'-것'은 생각보다 중독성이 강하다.
 
<이전>
 
내가 살아 있다는 것에 대한 증거
사랑한다는 것은 서로를 배려한다는 것이다.
 
그 친구가 서로 알고 지낸 것은 어린 시절부터였다.
친구들과 함께 있었다는 것을 이야기했지만 코치는 믿지 않았다.
우리에게 그것은 미래적인 것을 의미했다.
 
그 친구가 무슨 말을 듣고 싶은 것인지 판단하기 어려웠다.
나는 이 도시가 내 고향인 것처럼 생각했다.
위로의 말과 도움의 손길이 우리에게 가장 필요한 것이라고 말할 수 있다.
이제야 난 내가 느낀 분노의 강도가 얼마나 엄청난 것인지 깨달을 수 있었다.
 
실패한다는 것은 단지 출구를 찾지 못했다는 것일 뿐이다.
그가 자신은 별로 한 게 없다고 말한 것은 겸손을 부리는 것과 같았다.
 
<개선>
 
내가 살아 있다는 증거
사랑이란 서로를 배려하는 것이다.
 
그 친구와 어린 시절부터 서로 알고 지냈다.
친구들과 함께 있었다고 이야기했지만 코치는 믿지 않았다.
우리에게 그것은 미래를 의미했다.
 
그 친구가 무슨 말을 듣고 싶어 하는지 판단하기 어려웠다.
나는 이 도시가 내 고향처럼 여겨졌다.
위로의 말과 도움의 손길이 우리에게 가장 필요합니다.
이제야 난 내가 느낀 분노의 강도가 얼마나 컸는지 깨달을 수 있었다.
 
실패한다는 것은 단지 출구를 찾지 못한 것일 뿐이다.
그가 겸손을 부리느라 자신은 별로 한 게 없다고 말한 게 아니었다.

source.codeaurora.org/quic/la/kernel/msm-5.4/log/?h=LA.UM.10.9.1.r1

이번에는 임베디드 혹은 시스템 리눅스 개발과 관련된 이야기를 해보려고 해요. 
 
저는 개발자 뿐만 아니라 취준생 분들과 교류를 하면서 여러 가지 정보를 공유받고 공유하기도 하는데요. 가끔 황당할 때가 있어요. 어! 어떻게 이런 생각을 할 수가 있지? 이런 정보를 어떻게 들었지? 그럼 어떤 황당한 소리를 들었냐고요? 이제부터 이야기를 해볼께요.
 
'리눅스 디바이스 드라이버'는 배울 필요가 없다
 
가장 먼저 들었던 소리는 '리눅스 디바이스 드라이버'는 배울 필요가 없다는 의견을 주신 분들이 있었어요. 앱 개발자 분들은 이런 말을 할 수도 있을 것 같아요. 그런데 임베디드나 리눅스 시스템 분야 개발을 지망하시는 분들 입에서 이런 말이 나오더라고요. 그래서 제가 물어봤죠. 디바이스 드라이버를 배우지 않아도 되는 이유가 뭐에요? 그런데 뭐라고 대답하는 줄 아시나요? SoC 칩 업체에서 안정된 리눅스 드라이버를 제공하기 때문이래요. 이 이야기를 듣고 저도 모르게 나오는 웃음을 참기 어려웠어요. 이게 뭔 소리지?
 
다시 한번 강조하지만 이런 말은 한 사람이 임베디드 리눅스 개발자 지망생이었어요. 그래서 이 친구에게 다시 한번 물어봤어요. 이게 니 생각이냐? 그랬더니 자신이 다녔던 IT 학원 강사가 이런 말을 했다는 거였어요. 취준생들이 IT 강사들이 하는 말을 그대로 믿는다는 게 좀 안타까웠어요. 
 
그래서 제가 그 친구에게 임베디드 리눅스 개발자가 리눅스 디바이스 드라이버를 꼭 배워야 하는 이유를 설명해 줬어요. 그 이야기를 여기서 하면요.
 
먼저 제품을 구성할 때 부품이 바뀔 수가 있어요. 예를 들어 A란 센서 부품에서 B라는 센서 부품으로 변경됐어요. 그럼 B라는 센서의 드라이버를 제품에 맞게 수정해야 해요. 
 
이 때 SoC 칩 업체 개발자에게 B란 센서의 드라이버를 제작해 달라고 하면, 소스를 줄까요? 이런 요청을 하면 아예 들은 척도 하지 않을껄요?
 
두 번째로는 SoC 칩 업체에서 전달하는 드라이버 자체도 100% 안정성이 보장된다고는 볼도 수 없고요. 이건 좀 민간한 이야기기도 한데요. 생각지도 못한 버그가 숨어 있을 수 있어요. 그런데 제품을 개발하는 도중에 버그가 나오면 SoC 칩 업체 개발자가 그 버그를 잡아 줄까요? 물론 개발하려는 SoC 칩에 대한 기술 지원 비용을 지불한다면 가능하겠죠.
 
그런데 생각보다 SoC 칩에 대한 기술 지원 비용을 내지 않고 개발하는 프로젝트가 은근히 많아요. 이런 상황에서는 제품 개발자가 SoC 칩 업체에서 전달된 드라이버 코드를 수정해야 되죠.
 
또한 디바이스 드라이버를 모르면 부팅 시간이라던가 디바이스의 실행 시간을 최적화하는 작업을 진행할 수 없어요. 리눅스 시스템 프로그래밍으로 이런 작업을 할 수 있다고 주장하시는 분도 있는데요. 사실 시스템 프로그래밍은 직접 하드웨어를 콘트롤 할 수 없으므로 한계가 있어요.
 
스케줄러 코드를 수정할 필요가 없으니 리눅스 커널은 배울 필요가 없다
 
이어서 제가 들었던 황당한 이야기를 해볼께요. 리눅스 시스템 개발 업계에서 이런 소리를 하시는 분들이 있는데요. 스케줄러 코드를 수정할 필요가 없으니 리눅스 커널은 배울 필요가 없다는 소리를 해요. 작년까지만 해도 2000년대 초반에 임베디드 개발을 시작했다가 리눅스에 적응하지 못했던 퇴물 개발자들로부터 이런 소리를 들었는데요. 요즘에는 주니어 개발자들의 입에서 이런 말을 들을 때 '약간 어이가 없다'는 생각이 좀 들었어요. 참 꼰대는 나이를 초월해서 존재한다는 생각도 드는데요. 
 
'리눅스 커널의 스케줄러 소스 코드를 수정할 필요가 없다' 맞는 소리죠. 다른 해야 할 일이 얼마나 많은데요. 이런 말을 하면서 차라리 리눅스 커널에서 실전 개발에 도움이 될만한 내용을 잘 배우자라고 주장하면 수긍할꺼에요. 저도 비슷한 생각이거든요. 리눅스 커널의 내용은 너무 방대해서 먼저 배우면 좋은 내용부터 배우자란 말에 동의해요. 그런데 리눅스 커널은 배울 필요가 없다라는 주장에는 전혀 동의할 수가 없어요. 
 
리눅스가 어떻게 돌아가는지 시스템 개발자 수준으로 알려면 리눅스 커널의 기본 동작 원리는 알아야 해요. 이걸 모르고 알고는 엄청난 차이에요. 또한 리눅스 드라이버나 리눅스 시스템 프로그램으로 하드웨어를 제어해도, 이런 프로그램의 동작 원리를 깊게 파고 들어가면 만나는게 리눅스 커널이거든요. 그리고 리눅스 디바이스 드라이버는 리눅스 커널에서 제공하는 API로 구성돼 있어요. 그러니 리눅스 커널을 모르면 리눅스 디바이스 드라이버 자체를 제대로 개발할 수가 없죠.
 
그렇다면 리눅스 디바이스 드라이버를 배울 필요가 없다. 리눅스 커널을 배울 필요가 없다는 소리를 하는 이유는 뭘까요?
 
이런 소리를 IT 강사들이 한다면, 리눅스 커널 드라이버가 리눅스 커널을 제대로 가르칠 능력이 안되기 때문일 꺼에요. 학생들이 리눅스 커널에 대해 질문을 하면 '그거 SoC 칩 업체에서 전달하는 거니 잘 몰라도 돼'라고 대답하는 거죠.
 
실제 현업에서는 리눅스 디바이스 드라이버를 배울 필요가 없다는 소리보다 리눅스 커널을 제대로 배울 필요가 없다는 소리를 더 자주 듣는데요. 개발자보다 관리자 즉 매니저들이 이런 말을 더 자주 할 가능성이 높아요. 저도 그랬고요.  이렇게 말하는 가장 큰 이유는 조금은 극단적인데요. 개발자를 오로지 비용 관점으로 관리하기 때문이에요. 회사에서 100원을 투자하면 120원만큼 개발자가 일을 하기 원하는 경우가 있거든요. 그런데 개발자가 리눅스 커널을 배우는데 시간을 투자하면 회사 입장에서는 손해라고 생각하는 거에요. 왜냐면 리눅스 커널은 며칠 배운다고 바로 티가 나지 않거든요. 뭔가 개발자의 기초 체력을 키운다란 느낌이에요.  
 
이렇게 제가 대본까지 써가면서 이런 콘텐츠를 만든 이유는, 취준생들이 왜곡된 정보를 듣고 잘못된 방향으로 커리어를 선택할 수 있이 때문이에요.

 

이렇게 제가 이런 글을 쓴 이유는, 취준생들이 왜곡된 정보를 듣고 잘못된 방향으로 커리어를 선택할 수 있기 때문이에요. 이런 왜곡된 정보를 참고해서 리눅스 디바이스 드라이버나 리눅스 커널에 대해 아무런 공부를 하지 않은 체, 면접을 볼 수도 있거든요. 운이 좋게 면접에 통과 하면 좋겠지만 면접에서 리눅스 디바이스 드라이버나 커널에 대해 조금이라도 배운 경쟁자가 있다면 바로 탈락하겠죠.
 
SW 업계에서 배울 필요가 없는 지식은 없고 우선순위만 있을 뿐이다.
또한 IT 개발자가 배울 필요가 없는 지식은 없는 것 같아요. 리눅스 시스템 개발자라도 해도 파이썬으로 애플리케이션을 코딩하는 것 배울 필요가 없는 건 아니에요. 시간이 있으면 배우면 좋지만, 우선 순위라는 게 있잖아요. 뭐 arm 프로세서나 하드웨어와 같이 더 중요하게 익혀야 하는 테마가 있잖아요.

 

 

https://youtu.be/ESq8GJ3bCz8


트러스트 존에 대한 이야기를 조금 하려고 합니다. 너무 기술적인 이야기는 빼고요.
 
대부분 트러스트 존하면 Arm 프로세서에서 제공하는 보안 기능이란 생각이 머릿 속에 떠오르는 경우가 많습니다.
이번에는 TZ의 기술적인 측면이 아니라 비즈니즈적인 혹은 사업적인 측면에 대해 이야기해볼까요?
 
arm 프로세서의 높은 가격 경쟁력 유지
 
어떤 제품에서 보안 기능이 필요 없어 트러스트 존을 사용하지 않아도 됩니다. 간단한 전자 명함이나 온도계는  해킹을 시도하지 않고, 해킹을 당해도 큰 문제가 발생하지도 않습니다. 특히 IoT 디바이스는 가격 경쟁력이 중요한데 보안과 관련된 프로그램을 개발하면 개발비가 더 많이 들겠죠.
 
하지만 보안 기능이 필요없거나 보안이 필요없는 제품에도 트러스트 존이 탑재된 Arm 프로세서를 사용하는 경우가 많습니다. 
 
그 이유는 무엇일까요? Arm 홀딩스는 자신의 제품을 팔 때, 트러스트 존이란 기능을 끼워 파는 경우가 많기 때문입니다.
그냥 시장에 트러스트 존이 활성화된 Arm 프로세서 제품군을 내 놓는 것입니다. 
 
또한 가끔 Security 관련 기능을 대폭 강화하면서, Arm사의 Sales Manager는 다음과 같이 말합니다.
 
   " 보안이 중요하니 이런 기능(크립토 엔진 업데이트, 기타 등등)이 업데이트됐다."
   " Security Hole(보안의 헛점)이 있으면 안된다. "
 
이런 이야기를 할 때 보안이 뚫리면 기업이 얼마나 큰 손해를 보는지에 대한 데이터도 첨부합니다.
하지만 조금 삐딱한 시선으로 바라보면, 이들이 하는 말은 다음과 같이 해석할 수도 있습니다.
 
   " 이번에 우리가 파는 Arm 프로세서에는 이렇게 좋은 기능이 추가됐어. "
   " 그러니 우리가 돈을 더 받아야 겠다. "
 
Arm 프로세서의 가격을 협상하거나 가격을 높게 받을 때 사용되는 카드 중 하나가 트러스트 존 혹은 보안 기능입니다. 이처럼 시장에서 필요하지 않는 기능인데, 솔류션 업체가 높은 가격에 자사의 제품을 판매하기 위해 개발하는 기능이 생각보다 많습니다.
 
arm 프로세서의 높은 라이선스 가격 경쟁력 유지
 
또한 Arm 사에서는 다양한 방식의 라이선스를 배포합니다. 그 중 하나가 트러스트 존을 활용해 SoC 시스템 아키텍처를 설계할 수 있는데요. 예를 들면 SoC 벤더(퀄컴, 엔비디아) 입장에서 보호해야 할 메모리 공간은 시큐어 월드에서만 접근할 수 있습니다. 그런데 이런 기능도 Arm 사에서 제공하는 라이선스를 이용하면 쉽게 SoC를 설정할 수 있습니다. 
 
Arm 사는 SoC 벤더가 보안과 관련돼 어떤 기능을 추가할 지에 대해 많은 고민을 하고, 이들이 필요한 보안 기능을 트러스트 존에 추가합니다. 또한 SoC 벤더가 자신만의 Secure OS를 개발해 Maintain하려면 많은 개발비가 든다는 사실도 알고 있습니다. 이런 요구 사항을 파악한 후 트러스트 존의 라이선스를 개발합니다. 그리고;
 
    "arm 프로세서의 라이선스에 대해 높은 가격을 책정합니다."
 
Arm 사 입장에서 트러스트 존은 높은 라이선스 비용과 Arm 프로세서 가격을 받아 내기 위한 중요한 기능입니다. 그래서 꾸준히 트러스트 존의 기능을 업데이트 해 왔습니다.

난 신입 사원 연수 과정에서 이 회사의 경영 이념에 대해서 알게 되었고 이 후 수 없이 귀가 따갑도록 많이 듣게 되었다. 난 그 당시 참 순진했었다. 이 회사가 경영 이념대로 운영되고 있다고 철썩 같이 믿었다. 이 회사가 이 경영 이념에 따라 의사결정이 되고 임직원을 대한다고 생각했다.

난 다른 회사의 경영 이념에 대해서도 읽었다. 다른 회사들의 경영 이념도 읽어보면 뭐듣기 좋은 문구는 다 가져다가 놓은 것 같다. “창의적, 도전적 인재, 창조적 발전, 인격체로 구성원을, 존중을 하는, 어쩌구”.

난 부서에 배치되고 난 이후에 처음 직속 임원 간담회에 참석했었다. 그 분은 간담회에서 ‘일찍 퇴근해라, 푹 쉬어라, 휴가 잘 다녀와라, 가정적인 남편이 되라’라고 말씀하시면서 온화한 미소와 함께 진심으로 임직원을 보살피는 것 같았다. 마치 경영이념대로 행동하시는 것이었다 그 당시 난 그 분의 미소를 잊지 못한다. 마치 부처님의 얼굴에서 우러나오는 미소 혹은 기도하고 있는 수녀님의 눈길을 느꼈기 때문이다. 난 진심으로 그 분이 훌륭한 경영자라고 생각했다. 딱 1달 동안만.

하지만, 부서에 배치가 된 후, 1년 만에 난 이 경영 이념이 허울이라는 것을 깨닫게 되었다. 회사의 본심을 알아채기 까지 많은 시간이 걸리지 않았던 것이다. 부서장들은 노골적으로 야근 특근을 강요하였으며 개인의 사생활에 대해서는 아예 관심조차 가지지 않았다. 대부분 야근, 특근을 밥 먹듯이 하면서 미친 듯이 일만 하는 일중독자들을 핵심인재로 바라보았다.

왜 회사는 실상과 거리가 먼 이런 경영이념을 공표하고 부르짖을 까라고 의문을 갖기 시작했다. 이 의문을 풀기 위해 우선 회사란 무엇인가란 질문을 스스로 던졌다. 이런 의문을 갖고 계속 회사를 다녔다.

오래 되지 않아 난 나의 직속 임원이 회사란 개념의 실체라고 확신을 했다. 임원의 뜻은 회사의 뜻, 임원의 결정의 회사의 메시지인 것이다. 임원의 모습을 회사의 모습인것이다.  회사는 CEO가 운영을 하며 임원들은 CEO와 가장 코드가 맞는 혹은 그 이상의 CEO와 운명을 같이 하는 마치 광신도와 같은 사람들로 발탁되는 것 볼 수 있었다.

일단 이 회사의 임원들은 우선 정규직이 아니다. 대부분 2~3년 단위로 계약을 하며 실적이 안 좋을 때 단칼에 목이 날라가곤 한다. 보통 임원들에게는 달성하기 쉬운 목표는 거의 주어지지 않으며 대신 현실적으로 실현 불가능한 목표만 주어진다. 임원들이 스스로 조금이라도 안이한 목표를 설정하면 CEO는 바로 집으로 가라고 한다. 난 저번에 나의 직속 임원의 다이어리를 본 적이 있다. 일부러 보게 하셨지만. 난 평사원들이 모르는 격이 다른 메모가 있을 것이라 예상을 했었다. 그런데 그 내용은 대부분 아래와 같았다.

'xxx 못하면 나 집에 감', 집에 가라고 함. 집에 가야 하나?

이렇게 불안정적인 자리에서 일하는 임원들이 진심으로 임직원들에게 ‘6시에 정시 퇴근을 하고 충분한 휴식을 취하고 웰빙을 즐기라’라고 말할 수 있을 까? 속 마음은 모든 직원들이 미친 듯이 일을 하고 하고 또 해서 마치 마약 중독자의 수 십 배의 일중독에 걸려있기를 바랄 것이다. 나라도 그럴 것 같다. 이런 위치에 있는 임원들에게 있어서 경영 이념이란 어떻게 들릴 까? 단지 허상일 뿐일 것이다.

그럼 왜 듣기 좋은 경영이념을 만들까? 사람들에게 이 회사를 좋은 모습으로 볼 수 있도록 꾸며낸 것이 아닐까?
난 아직 그 이유를 잘 모르겠다. 

임베디드 BSP 개발자들은 언제 답답함을 느낄까요? 
야근을 할 때 일까요? 사채업자와 같은 매니저가 찾아와 목에 칼을 들이 대면서 말도 안되는 일정으로 윽박지를 때인가요?
이런 상황은 짜증이 조금 나긴 하지만 그나마 버틸만 합니다.
 
임베디드 BSP 개발을 진행하다가 가장 암담함을 느낄 때는, 뭘 배우고 공부를 해야 실력을 키울 수 있을 지 모를 때입니다. 실력을 키우는 방법을 모르는 상황이죠. 아마 안개 속에서 보이지 않는 적과 싸우는 느낌일텐데요.
 
이런 임베디드 BSP 개발자가 어떻게 하면 실력을 키우는 되는지 주위 선배들에게 물어 보면 속 시원하게 대답을 해주지도 못합니다.
 
위에서 언급된 임베디드 BSP 개발자가 저였습니다. 이런 암담함을 초보 개발자 시절에 3년 정도 겪었습니다. 개발 도중에 크래시가 발생하면 매니저는 "옥상에서 뛰어 내리라고 했는데, 그 때 가장 답답했던 것은 "뭘 배워야 욕을 덜 먹을지 몰랐다"는 점이었습니다.
 
(그 당시 트라우마가 아직도 남아 있어, 저는 옥상에 잘 가지 않습니다.)
 
시간이 지나고 보니, 임베디드 BSP 개발자로써 실력을 키우기 위해 배워야 할 지식이 무엇인지 천천히 알게 됐습니다. 그 목록을 정리하면 다음과 같습니다.
 
   * 디버깅 스킬(TRACE32 혹은 하드웨어 디버거)
   * Arm 아키텍처(특히 익셉션, 메모리 시스템)
   * SoC에 대한 지식(특히 Stability Architecture, Boot Sequence)
   * 리눅스 커널
종종 현업 개발자들이랑 만나면, 듣는 이야기가 있습니다.
 
   "개발자로써 커리어를 관리하기 어렵다."
   "지금 하고 있는 개발 스킬을 다른 회사에서 활용할 수 있을까?"
 
개발자들끼리 조금 진지하게 대화를 나누면 나오는 주제입니다. 물론 저도 이런 고민을 수도 없이 했는데요. 종종 "개발자로써 커리어를 관리하기 어려운 이유가 무엇인가"에 대해 생각해 봤습니다. 가끔은 다른 회사의 임원이나 관리자분들을 만날 기회가 있었는데, 그 분들과 대화를 나누니 무엇인가 퍼즐이 맞춰진다는 느낌을 받았습니다.
 
그 퍼즐은 바로 "개발자의 커리어 관리"입니다.
 
많은 분들이 취준생들에게 어찌보면 포괄적이고 두루뭉실한 조언을 많이 합니다. 그것은;
 
    "열심히 노력해라. 노력한 만큼 보상이 주어지는 게 소프트웨어 개발이다."
    "개발자로써 실력을 키우도록 노력해라."
 
틀린 말은 아니지만, 저에겐 뭔가 공허한 소리로만 들리는데요. 그 이유에 대해 조금 더 말씀드리겠습니다.
 
개발자들은 부서장들의 성과를 위해서만 존재한다
 
개발자로써 커리어를 관리하고 키우기 전에 먼저 알아야 할 핵심이 있습니다.
 
   "개발자들은 부서장들의 성과를 위해서만 존재한다."
 
한국에 있는 대부분의 IT 회사들은 위에서 언급한 규칙에 따라 움직이게 되어 있습니다. 여러분들은 여러분의 상사를 위해 존재한다는 말입니다. 이런 문장을 읽으면 물론 불쾌한 느낌이 들기 마련인데요. 조금은 듣기는 거북해도 맞는 말이란 생각이 듭니다. 쓴 약이 몸에도 좋다는 말이 있잖아요.
 
매니저들이나 부서장(대부분 개발자들의 상사)들은 개발자들에게 다음과 같이 조언합니다.
 
   "개발자로써 역량을 키우는게 중요하다."  
 
개발자들이 매니저에게 이런 말을 들으면 "그래, 개발자로써 실력을 키우는 게 중요하지. 열심히 공부해야 겠다"란 생각이 들 것입니다. 그런데 부서장들의 속 마음을 디버깅해보면 그들이 정말로 하고 싶은 메시지는 다음과 같습니다.
 
   " (나의 성과를 위해) 개발자로써 역량을 키우는게 중요하다."  
 
부서장 입장에서는 자신의 성과를 달성하는게 가장 중요합니다. 첫 째도 성과, 두 번째도 성과입니다. 이를 위해 필요한 조건 중의 하나가 개발 역량인 겁니다. 그런데 부서장은 한술 더 떠서 다음과 같은 이야기를 합니다.
 
   " 개발자로써 전문성을 유지하고 키워나가는 게 중요하다."  
 
하지만 이들의 속마음을 들여다보면 "나의 성과를 이루기 위해 내 부서에 있는 개발자들이 전문성을 키웠으면 한다" 진심입니다.
 
니가 나를 위해 일하지 않고, 니가 크려고 해!
 
그런데 가끔 개발자 중에 전문성을 키우다가 "개발자가 소속된 부서의 성과"를 내는 것 이상의 실력을 키우는 경우도 있습니다. 개발자로써 역량을 끌어올리다 보니 전문성이 계속 증진되는 경우입니다.
 
예를 들면, 리눅스 커널에 컨트리뷰션(기여)를 한다던가, 컴파일러 코드를 개선해 뭔가 성능을 개선하는 것을 들 수 있습니다. 가끔은 공부한 내용을 잘 정리해 책을 출간하기도 합니다.
 
그런데 거의 대부분의 부서장들은 자신의 성과에 직접적인 결실을 맺을 수 없는 개발 역량을 키우는 것 별로 좋아 하지 않습니다. 물론 책을 쓰는 것을 싫어하는 분들도 많습니다.(이 사실을 제가 출판사 사장님께도 들은 내용입니다.) 그 이유는 간단합니다.
 
    "자신을 위해 일을 하지 않기 때문입니다."
 
부서장들은 자신도 모르게 이런 생각이 들 겁니다.
 
   "니가 나를 위해 일하지 않고, 니가 크려고 해!"
   "그건 내가 용납할 줄 알아?" 
 
극단적으로 말해, 부서장은 자신의 성과를 위해 개발자 여러분이 어떤 개발 역량을 갖추었는지 관심을 갖습니다. 자신의 성과를 위해 여러분이 존재할 뿐인 것이죠.
 
대부분 IT 업체는 부서장의 성과를 중심으로 운영됩니다. 이 점을 염두에 두면 그 동안 이해되지 않았던 많은 부분이 명쾌해질 것입니다.
연말이 되면 직장인을 포함해, 많은 개발자들은 자신들이 얼마나 많은 인센티브를 받을 지 기대합니다. "연봉의 몇 프로를 받을 것 같다"와 같은 이야기를 하죠. 하지만 이건 카메라 앵글 중에 밝은 부분만을 포커스로 잡은 것이라 볼 수 있습니다.
 
사실, 많은 임원들이 12월달에 짤립니다. 자기는 당연히 연장(물론 계약이죠)될 걸로 믿었던 임원들이 집에 갑니다. 또한 회사의 오너가 쓰는 펜 끝에서 수 십명에서 수 백명의 인원이 체스판 말들처럼 옮겨집니다. 이 인원들에게 일자리가 있으면 다행이긴 하지만 아닌 경우도 상당합니다.
 
이런 상황에서 직장인이나 개발자 분들은 동료에게 카톡으로 인센티브 몇 퍼센트 받았냐고 물어봅니다. 예상보다 적게 받으면 서로를 위로해주고 회사를 욕하기도 하죠. 이런 글을 읽다가 파울로 코엘료의 '연금술사'라는 책에서 현재 상황을 투영하는 부분이 떠오르네요.
 
바로 주인공인 산티아고가 자신이 기르는 양들의 모습을 보면서 드는 생각을 언급한 부분인데요.
양들은 단지 맛있는 먹이와 물만 제대로 제공하면, 자기 동료 양들이 털이 깎이고 도축되는 걸 보고도, 그 최악의 상황이 자기 차례가 될 때까지, 그저 물과 먹이에만 만족하도록 길들여져 있다는 겁니다.
 
물론 1년 동안 소속된 조직의 기준에 맞게 일을 잘해서 좋은 평가를 받고, 인센티브를 연봉의 몇 퍼센트라도 더 받은 직장인이나 개발자 분들에게 "축하드립니다"라고 말씀드리고 싶어요. 하지만 정말 중요한 건 이런게 아닌 것 같아요. 
 
정말로 정말로 무서운건; 
 
   소속된 조직의 매니저나 평가자들의 눈에 들지 못해, 인센티브를 더 받지 못하는 게 아니라, 
   이 양들처럼 길들여져서 주위 동료들 짤려나가는 순간까지도 자기 몫의 먹이(인센티브)에만 시선이 고정되는 겁니다.
 
어쩌면 그게 조직의 의도일 수 있다고 봅니다. 자신의 캐리어를 멀리 내다 보지 못하고, 양들이 자신이 먹을 먹이에 길들여져 있는 것 처럼 코 앞의 연봉과 인센티브에 연연하게 만드는 것이죠.
 
이번에는 조금 더 다크한 부분으로 카메라의 앵글을 비춰 볼까요?
 
조직에서 평가자의 입장에 있는 매니저들은 연말 평가 기간이 되면 자신에게 무슨 막강한 권한이 있는 듯 착각하곤 합니다.  연말 평가와 관련된 면담을 할 때 자신이 무슨 판결문을 낭독하는 판사가 된 듯한 착각에 빠지면서 다음과 같은 훈시를 합니다.
 
    * 1년 동안 아무것도 한 일이 없네! 
    * Jira에 있는 로그 분석은 거의 쓰레기 수준이야.
 
자신이 살아남기 위해, 혹은 자신의 성과를 위해, 구성원들을 필요 이상으로 위협하고 억압하는 것이죠. 
그래서 매니저들은 오로지 자신의 성과를 위한 상황과 수준에 맞게 개발자들을 몰아갑니다. 양들을 몰고 먹이를 주듯이 말이죠. 
 
하지만 현실은;
 
    * 말 잘 듣는 개발자를 이용해먹고, 상황 안 좋아지면 가차없이 내칩니다!
 
왜냐면 평가자의 입장에 있는 매니저들도 언제 짤릴 지 모르는 처지기 때문이죠. 개발자를 억압하는 매니저들도 자신의 상사 앞에서는 개처럼 비벼대고 굽신거릴 수 밖에 없는 입장입니다.
 
가끔 평가를 받는 개발자나 직장인들은 이런 알량한 평가 지표(오로지 매니저의 성과를 위한)를 위해 동료들끼리 편가르고, 질시하기도 합니다. 이런 걸 매니저들이 조장하기도 하는데요. 이런 분들에게 다음과 같이 말씀드리고 싶어요.
 
   "조직 생활이 마치 인생의 전부인 양 길들여지길 바라는 조직의 울타리나 프레임에 갇히지말고, 자신의 인생에서 
    자신이 주인공이 되는 삶을 사는 것은 어떨까요?"  
 
자신이 속한 조직이나 회사가, 여러분의 목을 쥐고 흔드는 상황이 되기 전에, 스스로 언제든 마음만 먹으면 회사를 떠날 수 있는 준비를 해보는 것도 좋을 것 같아요. 인센티브 몇 퍼센트에 너무 집착하지 않고, 스스로 자신의 캐리어를 설계하고 독립하는, 어디에서도 인정 받을 수 있는 능력을 키우는 데 더 많은 시간을 투자하는 게 좋지 않을까요?

+ Recent posts