05. 운영 서버에서 조심할 명령 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 운영 서버에서 위험한 명령은 왜 단순한 명령 실수가 아니라 장애 원인이 되는가?
• rm, chmod, chown, kill, reboot, firewall 변경 전에 무엇을 확인해야 하는가?
• 변경 명령을 안전하게 실행하려면 어떤 기록과 rollback 계획이 필요한가?

개요

운영 서버에서 명령은 코드 배포만큼 위험할 수 있다.

한 줄의 rm, chmod, chown, kill, systemctl restart, firewall 변경으로 서비스가 중단되거나 복구 증거가 사라질 수 있다.

중요한 것은 명령을 무조건 피하는 것이 아니라 읽기 명령, 영향 범위 확인, 백업 또는 rollback, 실행 기록을 갖춘 뒤 변경하는 것이다.

읽기 명령과 변경 명령

운영 서버 명령은 먼저 둘로 나눈다.

읽기 명령:

• ls
• ps
• ss
• df
• du
• journalctl
• systemctl status
• cat, head, tail

변경 명령:

• rm
• mv
• chmod
• chown
• kill
• systemctl restart
• reboot
• iptables, ufw, firewall-cmd
• package upgrade

장애 중에는 읽기 명령으로 상태를 먼저 고정한다.

변경 명령은 대상, 영향, 되돌리는 방법을 확인한 뒤 실행한다.

삭제 명령

rm -rf는 운영 서버에서 가장 조심해야 하는 명령 중 하나다.

위험한 패턴은 다음이다.

rm -rf /var/log/order-api/*
rm -rf $DEPLOY_DIR/*
find /tmp -type f -delete

변수가 비어 있거나 경로를 잘못 잡으면 전혀 다른 대상이 삭제될 수 있다.

삭제 전에는 반드시 대상 목록을 먼저 출력한다.

echo "$DEPLOY_DIR"
find /var/log/order-api -type f -mtime +14 -print

로그 삭제는 장애 증거를 없앨 수 있으므로 압축, 이동, 보존 기간을 먼저 판단한다.

권한 변경

chmod -R과 chown -R은 넓은 범위를 한 번에 바꾼다.

sudo chmod -R 777 /opt/order-api
sudo chown -R app:app /

이런 명령은 운영 사고로 이어질 수 있다.

권한 문제는 필요한 파일과 디렉터리를 좁혀서 바꾼다.

sudo chown app:app /opt/order-api/order-api.jar
sudo chmod 640 /etc/order-api/order-api.env

Secret 파일을 넓게 열면 서비스는 살아나도 보안 사고가 된다.

프로세스 종료와 재시작

kill -9와 systemctl restart는 즉시 효과가 있어 보이지만 원인을 지울 수 있다.

먼저 어느 프로세스인지 확인한다.

ps -fp <pid>
cat /proc/<pid>/cmdline | tr '\0' ' '
systemctl status order-api

systemd가 관리하는 서비스는 되도록 service 단위로 stop/start한다.

sudo systemctl stop order-api
sudo systemctl start order-api

재시작 전에는 in-flight request, batch, migration, file upload, queue consumer 여부를 확인한다.

원인 모를 재시작은 장애 회고에서 가장 약한 증거를 남긴다.

Firewall 변경

방화벽 명령은 접속 경로를 끊을 수 있다.

sudo ufw deny 22
sudo iptables -F

이런 명령은 SSH를 차단하거나 모든 방화벽 규칙을 지워 예상치 못한 노출을 만들 수 있다.

방화벽 변경 전에는 다음을 확인한다.

• 현재 SSH 세션 유지
• 새 SSH 접속 시험
• 현재 규칙 백업
• 변경 후 확인 명령
• rollback 명령

실행 전 체크리스트

변경 명령을 실행하기 전 다음 질문에 답한다.

• 대상 서버와 환경이 prod가 맞는가?
• 명령 대상 경로가 정확한가?
• 변수 값이 비어 있지 않은가?
• 명령이 삭제, 권한 변경, 재시작, 접속 차단을 일으키는가?
• 사용자 영향이 있는가?
• 실행 전 상태를 기록했는가?
• 되돌리는 명령이나 백업이 있는가?
• 누가 승인했고 누가 관찰하는가?

안전한 실행 패턴

변경 전에 dry-run 또는 출력 명령을 먼저 둔다.

find /var/log/order-api -type f -mtime +14 -print

그 다음 대상이 맞으면 변경한다.

find /var/log/order-api -type f -mtime +14 -name '*.gz' -delete

systemd 변경은 실행 전후를 남긴다.

systemctl status order-api
sudo systemctl restart order-api
systemctl status order-api
journalctl -u order-api --since "5 minutes ago" --no-pager

명령과 결과를 incident timeline에 남기면 다음 판단이 쉬워진다.

장애 신호

• 명령 실행 직후 SSH 새 접속이 실패한다.
• chmod -R 후 Secret 파일이 world-readable이 된다.
• 로그 삭제 후 장애 시간대 증거가 사라진다.
• kill -9 후 lock 파일이 남아 재시작이 실패한다.
• systemctl restart 후 서비스가 start-limit에 걸린다.
• package upgrade 후 Java version이 바뀌어 애플리케이션이 뜨지 않는다.

하지 말아야 할 대응

• 대상 확인 없이 rm -rf를 실행한다.
• 권한 문제를 넓은 chmod 777로 덮는다.
• 원인 확인 전 reboot부터 한다.
• maintenance window 없이 Java, Nginx, systemd, kernel package를 upgrade한다.
• 장애 로그를 보존하지 않고 삭제한다.
• 방화벽 변경 후 새 SSH 접속을 시험하지 않는다.
• 운영 서버에서 개인 판단으로 package upgrade를 실행한다.

인프라 담당자와 공유할 자료

명령: sudo systemctl restart order-api
실행 시각: 16:12 KST
실행자: joseph
사전 상태: p95 4s, Hikari pending 40, process alive
실행 이유: stuck thread 의심, 배포 중지 상태
결과: restart 후 health fail, journal에 EnvironmentFile missing
다음 요청: env 파일 복구와 unit 상태 확인

운영 명령은 결과뿐 아니라 실행 이유와 사전 상태가 중요하다.

실전 팁

• prod에서는 prompt나 hostname으로 환경을 눈에 띄게 구분한다.
• 명령을 붙여넣기 전에 경로와 변수 값을 echo로 확인한다.
• 긴 명령은 동료 리뷰나 change ticket에 먼저 적는다.
• 변경 명령 전후에 읽기 명령을 붙여 상태 차이를 남긴다.
• 장애 중에는 “조치한 사실”보다 “조치 전후 지표 변화”를 기록한다.

확인 질문

확인 질문

• 운영 서버에서 읽기 명령과 변경 명령을 구분해야 하는 이유는 무엇인가?
  • 읽기 명령은 증거를 모으지만 변경 명령은 서비스 상태와 복구 가능성을 바꾸므로 승인, 기록, rollback이 필요하기 때문이다.
• rm이나 로그 정리 전에 확인해야 할 것은 무엇인가?
  • 대상 경로, 삭제 대상 목록, 장애 증거 보존 필요성, 프로세스가 파일을 잡고 있는지, backup 또는 rollback 가능성이다.
• systemctl restart를 반복하면 위험한 이유는 무엇인가?
  • 원인 로그가 밀리고 restart loop나 DB 연결 폭주를 만들 수 있으며, 장애 원인을 지우는 조치가 될 수 있기 때문이다.

참고 문서

• Linux man-pages, rm