[SSAFY] 특화프로젝트 Vincent Run Gogh 회고록

러닝 경로를 추천해주고, GPS를 활용해 러닝 경로로 그림을 그리는 Mobile App

들어가기 전에,,

어쩌다 공통 프로젝트 때 알게된 친구가 팀 제안을 줘서 들어가게 됐다.
나와 다른 프엔 팀원 빼고 이미 공통프로젝트를 같이 했던 팀원들이라 처음에는 소외감을 느낀다거나 어색하지 않을까 싶었지만 모두들 반갑게 맞아주고 정말 정말 성격이 잘 맞아서 😁 하루만에 친해지게되었다ㅋㅋ (애초에 그런거 잘 안 느끼면서 걱정만 함 ㅋ)

편한 분위기에서 프로젝트 주제가 정말 많이 나왔지만 모두의 맘에 딱 드는 주제가 없어 반려하고 하나씩 제외하다 보니 결국 마지막에 남은 주제를 선택하게되었다ㅜ 이 부분에는 아쉬움이 있다.
그럼에도 불구하고 모두 최선을 다했고 할 수 있는 범위 내에서 최대한 고도화시킨거 같다.

프로젝트 소개

앱 프로젝트 / 6인 프로젝트 / 2024.08.26~24.10.11

사용자가 지도에 직접 그린 그림을 기반으로 도로 경로를 설정하고 러닝을 통해 맵에 드로잉을 할 수 있는 서비스.
커뮤니티를 통해 다른 사용자가 만든 경로나 뛴 경로를 자신의 경로로 추가할 수 있습니다.

기획 과정

전 프로젝트와 다르게 회의록을 혼자 작성하지도 않고 시키지 않아도 다들 자기 할 일을 알아서 하니까 너무 편하고 좋았다! 이거시 팀프로젝트?!
빅데이터 분산이 주제인 만큼 데이터 확보에 어려움이 있을 것이라 생각했고, 실제로도 그러했다.
그래서 데이터부터 찾고 주제를 정하자는 의견과 주제를 정하고 데이터를 찾자는 의견으로 나누어졌다. 이런 고민이 무색하게도 데이터를 찾으면 주제가 별로였고, 주제를 정하면 데이터가 마땅치 않았다.
무수한 아이디어 회의들,,

여기서 내가 하고 싶었던 주제는 스마트팩토리 MES었다. 그래서 적극적으로 데이터도 찾고 구상도 하면서 디지털 트윈까지 해보면 어떨까 찾아보았지만 다들 관심 분야도 아니었을 뿐더러, 코치님께서 기업 연계 프로젝트를 스마트팩토리와 관련된 주제로 진행했었는데 고충이 꽤나 많으셨는지 재고를 권하셔서 이 친구도 버려지게 되었다,,😥

지금와서 생각해보면 조금 더 어필해볼걸 후회가 든다. 자율 프로젝트에 파이프라인 디지털 트윈을 주제로 프로젝트를 완성도 있게 한 팀을 보고 1. 나도 해보고 싶다 2. 아 빅데이터가 아니었다면 모니터링하는 부분을 축소해서 어느정도는 구현할 수 있었을텐데 하는 아쉬움이 들었다.

그래서 회고를 하면서도 다시금 느끼는 것은 나한테 프로젝트 주제는 동기부여와 성취감에 정말 중요하다!
회사에 가면 원하는 프로젝트를 선택할 순 없을테니 원하는 산업의 회사로 취업하자!
최근 서류가 잘 안되서 은행권이나 아무 산업군의 IT라도 가자 라는 생각이었는데, 과연 가서 만족할 수 있을까? 라는 고민이 들게 된다,,

도전 과제 및 해결책

Svelte 도전기

전부터 관심 있던 스벨트!
프엔 팀원을 꼬셔 스벨트를 써보기로 했다. 너무 고맙게도 흔쾌히 오케이하고 오히려 먼저 공부해와서 팀원에 대한 신뢰와 공부에 대한 자극을 받을 수 있었다.

🤔왜 스벨트를 쓰고 싶었는가?

