주니어 개발자가 팀에서 성장하는 방법 - (1)

이 시리즈를 통해 회사에 입사하고 2년 반동안 겪은 다양한 경험들을 바탕으로 성장할 수 있는 방법들을 공유해보는 시간을 가져보고자 합니다.

 

저와 같은 주니어 개발자 혹은 취업을 준비하고 있는 취업 준비생 분들에게 조금이나마 도움이 됐으면 좋겠다는 제 생각을 공유하는 것이니 열린 마음으로 읽어주시면 감사하겠습니다 ㅎㅎ

1. 해보고 질문하자. 물어보자. 

최근 다양한 IT 매체에서 '주니어 개발자는 질문을 많이 해야된다'는 이야기를 간접적으로 많이 보고 들은 것 같습니다. 하지만 무엇을 질문하는가에 대한 이야기는 구체적으로 안해준다는 것이 굉장히 아이러니 했습니다.

 

아래 질문 예시를 볼까요?

A 사원:  팀장님. 프로젝트를 git에서 pull 받은 뒤 로컬 환경에서 실행하려 하는데 빌드에서 충돌이 나서 실행이 안됩니다. 혹시 어떻게 해결하는지 아시나요?

B 사원: 팀장님. 프로젝트를 git에서 pull 받은 뒤 로컬 환경에서 실행하고자 하는데 빌드간 충돌이 발생해 실행이 안되고 있습니다. 
확인해 봤을 땐 IDE 초기 설정이 문제인 것 같은데 혹시 해당 프로젝트 실행간 필요한 설정이 별도로 있는지 확인 가능하실까요?

C 사원: 팀장님. 프로젝트를 git에서 pull 받은 뒤 로컬 환경에서 실행하는 경우 정상 실행되지 않는 문제가 있는 것 같습니다.
혹시 팀 내에 이슈 관련 이력들이 공유되고 있을까요? 공유되고 있다면 어디서 확인할 수 있는지 알려주시면 감사하겠습니다. 

 

여러분이 팀장이라면 세 명의 사원들 중 어떤 사원의 질문이 가장 마음에 드시나요? 

 

저라면 답변을 가장 짧게 할 수 있는 질문을 한 사람이 가장 마음에 들 것 같습니다.

A에게 하는 답변: ~는 확인해 보셨나요?
B에게 하는 답변: IDE 화면 캡쳐해 공유 후, 혹시 이것과 차이점이 있으실까요?
C에게 하는 답변(이력이 없을 경우): 이력 찾아본 뒤 링크 공유. 
C에게 하는 답변(이력이 있을 경우): 이력은 따로 관리하지 않습니다. 혹시 ~는 확인해 보셨나요?

 

이력이 잘 관리되고 있는 팀에서는 C 사원의 답변이, 그렇지 않을 경우엔 혼자서 어느정도 원인을 파악해 확인해봐야 될 부분을 좁혀준 B 사원의 질문이 가장 마음에 들겠네요.

 

다시 주제로 돌아가서, 어떤 상황에서건 혼자서 해보고 질문하는 것은 매우 중요한 요소입니다. 이것은 질문하는 사람의 시간을 뺏는 것을 최소화하며 모르는 부분을 찾아 해결하는 능력을 향상시킬 수 있기 때문입니다.

 

'나 열심히 찾아봤는데 아직 잘 모르겠어... 이것까진 생각해봤는데 도와줘..'가 질문을 읽은 사람에게 느껴지는 질문이 가장 좋은 질문이라고 생각합니다. 

 

30분은 찾아보자

그렇다고 3~4시간, 하루 이틀씩 하나의 문제를 가지고 끙끙 앓을 필요는 없습니다. 중요한 것은 질문하기 전 고민을 해 봤는가이지 시간적인 노력이 아니기 때문입니다. 

 

따라서 일정 시간을 정하고, 그 시간이 넘어서도 잘 모르겠으면 질문을 해 문제를 해결하는 것을 권장드립니다. 

 

제가 정한 규칙은 30분입니다. 2년간의 축척된 삽질을 바탕으로 통계를 내 본 결과, 30분 정도 찾아보면 내가 해결할 수 있는 문제인지 파악할 수 있는 최소 시간이었음을 깨달았기 때문이죠.

 

물론 이 시간은 온전히 제 경험을 통한 저만의 의견입니다. 하지만, 질문을 하기전 혼자 고민해보는 시간의 마지노선을 정하는 것을 추천드립니다.

 

2. 하기 전에 물어보자

혼자서 개발하실 경우 큰 문제는 없겠지만 팀원들과 함께 업무를 할 경우에는 무조건 질문하시는 것을 추천드립니다. 

 

개발자라는 직업은 문제 해결을 하는 직업이기 때문에 하나의 논제에도 다양한 해결 방안이 나오기 마련입니다.  코드 리뷰 문화가 잘 자리잡은 팀에서도 작은 개발 단위인 PR(Pull Request)에서조차 여러 의견이 나올 수 있습니다.

 

아래 예시를 봐볼까요? 

