Super 주니어 개발자

Career/Conference

Super 주니어 개발자

김 정 환 2022. 7. 31. 16:26

개발자 컨퍼런스라는 것을 처음으로 신청해서 참여했습니다. 입사하고 1년이 다 되어가는데, 취업을 열심히 준비할 때의 '개발자'와 지금 생각하는 '개발자'가 다르게 느껴습니다. 나태해진 건지 무뎌진 건지 모르겠지만 어떠한 동기가 필요했고 개발자 컨퍼런스만한게 없지 않을까 생각했습니다. 멋진 사람들을 보면 그렇게 되고 싶은 생각이 듭니다.

총 9명의 개발자가 9가지의 이야기를 들려주었습니다. 주니어 개발자로서 갖추어야 하는 마음과 태도를 충분하게 배울 수 있었습니다. 정말 저에게 필요했던 것을 찾은 기분이었습니다. 제가 가져온 키워드는 자동화, 코드리뷰, 회고 이렇게 3가지 였습니다. 자동화는 업무 능률을 향상시키고 노력 대비 좋은 성과를 낼 수 있다고 생각했습니다. 코드리뷰는 업무의 이해를 돕고 근본적인 '개발' 능력을 향상시키는 좋은 방법이라고 생각했습니다. 회고는 실수를 줄이는 좋은 방법이라고 생각했습니다.

위에서 3가지에 대해서 간략하게 적었지만, 저는 더 길게 적어보고 싶습니다. 9가지 이야기를 들으면서 기록한 내용을 정리해서 기록하겠습니다.

주니어 버릇 은퇴까지 간다.

1번째 이야기는 이 문장으로 요약됩니다. '너 자신을 알라' 자기 자신을 알아야 다음 단계로 나아갈 수 있습니다. 개발자의 능력을 지표로 알려주는 5각형 모형이 있다고 합니다. 한 번 해보면 좋을 것 같습니다. 자신이 어떤 사람인지 알게 되면, 어떤 환경에서 가장 높은 퍼포먼스를 낼 수 있는지 또는 내가 원하는 개발자가 되기 위해서 무엇이 필요한지 알 수 있습니다.

발표자는 몇 가지 좋은 방법을 제시해 주셨습니다.

회고하기
모르는 것은 모른다고 하고, 확실히 알고 가기
키워드 주워 담디
패기와 객기 구분하기
환경에 영향 받지 않기
한 번 실수한 것은 두 번 실수 하지 않기

이렇게 자신의 성장을 챙길 수 있습니다. 그러면 회사의 성과를 챙겨보겠습니다. 하는 일이 생산성이 높으면 굉장히 좋습니다. 그렇다면 생산성을 높이기 위해서는 어떻게 해야할까요.

귀찮은 일, 사람이 하면 실수할 일 등을 찾아서 해결
자동화 툴 만들기
레거시 걷어내기
CI/CD를 활용한 배포 및 테스트 자동화
슬랙과 지라 등 협업 관리 자동화
시스템 업데이트 자동화
사내 신기술 전파

성격 급한 주니어 개발자의 우당탕탕 생존기

2번째 이야기에서 가장 마음에 들었던 내용은 '왜?' 입니다. 무엇인가를 해야할 때는 항상 '왜?'라는 질문으로 시작해서 근거를 찾고 행동으로 옮기는 것입니다. 회사에서 일하다 보면, 항상 왜를 말하기 힘듭니다. 좋지 않게 보는 분들이 꽤있기 때문입니다. '그냥 해'라고 말하면 얼굴은 짜증이 나는 표정을 계속 보면 어느 순간에는 포기하게 되더라구요. 오늘을 기점으로 다시 돌아오려고 합니다. 사람 가려가면서 해야겠습니다.

1년 만에 리더가 된 내가 신입이었던 건에 대하여

3번째 이야기는 '무엇이든지 하자'라고 요약될 것 같습니다. 회사에서 무엇을 하면 성장할 수 있을까에 대해서 말씀해 주셨습니다. 발표자님은 몇 가지를 말씀해주셨습니다.

