Command line crash Course

김동현·2026년 2월 23일
MDN

mdn 학습 번역 - HTML

목록 보기
1/31

명령줄(커맨드 라인) 속성 코스

터미널의 세계로 오신 것을 환영합니다

터미널은 텍스트 기반의 프로그램들을 실행하기 위한 텍스트 전용 인터페이스예요. 웹 개발을 위한 도구를 하나라도 사용해 보신다면, 터미널 창을 열고 도구를 다루기 위해 명령어들을 입력해야 할 확률이 거의 100%랍니다. (이런 도구들을 보통 CLI 도구 — Command Line Interface 도구라고 부르는 걸 자주 보시게 될 거예요.)

명령줄에 명령어를 입력하는 방식으로 사용할 수 있는 도구는 정말 많습니다. 많은 도구들이 컴퓨터 시스템에 기본으로 설치되어 있고, 그 외에도 패키지 레지스트리(Package registries)를 통해 수많은 도구들을 추가로 설치할 수 있어요. 패키지 레지스트리는 쉽게 말해 앱스토어 같은 건데, 주로 명령줄 기반 도구나 소프트웨어를 위한 곳이죠. 나중에 이 챕터에서 몇 가지 도구를 직접 설치해 볼 거고, 패키지 레지스트리에 대해서는 다음 챕터에서 더 자세히 배울 거예요.

명령줄이 받는 가장 큰 비판 중 하나는 사용자 경험(UX)이 굉장히 떨어진다는 점이에요. 처음 명령줄 화면을 보면 좀 막막할 수 있어요. 빈 화면에 커서만 껌벅이고, 도대체 뭘 해야 할지 알려주는 힌트가 거의 없거든요.

겉보기엔 별로 환영해 주는 느낌이 아니지만, 사실 이 안에서 할 수 있는 일이 무궁무진해요. 제가 장담하는데요, 약간의 가이드와 연습만 있다면 사용하는 게 훨씬 쉬워질 겁니다! 겉으론 불친절해 보이는 이 환경에서 여러분이 첫걸음을 잘 뗄 수 있도록 이 챕터가 준비된 거랍니다.

터미널은 어디서 시작되었을까요?

터미널은 대략 1950년대에서 60년대 사이에 등장했어요. 초기 모습은 우리가 지금 사용하는 것과는 전혀 달랐죠 (지금 형태가 된 것에 감사해야 할 정도예요!). 위키백과의 컴퓨터 단말기(Computer Terminal) 항목을 보시면 그 역사를 조금 더 읽어보실 수 있어요.

그 이후로 터미널은 데스크톱 컴퓨터부터 클라우드 깊숙한 곳의 서버, 라즈베리 파이 제로 같은 초소형 컴퓨터, 심지어 모바일 폰에 이르기까지 모든 운영체제에서 절대 빠지지 않는 핵심 기능으로 자리 잡았습니다. 터미널은 컴퓨터의 바탕이 되는 파일 시스템과 로우레벨 기능들에 직접 접근할 수 있게 해 주거든요. 그래서 뭘 해야 할지 정확히 알고만 있다면, 복잡한 작업들을 순식간에 처리할 수 있는 엄청난 유용함을 자랑하죠.

또한 자동화에도 굉장히 유용해요. 예를 들어, 수백 개의 파일 이름을 "ch01-xxxx.png"에서 "ch02-xxxx.png"로 한 번에 바꾸는 명령어를 작성할 수도 있죠. 만약 윈도우 탐색기나 맥 파인더 같은 GUI 앱에서 이걸 일일이 바꾼다면 시간이 엄청 오래 걸리겠죠?

어쨌든, 터미널은 앞으로도 우리 곁을 떠나지 않을 거예요.

👨‍🏫 강사의 팁: 나중에 면접관들이 종종 "이런 대량의 파일 수정이나 자동화 작업을 어떻게 처리하시겠어요?" 하고 물어볼 때가 있어요. 이때 쉘 스크립트나 터미널 명령어를 언급하며 해결책을 제시하면 꽤 좋은 인상을 줄 수 있습니다. 기술 면접 준비를 하신다고 하니, 이런 기본적인 파일 제어 명령어는 머릿속에 잘 정리해 두시면 든든한 무기가 될 거예요.

터미널은 어떻게 생겼나요?

아래 이미지들에서 터미널을 실행할 수 있는 다양한 프로그램들의 모습을 확인해 보세요.

다음 이미지들은 Windows에서 사용할 수 있는 명령 프롬프트들을 보여줍니다. 시작 메뉴에서 프로그램 이름을 쳐서 실행할 수 있는 "cmd" 프로그램부터 "powershell"까지 다양한 옵션이 있어요.

기본 윈도우 cmd 라인 창과 윈도우 파워쉘 창

그리고 아래는 macOS의 기본 터미널 애플리케이션 모습이에요.

기본 macOS 터미널

터미널에는 어떻게 접속하나요?

오늘날 많은 개발자들이 유닉스(Unix) 기반 도구들을 사용하고 있어요 (예: 터미널이나 터미널을 통해 접근할 수 있는 도구들). 현재 웹에 존재하는 많은 튜토리얼과 도구들이 유닉스 기반 시스템을 지원하고 (때로는 아쉽게도 유닉스 환경을 당연하게 전제하기도) 있지만 걱정하지 마세요. 대부분의 시스템에서 사용할 수 있거든요. 이 섹션에서는 여러분이 선택한 운영체제에서 터미널에 접근하는 방법을 살펴볼게요.

Linux/Unix

위에서 힌트를 드렸듯이, Linux/Unix 시스템은 터미널이 기본으로 제공되며 애플리케이션 목록에서 쉽게 찾을 수 있어요.

macOS

