AWS Lambda를 활용해 운영하던 치지직 방송 알림 봇의 응답 속도와 운영 비용을 개선한 경험을 소개합니다. 약 7,000개의 방송 채널을 주기적으로 확인하는 과정에서 발생한 타임아웃 문제를 해결하고, API 호출 방식을 변경해 실행 시간을 약 15초에서 1분 30초 수준으로 단축했습니다.
치지직 방송 알림 서비스의 구조와 운영 환경
치지직 방송 알림 서비스는 스트리머가 라이브 방송을 시작하면 미리 등록된 디스코드 채널에 알림 메시지를 전송하는 시스템입니다. 방송 상태를 주기적으로 확인하고, 이전에 저장한 방송 정보와 비교해 새로운 방송이 시작되었는지 판단하는 방식으로 동작합니다.
디스코드와 연동되는 치지직 알림 봇
치직은 치지직 스트리머의 방송 시작 소식을 디스코드 사용자에게 전달하기 위해 개발한 사이드 프로젝트입니다.
서비스에 등록된 스트리머가 방송을 시작하면 시스템이 이를 감지하고, 해당 스트리머의 알림을 구독한 디스코드 채널에 메시지를 전송합니다. 사용자는 치지직을 직접 확인하지 않아도 방송 시작 여부를 알 수 있습니다.
서비스가 성장하면서 등록된 채널의 수도 꾸준히 증가했습니다. 당시 약 7,000개의 채널이 등록되어 있었으며, 새로운 방송을 가능한 한 빠르게 감지하면서도 안정적인 운영 비용을 유지하는 것이 중요한 과제가 되었습니다.
기존 시스템에서 사용한 AWS 서비스
기존 구조는 AWS Lambda, Amazon DynamoDB, 치지직 API, Discord API를 조합해 구성했습니다.
AWS Lambda는 주기적으로 실행되는 방송 감지 작업을 담당하고, DynamoDB는 채널별 마지막 방송 정보를 저장합니다. 치지직 API에서 가져온 정보를 데이터베이스에 저장된 값과 비교한 뒤, 새로운 방송이 확인되면 Discord API를 통해 알림 메시지를 전송합니다.
이 구조는 별도의 상시 실행 서버를 관리하지 않아도 된다는 장점이 있습니다. 다만 감시 대상 채널이 증가하면 외부 API 호출 횟수와 Lambda 실행 시간이 함께 증가한다는 한계가 있었습니다.
기존 방송 감지 방식에서 발생한 성능 문제
기존 시스템은 전체 채널을 7개 그룹으로 나누고, 각 그룹을 담당하는 Lambda 작업을 일정한 간격으로 실행했습니다. 채널을 분산해 처리했지만, 개별 채널의 방송 상태를 확인하는 방식 때문에 실행 시간이 길어지는 문제가 있었습니다.
7개의 Lambda 작업으로 전체 채널 확인하기
기존 방송 감지 로직은 다음 순서로 동작했습니다.
- 7개의 트리거가 일정한 간격으로 Lambda 함수를 실행합니다.
- 각 Lambda는 자신에게 할당된 인덱스에 해당하는 채널 목록을 DynamoDB에서 조회합니다.
- 조회한 채널마다 치지직 API에 GET 요청을 보내 마지막 방송 정보를 가져옵니다.
- API 응답과 DynamoDB에 저장된 방송 정보를 비교해 새로운 방송이 시작되었는지 확인합니다.
- 새로운 방송이 감지되면 데이터베이스를 갱신하고, Discord API에 POST 요청을 보내 알림을 전송합니다.
채널을 7개 그룹으로 나누었기 때문에 각 Lambda는 약 1,000개의 채널을 담당했습니다. 따라서 Lambda가 한 번 실행될 때마다 수백에서 약 1,000건에 달하는 외부 API 요청을 처리해야 했습니다.
이 방식에서는 방송 중인 채널뿐 아니라 현재 방송하지 않는 채널까지 개별적으로 확인해야 했습니다. 실제로 새로운 방송이 시작된 채널이 많지 않더라도 전체 채널을 대상으로 반복적인 요청이 발생한다는 점이 비효율적이었습니다.
실행 시간 증가와 API 요청 부담
기존 구조의 가장 큰 문제는 처리 대상이 증가할수록 실행 시간이 길어졌다는 점입니다.
각 채널을 확인하는 과정에서 네트워크 요청이 반복적으로 발생하므로, 전체 작업 시간은 API 응답 속도와 요청 횟수에 영향을 받습니다. 채널 수가 늘어나면 Lambda의 실행 시간이 길어지고, 이에 따라 호출당 과금되는 실행 비용도 증가할 수 있습니다.
또한 일정한 주기로 수천 건의 요청을 보내는 방식은 외부 서비스에 불필요한 트래픽을 발생시킬 수 있습니다. 따라서 서비스의 규모가 커질수록 요청 횟수를 줄이는 방향으로 구조를 개선할 필요가 있었습니다.
AWS Lambda 타임아웃 문제와 원인 분석
기존 시스템은 한동안 큰 문제 없이 작동했습니다. 그러나 어느 시점부터 여러 사용자에게 방송 알림이 수 시간씩 지연된다는 문의가 접수되기 시작했습니다.
Lambda 모니터링 대시보드를 확인한 결과, 함수 실행이 제한 시간을 초과하는 타임아웃 오류가 발생하고 있었습니다. 단순히 채널 수가 증가한 것만으로 설명하기 어려운 문제가 나타난 것입니다.
외부 API 응답 지연으로 인한 Lambda 실행 중단
원인을 분석하는 과정에서 치지직 API에 GET 요청을 보낸 후 응답을 받지 못하고 대기하는 상황을 확인했습니다.
기존 Python 코드에서는 requests 라이브러리를 사용하고 있었으며, 해당 요청에 설정된 타임아웃은 60초였습니다. 서버가 연결을 유지한 채 응답을 보내지 않으면 프로그램은 설정된 제한 시간까지 해당 요청에서 대기할 수 있었습니다.
이러한 요청이 여러 채널을 확인하는 과정에서 반복되면 Lambda 전체 실행 시간이 급격히 증가할 수 있습니다. 결국 함수의 최대 실행 시간을 초과하면서 작업이 정상적으로 완료되지 못했고, 방송 알림도 지연되었습니다.
HTTP 요청에 타임아웃을 설정하는 것은 중요하지만, 타임아웃 값만 조정하는 것으로는 요청 자체가 지나치게 많다는 근본적인 문제를 해결할 수 없습니다.
단순한 요청 제한 문제로 보기 어려웠던 이유
당시 관찰한 현상은 특정 시간대에 집중되어 나타났습니다. 특히 오후 6시부터 밤 10시 사이에 문제가 발생하는 경향이 있었습니다.
일반적인 HTTP 400번대 응답은 요청 오류나 인증, 접근 제한 등의 문제를 조사할 때 참고할 수 있습니다. 하지만 서버가 응답하지 않고 요청이 대기 상태로 남는 현상은 이와 구별해서 살펴봐야 합니다.
물론 특정 HTTP 상태 코드가 반환되지 않았다는 사실만으로 상대 서버의 내부 문제라고 확정할 수는 없습니다. 네트워크 연결, DNS, 프록시, 서버 처리 지연 등 여러 가능성을 함께 검토해야 합니다.
다만 당시에는 외부 API 응답 지연으로 인해 전체 작업이 중단되는 현상이 확인되었고, 기존 구조를 그대로 유지해서는 안정적인 서비스를 제공하기 어렵다고 판단했습니다.
치지직 팔로우 API를 활용한 방송 감지 구조 개선
문제를 해결하기 위해 가장 먼저 검토한 것은 치지직에서 제공하는 팔로우 채널의 라이브 상태 조회 API였습니다.
이 API를 활용하면 여러 채널의 방송 여부를 한 번의 요청으로 확인할 수 있습니다. 모든 채널을 개별적으로 조회하는 대신, 실제로 방송 중인 채널을 먼저 추려내는 방식으로 불필요한 요청을 줄일 수 있습니다.
여러 채널의 방송 상태를 한 번에 조회하기
기존 방식에서는 등록된 채널 약 7,000개를 대상으로 방송 정보를 개별 조회했습니다. 반면 팔로우 API를 사용하면 특정 계정이 팔로우한 채널 중 현재 라이브 중인 채널 목록을 한 번에 가져올 수 있습니다.
이렇게 하면 방송하지 않는 채널을 대상으로 반복적인 상세 조회 요청을 보낼 필요가 없어집니다.
개선된 구조에서는 먼저 팔로우 API를 호출해 라이브 중인 채널을 확인하고, 해당 채널에 대해서만 추가적인 방송 정보 조회 요청을 보냅니다.
다만 이 API는 라이브 여부를 확인하는 데 유용하지만, 당시 사용한 응답만으로는 각 채널의 방송 시작 여부를 판단하는 데 필요한 방송 ID를 직접 확인할 수 없었습니다. 따라서 라이브 중인 채널에 대해서는 추가 API 요청을 통해 마지막 방송 정보를 가져와야 했습니다.
그럼에도 전체 채널을 확인하던 기존 방식보다 요청 대상을 크게 줄일 수 있다는 장점이 있었습니다.
로그인 세션과 계정별 팔로우 제한 해결하기
팔로우 API를 사용하려면 네이버 계정의 로그인 세션이 필요했습니다. 따라서 기존의 공개 API를 사용하는 방식과 달리 세션 관리와 계정 운영이라는 새로운 과제가 생겼습니다.
당시 고려했던 주요 문제는 다음과 같습니다.
- 세션 관리: 세션이 만료되거나 인증 상태가 변경되면 API 요청이 실패할 수 있습니다.
- 계정별 팔로우 제한: 계정당 팔로우할 수 있는 채널 수에 제한이 있어, 약 7,000개의 채널을 한 계정으로 관리하기 어려웠습니다.
- 장애 대응: 인증이나 계정 접근에 문제가 발생하면 방송 상태를 확인하는 작업 전체에 영향을 줄 수 있습니다.
이를 해결하기 위해 세션을 주기적으로 갱신하고, 여러 계정에 채널을 분산하는 방식을 적용했습니다.
당시 구현에서는 약 12시간 간격으로 특정 API를 호출해 새로운 세션 정보를 확보하도록 구성했습니다. 이러한 방식은 세션 상태를 지속적으로 관리하기 위한 대응책이었으며, 실제 운영 환경에서는 인증 정책과 API 동작이 변경될 가능성도 고려해야 합니다.
또한 계정당 팔로우 수 제한을 고려해 총 7개의 계정을 준비했습니다. 계정 수를 늘리는 것만으로 충분한 것은 아니므로, 각 계정에 어떤 채널을 할당할지 결정하는 분배 로직도 함께 설계했습니다.
채널 ID를 이용한 균등한 작업 분배
채널을 계정별로 분산하기 위해 치지직 채널 ID를 기준으로 인덱스를 계산했습니다.
예를 들어 채널 ID를 정수로 변환한 후 7로 나눈 나머지를 인덱스로 사용하면, 각 채널을 0부터 6까지의 그룹 중 하나에 할당할 수 있습니다.
이 방식은 별도의 복잡한 분배 알고리즘 없이 채널을 여러 그룹으로 나눌 수 있다는 장점이 있습니다. 실제 운영 데이터에서도 각 인덱스에 채널이 비교적 고르게 분배되었습니다.
인덱스를 데이터베이스에 저장해 두면 특정 그룹에 속한 채널을 쉽게 조회할 수 있습니다. 새로운 채널이 서비스에 등록될 때에도 동일한 규칙을 적용하면 해당 채널을 자동으로 적절한 계정에 할당할 수 있습니다.
이와 함께 각 인덱스에 속한 채널을 해당 계정이 팔로우하도록 처리하는 초기화 작업을 수행했습니다. 이후 새롭게 등록되는 채널도 팔로우 목록에 추가하도록 구성해 수동으로 계정을 관리해야 하는 부담을 줄였습니다.
개선된 방송 알림 로직의 처리 과정
새로운 구조에서는 전체 채널의 방송 정보를 개별적으로 조회하지 않습니다. 먼저 라이브 중인 채널을 선별한 뒤, 실제로 방송 중인 채널에 대해서만 필요한 상세 정보를 확인합니다.
새로운 Lambda 실행 순서
개선된 방송 감지 로직은 다음과 같습니다.
- 기존과 같이 7개의 트리거가 일정한 간격으로 Lambda 함수를 실행합니다.
- 각 Lambda는 자신에게 할당된 인덱스에 대응하는 네이버 계정의 세션을 이용해 팔로우 채널의 라이브 상태를 조회합니다.
- 응답에 포함된 라이브 채널 목록을 순회하며 각 채널의 마지막 방송 정보를 조회합니다.
- 조회한 방송 정보와 DynamoDB에 저장된 마지막 방송 정보를 비교합니다.
- 새로운 방송이 확인되면 DynamoDB의 정보를 갱신하고 Discord API를 통해 알림 메시지를 전송합니다.
이 구조의 핵심은 전체 채널을 확인하는 단계와 상세 방송 정보를 확인하는 단계를 분리한 것입니다.
기존에는 약 1,000개의 채널을 확인하기 위해 각 채널에 개별 요청을 보내야 했습니다. 개선 후에는 팔로우 API 요청 한 번으로 라이브 채널 목록을 얻고, 해당 목록에 포함된 채널에 대해서만 추가 요청을 보냅니다.
따라서 실제 방송 중인 채널이 적은 시간대에는 요청 횟수가 크게 감소합니다.
방송 ID를 한 번에 확인할 수 없는 한계
이번 개선이 모든 API 요청을 제거한 것은 아닙니다.
팔로우 API에서 방송 ID와 같은 상세 정보를 함께 제공한다면, 한 번의 요청으로 새로운 방송을 감지하는 데 필요한 데이터를 대부분 확보할 수 있습니다. 그러나 당시 사용한 API는 라이브 여부를 중심으로 정보를 제공했기 때문에 개별 방송 정보를 확인하는 추가 요청이 필요했습니다.
즉, 전체 채널 수가 아니라 실제 라이브 중인 채널 수에 따라 추가 요청량이 달라지는 구조입니다.
방송 중인 채널이 많아지는 시간대에는 실행 시간이 길어질 수 있지만, 방송하지 않는 채널까지 모두 조회하던 기존 방식보다는 훨씬 효율적으로 동작할 수 있습니다.
실행 시간과 AWS Lambda 비용 개선 결과
API 호출 방식을 변경한 뒤에는 Lambda 실행 시간과 월간 운영 비용에서 유의미한 차이가 나타났습니다.
실행 시간은 약 15초에서 1분 30초 수준으로 단축
개선 전에는 Lambda 작업이 한 번 실행될 때 약 6분 30초까지 소요되었습니다. 개선 후에는 시간대에 따라 약 15초에서 1분 30초 수준으로 줄었습니다.
방송이 많이 시작되는 밤 10시 무렵에는 처리해야 할 라이브 채널이 많아져 실행 시간이 상대적으로 길어졌습니다. 반대로 많은 사용자가 잠든 오전 8시 무렵에는 방송 중인 채널이 줄어들면서 실행 시간도 약 15초까지 감소했습니다.
이는 새로운 구조가 실제 라이브 채널 수에 영향을 받는다는 점을 보여줍니다.
주말에는 방송량이 더 많을 것으로 예상했지만, 당시 측정 결과에서는 평일과 비교해 뚜렷한 차이가 나타나지 않았습니다. 물론 이러한 결과는 특정 시점의 서비스 이용 패턴을 반영하므로, 이후에도 동일한 경향이 유지된다고 단정할 수는 없습니다.
월간 운영 비용 약 11달러에서 1.5달러로 감소
실행 시간 감소는 AWS Lambda 운영 비용 절감으로도 이어졌습니다.
- 개선 전: 월 약 11달러
- 개선 후: 월 약 1.5달러
월간 비용은 약 86% 감소했으며, 절대 금액으로는 약 9.5달러를 절약했습니다.
다만 이 수치는 당시 프로젝트의 운영 환경과 사용량을 기준으로 한 결과입니다. Lambda 비용은 실행 횟수, 메모리 설정, 실행 시간, AWS 요금 정책 등에 따라 달라질 수 있습니다. 또한 세션 관리나 추가 계정 운영에 필요한 비용은 별도로 고려해야 합니다.
그럼에도 외부 API를 호출하는 방식을 변경하는 것만으로 서버리스 애플리케이션의 실행 시간과 비용을 동시에 줄일 수 있다는 점에서 의미 있는 개선이었습니다.
서버리스 프로젝트에서 얻은 성능 최적화 교훈
이번 경험에서 가장 중요한 점은 무조건 더 빠른 코드를 작성하는 것보다 불필요한 작업 자체를 줄이는 것이 더 효과적일 수 있다는 사실입니다.
API 요청 횟수부터 줄이는 것이 중요합니다
외부 API를 사용하는 프로그램에서는 네트워크 요청이 전체 실행 시간의 상당 부분을 차지할 수 있습니다. 특히 여러 대상을 반복해서 조회하는 구조에서는 요청 하나의 지연이 전체 작업에 누적될 수 있습니다.
따라서 성능을 개선할 때는 다음과 같은 순서로 접근하는 것이 좋습니다.
- 현재 작업에서 발생하는 API 요청 횟수를 측정합니다.
- 여러 대상을 한 번에 조회할 수 있는 API가 있는지 확인합니다.
- 필요한 대상만 선별해 상세 조회를 수행하도록 변경합니다.
- 요청 타임아웃과 재시도 정책을 적절하게 설정합니다.
- 실행 시간과 오류율, 비용을 개선 전후로 비교합니다.
단순히 Lambda 메모리를 늘리거나 타임아웃을 길게 설정하는 방법도 상황에 따라 도움이 될 수 있습니다. 하지만 불필요한 요청이 근본 원인이라면 호출 구조를 개선하는 것이 더 효과적입니다.
인증 세션과 외부 서비스 의존성을 함께 관리해야 합니다
인증이 필요한 API를 사용하는 경우에는 세션 갱신, 인증 실패, 계정 제한, API 정책 변경 등을 고려해야 합니다.
특히 여러 계정을 이용해 요청을 분산하는 구조에서는 계정별 상태를 추적하고, 특정 계정에 문제가 발생했을 때 이를 감지할 수 있는 모니터링이 필요합니다. 세션 갱신이 실패하거나 팔로우 목록이 최신 상태가 아니라면 일부 채널의 방송을 놓칠 수 있기 때문입니다.
또한 HTTP 요청에는 적절한 타임아웃을 설정하고, 재시도가 필요한 오류와 재시도해도 해결되지 않을 오류를 구분하는 것이 좋습니다. 무조건적인 재시도는 오히려 요청량을 증가시키고 장애를 악화시킬 수 있습니다.
외부 API에 의존하는 서비스는 API 제공자의 정책과 응답 방식이 바뀔 가능성도 염두에 두어야 합니다. 운영 중인 서비스에서는 API 사용 조건을 확인하고, 허용된 방식으로 데이터를 조회하는 것이 중요합니다.
치지직 방송 알림 봇의 개선 과정을 마무리하며
처음에는 즐겨 보던 소규모 스트리머를 위해 시작한 프로젝트였지만, 서비스에 등록된 채널이 약 7,000개까지 늘어나면서 성능과 운영 비용을 지속적으로 관리해야 하는 상황이 되었습니다.
기존 구조는 단순하고 구현하기 쉬웠지만, 모든 채널을 개별적으로 조회한다는 한계가 있었습니다. 이를 해결하기 위해 팔로우 채널의 라이브 상태를 일괄 조회하는 API를 도입했고, 실제 방송 중인 채널에 대해서만 추가 정보를 확인하도록 변경했습니다.
그 결과 Lambda 실행 시간은 기존 약 6분 30초에서 15초~1분 30초 수준으로 줄었으며, 월간 운영 비용도 약 11달러에서 1.5달러로 감소했습니다.
대규모 인프라를 도입하지 않더라도 기존 시스템의 병목 지점을 파악하고 데이터 조회 방식을 개선하면 충분히 큰 효과를 얻을 수 있습니다. 특히 서버리스 환경에서는 실행 시간과 요청 횟수가 비용에 직접적인 영향을 줄 수 있으므로, 시스템을 설계할 때부터 작업량을 줄이는 방법을 함께 고민하는 것이 중요합니다.
치직 프로젝트는 앞으로도 안정적인 방송 감지와 효율적인 운영을 목표로 개선해 나갈 예정입니다.
프로젝트 GitHub 저장소: junah201/chzzk-discord-bot
버그 제보와 기능 개선을 위한 Issue 및 Pull Request는 언제든지 환영합니다.