기술 블로그와 시니어 개발자(나의 생각)

개요

기술 블로그, 시니어 개발자 내가 최근들어 가장 많이 생각하는 주제들이다. 글로 쓸정도의 내용인지는 잘 모르겠지만 나조차도 아직 내가 이것들에 대해 어떻게 생각하는지 제대로 정리해본적이 없기에 나 스스로를 위해 그리고 앞으로를 위해 이를 글로 정리해보려고 한다.

 

기술 블로그

나는 작년부터해서 기술블로그를 열심히 쓰고 있다. 처음 시작은 어색하고 억지로 쓰는 느낌이였지만 지금은 습관이되어 일주일에 한 개 정도는 기술블로그를 작성하지 않으면 성에 안차는 느낌을 받는다. 기술블로그란 뭘까? 내가 왜 기술블로그를 열심히 쓰기로 결정했을까? 이제부터 그 이유와 나의 생각들을 적어보겠다.

개발자가 외부에 자신을 표현할 수 있는 방법은 대표적으로 두 가지가 있다고 생각한다. 한 가지는 깃헙이고 나머지는 기술블로그이다.

 

개인적으로는 깃헙보다는 기술블로그를 선호한다. 이유는 깃헙에서는 개발자의 개발 역량을 볼수는 있어도 그 사람이 어떤 생각을 가지고 개발하였으며 어떤 사람인지에 대해서는 나와있지 않기 때문이다. 기술 블로그에서는 그 사람의 개발 역량과 더불어 그 사람이 어떠한 생각을 가지고 이러한 방식을 사용했는지, 평소에 어떤 주제에 대해 어떤식으로 접근하는지, 개발 마인드는 어떤지 등 작성자의 모든 것이 보여지게된다.

어떤 글에서는 다른 개발자 누군가는 한 번쯤 고민해봤을 법한 내용들도 적어놓으며, 또 어떤 글에서는 순수하게 기술에 대한 그 사람의 진심을 적어놓기도 한다.

그렇기에 기술블로그는 자신이 어떤 개발자인지를 가장 정확하고 빠르게 전달할 수 있는 방법이라고 생각한다.

 

물론 이런 생각을 처음부터 한 것은 아니다. 이런 생각은 나를 따르는 주니어 개발자들에게 반드시 기술블로그를 쓰라고 권유하면서 왜 써야하냐는 이유를 들었을 때 그 이유를 내가 생각하는 기술블로그의 가치와 잘 어울려지게 설명하기 위해 생각한 내용들이다.

그렇다면 나는 처음에 왜 이런 생각을 가지고 있던 것도 아닌데 왜 기술블로그를 쓰기 시작했을까? 나는 나를 표현하는 방식 그리고 성장하기위한 방식으로 기술블로그만큼 적합한 것이 없다고 결론내려져서이다.

 

나는 코딩을 기가 막히게 잘하는 것이 아니기에 코드 혹은 알고리즘으로 보는 사람에게서 "우와" 라는 생각이 들게 할 자신은 없다. 하지만 마인드, 문제 해결 능력, 끈기, 창의력 등은 분명한 나의 강점이라는 사실도 알고 있다. 

기술 블로그는 바로 이 강점을 가장 잘 살릴 수 있는 방법이라고 판단했다. 그래서 블로그를 통해 내가 어떻게 문제를 해결했고, 어떤 생각을 거쳐 그 과정에 도달했는지를 꾸준히 기록해왔다. 기술 블로그는 나의 사고 과정과 문제 해결 방식, 그리고 나의 마인드를 전달하는 최고의 도구가 되어주었다.

나의 블로그 글들은 단순한 결과물이 아닌, 과정의 기록이다. 업무를 할 때나 공부를 할 때 나는 내 생각과 과정들을 모두  노션(Notion)에 메모하면서 꼼꼼히 저장해둔다. 그리고 기술 블로그는 그 메모를 다듬어 올리는 형태로 작성한다.

이러한 방식으로 블로그를 작성하면, 나만의 사고 과정이 자연스럽게 드러나고, 단순한 기술 설명을 넘어 내가 어떤 개발자인지를 보여줄 수 있게 된다. 나의 끈기와 문제 해결 능력, 그리고 창의적인 접근 방식을 통해 기술 블로그가 나만의 색깔을 가지게 되는 것이다.

메인 카테고리 > 서브 카테고리 > 내용의 방식으로 나눠 정리하고있다.

 

또한 기술 블로그를 통해 나의 생각을 글로써 표현하는 법을 꾸준히 연습하려고 한다. 처음에는 문장 하나하나 적기가 되게 어색하고 힘들었는데 이제는 나의 생각을 자연스럽게 글로 표현할 수 있게 되었다. 좋은 개발자는 코드를 잘 짜는 것 뿐 아니라 자신의 생각을 글로 잘 표현할 수 있어야 하기에 나의 성장을 위해 기술 블로그로 글쓰기 연습을 하고 있다고 생각한다.

 