macOS는 그래픽 사용자 인터페이스(GUI) 밑에 다윈(Darwin)이라는 시스템이 깔려 있어요. 다윈은 유닉스 계열 시스템이라서 터미널과 로우레벨 도구들에 대한 접근을 제공하죠. macOS의 다윈은 유닉스와 거의 호환되기 때문에, 이 문서를 따라오시는 데 전혀 문제가 없을 겁니다.

macOS에서 터미널은 응용 프로그램/유틸리티/터미널에 있어요.

Windows

다른 프로그래밍 도구들과 마찬가지로, 과거 Windows에서 터미널(또는 명령줄)을 사용하는 건 다른 운영체제만큼 간단하거나 쉽지 않았어요. 하지만 상황이 점점 좋아지고 있죠.

Windows에는 오래전부터 cmd("명령 프롬프트")라는 터미널 비슷한 자체 프로그램이 있었지만, 유닉스 명령어들과 호환되지 않고 예전 윈도우 DOS 프롬프트와 같은 역할을 할 뿐이에요.

Windows에서 더 나은 터미널 경험을 제공하는 프로그램으로는 PowerShell(설치 파일 찾기)이나 Git Bash(Git for Windows 도구 모음에 포함되어 제공됨) 등이 있습니다.

하지만 현재 Windows 환경에서 가장 추천하는 선택지는 WSL(Windows Subsystem for Linux)이에요. 가상 머신(VM)을 띄우지 않고도 Windows 10/11 안에서 Linux 운영체제를 직접 실행할 수 있게 해주는 호환성 계층으로, Windows에서 "진짜 터미널"을 구동할 수 있게 해 줍니다.

Windows 스토어에서 무료로 바로 설치할 수 있어요. 필요한 모든 문서는 Windows Subsystem for Linux 공식 문서에서 확인하실 수 있습니다.

Windows Subsystem for Linux 문서 스크린샷

Windows에서 어떤 옵션을 고를지 고민이시라면, WSL을 설치해서 사용해 보시길 강력히 추천해요! 기본 명령 프롬프트(cmd)를 계속 써도 많은 도구들이 그럭저럭 돌아가긴 하겠지만, 유닉스 도구들과 완벽하게 호환되는 환경을 갖추면 모든 작업이 훨씬 수월해질 거예요.

여담: 명령줄(Command line)과 터미널(Terminal)의 차이는 뭔가요?

일반적으로 이 두 단어는 서로 섞여서 쓰입니다. 기술적으로 따지자면, 터미널은 쉘(shell)을 시작하고 연결해 주는 '소프트웨어'를 말해요. 쉘은 여러분의 세션과 세션 환경(프롬프트의 모양이나 단축키 등을 커스터마이징 하는 곳)이고요. 명령줄은 문맥 그대로 여러분이 명령어를 입력하고 커서가 깜빡거리는 그 '줄(line)' 자체를 의미합니다.

꼭 터미널을 써야 하나요?

명령줄에서 사용할 수 있는 엄청나게 많은 도구들이 있지만, Visual Studio Code 같은 도구를 사용하신다면 굳이 터미널을 직접 열지 않고도 터미널 명령어를 대신 실행해 주는 확장 프로그램(Extensions)이 무수히 많아요. 하지만 여러분이 하고 싶은 모든 작업에 딱 맞는 코드 에디터 확장을 매번 찾을 수는 없을 거예요. 결국엔 터미널을 직접 다루는 경험이 꼭 필요해진답니다.

👨‍🏫 강사의 팁: 요즘 React.js나 Next.js로 개발하실 때 VS Code 안에 내장된 터미널을 열어서 npm start나 npm run dev 치면서 작업하시죠? 그것도 터미널을 사용하는 훌륭한 방법이에요!

기본 내장 터미널 명령어

말이 너무 길었네요! 이제 터미널 명령어들을 직접 살펴봅시다. 기본적으로 명령줄이 할 수 있는 몇 가지 기능들과 각 기능에 해당하는 도구 이름들은 다음과 같아요:

  • 컴퓨터의 파일 시스템을 돌아다니고 파일/폴더를 생성, 복사, 이름 변경, 삭제하는 기본 작업:
    • 디렉터리(폴더) 구조 안에서 이동하기: cd
    • 디렉터리 만들기: mkdir
    • 파일 만들기(그리고 메타데이터 수정하기): touch
    • 파일이나 디렉터리 복사하기: cp
    • 파일이나 디렉터리 이동(이름 변경)하기: mv
    • 파일이나 디렉터리 삭제하기: rm
  • 특정 URL에 있는 파일 다운로드하기: curl
  • 큰 텍스트 뭉치 안에서 텍스트 조각 검색하기: grep
  • 파일 내용을 페이지 단위로 보기: less, cat
  • 텍스트 스트림 조작 및 변환하기 (예를 들어 HTML 파일에 있는 모든 <div>를 <article>로 한 번에 바꾸기): awk, tr, sed

참고: 웹상에는 명령줄에 대해 훨씬 더 깊이 다루는 훌륭한 튜토리얼들이 많아요. 이 문서는 아주 가벼운 소개일 뿐입니다!

그럼 앞으로 넘어가서 명령줄에서 이런 도구들을 몇 개 직접 사용해 볼까요? 더 진행하기 전에 터미널 프로그램을 켜주세요!

명령줄에서 길 찾기 (네비게이션)

명령줄을 켜면 무언가 "작업을 하기 위해" 필연적으로 특정 디렉터리로 이동해야 합니다. 모든 운영체제는(기본 설정이라면) 터미널 프로그램을 여러분의 홈(Home) 디렉터리에서 시작하도록 띄워줄 거예요. 거기서부터 여러분이 원하는 다른 위치로 이동하셔야 합니다.

