다음 모델의 도약 이전에 AI에게 브레이크 페달이 필요한 이유

가장 실질적인 AI 안전 기능은 선언문이 아닙니다. 그것은 시스템이 비용이 많이 들거나, 위험하거나, 되돌리기 어려운 행동을 시작할 때 실제로 작동하는 브레이크 페달(brake pedal)입니다.

그 생각은 이번 주에 특히 시의적절하게 느껴졌습니다. BBC는 Anthropic의 공동 창립자인 Jack Clark가 AI가 인간의 개입이 줄어든 상태로 개발될 수 있는 지점에 도달하고 있다고 경고했다고 보도했습니다. Reuters는 모델이 출시되기 전에 미국 정부의 포괄적인 승인을 요구해서는 안 된다는 Sam Altman의 주장을 보도했습니다. OpenAI 또한 새로운 생물 방어(biodefense) 관련 글을 게시하며, 프런티어 모델(frontier models)이 점점 더 심각해지는 실제 오용 시나리오에 대해 평가받고 있음을 상기시켰습니다.

이러한 이야기들은 보통 정책적 드라마로 프레임이 짜여집니다: 속도를 높일 것인가, 늦출 것인가, 규제할 것인가, 규제하지 않을 것인가. 개발자(Builders)들은 이를 다르게 읽어야 합니다. 유용한 질문은 더 간단합니다: 만약 당신의 앱이 내일 갑자기 훨씬 더 강력한 모델에 대한 접근 권한을 얻게 된다면, 제품 전체를 종료하지 않고도 속도를 늦출 수 있는 어떤 제어 수단이 있습니까?

브레이크 페달은 제품 요구 사항입니다

대부분의 팀은 이미 일반적인 소프트웨어를 위한 기능 플래그(feature flags), 속도 제한(rate limits), 롤백 계획(rollback plans), 그리고 사고 대응(incident response)을 이해하고 있습니다. AI 제품도 동일한 근력이 필요하지만, 서버 동작뿐만 아니라 모델의 동작에 맞춰 조정되어야 합니다.

A 브레이크 페달은 위험이 증가할 때 능력, 범위, 속도, 접근성 또는 자율성을 줄이는 모든 메커니즘을 의미합니다. 이는 위험한 작업을 더 약한 모델로 라우팅하거나, 신뢰도 임계값(confidence threshold) 이상의 경우 인간의 검토를 강제하거나, 신규 계정에 대한 도구 사용(tool use)을 비활성화하거나, 지출 한도를 낮추거나, 에이전트(agent)가 정의된 정책 범위를 벗어난 행동을 시도할 때 일시 중지하는 방식 등으로 나타날 수 있습니다.

핵심은 AI를 지루하게 만드는 것이 아닙니다. 핵심은 강력한 AI를 배포 가능하게(deployable) 만드는 것입니다. 코드를 작성하고, 내부 문서를 탐색하며, API를 호출하고, 워크플로(workflow) 전반에 걸쳐 작동할 수 있는 모델은 행동하기 때문에 유용합니다. 그것이 바로 모델이 자신의 행동을 멈추거나, 늦추거나, 좁힐 수 있는 명확한 방법이 필요한 이유이기도 합니다.

정책 논쟁이 엉망인 아키텍처를 구원하지는 못할 것입니다

Altman이 모델 승인을 의무화하는 것에 대해 반대 의견을 냈다고 알려진 점은 한 가지 관점에서 타당합니다. 느린 승인 절차는 유용한 작업을 동결시키고, 규제 준수 비용을 감당할 수 있는 거대 기업들에게만 유리하게 작용할 수 있기 때문입니다. 하지만 그 반대의 극단적인 상황 역시 취약합니다. 만약 모든 팀이 내부적인 제어 평면 (control plane) 없이 단순히 더 강력한 모델을 제품에 출시한다면, 첫 번째 심각한 사고가 발생했을 때 비로소 제어 평면이 강제로 도입될 것입니다.

이는 개발자들에게 좋지 않은 거래입니다. 외부 규제는 늦게 도착할 수도 있고, 아마도 투박한 형태일 것입니다. 반면 내부 통제는 구체적일 수 있습니다. 의료 보조 도구, 교실 튜터, 코딩 에이전트, 그리고 영업 자동화 봇은 모두 동일한 브레이크 페달을 필요로 하지 않습니다. 이들에게는 그들이 초래할 수 있는 위해(harm)에 맞춘 브레이크가 필요합니다.

예를 들어, 로컬 에디터에서 차이점(diffs)만 제안하는 코딩 어시스턴트는 운영 환경 자격 증명 (production credentials)을 가진 에이전트보다 더 많은 자유를 허용할 수 있습니다. 답장 초안을 작성하는 고객 지원 봇은 환불을 처리하는 봇보다 더 완화된 통제를 받을 수 있습니다. 공개 논문을 요약하는 AI 연구 보조원은 개인 연구 노트 및 조달 시스템에 연결된 보조원과는 다릅니다.

