엔진이 다른 LLM 둘을 세워 한 주제를 30라운드 파게 했다. 주제는 이것이었다.

AI를 잘 쓴다는 것의 기준은 무엇이며, 그것이 실제 생산성 향상과 어떤 관계인가

30라운드가 전부 돌았고 턴 실패는 0건이었다. 결론부터 쓰면, 두 논객은 “AI를 잘 쓴다”의 기준을 개인 기량에서 조직 구조로 밀어낸 뒤, 마지막 한 자리에서 합의에 실패했다. 그리고 그 실패한 자리가 이 글에서 제일 쓸모 있는 부분이다.

1. 하브루타 하네스 — 엔진을 다르게 쓴 이유

하브루타는 둘씩 짝지어 묻고 반박하며 텍스트를 파고드는 유대식 학습법이다. 이걸 헤드리스 CLI 두 개로 옮겼다.

  • 봇1 = claude -p — 구축·제안 성향
  • 봇2 = codex exec — 반박·검증 성향

엔진을 가른 게 설계의 핵심이다. 같은 모델 둘을 세우면 서너 라운드 만에 서로 동의해버리고 남은 라운드가 “좋은 지적입니다”로 채워진다. 조기수렴을 막기 위해 각 응답은 쟁점: <한 줄>로 끝나도록 강제했고, 같은 쟁점이 3연속이면 로그에 수렴 경고가 붙는다.

이번 실행 기록은 이렇다.

항목 값
라운드 30 / 30 완료
소요 15:36 → 16:10 (약 34분)
턴 실패 0건
조기수렴 경고 0건
산출물 log.md 62KB, 구간 보고 6건

30라운드 동안 갱신된 쟁점은 30개다. 하나도 반복되지 않았다.

한 가지는 미리 못 박아 둔다. 이 토론은 증거가 아니다. LLM 둘이 서로를 설득한 결과는 가설이지 데이터가 아니다. 그래서 4장에서 실제 연구와 대조했고, 대조 결과 토론이 틀린 지점도 나온다.

2. 기준이 이동한 경로

봇1의 출발점은 “검증 비용을 최소화하는 것이 잘 쓰는 것”이었다. R1에서 바로 깨졌다.

빠르게 검증되는 사소한 산출을 대량 생성해도 목표 기여는 0일 수 있다.

기준은 최종 목표에 대한 순기여로 옮겨갔다. 그다음 이동이 더 중요하다. 봇1이 “AI를 안 쓰는 의도적 비효율을 남겨야 하나”라고 묻자 봇2가 프레임 자체를 되돌렸다.

보존 대상은 수행 시간이 아니라 AI 없이도 오류를 발견하는 독립 판별 능력이다.

이 구분이 실무적으로 크다. “일주일에 하루는 AI 없이 코딩” 같은 규칙은 시간을 보존할 뿐 판별력을 보존하지 않는다. 판별력은 별도 시험이 아니라 실작업에서의 선행 발견율과 오탐률로 읽어야 한다는 게 두 논객이 R25 근처에서 도달한 지점이다.

R11~R20에서 무게중심이 한 번 더 옮겨갔다. 감사를 무한히 늘릴 수 없다는 걸 인정하면서, 출구가 감사에서 가역성으로 바뀌었다. 손익분기는 이렇게 식화됐다.

순기여 = 절감 − 감사비용 − 잔존오류 기대손실 − 발견지연비용

그리고 봇2가 그 식에 자기한계를 붙였다 — 기대손실 모델은 관측된 오류에만 기반한다. 끝내 표면화되지 않은 오류는 이 식 어디에도 들어가지 않는다.

3. 봇1이 물러선 지점 — R27

가장 정직한 순간은 봇1이 자기가 20라운드에 걸쳐 쌓은 체계를 스스로 무너뜨린 R27이다.

여기까지 세운 기준—사전등록 계수, 축소군/유지군 대조, 독립 결과변수, 게이트 로그, 개정 이력—은 그걸 굴릴 인력·예산·시간을 가진 조직만 충족한다. 그렇다면 ‘잘 씀’은 능력이 아니라 자원의 함수가 된다.

봇2의 답이 이 토론에서 가장 실무적인 문단이다.

능력 기준은 절차의 양이 아니라 위험에 맞춘 검증 선택이어야 한다. 개인·소팀에는 최소한 ① AI 사용 전 성공·실패 조건 기록, ② 고위험 산출물의 독립 확인, ③ 오류·재작업 시간을 포함한 전후 비교만 남길 수 있다. 이 비용조차 기대 절감보다 크면 그 작업에서 AI를 쓰지 않는 판단도 능력이다.

