왜 당신의 AI가 혼자 결정하게 해서는 안 되는가: 3가지 옵션 패턴

왜 당신의 AI가 혼자 결정하게 해서는 안 되는가: 3가지 옵션 패턴

5월 16일 화요일 오후. Catherine이 Maisons-Laffitte 지점에서 전화를 걸어옵니다. 그녀는 문제를 말하기도 전에 수화기에 대고 평소처럼 _"음, 버그가 있지만 금방 고쳐질 거예요"_라는 말을 내뱉으며 통화를 시작합니다. 이번에는 버그가 아닙니다. 이미 계약이 완료되고 두 번이나 수업이 진행된 과정에서 강사가 연도 중간에 교체되는 상황입니다.

겉으로 드러난 질문은 모욕적일 정도로 단순해 보입니다. UPDATE 명령어로 등록(inscriptions) 테이블을 수정하고, 오른쪽 열에 새 강사의 이름을 넣으면 끝나는 10초짜리 작업입니다. 제 손은 키보드 위에 있고, 에이전트(agent)는 지시를 기다리고 있으며, 저는 일주일 뒤에 다시 작업하게 될 다섯 줄의 코드를 막 작성하려던 참입니다.

왜냐하면 겉으로 드러난 질문이 진짜 질문이 아니기 때문입니다. 진짜 질문은 우리 ERP에서 누가 그 작업을 실행할 수 있는지, 수정 후 등록 상태가 _어떤 상태(status)_로 남아야 하는지, 그리고 6개월 뒤 누군가가 왜 아이의 서명이 바뀌었는지 묻는 학부모에게 답변할 수 있도록 _어떤 흔적(trace)_을 남겨야 하는지입니다. 이 세 가지 질문 중 어느 것도 SQL 전문 지식에서 나오는 것이 아닙니다. 이는 워크플로우(workflow), RBAC(역할 기반 액세스 제어), 감사(audit)에서 나옵니다. 각각의 질문은 단독으로 보면 너무나 당연해 보여서 즉석에서 결정해 버리게 됩니다. 하지만 이 질문들이 쌓이면, 제가 지금 혼자 결정했을 때 다음 주에 저를 기다리고 있을 '재작업'을 만들어냅니다.

내가 결정하는 세 가지 이유, 그리고 그 세 가지 모두가 거짓말인 이유

AI와 함께 단독으로 코딩하는 것은 겉보기에는 경제적으로 보이지만, 실무 경험을 통해 저는 이를 반대로 해석하는 법을 배웠습니다. 세 가지 내부적인 힘이 제가 질문을 공식화하기 전에 결정을 내리도록 압박합니다.

맥락(context)에 대한 자부심은 _'내가 이 사건을 봤고, 테이블을 알고 있으며, 해결책이 보인다'_라고 속삭이며, 질문을 입 밖으로 내뱉는 수고를 덜어줍니다. 속도는 작성된 코드는 측정하지만 다시 작성된 코드는 측정하지 않기에, 세 가지 옵션을 공식화하는 것이 30초를 낭비하는 반면 코딩은 _앞으로 나아간다_고 저를 설득합니다. 인지적 분할 상환(Cognitive amortisation), 즉 에이전트에게 위임하는 각 결정이 나의 숙련된 자율성을 침식한다는 괴로운 느낌은, 결정을 내리기 위해 결정을 요구하게 만듭니다.

이 세 가지는 서로를 강화하며, 세 가지 모두 거짓을 말합니다. 맥락의 자부심(Pride of context)은 나의 맥락이 바로 내가 고려하지 못한 옵션들을 보지 못하게 만드는 눈가리개라는 사실을 무시합니다. 속도는 오직 작성 곡선(writing curve)만을 고려할 뿐, 재작업 곡선(re-do curve)은 결코 고려하지 않습니다. 인지적 분할 상환(Cognitive amortisation)은 '결정하는 것(deciding)'과 '실행하는 것(executing)'을 혼동합니다. 나에게 세 가지 옵션을 건네주는 에이전트는 아무것도 결정하지 않습니다. 여전히 결정하는 것은 나입니다. 나는 더 잘 결정합니다.

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

나는 반사적인 행동을 뒤집었습니다. 감사(audit), 권한(permission), 또는 워크플로(workflow)에 영향을 미치는 어떠한 변경을 하기 전에도, 나는 에이전트에게 세 가지 옵션을 요구합니다. 단순히 같은 호출의 세 가지 변형이 아닙니다. '구조적으로 구별되는(structurally distinct)' 세 가지 옵션이며, 각각은 비즈니스 효과(business effect), 코드 표면적(code surface), 운영 비용(operational cost)이라는 세 가지 명시된 축에 대해 명확한 트레이드오프(trade-off)를 가집니다.

화요일, Catherine. 에이전트에게 일곱 단어를 던집니다: "signed inscription 상의 trainer 변경, 세 가지 옵션 요청." 25초 후, AskUserQuestion을 통해 세 가지 옵션이 돌아옵니다. (a) 직접적인 UPDATE, 자유 형식 노트(free notes)에 추적성 기록, 약한 감사(audit). (b) 명시적인 동기와 함께 현재 inscription을 종료하고, 새로운 trainer와 연결된 새로운 inscription 생성, 상태(status)에 추적성 기록, 강력한 감사(audit). (c) annex 플래그 및 수동 노트 추가, 중간 수준의 감사(audit).

나는 5초 만에 (b)를 선택했습니다. 직관에만 의존했다면 (a)를 선택했을 것입니다. (a)의 함정은 일주일 뒤, 학부모가 왜 자녀의 기록에 있는 서명이 바뀌었는지 물을 때 드러납니다. 나는 자유 형식 노트에서 흔적을 찾으려 애쓰지만, 아무도 자유 형식 텍스트 필드를 grep(검색)할 생각은 하지 못하며, 결국 서명 로그로부터 이력을 재구성하는 데 3시간을 허비하게 됩니다.

규칙: 의도적인 제한

이 패턴은 질문이 감사(audit), 권한(permission), 워크플로(workflow)와 같이 비즈니스 측면의 흔적을 남기는 시스템 전환(system transition)을 건드릴 때만 적용됩니다. 만약 질문이 "이 컬럼에 어떤 Postgres 인덱스를 쓸까" 또는 _"이 헬퍼 함수에 어떤 TypeScript 시그니처(signature)를 쓸까"_라면, 전문 지식이 직접 결정합니다. 이럴 때 질문을 던지는 것은 예리함을 더하기보다 오히려 역량을 희석시킬 뿐입니다.

구조적으로 구별되는 세 가지 옵션을 듣는 데 드는 30초는, 다음 주에 당신이 치러야 할 3시간의 재작업을 방지해 줍니다. 이 규칙은 작성된 코드의 줄 수로 측정되는 것이 아닙니다. 다시 작성하지 않아도 되는 코드의 줄 수로 측정됩니다.

기술 출처: github.com/michelfaure/doctrine-counterpart (R13) 내의 ask-3-options-before-code/SKILL.md.