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

 

Overview

 

Web Programming

 

여러 분야의 개발을 동시에 하면서 항상 그래 왔지만 유난히도 '참 가야 할 길이 멀구나' 싶은 생각이 들었던 한 주였다. 우선 프런트엔드 쪽에서는 그동안 개발했던 웹 랜딩페이지(+모바일 대응) 보다는 철저히 모바일을 위한, 데스크톱이 아닌 디바이스의 환경에 최적화된 웹뷰 작업이었다. 프론트엔드 개발을 하면서 가장 귀찮았던 것이 크로스 브라우징이었는데 디바이스 쪽은 훨씬 고려해야 할 것들이 많았다.

 

 

기본적으로 브라우저 대응(iOS -> Safari, Android -> Chrome)및 다양한 해상도와 Notch 등의 디바이스 특성 등을 고려하면서도 전반적으로 데스크톱이 아닌 디바이스이기 때문에 고려해야 할 사항들(보안상 이슈로 인한 동영상 플레이 제한 등)까지 신경 쓰다 보니 생각보다 고려해야 할 것들이 많아졌던 것 같다. 특히 웹뷰 내에서의 상태 관리가 아닌 웹뷰와 클라이언트 간의 브리지 통신을 해야 하는 경우 인터페이스를 정의하고 테스트하고 수정하는 과정이 생각보다 까다롭고 귀찮았다. 

 

 

 

Server Programming

 

이래저래 웹뷰쪽 개발을 어느 정도 마치고 나머지 기획과 디자인이 확정되는 동안, 웹뷰에서 해야 할 일들의 우선순위가 조금 밀려서 서버 쪽 서포트를 할 수 있게 되었다. Django Admin 쪽과 DRF를 사용한 간단한 REST API 구현하는 일을 맡았는데, Python자체를 굉장히 오랜만에 사용해본 것 같아서 Javascript에서 사용하는 문법과 맞지 않는 부분들을 다시 공부하고 수정하느라 시간이 들었다.

 

 

이전에 NodeJS로 서버를 개발했었는데, 기본적으로 시스템을 설계하고, API를 구성하는 패러다임 자체는 동일했지만, 워낙에 두 언어가 달라서 이 차이를 메워가는데 시간을 많이 사용했다. 기본적인 수준에서 간단한 알고리즘을 작성하거나, 간단한 웹 프로젝트를 개발하는 데는 깊은 이해까지는 필요 없을지도 모르지만, 앞으로 웹 개발만큼이나 Server개발 비중이 높아질 것 같아서 Python 공부를 다시 틈틈이 시작해야 할 것 같다. 좋았던 건, 회사에서 이미 Django로 쓰인 코드들이 많이 있어서 이 코드에 사용된 개념들이나 라이브러리의 기능들을 위주로 우선 공부하고 질문하면서 방향을 빠르게 잡을 수 있다는 점이었다.

 

 

서버 쪽은 웹 브라우저처럼 복잡하게 크로스 브라우징에 대한 신경을 크게 쓰지 않아도 된다는 장점이 있지만(SSR로 서버 쪽에서 렌더링 하는 경우를 제외하고 순수한 API 서버나 인증서버로 사용되는 경우), 그만큼 전체 인프라에 대한 지식이 필요하며, 특히 규모가 커질수록 아키텍처에 민감하게 신경을 써야 하는 것 같다(이건 웹도 마찬가지이긴 하지만)

 

 

친구들이 추천해준 여러 Docs와 저서들이 많은 도움이 되었다. '객체지향의 사실과 오해', '오브젝트'등의 책을 통해(개인적으로 객체지향의 본질에 대해 잘 소개하고있는 책이라 생각한다.) 그냥 구글 검색으로 대충만 알고 있었던 객체 지향 패러다임에 대해 조금 더 깊은 이해를 할 수 있었고 이를 적용해서 '역할과 책임'을 기준으로 이번에 새로 개발하는 기능에 대해 유지보수하기 쉬운 스키마를 정하는 과정에서 여러 의견들을 낼 수 있었다. 규모가 어느 정도 있는 팀 프로젝트에서는 생각보다 개발하는 시간만큼이나, 어쩌면 더 많은 시간을 아키텍처를 설계하고 이런저런 시나리오들을 점검하는 과정에서 더 많은 시간을 사용하며, 그만큼 중요하다는 것을 느끼게 되었다. (애초에 아키텍처의 중요성을 알고 이를 미리 설계하려는 개발자들은 개발을 잘해서 시간이 적게 걸리는 건 아닐까 하는 생각이 들기도 한다.)

 

 

