에브리타임에서 스크랩 200개를 받다.

노 기 훈·2025년 3월 7일

개인프로젝트

목록 보기

1/1

강의실을 찾아주는 웹사이트, uhdiro를 만들게 된 이유

매년 새 학기에 개강을 하면 새로 입학한 새내기 분들을 포함해 많은 한림대학교 학우분들이 강의실을 찾기 위해 한림대학교에서 제공하는 캠퍼스맵을 찾아보곤합니다.

캠퍼스맵은 각 건물들의 위치를 한 눈에 볼 수 있다는 장점이 있지만 강의실과 건물의 정보를 보고 찾아가기에는 어렵다는 점이 있습니다.

그래서 한림대학교의 학우분들은 에브리타임을 통해 본인이 찾는 강의실을 물어보곤 합니다.

에브리타임을 통해 직접 물어보는 방식은 정확하지 않은 정보를 얻을 수도 있고, 항상 도움을 받는 다는 보장도 없기에 많은 분들이 불편해 하고 있다는 것을 느끼게 되었습니다.

그래서 저는 강의실과 건물을 찾는 분들에게 조금이나마 도움을 드리고자

강의실,건물을 찾아주는 웹사이트를 만들어보자라고 생각하였습니다.

이런분들을 도와주고자 하는 분은 저말고도 저희 학과의 한 선배분도 계셨습니다.
그 분께서 제작한 웹에서의 문제점은 자신이 찾고자하는 건물이나 강의실을 찾기위해 여러 depth를 통해 접근(공학관 클릭→1층 클릭→ 사진에서 정보 획득)을 하고 강의실을 사진에서 어렵게 찾아야한다는 점이 있었습니다.
또한 검색이 불가하여, 본인이 찾고자하는 강의실 번호를 통해 건물을 알아내는 과정을 통해서만 건물을 검색할 수 있었습니다.

저는 기존의 웹을 개선하고자 검색을 통해 한림대학교의 건물과 강의실의 위치를 제공하는 웹사이트를 만들고 싶었습니다.

uhdiro의 상세한 제작 과정

1. MVP 기능 설정

먼저 웹에서 제공하고자하는 MVP 기능을 정리하였습니다.

강의실, 건물 번호와 이름으로 찾기
찾은 정보를 최근 기록 또는 내 장소로 저장
실시간 위치 제공
지름길 제공

기획 자체가 강의실과 건물을 쉽게 찾을 수 있는 웹이기 때문에 MVP역시 간소하다고 생각해서 여러 기능들을 덧붙일까 생각도 했습니다.

하지만 처음 MVP를 과하게 잡고 개발을 시작하면 계획 단계에서 고려하지못한 여러 상황때문에 일정이 미뤄지고 각 기능에 대한 퀄리티가 떨어지는 경우가 허다하다고 생각하여 위의 기능이라도 완벽하게 구현하고자 하였습니다.

2. 플랫폼 설정

보통 강의실을 찾을때는 책상에 앉기보다는 휴대폰을 들고 걸어다니며 찾을것으로 생각하였고, 이후 홍보하게될 에브리타임으로 배포하였을때 처음 유입되는 환경이 모바일이기 때문에 타겟을 모바일로 설정하였습니다.

밑의 사진은 출시 이후의 analytics의 분석 내용인데 역시 제 예상이 맞았습니다!!

3. 각 기능에 대한 상세한 로직 설정

디자인과 거의 같은 시점에 진행하였으며, 1차적으로 자필로 로직에 대한 구성을 하고 피그마(피그잼)으로 로직을 상세하게 설정하였습니다.

또한 각 기능에서 필요한 기술스택을 수집하고 테스트를 간소하게 진행하였습니다.

(저는 이 과정이 사소하지만 이후에 생길 트러블슈팅을 미리 예측하고 기능 개발의 단계를 가늠잡을 수 있다는 점에서 매우 중요하다고 생각합니다.)

