만들 것 정하기 - 가계부 한 장짜리 기획서

이 장에서 배우는 것

가계부를 만들고 싶다는 말만으로는 무엇부터 만들어야 할지 정하기 어렵다. 카드 결제 내역을 자동으로 읽는 앱과 지출 몇 건을 직접 적는 프로그램은 필요한 일이 다르다. 이 책에서는 혼자 쓰는 작은 가계부를 만들고, 실행 결과를 눈으로 확인하면서 기능을 하나씩 더한다. 이 장에서는 코드를 많이 만드는 대신 앞으로 만들 범위를 한 장짜리 기획서로 정한다.

기획서는 만들 기능, 이번에 제외할 기능, 기록할 데이터, 완료를 판단할 조건을 적은 문서다. 문서 작성 도구가 없어도 된다. 먼저 대화창에서 내용을 정리하고, 마지막에는 그 내용을 Python 코드에 담아 검사한다. 환경 준비와 첫 요청문을 따라 해 보았다면 시작할 수 있다.

• 만들 기능과 이번에 하지 않을 일을 구분한다.
• 날짜·금액·분류·메모의 뜻과 예시를 정한다.
• 실행 결과로 확인할 수 있는 완료 기준을 쓴다.
• AI에게 기획서 수정을 요청하고 변경 내용을 직접 비교한다.
• 기획서의 빠진 항목과 완료 기준 수를 출력하는 프로그램을 실행한다.

이번 장에서 만들 것

퇴근길에 쓴 식비를 적으려고 가계부를 만들기 시작했다고 하자. 처음에는 날짜와 금액만 있으면 될 것 같았는데, 만들다 보니 로그인과 휴대전화 화면도 떠오른다. 생각나는 기능을 모두 넣으면 첫 지출을 기록하기도 전에 작업 범위가 커진다. 이때 필요한 것은 더 긴 코드가 아니라 이번 작업의 경계다.

이번 장의 결과물은 가계부 기획서와 그 기획서를 검사하는 main.py 파일이다. 파일은 Python 프로그램을 저장하는 단위이며, 여기서는 main.py라는 이름을 계속 사용한다. 실행하면 기획서에 필요한 항목이 빠졌는지와 완료 기준이 몇 개인지를 표시하고 바로 끝난다. 지출을 입력받거나 파일에 저장하는 기능은 아직 만들지 않는다.

이번 기획서에 담을 네 가지 항목

항목	적을 내용	확인 방법
기능 목록	앞으로 만들 가계부 기능	작업 순서와 범위가 보이는지 읽는다.
이번에 안 할 것	로그인, 계좌 자동 연결 등	추가 요청을 구분할 수 있는지 읽는다.
데이터 항목	날짜, 금액, 분류, 메모	네 항목의 뜻과 예시를 확인한다.
완료 기준	결과를 보고 판단할 조건	각 조건을 실제로 확인할 수 있는지 읽는다.

검사 프로그램이 기획서의 품질까지 판단해 주는 것은 아니다. 프로그램은 정해 둔 이름의 항목이 있는지 확인하고 완료 기준의 개수를 센다. 내용이 구체적인지는 사람이 읽고 판단한다. 이 구분을 해 두면 “검사를 통과했으니 내용도 충분하다”라는 오해를 줄일 수 있다.

따라하기

각 단계의 요청문을 AI 대화창에 그대로 보내고, 답을 받은 뒤 확인 사항을 살펴본다. 아래의 AI 답 요지는 예상 방향을 보여 주는 예시다. AI의 답은 매번 다를 수 있으므로 문장 자체보다 필요한 내용이 들어 있는지 확인한다. AI가 코드를 제안하더라도 마지막 완성 코드와 비교하고 직접 실행한다.

단계 1. 가계부의 사용자를 한 사람으로 정한다

① 보낼 요청문

혼자 쓰는 가계부를 Python으로 만들려고 한다. 나는 프로그래밍을 처음 배운다. 목표는 지출을 기록하고 나중에 확인하는 것이다. 사용자 한 명, 원화 지출만 다룬다. 아직 코드는 쓰지 말고, 이 앱의 목적을 두 문장으로 정리해 달라. 로그인과 계좌 자동 연결은 넣지 말라.

② AI가 돌려줄 내용의 요지

