👍 174번, 👎 0번 — AI 보안 분석가의 피드백 버튼은 '봤음' 버튼이 되어 있었다

우리 클러스터의 보안 알림은 AI 에이전트 파수꾼(Watchman) 이 먼저 받는다. 파수꾼은 알림마다 증거를 모아 정상인지 위협인지 분류한 뒤 텔레그램 카드로 보낸다 (앞선 글, 공개 관제 뷰). 카드 밑에는 버튼이 두 개 있다. 👍 맞음 과 👎 틀림. 사람이 판정을 채점하라고 둔 버튼이다.

오늘(2026-10-04) 감사로그에서 이 버튼이 실제로 어떻게 쓰였는지 셌다. 결론부터 말하면 이 버튼은 정확도 라벨이 아니라 ‘확인했음’ 도장으로 쓰이고 있었다. 그래서 이 버튼으로는 판정 정확도를 잴 수 없다. 이 글에는 숫자, 그렇게 된 이유, 고칠 방향, 그리고 고치기 전까지 버튼을 어떻게 누르면 좋은지를 적는다.

범위: 아래 수치는 파수꾼 한 대의 감사로그(2026-09-24 ~ 2026-10-04, 파드 안 /data/audit.jsonl)를 직접 센 것이다. 라벨을 누른 사람은 운영자 한 명이다. 일반화된 통계가 아니라 한 시스템의 실측이다.

1. 숫자

항목	값
라벨 기록(human_label)	174건, 전부 운영자 계정
그중 👍 맞음	174건
그중 👎 틀림	0건
권한 없어서 거부된 라벨	0건
라벨이 붙은 run(조사 1건)	167개 (같은 run 중복 7건)
그중 판정이 없는 ‘🟡 판단 보류’ 카드	61개 (37%)
그중 “LLM 응답 실패로 조사 미완 — HTTP 410” 카드	4개
그중 “지난 판정 재사용” 카드	45개
같은 기간 보낸 카드	약 1,800장 → 라벨이 붙은 비율 약 9%

버튼 배선은 멀쩡하다. 누르면 기록되고, 권한 검사도 통과하고, 거부는 한 건도 없다. 문제는 무엇에 눌렸는가 다. 판정이 아예 없는 카드(“판단 보류 — 사람 확인 필요”)에 “👍 맞음”을 누르면 “무엇이 맞다”는 뜻인지 정의할 수가 없다. LLM 호출이 실패해 조사 자체가 끝나지 못한 카드에도 👍 가 4번 눌렸다. 이 37% 는 맞다·틀리다의 라벨이 아니다. “이 카드를 읽었다”는 기록이다.

2. 왜 이렇게 되나 — 버튼 하나에 뜻이 두 개 실렸다

2-1. ‘확인’ 이라는 동작에 둘 곳이 없다

운영자는 카드를 읽고 나면 읽었다는 표시 를 하고 싶다. 그런데 카드에 있는 버튼은 👍 와 👎 둘뿐이다. 그러면 손은 자연스럽게 덜 나쁜 쪽인 👍 로 간다. 👎 는 “에이전트가 틀렸다”는 고발처럼 느껴지고, 그렇다고 말하려면 실제로 틀렸다는 근거가 있어야 한다. 반면 👍 는 대충 눌러도 부담이 없다. 버튼의 뜻(정확도)과 사람이 하고 싶은 일(확인)이 어긋나면 사람이 하고 싶은 일이 이긴다.

2-2. 자동화 편향은 훈련으로 없어지지 않는다

자동화된 결정 보조를 쓰는 사람이 그 권고를 검증 없이 따르는 경향을 자동화 편향(automation bias) 이라고 한다. Parasuraman 과 Manzey 는 관련 연구를 종합해, 자동화 편향이 보조 장치가 틀릴 때 누락 오류(omission)와 수행 오류(commission)를 둘 다 낳고, 초보와 전문가 모두에게 나타나며, 훈련이나 “권고를 검증하라”는 명시적 지시로는 막히지 않는다 고 정리했다 (Parasuraman & Manzey, 2010, Human Factors 52(3)). 같은 리뷰는 이 현상을 여러 작업이 주의를 두고 경쟁할 때 생기는 주의 배분 문제로 설명한다.

알림을 하루 수십 장 받는 운영자가 카드마다 증거를 다시 확인할 수는 없다. 그러면 👍 는 “판정 맞음”이 아니라 “판정 그대로 받아들임”이 된다. 👎 가 0건이라는 숫자는 “판정이 다 맞았다”는 뜻이 아니다. 검증을 했다는 증거가 없다 는 뜻이다. 이건 운영자 개인의 성실성 문제가 아니라 설계 문제다. 위 논문이 말하는 핵심이 바로 “지시로는 안 된다”이므로, 고칠 곳은 사람의 습관이 아니라 버튼이다.

2-3. “오탐” 이라는 말 자체가 뭉뚱그려져 있다

