프로그래밍 개념 정리

주소창에 URL을 입력하면 무슨 일이 일어날까?

초링초링 — Mon, 20 Apr 2026 15:35:03 +0900

우리는 매일 브라우저 주소창에 주소를 입력합니다.

예를 들어 이런 주소를 입력한다고 해보겠습니다.

https://www.example.com

그리고 엔터를 누르면 잠시 뒤 화면에 웹페이지가 나타납니다.

사용자 입장에서는 아주 단순합니다.

주소를 입력한다.
엔터를 누른다.
화면이 뜬다.

하지만 개발자의 관점에서 보면 이 짧은 순간에 꽤 많은 일이 일어납니다.

브라우저는 주소를 해석하고, 서버의 위치를 찾고, 서버와 연결하고, 요청을 보내고, 응답을 받은 뒤, HTML/CSS/JavaScript를 해석해서 화면을 그립니다.

이번 글에서는 주소창에 URL을 입력했을 때 어떤 일이 일어나는지 큰 흐름부터 차근차근 정리해보겠습니다.

전체 흐름

먼저 전체 과정을 아주 단순하게 표현하면 다음과 같습니다.

사용자
  ↓
브라우저 주소창에 URL 입력
  ↓
브라우저가 URL 해석
  ↓
DNS로 서버 IP 주소 찾기
  ↓
서버와 연결
  ↓
HTTP 요청 전송
  ↓
서버가 요청 처리
  ↓
HTTP 응답 수신
  ↓
HTML, CSS, JavaScript 해석
  ↓
화면 렌더링

조금 길어 보이지만 핵심은 단순합니다.

브라우저는 사용자를 대신해서 서버에 "이 페이지 주세요"라고 요청하고, 서버는 "여기 있습니다"라고 응답합니다. 그 응답을 브라우저가 해석해서 우리가 보는 화면으로 만들어주는 것입니다.

URL이란?

주소창에 입력하는 https://www.example.com 같은 값을 URL이라고 부릅니다.

URL은 Uniform Resource Locator의 줄임말입니다. 쉽게 말하면 인터넷에 있는 자원의 주소입니다.

여기서 자원은 HTML 페이지일 수도 있고, 이미지일 수도 있고, CSS 파일이나 JavaScript 파일일 수도 있습니다.

예를 들어 아래 URL을 보겠습니다.

https://www.example.com/products?id=123

대략 이렇게 나눠볼 수 있습니다.

https://        → 어떤 방식으로 통신할 것인가
www.example.com → 어느 서버에 요청할 것인가
/products       → 서버의 어떤 경로를 요청할 것인가
?id=123         → 요청에 함께 보낼 추가 정보

브라우저는 사용자가 입력한 문자열을 그냥 통째로 서버에 보내지 않습니다. 먼저 URL을 분석해서 어떤 프로토콜을 사용할지, 어떤 도메인으로 접근해야 하는지, 어떤 경로를 요청해야 하는지 파악합니다.

여기서 https는 HTTPS라는 방식으로 통신하겠다는 뜻입니다. HTTPS는 HTTP 통신을 암호화해서 중간에서 내용을 쉽게 훔쳐보거나 변조하지 못하게 해주는 방식입니다.

브라우저는 먼저 주소를 해석한다

브라우저 주소창은 생각보다 똑똑합니다.

우리가 주소창에 devlov.tistory.com이라고 입력하면 브라우저는 이것을 웹사이트 주소로 보고 접속을 시도합니다. 반대로 웹개발이란이라고 입력하면 검색어로 판단해서 기본 검색 엔진으로 검색합니다.

브라우저는 입력값을 보고 대략 이런 판단을 합니다.

이건 검색어인가?
이건 URL인가?
프로토콜이 생략되어 있나?
도메인은 무엇인가?
경로는 무엇인가?

최근 브라우저에서는 https://를 직접 입력하지 않아도 자동으로 HTTPS 접속을 먼저 시도하는 경우가 많습니다.

즉, 사용자는 example.com만 입력했지만 브라우저는 내부적으로 https://example.com처럼 해석해서 접속을 시도할 수 있습니다.

DNS: 도메인을 IP 주소로 바꾸기

URL에서 가장 중요한 부분 중 하나는 도메인입니다.

www.example.com

사람은 이런 문자 주소를 읽기 편합니다. 하지만 컴퓨터끼리 통신할 때는 보통 IP 주소가 필요합니다.

예를 들어 어떤 서버는 이런 IP 주소를 가질 수 있습니다.

93.184.216.34

사람이 매번 이런 숫자를 외우기는 어렵습니다. 그래서 www.example.com 같은 도메인을 사용합니다.

DNS는 Domain Name System의 줄임말입니다. 쉽게 말하면 도메인 이름을 IP 주소로 바꿔주는 시스템입니다.

비유하자면 전화번호부와 비슷합니다.

사람이 기억하기 쉬운 이름: www.example.com
실제 연락처: 93.184.216.34

브라우저는 서버에 요청을 보내기 전에 먼저 이 도메인이 어떤 IP 주소를 가리키는지 알아내야 합니다.

DNS 조회는 대략 이런 식으로 진행됩니다.

브라우저: www.example.com의 IP 주소가 뭐지?
DNS: 이 도메인은 93.184.216.34를 가리켜.
브라우저: 이제 이 IP 주소로 접속해야겠다.

실제로는 브라우저, 운영체제, 공유기, 통신사 DNS 서버, 권한 있는 DNS 서버 등 여러 단계가 관여할 수 있습니다. 하지만 입문 단계에서는 "DNS는 도메인을 IP 주소로 바꿔준다" 정도로 이해해도 충분합니다.

서버와 연결하기

브라우저가 서버의 IP 주소를 알게 되면 이제 서버와 연결을 시도합니다.

웹에서 전통적으로 많이 쓰이는 연결은 TCP 연결입니다. TCP는 데이터를 안정적으로 주고받기 위한 통신 방식입니다.