참고: "디렉터리(Directory)"는 우리가 이전 문서에서 "폴더(Folder)"라고 불렀던 것의 기술적인 용어예요. 사용자 인터페이스(UI) 상에서 파일 구조를 볼 때는, 아이콘 모양도 실제 서류철(폴더)처럼 생겼으니 "폴더"라는 말이 더 직관적이죠. 하지만 특히 터미널에서 명령어로 파일을 조작할 때는 "디렉터리"라는 용어를 훨씬 더 자주 듣게 될 거예요. 미묘한 뉘앙스 차이는 있지만 기본적으로 두 단어는 같은 뜻이랍니다.

cd 명령어는 Change Directory(디렉터리 변경)를 뜻해요. 기술적으로 cd는 외부 프로그램이 아니라 운영체제 자체에 '내장(built-in)'된 기능입니다. 기본적으로 제공된다는 뜻이기도 하고, 여러분이 실수로 지워버릴 위험도 없다는 뜻이죠 (정말 다행이죠!). 명령어가 내장 기능인지 아닌지 너무 깊게 고민하실 필요는 없지만, 이런 내장 명령어들은 모든 유닉스 기반 시스템에 공통으로 존재한다는 점만 알아두세요.

  1. 디렉터리를 이동하려면 터미널에 cd를 입력하고 띄어쓰기 후 이동하고 싶은 디렉터리 이름을 적으세요. 홈 디렉터리 안에 바탕화면이 있다고 가정하면, cd Desktop이라고 입력할 수 있죠 (아래 스크린샷 참고).

    여러 윈도우 터미널에서 cd Desktop 명령어를 실행한 결과 - 터미널 위치가 바탕화면으로 이동함

  2. 시스템의 터미널에 다음을 직접 입력해 보세요:

    cd Desktop

  3. 이전 상위 디렉터리로 다시 올라가고 싶다면 점 두 개(..)를 사용하면 됩니다. 지금 입력해 보세요:

    cd ..

참고: 아주아주 유용한 터미널 단축키 팁! Tab 키를 누르면 이름의 일부만 쳐도 나머지 이름을 자동으로 완성해 줍니다. 전체 이름을 다 타이핑할 필요가 없어요. 예를 들어, 위 명령어들을 쳐본 뒤 cd D까지만 치고 Tab 키를 눌러보세요. 현재 디렉터리 안에 Desktop이 있다면 자동으로 그 이름을 완성해 줄 거예요. 앞으로 명령어를 입력하실 때 이 팁을 꼭 기억하세요!

이동하려는 디렉터리가 깊숙한 곳에 중첩되어 있다면, 그곳까지 가는 경로(path)를 알아야 해요. 파일 시스템 구조에 익숙해질수록 점점 쉬워지겠지만, 경로가 확실하지 않다면 ls 명령어(아래에서 배울 거예요)를 조합해서 확인하거나 탐색기/파인더 창을 클릭해 보며 현재 내가 있는 곳을 기준으로 해당 디렉터리가 어디쯤 있는지 파악할 수 있어요.

예를 들어 바탕화면(Desktop)에 있는 project 디렉터리 안의 src 디렉터리로 이동하고 싶다고 해볼게요. 홈 디렉터리에서 출발한다면 이렇게 세 번 명령어를 칠 수도 있습니다.

cd Desktop
cd project
cd src

👨‍🏫 강사의 팁: 프론트엔드 개발하실 때 src 디렉터리 정말 많이 보시죠? React나 Next.js 프로젝트를 생성하면 코드가 거의 다 저 안에 들어가잖아요. 터미널로 그곳까지 찾아가는 건 앞으로의 일상입니다.

하지만 이렇게 치는 건 시간 낭비죠! 대신, CSS나 HTML, JavaScript 코드 안에서 이미지 경로를 지정할 때처럼 슬래시(/)로 경로의 항목들을 구분해서 한 줄의 명령어로 이동할 수 있어요:

cd Desktop/project/src

경로 맨 앞에 슬래시를 붙이면 절대 경로가 됩니다 (예: /Users/your-user-name/Desktop). 위 예제처럼 맨 앞의 슬래시를 생략하면 현재 작업 중인 디렉터리를 기준으로 하는 상대 경로가 되고요. 이건 웹 브라우저에서 보는 URL 작동 방식과 완전히 똑같아요. 맨 앞의 슬래시는 "웹사이트의 최상위 루트"를 의미하고, 슬래시가 없으면 "현재 내 페이지를 기준으로 한 상대적인 URL"을 의미하죠.

참고: 윈도우에서는 슬래시(/) 대신 백슬래시(\)를 사용해요 (예: cd Desktop\project\src). 모양이 참 이상해 보일 수 있는데, 이유가 궁금하시다면 Microsoft의 수석 엔지니어가 설명하는 이 YouTube 영상을 한번 시청해 보세요!

디렉터리 내용물 목록 보기

또 다른 유닉스 내장 명령어는 ls (list의 줄임말)예요. 현재 있는 디렉터리 안의 내용물을 목록으로 쫙 보여주죠. 만약 윈도우의 기본 명령 프롬프트(cmd)를 쓰고 계신다면 이 명령어는 작동하지 않습니다. 윈도우 cmd에서는 dir을 사용하셔야 해요.

자, 터미널에서 다음 명령어를 실행해 보세요:

ls

현재 작업 디렉터리에 있는 파일과 폴더 목록이 나옵니다. 그런데 정보가 너무 빈약하죠? 항목의 이름만 딸랑 보여주고, 이게 파일인지 디렉터리인지, 다른 정보는 전혀 나오지 않아요. 다행히 명령어 사용법을 아주 살짝만 바꾸면 훨씬 더 많은 정보를 볼 수 있답니다.

명령어 옵션 소개