Oxford 연구진이 SOC 실무자를 인터뷰한 연구에 따르면, 현업이 “오탐(FP)”이라고 부르는 경보의 상당수는 사실 benign trigger 다. 탐지 규칙은 정확히 맞았지만, 그 행위가 그 조직에서는 정상 업무여서 무시하는 경보다 (Alahmadi, Axon, Martinovic, USENIX Security ‘22). 같은 연구는 이 구분 없이 “FP 비율”을 재면 도구 성능을 잘못 평가한다고 지적한다. 또 경보 검증이 지루한 작업이라 alarm burnout 과 무감각(desensitization) 으로 이어진다고 보고한다.

파수꾼 카드에서도 같은 일이 보인다. 라벨이 붙은 카드 상당수가 “GitHub Actions 러너의 정상 툴 캐시 설치”, “wifi-probe DaemonSet 의 정상 연결 테스트” 같은 판정이다. Falco 규칙은 정확히 울렸고, 행위는 정상 업무다. 여기서 👍 하나로는 “에이전트가 정상이라고 본 게 맞다”와 “이 규칙은 여기선 소음이다”를 구분하지 못한다.

3. 라벨이 틀리면 생기는 비용 — 측정과 기억 둘 다 망가진다

측정. 👎 가 0 이면 “에이전트가 위험을 과하게 잡는 오류”도, “위험을 놓치는 오류”도 잴 수 없다. 판단 보류 카드에 눌린 👍 를 정답으로 세면 정확도가 실제보다 좋아 보인다.

기억. 파수꾼에는 RECALL 이라는 꺼진 기능이 있다. 사람이 👍 를 누른 판정을 서명해서 저장해 두고, 비슷한 알림이 오면 꺼내 보는 기능이다. 여기서는 👍 가 곧 ‘기억에 써라’ 다. OWASP 는 에이전트 위협 목록에서 이 위험을 ASI06 Memory & Context Poisoning 으로 따로 분류한다. 공격 시나리오 중 하나가 정확히 “보안 AI 의 기억을 다시 훈련시켜 악성 행위를 정상으로 분류하게 만드는 것”이고, 완화책으로 기억 쓰기 전 내용 검증, 출처 표기, 검증되지 않은 기억의 만료, 그리고 영향이 큰 기억을 꺼낼 때 출처 점수와 사람 확인 태그를 둘 다 요구하는 것 을 든다 (OWASP Top 10 for Agentic Applications 2026, ASI06).

공격자가 없어도 같은 일이 일어난다. “봤음” 으로 누른 👍 가 “사람이 검증한 정답”으로 기억에 들어가면, 그건 사람 확인 태그가 붙은 오염이다. 지금 RECALL 이 꺼져 있어서 실제 피해는 없다. 레코드 스키마 검사가 판정 없는 run 의 일부를 막아 주기도 한다. 하지만 버튼의 뜻을 바로잡기 전에 RECALL 을 켜면 안 된다.

4. 제안 — 버튼이 뜻을 하나씩만 갖게 한다

아직 구현 전 이다. 버튼을 실제로 누르는 운영자의 확인을 받은 뒤 진행한다.

① 판정이 없는 카드(판단 보류·미완)에는 다른 버튼을 단다.

[🟢 정상이었음]  [🔴 실제 문제]

판정이 없으니 채점할 것도 없다. 대신 사람이 판정을 직접 채운다. 지금 의미 없이 쌓이는 37% 가 그대로 진짜 정답 라벨이 된다. 에이전트가 끝내 판정하지 못한 사례이므로 가장 값진 라벨이기도 하다.

② 판정이 있는 카드는 틀린 방향까지 남긴다.

[👍 맞음]  [👎 과하게 봄]  [👎 놓침]  [👀 확인만]

• 과하게 봄: 에이전트는 위험하다고 했는데 실제론 정상이었다.
• 놓침: 에이전트는 정상이라고 했는데 실제론 위험했다. 보안에서 더 비싼 쪽이다.
• 확인만: “봤다”는 도장. 이 버튼이 있어야 습관적인 👍 가 이쪽으로 빠진다. 정확도 집계에서는 빼고, 커버리지(사람이 본 비율)에만 센다.

텔레그램 인라인 버튼의 callback_data 는 1~64 바이트 로 제한된다 (Telegram Bot API, InlineKeyboardButton). 파수꾼은 지금 wm:l:<run_id>:<code> 꼴로 보낸다. run_id 가 19자라 코드 한 글자를 늘려도 한도 안에 든다. 같은 문서는 버튼이 눌리면 봇이 반드시 answerCallbackQuery 로 응답해야 한다고 적고 있다. 응답하지 않으면 클라이언트에 진행 표시가 계속 남는다. 파수꾼은 이미 그렇게 하고 있어서 버튼 수가 늘어나도 바뀌지 않는다.

③ /state 에 집계를 띄운다. 라벨 커버리지, 👎 비율, 방향별(과대/과소) 오류 수, 판단 보류 카드에서 사람이 채운 판정 수. 👎 가 계속 0 이면 그 자체가 경보다. “완벽하다”가 아니라 “아무도 채점하지 않는다”는 신호이기 때문이다.

