210928 CodeStates 47일차

공윤배·2021년 10월 4일

210928 CodeStates 47일차

오전에는 웹 애플리케이션의 빌드와 배포에 대해 배우고 웹호스팅 서비스 Vercel을 이용해 직접 웹 호스팅 서비스를 이용해보는 실습을 했다.
이번주가 Section2의 마지막 주다.
오전을 마지막으로 Section2의 모든 수업이 끝나고 HA test를 응시했다.

정적웹페이지와 동적웹페이지

  • 정적웹페이지: HTML파일 자체로 배포되는 웹페이지
  • 동적웹페이지: 서버에 의해 동적으로 생성된 HTML파일이 배포되는 웹페이지

이전에 배웠던 SSR(Server Side Rendering)같은 경우는 서버에서 동적으로 렌더링을 진행한 후, 클라이언트에세 완성된 HTML파일을 전달하기 때문에 동적웹페이지이다.
동적웹페이지를 만들기 위해서는 서버가 요청에 따라 매번 동적으로 HTML파일을 생성하여 응답해야만 했다.
따라서, 네트워크상에서 주고받는 패킷의 크기가 다소 컸다.

점차 브라우저의 발달과 AJAX기술이 보편화되면서, 모든 동적인 정보들을 서버에서 부담하여 렌더링할 필요가 없게되었다.
정적인 HTML파일만을 보내고 필요한 부분만을 클라이언트가 요청하게 되면 서버는 알맞은 데이터만을 JSON과 같은 데이터포맷으로 제공하여 클라이언트측에서 렌더링하는 CSR(Client Side Rendering)이 등장하였다.
서버가 동적으로 웹페이지를 렌더링하지 않으며, HTML/CSS/JS파일의 소스코드 그대로 작동하는 특징을 갖기에 CSR같은 경우는 정적웹페이지이다.

빌드

현대의 웹 애플리케이션은 정적웹페이지와 AJAX기술을 함께 사용하며, SPA(Single Page Application)로 변모함에 따라 클라이언트 사이드의 규모가 커지게 되었다.
이때, 웹사이트의 구성요소를 각 파일로 분리하는 모듈화가 이루어진다.
고도화된 현재의 웹 애플리케이션은 수많은 모듈들이 결합되어있다.
이처럼 수많은 모듈들을 하나로 묶어주는 작업을 번들링이라하며, 이 과정에서 JSX파일과 같이 브라우저에서 자체적으로 해석이 불가능한 다양한 보조 기술들을 브라우저가 해석할 수 있도록 만들어주는 작업들이 수반된다.
이러한 과정을 통칭해 소프트웨어 빌드라고 부른다.

소프트웨어 빌드: 소스코드를 실행 가능한 결과물로 변환하는 작업
번들링: 웹 애플리케이션을 이루는 수많은 모듈들을 하나로 묶어주는 작업

Webpack을 이용하여 수많은 모듈을 하나의 정적파일로 만들어내는 번들링 과정

다양한 모듈들은 정적파일들로 결과가 만들어져야하며, 이러한 빌드과정은 배포에 있어서 필수적이다.
React프로젝트를 내 컴퓨터(로컬환경)에서 자체적으로 실행하기 위해서는 npm start로 개발서버를 실행시켜주지만, 인터넷 상에 배포하기 위해서는 개발서버를 실행할 필요가 없으며, 정적파일을 호스팅하는 서비스에 결과물만 업로드해주면 된다.
create-react-app 툴로 생성된 React프로젝트는 npm build을 이용하여 모듈을 정적인 파일로 만들어주는 빌드를 진행할 수 있다.

여러가지 빌드 툴들이 하나의 파일로 번들링하는 과정

프로젝트를 빌드하는데 사용되는 여러가지 툴들이 있다.

  • webpack: 모듈번들러
  • babel: TypeScript,JSX와 같이 브라우저가 해석할 수 없는 언어를 JavaScript로 바꿔주는 컴파일러
  • ESLint: JS Code convention 및 문법검사기
  • Sass,less: CSS전처리기

웹호스팅

로컬환경에서 개발을 진행한 후 개발한 코드를 실제 서비스로 만들기 위해서는, 빌드과정과 이를 웹에 노출시키는 배포과정이 필요하다.
빌드를 통해 만든 정적파일이 웹을 통해 제공되려면, 만들어진 정적파일을 제공하는 웹서버가 필요하다.
정적파일을 제공할 수 있도록 서버의 공간을 대여해주는 서비스를 웹호스팅 서비스라고 한다.
웹호스팅 서비스를 이용하면 내가 직접 서버를 구축하지 않더라도 나의 코드를 정적파일로 만들어 웹에 노출시킬 수 있다.
웹호스팅 서비스는 내가 작성한 코드를 빌드하여 정적파일로 만들고 웹에서 접근가능하게만 해주며, 동적웹페이지나 API서버를 제공하려면, 별도의 클라우딩 컴퓨팅 서비스가 필요하다.

다양한 웹호스팅 서비스들이 있다.

  • Amazon Web Service S3
  • Google Cloud Storage
  • Vercel
  • GitHub Pages

CodeStates과정에서는 Vercel을 이용한 배포를 실습해보았고, 혼자 생활코딩을 보면서 GitHub Pages를 이용해보았다.

