콜로나 맵(코로나 원격의료 정보앱) 만들기 기록

이번에 팀에서 코로나 원격의료와 관련한 정보 제공 앱을 만들게 되었다. 질병과 관련해서 형세가 급하게 흘러가다 보니, 원격 의료와 의약품 배달이 한시적으로 법적 제한이 풀리게 되었고, 원격 의료 및 의약품 배달을 실시하는 것에 대해서는 의료인들 자율적으로 따를 수 있게 했다. 해당 경험이 일반인들, 의료인들 모두 전무하다 보니, 프로세스에 대해서도 정부 지침 정도만 있고, 일반인들은 그 조차도 잘 모르는 게 현실이었다. 우리 팀은 PWA로 빠르게 해당 정보를 제공해주는 앱을 만들기로 결정했다

기술 스택

이 앱이 우리 팀의 메인 앱이 될 것이라고 생각하지는 않아서, 익숙하지는 않지만 빠르게 만들 수 있는 스택을 골랐다. 앱 심사가 통과된 경험도 없어서 그 부분에서 얼마나 시간을 써야 할지 모르기 때문에, 우리는 PWA를 통해 사용자에게 앱을 직접 설치할 수 있게 했다. 웹으로 접근하면 이 앱이 무슨 앱인지, PWA를 홈 화면에 추가할 때는 어떻게 해야 하는지, 우리 팀은 이렇게 구성 되어있다. 라는 내용의 3장짜리 페이지를 만들었다.

PWA는 React로 구성을 했다. serviceWorker를 조작하기 쉽게 해놓기도 했고 초기에 선택했던 expo web은 여전히 베타 버전이라고 하고 (분명, 35 버전에는 정식 버전이 릴리즈 될 거랬는데 지금 36이다.) 여러가지 제약이 있어서, 개발 중간에 아주 난처한 상황이 생길까봐 애초부터 리액트를 선택한 것이 있다. 프론트 개발자 친구가 TS에 익숙하지 않아서 JS를 사용하게 되었다. 이번 프로젝트에서 내가 프론트에 참여한 것은 극히 일부고, 배포와 관련된 작업을 진행했다. 애플리케이션 자체의 특별한 기술은 없었고, 배포할 때는 Github Action을 사용해서 S3에 배포되도록 했고, CloudFront를 사용해서 https 통신이 가능하게 했다. 설정하는데 오랜 시간이 걸리지 않기도 했고, 프론트 개발자가 master 브랜치에 머지하게 되면 자동으로 배포되는 환경이어서 배포를 직접 하지 않아도 됐다. 다만 아쉬운 점은 개발 단계에서 빠르게 여러번 배포 해보고 확인하는 과정이 있었는데 CloudFront에서는 캐시가 24시간 지속이 되서, 변경 사항이 제대로 반영되지 않았다. 직접 Invalidating을 해줘야 캐시를 없애고 새로 보여줬다. 이 부분이 프리티어가 이긴 한데 금액이 있다. 확인해보지는 않았지만 앱 자체자 작아서 프리티어 안에 해결할 수 있다고 생각해서 이 방법을 선택했다. 그렇지만 문서에서는 이 방법 보다는 객체에 versioning을 할 것을 추천했다. 이 부분은 아마도 웹팩으로 가능할 것 같기도 한데, 다음 단계에선 꼭 시도할 수 있었으면 좋겠다. 이 링크에서 관련된 내용을 확인할 수 있다.

백앤드는 서버리스 프레임워크를 선택했다. 선택한 가장 큰 이유는 해보고 싶어서 선택했다 (ㅎㅎ…). 그리고 일단, 이 앱에 사용자가 늘었을 때, 운영 환경을 신경쓰지 않고 싶어서라는 이유도 있긴 하다. 서버리스는 항상 관심 갖고 있던 것이기도 하고, 공부는 몇 번 했지만, 실제 프로젝트에 도입해 본 적은 없었다. 서버리스 프레임워크를 사용할 때 아키텍쳐에 대해 무지했기 때문에 그런 부분에서 조금 아쉬움이 많이 남았다. 개발하면서 가장 큰 화두는 아키텍쳐와 CORS 제한이었다. 우리 앱은 실제로 https://corona.deliverypharmacy.co.kr 이라는 앤드포인트와 https://callona.deliverypharmacy.co.kr이라는 앤드포인트 두 개가 사용되고 있다. API Gateway가 모든 서비스에 열려있지 않길 바라기도 해서 CORS 제한을 두려고 했는데, 생각해보니까 여러 앤드포인트를 CORS Origin header로 설정해둘 수 없었다. 그 부분은 뭐… 쉽게 해결이 가능하긴 했다. 그런데 궁금한게 사실 CORS 설정은 람다에서 보내주는 해더를 설정하는 것도 하고, 서버리스 프레임워크에서도 cors 옵션을 넣어줬다. 그렇다면 서버리스 프레임워크에 넣은 건 뭘 하는 데 쓰이는 건가?…

