5년차 이상의 개발자 분들에게 꼭 전하고 싶은 메시지가 있습니다. 그것은 바로 다음과 같아요.
 
    * 용기를 내서, 더 좋은 조건에서 개발할 수 있도록 이직에 도전하세요.
 
갑자기 무슨 소리냐구요? 쉽게 말씀드리면 '용기를 내서 자신의 캐리어를 경쟁력있게 관리하고 이를 발판으로 기회가 되면 더 좋은 회사로 이직을 준비하라'는 말씀입니다. "왜 갑자기 이런 소리를 하는지"라며 의아해 할 수 있을 것 같은데요. 이제부터 이야기를 풀어 보겠습니다.
 
회사에 불만을 품은 개발자들
 
책을 출간하고 나서 여러 개발자들과 교류를 하게 되는데요. 저보다 나이가 많던 적던 여러 개발자들과 대화를 나누다보면 느끼는 점이 하나 있습니다. 바로 "자신이 다니고 있는 회사에 불만을 품고 있다"라는 점입니다. 처음 만나면 어색한 분위기에서 커피를 한잔 마시면서 기술적인 이야기를 주로 하는데, 시간이 지나 술이 들어가면 진지한 속 마음을 들어내는데요. 대부분 자신이 몸담고 있는 부서나 회사에 대한 이야기를 합니다. 어떤 분들은 회사 자랑을 하지만, 이런 경우는 거의 없는 듯 합니다. 한도 끝도 없이 회사 욕을 하는 경우가 많죠.
 
"회사에 비전이 없다"는 기본이고 "매니저가 돌대가리다"는 불만을 서슴치 않고 표출합니다. 특히 관리자들이 얼마나 멍청한지에 대한 스토리는 한도 끝도 없는 것 같습니다. 개발자의 불만은 해수욕장의 모래와 같이 한도 끝도 없지만 개발자의 가장 중요한 캐리어 관리 측면에서 불만의 내용은 크게 다음과 같이 요약할 수 있어요.
 
   * 개발자로써 전혀 발전이 없다.
   * 연봉이 낮다.
 
지금 다니고 있는 회사에 비전이 있고 리더쉽이 있는 매니저와 실력이 뛰어난 동료와 함께 일하는 것도 중요하지만, 사실 이는 개발자의 캐리어에 핵심 요소는 아니거든요. '실력'과 '연봉'이 개발자 캐리어를 관리하는데 가장 중요한 척도인 것 같습니다. 이 밖에 개발자에게 더 중요한 게 있을까요?
 
기술적인 발전이 없는 개발하는 하는 경우
 
많은 개발자들이 현재 개발을 하면서 기술적인 발전을 이룰 수 없다고 불평을 합니다. 틀에 밖힌 개발을 하는 것이죠. 소프트웨어는 분야가 넓기 때문에 구체적인 예시를 들기는 좀 어려운데요. 기계적으로 깃 머지를 하거나 손머지 혹은 다른 업체가 개발한 소스를 인테그레이션(Integration)해서 테스트를 돌리는 작업이 예시가 될 수 있습니다. 
 
이런 불만을 표출하는 분들에게 워라벨이 어떠냐고 물으면, 대부분의 경우 워라벨은 만족스럽진 않지만, 그나마 참을만 하다고 말합니다. 예를 들면, "주말 특근을 전혀 안 한다"거나, "야근을 하지 않고 7~8시면 퇴근할 수 있다"를 들 수 있겠네요. 그럭저럭 워라벨은 나쁘지는 않습니다.
 
하지만 개발자로써 기술적인 발전이 없는게 문제입니다. 틀에 밖힌 기계적인 개발 업무를 지속하니 보람을 느끼지 못하는 것이죠. 그래서 퇴근을 할 때가 되면 뭔가 불편함을 느끼며, 가끔 다음과 같은 생각이 듭니다.
 
   * 개발자로써 도태되는 것 같고 실력도 거의 늘지 않는데 회사 밖에서는 개발자로써 명함을 내밀 수 있을까?
 
심리적으로 모기를 물렸는데 약간 가려운 느낌과 비슷하다고 볼 수 있겠네요. 이런 느낌이 들면 가끔 비슷한 불만을 갖는 동료들끼리 술을 한잔합니다. 술을 마시면서 동료들이 자신의 불만을 들어주면 동질감을 느끼면서 뭔가 후련한 느낌이 듭니다. 수다를 떠는 순간만큼은 이런 불만과 불안감에서 벗어날 수 있습니다. 
 
그런데 문제는 "이런 불안감과 불만을 갖고 불만이 있는 업체에서 계속 개발을 한다"라는 겁니다. 그 이유는 무엇일까요? 
 
    * 바로 이런 불안감과 불만은 참을만 한 수준이기 때문이죠. 
 
도저히 견딜 수 없을 정도의 불만은 아닌 겁니다. 그러면서 "그래, 모든 개발자들의 나와 같은 패턴의 개발을 할꺼야", "회사에서 열심히 일하면 되는 거지"라면서 스스로를 위로합니다.
 
결국, 기술적인 발전이 없는 개발 업무를 하면서 3~5년 동안 계속 같은 회사에 다니거나 비슷한 패턴의 일을 하는 회사로 옮겨서 같은 패턴의 프로젝트에 투입돼 개발을 합니다. 그러다가 보면 나이는 어느 새 40대가 됩니다.
 
연봉이 낮다는 불만을 가진 개발자
 
다음으로 개발자들이 많은 불만을 품는 이유는 '연봉이 낮다'라는 점입니다. 연봉이 낮다는 불만을 표출하는 분들의 이야기를 조금 더 들어보면, 대부분의 개발 업무의 난이도가 낮은 경우가 많습니다. 왜나면 그 분들이 스스로 자신이 하고 있는 개발 업무의 난이도가 낮다고 말하거나, 개발 업무의 내용을 들어보면 저도 그렇게 느낄 때가 많거든요. 물론 자신이 연봉을 낮게 받는다고 느끼는 개발자들의 기술적인 난이도가 낮다는 것은 아닙니다. 그냥 이런 경향이 있다는 것이죠.
 
