본문 바로가기
휴게소

9개월 차 프론트엔드 개발자 회고

by Vintz 2022. 8. 8.
반응형

지난 회고에 이어 3개월이 지났다. 이번 회고는 다른 시기와 달리 더 보고, 듣고, 배우고, 느꼈던 것들이 많았다.

개발자 커뮤니티

이제는 커다란 커뮤니티가 된 테오의 프론트엔드 오픈채팅방은 다양하고 많은 질문들과 대답들이 오고간다. 뛰어난 분들이 많아서 대화를 보는 것만으로도 도움이 될 때가 많다. 그 외에도 컨퍼런스나 해커톤, 좋은 블로그 글 등 유용한 정보들을 공유 해주어서 주변 개발자 지인들에게도 추천하고 있다. 요즘은 대화가 많이 쌓여있을 때는 못볼 때도 있지만 틈틈이 출근길이나 퇴근길에 보려고 노력하고 있다.

 

그리고 그 덕분에 인프런 네트워킹 데이 행사에도 참여할 수 있었다. 프론트엔드 개발자들이 오프라인으로 모여 연사도 듣고, 피자와 맥주를 마시면서 대화도 나누는 네트워킹 행사였다. 걱정했던 것과 달리 어색했던 분위기도 금방 풀렸고, 각자 다양한 곳에서 일하는 개발자들의 이야기를 듣는 게 정말 재밌었다.

