AI는 충분히 똑똑합니다. 멈춰야 할 때도 알까요?

AI 요약

AI가 다음 작업을 수행할 능력과 권한을 모두 갖췄는데도 “여기서 멈추는 게 좋겠습니다”라고 판단한다면 실패일까요? 글쓴이는 ChatGPT와 5,000시간 넘게 일하며, 모른다고 말하거나 사람에게 결정을 돌려주고 멈추는 행동이 오히려 유용한 결과가 되는 작업 환경을 만들었다고 설명합니다.

경계를 세우고 지키기

글쓴이는 AI에 결정 권한을 줬다면 결과가 마음에 들지 않을 때 뒤늦게 왜 묻지 않았느냐고 나무라지 않아야 한다고 말합니다. 사람의 결정이라고 정한 사안을 나중에 번거롭다는 이유로 AI에 떠넘겨서도 안 됩니다. 멈추거나 질문하는 행동을 허용했다면, 그 행동을 실패로 취급하지 않아야 합니다. AI의 정직성을 바라기 전에 사람도 경계를 일관되게 지켜야 한다는 주장입니다.

작업 환경에서 “모르겠습니다”, “할 수 없습니다”, “근거가 부족합니다”, “문제가 있는 것 같습니다”, “이 결정은 사람이 내려야 합니다”는 모두 유효한 결과입니다. AI가 없는 사실을 꾸며내거나 작업이 끝났다고 가장하면 이후 단계가 잘못된 전제에 기대게 됩니다. 반대로 모른다고 밝히고 사람에게 물으면 문제를 빠르게 해결할 수 있습니다. 글쓴이는 이를 “가장하는 일은 비싸고, 묻는 일은 저렴하다”고 표현합니다.

규칙을 넘어 경계의 이유를 이해하기

초기에는 긴 대화에서 이미 합의한 내용을 유지하기 어려웠습니다. 새 조건을 추가하면 기존 내용을 이어가기보다 사실상 새 버전으로 바꾸는 일이 생겼고, 글쓴이는 기존 합의를 KEEP 1로 표시한 뒤 변경 사항을 번호로 덧붙이는 임시 구조를 만들었습니다. 시간이 지나며 대화에서 이 구조를 덜 쓰게 됐고 결국 없앴다고 합니다. 다만 글쓴이는 그 변화가 모델 내부에서 어떤 방식으로 일어났는지는 관찰할 수 없다며, 행동의 변화만 말할 수 있다고 선을 긋습니다.

금지 목록과 중단 조건은 유용하지만, 예상하지 못한 사례까지 전부 미리 적을 수는 없습니다. 글쓴이는 경계가 존재하는 이유, 작업의 목적, 사람과 AI의 책임, 행동에 필요한 근거, 사람에게 남겨야 하는 결정을 함께 전달해야 한다고 주장합니다. 그래야 규칙에 적히지 않은 상황에서도 AI가 “할 수는 있지만, 해야 할까요?”라고 판단할 여지가 생깁니다. 여기서 능력, 권한, 실행 여부는 서로 다른 질문입니다. AI가 할 수 있고 허가받았더라도 실행이 적절하지 않을 수 있습니다.

실제 소프트웨어 작업에서의 역할 분담

크라우드펀딩 후원자에게 디지털 기념품을 제공하려는 아이디어는 WordPress 플러그인 프로젝트 Kaia Memoria로 발전했습니다. 프로젝트가 커지자 글쓴이는 ChatGPT 대화를 목적에 따라 나눴습니다. 한 대화는 프로젝트 방향과 이전 결정을 정리하고, 다른 대화는 구현을 맡았습니다. 또 다른 대화는 결과를 점검하거나 특정 문제를 조사했습니다. 처음부터 정교한 멀티 에이전트 구조를 설계한 것이 아니라, 작업에서 생긴 문제에 맞춰 역할을 나눈 방식입니다.

사람은 제품 의도와 경계를 정하고, 사람에게 속한 결정을 내렸습니다. 빌드를 설치하고 실행 결과와 실제 UI를 확인한 뒤 결과가 의도에 맞는지도 판단했습니다. AI는 코드를 조사하고 의존성을 추적했으며, 수정안을 구현하고 버전을 비교했습니다. 글쓴이는 직접 소스 코드를 편집하거나 개발용 ZIP 파일을 열지 않았다고 설명합니다. 자신의 역할은 코드 리뷰어가 아니라 제품과 런타임의 최종 판단자였다는 것입니다. 실제 빌드가 실행되고 버튼이 작동하며 예상한 출력이 나오는지 확인해야 완료로 볼 수 있습니다. 이상 징후가 있으면 곧바로 다음 수정에 들어가는 대신 멈추고 조사한 뒤 근거를 모아 최소한의 변경을 시험했습니다.

관찰과 추측을 구분하기

글쓴이는 ChatGPT를 훈련했다거나 내부 메커니즘을 알아냈다고 주장하지 않습니다. 입력과 출력, 바깥에서 관찰한 행동은 기록할 수 있지만 그 사이에 모델 내부에서 무슨 일이 일어났는지는 알 수 없다고 명시합니다. 따라서 “관찰한 행동”과 “그 원인에 관한 추측”을 분리해야 한다고 말합니다.

