Devin.KR

AI 개발 · 기본

바이브 코딩 시대의 기본서 - 처음 AI 와 함께 만드는 프로그램

맡기면 안 되는 것 - 개인정보·비밀번호·저작권

AI 도구에 붙여 넣으면 안 되는 정보, 코드 속 비밀번호·API 키, 남의 코드와 라이선스, 학교 과제와 AI 사용 기록, 완성 코드는 문자열 묶음에서 이메일·전화번호·키처럼 보이는 값을 정규식으로 찾아 가리는 검사기

개발자KR · 원고 갱신

이 장에서 배우는 것

앞 장에서 작업한 내용을 저장하고 이전 상태로 되돌리는 습관을 익혔다. 그러나 저장한 파일 안에 다른 사람의 연락처나 서비스 접속 비밀번호가 들어 있다면, 버전을 남기는 것만으로 해결되지 않는다. 무엇을 저장할지, 무엇을 AI 도구에 보낼지 먼저 결정해야 한다. 한 번 보낸 정보는 내 컴퓨터의 파일을 지운다고 함께 지워지는 것이 아니기 때문이다.

이 장에서는 AI에게 도움을 요청하기 전에 정보의 경계를 정한다. 개인정보와 비밀번호를 구별하고, 남의 코드에 붙은 사용 조건을 확인하며, 학교 과제에서 AI의 도움을 받은 범위를 기록한다. 마지막에는 문자열 묶음에서 이메일·전화번호·키처럼 보이는 값을 찾아 가리는 작은 검사기를 만든다. 검사기는 검토를 돕는 도구다. 출력에 표시가 없다는 이유만으로 전송해도 된다고 판단하지 않는다.

  • AI에게 보낼 자료에서 빼야 할 정보와 가짜 값으로 바꿀 정보를 구별한다.
  • 코드 속 비밀번호와 API 키가 왜 특별히 조심해야 할 값인지 설명한다.
  • 남의 코드의 라이선스와 학교 과제의 AI 사용 규칙을 확인한다.
  • 정규식으로 일부 정보를 가리고, 예시 검사와 변경 내용 검토로 동작을 확인한다.

문제 상황

동아리 신청 명단을 정리하던 사람이 이메일 주소를 검사하는 프로그램을 만들고 있다. 프로그램이 예상과 다르게 움직이자 명단과 코드 전체를 AI 대화창에 붙여 넣으려 한다. 명단에는 회원의 이름과 전화번호가 있고, 코드에는 시험 삼아 연결한 서비스의 접속 키가 있다. 파일 맨 아래에는 다른 사람이 공개한 예제 코드도 붙어 있다.

질문은 “이메일 주소를 잘못 찾는 이유를 알려 달라”다. 이 질문에 실제 회원의 연락처나 서비스 접속 키는 필요하지 않다. 문제가 생기는 모양을 보여 주는 가짜 주소 몇 개면 충분할 수 있다. 남의 예제 역시 공개되어 있다는 사실만으로 자유롭게 다시 배포할 수 있는 것은 아니다. 자료 전체를 보내기 전에 질문에 필요한 부분을 새로 구성해야 한다.

이메일 주소를 찾는 부분을 확인해 달라. 아래 자료는 실제 명단이 아니라 문제를 재현하도록 만든 가짜 예시다. 이름과 연락처를 추가로 요구하지 말고, 이 예시에서 잘못되는 이유와 확인 방법을 설명해 달라.

이 요청문은 실제 자료 대신 재현용 자료를 쓰겠다는 경계를 담고 있다. 다만 요청문에 개인정보를 넣지 말라고 적었다고 해서 이미 붙여 넣은 개인정보가 사라지는 것은 아니다. 보내기 전에 자료 자체를 바꾸어야 한다. 질문에 필요하지 않은 열은 지우고, 필요한 값도 같은 문제를 보여 주는 가짜 값으로 바꾼다.

보내기 전에 정보의 경계를 정한다

