프로젝트 지침 파일 - 다음 세션에도 이어지는 규칙

이 장에서 배우는 것

앞 장에서 오류를 다시 일으키는 조건을 정리하고, 원인을 가정한 뒤 실행으로 확인했다. 그 과정에서 같은 설명을 여러 번 했을 수 있다. “이 도구는 외부 패키지를 쓰지 않는다”, “예제 데이터는 실제 메모와 분리한다”, “수정 뒤에는 이 명령으로 확인한다” 같은 설명이다. 이런 규칙은 다음 작업에서도 필요하다. 대화 속에만 두면 새 세션을 시작할 때 다시 전달해야 한다.

이 장에서는 혼자 쓰는 메모·할 일 관리 도구에 프로젝트 지침 파일을 붙인다. 지침 파일은 반복해서 적용할 규칙을 모은 문서다. 마지막에는 지침의 필수 절이 빠졌는지, 정한 길이 제한을 넘었는지 검사하는 Python 프로그램을 만든다. 문서를 검사하는 프로그램도 AI에게 맡겼다는 이유만으로 믿지 않고, 정상 입력과 잘못된 입력을 함께 실행해 확인한다.

• 사람을 위한 프로젝트 소개와 에이전트를 위한 작업 지침을 구분한다.
• 실행·테스트 명령, 코드 관례, 금지 사항, 폴더 경계를 짧게 기록한다.
• 폴더별 지침의 적용 범위와 충돌 처리 원칙을 설명한다.
• 지속할 규칙, 작업 기록, 인계 메모를 나누어 관리한다.
• 지침 텍스트의 필수 절과 길이를 검사하고, 검사의 한계를 설명한다.

문제 상황

메모 도구의 검색 오류를 고친 다음 날, 새 대화에서 AI에게 완료한 할 일을 숨기는 기능을 요청했다고 하자. 어제는 표준 라이브러리만 사용한다고 설명했다. 오늘의 대화에는 그 설명이 없다. AI는 화면을 다루는 외부 패키지를 제안하고, 예제에 쓰던 파일 이름을 실제 저장 파일 이름으로 바꾼다. 코드는 실행될 수 있지만 프로젝트의 약속과 어긋난다.

문제는 새 기능의 설명이 부족하다는 데만 있지 않다. 기능을 바꾸어도 유지해야 할 조건이 대화에 흩어져 있다. 실행 방법은 첫 대화에, 테스트 방법은 오류 수정 대화에, 데이터 파일을 건드리지 말라는 말은 중간 답변에 있다. 사람도 이 기록을 모두 찾아 읽기 어렵다.

완료한 할 일을 숨기는 기능을 추가하라. 먼저 프로젝트 지침을 읽고 적용할 규칙을 요약하라. 변경 뒤에는 실행 결과와 테스트 결과를 보여 주고, 변경 전후의 차이를 검토할 수 있게 정리하라.

이 요청이 유용하려면 실제 지침이 있어야 한다. “지난번처럼 하라”는 말은 지난번의 어느 부분을 뜻하는지 분명하지 않다. “지침을 읽으라”는 말도 지침에 실행 방법이 없으면 충분하지 않다. 반복되는 약속을 파일로 옮기고, 현재 작업의 요구는 이번 요청에 남겨야 한다.

지침을 적었다고 규칙 준수가 보장되지는 않는다. AI가 읽은 규칙을 짧게 되짚게 하고, 받은 코드의 실행·테스트·변경 내역을 확인해야 한다. 변경 내역을 비교한 결과를 디프(diff)라고 한다. 지침은 검토할 기준을 제공하고, 디프는 실제 수정이 그 기준에 맞는지 판단할 재료를 제공한다.

에이전트를 위한 README에 무엇을 적을까

README는 프로젝트를 처음 접한 사람이 목적과 사용법을 찾는 안내 문서다. 에이전트(agent)는 요청에 따라 파일을 읽고 코드를 수정하며 명령을 실행하는 AI 작업 주체를 뜻한다. 에이전트를 위한 README라는 표현은 이 작업 주체에게 필요한 안내를 따로 정리한다는 의미다. 사람도 읽을 수 있지만, 중심 질문은 “무슨 프로젝트인가”보다 “여기서 어떻게 작업해야 하는가”다.

