Table of Contents
글을 시작하며
안녕하세요. 이 블로그를 운영하기 시작한 이후로, 처음 제 개인적인 이야기를 적는듯 합니다.
그동안 적지 않은 일이 있었습니다. 일단 가장 큰일은 이직 을 하게 되었습니다. 이 과정에 제 개인적인 생각들과 앞으로의 방향성에 대한 여러가지 고민을 해 볼 수 있었죠. 그덕에 본격적으로 다시 집중해서 공부할 영역을 정할 수 있었습니다.
블로그를 새롭게 개편하게 되었습니다. 디자인과 기능등에 작은 변경사항 들이 생겼죠. 큰 이슈는 없었지만, 이번에 겪은 소소한 팁들을 공유할까 하는데요. 큰 덩어리를 놓고 보자면 React.js + Node.js 로 직접 SSR 을 구현해 놓았던 블로그를, 처음 배포했을 때와 같이 Next.js 로 바꾸었습니다. 이부분에 대한 자세한 이야기는 따로 글을 적을 생각입니다.
그럼, 본격적인 이야기를 시작해 보겠습니다.
이직
저는 약 5년간 백화점에서(흔히 유통업계라 불리는) 옷을 판매하는 일을 해왔습니다. 그리고 28에 처음 코딩이라는 것을 시작하였죠. 어쩌다 보니 판교에서 개발로 돈을 벌고 있었고, 어쩌다 보니 약 3년 7개월 이라는 시간을 근무한 회사를 떠나 이직을 하게 되었습니다.
제가 이전에 근무하던 회사는 생활연구소 라는 회사입니다. 주로 청소연구소 라는 이름으로 서비스 중인 앱의 Backend API, DevOps, Web/Mobile Frontend, Backoffice Back/Frontend 에 관한 일을 했습니다. 팀은 Server 팀 이라고 불리는 팀에 있었으나 사실상 흔히들 Full Stack Engineer 라 불리우는 롤을 맡고 있었죠. 개인적으로 특별히 맡고 있던 역할은 사내 매출, 정산과 관련된 모든 엔지니어링을 담당하고 있었습니다.
너무 많은 부분을 맡고 있지 않았냐구요? 사실 저는 개발자로서의 첫 커리어를 시작할 때 모든것을 다 할 수 있는 회사를 원했습니다. 기본적으로 서비스를 나 혼자 운영할 수 있는 스킬의 기본을 쌓아보고 싶었죠. 그리고 그 시간동안 참 많은것들을 경험했습니다.
왜 떠나게 되었는가
개인적으로 생활연구소 라는 회사는 정이 굉장히 많이 든 곳이었습니다. 제가 입사할 당시 저를 포함한 직원이 채 20명 이 되지 않았었고, 시리즈 투자는 받기전 이었습니다. 저는 이 회사의 창업멤버를 제외한 첫 웹 개발자 로 입사한 사람이었죠. 이후 함께한 시간동안 회사는 시리즈 A, B, C 투자를 받았고, 직원은 어느덧 100명 에 가까이 늘어나 있었습니다.
제게 3년 7개월 이란 시간은, 이 모든 것들을 만들어 나가기 위해 동료들과 함께 무던히 노력 했던 시간이었습다. 어느덧 한국 이름보다 요한(john) 이라 불리는 것이 더 익숙해져 있었을 정도이니 말입니다. 이렇게 정이 든 회사를 떠나며 이직을 결심한 계기는 개발자로서의 커리어에 대한 고민이 가장 큰 영향을 주었습니다.
좋으나 싫으나 4년차의 개발자가 된 저로서는 어느 한 분야에 집중을 해야 할 시기가 된 것 같다는 생각을 했습니다. 그리고 Web 잡부로 일해온 저로서는 이제 집중해야 할 것을 찾아야 겠다는 생각을 하는 시기가 되었죠. 결과적으로 저는 Web Frontend 라는 분야를 선택하게 되었습니다. 그렇다고 흔히 말하는 Backend 에 관련한 공부를 놓을 생각은 없는데요. 그 이유는 제가 생각하는 Frontend 라는 분야의 특성이 사실 Backend 와 다르다면 다르고, 어찌보면 또 다르지만은 않다 이기 때문입니다.
앞으로의 계획
앞으로의 계획은 굉장히 단순합니다. 저는 제가 가장 잘 하는 것을 꼽으라면 안되는게 될때까지 그냥 꾸준히 하는걸 잘합니다. 그래서 그냥 앉아서 계속 공부할 생각입니다. 아울러 새로운 회사에 도움이 되어야 겠죠. 이 조직에 얼마나 더 있을지, 정확히 어떤일을 더 하게될지는 아직 모르지만 입사한지 얼마 되지 않은만큼 일단은 적응에 힘을 쓰려 합니다. 그리고 어서 도움이 되는 동료가 되어야겠죠.
추가로 소홀했던 블로그에 글을 좀 열심히 적을 생각인데요. 제가 공부했었지만 잊어버린(Network, 브라우저, Javascript, DevOps 관련 등...) 부분들 중 웹개발을 할 때 꼭 알아야 한다고 생각하는 부분들에 대한 공부를 다시 집중해 할 생각입니다. 특히나 Javascript 의 딥한 부분이나, 메커니즘 등이 가물가물하여 당분간 그 부분에 집중할까 합니다. 여기서 제가 생각하는 Frontend 개발자가 알아야 한다고 생각하는 부분에 대한 이야기를 조금 해보겠습니다.
Frontend 개발자는 어디까지 알아야 하는가
이부분은 개인적으로 할말이 많은 부분입니다. 특히나 주니어 분들. 혹은 취준생 분들께 꼭 말씀드리고 싶은 이야기 입니다. 처음 취업을 준비할 시기에 Javascript, CSS, React, Vue 등등등 과 더해 Browser, Network 등등의 공부를 누구나 할 것으로 생각이 됩니다. 당연히 javascript 잘 알아야 겠죠. 실무자 라면 평소 팀에서 쓰는 라이브러리도 잘 사용해야 할 것입니다. 라이브러리나 프레임워크 없이 바닐라로 코딩도 할 수 있어야 하구요. 그러나. 저는 그 이후에 이야기를 하고싶습니다.
Frontend 개발자 임에도 불구하고, Backend 를 알아야 한다고 생각하기 때문입니다. 더 나아가 웹 서비스에 대한 전반적인 지식과 운영에 관련한 지식을 꼭 갖추어야 한다고 이야기 드리고 싶습니다. 물론 이건 Backend 개발자라 하더라도 제 생각은 크게 다르지 않습니다. Backend 개발자도 Frontend 알아야 한다고 생각합니다. 기본적으로 자기가 집중하는 분야는 진짜 엄청나게 파고, 나머진 적당히 해야한다 라는 이야기를 하고 싶습니다.
API 를 협의한다면
백엔드 개발자와 API 를 협의한다고 가정해 보겠습니다(REST 로 설계가 되어있다는 가정). 기획에 추가 요구사항이 생긴 덕에 새로운 데이터를 내려받아야 하는 상황입니다. 가령 Frontend 개발자의 시선에서는, 이 데이터는 기존에 부르던 API에 그냥 데이터 하나만 더해서 내려주면 로직상 더 깔끔하게 처리가 가능한 상황입니다. 그러나 Backend 개발자는 굳이 새로운 API 를 하나 더 만들고 이걸 나중에 한번 더 호출해 달라고 요구합니다. 물론 그 이유는 당연히 설명해달라 하면 다 설명 해주시겠죠. 그러나 이때 빠른 납득과 이해를 위해서는 백엔드를 어느정도 좀 알면 좋다는 생각을 자주 합니다.
이를테면 우리가 현재 만드는 서비스의 트래픽이 만만찮다고 가정해보죠. 그럼 메인페이지(예를 들어 home) 라던지 혹은 리스트를 내려주는 API 를 작성할때, 교과서에서 배운대로 코딩을 하면 디비가 그냥 죽어버리는 경우를 종종 만날 수 있습니다. 간단히 예를 들다면 이런 쿼리를 날린달까요.
SELECT * FROM post ORDER BY updated_at DESC;
물론 slave 달고, 캐시하고, 이때 캐시전략은 어떻게 해서 여긴 MongoDB 쓰고, 여긴 그냥 Redis 쓰고, 뭐 어쩌구의 영역이야 그정도 트래픽을 감당해야 하는 서비스는 당연히 잘 되어있겠죠. 그럼에도 불구하고 불가피한 상황이 생깁니다. 이부분을 깊게 들어가면 이야기에 주제에서 너무 벗어나는 듯 하여 이 이야기는 여기까지만 하겠습니다.
혹은 조회가 정말 많은 메인 페이지에서는 DB 를 최대한 때리지 않게 설계를해서 부하를 감당케 해야하는 상황 인지라, 처음에 부르는 API 에서 DB 를 때려 동적으로 데이터를 만들어내는 로직을 넣기가 곤란한 상황이 종종 있습니다. 어떨땐 DB 를 때리는 로직을 넣기는 하지만 내려주어야 하는 데이터를 만들기 위해, 상대적으로 부하가 큰 로직을 작성해야 하는 경우가 더러 있죠. 저는 이럴때 클라이언트 개발자 분들께 양해를 구하고, 협의를 요청했었는데요. 이부분을 이해해주시는 분들과는 정말정말 협업할때 수월했습니다.
물론 훌륭한 Frontend 엔지니어 분들이 많기에 이런 부분을 모른다는 의미로 한 이야기는 아닙니다. 다만 Web 서비스 하나가 전체적으로 어떻게 돌아가는지에 대한 메커니즘을 잘 이해한다면 협의를 하는 과정이나 기타 스펙을 잡아나아가는 과정에서 빠른 의사결정을 하는데에 도움이 될 것이란 생각입니다.
이부분은 Backend 엔지니어도 마찬가지 입니다. Figma 에 나타난 flow 상 중간저장 등이 명시되어 있거나, submit 이 한번에 일어나는 것이 아니라 쪼개서 일어나야 하는데 이걸 무시하고 그냥 하나의 통 API 로 설계를 해버린다면 의도치 않게 까다로운 상황이 생기겠지요.
말의 요지는 Web Service 를 만드는 개발자라면, 분야 불문하고 이 Web Service 전체가 어떻게 돌아가는지에 대한 전체적인 이해를 하는것이 좋지 않을까 란 생각을 저는 합니다.
운영(Operations)과 최적화의 영역을 생각해보자 (with.Server Side Rendering)
이부분은 특정 주제(Server Side Rendering) 에 대한 이야기를 나눌때 제가 참 아쉽다 느낀 부분이 많았는데요. SSR 이 마냥 장점만 있는것은 아닙니다. 일단 제가 SSR 이 가지는 가장 큰 트레이드 오프라 생각하는 부분은 Server 를 운영 한다는 부분입니다. 만약 작은 서비스라 하면 크게 문제가 되지 않을 수도 있습니다. 하지만 순식간에 수천 ~ 수천만, 혹은 그 이상의 request 가 일어나는 서비스의 SSR 을 진행한다면 어떤 부분을 고려해야 할까요? 어마어마한 request 가 짧은 시간내 발생할 가능성이 있다면요.
말그대로 대용량 트래픽 처리 에 대한 부분을 꼭 고려해야 합니다. 물론 SSR Server 가 Backend API Server 에 비해 수평 확장에 대해 대체적으로 유리하다는 것은 맞다란 생각입니다. 허나, 이부분은 정적 페이지로 서비스 하고, 이부분은 나중에 데이터를 페칭하도록 해서 CSR 로 화면을 그리도록 하자. 이부분은 동적으로 바뀌어야 하는 데이터가 있지만 완전히 실시간 성일 필요는 없으니, 캐시를 도입해서 부하를 줄이자 라는 등의 의사결정을 위한 논의가 필요합니다. 아울러 팀원들이 이에대한 경험이 없다면 섣불리 도입했다가 오히려 더 큰 폭탄과 함께 할 수도 있는 부분이란 생각입니다.
너무나 당연한 부분입니다만. 트래픽에 대한 스케일링과 여러 대응이 제대로 되지 않는다면, 단지 first paint 만 빨라진채 밀려오는 요청을 힘겹게 처리하는 서버의 응답만을 기다리고 있는 브라우저를 사용자는 보게 될 것입니다. 오히려 더 느려질 수도 있다 는 뜻입니다. 단순히 속도만 느려진다면 차라리 다행일듯 싶은데요. 서버가 뻗어버려서 서비스에 장애가 나는 상황을 만들지 않으려면 미리미리 스케일링 처리도 하고, 모니터링도 잘 하고, 부하가 친다싶으면 슬랙에 알림도 쏴서 어서 지켜보라는 등등의 대비도 잘 해야겠죠.
제가 가장 아쉬웠던 부분은 그냥 우리 페이지 뜨는 속도가 느리니 SSR 을 도입하자 란 단순한 주장을 들을때 였는데요. 페이지가 왜 느린지 프로파일링을 제대로 해보지도 않고 이런 말을 하는것은 너무나 섣부른 접근이라는 생각입니다. 아니 지금 느린게 js chunk file 이 커서인지, image load 가 느린것인지, api call 이 느린 이유인지를 정확히 알지도 않은채 무작정 도입 한다니요. 속도를 개선하거나, 사용성을 개선하기 위한 방법은 굉장히 다양합니다.
- Code Splitting 이 되어있다 해도, main chunk 가 크다면
tree shaking이 제대로 되고는 있는지 분석해보고, main chunk 의 사이즈를 줄이는데 우선적으로 힘을 쓰면 됩니다. - image file 에 대한 로드가 느리다면 이에대한
resizing,CSS Sprite,lazy loading등과CDN등을 도입하면 됩니다. - 혹은 그저 image 의 width 와 height 에 해당하는
skeleton만을 미리 그려주어도Layout Shift를 굉장히 많이 개선할 수 있습니다. - 이외에도 수없이 많은 방법이 있겠지요.
저는 위와같은 우선적인 개선사항보다 더 큰 이점이 있을때. 그리고 위의 사항이 이미 충족되었으나, SSR 로 얻는 추가적인 요소가 있을때 도입하는 것이 SSR 이란 생각입니다. 그리고 회사입장에선 가장 중요한 문제중 한가지인 비용 문제를 생각해야 합니다.
기존에 CDN 을 이용해 웹 서비스를 제공하던 회사라고 가정하겠습니다. 이때는 CDN 비용만을 생각하면 되었습니다. 하지만 이제 Server 를 운영하는데 비용이 추가됩니다. 사용자가 정말 많은 서비스에 화면을 그려내는 SSR Server 의 비용을 생각한다면, 만만찮을 것입니다. 비용만이 문제가 아닙니다. 이를 운영하고 관리하는 인적 자원역시 더 필요할것은 자명한 사실입니다.
React.js 프로젝트를 Next.js 로 이관하고 빨라졌다고 해서 이게 모두 SSR 덕이란 생각은 섣불리 하지 않으셨으면 좋겠습니다. 실제로 Next.js 가 해준 작업들 중에 image 최적화, ssg, code splitting 등 어느 부분이 내 어플리케이션에 속도를 높여 주었냐가 더욱 중요한 아젠다 입니다.
운영(Operations)과 최적화의 영역을 생각해보자 (with.Edge Computing)
직전 언급한 사항들을 상쇄해 내고도 더큰 비즈니스적, 퍼포먼스적인 이득이 있냐를 우선적으로 고려하는 것이 저는 맞다고 생각합니다. 하지만 위의 요소가 전부다 충족되어 이제 SSR Server 를 운영한다고 가정 해보겠습니다. 그럼 우리 Frontend 개발자들에겐 어떤 지식이 필요로 하게 될까요?
얼마전 2022 FEConf 에서도 그렇고, 사실 수년전부터 이런 이야기는 참 많이 대두 되었습니다. 웹의 미래는 엣지다 라는 뉘양스의 이야기 말입니다. 저는 이 문장에 격하게 공감하는 1인입니다. 이제는 국내에서도 이런 이야기는 심심찮게 들립니다. 관련 내용에 관하여, 비교적 최근 접한 링크 두가지를 첨부합니다.
그럼 이어서, 우린 뭘 공부해야 할까요?
Internet 서비스의 근본적인 부분을 이해해야 한다는 생각입니다. 예를들어 수많은 MicroService 로 이루어진 서비스가 있다고 가정해 보겠습니다. 이때 BFF 에서 GraphQL 등을 사용한 고도화를 직접 시도해 볼 수 있지 않을까요?
혹은, 각 edge location 별 커스텀 함수를 태우는 작업을 Frontend 엔지니어들이 하면 어떨까요? 이미 aws lambda@edge 등을 통한 이미지 리사이징 등의 기능은 너무나 흔하게 사용되고 있습니다. 저는 앞으로 이 부분이 더욱 발전될 것이라 생각하는데요.
이에따른 Server 의 스케일링, CDN, 그리고 이로인해 신경써야 하는 요소에 관한 공부를 한다면 조금더 대체 불가능한 개발자로서 성장해 나아가지 않을까란 생각을 합니다. 저역시 너무나 모자란 부분이 많기에 꾸준히 공부를 해야하지만 Frontend 란 분야는 제가 생각하기에 참 매력적인 분야입니다.
마치며
저는 위 언급한 부분과 같이 기존에 공부한던 부분에서 백엔드에 대한 부분에 비중을 조금 줄이는 대신, 제가 부족하다 느끼는 browser, javascript, node.js, devops 에 대한 부분을 꾸준히 공부하려 합니다.
이전엔, 코드가 아무리 거지같아도 장애는 DB 에서 난다는 말에 엄청난 동감을 하며 query 튜닝에 힘을 써 왔었습니다.
이제는 Frontend 와 관련된, 한번쯤 공부는 했었지만 기억이 잘 나지 않는 부분을 복습하는 마음으로 다시 공부하고, 그에대한 글을 꾸준히 작성하려 하는데요.
WebService 의 최적화와 Network, 자바스크립트의 깊은부분을 다루는 책을 샀습니다. 한동안 잊고 있던 부분을 다시 부여잡아 보려 합니다. 어서 읽고싶네요. Frontend 개발자로서의 새로운 시작이 어떻게 끝나게 될진 모르지만, 늘 노력하는 개발자가 되고 싶습니다.
이 블로그에도 글을 더욱 자주올려 다른 개발자 분들께 도움이 되고 싶습니다. 무던히 노력하겠습니다.
긴글 읽어주셔서 감사합니다. 여러분의 코딩이 늘 즐거우셨으면 합니다.