Milvis 개발 회고

2022년부터 개발을 해왔던 Milvis 가 드디어 끝났다. 마음 먹고 개발을 했다면 3달 정도만에 끝낼 수 있었을 텐데 백엔드 개발자분과 나의 개인 일정으로 중간중간 텀이 생겨 예정보다 늦게 마무리를 했다.

올해 3월, 학생회를 통해 학생들에게 배포했다. 백엔드 개발자 분께서 에브리타임에도 홍보 글을 올려주셔서 그쪽으로 피드백을 받고 있다.

당장 반영할 수 있는 피드백은 반영하고, 기능에 대한 부분은 회의를 진행하며 차근차근 유지보수를 해나갈 예정이다.

유지보수와 관련한 내용도 회고글 뒤에서 다룰 예정이니 우선 Milvis 에 대해 소개를 해야겠다.

제작 배경

현재 내가 다니고 있는 학교는 부산대학교 밀양캠퍼스다. 그리고 내가 겪었던 불편함은 다음과 같다.

1. 번거로운 환승

밀양캠퍼스는 자체 기숙사도 있지만 부산을 왕복하는 통학버스도 지원하고 있고, 그냥 기차로 통학하는 학생도 꽤 된다.

거기다 주말이 되면 기차를 타고 본가에 가야해서 기차와 버스를 환승하는 학생이 많다.

하지만 환승을 하기 위해선 코레일 어플과 우리학교의 버스 시간표를 일일이 대조해야하는 번거로움이 있었다. 그리고 버스와 기차 시간 사이의 환승 시간이 적절한지 등을 학생이 일일이 계산해야했다.

2.불편한 버스 시간표 디자인

기존 버스 시간표는 시간을 확인하기 불편한 디자인이었다.

대충 보여주면 이렇다...

이렇게 눈이 아플정도의 시간표를 사용자에게 더 잘 보여줄 수 있도록 개선해야겠다는 생각이 들었다.

기능 소개

1. 기차-버스 환승 시간표

기차와 버스 시간 환승시간을 확인할 수 있도록 도와주는 기능이다.

두 대중교통의 환승 시간을 편하게 볼 수 있도록 시간표를 한꺼번에 비교할 수 있으면 좋겠다고 생각했다.

코레일 열차 시간 API 와 우리 학교 버스 시간표 정보를 한번에 보여줄 수 있도록 했다.

2.버스시간표 디자인 개선

해당 기능은 API 보단 디자인에 초점을 맞췄다. 어떤 디자인이 사람들에게 보기 편할지 계속 고민하다가 순정(?)을 살리기로 했다.

정각 시간대 (6시, 7시...) 가 없어 보기 불편했기 때문에 정각 시간을 큼지막하게 넣어주었다.

위 사진엔 시간표 정보가 좀 뒤죽박죽인데, (16:00 이라고 표시된 것도 있고 16:00분 이라고 표시된 것도 있다) 지금은 고친 상태다!

기획 & 디자인 과정

1. 인원

처음엔 프론트엔드 2명, 백엔드 1명 이 팀을 이루고, 거기다 이미 취업한 학교 선배가 멘토링을 해주었다. 프론트엔드에도 취업한 선배 분이 계셨는데 프론트 개발자는 아니고, 이직을 고민하시던 도중 참여하게 되었다.

우리 팀 중 2분이 취업을 이미 한 상태였기 때문에 어느 시점부턴 프론트 1명, 백엔드 1명으로 프로젝트를 진행하게 되었다.

2. 디자인

디자인은 내가 담당했다. 처음으로 Figma 를 사용해서 많이 어수선하다. 디자인은 네이버나 프로그래머스 등의 사이트들을 참고했다.

개발 과정

1. 사용기술

React

2022년 초에 막 클론 코딩으로React 문법공부를 끝냈고, 무언가 웹을 만들어보고 싶단 생각이 들었다.

그래서 주변의 불편한 점이 무엇이 있을까 고민하다가 멘토링을 해주는 선배의 도움으로 Milvis 를 고안하게 되었다.

