리눅스 CLI와 권한: 마우스 없는 세상에서 살아남기

“기능 수정 완료했습니다!” …근데 배포는요?

입사 후 3개월, 수습 기간이 끝나갈 무렵 처음으로 실무 업무를 받았다. 아주 간단한 기능 수정이었지만, 나는 긴장 반 설렘 반으로 내 자리의 컴퓨터(localhost)에서 코드를 고치고 테스트까지 완벽하게 마쳤다.

“팀장님, 로컬에서 테스트 다 통과했습니다!”

팀장님은 고개를 끄덕이며 배포를 지시했다. “수고했어요. 그럼 GitLab(깃허브 같은 소스 코드 저장소)에 커밋하고 운영 서버에 배포해 보세요.”

배포? 나는 수습 때 받은 인수인계 문서를 황급히 뒤졌다. 문서에는 알 수 없는 용어들이 적혀 있었다.

코드를 GitLab에 푸시(Push)한다. (이건 알겠다)
GitLab CI가 자동으로 빌드할 때까지 기다린다. (자동? 좋네)
운영 서버에 접속해서 docker service update ... 명령어를 입력한다. (도커? 이건 또 뭐지?)

일단 시키는 대로 코드를 올렸다. 이제 마지막 단계인 ‘운영 서버 접속’만 남았다. 나는 주섬주섬 일어날 준비를 했다. 드라마에서 본 것처럼, 에어컨 바람이 쌩쌩 부는 서버실(IDC)에 직접 들어가서 서버에 달린 키보드를 두드려야 하는 줄 알았기 때문이다.

그 모습을 본 사수님이 웃으며 나를 불렀다. “어디 가요? 그냥 자리에 앉아서 SSH로 접속하면 돼요.”

검은 화면과의 첫 만남

SSH(Secure Shell)라는 프로그램을 켜고, 사수님이 알려준 IP 주소와 비밀번호를 치고 엔터를 눌렀다. 윈도우였다면 화려한 바탕화면이 나를 반겼을 것이다. 하지만 내 모니터에 뜬 건 시커먼 배경에 깜빡이는 커서 하나뿐이었다.

ubuntu@ip-172-31-0-1:~$ _

마우스로 클릭할 아이콘도 없고, 우클릭해서 ‘새 폴더 만들기’를 할 수도 없었다. 당황해서 아무 키나 눌러보다가 ls를 치니 파일 목록이 텍스트로 주르륵 떴다.

‘아, 이게 말로만 듣던 CLI(Command Line Interface)구나.’

하지만 진짜 공포는 파일을 실행하려고 할 때 찾아왔다. 매뉴얼에 적힌 update 스크립트를 실행했는데, 윈도우에서는 더블 클릭이면 끝날 일이 여기서는 빨간 에러 메시지로 돌아왔다.

Permission denied (권한이 거부되었습니다)

내 서버인데 내가 실행을 못 한다니? 도대체 리눅스는 왜 이렇게 불친절한 걸까?

*서버는 친절한 그래픽(GUI)을 제공하지 않는다. 오직 텍스트(CLI)뿐이다.*

디지털 물류 센터의 창고지기

우리의 ‘디지털 물류 센터’ 세계관으로 돌아와 보자. 윈도우가 깔린 내 노트북이 ‘안락한 개인 사무실’이라면, 리눅스 서버는 오직 물류 처리를 위해 지어진 ‘거대한 창고’다. 이 창고에는 수만 개의 상자(파일)가 쌓여 있다.

만약 창고지기가 일일이 걸어 다니며 상자를 확인하고(GUI), 열쇠로 하나하나 문을 연다면(클릭) 작업 속도가 너무 느릴 것이다. 그래서 리눅스는 ‘명령어’라는 무전기를 사용한다.

“1번 구역 상자 전체 리스트 출력해!” (ls) “3번 상자를 5번 구역으로 옮겨!” (mv) “이 상자 실행해!” (./start.sh)

마우스가 없어서 불편한 게 아니다. 익숙해지면 마우스보다 백 배 빠른 속도로 수천 개의 파일을 제어할 수 있기 때문에 의도적으로 그래픽을 뺀 것이다.

*일일이 뛰어다니는 것보다, 무전기(명령어)로 지시하는 것이 훨씬 빠르고 강력하다.*

[Code Verification] 권한(Permission)의 절대 법칙