기능 중 기록 저장 및 내 장소 저장을 하기 위한 방법으로는 회원가입을 하고 각 사용자의 정보를 기록하는 방식, 로컬스토리지를 통해 회원가입을 하지 않고 관리하는 방식을 생각하였습니다.

저는 장소를 저장하기 위해 회원가입을 한다는 점은 불필요하게 사용자의 정보를 받고, 사용자 경험 측면에서 좋은 점이 없다고 생각하여 과감하게 로컬스토리지로 회원 상태를 저장하고자 하였습니다.

4. 디자인 전 래퍼런스 수집

저는 디자이너가 아닌 프론트엔드 개발자이다보니 디자인 감각이 뛰어나지 않습니다!

따라서 카카오맵, 네이버지도맵에서 많은 참고를 받았습니다.

5. UI 디자인

래퍼런스에서 지도의 구성을 참고하여 ui를 개발하였습니다.
각 기능의 특색을 잘 표현하고자 하였습니다.

또한 모든 디자인을 한번에 끝내지 않고, 두 단계를 기준으로 디자인을 구성하였습니다.

검색 입력 → 결과창
결과창에서 결과 클릭→ 지도 표시

검색창에 사용자가 입력을 하고 결과창에 결과를 보여주는 것을 우선 디자인하였습니다.(개발 단계에서 이 기능이 우선적으로 개발된다고 생각하여서 그렇게 구성하였습니다.)

온전히 저의 감과 미약한 ui 지식을 총동원해 디자인을 했기 때문에 좋은 디자인인지는 사실 잘 모르겠습니다.

6. 개발환경 구성

사실 기능을 정리하고 디자인을 하는 과정에서 머리속으로 계속 생각하였기 때문에 어떤 프레임워크를 사용할지는 미리 정해둔 상태였습니다.

페이지 구성

우선 다른 맵 애플리케이션도 그렇듯이 라우터를 통한 하부페이지가 거의 없는 단일페이지를 생각하였습니다.

프레임워크 설정

검색엔진 측면에서 하나의 페이지만 검색하면 되기때문에 Next를 이용한 SSR보다는 React를 사용한 CSR이 적합하다고 생각하였습니다.

스타일링 라이브러리 결정

많은 고민을 했지만 빠르게 프로덕트를 개발해야했기 때문에 저에게 익숙한 라이브러리를 우선적으로 고려하였습니다.
따라서 Sass와 Styled-Component를 고민하였고 번들사이즈를 조금이라도 줄이고자 Sass를 선택했습니다!

개발환경 세팅

페이지가 하나기 때문에 한 페이지에 들어가는 중요 컴포넌트(header, map)와 중요 컴포넌트의 하부 컴포넌트 또는 비교적 중요하지 않은 컴포넌트(sidebar, modal)를 같은 components 파일 내부에 묶어 관리하는것에 대한 고민을 수차례했지만, 우선은 하나의 파일에서 관리를 하고자 결정하였습니다.

7. 개발

사실 개발 과정은은 정신없이 개발하였고 각 과정을 장황하게 설명드리기에는 어려움이 있어 키워드로 정리해보았습니다.

git 브랜치 전략 수립

우선 저는 dev, main, release 브랜치 3가지를 구성했습니다.

dev에서 각 기능을 개발하고 main으로 푸시를 하면 배포가 되는 방식으로 진행하였으며 main에서 release 브랜치를 분리하여 배포 버전을 관리하였습니다.

json데이터 2천줄 노가다

우선 사용자가 건물과 강의실을 검색했을때 결과가 나오기 위해서는 모든 건물과 강의실에 대한 정보가 필요합니다.

저는 학과 선배님께서 개발하신 사이트의 한림대학교 정보를 가져와 입력을 했습니다.

데이터는 모두 리액트 내부의 json에서 관리하였습니다.

(강의실에 대한 정보는 거의 변경되지 않아 매우 정적인 데이터라는 측면에서 따로 분리하지 않았습니다)

