code review

이제는 디폴트가 된 git/github 시대에 예전을 생각하면 svn(tortoise 제품, 맨날 톨토이즈라고 발음 했는데 실제로는 털터스[tɔːrtəs]), hg(mercurial) 이런 것들을 사용했다.

commit 하면 바로 서버에 올라가고 필요한 사람이 trunk 였나? 여기로 머지를 했던것 깉다.

이때는 코드 리뷰라는 말도 생소 했고, 내 로컬에서 새 버전을 다운받아 에러가 발생하면 그제야 서버 커밋 로그를 뒤져 어떻게든 돌아가게 하려고 했던 기억이 난다.

github 같은게 없어서 메신져나 동료 옆자리에 앉아 같이 코드를 보면서 수정을 했었는데...(pair programming 이라는 말도 몰랐을때다)

그러고 보면 git/github 이 이전 버전 컨트롤 보다 개발도 편하고 코드 충돌에 있어서도 교통 정리를 잘해준다. 

github 이라는 오픈 공간은 같은 관심사를 가진 여러 사람들을 모이게 했고 집단지성을 발휘해 빠른 속도로 좋은 프로그램들이 많이 나올 수 있는 인큐베이터가 됐다.

이런 흐름속에 PR(Pull Request)라는 과정이 추가되고, 이곳에선 더 좋은 품질을 위해 생각을 공유하고 때론 배움의 장소로 사용된다.

실제로 구글링 하면 github 이슈에서 원인과 해결방법을 제시해주기 때문에 스택오버플루와 함께 깃헙은 좋은 나에게 좋은 선생님들이다. 이젠 이것도 AI 가 잘해주지만...

암튼 이 PR 과정에 코드리뷰가 진행되고 commiter 의 코드를 보며 갑론을박 토론의 장이 펼쳐지곤 한다.

이런 토론이 가끔 나쁘게 흘러가는 경우가 있다.

상대를 무시하는 듯한 말투, 뭐하나라도 꼬투리를 잡아 늘어지는 경우등 이런 것 들은 기여자를 기죽게하고 contribute 에 소극적이게 한다.

