개발일지 (1월 2주차 회고)

 

 

Overview

 

본격적으로 2021 1Q 업무를 수행하면서 개발하는 내용들이 구체적으로 정해지고, 그에 따라 공부해야 하는 내용들도 구체적으로 정해졌던 한 주였다. 지난주의 다짐에 따라 우선 주말에는 취미로 iOS 개발 공부를 시작했다. iOS개발을 하기 위한 여러 가지 방법 (Object C, Swift, React Native등) 들이 있지만 Stanford cs193p강의를 메인으로 삼았기 때문에 개발 내용은 Swift, SwiftUI로 진행하는 일이 대부분이었다.

 

 

좋은 학교에서 체계적으로 진행하는 수업이다보니 과제의 퀄리티도 굉장히 좋았고, 단순히 클론 코딩으로 가르치는 방식이 아닌 내부적으로 Swift라는 언어가 동작하는 방식까지 소개하는 수업이라 흥미가 있었다. 개인적으로는 OOP를 '지원'한다는 느낌보다는 '지향'한다는 느낌이 강해서 자바스크립트와 비교하면서 공부하는 재미가 있었다. 

 

 

또한 웹개발을 하지만, 콴다 앱에 들어가는 웹뷰를 작업하는 일이 많아짐에 따라서 기존의 메인 랜딩페이지를 작업하는 것과는 차이가 조금 있었다. 아무래도 데스크톱 브라우저에서 띄우는 것이 아닌, 디바이스 환경에서 띄우는 것이다보니 디바이스의 웹뷰가 지원하는 선에서만 동작을 처리해야하거나, 지원하지 않는 경우 앱 개발팀들과의 소통을 통해 설정을 바꾸어야 하는 일들도 꽤 있었다. 특히 디바이스의 특성상 비교적 많은 CPU리소스를 소모할 수는 없기 때문에 이에 따른 적절한 Throttling, Network Optimization등의 최적화 방안을 고민해야 했다.

 

 

입사한지 얼마 되지 않았지만, 아무래도 웹쪽 지원이 많이 필요했던 상황이다보니 바로 새롭게 들어가는 랜딩 페이지 개발을 시작하게 되었다. 내부적으로 Infra팀이 있지만, Nextjs를 사용해서 기본 프로젝트를 빌드하고, Sentry설정을 만지고, Elastic Beanstalk 환경 설정 및 Jenkins파일 설정은 웹 개발자가 해야할 일이라고 생각했다. 회사가 지향하는 방향이 '정보의 투명성'이다 보니, 다행스럽게도 사내의 AWS Infra에 대해서 직접 눈으로 보면서 익힐 수 있었고, 여러 설정들을 확인해보면서 무사히 CI/CD등 새 프로젝트 배포(아직은 껍데기 뿐이지만)를 마무리했다.

 

 

iOS & Swift

 

결론부터 말하면 '수업이 굉장히 재미있다' 그 중심에는 적절한 난이도의 과제도 한몫하는 것 같았다. 아무런 배경이 없이 처음에 듣기에는 다소 난해할 수 있겠다는 생각이 들긴 했지만, 수업을 시작할 때 그래도 내가 자바스크립트에 조금 익숙한 상태였다는 점, 그리고 MVVM, MVC패턴들에 대해 약간의 이해를 가지고 있다는 점에서 개념을 이해하는데에는 크게 무리가 없었던 것 같다.

 

 

스위프트라는 언어 자체가 자바스크립트와 비슷하고, 기본적으로 OOP의 패러다임을 통해 개발을 하면서도 중요한 로직들은 함수형 파이프라인을 통해 처리하기 때문에 굉장히 직관적이었고, 애플에서 인터페이스들에 대한 문서화를 잘 시켜두어서 강의를 듣다가 알쏭달쏭한 부분들이 나오면 바로 문서를 찾아보면서 공부할 수 있어서 효율 측면에서도 꽤 괜찮았다.

 

 

특이한 개념들, 그리고 다소 난해한 개념 및 상황들은 추후 따로 포스팅하면 좋을 것 같다는 생각이 들었다.

 

 

Frontend

 