리눅스 초심자를 가장 괴롭히는 건 바로 ‘권한(Permission)’ 문제다. 윈도우는 ‘관리자 권한으로 실행’ 한 번이면 웬만한 건 다 해결된다. 하지만 리눅스는 파일 하나하나마다 “누가(Who), 무엇을(What) 할 수 있는지”를 엄격하게 따진다.

터미널에 ls -l을 치면 나오는 외계어를 해석할 줄 알아야 생존할 수 있다.

$ ls -l myscript.sh
-rwxr-xr--  1  owner  group  1024  Jan 1 12:00  myscript.sh

분석: 가장 앞의 -rwxr-xr--가 핵심이다. 맨 앞의 -(파일)를 제외하고 3개씩 끊어 읽어야 한다.

소유자(User) rwx: 읽고(Read), 쓰고(Write), 실행(Execute) 다 할 수 있다. (주인님)
그룹(Group) r-x: 읽고 실행만 할 수 있다. 수정(Write)은 안 된다. (같은 팀원)
나머지(Other) r--: 읽기만 할 수 있다. (외부인)

내가 짠 스크립트가 실행이 안 된다면? 십중팔구 실행 권한(x)이 없어서다. 이때 초보자들은 답답한 마음에 chmod 777이라는 금단의 주문을 외운다.

# 절대 하지 말아야 할 행동
$ chmod 777 myscript.sh

777은 “나도, 너도, 지나가는 개도 이 파일을 수정하고 실행할 수 있게 하라”는 뜻이다. 보안 대문을 활짝 열어젖히는 행위다. 실무에서는 절대 금물이다. 필요한 권한(chmod +x 등)만 최소한으로 부여하는 습관을 들여야 한다.

*‘chmod 777’은 편하지만, 해커에게도 편한 길을 열어주는 것이다.*

실무 조언: 터미널 공포증 극복하기

입사 초기, 사수님은 서버 접속 툴로 PuTTY를 쓰라고 했다. 하지만 나는 인터넷 검색으로 MobaXterm이라는 더 좋은 툴을 찾아냈다. 이 프로그램은 SSH 접속만 해도 왼쪽에 내 컴퓨터 탐색기처럼 파일 목록(SFTP)을 띄워줬기 때문이다.

덕분에 나는 터미널 명령어를 몰라도 파일을 더블 클릭해서 수정하고 저장하곤 했다. 하지만 그렇게 ‘편법’만 써서는 절대 리눅스와 친해질 수 없다. 긴급한 장애 상황에서 GUI 툴이 켜지길 기다릴 시간은 없으니까.

vi (또는 nano)와 친해져라: 서버 설정 파일(application.yml 등)을 고칠 때마다 마우스로 열어서 고칠 것인가? vi 편집기로 서버에서 바로 수정할 수 있어야 퇴근 시간이 빨라진다. 처음엔 단축키가 헷갈려도, i(입력), :wq(저장 후 종료) 두 개만 알면 일단 수정은 할 수 있다.
로그를 두려워 마라 (tail -f): 서버가 죽었을 때 멍하니 있지 말고 tail -f catalina.out (톰캣 로그) 명령어를 쳐라. 화면에 실시간으로 올라오는 로그를 보는 것이 문제 해결의 시작이다.
자동화 스크립트 (Shell Script): 매번 치는 긴 명령어(빌드, 배포, 재시작)를 deploy.sh 파일 하나에 몰아넣어라. “엔터 한 번으로 배포 끝”이라는 로망은 쉘 스크립트에서 시작된다.

마치며: 환경을 지배하는 자

윈도우라는 온실을 벗어나 리눅스라는 야생에 적응하는 것은 고통스럽다. 하지만 그 고통을 넘어서면, 마우스로는 절대 할 수 없는 강력한 제어권이 손에 들어온다.

리눅스는 이제 더 이상 미지의 영역이 아니다. 하지만 여전히 근본적인 문제가 남아있다. 내 노트북(개발 환경)에는 자바 17이 깔려 있는데, 리눅스 서버(배포 환경)에는 자바 8이 깔려 있다면? 혹은 리눅스에는 있는데 내 윈도우에는 없는 라이브러리가 있다면?

“내 컴퓨터에선 되는데요?”라는 변명은 OS 차이와 라이브러리 버전 차이에서 온다. 이 환경 차이를 아예 없앨 수는 없을까? 내 노트북 환경을 그대로 얼려서 서버로 가져갈 수는 없을까?

이 말도 안 되는 상상을 현실로 만든 기술이 있다. 다음 시간에는 가상화를 넘어 컨테이너 혁명을 일으킨 도커(Docker)에 대해 이야기해 보자.