개인정보는 사람을 알아볼 수 있게 하는 정보다. 이름이나 이메일처럼 바로 눈에 띄는 정보뿐 아니라, 반·날짜·특정 사건을 함께 놓았을 때 누구인지 짐작할 수 있는 내용도 주의해서 다뤄야 한다. 이름만 지운 상담 기록에 학년과 드문 사건이 그대로 남아 있다면, 주변 사람이 당사자를 알아볼 수 있다.

실제 자료를 가짜 자료로 바꿀 때는 문제와 관련된 형태만 남긴다. 공백 때문에 오류가 난다면 가짜 주소 앞뒤에도 공백을 넣는다. 같은 사람이 두 번 등장해서 문제가 생긴다면 같은 가짜 이름을 두 번 쓴다. 실제 정보가 아니라 오류를 일으키는 구조를 보존하는 것이다. 이렇게 필요한 부분만 남기면 AI의 설명을 스스로 확인하기도 쉬워진다.

AI에게 보낼 자료를 줄이는 판단 예시
발견한 정보보내기 전 처리남겨 둘 내용
회원의 이름과 연락처불필요한 항목은 삭제하고 필요한 값은 가짜 값으로 바꾼다.중복, 공백, 구분자처럼 문제와 관련된 모양
개인 상담과 건강 관련 내용원문을 제외하고 질문에 필요한 상황만 새로 작성한다.개인을 짐작하게 하지 않는 재현 조건
비밀번호와 접속 키값을 제거하고 용도를 나타내는 표시로 바꾼다.값을 읽는 코드와 오류의 구조
내부 문서와 남의 코드공유 권한과 사용 조건을 먼저 확인한다.허용된 범위의 설명 또는 직접 만든 작은 예시

AI 도구가 대화를 저장하는지, 조직에서 어떤 자료의 전송을 허용하는지는 사용 환경에 따라 다르다. 개인 계정인지 조직에서 관리하는 계정인지도 구별해야 한다. 이 장에서는 특정 제품의 설정에 기대지 않고, 질문을 해결하는 데 필요한 최소한의 가짜 자료를 준비하는 방법을 기본으로 삼는다. 비공개 저장소나 개인 대화창이라는 이유만으로 자료를 보내도 된다고 판단하지 않는다.

실제 자료에서 필요한 모양만 남기고 가짜 값으로 바꾼 뒤 사람이 확인하고 보낸다

비밀번호와 키는 코드에서 분리한다

비밀번호는 사람이나 프로그램이 접근 권한을 증명할 때 쓰는 값이다. API 키는 프로그램이 다른 서비스의 기능을 요청할 때 제시하는 접속 값이다. API는 프로그램끼리 기능이나 데이터를 주고받는 약속을 뜻한다. 키마다 허용된 권한은 다르지만, 키를 가진 사람이 그 권한을 사용할 수 있다는 점에서 일반적인 예시 문자열과 다르다.

코드에 키를 직접 적으면 파일을 복사하거나 변경 내용을 공유할 때 키도 함께 이동한다. 현재 파일에서 지웠더라도 앞서 저장한 버전이나 대화 기록에는 남아 있을 수 있다. 값이 들어 있는 줄만 가리고, 그 줄의 설명이나 실행 결과에 같은 값을 다시 적는 실수도 생긴다. 코드, 출력, 화면 사진을 같은 기준으로 살펴야 한다.

실제 프로그램에서는 비밀 값을 코드와 분리해 실행 환경에서 전달하는 방법을 쓸 수 있다. 환경 변수는 프로그램을 실행할 때 바깥에서 전달하는 이름과 값이다. 다만 환경 변수로 옮겼다는 사실이 모든 문제를 해결하지는 않는다. 프로그램이 그 값을 출력하면 다시 노출될 수 있다. 이 장의 검사기는 실제 키를 사용하지 않으며, 네트워크에도 연결하지 않는다.

실제 비밀번호나 키를 이미 보냈다면 대화에서 값을 지우는 것만으로 끝내지 않는다. 해당 서비스에서 비밀번호를 바꾸거나 키를 폐기하고 새로 발급하는 조치를 취한다. 조직의 값이라면 담당자에게 노출 범위를 알리고 정해진 절차를 따른다. 기록 삭제와 권한 무효화는 서로 다른 일이다. 이 구별은 코드를 고치는 것보다 먼저 알아야 할 경계다.

