추가 연구를 2주짜리 예비 실험으로 좁히는 설계서

선행연구의 마지막 문장에 “다양한 환경에서 추가 연구가 필요하다”가 보여도, 다음 주에 무엇을 할지는 정해지지 않아요. 연구를 시작하려면 그 문장을 내가 확보할 수 있는 사람·자료·시간으로 바꾸어야 해요. 이번 글에서는 2주, 연구자 30시간과 별도로 확보한 참여자 14시간, 기본 Python을 아는 참여자 8명을 가정해 예비 설계서 한 장을 완성해요. 실제 참여자 실험을 수행한 결과는 아니에요.

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

한계에서 곧바로 가설로 뛰지 않아요

출발점은 Becker 외 연구의 4.1절이에요. 특정 개발자와 저장소 환경에서 얻은 결과를 다른 환경 전체로 옮기기 어렵다는 범위 제한을 확인할 수 있어요. 여기서 “초보자는 AI를 쓰면 빨라진다”를 결론내리면 한계를 새 사실로 바꿔 버려요. 아직 우리가 가진 것은 비교할 만한 질문이에요.

처음 떠올린 질문은 “AI가 초급 분석가의 생산성을 높이는가?”였어요. 하지만 생산성에 보고서 품질, 오류 수정, 재사용까지 모두 넣으면 2주 안에 측정하기 어려워요. 그래서 첫 예비 실험의 목적을 검토·수정을 포함한 완료 시간을 빠짐없이 측정할 수 있는지 확인하는 것으로 좁혔어요. 효과의 방향을 검토하는 본 실험은 이 절차가 작동한 다음이에요.

질문을 좁힌다고 중요한 결과를 버리는 것은 아니에요. 속도만 기록하면 품질이 낮은 빠른 답을 성공으로 세기 쉬우므로, 완료 기준에 출력 검사와 짧은 수동 점검을 붙여요. 지표를 늘리는 대신 하나의 지표가 무엇을 뜻하는지 고정하는 선택이에요.

가능한 설계 세 개를 같은 자원표에 올려요

설문은 빨리 만들 수 있지만 작업 시간을 직접 기록하지 못해 제외했어요. 실제 팀의 4주 업무를 관찰하는 안은 현실성이 높지만 이번 기간을 넘겨 보류했어요. 선택한 안은 각 참여자가 두 종류의 작은 과제를 서로 다른 조건에서 수행하는 방식이에요.

두 세션은 각각 최대 45분, 사전 안내는 15분으로 잡았어요. 참여자 시간은 8명×105분=840분, 즉 14시간이에요. 연구자가 각 세션에 한 명씩 동행한다고 가정하면 연구자에게도 진행 14시간이 필요해요. 여기에 준비 8시간과 분석 4시간을 더하면 연구자 26시간, 참여자까지 합친 인시는 40시간이에요. 연구자 예산 30시간 중 4시간을 예비로 남기는 설계예요. 두 사람의 시간이 같은 순간에 쓰였다고 인시를 한 번만 세면 안 돼요.

이 계산은 자원 배정 가정이며 실제 소요시간 관측값이 아니에요. 동의·기관 절차와 모집은 실행 전에 확보되어 있다는 조건이에요. 그 준비에도 같은 30시간을 써야 한다면 해당 비용을 더한 뒤 다시 판단해야 해요. 참여자는 협조가 확정된 인원만 세어요.

완전 자율 진행은 동행 시간을 줄일 수 있지만 누락이 생기는 순간을 관찰하기 어려워요. 지금 목적은 계측 절차 점검이므로 동행을 없애기보다 인원을 줄였어요. 4명 안은 ‘작은 효과 실험’이 아니라 기록 문제가 나타나는지 살피는 범위를 더 좁힌 선택이에요. 자원 시나리오 (ZIP: resource-scenarios.csv)를 계산한 결과이고, 실제 모집 성공률이나 일정 지연을 예측한 표는 아니에요.

‘완료’가 언제인지 과제와 함께 적어요

과제 A는 합성 CSV의 중복행 정리예요. 입력 열은 record_id, customer_id, updated_at, value이고, 같은 customer_id 안에서 유효한 최신 시각의 행을 남겨요. 동률이면 작은 record_id를 남기며, 시각을 해석할 수 없는 행은 오류 파일로 분리하도록 정했어요. 결과에는 본표와 오류표가 모두 있어야 해요.

과제 B는 합성 CSV 날짜 정규화예요. 허용 입력은 YYYY-MM-DD 또는 YYYY/MM/DD, 출력은 YYYY-MM-DD예요. 존재하지 않는 날짜나 다른 형식은 오류표로 보내요. 시간대 변환처럼 별도의 지식이 필요한 기능은 이번 과제에서 제외했어요. 두 과제가 완전히 같은 난이도라고 가정하지 않기 때문에 배정표에 과제 순서도 함께 넣었어요.

AI 조건에서도 사람이 마지막 검사를 해요. 첫 테스트 통과 시각과 수동 점검 종료 시각을 나누어 기록하고, 총시간에는 입력 읽기·질문 작성·생성 대기·검토·수정을 모두 포함해요. 수동 점검은 원본 파일 보존, 입력 행 수가 본표와 오류표의 처리 규칙에 맞는지, 동률·잘못된 날짜 사례가 예상대로 처리되는지를 확인해요. 정답 검사만 맞고 원본을 덮어쓴 경우는 완료가 아니에요.

