비전공자 주니어 FE 개발자의 2024 - 1분기 첫 회고

작년 11월 초에 입사한 후, 벌써 4개월이 지났다.

회사의 소스코드 구조를 100% 파악하진 못했지만, 풀무원 1차 도입 프로젝트로 마무리되어 성공적으로 마무리 되어가고 있다.

1분기의 마지막 주이므로 1분기 회고를 작성해보려고 한다.

POC

처음 입사했을 때부터 아직 우리 회사의 솔루션을 사용하는 고객사가 없었다. 그래서 고객사 영업을 위해 미팅에서 사용할 POC 시연을 위주로 업무를 진행하였다.

POC(Proof of Concept)란, 새로운 기술을 도입할 때 이름 검증하기 위한 과정

WATA는 기존 물류 프로세스에는 없던 3D, Lidar 등 디지털 트윈 기반 물류 통합 관리 플랫폼을 제공하려고 한다.

내가 처음 입사하여 맡았던 업무가 기억이 난다. 고객사 POC에 사용하기 위해 Unity로 구현된 모니터링 화면에서 물류 지오펜스를 클릭, 더블클릭 했을 때 실행되는 로직을 수정하는 작업이었다. 처음 코드를 접해보고 든 생각은 방대한 컴포넌트다.. 였다.

 

해당 컴포넌트의 구조를 파악하고 추후에 기능을 추가하거나 할 때 용이하게 하기 위해 파일을 기능, 관심사 별로 구분하였다.

이렇게 시도한 작업물들을 토대로 이후 풀무원 프로젝트 도입 시 설계와 구현에 많은 시간을 단축할 수 있었다.

풀무원 1차 프로젝트 (23.12 ~ 24.03)

드디어 처음 입사한 이후로 고객사를 상대로 실제 서비스로 진행했다. 내가 맡은 업무는 다음과 같다.

• Unity로 구현된 화면에서 FE와 Unity 간의 API 통신
• Unity 화면 좌측 데이터를 나타내는 패널 구현
• 물류 배치된 데이터를 보여주는 대시보드 페이지 구현

 Unity와 FE 간의 기존 API 문서가 정리되지 않아 소통에 어려움이 있었다. 이력을 남기기 위해서라도 문서정리는 필수라고 생각된다. 또한, 그 과정에서 BE API 연동도 추가되어 하나의 문서에서 과정에 따른 Unity, BE API 문서를 정리하여 로직의 순서와 흐름을 판단하는데 용이했다.

 

 데이터를 보여주는 페이지를 구현할 때에는 React-query 라이브러리를 사용하여 Data Fetching API 설계와 최적화를 하였다. 무한스크롤 컴포넌트가 기존에 구현되어 있었는데, 네트워크 탭을 확인해보니 2회 요청되는 문제를 발견했다. 원인은 무한스크롤 컴포넌트 하단의 div 태그가 일정수준 화면에 노출되었을 때, 다음 페이지를 요청하는 로직에서 초기요청을 보내고 div 태그도 노출 되어 2번 요청이 발생한 것이었다. 초기 요청의 상태에 따라 div 태그를 노출하도록 수정하여 API 요청을 최소화 하였다.

 

 이외에도 Unity에서 호버가 발생할 때마다 BE로 API를 요청하는 로직을 FE가 BE로 부터 응답받은 데이터 참조하여 Unity에 응답메세지를 보냄으로써 불필요한 BE API 요청을 줄일 수 있었다.

👍 Liked

1. Unity, FE API 통신 문서 작성

 

모니터링 화면에서 Unity와 message를 통해서 통신을 하는데, 이에 대한 문서를 정리하여 문서를 통해 협업하면서 소통의 오류를 줄여서 좋았다.

 

2. Rechart 커스텀 컴포넌트 storybook 문서 작성

 

이전 회사에서 차트 라이브러리를 적용하는데 오랜 시간이 걸렸던 경험이 있었다. 다른 개발자도 차트를 사용할 때마다 오랜 시간이 걸리는 것을 줄여주기 위해 Storybook으로 차트 컴포넌트 사용법에 대한 문서를 작성하여 업무의 효율을 높일 수 있어서 좋았다.

 

3. Data Fetching 구조를 통일할 수 있어서 좋았다.

 

기존 컴포넌트에서 Data Fetching하는 로직이 중구난방으로 작성되어 있는 부분은 부모 컴포넌트에서 한번에 관리하도록 통일함으로써 전체적인 컴포넌트 구조를 통일할 수 있어서 코드의 가독성과 협업에 도움이 되어 좋았다.

 

4. 지라에 이슈티켓을 생성하여 작업을 하여 나와 다른 사람들의 업무를 파악할 수 있어서 좋았다.

 

지라에 이슈티켓을 생성하여 해당 작업 넘버와 feature 브랜치명을 일치시켜 작업을 하여 git 이력을 확인하는데도 용이하고 다른 사람이 어떤 작업을 하는지 파악하는데도 용이해서 좋았다.

📗 Learned

1. 리액트 리렌더링 시 Unity 에러의 원인을 배웠다.

 

