150명을 어떻게 옮겼는가 — 기술보다 어려웠던 부분 (Part 11)

개요

• 병행 운영 기간을 충분히 뒀다. 신규 접속을 IPsec으로 열고 SSL VPN을 남겨둔 채 사용자를 옮겼다.
• 전환 순서: 본인 → IT 인접 인원 → 협조적 소수 → 부서 단위 → 잔여 인원. 각 단계에서 멈출 수 있게 설계했다.
• 문의는 기술 문제보다 "어떻게 하는지 모른다"가 압도적으로 많았다. 대응은 안내문 축약이었다.
• 롤백 기준을 숫자로 미리 정해뒀다. 정하지 않으면 판단이 감정으로 흐른다.

이 글은 누구를 위한 글인가

기술 검증은 끝났고 이제 실제 사용자를 옮겨야 하는 사람. 특히 담당자가 본인 한 명인 경우.

읽고 나면 무엇을 미리 준비해야 문의 폭주를 피할 수 있는지 알게 된다.

1. 가장 중요한 결정: 병행 운영

전환 방식은 두 가지다.

방식장점단점

일괄 전환 (특정일에 SSL VPN 종료)	짧고 명확, 관리 부담 짧음	실패 시 전원 영향
병행 운영 후 점진 전환	롤백 가능, 문제 조기 발견	기간이 길고 두 시스템 관리

병행을 골랐다. 이유는 하나다. 1인 담당 체제에서는 전원 장애를 감당할 수 없다.

150명이 동시에 접속 불가가 되면, 원인 파악과 문의 응대를 동시에 해야 한다. 그건 물리적으로 불가능하다. 반면 5명이 안 되면 5명을 SSL VPN으로 되돌리고 차분히 원인을 본다.

병행 운영의 대가는 관리 부담이지만, 그건 예측 가능한 비용이다. 전원 장애는 예측 불가능한 비용이다.

SSL VPN 터널 모드가 제거되는 것은 7.6.3부터다. 현재 7.4 브랜치에 있다면 병행 기간을 확보할 여지가 있다. 이 여유를 쓰지 않는 건 아깝다. 반대로 이미 7.6.3 이상이라면 이 선택지가 없으므로, 업그레이드 전에 전환을 끝내야 한다.

2. 전환 순서 — 각 단계에서 멈출 수 있게

단계대상인원이 단계에서 확인한 것

0	나 자신	1	기본 동작, 여러 네트워크 환경
1	시스템팀 인접 인원	3~4	안내문 없이도 되는지
2	협조적 자원자	8~10	안내문 초안의 실효성
3	부서 단위	20~30	문의 유형 수집, 처리 시간 측정
4	잔여 인원	나머지	예외 케이스 처리

핵심은 단계 2와 3 사이에 시간을 충분히 뒀다는 점이다.

단계 2에서 나온 피드백으로 안내문을 다시 썼다. 이게 없으면 단계 3에서 같은 문의를 30번 받는다. 1인 담당에서 같은 문의를 30번 받는 건 그 자체가 장애다.

단계 3의 부서 선정 기준도 정했다.

• 외부 접속 빈도가 높은 부서를 먼저 (문제가 있으면 빨리 드러난다)
• 단, 마감이 촉박한 시기는 피한다
• 해당 부서에 협조적인 사람이 최소 1명 있어야 한다

세 번째가 실질적으로 중요하다. 부서 내부에 물어볼 사람이 있으면 내게 오는 문의가 절반으로 줄어든다. 단계 2의 자원자를 각 부서에 흩어 배치했다.

3. 공지문 — 세 종류를 따로 썼다

수신자에 따라 완전히 다르게 썼다. 하나로 쓰려는 시도는 실패한다.

3.1 전체 사용자용 (사내 게시판)

기술 내용을 전부 뺐다. 필요한 정보만.

 

[안내] VPN 접속 방식 변경

■ 무엇이 바뀌나요
  원격 접속에 사용하는 프로그램이 바뀝니다.

■ 언제까지 해야 하나요
  <날짜>까지 새 방식으로 전환 부탁드립니다.
  기존 방식은 <날짜>에 종료됩니다.

■ 어떻게 하나요
  아래 링크에서 설치 파일과 안내서를 받으세요.
  <포털 링크>
  소요 시간: 약 10분