리팩토링 : 코드와 기능을 이해하는 최고의 방법이면서 서비스 효율을 향상시킬 수 있습니다. 그러나 회사는 리팩토링에 관심이 없습니다. 서비스의 기능만 수행되고 있으면 되기 때문에 새로 코드를 리팩토링을 요구하지 않습니다. 오히려 리팩토링을 했을 때에 문제가 일어나면 개발자 본인의 책임이 됩니다. 그럼에도 불구하고 리팩토링을 하면 관련 기술과 코드 이해도가 높아지는 것을 맞는 것 같습니다.
시스템 구성 : 어떤 소프트웨어를 도입하는 것도 시스템이지만 구성원이 합의하는 것도 시스템입니다. 코딩 컨벤션이나 아키텍쳐, 스타일 가이드 등을 만들어 놓으면 팀원들과 개발하기 좋은 환경이 만들어질 것 같습니다.
자동화 : 자동화를 하고 싶은 것을 찾아 봅시다. 보통 빌드 자동화나 배포 자동화를 생각할 수 있습니다. 자동화를 위해서 CI/CD 툴을 도입하는 것도 좋은 생각입니다.
공유 : 공유할 수 있는 공간이 있으면 좋습니다. 하는 일 또는 하고 싶은 일을 제시하고 의견을 물어볼 수 있으면 그 조직은 살아있다고 생각합니다. 구성원 간에 끊없는 상호작용은 그 조직을 더 유기적으로 성장시킬 수 있다고 생각합니다.

이직 잘하기

4번째 이야기는 '개발자로서의 가치관'으로 요약될 것 같습니다. 선택의 순간에 우리는 자신만의 기준을 두고 판단하여 선택을 하고 행동한다고 생각합니다. 그 기준은 아마 가치관이지 않을까 생각합니다. 개발자의 가치관은 코딩 스타일과 아키텍쳐, 조직 문화에 반영된다고 생각합니다. 그래서 회사는 각자의 인재상을 제시하고 있는 것은 아닐까요. 그래서 이 가치관을 만들었으면 좋겠다는 생각을 했습니다. 지금 생각해본 저의 '개발자로서의 가치관'은 '현재 상황을 해결하여 더 편한 상황으로 만드는 개발' 입니다. 크게는 이렇지만, 아키텍쳐와 코딩 스타일 같은 세부적인 부분에서는 아직 잘 모르겠습니다. 경험은 있지만 선택적으로 집중해서 고민해보지 않았습니다. 일과 공부를 하면서 '가치'를 염두해두고 생각해 보겠습니다.

존재감 한껏 부각시켜줄 소프트 스킬

5번째 이야기는 '개발 문화'로 요약될 것 같습니다. 문화라는 한 사회의 주요한 행동 양식이나 체계를 말합니다. 회사의 성장 방향에 맞는 개발 문화를 안착시키면, 그렇게 성장할 거라고 생각합니다. 꼭 회사가 아니더라도 흔히 좋은 개발자가 되기 위한 보편적인 개발 문화도 자리 잡아야 한다고 생각합니다. 발표를 들으면서 제가 저희 크루에 도입하고 싶은 개발 문화를 적어보겠습니다.

발표해보자 : 일단 발표 주제를 선정하고 발표 날짜를 잡아서 해보는 것입니다. 발등에 불이 떨어지면 어떻게든 하게 될 거라고 생각합니다. 그러면 스스로 자료를 찾아서 정리하고 공부를 할 수 있다고 생각합니다. 또한 은근슬쩍 성과로서 어필이 됩니다.
해결사가 되어보자 : 문제를 마주한 동료를 도와서 함께 해결하면 좋을 것 같습니다. 동료들 사이에서 평판을 올릴 수 있습니다. 그렇게 트러블 슈팅을 했으면 경험을 정리해서 공유하면 좋습니다. 해결하는 과정에서 동료와 논의된 내용도 있을 것입니다. 그 내용도 결론지어서 정리하면 좋습니다.
설득해보자 : 협업을 하다보면 설득을 해야할 경우가 생깁니다. 그럴 때에는 상대방에게 맞게 이야기를 재구성하여 말하는 것이 좋습니다. 그리고 항상 적절한 레퍼런스를 근거로 제시하여 자신의 의견이 충분한 이유가 있음을 보여주어야 합니다. 만약에 갈등 상황이 생길 것 같으면 서로의 공통점에 집중하는 것이 좋습니다. 공통점은 서로를 이해하는 하나의 통로이기 때문입니다.
팀 플레이어가 되어보자 : 팀에서 한 사람이 너무 잘해도 팀이 실패하면 실패한 것입니다. 따라서 팀 전체의 기량과 성과를 올리는 개발자가 되었으면 좋겠습니다. 동료가 잘하고 있는지 그냥 물어보기도 하고, 배운 기술을 공유하기도 하고, 커피도 마시며 근황 토크도 하면서 함께 성장하는 개발자가 되었으면 합니다.
그 외, 질문을 잘할 수 있는 문화, 공유를 잘할 수 있는 문화, 자신감을 올려주는 문화 등

