첫 요청문 쓰기 - 목적·입력·출력·예시 네 칸

이 장에서 배우는 것

앞 장에서 작업 폴더를 만들고 Python 파일을 실행했다. 이제 그 파일에 담을 프로그램을 AI에게 부탁할 차례다. 그런데 “쓸 만한 프로그램을 만들어 줘”라고 말하면 무엇이 나올지 예상하기 어렵다. AI는 우리가 생략한 조건을 추측해서 채운다. 그 추측이 내 생각과 다르면 코드는 실행되더라도 원하는 프로그램은 아니다.

이 장에서는 첫 요청을 목적·입력·출력·예시 네 칸으로 나누어 쓴다. 문장을 길고 근사하게 만드는 연습이 아니다. 내가 원하는 일을 다른 사람이 읽어도 같은 모습으로 떠올릴 수 있게 적는 연습이다. 끝에서는 요청문에 네 칸이 있는지 살피는 작은 프로그램을 실행한다. 이 프로그램은 AI를 호출하지 않는다. 정해 둔 낱말 규칙으로 글을 확인하고, 비어 있는 칸을 알려 준다.

• 막연한 요청에서 AI가 추측해야 하는 부분을 찾는다.
• 목적·입력·출력·예시를 구분해 첫 요청문을 쓴다.
• 예시 입력과 기대 출력을 짝지어 원하는 동작을 보여 준다.
• 한 번에 확인할 수 있는 작은 일 하나를 요청한다.
• 요청문 점검기를 실행하고, 점검 결과의 한계까지 확인한다.

문제 상황

모임에서 사용할 인사말을 만드는 프로그램이 필요하다고 하자. 이름이 “민지”이면 “민지님, 반갑다.”라는 문장을 보여 주면 된다. 처음에는 AI에게 다음처럼 말하기 쉽다.

인사 프로그램을 만들어 줘.

이 말만으로는 이름을 어디서 얻는지 알 수 없다. 실행할 때 사람이 이름을 입력하는지, 파일에서 이름을 읽는지, 코드에 이름을 미리 적는지가 빠졌다. 인사말도 정해지지 않았다. AI가 이름을 묻는 창을 만들거나, 여러 언어의 인사말을 출력하더라도 요청에 어긋났다고 말하기 어렵다.

여기서는 실행하자마자 정해진 결과를 보여 주는 작은 프로그램이 필요하다. 이름을 직접 입력받는 동작은 필요 없다. 이 조건을 말하지 않으면 AI가 친절하게 추가한 입력 기능 때문에 실행이 멈춘 것처럼 느껴질 수도 있다. 프로그램은 이름을 기다리고 있지만, 처음 실행하는 사람은 그 이유를 모를 수 있다.

다음 요청은 확인할 지점을 드러낸다.

목적: 이름 하나를 이용해 한국어 인사말 한 줄을 만든다.
입력: 코드에 미리 적은 이름 “민지”를 사용한다. 실행 중에는 입력을 묻지 않는다.
출력: 이름 뒤에 “님, 반갑다.”를 붙인 문장을 화면에 한 줄로 보여 준다.
예시: 이름이 “민지”이면 “민지님, 반갑다.”를 출력한다.

이제 결과를 판단하기 쉬워졌다. 이름을 묻고 기다리면 입력 조건과 다르고, “안녕하세요, 민지”라고 나오면 출력 조건과 다르다. 요청문은 AI에게 일을 맡기는 글이면서, 나중에 결과를 확인할 때 되돌아볼 약속이기도 하다.

네 칸으로 원하는 동작을 나눈다

AI에게 작업을 부탁하는 글을 요청문이라고 부르며, 프롬프트(prompt)라는 말도 쓴다. 요청문에 정해진 정답 문구가 있는 것은 아니다. 다만 처음에는 네 칸을 고정해 두면 빠뜨린 조건을 발견하기 쉽다. 각 칸은 서로 다른 질문에 답한다.