1. 리액트를 쓰면서 useState와 다른 컴포넌트 구조 코드(boilerplate) 등 들어가는 반복되는 코드도 너무 싫었고
2. 스벨트는 컴파일러로 virtual DOM을 쓰지 않고 실제 DOM에 반영하여 reactive하게 만든다는 것이 기존에 사용해왔던 react와 vue와 비교했을 때 매력적으로 느껴졌다.

하지만(1),,
리액트를 사용했을 땐 구선생에게 물어보면 한글로 번역된 공식 문서부터 티스토리, 스택오버플로우 등 다양한 자료들이 있어서 비교적 쉽게 공부할 수 있었고 다양한 라이브러리가 있어 이거 없어? 이런 일이 별로 없었다..

그러나 스벨트는 간간히 정리한 블로그는 있었지만 공식 문서의 내용을 재정리한 느낌이지 기능적인 구현을 한 글은 리액트에 비해 많지 않았다.

그렇기 때문에 이번 프로젝트에서는 공식문서를 많이 참고하고 날것? 의 코드를 많이 참고한거 같다. 또한 이전까지는 에러를 해결하지 못할 때만 잠깐 쓰던 gpt햄을 결제할 수 밖에 없었다. 그래도 낮은 러닝 커브의 프레임워크였기 때문에 빠르게 익숙해질 수 있었다!

하지만(2),,
프로젝트를 위해 빠르게 익혔기 때문에 생명주기라던가 반응성, store에 허점이 있었고 화면 랜더링 관리에 어려움이 있었다. 그리고 리액트만 하다가 해서 그런지 직접 DOM에 접근해 이벤트를 설정한다던가 하는 방식이 어색했다.

또한 외부 라이브러리(Chart.js)와 함께 반응성 변수를 사용하는 경우 컴포넌트 리렌더링이 원하는 시점에 이뤄지지 않는 문제도 있었다.

이렇게 적고 나니 어려움이 많았네 ㅎ

JavaScript를 -> TypeScript

프로젝트 초기에는 JavaScript를 사용했지만 일주일 정도 진행을 한 상태에서 TypeScript로 변경하자고 팀원에게 의견을 물었다.
변경하고 싶은 이유와 변경 소요 시간, 관련 자료들로 설득을 하니 주말동안 고민을 해보겠다고 하더니 이번에도 팀원은 타입스크립트에 대해 잔뜩 찾아보고 자신의 코드를 어느정도 변경한 채로 다음 회의에 왔다... 진짜 머싯는 사람,,😮

TypeScript를 도입한 이유로는

1. 정적 타입 체크
   백에서 받고 보내는 데이터의 타입을 확실히 하고, 위치 데이터를 가공하는데 일관성을 주고 싶었다.

2. 자체적인 문서화, 유지보수성 향상
   팀 프로젝트에서 가장 어려운 점은 다른 팀원의 코드를 이해하고 사용하는 것이라 생각한다. js를 썼을 때는 내가 사용하고 싶은 코드를 이해하려면 전반적으로 다 이해해서 이 변수에 어떤 값이 들어가는지 다 확인해야했지만, ts에서는 타입 정의 코드만 보면 되니 코드 가독성이 높아질 수 밖에 없다. 실제로도 사용해보고 느낀 점이다!

3. 그냥 사용해보고 싶었음!
   제일 큰데,, ㅋㅋ 채용 공고나 job script에 ts는 자주 나오니 사용해보고 싶었다ㅎ

tsconfig.json 파일 등을 만들고 설정을 바꾸면서 js 프로젝트를 ts로 변경하는 작업을 진행했는데
타입을 지정하면 typescript preprocessor 에러가 발생해서 결국 프로젝트를 ts로 다시 생성했다ㅜ

gps 보정

다른 러닝 앱처럼 일정 시간 동안 위치를 받아오며 연결해서 선을 그려줘야했는데 PWA여서 그런지 gps가 가끔(자주) 튀었다.
기기마다 또 내/외부 마다 gps의 정확도가 천차만별이라 라이브 시연이 걱정이었고, 실제로 시연때도 gps가 말썽이었다.

