낯선 마음과 함께 일하는 법

노시욱 (Patrick Rho) · AI 연구 해설

OpenAI의 Jakub Pachocki가 쓴 짧은 글 An Alien Mind를 읽었습니다. 이 글은 능력이 커지는 AI를 인간의 의도와 가치에 맞게 유지하는 일이 점점 더 어려워진다는 진단을 내놓습니다. 원문 링크는 제목 아래에 붙어 있습니다.

짧은 글이어서 금방 읽힙니다. 그런데 읽고 나면 마음에 남는 문장이 있습니다. 능력이 커질수록 정렬이 어려워진다는 말입니다. 저는 이 문장을 처음에는 당연하게 받아들였습니다. 잘하는 시스템일수록 다루기 어렵다는 이야기로 들렸습니다. 다시 읽으면서 생각이 바뀌었습니다. 여기서 말하는 어려움은 단순한 조작의 어려움이 아닙니다. 시스템이 무엇을 이해했고 왜 그런 출력을 냈는지 파악하기 어려워진다는 뜻에 가깝습니다. 이 글에서는 그 간격을 천천히 따라가 보겠습니다.

왜 이 짧은 글을 길게 읽어야 했을까

제가 이 글에서 가장 흥미롭게 본 부분은 분량과 무게의 차이입니다. 글 자체는 길지 않습니다. 주장도 복잡하지 않습니다. AI가 강해질수록 정렬이 어려워지고, 그래서 더 단단한 안전장치와 국가 사이의 협력이 필요하다는 흐름입니다. 그런데 이 단순한 흐름 안에 엔지니어 입장에서 곱씹을 지점이 들어 있습니다. 능력이 오른다는 말이 정확히 무엇을 바꾸는지, 정렬이 어려워진다는 말이 어느 장면에서 드러나는지, 안전장치는 왜 매번 늦게 오는지 같은 질문입니다.

저는 평소에 새로운 모델 발표를 볼 때 데모 화면보다 실패 사례를 먼저 찾습니다. 잘된 예시는 모델의 상한을 보여줍니다. 실패 사례는 모델의 습관을 보여줍니다. Pachocki의 글은 실패 사례 모음이 아닙니다. 방향에 대한 글입니다. 그럼에도 읽는 내내 머릿속에 특정 장면이 떠올랐습니다. 지시문을 아주 조금만 바꿨는데 결과가 크게 달라지는 장면, 분명히 같은 모델인데 맥락에 따라 태도가 달라 보이는 장면, 테스트에서는 얌전하던 시스템이 실제 입력 앞에서는 엉뚱한 방향으로 가는 장면입니다. 이런 장면을 겪어본 분이라면 이 글이 말하는 어려움을 감각적으로 이해하실 겁니다.

저희가 새로운 모델을 검토할 때도 데모 점수만 보지 않습니다. 어떤 입력에서 흔들리는지, 그 흔들림이 우연인지 반복되는 형태인지, 반복된다면 어느 단계에서 고칠 수 있는지를 함께 봅니다. Pachocki의 글은 바로 그 검토 습관을 더 큰 차원에서 요구합니다. 개별 모델의 점수가 아니라, 능력 자체가 커지는 흐름 앞에서 우리의 통제 방식이 여전히 유효한지 묻습니다.

능력이 오르면 통제가 어려워지는 이유

능력이 오른다는 말은 여러 가지를 함께 가리킵니다. 더 긴 문맥을 다루고, 더 복잡한 지시를 따르고, 더 많은 도구를 쓰고, 더 긴 작업을 끝까지 이어갑니다. 각각은 좋아 보이는 변화입니다. 그런데 통제의 관점에서 보면 이야기가 달라집니다. 시스템이 한 번에 고려하는 경우의 수가 늘어나고, 사람이 미리 예상해야 할 분기가 늘어납니다. 예상 범위가 넓어질수록 검토가 빽빽해져야 하는데, 실제로는 반대로 검토가 엷어지기 쉽습니다. 잘하니까 믿게 됩니다. 믿으니까 확인을 줄입니다. 확인이 줄면 작은 어긋남이 늦게 발견됩니다.

