[O'REILLY] Node & Express - 21장 : 사이트 오픈 (완)

이번 포스팅은 사실 DevOps의 영역과 밀접한 관계가 있다.

단순한 서버의 비즈니스로직 개발을 넘어서 지속적이고 자동화된 솔루션을 구축하는 것에 대한 문화에 대한 기본적인 지식을 포함하고 있다.

 

1. 도메인 등록과 호스팅

- 인터넷의 모든 웹사이트/서비스는 인터넷 프로토콜(IP) 주소로 식별한다.

- 도메인이름은 google.com 과 같은 사람이 이해하기 쉬운 주소이름을 숫자로된 IP 주소로 연결한다.

- 호스팅은 웹사이트를 실행하는 컴퓨터를 가리킨다.

- 도메인 등록업체는 대부분 호스팅 서비스를 제공하거나, 호스팅 업체와 파트너십을 맺고 있다.

- 도메인이름과 IP주소를 연결하는 것은 DNS(Domain Name System)이다.

 

2. 보안

- 도메인 이름에는 가치가 있다.

- 도메인을 탈취당할 경우 문제가 커진다.

- 도메인 보안에는 심혈을 기울여야한다.

- 추천하는 도메인 업체는 AWS 라우트 53, Name.com 

- 보안 시스템의 강도는 그 구성원 중 가장 약한 고리를 따른다. 이메일 또한 예외가 없다.

 

3. 최상위 도메인

- .com / .net 처럼 마지막에 있는 것을 최상위도메인(TLD, Top Level Domain) 이라고 한다.

- 일반적으로 국가코드 TLD와 일반 TLD 두가지로 나뉜다.

- .com 이나 .net 의 취득에는 제한이 없지만 나머지는 제한이 존재할 수 있다.

- .com 도메인이 부족해짐에 따라, 다른 TLD를 사용하거나 .com.us 같은 우회수단을 사용하기도 한다.

 

4. 서브도메인

- TLD 앞에 도메인이 있고, 그 앞에 서브도메인이 있다.

- 가장 널리 쓰이는 서브도메인은 www이다.

- 핵심도메인에는 서브도메인을 쓰지 않길 권한다.

- 리디렉트가 가능하므로, www를 사용하는 고객을 잃지 않을 수 있다.

- 서브도메인은 다른 용도로 사용한다. api.이것.com 혹은 blogs.블로그.com 등

- 보통 이런 구분은 기술적이유이지만, 좋은 프록시를 사용한다면 서브도메인이나 경로 어느쪽이든 기준을 삼아 트래픽을 

리디렉트할 수 있으므로, 콘텐츠의성격에 따라야 한다. URL은 기술적 구조가 아니라 정보의 구조를 표현해야 한다.

- 따로 명시하지 않으면 도메인 등록 업체는 서브도메인을 구분하지 않고 모든 트래픽을 서버로 리디렉트한다.

- 서브도메인에 따라 적절히 반응하는 것은 나의 서버 혹은 프록시서버에서 할 일이다.

 

5. 네임 서버

- 도메인 동작을 위해서는 네임서버가 필요하며, 호스팅을 계약할 때 네임서버를 제출해야한다.

- 보통은 호스팅 서비스에서 다 해주므로 하라는 일만 잘 하면 된다.

- 호스트의 네임서버를 거치지 않고 도메인과 웹사이트를 직접 연결하려면 A 레코드나 CNAME을 사용하면 된다.

- CNAME 레코드는 조금 경직된 편이므로 A레코드를 선호한다. 근데 꼭 필요하지는 않다.

 

6. 호스팅

- 클라우드 호스팅 써라. 그냥 AWS 써라. Azure 도 쳐준다. 다른 선택지로는 Naver, Google Cloud 등이 있다. 근데 취업이나 이직하려면 결국 AWS 쓴다

 1) Sass : 서비스로서의 소프트웨어, 그냥 쓰면 되는 서비스(구글문서, 드롭박스 등)

 2) PaaS : 서비스로서의 플랫폼, 인프라 구조(운영체제, 네트워크) 전체를 제공한다는 의미이다. 그저 앱만 만들면 된다. 일반적으로 개발자들은 이걸 찾게 된다.

 3) IaaS : 서비스로서의 기반 구조, 유연하지만 할 일이 많다. 가상 머신과 기본네트워크만 제공된다. 직접 운영체제, DB, 네트워크 정책 등을 설치하고 관리해야 한다. PaaS 도 운영체제와 네트워크를 설정할 수 있으므로, 특별한 경우가 아니면 PaaS다.

 4) Faas : 서비스로서의 함수, AWS 람다, 구글 함수, 애저함수 처럼 런타임 환경을 설정할 필요 없이 클라우드에 있는 기능을 실행하기만 되는 환경이다. 요새 대세인 서버리스(Serverless)구조가 요기다.

 