이부분은 프로젝트 발표 전날 새벽까지도 계속 리팩토링하며 최적화를 하려고 노력했지만 PWA의 한계라 생각하여 많이 아쉬웠다.
다시는 gps 프로젝트를 안하리 다짐을 하며,,,😥

최적화는 아래와 같은 로직으로 진행했다.

1. 이전 위치와 현재 받아온 위치의 거리를 계산하고, 속도 추정
2. 이전까지의 속도와 설정한 최대 속도와 비교
3. 계산된 속도가 최대 속도를 초과하면, 위치 값 무시

이런 간단한 로직을 적용했더니 여러 예외 사항이 발생했다ㅋㅋ
대표적으로는 잘못된 위치를 지속적으로 받아올 경우, 이동이 감지 되지 않았다!!! 망해따 싶었다ㅎㅎ

그래서 2차 최적화에서는 초과 속도 감지 시 최대 이동 가능 거리를 고려하여 좌표를 조정했다.

위의 로직에서 '무시'가 아니라 이동하고 있는 방향을 계산하여 그 방향의 좌표값으로 값을 바꾸었다.

1. 튄 방향으로의 방향 벡터 계산
2. 이전 속도 값으로 Math.sin(radians)와 Math.cos(radians)을 사용하여 위도와 경도를 조정
3. 조정된 값 반환

비동기 작업

이 부분도 마지막까지 최적화를 한 부분인데 실제 코드에 반영되진 않았다. 조금 더 리팩토링이 필요해보인다.

서비스에서 Leaflet 맵을 html2canvas를 사용해 지도 캡처하여 이미지를 뽑아내는 과정이 있는데
여기서 맵이 다 로딩 되지 않았을 때 사용자가 캡쳐 버튼을 누르면 맵이 누락되는 버그🐛가 있었다.

그래서 Leaflet 맵의 로드 완료 여부를 체크하고, 완전히 로드되기 전에 캡처를 시도할 경우 사용자에게 알림을 주고 재시도를 유도하는 로직을 구현했다.

1. 로드 상태 확인 및 대기
   tileLayer.on('load')과 map.on('movestart')을 통해 맵의 로딩 상태를 지속적으로 체크하여 화면 캡처를 실행하기 전에 isMapLoaded 플래그를 확인하며 맵이 로드될 때까지 비동기 대기(Promise) 로직을 사용했다.

2. 타임아웃 로직 추가
   만약 로드 상태 확인이 일정 시간(20초) 내에 완료되지 않을 경우, 타임아웃 에러를 발생시키고 사용자에게 재시도를 요청하는 피드백을 제공했다. 실제 사용해보니 어떤 기기에서는 바로 되고 여러번 반복해도 캡쳐가 안되는 기기가 있었다. (대체 왜..?)

3. 로딩 중 사용자 경험 개선
   캡처 작업이 진행되는 동안 사용자에게 로딩 알림(loadingAlert)을 표시하여 작업 진행 상황을 명확히 전달하고, 오류 발생 시 명확한 메시지를 통해 재시도를 유도하였다.

이 작업을 통해 비동기 프로세스와 관련된 문제를 사전에 예측하고 효과적으로 처리하는 방법을 설계할 수 있었다.

향후 계획

웨어러블 기기용 앱을 만들어서 연동시키는 건 어떤가 싶다.

마무리 및 후기

배운 점

화면 설계서 작성
프로젝트 설계 때 화면 설계서를 자세히 작성하여 프로젝트 구조와 사용자 인터페이스를 명확히 정의했다. 확실히 설계를 꼼꼼히 할 수록 개발이 편하다

아쉬운 점

공통 때와 마찬가지로 네이티브 앱으로 만들었으면 더 높은 완성도가 나왔을 것 같다.
하지만 위치가 잘 받아와졌다고 가정하면 PWA로 배포한 선택은 사용자 접근성도 좋아서 싸피 프로젝트로는 맞는 선택이었다고 생각한다.

또한 중간에 ts로 변경하여 타입 정의와 정리를 못해 ts를 100% 사용했다는 느낌이 안들었다. 중간중간 any도 많이 쓴거 같다 ㅎ
다음에 할때는 설계 때 타입 명세서를 작성하여 좀 더 typescript틱 한 코드를 짜고 싶다.