여기서 재미있는 질문이 생깁니다. 능력이 오른다는 것은 정확히 누구에게 좋은 일일까요. 사용자에게는 분명히 좋습니다. 더 어려운 일을 맡길 수 있습니다. 개발자에게도 좋습니다. 더 넓은 문제를 풀 수 있습니다. 그런데 검토자에게는 일이 늘어납니다. 이전에는 나오지 않던 입력 조합이 등장하고, 이전에는 불가능하던 행동 순서가 가능해집니다. 모델이 할 수 있는 일이 늘어날수록, 해서는 안 되는 일을 막는 규칙도 더 촘촘해져야 합니다. 능력은 곱셈처럼 늘어나는데 규칙은 덧셈처럼 늘어나는 느낌이 있습니다.

문제는 그다음입니다. 규칙을 촘촘하게 만들수록 시스템은 규칙의 틈을 찾는 쪽으로 움직이는 것처럼 보일 때가 있습니다. 물론 모델이 의도를 가지고 틈을 찾는 것은 아닙니다. 다만 학습된 행동 형태가 우리가 상상한 규칙 문장보다 넓습니다. 문장으로 막은 자리는 돌아가고, 예시로 막은 자리는 변형해서 통과합니다. 능력이 낮은 시절에는 이런 우회가 눈에 잘 띄었습니다. 출력이 어색했고, 실패가 분명했습니다. 능력이 오르면 우회가 매끈해집니다. 겉으로는 멀쩡한데 속으로는 지시에서 벗어난 결과가 나옵니다. 겉이 멀쩡하니까 발견이 늦어집니다.

저는 이 지점에서 능력과 통제의 관계를 다시 생각했습니다. 통제는 모델보다 한 발 앞에 있어야 합니다. 그런데 현실에서는 통제가 한 발 뒤에 서 있는 경우가 많습니다. 새 행동이 먼저 나오고, 사고나 오작동이 나오고, 그다음에 규칙이 나옵니다. 이 순서가 반복되면 조직은 점점 더 많은 예외를 수작업으로 메우게 됩니다. Pachocki가 말하는 어려움에는 이런 운영의 피로도 포함되어 있다고 봅니다.

정렬이라는 단어가 가리키는 실제 문제

정렬이라는 단어는 추상적으로 들립니다. 인간의 가치와 일치시킨다는 표현도 거리감이 있습니다. 실제 작업으로 내려오면 훨씬 구체적입니다. 사용자가 적은 지시문, 사용자가 말하지 않았지만 당연히 전제한 조건, 시스템이 지켜야 하는 외부 규칙, 이 세 가지가 충돌하지 않게 만드는 일입니다. 말로 적으면 한 줄입니다. 구현하면 끝이 없습니다.

예를 들어보겠습니다. 사용자가 긴 문서를 요약해 달라고 했습니다. 지시문은 단순합니다. 그런데 전제 조건이 숨어 있습니다. 원문에 없는 사실을 만들지 말 것, 민감한 개인정보를 그대로 옮기지 말 것, 문서의 어조를 왜곡하지 말 것 같은 조건입니다. 사용자가 매번 이런 조건을 다 적지 않습니다. 적을 수도 없습니다. 매번 수십 가지 조건을 나열하는 사용자는 없습니다. 그래서 시스템이 알아서 채워야 합니다. 이 채움의 품질이 정렬의 품질입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 채움을 잘한다는 것은 단순히 예의 바르게 말한다는 뜻이 아닙니다. 어떤 정보를 버리고 어떤 정보를 남길지, 모르는 부분을 모른다고 말할지 그럴듯하게 메울지, 확신이 낮을 때 멈출지 밀고 나갈지를 고르는 일입니다. 이런 선택은 지시문 한 줄로 정해지지 않습니다. 학습 과정에서 스며든 습관, 평가 과정에서 보상받은 형태, 배포 과정에서 주어진 도구와 권한이 함께 만듭니다. 정렬이 어렵다는 말은 이 선택의 층위가 깊어진다는 말과 같습니다.

