이번 동영상은 아래 블로그에 업로드된 글을 설명합니다.
 
[임베디드] 꼰대 개발자가 되는 방법(1) 
 
 
특히 임베디드 소프트웨어 분야에 꼰대 개발자가 많으니 조심합시다.


https://youtu.be/jivbUK8pfeo

# 꼰대 개발자의 특징 
 
● 자신이 성공한 개발자라고 확신한다.
● 다른 개발자들도 나처럼 성공하고 싶어 한다고 확신한다.
● 자신의 개발 방식이 여전히 먹힐 것이라 확신한다.
● 귀찮게 충고를 한다.
● 문제 해결 능력이 떨어지는 유형이 많다.
 
# 꼰대 개발자와 일할 때 주의해야 할 점  
 
● 충고를 하면 잘 들어주는 척 한다.
● 개발 팁은 절대 새겨 들으면 안된다. 
● 같이 일하면 실력이 늘지 않는다.
 
많은 취준생들이 회사에 취업을 할 준비를 하면서 IT 학원을 다니거나, 독학을 하기도 합니다.
커뮤니티에 가보면 정말 취준생들이 올린 질문을 볼 수 있죠.
 
현업 개발자들도 역량을 키우기 위해 공부를 할까
 
그런데 취준생 분들이 취업에 성공한 다음 현업 개발자가 되면 역량을 키우기 위해 공부를 할까요?
안 하시는 분도 있고 하시는 분도 있을 겁니다.
 
분명한 사실은 역량을 키우기 위해 고민하고 실제 개발 능력을 업그레이드하기 위해 공부하는 개발자들이 있다는 거죠.
5~6년차 현업 개발자들도 자신의 역량이 부족하다는 것 느끼고 실력을 키우려는 노력을 합니다.
 
11+연차인 저는 역랑을 키우기 위해 공부를 하냐구요? 정말 아직도 심하다 싶을 정도로 공부를 합니다.
음, 그런데 이게 공부가 아니라 아예 습관으로 굳어져서 코드를 작성하고 디버깅을 하는 게 게임을 하는 것 같이 되버린지 오래입니다. 
 
'코드를 작성하고 디버깅을 어디서 하냐구요?' 집에서 하죠. 그렇다면 코딩을 왜 집에서 할까요?
 
저 같은 경우는 사실 최근에 회사에서 코딩을 할 기회가 그리 많지 않았어요.
브링업을 하거나 커널 크래시 같이 문제를 해결하는 역할을 맡았거든요. 언제부터인가 드라이버 코드를 많이 짜고 개선하고 싶다는 욕구가 화산처럼 분출하기 시작했어요. '내가 드라이버를 짰으면 저 돌대가리 보단 잘하겠다'라는 자만심이 생긴 거죠.
 
그래서 집에 라즈베리 파이를 4개 정도 산 다음에 실컷 코딩을 합니다.
왜 4개나 샀냐구요? 라즈베리 파이를 쓰다 보니 도중에 라즈베리 파이가 제대로 동작을 하지 않더라구요.
 
보통 하루에 2~5시간 정도 코딩을 하면서 놀고 토요일에는 10시간 정도 하고 노는 것 같아요.
물론 리눅스 커널이나 ARM 프로세서에 대한 코드를 분석하는 것은 병행하면서 하는 거죠.
 
일요일에는 새벽 5시에 일어나 아침 10시까지 이 짓(?)을 하고 이후는 컴퓨터나 휴대폰을 아예 쳐다보지 않아요.
이 정도하면 눈이 피곤해서 뭘 하지 못하죠.
 
역량을 키우기 위해 열심히 노력하는 개발자 분들이 종종 보이는데요.
많이 활용하는 방법이 바로 사이드 프로젝트인것 같아요.
 
사이드 프로젝트 
 
자신이 키우고 싶은 역량과 관련된 프로젝트를 해보는 거죠. 물론 회사에서 일을 마친 다음에 집에서 해야 겠죠.
 
회사 일은 30%만, 70%는 '사이드 프로젝트'에 투자하세요_ 스타일쉐어 iOS 개발자 전수열의 이야기
 
지금 당장 사이드 프로젝트를 시작해야하는 이유 (Start your side project now!)
 
Why & How You Start a Side Project (사이드 프로젝트가 중요한 이유) 
 
사이드 프로젝트의 중요성은 위 비디오를 보면 다 아실테니 구지 따로 설명을 하지 않을께요.
 
스터디 모임 참석
 
역량을 키우기 위해 열심히 노력하는 개발자 분들이 종종 보이는데요.
 
가장 대표적인 예가 iamroot란 스터디 모임에 참가하는 분이에요.
매주 토요일 8시간 동안 거의 한 주도 거르지 않고 스터디에 참가해 자신이 준비한 내용을 발표한다는 것은 정말 어려운 일인데.처음에 500 명 정도의 개발자가 스터디 모임에 모인다고 하네요.
 
저도 iamroot란 스터디 모임에 참가를 해볼까 몇 번 망설였는데. 너무 살벌한 규칙 때문에 못할 것 같네요.
무엇보다 코딩을 하는 도중에 30분 정도 편하게 누워서 자는 습관이 있는데 스터디 모임에서 그러면 안될 것 같아요.
 
