리눅스 명령어 기본 모음, 맥 터미널에서 직접 해 보니 같은 것과 다른 것

맥 터미널에서 free -h를 치면 zsh:2: command not found: free가 돌아옵니다. 파일, 권한, 프로세스, 압축을 다루는 리눅스 명령어는 맥의 zsh에서 종료 코드 0으로 끝났고 대부분 0.0초 만에 마쳤어요. 하지만 free, ip, wget은 없었고 sed -i와 stat -c는 오류를 냈습니다. AI 코딩 도구가 알려 준 명령을 맥에 그대로 붙여 넣고 있다면, 이 기록으로 어디가 같고 어디가 다른지 먼저 확인해 보세요.

터미널 명령어 기본 모음, 한 표로 보기

아래 표는 자주 쓰는 명령을 하는 일과 함께 정리한 것입니다. 오른쪽 칸은 이번에 맥 터미널에서 실제로 친 형태예요.

결론부터 말하면, 표의 명령은 맥 터미널에서 모두 종료 코드 0으로 끝났습니다. 달랐던 건 다섯 군데예요. free, ip, wget은 명령 자체가 없었고(종료 코드 127), sed -i와 stat -c는 둘 다 오류 문구를 냈습니다(두 명령을 이어 붙인 줄 전체의 종료 코드는 마지막 stat 기준으로 1). 맥의 기본 명령은 BSD 계열이라서 리눅스의 GNU 명령과 옵션이 다를 수 있기 때문이죠.

도식출처: 직접 실행한 순서

그럼 각 명령을 실제로 치면 무엇이 찍힐까요? 주제별로 명령과 출력을 한 번씩 그대로 옮깁니다.

함께 읽을 글

• 파이썬(Python) 딕셔너리 사용법, 자주 쓰는 동작을 직접 실행해 보니
• tar 압축 해제 방법, macOS 터미널에서 tar.gz와 zip 직접 풀어 보니
• 깃(git) stash 사용법, 새 파일까지 치우고 다시 꺼내 보니

파일과 폴더는 어떻게 다룰까요?

아래 예제는 모두 빈 연습 폴더 하나를 기준 위치로 삼습니다. 코드 블록은 하나하나 이 연습 폴더에서 새로 시작해 실행한 기록이라, 블록마다 cd project로 시작합니다. 먼저 연습 폴더를 만들고 목록을 봅니다. mkdir -p는 중간 폴더까지 한 번에 만들고, ls -la는 숨김 항목과 권한까지 보여 줍니다.

$ pwd && mkdir -p project/src project/docs && touch project/README.md && ls && ls -la project
.
project
total 0
drwxr-xr-x@ 5 finn  wheel  160 Oct 27 17:05 .
drwxr-xr-x@ 3 finn  wheel   96 Oct 27 17:05 ..
-rw-r--r--@ 1 finn  wheel    0 Oct 27 17:05 README.md
drwxr-xr-x@ 2 finn  wheel   64 Oct 27 17:05 docs
drwxr-xr-x@ 2 finn  wheel   64 Oct 27 17:05 src

이어서 네 줄짜리 파일을 만들고 cat, head, tail로 읽었습니다. wc -l은 줄 수를 셉니다.

$ cd project && printf '첫째 줄\n둘째 줄\n셋째 줄\n넷째 줄\n' > docs/note.txt && cat docs/note.txt && head -n 2 docs/note.txt && tail -n 1 docs/note.txt && wc -l docs/note.txt
첫째 줄
둘째 줄
셋째 줄
넷째 줄
첫째 줄
둘째 줄
넷째 줄
       4 docs/note.txt

복사, 이동, 이름 바꾸기, 지우기도 연습 폴더에서 다시 시작해 한 줄로 이어서 실행했습니다. 한 터미널에서 순서대로 따라 한다면 블록 하나를 실행한 뒤에는 project의 상위 폴더인 연습 폴더로 돌아와서 다음 블록을 실행하는 편이 좋습니다. 그러지 않으면 project 안에서 다시 project를 찾다가 실패합니다. 뒤에 나오는 du와 tar 예제도 이 연습 폴더에서 실행합니다. mv는 옮길 때도, 이름을 바꿀 때도 같은 명령을 씁니다.

$ cd project && cp docs/note.txt docs/note-copy.txt && mv docs/note-copy.txt src/ && mv src/note-copy.txt src/memo.txt && ls docs src && rm src/memo.txt && ls src
docs:
note.txt

