‘성장에 한계를 느끼는 순간, 스스로 돌파구를 찾는 개발자가 되려면’을 듣고
이 포스트는 이종립님의 ‘성장에 한계를 느끼는 순간, 스스로 돌파구를 찾는 개발자가 되려면’을 듣고 작성하였습니다.
어쩌다 듣게 되었나?
회사를 1년 간 다니고 내가 성장한 게 있었나를 돌아보니 크게 발전한 것 같지도 않았고, 그렇다고 성장을 하려니 뭔가 발목 잡히는 기분이라… 이 상황에서 내가 무엇을 할 수 있을지를 고민하는데, 내 멘토 분께서 이 강의를 추천해주셨고 제목을 보니 “와 이거 내 얘긴가” 싶어서 수강신청 하였다.
라이브 강의를 듣고 제일 기억에 남는/중요한 점?
라강을 들으면서 강의 내용을 쭉 정리해나가는데 딱 세 가지가 내 뇌리에 크게 박혔다.
팀플레이
혼자 고민하는 시대는 끝났다. 여러 사람과 함께 잘 할 줄 알아야 한다.
사실 이건 누구나 다 알고 있는 것이다. 실천이 어려워서 그렇지. 나도 솔직히 말하자면 혼자 알아서 구글링하고 알아서 코딩하는 것 쯤은 누구나 훈련할 수 있다고 생각한다.
혼자 알아서 하는 건 대학 때까지 이미 충분히 겪어봤고 방법도 나름대로 있기 때문에, 나는 팀플레이를 할 수 있는 공간을 원했고 지금도 원하고 있다.(사실 대학에서 스터디 제안했다가 대차게 까이고 나 혼자 공부해서 과탑했다.)
그래서 팀플레이를 위해 한 프로그램을 신청하는데… 이건 나중에 등록이 무사히 완료되면 작성하겠다.
컨텍스트
동료들과 컨텍스트 쌓자.
와 이거 진짜 어렵다. 쉽게 바꿔 말하자면 ‘가까워지자’인데, 사회성이 떨어지는 나에게는 너무나도 어렵다.
위에서도 말했지만, 나는 ‘혼자 알아서 하는 데에 특화’되어있기 때문에 당연히 팀원들과도 개인적인 이야기는 개미의 턱에 달린 10번째 털만큼만 했다. 팀원들과 얘기할 때에는 일에 대해서만 하지, 친하지도 않은 사람과 개인적인 이야기 하는 건 싫어하기도 해서 안 한다.
근데 이게 모순적인 게, 개인적인 이야기를 하지 않는데도 친해질 수가 있나?
어쨌든, 컨텍스트를 잘 쌓아두면 직장 내에서 뭔가를 시도할 때 갈등상황을 극복하는 데 도움이 된다고 한다.
동료에게 뭔가 해보자고 제안할 때, 같이 식사를 하거나 운동을 하거나 게임을 하는 등 어느 정도 친해지면서 컨텍스트를 쌓고 시작해보자.
그런데 이럼에도 불구하고 동료들이 시도에 눈치를 준다면 이직을 생각해보자.
내가 직장에서 “이거 이래서 좋다는데, 이거 한 번 써볼까요?”를 몇 번 제안했던 적이 있다. 현재 팀의 규모가 작아서 팀원이 늘어나 체제를 못 바꾸기 전에 먼저 바꿔놓아야 한다고 생각했기 때문이다. 그 때마다 누가 눈치를 주진 않았는데, 항상 “내가 익숙하지가 않다.”, “나중에 하자.”라는 팀장의 대답을 듣고 제안을 접었던 적이 좀 있다.
지금 이 강의를 듣고 다시 떠올려보면 조금 팀장님과 친해져 보기도 하면서 신뢰를 쌓고 저 말을 했더라면 결과가 달랐을까 하는 생각이 든다.
코드 리뷰
코드 리뷰의 첫 번째 목표는 대화와 분위기이고, 두 번째 목표는 더 나은 코드이다.
난 코드 리뷰를 무조건 ‘더 나은 코드! 집단 지성!’으로만 생각했는데, 첫 번째 목표를 들어보니 일리가 있었다.
코드 리뷰는 서로가 같이 배우고 성장하는 시간이지, 두 번째 목표에만 비중을 둔다면 코드 리뷰는 숙제 검사와 같은 시간이 될 것이다.
그러다보면 자연스레 코드 리뷰 시간을 부담스러워 하고 서로 자신이 짠 코드를 보여주려 하지 않다보니 서로의 성장이 더뎌질 것이다.
저 내용을 듣고 보니 코드 리뷰는 서로의 실력적인 성장 뿐만 아니라 내면적인 성장도 같이 이룰 수 있는 아주 중요한 시간인 것 같았다.
나도 저런 거 해보고 싶다.
이종립 개발자님의 팁
이건 이종립 개발자님께서 경험해 보신 내용을 정리한 글이다.
위키를 써보자
블로그를 쓸 때에는 글을 완성해야 한다는 강박이 있었기에(완전 공감) 그런 강박에서 벗어나 계속해서 써내려가는 형식의 위키를 쓰기로 했다.
글을 랜덤으로 노출되게 하는 기능을 도입함으로써 이전에 쓴 글의 우선순위가 내려가는 것을 방지한다. 또한 과거의 글을 랜덤하게 봄으로써 지속적인 업데이트를 하여 위키 전체의 문서 수준이 향상된다.
목차를 작성하면 위키를 매일 볼 때 목차를 외우게 되고, 회사에서도 “내 위키에 이런 내용이 있었지” 하고 찾아볼 수 있다.
침체기가 온다면?
문서를 쓰기 싫을 때에는 제목만 올린다. 그러다 랜덤 기능을 돌렸을 때 제목만 있는 문서가 뜨고 문서를 작성할 여력이 있으면 그 때 마저 작성했다.
이것저것 생각나는 거 다 하자
BDD 테스트 코드
어떻게 작성해야 할 지 모르겠다면, 표준적인 방법을 따르자. ‘이 메서드는 이런 환경에서 이런 결과를 내고, 이런 입력이 들어오면 예외를 발생시킨다.’와 같은 컨텍스트를 작성하면, 어떤 경우의 컨텍스트가 빠졌는지도 볼 수 있다.
매주 세미나
서로 아는 건 공유하고, 모르는 건 솔직하게 말하고 배우자.
기술 블로그를 만들자
위의 ‘위키를 써보자’와 같은 맥락인데, 목차를 만들면 개요를 파악하기 쉽다.
HISTORY 문서를 열심히 작성하자
프로젝트 체크리스트를 작성하자.
- 달성한 항목은 지우지 말고 그대로 둔다(history 문서니까).
- 위에서 아래로 할 일 → 한 일 순으로 나열한다.
- 한 일 옆에는 관련 문서의 링크를 건다.
- 문서의 제일 하단에는 링크 모음을 둬서 관련 url을 한꺼번에 볼 수 있게 한다.
- 장애 관련 문서도 날짜-한 일을 제목으로 체크리스트에 포함한다.
좋은 동료와 일하고 싶다면?
내가 먼저 좋은 동료가 되자(힘내보자..!).
테스트를 먼저? 리팩터링을 먼저?
이건 나도 테스트 코드와 리팩터링을 알게 되면서 고민한 문제인데 역시 테스트 코드를 통과하고 나면 리팩터링을 하라고 하셨다.
하루가 너무 짧다. 시간을 효율적으로 쓰려면?
평소에 하는 일의 가지 수를 줄이자.
공부를 한다면 회사 일과 관련된 공부를 먼저 하는 게 효율적이다. 업무와 관련된 공부를 하면 동료에게 도움을 받을 수도 있다.
그리고 반드시 기록을 남기자.
나에게 도움이 되는 정보와 도움이 되지 않는 정보를 구분하는 법
회사와 관련된 정보면 당장 도움이 될 것이다. 회사와 관련되지 않은 정보면 우선 순위를 미뤄도 될 것이다.
개인 프로젝트를 어떻게 해야할까?
개인 프로젝트는 코드로 꼭 뭔가를 만드는 게 아니라, ‘일주일 동안 어떤 기능에 대해 공부하겠다’, ‘일주일 동안 이 책에 대해 정리를 한 레포트를 만들어 보겠다’는 것도 프로젝트라 생각한다.
일주일 동안 집중해서 무언가를 한 거면 그것만으로도 프로젝트다.
관심사는 너무 여러 가지로 퍼지지 않게, 회사에서 하는 일을 위주로 관심사를 줄이자.
백엔드 개발자가 혼자 밖에 없는데 성장할 수 있을까?
혼자 있어도 성장할 수 있다. 위키를 만들어 보는 게 도움이 될 것이다.
혼자니까 반드시 커뮤니티 활동을 해봐야 한다. 관심사가 비슷한 개발자와 얘기를 나누면 내가 생각지도 못 한 점을 지적해주거나 보완해주는 경우도 있다.
그런데 나는 이건 어느 정도 한계가 있다고 본다. 결국에는 사람을 많이 만나보고 교류를 해야하는데, 커뮤니티로는 어느 정도야 괜찮아도 충분하지는 않을 거라 생각한다.
신입 개발자로 취직하려 할 때 지식 외 갖춰야 할 것은?
취직이나 이직을 고민할 때 관심 있는 회사의 영역을 더 넓혀서 채용공고를 수집해보자. 예를 들어 3군데가 있다면 10군데로.
채용공고에서 공통된 분야를 뽑아내서 먼저 공부하면 도움이 될 것이다.
나도 해보고 싶다!
이종립님께서 말씀해주신 경험 중에, 재밌어보이는 것 중에 하나가 ‘짝코딩’이었다.
짝코딩
서로 원격으로 본인의 화면을 띄워놓고 공유하면서 코딩을 하셨다는데, 모르는 게 있으면 물어보고 같이 찾아보기도 하는 행복한 경험이었다고 말씀하셨다.
나도 저런 거 해보고 싶다2.
댓글남기기