[태그:] 보안 경계

도구는 이제 잘 돌아간다. 그런데 일을 시키려고 하면 승인 프롬프트가 뜬다. 하나 눌러 주면 또 뜨고, 또 눌러 주면 다음 것이 뜬다. 그래서 전부 열어 두고 싶어지고, 그러다 문득 이걸 다 열어도 되는 것인가 하는 생각이 든다. 전부 열면 위험하고 안 열면 일이 안 되는 자리, 여기가 이 글의 주제다.

전부 허용해 두었을 때 우리가 본 것. 겉으로는 잘 돌아간다. 문제는 무언가 잘못된 뒤에 드러난다. 어디서 멈췄어야 하는지를 되짚으려 해도 멈출 자리가 애초에 없었으므로 되짚을 지점이 없다. 기록만 놓고 보면 게이트가 없었던 것과 게이트를 통과한 것이 구별되지 않는다.

전부 물어보게 두었을 때 우리가 본 것. 이쪽은 훨씬 빨리 드러난다. 사람이 답하기 전까지 아무것도 진행되지 않으므로, 사람이 자리를 비운 시간만큼 일이 통째로 서 있다. 우리가 실제로 잰 것은 여기까지다. 덧붙이면, 답해야 할 항목이 많아질수록 그 답이 형식적으로 되기 쉽다고 우리는 경계하고 있는데, 이 문장은 우리가 측정한 것이 아니라 위 관측에서 나온 우려다.

우리가 이 문제를 겪으면서 얻은 결론은 하나다. 승인 요청은 한 종류가 아니다. 두 층으로 갈라야 하고, 갈라지 않으면 둘 중 하나가 무너진다. 통지성 항목을 전부 사람에게 보내면 기동이 막히고, 되돌릴 수 없는 행위를 기계가 대신 누르면 정지 경계가 사라진다. 우리는 그 두 실패를 각각 겪었다. 다만 그것이 모든 설계에서 반드시 그렇게 된다는 뜻은 아니다. 우리가 관측한 두 형태를 적는 것이고, 규칙 제안으로 읽어 주기 바란다.

이 자리를 우리는 승인 피로라고 부른다. 도구가 못 미더워서 생기는 문제가 아니라, 도구가 제 할 일을 하는데도 사람이 그 속도를 따라가지 못해서 생기는 문제다. 그래서 해법도 도구를 덜 쓰는 쪽이 아니라 물어봐야 하는 것과 물어보지 않아도 되는 것을 갈라 두는 쪽에 있다고 우리는 봤다.

먼저 이 글에서 쓰는 말 몇 개를 풀어 둔다. 승인 프롬프트는 도구가 어떤 동작을 하기 전에 사람에게 허락을 묻는 화면이다. 게이트는 그 허락 없이는 다음으로 넘어가지 못하게 막아 둔 관문을 말한다. 원장은 그런 요청과 결정이 한 줄씩 쌓이는 기록 파일이다. 그리고 이 글에서 통지성과 행위 승인이라고 부르는 두 낱말은 우리가 우리 시스템을 정리하려고 붙인 이름이지 업계 표준 용어가 아니다.

미리 한 가지 밝혀 둔다. 이 글은 안전 경계를 다루므로, 독자가 이 문안을 그대로 따라 자기 시스템의 게이트를 열 수 있다. 그래서 이 글은 이렇게 하면 안전하다고 말하지 않는다. 우리가 어디에 선을 그었고 그 이유가 무엇인지를 적을 뿐이다. 자기 환경의 위험은 자기가 판단해야 한다. 다만 이 글에서 단정하는 것이 딱 하나 있고, 그것은 4번 항목에 적었다.

일을 끊는 승인이 어느 쪽인가

• 1. 승인 프롬프트가 계속 떠서 일이 끊긴다 (증상과 논지)
• 2. 요청이 다 같아 보이는데 우리 원장에서는 이미 두 유형으로 갈려 있었다 (우리 실측)
• 3. 상태 통지까지 사람에게 보냈더니 기동이 막혔다 (우리 실측 + 처방)
• 4. 되돌릴 수 없는 행위를 기계가 대신 누르면 정지 경계가 사라진다 (이 글의 유일한 단정)
• 5. 무엇을 말하는 화면과 무엇을 요구하는 화면을 감시 장치가 구별하지 못했다 (우리 실측)
• 6. 승인 창이 닫힌 뒤 도착한 결재를 쓸 수 없었다 (우리 실측)
• 7. 우리가 그은 경계와 그 이유 (처방)