첫 요청문 네 칸에 담을 내용

칸	답할 질문	인사말 프로그램의 내용
목적	무엇을 하려는가	이름으로 인사말 한 줄을 만든다.
입력	어떤 자료를 어디서 받는가	코드에 적어 둔 “민지”를 사용한다.
출력	결과를 어떤 모양으로 어디에 보여 주는가	화면에 인사말 한 줄을 출력한다.
예시	자료 하나가 어떤 결과로 바뀌는가	“민지” → “민지님, 반갑다.”

목적에는 프로그램을 만드는 이유를 짧게 적는다. “도움이 되는 도구”보다는 “요청문에서 빠진 항목을 찾는 도구”가 낫다. 입력에는 자료의 내용뿐 아니라 들어오는 방법도 적는다. “이름”만 쓰는 것과 “코드에 미리 적은 이름 하나”라고 쓰는 것은 다른 요청이다.

출력에는 결과의 모양을 적는다. 화면에 보여 줄지, 파일로 남길지부터 구분한다. 화면에 보여 준다면 한 줄인지 여러 줄인지, 어떤 문구를 사용할지 정한다. 예시는 입력과 출력을 연결한다. 설명만 읽고 남아 있던 의문을 실제 값 하나로 줄이는 역할을 한다.

처음 쓸 때는 다음 틀을 복사하고 각 줄의 내용을 바꾸면 된다. 대괄호 안의 설명을 그대로 남겨 두는 것이 아니라, 내 프로그램에 해당하는 문장을 넣는다.

목적: [프로그램이 할 일 하나]
입력: [사용할 자료와 자료가 들어오는 방법]
출력: [결과를 보여 줄 곳과 결과의 모양]
예시: [구체적인 입력 하나 → 기대하는 출력]

입력이 없는 프로그램이라면 “입력: 외부 입력 없이 코드에 정한 자료를 사용한다.”라고 적는다. 빈칸으로 두는 것과 입력이 필요 없다고 명시하는 것은 다르다. 빈칸은 결정을 미룬 상태이고, 입력이 없다는 문장은 하나의 결정이다.

네 칸만으로 모든 조건을 표현할 필요는 없다. Python으로 만들어 달라는 조건이나 외부 패키지를 사용하지 말라는 조건은 뒤에 짧게 덧붙일 수 있다. 네 칸은 동작을 정리하는 기본 틀이고, 실행 환경은 그 동작을 구현할 때 지킬 조건이다.

예시를 붙이고 한 번에 하나만 시킨다

“빠진 칸을 알려 줘”라는 말에도 여러 해석이 있다. 빠진 칸의 이름만 보여 줄 수도 있고, 요청문 전체를 다시 써 줄 수도 있다. “출력이 간단했으면 좋겠다”는 말 역시 사람마다 다르게 받아들인다. 이럴 때 기대하는 결과를 직접 쓰면 범위를 좁힐 수 있다.

예시: “목적: 인사말 만들기”만 있는 요청문이면 “빠진 칸: 입력, 출력, 예시”를 출력한다.

이 예시에는 표시할 낱말, 칸의 순서, 쉼표 뒤의 띄어쓰기까지 들어 있다. AI가 만든 프로그램을 실행한 뒤 화면의 결과와 비교할 수 있다. 다만 예시 하나가 모든 상황을 설명하지는 않는다. 네 칸을 모두 채운 경우도 함께 주면 성공했을 때의 모습까지 정해진다.

예시와 본문 설명이 충돌하지 않는지도 살핀다. 출력 설명에는 “한 줄”이라고 적고 예시에는 세 줄을 보여 주면 AI가 어느 쪽을 따라야 할지 모호하다. 예시는 장식이 아니라 요구 사항의 일부다. 요청을 보내기 전에 네 칸을 읽고, 예시가 앞의 설명을 그대로 보여 주는지 확인한다.

