SOYALI님의 블로그

[ Linux ] 운영 서버 로그 기반 의심 징후 탐지 체크리스트

soyali — Wed, 28 Jan 2026 15:41:38 +0900

운영 서버에서 로그를 보는 목적은 단순히 이벤트를 확인하는 것을 넘어, 비정상/의심 행동을 조기에 포착하는 것입니다.
이 글에서는 auth.log/secure 같은 인증 로그에서 비정상 sudo 패턴, IP 기반 이상 탐지, 로그인 이상 징후를 찾아내는 방법을 실전 기준으로 정리합니다.

명령어는 Ubuntu 기준으로 작성되었습니다.

1. 리눅스 인증/권한 로그 위치

운영 서버에서 인증/SSH/권한 상승 로그는 대개 아래 위치에 저장돼요. 이 파일들이 이상 탐지의 출발점입니다

배포판 계열인증	권한 상승 로그
Debian/Ubuntu	/var/log/auth.log
RHEL/CentOS/Rocky/Alma	/var/log/secure

이 파일에는 SSH 로그인 성공/실패, sudo, su, su - 같은 이벤트가 포함됩니다.

2. 운영 서버 이상 징후 탐지

1) 반복된 로그인 실패 (브루트포스 의심)

짧은 시간에 여러 로그인 실패 → 브루트포스 공격 가능성
동일 IP에서 많은 실패가 있으면 방화벽/차단 조치 후 분석 권장.
실패 패턴이 장시간 쌓이는 경우 보안 설정 재검토 필요.

sudo grep "Failed password" /var/log/auth.log | cut -d ' ' -f 11 | sort | uniq -c | sort -nr | head -n 20

2) 정상 범주와 다른 SSH 로그인 성공 IP

로그인 성공이 예상 범위(내부망, 사무실 IP 등)를 벗어나면 잠재적인 외부 접근 가능성이 있습니다.

sudo grep "Accepted password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c

- 예상치 못한 외부 IP가 있으면 접속 시간/사용자명과 함께 추가 조사 필요.

3) sudo 명령 과도 사용

정상 운영자라도 sudo 명령을 과도하게 반복해서 쓰면 자동화 스크립트, 비정상 행위 가능성이 있습니다.

sudo grep "sudo" /var/log/auth.log | awk '{print $1,$2,$3,$9,$11}' | sort | uniq -c | sort -nr | head -n 20

- 시간/사용자/명령별로 리포트해서 비정상 패턴 여부를 판단할 수 있습니다.

4) 권한 없는 sudo 시도

sudo 권한이 없는 사용자가 sudo를 시도하면 권한 설정 누락 또는 무단 시도일 수 있습니다.

sudo grep "NOT in sudoers" /var/log/auth.log

이런 이벤트는 운영자가 의도적으로 sudo 권한을 주지 않은 계정의 무단 사용 시도로 해석됩니다.

5) su/su - 전환 이상 패턴

정상범주를 벗어나는 su/su - 전환이 반복되면 운영 이상 행동의 힌트가 되기도 합니다.

sudo grep "su:" /var/log/auth.log

- 어떤 사용자가 언제 루트 전환을 시도했는지를 빠르게 확인할 수 있습니다.

3. 실시간 모니터링

실시간 모니터링으로 이상 시도를 빠르게 포착하는 것도 실전에서 유용합니다.

sudo tail -f /var/log/auth.log | grep -E "Failed password|Accepted password|sudo"

- tail -f로 실시간 감시를 하면서 이상한 입력이 들어오는 순간 빠르게 대응할 수 있습니다.

4. 추가 보안 보강 도구

Fail2Ban : 로그를 스캔해 지정된 조건 이상 실패가 쌓이면 해당 IP를 자동 차단하는 도구입니다.

# 설
sudo apt install fail2ban

# SSH 로그인 실패가 연속으로 발생하면 특정 시간 동안 해당 IP를 차단
sudo systemctl enable fail2ban

# 차단 상태 확인
sudo fail2ban-client status sshd

- 로그 동작은 /var/log/fail2ban.log에 기록됩니다.

5. 실전 판단 기준

이상 패턴	의미	대응
반복된 로그인 실패	브루트포스 의심	IP 차단/Fail2Ban
낯선 IP의 로그인 성공	외부 접근 가능성	접속 시간/사용자 비교
과도한 sudo 패턴	자동화/비정상 동작	사용자/스크립트 조사
권한 없는 sudo 시도	계정/권한 설정 문제	sudoers 검토
su/su - 반복 전환	운영 이상 시도	해당 사용자 조사