1. 승인 프롬프트가 계속 떠서 일이 끊긴다

증상. 작업을 시키면 도구가 중간에 멈춰 서서 허락을 묻는다. 하나 답하면 다음 것이 뜬다. 사람이 자리를 비우면 그 자리에서 작업이 통째로 멈춰 있다.

여기서 흔히 하는 선택 두 가지. 하나는 전부 허용해 두는 것이다. 그러면 빨라진다. 다른 하나는 전부 물어보게 두는 것이다. 그러면 안심이 된다. 우리는 두 쪽을 다 해 봤고, 두 쪽 다 각자의 방식으로 무너졌다.

우리가 내린 결론. 문제는 허용의 양이 아니라 종류를 안 나눈 것이었다. 승인 요청을 하나의 덩어리로 보면 열거나 닫는 두 선택밖에 없다. 그런데 실제로 올라오는 요청은 성격이 다른 것들이 섞여 있다. 어떤 것은 무엇을 알리는 화면이고, 어떤 것은 무엇을 하겠다고 요구하는 화면이다.

그 둘을 가르려고 우리가 먼저 던지는 질문은 이것이다. 이 처리가 기록만 닫는가, 아니면 동작 실행·권한 부여·차단 해제도 하는가.

되돌릴 수 있다는 것은 기준이 되지 못한다. 우리도 처음에는 되돌릴 수 있는가를 기준으로 삼았는데 그것으로는 갈리지 않았다. 되돌릴 수 있는 일도 실제 행위다. 로컬에 커밋을 하나 남기는 것도, 원본이 있어 복구할 수 있는 파일 변경도 행위이고, 캐시를 지우는 일조차 내용과 다시 만드는 비용에 따라 영향이 달라진다. 복구할 수 있다는 이유만으로 요청할 권한이 생기지는 않는다.

확인 방법. 지금 떠 있는 프롬프트를 보고 이렇게 물어보라. 이 항목을 처리하면 기록 하나가 닫히는 것으로 끝나는가, 아니면 무언가가 실행되거나 권한이 열리거나 막혀 있던 것이 풀리는가. 뒤쪽이 하나라도 있으면 그것은 통지가 아니다. 이 질문의 답이 다음 항목들의 갈림길이 된다.

2. 요청이 다 같아 보이는데 우리 원장에서는 이미 두 유형으로 갈려 있었다

이 항목은 우리가 직접 측정한 것이다.

우리가 측정한 것. 우리 승인 원장을 전수로 셌다. 2026년 9월 8일 22시 5x분 시점에 총 92건이었고, 유형별로는 이렇게 갈려 있었다.

첫 실행 신뢰 관문        24
부트 판정 불가          22
통지성 승인            21
행위 승인             12
팀 편성 통지            7
컨텍스트 순환 검증        6
                    ----
합계                  92

여기서 우리가 놀란 대목. 우리는 두 층이라는 구분을 이 글을 쓰면서 정리한 개념이라고 생각했다. 그런데 원장을 열어 보니 통지성 승인 21건과 행위 승인 12건이 이미 서로 다른 유형으로 갈려 기록되고 있었다. 즉 이 구분은 나중에 붙인 해석이 아니라 운영하면서 이미 갈라 두고 있던 것이었다. 이름을 붙이지 않았을 뿐이다.

이 표가 말해 주는 것과 말해 주지 않는 것. 이 표는 그 시점 우리 기록에 서로 다른 라벨이 있었다는 것까지만 보여 준다. 그 라벨이 옳게 붙었다거나 통지로 분류된 21건은 자동으로 처리해도 된다는 결론은 여기서 나오지 않는다. 그렇게 읽으면 우리가 붙인 이름으로 우리 설계를 정당화하는 것이 된다. 자동으로 처리해도 되는지는 라벨이 아니라 그 요청 하나하나가 실제로 무엇을 하는지로 판단해야 한다.

