Devin.KR

AI 개발 · 기본

AI 시대의 개발 공부 - 무엇을 배우고 어떻게 익힐까

정직하게 쓰기 - 학업 윤리·저작권·AI 사용 기록

과제·시험에서 AI 사용 규칙을 먼저 확인하기, AI 를 협업자로 밝히고 어디에 썼는지 기록하기, 생성 결과와 저작권·라이선스, 외부 코드·글을 그대로 붙이지 않기, 개인정보·비밀값을 AI 에 넣지 않기, 결과의 책임은 사람에게 있다는 점, 예시 프로그램은 AI 사용 기록 양식(날짜·용도·요청 요지·검증 방법)을 읽어 빠진 항목을 찾아 알려 준다

개발자KR · 원고 갱신

이 장에서 배우는 것

앞 장에서 버전 관리와 리뷰, 문서로 함께 일하는 방법을 살펴보았다. 함께 일할 때는 결과뿐 아니라 그 결과를 만든 과정도 설명할 수 있어야 한다. AI의 도움을 받았다면 무엇을 맡겼고, 무엇을 직접 확인했는지 밝히는 일이 그 과정에 포함된다. 코드를 빨리 얻는 능력과 코드를 정직하게 사용하는 능력은 함께 길러야 한다.

개발자의 일이 바뀌어도 판단과 책임까지 자동으로 넘어가지는 않는다. AI가 설명을 제안하고 코드를 작성하더라도, 과제 규칙을 확인하고 외부 자료의 이용 조건을 살피며 실행 결과를 검증하는 사람은 사용자다. 이 장에서는 그 판단을 짧은 기록으로 남기는 방법을 익힌다. 예시 프로그램은 기록의 빈칸을 찾는다. 기록의 진실성이나 사용 허가까지 판정하는 프로그램은 아니다.

  • 과제와 시험에서 AI 사용 규칙을 먼저 확인하고, 불분명한 부분을 질문할 수 있다.
  • AI를 작업의 협업자로 밝히고 날짜·용도·요청 요지·검증 방법을 기록할 수 있다.
  • 생성 결과와 외부 자료를 사용할 때 저작권과 이용 조건을 따로 확인할 수 있다.
  • 개인정보와 비밀값을 요청에서 덜어 내고, 결과를 직접 검증할 수 있다.
  • 짧은 Python 프로그램을 읽고 실행하여 기록에서 빠진 항목을 찾을 수 있다.

문제 상황

개발 공부를 시작한 학생이 학습 기록장을 만드는 과제를 받았다. 과제 안내에는 “외부 도움을 받은 부분을 밝힐 것”이라고 적혀 있다. 학생은 AI에게 기록을 묶는 코드를 요청했고, 제안받은 코드를 실행해 보았다. 화면에 결과가 나오자 제출할 준비가 끝났다고 생각했다.

제출 직전 친구가 묻는다. “AI로 코드까지 만들어도 되는 과제였나? 어느 부분을 직접 확인했나?” 학생은 AI 사용 자체를 숨길 생각은 없었다. 그러나 허용 범위를 확인하지 않았고, 어떤 요청을 보냈는지도 기억이 흐릿하다. 실행했다는 사실은 기억하지만 어떤 입력을 넣었는지, 예상 결과와 비교했는지는 설명하지 못한다.

여기에 또 다른 문제가 생겼다. AI에게 오류를 설명하려고 학습 기록 전체를 붙였는데, 그 안에는 친구의 이름과 연락처가 있었다. 참고한 외부 코드의 출처도 적어 두지 않았다. 프로그램이 동작한다는 사실만으로 이 문제들이 해결되지는 않는다.

실무에서도 비슷한 상황을 만난다. 팀원이 AI로 만든 수정안을 가져왔는데 사용한 자료, 입력한 정보, 확인한 범위가 남아 있지 않으면 리뷰하는 사람이 판단하기 어렵다. 짧더라도 사실에 맞는 기록이 있으면 무엇을 다시 확인해야 하는지 알 수 있다. 지금 만들 도구는 이 기록에서 기본 항목이 빠졌는지 알려 준다.

허용 범위와 책임을 먼저 확인한다

학업 윤리는 배움을 평가하는 약속을 지키는 태도다. 과제에서는 자신이 한 일을 자신이 한 만큼 설명하고, 시험에서는 정해진 도움의 범위를 지켜야 한다. AI를 쓸 수 있는지는 과목 이름이나 친구의 사용 여부만으로 결정할 수 없다. 같은 수업에서도 연습 과제와 평가 과제의 규칙이 다를 수 있다.