src:
memo.txt

지운 파일이 정말 사라졌는지는 어떻게 알까요? 마지막 ls src가 아무것도 출력하지 않은 것이 그 답이죠. 이 실행에서 지우는 명령은 연습 폴더 안에서만 썼습니다. 폴더째 지우는 rm -r처럼 되돌릴 수 없는 명령도 연습 폴더에서 먼저 쳐 보는 것이 안전합니다.

파일과 글자를 찾는 방법

find는 이름으로, grep은 내용으로 찾습니다. grep -rn은 하위 폴더까지 뒤져 줄 번호를 붙이고, | head -3이 앞 세 줄만 남깁니다.

$ cd project && find . -name '*.txt' && grep -n '셋째' docs/note.txt && grep -rn '줄' . | head -3
./docs/note.txt
3:셋째 줄
./docs/note.txt:1:첫째 줄
./docs/note.txt:2:둘째 줄
./docs/note.txt:3:셋째 줄

스크립트에 실행 권한을 주려면?

AI 에이전트가 만들어 준 셸 스크립트가 실행되지 않는다면 권한부터 보세요. chmod +x 전후로 ls -l을 비교하면 x가 붙은 것이 보입니다.

$ cd project && printf '#!/bin/sh\necho 스크립트 실행됨\n' > run.sh && ls -l run.sh && chmod +x run.sh && ls -l run.sh && ./run.sh
-rw-r--r--@ 1 finn  wheel  38 Oct 27 17:05 run.sh
-rwxr-xr-x@ 1 finn  wheel  38 Oct 27 17:05 run.sh
스크립트 실행됨

프로세스를 보고 끝내는 방법

개발 서버가 멈추지 않을 때 쓰는 조합입니다. sleep 300 &로 뒤에서 도는 프로세스를 만들고 ps로 확인한 다음 kill로 끝냈습니다.

$ sleep 300 & pid=$! && ps -p $pid -o pid,comm && kill $pid && sleep 0.2 && ps -p $pid -o pid,comm || echo "$pid 프로세스가 끝남"
  PID COMM
92137 sleep
  PID COMM
92137 프로세스가 끝남

두 번째 ps는 머리줄만 찍고 프로세스를 찾지 못했습니다. 그래서 || 뒤의 echo가 실행됐어요.

디스크와 폴더 크기 확인

df -h는 디스크 전체를, du -sh는 폴더 하나의 크기를 사람이 읽기 쉬운 단위로 보여 줍니다.

$ df -h / && du -sh project
Filesystem        Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/disk3s3s1   1.8Ti    13Gi   1.4Ti     1%    484k  4.3G    0%   /
8.0K	project

그런데 리눅스 서버에서는 어떻게 나올까요? 이번 실행은 맥에서만 했으니 리눅스 출력은 문서로만 짚어 볼게요. GNU coreutils 설명서는 GNU의 df, du, ls가 크기를 블록 단위로 보여 준다고 설명합니다. human-readable 형식에서는 크기 뒤에 M 같은 단위 글자가 붙고 1024의 거듭제곱을 쓰며, si 형식은 1000의 거듭제곱을 쓴다고 하죠.

압축 파일 만들고 안을 보는 방법

배포용으로 폴더를 묶을 때는 tar -czf로 만들고 tar -tzf로 안을 확인합니다.

$ tar -czf project.tar.gz project && tar -tzf project.tar.gz
project/
project/docs/
project/run.sh
project/README.md
project/src/
project/docs/note.txt

웹 요청으로 서버 응답 확인하기

배포한 서비스가 살아 있는지 볼 때는 curl -sI로 응답 머리만 받아 봅니다. 이 단계는 0.6초가 걸렸습니다.

$ curl -sI https://example.com | head -3
HTTP/2 200
date: Tue, 27 Oct 2026 08:05:32 GMT
content-type: text/html; charset=utf-8

파이프와 리다이렉션은 어떻게 쓸까요?

|는 앞 명령의 출력을 뒤 명령에 넘깁니다. 예를 들어 sort | uniq -c는 같은 줄이 몇 번 나왔는지 세 주죠. >로 words.txt를 만들었고, >>로 app.log에 한 줄을 붙인 뒤 cat으로 확인했습니다.