역량을 키우기 위해 가장 많이 하는 게 바로 스터디 모임인 것 같아요.
사실 인터넷 카페에 가보면 각 IT 분야별로 스터디 모임을 모집하는 공고를 쉽게 볼 수 있는데요.
 
혹시 역량을 더 키우고 싶은 분이 있으면 카페에 등록을 하고 스터디 모임에 한 번 참가하시길 바래요.
 
회사에서 몰래 야근하기
 
예전에 제가 자주 썼던 방법이긴 한데요. 
운이 좋게도 프로젝트를 열심히 하면 제 실력이 부쩍 느는 과제를 맡았어요.
 
그 당시 6시 정도면 퇴근할 정도의 업무 강도였는데, 관련 내용을 더 많이 배우고 싶어서 거의 9시 반 까지 남아서 
분석을 더 했던 것 같아요. 어느 누구도 저에게 야근을 하라고 강요하지 않았는데, 스스로 남아서 더 분석을 하거나 코딩을 한 거죠.
 
조금 더 공부를 하다가 피곤하면 집에 가기도 했던 것 같아요. 이런 제 생각인데 '이런 야근은 그리 나쁘진 않은 것 같아요'
물론 이런 점을 악용해서 개발자들에게 야근을 권장하는 분위기는 절대 있어서는 안되겠지만요.
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
 
아래 포스팅에서 말씀드린 것 처럼, 이렇게 저를 뿌듯하게 하는 격려와 응원의 메시지를 받기도 했지만.
 
처절한 임베디드 개발 현실에 대한 분노와 울분의 글(댓글/이메일)도 읽게 됐습니다. 예를 들면 다음과 같은 스토리죠.
 
    * 회사에서 개발하는게 너무 힘들다. 
  군대에서 마취를 하지 않고 수술을 받아 본 적이 있는데, 그 보다 더 힘들다.
   
* 스트레스로 이빨이 흔들려 3개나 치과 치료(?)를 받았다.
 
* 선임 개발자들이 출신 학교는 물론이고 부모님 안부를 묻는 모욕적인 언사를 서슴치 않는다.
   (아마 스스로 퇴사를 유도하는게 아닌 가 싶습니다.)
 
* 집에 제대로 퇴근한 적이 없다. 6개월 동안 매일 새벽 1시 이후에 퇴근했다.
 
이런 메시지를 읽으면 마음이 조금 무거워집니다. 
제가 뭐 직접적인 도움을 줄 수도 없고, 블로그를 통해 유익한 컨텐츠를 계속 올리는 게 제가 할 수 있는 최선이라 생각이 듭니다.
 
그런데 아주 특이한 메일을 받았는데요. 하루에 3시간 밖에 잠을 자지 않고, 
책의 실습까지 다 마치고 나니 실력이 늘어 자신감이 급상승해, 면접을 보고 무사히 통과를 했다는 스토리였습니다.
이거 1년 6개월 동안 쓴 원고인데 거의 50일만에 다 읽은 독자님도 있다니. 뭔가 기를 빨린 듯한 느낌이지만 참 기분이 좋았습니다.
 
그런데 가끔, 이런 생각을 합니다.
 
    * 임베디드 개발에 진입 장벽이 높을까?
 
물론 어느 분야나 마찬가지로 고급 개발자가 되기 위한 진입 장벽이 있기 마련입니다만, 과연 임베디드 개발의 신입 개발자가 되기 위한 장벽이 있을까? 
장벽이 있다면 그 이유는 무엇일까? 저도 모르게 이런 생각이 듭니다.
 
제가 내린 결론은, 어느 정도 신입 임베디드 개발자가 되기 위한 진입 장벽이 있다는 것입니다. 
그렇다면 그 진입 장벽의 실체는 무엇인가에 대해서 이야기를 해보려고 합니다.
 
다음 포스팅에서 이 이야기를 하겠습니다. 
요즘 ARM 프로세서와 같은 기술적인 컨텐츠를 올리는데요.
 
이번 시간에는 조금 예민한 이야기를 에세이 형식으로 포스팅합니다. 주제는 임베디드 BSP 분야의 코드몽키의 특징입니다.
코드몽키가 뭔지 궁금하시다고요? 아래 동영상을 보면 알 수 있을 겁니다.
 
 
리눅스 개발자들과 교류를 하다가 가끔 술 한잔 할 때 가끔 코드몽키에 대해 스토리를 이야기합니다. 그 분들이 하는 말을 좀 듣고 나니 몇 가지 공통점이 있더라구요. 
몇 가지 공통점을 보여 요약을 해 봤거든요. (사실, 이 글을 블로그에 비공개로 업로드됐는데 공개로 올려도 될 것 같아 포스팅합니다.) 
 
제가 아는 친구는 중견 기업의 CTO 개발자로 일하고 있는데요. 
(그 친구가 말하는) 임베디드 코드몽키 때문에 회사 문을 닫을 뻔했다고 하는데요. 
개발 과정에서 종종 큰 사고를 쳐서 그 친구의 주요한 역할이 면접 때 임베디드 코드몽키를 가려내는 일이라고 하는군요. 
 