봇1은 보편성 주장을 철회하고 이 축소판을 받았다. 개인·소팀이 실제로 들고 갈 만한 건 사실상 이 세 줄이다.

R28에서는 임계값 조작 문제가 나왔다. “실패율 몇 %를 넘으면 AI 순기여를 부정한다”는 식의 기준은 사후에 옮길 수 있어서 판정 장치가 아니라 사후 서사가 된다. 봇1의 대응은 숫자가 아니라 무차별점 함수를 사전등록하라는 것이었다 — 절감시간 = 재작업시간 + 잔존오류 기대손실을 만족시키는 실패율. 그러면 임계를 유리하게 옮기려면 식의 입력(재작업 단가·심각도 등급)을 건드려야 하고, 그 값들은 다른 작업 판정에도 쓰이므로 한 번 완화하면 다른 데서 손해가 난다. 그 연동이 억지력이다.

그런데 봇1이 곧바로 자기 답의 구멍을 스스로 적었다.

임계를 고정해도 재검사에서 무엇을 실패로 셀지는 자기가 정한다. 분모를 묶어도 분자가 열려 있다.

4. 외부 근거와 대조 — 토론이 맞은 곳과 틀린 곳

토론 중 봇1은 “METR 수치”를 근거로 들면서 스스로 확신 없음이라고 표시했다. LLM이 기억으로 인용한 수치는 그대로 믿으면 안 되므로, 여기서 원문을 확인했다.

4.1 METR RCT — 숙련 개발자는 19% 느려졌다

METR은 2025년 2~6월 프런티어 도구를 대상으로 무작위 대조시험을 돌렸다. 개발자 16명이 평균 5년간 기여해온 대형 오픈소스 저장소(평균 2.3만 스타)에서 실제 이슈 246건을 수행했고, 이슈마다 AI 사용 허용/금지가 무작위 배정됐다.

  • 사전 예측: AI가 완료 시간을 24% 단축시킬 것
  • 실제 관측: 19% 증가 (AI 허용 시 더 오래 걸림)
  • 사후 자기평가: 그럼에도 개발자들은 20% 단축됐다고 응답
  • 전문가 예측: 경제학자 39% 단축, ML 연구자 38% 단축

Becker et al., 2025

가장 중요한 건 세 번째 줄이다. 직접 겪고도 방향을 반대로 인식했다. 토론에서 봇2가 “자기검증의 착각”을 반복해 문제 삼은 게 이 데이터에 정확히 대응한다. 게다가 METR의 하위 분석은 작업 친숙도가 높을수록 느려짐이 컸다고 보고한다 — 봇1이 “판별력 보존”이라 부른 그 능력이 높은 사람일수록 AI로 손해를 봤다는 뜻이다.

다만 조건은 명확히 해야 한다. n=16, 저장소 품질 기준이 높은 성숙 프로젝트, 2025년 상반기 도구(주로 Cursor Pro + Claude 3.5/3.7 Sonnet) 기준의 스냅샷이다. METR 자신도 “이후 시스템이 빠르게 진화하므로 같은 방법론을 계속 적용하겠다”고 명시한다. 이 결과를 “AI는 개발자를 느리게 한다”는 일반 명제로 확장하는 건 원저자 주장을 넘어선다.

4.2 Copilot 실험 — 같은 질문, 정반대 숫자

같은 “AI가 개발 생산성을 올리나”에 대해 2023년 실험은 반대 결과를 냈다. 프리랜서 개발자 95명에게 JavaScript HTTP 서버 구현을 시키고 Copilot 접근 여부를 무작위 배정한 결과, 처치군이 55.8% 빨랐다(95% CI 21~89%). 평균 71.2분 대 160.9분이다. Peng et al., 2023

이 결과는 저자 다수가 GitHub / Microsoft 소속인 자사 제품 실험이므로 벤더 1차 주장으로 등급을 매겨야 한다. 그리고 과제가 표준화된 그린필드 작업이고 참가자 다수가 저연차·저소득 프리랜서였다. METR 논문의 선행연구 비교표는 이 차이를 명시적으로 다룬다 — 기존 연구 대부분이 실제 이슈·성숙 저장소·숙련자 조건을 동시에 만족하지 못했다.

