개발자라면 알아야 하는 것들, 읽으면 좋은 글과 조언

좋은 글이라 생각돼서 두고두고 보려고 가져온 글~~

--------------------------------------------------------------------------------------------------------------------------------------

말도 없이 사라진 직군이 있다. 컴퓨터 인공지능과 기계학습이 사람 직업의 몇 퍼센트를 없애고 어쩌고 하는데, 보통 사람들은 눈치채지도 못한 사이에 없어진 직군과 없어져 가는 직군들도 있다.

시스애드민(Sys Admin) 이라고 아시는가. 한때만 해도 전세계적으로 몇백만명이 부족하다는 직업이었다. 리눅스에 LAMP 스택 깔 줄 알거나 윈도 서버에 메일 서버 깔 줄 알고, 전반적인 시스템 관리 할 줄 알고 하는 그런 사람들 말이지. 하드 웨어 관리도 좀 해주고.

요즘엔 시스애드민 자리가 안 난다. 다 데브옵스로 바뀌었다. 데브 옵스 몸값은 천정부지로 솟았지만 시스템 애드민들은 갈 데가 별로 없다. 현재 아주아주 좋은 직장 다니는 시스 애드민 사람들도 쉽게 옮길만한 자리가 없다.

10년 전만 해도 회사마다 전산실이 있거나 컴퓨터 담당 부서가 있었고, 서버 관리하는 사람들이 필요했잖소. 요즘에는 아마존이나 그 외 클라우드 서비스, IaaS, SaaS, PaaS 뭐 등등, 회사 내에 서버 안 쓰고 그걸 아마존이나 마소 애저 등에 외주 주는 식으로 바뀌다 보니까, 아마존의 엔지니어 한 명당 전세계 몇만개의 일자리를 뺏어간 셈이다. 물론 아마존에서는 엔지니어 찾기 힘들다고 우는 소리 하겠지.

몇 년 전만 해도 아마존 AWS 시스템 좀 관리하는 자리가 꽤 많았고 돈도 짭짤했다. 그래서 이전 시스 애드민들이 AWS 로 많이 옮겨갔다. 하지만 AWS 로 옮겨간다는 건 스케일 아웃 컴퓨팅, 클라우드 시스템을 이해하고 관리한다는 건데, 이거 간단하지 않다. 실력 있는 애들은 당연히 살아남았고 연봉도 확 올랐지만 안 그런 애들은 점점 설 자리가 없어져갔다.

남편은 남아공에서도 좀 특이한 케이스로, 네트워크 전문가면서 개발일도 꽤 하는 편이었다. 특화되지 않고 제네럴리스트라 걱정했었는데 다행히 트렌드에 맞아서 데브옵스 직에 딱 맞췄다. 데브옵스 (DevOps) 는 이전 시스애드민의 업업업글 버전으로, 개발팀의 프로덕트를 수만명 수십만명이 쓸 수 있도록 스케일 아웃 하거나, 디플로이 하거나, 그 외 시스템 모니터링을 자동화 하는 일을 한다. 이전에는 회사 서버 몇 개만 걱정하고 필요한대로 깔고 고치고 했을 것을, 이제는 회사 일에 지장 안 주면서 수십 수백 수천개의 서버를 한꺼번에 관리하는 시스템을 만드는 셈이다.

결론은 - 다행히 남편은 이번엔 살아남았다. 다음에는 살아남을까?

난 나름 데이터 사이언티스트인데, 뭘 해야 데이터 사이언티스트가 되냐고 물으면 참 난처하다. 쌩으로 들어오려면 상당히 빡세기 때문이다. 통계학 박사을 기본으로 요구하는 데도 많고 좀 그렇다. 하지만 나처럼 개발 일 하다가 이쪽으로 들어온 애들 보면 -