■ 달라지는 점
  비밀번호를 입력할 때, 뒤에 OTP 6자리를 이어서 입력합니다.
  (예: 비밀번호가 abc123, OTP가 456789 → abc123456789)

■ 안 될 때
  안내서 4페이지를 먼저 확인해 주세요.
  해결되지 않으면 <연락처>

"왜" 바뀌는지는 쓰지 않았다. 벤더가 기능을 제거해서라는 설명은 사용자에게 아무 행동 지침을 주지 않는다. 첫 버전에는 배경 설명을 넣었는데, 읽는 사람이 줄었다.

OTP 입력 방식만 예시로 못 박았다. 이게 문의의 대부분을 만들 것을 알고 있었다. (알았지만 예상보다 많았다.)

3.2 팀장 보고용 (간단히)

전달 경로가 메신저였으므로 짧게.

 

VPN 전환 진행 상황 공유드립니다.

- 신규 방식 접속 테스트 완료, 현재 <N>명 전환됨
- 기존 방식도 <날짜>까지 병행 운영되므로 업무 영향 없습니다
- 부서별 안내는 <날짜>부터 순차 진행 예정
- 특이사항 없습니다

한 항목 한 줄. 상세 설명은 대면으로 한다. 문서에 길게 쓰면 읽히지 않고, 중간의 중요한 한 줄이 묻힌다.

3.3 벤더 문의용 (별개 문서)

기술 내용을 전부 담는다. 로그 원문, 재현 절차, 이미 시도한 것 목록. 여기서 축약하면 왕복이 늘어난다.

이미 시도한 것을 명시적으로 나열하는 게 특히 중요하다. 이걸 안 쓰면 첫 답변으로 이미 해본 것을 다시 제안받는다.

4. 실제 문의 유형 — 상위 5개

집계 결과다.

순위문의 내용비중실제 원인

1	"OTP를 어디에 입력하나요"	압도적 1위	안내문 이해 부족
2	"접속이 안 됩니다" (실제로는 설치 미완료)	높음	프로파일 가져오기 단계 누락
3	"가끔 끊깁니다"	중간	클라이언트 환경 (Part 9)
4	"밖에서는 안 됩니다"	중간	UDP 차단 환경 (Part 8)
5	"예전 걸로 쓰면 안 되나요"	소수	전환 저항

1위에 대한 대응

별도 OTP 입력창이 없다는 걸 사용자가 예상하지 못한다. 이건 사용자의 문제가 아니라 인터페이스가 기대와 다른 문제다.

세 번 고쳤다.

1. 안내문에 텍스트로 설명 → 효과 미미
2. 굵은 글씨 + 빨간 박스 → 조금 개선
3. 실제 입력 화면 캡처에 화살표와 예시 문자열을 그려 넣음 → 문의 대폭 감소

텍스트로 세 번 설명하는 것보다 이미지 한 장이 낫다. 이걸 처음부터 했어야 했다.

5위에 대한 대응

"예전 걸로 쓰면 안 되나요"는 기술 문의가 아니다. 두 가지로 답했다.

• 기존 방식은 장비 제조사가 기능을 제거해서 종료된다 (선택 사항이 아니다)
• 전환 후 문제가 있으면 함께 해결한다 (혼자 남겨두지 않는다)

두 번째가 실제로 효과가 있었다. 저항의 상당 부분은 "바뀌면 나 혼자 감당해야 한다"는 불안이었다.

5. 롤백 계획 — 숫자로 미리 정했다

전환 시작 전에 중단 기준을 정해서 문서에 적었다. 이걸 안 하면 판단이 감정으로 흐른다. 문의가 몰리는 날에는 "이거 되돌려야 하나"가 계속 머릿속에 있고, 기준이 없으면 하루 종일 그 생각을 한다.

조건조치

한 단계에서 실패율 30% 초과	다음 단계 중단, 원인 파악 후 재개
동일 원인 문의가 5건 이상	안내문/설정 수정 후 재개
원인 불명 접속 실패 발생	해당 사용자만 기존 방식으로 되돌리고 조사
기존 방식에 영향 발생	즉시 전체 중단