HTTPS를 사용한다면 TCP 연결 이후에 TLS라는 암호화 과정도 진행됩니다.

흐름을 단순화하면 다음과 같습니다.

브라우저
  ↓
서버 IP 주소로 TCP 연결 시도
  ↓
HTTPS라면 TLS 암호화 연결 설정
  ↓
HTTP 요청을 보낼 준비 완료

여기서 헷갈릴 수 있는 부분이 있습니다.

HTTP와 TCP는 같은 것이 아닙니다.

TCP는 데이터를 안정적으로 전달하기 위한 아래쪽 통신 방식에 가깝고, HTTP는 웹에서 클라이언트와 서버가 요청과 응답을 주고받기 위한 약속입니다.

비유하자면 TCP는 택배 운송 시스템이고, HTTP는 택배 상자 안에 들어 있는 주문서 양식에 가깝습니다.

다만 최근에는 HTTP/3처럼 TCP 대신 QUIC이라는 방식을 사용하는 경우도 있습니다. 하지만 처음 웹의 흐름을 이해할 때는 "브라우저가 서버와 연결한 뒤 HTTP 요청을 보낸다"는 큰 흐름을 먼저 잡는 것이 좋습니다.

HTTP 요청 보내기

서버와 연결되면 브라우저는 HTTP 요청을 보냅니다.

HTTP 요청은 브라우저가 서버에게 보내는 메시지입니다.

예를 들면 이런 의미입니다.

서버야, / 경로에 해당하는 페이지를 보내줘.
나는 HTML을 이해할 수 있어.
나는 이런 브라우저를 사용하고 있어.
쿠키도 같이 보낼게.

실제 HTTP 요청은 대략 이런 형태를 가질 수 있습니다.

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

여기서 GET은 HTTP 메서드입니다.

GET은 서버에서 데이터를 가져올 때 주로 사용합니다. 주소창에 URL을 입력해서 페이지를 여는 것은 대부분 GET 요청입니다.

다른 대표적인 메서드로는 POST가 있습니다. POST는 로그인, 회원가입, 글 작성처럼 서버에 데이터를 보내야 하는 상황에서 자주 사용합니다.

즉, 브라우저가 서버에 보내는 요청은 그냥 "접속합니다"가 아니라 꽤 구체적인 메시지입니다.

어떤 방식으로 요청할지
어떤 경로를 요청할지
어떤 도메인에 대한 요청인지
브라우저가 어떤 데이터를 받을 수 있는지
쿠키나 인증 정보가 있는지

이런 정보들이 HTTP 요청에 담깁니다.

서버는 요청을 처리한다

브라우저의 요청을 받은 서버는 이제 요청을 처리합니다.

서버가 하는 일은 서비스마다 다릅니다.

단순한 정적 웹사이트라면 서버는 이미 만들어져 있는 HTML 파일을 그대로 돌려줄 수 있습니다.

요청: /
응답: index.html 파일

반대로 로그인한 사용자의 마이페이지처럼 사용자마다 다른 화면을 보여줘야 한다면 서버는 더 많은 일을 해야 합니다.

예를 들어 이런 과정이 있을 수 있습니다.

1. 요청에 포함된 쿠키를 확인한다.
2. 이 사용자가 로그인한 사용자인지 확인한다.
3. 데이터베이스에서 사용자 정보를 가져온다.
4. 필요한 데이터를 조합한다.
5. HTML 또는 JSON 응답을 만든다.
6. 브라우저에 응답을 보낸다.

이때 백엔드 개발자가 작성한 코드가 실행됩니다.

Node.js, Java Spring, Ruby on Rails, Django, NestJS 같은 서버 기술들은 결국 이런 요청을 받아서 응답을 만들어내기 위해 사용됩니다.

서버 개발을 아주 단순하게 말하면 다음과 같습니다.

요청을 받는다.
필요한 일을 한다.
응답을 보낸다.

물론 실제 서비스에서는 인증, 권한, 데이터베이스, 캐시, 외부 API, 로그, 에러 처리, 보안 등 훨씬 많은 요소가 들어갑니다. 하지만 출발점은 항상 요청과 응답입니다.

HTTP 응답 받기

서버가 요청을 처리하면 브라우저에 HTTP 응답을 보냅니다.

HTTP 응답은 서버가 브라우저에게 보내는 메시지입니다.

예를 들면 이런 의미입니다.

요청한 페이지를 찾았어.
상태는 성공이야.
응답 내용은 HTML이야.
아래 내용을 화면에 그리면 돼.

실제 응답은 대략 이런 형태를 가질 수 있습니다.

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<!doctype html>
<html>
  <head>
    <title>Example</title>
  </head>
  <body>
    <h1>Hello Web</h1>
  </body>
</html>

여기서 200 OK는 상태 코드입니다.

상태 코드는 요청이 어떻게 처리되었는지 알려줍니다.

대표적인 상태 코드는 다음과 같습니다.

200: 성공
301, 302: 다른 주소로 이동
400: 잘못된 요청
401: 인증 필요
403: 접근 권한 없음
404: 찾을 수 없음
500: 서버 내부 오류

우리가 흔히 보는 "404 Not Found"는 브라우저가 요청한 자원을 서버에서 찾지 못했다는 뜻입니다.

반대로 "500 Internal Server Error"는 서버 안에서 문제가 발생했다는 뜻입니다. 이 경우에는 프론트엔드 코드 문제가 아니라 백엔드 코드, 서버 설정, 데이터베이스 연결 등 서버 쪽 문제일 가능성이 큽니다.

브라우저는 HTML을 읽기 시작한다

브라우저가 서버로부터 HTML 응답을 받으면 이제 화면을 만들기 시작합니다.

HTML은 웹페이지의 구조를 표현합니다.

예를 들어 이런 HTML이 있다고 해보겠습니다.

<!doctype html>
<html>
  <head>
    <title>나의 웹페이지</title>
    <link rel="stylesheet" href="/style.css">
  </head>
  <body>
    <h1>안녕하세요</h1>
    <script src="/main.js"></script>
  </body>