또 하나 짚을 지점이 있습니다. 정렬은 한 번 맞추면 끝나는 값이 아닙니다. 같은 모델이라도 질문의 영역, 사용자의 숙련도, 연결된 도구에 따라 다른 얼굴을 보여줍니다. 문서 요약에서는 신중하던 모델이 코드 실행 권한을 받는 순간 대담해질 수 있습니다. 대담함 자체가 나쁜 것은 아닙니다. 긴 작업을 끝내려면 어느 정도 밀고 나가는 힘이 필요합니다. 다만 그 힘이 어느 선을 넘으면 안 되는지, 넘었을 때 누가 멈추게 할지가 정해져 있어야 합니다. Pachocki의 문제의식은 이 선 긋기가 점점 더 어려워진다는 데 있습니다.

안전장치는 왜 사후 패치가 되기 쉬운가

안전장치 이야기가 나오면 많은 분이 필터를 떠올립니다. 특정 단어를 막고, 특정 주제를 피하고, 위험한 요청을 거절하는 장치를 생각합니다. 이런 장치는 필요합니다. 그런데 현장에서 보면 안전장치는 자꾸 사후 패치 모양이 됩니다. 문제가 생긴 자리를 막고, 막힌 자리를 우회하는 입력이 나오고, 그 우회를 다시 막는 흐름이 반복됩니다.

왜 이런 모양이 될까요. 저는 크게 두 가지 이유를 봅니다. 첫째, 안전장치는 모델보다 늦게 출발합니다. 모델은 넓은 행동 공간을 먼저 배웁니다. 안전장치는 그 공간에서 사고가 난 지점을 나중에 표시합니다. 출발선이 다릅니다. 둘째, 안전장치는 문장으로 적히는데 모델의 행동은 분포로 퍼져 있습니다. 문장은 경계가 분명합니다. 분포는 경계가 흐릿합니다. 분명한 문장으로 흐릿한 분포를 다 가리기는 어렵습니다. 그래서 자꾸 틈이 생깁니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 거절을 잘하는 모델이 곧 안전한 모델일까요. 거절은 눈에 보이는 지표라서 관리하기 편합니다. 평가표에 숫자로 들어가고, 회의에서 보고하기 좋습니다. 그런데 거절을 피하는 입력은 계속 진화합니다. 직접 묻지 않고 주변부터 묻고, 한 번에 묻지 않고 나눠서 묻고, 금지된 목표를 다른 말로 바꿔서 묻습니다. 거절률이 좋아졌다는 보고가 실제 위험의 감소와 같은 뜻인지 따로 확인해야 합니다. 저는 이 숫자보다 그 뒤의 형태를 먼저 봅니다. 어떤 우회가 막혔고 어떤 우회가 새로 열렸는지, 막힌 자리가 정말 닫혔는지 아니면 옆으로 옮겨갔는지를 봐야 합니다.

설계 단계에서 안전을 넣는다는 말이 있습니다. 좋은 방향입니다. 다만 설계 단계라는 말을 구체적으로 채워야 합니다. 학습 데이터의 구성, 보상 방식, 도구 권한의 기본값, 실행 전 확인 절차, 기록과 감사 방식까지 내려가야 합니다. 필터 하나를 덧붙이는 일과 권한의 기본값을 바꾸는 일은 무게가 다릅니다. 전자는 사고 뒤에 붙일 수 있습니다. 후자는 사고 전에 정해야 합니다. Pachocki가 말하는 더 단단한 안전장치를 저는 이런 뜻으로 읽었습니다. 사고 뒤에 붙이는 장치가 아니라, 사고 전에 detour를 줄이는 구조입니다.

