프로그래머

• 관련 항목 : 직업 관련 정보, 컴퓨터 관련 정보

1 개요

프로글래머
프로그래머란 컴퓨터 프로그램을 만드는 사람이다. 전 세계적으로 유명한 프로그래머로는 존 카멕, 성공한 사람들 중엔 빌 게이츠 같은 사람이 있다. 이 나무위키도 프로그래머의 손 끝에서 탄생한 것이다. 무슨 주문을 외웠길래 이런 위키가 만들어졌는지 알고 싶고 지금 크롬으로 접속했다면 Ctrl+U를 눌러보자.(또는 F12도 된다).대강 무슨 주문을 외웠는지 엿볼 수 있을 것이다. 물론 관련 지식이 없다면 주문의 내용을 해석할 수는 없겠지만, 일단 주문의 모습은 볼 수 있을 것이다.

서양에서는 '프로그래머들 중엔 비만이 많다'는 편견이 있다고 한다. 하루종일 컴퓨터 앞에 앉아서 간식 처묵하는 이미지 때문인 듯하다.(...) 물론, 실제로 프로그래머들은 대부분 의자에 앉아 있는 시간이 많으므로 대개 운동이 부족한 것은 사실이다. 그러나, 실제 제대로된 프로그래머들 중에서는 비만이 거의 없는데, 왜냐하면 생각하느라 먹을 생각을 잘 안하기 때문이다. 구글 직원이라면 몸짱일수도(...) 쓸만한 프로그래머들은 내가 만드려는 프로그램에 대해 생각하는데 80%이상의 시간을 쓰고, 그걸 구현하는데는 20%의 시간도 안쓴다. 그리고 프로그래머들은 자신의 능력을 이용해 간혹 기발한 일을 벌이기도 하는데, 그게 나쁜 쪽으로 발현되는 것 중의 하나가 바로 크래킹이다. 같은 맥락에서 프로그래머는 보통 개인주의적 괴짜 집단 내지 틀에 박힌 것에 거부감을 지닌 이미지로 연상되기도 한다.............

2 거창한 알고리즘 연구자가 아니다

보통 수학이론을 이용하여 알고리즘에 대해 연구하는 사람과 프로그래머를 혼동하곤 하는데, 일반적인 프로그래머는 거창한 알고리즘 연구자가 아니다. 여러분이 생각하는 그 알고리즘 연구는 보통 대학원의 연구실이나, 대기업 연구소 등에서 이뤄진다. 그에 반해 일반적인 프로그래머들은 사실 조립공이라고 보는 것이 정확할 것이다. 알고리즘 자체에 대한 연구는 수학자나 전산학자(컴퓨터공학자)들이 하는 것이고, 그 연구 결과를 소수의 코어파트 프로그래머들이 가져다가 부품을 개발하며, 그 부품을 대다수의 일반 프로그래머들이 사용한다.

위 문단보다 더 와닿게 비유하자면 프로그래머는 건설업에서의 인부와 같다. 살짝 안습해 보일지 몰라도 사실이다. 초창기엔 머리만 좋으면 뭘 해낼수 있었지만 현재의 몇십만줄의 코드가 들어가는 프로그램은 폰 노이만이 와도 도저히 혼자서 만들수가 없다. 개인별 능률에 분명히 차이가 있지만 어차피 똑같은거 가지고 구현하는건데 시간의 차이가 있을뿐 결과물은 비슷하다(물론 발코딩은 예외다) . 위 사실은 프로그래머가 대체 가능 하다는걸 의미한다. 프로그래머가 희소성 있고 전문적인 직업이라고 생각했으면 상상이 깨질만한 부분. 물론 다른 대부분의 직업들, 심지어 전문의라고 할 지라도 마찬가지지만.

3 최초의 프로그래머

프로그래머는 대표적인 남초 직업이다. 그런데 의외로 최초의 프로그래머로 인정받는 사람은 바로 러브레이스 백작부인 에이다 킹(1815 ~ 1852)이다. 그녀는 찰스 배비지의 해석 기관 컴퓨터 상의 구현을 알고리즘으로 설명한 최초의 사람이기도 하다.

최초의 프로그래머가 여성이라는 사실에 놀란 사람들도 있을텐데, 프로그래밍 관련 서적들을 읽다보면 간혹 저자가 여성인 경우도 있다. 이후로도 초기의 프로그래머는 여성이 많은데, 컴퓨터에서 넘어온 사람이 많았기 때문.

4 종류

'프로그래머'라는 단어 하나로 간편하게 통칭하여 부르고 있긴 하지만, 사실 프로그래머에도 여러 종류(?)가 있다. 고급 언어와 툴을 다룰 줄 아는게 전부인 프로그래머부터, 저급 언어까지 다룰 줄 아는 프로그래머까지 그 스펙트럼은 어마어마하게 넓다. 또 소수의 코어파트 프로그래머들이 있는가 하면, 다수의 양산형 프로그래머인 코더가 있다.

컴퓨터 프로그래밍 기술에 능숙한 사람들은 유명세를 타기도 하지만, 이러한 관심을 받는 대상은 보통 소프트웨어 공학자 집단으로 국한된다. 그리고 종종 저명한 프로그래머들 중에는 "해커"라는 이름으로 불리는 사람들도 있다.

4.1 일반 프로그래머

프로그래밍 언어, 알고리즘 등에 대한 전문 지식을 쌓고, 복잡하고 논리적이고 완성도 있는 프로그램을 개발하는 프로그래머들이 존재한다. 프로그래밍은 진입 장벽이 낮은 편이라 컴퓨터공학과 외에 거의 모든 공대에서 간단한 프로그래밍과 코딩 정도는 할 줄 알 정도라, 코더는 굉장히 많지만 알고리즘을 이해할 수 있는 프로그래머는 많지 않다. 정보 보안, OS, 네트워크 등 여러 방면에 있어서 1960년대 이후 계속해서 역할이 커지고 있다.

4.2 융합형 프로그래머

자신의 전문 지식을 바탕으로, 중급 수준의 프로그래밍을 익히고 직접 코딩을 하는 프로그래머들이 존재한다. 의사가 직접 의료 프로그램을 통계화, 수치화한다든가, 국과수 직원이 치아 감별을 통한 개인 식별을 위한 프로그래밍을 한다든가 하는 경우가 이에 속한다. 이들은 전문가 수준의 고급 코딩을 하지는 못하더라도, 자신이 원하는 프로그램을 짤 만한 코딩 능력은 갖추고 있으며, 무엇보다도 자신의 전공 분야에 대한 전문성이 탁월하기에 시너지 효과가 극대화된다. 마치 의사와 변호사가 합동으로 하는 것보다 의사 자격을 가진 변호사 한 명이 의료 소송 시장을 휩쓸고 있는 것처럼, 융합형 프로그래머는 자신의 전문성과 프로그래밍을 결합하여 그 분야의 전문가만이 떠올릴 수 있는 창의적인 아이디어를 바로 시장에 내보낼 수 있게 된다.

이들에게 요구되는 능력은 프로그래밍 능력이 아니라 자기 분야의 전문성이다. 전문성과 달리 프로그래밍은 극도로 완벽하고, 정교하고, 간결한 수준으로 잘 할 필요는 없다. 혹시 다소 불필요한 부분이 코드에 덕지덕지 붙어있다거나, 코딩하는 시간이 다소 오래 걸리거나 해도 크게 문제되지는 않는다. 이들에게 최우선으로 요구되는 사항은 전문성이고, 프로그래밍 능력은 그 다음이기 때문이다. 어차피 프로그램을 잘 짜서 성공하게 된다면, 그 다음부터는 프로그램 설계가 아닌 단순 코딩 정도는 양산형 프로그래머에게 맡겨도 된다.

4.3 코더

