개발일지 (3월 회고)

 

 

Membership 출시

 

1월부터 시작했던 프리미엄 멤버쉽 출시가 (드디어) 3월 초에 배포가 되었고, 어느 정도의 안정화 작업을 거쳐서 실 결제하는 사용자들이 하나 둘씩 생기게 되었다. 사내에서도 처음으로 구독결제 서비스를 출시하는 것이었기 때문에 기술적으로 여러 가지 고려해야 할 것들이 많아서 팀원들이 정말 고생을 많이 했구나 하는 생각이 들었다.

 

 

웹쪽에서는 사실 클라이언트와의 브릿지 연결 & 데이터 로깅등을 통한 일종의 매개 역할을 해주어야 하는 일들이 많아서 직접적으로 구독/해제 모델에 대한 기능 구현쪽과는 복잡하게 묶여있지는 않았지만, '웹뷰' 환경이기 때문에 고려해야 하는 여러 기술적인 과제들이 있었다.

 

 

클라이언트 웹뷰는 Operating System자체가 기존 데스크탑 브라우저에서 열리는 환경과는 다르게 많은 제약을 가진다. 일단 기기 자체가 한정된 '배터리'를 소모하기 때문에 '저전력모드', 'sleep mode'등의 기능이 들어가게 되며, 이는 필연적으로 animation frame에 대한 제약, cpu throttling에 따른 성능 저하를 가져온다. 또한 이전 기기의 웹뷰에 할당되는 메모리 및 CPU Resource 제약등의 이슈로 인해서 정상적인 상황임에도 페이지 로드가 늦게 되는 이슈 등이 있어서 이를 고려해서 구현을 해야 했다.

 

 

[개발시 고려한 이슈들]

- OS 환경을 고려한 Inline Video Play: 저전력모드, 잠금화면, 백그라운드 등의 OS이슈들을 고려해서 자연스러운 UX 구현

- Performance Optimization: 리소스들의 resizing, video transcoding

- Conditional Rendering: 우선순위가 높은 리소스들이 먼저 다운로드 되고 렌더링 된 후에, 이후 컴포넌트들을 렌더링함.

- Server Side Rendering: 기존의 Jamstack 배포 방식에서 렌더링 성능을 개선하기 위한 SSR 방식으로의 변경.

- api 도메인 분리: Server To Server Domain은 internal domain, Client To Server Domain은 gateway로 변경하여 내부 서버를 보호

 

 

Design System

디자인 시스템에 대해서 3월 중순쯤에 처음 듣게 되었던 것 같다. (나중에 포스팅할 기회가 있겠지) 개발자와 디자이너 사이에는 항상 크고작은 의견차이가 있게 마련인데, 실제 프로덕션 개발할 때는 이 의견차이에서 비롯된 오해들이 개발비용을 증가시킨다는 것을 어렴풋이 체감하고 있었던 터라, 디자인 시스템에 대한 매력이 조금 크게 다가왔던 것 같다.

 

개발자와 디자이너 사이의 Single Source of Truth로 기능하여, 둘 사이의 소통에서 오는 오해를 최소화한다는 점과, 디자이너의 입장에서는 기획시에, 디자인 시스템의 컴포넌트들을 기반으로 해서 조금 더 큰 그림을 설계하는데 리소스를 사용할 수 있으며, 개발자의 입장에서도 fontset, font-size, background-color등과 같은 디테일에 신경쓰는 비용을 절약해서 로직 구현에 더욱 집중할 수 있다는 점에서 도입의 필요성을 느꼈다.

 

2주정도의 리서치를 진행한 후에 디자인 팀과 이야기하는 시간을 가지게 되었고, 마침 디자인 팀에서도 필요성을 느끼고 있었던 터라 1분기 내에 디자인 시스템 가이드를 전달해주겠다는 답변을 받았다. 2분기 정도부터는 Packaging 작업과 함께 간단한 Component들부터 서서히 대체할 수 있을 것 같다.

 

Operating System & Database

 

웹쪽이슈는 항상 특정 기간에 몰아치는 일이 많은 것 같다. 조금 여유로운 기간에는 서버쪽을 서포트하기 위해 서버 공부를 이것저것 하고 있는데, 아무래도 레이아웃, 크로스 브라우징 등의 고려사항이 적은 대신에, 운영체제, 데이터베이스등 CS분야의 지식이 비교적 많이 필요한 것 같다는 생각이 들었다. 

 

