개발일지 (4 & 5월 회고)

 

 

Overview

4월 회고를 쓰려고 보니 5월이 다 지나가 버렸다. 별 수 없이 4~5월 회고를 쓰기 위해 키워드를 정리하는데 생각보다 이것저것 배운 게 많은 것 같아서 회고할 타이밍을 굉장히 잘 잡았다는 생각이 들었다. 초당 수만 ~ 수십만 건의 대용량 트래픽이 발생하는 애플리케이션의 최전선에서 여러 버저닝을 관리하고 예측하기 어려운 에러들을 핸들링하는 기회가 모든 개발자들에게 찾아오는 건 아닐 것 같은데, 이런 경험을 쌓아나간 것 같아서 감사한 마음이 들었다. 

 

 

FrontEnd Service With Million Traffics

 

 

900만명 가까운 사용자가 접속하는 웹 프로젝트를 맡아 개발하는 데에는 참 많은 책임이 따른다는 걸 배웠다. 이전에는 TF에서 맡은 컴포넌트만 몇 개 만든 다음에  QA 돌려보고 PR올리고 Approve 받고 머지 -> 잘 돌아가네 끝이었는데, 프로젝트 자체를 담당하게 되다 보니 여러 가지 신경 써야 될 것들이 많아졌다.

 

5월은 특히 코드를 작성하는 기간만큼이나 가이드, 컨벤션 문서를 작성하는데 시간을 많이 쏟았다. 내가 맡은 웹 페이지가 애플리케이션에서 가장 트래픽이 많은 페이지이고, 사실상 회사에서 중요한 서버들을 다 찌르고 다니는 프로젝트이기 때문에 Production에서 한번 오류가 나서 사용자들이 갑자기 요청을 더 많이 보내게 되면 (잘 나오던 페이지가 제대로 안 뜨니까 2~3번씩 더 추가 요청을 보내는 것 같다.) 인스턴스가 갑자기 급증하는 트래픽을 감당하지 못하고 각종 서버에 요청을 어마어마하게 때리고 서버며 DB며 줄줄이 터진다. 

 

이러한 상황이 5월중에 한번 발생했고(바로 리버트 해서 큰 문제는 없었던 것 같다. 대신 한 30분 정도 장애가 있었다 ㅠ) 이를 막기 위한 대안책을 마련하는데 시간을 조금 쏟았다. 

 

 

1. 프로젝트의 오랜 숙원이었던 테스트코드를 붙였다. 아직 커버리지는 미미하지만, 개발 가이드에 테스트 코드 작성을 Approve 조건에 필수로 넣으려고 하니 점점 커버리지가 높아질 것 같다.

 

2. 여러 TF에서 개발이 일어나기 때문에, 각각의 개발 사항은 별도의 환경에서 QA를 진행할 수 있도록 가이드를 작성하고 인프라팀과 회의를 통해 클론 환경 만드는 가이드를 작성했다. 웹뷰이기 때문에 브라우저에서 테스트하거나 앱 브라우저에서 테스트할 때는 보이지 않던 사항들이 인앱브라우저로 들어가면 생기게 된다. 여러 TF에서  QA시 일어나는 간단한 디자인 이슈 수정한 커밋들이 하나의 Develop브랜치에 조목조목 쌓이다 보니  production 머지할 때 여러 개발사항들이 동시에 올라가거나 지저분한 체리 픽 과정을 거쳐야 한다. 이걸 막기 위한 목적이 가장 컸다. 한 번의 Production 머지에는 가급적 하나의 개발사 항만 포함이 되고, Develop브랜치의 커밋 히스토리가 리버트, 핫픽스가 쉽게끔 깔끔하게 정리하고 싶었다. 

 

3. 주석 & 디렉토리 가이드 및 Webview개발 가이드 등을 작성했다. 웹 개발자가 없는 TF도 있기 때문에 임시로 서버 개발자 분들이 해당 프로젝트에서 개발을 하시는 경우가 있기 때문에 참고하면 도움이 될 만한 가이드들을 최대한 많이 제공하려 한다. 내가 모든 코드를 다 리뷰하는 데에는 한계가 있기 때문에 최대한 편리한 플랫폼으로 프로젝트를 만들려고 한다. 

 

 

 

Study Street (Spring)

교육계에 종사하는 회사이다 보니(?) 사내에 기본적으로 배움에 열정이 있는 멋진 개발자들이 많아서 좋은 것 같다. 사내에 Study Street이라는 채널이 있는데, 해당 채널에서 배우고 싶은 분야들을 나열하고, 투표를 통해 한 분야를 선정한다. 이전 Study때는 Java 언어에 대해 스터디를 했었는데, 입사하기 전에 진행한 스터디라 빠르게 자료만 훑었다. 

 

