개알못인 당신이 웹개발을 시작한다면 (2)
웹 개발 공부를 시작하시려는 분들께 도움이 되어보겠다는 무모한 주제로 연재를 시작했습니다. 전체적인 공감대는 어떨지 모르겠으나, 적어도 지인 몇몇 분께서 응원해주신바, 조금 더 무모한 진행을 계속해보겠습니다. 적어도 ‘나도 이런 거 써봐야지’하는 자극은 된 것 같습니다. 바람직한 일이죠. 너무 완벽하려 하지 말고 나름의 주관을 정리해서 공유하는 것이 꽤 중요한 것 같습니다. 우리가 자료 정리나 공유에 인색한 이유 중 하나도 지나친 완벽주의 때문이 아닐까 합니다.
1편: 프론트엔드와 백엔드 - https://goo.gl/7GLeQN
지난 편에는 연재의 전체 목표와 제공 가치를 말씀드렸고, 임의로 나눈 주제 중에 프론트엔드와 백엔드에서 공부해야 할 키워드를 말씀드렸지요. 요약하면,
- 프론트엔드: HTML5, CSS3, Javascript
- 백엔드: 루비나 파이썬 중에 마음에 드는 것 골라서 학습
이런 키워드를 두고 공부하시면 좋을 것 같다고 제안을 드렸습니다. 이 연재의 방향성에 도움이 되고자, 조금 미리 React나 Vue.js 같은 주제를 말씀드렸습니다만, 다시 강조하자면, 그런 주제를 시작하기에 앞서서 HTML5, CSS3, Javascript 기초를 먼저 닦아두는 편이 좋습니다. 흔히 우리는 무언가 공부해야 하는 주제가 쌓여있을 때, 조급한 마음에 기초를 건너뛰고 지금 당장 쓰이는 기술에 먼저 접근하려는 유혹에 빠지는데, 그래 봤자 다시 기초로 돌아와야 해서 오히려 더 느리게 나아가게 되기도 합니다. 유행하는 기술을 빨리 공부하고 싶은 조급한 마음은 잠시 가라앉히고, 기초부터 닦는 게 실질적 도움이 더 크기도 해요. 그리고, 어차피 React나 Vue.js 같은 것들은 2~3년이 지나면 또 언제 핫했냐는 듯 금세 유행이 가고 더 새로운 기술로 그 관심이 옮겨갑니다. 빠르게 변하는 분야는, 어제의 핫한 기술이 오늘의 폐품이 되는 주기가 굉장히 짧습니다.
아, 참 힘들게 배웠는데 이젠 아무도 관심도 없다.
그래서 기초를 잘 쌓으면서, 그 위에 유행하는 기술은 잘 익혀서 유통기한 내에 잘 써먹고 잊으면 됩니다. 핫한 기술들은 지식을 축적하는 게 아니라 소비하는 일이라고 보면 좋습니다. 잘 씹어 먹고 잘 소화해서 그 날의 에너지원으로 삼으면 됩니다. 굳이 그 지식들을 뼛속 깊이 쌓아둘 필요는 없어요. 너무 오래 쌓아두면 오히려 독소가 됩니다. 반면, 기초가 되는 기술들은 뼈로 만들기까지 시간이 좀 들고, 당장은 쓸모없어 보이기도 합니다만, 일단 뼈가 되고 나면 그 위에 지방을 쌓든 근육을 키우든, 중요한 버팀목이 되어줍니다. 뼈와 지방은, 어느 한쪽이 중요하고 다른 쪽이 덜 중요한 것이 아니라, 성격과 활용이 다른 것뿐이고 둘 다 중요하고 필요합니다. 다만 보통 초심자들이 겉에 잘 드러나는 지방과 근육에 쉽게 현혹되기 때문에, 이 연재에서는 균형을 맞추고자 뼈를 만드는 쪽을 좀 더 강조하는 입장을 취하도록 하겠습니다.
다시 말해 React나 Vue.js는 요새의 칼로리원이나 근육으로 삼으면 되고, HTML5, CSS3, Javascript로는 탄탄한 뼈를 만들면 됩니다. 뼈가 없으면 애써 근육을 만들어봐야 지지대가 없어서 힘을 쓸 수 없겠죠? 한편, 우리 몸의 뼈도 보통 6개월이 지나면 완전히 새로운 세포로 교체된다고 하더군요. 기초 기술이라고 해서 영원한 것은 아니고, 단지 지방이나 근육보다 조금 더 오래가는 것뿐이에요.
자, 그럼 이제 모호한 얘기는 이쯤에서 줄이고, 이어서 이번 편에는 “데이터베이스”와 “네트워크”에 대해 어디서부터 공부하면 좋을지 정리해볼게요.
데이터베이스 (Database)
드디어 우리 웹서비스의 데이터를 저장할 방법을 알아볼 때입니다. 보통 프론트엔드와 백엔드는 오가는 데이터를 처리하면서 일시적인 부분만을 잠깐씩 기억하면서 활용하며, 실제로 오래 보관할 내용은 데이터베이스에 기록합니다.
데이터베이스의 사전적 의미는 “잘 정돈한 데이터의 모음”입니다. 우리가 필요한 데이터를 잘 기록하면서, 필요한 때에 찾아보기 좋게 잘 정돈해 놓는 거지요. 흔히 약자로 DB라고 부르는데, 데이터 모음을 포함해서, 그 데이터 모음을 관리하는 시스템이나 소프트웨어를 뭉뚱그려 부르기도 합니다. (정확하게 말하자면, 후자는 DBMS라고 구분해서 말해야 하는데 그러지 않아도 널리 이해하는 분위기인 것 같습니다.)
DB도 종류가 여럿인데, 가장 널리 쓰이는 것은 RDB라고 관계형(Relational) 데이터베이스입니다. MySQL, PostgreSQL, Oracle 등이 RDB이지요. 대부분 RDB를 쓰기에 DB라고만 해도 RDB를 뜻하기도 합니다.
DB에 컬럼, 레코드, 테이블의 구조를 갖춰 데이터를 기록하는데, 이는 우리가 흔히 쓰는 스프레드시트 프로그램의 구조와 비슷합니다. 엑셀이나 구글시트의 시트가 DB의 테이블이고, 각 시트의 행이 레코드이며, 열이 컬럼입니다. 엑셀로 가계부를 정리할 때, 날짜/내역/금액/비고 등의 열을 두고, 각각의 행에 입출금 내역을 적어 놓는 것과 같습니다.
- 가계부(시트) => 테이블
- 날짜/내역/금액/비고(열) => 컬럼
- 입출금 내역(행) => 레코드
영수증을 어딘가에 잘 쌓아두기만 해도 될 텐데, 왜 굳이 엑셀에 힘들게 적어 놓나요? 기초 자료를 바탕으로 잔액이나 총 지출/수입 등을 자동으로 계산할 수 있고, 특정 날짜의 항목을 찾거나, 내역의 텍스트나 금액을 기준으로 검색해서 찾아보기 쉽기 때문 아닌가요? 기록으로 보관하려는 의도도 있고, 계산과 검색이 편한 구조로 남겨두는 목적도 있습니다.
엑셀 등에 담는 시트가 테이블인 셈인데, 관계형 데이터베이스는 그 안의 여러 테이블 사이에 관계를 다루는 연산들이 있습니다. 한 테이블만을 대상으로 해서 계산하거나 검색하는 범위를 넘어서, 두 테이블 이상을 합쳐서 무언가 계산하거나 검색하는 경우도 많습니다.
DB에 연산을 요청하는 내용을 쿼리(query)라고 부릅니다. 우리말로 ‘질의’라고 번역하거나 그냥 쿼리라고 부릅니다. 이 쿼리는 꽤 유연하고 강력한 기능들이 많이 필요하기에, 하나의 언어로 되어있습니다. 이 언어의 표준 격으로 SQL(Structured Query Language, 구조화된 질의 언어)이라는 것이 있고, 각 DB 제품마다 조금씩 다른 방언(dialect)을 씁니다. 서울말을 바탕으로 한 표준어가 있고, 각 지방에서 쓰이는 방언들이 조금씩 다르지만 대개는 의사소통이 되는 것 상황과 비슷합니다. MySQL에서 쓰는 쿼리와, PostgreSQL에서 쓰는 쿼리가 거의 비슷하면서도 세세한 부분이 조금씩 다릅니다.
휴, 여기까지만 해도, 웹 개발을 위해 자바스크립트, (루비 or 파이썬), SQL까지 세 개의 복잡해 보이는 언어를 배워야 하게 되었네요. HTML도 사실상 마크업 언어이기 때문에 그런 것까지 언어라고 말하면 금세 더 배워야 할 언어의 수가 늘어납니다. 하지만, 언어라고 해서 너무 겁먹을 필요는 없습니다. 영어나 중국어를 배우는 것처럼 어려운 일은 아닙니다. 문서도 잘 돼있고, 보통 좋은 언어들은 그 표현 자체가 단순하며, 무엇보다 쓰는 순간마다 도와주는 도구가 아주 잘 돼 있어서, 대충 얘기해도 철석같이 잘 알아들을 수 있는 표현으로 바꿔주며, 조금이라도 틀린 표현이 나오면 자동으로 알려줍니다. 내가 콩글리시로 대충 얘기해도 늘 따라다니는 미국인이 그 자리에서 정확한 표현으로 통역해주는 상황이랄까요? 다만, 너무 어긋나면 통역이 불가능하겠지만요.
아무튼, 이쯤에서 DB도 제품을 골라야 하겠습니다. 지금 상황에서는 MySQL이 가장 널리 쓰이는 것 같습니다. 책도 많이 나와있고요. 다만 저 개인적으로는 MySQL이 오라클에 인수됐기 때문에 능동적으로 발전해 나가야 할 이유가 줄어들었다고 생각합니다. 아마 그 흐름을 MariaDB가 이어받는게 아닌가 합니다만, 그냥 전 속 편하게 PostgreSQL을 쓰자는 입장이기에 잘 모르겠습니다. 안전한 선택을 하시려면 MySQL, 그 보다는 마이너하지만 제대로 된 선택을 하시려면 PostgreSQL을 택하시면 되겠습니다. 그렇다고 MySQL이 제대로 된 것이 아니라는 뜻은 아닙니다. 아 참 이거 조심스럽네요. 매번 말씀드리듯, 적지 않은 기술적 선택에 개인 취향이 많이 작용합니다. 정리하자면, MySQL이나 PostgreSQL 중에 고르면 됩니다. 이 역시 주변에서 Oracle이나 Microsoft SQL Server 등을 권하기도 할 겁니다. 고맙다 말하고 무시합니다. 마침 서울에 출장 온 김에 대형 서점에 들러서 둘러 보았더니, 역시나 오라클과 SQL Server 책이 많더군요. 아무래도 기업들이 많이 쓰는 제품이라 그런 것 같습니다. 우리는 기존 기업에 취직해서 DBA가 될 게 아니라, 내가 원하는 작은 웹서비스를 만들 것이므로 깔끔히 외면하도록 합니다. 그래도 MariaDB나 MySQL 책은 더러 있었는데, 아쉽게도 PostgreSQL책은 레퍼런스 사이트를 번역한 책 한 권 밖에 찾지 못했습니다. 그래서 PostgreSQL로 선택하신다면, SQL 기본 서적을 보면서 공식 웹사이트 매뉴얼을 참고하시는 방법이 좋을 것 같습니다.
한편, DB는 데이터를 보관한다는 측면에서 워낙 중요하고, 또 오랜 기간 중요하게 기능하며 발전해 왔기에, 이용하는 입장에서도 어렵지만, 그걸 관리하고 운영하는 입장은 훨씬 더 어려운 면이 있습니다. 데이터를 잘 남겨두고, 주기적으로 백업(별도 보관)하고 혹시라도 장애가 나면 복구해야 하며, 때로는 데이터를 다른 곳으로 옮겨야 하며, 새로 구축해야 할 때도 있습니다. 관리(Administration)의 측면만 봐도 큰 일이고 전문적이어서 그 직종이 따로 있고, 큰 회사들은 전담 팀과 부서가 따로 있는 경우가 많습니다. 그러나 역시 겁먹을 필요는 없습니다. 2층 집을 짓는 우리에게는 별도 인력을 확보할 여력이 없기도 하고, 다행히도, 앞으로 사용할 AWS 같은 환경에서는 그 관리의 행위와 역할이 클라우드 쪽으로 대폭 옮겨 가서, 개발자가 직접 해야 할 일이 훨씬 줄었습니다. 백업이나 복구 같은 일만 해도 꽤 어렵고 힘든 일인데, 요새는 AWS 콘솔에서 클릭 몇 번 하면 알아서 잘 해주지요. 아직 설명하지 않은 시스템 운영 측면에서도, 이 시대의 인프라 시스템이 너무 잘 돼 있어서, 사실 그 어느 때보다도 한 개인이 완전한 서비스를 만들어 내기 쉬운 환경이 됐습니다. 앞으로 더 쉬워지겠지요.
다시 데이터베이스의 이용 측면으로 돌아와서, 웹 개발자 입장에서는 우리가 고른 루비나 파이썬 백엔드 프로그램에서 데이터베이스에 접근해서 새 데이터를 기록하거나, 이미 기록한 데이터를 잘 조회해서 보여주는 일을 합니다. 그때 우리가 만드는 백엔드 소프트웨어(웹서비스)가 DB와 통신하기 위해 사용하는 언어가 SQL입니다. 백엔드가 직접 SQL을 거의 그대로 쓰는 경우는 요새는 별로 없고, 그 사이에 조금 더 편리한 계층이 있습니다. 루비온레일스의 경우에는 액티브레코드(ActiveRecord)라는 라이브러리가 그 일을 합니다. DB서버가 다루는 집합(set) 구조의 레코드와 컬럼을 객채지향 프로그램에서 다루기 좋은 형태로 변환하는 일을 하지요. 이 형태가 아직 통일된 것은 아니라, 각 언어별로 조금씩 다른 구조를 취하기도 합니다. 예를 들어 자바에서는 JPA라는 표준이 있어서 그런 일을 담당합니다. 루비온레일스의 액티브레코드 같은 경우는, 적어도 제가 써 본 것들 중에는 가장 우아하고 강력한 기능을 자랑했습니다. 아무래도 이질적인 무언가를 매개하는 일을 할 때는 보다 유연한 언어가 유리한 것 같습니다.
액티브레코드처럼 훌륭한 지원 도구가 있는 경우에는 SQL을 아주 기본적으로만 알아도 됩니다. 복잡한 구문들을 액티브레코드가 대신 처리해주니까 말이죠. 하지만, 그렇다고 SQL을 몰라도 된다는 뜻은 아닙니다. 복잡하고 번거로운 작업을 아주 편리하게 대신해주는 겁니다.
그래서 DB를 하나 골라서, SQL의 기초를 공부해가며 테이블과 관계를 다루는 법을 익히면서, 우리가 택한 언어에서 널리 쓰이는 DB 접근 레이어를 써서 유연하게 데이터를 다룰 수 있게끔 공부하면 되겠습니다.
- DO: MySQL or PostgreSQL
- DON’T: Oracle nor SQL Server
완전히 다른 얘기로, 데이터베이스라는 것이 결국, 우리가 만드는 웹서비스에 잘 정리하고 나중에 찾아볼 데이터를 잘 다룰 수 있으면 되는 겁니다. 그 형태가 꼭 관계형 DB일 필요는 없지요. 만약 그냥 디스크에 파일로 저장하거나 엘라스틱 서치 같은 검색 엔진에 부어 넣고도 내가 원하는 기능을 만들 수 있다면 그렇게 쓰면 됩니다. 그래서 RDB 말고도 MongoDB나 AWS의 DynamoDB를 비롯해서 다양한 형태의 데이터베이스가 널리 쓰이고 있습니다. 어쩌면 사람들이 너무 RDB에 치우쳐 있기에, 경우에 따라 다른 방식의 접근이 더 좋은 경우도 있다는 것을 잊게 되기도 하는 것 같습니다. 그리고 RDB를 쓴다고 해서 반드시 100% 모든 데이터를 RDB에 담아야 하는 것도 아닙니다. 대부분은 RDB에 담고, 경우에 따라서 다른 형태로 저장해도 되지요. 그러니 RDB를 공부한다고 해서, 세상의 데이터베이스가 RDB가 전부다라는 생각으로 굳어지지는 말아야 하겠습니다. 분명, RDB는 오랜 기간 발전하면서 매우 성숙한 제품과 기술들이 함께 진보했기 때문에 가장 안전한 선택입니다만 말이죠.
한 가지 더, 한 귀로 흘려들으실 여담으로, 제가 만약 RDB 외에 선택 다른(?) DB를 쓴다면 Datomic이라는 제품을 쓰겠습니다. 아직 널리 알려지지 않았고, 상용 제품이기에 접근성이 떨어집니다만, 불변(immutable) 데이터베이스라는 점이 아주 매력적으로 보입니다. 아직은 좀 기다려 봐야죠. 발상과 접근이 너무 좋아서, 곧 비슷한 접근 방식을 취하는 오픈소스 제품이 나와서 함께 발전하지 않을까 생각하고 있습니다. 그리고 조금 더 용기가 난다면, 돈을 내고라도 써 볼 만한 제품이라고 눈독 들이고 있습니다. 유료라고 해서, 오라클 같은 대기업용 제품처럼 막대한 비용이 필요한 건 아니니까요. 아니면, AWS위에서 과금제로 쓰는 만큼 돈을 내는 Datomic이 출시될 수도 있으니, 그걸 써도 괜찮지 않을까 합니다.
괜한 딴 얘기를 했네요. 우선 RDB 하나 골라서 공부하며 씁시다! RDB의 단점으로 지적되는 부분들이, 적어도 우리가 목표로 하는 동네 웹서비스 영역에서는 문제점으로 드러날 일은 없다고 생각해요. 나중에 AWS를 언급하면서 RDS 서비스를 말씀 드릴 텐데, MySQL, PostgreSQL 다 편하게 쓸 수 있으니, 고르시기만 하면 됩니다. 거 참 좋은 세상!
요약: MySQL이나 PostgreSQL을 고르고, SQL을 공부해 가며, 내가 택한 언어의 DB 접근 라이브러리를 써서 연습한다.
네트워크 (network)
네트워크야 익숙하시죠? 우리 어디 가서 WiFi 안되면 공황상태에 빠지잖아요? 너무 익숙해서 모른다고 말하기 민망할 지경이죠. 우리 장비들이 서로 통신하는 망을 네트워크라고 합니다. 오래전에는 다른 네트워크 방식이 많았지만, (지금도 은행같은 금융권이야 다른 망을 많이 쓰겠지만) 요새야 네트워크라고 하면 인터넷을 의미하는 거죠. 간단하게만 얘기하자면, 우리가 쓰는 컴퓨터와 저 멀리 있는 백엔드 서버와 통신하는 연결선이라고 생각하면 어떨까 합니다.
어떤 장비가 네트워크에 연결되면, 고유의 주소를 할당받습니다. IP라고 줄여 부르는 이 주소가 인터넷에서의 주소입니다. Internet Protocol 주소의 약자인데, 인터넷에서 쓰는 주소라고 생각하시면 되겠습니다. 모든 장비에 이 IP주소가 있어야 서로 통신이 됩니다. 내가 편지를 어디론가 보내려면, 받는 사람 주소가 있어야 하는 것처럼 당연한 일입니다. 생긴 모습은,
104.74.171.196이렇게 네 뭉치 숫자가 마침표로 이어진 모양으로 생겼습니다. 각 숫자가 1바이트라서 최대 255까지 표현합니다. 숫자상으로는 0.0.0.0부터 255.255.255.255까지 표현할 수 있습니다만, 중간중간 영역이 특별한 용도로 제외되기 때문에 모든 숫자를 다 쓰는 것은 아닙니다. 이렇게 4바이트로 인터넷 주소를 쓰는 것을 IPv4(Internet Protocol version 4) 주소라고 합니다. 특별한 목적으로 제외된 영역을 빼고 단순하게 계산해도 4바이트로는 2^32인 42억 개 정도까지 쓸 수 있습니다. 이 주소를 IANA라는 단체에서 영역으로 떼어서 전세계 인터넷 서비스 제공업체에 할당해 주는데, 2011년 3월에 동이 났다고 하는군요. 실제로 전세계에서 42억 개 정도를 다 쓰는 것은 아니겠지만, 과잉 할당된 곳도 있을 테고, 또 워낙 세상에 장비들이 많으니 그럴 만도 합니다.
그래서 IPv6(Internet Protocol version 6) 주소를 쓰게 됩니다. IPv6에서는 16바이트로 인터넷 세상의 주소를 표현합니다. 16바이트로 표현하면 2¹²⁸ 개의 주소를 표현할 수 있으므로, 적어도 우리가 살아있는 동안에 부족할 일은 없어 보입니다.
이렇게 생겼다는데, 거 참 생소하네요.
요새야 거의 모든 장비와 서비스가 IPv4와 IPv6를 함께 지원하지만, 적어도 국내 환경에서는 그다지 호응이 없어 보입니다. 정확한 이유야 모르겠지만, 아마도 우리나라에 할당된 IPv4 주소 영역이 매우 넉넉하기 때문이 아닐까요? 부족하지 않으니 아쉬울 것이 없어서 우물을 팔 필요가 없는 거지요. 그래서 아직은 IPv4 만 알아도 되겠습니다만, 좀 익숙해지고 나서 IPv6도 신경 쓰면 좋겠지요.
IPv4건 IPv6건, 이 주소로 원하는 목적지에 요청을 보내야 하는데, 보시다시피 이 주소는 우리가 일일이 외우기는 어렵습니다. 네이버나 구글에 접속해서 검색을 해봐야 하는데, 저런 숫자로 접근해서 봐야 한다면 참 골치 아픈 일이 아니겠습니까?
그래서 전화번호부 역할을 해주는 서비스가 있습니다. 114 전화해서 “네이버” 얘기하면 “네이버” 전화번호를 알려주는 것처럼요. 그럼 우리는 여러 서비스의 전화번호를 외우지 않아도 됩니다. “114”라는 전화번호 하나만 외우고 있으면 되지요. 그런 전화번호부 역할을 해주는 것이 DNS입니다. 도메인 이름 시스템(Domain Name System)이라고, 우리가 읽을 수 있는 문자로 표현합니다.
www.naver.com이렇게요. 저 이름이 사실은 104.74.171.196를 대신하는 주소명인 겁니다. 저 주소명을 IP주소로 알아내는 작업을 “DNS 조회(look up)”라고 합니다. 114에 전화 걸어서 상표명 묻는 행위인 거죠. 난 114를 입력한 적이 없는데 어떻게 그런 일을 하냐고요? 우리 장비가 인터넷에 연결되면, 우리 장비에 임시 IP주소를 할당해 주면서 DNS 서버 주소도 함께 줍니다. 그 114 역할을 하는 IP주소를 우리 컴퓨터나 스마트폰의 장비가 잘 기억하고, 그때그때 물어봐가며 IP 주소를 가져와서 원하는 목적지에 연결해 주는 작업을 합니다.
IP주소도 유한한 자원입니다만, 저 도메인명도 희소한 유한 자원이기에, 돈을 주고 삽니다. 1년에 돈 만원 정도 내면 해당 이름을 내가 원하는 IP주소에 연결하는 일을 해둘 수 있습니다. 자기 블로그 자기 도메인 명으로 운영하는 사람들 있죠? 그 도메인을 도메인 등록 서비스 업체에서 산 거에요. 우리도 돈 만원쯤 내서 사면 우리 백엔드 서버들에 할당된 IP주소로 쉽게 접근할 수 있도록 전화번호부(DNS)에 등재해 둘 수 있습니다.
DNS를 거쳐서 알아내든, 직접 외우고 있었든 이제 IP주소를 알았습니다. 그다음 포트에 대해서 알아볼게요. IP주소는 보통 한 장비를 의미하고, 한 장비 내에서도 포트(port)라는 것이 여러 개 있습니다. 포트는 2바이트로 0~65535 사이의 숫자를 씁니다. 0번과 49152번 이후의 숫자를 특별한 용도로 제외하고 그 사이의 숫자로 약 5만 개의 포트를 쓸 수 있습니다.
포트는, 반드시 그런 것은 아닙니다만, 각 통신 목적에 맞는 포트 번호 관례가 있습니다. 예를 들어 우리 웹브라우저로 접근하는 웹서비스의 경우 80번 포트를 써요. 암호화된 통신의 경우는 443번 포트를 쓰고요. 웹서비스 통신에 오고 가는 데이터 규약을 HTTP라고 부르는데, 이걸 암호화하지 않고 주고 받는 경우는 80번 포트로 접근하고, 암호화해서 주고 받는 경우에는 443번 포트에 접근합니다.
즉, 브라우저에서 아래 주소를 치는 것은
http://www.naver.com/사실상
http://www.naver.com:80/과 동일합니다. 저런 주소 전체를 URL이라고 부르는데, 앞에 http가 프로토콜이고 www.naver.com이 도메인 명이며 80이 포트번호입니다. 암호화한 데이터를 주고받는 https의 경우는,
https://www.naver.com/으로 접근하고, 이는 사실상
https://www.naver.com:443/으로 접근한 것과 같습니다. 이 글을 쓰는 현재 http로 네이버에 접근하면, 자동으로 암호화된 https로 다시 연결하게 처리해주네요. 무조건 암호화된 통신을 하겠다는 얘기입니다.
우리가 웹서비스를 만들면 우선 80 포트 기준으로 백엔드 서비스를 띄워놓고 개발하다가, 나중에 도메인도 사고, 친구들에게 공개하기 전에는 폼나게 443번 포트에 암호화된 웹서비스를 올려두도록 합시다. 여기에는 TLS 인증서를 발급받아서 올려놓아야 하는데, 요새는 무료로 제공하는 서비스도 있기에 아주 어려운 일은 아닙니다. 혹시 연재가 길어진다면 그 부분도 적도록 할게요.
네트워크도, 조금 살펴보니 의외로 재밌지 않나요? 더 관심이 가신다면 네트워크 관련 서적을 더 살펴보시면 제 어설픈 설명보다 훨씬 잘 정리된 내용을 보시기 좋을 거예요.
그다음으로, 네트워크 기초를 보고 나면, 웹브라우저와 우리가 만들 백엔드 서버가 HTML, CSS, Javascript 파일 등을 주고받을 때 쓰는 프로토콜인 HTTP에 대해서도 살펴보도록 합시다. HTTP는 현재는 버전 1.1이 널리 쓰이고 있고, 2.0도 거의 모든 웹브라우저가 지원하며, 2017년 5월 기준, 상위 1천만 개의 웹사이트 중 13.7%가 지원하고 있다고 나와있으나, 체감상 아직 널리 쓰이는 것 같지는 않습니다. 이 점도, 아쉬운 사람이 우물을 파야 하는데, 구글이나 네이버 같은 대형 서비스 제공업체에서나 엄청난 망 비용을 절약하고 싶어서 아쉬운 거지, 소규모 서비스 제공자나 소비자 입장에서야 그다지 아쉬운 상황이 아니라서 말이죠. 그래도 언젠가는 2.0이 널리 쓰이겠지요. 아마도 IPv6가 안착할 때쯤? ㅎㅎ
그런 날이 오긴 하는 건가?
이상 네트워크는, 제가 쉽게 설명하기에는 좀 무리가 있는 카테고리였음을 인정합니다. 솔직히, 뭐라고 요약해야 할지도 잘 모르겠네요.
요약: 인터넷 네트워크 기초 서적을 한 권 살펴보고, HTTP/1.1 프로토콜의 기초를 파악한다.
마무리
이상, 웹 개발을 시작하는 분들을 위한 연재 2편을 마무리하겠습니다. 다음 편에는 각종 개발 도구에 대한 이야기를 늘어놓아보겠습니다. 긴 글 읽어주셔서 감사합니다. 마음에 드신다면 주변에 공유해주시고, 틀린 내용 있으면 편하게 지적해주시고, 전혀 다른 생각이 있어서 불편하다면, 마음에 드는 글을 찾거나, 직접 작성해서 공유해주세요. 다음 편에 만나요~
3편 읽으러 가기
1편: 프론트엔드와 백엔드 — https://goo.gl/7GLeQN
2편: 데이터베이스와 네트워크 — https://goo.gl/d16511
3편: 기본 개발 도구 — https://goo.gl/wWgqyw
4편: 기초 자료 구조 — https://goo.gl/ch4paX
5편(끝): 리눅스, 도커, AWS — https://goo.gl/KTd8WP
