새벽 3시입니다. 이번 분기에 벌써 네 번째 보는 페이지로 당신의 휴대폰 화면이 밝아집니다. 당신은 해결 방법을 알고 있습니다. 그 해결 방법을 _문서화(documented)_까지 해두었습니다. 그럼에도 불구하고, 당신은 반쯤 잠든 상태로 지난달에 실행했던 똑같은 세 개의 명령어를 실행하기 위해 서버에 SSH 접속을 하고 있습니다. 런북(runbook)이 스스로 실행되는 것도 아니고, 아무도 그것을 믿고 맡기지 않기 때문입니다.

장애가 _이해(understood)_된 시점과 _해결(resolved)_된 시점 사이의 그 간극 — 바로 그곳에 PRAXIS가 존재합니다.

문제점: 해결된 장애임에도 여전히 당신을 깨우는 상황

대부분의 온콜(on-call) 고통은 새로운 장애 때문이 아닙니다. 그것은 반복적이고 이미 진단된 장애입니다. 지식은 이미 존재합니다. 다만 위키(wiki) 페이지, Slack 스레드, 혹은 시니어 엔지니어의 머릿속에 머물러 있을 뿐입니다. 따라서 조직은 그 대가를 두 번 치릅니다. 한 번은 원인을 파악하기 위해, 그리고 그 이후로는 방해받는 수면을 통해 영원히 말입니다.

명백한 답은 "복구(remediation)를 자동화하는 것"입니다. 하지만 아무도 그렇게 하지 않는 명백한 이유는 두려움 때문입니다. 조용한 자동 복구(auto-remediation)는 아주 좋은 아이디어처럼 보이지만, 확신에 차서 잘못된 DROP 명령어를 실행하거나, 검증되지 않은 성공을 보고하여 5분짜리 일시적 장애를 사후 분석(postmortem)이 필요한 대형 사고로 키워버리기 직전까지만 그렇습니다. 잘못된 자동화 작업의 비용은 비대칭적입니다. 단 한 번의 잘못된 쓰기(write) 작업이 백 번의 올바른 작업보다 더 큰 피해를 줄 수 있습니다.

따라서 진짜 설계 질문은 "모델이 이것을 고칠 수 있는가?"가 아닙니다. "상태를 변경하는 모든 작업의 앞에 인간을 확실히 배치하면서, 어떻게 모델이 지루한 대량의 작업을 수행하게 할 것인가?"입니다.

핵심 아이디어: 엄격한 승인 게이트를 갖춘 오토파일럿

PRAXIS는 **의무적인 인간 개입 승인 게이트(mandatory human-in-the-loop approval gate)**를 갖춘 알람-to-복구(alert-to-remediation) 오토파일럿입니다. "오토파일럿(autopilot)"이라는 단어를 선택한 데에는 의도가 있습니다. 비행기를 조종하되, 되돌릴 수 없는 모든 것에 대해서는 여전히 인간이 제어권을 갖는다는 의미입니다.

전체 흐름은 다음과 같습니다:

1. 서명된(signed) 운영 경고가 도착합니다.
2. Qwen 모델이 이를 **분류(classify)**하고 **근본 원인(root cause)**에 대해 추론합니다.
3. PRAXIS는 로그, 상태, 컨텍스트 등 **읽기 전용 증거(read-only evidence)**를 수집하며, 변경을 일으키는 어떤 것도 건드리지 않습니다.
4. 이는 **위험 레이블이 지정된 복구 계획(risk-labelled remediation plan)**을 초안 작성합니다.
5. 시스템은 멈춥니다(stops). 사람이 정확한 계획을 승인하기 전까지는 상태를 변경하는 어떤 것도 발생하지 않습니다.
6. 승인이 이루어지면, 격리된 대상에 대해 **승인된 조치들을 실행(executes the approved actions)**합니다.
7. 모든 단계는 **감사 가능한 결정 추적(auditable decision trail)**에 기록됩니다.
8. 해결된 인시던트는 다음을 위해 재사용 가능한 인시던트 메모리가 됩니다.

흥미로운 엔지니어링은

분산 시스템(Distributed systems)은 깔끔하게 실패해 주는 친절함을 갖추고 있지 않습니다. 때로는 액션을 실행했지만 그것이 제대로 전달되었는지 알 수 없는 경우가 발생합니다. 연결이 끊기거나, 응답이 모호하거나, 호출 도중에 대상이 응답 불능 상태가 되기도 합니다. 단순한 자동화(Naive automation)는 이를 두 가지 재앙적인 방식 중 하나로 처리합니다. 성공했다고 가정하거나(그리고 당신에게 거짓말을 하거나), 맹목적으로 재시도합니다(그리고 중복 적용을 발생시킵니다).

PRAXIS는 둘 다 하지 않습니다. 실제 액션을 발송하기 전에, PRAXIS는 지속 가능한 발송 전 의도(durable pre-dispatch intent) — 즉, "나는 곧 X를 수행할 것이다"라는 기록된 내용을 남깁니다. 만약 해당 액션의 결과를 사후에 확인할 수 없다면, 인시던트는 해결됨(resolved)으로 표시되지 않으며 재시도되지도 않습니다. 대신 터미널 상태인 RECONCILIATION_REQUIRED 상태로 이동하여 인간의 개입을 기다립니다.

설계 원칙은 단호합니다. 거짓된 성공을 보고하느니 차라리 멈춰서 불확실함을 인정하는 쪽을 택합니다. RECONCILIATION_REQUIRED 상태에 머물러 있는 인시던트는 인간에게 "여기서 무슨 일이 일어났는지 확실하지 않으니 와서 확인해 주세요"라는 정직한 메시지를 전달하는 것입니다. 이것이 바로 새벽 3시에 당신이 원하는 메시지이며, 침묵하는 자동화가 보내기를 거부하는 바로 그 메시지입니다.