시니어 개발자

다음 주제로 시니어 개발자에 대해 이야기해보자. 시니어 개발자란 무엇일까? 내가 생각하는 시니어 개발자는 단순히 개발 실력만 뛰어난 것이 아니라, 많은 개발자들이 마주하는 다양한 고민들에 대해 자신만의 결론을 내리고 어느 정도 해답을 찾은 사람이다.

 

좋은 개발 문화를 어떻게 만들까? 후배 개발자를 어떻게 서포트할까? 풀스택 개발자란 무엇일까? 연차가 쌓이면서 개발자가 마주하는 고민은 단순히 코드를 어떻게 잘 짤 것인가에서 벗어나 더 넓은 범위로 확장된다. 나 역시 마찬가지다.

 

얼마 전 팀장님과 앞으로의 스터디 방향에 대해 이야기를 나누었는데, 이런 요청을 받았다. “이론 관련 스터디와는 별개로, 중급자 이상의 스터디를 종식님이 스터디 장으로서 주도해보고, 방향을 고민해 주세요.”

 

나는 이 주제에 분명히 자신이 있다. 현재 팀 내에서 가장 많은 경험과 배경지식을 가지고 있는 것도 나고, 팀원들이 믿고 따를 수 있는 것도 나라고 생각한다. 하지만 어떻게 스터디를 진행해야 팀원 모두에게 좋은 영향을 미칠 수 있을까? 다양한 고민을 해보았다.

 

현재 어느 정도 방향을 정리했는데, 내가 생각한 방식은 실제 업무에서 사용할 수 있는 주제를 선정하는 것이다. 예를 들어, Git Action을 활용해 노션을 자동으로 업데이트하거나, 회사의 테스트 도구에 시각적 회귀 테스트를 도입해보는 것이다. 3명으로 이루어진 스터디 조가 주제 선정, 디자인,기획, 개발을 모두 담당하여 프로젝트를 진행하고 발표하는 구조로, 스터디 장은 주제를 개선하거나 문제가 있을 때 약간의 팁을 주는 방식으로 서포트만 한다. 그리고 내가 따로 개발 중인 ‘프론트엔드 전체 테스트 환경 구축’ 개발이 종료된 이후 이를 주제로 앞으로의 스터디 방식을 함께 발표하는 것으로 생각하고 있다.

 

이 방식대로라면 팀원 모두가 만족하고, 회사에도 도움이 되는 긍정적인 결과를 얻을 수 있을 것이다. 하지만 현실은 그리 녹록지 않다. 회사에서 이러한 방식을 위해 따로 많은 시간을 주지는 않을것이며 본인이 담당하고 있는 일들도 분명히 존재할 것이다. 따라서 스터디의 목적을 회사의 업무와 별개로, 본인의 성장을 위한 활동으로 설득해야 하는 과제가 있다.

물론, 주제를 잘 선정해서 부문장님께 보고하고 공식 업무로 진행할 수도 있지만, 그렇게 되면 더 이상 스터디가 아닌 프로젝트가 되어버린다. 또한, 모든 개발자가 같은 열정으로 참여하지 않을 수도 있다. 워라밸을 중시하는 개발자도 있을 것이고, 이런 개발자들을 어떻게 스터디에 포함시킬지 고민해야 한다. 그들을 제외시키는 것이 맞을까? 아니면 참여하도록 동기부여할 방법을 찾아야 할까?

또한 다른 고민들로 팀 내 코드 리뷰 문화는 어떻게 해야 할까? 어떻게 해야 개발자들이 자유와 책임을 동시에 느끼도록 만들 수 있을까? 아마도 이러한 고민들은 나뿐만 아니라 리드급 개발자들이라면 한 번 쯤은 해봤을 것이라고 생각한다.

결국 내가 생각하는 시니어 개발자는 이러한 고민들을 이미 거쳐 자신만의 해답을 찾았거나, 문제에 직면했을 때 빠르게 답을 찾아내는 사람이다. 나는 지금 이 과정을 거치며 시니어 개발자로 성장하기 위한 길을 찾고 있다고 느낀다.

 

최근 근황

저번주부터 해서 현재 두 가지의 일을 하고 있다. 회사의 일 그리고 퇴근 후 다른 회사로 출근하여 하는 두 번째 일.

회사의 업무가 끝나고 난 뒤 밤, 매 주 일요일 두 번째 회사로 출근을 한다. 여기서 두 번째 회사는 마음에서 정한 사이드와 같은 느낌의 회사가 아니라 물리적으로 존재하는 실제 회사이다.

 

물론 두 개의 회사와 정식으로 계약을 맺고 출근을 하고있는 것은 아니다. 같이 창업을 준비하고 있는 친구 덕분에 엑셀러레이팅 회사의 스타트업용 사무실을 사용할 수 있게 되어 그 곳으로 출근하는 것이다.

 

