좋은 개발자가 되는 방법

좋은 개발자란 뭘까? 아니, 우리가 좋은 개발자가 돼야 하는 이유는 뭘까?

2011년 11월, 큰 꿈을 품고 사회에 나온 것이 어느새 8년 전이다. 첫 직장에서는 안드로이드 개발자로 4년 일했고, 이후 스타트업 창업자와 프리랜서를 2년간 겸했다. 1년 4개월간 IT 기자로 활동하다가 올해 5월에 다시 개발자로 돌아왔다.

 

나는 7년 차 개발자다. 주로 안드로이드 개발자로 일했고, 자바(Java)를 주 언어로 다룬다. 파이썬(Python) 등 간단히 다루는 언어도 있고, AWS 등 필요에 의해 틈틈이 배운 기술도 있다. 은행 업무를 도메인으로 가지고 있으며, 다양한 디바이스에 UI를 최적화하는 것이 주특기다.

 

큰 꿈을 품었던 신입 사원이라면 5년 뒤, 10년 뒤 자신의 모습을 상상해봤을 것이다. 나 역시 그랬지만, 사실 그때 그렸던 내 모습이 기억나지 않는다. 하지만 대리, 과장을 보며 언젠가 나도 저 위치가 되겠거니 상상을 했던 것 같다. 나는 그들보다 더 멋진 일을 하고 싶었다. 더 나은 개발자가 되고 싶었다.

 

나는 욕심이 많다. 덕분에 눈앞에 선배들보다 더 먼 곳의 인기인이 내 타깃이었다. 언젠가 나도 그들과 함께 또는 동등하게 일하고 싶은 꿈이 있었다. 그래서 기회가 왔을 때 다양한 경험을 쌓으려 자리를 옮겼다. 그리고 그 경험들이 나를 단단하게 만들어줬다.

 

다양한 경험을 하다가 다시 개발자로 돌아왔다. 지금은 극복했던 여러 고통을 떠올리며 어느 날 내게 물었다.

 

"그래서, 나는 멋진 일을 하고 있는가? 더 나은 개발자가 됐는가?"

 

우리나라 개발자는 약 9만 명, 그리고 이들은 완전 고용 상태라고 한다.(구글 인재 영입 나서자… 네이버 ‘1500억 스톡옵션’ 꺼냈다.) 기자로 일하며 가장 많이 받았던 요청 중 하나가 '개발자 추천'이었다. 제발 좋은 개발자 좀 추천해달라는 요청이었다.

 

'좋은'이란 단어는 편히 사용할 수도 있지만, 사람을 추천함에서는 쉽지 않은 단어다. 게다가 완전 고용 상태인 이 업계에서 '좋은 개발자'는 당연히 고용 상태다. 고용 상태인 좋은 개발자를 데려오기는 쉽지 않은 일이다. 그런데 '좋은 개발자'란 뭘까?

 

"좋은 소프트웨어 개발자란 코딩, 문제 해결, 단위 테스트 작성을 능숙하게 잘하는 사람이 아니다. 좋은 소프트웨어 개발자는 자신의 경력을 관리하고 목표를 성취하며 삶을 즐기면서 살아가는 사람이다."
- 존 손메즈,  『소프트 스킬』 중

 

7년 차 개발자인 나도 '좋은 개발자'를 정의하는 데 간단하지 않다. 그런데 존 손메즈는 '삶을 즐기면서 살아가는 사람'이라고 정의한다. 그게 정말 좋은 개발자일까? 생각해보니 나는 벽을 만나거나, 번아웃이 왔을 때 최대한 삶을 즐기려 노력했던 것 같다. 덕분에 지금까지 개발자로 일할 수 있었다. 살아남는 자가 강한 자라는 논리가 여기에도 적용될까?

 

개발자는 언제나 부족했다. 현재 추세라면 앞으로 '좋은 개발자'는 더욱더 귀해질 예정이다. 당신이 개발자라면, 개발자와 함께 일하는 동료라면 좋은 개발자를 발견할 수 있어야 하지 않을까?

 

이 글에서는 좋은 개발자에 관해서 알아본다.

 

 

『소프트 스킬』

 

 

개발자의 커리어

 

◆ 개발자의 조직

 

좋은 개발자의 기준은 좋은 연인의 기준처럼 모두가 다를 수 있다. 동료로서 좋은 개발자, 직원으로서 좋은 개발자, 멘토로서 좋은 개발자 등 각자 환경에서 좋은 개발자는 달라야 한다. 그 때문에 자신이 선호하는 역할에 맞는 환경에서 일하는 것이 중요하다. 다양한 환경에서 일할 수 있는 것은 개발자가 갖는 특권 중 하나다.

 

