봇 버튼 상호작용을 큐로 안정적으로 처리하는 구조 설계

최근에 listener 모듈에 interactive button handler를 추가하고, 이를 bot_action_queue와 함께 구현했다. 사용자의 버튼 클릭 같은 상호작용을 체계적으로 처리하기 위한 작업인데, 이 과정에서 이벤트 기반 아키텍처와 큐 메커니즘이 얼마나 중요한지 다시 한번 깨달았다.

Listener 패턴으로 이벤트 처리하기

listener 패턴은 기본적으로 옵저버(Observer) 패턴의 변형이다. 어떤 이벤트가 발생했을 때 미리 등록된 핸들러들이 그 이벤트에 반응하도록 설계되는 방식이다. 이번에 interactive button handler를 추가한다는 것은, 사용자가 UI의 버튼을 클릭했을 때 그 신호를 캡처하고, 적절한 로직을 실행시키는 구조를 만들었다는 의미다.

이 패턴의 장점은:
- 느슨한 결합: 버튼 UI와 실제 액션 로직이 직접 연결되지 않음
- 확장성: 새로운 버튼이나 상호작용 타입을 추가하기 쉬움
- 일관성: 모든 상호작용을 한 곳에서 관리 가능

왜 bot_action_queue가 필요한가

여기서 중요한 부분이 바로 queue 메커니즘이다. 단순하게 생각하면 "버튼 클릭 → 즉시 액션 실행"이 가장 빠를 것처럼 보이지만, 실제 시스템에서는 여러 가지 이유로 이게 문제가 된다.

bot_action_queue에 액션을 쌓아두고 순차적으로 처리하면, 사용자의 여러 클릭이 동시에 들어와도 순서대로 처리된다. 또한 만약 어떤 액션이 실패했다면, 큐에 남아있는 상태에서 재시도 로직을 적용할 수 있다.

구현 관점의 고민들

listener.py에서 이 구조를 만들 때 고민했던 부분들:

• 이벤트 등록 메커니즘: 어떤 버튼 타입에 어떤 핸들러를 연결할 것인가
• 액션 객체 설계: bot_action_queue에 어떤 형태의 데이터를 넣을 것인가 (메타데이터, 사용자 정보, 타임스탬프 등)
• 에러 처리: 큐에서 처리 중 실패한 액션을 어떻게 처리할 것인가
• 로깅: 디버깅을 위해 버튼 클릭부터 액션 완료까지의 전체 흐름을 추적할 수 있어야 함

이런 고민들은 단순해 보이는 "버튼 누르면 뭔가 실행"이라는 요구사항이 실제로는 얼마나 많은 엣지 케이스와 운영 고려사항을 포함하는지 보여준다.

팀 협업으로 본 이 변경

이런 구조를 마련해두면 다른 팀원들이 새로운 버튼 상호작용을 추가할 때 일관된 패턴을 따를 수 있다. 단순히 핸들러를 listener에 등록하고, 필요한 로직을 작성하면 되는 식으로 표준화할 수 있단 뜻이다. 또한 큐 기반 처리는 시스템 전체의 안정성을 높여주기도 한다. 만약 특정 액션이 과도하게 많이 들어온다면, 큐에서 조절할 수 있으니까.

이번 작업을 하면서 느낀 건, 작은 기능 하나를 추가할 때도 "어떻게 하면 시스템이 더 안정적이고 유지보수하기 좋을까"를 생각하는 게 중요하다는 거다. 급하게 동작하게만 만드는 것과, 확장을 고려해서 설계하는 것의 차이는 시간이 지날수록 더 커진다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.