표에 있는 이름을 쉬운 말로 풀면 이렇다. 첫 실행 신뢰 관문은 어떤 폴더에서 도구를 처음 켤 때 이 폴더를 믿을 것인지 묻는 화면이다. 부트 판정 불가는 기동이 끝났는지를 기계가 스스로 판정하지 못해 사람에게 알린 것이다. 팀 편성 통지는 여러 대를 동시에 띄우는 과정에서 일부만 준비됐다는 알림이고, 컨텍스트 순환 검증은 작업 기억을 정리한 뒤 잘 복원됐는지 확인한 기록이다. 통지성 승인과 행위 승인은 이 글이 다루는 두 층이다.

이 이름들을 나란히 놓고 보면 성격이 갈린다. 앞의 네 가지는 대체로 무엇이 이러이러한 상태다라고 알리는 쪽이고, 마지막 하나는 무엇을 하겠다고 요구하는 쪽이다. 우리가 두 층이라고 부르는 것이 바로 이 갈림이다. 다만 이름이 성격을 정하는 것은 아니므로, 이름이 아니라 그 항목이 요구하는 일이 무엇인지를 보고 판단해야 한다.

수치에는 시각이 붙어야 수치다. 같은 원장이 그날 이른 시각에는 지금보다 작았다. 원장은 계속 자라기 때문에, 시각 없는 건수는 다음 주에 읽으면 틀린 값이 된다. 그래서 위 표에는 측정 시각을 함께 적었다.

범위를 밝혀 둔다. 이것은 우리 한 팀의 원장이다. 모든 사용자가 이 분포를 본다는 주장이 아니다. 우리 환경은 여러 대의 에이전트를 동시에 돌리는 구성이라 일반 사용자보다 기동 관련 항목이 많이 쌓인다.

그리고 우리가 이 표를 만들면서 걸러낸 문장이 하나 있다. 우리 기록에는 승인이 사람을 가장 자주 멈춰 세운 항목이라고 적었다가 발행 전 기계 검사에서 걸러낸 자국이 남아 있다. 실제로 세어 보니 건수가 가장 많은 것은 첫 실행 신뢰 관문 24건이었고 그다음이 부트 판정 불가 22건이었다. 승인 계열은 그 뒤였다. 체감이 컸던 것과 건수가 많은 것은 달랐다.

기록이 없으면 셀 수 없다. 우리가 위 표를 만들 수 있었던 것은 요청과 결정이 한 줄씩 쌓이는 파일을 두고 있었기 때문이다. 그런 파일이 없으면 승인이 몇 번 떴는지, 그중 어떤 성격이 많았는지를 나중에 확인할 방법이 없고, 남는 것은 사람의 인상뿐이다. 그리고 인상은 실제 분포와 달랐다 — 바로 위 문단이 그 사례다. 도구가 그런 기록을 남기지 않는다면, 적어도 승인 프롬프트가 떴을 때 어떤 종류였는지를 며칠만 손으로 적어 보는 것으로도 갈래가 보인다.

확인 방법. 자기 도구에도 승인 기록이 남는 곳이 있다면 유형별로 세어 보라. 세어 보기 전의 인상과 세어 본 결과가 다를 수 있다. 그리고 셀 때는 그 수를 언제 셌는지를 같이 적어 두라.

3. 상태 통지까지 사람에게 보냈더니 기동이 막혔다

이 항목도 우리가 직접 측정한 것이다.

증상. 안전하게 하려고 승인이 필요한 항목을 넉넉히 잡아 두면, 사람이 답해 줄 때까지 아무 일도 진행되지 않는다. 특히 도구를 켜는 단계에서 이런 항목이 몰리면 시작 자체가 안 된다.

우리가 겪은 것. 우리 원장에서 통지성으로 분류되는 항목은 21건이었다. 이런 항목은 기계가 상태를 알리려고 올린 것이다. 부트 판정이 안 된다거나, 첫 실행 관문이 감지됐다거나, 팀 편성이 일부만 끝났다거나, 컨텍스트 순환이 검증됐다는 식이다. 사람이 답을 해야 다음이 진행되는 구조로 두면, 이런 알림 하나하나가 전부 정지선이 된다.