승인된 계획이 실행되는 계획이다

승인 게이트(Approval gate)는 승인되는 대상이 실제로 실행되는 대상일 때만 의미가 있습니다. 인간은 실행기(executor)가 자유롭게 재해석할 수 있는 모호한 의도가 아니라, 구체적이고 경계가 정해진 액션 세트인 정확한(exact) 계획을 승인합니다. 영향 범위(Blast radius)는 의도적으로 매우 작게 설정되었습니다. 단 하나의 실제 쓰기 어댑터(write adapter)는 오직 격리된, 일회용 Function Compute 데모 대상만을 재시작합니다. 주의(caution) 또는 위험(dangerous) 등급의 모든 도구는 **눈에 띄게 라벨링된 드라이 런(dry-run)**입니다. 당신은 도구가 실제로 액션을 취하지 않고도, 무서운 액션에 대해 추론하는 과정을 지켜볼 수 있습니다.

스택(The stack)

런타임은 Qwen 전용이며, Qwen Cloud(Alibaba의 Model Studio)에서 제공됩니다:

• 추론(Reasoning): qwen3.7-max, 가용성을 위해 동일한 Qwen 기반의 OpenRouter 폴백(fallback)을 사용합니다.
• 분류(Classification): qwen-flash — 대량의 분류(triage) 단계를 위해 저렴하고 빠릅니다.
• 메모리 임베딩(Memory embeddings): text-embedding-v4 (1024-dim).

이 시스템은 Alibaba Cloud Function Compute 3.0에서 실행되며, 시맨틱 장애 메모리(semantic incident memory)는 Alibaba Cloud Tablestore 벡터 검색에 저장됩니다. 해결된 장애는 임베딩되어 저장되므로, 향후 유사한 장애가 재발했을 때 지난번에는 어떻게 처리되었는지 불러올 수 있습니다. 이는 일반적인 모델의 사전 지식(prior)이 아닌, 여러분만의 이력에 기반한 회상(recall)입니다.

구축 방식에 관한 참고 사항

PRAXIS는 AI 코딩 에이전트, 주로 개발 에이전트로 GPT-5.6을 실행하는 OpenAI Codex를 사용하여 구축되었습니다. 이 점을 정확히 명시할 가치가 있는데, 혼동하기 쉽기 때문입니다. Codex와 GPT-5.6은 빌드 타임 도구(build-time tooling)일 뿐입니다. 이들은 코드를 작성하고 리팩터링(refactoring)했을 뿐, 제품 내부에서 실행되는 것이 아닙니다. PRAXIS 런타임(runtime)은 Qwen 전용입니다. 실제 장애 처리 경로(live incident path)에서 OpenAI 모델을 사용하는 것은 전혀 없습니다. 이러한 경계를 명확히 유지하는 것은 아키텍처 측면뿐만 아니라 정직성 측면에서도 중요합니다. 장애를 추론하는 시스템과 그 추론기를 작성하는 데 도움을 준 시스템은 서로 다른 두 개의 시스템입니다.

솔직한 한계점

사용자가 직접 격차를 발견하게 하기보다, 차라리 과소평가하여 설명하는 편을 택하겠습니다.

• 메모리가 아직 엔드 투 엔드(end-to-end)로 실시간 검증되지는 않았습니다. 쓰기 및 회상(write-and-recall) 경로는 구현 및 테스트되었으나, 새로 승인된 해결책이 메모리 행을 작성하고, 이후에 실제로 구별되는 재발 상황에서 이를 회상하는 과정이 하나의 연속된 실행에서 실시간으로 입증된 것은 아직 아닙니다. 즉, "구현 및 테스트됨"이지 "프로덕션에서 검증됨"은 아닙니다.
• 단일 운영자 데모입니다. 장애 정보는 프로세스 로컬(process-local)이며, 인스턴스 간 지속성(cross-instance durable)을 갖지 않습니다. 이는 멀티 테넌트(multi-tenant) 방식이 아니며, 프로덕션급 지속성을 보장한다고 주장하는 것도 아닙니다. 이는 플릿(fleet) 규모의 SaaS가 아니라, 안전한 아키텍처를 보여주기 위한 정직한 데모입니다.

이 중 어느 것도 PRAXIS가 전달하고자 하는 핵심을 훼손하지 않습니다. 핵심은 안전한 자동화의 형태 — 즉, 게이트(gate), 조정(reconciliation), 감사 추적(audit trail) — 이며, 그 형태는 실재하며 작동하고 있습니다.

체험하기 / 코드 읽기

**실시간 공개 읽기 전용 데모 (live, public, read-only demo)**가 준비되어 있으며, 별도의 로그인이 필요하지 않습니다. 데모를 열어 인시던트(incident)가 상태 머신(state machine)을 통해 실시간으로 흐르는 과정을 지켜보세요. 모든 것을 볼 수 있지만, 오직 유지 관리자의 운영자 토큰(operator token)만이 무언가를 승인할 수 있으므로, 여러분이 보더라도 승인 게이트(approval gate)는 온전하게 유지됩니다.

• 실시간 데모 (Live demo): https://praxis.kopachelli.dev
• 소스 코드 (Apache-2.0): https://github.com/Kopachelli/praxis

해당 리포지토리(repo)에는 README와 **859개의 통과된 자동화 테스트 (automated tests)**가 포함되어 있습니다. 만약 자동 복구(auto-remediation)를 원하면서도 모델에게 운영 환경(production)의 열쇠를 맡기는 것이 꺼려졌다면, 여기서 흥미로운 지점은 바로 모델이 혼자 운전하는 것을 거부하는 바로 그 부분입니다.