SQL 도 하고. R 도 하고, 파이썬도 하고, 그냥 개발도 한다. 리눅스 기본은 다 알고, AWS 나 애저 등의 스케일 아웃 기본은 다 안다. 하둡도 알고 하이브도 안다. 뭐 되게 전문적으로 하는 건 아니지만 일 할 만큼은, 모르면 누구한테 어디에 뭘 물어봐야 할 정도는 안다. 통계도 기본은 하고 수학도 선형수학 정도는 한다. 기계학습도 기본적인 건 한다. 자바스크립트도 어느 정도는 하니까 정말 급하면 D3 플롯도 한다 (하기 싫지만). 데이터 프레젠테이션 용 웹 사이트도 만들라면 만든다. 데이터 긁어오는 스크립트도 하라면 한다.

아무리 좋은 학교에서 졸업하고 박사학위 있는 사람이라도 이런 잡다한 거 다 하는 사람은 과반수를 넘지 않는다. 그래서 박사학위 있는 사람들은 기계학습 알고리듬 파는 쪽으로 (의외로 자리가 훨 적다) 가거나, 다행히 개발 경력이 있거나 데이터 분석에 강하면 데이터 애널리스트로 들어가는 건 쉽다. 통계 박사 학위 하나로만 들어가는 건 좀 빡세다. 지금 현재 직장에서 데이터를 좀 다룰줄 아는 사람에게 그 쪽 일 더 시키면서 데이터 사이언티스트 명함을 주는 것은 쉽지만, 정말 작정하고 데이터 사이언티스트를 찾는 회사는 원하는것도 많고 기대도 많고 자기네가 교육할 생각은 없기 때문이다.

그러니까, 뭘 배우면 됩니까 하면, 뭐 이것도 하고 저것도 하고 - 여러사람 고용하던 예전과 달리 한 사람이 이것 저것 다 하니까 그런 사람이 필요하다는 것. 아니 사실은, 지금 있는 자리에서 데이터 관련 일 좀 배우면서 끼어드는 게 제일 쉽다. 보통은 개발일 하던 사람이 데이터 무슨 일이 필요한지 아니까 대강 대강 하고, 테크 회사에는 정통 통계/기계학습 출신 데이터 사이언티스트 소수 (개발력은 좀 약하다), 데이터 분석쪽에서 흘러온 사람 반 정도이다.

SQL 만 죽어라 파던 DB 시절 출신 사람들은 어중간해졌다. 이젠 코딩 할 줄 알아야 한다. DB 튜닝/애드민 하던 사람들은 아마존이 밀고 들어오면서 데브 옵스로 바꾸지 않으면 살아남기 힘들다. 역시 코딩 할 줄 알거나 스케일 아웃 알아야 한다. 데이터 분석만 하던 사람들은 계속적으로 나오는 시각화 툴로 인터랙티브 차트 만들고, 예전에는 그냥 디비에서 SQL 로 데이터 뽑으면 됐을 거를 데이터 프로세싱 하는 것도 배워야 한다. 기계 학습도 좀 배워야 할 거 같고, R 도 배워야 할 것 같고 그렇다.

난 어쨌든 경력 덕분에 이거 저것 했던 가락이 있어서 성공적으로 직함을 데이터 사이언티스트로 바꾸고 지금까진 살아남았다. 다음에는 살아남을까?

어디 가든 사람 없다고 난리다. 개발자도 없고 데브옵스도 없고 데이터 사이언티스트도 없다고 난리다. 하지만 예전처럼 학위 딴다고 취업이 보장되는 시대는 지난지 오래다. 어차피 인사과 통과하려고 학위따고 자격증 따는 건데, 면접 가면 학벌 학점 자격증 다 필요 없다. 실력이다 (면접으로 실력을 얼마나 잘 측정하느냐는 차치하고 ㅡㅡ). 실력 있는 애들은 내가 자괴감 느낄 정도로 많지만, 아직은 내 생계를 걱정 안해도 될만큼 모자란다. 개발도 잘 하는데 통계랑 수학도 잘 아는 애? 많다 (시발). 개발도 잘하고 통계도 잘하는데 무려 프레젠테이션도 잘 하고 시각화도 잘 하는 애? 있다. 개발도 구글 면접 패스 할 정도인데 네트워크랑 시스템도 잘 아는 애? 놀랍게도 많다. 데브옵스 자리 자체가 인력 부족으로 사라져야 할 거 같은데 그런 애들이 또 기어나온다. 그리고 그런 애들이 만든 시스템은 어중간 한 애들 일자리 수십개 수백개를 없애버린다. 능력인이 많지만, 당장 회사에서 필요한 수요만큼은 없기 때문에 나나 남편이 먹고 살고 있는 거다.

