제 블로그 발행 스크립트에는 grep 한 줄이 들어 있었습니다. 글을 올리기 전에 파일을 열어서 판정: 합격 이라는 문자열이 있는지 찾는 코드였습니다. 두 달 반쯤 돌리다가 7월 말에 지웠습니다.
앤트로픽과 오픈AI, 구글이 AI 안전 표준기구를 같이 세우는 걸 논의하고 있다는 기사를 읽다가 그 한 줄이 떠올랐습니다. 한쪽은 프런티어 모델을 만드는 회사들이고 한쪽은 저 혼자 쓰는 블로그 파이프라인이라 나란히 놓기엔 좀 민망한데, 기사를 읽는 내내 그 grep 생각이 떠나지 않았습니다.
검문소와 통행증 발급처가 같았습니다
당시 이 레포에는 보안 기준선이 번호를 달고 몇 개 있었고, 그중 하나가 "게이트 불합격 글은 업로드 차단" 이었습니다. 문장만 보면 꽤 단단해 보입니다. 실제로 하는 일은 단순했습니다. 발행 스크립트가 _workspace/briefs/{slug}-ai-check.md 를 열고, 거기 판정: 합격 이 있으면 올리고 없으면 멈춥니다. 그게 전부였습니다.
그 파일은 AI 문체 검사를 맡은 에이전트가 씁니다. 글을 읽고, 검사 결과를 파일에 적고, 코드는 그 파일에서 문자열을 찾습니다. 검사받는 쪽이 통행증을 발급하고 검문소는 그 통행증이 있는지만 확인하는 모양이었습니다.
처음 걸었을 때는 기분이 좋았습니다. 파이프라인에 단단한 게 하나 생긴 것 같았고, 문서에도 불합격이면 못 나간다고 자신 있게 적어뒀습니다. 그 문장을 쓰면서 이걸로 문체 쪽은 한시름 놨다고 생각했던 게 기억납니다.
그 기분이 사라진 건 발행이 한 번 막혔을 때입니다. 원인을 찾으려고 브리프 파일을 열었는데, 적혀 있는 문장이 제가 봐도 근거가 없었습니다. 무엇을 보고 그렇게 판정했는지가 파일 어디에도 없었고 판정 한 줄만 덩그러니 있었습니다. 그러고 나니 통과한 글들 쪽이 궁금해졌습니다. 열어보니 다 비슷했습니다. 문장 모양만 조금씩 다르고 판정 줄은 전부 같은 모양이었습니다.
"그럼 지금까지 이게 뭘 막은 거지" 하는 생각이 제일 먼저 들었습니다. 두 달 반 동안 이 게이트에 걸린 글이 몇 편 있었는데, 글이 나빠서 걸린 게 아니었다는 걸 그때 알았습니다. 걸린 글과 통과한 글 사이에 품질 차이가 있었던 게 아니라, 브리프에 어떤 문자열이 들어갔느냐의 차이만 있었습니다. 그동안 저는 게이트가 일을 하고 있다고 믿고 있었고, 그 믿음 덕분에 정작 글을 다시 읽어보는 일은 덜 했던 것 같습니다. 게이트가 있다는 사실이 제 눈을 대신하고 있었던 겁니다.
사람 사이에서도 비슷한 일이 있을 것 같습니다. 리뷰어가 승인을 눌러주면 작성자는 자기 코드를 한 번 덜 읽고, 리뷰어는 작성자가 테스트를 돌렸겠거니 하고 넘깁니다. 서로 상대가 보고 있다고 믿으면 결국 아무도 안 보는 상태가 됩니다. 제 grep 은 그 승인 버튼 노릇을 했는데, 버튼을 누른 쪽이 사람도 아니고 저도 아니고 검사받는 글을 쓴 것과 같은 계열의 모델이었습니다. 그러니 저는 아무도 안 본 글을 누군가 봤다고 믿고 내보낸 셈입니다.
지우기까지
게이트를 빼는 건 늘 변명처럼 보여서, 편하자고 지우는 게 아니라는 걸 저 자신한테 먼저 설명해야 했습니다. 그때 적어둔 이유가 셋 있었는데, 이번 뉴스를 읽으면서 그걸 그대로 다시 꺼내 보게 됐습니다.
하나는 방금 말한 자기 채점입니다. 코드가 찾는 문자열을 검사받는 쪽이 썼으니, 이 게이트가 실제로 본 것은 글의 품질이 아니라 서류가 있느냐 없느냐였습니다. 셋 중에 이 문장이 제일 오래 머리에 남았습니다.
또 하나는 오탐이었습니다. 품질 게이트 쪽은 파일 전체에서 \bFAIL\b 를 찾고 있었는데, 그러면 브리프에 "FAIL 조건 없음" 이라고 적혀 있어도 걸립니다. FAIL 이라는 글자가 스치기만 하면 멀쩡한 글이 못 나갔습니다. 그냥 버그라고 넘길 수도 있었는데 저는 그렇게 안 보였습니다. 검사 대상을 문자열로 잡은 이상 이런 사고는 모양만 바꿔서 계속 날 것 같았습니다.
마지막 게 결정적이었습니다. 실패가 반대 방향으로 나고 있었습니다. 나쁜 글은 합격이라고 적으면 통과합니다. 좋은 글은 브리프를 안 만들었거나 FAIL 이 한 번 스치면 막힙니다. 걸러야 할 방향과 정확히 반대로 거르고 있었던 겁니다. 이걸 적고 나니 튜닝으로 손볼 문제가 아니라 애초에 종류가 틀린 물건이라는 생각이 들었습니다.
그래도 지우는 데는 시간이 좀 걸렸습니다. 하네스에서 가드레일을 빼는 일이 넣는 일보다 어렵다는 글을 따로 쓴 적이 있는데, 그때 머릿속에 있던 게 이 일이었습니다. 규칙을 넣을 때는 "혹시 모르니까" 하나로 충분한데, 뺄 때는 안 빼도 되는 이유를 전부 이겨야 합니다. 없애도 아무 일 없다는 건 미리 보여줄 방법이 없습니다. 지우고 나서 한동안 별일이 없으면 그제야 조금 안심이 되는데, 그것도 운이 좋았던 건지 원래 필요 없었던 건지는 끝까지 구분이 안 됩니다. 결국 저는 이 게이트가 무엇을 막고 있었는지를 직접 보고 나서야 지울 수 있었습니다. 막고 있던 게 좋은 글이었다는 걸 본 다음에는 남겨둘 이유를 찾기가 더 어려웠습니다.
같은 레포에 멀쩡한 게이트도 있었습니다
그렇다고 게이트라는 게 다 틀렸다고는 생각하지 않았습니다. 같은 레포에서 잘 돌던 게이트가 하나 있었거든요. 커밋 직전에 시크릿을 찾는 훅입니다. 파일 안에 특정 키 패턴이 있는지를 봅니다. 그 값은 모델이 뭐라고 하든 안 바뀝니다. AWS 키 모양의 문자열이 파일에 있으면 있는 거고 없으면 없는 겁니다. 에이전트가 브리프에 "안전합니다" 라고 적어도 grep 결과는 그대로입니다.
이렇게 쓰고 보면 시크릿 스캔이 더 똑똑한 검사였던 것도 아닙니다. 하는 일만 보면 오히려 더 단순합니다. 정해진 패턴이 파일에 있는지만 봅니다. 문체 게이트도 정해진 문자열이 파일에 있는지만 봤으니, 코드만 놓고 보면 둘은 거의 같은 물건입니다. 차이는 그 파일을 누가 썼느냐 하나였습니다. 시크릿 스캔이 보는 파일은 제가 커밋하려던 코드였고, 문체 게이트가 보는 파일은 검사받는 쪽이 자기 손으로 쓴 판정서였습니다.
둘을 나란히 놓고 보다가 기준을 하나 적었습니다.
검사 결과를 검사받는 쪽이 쓸 수 있는가. 쓸 수 있으면 그건 게이트가 아니라 서류 확인이다.
이렇게 놓고 보면 자율규제냐 아니냐는 생각보다 중요한 질문이 아닌 것 같습니다. 남이 검사한다고 다 되는 것도 아니고 스스로 검사한다고 다 안 되는 것도 아닙니다. 검사 결과가 검사받는 쪽 손에서 나오느냐만 보면 되는 것 같습니다.
이 기준으로 보면 검사가 대충 두 종류로 나뉘는 것 같습니다. 하나는 바깥의 사실을 보는 검사이고, 다른 하나는 누군가의 말을 보는 검사입니다. 파일에 키가 있느냐는 사실이고, 브리프에 합격이라고 적혀 있느냐는 말입니다. 말을 보는 검사가 다 쓸모없다는 건 아닌데, 그 말을 한 쪽이 검사받는 쪽이면 검사가 아니라 받아쓰기가 됩니다.
만약 그 브리프를 제가 직접 썼다면 어땠을까 하는 생각도 해봤습니다. 그러면 판정을 쓰는 손이 검사받는 쪽 손은 아니게 됩니다. 그런데 그건 그냥 제가 글을 읽는 일이고, 굳이 grep 으로 제 문장을 찾을 이유가 없습니다. 제가 읽었으면 그걸로 끝입니다. 그 게이트가 의미가 있으려면 사람이 읽어야 했고, 사람이 읽으면 게이트가 필요 없었다는 얘기가 되는데, 이건 지금 생각해도 좀 우습습니다.
그 시크릿 스캔도 완벽했던 건 아닙니다. 훅을 걸어뒀는데 AWS 키가 그대로 통과한 적이 있고, 훅이 실제로 커밋되는 내용 말고 다른 걸 보고 있던 게 원인이었습니다. 모델 출력과 상관없는 사실을 본다는 건 방향이 맞다는 정도이고, 그 안에서도 얼마든지 틀릴 수 있었습니다.
문체 게이트를 지운 다음에는 판정 라벨을 체크리스트로 바꿨습니다. 합격·불합격 대신 줄 단위로 어디를 어떻게 고쳤는지를 남깁니다. 판정은 없어졌고 검토는 남았습니다. 이게 약해진 건지는 지금도 가끔 확신이 안 섭니다. 멈추는 장치가 있다가 없어졌으니 숫자로만 보면 약해진 게 맞는데, 그 장치가 실제로 멈춘 건 엉뚱한 글이었으니 원래부터 없었던 거나 다름없다는 생각도 듭니다. 그래도 파일을 열면 뭘 봤는지는 보입니다. 예전에는 판정만 보였습니다.
판정만 있는 파일은 읽어도 할 수 있는 게 없습니다. 맞다고 믿거나 틀렸다고 의심하는 것 말고는요. 줄 단위 수정 내역은 적어도 그 줄을 다시 열어서 제 눈으로 볼 수 있고, 거기서 동의가 안 되면 고치면 됩니다. 판정 한 줄보다는 그쪽이 훨씬 할 일이 많은데, 할 일이 많다는 게 이 경우엔 좋은 쪽인 것 같습니다.
7월이라는 단어
뉴스로 돌아가면, 다리오 아모데이가 지난 12일에 「We Must Pace the Frontier」라는 에세이를 냈습니다. 프런티어 AI 개발 속도를 늦추자는 것, 그리고 독립적인 외부 평가기관이 기업 내부 직원과 같은 수준으로 기술에 접근해서 안전성을 검증하게 하자는 게 요지로 보도됐습니다. AI 가 자기 후속 모델을 설계하거나 훈련하는 일은 극히 신중해야 한다는 말, 인간의 목표와 반대로 가는 에이전트 군집이 인터넷을 장악하는 시나리오에 대한 경고도 같이 들어 있었다고 합니다. 단계는 셋으로 나눴습니다. 랩 내부에 독립 평가자를 두고, 그다음 민주적 조율, 마지막으로 글로벌 조율입니다.
여기에 동의한다는 사람이 빠르게 늘었습니다. 샘 알트먼, 데미스 하사비스, 일론 머스크, 사티아 나델라가 차례로 비슷한 말을 보탰습니다. 나델라는 의도적인 속도 조절을 환영한다고까지 했습니다. 그리고 하루 뒤에 워싱턴포스트가 표준기구 논의를 보도했습니다. 세 회사의 CEO 아래 직급 실무그룹이 정기적으로 만나 왔고, 공동 안전 표준을 만들고 프런티어 모델을 테스트하고 미국 정부와 감독을 조율하는 권한을 이야기하고 있다는 내용이었습니다.
저는 권한 목록보다 7월 이라는 단어에서 먼저 멈췄습니다. 실무그룹이 만나기 시작한 게 7월이고 아모데이의 공개 제안은 9월입니다. 제안이 나오고 업계가 호응한 게 아니라, 두 달 넘게 이어지던 논의 위에 공개 제안이 얹힌 순서입니다.
회사들이 미리 실무 협의를 하는 건 이상한 일이 아닙니다. 그런데 순서를 이렇게 놓고 읽으면 그림이 좀 달라 보입니다. 며칠 사이에 제안과 동조가 연달아 나온 장면이 실은 준비된 논의를 바깥에 내보이는 창구였을 수도 있습니다. 밖에서 요구가 들어와서 생기는 기구와, 안에서 먼저 합의하고 나중에 바깥의 동의를 받는 기구는 이름이 같아도 다른 물건일 것 같습니다. 앞의 것은 바깥에서 요구한 조건을 맞추려고 만들어지고, 뒤의 것은 안에서 정한 조건을 바깥에 설명하려고 만들어집니다. 어느 쪽이든 문서는 비슷하게 나올 텐데, 그 문서 안의 판정을 누가 쓰느냐는 꽤 다를 것 같습니다. 이 논의에 안 들어간 회사들도 있고, 트럼프 행정부는 속도 조절 자체에 반대하고 있으니 업계 전체가 한목소리를 낸 것도 아닙니다.
순서에 이렇게 신경이 쓰이는 건 제 레포에서도 순서가 문제였기 때문인 것 같습니다. 바깥에서 보면 검사가 있고 그 뒤에 결과가 나오는 것처럼 보였지만, 실제로는 결과를 적는 일과 검사를 받는 일이 같은 손에서 같이 일어났습니다. 7월 실무그룹에서 실제로 무엇을 정했는지는 저는 모릅니다. 다만 만약 9월의 공개 제안이 이미 정해진 결론을 바깥에 알리는 일이었다면, 그 뒤에 이어진 동조 발언들은 검토라기보다 서명에 가까웠을 것 같습니다.
판정을 쓰는 손
"랩 내부에 독립 평가자를 둔다" 는 아모데이의 1단계는 얼핏 보면 제가 지운 게이트랑 닮았습니다. 검사받는 쪽 건물 안에 검사자가 들어와 앉는 거니까요. 그런데 제 기준으로는 이건 통과할 수도 있습니다. 판정을 쓰는 손이 평가자의 손이고, 그 평가자가 랩 바깥에서 오고, 돈줄이 따로라면, 그 판정은 검사받는 쪽이 쓴 문자열이 아닙니다. 어느 건물에 앉아 있느냐는 별로 상관이 없습니다.
그런데 바로 그 조건을 데이비드 색스가 13일에 X 에서 건드렸습니다. METR 이 앤트로픽의 투자자·직원과 얽혀 있는데 독립적인 척하지 말라는 취지였다고 합니다. 색스가 안전을 우습게 본다는 얘기가 아니라 돈줄을 문제 삼은 거라 저는 이 말이 꽤 아프게 들렸습니다. 평가기관이 독립적인지는 그 기관이 자기를 뭐라고 부르느냐보다 누구 돈으로 돌아가느냐에 달려 있다는 얘기니까요.
그러고 보면 아모데이와 색스는 서로 반대편에 선 것처럼 보이는데 같은 걸 보고 있습니다. 판정을 쓰는 손이 누구 손이냐. 아모데이는 그 손을 바깥에서 데려오자고 하고, 색스는 데려온 손이 이미 안쪽과 묶여 있다고 합니다. 찬성 반대로만 읽으면 이게 잘 안 보이는데, 저한테는 이 논쟁에서 이 부분이 제일 쓸모 있었습니다.
찬성 반대로 읽으면 결국 누가 이기느냐를 보게 되는데, 손을 보면 누가 이기든 남는 문제가 보입니다. 아모데이 안이 그대로 통과돼도 평가자의 돈줄 문제는 남고, 표준기구 얘기가 흐지부지돼도 각 회사 안에서 누가 판정을 쓰느냐는 문제는 그대로입니다. 어느 쪽으로 가든 그 질문은 따라옵니다.
제 레포 일로 바꿔 보면, 그때 게이트를 살리려면 방법이 하나 있긴 했습니다. 검사 브리프를 쓰는 에이전트를 본문 쓰는 에이전트와 떼어놓는 겁니다. 사실 구조는 이미 그렇게 돼 있었습니다. 그런데 둘 다 같은 모델이고 같은 시스템 프롬프트 계열을 쓰고 같은 세션에서 돌았습니다. 이름만 둘이지 판정을 쓰는 손은 하나였습니다. 본문 쓰는 쪽이 자주 하는 실수를 검사하는 쪽도 똑같이 못 보는 일이 생기는데, 같은 모델이면 그게 이상한 일이 아닙니다. 둘이 같은 데서 같은 걸 놓치니까, 검사가 두 번 일어나도 실제로는 한 번 본 것과 크게 다르지 않았습니다. 색스가 METR 을 두고 한 말이 저한테는 이 얘기로 들렸습니다.
만약 그때 검사 쪽만 다른 회사 모델로 바꿨다면 어땠을까 생각해 봅니다. 판정을 쓰는 손이 둘이 되긴 했을 겁니다. 그래도 그 브리프를 발행 경로에 넣는 코드는 여전히 문자열만 찾았을 테니, 손이 둘이 된 만큼 나아졌을지는 모르겠습니다. 독립성은 판정을 쓰는 쪽에서 한 번 필요하고, 그 판정을 읽고 뭔가를 결정하는 쪽에서 또 한 번 필요한 것 같은데, 저는 처음에 앞의 것만 생각했습니다.
돈줄 다음
돈줄이 완전히 따로인 평가기관을 만든다고 해도 물어볼 게 둘은 더 남아 있는 것 같습니다.
하나는 안 좋은 결과를 평가자가 스스로 낼 수 있느냐입니다. 평가 결과를 먼저 랩에 보내고 랩이 공개 여부를 정한다면, 평가자가 바깥 사람이어도 판정을 쓰는 손은 다시 안쪽으로 돌아옵니다. 누가 문장을 썼느냐보다 그 문장을 세상에 내보낼지를 누가 정하느냐가 진짜 권한인 것 같습니다. 제 레포에서도 브리프는 검사 에이전트가 썼지만 그걸 발행 경로에 넣을지는 제가 정했습니다. 그러니 그 판정은 어차피 제 판정이었습니다.
다른 하나는 그 결과가 실제로 뭔가를 멈출 수 있느냐입니다. 이건 저도 저한테 아직 답을 못 했습니다. 저는 게이트를 지우고 체크리스트로 바꿨으니 지금 이 레포에는 발행을 멈추는 문체 게이트가 없습니다. 검토는 남기고 멈추는 힘은 버렸습니다. 제 경우엔 그게 맞았다고 지금도 생각합니다. 최악이라 해봐야 어설픈 글이 하나 올라가는 거니까요.
다만 게이트를 지우면서 기대했던 건 제가 글을 다시 읽게 되는 거였는데, 정말 그렇게 됐는지는 장담을 못 하겠습니다. 장치가 없어진 만큼을 제 눈이 다 메우고 있다고 말하기엔, 제 눈도 그렇게 믿을 만한 물건은 아닙니다. 체크리스트는 남았지만 체크리스트도 결국 누가 열어봐야 의미가 있습니다.
프런티어 모델 평가에서 같은 선택을 하면 얘기가 달라집니다. 검토만 있고 멈추는 힘이 없으면 결과를 아무리 성실하게 적어도 출시 일정은 그대로 갑니다. 보고서는 쌓이고 배포는 예정대로 나갑니다. 그러면 그 기구는 검문소라기보다 기록 보관소에 가깝습니다. 기록 보관소도 쓸모가 있지만 그걸 검문소라고 부르면 곤란합니다. 이름을 잘못 붙이면 바깥에서는 누군가 막고 있다고 믿게 되고, 안에서는 적어두기만 하면 할 일을 다 했다고 느끼게 됩니다. 제가 문서에 "업로드 차단" 이라고 적어놓고 안심했던 것과 비슷한 일이 훨씬 큰 규모로 생기는 겁니다.
그래서 저는 권한 목록의 세 번째 줄을 기다리고 있습니다. 공동 표준과 모델 테스트까지는 문서 작업이고, 정말 궁금한 건 미국 정부와의 감독 조율이 어떤 모양이냐입니다. 정보를 나누는 데서 끝나는지, 어느 시점에 "이건 안 된다" 고 말할 수 있는 권한이 생기는지. 아직 보도만 봐서는 거기까지 나와 있지 않습니다.
만약 그 권한이 생긴다면 그다음에는 누가 그 권한을 쓰느냐가 남습니다. 멈추라는 말을 할 수 있어도, 그 말을 하는 순간 자기 회사 출시도 같이 멈추는 사람한테 그 권한이 있으면 쓰기가 쉽지 않을 겁니다. 권한이 있다는 것과 그 권한이 실제로 쓰인다는 것 사이에도 꽤 먼 거리가 있는 것 같습니다. 제 grep 도 막는 권한은 분명히 있었는데, 그 권한이 누구 말을 듣고 있었는지가 문제였습니다.
상장하면 안전해진다는 말
그다음 기사에서는 좀 놀랐습니다. 액시오스 보도로는 앤트로픽이 이 논란에도 올해 안에 IPO 를 그대로 밀고 갈 가능성이 높다고 합니다. 거기까지는 그럴 수 있다고 봤는데, 지난 48시간이 오히려 IPO 논거를 강화했다는 시각이 있다는 대목에서 멈췄습니다. 상장회사가 되면 투명성이 높아지니까 안전도 좋아진다는 논리였습니다.
이 문장을 읽는데 제가 지운 코드가 또 떠올랐습니다.
공시는 서류입니다. 서류가 늘어나는 것과 모델이 안전해지는 것 사이에 무슨 연결이 있는지 저는 잘 모르겠습니다. 상장사가 되면 분기마다 문서를 내고, 리스크 요인을 적고, 감사를 받습니다. 그건 문서가 있다는 걸 보증합니다. 제 grep 이 판정: 합격 이 파일에 있다는 걸 보증했던 것과 같은 종류의 보증입니다. 서류가 있다는 걸 품질로 읽는 겁니다. 투명성이 쓸모없다는 생각은 아닙니다. 다만 투명하게 공개되는 게 뭐냐에 따라 얘기가 많이 달라질 것 같은데, 그 부분은 이 논리에서 쏙 빠져 있었습니다.
감사를 받는 건 재무제표이지 모델의 안전이 아닙니다. 프런티어 모델이 어떤 위험한 능력을 갖췄는지 판정하는 회계 기준 같은 건 아직 없습니다. 그러니 안전에 관한 공시는 지금으로서는 회사가 스스로 쓰고 형식도 스스로 정하는 문서에 가깝습니다.
회계도 처음부터 기준이 있었던 건 아닐 텐데, 기준이 생기기 전의 재무제표는 아마 지금의 안전 공시와 비슷한 물건이었을 것 같습니다. 회사가 쓰고 싶은 대로 쓰고, 읽는 사람이 알아서 믿거나 안 믿는 문서요. 그렇다면 안전 쪽도 언젠가는 기준이 생길 수 있다는 얘기인데, 그게 몇 년이 걸릴지는 모르겠고 그동안에도 모델은 계속 나옵니다.
순서도 좀 이상합니다. 지금 논의 중인 표준기구가 하려는 일 중 하나가 바로 그 테스트와 감사 기준을 만드는 건데, 기준이 없어서 만들자고 하는 와중에 다른 쪽에서는 상장하면 투명해져서 안전해진다는 말이 벌써 쓰이고 있습니다. 채점 기준표를 만드는 회의를 하는 옆방에서 시험만 보면 실력이 는다고 말하는 것 같습니다.
만약 기준이 먼저 나오고 상장이 나중이라면 조금 다를 것 같습니다. 그러면 공시에 적힐 안전 항목이 적어도 표준기구가 정한 형식을 따르게 되고, 회사마다 제멋대로 쓰는 문서는 아니게 됩니다. 순서가 반대면 회사가 먼저 쓴 형식이 나중에 그대로 기준이 될 수도 있습니다. 처음 써둔 양식이 나중에 규칙이 되는 건 작은 레포에서도 자주 보는 일이라, 큰 쪽이라고 다를 것 같지는 않습니다.
오픈AI 가 올해 안에 AGI 를 만든다고 인터뷰에서 말했을 때도 제가 걸린 건 시점이 아니라 정의였습니다. 뭘 달성했다고 말할 때 그 기준을 누가 쥐고 있느냐에서 저는 매번 걸립니다.
검사했다고 말할 수 있다는 것
색스는 이런 말도 했습니다. 제품이 실제로 피해를 주는 사이버공격을 가능하게 하면 엄청난 제품 책임을 지게 된다는 얘기였고, 저는 속도 조절을 말하는 동기가 안전이 아니라 책임을 피하려는 걸 수도 있다는 뜻으로 읽었습니다. 앤트로픽 안에서 무슨 얘기가 오갔는지는 저야 알 수 없습니다. 그런데 이 말을 거꾸로 놓고 보면 제가 아는 게 하나 있습니다.
게이트가 있으면 "우리는 검사했다" 고 말할 수 있습니다. 실제로 검사를 안 해도 그렇게 말할 수 있습니다. 자기가 통행증을 발급하는 게이트가 주는 진짜 쓸모는 그쪽인 것 같습니다.
제가 그랬습니다. 그 grep 을 지울 때 뭐가 제일 아까웠는지 나중에 곰곰이 생각해 봤는데, 막아주던 기능이 아니었습니다. 문서에 "불합격 글은 업로드가 차단된다" 고 적을 수 있다는 게 아까웠습니다. 그 문장이 있으면 파이프라인 전체가 관리되고 있는 것처럼 보였거든요. 기능이 아니라 문장을 잃는 게 아까웠던 겁니다. 누가 이 레포를 들여다볼 일도 없는데 저는 그 문장이 있는 문서를 보면서 안심하고 있었습니다. 남한테 보여주려는 문장이 아니라 저 스스로에게 보여주는 문장이었는데, 그게 오히려 더 떼어내기 어려웠습니다.
그걸 인정하는 데 며칠 걸렸습니다. 그 며칠 동안 게이트를 살릴 방법을 찾았는데, 지금 보면 게이트가 아니라 그 문장을 지킬 방법을 찾고 있었습니다.
그 문장을 지키고 싶었던 마음이 어디서 왔는지도 가끔 생각합니다. 혼자 쓰는 파이프라인이라 아무도 검사하지 않는데, 그래서 오히려 뭔가를 검사하고 있다는 문장이 필요했던 것 같습니다. 회사라면 그 문장을 읽을 사람이 투자자이고 규제기관이고 사용자일 테니, 그 문장을 지키고 싶은 마음은 저보다 훨씬 클 겁니다. 그 마음이 클수록 문장과 실제 검사 사이가 벌어져도 알아차리기가 더 어려울 것 같습니다.
감시 훅을 잔뜩 걸어두고 넉 달 만에 열어봤더니 아무것도 안 보고 있었던 적도 있습니다. 그때도 그 훅들이 실제로 한 일은 저를 안심시킨 것뿐이었습니다. 걸어놓는 것과 보고 있는 건 다른 일인데, 기록에는 걸어놓은 쪽만 남습니다.
그래서 이번 표준기구 얘기를 보면서도 권한 목록보다 결과를 누가 적느냐가 계속 눈에 들어옵니다. 공동 표준을 만들고 프런티어 모델을 테스트한다는 건 다 좋은 말인데, 그 테스트 결과를 적는 손이 어디 소속인지가 안 나오면 그냥 목록입니다.
카르텔이라는 말
색스는 반독점 쪽도 같이 때렸습니다. 카르텔을 만들려고 반독점법을 멈춰야 하는 척하지 말라는 취지였습니다. 코히어의 에이든 고메스도 이게 대형 기업들의 카르텔이 될 수 있다고 했습니다.
이 부분은 저는 생각이 좀 다릅니다. 협력 자체가 문제라고는 안 봅니다. 표준을 같이 만드는 것과 그 표준을 통과했는지를 스스로 적는 건 다른 일입니다. 앞의 건 반독점 문제이고 뒤의 건 검증 문제인데, 둘이 섞이면 둘 다 흐려집니다.
표준을 같이 만드는 건 오히려 필요한 일일 수도 있습니다. 회사마다 자기 기준으로 안전하다고 말하면 그 말들끼리 비교할 방법이 없습니다. 같은 기준표가 있어야 누가 어디서 빠졌는지가 보입니다. 제가 마음에 걸리는 건 그 기준표에 점수를 적는 사람이 누구냐인데, 그건 기준표를 몇 회사가 같이 만들었느냐와는 별로 상관이 없습니다.
실제로 흐려지는 게 보입니다. 표준기구를 카르텔이라고 부르면 방어하는 쪽은 "안전을 위한 협력을 왜 막느냐" 고만 답하면 됩니다. 그러면 판정을 누가 쓰느냐는 질문은 대화에서 빠져버립니다. 카르텔이라는 단어 하나가 얘기를 산업 구조 쪽으로 끌고 갑니다. 그 방향의 논쟁도 필요하긴 할 텐데, 그쪽으로 한참 가고 나면 표준기구가 생기든 안 생기든 판정 줄은 여전히 검사받는 쪽이 쓰고 있을 수도 있습니다. 저는 그게 제일 걱정되는 그림입니다.
재밌는 건 색스 본인도 둘을 나눠서 말한 대목이 있다는 겁니다. 기업들이 안전을 위해 협력하는 데 꼭 반독점법 면제가 필요한 건 아니라고 했는데, 이 말은 저도 맞다고 봅니다. 협력하려면 면제가 필요하다는 말이 나오는 순간, 그 협력 안에 경쟁을 제한하는 뭔가가 들어 있다고 스스로 말하는 것에 가까워집니다.
젠슨 황은 AI 종말론을 헛소리라고 일축했고, 아모데이 제안에는 아직 입장을 안 냈습니다. 종말론이 과장이냐는 것도 판정을 누가 쓰느냐와는 또 다른 질문이라, 이것까지 한 줄에 놓으면 다시 흐려질 것 같습니다.
정부 규제가 답이라는 쪽으로 가고 싶은 마음도 드는데, 규제기관이 프런티어 모델을 평가할 역량이 있는지, 그 평가가 또 다른 서류 확인이 되지는 않을지 저는 모릅니다. 트럼프 행정부가 속도 조절에 반대하는 게 구조에 대한 반대인지 속도에 대한 반대인지도 기사만으로는 잘 구분이 안 됐습니다.
제가 아는 건 블로그 발행 파이프라인 하나뿐인데, 자기가 쓴 문자열을 자기 검문소로 쓰는 구조는 크기와 상관없이 비슷하게 실패할 것 같습니다. 제 경우엔 나쁜 글이 통과하고 좋은 글이 막혔습니다. 큰 쪽에서 뭐가 통과하고 뭐가 막힐지는 모르겠는데, 생각했던 것과 반대 방향으로 틀리지 않을까 하는 짐작은 듭니다.
반대 방향으로 틀린다는 게 구체적으로 뭘지 생각해 보면, 성실하게 보고서를 쓰는 회사가 더 손해를 보는 그림일 것 같습니다. 위험한 결과를 정직하게 적은 쪽은 출시가 늦어지고, 적당히 적은 쪽은 표준을 통과했다는 문장을 먼저 얻습니다. 제 레포에서 브리프에 FAIL 이라는 글자를 한 번이라도 적은 글이 막혔던 것과 모양이 닮았습니다. 그냥 짐작이고, 그렇게는 안 되기를 바랍니다.
한동안 LLM 을 탓하다가 문제가 대개 그 바깥 구조에 있었다는 걸 알게 된 적이 있는데, 이번 뉴스도 비슷한 층의 얘기로 보입니다. 모델이 얼마나 위험하냐를 두고 다투는 것처럼 보이지만, 저한테는 그 위험을 판정하는 절차를 누가 쥐느냐가 더 크게 보입니다. 모델 쪽 질문은 시간이 지나면 어떻게든 답이 나올 텐데, 절차는 한번 굳으면 오래 갑니다. 제 레포에서도 근거 없는 grep 한 줄이 두 달 반을 아무도 모르게 버텼는데, 여러 회사와 정부가 같이 만든 절차라면 바꾸는 데 얼마나 걸릴지 감이 잘 안 옵니다.
표준기구가 생기면 첫 보고서를 열어볼 생각입니다. 판정 줄 옆에 근거가 붙어 있는지, 판정만 있는지부터 보게 될 것 같습니다.
댓글
댓글 쓰기