[공모전] 2024 공개 SW 개발자대회 후기 [이번역] 회고_02

2024 제 18회 공개 SW 개발자 대회 공모전 회고_02

이번역(부제: 한발자국도걸을수없다)

---

01. 한발자국도걸을수없다

• 원래 프로젝트 이름은 한발자국도걸을수없다였다. 그러나 너무 길어 여러 이름을 후보에 두고 고른 뒤, 가장 짧고 직관적인 이번역이 제목이 되었다. 원래 제목은 슬로건으로 들어갔다.

• 프로젝트 이름에 관련된 회의를 가장 오랫동안 했는데, 이번역은, 타러가유, 역이어때 등 재밌는 이름이 많이 나왔다.

• 그 동안의 프로젝트는 웹 구조였다면, 이번 프로젝트는 웹/앱 구조로 진행했다.

01. 구형좌표 알고리즘

😀 [기능 1] 지하철 편의시설 조회

• 3주간 열심히 가공한 DB가 바로 이렇게 구현되었다.

• 구형좌표계 알고리즘을 활용해 코드로 짰다. 지구 반지름을 쿼리문에 넣어 사용자의 위치에서 가장 가까운 DB를 추출해 배열처리해 반환하는 구조이다.

• 에스컬레이터를 비롯한 다른 편의 시설의 경우, 하나의 Table에서 해당 data를 추출해 배열로 반환하는 구조였다면, 역 전체 정보 조회일 경우에는 모든 data를 반환하기 때문에 컴포지트 패턴(Composite Pattern)을 활용했다.

😀 [기능 2] 역 정차 시 조회

• 추가 기능을 고민할 때, 주위에서 가장 많은 답변을 받은 기능이다. 출/퇴근 시 어느 역인지만 빼고 다 알려준다고.. 그래서 한 번 만들어보자 했다.

• 사용자의 latitude와 longitude만 받고 난 다음 DB에서 가장 가까운 역 1개를 무조건 반환하는 구조였다.

• 이 기능을 구현한 뒤, 여러 핸드폰으로 test하는 과정에서 신기한 문제를 발견했다.
  IOS의 경우, 위치를 받아오는 텀이 약 10분 내외인 점이었다. 그 외 갤럭시와 LG 휴대폰을 비롯한 Android에서는 모두 정확하게 역을 받아왔다.

  😀 test 기록
  (LG 벨벳, 삼성 S9, S10, S20, S21, S22, S22울트라, S24, IPhone 14, 15 등)

  • 첫 번째 구현 당시, geolocation 방식으로 버튼을 누를 때 마다 위치를 반환하는 구조였는데, Android 휴대폰은 정확했으나 IOS 부분 미정확했다.
  • 차후 WatchPosition 방식으로 변경한 뒤, on-off 할 수 있게끔 구현하여 정확도를 개선했다.

• 해당 부분은 수정하여 정확도를 개선했지만, 멘토링을 통해 다른 방법이 있는지
  탐색할 예정이다.

02. WebSocket STOMP 채팅

😀 [기능 3] 실시간 다대다 채팅

• 지난 학원에서 Spring MVC 구조로 WebSocket 채팅을 구현한 경험이 있었는데,
  다시 구현해보길 정말 잘했다. 아예 구조가 달랐다. 이전 코드는 WebSocket.io 방식이었다면, 이번에는 WebSocket STOMP 방식을 사용했다.

• WebSocket STOMP 방식을 사용하게 된 이유는 호선별 채팅을 지역이라는
  하나의 채팅방에서 전체 조회하기 때문이었다. 예를들어 수도권 채팅방 내에서는
  수도권 1~9호선을 비롯해 서해선, 신림선 등 모든 호선을 조회할 수 있다.

• WebSocket STOMP 방식의 가장 큰 어려움은 바로 test에 있었다. postman으로 test할 수 없었고, 많은 사람들이 apic이라는 사이트에서 test를 했다는데 나는 실패했기 때문이었다. log가 따로 남지 않으니 수정을 어떻게 해야하는지에 대해서도 난감했다. 다른 방법으로는 인증서 문제에 부딪히기도 했다.

• 그렇게 며칠을 매달린 결과, gitHub에서 유용한 test 사이트를 찾을 수 있었다.
  https://cdiptangshu.github.io/stomp-client/ 이다.
  별도의 인증서가 필요 없어 test에 정말 적합하다 판단된다.

• 채팅 시 접속 브라우저별 오류가 발생했었다. 실시간 송, 수신, 삭제는 WebSocket 방식을 사용한다면 이전 채팅의 기록은 GET 방식을 사용하는데, WebSocket이 호출되지 않는 오류였다.

• 해당 오류는 Android, IOS 상관 없이 브라우저별로 나타나는 오류였다. 원인을 파악한 결과 ES6(ECMAScript 2015)를 지원하지 않는 브라우저에서 화살표 함수가 동작하지 않는 오류였다. 화살표 함수 제거 후 코드 작동을 확인했다.

03. Gson Parsing

😀 [기능 4] 길 찾기 입력 시, 도보와 자전거를 모두 제공한다.

• 길 찾기 시 가장 많이 사용한 API는 Sk TMap API였다. 해당 API는 SK에서 제공하는데,
  도보로 길을 안내할 뿐더러 옵션을 선택할 수 있었다. 한 발자국도 걸을 수 없기 때문에 최단거리+계단이 없는 옵션을 선택했다.

• 또한, 프로젝트의 정체성을 살리기 위해 현재 위치에서 가장 가까운 역으로 도보 안내를 하는 기능을 만들었다. 목적지가 역일 경우에는 가장 가까운 에스컬레이터나 엘리베이터로 안내하게끔 구현했다.