작업의 크기도 줄여야 한다. 요청문 점검기를 부탁하면서 회원 가입, 저장 기능, 화면 꾸미기까지 함께 요청하면 처음 결과를 확인하기 어려워진다. 이름표가 없는 줄을 놓친 것인지, 저장 과정이 잘못된 것인지 구분할 일이 늘어난다. 먼저 네 칸을 확인해 화면에 결과를 보여 주는 일만 맡긴다.

여기서 “하나만 시킨다”는 말은 조건을 하나만 적으라는 뜻이 아니다. 한 가지 동작을 분명하게 만들기 위해 입력 방법과 출력 모양을 자세히 적을 수 있다. 네 칸을 점검하는 기능 하나에 여러 확인 조건이 붙는 것은 자연스럽다.

이 장의 완성 프로그램을 부탁하는 요청문은 다음처럼 쓸 수 있다.

목적: 요청문에 목적·입력·출력·예시 네 칸이 채워졌는지 검사하는 작은 프로그램을 만든다.
입력: 코드에 요청문 두 개를 문자열로 미리 넣는다. 하나는 네 칸을 채우고, 다른 하나는 입력 칸을 비우고 예시 줄을 생략한다. 실행 중에는 입력을 묻지 않는다.
출력: 각 요청문의 번호와 점검 결과를 화면에 보여 준다. 빠진 칸은 목적·입력·출력·예시 순서로 나열한다. 모두 채웠으면 “네 칸이 모두 채워졌다.”라고 출력한다.
예시: 목적·입력·출력·예시가 모두 채워졌으면 “네 칸이 모두 채워졌다.”를 출력한다. 입력이 비고 예시가 없으면 “빠진 칸: 입력, 예시”를 출력한다.

Python 3.12 이상에서 표준 라이브러리만 사용하는 main.py 한 파일로 만든다. python3 main.py로 실행하면 결과를 출력하고 끝나야 한다. 네트워크는 사용하지 않는다.

각 줄의 첫 콜론 앞 낱말이 목적·입력·출력·예시 중 하나인지 확인한다. 앞뒤 공백은 무시하고, 콜론 뒤에 공백 이외의 글자가 있어야 채워진 칸으로 인정한다. 같은 칸이 여러 번 나오면 내용이 있는 줄 하나만 있어도 인정한다. 문장의 뜻은 판단하지 않는다.

마지막 문단은 검사 규칙을 정한다. “잘 쓴 요청문인지 판단해 줘”라고 범위를 넓히지 않았다. 낱말과 빈칸만 검사하므로 프로그램이 할 수 있는 일과 사람이 읽어야 할 일이 구분된다.

낱말 규칙으로 점검할 수 있는 범위를 정한다

이번 프로그램에서 문자열은 글자를 묶어 둔 값이다. 요청문 전체를 문자열로 보관한 뒤 줄마다 나누어 읽는다. 각 줄에서 첫 번째 콜론을 찾아 왼쪽은 칸 이름, 오른쪽은 내용으로 취급한다. “목적: 인사말 만들기”라면 칸 이름은 “목적”, 내용은 “인사말 만들기”다.

콜론 앞뒤의 공백은 지운다. 따라서 “입력 : 이름 하나”도 입력 칸으로 인정한다. 반면 “입력값: 이름 하나”는 이름이 다르므로 인정하지 않는다. 이 프로그램은 비슷한 뜻의 낱말을 알아서 바꾸지 않는다. 콜론도 보통의 반각 콜론인 “:”을 사용한다.

또한 “출력:” 뒤에 아무 글자도 없으면 출력 칸이 비었다고 판단한다. 공백만 있어도 마찬가지다. “출력: 나중에 정한다”라고 쓰면 글자가 있으므로 채워진 칸으로 처리한다. 내용이 충분한지까지 판단하지 않는다는 뜻이다. 점검 결과가 좋더라도 사람이 요청문을 다시 읽어야 한다.

