Skip to main content

신입 웹프론트엔드 개발자 1개월 차 후기

· 18 min read
박서영

0. 들어가며​

 안녕하세요. 비브로스 웹프론트엔드팀 신입 개발자 박서영입니다. 😀 저는 현재 입사 5주차로 온보딩 프로그램을 진행 중입니다. 입사하기 전 새로운 환경(새로운 팀, 새로운 사람들, 새로운 기술 스택과 업무툴 등 )에 어떻게 적응해야 할 지 걱정이 많았었습니다. 하지만 제 걱정과 달리, 팀 협업 시스템과 기술 스택에 잘 녹아들 수 있었는데 바로 온보딩 프로그램 덕분이었다고 생각합니다.
저희 팀은 어떤 방식으로 온보딩을 진행하고 있는지 경험을 공유하고, 좋았던 점과 아쉬웠던 점에 대해서 함께 이야기 나눠보고자 합니다.

1. 좋았던 점​

1.png

 웹프론트엔드 팀의 서류합격자라면 과제 명세서와 함께 팀 소개 문서를 받게 됩니다. 이 문서에는 현재 웹프론트엔드팀이 어떤 프로젝트를 진행하고 있고, 어떤 기술 스택을 사용하고 있으며 어떤 워크툴을 활용해서 일을 하게 되는지, 팀 개발문화 전반에 대해 상세하게 작성되어있습니다. 많은 신입분들이 회사에 기대하는 점 중 하나가 ‘개발문화`와 이를 지탱하는 협업 시스템일 텐데요. 저는 이 문서를 읽고 나서, ‘꼭 회사에 합격에서 개발문화를 체험해보고 싶다’라고 다짐했던 기억이 납니다. 실제 입사를 하고 나서도 협업 시스템에 굉장한 만족감을 느꼈습니다.

데일리 스크럼​

 매일 오전, 스크럼을 통해 전날 한 일과 오늘 할 일 등 전체적인 업무 진행 상황을 공유합니다. 다른 팀원들이 어떤 작업을 하고 있고, 어떤 기술적 문제를 해결하고 있는지 들을 수 있어서 좋았습니다. 또 스크럼을 통해 스스로 업무 생산성을 체크하고 이를 기반으로 테스크 수행 기간을 점차 정확하게 산정할 수 있어서 도움이 많이 되었습니다.

코드 리뷰​

 2021 프로그래머스 데브 설문조사에 따르면, ‘현재 개발팀에 도입된 것이 무엇이 있느냐?’는 질문에 코드리뷰가 1위를, ‘현재 팀에 가장 도입하고 싶은 것이 무엇이냐’라는 질문에 코드리뷰가 3위를 차지했습니다. 결과에서 살펴볼 수 있듯이 현재 많은 개발팀들이 코드리뷰 시스템을 도입하거나 도입을 계획하고 있습니다. 이쯤되면 도대체 왜 모두가 코드리뷰를 하는 것일까 궁금해지는데요. 제가 온보딩 과정을 통해 느낀 코드리뷰의 장점은 ‘상향 평준화’라고 생각합니다.

2.png

이미지 출처

3.png

 한 달 동안 제가 받은 코드리뷰를 세어보니 총 134개였습니다. 변수 네이밍부터 성능 최적화까지 세밀하면서도 강도 높은 코드리뷰를 경험할 수 있었습니다. 사실 면접 때 함수형 프로그래밍을 지향한다고 말했지만, 외부 상태를 변경하는 함수를 짜거나 인자로 전달된 데이터를 직접 변경하는 등 다소 부끄러운 순간들도 있었습니다. 그동안 ‘작동만 하면 되는 코드’를 짰다면 이제는 ‘준수하게 작동하는’ 코드를 짜야 하는 주니어 개발자가 되었음을 실감했던 것 같습니다.

받았던 코드리뷰 중 하나를 소개하자면,

4.png

이미지 출처

5.png

 두 배열의 차집합을 구하는 상황에서
const difference = array1.filter(a⇒array2.includes(a));
를 조건 반사하듯이 썼다가 시간복잡도에 대한 피드백을 받았었습니다. 업무시간 동안 해결하지 못해서, 퇴근하고 예제코드를 만들어가 알고리즘에 관심 있는 주니어분들과 함께 토론했었던 기억이 납니다. 이렇듯 코드리뷰를 통해 코드를 작성하기 전에 한 번 더 고민하고, 고민을 해결하기 위해 좀 더 공부하는 등 선순환 구조가 형성될 수 있다고 보입니다.

 혹시 이 글을 보고 계시는 분들 중에서, 시간복잡도를 고려하여 효율적으로 차집합을 구하는 코드가 떠오른 분이 계신다면 예제코드를 토글로 추가해놓았으니 댓글로 남겨주셔도 좋을 것 같습니다 🙆‍♂️

  • 예제 코드

    //4명의 플레이어가 있습니다. winners라는 변수에는 우승한 플레이어들의 id 번호가 담겨있습니다.
    //이기지 않은 플레이어들을 반환하는 코드를 작성해주세요.

    const players= [
      {
        id: 1,
        name:'cat'
      },
      {
        id: 2,
        name:'dog'
      },
      {
        id:3,
        name:'sheep'
      },
      {
        id:4,
        name: 'mouse'
      }
    ]

    const winners = [ 1,2 ];

    //const others =  players.filter(e=> !winners.includes(e.id));🙅‍♂️
    const others =  "...코드를 작성해보세요.... 🙆🏻‍♀️";

    //기대값
    console.log(others);
    [
      { id: 3, name: 'sheep' },
      { id: 4, name: 'mouse' }
    ]


webstorm​

6.png

 팀 워크툴 중 제일 적응하기 어려웠던 것은 webstorm이었습니다. 아무래도 기존에 사용하던 에디터와 단축키나 동작 방식이 미묘하게 달라서 손가락이 적응하는 데 시간이 걸렸던 것 같습니다. 아직 어색한 부분이 있어, 명령어가 적힌 메모장을 띄워놓고 작업을 하고 있는데요.

 먼저 webstorm은 어색한 문법을 교정해주고 타입을 추론해주는 기능이 있습니다. 여기서 어색한 문법이란 자바스크립트 뿐만 아니라 영어도 포함하고 있는데, 오타 때문에 에러와 몇 시간 동안 씨름했던 경험이 있다면 webstorm 사용을 적극적으로 추천해드리고 싶습니다.

 또 webstorm은 코드 리뷰툴과도 궁합이 알맞습니다. 그동안 코드 리뷰를 받으면, 한쪽 모니터에 github pr 댓글을, 다른 한쪽 모니터에 에디터를 켜두고 고개를 돌려가며 비교했었습니다. 그러나 지금은 webstorm과 코드 리뷰 툴을 연동해서, 팀원이 남긴 리뷰가 정확히 몇 번째 줄에 관한 리뷰인지 에디터 내에서 확인하고, 반영한 리뷰는 이모티콘으로 꼼꼼히 표시해서 좀 더 수월하게 코드리뷰 작업을 할 수 있었습니다.

7.png

8.png

9.png

이미지 출처

angular​

 angular를 매니악하게 파시는 분들을 종종 봤기 때문에 호기심이 생기다가도, 러닝 커브가 부담스러워 선뜻 도전하지 못했었습니다. 다행히 온보딩 과정 덕분에 angular에 소프트랜딩할 수 있었습니다. 일단 러닝 커브가 높다는 소문은 사실이었습니다. angular는 프레임워크고, 프레임워크에서는 프로그래밍 규칙들이 정해져 있으며, 개발자는 그것을 익혀야 합니다. 또 angular가 워낙 많은 기능을 지원하다 보니 배워야 할 양이 정말 많습니다. 다만 규칙을 기반으로 코드를 짜기 때문에, 누가 작성하든 비슷한 결의 코드가 나올 것이고 이는 프로젝트의 통일성이나 유지보수 측면에서 유리할 수 있겠다는 생각이 들었습니다.

observable​

 observable을 설명할 때 ‘구독’과 ‘게시’라는 단어가 자주 등장하는데 저는 수도꼭지로 설명하는 게 좀 더 이해하기 쉬웠던 것 같습니다. promise가 값을 한 번 반환하고 끝이라면 observable은 수도꼭지를 틀어놓은 것처럼 pipe를 타고 값들이 계속 흘러나오게 됩니다. 문제는 흘러나오는 값들을 다룰 수 있는 메서드들을 따로 배워야 하고, 구독이 끝나면 구독을 취소해서 수도꼭지를 잠가주어야 하는 사실이 이 친구를 머리로 이해하는 것과 별개로 받아들이기가 어려웠습니다.

 observable의 편리함에 의문을 품던 시기를 지나 정말 제대로 배워보고 싶다는 생각이 든 건 온보딩 3주차 쯤이었던것 같습니다. 영어를 배울 때 귀가 트인다는 표현처럼, 모니터 너머 모바일 팀의 대화 내용이 점점 들리기 시작했습니다. 또 angular와 객체지향 프로그래밍, rxjs와 반응형 프로그래밍 기법 등 온보딩 과정을 진행하면서 자연스럽게 다양한 프로그래밍 기법에 관심을 가지게 되었습니다. 여러 프로그래밍 기법들이 상호배타적인 관계가 아니기 때문에 angular와 rxjs을 열심히 학습하면 저희 팀 미션인 개인 성장 측면에서도 많은 도움이 되겠다는 확신이 들었습니다. 그래서 현재는 이 스택들에 흥미를 갖고 공부하고 있습니다.

공식문서로 학습하는 습관​

 기술 온보딩을 진행하면서 가장 큰 수확이라고 하면 저는 공식문서로 학습하는 습관을 뽑고 싶습니다. ‘localStorage를 활용하여 로그인 기능’을 react로 구현해야 하는 상황이 있다고 가정해보겠습니다. ‘localStorage, 로그인, react’만 검색해도 관련 블로그 글들이 쏟아집니다. 수많은 사람들이 관련 에러와 덧붙일 수 있는 추가 기능까지 세세하게 작성해놨습니다. 혹여 이해하기 어려울까 봐 코드 하나하나 주석도 달려있습니다. 너무나 많은 예제 코드 덕에 개념을 이해하기 전에 복사 붙여넣기만으로도 기능을 충분히 구현할 수 있을 것입니다.

 처음에 angular가 어렵게 느껴졌던 지점이 바로 이것이었습니다. 검색했는데 블로그 글이 나오지 않았습니다. 기능 구현에 관한 글은 고사하고 개념에 관해 서술한 글마저 찾기 어려울 때도 있었습니다. 그러다 보니 공식문서를 파고들면서 개념을 이해해야 했습니다. 지나고 보니 개발자로서 앞으로 새로운 기술을 흡수하는 데 있어 꼭 필요한 습관이었다고 생각합니다. 누가 먹기 좋게 썰어놓은 글만 주워 먹는 게 아니라, 제가 먼저 기술들을 찍어 먹어보고 다른 사람들에게 소개할 수 있는 개발자가 되기 위해서 지금처럼 공식문서를 통해 학습하는 습관을 꾸준히 길러나가려고 합니다.

2. 아쉬웠던 점​

컨벤션 업데이트​

 angular 튜토리얼이 best practice가 아니고(다른 팀원분의 표현을 빌리자면), 병드민 레파지토리에 레거시가 남아있고, 컨벤션 문서가 업데이트되지 않아서 이 사이에서 종종 헷갈렸던 경우들이 있었습니다. 이 중에 가장 빨리 바꿀 수 있는 게 컨벤션 문서 업데이트로 보이는데 기회가 된다면 코드리뷰 과정에서 메모해두었던 컨벤션들을 문서에 반영하고 싶습니다.

리뷰어 태그​

 현재 코드를 푸쉬하면, 리뷰가 자동으로 생성되고, 리뷰어가 자동으로 할당됩니다. 여기서 한 발자국 더 나아가 슬랙이나 잔디에서 리뷰어가 태그되는 기능을 추가하면 좋겠다는 생각이 들었습니다. 해당 기능을 도입하면, 신입 입장에서 팀원들을 직접 태그해야 하는 부담감을 해소할 수 있고, 팀원 입장에서 하루에 대강 5개~10개 정도 태그하는 메시지를 절약할 수 있다고 생각됩니다.

3. 마치며​

 제가 입사하고 얼마 지나지 않아 사무실 모니터 암이 전부 교체되었습니다. 모니터 암 1구가 편할지 2구가 편할지 비교하고 몇몇 분들 데스크에 모니터 암을 미리 설치해서 체험 후기를 받아보는 등 아주 신중하게 바꿨던 것으로 기억합니다. 일련의 교체 과정을 지켜보면서, 지금 프론트엔드팀에서 사용하고 있는 업무 툴과 협업 시스템들 또한 정착되기까지 얼마나 많은 실험과 토론을 거쳤을지 팀원들의 수고를 조금이나마 짐작할 수 있었습니다. 개발문화가 자리 잡은 팀에 들어온 만큼, 남은 온보딩 과정도 성실히 수행해서 저 또한 다른 팀원에게 도움이 되고 저희 팀의 개발문화 발전에 기여하고 싶습니다.

💡 🚀 우리팀이 일하는 방법! 👉🏻 비브로스 웹프론트엔드팀 👈🏻

비브로스