무엇을 맡기고 무엇을 남길까 - 위임의 판단

이 장에서 배우는 것

앞 장에서 바이브 코딩은 AI에게 일을 맡기는 정도와 사람이 확인하는 정도에 따라 달라진다는 점을 살펴보았다. 이제 작은 메모·할 일 관리 도구에 필요한 작업을 펼쳐 놓고, 어느 일을 맡길지 판단한다. 판단의 출발점은 AI가 그 일을 할 수 있느냐가 아니다. 내가 원하는 결과를 정할 수 있는지, 받은 결과가 맞는지 확인할 수 있는지가 먼저다.

AI는 반복되는 코드를 작성하거나 여러 초안을 만드는 데 도움이 된다. 그러나 편리한 결과와 내 목적에 맞는 결과는 다를 수 있다. 메모를 보기 좋게 출력하는 일과 오래된 메모를 지우는 일은 모두 짧은 코드로 만들 수 있지만, 잘못됐을 때의 영향은 다르다. 이 장에서는 코드 길이보다 위험도와 검증 가능성을 기준으로 위임을 판단한다.

• 반복·초안·변환·탐색 작업에서 AI에게 맡길 부분을 찾는다.
• 목표·우선순위·최종 판단·위험 결정에서 사람이 남겨 둘 책임을 구분한다.
• 작업을 맡기기 전에 결과를 확인할 기준과 방법을 정한다.
• 같은 요청으로 받은 여러 안을 공통 기준으로 비교한다.
• 작업 목록을 ‘맡김/함께/직접’으로 분류하는 Python 프로그램을 읽고 실행한다.

문제 상황

혼자 쓰는 메모·할 일 관리 도구를 만들고 있다고 하자. 현재는 메모 제목과 완료 여부를 화면에 출력하는 정도다. 다음에 하고 싶은 일은 많다. 출력 모양을 정리하고, 목록에 번호를 붙이고, 저장된 자료의 모양을 바꾸고, 오래된 메모를 지우고 싶다. 어떤 기능부터 만들면 좋은지도 AI에게 물어보고 싶다.

이 목록을 한꺼번에 맡기면 AI는 각 작업의 무게를 비슷하게 취급할 수 있다. 화면에 번호를 붙이는 변경은 잘못돼도 출력만 다시 고치면 된다. 반면 오래된 메모를 삭제하는 변경은 필요한 내용을 잃게 할 수 있다. 두 작업이 모두 반복문 하나로 구현된다고 해서 같은 방식으로 맡겨도 되는 것은 아니다.

목표가 불분명한 작업도 있다. “더 편하게 만들어 줘”라는 요청에는 여러 해석이 들어간다. 입력 단계를 줄이는 것이 편할 수도 있고, 삭제 전에 확인하는 것이 편할 수도 있다. 혼자 쓰는 도구에서 무엇을 더 중요하게 여기는지는 사용자인 내가 정해야 한다. AI가 낸 기능 제안은 그 판단에 쓰는 자료다.

따라서 먼저 작업을 나누고, 각각에 대해 잘못됐을 때의 영향과 확인 방법을 적는다. AI에게 맡길지 결정하는 일도 작은 설계 작업이다. 이 장의 프로그램은 그 판단을 대신 끝내는 도구가 아니라, 판단 근거를 빠뜨리지 않도록 표로 보여 주는 도구다.

맡길 일과 사람이 쥘 일을 나눈다

AI에게 맡기기 좋은 작업에는 반복·초안·변환·탐색이라는 공통점이 있다. 해야 할 일이 어느 정도 정해져 있거나, 받은 결과를 재료로 삼아 사람이 다음 결정을 내릴 수 있다. 다만 이 네 가지에 속한다고 자동으로 맡길 수 있는 것은 아니다. 실제 자료를 지우는 반복 작업처럼 위험이 큰 경우도 있다.

작업의 성격에 따라 AI와 사람이 맡는 부분을 나눈다