작업을 시작하기 전에 과제 안내와 시험 규정을 읽는다. 설명을 질문하는 것은 허용되지만 제출 코드를 생성하는 것은 제한될 수 있다. 반대로 코드 생성은 허용하되 요청과 수정 과정을 함께 제출하도록 할 수도 있다. 안내에 AI가 언급되지 않았다고 해서 허용을 뜻한다고 단정하지 않는다. 담당자에게 사용하려는 방법을 구체적으로 설명하고 확인한다.

학습 기록장 과제에서 AI에게 오류 메시지의 뜻을 질문하려 한다. 제출할 코드는 직접 작성하고, 받은 설명과 확인 과정을 기록할 예정이다. 이 방식이 허용되는지 확인하고 싶다.

질문에는 도구 이름보다 사용 범위가 중요하다. “AI를 써도 되나”보다 “오류 설명에 쓰는가, 코드 생성에 쓰는가, 제출 문장을 다듬는가”를 나누어 묻는 편이 판단에 도움이 된다. 금지된 도움을 받은 뒤 사용 사실을 밝히는 것으로 규칙 위반이 해소되지는 않는다. 공개와 허용은 각각 확인해야 한다.

사용 전과 제출 전에 확인할 질문
상황확인할 내용남길 근거
과제를 시작할 때설명·코드·문장 중 어디까지 도움을 받을 수 있는가과제 안내와 확인받은 내용
시험을 볼 때AI와 외부 자료 사용이 허용되는가시험 규정
AI를 사용한 뒤무엇을 요청했고 어느 부분에 반영했는가사용 기록과 수정 내용
제출하기 전직접 확인한 결과와 아직 확인하지 못한 부분은 무엇인가실행 결과와 비교 기록

AI를 협업자로 밝힌다는 말은 작업 과정에서 도움을 받았음을 공개한다는 뜻이다. AI를 평가의 책임자로 세우거나 사람과 같은 법적 지위로 취급한다는 뜻은 아니다. 제출자는 규칙을 지켰는지, 결과가 요구사항에 맞는지 설명해야 한다. “AI가 그렇게 답했다”는 말은 결과를 확인한 근거가 될 수 없다.

AI 사용은 규칙 확인, 허용된 도움, 직접 검증, 사용 공개의 흐름으로 진행한다

검증은 실제 결과를 확인하는 일이다. 코드를 읽어 어떤 입력을 다루는지 살피고, 실행하여 출력이 예상과 맞는지 비교하며, 빈 입력 같은 경우도 시험한다. 자신이 설명하지 못하는 부분이 있다면 그 부분을 다시 읽고 질문한다. 확인하지 못한 범위도 기록하면 다음에 할 일을 분명히 할 수 있다.

생성 결과와 입력 자료의 출처를 살핀다

저작권은 창작물의 이용과 관련된 권리다. 라이선스(license)는 자료나 코드를 어떤 조건으로 사용할 수 있는지 정한 허락의 조건이다. 인터넷에서 읽을 수 있다는 사실과 자신의 결과물에 가져다 쓸 수 있다는 사실은 다르다. 출처를 적는 일과 사용 조건을 지키는 일도 서로 대신할 수 없다.

AI가 만든 결과라고 해서 모든 부분을 자유롭게 사용할 수 있다고 단정하지 않는다. 생성 결과의 취급은 적용되는 법, 서비스의 약관, 입력 자료와 결과의 내용에 따라 확인할 사항이 달라질 수 있다. 이용 권한에 관한 서비스 안내만 읽고 외부 창작물과의 관계까지 해결되었다고 생각해서는 안 된다. 공개나 배포를 앞두고 판단이 어려운 경우에는 담당자나 관련 전문가에게 확인한다.

예를 들어 AI가 제안한 코드에 낯선 저작권 표시나 긴 주석이 포함되어 있다면 출처를 살펴볼 이유가 된다. 반대로 표시가 없다는 사실만으로 외부 자료와 무관하다고 확인된 것은 아니다. AI에게 출처를 물어서 받은 답도 확인 대상이다. 제시된 원문을 실제로 찾아 보고, 해당 자료에 붙은 이용 조건을 읽어야 한다.

