프로젝트 서울 행을 제출했다. 지인과 함께 2인 프로젝트로 진행했으나, 다른 팀원이 디자인과 기획을 도맡고 개발 자체는 혼자서 진행했다.

나에게는 리액트로 하는 첫 실습이었지만, 교육자 없이 진행하는 첫 프로젝트이기도 했다. 혼자서 웹 사이트를 배포까지 하는 데는 어려움이 많았다. 거쳐온 오류 해결 과정이나 개선해야할 아쉬운 점을 정리할 필요가 있다.

프로젝트 소개

'서울 행'은 2023 서울 열린데이터광장 공공데이터 활용 모바일 앱/웹 경진대회에 제출한 웹 프로젝트다.
서울 공공데이터 중 '서울시 문화행사 정보', '서울시 문화공간 정보', '서울시 유적지 현황'을 사용했다.
GitHub 링크

지도를 통해서 서울시의 문화 공간과 유적지를 확인하고, 해당 공간에서의 문화행사를 확인하거나 키워드로 찾아볼 수 있다. 또한 별도 페이지에서 원하는 특징의 행사를 모아볼 수 있도록 한다.

백엔드 없이 프론트엔드만 구현하여 배포했다. 백엔드를 연동한다면, 개인이 원하는 행사를 따로 저장할 수도 있을 것으로 보인다.

진행 과정

함께 주제를 선정하고 기획까지 하는 것에는 얼마 걸리지 않았다. 기획에 큰 갈등은 없었다. 문제는 이후 디자인이나 기능을 뒤늦게 정하면서 시간이 지체되고 두 명 모두 일정이 매우 바빠지기 시작했다는 것이다.

목표는 완성이 1위, 필요없는 코드를 줄이는 것이 2위였다.

제출 기간 마지막까지 서류를 작업할 수 밖에 없었다.

개발 툴

IDE로는 WebStorm을 사용했으며, 프론트엔드만을 구현하기 때문에 React를 사용했다. 추가 라이브러리로 Styled Components, react-router-dom, axios, https-proxy-middleware를 사용했고 배포에는 Netlify를 사용했다.

지도 api로는 kakao map api를 사용했다.

피드백

기획

기획에서 제일 중요한 것은 문서작업이다.
기획에 필요한 것은 주제와 페이지의 구성, 기능 구성이었다.
주제와 페이지의 구성까지만 선정하고 기능은 세세하게 설정하지 못한 것이 마이너스였던 것 같다.

예를 들어, 예약 페이지에서는 '필터를 이용하여 특징 별로 행사 리스트를 볼 수 있다!' 라는 것만 정해둔 채로, 추가로 어떤 기능이 필요할지, 행사는 어떻게 보여줄 것인지가 의논이 되지 못했다. 직접 만들면서 어떤 부분이 의논되었어야 했는지 깨달았던 것 같다.

이러한 기능을 표로 정리하는게 훨씬 수월했을 것이다. 후반쯤에야 IA를 작성하기 시작했고, 그에 따라 기능을 추가했다.

처음부터 요구사항을 분석하고 IA를 작성하여 필요한 기능과 입출력 데이터를 확인하는 것이 중요하다.

데이터 분석

서울 열린데이터 광장에서 공공데이터를 사용해서 만드는 것이 주된 과제였다. 그래서 기획과 동시에 사용할 데이터를 선정하는 시간을 가졌다.

웃기게도 기획에서부터 부족한 섬세함이 여기서도 문제가 되었다.

첫째, 데이터에서 칼럼명으로 확인한 데이터가 알고보니 우리가 알고 있는 데이터가 아니었다. '신청일' 이라는 이름의 컬럼을 보고 우리는 컬럼 데이터 확인 없이 '행사의 신청일' 즉 행사를 신청하는 날인 줄 안 것이다. 그러나 안의 데이터를 봤을 때, '신청일'이라는 것은 행사를 데이터에 올리도록 하는 신청일인 것으로 추측되었다.