예를 들어 합성 기록 P01은 09:00에 시작해 09:18에 첫 검사를 통과하고 09:27에 점검을 끝내요. 기록값은 총 27분, 첫 통과 이후 9분이에요. 9분은 첫 통과 후 검사·수정 구간이지 작업 중 있었던 모든 검토 시간의 합은 아니에요. 이 한 줄은 기록 양식의 완성 예제이며 AI의 효과를 보여주는 관측 결과가 아니에요. measurement-example.csv (ZIP: measurement-example.csv)에 synthetic=true를 붙였어요.

배정과 중단 조건을 결과보다 먼저 정해요

같은 문제를 AI 없이 풀고 다시 AI로 풀면 정답을 기억한 효과가 섞여요. 예제에서는 서로 다른 A·B를 쓰고 순서와 AI 조건을 네 묶음으로 균형 배정했어요. assignment.csv (ZIP: assignment.csv)에는 8명의 예정 배정이 들어 있어요. 실제 모집 시에는 동의한 참여자를 무작위로 이 자리에 배정하고, 난수 생성 방식과 도구 판본을 기록해야 해요. 현재 CSV의 P01~P08은 실제 사람의 무작위 배정 결과가 아니라 자리표예요.

AI 불허 조건에서 허용할 검색·문서·자동완성 범위도 시작 전에 설명해요. 두 조건 모두 같은 로컬 문서와 일반 검색을 허용하되 생성형 AI 사용만 구분하는 안으로 적었어요. 기능 구분이 불가능한 환경이면 별도 계정이나 도구를 마련하기보다 통제 가능한 작은 실습 환경으로 범위를 줄여요. 참가자 연구의 동의·심의 필요성도 소속 기관 기준에 맞춰 확인할 사항이에요.

예비 성공 기준은 기록 16회 중 14회 이상 완비, 과제 정의 오류 0건, 조건 위반 0건으로 두었어요. 이 숫자는 보편 기준이 아니라 현재 자원에서 정한 운영 기준이에요. 정답과 테스트가 모순되는 사례가 한 건이라도 나오면 해당 과제를 중단해 고치고, 누락 기록이 세 건 이상이면 타이머나 기록 절차를 수정해요. 45분 제한에 걸린 작업은 ‘45분에 성공’으로 바꾸지 않고 미완료로 남겨요. 성공한 작업만 평균내면 어려운 작업을 빼고 속도를 평가하게 돼요.

기록 완비와 과제 완료도 분리해요. 시작 09:00, 제한 종료 09:45, 상태 ‘미완료’, 첫 통과 없음과 사유가 모두 남았다면 기록은 완비해요. 시간 45분은 관찰한 작업 시간이고 완료 시간으로 요약하지 않아요. 반대로 완료라고 표시됐어도 검토 종료가 없으면 기록은 불완전해요. 기록 예제 네 건 (ZIP: measurement-example.csv)에는 정상 완료, 제한 종료, 종료 시각 누락, 시간 순서 오류가 들어 있어요. 모두 합성 값이에요.

기록에는 휴식 시간을 별도 숫자로 남기고 총 작업시간은 종료−시작−휴식으로 계산해요. 첫 통과 뒤 구간을 따로 계산하려면 그 구간의 휴식도 구분해야 해요. 첨부 예제는 휴식 0분으로 고정했어요. python3 verify-design.py는 자리표의 A/AI·A/NoAI·B/AI·B/NoAI가 각각 4회인지와 네 기록의 상태를 확인해요. 계산 결과 정상 완료 1건, 제한 종료 1건, 시각 누락 1건, 순서 오류 1건이며 기록 완비는 2/4예요. 이 네 건은 전체 예비 실험의 성공 판정에 쓰는 데이터가 아니에요.

인원을 4명으로 줄이면 예정 세션은 8회예요. 원래 14/16이라는 비율을 유지하려면 기록 완비 기준은 올림하여 7/8로 바꿔야 해요. 분모가 바뀌었는데 ‘14회 이상’을 유지하면 불가능한 계획이 돼요. 종료 시각 누락과 순서 오류는 원기록 확인·절차 수정을 먼저 하고, 효과가 좋아 보이도록 값을 채우지 않아요. 기록 절차나 과제를 고친 뒤에는 판본을 나눠 다시 점검해요.

이제 손에 남는 것은 “추가 연구”라는 문장이 아니라 protocol.md (ZIP: protocol.md)의 실행 전 설계예요. 본 실험에 필요한 표본 수는 이 여덟 명으로 충분하다고 정하지 않았어요. 예비 단계에서 기록의 분산과 실패 유형을 살핀 뒤 연구 질문·검정력·반복 측정 구조에 맞춰 따로 계획할 부분이에요. 참여자를 확보하지 못하면 시간 비교를 했다고 쓰지 않고, 자료와 검사 절차의 자체 점검까지만 진행하면 돼요.

2026년 10월 13일에 공개 논문을 확인하고 예제 설계 파일을 만들었어요. 사람 대상 실행과 효과 추정은 아직 하지 않았어요. 다음 기여 비교표에서는 이 작은 설계가 무엇을 보완할 수 있고 무엇을 주장할 수 없는지 정리해요.

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

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

python3 replay.py

확인할 결과는 연구자26시간·참여자14시간, 축소 설계19+7=26인시예요. 명령이 성공해도 이 값과 본문의 적용 범위를 함께 대조하세요. 실행 안내 (ZIP: README.txt)에 필요한 파일과 개별 명령을 적었어요. 실행 코드는 verify-design.py (ZIP: verify-design.py)에서 직접 볼 수 있어요. Python3.12의 표준 라이브러리를 사용하며, 명령이 실패하면 ZIP의 폴더 구조와 오류에 나온 파일부터 확인해요. 실제 앱 실행에 필요한 프로그램은 원래 설명을 따르세요.

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

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