터미널을 쓰며 더 나은 개발자가 됐습니다. 예상했던 이유와는 달랐습니다

AI 요약

터미널을 쓰기 시작한 이유는 디렉터리 이동이나 패키지 설치처럼 그래픽 인터페이스에서도 할 수 있는 작업을 처리하기 위해서였습니다. 하지만 Linux 환경에서 명령어를 실행하다 보니, 명령이 무엇을 하고 왜 실패하는지 궁금해졌습니다. 저자는 빠르게 명령어를 입력하는 능력보다 운영체제와 애플리케이션이 실제로 어떻게 움직이는지 이해하게 된 점을 더 큰 변화로 꼽습니다.

파일과 프로세스를 직접 확인하기

터미널에서는 현재 작업 디렉터리와 숨김 파일, 상대 경로와 절대 경로를 의식해야 합니다. pwd, ls -la, cd .. 같은 명령을 쓰며 자신이 어디에 있는지 확인하고, 설정 파일이 보이지 않는 이유나 경로를 잘못 지정한 원인을 파악합니다. 파일 관리자에서는 인터페이스가 자연스럽게 처리하던 요소를 직접 확인하면서 파일과 디렉터리 구조에 관한 이해가 구체적으로 바뀝니다.

개발 서버가 이미 사용 중인 포트에서 실행되지 않을 때도 창을 닫아가며 해결하기보다 프로세스와 소켓을 살펴봅니다. ps aux, pgrep -af node, ss -ltnp로 실행 중인 프로세스와 수신 대기 포트를 확인하고, ss -ltnp | grep ':5173'로 Vite 개발 서버가 흔히 쓰는 포트 5173을 살펴볼 수 있습니다. 소켓에 연결된 모든 프로세스 정보가 항상 보이는 것은 아니며, 권한에 따라 확인 범위가 달라질 수 있다고 덧붙입니다. 실행 중인 애플리케이션과 프로세스, 포트의 관계를 확인하면 서버가 동작한다는 말의 의미도 분명해집니다.

권한과 네트워크 문제 좁히기

파일을 수정하거나 스크립트를 실행하지 못하면 ls -l과 stat으로 소유자와 권한을 확인합니다. 디렉터리의 실행 권한은 파일의 실행 권한과 다르게 디렉터리 안을 탐색할 수 있는지를 나타냅니다. 권한 오류가 날 때마다 sudo를 붙이면 명령이 실행되더라도 원인을 파악하지 못할 수 있고, 작업에 따라 root 소유 파일을 만들 수도 있습니다. 저자는 일단 동작하게 만드는 것과 실패 이유를 이해하는 것을 구분합니다.

네트워크 연결 문제도 하나의 막연한 오류로 다루지 않습니다. dig로 DNS 조회 결과를 확인하고, curl -I https://example.com으로 HTTP 응답을 살펴보며, ss -ltn으로 로컬 시스템에서 TCP 연결을 기다리는 포트를 확인합니다. 각 명령이 보여주는 정보는 서로 다르므로, 호스트 이름 확인과 서버 응답, 로컬 포트 상태 중 어디에서 문제가 생겼는지 차례로 좁힙니다. 이 명령들이 모든 네트워크 문제를 설명해 주지는 않지만 조사를 시작할 지점을 제공합니다.

오류 메시지를 읽고 작은 실습으로 익히기

컴파일 오류와 의존성 경고, 스택 트레이스, 서버 로그를 훑고 곧바로 해결책을 시도하는 대신 실제 메시지를 읽으라고 권합니다. 환경 변수가 없는 문제와 네트워크 요청 실패, 의존성 충돌과 문법 오류는 서로 다른 종류의 문제입니다. 원인을 구분하면 무엇을 검색하고 어떤 정보를 더 확인할지 알기 쉬워집니다.

글에는 Linux를 중심으로 한 실습도 담겼습니다. 프로젝트 디렉터리에서 pwd, ls -la, find . -maxdepth 2 -type f를 실행해 위치와 숨김 파일, 파일 구성을 확인합니다. 개발 서버를 실행한 뒤 다른 터미널에서 pgrep -af node와 ss -ltnp를 사용해 프로세스와 포트를 찾아봅니다. ls -l package.json과 stat package.json으로 파일 권한과 소유자를 확인하고, curl -v https://example.com 출력에서 연결 정보와 TLS 협상, 요청 및 응답 헤더를 살펴봅니다. 명령어를 외우는 대신 결과가 무엇을 보여주는지 이해하는 것이 실습의 목적입니다.

마지막으로 printf 'apple\nbanana\napricot\n' | grep '^a' 예시를 들어 파이프의 역할을 설명합니다. 파이프는 한 명령의 출력을 다음 명령의 입력으로 전달하므로 작은 도구를 연결해 작업할 수 있습니다. 저자는 그래픽 애플리케이션을 버리고 모든 일을 터미널에서 처리하자고 주장하지 않습니다. 터미널을 사용한다고 저절로 개발 실력이 좋아지는 것도 아닙니다. 명령어를 복사하는 데 그치지 않고 무엇을 하는지 궁금해하며 조사하는 태도가 중요하다는 것이 글의 요지입니다. 일부 명령은 macOS나 Windows에서 다를 수 있다고 안내합니다.

dev.to 반응

• @james_anderson_h — 동작하게 만드는 것과 왜 동작하지 않았는지 이해하는 것의 차이가 글 전체의 요지이며, 개발에서 가장 저평가된 생각 중 하나입니다. 터미널의 진짜 가치는 입력 속도나 외워둔 명령어가 아니라, 이해를 대신해 주던 인터페이스를 걷어낸 데 있습니다. GUI는 프로세스와 권한, 경로를 매끄럽게 처리해 존재를 배우지 못하게 하는 친절한 도구입니다. 그러다 문제가 생기면 어디서부터 봐야 할지 모르게 됩니다. 터미널은 그 계층을 숨기지 않으므로 실제로 보게 만들고, 더 나은 조사자가 되는 능력은 어떤 프레임워크와 도구보다 오래 갑니다. 좋은 글입니다.
  • @sizzlebop — 정말 감사드립니다. "GUI가 이해를 대신해 준다"는 표현이 정말 좋습니다. 제가 말하려던 생각과 정확히 같습니다. 가장 큰 이점은 명령어 입력이 빨라진 게 아니라 더 나은 조사자가 된 것입니다. 읽어주셔서 감사합니다.
  • @james_anderson_h — 바로 그겁니다. 더 나은 조사자가 되는 교훈은 어떤 도구에도 묶이지 않아서 조용히 거의 모든 것보다 가치가 커집니다. 명령어는 바뀌고 프레임워크는 사라져도 추측하는 대신 실제로 무슨 일이 일어나는지 묻는 습관은 어떤 문제에도 이어집니다. 초보 시절에 읽고 싶었던 글입니다. 써주셔서 감사합니다.
• @anas_issath — 포트 5173을 차지한 채 잊힌 Vite 서버는 너무 공감됩니다. sudo 부분도 와닿았습니다. 명령을 실행되게 만드는 것과 실패 이유를 아는 것은 정말 다릅니다. 후회할 root 소유 파일을 저도 몇 개 만들었습니다. 명령어를 외우는 것보다 호기심이 중요하다는 좋은 알림입니다.

원문: dev.to / 번역·요약: Trawling