“코드는 완벽하게 돌아가는데 왜 논문 심사에서 자꾸 걸릴까?” 컴퓨터공학·소프트웨어 전공 대학원생이 논문 디펜스를 앞두고 가장 많이 하는 고민입니다. 일반적인 논문 디펜스 준비 조언—발표 자세를 가다듬고, 예상 질문 목록을 뽑고, 복장을 신경 쓰라—은 전공을 가리지 않고 통용되지만, 컴퓨터공학 심사위원이 실제로 던지는 질문은 다른 전공과 결이 상당히 다릅니다. 이 글은 컴퓨터공학·SW 논문 심사에서 실제로 반복적으로 나오는 질문 유형을 다섯 갈래로 나누고, 각 질문에 어떻게 답변을 준비해야 하는지 정리합니다.
일반적인 디펜스 FAQ는 “예상 질문 유형, 발표 구성, 복장”처럼 전공 무관 공통 사항을 다룹니다. 이 글은 그 공통 사항을 반복하지 않고, 컴퓨터공학·SW 전공에서만 특유하게 반복되는 실험 설계·재현성·기여도 관련 질문에 집중합니다.
왜 컴퓨터공학 심사 질문은 다른가
사회과학이나 인문학 논문 심사에서는 “이론적 함의”와 “선행연구와의 관계”가 질문의 중심이 됩니다. 반면 컴퓨터공학·소프트웨어 논문 심사위원은 결과의 재현 가능성, 비교 대상(베이스라인)의 공정성, 그리고 성능 향상의 원인을 훨씬 구체적으로 파고듭니다. 이는 이 분야의 논문이 “주장”보다 “측정 가능한 성능”으로 평가받는 문화에서 비롯됩니다. 컴퓨터공학 논문 작성법에서 다루는 기여 문장·베이스라인·절제연구의 논리가 그대로 디펜스 질문으로 이어진다고 보면 됩니다.
또한 국내 대학원 논문 심사위원 구성 자체도 이 분야에서는 실무 영향을 받습니다. 산학협력 연구가 많은 세부분야는 기업 소속 겸임교수나 외부 전문가가 심사위원으로 참여하는 경우가 있어, 학술적 엄밀성뿐 아니라 “실제로 사용 가능한가”라는 실용적 질문이 추가되기도 합니다. 심사위원 구성 기준 자체가 궁금하다면 논문 심사위원 구성 FAQ를 참고해 두면 누가, 왜 이런 질문을 던지는지 미리 감을 잡을 수 있습니다.
질문 유형 1: 베이스라인의 공정성
가장 흔하게 나오는 질문은 “왜 이 베이스라인과 비교했는가, 더 강력한 최신 기법과는 왜 비교하지 않았는가”입니다. 이 질문에 대비하려면 다음을 미리 정리해 두어야 합니다.
- 선택한 베이스라인이 해당 하위분야에서 표준으로 통용되는 이유(가장 많이 인용되거나, 공식 구현이 공개되어 재현 가능하거나).
- 더 최근 기법을 제외했다면 그 이유(공개 코드가 없음, 하드웨어 요구사항이 다름, 문제 설정이 다름 등)를 한 문장으로 설명할 수 있는가.
- 동일한 데이터 분할·전처리·하이퍼파라미터 탐색 범위를 베이스라인에도 똑같이 적용했는가.
“공정한 비교였는가”라는 질문에 즉답하지 못하고 우물쭈물하면, 이후 모든 성능 수치의 신뢰도가 흔들립니다. 발표 슬라이드에 베이스라인 선정 기준을 별도 슬라이드로 준비해 두는 것이 좋습니다.
특히 국내 학회·학술지 관행상 국문 논문에서도 베이스라인 표기는 원문 논문명을 그대로 쓰는 경우가 많은데, 이때 “왜 국내 관련 연구는 비교 대상에서 빠졌는가”라는 질문이 추가로 나올 수 있습니다. 국내 학회 발표 논문 중 관련성이 높은 연구가 있다면 간단히라도 언급하고 비교하지 않은 이유를 준비해 두는 것이 안전합니다.
질문 유형 2: 절제연구(Ablation)의 논리
“이 구성요소를 빼면 성능이 왜 떨어지는가, 그 인과관계를 어떻게 확신하는가”는 절제연구를 다룬 논문에서 거의 예외 없이 나오는 질문입니다. 절제연구 결과표를 준비할 때는 단순히 “구성요소 A를 제거하니 성능이 2%p 떨어졌다”는 수치만 제시하지 말고, 그 구성요소가 정확히 어떤 정보를 모델에 제공하는지, 왜 그 정보가 없으면 특정 하위 성능(예: 특정 클래스, 특정 조건)이 나빠지는지를 설명할 수 있어야 합니다. 성능 저하의 크기뿐 아니라 “어디서” 저하가 발생하는지에 대한 세부 분석을 요구받는 경우가 많습니다.
답변을 준비할 때 유용한 틀은 “구성요소 → 그 구성요소가 제공하는 정보 → 그 정보가 없을 때 실패하는 구체적 사례”의 3단 논리를 미리 문장으로 만들어 두는 것입니다. 예를 들어 “주의(attention) 모듈을 제거하면 전체 정확도는 2%p만 떨어지지만, 문장 길이가 긴 입력에서는 8%p까지 떨어진다”처럼 구간별 차이를 제시하면, 단순 평균 수치보다 훨씬 설득력 있는 답변이 됩니다. 이런 구간별 분석 결과를 결과 장에 표로 미리 넣어두면 질문 자체가 나오지 않는 경우도 많습니다.
질문 유형 3: 재현성과 실험 설정
“이 결과를 다른 사람이 재현하려면 무엇이 필요한가”는 최근 몇 년간 컴퓨터공학 심사에서 비중이 커진 질문입니다. 코드, 데이터, 실행 환경, 랜덤 시드, 하이퍼파라미터를 모두 공개했는지, 공개하지 않았다면 왜 그런지 답할 준비가 필요합니다. 재현성 4요소(코드·데이터·환경·시드)를 어떻게 기록해야 하는지는 컴퓨터공학·소프트웨어 논문 AI 활용법에서도 강조하는 부분이므로, 논문 작성 단계에서부터 재현성 체크리스트를 만들어 두면 디펜스에서 당황할 일이 줄어듭니다.
재현성 관련 질문에서 특히 자주 나오는 후속 질문은 “학습에 사용한 GPU와 총 학습 시간”입니다. 이는 단순한 호기심이 아니라 “이 결과를 검증하는 데 드는 실제 비용이 합리적인가”를 판단하기 위한 질문이므로, 하드웨어 사양과 대략적인 학습 시간을 슬라이드 각주에 미리 적어두는 것이 좋습니다.
질문 유형 4: 통계적 유의성과 실행 횟수
딥러닝 계열 논문에서는 “이 성능 차이가 우연한 시드 값 때문은 아닌가”라는 질문이 자주 나옵니다. 단일 실행 결과만 제시했다면 “왜 여러 번 반복 실행하지 않았는가”라는 후속 질문을 피하기 어렵습니다. 최소 3~5회 반복 실행 후 평균과 표준편차를 함께 보고하거나, 반복이 현실적으로 어려운 대규모 실험이라면 그 이유(계산 비용, 시간 제약)를 명확히 설명할 준비를 해야 합니다.
질문 유형 5: 기여의 경계와 저자성
공동 연구, 오픈소스 코드 활용, AI 코딩 보조 도구 사용이 일반화되면서 “이 논문에서 본인이 직접 기여한 부분은 정확히 무엇인가”를 명시적으로 묻는 심사위원이 늘었습니다. 서론의 기여 목록(contribution list)을 발표 자료에도 그대로 가져와, 어느 부분이 지도교수·공동연구자의 기여이고 어느 부분이 본인의 독자적 기여인지 구분해 설명할 수 있어야 합니다. AI 코딩 보조 도구를 사용했다면 그 활용 범위와 검증 절차를 밝히는 것이 최근 심사 관행에 더 안전합니다. 오픈소스 코드를 일부 가져와 수정한 경우라면 어느 파일, 어느 함수가 원본이고 어느 부분이 본인의 수정인지 구분해 설명할 수 있어야 하며, 이 경계가 모호하면 소스코드 표절 논란으로 번질 수 있습니다. 코드 인용과 표절을 가르는 기준이 궁금하다면 소스코드 표절 기준을 미리 확인해 두는 것이 좋습니다.
실전 예시: 질의응답이 실제로 어떻게 오가는가
구체적인 감을 잡기 위해, 가상의 발표 상황을 예시로 구성해 보았습니다. 실제 논문 내용과는 무관한 설명용 예시입니다.
심사위원: “제안하신 모델이 베이스라인 대비 3%p 향상되었다고 하셨는데, 이 차이가 통계적으로 유의미한 차이인지, 아니면 시드 값에 따른 우연한 편차인지 어떻게 구분하셨나요?”
바람직한 답변 예시: “다섯 개의 서로 다른 랜덤 시드로 각각 학습을 반복했고, 제안 모델의 평균 성능은 82.4%(표준편차 0.6%p), 베이스라인은 79.4%(표준편차 0.8%p)였습니다. 두 분포의 신뢰구간이 겹치지 않는 것을 확인해 우연한 편차가 아니라고 판단했습니다.”
피해야 할 답변: “한 번 돌려봤는데 3%p 차이가 나서 유의미하다고 생각했습니다.”
이 예시에서 보듯, 좋은 답변은 항상 “몇 번, 어떤 조건에서, 어떤 수치로” 확인했는지를 구체적으로 제시합니다. 발표 전에 다섯 가지 질문 유형 각각에 대해 이런 형식의 모범 답변 초안을 한두 문장씩 미리 써 두면, 실제 질의응답에서 즉흥적으로 답하는 부담이 크게 줄어듭니다.
발표 자료 구성: 질문을 미리 흡수하는 슬라이드 배치
위 다섯 유형의 질문은 발표 시간 안에 스스로 먼저 답하는 방식으로 상당수 예방할 수 있습니다. 권장하는 슬라이드 순서는 다음과 같습니다.
- 연구 문제와 기여 목록(본인의 기여 범위 명시)
- 베이스라인 선정 기준과 실험 설정
- 주요 결과(반복 실행 평균·표준편차 포함)
- 절제연구 결과와 원인 분석
- 재현성 정보(코드·데이터 공개 여부)
- 한계와 향후 연구
이 순서로 발표하면 심사위원이 굳이 묻지 않아도 될 정보를 먼저 제공하게 되어, 질의응답 시간이 훨씬 여유로워집니다.
다섯 가지 질문 유형 요약표
발표 전 최종 점검용으로 다섯 유형을 표로 정리해 두면 놓치는 부분 없이 준비할 수 있습니다.
| 질문 유형 | 핵심 질문 | 미리 준비할 것 |
|---|---|---|
| 베이스라인 공정성 | 왜 이 비교 대상을 골랐는가 | 선정 기준, 제외한 기법과 그 이유 |
| 절제연구 논리 | 왜 이 구성요소가 필요한가 | 구간별 성능 차이, 원인 설명 |
| 재현성 | 다른 사람이 재현할 수 있는가 | 코드·데이터·환경·시드 공개 여부 |
| 통계적 안정성 | 우연한 결과는 아닌가 | 반복 실행 횟수, 평균·표준편차 |
| 기여의 경계 | 본인이 직접 한 부분은 무엇인가 | 기여 목록, AI·오픈소스 활용 범위 |
이 표를 발표 리허설 직전에 한 번 훑어보며 각 칸에 자신의 논문 내용을 한 문장씩 채워 넣는 연습을 하면, 실제 질의응답에서 답변이 훨씬 매끄러워집니다.
일반 디펜스 준비와 무엇이 다른가
발표 자세, 시간 배분, 긴장 관리 같은 일반적인 디펜스 준비 요령은 전공을 가리지 않고 동일하게 적용됩니다. 다만 컴퓨터공학·소프트웨어 논문은 “왜 이 실험 설계가 타당한가”를 다투는 질문 비중이 다른 전공보다 훨씬 크기 때문에, 일반적인 구술심사 준비 가이드만으로는 충분하지 않습니다. 발표·복장·심사위원 구성 등 공통 준비사항이 궁금하다면 논문 디펜스(구술 심사) 준비 FAQ를 함께 참고하고, 이 글에서 다룬 실험 설계 관련 질문 준비를 별도로 병행하는 것을 권장합니다.
AI 활용 논문일 때 추가로 준비할 질문
AI 코딩 보조 도구를 활용해 논문을 작성했다면, “AI가 생성한 코드/문장 중 어디까지가 본인 검증을 거쳤는가”라는 질문에도 대비해야 합니다. 컴퓨터공학·소프트웨어 논문 AI 활용법에서 다루는 코드 기여 구분 원칙을 발표 전 다시 점검하고, 재현성 요소와 AI 활용 범위를 하나의 슬라이드에 함께 정리해 두면 관련 질문에 흔들리지 않고 답할 수 있습니다. Tesify로 논문 초안을 잡았다면, 어떤 문단이 AI 초안이고 어떤 부분을 직접 검증했는지 스스로 구분해두는 습관이 디펜스에서 그대로 방어 논리가 됩니다. Tesify로 논문 구조와 재현성 체크리스트 정리하기에서 서론의 기여 목록과 재현성 항목을 미리 표로 만들어두면 발표 슬라이드로 옮기는 시간도 절약됩니다.
세부분야별로 강조점이 다르다는 점도 기억하기
컴퓨터공학이라는 이름 아래에도 세부분야에 따라 심사에서 강조되는 지점이 조금씩 다릅니다. 시스템·네트워크 분야는 처리량과 지연 시간 같은 성능 지표의 측정 방법론을 까다롭게 묻는 경향이 있고, 인공지능·머신러닝 분야는 앞서 다룬 재현성과 통계적 안정성 질문의 비중이 특히 높습니다. 소프트웨어공학 분야는 사용자 연구나 설문을 병행한 경우 표본 크기와 참여자 모집 방법을 묻는 경우가 많아, 다른 사회과학 논문의 방법론 질문과 겹치는 지점도 생깁니다. 자신의 세부분야에서 최근 통과된 선배 논문의 디펜스 후기를 미리 구해 듣는 것도 실질적인 도움이 됩니다.
자주 묻는 질문
Q. 심사위원이 코드를 직접 실행해 보라고 요구하나요?
A. 흔하지는 않지만, 재현성을 강조하는 학과나 지도교수는 실제로 발표 중 코드 저장소 링크를 확인하거나 간단한 데모 실행을 요청하기도 합니다. 발표 전 저장소가 실제로 클론·실행 가능한 상태인지 반드시 점검해야 합니다.
Q. 통계적 검정을 반드시 해야 하나요?
A. 컴퓨터공학 분야 상당수 논문은 t-검정 같은 전통적 통계 검정 대신 여러 번 반복 실행한 평균과 표준편차, 또는 신뢰구간으로 성능 차이의 안정성을 보고합니다. 다만 통계 기반 평가를 관행으로 삼는 세부분야(예: 인간평가 기반 NLP 연구)라면 적절한 검정을 요구받을 수 있습니다.
Q. 베이스라인을 직접 재구현했는데 원 논문보다 성능이 낮게 나왔습니다. 어떻게 설명해야 하나요?
A. 흔히 발생하는 상황입니다. 원 논문과 하이퍼파라미터·데이터 전처리·평가 지표 정의가 정확히 일치하는지 먼저 확인하고, 차이가 있다면 그 차이를 명시하고 “동일 조건에서의 상대적 비교”라는 점을 발표에서 분명히 밝히는 것이 안전합니다. 재구현 성능이 원 논문과 다르다는 사실 자체를 숨기지 않는 것이 중요합니다.
Q. 산업체 겸임교수가 심사위원으로 들어오면 질문 성격이 달라지나요?
A. 예, 다소 달라지는 경향이 있습니다. 학계 심사위원이 방법론의 이론적 정합성을 주로 묻는다면, 산업체 출신 심사위원은 “실제 서비스에 적용했을 때의 지연 시간, 메모리 사용량, 확장성”처럼 실무적 제약 조건을 함께 묻는 경우가 많습니다. 논문에 계산 복잡도나 자원 사용량을 간단히라도 언급해 두면 이런 질문에 대비할 수 있습니다.
마지막으로, 다섯 유형 어디에도 속하지 않는 예상 밖의 질문이 나올 때의 대응 원칙도 준비해 두는 것이 좋습니다. 즉시 답이 떠오르지 않을 때는 “확인하지 못한 부분이라 정확한 답변을 드리기 어렵습니다. 후속 연구에서 다루겠습니다”라고 솔직하게 인정하는 편이, 근거 없는 추측성 답변을 내놓는 것보다 심사위원에게 훨씬 신뢰를 줍니다. 컴퓨터공학 심사위원은 모든 것을 아는 학생보다, 자기 연구의 한계를 정확히 아는 학생을 더 높이 평가하는 경향이 있습니다.
컴퓨터공학·SW 논문 디펜스는 결국 “이 실험이 왜 믿을 만한가”를 논증하는 자리입니다. 베이스라인의 공정성, 절제연구의 인과 논리, 재현성 정보, 반복 실행의 안정성, 그리고 본인의 기여 범위—이 다섯 갈래를 발표 전에 스스로 정리해두면 대부분의 질문에 침착하게 답할 수 있습니다. 위 요약표를 인쇄해 발표 리허설 때마다 옆에 두고 점검하는 것만으로도 실전 대응력이 눈에 띄게 달라집니다.