외부 코드나 글을 통째로 붙여 자신의 작업으로 제출하지 않는다. 먼저 내용을 이해하고, 사용이 허용되는지 확인하며, 과제에서 요구한 출처 표시를 따른다. 문장을 몇 군데 바꾸거나 변수 이름을 바꾸는 것만으로 이 확인을 대신할 수 없다. 사용 조건을 확인하기 어렵다면 자신의 요구사항에서 출발해 새로 작성하는 방법을 선택할 수 있다.

공식 문서는 사용법과 사실을 확인하는 근거로 활용한다. 필요한 링크를 남기되, 설명 문장과 예제 코드를 통째로 옮기는 습관은 피한다. 외부 자료를 참고한 사실을 기록하면 나중에 자신의 판단과 자료에서 얻은 정보를 구분하기 쉬워진다.

자료의 출처에 따라 따로 확인할 사항
자료확인할 질문기록할 내용
AI가 생성한 코드직접 읽고 실행했는가, 출처 확인이 필요한 부분이 있는가요청 요지와 검증 결과
외부 저장소의 코드이용 조건과 표시 의무는 무엇인가원문 위치와 확인한 조건
외부 글과 그림복사·수정·배포가 허용되는가출처와 허락 또는 이용 조건
자신이 제공할 자료개인정보나 공개할 수 없는 내용이 있는가제외하거나 가상값으로 바꾼 항목

개인정보는 사람을 알아볼 수 있는 정보다. 이름과 연락처뿐 아니라 여러 정보의 조합으로 특정 사람이 드러나는 경우도 생각해야 한다. 비밀값은 다른 사람이 알면 안 되는 값으로, 비밀번호나 서비스 접근을 허용하는 키 등이 해당한다. 실무 자료에는 공개되지 않은 일정이나 내부 문서도 들어 있을 수 있다.

AI에 보낼 요청은 문제를 설명하는 데 필요한 최소한의 정보로 만든다. 실제 학생의 학습 기록 대신 가상의 기록을 넣고, 실제 계정 정보 대신 “가상 계정”이라고 표시한다. 이름만 지운 뒤 연락처나 자세한 생활 정보를 그대로 남기면 충분히 덜어 냈다고 보기 어렵다. 원본에서 일부를 가리는 것보다 필요한 구조만 가진 가상 예시를 새로 만드는 편이 분명할 때가 많다.

가상의 학습 기록 세 개를 사용한다. 실제 이름, 연락처, 계정 정보는 포함하지 않는다. 날짜·용도·요청 요지·검증 방법 중 비어 있는 항목을 찾는 방법을 설명해 달라.

민감한 내용을 이미 보냈다면 같은 내용을 더 보내며 해결하려 하지 않는다. 관련 수업이나 조직의 처리 절차를 확인한다. 노출된 접근 키처럼 실제 권한과 연결된 값은 담당자와 함께 폐기나 교체 필요성을 확인해야 한다. 사용 기록에도 원래 비밀값을 다시 적지 않는다.

사용 기록은 확인한 사실을 남긴다

기록은 길이보다 구체성이 중요하다. “AI를 사용했다”만 적으면 어디에 도움을 받았는지 알기 어렵다. “기록 검사 함수의 초안을 요청했다”라고 적으면 범위가 드러난다. “확인 완료”보다 “빈 문자열을 넣었을 때 날짜가 빠진 항목으로 표시되는지 비교했다”가 검증을 더 잘 설명한다.

이 장에서는 네 항목을 기본 양식으로 삼는다. 날짜는 사용 시점을, 용도는 도움을 받은 작업을, 요청 요지는 보낸 질문의 핵심을, 검증 방법은 사람이 확인한 행동을 적는 칸이다. 이 양식은 모든 과제에 통용되는 규정이 아니라 연습용 출발점이다. 제출 규칙에 도구 이름, 반영한 부분, 출처 등이 필요하다면 항목을 더한다.

짧아도 확인 가능한 AI 사용 기록의 예
항목기록 예시읽는 사람이 알 수 있는 것
날짜2026-10-05언제 도움을 받았는가
용도사용 기록 검사 코드의 초안어떤 작업에 도움을 받았는가
요청 요지네 필수 항목에서 빈칸을 찾도록 요청무엇을 맡겼는가
검증 방법빈 문자열과 공백만 있는 값을 실행해 예상과 비교사람이 어떻게 확인했는가