우리가 바꾼 방식. 통지성 항목은 근거를 적고 자동으로 종결하게 했다. 중요한 것은 종결 자체가 아니라 근거를 적는다는 쪽이다. 무엇을 보고 종결했는지가 원장에 남지 않으면, 나중에 그 판단이 옳았는지 확인할 방법이 없어진다. 조용히 넘어가는 것과 근거를 남기고 넘어가는 것은 다른 일이다.

근거에 무엇을 적는가. 우리가 남기는 것은 세 가지다. 무엇을 보고 그렇게 판정했는지, 그 시점에 상태가 어땠는지, 그리고 왜 이 항목이 기록만 닫는 쪽이라고 봤는지다. 세 번째가 빠지면 나중에 그 판단을 다시 검토할 수 없다. 종결 자체는 한 줄이면 되지만 근거가 없으면 그 한 줄은 기록이 아니라 흔적일 뿐이다.

종결한다는 것이 알리지 않는다는 뜻은 아니다. 우리는 통지성 항목의 알림 기록만 자동으로 닫고, 그 기록을 지우지는 않는다. 사람이 나중에 훑어볼 수 있게 남겨 두고, 같은 알림이 반복되면 그 반복 자체가 신호가 된다. 진행을 막지 않는 것과 보이지 않게 하는 것은 다른 일이고, 우리가 없앤 것은 앞쪽이다. 이 구분을 놓치면 통지성 자동화가 그냥 알림 끄기가 된다.

★자동 종결이 무엇을 하고 무엇을 하지 않는지 못박아 둔다. 우리 자동 종결은 알림 기록을 닫는 것이다. 그것은 실제 신뢰 화면이나 권한 화면에 승인 입력을 보내지 않고, 막혀 있던 실행을 풀지도 않는다. 이 구분이 중요한 이유는, 어떤 화면이 떴다는 것을 감지하는 일과 그 화면에 응답하는 일이 서로 다른 일이기 때문이다. 감지 기록을 자동으로 닫는 것은 우리가 하는 일이고, 화면에 대신 답하는 것은 우리가 하지 않는 일이다. 이 글의 다른 항목에서 첫 실행 신뢰 화면 이야기가 나오는데, 그 화면에 자동으로 답해도 된다는 뜻으로 읽지 않기 바란다.

이것이 안전하다는 뜻은 아니다. 우리 환경에서 이 항목들이 기록만 닫는 성격이라고 판단해서 그렇게 그은 것이다. 같은 이름의 알림이라도 자기 환경에서 그 처리가 무언가를 실행하거나 권한을 열거나 차단을 푼다면 이 선은 그대로 쓸 수 없다.

확인 방법. 자동으로 종결되는 항목이 있다면 그 기록에 근거가 함께 남는지 확인하라. 근거 없이 종결만 되어 있으면, 그것은 자동화가 아니라 그냥 안 보이게 만든 것이다.

4. 되돌릴 수 없는 행위를 기계가 대신 누르면 정지 경계가 사라진다

이 항목이 이 글에서 단정하는 유일한 대목이다.

단정. 되돌릴 수 없는 행위는 사람 게이트로 남겨라. 우리가 그 목록으로 쓰는 것은 다음과 같다.

발행 . 배포 . 과금 . 삭제 . 외부 발송

왜 이것만 단정하는가. 앞의 항목들은 우리 환경에서의 선택이라 자기 환경에서 달라질 수 있다. 그런데 이 목록은 성격이 다르다. 이 행위들은 실행되고 나면 실행 전으로 돌아갈 수 없다. 잘못 눌렸을 때 고칠 기회가 없다는 뜻이고, 그래서 판단을 자동화의 대상으로 두지 않는 것이 우리 설계의 기준선이다. 우리 시스템에서 이 목록은 승인 요청의 대상이 아니라 무조건 멈추고 사람에게 묻는 대상이다.

기계가 대신 누르면 무엇이 사라지는가. 게이트가 하는 일은 막는 것이 아니라 사람이 개입할 지점을 만드는 것이다. 그 지점을 기계가 통과시키면 게이트는 형태만 남고 기능은 없어진다. 그러면 문제가 생겼을 때 어디서 멈췄어야 하는지를 되짚을 자리도 함께 사라진다.