이 과정에서 꼬박 이틀이 걸렸습니다.

각 층에 대한 사진을 ai를 통해서 분석하려는 시도를 수차례했지만 정확하지 않았습니다. 또한 방안에 여러줄에 걸쳐 강의실의 이름이 있다면 각 줄을 다른방의 각줄과 매칭하여 결과를 반환해주었기 때문에 번거롭고 힘든 과정이지만 직접 입력을 했습니다.

자그마치 json파일이 2000줄이 넘어갔습니다.

사실 모든 과정중에서 가장 힘든 과정이었고, 그만할까 하는 생각도 더러 했지만 고민할때 마다 에브리타임에 올라오는 “땡땡강의실 어딘가요ㅠㅠ” 와 같은 글이 올라오는 것을 보면 포기할 수 없었던것 같습니다. (포기안한 나 매우 칭찬해~)

패널의 위치는…?

UI는 크게 헤더[제목, 사이드바, 입력창] / 맵으로 나눠집니다.

그리고 그 사이에 입력창에 데이터가 들어오면 펼쳐질 패널이 존재합니다.

패널의 위치에 대해서도 많은 고민이 있었습니다. 패널을 따로 컴포넌트로 분리하여 관리하고자 하였지만 분리를 하게되면 입력창에서 관리되는 많은 상태들이 전역으로 관리되어야 하고 이는 오버엔지니어링이라는 판단이 들어 헤더에서 같이 관리하였습니다.

전역으로 상태를 관리

작고 귀여운 기능들에 비해 전역으로 관리해야하는 상태들이 꽤나 많습니다.

우선 입력창에서 결과를 입력하면 입력한 값을 다른 컴포넌트(부모를 거치는 형제)인 패널 컴포넌트로 넘겨줘야 하기때문에 입력 상태를 전역으로 관리하였습니다

그후 입력에 대한 결과를 입력창과 패널에서 보여주고, 맵에도 표시를 해줘야하기 때문에 결과에 대한 상태도 전역으로 관리하였습니다.

결과는 크게 건물, 강의실로 나눌 수 있지만 각각의 데이터 구조가 꽤 달라 따로 분리하여 관리를 하였습니다.

그리고 마지막으로 관리하는 전역상태는 패널의 오픈유무입니다.

배포하고 테스트하는 과정에서 패널과 맵의 마커의 z-index에서 여러 문제(패널위에 마커가 표시되는)가 발생하였습니다.

해당 과정을 해결하기 위한 가장 명쾌한 방법은 패널의 open상태에 따라서 마커 표시 유뮤를 결정하는 것이었습니다.

따라서 패널 상태 역시 전역으로 관리하였습니다.

컴포넌트 분리

저의 요즘 가장 큰 관심사는 컴포넌트 분리가 아닐까 싶습니다.

컴포넌트를 분리하는 기준을 설정하고 어떤 시점에 컴포넌트를 분리할것인가.

정말 어렵다고 생각합니다.

그렇지만 저의 생각을 설명해보자면

재사용이 되는 컴포넌트라면 분리를 합니다.

재사용이 안되는 컴포넌트라면 일단 두지만, 추후에 분리가 재사용이 될 여지가 있다면 분리를 합니다.

또한 한 tsx파일에서 많은 컴포넌트를 분리하지 않는다면 가독성의 측면이 크게 떨어지기 때문에 어느정도 컴포넌트를 분리하는게 필요하다고 생각합니다.

컴포넌트를 분리하는 시점은 꼭 분리해야한다!라는 생각이 들면 바로 분리를 합니다.

하지만 컴포넌트를 분리하면서 여러 상태들 역시 분리가 되고 특정한 상황에서는 로컬 상태를 전역 상태로 관리해야하는 경우도 더러 생김을 경험했습니다.