기술의 발전으로 왠만한 프로그래머용 툴도 입문 난이도가 내려갔다. 이 덕분에 프로그래밍의 진입 장벽은 상당히 낮다. 그리고 기업이나 컴퓨터 학원 등지에서는 기초적인 코딩만 배운 프로그래머를 배출하였다. 이러한 프로그래머를 비하하는 용어로 "코더"가 있다. 원래 코더란 프로그램 코드를 볼 수 있고, 이에 따른 전반적인 테스트할 수 있는 사람을 의미하는 용어다. 그런데 지금 코더라는 용어는, 단순히 코딩만 할줄 알 뿐, 자기 프로그램을 개발할 능력은 없는 어설픈 프로그래머를 비하하는 의미로 변질되어 쓰이고 있는 상황이다.

코더와 프로그래머의 차이는 '알고리즘을 스스로 설계할 수 있는지'의 여부에 있다. 즉 주어진 문제를 해결하는 방법을 스스로 찾아내서 코딩할 수 있으면 프로그래머고, 아니면 코더다. 조금 더 구체적으로 말하자면, 소스 코드를 복사해서 붙이는 것 밖에 할 줄 모르는 사람은 코더이고 소스 코드를 읽어서 그 작동 원리를 이해하고, 나아가 자신의 프로그램의 문맥에 맞게 튜닝해서 최적화할 수 있는 능력까지 갖춘 사람은 프로그래머다. 위에서 프로그래머는 거창한 알고리즘 연구자가 아니라고 하지 않았냐고? 거창한 알고리즘 연구자가 아닌 것 뿐이지, 일반적인(소소한) 알고리즘의 연구자는 맞다. 알고리즘이라는 단어 자체가 문제를 해결하는 방법 또는 절차를 의미한다. 자동차로 치면 코어파트 프로그래머가 튜닝 부품을 생산하는 업체라고 한다면, 프로그래머는 튜닝샵 직원, 코더는 서비스센터의 수습 정비사 정도 포지션정도에 해당한다.

프로그래머에게는 코드 리딩 능력도 중요하고, 자신에게 필요한 코드가 없을 때는 스스로 그것을 창조할 수 있는 능력도 있어야 한다. 즉 어떤 함수의 입력과 출력이 정의된 명세서가 주어지면 그 명세를 만족하는 코드(실제 컴파일 가능한 코드 또는 의사 코드)를 만들어낼 수 있는 사람이 프로그래머, 의사 코드(Pseudo code)가 주어졌을 때 그걸 실제로 동작하는 코드로 구현할 수 있는 사람은 코더라고 볼 수 있다. 다만 프로그래머가 의사 코드를 만들어서 코더한테 던져주는 프로세스는 요즘에 거의 사라졌다. 프로그래밍 언어가 많이 발전해서 현대의 프로그래밍 언어는 의사 코드에 매우 가깝다. 60년대에는 단순히 천공카드에 자료를 펀치하는 코더도 제대로 월급 받으면서 일할 수 있었지만 지금은 그런 저수준 작업이 필요없기 때문에 빨리 프로그래머로 전직(?)하는 게 좋다.

오늘날 플랫폼 싸움이 커지면서 각자 자신들의 플랫폼 생태계를 성장시키기 위해 어플리케이션 만드는 과정을 점점 쉽게 만들어가는 추세이다보니, 과거에는 자신이 만든 프로그램의 몇몇 파트에 다른 라이브러리의 함수를 가져다 사용하는 수준이었다면, 요즘엔 아예 프로그램의 구조와 디자인 및 대부분의 뼈대가 되는 코드를 플랫폼에서 제공하는 프레임워크가 다 만들어 놓으면, 프로그래머는 거기에 부분부분 자신의 코드를 끼워 넣어 손만 보는 수준까지 왔다. 도구 사용이 쉬워졌다는것은 도구 자체에 신경 써야 하는 시간과 노력을 원래 목적에 할애할 수 있게 되었다는 것이기도 하기 때문에, 오히려 환영하는 프로그래머들이 많다. 실제로 일일이 다 개발하는 데 드는 시간이 모두 절약되며, 코더 및 소프트웨어 개발자들에게 있어 시간은 곧 돈과 연결되기 때문이다.

물론 고급 프로그래머도 사람이기 때문에 설계 미스를 내는 경우가 있다. 대표적인 경우가 Win32 애플리케이션 API. 왠지 null값을 파라메터에 자주 넘긴다고 생각했다면 착각이 아니다. 그리고 PHP라는 언어도 함수 이름에 일관성이 없어서 레퍼런스를 항상 참고해야 한다. 뭔가 프레임워크를 사용하는 방식이 어렵게 느껴지면 첫째는 본인 실력을 의심해야 하는 게 맞지만 둘째로는 그 프레임워크의 설계가 잘못돼있을 가능성도 고려하자. 프레임워크를 바꿨더니 안 되던 일이 일사천리로 진행되는 경우도 간혹 있다. 대형 프레임워크일수록 이런 설계 결함이 발생할 확률이 높아지기 때문에 몇몇 프로그래머는 '마이크로 프레임워크' 쪽으로 전향하기도 한다.

고급 프로그래머 중에서도 전체 프레임워크 기본 틀을 설계하는 최상급 프로그래머들은 소프트웨어 아키텍트 라고도 불린다.

5 되는 방법

프로그래밍에 대해서 흥미를 잃기 쉬운 보수적인 교육환경이라면 파이썬을 선택하라. 하지만 모던 C++과 C# 등도 좋은 시작점이 된다.

프로그래머가 되고 싶다면, 한국의 컴퓨터공학 커리큘럼상에서는 C나 Java부터 가르치는데 이거 생까고 미국에서 입문과정으로 가르치는 Python부터 시작하는 것을 추천한다. 미국에서 괜히 파이썬을 입문용으로 가르치는 게 아니다. 그나저나 파이썬 강의는 도처에 널렸으므로 적당한 것 하나 골라잡고, 따라하다보면 일단 코더 타이틀은 획득할 수 있다. 사실 미국에서 진짜 입문용으로 가르치는 것은 스크래치라는 언어인데, 이거는 자료가 너무 없기 때문에 추천하기 어렵다. 그리고 스크래치 언어의 설계 목적은 철저히 교육용이다. 실용적인 프로그램을 이걸로 만들겠다는 건 레고 블럭으로 진짜 사람이 들어가 살 집을 지어보겠다는 것과 마찬가지다.
경험담이지만 Python부터 배우고 C++로 넘어가려하니 어려워서 못넘어가겠다...

다만 이건 '프로그래밍'이라는 관점에서 Python을 먼저 배우는게 좋다는 이야기이지, 컴퓨터공학을 배울때 Python으로 입문하는게 짱이다는 이야기는 아니다. 컴퓨터공학 커리큘럼에서 C를 먼저 배우는 이유는, 하드웨어 제어 등 전체적인 '컴퓨터 공학 개론'에 C가 적합하기 때문이다. 특히 유닉스 시스템 콜은 C를 모르면 학습 자체가 불가능하다. 당장 현업에서 써먹을만한 프로그래머를 육성하려면 Java와 Python부터 가르치는게 짱이라는건 교수들도 잘 안다.

80~90년생 프로그래머는 BASIC부터 시작했을 가능성이 높은데, 21세기의 Basic이라고 할 만한 것이 바로 Python이다. 베이직과 달리 파이썬은 매우 고성능이기 때문에 입문 이후에도 주력으로 사용할 수 있는 특징이 있다. 문법 자체도 영어로 글쓰듯이 만들어져 있어 접근성이 굉장히 높다. 영미권에서 먼저 배우는 이유가 그만큼 친숙한 영어를 기반으로 되어있기 때문. 참고로 위에서 C와 Java를 생까라고 했는데 그 이유를 설명하자면, C언어는 원래 태생이 기계 제어 언어, 다시 말해 OS (운영체제)를 만들기 위해 개발된 언어이기 때문에 배우려는 사람이 이미 컴퓨터 아키텍처에 대해서는 잘 알고 있다고 가정하고 들어가기 때문이다. 그리고 자바는 아무래도 타이핑해야 할 양이 너무 많아서 오타 교정하다가 힘 다 빠진다.

