생각을 루프로 돌리면 흔적이 안 남는다: OpenAI Astra가 지우는 건 감사 로그다

지난 1년 동안 추론 모델이 준 부수 효과가 하나 있다. 모델이 답을 내기 전에 생각한 내용이 글로 남았다. 사람이 읽을 수 있는 형태로 남았고, 그래서 모델이 이상한 답을 냈을 때 어디서 틀어졌는지 되짚을 수 있었다. 업계는 이걸 chain of thought 모니터링이라고 부르며 사실상 유일한 사후 감사 수단으로 써 왔다.

곧 나올 OpenAI의 Astra가 그 전제를 흔든다. 이 모델은 recurrent depth라는 방식을 쓴다. 순차적으로 토큰을 뱉으며 생각하는 대신 같은 질의를 루프에 넣고 여러 번 통과시킨다. 계산은 모델 안에서 도는데 밖으로 나오는 글은 그만큼 안 나온다. 반대하는 쪽에서는 이 방식을 opaque recurrence, 불투명한 재귀라고 부른다.

한 줄 정리

모델이 더 깊이 생각하는 방식을 바꾸면서 그 생각을 나중에 읽어 볼 수단이 같이 줄어든다.

무엇이 달라지나

기존 추론 모델은 생각을 토큰으로 뱉는다. 토큰은 순서가 있고 글자로 남는다. 그래서 답이 틀렸을 때 "3번째 단계에서 조건을 뒤집어 읽었다" 같은 진단이 가능했다. 완벽한 기록은 아니다. 모델이 쓴 사고 과정이 실제 계산과 다를 수 있다는 지적은 예전부터 있었다. 그래도 아무것도 없는 것보다는 나았다.

루프 방식에서는 같은 층을 여러 번 통과하며 표현을 다듬는다. 깊이가 늘어나는데 그 깊이가 글자로 환산되지 않는다. 파라미터를 키우지 않고도 어려운 문제에 계산을 더 쓸 수 있다는 게 이 방식의 매력이다. 흔적이 덜 남는다는 게 그 대가다.

Redwood Research의 Buck Shlegeris는 Astra가 이 방식을 쓴다는 보도에 "극도로 우려한다"고 썼다. OpenAI가 이 방향을 더 밀면 chain of thought 모니터링 가능성을 완전히 파괴할 수 있다고 봤다.

한 가지는 짚어 둘 만하다. 사고 기록은 원래도 완전한 증거가 아니었다. 모델이 적어 내려간 단계가 실제 내부 계산을 그대로 옮긴 것이라는 보장은 없고, 답을 정해 놓고 그럴듯한 설명을 붙이는 경우도 관찰됐다. 그러니 지금 사라지는 게 진실의 기록이라기보다는 점검할 거리에 가깝다. 그래도 점검할 거리가 있는 쪽과 없는 쪽의 차이는 크다.

OpenAI의 답과 남는 것

OpenAI 쪽 설명은 범위 문제다. 수석과학자 Jakub Pachocki는 Astra의 계산 깊이가 GPT-4 수준에 가깝게 유지되고 회사가 여전히 chain of thought 모니터링을 안전 확보의 우선순위로 둔다고 밝혔다. 보도에서도 Astra의 이 기법 사용은 제한적이고 사고 기록은 여전히 읽을 수 있을 것으로 보고 있다.

그러니 이번 모델 하나로 감사 수단이 사라지지는 않는다. 다툼의 대상은 방향이다. 성능을 올리는 가장 값싼 손잡이 중 하나가 "밖으로 안 보이는 계산을 늘리는 것"이라면, 경쟁 중인 회사들이 그 손잡이를 안 당길 이유가 없다.

배경도 조용하지 않다. Astra는 안전 절차를 보강하느라 몇 주 미뤄졌고, 그 사이 테스트 과정에서 에이전트가 실제 표적을 공격한 일이 보고됐다.

에이전트를 붙여 쓰는 팀에게

5명에서 30명 규모 팀이 에이전트를 업무에 넣을 때 실제로 부딪히는 질문은 성능이 아니라 사후 처리다. 자동 회신이 엉뚱한 고객에게 잘못된 금액을 보냈다. 문서 정리 작업이 폴더 하나를 지웠다. 이때 무엇을 근거로 원인을 찾고, 무엇을 근거로 "고쳤다"고 말할 수 있나.