문제는... 문법 공부를 막 끝냈다고 했지, React 를 완벽하게 아는 건 아니었단 것이다. useState 와 useEffect 의 개념에 대해서만 알고 있었는데 useEffect 훅 마저도 반쪽자리 개념으로 습득했다. (마운트 될 때만 콜백함수를 실행해주는 걸로 알았음...)

그래서 프로그래머스 데브코스가 끝난 뒤 해당 프로젝트를 다시 열었을 땐 코드를 엎어버리고 싶은 마음을 간신히 참았다.

도대체 왜...왜 이런 코드를 작성한 거지...? 😭

과거의 나는 이런 코드를 보며 잘 짰다고 흡족해하고 있었을 생각을 하니 부끄러웠다...

아무튼 부트캠프가 끝난 뒤 고칠 부분은 고치고, 리팩토링이 필요하다 생각한 부분은 간단하게라도 리팩토링을 해서 프로젝트를 끝마쳤다.

끝?

그럼 React 만 사용한 건가요...?

그렇다...! 해당 프로젝트는 상태 관리 라이브러리도, CSS 라이브러리도 사용하지 않고 배포한 상태다.

내가 부트 캠프를 하면서 얻어온 지식이 있다고 해도 우리 팀엔 엄연히 나와 같이 하는 프론트엔드 팀원이 있었고, 내 멋대로 새로운 라이브러리를 도입할 수 없다고 판단했다.

하지만 프론트엔드 팀원의 사정으로 내가 프로젝트를 혼자 담당하게 되면서 프로젝트를 멋대로 바꿀 수 있는 권한(?) 을 얻었다.

그래서 다음 요소를 추가해보려고 한다.

• Typescript
  프로젝트가 자바스크립트로만 되어 있다보니 확실히 자동완성 면에서도 불편하고, 발견하지 못하는 타입 오류가 많다. 안정성을 위해 추가하면 좋을 거 같다!
  
• React-hook-form
  버스-기차 환승 시간 페이지에서 폼을 작성해야 하는데, 렌더링을 개선하기 위해 React-hook-form 라이브러리를 도입해봐도 좋을 거 같다.
• Emotion or Chakra
  class 이름을 기반으로 CSS 를 작성하고 있는데... 상당히 불편하고, 공통 컴포넌트도 줏대(?)가 없어서 UI 나 CSS 프레임워크를 도입할 필요를 느꼈다.
• react-query
  ㅠㅠ...꽃이 지고야 봄인 줄 알았습니다... . 프로젝트에서 사용할 때 당연히 여겼는데, fetch API 하나로 API 호출 및 error 상태를 관리하려고 하니 너무 더럽다. 하다 못해 fetch API 를 훅으로 분리하여 에러 상태를 관리 할 수 있도록 리팩토링을 해야할 거 같다.
• ESLint Prettier
  추후 동아리를 만들어 해당 프로젝트의 코드를 인수인계 해야하는데 이를 대비해 기본 세팅을 해놓을 생각이다.

코드 리팩토링과 더불어 새로운 라이브러리를 도입하는 게 대공사겠지만 정리된 코드를 보면 흡족할 것이라고 믿어 의심치 않는다.

지금은 React-hook-form 과 Redux 를 공부하기 위해 토이 프로젝트도 하나 하고 있는데... 얼른 끝내고 Milvis 를 뜯어고칠 생각이다.

2. 기능 개발 과정

기능을 개발하면서 어떤 부분을 신경 썼는지에 대해 이야기 해보고자 한다. 전체 기능을 두루 만지긴 했으나 주로 담당한 페이지는 아래와 같다.

1. 기차 - 버스 환승 시간표
2. 메인페이지

기차 - 버스 환승 시간표

1. 날짜 선택하기, 시간 선택하기
열차 탑승 날짜와 시간을 선택하기 위해 input 태그의 date 타입과 select 를 이용하여 구현했다.

어려울 것 없는 구현이었다.