사용자 한 명이 원화 지출을 기록하고 확인하는 가계부다. 작은 기능부터 만들고 실행 결과를 확인하면서 확장한다.

③ 직접 확인할 것

목적에 사용자 한 명과 지출 기록이라는 말이 들어 있는지 읽는다. 여러 사람의 자료를 나누거나 은행에 연결한다는 내용이 들어 있으면 삭제를 요청한다. 이 단계에는 실행할 코드와 터미널 명령이 없다. 기대 결과는 목적을 설명하는 두 문장이다.

④ 체크포인트

누가 무엇을 위해 쓰는지 다른 사람에게 두 문장으로 설명할 수 있으면 다음 단계로 간다. “편리한 앱”처럼 판단하기 어려운 표현만 남아 있으면 지출을 기록하고 확인한다는 행동으로 바꾼다.

단계 2. 기능 목록과 제외 범위를 나눈다

① 보낼 요청문

방금 정한 목적을 유지하라. 기능 목록은 지출 기록, JSON 저장과 불러오기, 분류 확인, 월별 보고, 예산 경고, 검색과 수정·삭제, CSV 가져오기·내보내기, HTML 보고서, 검사, 코드 정리, 사용 설명서로 정리하라. 이번에 안 할 것은 로그인, 계좌 자동 연결, 여러 사용자, 휴대전화 앱 배포로 정리하라. 구현 방법과 코드는 쓰지 말고 두 목록만 보여 달라.

② AI가 돌려줄 내용의 요지

앞으로 만들 기능과 제외할 기능이 별도 목록으로 정리된다. 제외한 기능은 이번 작업의 완료 조건에 포함하지 않는다.

③ 직접 확인할 것

기능 목록이 앞으로의 작업 범위이고, 이번 장에서 모두 구현한다는 뜻은 아닌지 확인한다. JSON과 CSV는 자료를 저장하거나 주고받는 형식이며, HTML은 화면에 보여 줄 문서 형식이다. 지금은 이름만 기획서에 적는다. 실행 명령은 없으며 두 목록이 분리된 답이 기대 결과다.

④ 체크포인트

로그인 요청을 받았을 때 “이번 범위에는 없다”라고 기획서를 근거로 말할 수 있으면 다음 단계로 간다. 제외 범위는 앞으로도 만들 수 없다는 선언이 아니라 이번 작업에서 빼겠다는 선택이다.

단계 3. 데이터 네 항목의 뜻을 정한다

① 보낼 요청문

가계부 데이터는 날짜, 금액, 분류, 메모 네 항목으로 한정하라. 날짜 예시는 2026-10-01, 금액 예시는 8500, 분류 예시는 식비, 메모 예시는 점심으로 하라. 금액은 원 단위 양의 정수이며 메모는 빈 내용도 허용한다고 적어 달라. 날짜는 연-월-일 형식으로 적는다. 코드는 쓰지 말고 항목별 뜻과 예시를 표로 정리하라.

② AI가 돌려줄 내용의 요지

날짜는 지출한 날, 금액은 지출한 원화 금액, 분류는 지출의 종류, 메모는 선택해서 적는 설명이다. 예시 한 건은 2026-10-01, 8500, 식비, 점심이다.

③ 직접 확인할 것

8500원이라는 표시와 프로그램에 담을 숫자 8500이 구분되어 있는지 확인한다. 정수는 소수 부분이 없는 수다. 메모를 비워도 되는지 역시 읽는다. 실행 명령은 없으며 다음 표와 같은 네 항목이 기대 결과다.

지출 한 건을 설명하는 데이터 약속

항목	뜻과 규칙	예시
날짜	지출한 날, 연-월-일 형식	2026-10-01
금액	원 단위 양의 정수	8500
분류	지출의 종류	식비
메모	선택해서 적는 설명, 빈 내용 허용	점심

④ 체크포인트

예시 한 건을 네 항목으로 나누어 읽을 수 있으면 다음 단계로 간다. 이 단계는 입력을 검사하는 코드를 만드는 과정이 아니다. 나중에 검사할 규칙을 글로 정하는 과정이다.

단계 4. 눈으로 판단할 완료 기준을 쓴다

① 보낼 요청문