마이스터고 개발자의 회사생활

6번째 이야기는 '코드 리뷰'로 요약될 것 같습니다. 이제 1년차가 되어가니 코드 리뷰가 중요한 것을 알게 되었습니다. 무슨 의도에서 코드를 추가하고 삭제했는지 알아야 코딩을 잘 할 수 있기 때문입니다. 코드리뷰를 하는 시스템에 대해서 저희 크루원들과 논의해서 새로운 문화로 안착시켜야 할 것 같습니다.

9개월 만에 이직한 신입 개발자가 있다?!

7번째 이야기는 '포트폴리오 정리'로 요약될 것 같습니다. 링크드인이나 노션 등 자신의 성과를 기록할 수 있는 곳에 회사에서의 성과나 프로젝트를 기록하는 것이 평소에 필요하다고 생각합니다. 자동화를 만들었거나 트러블슈팅 등 했던 내용을 기록하면 좋을 것 같습니다. 언제 누구에게서 연락이 모르고, 포르폴리오를 관리하면 자신이 얼마나 노력하고 잘했는지 볼 수 있기 때문입니다. 이 기회에 링크드인에서 쓸대없는 내용은 지우고 다시 관리해보려고 합니다. 그리고 노션에 대한 이용도 한 번 고려해 보겠습니다.

ML엔지니어의 대학 일기 아닌 개발 일기

8번째 이야기는 '지속적인 성장'으로 요약될 것 같습니다. 하고 싶은 것이 있어야 행동하고 성장한다고 생각합니다. 일에서만의 이야기가 아니라 삶에서도 필요한 부분이라고 생각합니다. 그래서 발표자님은 평소에 버킷 리스트를 작성하여 달성하고 계신다고 합니다. 버킷 리스트까지는 아니지만 하고 싶은 것을 적어보기로 했습니다. 저번에 다녀온 해시코프 후기와 오늘 컨퍼런스 후기를 블로그에 남기고 싶었습니다. 그래서 이렇게 하고 있네요.

1년차 개발자, ML ops 위에서 방향성을 고민하다

9번째 이야기는 '고민보다는 코딩'으로 요약될 것 같습니다. 발표자님이 하신 말중에 기억에 남는 말이 있습니다. '고민을 하면 고민이 늘고, 코딩을 하면 코딩이 는다' 참으로 재밌습니다. 저는 왜 고민을 했을까요. 실패를 두려워서 인지, 최고의 선택을 하기 위해서 인지, 손실을 최소한으로 하기 위해서 인지. 그런데 신기하게도 고민이 늘었고 막상 얻은 것은 없는 것 같습니다. 실패를 했으면, 성공을 위한 경우를 하나 줄렸을 텐데 말이죠. 이와 더불어, 다른 말씀도 해주셨습니다.

지금 물어보는 것이 나중에 물어보는 것보다 낫다.
함께 알아내는 것이 혼자 알아내는 것보다 낫다.
호기심을 가지는 것이 게으른 것보다 낫다.
일단 시도해보는 것이 고민하는 것보다 낫다.

마지막으로 기록하는 습관을 만들겠습니다. 아무것도 남기지 않는 것보다 복사 붙여넣기 만이라도 하는 것이 낫습니다.

이렇게 참으로 뜻 깊었던 Super 주니어 개발자 컨퍼런스를 요약해 보았습니다. 정말 총명하시고 유능하신 분들을 뵐 수 있어서 너무나 좋았습니다. 다음에 또 다시 기회가 있다면 언제든지 참여하여 생각을 서로 공유하고 싶습니다. 저도 주니어 개발자라는 말을 듣고 나중에는 시니어 개발자가 되고 싶습니다. 그러면 언제부터 주니어가 아닌 시니어라고 불릴 수 있을까요. 제가 생각하는 시니어는 책임을 질 수 있는 직책인 것 같습니다. 영향력이 있기 때문에 영향을 미치고 자신이 하는 것과 팀원들이 하는 것에 책임을 질 수 있는 사람이 되었을 때에 시니어가 되는 것이 아닐까 생각해 봅니다.