성격	AI에게 요청할 일	사람이 남길 일
반복	할 일 목록에 번호를 붙이는 코드 작성	시작 번호와 출력 순서 결정
초안	빈 목록 안내 문구 여러 개 제안	사용자에게 맞는 표현 선택
변환	정해진 규칙에 따라 자료 모양 변경	보존할 값과 누락 허용 여부 결정
탐색	저장 방식 후보와 비교 항목 제안	실제 조건 확인과 채택 여부 결정

반복 작업에서는 같은 규칙이 여러 항목에 적용된다. 규칙이 명확하고 작은 예시로 확인할 수 있다면 위임하기 쉽다. 초안 작업에서는 처음부터 한 가지 답을 확정할 필요가 없다. 몇 가지 후보를 받고 골라 쓰면 된다. 변환 작업에서는 바뀌는 부분뿐 아니라 그대로 남아야 할 값도 정해야 한다. 탐색 작업에서는 제안이 빠졌거나 사실과 다른 부분이 없는지 사람이 확인해야 한다.

사람이 쥘 일은 목표·우선순위·최종 판단·위험 결정이다. 목표는 도구로 해결하려는 문제다. 우선순위는 먼저 할 일과 미룰 일을 정하는 기준이다. 최종 판단은 후보 가운데 실제로 쓸 결과를 고르는 일이다. 위험 결정은 실패했을 때 감수할 수 있는 영향을 정하는 일이다. AI에게 의견을 구할 수는 있어도, 그 의견을 받아들일 책임까지 넘길 수는 없다.

예를 들어 AI가 “완료한 할 일을 자동으로 삭제하면 목록이 짧아진다”고 제안할 수 있다. 목록이 짧아지는 것은 장점이다. 그러나 완료 기록을 나중에 찾아보고 싶은 사람에게는 맞지 않는다. 제안이 자연스러워 보이는지와 내 목적에 맞는지는 별개로 확인한다.

이 장에서 ‘맡김’은 AI에게 초안 구현을 요청하고 정해 둔 기준으로 확인한다는 뜻이다. ‘함께’는 사람이 조건을 더 구체적으로 정하고 작은 예시의 결과를 살피면서 진행한다는 뜻이다. ‘직접’은 사람이 결정이나 검증 방법 마련을 주도한다는 뜻이다. 직접으로 분류했다고 AI의 설명이나 의견을 이용하지 못하는 것은 아니다.

세 분류 모두 사람의 확인을 포함한다. 차이는 사람이 어디에 얼마나 개입하느냐다. 간단한 출력 변경은 완성된 초안을 받아 확인할 수 있다. 자료 변환은 입력과 결과를 대조하면서 진행하는 편이 낫다. 실제 메모 삭제는 삭제 대상과 복구 방법을 사람이 먼저 정해야 한다.

검증 방법을 먼저 정한다

검증은 결과가 정한 조건을 만족하는지 확인하는 일이다. “실행된다”는 조건 하나만으로는 부족하다. 할 일 세 개를 출력하는 코드가 오류 없이 실행돼도 두 개만 보여 준다면 목적을 이루지 못했다. 실행 성공과 작업 성공을 구분해야 한다.

이 장의 원칙은 결과를 검증할 방법이 없으면 그 상태로 맡기지 않는다는 것이다. 확인 방법이 없다는 이유로 작업을 포기하라는 뜻은 아니다. 사람이 먼저 기대 결과를 정하거나, 작업을 더 작게 나눠 확인 가능한 상태로 바꾸라는 뜻이다.

확인 기준은 요청을 보내기 전에 적는다. 결과를 보고 나서 기준을 만들면 AI가 만든 결과를 받아들이기 쉬운 방향으로 기준이 바뀔 수 있다. “목록에 번호를 붙인다”는 작업이라면 번호가 1부터 시작하는지, 항목 순서가 유지되는지, 빈 목록에서 잘못된 번호를 출력하지 않는지를 먼저 정한다.