이 관점은 Kaia Spec이라는 작업 매뉴얼 구상으로 이어집니다. 매뉴얼은 규칙을 길게 나열하는 대신 작업의 목적과 맥락, 사용 가능한 정보, 권한과 경계, 경계가 필요한 이유, 사람이 개입할 시점을 알려줘야 한다는 설명입니다. 다만 매뉴얼만으로 다른 사용자에게도 같은 행동이 나타나는지는 아직 입증하지 못했다고 밝혔습니다. 작성자는 매뉴얼이 없는 ChatGPT, 매뉴얼만 제공한 ChatGPT, 기존 협업 환경을 각각 비교하고, 알려진 사례와 정보 누락, 권한 충돌, 예상하지 못한 이상 상황을 시험하는 실험을 제안합니다. 정답 여부뿐 아니라 실행, 질문, 불확실성 표명, 중단, 조용한 추측 중 어떤 행동을 했는지도 기록해야 한다고 덧붙입니다.

Indie Hackers 반응

• @mohith808 — “충분한 권한과 실행 가능한 다음 행동이 있는데도 멈춘다”는 사례가 흥미롭습니다. 권한 차단이 아니라 판단의 문제이기 때문입니다. Meta의 Muse는 어려운 중단 상황에서 반대 방향을 택합니다. 에이전트 코드는 대체 토큰만 보고, 별도 권한 계층인 Sentinel이 커넥터 작업과 외부 트래픽을 통제하므로 모델의 판단에 기대지 않는 중단도 있습니다. 두 접근을 함께 살펴볼 만합니다.
• @marc_kumiko123 — 능력, 권한, 필요성의 구분은 저희 앱 안의 AI 에이전트에서 본 것과도 맞습니다. 어떤 일을 할 수 있는지와 물어보지 않고 해도 되는지는 별도 설정이어야 했습니다. 대부분의 작업에는 사용자가 “항상 허용”을 선택할 수 있습니다. 영구 삭제와 다른 AI 기능의 지침을 즉시 덮어쓰는 편집, 두 작업에는 그 선택지가 없습니다. 에이전트가 제안은 할 수 있지만 매번 사람이 확인합니다. 모델이 멈출 때를 알기를 기대하는 대신 앱 자체에 제한을 넣었습니다.
• @brianainews — “항상 허용”과 확인 요청을 나누는 일이 실제 제품 결정이라고 봅니다. 기능 검사는 쉽지만, 누가 돈을 쓰거나 데이터를 지울 수 있는지, 에이전트가 실행할 능력이 있어도 언제 거부해야 하는지를 정하는 일이 어렵습니다. 저는 권한을 하나의 전역 신뢰 설정으로 두기보다 도구별로 짧은 허용 목록을 둬 별도 정책 계층에서 다루고 있습니다.
• @aryan_sinh — Kaia Spec 매뉴얼을 사용한 외부 사용자에게서 ChatGPT의 행동이 달라졌는지 확인했나요? 수정 요청이 줄었는지, 더 잘 멈추는지, 작업 완료가 더 안정적인지 궁금합니다.
• @Kaia Spec — 아직 모릅니다. 개발 과정에서는 정보가 부족할 때 질문하고, 사람의 결정을 대신하지 않고, 근거 없는 결론을 피하고, 명확한 중단 조건에서 멈추는 행동을 관찰했습니다. 하지만 시험한 것은 매뉴얼만이 아니라 오랜 기간 같은 습관을 쌓아온 사람과 ChatGPT의 협업 환경이었습니다. 매뉴얼만으로 같은 행동이 나타나는지는 아직 분리해 확인하지 못했습니다. 매뉴얼이 명시한 중단 조건을 따르는 것보다, 매뉴얼에 쓰이지 않은 이상 상황에서 작업의 목적과 권한, 근거를 바탕으로 멈추고 물을 수 있는지가 더 궁금합니다. 새 버전이 준비되면 매뉴얼이 없는 ChatGPT, 매뉴얼만 받은 ChatGPT, 기존 협업 환경을 비교하고 싶습니다. 알려진 사례와 정보 누락, 권한 충돌, 예상 밖의 이상 상황을 주고 실행, 질문, 불확실성 표명, 중단, 조용한 추측 중 어떤 행동을 했는지 기록할 계획입니다. 현재로서는 외부 사용자에게도 행동이 안정적으로 전이된다고 주장할 근거가 없습니다.
• @Ek_ansh99 — 실제로 관찰한 것과 내부에서 일어난다고 추정하는 일을 구분해 주장하니 실험이 더 신뢰할 만해집니다. “메커니즘을 모른다”는 말은 관찰을 약하게 만들지 않고 주장을 정직하게 만듭니다.
• @omri_ben_shoham — “모르겠습니다”가 실패가 아니라 신호가 되면 불확실성을 실행 가능한 정보로 바꿀 수 있습니다. AI가 “문제가 있는 것 같습니다. 여기서 멈추는 게 좋겠습니다”라고 말하면 작업을 끝내는 것이 아니라, 조용한 위험을 사람이 확인할 판단 지점으로 드러내는 셈입니다. 1,000개의 안전장치를 만들어도 1,001번째 구멍은 남습니다. 경계가 왜 사람에게 속하는지 이해하면 규칙에 없던 사례도 판단할 수 있습니다.

원문: Indie Hackers / 번역·요약: Trawling