연봉이 낮은 개발직의 경우 대부분 기술적인 발전을 기대할 수 없는 개발을 할 가능성도 있습니다. "업계에서 가장 어렵고 도전적인(cutting edge) 난이도의 프로젝트를 해당 IT 업계 기준으로 낮은 연봉을 받는 개발자가 리딩한다"라는 뉴스를 들어본 적이 있나요? 아마 많지는 않을 겁니다. 실력있고 포부가 있는 개발자들은 무엇인가 도전적인 프로젝트를 하고 싶은 경우가 많은데, 대부분의 경우 높은 연봉을 주는 IT 업체로 몰리기 마련입니다.  
 
아무튼 낮은 연봉을 받는 개발자들은 항상 연봉을 낮게 받는다는 불만을 가진채 개발을 합니다. 꾸역 꾸역 불만을 품은 채 계속 회사에 다닙니다. 물론 워라벨에 불만이 없는 것은 아니지만 그래도 참을 수 있을 정도입니다. 
 
결혼을 하고 가정을 꾸리면 이런 불만을 상쇄할만한 좋은 핑계거리가 생깁니다. 
 
   * 그래, 워라벨이 중요하지 돈을 많이 벌면 뭐해?
   * 가족과 함께 여유로운 시간을 보내는 게 중요한 거야.
 
가끔은 때로는 낮은 연봉을 받고 있지만 워라밸이 좋아서 틈틈이 공부할 여유 시간이 있는 경우도 있습니다.  이런 조건을 잘 활용해서 열심히 자기 개발을 하는 개발자도 물론 존재합니다. 하지만 워라벨에 만족한 채 자기 개발을 등한시 하는 경우가 많습니다.
 
캐리어 관리를 안하는 개발자의 최후: 희망퇴직
 
이런 상태로 계속 개발을 하다보면 어느 새 40대 초반의 나이가 됩니다. 경력은 쌓이는데 나이만 먹지 실력은 풍선에 있는 바람이 빠지듯 서서히 떨어집니다.  스스로 자신에게 개발자로써 실력이 없다는 사실을 너무나도 잘 알게 됩니다. 회사의 매니저들은 이를 기가 막히게 잘 알아차립니다. 40대 초반인 이런 부류의 개발자를 보면 투명 완장을 채워 관리를 같이 하면서 개발을 시킵니다.
 
문제는 IT 업계는 생각외로 변화가 심하다는 사실입니다. 트렌드에 민감합니다. 이런 부류의 40대 개발자들은 지금까지 다니던 회사가 적자를 본다던가 사업 구조 개편을 하면 '정리 해고'나 '희망퇴직'의 1순위가 될 가능성이 높습니다.
 
최근에 사실 상 강제 희망 퇴직 대상이 된 개발자를 직접 만나 그들의 눈물과 고통으로 얼룩진 분노의 넋두리를 듣게 됐습니다. 폐암 말기 환자가 피를 토하면서 절규를 하듯이 자신이 다니던 회사를 욕하기도 합니다. 안타까운 현실은 이 분들은 그냥 버티는 것 이외에 아무 것도 대처할 게 없다는 것입니다.
 
희망퇴직이나 lay-off의 대상자가 된 분들은 고속 터미널 휴게실에서 아끼던 지갑을 잃어버렸거나, 길가다가 누구한테 싸대기를 한 대 맞은 듯한 표정들이었습니다.
 
이런 상황에 몰리는 퇴물 개발자들은 회사를 원망합니다. "난 개발을 하고 싶은데 왜 관리까지 시키냐?", "회사가 너무 악독하다. 왜 강제로 희망 퇴직을 시키냐?"라면서 불만을 표출합니다. 그런데 조금만 생각을 해봅시다. 개발자는 다른 회사에서 좋은 조건의 오퍼가 있으면 대부분 회사를 그만 둘 자유가 있습니다. 개발자를 자기 마음대로 회사를 그만둘 수 있는데, 왜 회사는 개발자에게 고용을 "반드시" 보장해야 하나요? 세상에서 자기가 보고 싶은 부분만 초점을 맞추는 것은 아닌지 모르겠습니다.
 
아무튼 실력을 키우지 않아 회사에서 버림 받는 개발자들의 최후는 비참합니다. 지금 회사가 안정적이고 만족할만한 연봉을 받는다고 해서 개발 역량을 유지하는 걸 게을리하면 이런 운명에 처하게 되는 겁니다.
 
만약, 자신의 개발 캐리어를 꾸준히 관리해 경쟁력을 유지했다면, 회사에서 희망퇴직을 요구해도 그리 스트레스를 받지는 않을 겁니다. "위로금 받고 보름 정도 여행 좀 하다가 다른 회사로 가지"라고 생각하겠죠.
 
 
결론
 
제가 드리고 싶은 말씀은 다음과 같습니다.
 
    * 개발자로써 무엇인가 불만이 생길 때, 자신의 개발 능력을 키우는게 중요합니다. 
    * 앞으로 경쟁력 있는 연봉을 받을 수 있거나 기술적인 발전을 이룰 수 있는 
        지금보다 더 좋은 조건에서 개발할 수 있게, 캐리어를 관리하는게 중요합니다.
 
개발자 분들, 용기를 내서 계속 도전합시다!
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
 
 
 
 
 
새로운 지식이나 스킬을 배울 때 태도나 마인드는 중요합니다. 사실 뭔가를 배울 때 태도는 많은 걸 결정합니다.
이는 임베디드 리눅스를 배우는 과정에도 그대로 적용될 수 있습니다. 실무 스킬을 배울 때의 태도에 따라 고수 개발자가 될 수도 있는 거죠.
 
스스로 너무 자신을 자책하지 마세요
 
사실 많은 신입 개발자 분들이 이런 유형에 포함될 지도 모르겠는데요. 저도 처음 임베디드 리눅스를 배울 때 '스스로 자신을 너무 자책'했던 것 같습니다.
개발을 하는 도중에 뭔가 잘 안돼거나 막히면 스스로를 자책하는 거죠. 지금도 뭔가 막히면 스스로 다음과 같은 소리를 저도 모르게 합니다.
 
    "이것도 못 하니? 난 정말 허접이구나!"
 