이처럼 확인 규칙이 단순하면 예상 결과를 손으로 계산하기 쉽다. AI에게 받은 코드도 같은 방식으로 확인한다. 두 요청문에서 어떤 칸이 인정될지 먼저 적고, 실행 결과가 그 예상과 맞는지 비교한다. 이후 수정본을 받으면 이전 코드와 달라진 부분을 보여 주는 차이 비교인 diff도 살핀다. 요청하지 않은 입력 기능이나 파일 저장이 추가되었다면 그 이유를 확인한다.

완성 코드

다음 코드를 main.py에 저장한다. 빈 줄을 포함해 55줄이며, 별도의 파일이나 패키지가 필요 없다. 두 요청문과 세 가지 검사 사례를 코드 안에 넣었다. 검사는 예상과 다를 때 실행을 멈추도록 작성했다.

FIELDS = ("목적", "입력", "출력", "예시")

REQUESTS = (
    """목적: 이름으로 인사말을 만든다.
입력: 코드에 적힌 이름 민지를 사용한다.
출력: 화면에 인사말 한 줄을 보여 준다.
예시: 민지 → 민지님, 반갑다.""",
    """목적: 이름으로 인사말을 만든다.
입력:
출력: 화면에 인사말 한 줄을 보여 준다.""",
)


def find_missing(request):
    filled = set()
    for line in request.splitlines():
        label, separator, content = line.partition(":")
        label = label.strip()
        content = content.strip()
        if separator and label in FIELDS and content:
            filled.add(label)
    return [field for field in FIELDS if field not in filled]


def describe(missing):
    if missing:
        return "빠진 칸: " + ", ".join(missing)
    return "네 칸이 모두 채워졌다."


def run_checks():
    complete = "목적: 가\n입력: 나\n출력: 다\n예시: 라"
    blank = "목적: 가\n입력:   \n출력: 다"
    repeated = "목적:\n목적: 가\n입력: 나\n출력: 다\n예시: 라"
    cases = (
        (complete, []),
        (blank, ["입력", "예시"]),
        (repeated, []),
    )
    for request, expected in cases:
        actual = find_missing(request)
        if actual != expected:
            raise AssertionError("점검 결과가 예상과 다르다.")
    print("확인: 검사 3개 통과")


def main():
    run_checks()
    for number, request in enumerate(REQUESTS, start=1):
        print(f"요청문 {number}")
        print(describe(find_missing(request)))


if __name__ == "__main__":
    main()

줄별 해설

모든 문법을 한꺼번에 외울 필요는 없다. 지금은 요청문을 어디에 넣고, 어떤 규칙으로 검사하고, 결과를 어디에 보여 주는지 따라가면 된다. 빈 줄은 읽기 좋게 덩어리를 나누며 실행할 동작은 없다.

완성 코드의 각 줄이 맡은 역할

