Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 디자인 리뷰나 회의실에서 발생하는 집단 순응(group conformity) 현상을 관찰하며 시작합니다. 필자는 AI 모델이 인간의 합의적인 데이터 패턴을 학습하는 과정에 주목하고, '상호 합의를 인위적으로 만들지 말라'는 지침을 통해 모델들이 외교적 분열보다 가치 있는 의견 불일치를 생성할 수 있음을 실험으로 보여줍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기사람 다섯 명을 방에 넣고 무언가에서 구멍을 찾도록 요청하면, 대부분의 경우 그들은 서로 동의하게 됩니다... 그리고 그것이 옳기 때문이 아닙니다. 단지 사람들이 방에서 하는 행동일 뿐입니다.
저는 디자인 리뷰에서 셀 수 없을 만큼 많이 이런 광경을 목격했고, 저 자신도 여러 번 유발해 왔습니다. 보통은 제가 가장 선임자의 목소리를 내면서 이미 마음속으로 결론을 내려놓았기 때문이죠. 일단 방이 어떤 형태에 합의하면, 그것에 반대하는 것은 무언가를 비용으로 치르게 하는데, 그 비용은 기술적인 것이 아니라 사회적입니다 (회의록에는 절대 남지 않지만, 당신은 느낍니다).
저는 성인이 된 내내 심리학에 대해 어느 정도 관심 있는 아마추어로서 애정을 가져왔습니다. 저는 그것을 제대로 공부할 만큼 똑똑하지 않았고 (제 딸이 하였고, 결국 그 일을 하게 된 사람이죠).
저에게 와닿았던 것은 집단 순응(group conformity)입니다. 주로 제가 앉아 있던 거의 모든 디자인 리뷰에서 이 현상을 관찰할 수 있기 때문이죠. 사람들은 방이 기대하는 방향으로 표류합니다. 진정한 반대는 질문으로 완화되고, 어떤 요점은 세 사람이 이미 다음 단계로 넘어갔기 때문에 놓아지는데, 마지막까지 그것을 붙잡고 있는 것은 어색하게 느껴집니다.
그래서 저는 계속해서 생각합니다... 모델이 왜 다를 수 없을까?
그들은 인간의 산출물, 방대한 양의 데이터를 학습합니다. 여기에는 모든 정중한 회의록, 모든 외교적인 코드 리뷰, 그리고 평화를 유지하기 위해 누군가가 물러난 포럼 스레드가 포함됩니다. 그리고 그 밑바탕에는 모두 예측 엔진(prediction engines)이며, 입력이 원하는 것처럼 보이는 것을 만들어내려고 노력합니다. 때로는 입력이 사람이고 때로는 다른 모델이지만, 어느 쪽이든 합의로 향하는 끌림은 우리 자신이 거기에 넣었기 때문에 존재합니다.
그것은 제가 아첨(sycophancy)에 대해 생각하는 방식을 바꾸었습니다. 보통 그것은 결함으로 묘사되며, 스며들어와서 학습을 통해 제거해야 할 무언가로 여겨지지만, 저는 그것이 오히려 훈련 데이터가 드러나는 것, 즉 우리 자신이 회의실에서 하는 행동을 반영하는 것이라고 의심합니다.
제가 얼마 전에 afmpeg에 대한 아키텍처 교차 검토(architecture cross-review)를 진행한 적이 있는데, 원본 자료가 필요하시면 이 보고서(write-up is public)를 참고하실 수 있습니다. 서로 다른 공급업체의 두 모델이 같은 아키텍처를 독립적으로 검토했고, 서로의 작업은 전혀 보지 못했습니다. 지금까지는 평범한 수준이었습니다.
그런 다음 저는 각 모델에게 상대방의 보고서와 함께 두 모델이 의견을 달리했던 네 가지 특정 지점을 보여주면서 다음과 같이 표시하도록 요청했습니다: 입장을 고수할 것인지, 아니면 수정할 것인지. 그리고 하나의 지침을 첨부했습니다:
상호 합의를 인위적으로 만들어내지 마십시오. 상호 검토를 거쳐도 남아있는 의견 불일치야말로 외교적인 분열보다 더 가치가 있습니다.
이 한 문장이 이 실험의 대부분을 차지합니다. 이것은 사회가 결코 없었던 것에 대한 사회적 본능을 무너뜨리기 위한 것입니다. 만약 이 문장이 없다면, 저는 전체 과정이 두 모델이 서로에게 지나치게 친절해지는 것(별로 많은 것을 배우지 못하는 매우 값비싼 방식)으로 붕괴될 것이라고 생각합니다.
저는 기대했던 것보다 더 잘 작동했고, 저를 놀라게 한 것은 그들이 포기할 의향이 얼마나 많았는지였습니다.
첫 번째 검토자는 이 아키텍처에 제기된 다섯 가지 비판 사항을 모두 인정했으며, 그 양보 중 몇몇은 '제가 고려하지 못했습니다(I had not considered)'라는 버전으로 시작했는데, 이는 모델들이 자주 사용하는 표현이 아닙니다.
또한 가장 크게 추천했던 변경 사항도 철회했습니다. 이전에 컴파일 시점에서 이러한 종류의 문제를 포착하는 것이 높은 가치를 지닌 움직임이라고 주장했었다가, 이제는 사람이 이미 설계를 올바르게 한 후에야 컴파일러가 다시 잘못되는 것을 잡아낸다는 점을 받아들였습니다. 즉, 안전장치일 뿐이고 실제 작업을 하는 것은 아니라는 것입니다.
그리고 상대방의 자극으로 인해, 자신이 제안했던 리팩토링(refactor)이 전체 클래스의 연산을 담을 곳이 없다는 것을 발견했습니다. 파일 시스템에 접근하는 것을 막으면서도 다른 대안적인 처리 공간을 제공하지 못했고, 그 결과 하나의 출력 형식은 포함성 문제(containment problem)를 단순히 작동하지 않는 기능으로 만들어 버렸습니다.
두 번째 리뷰어는 제가 더 마음에 드는 행동을 했습니다. 자신이 근거로 삼았던 메커니즘을 포기하고 스스로의 모순에 빠졌습니다. 다른 사람의 제안에 맞서 일관성 규칙(consistency rule)을 결정적인 논거로 사용했다가, 정작 자신은 그 규칙이 깨지는 것을 받아들인 것입니다.
둘 다 움직였고, 둘 다 말했고, 아무도 대가를 치르지 않았습니다. 마감 기한이 있는 5명의 엔지니어들이 모인 방에서 그런 상황을 만들어내는 건 정말 어렵습니다!
하나의 차이점은 유지되었습니다. 첫 번째 리뷰어는 샌드박스(sandbox) 자체가 모든 탈출 시도(escape attempt)를 크고 명백한 실패로 만든다는 주장을 받아들이지 않았습니다. 그리고 그 논리는, 순순하게 행동하지 말라고 지시받은 리뷰어에게서 기대할 수 있는 종류의 것이었습니다:
파일 시스템 작업이 거부되면 일반적으로 오류가 발생할 뿐이며, 프로세스를 본질적으로 종료시키지는 않습니다. 구성 요소는 이 오류를 흡수할 수 있습니다.
이것은 소리 내어 말하는 순간 명백해졌고, 저를 포함해서 아무도 그것을 말한 적이 없었습니다.
결함의 두 가지 전체 계열(families of defect)이 분석의 별개 섹션에 마치 서로 관련 없는 것처럼 놓여 있었는데, 알고 보니 매우 밀접하게 연결되어 있었습니다. 샌드박스가 제공하는 보호는 그 위에 있는 코드가 거부된 내용을 쓰레기통에 버리지 않는다는 것에 달려 있으며, 거부가 쓰레기통에 버려질 수 있는 샌드박스는 벽이라기보다는 정중한 제안에 가깝습니다.
이것은 자체적인 요구사항으로 명세(spec)에 포함되었습니다. 두 리뷰어 모두 혼자서 그 지점에 도달한 것은 아니었고, 저는 그것이 단지 그들 중 한 명이 서면으로 친절하게 행동하지 말라는 지시를 받았기 때문에 존재하는 것이라고 확신합니다.
위의 모든 것은 모델 검사(models checking)에 대한 모델 검사이며, 점검해야 할 대상이 바로 나 자신일 때는 훨씬 더 불편해집니다.
저는 검색 시스템을 질문 세트와 비교하여 보정하고 있었습니다. 저는 그 시스템이 검색할 문서를 작성했고, 질문도 제가 직접 작성했습니다(실제 테스트를 강제하기 위해 의도적으로 어렵게 만들었습니다). 그리고 저는 모든 답을 알고 있었습니다.
그것 때문에 저는 그것이 작동했는지 여부를 판단하는 최악의 심사관이 되었고, 저는 놀라울 정도로 알아차리는 것이 느렸습니다. 검색된 구절을 읽었을 때, 그것이 질문에 대한 답을 제시한 것인지 아니면 제가 이미 가지고 있던 답변을 단순히 상기시켜 준 것인지 구분할 수 없었고, 자신의 문서를 모르는 상태로 되돌릴 수는 없습니다.
그래서 저는 경쟁사 벤더의 모델에게 심사 역할을 맡겼는데, 그 주된 자격은 제 컨텍스트가 전혀 없다는 것이었습니다. 저는 그것의 무지함 때문에 이 심사관을 선택했습니다 (이 문장을 제가 쓰게 될 줄은 상상도 못 했습니다).
그러고는 한 벤더 범위의 양 끝에 있는 두 모델을 대상으로 테스트를 두 번 더 실행했습니다. 왜냐하면 단 하나의 심사관의 말만 믿는 것은 또다시 같은 실수를 저지르는 것이 되었을 것이기 때문입니다. 제가 원했던 것은 판결(ruling) 그 자체가 아니라, 살펴볼 다양한 의견들의 분포였습니다.
그리고 그중 하나가 제 문서들이 스스로 모순된다고 발표했을 때, 저는 그것이 실제 모순인지 아니면 단순히 컨텍스트에서 벗어나 이상해 보이는 두 구절에 불과한지 확인하러 갔습니다. 심사관의 발견은 증거 더미 속으로 돌아갔고, 최종 결정권은 제게 남았습니다.
같은 일이 제가 일주일 동안 매달렸던 스펙에서도 발생했습니다. 저는 자신이 편향되어 있고 공정할 것이라고 믿지 못했기 때문에 특별히 두 번째 의견을 요청했고, 그 리뷰는 충분히 어려워서 스펙이 '승인됨(approved)'에서 다시 '초안(draft)'으로 돌아가 재작성되었습니다. 기분이 상했어요! 하지만 그것에 대해 논쟁하는 것은 제가 디자인 자체를 방어하는 것이 아니라 일주일이라는 시간을 방어하는 것이었을 겁니다.
여기서 멈추면 모든 것이 매우 원칙적으로 들릴 것입니다. 하지만 이것 또한 대처 메커니즘이기도 하므로, 이 부분을 건너뛰는 것은 약간 부정직하게 느껴질 것 같습니다.
평소 날에는 여러 프로젝트에 걸쳐 이런 세션들을 많이 진행합니다. 때로는 열네 개나 됩니다. 저는 그렇게 많은 컨텍스트를 머릿속에 담을 수 없으며, 마땅히 받아야 할 주의력을 가지고 그 모든 작업을 제가 직접 확인할 수는 없습니다. 그래서 저는 대신 여분(redundancy)을 구매하고, 그렇지 않았다면 이중으로 확인되었을 것들을 삼중으로 확인하게 만듭니다. 이것은 엄밀함(rigour)이라기보다는 헤징(hedging)에 가깝고, 외부에서 보면 둘 다 매우 비슷해 보입니다.
리뷰어는 종종 예산 문제로 지적받기도 합니다. 만약 한 구독권에 일주일치 할당량이 남아 있고 다른 것은 거의 소진되었다면, 할당량이 있는 쪽이 리뷰를 진행하고 무거운 작업은 여유가 있는 곳으로 이동합니다. 매일매일, 크로스 모델(cross-model) 리뷰는 대부분 어떤 구독권이 아직 감당할 수 있는지 계산하는 저의 일입니다 (저는 구두쇠라 티가 납니다).
저는 이 모든 것이 두 번째 의견을 권위 있게 만들지는 못한다고 생각합니다. 그것 역시 또 다른 생성 모델(generative model)이며, 첫 번째 모델만큼이나 결함이 있을 수 있기 때문에, 여전히 그 가정에 동의하지 않는 부분에서는 반박하고, 평가자를 평가하는 인간의 역할은 여전히 이 시스템의 중요한 일부입니다.
저는 단일 모델의 리뷰가 무가치하다고까지는 말하지 않을 것입니다... 대부분의 것에는 가치가 있으며, 그것을 사용하려면 매우 신중하게 정의해야 하는 단어입니다. 하지만 결함이 있나요? 네. 제가 정착한 단어는 '결함(Flawed)'이며, 이것이 제가 하나에만 의존하는 것을 멈춘 이유입니다.
헤라클레이토스(Heraclitus)는 우리보다 훨씬 전에 그 지점에 도달했지만, 사람들은 그것을 끊임없이 오해합니다. "전쟁은 모든 것의 아버지이자 왕이며; 어떤 이들에게는 신으로, 어떤 이들에게는 인간으로 나타났고; 어떤 이들을 노예로, 어떤 이들을 자유민으로 만들었다" (이는 Stanford Encyclopedia of Philosophy가 번역한 단편 53에 나오는 구절)는 마치 전장에서 환호하는 사람처럼 읽히지만, 그가 실제로 의미했던 것을 살펴보면 다릅니다.
원래 그리스어로는 "Πόλεμος πάντων μὲν πατήρ ἐστι, πάντων δὲ βασιλεύς, καὶ τοὺς μὲν θεοὺς ἔδειξε τοὺς δὲ ἀνθρώπους, τοὺς μὲν δούλους ἐποίησε τοὺς δὲ ἐλευθέρους"입니다 (대략적으로 "polemos panton men pater esti, panton de basileus, kai tous men theous edeixe tous de anthropous, tous men doulous epoiese tous de eleutherous"). 그는 'polemos'를 사용하는데, 여기서 이는 전쟁보다는 대립(opposition)에 가깝습니다. 즉, 서로 반대되는 것들 사이의 긴장이며, 그가 생각하기에 모든 것이 존재하게 되는 방식이 바로 그것입니다. 그의 그림은 활과 리라였습니다. 어떤 것도 두 가지 힘이 서로 당기는 상태가 아니면 존재할 수 없으며, 그 힘들이 멈추는 순간 당신에게 남는 것은 막대기와 상자뿐입니다.
제가 만든 것이 대략 이와 같습니다. 매우 작고 매우 저렴한 방식으로, 서로 반대 방향으로 잡아당기지만 휴전은 금지된 두 가지를 이용했습니다. 방에 있는 다섯 명의 엔지니어들이 아마도 같은 것을 만들어낼 수 있을 것입니다... 다만 그들끼리 그것 때문에 다툴 의향만 있다면요. 그리고 저는 제가 좋아하는 사람들에게 그런 요구를 하고 싶지는 않습니다.
원래는 2026년 10월 21일 phpboyscout.uk에 게시되었습니다.