글을 조금만 읽으면 기분이 나뻐질 수 있는데요. 
"이 글을 쓴 너도 임베디드 코드몽키가 아니냐?"라고 반문을 할 지 모르겠습니다. 
이렇게 질문을 하면 '네, 저도 임베디드 코드몽키입니다'라고 대답하겠습니다. 그리고 '기분이 나쁜 분은 코드몽키일 가능성이 매우 낮습니다"라고 말씀드리고 싶어요.
 
참고로 이 글은 모두 제 생각은 아니고 시니어 급 리눅스 시스템 개발자들의 생각을 정리한 것입니다. 
이제부터 임베디드 분야의 코드몽키의 특징에 대해 몇 가지 정리해 보겠습니다.
 
배우려는 의지가 없다
 
다른 코드몽키와 마찬가지로, 임베디드 코드몽키의 특징은 스스로 배우려는 의지가 없다는 점을 들 수 있어요.
물론 개발을 하다보면 어쩔 수 없이 뭔가 배워야 할 때가 있습니다. 이 때는 임베디드 코드몽키는 자신에게 주어진 일을 할 정도의 지식만 배운다는 점입니다.
이것도 구글링을 통해 얻는 간단한 지식에 불과한 경우가 많죠. 
 
책을 읽지 않는 것은 물론 꼭 봐야할 스팩 문서도 쳐다보지 않습니다.
 
스팩에 맞게 공부해서 학점을 따는데 길들여 졌는지, 하는 일이 관심이 없는 지 모르겠지만,
아무튼 임베디드 코드몽키는 배우려는 의지가 거의 없습니다.
 
단순 반복적인 일을 편하게 느낀다 
 
개발을 하다보면 코드몽키성 업무는 누구나 마추치게 됩니다.
빌드 스크립트만 짜거나 특정 피쳐를 넣고 빼는 일, 기계적인 깃 머지 혹은 단순 브링업과 같은 일이죠.
 
임베디드 코드몽키들은 이런 반복적인 일을 좋아하고 편하다고 느낍니다.
 
고수 개발자들이 가장 혐오하는게 단순 반복적인 개발업무인데, 이런 임베디드 코드몽키들은 이런 코드몽키성 업무만 쫒아 다닙니다.
 
보통 신입 개발자들에겐 가장 쉬운 업무를 주는 경우가 많은데요. 어쩔 수 없이 코드몽키성 업무를 주는 상황이 많습니다.
그런데 5년차 이상의 임베디드 코드몽키 개발자들이 이런 업무에 스스로 뛰어들어 신입개발자들과 경쟁을 한다고 하네요.
 
메뉴얼 대로 시키는 일만 한다
 
대부분의 임베디드 코드몽키는 메뉴얼대로 하는 일을 좋아합니다.
대신 조금이라도 스스로 일을 하는 걸 싫어합니다. 절대적으로 시키는 일만 합니다.
 
다른 동료가 작성한 코드에 심각한 버그가 있던 말건 기계적으로 코드를 머지합니다.
하지만 메뉴얼을 벗어난 업무를 지시하면 분노합니다. 임베디드 코드몽키에게 메뉴얼화가 안된 새로운 일을 주면 대부분 싫어하기 때문이죠.
'이걸 왜 해야 해?'라고 질문을 던지며 갱스터 랩을 하면서 100가지 이상 이유를 들이댑니다. 
 
자신에게 주어진 일을 왜 해야 하는지, 결과물을 어떻게 나올 지 고민을 안하기 때문이라고 합니다.
 
노력을 할 필요가 없다고 생각한다 
 
임베디드 코드몽키는 노력을 해도 자신의 삶이 나아지지 않는다고 생각하는 경우가 많다고 합니다. 
의도적으로 개발자, 직장인의 한계를 말하는 경우도 있다고 하는군요. 예를 들면 다음과 같아요.
 
아무리 개발을 잘해봤자 재테크를 하는 것보다 돈을 벌지 못한다.
개발을 잘 하려고 공부를 해도 나이먹으면 치킨 집을 차릴 수 밖에 없다.
 
100% 틀린 말은 아니지만 구지 저런 소리는 자주 할 필요가 있는 지 좀 의문이 들긴 합니다. 
 
평범한 개발자를 유난히 높게 평가한다 
 
임베디드 코드몽키들은 지극히 평범한 그저 그런 개발자를 아주 뛰어난 개발자라고 칭송하는 경우가 많습니다. 
메뉴얼대로 시키는 일에 익숙해져 있기 때문에 조금이라도 일을 창의적으로 하는 개발자를 보면(다른 개발자가 보기엔 '개나 소나하는' 일인데) 
'우아, 정말 대단하다'라고 진심으로 박수를 보낸다고 합니다. 
 
저는 이런 상황을 겪진 않았지만 다른 시니어급 개발자들은 이런 상황을 종종 겪었나 봅니다.
 
코드몽키가 되는 건 사실 개개인의 선택이고 뭐라고 말할 필요는 없는 것 같습니다.
하지만 가끔 동료에게 피해를 주거나 부서에서 진행 중인 프로젝트에 엄청난 대형사고를 치는게 문제라고 합니다.
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
 
 
혹시 코드몽키란 말을 들어 본 적이 있나요?
코드몽키에 대해 잘 소개한 유튜브 동영상이 있어 소개합니다.
 