남의 코드와 내 작업의 출처를 남긴다

라이선스는 저작물을 어떤 조건으로 사용할 수 있는지 정한 허락이다. 인터넷에서 코드가 보인다고 해서 수정·복사·배포가 모두 허용되는 것은 아니다. 코드를 가져오기 전에 설명 페이지와 라이선스 파일을 확인한다. 출처 표시, 저작권 안내 유지, 변경한 코드의 공개 등 요구 사항은 라이선스마다 다르다. 출처를 적는 것과 사용 허락을 얻는 것도 별개의 문제다.

AI가 “자유롭게 써도 된다”고 답해도 그것만으로 허락이 생기지는 않는다. 출처나 조건을 확인할 수 없다면 그 코드를 그대로 포함하지 않고, 필요한 동작을 말로 정리해 직접 구현하는 쪽을 택할 수 있다. 다만 표현만 바꾼 재작성으로 원래 코드의 사용 조건을 피할 수 있다고 생각해서는 안 된다. 판단이 어려운 자료는 배포 전에 권한을 확인한다.

학교 과제에서는 교사가 정한 AI 사용 범위를 먼저 읽는다. 아이디어 정리는 허용하지만 코드 생성은 금지하는 과제도 있을 수 있다. 규칙이 모호하면 과제 담당자에게 허용 범위를 확인한다. AI 사용 기록을 남겼다는 사실이 금지된 사용을 허용해 주지는 않는다. 허용된 경우에는 무엇을 맡겼고, 무엇을 직접 확인하고 고쳤는지 기록한다.

AI 사용 기록: 가짜 문자열을 검사하는 정규식의 후보를 요청했다. 받은 코드를 실행해 이메일·전화번호·연습용 키의 치환 결과를 확인했다. 실제 연락처는 입력하지 않았다. 주소의 일부만 가려지던 부분을 수정하고 변경 전후를 비교했다.

기록에는 도구 이름, 사용 날짜, 도움받은 범위, 직접 검증한 내용을 적을 수 있다. 과제에서 요구하는 양식이 있다면 그 양식을 따른다. 대화 전체를 제출해야 하는 경우에도 대화에 다른 사람의 개인정보나 비밀 값이 들어 있지 않은지 확인한다. 증거를 남기려다가 불필요한 정보를 함께 공유하지 않도록 한다.

완성 코드

이제 전송 전에 일부 값을 가리는 검사기를 만든다. 정규식은 문자열에서 찾을 모양을 규칙으로 적는 표현이다. 여기서는 흔한 이메일 모양, 국내 휴대전화 번호 모양, 정해 둔 연습용 키 모양을 찾는다. 이름·주소·상담 내용이나 세상의 모든 키 형식을 알아내는 프로그램은 아니다.

아래 프로그램을 main.py로 저장한다. 예시의 이메일은 예시용 도메인을 쓰며, 전화번호와 키도 실습용으로 만든 값이다. 키의 앞부분인 sk-demo-와 api_demo_는 이 프로그램이 정한 표식이다. 실제 서비스의 키 형식을 뜻하지 않는다. 검사기는 원문을 화면에 출력하지 않고 가린 결과와 발견 개수만 보여 준다.

import re

LABELS = {
    "email": "이메일",
    "phone": "전화번호",
    "key": "연습용 키",
}

PATTERNS = {
    "email": r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}",
    "phone": r"(?<!\d)01[016789][ -]?\d{3,4}[ -]?\d{4}(?!\d)",
    "key": (
        r"(?<![A-Za-z0-9_])(?:sk-demo-|api_demo_)"
        r"[A-Za-z0-9]{16,}(?![A-Za-z0-9_])"
    ),
}

RULE = re.compile(
    "|".join(f"(?P<{name}>{pattern})" for name, pattern in PATTERNS.items())
)


def mask_text(text):
    counts = {name: 0 for name in LABELS}

    def replace(match):
        name = match.lastgroup
        counts[name] += 1
        return f"[{LABELS[name]}]"

    masked = RULE.sub(replace, text)
    return masked, counts