마무리

로그 기반 이상 징후 탐지는 현장 운영에서 가장 기본적이고 즉각적인 대응 수단입니다.
로그 분석은 정기적으로, 그리고 자동화 도구(예: Fail2ban, auditd)와 함께 병행하며 운영 품질과 보안 수준을 높이는 데 쓰면 좋습니다.

[ Linux ] su / su - / sudo 로그 확인 및 감사 방법

soyali — Wed, 28 Jan 2026 15:10:12 +0900

이전 글에서 su, su -, sudo의 차이점을 정리했는데요.
이번에는 운영 서버에서 권한 상승 관련 로그를 어떻게 확인할지 알아보겠습니다.
로그는 누가 어떤 권한 상승을 했는지를 추적하는 데 필수적입니다.

1. 인증/보안 로그 파일 위치

리눅스는 인증 및 권한 상승 관련 이벤트 로그를 /var/log 아래 특정 파일에 저장합니다.

배포판 계열인증	권한 상승 로그
Ubuntu / Debian	/var/log/auth.log
RHEL / CentOS / Rocky / Alma	/var/log/secure

이 위치는 시스템 로그인/SSH/권한 상승 관련 로그를 포함합니다.

2. su / su - 로그 확인

su와 su -는 사용자 전환 세션 이벤트로 인증 로그에 기록됩니다.
이는 권한 상승(예: 일반 사용자 → root) 시도와 성공/실패 모두에 해당합니다.

su/su - 로그 검색

Ubuntu/Debian:

sudo grep "su" /var/log/auth.log

CentOS/RHEL:

sudo grep "su" /var/log/secure

이렇게 하면 누가 어떤 계정으로 전환했는지 확인할 수 있습니다.

3. sudo 로그 확인

1) 기본 sudo 이벤트 검색

Ubuntu/Debian:

sudo grep "sudo" /var/log/auth.log

CentOS/RHEL:

sudo grep "sudo" /var/log/secure

이렇게 하면 누가 sudo 명령을 실행했는지 로그를 확인할 수 있습니다.

2) 실시간 sudo 로그 보기

로그를 실시간으로 모니터링하면 사용자 행동을 즉시 파악할 수 있습니다.

Ubuntu/Debian:

sudo tail -f /var/log/auth.log | grep sudo

CentOS/RHEL:

sudo tail -f /var/log/secure | grep sudo

이 명령은 새로운 sudo 이벤트가 발생할 때마다 화면에 표시합니다.

4. SSH 인증 및 세션 로그

sudo나 su 로그는 SSH 로그인/로그아웃 기록과 함께 보면 더 많은 맥락을 알 수 있습니다.

# SSH 로그인 성공
sudo grep "Accepted" /var/log/auth.log

# SSH 로그인 실패
sudo grep "Failed" /var/log/auth.log

이 명령은 인증 성공/실패와 관련된 로그를 보여줍니다.

5. 로그 분석/필터링 팁

실무에서는 단순히 로그 전체를 보는 것보다 필요한 이벤트만 빠르게 추출하는 것이 중요합니다.

특정 사용자 sudo 로그

sudo grep "sudo.*username" /var/log/auth.log

실패한 su 시도

sudo grep "su.*authentication failure" /var/log/auth.log

일정 시간대 이벤트

sudo grep "Jan 28" /var/log/auth.log | grep sudo

로그 파일은 시간이 지나면 용량이 커지고 이름이 바뀌기 때문에 압축된 로그(auth.log.*, secure.*)까지 살펴야 하는 경우가 많습니다.