그런데 나중에 몇 개의 프로젝트를 마무리한 후에 절감했던 사실이 있습니다. 그것은 바로 다음과 같은 사실입니다. 
 
    "개발하는 과정이 걸림돌을 만나는 것 그 자체이다"
 
개발을 하는 과정에 수 많은 걸림돌을 만나게 됩니다. 몇 가지 예시를 들어볼까요?
 
   * 당연히 잘 동작할 것이라 예상하고 짠 코드를 빌드해 타겟 디바이스에 다운로드해 
     확인하면 제대로 동작하지 않습니다. 
   * 가끔은 아예 부팅이 안 됩니다.
   * 컴파일러를 설치하다가 에러 메시지와 함께 중단됩니다. 
   * GIT 브랜치에 코드를 반영했는데 conflict이 났다는 경고 메시지를 만날 수 있습니다. 
 
물론 이런 걸림돌은 모두 제거 됐습니다. 이 후 프로젝트를 계속 진행하면서, 개발을 하다 보면서 뭔가 하다가 잘 안돼거나 막히면, 다음과 같이 생각하는 게 낫다고 생각하게 됐습니다.
 
    * 어디가 문제일까? 차근 차근 확인해볼까?
    * 문제를 해결하는 과정으로 뭔가 배울 수 있을 거야. 언젠가는 잘 되겠지.
 
이런 긍정적인 마인드와 함께 문제의 원인을 찾기 위해 리서치를 하는 것이죠. 그런데 문제는 이런 상황에서 자신을 너무 자책하는 겁니다.
 
   "이런 것도 못 하다니, 난 허접 쓰레기구나"
 
개발 도중 뭔가 막혀 잘 안돼는 것은 아직 해본 적이 없는 걸 해봤거나 기반 지식이 부족할 뿐입니다. 절대 자신이 바보라서 못하는 게 아닌 것이죠.
 
스스로 자신을 너무 자책하면 이 과정에서 너무 많은 에너지를 소모할 가능성이 높아집니다. 이런 태도와 마인드로 개발을 하게 되면 빨리 지칠 가능성이 높아집니다. 또한 감정적으로 바뀝니다. 그래서 가끔은 키보드를 주먹으로 치거나 욕을 하기도 합니다. 이런 태도와 마인드로는 개발을 오래할 수 없습니다. 개발이 지겹고 재미없다고 느낄 가능성이 높아집니다. 
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
 
 
 
 

임베디드 시스템 개발자가 되기 위해 어떤 실무 지식을 쌓아야 하는지 설명하는 유튜브 동영상입니다.

실무 개발에 궁금해 하시는 취준생 분들께 많은 도움이 됐으면 좋겠습니다.



https://youtu.be/poTg10-ozD4

많은 개발자들이 꼰대 개발자를 싫어합니다. 아마 꼰대 개발자를 좋게 보는 분들은 없겠죠.
그런데 조금 생각 해보면, 소프트웨어 개발자들은 꼰대가 되기 쉬운 환경에서 일하고 있는 부분도 있다고 봅니다.
특히 임베디드나 시스템 프로그래밍 분야는 특히 심하다고 생각합니다.
 
그 이유에 대해서 조금 더 알아볼까요?
 
경험치로 개발하면서 먹고 살 수 있다
 
하드웨어를 제어하는 임베디드나 시스템 프로그래밍을 하는 분야에서 경험치로만 먹고 사는 개발자들이 은근히 많습니다. '예전에 이런 식으로 했더니 해결했으니 그 방법을 시도해보자'라고 말합니다. 물론 기술적인 배경 지식이나 이를 뒷 받침할 수 있는 근거는 부족합니다. '예전에 했더니'가 근거의 전부입니다. 문제가 생겼는데 어떤 방법을 써 볼까 고민하는 도중에, 이렇게 확신을 갖고 어떤 개발자가 자신의 의견을 제시하면 한 번 그 방법을 써 보자라고 결정하는 경우가 많습니다.
 
그런데 재미있는 사실은 이 '예전에 했던' 방식이 통할 때가 은근히 많다는 겁니다. 특히 하드웨어와 관련된 문제인 경우에는 경험치가 통할 가능성이 높습니다. 경험치가 통하게 되면 시니어 급 개발자들은 우쭐해 집니다. '맞어, 내가 예상했던 방법이 먹히네!, 난 뛰어난 개발자야'라고 스스로를 대견하게 생각합니다. 하지만 이런 시니어급 개발자는 나태해질 확률이 높습니다. 새로운 기술이나 지식을 배우지 않아도 경험치로 먹고 살 수 있는데, 구지 새로운 기술에 대해 공부할 필요성을 못느끼는 것이죠. 새로운 기술이나 지식을 바탕으로 문제를 해결하거나 기능을 구현하려면 머리도 아프고 설명할 꺼리도 늘어날 가능성도 높습니다.
 
이렇게 나태하게 6개월 정도만 지내면, 자신도 모르게 바보가 될 가능성이 높아집니다. 소프트웨어의 세상은 흐르는 계곡 물 위의 보트에 있는 것과 비슷합니다. 실력을 업데이트하면 그 나마 보드에서 떠 내려가지 않게 됩니다. 가만히 있으면 현상 유지만 해도 떠 내려가는 업계가 SW인 거죠.   
 
이 중에 예전에 자신이 개발을 잘 해서 인정 받았던 '아름다운 추억'이 있거나 사내 정치를 잘해서, 지금은 퇴물이 됐지만, 실력이 좋다고 인정을 받으면 꼰대 개발자가 되는 것입니다. 에일리언 영화에서 보면, 에일리언이 뿌린 '분비물'이 몸에 뭍으면 며칠 후에 배 속에서 에일리언이 뚫고 나오듯이, '과거에 실력을 인정 받았던 기억'과 '새로운 걸 공부하지 않는 나태함'이 합쳐지면 자신도 모르게 꼰대 개발자로 변신하게 되는 겁니다.
   ●  개발자 여러분, 혹시 버그를 할당 받은 적이 있나요? 
 