def check_examples():
    cases = [
        ("문의: learner@example.com", "문의: [이메일]", (1, 0, 0)),
        ("연락: 010-0000-0000", "연락: [전화번호]", (0, 1, 0)),
        ("키: sk-demo-ABCDEFGHIJKLMNOP", "키: [연습용 키]", (0, 0, 1)),
        ("키: api_demo_1234567890ABCDEF", "키: [연습용 키]", (0, 0, 1)),
        ("개수: 3", "개수: 3", (0, 0, 0)),
    ]
    for original, expected, expected_counts in cases:
        masked, counts = mask_text(original)
        assert masked == expected, "가림 결과 확인 필요"
        actual_counts = tuple(counts[name] for name in LABELS)
        assert actual_counts == expected_counts, "발견 개수 확인 필요"


def main():
    check_examples()
    print("예시 검사: 통과")
    texts = [
        "문의: learner@example.com",
        "연락: 010-0000-0000",
        "키: sk-demo-ABCDEFGHIJKLMNOP",
        "메모: 모임은 수요일이다.",
    ]
    totals = {name: 0 for name in LABELS}
    for number, text in enumerate(texts, start=1):
        masked, counts = mask_text(text)
        print(f"{number}. {masked}")
        for name in LABELS:
            totals[name] += counts[name]
    summary = ", ".join(f"{LABELS[name]} {totals[name]}개" for name in LABELS)
    print(f"발견: {summary}")
    print("주의: 표시가 없어도 직접 검토해야 한다.")


if __name__ == "__main__":
    main()

AI에게 같은 프로그램을 요청한다면 조건과 확인 예시를 함께 준다. 정규식만 만들어 달라고 하면 어떤 범위를 찾는지 불분명한 코드가 나올 수 있다. 실제 자료 없이도 요구 사항과 검사 기준을 충분히 전달할 수 있다.

Python 표준 라이브러리만 사용해 문자열 목록을 검사하는 main.py를 만들어 달라. 이메일, 국내 휴대전화 번호, 내가 지정한 연습용 키를 표시로 바꾸고 종류별 개수를 출력한다. 원문은 출력하지 않는다. 실제 키 탐지를 보장한다고 설명하지 않는다. 가짜 입력으로 치환 결과와 개수를 검사하고, 마지막에 사람이 다시 검토해야 한다는 문장을 출력한다.

줄별 해설

첫 줄의 import re는 정규식을 처리하는 표준 라이브러리를 불러온다. 별도로 설치할 패키지는 없다. LABELS는 내부에서 쓰는 이름과 화면에 보여 줄 이름을 연결한다. 이렇게 이름과 값을 연결한 자료를 딕셔너리라고 한다. email을 찾았을 때 화면에는 이메일이라는 이름을 쓰도록 정한 것이다.

PATTERNS도 딕셔너리다. 각 값에는 찾을 모양이 들어 있다. 문자열 앞의 r은 역슬래시를 많이 쓰는 정규식을 적기 편한 표기다. 이메일 규칙의 대괄호는 허용할 문자 범위를 나타내고, +는 앞의 모양이 한 번 이상 이어짐을 뜻한다. \.은 주소 속의 점 하나를 찾는다. 이 규칙은 주소처럼 생긴 문자열을 찾을 뿐, 실제로 메일을 받을 수 있는 주소인지 확인하지 않는다.

전화번호 규칙의 \d는 숫자 한 자리를 뜻한다. {3,4}는 세 자리 또는 네 자리라는 뜻이다. [ -]?는 공백이나 붙임표가 없거나 한 번 있는 경우를 허용한다. 앞뒤의 숫자 경계 조건은 더 긴 숫자의 일부를 전화번호로 잡는 일을 줄인다. 국제전화 표기, 괄호가 있는 표기, 집 전화번호까지 모두 처리하지는 않는다.

키 규칙은 정해 둔 접두사 뒤에 영문자나 숫자가 열여섯 자리 이상 이어지는 값을 찾는다. 두 줄로 나눈 문자열은 괄호 안에서 하나로 이어진다. 이 길이와 접두사는 실습 규칙이다. 다른 접두사, 밑줄을 포함하는 값, 일반적인 비밀번호는 놓칠 수 있다. 코드에서 key라는 이름을 쓴다고 실제 비밀 값을 전부 구별하게 되는 것은 아니다.

