Docker CLI 도구는 Docker 이미지(image)의 효과적인 관리를 위해서 다양한 커맨드(command)를 제공합니다. 이번 포스팅에서는 자주 쓰이는 커맨드 위주로 어떻게 Docker 이미지를 제어할 수 있는지 알아보도록 하겠습니다. 이미지 조회 docker images 커맨드는 이미지를 조회할 때 사용됩니다. 인자를 넘기지 않고 이 커맨드를 호출하면 전체 이미지 목록을 출력해줍니다. 특정 리파지토리(repository)에 해당하는 이미지만 필터링해서 보고 싶을 때는, 리파지토리를 인자로 넘겨주면 됩니다. 태그까지 인자로
터미널에서 작업하다 보면 반복적으로 입력하는 명령어가 참 많습니다. 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와 마찬가지로 반세기가
이전 포스팅에서 AWS CLI의 aws s3 커맨드를 사용하는 방법에 대해서 살펴보았습니다. 이번 포스팅에서는 aws s3api 커맨드를 통해서 Amazon S3를 좀 더 세밀하게 제어하는 방법에대해서 알아보도록 하겠습니다. S3 버킷의 Region 확인 종종 본인이 생성한 S3 버킷이 속한 Region이 어디인지 햇갈릴 때가 있습니다. 이럴 때는 aws s3api get-bucket-location 커맨드를 통해서 Region을 알아낼 수 있습니다. S3 버킷의 Life Cycle 설정 Amazon S3에 저장되어 있는 파일들의
Amazon S3는 AWS에서 제공하는 클라우드 스토리지 서비스입니다. AWS CLI를 이용하면 간편하게 S3 버킷을 제어하고 S3 오브젝트에 접근할 수 있으며, Unix의 파일 시스템 커맨드와 매우 유사해서 배우기도 쉽습니다. 이 번 포스팅에서는 자주 사용되는 AWS CLI의 Amazon S3 관련 커맨드을 살펴보도록 하겠습니다. 버킷 생성하기 Amazon S3에 데이터를 저장하려면 먼저 버킷(Bucket)을 생성해야 합니다. 버킷은 Amazon S3에서 파일 시스템의 최상위 디렉터리나 드라이브 정도의 역할을 하는 저장 단위 개념
DynamoDB는 AWS에서 제공하는 관리형 NoSQL 데이터베이스 서비스입니다. AWS CLI를 이용하면 간편하게 DynamoDB 테이블을 제어하고 테이터에 접근할 수 있습니다. 이 번 포스팅에서는 자주 사용되는 AWS CLI의 DynamoDB 관련 커맨드을 살펴보도록 하겠습니다. 테이블 생성하기 아직 본인 AWS 계정에 DynamoDB 테이블이 없으신 분들은 일단 테이블부터 생성하셔야 합니다. 예제로 과일 정보를 저장하기 위해서 Fruits 테이블을 생성해보겠습니다. aws dynamodb create-table 커맨드를 사용하
코딩 에이전트를 쓰다 보면 터미널 로그에 grep이 심심찮게 지나가는 걸 보게 됩니다. 클로드 코드(Claude Code)나 Cursor 같은 도구가 코드베이스에서 함수 정의를 찾거나 특정 패턴을 추적할 때 내부적으로 grep을 돌리거든요. 예전부터 있던 명령어인데 AI 시대에 오히려 더 자주 보게 된 셈이죠. grep은 Globally search a Regular Expression and Print matching lines의 약자입니다. 이름 그대로 파일이나 입력 스트림에서 특정 패턴과 일치하는 줄을 찾아서 출력하는 도구예요
AWS(Amazon Web Services)에 접근하기 위해서는 필수적으로 인증 절차가 필요합니다. 웹 브라우저에서 AWS Management Console을 통해 접근하든지, 터미널에서 AWS CLI를 사용하여 접근하든지, 애플리케이션이 AWS SDK를 통해 접근하든지 절대 예외는 없지요. 이번 포스팅에서는 AWS의 인증 정보(Access Key ID, Secret Access Key)에 대한 기본 개념을 잡고, AWS CLI를 통해서 간단하게 AWS 인증 정보를 설정하고 프로파일로 관리하는 방법에 대해서 함께 실습을 해보겠습니다
ES6(ES2105) 이상의 최신 자바스크립트 문법으로 작성된 코드가 노드JS(NodeJS)에서 실행이 안 되는 경우가 종종있습니다. 이럴 경우 어쩔 수 없이 예전 자바스크립트 문법으로 코드를 재작성하기도 하는데요. 이번 포스팅에서는 자바스크립트 Transpiler인 Babel을 이용하여 이 문제를 해결해보겠습니다. NodeJS에서 ES6 코드 실행 오류 먼저 간단한 예제 프로젝트를 하나를 만들겠습니다. babel-test라는 디렉터리에 NPM 패키지를 생성합니다. 이제 다음과 같이 매우 간단한 자바스크립트 코드를 작성해보겠습니다.
프로젝트가 커지면 파일을 찾는 것 자체가 일이 됩니다. "그 설정 파일이 어디 있었더라?", "테스트 파일이 몇 개나 되지?", "일주일 전에 수정한 파일이 뭐였지?" 같은 질문에 매번 파일 탐색기를 뒤지는 건 비효율적이죠. find는 디렉토리 트리를 탐색하면서 조건에 맞는 파일을 찾아주는 명령어입니다. 이름, 타입, 크기, 수정 시간 같은 다양한 조건을 조합할 수 있고, 찾은 파일에 대해 명령어를 바로 실행할 수도 있어요. 1970년대 Unix 시절부터 있었던 아주 오래된 도구인데, 그만큼 어디서든 쓸 수 있다는 게 강점입니다.
백엔드 개발을 하든 프론트엔드 개발을 하든 자바스크립트 프로젝트에서 npm(Node Package Manager)을 사용하는 것은 거의 필수적인데요. 이번 포스팅에서는 실무에서 자바스크립트 프로젝트를 하면서 자주 사용하게 되는 npm 커맨드들을 정리해보았습니다. 프로젝트 생성 npm init 커맨드를 사용하면 현재 디렉터리에 npm 기반으로 프로젝트를 생성할 수 있습니다. 커맨드를 실행하면 패키지 이름, 버전, 설명 등등을 입력하게 됩니다. 프로젝트를 생성할 때 이러한 정보들을 일일이 입력하는 게 귀찮게 느껴질 수 있습니다. 이 때
ps는 맥이나 리눅스 터미널에서 현재 실행 중인 프로세스를 확인하기 위해서 사용되는 쉘 커맨드입니다. 이번 포스팅에서는 많이 사용되는 옵션 위주로 ps 커맨드를 어떻게 사용하는지 알아보겠습니다. 무옵션 옵션없이 ps 커맨드를 실행하면 현재 사용자의 세션에서 실행 중인 프로세스를 출력해줍니다. 첫번째 칼럼에서 프로세스의 식별자인 프로세스 아이디를 확인할 수 있으며 마지막 칼럼에서 실행 중인 커맨드를 확인할 수 있습니다. -e 옵션 -e (everything) 옵션을 사용하면 현재 사용자 뿐만 아니라 다른 사용자들이 실행하고 있는 모든
맥이나 리눅스 터미널에서 가장 자주 사용하는 커맨드 중에 하나인 ls에 대해서 알아보도록 하겠습니다. ls는 파일이나 디펙토리 목록을 나열하기 위해서 사용하는 리눅스 커맨드입니다. 파일과 디렉터리 나열하기 단순히 현재 디렉터리 내의 어떤 파일과 디렉터리가 있는지를 보려면 터미널에 ls라고 입력합니다. 기본적으로는 알파벳 순으로 나옵니다. 확장자 여부로 파일과 디렉터리를 유추할 수 있지만 좀 더 명확하게 파일과 디렉터리가 구분되었으면 좋겠습니다. 파일과 디렉터리 구분하기 -F 옵션을 사용하면 디렉터리 이름 뒤에는 / 기호가 붙습니다.
개발하다 보면 API 키, 데이터베이스 비밀번호, 토큰 같은 민감한 정보를 다룰 일이 많은데요. 이런 값들을 .env 파일이나 설정 파일에 평문으로 저장해두면 실수로 Git에 커밋하거나 다른 사람에게 노출될 위험이 있습니다. macOS에는 이런 민감한 정보를 안전하게 보관할 수 있는 **키체인(Keychain)**이라는 시스템이 내장되어 있는데요. 보통은 키체인 접근(Keychain Access) 앱을 통해 GUI로 사용하지만, 터미널에서 security 명령어를 사용하면 키체인을 훨씬 효율적으로 다룰 수 있습니다. 이번 글에서는
터미널 환경을 설정하다 보면 .bashrc에 넣으라는 곳도 있고, .bash_profile에 넣으라는 곳도 있고, .zshrc에 넣으라는 곳도 있습니다. 비슷비슷한 이름의 파일이 왜 이렇게 많은 건지, 도대체 어디에 뭘 넣어야 하는 건지 헷갈리죠. 사실 이 파일들은 각각 로드되는 시점이 다릅니다. 그래서 PATH 환경 변수를 설정하든, Oh My Zsh 플러그인을 추가하든, Starship 프롬프트를 초기화하든 적절한 파일에 넣어야 제대로 동작합니다. 이 글에서는 Bash와 Zsh의 설정 파일이 각각 언제 로드되는지, 어떤 파일에
터미널에 git이라고 치면 Git이 실행되고, python이라고 치면 Python이 실행됩니다. 그런데 이 프로그램들이 디스크 어딘가에 파일로 존재할 텐데, 운영체제는 어떻게 그걸 찾아서 실행하는 걸까요? 🤔 이걸 가능하게 해주는 게 바로 PATH 환경 변수입니다. 개발 환경을 셋업하다 보면 "PATH에 추가하세요"라는 안내를 자주 보게 되는데, 정확히 뭘 어디에 추가하라는 건지 모호하게 느껴질 때가 있죠. Homebrew를 설치할 때도, Mise를 설정할 때도, pyenv나 nvm을 쓸 때도 PATH 설정이 빠지지 않습니다. 이