MARS 프로젝트 (Management Automated Reporting System)
공사현장에서 사용하는 장비에 gps디바이스를 부착하여 장비의 현황을 실시간 모니터링하며
장비를 선제관리 하기 위한 시스템
✅ 들어가며
1개월간 무스마란 회사에서 프론트엔드 개발자로 인턴을 하게되었다.
처음엔 ‘인턴이 완성한 프로젝트가 이 회사에 영향을 미치는게 있을까?’ 의문이 들었는데
여쭤보니 내가 한 프로젝트가 고객사에게 샘플 제품으로 보여줄 때 쓰일 수 있다고 한다.
그래서 단순히 과제를 완성해야 한다는 마인드가 아닌, 실제 고객들이 원하는 제품을 만들어야 한다는 생각을 갖고 이 프로젝트에 임하게 되었다.
✅ 기획을 하다
1) 멘붕의 기획
실제 회사의 서비스에 대한 기능구현 명세서를 받고 우리는 멘붕이였다.
공사현장 이라는 생소한 도메인과 기획은 처음이라 처음엔 정말 막연했다.
용어 조차 이해하기 힘들었고 회사 제품인 사이트를 몇 개 참고하긴 했지만 처음엔 감이 잘 오지 않았다.
2) 적극적인 질문
그러나 일단 우리는 매일 아침 회의때마다 우리가 겪고있는 어려움이나 질문사항을 정리해서 회의에 들어갔고 시간이 지나니 우리가 해야할 부분을 캐치할 수 있었다.
이후 나와 같은 프론트인 해뤼님과 같이 남아서 일주일간 스토리보드를 구상하였고,
그 스토리보드를 토대로 백엔드분들과 사수님의 피드백을 덧붙여서 진행되었다.
3) 문서로 소통하기!
스토리보드를 구상하기 전엔 말로만 소통하다보니 같은 말을 해도 모두 다르게 생각하고 있었다.
오랫동안 소통하며 나눴던 얘기들을 다음날 다시 얘기해보니 4명의 말이 모두 달랐다.
그래서 좀 더 명확한 소통을 위해 프론트에서 스토리보드를 만들었고 그 토대로 대화를 하니 좀 더 명확하게 소통할 수 있었다.
기획을 하면서 다시 느끼는 점이지만 모든 소통은 문서로 근거를 남겨놓는게 모두에게 좋을 것 같다는 생각을 하게됐다.
소통의 오해가 없도록 명확히 근거를 남겨놓는게 앞으로 개발자로 일할 때도 좋을 것 같다.
✅ 느낀점
📍 잘한점
1. 반복되는 UI, 컴포넌트로 만들어 재사용
여러 페이지에서 비슷한 UI가 있었다.
그래서 초반에 설계시 어떤 부분을 공통 컴포넌트로 만들 수 있는지 고민했다.
그러나 같은 컴포넌트를 쓰더라도 조금씩 다르게 스타일링을 줘야하는 부분이 있어서
그 부분을 어떻게 해결해야 할지가 난관이였다.
고민끝에 이렇게 다른 부분은 다 prop으로 받아서 한 컴포넌트를 써도 상황에 맞게 다른 UI가 그려질 수 있도록 하였다.
이렇게 처음부터 설계에 대한 고민을 하고 진행하니 컴포넌트를 만들어 놓기만 하면 그 뒤론 쭉쭉 진행이 되었고, 초반 설계의 중요성에 대해 느낄 수 있었다.
2. 주도적으로 기획을 진행했다.
기획은 처음이라 어떻게 해야할지 너무 추상적이였다.
만들어야 하는 기능내용이 담겨진 텍스트 항목만 보고 기획을 해야했다.
기획을 고민 할 수록 내가 이 앱의 사용자라면 어떨까? 라는 생각을 많이 하게됐다.
이렇게 사용자 관점에서 생각해본 적이 처음인 것 같다.
사용자 관점에서 바라보고 어떻게 하면 사람들이 이 앱을 사용해줄까?란 생각을 갖고 기획을 하다보니 내가 생각한 기획에 더 확신이 생기곤 했다.
나는 그냥 프론트엔드 개발자는 이미 기획된 내용을 코드로 페이지를 잘 구현하는 거라고 단순하게 생각했다.
그러나 이미 설계된 기획만 보고 시스템에 대한 사고없이 코드만 잘 치는게 중요한게 아니란 걸 깨달았다.
코드를 구현하는 단계 보다도 더 높은 단계에 있는 추상화 단계를 생각해보아 이 시스템의 가치에 대한 이해를 전제로 기능을 구현해야 하는 것이고 코딩은 그 수단일 뿐인 것이다.
앞으로 코딩을 넘어서 이 기능의 의미와 이 시스템에서의 유기적인 관계를 사고하도록 시도해봐야겠다.
📍 회고할 점
1. 상태관리에 대해 고민해보기
이번 프로젝트에서 상태관리를 처음 해봤다.
처음이다 보니 어떤 데이터를 store로 관리를 해야할지 감이 잘 안왔다.
그래서 코드를 치다가 멈추고 보니, prop으로 같은 값을 계속 보내고 있는게 보였다.😐
그래서 다시 그 데이터를 store로 관리하도록 수정했는데, 처음부터 이렇게 store로 관리할 데이터를 파악하는게 아직 미숙한 것 같다.
이번 프로젝트를 경험으로 상태관리에 대해 제대로 공부할 예정이다.
2. 짧은 주기의 프로토타이핑 실패
기획이 일주일동안 이루어졌는데, 이렇게 기획이 길어진 이유는 가설을 확인받는 주기가 너무 길었다.
일단 기획에 대한 가설을 세우고 빨리 피드백을 받아서 버리는 내용을 줄였어야 했는데
우리는 너무 많은 내용을 한번에 확인받으려 해서 피드백을 받으면 버려야 할 부분이 많았다.
이 산업에 대한 도메인 지식이 없어서 용어 파악하는데도 시간이 걸리곤 했는데
낯선 지식일 수록 나 혼자 그 정답을 찾으려 하지 말고
일단 내가 생각한 대로 내어보내고 자주 확인을 받아 빨리 방향을 잡았어야 했지 않나 생각된다.
✅ 내가 기여한 기능들
🔆 기획
- 앱의 모든 페이지 기획
- ppt를 통한 스토리 보드 작성 후 내용 공유
🔆 공통
- 초기셋팅
- 토스트 메세지 - Context API 사용
- 삭제 확인 모달창 - 공통 컴포넌트로 만들어 전역에서 재사용 가능하도록 구현
🔆 메인화면
1. 구글지도
- 일반지도 , 위성지도
- 마커 : 장비의 위치를 아이콘으로 표시, 장비 가동 상태에 따른 아이콘 색상 변경
-
클러스터 : 지도 축소시 마커가 하나로 합쳐지는 기능
-
오버레이 : 마커 클릭시 오버레이에 해당 장비 이름 출력
-
GroundOverlay : 배경이미지에 공사현장 도면을 깔음
( ※ 회사 보안상 도면은 일반 이미지로 대체함)
2. 날씨
- openweather 날씨 api 활용 : 지도 중심 좌표를 기점으로 api 호출 , 5일치 날씨가 보여짐
3. 대쉬보드
- 장비, 디바이스 실시간 모니터링 : 10초마다 실시간 데이터가 들어와 실시간으로 데이터가 변함.
( ※ 실시간 데이터 받는 시스템이 구축되있지 않아 실시간 데이터 변동 처리 불가했음)
🔆 장비 디테일 페이지
1. 반복되는 UI , 컴포넌트로 만들어 재사용
- Input box , Select box
- 로그 리스트 부분
2. 구글지도
해당 장비의 위치를 구글지도에 표시
3. CRUD
-
GET
- 장비 정보 데이터를 store에 담아 관리
- MobX의 observer를 통한 변경된 store값을 자동 리렌더링
-
PATCH : 장비 정보 edit
-
POST : 장비 수리 이력 등록기능
-
DELETE : 해당 장비와 연결된 디바이스를 매칭 해제
🔆 디바이스 디테일 페이지
1. CRUD
- GET
- 디바이스 정보 데이터를 store에 담아 관리
- MobX의 observer를 통한 변경된 store값을 자동 리렌더링
- PATCH : 디바이스 정보 edit
- POST : 디바이스 수리 이력 , 배터리 교체 이력 등록기능
- DELETE : 해당 디바이스와 연결된 장비를 매칭 해제
