테크 한 스푼

CORS란 무엇인가 – 브라우저에서 API 요청이 막히는 이유

테크 한 스푼 — Sun, 31 May 2026 21:37:41 +0900

1. 개발하다가 갑자기 막히는 그 오류

웹 개발을 처음 시작하면 반드시 한 번은 마주치는 오류가 있습니다. 브라우저 콘솔에 다음과 같은 메시지가 뜨면서 API 요청이 막히는 상황입니다.

Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' has been blocked by CORS policy.

이 오류를 처음 보면 무슨 의미인지, 어떻게 해결해야 하는지 당황스럽습니다. 이 글에서는 CORS가 왜 존재하는지, 오류가 왜 발생하는지, 어떻게 해결하는지를 단계별로 설명드립니다.

2. 동일 출처 정책(Same-Origin Policy)이란?

CORS를 이해하려면 먼저 **동일 출처 정책(Same-Origin Policy)**을 알아야 합니다.

브라우저는 보안상의 이유로 다른 출처에서 온 리소스를 기본적으로 차단합니다. 여기서 출처(Origin)는 프로토콜 + 도메인 + 포트의 조합입니다.

예를 들어 http://localhost:3000과 http://localhost:8080은 포트가 다르기 때문에 서로 다른 출처입니다. http://example.com과 https://example.com은 프로토콜이 달라 다른 출처입니다.

이 정책이 존재하는 이유는 악의적인 사이트가 사용자 모르게 다른 사이트의 API를 호출해 개인정보를 탈취하는 것을 막기 위해서입니다.

3. CORS란 무엇인가?

**CORS(Cross-Origin Resource Sharing)**는 동일 출처 정책의 예외를 허용하는 메커니즘입니다. 서버가 "특정 출처에서 오는 요청은 허용한다"고 브라우저에게 알려주는 방식입니다.

즉, CORS는 서버가 설정하는 것입니다. 브라우저가 요청을 막는 것이 아니라, 서버가 허용 출처를 명시해주지 않아서 브라우저가 차단하는 것입니다.

CORS 오류는 브라우저에서만 발생합니다. Postman이나 curl 같은 도구로 같은 API를 호출하면 정상적으로 응답이 옵니다. 이 차이가 CORS를 이해하는 핵심입니다.

4. CORS 오류가 발생하는 상황

가장 흔한 CORS 오류 상황입니다.

프론트엔드가 http://localhost:3000에서 실행 중인데, 백엔드 API가 http://localhost:8080에 있을 때 발생합니다. 프론트엔드 배포 주소가 https://myblog.com인데, API 서버는 https://api.myblog.com에 있을 때도 발생합니다. 외부 API를 브라우저에서 직접 호출할 때 해당 API 서버가 CORS를 허용하지 않으면 발생합니다.

5. CORS 오류를 해결하는 방법

CORS 오류는 서버 쪽에서 허용 출처를 설정해야 해결됩니다.

Node.js (Express) 서버에서 CORS 설정 cors 패키지를 설치하고 미들웨어로 등록합니다.

npm install cors

const cors = require('cors');
app.use(cors({ origin: 'http://localhost:3000' }));

모든 출처를 허용하고 싶다면 origin: '*'으로 설정합니다. 단, 실서비스에서 모든 출처를 허용하는 것은 보안상 좋지 않으므로 허용할 출처를 명시적으로 지정하는 것이 좋습니다.

Nginx에서 CORS 헤더 추가 Nginx 설정 파일의 location 블록에 아래 헤더를 추가합니다.

add_header 'Access-Control-Allow-Origin' 'https://myblog.com';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

Spring Boot에서 CORS 설정 컨트롤러나 설정 클래스에서 @CrossOrigin 어노테이션 또는 WebMvcConfigurer를 사용해 허용 출처를 등록합니다.

6. CORS 관련 HTTP 헤더 이해하기

CORS는 HTTP 헤더를 통해 동작합니다. 주요 헤더를 알아두면 오류 메시지를 해석하는 데 도움이 됩니다.

서버가 응답에 포함하는 헤더

Access-Control-Allow-Origin은 어떤 출처에서 오는 요청을 허용할지 지정합니다. https://myblog.com 처럼 특정 도메인을 지정하거나, *로 모든 출처를 허용할 수 있습니다.

Access-Control-Allow-Methods는 허용하는 HTTP 메서드를 지정합니다. GET, POST, PUT, DELETE 처럼 명시합니다.

Access-Control-Allow-Headers는 요청에 포함할 수 있는 헤더를 지정합니다. Authorization, Content-Type 처럼 명시합니다.

Access-Control-Max-Age는 Preflight 요청의 결과를 브라우저가 캐시하는 시간(초)을 지정합니다.

7. Preflight 요청이란?

브라우저는 실제 요청을 보내기 전에 서버가 해당 요청을 허용하는지 먼저 확인하는 Preflight 요청을 보내는 경우가 있습니다.

Preflight 요청은 OPTIONS 메서드로 전송되며, 서버가 해당 출처와 메서드를 허용한다고 응답하면 실제 요청을 보냅니다.

Preflight 요청이 발생하는 조건은 GET, POST, HEAD 이외의 메서드를 사용할 때, Content-Type이 application/json인 경우, 커스텀 헤더(예: Authorization)를 포함하는 경우입니다.

서버에서 OPTIONS 요청을 처리하도록 설정하지 않으면 Preflight 단계에서 CORS 오류가 발생합니다.

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

동일 출처 정책 때문에 브라우저는 기본적으로 다른 출처의 리소스 요청을 차단합니다.
CORS는 서버가 특정 출처의 요청을 허용하도록 브라우저에 알려주는 메커니즘입니다.
CORS 오류는 서버에서 Access-Control-Allow-Origin 헤더를 설정해 해결합니다.
CORS 오류는 브라우저에서만 발생하며, Postman 같은 도구에서는 발생하지 않습니다.
실서비스에서는 모든 출처(*)를 허용하지 말고 필요한 도메인만 명시적으로 허용합니다.

다음 글에서는 웹소켓(WebSocket)이란 무엇인지, 실시간 채팅이 되는 원리를 알아보겠습니다.

JWT 토큰이란 무엇인가 – 토큰 기반 인증 쉽게 이해하기

테크 한 스푼 — Sun, 31 May 2026 15:52:45 +0900

1. 세션 방식의 한계

앞서 세션 방식의 로그인을 배웠습니다. 사용자가 로그인하면 서버가 세션을 생성하고, 세션 ID를 쿠키로 전달하는 방식입니다.

세션 방식은 잘 동작하지만 한 가지 큰 문제가 있습니다. 사용자 정보가 서버 메모리에 저장되기 때문에, 서버가 여러 대로 늘어나면 문제가 생깁니다.

예를 들어 서버 A에서 로그인해서 세션이 서버 A에 저장됐는데, 다음 요청이 서버 B로 전달되면 서버 B에는 그 세션 정보가 없어서 로그인이 풀리는 현상이 생깁니다. 트래픽이 많은 대형 서비스에서는 서버를 여러 대 운영하는 것이 기본이기 때문에, 이 문제가 매우 중요합니다.

이 문제를 해결하기 위해 등장한 것이 JWT 토큰 방식입니다.

2. JWT란 무엇인가?

**JWT(JSON Web Token)**는 사용자 정보를 토큰 자체에 담아 클라이언트에 전달하는 인증 방식입니다.

세션 방식은 사용자 정보를 서버에 저장하고 ID만 주는 방식이라면, JWT는 정보 자체를 암호화해서 토큰으로 만들어 클라이언트에게 주는 방식입니다.

쉬운 비유로 설명하면, 세션은 물품 보관함 번호표와 같습니다. 번호표만 있고 실제 물건은 서버(보관함)에 있습니다. 반면 JWT는 신분증과 같습니다. 신분증 자체에 이름, 생년월일, 사진 등 모든 정보가 담겨 있습니다.

3. JWT의 구조

JWT는 세 부분으로 구성되며, 각 부분은 점(.)으로 구분됩니다.

실제 JWT 토큰은 다음처럼 생겼습니다.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

이 세 부분은 순서대로 헤더(Header), 페이로드(Payload), 서명(Signature)입니다. 각 부분은 Base64로 인코딩되어 있습니다.

헤더(Header) 토큰의 타입(JWT)과 사용된 암호화 알고리즘 정보를 담고 있습니다.

페이로드(Payload) 실제 담고 싶은 데이터(사용자 ID, 권한, 만료 시간 등)를 담는 부분입니다. 이 데이터를 **클레임(Claim)**이라고 부릅니다.

{
  "userId": 123,
  "email": "hong@example.com",
  "role": "admin",
  "exp": 1746000000
}

서명(Signature) 헤더와 페이로드를 합친 뒤 서버만 알고 있는 비밀 키로 암호화한 값입니다. 이 서명 덕분에 토큰이 위조되지 않았음을 검증할 수 있습니다.

페이로드는 Base64로 인코딩된 것이라 누구나 디코딩해서 볼 수 있습니다. 따라서 비밀번호 같은 민감한 정보는 절대 페이로드에 넣으면 안 됩니다.

4. JWT 인증 동작 방식

JWT를 사용한 로그인 과정을 순서대로 살펴보겠습니다.

첫 번째로 사용자가 아이디와 비밀번호로 로그인 요청을 보냅니다.

두 번째로 서버가 아이디와 비밀번호를 확인하고 일치하면, 사용자 정보가 담긴 JWT 토큰을 생성해서 클라이언트에 전달합니다.

세 번째로 클라이언트(브라우저 또는 앱)는 토큰을 저장합니다. 주로 로컬 스토리지나 쿠키에 저장합니다.

네 번째로 이후 API 요청 시마다 HTTP 헤더에 토큰을 담아 서버로 전송합니다. Authorization: Bearer 토큰값 형태로 전달합니다.

다섯 번째로 서버는 토큰의 서명을 검증해 유효한 토큰인지 확인합니다. 유효하면 토큰 안의 사용자 정보를 꺼내 요청을 처리합니다.

이 과정에서 서버는 토큰을 어디에도 저장하지 않습니다. 서명 검증만으로 토큰의 유효성을 판단합니다.

5. 세션 방식 vs JWT 방식 비교

구분세션 방식JWT 방식

정보 저장 위치	서버	클라이언트(토큰 안)
서버 부하	있음 (세션 저장 필요)	없음
다중 서버 환경	별도 처리 필요	간편
토큰 강제 만료	가능	어려움
보안	상대적으로 안전	토큰 탈취 시 위험
주요 사용처	일반 웹사이트	모바일 앱, SPA, MSA

6. JWT의 장점과 단점

장점

서버에 상태를 저장하지 않아 서버 확장이 자유롭습니다. 서버 여러 대를 운영해도 어떤 서버에서든 토큰을 검증할 수 있습니다. 모바일 앱이나 다양한 클라이언트에서 사용하기 편리합니다.

단점

토큰이 탈취되면 만료 전까지 막을 방법이 없습니다. 세션처럼 서버에서 즉시 로그아웃 처리가 어렵습니다. 페이로드에 많은 정보를 담을수록 토큰 크기가 커져 매 요청마다 전송 데이터가 늘어납니다.

7. JWT 사용 시 주의해야 할 보안 사항

만료 시간 설정 필수 JWT는 토큰에 만료 시간(exp)을 설정해야 합니다. 만료 시간이 없으면 한 번 발급된 토큰이 영원히 유효해져 보안 사고 시 대응이 불가능합니다. 일반적으로 액세스 토큰은 15분~1시간, 리프레시 토큰은 7~30일로 설정합니다.

HTTPS 사용 필수 토큰이 네트워크에서 탈취되지 않도록 반드시 HTTPS로 통신해야 합니다.

민감한 정보 페이로드에 넣지 않기 페이로드는 누구나 디코딩해서 볼 수 있기 때문에 비밀번호, 카드 번호 같은 민감한 정보는 절대 담으면 안 됩니다.

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

JWT는 사용자 정보를 토큰 자체에 담아 클라이언트에 전달하는 토큰 기반 인증 방식입니다.
헤더, 페이로드, 서명 세 부분으로 구성되며 서명으로 위조 여부를 검증합니다.
서버에 상태를 저장하지 않아 다중 서버 환경에 적합합니다.
페이로드는 디코딩 가능하므로 민감한 정보를 담으면 안 됩니다.
반드시 만료 시간을 설정하고 HTTPS와 함께 사용해야 합니다.

다음 글에서는 CORS란 무엇인지, 브라우저에서 API 요청이 막히는 이유를 알아보겠습니다.

쿠키와 세션의 차이 – 개념 및 활용, 로그인 상태는 어떻게 유지되는가?

테크 한 스푼 — Sun, 31 May 2026 09:13:54 +0900

로그인은 한 번만 했는데 왜 계속 유지될까?
HTTP는 기본적으로 상태를 기억하지 못한다
쿠키(Cookie)란 무엇인가?
세션(Session)이란 무엇인가?
쿠키와 세션의 차이 비교
실제 로그인 과정에서 쿠키와 세션이 동작하는 방식
쿠키와 세션의 보안 이슈
정리 및 다음 단계

1. 로그인은 한 번만 했는데 왜 계속 유지될까?

네이버에 로그인하면 브라우저를 닫았다 열어도 로그인 상태가 유지됩니다. 반대로 어떤 사이트는 일정 시간이 지나면 자동으로 로그아웃됩니다.

인터넷 쇼핑몰에서 상품을 장바구니에 담고 페이지를 이동해도 장바구니 내역이 사라지지 않습니다. 이런 것들이 모두 가능한 이유가 바로 쿠키와 세션 덕분입니다.

2. HTTP는 기본적으로 상태를 기억하지 못한다

쿠키와 세션을 이해하려면 먼저 HTTP의 특성을 알아야 합니다.

HTTP는 무상태(Stateless) 프로토콜입니다. 서버는 각 요청을 완전히 독립적으로 처리하며, 이전 요청을 기억하지 못합니다.

쉬운 비유로 설명하면, 매번 방문할 때마다 기억을 잃는 가게 직원과 같습니다. 오늘 처음 방문해서 주문한 손님이 5분 후 다시 와도 직원은 그 사람을 전혀 기억하지 못합니다.

이 특성 때문에 서버는 "이 요청을 보낸 사람이 아까 로그인한 그 사람이구나"를 자동으로 알 수 없습니다. 이 문제를 해결하기 위해 쿠키와 세션이 등장했습니다.

3. 쿠키(Cookie)란 무엇인가?

쿠키는 서버가 브라우저에 저장하도록 요청하는 작은 텍스트 데이터입니다. 브라우저는 쿠키를 저장해두고, 이후 같은 서버에 요청을 보낼 때마다 자동으로 쿠키를 함께 전송합니다.

쿠키의 동작 방식을 순서대로 살펴보면 다음과 같습니다. 사용자가 처음 사이트에 접속하면 서버가 브라우저에게 "이 쿠키를 저장해줘"라고 응답합니다. 브라우저는 쿠키를 저장합니다. 사용자가 같은 사이트에 다시 요청을 보내면 브라우저가 저장된 쿠키를 자동으로 요청에 포함시킵니다. 서버는 쿠키를 확인해서 누가 요청했는지 식별합니다.

쿠키의 주요 특징은 다음과 같습니다. 브라우저(클라이언트)에 저장됩니다. 만료 기간을 설정할 수 있어 브라우저를 닫아도 유지됩니다. 용량이 작습니다(4KB 제한). 사용자가 직접 확인하거나 삭제할 수 있습니다.

4. 세션(Session)이란 무엇인가?

세션은 사용자 정보를 서버에 저장하는 방식입니다. 서버는 각 사용자에게 고유한 세션 ID를 부여하고, 이 ID를 쿠키에 담아 브라우저로 전달합니다. 이후 브라우저는 요청마다 세션 ID를 담은 쿠키를 서버로 전송하고, 서버는 세션 ID로 해당 사용자 정보를 찾아 처리합니다.

세션의 주요 특징은 다음과 같습니다. 실제 데이터는 서버에 저장되고, 브라우저에는 세션 ID만 전달됩니다. 브라우저를 닫으면 기본적으로 세션이 종료됩니다. 서버에서 세션을 직접 만료시킬 수 있습니다. 서버 메모리나 데이터베이스를 사용하기 때문에 쿠키보다 많은 자원을 사용합니다.

5. 쿠키와 세션의 차이 비교

구분쿠키세션

저장 위치	브라우저(클라이언트)	서버
보안	상대적으로 낮음	상대적으로 높음
만료	설정한 기간 유지	브라우저 종료 시 또는 서버 설정 기간
저장 용량	작음 (4KB)	상대적으로 큼
서버 부하	없음	있음
사용 예	자동 로그인, 장바구니, 설정 저장	로그인 인증, 민감한 사용자 정보

6. 실제 로그인 과정에서 쿠키와 세션이 동작하는 방식

일반적인 로그인 처리 흐름을 순서대로 살펴보겠습니다.

첫 번째로 사용자가 아이디와 비밀번호를 입력해 로그인 요청을 보냅니다.

두 번째로 서버는 아이디와 비밀번호를 확인하고, 일치하면 세션을 생성합니다. 세션에는 사용자 ID, 로그인 시간 등의 정보가 저장됩니다.

세 번째로 서버는 생성된 세션 ID를 쿠키에 담아 브라우저로 전달합니다.

네 번째로 브라우저는 세션 ID가 담긴 쿠키를 저장합니다.

다섯 번째로 이후 사용자가 다른 페이지에 접속할 때 브라우저가 자동으로 세션 ID 쿠키를 서버에 전송합니다.

여섯 번째로 서버는 세션 ID로 저장된 사용자 정보를 찾아 로그인 상태를 확인하고 페이지를 제공합니다.

이 과정 덕분에 매 페이지마다 다시 로그인하지 않아도 로그인 상태가 유지됩니다.

7. 쿠키와 세션의 보안 이슈

쿠키의 보안 취약점 쿠키는 브라우저에 저장되기 때문에 사용자가 직접 내용을 볼 수 있고 수정도 가능합니다. 또한 XSS(Cross-Site Scripting) 공격으로 쿠키가 탈취될 수 있습니다. 이를 방지하기 위해 HttpOnly 속성을 설정하면 JavaScript로 쿠키에 접근하는 것을 막을 수 있습니다. Secure 속성을 설정하면 HTTPS 연결에서만 쿠키가 전송됩니다.

세션 하이재킹 세션 ID가 담긴 쿠키를 공격자가 탈취하면, 그 ID로 서버에 접근해 해당 사용자인 척 행동할 수 있습니다. 이를 세션 하이재킹이라고 합니다. 공용 와이파이에서 HTTPS가 아닌 사이트를 사용할 때 특히 위험합니다.

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

HTTP는 무상태 프로토콜이라 서버가 사용자를 기억하지 못합니다. 이 문제를 쿠키와 세션으로 해결합니다.
쿠키는 브라우저에 데이터를 저장하고, 요청마다 자동으로 서버에 전송됩니다.
세션은 서버에 데이터를 저장하고, 브라우저에는 세션 ID만 쿠키로 전달합니다.
로그인 인증처럼 민감한 정보는 세션으로, 설정 저장이나 자동 로그인처럼 긴 기간 유지가 필요한 것은 쿠키로 처리합니다.

다음 글에서는 JWT 토큰이란 무엇인지, 토큰 기반 인증이 어떻게 동작하는지 알아보겠습니다.

JSON이란? – JSON 뜻, 목적, 데이터를 주고받는 형식 쉽게 이해하기

테크 한 스푼 — Sat, 30 May 2026 23:25:54 +0900

1. API 응답에서 자꾸 나오는 이 형태는 무엇인가?

REST API를 배우면서 서버 응답 예시로 아래와 같은 형태를 자주 봤을 것입니다.

{
  "name": "홍길동",
  "age": 30,
  "email": "hong@example.com"
}

중괄호, 따옴표, 콜론, 쉼표로 이루어진 이 형태가 바로 JSON입니다. 웹 개발에서 데이터를 주고받을 때 가장 널리 쓰이는 형식입니다.

2. JSON의 정의

**JSON(JavaScript Object Notation)**은 데이터를 저장하고 전송하기 위한 텍스트 기반의 경량 데이터 형식입니다. 이름에 JavaScript가 들어가지만 특정 언어에 종속되지 않으며, Python, Java, PHP, Go 등 거의 모든 프로그래밍 언어에서 읽고 쓸 수 있습니다.

JSON의 가장 큰 장점은 사람이 읽기 쉽고, 컴퓨터가 파싱하기도 쉽다는 점입니다. 구조가 단순하고 용량이 가벼워 API 통신에 최적화되어 있습니다.

3. JSON의 기본 문법

JSON은 키(key)와 값(value)의 쌍으로 구성됩니다. 키는 반드시 큰따옴표로 감싸야 하고, 키와 값은 콜론(:)으로 구분하며, 여러 쌍은 쉼표(,)로 구분합니다.

기본 형태입니다.

{
  "키": 값,
  "키": 값
}

실제 사용자 정보를 담은 JSON 예시입니다.

{
  "id": 1,
  "name": "홍길동",
  "email": "hong@example.com",
  "isActive": true
}

4. JSON에서 사용할 수 있는 데이터 타입

JSON에서 값으로 사용할 수 있는 타입은 6가지입니다.

문자열(String): 큰따옴표로 감쌉니다. "홍길동", "seoul" 처럼 표현합니다.

숫자(Number): 따옴표 없이 씁니다. 30, 3.14, -100 처럼 표현합니다.

불리언(Boolean): 참 또는 거짓을 나타냅니다. true 또는 false로 씁니다.

null: 값이 없음을 나타냅니다. null로 씁니다.

배열(Array): 대괄호로 감싸고 쉼표로 구분합니다. 여러 값을 순서대로 담을 수 있습니다.

{
  "hobbies": ["독서", "운동", "코딩"]
}

객체(Object): 중괄호로 감싼 키-값 쌍입니다. 객체 안에 객체를 중첩해서 사용할 수 있습니다.

{
  "user": {
    "name": "홍길동",
    "address": {
      "city": "서울",
      "zip": "04524"
    }
  }
}

5. JSON vs XML – 왜 JSON이 대세가 됐나?

JSON이 등장하기 전에는 **XML(eXtensible Markup Language)**이 데이터 교환의 표준이었습니다. 두 형식을 같은 데이터로 비교해 보겠습니다.

XML로 사용자 정보를 표현하면 다음과 같습니다.

<user>
  <name>홍길동</name>
  <age>30</age>
  <email>hong@example.com</email>
</user>

JSON으로 같은 내용을 표현하면 훨씬 간결합니다.

{
  "name": "홍길동",
  "age": 30,
  "email": "hong@example.com"
}

구분JSONXML

가독성	높음	보통
용량	가벼움	무거움
파싱 속도	빠름	느림
문법	단순	복잡
현재 사용	대부분의 웹 API	일부 레거시 시스템

JSON이 가볍고 읽기 쉬우며 JavaScript와 자연스럽게 연동된다는 장점 덕분에, 현재는 웹 API의 표준 데이터 형식으로 자리 잡았습니다.

6. 실제 서비스에서 JSON이 사용되는 방식

REST API 응답 서버가 클라이언트에게 데이터를 돌려줄 때 JSON 형태로 반환합니다. 쇼핑몰에서 상품 목록을 요청하면 아래처럼 JSON 배열로 응답이 옵니다.

[
  {
    "id": 1,
    "name": "노트북",
    "price": 1200000,
    "inStock": true
  },
  {
    "id": 2,
    "name": "마우스",
    "price": 35000,
    "inStock": false
  }
]

설정 파일 많은 프로그램이 설정 파일을 JSON 형식으로 저장합니다. Node.js 프로젝트의 package.json, VS Code의 설정 파일이 대표적인 예입니다.

로컬 스토리지 브라우저의 로컬 스토리지에 복잡한 데이터를 저장할 때도 JSON 문자열로 변환해 저장합니다.

7. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

JSON은 키-값 쌍으로 이루어진 경량 데이터 형식으로, REST API 통신의 표준입니다.
문자열, 숫자, 불리언, null, 배열, 객체 6가지 타입을 지원합니다.
XML보다 가볍고 읽기 쉬워 현재 웹 서비스의 데이터 교환 형식으로 가장 많이 사용됩니다.
키는 반드시 큰따옴표로 감싸야 하며, 문자열 값도 큰따옴표를 사용합니다.

다음 글에서는 쿠키와 세션의 차이, 로그인 상태가 어떻게 유지되는지 알아보겠습니다.

REST API란 – GET, POST, PUT, DELETE 완전 정리

테크 한 스푼 — Sat, 30 May 2026 18:52:13 +0900

1. API를 배웠는데 REST는 또 뭔가?

API가 "서로 다른 소프트웨어가 소통하는 창구"라는 것을 배웠습니다. 그런데 개발 관련 글을 읽다 보면 단순히 "API"가 아니라 "REST API", "RESTful API"라는 표현을 더 자주 만나게 됩니다.

REST는 API를 만드는 여러 방식 중 하나입니다. 현재 웹 서비스에서 가장 널리 사용되는 API 설계 방식이기 때문에, 웹 개발을 배운다면 REST API 개념은 반드시 알아야 합니다.

2. REST API의 정의

**REST(Representational State Transfer)**는 웹의 장점을 최대한 활용할 수 있도록 로이 필딩이 2000년에 제안한 API 설계 원칙입니다. REST 원칙을 따르는 API를 REST API 또는 RESTful API라고 부릅니다.

REST API는 HTTP 프로토콜을 기반으로 동작합니다. URL로 어떤 데이터를 다룰지 표현하고, HTTP 메서드(GET, POST, PUT, DELETE 등)로 어떤 행동을 할지 표현합니다.

3. REST의 핵심 원칙

REST API가 따르는 주요 원칙을 알아두면 왜 이런 방식으로 설계하는지 이해하는 데 도움이 됩니다.

균일한 인터페이스: URL과 HTTP 메서드를 일관된 방식으로 사용합니다. 누가 만들어도 비슷한 구조를 갖습니다.

무상태(Stateless): 각 요청은 독립적이며, 서버는 이전 요청의 상태를 기억하지 않습니다. 필요한 정보는 매 요청마다 함께 전달해야 합니다.

계층 구조: 클라이언트는 자신이 서버와 직접 통신하는지, 중간 서버(프록시, 로드밸런서)를 거치는지 알 필요가 없습니다.

캐시 가능: 응답 데이터는 캐시할 수 있어야 하며, 이를 통해 성능을 높일 수 있습니다.

4. HTTP 메서드 완전 정리 – GET, POST, PUT, DELETE

REST API에서 가장 중요한 개념이 바로 HTTP 메서드입니다. 같은 URL이라도 어떤 메서드를 사용하느냐에 따라 완전히 다른 동작을 합니다.

메서드역할비유

GET	데이터 조회	도서관에서 책을 빌려보기
POST	데이터 생성	도서관에 새 책 등록하기
PUT	데이터 전체 수정	책의 내용 전체를 새 버전으로 교체하기
PATCH	데이터 일부 수정	책의 특정 페이지만 수정하기
DELETE	데이터 삭제	책을 도서관에서 폐기하기

GET – 데이터를 가져올 때 서버에서 데이터를 읽어오는 요청입니다. 데이터를 변경하지 않기 때문에 몇 번을 호출해도 결과가 같습니다. 브라우저에서 URL을 입력하면 기본적으로 GET 요청이 발생합니다.

POST – 새 데이터를 만들 때 서버에 새로운 데이터를 생성하는 요청입니다. 회원가입, 게시글 작성, 주문 생성 등이 해당됩니다. 같은 요청을 반복하면 데이터가 중복으로 생성될 수 있습니다.

PUT – 데이터를 수정할 때 기존 데이터를 새로운 내용으로 완전히 교체하는 요청입니다. 수정하지 않은 필드도 모두 포함해서 전송해야 합니다.

PATCH – 데이터 일부만 수정할 때 기존 데이터 중 일부 필드만 수정하는 요청입니다. 변경할 필드만 보내면 됩니다. PUT과 혼용되는 경우도 많습니다.

DELETE – 데이터를 삭제할 때 서버의 특정 데이터를 삭제하는 요청입니다. 게시글 삭제, 계정 탈퇴 등이 해당됩니다.

5. REST API URL 설계 방식

REST API URL은 명사로 리소스(자원)를 표현하고, HTTP 메서드로 행동을 표현합니다.

예를 들어 블로그 게시글을 관리하는 API URL을 설계한다면 아래와 같이 구성합니다.

전체 게시글 목록을 조회할 때는 GET 방식으로 /posts에 요청합니다. 특정 게시글을 조회할 때는 GET 방식으로 /posts/1처럼 ID를 URL에 포함합니다. 새 게시글을 작성할 때는 POST 방식으로 /posts에 요청합니다. 게시글을 수정할 때는 PUT 방식으로 /posts/1에 요청합니다. 게시글을 삭제할 때는 DELETE 방식으로 /posts/1에 요청합니다.

REST API URL 설계 시 지켜야 할 규칙이 몇 가지 있습니다. URL에는 동사 대신 명사를 사용합니다. /getPosts 대신 /posts처럼 작성합니다. 소문자를 사용하고 단어 구분에는 하이픈(-)을 사용합니다. 마지막 슬래시(/)는 붙이지 않습니다.

6. REST API 요청과 응답의 구조

REST API는 주로 JSON 형식으로 데이터를 주고받습니다.

요청 예시로, 새 사용자를 생성하는 POST 요청의 본문(body)은 아래와 같은 JSON 형태입니다.

{
  "name": "홍길동",
  "email": "hong@example.com",
  "password": "1234"
}

응답 예시로, 서버는 처리 결과를 HTTP 상태 코드와 함께 JSON으로 돌려줍니다.

{
  "id": 1,
  "name": "홍길동",
  "email": "hong@example.com",
  "createdAt": "2026-05-01T09:00:00Z"
}

HTTP 상태 코드로 요청 결과를 알 수 있습니다. 200은 성공, 201은 생성 성공, 400은 잘못된 요청, 401은 인증 필요, 404는 리소스 없음, 500은 서버 오류를 의미합니다.

7. REST API가 아닌 것들 – SOAP와의 차이

REST 이전에는 **SOAP(Simple Object Access Protocol)**이라는 방식이 많이 사용됐습니다. 두 방식을 간단히 비교하면 다음과 같습니다.

구분REST APISOAP

데이터 형식	JSON (주로)	XML
속도	빠름	느림
복잡도	간단	복잡
현재 사용	대부분의 웹 서비스	금융, 공공기관 일부