</html>

브라우저는 HTML을 위에서 아래로 읽어가며 문서 구조를 파악합니다.

이 과정에서 DOM이라는 구조를 만듭니다.

DOM은 Document Object Model의 줄임말입니다. 쉽게 말하면 HTML 문서를 브라우저가 다루기 쉬운 객체 구조로 바꾼 것입니다.

HTML이 글로 적힌 문서라면, DOM은 그 문서를 브라우저가 이해하고 조작할 수 있게 만든 나무 구조입니다.

html
 ├─ head
 │   ├─ title
 │   └─ link
 └─ body
     ├─ h1
     └─ script

JavaScript에서 document.querySelector() 같은 코드를 사용할 수 있는 이유도 브라우저가 HTML을 DOM으로 만들어두기 때문입니다.

CSS 파일을 다시 요청한다

HTML 안에는 CSS 파일을 불러오는 코드가 있을 수 있습니다.

<link rel="stylesheet" href="/style.css">

브라우저는 이 코드를 발견하면 다시 서버에 요청을 보냅니다.

/style.css 파일을 주세요.

그러면 서버는 CSS 파일을 응답으로 보내줍니다.

CSS는 화면의 모양을 결정합니다.

h1 {
  color: red;
  font-size: 32px;
}

브라우저는 CSS를 해석해서 CSSOM이라는 구조를 만듭니다.

CSSOM은 CSS Object Model의 줄임말입니다. DOM이 문서의 구조라면, CSSOM은 각 요소에 어떤 스타일을 적용해야 하는지에 대한 정보입니다.

브라우저는 DOM과 CSSOM을 조합해서 실제로 화면에 보여줄 요소와 스타일을 계산합니다.

JavaScript 파일도 다시 요청한다

HTML 안에는 JavaScript 파일을 불러오는 코드도 있을 수 있습니다.

<script src="/main.js"></script>

브라우저는 이 코드를 만나면 /main.js 파일도 서버에 요청합니다.

JavaScript는 HTML과 CSS를 조작하거나, 사용자 이벤트를 처리하거나, 서버에 추가 데이터를 요청하는 데 사용됩니다.

예를 들어 버튼을 클릭했을 때 화면의 문구를 바꾸는 일은 JavaScript가 할 수 있습니다.

document.querySelector("h1").textContent = "반갑습니다";

여기서 중요한 점은 브라우저가 처음 받은 HTML 하나만으로 모든 화면을 완성하는 경우는 많지 않다는 것입니다.

대부분의 웹페이지는 HTML을 받은 뒤 CSS, JavaScript, 이미지, 폰트 같은 자원을 추가로 요청합니다.

그래서 실제 흐름은 이렇게 됩니다.

1. HTML 요청
2. HTML 응답
3. HTML 안에서 CSS, JS, 이미지 주소 발견
4. CSS, JS, 이미지 추가 요청
5. 각 파일 응답
6. 화면 구성

웹페이지 하나를 여는 것처럼 보이지만, 내부적으로는 여러 번의 요청과 응답이 오가는 것입니다.

브라우저가 화면을 그리는 과정

브라우저가 화면을 그리는 과정을 렌더링이라고 부릅니다.

단순화하면 다음과 같은 흐름입니다.

HTML 파싱
  ↓
DOM 생성
  ↓
CSS 파싱
  ↓
CSSOM 생성
  ↓
DOM + CSSOM 조합
  ↓
Render Tree 생성
  ↓
Layout
  ↓
Paint

각 단계를 조금 더 쉽게 설명해보겠습니다.

DOM 생성

브라우저가 HTML을 읽고 문서 구조를 만듭니다.

이 페이지에는 제목이 있고, 문단이 있고, 버튼이 있구나.

CSSOM 생성

브라우저가 CSS를 읽고 스타일 정보를 만듭니다.

제목은 빨간색이고, 글자 크기는 32px이구나.

Render Tree 생성

브라우저가 DOM과 CSSOM을 합쳐서 실제로 화면에 보여줄 요소 목록을 만듭니다.

여기서 display: none처럼 화면에 보이지 않는 요소는 렌더 트리에서 제외될 수 있습니다.

Layout

각 요소가 화면의 어디에, 어떤 크기로 배치될지 계산합니다.

제목은 위에서 20px 떨어진 곳에 놓고,
너비는 화면 전체를 사용하고,
버튼은 그 아래에 배치하자.

Paint

계산이 끝나면 실제 픽셀로 화면에 그립니다.

우리가 보는 웹페이지는 이 과정을 거쳐 나타납니다.

개발자 도구로 직접 확인하기

이 흐름은 브라우저 개발자 도구에서 직접 확인할 수 있습니다.

Chrome 기준으로는 다음 순서로 볼 수 있습니다.

1. 웹페이지를 연다.
2. F12 또는 우클릭 → 검사를 누른다.
3. Network 탭을 연다.
4. 새로고침한다.

그러면 브라우저가 서버에 보낸 요청 목록이 보입니다.

여기서 확인할 수 있는 것들이 있습니다.

문서 요청: HTML
스타일 요청: CSS
스크립트 요청: JavaScript
이미지 요청: PNG, JPG, WebP
폰트 요청: WOFF, WOFF2
API 요청: JSON

각 요청을 클릭하면 더 자세한 정보도 볼 수 있습니다.

Headers: 요청/응답 헤더
Preview: 응답 미리보기
Response: 실제 응답 내용
Timing: 요청에 걸린 시간

처음에는 복잡해 보이지만, Network 탭을 보면 "웹페이지 하나를 열 때 정말 많은 요청이 발생하는구나"라는 것을 바로 느낄 수 있습니다.

웹개발을 공부할 때 개발자 도구의 Network 탭은 아주 중요합니다. 화면에 문제가 생겼을 때 이 요청이 성공했는지, 서버가 어떤 응답을 보냈는지, 상태 코드는 무엇인지 확인할 수 있기 때문입니다.

