메리톡톡 자동화 구조를 다시 설계하며
메리톡톡을 다시 만들면서, 서비스가 스스로 상태를 점검하고 문제를 발견한 뒤, 필요하다면 개선 제안까지 할 수 있는 시스템이 필요하다는 생각이 들었습니다.
단순히 장애 여부를 감시하는 모니터링 수준이 아니라, 사람의 개입을 최소화하면서도 위험한 작업은 자동으로 실행되지 않도록 막아주는 구조가 필요했습니다. 그래서 백그라운드 서비스를 몇 가지 계층으로 나누어 설계하기로 했습니다.
전체 구조
전체 구조는 크게 세 가지 계열로 구분했습니다.
Watcher 계열, Control 계열, Communication 계열입니다. 각각의 역할은 명확하게 분리했습니다.
Watcher
Watcher는 말 그대로 관찰만 담당합니다.
Site Health Watcher, Log Analyzer, GitHub Watcher, Content Planner, Product Insight Agent 등이 여기에 속합니다.
이들은 서비스 상태, 로그, GitHub 이슈, 콘텐츠 흐름, 제품 관련 지표 등을 수집하고 해석한 뒤 AiObservation으로 저장합니다. 중요한 점은 Watcher가 직접 실행 권한을 갖지 않는다는 것입니다. Watcher는 상황을 발견하고 기록하며, 필요한 경우 제안의 근거가 되는 정보를 남기는 역할만 합니다.
Control
Control 계층은 제안을 평가하고 실행 여부를 결정합니다.
이 계층의 핵심은 Approval Manager입니다. Approval Manager는 생성된 제안의 위험도를 판단하고, 승인 정책에 따라 자동 실행이 가능한지 또는 사람의 승인이 필요한지를 결정합니다.
승인된 제안만 AutomationJob으로 변환되며, 이후 Job Poller가 실제 작업을 실행합니다.
Communication
Communication 계층은 결과를 사람에게 전달하는 역할을 합니다.
현재는 Slack Reporter가 이 역할을 담당합니다. Watcher가 발견한 내용, Approval Manager의 판단 결과, Job Poller의 실행 결과 등을 Slack으로 알려주어 운영자가 필요한 정보를 빠르게 확인할 수 있도록 합니다.
권장 실행 흐름
전체 실행 흐름은 단계별로 나누어 생각할 수 있습니다.
먼저 Watcher가 서비스를 관찰합니다. 이후 Analyzer 또는 Planner가 관찰된 데이터를 해석하고, 그 결과를 AiObservation으로 저장합니다. 이 관찰 결과를 바탕으로 AiSuggestion이 생성되며, Approval Manager가 해당 제안의 위험도를 판단합니다.
위험도가 낮은 작업은 정책에 따라 자동으로 진행될 수 있지만, 고위험 작업은 자동 실행하지 않고 반드시 승인 과정을 거치도록 했습니다. 승인된 제안만 AutomationJob으로 변환되고, Job Poller가 이를 실행합니다. 마지막으로 Slack Reporter가 실행 결과를 보고합니다.
정리하면 다음과 같습니다.
- Watcher가 서비스를 관찰합니다.
- Analyzer 또는 Planner가 관찰된 의미를 해석합니다.
- AiObservation을 저장합니다.
- AiSuggestion을 생성합니다.
- Approval Manager가 위험도를 판단합니다.
- 승인된 제안만 AutomationJob으로 변환합니다.
- Job Poller가 작업을 실행합니다.
- Slack Reporter가 결과를 보고합니다.
핵심 설계 원칙
이 구조를 만들면서 가장 중요하게 생각한 원칙은 다음과 같습니다.
1. 관찰과 실행을 분리합니다
Watcher는 실행 권한을 갖지 않습니다. 단지 상황을 관찰하고, 기록하고, 제안의 근거를 남길 뿐입니다.
실행 여부는 Control 계층에서 결정합니다. 이렇게 해야 관찰 과정에서 발생한 오판이 곧바로 실제 작업으로 이어지는 위험을 줄일 수 있습니다.
2. 제안과 승인을 분리합니다
AI가 어떤 작업을 제안할 수는 있습니다. 하지만 그 제안을 실행해도 되는지는 별도의 승인 정책이 판단해야 합니다.
특히 데이터 삭제, 설정 변경, 배포, 외부 알림 발송처럼 영향 범위가 큰 작업은 AI의 판단만으로 자동 실행되어서는 안 됩니다. 위험도가 높은 작업은 항상 사람의 승인을 거치도록 설계했습니다.
3. AI 판단과 시스템 정책을 분리합니다
AI는 유연하게 판단할 수 있다는 장점이 있습니다. 하지만 그만큼 결과가 항상 예측 가능한 것은 아닙니다.
반면 시스템 정책은 단단한 규칙이어야 합니다. 어떤 작업은 자동 실행할 수 있고, 어떤 작업은 반드시 승인이 필요하며, 어떤 작업은 아예 실행해서는 안 된다는 기준이 명확해야 합니다.
AI 판단과 시스템 정책이 섞이면 구조가 불안정해질 수 있습니다. 그래서 AI는 제안하고, 시스템은 정책으로 제한하는 방식으로 역할을 분리했습니다.
4. 고위험 작업은 자동 실행하지 않습니다
서비스 운영에서 가장 조심해야 할 부분은 되돌리기 어려운 작업입니다.
데이터 삭제, 권한 변경, 설정 변경, 결제 관련 처리, 배포와 같은 작업은 작은 실수도 큰 문제로 이어질 수 있습니다. 따라서 이런 작업은 자동 실행하지 않고, 반드시 사람의 확인을 거치도록 했습니다.
5. 모든 작업은 감사 가능해야 합니다
자동화 시스템은 편리해야 하지만, 동시에 추적 가능해야 합니다.
누가, 언제, 어떤 근거로 무엇을 제안했는지, 어떤 정책에 따라 승인되었는지, 실제로 어떤 작업이 실행되었는지를 모두 기록해야 합니다. 그래야 문제가 생겼을 때 원인을 추적할 수 있고, 이후 정책을 개선할 수도 있습니다.
왜 이렇게 나누었을까요?
혼자 서비스를 운영하다 보면 구조를 최대한 단순하게 만들고 싶은 유혹이 생깁니다. Watcher가 문제를 발견하면 바로 처리하도록 만드는 방식이 처음에는 훨씬 간단해 보입니다.
하지만 그렇게 만들면 나중에 감당하기 어려운 장애가 생길 수 있습니다. AI가 잘못 판단했거나, 로그를 잘못 해석했거나, 일시적인 오류를 실제 장애로 오인했을 때 곧바로 실행까지 이어진다면 오히려 서비스 안정성을 해칠 수 있습니다.
저는 메리톡톡을 오래 운영하고 싶습니다. 그래서 처음부터 관찰과 실행 사이에 승인이라는 안전장치를 두기로 했습니다.
이 구조가 완벽하다고 생각하지는 않습니다. Watcher가 너무 많은 데이터를 쌓을 수도 있고, Approval Manager가 지나치게 보수적으로 판단할 수도 있습니다. Slack 알림이 많아져 오히려 피로감을 줄 수도 있습니다.
하지만 지금 단계에서는 이렇게 시작하는 것이 맞다고 생각합니다. 처음부터 모든 것을 자동화하기보다는, 안전한 범위 안에서 자동화를 시작하고, 실제 운영 경험이 쌓이면 조금씩 개선해 나가면 됩니다.
다음 단계
현재는 이 구조를 실제 코드로 옮기는 중입니다.
가장 먼저 Site Health Watcher와 Slack Reporter를 만들고, Approval Manager는 최소 기능부터 구현할 예정입니다. 처음부터 복잡한 승인 정책을 만들기보다는, 위험도를 단순하게 분류하고 승인 여부를 기록할 수 있는 수준에서 시작하려고 합니다.
이 과정에서 여러 가지 문제를 만나게 될 것 같습니다. 어떤 데이터까지 관찰해야 하는지, 알림은 어느 정도가 적절한지, 자동 실행 가능한 작업의 범위를 어디까지 허용할지 같은 고민들이 계속 생길 것입니다.
그 과정도 하나씩 기록해 보려고 합니다.
혼자 서비스를 만드는 사람에게 가장 어려운 일 중 하나는 기능을 더 만드는 것이 아니라, 오히려 덜 만드는 결정을 하는 일이라고 생각합니다.
이번에는 최소한의 기능으로 시작하고, 필요한 만큼만 확장해 보려 합니다.