작업을 맡기기 전에 기대 결과와 확인 방법을 짝지어 둔다

작업	확인 기준	확인 방법
목록 번호 붙이기	1부터 시작하고 순서를 유지한다	세 항목과 빈 목록의 출력을 비교한다
안내 문구 초안	다음 행동을 알 수 있고 길이가 짧다	후보마다 같은 기준으로 직접 읽는다
저장 자료 변환	항목 수와 제목이 보존된다	작은 입력의 변환 전후 값을 대조한다
오래된 메모 삭제	정한 대상만 삭제되며 복구할 수 있다	복사한 자료에서 대상과 복구 결과를 확인한다

모든 검증이 자동화되는 것은 아니다. 안내 문구가 이해하기 쉬운지는 사람이 읽어서 판단할 수 있다. 이때도 “마음에 든다”보다 “비어 있다는 사실과 다음 행동을 한 문장으로 알려 준다”처럼 기준을 구체적으로 적는 편이 좋다. 자동으로 확인하기 어렵다는 것과 확인 방법이 없다는 것은 다르다.

위험도는 잘못된 결과가 미치는 영향과 되돌리기 어려운 정도를 함께 보고 정한다. 여기서는 화면 표현 변경을 ‘낮음’, 보존해야 할 자료의 모양을 바꾸는 일을 ‘보통’, 실제 자료 삭제나 중요한 사용 방침 결정을 ‘높음’으로 적는다. 이는 이 예제의 기준이며 모든 프로젝트에 그대로 적용되는 규칙은 아니다.

그림의 분류 순서는 중요하다. 먼저 검증 방법이 있는지 확인한다. 없으면 위험도가 낮아 보여도 직접으로 분류한다. 검증 방법이 있더라도 위험이 높으면 사람이 주도한다. 남은 작업 가운데 위험도가 보통이면 함께, 낮으면 맡김으로 분류한다.

분류는 작업의 영구적인 속성이 아니다. 실제 메모를 삭제하는 작업은 직접으로 남겨 두되, “삭제할 후보를 화면에만 출력한다”는 작은 작업은 별도로 분리할 수 있다. 실제 자료를 바꾸지 않고 후보 목록을 확인할 수 있게 되면 위험도와 검증 가능성을 다시 판단할 수 있다.

여러 안을 같은 기준으로 비교한다

AI에게 한 가지 결과만 받으면 그 결과가 선택의 기준이 되기 쉽다. 초안과 탐색에서는 같은 요청으로 여러 안을 받아 비교할 수 있다. 이때 요청 조건과 확인 기준을 유지해야 한다. 한 안에는 간결함을 요구하고 다른 안에는 자세함을 요구하면 무엇이 더 적합한지 비교하기 어렵다.

빈 할 일 목록의 안내 문구를 고르는 상황을 생각해 보자. 먼저 기준을 “빈 상태와 다음 행동을 한 문장으로 알리고, 공백과 문장부호를 포함해 40자 이내로 쓴다”로 정한다. 다음은 AI에게 보낼 수 있는 요청과 가상의 답이다.

혼자 쓰는 할 일 도구에서 목록이 비었을 때 보여 줄 문구를 세 가지 제안하라. 각 문구는 공백과 문장부호를 포함해 40자 이내로 쓴다. 할 일이 없다는 사실과 새 할 일을 추가할 수 있다는 사실을 한 문장으로 알린다.

안 A: 할 일이 없다. 새 할 일을 추가할 수 있다.
안 B: 할 일이 없으니 새 할 일을 추가해 보자.
안 C: 새 할 일을 추가할 수 있다.

세 문구를 요청 전에 정한 동일한 기준으로 비교한다

후보	빈 상태와 다음 행동	길이·문장 기준	판단
A	둘 다 알린다	40자 이내지만 두 문장이다	문장 수를 고친 뒤 재검토한다
B	둘 다 알린다	40자 이내이며 한 문장이다	기준을 충족한 후보로 남긴다
C	빈 상태를 알리지 않는다	40자 이내이며 한 문장이다	내용을 보완해야 한다