행사 자체도 인프런측에서 준비를 잘 해주셨다. [출처 - https://www.inflearn.com/pages/midnight-fe]

행사에서 만남을 갖고 난 후에 네트워킹 데이 단톡방이 생겼다. 여기서도 좋은 정보들과 글들을 공유한다. 이때 나는 '커뮤니티를 통해 정보를 습득하는 것과 혼자 공부하고 알아보는 것, 이 둘의 격차가 생각보다 클 수 있겠구나'라는 생각을 하게 됐다. 개인적으로 말로 하는 것보다 글로 표현하는 것을 더 좋아하는데, 이 행사를 통해서 내 부족한 소프트 스킬도 키울 수 있었던 것 같다.

커피챗과 테크니컬 라이팅

우연한 기회로 라인의 개발자이신 유동균님과 커피챗을 하게 되었다. 30분으로 잡혀있던 커피챗이 1시간이 조금 넘도록 이어졌는데, 사실 몇 시간 더 하고 싶었다. 신입의 시점이 아닌 시니어 시점의 고민과 같은 흥미로운 주제들로 대화를 이어갔기 때문에 정말 재미있었다. 특히 유동균님을 통해 '테크니컬 라이팅'이라는 키워드를 처음 듣게 되었다. 그리고 '개발자를 위한 글쓰기 가이드'라는 책도 알게 되었다. 책 초반에 나오는 내용인 원뿔 이야기를 해주셨는데, 재밌어 보이기도 하고 주제가 글쓰기여서 조금씩 읽고 있다.

회사 생활

최근 회사일로 정말 바쁘게 지냈다. 입사 시기가 비슷한 FE 개발자분과 함께 프로젝트를 진행하면서 많은 시행착오를 겪었다. 프로젝트의 페이지가 굉장히 많았는데, 각자가 맡은 페이지의 기능 구현을 완료하고 보니 많은 부분이 상이했고, 각자 생각한 구현 정도의 차이도 있었다. 적극적으로 커뮤니케이션을 하고, 협의한 내용을 제대로 문서화 했다면 더 좋은 결과가 있었을 것이다. 일정에 쫓겨서 이런 부분들을 놓친 것이 많이 아쉬웠다.

 

블로그 글은 엄두도 못낼 정도로 프로젝트에 매진 했다. 그럼에도 불구하고 일정이 밀려 자책도 많이 하고, 실력이 부족하다는 것을 여실히 느꼈다. 관리자 페이지라서 재사용할 컴포넌트가 많다고 생각했다. 그런데 하나의 컴포넌트로 너무 많은걸 하려다보니 오히려 컴포넌트간 결합도가 올라가고, 유지 보수가 어려워진다는 것을 깨달았다. 그리고 입력 폼들을 다루면서 제어 컴포넌트와 비제어 컴포넌트에 대해 알게 되고, onChange()와 useRef()의 사용성에 대해서도 고민을 하게 됐다. 리렌더링을 최소화하려고 했던 useRef()의 사용이 오히려 코드가 지저분해졌으며, 더 많은 작업을 해야했다. onChange()를 커스텀 훅으로 만들어서 사용을 하는 방법으로 리팩토링 해볼 생각이다.

 

이렇게 생각하게 된 여러 이유가 있었지만 테오의 오픈채팅방에서 다음과 같은 대화가 있었다.

"리액트쿼리 공식문서보다 설명을 잘하는 블로그 글을 쓴 걸로 유명한 tkdodo님도 '리렌더는 뷰가 최신화 됐단 걸 보장하니까 좋은 거다. 오히려 렌더 해야 되는데 안 하면 그게 진짜 나쁜 거고, 최적화를 위해서는 리렌더를 막을 게 아니라 구조 변경을 통해 slow render를 막아야 한다.'라고 주장하셨더라구요. 전혀 필요없는 렌더링이라면 당연히 안 하면 좋죠. 근데 그걸 하기 위해서 추가로 작업 해야 하고, 소스코드가 지저분해진다면, 그냥 렌더 되게 냅두는 것도 좋다고 봐요. 성능이 좋아야 하는 핵심 이유는 사용자가 불편함을 느낄 수 있기 때문이고, 대부분의 상황에서 리액트는 충분히 빠르기 때문에 사용자가 불편함을 느낄 일이 없으니까요."

마침 고민하고 있던 내용을 이렇게 시원하게 알려주셔서 정말 감사했다.

 

또 하나 알게된건 리팩토링의 비용이 생각보다 많이 든다는 것이었다. 회사 홈페이지 국제화를 한 후에 조금 지나서 해당 구현 방식에 대해 의구심이 들었었다. 하지만 구조 전체를 바꿔야하는 리소스가 들고 이미 배포가 끝나서 언제 시간을 내야할지도 모르는 상황이었다. 이 문제로 앞으로 나아가지 못한다면 차라리 다음 프로젝트를 더 잘하기로 하고, 기회가 된다면 그때 적용 해보는 것이 더 나을 것 같단 생각이 들었다.

불규칙성

마케팅 회사의 개발자이다 보니 프로젝트 외에도 광고주의 페이지에 광고 패널을 설치 하거나, 사용자의 여러 행동들을 추적할 수 있게 스크립트 설치를 하는 일도 하고 있다. 문제는 이 요청이 불규칙적이라는 것이었다. 이 방식이 개선되기 전에는 영업팀이 트렐로에 카드를 생성하면 사내 메신저로 알림이 뜨는데 이걸 보는 즉시 일을 처리했었다. 일 처리가 빠르다는 장점이 있었지만 프로젝트를 하는 중간에 자주 알림이 뜨면 집중이 되지 않고, 언제 요청이 올지 몰라 불안함을 느끼기도 했다. 이런 방식이 비효율적이라고 생각을 해서 회의 시간때 개선 방향을 다음과 같이 제안했다.

  • 오전과 오후 시간대를 정해서 그 시간에만 일 처리를 한다.
  • 긴급건은 따로 메시지를 주거나 개발자가 확인하여 바로 처리한다.
  • 정한 시간대 내에 완료하지 못할 정도가 되면 미리 더 하거나 영업팀에게 미리 양해를 구한다.

이렇게 하면 정한 시간대 외에는 프로젝트에 온전히 집중할 수 있고 불안해 하지 않아도 된다. 게다가 시간대를 정했기 때문에 그 시간대에는 해당 일을 맡은 개발자 모두가 광고 패널과 스크립트 설치만 해서 빠르게 처리 할 수 있다. 다행히 현재는 이 방식으로 일 처리를 하고 있어서 개발할 때는 열심히 개발만 하고 있다.

알고리즘 공부

마지막으로 요즘 알고리즘 공부를 시작했다. 유데미에 괜찮은 가격으로 올라온 자바스크립트 알고리즘 강의가 있어서 구매를 했는데 만족하고 있다. 같은 강의를 듣는 지인이 있어서 매주 수요일 저녁에 라이브 코테를 하는 방식으로 진행하고 있다. 라이브로 코딩을 하면서 말로 설명하는 것이 이렇게나 어려울 줄은 몰랐다. 정말 머릿속이 새하얘지는 느낌이다. 앞으로 4개월 정도는 알고리즘 공부에 집중하려고 한다.


다음 회고 글은 1년차 프론트엔드 개발자가 되어 있을텐데 느낌이 많이 다를 것 같다. 꾸준히 공부하고 성장해서 지속 가능한 개발자가 되자.

반응형