쉘 스크립트를 쓰다 보면 잠깐 저장할 파일이 필요할 때가 많습니다. API 응답을 받아서 가공하거나, 여러 명령의 중간 결과를 합치거나, 압축하기 전에 작업 디렉토리를 하나 만들어두는 경우가 그렇죠. 처음에는 대충 /tmp/result.txt 같은 이름을 쓰기 쉽습니다. 조금 더 신경 쓰면 프로세스 ID를 붙여서 /tmp/myapp.$$처럼 만들기도 하고요. 혼자 쓰는 노트북에서는 별문제가 없어 보이지만, 이런 방식은 스크립트가 서버나 CI에서 돌기 시작하면 꽤 위험해집니다. 파일 이름이 예측 가능하고, 이미 같은 이름의 파일이 있
터미널에서 코드 파일을 빠르게 훑어보고 싶을 때 보통 cat file.py라고 입력하는데요. 출력은 잘 되지만 색도 없고 줄 번호도 없어서 조금만 길어져도 가독성이 뚝 떨어집니다. 그렇다고 매번 에디터를 켜기엔 번거롭고, less로 열면 페이징은 되지만 여전히 흑백이라 아쉽죠 😅 이런 답답함을 해결해 주는 도구가 바로 bat입니다. 이름에서 짐작하셨겠지만 cat을 본떠 만든 도구인데요. Rust로 작성됐고 ripgrep, fd처럼 "기존 유닉스 도구를 현대적으로 다시 만든" 계열에 속합니다. 문법 강조, Git 통합, 줄 번호,
이전 글에서 grep의 기본기를 살펴봤는데요. grep이 50년 넘게 살아남은 검증된 도구인 건 맞지만, 요즘 코드베이스를 다루다 보면 살짝 아쉬운 부분이 있습니다. node_modules를 빼먹으면 결과가 쏟아지고, .gitignore에 있는 파일까지 뒤지고, 바이너리 파일도 가리지 않죠 😅 ripgrep(rg)은 이런 불편함을 해결하기 위해 만들어진 검색 도구입니다. fd의 핵심 라이브러리를 만든 Andrew Gallant(BurntSushi)가 Rust로 개발했고, grep보다 훨씬 빠르면서도 개발자에게 친화적인 기본값을 가
터미널을 열 때마다 보이는 프롬프트가 밋밋하다고 느끼신 적 있으신가요? 기본 프롬프트는 현재 디렉터리 정도만 보여주다 보니 Git 브랜치를 확인하려면 git branch를 치고, Node.js 버전이 궁금하면 node -v를 입력해야 하죠. Starship은 이런 불편을 해결해주는 크로스 쉘 프롬프트입니다. Rust로 만들어져서 빠르고, Bash부터 Zsh, Fish, PowerShell까지 거의 모든 쉘에서 동작합니다. 이 글에서는 Starship을 설치하고 나만의 프롬프트를 설정하는 방법을 알아보겠습니다. Starship이란?
셸 스크립트를 들여다보면 거의 항상 첫 줄에 이런 코드가 있습니다. -euo pipefail이라는 옵션이 뭔지 모르고도 한참을 그냥 따라 쓰다가, 어느 날 set -a로 시작하는 .env 로딩 스크립트를 마주치면 또 한 번 당황하게 되는데요. 그러다 문득 "그러면 옵션 없이 그냥 set만 쓰면 어떻게 되지?" 하는 의문도 생깁니다. set은 셸에서 가장 자주 쓰이는 명령어인데도 정작 그 정체가 뭔지 정리된 자료가 많지 않습니다. 이번 글에서는 set이 어떤 명령어이고, 왜 옵션이 헷갈리게 보이는지, 자주 쓰는 패턴은 무엇인지 하나씩
터미널에서 작업하다 보면 길고 복잡한 명령어를 반복해서 입력하게 됩니다. docker compose --file docker-compose.production.yml up --detach 같은 명령어를 한 글자씩 정확히 치는 건 너무 비효율적이죠. 그래서 우리에게는 Tab 키가 있습니다. Tab 키로 명령어 이름과 파일 경로를 완성하는 건 누구나 알고 있죠. 그런데 쉘의 자동 완성은 그게 끝이 아닙니다. 서브 명령어, 옵션 플래그, 환경 변수, 심지어 Git 브랜치 이름까지 Tab 한 번으로 완성할 수 있는데요. 이 글에서는 Bas
쉘 스크립트를 읽다 보면 ${tag#v}나 ${file%%.*} 같은 독특한 문법을 마주치게 됩니다. 중괄호 안에 #이나 % 같은 기호가 붙어 있어서 처음 보면 꽤 당황스러운데요. 이게 바로 Bash의 **파라미터 확장(Parameter Expansion)**입니다. 파라미터 확장을 알면 sed, awk, cut 같은 외부 명령어 없이도 변수값을 자유자재로 다룰 수 있습니다. 문자열에서 특정 부분을 잘라내거나, 패턴을 치환하거나, 변수가 비어 있을 때 기본값을 넣어주거나... 이런 작업을 Bash 내장 기능만으로 처리할 수 있죠.
쉘 프로그래밍을 처음 하시는 분들이 스크립트를 읽으시다가 2>&1 같은 알 수 없는 문법을 보고 당황하시는 경우가 있습니다. 이것을 보통 리다이렉션(Redirection)이라고 하는데요. 어떤 명령의 입력이나 출력을 다른 곳으로 변경하기 위해서 사용됩니다. 이번 포스팅에서는 쉘 리다이렉션의 기본 사용법을 알아보고 다양한 예제를 통해 어떻게 실제 쉘 프로그래밍에 활용할 수 있는지 배워보겠습니다. 표준 스트림 쉘의 리다이렉션을 이해하려면 우선 macOS와 같은 유닉스 계열 운영체제의 세 가지 표준 스트림(Standard Stream)을
쉘을 처음 쓰시다 보면 누군가의 블로그나 README에서 이런 명령어를 자주 보게 됩니다. 가운데 들어 있는 | 기호가 도대체 무슨 역할을 하는지 처음에는 감이 잘 잡히지 않으실 텐데요. 이 기호를 파이프(pipe) 또는 파이프라인(pipeline)이라고 부릅니다. 이름 그대로 한 명령어의 출력을 다음 명령어의 입력으로 흘려보내는 관이라고 생각하시면 됩니다. 이번 포스팅에서는 리눅스 파이프의 기본 개념부터 실제로 자주 쓰는 조합 패턴까지 차근차근 살펴보겠습니다. 앞으로 파이프가 들어간 명령어를 보실 때 마음이 한결 편해지실 거예요.
터미널에서 작업하다 보면 반복적으로 입력하는 명령어가 참 많습니다. git status를 하루에 몇 번이나 치는지, cd ../../../ 같은 긴 경로 이동을 얼마나 자주 하는지 세어 보면 놀라울 정도인데요. 이런 반복 작업을 줄여주는 도구가 바로 Oh My Zsh입니다. Oh My Zsh는 Zsh 쉘의 설정을 관리해주는 오픈 소스 프레임워크입니다. 300개가 넘는 플러그인과 150개 이상의 테마를 제공하고, 커뮤니티가 활발하게 관리하고 있어서 전 세계 개발자가 가장 많이 쓰는 Zsh 프레임워크이기도 합니다. 이 글에서는 Oh M
프로젝트 디렉토리에서 특정 파일을 찾으려고 find . -name '*.ts'를 입력했는데 node_modules 안의 파일까지 끝도 없이 쏟아져 나온 경험, 한 번쯤 있지 않으신가요? 아니면 find 명령어의 옵션이 너무 많아서 매번 검색해보게 되는 분도 계실 거예요. 이럴 때 써볼 만한 도구가 바로 fd입니다. fd는 기존 find 명령어를 대체하기 위해 만들어진 커맨드라인 도구인데요. 직관적인 문법, .gitignore 자동 적용, 병렬 탐색을 통한 빠른 속도가 특징입니다. Rust로 작성되어 있고 ripgrep에서 사용하는
스크립트를 읽다 보면 sed 's/foo/bar/g' 같은 구문이 자주 등장합니다. 뜻은 대충 짐작이 가는데, 정확한 문법이나 다양한 활용법은 막상 모르는 경우가 많죠. CI/CD 파이프라인 설정 파일이나 배포 스크립트에도 단골로 등장하고, 코딩 에이전트가 터미널에서 파일을 수정할 때도 종종 꺼내드는 도구입니다. sed는 Stream Editor의 약자입니다. 파일이나 표준 입력으로 들어오는 텍스트를 줄 단위로 읽어서 변환한 뒤 출력하는 도구예요. 1974년 Bell Labs에서 태어났으니 grep, find와 마찬가지로 반세기가
코딩 에이전트를 쓰다 보면 터미널 로그에 grep이 심심찮게 지나가는 걸 보게 됩니다. 클로드 코드(Claude Code)나 Cursor 같은 도구가 코드베이스에서 함수 정의를 찾거나 특정 패턴을 추적할 때 내부적으로 grep을 돌리거든요. 예전부터 있던 명령어인데 AI 시대에 오히려 더 자주 보게 된 셈이죠. grep은 Globally search a Regular Expression and Print matching lines의 약자입니다. 이름 그대로 파일이나 입력 스트림에서 특정 패턴과 일치하는 줄을 찾아서 출력하는 도구예요
프로젝트가 커지면 파일을 찾는 것 자체가 일이 됩니다. "그 설정 파일이 어디 있었더라?", "테스트 파일이 몇 개나 되지?", "일주일 전에 수정한 파일이 뭐였지?" 같은 질문에 매번 파일 탐색기를 뒤지는 건 비효율적이죠. find는 디렉토리 트리를 탐색하면서 조건에 맞는 파일을 찾아주는 명령어입니다. 이름, 타입, 크기, 수정 시간 같은 다양한 조건을 조합할 수 있고, 찾은 파일에 대해 명령어를 바로 실행할 수도 있어요. 1970년대 Unix 시절부터 있었던 아주 오래된 도구인데, 그만큼 어디서든 쓸 수 있다는 게 강점입니다.
ps는 맥이나 리눅스 터미널에서 현재 실행 중인 프로세스를 확인하기 위해서 사용되는 쉘 커맨드입니다. 이번 포스팅에서는 많이 사용되는 옵션 위주로 ps 커맨드를 어떻게 사용하는지 알아보겠습니다. 무옵션 옵션없이 ps 커맨드를 실행하면 현재 사용자의 세션에서 실행 중인 프로세스를 출력해줍니다. 첫번째 칼럼에서 프로세스의 식별자인 프로세스 아이디를 확인할 수 있으며 마지막 칼럼에서 실행 중인 커맨드를 확인할 수 있습니다. -e 옵션 -e (everything) 옵션을 사용하면 현재 사용자 뿐만 아니라 다른 사용자들이 실행하고 있는 모든
맥이나 리눅스 터미널에서 가장 자주 사용하는 커맨드 중에 하나인 ls에 대해서 알아보도록 하겠습니다. ls는 파일이나 디펙토리 목록을 나열하기 위해서 사용하는 리눅스 커맨드입니다. 파일과 디렉터리 나열하기 단순히 현재 디렉터리 내의 어떤 파일과 디렉터리가 있는지를 보려면 터미널에 ls라고 입력합니다. 기본적으로는 알파벳 순으로 나옵니다. 확장자 여부로 파일과 디렉터리를 유추할 수 있지만 좀 더 명확하게 파일과 디렉터리가 구분되었으면 좋겠습니다. 파일과 디렉터리 구분하기 -F 옵션을 사용하면 디렉터리 이름 뒤에는 / 기호가 붙습니다.
CI 로그에서 exit code 137을 보고 "이게 뭐지?" 싶었던 적이 있는데요. Docker 컨테이너가 OOM으로 죽었을 때, Ctrl+C로 스크립트를 끊었을 때, 명령어 오타가 났을 때, 매번 다른 숫자가 떠도 잘 보지 않으면 의미를 잊기 쉽습니다. 사실 이 숫자들에는 나름의 규칙이 있고, 한 번만 정리해두면 다음에 로그를 볼 때 훨씬 빠르게 원인을 짚을 수 있습니다. 이번 글에서는 종료 코드가 만들어지는 원리부터 자주 마주치는 코드의 의미, 셸과 Node.js, Python에서 다루는 방법까지 정리해보겠습니다. 종료 코드란