RULE을 만드는 부분은 세 규칙에 이름을 붙이고 |로 연결한다. |는 여러 후보 중 하나를 찾게 한다. re.compile은 이 표현을 검색에 쓸 규칙으로 준비한다. 한 위치에서 여러 후보가 맞으면 앞에 놓인 후보가 선택될 수 있다. 예시 검사뿐 아니라 규칙이 겹칠 만한 입력도 살펴야 하는 이유다.

def로 시작하는 줄은 여러 줄의 작업을 함수라는 이름으로 묶는다. mask_text는 문자열 하나를 받아 가린 문자열과 개수를 돌려주는 함수다. counts를 만드는 줄은 종류마다 개수를 0으로 준비한다. 그 안의 replace 함수는 찾은 값 하나를 어떤 표시로 바꿀지 정한다. match.lastgroup으로 맞은 규칙의 이름을 얻고, 해당 개수를 하나 늘린 뒤 [이메일] 같은 문자열을 반환한다.

RULE.sub는 발견한 부분마다 replace를 호출해 새 문자열을 만든다. 원래 문자열 자체를 고치는 것이 아니라 결과를 새로 돌려준다. return 뒤의 masked, counts는 결과 두 개를 함께 돌려준다는 뜻이다. 받는 쪽에서도 masked, counts처럼 두 이름으로 나누어 받을 수 있다.

check_examples의 cases에는 입력, 기대하는 문자열, 기대하는 개수를 함께 적었다. 세 개의 숫자는 이메일·전화번호·연습용 키 순서다. for는 예시를 하나씩 꺼내 반복한다. assert는 뒤의 조건이 참인지 확인하고, 거짓이면 실행을 멈춘다. 원문이 오류 메시지에 다시 노출되지 않도록 실패 설명도 고정 문장으로 적었다. 이 검사는 예시 다섯 개에 대한 확인이며 전체 탐지 범위를 증명하지 않는다.

main은 예시 검사를 먼저 실행하고 실습 문자열을 처리한다. enumerate는 문자열과 함께 순번을 제공한다. start=1은 첫 순번을 1로 정한다. f가 붙은 문자열은 중괄호 안의 값을 글자 사이에 넣는다. 각 줄을 처리한 뒤 종류별 개수를 totals에 더하고, join으로 요약 문구를 연결한다. 마지막 조건문은 이 파일을 직접 실행할 때 main을 호출한다.

실행 결과

main.py를 저장한 폴더에서 터미널에 다음 명령을 입력한다. 파일을 저장만 하고 실행하지 않으면 정규식이나 출력이 맞는지 확인할 수 없다.

python3 main.py

정상적으로 실행하면 다음 결과가 나온다. 현재 시각, 외부 파일, 네트워크에 의존하지 않으므로 같은 코드의 출력은 같다.

예시 검사: 통과
1. 문의: [이메일]
2. 연락: [전화번호]
3. 키: [연습용 키]
4. 메모: 모임은 수요일이다.
발견: 이메일 1개, 전화번호 1개, 연습용 키 1개
주의: 표시가 없어도 직접 검토해야 한다.

이 결과에서 확인할 것은 세 가지다. 가려야 할 가짜 값이 표시로 바뀌었는지, 종류별 개수가 맞는지, 일반 메모가 그대로 남았는지를 본다. 통과라는 문구만 읽지 말고 기대 출력과 실제 출력을 비교한다. AI가 코드를 수정했다면 변경 전후 차이도 확인한다. 변경 전후의 차이를 보여 주는 비교를 diff라고 한다. 정규식 수정 외에 원문을 출력하는 줄이 추가되지는 않았는지도 살핀다.

다섯 예시가 통과해도 놓치는 값은 있다. 예를 들어 사람의 이름이나 접두사가 없는 비밀번호는 이 규칙에 해당하지 않는다. 영문자와 숫자만으로 만든 규칙은 다른 문자로 된 이메일 주소도 놓칠 수 있다. 반대로 연락처가 아닌 예시 문자열을 가릴 수도 있다. 따라서 탐지하지 못한 경우와 필요 이상으로 가린 경우를 모두 확인해야 한다.