회사에서 Backend 서비스를 주로 Django로 작성하고 있는데, 특정 시점 이후부터는 서서히 Spring으로 갈아타려는 움직임이 보이고 있어서 Spring에 대한 관심이 높아진 것 같았다. (Spring Boot로 프로젝트 세팅을 해보니 정말 편하긴 하다.) 스터디는 후진 없이 스프링 공식 문서를 처음부터 끝까지 훑는 방식으로 2~3달 동안 진행했고, 파트를 나눠 자신이 맡은 파트에 대해서 깊게 공부하고 발표하는 식으로 스터디를 진행했다.

 

사내의 몇몇 서버들이 Spring으로 개발이 되어 있는데, 시니어 개발자분들께서 해당 스터디에 참여하셔서 특정 파트의 발표가 끝나면 해당 파트가 사내의 어떤 서버에 어떤 식으로 적용되어 있는지, 어떤 식으로 개선할 수 있는지에 대해서 하나씩 코멘트를 해주셨는데, 해당 부분이 정말 많은 도움이 되었다. 처음 공식문서를 접하는 입장에서는 어떤 기능이 자주 쓰이는 기능인지, 어떤 식으로 사용하는지에 대해서는 감을 잡기가 어려웠던 것 같은데 (Production에서 사용되는) 예제 코드를 보면서 감을 많이 잡았고, 내가 맡은 파트를 준비할 때도 해당 프로젝트들을 많이 참고해서 준비하니 도움이 많이 되었다.

 

성공적으로 스터디를 마무리했고, 2Q내로(한달 남았다!) Spring으로 구축된 서버 Project에 간단한 PR이라도 올려보려 한다. 

다음 스터디는 kubernetis 스터디로 정해졌는데, 사실 웹 개발을 주로 하다 보니 쿠버네티스에 대해서는 거의 아는 것이 없지만, 뭔가 기대가 되는 것 같기도 하다.

 

 

 

 

Design System

입사하자마자 프론트엔드 & 백엔드 & 디자인 팀에 열심히 요청했던 것이 바로 "디자인 시스템"이었다. 가장 큰 이유는 디자이너와 개발자 사이의 "인터페이스"를 만들고 싶다는 욕심에서였던 것 같다. 엣지 케이스일 수도 있겠지만 생각보다 디자이너가 이해하는 디자인과 개발자가 이해하는 언어가 다르며, 그 디테일에 대한 집착에도 차이가 날 수 있는 것 같다는 것을 느꼈다.

 

가장 크게는 시간이 흐르면 디자이너도 바뀌고 디자인도 조금씩 바뀐다는 것이다. 그러다 보니 자연스럽게 "레거시"가 생기게 된다. 하나의 앱에서 사실상 동일한 기능을 하는 버튼들이 거치는 디자이너와 개발자에 따라 조금씩 모양과 색깔이 바뀌어간다. 여기에서 나오는 UI의 비일관성을 제거하고 싶었던 마음이 가장 컸던 것 같다. 

 

버튼이 있는 컴포넌트를 만들때마다 hover, disabled의 옵션이 모두 들어간 CSS를 입력하지 않고, 그냥 "디자인 시스템에 있는 PrimaryButton으로 해주세요"로 의사 결정이 되기를 원했다. 버튼 하나 만드는데, 이거 Hover 이펙트는 어떻게 할까요, disabled 하면 이렇게 나오는데 괜찮나요 와 같은 상대적으로 덜 중요한 사항들에 의사소통 비용을 낭비하는 것은 아깝지 않은가. 이는 아직까지도 디자인 시스템을 만들면서 가장 추구하는 방향이기도 하다. 

 

 

5월 중순쯤부터 디자인 팀에서 간략한 가이드를 주셨다. (사내 자산이라 공개하기는 어렵지만) 이를 바탕으로 디자인 시스템 세팅을 하고 Color, Button등의 컴포넌트를 만들기 시작했다. 막상 만들어보니 생각보다 고려해야 할게 많았던 것 같다. 일단 "라이브러리"이기 때문에 Tree-shaking이 잘 되어야 하고, 빌드했을 때 가벼워야 하므로, 해당 사항을 모두 고려해서 번들러를 선택해야 했다.

 

또한 향후 여러 프로젝트에서 import해서 사용해야 하는 라이브러리이므로 테스트 코드를 꼼꼼하게 작성해야 하며, 버저닝을 잘하고, npm private package에 잘 묶어서 배포해야 한다. (이 부분은 6월 중으로 간략하게 가이드를 작성할 것 같다.)

 

가장 애매한 부분은 "어느 정도까지 추상화를 해야 하는가" 인것 같다. input box를 작성한다면, Form 라이브러리까지 넣어주는 게 맞는가? 아니면 프로젝트에서 맞는 form 라이브러리를 넣고, 디자인만 입힐 수 있도록 해야 하는가와 같이 어느 걸 선택해도 되지만, 각각의 장단점이 명확한 사항들이 언제나 문제인 것 같다.

 