게임계의 꽃미남 엔지니어이자 개발자인 김포프님의 동영상입니다.
 
제목: 코드몽키의 미래
 
제 자신이 코드몽키인지 뒤돌아 보는 계기가 된 것 같은데요.
중요한 발언을 요약해 봤어요.
 
> (1:30)
> 너네는 이 직종은 무조건 괜찮아 라는 망상만 듣고 들어와서
> 이거면 끝이겠지라고 생각하겠지만, 정작 잘못 받 들여놓고 잘못 시작하면
> 10년 뒤에 돌이킬 수 없는 상황이 된다는..
> 그냥 평생 노예처럼 살아가야 된다라는 애기를 할 수 밖에 없어요.
> 주변에서 그런 사람도 많이 봤고, 제가 보는 미래도 그럴 수 밖에 없고...
 
코드 몽키가 되면 평생 노예와 같이 저임금, 끝없은 야근과 함께 개발해야 된다는 이야기 같습니다.
그렇게 될 수 밖에 없다고 예언을 하네요. 살벌하네요.
 
> (1:53)
> 그러나 결과적으로는 제가 말하는 엔지니어급, 아키텍터 급, 이런 사람들은
> 우리가 알고 있는 프로그래머가 누리는 사회적 지위하던가 금전적인 지위를 그대로 이어갈 것이라고 보지만
> 그게 안 되는 사람들, 코드몽키들의 미래는 아무도 쉽게 얘기하려 하지 않고, 
> 대충 알고 있어도 모른 척을 하려는게 있죠.
 
그래도 고급 개발자들은 나름대로 인정받고 잘 지낼 것 같다고 예측하네요. 
 
> (2:00) ~ (12:08)
>
> 요약: IT 산업 초창기에는 프로그래머의 수가 적어서 많은 연봉을 받으면서 개발을 했다.
> 하지만 IT 산업의 인프라가 늘면서 다수 하드웨어 개발자들이 SW 개발자로 유입되면서, SW 개발자의 수가 늘어났따.
> 인력도 늘어나고, 일자리도 늘어났다. 이제는 일반 사무직에 종사하는 분들도 엑셀로 프로그램을 하면서 코딩을 하는 세상이 됐다. 
> 이제 코딩 교육이 보편화되서 대부분 프로그래밍은 기본 기술로 여겨진다.
 
> (12:08)
> 그렇게 또 저렴한 인력이 생긴다는 거에요.
> 누구나 다 하니까 이게 비쌀리가 없잖아요.
 
음, 코드 몽키는 저렴한 인력이라고 말씀하시네요.
 
> (13:31)
> 제가 아는 아키텍트는 그런 이야기를 했거든요. 
> 너희들은 함수 대가리만 짜주면 코드만 짜서 오는 게 코드몽키 일이 될꺼라고..
> "그거보다 더 단순한게 코드몽키 일이 될 수 있겠다. 정형화될 수 있고, 정형화된 일을 많이 줄 수 있다면.
> 충분히 될 수 있겠구나."란 생각을 하는 거에요.
 
코드몽키는 단순, 반복적인 코딩, 정형화된 코딩을 하는 분들을 의미하는 것 같네요.
 
> (14:51)
> 그래 단순한 건 누구나 할 수 있어. 단순한 건 그 사람들한테 주면 돼
 
단순한 일을 코드몽키한테 주면 된다고 말씀하는 것 같네요.
 
> (15:13)
> 그만큼 코드 몽키가 많아지고 많아 질 수록, 학교에서의 정규 과정은 쉬워질 수 밖에 없죠.
> 일반적인, 좋지 않은 학교들의 ...
> 그런데 이제 문제는 그런 학교에서 가르치면서 "야 너희은 코드몽키가 될꺼야" 그런 얘기는 안한다구요.
> 결과적으로 그런 학교는 코드몽키를 만드는 학교고 그런 얘기는 안한다구요.
> 코드몽키가 많아져서 졸업생은 많아지고 질보다는 양으로 처리하는 학교가 되는 거고
> 그런 변화를 보고 있고...
 
이 부분을 보니, 
스타크래프트의 저그란 종족의 해처리에서 '미네랄이 적게 드는' 저글링이 나오는 모습이 떠오르는데요.
 
요즘 코드몽키를 육성하는 학교가 있나 보네요. (전 잘 모르겠지만) 
 
> (15:45) ~ (16:04)
> 그러면 더 훌륭한 학교가 있잖아요.
> 잘 가르쳐서 훌륭한 거든, 입학 점수가 훌륭한 거든, 뭐든 간에..
> ...
> 이거의(학교간의) 양극화도 더 커질 것 같아요.
 
학교간의 양극화도 심해질 것이란 예상입니다.
 
> (16:09)
> 굉장히 많은 학원과 굉장히 많은 학교가 생겨났지만,
> 그러면 그럴수록, 모든 사람이 이제 '아 나도 교육을 받았다는 만족감은 있고
> ...
> 삶의 질에서는 크게 차이가 없어지지 않나.
> 오히려 그 양극화가 커지지 않나 좋은 학교와 나쁜 학교 간에..
> ...
> 그래서 코드몽키도 그렇게 가고 있구나.
 
프로그래밍이라 직종이 더 대중화되면서 코드몽키가 더 많이 생긴다는 이야기를 하시는 것 같네요.
 
