왜 프로그래머는 계속 공부하는데도 모자른걸까?
프로그래머가 아무리 공부를 해도 쏟아지는 지식을 다 알순 없습니다.
그렇다면 무엇을 배울지 선택을 해야 합니다.
그런데 학계보다는 업계가 분야를 주도하다보니 공격적인 (학계는 좀 수비적이죠) 개발이 이뤄지고 있고
그 아래에 개발자들은 넘쳐나는 정보의 홍수속에 지치는거죠. (혁신이 무조건 좋은 것만은 아니라는...)
프로그래머가 공부한 지식은 1년사이에 50%는 쓸모가 없어지고 나머지 50%는 거의 2년내지는 3년안에 쓸모가 없어집니다.
지식 수명이 짧으니 가급적이면 수명이 긴 지식을 습득하여 밑빠진 독에 물붓는 경우는 만들지 않으면 좀더 도움이 되겠죠? (진짜 제가 이렇게 공부 많이 할줄 알았으면 전 짧고 빡세게 배우고 평생 써먹는 직업을 선택했을겁니다.)
어쨋든 모든 지식을 다 습득할 수 는 없습니다. 무엇을 배워야 할지 선택해 봅시다.~
지식은 두가지로 나눌수 있습니다.
A. 시간이 지날수록 필요 없어지는 지식
B. 시간이 지나도 필요한 지식
A에 관한 지식들은 어떤게 있을까요?
1. 이 회사를 그만두면 필요 없어지는 지식들
-> 한 회사를 죽을때까지 다닌다면 정말 좋겠지만 그럴순 없겠죠? 그런데 그 회사에서만 필요한 지식에만 몰두한다면 이직할때 지식 빈털털이가 됩니다.
ex1) 어떤 분은 유명한 게임 프로젝트에서 수천라인짜리 렌더링 함수에 대해서 잘 알고 있었습니다. 그 함수는 이분만 수정할수 있고 그것에 대해서 이분에게는 자부심이 있었지만 회사를 그만두면서 몽땅 무용지물이 되었습니다.
저런 함수를 잘 알고 있다면 회사내에서 입지는 견고해지지만요...
ex2) Mysql을 많이 쓴다하여 죽어라고 공부했는데 새로운 회사에서는 MongoDB쓴다네요. 또 새로운 회사에서는 CouchBase 쓴다네요?
이건 뭐 공부를 차라리 하지 말아 버릴까 라는 생각도 들고...
2. UI
UI는 변화가 많은 분야이며 OS, 언어, 라이브러리등등에 따라 거의 매 프로젝트마다 새로운 경험을 하기때문에 배우긴 어렵고 배워도 다음 프로젝트에서 쓰지 않을 경우가 많습니다.
UI에는 뭐뭐가 있을까요? WebUI(HTML, JavaScript, CSS, JQuery, 각종 GUI Framework), 각종 OS 기본UI (Windows, Mac, Android, IOS) 그안에 또 델파이 UI, MFC UI, VB UI등등 그리고 3rd Party UI Library등등을 합치면 정말 어마어마한 UI작업들이 있습니다.
근데 UI작업이 쉬운게 아닙니다. 시간도 오래 걸리지요. 사실 UI는 프로그래밍을 제일 잘하는 사람이 해야 하는데 워낙 쓸모 없어질 확률이 높고 노가다성 코드가 많이 때문에 기피되고 있습니다.
불편한 진실이지만 그래서 신입들이 이 분야로 진입되기가 쉽습니다. 나는 하기 싫고 누군가는 시켜야 겠고 신입들은 진입장벽을 넘고 실무자들에게 교육을 받을수 있는 기회를 얻고 서로 윈윈 하는 전략이라고도 생각이 들지만 그 신입이 평생 신입은 아니니 뭐.. 아주 좋은 해결책은 아닌거 같고..
Facebook에서는 프로그래머는 Front-End, Back-End를 같이 짜야 한다는군요. 평등한 규칙이라고 생각합니다.
요리사가 도마, 칼은 자기가 닦아야 하는것과 같은 이치라고 생각합니다.
3. Open source나 3rd party library로 대체되는 지식
예전엔 TCP로 통신 할려면 진짜 프로토콜 만들고 별짓을 다했습니다. TCP로 통신하려면 버퍼링도 해야되고 뭣도 해야 되고 근데 지금은 그냥 라이브러리 많이 쓰는거 하나 골라서 쓰면되요. 근데 이 부분은 좀 애매한게 그렇다고 그 경험이 필요 없느냐. 그럴수도 있고 아닐수도 있습니다. 기본이 중요하다 하지만 사업을 전체적으로 보면 그렇게 중요할까요? 그렇다고 몰라도 트러블슈팅이 가능할까요? ^^ 이건 뭐 답이 있는건 아니죠..
B에 관한 지식은 어떤게 있을까요?
1. 통신
빅데이타처리, 분산처리를 하려면 머신이 자체가 여러대가 있어야 합니다. 그럴려면 통신을 해야 겠지요. 통신 분야는 어디를 가던 요즘 시대에는 반드시 필요하며 다른 매체가 생기기 전까지는 지금과 같은 통신에서 벗어나지 않을겁니다. 예전에는 프로토콜을 설계하기도 하고 네트웍코어를 직접만들어쓰기도 하고 그랬는데 요즘은 그냥 잘 만들어져 있는거 가져다가 씁니다.
어라 A의 3번하고 상충되는 얘기 아닌가? 아니죠? 묘미하게 다르죠...
2. 언어 (C, C++, C#, JAVA, Delphi, VB, PowerBuilder, Python, Ruby, Lua)
언어는 두가지 측면이 있는데 하나는 순수 문법 자체이고 또 하나는 그와 관련된 라이브러리입니다.
C++라고 하면 STL, Boost같은것들 말이죠. 이런것들은 잘 변하지 않습니다. 시간이 지나도 계속 쓸수 있죠.
3. Design Pattern, Refactoring, TDD, UML
이 놈들도 계속 사용되고 있는 놈들입니다.
4. Block, None Block, 동기, 비동기, 멀티스레드, 배타제어
하나의 머신에는 여러개의 프로세스를 실행시킬수 있고 하나의 프로세스에 여러개의 스레드를 만들수 있습니다.
서버 프로그램쪽에서 특히 필요한 지식들입니다.
5. 알고리즘
요즘은 알고리즘 몰라도 그냥 가져다가 쓰면 된다고 하던데.. 일단 알아야 검색도 하겠죠?
6. DB와 NoSQL
말씀 안드려도 되는놈들. NoSQL은 너무 많은게 문제..
7. 설계및 부하분산
이건 NoSQL의 아키텍쳐를 보면 잘 공부가 많이 되더군요.
8. 경험
RFC 문서를 보고 "아! 이렇다면 이런 이런 문제들이 발생할수 있겠군!" 하고 딱 떠오른다면 당신은 천재입니다.
보통은 그렇지 않으니 만들어보고 사용해보고 얻어지는 중요한 경험들(책에선 잘 다루지 않죠)은 언제나 우리의 소중한 양식입니다.
9. 암복호화
여기저기 많이 나오는 얘기입니다. AES, SHA, MD5등등이 유명하죠..
여기까지 보시고 잘 정리가 안되실거 같아서 요약을 하자면
1. 모든 지식을 다 습득할 수는 없다.
2. 가급적이면 수명이 긴 지식을 습득하자
2. 클라이언트 지식보다는 서버 지식이 수명이 길다.
A, B로 분류한 이유는 이게 정답이다 라기 보다는 수명이 짧은, 긴 지식들이 있으니 잘 판단해서 타겟을 정하자 라는 의미입니다. 명확하게 나누기는 사실 애매한 부분이 있습니다. 배우기 싫다고 다 피할수 있는것도 아니구요. 동료들을 배려하지 않고 "나는 이것만 하겠어!" 라는 마인드를 갖어서는 안되겠죠.
다음글은 회사가 어떨때 사람을 뽑으며 사람을 뽑는 사람들의 입장에서 대해서 적어보려 합니다.
아마 다음글이 제가 왜 위 지식을 언급했는지에 대한 이유가 될거 같습니다.
다음 다음글은 위에 나열한 (쓰다보면 추가될수도 있는데..) 수명이 긴 지식들을 익히는데 도움이 되는글을 써보겠습니다.
쓰다보면 책을 만들만큼의 분량이니 모든걸 쓸순 없지만 가장 짧고 가장 도움이 될만한 내용을 써보겠습니다.
글을 쓰고 나면 항상 이게 도움이 되려나... 이렇게 글에 두서가 없는데.. 어쩌지.. 이런 걱정만 드네요..
글을 쓰는건 어렵네요. (이번엔 컬러풀하게 색깔도 넣어보았습니다. 헤헤)
2013.04.21일 추가
계속 Base가 되는 지식을 습득하시다 보면
어느순간 내가 지식을 습득하는 시간이 새로운 지식이 나오는 시간보다 짧아지는걸 느낍니다.
그때까지는 엄청 괴로운거죠. 그런데 그부분만 뚫게 되면
그 담부터는 업무에 들어가는 시간 그리고 자기계발하는 시간을 들이고도 시간이 남습니다.
그 시기가 한 10년차 정도 인거 같습니다.
그 시기가 오면 프로그래밍이 정말 할만 합니다. 잼있어요~