정지 경계라는 말을 풀어 두면 이렇다. 자동화된 작업에는 사람이 개입하기로 미리 정해 둔 지점이 몇 군데 있다. 그 지점이 있으면 잘못된 방향으로 가더라도 거기서 한 번 멈춘다. 그 지점을 기계가 통과시키기 시작하면, 남는 것은 사람이 나중에 결과를 발견하는 것뿐이다. 되돌릴 수 있는 일이라면 발견한 뒤에 고치면 되지만, 되돌릴 수 없는 일은 발견해도 고칠 것이 없다. 그래서 우리는 이 목록만큼은 자동화의 대상으로 두지 않는다.

요청자와 결재자를 나눈다. 우리는 행위 승인을 다룰 때 요청하는 쪽과 결재하는 쪽을 같은 주체로 두지 않는다. 일을 만든 쪽이 그 일의 허락도 스스로 내주면 게이트가 자기 자신을 통과시키는 구조가 되기 때문이다. 다만 시각 두 개로 이 구분을 확인했다고 말할 수는 없다. 시각은 순서와 만료를 보는 참고값이다.

왜 그 구분이 중요한가. 일을 만든 쪽이 그 일의 허락도 스스로 내주면, 형식적으로는 승인 절차가 있지만 실질적으로는 아무도 검토하지 않은 것이 된다. 그런데 기록만 보면 승인을 거친 것처럼 보이기 때문에 나중에 이 상태를 알아채기 어렵다. 그래서 확인해야 하는 것은 시각이 아니라 세 가지다. 요청과 결정이 서로 연결돼 있는가, 승인한 사람이 누구이고 그 사람에게 그 권한이 있는가, 그리고 승인한 대상과 범위가 실제 실행된 것과 같은가. 같은 주체가 시간을 두고 요청하고 스스로 승인할 수도 있고, 서로 다른 주체가 기록 정밀도 안에서 같은 시각에 남을 수도 있다. 그래서 시각만으로는 갈리지 않는다. 이 셋을 확인할 수 없으면 통과라고 하지 말고 분리 여부 미확인으로 남겨라.

확인 방법. 자기 설정에서 허용 목록을 훑어보고, 위 다섯 가지에 해당하는 동작이 자동 허용에 들어가 있는지 본다. 특히 명령 한 줄로 외부에 무언가를 내보내거나 지우는 동작이 포함돼 있는지를 본다. 들어가 있다면 그것이 의도한 것인지 다시 판단하기를 권한다.

5. 무엇을 말하는 화면과 무엇을 요구하는 화면을 감시 장치가 구별하지 못했다

이 항목도 우리가 직접 측정한 것이다. 두 층을 갈라 놓아도 남는 함정이다.

증상. 승인 프롬프트를 자동으로 알아채는 장치를 두면, 그 장치가 가짜 프롬프트를 잡는 일이 생긴다.

우리가 겪은 것. 우리 감시 장치는 화면에 나타난 문면을 보고 승인 프롬프트를 탐지한다. 그런데 그 화면에 승인 프롬프트를 설명하는 우리 문장이 떠 있으면, 장치는 그것도 프롬프트로 잡았다. 즉 보고서가 경보를 만들었다. 승인에 대해 쓴 글이 승인 요청으로 감지된 것이다.

초보용으로 옮기면 이렇다. 문면으로만 판별하는 방식은 무엇을 말하는 화면과 무엇을 요구하는 화면을 구별하지 못한다. 사람에게는 너무 당연한 차이인데, 글자만 보는 쪽에서는 같은 글자다.

독자에게도 같은 형태가 온다. 승인이나 권한에 대해 문서를 쓰거나, 화면을 캡처해 두거나, 오류 메시지를 그대로 붙여 놓은 파일을 열어 두면, 화면 글자를 보는 장치에게는 그것이 실제 요청과 같은 모양이다. 설명하려고 만든 것이 감지 대상이 되는 것이다.

오류의 방향도 봐야 한다. 우리 경우에는 실제로 존재하지 않는 요청이 감지된 쪽이었다. 이 방향이 무해하다고는 말할 수 없다. 탐지 뒤에 자동 응답이 연결돼 있으면 그 응답이 무엇을 대상으로 무슨 일을 하는지에 따라 결과가 달라지기 때문이다. 기록을 남긴다는 것만으로 이 공백이 메워지지도 않는다. 반대 방향, 즉 실제 요청이 있는데 감지되지 않는 쪽도 있는데, 우리는 그 반대 방향을 세어 본 적이 없다. 그러니 이 항목에서 우리가 말할 수 있는 것은 한 방향의 오탐을 봤다는 것까지다.