이번 장의 완료 기준을 네 개로 작성하라. 기능 목록과 제외 범위가 각각 한 개 이상 있다, 데이터에 날짜·금액·분류·메모가 있다, 필요한 기획서 항목이 없으면 그 이름을 출력한다, 정상 기획서의 완료 기준 수를 4개로 출력한다는 조건을 넣어 달라. 편리하다거나 보기 좋다는 표현은 쓰지 말라. 앞으로 만들 가계부 전체의 완료 기준과 이번 장의 완료 기준을 섞지 말라.

② AI가 돌려줄 내용의 요지

이번 장에서 확인할 조건 네 개가 나온다. 각 조건은 문서를 읽거나 프로그램의 출력을 확인해서 판단할 수 있다.

③ 직접 확인할 것

조건을 읽고 통과 여부를 판단할 방법이 떠오르는지 확인한다. 예를 들어 “쓸 만한 기획서다”는 사람마다 판단이 다르다. “데이터에 네 항목이 있다”는 실제 목록과 비교할 수 있다. 실행 명령은 없으며 서로 구분되는 조건 네 개가 기대 결과다.

④ 체크포인트

네 조건에 번호를 붙이고 각각 확인 방법을 말할 수 있으면 다음 단계로 간다. 조건 수를 세는 검사와 조건을 실제로 만족하는지 확인하는 일은 다르다는 점도 함께 기억한다.

단계 5. AI에게 기획서를 다듬게 하고 변경 내용을 비교한다

① 보낼 요청문

지금까지 정한 내용을 기능 목록, 이번에 안 할 것, 데이터 항목, 완료 기준이라는 네 제목 아래 한 장짜리 기획서로 합쳐 달라. 새 기능을 추가하지 말라. 모호한 문장을 구체적으로 다듬되 데이터 네 항목과 완료 기준 네 개는 유지하라. 다듬은 기획서 뒤에는 바꾼 문장과 바꾼 이유를 짝지어 적어 달라.

② AI가 돌려줄 내용의 요지

네 제목 아래 기획서가 정리된다. 표현을 고친 부분은 이유와 함께 제시되며, 합의한 기능과 제외 범위는 유지된다.

③ 직접 확인할 것

수정 전후의 차이를 비교하는 검토를 diff 검토라고 한다. 별도 도구가 없어도 두 답을 나란히 읽으며 할 수 있다. 기능이 새로 생겼는지, 메모가 필수로 바뀌었는지, 완료 기준이 늘었는지 확인한다. 실행 명령은 없으며 범위가 유지된 기획서와 변경 이유 목록이 기대 결과다.

④ 체크포인트

바뀐 문장을 설명할 수 있고 의도하지 않은 추가가 없으면 다음 단계로 간다. AI가 정리했다는 이유만으로 내용을 확정하지 않는다. 잘 정돈된 문장에도 처음 요청과 다른 조건이 들어갈 수 있다.

단계 6. 기획서를 검사할 코드로 바꾼다

① 보낼 요청문

이 기획서를 담는 Python 3.12 이상용 main.py를 작성하라. 사전의 항목 이름은 기능 목록, 이번에 안 할 것, 데이터 항목, 완료 기준으로 하라. 필요한 항목 이름이 빠졌는지 검사하고 완료 기준 수를 출력하라. 정상 기획서와 완료 기준 항목을 뺀 기획서를 차례로 검사하라. 사용자 입력, 파일 읽기·쓰기, 외부 패키지, 네트워크 호출 없이 실행하고 끝내라. 출력은 항상 같아야 한다.

② AI가 돌려줄 내용의 요지

이름과 내용을 짝지어 담는 사전과, 여러 값을 차례로 담는 목록을 사용한다. 정상 예시와 항목이 빠진 예시를 검사하는 코드가 제시된다.

③ 직접 확인할 것

사전은 이름으로 내용을 찾는 자료 구조이고 목록은 값들을 순서대로 담는 자료 구조다. 아래 완성 코드를 main.py에 저장한다. AI가 준 코드가 다르면 항목 이름, 검사 순서, 출력 문장을 완성 코드와 비교한다. 터미널에서 실행할 명령은 다음과 같다.

python3 main.py

정상 기획서에서는 빠진 항목이 없고 완료 기준이 4개로 나와야 한다. 누락 예시에서는 완료 기준이 빠졌고 0개로 나와야 한다. 전체 출력은 뒤의 실행 결과와 비교한다.

④ 체크포인트