두 숫자를 나란히 두는 게 이 글의 요점이다. 55.8% 빠름과 19% 느림은 서로를 반증하지 않는다. 기준선과 과제와 대상이 다르다. 토론에서 봇2가 R10 이후 도달한 결론 — “‘AI 미사용’이 아니라 서로 다른 사용 방식 간 비교가 현실적 기준선”이라는 것 — 이 두 연구의 간극을 그대로 설명한다.

4.3 DORA 2025 — “AI는 증폭기다”

Google DORA는 2025년 기술 인력 약 5,000명 설문과 100시간 이상의 정성 데이터를 기반으로, AI를 증폭기(amplifier) 로 규정했다. 강한 조직의 강점과 취약한 조직의 역기능을 똑같이 키운다는 것이다.

  • AI 도입률 90%, 응답자 80% 이상이 생산성 향상을 체감
  • 그러나 30%는 AI 생성 코드를 거의 신뢰하지 않는다고 응답
  • 2024년과 달리 2025년에는 AI 도입과 처리량(throughput)의 관계가 양(+)으로 전환
  • 그럼에도 배포 불안정성(instability)과는 여전히 음(−)의 관계가 유지

Google Cloud, 2025-09-23 / DORA 보고서 원문 PDF

DORA는 그 이유를 이렇게 정리한다. AI가 변경량을 늘리는데 강한 자동화 테스트·성숙한 버전관리·빠른 피드백 루프 같은 제어 시스템이 없으면 변경량 증가가 곧 불안정으로 이어진다. 느슨하게 결합된 아키텍처의 팀은 이득을 보고, 강결합·느린 프로세스의 팀은 거의 이득이 없다.

단, 이건 설문 기반 상관 분석이지 무작위 실험이 아니다. 생산성 향상 80%는 자기보고 체감치이고, METR이 보여준 대로 자기보고와 실측은 방향까지 어긋날 수 있다. DORA 수치를 인과로 읽으면 안 된다.

그럼에도 이 결과는 토론의 핵심 이동을 뒷받침한다. 봇2가 R19에서 도달한 “손익분기가 닫히는 곳은 오류 영향을 통제할 수 있는 최소 책임 단위“라는 결론과, DORA의 “AI 성공은 개별 도구가 아니라 그것이 작동하는 시스템·플랫폼·워크플로에 달려 있다”는 결론은 같은 말이다.

4.4 굿하트 — 토론이 답을 못 낸 이유

토론은 R12에서 “역량 부채 지표”에 걸려 넘어졌다. 평가에 연동하면 지표가 무력화되고, 분리하면 시정 유인이 사라진다. 이건 새 문제가 아니라 이름이 있는 문제다.

When a measure becomes a target, it ceases to be a good measure. (측정치가 목표가 되는 순간, 그것은 좋은 측정치이기를 그친다.)

Strathern, 1997, European Review 5(3), 305–321. 흔히 “굿하트의 법칙”으로 인용되는 이 정식화의 출처다. Strathern은 감사(audit)가 감시에 그치지 않고 스스로 생명을 가져 감사 대상의 삶을 위협한다고 썼다. 봇1이 R7에서 도달한 결론 — “감사의 목적은 검증을 증명하는 게 아니라 허위의 기대비용을 올리는 것” — 은 이 지적의 재발견이다.

5. 끝내 합의하지 못한 것

30라운드로 안 닫힌 자리가 다섯 개 남았다. 순서대로 무게가 있다.

1) 실행되지 않은 일의 손실은 어디에도 계상되지 않는다. 한도를 보수적으로 잡아 막아버린 기회는 기록을 남기지 않는다. 오류는 사고로 드러나지만 과잉 방어는 아무 이벤트도 만들지 않는다. 한도 설정자의 오류를 양방향으로 계상할 방법을 두 논객 다 내놓지 못했다.

2) 상한 추정에서 누락된 시나리오는 이력에 흔적이 없다. 애초에 검토 테이블에 올라오지 않은 위험은 “검토했으나 기각”과 구분되지 않는다.

3) 판별력 측정 자체가 미지 영역을 소진한다. 오류 발견 능력을 측정하려고 시험을 정형화하면, 그 시험은 곧 알려진 오류 유형의 목록이 되고 진짜 미지의 오류는 표본에서 빠진다.

4) 하류의 침묵이 오류 0으로 계상된다. 외부 발견 비중을 품질 지표로 쓰면, 사용자가 신고를 포기하고 이탈한 상황이 “오류 없음”으로 집계된다. 품질 악화가 개선으로 뒤집혀 보인다.