아직 없다고요? 조금만 기다리면 금방 할당 받을 꺼에요. 그런데 버그를 할당 받으면 정말 짜증이 날꺼에요.
그 이유는 여러분의 관리자들이 짜증나거나 상기된 표정으로 나타나 여러분을 괴롭힐 가능성이 높기 때문이에요.
 
   ●  버그는 언제 까지 잡을 수 있냐?
   ●  버그를 잡을 수 있는 대책이 뭐냐?
 
보통 버그가 나오면 버그와 관련된 기능을 맡고 있는 개발자에게 할당되는 경우가 많습니다.
왜냐면 버그 관련된 코드를 작성한 개발자가 해당 버그를 잘 수정할 확률이 높기 때문이죠.
 
그래서 여러분이 버그를 할당 받으면 여러분이 짠 코드에 논리적 오류가 있는 지 점검합니다. 코드를 분석하고 디버깅을 하죠. 여기까지 문제가 될 건 없습니다. 너무나 당연한 이야기죠.
 
그런데 문제는 다른 개발자가 짠 모듈의 버그를 여러분 보고 잡으라는 상황인데, 이런 상황을 겪으면 정말 짜증납니다.
동료가 퇴사를 했거나 휴가를 간 상황이면 짜증이 바다와 같이 밀려 오게 됩니다.
"내가 짠 코드도 아닌데 왜 나보고 문제를 잡으라고 하는 거지?"란 생각이 무의식적으로 들기 때문이죠.
 
아무튼 버그를 잡는 과정(코드를 분석하고 디버깅을 수행)은 아주 짜증나는 일이에요. 가장 큰 이유는 관리자들이 압박을 하기 때문이죠.
 
"차를 몰고 있는데 20톤 짜리 덤프 트럭이 요란한 경적을 울리면서 차 바로 뒤 범퍼에 딱 붙어 있는 느낌" 혹은 "스타크래프트에서 테란에게 10만년 조이기를 당하는 느낌"이라고 할까요? 관리자들은 다양한 방식으로 압박을 해오는데, 미소를 지으면서 버그를 언제까지 잡을 수 있는지에 대해 물어보거나 화를 내기도 합니다. 정말 다양한 종류의 관리자를 볼 수 있습니다. 
 
개발자 입장에서는 디버깅을 할 때 뭔가 코드의 흐름이나 자료 구조가 눈에 보이고 버그를 유발하는 코드에서 뭔가 실마리가 보일 때는 그마나 버틸만합니다. 가끔은 이 과정에서 흥미를 느끼고 뭔가 개발자로써 실력이 느는 듯한 느낌도 받을 수 있습니다. 물론 아주 소수의 개발자이지만요.
 
그런데 버그에 대한 분석을 시작할 수 없는 앞이 캄캄한 상황을 맞이할 수 있습니다. 정말 이때 개발자가 받는 심리적인 압박감은 생각보다 큰데요.
이 때 개발자들은 대응하는지 이야기하겠습니다.
 
솔직히 털어놓는 개발자
 
차라리 솔직히 현재 상황을 털어 놓는 게 최선입니다. 욕을 먹더라고 자신이 버그를 잡기 어려운 이유를 차근차근 이야기하는 것이죠. 물론 그 동안 시행착오를 겪으면서 찾아본 코드나 로그에 대해서 설명도 해야 합니다. 현재 상황에 대해 실토를 하면 관리자들은 다른 대안이나 대책을 마련할 수 있습니다. 예를 들면 버그를 잡을 시간을 번다던가, 다른 개발자를 찾아본다던가, 아니면 관련 기능에 대한 스팩을 조정한다던가 등등의 대응을 할 수 있죠.
 
이 때 정말 용기가 필요합니다. 이런 사실을 실토할 때 관리자들에게 욕을 먹지만 나중에 문제를 잘 해결하고 나서는 잊어 먹을 가능성이 높습니다. 
 
대충 코드를 수정한다
 
제대로 코드를 이해하지 못한 채 코드를 일단 수정하는 선택을 합니다. 계속 관리자들이 압박을 하니까 말이죠. 물론 코드의 수정 내역은 그럴 싸 하게 포장해 말합니다.
하지만 현재 처한 문제를 모면하기 위해 땜빵으로 가짜 패치를 만들면 나중에 반드시 다른 버그로 부메랑을 맞을 가능성이 높습니다. 왜냐면 소프트웨어는 거짓말을 안하거든요.
 
대충 코드를 수정하느니 차라리 솔직히 잘 모르겠다고 실토하고 다른 도움을 관리자에게 요청하는 게 좋습니다.
 
버그를 다른 개발자에게 넘긴다
 
버그를 잡기 어려운 상황에서 개발자들이 많이 하는 수법이 버그를 다른 개발자에게 넘기는 것입니다. 버그가 할당될 때 보통 로그와 함께 전달되는 경우가 많은데요. 문제가 발생한 재현 경로가 약간 애매한 경우에는 관련 모듈 기능의 어떤 메시지가 보이면 해당 담당자에게 버그를 던집니다. 충분히 로그를 분석하지 않고 문제가 재현된 상황도 체크하지 않고 말이죠.
 
한 가지 예를 들어볼까요? 오디오 사운드가 끊긴다는 내용과 함께 로그가 전달된 상황입니다.
그 로그는 다음과 같습니다.
 