지금 컴퓨터 전공하면 취업할 수 있을까?

영어만 잘 한다면, 좋은 대학에서 컴퓨터 전공하면 인사과 통과할 수 있고, 알고리듬 면접 고시공부하듯 하면 들어갈 수 있다. 하지만 당신은 살아남을까? 지금 당장은 억대 연봉에 좋은 대우 받지만, 인력 필터가 한 번 더 돌아가면, 그 때는 당신은 살아남을까?

너무 비관적으로 보일지 모르겠으나 이런 비관적인 태도 때문에 계속 공부하고 업스킬 해서 지금까지 살아남았다만 이젠 버거워서 무섭다. 다음 웨이브가 몰아칠 때 준비되었을까 확신이 안 간다. 데이터 사이언스 붐이 언제까지 갈까. 사물인터넷이 완벽하게 상용화 되고 그에 따른 버티컬 제품군들이 (예: 홈 자동화 데이터 제품, 무인 자동차 데이터 제품) 다 들어서고 더 이상 회사마다 특화된 데이터 파이프라인과 프로세싱이 필요 없어지는게 몇 년 걸릴까. (되면 난 무직). 스케일 아웃 시스템 관리도 완전히 상용화/표준화 되어서 엔지니어들을 고용하지 않고 아마존 서비스 지원 챗으로 해결되는게 몇 년 걸릴까. (되면 남편 무직).

오랜만에 와서 우울한 얘기 해서 죄송합니다 =3=3=3

개발자로서, 몰라도 되지만 그래도 알아야 하는 것들

- 한참전에 썼던 글을 어쩌다가 찾았음

개발자로 취업한다 하면, 특히나 경력직이라면, "이 정도는 알겠지"라고 넘겨짚는 부분이 꽤 많다. 그리고 그걸 모르면 약간 충격 받을 때 있다. 물론 다 자세히 알거라고는 생각 안 한다. 하지만 개발일 하면서 한 번은 해봤을 거고, 아니면 비슷한 걸 해봤고, 다시 하라고 하면 하루 이틀 삽질 해보고 하겠지...라고는 기대한다. 그리고 실제로 내 주위 개발자들은 거의 그렇다.

하지만 돌아보면 지금은 별 거 아닌거 같아도 그 땐 며칠, 몇 주간의 삽질 끝에 배운 것들이고, 짧은 코스로 배웠으면 수십개에 해당할 수도 있겠다 싶다.

중요 순서대로 쓴 건 아니고 그냥 생각나는대로.

# version control system.

요즘엔 github 이 유행이니까 그거 하나만 해도 될 거 같다. 체크아웃 하고, 브랜치 만들고, 체크 인하고, merge 에러 생기면 그거 처리하고, diff 하고 등등. 하나 할 줄 아면 다른 것도 다 한다. 그렇지만! 버전 컨트롤 하나만 써본 사람은 취업 되도, 하나도 안 써본 사람은 안 된다. 개발자로 안 본다.

# 정규식. Regex.

이건 솔직히 문서 작업하는 사람들은 다 배워두면 좋다고 늘 생각한다. 예를 들어 - "철수", "영희", "영수" 라는 문장이 있는데 이것을 

철수, 

영희, 

영수 

요렇게 바꿔야 한다고 하자. 수작업으로 하겠죠? 하지만 그런게 수천 수만개 있으면? 정규식이라고는 할 수도 없는 아주 간단한 방법으로 5초면 바꿀 수 있다. 그 반대도 쉽다. \n 이랑 \r, \t 알아두고, 정규식의 ^ 랑 $ 요거만 알아도 시간 엄청 절약한다. 약간 까다로운 정규식도, 웹 프로그래밍 하면 솔직히 알아야 한다. 이것도 난 절대 안 배울것 같았는데 급할 때 조금조금씩 하니까 배우게 되더라.

