[태그:] AI 에이전트

  • 리뷰어 세 좌석이 동시에 멈췄다 — 계정 하나를 나눠 쓰고 있었다

    리뷰어 세 좌석이 동시에 멈췄다 — 계정 하나를 나눠 쓰고 있었다

    중요한 판단을 도우미 하나에게만 맡기는 것이 불안할 때가 있다. 그래서 같은 것을 여러 쪽에 따로 물어본다. 우리도 그렇게 하려고 검토 담당 자리를 여러 개 두었다. 이 글은 그렇게 나눠 둔 자리들이 같은 날 한꺼번에 멈춘 이야기다.

    이 글은 회사에 빗대어 쓴다. 끝까지 그 하나로만 간다. 검사 담당자를 세 팀에 따로 뒀는데, 셋이 같은 회원 카드 한 장으로 출입하고 있었다는 그림이다. 카드 한 장의 하루 출입 횟수가 정해져 있다면, 셋이 나눠 쓰는 순간 셋 다 그 한도 안에 갇힌다.

    용어 둘만 풀어 둔다. 자리는 어떤 담당이 앉아 일하는 한 칸이다. 우리는 도우미 하나를 자리 하나에 앉힌다. 교차검증서로 다른 쪽에게 같은 것을 따로 보게 하는 것이다. 한쪽이 놓친 것을 다른 쪽이 잡아 주기를 기대하고 하는 일이다. 이 둘만 알면 나머지는 따라온다.

    비유를 한 번 더 풀어 둔다. 회원 카드에 붙은 한도는 사람 수와 무관하게 정해진다. 한 사람이 쓰든 세 사람이 나눠 쓰든 그 카드로 들어갈 수 있는 횟수는 같다. 그래서 사람을 늘리면 한 사람이 쓸 수 있는 몫이 줄어든다. 늘어난 것은 손이고 줄어든 것은 각자의 몫이다.

    논지는 한 줄이다. 일하는 자리를 나누면 실행은 갈라지지만, 바깥 서비스의 계정은 갈라지지 않는다. 내 쪽에서 무엇을 몇 개로 나누든 그것은 내 쪽 사정이다. 한도를 세는 쪽은 바깥이고, 바깥은 카드 한 장을 보고 센다.

    앞선 편과의 경계. 자리는 있는데 사람이 없어서 지시가 삼켜진 이야기는 앞 편에 적었다. 이 글은 반대다 — 자리도 있고 사람도 있었다. 막힌 곳이 안쪽이 아니라 바깥이었다.

    이 글이 도움이 되는 사람. 같은 것을 여러 쪽에 따로 물어보는 사람이다. 하나에게만 맡길 때는 이 문제가 생기지 않는다 — 나눌 것이 없으니 나뉘지 않을 것도 없다. 검토를 둘 이상으로 늘리는 순간, 늘린 것이 무엇이고 늘지 않은 것이 무엇인지가 갈린다.

    근거의 범위를 먼저 밝혀 둔다. 이 글의 근거는 우리가 겪은 한 사건이다. 이 일이 얼마나 자주 나는지 우리는 세지 않았고, 다른 서비스의 한도 정책이 어떻게 되어 있는지도 재지 않았다. 그래서 이 글에 그런 문장이 없다.

    검토 자리를 셋으로 나눠도 바깥 계정이 하나면 총량이 늘지 않는다는 것을 칸으로 나눠 그린 도식. 첫째 칸은 우리가 나눈 것으로, 검증 담당 자리를 셋으로 두고 서로 다른 실행 묶음에 각각 배치했으며 화면에는 셋이 따로 떠 있었다고 적혀 있다. 둘째 칸은 바깥이 세는 것으로, 계정 하나를 셋이 나눠 쓰고 있었고 한도는 그 계정에 붙어 있으며 한 곳이 많이 쓰면 나머지가 줄어든다고 적혀 있다. 셋째 칸은 그래서 일어난 일로, 세 자리가 같은 시각에 개인 할당량 소진으로 멈췄고 다시 쓸 수 있게 되는 시각도 거의 같았으며 그 겹침이 카드 한 장이라는 근거였다고 적혀 있다. 넷째 칸은 그동안 화면으로, 자리 목록도 편성 점검도 정상이었고 자리는 열려 있었고 담당도 걸려 있었으며 그 상태로 엿새 동안 아무 일도 못 했다고 적혀 있다. 아래 칸은 갈라 적기다. 있는지 확인하는 검사는 자리가 열려 있는지를 보고, 되는지 확인하는 검사는 실제로 일을 시켜 본다는 것, 그리고 우리를 깨운 것은 점검이 아니라 실제로 시켜 본 일이었다는 것이 적혀 있다. 맨 아래 두 줄은 한정이다. 관측은 한 번이라는 것, 그리고 다른 서비스의 한도 정책은 우리가 재지 않았다는 것이다.
    계정을 어떻게 써야 한다는 그림이 아니다. 우리 쪽에서 나눈 수와 바깥에서 세는 수가 다르다는 것, 그리고 정상 표시가 되는 것의 증거가 아니라는 것을 그린 것이다. 아래 두 줄은 한정이다.

    세 자리가 함께 멈춘 날

    1. 우리가 나눈 수와 바깥이 세는 수는 다른 수다

    증상. 여러 쪽에 따로 검토를 맡겨 두었는데, 어느 날 그 검토가 하나도 돌아오지 않는다. 자리를 확인해 보면 셋 다 그대로 있다. 그런데 셋 다 일을 하지 않는다.

    여기서 갈리는 두 가지 해석. 하나는 우연히 셋이 동시에 고장 났다고 보는 것이다. 다른 하나는 내가 셋에게 일을 제대로 보내지 않았다고 보는 것이다. 우리 기록에서는 둘 다 아니었다. 셋은 멀쩡했고 일도 갔다. 셋이 같은 문 앞에서 막혔다.

    교차검증을 하는 이유부터 짚어 둔다. 같은 것을 여러 쪽에 따로 보게 하는 것은 한쪽이 놓친 것을 다른 쪽이 잡아 주기를 기대하는 일이다. 그러려면 그 여러 쪽이 서로 다른 조건에 있어야 한다. 같은 조건에 있는 셋은 같은 것을 놓친다.

    다양성을 늘리는 쉬운 방법. 검토를 늘리고 싶을 때 손쉬운 길은 자리를 하나 더 여는 것이다. 자리는 화면에 바로 뜨고 개수도 셀 수 있다. 그래서 자리를 늘리면 다양성이 늘었다는 감각이 함께 온다. 늘어난 것은 자리이고, 다양성은 그것과 다른 축에 있다.

    우리가 나눈 것. 우리는 검증 담당 자리를 셋으로 두고 서로 다른 실행 묶음에 각각 배치했다. 화면에는 셋이 따로 떠 있었고, 각자 자기 일감을 받았다. 여기까지는 우리가 의도한 대로였다.

    그 의도가 어디까지 이뤄졌는가. 자리를 셋으로 나눈 의도는 서로 다른 쪽에게 따로 보게 하는 것이었다. 실행을 나누는 데까지는 이뤄졌다. 셋이 서로 다른 조건에 있게 하는 데까지는 이뤄지지 않았다. 의도와 결과가 갈린 자리가 정확히 거기다.

    바깥이 센 것. 그 셋은 바깥 서비스를 쓴다. 그리고 그 서비스는 계정 하나를 보고 한도를 센다. 우리가 자리를 몇 개로 나눴는지는 바깥에서 보이지 않는다. 바깥에서 보이는 것은 같은 카드가 반복해서 들어온다는 것뿐이다.

    나눈다는 말이 무엇을 나누는가. 나누면 실행은 갈라진다. 셋은 각자 자기 일감을 붙들고 서로를 기다리지 않는다. 갈라지지 않는 것은 그 셋이 함께 쓰는 바깥 자원이다. 나뉘는 것과 나뉘지 않는 것을 갈라 적어 두지 않으면, 앞의 것을 보고 뒤의 것까지 나뉘었다고 읽는다.

    그래서 무엇이 어긋나는가. 자리를 늘리면 동시에 일하는 손은 늘어난다. 그런데 할 수 있는 총량은 늘지 않는다. 총량은 카드에 붙어 있기 때문이다. 손을 셋으로 늘리면 한 손이 많이 쓸 때 나머지 두 손이 그만큼 못 쓰게 된다.

    손이 늘면 무엇이 좋아지는가. 총량이 그대로여도 손이 느는 것에는 값이 있다. 같은 시간에 여러 갈래를 동시에 볼 수 있기 때문이다. 우리가 놓친 것은 그 값이 총량과 다른 값이라는 점이다. 동시에 보는 폭과 하루에 할 수 있는 양은 서로 다른 축이고, 자리를 늘리면 앞쪽만 는다.

    쓸 수 있는 형태는 여기까지다. 자리 수와 계정 수는 다른 수다. 우리가 본 것은 한 계정을 세 자리가 나눠 쓴 한 사건이고, 그 사건에서 그 두 수가 갈렸다. 그보다 넓은 규칙을 우리는 이 글에 쓰지 않는다.

    총량이 어디에 붙어 있는가. 이 물음이 이 글의 핵심이다. 총량이 자리에 붙어 있으면 자리를 늘릴 때 총량도 는다. 총량이 카드에 붙어 있으면 자리를 늘려도 총량은 그대로다. 어느 쪽인지는 내 화면이 아니라 바깥이 정하는 것이라, 물어보지 않으면 알 수 없다.

    세어 보기가 어려운 경우도 있다. 자리마다 어떤 계정을 쓰는지가 한 화면에 모여 있지 않으면, 그 수를 세려면 자리를 하나씩 열어 봐야 한다. 그 번거로움이 세지 않게 만드는 힘이다. 우리도 그래서 세지 않았다.

    확인 방법. 자기가 지금 굴리는 검토 자리를 세어 보고, 그 자리들이 쓰는 계정을 따로 세어 보라. 두 수가 다르면 그 차이만큼은 나눈 것처럼 보이지만 나뉘지 않은 것이다. 세어 보기 전에는 두 수가 같다고 가정하고 있는 셈이다.

    2. 세 자리가 같은 시각에 멈췄다

    이 항목은 우리가 실제로 겪은 것이고 관측 한 번이다.

    관측. 서로 다른 실행 묶음에 각각 배치한 검증 담당 세 자리같은 시각에 멈췄다. 멈춘 이유는 셋 다 같았다 — 개인 할당량을 다 썼다는 것이었다. 세 자리가 각각 다른 일감을 붙들고 있었는데도 그랬다.

    각각 다른 일감을 붙들고 있었다. 셋은 서로 다른 묶음에서 서로 다른 것을 보고 있었다. 보는 것이 다르면 쓰는 양도 다를 텐데, 그런데도 멈춘 시각이 같았다. 이것이 우리가 이 관측을 그냥 넘기지 못한 첫 이유다.

    처음에 든 생각. 우리는 이것을 우연으로 읽으려 했다. 셋이 마침 비슷하게 많이 썼을 수도 있다고 본 것이다. 각자 한도를 따로 갖고 있다면 세 개의 한도가 비슷한 시점에 차는 일이 아주 없을 수는 없다.

    그 표시가 준 인상. 멈춤에 붙은 문구는 개인 할당량을 다 썼다는 것이었다. 이 말은 한도가 각자에게 붙어 있다는 인상을 준다. 그 인상이 우연이라는 첫 해석을 오래 붙들게 했다. 말이 가리키는 단위와 실제로 세는 단위가 같으리라는 보장은 없다.

    그런데 그 해석은 다음 사실 앞에서 무너졌다. 셋의 다시 쓸 수 있게 되는 시각이 거의 같았다. 한도가 따로 있는 셋이라면 그 시각도 각자 다르게 잡힌다. 셋의 회복 시각이 나란히 붙어 있다는 것은 세는 쪽이 하나라는 뜻이다.

    회사로 옮겨 보면 이렇다. 세 팀의 검사 담당자가 같은 시각에 문 앞에서 막혔다. 그리고 다시 들어갈 수 있게 되는 시각도 셋이 같았다. 카드가 세 장이면 이런 모양이 나오지 않는다. 카드가 한 장일 때 나오는 모양이다.

    카드가 한 장이라는 것은 문 앞에서 보이지 않는다. 각 팀 화면에는 자기 담당자만 뜬다. 다른 팀 담당자가 오늘 몇 번 드나들었는지는 그 화면에 없다. 그래서 내 쪽 화면을 아무리 봐도 남은 한도가 얼마인지 알 수 없다.

    초보용으로 옮기면 이렇다. 여러 쪽이 동시에 멈췄다는 것만으로는 원인을 알 수 없다. 우연히 겹칠 수도 있기 때문이다. 그런데 다시 살아나는 시각까지 겹치면 그것은 우연으로 설명하기 어려워진다. 멈춘 시점보다 풀리는 시점이 더 많은 것을 말해 준다.

    같은 시각이라는 말에 대해. 우리는 그 겹침을 초 단위로 재어 적어 두지 않았다. 우리가 본 것은 셋이 나란히 멈췄고 나란히 풀렸다는 정도다. 그러니 이 글의 근거는 겹쳤다는 것이지 몇 초 안에 겹쳤다는 것이 아니다.

    한정을 적어 둔다. 우리는 이것을 한 차례 봤다. 같은 모양이 다시 나는지, 얼마나 자주 나는지 우리는 세지 않았다. 이 항목은 그 한 번의 관측을 적은 것이다.

    이 관측에서 남은 것. 사건 자체보다 어디를 봐야 하는지를 알게 된 것이 남았다. 여럿이 함께 멈추면 우리는 이제 각자의 사정을 보기 전에 셋이 공유하는 것이 무엇인지부터 본다. 공유하는 것이 있으면 그것이 먼저 의심할 자리다.

    확인 방법. 여러 쪽이 함께 멈췄으면 다시 쓸 수 있게 되는 시각을 각각 적어 보라. 그 시각들이 나란히 붙어 있으면 세는 쪽이 하나일 가능성을 먼저 확인해야 한다. 각자 다르게 잡혀 있으면 우연 쪽이다.

    3. 다시 쓸 수 있게 되는 시각이 겹친 것이 근거였다

    이 항목은 어떻게 알았는가에 대한 것이다. 앞 항목과 같은 사건을 다른 각도에서 본다.

    우리가 직접 본 것과 추론한 것을 갈라 적는다. 직접 본 것은 세 자리가 같은 시각에 멈췄다는 것과 회복 시각이 거의 같았다는 것이다. 추론한 것은 그 셋이 한 계정을 나눠 쓰고 있었다는 것이다. 앞은 관측이고 뒤는 그 관측에서 끌어낸 결론이다.

    
    본 것    세 자리가 같은 시각에 멈췄다
    본 것    다시 쓸 수 있게 되는 시각이 거의 같았다
    추론     한도를 세는 쪽이 하나다 = 계정 하나를 셋이 나눠 쓴다
    

    이 추론이 서는 이유. 한도가 각자에게 붙어 있으면 차는 시점도 풀리는 시점도 각자 따로 잡힌다. 셋이 같은 창을 공유할 이유가 없기 때문이다. 반대로 한도가 계정 하나에 붙어 있으면 그 창은 하나뿐이고, 셋은 같은 창이 열릴 때까지 함께 기다린다.

    왜 관측과 추론을 갈라 적는가. 갈라 두면 나중에 뒤집을 자리가 분명해지기 때문이다. 새 사실이 나왔을 때 바꿔야 하는 것은 대개 추론 쪽이고, 관측은 그대로 남는다. 둘을 한 문장에 섞어 적으면 무엇을 고쳐야 할지 알기 어려워진다.

    이 추론이 서지 않는 경우도 적어 둔다. 셋이 각자 한도를 갖고 있는데 우연히 비슷한 시각에 찼고 회복 창의 길이도 같다면, 겉모양이 비슷해질 수 있다. 우리는 그 가능성을 완전히 배제하는 실험을 하지 않았다. 우리가 한 것은 둘 중 어느 쪽이 더 그럴듯한지를 본 것이고, 이 글의 결론은 그 판단까지다.

    거의 같았다는 말도 그대로 둔다. 셋의 회복 시각은 거의 같았지 정확히 같지 않았다. 그 차이를 우리는 재지 않았고, 그 차이가 무엇에서 왔는지도 모른다. 정확히 같았다고 적으면 우리가 재지 않은 것을 잰 것처럼 쓰는 일이 된다.

    초보용으로 옮기면 이렇다. 원인을 찾을 때 같이 일어난 것만 보면 우연과 구별되지 않는다. 같이 풀리는 것까지 보면 구별이 쉬워진다. 함께 멈추는 것은 여러 이유로 생기지만, 함께 풀리는 것은 같은 시계를 보고 있다는 뜻이기 때문이다.

    이 결론을 확정으로 쓰지 않는 이유. 우리가 본 것은 한 사건이다. 그 한 사건 안에서는 이 설명이 잘 맞았지만, 한 사건은 규칙이 되기에 모자란다. 그래서 이 글은 이 결론을 우리 한 사건에 대한 설명으로 두고, 그 밖으로 넓히지 않는다.

    확인 방법. 어떤 두 가지가 같은 원인에서 나왔는지 보고 싶으면 시작 시각만 보지 말고 끝나는 시각도 보라. 둘 다 겹치면 공통 원인 쪽이고, 시작만 겹치면 아직 모르는 것이다.

    4. 그동안 화면은 전부 정상이었다

    이 항목은 왜 엿새나 걸렸는가에 대한 것이다.

    관측. 그 기간에 자리 목록도 정상이었고 편성 점검도 정상이었다. 자리는 열려 있었고 담당도 그 자리에 걸려 있었다. 화면만 보면 검토 체계가 갖춰져 있는 상태였다.

    그 상태로 무슨 일이 있었는가. 엿새 동안 아무 일도 못 했다. 검토를 맡길 수 없었으니 그 자리들이 하기로 한 일이 전부 밀렸다. 그동안 화면은 계속 정상이라고 말하고 있었다.

    왜 화면이 정상이었는가. 그 화면들이 재는 것은 자리가 열려 있는가이기 때문이다. 자리는 실제로 열려 있었다. 담당이 걸려 있는지도 재고 있었고, 그것도 사실이었다. 화면은 틀린 말을 하지 않았다. 재지 않은 것을 말하지 않았을 뿐이다.

    점검은 만든 사람이 정한 것만 본다. 점검 목록에 없는 항목은 정상으로 표시되는 것이 아니라 아예 물어지지 않는다. 물어지지 않은 것은 화면에 자리를 차지하지 않으니, 빠져 있다는 사실도 화면에 없다. 목록에 무엇이 있는지는 목록을 열어야만 알 수 있다.

    정상이라고 말한 화면이 하나가 아니었다. 자리 목록도 정상이었고 편성 점검도 정상이었다. 서로 다른 두 화면이 같은 말을 하면 확인이 두 번 된 것처럼 느껴진다. 그런데 두 화면이 같은 것을 재고 있으면 그것은 한 번 잰 것이다.

    여기가 이 절의 요점이다. 우리가 알고 싶었던 것은 지금 검토를 맡길 수 있는가였다. 화면이 답하고 있던 것은 자리가 준비돼 있는가였다. 두 물음은 다른 물음인데, 화면 하나가 둘 다 답해 주는 것처럼 읽혔다.

    정상 표시가 오래 유지되면 생기는 것. 사람은 같은 화면을 계속 다시 읽지 않는다. 같은 표시가 이어지면 그 표시를 배경으로 넘기게 된다. 그러면 그 화면은 정보를 주는 자리에서 안심을 주는 자리로 바뀐다. 우리 경우 그 안심이 엿새 동안 이어졌다.

    초보용으로 옮기면 이렇다. 점검 화면이 초록색이라는 것은 그 점검이 보는 항목이 정상이라는 뜻이다. 그 항목 목록에 내가 궁금한 것이 들어 있는지는 따로 확인해야 한다. 초록색은 확인했다는 뜻이 아니라 확인한 것들이 정상이라는 뜻이다.

    엿새라는 기간에 대해. 그 기간은 일이 멈춰 있던 기간이자 정상 표시가 유지된 기간이다. 뒤쪽이 앞쪽을 늘렸다. 이상하다는 신호가 어디에도 없으면 확인하러 갈 이유가 생기지 않기 때문이다.

    밀린 일에 대해. 검토 자리가 하기로 한 일은 대개 다른 일의 앞 단계다. 검토가 서면 그 뒤에 올 것도 함께 선다. 그래서 멈춘 기간의 값은 그 기간에 검토가 못 한 양만이 아니라, 그 뒤에서 기다린 양까지 합친 것이 된다. 그 합을 우리는 세지 않았다.

    초록색을 의심하라는 말이 아니다. 점검은 그 값을 하는 일을 한다 — 목록에 있는 항목이 어긋나면 그때는 알려 준다. 우리가 놓친 것은 그 목록에 무엇이 들어 있는지를 한 번도 읽어 보지 않았다는 점이다. 화면을 믿은 것이 아니라 화면이 무엇을 재는지 모른 채 믿은 것이다.

    확인 방법. 자기가 쓰고 있는 점검 화면에서 무엇을 재고 있는지 목록을 한 번 열어 보라. 거기에 바깥 서비스를 실제로 쓸 수 있는가가 들어 있는지가 볼 지점이다. 들어 있지 않으면 그 항목은 초록색이 답해 주지 않는 항목이다.

    5. 있는지 확인하는 검사와 되는지 확인하는 검사는 다르다

    이 항목은 어떻게 발견했는가에 대한 것이고, 우리 쪽 몫을 적는 자리다.

    발견 경위. 점검이 잡아낸 것이 아니다. 실제로 일을 시켜 보고 알았다. 검토를 하나 맡겼고, 그것이 돌아오지 않아 들여다봤고, 거기서 멈춰 있는 것을 봤다. 우리를 깨운 것은 화면이 아니라 일감이었다.

    두 검사를 갈라 적으면 이렇다.

    
    있는지 확인    자리가 열려 있는가 · 담당이 걸려 있는가
    되는지 확인    실제로 하나 시켜 보고 결과가 돌아오는가
    

    앞의 것은 싸고 뒤의 것은 비싸다. 자리가 열려 있는지는 목록만 읽으면 되지만, 되는지 보려면 실제로 한 번 써야 한다. 쓰면 그만큼 한도를 쓴다. 그래서 되는지 확인하는 검사를 자주 돌리기는 어렵다.

    그러면 얼마나 자주 해 봐야 하는가. 그 주기를 우리는 정해 두지 않았고 재지도 않았다. 말할 수 있는 것은 한 번도 해 보지 않으면 알 수 없다는 것까지다. 우리 경우 그 한 번이 엿새 뒤에 왔다.

    그래도 갈라 두어야 하는 이유. 두 검사를 하나로 여기면 싼 검사가 비싼 검사의 답까지 준다고 믿게 된다. 우리 경우가 그랬다. 자리 목록이 정상이라는 것을 보고 검토 체계가 돌아간다고 읽었다. 목록은 그런 말을 한 적이 없다.

    두 검사를 함께 쓰는 방법. 싼 검사는 자주 돌리고, 비싼 검사는 가끔 돌리되 돌렸다는 사실을 기록해 두는 것이다. 그러면 마지막으로 실제로 시켜 본 것이 언제인지가 남는다. 그 시각이 오래되어 있으면, 지금 초록색이 무엇을 근거로 초록색인지 다시 물어볼 수 있다.

    우리 쪽 몫을 적어 둔다. 바깥 서비스가 계정 하나로 한도를 세는 것은 그쪽 방식이고, 그 방식을 우리가 확인하지 않은 채 자리를 셋으로 나눈 것이 우리 쪽 몫이다. 나눈다고 나뉘는지를 물어보지 않았다.

    왜 물어보지 않았는가. 나누는 동작이 우리 쪽에서 완결되기 때문이다. 자리를 셋으로 두는 일은 우리 손으로 끝나고, 끝나면 셋이 화면에 뜬다. 거기서 바깥도 셋으로 보는가를 물으려면 한 걸음을 더 가야 하는데, 화면이 이미 셋을 보여 주고 있어서 그 걸음을 건너뛰게 된다.

    우리 쪽 몫을 적는 이유. 바깥 방식을 탓하는 문장으로 끝내면 다음에 할 일이 남지 않는다. 우리가 할 수 있었던 것은 나눈 뒤에 나뉘었는지 물어보는 일이었고, 그 일은 지금도 우리 손 안에 있다. 그래서 이 절을 우리 쪽 몫으로 적는다.

    초보용으로 옮기면 이렇다. 준비돼 있는 것과 쓸 수 있는 것은 다르다. 창고에 재료가 있는 것과 오늘 요리를 낼 수 있는 것이 다른 것과 같다. 앞의 것은 목록으로 알 수 있고, 뒤의 것은 한 번 만들어 봐야 안다.

    기록해 두면 좋은 것 하나. 실제로 시켜 본 날짜를 적어 두는 것이다. 적어 두지 않으면 마지막으로 언제 확인했는지가 기억에만 남고, 기억은 정상 표시가 이어질수록 흐려진다. 우리 경우 그 날짜가 없어서, 엿새가 지난 뒤에야 그 기간을 거꾸로 세어 봤다.

    확인 방법. 검토 체계를 갖췄으면 가끔 실제로 하나 시켜 보라. 결과가 돌아오면 되는 것이고, 돌아오지 않으면 그때 자리를 들여다보면 된다. 목록이 정상인 것을 보고 넘어가면, 다음에 알게 되는 것은 정상 표시가 유지된 기간이 얼마나 길었는지다.

    정리 — 확인할 것 세 가지

    아래 셋은 우리가 이 사건 뒤에 정한 확인 절차다. 새로 만든 규칙이 아니라 그때 하지 않아서 놓친 것을 적어 둔 것이다.

    첫째, 우리는 검토의 다양성을 자리 수가 아니라 계정 단위로 센다. 자리가 셋이어도 카드가 한 장이면 바깥에서 세는 수는 하나다. 우리 경우 그 두 수가 달랐고, 다르다는 것을 세어 보기 전에는 몰랐다.

    둘째, 우리는 되는지 확인하려면 실제로 시켜 본다. 목록에 떠 있는 것은 되는 것의 증거가 아니다. 우리 경우 엿새 동안 목록은 정상이었고 그동안 검토는 하나도 돌아오지 않았다.

    셋째, 우리는 한도가 바깥에 있다는 것을 계산에 넣는다. 내 쪽에서 실행을 나눠도 바깥 한도는 나뉘지 않는다. 나누는 쪽과 세는 쪽이 다르면, 나눈 결과는 세는 쪽 화면에 나타나지 않는다.

    세 항목이 전부 세어 보라로 수렴하는 것도 적어 둔다. 자리 수와 계정 수를 세고, 실제로 돌아온 결과를 세고, 한도가 어디에 붙어 있는지를 센다. 세지 않으면 두 수가 같다고 가정하게 되고, 그 가정은 화면이 정상인 동안 계속 유지된다.

    셋을 한 줄로 묶으면 이렇게 된다. 내가 나눈 수와 바깥이 세는 수를 각각 세어 보는 것이다. 두 수가 같다고 가정하는 순간 그 차이는 보이지 않게 되고, 차이가 드러나는 자리는 대개 일이 멈춘 뒤다.

    이 셋 중 어느 것도 사고를 막는 장치는 아니다. 셋 다 알아차리는 시점을 앞당기는 것이다. 우리 경우 알아차린 것은 엿새 뒤였고, 그 엿새는 무엇이 잘못됐는지 몰라서가 아니라 잘못됐다는 신호가 없어서 흘렀다.

    마지막으로 하나만 덧붙인다. 이 글은 계정을 어떻게 쓰라는 이야기가 아니다. 우리가 적은 것은 좁다 — 우리 한 사건에서 자리 수와 계정 수가 다른 수였고, 그 차이를 정상 표시가 가려 주었다.

    한 사건의 기록과 그 범위

    우리 운영 기록에서 확인한 것 (우리가 쓰는 환경의 한 사건이다)

    • 서로 다른 실행 묶음에 각각 배치한 검증 담당 세 자리같은 시각에 개인 할당량 소진으로 멈춘 것 (관측 한 번)
    • 셋의 다시 쓸 수 있게 되는 시각이 거의 같았던 것. 한도가 각자에게 붙어 있었다면 그 시각이 그렇게 겹칠 이유가 없다 — 이것이 셋이 한 계정을 나눠 쓰고 있었다고 본 근거다
    • 그 기간에 자리 목록도 편성 점검도 정상을 표시한 것. 자리는 열려 있었고 담당도 걸려 있었다
    • 그 상태로 엿새 동안 아무 일도 못 한
    • 그것을 잡아낸 것이 점검이 아니라 실제로 일을 시켜 본 것이었다는 것

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

    • 다른 서비스의 한도 정책이 어떻게 되어 있는지 우리는 재지 않았다. 이 글은 우리가 쓰는 환경에서 겪은 한 사건이다. 그래서 여러 서비스가 어떻게 한도를 센다는 문장이 이 글에 없다
    • 관측은 한 번이다. 세 자리가 그렇게 된 것을 한 차례 봤을 뿐이고, 이 일이 얼마나 자주 나는지 세지 않았다. 그래서 빈도에 대한 문장이 이 글에 없다
    • 셋이 각자 한도를 갖고 우연히 비슷하게 찼을 가능성. 우리는 그 가능성을 배제하는 실험을 하지 않았다. 어느 쪽이 더 그럴듯한지를 본 것까지가 우리가 한 일이다
    • 자리를 몇 개로 두는 것이 적절한지. 우리가 확인한 것은 자리 수와 계정 수가 다른 수라는 것까지다

    이 글에서 쓴 비유에 대해

    • 세 팀의 검사 담당자가 회원 카드 한 장을 나눠 쓰는 그림은 설명을 위해 쓴 비유다. 우리 환경이 그렇게 생겼다는 뜻이 아니고, 비유에서 따라 나오는 결론을 사실로 쓰지 않았다. 이 글의 사실은 위에 적은 다섯 줄이 전부다

    이 글이 하지 않는 말

    • 이 글은 계정을 어떻게 구성해야 한다고 쓰지 않는다. 우리가 확인한 것은 우리 한 사건에서 자리 수와 계정 수가 다른 수였다는 것이고, 그 두 수를 어떻게 맞출지는 쓰는 사람의 사정에 달려 있다
    • 이 글은 이 문제를 우리가 정리했다고 쓰지 않는다. 위 세 가지는 우리가 정한 확인 절차이고, 그 절차가 다음에 같은 것을 잡아낼지는 아직 재지 않았다

    같은 계열을 다른 자리에서 다룬 글

  • 승인 프롬프트가 계속 뜬다 — 권한을 어디까지 열어야 하나

    승인 프롬프트가 계속 뜬다 — 권한을 어디까지 열어야 하나

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

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

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

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

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

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

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

    승인 요청을 두 층으로 가른 구조를 정리한 도식. 층 1은 기계가 올린 상태 통지로 무엇을 알리는 항목이고 우리 원장에서 21건이며 근거를 적고 알림 기록만 닫되 화면에 승인 입력을 보내지는 않는다. 층 2는 되돌릴 수 없는 행위 승인으로 발행 배포 과금 삭제 외부 발송이 여기 속하고 우리 원장에서 12건이며 사람 게이트로 남긴다. 먼저 묻는 것은 이 처리가 기록만 닫는가이며, 실행이나 권한 부여나 차단 해제가 있으면 통지가 아니라서 범위와 대상과 부수효과와 복구 비용을 확인하고 하나라도 확인되지 않으면 사람에게 보낸다. 되돌릴 수 있음은 기준이 아니라는 단서와, 이렇게 하면 안전하다는 뜻이 아니라 우리가 그은 선과 그 이유라는 단서를 함께 적었다. 같은 시각 원장 92건의 유형 전수와 두 층을 갈라도 남는 함정 둘도 담았고, 그 표는 라벨이 있었다는 증거일 뿐 자동 처리 적격의 근거가 아니라고 적었다.
    손상 예시가 아니라 구조를 그렸다. 우리 한 팀의 원장이고 일반 분포로 읽을 것이 아니다. 먼저 묻는 것은 기록만 닫는가이고, 되돌릴 수 있음은 기준이 아니다 — 2026-09-08 22:5x 실측.

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

    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건
    • 행위 승인 기록에 요청과 결정이 각각 시각과 함께 남는다는 것. 다만 그 두 시각으로 요청자와 결재자가 분리됐다고 판정할 수는 없다 — 시각은 순서와 만료의 참고값이고, 분리 여부는 요청과 결정의 연결·승인자와 그 권한·승인 대상과 범위의 일치로 확인해야 한다

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

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

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

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