2. 역 선택하기

• 역명을 클릭하면 역을 직접 입력하여 검색할 수 있는 input 컴포넌트가 뜬다.
• 사용자가 입력한 문자를 포함하는 역명을 list 로 보여줘야 하는데... select option 을 사용할 수도 있었지만 그건 멋이 안 나서(...) ul 과 li 태그를 사용하여 목록 추천 기능을 구현했다.
• 사용자의 입력을 받을 때 디바운싱을 적용했다.

Input 컴포넌트에 검색하고 선택하게 되는 역명이 출발역인지 도착역인지를 판별해야 했다.

내가 선택한 방법은departToggle arriveToggle 을 만들어, 어느 한쪽을 클릭하면 다른 한쪽의 값은 false 가 되도록 만들었다.

그래서 Input 컴포넌트에 입력되는 역명은 true 의 값을 가지고 있는 역에 할당되게 했다.

if (departToggle === true) {
	setDepartStation(station);
} else if (arriveToggle === true) {
	setArriveState(station);
}

해당 하위 컴포넌트에만 할당되는 state 가 무척 많다. 2022 년에 이걸 만들 당시에는 관련 로직이 너무 많아 class 로 만들어 분리했는데 관련있는 메서드를 모으려고 한 시도 자체는 괜찮았지만 다른 비즈니스 로직은 하나의 파일 안에 있는데 해당 로직만 class 로 분리되어 있으니 일관성이 없어보였다.

또, 출발역과 도착역 중 하나는 반드시 밀양역으로 설정이 되어야 하는데 useEffect 의 사용법을 잘 몰라서 일일이 메서드를 호출해서 바꾼 로직도 충격이었다.

관련 state 와 메서드가 많아서 전체적인 리팩토링을 할 때 제일 고생한 부분이었다.

3. 환승 시간표 구현

마음에 드는 디자인을 뽑았지만 코드로 구현하기 위해서 어떻게 할지 고민을 조금 했다.

당시 React 를 배운지 얼마 안 되었을 시기라, 가운데 있는 선은 어떡할지. 원모양의 시간은 어떻게 표시할지, 왼쪽 오른쪽에 표시되는 시간표를 어떻게 배치할지 등을 고민했다.

cssflex 속성을 배우지 않은 상태로 만드려고 했다면 꽤 힘들었을 거 같다.

더불어 해당 시간 간격은 일정하게 떨어져 있는 게 아니라, 환승 시간을 시각적으로 보여주고 싶었다.

환승 시간이 길 때

환승 시간이 짧을 때

이를 위해 시간표를 처음부터 끝가지 탐색하며 자신의 바로 뒷 시간과 대조해 margin 값을 다르게 넣어주어 해결했다.

메인페이지

처음엔 메인페이지에서 기능을 설명하는 Card 들을 슬라이드 형태로 보여주려고 했다.

그래서 pagination 도 만들어보고... state 로 보여지는 페이지를 관리도 해보고 했는데, 조금 시간이 지나고 든 생각은 사용자가 과연 이 슬라이드를 편리하다고 생각할까? 였다.

아무리 헤더가 있다지만 특정 페이지로 이동하기 위해선 3초마다 바뀌는 카드들을 기다리거나 pagination 을 직접 클릭해서 이동하는 메인화면은 사용자의 경험을 해치기만 할 뿐이란 생각이 들었다.

그래서... 2년전의 내가 열심히 구현했음에도 불구하고 가차없이 삭제한 뒤 지금과 같은 메인 페이지를 만들었다.

3. API 트러블 슈팅

CORS 에러

백엔드와 처음 협업을 하면서 만나게 되는 1순위 에러... CORS 에러였다. API 를 만들어줬는데 쓰질 못하게 하는 원인.

콘솔에 CROSS ORIGIN ERROR 라고 적힌 녀석을 구글에 검색하자마자 방대한 양의 결과가 뜨는 걸 보고 안심했다. 누구나 겪는 에러구나... 싶어서.