이 장에서는 지침 파일의 이름을 AGENTS.md로 정한다. 이 이름 자체가 Python의 기능은 아니다. 파일을 만들었다고 Python이 읽거나 규칙을 적용하지 않는다. 사용하는 도구가 지침 파일을 어떻게 찾는지 확인하고, 필요하면 요청에서 읽을 파일을 직접 지정해야 한다. 제품별 자동 탐색과 적용 방식은 다를 수 있으므로, 이 장의 폴더 예시는 프로젝트에서 정한 운영 원칙으로 이해한다.

지침에 남길 정보와 이번 요청에 남길 정보를 구분한다

정보	둘 곳	작성 예
반복되는 실행 방법	프로젝트 지침	루트에서 python3 main.py를 실행한다.
검증 방법	프로젝트 지침	검사 예제를 모두 실행하고 예상 출력과 비교한다.
코드 관례	프로젝트 지침	함수 이름은 소문자와 밑줄로 쓴다.
데이터 보호 규칙	프로젝트 지침	사용자의 저장 파일을 예제 데이터로 덮어쓰지 않는다.
오늘 추가할 기능	이번 작업 요청	완료한 할 일을 목록에서 숨기는 선택을 추가한다.
작업 중 발견한 미완료 항목	인계 메모	빈 검색어의 처리는 아직 확인하지 않았다.

실행 명령에는 실행 위치도 적는다. 같은 명령이라도 어느 폴더에서 실행하는지에 따라 읽는 파일이 달라질 수 있다. 테스트 명령에는 통과 조건을 덧붙인다. “테스트를 실행한다”보다 “모든 검사 예제가 통과하고 기본 출력이 예상 결과와 같아야 한다”가 검토에 도움이 된다.

코드 관례는 프로젝트에서 실제로 지키는 몇 가지로 제한한다. 이름 규칙, 입력과 출력의 분리, 오류를 사용자에게 표시하는 방식 정도면 작은 도구의 출발점으로 충분하다. Python 문법 전체를 다시 설명할 필요는 없다. 금지 사항도 행동을 판단할 수 있게 쓴다. “위험한 일을 하지 않는다”보다 “예제 실행에서 사용자의 저장 파일을 수정하지 않는다”가 구체적이다.

폴더 경계는 파일을 둘 위치와 수정 범위를 알려 준다. 메모 도구에서 예제 자료를 examples에, 개인 데이터를 data에 둔다면 각각의 역할을 적는다. 다만 폴더 경계는 문서상의 약속이다. 파일 접근을 기술적으로 막는 권한 설정과는 다르다. AI가 수정한 파일 목록을 살펴보는 과정이 여전히 필요하다.

실행: 프로젝트 루트에서 python3 main.py를 실행한다.

테스트: 기본 실행에 포함된 검사 예제가 모두 통과해야 한다.

코드 관례: 표준 라이브러리만 사용하고 함수 이름은 소문자와 밑줄로 쓴다.

금지 사항: 사용자 저장 파일을 예제 데이터로 덮어쓰지 않는다.

폴더 경계: examples는 예제 자료, data는 사용자 저장 자료를 위한 위치다.

이 예시의 실행 명령은 이번 장의 검사 도구에 맞춘 것이다. 실제 메모 도구에 옮길 때에는 그 프로젝트에서 확인한 명령으로 바꿔야 한다. 그럴듯한 명령을 적는 것과 실행해 본 명령을 적는 것은 다르다. 지침을 처음 만들거나 실행 방법을 바꿀 때에는 적어 놓은 명령을 직접 실행한다.

짧은 지침은 필요한 규칙을 찾기 쉽다. 모든 설명을 삭제하라는 뜻은 아니다. 판단에 필요한 문장을 남기고, 긴 배경 설명과 지난 작업의 대화는 다른 문서로 옮긴다. 이 장의 프로그램은 연습을 위해 600자라는 제한을 사용한다. 이는 제품의 입력 한도나 보편적인 적정 길이가 아니라, 문서가 길어졌음을 알아채기 위한 프로젝트 내부 기준이다.

폴더별 지침과 충돌 처리