Django, Django Admin, Django Rest Framework등의 기본 Docs자체도 굉장히 많은 도움이 되었다. 회사에서 기존에 작성된 여러 코드들을 보면서 모르는 Method나 Class가 나오면 바로바로 Docs를 찾아보면서 공부하는 방식으로 Follow up을 했고, 이번 프로젝트에서 고려해야 할 여러 서버 코드들에 대한 Follow up을 순조롭게 진행할 수 있었다. 

 

 

아쉽게도 Javascript, Python을 동시에 익히는 것도 벅차다고 느꼈기 때문에 Python & Django Followup을 어느 정도 수준까지 익히기 전까지는 잠시 Swift는 현실적으로 보류하는 것이 맞겠다고 판단했다.

 

 

 

Infrastructure

 

Django Server에 대해 공부하고, 아키텍쳐에 대해 의논하다 보니 자연스럽게 Infrastructure에도 많은 관심을 가질 수밖에 없었고, 전체적으로 추상화된 시스템이 실제로는 AWS에 어떻게 배포가 되어 있는지, 무엇을 사용하여 어떻게 연결되어 있는지에 대해 관심을 가지고 이것저것 찾아보았다. 

 

AWS에서 생각보다 많은 기능들을 지원한다는 것을 새삼 느낀다. 기본적인 로드 밸런싱이나,  Static file, Computing Resources들을 비롯해서 CI/CD, Authentification 등 한 회사가 프로덕트를 만들기 위해 필요한 모든 과정들과 요소들을 가지고 있다는 것을 다시 확인했다.

 

 

 

Details

ffmpeg: 크로스 플랫폼을 지원하는 오픈소스 멀티미디어 프레임워크로 동영상 파일의 재생이나 인코딩 툴들을 개발하는데에도 사용한다. 샘플로 제공받은 영상에 여러 가지 전처리가 필요했는데, 이를 서버 쪽 코드로 옮기기 전에 QA팀과 적절한 해상도와 배속, Thunail 추출 등을 의논하기 위해서 Scratch로 여러 테스트 샘플들을 만들어야 했다. 이를 몇 줄의 코드 만으로 옮길 수 있게 해 주었다.

 

 

프레임 배속, 영상의 프레임을 특정 비율로 Crop, 음성 제거, 해상도 조절 등 기본적인 영상처리에 필요한 것들을 단 한 줄의 Command Line으로 처리할 수 있다는 것이 가장 큰 장점으로 다가왔다. 서버 쪽 영상처리 코드에도 ffmpeg 라이브러리를 도입할 가능성이 커진 것 같다.

 

 

HLS: HTML Video Tag의 퍼포먼스를 위해 (저사양 기기에서도 문제없이 동영상 Preview가 재생되어야 하니까) 영상의 용량이나 재생 원리 등을 찾아보던 중 링크를 타고 타다가 도달하게 된 개념이다. HTTP Live Streaming의 약자로 HTTP 프로토콜을 사용하여 라이브 스트리밍을 가능하게 하는 프로토콜이다. 회사에서 스트리밍 서비스도 제공하고 있어서 이 부분은 조금 심도 깊게 공부하고 싶다는 생각이 들었다. 자세한 내용은 추후 포스팅을 통해 다루려 한다.

 

 

Deep Link: 딥 링크란 모바일 애플리케이션의 특정 페이지에 도달할 수 있는 링크. 모바일 애플리케이션도 각자의 프로토콜을 가지고 있다. (e.g: youtube://) 모바일 애플리케이션의 특정 페이지로 이동하는 기술을 의미하는데, 생각보다 고려해야 할 것이 많다. 사용자의 접속 환경에 따라, 사용하는 기기에 따라, 애플리케이션의 설치 유무에 따라 각각 처리해야 할 사항들이 다르기 때문이다. 태생적으로 HTML이 모두에게 공개되어 있는 것과는 다르게 딥 링크는 애플리케이션의 데이터 베이스 내의 데이터를 가리키고 있기 때문에 이를 '검색 엔진'의 형태로 묶는 것이 어려워서, 구글, 야후 등의 검색엔진들이 이에 많이 관심을 가지고 있는 상태인 것 같다.