[회고] 작은 팀에서 주니어 개발자로 일하기

작은 팀에서 주니어 개발자로 일하기

 

 

시작하며

---

회사에서 1인 개발을 하고있는 3년차 백엔드 개발자이다. 2인 개발팀에서 1년간 일을 하다가 팀장님의 퇴사로 혼자 남게된지 얼마 안되었다. 

두명의 개발자로 구성된 작은 팀에서 웹 애플리케이션 서비스를 개발하고 운영하며 느낀점을 공유하고자 글을 적는다.

주요 레포 기여자... 가린 것은 팀장님... 

 

작은 팀에서 주니어로 개발자로 일한다는 것

---

성장

 

빠른 기술적 성장이 가능하다.

 

전 회사에서 20명이 넘는 대규모의 개발팀에서 주니어 개발자로서 일 할 때이다. 리더가 구현한 코어를 갖다 쓰고, 시니어가 정한 디자인에 맞추어, 비즈니스 로직을 구현하는 일에만 집중했다. 난제는 리더와 시니어가 해결하면 된다. 주니어는 비즈니스 로직 구현에만 집중해도 서비스는 잘만 돌아갔다. (대규모의 모든 팀이 그렇다는 것은 아니다. 나의 경우 SI 라는 배경이 있기도 했다.)

 

그러나, 작은 팀에서 이와 같이 했다간 서비스가 돌아가지 않을 것이다. 비즈니스 로직 뿐만 아니라 아키텍처, 디자인 패턴, 코어, 설정 및 구성, 디자인, 테스팅, 보안, 배포, 이외의 많은 것들을 모두 해야한다. 상황에 맞는 디자인 패턴을 사용하여 아키텍처를 구조화하고, 프레임워크의 동작 원리를 이해하여 구성을 설정하고, 새로운 것을 도입할 때 각각을 비교하여 분석하고, 테스팅 방법과 보안, 배포, 장애 대응까지 다양하고 딥한 영역을 분석하고 고민해야한다. 

 

자기 역할만 해도 벅찰 것 같지만 내가 맡은 영역이 아니라도 모두 알고 이해해야한다. 작은 팀일수록 팀원 한명의 부재는 큰 영향을 미친다. 장애가 발생했을 때 내가 맡지 않은 영역이라도 미리 알고 빠르고 유연하게 문제에 대처할 수 있어야한다.

 

이러한 점들을 보았을 때, 기술적으로 빠르게 성장할것 같지만 이것은 착각일 수 있다. 중요한 것은 빠르게 성장하는 것이 아니라, 올바른 방향으로 성장하는 것이다. 소규모의 팀에서는 내 소스가 아닌 다른 사람의 소스를 볼 기회와 피드백의 기회가 적다. 소규모의 팀은 시간과 비용이 부족한 경우가 대부분인데, 열악한 팀에서는 코드 리뷰조차 어려울 수 있다. 1인 개발의 경우 셀프 리뷰를 해야하는 상황이다. (혼자 PR하고 혼자 코멘트 달고 혼자 머지하는 것을 셀프 리뷰...라고 한다)

 

이는 소규모 팀에서 일하는 것의 가장 큰 어려움이었다. 올바른 방향으로 빠르게 성장하기 위해서는 자신이 옳은 방향으로 잘 나아가고 있는가 끊임없이 의심해야한다. 나의 경우 2인 개발이라는 점을 이용하여 주로 페어 프로그래밍을 하곤 했다. 1인 개발의 경우, 외부의 좋은 소스를 많이 보고, 많이 짜고, 많이 고민하는 법 밖에 없는 것 같다. 아직까지도 명쾌한 해결 방법을 찾지 못한 문제이기도 하다.

 

 

자유

 

기술 도입과 변경이 자유롭다.

 

대규모의 팀에서는 내가 하고싶은 일과 해야 할 일을 명확히 구분해야 한다. 내가 하고 싶은 일 일지라도 합리적인 이유를 들어 팀원 전부를 설득할 수 없다면 해서는 안되는 일이다.

 

소규모의 팀은 새롭고 다양한 기술을 좋아하는 사람이라면 적성에 맞다. 새로운 기술의 도입과 변경이 비교적 자유롭다. 자율성이 합의된 상황을 전제로, 언어와 프레임워크를 내맘대로 선택할 수 있고, 내가 좋아하는 라이브러리를 도입할 수 있다. 사용해보다가 프로젝트 성격에 맞지 않는다면 과감하게 다른 것으로 변경할 수도 있다. (물론 모든 결정에는 팀원간의 합의가 필요하다.) 

 