나는 SI(System Integration, 시스템 통합) 개발자, 자사 서비스 개발자, 프리랜서 개발자, 정직원 개발자 등 다양한 환경을 경험했다. 결론부터 말하면, 무조건 나쁜 환경은 없다. 흔히 SI 환경이 최악이라고 말하고, 나 역시 SI 환경이 가장 싫었다. 하지만, 자신이 SI에 특화된 사람이라며 SI가 좋다고 말하는 개발자를 여럿 만났다.

 

SI 프로젝트는 대부분 발주사의 사무실에 파견을 하러 가는 형태다. 공공, 금융 등 프로젝트가 많이 있다. 나는 SI 특유의 딱딱하고 무거운 분위기가 싫었다. 군대 문화라고 생각하면 된다. 매번 팀원이 바뀌어 팀워크를 다지지 못하는 것도 싫었다. 하지만 시키는 것만 하면 되기 때문에 편하다고 말하는 개발자도 있었다. 늘 새로운 사람을 만날 수 있어 좋다고 말하던 개발자도 있었으니, 그야말로 생각하기 나름이다.

 

창업자로 일할 때도 기억에 남는다. 안드로이드 개발자였음에도 서버 개발이 필요해 빠르게 파이썬을 배워 개발했다. 데이터베이스나 서버 관리도 내가 해야 했다. SI 특유의 압박감과 비교할 정도가 아니었다. 개발자 출신 창업자라고 해서 고객이 부족한 경영 마인드를 이해해주는 것은 아니다. 개발자 역할과 창업자 역할을 다 해야만 했고, 결과적으로 나는 실패했다. 누구에게도 구속받지 않는 자유를 꿈꿨지만, 고객은 상사보다 더 헤아리기 힘들었다.

 

"사업가의 삶은 롤러코스터를 타는 것처럼 늘 기복이 심하다. 개발한 상품이 인기를 끌어 천하를 얻는 듯한 날도 있고, 완전히 실패해서 이번 달 월세를 어떻게 내나 고민으로 밤새우는 날도 있다."
- 존 손메즈,  『소프트 스킬』  중

 

프리랜서로 일할 때도 많은 것이 불안정했다. 정직원일 때는 프리랜서가 마냥 좋아 보였는데, 프리랜서가 되니 정직원이 좋아 보였다. 원하는 일만 골라서 하려고 했지만, 고객 역시 원하는 개발자에게 일을 맡기니 경쟁력이 없는 한 원하는 것을 고르는 것은 그저 꿈이었다.

 

"소프트웨어 개발자 초년생일 때는 직원으로 일하는 게 적절하다. 위험이 가장 적고, 경험이 없어도 진입할 수 있기 때문이다. 직원으로 일하는 것은 수습생과 비슷하다. 나중에 독립할 마음이 있는 사람도 처음에는 직원으로 시작해서 능력을 키워나가면 좋다."
- 존 손메즈,  『소프트 스킬』  중

의도한 것은 아니지만, 나는 첫 직장에서 정직원 개발자로 4년간 일한 뒤 독립을 선언했다. 최소 3~4년은 첫 직장에 있어야 한다는 주변 어른의 말씀을 들은 것도 있지만, 우연히 시점이 맞았다. 결과적으로 그때의 인연으로 프리랜서도 할 수 있었고, 지금까지 이어지고 있으니 운이 좋았다고밖에 말할 수 없다.

정직원 개발자로 일하며 창업자와 프리랜서를 꿈꿨다. 다시 정직원 개발자로 돌아온 나는 창업자와 프리랜서에 관한 막연한 꿈을 접을 수 있었다. 나는 내게 더 맞는 환경으로 돌아왔다.

 

 

◆ 개발자의 전문성

 

나는 전투적인 개발자였다. 일정 압박을 무조건 받아들이지 않고, 내 여유 시간을 확보해내는 전투를 했다. 때로는 그런 성향이 나를 너무 힘들게 해 다 포기할까 싶었다. 하지만 눈앞에 보이는 결점을 그냥 넘기는 것보다는 압박감을 받아들이는 것이 더 편했다. 결국 내가 더 편한 것을 선택한 것뿐이다.

 

"전문가는 필요할 때 "아니요."라고 말할 줄 알아야 한다." 
- 존 손메즈,  『소프트 스킬』  중

 

