레이블이 programmer인 게시물을 표시합니다. 모든 게시물 표시
레이블이 programmer인 게시물을 표시합니다. 모든 게시물 표시

code monkey 와 ninja programmer

국내에서는 그리 많이 쓰이는 용어 같지 않은데, 어쩌다 외국 프로그래머 관련 글이나 동영상을 보면 code-monkey(코드몽키)와 ninja-programmer(닌자프로그래머)라는 말이 언급 되는 경우가 있다. 둘다 프로그래머을 지칭하는 말인데 처음 들었을때 단어에서 풍기는 뉘앙스가 code-monkey는 원숭이라는 단어가 우습고 약간 멍청한 느낌이고 ninja-programmer 는 왠지 닌자처럼 은둔하면서 일을 처리하는 은둔고수를 표현하고 있는것 같았다. 아니나 다를까 그 단어에서 풍기는 뉘앙스가 거의 맞아 떨어졌다.

code-monkey 는 보통 프로그래밍을 업으로 막 시작한 초짜 주니어 프로그래머로, 흔히들 코더(coder)라고들 부르기도 한다. 단순하고 반복되는 코딩 작업을 하며 깊은 생각을 하지 않고 어셈블리라인(assembly line, 공장 조립 라인)처림 좀 과격하게 말해 멍청한 코드를 생산하는 어리석은 주니어 프로그래머라고 한다. 바나나로 훈련된 원숭이가 컴퓨터 앞에 앉아 타자치는 이미지를 생각하면 될 것 같다. 그런데 초짜 주니어라고해도 왠만한 시니어 이상의 머리회전과 스킬셋을 무장한 특출난 사람도 요즘엔 심심치 않게 보이고 또 이런 친구들한테 오히려 많이 배우기도 한다.

ninja-programmer 는 코드몽키 처럼 지칭하는 단어에 코드가 들어가지 않고 프로그래머라는 단어가 들어간것 부터가 진정한 프로그래머라는 것을 암시한다. 코드 몽키가 원숭이 이미지를 떠올리면 됐듯이 닌자프로그래머는 일본 영화나 애니에서 그려지는 닌자를 떠올리면 된다. 그림자 처럼 은둔하면서 다른 사람들이 해결하지 못하는 골치아픈 일을 음지에서 쥐도 새도 모르게 해결하는 해커같은 자들을 말한다. 뛰어난 실력을 갖추고 항상 수련하는 닌자처럼 공부도 게을리 하지 않는다. 팀에서 프로젝트 진행시 쉽게 해결하지 못한 이슈들이 하룻밤 자고 다음 아침이 되면 (닌자프로그래머)에 의해 멋지게 해결된 상태가 된다. 이 닌자프로그래머는 말도 많이 없고 사람들 앞에 잘 나서지 않아 평소에는 존재감이 없지만 큰 문제가 터지면 꼭 남들 잘때(ㅋ)밤을 새워가며 문제를 파고들어 결국 해결하는 스타일이다. 한마디러 아주 실력있고 간지나는 프로그래머라고 할 수 있다.

다시 간략히 정리하면
코드몽키: 실수도 많고 아직 배워야할것도 많은 주니어지만 게으르고 멍청한 녀석
닌자프로그래머: 실력 좋고 평소엔 말수도 적어 존재감도 없지만 감쪽같이 문제를 해결하는 음지의 고수

좀더 다양한 스타일로 간달프, 이론가 등의 프로그래머 타입이 있다. 자세한 내용은

시간이 지나면서 경험도 좀 쌓이고 나름 노력을 했다면 예전의 어리숙한 주니어(junior)티를 벗어내고 나름 괜찮은 시니어가 됐다고 생각을 하게 되는데, 글쎄 난 아직 남들에게 senior 라고 당당하게 말하기가 부끄럽다. 그래도 이렇게 자신을 부끄럽게 생각하지 않고 나잘났다고 떠드는 껍데이 senior 보단 낫다고 맘속으로 위안을 한다. 10년이 넘게 키보드를 잡고 나름 프로그래머 위치를 지키고자 힘쓰고 있는데 점점 머리도 잘 안돌아가고 또 왜 이렇게 게을러진건지(겨울이라 잠만자고 싶은...), 닌자 프로그래머가 되기는 커녕 코드 몽키로 퇴화하는건 아닐런지, 열심히 learning 하자!

