230710 월요일 업무 TIL

이번주는 비가 많이 와서 집에 오자마자 뻗었다는 핑계로 이번 주말에 몰아서 작성했다. 이런 나 자신을 반성하며.. 

 

'오늘 나에게 한마디' 

새로운 한 주의 시작 화이팅! 

'오늘의 고민' 

 나도 이슈를 많이/얼른얼른 쳐내는 팀원이 되고 싶다. 

[잘한점] 

상황1) production env 파일을 체크하던 중에 다른 팀에서 작성한 코드 중에서 안쓰이는 코드가 있어 다른 팀원에게 자문을 구했다.

액션1) 다른 팀원의 말로는 이 변수는 현재 안쓰이고 있으므로 있을 필요가 없기도 하니 삭제해야 한다고 잘 캐치했다는 칭찬을 들었다. 

칭찬1) 배포가 나가기 전에 상당히 체크해야 할 부분이 꽤 있는데, 이렇게 다른 분이 놓친 것을 내가 체크하고 수정할 수 있어서 뿌듯했다. 

 

상황2) 팀장님께서 전체 팀원들에게 '내가 작업한 내용에 대해 회고'를 써보라고 권유하셨다. 이걸 토대로 나중에 발표도 해야 한다. 

액션2) 나는 이미 블로그에 매일(이라고는 하지만, 밀려서 쓸 때도 있으니..ㅎ) 오늘 하루 TIL겸 회고를 작성하고 있었다. 

칭찬2) 내가 나름 쌓아온 이런 습관들이 전체적으로 팀원들에게 필요한 행동이고, 내가 잘하고 있었다는 생각이 들었다. 

---

[개선점] 

문제1) 팀장님께서 전체 회의때 '프론트-백엔드 작업의 시작~마무리 완성도가 낮다'라는 말씀을 해주셨다. 

원인1) 아무래도 일정상 일을 급하게 쳐내다보니, 프론트엔드와 백엔드 팀원들간의 소통이 확실히 많지 않고, 일단 백엔드에서 '프론트엔드에서 이런 데이터가 필요하겠지'하고 추측한 후에 프론트엔드에게 응답 데이터를 내려주는 상황이 지속되고 있었다. 그러나 이런 문제가 프론트엔드에서 데이터가 잘못된 형태로 내려온다거나, 맞지 않는 데이터가 내려가서 추후에 문제가 발생하여 이슈가 발생하는 일이 잦다. 

액션플랜1) 백엔드 개발자로서 추측하면서 '프론트엔드쪽에서 이런 데이터가 필요하겠지?'라고 혼자 정리해보는건 좋지만, 내가 정리한 것을 토대로 프론트엔드 개발자와 충분한 논의가 필요하다는 것을 다시금 깨닫게 되었다.  

---

[배운점] 

배움1) 전체 배포가 나가기 전에 stage 환경과 production 환경에서 각각의 변수를 체크하는 업무를 처음 하였다. DEV DB와 PROD DB를 체크하는 업무와 유사하게 느껴졌다. 

의미1) production 환경변수 (xxx.env.production)를 체크하면서 stage 환경과 비교했을때 아래의 표를 참고하면 좋을 것 같다. 

stage	production
O	X
X	O

-> env 파일(환경변수 파일)에서 해당 환경변수가 쓰이고 있는지 live 배포 나가기 전에 확인을 해야한다고 한다. 

 

배움2) Prod 환경에서 pod(kubernates)를 종료하려면 replicas 개수를 0으로 해서 조정한다. 

의미2) replica 개수를 0으로 해서 production 환경을 종료할 수 있다니 처음 알았다. 

 

배움3) stageMQ 환경과 ProdMQ 환경의 주소가 다를 수 있다. 

의미3) 주로 로컬에서 MQ 환경을 돌려보기만 했지 Prod 환경에서는 MQ를 돌려본적은 없다. 그래서 stage 환경과 prod 환경의 MQ 주소가 달라서 의아했는데, 둘이 주소 다를 수 있다고 한다. 

 

배움4) 프론트엔드쪽에 데이터 값을 내려줄때 0인지 null 값으로 내려줘야 하는지는 상의를 해야한다. 

의미4) 아직 0과 null 차이에 대해서 크게 와닿지는 않는다. 하지만 프론트엔드쪽에서는 값을 0으로 받을때와 Null값으로 받을때 둘이 다르다고 한다. 이 부분에 대해서 좀 더 파악해야겠다는 생각이 들었다. 

 

배움5) webpack build analyzer 웹팩 빌드 도구가 있다. 프론트엔드에서 배포 시간이 너무 오래걸리니, 대리님께서 이 도구를 이용하여 빌드 속도가 왜 느려졌는지에 대한 파악을 해주셨는데 이런 도구를 처음 보니 신기했다. 

어떤 파일이 어떻게 빌드가 되는지 분석하고, chunk size를 줄여나가야 함 + code splitting이 프론트엔드쪽에서 필요하다는 분석이 있었다고 한다. code splitting은 webpack의 기능이라고 한다.

의미5) 나는 백엔드 개발자이지만, 항상 프론트엔드가 여러모로 백엔드 코드보다 무겁다는 것은 체감하고 있었다. (링크나 이미지 등 작업 리소스가 많으니) 하지만 저런 분석 도구를 통해 어디서 용량을 많이 잡아먹는지 분석하고 배포 빌드 속도를 줄일 수 있다는 것이 신기했다. 

 

배움6) lottie라는 프론트엔드 라이브러리가 있다. motion이 들어가있는 Json 파일 (ex. 홈화면에서 뭔가 움직이는 모션을 취하는 캐릭터라던지..) 애니메이션이 적용되어 있어 무겁다고 한다.

의미6) 위에서 배포 빌드 속도를 많이 잡아먹는데 lottie도 한몫을 했다고 한다. 

 

그래서 왜 build 속도 개선을 해야하는가? 

- 웹서비스는 장애 발생시에 빠른 대응과 처리가 필요한데, 빌드 속도가 느려질수록 장애 대응 속도도 느려지는 것이다. 

 

배움7) 우리 팀의 백엔드 배포 빌드 속도는 약 7~8분정도 걸리는데 오래 걸리는 것이라고 한다. 오래 걸린다고 생각은 해본 적이 없는데, 팀장님의 말씀으로는 이것도 느린 것이라고 한다. 왜냐하면 프론트엔드에 비해 lottie 같은 무거운 모션 라이브러리나 컴포넌트(한 화면에 여러 동작들이 들어가니),css도 없는데 저 시간도 오래 걸리는 것이라고 하셨다. 

의미7) 우리 팀의 백엔드 코드는 주로 모듈화를 사용하는데, 모듈화가 중구난방 사용중인 것들이 많아서 그렇다고 한다. 그래서 안쓰는 모듈이나 파일들 등은 바로바로 쳐내야겠다는 생각이 들었다. 

 

배움8) 백엔드에서 서버를 2개 켜서 각각의 API를 동시에 켜야 하는 경우가 있다. 이런 경우에는 httpService나 axios 같은 라이브러리를 자주 사용한다.

의미8) 서버 2개를 켜서 2개의 API를 동시에 켜고, 데이터를 두 쪽에서 받아올 수 있는 것은 알고 있었는데 정확히 어떤 라이브러리를 이용해서 받아오는지는 잘 모르고 있었다. 이번 기회에 팀원에게 물어보니 저 두개의 라이브러리를 사용해서 데이터를 두 쪽에서 받아온다고 한다. 물어보길 잘했다.