$ printf 'b\na\nb\nc\nb\n' > words.txt && sort words.txt | uniq -c && ls project | wc -l && echo '로그 한 줄' >> app.log && cat app.log
   1 a
   3 b
   1 c
       4
로그 한 줄

맥에서 실패한 리눅스용 명령 모아 보기

여기까지의 예제는 이번 맥 환경에서 성공했습니다. 리눅스에서의 출력과 옵션 호환성은 비교 실행하지 않았습니다. 이제 리눅스에서 흔히 쓰는 명령을 맥에 그대로 친 결과를 숨기지 않고 모았어요. 먼저 명령 자체가 없는 경우입니다.

$ free -h; ip addr; wget --version
zsh:2: command not found: free
zsh:2: command not found: ip
zsh:2: command not found: wget

다음은 명령은 있지만 GNU 방식 옵션이 통하지 않은 경우입니다. sed -i는 오류 문구를 냈고, stat -c는 illegal option -- c와 함께 맥 stat이 받는 옵션 목록을 보여 줬습니다.

$ echo a > x.txt && sed -i 's/a/b/' x.txt; stat -c %s x.txt
sed: 1: "x.txt
": extra characters at the end of x command
stat: illegal option -- c
usage: stat [-FLnq] [-f format | -l | -r | -s | -x] [-t timefmt] [file ...]

이름이 같아도 맥 쪽은 BSD 계열, 리눅스 쪽은 GNU 계열이라는 점이 핵심입니다. GNU 설명서는 자기 유틸리티가 대부분 POSIX 표준과 호환된다고 밝히지만, -i나 -c 같은 옵션까지 맥과 같다는 보장은 아니죠. 서버용 배포 스크립트를 맥에서 먼저 돌려 본다면 sed와 stat 줄부터 확인하는 게 좋겠습니다.

Claude Code에게 맥용 대신할 명령을 물어보면?

그렇다면 맥에서는 무엇으로 대신할까요? claude --model opus -p로 Claude Code 2.1.309에 한 번 물어봤습니다. 아래는 그때 한 번 받은 답이라, 다시 물으면 다르게 나올 수 있어요.

$ claude --model opus -p "맥 터미널에서 리눅스의 free -h, ip addr, sed -i 's/a/b/' 파일, stat -c %s 파일 대신 쓸 수 있는 명령을 하나씩, 명령만 한 줄씩 출력해. 설명이나 코드 블록 표시는 붙이지 마."
vm_stat
ifconfig
sed -i '' 's/a/b/' 파일
stat -f %z 파일

이 단계의 5.7초는 명령을 실행해 답이 끝까지 출력될 때까지 걸린 시간입니다. 기록에는 받은 명령을 실행한 출력이 따로 없으니, 연습 폴더의 x.txt 같은 파일에 직접 쳐서 확인해 보세요. wget은 이번 질문에 넣지 않았습니다.

도식출처: 근거를 바탕으로 코드가 그린 도식

AI 에이전트에게 셸 명령을 맡긴다면 프롬프트에 "맥 터미널에서"처럼 실행할 곳을 적어 두는 편이 낫습니다. 이번 질문에는 "맥 터미널에서"라고 적었고, 받은 답 네 줄은 모두 맥용 형태였습니다. 실행할 곳을 빼고 물었을 때와는 비교하지 않았습니다.

측정 조건과 한계

실행 환경은 다음과 같습니다. 새 임시 폴더에서 각 명령을 적힌 차례대로 한 번씩만 실행했고, Claude Code는 이미 로그인된 상태였습니다.

$ uname -s -r -m && echo "$SHELL" && zsh --version
Darwin 27.0.0 arm64
/bin/zsh
zsh 5.9 (arm64-apple-darwin26.0)

0.0초가 아닌 단계와 오류가 난 단계만 추리면 이렇습니다.

한 번씩만 잰 값이라 이 측정만으로는 단계별 시간 차이의 원인을 가를 수 없습니다. 궁금하다면 같은 명령을 여러 번 돌려 비교해 보세요. 또 리눅스에서는 실행하지 않았으니, 리눅스 쪽 동작은 GNU coreutils 설명서와 리눅스 매뉴얼 intro(1)에서 확인하는 것이 맞습니다. 리눅스 매뉴얼 1절은 파일 다루는 도구와 셸 같은 사용자 명령을 다룹니다.