프로젝트가 커지면 루트의 규칙만으로 설명하기 어려운 부분이 생긴다. 루트는 프로젝트의 가장 바깥 폴더를 뜻한다. 예를 들어 전체 코드에서는 표준 라이브러리만 사용하고, examples 폴더에서는 개인 이름이나 실제 메모를 예제에 넣지 않기로 정할 수 있다. 이때 examples 안의 지침은 그 폴더에서 작업할 때 필요한 규칙만 담는다.

이 프로젝트에서는 루트 지침을 공통 규칙으로 삼고, 하위 폴더 지침은 해당 폴더와 그 아래에 적용한다고 정한다. 같은 주제를 더 구체적으로 설명하는 하위 지침은 그 범위에서 우선 적용하되, 공통 금지 사항을 바꾸려면 루트 지침도 함께 검토하도록 한다. 서로 다른 폴더의 규칙이 자동으로 모두 합쳐진다고 가정하지 않는다.

이것은 이 책의 예제에서 정한 규칙이다. 실제 에이전트 도구의 탐색 범위와 우선순위가 같다고 단정해서는 안 된다. 지침을 읽는 순서와 충돌 처리 방식은 도구에서 확인해야 한다. 요청에 “루트 지침과 수정할 폴더의 지침을 읽고, 서로 어긋나는 항목이 있으면 구현 전에 알려 달라”를 넣으면 적용 근거를 검토하기 쉽다.

examples의 자료를 수정하라. 루트와 examples의 지침을 읽고 이 작업에 적용할 규칙을 요약하라. 공통 금지 사항과 폴더 지침이 충돌하면 충돌한 문장을 제시하고 먼저 확인하라.

AI가 “하위 지침이 더 가까우므로 무엇이든 덮어쓸 수 있다”고 답한다면 프로젝트의 충돌 처리 원칙과 맞지 않는다. 특히 “사용자 데이터를 수정하지 않는다”와 “검증을 위해 data의 내용을 초기화한다”가 함께 있으면 그냥 진행하지 않는다. 어느 파일을 어떻게 바꿀지 구체적으로 확인해야 한다.

이번 요청에서 예외를 허용했다고 해서 지속할 지침을 조용히 바꾸어서는 안 된다. 한 번만 다른 출력 형식을 쓰라는 요구는 이번 작업에 한정한다. 앞으로도 같은 형식을 쓰기로 결정했다면 지침을 수정하고 그 변경을 디프에서 별도로 확인한다. 코드 변경과 규칙 변경은 각각 검토할 대상이다.

작업 기록과 인계 메모를 따로 남긴다

작업 기록은 무엇을 바꾸었고 무엇을 확인했는지 적은 기록이다. 인계 메모는 다음 작업자가 어디서 이어 시작할지 알려 주는 짧은 문서다. 여기서 다음 작업자는 다른 사람일 수도 있고, 새 세션의 AI일 수도 있다. 두 문서는 프로젝트 지침과 목적이 다르다.

“외부 패키지를 쓰지 않는다”는 계속 적용할 규칙이다. “검색 함수의 빈 입력 처리를 고쳤다”는 완료한 작업 기록이다. “줄바꿈이 포함된 메모는 아직 확인하지 않았다”는 다음 작업을 위한 상태 정보다. 이를 모두 지침에 넣으면 오래된 진행 상황이 현재 규칙처럼 보일 수 있다.

규칙과 상태를 구분하면 다음 세션에서 확인할 일이 분명해진다

기록 종류	답하는 질문	남길 내용
프로젝트 지침	계속 지킬 약속은 무엇인가	실행·테스트 방법과 수정 범위
작업 기록	무엇을 바꾸고 확인했는가	변경 요약, 실행 결과, 테스트 결과
인계 메모	어디서 이어 시작하는가	현재 상태, 미확인 항목, 다음 행동

현재 상태: 검색 결과에서 완료한 할 일을 제외하는 처리를 추가했다.

확인한 것: 빈 목록과 완료 항목만 있는 목록을 실행해 결과를 확인했다.

미확인 항목: 파일에서 읽은 데이터에 같은 처리가 적용되는지는 아직 확인하지 않았다.

다음 행동: 파일 입력 예제를 확인한 뒤 변경 내역을 검토한다.

