최근 도움을 드리고 있는 분이 계신데 이분도 받아들이기 힘들어하시고,

저역시도 오랜기간 한 2년넘게 받아 들이기 힘들어서 선듯 손이가지 못했던 부분이 있습니다.

 

제목에서와 같은 배포 패러다임 입니다.

 

그누보드는 PHP 를 기반으로 하다보니, 

스크립트만 올리면 바로 서버에서 실행이 됩니다.

 

이런 종류의 언어가

html, css, javascript, php, ... 젤친한순으로.. 보면 이렇습니다.

 

그리고

react나 vue, 그리고 svelte 는 javascript 입니다.

 

그럼 배포는 서버에 올리면 알아서 실행되어야 할 것들이겠죠!

 

그런데 반은 맞고 반은 아닙니다.

빌드 및 실행 방식에 따라서

서버사이드렌더링인지 프론트랜더링인지에 따라서 달라집니다.

 

아 어렵다..

 

react 나 vue 는 js 파일을 html 페이지에 링크 걸어주는 것으로

라이브러리가 로드 되어 그안에서 바로 사용할 수 있습니다.

아쉬운데로 이런 방식으로 페이지 별로 별도로 로딩해서 바인딩이나 뭐 이런 기능들을 간간히 사용할 수 있습니다.

 

그런데 next.js 나 nest.js 와 같이 라우팅을 걸어주는 프로그램은 전체 라우팅을 구현하면서

html 페이지에 주입하는 방식이 아닌 오히려 js 묶음에 html 을 넣는 방식을 사용합니다.

 

node 를 이용해서 서버사이드랜더링이 되는 웹서버를 만들어 낸 것입니다.

이쯤되면 격이 달라집니다.

이건 단순 실행 스크립트 수준이 아니라 프로그램 수준으로 구동이 되는 것입니다.

 

요 차이를 잘 기억해주셔야합니다.

 

php 를 서버사이드 언어로 분류 됩니다.

서버측 언어다, 서버에서 프로그램 실행되어서 동적 결과를 뱉어 낸다.

DB도 접속하고.. 거기에서 나온 결과를 if나 for문을 돌려가면서 현란한 결과물을 만들어 냅니다.
 

react 의 next.js,vue의 nest.js, svelte의 sveltekit이 이러한 일을 합니다.

그래서 우리는 php 로 페이지나 스킨 개발 할 때 해깔렸던, 

php에서 변수만들면 그게 js에서 받아 쓸 수 있지만 반대로

js에서 변수 만들면 이것을 php에서 못받아 쓰니까 뭐 이러 제한적 규칙들을 익히고

처리하는 방법을 별도로 공부해오고 구현해 왔습니다.

 

svelte도 이렇게 서버쪽 부분과, 프론트쪽 부분을 두루 영향미치는 코드들이 있습니다.

이를 잘 구분해서 개발을 해야합니다. 간혹 window 객체가 없다고 에러가 뜨는데

서버쪽에서는 window 객체가 없어 해당 구분이 실행될때 에러가 뜨게 되는 것입니다.

 

이경우 해당 구분앞에 brows && 붙여주면 에러를 회피할 수 있습니다.

브라우저 상태일때 만 실행하라고 분기 시켜준 것입니다.

 

아무튼

 javascript 가 프론트에서나 사용되는 언어인줄 알았는데,

이놈이 node.js 를 만나면서 서버사이드 언어가가 되버린 것입니다.

 

그러면서 챙겨야 할 게 많아지게 됩니다.

php는 나름 대단한게  스크립트만 올려주고 접속 형태로 실행만하면 만사오게이 입니다.

지금까지 우리는 배포에 큰 공을 들이지 않았습니다.

ftp연결해서 서버에서 직접 개발했습니다.

 

코드 변경 -> 저장 -> ftp업로드-> 웹페이지 확인

요 페턴을 반복하면 됐습니다.

