그런 개발자로 괜찮은가 - '자기계발' 편

　학창 시절엔 ‘선생님’께서 정해놓으신 커리큘럼에 따라가기만 하면 큰 문제 없이 지식을 학습할 수 있었다. 거기에 주기적으로 치르는 시험을 통해 ‘점수’라는 평가 기준으로 얼마나 잘 성장했나를 검사하기도 한다. 졸업 후 어렵게 어렵게 취업에 성공을 하여 ‘신입 개발자’라는 배지를 달고 회사에 첫 출근. 그렇게 n 년이 지난 지금과 라떼 시절(?)을 비교해 보며 과연 ‘학습’에 대한 열정 그래프가 아직도 우상향 중인가? 하는 질문엔 일단 단전부터 올라오는 깊은 한숨과 함게 이상하게도 앞이 캄캄해진다.

　배워야 할게 너무 많다. 아니 그보다 배운 것을 이제 활용해야지 싶으면 또 새로운 기술이 등장한다. 그렇게 매너리즘에 빠지고. 거기다 회사일이 바쁘다는 핑계로 자기계발을 멈추다 보면 남들보다 뒤처진다는 생각에 괜히 자괴감이 들어 우울해 지곤 한다. (코로나 블루 때문만은 아니겠지…) 그 가운데 회사에는 정말 좋은 선배님들도 많고 멘토-멘티 관계를 잘 활용하면 충분히, 잘, 올바른 길로 성장할 수 있을 것이라 생각한다. 하지만 그렇게 누군가에게 ‘의존’만 하다 그 대상이 없어진다든지 심지어 그런 대상조차 없을 경우에는 어떻게 해야 할까? 점점 기술은 발전하고 배워야 할 것들은 홍수처럼 넘쳐흐르고 있는 가운데 ‘회사원’에서 나아가 ‘개발자’로써 성장을 하기 위해서는 어떠한 방법이 있을까?

　이번 포스팅에서는 개발자로 살아가면서 성장하기 위한즉, 자기계발의 ‘방법’에 대해 이야기해보려 한다. 이것이 정답이다 하는 은 탄환을 소개하려는 것은 아니다. 특히 개발자로서의 생을 마감(?) 할 때까지는 계속 배워야 하는 숙명과도 같은 직업이기에 첫 단추를 잘 끼워서 갑작스러운 기술의 변화에 일희일비 하지 않고 스펀지처럼 무엇이든 흡수하는. 말랑말랑한 정신을 갖기 위함이라고나 할까.

블로그

　개발자가 글도 써야 하나?라는 질문에는 필자가 예전에 정리해둔 개발하기 바쁜데 글까지 쓰라고? (글쓰는 개발자가 되자.)라는 글을 참고해봐도 좋을 것 같다. 해당 포스팅에서 수차례 강조하였지만 그만큼 개발자에게는 특히나 글쓰기가 중요하고 필요하다. 글을 꼭 ‘잘’써야 한다는 부담을 가질 필요는 없다. (필자도 그렇게 잘 쓰는 편은 아니다…) 다만 무언가를 기록하고 정리하고 자신만의 기준에 맞추어 재 정리하는 습관을 기르다 보면 이러한 생각들이 개발을 할 때에도 도움이 상당히 되었기 때문이다.

　복잡한 구조가 필요로 하는 개발을 해야 한다고 가정해보자. 연동하는 시스템도 많고 정말 다양한 요구 사항을 하나의 시스템에서 구현을 해야 할 경우 보통 개발을 하기에 앞서 ‘설계’라는 단계를 거치기 마련이다. 그때 글쓰기를 했을 때의 습관(스킬?)을 적용해 보면 요구 사항들 중에 중요한 feature 기준으로 정리를 하게 되고, 각 이해관계자들에게 정리한 부분을 공유하며 예외 상황을 보다 빠르게 확인할 수도 있다. 심지어 코드 레벨에서도 지난밤에 야식으로 먹은 라면 면발처럼 꼬여있는 부분들을 보다 개발하기 편하고 유지 보수가 용이하게 구조를 변경하는 ‘정리’의 습관 또한 글쓰기를 통해서 수련을 할 수 있다. 이러한 ‘꼼꼼함’을 기르는 데에는 글쓰기만 한 게 없다고 생각한다.

　우리는 다양한 개발 언어로 코딩을 하곤 한다. 왜 읽기좋은 코드가 좋은 코드라는 책이 있듯이 결국 코딩 또한 커뮤니케이션이 일종이라 생각한다. 내가 생각하는 로직을 개발 언어로 코딩을 해야 하는 상황이면, 결국 내가 생각하는 로직이 명료하고 정리가 잘 된 상태에서야 코드 또한 소위 ‘읽기 좋은 코드’가 되지 않을까 싶다.