모니터링 페이지에서 Unity 통신을 받아 FE 상태값을 변경해주는 로직을 listener로 등록해주고 있다. listener는 오직 Unity가 초기에 로딩되었을 때 한번만 등록해줘야한다. 그런데, listener 내부에서 상태값을 참조하게 되면 state가 변할 때마다 리렌더링이 발생하고 listener를 등록하는 로직이 다시 실행되어 Unity 에러를 발생시킨다는 것을 알게되었다.

이를 해결하기 위해 FE 상태값을 참조하지 않고 FE API 요청 → BE 응답 데이터 참조 → Unity 통신하는 구조로 해결했다.

 

2. Websocket 통신에 대해 배웠다.

 

HTTP 통신은 단방향 통신으로 클라이언트가 요청을 보내면 서버가 응답을 보내는 방식이다. 웹소켓 통신은 클라이언트가 요청을 보낼수도 서버가 요청을 보낼 수도 있는 양방향 통신이다. 웹소켓 통신은 주로 연결성을 지속하기 위해 사용한다. 그러므로 HTTP 통신에 비해 많은 리소스가 소모된다.

 

3. React-hook-form 라이브러리 사용이유와 방법을 배웠다.

 

RHF은 form 내부의 input들을 uncontrolled(비제어) 컴포넌트로 관리하여 state값과 state 변경 함수 로직을 최소화하고 리렌더링을 방지하기 위해 사용한다. 또한, 제출 시 schema를 적용하여 유효성 검사를 통과하지 못한 경우, 에러를 발생시켜 에러를 핸들링 하기에 용이하다. React-table 라이브러리와 함께 사용할 때, schema를 어떻게 설정해야하는지 몰라 애먹었는데 submit 함수 호출값을 확인하여 각 행별로 Input 값들이 어떻게 전달되는지 구조를 파악하고 schema를 정확히 적용하는 방법을 배웠다.

 

4. 페이지 이동 시 이전 페이지의 스크롤을 유지하는 방법을 배웠다.

 

스크롤을 유지하기 위해서는 스크롤이 발생하는 대상(DOM 요소)을 찾고 대상의 scrollTop 값을 참조하고 새로고침하더라도 유지가 되어야하기 때문에 storage에 저장해야한다. DOM 요소에 접근하기 위해 ref를 사용하고 이벤트 발생시 스크롤 위치를 storage에 저장한다. 해당 로직을 재사용하기 위해 useScroll이라는 훅으로 정의해두었다.

😅 Lacked

1. POC 프로젝트별 구분을 못해서 아쉬웠다.

 

물류타입에 따라 Rack형, 평치형, 대차형에 따라 동작하는 로직도 모두 다르고, 패널에 나타나는 정보도 모두 달랐지만 기존 POC에서는 하나의 방대한 컴포넌트에서 조건문으로 구분해주고 있어 추후 기능을 추가할 때, 오랜 시간이 걸린다.

이를 해결하기 위해서는 프로젝트별 POC용 기획이 재정이되어야 이를 기반으로 개발을 이어나갈 수 있는데 기획없이 POC를 보여주기 위해 그 때 그 때 개발에 요청하는 식이어서 구조 파악도 어렵고 작업시간도 오래 걸려서 추후에 이를 해결하고 싶다.

 

2. 라우터 구조 파악을 못해서 아쉬웠다.

 

플로팅 햄버거 버튼의 상태값이 세션 스토리지에 등록되어야 하는 이유에 대한 의문이 들어 코드를 살펴보니, 라우터 구조에서부터 문제가 비롯된 것 같다. react-router-dom 라우팅 랭크 기능으로 무한루프를 방지한다고 주석이 추가되어 있었지만 이해가 안되었다. 또한, Unity viewer의 라우터 경로와 실제 URL에 나온 경로가 일치하지 않는 이유도 모르겠다. 다음 분기 때는 프로젝트 별로 라우터를 구분하여 디버깅을 하여 라우터 구조를 이해하고 문제를 해결하고 싶다.

 

3. 테스트 코드 작성없이 작업해서 아쉬웠다.

 

상대방이 어떤 작업을 하는지까지는 이슈티켓을 통해 이해할 수 있었지만, 코드리뷰를 하거나 시간이 지나 다른 사람이 작성한 코드를 볼 때 이해가 안되는 부분이 있었다. 테스트 코드를 작성하여 작업을 하면 나중에 코드를 다시보더라도 테스트 코드를 통해 코드의 이해를 높일 수 있어서 유지보수성이 좋아질 것으로 생각된다. 2분기 때는 테스트 코드 작성으로 PR 코드리뷰를 적극적으로 진행해보고 싶다.

 

4. 회사 시스템에 대해 아쉬웠다.

 

QA 진행하기 5일전, 갑자기 기획 변경이 발생하였고 일정에 맞추기 위해 밤샘 야근을 해야하는 일이 발생한 적이 있다. 사전에 협의된 내용과 문서를 통해서 일이 진행되어야 하는데, 구두 혹은 채팅으로 업무가 전달되는 일이 간혹 있어서 소통에 오류가 생겼고 그 결과 일정 수립 실패 등등의 문제가 발생해서 아쉬웠다. 이를 해결하려면 문서화를 더욱 열심히 하고 공유를 밖에 없는 것 같다.