다만 Python으로 입문하는 것이 무조건 좋은 것 만은 아니다. C++이나 C로 입문한 사람들이 이를 아니꼽게 보는 것이 아주 틀린 것은 아닌 것이 포인터에 대한 개념을 제대로 학습하지 못하고 넘어가면 프로그래밍을 하는데 핵심적인 개념들, 포인터, Call by Reference나 Call by Value 등에 대한 이해를 모호하게 하고 넘어갈 수 있으며, 파이썬 자체가 워낙 오픈소스와 튜토리얼에 기반하여 배우게 되는 언어다 보니 스스로 버그를 교정하고 원인을 분석하는 자세가 잡히기 힘들기도 하다. 쉽게 말해서 문제를 스스로 해결하려 들지 않고 별 생각 없이 질문 게시판에 툭 던져서 누가 대신 해결해주기 바라는 잘못된 마음가짐을 가질 수 있다는 것.

문제는 한국 대학 교육 현실상, 명문대 컴공 조차 교수들이 비주얼 스튜디오 2010을 위시한 구세대 표준을 강요하는 곳이 매우 많다는 것. 심한 곳은 아예 DOS시절에나 사용하던, 그래서 현대에는 사용하지도 않을 뿐더러 심지어 금지하는 기법을 가르치는 경우도 있다. 이렇게 되면 구세대적인 트릭과 패턴을 위주로 학습할 수 밖에 없게 되고, 직관적으로 이해되지 못하는 트릭은 '원래 그렇다'는 식으로 강요하게 되는데 이런 환경에서는 컴공생들이 흥미를 잃기 쉽다. 실전에 들어가서도 문제인데 현대의 고성능 CPU 아키텍처를 엿먹이는 이들 트릭들을 남발하면 차라리 대충 배운 코더가 짠 코드만도 못한, 저성능에 보안 결함을 안고 있고 디버깅도 어려운 쓰레기를 만들게 된다. 차라리 컴파일러가 어느 순간에 빡쳐서 Deprecated 에러 메시지를 날리면서 컴파일을 거부해 버리는 게 나을 지경.

즉 파이썬을 추천하는 것은 이런 상황 속에서 지속적으로 프로그래밍에 대한 흥미를 고취시킬 수 있는 수단으로서의 영향도 큰 것이다. 기초가 중요한 건 부정할 수 없는 사실이지만 헬로월드도 버거워서 쩔쩔매는 학부생한테 OS의 기초이론부터 차근차근 공부시켜 헬로월드를 찍게 하겠다는 발상은 잘못돼도 크게 잘못된 것이다. 이건 마치 레이서 지망생에게 시작부터 F1경주차를 태워서 타이어 매니지먼트니 슬립스트림이니 하면서 떠들어대는 것과 다를 게 없다. 일단 바퀴는 굴려보고 나서야 차를 계속 몰지 딴 일을 할지를 고민해볼 게 아닌가.

파이썬을 입문으로 추천하는 것에 대해 일부 꼰대 개발자들의 덮어놓기 식 비난은 걸러 들을 필요가 있지만, 끈기가 있다면 모던 C++이나 C# 을 통해 입문하는 방법도 있다. 자바의 경우는 최근 (사용 층이) 보수적이며 밀려나는 언어란 시점도 있고, 아무래도 구세대 C++/C 이상으로 자바 그 자체에 대한 끝없는 공부 가능성이 있어 지치기 쉬우므로 입문으로서는 추천하지 않는 편이다.

Python이 본인 스타일과 안 맞으면 Ruby로 시작해도 좋다. C언어로 언젠간 전향해야 하는 사람이라면 Go언어가 좋다. 두 언어가 성질이 매우 비슷하기 때문이다. 하지만 C++은 절대 시작 언어로 선택해선 안 된다! 학교에서 1학년 객체 지향 프로그래밍 과목으로 C++을 강요해서 어쩔 수 없이 배우는 경우가 많지만 C++언어는 현대에 쓰이는 수많은 프로그래밍 언어 중 코딩 난이도가 최상위권에 있다. 어셈블리어와 자웅을 겨룰 정도. 동의를 못 하겠다면 C++의 iostream 헤더 파일을 열어봐라. 코드를 암호화해놓은 것 같겠지만 그거 분명히 C++코드다. 그 다음에 Go언어 컴파일러 소스 코드를 열어보면 코딩 난이도의 차이가 확 느껴질 것이다. 세상에서 가장 복잡한 프로그램이라는 컴파일러의 Go 언어 버전하고, 그냥 단순히 데이터 입출력만을 처리하는 iostream 헤더 코드(소스 코드도 아니고 그냥 선언문)의 C++ 언어 버전의 코드 가독성 차이는 넘사벽이라는 말로도 표현을 못 할 정도로 크다. 물론 시작언어로 쓰지 말란 얘기지 주력언어로 쓰지 말란 얘기는 아니다. 2016년 현재까지 C++로 만들어진 대형 프로젝트의 수는 무척 많으며 신규 프로젝트가 C++로 시작되는 경우도 아직 많다. 그리고 언어가 어렵다는거지 성능이 모자라는 게 아닌데다가 현대적인 코딩 스타일을 익혀 최신 방식으로 코딩하면 가독성 문제도 상당 부분 완화된다.

파이썬을 어느 정도 익히고 대강 구구클래스 구구단 프로그램 정도는 스스로 만들 줄 알게 됐으면 이제 컴퓨터공학 기초를 닦기 시작한다. 바로 자료구조와 알고리즘을 공부하란 소리다. 컴퓨터공학 대학교 과정 1학년때 가르치는 그 과목 맞다. 자료구조와 알고리즘을 제대로 공부하지 못하면 평생 양산형 개발자(코더)로 남을 수밖에 없다. 그런데 사실 자료구조와 알고리즘을 마스터 하게 된다면 프로그래머의 최정점에 서게 되는 셈이므로, 마스터할때까지 공부하려고 할 것 까지는 없고, 기본적인 정렬 알고리즘이나 탐색 알고리즘, 다익스트라 알고리즘 등 대학 1학년 과정의 기초 알고리즘까지 익히고, 다음 단계로 넘어가도 된다.

다음으로 이제 자신이 어떤 분야에서 활동하고 싶은가에 따라서, 사용할 언어를 선택해서 공부하면 된다.. 웹 프로그래머라면 보통 자바스크립트를 주력으로 삼게 될 테고, 시스템 프로그래머라면 보통 C++언어를 주력으로 삼게 될 것이다. 각 분야마다 선호가 되는 언어는 각각 다르다. 해당 언어와 함께 구글검색을 연습하면 좋다. 정말 어지간한 질문은 구글에 검색하면 답이 다 나오기 때문이다. 그냥 에러메시지를 긁어다 구글 검색창에 붙여넣기만 해도 스택오버플로우 사이트에 해법 올라온 걸 검색할 수 있다. 한편 네이버의 경우에는 안타깝게도 구글과 달리 반대로 어지간한 질문에도 의미없는 답변만 줄줄 달려 있는 것을 확인할 수 있을 것이다. 이제부터 영어를 열심히 공부해야 한다. 하지만 생활영어가 아니라 공학영어이므로 토익 점수하고는 별 관계가 없고, 그냥 소스코드를 읽을 수 있는 정도의 영어실력이면 충분하다. 사실 공학영어만 필요하면 따로 영어학원에 등록해서 수강할 필요까지는 없고 그냥 영어사전만 끼고 있어도 충분하다. 극단적으로 말해, 영어 문법을 전혀 몰라도 명사와 동사만 사전 찾아서 뜻을 찾다 보면 비록 시간은 오래 걸리지만 코드의 모든 문장을 완전히 이해할 수 있다. 기초 알고리즘을 표현한 함수의 경우에는 애초에 변수 이름이 알파벳 한 글자로 이루어진 게 많아서 사전조차 찾아볼 필요가 없고 사칙연산만 할 줄 알면 전체 코드를 이해할 수 있다.

