bozo bit의 가치는 어떤 사람들이 안정적인 역정보의 출처라는 데 있음
그런 사람들은 습관적으로 반복해서 틀린 결론에 도달하고, 아주 직접적으로 쓰인 문서도 오해하며, 목표를 해결하지 못하면서 새 문제를 만드는 설계를 내놓음
누군가에게 bozo bit를 켠다는 건, 그 사람의 소통에서 지식을 얻으려 드는 시간이 낭비라고 판단했다는 뜻임
이 글은 bozo bit를, 특정 문제가 일어날 수 없다고 굳게 믿고 거기서부터 거꾸로 이유를 만들어내는 다른 현상과 섞고 있음
들어본 용어로는 사후 정당화이고, 수세기 혹은 수천 년 동안 피해야 한다는 논의가 많았음
글의 예시인 운영 데이터베이스에 LLM 관리자 권한을 준 회사로 돌아가면, “그건 나한테는 X 때문에 안 일어난다”는 반응은 X가 “운영 데이터베이스 관리자 권한을 LLM에 주는 건 너무 기괴하고 미친 듯이 위험해서 애초에 하지 않는다”에 가깝다면 정당함
위험한 걸 먹고 참사가 나는 사람들과 비슷함. 누군가 민달팽이를 먹고 뇌 기생충으로 죽었다는 뉴스를 읽으면서, 나는 그 특정 원인으로 죽지 않을 거라고 확신할 수 있음
글쓴이는 그게 죽은 사람보다 내가 더 낫거나 똑똑하다고 믿어서라고 상상하지만, 실제 사고 과정은 “즙 많은 민달팽이가 가득한 무인도에서 굶고 있어도 자발적으로 민달팽이를 먹지는 않을 거라고 100% 확신하므로, 민달팽이 매개 기생충은 내 위험 모델에 없다”에 가까움
“그들이 알았어야 했다”는 말이 incoherent하다는 부분도 동의하기 어려움. 사람들은 모르는 것 때문에 늘 비난받고, 그게 어른으로 산다는 것의 일부임
3살 아이가 민달팽이를 먹었다면 탓하지 않겠지만, 30살 동료가 민달팽이를 먹었다면 당연히 탓할 것임. 너무 명백하게 어리석은 행동은 한 사람을 비난해도 됨
“무언가를 모르는 것” 때문에 어떻게 비난할 수 있느냐는 말에는 이미 고의적 무지라는 용어가 있음
이 글이 전에는 생각해보지 못한 좋은 지점을 제시했다고 보지만, 나에게는 뚜렷한 결함도 몇 가지 있었고 그게 첫 번째임
두 번째는 미국인들 이야기를 읽으며 “그래도 그들의 차이 두기를 통한 거리두기(distancing through differencing)가, 내가 AI 운영 삭제 사고를 무시할 때 하는 것과 정말 같은가?”라고 스스로 묻게 됐다는 것임
즉, 다른 공장에서 위험이 어떻게 발생했는지 전혀 모르면서 자기들에게는 닿지 않을 거라고 치부했다면 정당하지 않음
하지만 관리자가 새롭고 실험적이며 비결정적인 휴머노이드 로봇을 공장 현장에 들여와, 숙련 노동자들이 더 빨리 일하도록 자유롭게 돕게 했다는 말을 들었다면, 그들의 무시는 같은 빛으로 볼 수 없음
그래도 결론은 받아들임. 무모함은 이분법이 아니기 때문임
다음에 터무니없는 이야기를 들으면, “그들이 한 것만큼 부주의하진 않더라도, 내가 하는 일 중 더 조심해서 안전장치를 둘 만한 건 무엇인가?” 하고 잠깐 멈춰 생각하게 될 듯함
3살 아이가 왜 민달팽이를 먹었는지는 묻지 않을 것임
하지만 30살 동료가 민달팽이를 먹었다면, 그 상황에 이르게 된 경위를 철저히 조사할 것임
그 사람을 “탓하고” 싶어진다면, 먼저 왜 우리가 민달팽이를 먹는 사람을 채용했는지, 그리고 지금도 계속 그런지 물어볼 듯함
이 글에서 얻은 핵심은 글쓴이가 bozo bit가 무엇인지 모른다는 것임
몇 가지 타당한 지점이 있음
“이 반응이 왜 역효과인지 말하고 싶다. 또 bozo bit 켜기와 친척뻘인 이 현상의 기술적 용어를 짚고 싶다. 차이 두기를 통한 거리두기(distancing through differencing)라고 한다”는 부분에서, 이 반응은 생산적이면서도 역효과적임
이미 감당 못 할 만큼 많은 사건이 쏟아지는 세상에서 모든 입력을 평가하지 않아도 된다는 건 엄청난 최적화라서 생산적임
동시에 글에서 든 이유들 때문에 역효과적이기도 함
어떤 걸 진지하게 받아들이고 주의를 기울여야 하는지 아는 게 진짜 요령임. 그 요령을 익히고 나면 다시 알려주겠음
누군가가 AI에 운영 환경 직접 접근권을 줬다는 일에서 내가 배워야 할 게 뭔가?
LLM 사건을 다소 관대하게 해석하면, 운영 접근은 접근 제어가 되어야 하고, 파괴적인 작업에는 2인 승인이 필요하다는 교훈으로 볼 수 있음
한때 빠르게 성장하던 회사에서 일했는데, 엔지니어링 관행 상당수가 1000명 규모의 다국적 기업이라기보다 차고 스타트업에 가까웠음
당시 세 가지가 참이었음. 첫째, 서비스 배포는 노트북의 Git 체크아웃 디렉터리로 cd한 뒤 <tool> deploy <service-name>을 실행하는 방식이었고, 현재 체크아웃된 Git 커밋이 그대로 배포됐음
둘째, 동료를 신뢰한다는 문화 때문에 배포 시스템의 접근 제어가 최소화되어 있었음. 배포 허용자 목록이 있었고, 거기에 들어 있으면 어떤 서비스든 배포할 수 있었음
셋째, 주 Git 저장소가 크고 사무실 와이파이가 혼잡해 클론에 오래 걸렸음. 신규 입사자가 더 빨리 시작하도록 노트북 프로비저닝 이미지에 주 저장소의 Git 체크아웃이 포함돼 있었음
그러던 어느 날 데이터베이스 팀에 새 인턴이 들어왔고, Database Team 101 위키 튜토리얼을 따라 하다가 배포 권한이 동작하는지 확인하라는 추천 명령 <tool> deploy --prod <database>를 실행함
알고 보니 노트북 프로비저닝 이미지가 오래된 상태였고, 그 인턴은 아직 git pull origin master를 하는 온보딩 수업을 듣기 전이었음
“LLM이 운영 환경을 망가뜨린” 이야기와 “인턴이 운영 환경을 망가뜨린” 이야기는 비슷하지만, 후자가 더 배우기 쉬움. 개별 실수들이 더 작기 때문임
장애 분석 관점에서 보면, bozo bit를 켠 뒤 학습을 멈추는 것은 전체 장애 트리를 봐야 하는 상황에서 단일 기여 요인, 즉 “인적 오류!”에서 멈추는 형태임
제시된 예시에서는 장애 트리의 “LLM 루프에 운영 접근권을 줬다”는 노드가 독자의 “멍청이는 무시” 휴리스틱을 발동시킴
하지만 형제 노드인 “시스템이 API를 통한 무확인 삭제를 허용했다”는 귀중한 교훈이고, 처음 눈에 띄는 노드에서 멈추면 놓칠 수 있음
또한 장애 트리에는 그 위험한 작업이 GUI에서는 제거됐는데 왜 API에는 남아 있었는지, 그리고 LLM이 왜 운영 접근권을 얻게 됐는지를 파고드는 자식 노드도 포함되어야 함
한편으로는, bozo 같은 곳에서 나온 보고서에서 합리적인 장애 트리를 복원할 가능성이 더 낮다고 봐야 하는지 질문할 수 있음
다른 한편으로는, 진짜 질문은 bozo 조건에서 더 밝게 빛나는 노드가 그 안에 들어 있느냐일 수도 있음
그 노드들이 잘못 식별되고 잘못 연결됐는지는 별로 중요하지 않을 수 있음. 결국 내게 필요한 건 그들의 과거 실패를 위한 장애 트리가 아니라, 내 미래 실패를 막기 위해 내가 장애 트리에서 무엇을 빠뜨렸는지 확인하는 것이기 때문임
이 글은 제시한 핵심 예시의 bozo에게 bozo bit를 켠 것이 왜 틀렸는지 설명하는 부분을 눈에 띄게 건너뜀
논문 사례로 넘어가고, 자기 글의 핵심 예시는 다루지 않음
그래서 글쓴이가 다른 bozo를 슬쩍 통과시키려는 것처럼 보임
Lobste.rs 의견들
bozo bit의 가치는 어떤 사람들이 안정적인 역정보의 출처라는 데 있음
그런 사람들은 습관적으로 반복해서 틀린 결론에 도달하고, 아주 직접적으로 쓰인 문서도 오해하며, 목표를 해결하지 못하면서 새 문제를 만드는 설계를 내놓음
누군가에게 bozo bit를 켠다는 건, 그 사람의 소통에서 지식을 얻으려 드는 시간이 낭비라고 판단했다는 뜻임
이 글은 bozo bit를, 특정 문제가 일어날 수 없다고 굳게 믿고 거기서부터 거꾸로 이유를 만들어내는 다른 현상과 섞고 있음
들어본 용어로는 사후 정당화이고, 수세기 혹은 수천 년 동안 피해야 한다는 논의가 많았음
글의 예시인 운영 데이터베이스에 LLM 관리자 권한을 준 회사로 돌아가면, “그건 나한테는 X 때문에 안 일어난다”는 반응은 X가 “운영 데이터베이스 관리자 권한을 LLM에 주는 건 너무 기괴하고 미친 듯이 위험해서 애초에 하지 않는다”에 가깝다면 정당함
위험한 걸 먹고 참사가 나는 사람들과 비슷함. 누군가 민달팽이를 먹고 뇌 기생충으로 죽었다는 뉴스를 읽으면서, 나는 그 특정 원인으로 죽지 않을 거라고 확신할 수 있음
글쓴이는 그게 죽은 사람보다 내가 더 낫거나 똑똑하다고 믿어서라고 상상하지만, 실제 사고 과정은 “즙 많은 민달팽이가 가득한 무인도에서 굶고 있어도 자발적으로 민달팽이를 먹지는 않을 거라고 100% 확신하므로, 민달팽이 매개 기생충은 내 위험 모델에 없다”에 가까움
“그들이 알았어야 했다”는 말이 incoherent하다는 부분도 동의하기 어려움. 사람들은 모르는 것 때문에 늘 비난받고, 그게 어른으로 산다는 것의 일부임
3살 아이가 민달팽이를 먹었다면 탓하지 않겠지만, 30살 동료가 민달팽이를 먹었다면 당연히 탓할 것임. 너무 명백하게 어리석은 행동은 한 사람을 비난해도 됨
이 글이 전에는 생각해보지 못한 좋은 지점을 제시했다고 보지만, 나에게는 뚜렷한 결함도 몇 가지 있었고 그게 첫 번째임
두 번째는 미국인들 이야기를 읽으며 “그래도 그들의 차이 두기를 통한 거리두기(distancing through differencing)가, 내가 AI 운영 삭제 사고를 무시할 때 하는 것과 정말 같은가?”라고 스스로 묻게 됐다는 것임
즉, 다른 공장에서 위험이 어떻게 발생했는지 전혀 모르면서 자기들에게는 닿지 않을 거라고 치부했다면 정당하지 않음
하지만 관리자가 새롭고 실험적이며 비결정적인 휴머노이드 로봇을 공장 현장에 들여와, 숙련 노동자들이 더 빨리 일하도록 자유롭게 돕게 했다는 말을 들었다면, 그들의 무시는 같은 빛으로 볼 수 없음
그래도 결론은 받아들임. 무모함은 이분법이 아니기 때문임
다음에 터무니없는 이야기를 들으면, “그들이 한 것만큼 부주의하진 않더라도, 내가 하는 일 중 더 조심해서 안전장치를 둘 만한 건 무엇인가?” 하고 잠깐 멈춰 생각하게 될 듯함
하지만 30살 동료가 민달팽이를 먹었다면, 그 상황에 이르게 된 경위를 철저히 조사할 것임
그 사람을 “탓하고” 싶어진다면, 먼저 왜 우리가 민달팽이를 먹는 사람을 채용했는지, 그리고 지금도 계속 그런지 물어볼 듯함
몇 가지 타당한 지점이 있음
“이 반응이 왜 역효과인지 말하고 싶다. 또 bozo bit 켜기와 친척뻘인 이 현상의 기술적 용어를 짚고 싶다. 차이 두기를 통한 거리두기(distancing through differencing)라고 한다”는 부분에서, 이 반응은 생산적이면서도 역효과적임
이미 감당 못 할 만큼 많은 사건이 쏟아지는 세상에서 모든 입력을 평가하지 않아도 된다는 건 엄청난 최적화라서 생산적임
동시에 글에서 든 이유들 때문에 역효과적이기도 함
어떤 걸 진지하게 받아들이고 주의를 기울여야 하는지 아는 게 진짜 요령임. 그 요령을 익히고 나면 다시 알려주겠음
누군가가 AI에 운영 환경 직접 접근권을 줬다는 일에서 내가 배워야 할 게 뭔가?
한때 빠르게 성장하던 회사에서 일했는데, 엔지니어링 관행 상당수가 1000명 규모의 다국적 기업이라기보다 차고 스타트업에 가까웠음
당시 세 가지가 참이었음. 첫째, 서비스 배포는 노트북의 Git 체크아웃 디렉터리로
cd한 뒤<tool> deploy <service-name>을 실행하는 방식이었고, 현재 체크아웃된 Git 커밋이 그대로 배포됐음둘째, 동료를 신뢰한다는 문화 때문에 배포 시스템의 접근 제어가 최소화되어 있었음. 배포 허용자 목록이 있었고, 거기에 들어 있으면 어떤 서비스든 배포할 수 있었음
셋째, 주 Git 저장소가 크고 사무실 와이파이가 혼잡해 클론에 오래 걸렸음. 신규 입사자가 더 빨리 시작하도록 노트북 프로비저닝 이미지에 주 저장소의 Git 체크아웃이 포함돼 있었음
그러던 어느 날 데이터베이스 팀에 새 인턴이 들어왔고, Database Team 101 위키 튜토리얼을 따라 하다가 배포 권한이 동작하는지 확인하라는 추천 명령
<tool> deploy --prod <database>를 실행함알고 보니 노트북 프로비저닝 이미지가 오래된 상태였고, 그 인턴은 아직
git pull origin master를 하는 온보딩 수업을 듣기 전이었음“LLM이 운영 환경을 망가뜨린” 이야기와 “인턴이 운영 환경을 망가뜨린” 이야기는 비슷하지만, 후자가 더 배우기 쉬움. 개별 실수들이 더 작기 때문임
장애 분석 관점에서 보면, bozo bit를 켠 뒤 학습을 멈추는 것은 전체 장애 트리를 봐야 하는 상황에서 단일 기여 요인, 즉 “인적 오류!”에서 멈추는 형태임
제시된 예시에서는 장애 트리의 “LLM 루프에 운영 접근권을 줬다”는 노드가 독자의 “멍청이는 무시” 휴리스틱을 발동시킴
하지만 형제 노드인 “시스템이 API를 통한 무확인 삭제를 허용했다”는 귀중한 교훈이고, 처음 눈에 띄는 노드에서 멈추면 놓칠 수 있음
또한 장애 트리에는 그 위험한 작업이 GUI에서는 제거됐는데 왜 API에는 남아 있었는지, 그리고 LLM이 왜 운영 접근권을 얻게 됐는지를 파고드는 자식 노드도 포함되어야 함
다른 한편으로는, 진짜 질문은 bozo 조건에서 더 밝게 빛나는 노드가 그 안에 들어 있느냐일 수도 있음
그 노드들이 잘못 식별되고 잘못 연결됐는지는 별로 중요하지 않을 수 있음. 결국 내게 필요한 건 그들의 과거 실패를 위한 장애 트리가 아니라, 내 미래 실패를 막기 위해 내가 장애 트리에서 무엇을 빠뜨렸는지 확인하는 것이기 때문임
이 글은 제시한 핵심 예시의 bozo에게 bozo bit를 켠 것이 왜 틀렸는지 설명하는 부분을 눈에 띄게 건너뜀
논문 사례로 넘어가고, 자기 글의 핵심 예시는 다루지 않음
그래서 글쓴이가 다른 bozo를 슬쩍 통과시키려는 것처럼 보임
배운 건 있음: AI 도구를 쓰지 말 것