“아마 동작할 것”은 운영 인프라에서는 통하지 않는다 #
BASTION은 AI가 인프라 로그를 분석하고, 공격을 자동으로 차단하며, 대역 품질을 제어하는 “AI Ops Platform”입니다. 이렇게 쓰면 화려하게 들리지만, 우리가 개발에서 가장 신경 쓰는 것은 기능을 늘리는 일이 아닙니다. “동작한다고 증명된 것만 운영에 넣는다”는, 수수한 규율 쪽입니다.
운영 인프라에 자동 제어를 넣는다는 것은, AI의 판단 실수가 그대로 사고로 이어진다는 뜻입니다. 공격이 아닌 통신을 공격으로 오판해 차단하면 정상 고객이 막혀 버립니다. 혼잡도 아닌데 대역을 조이면 서비스가 저하됩니다. 그래서 우리는 “이론상으로는 맞을 것” “아마 동작할 것” 단계의 것을 운영에 넣지 않습니다.
이 글에서는 새로운 탐지 로직이나 제어를 운영에 넣기 전에 우리가 실제로 하는 일을 적습니다.
엔지니어는 “아름다운 설계”에 끌린다 ― 그것이 함정이 된다 #
솔직히 말하면, 우리에게도 “이론적으로 우아한 모델”이 있었습니다. 종이 위에서는 논리가 통하고, 설명하면 기분이 좋습니다. 이런 설계는 매력적입니다.
하지만 운영 트래픽은 종이 위의 가정대로 움직이지 않습니다. 우리는 자사 인프라의 실데이터로 그 모델을 검증했고, 예상과 다르게 동작하는 부분을 찾아냈습니다. 거기서 취한 행동은 단순합니다 ―― 모델 쪽을, 데이터가 뒷받침하는 범위까지 주장을 낮춰 다시 만들었습니다. 그림이 아름다우니 채택하는 것이 아니라, 데이터가 뒷받침하는 범위만 채택합니다.
이것은 패배가 아닙니다. 오히려 자신의 아름다운 가설을 자신의 데이터로 반증할 수 있다는 것이야말로, 운영 인프라를 맡는 제품에는 반드시 필요하다고 생각합니다.
검증의 작법 ―― 운영에 영향을 주지 않고 가설을 시험한다 #
구체적으로는 이런 순서로 검증합니다.
1. 관측만으로 가설을 시험한다 (READ-ONLY) #
새로운 탐지 로직은 우선 운영에 아무것도 쓰지 않는 “관측 전용”으로 동작시킵니다. 운영의 차단이나 제어에는 일절 손대지 않고, “만약 운영이었다면 어떻게 판정했을지”를 실데이터로 기록할 뿐입니다. 이렇게 하면 가설이 빗나가도 누구도 곤란하지 않습니다.
2. 진짜 이상과 단순한 노이즈를 나눌 수 있는지 확인한다 #
탐지 로직의 가치는 “이상을 찾아낼 수 있는 것”보다, “이상이 아닌 것을 이상이라고 말하지 않는 것”으로 결정됩니다. 배경 노이즈로 가득 찬 로그 속에서 진짜 이상만 골라낼 수 있는가. 우리가 보는 것은 단일 지표가 임계값을 넘었는지가 아니라, 복수의 관측면이 보조를 맞춰 무너지기 시작했는가(협조적 시작, co-onset)를, 각 대상의 자체 평상에서의 상대적 변화로서 포착할 수 있는가 하는 점입니다. 자사 환경에서 유사 부하나 이벤트를 가해, 탐지 로직이 “진짜 협조적 이상”과 “우연히 동시에 일어난 무관한 흔들림”을 분리할 수 있는지를 실데이터로 확인합니다. 분리하지 못하면 그 탐지는 쓸모가 없습니다.
3. 자신의 가설에 반대되는 관점을 부딪친다 #
“이 탐지는 정말 효과가 있는가? 우연히 맞은 것은 아닌가?”라고, 자신의 가설에 대립하는 해석을 의도적으로 부딪칩니다. 관측 창을 잡는 방식을 바꿔도 결론이 변하지 않는가, 다른 설명으로 같은 결과가 나오지 않는가. 반증을 견디지 못한 주장은 제품 설명에서 빼냅니다.
증명된 것은 운영으로, 증명되지 못한 것은 관찰 계층으로 #
검증을 통과한 것만이 단계적으로 운영으로 나아갑니다. 운영에 대한 쓰기는 반드시 “드라이런 → 한정 운영 → 전체 운영”의 3단계. 긴급 정지 명령은 처음부터 준비되어 있습니다. 그리고 모든 운영 반영은 “AI가 제안하고 사람이 승인하는” 게이트를 통과합니다.
이 규율은 제품을 보여주는 방식에도 그대로 드러납니다. 예를 들어 BASTION의 두 모듈은 가동 상황이 다릅니다.
- 보안 모듈은 실전에서 다수의 공격 캠페인을 탐지·자동 차단해 온 실적이 있으며, 운영에서 풀 오토로 가동하고 있습니다.
- 한편 품질 모듈(대역의 동적 제어)은 기능으로서는 구현이 끝났지만, 아직 관측을 중심으로 단계적으로 투입 중입니다. 회선이 실제로 혼잡해지는 장면에서 제어가 의도대로 듣는지는, 그 장면의 데이터로 확인한 뒤에 합니다 ―― 그래서 “운영에서 풀 가동하고 있다”고는 쓰지 않습니다.
“구현했다 ＝ 운영에서 동작한다”가 아닙니다. 이 구별을 우리는 제품 페이지에서도 무너뜨리지 않습니다.
AI(LLM) 자신도 신용하지 않고 검증한다 #
이 “신용하지 않고 검증한다”는 자세는, BASTION의 핵심인 로컬 LLM에도 향해 있습니다.
이전에 로컬 LLM이 모니터링 리포트 안에서 실재하지 않는 수치를 생성한 적이 있었습니다(그 전말과 대책은 “로컬 LLM이 모니터링 리포트의 수치를 날조한 이야기와 그 대책”에 적었습니다). 그 이후로 LLM의 출력 중, 시스템을 실제로 움직이는 판정 ―― 공격 IP인지의 최종 판정이나 차단의 실행 ―― 은 LLM에 결정하게 하지 않고, 실기 로그와 대조한 수학적·결정론적 판정으로 합니다. LLM이 잘하는 것은 자연어의 요약이나 정형이지, 운영의 의사결정이 아닙니다. LLM도, (침해될 수 있는 DMZ에 두는) Agent도, 우리에게는 “신용하지 않고 검증하는” 대상입니다.
왜 이 수수한 규율이 가장 큰 차별화가 되는가 #
AI Ops나 AI 보안 분야는 화려한 말이 오갑니다. 하지만 운영 인프라를 맡는 현장 담당자가 정말로 신경 쓰는 것은 “그것이 사고를 일으키지 않는가” “오탐지·오제어로 우리가 곤란해지지 않는가”입니다.
그래서 우리는 버즈워드가 아니라, 실제로 동작하고 있는 사실로 이야기합니다 ―― 운영에서 가동하는 공격 캠페인 탐지, 폐역 구성이라면 로그를 일절 외부로 내보내지 않는 것, 그리고 “증명된 것만 운영에 넣는다”는 만드는 방식 그 자체.
아름다움으로 결정하지 않는다. 책상 위에서 결정하지 않는다. 자신의 아름다운 가설을 데이터로 의심할 수 있을 것. 이것이 BASTION을 운영 인프라에 넣어도 되는 상태까지 끌고 가기 위한 우리의 규율입니다.