• 목적지를 조회한 뒤, 해당 위치를 OkHttpClient로 보내 경로 Data를 호출한다.
  이 때 Data는 String으로 호출이 되므로 Gson으로 파싱한다. 그리고 FE와 협의 후 불필요하다 판단되는 Data를 filtering해서 제거했다.

• 자전거의 경우, 서울과 대전 지역만 실시간 자전거 API가 존재했다.
  대전의 경우 한 번에 모든 Data를 보내주는 반면, 서울은 1000건씩 나눠서 호출해야 했는데 약 2700건의 data를 한 번에 호출한 뒤, 가장 가까운 위치로 정렬해서 0번째 data를 사용한다.

• 자전거 길 찾기의 경우, 도보로 역까지의 거리보다 보관소의 거리가 멀다면 제공하지 않도록 코드를 설계했다. 도보로 가는게 더 빠르다면 자전거는 불필요하기 때문이다. 실시간으로 대여가 가능한 보관소를 반환하므로 호출 할 때 마다 결과가 다르다.

• 그리고 서울시 자전거 API는 간헐적으로 timeout 500 error가 발생했다.
  하루에 많으면 1번, 30분에서 1시간 내지로 해당 error가 발생했고, 원인을 찾지 못했다.
  proxy와 application.yml 모두 설정을 수정했으며 OkHttpClient 시간도 10 > 15s로 변경했으나 미봉책에 불과했다.

• 너무 궁금해 공공데이터포털에 연락을 드려 조언을 구했다. 해당 API가 작년까지는 관련 error가 계속 발생해 수정을 했으니 더 이상 API의 문제가 아닌 것 같다는 답변을 받았다. 대전 API와 코드가 동일한데 서울 자전거에서만 오류가 발생했고, 아마 모든 data를 조회할 때 사용하는 for문에서 문제가 생긴게 아닐까? 하는 추론만이 남은 상태다. 그럼에도 이 오류를 반드시 고쳐내고 싶다.

😀 [기능 5] 역 간 경로 안내 기능, 길 찾기 시 함께 제공한다.

• 길 찾기 시, 역이 존재하면 역 간 안내도 함께 제공한다. 해당 API는 Odsay API를 활용했다.

• 경로 안내 알고리즘을 직접 짜보고 싶었는데, 정확한 구현에 실패했다. 직접 모든 data를
  코드로 넣더라도, 수도권 노선도의 경우 갈라지는 노선이 존재해 어느 노선을 먼저할지 답을 찾지 못했기 때문이다. 가능하다면 리팩토링 단계에서 직접 만든 알고리즘으로 대체하고 싶다.

04. Member 기능 멘토가 되다

• DEEP 프로젝트 당시, BE공부를 시작한 팀원과 멘토링을 진행했었다. 그 팀원이 무럭무럭 성장해(?) 드디어 코드 구현을 맡게 되었다. 팀원은 Member를 담당했다.

• Member 기능은 아주 기초적이면서 JWT나 Oauth 2.0등의 고급 개념이 더해진 기능이라 생각한다. 어렵다 판단되는 개념들은 같이 공부를 통해 나 역시 한 번더 짚고 넘어가 이해를 높이는 좋은 경험이었다.

• 프로젝트 시 BackEnd 코드는 단계가 아주 명확하다고 생각한다. 개인적으로 이런 부분이 장점이라 생각하는데, 팀원 역시 단계별로 코드를 구현해 이해가 더 빨랐다.
  ID, PW 찾기나 프로필 편집과 같은 단순 select 구조는 한 번에 구현한 뒤, 다시 복습해보는 시간을 가졌다. 같이 성장한 기분이라 정말 기뻤다.

05. ELK

• 지난 DEEP 프로젝트 당시, 서버에 대한 이해도가 부족해 ELK를 결국 꺼야했다.
  그 때의 경험을 반면교사 삼아 이번에는 EC2 t3.large 요금제를 구매해 ELK를 구동했다.

• t3.small의 경우(DEEP) memory가 2GB였지만 t3.large는 8GB로 작동에 성공했다. Controller 시작과 끝 부분에 Log가 호출되도록 처리를 했다. 팀원들이 기능 개발할 때 호출되는 API를 보며 얘기를 했더니 그걸 왜 보냐고 혼이 났다. 그래도 너무 기뻤다!

06. 1차 결과

• 프로젝트가 진행될수록 애정이 깊어졌다. 모든 프로젝트가 그랬겠지만, 스스로 성장하는 것이 체감이 되어서 그런걸까? 그래도 AI나 최신 기술이 없어 참 아쉬웠다.

• 다 같이 ReadMe를 꾸미고, 동영상을 찍고 YouTube에 올리면서 이제 100만 구독 가는거냐고 설레발도 쳤는데 제발 합격하고싶었다. 다들 너무 고생했는데.. 팀장으로서 좋은 결과로 보답하고싶었다.
  

• 다른 후기들을 찾아보니, 1차에서 떨어졌다는 이야기가 많이 보였다. 또 보고서를 풍부하게 쓰는 것이 좋다는 팁도 종종 보였다. 최대한 노력해서 쓴다고 썼는데, 13장밖에 나오지 않았다. 꼭 제출하고 나서야 아~ 이것도 쓸걸!! 하고 후회가 됐는데 합격했다!

• 추석 연휴가 지나고 나면, 멘토링과 함께 보완을 한다. 결과와는 상관 없이 최선을 다해 후회가 안남는 마무리를 하는게 목표다.

• 🚇 [공모전] 2024 공개 SW 개발자대회 후기 [이번역] 회고_03
• 🚇 NoneStep GitHub : https://github.com/None-Step/None-Step-BE.git