두 경우가 모두 예상대로 나오면 다음 단계로 간다. 항목이 없는 경우를 함께 실행하는 것은 작은 테스트다. 테스트는 미리 정한 상황에서 실제 결과가 기대와 같은지 확인하는 일이다.

단계 7. 다시 실행하고 기획서의 한계를 확인한다

① 보낼 요청문

방금 코드에서 실제로 검사하는 것과 사람이 읽고 확인해야 하는 것을 나누어 설명하라. 코드는 바꾸지 말라. 항목의 존재와 완료 기준 개수만으로 내용의 품질을 보장할 수 없는 이유를 이 기획서의 예로 설명하라.

② AI가 돌려줄 내용의 요지

코드는 필요한 이름의 존재와 완료 기준 수를 확인한다. 기능의 타당성, 날짜 규칙의 충분함, 완료 기준의 구체성은 사람이 읽어야 한다.

③ 직접 확인할 것

먼저 컴파일 검사로 Python이 코드를 해석할 수 있는지 확인한다. 컴파일 검사는 프로그램의 행동이 맞는지까지 확인하는 검사는 아니다. 다음 명령을 순서대로 실행한다.

python3 -W error -m py_compile main.py
python3 main.py

첫 명령은 경고를 오류로 취급하여 검사하며, 정상일 때 출력 없이 끝난다. 둘째 명령은 앞 단계와 같은 결과를 내야 한다. 기획서의 항목 이름을 잘못 적지 않았는지도 마지막으로 비교한다.

④ 체크포인트

컴파일 검사가 조용히 끝나고 실행 결과가 일치하며, 기획서 네 부분을 직접 읽었다면 이번 장의 작업을 마친다. 다음에는 이 범위 안에서 지출 한 건을 기록하고 보여 주는 기능부터 만든다.

완성 코드

아래 전체를 main.py에 저장한다. 줄 번호는 코드에 넣지 않는다. 기획서 내용도 코드 안에 있으므로 별도 입력 파일은 필요 없다. 코드는 날짜를 계산하거나 현재 시각을 읽지 않으며, 입력을 기다리지 않는다.

plan = {
    "기능 목록": [
        "지출 기록",
        "JSON 저장과 불러오기",
        "분류 확인",
        "월별 보고",
        "예산 경고",
        "검색과 수정·삭제",
        "CSV 가져오기·내보내기",
        "HTML 보고서",
        "검사",
        "코드 정리",
        "사용 설명서",
    ],
    "이번에 안 할 것": [
        "로그인",
        "계좌 자동 연결",
        "여러 사용자",
        "휴대전화 앱 배포",
    ],
    "데이터 항목": {
        "날짜": "지출한 날, 연-월-일 형식, 예: 2026-10-01",
        "금액": "원 단위 양의 정수, 예: 8500",
        "분류": "지출의 종류, 예: 식비",
        "메모": "선택 설명, 빈 내용 허용, 예: 점심",
    },
    "완료 기준": [
        "기능 목록과 제외 범위가 각각 한 개 이상 있다.",
        "데이터에 날짜·금액·분류·메모가 있다.",
        "필요한 기획서 항목이 없으면 그 이름을 출력한다.",
        "정상 기획서의 완료 기준 수를 4개로 출력한다.",
    ],
}

required_keys = [
    "기능 목록",
    "이번에 안 할 것",
    "데이터 항목",
    "완료 기준",
]

incomplete_plan = plan.copy()
del incomplete_plan["완료 기준"]

examples = [
    ("정상 기획서", plan),
    ("누락 예시", incomplete_plan),
]

for title, current_plan in examples:
    missing = []
    for key in required_keys:
        if key not in current_plan:
            missing.append(key)
    criteria = current_plan.get("완료 기준", [])
    print(f"[{title}]")
    if missing:
        print("빠진 항목: " + ", ".join(missing))
    else:
        print("빠진 항목: 없음")
    print(f"완료 기준 수: {len(criteria)}개")

줄별 해설

1~33줄은 plan이라는 이름에 기획서 사전을 담는다. 등호는 오른쪽 값을 왼쪽 이름에 연결한다. 중괄호로 사전을 만들고, 따옴표 안의 글을 이름과 내용으로 사용한다. 이름과 내용 사이의 콜론은 둘을 짝짓는다. 각 항목 뒤의 쉼표는 다음 항목과 구분하는 표시다.

