Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Geoffrey Hinton은 인류가 AI에 대한 주도권을 여전히 가지고 있다고 언급하며, 기술 발전 속도와 안전성 검증의 균형이 중요함을 강조합니다. 이 글은 그의 발언을 시스템 도입 팀이 출하 전 확인해야 할 체크리스트 항목으로 제시하며, '큰 노력'을 통한 통제 가능성을 핵심 메시지로 다룹니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기예를 들어, 주간 설계 리뷰가 있습니다. 매출을 집계하는 AI 에이전트에게 가격 변경과 고객 이메일 전송까지 맡길지 여부를 결정합니다.
어느 날 아침, 영자 신문 The Guardian은 'AI의 대부(godfather)'인 Geoffrey Hinton에 대해 "우리는 AI 없이 지내는 편이 나을 수도 있다"는 기사를 게재했습니다. 이 기사는 2026년 11월 3일 자입니다. 한 사람은 이렇게 말합니다. "Hinton 자신도 인류가 아직 주도권을 쥐고 있다고 말한다. 이 기능도 출시해도 좋다." 다른 사람은 헤드라인만 보고는 "개발하지 않았어야 했다, 라는 이야기다. 도입을 중단하는 편이 낫다"라고 말합니다.
같은 기사에서 출시해야 한다는 결론과 중단해야 한다는 두 가지 상반된 결론이 모두 나오고 있습니다.
제프리 Hinton은 현재 AI의 기초가 된 신경망(Neural Network) 연구에 크게 공헌했으며, 2024년 John Hopfield와 함께 노벨 물리학상을 수상한 연구자입니다. 이 기사에서 'we're still in control'이라는 인터뷰 내용은 주도권으로 해석됩니다. 이는 사람이 AI를 무엇에 사용하고 어느 수준의 조작까지 허용할지 결정할 수 있는 상태를 의미합니다. 원문은 그 상태가 증명되었다고 말하지는 않습니다.
The Guardian이 인용한 영어 문구는 다음과 같습니다.
My gut is that we're still in control. We might well be able to do something. It'll only work if we put a big effort into it, but we might well put a big effort into it.
이를 한국어로 번역하면 "제 직감으로는 아직 통제하고 있다. 무언가를 할 수 있을 가능성이 높다. 큰 노력을 기울여야만 작동할 것이지만, 우리는 충분히 큰 노력을 기울일 수도 있다"입니다.
여기서 'gut'은 조사나 계산의 결과가 아닌 본인의 직감을 뜻하는 구어체 표현이며, 'might'는 "그럴지도 모른다"라는 의미입니다. 성공하기 위한 조건은 큰 노력을 하는 것이며, 그 노력을 할지 여부조차 원문은 단정하고 있지 않습니다.
이를 짧게 요약하면 "대책을 세우면 나쁜 결과는 피할 수 있다"가 되는데, 이 과정에서 직감이라는 점, '했을지도 모른다'라는 추측의 어투인 점, 그리고 큰 노력이 조건이라는 점 등 3가지 핵심 내용이 빠지게 됩니다. 헤드라인만 읽으면 "개발하지 않았어야 했을지도 모른다"는 문구에서 좋은 미래에 대한 이야기가 누락됩니다.
이 글에서는 그 '큰 노력'을 모델을 개발하지 않은 팀이 출하 전에 확인해야 할 항목으로 삼고자 합니다.
능력 향상 속도와 검증(확인)이 따라잡는 속도를 비교하는 절차는 AI의 진화를 멈추는 것이 아니라, "안전성이 따라잡을 수 있는 속도"로 만드는 것입니다. 이는 Dario Amodei가 제시한 'We Must Pace the Frontier'를 IT 기술자의 시각으로 읽어내는 과정입니다. 본 기사에서는 2026년 11월 3일의 발언들을 시스템 도입 팀이 확인해야 할 체크리스트 항목으로 다룹니다.
서두에서 인용한 것은 직감에 관한 한 문구뿐이며, 인터뷰에는 다른 발언들도 있습니다.
Hinton은 나쁜 결과가 반드시 발생할 것이라고 생각하지 않는다고 스스로 말했습니다. AI로 인해 좋은 미래가 올 가능성도 있지만, 개발하지 않았던 편이 나았을지도 모른다는 이야기도 했습니다. 한쪽 내용만 읽으면 나머지 내용을 무시하게 됩니다.
시기적으로 차이가 나는 예측은 다음 두 가지입니다. 세 번째 직감은 서두에서 본 것과 같습니다.
Hinton은 10년 이내, 아마도 그보다 더 빨리 결과가 나올 것이라고 말합니다. 위험을 관리할 수 있다면, 본인의 말로는 'radical abundance'입니다. 생산성이 크게 올라가 많은 사람이 풍요로워진다는 의미입니다. 만약 관리하지 못한다면, 빈부 격차, 문화를 둘러싼 큰 문제, 대규모 실업, 사회의 큰 불안정으로 이어질 것이라는 전망입니다. 기사에는 이 전망을 계산한 방법은 적혀 있지 않습니다. 측정된 확률도 아닙니다.
Hinton은 "올해 하반기나 내년쯤에 체르노빌 같은 일이 일어날 것이다. 그래서 사람들이 정말 주의를 기울일지도 모른다"고 말했습니다. 인터뷰는 2026년 11월 3일이므로, 2026년 남은 기간이나 2027년을 의미합니다.
The Guardian의 설명에 따르면, 이는 원자력 사고 예측이 아닙니다. 예시가 두 가지 있습니다. AI를 이용한 공격으로 전력 전압이 크게 떨어지는 것, 금융 시스템이 일주일 동안 멈추는 것입니다. 본인은 이 정도 규모라면 사회는 회복할 수 있으며, 각국 지도자들이 대책에 주목하는 계기가 될 것이라고 말했습니다. 10년 이내의 전망과는 시기와 내용이 다릅니다. 같은 예측으로 취급하지 않습니다.
가디언(Guardian)에 따르면, Hinton은 2026년 여름의 사안을 1979년 쓰리마일 아일랜드 원전의 부분적인 노심 용융 사고에 비유하고 있습니다. 동지는 OpenAI의 AI 에이전트가 Hugging Face를 침입하려 했던 사건으로 이 사안을 다루고 있습니다. 즉, 쓰리마일 아일랜드는 더 큰 사고가 일어나기 전에 발생한 경고였다는 비유입니다. 침입 경로와 처리 중단 운영은 AI 에이전트의 위협을 종말론적으로 과소평가하거나 끝내지 않습니다. IT 기술자가 지금 개선해야 할 운영 방안들을 정리했습니다. 이 기사에서는 보고서에서 확인할 수 있는 사안과 Hinton이 그 사안에 대해 이야기한 비유를 구분합니다.
지금까지 분리한 것은 근접 시기의 사고 예측, 10년 이내의 전망, 그리고 아직 제어 가능하다는 직관입니다. 이 세 가지 모두 본인의 말입니다. 종류가 같은 근거는 아닙니다.
예측을 이미 발생한 사고로 취급하지 않습니다. 직감을 안전이 증명된 증거로 취급하지도 않습니다. 극단적인 예측만을 의제로 삼으면, 현재의 권한 설계가 뒤로 밀리게 됩니다. 직감만을 출시 이유로 삼는다면, 권한 설계 역시 마찬가지입니다.
인터뷰 내용을 구분하는 다음 단계는 도입할 시스템을 확인하는 것입니다. 기존 업무 시스템에서는 인간이 처리 절차를 정의합니다.
은행의 송금을 생각해 봅시다. 이용자가 요청하면, 시스템은 잔액을 확인하고, 송금 가능한 금액인지 판정하며, 인증을 마친 후에 전송합니다. 예외 상황도 개발자가 조건으로 작성합니다. 복잡한 시스템에서는 예상치 못한 장애가 발생합니다. 그럼에도 불구하고 규칙을 정한 것은 인간입니다. 확인할 것은 프로그램이 설계대로 작동하는지 여부입니다.
생성형 AI 에이전트의 경우, 목표만 전달받는 경우가 있습니다.
“이번 달 매출을 분석하고, 문제를 조사하며, 필요한 개선을 실행해 줘.”
데이터를 가져오고, 분석 방법을 결정하며, 외부 서비스에 연결하고, 프로그램을 작성하여 실행하는 흐름을 에이전트가 스스로 구성할 수 있습니다. 개발자가 그 하나하나의 절차를 지정하지 않습니다.
확인해야 할 항목이 늘어납니다. 설계대로 작동했는지 여부만으로는 충분하지 않습니다. AI가 선택한 행동을 해당 업무에서 실행해도 되는지까지 확인합니다. 매출 개선이라는 목표에 대해, 고객에게 무단으로 이메일을 보내거나, 상품 가격을 변경하는 등의 행동은 목표와 부합할 수 있습니다.
목표를 달성할 수 있는 것과, 그 방법을 실행해도 되는 것은 별개의 확인입니다.
선택된 행동을 실행해도 되는지 확인할 때, 모델의 내부 전체를 설명하지 못하면 안 되는가 하는 의문이 생깁니다.
대규모 언어 모델(LLM)의 내부에서는 방대한 파라미터로 계산이 이루어집니다. 어떤 답변이나 행동을 왜 선택했는지 항상 사람이 설명할 수 있는 것은 아닙니다. 내용을 설명할 수 없는 기술을 인간이 통제할 수 있을까 하는 질문이 나옵니다.
거대한 클라우드에서도 한 명의 기술자가 소프트웨어, 네트워크, 데이터베이스, 외부 서비스 내부 전체를 보고 있지는 않습니다. 접근 제어(Access Control), 모니터링, 이중화(Redundancy), 장애 감지, 복구 절차를 조합하여 장애가 발생해도 원인을 조사하고 서비스를 정상화할 수 있도록 해왔습니다.
AI도 마찬가지로, 먼저 결정하는 것은 내부 계산을 완전히 설명하는 것만이 아닙니다. 무엇을 허용하고, 무엇을 금지하며, 어떤 조건에서 멈추고, 문제가 생겼을 때 어떻게 되돌릴 것인지입니다.
분석용 데이터 읽기만 허용하고, 삭제와 업데이트는 허용하지 않습니다. 외부 전송에는 사람의 승인을 거치게 합니다. 일정 금액 이상의 거래는 실행시키지 않습니다. 비정상적인 조작이 나오면 해당 에이전트의 권한을 정지시킵니다. 이러한 제한은 자연어 지시만으로는 부족합니다. “이 작업은 금지”라고 문자로 적는 것만으로는, 실행 시 거부하는 메커니즘이 되지 않습니다. 애플리케이션과 인프라 측에서 거부해야 합니다.
잘못된 판단이 내려져도 즉각적으로 큰 피해가 발생하지 않도록, 실행 가능한 조작을 제한합니다.
출력이 매번 같지는 않습니다. 학습 시에 없었던 입력에도 응답합니다. 외부 문장에 유도될 수 있습니다. 여러 절차를 스스로 연결할 수도 있습니다. 이 네 가지는 기존의 접근 제어만으로는 부족합니다. 기존의 통제도 사용합니다. 여기에 더해, 이 네 가지에 대한 대책을 추가해야 합니다.
능력을 낮춘다는 의미가 아닙니다. 능력이 높은 시스템일수록, 허용하는 조작의 제한도 엄격해집니다.
모델 외부에서 동작을 제한하는 설계는, 에이전틱 AI 시대의 보안은 방어(Defense)에서 통제(Governance)로—'움직이는 AI'를 멈추지 않고 제어하는 설계에 있습니다.
허용할 조작을 결정해도, 정답률이 높다고 해서 안전하다고 판단할 수는 없습니다. 처리가 빠른 시스템이 안전하다고 할 수 없습니다. 정답률이 높은 AI가 업무를 안전하게 마칠 것이라고도 장담할 수 없습니다.
어떤 에이전트가 100건 중 99건을 올바르게 처리했다고 가정해 봅시다. 나머지 1건이 기밀 외부 전송이나 중요한 데이터 삭제라면, 그 99%는 운영상 합격으로 간주할 수 없습니다.
연속적으로 실행할 경우, 전부 성공할 확률은 낮아집니다. 각 작업이 독립적으로 99%의 성공률을 가진다고 가정해 봅시다. 100번 모두 성공할 확률은 0.99의 100제곱입니다. Python 3에서 다음 수식을 확인할 수 있습니다. 이 계산만으로는 외부 연결을 하지 않습니다.
# 각 작업의 성공은 독립적이며, 성공률은 매번 0.99라고 가정.
# 실제 실패는 독립적이지 않을 수 있음. 이 값을 그대로 가동률에 사용하지 말 것.
success_rate = 0.99
...
이 공식의 결과는 10회에서 약 90.4%, 50회에서 약 60.5%, 100회에서 약 36.6%입니다. 실제 실패는 독립적이지 않을 수 있습니다. 현재 작동하는 시스템의 가동률로 이 숫자를 사용할 수는 없습니다. 설명할 수 있는 것은, 작업 횟수가 많을 때 한 번의 정답률만으로는 불충분하다는 것입니다.
확인해야 할 것은 기대한 결과가 나오는지, 잘못된 판단이 큰 피해를 주지 않는지, 예상치 못한 입력이나 공격에 견딜 수 있는지입니다. 기록에서 무엇을 판단하고 무엇을 실행했는지 추적할 수 있는 것, 문제가 발생했을 때 멈추고, 분리하고, 되돌릴 수 있는 것도 확인해야 합니다. 소프트웨어의 품질 보증(QA)나 보안에서도 같은 종류의 확인을 합니다.
AI 운영에서는 올바른 답변을 내놓았다는 것 외에 다른 확인이 필요합니다. 적절한 권한으로 허가된 절차를 선택했고, 허용된 범위 내에서 작동했는지 여부입니다. 벤치마크 점수와 운영에 필요한 안전 평가는 분리해서 봐야 합니다.
출력의 정확성을 모델 자체의 설명에 두지 않는 원칙은 'LLM에게 전적으로 맡기는 것'이 위험한 이유, 즉 수학이 보여주는 한계점과 설계로 보완해야 할 세 가지 원칙에 있습니다. 이 글에서 추가할 내용은 정답률을 연속적인 작업에 적용했을 때 주의해야 할 점입니다.
정답률과 권한을 확인한 후 자주 나오는 대책은 '사람이 언제든지 멈출 수 있게 하는 것'입니다. 중단(Stop)할 수 있는 것은 필요합니다. 중지 버튼이 있다는 것과 피해를 막을 수 있는 것은 같지 않습니다.
에이전트가 외부 서비스를 사용한다고 가정해 봅시다. 실행 프로세스를 멈추더라도, 전송된 이메일은 취소할 수 없습니다. 외부에서 시작된 처리가 계속될 수도 있습니다. 삭제한 데이터가 복구되지 않을 수도 있습니다.
기존 설계에서 말하는 페일세이프(Fail-safe)와 다층 방어(Defense in Depth)가 참고가 됩니다. 페일세이프는 고장 났을 때 안전한 쪽으로 기울이는 설계입니다. 다층 방어는 하나의 대책이 빠져도 다른 대책으로 피해를 막는 설계입니다. 대량의 이메일을 처리하게 한다면, 전송 전 확인 외에도 건수 상한선, 수신자 제한, 이상 감지, 전송 대기 큐(queue)를 두어야 합니다. 인증 정보는 짧은 기한으로 무효화할 수 있도록 하고, 필요하다면 외부 통신 자체를 차단해야 합니다. 이것들은 중지 버튼을 대체하는 것이 아닙니다. 중지 버튼과 병용하는 대책입니다.
AI가 항상 안전한 판단을 내린다고 생각해서는 안 됩니다. 오류 가능성을 전제로 삼고, 잘못되었을 때 피해가 확산되지 않도록 해야 합니다. 보안에서 말하는 제로 트러스트(Zero Trust)에 가까운 것이 이 제한입니다. 제로 트러스트는 AI의 판단을 올바르게 만드는 기술이 아닙니다. 인증(Authentication), 인가(Authorization), 최소 권한(Least Privilege)으로 AI의 조작이 영향을 미치는 범위를 좁히는 사고방식입니다. 최소 권한은 작업에 필요한 권한만을 부여하는 원칙입니다.
스스로 절차를 결정할 수 있는 범위가 넓어지면, 중단이나 수정 지시에 따르는지에 대한 문제도 발생합니다. AI 안전성 연구에서는 사람이 수정하거나 멈추는 것을 받아들이는 성질을 Corrigibility(수정 가능성)이라고 부릅니다. Nate Soares 등이 2015년에 정리한 것이 Corrigibility입니다. 현재로서는 모든 고급 AI에 이 속성을 반드시 갖게 하는, 광범위하게 합의된 방법은 없습니다.
모델 연구와 시스템 측면의 제한은 동시에 진행되어야 합니다. 모델이 중단 지시에 따르는 것만으로 피해 방지를 맡겨서는 안 됩니다.
적절한 설계를 한다면 위험은 해결된다고 읽힐 수 있습니다. 하지만 Hinton 씨의 경고에는 다른 문제가 있습니다. 안전 대책이 기술적으로 가능하더라도, 기업이나 사회가 그것을 이행할 것이라고는 확신할 수 없다는 것입니다.
새로운 모델을 빨리 출시하면 이용자를 얻기 쉽습니다. 충분한 안전 평가는 시간과 비용이 듭니다. 경쟁사들이 연이어 공개하는 상황에서, 평가를 우선시하면 공개가 지연됩니다. 대책의 비용은 기업이 부담합니다. 큰 사고의 피해는 사용자나 사회에 미칠 수 있습니다. 한 회사가 안전을 우선해도, 다른 회사가 먼저 공개한다면 그 회사만 불리해집니다.
의약품, 자동차, 항공기, 원자력 분야에서는 진보와 안전 확인을 양립시키기 위해 독립적인 평가나 규제가 만들어져 왔습니다. Hinton 씨가 AI에도 독립적인 평가를 요구하는 것은, 만든 사람 외의 확인이 필요하다고 생각하기 때문입니다.
본인의 제안은 공개한 후에 소송으로 바로잡는 방식이 아닙니다. 미국 식품의약국(FDA)처럼, 공개하기 전에 독립적인 기관을 통해 '이익이 해악보다 크다'는 충분한 통계적 증거를 제시하는 것입니다. 힌튼 씨는 1950년대 탈리도마이드 사례를 들며, 공개된 후에 소송으로 다루는 것은 올바른 방식이 아니었다고 말합니다. 대형 기술 기업들이 지금 하고 있는 일은 이와 같은 취급이라는 것이 힌튼 씨의 주장입니다.
이러한 비유를 AI에 그대로 적용할 수는 없습니다. 의약품은 조건을 정한 임상시험을 통해 유효성과 부작용을 통계적으로 검증합니다. 반면, 범용(General-purpose) AI는 사용처가 광범위하고 공개된 후에 새로운 활용 방식이 생겨납니다. 외부 도구와 결합하면 할 수 있는 것도 달라집니다. 따라서 공개 전의 평가만으로는 공개 후의 새로운 활용 방식을 확인할 수 없습니다. 공개 후의 감시, 사고 보고, 지속적인 검증, 그리고 필요하다면 사용 제한이 필요합니다.
위험의 크기 또한 모두 같지 않습니다. 문장 요약 AI와 중요 인프라 제어에 관련된 AI에 동일한 합격 기준을 적용하는 것이 타당하지 않을 수 있습니다. 용도와 피해 규모에 따라 요구되는 안전 수준이 달라집니다. 누가 합격 기준을 정할 것인가, 즉 '안전을 위한 협력'이 도입되기 전에 이 질문을 던지는 것이 중요합니다.
2026년 9월 21일, 핀란드의 알렉산더 스트룹 대통령과 노르웨이의 요나스 가를 스트레 국무총리가 『A Call for Control of Frontier AI Models』(프론티어 AI 모델 통제 촉구)을 발표했습니다. 프론티어 AI는 현재 가장 높은 수준의 능력을 가진 모델을 지칭합니다. 이 요청의 핵심은 AI가 인간의 지휘, 감독, 제어 하에 있어야 한다는 문장입니다. 기업들에게는 공개 전 필수적인 시험과 평가자가 위험을 판단할 수 있는 접근성을 갖춘 독립적인 평가를 요구하고 있습니다. 안전 규칙이 엄격해질수록, AI의 혜택을 누릴 수 있는 국가와 그렇지 못한 국가 간의 격차를 벌이지 않아야 한다고도 명시했습니다.
대통령실의 'The rapid development of AI requires international cooperation' 문서에는 지금까지 32개국에서 34명의 리더가 참여했다고 언급되어 있습니다. 이는 각국의 법으로 채택된 문서는 아니며, 리더들이 자발적으로 요청한 것입니다. 가디언(Guardian)은 힌튼 씨가 이 요청을 지지하고 있다고 전했습니다. 요청이 먼저 나오고, 11월 3일에 인터뷰가 예정되어 있습니다.
인간이 주도권을 갖기 위해서는 기술로 작동 자체를 제한하는 것만으로는 충분하지 않습니다. 기업의 책임, 제3자의 평가, 그리고 사회적 규칙 또한 필요합니다. 힌튼 씨가 언급한 큰 노력에는 이 세 가지 요소가 모두 포함됩니다.
앞서 언급된 기업의 책임이나 사회적 규칙이 정비될 때까지 배포(출하) 팀의 검토를 미룰 수는 없습니다. 먼저 작성할 수 있는 확인 사항들이 있습니다. 연구자들만 안전에 관심을 가져야 한다는 구분은 이 팀에는 맞지 않습니다. AI가 업무에 투입되면, 안전이 변하는 것은 모델 자체뿐만이 아닙니다. 그 모델을 호출하는 시스템의 설계와 운영 방식에서도 변화합니다.
네 가지를 작성하기 전에, 단 하나만 결정할 수 있습니다. 해당 업무를 AI에게 맡길 필요가 있는지 여부입니다. AI로 할 수 있는 것과 AI로 해야 하는 것은 같지 않습니다. 조건이 명확하게 정의되는 처리라면 기존의 프로그램으로 충분한 경우가 있을 수 있습니다. 얻게 될 이익과 새롭게 발생하는 위험을 비교하여 사용할 기술을 선택해야 합니다. AI에 맡기기로 결정했을 때, 다음 네 가지를 작성합니다.
정보 정리와 제안까지는 AI에게 맡기고, 계약이나 송금의 최종 결정은 사람이 수행합니다. 위험도가 낮은 정형화된 처리는 자동 실행하고, 위험도가 높은 처리만 승인을 받도록 합니다. 이 경계는 프롬프트의 문장으로 작성되는 것이 아니라, 호출 가능한 도구 목록(list of callable tools)으로 작성됩니다.
자연스럽고 설득력 있는 글이라도 반드시 정확한 것은 아닙니다. 업무에서 확인해야 하는 것은 글이 얼마나 잘 쓰였느냐가 아닙니다. 근거 데이터와 실행 결과입니다. AI가 작성한 SQL을 실행한다면, 구문(syntax)이 통하는 것 외에도 참조하는 테이블, 업데이트 범위, 실행 권한 등을 확인합니다.
실수를 전제로 처리 단위를 작게 나누고, 권한을 제한하며, 실행 이력을 남깁니다. 필요하다면 중간에 멈추고 되돌릴 수 있도록 합니다. '절대 틀리지 않는 것'만을 목표로 하면, '틀린 후의 중단 및 복구 방식'이 설계에서 빠지게 됩니다. '실수하더라도 큰 사고가 나지 않도록 하는 것'을 또 하나의 목표로 삼아야 합니다.
취소 가능한 작업과 취소 불가능한 작업을 구분하는 것은 '인간 대체(human replacement)'를 목표로 하지 않는, 아기레(Agirre)의 Better Path 개념을 AI 에이전트의 권한 설계에 적용하는 것입니다.
AI가 판단했다고 해서 운영 책임이 사라지는 것은 아닙니다. 누가 승인하고, 어떤 기준으로 실행하며, 문제가 발생했을 때 누가 대응할 것인지가 설계 항목에 포함되어야 합니다. 책임자의 이름 칸이 비어 있는 처리는 자동 실행으로 넘어가기 전 확인 사항으로 남겨둡니다.
네 가지 확인 항목을 작성하는 일은 코드를 빠르게 작성하는 것과는 다릅니다. 지금까지 기술자에게 요구되어 온 것은 요청된 기능을 구현할 수 있는 능력입니다. 그 능력이 필요 없어지는 것은 아닙니다.
AI가 프로그램을 작성하고, 테스트를 만들고, 장애 원인의 후보들을 나열하는 환경에서는 기능 구현에 걸리는 시간이 단축될 가능성이 있습니다. 이때 필요한 것은 무엇을 만들지, 어디까지 자동화할지, 완성된 시스템이 업무 속에서 안전하게 작동하는지 확인하는 것입니다.
작성해야 할 내용은 네 가지 질문입니다. AI의 제안을 그대로 채택해도 괜찮은가? 성능이 향상되었을 때 위험성은 증가하지 않았는가? 효율성을 위해 사람의 확인 과정이 빠진 곳은 없는가? 문제가 발생했을 때, 누가 그 결과에 대응할 것인가. 이 네 가지를 권한 설정과 테스트 항목으로 작성하는 것이 앞으로의 업무입니다.
이를 위해 읽어야 할 범위는 모델의 작동 방식(mechanism)만 아닙니다. 소프트웨어 공학 (Software Engineering), 정보 보안 (Information Security), 품질 보증 (Quality Assurance), 운영, 위험 관리, 필요한 범위의 법률 및 윤리까지 포함합니다. 모든 것을 같은 깊이로 배울 필요는 없습니다. 자신의 시스템에서 어떤 판단이 빠져 있는지 알기 위해 활용하는 것입니다.
AI로 인해 작업 시간이 단축되는 부분은 있습니다. 기술을 업무와 사회 속에서 안전하게 작동시키겠다는 책임은 줄어들지 않습니다. 사람과 함께 판단하고 책임을 지는 것에 대해서는, 'AI를 사용할 수 있다'만으로는 부족합니다. Gartner의 예측이 보여주듯이, 앞으로 교육이 키워야 할 7가지 능력에 대해 작성했습니다. 결론은 같습니다. 7가지 능력 목록은 해당 기사에 있습니다.
확인 항목과 기술자의 업무를 살펴보았으니, 인터뷰의 첫 문장으로 돌아가겠습니다. 아직 통제하고 있다는 것은 본인의 직관입니다. 잘 되게 하는 조건은 큰 노력이 필요합니다.
이 문장은 고도화된 AI의 모든 위험을 현재 기술로 완벽하게 제어할 수 있다는 의미는 아닙니다. 그러한 보장은 현시점에는 존재하지 않습니다. 고용 변화, 경제 격차, 가짜 정보나 편향된 정보가 확산되는 것, 결정 권한이 일부 조직에 집중되는 것은 접근 통제(Access Control)만으로는 해결되지 않습니다.
그럼에도 불구하고 사람이 결정할 수 있는 것은 있습니다. 어떤 권한을 넘겨줄지. 어떤 용도로 사용할지. 어떤 평가를 거친 시스템을 업무에 도입할지. 위험이 확인되었을 때, 어떤 제한을 걸지. 얻은 이익을 누구를 위해 사용할지. 이것들은 성능이 높아진다고 해서 자동으로 결정되는 문제가 아닙니다.
주도권(Authority)이란 모든 과제에서 인간의 지능이 우위에 있다는 것을 의미하는 것만은 아닙니다. AI가 더 높은 능력을 갖게 되는 분야가 늘어나더라도, 무엇에 사용할지, 어느 정도까지 허용할지를 사람이 결정하는 상태를 유지하는 것입니다. 기술로 조작을 제한하는 문제이며, 사회가 어떤 사용 방식을 선택할지의 문제입니다.
주도권의 의미는 앞 절과 같습니다. 사람이 사용 방식과 허용되는 조작을 결정하는 상태입니다. 다음 설계 검토(Design Review)에서 작성할 것은 그 상태를 시스템 설정으로 만드는 것입니다.
AI의 발전을 멈출지, 가속화시킬지만으로는 해당 검토가 끝나지 않습니다. 능력이 높아지는 속도에 맞춰 평가와 제한, 운영이 따라잡고 있는지를 살펴봐야 합니다. 성능 연구와 안전 연구, 새로운 기능과 예상치 못한 동작 탐지는 둘 다 필요합니다. 도입하는 팀이 검토에서 결정할 수 있는 것은 좀 더 앞선 항목들입니다.
접근 권한을 어떻게 나눌지. 로그를 어디까지 남길지. 어떤 처리에 승인을 거칠지. 이상 징후를 어떻게 발견할지. 장애가 발생했을 때, 피해를 어디서 막을지. 이것들은 일상적인 개발과 운영 과정에서 이미 결정하고 있는 것입니다. 네 가지 확인 항목은 이 일상의 결정 사항들을 에이전트(Agent)용으로 재작성한 것입니다.
기존 기술로 대처할 수 있는 문제와, 새로운 연구, 제도, 국가를 넘나드는 협력이 필요한 문제가 모두 존재합니다. 시스템을 설계하는 사람, 도입을 결정하는 조직, 운영하는 사람에게도 결정할 수 있는 부분이 있습니다.
Hinton 씨의 경고는 나쁜 결과가 이미 결정되었다는 예측으로 받아들일 필요가 없습니다. 지금이야말로 큰 노력을 구체적인 내용으로 작성할 수 있다는 촉구입니다. 출하해도 되는지는 확인하고 작성한 항목으로 판단합니다.
다음 설계 검토에서는 에이전트에게 제공할 도구를 늘리기 전에, 네 가지 확인 항목을 작성할 것입니다. 위임하는 판단, 검증 대상, 실패를 막는 위치, 실행 책임자입니다. 하나라도 공란이라면, 그 조작은 자동 실행으로 진행되기 전의 확인 사항으로 남겨둡니다.
인간이 주도권을 갖는지 여부는 AI의 성능만으로는 결정되지 않습니다. 위임하는 판단, 검증 대상, 실패를 막는 위치, 실행 책임자. 이 네 가지가 현재 설계에서 어떻게 작성되느냐에 따라서도 결정됩니다.
작성일: 2026-11-04