Phinq 구축하기: Cronjob 장애로 인해 에이전트 거버넌스 (Agent Governance)를 처음부터 다시 설계하게 된 과정

By Hytham H -- 2026년 6월 29일

사건 발생

Hermes가 파일을 덮어썼습니다. Phinq는 이를 감지하지 못했습니다.

코드가 잘못되었기 때문이 아닙니다. 두 가지 이유가 있었습니다.

첫째, 해당 세션에서 기술 (skill)이 로드조차 되지 않았습니다. 에이전트에게는 스스로를 대조해 볼 지침이 없었습니다. 프롬프트 (prompt)도, 규칙 (rule)도, 안전망 (safety net)도 없었습니다.

둘째, 설령 로드되었다 하더라도 여전히 감지하지 못했을 것입니다. 해당 기술은 파일 작업 (file operations)만을 감시했습니다. 하지만 cronjob은 API를 통해 상태를 변이시켰습니다. 이는 다른 접점 (surface)이자 다른 경로였으며, 파일 작업 훅 (file-op hook)으로는 완전히 보이지 않는 영역이었습니다.

저는 자신이 통제받고 있다는 사실조차 모르는 행위자를 통제하려 하고 있었습니다.

진단

이 실패는 정직한 질문을 던지게 만들었습니다: 왜 이를 방지하기 위해 특별히 구축된 도구가 정작 이를 방지하는 데 실패했을까?

답은 불편합니다. 마크다운 기술 (markdown skill)은 권고 사항일 뿐입니다. 에이전트는 작업 도중 토큰 압박 (token pressure) 속에서 스스로 그 기술을 참조하기로 선택해야 하며, 이를 강제하는 메커니즘은 없습니다.

통제 대상이 무시할 수 있는 거버넌스 (governance)는 거버넌스가 아닙니다.

존재하는 모든 도구—파일 작업, API 호출, 데이터베이스 쿼리, 네트워크 요청—에 대해 훅 (hook)을 계속 추가할 수도 있겠지만, 그것은 두더지 잡기 게임과 같습니다. 당신은 항상 도구 하나 뒤처지게 됩니다. 다음 cronjob, 다음 API 접점, 당신이 감시할 생각을 하지 못한 다음 무언가가 나타날 것입니다. 위험 요소를 한 번에 하나의 접점씩 열거하면서, 무엇이든 호출할 수 있는 에이전트보다 앞서 나갈 수는 없습니다.

문제는 누락된 훅이 아니었습니다. 문제는 아키텍처 (architecture)였습니다.

전환

모든 도구를 개별적으로 가로채려고 시도하는 대신, 모든 도구 호출이 이미 통과하는 단 하나의 병목 지점(chokepoint), 즉 LLM API 호출 자체로 집행(enforcement)을 옮기는 것입니다.

에이전트가 취하는 모든 행동은 OpenAI, Anthropic, OpenRouter 등 해당 API를 사용하는 LLM 제공업체로의 요청 내 도구 호출 (tool call)로 시작됩니다. 그곳에서 가로챈다면 어떤 도구가 존재하는지 알 필요가 없습니다. 접점마다 훅을 만들 필요도 없습니다. 모든 행동이 반드시 지나가야 하는 관문에 앉아 있으면 됩니다.

그것이 바로 프록시 (Proxy)가 하는 일입니다. Fastify/TypeScript 기반의 인터셉팅 서버 (Intercepting server)를 구축하세요. 에이전트의 베이스 URL (Base URL)을 그곳으로 지정하기만 하면 됩니다. 모든 요청은 업스트림 (Upstream)에 도달하기 전에 반드시 이곳을 거쳐 흐릅니다. 도구 호출 (Tool calls)은 분류되고, 선언된 규칙에 따라 검사되며, 통과(Pass), 차단(Block), 또는 승인을 위해 일시 중지(Pause)됩니다.

코드 변경은 필요 없습니다. SDK도 필요 없습니다. 도구별로 훅 (Hook)을 유지 관리할 필요도 없습니다. 그저 URL만 바꾸면 됩니다.

(프로세스 내부 게이팅 (In-process gating)을 위한 SDK 경로도 존재하지만, 프록시 방식이 훨씬 더 단순한 이야기입니다.)

분류기 (Classifier)가 실제로 하는 일

결정론적 규칙 세트 (Deterministic rule set)가 모든 도구 호출을 다섯 가지 레벨 중 하나로 점수화합니다:

레벨	동작	예시
RISK_REDUCING	항상 통과	작업 취소, 변경 사항 되돌리기
...