코딩테스트, 알고리즘테스트

코딩 문제를 어쩌다 풀면 느끼는건 내가 이렇게 바보인가라는 암울함과 풀었을때 밀려오는 앗싸 !풀었다 하는 뿌듯함이다. 후자까지 가기 어려운 문제들을 만나면 시간이 지날 수록 쌓여가는 스트레스와 집중력 저하로 그냥 포기하는게 정신 건강에 좋을때도 있는것 같다.
코딩테스트는 아주 어렵고 새로운 문제가 아니라면 일정한 알고리즘 방법들을 알고 응용하면 풀수있도록 만들어졌다. 그런데 나같이 알고리즘 공부를 맘먹고 해본적이 없거나 계속 문제를 풀어보지 않는 경우 그 쉬운 문제도 갈피를 못잡을때가 많다.
사실 코딩 하기전 생각을 하는 시간이 꽤길고, 그 생각(방법) 맞다면 몇분 안되는 코딩으로 결과를 낼 수 있어, 문제만 파악 되었다면 컴앞에 앉아 있지 않아도 된다. 편하게 누워서 머리속으로 이런저런 방법들을 생각해 볼 수 있다. 머리속에서 모든 것을 그려(시뮬레이션)볼 수 있는 고수가 아닌 내 경우는 종이에 이런저런 생각들을 써보고 정리하는게 많은 도움이 된다. 누구는 금방 생각나서 문제를 바로 푸는 사람이 있지만 여러가지 아이디어가 떠오르지만 막상 코딩 해보면 구멍이 많았다는것을 알게되는(나같은) 사람도 많을 것이다.
프로그래머로써 여러 유명한 프로그래밍 콘테스트에 입상하고 싶어 도전을 하는 경우도 있고 신입이나 이직을 생각하는 사람이라면 IT회사의 1차관문이자 역량의 척도로서 프로그래밍(코딩) 테스트를 보도록 한다. 프로그래밍 콘테스트는 경연지역이 넓어질수록 날아다니느 고수가 많고 등장하고 그만큼 문제도 어려우니 많은 준비(문제도 많이 풀고 알고리즘 책도 공부하고)가 필요한 경우이고, 입사,이직을 위한 경우라면 콘테스트까지는 아니니 문제를 어느정도 풀수 있어야 한다. 그런데 실무에서는 알고리즘을 생각하는 경우가 거의 없어 평소에 틈틈히 문제를 풀어봐서 감을 잃지 말아야한다. 그런데 게을러서 손을 많이 놓고 있는것 같다. 아니 사실은 어쩌다 문제에 꽂혀 풀고 나면 진이빠져 한동안 알고리즘을 생각하고 싶지 않게 된다. (충분한 휴식이 필요해~ㅋ) 암튼 알고리즘 문제를 들여다 보고 몇일 고생하고 풀어냈을때 만족감을 오랫만에 느낄 수 있어 좋았다.  그래도 꾸준히 문제를 풀어보지는 않을것 같다~ㅠ
한가지 불만사항은 문제의 난이도가 쉽고 어렵고를 떠나서 문제를 풀기 위해선 방법, 즉 알고리즘을 떠올려야 하고 이게 핵심인데, 모두들 코딩(coding)테스트라고 하고 한다. 사실 코딩이라는 것은 어떤 아이디어를 프로그래밍 언어의 문법(syntax)을 알아서 그 언어로 작성하는것이다. 영어를 안다고해서 미적분 문제을 풀지는 못한다. 미적분 문제를 푸는 방법이 알고리즘(algorithm)이라고 본다면 영어는 단순히 알고리즘을 표현하는 도구이고 이게 코딩이라고 생각한다. 아마 이렇게 까칠하게 나누지 않아도 알고리즘을 포함한 것을 일반적으로 문제를 푼다는 의미를 코딩에 암묵적으로 내포되어 있다고 모두들 알고 있을것 같다. 그래도 예전에 포스팅한 글에서 개발자라는 말보다 프로그래머라는 말을 쓰고 불러주길 바랬던것과 같이 코딩테스트가 알고리즘 또는 아이디어(방법을 생각해낸다는의 어떤 말???)같은 의미가 명확하게 들어가 있는 용어로 불렸으면 하는 바램이다.