결론적으로 도메인이 같지 않은 경우 백엔드 서버에서 프론트엔드에서 사용하는 도메인을 허용해줘야지만 에러가 나지 않는다고 해서, 이를 허용해줌으로써 간단하게 해결했다.

https 에러

문제는 localhost 로 확인했을 땐 API 호출이 잘 되었는데 vercel 로 배포한 웹에선 API 호출이 안되는 문제가 있었다.

문제를 확인해 보니 https 페이지에선 http 를 호출할 수 없다는 경고가 떴다.

구글에 검색도 해보고... 데브코스로 알게된 프로젝트 경험이 많은 지인분께 슬쩍 해결방법을 여쭤보기도 했다.

너무 친절하게 알려주셔서 감동...☺️

임시 해결방법으로 http 요청을 https 로 바꾸는 태그를 삽입하는 방법도 있었으나 이 경우 아예 없는 서버로 요청이 가서 패스했다.

백엔드와 상의해서 결국 웹 서버를 https 로 바꾸는 걸로 해결했다.

배운점 & 회고

팀 프로젝트

따지고 보면 처음 경험한 팀 프로젝트였다. 문서화부터 컨벤션, 각종 협업 규칙같은 걸 만드는 경험을 Milvis 를 개발하며 처음으로 접했다.

기획부터 개발까지 공통적인 규칙을 만들고, 회의 일정을 잡고, PR 을 올리면 올렸다고 얘기를 하고... 이런 과정을 처음 겪었다.

더불어 github 도 이때 거의 처음으로 제대로 써보았다. init, add, commit, push, pull 등등... 헷갈렸던 개념을 Milvis 를 하면서 감을 잡아갔고 덕분에 데브코스에 들어가서도 빨리 적응할 수 있었다고 생각한다.

아쉬운 점

2022 년에 막 시작한 react 공부, 그리고 처음 팀 프로젝트라 그런지 아쉬운 점이 많이 보인다. 눈이 너무 높아졌다는 생각이 든다.

그 당시에 괜찮게 짠 코드가 이상하게 보이는 건 물론이고, 협업 방식에 대해서도 아쉬운 점이 많다. 하지만 이런 문제들은 처음 개발하며 겪게 되는 문제라 넘어갈 수 있겠으나...

길찾기 기능 이 원래는 기획 때 있었는데, 밀양시에서 제공해주는 API 가 부정확하고 데이터를 수집하는 데 어려움이 있어 중간에 해당 기능을 빼게 된 것이 아쉽다. 생각해보면 네이버와 카카오도 , 심지어 밀양 실시간 버스 시스템도 잘 모르는 데이터를 학생 수준에서 모으려고 했던 건 쉽지 않은 일이었다.

기획 단계에서 해당 기능이 구현 가능한지를 좀 더 검토해보았어야 하는 일이라고 생각한다. 그렇다면 중간에 데이터를 찾거나, 필요없는 기능을 만드는 데 시간을 할애하지 않고 더 빨리 배포를 할 수 있었을 거란 생각이 든다.

앞으로의 계획

우선 위에서 말했던 것처럼 피드백을 꾸준히 받아 기능을 추가+유지보수 해나갈 예정이다.

그리고 백엔드 개발자 분께선 가능하면 우리 코드를 계속 유지보수 해줄 수 있는 사람을 후배 중에서 골라서 가르치고 참여하도록 할 수 있으면 좋을 거 같다고 해서, 인수인계를 할 사람을 구해야 한다.

하지만 여기서 문제는... 내 코드를 남에게 보여주기에 너무 더러운 상태란 것이다. 그래서 가능하면 위에서 언급한 라이브러리들을 사용해서 코드를 최대한 깔끔하게 만들고 리팩토링 작업을 한 뒤 사람을 구하고 싶다.

취업준비를 하면서 리팩토링을 하기 쉽지 않겠지만... 그래도 내가 만든 결과물을 끝까지 책임지는 박찬욱 감독의 마인드를 가지려고 한다. 이상 끝!