주니어 개발자의 개발문화 변화시키기(Part. 1)

현재 회사에 입사한지 어느덧 1년이 넘어가고 있는 주니어 개발자입니다. 시간이 참 빠른 것 같습니다..

 

저는 재직 중인 회사에서 백엔드 개발자로 업무를 진행하는 도중 시니어개발자 분들이 퇴사를 하시면서 주니어끼리 업무를 하는 시간이 꽤나 길어졌습니다. 테크리드가 없다는 사실은 뼈아픈 일이였고 최근들어 많은것을 느껴서 팀 내 개발문화를 변화시키고 싶은 결심을 하게되었습니다.

 

비슷한 상황에 놓이신 분들을 위해 저의 개발문화 적용과정과 생각들을 공유드리려고 합니다!!

 

미니언즈는 주니어 개발자와 이미지가 비슷하다고 생각해서 넣어봤습니다 ㅎㅎ

활기찬 주니어 개발자?..

 

왜 개발문화를 변화시키고 싶은 생각이 들었나??

 

 

첫 시작은 우아한 테크세미나에서 '어느 날 시니어가 사라졌다'라는 발표 영상을 보게 되었는데 시니어 없이 주니어끼리 개발문화를 정착시키고 만들어가는 과정에 대한 소개였습니다.

 

저희 부서 또한 시니어 없이 주니어개발자만 15명이고 PO님은 프로젝트에 대한 총괄 관리만 해주시는 상황이어서 많은 부분 공감이 갔습니다. 테크리드가 없는 상황에서 그나마 남아있던 개발문화도 체계 없이 흘러가고 있는 중이었습니다.

 

이런 상황에 염증을 느끼고 있던 참이었고 MSA 프로젝트를 진행하다 보니 각자 맡은 도메인에 대해서는 명확히 파악하고 있지만 다른 도메인 로직이나 전체적인 프로세스, K8S 관리 등 다양한 정보에 대한 공유와 소통이 명확히 이루어지지 않고 있었습니다.

 

이렇듯 현재 상황을 변화시켜야 한다는 것을 느끼고 있던 시점이어서 더욱 관심이 갔습니다. 개인적으로 성찰하게 되는 부분들도 많았고 성공경험을 본받아 즉시 행동하기로 결심했습니다.

 

개발문화를 변화시키기 위한 계획!!

세미나에서 본 영상을 참고삼아 KPT회고, 테크스펙, 페어프로그래밍에 대한 개념을 부서 상황에 맞게 재정립했습니다.

(위 개념에 대한 설명은 이 글에서 설명하기엔 너무 방대하므로 궁금하신 분들은 찾아보시면 좋을 것 같습니다!)

 

또한 뱅크샐러드, 오늘의집에서는 분기별로 FIT-IT-WEEK를 진행하며 버그, 문서화, 리팩토링, 테스트 코드 등등 미뤄왔던 기술부채 작업을 해결해 나가는 것을 보고 이것 또한 적용하고 싶었습니다.

 

현재 어느 정도 규모가 있는 이커머스 프로젝트를 진행하고 있다 보니 여러 가지 이벤트/기획전을 자주 시도하고 있어 이에 따라 신규 개발요청도 지속적으로 들어오는 편입니다. 또한 도메인별로 정/부가 존재하지만 각자 맡고 있는 도메인이 2~3개씩 있어 주요 트러블슈팅과 신규개발은 사실상 각자 진행해야 하는 상황입니다.

 

이러한 이유 때문에 현재로서는 분기별로 일주일 동안 모든 작업을 미뤄두고 FIT-IT-WEEK 작업을 진행하는 것은 어렵다고 생각했고 2주 ~ 한 달 사이 간격으로 하루 정도라도 이러한 시간을 가지면 어떨까 생각했습니다.

 

1. FIT-IT-WEEK를 위한 새로운 프로젝트를 개설하여 지정된 날짜마다 진행

2. 주간 태스크 작업이 일찍 끝난 사람은 FIT-IT-WEEK에 있는 태스크를 당겨와서 진행

 

위와 같이 여러 선택지를 작성해 다양한 시도를 해볼 수 있도록 예시를 만들었고 다른 개발문화들도 동일한 방식으로 정리했습니다. 추후에도 지속적인 점검을 통해 능동적으로 변화시켜 다른 좋은 문화들을 추가해보기도 하면서 점차 개선해 나갈 생각입니다.

 

팀원들과 첫 공유!!

두근두근..

더불어 현재 팀 문화에 대한 논의거리도 함께 적어 팀원들과 공유하기 위한 준비를 마쳤습니다.

 

