내부 자동화 봇을 클라우드로 옮기며 먼저 정한 경계

여러 내부 자동화 봇이 작은 장비 한 대에서 돌아가고 있었다. 기능에는 문제가 없었지만, 24시간 안정적으로 운영하기에는 한계가 있었다. 클라우드 이전을 검토한 이유는 단순히 실행 장소를 바꾸려는 것이 아니었다. 운영 안정성을 높이는 동시에 접근 경로와 보안 경계를 다시 정할 필요가 있었다.

문제를 다시 정의하기

이전의 핵심은 서버 위치가 아니라 운영 경계를 다시 정하는 일이었다. 외부 플랫폼과 어떻게 연결할지, 운영자가 어떤 방식으로 접근할지, 다른 클라우드 자원과 어디까지 분리할지를 함께 결정해야 했다.

선택지를 나눈 기준

가장 먼저 살핀 것은 외부 요청을 받는 방식이었다. 봇을 실행하려고 인바운드 포트를 열면 운영해야 할 접점이 하나 더 생긴다. 방화벽 설정과 인증, 노출 상태를 계속 관리해야 하고 잘못된 설정이 새로운 위험으로 이어질 수도 있다. 그래서 외부에서 서버로 직접 들어오는 연결을 열지 않고, 봇이 외부 플랫폼과 연결을 맺은 뒤 그 통로로 이벤트를 받는 방식을 택했다. 필요한 기능은 유지하면서 공개해야 할 진입점을 줄이는 선택이었다.

데이터 저장 방식도 같은 기준으로 판단했다. 별도 데이터베이스를 붙이면 확장성과 관리 기능은 좋아지지만, 당시 봇이 다루는 상태를 보관하기에는 의존성이 커진다. 연결 정보와 권한, 장애 지점도 함께 늘어난다. 현재 범위에서는 로컬 JSON 파일로 충분하다고 보고 외부 데이터베이스를 두지 않았다. 모든 시스템에 같은 구성이 필요한 것은 아니다. 규모가 작을 때는 단순한 구조 자체가 운영상의 이점이 된다.

내린 결정과 실행

접근 방법은 편의보다 추적 가능성을 우선했다. 개인이 보관하는 SSH 키로 서버에 접속하면 당장은 익숙하지만, 누가 언제 어떤 권한으로 접근했는지 일관되게 남기기 어렵다. 키를 배포하고 회수하는 일도 별도로 관리해야 한다. 이 문제를 피하려고 클라우드의 계정·권한 관리 체계와 원격 관리 기능을 이용하기로 했다. 사람의 접근을 중앙에서 통제하고 감사 로그를 남길 수 있어야 한다는 판단이었다.

네트워크는 완전히 새로 만들지, 기존 인프라를 활용할지를 두고 비교했다. 별도 네트워크는 경계가 명확하지만 새로 관리할 항목이 늘어난다. 기존 네트워크를 그대로 쓰면 운영 부담은 줄어도 다른 자원과의 구분이 흐려질 수 있다. 검토 끝에 기존 환경을 재사용하되 봇이 놓이는 구역은 분리하기로 했다. 새 기반을 하나 더 운영하지 않으면서도 접근 범위를 제한할 수 있는 절충안이었다.

결과와 남은 문제

선택한 구조에서는 서버를 외부에 직접 공개하지 않아도 필요한 이벤트를 받을 수 있다. 운영자의 접근은 중앙 권한 체계에 남고, 봇은 기존 자원과 분리된 구역에서 동작한다. 다만 로컬 파일 저장 방식은 현재 규모에 맞춘 결정이므로, 상태가 늘거나 여러 인스턴스가 함께 동작해야 할 때는 다시 검토해야 한다.

다음에 적용할 원칙

돌아보면 이번 이전의 핵심은 서버를 어디에 둘지가 아니었다. 어떤 연결을 허용하고, 사람의 접근을 어떻게 기록하며, 다른 자원과 어디까지 나눌지를 정하는 일이었다. 작은 자동화 도구라도 계속 운영할 서비스가 되면 기능만 옮겨서는 부족하다. 처음부터 필요한 접점만 남기고 관리할 경계를 분명히 해야 이후의 운영도 단순해진다.