왜 당신의 AI가 감사(Audit)나 권한(Permission)을 단독으로 결정해서는 안 되는가

왜 당신의 AI가 감사(Audit)나 권한(Permission)을 단독으로 결정해서는 안 되는가

5월 16일 화요일 오후. Catherine이 Maisons-Laffitte 지점에서 전화를 걸어옵니다. 수화기를 들자마자 그녀는 문제를 말하기도 전에 평소 습관처럼 _"음, 버그(bug)가 있지만 금방 고쳐질 거예요"_라고 말합니다. 이번에는 버그가 아닙니다. 이미 계약이 완료되고 두 번이나 출석 체크(émargé)가 완료된 강의에 대해, 연도 중에 강사를 교체해야 하는 상황입니다.

겉으로 보기에는 기술적으로 모욕적일 만큼 단순한 문제입니다. 등록 테이블(table des inscriptions)에 UPDATE를 실행하고, 올바른 필드에 새 강사의 이름을 넣으면 10초면 끝납니다. 제 손은 키보드 위에 있고, 에이전트(agent)는 지시를 기다리고 있으며, 저는 일주일 후에 다시 작업하게 될 다섯 줄의 코드를 막 작성하려는 참입니다.

왜냐하면 겉으로 보이는 질문이 실제 질문이 아니기 때문입니다. 실제 질문은 우리 ERP에서 누가 이 작업을 수행할 수 있는지, 수정 후 등록 상태(statut)를 어떤 상태로 남겨두어야 하는지, 그리고 6개월 뒤에 학부모가 왜 자녀의 서명이 변경되었는지 알 수 있도록 _어떤 흔적(trace)_을 남겨야 하는지입니다. 이 세 가지 질문 중 어느 것도 SQL 전문 지식에서 나오지 않습니다. 이는 워크플로우(workflow), RBAC(역할 기반 액세스 제어), 감사(audit)에서 나옵니다. 각각을 따로 떼어놓고 보면 너무나 당연해 보여서 즉시 결정(trancher)하게 됩니다. 하지만 이 질문들이 결합되면, 제가 지금 단독으로 결정했을 때 다음 주에 저를 기다리고 있는 재작업(re-do)을 만들어냅니다.

제가 결정을 내리게 만드는 세 가지 이유, 그리고 그 세 가지 모두가 거짓말을 하는 이유

AI와 함께 단독으로 코딩하는 것은 겉보기에 비용 절감을 가져다주는 것 같지만, 실무를 통해 저는 그것을 거꾸로 읽는 법을 배웠습니다. 세 가지 내부적인 힘이 제가 문제를 공식화하기도 전에 결정을 내리도록 압박합니다.

맥락의 오만(L'orgueil du contexte)은 내게 '내가 그 사고를 봤고, 그 테이블을 알고 있으며, 해결책이 보인다'라고 속삭이며, 문제를 소리 내어 질문하는 과정을 생략하게 만듭니다. 속도(La vitesse)는 작성된 코드만을 측정할 뿐 다시 작성된 코드는 결코 측정하지 않는다는 점은, 세 가지 옵션을 구성하는 것이 30초를 낭비하는 것이며 코딩을 하는 것이야말로 '전진'하는 것이라고 나를 설득합니다. 인지적 감가상각(L'amortissement cognitif)은 에이전트(Agent)에게 위임된 모든 결정이 실무자로서의 나의 자율성을 갉아먹는다는 끈질긴 느낌을 주며, 결정을 위한 결정으로서 내가 직접 결정을 내리도록 몰아세웁니다.

이 세 가지는 서로를 강화하며, 세 가지 모두 거짓말을 합니다. 맥락의 오만은 나의 맥락이 바로 내가 고려하지 못한 옵션들에 대해 나를 눈멀게 만드는 원인이라는 점을 간과합니다. 속도는 단 하나의 곡선, 즉 작성의 곡선만을 계산할 뿐, 재작업(Re-do)의 곡선은 결코 계산하지 않습니다. 인지적 감가상각은 '결정하는 것'과 '실행하는 것'을 혼동하지만, 세 가지 옵션을 제안하는 에이전트는 아무것도 결정하지 않습니다. 결정은 언제나 내가 합니다. 나는 단지 더 잘 결정할 뿐입니다.

패턴: 구조적으로 구별되는 세 가지 옵션

나는 이 반사 작용을 뒤집었습니다. 감사(Audit), 권한(Permission) 또는 워크플로(Workflow)에 영향을 미치는 모든 수정 사항을 적용하기 전에, 나는 에이전트에게 세 가지 옵션을 요구합니다. 동일한 옵션의 세 가지 변형이 아닙니다. 세 가지의 '구조적으로 구별되는(structurellement distinctes)' 옵션이며, 각각은 명명된 세 가지 축인 비즈니스 효과(Effet métier), 영향을 받는 코드 범위(Surface de code touchée), 운영 비용(Coût opérationnel)에 대한 명시적인 트레이드오프(Trade-off)를 가집니다.

화요일, Catherine. 에이전트에게 일곱 단어를 던집니다. "서명된 등록에 대한 강사 변경, 세 가지 옵션". 25초 후, AskUserQuestion을 통해 세 가지 옵션이 반환됩니다. (a) 직접적인 UPDATE, 자유 메모(Notes libres)를 통한 추적성, 낮은 감사(Audit) 수준. (b) 명시적인 사유와 함께 현재 등록을 종료하고 새로운 강사와 연결된 새 등록을 생성, 상태(Statut)를 통한 추적성, 높은 감사(Audit) 수준. (c) 부가적인 플래그(Flag)와 수동 메모, 중간 수준의 감사(Audit).

나는 (b)를 5초 만에 결정했습니다. 직관만 따랐다면 (a)를 선택했을 것입니다. (a)의 함정은 일주일 뒤, 한 학부모가 왜 아이의 서명이 바뀌었는지 물어볼 때 드러납니다. 자유 메모(Free notes)에서 흔적을 찾으려 하지만, 아무도 자유 입력 필드를 뒤져볼 생각은 하지 않습니다. 결국 서명 로그(Logs d'émargement)로부터 이력을 재구성하는 데 3시간을 허비하게 됩니다.

선택에 의한 좁은 규칙

이 패턴은 질문이 비즈니스(Métier), 감사(Audit), 권한(Permission), 워크플로우(Workflow) 측면에서 흔적을 남기는 시스템 전환과 관련될 때만 적용됩니다. 만약 질문이 "이 컬럼에 어떤 Postgres 인덱스를 쓸까" 또는 _"이 헬퍼(Helper) 함수에 어떤 TypeScript 시그니처(Signature)를 쓸까"_와 같은 것이라면, 전문 지식이 즉각적으로 결정합니다. 이런 경우 질문을 던지는 것은 명확하게 만드는 것보다 오히려 내용을 희석시킬 뿐입니다.

구조적으로 구별되는 세 가지 옵션을 듣는 데 걸리는 30초는, 다음 주에 우리가 지불하지 않아도 될 3시간의 재작업(Re-do)을 의미합니다. 이 규칙은 작성된 코드의 줄 수로 측정되지 않습니다. 다시 작성하지 않아도 되는 코드의 줄 수로 측정됩니다.

Skill source : ask-3-options-before-code/SKILL.md in github.com/michelfaure/doctrine-counterpart (R13).