처음 몇몇 분들에게 공유해 본 결과 모두가 긍정적인 반응을 보였고 용기를 얻어 팀 전체에 링크를 공유했습니다.

 

떨리는 마음으로 공유했고 다행히 모든 팀원들이 이러한 문화를 원하고 있었다는 것을 알았습니다!!

 

개발 문화 선호도 투표 결과

 

무언가 이루어지고 있다는 생각에 왠지 모르게 기분이 좋아졌었습니다 ㅎㅎ 기쁜 마음으로 구글폼을 만들어 어떤 개발문화를 가장 먼저 정착시킬지에 대한 투표를 부탁드렸습니다.

 

투표는 중복으로 선택할 수 있도록 진행했고 위에 보이는 사진과 같이 가장 많은 투표를 받은 건 테크스펙이었습니다.(휴가를 갔다 오신 3분도 개인적으로 투표를 받았는데 1등은 변화가 없었습니다!!)

 

팀 내에서 위키를 사용하고 있긴 하지만 문서화에 대한 정형화된 형식도 없고 각자 필요에 따라 혹은 필요한 상황이 생기면 그때그때 문서화를 진행하다 보니(문서의 MSA화?..) 복잡하기도 하고 정작 필요한 정보가 없는 경우도 잦았습니다ㅠ..

 

모두가 이런 경험을 해본 덕에 문서화와 연관되어 있는 테크스펙이 투표수 1등을 차지한 것 같습니다.

 

추가 의견으로는 각 도메인별로 swagger 링크에 접속해 API 명세서를 확인하는 것이 아닌 통합적으로 확인하고 싶으신 것 같아(저희는 swagger + springDocs를 쓰고 있습니다.) 앞으로 해당 부분을 해결하기위해 고심해봐야 할 것 같습니다.

 

마지막으로 부서 내 전체 공유!!

 

한가지 우려되었던 점은 혹시나 개발팀이 진행하려는 일들이 현재 상황에 부정적인 영향을 끼칠까 걱정되기도 하고 테크스펙을 진행하면 산출한 마일스톤도 전체적으로 공유해야 하니 PO님 그리고 저희와 자주 협업하는 부서들과 공유해야 하는 과정이 필요하다고 느껴졌습니다.

 

때문에 현재 팀 내 개발문화에 대한 애로사항과 새로운 개발문화를 정착시키고 싶은 이유 그리고 앞선 상황을 정리해서 자료를 만들어 발표를 진행했고 무사히 마칠 수 있었습니다.

 

느낀 점

 

개인이 발전하기 위해서는 퇴근하고 개인공부를 하는 것도 중요하지만 아무래도 직장인은 하루의 대부분의 시간을 차지하고 있는 회사 내의 환경이 굉장히 중요하다는 생각을 하고 있습니다. 이렇게 회사에서도 본인이 추구하는 열정과 욕심을 적극 활용해 팀과 같이 성장하면서 긍정적인 영향을 끼칠 수 있는 개발자란 직업은 참 좋은 것 같습니다.

 

이 글을 보시는 분들도 회사 내에 불만이 있거나 마음에 안 드는 상황이 지속될 경우 용기를 내어 조심스럽게 말해보는 건 어떨까요??

 

저는 아무것도 안 변하겠지 라는 생각과 누군가 해결해 주기만을 원했던 사람이었던 것 같습니다. 결과를 두려워하지 말고 먼저 용기를 내어 마음속에 담아두고 있던 말과 함께 행동한다면 긍정적인 효과를 가져오는 것 같습니다. 가만히 있는다면 아무런 일도 일어나지 않으니까요!!

 

앞으로의 계획

언제부터인지는 모르겠지만 꽤나 예전부터 회사에서 업무를 하면서 더 효율적으로 일하며 발전할 수 있는 방법이 없을까?? 에 대한 생각이 머릿속에 자리 잡고 있었습니다.

 

머릿속에 오랫동안 자리 잡고 있는 생각은 그만큼 많은 고민을 하며 갈망하고 원한다는 뜻이라고 생각합니다. 이를 좀 더 빠르게 눈치채고 행동하는 것도 중요하다고 느꼈습니다.

 

 

결론

두서없이 말이 많았지만 어쨌든 추후에 다시 개발문화 적용기에 대한 후기글을 써보려고 합니다.

 

좋은 개발 문화를 만들어 금방 적용 할 수 있도록 열심히 노력해 모두가 성장할 수 있는 좋은 환경을 만들어 보겠습니다!!