[ 7164.614352] rpi sound_card.27: Ply shutdown, devnum 7
[ 7165.077580] ------------[ cut here ]------------
[ 7165.077807] WARNING: at /root/rpi/kernel/workqueue.c:2904 __cancel
_work_timer+0x12c/0x178()
[ 7165.087114] Modules linked in: texfat(PO)
[ 7165.092596] CPU: 3 PID: 1373 Comm: mmcqd/0 Tainted: P        W  O 3.10.44+ #1
[ 7165.101579] [<c0017344>] (unwind_backtrace+0x0/0x144) from [<c0013874>] (show_stack+0x20/0x24)
[ 7165.111750] [<c0013874>] (show_stack+0x20/0x24) from [<c0936350>] (dump_stack+0x20/0x28)
[ 7165.121489] [<c0936350>] (dump_stack+0x20/0x28) from [<c0028848>] (warn_slowpath_common+0x5c/0x7c)
[ 7165.132133] [<c0028848>] (warn_slowpath_common+0x5c/0x7c) from [<c0028894>] (warn_slowpath_null+0x2c/0x34)
[ 7165.143418] [<c0028894>] (warn_slowpath_null+0x2c/0x34) from [<c0048600>] (__cancel_work_timer+0x12c/0x178)
[ 7165.154654] [<c0048600>] (__cancel_work_timer+0x12c/0x178) from [<c0048668>] (cancel_delayed_work_sync+0x1c/0x20)
[ 7165.168097] [<c0048668>] (cancel_delayed_work_sync+0x1c/0x20) from [<c007b588>] (pm_qos_update_request+0x34/0xac)
[ 7165.178711] [<c007b588>] (pm_qos_update_request+0x34/0xac) from [<c064348c>] (sdhci_disable+0x2c/0x48)
[ 7165.189268] [<c064348c>] (sdhci_disable+0x2c/0x48) from [<c062e68c>] (mmc_release_host+0xa8/0xc0)
[ 7165.199855] [<c062e68c>] (mmc_release_host+0xa8/0xc0) from [<c0640794>] (mmc_blk_issue_rq+0x104/0x664)
[ 7165.210600] [<c0640794>] (mmc_blk_issue_rq+0x104/0x664) from [<c0641514>] (mmc_queue_thread+0xb4/0x14c)
[ 7165.221673] [<c0641514>] (mmc_queue_thread+0xb4/0x14c) from [<c004ef1c>] (kthread+0xc0/0xd0)
[ 7165.231685] [<c004ef1c>] (kthread+0xc0/0xd0) from [<c000f788>] (ret_from_fork+0x14/0x20)
[ 7165.241314] ---[ end trace b64c1dfefe8a5e9e ]---
 
그런데 위 로그를 보니 파일 시스템 관련 메시지가 보여, 다음과 같은 내용으로 파일 시스템 담당자에게 버그를 이관합니다.
 
   *  파일 시스템 문제로 오디오 사운드가 끊어지는 것 같습니다. 버그 수정 바랍니다.
 
이런 내용을 받아 본 파일 시스템 개발자는 정말 짜증이 나기 마련이고, 감정적으로 대응할 가능성이 높습니다.
파일 시스템 개발자는 로그에서 오디오와 관련된 메시지를 찾아서 다시 이관을 합니다.
 
   *  아래 로그에 오디오 사운드 카드 관련 에러 메시지가 보입니다. 관련 내용 확인하시고 대응 하시기 바랍니다.
 
[ 7164.614352] rpi sound_card.27: Ply shutdown, devnum 7
 
충분히 로그나 재현 상황을 체크하지 않고 바로 다른 담당자에게 버그를 이관하면 문제는 해결되지 않고 계속 분쟁이 생길 가능성이 높습니다.
저번 포스팅에서는 코드 몽키의 미래에 대해 이야기했습니다. 그 포스팅을 읽고 종종 아래와 같은 질문을 주시는 분들이 있었어요.
 
   * 임베디드 개발에서 구체적인 코드 몽키적인 일이 무엇인가?
 
이 질문에 대한 생각을 조금 정리해 설명하겠습니다.
 
코드 몽키성 임베디드 개발 업무란
 
코드 몽키성 업무의 주요 특징으로는 다음과 같은 특징을 지녀요. 
 
   * 개발 업무를 매뉴얼화 할 수 있다
   * 업무의 난이도가 낮다
   * 일을 할 때 거의 막히는 부분이 없다.
 
지금 하고 있는 개발 업무가 위와 같은 범주 중 하나라고 느낀다면 “아, 내가 코드 몽키성 개발 업무를 하고 있구나”라고 여겨도 좋습니다. 이렇게 말씀드리는 이유는 임베디드 개발의 범위가 넓고 구체적으로 코드몽키성 업무에 대해 언급을 해도 공감이 안될 수 있기 때문입니다.
 
단순 설정 업무
 
많은 임베디드 개발자들이 리눅스 기반 환경에서 개발을 하시니 리눅스 드라이버를 예로 들어 설명하겠습니다. 
 
가장 먼저 설정 업무를 코드 몽키성 개발 업무라고 볼 수 있는데요. 한 가지 예를 들겠습니다. 현재 시스템에서 커널 로그가 제대로 출력되지 않습니다. 그런데 주위 동료가 CONFIG_PRINTK 라는 컨피그를 켜보라고 합니다. 그래서 CONFIG_PRINTK를 추가한 다음에 커널 드라이버를 빌드합니다. CONFIG_PRINTK 컨피그를 추가한 다음에 디바이스에 커널 이미지를 내려받은 후에 확인해보니 커널 로그가 제대로 출력이 됩니다. 스스로 뿌듯해 합니다.
 
   * 그래, 드디어 내가 해냈어.
 
하지만 CONFIG_PRINTK 컨피그를 키면 새롭게 어떤 함수들이 동작하는지, 어떤 원리로 커널 로그가 출력되는지 알려고 하지 않습니다. 그냥 설정 파일을 추가한 후 돌려 보는 것이죠. 생각보다 임베디드 리눅스를 개발할 때 이런 업무를 자주 수행하는데, 안타깝지만 이런 업무는 코드 몽키가 되는 지름길 중 하나입니다. 제가 언급한 코드 몽키성 업무의 주요 특징을 다음과 같이 바꾸어 볼 수 있거든요.
 
   * “개발 업무(CONFIG_PRINTK를 추가하는 것은)를 매뉴얼화 할 수 있다”
   * (CONFIG_PRINTK를 추가하는 것은)업무의 난이도가 낮다
   * (CONFIG_PRINTK를 추가하는)일을 할 때 거의 막히는 부분이 없다.
 
