[🛠] Operations Automation #3: 레거시 연차 자동화의 NAS 이관과 외부 HTTPS 연결

✨ GPT-5.6 Sol의 요약 　

기존 연차 촉진 기능과 데이터를 새 NAS 환경으로 옮기고, 외부 HTTPS 연결 뒤 실제 모바일 기기에서 드러난 UI 결함까지 고친 기록.

레거시 연차 자동화의 기능과 데이터를 새 NAS 환경으로 가져오고, 외부 HTTPS 요청이 NAS 내부 애플리케이션까지 도달하는 경로를 연결했다. 단순히 container를 띄운 것이 아니라 기존 업무 흐름을 새 운영 환경으로 옮기는 작업이었다.

하지만 새 화면이 뜬다는 것만으로는 이관됐다고 말할 수가 없었다. 직원과 연차 데이터가 보여야 하고, 촉진 대상과 문자 문구가 기존과 같아야 했다. 하루 130건을 넘긴 문자는 다음 날로 넘어가야 했고 발송 대기열과 이력도 이어져야 했다. 하나라도 빠지면 이름만 바뀐 다른 서비스가 된다.

앞서 영업 자동화와 직원 행정을 다시 나누면서 기존 연차 촉진 기능은 먼저 재현한 뒤 옮기기로 했다. 막상 시작해 보니 그 순서가 더 중요했다. NAS 배포는 잠시 뒤로 미뤘다.

로컬 기능 재현과 데이터 복원

FastAPI, Next.js, MariaDB를 격리된 로컬 Compose 환경에서 먼저 실행했다. 기존 서비스와 부딪히지 않도록 port, network, volume과 credential도 따로 잡았다. 관리자 로그인을 하고 직원·연차 데이터를 열어 본 다음, 촉진 대상과 생성된 문구, 130건 제한을 넘긴 예약 건, queue와 이력을 기존 흐름과 맞춰 봤다.

운영 DB에 바로 손대고 싶지는 않았다. 기존 SQL backup을 별도 MariaDB에 복원한 뒤 schema와 핵심 table count를 비교했다. backend를 다시 띄운 뒤에도 데이터가 남아 있는지 봤다. 여기까지 되고 나서야 로컬 동작 기준이 생겼다. 이후 NAS에서 문제가 나면 코드가 달라진 것인지, image나 network가 잘못된 것인지 나눠 볼 수 있었다.

backup이 복원됐다는 사실만으로 운영 전환이 끝난 것은 아니었다. 관리자 계정도, 업무폰도, 실제 문자도 아직 새 경로를 통과하지 않았다.

실제 SMS 발송 경로의 이중 제한

그다음 막히는 지점은 실제 SMS였다. 문자를 보내지 않으면 Android 업무폰까지 이어지는 경로를 끝까지 볼 수 없다. 그렇다고 production 발송을 열어 놓고 시험할 수도 없었다.

그래서 server의 발송 mode부터 세 개로 갈랐다.

NO_SEND
ALLOWLIST_SEND
PRODUCTION

평소에는 NO_SEND다. 시험할 때만 허용한 수신자 한 명을 ALLOWLIST_SEND에 넣었다. 전화번호 원문 대신 SHA-256 hash로 대상을 맞췄고 server가 가져갈 수 있는 건수를 1건으로 제한했다. Android 앱 안에도 별도의 1건 budget을 넣었다. server와 앱 중 한쪽을 잘못 다뤄도 두 번째 문자는 나가지 않게 하고 싶었다.

이 상태는 코드만 보고 넘기지 않았다. Computer Use로 실제 관리 화면을 열어 NO_SEND, 지금 claim 가능한 건수, queue와 이력을 확인했다. 같은 화면에서 Codex의 작업 결과와 구현 코드도 같이 대조했다.

운영 앱을 그대로 건드리지 않도록 테스트 package도 따로 만들었다. USB로 연결한 Android 기기에는 adb reverse로 로컬 endpoint를 붙였다. 그렇게 실제 문자 한 건이 SUCCESS로 끝났고 수신 기기에서도 도착한 문자를 봤다.

여기서 애매한 결과도 하나 나왔다. 사용자는 문자를 받았지만 Android delivery callback은 잡히지 않았다. SUCCESS는 통신사 발송 요청이 접수됐다는 뜻이지, delivery callback까지 끝났다는 뜻은 아니었다. 실제 수신과 callback 상태를 같은 성공으로 묶으면 나중에 UNKNOWN 건을 어떻게 다룰지 더 헷갈릴 것 같았다.

한 건을 본 뒤에는 곧바로 NO_SEND로 돌렸다. Android readiness는 0, server claim은 204 No Content가 나왔다. 테스트가 한 번 더 눌리더라도 다음 문자가 없다는 상태에서 끝냈다.

linux/amd64 Docker 이미지의 NAS 이관

NAS에는 전체 자동화 플랫폼이 아니라 연차 자동화 서비스만 따로 올렸다. NAS에서 source를 다시 build하지 않고 Mac에서 linux/amd64 image를 만든 뒤 hash를 확인해 옮겼다. Compose project도 기존 stack과 분리했다. backend 하나를 교체할 때 MariaDB와 Frontend까지 같이 다시 만들어지지 않게 하려는 구성이었다.

외부 HTTPS와 Reverse Proxy 연결