A 사원: 파일 업/다운로드 기능 개선건 PR 올렸습니다.
B 대리: 네 확인해 볼게요~ (확인 중) A 사원님. 파일 확장자나 파일 다운로드 제한 기능 같은게 없는 것 같은데 이유를 알 수 있을까요? 그리고 지금까진 사내 OBS를 써왔는데 트래픽이 많아져서 클라우드 연동해서 쓰기로 어제 결정났거든요. 이런 것들 고려해서 다시 PR 올려주세요~ (PR Close)
A 사원:  ... (타닥타닥) 

오늘 결론냈던 내용이 고객 요청으로 인해 요구사항이 변경되었을 수 있고, 내가 고려하지 못한 부분까지 다른 팀원들이 생각할 수 있기 때문에 재작업을 하지 않기 위해선 코드를 구현하기 전 다시 한 번 구체적인 논의를 진행 후 작업을 진행하시는 것을 권장드립니다. 

 

이런 논의를 자주 하다보면 함께 일하는 팀원의 개발 스타일이나 사고를 알 수 있어 점차 긍정적인 방향으로  업무 처리를 진행할 수 있습니다. 주니어 개발자라면 대부분이 본인보다 높은 경력을 가지고 있을 것이기 때문에 이러한 논의에서 배울 수 있는 점이 매우 많으니 작업 이전에 'B 대리님. 코드 구현 이전에 고려한 내용을 정리해 봤습니다. 이런 방향으로 구현할 계획인데 보완할 점이나 고려해야할 부분이 추가로 있을까요?'라고 한 번 물어보세요.

 

3. 신기술. 그걸 도입해서 얻는 이점이 뭔데?

MSA, AI, DDD, 헥사고널 아키텍쳐 등 다양한 개념들이 쓰나미처럼 몰려오고 있습니다. 개발 실력 향상을 추구하는 주니어 개발자에게 있어 이러한 기술들은 굉장히 해보고 싶고, 구미가 당길법한 것들입니다. 이러한 것들을 도입해보자! 제안해본 분들도 있을 것이라 생각됩니다.

 

어떤 답변을 받았었나요? 부정적이거나 흐지부지 끝난 경우 많았었나요? 혹은, 다음과 같은 질문을 받아보셨나요?

 

'이걸 도입하면 얻는 이점이 뭐죠?'

 

신기술 도입에는 사실 숨겨진 이면이 있습니다. 공수라고 하는 괴물이지요. 신기술을 공부하고 기존 시스템에 도입하는 그 긴 시간동안 팀은 별도의 성과를 내야 합니다. 왜냐면 회사니까요.

 

회사 입장에서는 신기술을 도입하건 1990년대 java 6을 도입하건 시스템이 개발되어 수익을 얻는 것에 더 관심을 많이 가질 것입니다.

들인 노력에 비해 기대 효과가 크지 않은 것들에 대해 시간과 노력을 투자하는 것은 옳지 않다고 생각하겠지요. 

 

만약 도입하고 싶거나 해보고 싶은 것들이 있다면 팀에서 공수를 들여야 하는 합당한 이유들을 준비하거나 사이드 프로젝트로 공부하시는 것을 추천드립니다. 개발자이기 이전에 월급을 받는 회사원이라는 점 명심하세요.

 

 

4. 몰라도 자신있게 의견을 말하자. 고집은 부리지 말고..

사실 생각보다 팀에서 주니어에게 바라는 것은 크게 없습니다. 지금 당장 시스템을 개선한다던지 신규 프로젝트를 할거면 경력 있는 개발자를 채용하겠죠. 그럼 왜 신입, 주니어를 채용할까요? 

 

제가 생각하기엔 두 가지가 있습니다. 그것은 바로 안정성을 흔드는 열정과 아직 열려있는 성장 가능성입니다.

팀에 열정을 불어넣는 사람이 된다면 지금 당장 팀에 도움이 되지 않아도 팀원으로서 팀에 이바지 할 수 있지 않을까요?

 

따라서 최대한 업무에 적극적으로 참여하고 자신있게 의견을 제안하고 말해봅시다. 모르는게 있으면 '제가 잘 몰라서 그러는데 이건 뭔가요?' 자신있게 궁금해 하세요.

 

몰라도 괜찮습니다. 잠깐 부끄러운 대신 그 지식은 부끄러운 만큼 오래 갈테니까요.

 

 

오늘은 개발적인 것보다는 마음가짐에 대해 이야기 해봤습니다. 사실 이 모든 이야기는 제가 신입때 경험했던 것들을 바탕으로 글을 작성한 것이니 저보다 뛰어나신 분들은 '뭐 당연한 소리를 글로 쓰고 있어' 라는 생각을 하실 수도 있습니다. 

 

 

근데... 팀원들은 본인에 대해 어떻게 생각할지 모르잖아요?
항상 겸손해야 합니다

 

 

2부에서는 지금 쓴 내용을 토대로 2년 반동안 어떻게 성장하고 있는지 조금 더 구체적으로 작성해 보겠습니다. 아직 햇병아리지만 귀엽게 봐주셨으면 감사하겠습니다.

 

감사합니다.