“모두 잘된다”는 인계 메모보다 확인한 범위와 확인하지 않은 범위를 나눈 메모가 유용하다. 명령이 실패했다면 실패 결과도 적는다. 실행하지 않은 테스트를 통과했다고 쓰지 않는다. 다음 세션에서는 메모의 주장을 현재 파일과 대조하고, 필요한 검증을 다시 실행한다.

작업이 끝나면 인계 메모도 갱신한다. 해결된 항목을 계속 미완료로 남겨 두면 다음 작업자가 이미 끝난 일을 반복할 수 있다. 반대로 작업 기록에는 당시의 검증 범위를 남겨, 어떤 근거로 완료를 판단했는지 추적할 수 있게 한다.

완성 코드

다음 코드를 main.py로 저장한다. 별도의 지침 파일 없이 실행할 수 있도록 두 문서의 텍스트를 프로그램 안에 넣었다. 검사 함수는 전달받은 문자열을 읽는다. 실제 파일을 검사하려면 파일에서 읽은 문자열을 같은 함수에 전달하면 된다. 기본 실행은 파일을 만들거나 수정하지 않는다.

검사할 필수 절은 실행, 테스트, 코드 관례, 금지 사항, 폴더 경계다. 절은 문서에서 같은 주제를 묶은 부분이다. 이 프로그램에서는 앞뒤 공백을 제거한 줄이 “## ”로 시작하면 절 제목으로 본다. 본문에서 단어를 찾는 것보다 제목의 존재를 분명하게 검사할 수 있다.

REQUIRED_SECTIONS = (
    "실행",
    "테스트",
    "코드 관례",
    "금지 사항",
    "폴더 경계",
)
MAX_CHARS = 600

GOOD_RULES = """## 실행
프로젝트 루트에서 python3 main.py를 실행한다.

## 테스트
기본 실행의 검사 예제가 모두 통과해야 한다.

## 코드 관례
표준 라이브러리만 사용한다.
함수 이름은 소문자와 밑줄로 쓴다.

## 금지 사항
사용자 저장 파일을 예제 데이터로 덮어쓰지 않는다.

## 폴더 경계
examples는 예제 자료를 둔다.
data는 사용자 저장 자료를 둔다.
"""

BAD_RULES = (
    "## 실행\n프로젝트 루트에서 python3 main.py를 실행한다.\n\n"
    "## 테스트\n기본 실행의 검사 예제를 확인한다.\n\n"
    + "오늘 요청한 버튼 색상을 바꾼다. " * 80
)


def collect_sections(text):
    sections = set()
    for line in text.splitlines():
        line = line.strip()
        if line.startswith("## "):
            title = line[3:].strip()
            sections.add(title)
    return sections


def inspect_rules(text, max_chars=MAX_CHARS):
    sections = collect_sections(text)
    missing = []
    for title in REQUIRED_SECTIONS:
        if title not in sections:
            missing.append(title)
    too_long = len(text) > max_chars
    return missing, too_long


def run_tests():
    assert inspect_rules(GOOD_RULES) == ([], False)
    assert inspect_rules("") == (list(REQUIRED_SECTIONS), False)
    assert inspect_rules(BAD_RULES) == (
        ["코드 관례", "금지 사항", "폴더 경계"],
        True,
    )
    assert inspect_rules(GOOD_RULES, len(GOOD_RULES)) == ([], False)
    assert inspect_rules(GOOD_RULES, len(GOOD_RULES) - 1) == ([], True)


def print_report(name, text):
    missing, too_long = inspect_rules(text)
    print(f"[{name}]")
    if missing:
        print("필수 절: 누락 - " + ", ".join(missing))
    else:
        print("필수 절: 모두 있음")
    if too_long:
        print(f"길이: {MAX_CHARS}자 초과")
    else:
        print(f"길이: {MAX_CHARS}자 이하")
    if missing or too_long:
        print("판정: 수정 필요")
    else:
        print("판정: 형식 검사 통과")


def main():
    run_tests()
    print("검사 예제: 5개 통과")
    print_report("기본 지침", GOOD_RULES)
    print()
    print_report("수정할 지침", BAD_RULES)


if __name__ == "__main__":
    main()