세 답이 비슷해 보인다고 다 맞는 것은 아니다. 반대로 여러 답이 같은 내용을 말한다고 사실이 확인된 것도 아니다. 코드 후보를 비교할 때는 같은 입력과 같은 기대 결과로 실행한다. 설명이 길거나 자신 있게 쓰였다는 이유로 선택하지 않는다.

선택한 코드도 그대로 믿지 않는다. 작은 테스트, 즉 입력을 주고 기대 결과와 비교하는 확인을 실행하고, 수정 전후의 차이인 diff를 읽는다. 목록 번호만 요청했는데 삭제 기능까지 바뀌었다면 변경 이유를 확인해야 한다. 이 장에서는 분류 규칙을 짧은 검사 코드로 확인하고, 실제 변경이 작업 목록·분류 함수·출력 부분 중 어디에 생겼는지 살펴본다.

완성 코드

다음 코드를 main.py에 저장한다. 위험도는 사람이 입력한 값이다. 검증 가능성은 앞서 정한 확인 방법이 있는지를 뜻한다. 프로그램은 그 입력을 바탕으로 분류 표를 출력한다. 실제 메모를 읽거나 바꾸지 않으며 외부 패키지도 사용하지 않는다.

VALID_RISKS = ("낮음", "보통", "높음")

TASKS = [
    ("목록 번호 붙이기", "낮음", True),
    ("빈 목록 문구 초안", "낮음", True),
    ("저장 형식 후보 탐색", "낮음", False),
    ("저장 자료 변환", "보통", True),
    ("완료 표시 방식 변경", "보통", True),
    ("오래된 메모 삭제", "높음", True),
    ("다음 기능 우선순위 결정", "높음", False),
]


def classify(risk, can_verify):
    if risk not in VALID_RISKS:
        raise ValueError("위험도는 낮음, 보통, 높음 중 하나여야 한다.")
    if type(can_verify) is not bool:
        raise ValueError("검증 가능성은 True 또는 False여야 한다.")

    if not can_verify:
        return "직접", "확인 방법부터 정한다"
    if risk == "높음":
        return "직접", "위험 결정을 사람이 주도한다"
    if risk == "보통":
        return "함께", "조건과 결과를 단계마다 확인한다"
    return "맡김", "기준을 정하고 받은 결과를 확인한다"


def check_rules():
    expected = [
        ("낮음", True, "맡김"),
        ("보통", True, "함께"),
        ("높음", True, "직접"),
        ("낮음", False, "직접"),
        ("보통", False, "직접"),
        ("높음", False, "직접"),
    ]
    for risk, can_verify, decision in expected:
        actual, _ = classify(risk, can_verify)
        if actual != decision:
            raise AssertionError("분류 규칙과 결과가 다르다.")


def main():
    check_rules()
    counts = {"맡김": 0, "함께": 0, "직접": 0}
    print("위임 판단표")
    print("작업 | 위험도 | 검증 가능 | 분류 | 확인 방향")
    for title, risk, can_verify in TASKS:
        decision, reason = classify(risk, can_verify)
        counts[decision] += 1
        verification = "예" if can_verify else "아니오"
        print(f"{title} | {risk} | {verification} | {decision} | {reason}")
    print()
    print(f"합계: 맡김 {counts['맡김']} / 함께 {counts['함께']} / 직접 {counts['직접']}")
    print("규칙 검사: 6개 조합 통과")


if __name__ == "__main__":
    main()

줄별 해설

VALID_RISKS는 허용하는 위험도 세 가지를 담는다. 괄호로 묶인 값의 모음은 튜플이다. 여기서는 변경하지 않을 선택지를 보관한다. TASKS는 작업 목록이며, 각 항목은 작업명·위험도·검증 가능성 순서로 값을 담는다.