예시 검사 통과는 정한 예시의 일치만 뜻하며 전송 전 원문과 결과를 사람이 다시 검토해야 한다

실무에서 자주 틀리는 것

가린 문자열을 만들고 원문을 출력한다

다음 코드는 주소를 가린 결과를 만들었지만 마지막 줄에서 원문을 출력한다. 변수 이름을 대충 훑으면 놓치기 쉽다. 실제 비밀 값으로 시험하지 말고 아래처럼 가짜 값으로 출력까지 확인한다.

text = "문의: learner@example.com"
masked = text.replace("learner@example.com", "[이메일]")
print(text)

출력할 대상을 masked로 고친다. 완성 코드에서는 정규식을 쓰지만, 결과를 담은 변수를 출력해야 한다는 원칙은 같다.

text = "문의: learner@example.com"
masked = text.replace("learner@example.com", "[이메일]")
print(masked)

발견 개수가 0이면 전송해도 된다고 판단한다

다음은 잘못된 판단을 작은 코드로 나타낸 예다. 검사기가 아무것도 찾지 못했어도, 규칙에 없는 이름이나 내부 내용이 남아 있을 수 있다.

found_count = 0
if found_count == 0:
    print("전송 가능")

발견 개수는 검사 결과로만 보고한다. 실제 전송 여부는 자료의 출처와 공유 권한, 남아 있는 내용을 함께 검토해 결정한다.

found_count = 0
print(f"규칙으로 발견한 값: {found_count}개")
print("전송 전 내용과 공유 권한을 직접 확인한다.")

사용하지 않는 키는 코드에 남겨도 된다고 생각한다

아래 값은 실행을 위한 연습용 가짜 문자열이다. 실제 키를 이런 자리에 적은 뒤 “지금은 쓰지 않는 줄”이라며 남겨 두는 습관을 피해야 한다. 파일이 공유되면 실행 여부와 관계없이 문자열을 읽을 수 있다.

service_key = "sk-demo-ABCDEFGHIJKLMNOP"
print("문자열 예시 준비 완료")

접속이 필요 없는 설명용 코드라면 키 값 자체를 빼고 목적만 남긴다. 실제 접속 프로그램에서 값을 외부로 분리하는 작업과, 이미 노출된 키를 폐기하는 작업도 구별한다.

service_key = None
print("이 예시는 서비스에 접속하지 않는다.")

여기서 None은 값이 없음을 나타낸다. 현재 파일의 한 줄을 지웠다는 사실만으로 앞서 공유한 파일이나 저장 기록까지 정리되었다고 판단하지 않는다.

AI의 설명을 사용 허락으로 기록한다

다음 코드는 출처 확인을 마친 것처럼 기록하지만 실제 확인 근거가 없다. AI의 답변은 원저작자의 허락이나 과제 규칙을 대신하지 못한다.

source_note = "AI가 사용 가능하다고 답함"
license_checked = True
print(source_note, license_checked)

확인 전이라면 미확인 상태를 그대로 남긴다. 설명 페이지와 사용 조건을 직접 확인한 뒤 기록을 갱신한다. 학교 과제에서도 허용 여부를 확인하기 전까지 같은 태도를 유지한다.

source_note = "출처와 사용 조건 확인 필요"
license_checked = False
print(source_note, license_checked)

True와 False는 각각 참과 거짓을 뜻한다. 상태를 참으로 적는 것은 확인 행위를 대신하지 않는다. 기록은 실제로 한 일과 일치해야 한다.

한눈에 보기