저장+ftp업로드도 합쳐서 그야말로 로컬에서 개발하듯이 2스텝으로 쉽게 개발해오고 있습니다.

저장->확인, 저장->확인, 저장->확인

 

고객도 주소만 알여주면, 실시간으로 변경사항 바로 보고 안심시킬 수 있었습니다.

 

그런데,

앞으로는 위방식은  아주 급작스러운 비상상황에나 하는 일이 될 것입니다.

 

이제는 이렇게 해야 합니다. 적어도 node 개발 할때는 말입니다.

 

로컬 개발 pc 에서

git 생성 -> git 연결 -> 로컬 개발환경 구성 -> 개발 -> 저장 -> 로컬서버 브라우저확인 -> 빌드 -> git 커밋(올리기)

 

배포 서버에서

git clone -> git pull (내려받기) -> 빌드 -> 웹에서 확인

 

참 길어졌습니다.

 

변경된 환경의 장점을 설명하면

1. 개발 환경과 배포 환경이 분리되어 있습니다.

 - java 개발에서는 진작부터 사용해오던 방식이죠.

 - 개발자가 실운영 서비스에 바로 접속해서 작업을 하지 않습니다. 절대 해서는 안될 일지죠. 그런데 여태 우리는 해왔죠?

 - 개발자 서버에서 다양한 시도와 개발이 가능하게 됩니다. 그리고 최종 승인된 안정화 버전을 실서버에 배포합니다.

2. git을 경유하기 때문에 형상관리가 강제되어 코드 덮어 쓰기 문제 그리고 코드의 히스토리 및 개발 이슈 등의 관리가 해결됩니다.

3. 하나의 코드로 서버를 여러대 운영할시 자동 배포에 최적화 됩니다.

  서버가 여러대면 바뀐 파일을 같이 수정해줘야하는데, 설정을 잘 해두면, 한번 코드 변경으로

  서비스 중단없이 여러대 동시 자동배포가 가능해집니다.

 

오! 나름 장점이 많습니다.

 

단점

개발 및 배포가 너무 길어졌습니다.

- 고객의 요청사항을 반영하기 까지 시간이 걸려서 고객이 싫어라 합니다.

git 사용 방법을 숙지해야합니다.

 

node 도 스크립트만 올려서 바로 실행하는 방식이라면

전통적인 방식인 ftp를 이용할 수도 있습니다.

 

그런데, 이놈은 나름 프로그램이라서

내용을 서버에 올리고

npm install 

npm run build

node ./build/index.js 또는 pm2 restart ./build/index.js

이런 명령어를 실행해서 node 서버를 실행 시켜줘야 합니다.

 

너무 길조 이래서 개발 하겠습니까?

 

그래서 git 의 장점도 살리고 스크립트도 실행하고, 실행 성공여부 등도 관리하는 차원에서

여러 서비스와 대안이 존재합니다.

 

git또는 git과 연동해서 운영되는 여러 자동 배포 서비스가 있습니다.

그리고 클라우드 업체 Saas 업체들이 저마다 배포를 단순화 해서 쉽게 배포할 수 있게만들어 놓고

호객 행위를 하고 있습니다. 복잡한 부분인데, 이걸 단순화 해서 클라우드 이용자를 유치하겠다는 전략입니다.

 

코딩 -> 저장 -> 빌드 -> 확인 -> git commit -> [알아서 자동 앱포]

 

 

github , gitlab에 자체 자동 배포 서비스들이 존재합니다.

 

그리고 자동 배포로 유명한 jenkins 등 여러 자동 배포 서비스 들을 이용할 수도 있습니다.

 

이부분은 제가 공부 중이어서 적당히 쉬운 버전을 찾고 있는데, 아직 탐색중이어서

성공후 성공 후기를 따로 올려드리겠습니다.

 

배포가 쉬워야 할 맛이 날텐데, 말이죠.