프로그래밍 언어는 프로그래머의 도구일 뿐이지만, 각 언어마다 장단점이 있고, 시장의 수요에 따라 특정 언어를 할 줄 알면 몸값이 올라가는 경우가 있기 때문에 다양한 언어를 다룰 줄 아는 것이 여러가지로 좋고 또 중요하다. 각 언어들은 각자의 쓰임이 있기 때문에 무턱대고 어떤 언어가 좋고 나쁘다를 따지는 것은 매우 어리석은 짓이다. 만약 언어들의 절대적인 우열이 존재한다면 프로그래밍 언어는 하나로 통일됐을 것이다.

어느 정도 실전에 사용할 만한 코드를 짤 수 있게 되었다면, 이제부터는 슬슬 고급 기술을 연마할 차례다. 각 언어마다 디자인 패턴이라는 일종의 설계 지침서가 있는데, 이런 패턴들을 학습하고 전문용어를 익혀 고급 개발자와의 커뮤니케이션(쉽게 말해 의사소통)이 원활해지도록 노력해야 한다.

디자인 패턴까지 공부했는가? 그러면 축하한다. 당신은 이미 프로그래머다. 이제부터 여러분은 스스로 나아갈 수 있을 것이다. 이제 GitHub라는 프로그래머의 성지로 성지순례를 떠나자. 거기서 깨달음을 얻고 자신의 나아갈 길을 발견할 수 있을 것이다. 위에서 설명한 GitHub만 잘 돌아다니면서 쓸만한 정보들을 수집하고, "stackoverflow"사이트만 잘 이용하더라도 혼자 힘으로도 고수가 될 수 있다.

5.1 필요한 장비

5.1.1 데스크탑

참고로 리눅스를 가까이하고 윈도우를 멀리하면 프로그래머로서의 삶이 좀 더 편해진다. 물론 윈도우 환경에서 사용할 수 있는 끝판왕급 개발 도구인 비주얼 스튜디오라는 게 있긴 하다. 그럼에도 불구하고 리눅스를 추천하는 이유는 리눅스쪽이 CLI환경 기준이라 답변 달리는 게 커맨드 명령 같은 간단한 거라 답변의 양에서 압도적이기 때문. 게임 프로그래머가 되고 싶은 사람도 주력 개발은 윈도우에서 할지언정 일단 리눅스 환경은 경험해보는 게 좋다. 편리한 줄 모르면 불편한 줄도 모른다.

근데 리눅스만 깔아놓으면 일상생활이 몹시 불편해지기 때문에 아니야 코딩덕후는 리눅스가 더 편하다구프로그래머가 되고자 한다면 그냥 컴퓨터 두 대를 사서 각각 윈도우와 리눅스를 깔아놓는 걸 추천한다. 버츄얼박스 같은 가상화는 추천하지 않는다. 리눅스 호스트에 윈도우를 버츄얼로 띄우면 게임 따윈 꿈도 꿀 수 없고 윈도우 호스트에 리눅스를 버츄얼로 띄우면 하드웨어 접근 제한 때문에 엄한 데서 삽질을 할 수 있다. 물론 초보 프로그래머가 하드웨어를 컨트롤할 일은 거의 없으니 윈도우 호스트에 리눅스 버츄얼 정도는 중급 프로그래머가 되기 전까지는 괜찮다. 듀얼부팅? 하지마라. 장담하건데 듀얼부팅 환경을 꾸며놓으면 얼마 안가서 리눅스는 절대 안 쓰고 윈도우만 쓰게 된다.

컴퓨터 두 대 사는 게 아무래도 부담이 되면, 리눅스용 컴퓨터는 본체만 어디 재활용센터나 중고시장 같은데서 주워오고, 거기에 서버용 리눅스를 깐 뒤에 SSH(PuTTY등)로 원격 접속해서 사용하는 방법을 추천한다. 10만원 정도면 PC방에서 배출되는 중고컴 정도는 구입할 수 있다. 전기료는 하루종일 켜놓는 게 아닌 한에야 별로 차이 안 난다. 리눅스컴도 전기 먹을만한 작업을 안 하고 윈도우컴도 전기먹을만한 작업을 안 하니까. 게임 하나 돌리고 있는 컴퓨터가 저거 두 대분보다 더 많은 전기를 소모한다.

맥북프로나 맥프로 (mac os x가 탑재 되어 있는 애플 컴퓨터)도 프로그래머용으로는 좋은 선택이다. 가격이 비싼 건 단점이지만 XCode등의 좋은 소프트웨어를 무료로 사용할 수 있다. 복돌이는 그냥 맥이 비싸다고만 생각할 수 있지만 윈도우 환경에서 대학생 할인 혜택 없이 개발환경을 풀 세팅하려면 소프트웨어 가격만 백만원 정도를 각오해야 하는 만큼 개발 머신으로서는 비싸다고 볼 수 없다. 기본적으로 맥 OSX가 유닉스 계열이라 리눅스 공부하는 시간을 아낄 수 있고 전반적인 튜닝이 잘 돼 있어 잔손질이 가지 않는다. 특히 휴먼 인터페이스 분야에서는 애플이 선두를 달리고 있으므로 멀티터치나 포스 클릭 등의 미래지향적 인터페이스를 개발해볼 수 있다. 선택은 각자의 몫.

5.1.2 서버

아예 공짜를 원한다면 좋은 방법이 있다. 아마존 웹 서비스를 사용하는 것이다. EC2인스턴스의 t2.micro 인스턴스는 가입 후 1년간 무료로 사용할 수 있다. 1년 지나면 계정을 지우고 다른 신용카드를 붙이는 방법으로 계속 사용할 수도 있다. micro인스턴스라도 어지간한 프로그램은 충분히 컴파일할 수 있다. 심지어 웹 서버에 데이터베이스 서버를 덕지덕지 붙여도 혼자 쓸 목적으로는 충분한 성능을 낸다. 돈 내고 쓰겠다고 해도 예약인스턴스를 구매하면 t2.nano급(가장 싼 인스턴스)의 1년 자유이용권(All upfront) 가격이 40달러 선이다. 시간당 비용은 0.0065달러이므로 하루에 다섯 시간씩 매일 사용하는 경우에도 1년내내 20달러도 안 나온다.

단, 본인이 덜렁이 기질이 있거나 보안의 '보'자도 모르는 생초보라면 아마존 웹 서비스는 사용해서는 안된다. 위의 각주에도 언급돼있지만 앗 하는 사이에 돈십만원 빠져나가는 건 우습다. 이건 후불요금이기 때문에 환불도 안 된다. 보안을 철저히 챙길 자신이 없다면 클라우드 컴퓨팅에는 손대지 말자.

5.1.3 모니터

그리고 중수 이상의 프로그래머라면 가급적 초고해상도 모니터와 좋은 키보드를 갖추는 것이 권장된다. 왜냐하면 하나의 화면에 몇 줄의 코드가 보여지는지가 생산성에 많은 영향을 미치기 때문이다. 보통 코딩창, 빌드창, 로그창, 레퍼런스 웹 브라우저, 퍼포먼스 모니터 등 10개 이상의 창을 동시에 들여다봐야 할 상황이 잦은데 이 모든 창들이 다 텍스트를 출력하므로 고해상도 모니터가 필요한 것이다.