> (16:43)
> 결과적으로는 삶의 선택이거든요.
 
코드몽키나 되느냐, 되지 않느냐도 삶의 선택이라고 보는군요.
저도 이 생각에 동의합니다.
요즘엔 학창 시절이 잘 생각나지 않는다. 학교를 졸업한 지 15+년이 지나서 그런가?
 
희미한 기억 속의 학창 시절에는 뭔가 수업을 듣고 학점을 따는 방식으로 공부했던 것 같다. 학점을 잘 따기 위해 공부를 하는 과정에서 지식을 습득할 수 있었다. 물론, 1학기가 지나면 내가 얼마나 그 지식을 잘 알고 있는지 결과를 확인할 수 있었다. 학점이 나오기 때문이다. A~C 까지 학점을 받는 것이다. 
 
정확한 기억은 아니지만, 학창 시절 학점이 별로 좋지 않았다. 낮은 학점을 받고 나면 난 스스로 다음과 같이 말하며 위로했다.
 
    * 학점이 높은 사람이 반드시 그 지식을 잘 아는 사람이 아니다.
 
요즘 드는 생각은 '학점이 높은 사람이 좋은 학생이고 그 지식을 많이 알 가능성이 높다'이지만, 그 시절에 바퀴 벌레가 살충제를 맞고 꿈틀 거리 듯 힘들어 하는 게 나의 모습이었다.
 
졸업 후 정말 운이 좋게 취업을 해서 'SW 개발자'로 일을 한 다음, 학교의 전공 수업을 듣고 학점을 따는 방식으로 학습을 하지 않게 됐다. 배워야 할 지식이 있으면 그 때 그 때 맞게 배우는 방식을 선택할 수 밖에 없게 됐다. 
 
누구도 뭘 배우고 얼마나 알아야 하는지 알려주지 않는다. 또한 학습의 방향까지도 스스로 결정해야 한다.
무엇보다 배운 다음에 그 결과를 확인하기 어렵다. 차라리 학부 시절에 전공 수업을 듣고 학점을 받는 게 속 편할 지도 모르겠다는 생각도 든다. 그래서 다음과 같은 질문을 던지면서 몇 년 동안 고민을 했다. 
 
    * '내가 제대로 배운 내용을 알고 있는지, 그 수준은 얼마나 되는지에 대한 피드백'을 어떻게 확인할 수 있을까?
 
고민 끝에 대학교 학부 시절의 학점 수준은 아니지만 '공부한 내용에 대한 피드백'을 확인하는 몇 가지 알게 된 내용을 이야기해보고자 한다.
 
블로그의 방문자 수
 
배운 내용을 정리하고 이를 통해 실력을 키우고 싶은 개발자가 있다면 '반드시 블로그를 해보세요'라고 권하고 싶다.
분석한 소스나 로그를 글로 정리하는 과정에서 생각보다 많은 걸 배운다. 여기서 한 가지 주의해야 할 점이 있다.
 
    * 반드시 블로그에 올리는 글은 공개!로 해야 한다.
 
물론 일기나 개인적인 생각은 블로그에 비공개로 올려 자신만이 봐야 한다. 때로는 완성되지 않는 글이 있으면 비공개로 모드로 저장한 다음, 퇴고를 한 다음에 완성된 글을 블로그에 포스팅할 수 있다. 
 
   * 기술적인 내용을 정리해 블로그에 '비공개' 모드로 올리는 것은 그리 바람직하지 않는 것 같다. 
 
'비공개' 모드로 블로그에 글을 올리면 다른 개발자들이 글을 읽을 수 없다. 당연한 이야기지만 자신이 블로그에 올린 글은 네이버나 구글링에서 검색이 되지 않는다.
 
이게 왜 중요하냐면, 블로그에 글을 올리면 구글링을 통해 많은 개발자들이 블로그의 글을 읽을 수 있고, 이것이 통계 자료로 잡히기 때문이다. 블로그에 올린 내용이 개발자에게 도움이 되면 더 자주 블로그에 오거나, 블로그의 글을 읽는 시간이 늘어나기 마련이다. 
 
내가 하고 싶은 이야기는 블로그의 통계 자료가;
 
   * '내가 올린 글이 경쟁력이 있는 지' 혹은 '내가 배운 내용을 제대로 정리했는지' 
 
확인하는 척도가 되기 때문이다.
 
많은 개발자들이 구글링을 통해 개발 지식을 검색한다. 그런데 개발자들이 블로그에 방문하는 횟수와 블로그에 머물러 있는 시간을 구글 인공 지능 알고리즘이 계산해 이 정보를 바탕으로 검색 결과를 출력해준다는 것이다. 
 
그럼, rousalome.egloos.com 블로그의 검색 결과를 확인해볼까?
 
구글 웹마스터에 블로그를 등록하면 더 자세한 정보를 얻을 수 있는데 아래는 6월의 http://rousalome.egloos.com/ 블로그의 검색 실적이다.
 
 
 
