개인 LLM 서비스를 서버로 옮기면서 복구 경로도 같이 정리했다

개인적으로 쓰는 LLM 기반 서비스를 클라우드 서버로 옮겼다. 옮길 파일이 많았고, 전송이 중간에 멈출 수도 있었다. 파일을 전부 다시 보내야 하는 상황을 피하려고 이어서 전송할 수 있는 구조를 준비했다.

작업은 내가 구조를 정하고 AI 코딩 에이전트에 나눠 맡기는 방식으로 진행했다. 구현한 뒤에는 이전과 호출이 실제로 되는지 확인했다.

파일을 옮기고 복구본을 남겼다

전송이 끊겼을 때 이어 가는 것과 데이터가 잘못됐을 때 되돌리는 것은 다른 일이다. 그래서 중단 후 이어서 전송하는 구조와 별도로 데이터베이스 복구본도 보관했다.

이전을 시작한 것만으로 끝난 건 아니다. 전송이 중단됐다가 다시 진행되는지, 필요한 데이터가 대상 서버에 있는지도 살펴봐야 했다. 파일 수가 많을수록 어디까지 진행됐는지 확인하는 일이 중요했다.

모델 호출 경로를 바꿨다

LLM 호출은 서버 중계와 역방향 SSH 터널을 이용하는 구조로 바꿨다. 역방향 SSH 터널은 떨어진 장비 사이에 통신 경로를 열어 원격 서버에서 다른 쪽의 서비스를 이용하도록 하는 방식이다.

터널 연결이 끊기면 자동으로 다시 연결되도록 구성했다. 확인 기록에서는 재연결까지 약 6초가 걸렸다. 내가 구성한 환경에서 확인한 시간이고, 모든 장애가 그 안에 복구된다는 뜻은 아니다.

한 번 연결된 뒤에도 볼 것

이전한 서버에서 모델 호출이 되는 것까지 확인했다. 그렇지만 한 번 연결되는 것과 계속 안정적으로 운영되는 것은 다르다. 전송을 이어 가는 장치, 복구본, 자동 재연결은 각각 다른 상황에 대비한 것이다.

개인 프로젝트라 해도 서버가 멈추거나 연결이 끊기면 다시 살펴봐야 한다. 이번에는 어디서 이어서 시작할지, 연결이 돌아왔는지를 확인할 수 있도록 경로를 정리해 뒀다.