Step 19. 리눅스 기본 명령어 2 — 출력을 조종하는 세 개의 수도관

Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★★☆☆ | 예상 소요 시간 3시간

전제: Step 18 완료. 가상머신 속 우분투 터미널에서 진행합니다.

준비물: 우분투 가상머신, 터미널 두 개 띄울 수 있는 환경(3-5절에서 사용).
주의: 오늘 실습은 VM 안이라 100% 안전합니다. ⚠️ 단 하나의 주의보가 있습니다 — >는 기존 파일 내용을 지우고 씁니다. 이것만 확실히 잡고 넘어갑니다.
실측 안내: 이 챕터의 출력은 Ubuntu 24.04에서 실제 실행한 결과입니다. 실측은 관리자(root) 계정으로 진행되어 경로에 /root가 보이지만, 여러분의 VirtualBox 우분투에서는 /home/사용자이름으로 보입니다. 그 차이 외에는 같습니다.

공장의 기계들을 생각해 보세요. 각 기계에는 물이 들어오는 관과 나가는 관이 있습니다. 배관공이 나가는 관을 뽑아 하수구 대신 다른 기계의 입구에 꽂으면, 두 기계가 연결된 생산라인이 됩니다. 리눅스의 명령들이 바로 이 기계들입니다. 화면으로 나오던 출력을 파일로 돌리고(>), 다른 명령의 입력으로 돌리고(|). 이 배관 기술이 리눅스 명령의 진짜 힘입니다. Step 3의 파이프와 Step 4의 Out-File을 기억해 두세요 — 이름만 다르고 사상은 같습니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