새 주소로 로그인 화면이 열리고 기존 직원·연차 데이터도 보였다. 그런데 외부 브라우저에서 MariaDB까지 요청이 어떻게 들어가는지 글만으로는 한눈에 잡히지 않았다. 특히 3101이 인터넷에 열린 port인지, NAS 안에서만 쓰는 port인지 설명할 때 자꾸 경계가 섞였다. 요청 경로를 그림으로 옮겨 봤다.

그림으로 놓고 보니 외부에 필요한 것은 HTTPS 443 하나였다. Router가 443을 NAS로 넘기고, NAS reverse proxy가 hostname을 보고 127.0.0.1:3101의 Frontend로 보낸다. Backend 8000과 MariaDB 3306은 Docker network 안에서만 연결된다. 3101도 NAS loopback에만 묶여 있으니 인터넷에서 직접 접근할 수 없다.

Cloudflare를 기본 경로에 넣지 않은 것도 같은 이유였다. 이미 쓰고 있는 authoritative DNS와 고정 공인 IP가 있고 Router도 직접 제어할 수 있었다. 서비스용 A record만 추가하고 NAS에서 인증서를 관리하면 중간 구성요소를 하나 줄일 수 있었다. 대신 인증서 갱신과 port forwarding은 직접 관리해야 한다. 인증서 발급·갱신용 80을 제외하면 실제 서비스 요청은 443으로만 받는다.

실제 모바일 기기 검증과 반응형 UI 수정

외부 HTTPS 주소가 열렸다고 이관이 끝난 것은 아니었다. USB로 연결한 실제 Android 기기에서 모바일망으로 새 주소에 접속하고, 로그인부터 대시보드와 직원 목록, SMS 이력, 연차 관리까지 직접 돌아봤다. 화면은 열렸지만 그대로 쓸 수 있는 상태는 아니었다.

PC 브라우저에서 폭만 줄였을 때는 놓쳤던 문제가 실제 기기에서 한꺼번에 보였다. 대시보드는 데스크톱 sidebar가 화면 대부분을 차지해 카드와 글자가 세로로 찌그러졌다.

아래 비교 이미지는 모두 왼쪽이 수정 전, 오른쪽이 수정 후다.

직원 목록에서는 제목과 버튼이 한 글자씩 떨어졌고, 넓은 table은 작은 폭에 억지로 눌려 있었다. 제목과 동작 영역이 가로 흐름을 유지하게 만들고, table은 내용을 찌그러뜨리는 대신 필요한 만큼 가로로 넘겨 볼 수 있게 바꿨다.

SMS 이력과 연차 관리의 filter도 같은 문제였다. 여러 입력칸과 날짜 범위를 한 줄에 욱여넣고 있었다. 작은 화면에서는 두 열을 중심으로 배치하고 날짜 범위는 별도 행으로 내려, 각 항목이 무엇인지 읽고 누를 수 있게 했다.

수정 뒤에는 새 Docker image를 다시 배포하고 같은 휴대폰에서 다시 로그인했다. 메뉴를 열고, 화면을 스크롤하고, 각 filter와 table을 직접 보면서 처음 발견한 결함이 사라졌는지 확인했다. 외부 네트워크가 NAS의 container까지 닿는지만 보려던 검증이 실제 사용 화면까지 고치는 과정으로 이어졌다.

단계별 이관 상태와 관리자 UI/E2E 검증

NAS 이관과 외부 접속, 내부 문자 한 건까지 이어 놓고 전체 로드맵을 다시 펼쳐 보니 1~3단계는 넘어와 있었다. 지금 위치는 개선한 관리자 UI를 새 image로 배포하고, ADB와 실제 기기에서 전 페이지를 다시 보는 4단계였다.

이 그림을 붙여 놓으니 이번 작업의 다음 경계도 선명해졌다. 외부 접속 자체는 이미 통과했지만 관리자 화면의 실기기 재검증이 끝나기 전에는 본사 dogfooding으로 넘어갈 수 없다. 그래서 다음 단계는 새 기능을 더 붙이는 일이 아니라, 수정한 UI가 데스크톱과 모바일 모두에서 같은 업무 흐름을 유지하는지 끝까지 확인하는 것으로 잡았다.

운영 전환 전 안전 상태와 롤백

지금 새 stack은 일부러 자동으로 아무 일도 하지 않게 해뒀다.

ENABLE_SCHEDULER=False
SMS_SEND_MODE=NO_SEND
SMS_ALLOWLIST_MAX_CLAIMS=0

관리자 credential은 Compose나 image에 적지 않았다. NAS에서는 권한이 0600인 secret file로 넣고 Mac에서는 Keychain에 보관했다.

새 주소에서 로그인하고 데이터를 읽을 수 있고, 제한된 조건에서는 문자 한 건도 도착했다. 외부 모바일망에서도 로그인부터 데이터 조회와 화면 조작까지 확인했다. 그래도 기존 연차 문자 서비스를 지우기에는 delivery callback이 없는 건의 복구 방식과 실제 발송 조건 승인이 남아 있다.

그래서 기존 container와 volume은 중지만 하고 그대로 뒀다. 지금 다음으로 필요한 것은 구성을 더 늘리는 일이 아니다. callback이 없는 발송 건을 어떻게 복구할지 정하고, 실제 발송도 승인된 조건에서 제한된 건수부터 여는 것이다.

기술 이관과 별개로, AI가 실제 휴대폰과 공유기·NAS 관리자 화면까지 함께 보게 하며 내가 느낀 변화는 AI를 적극 활용할 줄 알면 할 수 있는 일이 무궁무진해진다에 따로 적었다.