현재는 대부분의 웹·앱 서비스가 REST API를 사용하며, SOAP는 일부 금융기관이나 레거시 시스템에서 유지되고 있습니다.

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

REST API는 HTTP를 기반으로 URL로 리소스를 표현하고 메서드로 행동을 표현하는 API 설계 방식입니다.
GET은 조회, POST는 생성, PUT은 전체 수정, PATCH는 부분 수정, DELETE는 삭제를 담당합니다.
URL은 명사로 설계하고, 행동은 HTTP 메서드로 구분합니다.
REST API는 주로 JSON 형식으로 데이터를 주고받습니다.

다음 글에서는 JSON이 무엇인지, 데이터를 어떻게 주고받는지 알아보겠습니다.

API란 무엇인가 – API 개념, API 목적 등에 대 쉬운 설명

테크 한 스푼 — Sat, 30 May 2026 14:08:34 +0900

1. API라는 단어, 어디서 많이 들어봤는데?

뉴스나 IT 관련 글을 읽다 보면 "API를 연동했다", "API 키를 발급받아야 한다", "API 요청 한도를 초과했다"는 표현을 자주 접하게 됩니다. 개발자들 사이에서는 너무나 당연하게 쓰이는 단어지만, 처음 접하는 분들에게는 막연하게 느껴질 수 있습니다.

이 글에서는 기술적인 설명을 최대한 줄이고, 일상적인 비유를 통해 API가 무엇인지 쉽게 설명드립니다.

2. API의 정확한 정의

**API(Application Programming Interface)**는 서로 다른 소프트웨어가 서로 소통할 수 있도록 정해놓은 규칙과 방법의 집합입니다.

풀어서 설명하면, 어떤 서비스가 자신의 기능이나 데이터를 외부에서 사용할 수 있도록 공개한 창구라고 볼 수 있습니다. 이 창구를 통해 개발자는 해당 서비스의 내부 구조를 몰라도 필요한 기능을 가져다 쓸 수 있습니다.

3. 일상 속 API – 실생활 비유로 이해하기

API를 이해하는 가장 좋은 방법은 식당의 주문 시스템으로 비유하는 것입니다.

손님(클라이언트)은 주방(서버) 안이 어떻게 돌아가는지 알 필요가 없습니다. 손님은 메뉴판에서 원하는 음식을 고르고, **웨이터(API)**에게 주문합니다. 웨이터는 주방에 주문을 전달하고, 완성된 음식을 손님에게 가져다줍니다.

이 비유에서 각 역할을 정리하면 다음과 같습니다.

식당 비유API 세계

손님	앱 또는 개발자
웨이터	API
주방	서버 또는 데이터베이스
메뉴판	API 문서(Documentation)
음식	요청한 데이터 또는 기능

손님은 주방 레시피를 몰라도 음식을 먹을 수 있듯, 개발자는 상대방 서버의 내부 구조를 몰라도 API를 통해 원하는 데이터를 가져올 수 있습니다.

4. API가 실제로 사용되는 사례

사례 1. 카카오맵 API 배달 앱에서 지도를 보여줄 때, 그 앱이 지도를 직접 만든 것이 아닙니다. 카카오맵 API를 사용해 카카오의 지도 데이터를 가져와서 보여주는 것입니다. 카카오가 만들어 공개한 창구(API)를 통해 다른 앱들이 지도 기능을 사용하는 것입니다.

사례 2. 날씨 앱 스마트폰 날씨 앱은 직접 기상 데이터를 수집하지 않습니다. 기상청이나 날씨 데이터 제공 서비스의 API를 호출해 현재 날씨 정보를 받아옵니다.

사례 3. 소셜 로그인 "구글 계정으로 로그인", "카카오 계정으로 로그인" 버튼을 클릭하면 구글·카카오의 API를 통해 인증 정보를 주고받습니다. 서비스가 구글 서버에 직접 접근하는 것이 아니라, 정해진 API 규칙에 따라 인증 요청을 보내고 결과를 받는 것입니다.

사례 4. 결제 시스템 쇼핑몰에서 카드 결제를 할 때 쇼핑몰이 직접 카드사와 통신하는 것이 아닙니다. 토스, 아임포트 같은 결제 대행사의 API를 통해 결제를 처리합니다.

5. API의 종류

API는 사용 방식과 접근 범위에 따라 여러 종류로 나뉩니다.

공개 API (Open API / Public API) 누구나 사용할 수 있도록 공개된 API입니다. 카카오맵 API, 공공데이터포털의 날씨 API, YouTube Data API 등이 해당됩니다. 대부분 API 키를 발급받아 사용합니다.

비공개 API (Private API) 회사 내부에서만 사용하는 API입니다. 프론트엔드 앱과 백엔드 서버가 서로 데이터를 주고받을 때 사용하는 API가 대표적입니다.

파트너 API (Partner API) 특정 파트너사에게만 제공하는 API입니다. 예를 들어 특정 플랫폼과 계약을 맺은 업체에게만 제공하는 배송 추적 API 같은 것들이 해당됩니다.

6. API 없이는 어떤 일이 생길까?

API가 없다면 모든 서비스가 필요한 기능을 처음부터 직접 만들어야 합니다. 지도 기능이 필요하면 직접 지도를 만들고, 결제 기능이 필요하면 직접 카드사와 계약하고, 날씨 정보가 필요하면 직접 기상 관측 장비를 설치해야 하는 식입니다.

API 덕분에 개발자들은 이미 잘 만들어진 기능을 가져다 쓰고, 자신의 서비스만의 핵심 기능에 집중할 수 있습니다. 현대의 인터넷 서비스는 수많은 API가 서로 연결되어 동작하는 생태계라고 할 수 있습니다.

7. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

API는 서로 다른 소프트웨어가 소통할 수 있도록 정해놓은 규칙과 창구입니다.
식당의 웨이터처럼, API는 요청을 전달하고 결과를 돌려주는 중간 역할을 합니다.
카카오맵, 날씨 데이터, 소셜 로그인, 결제 시스템 등 일상 속 서비스 대부분이 API를 기반으로 동작합니다.
API 덕분에 개발자는 필요한 기능을 처음부터 만들 필요 없이 가져다 쓸 수 있습니다.

다음 글에서는 REST API란 무엇인지, GET·POST·PUT·DELETE가 각각 어떤 역할을 하는지 알아보겠습니다.

서버 없이 웹사이트 배포하는 방법 – GitHub Pages, Netlify, Vercel 비교

테크 한 스푼 — Fri, 29 May 2026 20:42:00 +0900

서버 없이도 웹사이트를 올릴 수 있다
정적 사이트란 무엇인가?
GitHub Pages – 가장 간단한 무료 호스팅
Netlify – 자동 배포와 편리한 기능
Vercel – 프론트엔드 개발자의 최애 도구
세 서비스 비교 정리
어떤 서비스를 선택해야 할까?
정리 및 마무리

1. 서버 없이도 웹사이트를 올릴 수 있다

지금까지 서버를 직접 운영하는 방법을 배웠습니다. 하지만 모든 웹사이트가 서버를 직접 운영해야 하는 것은 아닙니다.

포트폴리오, 블로그, 랜딩 페이지처럼 서버에서 동적으로 처리할 것이 없는 사이트라면, 서버를 빌리고 세팅하는 수고 없이 훨씬 간단하게 배포할 수 있습니다.

GitHub Pages, Netlify, Vercel은 이런 사이트를 무료로 간편하게 배포할 수 있게 해주는 서비스입니다. 각각 특징이 다르기 때문에, 어떤 서비스를 선택하면 좋은지 비교해 드립니다.

2. 정적 사이트란 무엇인가?

**정적 사이트(Static Site)**는 모든 사용자에게 동일한 HTML, CSS, JavaScript 파일을 그대로 전달하는 사이트입니다. 서버에서 데이터베이스를 조회하거나 코드를 실행하는 처리가 없습니다.

포트폴리오 사이트, 회사 소개 페이지, 이벤트 랜딩 페이지, 문서 사이트, 기술 블로그(Jekyll, Hugo, Gatsby 등으로 만든 것) 등이 해당됩니다.

반대로 로그인, 댓글, 결제, 실시간 데이터가 필요한 사이트는 서버가 필요한 동적 사이트입니다.

3. GitHub Pages – 가장 간단한 무료 호스팅

GitHub Pages는 GitHub 저장소(Repository)의 파일을 그대로 웹사이트로 제공하는 서비스입니다. GitHub 계정만 있으면 별도 가입 없이 바로 사용할 수 있습니다.

특징 완전 무료이며 GitHub 저장소와 직접 연결됩니다. 기본 도메인은 사용자명.github.io 형태입니다. 커스텀 도메인 연결도 지원합니다.

사용 방법 GitHub에서 새 저장소를 만듭니다. 저장소 이름을 사용자명.github.io 형식으로 만들면 해당 주소로 바로 접속 가능합니다. HTML, CSS, JS 파일을 저장소에 올리면 자동으로 배포됩니다.

일반 저장소도 Settings > Pages에서 배포 브랜치를 선택하면 GitHub Pages로 배포할 수 있습니다.

적합한 사용 케이스 개인 포트폴리오, 프로젝트 문서 사이트, GitHub와 연동해서 사용하는 기술 블로그에 적합합니다.

단점 서버 사이드 코드 실행이 불가능합니다. 빌드 기능이 제한적이어서 복잡한 프레임워크 사용에는 한계가 있습니다. 비공개 저장소는 유료 플랜이 필요합니다.

4. Netlify – 자동 배포와 편리한 기능

Netlify는 정적 사이트 호스팅에 특화된 서비스로, GitHub 저장소와 연동해 코드를 푸시하면 자동으로 빌드하고 배포하는 기능이 뛰어납니다.

특징 GitHub, GitLab, Bitbucket 연동 후 코드 푸시 시 자동 배포됩니다. 배포 이전 버전으로 즉시 롤백이 가능합니다. 폼 처리, 인증, 서버리스 함수 등 부가 기능을 제공합니다. 브랜치별 미리보기(Deploy Preview) 기능이 있어 PR마다 별도 URL로 미리 확인할 수 있습니다.

사용 방법 netlify.com에서 GitHub 계정으로 로그인합니다. 배포할 저장소를 선택하고 빌드 명령어와 출력 폴더를 지정합니다. Deploy 버튼을 클릭하면 자동으로 빌드 후 배포됩니다. 이후에는 코드를 푸시할 때마다 자동으로 다시 배포됩니다.

무료 플랜 제공 내용 매월 100GB 대역폭, 빌드 시간 300분, 서버리스 함수 125,000회 호출이 무료입니다.

적합한 사용 케이스 React, Vue, Next.js 정적 사이트, 팀 협업 프로젝트, 다양한 부가 기능이 필요한 사이트에 적합합니다.

5. Vercel – 프론트엔드 개발자의 최애 도구

Vercel은 Next.js를 만든 회사에서 운영하는 배포 플랫폼입니다. Next.js와의 완벽한 호환성으로 프론트엔드 개발자들 사이에서 특히 인기가 높습니다.

특징 Next.js와 완벽하게 통합됩니다. GitHub 연동 자동 배포가 매우 간편합니다. 엣지 네트워크를 통해 전 세계 어디서나 빠른 속도를 제공합니다. 서버리스 함수(API Routes)를 기본으로 지원합니다. 브랜치별 자동 미리보기 URL을 제공합니다.

사용 방법 vercel.com에서 GitHub 계정으로 로그인합니다. Import Project에서 저장소를 선택합니다. 프레임워크를 자동으로 감지해 빌드 설정이 자동 완성됩니다. Deploy 버튼 클릭 후 수십 초 안에 배포가 완료됩니다.

무료 플랜 제공 내용 개인 프로젝트 무제한, 매월 100GB 대역폭, 서버리스 함수 실행이 무료입니다.

적합한 사용 케이스 Next.js 프로젝트, React 앱, 개인 개발자 포트폴리오, API가 포함된 풀스택 프론트엔드 앱에 가장 적합합니다.

6. 세 서비스 비교 정리

항목GitHub PagesNetlifyVercel

가격	무료	무료(유료 플랜 있음)	무료(유료 플랜 있음)
자동 배포	기본 지원	강력한 자동 배포	강력한 자동 배포
빌드 기능	제한적	다양한 프레임워크 지원	프론트엔드 특화
서버리스 함수	미지원	지원	지원
Next.js 지원	제한적	지원	최상(공식 지원)
커스텀 도메인	지원	지원	지원
HTTPS	자동 적용	자동 적용	자동 적용
미리보기 URL	미지원	지원	지원

7. 어떤 서비스를 선택해야 할까?

GitHub Pages를 선택하면 좋은 경우 순수 HTML, CSS, JS로 만든 간단한 사이트, GitHub 저장소를 기반으로 문서나 포트폴리오를 만드는 경우, 추가 설정 없이 가장 간단하게 배포하고 싶을 때입니다.

Netlify를 선택하면 좋은 경우 폼 처리, 인증 같은 부가 기능이 필요한 경우, React, Vue, Gatsby 등 다양한 프레임워크를 사용하는 경우, 팀 협업 환경에서 PR 미리보기 기능을 활용하고 싶을 때입니다.

Vercel을 선택하면 좋은 경우 Next.js 프로젝트를 배포할 때, API Routes 같은 서버리스 기능이 필요할 때, 가장 빠른 빌드·배포 속도를 원할 때입니다.

8. 정리 및 마무리

오늘 배운 핵심을 정리합니다.

포트폴리오, 블로그, 랜딩 페이지 같은 정적 사이트는 직접 서버를 운영하지 않아도 무료로 배포할 수 있습니다.
GitHub Pages는 가장 간단하고 GitHub과 완벽하게 통합됩니다.
Netlify는 자동 배포, 롤백, 폼 처리 등 편리한 부가 기능이 강점입니다.
Vercel은 Next.js와의 완벽한 호환성과 빠른 속도가 강점입니다.
세 서비스 모두 HTTPS와 커스텀 도메인을 무료로 지원합니다.

내부 네트워크와 외부 네트워크의 차이 – 192.168.x.x는 왜 접속이 안 될까

테크 한 스푼 — Fri, 29 May 2026 15:32:52 +0900

친구에게 내 서버 주소를 알려줬는데 접속이 안 된다?
내부 네트워크와 외부 네트워크란?
사설 IP 주소의 범위
NAT – 사설 IP가 인터넷과 통신하는 방법
포트 포워딩이란 무엇인가?
클라우드 서버와 공인 IP
자주 발생하는 접속 문제와 해결법
정리 및 다음 단계

1. 친구에게 내 서버 주소를 알려줬는데 접속이 안 된다?

처음 서버를 공부하다 보면 이런 상황이 생깁니다. 내 컴퓨터에서 서버를 실행하고 IP 주소를 확인해 보니 192.168.0.5 였습니다. 이 주소를 친구에게 알려줬더니 접속이 안 된다고 합니다.

또는 AWS에서 서버를 만들고 내부 IP를 브라우저에 입력했더니 접속이 안 되는 경험도 있을 수 있습니다.

이 모든 상황의 원인은 내부 네트워크와 외부 네트워크의 차이를 이해하지 못했기 때문입니다.

2. 내부 네트워크와 외부 네트워크란?

**내부 네트워크(Private Network)**는 특정 장소(집, 회사, 데이터센터)의 공유기나 라우터 안에서만 통용되는 네트워크입니다. 이 안에서 사용하는 IP 주소를 **사설 IP(Private IP)**라고 합니다.

**외부 네트워크(Public Network)**는 인터넷 전체를 의미합니다. 인터넷에서 사용하는 IP 주소를 **공인 IP(Public IP)**라고 하며, 전 세계에서 유일합니다.

집에서 공유기를 사용하면 이런 구조가 만들어집니다.

인터넷(외부) ↔ 공유기(공인 IP 보유) ↔ 내부 기기들(사설 IP 사용)

공유기는 외부 인터넷과 내부 기기들 사이의 중간 역할을 합니다. 내부 기기들은 사설 IP를 가지며, 공유기의 공인 IP를 공유해 인터넷에 접속합니다.

3. 사설 IP 주소의 범위

사설 IP로 사용하도록 예약된 IP 범위가 있습니다. 이 범위에 속하는 IP는 인터넷에서 직접 접속할 수 없습니다.

클래스범위주로 사용되는 곳

A 클래스	10.0.0.0 ~ 10.255.255.255	대기업, 클라우드 내부
B 클래스	172.16.0.0 ~ 172.31.255.255	중소 규모 네트워크
C 클래스	192.168.0.0 ~ 192.168.255.255	가정용 공유기

집에서 공유기를 사용하면 192.168.x.x 대역의 사설 IP를 받는 이유가 바로 이 때문입니다. AWS EC2의 내부 IP가 10.x.x.x 대역인 것도 같은 이유입니다.

4. NAT – 사설 IP가 인터넷과 통신하는 방법

사설 IP를 가진 기기가 인터넷에 접속할 수 있는 이유는 NAT(Network Address Translation) 덕분입니다.

NAT는 공유기나 라우터에서 동작하며, 내부 기기의 사설 IP를 공인 IP로 변환해 인터넷으로 내보내고, 응답이 돌아오면 다시 해당 사설 IP로 전달합니다.

동작 과정을 예로 들면, 내 컴퓨터(192.168.0.5)에서 구글에 접속 요청을 보내면 공유기가 이를 받아 공인 IP(예: 123.45.67.89)로 바꿔서 구글로 전송합니다. 구글의 응답이 123.45.67.89로 오면 공유기가 다시 192.168.0.5로 전달합니다.

이 과정 덕분에 여러 기기가 하나의 공인 IP를 공유해 인터넷을 사용할 수 있습니다.

5. 포트 포워딩이란 무엇인가?

외부에서 내부 네트워크의 특정 기기에 직접 접속하려면 포트 포워딩(Port Forwarding) 설정이 필요합니다.

포트 포워딩은 공유기에서 특정 포트로 들어오는 외부 요청을 내부 특정 기기로 전달하도록 설정하는 기능입니다.

예를 들어 집 컴퓨터(192.168.0.5)에서 웹 서버(80번 포트)를 운영하고 외부에서 접속하게 하려면 공유기 관리 페이지에서 다음과 같이 설정합니다.

외부 포트 80으로 들어오는 요청을 내부 IP 192.168.0.5의 80번 포트로 전달하도록 설정합니다.

이렇게 하면 외부에서 공유기의 공인 IP(123.45.67.89)로 접속하면 내부의 192.168.0.5 서버로 연결됩니다.

단, 가정용 인터넷은 공인 IP가 수시로 바뀌는 유동 IP인 경우가 많습니다. 안정적인 서버 운영을 위해서는 고정 IP를 신청하거나 클라우드 서버를 사용하는 것이 낫습니다.

6. 클라우드 서버와 공인 IP

AWS EC2, GCP 등 클라우드 서버를 사용하면 공인 IP가 별도로 제공됩니다. 이 공인 IP는 인터넷에서 직접 접근 가능합니다.

AWS EC2를 예로 들면, 인스턴스를 생성하면 내부 IP(10.x.x.x 대역)와 공인 IP(퍼블릭 IP) 두 가지가 할당됩니다.

내부 IP는 같은 VPC(Virtual Private Cloud) 내부에서만 사용합니다. 공인 IP는 인터넷에서 직접 접속할 때 사용합니다.

클라우드 서버에서 외부 접속이 안 될 때는 두 가지를 확인해야 합니다. 방화벽(UFW)에서 해당 포트가 열려 있는지, 그리고 클라우드의 보안 그룹(Security Group)에서 인바운드 규칙이 설정되어 있는지 확인합니다.

7. 자주 발생하는 접속 문제와 해결법

문제 1. 사설 IP를 외부 접속 주소로 알려준 경우 192.168.x.x나 10.x.x.x 주소는 외부에서 접속할 수 없습니다. 공인 IP를 확인해 알려줘야 합니다. 공인 IP는 "내 IP 확인"을 구글에서 검색하거나, AWS 콘솔에서 퍼블릭 IP를 확인합니다.

문제 2. 클라우드 서버에서 포트는 열었지만 접속이 안 되는 경우 UFW 방화벽과 클라우드 보안 그룹(Security Group) 두 가지 모두를 확인해야 합니다. 둘 중 하나라도 막혀 있으면 접속이 안 됩니다.

문제 3. 공인 IP가 바뀌어 도메인 접속이 안 되는 경우 클라우드 서버의 IP는 재시작 시 바뀔 수 있습니다. AWS에서는 **탄력적 IP(Elastic IP)**를 할당하면 서버를 재시작해도 IP가 유지됩니다.

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

**사설 IP(192.168.x.x, 10.x.x.x 등)**는 내부 네트워크에서만 사용 가능하며 외부 인터넷에서 직접 접속할 수 없습니다.
공인 IP는 인터넷에서 유일하며 외부에서 직접 접속 가능합니다.
NAT를 통해 여러 기기가 하나의 공인 IP를 공유해 인터넷을 사용합니다.
외부에서 내부 기기에 접속하려면 포트 포워딩 설정이 필요합니다.
클라우드 서버 접속이 안 될 때는 UFW와 보안 그룹 두 가지를 모두 확인합니다.

다음 글에서는 서버 없이 웹사이트를 배포하는 방법, GitHub Pages와 Netlify, Vercel 비교를 알아보겠습니다.

서버 백업을 자동화하는 가장 쉬운 방법 – rsync와 cron 활용

테크 한 스푼 — Fri, 29 May 2026 09:04:02 +0900

백업하지 않으면 언젠가 반드시 후회한다
무엇을 백업해야 하는가?
rsync란 무엇인가?
rsync로 로컬 백업하기
rsync로 원격 서버에 백업하기
cron으로 백업 자동화하기
데이터베이스 백업 자동화
백업 보존 기간 관리하기
정리 및 다음 단계

1. 백업하지 않으면 언젠가 반드시 후회한다

서버 운영자들 사이에는 이런 말이 있습니다. "백업을 하는 사람과, 아직 데이터를 잃어본 적 없는 사람만 있다"고요.

디스크 고장, 실수로 인한 파일 삭제, 랜섬웨어 감염, 서버 제공업체의 장애 등 예상치 못한 이유로 데이터가 사라지는 일은 언제든 일어날 수 있습니다. 이런 상황에서 유일한 해결책은 미리 만들어둔 백업입니다.

2. 무엇을 백업해야 하는가?

반드시 백업해야 할 항목으로는 웹 서비스의 업로드 파일(/var/www/html 등), 데이터베이스 데이터, 환경 설정 파일(/etc 디렉토리 주요 설정), 애플리케이션 소스 코드(GitHub 연동이 없는 경우), SSL 인증서 파일이 있습니다.

보안 전문가들이 권장하는 3-2-1 규칙은 데이터 사본 3개 유지, 2가지 서로 다른 저장 매체 사용, 1개는 외부(오프사이트)에 보관하는 방식입니다. 예를 들어 원본 서버, 다른 서버의 백업, 클라우드 스토리지(S3 등) 세 곳에 보관하는 식입니다.

3. rsync란 무엇인가?

**rsync(Remote Sync)**는 파일과 디렉토리를 효율적으로 동기화하고 복사하는 리눅스 도구입니다. 전체 파일을 매번 복사하는 것이 아니라 변경된 부분만 전송하기 때문에 빠르고 효율적입니다. SSH를 통해 원격 서버로 안전하게 전송하며, 대용량 파일 전송이 중단됐을 때 이어서 전송하는 기능도 지원합니다.

4. rsync로 로컬 백업하기

같은 서버 내에서 특정 디렉토리를 다른 위치로 백업하는 기본 형태입니다.

rsync -av 원본경로 목적지경로

/var/www/html 디렉토리를 /backup/www로 백업하는 예시입니다.

rsync -av /var/www/html/ /backup/www/

-a는 권한·소유자·타임스탬프 등 모든 속성을 유지하는 아카이브 모드이고, -v는 진행 상황을 화면에 출력합니다. 원본에서 삭제된 파일을 백업 디렉토리에서도 삭제하려면 --delete 옵션을 추가합니다.

rsync -av --delete /var/www/html/ /backup/www/

5. rsync로 원격 서버에 백업하기

다른 서버로 백업을 전송할 때는 SSH를 통해 rsync를 사용합니다.

rsync -avz -e ssh /var/www/html/ 사용자명@백업서버IP:/backup/www/

-z는 전송 중 데이터를 압축해 속도를 높입니다. SSH 키 파일을 사용하는 경우 -e 옵션에 키 파일 경로를 지정합니다.

rsync -avz -e "ssh -i ~/.ssh/backup_key.pem" /var/www/html/ ubuntu@백업서버IP:/backup/www/

6. cron으로 백업 자동화하기

rsync 명령어를 cron에 등록하면 정기적으로 자동 백업이 실행됩니다. 먼저 백업 스크립트 파일을 만듭니다.

nano /home/ubuntu/scripts/backup.sh

스크립트 내용을 작성합니다.

#!/bin/bash
DATE=$(date +%Y%m%d)
rsync -avz /var/www/html/ /backup/www_$DATE/
echo "Backup completed: $DATE"

스크립트에 실행 권한을 부여하고 crontab에 등록합니다.

chmod +x /home/ubuntu/scripts/backup.sh
crontab -e

매일 새벽 3시에 실행하도록 아래 줄을 추가합니다.

0 3 * * * /home/ubuntu/scripts/backup.sh >> /var/log/backup.log 2>&1

7. 데이터베이스 백업 자동화

데이터베이스는 파일 백업과 별도로 진행해야 합니다. MySQL 백업 스크립트 파일을 만들고 아래 내용을 작성합니다.

#!/bin/bash
DATE=$(date +%Y%m%d_%H%M%S)
mysqldump -u root -p비밀번호 --all-databases > /backup/db_$DATE.sql
gzip /backup/db_$DATE.sql

비밀번호를 명령어에 직접 쓰는 대신 ~/.my.cnf 파일에 자격증명을 저장하는 것이 보안상 더 안전합니다.

[client]
user=root
password=비밀번호

이렇게 설정하면 이후 mysqldump --all-databases처럼 비밀번호 없이 실행할 수 있습니다.

8. 백업 보존 기간 관리하기

매일 백업을 만들면 시간이 지날수록 디스크가 가득 찹니다. 30일 이상 된 백업 파일을 자동 삭제하는 명령어를 cron에 등록합니다.

0 4 * * * find /backup -name "*.sql.gz" -mtime +30 -delete

9. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

rsync는 변경된 파일만 전송하는 효율적인 백업 도구입니다.
rsync와 cron을 조합하면 정기 자동 백업 시스템을 구축할 수 있습니다.
파일 백업과 데이터베이스 백업은 별도로 진행합니다.
3-2-1 규칙에 따라 3곳 이상에 백업을 보관하는 것이 이상적입니다.
오래된 백업은 자동 삭제 정책을 설정해 디스크 낭비를 방지합니다.

다음 글에서는 내부 네트워크와 외부 네트워크의 차이를 알아보겠습니다.

리눅스 프로세스 백그라운드 실행 방법 – nohup과 & 차이 정리

테크 한 스푼 — Thu, 28 May 2026 22:14:47 +0900

SSH를 끊으면 실행 중이던 프로그램이 꺼진다?
포그라운드와 백그라운드의 차이
& 기호로 백그라운드 실행하기
nohup이란 무엇인가?
nohup과 &를 함께 사용하는 방법
실행 중인 백그라운드 프로세스 관리하기
PM2 – Node.js 앱을 위한 더 나은 방법
정리 및 다음 단계

1. SSH를 끊으면 실행 중이던 프로그램이 꺼진다?

서버에 SSH로 접속해서 Python 스크립트나 Node.js 앱을 실행했는데, SSH 연결을 끊는 순간 실행 중이던 프로그램도 함께 종료되는 경험을 해본 적 있으신가요?

이것은 리눅스의 정상적인 동작입니다. SSH 세션이 종료되면 해당 세션에서 실행된 모든 프로세스에 종료 신호(SIGHUP)가 전달되어 함께 종료됩니다. 서버에서 프로그램을 장시간 실행해야 하는 경우에는 nohup과 & 를 활용해야 합니다.

2. 포그라운드와 백그라운드의 차이

포그라운드(Foreground) 실행은 일반적으로 명령어를 실행했을 때의 방식입니다. 프로그램이 실행되는 동안 터미널이 점유되어 다른 명령어를 입력할 수 없습니다.

백그라운드(Background) 실행은 프로그램이 뒤에서 실행되면서 터미널은 즉시 다음 명령어를 받을 수 있는 상태가 됩니다. 여러 작업을 동시에 실행할 수 있습니다.

3. & 기호로 백그라운드 실행하기

명령어 맨 끝에 &를 붙이면 백그라운드로 실행됩니다.

python3 server.py &

실행하면 PID가 출력되고 즉시 터미널 제어권이 돌아옵니다. 단, &만으로는 SSH 세션이 종료될 때 프로세스도 함께 종료됩니다.

4. nohup이란 무엇인가?

**nohup(no hangup)**은 SSH 세션이 종료될 때 전달되는 SIGHUP 신호를 무시하도록 프로세스를 실행하는 명령어입니다. nohup을 사용하면 SSH 연결이 끊겨도 프로세스가 계속 실행되며, 표준 출력이 자동으로 nohup.out 파일에 저장됩니다.

기본 사용법은 아래와 같습니다.

nohup python3 server.py

이렇게 실행하면 SSH를 끊어도 프로세스가 살아있지만, 터미널이 여전히 점유됩니다.

5. nohup과 &를 함께 사용하는 방법

실전에서는 nohup과 &를 함께 사용하는 것이 일반적입니다. nohup으로 세션 종료 신호를 무시하고, &로 백그라운드 실행까지 결합합니다.

nohup python3 server.py &

출력 로그를 특정 파일에 저장하고 싶다면 아래와 같이 리다이렉션을 추가합니다. 2>&1은 표준 오류(stderr)도 함께 로그 파일에 기록하라는 의미입니다.

nohup python3 server.py > /var/log/myapp.log 2>&1 &

6. 실행 중인 백그라운드 프로세스 관리하기

실행 중인 프로세스를 확인할 때는 ps aux와 grep을 조합합니다.

ps aux | grep python3

PID를 확인한 후 프로세스를 종료합니다.

kill 프로세스PID

강제 종료가 필요한 경우에는 -9 옵션을 추가합니다.

kill -9 프로세스PID

현재 세션의 백그라운드 작업 목록은 jobs 명령어로 확인하고, fg %작업번호로 포그라운드로 전환할 수 있습니다.