두 번째 문서에는 세 절이 빠져 있고, 일회성 요구가 반복되어 길이 제한도 넘는다. 일부러 잘못된 문서를 함께 넣었으므로 프로그램은 “통과”만 출력하지 않는다. 문제가 있을 때 누락한 절과 길이 문제를 모두 알려 주는지 확인할 수 있다.

줄별 해설

첫 부분의 REQUIRED_SECTIONS는 필수 제목을 순서대로 담은 튜플이다. 튜플(tuple)은 여러 값을 묶어 두는 자료형이다. 여기서는 실행 중에 목록을 바꾸지 않을 예정이므로 사용했다. MAX_CHARS는 이 프로그램에서 정한 문자 수 제한이다. 대문자 이름은 고정된 기준이라는 의도를 드러낸다.

GOOD_RULES에는 다섯 절이 모두 있다. 큰따옴표 세 개로 둘러싼 문자열은 여러 줄을 그대로 담는다. 줄바꿈도 문자열의 일부다. BAD_RULES의 문자열에는 두 절만 있고, 마지막 문장을 80번 반복한다. 문자열에 정수를 곱하면 같은 문자열이 그 횟수만큼 이어진다. 따라서 난수나 현재 시각 없이도 길이 문제를 재현할 수 있다.

collect_sections의 sections는 집합이다. 집합(set)은 중복된 값을 하나로 모은다. 같은 제목이 두 번 나와도 제목의 존재 여부는 한 번만 기록한다. 이번 도구는 중복 제목을 오류로 다루지 않는다. 이를 검사하려면 별도의 요구와 검증을 추가해야 한다.

splitlines는 텍스트를 줄 단위로 나눈다. strip은 각 줄의 앞뒤 공백을 제거한다. startswith는 줄의 시작이 지정한 문자열과 같은지 확인한다. line[3:]은 “## ”의 세 글자를 제외한 나머지를 가져온다. 마지막 strip은 제목 뒤에 붙은 공백도 제거한다.

inspect_rules는 제목을 수집한 뒤 필수 제목을 하나씩 확인한다. 문서에 없는 제목만 missing에 추가한다. 누락 목록을 만들 때 필수 제목의 순서를 사용하므로 집합의 표시 순서에 기대지 않는다. 같은 입력에는 같은 순서로 결과가 나온다.

len(text)는 문자열의 문자 수를 센다. 이 기준에는 공백과 줄바꿈도 포함된다. 파일의 저장 용량이나 화면에서 차지하는 폭을 측정하는 것은 아니다. 비교에 >를 사용했으므로 정확히 600자이면 허용하고 601자부터 길이 문제로 판단한다.

run_tests의 assert는 조건이 참인지 확인하는 문장이다. 조건이 거짓이면 실행이 멈추며 확인에 실패했음을 알린다. 정상 문서, 빈 문서, 누락과 길이 문제가 함께 있는 문서, 제한과 길이가 같은 경우, 제한을 한 글자 넘는 경우를 확인한다. 기본 명령은 python3 main.py다. 검사 문장을 생략하는 실행 옵션을 추가하면 이 확인 과정이 수행되지 않을 수 있으므로 이 예제의 검증에는 기본 명령을 사용한다.

print_report는 판정과 표시를 담당한다. 필수 절 검사와 길이 검사를 따로 출력해서 한 문제 때문에 다른 문제가 가려지지 않게 한다. “형식 검사 통과”라는 문구도 범위를 좁혀 쓴 표현이다. 제목과 길이를 통과했다고 실행 명령의 정확성이나 규칙의 품질까지 확인한 것은 아니다.

마지막 조건문은 이 파일을 직접 실행했을 때 main을 호출한다. main은 먼저 검사 예제를 확인한 다음 두 문서의 결과를 출력한다. 출력에 날짜, 임의 값, 파일 경로가 들어가지 않으므로 기본 실행 결과는 매번 같다.

실행 결과

macOS 또는 Linux의 터미널에서 main.py가 있는 폴더로 이동한 뒤 다음 명령을 실행한다. Python 3.12 이상을 사용한다.

python3 main.py

예상 출력은 다음과 같다. 검사 예제 중 하나라도 실패하면 아래 보고서를 끝까지 출력하기 전에 실행이 멈춘다.