아직 운영체제, 데이터베이스등의 과목들을 수강하지 않고 산업기능요원 복무를 시작했기 때문에, 온라인강의 & 원서등을 통해서 미리 공부하는 셈 치고 수강을 하게 되었다. 실무와 관련된 부분들이 많으니만큼, 확실히 이론적인 내용만 들을때보다 이해라든지, 필요성등이 더 와닿는 공부를 했던 것 같다. 현재 운영체제, 데이터베이스 두 과목 모두 1/3~ 1/2정도까지 수강한 상태고, 중간고사나, 실습과제등의 압박이 없는 강의들이니만큼 4월 말까지 수강을 완료하는 것을 목표로 잡게 되었다. 

 

특히 운영체제의 구조나, 프로세스, 스레드, 스케줄링등의 개념은 서버뿐 아니라, 브라우저(이건 사실 운영체제나 다름없는것 같다)를 이해하는 데에도 큰 도움이 되는 것 같다.

 

Deep Learning

 

이직을 결심하게 된 여러 이유들 중의 하나가 높은 수준의 '딥러닝'기술을 보유한 회사라는 것이었다. 아무래도 프론트엔드 개발자로 입사하다보니 직접 코드를 만지고 커밋할 시간들은 많이 없었지만, 언제든 질문하고 의견을 나눌 수 있는 문화가 마련되어 있어서 내가 얼마나 준비되어 가느냐가 관건일 것 같다는 생각이 들었다. 

 

아직까지는 '평생을 걸고 연구를 하고싶다' 정도의 흥미를 느끼지는 못하고 있어서, 어플리케이션을 만들기보다는 이것저것 원서 읽고, 논문 읽으면서 호기심을 충족하는 정도의 공부를 하고 있는데, 5월달 즈음에 여유가 조금 생긴다면 간단한 프로젝트를 하나 진행해도 좋을 것 같다는 생각이 들었다. Ian GoodFellow 저서인 Deep Learning을 구매해서 천천히 정독하는 것이 2분기 목표가 될 것 같다.

 

Spring Study

 

사실 PS를 자바로 해서 자바라는 언어자체가 어색하지는 않지만, 스프링은 잘 모른다. 그리고 스터디를 진행하면 할수록 내가 모르는게 많다는 사실을 깨닫게 되어 기분이 좋은 것 같다. 내가 모르는게 많고, 내가 모르는 것들을 아는 사람들이 주변에 있고, 또 이들은 친절하게도 나의 질문에 성심성의껏 답변을 해준다는 걸 프로베이션 기간 동안 알게 되었다. 

 

십여년 가까이 되는 시니어 백엔드 개발자들과, 무섭게 달려드는 주니어 개발자들과 함께 스터디를 한다는 것 자체도 굉장히 즐거운 경험이고, 일단 뭐라도 준비해가면 부족한 부분들을 성심성의껏 코멘트해주시는 것들을 보면서 스터디때마다 조금씩 기대를 가지고 가는 것 같다.

물론 아직 프로덕션의 API를 짜고, 최적화 하는데까지는 조금 시간이 더 필요할 것 같지만 말 그대로 '스터디'이니만큼 천천히 자바라는 언어 자체에 대해서도 이 기회에 공부를 좀 해보려 한다.

 

공부를 하면서 느끼는 거지만 Spring Boot가 나와서 참 다행이다. 이거 각잡고 세팅하려고 했으면 일주일 이상의 시간이 그냥 증발했을지도 모르겠다는 생각이 든다

 

Side Project

 

훈련소 다녀와서 주말이나 휴가때 틈틈히 진행했던 Side Project가 어느덧 마무리되어가는 것 같다. 나중에 상세한 포스팅으로 공유할 예정이긴 하지만, 처음부터 잘 짜여진 코드가 아닌 여러 사람들을 거치면서 누더기가 되어 버린 코드를 받아서 이걸 찢어지지 않게 함과 동시에 새로운 주머니를 만들어내야 하는 일은 참 많은 생각이 들게 한다.

 

유쾌한 경험은 아니지만, 이런 개발을 몇번 진행하다보니 '좋은 아키텍쳐란' 무엇인가를 절실하게 느끼게 되는 것 같다. 그리고 좋은 아키텍쳐가 갖는 장점은 프로젝트가 커져갈수록 많은 비용을 아끼며, 새로운 기능을 추가할때도 이를 비교적 수월하게 해주는 것 같다.

 

맨처음에는 React, Angular, Vue를 보고 와 프론트는 왜이리 공부해야 하는 프레임워크 & 라이브러리가 많지 라고 생각했었는데, NodeJs, Spring, Django등으로 이루어진 각각의 프로젝트의 코드들을 보고 나니 '그래도 쟤네는 언어는 하나잖아'라는 생각으로 바뀌고 있다. NodeJs는 가벼운데다가 프론트와 동일한 자바스크립트를 사용하기 때문에 처음에 개발할때는 비교적 수월했지만, 파일업로드 같은 기본적인 기능조차 depedency install을 해야하는 번거로움은 조금 있는 것 같다. (너무가볍다)