그리고 모니터를 뚫어지게 쳐다보는 특성상 시력이 안좋아지다보니 폰트는 가급적으로 키우는데 모니터 사이즈가 받쳐줘야 하기 때문. 보통 2560x1440 해상도의 IPS패널 또는 MVA패널 모니터를 사용하며 일부 프로그래머는 이 모니터를 세로로 돌려서 1440x2560으로 세팅해 사용한다. 이렇게 둘 경우 한 화면에 200줄 넘는 코드를 출력할 수 있다. 서브라임 텍스트 기준으로 메뉴바, 타이틀바, 툴바 등이 차지하는 공간을 제하고도 기본 설정에서 순수 코드창만 160줄의 코드가 한 화면에 보인다. 참고로 시중에서 적절한 가격대에 구할 수 있는 모니터 중에서는 3840x2160모니터가 가장 고해상도이다. 화면 주사율이나 색공간 따위는 고려 대상이 아니므로 144Hz니 AdobeRGB지원이니 광색역이니 이딴 건 필요없다. 하지만 TN패널 모니터는 대형 모니터에서 왜곡을 일으켜 주변부의 글자가 안 보이는 대참사가 일어나므로 피해야 한다. 그리고 듀얼 모니터도 큰 도움이 된다. 레퍼런스창(웹 브라우저)과 코딩창을 전환하지 않고 한 눈에 볼 수 있는 장점이 있다.

그리고 레티나 디스플레이는 디자이너를 위한 모니터이지 프로그래머를 위한 모니터는 아니다. 폰트가 더 이쁘게 출력되는 게 프로그래머에게 무슨 소용이란 말인가. 그렇다고 폰트 DPI를 일반 모니터와 똑같이 맞추자니 글자가 농담이 아니라 정말로 깨알 크기로 작아지는데 이런 환경에서 코딩할 수는 없다. 프로그래머에게 딱히 해가 되는 모니터는 아니지만 큰 이득을 주는 것도 아니므로 굳이 레티나 디스플레이를 고집할 필요는 없다. 그냥 있으면 좋다. 있으면...

모니터 배경색은 가급적 단색의 어두운 색을 선택하고 코딩창도 다크 테마로 해서 작업하는게 눈 건강에 좋다. 흰 배경은 눈을 많이 피로하게 한다. 폰트도 나눔고딕코딩 등의 가독성 위주의 폰트로 세팅한다.

5.1.4 키보드

키보드를 쳐야 하는 일이 아주 많으니 기계식 키보드와 같은 고급품을 구입해서 쓰는 것이 좋다. 키감도 키감이지만 본인의 손가락 건강에 영향을 준다. 나이먹어서 강제로 독수리 타법으로 코딩하고 싶은 게 아니라면 키보드에 투자하는 게 좋다. 다시 말해, 전문가에겐 전문적인 장비가 필요한 법이다. 대신 그래픽 카드나 CPU같은 건 좀 하급이어도 큰 문제가 되지 않는다. 개발할 때 본체 쪽 스펙은 좀 떨어져도 상관없다. 고급 프로그래머가 되면 빌드 머신을 따로 구성할 정도로 전문적으로 작업하게 되겠지만, 이미 거기까지 도달한 프로그래머는 자신에게 필요한 환경이 무엇인지 잘 알고 있을 것이다.

5.2 한 가지 언어만으로는 부족하다

첫번째 언어에서 디자인 패턴을 공부할 수준까지 가면, 틈나는 대로 다른 언어들도 공부하는 것이 좋다. 달랑 한 두개의 언어만 붙잡고 있으면, 그리고 그 외의 언어에 대한 지식습득을 외면한다면 어느 순간 도태될 수도 있다. 현실의 외국어와 달리 프로그래밍 언어는 문법이나 용어들이 다 비슷비슷하므로 습득하는데 큰 노력이 들지 않는다. 다른 언어들까지 잘 사용할 능력을 갖출 필요까지는 없고, 그냥 간단한 프로그램 만들 정도만 익히면 충분하다. 나중에 그 언어를 주력으로 사용하게 될 때, 나머지 상세한 부분을 공부해도 늦지 않다.

독학 학습 과정에서 일종의 종교적 신념(?) 같은 것들이 생겨나, 중수에 머무르는 프로그래머도 상당히 많다. 예를 들어 C++ 언어가 만능 언어라는 신념 등. 만능 언어가 맞긴 맞는데 만능기판과 PCB의 차이와 같은 것이다. 만능기판이 만능이긴 하지. 그런데 왜 사람들은 PCB를 굳이 제조해서 쓸까? 한 번 잘 생각해보기 바란다. 이러한 자신만의 독단적 신념에 빠져드는 것을 방지하고 예방하기 위해서는 전 세계 개발자의 트렌드를 예의주시하고 있어야 한다.

물론, 트렌드를 지속적으로 팔로우하는 건 어렵다. 라이브러리나 프레임워크를 뺀 순수 '언어'들만 해도 200여 종이 넘는다. 점유율 1.5%넘는 것들만 쳐도 20여종이 남는다. 그 중에서 다음 프로젝트에 무슨 언어가 쓰일 지는 확정지을 수 없다. '나는 게임 개발자니까 다음에도 당연히 C++이겠지?' 했다가 갑자기 파이썬 스크립트 뭉치가 툭 던져질 수도 있는 동네가 이 동네다. 당장 아이폰 앱 쪽을 봐라. '오브젝티브-C만으로도 충분하겠지?' 했는데, 어느날 갑자기 애플에서 Swift를 발표하지 않았는가...

그러므로 진정 고수가 되고 싶다면 한 언어만을 맹신하지 말고 다른 언어를 접해보자. 대표적으로 Go언어는 C언어가 할 수 있는 일은 죄다 할 수 있으면서도, 컴파일이 빠르고 코딩은 쉽다. Python은 C보다 할 수 있는 일들이 적지만, 워낙 쓰기 편한 까닭에 주류 언어의 지위를 차지하고 있다. Erlang이란 언어는 원래 통신장비에 들어갈 목적으로 설계된 언어인 탓에 동시접속자가 폭주해도 굳건히 버텨낸다.

한번 예를 들어보자. Java라는 한 우물만 계속해서 파게 될 경우, 처음엔 날코딩에서 시작해 IDE를 쓰게 되고, 써드파티 라이브러리를 사용하다가 스프링 프레임워크라는 것이 있다는 걸 알게 되고, 프레임워크의 유연성에 감동의 눈물을 흘리다가, 그 프레임워크를 만든 근간 기술인 디자인 패턴에 대해 공부하게 되고... 그렇게 차츰 자기도 모르게 고급 프로그래머가 되어 간다. 사실 이런 식으로 한 우물만 파더라도 고연봉을 받을 수는 있다. 왜냐하면 아직도 자바는 프로그래밍 언어 인기순위 2이기 때문이다. 하지만 그놈의 학습량이 문제다. 위에서 트렌드를 지속적으로 팔로우해야 한다고 했는데, 자바 쪽의 트렌드는 따라가려면 읽을 양이 엄청나게 많다. 그래서 다른 것에 한눈 팔 여유가 없다. 그런데 현재 자바 언어는 입지가 상당히 위험한 상태다. 구글과 오라클 간에 소송도 걸려 있고, 다른 경쟁 언어들이 더 강력하고 편리한 신기술로 무장하고 있는데다가, 언어 스펙의 발전이 오랜 기간 정체해 있었다. 코볼언어가 그랬듯 금융권이라는 보수적인 곳에서 자바를 쓰기 때문에 하루 아침에 몰락하고 그러진 않겠지만 일자리 자체가 줄어들어 취업문이 좁아지는 건 어쩔 수 없다. 그런데 최신 트렌드에 민감하게 반응하고 있었다면, 스프링 프레임워크를 접할 때 즈음엔 함수형 언어라는 게 있다는 사실을 어떻게든 주워들을 확률이 높다. "내 사랑 자바를 왜 까고 그래요?" 하고 대들면 뭔 일급 객체니, 클로저니... 하면서 사람을 열받게 하는데 당장 자리로 돌아가서 구글신에게 물어보면 뭔가 심상치 않은 분위기를 느낄 것이다. 그리고 10분 뒤, 당신은 멘붕을 경험할 것이다. "인터페이스가 불필요하다니!" 거기서 끝나지 않는다. 메서드 체이닝과 고차 함수 개념을 접하고 나면 객체를 상속하듯이 행동을 확장할 수 있는 함수형 언어의 설계 패러다임을 접하고 문화충격과 더불어 뇌 개조를 당하게 된다. 객체지향이 세상의 진리인 줄 믿었건만 또 다른 세계가 존재했던 것. 그리고 멀티스레드는 금단의 사과 같은 테크닉이라고 믿었던 자신에게 스레드가 다다익선이라고 가르치는 GPGPU세계도 잠시 스쳐지나갈 수 있다. 리턴값을 두 개 세 개 막 넘길 수 있는 Python과 Go를 보고, 숫자에 메소드를 붙이고 문자열 자체를 메소드명으로 해석해서 실행시키는 괴랄한 테크닉이 가능한 Ruby를 보고, 심지어 같은 자바가상머신을 사용하는데도 유연성이 훨씬 뛰어난 Scala와 Groovy를 접해보게 된다. 그런 세계여행(?)을 하고 돌아와서도 순수주의자처럼 자바 하나만으로 코딩하고 싶지는 않을 것이다. 심지어 남들이 헷갈리니까 언어는 하나로 통일하라고 말해도 싫을 것이다.

