Today I Learned
: 오늘은 TIL 컨셉보다는 여태까지 내가 노션에 정리해왔던 업무 관련 혹은 개발자 나름의 사회 생활(?) 혹은 다른 팀과의 협업 이라는 측면에서 배운점들을 진지하게 정리해보고자 한다.
온보딩 과정에서 해야할 것들
: 나는 같은 회사에서 현재 2년 N개월 정도의 연차인 개발자로 일하고 있지만, 여러 조직의 프로젝트를 경험한 개발자이다. 하도(?) 여러개의 프로젝트에 온보딩을 하면서 적응하고, 내 프로젝트 처럼 체화(?)시키는 과정을 자주 거치다보니 나만의 노하우가 생겼기에 아직 시니어 개발자라고 하기엔 뭐하지만 나만의 꿀팁을 정리해본다.
- 레거시 코드 분석도 중요하지만, 해당 프로젝트 or 서비스를 유저 입장에서 관심있게 사용해보는 것도 중요하다 : 처음엔 나도 개발자인 내가 서비스 자체를 이용해본다 한들 초반에(온보딩 과정에) 큰 도움이 될까? 라는 생각을 했었다. 하지만, 전체 서비스를 기획 혹은 사수분들의 설명을 통해 이해하기에는(사수분도 모르는 부분도 많다. 왜냐하면 모든 서비스를 한명의 사수가 개발하지는 않기 때문) 너무 방대하거나 이해해야할 히스토리가 많을 수 있다. 이걸 코드 분석을 통해 하는건 시간이 더 걸린다고 생각된다. 따라서, 아무리 재미없는 서비스라도(?).. 내가 이 서비스의 target 유저라는 마인드로 하나하나씩 기능을 사용해보는게 제일 먼저라고 생각한다. 이러다가 다들 발견하지 못한 에러를 발견할수도 있고, 비직관적이거나 고쳐야할 UX를 찾을수도 있다. 그리고 이 때, 이것저것 테스팅한 경험이 후에 개발을 할 때, 예를 들어, A라는 추가 기능을 개발했는데, 생각해보니 이 기능은 기존에 있던 B or C 기능에 사이드 이펙트를 일으킬 수 있는거지?! 라고 떠올릴 수 있다(물론 이것도 코드 분석으로 할수도 있지만, 서비스에 대한 이해도가 높거나, 적응을 많이 한 상태라면 더 쉽게 떠올릴 수 있다고 본다).
- 단순히 레거시 코드를 분석한다기 보다는 '하나의 목표'를 가지고 분석하는게 좋다 : 이건 사람마다 다를 것 같은데, 나같은 경우에는 아무 목표? 없이 레거시 코드를 분석하는건 처음 부서에 들아가서 졸음과의 전쟁을 하는 것과 같은,, 위험한 행위(?)라고 생각했다. 이에 따라, 사수분께 말씀을 드리고 정말 사소한 task 예를 들어, 사소한 css 수정 등의 태스크를 받아서 A 기능 혹은 A 컴포넌트 등을 깊게 분석해보면서 하나하나 아는 코드를 넓혀가는 전략을 쓰는게 도움이 됐다. 어차피 한번에 숲을 볼순없다. 나무를 하나하나(작은 태스크를 하나하나) 보다보면 언젠가 숲이 보이는 형태이기 때문에 '레거시 코드를 파헤친다!' 라는 좀 막연한 목표보다는 사소한 task라도 받아서 목표를 갖고 하나씩 알아가는게 좋았던 기억이 있다.
- 팀원분들의 코딩 스타일을 익힌다 : 모든 개발 분야, 하지만, 프론트엔드 분야에서는 특히나 컨벤션과 아키텍처가 다양한 편이다. vue 같은 좀 더 열린 프레임워크를 쓰면 더더욱 그렇다. 이 분야의 장점이자 단점은 100% 정답이 없다는 것이다. 이에 따라, 기존에 일하던 팀에서 다른 팀으로 옮겼거나 신입으로 들어왔다면 본인이 쓰던 방식 혹은 컨벤션과 전혀 다른 팀에서 일하게 될 수 있다. 이 부분은 사실 코드 리뷰 프로세스가 제대로 돼있는 팀이라면 자연스럽게 고쳐질 수 있겠지만, 그렇지 않은 부서도 있고, 미리 알아두면 센스 있는 신입 혹은 온보딩 개발자가 될 수 있으므로, react로 치면 열려 있는 개념들 예를 들어, useMemo는 몇번 정도의 연산이 걸리는 부분에서 쓰고 있구나 아니면, 조금 낭비인 것처럼 보여도 모든 다연산이 예상되는 부분에는 useMemo를 쓰는구나 등을 미리 파악해두면 팀에 온보딩할 때 더욱 빠르게 할 수 있다고 본다.
- 마지막으로 깃허브의 히스토리를 보는 것도 좋은 방법이다 : 사실 깃허브의 히스토리는 어마어마하게 많을수도 있기 때문에 앞서 말한 아무 목적없이 이걸 보면 엄청 지루하고, 그렇게 보기 좋게(?) 돼있는 것도 아니기에 힘든 작업이다. 하지만, 모든 히스토리를 본다는 관점보다는 코드를 분석할 때
여기는 왜 이렇게 했지??라는 생각이 들 때, 팀원분들한테 묻기 애매한 상황이 있다. 이럴 때 커밋 히스토리 등을 봐서 거기에(물론 코멘트를 남기는 문화가 정착된 팀인 경우에 한정이지만,,) 남긴 코멘트 등을 통해 아 여기서 이런 논의가 있었고, 그래서 이렇게 결정됐구나를 파악하면 이해가 더 잘된다. 코멘트가 없다면 해당 작업을 한 팀원분에게 시간을 내서 질문을 할수도 있다. 결과가 중요하긴 하지만, 그 과정에서 무슨 논의가 있었고, 그 결과로 어떤 선택을 했는지 등을 이해하고 넘어가면 팀의 문화도 더 잘 파악할 수 있고, 코드를 더 잘 납득할 수 있게 된다.
디자인 혹은 기획팀과의 협업시에
: 나같은 경우에는 처음엔 기획, 디자인 팀이 해달라는걸 웬만하면 다해주는 프론트엔드 개발자 였다. 내가 본래는 패션 쪽 앱을 기획하다가(회사는 아니지만) 개발이 답답해서 개발자가 된 케이스라서 그랬던 것 같기도하고, 그냥 회사의 매출을 위해 회사가 시킨대로 일을 하는 개발자이기에 그랬던 것도 있던 것 같다. 하지만, 회사를 위해서라도 조건 없이 해준다라는 발상은 좀 위험하다는 생각을 하게 됐다.
: 기획 혹은 디자인팀에서 부탁하는건 분명 회사에 도움이 되는 방향 혹은 그들도 윗사람이 시켜서 일을 했을거다. 그렇다 했을 때, fe 개발자가 개인적인 판단으로 이를 거부하거나, 논의가 필요하다고 말하는게 이상할수도 있다(주니어 때는 더더욱 그렇게 느껴진다. 근거라는게 부족하니까). 하지만, 다음과 같은 경우에는 확실하게 의견을 말해야한다고 생각한다.
: 마감 기한이 촉박하여 기능 개발이 가능하더라도 QA 기간이 줄어들어 완벽한 서비스 구현에 어려움이 있을 수 있는 상황. 시간을 갈아넣는게 개발자 아닐까?.. 할 수 있지만, 이건 더 좋은 창문을 새로 개발할 수 있는데, 깨진 창문에 청테이프를 붙인다음에 이 청테이프를 예쁘게 꾸며주세요! 부탁을 받은 것과 유사하다. 이런 경우에는 과감히 특정 개발 사항을 포기하고, 다음 업데이트를 노리는걸 제시해야한다(이렇게 배포를 해도 결국엔 문제가 생기기 때문에 개발을 포기한 것에 대한 미안함 혹은 회사에 매출 타격 등이 배포 이후 오류로 인한 결과와 유사해진다).
이외에 사소하지만, 아니 이건 솔직히 나만의 대응법?인데 정리해본다
- 보통 디자인팀에서 수정을 요청할 때(본래 첫 개발시에는 요청하지 않았던)의 근거들을 보면 대부분
미적인 혹은 유저가 편할만한 UX이기 때문이 많다. 이런 부탁을 받으면 사실 FE 개발자 입장에서는 앞서 말한 부분이 꽤나 추상적이고, 저렇게 주장을 할 때 보통 이렇게 수요 조사를 해봤는데 이게 더 이쁘대요! 혹은 더 편하다고 느낀답니다 심리, 뇌과학적으로! 이런식으로 정량적인 근거를 대는 것이 아니기 때문에 살짝귀찮은 감정이 드는게 사실이다(바쁜 시기에 공통 컴포넌트 룰을 무시하고, 하나의 컴포넌트에만 독특한 UI를 부탁한다던지 등). 하지만, 이럴 때 저런 속마음을 다 표출하면 협업하는 팀간에 사이가 좋아질리 없다. 어차피 다들 부서의 서비스를 위해 돈받고 일하는 직원인데..ㅎㅎ. 따라서, 이럴 때는 일단은 부탁 받은 UI/UX를 분석해보겠다고 하는 편이다. 그리고나서 시간 내에 구현할 수 있는지, 아토믹 패턴 등 UI 관련 컨벤션에 크게 어긋나고, 이걸 허용하는 순간 디자인 시스템에 따라 고칠게 많아지는지(그리고 이게 마감기한과 비교 했을 때 할만한 가치가 있는지) 등을 고민하고 논리적인 근거가 있을 때만 반대하고, 나머지는 그냥 컨펌하는 편이다. 앞서 미적인 부분 등 추상적인 근거를 댈 때 약간의 반감이 생긴다 했는데, 그것처럼 그분들도 fe 개발자가 이거 이런이런 개발을 해야해서 이정도의 가치가 있는지 모르겠어요 라고 말을 해버리면 그분들에게는 이게 추상적인 근거가 된다. 그래서 새로 블랙박스인 본인들의 업무 영역을 애매하게 설명하면서 부탁 or 거절을 하는게 되고, 오해가 쌓이는 일을 봤던 것 같다. - 위에서 말한 것의 반복인 것 같긴한데, 정말 코딩이 하기 싫은날이 있다(잘안되는날).. 우리 회사 같은 경우에는 복지가 좋은 편이라 보통 나는 이런날엔 일찍 퇴근해버리고 다음날에 더 잘하자라는 마인드이다. 이 때, 이런 잘 안되는날 다른 팀에서 앞서 말한 추상적인 근거로 약간은 귀찮은 수정 작업을 요청하면,, 나도 사람인지라(?)
이걸 왜 해야될까라는 생각이 든다(실제로 그런적이 있다). 하지만, 이건 정말 잠깐 지나가는 감정이다. 하지만, 이것도 사회생활 중 하나인데, 잠깐의 감정으로 회사의 비즈니스와 관련된 것에서 감정적으로 대응을 하면 본인이 후회할 뿐이다. 이럴 때는 솔직하게 내일까지 고려해보겠다고 말을 하는게 좋다. 너무 당연한 팁같은데 나같은 완벽주의 한테는 저런 일종의 미루기?도 허용이 안되던 때가 있었어서 써본다.
이외에 일하면서 떠오를 때마다 적은 것들
- 기획서랑 피그마, 백엔드 API 문서 + 팀즈 등 100% 명확화 한다음에 작업 시작하자.
- 매일매일 업무는 나 자신과의 싸움이고, 내가 설정한 나만의 목표를 이루는 것 외에는 아무것도 아니다. 따라서, 다른 사람에게 휘둘리거나 스트레스 받을 이유는 딱히 없다.
- 회사는 일하는 곳이다. 일하는 곳에서 일하는 것이 아닌 인간관계 혹은 나의 다른 부분 때문에 신경 쓰이는 일에는 에너지를 소모하지 않는다. 이건 삶의 규칙과 같다. 눈 앞에 있는 것에 집중한다.
- 동료 혹은 사수가 뭔가에 의문을 제기하거나, 시키거나, 내 코드를 없애고 본인의 코드로 뭔가를 할 때 개인적인 감정에 휘둘리지 않고, 일단 긍정하고, 만약 내 코드가 효율적인 것 같으면 이후에 반론한다.
- 감정에 휘둘리지 않고,
일을 효율적으로 모두가 잘되는 방향으로 한다고 생각하자. - 어떤 기능을 하나 구현한다고 했을 때 반드시 손코딩으로 끝까지 구현해본다. 이 때, 세세한 부분 예를 들어, 이미지 URL을 string으로 받아서 이미지를 컨버팅하고 띄워주는 기능이라고 했을 때 실제로 이 기능을 code sand box 등으로 간단하게 구현해본 다음에 구현을 시작하자. 그래야 중간에 cors 이슈로 api가 필요한지 아닌지 등을 전부 결정하고 시작할 수 있다. 사실상 코딩은 손코딩에서 끝나고 나머지는 실제 노동(?)을 하는거라고 생각한다.
- 다른 팀이랑 얘기할 때 (특히 버그)
이쪽은 건든게 없다라는 말은 웬만하면 하지말자. 그냥 멋없음.. 근거를 찾아서 근거로 얘기하자.
추상적인 말들이지만 새겨둘 점
- 빠르게, 대신 더 꼼꼼하게 완벽하게 이렇게 둘다 할 수 있다. 빠르지만 실수하는 개발자 X 실수가 없지만 느린 개발자 X 둘다 가져가는 개발자가 되도록 노력하자는 말.
- 10을 하라했을 때 최소 11을 하는 사람이 되자.
