git add는 작업 디렉토리(working directory) 상의 변경 내용을 스테이징 영역(staging area)에 추가하기 위해서 사용하는 Git 명령어입니다. git commit vs. git add git add 명령어는 다음 변경(commit)을 기록할 때까지 변경분을 모아놓기 위해서 사용합니다. 따라서, git commit 명령어를 통해 명시적으로 기록을 남기기 전까지는 아무리 git add 명령어를 많이 실행해도 Git 저장소의 변경 이력에는 어떤 영향도 주지 않습니다. git status git add 명령어를
새로운 프로젝트에 투입되거나 오픈소스에 기여하려면 먼저 원격 저장소의 코드를 내 컴퓨터에 가져와야 합니다. 이때 사용하는 명령어가 바로 git clone인데요. 원격 저장소의 모든 파일과 변경 이력을 통째로 복제해서 로컬에 동일한 저장소를 만들어줍니다. git init vs. git clone git init은 빈 Git 저장소를 새로 생성하는 명령어이고, git clone은 이미 존재하는 원격 저장소를 복사해오는 명령어입니다. 새 프로젝트를 처음부터 시작할 때는 git init을, 이미 존재하는 프로젝트에 참여할 때는 git cl
이번 포스팅에서는 Git 설정을 위해 사용하는 git config 명령어에 대해서 알아보겠습니다. 설정 범위와 설정 파일 git config 명령어에 대해서 배우기 전에 먼저 간단하게 설정 범위에 대해서 짚고 넘어가겠습니다. Git은 지역(local), 전역(global), 시스템(system) 이렇게 크게 3가지 범위로 설정이 가능한데요. 지역 범위로 설정하면 특정 저장소(repository)로 한정되고, 전역 범위는 현재 사용자(user)의 모든 저장소를 포함시킵니다. 자주 사용되지는 않지만 시스템 범위로 설정하면 해당 컴퓨터의
자바스크립트 프로젝트의 규모가 커지면 디렉토리 구조도 복잡해지기 마련입니다. 혹시 다음과 같은 코드 때문에 해당 모듈을 찾으려고 상위 디렉토리를 하나씩 짚어가며 올라가다가 스트레스 받으신 적이 있으신가요? 😝 상대 경로 Node.js에서 내부 모듈을 불러올 때 가장 흔히 사용되는 방법은 상대 경로를 사용하는 것입니다. 위에서 보시는 것 처럼 상대 경로를 사용해서 모듈을 불러오면 모듈이 어느 경로에 위치하는지 파악하기가 난해해지는 경우가 생깁니다. 뿐만 아니라, 이 자바스크립트 파일을 다른 디렉토리로 옮기려면 상대 경로를 그에 따라
ES6(ES2105) 이상의 최신 자바스크립트 문법으로 작성된 코드가 노드JS(Node.js)에서 실행이 안 되서 애를 먹는 경우가 종종 있는데요. 이번 포스팅에서는 자바스크립트 트랜스파일러(Transpiler)인 Babel을 이용하여 이 문제를 깔끔하게 해결해보겠습니다. 개발자들이 실행 환경에 구애받지 않고 항상 최신 문법의 자바스크립트로 코딩할 수 있도록 도와주는 유용한 도구인 바벨(Babel)에 대해서는 별도 포스팅을 참고바랍니다. Node.js에서 ES6 코드 실행 오류 먼저 간단한 예제 프로젝트를 하나를 만들겠습니다. js
Docker Compose는 여러 개의 컨테이너(container)로 구성된 애플리케이션을 관리하기 위한 간단한 오케스트레이션(Orchestration) 도구입니다. 이번 포스팅에서는 Compose 애플리케이션을 터미널에서 제어하기 위해 사용되는 Docker Compose 커맨드에서 대해서 알아보겠습니다. -f 옵션 Docker Compose는 기본적으로 커맨드가 실행하는 디렉토리에 있는 docker-compose.yml 또는 docker-compose.yaml를 설정 파일로 사용합니다. 다른 이름이나 경로의 파일을 Docker C
Docker 컨테이너(container)에 쓰여진 데이터는 기본적으로 컨테이너가 삭제될 때 함께 사라지게 됩니다. Docker에서 돌아가는 많은 애플리케이션이 컨테이너의 생명 주기와 관계없이 데이터를 영속적으로 저장을 해야하는데요. 뿐만 아니라 많은 경우 여러 개의 Docker 컨테이너가 하나의 저장 공간을 공유해서 데이터를 읽거나 써야합니다. 이렇게 Docker 컨테이너의 생명 주기와 관계없이 데이터를 영속적으로 저장할 수 있도록 Docker는 두가지 옵션을 제공하는데요. 첫번째는 Docker 볼륨(volume), 두번째는 바인드
Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능합니다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해집니다. 이번 포스팅에서는 컨테이너 간 네트워킹이 가능하도록 도와주는 Docker 네트워크에 대해서 알아보도록 하겠습니다. 네트워크 조회 Docker 네트워크의 기본은 내 컴퓨터에서 어떤 네트워크가 생성되어 있는지를 아는 것일 겁니다. docker network ls 커맨드를 사용하면 현재 생성되어 있는 D
Docker CLI 도구는 Docker 컨테이너(container)의 효과적인 관리를 위해서 다양한 커맨드(command)를 제공합니다. 이번 포스팅에서는 자주 쓰이는 커맨드 위주로 어떻게 Docker 컨테이너를 효과적으로 제어할 수 있는지 알아보도록 하겠습니다. 컨테이너 조회 가장 먼저 살펴볼 docker ps 커맨드는 Docker 컨테이너를 조회를 위해 사용되며 기본적으로 실행 중인 컨테이너 목록이 출력됩니다. -a 옵션을 사용하면 현재 중지되어 있는 컨테이너까지 함께 출력됩니다. -s 옵션을 사용하면 각 컨테이너의 디스크 사용
Docker를 사용하면서 가장 자주 접하는 커맨드는 단연 컨테이너를 실행하기 위해서 쓰이는 docker run일 것입니다. docker run 커맨드는 상당히 여러 가지 옵션을 통해 다양한 방식으로 컨테이너를 실행할 수 있도록 해줍니다. 이번 포스팅에서는 이중에서 자주 쓰이는 옵션 위주로 dockr run 커맨드를 어떻게 사용하는지 알아보겠습니다. 기본 포맷 docker run 커맨드의 기본 포맷은 다음과 같습니다. 여기서 이미지 식별자는 필수이며 이미지 ID나 리파지토리(repository):태그(tag)를 사용할 수 있습니다.
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 패키지를 생성합니다. 이제 다음과 같이 매우 간단한 자바스크립트 코드를 작성해보겠습니다.