예시로 다시 정리하기

사용자가 주소창에 아래 주소를 입력했다고 해보겠습니다.

https://www.example.com/products

브라우저와 서버 사이에서는 대략 이런 일이 일어납니다.

사용자: 주소창에 URL 입력

브라우저: 이 주소는 HTTPS를 사용하는구나.
브라우저: 도메인은 www.example.com이구나.
브라우저: DNS에게 IP 주소를 물어봐야겠다.

DNS: www.example.com의 IP는 93.184.216.34야.

브라우저: 이제 이 IP의 서버와 연결해야겠다.
브라우저: HTTPS니까 암호화 연결도 준비해야겠다.

브라우저 → 서버:
GET /products HTTP 요청

서버: /products 페이지 요청이 들어왔네.
서버: 필요한 데이터를 준비해야겠다.
서버: HTML을 만들어서 응답해야겠다.

서버 → 브라우저:
200 OK
HTML 응답

브라우저: HTML을 읽어야겠다.
브라우저: CSS 파일이 필요하네. 다시 요청하자.
브라우저: JavaScript 파일도 필요하네. 다시 요청하자.
브라우저: 이미지도 필요하네. 다시 요청하자.

브라우저: DOM과 CSSOM을 만들고 화면을 그리자.

사용자: 웹페이지가 보인다.

사용자 눈에는 "주소 입력 후 페이지 표시"로 보이지만, 내부적으로는 이런 여러 단계가 지나갑니다.

프론트엔드와 백엔드는 어디에 있을까?

이 흐름을 알면 프론트엔드와 백엔드의 역할도 조금 더 명확해집니다.

프론트엔드는 브라우저에서 실행되는 화면과 상호작용을 담당합니다.

HTML
CSS
JavaScript
React, Vue 같은 프론트엔드 라이브러리
브라우저에서 보이는 화면
사용자 클릭, 입력, 스크롤 처리

백엔드는 서버에서 요청을 처리하고 응답을 만듭니다.

HTTP 요청 처리
로그인 확인
데이터베이스 조회
비즈니스 로직 실행
HTML 또는 JSON 응답 생성
서버 로그와 에러 처리

프론트엔드와 백엔드는 완전히 따로 노는 것이 아닙니다. 브라우저가 서버에 요청을 보내고, 서버가 응답을 보내는 HTTP 흐름 위에서 서로 연결됩니다.

그래서 웹개발을 이해하려면 HTML, CSS, JavaScript만 아는 것도 부족하고, 서버만 아는 것도 부족합니다. 최소한 "브라우저가 서버에 요청하고 서버가 응답한다"는 흐름은 함께 이해해야 합니다.

왜 이 흐름을 알아야 할까?

처음 개발을 공부할 때는 React, Spring, Next.js, NestJS 같은 기술 이름이 먼저 눈에 들어옵니다.

하지만 이런 기술들은 모두 웹의 기본 흐름 위에서 동작합니다.

React로 만든 화면도 결국 브라우저에서 HTML, CSS, JavaScript로 동작합니다.

Spring이나 NestJS로 만든 서버도 결국 브라우저나 다른 클라이언트로부터 HTTP 요청을 받고 HTTP 응답을 보냅니다.

AWS, Nginx, Docker 같은 기술을 배우더라도 결국 사용자의 요청이 어떤 서버로 전달되고, 서버가 어떤 응답을 돌려주는지 이해해야 합니다.

이 흐름을 알고 있으면 문제가 생겼을 때 어디를 봐야 할지 감이 생깁니다.

예를 들어 화면이 안 뜬다고 해보겠습니다.

그때 확인할 수 있는 질문들이 생깁니다.

URL을 잘못 입력한 것은 아닐까?
DNS가 제대로 연결되어 있을까?
서버에 연결은 되고 있을까?
HTTPS 인증서 문제는 아닐까?
HTTP 상태 코드가 404인가, 500인가?
HTML은 받았는데 CSS가 깨진 것은 아닐까?
JavaScript 에러 때문에 화면이 멈춘 것은 아닐까?
API 요청이 실패한 것은 아닐까?

이 질문들을 던질 수 있게 되는 것만으로도 디버깅 실력이 크게 달라집니다.

마무리

주소창에 URL을 입력하면 브라우저는 단순히 "사이트를 연다"가 아니라 여러 단계를 거쳐 웹페이지를 화면에 보여줍니다.

핵심 흐름은 다음과 같습니다.

URL 입력
→ URL 해석
→ DNS 조회
→ 서버 연결
→ HTTP 요청
→ 서버 처리
→ HTTP 응답
→ HTML/CSS/JavaScript 해석
→ 브라우저 렌더링

웹개발은 이 흐름을 계속 확장해 나가는 과정이라고 생각해도 좋습니다.

프론트엔드 개발자는 브라우저 안에서 더 좋은 사용자 경험을 만들고, 백엔드 개발자는 서버에서 더 안정적이고 정확한 응답을 만들고, 인프라 영역은 이 요청과 응답이 안정적으로 오갈 수 있도록 도와줍니다.

처음에는 모든 용어가 낯설 수 있습니다. 하지만 "브라우저가 요청하고 서버가 응답한다"는 큰 그림을 먼저 잡으면, 이후에 HTTP, API, 쿠키, 세션, CORS, 배포, 캐시 같은 개념들도 훨씬 쉽게 연결됩니다.

참고 자료

MDN Web Docs, URL: https://developer.mozilla.org/en-US/docs/Glossary/URL
MDN Web Docs, HTTP overview: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
MDN Web Docs, Critical rendering path: https://developer.mozilla.org/ko/docs/Web/Performance/Guides/Critical_rendering_path

그림과 작동 원리로 쉽게 이해하는 서버의 기초

초링초링 — Fri, 5 Jan 2024 19:51:58 +0900

서버란

테니스 탁구 배구 따위에서 서브하는 쪽. 또는 그 사람

음식, 음료를 내는 데 쓰는 도구