7. 배포

- 지속적 배포(Continuous Delivery) 서비스를 추천한다.

- 처리과정을 자동화할 수록 개발이 편리해진다. 

- 코드를 수정하면, 자동으로 단위테스트와 통합테스트를 통과했다는 알림을 받고, 바꾼 내용이 온라인에 반영되는 것을 순식간에 확인할 수 있다면, 유지/보수가 훨씬 쉬워지고 자원이 아껴질 것이다. 다만, 이런 과정을 위한 준비에 시간을 많이 투자해야하고 꾸준한 유지/보수도 포함된다.

- AWS 코드 파이프라인 : 배워두자

- 젠킨스 : 배워두자

- 트래비스CI, 서클CI, Azure웹앱(Azure사용 시), 구글클라우드빌드(구글사용 시) 등이 있다.

 

 

이렇게 '오라일리 - WebDevelopment with Node & Express' 400쪽에 달하는 책을 읽고 정리를 해보았다.

복습이 되는 경우도 있었고, 이제는 사용하지 않는 사장된 구린 기술들도 있었고, 새로운 지식도 있었다.

실제로 모든 세세한 부분들을 글로 적어서 포스팅에 남길 수는 없었다. 그냥 내가 모르거나, 중요하다고 느끼는 부분만 적어놨을 뿐이다.

이제 강의만 듣는 공부법 그만하고 사이드프로젝트 위주로 스터디를 계속 진행해야 할텐데, 스터디 팀원들이 아직 프론트개발에 익숙하지 않은데다가, 기획/디자인을 내가 해야해서 현재 두번째 페이지의 메인비즈니스로직만 개발해놓고 리팩토링만 진행 중이다.

 

요새 유튜브를 보다보니 결국 한국에서는 스프링이나 하라는 얘기들이 너무 많은데.. 나는 스프링보다 유연하고 자유롭고 편하고 빠르게 개발할 수 있는 Node-Express 서버가 좋다. 결국 이직에는 Nest나 스프링같은 정형화된 아키텍쳐위주의 기술스택들이 사용되긴 할거다.. 그걸 감안해서.. 또 공부해야지 뭐.. 하나를 아는 것보다 여러개 아는 게 도움이 되지 않을까?

혹자는 하나를 깊게 파고 장인이 되어야 돈을 잘 벌 수 있다는데, 나는 욕심이 많은건지 '많고 다양한 걸 깊게 파면 고민 해결이잖아?' 의 입장이다. 현실적이라고는 못하지만, 실제로 위대로운 개발자들은 다양하고 여러가지 기술을 학습했고, 자주 사용하지도 않는 특수한 기술을 달달외우는 것보다는 현실에서 많이 사용하는 부분들을 파고들었다.

 

위대한 개발자가 되지는 못할지언정, 내 서비스를 오픈하고 사람들에게 공개하고, 그 서비스를 사용해서 사람들의 삶에 도움이 될 수 있다면 너무 행복할 것 같다.

굉장히 좋은 책