때문에 저는 컴포넌트의 분리는 바쁘게 개발해야하는 상황에서는 잘 건들지 않고 리펙터링 과정에서 진행합니다.

위처럼 컴포넌트를 분리했다가 예상과 다르게 상태를 전역으로 관리하고 또 다른 상태가 추가되는데 그 상태 역시 전역으로 관리해야한다면 해당 컴포넌트를 분리하는것도 불필요한 과정, 오버 엔지니어링이라고 생각합니다.

mvp기능 수정

처음 설정한 mvp에서 제외한 기능은 다음과 같습니다.

내 장소 저장, 지름길 표시

내장소 저장 기능은 최근 기록을 더 자주 사용할 수 있겠다라고 생각하여 과감하게 mvp기능에서 삭제하였으며 지름길 표시는 mvp중에서 후순위였는데 시간상 포기했습니다..

새롭게 추가한 기능으로는 한림대학교의 날씨를 openweather api를 통해 얻어와 표시해주었습니다.

react-kakao-maps-sdk 사용기

카카오 측에서 카카오맵 api 관련하여 정말 상세한 설명과 높은 퀄리티의 example들을 제공합니다. 따라서 맵을 사용하는데 크게 어려움은 없었습니다.

배포

지난 캡스톤 프로젝트에서 aws를 이용해 route53, cloudfront, s3,heroku 등을 사용해 배포한 경험이 있습니다.

각 과정을 다시 한번 수행하는데 무리가 없으나 대학생인 저에게 aws에서 청구되는 금액은 생각보다 큰 금액이기 때문에 이번 프로젝트에서는 vercel로 배포를 하게되었습니다.

http와 https에서 다르게 동작하는 경우가 있기 때문에 프로젝트 초기에 배포를 진행하였습니다

배포 이후 테스트에서 만난 문제

카카오맵이 배포환경(모바일)에서 깨지는 문제

해당 원인에 대한 해결책은 react-kakao-maps-sdk의 공식문서에 상세히 설명되어있었습니다.

https://apis.map.kakao.com/web/sample/mapRelayout/

지도 객체는 생성될 때 지도 div 크기에 따라 픽셀과 좌표정보를 설정하여 가지고 있습니다. 이 정보로 지도 객체는 지도표시, 마커 표시, 확대, 축소, 이동 등의 좌표 계산 등 지도 표시에 필요한 여러가지 연산을 수행하는데 이때 지도 div의 크기가 변경이 되면 지도객체가 가지고 있는 픽셀과 좌표정보가 div를 표시하는 크기와 달라지기 때문에 지도가 정상적으로 표출되지 않을 수도 있습니다

z-index꼬임 문제
또한 앞의 패널 전역 상태관리에서 설명했듯이 입력 중, 결과창과 결과 없음창이 전환되는 과정에서 map에 띄워져 있는 마커와 z-index의 꼬임 현상이 나타났습니다.

이를 해결하기 위해 z-index의 값들을 동적으로 수정하는 등의 작업을 진행했지만, 해결되지 않아 패널의 상태에 따라 마커를 온오프할 수 있도록 동작할 수 있게 구현하였습니다.

(사진에 있는 5시는 출시 당일날 오전 5시입니다…)

브라우저에서 위치 권한을 허락하지 않는다면 실시간 위치를 클릭해도 아무 동작하지 않는 문제

제 아이폰의 크롬은 위치 권한이 꺼져있어 실시간 위치를 클릭해도 위치를 보여주지 않는 문제가 있었습니다.
해당 경우는 크롬브라우저의 위치권한을 허락하지 않은 문제였고 이러한 경우 사용자에게 노티를 줘서 알려주면 좋겠다라는 생각이 들어 에러처리를 하였습니다.
(https://developer.mozilla.org/en-US/docs/Web/API/GeolocationPositionError 이곳에서 각 error.code에 대한 정보를 확인할 수 있습니다.)

추후에 토스트 메세지로 alert를 대신할 예정입니다!