저 과정 전체에 대한 퀵 투어를 원하는가? 프로그래밍 언어/코드 예제항목에 가 보자. "Hello, World!"는 그렇다치고 그 아래쪽 것들을 구경해볼것. 열 줄짜리 구구단 출력 자바 코드가 Ruby언어에 가면 어디까지 줄어드는지 한 번 보자.

위에서 자바를 너무 심하게 깠는데, 사실 C++프로그래머가 자바 세계로 넘어와도 비슷한 문화충격을 받을 수 있다. '아니 왜 포인터가 없지? 그러고도 프로그램이 돌아가나?', 'new는 있고 delete가 없다니, 코딩 개판이네', '연산자 오버로딩이 안돼? 다중상속도 안돼? 성능도 느리다고? 머신제어도 불가능? 장난감이구만...' 하고 있다가 크게 데이는 경우도 더러 있다. 또는 웹 개발자이긴 한데 IoT 디바이스 분야라서 PHP를 아두이노와 통신시키려고 별의 별 모듈을 덕지덕지 붙이다가 그냥 C언어를 이용하여 함수 호출 한 개로 끝내버리게 되는는 신나게 빡도는 경험도 할 수 있다. 하지만 다른 분야를 안 보고 있었다면, 일하는 내내 빡쳐있겠지 인과응보다. 뭐 그러다 최정점에 서게 되면 이거고 저거고 다 비슷해 보이는 언어의 한계를 돌파한 polyglot이 된다 무슨 언어를 쓰든 거기서 거기처럼 느껴질 수도 있겠지만 이 경지까지 가면 스스로 컴파일러를 제작해서 사용할 정도의 초월자가 되어있을 것이라 논외.(...)

5.3 학위의 위상

흔히 프로그래머에게는 학력이 중요하지 않다고, 심지어 대학 교육이 반드시 요구되는 분야가 아니라고들 말을 한다. 반대로 가능한 한 명문 대학과 명문 대학원을 가야 많은 것을 배울 수 있고 취업도 잘 된다는 말을 한다. 이는 상황에 따라 둘 다 맞다.

다음 상황이면 저학력이라도 상관없다.

• 웹,앱 디벨로퍼 처럼 직업학교에서도 배우는 정도의 커리큘럼으로 정리가 되어 있고 복잡한 처리를 필요로 하지 않는 분야
• 자기가 직접 앱 만들어서 팔고 회사 차릴 수 있는 사람.(다만 통계상 학력이 높은 사람이 회사를 차릴수록 수익률이 높고 오래가고 도산률이 낮다.)
• 중소기업이나 인기없는 스타트업 등 쉽게 들어갈 수 있는 직장에 들어가더라도 만족하는 사람. (낮은 대우 받고 계속 다니는 평범한 경우, 그 직장 규모 전체를 키워버리는 특이한 경우, 거기서 쌓은 경력으로 대기업에 이직하려는 경우 셋 다 포함.)
• 학위 없이도 명문대졸들 다 떨쳐내고 구글에 뽑힐만한 능력자.
• 공무원 시험이나 공공기관 시험 치려는 사람.

다음 상황이면 고학력이 반드시 필요하다.

• 수학, 물리학, 컴퓨터공학 등의 지식이 대학교 3학년 이상으로 올라가서 쓰이는 수준의 고급 프로그래밍(소프트웨어,빅데이터,데이터베이스,등등).
• 국내 대기업, 다국적 기업에 경력 없이 입사하고 싶은 사람.
• 해외취업 목표.
• 교수, 정부출연연구소 목표.

프로그래밍 분야에 있어서 학력 = 실력이 아니다. 고가의 실험실습 도구가 필요한 다른 분야와는 다르게 프로그래머에게는 오직 컴퓨터 한 대만 있으면 충분하고, 필요한 관련 지식에 대한 정보는 인터넷의 정보 바다에 흘러 넘친다. 게을러서, 즉 자기가 안 찾아봐서 관련 지식 및 정보를 모르는 경우는 있어도, 찾을 수가 없어서 관련 지식 및 정보를 모르는 경우는 극히 드물다고 할 수 있다. 그리고 일반적인 기업의 일반적인 코딩 및 실무에 필요한 능력만 따진다면, 대학에서 배우는 추상적인 지식들은 사실 쓸모없다.

그러나 아이러니하게도 "한국에서" 고급 지식을 익혀서 고급 엔지니어로 성장하려면 상위권 대학에 진학해야 한다. 한국에서 고급 지식을 효율적으로 얻을 수 있는 곳은 좋은 대학 뿐이다. 현업에 종사한지 2년 내로, 내가 나온 대학이 좋은 대학이었는지 아니었는지 뼈저리게 느끼게 된다. 그리고 앞으로의 20년이 대략 그려지겠지

널리 알려진 사실이지만 한국의 컴퓨터공학/소프트웨어과는 구조적인 문제로 커리큘럼이 낙후되어 있다. 컴퓨터공학과를 진학하게 되는 이유가 이론적 배경을 위해서임을 고려하면 이는 졸업자의 경쟁력에 심각한 마이너스 요소가 된다. 말할 것도 없지만, 미국의 스탠포드나 MIT와 비교했을 때 한국 대학의 커리큘럼을 모두 성실히 따라간다고 해도 기대되는 아웃풋은 처참할 지경. 그나마 세계 랭킹 50위권인 서울대학교나 KAIST에서나 미국의 제대로 된 탄탄한 커리큘럼에 그렇게 많이 꿇리지 않는 교육을 받을 수 있다. 문제는 이 지식이 없으면 고급 엔지니어가 되는데 엄청나게 큰 지장이 있다는 것이다. 이런 지식 은 단순 코더로서 실무 경험을 쌓는다고 해서 배울 수 있는 것도 아니며, 사이버대학 등의 접근성이 높은 대학교에서 깊이있게 배울 수도 없다.

대학원 또한 마찬가지. 애초에 중요한 건 대학원을 나왔느냐가 아니라 어떤 대학원에서 어떤 수준의 교육을 받고 어떤 퀄리티의 논문을 냈느냐라는 것을 상기하자. 현실적으로 낙후된 대학 환경에서 그나마 제대로 된 실력을 쌓을 수 있는 대학은 한국에 두세개 뿐이고, 이런 대학원은 들어가기가 상당히 어렵다. 결국 현실적인 문제로 고급 엔지니어가 되고자 한다면 실력이 중요한 IT 분야에서도 굉장히 좋은 교육을 받아야 하기 때문에 좋은 대학을 가는 것은 거의 필수적이다. 만약 자신이 외국 대기업 진출을 노리는 등 고급 엔지니어만이 할 수 있는 일을 하고 싶다면 일단 좋은 대학을 가고 보는 것을 강력하게 추천한다. 인맥, 다양한 기회 등은 덤.

