연구계획서에 “기존 연구와 차별화된다”를 썼는데, 바로 다음 문장에서 그 차이를 설명하지 못했다면 비교 대상이 아직 흐릴 수 있어요. 새로운 대상에 적용했다는 사실과 의미 있는 기여를 보였다는 판단은 한 단계 떨어져 있어요. 그 사이를 채우는 것이 이번 글의 기여 비교표예요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
예제는 초급 Python 사용자의 CSV 정리 과제에서 AI 사용 시간을 기록하려는 연구계획이에요. 앞선 설계와 연결되지만 이 글만 읽어도 사용할 수 있게 조건을 적어 둘게요. 참여자 8명, 과제 2개, 총 2주이며, 현재 목적은 효과의 우월성을 증명하는 것이 아니라 검토·수정을 포함한 측정 절차가 실행 가능한지 확인하는 일이에요. 연구 상황은 가정이며 결과는 아직 없어요.
닮은 논문을 찾아야 차이도 작고 정확해져요
초안의 문제 문장은 “기존 연구는 코딩 속도만 측정했으므로 본 연구는 최초로 검토 시간을 포함한다”였어요. 이 주장을 확인하려면 AI를 다루는 유명 논문을 넓게 모으는 것보다 완료 시간과 검토 단계를 다룬 가까운 연구를 찾아야 해요.
여기서는 Peng, Cui, Becker의 공개 논문을 비교했어요. 각 논문은 표준 코딩 과제, 기업 업무량, 기존 저장소의 작업 시간을 다루므로 제안 연구의 과제·측정·환경 축과 직접 닿아 있어요. 가까운 세 편을 고른 것은 “이 세 편 밖에는 관련 연구가 없다”는 뜻이 아니에요. 이번 표가 다루는 검색 범위를 제한한 것이에요. 문헌을 더 찾으면 표와 기여 문장이 함께 바뀔 수 있어요.
특히 Becker 외 2.2·2.3절에는 검토 이후의 수정 시간도 완료 시간에 포함된다고 설명돼 있어요. 따라서 초안의 핵심인 “최초로 검토 시간을 포함”은 유지할 수 없어요. 불리한 근거를 발견한 순간 삭제하면 연구의 의미가 사라지는 것처럼 느껴질 수 있지만, 실제로는 기여를 잘못된 전제에서 꺼내는 과정이에요.
차이의 오른쪽에 반드시 ‘무엇으로 확인할지’를 붙여요
표는 대상·과제·측정 방법을 적는 데서 멈추지 않아요. 각 차이 뒤에 왜 필요한지와 어떤 자료로 확인할지를 붙여요. 예를 들어 “대상이 초급 Python 사용자”라는 차이만으로 더 좋은 연구가 되는 것은 아니에요. 목표가 작은 분석 과제의 계측 절차라면, 처음 쓰는 도구에서 기록 누락이 얼마나 생기는지, 과제 설명의 모호함 때문에 완료 기준이 흔들리는지를 점검하는 데 그 대상이 필요하다고 설명해야 해요.
Peng 외 Study Design의 표준 과제는 완료 기준을 고정하는 비교 대상으로, Cui 외 1·2절의 업무 산출량은 우리가 측정하지 않는 장기 성과의 경계를 확인하는 대상으로 사용했어요. 원문의 결과를 길게 요약하기보다 이 연구계획의 선택에 필요한 축만 추출한 셈이에요.
완성 표에서 이번 연구의 기여 후보는 두 가지로 좁혀졌어요. 첫째, CSV 정리 과제에서 완료를 판단할 규칙과 기록 형식을 구체화해요. 둘째, 그 형식으로 실제 기록을 수집할 수 있는지 예비 단계에서 점검해요. 방법론의 근본적 새로움이나 AI 성능 향상은 이번 자료로 주장할 항목이 아니에요.
같은 총시간에서 서로 다른 다음 행동이 나오는지 확인해요
‘기록을 자세히 한다’는 설명만으로는 그 차이가 필요한지 알기 어려워요. 그래서 실제 참여자 결과 대신 총시간이 같은 두 합성 기록을 만들어 기존 방식과 제안 방식을 대조했어요. diagnostic-records.csv (ZIP: diagnostic-records.csv)의 D01·D02는 모두 09:00에 시작해 09:27에 끝나요. D01의 첫 테스트 통과는 09:18, D02는 09:09예요. 휴식은 없다고 고정했어요.
| 기록 방식 | D01에서 남는 값 | D02에서 남는 값 | 지금 할 수 있는 판단 |
|---|---|---|---|
| 시작·최종 종료만 | 27분 | 27분 | 전체 소요는 같아요. 어느 구간을 점검할지 정할 수 없어요. |
| 첫 통과 시각까지 추가 | 첫 통과 전18분 / 후9분 | 첫 통과 전9분 / 후18분 | D01은 첫 통과 전 작업을, D02는 통과 후 수정·점검을 먼저 살펴볼 단서가 생겨요. |
| 활동별 로그까지 추가 | 이 예제에는 없음 | 이 예제에는 없음 | 읽기·질문·생성 대기 중 무엇이 길었는지는 아직 몰라요. |
python3 verify-diagnostic.py를 실행해 같은 총시간 27분과 구간별 18+9, 9+18을 계산했어요. 합성 기록의 첫 통과 시각을 제거한 D03에서는 총시간은 남지만 구간을 나눌 수 없었고, 첫 통과가 종료 뒤인 D04는 잘못된 시각으로 표시했어요. 필드 추가가 유용하려면 그 필드가 기록되고 시간 순서가 맞아야 한다는 실패 조건도 함께 남긴 셈이에요. 계산 결과 (ZIP: diagnostic-result.json)에서 확인할 수 있어요.
여기서 얻은 결과는 “추가 시각이 다음 점검 대상을 구분한다”까지예요. 추가 기록이 참여자의 누락을 줄이는지, 해석을 더 정확하게 하는지는 검증하지 않았어요. 첫 통과 후 18분도 순수한 검토 시간은 아니에요. 재검사·수정이 섞이고 첫 통과 이전에도 검토가 있었을 수 있어요. 그래서 기여 후보를 ‘모든 검토 시간을 정확히 측정’으로 부풀리지 않고 ‘완료 과정의 구간을 구분할 기록 형식’으로 적었어요.
선행연구와의 독립 대조도 했어요. Becker 2.2.2·2.3절은 PR 검토 전후의 작업시간을 개발자가 보고한다고 설명해요. 우리의 첫 테스트 통과 시각은 PR 검토 시점과 같은 사건이 아니고, 두 구간 기록 자체를 처음 제안한 것도 아니에요. 기여 판정표 (ZIP: contribution-decisions.csv)는 이 근거를 보고 ‘새 시간 측정 방법’ 주장을 철회하고, 작은 과제의 정의·예외 처리를 적용 결과 후보로 남긴 기록이에요.
계획 단계와 결과 단계의 동사를 다르게 써요
계획서에는 다음처럼 쓸 수 있어요.
본 연구는 초급 Python 사용자의 CSV 정리 과제를 대상으로, 검토·수정을 포함한 완료 시간의 기록 절차를 구체화하고 예비 실험에서 실행 가능성을 점검한다. 과제별 완료 기준, 미완료 처리, 기록 누락을 함께 보고하여 후속 본 실험의 측정 설계를 보완하고자 한다.
여기서 ‘점검한다’는 계획서의 연구 목적이에요. 이미 실행한 논문의 결과 부분이라면 같은 문장만으로 충분하지 않아요. 실제 기록 완비율, 누락 원인, 수정한 절차와 근거를 채워야 해요. 기록이 16회 중 12회만 완전했다면 “계측 절차의 실행 가능성을 확인했다”로 끝내지 않고, 어떤 정보가 네 번 빠졌고 절차를 어떻게 고쳤는지 보여주어야 해요. 이 숫자는 결과 작성 방식을 설명하기 위한 가정이며 관측값이 아니에요.
기여 문장은 과장만 줄여서 완성되지 않아요. ‘검토 시간을 기록한다’가 너무 작아 보인다면, 왜 그 기록이 후속 결정에 필요한지를 붙여요. 예제에서는 총시간만 있을 때와 첫 테스트 통과·검토 종료가 나뉠 때 어떤 문제가 구분되는지 확인할 수 있어요. 다만 한 단계의 시간이 길다는 사실만으로 AI가 그 지연을 일으켰다고 설명하지는 않아요. 인과 설명에는 배정과 비교가 필요해요.
차이가 약할 때는 평가를 고치거나 범위를 줄여요
선행연구와 거의 같다는 사실이 보이면 표를 더 화려하게 만들 필요는 없어요. 재현 연구라면 같은 조건을 얼마나 충실히 재현했는지와 달라진 환경을 적는 것이 더 정확해요. 적용 연구라면 새 환경에서 실패하는 조건이나 필요한 수정이 결과가 될 수 있어요. 반대로 기존 연구와 다른 도구 이름만 넣고 평가 방법은 그대로라면 그 이름이 결과에 왜 중요할지 먼저 설명해야 해요.
방법 선택도 질문에 맞춰 달라져요. 최종 산출물까지의 시간 차이만 묻고 기록 부담이 크다면 시작·종료·완료 상태를 먼저 확보해요. 어떤 구간에서 절차를 고칠지 묻는 예비 단계라면 첫 통과 시각을 더해요. 지연이 ‘왜’ 생겼는지 설명해야 한다면 활동 로그나 인터뷰가 필요하지만, 수집·분류 자원이 없는 이번 계획에서 원인 설명을 약속하지 않아요. 앞 표의 9분과 18분은 이 선택의 정보 차이를 보여 주는 예제이지 어느 방식이 보편적으로 우월하다는 결과가 아니에요.
새 환경에 옮겼다는 차이도 모든 경우에 기여가 되지는 않아요. 같은 완료 규칙이 수정 없이 작동하고 새로 드러난 실패 조건도 없다면, 결과를 ‘새 방법’으로 유지할 이유가 약해져요. 그때는 재현·적용 기록으로 범위를 줄여요. 반대로 시각 누락 때문에 구간을 복구할 수 없다면 실행 가능성을 확인했다고 쓰지 않고 누락 원인과 수정한 기록 절차를 보고해요.
독자가 자신의 표를 만들 때는 가까운 연구마다 원문 위치를 먼저 적고, 차이마다 검증 자료 하나를 연결해 보세요. 연결할 자료가 없는 차이는 기여 확정이 아니라 가설이나 구현 특징으로 분류해요. “유일하다”나 “최초다”라는 표현이 꼭 필요하면 검색 기간·데이터베이스·검색식·포함 범위를 별도로 제시할 수 있어야 해요. 이번 예제의 제한된 조사에서는 그런 주장을 제거했어요.
contribution-matrix.csv (ZIP: contribution-matrix.csv)에는 근거 링크와 평가 연결을, claims-before-after.md (ZIP: claims-before-after.md)에는 수정 문장을 저장했어요. 완성 기준은 모든 차이에 근거와 확인 방법이 연결되고, 아직 실행하지 않은 일을 결과처럼 쓰지 않는 거예요. 2026년 10월 13일 공개판을 확인해 작성했으며, 표의 세 연구만으로 분야 전체의 새로움을 심사한 결과는 아니에요.
예제 파일을 한 번에 받아 다시 확인해요
이 글의 입력·코드·완성 자료 ZIP을 새 폴더에 풀면 R04/README.txt, replay.py, assets 폴더가 함께 생겨요. 개별 코드 파일만 저장하면 보조 모듈이나 입력이 빠질 수 있으므로 처음에는 이 묶음을 사용하세요. R04 폴더에서 다음 명령을 실행하면 본문에 사용한 검사를 순서대로 수행해요.
python3 replay.py
확인할 결과는 같은 총27분의 구간18/9·9/18, 누락·역전 기록 분리예요. 명령이 성공해도 이 값과 본문의 적용 범위를 함께 대조하세요. 실행 안내 (ZIP: README.txt)에 필요한 파일과 개별 명령을 적었어요. 실행 코드는 verify-diagnostic.py (ZIP: verify-diagnostic.py)에서 직접 볼 수 있어요. Python3.12의 표준 라이브러리를 사용하며, 명령이 실패하면 ZIP의 폴더 구조와 오류에 나온 파일부터 확인해요. 실제 앱 실행에 필요한 프로그램은 원래 설명을 따르세요.
작성·확인: Codex가 공개 원문 또는 공식 문서를 확인하고 예제와 초안을 작성했어요. 사람을 대상으로 한 사용성 검증은 수행하지 않았어요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.