2Q 중으로 간단한 컴포넌트들을 완성하여 몇 개의 프로젝트에 시범 적용할 예정이다. 일단은 어떻게든 시작이 되었다는 사실은 충분히 긍정적인 것 같다. 

 

 

AWS Solutions Architect

어떤 계기로 AWS Solutions Architect라는 자격증이 있다는 사실을 알게 되었다. 뭔가 '자격증을 따서 스펙을 쌓자'라는 느낌보다는 AWS에서 자기네들 서비스 이렇게 사용해라 하는 가이드가 있고, 이걸 공인해준다고 하니, 이 자격증을 준비하는 과정 자체가 굉장히 AWS 서비스를 익히는데 도움이 될 것 같아서 무작정 책을 사고, 강의를 끊어서 공부를 시작했다. 

 

회사 내에 인프라팀이 있지만, AWS Infrastructure에 대해 잘 모르는 상태에서 요청하는 것과, 잘 아는 상태에서 리소스를 요청하는 것 사이에는 큰 차이가 있다는 걸 깨닫게 되었다. 웹 개발자이지만, 실제로 규모가 큰 프로젝트의 개발을 하다 보면 컴포넌트를 만들고, 테스트 코드를 짜는 일 이외에도 고려해야 할 것이 꽤나 많다는 것을 느꼈다.

 

프로젝트 세팅만 해도 프로젝트 배포를 정적인 스토리지에 할 것인지, 클라우드 인스턴스에 할 것인지를 결정해야 하며, 내부 서버와의 통신을 위한 VPN설정은 어떻게 되어 있는지, 외부에서 접속하기 위한 DNS 설정은 어떤 식으로 할 것이며, 요청 트래픽 규모 및 애플리케이션 사이즈에 따라 인스턴스 설정 및 로드 밸런싱은 어떻게 할 것인지 등을 알아야 한다.

 

여기에 이미 배포된 프로젝트들의 상태 모니터링을 위해 인스턴스의 HealthCheck, Error monitoring, Sentry등의 에러 로깅 서비스와의 연동, CI/CD 서비스에 테스트 코드, QA를 위한 클론 환경 준비등을 신경 써야 한다. 

 

물론 인프라팀에 요청하면 이 모든 과정들을 진행해 줄 수는 있지만, 프로젝트 담당자가 해당 사항을 어느 정도 이해한 상태에서 큰 틀을 요청하는 것과 그렇지 않은 상태에서 그냥 어떤 서비스인지만 설명하고 나머지를 인프라팀에 요청하는 건 많은 차이가 나는 것 같다.

 

사내에서도 인프라를 AWS로 관리하고 있으며 AWS Solutions Architect의 시험 범위에 EC2, S3, Route53, ELB, RDS등의 핵심적인 개념들을 사실상 모두 다루고 있기 때문에 앞으로의 프로젝트 개발에도 많은 도움이 될 것으로 생각이 되며, 6월 중으로 공부를 마무리해 보려고 한다. 

 

 

 

Reading

올해 가장 잘한 일 중 하나는 '밀리의 서재' 정기 구독을 신청한 것이다. (홍보 아님) 이거 구독 시작한 후부터 책 읽는 양과 질이 기하급수적으로 증가한 느낌이다. 약속시간에 친구가 늦으면 오히려 고마워지고, 지하철을 가끔 타는데 기다리는 시간도 꽤나 유쾌해진 느낌이다. 이전에 책을 한 권씩 들고 다닐 때는, 그날 컨디션이나 감정에 따라 가져 간 책을 별로 읽고 싶지 않을 때도 많았는데, 아이패드 하나에 책을 원하는 만큼 넣어 다닐 수 있어서 굉장히 기분 좋게 그날그날 읽고 싶은 책을 읽을 수 있는 것 같다.

 

앱으로 읽다보니 읽고 싶은 목차들부터 읽을 수 있고, 책을 다 읽은 후에 밑줄 그은 부분만 따로 골라서 읽는 식의 독서가 가능해졌고, 생각보다 훨씬 많이 독서의 질이 높아진 것 같다. 많이 읽는 날에는 일주일에 한 10권에서 15권까지 책을 읽게 되는 것 같다. 

 

내 개인적인 성향 때문인지는 모르겠지만, 독서를 하면 할수록 특정 챕터를 읽고 나면 해당 챕터를 다룬 다른 책들을 여러 권 동시에 읽고 싶다는 생각이 자주 드는데, 앱으로 책을 읽게 되면서 이게 가능해져서 상당히 만족스러운 독서를 했었던 이번 달이었다.

 