7. PM2 – Node.js 앱을 위한 더 나은 방법

Node.js 앱을 운영한다면 nohup 대신 PM2를 사용하는 것을 강력히 추천합니다. PM2는 Node.js 앱 전용 프로세스 매니저로, 앱이 오류로 종료되면 자동 재시작, 로그 관리, 클러스터 모드 등 다양한 기능을 제공합니다.

PM2를 전역으로 설치합니다.

npm install -g pm2

앱을 시작하고 재부팅 후 자동 시작을 등록합니다.

pm2 start app.js
pm2 startup
pm2 save

실행 중인 앱 목록 확인과 실시간 로그 확인은 아래 명령어를 사용합니다.

pm2 list
pm2 logs

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

SSH 세션이 종료되면 해당 세션의 프로세스도 함께 종료됩니다.
&를 붙이면 백그라운드 실행이 가능하지만, SSH 종료 시 함께 종료됩니다.
nohup은 SSH 종료 신호를 무시해 세션이 끊겨도 프로세스가 유지됩니다.
실전에서는 nohup 명령어 & 형태로 두 가지를 함께 사용합니다.
Node.js 앱이라면 PM2를 사용하는 것이 훨씬 편리하고 안정적입니다.

다음 글에서는 서버 백업을 자동화하는 가장 쉬운 방법을 알아보겠습니다.

환경변수란 무엇인가 – 서버에서 비밀번호를 코드에 넣으면 안 되는 이유

테크 한 스푼 — Thu, 28 May 2026 15:43:57 +0900

1. 코드에 비밀번호를 직접 쓰면 생기는 일

개발을 처음 배울 때 아래처럼 데이터베이스 비밀번호를 코드에 직접 넣는 경우가 많습니다.

const db = mysql.connect({
  host: 'localhost',
  user: 'root',
  password: 'mypassword123'
});

이 코드를 GitHub에 올리면 공개 저장소라면 전 세계 누구나 비밀번호를 볼 수 있습니다. 비공개 저장소라도 실수로 공개로 바꾸는 순간 노출됩니다. 실제로 GitHub에 올라간 AWS 액세스 키나 데이터베이스 비밀번호가 수분 내에 악용되는 사례가 빈번하게 발생합니다.

이 문제를 해결하는 방법이 바로 환경변수입니다.

2. 환경변수란 무엇인가?

**환경변수(Environment Variable)**는 운영체제 수준에서 저장되는 키-값 쌍의 변수입니다. 프로그램이 실행될 때 이 변수를 읽어서 사용할 수 있기 때문에, 민감한 정보를 코드에 직접 쓰지 않고 외부에서 주입할 수 있습니다.

쉬운 비유로 설명하면, 환경변수는 배우가 대사를 말하기 전에 스태프에게 전달받는 쪽지와 같습니다. 대본(코드)에는 "비밀번호 입력" 자리만 표시해두고, 실제 비밀번호는 공연 직전 별도로 전달받는 방식입니다.

3. 리눅스에서 환경변수 사용하는 방법

현재 설정된 모든 환경변수를 확인하려면 아래 명령어를 사용합니다.

printenv

특정 환경변수 값만 확인할 때는 변수명 앞에 $를 붙입니다.

echo $HOME

환경변수를 현재 세션에만 임시로 설정할 때는 export를 사용합니다. 터미널을 닫으면 사라집니다.

export DB_PASSWORD=mypassword123

영구적으로 설정하려면 ~/.bashrc 파일을 열어 맨 아래에 추가합니다.

sudo nano ~/.bashrc

파일 안에 아래와 같이 작성하고 저장합니다.

export DB_PASSWORD=mypassword123
export DB_HOST=localhost

저장 후 변경 사항을 즉시 적용합니다.

source ~/.bashrc

4. .env 파일로 환경변수 관리하기

여러 개의 환경변수를 관리할 때는 .env 파일을 사용하는 것이 일반적입니다. 프로젝트 루트 디렉토리에 .env 파일을 만들고 아래와 같이 작성합니다.

DB_HOST=localhost
DB_USER=root
DB_PASSWORD=mypassword123
DB_NAME=myapp
SECRET_KEY=mysecretkey
AWS_ACCESS_KEY=AKIAXXXXXXXX

Node.js에서는 dotenv 패키지를 사용해 .env 파일을 읽어옵니다.

require('dotenv').config();
const dbPassword = process.env.DB_PASSWORD;

이렇게 하면 코드 어디에도 실제 비밀번호가 들어가지 않습니다.

5. 환경변수를 절대 GitHub에 올리면 안 되는 이유

.env 파일에 민감한 정보를 모아뒀다면, 이 파일이 GitHub에 올라가지 않도록 반드시 .gitignore 파일에 추가해야 합니다. .gitignore 파일에 아래 줄을 추가합니다.

.env
.env.local
.env.production

이미 GitHub에 .env 파일을 올렸다면 단순히 파일을 삭제한다고 해결되지 않습니다. Git은 커밋 히스토리를 보존하기 때문에, 이전 커밋을 통해 내용을 볼 수 있습니다. 이 경우 해당 비밀번호와 키를 즉시 변경해야 합니다.

6. 서비스별 환경변수 설정 방법

systemd로 관리하는 서비스에 환경변수를 주입할 때는 서비스 파일을 편집합니다.

sudo systemctl edit 서비스명

편집기가 열리면 아래 형태로 추가합니다.

[Service]
Environment="DB_PASSWORD=mypassword123"
Environment="SECRET_KEY=mysecretkey"

AWS를 사용한다면 Parameter Store나 Secrets Manager를 활용하면 환경변수를 더 안전하게 저장하고 관리할 수 있습니다. 팀 단위 프로젝트라면 이런 클라우드 서비스를 활용하는 것이 더 안전합니다.

7. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

환경변수는 코드 외부에서 민감한 정보를 프로그램에 전달하는 방법입니다.
데이터베이스 비밀번호, API 키 같은 민감한 정보는 절대 코드에 직접 써서는 안 됩니다.
.env 파일에 환경변수를 모아 관리하고, 반드시 .gitignore에 추가해 GitHub에 올라가지 않도록 합니다.
이미 GitHub에 올렸다면 해당 비밀번호와 키를 즉시 변경해야 합니다.

다음 글에서는 리눅스 프로세스 백그라운드 실행 방법 – nohup과 & 차이를 알아보겠습니다.

서버 타임존과 시간 동기화 문제 – 로그 시간이 이상할 때 해결법

테크 한 스푼 — Thu, 28 May 2026 10:01:51 +0900

1. 로그 시간이 9시간 어긋난다면?

서버 로그를 확인하다 보면 실제 발생 시간과 로그에 기록된 시간이 9시간 차이가 나는 경우가 있습니다. 오전 10시에 발생한 오류인데 로그에는 새벽 1시로 기록되어 있는 식입니다.

이 문제의 원인은 서버의 타임존이 한국 시간(KST)이 아닌 UTC로 설정되어 있기 때문입니다. UTC와 KST의 차이가 정확히 +9시간이기 때문에 이런 현상이 생깁니다.

타임존 설정은 단순히 로그 시간 문제뿐 아니라, 데이터베이스에 저장되는 날짜·시간 데이터, cron 작업의 실행 시간, SSL 인증서 유효성 검사 등 여러 곳에 영향을 미칩니다.

2. 타임존이란 무엇인가?

**타임존(Time Zone)**은 지역별 표준 시간대를 나타냅니다. 지구는 경도에 따라 시간이 다르기 때문에, 전 세계를 여러 구역으로 나누어 각 구역에 표준 시간을 지정합니다.

**UTC(협정 세계시)**는 국제 표준 기준 시간으로, 영국 그리니치 천문대를 기준으로 합니다. 대부분의 클라우드 서버는 기본적으로 UTC 타임존으로 설정됩니다.

**KST(한국 표준시)**는 UTC보다 9시간 빠릅니다. 리눅스에서는 Asia/Seoul로 표기합니다.

3. 서버 타임존 확인 및 변경하기

현재 서버의 타임존을 확인합니다.

timedatectl

출력 결과에서 Time zone 항목을 확인합니다. UTC로 표시된다면 변경이 필요합니다. 사용 가능한 타임존 목록 중 Asia 관련 항목을 검색하려면 아래 명령어를 사용합니다.

timedatectl list-timezones | grep Asia

타임존을 서울로 변경합니다.

sudo timedatectl set-timezone Asia/Seoul

변경 후 다시 timedatectl로 확인했을 때 Time zone: Asia/Seoul (KST, +0900)으로 표시되면 성공입니다.

타임존을 변경한 후에는 Nginx, MySQL 등 주요 서비스를 재시작해야 변경된 타임존이 해당 서비스에도 적용됩니다.

sudo systemctl restart nginx
sudo systemctl restart mysql

4. NTP란 무엇인가? – 서버 시간이 틀어지는 이유

타임존을 올바르게 설정했더라도, 서버의 시스템 시간 자체가 실제 시간과 조금씩 차이가 날 수 있습니다. 서버의 하드웨어 시계는 시간이 지나면서 오차가 누적되기 때문입니다.

이를 해결하기 위해 **NTP(Network Time Protocol)**를 사용합니다. NTP는 인터넷의 시간 서버와 주기적으로 동기화해 서버 시간을 정확하게 유지하는 프로토콜입니다.

현대 Ubuntu 서버는 systemd-timesyncd라는 내장 시간 동기화 서비스가 기본으로 활성화되어 있어 대부분의 경우 별도 설정 없이 자동으로 동기화됩니다.

5. 시간 동기화 상태 확인 및 설정

동기화 상태는 timedatectl 명령어로 확인합니다. 출력 결과에서 NTP service: active와 System clock synchronized: yes가 표시되면 정상적으로 동기화 중입니다.

동기화 서비스 상태를 별도로 확인하려면 아래 명령어를 사용합니다.

sudo systemctl status systemd-timesyncd

동기화가 안 될 때는 서비스를 재시작합니다.

sudo systemctl restart systemd-timesyncd

금융이나 로그 분석 등 시간 정확도가 중요한 서비스라면 chrony라는 더 정밀한 NTP 클라이언트를 사용합니다.

sudo apt install chrony -y
sudo systemctl enable chrony
sudo systemctl start chrony

설치 후 chronyc tracking 명령으로 동기화 상태를 확인할 수 있습니다.

6. 타임존 문제로 발생하는 실제 사례

사례 1. cron 작업이 엉뚱한 시간에 실행됨 "매일 오전 9시에 리포트 이메일 발송" cron을 설정했는데 UTC 기준으로 동작해 한국 시간 오후 6시에 발송되는 상황입니다. 타임존을 Asia/Seoul로 변경하면 해결됩니다.

사례 2. 데이터베이스의 날짜 데이터가 하루씩 밀림 MySQL의 타임존이 UTC로 설정된 상태에서 자정 이후 데이터를 저장하면 날짜가 하루 앞으로 기록되는 경우입니다. MySQL 설정에서 default_time_zone = '+09:00'을 추가해 해결합니다.

사례 3. SSL 인증서 유효성 오류 서버 시간이 실제 시간과 크게 차이 나면 SSL 인증서 유효성 검사가 실패할 수 있습니다. NTP 동기화로 해결할 수 있습니다.

7. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

클라우드 서버의 기본 타임존은 UTC이며, 국내 서비스라면 Asia/Seoul로 변경해야 합니다.
sudo timedatectl set-timezone Asia/Seoul 명령 하나로 타임존을 변경할 수 있습니다.
타임존 변경 후에는 관련 서비스를 재시작해야 적용됩니다.
NTP를 통한 시간 동기화로 서버 시간이 실제 시간과 차이 나지 않도록 유지합니다.
Ubuntu 서버는 systemd-timesyncd가 기본 활성화되어 있어 별도 설정 없이 동기화됩니다.

다음 글에서는 환경변수란 무엇인지, 서버에서 비밀번호를 코드에 넣으면 안 되는 이유를 알아보겠습니다.

리눅스 파일 권한(chmod, chown) 정복 – 777이 위험한 이유

테크 한 스푼 — Wed, 27 May 2026 21:32:42 +0900

Permission denied, 왜 이런 오류가 나는 걸까?
리눅스 파일 권한의 구조
권한을 숫자로 표현하는 방법
chmod – 파일 권한 변경하기
chown – 파일 소유자 변경하기
777 권한이 위험한 이유
실전에서 자주 쓰는 권한 설정 모음
정리 및 다음 단계

1. Permission denied, 왜 이런 오류가 나는 걸까?

리눅스 서버를 다루다 보면 Permission denied 오류를 자주 만나게 됩니다. 파일을 읽으려 하거나, 스크립트를 실행하거나, 특정 폴더에 파일을 생성하려 할 때 이 오류가 나타납니다.

이 오류의 원인은 대부분 파일 권한 설정 때문입니다. 리눅스는 파일과 폴더마다 누가 읽고, 쓰고, 실행할 수 있는지를 세밀하게 제어합니다. 이 개념을 이해하면 Permission denied 오류를 스스로 해결할 수 있습니다.

2. 리눅스 파일 권한의 구조

ls -al 명령어를 실행하면 파일 목록 앞에 -rwxr-xr-- 1 ubuntu www-data 1234 May 25 14:00 index.html 처럼 문자열이 표시됩니다. 맨 앞의 -rwxr-xr-- 부분이 바로 권한 정보입니다.

첫 번째 문자는 파일 종류를 나타냅니다. -는 일반 파일, d는 디렉토리, l은 심볼릭 링크입니다.

나머지 9자리는 3자리씩 세 그룹으로 나뉩니다.

위치문자의미

2~4번째 (rwx)	소유자(Owner) 권한	파일을 만든 사람
5~7번째 (r-x)	그룹(Group) 권한	같은 그룹에 속한 사람들
8~10번째 (r--)	기타(Other) 권한	그 외 모든 사람

각 자리의 문자 의미는 r은 읽기, w는 쓰기, x는 실행, -는 해당 권한 없음을 의미합니다.

따라서 rwxr-xr--는 소유자는 읽기·쓰기·실행 모두 가능, 그룹은 읽기·실행만 가능, 기타 사용자는 읽기만 가능이라는 의미입니다.

3. 권한을 숫자로 표현하는 방법

리눅스 권한은 숫자(8진수)로도 표현합니다. r=4, w=2, x=1로 계산하며, 세 값을 더해 권한을 표현합니다.

권한문자숫자

읽기+쓰기+실행	rwx	7
읽기+쓰기	rw-	6
읽기+실행	r-x	5
읽기만	r--	4
쓰기만	-w-	2
실행만	--x	1
권한 없음	---	0

세 그룹(소유자, 그룹, 기타)의 숫자를 이어 붙이면 최종 권한이 됩니다. 755는 소유자 rwx(7), 그룹 r-x(5), 기타 r-x(5)를 의미하고, 644는 소유자 rw-(6), 그룹 r--(4), 기타 r--(4)를 의미합니다.

4. chmod – 파일 권한 변경하기

**chmod(change mode)**는 파일이나 폴더의 권한을 변경하는 명령어입니다. 기본 형태는 다음과 같습니다.

chmod 권한숫자 파일명

index.html 파일을 소유자만 읽고 쓸 수 있게 설정하는 예시입니다.

chmod 644 index.html

스크립트 파일에 실행 권한을 추가할 때입니다.

chmod +x script.sh

폴더 내 모든 파일에 재귀적으로 권한을 적용하려면 -R 옵션을 사용합니다.

chmod -R 755 /var/www/html

5. chown – 파일 소유자 변경하기

**chown(change owner)**은 파일이나 폴더의 소유자와 그룹을 변경하는 명령어입니다. 기본 형태입니다.

sudo chown 소유자:그룹 파일명

index.html의 소유자를 ubuntu, 그룹을 www-data로 변경하는 예시입니다.

sudo chown ubuntu:www-data index.html

폴더 전체를 재귀적으로 변경할 때는 -R 옵션을 사용합니다.

sudo chown -R ubuntu:www-data /var/www/html

Nginx는 기본적으로 www-data 사용자 권한으로 실행됩니다. 웹 파일의 그룹을 www-data로 설정하면 Nginx가 파일을 읽을 수 있게 됩니다.

6. 777 권한이 위험한 이유

검색하다 보면 "Permission denied 오류 해결 방법"으로 chmod 777을 추천하는 글을 종종 볼 수 있습니다. 777은 소유자, 그룹, 기타 모두에게 읽기·쓰기·실행 권한을 부여하는 설정입니다.

문제는 "기타(other)"에 해당하는 모든 사람이 파일을 수정하고 실행할 수 있다는 점입니다. 서버에 악성 코드를 심거나, 중요한 파일을 덮어쓰거나, 설정 파일을 변조하는 것이 가능해집니다.

Permission denied 오류를 만났을 때 올바른 해결 방법은 777을 주는 것이 아니라, 필요한 사용자에게만 최소한의 권한을 부여하는 것입니다. 웹 파일의 올바른 권장 설정은 디렉토리 755, 파일 644입니다.

7. 실전에서 자주 쓰는 권한 설정 모음

웹 서버 파일에 권한 표준 설정을 적용할 때, 디렉토리에는 755, 파일에는 644를 각각 적용합니다.

sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;

SSH 개인키 파일은 반드시 소유자만 읽을 수 있어야 합니다.

chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh

스크립트 파일에 실행 권한을 부여할 때입니다.

chmod +x /home/ubuntu/scripts/backup.sh

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

리눅스 권한은 소유자, 그룹, 기타 세 그룹에 대해 읽기(r=4), 쓰기(w=2), 실행(x=1) 권한을 각각 설정합니다.
chmod로 권한을 변경하고, chown으로 소유자를 변경합니다.
777 권한은 보안상 매우 위험하며, 웹 디렉토리에는 절대 사용하면 안 됩니다.
일반적으로 디렉토리는 755, 파일은 644, SSH 키는 600이 권장 설정입니다.

다음 글에서는 서버 타임존과 시간 동기화 문제를 알아보겠습니다.

Nginx 리버스 프록시 설정하는 법 – 포트 없이 도메인으로 접속하기

테크 한 스푼 — Wed, 27 May 2026 13:57:50 +0900

포트 번호 없이 접속하고 싶다면
리버스 프록시란 무엇인가?
리버스 프록시가 필요한 이유
Nginx 리버스 프록시 설정하기
여러 서비스를 도메인으로 분기하는 방법
리버스 프록시에 HTTPS 적용하기
자주 발생하는 오류와 해결법
정리 및 다음 단계

1. 포트 번호 없이 접속하고 싶다면

Node.js로 만든 웹 앱을 서버에 올리면 보통 3000번 포트에서 실행됩니다. 이때 브라우저에서 접속하려면 myblog.com:3000처럼 포트 번호를 직접 입력해야 합니다.

하지만 실제 서비스에서 포트 번호를 노출하는 것은 보기에도 좋지 않고 보안상으로도 좋지 않습니다. 사용자가 그냥 myblog.com만 입력해도 접속할 수 있게 하려면 리버스 프록시 설정이 필요합니다.

2. 리버스 프록시란 무엇인가?

**리버스 프록시(Reverse Proxy)**는 클라이언트의 요청을 받아 내부 서버로 전달하고, 응답을 다시 클라이언트에게 돌려주는 중간 서버입니다.

쉬운 비유로 설명하면, 리버스 프록시는 회사 안내 데스크와 같습니다. 외부 방문객(사용자)이 회사(서버)에 오면 안내 데스크(Nginx)가 먼저 맞이하고, 방문 목적에 따라 적절한 부서(실제 앱 서버)로 안내해 줍니다. 방문객은 어느 부서로 연결되는지 알 필요가 없습니다.

포워드 프록시와 리버스 프록시를 간단히 비교하면 다음과 같습니다.

구분포워드 프록시리버스 프록시

위치	클라이언트 앞	서버 앞
역할	클라이언트 대신 요청	서버 대신 응답
대표 용도	VPN, 익명성 보호	로드밸런싱, 포트 숨기기

3. 리버스 프록시가 필요한 이유

포트 번호 숨기기: 사용자에게 3000, 8080 같은 포트 번호를 노출하지 않고 80, 443 포트로만 접속하게 할 수 있습니다.

HTTPS 일괄 적용: Nginx 앞단에서 SSL 처리를 하면 내부 앱은 HTTP로 통신하더라도 사용자에게는 HTTPS로 제공할 수 있습니다.

하나의 서버에서 여러 서비스 운영: 포트나 서브도메인으로 요청을 분기해 여러 앱을 하나의 서버에서 운영할 수 있습니다.

보안 강화: 실제 앱 서버의 존재를 숨기고 Nginx가 먼저 요청을 필터링합니다.

4. Nginx 리버스 프록시 설정하기

Node.js 앱이 3000번 포트에서 실행 중이라고 가정하겠습니다. myblog.com으로 접속하면 이 앱으로 연결되도록 설정합니다.

먼저 Nginx 사이트 설정 파일을 만듭니다.

sudo nano /etc/nginx/sites-available/myblog

편집기가 열리면 아래 설정 내용을 입력합니다. server_name에는 본인의 도메인을 입력하고, proxy_pass에는 앱이 실행 중인 내부 포트를 지정합니다.

