논문 세 편의 생산성 숫자가 다를 때, 평균내기 전에 볼 조건

“AI를 쓰면 빨라진다”는 논문과 “오히려 느려졌다”는 논문을 한 보고서에 넣어야 한다고 해 볼게요. 어느 논문을 뺄지부터 정하면 결론에 맞는 근거만 남기기 쉬워요. 먼저 세 편이 무엇을 같은 것으로 세고 무엇을 다른 것으로 측정했는지 적으면, 겉으로 상반된 숫자를 더 정확하게 설명할 수 있어요.

첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.

이번 예제는 AI 코딩 도구 도입을 검토하는 연구팀의 문헌 메모예요. 실제 공개 연구 세 편을 사용하지만 팀과 의사결정 상황은 가정이에요. 완성물은 조건 비교표 (ZIP: comparison.csv)와 보고서용 결론 메모 (ZIP: conclusion.md)예요. 실험을 재분석하거나 어느 연구가 더 참인지 점수를 매기는 작업은 아니에요.

질문을 ‘몇 퍼센트 좋은가’에서 잠시 떼어 놓아요

비교 질문은 “도구 접근이나 사용이 개발자의 작업 성과에 어떤 차이를 냈고, 그 차이를 우리 팀에 적용할 조건은 무엇인가?”로 정했어요. 여기에는 두 작업이 들어 있어요. 논문이 실제로 추정한 효과를 정확히 읽는 일, 우리 팀과의 차이를 판단하는 일이에요. 두 번째는 문헌의 직접 결론이 아니라 우리 쪽 해석이므로 칸을 나눠요.

자료는 Peng 외의 통제 과제 연구, Cui 외의 기업 현장 실험, Becker 외의 숙련 개발자 연구예요. 같은 코딩 주제를 다루면서 과제와 성과 측정이 달라 비교 연습에 맞아요. 같은 참가자를 세 조건에 무작위 배정한 하나의 연구가 아니라는 점을 첫 줄에 적어 두었어요.

숫자 옆에 분모와 완료 기준을 붙여요

Peng 외 연구는 표준 JavaScript 과제를 사용하고, 정해진 테스트를 모두 통과한 시점까지의 시간을 측정해요. 보고된 55.8% 시간 단축은 과제를 완료한 사람만 비교한 값이에요. 95명을 모집·배정했지만 완료자는 각 집단 35명이었고, 그 완료자 평균은 도구 접근 집단 71.17분, 비교 집단 160.89분이었어요. 따라서 95명 전원의 평균 효과로 읽으면 안 돼요. 전체 소프트웨어 개발 수명주기의 비용 절감으로 바로 옮길 수는 없어요. 원문의 Study Design·Results에서 과제와 측정 기준을 함께 확인했어요.

Cui 외 연구의 대표 숫자는 주간 완료 작업량의 변화예요. 또한 접근 권한의 무작위 배정을 도구 실제 사용의 도구변수로 쓰는 추정이므로, 단순히 권한을 받은 모든 사람의 평균 차이라고 적으면 추정 대상이 바뀌어요. 예제 표에는 이를 ‘실제 사용 효과의 IV 추정’으로 남겼어요. IV는 무작위 배정과 실제 사용의 차이를 이용하는 방법이라는 정도까지 읽고, 세부 가정은 원문에서 더 확인해야 해요. 공개 원문 1절·각주 4가 근거예요.

Becker 외 연구는 익숙한 저장소의 작업을 AI 허용 또는 불허에 배정하고, 검토 후 수정까지 포함한 완료 시간을 사용해요. 이 표에서는 허용된 작업의 시간이 더 길어진 결과를 그대로 남겨요. 원문 2.2·2.3·3절을 보면 어떤 시간을 포함했는지 확인할 수 있어요.

이 표만으로도 ‘증가’가 두 번째 연구에서는 산출량 확대, 세 번째에서는 작업 시간 증가라는 차이가 보여요. 같은 색의 위쪽 화살표로 두 숫자를 그리면 의미가 뒤집힐 수 있어요. 시각 자료도 먼저 유리한 방향을 정의하고 만들어야 해요.

단위를 맞춰도 비교가 완성되지는 않아요

시간 20% 단축을 작업량 20% 증가로 바꾸는 것도 피해야 해요. 단순한 산술 예제로, 같은 품질의 작업이 100분에서 80분으로 줄면 시간은 20% 감소하지만 고정된 시간의 처리율은 100÷80=1.25배예요. 이 계산조차 작업 종류·난이도·품질이 일정하다는 가정이 필요해요. 실제 논문의 작업량을 이런 식으로 환산했다는 뜻은 아니에요.

또한 표준오차와 신뢰구간은 같은 열에 숫자만 놓지 않아요. Peng의 보고 구간과 Cui의 표준오차는 이름을 붙여 원래 형태로 보존했어요. 발표 자료를 줄이더라도 불확실성 표시를 지워 단일 숫자만 확정값처럼 남기지 않는 편이 좋아요. Becker 연구의 세부 불확실성 분석은 원문으로 연결하고, 이 예제에서는 다른 자료와 수치를 합산하지 않았어요.