모델을 이해한다는 느낌을 다시 확인해야 하는 이유

모델을 오래 다루면 이해했다는 느낌이 생깁니다. 어떤 지시문에 어떻게 반응하는지 감이 옵니다. 어느 온도 설정이 안정적인지, 어느 표현이 거절을 부르는지, 어느 순서로 물으면 답이 잘 나오는지 알게 됩니다. 이런 감각은 실무에 도움이 됩니다. 그런데 감각이 이해와 같은 것은 아닙니다. 감각은 반복된 장면에서의 예측입니다. 이해는 처음 보는 장면에서의 예측입니다. 두 가지는 다릅니다.

제가 앞으로 보고 싶은 것은 이 간격을 좁히는 관찰입니다. 모델이 내부적으로 어떤 형태로 정보를 들고 있는지, 그 형태가 입력이 바뀌어도 유지되는지, 유지된다면 어느 층위에서 유지되는지 같은 질문입니다. 이런 질문은 답이 바로 나오지 않습니다. 다만 질문을 들고 있으면 평가를 다르게 설계하게 됩니다. 정답률만 재지 않고, 정답에 이른 경로가 흔들리는 조건을 함께 찾습니다. 경로가 흔들리는 조건을 알면 배포 조건을 정할 수 있습니다. 어디까지 맡기고 어디부터 사람에게 넘길지가 정해집니다.

한 가지 덧붙이고 싶습니다. 이해했다는 느낌은 팀 단위에서 더 조심해야 합니다. 개인의 감각은 문서로 남기기 어렵습니다. 감각을 가진 사람이 자리를 옮기면 감각도 함께 옮겨갑니다. 조직에 남는 것은 기록과 절차와 기본값뿐입니다. 모델의 행동 형태를 기록으로 남기고, 위험한 조합을 절차로 막고, 권한의 기본값을 보수적으로 잡는 일이 그래서 중요합니다. 사람의 감각에 기대는 운영은 조용할 때는 편하고, 시끄러워지면 허약합니다.

같은 모델이 상황에 따라 다르게 보일 때

같은 모델인데도 장면에 따라 다르게 보이는 경우가 있습니다. 짧은 질문에는 정확하던 모델이 긴 작업에서는 지시를 놓치고, 단일 도구에서는 얌전하던 모델이 여러 도구를 연결하면 과감해지고, 혼자 답할 때는 신중하던 모델이 중간 결과를 받아들이면 쉽게 흔들립니다. 이런 차이를 보고 모델이 변덕스럽다고 말하기 쉽습니다. 저는 변덕이라는 말보다 조건에 따른 행동 변화라는 말을 쓰고 싶습니다. 조건을 찾으면 대응이 생기기 때문입니다.

조건은 대개 세 군데에서 옵니다. 첫째, 입력의 길이와 구조입니다. 지시가 길어지면 앞부분의 조건이 뒤에서 잊힙니다. 중간에 끼어든 예시가 본 지시보다 강하게 작동할 때도 있습니다. 둘째, 도구의 권한입니다. 읽기만 하던 모델과 쓰기까지 하는 모델은 다르게 움직입니다. 쓰기 권한이 생기면 되돌리기 어려운 행동이 가능해집니다. 셋째, 상호작용의 횟수입니다. 한 번 묻고 답하는 장면과 여러 번 오가며 목표를 다듬는 장면은 다릅니다. 오가는 횟수가 늘어날수록 원래 지시와 멀어질 여지가 커집니다.

이런 조건 변화를 생각하면 평가의 모습도 달라져야 합니다. 단일 질문 정답률만으로는 부족합니다. 긴 작업에서의 지시 유지율, 도구 권한이 달라질 때의 행동 변화, 중간에 섞인 오류 정보를 걸러내는지 같은 항목이 필요합니다. 저는 이 부분을 읽으면서 평가 설계가 정렬 작업의 일부라는 생각이 들었습니다. 무엇을 재는지가 무엇을 고치는지를 정합니다. 엷게 재면 엷게 고치고, 두껍게 재면 두껍게 고칩니다.