이것이 왜 두 층 이야기와 이어지는가. 두 층을 잘 갈라 놓아도, 그 갈라진 층에 항목을 넣어 주는 장치가 잘못 넣으면 분류는 소용이 없다. 우리 경우에는 존재하지 않는 요청이 통지성 쪽으로 들어왔다. 반대 방향으로 틀렸다면 더 곤란했을 것이다.

확인 방법. 자동 감지 장치가 있다면 그 장치가 무엇을 근거로 판정하는지 확인하라. 화면 글자를 근거로 한다면 글자가 같기만 하면 걸린다는 뜻이다. 감지 기록을 훑어 실제 요청이 아닌 항목이 섞여 있는지 한 번 세어 보기를 권한다.

6. 승인 창이 닫힌 뒤 도착한 결재를 쓸 수 없었다

이 항목도 우리가 직접 측정한 것이다.

증상. 승인은 났는데 일이 진행되지 않는다. 기록에는 요청이 남아 있고 결재도 있었는데 결과가 없다.

우리가 겪은 것. 승인 요청에는 대기 창이 있다. 정해진 시간 안에 답이 오지 않으면 창이 닫힌다. 그런데 창이 닫힌 뒤에 결재가 도착한 경우가 있었고, 그 결재를 소비할 경로가 없었다. 그래서 그 항목들은 미결 상태로 남았다. 우리 기록에서 그렇게 남은 항목이 4건이다.

초보용으로 옮기면 이렇다. 승인에는 시간 축이 있다. 허락할 것인지만 설계하고 언제까지를 설계하지 않으면, 늦게 도착한 허락이 갈 곳을 잃는다. 그리고 이 상태는 거절보다 알아채기 어렵다. 거절은 결과가 분명한데, 미결은 아무 일도 일어나지 않은 것과 화면에서 똑같아 보인다.

느린 것과 멈춘 것을 가르는 법. 화면만 보면 둘이 같아 보인다. 우리가 쓰는 구분은 기록 쪽이다. 요청은 남아 있는데 그에 대응하는 결정 줄이 없고 대기 시간도 이미 지났다면, 그것은 느린 것이 아니라 멈춘 것이다. 이 판별이 가능하려면 요청과 결정이 각각 시각과 함께 남아 있어야 한다.

그래서 우리가 시간 축에서 정해 두는 것. 창을 얼마나 열어 둘지, 창이 닫혔을 때 그 요청을 어떤 상태로 남길지, 그리고 닫힌 뒤에 도착한 답을 어떻게 처리할지 세 가지다. 우리는 앞의 두 가지는 정해 두고 있었고 세 번째를 정해 두지 않았다. 그 빈칸이 위의 미결 항목으로 나타났다. 그 빈칸을 어떻게 메울지는 아직 우리도 정하지 못했고, 정하지 못했다는 사실을 그대로 적어 둔다.

확인 방법. 승인 기록에서 대기 시간 초과로 끝난 항목이 있는지 세어 보라. 그리고 그 항목들이 나중에 어떻게 처리됐는지 따라가 보라. 따라갈 경로가 없다면 그것이 이 문제다.

7. 우리가 그은 경계와 그 이유

여기까지가 우리가 겪은 것이고, 이 항목은 그것을 우리가 어떻게 정리했는지다. 다시 밝혀 두지만 이것이 안전한 설정이라는 뜻이 아니다. 우리가 어디에 선을 그었고 왜 거기에 그었는지를 적는 것이다. 자기 환경의 위험은 자기 것이고, 이 선을 그대로 옮겨 쓰는 것은 권하지 않는다.

우리가 쓰는 판별 질문. 요청 하나를 놓고 이 처리가 기록만 닫는지를 먼저 묻는다. 답이 갈리는 지점에서 처리도 갈린다.

기록만 닫는다              ->  근거를 적고 종결할 수 있다
실행 . 권한 부여 . 차단 해제  ->  통지가 아니다
  기존 승인 범위 안인가
  대상은 무엇인가
  부수효과가 있는가
  복구 비용은 얼마인가
  넷 중 하나라도 확인 불가  ->  사람에게 보낸다