프로그래머 폰트

iterm2 에선 monaco 사용하는데 역시 많이들 사용하는 폰트였군~


consolas 는 microsoft 에서 만든 대표 폰트
monaco 는 apple 에서 만든 대표 폰트

플밍랭귀지 만화는 늘 재밌어~ㅋ

플밍랭귀지 만화는 늘 재밌어~ㅋ
https://toggl.com/programming-princess/

Practice in piano, programming, english...

PC 앞에 앉아 구글을 띄워놓고 갑자기 멍해지는 순간이 있다. 분명 무엇을 검색하려고 띄운 구글인데, 검색어를 입력하지 못하고 있는것이다. 멀까? 무엇을 검색하려고 했던거지? 열심히 머리속을 뒤져보지만 도저히 생각나지 않는다. 한 10초가량 애쓴 끝에 한숨을 내쉬며 그냥 잊어버리기로 한다. 그리고 화장실로 향하는 순가 불현듯 스쳐지나가는 이미지. 아 그 인공지능 로봇 나오는 영화 제목을 알아려고 했었구나.(화장실을 다녀와서 구글링 검색~ㅎ)

이런 경험은 누구나 했을것이고 보통 나이가 많으면 자주 그런다며 가는 세월을 원망하는 이들도 있다. 나역시 에고~ 뇌세포가 하나씩 기력을 잃어 가는구나... 라고 대수롭지 않게 여겼다. 자 그런데 이 문제가 여기서 그치지 않고 나를 충격으로까지 몰고 가는 경우가 요즘 종종 보인다. 먼저 집에서 준영이와 놀아 주려고 피아노 건반을 치려는데 하도 쳐서 악보도 보지 않고 손가락이 저절도 움직였던 동요(^^;) 노래가 몇마디 가지 못하고 손가락이 혼란스러워 한다. 몇번을 시도해도 안되서 결국 악보를 보게 되었다. 플룻도 1년에 한두번 필받을때 꺼내는데 그때마다 손가락을 둘째치고 입술모양에 굉장히 힘이들어가고 쉽게 피로해서 한곡을 불면 입술이 뻐근해진다.

뭐 이정도의 취미생활은 그럴 수 있다. 이런저런 핑계로 또는 게을러서 손을 놓은 악기는 당연히 시간이 지나면서 까먹고 하니까. 그런데 이게 만약 내가 직업으로 삼는 프로그래밍이라면 어떨까? 여기서 더 큰 펀치로 날아온다. 모닝 퀘변을 위해 변기에 앉아 있을때 핸드폰으로 하는게 웹툰 보기, 기사검색, sns 등을 하는데, 어떻게 대학원때 랩실 홈페이지에 들어가게 되었고 여기서 잠깐 학생때의 추억을 회상하는데, 그때 배웠던 프로그래밍 알고리즘이 생각나고 그게 뭐였더라 하면서 자꾸 자신을 추궁하게 되었다. 내가 분명히 배웠고 프로젝트에 구현하며 논문까지 쓴것들이였는데 내부 알고리즘을 어떻게 프로그래밍을 했었는지 머리속으로 코딩을 해보려 하면 커서만 깜박이고 아무것도 할 수가 없더라. 결국 구글링하여 비슷한 예제 소스를 보면서 다시 기억을 살렸다. 아 근데 이게 정말 간단하고 쉬운 것인데 왜 이렇게 생각이 나지 않았을까? 곰곰히 생각해보면 위에서 말한 못치는 피아노 현상과 별반 다를게 없었다. 지금 업무와 상관없으니 굳이 코딩할 필요 없었던 것들이었고 그렇게 시간이 지나면서 머리속에서 점점 희미해져 갔다. 흠 지난번 면접 후기 포스트도 남겼고 반성도 했지만 그 이후로 행동이 크게 달라지지 않은것 같다.

영어하자. 영어해야된다. 라고 다짐하고 모르는 단어를 네이버 사전앱에 기록하고 계속 꺼내보면서 암기해야지라고 시작했던게 벌써 1년이 넘었다. 열심히 모르는 단어는 저장해 두긴했는데, 다시 꺼내보지 않았고 결국 예전에 분명 찾아서 알았던 단어인데 하면서 또 사전을 뒤지게 된다. 단어라함은 반본적으로 쓰고 익혀야 하는데 몰랐을때 한번을 넘기기 위해서, 그 위기를 모면하기 위해서 그렇게 일회용품처럼 사용하니 나중에 커다란 환경오염(모르는 영어 단어가 됨ㅠ)이 되어 돌아 오더라.

