취업 회고록
회사에서 맡은 업무와 제가 작성한 코드 snippet은 다음글에서 확인하실 수 있습니다 >>
입사한지는 한참 지났는데, 드디어 쓸 여유가 생겨서 취업 회고록을 남긴다. 그동안 느낀 점도, 배운 점도 정말 많다. 부족한 나를 이끌어주신 사수님들에게 감사를 드리며..
프로젝트가 아니기에 어떤 방식으로 글을 쓸 지 고민하다 시간 순으로 작성하기로 하였다. 마지막에는 내가 회사에서 개발한 코드를 공유하고자 한다. 물론 회사의 코드이기에 전체를 그대로 공유하기는 어렵지만, 간단한 snippet과 원리, 내가 배우게 된 것들을 공유해볼 예정이다.
Table of Content
- 입사 과정
- 입사 이후
- 담당 업무/코드공유
- 마치며
1. 입사 과정
부트캠프의 마지막 과정에 기업 인턴쉽이 있었다. 여러 회사를 선택할 수 있었는데, 회사 기술 스택이 TypeScript와 Next.js가 있기에 선택했다. 인턴 기업 중에는 대기업도 있었지만, 새로운 기술을 배울 수 있다는 점에서 이 회사가 가장 끌렸다. 지원 당시 입사 제안까지 받을 기대는 하지 않았다.
1달의 인턴 기간동안 2개의 과제를 전달 받아 진행했다. 프론트 리드분이 1달이라는 시간을 주셨지만, 일주일 만에 끝내버려서 과제를 더 달라고 요구했다. 인턴 첫 주에는 매일 매일 새벽까지 Next.js와 타입스크립트를 공부했다.
인턴 마지막 주에는 결국 입사 제안을 받았다. 나를 포함 3명의 인턴이 있었는데, 나만 프론트 포지션으로 제안을 받았다. 한 친구는 모바일 개발자로 제안을 받았고, 나머지 한 분은 아쉽게도 받지 못했다. 업무 분위기가 괜찮아 보였고, 특히 프론트 팀에서 일하면 재밌을 것 같아서 흔쾌히 수락했다. 취업 준비를 따로 하지 않았기 때문에, 그 과정의 고됨, 설움 etc..를 겪지 않고 지나갔다.
2. 입사 이후
처음 회사 코드를 보고 느꼈다. 내가 하던 건 애들 장난이라는 것을..
취업 이전에는 고려하지 못했던 게 무척 많았다. 특히 컴포넌트 재사용, CI/CD, 깃 관리 등 팀 협업과 효율성을 위한 개발 환경이 너무 새로웠다. 프론트 팀은 나를 포함하여 3인으로 구성되어 있었고, 인력이 부족한 상황이어서 온보딩 기간 없이 첫날부터 개발 업무에 투입되었다. 업무량이 많고 인력은 부족했던 상황이기에, 프론트 팀은 새로운 프로젝트가 없는 기간에 틈틈히 생산성을 끌어올리기 위한 개발 환경 구축에 힘을 써온 것 같았다. 입사 이후 내가 배운 점들을 크게 정리했을 때 다음과 같았다.
a. 코드 퀄리티
b. 사용자 경험
c. 협업를 위한 소통
부트캠프 시절까지는 무조건 추구해야할 이상향 정도로만 느껴지는 게 많았다. 하지만 현업에 있으면서 구체적인 경험을 통해 이러한 것들이 어느 부분에서 중요하고, 왜 중요한지 직접 볼 수 있었다. 사용자들의 피드백을 자주 받을 수 있는 점도 한 몫 했을 것이다. 첫날부터 운영팀이 사용하는 BMS 개발 업무를 인수인계 받았기 때문에, 자주 피드백을 받을 수 있었다. 실제 사용자가 없을 토이 프로젝트에서 '좋은 게 좋은 거니까'라는 마인드로 예외처리를 작성 하는 것과 현실은 달랐다.
a. 코드 퀄리티
drone.io를 이용해 PR 없이 머지하고 배포를 하다보니, 따로 코드 리뷰 세션이 있지 않았다. 그래서 첫 한 달은 개발 브랜치에 머지하기 전에 무조건 사수분들이 코드 검토를 해주시고, 수정 사항을 알려주셨다. 그 과정에서 많은 피드백을 받았다. 구현을 하기 위한 방법은 많지만, 최대한 효율적으로 작성하도록 리뷰해주셨다. 일정이 빠듯할 때는 내가 작성한 코드를 팀원들이 이어 받아 개발할 수 있기 때문에 가독성 또한 신경 써야했다.
배운 것들 중 기억에 남는 것은 있는 기능을 다시 만들어 쓰지 말것. 그 유명한 'don't reinvent the wheel'이겠다. 사용 중인 라이브러리에서 제공하는 기능 혹은 커스텀 훅이나 모듈을 최대한 활용할 것. 예를 들어 swr을 사용한다면, 불필요하게 코드를 짜는 대신 conditional fetching이나 뮤테이션을 활용하라는 피드백을 받았다. 둘째로, 회사에 이미 작성된 코드를 보면서 배운 점들이 많았다. 특히 하드 코딩이 된 부분을 최대한 줄이고, 재사용성을 최대한 고려해서 짜여진 컴포넌트를 보면서 배운 점이 많았다. 왜 진작 이렇게 하지 않았을까-싶을 정도로 개발 기간을 단축 시켜주었기 때문이다. (재사용으로 시간이 단축될 때 쾌감이 든다!) 이는 Code Splitting이 잘되어 있기 때문이었다. 유용한 함수나 커스텀 훅, 컴포넌트는 거의 모두 모듈화 되어 있었다. 배포 이후로 끝나는 단발성 프로젝트와 달리 운영 중인 서비스는 계속해서 유지 보수 및 새로운 기능을 추가해야 하기 때문에 이러한 개발 환경의 구축과 워크 플로우가 중요했다. 이제는 '개발 할 수 있다'가 중요한 게 아니라, 기존 설계를 유지하면서 어떻게 확장 가능하게 만들 것인지-를 고민하게 된 것 같다. (쓸데 없는 일을 반복해서 하고 싶지 않기에..) 특히 현업 경험은 처음이다보니 모노레포, 공용 라이브러리 같은 환경이 상당히 첨단으로 느껴졌다.
b. 사용자 경험
역시나 현업에 있지 않았더라면 경험이 어려웠을 것이다. 첫 출근일부터 관리자 페이지를 담당하도록 인수인계 받아 개발하였는데, 여러 로직 에러나 불편한 사항을 개선하라는 운영팀의 요청을 자주 받았다. 테이블 칼럼 사이의 간격, 필터링 버튼의 작동 방식, 페이지 레이아웃, 보여줄 데이터와 보여줄 필요가 없는 데이터, 백엔드에서 보내주는 필드를 적절한 이름으로 바꿔야 하는 등.. 운영팀도 사용자인지라, 개발을 아예 모르는 사람이라 가정하고 한 눈에 딱 알아보고 사용할 수 있도록 페이지를 제작해야 했다. 게다가 게시판 관리, 이벤트 관리, 유저 관리 등 서비스 운영의 정말 핵심적인 부분이기도 했기 때문에, '실제 서비스 사용자가 보지 않는 부분이니 상관없다'는 식으로 대할 수는 없었다.
백오피스 개발 업무에 적응할 때 쯤, 점차 서비스 배포에도 참여하게 되었다. 매달마다 변경되는 이벤트가 있었는데, 8월이 되면서 새로 이벤트 페이지의 UI를 변경해주어야 했다. 스타일 변경 정도의 간단한 일이라 생각하고 교체하여 배포했는데, 다음날 화면이 깨진다는 보고가 들어와 뜨악했다.. 백드롭 이미지 사이즈가 특정한 모바일 기기에서는 더 짧게 나왔던 것이 화근이었다. 급하게 백드롭에 있는 이미지 태그를 height: fit-content 에서 max-content로 변경하였다. 첫 배포부터 이런 문의가 들어와서 아찔했던 순간이었다. 개발자 도구의 장치 에뮬레이터에서 한가지 기기만 확인을 했던 것이 문제였다. 이런 식의 작은 문제들이 생길 수 있었기 때문에, 아무리 작은 업데이트이더라도 기본적인 사항은 꼼꼼히 확인해야 했다.
c. 협업를 위한 소통
수습기간이 끝나갈 때 쯤, CTO님과 면담하면서 질문을 너무 하지 않는다는 피드백을 받았다. 질문에 답변하느라 번거로운 것보다, 질문을 하지 않아서 생기는 문제를 다른 사수분들이 해결해야하는 것이 더 큰 문제일 수 있다는 말씀이었다. 그리고 사수들 또한 아무리 바쁘더라도 답변하는 것을 성가시다고 느끼지 않는다고 하셨다. CTO님은 백엔드 팀 또한 리드하고 계셨는데, 내가 맡은 업무를 개괄적으로 파악할 순 있어도, 내가 적극적으로 질문을 하지 않으면, 구체적으로 어떤 일을 하고 있는 지 어필이 되지 않는다고도 하셨다. 모두 타당한 말이었고, 면담 이후 이를 개선하려고 노력을 많이 했다.
질문을 하지 않게 된 배경에는 두려움이나 회피심 보단 이런 태도가 있었다. 본래 부트캠프 시절부터 질문을 자주 하지 않았고, 꼭 필요한 질문만 하려고 했다. 그 이유는 충분히 내가 해결할 수 있음에도, 답변을 겉으로만 이해한 채, 그 답변에 의존하게 되기 때문이었다. 최대한 질문을 구체화 시키지 않는다면, 그 답변을 내가 진짜 이해한 것이 아니라고 생각했다. 직접 해결하면서 배우자-라는 태도가 있었기에 질문을 잘 하지 않게 된 게 컸다. 이런 태도는 인턴, 현업 기간까지 이어져오다가 문제가 되었기에 바로 고치려 하였다.
확실히 질문을 많이 하니, 사수분들이 더 적극적으로 도와주셨다! 특히 프론트 리드분은 약간 불안한 마음으로 내가 하는 일을 종종 체크하러 오셨는데, 내가 먼저 질문을 하니 안도하시는 모습이었다. 질문을 하면서, 어떤 문제는 내 선에서 해결할 수 없는 것이니 빨리 보고해야겠다는 생각을 할 수 있었다.
출처: 퍼블리 트위터
기억에 남는 정말 좋은 답변이 있었다. 메인 페이지 리뉴얼 작업 중이었는데, 새로운 모달을 추가해야 했다. 나머지 모든 작업은 완벽하게 작동했지만, 한가지 문제가 있었다. 모달이 브라우저의 가운데가 아닌, 메인페이지 내용의 마지막 태그 다음에서 렌더링이 되는 이슈였다.
<회사공용모달컨테이너>
<내가 개발한 모달>
</회사공용모달컨테이너>
이러한 형태로 공용 모달 컴포넌트를 사용했어야 했는데, 공용 모달 컨테이너의 absolute가 메인페이지 태그의 relative를 기준으로 위치를 잡고있는 것이 문제였다. 공용 모달 컨테이너는 패키지로 받아온 것이기에 수정이 불가능했고, 내가 개발한 모달만 position:fixed로 바꾸어도 여전히 동일한 문제가 발생했다. 그래서 사수에게 여쭈어보니, 사수분께서 정말 간단한 답변을 해주셨다. "메인 페이지 렌더링이 온전히 끝나고 나서 모달이 렌더링 되야겠죠? 방법은 여러가지 있으니 잘 생각해보세요" 그 얘기를 들으니 불현듯 간단한 해결방법이 떠올랐다! 사수분이 바쁘신 것도 있었지만, 스스로 해결할 시간을 주신 것 같아서 감사했다. 나는 이 문제를 useEffect와 2개의 state를 사용해서 해결하였다.
useEffect(() => {
if (!Cookies.get("noticeClose")) setNoticeCookieState(true);
}, []);
useEffect(() => {
if (noticeCookieState) setNoticeModalState(true);
}, [noticeCookieState]);
state를 플래그처럼 사용하여 해결했다. useEffect를 통해 초기 렌더링 과정에서 "오늘은 더이상 보지 않기" 쿠키가 존재하지 않는다면, 첫 플래그를 true로 바꾸어준다. 다음 useEffect는 초기 렌더링이 끝나고 쿠키 state가 바뀔 때 한번 더 실행되는데 (useEffect는 deps가 있더라도 로드 시에 한번씩 실행된다), 초기 렌더링 이후 쿠키없음 state가 true일 때, 단축 평가를 통해 모달을 렌더링 해주는 state를 true로 바꾸어준다. 2개의 useEffect를 연달아 사용한다는 점이 물론 마음에 걸리긴 하였다. (useEffect는 왠만해선 사용하고 싶지 않았기에.)
잠시 후 사수님이 해결하셨냐 물어보시기에, 이런 방식으로 해결했다고 전했다. 잘했다고 얘기를 듣고, 본인은 이 상황에서 setTimeOut을 사용한다고 말씀주셨다. 이 질문과 답변, 해결 과정과 해결 이후의 소통이 상당히 적절하게 느껴져서 지금도 기억에 남는다.