True와 False는 참과 거짓을 나타내는 값이다. 이 프로그램에서 True는 결과가 이미 맞다는 뜻이 아니다. 결과를 확인할 방법을 사람이 마련했다는 뜻이다. “저장 형식 후보 탐색”은 현재 비교 기준과 사실 확인 방법을 준비하지 않았다고 가정해 False로 적었다.

def classify(risk, can_verify):는 분류 함수를 정의한다. 첫 번째 if는 위험도가 허용한 값인지 확인한다. not in은 값의 모음에 포함되지 않았다는 뜻이다. 잘못된 입력이면 raise ValueError로 입력 오류를 알리고 실행을 멈춘다. 모르는 위험도를 낮음으로 취급하지 않도록 한 것이다.

다음 조건은 검증 가능성에 참·거짓 값이 들어왔는지 확인한다. type은 값의 자료형을 확인하고, bool은 참·거짓 자료형을 가리킨다. is not으로 그 자료형이 다른지 검사한다. 글자 "아니오"를 넣는 실수와 올바른 False를 구분하려는 검사다.

if not can_verify:는 확인 방법이 없는 경우를 먼저 처리한다. 이어서 높은 위험과 보통 위험을 차례로 처리한다. 함수는 해당 조건에서 분류와 이유를 함께 반환한다. 모든 조건을 지나온 입력은 검증 가능하고 위험도가 낮으므로 마지막 줄에서 맡김을 반환한다.

check_rules 함수의 expected에는 세 위험도와 두 검증 상태를 조합한 여섯 가지 기대 결과가 들어 있다. 반복문은 각 조합을 함수에 넣는다. actual, _는 반환된 분류와 이유를 나눠 받으며, 밑줄 변수에는 이번 검사에서 사용하지 않을 이유를 담는다.

actual != decision은 실제 분류와 기대 분류가 다른지 확인한다. 다르면 AssertionError로 검사가 실패했음을 알린다. 기대 결과는 확인 기준을 코드로 적은 것이다. 검사가 통과했다고 사람이 입력한 위험도까지 올바르다는 뜻은 아니다.

main은 먼저 규칙 검사를 실행한다. 이어서 분류별 개수를 담은 딕셔너리 counts를 만든다. 딕셔너리는 이름을 통해 값을 찾는 자료 구조다. 여기서는 ‘맡김’이라는 이름으로 그 작업 수를 찾는다. 처음에는 모두 0이다.

두 개의 print가 제목과 열 이름을 출력한다. 반복문은 작업의 세 값을 나눠 받아 분류하고, counts[decision] += 1로 해당 개수를 늘린다. 조건이 들어간 대입문은 참·거짓 값을 화면에 표시할 ‘예’와 ‘아니오’로 바꾼다. f가 붙은 문자열은 중괄호 안의 값을 문장에 넣는다.

인수가 없는 print()는 빈 줄을 출력한다. 뒤의 두 줄은 합계와 검사 결과를 알린다. 마지막 조건은 이 파일을 직접 실행했을 때 main을 호출한다. 시각·난수·네트워크를 사용하지 않으므로 같은 파일과 작업 목록으로 실행하면 같은 출력이 나온다.

실행 결과

macOS나 Linux에서 Python 3.12 이상을 사용한다. main.py가 있는 위치에서 다음 명령을 실행한다.

python3 main.py

예상 출력은 다음과 같다. 열 사이의 세로줄은 항목을 구분하기 위한 문자이며, 별도의 표 출력 기능을 사용하지 않는다.

위임 판단표
작업 | 위험도 | 검증 가능 | 분류 | 확인 방향
목록 번호 붙이기 | 낮음 | 예 | 맡김 | 기준을 정하고 받은 결과를 확인한다
빈 목록 문구 초안 | 낮음 | 예 | 맡김 | 기준을 정하고 받은 결과를 확인한다
저장 형식 후보 탐색 | 낮음 | 아니오 | 직접 | 확인 방법부터 정한다
저장 자료 변환 | 보통 | 예 | 함께 | 조건과 결과를 단계마다 확인한다
완료 표시 방식 변경 | 보통 | 예 | 함께 | 조건과 결과를 단계마다 확인한다
오래된 메모 삭제 | 높음 | 예 | 직접 | 위험 결정을 사람이 주도한다
다음 기능 우선순위 결정 | 높음 | 아니오 | 직접 | 확인 방법부터 정한다