대부분의 터미널 명령어에는 '옵션(Options)'이 존재합니다. 명령어 이름 뒤에 붙여서 해당 명령어의 동작 방식을 살짝 바꿔주는 수식어 같은 역할을 하죠. 주로 명령어 이름 뒤에 띄어쓰기를 한 번 하고, 대시(-)를 붙인 다음 한 개 이상의 알파벳 문자를 적는 형태를 띱니다.

예를 들어, 다음 명령어를 쳐보고 어떤 결과가 나오는지 확인해 보세요:

ls -l

ls의 경우 -l (대시 엘) 옵션을 주면 한 줄에 하나의 파일이나 디렉터리가 나오고 훨씬 자세한 정보가 함께 표시됩니다. 디렉터리인지 확인하려면 출력된 줄의 가장 왼쪽 끝에 글자 "d"가 있는지 찾아보세요. "d"가 적혀 있는 것들이 우리가 cd로 들어갈 수 있는 디렉터리들입니다.

아래는 위쪽에 "기본" macOS 터미널, 아래쪽에 보기 좋게 아이콘과 색상을 추가해 꾸민 커스텀 터미널 스크린샷이에요. 둘 다 ls -l을 실행한 결과를 보여주고 있죠.

파일 목록을 보여주는 기본 macOS 터미널과 색상이 들어간 커스텀 터미널 - ls -l 명령어 실행 결과

참고: 각 명령어에 어떤 옵션들이 숨겨져 있는지 정확히 알고 싶다면 해당 명령어의 매뉴얼 페이지(Man page)를 찾아보시면 됩니다. 터미널에 man 명령어를 치고 알고 싶은 명령어 이름을 뒤에 적어주세요. 예를 들어 man ls처럼요. 그러면 터미널의 기본 텍스트 뷰어(제 터미널 기준으로는 less 프로그램)를 통해 매뉴얼 문서가 열리고, 화살표 방향키를 눌러 문서를 스크롤하며 읽을 수 있어요. 매뉴얼 페이지에는 모든 옵션이 아주아주 상세하게 적혀 있는데, 처음엔 좀 무시무시해 보일 수 있어요. 그래도 필요할 때 찾아볼 수 있다는 점만 기억해 두세요. 매뉴얼 페이지를 다 보고 나면 텍스트 뷰어의 종료(Quit) 명령을 이용해 빠져나와야 합니다 (less 에서는 "q" 키를 누르면 돼요. 만약 어떻게 끄는지 모르겠다면 웹 검색을 해보셔야 할 수도 있어요).

참고: 여러 개의 옵션을 동시에 적용해서 명령어를 실행하고 싶다면, 보통 대시(-) 뒤에 문자들을 쭉 이어서 하나의 문자열처럼 붙여 쓰면 됩니다. 예를 들어 ls -lah 또는 ls -ltrh처럼 말이죠. 방금 배운 man ls 명령어를 써서 이 추가 옵션들이 각각 어떤 역할을 하는지 직접 추리해 보세요!

가장 필수적인 두 개의 명령어에 대해 배웠으니, 이제 여러분의 디렉터리 이리저리 돌아다녀 보며 이곳저곳으로 내비게이션 할 수 있는지 연습해 보세요.

생성, 복사, 이동, 삭제 명령어 모음

터미널로 작업하면서 정말 자주 쓰게 될 다른 기본 유틸리티 명령어들도 있습니다. 아주 단순한 기능들이라 아까 배운 명령어들처럼 길게 설명하진 않을게요.

중요한 파일을 날려버리지 않도록, 컴퓨터 어딘가에 테스트용 디렉터리를 하나 만들고 아래 예제들을 가이드 삼아 직접 가지고 놀아보세요:

  • mkdir — 현재 위치에 여러분이 지정한 이름으로 새로운 디렉터리를 생성합니다. 예를 들어 mkdir my-awesome-website라고 치면 my-awesome-website라는 새 디렉터리가 생깁니다.
  • rmdir — 이름 지정된 디렉터리를 삭제합니다. 단, 디렉터리 안이 비어있을 때만 작동해요! 예를 들어 rmdir my-awesome-website는 방금 위에서 만든 디렉터리를 지웁니다. 만약 비어있지 않은 디렉터리(안에 들어있는 모든 내용물 포함)를 통째로 지우고 싶다면 rm -r 명령어를 쓰시면 되지만, 이 명령어는 꽤 위험합니다. 지우기 전에 나중에 필요한 파일이 들어있진 않은지 두 번 세 번 꼭 확인하세요. 영원히 사라지거든요.
  • touch — 현재 위치에 내용이 텅 빈 새로운 파일을 만듭니다. 예를 들어 touch mdn-example.md라고 하면 mdn-example.md라는 빈 파일이 하나 생성됩니다.
  • mv — 첫 번째로 지정한 위치의 파일을 두 번째로 지정한 위치로 이동시킵니다. 예를 들어 mv mdn-example.md mdn-example.txt처럼 적습니다 (위치는 파일 경로 형태로 적어줍니다). 이 명령어는 현재 디렉터리에 있는 mdn-example.md 파일을 같은 디렉터리에 mdn-example.txt라는 이름으로 이동시킵니다. 기술적으로는 '이동'이지만, 실제 쓰임새를 보면 파일의 '이름을 바꾸는(rename)' 역할을 하고 있죠.
  • cp — mv와 사용법은 비슷합니다. 첫 번째로 지정한 위치의 파일 사본을 두 번째로 지정한 위치에 생성합니다(복사). 예를 들어 cp mdn-example.txt mdn-example.txt.bak이라고 치면, mdn-example.txt의 복사본이 mdn-example.txt.bak이라는 이름으로 생깁니다 (물론 원하시는 다른 이름으로 만드셔도 상관없어요).
  • rm — 지정한 파일을 삭제합니다. 예를 들어 rm mdn-example.txt는 mdn-example.txt 단일 파일을 삭제하죠. 주의할 점은 이 삭제는 바탕화면의 휴지통으로 가는 게 아니라 영구 삭제라서 복구가 안 된다는 점이에요!