표준 스트림(stdin/stdout/stderr) 세 개의 관을 번호와 함께 설명한다
cat, less, head, tail을 파일의 길이와 목적에 맞게 골라 쓴다
>와 >>의 차이(덮어쓰기 vs 이어 붙이기)를 설명하고 올바르게 쓴다
파이프(|)로 명령 두 개를 연결해 결과를 가공한다
tail -f로 실시간 로그 감시를 체험하고 Ctrl + C로 종료한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	우분투 리눅스 터미널 (bash)
오늘의 명령어	`cat` / `less` / `head` / `tail`(파일 보기), `echo`(출력 만들기), `wc -l`(줄 수 세기), `>` `>>` `
필요한 개념	표준 스트림(0·1·2번 관), 리다이렉션, 파이프, 덮어쓰기 vs 이어 붙이기

2-1. 표준 스트림 — stdin, stdout, stderr

리눅스의 모든 명령에는 세 개의 관 — 표준 스트림(standard stream) — 이 기본으로 연결되어 있습니다:

이름	번호	역할	기본 연결
stdin (표준 입력)	0	들어오는 것	키보드
stdout (표준 출력)	1	정상 결과	화면
stderr (표준 오류)	2	오류 메시지	화면

핵심 통찰: "정상 결과"와 "오류"가 서로 다른 관으로 흐릅니다. 둘 다 화면에 보여서 구별이 안 됐던 것뿐입니다. 이 구분이 왜 중요한지는 Step 20에서 실감합니다 — 오류 관(2번)만 따로 쓰레기통에 버리는 기술이 있거든요.

2-2. 리다이렉션 — 관의 방향 바꾸기

출력이 기본적으로 화면으로 간다고 했습니다. 그 방향을 바꾸는 것이 리다이렉션(redirection)입니다:

명령 > 파일 — 출력을 파일로 (기존 내용은 삭제하고 새로 씀)
명령 >> 파일 — 출력을 파일 끝에 이어 붙임

Step 5에서 파워쉘의 Out-File -Append를 배울 때 "기록은 덮어쓰는 게 아니라 쌓는 것"이라고 했죠. 리눅스에서는 >와 >>가 그 역할입니다. 그리고 오늘의 주의보: 한 개(>)와 두 개(>>)의 차이는 "지우고 쓰기"와 "이어 쓰기" — 이 한 글자 차이로 소중한 파일이 날아가는 사고가 초보 시절 누구에게나 있습니다. 오늘 안전하게 겪고 가세요.

2-3. 파이프 — 명령에서 명령으로

|는 "왼쪽 명령의 출력을, 오른쪽 명령의 입력으로" 잇는 관입니다. Step 3에서 파워쉘로 배운 바로 그 개념이고, 사실 이 발상의 원조가 리눅스(정확히는 유닉스)입니다. "작은 도구들을 조립한다"는 철학의 핵심 부품이죠.

2-4. 파일을 보는 네 가지 도구 — 왜 넷인가

도구	특성	언제 쓰나
`cat`	전체를 한 번에 쏟아냄	짧은 파일
`less`	한 화면씩, 앞뒤로 탐색	긴 파일
`head`	앞부분만	처음 몇 줄 확인
`tail`	뒷부분만	로그의 최신 기록

로그 파일은 뒤로 갈수록 최신입니다. 그래서 보안 분석가가 가장 많이 쓰는 게 tail — "최근에 무슨 일이?"는 항상 파일의 뒤쪽에 있습니다.

3. 따라 하기

3-1. 보기 도구 체험 — cat, head, tail

시스템에 있는 파일로 연습해 봅시다. /etc/passwd는 사용자 계정 목록이 적힌 파일입니다:

cat /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

(2026-09-09 실측 — 실측 환경에서는 29줄짜리 파일이 전부 출력됐습니다. 여러분의 VM은 설치 때 만든 계정 줄이 추가되어 조금 깁니다.)

읽는 법: 한 줄이 계정 하나입니다. 이름:x:번호:번호:설명:홈디렉토리:기본셸 형태죠. 화면이 주르륵 지나갑니다 — 짧은 파일이라 다행입니다. 이번엔 긴 파일을 여행하는 도구:

less /etc/passwd

다른 세계가 열립니다: 화면 하나만큼만 보이고, 스페이스바로 다음 페이지, ↑↓로 한 줄씩 이동, / 누르고 글자를 치면 검색, 끝낼 때는 q. less는 "파일 속을 여행하는 도구"입니다. q를 눌러 나오세요.

head -n 5 /etc/passwd

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync

tail -n 5 /etc/passwd

uuidd:x:103:103::/run/uuidd:/usr/sbin/nologin
landscape:x:104:105::/var/lib/landscape:/usr/sbin/nologin
polkitd:x:990:990:User for polkitd:/:/usr/sbin/nologin
dnsmasq:x:999:65534:dnsmasq:/var/lib/misc:/usr/sbin/nologin
tcpdump:x:105:110::/nonexistent:/usr/sbin/nologin

(2026-09-09 실측.)

출력 읽는 법: 앞 5줄, 뒤 5줄만 나옵니다. -n 5는 "5줄"이라는 옵션. 파일이 아주 길 때 "어떻게 생겼나" 확인하는 가장 빠른 방법입니다.

왜 하는가: 지금은 작은 파일이라 감흥이 없지만, 나중에 수십만 줄짜리 로그를 만나면 cat은 화면을 도배하고 터미널을 멈추게 합니다. 그때 "아, 그래서 less와 tail이 있구나"가 절로 나옵니다.

3-2. 만들고 덮어쓰고 이어 붙이기 — > vs >>

연습 디렉토리에서 합시다 (cd ~ 후 mkdir stream-lab; cd stream-lab):

echo "hello" > a.txt
cat a.txt

hello

echo는 "받은 글자를 그대로 출력"하는 명령입니다. >가 그 출력을 화면 대신 파일로 돌렸죠. 이제 오늘의 주의 실험:

echo "world" > a.txt
cat a.txt

world

(2026-09-09 실측.)

예측하셨나요? hello는 사라지고 world뿐입니다. >는 덮어쓰기 — 기존 내용을 조용히 지웁니다. 이제 이어 붙이기:

echo "hello again" >> a.txt
cat a.txt

world
hello again

(2026-09-09 실측.)

>>는 끝에 이어 붙입니다. 이 차이가 오늘의 핵심입니다: 저장할 때마다 "지금 >를 써도 되는 상황인가?"를 한 번 물어보세요. 로그를 쌓는 상황이면 >>, 의도적으로 새로 쓰는 상황이면 >입니다.

3-3. 파이프 — 명령 합체

ls /etc | wc -l

(2026-09-09 실측. 숫자는 환경에 따라 다릅니다 — 설치된 구성 요소가 다르면 개수도 달라집니다.)

읽는 법: ls /etc의 출력(파일 목록)이 화면에 안 나오고, wc -l의 입력으로 흘러갔습니다. wc는 word count — -l 옵션으로 줄 개수를 셉니다. 결과: "/etc 아래 항목이 180개."

Step 5 기억나시나요? Get-Service | Measure-Object와 정확히 같은 패턴입니다. 목록 만들기 → 개수 세기. 도구가 바뀌어도 사고방식은 하나입니다.

3-4. 저장하고 확인하기 — 실전 루틴

ls -la /etc > filelist.txt
head -n 3 filelist.txt

total 864
drwxr-xr-x 100 root root       4096 Sep  9 11:29 .
drwxr-xr-x  22 root root       4096 Sep  9 11:28 ..

(2026-09-09 실측.)

루틴의 모양: 생성(>) → 확인(head/cat). 저장한 것은 반드시 바로 확인 — 이 2초의 습관이 "저장한 줄 알았는데 빈 파일" 사고를 막습니다.

왜 출력을 파일로 돌리는가: 이 작은 기술이 자동화의 문턱입니다. 명령의 결과를 파일에 남길 수 있다는 것은 — ① 기록: "그때 뭐가 있었는지" 나중에 비교 가능(Step 15의 베이스라인!), ② 전달: 결과를 다른 프로그램이나 사람에게 넘길 수 있음, ③ 야간 작업: 사람이 자는 사이 실행된 명령의 결과를 아침에 읽을 수 있음. Step 9의 스크립트가 "창을 닫아도 남는 명령"이라면, 리다이렉션은 "끝나고도 남는 결과"입니다.

3-5. 실시간 감시 — tail -f

오늘의 하이라이트. 터미널 창을 두 개 여세요(파일 메뉴 → 새 창, 또는 Ctrl + Alt + T 두 번).

창 1에서:

touch live.log
tail -f live.log

아무 일도 안 일어나고 커서가 깜빡입니다 — 끝나는 명령이 아닙니다. tail -f는 "파일의 끝을 계속 지켜본다"(follow)입니다. 파일에 새 줄이 추가되면 즉시 화면에 뜹니다.

창 2에서:

echo "첫 번째 사건" >> ~/stream-lab/live.log
echo "두 번째 사건" >> ~/stream-lab/live.log

창 1을 보세요 — 방금 그 줄들이 실시간으로 나타났습니다:

첫 번째 사건
두 번째 사건

(2026-09-09 실측 — 같은 원리로 실행해 확인한 실제 화면 출력입니다.)

끝낼 때는 창 1에서 Ctrl + C.

예측해 보기: 로그가 1초에 수십 줄씩 쌓이는 서버에서 tail -f를 하면 어떤 광경일까요? (정답: 화면이 쉴 새 없이 올라갑니다. 그래서 실전에서는 tail -f 로그 | grep ERROR처럼 파이프로 필터를 붙여서 원하는 것만 봅니다 — 오늘 배운 두 기술의 합체이자, 보안 관제실 화면의 원리입니다.)

왜 이게 보안과 관련되는가: 보안 관제의 출발점이 "로그를 실시간으로 지켜보는 것"입니다. 공격 징후(로그인 실패 폭주 등)가 로그에 찍히는 순간을 눈으로 확인하는 것 — 오늘 여러분이 그 감시대의 축소판을 직접 돌려 본 겁니다.

4. 미션과 연습문제

미션 — 나만의 관찰 일지

watch-log.txt 파일을 만들고, 오늘 실습한 명령 중 다섯 개를 echo와 >>로 한 줄씩 이어 붙여 기록하세요 (예: echo "1. ls /etc | wc -l → 180개" >> watch-log.txt)
매번 >>를 써서 다섯 줄이 쌓이게 하세요 (한 줄이라도 >로 쓰면 앞의 것이 지워집니다 — 그게 검증입니다)
cat watch-log.txt로 최종 확인
마지막으로 ls /etc | tail -n 3을 실행하고, 파이프 뒤에 tail이 붙는 이유를 말로 설명해 보세요

스스로 검증하는 법: 최종 파일에 다섯 줄이 모두 있으면 통과. 중간 줄이 사라졌다면 어디서 >를 썼는지 돌아보세요 — 이것이 오늘의 주의보를 몸에 새기는 방법입니다.

연습문제

문제 1. >와 >>의 차이를 "기존 내용의 운명" 관점에서 설명하고, 로그 파일을 쌓을 때 어느 쪽을 써야 하는지 말해 보세요.

문제 2. 표준 스트림 세 개의 번호와 역할을 말하고, "정상 결과와 오류가 다른 관으로 흐른다"는 사실이 왜 유용한지 한 가지 예를 들어 보세요.

문제 3. ls /etc | wc -l의 실행 과정을 "왼쪽의 출력 → 오른쪽의 입력"이라는 말을 써서 설명해 보세요.

문제 4. tail -f는 왜 스스로 끝나지 않으며, 어떻게 멈추나요? 그리고 이 명령이 보안 관제에서 쓰이는 이유는 무엇일까요?

5. 모범 답안과 완료 기준

미션 모범 답안

cd ~/stream-lab
echo "1. cat /etc/passwd — 계정 파일 전체 보기" >> watch-log.txt
echo "2. head -n 5 /etc/passwd — 앞 5줄만" >> watch-log.txt
echo "3. ls /etc | wc -l — /etc 항목 수 세기 (실측 180개)" >> watch-log.txt
echo "4. echo ... >> a.txt — 이어 붙이기" >> watch-log.txt
echo "5. tail -f live.log — 실시간 감시 (Ctrl+C로 종료)" >> watch-log.txt
cat watch-log.txt

1. cat /etc/passwd — 계정 파일 전체 보기
2. head -n 5 /etc/passwd — 앞 5줄만
3. ls /etc | wc -l — /etc 항목 수 세기 (실측 180개)
4. echo ... >> a.txt — 이어 붙이기
5. tail -f live.log — 실시간 감시 (Ctrl+C로 종료)

검증하는 법: ① cat 결과가 다섯 줄인가. ② 각 줄이 이어 붙은 순서대로 쌓였는가. ③ 참고로 >와 >> 둘 다 대상 파일이 없으면 새로 만들기 때문에, 첫 줄을 >>로 시작해도 파일이 만들어집니다. ④ ls /etc | tail -n 3의 설명 예시: "목록 전체를 화면에 뿌리지 않고, 파이프로 tail에 흘려서 마지막 3줄만 보기 위해" (실측 출력: xdg, xml, zsh_command_not_found — 여러분 환경에서는 다를 수 있습니다).

연습문제 해답

문제 1 해답. >는 기존 내용을 지우고 새로 쓰고(덮어쓰기), >>는 기존 내용 끝에 이어 붙입니다. 로그처럼 기록을 쌓는 상황에서는 반드시 >>를 씁니다 — >로 쓰면 이전 기록이 통째로 날아갑니다.

문제 2 해답. 0번 stdin(입력, 기본 키보드), 1번 stdout(정상 출력, 기본 화면), 2번 stderr(오류, 기본 화면). 유용성의 예: 오류 메시지(2번)만 따로 버리거나 파일로 모을 수 있어서, 정상 결과(1번)가 오류에 묻히지 않습니다. Step 20의 2>/dev/null이 바로 이 응용입니다.

문제 3 해답. ls /etc의 출력(파일 목록)이 화면에 나오지 않고 파이프를 통해 wc -l의 입력으로 흘러갑니다. wc -l은 입력의 줄 수를 세어 출력하므로, 결과는 "/etc 아래 항목의 개수"입니다 (실측 180).

문제 4 해답. tail -f의 일은 "파일의 끝을 계속 지켜보는 것"이라 스스로 끝나지 않는 것이 설계입니다. Ctrl + C로 멈춥니다 — "현재 실행 중인 것을 중단"하는 만능 브레이크입니다. 보안 관제에서 쓰이는 이유: 공격 징후가 로그에 찍히는 그 순간을 실시간으로 보기 위해서입니다.

완료 기준 체크리스트

[ ] 세 표준 스트림(입력/출력/오류)을 번호와 함께 설명할 수 있다
[ ] cat·less·head·tail을 상황에 맞게 고를 수 있다
[ ] less에서 q로 빠져나올 수 있다
[ ] >와 >>의 차이를 설명하고 올바르게 쓸 수 있다
[ ] 파이프로 명령 두 개를 연결할 수 있다 (ls /etc | wc -l 등)
[ ] tail -f로 실시간 감시를 체험하고 Ctrl + C로 종료했다
[ ] 미션: watch-log.txt 다섯 줄을 완성했다

6. 흔한 실수와 해결

벽 1. >로 썼더니 앞 내용이 사라졌다

증상: 분명 이어 썼는데 파일에 마지막 줄만 있습니다.
원인: 오늘의 주의보 그대로 — >는 덮어쓰기입니다.
해결: 누적은 >>. 그리고 이 사고를 지금 연습장에서 겪은 것은 행운입니다. VM에서 한 번 겪으면 평생 기억합니다.

벽 2. less에서 못 나오겠다

증상: less 안에서 뭘 쳐도 명령이 안 먹습니다.
원인: less는 자체 세계입니다 — 그 안의 키 조작법이 따로 있습니다.
해결: q가 탈출구입니다. 이것만 외우세요. (참고로 less 안에서 /로 검색, n으로 다음 발견 — 긴 로그에서 사건 현장만 짚어 다니는 분석가의 실제 손놀림입니다.)

벽 3. tail -f가 끝나지 않는다

증상: 명령이 완료되지 않고 커서만 깜빡입니다.
원인: 고장이 아니라 설계입니다 — 지켜보는 게 일인 명령이라 스스로 끝나지 않습니다.
해결: Ctrl + C. 터미널에서 "멈추지 않는 것"의 공통 해결책입니다.

벽 4. 파이프를 쳤는데 앞 명령 결과가 그대로 나온다

증상: ls /etc | wc -l인데 목록이 보입니다.
원인: |가 제대로 입력되지 않았거나(한글 입력 상태 등), 순서가 뒤집혔습니다.
해결: 자판 상태를 확인하고, "왼쪽의 출력 → 오른쪽의 입력" 순서를 소리 내서 읽어 보세요. 파이프에는 방향이 있습니다.

벽 5. echo를 쳤는데 따옴표나 특수문자가 이상하게 나온다

증상: echo "$HOME" 등에서 의도와 다른 출력.
원인: Step 7에서 배운 그것 — 큰따옴표는 변수를 풀고, 작은따옴표는 글자 그대로. bash도 같은 규칙입니다!
해결: 의도를 정하고 따옴표를 고르세요: 값을 풀려면 " ", 그대로 쓰려면 ' '. 이 규칙이 윈도우에서 리눅스로 그대로 넘어온다는 게 재미있는 지점입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
표준 스트림	입력(0)·출력(1)·오류(2) 세 개의 관
`>` / `>>`	덮어쓰기 / 이어 붙이기 — 차이를 명심!
`	` (파이프)
`tail -f`	파일 끝을 실시간 감시 (Ctrl+C로 종료)

오늘의 명령어

명령	하는 일
`cat` / `less`	전체 보기 / 페이지로 탐색 (q로 종료)
`head` / `tail`	앞부분 / 뒷부분 (`-n 5`로 줄 수)
`echo`	글자 출력 (파일 만들기의 재료)
`wc -l`	줄 수 세기 (파이프의 단골 파트너)

명령어보다 중요한 감각

로그 분석의 실제 손동작은 오늘 배운 것들의 조합입니다: 최신 기록은 tail로, 감시는 tail -f로, 수집은 >>로, 집계는 | wc -l로. 그리고 >의 덮어쓰기 사고는 "기록을 날리는" 대표적 실수 — 증거를 다루는 사람일수록 이 한 글자에 민감해야 합니다.

두 가지를 더 기억해 두세요. 첫째, 오늘의 파이프 뒤에는 50년 된 유닉스 철학이 있습니다 — "한 가지를 잘하는 작은 프로그램들을 조립해 큰 일을 해라." grep은 찾기만, wc는 세기만, tail은 끝만 보지만, 이것들을 |로 엮으면 "로그에서 에러만 골라 개수를 센다"가 한 줄이 됩니다. 둘째, 나중에 2>&1이라는 암호문을 만나면 오늘의 표로 해독하세요 — "2번 관(오류)을 1번 관(출력)과 같은 곳으로(&1) 본낸다." 오늘의 세 수도관 표가 그 암호의 해독 열쇠입니다.

전부 체크되면 Step 19 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.