이처럼 뭔가 설정만 변경하는 코드는 셸 스크립트에서 디바이스 트리까지 확장됩니다. 코드 분석이나 동작 원리를 모른체 이런 업무만 반복하면 어떻게 될까요? 
 
   * 바로 코드 몽키, 저렴한 임베디드 개발자가 되는 겁니다.
 
사실 이런 코드 몽키성 업무를 시키면 대부분 개발자들은 싫어합니다. “내가 무슨 잡일 하러 왔나?”라고 자신도 모르게 불만을 토로하죠. 하지만 안타까운 건 이런 사실을 모른 체 이런 코드 몽키성 업무만 쫒아 다니는 개발자가 존재한다는 사실입니다.
 
패치 반영 후 테스트
 
프로젝트를 진행하다 보면 패치 코드가 전달되는 경우가 많습니다. 그런데 패치가 전달됐으니 패치 코드 5벌을 반영 한 후 테스트를 해보라고 합니다. 패치를 순서대로 반영한 후 빌드를 마무리해서 테스트를 수행합니다. 물론 패치의 내용이 뭔지 파악하지 않습니다. 그냥 패치를 반영할 뿐입니다. 
 
프로젝트가 숨가쁘게 돌아갈 때 갑자기 패치가 전달돼 패치를 바로 반영하고 테스트를 돌려야 할 때가 분명히 있습니다. 프로젝트가 바쁘지도 않은데 패치를 기계적으로 반영하고 테스트를 수행합니다. 패치 코드가 어떤 함수의 내용을 변경하는지 어떤 자료 구조가 바뀌는지 열어볼 생각을 하지 않습니다. 단순히 기계적으로 패치를 반영할 뿐입니다.
 
이번에도 위에서 언급한 코드 몽키성 업무의 주요 특징을 다음과 같이 바꾸어 볼 수 있습니다.
 
   * “개발 업무(패치를 반영하고 테스트를 돌리는 일)를 매뉴얼화 할 수 있다”
   * (패치를 반영하고 테스트를 돌리는 일)업무의 난이도가 낮다
   * (패치를 반영하고 테스트를 돌리는 일)일을 할 때 거의 막히는 부분이 없다.
 
패치를 기계적으로 반영하고 돌리는 것은 코드 몽키성 업무 중 하나입니다.
 
GIT Merge
 
GIT은 소프트웨어를 관리하는 사실 상 표준 프로그램이 된 지 오래입니다. 프로젝트를 진행하다 보니 다른 업체에서 아래와 같은 메시지를 전달합니다.
 
    * 현재 프로젝트의 리눅스 커널 버전이 4.4인데 4.9로 변경해야 합니다. 
      그래야 저희가 개발한 패치가 그대로 반영될 수 있습니다.
 
위와 같은 상황은 실전 프로젝트에서 종종 겪는 일입니다. 사실 최신 버전의 리눅스 커널이나 배포판 버전을 탑재한 상황에서 최신 패치를 쉽게 반영할 수 있습니다. 대부분 최신 패치들은 최신 배포판 버전에서 작성된 경우가 많거든요. 
 
이럴 때 GIT Merge를 하라고 합니다. 커널 4.4 버전에서 4.9 버전으로 GIT Merge를 해야 하는 상황입니다. 브랜치에서 소스를 내려받아 GIT Merge를 하는데 conflict이 발생합니다. conflict을 잡고 소스를 빌드한 다음에 제대로 동작하는지 확인합니다. 
 
물론 GIT Merge 도중에 하는 업무를 기계적으로 수행합니다. 커널 버전이 4.9 버전으로 변경돼 소스의 변경 사항이 많아 전체 소스가 변경된 내역을 확인하는 것은 사실 상 불가능합니다. 하지만 특정 세부 기능에서 대략 어떤 코드가 변경되고, 어떤 기능이 추가됐는지는 확인할 수 있습니다. 하지만 이런 과정을 거치지 않습니다. 기계적으로 GIT Merge를 수행할 뿐입니다.
 
이번에도 역시 언급한 코드 몽키성 업무의 주요 특징을 다음과 같이 바꾸어 볼 수 있습니다.
 
   * “개발 업무(GIT Merge)를 매뉴얼화 할 수 있다”
   * (GIT Merge)업무의 난이도가 낮다
   * (GIT Merge)일을 할 때 거의 막히는 부분이 없다.
 
GIT Merge 를 기계적으로 수행하는 것은 코드 몽키성 업무 중 하나입니다.
 
To be continued...
 
 
    * 버그 때문에 우리 회사 문 닫을 뻔했어!
 
저번에 만났던 어떤 IT 업체의 개발자로 일하고 있는 친구가 했던 말입니다. 말 그대로 어떤 개발자가 짠 코드 때문에 버그가 발생해 회사가 문을 닫을 뻔 했다는 스토리인데요. 버그가 있는 코드를 어떤 양심 불량 개발자가 심어 놓고 도망을 가서 회사가 패널티를 낼 위기를 맞이할 뻔했다고 하더군요. 그 말을 할 때 그 친구의 표정이 잊혀지지 않습니다. 표정이 많을 걸 말해 주던데요.
 
이렇듯 버그는 IT 제품을 개발하는 개발자나 관리자의 머리를 빠지게 하고 다크 써클을 생기게 하는 최악의 유발자인 듯 합니다. 버그 때문에 회사가 문을 닫을 뻔 하기고 하고, 개발자는 가끔 짤리기도 합니다. 또한 중간에서 관리를 제대로 못했다고 관리자가 옷을 벗기도 합니다. 규모가 있는 IT 업체는 QA라고 부르는, 즉 인증 테스트를 책임지는 부서의 관리자들은 버그를 제대로 잡지 못해 징계를 받기도 합니다.
 
그런데 개발을 하다보면 다음과 같은 상황을 종종 겪게 됩니다.
 
    * 일정을 맞춰야 하는 상황인데, 일정 내에 잡지 못하는 버그가 있다.
    * 그런데 그 버그를 고객에게 절대 알릴 수 없다.
 
 