참고: 많은 터미널 명령어들이 별표(*)를 "와일드카드(wild card)" 문자로 사용할 수 있게 지원합니다. 와일드카드는 "어떤 문자들의 조합이 와도 상관없다"는 뜻이에요. 이 기능을 쓰면 특정 패턴과 일치하는 수많은 파일들을 한 번에 조작할 수 있죠. 예를 들어 rm mdn-* 라고 치면 이름이 mdn-으로 시작하는 모든 파일이 싹 지워집니다. rm mdn-*.bak 라고 치면 이름이 mdn-으로 시작하고 .bak로 끝나는 모든 파일들을 지워주죠.

터미널 — 위험할 수도 있다고요?

앞에서도 넌지시 말씀드렸지만 확실하게 짚고 넘어갈게요. 터미널을 쓸 때는 항상 주의하셔야 해요. 아주 단순한 명령어들은 크게 위험할 게 없지만, 명령어들을 조합해서 복잡하게 만들기 시작하면 그 명령어가 정확히 무슨 일을 할지 곰곰이 생각해야 합니다. 그리고 실제 목표로 하는 디렉터리에 실행하기 전에 무조건 먼저 테스트를 해보는 습관을 들이세요.

어떤 폴더에 1000개의 텍스트 파일이 들어있고, 파일 이름에 특정 문구가 포함된 파일들만 쏙쏙 골라서 지우고 싶다고 가정해 봅시다. 만약 조금이라도 실수하면 중요한 작업물 파일까지 같이 날려버릴 수 있어요.
좋은 습관 중 하나는, 일단 메모장 같은 텍스트 에디터에 터미널 명령어를 써보고 제대로 적었는지 눈으로 확인하는 거예요. 그다음 디렉터리의 백업 복사본을 만들어 두고, 거기서 명령어를 먼저 돌려보며 테스트를 진행하는 거죠.

만약 내 컴퓨터에서 직접 터미널 명령어를 테스트해 보는 게 영 불안하시다면, 온라인상에서 안전하게 명령어를 입력하며 연습할 수 있는 호스팅 터미널 서비스들도 있습니다. 내 컴퓨터를 망가뜨릴 걱정 없이 마음껏 연습할 수 있죠:

  • MDN의 학습 파트너인 Scrimba에서는 학습 환경 내에 직접 명령어를 입력해 볼 수 있는 터미널을 제공합니다. 명령줄 기초(Command Line Basics) 코스를 들어보시면 실제 작동 방식을 잘 배울 수 있어요. 파일 트리를 돌아다니고 터미널로 파일과 디렉터리를 조작하는 방법을 재미있고 인터랙티브하게 소개해줍니다.
  • sandbox.bio에 있는 Command-line playground 역시 훌륭한 터미널 연습 공간이에요. 여기서 다양한 명령어 인터페이스와 Bash 같은 대중적인 쉘 환경에 친숙해질 수 있습니다.

👨‍🏫 강사의 팁: 특정 터미널 명령어를 아주 빠르고 직관적으로 살펴보고 싶다면 tldr.sh 사이트를 강력 추천합니다! MDN처럼 커뮤니티가 주도하는 문서 서비스인데, 터미널 명령어에 특화되어 있어서 실무에서 정말 유용해요.

다음 섹션에서는 난이도를 한 단계 (아니 사실 여러 단계) 높여서, 명령줄에서 여러 도구들을 서로 연결해 터미널이 일반 데스크톱 GUI보다 얼마나 강력해질 수 있는지 알아볼게요.

파이프(Pipe)로 명령어 연결하기

터미널의 진가는 바로 | (파이프) 기호를 사용해 여러 명령어들을 사슬처럼 하나로 엮어 낼 때 발휘됩니다. 무슨 뜻인지 아주 간단한 예제를 통해 알아볼까요.

현재 디렉터리의 내용물을 출력하는 ls 명령어는 앞서 배웠었죠:

ls

그런데 만약 현재 디렉터리 안에 파일과 폴더가 몇 개나 있는지 빠르게 세어보고 싶다면 어떡할까요? ls 자체만으로는 그 개수를 세어주는 기능이 없어요.

이때 활용할 수 있는 다른 유닉스 도구로 wc가 있습니다. 이 명령어는 입력받은 데이터의 단어 수, 줄 수, 글자 수, 혹은 바이트 수를 세어주는 역할을 합니다. 텍스트 파일도 입력받을 수 있어서, 아래 명령어는 myfile.txt 파일이 몇 줄짜리인지 출력해 줍니다:

wc -l myfile.txt

여기서 중요한 점은, 이 wc 명령어가 파이프(piped)로 들어온 출력 결과의 줄 수도 세어줄 수 있다는 거예요. 예를 들어, 아래 명령어를 실행하면 원래 터미널 화면에 출력되어야 할 ls 명령어의 결과물(목록들)을 셉니다. 그리고 파일 이름들을 나열하는 대신, 그 결과물이 총 몇 줄인지 계산해서 화면에 개수만 딱 띄워주는 거죠.

ls | wc -l

ls 명령어는 파일이나 디렉터리를 한 줄에 하나씩 출력하니까, 줄 수를 세면 곧 그게 파일과 디렉터리의 총 개수가 되는 셈이에요.

도대체 무슨 일이 일어나고 있는 걸까요? 유닉스 명령줄 도구들의 기본적인 철학 중 하나는 텍스트를 터미널 화면에 출력한다는 것입니다. (이것을 "표준 출력(standard output)으로 내보낸다" 거나 줄여서 STDOUT이라고 불러요). 그리고 상당수의 명령어들은 스트림으로 들어오는 입력값 내용을 읽어 들일 수 있습니다. (이것을 "표준 입력(standard input)" 혹은 STDIN이라고 부르죠).