검사 예제: 5개 통과
[기본 지침]
필수 절: 모두 있음
길이: 600자 이하
판정: 형식 검사 통과

[수정할 지침]
필수 절: 누락 - 코드 관례, 금지 사항, 폴더 경계
길이: 600자 초과
판정: 수정 필요

실행 결과가 예상과 일치하면 입력 예제에 대한 동작을 확인한 것이다. 그다음 코드를 읽어 제목을 어떻게 찾는지, 길이에 무엇을 포함하는지 확인한다. 기존 프로젝트에 이 도구를 추가했다면 디프에서 사용자 데이터 수정이나 불필요한 파일 변경이 포함되지 않았는지도 살펴본다.

이 프로그램은 단순한 제목 형식만 처리한다. 문서의 인용문이나 다른 예시 안에 “## 실행”이 있어도 제목으로 인식할 수 있다. 실제 적용에서는 검사 대상의 형식을 일정하게 유지해야 한다. 여러 문서 형식을 지원하는 요구가 생기면 먼저 그 범위와 예상 결과를 정한다.

실무에서 자주 틀리는 것

본문에 단어가 있으면 절도 있다고 판단한다

다음 코드는 실제로 실행되지만 의도한 검사를 하지 못한다. “실행”이라는 단어가 본문에 있을 뿐인데 필수 절이 있다고 판단한다.

text = "실행 방법은 다음 작업에서 정리한다."
has_section = "실행" in text
print(has_section)

고친 코드는 줄의 제목 형식을 확인한다. 이 예제의 출력은 False다. 검사할 대상이 단어인지 절 제목인지 먼저 정해야 한다.

text = "실행 방법은 다음 작업에서 정리한다."
has_section = any(
    line.strip() == "## 실행"
    for line in text.splitlines()
)
print(has_section)

길이 제한의 경계를 한 글자 앞당긴다

“600자까지 허용”이라고 정했는데 >=를 사용하면 정확히 600자인 문서도 거부한다. 다음 코드는 True를 출력한다.

text = "가" * 600
too_long = len(text) >= 600
print(too_long)

고친 코드는 False를 출력한다. 경계값은 허용 범위와 거부 범위를 나누는 값이다. 제한과 같은 길이, 한 글자 짧은 길이, 한 글자 긴 길이를 확인하면 문장으로 정한 기준과 코드의 비교가 일치하는지 알 수 있다.

text = "가" * 600
too_long = len(text) > 600
print(too_long)

형식 검사를 내용 검증으로 확대한다

다음 문서에는 실행 절이 있지만 명령이 없다. 제목을 찾은 결과만으로 실행 방법이 검증되었다고 출력하면 확인 범위를 부풀린다.

text = "## 실행\n나중에 정한다.\n"
has_section = any(
    line.strip() == "## 실행"
    for line in text.splitlines()
)
if has_section:
    print("실행 방법 검증 완료")

고친 코드는 실제로 확인한 범위만 말한다. 명령의 정확성은 별도로 실행해 확인해야 한다. 필요한 검사가 늘어나면 절의 본문을 읽는 기능과 그에 맞는 검사 예제를 추가한다.

text = "## 실행\n나중에 정한다.\n"
has_section = any(
    line.strip() == "## 실행"
    for line in text.splitlines()
)
if has_section:
    print("실행 절 제목 확인")
    print("명령의 정확성은 별도 확인 필요")

문서를 짧게 만들기 위해 금지 사항을 지우는 것도 피해야 한다. 길이 경고는 중요한 규칙을 없애라는 지시가 아니다. 반복된 문장, 지난 작업의 상태, 일회성 요구부터 옮기고 남은 규칙이 판단에 충분한지 검토한다.

한눈에 보기

프로젝트 지침을 작성하고 검토할 때 사용할 기준이다

항목	작성 기준	확인 방법
실행·테스트	위치, 명령, 통과 조건을 적는다.	적힌 명령을 직접 실행한다.
코드 관례	반복해서 적용할 규칙만 남긴다.	변경 내역에서 적용 여부를 본다.
금지 사항	금지할 행동과 대상을 구체화한다.	수정한 파일과 동작을 확인한다.
폴더 경계	폴더의 역할과 규칙 적용 범위를 적는다.	작업 대상의 지침을 함께 읽는다.
작업 상태	기록과 인계 메모에 따로 둔다.	현재 파일과 기록을 대조한다.
자동 검사	필수 절과 길이부터 점검한다.	정상·누락·경계 입력을 실행한다.