데이터베이스는 DynamoDB를 사용했다. 람다와 가장 잘 맞는 데잍터베이스라는 말을 많이 들어서 사용하긴 했는데 사실 잘 모르겠다. 일단 다른 걸 사용해보지를 않아서 그렇고, API처럼 사용할 수가 있어서 연결 관련된 레이턴시를 줄일 수 있기 때문인가 싶다. 우선 완전 처음은 아니지만 메인 데이터베이스로 사용해본 결과 정말 힘들었다. 이 링크에서 데이터베이스 사용 미숙으로 얼마나 맘에 안드는 코드를 작성 했고, 앞으로 이 작업을 할 생각에 힘이 빠진다는 내용이 있다.

백앤드는 쪽에서는 몇 가지 해결해야지 싶은 것을 남긴 것들이 있는데, 첫 번째로 서버리스 프레임워크를 RDS와 한 번 사용해보는 것이다. RDS를 VPC 내부에서 접근할 수 있게 만들고 싶기 때문에, 람다도 VPC 내부에 배포를 하고, S3 등에 접근하게 하기 위해서는 NAT Gateway같은 방법을 사용해야 한다. 프로젝트를 진행할 생각을 이미 하고 있어서. VPC 안에 람다를 배포하는 데모를 만든 적이 있다. 그리고 서버리스 프레임워크 가이드 중에 Express application에 serverless-http라는 모듈을 래핑해 배포하는 것을 봤는데, 이것도 사용해봐야겠다고 생각했다. layer도 사용해야 할 것 같고, 해보고 싶은게 많긴 하다.

아무튼 우리는 이렇게 개발을 했다.

원격 근무

우리 팀은 만들어진지 얼마 되지 않았고, 그전까지 원격 근무를 해본 적이 없다. 인원도 얼마 없고, 모두가 모여서 일하는게 일상이었는데 코로나가 점점 심해지면서 원격근무를 진행했다. 사실 나는 원격 근무 허용이 좋다. 이러한 상황이 아니더라도 매일을 같은 공간에서 일하고 싶지는 않았다. 원격 근무를 걱정하는 많은 사람들이 도덕적 해이에 대해서 항상 얘기를 한다. 로켓펀치의 조민희 대표님은 성악설을 믿는 사람은 원격 근무가 불가능하다고 말했다고 한다. 무슨 말인지는 알겠는데 뭐 사실 대표하는 자리에 있는 사람일 수록 조직원들의 도덕적 해이가 걱정 안 할 수가 없다는 점은 누구든 공감하지 않을까? 성선설 성악설을 떠나서 일단 팀원에 대한 신뢰가 필요한 거라고 생각한다. 대표자가 팀원에게 신뢰를 보여주는 좋은 경험을 할 수도 있을 것 같다. (우리팀 대표님은 팀원들이 그렇게까지 신뢰가 가지는 않았나보다ㅎ 반대를 많이 하시고 걱정도 많이 한다. 그래도 뭐 결과적으로는 잘 해주고 있는 것 같다고 하시긴 했다.)

결과적으로 원격 근무는 좋다. 일단 현재 지내는 곳, 일하는 곳 모두 근처에 확진자가 많이 있기도 하고, 지하철을 타고 출근하기 때문에 좀 겁도 났는데 지금은 집에서 개발한다. 나의 경우 원격 근무를 진행해본 결과, 근무지와 큰 상관 없이 일을 하는 것 같다. 회사에서 근무 했을 때와, 집에서 근무 했을 때 waka time에 찍히는 시간도 비슷하고 (오히려 집에 있으니, 일상과 업무에 대한 경계가 모호해지면서 업무 시간이 훨씬 길어지기도 한다.), 퍼포먼스도 그다지 차이가 나지 않는다. 잠깐 쉬어야지 하는 것도 훨씬 편하게 쉬고, 스트레칭도 편하게 하고, 통근 시간이 없고 등 좋은 점은 참 많았다.

그럼에도 불구하고 안 좋은 점도 있긴 하다. 혼자 일하고 있자니 솔직히 좀 심심하긴 하다. 그 외엔? 없음 ㅋㅋ