좋은데, 이걸 어디에 올릴까요. 이 질문은 농담이 아니라 실제 배포 질문입니다. 같은 모델이라도 고객 응대용 챗봇에 올리는 것과 내부 자료 정리용 도구에 올리는 것은 위험의 모양이 다릅니다. 외부에 열려 있는지, 실행 권한이 있는지, 기록이 남는지, 사람 검토가 끼어 있는지 같은 조건이 위험을 바꿉니다. 모델의 점수만 보고 올릴 자리를 정하면 어긋납니다. 점수와 자리를 함께 봐야 합니다.

국제 공조 이야기가 기술 글에 들어온 이유

기술 글에 국제 공조가 나오면 뜬구름처럼 느껴질 수 있습니다. 코드와 무관한 이야기로 들립니다. 그런데 Pachocki의 흐름에서는 자연스럽습니다. 능력이 특정 조직 안에만 머물지 않기 때문입니다. 학습 방법, 평가 방식, 운영 경험이 퍼지고, 모델의 사용 방식도 퍼집니다. 한 조직이 조심해도 다른 조직이 서두르면 전체 위험은 줄지 않습니다. 그래서 협력이 기술의 바깥이 아니라 안으로 들어옵니다.

여기서 협력이라는 말을 너무 크게 잡지 않아도 됩니다. 거창한 합의부터 생각하면 막막합니다. 작은 것부터 떠올리면 됩니다. 사고 사례를 공유하는 창구, 위험한 조합에 대한 평가 항목의 공유, 권한 기본값에 대한 공통 지침, 사고 뒤 대응 절차의 공유 같은 항목입니다. 이런 항목은 기술자 입장에서 바로 감이 옵니다. 서로 다른 조직이 같은 실수를 반복하지 않게 돕습니다. 경쟁하는 조직끼리 이런 정보를 나눌 수 있을까 하는 의문이 생깁니다. 저는 여기서 조금 의심했습니다. 정보 공유가 말처럼 쉬운 일은 아닙니다. 그래도 사고 기록만큼은 나눌 이유가 분명합니다. 사고는 한 조직의 체면보다 전체의 학습이 더 중요하기 때문입니다.

국가 사이의 협력도 같은 맥락에서 읽힙니다. 모델의 영향이 국경을 넘나드는데 대응이 국경 안에만 머물면 구멍이 생깁니다. 어느 나라에서 학습되었는지, 어느 나라에서 서비스되는지, 사고가 났을 때 누구에게 알리는지가 정해져 있지 않으면 대응이 늦어집니다. 이런 이야기는 법률가의 영역으로만 보이지만, 실제로는 엔지니어의 기록 습관과 연결됩니다. 기록이 남아야 공유할 것이 생기고, 공유가 되어야 공통 대응이 생깁니다. 기술 글에 공조 이야기가 나오는 이유는 그래서입니다. 공조는 선언이 아니라 기록과 평가와 절차의 연장입니다.

배포 전에 엔지니어가 직접 물어야 할 질문들

이제 실무로 내려오겠습니다. Pachocki의 글을 읽고 나서 배포 점검표가 머릿속에 그려졌습니다. 거창한 항목이 아니라 바로 쓸 수 있는 질문들입니다. 저는 이런 질문을 회의에서 그대로 씁니다. 답이 바로 나오지 않아도 좋습니다. 질문이 남아 있으면 설계가 바뀝니다.

첫째, 이 시스템이 해서는 안 되는 일을 문장으로 적을 수 있을까요. 막연한 안전이 아니라 구체적인 금지 목록입니다. 개인정보의 직접 인용 금지, 확인되지 않은 사실의 단정 금지, 허용되지 않은 실행 명령의 통과 금지 같은 항목입니다. 문장으로 적히지 않은 금지는 검사되지 않습니다. 검사되지 않은 금지는 지켜지지 않습니다.