하루에 12시간에서 많게는 16시간까지 컴퓨터 앞에 앉아있다 보니 어떤 날은 그냥 컴퓨터의 '컴'자도 꼴 보기 싫어질 때가 있는데, 이때 여행을 다룬 책이라든지, 식물을 기르면 좋은 이유, 커피의 역사 같은 많이 범주가 달라 보이는 책들을 읽으면 다시 힘을 내서 개발을 하게 되는 것 같기도 하다.

 

 

Wayfinding

작년 이맘때쯤부터 진행하던 사이드 프로젝트가 사실상 모두 마무리되었다. 독일 쾰른의 전시회장에 있는 수백 개의 Device에서 특정 Fair, Event, Facility로 길 안내를 해주는 Product의 개발을 맡아 거의 1년 동안 진행했다. Fair의 특성상 시간이 지나면 새로운 Fair가 열리고, 하나의 Fair가 여러 개의 홀을 쓰고, 인파가 몰리면 해당 Fair로의 진입이 막히는 등 고려해야 할 것이 여러 가지가 있어서 학부 시절에 배웠던 여러 알고리즘을 사용하기에 좋았던 프로젝트였다.

 

다만, 항상 느끼지만 이론과 프로덕트의 큰 차이 중 하나는 "노가다"인것 같다. 사람에 따라 그 정의는 다르겠지만, 큼지막한 로직을 잘 만들어낸 후에는 엄청난 디테일 작업이 들어간다. 개발 자체는 한 달 정도 걸려서 4월 정도에 다 마무리가 되었지만, 5월 내내 유지 보수하고 피드백 정리하는데 진땀을 뺐다. 특히 요 Edit Arrow라는 기능을 만드는 게 너무 힘들었다. 특정 signpost에 나오는 방향을 수동으로 설정할 수 있도록 만드는 기능인데, 처음부터 내가 만든 프로젝트가 아니다 보니 사실상 모든 코드를 뒤적거리면서 direction을 수정하는 로직을 넣어주어야 했고, 이거 다시 빼라 그러면 잠수할 것 같다.

 

 

https://www.samsungsds.com/en/story/Nexshop-in-Koelnmesse.html

Samsung SDS’ Digital Signage System Was Deployed at Koelnmesse in Germany, the World’s 7th Largest Trade Fair and Exhibition

 

우여곡절이 많았지만, 리액트를 처음 배울 때부터 맡아서 내 리액트 경력과 함께한 프로젝트이니만큼  잘 마무리가 되었으면 좋겠다. 지금 독일에서 마지막 피드 백중이라고 한다. 6월 중에는 개시한다고 하니 그전에 추가 피드백이 오지 않기만을 바랄 뿐이다. 

 

Side Project

시간에 여유가 조금 있는 날은 2030의 코인 광풍을 따라 코인 모니터링하는 프로그램을 간단하게 만들어보고 있다. (사실상 실험실이다.) Nodejs로 서버를 하나 구축해서 3초마다 가격 당겨오고, 그래프를 그린 다음 흐름을 분석해서 예측하는 프로그램을 간단하게 만들고 있다. 이번에 AWS 공부하면서 이것저것 설정 배우고 있으니 어느 정도 윤곽이 잡히면 EB 띄워서 CMS까지 만들어보려고 한다. 

 

 

Seminar

회사에서 특정 주제로 세미나를 진행하는 '세미나 열풍'이 불고 있어서 좋은 것 같다. 물 들어올 때 노 저으라는 말도 있지 않던가. 나도 6월에 'React Hook System'에 대해서 세미나를 진행해보기로 했다. 개발을 처음 시작할 때는 잘 몰랐는데 자바스크립트가 내 생각보다 버그를 일으키기 쉬운 구조의 언어임과 동시에, '잡기 무지막지하게 까다로운' 버그를 일으키기 쉬운 구조의 언어임을 알아버려서 그 뒤로부터 어떤 프레임워크를 사용하든 간데 'Under the Hood'에 대해 조금 집착하는 버릇이 생긴 것 같다.

 

"보통 React를 사용하는 개발자들도 Hook이 실제로 어떻게 구현되어 있는지까지 공부하지는 않을 것이다"라는 내 지극히 개인적인 주관 하에 세미나를 준비하면 사내 같은 프론트엔드 개발자들에게도 도움이 될 것 같다는 생각도 있었고, 무엇보다 준비하는 과정에서 내가 알고 있었던 것들을 더 확실히 하는 과정을 거칠 것 같아서 조금 제대로 준비하면 어떨까 하는 생각이 들었다.

 

보통 1시간이 넘어가는 세미나는 텐션이 떨어지는 감이 있어서 첫 세미나 때에는 React Hook System에 대한 전반적인 소개와 'useState'정도까지만 다루려고 한다. (그전에 포스팅을 먼저 해야겠지)