고객사에 도착해서 처음 요청할 것들

한 줄 요약

첫날 막히는 이유는 실력이 아니라 권한입니다. 무엇을 요청해야 하는지 알고 가면 하루를 벌고, 모르면 사흘을 기다립니다. 그리고 권한을 받았다면 받은 것이 정말 요청한 것인지 그 자리에서 확인합니다.

왜 이게 필요했나

고객사 첫 방문에서 흔한 하루는 이렇습니다. 오전에 소개, 오후에 노트북 반입 승인, 다음 날 VPN 계정, 그다음 날 서버 접근. 실제로 손을 대는 건 나흘째입니다. 그런데 나흘째 로그를 열어 보니 보존 기간이 2주라 고객이 말한 3주 전 장애의 로그는 이미 지워졌고, 문제를 찾았는데 고칠 권한은 읽기뿐이라 변경 신청을 새로 올려야 합니다. 이 지연은 대부분 "무엇이 필요한지 미리 말하지 않아서" 생깁니다.

승인 체계는 대체로 직렬입니다. VPN 승인이 끝나야 계정 신청이 올라가고, 계정이 나와야 권한 신청이 됩니다. 단계마다 결재자가 다르고 결재자마다 하루씩 걸립니다. 그래서 첫날에 전부 동시에 던져야 병렬로 굽니다. 순서를 지켜야 하는 것이라도 "다음에 무엇을 신청할지" 를 미리 알려 두면, 앞 단계가 끝나는 즉시 다음 결재가 올라갑니다.

무엇을 요청하는가

요청	왜 필요한가	자주 빠지는 것
망 접근 (VPN/전용선)	아무것도 못 함	2FA 기기 등록이 별도 절차
계정 + 권한	조회조차 안 됨	읽기 권한과 실행 권한이 따로
서버 목록·구성도	어디를 봐야 할지 모름	최신본이 위키가 아니라 누군가의 PC 에
로그 위치·보존 기간	조사 범위가 결정됨	30일 지나면 없다는 걸 나중에 앎
담당자와 연락 체계	막혔을 때 물어볼 곳	야간·주말 연락 규칙
변경 절차	고치려면 반드시 필요	긴급 변경도 승인이 필요한 경우

여기에 하나 더, 가장 자주 빠지는 것 — 테스트 환경이 있는지, 있다면 운영과 무엇이 다른지입니다. "같습니다" 라는 답은 대개 사실이 아닙니다. 데이터 양, 외부 연동, 인증서가 다릅니다. 운영에서만 나는 문제를 테스트 환경에서 재현하려고 하루를 쓰기 전에, 다른 점의 목록부터 받습니다.

받은 권한을 확인하는 법

계정이 나왔다는 연락을 받으면 접속하자마자 몇 가지를 봅니다. 전부 읽기만 하는 명령이라 낯선 서버에서도 안전합니다.

id; groups                 # which groups this account belongs to
sudo -l                    # what may be run as root, without running it
chage -l "$USER"           # account and password expiry dates
timedatectl                # is the clock synced, which time zone

sudo -l 은 실행 권한을 실제로 쓰지 않고 목록만 보여 줍니다. 여기서 필요한 명령이 빠져 있으면 첫날 바로 추가 신청을 올립니다. chage -l 의 만료일은 의외로 자주 걸립니다. 협력사 계정은 짧게 발급되는 경우가 많아, 조사가 한창일 때 계정이 잠깁니다. 시계와 시간대는 나중에 여러 장비의 로그를 맞춰 볼 때 필요합니다.

로그 보존 기간은 말로 듣지 말고 설정에서 확인합니다. 파일 로그는 대개 logrotate 가 관리합니다. rotate 는 지우기 전에 남겨 둘 개수이고, 회전 주기(daily, weekly)와 곱해야 기간이 됩니다. weekly 에 rotate 4 면 지금 쓰는 파일과 약 4주치의 지난 파일이 남습니다. maxage 가 있으면 그 일수보다 오래된 파일은 개수와 상관없이 지워집니다.