주된 정보의 제공이나 작업을 수행하는 컴퓨터 시스템

→ 웹브라우저가 클라이언트, 검색 서비스를 제공하는 업체의 컴퓨터가 서버

클라이언트/서버 시스템

서버의 처리는 클라이언트의 요청에서 시작한다
1. 클라이언트로부터 요청(request)을 받아서 처음으로 처리를 시작하고, 서비스를 제공(응답, response)합니다.
웹서비스에 대입해 보자
1. ‘클라이언트/서버 시스템’ : 서버와 클라이언트로 구성된 시스템. 서버/클라이언트 시스템은 서버에서 데이터를 일원적으로 보다 쉽게 관리할 수 있어 대부분의 컴퓨터 시스템에 채용하고 있습니다.

다양한 서버

서버의 역할은 서비스에 따라 결정된다.
1. 그렇다면 서비스란? 여러분 자신이 인터넷에서 전달하는 정보의 모든 것이 서비스 그 자체입니다. 카카오톡, 트위터 모두 ‘서비스’ 입니다.
수많은 서버 수많은 서비스
1. 웹서버(HTTP 서버), 메일 서버(SMTP/POP 서버)
2. 명칭만 다를 뿐 본질적으로는 같음.

서버 소프트웨어

서버 소프트웨어를 설치하고 실행시키기만 하면 된다.

다양한 서버 소프트웨어
1. 서버 소프트웨어는 서비스를 제공하기 위한 기능을 가진 소프트웨
여러 서버를 1 대의 컴퓨터에 모은다
1. ex) Apache, IIS, nginx

구축할 서버의 종류와 서버 소프트웨어 선정

어떤 서버를 준비하는가?
1. → 사용자와 시스템의 목소리에 귀 기울인다
2. ex) 메일을 송신하고 싶다. 이 때는 메일 서버가 필요함.
어떤 서버 소프트웨어를 설치할 것인가?
1. 일반적으로 사용하는 것들이 정해져 있음.
2. ex) 웹서버 - 아파치, 엔진엑스 IIS, DNS서버 - BIND, Unbound, Windows Server
요구되는 기능, 구입/운용 관리 비용 등 요소를 비교하여 결정

서버 운용 기간

운용 관리 단계는 시스템의 수명에서 가장 긴 단계, 서비스가 종료할 때까지 계속 이어진다.

설정 변경
1. 사용자의 요구에 맞춰 서버 설정을 변경해 간다.
장애 대응
1. 사전 대응 : 이상한 에러 로그가 기록될 때 인식되도록 해 둔다.
2. 사후 대응

서버와 네트워크

본래 네트워크란
1. 네트워크는 무언가와 무언가의 연결 전반을 의미
컴퓨터 네트워크란
1. LAN이란 : Local Area Network - 일정 범위에 존재하는 컴퓨터를 연결한 네트워크
2. ex) LAN > LAN 스위치 > 라우터 > 방화벽 > 인터넷 > 다른 라우터

그림과 작동 원리로 쉽게 이해하는 서버의 기초 1장 내용입니다.

HTML, CSS, Javascript란 무엇일까?

초링초링 — Fri, 27 Oct 2023 00:03:32 +0900

웹(Web)이란?

월드와이드웹(World Wide Web)의 줄임말이다. 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 말한다. 구체적으로는 인터넷 상의 정보를 하이퍼텍스트 방식과 멀티미디어 환경에서 검색할 수 있게 해주는 정보검색 시스템이다. 하이퍼텍스트는 웹 브라우저라고 불리는 프로그램을 통해 웹서버에서 문서나 웹 페이지 등의 정보 조각을 읽어들여 컴퓨터 모니터에 출력하는 형태로 보이게 된다. 월드 와이드 웹에 관련된 기술은 월드 와이드 웹 컨소시엄(W3C)이 개발하고 있다. 출처 - 위키백과

Chrome, Firefox, Safari, Edge Logo

개발자가 웹이라는 단어를 사용할 때 웹은 주로 ‘브라우저’ 에서 일어나는 기술의 일련을 뜻한다. 반대되는 개념은 아니지만 비슷한 개념으로는 ‘앱’ 이 있다. 앱은 주로 모바일에서 사용되며 웹 브라우저 앱 이외에 모바일 환경에서 실행되는 프로그램을 지칭한다.

HTML 이란?

하이퍼텍스트 마크업 언어(HyperText Markup Language)의 줄임말이다. 웹 브라우저 상에서 정보를 나타내기 위해서 만들어진 언어이다. 웹 컨텐츠의 내용의 구조를 정의한다. 주로 위치, 색깔, 크기 등을 꾸미는 CSS(Cascading Style Sheets)와 Javascript와 함께 사용된다. 웹 브라우저는 웹서버에서 HTML 문서를 전달받거나 내 로컬 스토리지에서 전달받고 문서 내용을 그려낸다.

HTML의 역사

HTML 최초의 일반 공개 설명은 1991년 말에 버너스리가 처음으로 인터넷에서 문서를 "HTML 태그"(HTML tag)로 부르면서 시작되었다. 하이퍼링크를 제외한 HTML 태그들은 CERN 자체의 SGML 기반 문서화 포맷인 SGML GUID에 강하게 영향을 받았다. 이 요소 중 13개는 HTML 4 버전에서도 여전히 존재한다. SGML은 문서용 마크업 언어를 정의하기 위한 메타 언어이다. IBM에서 1960년대에 개발한 GML(Generalized Markup Language)의 후속이며, ISO 표준이다. 가장 최근에는 2008년 1월 HTML 5 초안 작업은 W3C에 의해 발표되었다.

출처 - 위키백과

HTML의 사용

HTML 요소의 가장 보편적인 형태는 다음과 같다.

<tag attribute1="value1" attribute2="value2">보이는 내용</tag>

간단한 HTML 문서는 다음과 같이 생겼다.

<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
</head>
<body>

<h1>My First Heading</h1>
<p>My first paragraph.</p>

</body>
</html>

CSS 란