④ 기억에 들어가는 조건을 테스트로 고정한다. RECALL 에는 “판정 있음 + 👍 맞음” 만 들어간다. 확인만·판단 보류·재사용 판정에 누른 버튼은 들어가지 않는다. OWASP ASI06 의 “검증된 출처만 기억에 쓴다”를 코드 한 줄이 아니라 회귀 테스트로 못 박는다.

5. 고치기 전까지의 사용법

버튼이 바뀌기 전에도 오늘부터 라벨 품질을 올릴 수 있다. 원칙은 하나다. “맞다”고 말할 수 없으면 누르지 않는다.

카드 상태	지금 누를 것	이유
판정 있음, 증거를 봤고 동의함	👍	이게 원래 👍 의 뜻이다
판정 있음, 증거를 봤고 동의 안 함	👎	과대·과소 구분은 아직 없으니 감사로그 run 번호를 메모해 두면 나중에 붙일 수 있다
판정 있음, 그냥 훑어봄	누르지 않음	훑어본 👍 는 측정을 오염시킨다. 안 누른 것은 “모름”으로 남는다
🟡 판단 보류 / 조사 미완	누르지 않음	채점할 판정이 없다. ①이 생기면 그때 정상/실제 문제로 답한다
“지난 판정 재사용”	원래 판정이 여전히 맞을 때만 👍	재사용은 과거 판정의 복사본이다. 상황이 바뀌었으면 👎

모든 카드에 다 누를 필요는 없다. 라벨은 많은 것보다 정확한 게 낫다. 하루 몇 장이라도 증거를 보고 누른 👍·👎 가, 1,800장에 습관처럼 누른 👍 보다 정확도를 훨씬 잘 말해 준다. 특히 👎 는 에이전트를 탓하는 버튼이 아니다. 개선 재료를 주는 유일한 버튼이다.

6. 같은 날 고친 것 — 410 Gone

라벨 문제를 찾기 직전에 고친 장애도 기록해 둔다. 2026-10-03 18시 ~ 10-04 03시(KST) 사이에 호스티드 추론 API 의 주 모델이 HTTP 410 Gone 을 돌려줬다. 410 은 HTTP 의미상 “대상이 더 이상 없고, 그 상태가 영구적일 가능성이 크다”는 응답이다 (RFC 9110 §15.5.11). 파수꾼은 429·5xx 일 때만 예비 모델로 넘어갔다. 그래서 410 은 설정 오류로 보고 즉시 포기했고, 48시간 동안 조사 40건이 “LLM 응답 실패로 조사 미완”으로 끝났다. 위 표의 “410 카드에 눌린 👍 4건”이 바로 이 카드들이다.

수정 후에는 410·404 를 “그 모델이 사라짐”으로 보고, 그 모델만 이번 호출에서 빼서 예비 모델로 넘어간다. 호스티드 모델이 전부 사라졌으면 클러스터 안 자체 서빙 모델로 넘어간다. 키 오류(401)나 요청 오류(400)는 예전처럼 바로 실패로 올린다. 설정 결함을 로컬 모델의 답으로 덮지 않기 위해서다. 회귀 테스트 4개를 추가해 989개가 통과했고, 운영 반영 후 파드 안 코드 해시가 저장소와 일치하는 것을 확인했다.

정리

• 버튼은 작동했지만 뜻이 틀렸다. 👍 174 / 👎 0 은 정확도 100% 가 아니라 채점 0회다.
• 원인은 사람의 성실성이 아니라 설계다. 자동화 편향은 지시로 막히지 않는다(Parasuraman & Manzey, 2010). ‘확인’ 이라는 동작에 따로 둘 곳을 만들어야 한다.
• 라벨은 측정에만 쓰이는 게 아니라 기억의 입구 다. 입구가 오염되면 OWASP ASI06 이 말하는 기억 오염이 사람 손으로 일어난다.
• 제안: 판단 보류 카드엔 “정상/실제 문제”, 판정 카드엔 “맞음/과하게 봄/놓침/확인만”, /state 집계, 기억 입구 테스트.

References

1. Raja Parasuraman, Dietrich H. Manzey. “Complacency and Bias in Human Use of Automation: An Attentional Integration.” Human Factors 52(3):381–410, 2010. DOI: 10.1177/0018720810376055
2. Bushra A. Alahmadi, Louise Axon, Ivan Martinovic. “99% False Positives: A Qualitative Study of SOC Analysts’ Perspectives on Security Alarms.” 31st USENIX Security Symposium, 2022, pp. 2783–2800. usenix.org
3. OWASP GenAI Security Project. “OWASP Top 10 for Agentic Applications 2026 — ASI06: Memory & Context Poisoning.” genai.owasp.org
4. Telegram. “Bot API — InlineKeyboardButton / answerCallbackQuery.” core.telegram.org
5. R. Fielding, M. Nottingham, J. Reschke (eds.). “RFC 9110: HTTP Semantics,” §15.5.11 410 Gone. IETF, 2022. rfc-editor.org
6. 파수꾼 감사로그(/data/audit.jsonl, 2026-09-24 ~ 2026-10-04) 직접 집계 — 1차 데이터, 단일 시스템.