grep -nE 'daily|weekly|monthly|rotate|maxage' /etc/logrotate.conf /etc/logrotate.d/*
journalctl --disk-usage
ls -d /var/log/journal     # absent: the journal may live in memory only
journalctl --list-boots | head -3

systemd 저널은 기간이 아니라 용량으로 지워지는 것이 기본입니다. 기본 상한은 파일 시스템 크기의 10% 이고 최대 4G 이며, 기간 제한(MaxRetentionSec)은 기본으로 꺼져 있습니다. 그래서 로그가 많은 서버일수록 저널이 덮는 기간이 짧아집니다. 더 중요한 함정이 있습니다. 기본 설정(Storage=auto)에서는 /var/log/journal 디렉터리가 있을 때만 디스크에 저장하고, 없으면 메모리에만 둡니다. 그 서버는 재부팅하는 순간 이전 저널이 전부 사라집니다. journalctl --list-boots 에 부팅이 하나뿐이라면 이 경우를 의심합니다.

무엇을 만지지 않는가

첫 주의 기본자세는 읽기만 합니다. 이건 소심함이 아니라 계산입니다. 낯선 시스템에서 변경 하나의 영향 범위를 예측할 수 없기 때문입니다.

만지기 전에 세 가지를 확인합니다.

1. 되돌릴 수 있는가 — 되돌리는 방법을 말로 설명할 수 있어야 합니다.
2. 누가 영향을 받는가 — 이 서버를 누가 쓰는지 모르면 아직 이릅니다.
3. 지금 해야 하는가 — 조사 단계에서 고치기부터 하면 원인을 잃습니다.

특히 세 번째. 재시작은 증상을 지우면서 증거도 함께 지웁니다. 재시작이 필요하더라도 그 전에 상태를 남깁니다 — 프로세스 목록, 메모리, 열린 파일, 최근 로그. 몇 초면 끝납니다.

date -u +%FT%TZ                          # when this snapshot was taken
ps auxf                                  # process tree
free -m                                  # memory
ss -tanp                                 # sockets and their owners
lsof -p "$PID"                           # files the process holds open
journalctl -u "$UNIT" --since "30 min ago"

시각을 먼저 찍는 이유는, 스냅샷이 여럿 쌓이면 어느 것이 재시작 전인지 구별할 수 없게 되기 때문입니다. 이 스냅샷 하나가 나중에 보고서의 절반이 됩니다.

신뢰는 첫 주에 결정된다

기술적으로 옳은 말을 해도, 그 말을 들어 줄 관계가 없으면 아무것도 못 바꿉니다. 첫 주에 신뢰를 만드는 방법은 단순합니다.

• 작은 것을 빨리 돌려준다 — 사흘짜리 분석보다 한 시간짜리 확인 결과가 먼저 나가야 합니다.
• 모르는 것을 모른다고 말한다 — 추측을 사실처럼 말하면 한 번에 잃습니다.
• 약속한 시각에 보고한다 — 진전이 없어도 "아직 없음"을 제시간에.

현장에서 만나는 모습

• 조사하다 로그가 20일치뿐인 걸 알게 됨 → 첫날 보존 기간을 물었으면 조사 범위를 다르게 잡았을 일. 고객에게 "3주 전 장애는 로그로 확인할 수 없다" 는 사실을 첫날 알렸다면 다른 증거(모니터링 지표, 고객 측 기록)를 미리 찾았을 것입니다.
• 서버가 재부팅된 뒤 저널이 텅 빔 → 저장 방식이 메모리였다. 장애 원인이 재부팅 직전에 있었다면 그 기록은 처음부터 남을 수 없었습니다.
• 문제를 찾았는데 고칠 권한이 없음 → 변경 절차를 미리 확인하지 않은 결과. 읽기 권한과 실행 권한이 따로라는 것을 sudo -l 로 첫날 봤다면 막히지 않았습니다.
• 조사 중간에 계정이 잠김 → 협력사 계정의 만료일을 확인하지 않았다.
• 재시작으로 증상이 사라져 원인 미상으로 종결 → 스냅샷 없이 재시작한 대가.

이어지는 학습에서 확인할 것

바로 뒤의 이론에서 변경 전에 무엇이 무엇에 닿는지 그리는 법을 다룹니다. 그 뒤 실습에서 첫날 요청 목록, 보존 기간, 상류와 하류, 공유 상태, 배치 창을 직접 캐내고, 되돌리기 스크립트와 재시작 전 스냅샷 스크립트를 만듭니다. 이 절에서 본 보존 기간 계산과 스냅샷 명령이 그대로 쓰입니다.