# 웹 프로그래밍

사실 잘 할 필요는 없지만, 아무리 백 엔드 전문이라 해도 웹 프로그래밍이랑 전혀 모른척 하고 살 수는 없는지라, 아주 기본적인 MVC 프레임워크 개념은 알아야 한다. 이쁘게는 꾸미지 못할지라도, 백엔드 데이터를 REST API 로 expose 하는 정도는 하루내에 뚝딱 다들 한다. 거기에다가 Twitter 에서 나온 Bootstrap 같은 거 덮어씌우면 의외로 그럴듯한 웹페이지 하나 3-4일만에 만들 수 있다.

# 자바스크립트.

아주 잘 할 필요는 없으나, 그래도 기본적인 컨셉은 알아두면 사는데 편하다. CSS 랑 HTML 은 말할 것도 없다. 그리고 웹 스크립팅 랭귀지 하나쯤은, 아주아주 단순하게는 쓸 수 있음 좋다. Php 라던가, Asp (는 요즘에 좀 갔지만 하여튼). 어떤 언어를 쓰더라도 기존 기술과 비슷하게 나오기 땜에, 난 이전에 Php 랑 Perl template 좀 썼던 것, C# 로 들어오니까 Razr 란 거 뭐 비슷비슷 하더라.

# SQL.

이것도 의외로 쓸 일 많다. 아주 잘 할 필요는 없다. 그래도 select 구문 distinct, group by , order by, union all, inner join 요 정도만 알아도 삶이 무척 쉬워진다.

# 시간, locale. encoding.

초보 개발자와 중견 개발자의 큰 차이중의 하나가, 시간에 대한 개념이 있느냐이다. 지가 미국에 산다고 무조건 시간을 다 EST 에 맞춘다던지 하는 케이스. (UTC 써요 UTC. 내가 런던이라서 시간대가 비슷해서 하는 말은 아니고..) 이럴 땐 나중에 리포트 뽑고 하려면 개판난다. 

아, 영어만 쓰는 프로그래머의 경우 유니코드 개념을 모를수 있겠다. 그리고 시간 formatting/parsing. 시간 포맷이 아주 여러가지인데, 미국식있고 ISO 의 표준이 있고, 프로그래밍 언어마다 조금씩 다르고 뭐 그렇다. 그런 스트링 시간을 parse 하는 것도, 해 보면 별 거 아니지만, 그래도 익숙해지는데엔 꽤 시간 걸렸던 걸로 기억한다. Date 객체가 언어마다 조금씩 다른데, 그것 사용하는 방법은 외우진 못해도 구글로 5초만에 찾을 수 있게 된다. 흠. 그리고 보니 epochmillis 이런 개념도 배우긴 배워야 하는구나. 2015년 2월 1일 이렇게 쓰면 사람이 읽기엔 좋지만, 프로그래밍할 때는 귀찮다. 1970년 1월 1일부터 지금까지의 시간을 초로 바꾼 것을 Epoch seconds 라고 하고, 보통 밀리세컨트 기준으로 epochmillis 로 쓴다. 이건 그냥 숫자기 때문에 더하기 빼기 하기 쉽다. 여기에 더해서 Timespan 이라는 개념도 유용하다.

# linux 에서 bash/shell scripting

인생에 꽤 도움 되는 거 중에 하나가 linux 에서 bash/shell scripting. 뭐 리눅스 애드민 할 것도 아니고 까다로운 건 할 필요 없지만, 그래도 리눅스 시스템에서 간단한 스크립팅 언어 쓰고 프로그램 돌리는 정도는 알면 여러모로 편하다. 난 윈도 시스템은 사실 데스크톱 이외로는 써본 적이 없긴 한데, 윈도 시스템/파워쉘 스크립팅도 리눅스 아는 사람한테는 그리 힘들진 않더라. 난 sed, awk 이런 건 편하게는 못 쓰는데, 그냥 파이썬, 배쉬 스크립팅만 해도 아주 감사한 계기가 많이 생긴다. 투자 시간대비 최고 이득은 단연 vi 에디터.

# 디자인 패턴.