CSS(Cascading Style Sheets) 의 줄임말이다. CSS는 문서가 사용자에게 어떻게 보여질 지 정의하는 언어이다. 예를 들어 위치가 어디일지, 색깔은 어떤 색일지, 진하게 굵게 등등이다. 주로 HTML과 함께 사용되며 SVG 혹은 XML과도 함께 사용할 수 있다. CSS는 규칙 기반 언어로, 특정한 요소에 정의될 규칙을 설정하고 그 요소들에게 적용될 스타일을 작성하면 웹브라우저에서 그려지는 형태다. - 출처 : MDN

CSS는 문서 내용과 표시 형식을 분리하기 위해서 고안되었다. 이런 분리는 문서의 접근성을 증가시킨다. 또, 여러 문서에 CSS 포맷을 함께 적용시킬 수 있는 장점도 있다. 또한 이 CSS 파일을 캐싱해서 로딩 부담을 줄일 수도 있다. - 출처 : 위키백과

CSS의 사용

h1 {
  color: red;
  font-size: 5em;
}

다음은 h1이라는 태그의 글자색을 빨간색으로 하고 글자 크기는 5em이라고 설정하는 CSS이다.

스타일시트(Style sheet)

스타일 시트는 여러 규칙의 목록들이다. 각각의 규칙은 1개 이상의 선택자와 선언 블록(Declaration block)으로 구성된다.

선택자(Selector)

어느 부분의 마크업에 스타일을 적용할 지 선언하는 부분이다. 태그명과 클래스, ID로 선택할 수 있다. 클래스는 여러 개의 요소에 적용할 수 있고 ID는 하나의 요소에만 적용할 수 있다.

선언 블록

선언 블록은 괄호로 이루어진 선언들의 목록으로 이루어진다. 선언은 “프로퍼티: 값” 이렇게 구성된다.

Javascript

자바스크립트는 객체 기반의 스크립트 프로그래밍 언어다. 자바스크립트는 웹브라우저 내에서 주로 사용되며 Node.js와 같은 런타임 환경과 같이 서버 프로그래밍에서 사용된다. Javascript는 처음에는 Mocha, 나중에는 LiveScript 라는 이름으로 개발되었다. 하지만 Java가 유행할 때 유행을 타기 위해 Javascript라고 이름을 붙였다는 설이 있다. 두 언어는 사용되는 환경과 목적이 매우 다르다 !! (개발자가 아닌 분들이 제일 많이 물어보시는 질문)

지금 프론트엔드 개발에서 가장 많이 사용하는 라이브러리 react, vue가 javascript 기반 라이브러리이고 node.js 환경에서 express.js 등의 서버 프로그램도 작성할 수 있다. (잘만 사용하면 당신도 풀스택 개발자 ) 여전히 빠른 속도로 발전하고 있으며 최근에는 three.js 처럼 3D 렌더링도 가능한 라이브러리도 만들어지고 있다.

Javascript의 사용

<!DOCTYPE HTML>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html" charset="UTF-8" />
    <title>자바스크립트 페이지</title>
<link rel="stylesheet" href="chrome://resources/css/text_defaults_md.css">
    **<script type="text/javascript">
      document.write("<p>Hello World!</p>");
    </script>**
  </head>
  <body>
    <noscript>
      <p>브라우저가 자바스크립트 기능을 지원하지 않거나 자바스크립트 기능이 꺼져 있습니다.</p>
    </noscript>
  </body>
</html>

위 코드에서 <script> </script>로 감싸진 부분 이 javascript 코드이다. javascript 코드를 당장 실행하고 싶다면 웹브라우저 - 개발자 도구 - 콘솔 창에서 코드를 입력하면 바로 실행할 수 있다. 위 코드를 메모장에 저장해서 index.html 과 같이 html 포맷 파일로 저장하면 브라우저로 바로 열어볼 수 있다.

위 사진에서 콘솔에서 console.log 함수를 실행한 것을 확인할 수 있다.

HTML, CSS, Javascript

HTML, CSS, Javascript는 웹의 구성요소로 현재까지 브라우저에 문서를 표시하기 위한 형식으로 사용되고 있다. 거꾸로 우리가 브라우저를 통해 보는 모든 정보는 HTML, CSS, Javascript로 이루어져 있다고 생각하면 된다. 아무리 다른 언어로 웹페이지를 만들었다고 하더라도, 결국에 사용자가 보게 되는 것은 HTML, CSS, Javascript 뿐이다. 그래서 웹 프론트엔드 개발은 HTML, CSS, Javacript를 만들어내는 일이라고 해도 부족한 말은 아니다. 단지, 해당 요소들을 현대적으로 빠르게 개발하기 위한 여러 기술들이 개발되었을 뿐이다. 처음 개발을 배우게 되면 실제로 존재하는 HTML을 잊어버린 채 react로 만들어진 요소, 결과만 생각할 수 있는데 react도 결국에는 HTML, CSS를 잘 조작하기 위한 방법 중 하나다.

끝으로 웹의 요소들을 정말 잘 활용해서 매번 볼 때마다 감탄을 자아내는 애플 신제품 상세페이지 링크를 첨부한다. (이 글은 애플의 광고를 받고 작성된 글이 아닙니다 )

웹개발, 웹개발자란 무엇일까? 프론트엔드, 백엔드 개발자란?

초링초링 — Sat, 21 Oct 2023 00:25:46 +0900

웹 개발자, 서버 개발자, 프론트엔드 개발자, 백엔드 개발자 등등 개발자를 지칭하는 단어들을 많이 본 적이 있을 것이다. 처음 개발을 시작했을 때는 사실 내가 어떤 개발자라고 부르는 지도 정확히 몰랐다. 그도 그럴 것이 처음에는 언어는 루비로 루비온레일즈 프레임워크를 사용해 사용자가 사용하는 화면부터 서버 로직까지 모두 다 개발하는 역할이었기 때문이다. 지금부터 내가 느낀 웹개발이란 무엇인지, 프론트엔드, 백엔드가 무엇인지 설명해 보도록 한다. 경험에 의거한 것이기에 다른 사람의 견해와는 차이가 있을 수 있으니 이런 의견도 있구나 하고 생각하셔도 좋다.