둘째, 유적지 현황 데이터에는 정확한 주소나 좌표 데이터가 없었다. 정말로 유적지가 무엇이 있는지만 알 수 있었다. 다행히도 유적지는 행사만큼 api를 받아서 매번 수정될 정도로 자주 바뀌는 것이 아니었으므로, 별도로 json 데이터를 받고 거기에 좌표를 조사하여 추가 후 적용했다.

전체적인 기획에는 아주 당연하게도 그 column에 대한 정보를 자세히 분석해야한다. 우리는 서울 공공데이터라는 것을 너무 신뢰한 나머지 데이터가 우리가 원하는 데이터가 아니거나, 사용할 수 없는 데이터가 있을 수 있음을 생각하지 못했다.

어떤 데이터를 사용하던 간에 그 데이터가 사용 가능한지 확인해야할 것이다.

확장성

지인에게 수업을 받으면서 몇 번이고 중요하다 조언받은 요소다. 코드를 작성할 때 꼭 필요하다는 것이다. 그 중요성을 모르는 것은 아니었다.

그러나 직접 프로젝트를 만들면서 제대로 느끼게 되었다. 기획을 맡은 팀원에게는 추가 요구 사항과 수정 사항이 끊임없이 나올 수 있다. 여기서 요구 사항이 하나 또 생겼다고 코드를 갈아엎는 일은 없는 것이 좋다. 수정 사항이 있다고 모든 파일을 돌며 똑같은 단어를 수정하는 것도 없는 것이 좋을 것이다. 모두 경험으로 깨닫게 되었다.

예를 들어 ThemeProvider를 배웠음에도 처음에는 그 필요성을 느끼지 못했는데, 지인이 그렇게도 강조하던 코드의 필요 특성을 만족하기 위해 필요했던 것이다. 기획 과정에서 디자인을 정할 때 주 색상과 보조 색상을 대충 설정했었다. 언제든 바꿀 수 있는데도 그걸 굳이 pink, white 등 색상 이름으로 직접 정했던 것이다. 주 색상과 보조 색상을 정했을 때는 하나하나 파일에 접근하여 수정해야했다.

개발과정에서는 요구 사항을 쉽게 적용할 수 있도록 수정이 용이한 코드를 짜야한다.

섬세한 기획

'섬세한 기획'이란 무엇인가. 이걸 뜻하는 단어를 까먹은 나머지 이렇게 부른다. 기획에는 항상 구멍이 있기 마련이다. 실무에서 QA팀이 하는 일이 이러한 구멍을 찾는 일일 것이다. 팀원에게 전문적인 QA를 부탁하긴 어려웠고, 정상적인 사용 하에 오류를 찾도록 부탁했다.

물론 요구 하에 삭제 처리한 것도 있지만, 대부분의 리스트 페이지에서는 해당 아이템이 존재하지 않을 때 행사가 없다는 문구를 넣도록 했다. 행사를 api로 불러오는 과정에서는 '불러오는 중'이라는 메세지를 넣었다. 로딩 중이라는 것을 사용자에게 보여줄 필요가 있었고, api로 불러오지 못했는데 리스트로 보여주려하면 에러가 발생하기 때문이었다.

또 다른 예시로 kakao map을 사용하는 과정에서 매번 문제가 발생했다. 이는 코드의 작성 문제로, kakao map 역시 데이터 api처럼 가져오는데 불러오는 중에 kakao map에 어떤 기능을 추가하려고 했기 때문이다. 이러한 순서 처리를 할 필요가 있었다.

기능의 순서와 예외를 QA 전에도 항상 생각해야한다.

다음 목표

팀원에게 허락을 구해 공모전 결과 발표 후 '서울 행 2'를 만들어볼 예정이다.
팀원의 도움으로 나의 능력보다 훨씬 잘 만들어진 프로젝트였지만, 아직 기능 면에서 아쉬운 점이 한 두가지가 아니었고, 이미 만들어진 프로젝트에서 수정을 하는 연습 또한 필요하다고 생각한다.
백엔드 공부와 UI 공부 이후 아래와 같이 수정할 예정이다.

• 실수로 추가한 행사 예정일 필터 삭제
• 전체적인 UI 수정
• 백엔드 추가 - 사용자가 원하는 행사를 저장할 수 있도록 한다.