합계: 맡김 2 / 함께 2 / 직접 3
규칙 검사: 6개 조합 통과

받은 코드를 확인할 때는 이 출력과 실제 출력을 대조한다. 규칙 검사 문구가 보이는지, 작업 일곱 개가 모두 나오는지, 분류별 합계가 맞는지도 확인한다. 코드가 수정됐다면 변경 전후의 차이를 읽고 요청하지 않은 자료 변경이나 삭제가 추가되지 않았는지 살핀다.

이 원고의 코드는 여기서 실제 실행한 결과를 첨부한 것이 아니다. 따라서 위 출력은 코드에서 도출한 예상 결과다. 독자의 환경에서 실행해 확인하는 과정까지가 검증에 포함된다.

실무에서 자주 틀리는 것

위험도가 낮다는 이유만으로 맡긴다

다음 코드는 확인 방법이 없는데도 낮은 위험이라는 이유로 맡김을 출력한다. 실행되는 코드라도 이 장의 원칙을 만족하지 못한다.

risk = "낮음"
can_verify = False
decision = "맡김" if risk == "낮음" else "직접"
print(decision)

고친 코드는 검증 가능성을 먼저 확인한다. 확인할 수 없으면 사람이 기준을 마련하도록 직접으로 남긴다.

risk = "낮음"
can_verify = False
if not can_verify:
    decision = "직접"
elif risk == "높음":
    decision = "직접"
elif risk == "보통":
    decision = "함께"
else:
    decision = "맡김"
print(decision)

‘아니오’라는 글자를 거짓으로 생각한다

내용이 있는 문자열은 조건문에서 참으로 처리된다. 다음 코드는 글자의 의미와 달리 “확인 방법 있음”을 출력한다.

can_verify = "아니오"
if can_verify:
    print("확인 방법 있음")
else:
    print("확인 방법 없음")

판단에 쓰는 값은 참·거짓으로 저장하고, 화면에 보일 때 문구로 바꾼다. 완성 코드의 자료형 검사도 이런 실수를 찾기 위해 넣었다.

can_verify = False
label = "예" if can_verify else "아니오"
print(f"검증 가능: {label}")

실행 성공만 확인한다

다음 코드는 결과를 출력하고 성공이라고 선언한다. 예상한 분류가 직접이어야 한다는 조건을 확인하지 않는다.

actual = "맡김"
expected = "직접"
print(actual)
print("실행 성공")

고친 예시는 의도적으로 잘못된 결과를 넣어 실패를 잡는지 보여 준다. 이 코드를 따로 실행하면 오류가 발생하는 것이 예상 결과다. 실제 분류 함수의 결과를 검사할 때도 같은 방식으로 비교한다.

actual = "맡김"
expected = "직접"
if actual != expected:
    raise AssertionError("기대 분류와 실제 분류가 다르다.")
print("검사 통과")

모르는 입력을 기본값으로 넘긴다

아래 코드는 오타가 있는 위험도를 맡김으로 처리한다. 입력을 이해하지 못했는데도 낮은 위험과 같은 결정을 내린다.

risk = "노픔"
if risk == "높음":
    print("직접")
elif risk == "보통":
    print("함께")
else:
    print("맡김")

먼저 허용한 값인지 확인하면 오타를 수정할 수 있다. 고친 코드 역시 잘못된 입력을 보여 주기 위한 예시이므로 실행하면 입력 오류로 끝난다.

risk = "노픔"
if risk not in ("낮음", "보통", "높음"):
    raise ValueError("위험도 입력을 확인한다.")
if risk == "높음":
    print("직접")
elif risk == "보통":
    print("함께")
