이전 포스팅에서 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는 파일이나 디펙토리 목록을 나열하기 위해서 사용하는 리눅스 커맨드입니다. mkdir 명령어로 디렉터리를 만들고 나서 제대로 만들어졌는지 확인할 때도 결국 ls를 치게 되죠. 파일과 디렉터리 나열하기 단순히 현재 디렉터리 내의 어떤 파일과 디렉터리가 있는지를 보려면 터미널에 ls라고 입력합니다. 기본적으로는 알파벳 순으로 나옵니다. 확장자 여부로 파일과 디렉터리를 유추할 수 있지만 좀 더 명확하게 파일과 디렉터리가 구분되었으면
개발하다 보면 API 키, 데이터베이스 비밀번호, 토큰 같은 민감한 정보를 다룰 일이 많은데요. 이런 값들을 .env 파일이나 설정 파일에 평문으로 저장해두면 실수로 Git에 커밋하거나 다른 사람에게 노출될 위험이 있습니다. macOS에는 이런 민감한 정보를 안전하게 보관할 수 있는 **키체인(Keychain)**이라는 시스템이 내장되어 있는데요. 보통은 키체인 접근(Keychain Access) 앱을 통해 GUI로 사용하지만, 터미널에서 security 명령어를 사용하면 키체인을 훨씬 효율적으로 다룰 수 있습니다. 이번 글에서는
CI 로그에서 exit code 137을 보고 "이게 뭐지?" 싶었던 적이 있는데요. Docker 컨테이너가 OOM으로 죽었을 때, Ctrl+C로 스크립트를 끊었을 때, 명령어 오타가 났을 때, 매번 다른 숫자가 떠도 잘 보지 않으면 의미를 잊기 쉽습니다. 사실 이 숫자들에는 나름의 규칙이 있고, 한 번만 정리해두면 다음에 로그를 볼 때 훨씬 빠르게 원인을 짚을 수 있습니다. 이번 글에서는 종료 코드가 만들어지는 원리부터 자주 마주치는 코드의 의미, 셸과 Node.js, Python에서 다루는 방법까지 정리해보겠습니다. 종료 코드란
터미널을 열고 새 프로젝트를 시작할 때 가장 먼저 치는 명령어가 뭘까요? 아마 mkdir일 겁니다. 이름 그대로 make directory, 뒤에 이름만 붙이면 끝이라 딱히 배울 게 없어 보이는데요. 그런데 막상 쓰다 보면 mkdir: project/src: No such file or directory 같은 메시지에 한 번쯤 막힙니다. 만들라고 시켰는데 없다니, 무슨 소리인가 싶죠. 🤔 셸 스크립트에 mkdir을 넣었다가 두 번째 실행부터 에러가 터지면서 스크립트가 죽는 경험도 흔합니다. 이 글에서는 mkdir의 기본 사용법에서
터미널 환경을 설정하다 보면 .bashrc에 넣으라는 곳도 있고, .bash_profile에 넣으라는 곳도 있고, .zshrc에 넣으라는 곳도 있습니다. 비슷비슷한 이름의 파일이 왜 이렇게 많은 건지, 도대체 어디에 뭘 넣어야 하는 건지 헷갈리죠. 사실 이 파일들은 각각 로드되는 시점이 다릅니다. 그래서 PATH 환경 변수를 설정하든, Oh My Zsh 플러그인을 추가하든, Starship 프롬프트를 초기화하든 적절한 파일에 넣어야 제대로 동작합니다. 이 글에서는 Bash와 Zsh의 설정 파일이 각각 언제 로드되는지, 어떤 파일에
터미널에 git이라고 치면 Git이 실행되고, python이라고 치면 Python이 실행됩니다. 그런데 이 프로그램들이 디스크 어딘가에 파일로 존재할 텐데, 운영체제는 어떻게 그걸 찾아서 실행하는 걸까요? 🤔 이걸 가능하게 해주는 게 바로 PATH 환경 변수입니다. 개발 환경을 셋업하다 보면 "PATH에 추가하세요"라는 안내를 자주 보게 되는데, 정확히 뭘 어디에 추가하라는 건지 모호하게 느껴질 때가 있죠. Homebrew를 설치할 때도, Mise를 설정할 때도, pyenv나 nvm을 쓸 때도 PATH 설정이 빠지지 않습니다. 이