Section2 회고

어느덧 CodeStates과정을 시작한지 10주가 지났다.(추석연휴 포함하면 11주)
Section1을 진행할 때에는 크게 어렵지가 않았다.
기존에 JS는 아니더라도 Java나 Python등을 조금은 알고있었기 때문에 React를 제외하면 크게 새롭지 않은 내용들이었다.
딱히 Section1이 끝나고는 회고를 해봐야겠다라는 생각도 들지 않았다.
Section2는 조금 난이도가 있었던 것 같다.

  • 일단 블로그 정리가 너무 어려웠다.
    올해 초 겨울에 몇몇 회사들에 입사지원을 하고 코딩테스트까지 통과한 후, 처음으로 면접을 봤었다.
    그때 당시만 해도, 코딩테스트는 Java,Python을 이용해서 봤었고, 프로젝트 경험이라고는 Spring을 이용한 웹 페이지 개발(?)정도 밖에 없었다.
    사실은 프로젝트라고 하기도 쪽팔린 수준이었다.
    Spring을 제대로 알지도 못했고, 인터넷을 뒤져가며, 조원이 구해온 템플릿에 알맞은 정보만 DB에서 가져와 보여주는 정도였던것 같다.
    그때 면접을 보면서 내가 그동안 배웠던 것은 진짜 아무것도 없구나 라고 느꼈다.
    코드를 작성하여 실행하는 것에 급급했지 한번도 왜 이렇게 작동이 되는가에 대한 개념을 알지 못했기에 면접에서 질문에 잘 대답하지 못했던 것 같다.
    Section2를 진행하며 에러없이 실행되는 코드에 집중하기 보다는 아닌 개념에 대해 많이 정리하려고 노력했다.
    블로그를 정리하기 위해 CodeStates의 자료뿐만 아니라, 온갖 공식문서와 블로그들을 찾아보았다.
    영어가 익숙치 않다는 첫번째 문제점이 있었고, 두번째 문제점은 개념을 알기위해 검색을 하면 내가 모르는 새로운 개념이 등장하는 점들 때문에 정리가 어려웠던 것 같다.
    나무가 아닌 숲을 보자는 생각에 메모장에 조금씩 정리를 하며 하나의 파트가 끝나면 블로그를 작성하려 했는데, 이것저것 찾아보니 점점 블로그작성이 밀리게되었다.
    Section3는 다시 하루에 하나씩 조금이라도 그날 배운것을 정리해야겠다.

  • Section3와 프로젝트를 진행하는 기간까지 포함해서 12주 정도 남았다.
    결국 개발자로 취업을 하는 것이 나의 궁극적인 목표인데 어떤 개발자가 되고싶은지를 잘 모르겠다.
    페어분들을 만나서 얘기를 하다보면 자신이 프론트엔드개발자가 될거라고 말하시는 분도 있고, 백엔드 개발자가 될거라고 말하시는 분들도 있다.
    나도 하루빨리 뚜렷한 목표를 정하는게 동기부여에도 도움이 될 것 같다.

  • Section2를 진행하며 카카오 블라인드 공채에 지원해봤다.
    기본적인 인적사항만 기재하고 바로 코딩테스트를 볼 수 있어 큰 기대는 하지않고 경험삼아 코테만 진행하자라는 생각으로 지원했다.
    작년에는 python으로 3문제정도 풀었던 기억이 있는데, 올해는 몇 문제를 풀수 있을까 궁금하기도 했었다.
    올해는 JS로 4문제를 풀었고, 얼떨결에 1차를 합격했다.
    추석연휴기간에 블로그를 싹다 정리하려 했는데 갑자기 2차 코딩테스트를 진행해야되서 블로그는 또 밀리게 되었다.ㅜㅜ
    추석 연휴의 토요일날 2차 코딩테스트를 봤다.
    결과는 썩 좋지 않았지만, 의외로 CS기초테스트에서 나쁘지 않았던 것 같다.
    정보처리기사를 준비하며 봤던 내용들이 꽤나 있었지만, 세밀하게 까지는 기억을 못하는 것 같다.
    CS지식도 나중에 좀더 보완할 필요가 있을 것 같다.
    2차 코딩테스트는 너무나도 새로웠다.
    여태까지 코딩테스트를 준비하며 입력값을 받아 문제에서 원하는 정답을 return하기 위해 코드를 작성하는 문제들을 풀었는데, 2차 코딩테스트는 실제로 서비스에 적용할 만한 로직을 코드로 구사해야했다.
    문제는 실제로 서비스에 적용할 만한 로직에 정답은 없다는 것 이다.
    물론 나는 API서버 교신에 3시간을 낭비해서 그런 로직에 대한 생각도 거의 못해봤다.
    내가 개발자가 되어 실제로 사람들이 이용할 서비스를 개발하면 그때는 항상 이러한 정답없는 문제를 맞닥뜨리게 될 것 같다.
    그때는 어떻게 최적의 방법을 찾을 수 있을까에 대해 조금은 고민해봐야 할 것 같다.

Section3도 열심히 진행하고 프로젝트도 잘 마무리해서 하루빨리 어엿한 주니어 개발자가 되고싶다.

0개의 댓글