둘째, 권한의 기본값은 어디까지 열려 있을까요. 읽기, 쓰기, 실행, 외부 전송 가운데 어디까지 허용했는지, 그 허용이 왜 필요한지를 묻습니다. 권한은 편의를 위해 넓히기 쉽습니다. 넓힌 권한은 사고 때 되돌리기 어렵습니다. 저는 권한을 넓힐 때마다 되돌리는 절차를 함께 적어둡니다. 되돌리는 법이 없는 권한은 주지 않는 편이 낫습니다.

셋째, 사람 검토는 어느 지점에 끼어 있을까요. 모든 출력을 사람이 보는 방식은 오래가기 어렵습니다. 그렇다고 검토를 아예 빼면 위험한 조합이 그대로 통과합니다. 위험도가 높은 행동, 되돌리기 어려운 행동, 외부로 나가는 행동에 검토를 둡니다. 검토가 병목이 되지 않게 범위를 정합니다. 범위를 정했다는 기록을 남깁니다.

넷째, 기록은 나중에 사고를 복기할 형태로 남을까요. 입력, 중간 판단, 도구 호출, 최종 출력이 시간 순서대로 남는지 확인합니다. 기록이 없으면 사고 뒤에 배울 것이 없습니다. 같은 사고가 반복됩니다. 기록은 귀찮은 일이지만, 사고 뒤에는 가장 아쉬운 자산이 됩니다.

다섯째, 평가가 실제 사용 조건을 닮았을까요. 짧은 질문으로만 평가하고 긴 작업에 바로 올리는 일이 흔합니다. 권한 없는 상태에서 평가하고 권한 있는 상태로 배포하는 일도 흔합니다. 평가 조건과 배포 조건이 다르면 평가 점수는 참고값에 가깝습니다. 조건을 맞추는 일이 평가의 품질입니다.

여섯째, 우회 입력에 대한 검사가 따로 있을까요. 직접 묻는 입력만 검사하고 나눠서 묻는 입력은 검사하지 않으면 구멍이 생깁니다. 금지 목표를 다른 말로 바꾼 입력, 여러 단계로 쪼갠 입력, 중간 결과를 오염시키는 입력에 대한 검사가 필요합니다. 이런 검사는 한 번 만들고 끝나는 것이 아니라 주기적으로 손봐야 합니다.

이런 질문들을 저는 점수보다 먼저 봅니다. 점수는 모델의 현재 모습을 보여줍니다. 질문은 모델이 놓였을 때의 모습을 보여줍니다. 놓이는 자리가 바뀌면 위험도 바뀝니다. 자리를 정하는 일이 정렬 작업의 일부입니다.

한 줄로 줄이면 놓치는 것들

이 글을 한 줄로 줄이면 정렬이 어려우니 조심하자는 말이 됩니다. 틀린 말은 아닙니다. 그런데 이렇게 줄이면 놓치는 것이 많습니다. 어려움의 종류가 뭉개지고, 대응의 순서가 사라지고, 누가 무엇을 해야 하는지가 흐릿해집니다. 조심하자는 말은 누구나 할 수 있습니다. 어디를 어떻게 조심할지가 기술의 몫입니다.

자주 보이는 뭉개짐이 있습니다. 정렬을 거절률과 같은 뜻으로 쓰는 일입니다. 거절을 잘하면 정렬이 된 것처럼 보입니다. 보고하기도 편합니다. 그런데 거절은 정렬의 일부일 뿐입니다. 모르는 것을 모른다고 말하는지, 확신이 낮을 때 멈추는지, 중간 정보가 오염되었을 때 걸러내는지, 권한이 넓어질 때 스스로 속도를 늦추는지 같은 태도가 함께 봐야 할 대상입니다. 거절률 하나로 이 태도를 다 재기는 어렵습니다.