　블로그를 시작할 때 어디서부터 시작해야 하나 막막하다면, 오늘의 배운 내용 (개발자들 사이에서 유행처럼 번지고 있는 TIL에 대해서 정리해 보는 것부터 추천한다. 경력이 1년 차여도 10년 차여도 개발을 하다 보면 새로운 것을 발견하기 마련이다. 그렇게 조금씩 적절한 블로그 플랫폼에 정리를 해 나가다 보면 어느새 자신만의 개발 히스토리가 만들어지고, 나아가 글쓰기가 전해주는 긍정적인 효과를 만끽하리라 자부한다.

토이프로젝트

　우리는 개발자이다. 맘만 먹으면 생각하고 있는 동작을 얼마든지 만들 수 있는 능력을 가진 대단하면서도 신기한 사람들이다. 그러나, 회사에서 주어진 스펙을 개발하다 보면 이미 만들어진 개발 환경(일명 레거시)에 스펙을 위한 기능만을 개발하다 보니 정작 아무것도 없는 상황에서 시작하려면 머리가 하얘지기 마련이다. 더불어, 회사에서 추구하는 개발 방법론과 주어진 스킬 트리에 맞춤형(?) 개발자가 되다 보니 새로운 기술을 습득하는데 상당한 기술적 장벽이 생기면서 자칫 ‘기술적 고립’이 될 수도 있는 처지에 빠질 수도 있다.

　이렇게 위험한 상황을 조금이나마 벗어나기 위해서는 단언컨대 ‘토이 프로젝트’를 시작하는 것이 가장 좋다고 생각한다. 어떠한 기능을 어떠한 기술로 만들 것인지. 이런 것도 해볼까 저런 것도 해볼까. 마치 어렸을 적 레고 블록이라는 장난감으로 여러 가지를 만들었던 것처럼 밑바닥부터 새롭게, 그리고 자유롭게 만들어 나가면서 정말 회사에서 배우지 못한 다양한 기술들을 뼈저리게(?) 배울 수 있는 기회이기 때문이다. 요즘 핫한 개발 방법론이라든지, 새로운 언어, 새로운 기술 set을 접목시켜 봄으로써 회사라는 명찰을 떼고 나 자신이 개발자로써 어떠한 기술을 사용할 수 있는지 확인 또한 가능하다.

　여기서 중요한 점은, 그냥 읽어보고 따라 하기만 하는 것보다 그걸 활용해서 실제 결과물을 만들어 보는 것까지 가 중요한 포인트 같다. 이론은 누구나 대충 어림잡아 알고 있다. 하지만 실제로 해보는 건 하지 않은 것과 엄청난 차이가 있다는 걸 명심하자.

　꼭 회사 밖에서 찾을 필요는 없다. 팀 내에서 반복적이고 귀찮은 작업들을 자동화 시켜 본다든지, 아니면 바깥에서 들은 기술들을 우리 팀에 접목시켜본다든지. 내가 주체가 되어 무언가를 진행한다는 그 자체가 중요하고 거기서 기술적인 인사이트를 찾고 나만의 것으로 만드는 과정이 핵심 포인트라 생각한다. 필자는 회사 내부에서도 언제부터인가 시키지도 않는 스펙 개발 이외의 것을 시도하려고 부단히 노력 중이다. 일단 무언가를 만들어 본다가 가장 중요하다. ( 참고 : 어려운 것을 쉽게 배우는 방법 : 슈퍼파워를 장착하기 위한 3단계 학습법 )

　이제는 약 3천여 명이 구독하고 있는 필자의 첫 토이 프로젝트인 기술블로그 구독서비스의 개발 후기를 읽어보는 것도 좋을 것 같다. 벌써 만든 지 2년이 다 되어 가는데 기술적인 인사이트뿐만 아니라 ‘서비스’라는 것에 대한 또 다른 시각을 넓혀주는 좋은 계기가 되었기 때문이다. (어서 또 다른 것을 만들어 봐야 하는데 … )

배우기 위한 노력

　스터디를 하는 방법은 다양하다. 오프라인으로 마음 맞는 사람들끼리 모여서 정해진 규칙에 따라 스터디를 하거나, 나 홀로 인터넷 강의를 들으면서 정해진 커리큘럼대로 배우거나, 그게 아니면 적당한 책을 구입해서 읽거나. 이 외에도 수많은 방법으로 스터디를 하곤 하는데 여기서 이야기하고자 하는 건 스터디의 방법이 아니라 무언가를 배우기 위한 ‘노력’을 꾸준히 해야 한다는 걸 말하고 싶다. 일반적으로 회사에 출근을 하면 업무에 치여서 팀 메신저에 ‘왜 벌써 6시에요?‘라는 소리가 나올 정도로 시간 가는 줄 모르고 일한다. 그러다 퇴근을 하면 피곤에 절어 쉬거나 개인적인 여가활동을 하다 보면 어느덧 자야 하는 시간. 그럼 도대체 언제 개발 공부를 해야 할까?

　사람마다의 추구하는 행복의 가치관이 다 다르고 훌륭한 개발자로서의 모습 또한 다 다른 만큼 이 부분에 있어서는 정답은 없다. 하지만 개발자로써 학습능력을 꾸준하게 기르기 위해서는 업무시간 외적으로 어느 정도는 개발 공부를 하기 위해 시간을 할애를 해야 한다고 생각한다. 예컨대, 필자는 하루에 최소 한 시간은 회사 업무 외적으로 개발 공부를 하는데 시간을 쏟으려 한다. (하지만 잘 지켜지지 않는 게 함정…) 그렇게 하기 위해서는 꾸준한 운동으로 건강한 몸이 뒷받침되어야 가능하기에 야근을 하든 안 하든 퇴근 후 운동과 개발 공부는 어떤 일이 있어도 (잠을 줄여서라도) 꼭 하려고 하고 있다. 어쩔 땐 그러한 ‘공부를 해야 한다’라는 생각들이 필자를 오히려 구속(?) 시키는 느낌도 받지만 그럴 때면 (위에서 말했던 것처럼) 무언가를 만들어 보며 좀 더 ‘재미있게’ 마인드를 유지하려고 노력 중이다. (이러한 글을 쓰는 것도 어떻게 보면 마인드 컨트롤 방법 중 하나라 볼 수 있다.)

　만약, JAVA 라는 언어에 대해 완벽히 안다고 가정해보자. 그럼 10년 20년 그 지식으로 평생 먹고 살수 있을까? 기술은 시대의 변화에 맞춰 바뀌기 마련이며 그러한 변화를 싫어하다보면 우물안의 개구리가 되는건 시간문제라 생각한다. 개발자는 기술의 변화에 민감하게 반응해야 하고 그러한 부분들을 너그럽게 수용할줄 알아야 하며 그렇게 하기 위해서는 자신에게 맞는 방법을 찾아서 흘러 넘치는 변화의 밑물에 노를 저을줄도 알아야 한다 한다.

나를 정리하는 시간

　앞서 이야기 했던 부분들은 결국은 ‘악셀을 밟고 앞으로 전진!‘같은 성격의 이야기라면 이번엔 악셀에서 잠시 발을 떼고 정차 후 점검을 하는 관점으로 이야기를 해 보고자 한다. 장거리 운전을 할때는 워셔액은 충분한지, 타이어 공기압은 괜찮은지 점검하는 것처럼 말이다.

　필자가 학부시절 연구실을 다닐때 한 선배에게 들은 말이 아직도 생각난다. 본인은 (대학생시절) 한달에 한번씩 이력서를 업데이트 한다고… 그러다 보면 변화가 있었는지 한눈에 알 수 있고, 부족한 부분이 무엇인지 점검이 가능하다는 이야기. 얼마전에 이력서 작성법에 대해 아주 좋은 정리글을 보았다. (개발자 이력서 작성하기 (feat. 이력서 공개)) 이처럼 이력서는 이직할때만 사용하는게 아니라 상시 나를 돌아볼수도 있는 수단이라 생각이 들기 때문에 자신만의 방식으로 이력서를 업데이트 하는것도 좋은 방법이라 생각이 든다. (물론 필자도 링크드인만 몇줄 적은게 다 이지만… 이참에 정리한번 해봐야겠다.)

　자신만의 기술 스택을 정리하는 것 또한 방법이 될 수 있다. 쿠버네티스가 요즘 뜨고 있다고? 머신러닝이 대세라고? 하며 요즘 뜨는 기술들만 따라 하는 자세보다 자신이 생각하는 기본기를 탄탄히 다지면서 각자의 호흡, 각자의 속도를 유지하며 꾸준하게 기술 스택을 만들어 나가는 게 올바른 방법이라 생각이 든다. 우리는 1~2년 짧게 개발만 하는 것이 아니라 오랫동안 마라톤처럼 달려야 하기 때문에 탄탄한 기본기를 다지는 자신만의 방법이 필요한 때이다.

마치며

　적어도 ‘개발자’ 라면, 그리고 좀 더 괜찮은 ‘개발자’로써 오랫동안 개발을 하고 싶다면 ‘자기계발’은 뗄래야 뗄 수 없는 필연적인 키워드이기 때문에 속도는 늦더라도 꾸준히 지속하는 게 중요하다고 생각한다. ‘자기계발’이라는 키워드로 이야기를 하다 보면 점점 ‘꼰대’가 되는 것만 같아 아쉽지만, 다~ 잘 되고자 하는 (또 꼰대 말투) 부분들이니 너무 노여워하지는 않았으면 한다. :)