내가 쓰지는 않더라도 그게 뭔지는 알아야 다른 사람들 코드보고 이해가 간다 ㅜㅜ 그냥 간단한 웹 프로그래밍이라고 해도, decorator 이런 거 모르면 이게 도대체 왜 여기있는지 이해가 안 된다고 해야 하나.

# Linear algebra, matrix calculation.

나 고등학교 수학 아프리카 수준으로만 끝내고, 대학교에서는 수학 제대로 안 들었다가 나중에 공부한 부분이다. 이것 역시 그리 어렵지는 않은데, 데이터 처리할 때 벡터 계산 할 수 있으면 훨씬 빨라서 도움된다. 예를 들어 아이템 백개 들어있는 어레이가 있을 때, for loop 으로 하나하나 처리하는 거랑, 벡터 계산으로 한줄짜리로 끝내는 거랑, 아무래도 두번째가 낫겠죠. 예를 들어. df['Either'] = (df.Type== "A") | (df.Type== "B") 요렇게 하면, 수천줄의 데이터 프레임 칼럼 하나가 짧은 한 줄로 뙇!. 아니면 for i in range(len(df['Either']): 뭐 어쩌구 나가야되겠죠.

# Latex/D3 등등, 프레젠테이션이나 문서화 툴.

난 둘다 기초만 배웠지만 기본적인 markup/markdown 몇 개 배워두면 비슷비슷하고, visualisation 툴은 한두개 배워두면 나중에 본전 뽑는다.

# 보안

난 보안 잘 모른다. 그래도 기본적인 컨셉 모르면 피볼 때가 꽤 있다. Certificate 이 뭔지, private/public 키가 뭔지, 그게 어케 돌아가는 건지, sign with a certificate 이 뭔지, 내 컴퓨터에 어떻게 설치하고, 어떻게 개발용 버전 만들 수 있는지, 서버 authentication 은 뭔지 이런 거. Single Sign On 이 뭐고, Kerberos 는 뭐하는 거고, encryption 이 뭔지, http 랑 https 차이가 뭔지, cer/pfx 종류 차이...는 그냥 알아만 두면 좋습니다. 네. 해야 할 때가 오더라고요. 이번주처럼 squint 이모티콘 (서버 expired certificate 왕창 업데해야 하는데 제일 만만한 내가 해야 함 ㅜㅜ)

# 각 데이터 포맷.

XML, Json, CSV/TSV 등등의 파일을 열어서/ 아니면 REST API 로 받아서 parsing 하고, 각 엘레먼트 찾는 방법. 이것 역시 배워보면 별 거 아닌데 상당히 유용하고, 익숙해지면 무지 효율적이다. 개인적으로 내가 세상에서 제일 싫어하는게 XML, XPath 이다.

# 위 아이템과 약간은 비슷한, SerDe operation. Serialize Deserialize.

이거 직접 SerDe 드라이버 쓸 일은 없더라도 (...하이브 SerDe 써보려다가 죽을 뻔한 1인), 뭔지는 알아야 한다. 데이터 주고 받는게 너무 기본이라서;;

음. 생각나는게 이정도라 여기에서 스톱.

꼭 컴퓨터 싸이언스를 해야 하냐, 코딩 학원도 괜찮지 않냐, 뭐 코딩이 그렇게 어려운 것도 아닌데.. 등등의 얘기 듣는다. 맞는 말이다. 하지만 그것은 자신이 소프트웨어 엔지니어링이 필요 없는 환경만 알기 때문이기도 하다.

건축을 예를 들어보자. 누구든지 조금만 배우면 뒷 마당에 헛간 만드는 정도는 할 수 있다. 웬만하면 설명서가 있을 거고, 유튜브 비디오에 별 희한한 튜토리얼이 다 있으니 찾아보면 되겠다. 눈썰미가 있으면 그렇게 간단히 시작했다가 재미 붙여서 이래 저래 잡다한 거 해 보다가 인테리어 고치는 작은 사업을 동네에서 할 수도 있겠다.

그렇지만 당신이라면 이 사람에게 고층 아파트 시공을 맡기겠는가? 아니라고? 왜? 이 사람이 멍청해서? 이 사람을 못 믿어서? 서울대를 안 나와서? 인맥이 없어서?

아뇨. 그걸 떠나서 이건 엔지니어링 문제거든요. 그리고 망하면 문제가 크잖아요. 헛간을 좀 잘못 만들어서 문이 제대로 안 닫기는 것과, 50층짜리 빌딩의 파운데이션이 제대로 안 된 거랑 이건 문제의 스케일이 다르다.

우리 팀에서 지금 처리하는 데이터가 일초에 2백만 리퀘다. 이 규모를 설명하자면.

창구를 만들어서 클레임 데이터를 컴퓨터에 입력한다고 하자. A4 한장을 타이프 쳐서 입력하려면 꽤 오래 걸리겠지. 그렇지만 자동화 시스템을 만들어서, 종이를 넣기만 하면 자동으로 스캔 되어서 에러 없이 데이터베이스에 들어간다고 하자. (보통 한 리퀘스트는 A4 몇장에서 몇십, 몇백장일 수 있지만 그냥 단순화 해서 한 장이라고 치고.)

A4 종이를 계속 계속 입력하고, 그게 컴퓨터 데이터베이스에 들어가는 단순한 시스템인데, 1초에 천 장 정도 처리한다고 하자. 그걸 종이로 쌓으면 약 10 센티 정도 높이다. 그럼 2백만 리퀘는? 에버레스트 반 정도 높이다. 한 시간이면? 지구를 한 바퀴 도는 정도의 높이다. 하루면 지구를 스물 네번 돌만큼의 A4 종이를 처리한다는 얘기다.

그걸 컴퓨터 하나로 안 되지. 몇 천개의 컴퓨터가 동시에 처리한다. 그러면 한 군데에 두면 위험하고, 전세계 데이터센터 x 군데에서 돌아간다. 이럴 때 컴퓨터가 죽을 확률이 0.1% 라고 해도, 천대에 한 대는 죽는다는 말이다. 몇 천 대가 돌아가면 당연히 하루에도 몇 대씩 죽는다. 그러면 그 컴퓨터가 맡았던 일을 다른 컴퓨터에 옮겨야 되고, 데이터를 잃으면 안 된다. 이게 다 자동화 되어야 하고, 전체적인 상황이 어떤지 모니터도 할 수 있어야 한다. 혹시라도 시스템을 업데이트 하면, 내 컴이나 회사 서버 한 에서 돌아가는 프로그램 업데이트하는 거랑, 전세계에 퍼져있는 몇천대/몇만대의 시스템을, 다운타임 전혀 없이 업데이트 하는 것은 차원이 다를 수 밖에 없다.

50층 빌딩을 지을 거면, 건축물의 설계는 알아야 한다. 기초를 어떻게 만들건지 생각을 하고 지어야 한다. 전기 시스템, 물 시스템, 혹시라도 지진이 많은 지형이면 어떻게 대처할 건지, 공기 정화 시스템은 어떻게 할 건지, 엘리베이터는 어떻게 등등 생각할 것이 엄청 많다. 소프트웨어도 마찬가지다. 데이터베이스에 기록한다고 하면 말이 간단하지, 공책으로 비교하면 똑같은 공책에 수백명이 동시에 적으려고 하면 어떻게 처리할 건지, 두 사람이 각각 다른 기록을 넣으면 어떻게 할 건지, 그렇게 적어가면서도 누군가가 그 공책을 보고 싶다고 하면 어떻게 보여줄 건지도 계획해야 한다. 이건 누가 똑똑해서, 혹은 열심히 하겠다고 해서 해결되는 문제가 아니다. 상당히 까다로운 엔지니어링 문제를 이해하고, 해결할 수 있어야 한다. 그래서 소프트웨어 엔지니어링이다. (내가 든 예는 scale 의 문제지만 다른 분야도 엄청 많다.)

이 바닥에서 못 버티겠다고 우는 소리 가끔 하는건 십 년 넘게 동네 건축업자 정도의 수준이었다가 갑자기 무섭게 지어나가는 고층 아파트 시공사에 들어오니까 내가 몰랐던 게 너무 많아서다. 똑똑해서 커버되는 것도 아니고 그냥 열심히 한다고 해서 해결되지도 않는다. 이건 그냥 정석으로 제대로 공부하거나 차근차근 경험 쌓아야 한다. 딱히 이게 작은 규모 건축보다 어렵다는 말도 아니다. 단지 풀어야 하는 문제가 다를뿐이다. 오히려 작은 건축업체의 경우는 여러분야의 경험을 다양하게 쌓을 기회가 많고 큰 시공사일수록 전문성은 늘어나지만 전체적인 경험은 줄어든다. 그래서 젊을 때에는 스타트업에서 일하는 것이 오히려 더 도움이 될 수도 있다. 큰 시공사에서 유리창 설치만 주구창창 하는 것보다 집 하나 전체를 짓는 기회가 주어질 수 있으니까.

기술직에서 학벌 크게 안 본다는 거 사실이다. 그렇지만 일은 할 줄 알아야 한다. 그래서 최고 좋은 지원자는 '이전에 고층 아파트 시공사에서 이런 일을 했고 지금 곧바로 투입 가능합니다' 이다. 누구 이름을 아는게 중요한게 아니라, 실제로 아파트 시공사에서 일하는 사람이 '얘 나랑 같이 일하던 앤데 xyz 할 줄 알아' 말 해 줄 수 있는 게 도움 된다. 좋은 학벌이거나 아주 머리 좋다는 점을 어필하면, 아래부터 차근차근 일 배워올 거면 조금 더 유리할 수 있겠다.

거듭 말하지만 고층 아파트 시공이 뭐 세상에서 제일 대단한 건 당연히 아니고, 엄청 천재들만 건축업계에 있는 것도 아니듯이 소프트웨어쪽도 그렇다. 하지만 어느 업계나 그렇겠지만, 경험 쌓고 알아야 하는 부분이 많다. 그러나 아무래도 눈으로 보이지 않는 부분이라 그런지, 영어 일 년 배우고 영어 동시통역, 피아노 일 년 배우고 피아노 학원하겠다는 사람은 별로 없어도 프로그래밍 배워서 취업...하겠다는 계획은 꽤 자주 듣는다. 불가능한 건 아닌데, 실제 (원하는 수준의) 취업은 그리 쉽지 않다.

"인재를 찾습니다"의 실제 시나리오

1. 록스타 코더, 인재를 찾는다는 이들은 기술적이지 않은 높은 관리직님들이 많다. 너무 높은 레벨이셔서 자기 회사 개발팀에서 무슨 기술을 쓰는지도 잘 모른다. 자신의 판단력을 오버 신뢰한다. 록스타 코더, 똑똑한 사람 뽑으면 알아서 좋은 성과 내겠지 착각한다. Quora 에서 답글 잘 쓰는 사람, 자기가 본 TED 토크 사람을 인재로 보고 영입하려는 미친짓도 한다.

--> "애자일, TDD 는 이제 지났죠. 큰 기업들에서는 요즘 *** 로 큰 성공을 거두고 있습니다. 저 역시 이전 팀에서 *** 메서돌로지로 아주 좋은 효과를 보았기 때문에 이 회사에서도 생산량을 두 배로 올릴 거라 확신합니다. "

이딴 식으로 말하는, 지난 몇 년간 코드 한 줄도 안 쓴 애를 시니어/리드/매니저로 들여와서 반감사게 하고 팀 사기 저하시킨다. (애자일 TDD 가 꼭 좋다는 말은 아니고 ㅋㅋ). 테크 회사에서는 찾기 힘들긴 하지만 가끔식 있다.

2. 개발팀장 위의 사람. 기술력 있는 사람 볼 줄은 알고 일에 대한 이해도 있긴 한데 실적 내서 자기 진급하는게 훨씬 중요하기 때문에 좀 무리가는 채용도 한다. 1번처럼 뜬금없는 케이스는 아니다. 편하게 부릴 수 있는 사람, 자기와 손발이 맞는 사람 들여오려고 한다. 이전 직장에서 자기 팀을 싹 다 몰아오려는 이들도 많다. 정치적인 고려가 앞선다. 금융권 C++ 만 십년 하던 애 데리고 와서 안드로이드 팀 리드로 앉힌다던가 하는 미친 짓도 한다. (그런데 이게 사실 성공할 때도 있다 ㅋㅋ) 객관적인 실력 평가 보다는 자기 판단력을 심히 신뢰한다. 과거의 영광을 재현할 수 있게 신뢰할 수 있는 충성도 만빵 일꾼을 원한다. 외부에서 프린시팔/스태프 레벨 급으로 들어온 사람 중에 자주 보인다.

3. 개발팀장. 일 잘하고 문제 안 일으키고 쓸데없는 걸로 시간 낭비 안 하게 하는 사람이 좋다. 이 사람에게 최악 팀원은 윗 매니저 강력 추천으로 들어와서 고용했더니 "아 이거 Node.js 로 다 다시 쓰면 훨씬 빠를텐데."

됐고. 코드 리뷰나 제대로 하지 그래?

그런데 이런 애들이 꼭 --자기가 좋아하는 언어-- 로 하면 이런 문제 없는데 --현재 팀의 언어--로 해야 하니까 문제가 생기는 거라고 투덜거린다. 됐고. 이번 쿼터 deliverable 뭔지 다시 보고 제발 일이나 하자.

이런 사람들한테 1) *** 스택이 제일 좋은데 그걸로 합시다 하는 인간 2) 왜 (애자일/워터폴/칸반) 안하나요? 로 세시간 토론하려는 인간 3) 애자일을 제대로 하고 있는가에 대해 토론하려는 인간 4) 최근 테크 추세에 대해서 토론하려는 인간들 제일 짜증난다. 일 하자고 일. 자바/C/C++/C# 쉣인거 알고 해스켈/F#/스칼라/그 외 신생 툴이 핫 한거 아는데 닥치고 이번 분기에 가나다 끝내는데 집중좀 하자. 너도 해커뉴스 좀 그만 읽고.