서버, 클라이언트란?

서버란 쉽게 생각하면 내가 요청하는 값을 돌려주는 컴퓨터라고 생각하면 된다. 영어로는 server이고 실제로 영어에서 레스토랑에서 음식을 가져오는 사람을 server라고 한다. 클라이언트는 직역하면 고객이다. 레스토랑에서 음식을 주문하는 사람이라고 생각해도 크게 무리는 없다. 가장 대표적인 클라이언트는 웹브라우저라고 생각하면 된다. 웹브라우저는 Chrome, Safari, Firefox 최근에는 웨일, Arc 브라우저 등등이 있다. 그 외에 클라이언트는 윈도우 혹은 맥에서 실행되는 응용프로그램일수도 있고 키오스크 단말기가 될 수도 있다. 여기서 기기(사용자의 컴퓨터, 휴대폰, 키오스크 등)와 프로그램 - 브라우저 - 가 혼용해서 쓰였는데 나는 실제로 혼용해서 써왔기 때문에 구체적인 정의보다는 내가 이해하고 있는 개념으로 설명한다.

웹개발이란?

웹개발이란 브라우저 상에서 동작하는 '웹'이 동작하기 위해 필요한 모든 기술 분야를 의미한다. 지금은 영역이 점점 흐려지고 있지만, 가장 유명한 웹서비스인 구글, 페이스북, 아마존 그리고 한국에서는 네이버, 다음은 전부 브라우저상에서 동작하는 웹에서 시작했다. 특히 과거에는 프론트엔드와 백엔드 구분이 지금만큼 명확하지 않았기 때문에 웹개발자로 뭉뚱그려서 불렀던 관행도 있었던 것 같다.

매우 대략적으로 설명한 웹개발의 변천사

위 그림을 보면 이해할 수 있는데, 서버에서 모든 정보를 다 처리하는 방법이 대세였던 시기가 있었고 이 경우, 개발자가 서버에서 데이터를 처리하는 기술과 화면에 보여지는 기술 모두 어느정도는 알고있어야 했다. 하지만 클라이언트 성능, chrome 브라우저와 node.js의 발전으로 프론트엔드 프레임워크가 엄청난 속도로 성장하면서 웹브라우저 안에서만 동작하는 기술을 익히는 것 만으로도 전문성이 필요해졌다. 그래서 실제로 채용도 웹 프론트엔드 개발자를 따로 채용하기도 한다.

그래서 서버-클라이언트, 프론트엔드-백엔드 개발자의 차이가 뭐야?

대응되는 두 개념을 엄밀하게 정의하는 것은 역시 위키를 참조하는 편이 좋겠다. 하지만 그 뒤에 ~개발자가 붙어서 실제 사용되는 언어 속에 녹아드는 순간 사전적 의미와 완전히 대응되지는 않는다는 생각이 든다. 내가 느끼기에 서버, 클라이언트 개발자라는 단어는 상대적으로 앱 개발 혹은 게임 개발 쪽에서 많이 쓴다. 왜냐하면 아까 정의한 것처럼 클라이언트는 브라우저 뿐만이 아니라 사용자의 휴대폰, PC 어플리케이션 등등을 통칭하고 있기 때문이다. 그리고 프론트엔드, 백엔드와 같은 경우는 앞에 (웹) 프론트엔드, (웹) 백엔드 같이 앞에 (웹)이 생략되어 있는 느낌이다. 프론트엔드라는 단어 자체가 사용자가 마주하는 모든 인터페이스를 말하고 백엔드는 글자 처럼 사용자 뒤에서 사용자에게 보이지 않는 모든 기술을 통칭한다. 실제로 일도 이렇게 하는데, 사용자가 화면상에서 마주하는 모든 일은 프론트엔드 개발자의 영역이고, 백엔드 개발자의 경우 단순히 서버 뿐만 아니라 서버가 작동하기 위해 필요한 데이터베이스, 클라우드, 배포시스템 같은 영역도 수행해주기를 기대하기 때문이다.

만약 웹개발 예를 들어 javascript 언어로 react 프레임워크로 만들어진 프로젝트를 담당하고 있다면 웹 프론트엔드 개발자다. java/kotlin 언어로 android 앱을 개발 하고 있다면 android 개발자다. 여기서 문제는 최근 기술의 발전으로 인해 하이브리드 앱을 개발하는 개발자도 많다는 것이다. react-native, ionic 등등으로 웹 개발자가 앱에 대해 깊게 알지 못해도 어느정도 작동하는 앱을 만들 수 있게 된 것이다. 그러면 우리는 하이브리드 앱 개발자 라고 구체적으로 말하기도 한다. 그리고 이 모든 영역을 넘나드는 넓은 범위를 가진 개발자들도 있는데 그런 분들은 그냥 자신을 클라이언트 개발자 라고 부르는 것 같다. 게임 같은 경우도 게임 클라이언트 개발자 라고 게임을 앞에 특정해서 부르는 편이다. 그런데 이마저도 게임 클라이언트 개발 기술이 유니티, 언리얼엔진 등등으로 나뉘어서 아예 더 좁혀서 유니티 개발자 라고 부르기도 한다.

서버는 상대적으로 편하다. 서버, 백엔드의 경우 사용자 눈에 보이지 않기 때문에 사실 두 단어가 혼용되는 경우가 많은 것 같다. 서버 뿐만이 아니라 사용자에게 보이지 않는 다른 모든 일을 하는 경우 조금 더 백엔드 라고 자신을 칭하는 편인 것 같다.

이것은 확실한 정의일까?