요청 요지는 대화 전체를 복사하는 칸이 아니다. 핵심 작업과 조건을 요약하면 된다. 전체 대화 제출이 요구되는 경우에는 해당 규칙을 따르되, 개인정보와 비밀값을 처음부터 입력하지 않는 것이 중요하다. 기록을 나중에 기억으로 채울 때는 불확실한 내용을 확실한 사실처럼 쓰지 않는다.

다음 프로그램은 세 개의 가상 기록을 읽는다. 여기서 읽는다는 것은 파일을 여는 대신 코드 안에 준비된 데이터를 차례로 살펴본다는 뜻이다. 날짜, 기록 개수와 순번 등 예시 프로그램 안의 숫자는 설명용 가상값이다. 고정된 데이터를 사용하므로 실행할 때마다 같은 결과가 나온다.

검사 기준은 항목이 없거나, 값이 빈 문자열이거나, 공백만 있으면 빠진 항목으로 보는 것이다. 날짜 형식이나 검증 내용의 충실성은 검사하지 않는다. 모든 값은 문자열, 즉 글자를 담는 값으로 준비되어 있다고 가정한다. 정해진 입력 범위를 이해하고 읽는 것도 코드를 검증하는 일이다.

프로그램이 찾는 빈칸과 사람이 확인해야 하는 내용의 타당성은 서로 다른 검사다

완성 코드

다음 코드를 main.py라는 이름으로 저장한다. 별도의 설치나 계정 없이 Python 3.12 이상에서 실행할 수 있다. 실행 중 입력을 받거나 네트워크에 접속하지 않으며, 준비된 기록을 검사한 뒤 종료한다.

required_fields = [
    "날짜",
    "용도",
    "요청 요지",
    "검증 방법",
]

records = [
    {
        "날짜": "2026-10-05",
        "용도": "사용 기록 검사 코드의 초안",
        "요청 요지": "네 필수 항목에서 빈칸을 찾도록 요청",
        "검증 방법": "빈 문자열과 공백 값을 실행해 예상과 비교",
    },
    {
        "날짜": "",
        "용도": "오류 메시지 설명",
        "요청 요지": "항목 이름을 잘못 썼을 때의 동작을 질문",
        "검증 방법": "",
    },
    {
        "날짜": "2026-10-06",
        "용도": "검사 조건 읽기",
        "요청 요지": "   ",
        "검증 방법": "공백만 있는 값을 넣어 빠진 항목 표시 확인",
    },
]

def find_missing(record):
    missing = []
    for field in required_fields:
        value = record.get(field, "")
        if not value.strip():
            missing.append(field)
    return missing

def main():
    print("AI 사용 기록 점검")
    incomplete_count = 0
    for number, record in enumerate(records, start=1):
        missing = find_missing(record)
        if missing:
            incomplete_count += 1
            fields_text = ", ".join(missing)
            print(f"기록 {number}: 빠진 항목 — {fields_text}")
        else:
            print(f"기록 {number}: 필수 항목이 모두 있다.")
    print(f"미완성 기록: {incomplete_count}/{len(records)}")
    print("항목이 있어도 내용의 정확성과 사용 허가는 따로 확인한다.")

main()

줄별 해설

