논문 요약 세 개를 붙여 놓았는데 관련 연구 문단처럼 읽히지 않는다면, 요약을 더 길게 쓰기보다 문단이 답할 질문을 먼저 고르는 편이 좋아요. 이번에는 “AI 코딩 연구의 숫자를 왜 같은 생산성 효과로 바로 묶을 수 없는가?”를 설명하는 문단을 만들어요. 실제 공개 논문을 사용하고, 이 문단을 넣을 연구계획은 가정해요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
완성 결과는 수정 전후 문단 (ZIP: paragraph-before-after.md)과 문장별 근거표 (ZIP: sentence-evidence.csv)예요. 문장을 자연스럽게 다듬는 데서 끝내지 않고, 연결어가 원문보다 강한 결론을 만드는지도 확인할 거예요.
이름을 지우고도 문단의 질문이 남는지 봐요
출발 문단은 다음과 같아요.
AI 도구의 생산성에 대한 연구가 있다. Peng 외는 코딩 과제를 연구했다. Cui 외는 기업 개발자를 연구했다. Becker 외는 오픈소스 개발자를 연구했다. 따라서 AI 도구의 효과에 대해 추가 연구가 필요하다.
틀린 사실을 크게 말하지 않아도 이 문단은 독자의 판단을 돕기 어려워요. 세 연구의 대상이 다르다는 단서는 있지만 그 차이가 왜 중요한지 빠져 있어요. 마지막 ‘따라서’도 앞 문장에서 도출되지 않아요. 연구가 세 편 있다는 사실은 추가 연구의 필요성이나 구체적인 공백을 증명하지 않아요.
이름을 잠시 A·B·C로 바꿔 읽으면 문제가 더 잘 보여요. A는 이것, B는 저것을 했다는 문장만 남아요. 이때 문단의 중심을 “A보다 B가 낫다”로 억지로 만들지 않고, 내가 설명해야 할 비교 축을 골라요. 이 예제에서는 대상의 수나 발표 연도보다 작업과 성과 지표의 차이가 중심이에요.
근거를 논문별 폴더에서 주장별 줄로 옮겨요
관련 연구를 쓰기 전에 작은 표에 근거를 배치했어요. “측정 단위가 다르다”는 주장 줄에는 Peng의 Study Design과 Cui의 1·2절을 함께 넣었어요. “완료에 포함하는 과정도 확인해야 한다”는 줄에는 Becker의 2.2·2.3절을 넣었어요. 연구 하나를 문단 하나로 배당하는 대신, 주장 하나에 필요한 자료를 모은 것이에요.
이때 초록의 결론만 다시 옮기지 않아요. 첫 근거는 무엇을 측정했는지, 두 번째는 어떤 업무 단위를 사용했는지, 세 번째는 시간의 종료 기준이 무엇인지 확인하는 용도예요. 논문 전체를 요약하지 않아도 해당 문장을 뒷받침하는 원문 위치가 있어야 해요. 원문 위치를 못 찾은 줄은 유려한 문장으로 채우지 않고 삭제하거나 확인 대기로 남겨요.
같은 문장을 다른 표현으로 읽었을 때도 근거가 유지되는지 원문과 대조했어요. Peng의 Study Design은 저장소 생성부터 12개 테스트를 처음 모두 통과한 커밋까지를 시간으로 잡아요. 따라서 ‘Peng은 아무런 결과 검사 없이 코딩 속도만 쟀다’는 문장은 맞지 않아요. 반면 그 테스트가 모든 코드 품질을 보증한다고 확대할 수도 없어요.
Becker 2.2.2·2.3절의 시간은 PR 검토 전후에 개발자가 일한 시간을 스스로 보고한 값이에요. PR을 올리고 병합될 때까지 흐른 달력상의 대기시간 전체라고 쓰면 다른 지표가 돼요. Cui 1절·각주4의 주간 완료 작업량을 ‘같은 과제를 몇 분 더 빨리 끝냈다’로 바꾸는 것도 피했어요. 이 세 대조는 원문 설명에서 확인한 사실이고, 그래서 숫자를 그대로 합치지 않겠다는 선택은 작성자의 판단이에요.
문헌을 비판적으로 종합하라는 원칙은 Pautasso의 문헌고찰 안내, Rule 6에서도 확인할 수 있어요. 아래 문장 번호와 역할 표시는 그 원칙을 이 예제에 적용한 편집 도구예요. 특정한 문단 길이나 다섯 문장 구조가 모든 분야의 정답이라는 뜻은 아니에요.
중심 주장 뒤에 비교 근거, 마지막에 내 목적을 놓아요
수정 문단은 이렇게 완성했어요.
AI 코딩 도구의 효과를 해석할 때에는 연구가 생산성을 어떤 작업과 지표로 정의했는지 함께 볼 필요가 있다. 표준 과제의 완료 시간을 다룬 Peng 외 연구와 기업의 주간 완료 작업량을 다룬 Cui 외 연구는 효과를 관찰하는 단위가 다르다. Becker 외 연구는 익숙한 저장소의 작업을 대상으로 검토 이후 수정까지 포함한 시간을 측정한다. 이 차이 때문에 세 연구의 효과 크기를 동일 지표의 관측값처럼 합산하지 않는다. 본 연구계획은 작은 CSV 정리 과제에서 완료 기준과 검토 시간을 명시해, 후속 효과 비교에 앞서 측정 절차의 실행 가능성을 점검하고자 한다.
첫 문장은 독자가 읽을 이유를 주고, 둘째·셋째 문장은 그 판단에 필요한 차이를 보여줘요. 넷째는 자료를 어떻게 다룰지에 대한 작성자의 판단이에요. 마지막 문장은 이번 계획의 목적이므로 선행연구가 제안한 방법처럼 인용을 붙이지 않았어요. 이 역할 구분이 있어야 독자가 사실과 해석의 경계를 찾을 수 있어요.
‘한편’, ‘반면’, ‘따라서’는 문단을 매끄럽게 만들지만 자료 사이에 없던 관계도 만들 수 있어요. 예를 들어 “Becker는 앞선 연구를 반박했다”라고 바꾸면 같은 조건의 주장을 직접 부정했다는 의미가 더해져요. 이 비교에서는 조건이 다르므로 그런 연결어를 선택하지 않았어요. “다른 작업 환경을 다뤘다” 또는 “완료 기준을 다르게 정했다”처럼 관찰한 차이를 적으면 돼요.
문장마다 인용의 일을 확인해요
검토할 때는 인용이 있다는 사실보다 무엇을 맡고 있는지 봐요. 문장 2의 두 출처는 각각의 측정 단위를 확인해 주지만, 두 연구를 합산할 수 없다는 모든 통계적 논증을 대신해 주지는 않아요. 문장 4는 현재 비교표에서 내린 제한된 판단이에요. 문장 5는 계획이므로 아직 효과가 확인되었다는 동사를 쓰지 않아요.
출처를 하나 빼도 같은 결론이 남는지 시험해요
근거표를 더 늘리는 대신, 문단에서 Becker를 사용할 수 없다고 가정해 봤어요. 실제 접근 실패가 발생했다는 뜻은 아니고, 출처 손실에 견디는 범위를 점검하는 편집 예제예요. 이때 ‘검토 이후 수정까지 포함한다’는 세 번째 문장은 함께 삭제해야 해요. 다른 두 출처를 문장 끝에 붙여 그대로 남기면 확인하지 않은 일을 그 출처에 맡기게 돼요.
범위를 줄인 완성 문단은 다음과 같아요.
AI 코딩 도구의 효과를 비교하려면 결과변수부터 구분해야 한다. 표준 코딩 과제의 완료 시간을 측정한 Peng 외 연구와 기업의 주간 완료 작업량을 분석한 Cui 외 연구는 같은 단위의 결과를 보고하지 않는다. 이 두 연구의 숫자를 동일한 시간 단축률로 취급하지 않고 각각의 지표와 조건을 제시한다. 본 계획은 작은 CSV 과제의 시작·종료와 완료 상태를 먼저 정의할 예정이다.
이 네 문장도 측정 단위 차이라는 질문에는 답해요. 다만 검토 전후 시간이라는 선행 설계와의 연결은 더 이상 설명하지 않아요. ‘세 연구’도 ‘두 연구’로 바꿔 문장과 근거 수를 맞췄어요. 편집 대안 파일 (ZIP: paragraph-alternatives.md)에 삭제 이유와 문장별 연결을 완성해 두었어요.
반대로 세 편을 모두 확인했지만 지면이 짧으면 출처를 임의로 빼기보다 목적에 맞춰 압축해요. 연구계획서에서 완료 정의를 설계하는 문단이라면 현재 다섯 문장 버전을 쓰고, 팀 보고서에서 서로 다른 숫자를 한 점수로 합산하지 말아야 하는 이유만 설명한다면 위 네 문장 버전을 쓸 수 있어요. 연구의 발전 순서가 질문일 때는 발표 연도별 구성이 맞지만, 여기서는 측정 차이를 찾으려 다시 앞뒤로 읽어야 하므로 주장별 구성을 골랐어요.
| 확인한 반례 | 원고에 내린 결정 | 독자가 남길 수 있는 결론 |
|---|---|---|
| 두 시간 연구에도 완료 사건·기록 방식 차이가 있음 | ‘단위만 같으면 합산 가능’을 쓰지 않아요. | 지표명과 함께 시작·종료·자료 수집 방식을 확인해요. |
| 첫 테스트 통과가 완료 기준인 연구가 있음 | ‘기존 연구는 검사를 안 했다’를 삭제해요. | 검사 유무와 모든 품질의 보증을 구분해요. |
| 출처 하나를 사용할 수 없음 | 그 출처에만 기대는 문장도 삭제해요. | 남은 두 지표의 비교까지만 주장해요. |
| 차이는 있지만 그 원인의 비교 자료는 없음 | ‘조건 차이 때문에 효과 방향이 바뀌었다’를 쓰지 않아요. | 관찰한 차이와 원인 가설을 구분해요. |
원문 대조와 편집 판단은 sentence-evidence.csv (ZIP: sentence-evidence.csv)의 ‘확인한 사실·허용하지 않는 확장·편집 결정’ 열에 있어요. 문장 수나 인용 개수를 통과 기준으로 삼지 않아요. 남기려는 결론에서 뒤로 돌아가 필요한 사실이 실제 원문에 있는지 확인하는 방식이에요.
자신의 문단에서도 세 단계를 반복할 수 있어요. 문단이 답할 질문을 한 줄로 적고, 그 질문에 필요한 근거만 모은 뒤, 각 연결어가 자료보다 강한 의미를 만들지 확인해요. 문헌 사이에 공통점이 없다면 하나의 문단으로 묶으려 하지 않아도 돼요. 주제가 다른 자료는 문단을 나누고, 자료가 부족한 주장에는 “확인한 자료의 범위에서는”처럼 실제 확인 범위를 밝히세요.
최종 파일에서는 문장 1~5가 모두 근거 또는 작성자 책임과 연결됐는지 확인했어요. 원문 문장을 번역해 이어 붙이지 않고 이 비교 목적에 맞춰 새 문단을 작성했어요. 2026년 10월 13일에 확인한 공개판을 기준으로 하며, 분야 전체의 관련 연구를 빠짐없이 검토했다는 뜻은 아니에요. 기여를 더 구체화해야 한다면 기여 비교표의 차이와 검증 방법을 문단 마지막 문장과 맞춰 보세요.
작성·확인: Codex가 공개 원문 또는 공식 문서를 확인하고 예제와 초안을 작성했어요. 사람을 대상으로 한 사용성 검증은 수행하지 않았어요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.