나는 타인의 인정과는 별개로 늘 스스로 '전문가'라고 생각하며 일했다. 내가 전문가라고 생각하는 기준은 딱 두 가지다. “남의 돈을 받고 일하는가?” “ 사기를 치지 않는가? “ 등이다.

 

남의 돈을 받고 일하면 대부분 전문가다. 누군가의 돈을 받는다는 것은 누군가의 시간을 절약해주고 있는 것이고, 자신의 가치를 어떻게 생각하든 상대가 가치를 인정했다는 뜻이다. 상대가 지속해서 돈을 지급하며 일을 맡긴다면, 자신의 전문성에 관해 조금 더 자신감을 가져도 좋다.

 

내가 말하는 사기는 거창한 것이 아니다. 남을 속이면 사기다. 개발자가 한 달 뒤까지 기능을 개발한다고 말하고, 한 달 뒤 기능을 개발하지 못하면 사기다. 나는 이런 개발자를 너무도 많이 봤다. 물론 일정은 변경될 수 있다. 그런 경우 충분한 대화를 통해 협의하며 조율하면 된다. 하지만 한 달간 가만히 있다가 일정 마감이 돼서야 개발을 마치지 못했다고 하는 것은 내 기준에서 사기다. 누군가는 마치지 못한 그 일을 해야만 한다. 결국 동료에게 피해를 주는 프로답지 못한 행동이다.

 

나는 전문성을 갖춘 개발자를 많이 만났다. 수많은 개발자 추천 요구에도 그들을 추천할 수 없는 이유는 다양한데, 우선 고용 상태이거나 기술 분야가 달라서인 경우가 크다. 적은 이유로 추천을 요구한 상대에게 추천하고 싶지 않아서인 경우도 있었다.

 

전문성을 갖춘 개발자 중 자신감이 부족한 개발자도 많이 봤다. 한 조직에 머무르며 '알아서 잘 챙겨 주겠지'하는 태도는 옳지 않다. 내가 만난 세상은 그리 호락호락하지 않았다. 전문성이 부족한 분야에서 과하게 자신감을 보이면 안 되지만, 스스로가 속한 분야에서 자신감을 비치는 것은 꼭 필요하다.

 

충분한 능력을 갖추고 있음에도 인정받지 못하는 개발자들이 참 아쉬웠다. 반면 능력 이상의 대우를 받는 사람도 있었다. 씁쓸한 것은 처음엔 능력 이상의 대우를 받다가 결국 대우에 맞는 능력을 갖추는 경우를 본 것이다. 이미 능력을 갖춘 개발자가 기회를 얻었더라면 얼마나 좋았을까 싶었다.

 

그렇다면 능력 이상의 기회를 얻는 게 나쁜 것일까? 글쎄, 기자 생활을 하며 수많은 상황을 경험하니, 기회를 얻는 것도 능력이라는 생각이 들었다. 그렇다면 개발자에게 기회란 뭘까? 그들은 어떻게 기회를 얻을까?

 

 

개발자의 외부활동

 

개발자가 개발을 잘하면 인정받을까? 라는 질문에 대한 답은 맞다. 그런데 개발자가 개발만 잘하면 인정받을까? 라는 질문에 대한 답에는 '아니다'고 답하겠다.

 

리눅스의 아버지 리누스 토발스(Linus Benedict Torvalds)나 파이썬의 아버지 귀도 반 로섬(Guido van Rossum)처럼 엄청난 기술력을 가졌다면 모르겠다. 하지만 평범한 소프트웨어 개발자라면 기술력만으로는 경쟁력을 갖추기 어렵다. 게다가 리누스 토발스와 귀도 반 로섬은 강연도 하고 책도 쓴다. 이들도 기술력만 갖추진 않았다.

 

"언젠가는 일류 개발자들과 동등한 기술 수준에 이르는 날도 올 것이다. 경력이 10년 정도 되면 많은 소프트웨어 개발자가 그런 수준에 이른다. 그 정도 수준이 되면 더 발전하기가 어려워진다. 다른 이들도 비슷한 경지에 이르러 있으므로 개인적 재능의 중요성은 훨씬 낮아진다."
- 존 손메즈,  『소프트 스킬』  중

 

나는 뛰어난 기술력을 가진 개발자가 아니다. 그런데도 많은 프로젝트를 성공적으로 마쳤고, 퇴사 후에도 프리랜서 제안을 받아 함께 일했다. 그 때문에 후배 개발자에게 이야기할 기회가 된다면 기술력 외 다른 부분을 채우도록 권유한다. 내 경우에는 기술력보다 커뮤니케이션 스킬에 큰 덕을 봤다.

 