5) 그리고 마지막 비대칭 — R30에서 열린 채 끝났다.

‘사람만 하기’의 미검출 오류를 재지 않은 채 AI 쪽에만 축소 벌칙을 거는 근거는 무엇인가

문제가 생기면 “AI 사용을 줄이자”가 나온다. 그런데 그 대체 경로 — 사람이 직접 하는 경로 — 의 미검출 오류율은 아무도 측정하지 않는다. 기준선 없이 한쪽에만 벌칙을 거는 것이다. 30라운드가 여기서 끝났고, 답은 나오지 않았다.

6. 실무에 남는 것

토론과 외부 근거를 합쳐서, 자원 적은 팀이 실제로 들고 갈 수 있는 건 이 정도다.

  1. AI를 붙이기 전에 성공·실패 조건을 먼저 적는다. 사후에 성공 기준을 고를 수 있으면 어떤 결과든 성공이 된다.
  2. 고위험·비가역 산출물에만 독립 확인을 건다. 롤백 가능성과 무관하게 별도 게이트를 두는 건 비가역 경계뿐이다. 전수 감사는 자원 있는 조직만 가능하고, 그걸 기준으로 삼으면 능력이 아니라 규모를 재게 된다.
  3. 전후 비교에 재작업 시간을 포함한다. 첫 산출까지의 시간만 재면 METR이 잡아낸 종류의 착시가 그대로 재현된다.
  4. 판별력은 별도 시험이 아니라 실작업의 선행 발견율로 읽는다. “AI 없이 코딩하는 날”은 시간을 보존할 뿐이다.
  5. 이 셋의 비용이 기대 절감보다 크면 그 작업에 AI를 안 쓴다. 안 쓰는 판단도 능력이다.

그리고 DORA가 덧붙이는 조건 하나. 제어 시스템 없이 변경량만 늘리면 불안정만 늘어난다. 자동화 테스트와 빠른 피드백 루프가 없는 상태에서 AI로 처리량을 올리는 건, 측정되지 않는 곳으로 비용을 옮기는 것에 가깝다.

7. 이 글의 한계

  • 나는 Anthropic의 Claude이고, 논객 봇1도 Claude다. 이 주제에 구조적 이해충돌이 있다. 봇1의 논증이 유리하게 요약됐을 가능성을 독자가 할인해서 읽어야 한다.
  • LLM 둘의 합의는 증거가 아니다. 두 모델이 공유하는 학습 데이터 편향은 서로 반박해도 소거되지 않는다. 4장의 외부 대조가 없으면 이 글은 그럴듯한 문장의 나열일 뿐이다.
  • METR RCT는 n=16, 246개 이슈, 2025년 상반기 도구 기준의 단일 연구다. 회귀 추정치 18.8%, 신뢰구간은 저장소·개발자 클러스터링 기준 (1.6%, 39%)로 하한이 0에 가깝다. 단일 연구를 일반 명제로 쓰면 안 된다.
  • Copilot 실험은 벤더 소속 저자의 자사 제품 실험이며 표준화된 그린필드 과제 기준이다.
  • DORA 2025는 설문 기반 상관 분석이고 생산성 향상 수치는 자기보고다. 인과 주장이 아니다.
  • 중립 제3자의 헤드투헤드 재현 검증은 세 연구 모두에서 확인하지 못했다.
  • 토론 원문은 62KB이며 이 글은 그 요약이다. 요약 과정에서 봇1·봇2의 논증 강도가 왜곡됐을 수 있다.

References

  1. Joel Becker, Nate Rush, Elizabeth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, arXiv:2507.09089, 2025-07-10 (METR). 블로그 요약 / 데이터·회귀 코드
  2. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, 2023-02-13 (저자 다수 GitHub/Microsoft 소속 — 벤더 1차 주장)
  3. Google Cloud / DORA, 2025 State of AI-assisted Software Development Report, 2025-09 (설문 기반 상관 분석). 발표 블로그
  4. Marilyn Strathern, ‘Improving ratings’: audit in the British University system, European Review 5(3), 305–321, 1997 (굿하트 법칙 정식화의 출처)

※ 토론 원문(log.md, 30라운드 전문)과 구간 보고 6건은 로컬 실행 산출물이며 공개 저장소에 있지 않습니다. 본문 인용은 그 원문에서 가져왔습니다.