낮은 프린시팔, 높은 시니어, 보통 한 회사에서 몇 년 계속 일한 사람들이 많다.

4. 개발 리드. 팀 내 위치에 따라서 시나리오가 다르지만 3과 비슷하면서 약간 다르다. 윗 분들이 이번 분기에 뭘 해야 하고 뭐 어쩌고 하는 건 좀 관심이 덜 간다. 하지만 제발 좀 유닛 테스트 잘 짜고 순순히 버그 잘 고치고 문서화도 하고 유저 이메일 들어오는 거 처리해주고 빌드 시스템 모니터 해주는 수퍼 신입은 언제 오나 목이 빠진다. 자기보다 더 잘 하는 사람 들어오는 건 좀 위협 된다 (그런 놈 들어오면 이제 내가 유닛 테스트 고치고 피처 대신 버그 고치고 문서화도 해야 하고 유저 이메일도 직접...??!!) 인터뷰가 제일 무난하다. 좀 편하게 살고 싶어하는 욕구가 크다. 미팅 좀 안 했으면 좋겠다. 하루 종일 미팅하고 문서화 하고 윗분들한테 프레젠테이션 하고 나서 저녁시간에 코드 보려니 죽을 맛이다.

5. 초-중급 개발 팀원. 결정권도 없으면서 면접 제일 열심히 들어간다. "객관적 실력 검증"에 제일 열 올리느라 제일 어려운 질문 낸다. 아, 이것도 모른다니 쇼킹이다 이런 소리 제일 많이 한다. 연봉에 큰 관심 있다. 이전 회사 어디에서 뭘 했는지에도 관심 아주 많다. '고수'가 되고 싶어하므로 강호에 어떤 실력자가 있는지 늘 탐색하고 있다. 윗분들에게 프레젠테이션 하는 거 좋아한다.

짧게 쓰려고 했는데 또 길어졌습니다. 죄송. 물론 짧게 쓰려고 하다 보니 단순화 일반화 했습니다.

--------------------------------------------------------------------------------------------------------------------------------------

(from Yangpa님) 페이스북에 공개글로 올라왔던 글입니다