자료를 보내고 코드를 사용할 때 확인할 경계
대상먼저 할 일확인할 한계
개인정보필요한 형태만 가짜 자료로 재현한다.이름을 지워도 주변 내용으로 사람을 짐작할 수 있다.
비밀번호와 API 키질문에서 값을 빼고 코드와 분리한다.이미 노출됐다면 삭제 외에 변경·폐기를 진행한다.
남의 코드출처와 라이선스 조건을 확인한다.공개되어 있거나 출처를 적었다고 사용이 모두 허용되지는 않는다.
학교 과제허용 범위를 확인하고 사용 내용을 기록한다.사용 기록이 금지된 도움을 허용해 주지는 않는다.
자동 가림 검사가짜 예시로 실행하고 결과와 변경 내용을 비교한다.규칙에 없는 정보는 놓치므로 사람이 다시 읽는다.

이 검사기의 역할은 눈으로 놓치기 쉬운 몇 가지 모양을 먼저 표시하는 데 있다. 어떤 정보가 민감한지, 어떤 코드를 사용할 권한이 있는지는 문자열 모양만으로 결정할 수 없다. 다음 장에서는 이런 한계를 읽어 내기 위해 왜 기초 지식이 필요한지 살펴본다.

연습 문제

  1. 완성 코드의 texts에 “추가: second@example.com”을 마지막 항목으로 넣는다. 실행 전에 새로 생길 출력 줄과 이메일 합계를 적고, 실행 결과와 비교한다.
  2. 가짜 입력 “기록: learner@example.com / 010-0000-0000”을 check_examples에 추가한다. 기대 문자열과 기대 개수 세 개를 직접 정한다. 두 종류가 같은 문자열에 있을 때도 확인해야 하는 이유를 설명한다.
  3. 검사 결과 발견 개수가 0인 상담 메모가 있다. 이름은 지웠지만 반, 날짜, 드문 사건의 설명이 남아 있다. 이 결과만으로 전송 여부를 결정할 수 없는 이유와 더 줄여야 할 내용을 적는다.
  4. 과제에 쓸 코드 조각의 라이선스를 찾지 못했다. AI는 출처를 적으면 쓸 수 있다고 답했다. 코드 사용과 AI 사용 기록에 관해 각각 어떤 행동을 해야 하는지 적는다.

정답과 해설

  1. 새 줄은 “5. 추가: [이메일]”이고 이메일 합계는 2개다. 전화번호와 연습용 키는 각각 1개로 유지된다. 프로그램을 실행해 새 줄과 합계를 함께 확인한다. 예상과 다르면 원문을 출력하도록 바뀌었는지, 항목을 texts 안에 넣었는지 살핀다.

  2. 기대 문자열은 “기록: [이메일] / [전화번호]”이고 기대 개수는 (1, 1, 0)이다. cases 목록 안에 아래 항목을 추가할 수 있다. 단일 항목 검사는 각 규칙을 확인하고, 이 검사는 한 문자열의 여러 일치를 모두 처리하는지 확인한다.

            (
                "기록: learner@example.com / 010-0000-0000",
                "기록: [이메일] / [전화번호]",
                (1, 1, 0),
            ),
    

    목록에 넣은 뒤 전체 프로그램을 실행한다. 예시 검사 수만 늘어나므로 기존 출력은 그대로다. 검사 실패가 사라졌다는 사실과 필요한 사례를 검사했다는 사실을 구별해야 한다.

  3. 이 프로그램은 상담 내용의 의미나 사람을 짐작하게 하는 조합을 검사하지 않는다. 반과 날짜, 사건의 특징을 함께 보면 당사자를 알아볼 수 있다. 원문 대신 질문 해결에 필요한 상황을 가상으로 다시 쓰고, 알아볼 단서를 제거한다. 상담 내용이 질문에 필요하지 않다면 통째로 제외한다.

  4. AI의 설명만으로 코드의 사용 허락을 확인했다고 기록하지 않는다. 원래 출처와 사용 조건을 확인하고, 확인할 수 없다면 그 조각의 사용을 보류한다. 과제의 AI 허용 범위도 별도로 확인한다. 허용된 도움에 대해서는 어떤 설명이나 코드 후보를 받았고 무엇을 직접 검사했는지 기록한다. 출처 기록, 사용 허락, 과제 규칙은 각각 확인해야 할 사항이다.

오탈자·오류 제보 비공개로 접수되어 원고 수정에 반영됩니다

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

READER FEEDBACK

질문·의견

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

댓글 0

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

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