줄	코드의 역할	확인할 점
1	FIELDS에 네 칸의 이름을 정해진 순서로 묶는다.	이 순서가 빠진 칸을 출력하는 순서다.
3~11	REQUESTS에 요청문 두 개를 넣는다. 큰따옴표 세 개는 여러 줄의 글을 묶는다.	첫 요청문은 모두 채웠고, 둘째는 입력이 비고 예시가 없다.
14	find_missing이라는 함수, 즉 이름을 붙인 작업 묶음을 정의한다.	request는 이 작업에 전달할 요청문이다.
15	인정된 칸 이름을 모을 집합을 만든다.	집합은 같은 값을 여러 번 넣어도 하나만 보관한다.
16	splitlines()로 요청문을 줄마다 나누고 for로 한 줄씩 다룬다.	한 줄을 처리한 뒤 다음 줄로 넘어간다.
17	partition(":")으로 첫 콜론을 기준 삼아 세 부분을 얻는다.	왼쪽 글, 콜론, 오른쪽 글을 각각 보관한다.
18~19	strip()으로 이름과 내용의 앞뒤 공백을 지운다.	글 중간의 공백은 지우지 않는다.
20	콜론이 있고, 이름이 네 칸 중 하나이며, 내용도 있는지 확인한다.	and로 연결한 세 조건을 모두 만족해야 한다.
21	조건을 만족한 칸 이름을 집합에 넣는다.	내용 없는 중복 줄이 있어도 이미 인정한 칸은 유지된다.
22	인정되지 않은 칸 이름을 목록으로 만들어 돌려준다.	대괄호 안에서 FIELDS의 순서를 따라 빠진 이름만 모은다.
25~28	빠진 칸 목록을 화면에 보여 줄 문장으로 바꾼다.	join()은 이름 사이에 쉼표와 공백을 넣어 연결한다.
31	미리 정한 검사 사례를 확인할 함수를 정의한다.	실제 결과와 기대 결과를 비교하는 자리다.
32~34	전체 채움, 공백, 중복 이름의 사례를 만든다.	\n은 문자열 안에서 줄바꿈을 나타낸다.
35~39	각 요청문과 예상되는 빠진 칸 목록을 짝짓는다.	[]는 빠진 칸이 없는 빈 목록이다.
40~41	각 사례를 검사하고 실제 결과를 actual에 담는다.	expected는 미리 적은 기대 결과다.
42~43	두 결과가 다르면 오류를 내고 멈춘다.	!=는 서로 다르다는 비교다.
44	세 사례를 모두 통과한 뒤 확인 문장을 출력한다.	검사 도중 멈추면 이 문장은 나오지 않는다.
47~48	프로그램의 주된 작업을 정의하고 먼저 검사를 실행한다.	요청문 결과보다 검사 결과가 먼저 나온다.
49	요청문을 하나씩 꺼내며 1부터 번호를 붙인다.	enumerate()가 번호와 요청문을 함께 준다.
50~51	번호를 출력하고, 빠진 칸을 찾아 문장으로 출력한다.	f가 붙은 문자열의 중괄호 자리에 번호가 들어간다.
54~55	이 파일을 직접 실행했을 때 main()을 호출한다.	지금은 파일의 실행을 시작하는 약속으로 읽으면 된다.

17줄에서 콜론이 없는 줄을 만나면 separator는 빈 문자열이 된다. 따라서 20줄의 조건을 통과하지 못한다. 내용 안에 콜론이 하나 더 있어도 첫 콜론 뒤의 글 전체가 content에 남는다. “예시: 이름: 민지 → 인사말”이라는 줄도 예시 칸으로 인정된다.

22줄의 짧은 표현이 낯설다면 “네 칸의 이름을 순서대로 보면서, 채워진 집합에 없는 이름만 목록에 넣는다”라고 읽는다. 빠진 이름을 집합에서 바로 출력하지 않는 이유는 순서를 유지하기 위해서다. 같은 요청문을 실행할 때마다 같은 순서의 결과가 나오도록 기준을 FIELDS에 두었다.

실행 결과

앞 장에서 사용한 터미널에서 main.py가 있는 폴더로 이동한 상태로 다음 명령을 실행한다. 터미널은 글자로 명령을 입력하고 결과를 보는 창이다.

python3 main.py

예상 출력은 다음과 같다. 사람이 이름이나 요청문을 입력할 차례를 기다리지 않고, 다섯 줄을 출력한 뒤 끝난다.

확인: 검사 3개 통과
요청문 1
네 칸이 모두 채워졌다.
요청문 2
빠진 칸: 입력, 예시

첫 줄은 코드에 넣은 세 검사 사례가 기대 결과와 일치했다는 뜻이다. 요청문 1은 네 칸에 내용이 있으므로 통과한다. 요청문 2는 입력 줄에 콜론만 있고, 예시 줄은 아예 없다. 두 경우 모두 빠진 칸으로 표시된다.

이 출력이 나온다고 해서 요청문이 유용하다는 사실까지 확인된 것은 아니다. 검사 사례에도 “가”, “나” 같은 짧은 글을 넣었다. 프로그램은 그것도 내용으로 인정한다. 따라서 실행으로 확인한 사실은 정한 낱말 규칙대로 동작한다는 데 한정된다. 요청 내용이 실제 목적에 맞는지는 사람이 읽어 확인한다.

