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

한 줄 요약

첫날 막히는 이유는 실력이 아니라 권한입니다. 무엇을 요청해야 하는지
알고 가면 하루를 벌고, 모르면 사흘을 기다립니다.

왜 이게 필요했나

고객사 첫 방문에서 흔한 하루는 이렇습니다. 오전에 소개, 오후에 노트북
반입 승인, 다음 날 VPN 계정, 그다음 날 서버 접근. 실제로 손을 대는 건
나흘째입니다. 이 사흘은 대부분 "무엇이 필요한지 미리 말하지 않아서"
생깁니다.

승인 체계는 대체로 직렬입니다. VPN 승인이 끝나야 계정 신청이 올라가고,
계정이 나와야 권한 신청이 됩니다. 첫날에 전부 동시에 던져야 병렬로 굽니다.

무엇을 요청하는가

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

여기에 하나 더, 가장 자주 빠지는 것 — 테스트 환경이 있는지, 있다면
운영과 무엇이 다른지입니다. "같습니다" 라는 답은 대개 사실이 아닙니다.
데이터 양, 외부 연동, 인증서가 다릅니다.

무엇을 만지지 않는가

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

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

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

특히 세 번째. 재시작은 증상을 지우면서 증거도 함께 지웁니다. 재시작이
필요하더라도 그 전에 상태를 남깁니다 — 프로세스 목록, 메모리, 열린 파일,
최근 로그. 이 스냅샷 하나가 나중에 보고서의 절반이 됩니다.

신뢰는 첫 주에 결정된다

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

작은 것을 빨리 돌려준다 — 사흘짜리 분석보다 한 시간짜리 확인 결과가

먼저 나가야 합니다.

모르는 것을 모른다고 말한다 — 추측을 사실처럼 말하면 한 번에 잃습니다.
약속한 시각에 보고한다 — 진전이 없어도 "아직 없음"을 제시간에.

현장에서 만나는 모습

조사하다 로그가 20일치뿐인 걸 알게 됨 → 첫날 보존 기간을 물었으면 조사

범위를 다르게 잡았을 일.

문제를 찾았는데 고칠 권한이 없음 → 변경 절차를 미리 확인하지 않은 결과.
재시작으로 증상이 사라져 원인 미상으로 종결 → 스냅샷 없이 재시작한 대가.

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

접근·보존 기간·변경 승인처럼 첫날 확보할 정보가 이후 영향 범위 판단을
어떻게 바꾸는지 살펴보고, 다음 이론에서 변경 전 확인 대상을 확장합니다.