여기에 대량 삭제, 자격 증명 읽기, 권한 변경, 또는 안전 장치를 비활성화하는 모든 행위와 같이 항상 에스컬레이션 (Escalate)되는 구조적 트리거 (Structural triggers)가 추가됩니다.

가역적인 동작 (Reversible actions)은 체감할 수 없는 지연 시간(Latency)과 함께 통과됩니다. 유일하게 대기하게 되는 것은 승인을 위해 붙잡힌 위험한 동작뿐입니다. 이것이 바로 핵심입니다.

머신러닝 (ML)도, 또 다른 블랙박스 (Black box)도 없습니다. 그저 집행이 보장되는 유일한 지점에서 강제되는 엄격한 규칙들뿐입니다.

리플레이 규율 (The Replay Discipline)

집행을 활성화하기 전에 보정 (Calibrate) 과정을 거쳐야 합니다. 프록시는 패스스루 모드 (Pass-through mode)로 실행될 수 있습니다. 즉, 모든 동작을 분류하고 모든 결정을 로그로 남기되, 아무것도 차단하지는 않는 방식입니다. 실제 코퍼스 (Corpus)를 통과시켜 보면서 잘못된 일시 중지 (False HOLDs)가 있는지 확인하고 임계값 (Thresholds)을 조정합니다.

일상적인 운영에서 잘못된 일시 중지가 전혀 발생하지 않을 때 비로소 집행을 활성화하십시오.

이것은 있으면 좋은 기능 (Nice-to-have)이 아닙니다. 운영자가 계속 설치해두는 도구와, 무해한 동작을 세 번 차단한 후 뽑아버리는 도구 사이의 차이를 결정짓는 요소입니다. 오탐률 (False-positive rate)이 거버넌스가 실제 워크플로우와 접촉했을 때 살아남을 수 있을지를 결정합니다. 만약 당신이 거버넌스 도구를 만들고 있는데 보정 루프 (Calibration loop)를 설계하지 않았다면, 제품을 완성한 것이 아닙니다.

감사 추적 (The Audit Trail)

감사 대상 엔티티 (Entity)가 스스로 보고하는 감사 로그 (Audit logs)는 변조 방지 증거 (Tamper evidence)가 없다면 아무런 가치가 없습니다.

모든 거버넌스 적용 액션 (governed action)은 해시 체인(hash-chained) 구조의 JSONL 파일에 기록됩니다. 첫 번째 항목은 무작위 로그 ID를 가진 제네시스 블록 (genesis block)입니다. 이후의 모든 항목에는 이전 항목의 해시 (hash)가 포함됩니다. 체인 내 어디에서든 단 1바이트만 변경해도 검증은 실패합니다.

단 한 번의 명령으로 이력이 온전함을 증명할 수 있습니다.

이것은 악의적인 에이전트 (malicious agents)를 잡아내기 위한 것이 아닙니다. 에이전트가 로그 파일에 쓸 수 있다면, 그 로그 파일을 조용히 수정할 수도 있다는 사실에 관한 것입니다. 감사 추적 (audit trail)은 감사 대상이 되는 주체에 의해 구조적으로 변경될 수 없어야 합니다. 그렇지 않다면, 그것은 여우에게 닭의 수를 관리하라고 부탁하는 것과 같습니다.

다음 단계

Phinq는 MIT 라이선스를 따릅니다. GitHub에 두 가지 구성 요소가 있습니다:

• github.com/phinq-co/phinq -- 프록시 (proxy), SDK, 분류기 (classifier), 그리고 감사 로거 (audit logger)
• github.com/phinq-co/phinq-governance -- 기존의 에이전트 스킬 (Agent Skill) (인프라가 필요 없는 더 가벼운 옵션)

호스팅 레이어 (세션 간 대시보드, 이상 탐지 (anomaly detection), 공유 가능한 보고서)는 개발 중입니다. 이것이 유용하다면 대기 명단에 등록하세요.

크론잡 (cronjob) 장애는 이 프로젝트에 일어난 가장 잘된 일이었습니다. 그것은 거버넌스가 환경적 (environmental)이어야 한다는 점을 증명했습니다. 즉, 액션이 물리적으로 거버넌스를 통과하거나, 아니면 아예 통과하지 못해야 한다는 것입니다. 행위자 (actor)에게 정중하게 요청함으로써 거버넌스를 할 수는 없습니다.

되돌릴 수 있는 액션은 통과합니다. 되돌릴 수 없는 액션은 일시 중지됩니다.

이것이 핵심 아이디어의 전부입니다.