지침은 매번 같은 설명을 다시 작성하는 부담을 줄인다. 동시에 실제로 읽을 분량을 차지한다. 다음 장에서는 필요한 파일과 기록을 골라 보여 주고, 오래된 대화를 정리한 뒤 새로 시작하는 기준을 다룬다.

연습 문제

1. GOOD_RULES에서 “## 금지 사항”이라는 제목만 지우고 본문은 남겨 둔다. 필수 절 검사 결과를 예상한 뒤 실행으로 확인하라. 기존 검사 예제 중 어떤 것이 실패하는지도 설명하라.
2. 길이 제한이 600자일 때 599자, 600자, 601자 문자열의 길이 판정을 확인하는 독립된 검사 코드를 작성하라. 필수 절의 존재 여부는 이 문제에서 검사하지 않는다.
3. “표준 라이브러리만 사용한다”, “오늘 목록 제목을 바꾼다”, “빈 목록을 확인했고 파일 입력은 미확인이다”를 프로젝트 지침, 작업 요청, 인계 메모로 나누고 이유를 설명하라.
4. 루트 지침에는 “사용자 저장 파일을 수정하지 않는다”, data의 지침에는 “검증 전에 저장 파일을 초기화한다”가 있다. 이 장에서 정한 충돌 처리 원칙에 따라 AI에게 보낼 요청을 작성하라.

정답과 해설

첫 번째 문제에서 inspect_rules(GOOD_RULES)의 결과는 누락 목록에 “금지 사항”이 들어가고 길이 판정은 False가 된다. 본문에 금지할 행동이 적혀 있어도 제목은 없다. 기본 프로그램을 그대로 실행하면 run_tests의 첫 검사에서 멈춘다. 입력 예제를 바꿨으므로 기존의 정상 문서 기대값과 맞지 않기 때문이다.

실험할 때는 원래 정상 문서를 유지하고 별도의 입력을 만드는 편이 확인하기 쉽다. 다음 코드는 완성 코드의 함수 정의가 있는 상태에서 실행하는 추가 검사다.

changed_rules = GOOD_RULES.replace("## 금지 사항\n", "")
assert inspect_rules(changed_rules) == (["금지 사항"], False)
print("제목 누락 확인")

두 번째 문제의 판정은 순서대로 False, False, True다. 다음 코드는 다른 함수 없이 독립적으로 실행할 수 있다.

limit = 600
for size in (599, 600, 601):
    text = "가" * size
    print(size, len(text) > limit)

세 번째 문제에서 “표준 라이브러리만 사용한다”는 다음 기능에서도 유지할 규칙이므로 프로젝트 지침에 둔다. “오늘 목록 제목을 바꾼다”는 이번 작업 요청에 둔다. “빈 목록을 확인했고 파일 입력은 미확인이다”는 다음 행동의 출발점을 알려 주므로 인계 메모에 둔다. 빈 목록의 검증 결과는 작업 기록에도 남길 수 있다.

네 번째 문제에서는 초기화를 바로 실행하도록 요청하지 않는다. 이 프로젝트의 원칙에 따르면 하위 지침이 공통 금지 사항을 조용히 바꿀 수 없다. 다음과 같이 충돌과 대안을 구체적으로 확인한다.

루트와 data의 지침에서 저장 파일 처리 규칙이 충돌한다. 사용자 저장 파일의 수정이나 초기화를 진행하기 전에 충돌한 문장을 제시하라. 사용자 데이터와 분리한 예제 입력으로 검증할 수 있는지 확인하고, 그 방법에 필요한 파일과 실행 명령을 설명하라.

지침 파일의 가치는 다음 세션에서 읽을 수 있다는 데서 시작한다. 그 내용이 현재 프로젝트와 맞는지, AI가 실제 수정에 적용했는지까지 확인해야 작업 기준으로 기능한다. 이번 장의 도구는 그중 필수 절과 길이라는 작은 부분을 반복해서 확인한다.