else:
    print("맡김")

한눈에 보기

검증 가능성과 위험도로 이 예제의 위임 방식을 정한다

검증 가능	위험도	분류	사람이 할 일
아니오	모든 수준	직접	기준과 확인 방법을 먼저 마련한다
예	높음	직접	위험과 실행 여부를 결정한다
예	보통	함께	조건과 결과를 단계마다 대조한다
예	낮음	맡김	받은 결과를 기준대로 확인한다

AI에게 맡기는 범위는 반복·초안·변환·탐색에서 찾되, 목표와 우선순위와 최종 판단은 사람이 쥔다. 여러 안은 같은 기준으로 비교하고, 코드가 돌아간다는 사실과 목적을 만족한다는 사실을 따로 확인한다. 다음 장에서는 이 판단을 바탕으로 요청을 한 장짜리 기획서로 정리한다.

연습 문제

1. 작업 목록에 ‘목록 구분선 출력’을 추가하라. 위험도는 낮음, 검증 가능성은 참으로 둔다. 새 작업의 분류와 실행 후 합계를 예상하고 실제 출력과 비교하라.

2. ‘저장 형식 후보 탐색’에 확인 방법을 마련했다고 가정하라. 이 작업의 검증 가능성을 참으로 바꾸면 분류가 어떻게 달라지는지 설명하라. 참으로 표시하기 전에 마련해야 할 확인 방법도 하나 적어라.

3. 확인 방법이 있는 모든 작업을 맡김으로 바꾸자는 제안이 나왔다. 완성 코드의 작업 가운데 이 제안의 문제를 보여 주는 예를 두 개 고르고 이유를 설명하라.

4. AI에게 빈 목록 안내 문구 세 가지를 요청하려 한다. 요청 전에 확인 기준 두 가지를 정하고, 후보들이 모두 그 기준을 통과했을 때 사람이 무엇을 결정해야 하는지 적어라.

정답과 해설

1. 다음 항목을 TASKS 목록에 추가한다. 분류는 맡김이다. 합계는 맡김 3, 함께 2, 직접 3이 된다. 전체 작업 수는 여덟 개지만 분류 규칙의 조합은 바뀌지 않으므로 검사 문구는 여전히 6개 조합 통과다.

   new_task = ("목록 구분선 출력", "낮음", True)
   print(new_task)
   

   위 코드는 추가할 항목의 값을 따로 확인하는 실행 예시다. main.py에는 출력 코드를 덧붙이지 않고 해당 튜플을 작업 목록에 넣는다. 변경 전후의 차이에 새 항목만 추가됐는지 살핀다.

2. 위험도가 낮음이고 검증 가능성이 참이므로 직접에서 맡김으로 바뀐다. 예를 들어 ‘표준 라이브러리만 사용 가능한가’, ‘작은 메모 목록을 저장하고 다시 읽을 수 있는가’를 비교 기준으로 정하고, 후보의 설명과 작은 실행 예시로 확인할 수 있다. 확인 방법을 실제로 준비한 뒤 값을 바꾼다. 분류가 바뀌어도 저장 방식의 최종 선택은 사람이 한다.

3. ‘저장 자료 변환’과 ‘오래된 메모 삭제’가 예가 된다. 자료 변환은 확인 방법이 있어도 보존해야 할 값을 단계마다 대조해야 하므로 함께로 분류한다. 메모 삭제는 확인 방법이 있어도 무엇을 지워도 되는지와 복구 가능한지를 사람이 결정해야 하므로 직접으로 분류한다. 검증 가능성은 위험도를 없애지 않는다.

4. 기준의 예는 ‘빈 상태와 추가 행동을 모두 알린다’와 ‘공백과 문장부호를 포함해 40자 이내인 한 문장이다’다. 후보들이 모두 통과하면 사람이 도구의 말투와 사용 목적에 맞는 문구를 고른다. 기준 통과는 후보를 남기는 근거이며 최종 선택을 자동으로 정해 주지는 않는다.