피아노, 프로그래밍, 영어 모두 멍청해지는것 같기도 하고 이대로 아무것도 못하는게 아닐까하는 생각에 사실 두렵다. 이를 타파할 방법이 무엇일까? 결론을 내리면 천재가 아닌 내 입장에선 꾸준히 연습하는 길, 연습이라 하면 노력과 힘든 일을 이겨내야 하는 뉘앙스가 풍기는 단어다. 재미가 있으면 연습이 좋을텐데 솔직히 지금은 연습이 좀 귀찮긴 하다. 그래도 이 글을 쓰면서 흐트러진 마음을 조금이나마 다잡아 본다. 연습이 나중에 습관으로 바뀌길 기대하면서 오늘도 "hello world"를 화면에 뿌려보자.ㅎ

프로그래밍 언어의 개성

각 프로그래밍 언어들의 개성이 싫어지기도 한다.



http://www.itworld.co.kr/news/99430?page=0%2C1


면접 후기

프로그래머라는 기술직에 종사하면 내 나이쯤 되면 한번 쯤 생각해보는 이직, 나역시 예외일 수 없다. 표면적으로는 새로운 일에 대한 도전, 현재 업무에 대한 매너리즘, 자기 발전등을 위해서, 그리고 솔직히 좋은 연봉과 처우를 위해서 이직을 고려하게 된다. 정말 실력있는 프로그래머라면 여기저기서 모셔가려 하겠지만 그건 일부분일테고, 나와 같은 평범한 프로그래머라면 두손 두발로 열심히 구인 정보를 찾고 문을 두드려야 한다. 최근 2~3달간 국내 대표적인 기업들에 지원서를 내면서 겪었던 경험은 이직을 처음 시도한 나에게 많은 충격과 고민을 안겨주었다.

보통 기업들의 채용과정은 서류심사, 1차면접, 2차면접의 절차를 거치게 된다. 1차는 기술 면접이고 미리 온라인으로 코딩테스트를 하거나, 전화로 간단한 질문을 하는 경우도 있다. 몇군데 서류 및 온라인 코딩 테스트등을 통과하면서 자신감이 올라간 상태라 그런지 1차 기술면접도 자신이 있었지만 몇곳은 불합격되었다. 뭐 최종 합격한곳이 있어 결국 이직은 성공했지만 불합격 된 원인을 파악하기 위해서 기술 면접을 통해 경험한 것들을 좀 정리해 본다.