빈 줄도 포함해 첫 줄부터 번호를 센다. 코드는 위에서 아래로 읽되, 함수의 내부는 마지막 줄에서 호출한 뒤 실행된다는 점에 주목한다. 함수는 이름을 붙여 다시 사용할 수 있게 묶은 작업이다.

  • 1행은 필수 항목을 담을 목록을 시작한다. 목록은 여러 값을 순서대로 담는 자료다.
  • 2행은 날짜를 첫 필수 항목으로 넣는다.
  • 3행은 용도를 다음 항목으로 넣는다.
  • 4행은 요청 요지를 넣는다.
  • 5행은 검증 방법을 넣는다.
  • 6행은 목록을 닫는다. 이 순서가 빠진 항목을 출력하는 순서가 된다.
  • 7행은 빈 줄이다. 필수 항목과 검사할 데이터를 구분한다.
  • 8행은 사용 기록 목록을 시작한다.
  • 9행은 첫 기록을 시작한다. 중괄호로 묶은 사전은 항목 이름과 값을 짝지어 담는 자료다.
  • 10행은 날짜라는 이름에 가상의 날짜 문자열을 연결한다.
  • 11행은 도움을 받은 용도를 적는다.
  • 12행은 요청의 핵심을 적는다.
  • 13행은 실행하고 비교한 방법을 적는다.
  • 14행은 첫 기록을 닫는다. 쉼표는 다음 기록이 이어짐을 나타낸다.
  • 15행은 두 번째 기록을 시작한다.
  • 16행은 날짜를 빈 문자열로 둔다. 따옴표 사이에 글자가 없다.
  • 17행은 오류 설명에 도움을 받았다고 적는다.
  • 18행은 어떤 동작을 질문했는지 적는다.
  • 19행은 검증 방법을 빈 문자열로 둔다.
  • 20행은 두 번째 기록을 닫는다.
  • 21행은 세 번째 기록을 시작한다.
  • 22행은 가상의 날짜를 적는다.
  • 23행은 검사 조건을 읽는 데 도움을 받았다고 적는다.
  • 24행은 요청 요지에 공백 세 개를 넣는다. 화면에서 빈칸처럼 보여도 문자열에는 공백이 들어 있다.
  • 25행은 공백 값을 시험한 방법을 적는다.
  • 26행은 세 번째 기록을 닫는다.
  • 27행은 전체 기록 목록을 닫는다.
  • 28행은 데이터를 준비하는 부분과 검사 함수를 구분하는 빈 줄이다.
  • 29행은 find_missing이라는 함수를 정의한다. record는 이 함수가 검사할 기록을 받는 이름이다.
  • 30행은 빠진 항목을 모을 빈 목록을 만든다.
  • 31행은 필수 항목을 하나씩 꺼내 field라는 이름으로 다룬다. 들여쓴 줄들이 항목마다 반복된다.
  • 32행은 기록에서 해당 항목의 값을 가져온다. get은 항목이 없을 때 두 번째 값인 빈 문자열을 돌려준다.
  • 33행은 strip으로 양끝의 공백을 제거한 결과가 비었는지 확인한다. not은 여기서 값이 비었을 때 조건이 참이 되게 한다.
  • 34행은 빠진 항목 이름을 missing 목록의 끝에 추가한다.
  • 35행은 검사가 끝난 목록을 함수 밖으로 돌려준다. 들여쓰기 위치를 보면 반복이 끝난 뒤 한 번 실행됨을 알 수 있다.
  • 36행은 두 함수를 구분하는 빈 줄이다.
  • 37행은 전체 실행을 맡는 main 함수를 정의한다.
  • 38행은 출력의 제목을 보여 준다.
  • 39행은 미완성 기록 수를 0으로 시작한다.
  • 40행은 enumerate로 기록과 순번을 함께 꺼낸다. start=1은 순번을 1부터 붙이라는 뜻이다.
  • 41행은 현재 기록을 검사 함수에 보내고, 돌려받은 목록을 missing에 담는다.
  • 42행은 빠진 항목 목록에 값이 있는지 확인한다. 빈 목록이면 이 조건은 거짓이다.
  • 43행은 미완성 기록 수를 하나 늘린다. 빠진 항목 수와 관계없이 해당 기록을 한 번 센다.
  • 44행은 빠진 항목 이름들을 쉼표와 공백으로 이어 붙인다.
  • 45행은 순번과 빠진 항목을 출력한다. 앞에 f가 붙은 문자열은 중괄호 자리에 변수의 값을 넣는다.
  • 46행은 빠진 항목이 없는 경우의 처리를 시작한다.
  • 47행은 필수 항목이 모두 있다는 결과를 출력한다.
  • 48행은 미완성 기록 수와 전체 기록 수를 출력한다. len은 목록에 담긴 값의 개수를 구한다.
  • 49행은 이 검사의 한계를 출력한다. 항목이 채워졌다는 사실과 내용이 타당하다는 판단을 구분한다.
  • 50행은 함수 정의와 실행을 구분하는 빈 줄이다.
  • 51행은 main을 호출한다. 앞에서 정의한 작업이 여기서 시작된다.

33행의 strip은 검사에 사용할 새 문자열을 돌려준다. 원래 기록에 들어 있는 문자열을 바꾸지는 않는다. 따라서 프로그램은 공백을 빈칸으로 판단하지만, 기록을 임의로 고쳐 저장하지는 않는다.

실행 결과

main.py를 저장한 폴더에서 다음 명령을 실행한다.

python3 main.py

예상 출력은 다음과 같다.