아니다. 그리고 웹 개발자에게 요구되는 역량의 범위가 어디까지일까? 에 대한 논쟁도 한창이다. 트위터(이제 X라고 불러야겠지) 에서도 주기적으로 사람들이 "그래도 css 정도는 다룰 줄 알아야 개발자" 와 같은 논쟁을 펼친다. 혹은 html과 css만 다루는 퍼블리셔라는 직군은 개발자라고 할 수 있는가? 심지어 요즘은 프론트엔드 개발자가 javascript, html 정도만 알면 되지 css까지 구체적으로 알아야 할까? 하는 논의까지 흘러가기도 한다. 개인적으로는 자신을 특정 직무에 얽매이지 않는 '소프트웨어 개발자'로 정의하기를 좋아한다. 그리고 같이 일하는 팀원들에게 프론트엔드, 백엔드에 크게 얽매이지 않고 업무를 수행해주기를 기대하는 것 같기도 하다. 큰 회사일수록 책임과 권한이 정말 세부적으로 나눠져 있고 한 직무에 요구되는 전문성의 깊이도 상당히 깊기 때문에 이것은 정말 관점의 차이다. 예를 들어 네이버에 하루에 수천만명이 접속하는데, 네이버 홈에서 보여지는 정보를 서버에서 제공하는 것과 화면에서 어떻게 보일 지 모두 다 이해하고 능숙해지기를 요구하는 것은 무리한 요구이고 새로운 개발자를 채용하기도 힘들 수 있다.

개발자의 직무 영역은 개개인이 속한 팀에 따라서 계속해서 변하고 있기 때문에 언제나 논쟁하기 좋은 주제인 것 같다. 최근에는 chatgpt는 물론 클라우드와 sass 서비스들이 워낙에 잘 만들어져 있어서 개발자들이 자신의 일자리를 없애가고 있는 중이라 언젠가는 이런 영역의 구분이 없어지고 나는 chatgpt로 홈페이지 만드는 개발자야 이렇게 부를지도 모르겠다.

Polling, Interrupt 방식

초링초링 — Mon, 22 Apr 2019 11:24:33 +0900

배경

타운홀 리뉴얼 과정에서 현황판의 데이터를 가져오는 방식을 polling 방식, interrupt 방식로 할 것인지 결정해야 했습니다. 10초마다 자동으로 갱신하는 polling 방식을 선택했습니다. 웹서핑 도중 polling이 쓰이는 여러 상황, 두 방식을 부르는 명칭을 발견해 명확히 알고 가면 좋을 것 같아 정리합니다.

개념

CPU에서 vs 통신에서 vs 웹에서

polling

CPU
- Polling은 특정 주기를 가지고 그 주기 마다 처리를 위한 시그널이 들어 왔는지를 체크 합니다. 따라서 커널과 같은 Interrupt Handler가 필요하지 않습니다. 해당 드라이버에서 스레드를 돌면서 주기적으로 체크만 하면 되기 때문입니다.
그래서 Interrupt 방식보다 구현이 쉽습니다. 하지만 시스템의 리소스를 많이 먹는 부분에 구현시 시스템 성능 저하의 원인이 되기도 합니다. 또한 처리에 정확한 타이밍을 요하는 곳에 사용을 할 경우, 이 또한 문제 발생의 원인이 되기도 합니다.

네트워크

- 폴링(polling)이란 하나의 장치(또는 프로그램)가 충돌 회피 또는 동기화 처리 등을 목적으로 다른 장치(또는 프로그램)의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료처리를 하는 방식을 말한다. 이 방식은 버스, 멀티포인트 형태와 같이 여러 개의 장치가 동일 회선을 사용하는 상황에서 주로 사용된다. 서버의 제어 장치(또는 프로그램)는 순차적으로 각 단말 장치(또는 프로그램)에 회선을 사용하기 원하는지를 물어본다. - 위키백과

- 통신에서, "폴링"은 한 프로그램이나 장치에서 다른 프로그램이나 장치들이 어떤 상태에 있는지를 지속적으로 체크하는 전송제어 방식으로서, 대체로 그들이 아직도 접속되어 있는 지와 데이터 전송을 원하는지 등을 확인한다.
명확히 말하면, 여러 개의 장치가 동일 회선을 공유하는 멀티드롭이나 멀티포인트 통신에서, 제어 장치는 각 장치에 한번에 하나씩 메시지를 보내어, 전송할 데이터가 있는지(즉, 회선을 사용하기 원하는지)를 묻는다.

웹에서

- 브라우저가 일정한 주기로 HTTP 요청을 보내는 방식입니다.
보통 실시간 데이터의 업데이트 주기는 예측하기 어려우므로, 그에 따른 불필요한 서버 및 네트웍 부하가 늘어납니다.
즉, 불필요한 서버 요청이 다수 생긴다는 말입니다. 주로 ajax call을 통해 요청합니다.

interrupt

- Interrupt 방식은 하드웨어에서 지정한 시그널을 받도록 구현하는 방식입니다.
- 커널의 Interrupt Handler가 Interrupt를 체크하고, Interrupt 발생시 Interrupt Thread(해당 드라이버)로 Interrupt 발생을
알려 줍니다. 따라서 Polling보다 다소 구현이 복잡합니다.
- 하지만 처리의 정확한 타이밍을 요하는 드라이버에 적합하고 드라이버에서는 Interrupt 발생 이벤트가 들어
올때만 처리를 하기 때문에 시스템에 부하를 줄일수 있습니다

응용

long polling

- HTTP 요청 시 서버는 해당 요청을 일정 시간 동안 대기 시킵니다. 만약, 대기 시간 안에 데이터가 업데이트되었다면, 그 즉시 클라이언트에게 응답을 보내고 전달받은 데이터를 처리 후 서버로 재요청을 시작합니다.

- 데이터 업데이트가 빈번한 경우엔 폴링에 비해 성능상 이점이 크지 않습니다.

스트리밍(Streaming) 방식

- 서버는 지속적인 업데이트를 위해 무한정(또는 일정 시간 동안) 요청을 대기시키며, "chunked" 기반 메시지를 이용하여 응답 시 연결을 유지 시킵니다.

예시