기술 면접은 보통 문제를 주고 손 코딩을 시키거나 특정 기술 및 원리등을 질문한다. 첫번째 손코딩의 경우는 그리 어렵지 않은 수준의 문제들을 내는데, PC로 디버깅이나 테스트를 할 수 없기 때문에 코드를 적기전 문제 파악 및 해결 방법을 대략적으로 머리속으로 생각해 결론을 내야 한다. 여기서 충격은 정말 쉬운 문제인데 갑자기 풀려고 하면 생각이 하나도 나지 않는 것이다. 이것보다 더 어려운 문제도 열심히 고민해서 풀었는데 쉬운 문제를 풀지 못할때는 정말 얼굴이 시뻘게 진다. 우선 면접은 사람이 평가되다보니 나같은 경우 굉장히 긴장해서 머리도 잘 안돌아가고 실수도 연발 하게 되더라. 그런데 면접이 끝나고 그 문제를 곰곰히 생각해보았지만 쉽사리 답을 찾을 수 없었다. 그러다 갑자기 유레카! 아 이렇게 하면되는 구나하고 솔루션이 떠오른다. 왜 이럴까? 변명일 수도 있겠지만 쉬운 문제라는게 사실은 나름 고민해서 나온 최상의 솔루션이라는 것이다. 그저 아 이런 문제는 이렇게 풀면 되는구나하고 코딩하번 하면서 익혔지만 수년동안 그 코드을 생각할 일이 없어지면서 머리속에 그 방정식(아이디어)은 날라가 버렸다. 그리고 그 문제를 해결하기 위해서 처음부터 수많은 생각을 시도해야 했다. 아마 일반적인 면접관들은 문제를 풀고 못풀고만 중요할 것이다. 왜 저렇게 쉬운 문제를 이렇게 오래 생각할까? 실력이 형편없군. 하며 속으로 생각할지도 모르겠다. 사실 이쪽 업계에서 기술 면접시 물어볼 수 있는 유명한 마치 기출 문제라도 되는 듯한 것들을 인터넷을 검색하면 쉽게 찾을 수 있다. 그럼 미리 기출문제를 풀어보면서 기술면접에 준비해야 되는데 이걸 안한 너의 잘못이라고 말할 수 도 있겠지만, 난 그러고 싶지 않았다. 미리 준비하는것이 나쁜것은 아니지만 평소에 내실력이 이렇다라는 것을 보여주기 위해서는 준비없이 평상시의 상태로 가야 한다는것이 내 생각이다. 평소에서 이것저것 문제를 많이 풀는 습관이 있다면 그자체가 실력으로 표출되기 때문이다. 그리고 한가지 코딩 면접에 바라는 것은 꼭 해답을 제시하기보다는 문제를 풀기위해서 이런 저런 방법을 시도해 보는것, 어떤 생각들을 했었는지 들어봤으면 한다. 비록 그 생각 틀렸다 하더라도 말이다. 결국 회사에서 정답이 없는 문제들을 해결하기 위한 시도들이 중요하기 때문이다. 이렇게 말하지만 프로그래머서라면 쉬운 문제들을 풀지 못한 자신도 한번 되돌아 봐야한다. 자 이제 두번째 기술 질의 응답의 경우를 살펴보자. 보통 경력 지원을 하는 곳이 이전 커리어와 연관된 팀에 지원을 하게 되고 그쪽 방면에서 사용하는 기술에 대해서 많이 알고 있어야 한다. 하지만 내 경우는 현재 있는 팀의 업무를 하는 곳은 몇군데 없고 업무 자체에 흥미를 잃어버린 상태라 직무를 변환하고 싶었다. 그래서 현재 업무와 다른 새로운 직무에 지원을 하게되었다. 뭐 프로그래머라는 전체 도메인을 봤을 기술 면접 이전까지는 무리 없이 진행이 되었다. 하지만 기술 면접에서는 물어보는 기술들은 아직 내가 현업에서 사용해보지 못한 것들도 있었고 정말 평소에 업무에는 무시하고 넘어가는 기술의 세부 스펙등 질문의 유형은 다양했다. 때로는 db, network, complier, os 등 넓게, 때로는 network tcp 내부 스펙 옵션등 한분야로 깊게, 모르면 모르겠다고 말해달라기에 당당하게 모른다를 남발하게 되었다. 여기서 참 모르는게 많구나~ 참 알아야 될것도 많구나~ 라는 이중적인 생각이 들었다. 그리고 모르는건 구글링해서 알아보면 안되요? 라고 반문도 하고 싶었다. 내가 블로그를 사용하는 가장 큰 이유가 시간이 지나고 사용하지 않게 되면 잊어버린 경우 블로그에서 쉽게 찾아보기 위한것이다. 물론 프로그래머라면 기본적인것들은 머리속에 넣어두어야 하지만 내 머리의 용량 한계가 있어서 그런지 LRU(LeastRecentlyUsed) 캐싱 방식으로 계속 사용하지 않는 지식은 머리속에서 말끔히 지워버린다. 뭐 그래도 모르는것보다는 아는것이 좋으니 많이 알고 있는 다른 지원자들에게 밀렸던것 같다. 평소 무심코 흘려보냈던 os, network, db 등에 대해서도 다시 한번 자세히 파고들어야 할것 같다.

뭐 변명을 하고 싶어서 주절주절 썼다고 생각도 들지만 나름 사람한명 뽑는것이 쉬운일이 아니니 면접관 입장에서도 많은 고민이 있어야 할것 같다. 그리고 꼭 이직을 위해서가 아니라 긴장감을 주기 위해서 다른 업체 사람들 만나서 평가도 받아보고 이런저런 기술얘기도 할 수있다는 측면에서 면접을 한두번 보는것도 좋은것 같다. 이제는 새로운 업무를 해야되니 또 열심히 달려봐야지~^^