2~14줄은 기능 목록이다. 대괄호 안에 기능 이름을 순서대로 넣었다. 목록에 적힌 기능은 구현된 기능이 아니라 앞으로 만들 기능이다. 15~20줄에는 이번에 제외할 일을 같은 방식으로 넣었다. 기능 목록과 제외 목록을 분리하면 범위를 바꿀 때 어느 쪽을 고쳐야 할지 알기 쉽다.

21~26줄은 데이터 항목 사전이다. 기획서 사전 안에 또 다른 사전을 넣었다. 날짜 같은 항목 이름과 설명을 짝지으려는 목적이다. 여기의 8500은 설명 문장 속 예시다. 실제 지출 금액을 계산하는 코드는 아직 없다. 27~32줄에는 완료 기준 네 문장을 목록으로 넣었다.

35~40줄은 반드시 있어야 하는 항목 이름을 정한다. 검사 대상인 plan과 기준인 required_keys를 따로 적는다. 필요한 항목을 검사 대상 자체에서 뽑으면 이미 사라진 이름을 알아낼 수 없기 때문이다. 여기서는 요구한 순서대로 목록을 만들었으므로 누락된 이름도 그 순서로 모인다.

42줄은 사전의 복사본을 만들고, 43줄은 복사본에서 완료 기준 항목을 지운다. 이 복사는 바깥 사전을 새로 만드는 얕은 복사다. 안쪽 목록까지 모두 새로 만들지는 않는다. 여기서는 바깥 항목 하나만 지우므로 원본의 완료 기준 항목은 남는다. 안쪽 목록을 수정하는 용도로 확대해서 쓰지 않는다.

45~48줄은 검사할 두 사례를 묶는다. 각 사례의 괄호에는 표시할 제목과 검사할 사전이 들어 있다. 50줄의 for는 두 사례를 차례로 꺼내 아래 코드를 반복한다. 들여쓴 부분이 반복해서 실행되는 범위다. 공백 깊이는 코드의 의미를 결정하므로 복사할 때 유지한다.

51줄은 빠진 이름을 모을 빈 목록을 만든다. 52~54줄은 필요한 이름을 하나씩 검사한다. 사전에서 in은 이름의 존재를 확인하며, not in은 그 이름이 없다는 뜻이다. 없는 이름만 append로 목록 끝에 추가한다.

55줄의 get은 완료 기준 내용을 가져온다. 이름이 없으면 두 번째 값인 빈 목록을 사용한다. 그래서 누락 예시도 오류로 중단되지 않는다. 56~61줄은 결과를 출력한다. f로 시작하는 문자열은 중괄호 자리에 값을 넣으며, len은 목록의 항목 수를 센다. join은 빠진 이름 사이에 쉼표와 공백을 넣어 한 문장으로 합친다.

실행 결과

main.py를 저장한 폴더에서 다음 명령을 실행한다. 명령은 터미널에 입력하며 Python 파일 안에는 넣지 않는다.

python3 main.py

예상 출력은 다음과 같다. 빈 줄 없이 여섯 줄이 나온다.

[정상 기획서]
빠진 항목: 없음
완료 기준 수: 4개
[누락 예시]
빠진 항목: 완료 기준
완료 기준 수: 0개

누락 예시의 0개는 완료 기준 항목을 찾지 못해 빈 목록으로 센 결과다. 비어 있는 완료 기준 항목이 있는 경우와 화면의 개수는 같을 수 있지만, 빠진 항목 출력은 다르다. 정상 예시와 누락 예시를 함께 보면 프로그램이 무엇을 구분하는지 확인할 수 있다.

실무에서 자주 틀리는 것

필요한 이름을 검사 대상에서 가져온다

다음 코드는 실행되지만 필요한 이름의 기준으로는 부족하다. 아래 짧은 코드는 각각 독립해서 실행할 수 있는 비교 예시다.

plan = {"기능 목록": ["지출 기록"]}
required_keys = list(plan)
print(required_keys)

이미 빠진 완료 기준은 이 목록에 들어오지 않는다. 기준을 따로 적어야 한다.

plan = {"기능 목록": ["지출 기록"]}
required_keys = ["기능 목록", "완료 기준"]
missing = [key for key in required_keys if key not in plan]
print(missing)

