1. 프로젝트 설명
- 어떤 프로젝트를 진행하였는지
연구실에서 이미 MATLAB으로 개발되었던 프로그램을 웹 버전을 개발하는 프로젝트를 진행하였다.
증기침입 위해성 평가를 진행할 수 있는 프로그램이다. (https://rapvi-ku.web.app/)
이 프로젝트의 특징은 다양한 종류의 많은 입력값들을 받고, 결과 값을 시각화해주는 것이라고 할 수 있을 것 같다.
- 프로젝트의 목적
MATLAB으로 개발된 프로그램의 단점을 극복하고자 하였다.
MATLAB으로 개발된 프로그램의 경우, 이용하고자 하는 사람의 컴퓨터에 MATLAB 프로그램이 설치가 되어있어야 한다.
또한 그 프로그램의 용량이 꽤나 무겁기 때문에 이 프로그램이 필요할 때 손쉽게 접근하여 사용하기에는 무리가 있었다.
따라서 이 프로그램의 기능들을 그대로 웹으로 옮겨 구현함으로써 사용자가 원할 때 링크를 통해서 사이트에 접속하기만 한다면, 별도의 프로그램 설치 필요없이 해당 서비스를 이용할 수 있게 함을 목적으로 하였다.
- 구현하고자 했던 주요 기능
1. 엑셀 파일에서 복붙한 데이터를 가지고 heat map 그리기
2. 사용자가 선택한 오염물질에 따라 입력값 자동완성 해주기
3. 사용자로부터 위경도 정보를 입력받아 부지 정보 표시해주기
4. 서버로부터 받은 계산 값을 시각화해서 보여주기 (그래프, 표, heat map)
5. 입력값과 계산값을 보고서 형식으로 PDF 파일 저장할 수 있게 하기
- 기술 스택
프론트엔드는 React.js를 이용하여 개발하였고, 백엔드는 flask를 이용하여 개발하였다.
2. KPT
- Keep
: 프로젝트 완료 후에도 간직하고 싶은 잘했던 것, 좋았던 것
1. 노션 문서 작성
팀별로 노션에 업무 진행 상황을 기록한 것이 좋았다.
진행상황을 표시함으로써 업무를 진행하고 있는 사람 뿐만 아니라 팀원들도 서로의 업무 진행 상황을 파악할 수 있어서 좋았다. 특히 나의 경우에는, 프론트엔드 요청 사항 노션 페이지를 하나 따로 만들어, 팀원들의 자잘한 업무 요청을 받은 후, 자체적으로 우선순위를 세우고 진행상황을 표시해주었다. 이를 통해 좀 더 효율적으로 업무를 진행할 수 있었다.
2. 정기 회의 전에 일주일 간 업무 내용 축약 보고
사실 이 부분은 20년도에 스타트업 인턴 근무하면서 배웠던 점을 적용했는데 좋았다.
회의 전에 슬랙에 각자 완료한 일 / 진행 중인 일 / 논의하고 싶은 사항 을 올리는 것이다.
이를 미리 작성하니, 회의가 효율적으로 진행되어 좋았다.
3. 스프린트 일정
(어쩌다보니 4월 1일에서야 일이 끝났지만) 원래 프로젝트 일정이 12월 ~ 2월로 약 3개월의 짧은 기간이었기 때문에 다소 속도감 있는 프로젝트 진행이 필요했다. 따라서 기능들을 일주일 단위로 나누어 개발 계획을 세워 진행하였다.
물론 계속 기한이 늘어지고 여러 가지 변수가 생겨서 이를 맞추지는 못했지만, 계획이라도 세웠기 때문에 이만하게라도 끝낼 수 있었다고 생각한다.
4. 배포 및 유지보수 비용 계획 수립
이번 프로젝트에서 색다르게 경험할 수 있었던 것 중의 하나였다.
개인 프로젝트나 토이 프로젝트에서는 신경 쓸 필요가 없었지만, 연구실에서 진행하는 프로젝트인 만큼 비용적인 측면도 고려해야 했고 특히나 프로젝트가 끝난 후에도 나랑 백엔드 개발자가 항상 붙어서 일해줄 수 있는 상황이 아니었기 때문에 이에 대한 계획이 필요했다.
웹 개발에 대한 배경 지식이 그나마 내가 제일 많았기 때문에 (신이시여...) 배포와 유지 보수 측면에 대한 문서를 작성했다.
이를 통해 정말 다양한 회사에서 배포 서비스를 제공한다는 것도 알게 되었고, 여러 플랜들의 장단점을 비교해볼 수 있었다.
5. 일단 해보기
회의 할 때마다 가장 많이 들은 말은 '이거 가능한가요?' 였던 것 같다.
물론 속으로는 '아니요' 했지만 '일단 해볼게요'로 대답한 후 일주일간 구현해내는 과정에서 나 스스로 기술적으로든 인내심이든 많은 것을 기를 수 있었다.
- Problem
: 프로젝트 중 겪었던 어려움(기술, 소통, 협업, 에러 등 프로젝트 진행 관련된 그 어느것이든) / 프로젝트 완료 후에도 아쉬움으로 남는 것
1. 소통 및 협업
지금까지 내가 해왔던 프로젝트들은 개인 프로젝트이거나 개발에 대한 이해가 잘 되어있는 사람들과 함께 진행한 프로젝트였기 때문에, 이번 프로젝트를 진행하면서 소통 및 협업 부분에서 어려움을 다소 많이 느꼈다.
일반적인 기획 - 개발 의 구조가 아닌, 연구 - 기획 - 개발 로 팀이 나누어졌고, 개발 분야에 대한 협업이 처음인 팀원들이 있었기 때문에 업무 초반에는 연구 - 백엔드 / 기획 - 프론트엔드 로만 나누어 소통이 이루어지는 문제가 발생하였었다.
다음부터는 프로젝트를 시작할 때 팀원 전체의 사전 지식을 확인하고 협업 가이드라인을 확실히 하는 것이 필요할 것 같다는 생각을 했다. 또한 개발 팀원이 조금 더 있어서, 진행하고 있는 작업이나 앞으로의 계획을 세울 때 피드백을 주고 받을 수 있다면 더 좋은 협업을 할 수 있을 것 같다.
2. 배포 및 서비스 유지
프론트와 백을 나누어 배포하는 방식을 선택하였다.
프론트의 경우는 Google Firebase에서 제공하는 호스팅 서비스를 사용하였으며, 백의 경우는 Pythonanywhere를 사용하였다.
프론트 : 처음에는 cloudtype의 배포 서비스를 이용하였었다. 이를 선택한 특별한 이유는 없었고, 지난 프로젝트 때 해당 서비스를 이용하였는데 오류도 거의 없고 사용 방법이 편리하고 간단했기 때문에 선택하였다. 하지만 백엔드와의 소통 과정에서 자꾸만 405 error가 발생하였고, 며칠 밤낮을 찾아보아도 해결되지 않아 Google Firebase에서 제공하는 호스팅 서비스로 옮기게 되었다. 옮겼더니 405 error가 발생하지 않았고 왜 그러는 지는 아직까지도 미스테리이다.
백엔드 : 큰 문제는 없지만, pythonanywhere의 사이트 특성 상 무료 서버를 사용하려면 3개월마다 서버 사용 연장 버튼을 수동으로 눌러줘야 한다는 문제가 있다. (이게 큰 문제일수도) AWS 같은 다른 플랫폼을 사용하면 이런 문제는 없어지지만, 백엔드 개발한 분이 이 부분을 해결하지 않고 가셔서.. 유지 보수 측면에서 조금 마음에 걸린다.
3. 기술
1) 다양한 형태의 많은 입력값
다양한 형태의 많은 입력값이 존재했기 때문에, 이를 관리하는 부분이 생각보다 어려웠다.
백엔드에서 로그인 기능을 구현하지 않아 사용자를 식별할 수 있는 방법이 없어, 단계별로 입력값을 백엔드에 넘겨주는 것이 아니라 여러 가지 입력 단계 중 마지막 단계에서 모든 입력값들을 한 번에 백엔드에 전송해주는 방법을 사용하였다.
값에 대한 유효성 검사나 타입 검사를 모두 프론트엔드 단에서 해결해야 했다. 또한 단계가 넘어갈 때마다 입력값들을 프론트가 가지고 있어야 했기 때문에 스토리지에 저장하는 방식을 선택하였고, 이로 인해 모든 변수들이 문자형으로 변환되고 이를 다시 사용할 때는 다시 알맞은 타입으로 변형시키는 과정이 필요하였다.
2) 보고서 형태의 PDF 파일 생성
사실 이 기능은 공식적인 업무가 끝나고 추가 잔업을 한 부분이라 다소 얼렁뚱땅 진행되었다.
html 내용을 pdf 파일로 변환하는 과정에서 2가지 라이브러리를 사용하였다.
먼저 html2canvas를 이용해서 html을 이미지로 변환하였고, 이후 jsPDF를 이용해서 이미지를 pdf로 변환하였다.
기능 자체는 잘 구현이 되었는데, 변환 속도가 다소 느리다.. 한 30초~1분 가량 소요되는 것 같다.
그리고 구글맵의 이미지는 pdf 파일 상에 나타나지 않는다. 이 부분은 구글맵에서 막아놓은 건가?
- Try
: Problem 중 해결된 사항에 대한 해결 방법 / 해결되지 않은 사항에 대한 피드백
1. 타입스크립트 (Problem 3-1에 대한 해결 방법)
이제 와서 백엔드가 사용자를 식별할 수 있는 기능을 구현하는 것은 무리이기 때문에, 현재 JavaScript로 개발되어 있는 프로젝트를 TypeScript로 리팩터링해보기로 하였다.
중요하게 생각하고 있는 작업 중 하나는 변수의 Type을 관리하는 파일을 만드는 것이다.
(참고하고 있는 블로그 글 : https://velog.io/@upisdown/React-JS-to-TS%ED%83%80%EC%9E%85%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-%EB%B3%80%ED%99%98)
타입스크립트 문법 자체는 공부를 했는데, 이를 리액트에 직접 적용하려니 다소 어렵다.
그치만 해봐야지.
3. 느낀점
- 기술
일단 해볼게요 -> 만들기 -> 성장
아예 구현 못하는 기능은 없는 것 같다. 붙잡고 있으면 만들어지긴 한다는 것을 알게 되었다.
일단 그냥 해보는 게 정말 중요한 것 같다.
대충이라도 만들어놓고 나중에 더 실력이 늘면 그 때 더 발전시키는 거다.
- 감정
좋은 협업이란 무엇일까에 대해서 깊게 생각해볼 수 있는 기회였다.
다양하고 많은 사람들이 있다는 것을 깨닫게 되었고 서로 맞추는 과정이 꼭 필요하다는 것을 알게 되었다.
그리고 소통할 때는 말을 부드럽게 하는 것이 필요하다는 것을 배울 수 있었다.
※ 회고록 작성하는 방법 참고
[프로젝트 회고] 회고 작성법
프로젝트를 마친 뒤 해당 프로젝트의 경험이 온전히 내 것이 될 수 있도록 프로젝트 회고를 하고자 한다.
velog.io
'개발 일지' 카테고리의 다른 글
🍀 lucky template : 지원서 편리하게 작성하는 서비스 개발 일지 (0) | 2023.10.22 |
---|---|
맛집 검색기 React 리팩터링 (0) | 2023.09.15 |
배포 및 운영 비용 (0) | 2023.01.10 |
[개발일지] 하이디라오 훠궈 소스 백과사전 (0) | 2022.12.07 |
맛집검색기 리팩터링 (0) | 2022.10.01 |