존 손메즈는 기술력 외 다른 부분으로 블로그나 잡지 기고, 책 저술, 콘퍼런스 강연, 유튜브 등을 말한다. 나는 이 중 블로그 덕분에 많은 기회를 얻었다. 내 블로그에는 책 서평을 주로 적는데, 가끔 책의 저자가 블로그에 찾아와 댓글을 달아주곤 했다. 구글 본사에서 일하는 엔지니어와 댓글로 대화를 나누고, 실제 만남까지 가졌던 경험은 블로그가 있었기에 가능했다.

 

 

구글 엔지니어가 댓글을 달아줬다. / 오세용닷컴

 

 

잡지 기고에 관한 이야기라면 정말 할 말이 많다. 나는 대한민국 유일의 소프트웨어 전문지 "마이크로소프트웨어"에서 일했다. 기고할 개발자를 찾는 것이 본업이었고, 1년 4개월 동안 수많은 개발자를 만났다. 블로그를 적는 것으로 기회를 얻을 수 있느냐 묻는다면 당연하다고 소리치고 싶다.

 

요즘은 서너 명만 모여도 '유튜브' 이야기를 빼놓지 않는다. 유튜브도 당연히 기회를 얻는 데 좋다. 블로그보다 더 좋다고 말할 수 있다. 하지만 유튜브는 매우 많은 투자가 필요하다. 시간이며, 장비며, 편집 프로그램 학습도 필요하다. 블로그로 적어 둔 글을 유튜브로 재발행 할 수 있으니 일단 블로그를 시작하는 것을 추천한다.

 

그렇게 콘텐츠가 공유되면, 다양한 경로를 통해 연결된다. 자신의 자리에서 열심히 개발만 한다고 모든게 술술 풀리지 않는다. 그런 꿈같은 이야기는 쉽게 일어나지 않는다.

 

내가 블로그를 하는 것을 보고 블로그를 하려면 어떻게 해야 하냐고 물어본 사람이 정말 많다. 하지만 그들 중 진짜 블로그를 시작한 사람은 거의 없고, 지속해서 블로그를 쓰는 사람은 전혀 없는 것 같다. 결국은 콘텐츠를 짜내는 것에 어려움을 느끼는 건데, 답은 학습이다.

 

꾸준히 무언가를 배워야 콘텐츠가 생긴다. 꾸준히 학습하는 것은 생각보다 쉽지 않다. 그 때문에 꾸준히 학습하고 있다면 충분히 자신감을 가져도 좋다. 나는 꾸준히 학습하기 위해 친구들과 커뮤니티를 만들어 공부하고 있다. 함께 책을 읽는 독서소모임과 경영 콘텐츠를 읽고 쓰는 경영소모임, 아세안(동남아시아) 시장을 조사하는 아세안 비즈니스 랩, 아비랩 등을 만들어 함께 공부한다.

 

 

따뜻한 커뮤니티 STEW

 

 

하지만 마음 맞는 친구를 모으는 것은 학습보다 쉽지 않다. 게다가 이 방법이 성향이 맞지 않을 수도 있다. 무엇보다 함께 공부하기 위해 혼자 공부하는 시간이 필요하다. 결국 더 나아지기 위해서 독학은 필수다.

 

 

개발자의 독학

 

한때 개발자를 포기하려 했다. 부끄럽게도 이유는 '죽을 때까지 공부하기 싫어서'였다. 개발자는 평생을 공부해야 한다. 다른 분야보다 역사가 짧음에도 엄청난 속도로 발전하고 있다. 덕분에 밥줄이 끊길 일이 없는 것으로 위안해야 할까?

 

"소프트웨어 개발자라면 반드시 혼자 공부하는 법을 익혀야 한다. 매일 새로운 기술이 등장하는 소프트웨어 개발 분야에서 살아남으려면 독학은 필수 기술일 수밖에 없다."
- 존 손메즈,  『소프트 스킬』  중

 

소프트 스킬에서 가장 집중해서 읽은 부분이 바로 '독학' 챕터다. 존 손메즈는 자신이 개발한 10단계 학습법을 설명하는데, 이 부분은 동료들에게 꼭 보여주고 싶을 정도로 의미가 있었다.

 

존 손메즈가 말하는 10단계 학습법은 다음과 같다.

 