한 가지 예를 들어 볼까요? 과금을 처리하는 소프트웨어 모듈에 심각한 버그가 있다는 사실을 개발 마지막 단계에서 알게 됐습니다. 물론 버그를 쉽게 재현하기는 어려운 상황이죠.
 
이런 상황을 IT 업체의 중간 관리자들은 종종 겪게 됩니다. 이 때 대부분 IT 업체의 관리자들은 3가지 중 한 가지를 선택합니다.
 
    1. 일정을 연기하고 제대로 버그를 잡고 소프트웨어를 배포한다. 물론 과징금을 낸다.
    2. 욕을 먹더라고 고객에게 버그를 알리고 빠른 시일 안에 버그를 잡겠다고 알린다.
    3. 버그를 알리지 않고 그냥 소프트웨어를 배포한다.
 
위와 같은 선택지 중에 1,2번을 선택하면 그나마 합리적인 결정이라고 볼 수 있습니다.
 
일정을 연기하고 버그를 제대로 잡은 다음 소프트웨어를 납품하는 게 당연하다고 생각할 것 같은데요. 만약 1번이나 2번을 선택한 IT 업체는 어떻게 일을 하게 될까요?
 
    * 제대로 문제를 해결할 때 까지 개발자들은 야근이나 집에 가지 못하게 됩니다.
 
 
소프트웨어 납품 일정을 못 맞추면 대부분 패널티를 물게 되거든요. 패널티를 내면서 고객에게 보통 다음과 같은 약속을 합니다.
 
    * 최대한 빠른 시간 내에 버그를 잡겠습니다.
 
저나 다른 개발자들이 가장 겪기 싫어 하는 상황인데요, 한 두번 쯤은 이런 고비를 맞이하게 됩니다. 많은 개발자들이 야근을 싫어하지만 이런 상황에서는 야근이나 철야는 어쩔 수 없는 것 같습니다. 일정 내에 품질을 맞추면서 소프트웨어를 마무리하는게 개발자의 프로 정신이라고 생각하거든요.
 
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
예전에 벤처를 창업했던 선배(CEO)가 즐겨 썼던 말이 있습니다.
 
   * 밤은 샜냐?
  
그 선배는 제가 봐도 정말 열정으로 몸이 타오르는 듯 한 모습이었습니다. 눈매도 독수리 같이 매서웠죠.
술 자리에서는 이런 말을 아주 자주 했습니다.
   
   * 밤을 새서 하면 된다. 불가능은 없다."
 
또한 밤을 새는 것은 정열적으로 공부하는 학생과 개발자의 기본 자세라고 목청 높혀 말하곤 했습니다.
그래서 그 선배가 창업한 회사의 사무실에서는 간의식 침대(라꾸라꾸)가 놓여 있었죠.
 
밤을 새는 게 정말 제대로 일하는 걸까?
 
그럼 그 선배가 했던 주장은 맞는 말이었을까요? 시간이 흐르고 보니 틀렸다는 게 증명됐습니다.
 
일단 그 선배와 같이 일하던 많은 개발자들이 떠났습니다. 맨날 밤을 새는 개발을 2~3년을 하니 몸이 망가진 거죠.
다들 약을 입에 달고 지내다가 병원 신세를 진 분도 생겼습니다.
 
연구소장은 당뇨병에 걸려 엄청 살이 빠져 오랫 만에 본 친구들이 못 알아보게 했습니다.
결국 그 스타트업은 거의 문을 닫기 직전의 상황이 됐고 한 때의 열정은 물거품과 같이 사라지게 됐죠.
 
이번에는 소프트웨어 공학 관점에서 그 스타트업 벤처 회사가 주로 썼던 밤을 새는 전략이 통하지 않았던 이유에 대해서 조금 더 이야기해보겠습니다.
 
밤을 새면 해결이 되는 과제의 난이도
 
사실 난이도나 스팩의 구현 복잡도가 높지 않은 프로젝트에서는 어느 정도 '밤을 새는 전략'이 통하기도 합니다.
기본 기술 역량이 부족해도 밤을 새면 부족한 역량의 빈틈을 메꾸어 주기도 합니다. 물론 이 과정에서 뿌듯함을 느끼기도 합니다.
 
그래서 이 벤처 회사는 초반에 많은 성과물을 냈습니다. 프로젝트로 많이 수주하고 매출도 올라가게 된 것이죠.
시간이 지나고 보니 밤을 새서 마무리한 프로젝트의 난이도가 그리 높지 않다는 사실을 조금 깨닫게 됐습니다.
 
그런데 돈을 벌면 R&D에 투자를 해서 개발자들의 역량을 업그레이드해야 하는데, 이 회사의 CEO는 '밤을 새면 된다'란 창업 정신을 갖고 있는 분이어서, R&D 투자를 소홀히 했습니다.
 
다음 프로젝트에서도 끊임없이 야근과 밤샘을 통해 결과물을 냈습니다. 물론 새로운 개발자를 영입하거나 기존 개발자의 역량을 키우는데 소홀히 했습니다. 구지 공부를 하지 않아도 야근과 함께 공부를 하면서 개발을 하면 된다라고 CEO 선배는 생각을 했습니다.
 
타이어에 조그마한 구멍이 나면 천천히 바람이 빠지듯이 이 선배가 차린 벤처의 기술 역량도 떨어지게 됩니다.
결국 벤처의 생명인 개발의 근간 기술이 부족한 상황에 직면합니다.
 
그래도 그 선배는 '밤을 새면 통한다'라는 전략을 버리지 않았습니다. 
 
근간 기술이 부족한 상태에서 밤을 새면서 코딩을 하니 '아무리 밤을 새도 문제를 해결'하지 못하거나 '계속 버그를 양산하는 결과물'을 내게 됩니다. 말 그대로 밤을 새도 문제를 해결하지 못하는 상황에 직면하는 거죠. 
 
