Slack 수동 운영에서 Request-on-Wake 구조로 전환하기

초기 방식: Slack 명령으로 GPU 서버를 켜고 껐습니다

GPU EC2는 계속 실행해 두기에는 비용 부담이 컸습니다. 초기에는 Slack에 간단한 명령어를 연결하고, Lambda를 통해 GPU EC2를 시작하거나 중지하는 방식으로 운영했습니다.

이 방식은 빠르게 적용할 수 있었고, 별도의 AWS 콘솔 접근 없이 팀원이 익숙한 Slack에서 인스턴스를 제어할 수 있다는 장점이 있었습니다.

다만 실제 서비스 요청과 서버 상태가 분리되어 있다는 한계가 있었습니다.

• 요청 전에 사용자가 서버를 미리 켜야 했습니다.
• 서버가 준비되기 전에 요청하면 실패할 수 있었습니다.
• 사용 후 종료 명령을 잊으면 비용이 계속 발생했습니다.
• 서비스 사용자가 인프라 운영 절차를 알아야 했습니다.

개선: 요청 자체가 서버를 깨우도록 만들었습니다

수동 명령에 의존하지 않도록 CPU EC2를 게이트웨이로 두고 Request-on-Wake 방식으로 전환했습니다.

CPU EC2가 요청을 받으면 GPU EC2의 상태를 확인합니다. GPU 서버가 중지된 상태라면 Lambda를 호출해 인스턴스를 시작하고, 추론 가능한 상태가 된 뒤 원래 요청을 vLLM 서버로 전달합니다.

사용자는 GPU 서버의 상태를 의식하지 않고 일반 API처럼 요청할 수 있고, 인프라 기동 절차는 게이트웨이 내부의 책임으로 감췄습니다.

역할을 분리했습니다

• CPU EC2: 항상 접근 가능한 요청 진입점, 요청 보관 및 전달
• Lambda: GPU EC2 시작·중지와 같은 짧은 제어 작업
• GPU EC2: vLLM을 통한 실제 모델 추론
• Slack: 초기 운영 및 관리 목적의 수동 제어 채널

배운 점

Slack 명령 방식은 PoC 단계에서 빠르게 비용을 통제하는 데 유용했습니다. 하지만 서비스로 발전시키려면 사용 흐름과 인프라 상태를 연결해야 했습니다.

이번 개선을 통해 초기의 단순한 운영 도구를 버리는 것이 아니라, 빠른 검증에 사용한 뒤 실제 요청 흐름에 맞는 자동화 구조로 점진적으로 발전시키는 경험을 했습니다.