파이프 연산자(|)는 이런 입력과 출력을 서로 연결해 주는 역할을 합니다. 한 명령어의 '출력'이 그다음 명령어의 '입력'이 되도록 하여 우리의 필요에 딱 맞는 복잡한 작업들을 조립해 나갈 수 있게 해 주죠. 이 예제에서는 원래라면 화면(STDOUT)에 뿌려졌어야 할 ls의 출력물이 파이프를 타고 wc의 입력물로 쑥 들어갑니다. 그럼 wc는 그 입력값을 받아서 몇 줄짜리인지 계산하고, 그 최종 결과 숫자를 화면(STDOUT)에 출력해 내는 거랍니다.

조금 더 복잡한 예제

이번에는 조금 더 복잡한 걸 해볼게요.

  1. 우선 URL에서 콘텐츠를 요청할 때 쓰는 curl 명령어를 사용해서 MDN의 "fetch" 페이지 내용물(HTML 등)을 가져와 보겠습니다. 주소는 https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch 예요. 지금 한번 입력해 보세요:

    curl https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch

    아마 화면에 아무런 결과물도 나오지 않을 거예요. 왜냐하면 저 페이지 주소가 다른 곳으로 리다이렉트(이동) 되었거든요 (현재는 /Web/API/fetch로 이동됩니다). 리다이렉트 된 주소까지 끝까지 따라가라고 curl에게 명시적으로 알려주려면 -L 플래그(옵션)를 써야 합니다.

  2. 이번엔 curl의 -I 플래그를 사용해 developer.mozilla.org 서버가 돌려주는 헤더 정보들만 살짝 들여다볼게요. 그리고 curl의 출력 결과를 grep 명령어와 파이프로 연결해서, 터미널 화면에 위치 이동(redirect) 정보들만 띄워봅시다 (grep에게 "location"이라는 단어가 포함된 줄만 뽑아서 보여줘! 라고 시키는 거예요). 아래 명령어를 실행해 보세요 (최종 페이지에 도착하기 전에 딱 한 번의 리다이렉트가 발생하는 걸 보실 수 있을 거예요):

    curl https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch -L -I | grep location

    여러분의 화면에는 대략 이런 결과가 나올 겁니다 (curl 명령어가 다운로드 카운터 같은 부수적인 정보를 먼저 뿜어내긴 할 거예요):

    location: /en-US/docs/Web/API/Window/fetch

  3. 억지로 만들어낸 예시이긴 하지만, 이 결과를 조금 더 다듬어 볼까요? location: 줄의 내용을 가져와서 맨 앞에 기본 도메인 주소(base origin)를 덧붙여 완전한 URL 형태가 출력되게 만들어 봅시다. 이 작업을 위해 명령어들의 사슬에 awk라는 녀석을 추가할 거예요 (awk는 JavaScript나 Ruby, Python 같은 프로그래밍 언어의 일종인데, 나이만 훨씬 많은 언어라고 보시면 됩니다!). 한번 실행해 볼까요:

    curl https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/fetch -L -I | grep location | awk '{ print "https://developer.mozilla.org" $2 }'

    짜잔! 최종 결과물은 아래처럼 예쁘게 나올 거예요:

    https://developer.mozilla.org/en-US/docs/Web/API/Window/fetch

명령어들을 이렇게 하나로 합쳐서, 모질라 서버가 /docs/Web/API/WindowOrWorkerGlobalScope/fetch 요청을 받았을 때 거쳐 가는 리다이렉트의 전체 URL 주소를 정확하게 뽑아낼 수 있었어요.
운영체제 시스템과 이렇게 친해지는 것은 앞으로 몇 년이고 여러분께 큰 도움이 될 겁니다. 한 가지 역할만 딱딱 하는 이 작은 도구들이 어떻게 맞물려 돌아가는지, 어떻게 나만의 툴킷이 되어 특수한 문제들을 해결해 주는 무기가 되는지 꼭 체득하시길 바라요!

👨‍🏫 강사의 팁: 프론트엔드 개발자로서 서버 API와 통신할 때(예: fetch나 axios를 쓸 때) 응답 헤더가 어떻게 오는지, CORS 에러가 날 때 어떤 상태인지 확인하려고 터미널에서 curl을 날려보는 일이 잦습니다. 이런 복합적인 명령어 사용법이 손에 익으면 개발 속도가 비약적으로 빨라질 거예요.

파워업! 도구 추가하기

지금까지 우리 컴퓨터에 기본으로 탑재되어 있는 명령어들을 살펴보았는데요. 이번엔 외부 써드파티(third-party) CLI 도구를 어떻게 설치하고 사용하는지 알아봅시다.

프론트엔드 웹 개발을 위한 무수히 많은 설치형 도구 생태계는 현재 대부분 npm이라는 곳에 모여 있어요. npm은 민간이 운영하는 패키지 호스팅 서비스로, Node.js와 아주 긴밀하게 함께 작동합니다. 생태계는 계속 확장되고 있어서, 시간이 지나면 더 다양한 패키지 제공처가 등장할 수도 있어요.

Node.js를 설치하면 npm 명령줄 도구도 자동으로 같이 설치됩니다 (그리고 npm을 돕는 npx라는 부가 도구도 함께 설치돼요). 이 npm이 바로 추가적인 명령줄 도구들을 다운받게 해주는 관문 역할을 합니다. Node.js와 npm은 macOS, Windows, Linux 어떤 시스템에서든 똑같은 방식으로 작동한답니다.

위 링크로 들어가서 여러분의 운영체제에 맞는 Node.js 설치 파일을 다운받고 실행해 지금 시스템에 npm을 설치해 보세요. 만약 설치 도중 옵션을 묻는다면, npm이 설치에 포함되도록 확실히 체크해 주세요.