위 출력 결과는 다음과 같은 사실을 말해준다.
 
    * 블로그에 접근한 총 클릭수: 블로그에 방문한 횟수(9.59천)
    * 총 노출 수:  키워드(리눅스나 관련 개발 지식)를 입력하면 구글 검색 엔진이 검색 결과를 보여주는 횟수 (7.37만)
    * 평균 게재순위:   키워드(리눅스나 관련 개발 지식)를 입력하면 구글 검색 엔진이 검색 결과를 보여주는 순위 (10.1)
 
이번엔 5월 통계 정보를 볼까?
 
 
6월보다 전반적으로 수치가 더 높다. 데이터는 다음과 같이 해석할 수 있겠다. 
 
    * 블로그의 6월 달에 검색 실적이 하락하고 있으니 더 분발해라!
 
책을 출간하기
 
블로그도 좋지만 지식을 체계적으로 정리한 다음에 책을 출간할 수 있다.
이 과정에서 학부에서 받는 학점보다 더 냉정하거나 냉혹한 피드백(결과)을 얻을 수 있다.
 
먼저 출간 제안 과정이다. 
 
IT 전문 출판사의 에디터들은 밥만 먹고 기술 서적을 읽는 분들이라,
개발자의 글을 조금만 읽으면 개발자의 내공을 바로 캐치한다고 한다. 개인적으로 아는 프리렌서 출판사 에디터 형님을 통해 알게 된 사실은, '대부분의 개발자들이 출판사에 출간 제안을 하면 대부분 거절 당한다고 한다'라는 것이다. 
 
운 좋게 출판사에서 출간 제안을 받아줬다고 가정하자. 그럼, 끝까지 원고를 마무리하는 비율은 얼마나 될까?
원고 집필이란 마라톤를 완주하는 확률은 3/50이라고 한다. 50명이 출간 계약을 하면 3명이 완주한다고 한다.
(이 데이터도 출판사 사장님께 들은 내용이다.)
 
이 모든 관문을 통과해서 책이 출간됐다고 가정하자. 그럼, 출판 시장의 아주 냉혹한 피드백을 받게 된다.
yes24에서 볼 수 있는 판매지수이다. 책이 내실이 있고 좋은 내용으로 구성돼 있으면 고객(개발자/학생)들이 구매한다.
하지만 반대의 경우 외면 받는다. 
 
책을 출간하는 과정으로 받는 피드백은 학부 과정에서 받는 학점보다 더 냉혹한 것 같다는 생각도 든다.
 
---
"이 포스팅이 유익하다고 생각되시면 댓글로 응원해주시면 감사하겠습니다.  
그리고 혹시 궁금점이 있으면 댓글로 질문 남겨주세요. 상세한 답글 올려드리겠습니다!"
 
Thanks,
Austin Kim(austindh.kim@gmail.com)
---
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
'디버깅을 통해 배우는 리눅스 커널의 구조와 원리'라는 책이 출간된 후 가장 좋은 점은 그 동안 만나뵀지 못했던 교수님들, 리눅스 강사님들, 리눅스 고수 개발자분들과 교류를 할 수 있었다는 점입니다. 많은 분들이 집필에 대해 칭찬과 격려를 해주시고, 적극적으로 홍보해 주시기도 했습니다. 친한 선배님은 집 근처 도서관에 희망 도서를 신청하셨다고 알려주시기도 했습니다.
 
'문c 블로그'의 문영일 선배님께 책 출간 소식을 말씀드렸는데, '문c 블로그'를 통해 제 책을 홍보해주셨습니다. 
아래 링크를 참고하세요.
 
 
정말 감사드리고, 밥은 제가 사드려야 될 것 같습니다.
 
이 밖에도 여러 임베디드 리눅스 개발자와 취준생으로 부터 메일을 받거나 블로그의 댓글을 보게 됐습니다. 
 
이 중 아주 특이한 메일을 받았는데요. 책이 예약 판매가 될 때 주문을 해서 책을 받은 분인데요.
하루에 3시간 밖에 잠을 자지 않고, '디버깅을 통해 배우는 리눅스 커널의 구조와 원리' 책을 1달 반만에 다 읽었다고 하네요. 물론은 실습까지 다 마쳤다고 하네요.  
 
책의 실습까지 다 마치고 나니 실력이 늘어 자신감이 급상승해, 면접을 보고 무사히 통과를 했다는 스토리였습니다.
 
이거 1년 6개월 동안 쓴 원고인데 거의 50일만에 다 읽은 독자님도 있다니. 
얼마나 절실했으면 이렇게 까지 공부를 했을까란 생각이 들기도 하면서, 기분이 좋았습니다.
 
어떤 회사의 관리자분은 이 책을 '직무 교육 교재'로 선정했고 이런 책을 써줘서 고맙다고 연락을 주시기도 했습니다.
이 분께 세미나를 진행하는 요령과 책을 실무에 활용하는 방법에 대해 공유드렸고, 
가을에 원-포인트로 2시간 정도 제가 세미나를 할 계획이라고 말씀드리니 참 기뻐하셨습니다.  
 
모든 개발자님과 독자분께 감사드리고, 꾸준히 개발에 도움이 되는 컨텐츠를 발굴해 공유하도록 하겠습니다.
 
---
"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!" 
 
Thanks,
Austin Kim(austindh.kim@gmail.com)
---
유튜브에 좋은 컨텐츠를 올리는 개발자들이 늘어났으면 좋겠다.
초보 개발자만 아니라 다른 개발자도 귀 담아 들으면 좋은 내용이 많은 것 같네.
 