나의 팀의 경우 'Java 11 은 8과 어떤 점이 다를까요?' 라는 지나가는 말에 '써볼래요?' 하고 개발 중반즈음 과감하게 자바 버전을 업그레이드하기도 했다. 만약 공부하고 싶은 기술이 있을때는 도입을 제안해서 덕업일치(?)를 이룰 수 있다. 물론 이러한 의사결정에는 합리적인 이유와 설득, 동의가 필요하다. 소규모의 팀에서는 대규모의 팀보다 적은 노력과 비용으로 유연한 변경이 가능하다. 개발 방법론과 문화도 빠르게 적용이 가능하다. TDD나 애자일 같은 개발 방법론도 적은 인원이 빠르게 의사결정하여 적용할 수 있다. 

 

그러나 자유로운 만큼 책임이 따른다는 것을 명심해야 한다. 자율성 안에서 적절한 선택과 그에 따른 리스크를 고려해야한다.

 

 

경험

 

작은 팀의 개발자는 개발만 하지 않는다. 개발 외에 다양한 경험을 할 수 있다.

 

관리자가 있는 팀에서는 주로 관리자가 타 직군, 업체, 고객간의 커뮤니케이션을 담당한다. 그러면 개발자는 이미 정의된 비즈니스대로 주어진 일을 한다. 하지만 작은 팀에서는 개발자가 직접 비즈니스 결정을 맡거나 커뮤니케이션을 담당하는 일이 종종 있다. 비즈니스 기획자와 업무를 정의하기도 하고, 타 업체의 개발자와 협업을 하기도 한다. 나의 기술을 다른 사람이 이해하기 쉽게 말이나 문서로 녹여내어 설명하고, 그들과 소통하며 비즈니스를 정의한다.

 

소통은 개발자에게 있어 필수적인 스킬이다. 내 기술력을 바탕으로 나의 생각을 말 또는 문서로 이해하기 쉽게 표현해야한다. 다른 사람의 요구사항을 잘 이해할 수 있는 이해력과 소통력도 중요하다. 즉, 말하기, 듣기, 읽기, 글쓰기 모두 소통이라고 볼 수 있다. 나의 경우 비즈니스 기획자 또는 외부 업체와 협업하는 일이 많았다. (신입때 전화공포증이 있었는데 지금은 한결 나아졌다.) 

 

소규모 팀의 시니어 개발자는 경영 또한 책임질 수 있다. 하지만 주니어 개발자인 나는 경험이 없으므로 설명하지 않겠다.

 

 

맺으며

---

작은 팀이 다른 팀만큼의 비즈니스적 성과를 내려면 구성원의 많은 노력이 필요하다. 다양하고 많은 일을 깊이 있게 해야하므로 쉽지 않은 일이다. 가능하다면 체계 있고 영감을 받을 동료가 많은 큰 팀에서 일하는 것이 가장 좋다. 하지만 이미 자신이 처한 상황이라면 그 상황에서 할 수 있는 것은 다 해보되 얻을 수 있는 것은 다 얻길 바란다. 피할 수 없으면 즐겨라

 

작은 팀에서의 나의 경험은 값지고 좋은 경험이었다고 생각한다. 나는 운이 좋은 편이었는데, 같이 일했던 팀장님이 좋은 리더였다. 개발 철학에 대한 재밌는 이야기도 많이 해주었고, 페어 프로그래밍도 즐거웠다. 개발 외의 인간적인 이야기도 많이 나누었는데 인생에 있어 긍정적인 영향을 주었을 정도로 친밀했다. 작은 팀에서의 사수는 정말 중요하고 소중한 존재이다. 모든 주니어가 좋은 사수를 만났으면 좋겠다. 

 

이 글을 쓰는 본래 목적은 작은 팀의 주니어 개발자에게 공감과 응원이 되었으면 해서이다. 거의 1인 개발을 하면서 외로움도 느껴봤고, 협업에 대한 갈증을 느끼기도 했다. 그럴때마다 1인 개발자나 소규모 팀의 개발자를 찾아다녔다. 나와 비슷한 처지에 놓인 사람들이 있다는 존재 자체만으로도 공감과 위로를 받곤 했다. 비슷한 사람 사이의 연대감은 어려움을 견디는 데 큰 힘이 되기 때문이다. 

 

지금의 나는 성장할 수 있는 환경을 지키되 협업에 대한 갈증을 해소할 수 있는 방안을 찾는 중이다. 조금 더 즐기고, 잘 할 수 있는 방법을 찾아가고 있다.