(https://news.hada.io/topic?id=16472 에 코드리뷰 안티패턴들)

개인적으로 품질과 함께 생산성이 중요하다고 생각한다.

생산성에 여러 의미가 있지만 난 속도에 무게를 두고 싶다.

container 가상화, 자동화 테스트, 심지어 프로그래밍까지 간결하고 이해하기 쉬우면서도 오류를 적게 나는 언어등으로 우리는 예전 보다 더 쉽고 빠르게 (rust 생각하면)때론 더 안전하게 만들 수 있다.

그리고 AI로 품질과 생산성이 좋아져 더 좋은 서비스가 출시가 더 빨라지기까지 한다.

이런 환경속에서 서비스(software/product)가 경쟁하듯 쏟아진다.

비지니스 관점에서도 빠른 서비스 출시는 시장 장악, 매출에도 영향이 클것이다.

상황이 이런데 나,우리의 서비스도 개발을 빨라해야 되지 않을까?

물론 코드 품질은 유지하면서도 속도도 높여야 겠지.

그런데 개발과정에서 아마 문제해결을 위한 시간 다음으로 협업과정에 오는 커뮤니케이션, 프로그래머들에겐 상시 진행되는 코드리뷰 과정이 많이 시간이을 잡아 먹는것 같다.

위 코드리뷰 안티패턴의 다크사이드 리뷰어가 아니더라도 들어보며 많은 프로젝트들이 리뷰 시간이 길어져 전체적인 생산성 저하가 발생되는것을 종종 본다.

코드 리뷰 과정은 적게는 1시간에 끝날 수도 있지만 길게는 일주일, 어쩌면 영영 끝나지 않고 묻히기도 한다.

리뷰가 지체로 PR 이 쌓이면 다음 작업에 영향을 미친다. 아무리 병렬적으로 작업을 한다고 해도 최종적으로 하나의 브랜치로 머지되니 다른 작업을 하고 있다면 수시로 diff 부분을 따라가고 충돌부분도 수정해야된다. 때론 중복 작업 까지 발생해 진짜 현재 PR중이 것들과 영향이 없는 이슈에 대해서만 병렬로 작업하는게 정신건강에 좋다.

암튼 지체되는 리뷰들을 되도록 줄여 개발 진행에 막힘이 없으면 한다.

이 문제와 관련한 여러 커뮤니티,기술블로그들의 글을 찾아봤다.

빠른 리뷰를 위해 많이 말하는게 데드라인, 템플릿, 우선순위, 알림등 이런저런 규칙과 시스템이 있었다.

이런것들로 어느정도 효과를 봤다고 수치와 그래프를 보여주기도 한다.

반면 이런 규칙과 제한등을 두면 사람들은 반감을 사고 오히려 리뷰를 대충하거나 소극적으로 한다 등의 안좋은 결과를 보였다는 글도 있었다.

개인적으로 알림, 템플릿은 optional(있으면 좋지만 없어도 딱히)이고 중요한건 리뷰문화 인것 같다.

내 코드 작성하는 것도 바뻐 다른 사람 코드 리뷰하는 시간이 부족하다는 말은 많이 하는데,

좀 들여다 보면 리뷰가 자체가 굉장한 스트레스로 다가오는 경우가 많다.

나같은 경우 github files changed 들을 보면 빨간색/초록색으로 보이는 차이들이 잘 읽히지 않는다. 마치 틀린그림 찾기처럼 꽤 집중을 해야 한다.

그래서 리뷰 잘 그리고 빠르게 하려면 내 생각은

- github > pulls/review-requested 로 나에게 요청한 리뷰들 수시로 확인하는 습관

- 되도록이면 이슈를 작게 나눠 코드 라인 수가 적게, 작은 이슈를 여러번 리뷰(https://smallbusinessprogramming.com/optimal-pull-request-size 코드라인이 200 줄정도면 1시간에 리뷰 확률 90%)

- 리뷰 중 생각난 문제들은 별도의 이슈를 생성하고 현재 리뷰는 마무리

- 리뷰 커멘트 작성시 명확하고 되도록 친절한 말을 사용

- 리뷰에 도움이될 툴 사용(diff 시 중요한부분만 보여주는 툴 https://github.com/wilfred/difftastic)

- https://soojin.ro/review/ 한글로 정리된 구글 코드 리뷰 가이드 참고

좋은 코드 뿐 아니라 잘 운영되는 리뷰 문화도 팀이 생산하는 또 하나의 결과물이 아닌가 싶다.

experience 라 쓰고 삽질이라 읽는다.

프로그래머(개발자)가 일을 할때 삽질했다라는 말을 많이 쓴다.

삽질이라는 말이 포크레인으로 한번에 처리할 일을 힘들게 땅만 팠다는 뉘앙스로

잘 모르는 영역을 힘들게 이것저것 시도해보거나,

원인 파악이 잘 안되는 일(버그같은)들을 처리하기 위해 힘들었다는 의미로 쓰인다.

흠, 자기가 힘들게 일했다는것을 빗대 말하면 듣는 사람에게 확 와닿기 때문일까?

IT 업계가 다른 공학분야 특히 건축분야의 용어를 많이 빌려 쓰는것 같은데, 삽질도 그렇게 공사현장을 연상시킨다.

많은 개발자들이 삽질을 했다고 하면 다음과 같은 몇가지 생각이 난다.

첫번째 진짜 힘들게 일했다.

두번째 나중에 알고 보니 너무 쉽게 할 수 있는 일이었다.

세번째 experience 라 쓰고 삽질이라 읽는다. 반대로 생각하면 삽질이라고 말하지만 경력사항에는 experience(경험)이라고 쓸 수 있다.

삽질이 너무 입에 붙어 쉽게 고칠 수 없는게 아쉽지만,

이 힘든 삽질이 나의 커리어라는 나무에 작은 밑거름이 될 수 있음도 잊지 말자.

직장인 넋두리

마음은 한동한 싱숭생숭하다 곧 화가났고 이제 현타가 온다.

매년 2월이 되면 직장인들의 연봉협상 결과가 속속 통보된다. 협상이라는 말은 왜 쓰는지 모르겠다.

지금 회사도 벌써 5년째가 되는데, 매년 그렇듯 올해 역시 연봉결과는 만족스럽지 못했다.

보통 이직 첫해는 이직했을때 올려받은 연봉등의 이익이 있어 좋기도 하지만 업무도 잘 모르고 배우는 입장이라 평가도 가장 낮고 보상도 거의 없을거라 생각한다.

2년째부터 조금씩 인정 받고 그에 따른 보상도 조금씩 오르길 바라지만 적어도 나에겐 그게 생각만큼 쉽지 않았다.

이 회사가 밖에서 보기에 평판도 좋고 구직자들에게 어쩌면 꿈의 직장으로 까지 그려지는 걸 보고 있으면 무슨 배부른 생각이라고 할지 모르겠다.

몇년동안 평가는 복잡해지고 많아졌지만 그에 따른 보상 결과는 적거나 없는 경우가 많다.

이런 상황속에도 나름 그래도 괜찮게 받고 있었나 싶었는데, 최근 IT 직장들의 보상관련 뉴스나 블라인드에 뜨는 글을 보고 있으면 그게 아니였구나 하는 생각이 든다.

어디는 얼마를 올려줬네, 어디는 어떤 보너스를 주네 하면서 코로나로 매출이 증대하고 앞으로 커갈 회사들이 하나둘 개발자들 처우와 채용에 불을 붙였다.

이런 와중 내 회사는 소외되고 있다는 생각을 떨쳐버릴 수가 없었고, 일도 손해 잡히지 않았다.

사람이라는게 어떻게 이렇게 간사하고 욕심쟁이냐고 속으로 말해보지만 좀 냉철하게 생각해보면 당연히 내 권리를 찾아가는게 뭐가 잘못되었냐는 대답이 온다.

직원들의 불만의 목소리를 커가고 대표에게도 호소해봤지만 대표들의 임금이 커가는 것에 비해 직원들의 보상은 사업확장과 미래 비전을 위한 투자로 지금은 여력이 없다는 대답만 듣는다.

솔직히 자본주의 시장에서 권력을 쥐고 있는 임원들이 맘대로 하는것에 크게 반할 수 있는 힘은 일반 직원들에겐 없다.

그나마 노조를 결성해 대항해보지만 특히 IT 업계에선 사람들 성향때문인지 그렇게 똘똘 뭉치지도 못하고 대표를 몰아부칠만한 날카로움도 없는것 같다.

뭐 이런 상황이 어제 오늘의 이야기는 아니겠지만, 40대가 되고 이제 얼마 남지 않을 것처럼 보이는 내 인생의 반은 좀 다르게 살아보고 싶은 맘이 든다.

좀더 높은 임금을 받고 좋은 환경에서 아이를 키우고 싶다.

이 회사에서는 삶의 질이 높지는 않더라도 당분간 꽤 평탄한 길을 걸을것 같지만 점점 안좋아질것 같은 느낌이 든다.

대표나 임원들의 대답을 듣고 있으면 뭔가 사업을 벌리고 있고 그에 따른 성과도 조금은 있어 보이지만 여러 문어발식으로 확장된 사업들에 투자로 돈이 모이질 않고 뭔가 회사가 외형만 뻥튀기 되는것 같다.

이런 뻥튀기에 지분을 소유한 임원들은 그들의 몫을 톡톡히 챙기고 있고, 일반 직원들의 보상은 점점 줄어간다.

사업을 늘리고 있으니 사람은 많이 뽑을테고 그로 인해 내 몫을 점점 줄어들테고,

무엇보다 이 회사의 비전이라고 말하는것들은 죄다 기술을 소유한 인력들에 의해 움직이는것들인데,

글세 몇몇 핵심인력들에 대해서는 아주 후한 보상이 주어지고 있을지도 모르지만,

전체적인 그림은 새로운 도전 회사들에 비해 임금이라던지 기타 메리트가 점점 사라지고 있다.

과연 이런 보상체계에서 직원들은 일할 의욕이 얼마나 생길것이며 얼마나 이직없이 계속 머무를 수 있게 할까?

능력있으면 이직하고 아니면 박봉이라도 이 자리에 머물려고 할테고, 뭐 각자 상황에 따라 처신을 하겠지만은 한가지 분명한것은 경쟁회사보다 못한 보상이라면 좋은 인재는 사라지고 점점 쇄락의 길로 접어들게 뻔한다.

밖에서 보는 이 회사는 앞날이 창창하고 우리나라에서는 최고라고 말하지만 내가 볼때는 그 알맹이는 점점 썩어가고 있다.

코로나로 인한 언택트 시대에 기술의 중요성이 더욱더 부각되고 그로 인해 IT 수혜가 발생하고 있는 상황에서, 겉으로는 매출이 증가하고 앞으로도 발전 할것으로 보이지만 모든 IT 회사가 그렇지 않을것이다.

새로운 도전을 위해 기존 제조,유통,금융,엔터테인먼트등도 IT 의 중요성을 깨닫고 이 시장에 뛰어 들고 있다.

이런 상황에서 아직까지는 기존의 IT 대기업들이 탄탄한 입지를 유지하고 있지만 덩치가 커진만큼 빠르게 움직이지 못하고 생각의 속도도 초기처럼 빛나지 못하는것 같다.

개인적으로 앞날에 대한 깊은 고민없이 그저 그런 생각들로 움직이는 회사는 크던 작던 빨리 망해야 한다.

그래야 본보기가 되고 인재들은 새로운 회사로 흡수돼 더 좋은 회사들을 만든다.

회사에 대한 불만으로 서론이 길었다.

자 이제 나는 뭘해야 될까? 그래 이직, 이직을 해야지. 그런데 그게 말처럼 쉬우면 얼마나 좋을까?

링크드인에 그동안 회사에서 한일을 써보면서 내가 뭐 그리 특별한 능력이 있나 다른 회사에서 내가 얼마나 쓸모 있는 사람일까라는 생각이 든다.

부끄럽다. 그동안 회사 일만 하면 되고 자기 발전에 크게 신경쓰지 못했던것이 새삼 부끄러워지는 시간이다.

지금 뭔가 시작하자고 하니 앞서 연봉 결과로 한동안 집중도 않되고 힘도 빠질것 같다.

프로그래밍 언어는 숫자를 왜 0 부터 시작해야 될까?

프로그래밍 언어는 숫자를 왜 0 부터 시작해야 될까?

처음 프로그래밍을 접한게 GW-BASIC 과 C 인 나로서는 숫자가 0부터 시작하는게 당연한줄 알았는데 FORTRAN 등은 옛날 프로그래밍은 1부터 시작을 했다고 한다.

숫자를 0 부터 시작해야 한다고 말한 사람은 최단경로 알고리즘과, 세마포어 연구로 유명한 네덜란드의 다익스트라(Dijkstra)다.

수열을 표현할때 다음과 같이하는것이 가장 자연스럽다.
하한(2) 상한(13)

2 <= i < 13

이렇게 사용하는것이 13 - 2 = 11 로 수열의 길이를 쉽게 알 수 있다.
다음과 같은 인접한 수열을 표현한다고 했을때, i의 상한과 j의 하한이 같다(인접한다고 할 수 있다.)

2 <= i < 13 , 13 <= j < 20

하한은 < 로 표현한다면 a < 1 로 는 자연수가 될 수 없다.

상한은 <= 표현해 공집합을 나타낸다면 2 <= n <= 1 과 같이 아름답지 못하기 때문에 상한을 배제하는 < 로 표현하는것이 좋다.

뭐 이런 아름다운 수열 표현을 위해 하한은 포함하고 상한은 배제하는 방식을 사용한다.
그럼 하한은 포함하고 상한은 배제 방식을 사용한다고 했을때
N 개를 루프를 처리할때

1 <= i < N+1

보다는

0 <= i < N

이 +1 이 없어 깔끔하다

참고
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html
https://fastbeautiful.tistory.com/3

하한은 포함하고 상한은 배제하는 방식이 golang 슬라이스나 python 배열 범위 지정이 딱 이런 형식이다.

[:3]  ->  0 <= i < 3  ->  0,1,2
[1:5]  ->  1 <= i < 5  -> 1,2,3,4

위 번역글에 보면 수학자가 0부터 세는 컴퓨터 프로그래머를 비난 했다고 하는데, 뭐 dijkstra 의 방식을 싫어하는 사람들도 있을거다. 솔직히 다른 방식을 사용하는 사람들도 개취로 존중해주고 싶은게 내 맘이다.(사실 현업에서 이런 약속이 있어야 훨씬 업무적으로 편해서 왠만해선 합의하게 되지만) 다행히 난 dijkstra 의 방식이 참 맘에 든다.

암튼 dijkstra 보니 c 언어 할아버지 dennis ritchie 가 그립지만 또 한명의 c 언어 할아버지 ken thompson 이 go 를 만들어줘서 다행이다.

참고로 공대만화에도 다익스트라와 0의 이야기가 나온다.ㅎ
https://www.facebook.com/engineertoon/posts/1002506639936191

그저 그런 사람이 그저 그런 미래를 만들고 결국 망한다.

국내 포털의 대표주자 네이버와 구글의 망중립성과 세금에 관해 vs(대결) 구도 기사를 보고 갑자기 답답한 마음에 생각을 전적으로 나 개인 사용자 입장에서 정리해 본다.

네이버의 국내 점유율은 언제가는 점점 낮아질거란 생각이 들었던때가 꽤 오래전이었다. 하지만 생각과 다르게 네이버의 1등 자리는 꽤 오래 유지되었고, 유지되고 있는 중이다. 내 생각이 틀렸다고 말하고 싶진 않지만 팩트만 놓고 본다면 내 예상은 보기 좋게 빗나갔다. 그래도 요즘 돌아가는 상황을 보면 그 옛날 생각이 점점 현실이 되가는 느낌이다.

pc 사용율은 mo 에 역전당한 현실에서, 그래도 모바일에서는 네이버보다 앞서던 카카오톡의 체류시간도 이제는 유튜브에 자리를 내놓았다. 사실 체류시간이라는게 네이버(포털앱)은 무언가를 검색하고 찾을려고 들어가서 찾게되면 그 간격이 가장 짧을것이고, 그나마 카톡으로 이런 저런 텍스트로 수분에서 수십분동안 사용하는 그 체류간격은 네이버의 검색보다 길것이다. 그리고 유튜브, 보통 수십분에서 많게는 1시간을 넘어가는 동영상들의 무궁무진한 컨텐츠 집합과 그 내용까지 알차니 톡의 수십분짜리 대화나 잡담보다 훨씬 우리의 시간이 많이 들어가는 곳이다. 뭐 이렇게 보면 어쩌면 당연한 youtube > kakaotalk > naver 순이라고 볼 수 있다. 그런데 매스컴에선 유튜브가 카카오톡을 넘어섰다는것에 대해서 꽤 걱정스러운가 보다. 네이버나 카카오의 입장에서 방어적인 말투로 말하자면 위협은 되지만 동영상 컨텐츠의 특성 이득이라고 말할 수 있다. 하지만 내 생각은 그렇지 않다. 동영상이건 톡이건, 검색이건 그 특성으로 체류시간이 차이난다는것은 결국 변명에 지나지 않다고 본다. 전쟁을 하는데(사실 난 이런 거대 it기업들의 경쟁은 전쟁처럼 치열해야하나고 본다. 그리고 치열함 속에서 사용자가 더 질높은 서비스를 누리기를 바란다.) 소총(네이버포털앱)을 들고 싸우는 보병부대와 탱크들(카카오톡) 기갑부대를 넘어 최첨단 전투기(유튜브) 부대가 싸우게 되는데 우리는 전투기가 없어서 졌다고 말하는것만 같다. 사용자들은 냉철하고 철저한 자기 이득을 취한다. 유튜브의 눈부신 발전속도에 카톡과 네이버앱은 그 특성으로 따라가지 못한다. 그럼 왜 네이버와 카카오는 전투기를 만들지 않았을까? 만들려고 노력을 했고 지금도 진행중인것 같다. 그런데 그 꼴을 보면 답답하기 그지 없다. 카카오tv, 네이버캐스트, 이런 동영상 서비스를 내놓고 있는데 한두번 이 동영상을 경험한 나로서는 유튜브에 더욱더 메달렸다.

이제는 포털에서 검색하는것보다 유튜브에서 검색을 하는게 자연스러워 지고 있다. 전문적인 내용을 찾고자 할때는 당연히 구글이였는데 이것도 (어떤 강의 동영상들 처럼) 유튜브가 더 좋은 결과를 내어주고 있다. 뭐 구글이 유튜브를 안내하고 있으니 거의 같은 서비스 묶음(구글+유튜브)이라고 봐야할것 같다. 암튼 이 유튜브의 컨텐츠를 보고 있으면 검색결과 상단에 위치한 광고성 링크들이 새삼 짜증나게 보인다. 물론 유튜브에 동영상 시작전 광고와 긴 영상의 중간마다 위치한 광고가 있지만 국내 포털의 동영상 2~3분 되는 동영상 컨텐츠를 보기위해 10초를 넘어가는 잼없는 광고보다는 훨~씬 눈에 거슬리지 않는다.

뭐 계속 두서 없어 국내 포털의 동영상 서비스를 까고 있는데, 제목에서 언급대로 말하고자 하는 요지는 왜 이런 서비스가 나오게 되었는가다. 어떤 회사가 사람이 중요하지 않겠냐마는 it 회사는 있는 경쟁력이라고는 사람, 역량있는 능력있는 사람들이 정말 다다. 기술도 이들로 부터 나오니 가장 우선으로 가져야하고 지켜야할 가치가 사람이다. 그런데 우리나라의 포털(사실 포털뿐이겠는가 산업 전반적으로도 그렇지만 우선 it 부분만 까본다.ㅋ)를 이끌고 있는 사람, 그 리더들이 가장 중요하면서 동시에 가장 연봉값을 해야하는 책임이 있는 자리인데 심히 그 능력이 의심스럽고 실망스러울때가 한두번이 아니다. 뭐 그분(?)들은 나름 열심히 자수성가한 사람들로 기존의 한국 재벌들에 비해서 촉망받고 유능하고 이렇게 국내의 큰 성공한 회사를 만든 이들이니 그 노력과 능력은 존경하는 면도 있다. 그런데 어느정도 이름이 알려지고 국내에서 대기업의 반열에 오르고부터 그닥 글쎄올시다.

혁신은 사라지고 현상 유지 나쁘게 말하면 방어적인 자세를 취하는듯한 모습에 실망스럽다. 유튜브와 같은 동영상을 만들자 아니 그 이상의 것으로 사용자들에게 사랑받는 서비스를 만들어보자. 이런 포부를 내고 확신에 찬듯 모두를 이끌어 줄 스티브 잡스같은 카리스마는 찾아볼수가 없다.(사실 난 스티브 잡스에 그닥 열광적인 사람은 아니다.) 물론 어려움이 많을것이다. 동영상 컨텐츠가 유튜브에 비해 쨉도 안되니 어떻게 사람들을 끌어 들일것이며 또 어떻게 양질의 컨텐츠 생산자들을 모을지, 그리고 국내의 관련 cp 들의 요구조건을 어떻게 설득할것인지. 내가 모르는 많은 곳에서 산을 넘어야할 문제가 가득할것이고 많은 일들이 어쩔수 없다는듯의 회의적인 의사 표시를 해올것 같다. 그래도 한회사의 중요한 결정권을 가지고 있는 리더이지 않은가? 모두를 이끌어야 하는 나라로 치면 대통령같은 인물인데 그 책임감에 맞는 행동해야 되지 않을까? 모든 사원들은 그 리더를 보면서 힘내고 보다 높은 연봉과 인센이 기다리고 있을 미래를 꿈꾸며 회사에 출근하도록 만들어야하지 않을까?

스타트업의 무모한 하지만 희박하게라도 정말 대박일 수 있는 아이디어, 아이템 뭐 이런것들을 내놓고 이게 안되면 그런 사람들을 곁에두고 지원할 수 있는 인복이라고 있어야 할것 같은데, 내가 보기엔 그냥 그저 그런 뻔한 생각들로 불확실한 미래에 도박을 하고 있는것 처럼 보인다.

뭐 리더들만의 문제가 아니라 현장에서 일하는 어쩌면 나태한 뭐 지금 먹고 살만하니 그냥 길고 가늘게 가보자. 하는 사실 가늘고 짧게 끝날 어리석은 생각의 평직원들도 있겠지만은 우선 리더가 정신 차리고 그저 그런 사람처럼 그저 그런 생각으로 바보같은 미래를 꿈꾸지 않길 바란다. 그런 미래가 오기 전에 리더 뿐아니라 회사가 망하게 될지도 모르니까. 아니 사실 리더들은 회사 망해도 모아둔 돈이 엄청 많으니 잘 살겠지. 그럼 어차피 나같은 평민들만 불쌍한거지, 된장.ㅠ

[참고]

http://www.hani.co.kr/arti/economy/it/818291.html

http://news.chosun.com/site/data/html_dir/2018/03/16/2018031601633.html

http://www.ebn.co.kr/news/view/878211

http://v.media.daum.net/v/20180506203417074?rcmd=rn

C++ vector naming?

c++ STL(Standard Template Library) 에서 많이 사용하는 vector 의 이름은 STL 을 Alex's lesson 가 기존 C 에 내장된 배열(array)과 구분하기 위해 선택한것이라고 한다. 그런데 수학에서 고정된 숫자 순서를 vector 라는 용어로 사용한다고 하니 동적길이를 가지는 C++ STL 을 생각하면 혼동이 될것 같다.
처음 vector 를 알았을때 이름을 왜 동적배열 같은걸로 짖지 않았을까 의문이 들었는데..
아래 글을 보면 Alex's lesson 자신도 네이밍 실수를 인정하고, 이름 질때 신중해야한다고 조언도 한다.ㅋ

원문 : https://stackoverflow.com/questions/581426/why-is-a-c-vector-called-a-vector/758548#758548

It's called a vector because Alex Stepanov, the designer of the Standard Template Library, was looking for a name to distinguish it from built-in arrays. He admits now that he made a mistake, because mathematics already uses the term 'vector' for a fixed-length sequence of numbers. Now C++0X will compound this mistake by introducing a class 'array' that will behave similar to a mathematical vector.

Alex's lesson: be very careful every time you name something.

소프트웨어 및 서비스 배포 단계 명칭

참고 https://ko.wikipedia.org/wiki/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EB%B0%B0%ED%8F%AC_%EC%83%9D%EB%AA%85_%EC%A3%BC%EA%B8%B0

dev(pre-alpha) : 설계 및 기능 구현의 개발 단계
alpha : 어느정도 기능 구현이 완료되어 테스트 시작할 수 있는 단계
beta : 일반 사용자에게 오픈하여 테스트할 수 있는 단계
RC(release candidate) delta, gamma 라고도 한다 : 여러 베타 버전중 최종 출시 후보
RTM (Release to Manufacturing) : 안정화되어 대량 생산하기에 충분한 단계
GA(General Availability): 상업화 과정이 완료되어 사용자에게 사용할 수 있는 단계


인터넷으로 서비스 되는 경우는 다음과 같은 영역(zone)으로 구분할 수 있다.
dev :  개발
alpha : 테스트
beta(stage) : 서비스 내보내기전 최종 상태
service : 서비스에 적용되어 실제 사용되는 영역

모른다고 겁먹지 말자.

 요새 듣고 있는 팟캐스트 중 지대넓얕(지적 대화를 위한 넓고 얕은 지식)이라는게 있다. 평소 궁금하고 잘 알지 못했던 내용들을 쉽게 설명도 해주고 토론도하고 아주 재밌게 듣고있는데, 문득 내가 몸담고 있는 IT 세계에서도 이렇게 지대넓얕 들이 많다는 생각이 들었다.

 처음 C 로 Hello 프로그램을 빌드했던 중학생(1995년?)때에 비하면 20년이 흐른 2015년 현재는 정말 많은 IT 기술들이 세상을 뒤덮고 있다. 그때만 하더라도 DOS, C 만 알면 대부분이 가능했다. 리눅스도 대중화되어 있지 않아 몇몇 대형 서버에만 국한되는 얘기로 만져 볼일이 있을까 라는 생각도 들었다. 하지만 시간이 지나면서 인터넷을 통해 정말 많은 용어들이 여기저기서 튀어나오기 시작했다. 처음에는 별로 관심을 끌지 못했던 기술들이 인터넷이라는 미개척 황금시대를 배경으로 그 가치를 인정 받아 갔다. 급변하는 시대에 기술이 늘어가는 만큼 프로그래머로써 알아야 할것들도 그만큼 많아졌다.

 대학교 학과 공부가 모든것인 시대는 끝난지 오래다. 대학 컴퓨터공학과 교육에서 배우는 과목들은 분명 프로그래머로써 기본을 튼튼하게 해주는데는 틀림없는 사실이지만 당장 현장에서는 그닥 힘을 발휘하지 못한다. 회사에 취직한 신입들은 학교에서 컴퓨터 구조를 파악하고 컴파일러가 어떻게 동작되는지를 배웠지만 구글, 네이버의 검색, 메일, 클라우드 등의 서비스에 바로 투입하기에 어려움이 있다. 오픈소스를 통해 나오는 많은 라이브러리와 툴들을 두루두루 섭렵해야 하고 회사 자체 기술에도 익숙해져야 하기 때문이다. 물론 요즘 대학 교과 과정도 실무에 많은 중점을 두고 커리큘럼도 변경되었고 기타 개인적으로 오픈소스에 관심을 갖고 공부하는 학생들도 많아 예전 만큼 회사 업무와 거리가 멀지는 않을 것이다. 하지만 지금봐도 어려운 운영체제, 네트워크, 컴퓨터그래픽등... 정말 컴퓨터공학의 근본을 배우면서 매년 발생하는 기술들을 모두 따라 가기에는 벅차다는 생각이 든다.

 학교를 졸업해 취업을 준비하거나 이직을 할때 프로그래머 구직란 내용을 보면 보통 C++ , Java 등을 할 줄 아는 사람들을 뽑는다라고 표현을 쓴다. 할줄 아는 프로그래밍 언어로 사람을 뽑고 말고 한다는건데, 과연 C++ 만 할줄 아는 사람 또는 C++ , Java , Python, PHP, Perl 등 모두 다 할줄 아는 사람이 정해져 있을까? 프로그래밍은 기본적으로 공통된 논리 제어 개념을 가지고 있어 공통점이 많아 마음만 먹으면 프로그래밍 언어는 얼마든지 배울 수 있다. 물론 주로 사용하는 기술에 비해 많이 미숙하겠고 언어 컨셉이 객체지향에서 함수형으로.. 와 같이 패러다임이 바뀐 경우등은 그리 쉽게 익혀지지는 않을 것이다. 하지만 개인의 노력에 따라 프로그래머의 스킬은 얼마든지 변경되고 높일 수 있다.

 지난 포스트에 프로그램머들은 한 영역을 집중적으로 파고 들어 전문가(Specialist) 되는 경우와 깊게는 아니지만 여러 기술들을 두루두루 섭렵하는 만능인(Generalist)이 있다고 했는데, 보통 제너릴 리스트의 경우 전문가에 비해 그리 좋은 케이스는 아닌것 같다는게 요즘 생각이다. 프로젝트를 진행할때 여러가지 기술들을 많이 아는 것은 확실히 좋은데 실제 중심이되는 기술을 얼마나 전문성있게 풀어내느냐가 성패를 많이 좌우하기 때문에 한분야에서 내공있는 고수가 되는것이 더 매력적으로 보인다. 이런 고수가 되는것은 결코 쉽지 않을 것이다. 여기저기 기웃거리면서 간만 본다면 결국 아무것도 이룰 수 없기에 자신에게 중요한 기술을 우선으로 깊이있는 공부를 해보는 것이 좋을 것 같다.

 요즘 GoLang 과 함께 뜨고 있는 Docker 프로젝트를 보면서 알게된 리눅스의 컨테이너라는 개념이 있는데, 정말 밀접하게 관계가 있는 리눅스 영역에서 정작 리눅스의 아버지인 리누스 토발즈 본인은 잘모른다라고 말하고 있어 의외였다.(아래 기사 참고)

 리누스 토발즈 "컨테이너? 잘 모른다" (http://www.zdnet.co.kr/news/news_view.asp?artice_id=20150820115820)

 여태껏 이기술 저기술 얇게 발담그며 아는척 했던 자신이 부끄러워지는 순간이였다. 단순하게 몰라서 조금 해보고 공부하는 과정까지는 좋은데, 이것이 마치 다아는듯 허새가 몸에 섞여있었다. 프로그래머들은 자존심이 강해 모르는 용어가 나오면 이미 알고 있었다는듯 아무렇지 않게 넘겨버리는 경우가 있는데 모른다 말 하면 왠지 상대가 나를 낮게보고 무시할 것 같은 걱정이 앞서기 때문이다.(모른다고 나를 나무라는 상대는 그리 좋은 프로그래머가 아닐것이다.) 많이 알고 있으면 좋겠지만, 그렇다고 모른다는 것에 너무 겁먹지 말았으면 한다. 모르면 공부해서 언제든지 내것으로 만들 수 있다는 마인드를 갖는게 더 중요하지 않을까. 그리고 너무 기술 트렌드에 민감해 모든것을 놓치지 않고 따라가려 한다면 결국 깊이 있는 공부를 하지 못하고 남는것은 껍데기에 불과할 수 있다는 생각을 해본다. 모른다고 쫄지마~ㅋ

코드 가독성과 실력

 프로그래머에게 코딩은 많은 부분을 차지한다. 개인적으로는 어떻게 구현할 것인가에 How, 알고리즘(해결방법)이 그 무엇보다도 중요하다고 생각한다. 그래도 생각만하고 아무것도 하지 않는다면 무슨 소용인가? 결국 코딩이라는 일종의 손가락 노동을 통해 output 을 내야 하는 것도 프로그래머의 역할이다. 단순하게 손가락 운동이라고 했지만 사실 작가가 소설을 쓸때 작품 구상후 한자한자 써내려가면서 문체에 신경을 쓰듯이 코딩도 아이디어를 어떻께 표현하느냐에 따라 성능, 유지보수등이 판가름 난다. 이중 유지보수 얘기를 하자면 빼놓지 않고 나오는 것이 가독성이다.

 흔히들 가독성 있게 코드를 작성한 사람이 좋은 프로그래머라고 한다.(개인적으로 착한 프로그래머라는 말이 더 어울릴듯). 전임자가 만든 소스를 받아 들고 유지보수를 해야 하는 입장에선 무엇보다 로직을 빨리 파악하고 수정할 수 있어야 되는데 이때 걸림돌 중 많이들 생각하는 것이 얼마나 알아보기 쉽게 작성했느냐다. 하지만 때때로 성능을 위해서 매크로, 복잡한 비트 연산등을 사용할 수 있다. 물론 가독성이라는 누구에겐 쉽게 읽히고 누구에겐 전혀 이해되지 않는 외계어로 느껴질 수 있다. 그래서 코딩 컨벤션(convention)을 두고 있지만 모든 프로그래머가 딱딱한 규칙에 얽매이는 것을 싫어해서인지 잘 지켜지지 않는다. 나조차 평소 몸에 베인 코딩 스타일을 포기하고 컨벤션을 따른다는 것이 꽤 신경 쓰이는 일이다.

 과연 코딩 컨벤션을 지키고 누가봐도 한번에 알아볼 수 있는 코드를 짜는 것이 그 프로그래머의 실력을 말해주는 걸까? 이런 착한 프로그래머를 싫어할 사람은 없을 것이다. 하지만 누가봐도 한번에 알아 볼 수 있는 코드라는 것이 정말 있을까? 100라인 정도에 그리 어렵지 않은 로직을 표현하고 있는 코드만을 생각하면 코딩 컨벤션을 지키는 것이 눈에 쉽게 들어오고 이해도 빨리할 수 있도록 도움을 준다. 하지만 10라인 이하의 짧은 코드에서도 복잡한 수식으로 되어 있다면 나같이 수학에 약한 사람은 코드를 수식으로 만들어 내는 과정이 꽤 힘들다. (수식은 주석으로 적어주면 아주 효과 적일것 같다.) 이제 천라인, 만라인 되는 코드를 보자. 한가지 간과할 수 있는게 우리는 코딩 가독성이라고 하면 눈앞에 보이는 몇십줄짜리 코드만을 생각하는 경향이 있는데 실제 코드를 이해 한다는 것은 프로그램 전체를 이해한다는 커다란 그림을 내포하고 있다. 현재 코드 파일을 스크롤하며, 정의 부분을 따라가고, 또 다른 코드 파일을 열고 함수를 찾아가며... 등과 같은 일련의 코드 읽는 작업들이 수없이 반복된다. 함수들의 호출 루트를 따라가며 어떻게 이런 함수를 쓰게 되었는지 알게 되는 과정에 많은 공을 들인다. 몇백만라인의 윈도우, 리눅스 이걸 코딩 컨벤션을 지키고 최대한 알기 쉽게 표현했다고 해서 나같은 프로그래머가 쉽게 알아 들을 수 있을까? 이렇게 시스템 프로그래밍쪽을 예로 들자면 아마 부가적인 설명이 많이 필요할 것이다. 대학교에서 운영체제 시간에 몇줄 안되는 코드에 주석도 없는(아마 주석없이 코드만 보면 이해할 것이라고 생각하는가 보다)부분들에 대해 책에서는 몇페이지에 걸처 설명을 줄줄이 설명을 늘어놓은 경우가 있다. 이런식으로 코드를 짜는 OS 를 만드는 몇몇 천재들이 만들어놓은 것들을 보면 우리는 코드 이해력이 많이 떨어진다는 것을 체감할 수 있을 것이다. 극단적인 예를 들었지만 많은 프로그래밍 수요가 있는 응용프로그램 개발에 있어서도 별반 다르지 않다. 물론 가독성 있는 코드를 생산하는 취지는 좋지만 가독성의 기준이 객관적일 수 없다는 것을 알아야 한다. 아래 A,B 프로그램의 의견 중 누가 옳은지 판단 할수 없다. 이건 마치 정장을 즐겨 입느냐 청바지에 셔츠를 좋아하느냐의 차이와도 같다.

 A 프로그래머 왈 "변수명은 소문자로 시작하는게 편하고 중괄호는 다음 줄에 시작하는것이 익숙해."
 B 프로그래머 왈 "아니, 나는 변수명은 변수타입을 명시하는 prefix 와 언더바로 시작하고 중괄호는 제어문 바로 옆에서 시작하는것이 좋아."

 최근 Go, Python 같은 프로그래밍의 언어를 보면 들여쓰기, 중괄호의 위치, 변수명(Go에서는 변수명 첫자가 대/소문자냐에 따라 외부에서 액세스 여부가 갈린다.)까지 고정되어 있어 지켜지지 않으면 컴파일 단계에서 에러가 발생하게 된다. 결국 컨벤션을 프로그래머가 신경쓰지 않을 정도로 일반화되고 최대한 구현 방법에 집중할 수 있도록 하는 방향으로 발전한다. 아직까진 좀더 디테일한 부분까지는 언어가 제약하고 있진 않지만 Go, Python 등 최신 트렌드의 언어들은 코딩 스타일의 많은 부분을 고정시켜 놓고있다. 아마 점점 이런한 방식으로 발전한다면 지금보다는 코딩 스타일 변형 폭이 줄어들어 대부분의 프로그래머들이 같은 코딩 스타일로 통합(?)되는 효과가 있을 것이다.

 말하고싶은건 코딩 스타일에 따라 가독성이 좋다 안좋다라고 하는 것으로 프로그래머의 실력을 가늠해선 안된다는 것이다. 나도 가끔 변수명, 들여쓰기 부터 이해가 가지 않는 로직을 볼때면 스트레스가 이만 저만이 아니다. 그렇다고 이 프로그래머의 실력이 개떡같다고 단정지으면 안된다. 암호처럼 되어 있는 코드도 차분한게 이해하는 노력이 필요하다. 실제 나이가 지극하신 아키텍트들의 오래된 코딩 습관을 보면 메모리 절약을 위해 또는 조금의 성능향상을 위해서 매크로나 기타 비트 연산에 많은 공을 들이는 것을 자주 본다. 지금 시대의 컴퓨팅 파워를 봤을때 예전처럼 효과가 있진 않지만 이런 코드를 보며 배울 수 있다는 것에서 의미가 있다. 처음에는 쉽지 않겠지만 이것도 실력있는 프로그래머로써의 자질이라고 생각한다. 이렇게 말한다고 해서 정말 최소한의 탭간격도 지키지 않고, 일관성없는 스타일로 버무려진 스파게티 코드를 작성한 프로그래머라면 단언컨대 나쁜(실력 없는) 프로그래머가 분명할 것이다. 남의 코드를 보고 비평할 수 있으려면 그 코드를 완벽히 이해하고 잘못된 부분을 찾아 낼 수 있는 능력을 키워야 한다.

좋은 프로그래머란? 두번째

좋은 프로그래머란 무엇일까? 두번째 글

 흠... 가끔 이 질문을 스스로에게 던질 때면 나도 모르게 흥분된다. 아니 좀 화가 난다는 표현이 맞을거당. 프로그래머 마다 중점을 두는 부분이 다르고 때론 이런 생각들끼리 상충되기 때문이다. 지난번에 기술적 측면에서 끊임 없이 공부하고 성장하는 사람이 되어야 한다는 생각에는 변함이 없다.

 이번에는 인성적인 측면에서 좋은 프로그래머는 어떤 사람인가를 따져보고 싶다.
프로그래머들끼리 모이면 심심치 않게 자신이 선호하는 기술이나 아이디어를 가지고 싸우는 경우를 본다. 이건 이래서 좋다. 당신이 말하는건 이런 단점이 있다.. 등등 상대방의 헛점을 파고들어 공격하는 듯이 말한다. 물론 어느 정도라면 이런 토론은 좋은 선택을 할 수 있도록 도와준다. 하지만 어떨 때는 서로 기분 상하고 일을 더디게 만들고 심하면 저 사람과는 다신 일하고 싶지 않다는 생각마저 들 수 있다.(이러면 최악의 경우 누구 하나는 회사 그만 둘수도ㅠ)

 얘기를 들어보면 정말 논리적인 이유로 어느 한 사람의 손을 들어줘야할 때도 있지만 피장파장, 다시 말해 어느 것을 선택 해도 완벽하지 않으니 부족한 부분은 조금씩 보완해야 하는 경우가 대부분이다. 이게 말이 쉽지 나 조차도 내 의견이 상대방에 의해 밀리면 프로그래머의 자존심에 기스가는 것 같고 겜에서 진것 마냥 씩씩거릴 수 있다. 이건 비단 프로그래머라서가 아니라 사람이라는 누구나 느낄 수 있는 감정 아니겠는가.

 여기서 좋은 프로그래머라면 상대방을 잘 설득하거나 상대의 의견을 존중하고 의견을 따르게 된다. 일종의 커뮤니케이션 능력이라고도 볼 수 있겠지만 커뮤니케이션 이전에 자신의 부족한 부분을 인정하는... 내가 잘못 생각할 수 있겠구나 하는 마음가짐을 가지는것이 우선이다. 반대로 정말 상대가 말도 안되는 얘기를 하고 있다는 확신있다면 상대방의 맘 상하지 않게 설득할 수 있는 커뮤니케이션 능력도 필요하다. 그리고 제3자의 입장인 프로그래머가 있다면 수락되지 않은 사람의 의견도 존중해주고 격려해주는 분위기를 만들어야 한다. 우리는 어렸을 때부터 승자에겐 관대하고 패자에게는 비난의 화살을 돌리는 일에 나도 모르게 익숙해져 있다.

 프로그래머란 논리적으로 생각하고 이성적으로 판단해야 되지만 그 이전에 나와 동료는 감정을 가지고 있는 사람이라는 것을 염두해야 된다. 당연한 말들을 한것 같은데 나도 모르게 무심코 뱉은 말에 대해 다시 생각해보자.

프로그래밍 경진 대회

각종 프로그래밍 경진대회를 잘 정리해둔 기사이다.

한번은 도전해보고 싶은데, 문제들을 보면 후덜덜하네(ㅠㅠ)

http://www.bloter.net/archives/179092

윈도우 9 가 없는 이유

예전 Windows 95, 98 는 윈도우 버전을 파악할때 Windows 9x 로 문자열을 비교하는 코드가 존재해 오류를 발생할 수 있다고 한다.
때문에 Windows 9 라는 제품명 대신 Windows 10 로 넘어갔다.
윈도우 95, 98 도 실제 버전은 9가 아닌데, 지금 와서 생긴 일종의 버그네~ㅎ

스티브 잡스와 데니스 리치

같은해에 세상을 떠난 두분(아래 비교가 스티브 잡스를 좀 깍아내리는 측면이 없진 않다.)
둘다 대단한 업적들을 남겼지만 대부분의 사람들은 데니리 리치가 누구인지 조차 모른다.
사회적 분위기 속에 들어나지 않은 위대한 사람도 있다는걸 잊지말자~

좋은 프로그래머란?

 좋은 프로그래머란 뭘까? (회사에선 좋은 개발자라고 말하는데, 전에도 언급했지만 개발자(X)->프로그래머(O) 가 좋다.) 이 질문에 대해서 생각을 정리할 필요하 있어 글을 남긴다.

 나와 같은 프로그래밍을 하는 님들께 이 질문을 던지면 나름대로의 이유있는 답들을 하며, 몇시간동안 끝나지 않을 이야기가 시작되곤 한다. 가만히 들어보면 모두 맞는 말이다. 간혹 "야근을 하면서까지 일하는.... 회사에서 시키는 일만 잘하는.... "등의 맘에 들지 않는 말들도 있지만, 뭐 그것도 자기가 그렇게 생각하는걸 뭐 어쩌겠나~ 물론 회사에서 돈을 받고 다니는 직딩은 주어진 임무에 대해서 실수 없이 일정까먹지 않고 완료하는게 당연하다.

 '좋은' 이라는 수식어를 붙인 프로그래머는 어떨까? 돈을 받고 회사에 몸담고 있는 사람으로써 좋은 프로그램머는 결국 한정된 리소스(시간,비용등)내에서 프로젝트에 완성도를 높여 회사의 이익을 극대화할 수 있는 사람이 아닐까? 당연한 얘기일지 모르지만 막상 프로젝트를 진행하다보면 시간과 비용은 물론이고 예측하지 못했던 돌발변수가 발생해 결과물은 언제나올지 모를 상황이 벌어진다. 기획이나 디자인 부분에서 문제가 생길 수 도 있겠지만 결국 최종 결과물은 프로그래밍 영역이기 때문에 프로그래머라면 어떤 상황에서도 당황하지 않고 프로젝트를 완성할 수 있어야 한다.

 프로그래머라는 직업도 막상 발을 들여보면 여러가지 다양한 카테고리로 구분할 수 있다.
게임이냐, 웹이냐, 서버냐 클라냐, 어떤 프로그래밍 랭귀지를 쓰느냐 그 기준도 정하기 나름이고... 이 모든것을 골고루 잘하면 좋겠지만(물론 다 잘하는 천재도 있겠지ㅠㅠ) 보통 현재 자기가 하고 있는 일과 관련한 기술들을 습득하고 반복하게 된다.

 예를 들어... 현재 내가 하고 있는 일은 게임 서버 프로그래머 이다. 프로그래밍은 C++ 이고 IDE 로 Visual Studio 를 사용 DB 는 mysql 을 사용한다. 아마 대부분의 게임 서버 프로그래머가 가지는 공통 속성일것이다. 대학을 막 졸업하고 첨 이 일을 시작하는 신입 프로그래머에게는 시니어들과 작업하면 신기하고 재밌어하며 기술을 배워갈 것이다. 이 신입은 프로그래머가 3년뒤 같은 일을 하고 있다면 이 분야에서만큰 어느정도 기술과 경험을 갖추었을 것이고 성능(?ㅎㅎ)도 제대로 내고 있을 것이다. 입사한지 5년이 흐르고 회사에서 일잘하는 평판도 있도 이제 게임 서버 만드는것도 쉬워지고 제법 자신감도 크다. 이 프로그래머는 아마 10년 넘게 같은 일을 할 수 있을 것이다. 하지만 연봉은 년차에 비해서 그리 높지 않을 것이며 점점 프로그래머로서의 입지가 줄어들 것으로 본다.

 2000년대 이전의 관료적인 사고방식을 가진 공공기관, 제조업체들에서는 이렇게 일하는것이 좋았을지도 모른다. 하지만 IT 업계는 요즘도 그렇게 외치는 '혁신'이 없으면 살아남기 힘든곳이다. 혁신이라는 말을 여러가지 의미로 해석할 수 있지만 프로그래머에 있어서는 끊임없는 자기발전이 밑바탕이 되어야한다.

 내가 하고 있는 일은 언제부터인가 반복적이고 언제든지 나를 대체할 사람이 있다는것이 슬프지만 현실이다. 프로그래머가 적다고 하지만 요즘처럼 IT 기기가 친숙하고 국가적으로 SW산업을 육성한다고 학교에서도 교육을 시작하자고 하는 마당에 젊고 파릇파릇한 녀석들이 빠르고 명석한 두뇌로 내 자리를 위협할 것이다.

 프로그래머 개인적으로 봤을때 내 일을 대체할 사람이 널려 있다는것은 그만큼 내 몸값이 작다는 것이다. 그러면 내 몸값이 높다는건 내가 하고 있는 일을 할 수 있는 사람이 그리 많지 않다는 것이다. 하는 일이 얼마나 어렵고 높은 기술을 요하는데 그럴까? 여기서 일의 특성으로 두가지로 타입으로 나뉠 수 있는데...

 첫번째는 그 일에 대해서 완전 빠삭하고 깊게 알고 있는 스페셜리스트가 되는것이다. 프로그래머들에게서 신급으로 심지어 찬양 받는 해커들, 창시자들.... 등이 있다. 프로그래머들 사이에서 이름만 대면 알 수 있는 유명인이 아니더라도 각 회사에서 기술 아키텍트라고 칭하는 이들이 대표적이다. 다른말로 하면 장인이라고 할 수 있는 월등한 실력을 갖춘 이런 사람들은 박사급이 대부분이이고 그분야에서 어딜가도 꿀리지 않게 얘기할 수 있는 님들이다. 보다 견고하고 신리도 높은 시스템을 만들때 절대적으로 필요한 인력으로 구글, 애플등과 같이 세계최고의 글로벌 IT 기업들의 튼튼한 버팀목이 되어 준다. 비단 최고의 회사가 아니더라도 우리 주위에서 잘나간다는 회사들을 보면 이런 사람들이 꼭 존재한다.

 두번째는 이것저것 다양한 각 분야에서 보통은 한다는 제너널리스트가 있다. 예를 들어 게임 서버 프로그래머가 게임 클레이언트와 웹서버까지 개발할 수 있다면 각각 직군에 필요한 인력 2명은 아니더라도 1명으로 줄이고 어느정도 업무를 분담할 수 있다. 물론 본인 업무외 다른 분야를 심도있게 파고들지는 않아 스페셜리스에 비할바는 아니지만 다양한 분야의 경험은 프로젝트를 완성 속도를 높이고 다양한 경험으로 어쩔땐 높은 시너지효과를 가져오기도 한다. 회사입장에선 인력비용 절감과 사람 수에 따라 증가될 수 밖에 없는 커뮤니케이션 시간(꼭 사람들이 많아야 일을 빨리하고 좋은 품질이 나오는것은 아니기 때문에)을 줄일 수 있다.

 스페설리스트든지 제너널리스트든지 모두 밑바탕에 자기발전이 깔려 있다. 좋은 프로그래머는 이런 자기발전을 끊임없이 한다. 좀더 깊이 연구하고 내 일만 고집하지 않고 다른 분야도 공부하면서 언제 있을지 모를 위협에 대비해보자. 회사도 경쟁력을 잃지 않기 위해서 이런 좋은 프로그래머들을 많이 확보할 수 있도록 연구하고 노력해야 되지 않을까.

 참고로 요즘에는 제너널 리스트와 스페셜 리스트를 모두 아우르는 'T'자형, 'ㅠ'(파이)형(http://goodgle.kr/977) 인재가 결론이다라는 말도 많이 하더라. 왠지 사람들은 어느 한쪽도 부족하지 않은 완벽한 인간이 되기를 원하는것 같다. 100%가 아닌 80%도 되기 힘든 나로서는 어쩌란 말인지~ㅎ

게임 업계 개발자 가지 말라~

현재 게임쪽에 종사하는 프로그래머로써 어느정도 일리가 있어 보인다.

"개처럼 일하면 개취급 당합니다. 개발자가 가장 연봉이 많이 올라가는 시기는 열심히 일할 때가 아니라 새회사로 이직할 때입니다."
-> http://pillnaro.tistory.com/1098

한국의 쪼기 조직 문화

한국의 쪼기 조직 문화... 완전 공감 되는 글이다.

http://mbablogger.net/?p=6203

야근 하는 프로그래머...

프로그래머는 인간이지 기계가 아닌데... 임백준 님의 글에 100% 공감중.

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140218180039&type=xml

2013 년 전세계를 장악한 웹싸이트

2013 년 전세계에서 우위(장악?)를 점하고 있는 웹싸이트들..
한국은 Naver? Daum? ...
조사를 못한건지 작은 나라라 관심이 없는건지 unkown 으로 되어 있다.

http://visual.ly/world-map-dominating-websites


참고로 http://visual.ly/ 에서 많은 인포그래픽 자료를 찾을 수 있다.

프로그래머, 해커 vs 개발자, 엔지니어...

프로그래머/개발자/코더/해커/엔지니어...
비슷한 의미를 가지는 단어라고는 하지만 단어에서 풍기는 냄새는 사뭇 다르다.

Developers... MS 스티브 발머가 외치는 개발자라는 단어는
관료주의 회사의 일개미 뉘앙스가 강하게 느껴진다.


폴그레이험 - 프로그래머이자 드롭박스를 인큐베이팅한 창업 투자가
http://www.paulgraham.com/

나도 프로그래머라는 단어를 가장 선호한다.(사실 가장 멋진 말은 해커^^)
하지만 현실에선 여기 저기 심지어 프로그래머 자신도 자신을 개발자로 부르고 있다.