AI 사용 기록 점검
기록 1: 필수 항목이 모두 있다.
기록 2: 빠진 항목 — 날짜, 검증 방법
기록 3: 빠진 항목 — 요청 요지
미완성 기록: 2/3
항목이 있어도 내용의 정확성과 사용 허가는 따로 확인한다.

첫 기록에는 네 항목이 모두 있다. 두 번째 기록은 날짜와 검증 방법이 빈 문자열이다. 세 번째 기록의 요청 요지는 공백만 있으므로 빠진 항목으로 처리된다. 미완성 기록은 두 개다. 빠진 칸은 총 세 개지만, 프로그램이 세는 것은 빠진 칸을 가진 기록의 개수다.

출력을 확인한 뒤 작은 변경으로 검사 기준을 시험할 수 있다. 첫 기록의 날짜 항목을 통째로 지우면 get이 빈 문자열을 돌려주므로 날짜가 빠졌다고 표시된다. 반면 날짜 값을 “어제쯤”으로 바꾸면 빈칸 검사를 통과한다. 이 결과는 날짜가 올바르다는 뜻이 아니라 날짜 형식을 검사하지 않는다는 뜻이다.

실무에서 자주 틀리는 것

다음 코드는 각각 독립적으로 실행할 수 있는 짧은 비교 예다. 틀린 코드도 실행은 되지만 검사 기준이나 기록 방식이 목적에 맞지 않는다. 실행 오류만 찾는 것으로 검증이 끝나지 않는 이유다.

공백만 있는 값을 채워진 내용으로 본다

다음 코드는 빈 문자열만 비교한다. 공백 세 개는 빈 문자열과 다르므로 “항목 있음”이 출력된다.

value = "   "
if value == "":
    print("빠진 항목")
else:
    print("항목 있음")

양끝의 공백을 제거한 뒤 확인하면 “빠진 항목”이 출력된다. 검사 전에 어떤 값을 빈칸으로 볼지 정해야 한다.

value = "   "
if not value.strip():
    print("빠진 항목")
else:
    print("항목 있음")

항목 존재와 내용 존재를 혼동한다

다음 코드는 날짜라는 항목 이름만 확인한다. 값이 비어 있어도 “날짜 기록 완료”가 출력된다.

record = {"날짜": ""}
if "날짜" in record:
    print("날짜 기록 완료")

값을 꺼내 빈칸 여부를 확인하면 “날짜를 확인해야 함”이 출력된다. 이 수정 역시 날짜 형식까지 검사하는 것은 아니다.

record = {"날짜": ""}
value = record.get("날짜", "")
if not value.strip():
    print("날짜를 확인해야 함")
else:
    print("날짜 값이 있음")

빠진 항목 수를 미완성 기록 수로 센다

다음 코드는 한 기록에서 빠진 항목 두 개를 미완성 기록 두 개로 센다. 출력은 2지만, 실제로 살펴본 기록은 하나다.

missing = ["날짜", "검증 방법"]
incomplete_count = 0
incomplete_count += len(missing)
print(incomplete_count)

미완성 기록을 세려면 빠진 항목이 있을 때 한 번만 늘린다. 고친 코드의 출력은 1이다. 무엇을 세는 변수인지 이름과 동작을 함께 읽어야 한다.

missing = ["날짜", "검증 방법"]
incomplete_count = 0
if missing:
    incomplete_count += 1
print(incomplete_count)

하지 않은 검증을 기록 문장으로 채운다

다음 코드는 검증 방법이 비어 있다는 이유로 확인하지 않은 내용을 자동으로 넣는다. 프로그램은 실행되지만 기록은 실제 행동과 어긋난다. 이 예에서는 검증을 수행하지 않았다고 가정한다.

record = {"검증 방법": ""}
if not record["검증 방법"]:
    record["검증 방법"] = "실행 확인 완료"
print(record["검증 방법"])

고친 코드는 빈칸을 알리고 실제 확인을 요구한다. 이후 실행과 비교를 수행한 사람이 그 사실을 적어야 한다. AI가 그럴듯한 검증 문장을 만들어 주어도 실제 행동을 대신하지 못한다.

record = {"검증 방법": ""}
if not record.get("검증 방법", "").strip():
    print("실제로 확인한 방법을 기록해야 한다.")

한눈에 보기