발행 . 배포 . 과금 . 삭제 . 외부 발송  ->  사람 게이트

기록만 닫는 쪽에 우리가 넣은 것. 기계가 올린 상태 통지다. 부트 판정 관련, 첫 실행 관문 감지, 컨텍스트 순환 검증, 팀 편성 통지 같은 항목이다. 이유는 이 항목들이 무언가를 하겠다고 요구하는 것이 아니라 무언가를 알리는 것이기 때문이다. 다만 종결할 때 근거를 함께 적는다.

사람 게이트로 남긴 쪽. 발행, 배포, 과금, 삭제, 외부 발송이다. 이유는 4번 항목에 적은 그대로다. 실행 후에 실행 전으로 돌아갈 수 없기 때문이다. 그리고 그 목록 밖이라도 상태를 바꾸는 처리는 통지로 분류하지 않는다. 그때는 기존에 승인된 범위 안인지, 대상이 무엇인지, 부수효과가 있는지, 복구 비용이 얼마인지를 확인하고, 넷 중 하나라도 확인되지 않으면 사람에게 보낸다.

경계에 걸치는 것은 사람에게 보낸다. 애매할 때 어느 쪽으로 기울일지를 미리 정해 두지 않으면 그때그때 편한 쪽으로 기울게 된다. 우리는 판단이 서지 않으면 사람에게 묻는 쪽으로 정했다. 그 선택의 대가는 속도이고, 우리는 그 대가를 지불하기로 한 것이다. 다르게 정할 수도 있고, 그것은 각자의 판단이다.

판별 질문이 잘 안 통하는 자리도 있다. 기록만 닫는 것처럼 보이는데 실제로는 무언가가 함께 실행되는 경우다. 예를 들어 알림 하나를 닫는 처리가 그 김에 대기 중이던 작업을 다시 돌리게 되어 있으면, 그것은 기록을 닫은 것이 아니라 실행을 시킨 것이다. 우리는 이런 자리에서 처리가 실제로 무엇을 건드리는지 확인하고, 확인되지 않으면 사람에게 보낸다. 이것도 우리 선택이고 더 나은 방법이 있을 수 있다.

우리가 하지 않은 것도 적어 둔다. 우리는 자동 승인의 비율을 얼마로 두는 것이 좋은지 측정한 적이 없다. 어떤 설정이 얼마나 위험한지도 등급으로 재 본 적이 없다. 그래서 이 글에는 몇 퍼센트를 열라거나 어떤 설정이 더 위험하다는 이야기가 없다. 세어 보지 않은 것은 쓰지 않는 것이 우리 규칙이다.

처음 정할 때 우리가 쓴 순서. 우리는 허용 목록을 먼저 짜지 않았다. 며칠 동안 올라오는 요청을 그냥 받아 보면서 어떤 것들이 실제로 오는지를 봤고, 그다음에 각 항목에 그것이 기록만 닫는 처리인지를 물었고, 마지막에 그 답에 따라 목록을 만들었다. 목록을 먼저 만들면 실제로 오지도 않는 항목을 상상해서 넣게 되고, 정작 자주 오는 항목은 빠진다. 이 순서도 우리 방식이고 더 나은 순서가 있을 수 있다.

확인 방법. 지금 자기 설정에서 자동 허용된 항목을 한 줄씩 읽으면서 이것이 기록만 닫는 처리인지를 묻는다. 무언가가 실행되거나 권한이 열리거나 막혀 있던 것이 풀리는 항목이 자동 허용에 들어가 있으면, 그 자리가 이 글이 말하는 지점이다.

정리 — 확인할 것 다섯 가지

첫째, 승인 요청을 하나의 덩어리로 보지 않는다. 전부 열거나 전부 닫는 두 선택만 남는 이유가 그것이다. 무엇을 알리는 항목과 무엇을 하겠다고 요구하는 항목은 다르게 다룰 수 있다.

둘째, 가르는 질문은 이 처리가 기록만 닫는가다. 되돌릴 수 있는가는 기준이 되지 못한다 — 되돌릴 수 있는 일도 실제 행위이기 때문이다. 무언가가 실행되거나 권한이 열리거나 차단이 풀리면 통지로 분류하지 않고, 기존 승인 범위·대상·부수효과·복구 비용을 확인한다. 확인되지 않으면 사람에게 보낸다.