대기업에 입사하고자 할때는 대학 졸업장이 당연히 필요하고, 괜찮은 중견기업에 지원할 때도 필요하다. 설사 SI이나 SM 업무를 하더라도 "갑"에서는 개발자의 학력이나 학벌을 중요시 여기기도 한다. 그리고 대학교 졸업장 없이는 실력이 뛰어나더라도 상대적으로 설계 경험을 접해보기 힘든 경향이 있다. 사실 학력과 실력은 반드시 일치하는 것도 아니고, 이 분야 특성상 학력과 실력이 무관한 경우도 매우 많지만, 이 분야 특성을 잘 모르는 일반인들로서는 사회 통념상 학력이 없으면, '저 사람은 대학도 나오지 않았는데, 당연히 실력도 없을 거야~' 라는 식으로 선입견 내지 편견을 가지기 쉽다. 그래서 그러한 편견을 가진 일반인이 발주를 하는 갑의 위치에 있다면, 실력을 보지도 않고 쉽게 무시하기 일쑤이다. 하여간 한국에서 사회생활 하려면 대학은 나와야 한다 미국도 프로그래머로 취업하려면 보통 대학을 졸업해야 하고, 구글 오라클 등의 대기업에 취업하려면 좋은 학교 출신이 아무래도 유리하다.

아랫 글(4.3.필요한 능력)을 보면 알겠지만, 그 획기적인 알고리즘을 만들어낸다는 교수들이 바로 박사들이다. 또, 알게 모르게 석사학위도 꽤 쳐준다. 구글 검색엔진에 사용된 알고리즘을 고안해낸 래리 페이지가 바로 석사다[즉, 단순히 시간/공간적 절약만 알고리즘의 개선목표가 아니다]. 더붙여, 좋은 지도교수님 밑에서 잘 트레이닝 된 석사가 건성으로 졸업한 박사보다 나을 때도 많다. 끝으로, 교수가 코딩 안하는 이유는 어느정도 급만 되면 코딩할 필요가 없는 것도 있는 한편, 박사과정 학생들이 가져다 주는 획기적인 알고리즘이 타당한지 검증하고 논문 검토하는 데도 바쁘기 때문이기도 하다. 그 와중에 애들도 가르치고, 연구도 따와야 하고, 학내 정치도 해야 되지 않는가.

단, 본인 영어 실력이 좀 된다면 고급 엔지니어가 되기 위한 지식을 대학에 진학하지 않고 익힐 방법이 있긴 있다. Coursera, edx, MITOCW, Udemy 등에서 제공하는 강좌들에서 이런 고급 수학, 물리학 지식을 제공한다. 그리고 git-hub에 가서 MOOC 관련 다운로더 코드를 파이선으로 작성해 놓은 것들이 있는데 다운 받아서 실행하면 강의당 용량이 4G가 정도 하는 패키지로 자막까지 받을 수 있다. 미친듯이 사전 찾아가면서 공부하면 다 이해될 수 있다. (음식은 모두 준비되어 있는데 소화는 알아서 하는 격...)

5.4 다른 분야의 지식

다른 전공지식이 필요한 부분에 대해서는 그 전공지식과 업무에 대한 이해가 필수적이다.

• 건축물 해석 : 건축학 지식
• 3D 그래픽 라이브러리 : 기하광학
• 게임 물리 엔진 : 역학 위주의 게임 물리학

5.5 필요한 능력

300px
야근력

코더든 아니든 간에 일단 프로그래머라고 자부하려면, 최소한 (아주 기초적인 수준이더라도) 여러가지 프로그래밍 언어를 구사할줄 알아야 하며, 직종에 따라 다양한 툴과 엔진을 다룰 줄 알아야 한다. 한편 직접 툴을 다루진 않지만 데이터베이스, 알고리즘, 자료 구조간의 관계/구조를 설계하는 사람을 소프트웨어 설계자(아키텍트)라고 구분하여 부르기도 하는데, 아키텍트는 당연히 관련 분야 지식을 알아야 한다.

5.5.1 꾸준한 공부

그 중에는 프로그래밍 자체에 대한 흥미 및 이 분야의 트렌드를 지속적으로 팔로우하는 능력 및 꾸준한 공부습관도 포함되어 있는데, 이에 대해 부연설명하면 다음과 같다.

내가 하면 프로그래머요, 남이 하면 코더라고 부르기도 할 정도로, 진입장벽이 낮아졌지만, 진입장벽이 낮다고 해서 결코 '쉬운' 직업은 아니다. 툴은 점점 쉬워지고 있지만 그런 툴 자체가 워낙 많이 쏟아지고 있어서 프로그래머는 그 수많은 툴 중에 '선택'을 해야 한다. 라이브러리간 궁합도 따져봐야 되고 개발이 계속 되고 있는지, 얼마나 많은 유저가 쓰고 있는지, 그리고 검증되었는지 여부 등을 다 따져봐야 하게 된 것이다 (그리고 마지막엔 GPL때문에 리젝되겠지...). 1970년대에는 닥치고 C언어를 쓸 수 있었겠지만, 2015년 현재 그렇게 생각없이 도구를 골랐다간 망하기 일쑤다. 고민을 하는 동안에도 세계 어딘가에서는 새로운 툴이 만들어져 발표되고 있고 기존 툴이 대대적인 업그레이드를 해서 원래 후보 탈락이었는데 재검토가 불가피해지는 경우도 발생한다. 정말 안습인 건 1년동안 고생해서 프로그램 하나를 제작했는데 다른 회사에서 신기술을 도입한 더 좋은 프로그램을 일주일만에 출시해버리는 경우도 발생한다. 툴 선택이 잘못돼서 생산성이 떨어진 상태로 작업하는 게 어떤 참사를 불러오는지의 가장 극단적인 사례.

그래서 타 분야에 비해 꾸준히 관련 분야 지식을 공부해야 하는 자세가 요구된다. IT쪽 뉴스에 뭐가 뜨면 최소한 자기 분야는 죄다 챙겨봐야 하니까 말이다. 덕분에 학원출신이라도 이후 독학으로 대학출신을 능가하는것도 가능하며, 대학에서 우수하였더라도 졸업 이후에 자기 분야 지식에 대한 체크를 게을리 한다면, 양산형 프로그래머 수준으로 떨어지는것도 매우 쉽다. 특히나 IT 분야는 발전속도가 매우 빠른 분야이기때문에 공부를 그만두면 순식간에 뒤쳐질수 밖에 없다. 따라서 프로그래머라는 직업을 그만두는 때까지 공부를 게을리 해서는 안된다. 그러므로 어떻게 보면 사실 프로그래머에게 필요한 가장 중요한 적성은 뜬구름 같은 얘기이기도 하지만, 프로그래밍 그 자체에 대한 흥미라고 할 수 있다. 흥미가 있는 사람이라면 누가 시키지 않아도 직접 찾아서 새로운 기술과 관련 정보를 습득할테고, 누가 강요하지 않아도 알아서 공부할 것이기 때문이다. 그와 달리 학교에서처럼 시험같은 것으로 강요하는 사람이 없을 경우 스스로 공부를 하지 않는 케이스라면, 학교를 졸업하고 난 이후에는 공부에 소홀 할수 밖에 없을 것이고, 그렇게 되면 다른 사람들에 비해 실력이 뒤쳐질 수 밖에 없을 것이다.

또한, 컴퓨터 분야의 발전과 변화가 엄청나게 빠르기 때문에 어제의 상식이 구시대의 유물로 변하는 것은 금방이다. 이를 계속 따라잡으려면 새로운 지식을 받아들이는 것을 게을리해서는 안 되고, 그렇지 못하면 도태될 수밖에 없기에 프로그래머라는 직업을 계속하기 위해서는 많은 노력이 필요하다.

이렇게 트렌트 파악 및 꾸준한 공부가 필요한 분야이기 때문에 한편으로 프로그래머집단은 동종업계 종사자들 사이에서 지식 공유가 활발한 분야이기도 하다. 예를 들어, 위키위키는 프로그래밍에 쓰는 패턴들을 정리하기 위해서 처음 탄생했다. 또한, 모르는 사람들이 모여서 상업적인 목적으로 만든 것보다 쓸만한 물건을 만들어 내는 오픈 소스 프로젝트는 활발한 지식 공유 없이는 유지될 수가 없다.