실무에서 자주 틀리는 것

칸 이름이 글 어딘가에 있으면 채워졌다고 본다

다음은 잘못된 판정 기준을 따로 실행해 보는 코드다. “입력”이라는 낱말이 있다는 이유만으로 True가 나온다. True는 조건이 맞다고 판단했다는 값이다.

request = "목적: 입력 자료를 정리한다."
print("입력" in request)

이 요청문에는 입력 칸이 없다. 고친 코드는 콜론 앞의 이름과 뒤의 내용을 나누어 확인한다. 다음 코드는 False를 출력한다. False는 조건을 만족하지 않았다는 값이다.

request = "목적: 입력 자료를 정리한다."
label, separator, content = request.partition(":")
print(bool(separator and label.strip() == "입력" and content.strip()))

bool()은 판단 결과를 True나 False로 바꾼다. 단순히 낱말을 찾는 것과 칸의 형식을 확인하는 것은 다른 작업이다.

공백만 있는 내용을 채워진 것으로 센다

문자열에 공백이 들어 있으면 길이가 있으므로 다음 코드는 True를 출력한다. 사람이 보기에는 빈칸이지만 코드에는 공백 글자가 남아 있다.

content = "   "
print(bool(content))

앞뒤 공백을 지운 뒤 판단하면 False가 나온다. 완성 코드의 strip()이 필요한 이유다.

content = "   "
print(bool(content.strip()))

공백을 무시한다는 규칙도 요청문에 적어 두면 좋다. AI가 알아서 같은 기준을 선택할 것이라고 기대하기보다, 필요한 기준을 짧게 밝혀 둔다.

예상 답을 출력하는 것으로 검사를 대신한다

다음 코드는 실행되지만 점검기를 검사하지 않는다. 원하는 문장을 직접 출력했을 뿐이다.

print("빠진 칸: 입력, 예시")

완성 코드의 run_checks() 안에서는 아래처럼 실제 함수의 결과와 기대 목록을 비교해야 한다. 다음 조각은 find_missing이 정의된 완성 코드 안에서 실행하는 검사다.

actual = find_missing("목적: 인사말 만들기\n출력: 한 줄")
expected = ["입력", "예시"]
if actual != expected:
    raise AssertionError("빠진 칸 목록을 확인한다.")

기대 결과는 AI가 만든 함수의 출력에서 복사해 정하지 않는다. 요청문을 읽고 사람이 먼저 정한다. 그래야 구현이 잘못되었을 때 비교가 의미를 갖는다.

한 기능을 확인하기 전에 다른 기능을 끼워 넣는다

요청문 점검기를 만들던 중 아래 코드를 덧붙이면 프로그램은 사람의 입력을 기다린다. Python 문법 자체의 오류는 아니지만, 실행 중 입력을 묻지 않기로 한 이번 요청과 다르다.

request = input("점검할 요청문: ")
print(request)

이번 범위에서는 정해진 자료를 사용한다. 고친 코드는 즉시 출력하고 끝난다.

request = "목적: 인사말을 만든다."
print(request)

수정본을 받았을 때는 실행 결과와 함께 diff를 확인한다. 입력을 기다리는 줄이 새로 생겼는지, 요청하지 않은 기능이 붙었는지 살핀다. 한 번에 하나씩 요청하면 이런 변경을 알아보기 쉽다.

한눈에 보기

첫 요청문을 보내기 전과 코드를 받은 뒤에 확인할 일