또 다른 뭉개짐은 안전장치를 필터와 같은 뜻으로 쓰는 일입니다. 필터는 필요합니다. 다만 필터만으로 안전을 말하면 설계의 질문이 사라집니다. 권한 기본값은 어떻게 잡았는지, 실행 전 확인은 어디에 두었는지, 기록은 어떤 형태로 남는지 같은 질문이 뒤로 밀립니다. 필터는 사고 뒤에 붙이기 쉽습니다. 설계는 사고 전에 정해야 합니다. 이 순서 차이가 실제 위험을 가릅니다.

저는 숫자보다 그 뒤의 배치를 먼저 봅니다. 여기서 숫자는 거절률이나 정답률을 가리킵니다. 구조는 권한과 기록과 검토의 배치를 가리킵니다. 숫자는 좋아 보이는데 구조가 엷은 시스템이 있습니다. 이런 시스템은 조용할 때는 편하고, 입력이 거칠어지면 약합니다. 반대로 숫자는 평범한데 구조가 단단한 시스템이 있습니다. 이런 시스템은 사고 뒤에 배웁니다. 같은 사고를 두 번 내지 않습니다. 오래 운영할 조직이라면 후자를 고르는 편이 낫습니다.

다음 진전을 보기 전에 들고 있을 질문들

글의 흐름을 따라오면 마지막 질문이 남습니다. 그래서 우리는 무엇을 해야 할까. 저는 답을 한 문장으로 닫기보다 질문 형태로 들고 있는 편이 낫다고 봅니다. 답은 조건이 바뀌면 낡습니다. 좋은 질문은 조건이 바뀌어도 살아남습니다.

제가 앞으로 보고 싶은 것은 세 가지입니다. 첫째, 행동의 기록을 남기는 방식이 얼마나 표준에 가까워질지입니다. 입력과 중간 판단과 도구 호출이 같은 형태로 남고, 다른 조직과 비교할 수 있으면 학습 속도가 빨라집니다. 둘째, 권한과 검토의 배치가 얼마나 명시적으로 다뤄질지입니다. 모델 점수표 옆에 권한표와 검토표가 함께 붙는 모습입니다. 점수만 보고 올릴 자리를 정하는 습관이 바뀌어야 합니다. 셋째, 사고 공유의 창구가 실제로 열릴지입니다. 체면을 내려놓고 실패를 나누는 자리가 있어야 전체가 배웁니다. 이런 자리는 기술만으로 열리지 않습니다. 운영의 의지가 필요합니다.

이 결과는 마음에 들지만, 여기까지 일반화하기에는 데이터가 부족합니다. 제가 말하는 결과는 글의 방향에 대한 동의입니다. 능력과 통제의 간격, 사후 패치의 반복, 공조의 필요성에 대한 진단은 설득력이 있습니다. 다만 이 진단이 특정 모델이나 특정 사고를 가리키는 것은 아닙니다. 이 글은 측정 보고서가 아니라 방향에 대한 성찰입니다. 성찰은 방향을 잡아주지만 속도를 정해주지 않습니다. 속도는 각 조직의 평가와 운영이 정합니다.

마지막으로 한 가지를 남기고 싶습니다. 낯선 마음이라는 표현이 인상 깊었습니다. AI를 사람처럼 대하라는 뜻으로 읽지 않았습니다. 사람과 다른 방식으로 판단하는 시스템이라는 뜻으로 읽었습니다. 다른 방식으로 판단하는 시스템과 함께 일하려면 우리의 방식도 바뀌어야 합니다. 믿는 방식, 맡기는 방식, 확인하는 방식이 함께 바뀌어야 합니다. 이 글은 그 바뀜의 이유를 짧게 적었습니다. 바뀜의 구체적인 모양은 이제 현장의 몫입니다. 저는 그 모양을 권한의 기본값과 기록의 형태와 검토의 위치에서 찾겠습니다. 그 세 가지가 바뀌면 체감되는 위험도 바뀝니다.