광역 버스 과거 좌석 기록 서비스 개발 후기
해커톤 기간동안 개발한 광역 버스 과거 좌석 기록 서비스 개발 회고
Kernel 360 해커톤
현재 커널 360 에서 공부를 하고 있다. 과정 초반에 해커톤을 통해서 원하는 서비스를 기획하고 5일 내에 만드는 프로그램이 있다.
나는 이 곳에 통학하면, 평소에 버스를 이용하면서 그리고 새로운 장소로 면접을 갈 때 불편함을 느꼈던 요소를 해결하는 서비스를 기획했다. 운이 좋게도 서비스를 기획하고 팀을 꾸릴 수 있게 되었고 이 아이디어로 해커톤을 진행할 수 있었다.
기획
내가 겪었던 문제는 다음과 같았다.
"1009 번 버스를 타려고 하는데, 8시 30분에 의왕 톨게이트에서 난 이 버스를 탈 수 있는가?"
나는 이것을 판단하기 위해서 다음과 같은 프로세스를 겨쳤다.
- 내가 그 곳에 가야할 근방에 네이버 지도를 켠다
- 네이버 지도에서 해당 버스의 실시간 정보를 보면서 어떤 정류소에서 좌석이 얼마나 들어오는지 확인한다.
- 만약, 그 버스가 그 시간에 내가 원하는 정류소에서 없다면, 다른 시각대에 다른 정류소 혹은 다른 시간대에 다른 버스 다른 정류소를 찾아본다.
이유는 다음과 같았다.
- 적어도 이전의 기록을 보면 내가 그 장소에서 탈 수 있는지에 대해서 알 수 있고, 대안에 대해서 모색할 수 있다.
- 그 대안은 다른 버스, 다른 교통 수단이 될 수 있다. 그리고 오히려 앞의 정류장으로 먼저 가서 타는 것이 방법이 될 수도 있다.
- 네이버 지도는 늘 "최적화된 경로"만 제공한다. 그러나, 이것은 "내가 탈 수 있는지?"에 대한 정보는 전혀 제공하지 않는다.
"서비스"를 통하지 않고 문제를 해결하는 방법은 다음과 같다.
- 해당 경로로 출근하는 지인에게 "이 버스 탈 수 있나요?" 라고 물어본다.
- 위 처럼 그 시간에 기존 서비스로 일일히 찾아본다.
- 그냥 생각안하고 가서 기다려본다.
모든 방법이 지금 우리가 "새로운 경로" 혹은 "안가본 시간대"에서 광역버스를 타기 위해 대응하는 방법이다. 지인을 통하는 방법이 그나마 가장 효율적이지만, 정확한 정보라고는 할 수 없다. 그리고 나머지 방법은 내가 실패할 수도 있으며, 시간이 상당히 소요되는 일이라고 할 수 있다.
그 결과 나는 다음과 같은 결론에 이르렀다.
"과거에, 의왕 톨게이트에서 08시 23 분에 1009번 버스를 기다릴 때, 몇 명이 탈 수 있을까? 라는 정보를 알 수 있다면 이 판단을 조금 더 쉽게 할 수 있지 않을까?"
그리고 이런 서비스가 있는지 찾아보았지만, 아직 서비스 중인 것이 존재하지 않았다. 그래서 우선은 가장 간단한 해법을 고민했고 구현해야할 기능은 다음과 같았다.
- 사용자가 궁금해하는 버스에 대해서 좌석 정보를 저장하기
- 시간대, 정류소에 대한 정보가 함께 고려되어야한다.
- 사용자가 원하는 형태로 해당 자료를 가공해서 보여주기
- 가장 간단한 형태는 과거의 기록을 모두 보여주는 것이다.
- 그 다음은 시간대 필터링을 하여 보여주는 것이다.
- 그 다음은 요일, 공휴일과 같은 특성을 고려하여 보여주는 것이다.
- 마지막으로, 실시간 정보 / 내부의 알고리즘을 통해 "추천"을 해주는 것이다.
가장 간단한 해법으로는 그냥 과거의 정보를 적당히 걸러서 보여주는 것이다. 해커톤의 기간 동안에 데이터를 다 수집하기에는 어렵기에 결과를 발표하는 날에 정확한 정보를 보여줄 수는 없겠지만, 정보가 점점 쌓일 수록 사용자에게는 유의미한 데이터를 보여줄 수 있기에 충분히 가치있는 프로젝트라고 생각했다.
따라서, 우리 팀은 "일단은 어제의 정보를 보여주자"라는 목표로 프로젝트를 시작하게 되었다.
협업을 위한 기틀 다지기
Kernel 360 의 지침상 해커톤 5일 중 2.5일 / 2.5일 팀장을 제외한 팀원을 교체하여 진행한다. 첫 팀에서 상당히 노력을 쏟았던 내용 중 하나가 "협업을 위한 기틀 다지기" 였다.
Git / Github
개발자에게 있어 협업의 기본 중 하나는 Git의 활용 그리고 이슈 / 의견 관리이다. 전략은 다음과 같이 세웠다.
팀에서 어떻게 브랜치를 관리할 것인가? 부터 시작했다.
배포 주기에 대해서 생각할 때는 아니었으며, 가장 친숙하게 다가갈 수 있는 git-flow 브랜치 전략을 사용하기로 하였다. 또한 (여기 부캠 원칙) 원본 Repo를 fork -> 해당 fork repo 에서 branch 생성 -> PR 의 방식을 취한다.
또한, 브랜치명의 경우 feature/#13 과 같이 반드시 Issue 를 등록하고 카테고리/#이슈번호 로 브랜치 관리를 하도록 협의를 하였다. 기능 개발 이후에는 PR을 통해 변경 내용을 팀원에게 전파하고, 반드시 리뷰를 받는 방향으로 협업 전략을 정했다.
- 그러나 리뷰는... 거의 못했다.. 굉장히 아쉬운 부분이다.
- 만약 리뷰가 정상적으로 이루어졌다면 금방 해결될 수 있는 문제가 정말 많았다.
- 프로젝트 내내 계속 걸렸던 부분이고, 해커톤이라지만 상당히 스트레스를 받았던 부분이기도 하다.
Issue 의 경우 템플릿이 없을 경우 중구난방으로 적는 경우가 많아 Template 을 설정해두었으며, "어떻게 작성해야하는가?"를 같이 이야기하는 시간을 가졌다.
git 에 아직 익숙하시지 않은 분들이 많아 학습에 상당히 많은 시간이 소요됐다. 그러나, 한번 익히고 여러 번 사용을 하고 난 후 상당히 발전이 있었다. git / github 관련해서 쓸데없이 시간을 소모한 것 아닌가라는 고민을 하고 있었는데, 해당 팀원들이 다른 팀으로 가면서 학습한 것을 금방 적용하고 문제를 해결하는 모습을 볼 수 있었다.
IntelliJ / 코드
전반적으로 코드의 포맷은 맞추고 들어가야한다고 생각했다. 안하면 포매터 맞춘 사람과 안맞춘 사람 간에 conflict 문제, 코드가 엄청 난잡해지는 문제등을 경험하게된다. 그래서 Formatter 를 지정하고 CheckStyle 까지 지정하도록 했다. 아무래도 직접 만들어서 쓰는 것보다는 기존의 형식을 지정하는 것이 낫다고 생각해서, NAVER_HACKDAY 의 방식을 그대로 차용해왔다. 덕분에 효과적으로 코드를 (퀄리티와 별개로)정갈하게 유지할 수 있었다.
해당 부분에서 명명 규칙, 코딩 컨벤션까지 제대로 하고 갔으면 좋았을 것 같은데 그럴 여유가 없었다. 완벽하게 좋은 코드는 존재할 수 없지만, 협업을 위해서 지켜야할 것을 지키지 않을 때는 늘 문제가 생기기 마련이다. 긴 기간의 프로젝트라면 꼭 하고 갔어야하는 부분이었다. (안하니까 코드가 그냥 중구난방이다.)
DB 설계
DB의 경우 정말 많이 갈아엎었다. 가장 큰 이유는 "내 데이터"가 아니라는 것이었다.
CSV import
공공 데이터 포털에서는 CSV 포맷으로 정류소에 대한 정보와 버스 노선에 대한 정보를 CSV 로 제공한다. 그래서 초반부에는 DB 에 이 데이터를 적재하고 API 활용을 최소화하여 사용자에게 최대한 빠르게 정보를 전달하려고 했다. 그 기준에서 탄생한 ERD 는 아래와 같았다.
우리 팀에서는 최대한 정보를 정제하고, 필요한 정보를 담으려고 했었다. 그리고 이 정보를 기반으로 사용자에게 데이터를 DB 에서 뽑아 제공함으로써 지연을 낮추고자했다. 그러나, 이는 완전한 오판이었다.
- 사용자가 받고자 하는 정보에 대해서 제대로 파악하지 못했다.
- 최대한 효율적으로 사용자가 원하는 정보를 가져오는 API를 제대로 파악하지 못했다.
- 해당 데이터에는 존재하지 않는 정보, 필요하지 않은 정보, 과거에만 존재하는 정보 등이 포함된다.
이러한 이유로 인해서, DB를 3번정도 갈아엎었다. 결과적으로 만들게 된 DB 는 아래와 같다.
결국 우리가 지향하는 목표는 "데이터를 수집해서 사용자에게 도움이 되는 정보를 최대한으로 보여준다." 라는 것이었다. 따라서, 수집하고자하는 내용을 최대한 가공하지 않고 저장해야했으며, 필요한 정보를 선별해야했다. 이 작업은 두 번째 팀에서 기획에 대한 내용을 재점검하며 다시 도출할 수 있었다.
그 결과 도출된 내용으로는 다음과 같았다.
- 버스 노선 - 이름 / ID 의 경우 기존 테이블에 저장한 내용으로는 표현할 수 없다.
- 노선 정보 조회 API 에서 들고와서 보여주는게 좋다.
- API Call 제한을 생각하면 caching을 하는 것이 좋다. 그러나, 아직은 고려할 단계는 아니다.
- 모든 정류장에 대해서 정보를 저장할 필요가 없다.
- 우리가 관심있어하는 정류장은 "광역 버스 정류장"이다. 그러나 지금 정류장은 모든 정류장을 대상으로 한다.
- 또한, 저장된 정류장 정보는 과거의 데이터고, 24년 현재에 맞지 않는다.
- 사용자가 궁금한건 "어느 버스를 탈때", "그 버스의 정류장"만 궁금하다.
- 따라서, "노선에 대한 경유 정류소 조회 API"를 통해 해당 노선이 지나는 정류소만 저장하는 것이 적합하다.
- 초반에는 API 를 생각하다가 "정류소" 관점으로 접근했다. 그러나 잘못된 접근이다.
- "정류소"에서는 "도착정보조회 API" 를 통해서 버스에 대한 좌석 수 / 위치를 획득할 수 있다.
- 그러나 해당 정보를 정제하는 것도 일이며, 사용자가 궁금한 것은 "내가 궁금해하는 버스가 어떤 정류소에 도착할 때의 좌석 수"이다.
- 위 API 는 그런 정보를 획득하기 위해서는 별도의 정제 작업이 필요하다. 또한 API 호출 횟수가 증가할 수 있다.
- "노선 위치 정보 조회 API" 의 경우에는 해당 노선에서 운행하는 버스의 위치 정보 / 좌석 정보를 제공한다.
- 해당 API 가 제공하는 정보가 우리가 원하는 정보이다. 따라서, 도착 정보가 아닌 위치 정보를 활용하도록 한다.
마지막 DB 까지 오는데 3일이 걸렸다. 절반의 시간을 소모했지만, 제대로된 DB를 구축한 뒤에는 속도가 붙었다. 더 이상 수정할 것이 없었기 때문이다. 여기서 우리는 "설계의 중요성" 그리고 "고객의 니즈"에 대한 관점으로 접근하는 법에 대해서 배울 수 있었다.
기능
기능은 굉장히 단순하다.
- 사용자에게 관찰하고자하는 노선을 요청받는다.
- 해당 노선들에 대해서 버스 위치 정보 API 를 주기적으로 호출하고 저장한다.
- 사용자는 "노선", "정류소", "시간대" 라는 필터로 궁금한 정보를 조회한다.
백엔드에서는 3가지 기능을 모두 구현했으며, 프론트엔드에서는 시간 부족 문제로 "사용자 요청"에 관한 부분에 대해서는 해결하지 못했다.
문제 해결
공공데이터 OpenAPI 요청 서비스 코드 중복
- 공공 데이터 API 에 대한 요청 서비스 코드의 경우 다음과 같은 코드로 이루어짐
- 서비스 키 획득
- URI 설정
- Query Parameter 설정
- Request / Response 처리
- 또한, API 의 변동 가능성 / 서비스 키 변동 가능성 / Request / Respone 에 따라 다른 Object 변환 등이 고려됨.
- 따라서 중복되는 코드를 줄이고 추상화와 외부에서 값을 최대한 주입받아 사용할 수 있도록 변경의 필요가 있었음.
해결방안
- API Request 를 하는 Service code 추상화
- 기존 : 각 서비스별 하드코딩
- 유연성이 부족하며, 코드를 읽는데 어려움이 있었음.
- 코드 작성에 시간 소요.
- 변경 : Key, URL 을 주입받고, Abstract class 를 상속하여 사용할 수 있도록 변경
- 기존 : 각 서비스별 하드코딩
- API Key 주입 방식 변경
- 기존 : 하드 코딩 (서비스 키가 코드 내에 있었으며, repository 에 노출되는 위험 존재)
- 변경 : Property 로 부터 값을 주입받도록 변경 / Rolling key를 지원하는 interface 를 implement 하도록 변경
- ApiServiceKeyPropertyInterface
- 구현 - PublicApiServiceKeyProperty
- API 요청 경로 Property 화
- 기존 : 하드코딩
- 변경 : application.yaml + property 를 통해서 해당 값을 주입받고, interface 로
AbstractOpenApiService에서 사용할 수 있도록 변경 - ApiPropertyInterface
- BusRouteLocationApiProperty
효과
- ApiService 작성 시간 감소
- 빌드 이후에도 Key, URI 변경 가능 / Repository 에 Key가 더 이상 노출되지 않음.
Timezone 문제
- Server - DB 의 TZ 불일치로 인해 잘못된 시간값이 주입.
해결 방안
- 완벽하게 해결된 상태 아님.
- 현재는 Server / DB 의 TZ 를
Asia/Seoul으로 지정하여 해결함.- Front 에 넘어갈 때는 가공되어 보여지기 때문에 문제가 발생하지 않음.
- 그러나, Grafana 연동 중 DB에서 가져온 데이터를
UTC로 해석하여 TZ 를Asia/Seoul으로 설정하면 재해석되어 보이는 문제를 발견함.- 데이터 저장시 Zone 을 명시할 필요.
FE
- FE 가 굉장히 단순한데 너무 많은 시간을 쏟았다.
- 어쩔 수 없는 부분이라고 생각했는데, 끝나고 보니 그게 아니었다.
해결 방안
변경: 우선은 Grafana 로 보여주자.
- 우리가 보여주고 싶은 것은 시계열 데이터를 효과적으로 유저에게 전달하는 것이다.
- 굳이 React, Thymeleaf 를 써야할 이유가 있는가? 더군다나 해커톤인데. 표현하고 싶은 자료만 표현하면 된다.
- 이것을 가장 잘 해결할 수 있는 도구로 Grafana 가 있었다. 해커톤이 끝나고야 깨달았다.
- Grafana 에서 variable 을 잘 설정하고 데이터를 쿼리하면 FE가 굳이 필요가 없다. 어쩌면 REST API도.
- 그래서 Grafana 로 데이터를 표현했다. 차라리 Query 로 모든걸 표현하니 더욱 더 고객이 필요로하는 데이터를 표현하는데 집중할 수 있었다. (물론 이걸 공개해서 사용하는데는 어려움이 있지만)
발표 & 피드백
커널 360의 가장 좋은 점 중에 하나는 발표를 많이 할 수 있는 기회가 있다는 것. 그리고 실무자들에게 피드백을 받을 수 있다는 것이다. 이번에는 내가 발표를 진행했고, 이 프로젝트에 대한 피드백을 들을 수 있었다.
발표자료
발표 후기
앞선 팀들에서 상당히 좋은 결과물을 보여줬다. 게시판, 롤 정보 사이트, 야구장 정보 사이트, 시니어를 위한 채팅 사이트 등이었다. 그래서 결과물이 너무나 단순했던 우리 팀이라 많은 긴장을 했다.
그런데, 생각보다 발표는 깔끔하게 했던 것 같다. 우리가 왜 이것을 만들려고 했는지, 무엇을 이용해서 만들었는지, 어떤 고민을 하고 만들고 있었는지에 대한 정보는 제대로 전달했다고 본다. 아무래도 학습하는 곳에서 하는 발표라서 마지막에 회고를 남겼는데 나는 너무 아쉬움이 많이 남았던 팀 프로젝트라 아쉬움을 토로했다.
그러지 않았어도 될 것 같지만 고생만 하고 갔던 나의 팀원들에 대해서 죄송함을 표현하고 싶었다. 그것이 어떻게 그들에게 받아들여졌을지는 잘 모르겠다. 개발을 시작한 뒤로 매번 팀장으로 무언가를 하지만 나는 여전히 미숙하다는 것을 많이 느낀다.
피드백 & 질문
종합적으로 피드백을 요약하면 다음과 같았다.
- 실제 문제를 해결하고자 하는 아이디어에서 출발한 서비스라는 점에서 높은 평가
- 발표 전 전날에 멘토님이 와서 기획에 대한 아이디어를 제공해주셨을 때도 "쓸만한 서비스다" 라는 평을 남겨주셨고, 발표 당일에도 "실제 문제를 해결하는 서비스"라는 점에서 좋은 평가를 주셨다.
- 목표로 지향하는 바와 일치하는 점에서 그나마 다행이다라고 생각했고, 추후에 이 서비스를 계속 개발하게 될 것이라 다행이라고도 느낀다.
- 협업에 대한 고민에 대한 질문들
- 팀장으로서 이번에 잘 운영을 하지 못해서 업무 분배와 관련한 내용으로 답변을 드렸는데, 아무래도 git / 협업 규칙 / formatting / 명명 규칙 등과 같은 부분을 말해주신 것으로 생각한다. 나름 이것들에 많은 신경을 썼었는데, 질문의 요지를 제대로 파악하지 못하여 제대로 답하지 못한 것이 아쉽다.
- 문제 해결에 대한 피드백
- API Request 에 대한 부분에서 많은 피드백을 들었다. 나름 Rolling으로 해결한 부분에 대해서도 좋은 이야기를 들었고, 오히려 다른 방식으로 접근하면 어떻냐는 좋은 피드백도 들을 수 있었다. 많이 고민하고, 이 문제를 해결하기 위해서 고민을 했던 부분이라서 큰 도움이 되었다.
- 공공 데이터와 DB
- 초반부에 버스 노선 / 버스 정류소에 대한 데이터가 이미 csv 파일로 제공이 되어있어서 이를 DB에 넣고 시작을 했었다. 그러나 이 정보에는 불필요한 정보, 과거의 정보, 현재 없는 정보가 있었고 결국에 마지막이 될 때 쯤 다 걷어내고 다른 방식으로 선회했다.
- 해당 과정을 설명드리는데 조금 어려움이 있었고, 사실 처음 접근이 잘못되어 이해가 어려우셨을 것 같다는 생각도 든다. 개인적으로는 "남의 정보를 어떻게 다뤄야하는가?" 라는 생각에 대해서 많이 고민할 기회가 되어서 꽤나 좋았었다.
- 발표에서의 나의 회고
- 이번 프로젝트에서 내가 가장 후회하고 아쉬웠던 것은, "나만 성장하는 프로젝트"라는 점이었다. 프로젝트의 특성상 순차적으로 진행되어야했고, 기능도 구현할 것이 많지는 않았지만 고민할 거리는 왕창 있는 프로젝트였다. 또한 1-3 일차와 3-5일차가 다른 팀원으로 구성이 되었는데 (커널 360 지침) 1-3 일차의 경우 서비스 이해에 대한 동기화가 제대로 이루어지지 못했다. 이런 이유로 지지부진하게 프로젝트가 이어졌고, 상당히 고난이 있었다.
- 결과적으로 팀원들과 같이하는 느낌이 아니라, 워터폴 느낌으로 내가 무언가를 지시하는 형국으로 치닫았다. 서로가 확신을 가지지 못하니 나에게 물어볼 수 밖에 없었고, 나는 고민을 하다보면 무언가 바뀔게 생각나니 계속 바꾸게 되었다.
- 이런 부분이 너무 아쉽고, 미안하고, 후회스러웠다. 기존 팀원 분들이 다른 팀에서 역량을 발휘하는 모습을 보고 그 점을 더 느꼈었다. 이런 회고를 마지막에 붙였는데, 조금 위안을 삼아주는 말씀을 해주셨었다. (아마 협업에 대한 내용을 원한다는 말이었던 것 같지만.) 하지만, 여전히 "좋은 팀장" 그리고 "좋은 팀"이 아니었던 것은 부정할 수 없었다고 생각한다.
- 너무 작은 기능
- 다른 팀의 경우 CRUD 를 모두 포함하는 어플리케이션을 개발했다. 그러나, 우리 팀의 경우 CRUD 를 모두 구현하라는 기본적인 내용을 충족하지 못했고, 그런 것들을 할 수 있는 기능을 추천하는게 어떻냐? 라는 의견을 제시 받았다.
- 공감하는 내용이다. 이러한 문제로 인해서 "같이 개발하기"가 제대로 이루어지지 않았고, 다양한 기능을 표현하지 못해서 형편없어보이는 결과물이 나왔다. 다른 핑계도 많지만, 관점을 어떻게 잡냐의 문제인 것 같다.
- 내가 지향하는 목표와 이 곳에서 지향하는 목표가 일치하지 않는 점이 가장 크다고 본다. 나는 이곳에서 하고 싶었던 것은 "실제로 사용자가 쓸 수 있는 서비스"를 만들자는 것이다. 게시판은 세상에 널렸다. 높은 확률로 그런 서비스는 오래 운영할 수도, 사용자가 쓰지도 않을 것이다. 그냥 무의미한 포트폴리오의 일부가 될 뿐이다.
- 나는 너무 이 프로젝트를 길게 내다봤다는 생각이 든다. "함께"라는 키워드를 놓친 것이 아쉽지만, 그래도 발표가 끝나고 집에 가면서 내 어플리케이션이 나의 퇴근길에 도움이 됐다는 점에서 무의미한 프로젝트는 아니었다고 생각한다.
회고
이 사이트에 대해
탈까? 는 나의 수요에 의해서 탄생했다. "나도 쓰지 않는 프로젝트"가 아니라는 점에서부터 상당히 의미가 있었다. 그리고 반 쯤 완성된 이 사이트를 들고 나는 발표가 끝난 퇴근길에 활용했다. 내 목표는 이룬 셈이다.
이 사이트는 다음과 같은 용도로 사용할 수 있다.
- 처음 가는 출퇴근 길에 어떤 버스를 언제 어디서 탈지 정할 때 결정 요소로 활용하기
- 매일 타던 버스라도 내가 가보지 않은 시간대에 정보를 얻고 결정 요소로 활용하기
- 다른 버스의 상황과 비교하며 적합한 버스를 선택하는데 결정 요소로 활용하기
나는 이미 2번의 용도로 해당 사이트를 활용했다. 활용을 해보니 무엇이 아쉽고, 무엇이 더 필요한 지에 대해서 알게되었다. 기존에 개발한 것들은 내가 만들고도 잘 쓰지 않는 것이 대다수였다. (멘토링 사이트는 멘토를 확보하지 못해서 사용을 못했다.) 그런 점에서 이미 고객은 한 명은 확보한 셈이고, 스스로가 발전시킬 수 있는 서비스라는 것이 상당히 매력적이다. 이는 배포, 운영으로 이어지고 배포, 운영에서의 고민으로 이어질 것이다. 나 스스로에게는 상당히 매력적인 프로젝트라고 느낀다.
협업 규칙 관련
해커톤에서 협업 규칙 / 적용 때문에 많은 시간을 소요했다. 때문에 이걸로 시간을 많이 잡아먹어서 "빨리 코드쳐야하는 것 아닌가?"라는 의견도 공통적으로 있었다. 하지만 나로서는 다소 포기할 수 없는 너무 기본적인 요소이기도 했다. 이런걸 자동화 안해두고, 규칙을 안정해두면 이 때문에 더 많은 시간을 뻇길 것이 너무나 자명했다.
결과적으로 내 팀에서는 효과를 제대로 보지 못했다. 왜냐면 거의 나만 코드를 두들기는 결과가 있었으니까. 하지만, 우리 팀에서 전파한 내용이 다른 팀에 가서 효과를 보았다는 점에서 앞으로의 프로젝트에 모두가 도움이 될 내용을 얻어갔다는 것은 큰 보람이다.
개인적인 성장
"협업"의 관점과 "서비스"의 관점에 대해서 배워간다.
- "협업"은 단순하지 않다. 팀원의 성향, 숙련도, 서비스에 대한 이해도 모두를 고려해야하며 "해당 프로젝트에서 얻어갈 것" 또한 고려해야한다. 나는 이런 것들을 이번에 제대로 알지 못하고 작업을 했다. 아마, 다음 프로젝트에서는 이것들을 고려하게 되지 않을까 싶다.
- "서비스에 대한 관점"도 정말 중요하다. 개발은 단순히 코드를 치는 것이 아니다. 고객이 어떤 정보를 원하고 어떻게 사용할 것인지, 그리고 고객이 어떤 것을 불편해할 지에 대해서 고민을 해야한다. 그리고 우리 서비스에서는 그 고객들의 니즈를 어떻게 반영시키고 효과적으로 처리할까를 고민해야한다. 개발자는 그 고민을 녹여 코드로 나타내야한다.
- 그것을 잘하기 위해서는 처음 기획, 설계에서 치밀한 과정이 필요하다. 치밀하지 않은 기획과 설계는 여타 다른 포폴, 앱들처럼 잊혀지고 시간 뒤로 사라지는 프로젝트가 될 뿐이다.
앞으로 개선 할 것들
서비스를 써보면서 느끼는 것을 몇 가지 정리해본다.
- 멘토님이 이런 이야기를 하셨었다. "가장 효과적인 방법으로는 네이버 지도와 결합해서 사용하는 것이 아닌가? 그러면 확장 프로그램으로 도움을 주는 것은 어떤가?" 라는 말씀이다.
- 결국에 사용자는 네이버 지도를 보고 어떤 결정을 이루게된다. 사용자 관점으로 바라본다면 "네이버 지도"를 통해서 바라볼 수 있게 하는 것이 가장 바람직한 선택 중 하나라고 생각한다.
- 그렇지만, 나는 하나의 통합된 어플리케이션을 만드는 것도 하나의 방법일 수도 있다고 생각한다. (이는 학습적인 이유도 크게 작용한다.) 이 사이트를 활용하면서 느낀 것 중 가장 큰 하나는, "실시간 정보"가 추론에 큰 작용을 한다는 것이다.
- 일례로, 나는 퇴근길에 이 시간에 사당역에서 7800 버스는 꽉 찬다는 사실을 사이트를 통해 알게 되었다.
- 그러나 정류소에 당장 도착하는 버스는 2층 버스였고, 70 석이 넘는 여유가 있었다.
- 정류소에 가서 봤을 때, 줄을 선다면 2층 버스는 탈 수 있었다.
- 정류소의 줄을 측정하는 것은 정말 어려운 문제다. 그러나 과거의 데이터, 현재의 상황을 결합하면 사용자는 합리적인 추측이 가능해진다.
- 그래서 나는 그 버스를 결국 탔고 빠르게 집에 갈 수 있었다.
- 결국 사용자는 실시간의 정보, 과거의 정보가 모두 궁금하다. 확률을 따지는 일이기 때문이다.
- 이러한 이유로, 실시간의 정보도 우리 사이트에서 제공하면 좋겠다는 생각이다.
- 부가적으로 광역버스는 "어떤 요일", "공휴일"도 중요한 요소이다. "오전 11시"는 보통 좌석이 널널한 시각이지만, 공휴일에는 다르다. 서울에 점심 약속으로 올라가는 사람이 많기 때문이다. 이러한 요소는 모든 일자에 대한 평균치로 반영한다면 희석된다. 서비스에서는 이러한 정보까지 반영해서 사용자가 판단할 수 있도록 해야한다.
- SK Open API 를 활용하면 경로 계산과 지하철 혼잡도까지 획득할 수 있다. 궁극적으로 이 서비스의 방향은 "쾌적하게 이동하는 방법에 대한 고민의 해결" 이다. 버스에서 확장하여 다른 대중 교통까지 확장할 필요가 있다.
- 현재는 경기도 광역 버스만 지원한다. 서울 버스까지도 고려할 필요가 있다.
- 위에 언급한 지하철도 마찬가지이고, 혼잡한 다른 대상도 기능에 포함시켜주면 좋을 것이다.
- 최종적으로는 데이터를 분석하고 처리하여 "탈만한가?"라는 것을 간단하게 판단할 수 있도록 나타내야한다.
아쉬운게 많이 남는 프로젝트였다. 그렇지만 더 발전 가능성이 있는 프로젝트이기도 하다. 나는 이 프로젝트를 계속 고도화시켜볼 생각이다. 누구와 이것을 어떻게 할 지는 아직 모르겠다. 어쩌면 혼자 할 수도 있고. 아무튼 배운 것은 많았다.