목적	확인 방법
SSH 인증 성공/실패	grep "Accepted" / grep "Failed"
sudo 사용 내역	grep "sudo"
su / su - 세션 전환	grep "su"
실시간 감시	`tail -f …
특정 사용자 필터	grep "sudo.*username"

6. 왜 로그 확인이 중요할까?

보안 점검/감사: 누가 언제 어떤 권한 상승을 시도했는지 기록으로 남습니다.
운영 장애 원인 분석: 특정 명령을 실행한 사용자를 빠르게 찾을 수 있습니다.
침입 탐지: 비정상적인 sudo/su 시도가 있는지 감시합니다.

마무리

인증/권한 상승 로그는 /var/log/auth.log 또는 /var/log/secure에 저장됩니다.
sudo 로그는 명령 실행 정보까지 로그로 남습니다.
su/su -는 세션 전환 이벤트로 인증 로그에 기록됩니다.
실시간 모니터링과 필터링으로 이상 징후를 빠르게 포착할 수 있습니다.

[ Linux ] su, su -, sudo 차이점 정리 (운영 서버 기준)

soyali — Wed, 28 Jan 2026 14:53:05 +0900

팀장님께서 su와 su -의 차이점을 아느냐고 물어보셔서 정리한 내용입니다.

리눅스 서버에서 su, su -, sudo는 모두 권한 상승과 관련된 명령어지만, 목적과 동작 방식이 달라 운영 서버에서는 추적성 / 최소 권한 / 보안 정책 관점에서 접근해야 합니다.

1. su (Switch User) 명령어

su는 다른 사용자 계정으로 세션을 전환하는 명령어입니다.
기본값은 root이며, 해당 계정의 비밀번호를 입력해야 전환이 됩니다.

동작

전환 대상 계정의 비밀번호 입력 필요
전환 후 shell이 전환된 계정 세션으로 유지됨
exit으로 다시 원래 계정으로 돌아감

실무 특징

root로 완전히 로그인한 상태가 되므로 연속 명령 실행이 쉬움
하지만 전체 세션이 권한 상승 상태이기 때문에 실수로 시스템에 영향 줄 위험이 큽니다
어떤 명령을 했는지 세부 추적이 어려움

2. su - ( su with login ) 명령어

su -는 단순 계정 전환이 아니라 로그인한 것과 동일한 환경으로 전환합니다.

동작

root의 환경 변수, PATH, 홈 디렉토리 등이 적용
쉘은 root 로그인 세션과 동일하게 동작
기본 디렉토리가 /root로 변경

su 와 su - 차이

옵션	환경 반영	홈 디렉토리
su	기존 사용자 환경 유지	변경 없음
su -	root 환경 완전 반영	/root

실무 포인트

스크립트 실행/환경 변수가 명확히 필요한 경우 **su -**가 더 정확한 결과를 보장
다만 root 직접 세션 유지이므로 보안 리스크는 여전

3. sudo (Superuser Do) 명령어

sudo는 명령어 단위로 권한 상승을 수행합니다.
shell 전환 없이 지정한 명령만 root 권한으로 실행됩니다.

동작

본인 계정 비밀번호 입력
/etc/sudoers에서 실행 권한 여부 확인
명령 실행 후 일반 권한 상태로 돌아감

실무 특징

명령 단위 권한 적용 → 최소 권한 원칙
각 명령 실행 시 로그가 남아 추적/감사 가능
운영 서버에서는 표준 권한 상승 방식으로 간주됨

4. su / su - / sudo 차이점

구분	su	su -	sudo
실행 방식	사용자 전환	root 로그인 환경처럼 전환	특정 명령 실행
비밀번호	전환 대상 계정	전환 대상 계정	본인 계정
환경 반영	본인 환경 유지	root 환경 완전 반영	본인 환경 유지
명령 로그	제한적	제한적	명령 단위로 남음
운영 권장	X	X	O

5. 실무 적용 기준

기본 원칙
작업은 sudo 사용으로 수행 → 각 명령이 추적/로그 기록되어야 함
root 직접 로그인
보안 정책 상 차단 권장 (root 비밀번호 공유 리스크가 큼)
su / su - 활용 케이스
- 테스트/개발 환경에서 빠른 전환이 필요할 때
- 복구/비상 상황에서 전체 환경 점검이 필요할 때

운영 서버에서 중요한 건 “편한 권한 획득”이 아니라 “누가 무엇을 실행했는지 추적 가능한가?” 입니다.

마무리

su | 전체 세션 root 권한 상승 (환경 유지)
su - | root 로그인 환경으로 전체 반영
sudo | 단일 명령만 권한 상승 → 로그 + 제어 가능

운영에서는 sudo 기반 권한 관리가 표준입니다.

[ Oracle SQL Developer ] PDB 확인 및 사용자 계정 생성 절차

soyali — Wed, 12 Nov 2025 16:05:05 +0900

Oracle 12c 이후 버전부터는 멀티 테넌트(Multitenant) 구조가 도입되어,
데이터베이스가 다음과 같이 두 가지 계층으로 구성됩니다.

구분	설명
CDB (Container Database)	전체 시스템의 큰 틀로, Oracle 인스턴스의 루트 컨테이너 역할을 수행. 시스템 계정(SYS, SYSTEM)과 공통 메타데이터 관리.
PDB (Pluggable Database)	실제 사용자 데이터와 객체가 존재하는 독립적인 데이터베이스 단위. 일반 사용자 계정은 PDB 내부에 생성됨.

1. 현재 접속 컨테이너 확인

먼저, 현재 어떤 컨테이너(CDB 또는 PDB)에 접속 중인지 확인합니다.

SHOW CON_NAME;

출력

--------------------------------------------------------------------------------
CDB$ROOT

CDB$ROOT로 표시된다면 현재 CDB 루트 컨테이너에 접속 중이며, 이는 일반적으로 SYS 또는 SYSTEM 계정으로 접속한 상태입니다.

2. CDB 내 PDB 목록 확인

CDB에 등록된 PDB(플러그형 데이터베이스) 목록을 확인합니다.

SHOW PDBS;

출력

CON_ID CON_NAME OPEN_MODE RESTRICTED
---------- --------- ---------- ----------
2 PDB$SEED READ ONLY NO
3 XEPDB1 READ WRITE NO

※ 컬럼별 의미

컬럼명	설명
CON_ID	컨테이너 고유 ID. 각 CDB/PDB에 부여되는 내부 식별자.
CON_NAME	컨테이너 이름 (CDB$ROOT, PDB$SEED, XEPDB1 등).
OPEN_MODE	컨테이너 접근 모드. - MOUNTED: 데이터파일만 연결, 접속 불가 - READ ONLY: 읽기 전용 - READ WRITE: 읽기·쓰기 가능(일반 운영 상태)
RESTRICTED	제한 모드 여부. - YES: SYSDBA 등 특권 사용자만 접속 가능 - NO: 일반 사용자 접속 가능

참고: PDB$SEED는 새로운 PDB를 생성할 때 복제되는 템플릿 PDB로, 항상 READ ONLY 상태입니다.

3. PDB로 세션 전환

일반 사용자 계정은 CDB$ROOT가 아닌 PDB 내부에서 생성해야 합니다.

아래 명령으로 사용할 PDB로 세션을 전환합니다.

ALTER SESSION SET CONTAINER = <CON_NAME 입력>;

이제 <CON_NAME> 컨테이너에서 사용자 계정 및 객체를 생성할 수 있습니다. .

4. 사용자 계정 생성

CREATE USER test IDENTIFIED BY test;

test 계정을 생성하고 비밀번호를 test로 설정합니다.
이 상태에서는 아직 접속 및 객체 생성 권한이 없으므로 추가 권한을 부여해야 합니다.

5. 기본 권한 부여

GRANT CONNECT, RESOURCE TO <계정명>;

구분	권한	설명
로그인	CONNECT	DB 접속 가능 (CREATE SESSION)
객체 생성	RESOURCE	일반 객체 생성 권한 (TABLE, INDEX, CLUSTER 등)

6. 추가 객체 생성 권한 (옵션)

GRANT 권한(옵션1), 권한(옵션2).......... TO <사용자명>;

권한(옵션)	설명
CREATE VIEW	View 생성 가능 (SELECT 문을 기반으로 논리적 테이블 작성 가능)
CREATE SEQUENCE	SEQUENCE 생성 가능 (자동 증가 번호용 객체 생성)
CREATE PROCEDURE	PL/SQL 프로시저, 함수(Function), 패키지 생성 가능
CREATE TRIGGER	트리거(Trigger) 생성 가능 (데이터 변경 시 자동 동작 로직)
CREATE SYNONYM	SYNONYM 생성 가능 (객체의 별칭을 부여 — 스키마 분리 시 유용)
CREATE TYPE	사용자 정의 데이터 타입 생성 가능 (OBJECT TYPE, VARRAY 등)
CREATE MATERIALIZED VIEW	물리적 뷰(Materialized View) 생성 가능 — 주로 성능 튜닝용
CREATE JOB	DB 스케줄러(Job) 생성 가능 (자동 배치작업용)
CREATE TABLESPACE	별도 테이블스페이스 생성 가능 (일반 개발자보단 DBA 권한 수준)

※ 요약

단계	주요 명령	설명
1	SHOW CON_NAME;	현재 컨테이너 확인
2	SHOW PDBS;	CDB 내 PDB 목록 확인
3	ALTER SESSION SET CONTAINER = CON_NAME;	세션을 PDB로 전환
4	CREATE USER test IDENTIFIED BY test;	사용자 계정 생성
5	GRANT CONNECT, RESOURCE TO test;	기본 권한 부여
6	GRANT CREATE VIEW, ... TO test;	필요 시 추가 권한 부여

[ Linux ] curl GET 요청 시 URL 인코딩이 꼭 필요한 이유와 처리 방법

soyali — Fri, 13 Jun 2025 15:20:04 +0900

API 호출을 위해 curl을 사용하시는 분들이라면, GET 요청 시 쿼리 파라미터에 공백, 콜론, 쉼표 등 특수 문자가 포함될 경우 서버에서 요청을 제대로 인식하지 못하는 문제를 경험하신 적이 있을 것입니다.

왜 인코딩이 필요할까?

GET 요청에서 파라미터는 보통 다음과 같이 URL 쿼리 문자열에 포함됩니다:

https://호스트명:포트/경로?key=value

하지만 이 쿼리 문자열에 다음과 같은 문자가 포함되면 문제가 발생할 수 있습니다:

공백 ( )
쉼표 (,)
콜론 (:)
더하기 기호 (+)

예를 들어, RFC 2822 형식의 날짜를 쿼리 파라미터 값으로 전달해야 할 경우, 날짜 문자열은 다음과 같은 구조를 가집니다:

Fri, 13 Jun 2025 15:30:00 +0900

이 문자열에는 공백, 쉼표, 콜론, 더하기 기호 등 여러 특수 문자가 포함되어 있어, 이를 URL에 그대로 전달하면 구문 오류가 발생하거나 파라미터가 잘못 해석될 수 있습니다.

인코딩하지 않고 아래와 같이 전송할 경우,

curl "https://호스트명:포트/경로?time=Fri, 13 Jun 2025 15:30:00 +0900"

서버는 time 파라미터를 정확하게 인식하지 못하거나 오류를 반환할 수 있습니다.

반면, URL 인코딩을 적용하면,

curl "https://호스트명:포트/경로?time=Fri%2C%2013%20Jun%202025%2015%3A30%3A00%20%2B0900"

공백, 쉼표, 콜론, 더하기 기호가 모두 인코딩되어 쿼리 파라미터로 정상 전달되고, 서버에서 올바르게 해석할 수 있습니다.

1. curl 호출 시 자동으로 인코딩하는 방법

curl에서 --data-urlencode 옵션을 사용하면, 쿼리 파라미터 값을 자동으로 URL 인코딩하여 전송할 수 있습니다.

curl -G \
"https://${호스트명}:${포트}/${경로}" \
--data-urlencode "input_datetime=$rfc2822_datetime" \
-H "accept: application/json"

-G 옵션은 GET 요청임을 의미하며,
--data-urlencode는 파라미터 값을 URL 인코딩해 줍니다.

2. Shell script 함수로 수동 인코딩하기

urlencode() {
local raw="$1"
local encoded=""
local i c

for ((i=0; i<${#raw}; i++)); do
c="${raw:i:1}"
case "$c" in
[a-zA-Z0-9.~_-])
encoded+="$c"
;;
*)

# ASCII 문자를 %HEX 형식으로 변환
printf -v hex '%%%02X' "'$c"
encoded+="$hex"
;;
esac
done

echo "$encoded"
}

rfc2822_datetime="Fri, 13 Jun 2025 15:30:00 +0900"
encoded_datetime=$(urlencode "$rfc2822_datetime")

curl "https://${호스트명}:${포트}/${경로}?time=${encoded_datetime}" \
-H "accept: application/json"

[ Linux ] 사용자 입력 값을 RFC 2822 형식으로 변환하는 방법 - Shell script

soyali — Fri, 13 Jun 2025 14:45:58 +0900

최근 API 작업 중, 날짜 값을 RFC 2822 형식으로 변환해 전달해야 할 일이 있었습니다.
RFC 2822는 이메일 메시지의 형식을 정의한 인터넷 표준 문서이지만, 사용자가 직접 입력하기에는 다소 까다로운 부분이 있어 변환 방법을 찾아보고 정리하게 되었습니다.

- RFC 2822 정의

RFC 2822는 이메일 메시지의 형식을 정의한 인터넷 표준 문서입니다.
제목: Internet Message Format
작성자: Internet Engineering Task Force (IETF)
주요 목적: 이메일 헤더 구조, 날짜 포맷, 주소 포맷 등 메시지 형식을 통일

RFC란?
Request For Comments – 인터넷 표준 문서를 정의한 문서 시리즈입니다.

RFC 2822 날짜 포맷 예시

Tue, 14 May 2024 13:55:30 +0900

형식의 구성 요소 :

요일, 일 월 연도 시:분:초 시간대

Shell script

#!/bin/bash

# 입력받은 날짜 (YYYYMMddhhmmss 형식)
input_datetime=$1

# 유효성 검사 함수
validate_format() {
if [[ ! "$1" =~ ^[0-9]{14}$ ]]; then
echo "형식 오류: 입력한 날짜가 YYYYMMddhhmmss 형식이 아닙니다."
exit 1
fi
}

# RFC 2822 형식으로 변환 함수
convert_to_rfc2822() {
datetime="$1"

YYYY="${datetime:0:4}"
MM="${datetime:4:2}"
dd="${datetime:6:2}"
hh="${datetime:8:2}"
mm="${datetime:10:2}"
ss="${datetime:12:2}"

formatted_datetime="${YYYY}-${MM}-${dd} ${hh}:${mm}:${ss}"

# Asia/Seoul 타임존 기준으로 변환 후 출력
TZ=Asia/Seoul date -d "$formatted_datetime" '+%a, %d %b %Y %H:%M:%S %z'
}

# 입력값 유효성 검사
validate_format "$input_datetime"

# 변환된 RFC 2822 문자열
rfc2822_datetime=$(convert_to_rfc2822 "$input_datetime")

echo "$rfc2822_datetime"

입력 :

202506121600

변환 출력 :

Thu, 12 Jun 2025 16:00:00 +0900

[ Linux ] curl로 REST API 호출하는 방법

soyali — Fri, 13 Jun 2025 12:25:08 +0900

curl을 활용해 REST API의 대표적인 HTTP 메서드(GET, POST, PUT, DELETE, PATCH)를 사용하는 방법을 정리해보겠습니다.

curl 기본 구조

curl -X <HTTP_METHOD> <URL> [옵션들]

-X는 사용할 HTTP 메서드를 지정하는 옵션입니다. 그 외에도 -H(헤더), -d(데이터), -i(응답 헤더 포함) 등의 옵션이 자주 사용됩니다.

1. GET – 데이터 조회 (기본 방식)

curl https://api.example.com/users

혹은 명시적으로:

curl -X GET https://api.example.com/users

curl 기본값이 GET이기 때문에 -X GET 생략 가능 합니다.
요청 본문(body) 없습니다.
파라미터는 URL에 붙임: ?key=value

파라미터 예시 :

curl "https://api.example.com/users?name=soyali"

2. POST – 데이터 생성

curl -X POST https://api.example.com/users \
-H "Content-Type: application/json" \
-d '{"name": "soyali", "email": "test@example.com"}'

-X POST: POST 메서드 명시해야 합니다.
-d: 전송할 데이터 지정 (JSON, 폼 등)
-H: Content-Type 헤더 지정 (중요)

폼 데이터로 전송할 경우:

curl -X POST https://api.example.com/users \
-d "name=soyali&email=test@example.com"

3. PUT – 데이터 전체 수정

curl -X PUT https://api.example.com/users/soyali \
-H "Content-Type: application/json" \
-d '{"name": "soyali2", "email": "newtest@example.com"}'

전체 필드를 수정할 때 사용 합니다.
특정 리소스(ID 등)를 URL에 포함시키는 것이 일반적입니다.

-X와 -d, -H 조합은 POST와 동일합니다.

4. PATCH – 데이터 부분 수정 (선택)

curl -X PATCH https://api.example.com/users/soyali \
-H "Content-Type: application/json" \
-d '{"email": "test_updated@example.com"}'

PUT과 비슷하지만 전체 필드가 아니라 일부만 전송하여 수정합니다.
리소스의 일부분만 수정할 때 사용합니다.

-X와 -d, -H 조합은 POST와 동일합니다.

5. DELETE – 데이터 삭제

curl -X DELETE https://api.example.com/users/soyali

대부분의 DELETE 요청은 요청 본문이 없습니다.
주로 URL에 삭제할 리소스의 식별자를 포함하여 사용합니다.
요청을 보낸다고 해서 무조건 삭제되는 것은 아니며, 서버에서 해당 리소스를 허용한 경우에만 삭제됩니다.

인증이 필요한 경우

보안이 설정된 API는 Authorization 헤더를 함께 보내야 합니다.

curl -X DELETE https://api.example.com/users/soyali \
-H "Authorization: Bearer YOUR_TOKEN"

Bearer Token은 API 서버에서 사용자를 인증하는 데 사용됩니다.
실제 운영 환경에서는 토큰 없이는 삭제 요청이 거부되기도 합니다.

자주 쓰는 옵션 정리

-X	HTTP 메서드 지정 (GET, POST 등)
-H	헤더 추가 (Content-Type, Authorization 등)
-d	전송할 데이터 (JSON 등)
-i	응답 헤더도 함께 출력
-v	디버깅용 verbose 출력
-u	인증 정보 (-u username:password)

curl은 요청 방식만 바꿔주면 거의 모든 REST API 테스트에 대응할 수 있습니다.
중요한 건 메서드마다 사용 목적과 전달 방식이 다르다는 점입니다:

GET → URL로 파라미터 전송
POST/PUT/PATCH → body에 JSON 데이터 전달
DELETE → URL만으로 요청 가능

마무리 요약표

GET	데이터 조회	유저 목록, 상세 정보 요청
POST	데이터 생성	유저 추가, 글 등록 등
PUT	데이터 전체 수정	유저 정보 전체 덮어쓰기
PATCH	데이터 일부 수정	유저 이메일만 수정
DELETE	데이터 삭제	특정 유저나 리소스 제거

[ Linux ] 리눅스에서 API 호출을 할 때 curl이 거의 표준처럼 사용되는 이유

soyali — Fri, 13 Jun 2025 11:38:07 +0900

리눅스에서 API 호출을 할 때 curl이 거의 표준처럼 사용되는 이유는 단순히 편의성 때문이 아니라, 유연성과 범용성 때문입니다.

1. 거의 모든 리눅스 배포판에 기본 내장

대부분의 리눅스 시스템에 기본 설치되어 있기에 별도 설치 없이 바로 사용이 가능합니다.
서버, 개발 환경, 컨테이너 어디서든 동일한 명령어로 동작합니다.

2. HTTP 모든 메서드 지원 (GET, POST, PUT, DELETE 등)

curl -X GET https://api.example.com/data
curl -X POST -d '{"name":"soyali"}' https://api.example.com/users....

curl은 단순한 다운로드 도구가 아니라, HTTP, HTTPS, FTP, SFTP, SMTP, LDAP 등 다양한 프로토콜을 지원합니다.
REST API의 모든 요청 형식을 완벽하게 다룰 수 있습니다.

3. 요청 헤더, 인증, 데이터 전송 등 완벽 지원

예시: 토큰 인증 + JSON 데이터 전송

curl -X POST https://api.example.com/data \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"message": "반갑습니다."}'

Header 추가, Body 데이터 지정, 인증 처리까지 모두 가능 합니다.
복잡한 요청도 한 줄 명령어로 구성 가능 해결할 수 있습니다.

4. 디버깅과 로그 확인에 유리

curl -v https://api.example.com

-v 옵션으로 요청/응답 헤더, 상태 코드 확인 할 수 있습니다.
API 호출 시 어떤 데이터가 오고 가는지 추적이 가능합니다.
JSON이 아닌 응답 포맷도 그대로 출력되므로 테스트에 적합합니다.

5. 자동화/스크립트에 쉽게 포함 가능

curl은 Bash, Shell script, cron 작업에 자연스럽게 통합 가능 합니다.

#!/bin/bash

response=$(curl -s https://api.example.com/status)
echo "API 상태: $response"

별도의 라이브러리 없이, 순수 리눅스 명령어 기반 자동화가 가능합니다.

6. GUI 없이도 작동 – 서버 환경에 최적

리눅스 서버에는 GUI가 없기 때문에, 마우스가 없이도 테스트가 가능합니다.
curl은 CLI 환경에서도 강력한 HTTP 요청 도구 역할을 합니다.

7. 대체 도구는 있지만, curl만큼 범용적이지 않음

wget	다운로드 특화, POST는 가능하지만 유연성 떨어짐
httpie	가독성 좋고 현대적, 하지만 기본 설치 아님
Postman	GUI 기반, 리눅스 서버에 적합하지 않음
curl	가볍고 강력하며 거의 모든 작업에 대응 가능

마무리 요약

범용성	거의 모든 시스템에서 작동
기능성	다양한 HTTP 메서드, 인증, 헤더, 파일 전송 지원
자동화	스크립트와 쉽게 통합 가능
디버깅	응답 상태, 헤더 확인 등 실시간 추적 가능
서버 최적화	GUI 없이도 테스트 및 실행 가능

“무조건 API 호출은 curl을 사용해야 한다”가 아니라, 서버 환경과 기획 의도에 맞는 적절한 요청 도구를 사용하는 게 가장 좋습니다.

[ Linux ] man 명령어 - 섹션, 검색, 키워드 활용법

soyali — Mon, 2 Jun 2025 17:46:18 +0900

man은 "manual"의 줄임말로, 명령어의 공식 문서를 확인할 수 있는 기본 도구입니다.

1. man 사용법

man <알고싶은 명령어>

를 입력하면 less 명령어가 사용되어 매뉴얼이 보이게 됩니다.

조작키

space : 아래로 스크롤
q : 종료

2. man 페이지 구성

항목	설명
NAME	명령어 이름과 간략한 설명
SYNOPSIS	사용 형식 (옵션 포함)
DESCRIPTION	기능 및 작동 방식에 대한 상세 설명
OPTIONS	사용 가능한 옵션 목록
EXAMPLES	사용 예시 (있는 경우)
SEE ALSO	관련 명령어나 참고할 문서

3. 키워드 검색 방법 (man 페이지 안에서 찾기)

예시

man less

man 페이지 안에서 슬래시(/)를 누르고 검색어 입력 :

/color

해당 키워드를 포함한 항목으로 커서 이동
→ 다음 결과로 이동: n
→ 이전 결과로 이동: N

4. man 섹션 번호란?

리눅스의 매뉴얼은 총 9개의 섹션으로 나뉘며, 같은 이름의 명령어나 함수라도 구분해서 문서화되어 있습니다.

섹션 번호	내용
1	사용자 명령어 (Executable programs)
2	시스템 호출 (System calls, 예: open, read)
3	라이브러리 함수 (예: printf, malloc)
4	특수 파일 (디바이스, 드라이버 등)
5	파일 포맷 및 구성 파일
6	게임 및 유머 콘텐츠
7	기타 정보 (매크로, 규약 등)
8	시스템 관리자 명령어 (root 전용)
9	커널 관련 함수 (일부 시스템 한정)

세션 9번은 있을 수도 있고, 없을 수도 있습니다.

5. 키워드로 관련된 man 항목 찾기

man -k 키워드

예시

man -k list

키워드 "list"가 포함된 man 페이지 항목들을 검색

예시 출력

acl (5) - Access Control Lists
BIO_listen (3ssl) - BIO socket communication setup routines
chacl (1) - change the access control list of a file or directory
ciphers (1ssl) - SSL cipher display and cipher list tool
column (1) - columnate lists.......................................

6. 자주 쓰는 man 관련 명령 요약

명령	설명
man 명령어	기본 매뉴얼 보기
man -f 명령어	해당 이름이 어떤 섹션에 있는지 확인
man -k 키워드	키워드 기반 관련 문서 검색
/키워드	man 내부에서 키워드 검색
n, N	다음/이전 검색 결과로 이동
q	종료

마무리

빠르게 보고 싶을 때 → --help
깊이 이해하고 싶을 때 → man
정확히 찾아야 할 때 → man -k, /검색

[ Linux ] 명령어 설명 보는 법 – --help vs man

soyali — Mon, 2 Jun 2025 16:35:14 +0900

처음 Linux를 배우다 보면 이게 무슨 명령어고 어떻게 쓰는 건지 자주 질문하시는데요.
이때 사용하는 명령어가 바로 --help 옵션 또는 man 명령어 입니다.

하지만 둘은 약간의 차이가 있고, 사용하는 목적도 다릅니다.

이번 글에서는 두 도구의 사용법, 차이점, 언제 쓰면 좋은지를 함께 정리해보겠습니다.

1. --help 옵션 – 빠르게 요약 보기

사용법

명령어 --help

특징

짧고 간단한 요약 형태의 도움말 제공
자주 쓰는 옵션이나 기본 사용 예제를 빠르게 확인 가능
대부분 GNU 명령어에서 지원됨

언제 사용하면 좋을까?

옵션이 뭐였더라? 빠르게 기억 확인할 때
복잡한 문서 대신 짧은 힌트가 필요할 때
ls, cp, mkdir 같은 간단한 명령어 확인 시

2. man 명령어 – 매뉴얼 페이지 읽기

사용법

man [명령어]

특징

명령어의 공식 매뉴얼 페이지를 보여줌
옵션 설명, 예제, 반환 코드, 관련 명령어까지 상세하게 제공
터미널에서 페이지 방식으로 열림 (↑↓ 이동, / 검색, q 종료)

언제 사용하면 좋을까?

옵션 외에 전체적인 사용법을 학습하고 싶을 때
정확한 기능 설명과 동작 원리가 필요할 때
프로그래밍, 스크립트 작성 등에서 세부 동작 파악이 필요할 때

차이점 비교 요약

항목	--help	man
정보 수준	간단한 요약	자세한 매뉴얼
속도/형식	터미널에 바로 출력	페이지 방식 (less처럼 탐색 가능)
예제 포함 여부	거의 없음	종종 포함됨
목적	빠르게 옵션 확인	공식 문서 수준의 상세 설명
검색 가능 여부	기본 제공 안 됨	/검색어로 키워드 검색 가능

마무리

빠르게 요약 확인 → 명령어 --help
정식 매뉴얼 확인 → man 명령어