3AM Super Intelligence — 운영 장애를 조사하고 원인을 입증해 해결합니다

3AM은 기존 시스템을 다시 작성하지 않고도 운영 장애 원인을 조사하고 수정안을 제안하는 AI 온콜 엔지니어입니다. 자체 네트워크 안에서 실행되며, 수정 전 드라이런과 사람의 승인을 거치도록 설계했다고 제품 측은 설명합니다.

주제: AI 시스템 보안

에디터 노트

현재 설명에서 설득력 있는 부분은 자동 조치보다 승인 절차와 읽기 전용 기본값을 먼저 제시한다는 점입니다. 잠금 대기 사례에서도 제품 측은 세션과 대기 상태를 확인할 수 있다고 답했고, 쿼리 종료가 트랜잭션을 롤백할 수 있다는 위험을 인정했습니다. 댓글 작성자가 제안한 짧은 잠금 시간 제한은 장애를 찾는 데서 끝내지 않고 재발 방지책까지 제안할 수 있는지 묻습니다. 다만 67가지 장애를 주입한 단일 오픈소스 코어뱅킹 시스템의 테스트 결과가 실제 서비스와 다양한 운영 환경을 얼마나 대표하는지는 제시되지 않았습니다. 유해한 조치가 없다는 출시 기준도 측정 대상과 판정 방식이 공개되지 않아 제품 설명만으로 검증하기 어렵습니다. 오픈 알파 단계인 만큼 현재 확인되는 것은 설계와 테스트 범위이며, 폭넓은 운영 환경에서의 성능은 아직 자료에 나오지 않습니다.

AI 요약

3AM은 운영 장애가 발생하면 시스템 내부에서 원인을 확인하고 수정안을 마련하는 AI 온콜 엔지니어입니다. 제품 측은 3AM이 자체 네트워크 안에서 실행되고 외부 인바운드 포트를 열지 않으며, 완전한 에어갭 환경에서도 작동한다고 설명합니다. 외부로 전송되는 정보는 서명된 라이선스 확인뿐이라고 합니다.

장애 조치와 승인 절차

3AM은 처음에는 섀도 모드로 실행됩니다. 이때는 시스템을 관찰하고 수정안을 제시하지만 변경을 가하지 않습니다. 제품 측에 따르면 수정안은 드라이런으로 먼저 점검하고, Slack, Symphony, PagerDuty, xMatters 또는 이메일에서 사람이 승인한 뒤 적용합니다. 기본 권한은 읽기 전용이며, 자율성을 높이려면 승인자 두 명이 필요하다고 합니다. 각 단계는 해시 체인 방식의 감사 로그에 기록됩니다. 원인을 확인할 증거가 부족하면 확정하지 않고 조사 결과를 넘긴다는 설명도 덧붙였습니다.

검증 방식과 한계

제품 측은 10년 된 Java 코드 24만 4천 줄 규모의 오픈소스 코어뱅킹 시스템에 의도적으로 67가지 장애를 일으켜 테스트한다고 밝혔습니다. 공개하는 수치는 이 테스트에서 나온다고 설명하며, 유해한 조치가 한 건도 없어야 출시할 수 있다고 합니다. 제품은 현재 오픈 알파 단계입니다. 댓글에서 제품 측은 데이터베이스 세션과 잠금 대기 상태를 살펴 장애 원인을 찾을 수 있다고 답했습니다. 다른 트랜잭션을 취소할 수 있는 쿼리 종료는 증거를 제시하고 승인을 받은 뒤에야 실행한다는 입장입니다.

Product Hunt 반응