빌더들이 지금 당장 추가해야 할 것들

프런티어 (frontier) 모델이나 빠르게 변화하는 모델을 사용하여 구축하고 있다면, 다음 네 가지 통제 장치부터 시작하십시오.

역량 계층 (Capability tiers): 기본적으로 가장 강력한 모델, 도구, 그리고 컨텍스트 (context)를 모든 요청에 노출하지 마십시오. 작업의 민감도, 사용자 신뢰도, 그리고 비즈니스 가치에 따라 경로를 지정하십시오.
행동 경계 (Action boundaries): 읽기, 초안 작성, 권장, 그리고 실행을 분리하십시오. 조언에서 행동으로 넘어가는 단계는 명시적이어야 하며, 로그가 남아야 하고, 가능한 경우 되돌릴 수 있어야 합니다.
킬 스위치 (Kill switches) 및 폴백 (fallbacks): 전체 앱을 재배포하지 않고도 모델, 도구, 커넥터 또는 워크플로를 비활성화할 수 있도록 만드십시오. 더 약한 수준의 안전 모드 (safe mode)를 준비해 두십시오.
평가 게이트 (Evaluation gates): 일반적인 벤치마크 점수뿐만 아니라, 귀하의 제품에서 실제로 중요한 실패 사례들을 테스트하십시오. 오용 사례 (abuse cases), 개인정보 유출, 잘못된 도구 호출 (tool calls), 그리고 과도하게 확신에 찬 답변 등을 포함하십시오.

이것들은 화려한 기능들이 아닙니다. 출시 데모(launch demos)에 등장하는 일도 거의 없습니다. 하지만 이것은 성숙해질 수 있는 AI 기능과, 확장하기에는 너무 위험해지는 기능 사이의 차이를 결정짓는 요소입니다.

안전(Safety)은 속도의 이점이 될 수 있습니다

팀들은 때때로 안전(safety) 작업을 일종의 세금처럼 취급합니다. 그것은 근시안적인 생각입니다. 좋은 제어 장치(controls)는 실수를 억제할 수 있게 해주기 때문에 더 빠르게 제품을 출시(ship)할 수 있게 해줍니다. 만약 새로운 모델이 계획(planning) 능력은 더 뛰어나지만 도구(tools) 사용에 있어 가끔 너무 공격적이라면, 계획 용도로만 배포할 수 있습니다. 만약 모델이 숙련된 사용자에게는 훌륭하지만 초보자에게는 혼란스럽다면, 역할(role)에 따라 접근을 제한할 수 있습니다. 만약 모델 업데이트로 인해 동작이 변한다면, 조사하는 동안 트래픽을 이전 상태로 되돌릴(route back) 수 있습니다.

이는 모델 출시가 점점 예측 불가능해짐에 따라 특히 중요해집니다. 여러분의 스택(stack)에서 사용 가능한 가장 강력한 모델은 벤더(vendor)의 업데이트, 오픈 소스(open-source) 출시, 가격 하락, 또는 새로운 하드웨어 제약 조건으로 인해 변경될 수 있습니다. 여러분의 제품은 역량이 오직 느리고 계획된 단계로만 움직인다고 가정해서는 안 됩니다.

가까운 미래의 AI 앱은 단순히 더 나은 두뇌를 가진 채팅창이 아닙니다. 그것은 권한(permissions), 메모리(memory), 도구(tools), 예산(budgets), 평가(evaluation), 그리고 에스컬레이션 경로(escalation paths)를 갖춘 시스템입니다. 이는 모델을 둘러싼 엔지니어링 규율(engineering discipline)이 모델 자체만큼이나 중요하다는 것을 의미합니다.

AI 제품을 위한 간단한 테스트

한 가지 불편한 질문을 던져보십시오: 만약 다음 주에 모델의 능력이 두 배로 향상된다면 어떤 일이 벌어질까요?

만약 그 대답이 사용자들이 단순히 더 나은 결과를 얻게 된다는 것이라면, 계속 진행하십시오. 하지만 솔직한 답변이 의도보다 더 많은 작업을 수행하거나, 개인적인 컨텍스트(private context)를 노출하거나, 너무 많은 돈을 쓰거나, 혹은 수동으로 프로덕션 패치(production patch)를 강제해야 할 수도 있다는 것이라면, 여러분에게는 아직 브레이크 페달이 없는 것입니다.

브레이크 페달을 추가하기 가장 좋은 시점은 여러분의 실패 사례가 스크린샷으로 돌아다니기 전이지, 다음 모델의 도약 이후가 아닙니다.

참고 문헌

원문 게시처: https://blog.jenuel.dev/blog/ai-needs-a-brake-pedal-before-next-model-jump