정직한 AI 사용을 위해 사람이 맡을 판단
주제할 일판단의 한계
과제·시험 규칙사용 전에 허용 범위를 확인한다사용 사실 공개만으로 허가를 대신하지 못한다
사용 공개도움받은 부분과 직접 확인한 부분을 밝힌다AI에게 결과의 책임을 넘길 수 없다
외부 자료출처와 이용 조건을 확인한다출처 표시만으로 모든 이용이 허용되지 않는다
입력 정보개인정보·비밀값을 제외하고 가상 예시를 쓴다일부 정보만 가려도 사람이 드러날 수 있다
기록 검사누락·빈 문자열·공백 값을 찾는다사실성·날짜 형식·허용 여부는 별도 판단이다
결과 검증읽기·실행·예상 결과 비교를 수행한다한 번 실행했다고 모든 경우가 확인되지는 않는다

사용 기록은 자신의 기여를 줄이는 문서가 아니다. 무엇을 맡기고 무엇을 판단했는지 설명하는 근거다. 다음 장에서 과정을 보여 주는 포트폴리오를 만들 때도 이러한 기록이 출발점이 된다.

연습 문제

  1. 두 번째 기록의 날짜에 “2026-10-05”를 넣고 검증 방법은 그대로 둔다. 각 기록의 검사 결과와 미완성 기록 수가 어떻게 달라지는지 실행 전에 예상하라.
  2. 세 번째 기록에서 요청 요지 항목을 값까지 포함해 통째로 삭제한다. 프로그램이 오류 없이 빠진 항목을 찾는 이유를 설명하고 실행하여 확인하라.
  3. 첫 기록의 검증 방법을 “확인함”으로 바꾼다. 프로그램이 이 값을 통과시키는 이유와 사람이 추가로 확인할 내용을 설명하라.
  4. 한 과제는 AI의 개념 설명만 허용하고 코드 생성은 허용하지 않는다. 학생이 코드 초안을 받은 뒤 사용 사실을 공개하려 한다. 필요한 대응을 설명하고, 앞으로 허용된 설명 도움을 받을 때 남길 네 항목의 기록을 작성하라.

정답과 해설

  1. 첫 기록은 그대로 필수 항목이 모두 있다. 두 번째 기록의 빠진 항목은 검증 방법만 남는다. 세 번째 기록은 요청 요지가 빠져 있다. 미완성 기록 수는 여전히 2/3이다. 날짜 한 칸을 채웠지만 두 번째 기록에는 다른 빈칸이 남아 있기 때문이다. 실제 출력과 예상이 같은지 비교한다.
  2. 32행의 get은 요청 요지라는 항목이 없으면 빈 문자열을 돌려준다. 33행은 이를 빈칸으로 판단하고 항목 이름을 목록에 넣는다. 따라서 세 번째 기록의 출력은 이전과 같다. 항목이 없는 경우와 값이 공백뿐인 경우를 같은 기준으로 처리하는 것이다.
  3. “확인함”은 공백을 제거해도 글자가 남으므로 빈칸 검사를 통과한다. 사람이 어떤 입력을 실행했는지, 무엇을 예상했는지, 실제 출력과 어떻게 비교했는지를 추가로 확인해야 한다. 실제 확인을 하지 않았다면 문장을 자세하게 고치는 것으로 끝낼 수 없다. 먼저 검증을 수행해야 한다.
  4. 사용 사실 공개와 허용 범위 준수는 별개다. 받은 초안을 제출에 사용하기 전에 담당자에게 상황을 사실대로 설명하고 처리 방법을 확인해야 한다. 앞으로는 허용된 개념 설명 범위에서 질문한다. 예를 들어 날짜는 “2026-10-07”, 용도는 “공백 검사 개념 이해”, 요청 요지는 “공백만 있는 문자열이 빈 문자열과 어떻게 다른지 설명 요청”, 검증 방법은 “허용된 연습 코드에서 두 값을 실행해 비교”로 기록할 수 있다. 날짜는 가상 예시이며 검증 방법은 실제로 수행했을 때만 적는다.
오탈자·오류 제보 비공개로 접수되어 원고 수정에 반영됩니다

이메일 등 개인정보는 받지 않습니다. 답변이 필요한 질문은 아래 댓글을 이용해 주세요.

READER FEEDBACK

질문·의견

내용에 관한 질문이나 더 나은 설명을 위한 의견을 남겨 주세요. 오탈자는 위의 제보 양식이 더 빨리 반영됩니다. 이 댓글은 원래 게시글과 같은 자리에 쌓입니다.

댓글 0

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

댓글을 남기려면 로그인이 필요합니다.