마지막 코드는 빠진 이름만 모으는 짧은 목록 작성 방식이다. 완성 코드의 반복문과 같은 목적이며, 결과에는 완료 기준이 들어간다.

누락된 항목도 있다고 가정한다

다음 코드는 완료 기준이라는 이름이 없어 오류로 끝난다.

plan = {}
print(len(plan["완료 기준"]))

누락을 시연하는 프로그램에서는 없는 경우의 기본값을 정한다.

plan = {}
criteria = plan.get("완료 기준", [])
print(len(criteria))

이 코드는 0을 출력한다. 다만 get이 내용의 형식까지 고쳐 주지는 않는다. 이 장에서는 완료 기준이 있으면 목록이라는 전제로 정해진 예시를 검사한다.

같은 사전에 다른 이름만 붙인다

다음 코드는 원본과 예시가 같은 사전을 가리킨다. 예시에서 지우면 원본에서도 사라진다.

plan = {"완료 기준": ["항목을 확인한다."]}
example = plan
del example["완료 기준"]
print("완료 기준" in plan)

바깥 항목을 지우는 예시를 만들 때는 사전을 복사한다.

plan = {"완료 기준": ["항목을 확인한다."]}
example = plan.copy()
del example["완료 기준"]
print("완료 기준" in plan)

첫 코드는 False, 고친 코드는 True를 출력한다. 두 값은 각각 거짓과 참을 나타낸다. 원본이 유지되는지를 실행으로 확인하는 예다.

한눈에 보기

기획서 작성과 코드 검사의 역할

작업	이번 장의 선택	확인할 결과
범위 정하기	혼자 쓰는 원화 지출 가계부	기능과 제외 범위가 구분된다.
데이터 정하기	날짜·금액·분류·메모	뜻과 예시가 적혀 있다.
완료 기준 정하기	확인 가능한 조건 네 개	사람이 조건별로 판단할 수 있다.
프로그램 검사	이름 존재 검사와 목록 개수 세기	정상은 없음·4개, 누락은 완료 기준·0개다.
AI 답 검토	수정 전후 비교와 직접 실행	요청 범위와 실제 결과가 일치한다.

기획서가 짧아도 필요한 결정을 담을 수 있다. 기능 이름만 늘리는 대신 제외 범위와 완료 기준을 함께 적는 것이 핵심이다. 다음 작업에서 AI에게 요청할 때도 이 기획서를 함께 전달하면 무엇을 유지해야 하는지 설명하기 쉽다.

연습 문제

1. 원본 plan을 유지하면서 데이터 항목이 빠진 예시를 만들려면 완성 코드의 어느 줄을 바꾸면 되는가. 바꾼 뒤 누락 예시의 두 출력 문장을 예상하라.
2. 완료 기준 목록에 확인 가능한 조건 한 개를 추가하라. 정상 기획서와 누락 예시의 완료 기준 수가 각각 어떻게 바뀌는지 실행 전에 적어 보라.
3. “사용하기 좋은 가계부 기획서다”를 사람이 확인할 수 있는 조건으로 고쳐라. 현재 프로그램이 그 조건의 충족 여부까지 검사하는지도 설명하라.

정답과 해설

1. 43줄의 삭제 대상을 데이터 항목으로 바꾼다. 정상 기획서는 그대로이고 누락 예시에는 “빠진 항목: 데이터 항목”, “완료 기준 수: 4개”가 출력된다. 완료 기준을 삭제하지 않았기 때문이다. 수정 후 실행 결과를 예상과 비교한다.
2. 정상 기획서는 5개, 누락 예시는 0개가 된다. 완성 코드에서는 완료 기준 항목 전체를 복사본에서 지우기 때문이다. 다만 기존 기획서에는 4개로 출력한다는 조건이 있으므로 실제 요구를 바꾸려면 그 문장도 5개에 맞게 고쳐야 한다. 코드의 개수와 문서의 약속을 함께 비교한다.
3. 예를 들어 “데이터 네 항목 모두에 뜻과 예시가 적혀 있다”로 바꿀 수 있다. 문서를 읽어 각 항목을 확인하면 판단할 수 있다. 현재 프로그램은 설명과 예시의 존재까지 검사하지 않는다. 완료 기준 목록에 문장을 넣으면 개수만 늘어나므로, 목록에 적었다는 사실을 조건 통과로 해석하지 않는다.