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

정은아·2025년 1월 19일
1
post-thumbnail

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

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


📌 01. 3주간의 쉬는 시간(Feat. ☁️구름톤☁️)

☁️ 구름톤이 4회차 우수 수료생에게 준 100만원짜리 숙박권

  • 8월 28일 제출 완료 후, 9월 9일 결과가 나왔고 우리는 멘토링이 시작되는 시간까지 잠시 쉬는 시간을 갖기로 했다. 추석이 껴있기도 했고, 2차 프로젝트를 준비하기 위해 잠시 숨을 돌리기로 했다.
  • 나는 2023년 11월부터 2024년 5월 말까지 구름톤 풀스택 과정을 우수 수료생으로 수료했는데, 우수 수료생에게는 제주도 펜트하우스 숙박권을 준다. 미리 신청한 기간과 겹쳐 친구들과 함께 다녀왔다.
  • 펜트하우스는 정말 좋았다. 따로 성산일출봉을 볼 수 있는 공간도 있었고, 개인 수영장도 있었다. 따로 이용 가능한 옥상도 있어 기분전환하기에 정말 좋았다! 😄😄
  • 구름톤은 다양한 프로젝트와 과제들을 온라인으로 교육 받을 수 있는 기회라 생각해 지원했다.
  • 인프런 강의를 통해 내 속도에 맞춰 자율적으로 공부하고, 팀원들과의 스터디 덕분에 개발자로서 많이 배울 수 있었다.
  • 또한, 교육을 받으면서 만난 팀원들과 프로젝트를 진행해 유의미한 결과를 갖게 되어 뜻깊었다.
  • 10년만에 만난 제주도는........ 폭풍이 몰아쳤다..... 실화냐..? 돌아가는 날에 집에 가게 해달라고 싹싹 빌어서 겨우겨우 집에왔다;;

📌 02. 추가 기능 회의

😀 2차 기간 시작 직후 회의 내용들

  • 1차 보고서에는 우리 프로젝트의 보완점과 추가 기능에 대한 이야기를 적었었다.
    알림과 신고 기능이 그것이었지만, 그 기능이 과연 우리 프로젝트의 정체성을 보완하는가에 대해선 많은 이야기가 오고 갔다.
  • 이 프로젝트에서 확실히 어필하기 위해서는 지하철과 관련된 기능이면서 우리가 구현 가능해야하는 기능이어야 했다.
  • 이미 사용자에게 유용한 정보 10가지를 제공하고 있었고, 추가 기능으로 어떤 기능을 추가할지에 대해 갈피를 잘 잡지 못했다.
  • 이 회의가 꽤나 길게 이어졌다. 사용자에게 유용한 기능이되, 개발자의 입장으로 의견을 내는 것은 여전히 어려운 것 같다.

📌 03. 멘토링

  • 공개 SW개발자대회 1차 예선을 통과하게 되면, 멘토링을 받을 수 있다.
  • 담당 멘토님께 코드 관련된 멘토링을, 사회 문제형 프로젝트의 경우 사회 단체의 멘토링을 받아 기능을 보완할 기회가 주어진다.
  • 결과적으로 말한다면, 두 멘토링 모두 큰 도움이 됐다.

💎 03-1. 코드 멘토링

  • 코드 관련된 멘토링에 있어서는 웹 구조 내에서 할 수 있는 기능과 할 수 없는 기능에 대해 명확하게 기준을 제시해주셨다.
  • 같은 기능이 IOS와 Android 휴대폰에서 다른 반응을 보일 때가 종종 있었는데, 우리가 만족할 수 있는 수준으로 보완하기 위해서는 앱구조로 코딩해야했다.
  • 앞서 말했던 timeout error에 대해서도 멘토링을 받은 결과, 직접 개발한 API가 아니기 때문에 한계가 있다는 답변을 받게 되었다. 이후 보완하기는 했지만 아쉬움이 남았다.
  • 마지막으로 우리팀이 수상할 수 있는 확률에 대해 여쭤봤다. 대회 OT날 LLM에 대한 특강이 있었고 AI없이 수상할 수 있을까?가 우리의 화두였기 때문이다.
    멘토님께서는 충분히 가능하다고 응원해주셨다. 😄😄

💎 03-2. 사회문제형 멘토링

💡 가장 중요한 키워드는 결국 사회적 안전망이다. 안전이 가장 중요하다.

  • 추가 기능에 대해 고민이 많았다. 당시 지인 중 특수 교사로 일하던 지인을 포함해 주위에 정말 많은 의견을 모으고 있었다. 가장 인상적이고 관심이 갔던 기능은 아래와 같다.

    ✔️ 지하철 하차 후, 휠체어를 탄 상태에서 계단을 오르기 위해서는 도움이
         필요하다. 보통 벨을 눌러 해당 역의 직원에게 도움을 받아야 하는데
         이 시간이 꽤 길다. 도착 시간에 맞춰 도움을 받을 수 있다면 좋을 것 같다.

  • 출발 역과 도착 역을 입력하면 웹 구조에서 알림을 보낼 수 있지 않을까?
    몇 분의 간격을 두고 해당 역의 전화번호와 함께 알림을 보낼 수 있다고 생각했다.

  • 하지만 웹 구조에서 어떻게 알림을 보낼 것인지에 대해 답을 찾지 못했다.
    역시 어플이 아니기 때문에 알림을 보내기엔 한계가 분명했다.
    사용자가 우리 page를 끈다면? 배터리가 없거나 오류로 인해 휴대폰이 켜지지 않는다면?

  • 그러면 우리가 해당 회원의 정보에 기입된 휴대폰번호로 문자를 보낼 수는 있지 않을까? 하지만 소셜로그인 회원의 경우에는? 우리는 멘토링에서 뜻 밖의 답을 찾을 수 있었다.

