요약
단체 홈페이지와 신청 시스템이 한 서버에서 같이 돌고 있다. 새로 쓰려는 도구가 “버전이 낮다”며 경고를 낸다. 여기서 시스템 전체 버전을 올려버리면 멀쩡하던 신청 폼이 같이 멈출 수 있다.
답은 올리지 않고 덧대는 것이다. 기존 버전은 그대로 두고 새 버전을 따로 깔아, 새 도구만 그 위에서 돌린다. 이 글은 그 판단을 어떻게 내리는지, 무엇을 보고 안전하다고 확신하는지를 다룬다.
왜 이 기술인가
작은 단체의 서버 한 대에는 보통 여러 개가 얹혀 있다. 홈페이지, 신청 접수 API, 위키, 가끔 자동화 스크립트. 각각 다른 사람이 다른 시기에 올린 것이라 무엇이 무엇에 의존하는지 아무도 정확히 모른다.
이 상태에서 “버전이 낮다”는 경고를 보고 반사적으로 업그레이드하면, 멀쩡하던 것이 조용히 멈춘다. 더 나쁜 건 언제 멈췄는지 모른다는 점이다. 신청 폼은 누가 신청을 시도하기 전까지 고장 난 티가 나지 않는다.
그래서 순서가 필요하다. 올리기 전에 누가 그 버전을 쓰고 있는지 세는 것이 먼저다.
단계별 따라하기
1단계. 무엇이 그 도구를 쓰는지 센다
이름으로 짐작하면 틀린다. 실제로 겪은 사례에서, 사업명-api라는 이름의 서비스는 짐작과 달리 전혀 다른 언어(Python)로 돌고 있었다. 이름은 만든 사람의 사정일 뿐이다.
서버에 올라가 있는 서비스 목록을 본다.
ls /etc/systemd/system/*.service그중 의심되는 것들의 실행 줄을 직접 읽는다.
grep -H "ExecStart" /etc/systemd/system/서비스이름.service나오는 줄이 그 서비스가 실제로 실행하는 명령이다. 여기에 문제의 도구가 들어 있는지, 어떤 경로로 부르는지를 본다.
2단계. “경로”를 본다 — 이게 판단의 핵심이다
실행 줄의 경로가 두 종류로 갈린다.
| 실행 줄 | 뜻 |
|---|---|
/usr/bin/도구 처럼 절대경로 | 시스템에 깔린 그 버전만 씀. 내 계정에 뭘 깔든 상관없음 |
| 로그인해서 수동으로 띄운 프로세스 | 내 계정 설정을 따라감. 영향 받을 수 있음 |
여기서 알아둘 것이 하나 있다. 서버에서 서비스를 자동으로 띄우는 관리자(systemd)는 개인 계정의 설정 파일을 읽지 않는다. 내가 로그인했을 때만 적용되는 설정과, 서비스가 부팅 시 쓰는 환경은 애초에 분리돼 있다.
그래서 systemd로 등록된 서비스라면, 내 계정에 새 버전을 깔아도 그 서비스는 계속 옛 버전을 쓴다. 이게 “덧대기”가 안전한 이유다.
위험한 경우는 하나뿐이다. 누군가 로그인한 셸에서 직접 띄워둔 프로세스. 이건 나중에 재시작할 때 새 버전을 물 수 있다. 1단계의 목록에 그런 게 없는지만 확인하면 된다.
3단계. 시스템 대신 내 계정에 새 버전을 깐다
언어마다 “버전 매니저”라는 도구가 있다. 시스템 설치와 별개로, 내 계정 안에 여러 버전을 두고 골라 쓰게 해준다. 설치도 삭제도 내 홈 디렉터리 안에서만 일어난다.
순서에서 하나만 지키면 된다. 새 버전을 깔기 전에, 옛 버전 쪽에 잘못 설치해둔 도구를 먼저 지운다. 안 그러면 나중에 “지금 실행되는 게 어느 쪽 것인지” 알 수 없게 된다.
4단계. 검증은 “새 것”이 아니라 “옛 것”을 본다
새 버전이 깔렸는지 확인하는 건 쉽고, 대개 맞다. 정작 봐야 할 것은 반대쪽이다.
/usr/bin/도구 --version이 값이 작업 전과 똑같아야 한다. 이게 이 작업의 성공 조건이다. 새 버전이 깔린 것보다, 옛 버전이 그대로인 것이 중요하다.
그다음 서비스가 살아 있는지와 바깥에서 사이트가 열리는지를 확인한다.
systemctl is-active 서비스이름curl -sS -o /dev/null -w "%{http_code}\n" "https://우리사이트주소/"active와 200이 나오면 끝이다.
5단계. 되돌리는 법을 작업 전에 말해둔다
버전 매니저는 홈 디렉터리 한 곳에만 설치되므로, 그 디렉터리를 지우고 설정 파일에 추가된 몇 줄을 빼면 원상복구된다. 시스템은 처음부터 건드리지 않았으니 그걸로 끝난다.
이 문장을 작업을 시작하기 전에 공유하는 것이 중요하다. 되돌릴 수 있다는 걸 알면 결정이 빨라지고, 혼자 결정하지 않아도 된다.
교훈
“버전을 올린다”와 “새 버전을 쓴다”는 다른 일이다. 우리가 원한 건 대개 후자다. 도구 하나가 새 버전을 요구한다고 해서 서버 전체를 바꿀 이유는 없다. 요구한 그 도구에게만 새 버전을 주면 된다.
경고 메시지는 차단이 아니다. 실제 사례에서 설치 명령은 “버전이 안 맞는다”는 경고를 내면서도 성공했다고 출력했다. 성공 메시지만 보고 넘어가면, 맞지 않는 환경에서 도구가 돌고 있다는 걸 모른 채 지나간다. 경고는 읽어야 한다.
이름 말고 실행 줄을 읽는다. 서비스 이름, 파일 이름, 폴더 이름은 전부 과거의 사정이다. 지금 무엇이 실행되는지는 실행 줄에만 적혀 있다.
명령을 어느 컴퓨터에 넣는지 본다. 같은 사례에서 업그레이드 명령이 엉뚱한 기계에 들어가, 정작 문제의 컴퓨터는 그대로이고 손댈 필요 없던 서버만 바뀐 일이 있었다. 터미널 맨 앞 글자로 구분된다 — 사용자@서버이름:~#이면 원격 서버, PS D:\폴더>면 내 윈도우 컴퓨터다.
AI에게 맡길 때: 서버 비밀번호는 넘기지 않는다. AI에게는 확인할 명령을 만들고 결과를 읽어 판단하는 일을 시키고, 실행은 사람이 한다. 실제로 이 사례에서도 AI는 서버에 접속하지 못한 채, 유닛 파일 두 개의 실행 줄만 보고 “안전하다”는 판단과 절차를 만들었다. 판단에 필요한 건 접속 권한이 아니라 올바른 질문이었다.
참고
- 서비스가 자동 실행되는 방식(systemd)과 내가 로그인했을 때의 환경은 분리돼 있다 — 이 사실 하나가 “덧대기”의 근거다
- 관련 문서: 설정은-켰는데-왜-안-되나-캐시된-정책과-앱-재시작 — 설정이 반영되지 않을 때의 점검 순서
- 관련 문서: 배포했는데-라이브가-아니다-사슬을-끝까지-확인하는-법
문서 정리 = 데카(deka2026)