컴퓨터공학과 학생이 가장 자주 던지는 질문은 이것입니다. “같은 알고리즘을 구현하면 코드가 비슷해질 수밖에 없는데, 그것도 표절인가요?” 답은 “그 자체로는 아니다”입니다. 그런데 바로 다음 질문에서 상황이 복잡해집니다. 강의 슬라이드의 예제를 그대로 쓴 것은? 공식 문서의 샘플은? 스택오버플로에서 복사한 열 줄은? 선배의 졸업작품에 있던 모듈은? AI 코딩 도구가 자동완성해 준 함수는?
이 글은 검사 도구를 피하는 방법을 다루지 않습니다. 코드에서 무엇이 표절이고 무엇이 아닌지를 가르는 기준이 어느 규범 층위에서 나오는지 정리하고, 실제로 헷갈리는 여덟 가지 상황을 하나씩 판단한 다음, 코드 주석·본문·참고문헌 세 곳에 출처를 어떻게 남기는지를 보여 줍니다. 결론은 단순합니다. 가져다 쓰는 것은 대부분 허용되고, 가져다 쓴 사실을 숨기는 것이 문제입니다.
코드 표절은 글 표절과 무엇이 다른가
산문에서는 같은 생각을 서로 다른 문장으로 쓸 수 있는 폭이 넓습니다. 코드는 그렇지 않습니다. 이진 탐색을 구현하면 누가 짜도 비슷한 형태가 나오고, 언어와 프레임워크가 강제하는 관용적 표현이 있으며, 편집기의 자동완성과 코드 포매터가 표면을 한층 더 균질하게 만듭니다. 이것을 기능적 수렴이라고 부릅니다. 기능적 수렴 구간이 겹치는 것 자체는 판정 근거가 되지 않습니다.
대신 코드 표절 판정에서 실제로 무게가 실리는 것은 다음 세 가지입니다.
- 선택의 흔적이 같은가. 반드시 그래야 할 이유가 없는데도 변수 순서, 예외 처리 방식, 매직 넘버, 주석 위치, 심지어 오타까지 같다면 그것은 우연이 아닙니다.
- 설계 결정이 같은가. 자료구조 선택, 모듈 분할 방식, 상태 관리 전략처럼 여러 대안 중 하나를 고른 지점이 통째로 일치하는 경우입니다.
- 설명할 수 있는가. 자기 코드의 특정 줄이 왜 그렇게 되어 있는지 설명하지 못하면, 유사도 수치와 무관하게 문제가 됩니다.
세 번째 항목이 가장 중요합니다. 코드 표절 상담에서 결론을 가르는 것은 도구 점수가 아니라 구두 확인입니다. 글에서 인용과 표절을 가르는 기준이 무엇인지는 인용과 표절의 차이를 정리한 가이드에서 확인할 수 있고, 코드에서도 원리는 같습니다.
나를 구속하는 규범은 세 층에서 온다
“소스코드 표절”이라는 하나의 말 아래에 성격이 다른 세 가지 규범이 겹쳐 있습니다. 어느 층의 문제인지 구분하지 못하면 대응도 어긋납니다.
1층 · 교육부 훈령 「연구윤리 확보를 위한 지침」
연구 결과물 전반에 적용되는 상위 기준입니다. 제12조 제1항 제3호는 표절을 “일반적 지식이 아닌 타인의 독창적인 아이디어 또는 창작물을 적절한 출처표시 없이 활용함으로써, 제3자에게 자신의 창작물인 것처럼 인식하게 하는 행위”로 정의하고, 그 아래에 네 가지 유형을 둡니다. 그중 나목은 “타인의 저작물의 단어·문장구조를 일부 변형하여 사용하면서 출처표시를 하지 않는 경우”, 다목은 “타인의 독창적인 생각 등을 활용하면서 출처를 표시하지 않은 경우”입니다. 변수명을 바꾸는 것은 나목에 정면으로 해당하고, 알고리즘 설계를 그대로 옮기는 것은 다목에 해당합니다. 코드라고 해서 별도의 완화 규정이 있는 것이 아닙니다.
2층 · 학교 학칙과 수업 규정
학부 과제에서 무엇이 허용되는지는 대개 이 층에서 정해집니다. 어떤 과목은 외부 라이브러리 사용을 금지하고, 어떤 과목은 협업을 장려하되 최종 코드는 각자 작성하라고 요구하며, 어떤 과목은 참조한 모든 자료를 헤더 주석에 적도록 명시합니다. 같은 학교, 같은 학기에도 과목마다 다르므로 강의계획서와 과제 공지가 1차 근거입니다. 다른 과목의 관행을 근거로 삼는 것은 통하지 않습니다.
3층 · 저작권법과 오픈소스 라이선스
이 층은 학교와 무관하게 작동합니다. 코드는 프로그램저작물이고, 오픈소스라 해도 “마음대로 써도 된다”는 뜻이 아니라 “라이선스가 정한 조건을 지키면 써도 된다”는 뜻입니다. 조건을 어기면 그것은 연구윤리 문제 이전에 라이선스 위반입니다. 학교가 문제 삼지 않아도 남는 층이라는 점이 중요합니다.
세 층은 따로 작동합니다. 한 층을 통과했다고 다른 층이 해결되지는 않습니다.
유사도 검사 도구가 실제로 보는 것
대학에서 널리 쓰이는 MOSS와 JPlag은 코드를 글자 그대로 비교하지 않습니다. 먼저 소스를 토큰 열로 바꾸어 식별자 이름, 공백, 주석 같은 표면 정보를 걷어낸 뒤, 남은 토큰 순서에서 일치하는 구간을 찾습니다. 그래서 변수명을 바꾸거나 주석을 지우거나 줄바꿈을 고치는 것은 결과를 거의 바꾸지 못합니다. 두 도구의 출력 방식은 조금 달라서 MOSS는 유사도가 높은 상위 쌍을 돌려주고, JPlag은 제출물의 모든 쌍 조합에 대한 비교 결과를 제시합니다.
이 사실이 실무에서 뜻하는 바는 하나입니다. 표면을 손질해 점수를 낮추려는 시도는 효과가 없을 뿐 아니라, 발각될 경우 “고의로 감추려 했다”는 정황으로 해석됩니다. 문장을 조금씩 바꿔 붙이는 방식이 왜 위험한지는 짜깁기 표절의 정의와 사례에 정리되어 있고, 코드에서도 판단 구조는 동일합니다. 유일하게 유효한 대응은 출처를 밝히는 것입니다.
도구는 이름을 지운 뒤의 순서를 봅니다. 표면 수정은 판정에도, 윤리에도 아무 영향을 주지 않습니다.
상황별 판단 · 실제로 헷갈리는 여덟 장면
1. 강의 슬라이드나 교재의 예제 코드
대개 사용은 허용되지만 출처 표시는 필요합니다. 과제의 목적이 그 코드를 직접 작성하는 것이라면 사용 자체가 목적에 어긋나므로, 허용 여부는 과제 공지로 확인합니다. 표시는 헤더 주석에 “OO 강의 3주차 슬라이드 예제 기반” 한 줄이면 충분합니다.
2. 공식 문서의 샘플 코드
프레임워크 공식 문서의 시작 예제처럼 널리 통용되는 상용구는 일반적 지식에 가깝습니다. 그래도 실무에서는 어느 문서의 어느 절을 참고했는지 주석으로 남기는 편이 안전합니다. 문서 자체의 라이선스가 별도로 붙어 있는 경우가 있으므로 한 번은 확인하십시오.
3. 스택오버플로 답변에서 복사한 코드
가장 자주 놓치는 지점입니다. 스택오버플로의 게시물은 크리에이티브 커먼즈 저작자표시-동일조건변경허락(CC BY-SA) 라이선스로 배포되며, 이 라이선스는 저작자 표시를 요구합니다. 한 연구에서는 이용자의 85%가 이 라이선스가 적용된다는 사실을 인지하지 못했고, 62%는 복사한 코드에 출처를 표시하지 않았다고 보고했습니다. 실무 처리는 간단합니다. 답변 URL과 작성자 이름을 주석에 남기십시오.
4. 깃허브의 오픈소스 라이브러리
라이선스 종류에 따라 의무가 다릅니다. MIT는 저작권 고지와 라이선스 전문을 사본에 포함할 것을 요구하고, 아파치 2.0은 여기에 더해 변경 사실 표시와 NOTICE 파일 처리 의무가 붙습니다. GPL 계열은 파생물을 배포할 때 동일 라이선스로 소스를 공개할 것을 요구합니다. 학위논문에 코드를 부록으로 싣거나 졸업작품을 공개 저장소에 올리는 순간 “배포”에 해당할 수 있으므로, 제출 전에 사용한 라이브러리 목록과 각각의 라이선스를 한 번 훑어보는 절차를 넣어 두는 것이 좋습니다.
5. 논문에 실린 알고리즘을 직접 구현한 경우
구현 코드는 내가 쓴 것이므로 코드 표절이 아닙니다. 다만 아이디어의 출처는 밝혀야 합니다. 훈령 제12조 제1항 제3호 다목이 정확히 이 경우를 가리킵니다. 본문에 원 논문을 인용하고, 코드 주석에도 어느 논문의 어느 절을 구현한 것인지 남기십시오.
6. 동기와 함께 디버깅하다가 받은 코드
협업 허용 범위가 과목마다 다릅니다. 개념 토론은 허용하되 코드 공유는 금지하는 과목이 많습니다. 안전한 처리는 두 가지입니다. 받은 부분을 지우고 스스로 다시 작성하거나, 협업 사실과 범위를 제출물에 명시하는 것입니다. 숨기고 제출하면 두 사람 모두 조사 대상이 됩니다.
7. 연구실 선배나 이전 기수의 졸업작품 코드
같은 연구실 자산이라 해도 저작자가 따로 있는 저작물입니다. 이어받아 개발하는 것 자체는 정상적인 연구 활동이지만, 무엇이 물려받은 부분이고 무엇이 내가 새로 만든 부분인지를 문서로 구분해야 합니다. 이 구분이 없으면 심사에서 기여도를 방어할 수 없습니다. 졸업작품에서 참고와 도용의 경계가 어디인지는 졸업작품 표절과 저작권 가이드에서 더 자세히 다룹니다.
8. AI 코딩 도구가 자동완성한 코드
생성형 코딩 도구의 출력을 그대로 쓰는 것은 훈령의 연구부정행위 목록에 별도 항목으로 들어 있지 않습니다. 문제는 두 가지 방향에서 생깁니다. 하나는 과목이나 학교가 AI 사용을 제한하는 경우이고, 다른 하나는 도구가 학습 데이터의 코드를 상당 부분 그대로 재현해 라이선스 조건을 건드리는 경우입니다. 사용했다면 범위를 적어 두고, 생성된 코드는 반드시 직접 읽고 이해한 뒤 쓰십시오. 설명하지 못하는 코드는 어떤 출처에서 왔든 위험합니다.
출처는 세 곳에 남긴다
코드 출처 표시는 논문 인용과 달리 위치가 세 군데로 나뉩니다. 하나만 해 두고 나머지를 빠뜨리는 경우가 많습니다.
- 코드 주석. 가져온 블록의 바로 위에 출처, 원저작자, 라이선스, 확인한 날짜를 넣습니다. 수정했다면 “일부 수정”이라고 덧붙입니다. 채점자가 가장 먼저 보는 자리입니다.
- 저장소 문서. README나 별도의 고지 파일에 사용한 외부 코드와 라이브러리를 라이선스와 함께 목록화합니다. MIT와 아파치 라이선스가 요구하는 고지 의무는 이 자리에서 충족됩니다.
- 논문 본문과 참고문헌. 보고서나 학위논문에 코드를 실을 때는 방법 절에 사용한 도구와 외부 코드를 서술하고, 참고문헌에 소프트웨어 항목으로 올립니다. 표기 형식은 데이터셋·소프트웨어·분석 코드 인용법에 APA와 KCI 기준으로 정리되어 있습니다.
캡스톤디자인처럼 결과보고서와 산출물을 함께 내는 과목에서는 보고서 쪽에도 같은 목록이 들어가야 합격점을 받습니다. 보고서 구성은 캡스톤디자인 결과보고서 작성법을 참고하십시오.
제출 전 자가 점검 체크리스트
- 내 코드의 모든 줄을 내가 설명할 수 있는가. 설명하지 못하는 블록이 남아 있지 않은가.
- 외부에서 가져온 블록마다 바로 위에 출처 주석이 붙어 있는가.
- 사용한 외부 라이브러리 목록과 각각의 라이선스를 확인했는가.
- GPL 계열 라이브러리를 쓴 경우, 제출·공개 방식이 그 라이선스와 충돌하지 않는가.
- 스택오버플로나 블로그에서 복사한 코드에 작성자와 URL을 남겼는가.
- 구현한 알고리즘의 원 논문을 본문에서 인용했는가.
- 협업한 부분이 있다면 범위를 명시했는가.
- AI 코딩 도구를 썼다면 사용 범위를 기록해 두었는가. 과목 규정이 이를 허용하는지 확인했는가.
- 물려받은 코드가 있다면 내 기여 부분과 구분되어 있는가.
보고서 원고 자체의 유사도까지 함께 점검하려면 제출 전에 한 번 검사를 돌려 표시 구간을 직접 읽어 보는 습관이 도움이 됩니다. 절차는 독창성 자가 점검 8단계 체크리스트에 정리되어 있습니다.
자주 묻는 질문
같은 알고리즘을 구현했더니 동기와 코드가 70% 비슷합니다. 문제가 되나요
수치 자체는 판정 근거가 아닙니다. 짧은 과제에서 표준 알고리즘을 구현하면 유사도가 높게 나오는 것이 정상입니다. 문제가 되는 것은 반드시 그럴 이유가 없는 선택이 일치할 때, 예컨대 임의의 변수 순서나 예외 처리 방식, 주석 위치, 오타까지 같을 때입니다.
변수명과 함수명을 모두 바꾸면 유사도가 내려가나요
거의 내려가지 않습니다. MOSS와 JPlag은 식별자 이름과 공백, 주석을 제거한 토큰 열을 비교하기 때문입니다. 그리고 점수가 내려간다 해도 출처를 밝히지 않은 사실은 그대로 남습니다. 훈령 제12조 제1항 제3호 나목이 바로 이 행위를 표절로 규정합니다.
깃허브 오픈소스를 쓰면 출처를 밝혀야 하나요
밝혀야 합니다. MIT는 저작권 고지와 라이선스 전문 포함을, 아파치 2.0은 여기에 변경 사실 표시와 NOTICE 처리를, GPL 계열은 파생물 배포 시 동일 라이선스 공개를 요구합니다. 오픈소스는 조건 없는 사용 허락이 아니라 조건부 사용 허락입니다.
스택오버플로 코드도 인용해야 하나요
해야 합니다. 스택오버플로 게시물은 CC BY-SA 라이선스로 배포되며 저작자 표시를 요구합니다. 답변 URL과 작성자 이름을 주석에 남기는 것으로 충분합니다.
AI가 짜 준 코드는 어떻게 표시하나요
사용한 도구와 사용 범위를 코드 주석과 보고서 방법 절에 적습니다. 다만 과목이나 학교가 AI 사용을 제한하고 있다면 표시 이전에 허용 여부부터 확인해야 합니다. 이 층위는 교육부 훈령이 아니라 학교와 담당 교수의 규정에서 나옵니다.
제출 전 독창성 자가 점검
코드와 함께 내는 보고서, 설계 문서, 논문 본문은 여전히 글입니다. 여기서 출처 없이 옮겨 온 문단이 남아 있으면 코드를 아무리 깨끗하게 정리해도 소용이 없습니다. Tesify 표절 검사기는 유사도가 높은 구간을 문장 단위로 짚어 주므로, 제출 전에 어느 문단에 출처 표시가 빠졌는지 스스로 확인할 수 있습니다. 점수를 낮추는 도구가 아니라 빠뜨린 인용을 찾는 도구로 쓰는 것이 올바른 사용법입니다.
Tesify 표절 검사기로 보고서 원고 독창성 점검하기 — 무료로 가입한 뒤 보고서를 올리고, 표시된 구간마다 출처가 필요한 문장인지 하나씩 확인해 보십시오.
정리
코드가 비슷해지는 것 자체는 문제가 아닙니다. 문제가 되는 것은 가져온 사실을 숨기는 것입니다. 교육부 훈령은 단어와 구조를 일부 변형해 쓰면서 출처를 밝히지 않는 행위와 타인의 독창적인 생각을 출처 없이 쓰는 행위를 모두 표절로 규정하고 있고, 이 규정은 산문과 코드를 구분하지 않습니다. 그 위에 과목 규정과 오픈소스 라이선스라는 두 층이 별도로 얹힙니다. 세 층 모두에 대응하는 방법은 하나뿐입니다. 주석과 저장소 문서와 참고문헌 세 곳에 출처를 남기고, 내가 쓴 모든 줄을 설명할 수 있게 해 두는 것입니다.