✔️ 알림 문자는 도움이 된다. 또한, 현재 몇몇 역에서는 노인들의 일자리와
     연계해서 지하철 편의시설을 안내하는 근무를 하고 있다.
✔️ 그러나, SW적으로 해결하는 것 이전에 장비, 인력의 문제 해결이 우선이다.
     현재 서비스가 중단되었거나, 역무원의 부재, 휠체어 리프트 고장 등의
     경우가 정말 많다. 또한, 수도권 강남역을 예시로 동선이 복잡하고 불편하다.
✔️ 해당 문제의 경우 SW보다는 인력으로 해결해야하는 문제이다.
     이와 같이 정상적으로 프로세스를 처리할 안내원이 필요하다.

  • 더불어서 사용자에게 알림 등의 고지는 좋은 방법이지만, 부담을 주는 것이라고도 하셨다.

  • 해당 문제는 개인이 해결하기보다는 지자체 혹은 정부에서 해결해야하는 일이라는 이야기에 공감이 갔다. 어느 부분까지 SW가 사람을 대체하고, 대체할 수 없는가에 대해서도 생각하는 계기가 되었다.

  • 다음으로는 혼잡도 기능에 대해 여쭤봤다. 실시간 혼잡도에 대한 열망이 컸지만, 기술적으로 불가능했다. 차선책인 통계성 혼잡도가 도움이 될까?에 대한 의문이 있었는데 당연히 도움이 된다고 답변을 주셨다.
    거동이 불편한 사람에게는 정보만으로도 충분히 도움이 된다고 말씀해주셨다.

  • 또한, 지하철을 반드시 타야하는 이유가 있다면 반대로 지하철을 타면 안되는 이유에 대해서도 말씀해주셨다. 장마, 홍수 등 지하철을 탈 수 없는 날에 대해서도 말씀해주셨고, 우리는 이를 토대로 침수 피해 지역에 대해 조사하게됐다.

  • 추가적으로 사회적약자에 대해 구체적으로 정의하는 것을 권유해주셨다.
    어린이나 여성(임산부 등)의 경우도 고려할 것을 추천해주셨다.
    해당 조언을 바탕으로 우리는 지하철 이격 거리 안내를 추가하게 되었다.


📌 04. 추가 기능

✔️ 목록

  • 노인 계층을 위한 큰 글씨 page (메인page 및 편의시설 조회 등)
  • 시각 장애인을 위한 사진 음성 안내 기능
  • 지하철 역 및 경로 즐겨 찾기 기능
  • 지하철 지연 등의 공지 게시판
  • 실시간 날씨 안내
  • 전국 공중 화장실 안내
    공중 화장실의 경우, 장애인 화장실이 필수 요소이므로 + data 존재
  • 이번역 비상모드
    일부 data를 캐싱해 저장한 뒤 데이터가 없는 상태에서 볼 수 있게한다.
    비상, 재난 상황 등에서 사용 가능하게 대비한다.
  • 기후동행카드 등 추가 data 작업
  • 채팅 내 신고, 차단 기능
  • 침수 피해 알림
  • 지하철 혼잡도 안내
  • 지하철 환승 시 경로 안내
  • 위 내용을 포함한 여러 추가 기능 의견들이 나왔고, 구현 가능성사용자의 편의성을 고려해 즐겨찾기, 공지 게시판, 실시간 날씨, 편의 정보 추가 제공, 침수 피해 알림, 혼잡도의 기능을 추가하기로 결정했다.

📌 05. 리팩토링

  • 멘토링과 회의를 반복하며 추가 기능에 대한 뼈대를 다지는 동안, 이미 구현한 기능에 대한 리팩토링도 함께 시작됐다.
  • 리팩토링은 크게 비회원 채팅 조회지하철 정보 시간 단축이었다.
  • 회원 유입을 높이기 위해 채팅 서비스의 경우 조회는 비회원도 가능하게 보완했다.
    수정 전, 채팅의 모든기능은 Token이 필요하게끔 구현 완료했으나, 조회 API에서 Token을 제거했다. 단, 비회원 상태에서 채팅 입력시 로그인 알림이 뜨게끔 수정했다.
  • 지하철 정보 조회의 경우 수정 전, 편의 시설 조회 시, 모든 data를 조회한 뒤 사용자의 반경 내의 정보만 빼온 뒤 Front에 전달하는 구조였다. 평균 21ms가 소요됐다.
  • 해당 쿼리의 문제점은 모든 데이터를 조회한 뒤, 추가로 필터로 걸러내어 필요한 데이터를 추출하는 데에 메모리가 많이 소모된다는 점이었다.

✔️ 쿼리 수정 전(평균 21ms)

✔️ 쿼리 수정 후(평균 11ms)

  • 해당 로직을 모든 데이터에서 사용자의 반경 내에 있는 정보만 조회한 뒤, 필터로 걸러내지 않고 바로 Front로 전달하게끔 수정 완료했다.
  • 리팩토링을 하지 않았다면 불필요한 메모리가 계속 낭비됐을 것이다. 해당 문제를 캐치해내고 수정해 뿌듯했다.
  • 추가적으로, Front에서는 메인 페이지의 아이콘 크기를 키워 가시성을 높이는 작업을 하거나 Main Page Loading Lazy Decoding Async 작업을 완료함으로써 속도를 향상시켰다.

🚇 [공모전] 2024 공개 SW 개발자대회 후기 [이번역] 회고_04 보기
🚇 이번역 Git

profile
꾸준함의 가치를 믿는 개발자

0개의 댓글