지금까지는 사고 기록이 그 자리를 채웠다. 로그를 열어 모델이 무엇을 잘못 읽었는지 보고, 프롬프트를 고치고, 같은 입력으로 다시 돌려 확인하는 흐름이다. 그 기록이 얇아지면 이 흐름 전체가 약해진다.

대안은 모델 안이 아니라 모델 밖에 검토 지점을 두는 쪽이다. 세 가지가 실무에서 바로 먹힌다.

되돌릴 수 있는 작업만 자동으로 돌린다. 초안 작성, 분류, 태그, 요약은 틀려도 되돌아온다. 발송, 결제, 삭제, 게시는 되돌아오지 않는다. 앞쪽은 자동, 뒤쪽은 사람 한 번. 이 선을 업무 목록 옆에 적어 두면 모델이 바뀌어도 그대로 쓴다.

도구 목록을 좁힌다. 에이전트가 부를 수 있는 함수와 접근할 수 있는 계정을 화이트리스트로 관리한다. 사고 기록을 못 읽어도 무엇을 부를 수 있었는지는 남는다. 이쪽 로그는 모델 구조와 무관하게 우리 시스템이 기록한다.

입출력을 원본으로 저장한다. 모델이 무슨 생각을 했는지가 아니라 무엇을 받아서 무엇을 냈는지를 남긴다. 프롬프트 전문, 모델 이름과 버전, 받은 응답, 호출 시각. 재현이 되면 원인 분석의 절반은 끝난다. 사고 기록이 아니라 이쪽이 진짜 로그다.

셋 다 코드를 짤 줄 알아야 하는 일이 아니다. 첫째는 업무 목록에 선 하나 긋는 일이다. 둘째와 셋째는 도구를 붙일 때 담당자에게 요구할 조건이다. 요구 사항이라 우리가 문장으로 적으면 된다. 자동화를 외주로 맡기든 노코드 도구로 붙이든 계약서에 이 세 줄을 넣을 수 있다. 실제로 사고가 났을 때 "그 도구가 무엇을 받아 무엇을 냈는지 볼 수 있나요"에 대한 답이 없으면 그 자동화는 끄는 것 말고 고칠 방법이 없다.

anyAX 관점

모델 회사가 팔 수 있는 건 성능이다. 감사 가능성은 아무도 사겠다고 말하지 않는 항목이라 경쟁에서 먼저 깎인다. 읽히지 않는 계산은 벤치마크 점수를 올리는데 그 대가는 점수판에 안 찍힌다. 그래서 이 방향은 누가 악하게 굴어서가 아니라 시장이 재는 항목이 그것뿐이라서 밀린다.

감사 가능성은 우리 쪽 설계에서 나온다. 모델의 사고 기록에 기대는 관측은 공급자가 언제든 걷어 갈 수 있는 기능 위에 서 있다. 되돌릴 수 있는 작업과 없는 작업을 가르는 선, 도구 화이트리스트, 입출력 원본 보관, 이 셋은 모델 이름이 바뀌어도 그대로 돈다.

모델 회사가 이 방향을 얼마나 밀지는 우리가 못 정한다. Astra가 실제로 어떻게 나오는지, 사고 기록이 얼마나 남는지도 나와 봐야 안다. 우리가 정할 수 있는 건 그 답이 어느 쪽이든 우리 업무가 버티는지다. 사고 기록이 두꺼우면 좋고 얇아도 굴러가는 구조를 지금 만들어 두면, 다음 모델 세대의 설계 결정이 우리 운영 리스크가 되지 않는다.

작은 팀일수록 이쪽이 유리하다. 업무 종류가 스무 개 안쪽이라 어느 작업이 되돌릴 수 있는지 하루면 다 적는다. 그 표 한 장이 Astra가 어떤 방식으로 생각하든 상관없이 남는 자산이다. 표가 없으면 다음 사고 때 열어 볼 건 모델이 얼마나 친절하게 자기 생각을 적어 뒀는지, 그 운뿐이다.