셋째, 되돌릴 수 없는 행위는 사람 게이트로 남겨라. 발행, 배포, 과금, 삭제, 외부 발송이 우리가 쓰는 목록이다. 이것이 이 글에서 단정하는 유일한 항목이고, 근거는 실행 후에 되돌릴 수 없다는 성질 하나다.

넷째, 자동 감지 장치는 무엇을 근거로 판정하는지 확인한다. 화면 글자로 판정하면 무엇을 말하는 화면과 무엇을 요구하는 화면을 구별하지 못한다. 우리 경우에는 승인을 설명한 문장이 승인 요청으로 잡혔다.

다섯째, 승인에는 시간 축이 있다. 허락 여부만 설계하고 언제까지를 설계하지 않으면 늦게 도착한 결재가 갈 곳을 잃는다. 그 상태는 아무 일도 없는 것과 화면에서 똑같아 보이므로 기록을 세어 봐야 보인다.

마지막으로 하나만 덧붙인다. 이 글은 어떤 설정이 안전하다고 말하지 않았다. 우리가 그은 선과 그 이유를 적었을 뿐이고, 그 선도 우리 환경에서 나온 것이다. 다만 되돌릴 수 없는 행위를 사람 손에 남겨 두라는 것 하나는 환경과 무관하게 권한다. 되돌릴 수 없다는 것은 설정의 문제가 아니라 그 행위의 성질이기 때문이다.

원장에서 센 수와 그 한계

우리가 직접 측정한 것 (2026-09-08 22:5x 시점 · 우리 한 팀의 기록)

• 승인 원장 전수 92건과 그 유형 분포. 첫 실행 신뢰 관문 24, 부트 판정 불가 22, 통지성 승인 21, 행위 승인 12, 팀 편성 통지 7, 컨텍스트 순환 검증 6
• 통지성 승인과 행위 승인이 이미 서로 다른 유형으로 갈려 기록되고 있었다는 것. 두 층 구분이 사후 해석이 아니라 운영 중에 이미 갈려 있던 것이라는 근거다
• 건수가 가장 많은 항목이 승인 계열이 아니라 첫 실행 신뢰 관문이었다는 것. 우리 기록에는 그 반대로 적었다가 발행 전 기계 검사에서 걸러낸 자국이 남아 있다
• 감시 장치가 승인 프롬프트를 설명하는 우리 문장을 프롬프트로 탐지한 것. 문면 기반 판별의 한계 사례다
• 승인 대기 창이 닫힌 뒤 도착한 결재를 소비할 경로가 없어 미결로 남은 항목 4건
• 행위 승인 기록에 요청과 결정이 각각 시각과 함께 남는다는 것. 다만 그 두 시각으로 요청자와 결재자가 분리됐다고 판정할 수는 없다 — 시각은 순서와 만료의 참고값이고, 분리 여부는 요청과 결정의 연결·승인자와 그 권한·승인 대상과 범위의 일치로 확인해야 한다

이 글에서 우리 환경의 선택으로만 쓴 것 (일반 권고가 아니다)

• 통지성 항목을 근거와 함께 자동 종결하는 처리. 우리 환경에서 그 항목들이 기록만 닫는 성격이라고 판단해서 그은 선이다. 그 종결은 알림 기록을 닫을 뿐이고 화면에 승인 입력을 보내지 않는다
• 애매한 항목을 사람에게 보내는 규칙. 처리가 무엇을 건드리는지 확인되지 않으면 통지로 분류하지 않는다는 뜻이고, 속도를 대가로 지불하기로 한 우리 선택이다

우리가 측정하지 않아 쓰지 않은 것

• 어떤 설정이 얼마나 위험한지의 등급. 위험의 크기를 재 본 적이 없다
• 자동 승인 비율의 적정값. 비율을 두고 실험해 본 적이 없다
• 이 분포가 일반 사용자에게도 나타나는지 여부. 우리 한 팀의 원장만 셌다
• 두 층을 가르지 않으면 반드시 무너지는지 여부. 우리는 두 실패 형태를 각각 관측했을 뿐이고 그것이 모든 설계에서 필연이라는 것은 측정하지 않았다