출처: 초보 개발자, 이것만 안 해도 평균 이상 갑니다 (흔히 하는 실수 공개)
 
1. 최소한의 노력도 없이 구글링 하듯이 질문하기
 
    ● 고민을 하나도 하지 않고 자주 질문을 하면 다른 개발자에게 인터럽트를 유발하게 된다.
    ● 팀 동료의 생산성에 악영향을 끼친다.
    ● 동료 개발자에게 배려를 못한다는 느낌을 준다.
 
2.  반대로 너무 오래 침묵을 하기
 
    ● 질문을 하지 않고 혼자 끙끙 고민만 하다가 일정을 다 날려버리면 낭패다.
    ● 우선 하루나 반나절 동안 문제를 스스로 해결하기 위해 노력을 한 후, 스스로 해결이 불가능한지 
        판단을 내리는 게 중요하다.
 
3.  이해하기 전에 대답한다 
 
    ● 자신의 실력에 대한 과한 확신 때문에 해보지도 않고 성급하게 판단을 내린다.
    ● 큰 사고를 일으킬 수 있는 유형 중 하나다.
    ● 겸손한 자세를 갖는 게 중요하다.
 
4.  이해한 척 하기 
 
    ● 제대로 이해하기 못했는데 다시 물어보기 그래서 이해한 척을 한다.
    ● 예상하지 못한 낮은 성과물이 나올 가능성이 높다.
가끔 낙타와 같은 개발자가 눈에 보인다.
사막에서 주위 상황을 살피지 않고 모래에 머리를 박고 있는 낙타와 같이 개발을 하는 분들이다.
 
자신이 하고 있는 개발 업무가 회사 밖에서,
 
    ● 쓸모가 있는지,
    ● 경쟁력이 있는지,
    ● 활용이 가능한지,
    ● 어느 정도 난이도가 있는지,
    ● 개발자로써 역량을 키울 수 있는지,
    ● 다른 개발자가 인정할만한 일인지,
 
전혀 고민을 하지 않고 그냥 닥치는데로, 시키는데로만 일을 하는 개발자를 말한다.
이렇게 개발하는 개발자의 미래는 눈에 너무 선명하게 그려진다.
 
자신이 하고 있는 개발 업무가 회사 밖에서,
 
    ● 쓸모가 없고,
    ● 경쟁력이 없고,
    ● 활용이 불가능하고,
    ● 수준 낮은 일이고,
    ● 개발자로써 역량을 전혀 키울 수 없고,
    ● 다른 개발자가 '그게 개발 업무인지' 의문을 갖게 되는,
 
운명을 맞이할 가능성이 높게 된다. 
 
다른 SW 개발자들이 낙타와 같은 개발자가 되지 않길 빈다.
 
Written by <디버깅을 통해 배우는 리눅스 커널의 구조와 원리> 저자
 
 
 
제 동료들은 가끔 저에게 이런 질문을 던집니다.
 
    * 뭘 그렇게 블로그에 많은 글을 올릴까?
 
당연히 떠오르는 질문이라 생각됩니다. 글쓰기를 꺼리는 개발자들의 눈에 신기해 보일 수 있죠.
저도 국내 최고의 IT 블로그인 '문c 블로그'를 봤을 때도 저도 비슷한 의문이 생겼거든요. 
 
이번에는 제가 블로그를 하는 이유에 대해서 이야기를 해보고자 합니다.
 
먼저 나 자신을 위해 블로그를 합니다.
 
작곡가들은 종종 '난 대중이나 나 자신을 위해 작곡을 하지 않는다'라고 말합니다. 
조금 다른 소리로 들릴지 모르겠지만 우선 저는 '저를 위해 블로그'를 한다고 말씀드리고 싶네요.
 
일단 블로그에 제가 분석한 내용을 어느 정도 정리해서 올리고 나면, 뭔가 나만의 데이터 베이스를 구축했다란 생각이 듭니다. 꼭 데이터 베이스라... 계속 공학적인 단어만 쓰네요. 그런데 정신없이 개발을 하다 보면 가끔 구글링을 통해 뭔가 검색을 해야 할 때가 생깁니다. 모든 개발자들은 구글링을 생존의 수단으로 잘 활용하고 있죠.
 
구글링을 하기 전에 먼저 제 블로그를 검색합니다. 제가 운영하고 있는 블로그에 로그인을 하면 키워드로 검색이 가능하거든요. 제 블로그에 올린 글을 검색하면 구글링을 할 필요가 없을 경우가 많아요.
 
구글링을 하면 키워드에 많은 딱 적당한 블로그가 검색될 때도 있지만 이리저리 헤맬 때도 많은데요. 이런 시간이 절약되는 것 같아요. 조금 더 효율적으로 개발할 수 있죠. 제 블로그의 덕을 가장 많이 보는 개발자가 저인 것 같아요.
 
개발을 하다 보면 뭔가 소스를 봐야지 일을 진행할 수 있는 경우가 많고요. 혹은 버그를 잡는 과정에서 자연히 자료구조나 소스 코드를 분석할 때가 많아요. 이런 시간이 쌓이다 보면 '소스를 분석한 내용을 정리를 해야 되겠다'란 결심을 스스로 해요. 이럴 땐 먼저 제가 나중에 알아볼 수 있는 수준으로 분석 내용을 정리해 블로그에 올리는 거죠.
 