편한 개발 환경

라이브러리, 모듈, 알고리즘 왠만한건 다 가져다 쓸 수 있는 편한 개발 환경에만 의존하면 프로그래머 자신의 사고력과 능력은 낮아 질수 밖에 없다. 그래도 개발 환경의 편의로 얻는 생산성을 무시 못하니 적절하게 사용하는게 좋을듯 하다.
http://www.zdnet.co.kr/column/column_view.asp?artice_id=20140811090423

개발자가 알아야하는것

세상에서는 정말 알아야 할것이 너무 많다고 생각하고 나도 모르게 자신에게 스트레스를 주고 있었던건 아닌지 싶다.
http://www.zdnet.co.kr/column/column_view.asp?artice_id=20160125081726

연봉과 재미

연봉도 중요 하지만 재미와 발전할 수 있는 기회가 있는 직장으로 가고 싶다...
http://navercast.naver.com/contents.nhn?rid=213&contents_id=38808

golang 의 매력

golang 이 널리 퍼지길~ㅎ



https://iamprogrammer.io/2015/03/26/episode-2-%EA%B5%AC%EA%B8%80-%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EA%B0%80-%EB%A7%90%ED%95%98%EB%8A%94-go%EC%96%B8%EC%96%B4%EC%9D%98-%EB%A7%A4%EB%A0%A5-1%EB%B6%80/


프로그래밍 언어 익히기

새로운 프로그래밍 언어를 익힐때 여러소스를 참고 하면서 나만의 프로그램을 만들어 보았는데 잘하고 있는 거였네.
http://www.improgrammer.net/5-ways-to-learn-programming-faster/?utm_content=buffer24709&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer

파이썬3 로 넘어가기

흠 파이썬 3 이 좋은것 같은데, 변화의 속도가 너무 더디다.
https://b.ssut.me/64

모른다고 겁먹지 말자.

 요새 듣고 있는 팟캐스트 중 지대넓얕(지적 대화를 위한 넓고 얕은 지식)이라는게 있다. 평소 궁금하고 잘 알지 못했던 내용들을 쉽게 설명도 해주고 토론도하고 아주 재밌게 듣고있는데, 문득 내가 몸담고 있는 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자의 입장인 프로그래머가 있다면 수락되지 않은 사람의 의견도 존중해주고 격려해주는 분위기를 만들어야 한다. 우리는 어렸을 때부터 승자에겐 관대하고 패자에게는 비난의 화살을 돌리는 일에 나도 모르게 익숙해져 있다.

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

좋은 프로그래머란?

 좋은 프로그래머란 뭘까? (회사에선 좋은 개발자라고 말하는데, 전에도 언급했지만 개발자(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%도 되기 힘든 나로서는 어쩌란 말인지~ㅎ

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

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

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


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

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

주말밤 코딩

주말 밤 늦게까지 이어지는 코딩 작업은 해결 되지 못한 문제에 대한 내 강박관념으로 시작된다.
아~ 이 문제 도대체 뭐가 잘못된건지 해결하지 못하면 편하게 잠을 청할 수 없다.
이렇게 해보고 저렇게 해보고 그렇게 2~3시간은 훌쩍 넘겨버리는데 답은 쉽사리 보이지 않는다.
그러고 보면 이렇게 시간빨리 가는 일도 없다.
뭔가 골똘이 생각하고 한 곳에 집중하다 보면 뇌가 심장처럼 뛰고 고속질주하는 자동차 엔진처럼 열이 난다.
결국 원인을 알고 보면 변수 하나를 잘못쓴것... 에휴~
이것도 모르고 코드 파일을 정신없이 스위칭해가며 수많은 코드들속에 허우적거렸다니...
나름 경력이 쌓이면서 초보적의 실수가 줄었는데도 이런 상황은 가끔 나를 지치게한다.
그래도 몇시간이 흘러도 몇일이 지나도 해결되지 않던 문제를 푸는 순간의 뿌듯함이란 이루 말할 수 없다.
아마 이맛 때문에 프로그래밍을 좋아하는지도 모르겠다.
프로그래밍한다는 것은 멋진일이다. 적어도 아직까진 그렇다.