1단계 : 큰 그림을 보라
2단계 : 범위를 정하라
3단계 : 성공을 정의하라
4단계 : 자료를 찾아라
5단계 : 학습 계획을 세워라
6단계 : 자료를 선별하라
7단계 : 대충 사용할 수준까지 배워라
8단계 : 놀아라
9단계 : 유용한 일을 할 정도까지 배워라
10단계 : 가르쳐라
- 존 손메즈, 『소프트 스킬』중

 

 

10단계 학습법. / 소프트 스킬

 

 

10단계로 설명하니 조금 거창해 보일 수 있다. 몇 차례 읽어보니 비슷한 경험이 떠올랐는데, 이 학습법과 많은 부분이 닮아 소개하고 싶다.

 

현재 내 AWS EC2에는 워드프레스가 4개 실행되고 있다. 개인 블로그를 비롯해 커뮤니티 친구들과 유용하게 사용하고 있다. 나는 안드로이드 개발자로 서버 운영과는 거리가 멀었다. 몇 년 전 커뮤니티에서 사용할 홈페이지를 만들고 싶어 조사를 시작했다.

 

홈페이지는 모임 공지사항 및 친구들의 칼럼을 올리는 공간으로 구상했다. 우선 리눅스 서버와 홈페이지를 만들 언어를 선택해야 했다. PHP 등을 배워 직접 만들려고 했지만, 시간이 부족했다. 제로보드 등 다양한 솔루션을 알아보던 중 워드프레스를 선택했다.

 

전 세계 웹사이트 30%가 워드프레스로 만들어졌다. 수많은 테마가 있고, 빠르게 설치해 사용할 수 있는 점이 마음에 들었다. 리눅스 서버를 빌려서 여러 차례 워드프레스를 설치했다. 이 과정에서 리눅스 파일 권한, 타임존, 유저 생성, 접근 권한 등 리눅스 기초를 학습할 수 있었다. 워드프레스 홈페이지를 띄우고 친구들에게 아이디를 발급했다. 친구들의 의견에 따라 테마를 재설치하고, 속도 향상 등 플러그인을 설치하며 꽤 많은 시간을 보냈다.

 

 

워드프레스로 만든 아비랩. / 아비랩

 

 

몇 주가 흐르고, 이제 워드프레스를 설치하고, 도메인을 연결해 사용하는 것은 내가 가진 스킬 중 하나가 됐다. 홈페이지 개발을 원하는 비 개발자에게는 적극 워드프레스를 권하고, 원한다면 빠르게 사용 방법을 가르쳐줄 수 있는 단계가 됐다.

 

존 손메즈가 말하는 것은 딱 이 단계다. 글을 읽고 생각해보니 정말 내가 얻게 된 스킬은 존 손메즈의 방법을 따른 것 같다. 특히, 8단계 '놀아라'를 얼마나 잘 보내느냐에 따라 더 오래 배울 수 있는 것 같다. 놀면서 배운 게 정말 더 오래가는 것 같다. 독학에 어려움을 겪고 있다면, 놀면서 공부할 수 있는 분야를 찾아보자.

 

 

그래서 좋은 개발자란?

 

개발자의 커리어와 외부활동 그리고 독학에 관해 짧게 정리해봤다. 존 손메즈는 이 방법을 꽤 잘 활용한 것 같다. 이후 부동산 투자 등도 잘했기 때문이지만, 무려 33세에 은퇴했다고 하니 흔한 개발자는 아니다.

 

사실 위에서 말한 3가지 내용은 개발자 커뮤니티 활동을 하거나, 좋은 선배가 있다면 흔히 들어온 말일지도 모른다. 만약 위 내용을 다 처음 듣는 개발자라면, 개발자 콘퍼런스를 참여해보는 것을 추천한다. 요즘 콘퍼런스에는 기술 외 개발자 자체에 관한 세션도 많이 있다.

 

"좋은 소프트웨어 개발자란 코딩, 문제 해결, 단위 테스트 작성을 능숙하게 잘하는 사람이 아니다. 좋은 소프트웨어 개발자는 자신의 경력을 관리하고 목표를 성취하며 삶을 즐기면서 살아가는 사람이다."

- 존 손메즈,  『소프트 스킬』  중

 

존 손메즈의 경험이 꼭 정답은 아니다. 하지만 눈앞의 프로젝트에만 집중하고, 프로젝트가 끝나면 다음 프로젝트에 집중하는 식의 시야를 가졌다면, 한 번쯤 조금 먼 미래를 상상해볼 필요는 있다.

 

우리는 개발자이기 전에 행복할 자격이 있는 인간이지 않은가?