확인 대상	좋은 기준	직접 할 일
목적	확인 가능한 동작 하나가 드러난다.	이 프로그램이 할 일을 한 문장으로 읽는다.
입력	자료와 들어오는 방법이 정해져 있다.	입력을 묻는지, 정해진 자료를 쓰는지 확인한다.
출력	보여 줄 곳과 문장의 모양이 정해져 있다.	실행 화면과 요청의 표현을 비교한다.
예시	구체적인 입력과 기대 출력이 짝을 이룬다.	실행 전에 기대 결과를 먼저 적는다.
작업 범위	동작 하나를 먼저 확인할 수 있다.	저장이나 화면 꾸미기는 필요할 때 따로 요청한다.
코드 확인	실행·검사·변경 비교의 근거가 있다.	검사를 실행하고 수정본의 diff를 읽는다.
점검기의 한계	칸의 형식과 내용의 품질을 구분한다.	네 칸을 통과한 요청문도 직접 읽는다.

연습 문제

1. “글자 수를 세는 프로그램을 만들어 줘”를 네 칸 요청문으로 바꾼다. 코드에 미리 적은 “바다”의 글자 수를 세고, 화면에 숫자 하나만 출력하도록 한다. 다른 기능은 추가하지 않는다.
2. 완성 코드의 둘째 요청문에서 “입력:” 뒤에 “코드에 적힌 이름을 사용한다.”를 넣는다. 실행하기 전에 요청문 2의 결과가 어떻게 바뀔지 적고, 실제 출력과 비교한다.
3. 요청문에 “목적: 나중에 정한다”, “입력: 나중에 정한다”, “출력: 나중에 정한다”, “예시: 나중에 정한다”를 각각 한 줄씩 넣었다. 점검 결과를 예상하고, 그 결과만으로 일을 맡기기에 충분한지 설명한다.
4. 새 검사 사례로 “목적: 가”, “입력값: 나”, “출력: 다”, “예시: 라”를 각각 한 줄씩 넣으려 한다. cases에 추가할 기대 목록을 적고, 결과가 그렇게 나오는 이유를 설명한다.

정답과 해설

1. 다음처럼 작성할 수 있다. “바다”를 구체적인 예시로 삼고, 숫자 이외의 설명은 출력하지 않도록 범위를 정한다.

목적: 정해진 문자열의 글자 수를 센다.
입력: 코드에 미리 적은 문자열 “바다”를 사용한다. 실행 중에는 입력을 묻지 않는다.
출력: 화면에 글자 수를 숫자 하나로 출력한다.
예시: “바다” → 2

이 요청에서는 공백이나 여러 줄을 어떻게 셀지까지 다루지 않는다. 그런 자료가 필요해졌을 때 조건과 예시를 추가하면 된다. 지금 정한 자료에 대해 원하는 동작을 확인하는 것이 먼저다.

2. 요청문 2의 결과는 다음 한 줄로 바뀐다. 입력 칸은 채워졌지만 예시 줄은 여전히 없기 때문이다. 검사 사례를 담은 run_checks()는 수정하지 않았으므로 첫 확인 문장의 검사 개수는 그대로다.

빠진 칸: 예시

3. 점검기는 다음 문장을 출력한다.

네 칸이 모두 채워졌다.

각 칸의 이름이 규칙에 맞고, 콜론 뒤에 공백 이외의 글자가 있기 때문이다. 그러나 만들려는 동작, 사용할 자료, 결과의 모양은 정해지지 않았다. 이 결과는 형식이 채워졌다는 뜻이다. “나중에 정한다”를 실제 결정으로 바꾸고, 예시에 입력과 기대 출력을 넣어야 일을 맡길 준비가 된다.

4. 기대 목록은 다음과 같다. 이 코드는 기대 값을 출력해 확인하는 짧은 예다.

expected = ["입력"]
print(expected)

“입력값”은 FIELDS에 있는 “입력”과 다른 이름이다. 사람에게는 뜻이 비슷해 보여도 정한 규칙으로는 입력 칸이 아니다. “입력값”도 인정하고 싶다면 먼저 요청의 규칙을 바꾸고, 그 변경에 맞는 검사를 추가해야 한다. 다음 장에서는 이렇게 받은 코드에서 자료와 조건이 어떤 줄에 놓였는지 차근차근 따라간다.