뷰어앱 출시 프로젝트 회고

드디어 나도 코로나 2차 백신 접종자가 되었다. 내 몸 속의 백혈구들이 백신 속 바이러스들과 치열한 싸움을 하고있는 것 처럼, 지난 2개월간 나와 우리 회사 팀원들도 함께 도기보기 뷰어앱 출시 프로젝트라는 치열한 싸움을 마침내 끝내게 되었다(끝이라고 하고싶다).

2개월이라는 기간 동안 나와 팀원들 함께 노력했던 과정들을 시간이 지난 후에도 기억하고싶었고, 프로젝트를 진행하며 답을 찾지 못했던 질문들에 대한 답들도 미래에는 찾을 수 있을 것 같아 이참에 기록해보고자 한다. 기억이란 것은 항상 미화되거나 머리에서 지워지니까.

동호대교는 저녁 12시면 불이 꺼진다는 사실을 알게되었다

📌 1. 프로젝트 요약

  • 기간 : 8월 초 ~ 10월 7일, 약 2개월
  • 프로젝트 산출물
    • 악화된 건강
    • CCTV 영상과 도기리포트를 볼 수 있는 안드로이드, iOS 앱(a.k.a 뷰어앱)
    • 뷰어앱을 위한 백엔드 서버(FastAPI)
    • 뷰어앱에 임베딩되는 CCTV, 도기리포트 웹페이지(Vue)
  • 참여한 인력
    • 개발 3명, 디자인/기획 1명
    • 개발 인력 중 1명은 외부 인력으로서 React-Native 개발을 맡았고, 각자 회사의 다른 개발 업무도 진행하며 해당 프로젝트에 참여하였음.
  • 나의 포지션
    • 프로젝트 개발 업무 관리 / 백엔드(FastAPI) 서버 개발 / 공기계 앱(안드로이드), 기존 메인 서버(Flask) 로직 수정 개발(다른 분들도 웹 수정 개발, 백엔드 개발, 게다가 이 프로젝트 이외의 업무도 함께 했어야했다)

📌 2. 개발 내용

2.1 FastAPI 백엔드 개발

  • 기존에 운영중인 Flask 기반 서버에 로직을 구현하는 것을 고민했지만, 서비스가 이런저런 시도를 하다보니 남게되는 레거시 코드들과 로직들이 점점 쌓여가고있어 새로운 프레임워크의 백엔드를 별도로 구현하기로 결정했다.
  • FastAPI의 기능 중 API 자동 문서화(swagger)로 팀 외부에 계신 RN 개발자 분과 소통, 테스트가 편리했다.
  • 프로덕션용 서버 개발을 위해 해야하는 여러 장치들(환경 변수 관리, HTTPS 적용, JWT 토큰 등)을 공부하며 적용했다.

2.2 공기계 앱(안드로이드) 로직 수정 개발

  • 이번 프로젝트를 진행하다보니 기존에 운영중인 CCTV 영상 송신용 앱은 리포트되는 에러만 수정하는 것만으로도 빠듯했다.
  • 뷰어앱이 출시되면서 해당 앱에서는 몇몇 화면이 없어진다던지, 앱의 플로우가 일부 수정되어야 했다. 다행히도 코드를 수정할 때 기존 로직을 잘 드러내기만 하면 되는 것들이어서 다행이었다. 역시 이럴 때를 대비해서 코드를 짜는거구나! 싶었다. 지금 불편하고 머리 터질 것 같아도 언젠가는 감사할 순간들이 온다는 것을 경험했다.(언제까지나 계속 유지되고 오래 갈 코드라는 전제에서)
  • 안드로이드 코드에 손을 댄지 좀 오래돼서 이전의 코드들과 나의 과오(?)들을 마주하는게 부끄러웠다. 왜 이렇게 짰지? 누가 보면 욕하겠다…싶었다. 이런 걸 자극으로 삼아서 시간 날 때마다 리팩토링을 고민해보고싶다.

2.3 기존 메인 서버(Flask) 로직 수정 개발

  • 현재 서비스를 받쳐주는 백엔드는 Flask를 이용하고있다. 관련해서 기존 백엔드 로직도 수정해야했는데, 이 또한 기존 레거시 코드들에서 필요한 로직을 걷어내고 수정하는 것들이 주된 업무였다.
  • 내 코드를 누군가 보면 ‘???’하는 순간이 올 것 같은데, 최대한 읽기 쉬운

📌 3. 아직 정제되지않은 생각들 메모

  • 이정도면 괜찮지 않을까? 테스트 대충해도 돼지 않을까? 하는 마음이 드는 것이 놀라웠다.
  • 커뮤니케이션에 관하여
    • 같이 구현해야하는 것에 있어 상대방을 설득해야하는 연습을 많이 한 것 같다.
    • 반대로 내 의견을 내려놓고 공동의 목표에 더 초점을 맞춰 상대방의 의견을 받아들이는 연습도 하게된 것 같다.
    • 이 프로젝트에 주로 참여하지 않는 다른 팀원들에게 진행상황을 더 잘 공유했었으면 좋았을 것 같다. 안해서 딱히 문제가 된 일이 있던 건 아니지만, 아무튼 더 좋았을 것 같다.
  • 툴을 알아놓는 것을 하면 좋을 것 같다.
    • 외부에 있는 인력과 내부 인력간의 소통을 도울 수 있는 툴(공동 문서, 메신저를 통한 소통 규칙 등)을 많이 알아두면 좋을 것 같다. 우선은 손에 닿는 방식으로 시도하긴 했지만 효율적인 방식을 연구하고 적용하려고 노력하는 시간이 부족했던 것 같다. 이래서 한 번 큰 시스템에 몸담고 일을 해보는 것도 필요하다고 하는 것 같다. 연구하는 건 오래 걸리지만 이미 기존에 잘 만들어지고 다듬어진 방식도 의미가 있다고 생각한다.
    • 문서가 필요할까? 라는 생각도 잠깐 해보게 되었다. 어느 정도의 문서가 필요하고 필요하지 않을까?
  • 출시 주간
    • 출시를 위한 타임라인을 짜고싶었지만, 파트가 워낙 다양해서 꼼꼼히 하지는 못했다.
    • QA를 체계적으로 하지 못한 것 같아 아쉽다.
  • 사람에 관하여
    • 사람은 각자 강점이 있고, 완벽한 사람은 없다.
    • 역시 사람은 마감 기간이 다가오면 열심히 한다.
    • 완벽한 계획은 없는걸까?

📌 4. TODO

  • 팀원 분들과 1대1로 티타임 가지기
    • 피드백 받기
    • 고민은 없는지?
    • 하고싶은건 없는지?
  • docker화 해서 배포 자동화하기
  • 꾸준한 리팩토링하