항상 데스크탑 -> 모바일 순서로 레이아웃 개발을 하다가 '모바일' 만 개발하면 되는 상황에 놓여서 비교적 간단할 거라고 생각했지만 생각보다 고려해야 할 것이 많았다. 특히 iPhoneX등 Notch가 있는 디바이스의 경우 따로 Safe Area에 대한 고려를 해 주어야 했다. 이 Safe Area도 버전에 따라 polyfill 처럼 env, contstant등으로 설정을 해 주어야 했다. 기존에 개발되어 있는 코드는 Safe Area를 무시하는 속성 (이 영역까지 레이아웃에 모두 사용)을 사용하고 있어서 notch 영역이나, 화면 하단의 slider를 침범하지 않게 이를 고려한 패딩 설정을 해 주어서 UX를 개선했다.

 

viewport-fit = cover

 

 

 

 

 

웹뷰에서 동영상 Preview를 할 일이 생겼는데, 당연히 그냥 html5 video tag를 사용해서 autoplay를 하도록 구현했더니 안드로이드에서는 앱이 크래쉬가 났고, iOS에서는 영상이 재생되지 않았다. 확인해보니 보안상의 문제로 디바이스에서 사용하는 웹뷰의 동영상을 inline play할 수 없도록 설정이 되어 있어서, 이를 클라이언트 쪽에서 설정해주어야 했고, 설정을 변경하니 영상이 제대로 출력되는 것을 확인할 수 있었다.

 

 

AWS & InfraStructure

 

EC2

Elastic Computing Cloud: 클라우드에서 확장 가능한 컴퓨팅 용량을 제공 -> 단순 스토리지가 아닌 연산을 수행할 수 있는 인스턴스를 제공한다. 기본적으로 이곳에 서버 리소스들을 할당하는 것 같다.

 

 

S3

Simple Storage Service: EC2와는 다르게 '저장 용량'을 제공한다. 따라서 HTML, CSS, JS등의 스태틱파일을 저장하거나, image, video등의 리소스들을 저장하는데 주로 사용한다. 이번에 S3에 대해서 공부하면서 새롭게 알게 된 사실은 S3가 단순히 물리적 저장 영역을 의미하는 것을 넘어서 '논리적인 방식'을 함께 사용하는 저장 방식이라는 점이었다. S3는 Object Storage(객체 스토리지)를 의미하는데, 저장 공간이 물리적으로 손상을 입었을 때 이를 복구하기 위해 논리적인 방식으로 구성하여 (NAS 디스크 저장방식과 비슷하다) 피해복구 능력을 갖추었으며, 버전 관리가 가능하다는 장점이 있다. 따라서 높은 내구성과, 높은 가용성을 저렴한 가격으로 얻을 수 있는 서비스 정도로 정리할 수 있었다.

 

 

Aws Amplify

사내에서 EB등을 통해 배포하는 것을 보고 여러 가지 다른 배포 방법들을 찾아보다가 Amplify를 찾아보게 되었다. Amplify콘솔은 배포자동화 도구이며, 특히 정적 파일들에 대한 배포에 큰 장점을 지닌다. 일단 사용법이 굉장히 간단하고, Github과 연동하여 버전 관리가 가능하며, CI/CD까지 몇번의 클릭으로 쉽게 설정할 수 있게 해준다는 점이 편리했다.

 

찾아보니 내부적으로는 S3 & CloudFront를 사용하고 있으며, CloudFront를 사용하고 있음에도 불구하고 새로운 배포를 할때 따로 캐시를 Invalidation해 줄 필요가 없다는 장점을 가지고 있었다. 즉 새로운 배포가 모든 곳에서 즉시 반영이 된다는 것이다. 하지만 비교적 커스텀하기가 귀찮으며, 큰 시스템에는 적합하진 않을 것 같다는 생각도 들었다.

 

 

CloudFront

Aws에서 제공하는 CDN서비스로, 캐싱을 통해 빠른 전송속도를 지원한다. 즉 지구 반대편에서 요청을 보내도 CDN을 통해 서버가 있는 곳에서 요청을 보낸 것처럼 빠르게 응답을 보내줄 수 있다는 것이다. 아마존은  Edge서버를 전 세계 이곳저곳에 두어 캐시로 활용하고 있으며, Download Distribution(HTTP Resources), Streaming Distribution(Real Time Streaming Protocol)을 모두 지원한다. 사실상 AWS의 인프라를 활용하면서 CloudFront를 사용하지 않는 서비스는 거의 없는 것 같다.