server {
    listen 80;
    server_name myblog.com www.myblog.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

설정 파일을 sites-enabled에 연결해 활성화합니다.

sudo ln -s /etc/nginx/sites-available/myblog /etc/nginx/sites-enabled/

설정 파일 문법에 오류가 없는지 검사합니다.

sudo nginx -t

이상이 없으면 Nginx에 설정을 반영합니다.

sudo systemctl reload nginx

이제 myblog.com으로 접속하면 포트 번호 없이 Node.js 앱에 연결됩니다.

5. 여러 서비스를 도메인으로 분기하는 방법

하나의 서버에서 여러 앱을 운영할 때, 서브도메인으로 각 서비스를 분기할 수 있습니다. 예를 들어 blog.myblog.com은 3000번 포트 앱으로, api.myblog.com은 4000번 포트 앱으로 연결하는 방법입니다.

blog.myblog.com 설정 파일을 만듭니다.

sudo nano /etc/nginx/sites-available/blog

아래 설정을 입력합니다.

server {
    listen 80;
    server_name blog.myblog.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

api.myblog.com 설정 파일도 동일한 방식으로 만들고, proxy_pass 주소만 http://localhost:4000으로 변경합니다. 각 설정 파일을 sites-enabled에 연결하고 Nginx를 재시작하면 됩니다.

6. 리버스 프록시에 HTTPS 적용하기

리버스 프록시 설정 후 Certbot으로 HTTPS를 적용하면 자동으로 80번 설정을 443으로 전환해 줍니다.

sudo certbot --nginx -d myblog.com -d www.myblog.com

Certbot이 Nginx 설정 파일을 자동으로 수정하고 SSL 인증서를 적용합니다. 이후 http://로 접속하면 자동으로 https://로 리다이렉트됩니다.

7. 자주 발생하는 오류와 해결법

502 Bad Gateway 오류 Nginx가 연결하려는 내부 앱(localhost:3000)이 실행되지 않고 있을 때 발생합니다. Node.js 앱이 정상적으로 실행 중인지 먼저 확인합니다.

설정 파일 적용이 안 될 때 sites-available에 파일을 만들었어도 sites-enabled에 링크를 걸지 않으면 적용되지 않습니다. ln -s 명령으로 심볼릭 링크를 만들었는지 확인합니다.

Permission denied 오류 Nginx가 내부 소켓 파일에 접근할 수 없는 경우입니다. 앱이 유닉스 소켓을 사용한다면 파일 권한을 확인합니다.

8. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

리버스 프록시는 Nginx가 외부 요청을 받아 내부 앱 서버로 전달하는 구조입니다.
proxy_pass 설정으로 특정 도메인 요청을 내부 포트로 연결할 수 있습니다.
서브도메인별로 설정 파일을 만들어 여러 서비스를 하나의 서버에서 운영할 수 있습니다.
Certbot과 함께 사용하면 HTTPS까지 자동으로 적용됩니다.

다음 글에서는 리눅스 파일 권한(chmod, chown) 에 대해 알아보겠습니다.

서버에서 swap 메모리란 무엇인지, 언제 설정해야 하나

테크 한 스푼 — Wed, 27 May 2026 13:45:14 +0900

1. 서버가 갑자기 느려졌다면 메모리를 의심하라

월 몇 천 원짜리 저사양 클라우드 서버(1GB RAM)를 운영하다 보면 메모리가 부족한 상황이 자주 발생합니다. Nginx, Node.js, MySQL을 동시에 띄우면 어느 순간 서버가 극도로 느려지거나 프로세스가 강제 종료되는 현상이 나타납니다.

이럴 때 서버 용량을 업그레이드하기 전에 먼저 고려해볼 수 있는 것이 바로 swap 메모리 설정입니다.

2. swap 메모리란 무엇인가?

swap은 물리적인 RAM이 부족할 때 하드디스크(또는 SSD)의 일부 공간을 임시 메모리처럼 사용하는 기술입니다.

쉬운 비유로 설명하면 이렇습니다. 책상(RAM)이 가득 찼을 때 자주 쓰지 않는 물건을 바닥(디스크)에 내려놓고 공간을 확보하는 것입니다. 바닥에서 물건을 꺼내는 것이 책상에서 꺼내는 것보다 느리듯, swap은 RAM보다 속도가 훨씬 느립니다.

그럼에도 불구하고 swap이 있으면 메모리가 완전히 고갈됐을 때 서버가 즉시 다운되는 대신, 느리더라도 계속 동작할 수 있습니다.

3. swap의 장점과 단점

장점

메모리 부족으로 인한 서버 다운을 방지합니다. 저사양 서버에서 여러 서비스를 동시에 운영할 수 있습니다. 비용 없이 설정 가능하며, 급한 상황에서 즉각적인 완충 역할을 합니다.

단점

디스크를 메모리처럼 사용하기 때문에 RAM보다 수십 배에서 수백 배 느립니다. swap을 과도하게 사용하면 서버 전체가 심각하게 느려집니다. SSD를 swap으로 사용하면 SSD 수명이 단축될 수 있습니다.

swap은 근본적인 해결책이 아닙니다. 장기적으로는 RAM을 늘리거나 서버를 업그레이드하는 것이 맞지만, 단기 완충이나 가끔 발생하는 메모리 급증 상황 대응에는 효과적입니다.

4. swap이 필요한 상황

아래 상황 중 하나라도 해당된다면 swap 설정을 고려해볼 수 있습니다.

RAM이 1GB 이하인 저사양 서버를 운영 중일 때, free -h 명령어 실행 시 available 값이 자주 100MB 이하로 떨어질 때, OOM Killer가 프로세스를 종료하는 로그가 자주 발견될 때, 서버 비용을 늘리기 전에 임시로 버텨야 하는 상황일 때 swap이 유용합니다.

반대로 RAM이 넉넉하고 서버 성능이 충분하다면 swap을 굳이 설정할 필요는 없습니다.

5. swap 설정하는 방법 (Ubuntu 기준)

1단계. 현재 swap 상태를 확인합니다.

sudo swapon --show

아무것도 출력되지 않으면 swap이 설정되어 있지 않은 것입니다.

2단계. swap 파일을 생성합니다.

2GB 크기의 swap 파일을 생성하는 예시입니다. 서버 RAM의 1~2배 크기를 권장합니다.

sudo fallocate -l 2G /swapfile

3단계. swap 파일 권한을 설정합니다.

root만 읽고 쓸 수 있도록 권한을 제한합니다.

sudo chmod 600 /swapfile

4단계. swap 파일로 지정합니다.

sudo mkswap /swapfile

5단계. swap을 즉시 활성화합니다.

sudo swapon /swapfile

6단계. 서버 재부팅 후에도 swap이 유지되도록 등록합니다.

sudo nano /etc/fstab 파일을 열어 맨 아래에 다음 줄을 추가합니다.

/swapfile none swap sw 0 0

저장 후 free -h 명령어로 swap이 정상 설정됐는지 확인합니다. Swap 항목에 2.0G가 표시되면 성공입니다.

6. swap 사용량 확인 및 조정

swap 사용 현황은 free -h 또는 swapon --show 명령어로 확인합니다.

swappiness 설정

swappiness는 리눅스가 얼마나 적극적으로 swap을 사용할지 결정하는 값입니다. 0에서 100 사이의 값을 가지며, 기본값은 60입니다.

값이 높을수록 swap을 더 자주 사용하고, 낮을수록 RAM을 최대한 사용한 후에만 swap을 사용합니다. 서버 환경에서는 10~30 사이의 낮은 값을 권장합니다.

현재 swappiness 값을 확인합니다.

cat /proc/sys/vm/swappiness

swappiness를 10으로 변경합니다.

sudo sysctl vm.swappiness=10

재부팅 후에도 유지되게 하려면 /etc/sysctl.conf 파일에 vm.swappiness=10 줄을 추가합니다.

7. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

swap은 RAM이 부족할 때 디스크를 임시 메모리로 사용하는 기술입니다.
RAM보다 훨씬 느리지만, 서버 다운을 막아주는 완충 역할을 합니다.
1GB RAM 이하의 저사양 서버라면 1~2GB swap 설정을 권장합니다.
swappiness 값을 낮게 설정하면 RAM을 최대한 활용하고 swap은 최후의 수단으로 사용합니다.
swap은 임시방편이며, 근본 해결책은 RAM 증설입니다.

다음 글에서는 Nginx 리버스 프록시 설정 방법을 알아보겠습니다.

리눅스 cron으로 반복 작업 자동화하는 방법 – 초보편

테크 한 스푼 — Wed, 27 May 2026 13:44:22 +0900

1. 매번 직접 실행하는 게 귀찮다면?

서버를 운영하다 보면 주기적으로 반복해야 하는 작업들이 생깁니다. 매일 새벽 데이터베이스를 백업하거나, 매주 로그 파일을 정리하거나, 매시간 특정 스크립트를 실행하는 작업들입니다.

이런 작업을 매번 수동으로 실행하는 것은 번거롭고, 깜빡할 경우 문제가 생길 수 있습니다. 리눅스에는 이런 반복 작업을 자동으로 실행해주는 cron이라는 기능이 있습니다. 한 번만 설정해두면 지정한 시간에 알아서 실행됩니다.

2. cron이란 무엇인가?

cron은 리눅스에서 특정 명령어나 스크립트를 정해진 시간에 자동으로 실행해주는 스케줄러입니다. 윈도우의 작업 스케줄러와 비슷한 역할을 합니다.

cron 작업은 **crontab(cron table)**이라는 파일에 등록합니다. 각 사용자마다 별도의 crontab 파일을 가지며, 이 파일에 실행 시간과 명령어를 한 줄씩 작성합니다.

cron의 동작 원리는 간단합니다. 서버가 켜져 있는 동안 cron 데몬이 백그라운드에서 계속 실행되면서, 현재 시간이 crontab에 등록된 시간과 일치하면 해당 명령어를 자동으로 실행합니다.

3. crontab 문법 완전 이해하기

crontab의 각 줄은 다음 형식으로 작성합니다.

분 시 일 월 요일 실행할명령어

각 항목의 의미와 허용 범위는 다음과 같습니다.

항목범위설명

분	0~59	몇 분에 실행할지
시	0~23	몇 시에 실행할지
일	1~31	몇 일에 실행할지
월	1~12	몇 월에 실행할지
요일	0~7	무슨 요일에 실행할지 (0과 7은 일요일)

특수 문자를 활용하면 더 다양한 주기를 설정할 수 있습니다.

별표(*)는 "모든 값"을 의미합니다. 예를 들어 시 항목에 *를 쓰면 매시간을 의미합니다.

슬래시(/)는 "간격"을 의미합니다. */5는 "5마다"를 뜻합니다. 분 항목에 */5를 쓰면 5분마다 실행합니다.

쉼표(,)는 "여러 값"을 의미합니다. 1,15는 1일과 15일을 뜻합니다.

하이픈(-)은 "범위"를 의미합니다. 1-5는 1부터 5까지를 뜻합니다.

예시를 몇 가지 살펴보겠습니다.

매일 새벽 2시에 실행하려면 다음과 같이 작성합니다. 0 2 * * * 명령어

매주 월요일 오전 9시에 실행하려면 아래처럼 작성합니다. 0 9 * * 1 명령어

5분마다 실행하려면 다음과 같습니다. */5 * * * * 명령어

매월 1일 자정에 실행하려면 이렇게 씁니다. 0 0 1 * * 명령어

crontab 문법이 헷갈릴 때는 crontab.guru 사이트를 활용하면 시각적으로 확인할 수 있어 편리합니다.

4. crontab 등록하고 관리하는 방법

crontab 파일을 편집하려면 아래 명령어를 실행합니다.

crontab -e

처음 실행하면 편집기를 선택하는 화면이 나옵니다. nano가 가장 쉽기 때문에 nano를 선택합니다.

편집기가 열리면 원하는 cron 작업을 한 줄씩 추가하고 저장합니다. nano에서는 Ctrl + X → Y → Enter로 저장합니다.

현재 등록된 cron 목록을 확인하려면 아래 명령어를 사용합니다.

crontab -l

특정 사용자의 crontab을 확인하거나 수정하려면 -u 옵션을 사용합니다.

sudo crontab -u 사용자명 -l

모든 cron 작업을 삭제하려면 아래 명령어를 사용합니다. 실행 즉시 모든 작업이 삭제되므로 신중하게 사용해야 합니다.

crontab -r

5. 실전 예시 – 자주 쓰는 cron 설정 모음

예시 1. 매일 새벽 3시에 데이터베이스 백업 0 3 * * * mysqldump -u root -p비밀번호 데이터베이스명 > /backup/db_backup.sql

예시 2. 매주 일요일 자정에 로그 파일 압축 0 0 * * 0 gzip /var/log/nginx/access.log

예시 3. 매 10분마다 서버 상태 체크 스크립트 실행 */10 * * * * /home/ubuntu/scripts/check_server.sh

예시 4. 매월 1일 새벽 4시에 오래된 임시 파일 삭제 0 4 1 * * find /tmp -type f -mtime +30 -delete

예시 5. 서버 재부팅 후 자동으로 특정 스크립트 실행 @reboot /home/ubuntu/scripts/start_services.sh

@reboot는 특수 키워드로, 서버가 재부팅될 때마다 해당 명령어를 실행합니다.

6. cron이 실행되지 않을 때 확인하는 방법

cron을 등록했는데 실행이 안 된다면 아래 순서로 확인합니다.

1단계. cron 서비스가 실행 중인지 확인합니다.

sudo systemctl status cron

active (running) 상태가 아니라면 sudo systemctl start cron으로 시작합니다.

2단계. cron 실행 로그를 확인합니다.

grep CRON /var/log/syslog

cron이 실행됐는지, 오류가 있는지 로그에서 확인할 수 있습니다.

3단계. 명령어 경로를 절대 경로로 작성했는지 확인합니다.

cron은 일반 터미널과 환경이 다르기 때문에, 상대 경로나 별칭(alias)이 인식되지 않는 경우가 많습니다. 명령어와 파일 경로는 반드시 절대 경로(/usr/bin/python3 등)로 작성해야 합니다.

4단계. 스크립트 파일에 실행 권한이 있는지 확인합니다.

실행할 스크립트 파일에 실행 권한이 없으면 cron이 실행해도 아무 일도 일어나지 않습니다. chmod +x 스크립트파일명 으로 실행 권한을 부여합니다.

7. 정리 및 다음 단계

오늘 배운 핵심을 정리합니다.

cron은 리눅스에서 반복 작업을 자동으로 실행해주는 스케줄러입니다.
crontab 형식은 분 시 일 월 요일 명령어 순서로 작성합니다.
crontab -e로 작업을 등록하고, crontab -l로 목록을 확인합니다.
cron 명령어는 반드시 절대 경로로 작성하고, 스크립트에 실행 권한을 부여해야 합니다.
실행이 안 될 때는 /var/log/syslog에서 CRON 관련 로그를 확인합니다.

다음 글에서는 서버에서 swap 메모리란 무엇인지, 언제 설정해야 하는지 알아보겠습니다.

공용 와이파이 사용할 때 꼭 알아야 할 보안 수칙

테크 한 스푼 — Mon, 25 May 2026 17:58:50 +0900

카페 와이파이, 정말 위험한가?
공용 와이파이에서 발생하는 주요 보안 위협
보안 수칙 1 – HTTPS 사이트만 이용하기
보안 수칙 2 – VPN 사용하기
보안 수칙 3 – 자동 연결 기능 해제
보안 수칙 4 – 민감한 작업은 공용 와이파이에서 하지 않기
보안 수칙 5 – 파일 공유 및 에어드롭 비활성화
보안 수칙 6 – 개인 핫스팟 활용하기
내 서버를 공용 와이파이 환경에서 관리할 때 주의사항
정리

1. 카페 와이파이, 정말 위험한가?

카페, 공항, 도서관, 호텔 등 공공장소에서 무료로 제공하는 와이파이를 일상적으로 사용하는 분들이 많습니다. 하지만 이런 공용 와이파이는 편리한 만큼 보안 위협에 매우 취약합니다.

같은 네트워크에 연결된 다른 사용자가 내 데이터를 가로챌 수 있고, 악의적인 사용자가 가짜 와이파이 핫스팟을 만들어 접속을 유도하는 경우도 있습니다. 이 글에서는 공용 와이파이를 어쩔 수 없이 사용해야 할 때 반드시 지켜야 할 보안 수칙을 정리했습니다.

2. 공용 와이파이에서 발생하는 주요 보안 위협

중간자 공격 (Man-in-the-Middle Attack) 같은 네트워크에 있는 공격자가 내 기기와 인터넷 사이에 끼어들어 데이터를 가로채는 공격입니다. HTTP 사이트를 이용할 경우 로그인 정보, 개인정보가 그대로 노출됩니다.

패킷 스니핑 (Packet Sniffing) 네트워크를 통해 오가는 데이터 패킷을 몰래 캡처하는 방법입니다. 암호화되지 않은 통신은 내용이 그대로 보입니다.

악성 핫스팟 (Evil Twin Attack) 공격자가 "카페_Free_WiFi"처럼 믿을 만한 이름의 가짜 와이파이를 만들어 사용자가 접속하도록 유도합니다. 이 네트워크에 연결되면 모든 트래픽이 공격자를 거쳐 지나가게 됩니다.

세션 하이재킹 로그인 후 유지되는 세션 쿠키를 탈취해 해당 계정에 무단 접속하는 공격입니다.

3. 보안 수칙 1 – HTTPS 사이트만 이용하기

공용 와이파이에서 가장 기본적인 보호 수단은 HTTPS가 적용된 사이트만 이용하는 것입니다. HTTPS는 모든 통신이 암호화되기 때문에, 중간자 공격이나 패킷 스니핑으로 데이터를 가로채도 내용을 해독할 수 없습니다.

브라우저 주소창에서 자물쇠 아이콘과 https://를 반드시 확인합니다. Chrome 브라우저는 설정에서 "항상 보안 연결 사용" 옵션을 켜두면 HTTP 사이트 접속 시 자동으로 경고를 표시합니다.

4. 보안 수칙 2 – VPN 사용하기

**VPN(Virtual Private Network)**은 내 기기와 VPN 서버 사이의 모든 트래픽을 암호화된 터널로 전송하는 기술입니다. 공용 와이파이에서 VPN을 사용하면 같은 네트워크의 다른 사용자가 내 트래픽을 볼 수 없습니다.

VPN은 공용 와이파이 보안을 위한 가장 강력한 수단입니다. 무료 VPN은 속도 제한이 있거나 보안이 취약한 경우가 있어, 신뢰할 수 있는 유료 VPN 서비스를 사용하는 것을 권장합니다. 대표적인 유료 VPN 서비스로는 NordVPN, ExpressVPN, ProtonVPN 등이 있습니다.

5. 보안 수칙 3 – 자동 연결 기능 해제

스마트폰이나 노트북은 기본적으로 이전에 연결했던 와이파이에 자동으로 접속하는 기능이 있습니다. 이 기능이 켜져 있으면 같은 이름의 가짜 와이파이에 자동으로 연결될 수 있습니다.

iPhone의 경우 설정 > Wi-Fi 에서 각 네트워크의 자동 연결 옵션을 끕니다.

Android의 경우 설정 > Wi-Fi > 저장된 네트워크에서 자동 연결을 비활성화합니다.

Windows의 경우 Wi-Fi 설정에서 각 네트워크의 "범위 안에 있을 때 자동으로 연결" 옵션을 해제합니다.

6. 보안 수칙 4 – 민감한 작업은 공용 와이파이에서 하지 않기

아무리 HTTPS를 사용하고 VPN을 켜도, 다음과 같은 민감한 작업은 가능하면 공용 와이파이에서 하지 않는 것이 좋습니다.

인터넷 뱅킹이나 금융 거래는 개인 핫스팟이나 모바일 데이터를 사용합니다. 업무용 시스템 접속이나 중요한 파일 전송도 마찬가지입니다. 새로운 계정 가입 시 비밀번호 설정도 공용 와이파이에서는 피하는 것이 좋습니다.

이러한 작업들은 잠깐 기다렸다가 안전한 환경에서 처리하는 것이 훨씬 안전합니다.

7. 보안 수칙 5 – 파일 공유 및 에어드롭 비활성화

공용 와이파이에 연결된 상태에서 파일 공유 기능이 켜져 있으면, 같은 네트워크의 다른 사람이 내 기기에 접근을 시도할 수 있습니다.

Windows의 경우 설정 > 네트워크 및 인터넷 > 네트워크 속성에서 "네트워크 검색 및 파일 공유 끄기"를 선택합니다.

Mac의 경우 시스템 설정 > 일반 > 공유에서 모든 공유 옵션을 비활성화합니다. AirDrop은 "모두에게 공개" 대신 "연락처만" 또는 "수신 안 함"으로 설정합니다.

8. 보안 수칙 6 – 개인 핫스팟 활용하기

보안이 중요한 작업을 해야 한다면 공용 와이파이 대신 스마트폰 개인 핫스팟을 사용하는 것이 가장 안전합니다.

개인 핫스팟은 이동통신사의 암호화된 모바일 데이터를 사용하기 때문에 공용 와이파이보다 훨씬 안전합니다. 4G/5G 환경에서는 속도도 충분히 빠릅니다. 데이터 요금이 걱정된다면 은행 업무, SSH 접속 같은 민감한 작업만 핫스팟으로 처리하고 나머지는 공용 와이파이를 사용하는 방식으로 절충할 수 있습니다.

9. 내 서버를 공용 와이파이 환경에서 관리할 때 주의사항

서버를 운영하는 분들은 공용 와이파이에서 SSH로 서버에 접속하는 경우가 있습니다. 이때 추가로 주의해야 할 사항이 있습니다.

반드시 SSH 키 인증을 사용합니다. 비밀번호 인증을 사용하면 중간자 공격으로 비밀번호가 노출될 수 있습니다. VPN을 켠 상태에서 SSH 접속을 합니다. SSH 접속 후에는 서버에서 중요한 파일을 수정하거나 보안 설정을 변경하는 작업을 피하는 것이 좋습니다. 접속이 끝나면 즉시 연결을 종료합니다.

10. 정리

공용 와이파이 사용 시 보안 수칙을 요약합니다.

수칙핵심 내용

HTTPS 확인	자물쇠 아이콘 확인 필수
VPN 사용	트래픽 전체 암호화
자동 연결 해제	가짜 핫스팟 접속 방지
민감한 작업 금지	금융·업무는 안전한 환경에서
파일 공유 비활성화	외부 접근 차단
개인 핫스팟 활용	중요 작업 시 모바일 데이터 사용

공용 와이파이는 완전히 신뢰할 수 없는 환경이라는 것을 항상 염두에 두고, 위 수칙을 습관처럼 지키는 것이 중요합니다.

SSL 인증서 무료로 발급받고 HTTPS 적용하는 법

테크 한 스푼 — Mon, 25 May 2026 17:58:10 +0900

1. HTTPS 적용, 이제는 선택이 아닌 필수

과거에는 SSL 인증서를 구매하는 데 연간 수십만 원이 들었습니다. 그래서 개인 블로그나 소규모 사이트는 HTTP를 그냥 쓰는 경우가 많았습니다.

하지만 지금은 상황이 완전히 달라졌습니다. Let's Encrypt 덕분에 SSL 인증서를 무료로 발급받을 수 있게 됐고, 구글은 HTTPS를 검색 랭킹 요소로 반영하고 있으며, 크롬 브라우저는 HTTP 사이트에 "안전하지 않음" 경고를 표시합니다.

이 글에서는 Ubuntu 서버에 Nginx가 설치된 환경을 기준으로, Let's Encrypt 인증서를 발급받고 HTTPS를 적용하는 전 과정을 단계별로 안내드립니다.

2. Let's Encrypt란 무엇인가?

Let's Encrypt는 모질라 재단 등이 지원하는 비영리 인증 기관(CA)으로, 누구에게나 무료로 SSL/TLS 인증서를 발급해 줍니다. 2016년 서비스 시작 이후 현재까지 수억 개의 인증서를 발급한 세계 최대 규모의 무료 인증 기관입니다.

Let's Encrypt 인증서의 특징은 다음과 같습니다. 완전 무료이며, 발급 과정이 자동화되어 있어 몇 가지 명령어만으로 설치가 완료됩니다. 유효 기간은 90일이지만 자동 갱신을 설정하면 만료 걱정 없이 사용할 수 있습니다. 모든 주요 브라우저에서 신뢰하는 인증서입니다.

3. 준비 사항 확인

SSL 인증서를 발급받기 전에 아래 조건이 갖춰져 있어야 합니다.

도메인 보유 필수 Let's Encrypt는 IP 주소가 아닌 도메인에 인증서를 발급합니다. 도메인이 없다면 먼저 도메인을 구입하고 서버 IP에 연결해야 합니다.

DNS 전파 완료 도메인이 서버 IP를 가리키도록 DNS 설정이 완료되고 전파까지 끝나야 합니다. 인증서 발급 과정에서 Let's Encrypt 서버가 도메인으로 접속을 시도해 소유권을 확인하기 때문입니다.

80번 포트 오픈 방화벽에서 80번 포트가 열려 있어야 합니다. 인증서 발급 시 HTTP를 통한 도메인 소유권 확인이 이루어집니다.

Nginx 실행 중 Nginx가 정상적으로 실행 중인 상태여야 합니다.

4. Certbot 설치하기

Certbot은 Let's Encrypt 인증서 발급을 자동화해주는 공식 도구입니다. Certbot을 사용하면 인증서 발급, Nginx 설정 수정, 자동 갱신까지 모두 처리해 줍니다.

먼저 패키지 목록을 업데이트합니다.

sudo apt update

Certbot과 Nginx 플러그인을 설치합니다.

sudo apt install certbot python3-certbot-nginx -y

설치가 완료되면 certbot --version 명령어로 정상 설치를 확인합니다.

5. SSL 인증서 발급 및 Nginx에 자동 적용

아래 명령어 하나로 인증서 발급과 Nginx 설정 자동 변경이 동시에 이루어집니다. 도메인 주소는 본인의 도메인으로 교체합니다.

sudo certbot --nginx -d 도메인주소 -d www.도메인주소

명령어를 실행하면 몇 가지 질문에 답해야 합니다.

첫 번째로 이메일 주소 입력을 요청합니다. 인증서 만료 알림과 보안 공지를 받을 이메일 주소를 입력합니다.

두 번째로 서비스 약관 동의 여부를 묻습니다. A를 입력해 동의합니다.

세 번째로 뉴스레터 수신 여부를 묻습니다. Y 또는 N 중 선택합니다.

마지막으로 HTTP로 접속했을 때 자동으로 HTTPS로 리다이렉트할지 묻습니다. 2번(Redirect)을 선택하면 http://로 접속해도 자동으로 https://로 이동하도록 설정됩니다.

Successfully deployed certificate 메시지가 나타나면 발급이 완료된 것입니다.

6. HTTPS 적용 확인하기

발급이 완료되면 브라우저에서 도메인에 접속해 확인합니다.

주소창에 자물쇠 아이콘이 표시되면 HTTPS가 정상 적용된 것입니다. http://로 접속했을 때 자동으로 https://로 이동하는지도 확인합니다.

SSL 적용 상태를 더 자세히 확인하려면 SSL Labs(ssllabs.com/ssltest)에서 도메인을 입력해 인증서 등급과 보안 설정을 점검할 수 있습니다. A 등급 이상이면 양호한 상태입니다.

7. 인증서 자동 갱신 설정

Let's Encrypt 인증서는 90일마다 갱신이 필요합니다. Certbot은 설치 시 자동으로 갱신 타이머를 등록하기 때문에 별도 작업 없이도 자동 갱신됩니다.

자동 갱신이 제대로 설정됐는지 확인합니다.

sudo systemctl status certbot.timer

active 상태이면 자동 갱신이 활성화된 것입니다.

실제로 갱신이 잘 되는지 테스트만 해보려면(실제 갱신 없이 시뮬레이션) 아래 명령어를 사용합니다.

sudo certbot renew --dry-run

Congratulations, all simulated renewals succeeded 메시지가 나오면 자동 갱신이 정상적으로 동작합니다.

8. 자주 발생하는 오류와 해결법

오류 1. Challenge failed – Could not connect to domain 도메인이 서버 IP를 올바르게 가리키고 있지 않거나, DNS 전파가 아직 완료되지 않은 경우입니다. DNS 설정을 다시 확인하고 전파가 완료된 후 다시 시도합니다.

오류 2. 80번 포트 연결 실패 방화벽에서 80번 포트가 차단되어 있는 경우입니다. sudo ufw allow 80 명령으로 포트를 열고 다시 시도합니다.

오류 3. Nginx 설정 오류 Certbot이 Nginx 설정을 수정하는 과정에서 기존 설정과 충돌이 발생한 경우입니다. sudo nginx -t 명령으로 설정 파일 문법을 확인하고, 오류가 있다면 수정 후 sudo systemctl reload nginx를 실행합니다.

오류 4. Too many certificates issued 같은 도메인에 짧은 시간 안에 너무 많은 인증서 발급을 시도한 경우입니다. Let's Encrypt는 도메인당 주당 5회 발급 제한이 있습니다. 잠시 기다린 후 다시 시도합니다.

9. 정리

오늘 배운 핵심을 정리합니다.

Let's Encrypt는 무료로 SSL 인증서를 발급해 주는 비영리 인증 기관입니다.
Certbot을 사용하면 명령어 몇 줄로 인증서 발급과 Nginx 설정을 자동으로 처리할 수 있습니다.
인증서 유효 기간은 90일이지만 Certbot의 자동 갱신 기능으로 별도 관리가 필요 없습니다.
발급 전 도메인 DNS 설정 완료, 80번 포트 오픈, Nginx 실행 여부를 반드시 확인합니다.

서버가 갑자기 다운됐을 때 원인 찾는 방법 정리

테크 한 스푼 — Mon, 25 May 2026 17:57:10 +0900

서버 다운, 당황하지 말자
1단계 – 서버가 살아있는지 확인
2단계 – 서비스 상태 확인
3단계 – 시스템 자원 확인 (CPU, 메모리, 디스크)
4단계 – 로그로 원인 추적하기
5단계 – 서버가 완전히 응답하지 않을 때
원인별 해결 방법 요약
재발 방지를 위한 체크리스트
정리

1. 서버 다운, 당황하지 말자

서버를 운영하다 보면 언젠가 반드시 다운 상황을 맞닥뜨립니다. 사이트에 갑자기 접속이 안 된다는 연락을 받거나, 모니터링 알림이 울리는 순간 머릿속이 하얘지는 경험은 서버를 다뤄본 사람이라면 누구나 겪어봤을 것입니다.

이런 상황에서 가장 중요한 것은 침착하게 순서대로 원인을 추적하는 것입니다. 원인도 모른 채 서버를 무작정 재부팅하면 일시적으로 복구될 수 있지만, 근본 원인을 해결하지 못해 같은 문제가 반복됩니다.

이 글에서는 서버가 다운됐을 때 단계별로 원인을 찾는 체계적인 방법을 알려드립니다.

2. 1단계 – 서버가 살아있는지 확인

가장 먼저 서버 자체가 살아있는지 확인합니다. 서비스 다운과 서버 자체 다운은 원인과 해결 방법이 완전히 다릅니다.

ping 테스트 내 컴퓨터에서 서버로 ping을 보내 네트워크 연결 여부를 확인합니다.

ping 서버IP주소

응답이 오면 서버는 살아있지만 특정 서비스가 죽은 것입니다. 응답이 없다면 서버 자체가 다운되었거나 네트워크 문제가 있는 것입니다.

SSH 접속 시도 ping이 돼도 SSH로 접속해 봅니다. SSH 접속이 되면 서버는 정상 동작 중이고, 특정 서비스에 문제가 생긴 것입니다. SSH도 안 된다면 서버 자체의 심각한 문제이므로 클라우드 서비스의 콘솔(웹 기반 원격 접속)을 사용해야 합니다.

3. 2단계 – 서비스 상태 확인

SSH 접속이 됐다면 서비스 상태를 확인합니다. 웹 서버가 응답하지 않는다면 Nginx 상태부터 확인합니다.

sudo systemctl status nginx

active (running) 상태가 아니라면 서비스가 죽은 것입니다. 로그를 확인해 왜 종료됐는지 파악해야 합니다.

sudo journalctl -u nginx -n 100

데이터베이스 서버도 함께 확인합니다.

sudo systemctl status mysql

4. 3단계 – 시스템 자원 확인 (CPU, 메모리, 디스크)

서비스 자체는 실행 중인데 응답이 느리거나 없다면 자원 부족이 원인일 수 있습니다.

CPU 사용량 확인 top 명령어를 실행해 CPU가 100%에 달해있는지 확인합니다. 특정 프로세스가 CPU를 독점하고 있다면 그것이 원인입니다.

top

메모리 확인 메모리가 부족하면 서버가 스왑 영역을 사용하게 되고, 이 경우 성능이 급격히 저하됩니다.

free -h

available 값이 거의 0에 가깝다면 메모리 부족이 원인입니다.

디스크 확인 디스크가 가득 차면 로그 기록, 파일 생성 등 모든 쓰기 작업이 실패합니다. 서버가 다운되는 가장 흔한 원인 중 하나입니다.

df -h

Use% 항목이 100%에 가깝다면 디스크 부족이 원인입니다. 로그 파일이나 임시 파일을 정리해야 합니다.

5. 4단계 – 로그로 원인 추적하기

자원이 정상인데도 서비스가 죽었다면 로그를 상세히 살펴봐야 합니다.

시스템 로그 확인 서버 전체에서 발생한 오류를 확인합니다.

sudo tail -n 100 /var/log/syslog

서비스별 오류 로그 확인

sudo tail -n 100 /var/log/nginx/error.log

OOM Killer 동작 여부 확인 메모리가 완전히 부족하면 리눅스 커널이 특정 프로세스를 강제 종료하는 **OOM Killer(Out of Memory Killer)**가 동작합니다. 이 경우 아래 명령어로 확인할 수 있습니다.

sudo dmesg | grep -i "killed process"

OOM Killer가 Nginx나 MySQL을 종료했다면 메모리 증설 또는 메모리 누수 해결이 필요합니다.

6. 5단계 – 서버가 완전히 응답하지 않을 때

SSH도 접속이 안 되고 ping도 안 된다면 서버 자체가 완전히 다운된 것입니다. 이 경우 클라우드 서비스의 관리 콘솔을 통해 대응합니다.

AWS EC2의 경우 AWS 콘솔에서 EC2 인스턴스 상태를 확인합니다. 인스턴스가 stopped 상태라면 Start 버튼으로 재시작합니다. 실행 중인데 응답이 없다면 인스턴스 재부팅(Reboot) 또는 강제 중지 후 시작(Stop → Start)을 시도합니다.

재시작 후에는 반드시 로그를 확인해 원인을 파악하고, 재발 방지 조치를 취해야 합니다.

7. 원인별 해결 방법 요약

원인증상해결 방법

서비스 비정상 종료	특정 서비스만 응답 없음	systemctl restart로 재시작
CPU 과부하	top에서 CPU 100%	원인 프로세스 확인 후 처리
메모리 부족	free에서 available 거의 0	불필요한 프로세스 종료, 메모리 증설
디스크 풀	df에서 Use% 100%	로그·임시파일 정리, 디스크 증설
OOM Killer 동작	dmesg에서 killed process	메모리 누수 해결, 메모리 증설
서버 자체 다운	ping, SSH 모두 불가	클라우드 콘솔에서 재시작

8. 재발 방지를 위한 체크리스트

서버를 복구한 후에는 반드시 재발 방지 조치를 취해야 합니다.

원인이 된 로그를 저장해두고 나중에 분석합니다. 디스크가 문제였다면 logrotate 설정을 점검하고 불필요한 파일을 정기적으로 정리하는 cron 작업을 설정합니다. 메모리가 문제였다면 애플리케이션의 메모리 설정을 점검합니다. CPU 과부하가 문제였다면 어떤 요청이 원인이었는지 access 로그를 분석합니다. 그리고 모니터링 도구를 설정해 자원 사용량이 임계치를 넘으면 알림을 받도록 합니다.

9. 정리

서버 다운 시 대응 순서를 정리합니다.

1단계로 ping과 SSH로 서버 생존 여부를 확인합니다. 2단계로 systemctl status로 서비스 상태를 확인합니다. 3단계로 top, free, df로 자원 사용량을 확인합니다. 4단계로 로그 파일에서 오류 메시지를 분석합니다. 5단계로 서버 자체가 다운됐다면 클라우드 콘솔에서 재시작합니다.

복구 후에는 원인을 분석하고 재발 방지 조치를 반드시 취해야 합니다.

DDoS 공격이란 무엇이고 어떻게 막을 수 있을까?

테크 한 스푼 — Mon, 25 May 2026 17:56:34 +0900

서버가 갑자기 먹통이 됐다면?
DoS와 DDoS의 차이
DDoS 공격의 종류
DDoS 공격을 받으면 어떤 증상이 나타나나?
개인 서버 수준에서 DDoS를 막는 방법
클라우드 서비스의 DDoS 방어 기능
DDoS 완전 차단은 불가능하다 – 현실적인 대응 전략
정리

1. 서버가 갑자기 먹통이 됐다면?

멀쩡하게 돌아가던 서버가 갑자기 응답을 멈추고, 아무도 접속할 수 없는 상황이 생길 수 있습니다. CPU는 100%에 달하고, 네트워크 트래픽은 폭증하는데 정작 서비스는 아무것도 처리하지 못하는 상태입니다.

이런 상황의 원인 중 하나가 바로 DDoS 공격입니다. 뉴스에서 자주 들어봤지만 정확히 어떤 원리인지, 어떻게 대응해야 하는지 모르는 분들이 많습니다. 이 글에서는 DDoS 공격의 개념부터 현실적인 대응 방법까지 쉽게 설명드립니다.

2. DoS와 DDoS의 차이

DDoS를 이해하려면 먼저 **DoS(Denial of Service, 서비스 거부 공격)**를 알아야 합니다.

DoS 공격은 한 대의 컴퓨터가 특정 서버에 엄청난 양의 요청을 보내서 서버를 마비시키는 공격입니다. 마치 한 명이 콜센터에 전화를 수천 번 걸어 다른 사람들이 연결하지 못하게 방해하는 것과 같습니다.

**DDoS(Distributed Denial of Service, 분산 서비스 거부 공격)**는 수천, 수만 대의 컴퓨터가 동시에 한 서버를 공격하는 방식입니다. 공격에 사용되는 컴퓨터들은 대부분 악성코드에 감염된 일반인의 PC나 IoT 기기들로, 이를 **봇넷(Botnet)**이라고 부릅니다.

구분DoSDDoS

공격 주체	한 대의 컴퓨터	수천~수만 대의 분산된 컴퓨터
차단 난이도	상대적으로 쉬움	매우 어려움
공격 규모	소규모	대규모
공격 IP	단일 IP	수많은 분산 IP

DoS는 공격 IP를 차단하면 막을 수 있지만, DDoS는 수만 개의 IP에서 동시에 공격이 오기 때문에 단순 IP 차단으로는 막기가 매우 어렵습니다.

3. DDoS 공격의 종류

DDoS 공격에는 여러 가지 유형이 있습니다. 대표적인 세 가지를 알아보겠습니다.

볼류메트릭 공격(Volumetric Attack) 서버의 네트워크 대역폭을 초과하는 엄청난 양의 트래픽을 쏟아붓는 방식입니다. 서버가 데이터를 받아들이는 통로 자체를 막아버립니다. 가장 흔한 DDoS 유형입니다.

프로토콜 공격(Protocol Attack) TCP/IP 프로토콜의 취약점을 이용해 서버의 연결 처리 자원을 소진시킵니다. SYN Flood 공격이 대표적으로, 연결 요청만 보내고 완성하지 않아 서버의 연결 대기 큐를 가득 채웁니다.

애플리케이션 공격(Application Layer Attack) 정상적인 HTTP 요청처럼 위장해 웹 서버에 부하를 줍니다. 트래픽 양은 적어 보이지만 서버 자원을 많이 소비하는 복잡한 요청을 반복적으로 보내 서버를 마비시킵니다.

4. DDoS 공격을 받으면 어떤 증상이 나타나나?

DDoS 공격을 받으면 다음과 같은 증상이 나타납니다.

웹사이트 접속이 매우 느려지거나 완전히 연결이 되지 않습니다. 서버의 CPU, 메모리 사용량이 갑자기 급격히 치솟습니다. 네트워크 트래픽이 평소와 비교해 비정상적으로 폭증합니다. 로그 파일에 수많은 IP에서 짧은 시간 안에 대량의 요청이 기록됩니다.

이런 증상이 나타나면 먼저 서버 모니터링 명령어로 상태를 확인하고, 로그를 분석해 공격 여부를 판단해야 합니다.

5. 개인 서버 수준에서 DDoS를 막는 방법

소규모 DDoS 공격은 서버 자체적으로도 어느 정도 대응이 가능합니다.

방법 1. UFW로 특정 IP 차단 공격이 특정 IP 대역에서 집중된다면 해당 IP를 차단합니다.

sudo ufw deny from 공격IP주소

방법 2. Nginx로 요청 속도 제한(Rate Limiting) Nginx 설정에서 특정 IP의 요청 횟수를 제한할 수 있습니다. Nginx 설정 파일에 아래 내용을 추가하면 1초에 10번 이상 요청하는 IP의 요청을 제한합니다.

limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;

방법 3. Fail2Ban 활용 앞서 소개한 Fail2Ban을 SSH뿐 아니라 Nginx 로그에도 적용하면, 비정상적으로 많은 요청을 보내는 IP를 자동 차단할 수 있습니다.

6. 클라우드 서비스의 DDoS 방어 기능

대규모 DDoS 공격은 서버 자체적으로 막기 어렵습니다. 수 Gbps, 수십 Gbps에 달하는 트래픽이 밀려오면 서버가 트래픽을 처리하기도 전에 네트워크 회선 자체가 포화됩니다.

이런 경우 클라우드 서비스의 DDoS 방어 기능을 활용합니다.

Cloudflare는 전 세계 데이터센터에 분산된 네트워크를 통해 DDoS 트래픽을 흡수하고 정상 트래픽만 서버로 전달해 줍니다. 무료 플랜만으로도 기본적인 DDoS 방어 기능을 제공하기 때문에, 개인 서버를 운영한다면 Cloudflare DNS를 적용하는 것만으로도 상당한 보호 효과를 볼 수 있습니다.

AWS Shield는 AWS에서 제공하는 DDoS 방어 서비스입니다. Standard 등급은 AWS 사용자라면 무료로 제공되며, 일반적인 네트워크 및 전송 계층 공격을 자동으로 방어합니다.

7. DDoS 완전 차단은 불가능하다 – 현실적인 대응 전략

솔직히 말씀드리면, DDoS 공격을 100% 완벽하게 막는 방법은 존재하지 않습니다. 공격 규모가 서버와 네트워크가 처리할 수 있는 한계를 넘어서면 어떤 방어책도 한계가 있습니다.

따라서 현실적인 목표는 공격의 영향을 최소화하고 빠르게 복구하는 것입니다.

평소에 서버 모니터링을 통해 트래픽 이상 징후를 빠르게 감지하는 것이 중요합니다. Cloudflare 같은 CDN을 앞에 두어 서버 IP를 숨기고 트래픽을 분산시킵니다. 공격이 발생했을 때 클라우드 서비스의 스케일 업 기능으로 임시로 서버 성능을 높이는 방법도 있습니다. 그리고 공격이 끝난 후 로그를 분석해 패턴을 파악하고 방어 규칙을 보강합니다.

8. 정리

오늘 배운 핵심을 정리합니다.

DDoS는 수많은 분산된 컴퓨터가 동시에 서버를 공격해 서비스를 마비시키는 공격입니다.
소규모 공격은 UFW 차단, Nginx Rate Limiting, Fail2Ban으로 어느 정도 대응할 수 있습니다.
대규모 공격에는 Cloudflare, AWS Shield 같은 클라우드 방어 서비스를 활용해야 합니다.
DDoS를 100% 막는 방법은 없으며, 현실적인 목표는 영향을 최소화하고 빠르게 복구하는 것입니다.

서버 해킹 당하기 전에 꼭 해야 할 보안 설정 7가지

테크 한 스푼 — Mon, 25 May 2026 17:55:34 +0900

서버 보안, 왜 미루면 안 되는가?
보안 설정 1 – root 계정 SSH 접속 차단
보안 설정 2 – SSH 포트 변경
보안 설정 3 – 비밀번호 인증 비활성화
보안 설정 4 – 방화벽으로 불필요한 포트 차단
보안 설정 5 – Fail2Ban 설치로 무차별 대입 공격 차단
보안 설정 6 – 자동 보안 업데이트 설정
보안 설정 7 – 불필요한 서비스 비활성화
정리

1. 서버 보안, 왜 미루면 안 되는가?

서버를 인터넷에 연결하는 순간, 전 세계 어디선가 자동화된 봇이 해당 서버의 포트를 스캔하고 취약점을 찾기 시작합니다. 실제로 아무 설정도 하지 않은 채 서버를 공개하면 수 분 안에 SSH 로그인 시도 기록이 쌓이기 시작합니다.

해킹을 당한 서버는 개인 정보 유출, 랜섬웨어 감염, 스팸 메일 발송에 악용되는 등 심각한 피해를 초래합니다. 그리고 대부분의 해킹은 정교한 기술보다는 기본 보안 설정을 하지 않은 허점을 노립니다.

이 글에서는 서버를 운영하는 누구나 반드시 적용해야 할 보안 설정 7가지를 정리했습니다.

2. 보안 설정 1 – root 계정 SSH 접속 차단

root 계정은 서버의 모든 권한을 가진 최고 관리자입니다. 해커들이 가장 먼저 공격하는 계정이기도 합니다. root로 SSH 접속을 허용해 두면, 비밀번호 하나만 뚫리면 서버 전체가 장악됩니다.

SSH 설정 파일을 열어 PermitRootLogin 항목을 찾아 값을 no로 변경합니다.

sudo nano /etc/ssh/sshd_config

PermitRootLogin no 로 설정한 뒤 저장하고, SSH 서비스를 재시작합니다.

sudo systemctl restart sshd

이후에는 일반 계정으로 접속한 뒤 필요할 때만 sudo를 사용합니다.

3. 보안 설정 2 – SSH 포트 변경

SSH 기본 포트인 22번은 전 세계 해커들이 가장 많이 공격하는 포트입니다. 22번 포트를 다른 번호로 바꾸는 것만으로도 자동화된 공격의 대부분을 차단할 수 있습니다.

동일한 SSH 설정 파일에서 Port 항목을 찾아 변경합니다. 1024번 이상, 65535번 이하의 번호 중 사용하지 않는 번호를 선택합니다. 예를 들어 22222로 변경하는 식입니다.

Port 22222

저장 후 방화벽에서 새 포트를 열고, 기존 22번은 닫습니다.

sudo ufw allow 22222 sudo ufw delete allow 22

그다음 SSH 서비스를 재시작합니다. 포트를 변경한 경우 새 포트로 접속이 되는지 반드시 확인한 후 기존 세션을 종료해야 합니다.

4. 보안 설정 3 – 비밀번호 인증 비활성화

비밀번호 인증은 무차별 대입 공격(Brute Force)에 취약합니다. SSH 키 인증만 허용하고 비밀번호 인증을 완전히 비활성화하면 이 공격을 원천 차단할 수 있습니다.

SSH 키가 이미 설정되어 있다는 전제하에, SSH 설정 파일에서 PasswordAuthentication 항목을 no로 변경합니다.

PasswordAuthentication no

주의사항으로, 이 설정을 적용하기 전에 반드시 SSH 키 인증이 정상적으로 작동하는지 먼저 확인해야 합니다. 키 인증 없이 비밀번호 인증을 비활성화하면 서버에 영구적으로 접속할 수 없게 됩니다.

5. 보안 설정 4 – 방화벽으로 불필요한 포트 차단

서버에서 실제로 사용하는 포트 외에는 모두 차단하는 것이 원칙입니다. UFW를 사용해 필요한 포트만 열어두고 나머지는 차단합니다.

현재 방화벽 상태를 확인합니다.

sudo ufw status

웹 서버를 운영 중이라면 SSH 포트, 80번, 443번만 열어두는 것이 기본입니다. MySQL 같은 데이터베이스 포트(3306)는 외부에서 직접 접근할 필요가 없으므로 반드시 차단합니다.

모든 인바운드 트래픽을 기본 차단으로 설정합니다.

sudo ufw default deny incoming sudo ufw default allow outgoing

그 다음 필요한 포트만 허용합니다.

sudo ufw allow 22222 sudo ufw allow 80 sudo ufw allow 443 sudo ufw enable

6. 보안 설정 5 – Fail2Ban 설치로 무차별 대입 공격 차단

Fail2Ban은 로그 파일을 모니터링하다가 짧은 시간 안에 로그인에 여러 번 실패한 IP를 자동으로 차단하는 보안 도구입니다. SSH 무차별 대입 공격을 막는 데 매우 효과적입니다.

설치 명령어는 다음과 같습니다.

sudo apt install fail2ban -y

설치 후 자동으로 실행됩니다. 기본 설정으로도 SSH 보호가 활성화되며, 10분 안에 5번 이상 로그인 실패 시 해당 IP를 10분간 차단합니다.

현재 차단된 IP 목록을 확인하려면 아래 명령어를 사용합니다.

sudo fail2ban-client status sshd

실제로 이 명령어를 실행해 보면 수많은 IP가 차단된 것을 확인할 수 있습니다. 그만큼 서버에 대한 공격 시도가 많다는 의미이기도 합니다.

7. 보안 설정 6 – 자동 보안 업데이트 설정

보안 취약점은 계속 발견되고 패치가 배포됩니다. 수동으로 매번 업데이트하는 것은 번거롭기 때문에, 보안 패치만큼은 자동으로 설치되도록 설정하는 것이 좋습니다.

unattended-upgrades 패키지를 설치합니다.

sudo apt install unattended-upgrades -y

자동 업데이트를 활성화합니다.

sudo dpkg-reconfigure --priority=low unattended-upgrades

화면에 나타나는 대화 상자에서 Yes를 선택하면 보안 업데이트가 자동으로 적용됩니다. 운영체제 전체 업그레이드가 아닌 보안 패치만 자동 적용되므로 서비스 안정성에 영향을 주지 않습니다.

8. 보안 설정 7 – 불필요한 서비스 비활성화

서버에 설치된 서비스 중 실제로 사용하지 않는 것이 있다면 비활성화하는 것이 좋습니다. 실행 중인 서비스는 잠재적인 공격 대상이 될 수 있기 때문입니다.

현재 실행 중인 서비스 목록을 확인합니다.

sudo systemctl list-units --type=service --state=running

목록에서 사용하지 않는 서비스를 발견하면 중지하고 자동 시작도 비활성화합니다.

sudo systemctl stop 서비스명 sudo systemctl disable 서비스명

예를 들어 웹 서버만 운영하는데 Bluetooth 서비스나 프린터 서비스가 실행 중이라면 비활성화할 수 있습니다. 단, 어떤 역할을 하는지 모르는 서비스는 함부로 건드리지 않는 것이 좋습니다.

9. 정리

오늘 배운 서버 보안 설정 7가지를 요약합니다.

보안 설정핵심 내용

root SSH 차단	PermitRootLogin no 설정
SSH 포트 변경	22번 → 다른 번호로 변경
비밀번호 인증 비활성화	SSH 키 인증만 허용
방화벽 설정	필요한 포트만 열고 나머지 차단
Fail2Ban 설치	무차별 대입 공격 자동 차단
자동 보안 업데이트	보안 패치 자동 적용
불필요한 서비스 비활성화	공격 표면 최소화

이 7가지 설정만 적용해도 서버 보안 수준이 크게 높아집니다.

서버 재부팅 없이 서비스 재시작하는 방법 정리

테크 한 스푼 — Mon, 25 May 2026 17:54:01 +0900

1. 왜 재부팅 없이 재시작해야 할까?

서버 설정을 변경하거나 코드를 업데이트했을 때, 변경 사항이 적용되려면 서비스를 재시작해야 합니다. 이때 많은 초보자들이 서버 전체를 재부팅(reboot)하려는 경향이 있습니다.

하지만 서버를 재부팅하면 모든 서비스가 수십 초에서 수 분간 중단됩니다. 그 시간 동안 사이트에 접속하는 사람들은 서비스를 이용할 수 없습니다. 실제 서비스를 운영 중이라면 이는 큰 문제입니다.

다행히 리눅스에서는 서버 전체를 재부팅하지 않고 특정 서비스만 선택적으로 재시작할 수 있습니다. 대부분의 설정 변경은 서비스 재시작만으로 충분히 적용됩니다.

2. systemctl로 서비스 재시작하기

앞서 배운 systemctl 명령어로 서비스를 재시작할 수 있습니다. 기본 사용법을 다시 정리합니다.

서비스를 완전히 중지했다가 다시 시작합니다.

sudo systemctl restart 서비스명

서비스의 현재 상태를 확인합니다. 재시작 후 정상적으로 running 상태인지 반드시 확인하는 습관이 중요합니다.

sudo systemctl status 서비스명

서비스를 중지합니다.

sudo systemctl stop 서비스명

서비스를 시작합니다.

sudo systemctl start 서비스명

3. reload vs restart – 무엇이 다른가?

systemctl에는 restart 외에 reload라는 명령도 있습니다. 두 명령어의 차이를 이해하면 더 안전하게 서비스를 운영할 수 있습니다.

구분restartreload

동작 방식	서비스를 완전히 종료 후 재시작	서비스를 종료하지 않고 설정만 다시 읽음
서비스 중단	짧은 시간 중단됨	중단 없음 (무중단)
사용 시점	코드나 프로그램 자체가 바뀌었을 때	설정 파일만 변경됐을 때
지원 여부	모든 서비스 지원	일부 서비스만 지원

예를 들어 Nginx 설정 파일(nginx.conf)을 수정했다면, restart 대신 reload를 사용하면 서비스 중단 없이 설정을 반영할 수 있습니다.

sudo systemctl reload nginx

reload를 지원하지 않는 서비스는 reload 명령을 실행해도 자동으로 restart로 동작하거나 오류가 발생합니다. 확실하지 않다면 restart를 사용하는 것이 안전합니다.

4. 서비스별 재시작 명령어 모음

자주 사용하는 서비스별 재시작 명령어를 정리합니다.

Nginx 웹서버

설정 파일 문법 오류를 먼저 검사합니다.

sudo nginx -t

문법에 이상이 없다면 설정을 반영합니다.

sudo systemctl reload nginx

MySQL 데이터베이스

sudo systemctl restart mysql

SSH 서버

SSH 설정 변경 후 재시작 시에는 현재 접속이 끊어지지 않도록 주의합니다. 새 설정으로 접속이 가능한지 먼저 테스트한 후 재시작합니다.

sudo systemctl restart sshd

Node.js 앱 (PM2 사용 시)

PM2는 Node.js 앱을 백그라운드에서 실행하고 관리해주는 도구입니다. PM2로 실행 중인 앱을 무중단으로 재시작하려면 아래 명령어를 사용합니다.

pm2 reload 앱이름

코드 변경 사항을 반영할 때는 reload를 사용합니다.

pm2 restart 앱이름

5. 서비스가 재시작되지 않을 때 원인 찾기

재시작 명령을 입력했는데 서비스가 정상적으로 뜨지 않는 경우, 아래 순서로 원인을 확인합니다.

1단계. 서비스 상태 확인

sudo systemctl status 서비스명

출력 결과에서 오류 메시지를 확인합니다. 설정 파일 오류, 포트 충돌 등의 원인이 표시됩니다.

2단계. 로그 확인

sudo journalctl -u 서비스명 -n 50

최근 50줄의 서비스 로그를 출력합니다. 오류 원인이 더 자세히 나타납니다.

3단계. 설정 파일 문법 검사

Nginx의 경우 설정 파일에 문법 오류가 있으면 재시작이 실패합니다.

sudo nginx -t

이 명령어로 문법 오류 위치를 정확히 확인할 수 있습니다.

4단계. 포트 충돌 확인

같은 포트를 사용하는 다른 프로세스가 이미 실행 중이면 서비스가 뜨지 않습니다.

ss -tuln | grep 80

80번 포트를 사용하는 프로세스가 있는지 확인합니다.

6. 서버 재부팅이 반드시 필요한 경우

대부분의 경우 서비스 재시작으로 충분하지만, 아래 상황에서는 서버 전체 재부팅이 필요합니다.

커널 업데이트 적용 시 리눅스 커널이 업데이트됐다면 재부팅해야 새 커널이 적용됩니다. sudo apt upgrade 후 재부팅이 필요하다는 메시지가 뜨면 해당됩니다.

메모리 누수가 심각한 경우 장기간 운영 중 메모리 누수로 인해 서버가 비정상적으로 느려진 경우, 모든 프로세스를 초기화하기 위해 재부팅이 필요할 수 있습니다.

하드웨어 변경 후 새 디스크 추가, RAM 교체 등 하드웨어를 변경한 경우 재부팅이 필요합니다.

재부팅이 필요한 경우에도 서비스 점검 시간을 미리 공지하고, 트래픽이 적은 새벽 시간대를 활용하는 것이 좋습니다.

7. 정리

오늘 배운 핵심을 정리합니다.

서버 전체를 재부팅하는 대신, systemctl restart 명령으로 특정 서비스만 재시작할 수 있습니다.
reload는 서비스 중단 없이 설정만 다시 읽는 방식으로, 설정 파일 변경 시 restart보다 안전합니다.
서비스가 재시작되지 않을 때는 systemctl status와 journalctl로 원인을 확인합니다.
커널 업데이트 적용, 심각한 메모리 누수, 하드웨어 변경의 경우에는 전체 재부팅이 필요합니다.

서버 로그 파일이란? – 에러 났을 때 원인 찾는 법

테크 한 스푼 — Mon, 25 May 2026 17:52:51 +0900

1. 로그 파일이 왜 중요한가?

서버를 운영하다 보면 반드시 이런 순간이 찾아옵니다. 어제까지 잘 되던 사이트가 갑자기 오류 페이지를 보여주거나, 특정 기능이 작동하지 않거나, 서버가 예상치 못하게 재시작되는 상황입니다.

이런 상황에서 원인을 찾으려면 가장 먼저 로그 파일을 확인해야 합니다. 로그는 서버가 무엇을 했는지 기록한 일지입니다. 마치 블랙박스처럼, 문제가 발생하기 전과 후에 어떤 일이 있었는지 확인할 수 있습니다.

2. 로그 파일이란 무엇인가?

**로그(Log)**는 시스템이나 애플리케이션이 실행되면서 발생하는 이벤트를 시간 순서대로 기록한 파일입니다. 서버 로그에는 다음과 같은 정보가 담깁니다.

누가, 언제, 어떤 페이지에 접속했는지
어떤 오류가 발생했는지
서비스가 언제 시작되고 종료됐는지
사용자 로그인 시도 기록

로그는 문제 해결뿐 아니라 보안 감사, 서비스 분석, 성능 최적화 등 다양한 목적으로 활용됩니다.

3. 리눅스 주요 로그 파일 위치

리눅스에서 로그 파일은 주로 /var/log 디렉토리 아래에 저장됩니다. 주요 로그 파일을 정리하면 아래와 같습니다.

파일 경로내용

/var/log/syslog	시스템 전체 로그
/var/log/auth.log	로그인, SSH 접속 시도 기록
/var/log/kern.log	커널 관련 로그
/var/log/dpkg.log	패키지 설치/제거 기록
/var/log/nginx/access.log	Nginx 접속 로그
/var/log/nginx/error.log	Nginx 오류 로그
/var/log/mysql/error.log	MySQL 오류 로그

서버에서 문제가 생겼을 때 가장 먼저 확인하는 파일은 해당 서비스의 error.log입니다.

4. Nginx 로그 읽는 법

Nginx는 두 가지 로그 파일을 생성합니다.

access.log (접속 로그) 서버에 들어온 모든 HTTP 요청이 기록됩니다. 한 줄의 예시를 설명드리면 다음과 같습니다.

123.45.67.89 - - [25/May/2026:14:30:00 +0900] "GET /index.html HTTP/1.1" 200 1234

각 항목의 의미입니다.

123.45.67.89 → 접속한 사용자의 IP 주소
[25/May/2026:14:30:00 +0900] → 접속 시간
GET /index.html → 요청 방식과 요청한 페이지
200 → HTTP 응답 코드 (200은 정상)
1234 → 전송된 데이터 크기(바이트)

error.log (오류 로그) 서버에서 발생한 오류가 기록됩니다. 문제 해결 시 가장 먼저 확인해야 할 파일입니다. 오류 로그의 심각도는 debug, info, notice, warn, error, crit, alert, emerg 순으로 높아집니다.

5. 로그에서 에러 원인 찾는 방법

로그 파일은 양이 많아서 처음엔 어디서부터 봐야 할지 막막합니다. 아래 방법을 순서대로 활용하면 효율적으로 원인을 찾을 수 있습니다.

방법 1. 최근 로그만 확인하기 문제가 방금 발생했다면 로그 파일의 마지막 부분만 보면 됩니다. tail 명령어로 최근 50줄을 확인합니다.

tail -n 50 /var/log/nginx/error.log

방법 2. 실시간 로그 모니터링 서비스를 재시작하거나 특정 동작을 수행하면서 어떤 로그가 찍히는지 실시간으로 확인합니다.

tail -f /var/log/nginx/error.log

방법 3. 키워드로 검색하기 error, fail, denied, refused 같은 키워드로 오류가 있는 줄만 필터링합니다.

grep "error" /var/log/nginx/error.log

방법 4. 특정 날짜 기준으로 필터링하기 날짜를 함께 검색해 특정 시점의 로그만 확인합니다.

grep "25/May/2026" /var/log/nginx/access.log

6. 로그가 너무 많이 쌓일 때 – 로그 관리

서버를 오래 운영하면 로그 파일이 쌓여 디스크 용량을 가득 채우는 경우가 있습니다. 리눅스에는 logrotate라는 도구가 기본으로 설치되어 있어, 로그 파일을 주기적으로 압축하고 오래된 파일을 자동 삭제해 줍니다.

logrotate 설정 파일은 /etc/logrotate.conf와 /etc/logrotate.d/ 폴더에 있습니다. 대부분의 경우 기본 설정으로도 잘 동작하지만, 로그가 너무 빠르게 쌓인다면 설정을 조정할 수 있습니다.

현재 로그 파일들의 용량을 한 번에 확인하는 방법입니다.

du -sh /var/log/*

특정 파일이 지나치게 크다면 해당 서비스의 로그 레벨을 조정하거나 logrotate 주기를 짧게 설정하는 것을 고려합니다.

7. 정리

오늘 배운 핵심을 정리합니다.

로그 파일은 서버에서 발생한 모든 이벤트를 시간 순서대로 기록한 파일입니다.
리눅스 로그는 /var/log 디렉토리에 저장됩니다.
문제가 생겼을 때는 해당 서비스의 error.log를 가장 먼저 확인합니다.
tail -f 로 실시간 모니터링, grep으로 키워드 필터링을 활용하면 원인을 빠르게 찾을 수 있습니다.
로그가 쌓여 디스크를 채우지 않도록 logrotate를 활용합니다.

서버 CPU·메모리 사용량 확인하는 방법 – 모니터링 첫걸음

테크 한 스푼 — Mon, 25 May 2026 17:51:43 +0900

서버 모니터링이 왜 필요한가?
CPU 사용량 확인하기 – top / htop
메모리 사용량 확인하기 – free
디스크 사용량 확인하기 – df
네트워크 상태 확인하기 – netstat
프로세스 확인 및 종료하기 – ps / kill
한눈에 보는 모니터링 도구 – htop 설치 및 사용법
정리

1. 서버 모니터링이 왜 필요한가?

서버를 운영하다 보면 갑자기 사이트가 느려지거나, 서비스가 응답을 안 하는 상황이 생깁니다. 이런 상황에서 원인을 파악하려면 서버의 현재 상태를 확인할 수 있어야 합니다.

마치 자동차 계기판을 보듯, 서버도 CPU, 메모리, 디스크 사용량을 주기적으로 확인해야 합니다. 문제가 생겼을 때 빠르게 대응할 수 있고, 미리 문제를 예방할 수도 있습니다.

이 글에서는 별도의 도구 없이 리눅스 기본 명령어만으로 서버 상태를 확인하는 방법을 알아보겠습니다.

2. CPU 사용량 확인하기 – top

top 명령어는 현재 서버에서 실행 중인 프로세스와 CPU, 메모리 사용량을 실시간으로 보여주는 도구입니다. 서버에서 가장 기본적인 모니터링 명령어입니다.

top

실행하면 화면 상단에 전체 시스템 요약 정보가, 하단에는 프로세스 목록이 나타납니다. 상단의 주요 항목은 다음과 같습니다.

load average: 서버의 평균 부하를 나타냅니다. 1분, 5분, 15분 평균값이 표시되며, CPU 코어 수보다 낮은 값이면 정상입니다.

%Cpu(s): CPU 사용률입니다. us(사용자 프로세스), sy(시스템), id(유휴 상태) 등으로 나뉩니다. id 값이 낮을수록 CPU가 바쁜 상태입니다.

MiB Mem: 전체 메모리, 사용 중인 메모리, 여유 메모리를 표시합니다.

top 화면에서 자주 쓰는 단축키는 다음과 같습니다. q를 누르면 종료, M을 누르면 메모리 사용량 기준 정렬, P를 누르면 CPU 사용량 기준 정렬, k를 누르면 특정 프로세스를 종료할 수 있습니다.

3. 메모리 사용량 확인하기 – free

free 명령어는 서버의 메모리 사용량을 한눈에 확인할 수 있는 간단한 명령어입니다.

free -h

-h 옵션을 붙이면 MB, GB 단위로 읽기 쉽게 표시됩니다. 출력 결과에서 주요 항목은 다음과 같습니다.

total: 전체 메모리 용량입니다.

used: 현재 사용 중인 메모리입니다.

free: 완전히 비어 있는 메모리입니다.

available: 실제로 새 프로세스에 할당 가능한 메모리입니다. 리눅스는 여유 메모리를 캐시로 활용하기 때문에, free 값보다 available 값이 실제 사용 가능한 메모리를 더 정확하게 나타냅니다.

available 값이 전체 메모리의 20% 이하로 떨어지면 메모리 부족을 의심해 볼 수 있습니다.

4. 디스크 사용량 확인하기 – df

df(Disk Free) 명령어는 디스크 파티션별 사용량을 보여줍니다.

df -h

-h 옵션으로 GB 단위로 읽기 쉽게 표시됩니다. 출력 결과에서 Use% 항목이 사용률을 나타냅니다. 이 값이 80% 이상이면 주의가 필요하고, 90% 이상이면 디스크를 정리하거나 용량을 늘려야 합니다.

어떤 폴더가 용량을 많이 차지하는지 확인하고 싶다면 du 명령어를 사용합니다.

du -sh /var/log

이 명령어는 /var/log 폴더의 전체 용량을 보여줍니다. 로그 파일이 쌓여 디스크를 가득 채우는 경우가 많으므로 주기적으로 확인하는 것이 좋습니다.

5. 네트워크 상태 확인하기 – ss

ss 명령어는 현재 서버에서 열려 있는 포트와 네트워크 연결 상태를 확인합니다. 이전에는 netstat 명령어를 많이 사용했으나, 현재 Ubuntu에서는 ss를 권장합니다.

현재 열려 있는 포트 목록을 확인합니다.

ss -tuln

어떤 포트가 열려 있는지, 어떤 서비스가 해당 포트를 사용하는지 확인할 수 있습니다. 예상치 못한 포트가 열려 있다면 보안 이슈를 의심해볼 수 있습니다.

6. 프로세스 확인 및 종료하기 – ps / kill

ps 명령어는 현재 실행 중인 프로세스 목록을 보여줍니다.

ps aux

출력 결과에서 PID(프로세스 ID) 번호를 확인할 수 있습니다. 특정 서비스 이름으로 필터링해서 보려면 grep과 함께 사용합니다.

ps aux | grep nginx

특정 프로세스를 강제 종료하려면 kill 명령어에 PID를 입력합니다.

kill -9 프로세스PID번호

단, 중요한 시스템 프로세스를 잘못 종료하면 서버가 불안정해질 수 있으므로 신중하게 사용해야 합니다.

7. 한눈에 보는 모니터링 도구 – htop

htop은 top의 개선 버전으로, 컬러풀한 화면과 직관적인 인터페이스를 제공합니다. 마우스 클릭도 지원해서 훨씬 사용하기 편리합니다. 기본 설치가 아니기 때문에 별도로 설치해야 합니다.

sudo apt install htop -y

설치 후 htop을 실행하면 CPU 코어별 사용량, 메모리, 스왑 사용량을 그래프로 볼 수 있습니다. F6키로 정렬 기준을 변경하고, F9키로 프로세스를 종료할 수 있습니다. q 또는 F10으로 종료합니다.

서버를 처음 다루는 분들에게는 top보다 htop이 훨씬 직관적이므로 설치해서 사용하는 것을 추천합니다.

8. 정리

오늘 배운 모니터링 명령어를 정리합니다.

명령어확인 항목

top	CPU·메모리·프로세스 실시간 확인
free -h	메모리 사용량 확인
df -h	디스크 사용량 확인
ss -tuln	열려 있는 포트 확인
ps aux	실행 중인 프로세스 확인
htop	전체 시스템 상태 직관적 확인

서버 모니터링은 습관적으로 하는 것이 중요합니다. 서비스가 느려지거나 이상 징후가 느껴질 때 가장 먼저 이 명령어들을 실행해 보세요.

도메인 구입하고 내 서버에 연결하는 방법 (초보용)

테크 한 스푼 — Mon, 25 May 2026 17:50:48 +0900

1. 도메인이 왜 필요한가?

서버를 만들고 나면 IP 주소(예: 123.45.67.89)로 접속할 수 있습니다. 하지만 이 숫자 주소를 사람들에게 알려주고, 외우게 하는 것은 현실적이지 않습니다.

도메인(예: myblog.com)을 사용하면 기억하기 쉬운 주소로 서버에 접속할 수 있습니다. 또한 도메인이 있어야 HTTPS 인증서를 발급받을 수 있고, 검색 엔진에 제대로 등록도 됩니다. 블로그나 웹서비스를 운영하려면 도메인은 사실상 필수입니다.

2. 도메인 구입 전 알아야 할 것들

도메인을 구입하기 전에 몇 가지 개념을 알아두면 좋습니다.

도메인 등록 기관(Registrar) 도메인은 등록 기관을 통해 구입합니다. 대표적인 국내 서비스로는 가비아, 후이즈, 카페24가 있고, 해외 서비스로는 Namecheap, GoDaddy, Cloudflare가 있습니다.

도메인 연간 비용 도메인은 소유가 아니라 임대 개념입니다. 매년 갱신 비용을 납부해야 하며, 납부하지 않으면 도메인을 잃게 됩니다. 가격은 도메인 종류에 따라 다릅니다.

도메인 종류연간 비용 (대략)

.com	1~2만 원
.net	1~2만 원
.co.kr	2~3만 원
.io	5~7만 원
.ai	10만 원 이상

도메인 선택 팁 짧고 기억하기 쉬운 이름, 오타가 나기 어려운 이름이 좋습니다. 특수문자나 숫자는 가급적 피하고, 운영하는 서비스나 블로그 주제와 연관된 이름을 선택하는 것을 추천합니다.

3. 도메인 구입하는 방법

가비아를 예시로 도메인 구입 과정을 설명드립니다. 다른 등록 기관도 과정은 비슷합니다.

가비아(gabia.com) 접속 후 회원가입 및 로그인합니다.
상단 검색창에 원하는 도메인 이름을 입력합니다. (예: myblog)
사용 가능한 도메인 목록이 표시되면 원하는 것을 선택합니다.
장바구니에 추가 후 결제합니다.
결제 완료 후 My가비아 > 도메인 관리에서 구입한 도메인을 확인합니다.

도메인 구입이 완료되면 즉시 DNS 설정을 할 수 있습니다.

4. DNS 설정 – 도메인을 서버 IP에 연결하기

도메인을 구입했다고 해서 바로 서버와 연결되는 것은 아닙니다. DNS 설정을 통해 "이 도메인은 이 IP 주소로 연결해줘" 라고 알려줘야 합니다.

DNS 설정에서 가장 기본이 되는 레코드 종류를 먼저 알아두겠습니다.

레코드 종류역할

A 레코드	도메인을 IPv4 주소로 연결
AAAA 레코드	도메인을 IPv6 주소로 연결
CNAME 레코드	도메인을 다른 도메인으로 연결
MX 레코드	이메일 서버 지정

서버 IP에 도메인을 연결하려면 A 레코드를 설정합니다.

가비아 기준 DNS 설정 방법입니다.

My가비아 > 도메인 관리 페이지로 이동합니다.
구입한 도메인 옆 DNS 관리 버튼을 클릭합니다.
DNS 설정 탭에서 레코드 추가 버튼을 클릭합니다.
아래와 같이 입력합니다.
저장 버튼을 클릭합니다.

항목입력값

타입	A
호스트	@ (루트 도메인을 의미)
값/위치	서버의 IP 주소
TTL	3600 (기본값 사용)

www가 붙은 주소(www.myblog.com)도 연결하려면 호스트 항목에 @대신 www를 입력해 동일하게 A 레코드를 추가합니다.

5. 도메인 연결 확인하는 방법

DNS 설정은 전 세계 DNS 서버에 전파되는 데 시간이 걸립니다. 보통 수 분에서 최대 48시간이 소요되며, 대부분 1~2시간 안에 완료됩니다.

연결이 제대로 됐는지 확인하는 방법은 두 가지입니다.

방법 1. 브라우저 직접 접속 브라우저 주소창에 구입한 도메인(예: myblog.com)을 입력했을 때 서버 페이지가 뜨면 연결이 완료된 것입니다.

방법 2. nslookup 명령어 사용 터미널에서 nslookup 도메인주소 를 실행하면 해당 도메인이 가리키는 IP 주소를 확인할 수 있습니다. 설정한 서버 IP가 출력되면 정상입니다.

방법 3. DNS 전파 확인 사이트 이용 whatsmydns.net 같은 사이트에서 도메인을 입력하면, 전 세계 여러 지역에서 DNS가 제대로 전파됐는지 한눈에 확인할 수 있습니다.

6. 서브도메인 설정하는 방법

하나의 도메인으로 여러 서비스를 운영하고 싶다면 서브도메인을 활용합니다. 서브도메인은 별도의 추가 비용 없이 DNS 설정만으로 만들 수 있습니다.

예를 들어 myblog.com을 소유하고 있다면 다음과 같이 활용할 수 있습니다.

blog.myblog.com → 블로그 서버
api.myblog.com → API 서버
admin.myblog.com → 관리자 페이지

서브도메인 설정도 A 레코드 방식과 동일합니다. 호스트 항목에 @나 www 대신 원하는 서브도메인 이름(blog, api, admin 등)을 입력하면 됩니다.

7. 자주 하는 실수와 해결법

도메인을 입력해도 연결이 안 되는 경우 DNS 전파가 아직 완료되지 않은 경우입니다. 1~2시간 기다린 후 다시 시도해 보세요. whatsmydns.net에서 전파 상태를 확인할 수 있습니다.

IP 주소 입력 실수 A 레코드에 서버 IP를 잘못 입력한 경우입니다. 서버의 공인 IP 주소를 다시 확인하고 수정합니다.

방화벽에서 80번, 443번 포트가 막힌 경우 도메인 연결이 됐더라도 방화벽에서 해당 포트가 차단되어 있으면 접속이 안 됩니다. ufw allow 80과 ufw allow 443 명령으로 포트를 열어줍니다.

8. 정리

오늘 배운 핵심을 정리합니다.

도메인은 등록 기관에서 연간 비용을 납부하고 임대하는 개념입니다.
도메인을 서버에 연결하려면 DNS에서 A 레코드를 설정해 IP 주소를 지정합니다.
DNS 전파에는 최대 48시간이 소요될 수 있습니다.
서브도메인은 추가 비용 없이 DNS 설정만으로 만들 수 있습니다.

HTTP와 HTTPS 차이 – 자물쇠 아이콘이 생기는 이유

테크 한 스푼 — Mon, 25 May 2026 17:49:35 +0900

1. 주소창의 자물쇠, 왜 중요한가?

브라우저 주소창을 보면 어떤 사이트는 자물쇠 아이콘이 표시되고, 어떤 사이트는 "주의 요함" 또는 "안전하지 않음"이라는 경고가 뜹니다. 이 차이가 바로 HTTP와 HTTPS의 차이입니다.

단순히 아이콘 하나의 차이처럼 보이지만, 실제로는 개인정보와 데이터 보안에 직결되는 매우 중요한 차이입니다. 서버를 운영하는 입장에서도 HTTPS 설정은 선택이 아닌 필수가 되었습니다.

2. HTTP란 무엇인가?

**HTTP(HyperText Transfer Protocol)**는 웹 브라우저와 서버가 데이터를 주고받을 때 사용하는 통신 규칙입니다. 우리가 웹사이트에 접속할 때 사용하는 가장 기본적인 프로토콜입니다.

HTTP의 가장 큰 문제는 데이터가 암호화되지 않는다는 점입니다. 브라우저와 서버 사이를 오가는 모든 데이터가 평문(암호화되지 않은 텍스트) 형태로 전송됩니다.

쉬운 비유로 설명하면, HTTP는 엽서와 같습니다. 엽서는 내용이 그대로 노출된 채로 배달됩니다. 중간에 누가 가로채면 내용을 바로 읽을 수 있죠.

3. HTTPS란 무엇인가?

**HTTPS(HyperText Transfer Protocol Secure)**는 HTTP에 **보안(SSL/TLS 암호화)**을 추가한 버전입니다. 주소가 http://로 시작하면 HTTP, https://로 시작하면 HTTPS입니다.

HTTPS는 봉인된 편지와 같습니다. 내용이 암호화되어 있기 때문에 중간에 누가 가로채더라도 내용을 해독할 수 없습니다. 오직 발신자(브라우저)와 수신자(서버)만 내용을 확인할 수 있습니다.

HTTPS는 세 가지를 보장합니다.

기밀성: 전송 데이터를 암호화해 제3자가 내용을 읽을 수 없습니다.

무결성: 데이터가 전송 중에 변조되지 않았음을 보장합니다.

인증: 접속한 서버가 진짜 해당 사이트임을 인증합니다.

4. HTTP와 HTTPS의 핵심 차이

구분HTTPHTTPS

암호화	없음	SSL/TLS 암호화 적용
기본 포트	80번	443번
주소 형태	http://	https://
브라우저 표시	안전하지 않음 경고	자물쇠 아이콘
데이터 보안	취약	안전
SEO	불리	유리 (구글 랭킹 반영)
필요 항목	없음	SSL 인증서 필요

SEO 항목에서 볼 수 있듯이, 구글은 HTTPS 사이트를 검색 랭킹에서 우대합니다. 즉, 블로그나 웹사이트를 운영한다면 HTTPS 적용이 검색 노출에도 유리합니다.

5. SSL/TLS 인증서란?

HTTPS를 사용하려면 SSL/TLS 인증서가 필요합니다. 인증서는 해당 서버가 신뢰할 수 있는 서버임을 증명하는 일종의 디지털 신분증입니다.

인증서는 **CA(인증 기관, Certificate Authority)**라는 신뢰할 수 있는 기관에서 발급합니다. 브라우저는 이 CA 목록을 가지고 있어서, 인증서가 신뢰할 수 있는 CA로부터 발급됐는지 확인합니다.

인증서의 종류는 크게 세 가지입니다.

DV(Domain Validation): 도메인 소유권만 확인. 개인 블로그나 소규모 사이트에 적합합니다.

OV(Organization Validation): 도메인 + 기업 실체 확인. 기업 웹사이트에 적합합니다.

EV(Extended Validation): 가장 높은 수준의 검증. 금융, 쇼핑몰 등에서 사용합니다.

6. HTTPS가 없으면 어떤 일이 생기나?

현재 Chrome, Firefox, Safari 등 주요 브라우저들은 HTTP 사이트에 접속할 때 "안전하지 않음" 경고를 표시합니다. 이 경고는 방문자에게 심리적 불안감을 주어 이탈률을 높입니다.

더 심각한 문제는 실제 보안 위협입니다. HTTP로 전송되는 로그인 정보, 결제 정보, 개인정보가 네트워크 감청(Man-in-the-Middle 공격)을 통해 탈취될 수 있습니다. 특히 카페나 공항 같은 공용 와이파이 환경에서 이런 위험이 높습니다.

7. Let's Encrypt로 무료 HTTPS 적용하기

예전에는 SSL 인증서를 구매하는 데 연간 수십만 원이 들었습니다. 하지만 지금은 Let's Encrypt라는 비영리 기관이 무료로 인증서를 발급해 주기 때문에, 누구나 쉽게 HTTPS를 적용할 수 있습니다.

Ubuntu 서버에 Nginx가 설치된 상태라면, Certbot이라는 도구를 이용해 인증서를 발급받을 수 있습니다. 먼저 Certbot을 설치합니다.

sudo apt install certbot python3-certbot-nginx -y

설치가 완료되면 아래 명령어로 인증서를 발급받고 Nginx에 자동으로 적용합니다. 도메인 주소는 본인의 도메인으로 교체합니다.

sudo certbot --nginx -d 도메인주소

인증서는 90일마다 갱신이 필요하지만, Certbot이 자동 갱신을 처리해 주기 때문에 한 번 설정하면 별도로 관리하지 않아도 됩니다.

8. 정리

오늘 배운 핵심을 정리합니다.

HTTP는 암호화 없이 데이터를 전송하는 기본 프로토콜입니다.
HTTPS는 SSL/TLS 암호화를 추가해 데이터를 안전하게 전송합니다.
HTTPS를 사용하면 브라우저에 자물쇠 아이콘이 표시되고, 구글 SEO에도 유리합니다.
Let's Encrypt를 이용하면 무료로 SSL 인증서를 발급받아 HTTPS를 적용할 수 있습니다.

Nginx 설치하고 웹페이지 띄우기까지 – 30분 완성

테크 한 스푼 — Mon, 25 May 2026 16:48:27 +0900

Nginx로 뭘 할 수 있나?
Nginx란 무엇인가?
실습 환경 준비
Step 1 – Nginx 설치
Step 2 – Nginx 서비스 시작 및 확인
Step 3 – 방화벽에서 80번 포트 열기
Step 4 – 브라우저에서 접속 확인
Step 5 – 나만의 HTML 페이지로 교체
Nginx 기본 파일 구조 이해하기
정리

1. Nginx로 뭘 할 수 있나?

"서버를 만들었는데, 이제 웹사이트를 올리려면 어떻게 해야 하지?"

이 질문의 답이 바로 **Nginx(엔진엑스)**입니다. 서버에 Nginx를 설치하면 브라우저에서 내 서버의 IP 주소나 도메인으로 접속했을 때 웹페이지를 보여줄 수 있습니다.

이 글에서는 Ubuntu 서버에 Nginx를 설치하고, 직접 만든 HTML 파일을 웹에 올리는 과정을 단계별로 설명드립니다. 처음 따라 해도 30분 안에 완성할 수 있습니다.

2. Nginx란 무엇인가?

**Nginx(엔진엑스)**는 세계에서 가장 널리 쓰이는 웹 서버 소프트웨어 중 하나입니다. 사용자의 브라우저가 웹페이지를 요청하면, Nginx가 HTML, CSS, 이미지 등의 파일을 찾아서 응답합니다.

Nginx가 인기 있는 이유는 빠른 속도와 낮은 메모리 사용량 덕분입니다. 동시에 수만 명의 요청을 처리해도 안정적으로 동작합니다. 전 세계 상위 웹사이트의 상당수가 Nginx를 사용하고 있습니다.

웹 서버로서의 역할 외에도 Nginx는 리버스 프록시, 로드 밸런서로도 활용되지만, 지금은 가장 기본인 웹 서버 역할에 집중합니다.

3. 실습 환경 준비

이 글의 실습은 다음 환경을 기준으로 합니다.

운영체제: Ubuntu 22.04 LTS
서버: AWS EC2, GCP, 또는 어떤 클라우드 서버든 상관없음
접속 방법: SSH로 서버에 접속한 상태

SSH 접속 방법을 아직 모르신다면, 이전 글 **"SSH가 뭔지 모르는 초보를 위한 개념 + 접속 방법"**을 먼저 읽고 오시는 것을 추천드립니다.

4. Step 1 – Nginx 설치

SSH로 서버에 접속한 후, 먼저 패키지 목록을 업데이트합니다.

sudo apt update

이어서 Nginx를 설치합니다. -y 옵션은 설치 중 나오는 확인 질문에 자동으로 "예"를 선택합니다.

sudo apt install nginx -y

설치에는 보통 1~2분 정도 소요됩니다. 완료되면 아래 명령어로 버전을 확인합니다.

nginx -v

nginx version: nginx/1.18.0 (Ubuntu) 처럼 버전 정보가 출력되면 설치 성공입니다.

5. Step 2 – Nginx 서비스 시작 및 확인

Nginx 서비스를 시작합니다.

sudo systemctl start nginx

서버 재부팅 시에도 자동으로 시작되도록 등록합니다.

sudo systemctl enable nginx

현재 상태를 확인합니다.

sudo systemctl status nginx

결과에서 active (running) 이 표시되면 정상입니다. active (running) 대신 failed나 inactive가 표시된다면 설정 파일 오류나 포트 충돌이 원인인 경우가 많습니다. sudo journalctl -xe | grep nginx 명령으로 오류 내용을 확인할 수 있습니다.

6. Step 3 – 방화벽에서 80번 포트 열기

이전 글에서 UFW 방화벽을 설정했다면, HTTP 접속을 위한 80번 포트를 열어줘야 합니다.

HTTP 포트를 허용합니다.

sudo ufw allow 80

HTTPS 포트도 미리 허용해 둡니다.

sudo ufw allow 443

방화벽 상태를 확인합니다.

sudo ufw status

AWS EC2를 사용하는 경우에는 UFW 외에도 **AWS 보안 그룹(Security Group)**에서도 80번 포트를 허용해야 합니다. AWS 콘솔에서 EC2 인스턴스의 보안 그룹 설정으로 이동해, 인바운드 규칙에 HTTP(80) 항목을 추가합니다.

7. Step 4 – 브라우저에서 접속 확인

이제 브라우저를 열고 서버의 IP 주소를 http://내_서버_IP_주소 형태로 입력해 봅니다.

"Welcome to nginx!" 문구가 담긴 기본 환영 페이지가 나타나면 성공입니다. 이 화면이 보인다는 것은 Nginx가 정상적으로 실행 중이고, 브라우저에서 서버로 HTTP 요청이 제대로 전달되고 있다는 의미입니다.

8. Step 5 – 나만의 HTML 페이지로 교체

기본 환영 페이지 대신 직접 만든 HTML 페이지를 보여주도록 교체해 보겠습니다.

Nginx의 기본 웹 파일 경로는 /var/www/html/입니다. 먼저 기본 파일을 백업합니다.

sudo cp /var/www/html/index.nginx-debian.html /var/www/html/index.nginx-debian.html.bak

새 index.html 파일을 작성합니다.

sudo nano /var/www/html/index.html

nano 편집기가 열리면 아래 내용을 입력합니다.

<!DOCTYPE html> <html lang="ko"> <head> <meta charset="UTF-8"> <title>내 첫 번째 서버</title> </head> <body> <h1>안녕하세요!</h1> <p>Nginx 웹서버가 정상적으로 동작하고 있습니다.</p> </body> </html>

Ctrl + X → Y → Enter로 저장합니다. 브라우저에서 다시 새로고침하면 직접 작성한 페이지가 표시됩니다.

9. Nginx 기본 파일 구조 이해하기

Nginx를 설치하면 생성되는 주요 파일과 폴더의 역할을 알아두면 앞으로 설정을 변경할 때 도움이 됩니다.

경로설명

/etc/nginx/nginx.conf	Nginx 메인 설정 파일
/etc/nginx/sites-available/	사이트 설정 파일 보관 폴더
/etc/nginx/sites-enabled/	실제 활성화된 사이트 설정
/var/www/html/	기본 웹 파일 저장 위치
/var/log/nginx/access.log	접속 기록 로그
/var/log/nginx/error.log	오류 로그

오류가 발생했을 때 가장 먼저 확인해야 할 파일은 /var/log/nginx/error.log입니다. 아래 명령어로 실시간으로 확인할 수 있습니다.

sudo tail -f /var/log/nginx/error.log

10. 정리

오늘 진행한 실습을 정리합니다.

sudo apt install nginx -y 명령으로 Nginx를 설치했습니다.
systemctl start와 systemctl enable로 서버를 시작하고 자동 시작을 등록했습니다.
UFW와 클라우드 보안 그룹에서 80번 포트를 허용했습니다.
브라우저에서 서버 IP로 접속해 Nginx 기본 페이지 확인 후, 직접 만든 HTML 파일로 교체했습니다.

서버에 웹페이지를 올리는 가장 기본적인 과정을 완성했습니다.

리눅스 명령어 딱 10개만 알면 서버 운영 가능하다

테크 한 스푼 — Mon, 25 May 2026 16:47:13 +0900

1. 리눅스 명령어, 다 외울 필요 없다

서버를 처음 접하는 분들이 가장 두려워하는 것 중 하나가 바로 검은 화면에 글자만 가득한 터미널입니다. 리눅스 명령어가 수백 가지가 넘는다는 이야기를 들으면 더 막막하게 느껴지기도 합니다.

하지만 실제로 서버를 운영하면서 반복적으로 사용하는 명령어는 생각보다 많지 않습니다. 핵심 명령어 10개만 확실히 익혀두면, 기본적인 서버 관리 업무의 80% 이상을 해결할 수 있습니다.

이 글에서는 처음 서버를 다루는 분들을 위해 꼭 알아야 할 명령어 10개를 실용적인 예시와 함께 설명드립니다.

2. 명령어 사용 전 알아야 할 기본 규칙

명령어를 배우기 전에 터미널의 기본 규칙 몇 가지를 알아두면 훨씬 이해하기 쉽습니다.

프롬프트(prompt) 읽는 법

터미널에서 ubuntu@myserver:~$ 형태의 프롬프트가 표시됩니다. 맨 앞은 현재 사용자 이름(ubuntu), 그 다음은 서버 이름(myserver), 콜론 뒤는 현재 위치(~는 홈 디렉토리), 마지막 기호가 $이면 일반 사용자, #이면 root 계정입니다.

sudo란? sudo는 "관리자 권한으로 실행"을 의미합니다. 시스템 설정을 변경하거나 패키지를 설치할 때 앞에 붙여야 합니다. 예: sudo apt install nginx

경로 표기법

/ 로 시작하면 절대 경로 (예: /var/www/html)
./ 로 시작하면 현재 위치 기준 상대 경로
~ 는 홈 디렉토리 (예: ~/downloads = /home/ubuntu/downloads)

3. 핵심 명령어 10개 완전 정복

명령어 1. pwd – 현재 위치 확인

Print Working Directory의 약자로, 현재 내가 어디 있는지 전체 경로를 출력합니다.

pwd

서버에서 작업하다 보면 현재 위치를 잊어버리기 쉽습니다. 헷갈릴 때마다 pwd를 입력하는 습관을 들이면 좋습니다.

명령어 2. ls – 파일 및 폴더 목록 보기

List의 약자로, 현재 위치의 파일과 폴더 목록을 보여줍니다. 기본 목록은 아래와 같이 입력합니다.

상세 정보(크기, 권한, 날짜)를 포함해서 보려면 -l 옵션을 붙입니다.

ls -l

숨김 파일(.으로 시작하는 파일)까지 포함해서 보려면 -al 옵션을 사용합니다.

ls -al

서버에서 가장 많이 쓰는 옵션은 ls -al입니다. 파일 권한, 소유자, 크기, 수정 날짜까지 한 번에 확인할 수 있습니다.

명령어 3. cd – 폴더 이동

Change Directory의 약자입니다. 절대 경로로 이동할 때는 아래와 같이 입력합니다.

cd /var/www/html

현재 위치의 하위 폴더로 이동할 때입니다.

cd myproject

상위 폴더로 이동할 때는 ..을 사용합니다.

cd ..

홈 디렉토리로 바로 이동하려면 ~를 사용합니다.

cd ~

명령어 4. mkdir – 폴더 만들기

Make Directory의 약자입니다.

mkdir myproject

중간 폴더가 없어도 한 번에 생성하려면 -p 옵션을 사용합니다.

mkdir -p a/b/c

명령어 5. rm – 파일 및 폴더 삭제

Remove의 약자입니다. 삭제된 파일은 휴지통 없이 바로 영구 삭제되므로 신중하게 사용해야 합니다.

파일을 삭제할 때입니다.

rm 파일명

폴더와 내용을 모두 삭제할 때는 -r 옵션을 사용합니다.

rm -r 폴더명

rm -rf / 처럼 잘못된 경로를 입력하면 서버 전체가 삭제될 수 있으므로, -rf 옵션은 항상 경로를 두 번 확인하고 실행해야 합니다.

명령어 6. cat – 파일 내용 보기

Concatenate의 약자로, 파일 내용을 터미널에 바로 출력합니다.

cat config.txt

파일이 길 경우 less 명령어를 사용하면 페이지 단위로 볼 수 있습니다. 방향키로 스크롤하고 q로 종료합니다.

less /var/log/nginx/access.log

명령어 7. cp / mv – 복사 및 이동

파일을 복사할 때는 cp를 사용합니다.

cp 원본파일 복사본파일

폴더째로 복사할 때는 -r 옵션을 추가합니다.

cp -r 원본폴더/ 복사본폴더/

파일 이름을 변경하거나 다른 위치로 이동할 때는 mv를 사용합니다.

mv 파일명 새파일명 mv 파일명 /var/www/html/

명령어 8. nano – 파일 편집

서버에서 파일을 직접 편집할 때 초보자에게 가장 쉬운 에디터는 nano입니다.

nano 파일명

시스템 파일을 편집할 때는 sudo를 앞에 붙입니다.

sudo nano /etc/hosts

nano 실행 후 편집이 끝나면 Ctrl + X → Y → Enter 순서로 저장하고 종료합니다.

명령어 9. systemctl – 서비스 관리

서버에서 실행 중인 서비스(Nginx, MySQL 등)를 시작, 중지, 재시작할 때 사용합니다.

서비스를 시작합니다.

sudo systemctl start nginx

서비스를 중지합니다.

sudo systemctl stop nginx

서비스를 재시작합니다.

sudo systemctl restart nginx

현재 상태를 확인합니다.

sudo systemctl status nginx

서버 재부팅 시 자동 시작을 등록합니다.

sudo systemctl enable nginx

서버를 운영하다 보면 systemctl restart와 systemctl status를 가장 자주 사용하게 됩니다.

명령어 10. tail – 로그 실시간 확인

로그 파일의 최근 내용을 확인하거나, 실시간으로 업데이트되는 로그를 모니터링할 때 사용합니다. 마지막 50줄을 출력하려면 아래와 같이 입력합니다.

tail -n 50 /var/log/nginx/error.log

실시간으로 로그를 모니터링할 때는 -f 옵션을 사용합니다.

tail -f /var/log/nginx/access.log

서버에서 오류가 났을 때 가장 먼저 실행하는 명령어 중 하나입니다. Ctrl + C로 모니터링을 종료합니다.

4. 명령어를 조합하면 더 강력해진다

리눅스 명령어는 파이프(|)로 연결해서 조합할 수 있습니다. 파이프는 앞 명령어의 결과를 뒤 명령어의 입력으로 넘겨줍니다.

로그에서 "error"가 포함된 줄만 필터링해서 보는 예시입니다.

cat /var/log/nginx/error.log | grep "error"

현재 폴더의 파일 중 .conf 확장자만 보는 방법입니다.

ls -al | grep ".conf"

실시간 로그에서 특정 IP 접속만 모니터링할 때입니다.

tail -f access.log | grep "123.45.67.89"

5. 자주 발생하는 실수와 해결법

Permission denied 오류 권한이 없는 파일이나 폴더에 접근할 때 나타납니다. 앞에 sudo를 붙여 실행하면 해결되는 경우가 많습니다.

command not found 오류 해당 프로그램이 설치되어 있지 않거나 명령어 철자가 틀렸을 때 나타납니다. sudo apt install 프로그램명으로 설치할 수 있습니다.

No such file or directory 오류 입력한 경로나 파일명이 존재하지 않을 때 나타납니다. ls로 파일 목록을 확인하고 경로를 다시 입력해 보세요.

6. 정리

오늘 배운 10개의 핵심 명령어를 한눈에 정리합니다.

명령어기능

pwd	현재 위치 확인
ls	파일·폴더 목록 보기
cd	폴더 이동
mkdir	폴더 생성
rm	파일·폴더 삭제
cat / less	파일 내용 보기
cp / mv	복사·이동·이름변경
nano	파일 편집
systemctl	서비스 관리
tail	로그 확인

이 10개 명령어를 직접 타이핑하며 연습하는 것이 가장 빠른 방법입니다.

서버에서 파일 업로드·다운로드하는 방법 – SFTP 완전 정복

테크 한 스푼 — Mon, 25 May 2026 16:46:10 +0900

1. 서버에 파일을 옮겨야 하는 순간

서버를 운영하다 보면 반드시 파일을 주고받아야 하는 상황이 생깁니다.

예를 들어 내 컴퓨터에서 개발한 웹사이트 파일을 서버에 올리거나, 서버에 있는 로그 파일이나 백업 파일을 내 컴퓨터로 내려받아야 하는 경우가 대표적입니다. 혹은 서버의 설정 파일을 수정하기 위해 로컬로 내려받고, 수정 후 다시 올리는 작업을 반복하기도 합니다.

이런 상황에서 사용하는 대표적인 방법이 바로 SFTP와 SCP입니다.

2. SFTP란 무엇인가?

**SFTP(SSH File Transfer Protocol)**는 SSH를 기반으로 파일을 안전하게 전송하는 프로토콜입니다.

앞서 배운 SSH가 서버에서 명령어를 실행하는 원격 접속 도구라면, SFTP는 SSH의 보안 연결을 그대로 활용해 파일을 주고받는 전용 채널이라고 볼 수 있습니다.

SFTP의 특징을 정리하면, SSH와 동일한 22번 포트를 사용하고, 모든 파일 전송이 암호화됩니다. SSH 키 인증을 그대로 사용할 수 있으며, SSH만 설정되어 있으면 별도의 추가 설정 없이 바로 사용 가능합니다.

3. FTP vs SFTP – 무엇이 다른가?

SFTP를 이해하려면 기존의 FTP와 비교해 보는 것이 좋습니다.

구분FTPSFTP

풀네임	File Transfer Protocol	SSH File Transfer Protocol
암호화	없음 (평문 전송)	있음 (SSH 암호화)
포트	21번	22번 (SSH와 동일)
보안	취약	안전
현재 권장 여부	비권장	권장

FTP는 파일 전송 시 내용이 암호화되지 않아, 네트워크 감청 시 파일 내용과 계정 정보가 노출될 수 있습니다. 반면 SFTP는 SSH 보안 채널 위에서 동작하므로 훨씬 안전합니다. 현재는 특별한 이유가 없다면 SFTP 사용을 권장합니다.

4. 방법 1 – 터미널에서 SFTP 명령어로 전송

Mac, Linux, Windows 터미널 모두에서 sftp 명령어를 사용할 수 있습니다.

기본 접속 방법입니다.

sftp 사용자명@서버IP주소

SSH 키 파일을 사용하는 경우 -i 옵션을 추가합니다.

sftp -i 키파일경로.pem 사용자명@서버IP주소

접속하면 sftp> 프롬프트가 나타납니다. 이후 아래 명령어로 파일을 주고받을 수 있습니다.

서버에 파일을 업로드(내 컴퓨터 → 서버)합니다.

put index.html

폴더째로 업로드할 경우 -r 옵션을 사용합니다.

put -r 로컬폴더명/

서버에서 파일을 다운로드(서버 → 내 컴퓨터)합니다.

get /var/log/nginx/access.log

폴더째로 다운로드할 경우입니다.

get -r 서버폴더명/

접속을 종료할 때는 아래 명령어를 입력합니다.

exit

5. 방법 2 – FileZilla로 GUI 파일 전송

명령어가 익숙하지 않다면 FileZilla를 사용하는 것이 훨씬 편리합니다. FileZilla는 드래그 앤 드롭으로 파일을 전송할 수 있는 무료 FTP/SFTP 클라이언트입니다.

FileZilla 설치 및 접속 방법은 아래 순서를 따릅니다.

FileZilla 공식 사이트에서 무료로 다운로드 후 설치합니다.
상단 메뉴에서 파일 > 사이트 관리자를 엽니다.
새 사이트 버튼을 클릭합니다.
아래와 같이 정보를 입력합니다.

항목입력값

프로토콜	SFTP – SSH File Transfer Protocol
호스트	서버 IP 주소
포트	22 (또는 변경한 포트)
로그온 유형	키 파일 (SSH 키 사용 시)
사용자	사용자명 (예: ubuntu)
키 파일	.pem 파일 경로 선택

연결 버튼을 클릭하면 접속됩니다.
왼쪽 패널(내 컴퓨터)과 오른쪽 패널(서버) 사이에서 파일을 드래그 앤 드롭으로 전송합니다.

6. 방법 3 – SCP 명령어로 빠르게 전송

**SCP(Secure Copy Protocol)**는 SSH를 이용한 파일 복사 명령어입니다. SFTP처럼 대화형 세션을 열지 않고, 한 줄 명령어로 파일을 바로 전송할 수 있어 간단한 작업에 적합합니다.

내 컴퓨터에서 서버로 파일을 전송하는 기본 형태입니다.

scp 로컬파일경로 사용자명@서버IP:서버경로

index.html 파일을 서버의 /var/www/html/ 폴더로 전송하는 예시입니다.

scp index.html ubuntu@123.45.67.89:/var/www/html/

SSH 키 파일을 사용할 경우 -i 옵션을 추가합니다.

scp -i 키파일.pem index.html ubuntu@123.45.67.89:/var/www/html/

폴더째로 전송할 때는 -r 옵션을 사용합니다.

scp -r ./myproject ubuntu@123.45.67.89:/home/ubuntu/

반대로 서버에서 내 컴퓨터로 파일을 내려받는 방법입니다.

scp ubuntu@123.45.67.89:/var/log/nginx/access.log ~/downloads/

7. 어떤 방법을 선택해야 할까?

상황추천 방법

명령어가 익숙하고 빠르게 처리하고 싶을 때	SCP
여러 파일을 골라서 전송하거나 관리할 때	SFTP 또는 FileZilla
명령어가 불편하고 GUI가 편한 초보자	FileZilla
자동화 스크립트에 파일 전송을 포함할 때	SCP 또는 SFTP

처음에는 FileZilla로 시작해서 파일 구조에 익숙해지고, 이후 SCP나 SFTP 명령어로 넘어가는 것을 추천드립니다.

8. 정리

오늘 배운 핵심을 정리합니다.

SFTP는 SSH 기반의 안전한 파일 전송 프로토콜로, 암호화된 채널로 파일을 주고받습니다.
FTP는 암호화가 없어 보안에 취약하므로, 현재는 SFTP 사용을 권장합니다.
터미널에서 sftp 명령어, GUI 도구인 FileZilla, 한 줄 명령어 SCP 세 가지 방법을 상황에 맞게 사용할 수 있습니다.
처음이라면 FileZilla로 시작해 드래그 앤 드롭으로 편리하게 파일을 관리해 보세요.

처음 서버 받았을 때 가장 먼저 해야 할 설정 5가지

테크 한 스푼 — Mon, 25 May 2026 16:45:11 +0900

1. 서버를 받았는데 뭐부터 해야 할까?

AWS, GCP, 카페24 등에서 서버를 처음 생성하면, 그야말로 아무것도 없는 빈 컴퓨터가 하나 생깁니다. 운영체제(주로 Ubuntu)만 설치되어 있고, 아무런 서비스도 설치되어 있지 않습니다.

이 상태로 바로 서비스를 올리면 보안에 매우 취약합니다. 인터넷에 연결된 서버는 생성되는 순간부터 전 세계의 해킹 시도에 노출됩니다. 실제로 아무 설정도 하지 않은 채 서버를 방치하면 수 분 안에 로그에 해킹 시도 흔적이 남기 시작합니다.

이 글에서는 서버를 처음 받았을 때 가장 먼저 해야 할 기본 설정 5가지를 순서대로 설명드립니다. 이 글의 예시는 Ubuntu 서버를 기준으로 합니다.

2. 설정 1 – 패키지 업데이트

서버를 받으면 가장 먼저 해야 할 일은 시스템 패키지를 최신 상태로 업데이트하는 것입니다. 서버 이미지가 만들어진 시점과 지금 사이에 보안 취약점이 발견되고 패치가 배포됐을 수 있기 때문입니다.

패키지 목록을 새로고침합니다.

sudo apt update

이어서 모든 패키지를 최신 버전으로 업그레이드합니다.

sudo apt upgrade -y

apt update는 "어떤 업데이트가 있는지 확인"하는 명령이고, apt upgrade는 "실제로 업데이트를 적용"하는 명령입니다. 이 두 명령어는 항상 세트로 사용합니다.

업데이트가 완료되면 재부팅을 권장합니다.

sudo reboot

재부팅 후 SSH로 다시 접속하면 됩니다.

3. 설정 2 – 새로운 사용자 계정 생성 (root 직접 사용 금지)

처음 서버에 접속하면 root 계정으로 로그인하게 되는 경우가 많습니다. root는 서버의 모든 권한을 가진 최고 관리자 계정입니다.

그런데 root 계정을 직접 사용하는 것은 위험합니다. 실수로 중요한 파일을 삭제하거나, 해커가 root 계정을 탈취할 경우 서버 전체가 장악될 수 있기 때문입니다.

따라서 일반 사용자 계정을 만들고, 필요할 때만 sudo 명령을 통해 관리자 권한을 사용하는 것이 안전합니다.

새 사용자를 생성합니다. (myuser 자리에 원하는 이름 입력)

adduser myuser

생성한 계정에 sudo 권한을 부여합니다.

usermod -aG sudo myuser

새 계정으로 전환해서 sudo가 정상 동작하는지 확인합니다.

su - myuser sudo apt update

이후 SSH 접속도 root 대신 새로 만든 계정으로 접속하는 것을 권장합니다.

4. 설정 3 – SSH 보안 강화

SSH는 서버 접속의 관문이기 때문에 해커들이 가장 많이 공격하는 지점이기도 합니다. 몇 가지 설정만으로도 보안을 크게 높일 수 있습니다.

SSH 설정 파일을 열어줍니다.

sudo nano /etc/ssh/sshd_config

파일이 열리면 아래 세 가지 항목을 찾아서 수정합니다. root로 직접 SSH 접속을 차단하려면 PermitRootLogin 값을 no로 변경합니다. 비밀번호 인증을 비활성화하고 키 인증만 허용하려면 PasswordAuthentication 값을 no로 변경합니다. SSH 포트를 22 대신 다른 번호(예: 2222)로 바꾸려면 Port 항목을 수정합니다.

설정을 저장한 후 SSH 서비스를 재시작합니다.

sudo systemctl restart sshd

주의: 포트를 변경한 경우, 방화벽에서도 새 포트를 열어줘야 합니다. 그리고 현재 세션을 끊기 전에 새 포트로 접속이 되는지 먼저 확인해야 합니다. 확인 없이 세션을 끊으면 서버에 접속할 수 없게 될 수 있습니다.

5. 설정 4 – 방화벽(UFW) 설정

**UFW(Uncomplicated Firewall)**는 Ubuntu에서 쉽게 방화벽을 설정할 수 있게 해주는 도구입니다. 방화벽은 불필요한 포트로의 접근을 차단해 서버를 보호합니다.

먼저 현재 UFW 상태를 확인합니다.

sudo ufw status

SSH 포트를 허용합니다. 기본 22번을 사용하는 경우입니다.

sudo ufw allow 22

포트를 변경했다면 해당 번호로 허용합니다.

sudo ufw allow 2222

웹 서비스를 운영할 경우 HTTP와 HTTPS 포트도 허용합니다.

sudo ufw allow 80 sudo ufw allow 443

UFW를 활성화합니다.

sudo ufw enable

UFW를 활성화하면 허용한 포트 외의 모든 접속이 차단됩니다. 활성화 전에 반드시 SSH 포트를 허용해야 현재 접속이 끊기지 않습니다.

방화벽 설정 원칙은 간단합니다. 필요한 포트만 열고, 나머지는 모두 차단하는 것입니다.

6. 설정 5 – 타임존 설정

서버의 기본 타임존은 대부분 UTC(협정 세계시)로 설정되어 있습니다. 국내 서비스를 운영한다면 **한국 시간(KST, Asia/Seoul)**으로 변경하는 것이 좋습니다. 로그 파일의 시간, 데이터베이스에 저장되는 시간 등이 모두 서버 타임존을 기준으로 기록되기 때문입니다.

현재 타임존을 확인합니다.

timedatectl

타임존을 서울로 변경합니다.

sudo timedatectl set-timezone Asia/Seoul

변경 후 다시 확인합니다.

timedatectl

Time zone: Asia/Seoul (KST, +0900)처럼 표시되면 정상입니다.

7. 설정 완료 후 체크리스트

5가지 설정을 모두 마쳤다면 아래 항목을 한 번씩 확인해 보세요.

항목확인 방법기대 결과

패키지 업데이트	apt list --upgradable	업그레이드 대상 없음
사용자 계정	id myuser	uid, gid 정보 출력
SSH 설정	sudo sshd -T \| grep permitrootlogin	permitrootlogin no
방화벽	sudo ufw status	필요한 포트만 ALLOW
타임존	timedatectl	Asia/Seoul (KST)

8. 정리

처음 서버를 받았을 때 꼭 해야 할 5가지 설정을 정리합니다.

패키지 업데이트: 보안 취약점 패치 적용
사용자 계정 생성: root 직접 사용 금지, 일반 계정 + sudo 방식으로 운영
SSH 보안 강화: root 로그인 차단, 비밀번호 인증 비활성화, 포트 변경
방화벽 설정: 필요한 포트만 열고 나머지는 차단
타임존 설정: 한국 서비스라면 Asia/Seoul로 변경

이 5가지만 해도 서버의 기본적인 보안 수준이 크게 높아집니다.

SSH가 뭔지 모르는 초보를 위한 개념 + 접속 방법

테크 한 스푼 — Mon, 25 May 2026 16:44:24 +0900

1. SSH가 왜 필요한가?

서버는 대부분 멀리 떨어진 데이터센터에 있습니다. 물리적으로 그 서버 앞에 앉아서 작업할 수 없으니, 원격으로 서버에 접속해서 명령을 내릴 수 있는 방법이 필요합니다.

예를 들어 AWS나 카페24 같은 곳에서 서버를 빌렸다면, 그 서버는 어딘가의 건물 안에 있습니다. 직접 가서 키보드를 연결할 수는 없으니, 인터넷을 통해 원격으로 접속해야 합니다. 이때 사용하는 것이 바로 SSH입니다.

2. SSH의 정확한 정의

**SSH(Secure Shell)**는 네트워크를 통해 다른 컴퓨터(서버)에 안전하게 원격 접속할 수 있게 해주는 프로토콜입니다.

여기서 핵심 단어는 두 가지입니다.

원격 접속: 인터넷을 통해 멀리 있는 서버를 내 컴퓨터처럼 조작할 수 있습니다. 서버에 파일을 만들고, 프로그램을 설치하고, 서비스를 실행하는 등 모든 작업이 가능합니다.

안전하게(Secure): SSH는 모든 통신 내용을 암호화합니다. 누군가 중간에서 데이터를 가로채도 내용을 알아볼 수 없습니다.

쉬운 비유

SSH는 보안이 완벽한 원격 조종기와 같습니다. 마치 드론을 조종하듯, 멀리 있는 서버를 내 손안에서 직접 조작하는 것입니다. 그리고 그 조종 신호는 완전히 암호화되어 있어서 외부에서 해독할 수 없습니다.

3. SSH 이전에는 어떻게 접속했나? – Telnet과의 비교

SSH가 등장하기 전에는 Telnet이라는 프로토콜을 사용했습니다. Telnet도 원격 접속을 가능하게 했지만, 치명적인 문제가 있었습니다.

바로 암호화가 없다는 점입니다. Telnet으로 서버에 접속하면 아이디, 비밀번호, 모든 명령어가 **평문(암호화되지 않은 텍스트)**으로 전송됩니다. 해커가 네트워크를 감청하면 비밀번호를 그대로 훔쳐볼 수 있는 것입니다.

구분TelnetSSH

암호화	없음 (평문 전송)	있음 (강력한 암호화)
보안	매우 취약	안전
현재 사용	거의 안 씀	표준으로 사용
기본 포트	23	22

이런 보안 문제를 해결하기 위해 1995년 SSH가 개발되었고, 현재는 서버 원격 접속의 표준 방식이 되었습니다.

4. SSH 접속에 필요한 것들

SSH로 서버에 접속하려면 다음 정보가 필요합니다.

서버의 IP 주소 또는 도메인 접속할 서버의 주소입니다. AWS EC2라면 퍼블릭 IP 주소, 호스팅 서비스라면 제공받은 서버 주소입니다.

포트 번호 SSH 기본 포트는 22번입니다. 관리자가 보안상 변경하지 않았다면 22번을 사용합니다.

사용자 이름(Username) 서버에 등록된 계정 이름입니다. AWS EC2 Ubuntu 서버라면 기본값이 ubuntu, Amazon Linux라면 ec2-user입니다.

인증 방법: 비밀번호 또는 SSH 키 SSH 접속 인증 방식은 두 가지입니다.

비밀번호 인증: 간단하지만 보안이 상대적으로 약함
SSH 키 인증: 공개키/개인키 쌍을 이용한 방식으로 훨씬 안전하며, AWS EC2는 이 방식을 기본으로 사용

5. Windows에서 SSH 접속하는 방법

과거에는 Windows에서 SSH를 사용하려면 PuTTY 같은 별도 프로그램을 설치해야 했습니다. 하지만 Windows 10 이후부터는 기본으로 SSH 클라이언트가 내장되어 있습니다.

방법 1. Windows 터미널 (명령 프롬프트 / PowerShell) 사용

기본 접속(비밀번호 인증)은 아래 형태로 입력합니다.

ssh 사용자명@서버IP주소

실제 예시는 다음과 같습니다.

ssh ubuntu@123.45.67.89

SSH 키 파일을 사용하는 경우 -i 옵션으로 키 파일 경로를 지정합니다.

ssh -i 키파일경로.pem 사용자명@서버IP주소

AWS EC2 접속 예시입니다.

ssh -i C:\Users\myname\downloads\mykey.pem ubuntu@123.45.67.89

방법 2. PuTTY 사용 (GUI 방식 선호 시)

PuTTY는 그래픽 인터페이스로 SSH 접속을 도와주는 무료 프로그램입니다. 명령어가 익숙하지 않은 분들에게 적합합니다.

PuTTY 공식 사이트에서 다운로드 후 설치
Host Name 항목에 서버 IP 주소 입력
Port에 22 입력
Connection type에서 SSH 선택
Open 클릭 후 사용자명과 비밀번호 입력

6. Mac / Linux에서 SSH 접속하는 방법

Mac과 Linux는 기본적으로 SSH 클라이언트가 내장되어 있어서 터미널을 열고 바로 사용할 수 있습니다.

기본 접속 형태입니다.

ssh 사용자명@서버IP주소

실제 예시입니다.

ssh ubuntu@123.45.67.89

SSH 키 파일을 사용할 경우 아래와 같이 입력합니다.

ssh -i ~/downloads/mykey.pem ubuntu@123.45.67.89

SSH 키 파일 권한 오류 해결

처음 SSH 키 파일을 사용할 때 WARNING: UNPROTECTED PRIVATE KEY FILE! / Permissions 0644 for 'mykey.pem' are too open. 같은 오류가 발생할 수 있습니다.

이때는 아래 명령어로 키 파일의 권한을 변경해 주면 해결됩니다.

chmod 400 ~/downloads/mykey.pem

이 명령어는 키 파일을 나만 읽을 수 있도록 권한을 제한합니다.

7. SSH 접속 후 자주 쓰는 기본 명령어

SSH로 서버에 접속하면 터미널 화면만 나타납니다. 당황하지 말고, 아래 기본 명령어만 알면 기본적인 작업이 가능합니다.

명령어기능예시

pwd	현재 위치 확인	pwd
ls	파일 목록 보기	ls -al
cd	폴더 이동	cd /home/ubuntu
mkdir	폴더 만들기	mkdir myproject
rm	파일/폴더 삭제	rm -rf myproject
cat	파일 내용 보기	cat config.txt
exit	SSH 접속 종료	exit

8. 정리

오늘 배운 핵심을 정리합니다.

SSH는 원격 서버에 안전하게 접속하기 위한 프로토콜입니다.
Telnet과 달리 모든 통신이 암호화되어 보안이 강력합니다.
접속에는 서버 IP, 포트(기본 22), 사용자명, 인증 수단이 필요합니다.
Windows, Mac, Linux 모두 터미널에서 ssh 사용자명@IP주소 형태로 접속합니다.
AWS처럼 키 파일을 사용하는 경우 -i 키파일경로 옵션을 추가합니다.

클라이언트-서버 구조가 뭔지 그림으로 이해하기

테크 한 스푼 — Mon, 25 May 2026 16:37:37 +0900

1. 클라이언트-서버 구조란?

인터넷에서 이루어지는 거의 모든 통신은 **클라이언트-서버 구조(Client-Server Architecture)**를 기반으로 합니다. 스마트폰으로 유튜브를 보거나, 노트북으로 온라인 쇼핑을 하거나, 게임 앱을 실행할 때도 이 구조가 동작합니다.

클라이언트-서버 구조는 이름 그대로 **클라이언트(요청하는 쪽)**와 서버(응답하는 쪽), 두 가지 역할로 나뉩니다.

이 두 역할이 어떻게 소통하는지 이해하면, 인터넷과 서버에 대한 이해가 한 단계 깊어집니다.

2. 클라이언트란 무엇인가?

**클라이언트(Client)**는 서버에게 무언가를 요청하는 쪽입니다.

우리가 매일 사용하는 다음과 같은 것들이 모두 클라이언트입니다.

웹 브라우저: Chrome, Safari, Edge – 웹사이트를 요청
스마트폰 앱: 카카오톡, 인스타그램, 배달앱 – 데이터를 요청
게임 클라이언트: 리그 오브 레전드, 배틀그라운드 – 게임 서버에 요청
스마트 TV: 넷플릭스 앱 – 동영상 스트리밍 데이터를 요청

클라이언트의 특징

항상 먼저 요청을 보내는 쪽입니다.
사용자가 직접 보고 조작하는 인터페이스를 가집니다.
서버 없이는 대부분의 기능이 작동하지 않습니다.
성능이 서버보다 낮아도 됩니다.

3. 서버란 무엇인가? (역할 복습)

**서버(Server)**는 클라이언트의 요청을 받아 처리하고 응답하는 쪽입니다.

서버는 클라이언트와 달리 다음과 같은 특성이 있습니다.

항상 켜져 있습니다: 클라이언트가 언제 요청을 보낼지 모르기 때문
동시에 수많은 요청을 처리합니다: 수천, 수백만 명의 요청을 동시에 처리
사용자 인터페이스가 없습니다: 모니터나 키보드 없이 운영되는 경우가 많음
고성능 하드웨어를 사용합니다: 많은 요청을 빠르게 처리하기 위해

4. 요청과 응답 – 두 주인공의 대화

클라이언트와 서버의 통신은 항상 요청(Request) → 응답(Response) 패턴으로 이루어집니다.

기본 흐름

이 패턴은 단순해 보이지만, 실제로는 다양한 종류의 요청과 응답이 오갑니다.

HTTP 요청의 종류 (메서드)

웹에서 클라이언트가 서버에 보내는 요청은 목적에 따라 종류가 나뉩니다.

메서드의미예시

GET	데이터를 달라	게시글 목록 불러오기
POST	데이터를 저장해줘	회원가입, 글 작성
PUT	데이터를 수정해줘	프로필 정보 수정
DELETE	데이터를 삭제해줘	게시글 삭제

HTTP 응답 코드

서버는 요청을 처리한 후, 결과를 숫자 코드로 함께 전달합니다.

상태 코드의미설명

200	OK	요청 성공
201	Created	새 데이터 생성 성공
301	Moved Permanently	주소가 영구 이동됨
400	Bad Request	잘못된 요청
401	Unauthorized	인증 필요
403	Forbidden	접근 권한 없음
404	Not Found	요청한 페이지 없음
500	Internal Server Error	서버 내부 오류

"404 Not Found"나 "500 Internal Server Error"는 웹사이트를 사용하다 한 번쯤 봤을 것입니다. 이제 이 숫자들이 무슨 의미인지 알 수 있겠죠?

5. 실생활에서 보는 클라이언트-서버 구조

예시 1. 인스타그램 피드 새로고침

[클라이언트 - 스마트폰 앱]
사용자가 피드 새로고침 → 앱이 서버에 요청
"최근 게시물 20개 주세요"

[서버 - 인스타그램 서버]
DB에서 팔로잉 계정의 최근 게시물 조회
→ 게시물 데이터(이미지, 텍스트, 좋아요 수) 응답

[클라이언트 - 스마트폰 앱]
받은 데이터를 화면에 표시

예시 2. 배달앱 주문

[클라이언트 - 배달앱]
메뉴 선택 후 주문 버튼 클릭 → 서버에 요청
"치킨 1마리, 주소 서울시 강남구 XX로, 결제 카드"

[서버 - 배달 플랫폼 서버]
① 결제 서버에 결제 요청
② 주문 데이터를 DB에 저장
③ 가게 서버에 주문 알림 전송
→ "주문 접수 완료" 응답

[클라이언트 - 배달앱]
"주문이 완료되었습니다" 화면 표시

예시 3. 온라인 게임 캐릭터 이동

[클라이언트 - 게임 프로그램]
플레이어가 캐릭터를 오른쪽으로 이동
"캐릭터 위치: X=150, Y=200으로 이동"

[게임 서버]
위치 유효성 검사 (벽인지, 다른 캐릭터인지 확인)
→ "이동 승인, 현재 위치 X=150, Y=200" 응답
→ 같은 공간의 다른 플레이어들에게도 위치 전파

[클라이언트 - 다른 플레이어 화면]
상대 캐릭터가 이동하는 모습 표시

6. 클라이언트-서버 구조의 장점과 단점

장점

중앙 집중 관리 데이터가 서버 한 곳에 저장되므로, 모든 클라이언트가 항상 최신 데이터를 공유할 수 있습니다. 카카오톡 메시지를 폰에서 보내도 PC에서 확인할 수 있는 이유입니다.

확장성 사용자가 늘어나도 서버를 증설하는 방식으로 대응할 수 있습니다. 클라이언트(앱)를 수정하지 않아도 됩니다.

보안 중요한 데이터와 로직이 서버에 있기 때문에, 클라이언트(앱, 브라우저) 측으로 노출되지 않아 보안 관리가 용이합니다.

단점

서버 장애 시 전체 서비스 중단 서버가 다운되면 모든 클라이언트가 서비스를 이용할 수 없습니다. "서버 점검 중입니다"라는 메시지가 뜨는 이유입니다.

서버 비용 항상 켜져 있고 많은 요청을 처리해야 하는 서버를 운영하는 데는 상당한 비용이 듭니다.

네트워크 의존성 인터넷 연결이 없으면 대부분의 기능을 사용할 수 없습니다.

7. 다른 구조와의 비교 – P2P란?

클라이언트-서버 구조 외에 P2P(Peer-to-Peer) 구조도 있습니다. P2P는 중앙 서버 없이 참여자들끼리 직접 연결하는 방식입니다.

구분클라이언트-서버P2P

중심	중앙 서버 존재	중앙 서버 없음
특징	관리 용이, 보안 좋음	서버 비용 없음, 장애에 강함
예시	웹사이트, 앱, 게임	토렌트, 블록체인
단점	서버 장애 시 전체 중단	관리 어려움, 속도 불안정

현재 인터넷 서비스의 대부분은 클라이언트-서버 구조를 사용하며, P2P는 파일 공유나 블록체인 같은 특수한 목적에 활용됩니다.

8. 정리

오늘 배운 핵심을 정리합니다.

클라이언트: 요청을 보내는 쪽 (브라우저, 앱, 게임 프로그램 등)
서버: 요청을 받아 처리하고 응답하는 쪽 (항상 켜져 있음)
통신은 항상 요청(Request) → 응답(Response) 패턴으로 이루어집니다.
HTTP 메서드로 요청 목적을 구분하고 (GET, POST, PUT, DELETE), 상태 코드로 결과를 전달합니다 (200, 404, 500 등).
클라이언트-서버 구조는 중앙 집중 관리, 확장성, 보안 측면에서 장점이 있지만, 서버 장애 시 전체 서비스가 중단되는 단점도 있습니다.

포트(Port)란 무엇인가 – 80, 443, 3306 숫자의 의미

테크 한 스푼 — Mon, 25 May 2026 16:35:31 +0900

1. 포트라는 개념이 왜 필요한가?

앞선 글에서 IP 주소와 도메인에 대해 배웠습니다. IP 주소 덕분에 우리는 특정 서버 컴퓨터를 찾아갈 수 있게 되었죠.

그런데 한 가지 문제가 있습니다. 하나의 서버 컴퓨터에서는 보통 여러 가지 서비스가 동시에 실행됩니다. 예를 들어, 하나의 서버에서 웹사이트도 운영하고, 이메일 서버도 돌리고, 데이터베이스도 실행할 수 있습니다.

IP 주소만으로는 "이 서버에 연결하겠다"는 것만 알 수 있고, 서버 안의 어떤 서비스에 연결할지는 알 수 없습니다.

이 문제를 해결하기 위해 등장한 것이 바로 **포트(Port)**입니다.

2. 포트(Port)의 정의

**포트(Port)**는 하나의 서버(컴퓨터)에서 여러 서비스를 구분하기 위한 번호입니다.

쉬운 비유 1 – 아파트 호수

IP 주소를 아파트 단지의 주소라고 한다면, 포트 번호는 **호수(동·호수)**입니다.

IP 주소 = 서울시 강남구 테헤란로 123 (아파트 단지 주소)
포트 번호 = 101동 202호 (특정 집)

같은 아파트 주소라도 101동 202호, 101동 203호는 다른 집이듯, 같은 IP 주소라도 포트 번호가 다르면 다른 서비스에 연결됩니다.

쉬운 비유 2 – 회사 내선 번호

회사의 대표 전화번호가 IP 주소라면, 각 부서의 내선 번호가 포트 번호입니다.

대표 번호 (IP): 02-1234-5678
내선 100번 (포트 80): 웹 서비스 담당 부서
내선 200번 (포트 443): 보안 웹 서비스 담당 부서
내선 300번 (포트 3306): 데이터베이스 담당 부서

3. 포트 번호의 범위와 분류

포트 번호는 0부터 65535까지 총 65536개가 있습니다. 이 범위는 크게 세 구간으로 나뉩니다.

구분범위설명

잘 알려진 포트 (Well-known)	0 ~ 1023	국제 표준으로 지정된 포트. 주요 서비스에 사용
등록된 포트 (Registered)	1024 ~ 49151	특정 애플리케이션에 등록되어 관례적으로 사용
동적/사설 포트 (Dynamic)	49152 ~ 65535	임시 연결에 자유롭게 사용

개발자나 서버 관리자가 가장 많이 다루는 것은 0~1023 구간의 잘 알려진 포트입니다.

4. 자주 쓰이는 포트 번호 완전 정리

핵심 포트 번호 한눈에 보기

포트 번호프로토콜용도

80	HTTP	일반 웹사이트 접속
443	HTTPS	보안 웹사이트 접속 (SSL/TLS)
22	SSH	서버 원격 접속 (보안 터미널)
21	FTP	파일 전송
25	SMTP	이메일 발송
110	POP3	이메일 수신
143	IMAP	이메일 수신 (최신 방식)
3306	MySQL	MySQL 데이터베이스
5432	PostgreSQL	PostgreSQL 데이터베이스
27017	MongoDB	MongoDB 데이터베이스
6379	Redis	Redis 캐시 서버
3000	Node.js	Node.js 개발 서버 (관례)
8080	HTTP 대체	개발 환경 웹서버 (관례)

각 포트의 자세한 설명

포트 80 (HTTP) 우리가 브라우저에서 http://로 시작하는 주소에 접속할 때 사용하는 포트입니다. 브라우저는 기본적으로 포트 80으로 연결을 시도합니다. 주소창에 포트를 따로 입력하지 않아도 되는 이유가 바로 이 기본값 때문입니다.

포트 443 (HTTPS) https://로 시작하는 보안 연결에 사용되는 포트입니다. 현재 대부분의 웹사이트는 개인정보 보호를 위해 443포트를 사용합니다. 주소창에 자물쇠 아이콘이 표시되면 443포트를 통한 암호화 연결이 이루어진 것입니다.

포트 22 (SSH) 서버를 원격으로 제어할 때 사용하는 포트입니다. 개발자나 서버 관리자가 집에서 원격으로 서버에 접속해 명령어를 실행할 때 SSH를 사용합니다. 보안상 중요한 포트이므로 해킹 시도가 많아, 많은 관리자들이 22번 포트를 다른 번호로 변경해 운영합니다.

포트 3306 (MySQL) MySQL 데이터베이스 서버가 기본으로 사용하는 포트입니다. 앱서버가 데이터베이스에 연결할 때 이 포트를 통해 통신합니다. 보안상 외부에서 직접 접근하지 못하도록 방화벽으로 차단하는 것이 일반적입니다.

5. 포트와 IP 주소는 함께 쓰인다

실제로 서버에 접속할 때는 IP 주소와 포트 번호를 함께 사용합니다. 표기 방식은 다음과 같습니다.

IP주소:포트번호

예시:
192.168.0.1:80    → 192.168.0.1 서버의 웹 서비스
192.168.0.1:3306  → 192.168.0.1 서버의 MySQL 서비스
192.168.0.1:22    → 192.168.0.1 서버의 SSH 서비스

브라우저에서는 HTTP(80)와 HTTPS(443) 포트를 기본으로 사용하기 때문에 평소에는 포트 번호를 입력하지 않아도 됩니다. 하지만 개발 환경에서는 종종 포트를 직접 입력하기도 합니다.

http://localhost:3000 → 내 컴퓨터의 3000번 포트 (Node.js 개발 서버)
http://localhost:8080 → 내 컴퓨터의 8080번 포트 (Spring 개발 서버)

6. 서버에서 포트가 중요한 이유

포트 개념은 단순한 이론이 아닙니다. 실제 서버를 운영할 때 포트는 매우 중요한 역할을 합니다.

방화벽 설정

서버에 방화벽을 설정할 때는 어떤 포트를 열고 닫을지 결정합니다. 웹서버라면 80번, 443번은 열어두고, 외부에서 직접 접근할 필요 없는 3306번(MySQL) 같은 포트는 닫아두는 것이 기본 보안 원칙입니다.

서비스 충돌 방지

같은 서버에서 두 가지 서비스가 동일한 포트를 사용하려 하면 충돌이 발생합니다. 예를 들어, Nginx와 Apache를 같은 서버에서 동시에 80번 포트로 실행할 수 없습니다. 이럴 때는 하나를 8080번 같은 다른 포트로 변경해야 합니다.

보안 강화

SSH 기본 포트인 22번은 해커들이 가장 먼저 공격을 시도하는 포트입니다. 이를 10022번이나 다른 번호로 변경하면 자동화된 공격을 상당 부분 막을 수 있습니다.

7. 정리

오늘 배운 핵심 내용을 정리합니다.

포트는 하나의 서버에서 여러 서비스를 구분하는 번호입니다.
IP 주소가 아파트 단지 주소라면, 포트는 동·호수와 같습니다.
포트 번호는 0~65535까지 있으며, 주요 서비스는 고정된 번호를 사용합니다.
꼭 기억할 포트: 80(HTTP), 443(HTTPS), 22(SSH), 3306(MySQL)
서버 보안을 위해 불필요한 포트는 방화벽으로 차단하는 것이 기본입니다.

IP 주소와 도메인이 뭔지 모르는 사람을 위한 설명

테크 한 스푼 — Mon, 25 May 2026 16:32:29 +0900

1. 인터넷 주소는 원래 숫자였다

우리는 매일 www.google.com, www.naver.com 같은 주소를 입력하며 인터넷을 사용합니다. 이 주소가 너무나 자연스럽다 보니, 처음부터 이런 형태였다고 생각하기 쉽습니다.

하지만 사실 인터넷 세계에서 모든 컴퓨터와 서버는 숫자로 된 주소를 사용합니다. 예를 들어 구글의 실제 주소 중 하나는 142.250.196.100 같은 숫자 조합입니다.

사람이 이 숫자를 매번 외워서 입력하는 건 너무 불편하겠죠? 그래서 등장한 것이 바로 **도메인(Domain)**입니다.

2. IP 주소란 무엇인가?

정의

**IP 주소(Internet Protocol Address)**는 인터넷에 연결된 모든 기기에 부여되는 고유한 숫자 주소입니다. 집 주소처럼, 인터넷에서 특정 서버나 컴퓨터를 찾아가려면 IP 주소가 필요합니다.

IP 주소의 형태

현재 가장 많이 쓰이는 IPv4 주소는 다음과 같이 생겼습니다.

192.168.0.1 / 123.45.67.89

0부터 255 사이의 숫자 4개를 점(.)으로 구분한 형태입니다. 이론적으로 약 43억 개의 주소를 만들 수 있습니다.

그런데 인터넷에 연결되는 기기가 폭발적으로 늘어나면서 43억 개로도 부족해졌습니다. 이를 해결하기 위해 훨씬 더 많은 주소를 담을 수 있는 IPv6도 사용되고 있습니다.

2001:0db8:85a3:0000:0000:8a2e:0370:7334 (IPv6 예시)

내 IP 주소 확인하는 방법

지금 사용 중인 IP 주소가 궁금하다면 구글에서 **"내 IP 주소"**를 검색하면 바로 확인할 수 있습니다.

3. IP 주소의 종류 – 공인 IP vs 사설 IP

IP 주소에는 크게 두 가지 종류가 있습니다. 처음에는 헷갈릴 수 있지만 비유로 쉽게 이해할 수 있습니다.

공인 IP (Public IP)

인터넷에서 전 세계적으로 유일한 주소입니다. 아파트 단지의 도로명 주소와 같습니다. 외부에서 우리 집을 찾아오려면 도로명 주소가 있어야 하듯, 인터넷에서 서버를 찾아가려면 공인 IP가 필요합니다.

사설 IP (Private IP)

집이나 회사 내부 네트워크에서만 사용되는 주소입니다. 아파트 단지 안에서 "101동 302호"처럼 내부에서만 통하는 주소입니다.

구분공인 IP사설 IP

사용 범위	전 세계 인터넷	내부 네트워크(집, 회사)
유일성	전 세계에서 유일	내부에서만 유일
예시	123.45.67.89	192.168.0.x
누가 관리	인터넷 서비스 제공자(ISP)	공유기, 서버 관리자

집에서 공유기를 쓰면 공유기 자체는 하나의 공인 IP를 가지고, 집 안의 스마트폰, 노트북, TV 등은 각각 사설 IP를 부여받습니다.

4. 도메인이란 무엇인가?

정의

**도메인(Domain)**은 IP 주소를 사람이 기억하기 쉬운 문자 형태로 바꾼 것입니다. naver.com, google.com, youtube.com 같은 것들이 모두 도메인입니다.

도메인의 구조

도메인은 오른쪽에서 왼쪽으로 읽으면 계층 구조를 이해하기 쉽습니다.

http://www.naver.com
  │    │   └── 최상위 도메인(TLD): .com, .kr, .net 등
  │    └────── 2차 도메인: naver, google, kakao 등
  └─────────── 서브 도메인: www, mail, blog 등

.com: 상업적 목적의 웹사이트에 주로 사용
.net: 네트워크 관련 기관에서 주로 사용
.org: 비영리 기관에서 주로 사용
.co.kr: 한국의 상업적 목적 웹사이트

서브 도메인 예시

naver.com을 기본 도메인으로 사용하는 네이버는 서비스마다 서브 도메인을 달리 사용합니다.

www.naver.com – 네이버 메인 홈페이지
mail.naver.com – 네이버 메일
blog.naver.com – 네이버 블로그
map.naver.com – 네이버 지도

5. DNS – IP 주소와 도메인을 연결하는 전화번호부

도메인과 IP 주소를 연결해주는 시스템을 **DNS(Domain Name System)**라고 합니다.

쉬운 비유

스마트폰 연락처를 생각해 보세요. 친구에게 전화할 때 우리는 "010-1234-5678"을 외우는 게 아니라 "홍길동"을 검색해서 전화합니다. 스마트폰 연락처가 이름과 전화번호를 매핑해주는 것처럼, DNS는 도메인과 IP 주소를 매핑해줍니다.

DNS가 하는 일

- 사용자: "http://www.naver.com에 접속하고 싶어"
- DNS 서버: "http://www.naver.com은 223.130.192.200이야"
- 브라우저: 223.130.192.200으로 접속

전 세계에는 수많은 DNS 서버가 있으며, 이들이 서로 협력해 도메인-IP 매핑 정보를 관리합니다.

6. 브라우저에서 주소를 입력하면 벌어지는 일

이제 모든 개념을 합쳐서, 브라우저에 www.naver.com을 입력했을 때 어떤 일이 일어나는지 순서대로 살펴보겠습니다.

① 브라우저에 "http://www.naver.com" 입력

② 내 컴퓨터가 DNS 서버에 질문
"http://www.naver.com의 IP 주소가 뭐야?"

③ DNS 서버가 IP 주소 반환
"223.130.192.200이야"

④ 브라우저가 223.130.192.200(네이버 서버)에 접속 요청

⑤ 네이버 서버가 홈페이지 데이터 전송

⑥ 브라우저가 데이터를 받아 화면에 표시

이 모든 과정이 1초도 안 되는 시간 안에 이루어집니다. 인터넷이 빠르고 편리한 이유는 이처럼 잘 설계된 시스템 덕분입니다.

7. 정리

오늘 배운 핵심을 정리해 드립니다.

IP 주소: 인터넷에서 기기를 식별하는 숫자 주소 (예: 192.168.0.1)
공인 IP: 전 세계에서 유일한 주소 / 사설 IP: 내부 네트워크에서만 사용
도메인: IP 주소를 기억하기 쉽게 문자로 바꾼 것 (예: naver.com)
DNS: 도메인과 IP 주소를 연결해주는 전화번호부 역할

이 개념들은 서버를 직접 다루게 될 때 반드시 필요한 기초 지식입니다. 특히 서버에 도메인을 연결하거나, HTTPS를 설정하거나, 방화벽을 구성할 때 IP와 도메인 개념이 자주 등장합니다.

웹서버, 앱서버, DB서버 – 서버 종류 정리

테크 한 스푼 — Mon, 25 May 2026 16:28:34 +0900

1. 왜 서버 종류를 알아야 할까?

IT 직군에 관심이 생겼거나, 개발을 처음 배우기 시작했거나, 혹은 단순히 인터넷이 어떻게 작동하는지 궁금한 분들이라면 한 번쯤 이런 의문을 가지셨을 겁니다.

"서버가 한 종류가 아니라고? 웹서버, 앱서버, DB서버가 다 다른 건가?"

맞습니다. 서버는 하나가 아닙니다. 실제로 우리가 웹사이트 하나를 이용할 때 뒤에서는 여러 종류의 서버가 각자의 역할을 나눠서 처리하고 있습니다.

이 글에서는 가장 기본이 되는 세 가지 서버, 웹서버 / 앱서버 / DB서버의 역할과 차이를 명확하게 정리해 드립니다.

2. 웹서버(Web Server)란?

정의

웹서버는 사용자의 브라우저(클라이언트)로부터 요청을 받아, 정적인 파일(HTML, CSS, 이미지, JavaScript 등)을 반환하는 서버입니다.

쉬운 비유

웹서버는 식당의 안내 직원과 같습니다. 손님이 들어오면 가장 먼저 맞이하고, "어서 오세요, 이쪽으로 앉으세요"처럼 기본적인 안내를 담당합니다. 복잡한 주문 처리는 주방(앱서버)이 하지만, 첫 접점은 안내 직원이 담당하는 것처럼요.

웹서버가 처리하는 것들

HTML 파일 전송 (웹페이지 구조)
CSS 파일 전송 (웹페이지 스타일)
이미지, 동영상 파일 전송
JavaScript 파일 전송
HTTPS 처리 (보안 연결)

대표 소프트웨어

Nginx (엔진엑스): 현재 가장 많이 사용되는 고성능 웹서버
Apache (아파치): 오랜 역사를 가진 전통적인 웹서버

3. 앱서버(Application Server)란?

정의

앱서버는 사용자의 요청 중 비즈니스 로직을 처리하는 서버입니다. 단순히 파일을 전달하는 것이 아니라, 연산, 조건 처리, 데이터 가공 등 실제 기능을 수행합니다.

쉬운 비유

앱서버는 식당의 주방입니다. 손님(클라이언트)이 "김치찌개 1인분 주세요"라고 주문(요청)을 넣으면, 안내 직원(웹서버)이 주방(앱서버)에 전달하고, 주방에서 실제로 요리를 만들어냅니다.

앱서버가 처리하는 것들

로그인 / 회원가입 처리
장바구니 추가, 주문 처리
게시글 작성, 수정, 삭제
추천 알고리즘 계산
결제 로직 처리

대표 프레임워크 및 언어

Node.js (JavaScript)
Spring Boot (Java)
Django / Flask (Python)
Laravel (PHP)
Ruby on Rails (Ruby)

앱서버는 특정 프로그램이 아니라 개발 언어와 프레임워크를 이용해 직접 만드는 서버라는 점이 웹서버와 다릅니다.

4. DB서버(Database Server)란?

정의

DB서버(데이터베이스 서버)는 데이터를 저장하고 조회하는 전용 서버입니다. 앱서버가 "이 사용자의 정보를 줘" 또는 "이 데이터를 저장해"라고 요청하면, DB서버가 이를 처리합니다.

쉬운 비유

DB서버는 창고 관리인입니다. 식당으로 치면 재료 창고를 관리하는 역할입니다. 주방(앱서버)이 "양파 2개 꺼내줘"라고 하면 창고 관리인이 꺼내주고, "오늘 입고된 재료 넣어줘"라고 하면 정리해서 보관합니다.

DB서버가 처리하는 것들

회원 정보 저장 및 조회
게시글, 댓글 데이터 관리
주문 내역, 결제 기록 보관
상품 재고 관리
로그 데이터 저장

관계형 DB vs 비관계형 DB

DB는 크게 두 종류로 나뉩니다.

구분관계형 DB (RDBMS)비관계형 DB (NoSQL)

데이터 형식	표(테이블) 형식	문서, 키-값 등 다양
대표 제품	MySQL, PostgreSQL	MongoDB, Redis
특징	정형화된 데이터에 강함	대용량, 유연한 구조에 강함
사용 예	회원정보, 주문내역	채팅 메시지, 로그

5. 세 서버가 함께 동작하는 방식

이제 세 서버가 실제로 어떻게 협력하는지 살펴보겠습니다. **"쇼핑몰에서 로그인하는 과정"**을 예로 들어볼게요.

[사용자] → 아이디/비밀번호 입력 후 로그인 버튼 클릭

① 웹서버: 사용자의 로그인 요청을 받아 앱서버로 전달

② 앱서버: "이 아이디와 비밀번호가 일치하는 사용자가 있는지 확인해줘"
           → DB서버에 조회 요청

③ DB서버: 저장된 회원 데이터에서 해당 계정 검색
           → 결과를 앱서버에 반환

④ 앱서버: 로그인 성공/실패 판단 후 결과 생성
           → 웹서버로 전달

⑤ 웹서버: 결과 화면을 사용자 브라우저에 전송

[사용자] → 로그인 성공 화면 확인

이처럼 세 서버는 각자의 역할을 명확히 분리해서 협력합니다. 이렇게 역할을 나누는 이유는 각 서버를 독립적으로 관리하고 확장할 수 있기 때문입니다.

6. 각 서버의 대표 소프트웨어 정리

서버 종류역할대표 소프트웨어

웹서버	정적 파일 전달, 요청 중계	Nginx, Apache
앱서버	비즈니스 로직 처리	Node.js, Spring, Django
DB서버	데이터 저장 및 조회	MySQL, PostgreSQL, MongoDB

7. 정리

오늘 배운 핵심 내용을 정리합니다.

웹서버: 브라우저와 직접 대화하며 정적 파일을 전달하는 서버 (Nginx, Apache)
앱서버: 실제 기능과 로직을 처리하는 서버 (Node.js, Spring, Django)
DB서버: 데이터를 저장하고 조회하는 서버 (MySQL, MongoDB)
세 서버는 독립적으로 운영되면서 서로 협력해 하나의 서비스를 완성합니다.

처음에는 이 세 가지만 명확히 구분해도 충분합니다. 나중에 개발을 배우거나 서버를 직접 다뤄볼 때, 오늘 배운 개념이 큰 틀이 되어줄 것입니다.

다음 글에서는 IP 주소와 도메인이 어떻게 연결되는지, 그리고 우리가 주소창에 URL을 입력했을 때 어떤 일이 일어나는지 알아보겠습니다.

서버란 무엇인가?

테크 한 스푼 — Mon, 25 May 2026 16:27:01 +0900

1. 서버가 뭔지 감이 안 잡히는 분들에게

"서버가 터졌다", "서버 점검 중입니다"라는 말은 누구나 한 번쯤 들어봤을 겁니다. 게임을 하다가, 쇼핑몰에서 결제하려다가, 혹은 스트리밍 서비스를 보다가 이런 문구를 맞닥뜨린 경험이 있으시죠?

그런데 정작 "서버가 정확히 뭐야?"라고 물어보면 대답하기 어렵습니다. IT 업계에서 일하지 않는 이상 서버를 직접 다뤄볼 일이 없으니까요.

이 글에서는 기술 용어 없이, 일상적인 비유를 통해 서버가 무엇인지 쉽게 설명드리겠습니다.

2. 서버의 정확한 정의

**서버(Server)**란 다른 컴퓨터나 기기에 데이터나 서비스를 제공하는 컴퓨터 또는 프로그램을 말합니다.

영어 단어 'serve'는 "제공하다, 서비스하다"라는 뜻입니다. 즉, 서버는 무언가를 제공하는 역할을 합니다.

반대로, 서버에게 무언가를 요청하는 쪽을 **클라이언트(Client)**라고 합니다. 우리가 스마트폰이나 컴퓨터로 인터넷을 사용할 때, 우리의 기기가 바로 클라이언트입니다.

쉬운 비유로 이해하기

카페를 상상해 보세요.

손님(클라이언트): "아메리카노 한 잔 주세요" → 요청
바리스타(서버): 커피를 만들어서 제공 → 응답

인터넷도 똑같습니다.

사용자(클라이언트): 브라우저에 www.naver.com 입력 → 요청
네이버 서버: 네이버 홈페이지 데이터를 전송 → 응답

이처럼 서버는 항상 요청을 기다리고, 요청이 오면 적절한 데이터를 돌려주는 역할을 합니다.

3. 서버와 일반 컴퓨터의 차이

여기서 많은 분들이 헷갈려합니다. "그럼 내 컴퓨터로도 서버를 만들 수 있는 거 아냐?"

맞습니다. 기술적으로는 일반 컴퓨터도 서버가 될 수 있습니다. 실제로 개인 개발자들이 집에서 홈서버를 구축하는 경우도 있습니다.

그러나 실제 서비스에 사용되는 서버는 일반 컴퓨터와 여러 면에서 다릅니다.

구분일반 컴퓨터 (PC)서버

목적	개인 사용	다수의 요청 처리
운영 시간	필요할 때만 켬	24시간 365일 상시 운영
성능	일반 사용에 최적화	고성능 CPU, 대용량 RAM
안정성	가끔 꺼져도 무방	절대 꺼지면 안 됨
위치	집, 사무실	데이터센터
모니터	있음	대부분 없음
운영체제	Windows 주로 사용	Linux 주로 사용

가장 큰 차이는 **"항상 켜져 있어야 한다"**는 점입니다. 네이버 서버가 밤 12시에 꺼진다면 그 시간에 네이버를 이용할 수 없겠죠? 그렇기 때문에 서버는 특별한 하드웨어와 소프트웨어 구성을 갖추고, 데이터센터라는 전용 건물에서 관리됩니다.

서버 전용 하드웨어의 특징

ECC 메모리: 오류를 자동으로 수정하는 특수 RAM
이중화 전원 장치: 전원이 하나 꺼져도 다른 전원으로 운영 지속
레이드(RAID) 스토리지: 하드디스크 여러 개를 묶어 데이터 손실 방지
랙 마운트 형태: 좁은 공간에 많은 서버를 효율적으로 배치하는 구조

4. 서버는 왜 필요한가?

"그냥 파일을 USB로 나눠주면 안 돼?"라고 생각할 수도 있습니다. 하지만 현대 인터넷 서비스는 그렇게 단순하지 않습니다.

이유 1. 동시에 수백만 명이 접속하기 때문

카카오톡을 생각해 보세요. 지금 이 순간에도 수천만 명이 메시지를 주고받고 있습니다. USB로는 불가능한 일이죠. 서버는 이런 대규모 동시 접속을 처리합니다.

이유 2. 데이터를 중앙에서 관리해야 하기 때문

인스타그램에 사진을 올리면 친구들이 볼 수 있는 이유는, 서버에 사진이 저장되기 때문입니다. 데이터를 한 곳에서 관리하면 언제 어디서든 같은 데이터에 접근할 수 있습니다.

이유 3. 보안과 신뢰성이 필요하기 때문

은행 거래, 개인정보, 결제 정보 등 민감한 데이터는 아무 컴퓨터에 저장할 수 없습니다. 서버는 보안 설정과 백업 시스템을 갖추고 중요한 데이터를 안전하게 보관합니다.

5. 서버의 종류 간단 정리

서버는 역할에 따라 다양한 종류로 나뉩니다. 지금은 이름과 역할 정도만 알아두세요.

웹 서버 (Web Server)

웹사이트의 HTML, 이미지, CSS 파일 등을 사용자 브라우저에 전달하는 서버입니다. 우리가 브라우저에서 주소를 입력하면 가장 먼저 만나는 서버입니다. 대표적인 웹 서버 소프트웨어로는 Nginx, Apache가 있습니다.

앱 서버 (Application Server)

웹 서버 뒤에서 실제 로직을 처리하는 서버입니다. 예를 들어, 쇼핑몰에서 "장바구니에 담기" 버튼을 누르면 그 동작을 처리하는 것이 앱 서버입니다.

DB 서버 (Database Server)

데이터를 저장하고 조회하는 역할을 합니다. 회원 정보, 게시글, 주문 내역 등 모든 데이터가 DB 서버에 저장됩니다. MySQL, PostgreSQL, MongoDB 등이 여기에 해당합니다.

파일 서버 (File Server)

사진, 동영상, 문서 파일 등을 저장하고 제공하는 서버입니다. 구글 드라이브, 드롭박스 같은 클라우드 스토리지가 대표적인 예입니다.

메일 서버 (Mail Server)

이메일을 보내고 받는 서버입니다. Gmail, 네이버 메일이 메일 서버를 통해 운영됩니다.

6. 정리

오늘 배운 내용을 간단히 정리해 볼게요.

서버란 다른 기기에 데이터나 서비스를 제공하는 컴퓨터입니다.
요청하는 쪽은 클라이언트, 제공하는 쪽은 서버입니다.
일반 컴퓨터와 서버의 가장 큰 차이는 24시간 상시 운영과 고안정성입니다.
서버는 역할에 따라 웹 서버, 앱 서버, DB 서버 등으로 나뉩니다.

서버의 개념을 이해했다면, 다음 단계로 클라이언트-서버 구조가 실제로 어떻게 동작하는지 알아보는 것을 추천드립니다. 우리가 브라우저에서 주소를 입력했을 때 화면이 뜨기까지 어떤 일이 일어나는지 이해하면, 서버에 대한 이해가 훨씬 깊어질 것입니다.

테크 한 스푼 블로그 소개

테크 한 스푼 — Fri, 8 May 2026 12:07:42 +0900

안녕하세요! IT·AI 기술 블로그 테크 한 스푼에 오신 걸 환영해요

혹시 이런 경험 있으신가요? 뉴스에서 "AI가 어쩌고, LLM이 저쩌고, 반도체가 어쩌고..." 하는 말은 매일 들리는데, 막상 무슨 말인지 잘 모르겠는 그 느낌요. 저도 처음엔 그랬거든요.

그래서 시작했어요. 어려운 기술 이야기를 한 스푼씩, 부담 없이 떠먹여드리는 블로그를요.

이런 내용을 다뤄요

AI · LLM · 생성형 AI ChatGPT, Claude, Gemini 등 최신 AI 동향과 실생활 활용법

반도체 · 하드웨어 엔비디아 GPU, HBM, 스마트폰 최신 기술 트렌드

☁️ 클라우드 · 보안 AWS, 마이크로소프트, 사이버보안 이슈

IT 실전 팁 일반인도 쉽게 활용할 수 있는 기술 활용 가이드

이런 분들께 추천해요

AI 뉴스는 매일 보는데 내용이 어렵게 느껴지는 분
IT 기술에 관심은 있지만 전공자가 아닌 분
최신 테크 트렌드를 쉽고 빠르게 파악하고 싶은 분

소통해요

궁금한 점이나 다뤄줬으면 하는 주제가 있으면 댓글로 편하게 남겨주세요. 최대한 쉽고 재미있게 설명해드릴게요!

앞으로도 테크 한 스푼과 함께 IT·AI 세상을 한 스푼씩 맛봐요

개인정보처리방침

테크 한 스푼 — Wed, 6 May 2026 11:49:28 +0900

개인정보처리방침
시행일: 2026년 5월 6일

1. 총칙
「테크 한 스푼」(이하 "본 블로그")은 이용자의 개인정보를 소중히 여기며, 「개인정보 보호법」 및 관련 법령을 준수합니다. 본 방침은 본 블로그가 수집하는 개인정보의 항목, 수집 목적, 보유 기간 및 이용자의 권리에 대해 안내합니다.

2. 수집하는 개인정보 항목 및 수집 방법
본 블로그는 다음과 같은 정보를 자동으로 수집할 수 있습니다.
- 방문 기록, IP 주소, 브라우저 종류 및 OS 정보
- 쿠키(Cookie) 및 유사 기술을 통해 수집되는 이용 행태 정보
- Google 애드센스를 통한 광고 관련 데이터
- Google 애널리틱스를 통한 방문 통계 데이터 (수집 시)
수집 방법: 이용자의 블로그 방문 시 자동 수집

3. 개인정보 수집 및 이용 목적
- 블로그 이용 통계 분석 및 서비스 개선
- 맞춤형 광고 제공 (Google 애드센스)
- 불법·부정 이용 방지

4. 개인정보 보유 및 이용 기간
수집된 개인정보는 수집·이용 목적 달성 후 즉시 파기합니다. 단, 관련 법령에 따라 보존이 필요한 경우에는 해당 기간 동안 보관합니다.

5. 개인정보의 제3자 제공
본 블로그는 이용자의 동의 없이 개인정보를 외부에 제공하지 않습니다. 단, 아래의 경우는 예외로 합니다.
- Google 애드센스: 광고 게재 및 관련 서비스 운영 목적으로 Google LLC에 데이터가 전달될 수 있습니다.
- 법령에 의거하거나 수사 목적으로 관계 기관의 요청이 있는 경우

6. 쿠키(Cookie) 사용 안내
본 블로그는 이용자 편의 제공 및 맞춤형 광고를 위해 쿠키를 사용합니다. 이용자는 브라우저 설정을 통해 쿠키 저장을 거부할 수 있으나, 이 경우 일부 서비스 이용이 제한될 수 있습니다.

7. 이용자의 권리
이용자는 언제든지 개인정보 열람, 정정·삭제, 처리 정지를 요청할 수 있습니다. 권리 행사는 아래 이메일로 요청하시면 지체 없이 처리하겠습니다.

8. 개인정보 보호책임자
- 블로그명: 테크 한 스푼
- 이메일: dbsghwns7789@nate.com

9. 개정 이력
본 방침은 2026년 5월 6일부터 시행됩니다. 내용 변경 시 블로그를 통해 사전 공지합니다.

테크 한 스푼

CORS란 무엇인가 – 브라우저에서 API 요청이 막히는 이유

목차

1. 개발하다가 갑자기 막히는 그 오류

2. 동일 출처 정책(Same-Origin Policy)이란?

3. CORS란 무엇인가?

4. CORS 오류가 발생하는 상황

5. CORS 오류를 해결하는 방법

6. CORS 관련 HTTP 헤더 이해하기

7. Preflight 요청이란?

8. 정리 및 다음 단계

JWT 토큰이란 무엇인가 – 토큰 기반 인증 쉽게 이해하기

목차

1. 세션 방식의 한계

2. JWT란 무엇인가?

3. JWT의 구조

4. JWT 인증 동작 방식

5. 세션 방식 vs JWT 방식 비교

6. JWT의 장점과 단점

7. JWT 사용 시 주의해야 할 보안 사항

8. 정리 및 다음 단계

쿠키와 세션의 차이 – 개념 및 활용, 로그인 상태는 어떻게 유지되는가?

목차

1. 로그인은 한 번만 했는데 왜 계속 유지될까?

2. HTTP는 기본적으로 상태를 기억하지 못한다

3. 쿠키(Cookie)란 무엇인가?

4. 세션(Session)이란 무엇인가?

5. 쿠키와 세션의 차이 비교

6. 실제 로그인 과정에서 쿠키와 세션이 동작하는 방식

7. 쿠키와 세션의 보안 이슈

8. 정리 및 다음 단계

JSON이란? – JSON 뜻, 목적, 데이터를 주고받는 형식 쉽게 이해하기

목차

1. API 응답에서 자꾸 나오는 이 형태는 무엇인가?

2. JSON의 정의

3. JSON의 기본 문법

4. JSON에서 사용할 수 있는 데이터 타입

5. JSON vs XML – 왜 JSON이 대세가 됐나?

6. 실제 서비스에서 JSON이 사용되는 방식

7. 정리 및 다음 단계

REST API란 – GET, POST, PUT, DELETE 완전 정리

목차

1. API를 배웠는데 REST는 또 뭔가?

2. REST API의 정의

3. REST의 핵심 원칙

4. HTTP 메서드 완전 정리 – GET, POST, PUT, DELETE

5. REST API URL 설계 방식

6. REST API 요청과 응답의 구조

7. REST API가 아닌 것들 – SOAP와의 차이

8. 정리 및 다음 단계

API란 무엇인가 – API 개념, API 목적 등에 대 쉬운 설명

목차

1. API라는 단어, 어디서 많이 들어봤는데?

2. API의 정확한 정의

3. 일상 속 API – 실생활 비유로 이해하기

4. API가 실제로 사용되는 사례

5. API의 종류

6. API 없이는 어떤 일이 생길까?

7. 정리 및 다음 단계

서버 없이 웹사이트 배포하는 방법 – GitHub Pages, Netlify, Vercel 비교

목차

1. 서버 없이도 웹사이트를 올릴 수 있다

2. 정적 사이트란 무엇인가?

3. GitHub Pages – 가장 간단한 무료 호스팅

4. Netlify – 자동 배포와 편리한 기능

5. Vercel – 프론트엔드 개발자의 최애 도구

6. 세 서비스 비교 정리

7. 어떤 서비스를 선택해야 할까?

8. 정리 및 마무리

내부 네트워크와 외부 네트워크의 차이 – 192.168.x.x는 왜 접속이 안 될까

목차

1. 친구에게 내 서버 주소를 알려줬는데 접속이 안 된다?

2. 내부 네트워크와 외부 네트워크란?

3. 사설 IP 주소의 범위

4. NAT – 사설 IP가 인터넷과 통신하는 방법

5. 포트 포워딩이란 무엇인가?

6. 클라우드 서버와 공인 IP

7. 자주 발생하는 접속 문제와 해결법

8. 정리 및 다음 단계

서버 백업을 자동화하는 가장 쉬운 방법 – rsync와 cron 활용