개발을 잘 모르는데 서버부터 만들기 (7)
문과생 유목이의 개발일지 · 7화
NAS에 예약 시스템을 올리기로 했다. 목마른 자가 우물을 판다고 그랬나? 다시 퇴근하고 매일 3시간씩 독학을 시작했다. 그래도 세상이 좋아지고 숨어있는 고수들이 많아서 그런지 인터넷에서 여기 저기 검색을 해봤더니 여러 힌트가 나왔다.
Node.js, Express, PostgreSQL, Docker, API, 포트, 컨테이너, 리버스 프록시.
…… 이상한 단어 나열의 연속이였다. 하나도 몰랐다. 정확히는 지나가면서 봤는데 무엇이고 뭘 하는지 설명할 수 없었다. 경영학과를 나와서 사내 PC 고쳐주고 사는 나에게 기본 지식이란건 존재하지 않았다.
식당으로 바꿔서 이해했다
누군가 이걸 식당에 비유해서 적은 글을 보게 되었다. 그리고 지금 내 예약 사이트를 거기에 대입해서 정리하기 시작했다.
예약 웹페이지는 메뉴판이다. 손님이 보고 고르는 화면. 직원이 브라우저에서 보는 게 이거다.
API 서버(Node.js + Express) 는 주방이다. "대회의실 화요일 2시"라는 주문을 받아서, 가능한지 확인하고, 결과를 돌려준다. 손님은 주방에 직접 들어가지 않는다. 주문서만 주고받는다.
데이터베이스(PostgreSQL) 는 창고다. 예약 기록이 전부 여기 쌓인다. 주방은 요리를 할 뿐이고, 재료는 창고에 있다.
Docker는 주방을 통째로 담아둔 컨테이너다. 가스레인지, 칼, 냄비를 하나하나 설치하는 대신, 필요한 게 전부 들어 있는 주방 세트를 통째로 NAS에 올려놓는 것이다.
이 비유가 정확한지는 지금도 모르겠다. 다만 이렇게 보니 무엇부터 만들어야 하는지는 알 것 같았다.
전체 구조
정리하면 이렇다.
직원 브라우저
→ 예약 웹페이지
→ API 서버
→ 데이터베이스
요청은 왼쪽에서 오른쪽으로 가고, 결과는 오른쪽에서 왼쪽으로 돌아온다. 그게 전부다.
Google Sheet 방식과 비교하면 차이가 분명해졌다. Sheet에서는 이 네 칸이 전부 뭉쳐 있었다. 화면도 Sheet, 계산도 Sheet, 저장도 Sheet였다. 그래서 하나만 느려져도 전체가 느려졌고, 화면을 바꾸고 싶어도 저장 구조까지 건드려야 했다.
나눠놓으면 각각 따로 손볼 수 있다. 이걸 이해한 게 이 프로젝트에서 가장 큰 전환점이었다고 생각한다.
제일 오래 헷갈린 것
프론트와 백엔드의 경계가 제일 어려웠다. 눈에 보이는 화면과, 뒤에서 계산하는 부분이 왜 따로 있어야 하는지 한참 감이 안 왔다.
이해한 계기는 보안이었다. "이 시간에 예약 가능한가"를 브라우저에서 판단하면, 사용자가 화면을 조작해서 불가능한 예약도 통과시킬 수 있다. 그래서 진짜 판단은 반드시 서버가 해야 한다. 화면은 보여주기만 하는 역할이다.
포트 개념도 한참 걸렸다. NAS라는 집에 문이 여러 개 있고, 각각의 문마다 번호가 붙어 있다고 생각하니 겨우 이해가 됐다. 5000번 문으로 들어오면 DSM, 3000번 문으로 들어오면 예약 시스템. 너무 디테일한 설명을 여기서 기대히진 말아줘라. 내 지식의 범위로 최대한 쉽게 얘기하는 중이다.
공부는 퇴근 후에 했다. 모르는 단어는 커뮤니티에 물어보고, 답을 받으면 그 답에 또 모르는 단어가 있어서 다시 물어보는 식이었다. 댓글에 대댓글에 대대댓글이 계속 달렸다. 하루 세 시간씩, 이 주쯤 지나니 적어도 찾은 자료들이 무슨 뜻인지는 이해하기 시작했다.
이제 진짜로 시작해볼 차례였다.
다음 편 — Docker로 예약 서버 올리기 (8)
※ 이 연재에 등장하는 ㈜세움과 모든 인물은 가상이다. 기술적인 구성과 시행착오는 실제 구축 경험을 바탕으로 재구성했다.
댓글
댓글 쓰기