@siddheshkulthe — 오늘 3AM을 출시합니다. 다시 작성할 수 없는 시스템을 위한 AI 온콜 엔지니어입니다. 개발자에게는 추측이 아닌 증거가 필요합니다. 챗봇이 자신 있게 말한다고 새벽 3시에 운영 환경에 수정 사항을 적용하지는 않습니다. 그래서 3AM은 실제 시스템을 대상으로 한 실시간 점검으로 원인을 입증한 뒤에만 원인을 지목합니다. 입증할 수 없으면 그렇게 말하고 확인한 내용을 넘깁니다. 규제 산업 팀은 시스템 안에 머물러야 합니다. 은행, 보험사, 통신사는 운영 데이터를 다른 회사의 클라우드로 보낼 수 없고 규제 기관은 모든 데이터의 이동 경로를 묻습니다. 그래서 3AM은 인바운드 포트 없이 네트워크 안에서 실행되고 완전한 에어갭 환경에서도 작동합니다. 외부로 나가는 정보는 서명된 라이선스 확인뿐입니다. 모든 사람이 통제권을 유지해야 합니다. AI가 한밤중에 혼자 운영 환경을 바꾸는 것을 원하는 사람은 없습니다. 모든 수정은 먼저 드라이런으로 시험하고 Slack, Symphony, PagerDuty, xMatters 또는 이메일에서 사람의 승인을 기다립니다. 3AM은 관찰하고 수정안을 제안하되 아무것도 바꾸지 않는 섀도 모드로 시작합니다. 자율성을 높이려면 승인자 두 명이 필요합니다. 모든 단계는 감사 담당자가 검증할 수 있는 해시 체인 감사 로그에 남습니다. 입증이 핵심입니다. 실제 오픈소스 코어뱅킹 시스템에 의도적으로 67가지 장애를 일으켜 3AM을 시험합니다. 이 시스템은 10년 된 Java 코드 24만 4천 줄로 구성됩니다. 공개하는 모든 수치는 이 테스트에서 나옵니다. 유해한 조치가 한 건도 없어야 출시할 수 있으며, 단순한 목표가 아닙니다. 운영 장애로 밤낮없이 고생하는 팀을 위한 제품입니다. 처음 90일은 무료입니다. 써보고 부족한 점을 알려주시면 고치겠습니다. 3AM은 현재 오픈 알파 단계이며, 피드백을 모으고 제품을 더 발전시키기 위해 이용자들에게 직접 연락하고 싶습니다.
@bengeekly — 이 도구가 해결하는 문제보다 더 많은 버그를 만들지 않는다는 걸 어떻게 알 수 있나요?
- @siddheshkulthe — 좋은 질문입니다. 운영 환경에서 작동하는 도구에는 위험이 따르므로 3AM은 추측에 근거해 행동하지 않도록 설계했습니다. 모든 서비스는 아무것도 바꾸지 않고 수정안만 제시하는 섀도 모드로 시작합니다. 배포된 여러 서비스 사이의 간접적인 관계도 파악할 수 있습니다. 증거를 확인하고 사람이 승인한 뒤에만 조치합니다. 나중에는 수정이 효과가 있었는지도 다시 확인할 예정입니다. 실시간 실행을 보여드릴 수 있습니다.
@petrkovacik — 다시 작성할 수 없는 시스템을 위한 AI 온콜 엔지니어라는 방향이 좋네요. 운영 환경 접근 권한은 어떻게 처리하나요?
- @siddheshkulthe — 운영 환경 접근은 보통 가장 걱정되는 부분이라 신중하게 설계했습니다. 3AM은 자체 네트워크 안에서 실행되므로 외부에 노출되지 않습니다. 기본적으로 읽기 전용이고, 운영 환경을 바꾸려면 사람이 먼저 승인해야 합니다. 모든 단계도 기록됩니다. 원하시면 시연해 드릴 수 있습니다.
@german_merlo1 — 하하, 그 고통을 겪어봤습니다. 많은 창업자가 같은 경험을 했을 것 같네요. 팀의 성공을 바랍니다.
- @anujbarve — 하하, 그렇다면 우리가 왜 이 제품을 만드는지 잘 아시겠네요. 응원해 주셔서 감사합니다.
@saikat_kumar3 — 제가 원하는 건 "추측이 아니라 입증"이라는 부분입니다. 배포 뒤 운영 환경이 두 번 멈췄는데 모든 대시보드에는 앱이 멈췄다고 나왔습니다. 실제 원인은 시작 시점의 스키마 변경이 오래 걸리는 쿼리 뒤에서 잠금을 기다린 것이었습니다. 오류가 아니라 대기 중인 상태도 실시간 점검으로 찾아낼 수 있나요? 수정 과정은 다른 사람의 쿼리를 종료해야 할 때 어떻게 진행되나요?
- @anujbarve — 3AM은 실시간 데이터베이스 세션과 잠금 대기 상태를 살펴 무엇이 실제로 작업을 막는지 찾을 수 있습니다. 차단 중인 쿼리를 종료하는 문제는 다릅니다. 트랜잭션이 롤백될 수 있으므로 조치 전에 증거를 보여주고 승인을 받아야 합니다.
- @saikat_kumar3 — 이해했습니다. 증거를 보여주고 먼저 승인을 받는 방식이 맞습니다. 저희 문제는 결국 시작 시점의 마이그레이션에 짧은 잠금 시간 제한을 설정해 해결했습니다. 그러면 앱 전체를 멈추는 대신 배포가 빠르고 명확하게 실패합니다. 차단 원인을 찾은 뒤 예방책으로 이런 설정을 제안하면 좋겠네요.

원문: Product Hunt / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