대부분의 대학교 컴퓨공학과 교수들이 본인은 절대 코딩 안 하는 이유가 다른 게 아니라 이 트렌드를 못 따라가서다. 연구분야가 툴 그자체에 있는 게 아닌 한에야 교수들이 툴에 관심가져야 할 이유도 없고. 다른 분야 교수들(기계과 등)이 대학원생과 일대일 맞다이를 떠도 꿇릴 게 없는 반면 컴공과 교수들이 프로젝트 하나를 추진하려면 대학원생이 반드시 몇 명씩 필요한 이유도 이것 때문이다. 물론 코딩덕후출신 교수들도 있긴 한데 전체적인 모양새가 그렇다는 것이다.

5.5.2 컴공과 교수들이 하는 일

일반 프로그래머들이 코드 실행 속도를 0.1초, 0.001초를 줄이는 데 진땀빼는 동안, 거창한 알고리즘 연구자인 컴공과 교수들은 그 시간을 절반, 10분의 1하는 식으로 뭉텅이로 줄여버리는 연구를 한다. 공학자라기보다는 수학자에 가깝고 그래서 실세계의 프로그래밍 언어보단 의사 코드를 더 자주 사용한다.

구체적인 예시를 들자면, 일반 프로그래머들은 루프 수행 최적화, 호출 최적화, 인트린식 적용 같은 기법들을 동원해 코드의 수행속도를 빠르게 하려고 한다. 하지만 그렇게 애써서 빠르게 만들고 있는 알고리즘 그 자체가 선택 정렬인 셈이다. 교수들은 아예 정렬 속도의 차원이 다른 퀵 정렬을 연구해서 논문에 발표한다. 해당 교수의 연구실에 있는 대학원생은 이 교수가 개발한 알고리즘(의사 코드)를 실제 수행 가능한 프로그램으로 바꾸는 코더 역할을 수행한다. 비록 이들 대학원생은 효율성이 매우 떨어지는 발적화 코드를 생성하겠지만 알고리즘 자체가 차원이 다르게 빠르기 때문에 선택 정렬보다 압도적으로 빠르게 된다. 그리고 이 알고리즘이 현장의 프로그래머들에게 알려지고, 프로그래머는 새로운 알고리즘을 자신들이 알고 있는 방법으로 최적화한다. 그런 식으로 IT산업이 발전해 나가는 것이다. 교수들이 코딩 못하는 게 무능한 게 아니란 소리다. 심지어 컴공과 교수가 컴맹일 수도 있다. 컴맹도 알고리즘 연구하는데는 별 지장이 없다.

5.5.3 영어

코더를 넘어서서 제대로 대접받는 프로그래머가 되고 싶다면 영어로 된 기술언어 정도는 읽고 쓸 수 있을 능력을 만들어둘 것을 추천한다. 컴퓨터는 미국에서 만들었고 미국이 리드하고 있으며, 한국어로 된 프로그래밍 정보보다 영어로 된 정보가 압도적으로 많기 때문이다.

그렇지만 본인이 영어 못한다고 좌절하지는 말자. 영어에도 분야에 따라 난이도라는 게 있다. 기술자 영어는 생활영어보다도 더 아랫급인 아주(!) 쉬운 영어다. 어휘 자체가 공학영어는 생활영어보다 훨씬 적고, 3형식을 넘어가는 문장은 거의 쓰이지 않으며 에둘러 표현하는 것 따위는 절대 없다. 또한 문장에 애매모호함 따위는 없고 거의 모든 문장의 의미가 명확하다. 일반인이 들었을 때 왈도체스러운 영어를 구사하게 되니까 거기서 만족하면 곤란하지만 어쨌든 같은 기술자끼리는 말이 통한다. 정 안통하면 코드로 대화할 수도 있다.

6 연봉과 근무

대표적으로 북미의 경우 stackoverflow.com 에서 조사한 2016년 자료에 따르면 평균 $106,120로 연봉이 높은 직업(developer)에 속한다. 다른 나라들도 대부분 높은 편이며 한국도 $48000로 평균 이상은 된다.
연봉은 보유한 기술에 따라 달라지기도 한다. 북미 기준 가장 높은 페이를 받는 기술로는 스파크와 스칼라가 선정되었으며 그 위로 카산드라, F#, Go, Clojure 등이 차례로 선정되었다. 업종에 따라서 구분해도, 상대적으로 접근이 쉬운 웹 프론트 개발자 보다는 아이폰 개발자의 급여가 더 높은것으로 나온다. 링크의 내용은 정확한 통계치가 아니라 설문조사임으로 심각하게 따지지 말고 재미로 보도록 하자.

한국의 경우 프로그래머별 연봉의 편차가 큰편이다. 취업할때부터 이 차이는 시작되는데, 대졸초임 기준으로 중소기업의 경우 적게는 2200부터 시작하는 곳도 있지만 4800으로 시작하는 대기업도 있다. 벌써 2배차이 아쉽게도 신입인 경우 메이저 코딩 대회 입상 경력이 있거나, 유명 오픈소스 커미터가 아닌 이상 대부분 출신대학에 의해 연봉이 결정된다.

경력직의 경우 인사고과에 크게 의존하는 타 직종과는 달리 면접시 간단한 시험을 보는 등 실력 측정이 상대적으로 용이하기때문에 돈만보고 잦은 이직을 하는 사람도 많은편이며, 그만큼 연봉의 편차가 심해진다. 수년전에 올라온 연봉관련글에 다들 의견이 제각각이다 경력직으로 입사한 동료 개발자의 연봉을 알고나서 퇴사를 결심했다는 이야기도 종종 들릴정도. 대기업이나, 괜찮은 중견기업으로의 이직은 추천으로 많이 뽑기때문에 실력은 기본이고 최소한의 인맥 관리도 해두는것이 좋다.

프로그래머의 근무 형태는 일반적인 사무직과 비슷하다. 출근은 사무실로 하지만 FA분야 처럼 직접 기계장비를 제어해야 하는 경우는 공장으로 출근을 해야하는 경우도 있다. 다른 직장과 다른점은 현장에 나가거나 출근을 해야 업무효율이 극대화 되는게 아니라서 재택 근무나 투잡 형식의 알바가 가능하다는것이다. 직종 특성상 신기술 도입에 적극적이다 보니 영어만 통하면 몸은 한국인데 재택근무로 해외에서 일하는것도 불가능하지 않다. 회사에 별로 일이 없는데, 뭔가 매일 열심히 만들고 있는 사람이 있다면 회사 몰래 투잡을 하고 있을 가능성이 있다 SI나 소규모 앱 개발 등에서는 아예 정규직 형태가 아니라 프리랜서 형태로 근무하는 경우도 많다. 비전문가가 본다면 일하는건지 노는건지 구분하기 힘들기때문에 월급루팡하기 좋다.

7 이 속성을 가진 캐릭터

• 나루사와 카즈마 - 탐정학원Q
• 미스터 A - 비밀결사 매의발톱단 THE MOVIE- 나를 사랑한 흑우롱차
• 아이바 아사기 - 스트라이크 더 블러드
• 아카기 리츠코 - 신세기 에반게리온
• 아카사카 류노스케 - 사쿠라장의 애완 그녀
• 오오이시 이즈미 - 아이돌 마스터 신데렐라 걸즈
• 오카 타카오 - 역전재판 시리즈
• 웨일런 파크 - 아웃라스트
• 쿠나기사 토모 - 헛소리 시리즈
• 후지사키 치히로 - 단간론파 시리즈
• 나가토 유키 - 스즈미야 하루히 시리즈
• 마가타 시키 - 모든 것이 F가 된다

8 유사 용어

• 개발자
• 코딩덕후