작년 11월, 개인적으로 성장하고 싶은 욕심과 더 이상 부족한 점이 없었으면 좋겠다는 생각에 스스로와 하나의 약속을 정했다. 회사에서 야근을 하든, 늦게 퇴근하든 상관없이 최소 1시간은 개발 이론 공부를 하고 집에 가자는 결심이었다. 의외로 이 약속은 지키기 쉬웠으며 잘 지켜졌다.

 

올해 6~7월까지 이 약속을 꾸준히 지켜오며 늘 떠올린 생각은, 단순히 회사에서 조금 더 업무를 한다는 마음가짐으로 접근하면 크게 어려운 일이 아니라는 것이었다. 실제로 지인과의 약속이 있더라도 회사에서 늦게 끝난다고 말하면 자연스럽게 핑계가 되었고, 그래서 노력하지 않아도 이 약속은 쉽게 지켜졌다.

 

이런 생활을 하면서 수많은 책을 읽고, 자격증도 취득했으며, 기술 블로그도 작성하며 나의 부족한 점을 하나씩 채워나갔다. 하지만 어느 순간부터 이론 공부만으로는 더 이상 만족할 수 없다는 느낌이 들기 시작했다. 개발자에게 이론은 분명 중요한 요소다. 하지만 이론만 완벽하다고 해서 정말 훌륭한 개발자라고 할 수 있을까?

개인적인 생각으로는 답은 No다. 이론은 훌륭한 개발자가 되기 위한 필수 요소 중 하나일 뿐, 그것만으로 충분하지 않다. 훌륭한 개발자가 되려면 프로젝트를 큰 그림으로 그릴 수 있는 능력, 올바른 마인드셋, 그리고 다소 추상적이지만 무언가를 실질적으로 해낸 경험 등 다양한 요소들이 추가로 필요하다.

 

이런 이유로, 나는 더 나은 개발자가 되기 위해 남는 시간을 창업이라는 도전에 투자하기로 결심했다. 함께 프로젝트를 진행하고 있는 친구는 PM 겸 AI 개발자이자 웹 개발자로서 온전히 개발에 집중하고 있다.

그리고 나는 devOps, 백엔드, 웹 설계 및 조언, 그리고 앱 개발을 맡고 있으며, 회사에서 퇴근한 후에두 번째 사무실에서 개발을 하고 있다.

 

아직 이런 생활을 시작한 지 오래되지는 않았지만, 앞으로의 개발을 위한 큰 그림을 그리는 법을 연습하고 있다. 제품의 기획과 설계 단계에서 내가 회사 생활을 하며 경험하지 못했거나 경험하기 힘든 부분들을 직접 체험하고 있다. 물론, 스타트업에서 일하면서 어느 정도 경험했다고 할 수는 있지만, 스스로 100%의 책임과 결정을 내리는 것은 확실히 다른 차원의 경험이라고 생각한다.

 

흥미롭게도, 웹 개발은 내가 맡지 않는다. 웹 개발은 내가 가장 잘하는 분야이고 가장 효율적으로 일할 수 있는 영역일 것이다. 하지만 이번에는 새로운 도전을 위해 익숙한 부분을 과감히 내려놓았다. 그 이유는 함께 일하는 친구를 믿기 때문이다. 이 친구가 최소한의 조언과 프로젝트 관리를 해주기만 해도 최고의 결과물을 만들어낼 것이라 믿고 있다.

 

그래서 나는 실무에서 겪어본 적 없는 인스타그램 크롤러의 배포를 포함하여 모든 인프라를 AWS 클라우드 상에서 구축하기 위한 설계를 담당하고 있으며 전반적인 백엔드, DB 설계, 그리고 앱 개발까지 맡아 프로젝트를 진행하고 있다.

 

이러한 생활이 힘들지 않냐고 묻는다면, 힘들다는 것은 모르겠고 피곤하다는 답변을 할 것 같다. 하고 싶은 일을 그리고 이대로 하면 성장하는 것이 확실한 일을 하는 것은 생각보다 힘들지 않다. 오히려 함께 일하는 친구가 있어 일하는 순간에는 별다른 생각 없이 즐겁게 몰입하고 있는 것 같다. 또한, 한때 계속해서 팽팽하게 긴장하며 살다가 어느 순간 무너져서 번아웃이 왔던 경험이 있기에, 토요일 하루만큼은 개발을 아예 하지 않고 쉬는 날로 정해 피로를 풀거나 푹 쉬고 있다.

 

지금 진행 중인 이 프로젝트가 성공해서 CTO 자리를 맡게 될지, 아니면 쫄딱 망해 다른 기획이나 새로운 일을 찾아보게 될지, 또는 적당히 마무리하고 다시 이론 공부를 하며 내실을 다지게 될지, 그 결과는 알 수 없다. 하지만 어떤 엔딩을 맞이하든, 지금 하고 있는 이 순간이 재미있고 이 경험이 나의 앞날에 큰 도움이 될 것이라고 믿는다.

 

제품 이미지