마지막 항목이 가장 중요하다. 신규 방식 작업이 기존 방식을 망가뜨리면 그건 즉시 중단 사유다. 병행 운영의 전제가 무너지기 때문이다.

개별 사용자 롤백 절차도 미리 만들어뒀다.

 

1. 해당 사용자에게 기존 방식 접속 안내 (계정은 그대로 유효)
2. 실패 상황 기록: 시각 / 네트워크 환경(유선·무선·테더링) / 오류 메시지 / 클라이언트 로그
3. 진단 스크립트 실행 결과 수집 (Part 9)
4. 원인 확인 후 재전환

2번의 "네트워크 환경"을 첫 항목으로 올린 것은 Part 9의 교훈이다. 이 정보 하나가 원인 범위를 크게 좁힌다.

6. 계정 준비 — 스크립트로 감쌌다

150개 계정을 수동으로 만들 수는 없다.

 

bash

# /usr/local/bin/useradd.sh <username> <group>
# - 비밀번호 입력받아 해시 저장
# - TOTP 시크릿 생성
# - QR 코드 출력 (사용자 등록용)
# - 그룹에 따라 authorize 항목 추가
# - 처리 결과를 로그에 기록

삭제 스크립트도 같이 만들었다. 생성 스크립트만 만들고 삭제를 수동으로 하면, 퇴사자 계정이 남는다. 이건 시간 문제가 아니라 확실성 문제다.

 

bash

# /usr/local/bin/userdel.sh <username>
# - authorize에서 제거
# - 비밀번호/TOTP/모드 파일 삭제
# - IP 풀 세션 정리
# - 삭제 이력 로그

계정 정리를 정기 작업으로 넣었다. 인사 데이터와 대조해서 유효하지 않은 계정을 찾는다. 이 작업을 안 하면 6개월 뒤에 유령 계정이 쌓인다.

7. 되돌아보면 잘한 것 / 못한 것

잘한 것

• 병행 운영 기간 확보. 이게 없었다면 전환을 시작하지 못했을 것이다.
• 단계 2와 3 사이에 시간을 둔 것. 안내문을 다시 쓸 수 있었다.
• 롤백 기준을 숫자로 정한 것. 판단할 때 고민하지 않았다.
• 자원자를 각 부서에 흩어 배치한 것. 문의 양을 실질적으로 줄였다.
• 삭제 스크립트를 생성 스크립트와 같이 만든 것.

못한 것

• 클라이언트 환경 사전 조사를 안 했다. Part 9의 문제 전부가 여기서 나왔다. 드라이버 버전 분포만 미리 파악했다면 사전 업데이트로 해결됐다.
• 안내문 이미지를 처음부터 넣지 않았다. 텍스트로 세 번 고치는 동안 받은 문의가 전부 낭비였다.
• 문의를 정량적으로 기록하지 않았다. 초기 문의는 기억에 의존한 집계다. 단순한 스프레드시트라도 처음부터 있었어야 했다.
• UDP/TCP 이원화를 처음부터 하지 않았다. Part 3, 8의 이야기다. 이게 초기 설계에 있었다면 전환 중반의 혼란이 없었다.

8. 여기서 배운 것

• 1인 운영에서 병행 운영 기간은 사치가 아니라 필수다. 전원 장애를 감당할 인력이 없다면 점진 전환만이 가능하다.
• 각 단계에서 멈출 수 있게 설계한다. 멈출 수 없는 계획은 계획이 아니라 도박이다.
• 롤백 기준을 숫자로 미리 정한다. 정하지 않으면 문의가 몰리는 날 판단이 흔들린다.
• 사용자 안내는 텍스트보다 이미지다. 그리고 "왜"보다 "무엇을 하면 되는지"다.
• 전환 저항의 상당 부분은 **"혼자 감당해야 한다는 불안"**이다. 함께 해결한다는 약속이 기술적 설명보다 효과적이었다.
• 삭제 절차를 생성 절차와 동시에 만든다. 나중에 만들면 그 사이에 유령 계정이 쌓인다.
• 문의 유형을 처음부터 기록한다. 나중에 안내문을 고칠 때 근거가 된다.

다음 편에서는

마지막 편. 다시 한다면 무엇을 바꿀지, 그리고 아직 끝나지 않은 것들.