남는 질문은 “무엇이 결과 차이를 만들었나?”예요. 숙련도는 가능한 설명이지만 연구마다 도구, 시기, 과제, 기존 코드에 대한 익숙함도 달라요. 논문 사이의 차이만으로 숙련도의 인과효과를 분리할 수는 없어요. 비교표의 역할은 후보 설명을 드러내는 데까지예요. 하나를 원인으로 확정하려면 그 요인을 따로 비교하는 설계가 필요해요.

같은 단위의 연구 두 편만 남으면 어떻게 쓸까요

이번에는 공개 논문의 수치와 별개로, 비교 조건만 바꾼 합성 사례를 하나 더 볼게요. 연구 D와 E가 같은 완료 검사와 같은 과제를 쓰고, 각 집단 40명 모두가 완료했다고 가정해요. D는 100분에서 80분, E는 120분에서 108분이에요. 시간 단축률은 각각 20%와 10%지만, 표준편차와 배정·분석 설계는 주어지지 않았어요.

같은 단위라는 이유로 무조건 합치거나, 조건이 조금 다르다는 이유로 자료를 통째로 버릴 필요는 없어요. 질문이 ‘두 과제에서 어떤 변화가 관측됐나’라면 연구별 값을 보존해요. 질문이 ‘우리 팀의 평균 효과가 얼마인가’라면 대상·배정·분산과 통합 방법을 더 확보해야 해요. 조건별 완성 메모 (ZIP: condition-memos.md)에 다음 결론과 대안을 채웠어요.

같은 완료 정의를 가정한 D와 E에서는 평균 시간이 각각 20%와 10% 감소했다. 표본 수만으로 연구의 정밀도를 정할 수 없고 설계·분산 정보가 없으므로 두 비율을 통합 효과로 제시하지 않았다. E가 검토 전 시간만 센 자료라면 같은 완료 시간을 비교했다는 첫 문장부터 수정한다.

이 예제의 40명·시간 값은 설명을 위해 만든 값이며 원논문에 추가된 관측이 아니에요. 입력과 계산 코드 (ZIP: compare-conditions.py)를 실행하면 두 변화율과 조건별 보류 이유를 다시 확인할 수 있어요.

결론은 세 문장으로 완성해요

예제 보고서에는 다음처럼 적었어요.

검토한 연구는 사람의 코딩 작업을 다루지만 성과 지표와 작업 환경이 다르므로 보고된 효과 크기를 하나로 평균내지 않았다. 우리 팀의 도입 판단에는 코드 작성뿐 아니라 검토·수정까지의 완료 시간과 산출물 품질을 함께 확인할 필요가 있다. 숙련도나 저장소 익숙함이 차이를 설명할 가능성은 후속 검증 대상으로 남긴다.

첫 문장은 추출한 사실, 두 번째는 가상 팀의 목적에 따른 제안, 세 번째는 아직 검증하지 않은 설명이에요. 각 문장의 역할을 구분하면 논문 인용 뒤에 자기 생각이 섞여도 독자가 확인할 수 있어요. ‘가능성이 있다’는 표현만 덧붙이는 것보다 무엇이 검증되지 않았는지 적는 편이 선명해요.

자기 분야에 적용할 때도 비교표의 순서는 같아요. 질문을 정하고, 각 논문에서 대상·설계·비교 조건·결과변수·근거 위치를 채운 뒤, 단위가 맞는지 확인해요. 원문에서 측정값을 못 찾으면 초록 수치만으로 합치지 말고 그 칸을 ‘확인 필요’로 두세요. 자료가 두 편뿐이거나 연구 설계가 달라도 비교는 가능해요. 다만 결론을 “같은 현상을 얼마나 다르게 관찰했는가”가 아니라 “서로 어떤 질문을 답했는가”로 제한하면 돼요.

확인한 판본은 Peng arXiv v1, Becker arXiv v1, 확인일에 MIT가 제공한 Cui 공개 PDF예요. 2026년 10월 13일에 확인했으며 최신 도구의 효과를 측정한 새 실험은 수행하지 않았어요. 다음 글의 예비 설계서는 이 비교에서 드러난 측정 문제를 작은 실행 계획으로 바꿔요.

예제 파일을 한 번에 받아 다시 확인해요

이 글의 입력·코드·완성 자료 ZIP을 새 폴더에 풀면 R02/README.txt, replay.py, assets 폴더가 함께 생겨요. 개별 코드 파일만 저장하면 보조 모듈이나 입력이 빠질 수 있으므로 처음에는 이 묶음을 사용하세요. R02 폴더에서 다음 명령을 실행하면 본문에 사용한 검사를 순서대로 수행해요.

python3 replay.py

확인할 결과는 D 시간20% 감소·E 시간10% 감소, 통합 효과는 미계산예요. 명령이 성공해도 이 값과 본문의 적용 범위를 함께 대조하세요. 실행 안내 (ZIP: README.txt)에 필요한 파일과 개별 명령을 적었어요. 실행 코드는 compare-conditions.py (ZIP: compare-conditions.py)에서 직접 볼 수 있어요. Python3.12의 표준 라이브러리를 사용하며, 명령이 실패하면 ZIP의 폴더 구조와 오류에 나온 파일부터 확인해요. 실제 앱 실행에 필요한 프로그램은 원래 설명을 따르세요.

작성·확인: Codex가 공개 원문 또는 공식 문서를 확인하고 예제와 초안을 작성했어요. 사람을 대상으로 한 사용성 검증은 수행하지 않았어요.

설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.