시간이 흘러 제대로 일정을 못 맞추는 상황에 직면하거나 일정을 맞춰도 버그가 엄청나게 많은 결과물을 양산하게 됐습니다.
 
이처럼, 기반 지식이 부족한 상태에서 '밤을 새서' 일정을 맞췄다면 그 프로젝트가 그리 난이도 높지 않을 가능성이 높으며, 밤을 샌 전략을 계속 써야 하는지 자신을 되돌아 볼 필요가 있습니다.
 
다른 선배의 예시
 
예전에 다른 선배가 개발했던 프로젝트에서는 6명의 개발자가 맨날 야근을 해서 12개월 일정의 프로젝트를 6개월에 끝냈다고 합니다. 말 그대로 투혼을 발휘한 것이죠.
 
그런데 그 프로젝트를 끝낸 후에 황당한 일이 생겼습니다. 회사에서는 3명 개발자와 함께 6개월에 일정을 마치라는 지시를 한 것이죠. 그 선배는 맨날 야근에 시달리며 3명의 개발자와 함께 프로젝트를 마무리했는데 안타깝게도 프로젝트가 끝난 뒤 몸에 무리가 생겨 병원 신세를 지게 됐습니다.
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 

관련 스토리는 아래 동영상에서 확인할 수 있습니다.

https://youtu.be/68Q_LmD9h3s

[IT 에세이] 밤을 새면 모든 걸 다 해낼 수 있다!



많은 시스템 SW 개발자들이 생각 이상으로 불안해 합니다. 겉으로는 다들 잘 지내는 것 같지만, 술 한잔 하면 다들 불안감과 불만을 토해내는 경우가 많습니다. 그럼, 개발자들이 불안해하는 이유는 무엇일까요? 개발자들의 성향과 처한 현실에 따라 다르지만 대표적으로 불안해 하는 이유는 다음과 같습니다.
 
    * 현재 개발하고 있는 업무가 자신의 경력에 도움이 되는 지 의문이 생긴다.
    * 일을 해도 개발 능력이 느는 것 같지 않다.
 
신입 초년 개발자들은 자신이 몸 담고 있는 개발 분야가 전망이 있는지 의구심이 생기는 경우가 많아 불안해 합니다. 그런데 이런 불안함은 7~8년차 개발자들도 느낍니다. 전문성을 유지하면서 꾸준히 개발할 수 있는지 확신이 서지 않아 불안해 하는 겁니다. 그렇다면 10~15년차 개발자들은 불안해 하지 않을까요? 가장 불안해 하는 개발자들이 이 부류의 개발자입니다. "회사에서 짤리면 뭐 먹고 사냐"라고 불안해 합니다. 
 
사실, 어느 정도 불안해 하면서 개발하는 것은 유익한 면도 있다는 생각이 드는데요. 아무 생각없이 안주하고 만족하면서 지내는 것 보다는 낫겠지요.
 
문제는 불안해 하면서 가끔 책을 사거나 유튜브 동영상을 보면서 개인 시간을 할애해 공부를 하기도 합니다. 그러면서 스스로 다짐을 합니다.
 
    * "실력을 키워야 겠다"
 
하지만 1달 이상 꾸준히 공부를 하는 경우는 거의 없습니다. 대부분 짧으면 보름 길면 2달 정도 공부를 하다가 포기합니다. 그리고 다시 불안한 일상으로 복귀합니다. 끊임없이 불안해하며 꾸역 꾸역 개발을 합니다.
 
물론 지금 처한 상황(연봉/부서의 전망)에 꾸준히 불만을 품습니다. 하지만 이런 상황을 타개할 의지는 없습니다. 목줄을 찬 강아지가 끌려 다니듯한 느낌을 받습니다. 그렇다면 이런 불안감과 불만을 느끼면서 계속 (같은 회사에서) 비슷한 개발 업무를 하는 이유는 무엇일까요? 
 
    * 바로 이런 불안함과 불만의 강도가 그럭저럭 견딜만 하기 때문입니다.
 
실력이 늘지 않는 것 같아 짜증이 나지만 공부를 하지 않아도 개발자로써 캐리어를 유지할 수 있고, 연봉이나 대우도 불만이지만 참을 만 합니다. 라면의 재료는 "면 + 스프" 이듯 개발자로써 불안함과 불만이란 감정의 재료는 "현실에 대한 타협 + 나태함"인 듯 합니다.
 
그런데 연차 기준으로 10~15년차 개발자들은 보름이나 2달 동안 뭔가 공부를 해서 실력을 키우려는 다짐조차 하지 않는 경우가 많습니다. 물론 회사에서 짤릴까봐 굉장히 불안해 합니다. 하지만 아무 것도 하지 않습니다.
 
이게 불안해 하는 IT 개발자들의 현재 모습인 것 같아 포스팅을 해봅니다.
 
지금 졸업반에서 취업을 준비하는 취준생 분들은 현직 개발자들에게 진로에 대해 질문을 하는 경우가 많습니다. 하지만 많은 경우 현직 SW 개발자들도 취준생이 처한 처지와 그리 다르지 않습니다. 속으로 다 불안해합니다.
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
이번 동영상은 아래 블로그에 업로드된 글을 설명합니다.
 
[임베디드] 꼰대 개발자가 되는 방법(1) 
 
 
특히 임베디드 소프트웨어 분야에 꼰대 개발자가 많으니 조심합시다.


https://youtu.be/jivbUK8pfeo

# 꼰대 개발자의 특징 
 
● 자신이 성공한 개발자라고 확신한다.
● 다른 개발자들도 나처럼 성공하고 싶어 한다고 확신한다.
● 자신의 개발 방식이 여전히 먹힐 것이라 확신한다.
● 귀찮게 충고를 한다.
● 문제 해결 능력이 떨어지는 유형이 많다.
 
# 꼰대 개발자와 일할 때 주의해야 할 점  
 
● 충고를 하면 잘 들어주는 척 한다.
● 개발 팁은 절대 새겨 들으면 안된다. 
● 같이 일하면 실력이 늘지 않는다.
 

+ Recent posts