Windows 환경의 Node.js 설치기 화면. npm을 포함할 수 있는 옵션을 보여줌

여기서는 예시로 Prettier를 설치해 보겠습니다. 이전 코드 에디터 문서에서 VS Code 확장 프로그램 형태로 설치하는 법을 보여드렸었죠? 이번에는 명령줄 도구로서 설치하는 법을 보여드릴게요.

참고: Prettier는 매우 자기주장이 강한(opinionated) 코드 포맷팅 도구라서 설정할 수 있는 옵션이 "몇 개"밖에 없어요. 옵션이 적다는 건 그만큼 심플하다는 뜻이죠. 가끔 개발 도구들이 세팅하기 너무 복잡해서 골치가 아픈 경우가 많은데, 이렇게 "옵션이 몇 개 없는" 방식은 오히려 굉장히 매력적으로 다가올 때가 많답니다.

CLI 도구들은 어디에 설치해야 할까요?

Prettier 설치에 뛰어들기 전에, 한 가지 답해야 할 질문이 있어요. — "도대체 어디에 설치해야 하죠?"

npm을 사용하면 도구를 전역(Globally)으로 설치할지, 아니면 현재 프로젝트 디렉터리에 지역적(Locally)으로 설치할지 선택할 수 있습니다. 전역으로 설치하면 터미널 어디에서나 그 도구를 불러 쓸 수 있게 되죠.

두 방법 모두 장단점이 명확해요. 전역 설치의 장단점을 간단히 나열해 볼게요 (물론 이게 다는 아닙니다).

전역(Globally) 설치의 장점:

  • 터미널 어느 위치에서나 명령어를 쳐서 사용할 수 있다.
  • 딱 한 번만 설치하면 된다.
  • 디스크 용량을 덜 차지한다.
  • 항상 똑같은 버전을 쓰게 된다.
  • 원래 있던 유닉스 명령어처럼 자연스럽게 쓸 수 있다.

전역(Globally) 설치의 단점:

  • 특정 프로젝트의 코드베이스와 버전이 맞지 않아 호환성 문제가 생길 수 있다.
  • git 같은 도구를 통해 프로젝트 코드를 공유할 때, 다른 팀원들은 여러분의 컴퓨터에만 깔려 있는 전역 도구를 쓸 수 없다.
  • 바로 위 단점과 이어지는 문제로, 프로젝트 환경을 똑같이 복제하기가 매우 어려워진다 (반대로 지역으로 설치하면 프로젝트의 의존성(dependencies)으로 설정되어 npm install 한 방에 모든 팀원이 똑같은 도구를 설치할 수 있습니다).

단점의 개수는 적지만, 전역 설치로 인해 겪게 될 부정적 영향(팀원 간 버전 충돌 등)은 이점으로 얻는 편리함보다 훨씬 클 수 있어요.
따라서 우리는 여기서 지역적(Locally)으로 설치해 볼 텐데요. 각각의 장단점을 충분히 이해하셨다면, 추후에 필요에 따라 전역 설치를 쓰셔도 전혀 무방합니다.

👨‍🏫 강사의 팁: 프론트엔드 포트폴리오를 작성하실 때 TypeScript나 Next.js를 쓰게 되잖아요? 보통 그런 프로젝트들은 그 폴더 안에만 해당 도구들을(지역적으로) 설치합니다. 그래야 나중에 회사에 취업해서도 수많은 팀원들과 똑같은 환경으로 맞춰서 일할 수 있거든요. "내 컴퓨터에선 되는데 왜 네 컴퓨터에선 안 되지?" 하는 사태를 막는 1등 공신이에요!

Prettier 설치하기

Prettier는 프론트엔드 개발자들을 위한 강제성(opinionated) 짙은 코드 포맷팅 도구예요. JavaScript 기반 언어들에 초점을 맞추면서 HTML, CSS, SCSS, JSON 등도 지원합니다.

Prettier가 해주는 일은 다음과 같아요:

  • 모든 코드 파일의 스타일을 사람이 일일이 수동으로 맞추려다 생기는 머리 아픈 스트레스를 없애줍니다. Prettier가 자동으로 싹 다 맞춰주거든요.
  • 이제 막 웹 개발에 입문한 분들이 업계 모범 사례(best-practice) 스타일대로 코드를 작성할 수 있게 이끌어줍니다.
  • 어떤 운영체제에든 설치할 수 있고, 프로젝트 자체 도구의 일부로 포함시킬 수 있어서 함께 일하는 동료나 친구들이 여러분과 똑같은 코드 스타일을 유지하도록 강제할 수 있습니다.
  • 코드를 저장할 때마다, 혹은 타자를 칠 때마다, 심지어 코드를 배포(publish)하기 직전에 포맷팅이 작동하도록 세팅할 수 있어요 (이런 추가 도구 연동에 대해서는 모듈 후반부에서 더 살펴볼 거예요).

이 문서에서는 Prettier 설치 가이드에서 추천하는 대로 Prettier를 지역적으로(Locally) 설치해 볼 겁니다.

  1. Node.js를 설치했다면, 터미널을 열고 다음 명령어를 실행해 Prettier를 설치하세요 (명령어 중 --save-dev가 무슨 뜻인지는 다음 문서에서 자세히 설명해 드릴게요):

    npm install --save-dev prettier

  2. 이제 npx 도구를 사용해서 방금 지역적으로 설치한 Prettier 파일을 실행할 수 있어요. 다른 수많은 명령어들과 마찬가지로 아무 인자(argument) 없이 명령어만 덜렁 입력하면, 사용법과 도움말 정보가 화면에 출력됩니다. 지금 해보세요:

    npx prettier

화면에 대략 이런 내용이 나올 거예요:

Usage: prettier [options] [file/glob ...]

By default, output is written to stdout.
Stdin is read if it is piped to Prettier and no files are given.

…

사용법이나 도움말 정보가 아무리 길고 지루해 보여도 대충이라도 훑어보는 습관을 들이는 것이 좋습니다. 그 도구가 애초에 어떤 의도로 만들어졌고 어떻게 써야 하는지 이해하는 데 큰 도움이 되거든요.

참고: 만약 Prettier를 내 폴더에 지역적으로 먼저 설치하지 않은 상태에서 다짜고짜 npx prettier를 실행해 버리면, npx가 그 한 번의 명령어를 실행하기 위해 최신 버전의 Prettier를 임시로 쓱 다운받고 실행해 버립니다. 뭔가 되게 좋아 보일 수 있지만, Prettier의 버전이 올라갈 때마다 코드 포맷팅 결과물이 미세하게 바뀔 수 있거든요. 여러분이 "아, 이제 버전 업데이트해야겠다!" 하고 마음먹기 전까지는 계속 똑같은 포맷팅 규칙이 유지되길 원하실 텐데, 그러려면 버전을 고정시킬 수 있게 꼭 내 폴더에(지역적으로) 설치하고 쓰셔야 합니다.

Prettier 가지고 놀아보기

Prettier가 정확히 어떻게 작동하는지 가볍게 한번 써볼까요?

  1. 가장 먼저, 파일 시스템 어딘가에 찾기 쉬운 새로운 디렉터리를 하나 만드세요. Desktop(바탕화면)에 prettier-test라는 이름으로 만들면 좋겠네요.

  2. 그다음, 방금 만든 테스트 디렉터리 안에 index.js라는 새 파일을 만들고 아래 코드를 그대로 저장해 주세요:

    const myObj = {
a:1,b:{c:2}}
function printMe(obj){console.log(obj.b.c)}
printMe(myObj)

  3. 이제 내 코드 파일들에 수정할 부분이 있는지 없는지 Prettier를 돌려서 점검(check)해 볼 수 있어요. 터미널에서 cd 명령어로 여러분이 만든 디렉터리 안에 들어간 다음, 이 명령어를 실행해 보세요:

    npx prettier --check index.js

    그러면 다음과 비슷한 내용이 출력될 거예요:

    Checking formatting...
index.js
Code style issues found in the above file(s). Forgot to run Prettier?

  4. 호오, 고쳐야 할 코드 스타일 이슈가 발견되었다고 하네요. 문제없습니다! prettier 명령어 뒤에 --write 옵션을 붙여주면 Prettier가 알아서 예쁘게 코드를 고쳐줄 거예요. 우린 그저 유용한 코드를 짜는 핵심 고민에만 집중하면 됩니다. 이제 터미널에 이 버전을 실행해 보세요:

    npx prettier --write index.js

    이번엔 이런 결과가 뜰 겁니다:

    Checking formatting...
index.js
Code style issues fixed in the above file(s).

    하지만 화면에 뜨는 글씨보다 훨씬 중요한 건 이거죠! 아까 저장해 둔 index.js 파일을 다시 열어보세요. 코드 형태가 아래처럼 보기 좋게 재정렬되어 있을 거예요:

    const myObj = {
  a: 1,
  b: { c: 2 },
};
function printMe(obj) {
  console.log(obj.b.c);
}
printMe(myObj);

여러분이 어떤 작업 방식(workflow)을 선호하냐에 따라 이 모든 과정을 완벽하게 자동화시킬 수 있습니다. 그리고 이 '자동화'야말로 이런 도구들이 진정으로 빛을 발하는 부분이죠. 강사인 제 개인적인 취향은, 내가 복잡하게 세팅하지 않아도 알아서 "자연스럽게 마법처럼 돌아가는" 자동화를 좋아합니다.

Prettier로 자동화를 구현하는 방법은 정말 다양합니다. 비록 이 문서의 범위를 조금 벗어나긴 하지만, 온라인상에 훌륭한 자료들이 많이 있으니(일부는 아래에 링크해 두었어요) 찾아보시길 추천해요. 이런 식으로 Prettier를 자동으로 발동시킬 수 있습니다:

제가 개인적으로 가장 추천하는 방식은 두 번째예요 — VS Code에서 코드를 짜다가 저장 단축키를 누를 때마다, Prettier가 샤라락 끼어들어서 필요한 포맷팅을 싹 정리해 주고 저장되는 방식이죠. 다양한 방식으로 Prettier를 다루는 더 많은 정보는 Prettier 공식 문서에서 찾아보실 수 있어요.

가지고 놀아볼 만한 다른 도구들

몇 가지 도구들을 더 만져보고 싶으시다면, 재미 삼아 테스트해 볼 만한 짧은 리스트를 준비했어요:

  • bat — 파일을 터미널 화면에 출력해 주는 cat 명령어의 "예쁜 버전"이에요.
  • prettyping — 서버가 잘 살아있는지 응답을 체크할 때 쓰는 ping 명령어를 시각적으로 보기 좋게 띄워줍니다.
  • htop — 프로세스 뷰어입니다. 내 컴퓨터 CPU 팬이 비행기 이륙하는 소리를 낼 때, 도대체 어떤 녀석이 범인인지 찾아내고 싶을 때 아주 유용하죠.
  • tldr — 아까 챕터 초반에 웹사이트로 소개했었죠? 터미널 명령줄 도구로도 설치해서 쓸 수 있습니다.

위에서 소개한 도구 중 일부는 우리가 방금 Prettier를 설치할 때 썼던 npm을 이용해 설치해야 할 수도 있다는 점 참고해 주세요.

profile
김동현
프론트에_가까운_풀스택_개발자
다음 포스트

Basic HTML syntax

0개의 댓글