무엇보다 소스를 분석한 내용이나 디버깅 과정에서 얻은 팁을 글로 올리면 뭔가 머릿속이 정리된다는 느낌을 받습니다. 
 
    '그래, 이제 분석한 내용을 정리했으니 이제 잊어도 되겠지? 나중에 검색하면 되니까'
 
란 생각이 들면서 마음이 편해지기도 합니다.
 
블로그에 올린 포스팅 중에는 완성도가 높지 않은 글이 꽤 있는데요. 이게 제가 분석한 내용을 정리하는 수준으로 글을 올렸기 때문이에요. 어쨌든 이 블로그는 먼저 저를 위해 운영을 한다고 말할 수 있겠네요.
 
다른 개발자에게 도움을 주기 위해 블로그를 합니다.
 
구글링 검색으로 필요한 정보를 찾아내는 스킬은 사막에서 오아시스를 찾는 능력과 같이 개발자의 생존 능력/본능이 된 지 오래입니다. 그런데 제가 이 블로그에 올린 글은 열악한 조건(야근/스트레스)에서 고생하며 개발하고 있는 동료 개발자에게 도움이 될 수 있을 것이라 생각이 됩니다. 제가 블로그를 하는 또 다른 이유는;
 
     제 블로그가 다른 동료 리눅스 시스템 개발자분들에게 도움이 될 수 있기 때문입니다.
 
가끔 리눅스 컨퍼런스 모임에 나가서 발표를 하는데요. 발표를 하고 난 다음에 다른 리눅스 개발자들은 제 발표 주제에 대해 질문을 하지 않고 '블로그를 정말 잘 보고 있어요'란 이야기를 자주 합니다. 이런 이야기를 들을 때 기분이 뿌듯해지곤 합니다.
 
그래서 이 블로그에 초안 포스팅을 올릴 때는 저 자신을 위해 올리지만, 주말에는 이 글들을 다듬어서 다른 개발자들이 편하게(?) 읽을 수 있는 수준으로 나름대로 편집을 합니다. 스스로 '다른 개발자들은 이 글을 잘 이해할 수 있을까'라고 질문을 던지면서 말이죠. 이런 노력을 기울이지만 많이 부족하다는 사실을 저는 알고 있습니다. '문c 블로그'의 문영일 선배님도 리눅스 모임에서 저에게, 
 
    '글을 좀 쉽게 썼으면 좋겠다'
 
라고 하시더라고요. 
 
2010년 쯤 인가요. 제가 왕초보 리눅스 시스템 개발자였던 시절이 있었어요. 그때 실력이 너무 부족해서 개발을 하는 순간이 지옥과 같았는데요. 회사에 앉아 있는 게 청양 고추를 먹은 것과 비슷한 느낌이었어요. 맨날 욕을 먹고 다녔죠.
 
그때 다른 리눅스 개발자의 블로그가 저에게는 마치 어둠 속의 등불과 같은 존재였어요. 그 당시 구글링으로 버텼거든요. 다른 개발자의 블로그가 저에게 큰 도움이 됐지만 '감사합니다'란 감사의 댓글도 남기지 않은 적이 많았던 것 같아요.
 
그 당시 전 이런 생각을 했죠. 
 
    '언젠가 내가 다른 개발자에게 도움이 될만한 컨텐츠를 올릴 만한 능력이 생기면 나도 블로그를 해야겠다'
 
라고요. 제가 다른 개발자의 블로그로 많은 도움을 받았으니 나도 기여를 해야겠다는 거였어요.
 
뭔가 진지한 분위기로 가는 것 같은데요. 간단히 정리하면, 그냥 '제 블로그가 다른 분들에게 도움이 됐으면 좋겠다란 생각을 했었다'라고 말하고 싶네요.
 
그냥 글 쓰는 게 적성에 맞아서 블로그를 합니다.
 
좀 진지한 소리를 한 것 같아서 이번에는 가벼운 화제로 돌릴 려 하는데요. 
그냥 저는 글 쓰는 게 제 적성에 맞는 것 같아서 블로그를 한다고 말씀드리고 싶네요.
 
대부분 리눅스 개발자들은 글쓰기를 혐오하는데, 저는 그렇진 않은 것 같아요.
제가 개발자의 독특한 성향을 타고나지 않아서 그런 것 같은데요.  
 
뭐 아무리 블로그가 저와 다른 개발자에게 도움이 돼도 글을 쓰는 게 적성에 맞지 않으면 꾸준히 할 수는 없을 것 같아요.
 
6.6일 현충일날 오후에 갑자기 '내가 왜 블로그를 하는가'에 대해 곰곰이 생각한 것을 블로그로 정리해 봤습니다.
 
---
"이 포스팅이 유익하다고 생각되시면 공감 혹은 댓글로 응원해주시면 감사하겠습니다. 
"혹시 궁금한 점이 있으면 댓글로 질문 남겨주세요. 아는 한 성실히 답변 올려드리겠습니다!"
 
​Thanks,
Guillermo Austin Kim(austindh.kim@gmail.com)
---

+ Recent posts