과정이 보이는 포트폴리오 - 무엇을 맡기고 무엇을 판단했나

이 장에서 배우는 것

작동하는 프로그램을 보여 주면 그 프로그램이 어떤 일을 하는지는 알 수 있다. 그러나 그것만으로 만든 사람이 무엇을 이해했는지까지 알기는 어렵다. AI가 화면과 코드를 빠르게 만들 수 있는 환경에서는 결과물과 함께 판단의 흔적을 보여 주는 일이 더 중요해진다. 개발자의 일이 없어지는 것으로만 보기보다, 구현을 맡기는 일과 그 구현을 설명하고 확인하는 일의 비중이 달라진다고 보는 편이 학습에도 도움이 된다.

앞 장에서 AI 사용을 정직하게 밝히는 태도를 다뤘다. 여기서는 그 기록을 프로젝트의 설명으로 연결한다. 무엇을 맡겼는지에 더해, 어떤 기준으로 받아들였고 무엇을 바꿨는지를 남긴다. 포트폴리오(portfolio)는 자신이 해 온 작업을 다른 사람이 살펴볼 수 있도록 묶은 자료다. 이 장에서는 보기 좋은 결과물뿐 아니라 판단의 근거가 보이는 포트폴리오를 만든다.

결과물과 과정 기록이 서로 다른 정보를 보여 준다는 점을 이해한다.
명세, 테스트, 결정 기록, 실패와 수정 과정을 짧게 연결해 남긴다.
프로젝트 안내 문서인 README에 문제, 설계 판단, 검증 방법, AI 활용 범위를 담는다.
README의 필수 절을 점검하는 Python 프로그램을 읽고 실행한다.
문서의 형식 검사와 실제 실력의 확인을 구분한다.

문제 상황

개발 공부를 시작한 학생이 학습 기록장을 만들었다고 하자. 공부한 주제와 시간을 입력하면 목록으로 보여 주는 프로그램이다. 화면은 단정하고 실행도 잘된다. 학생은 포트폴리오에 화면 사진과 실행 방법을 넣었다. 그런데 프로젝트를 설명하는 자리에서 다음 질문을 받는다.

공부 시간이 비어 있을 때는 어떻게 처리했는가. 처음부터 지금 방식으로 만들었는가. AI가 제안한 코드 중 바꾼 부분은 무엇이며, 왜 바꿨는가.

학생은 마지막 화면을 기억하지만 처음의 요구와 수정 이유는 기억하지 못한다. “AI가 이렇게 만들어 줬다”는 말은 구현이 나온 경로를 설명하지만, 학생이 그 구현을 어떻게 판단했는지는 설명하지 못한다. 반대로 모든 코드를 직접 입력했다고 말해도, 입력값을 왜 제한했는지 설명하지 못하면 같은 문제가 남는다.

함께 일하는 상황에서도 이런 정보는 필요하다. 다른 사람이 학습 기록장에 주간 합계 기능을 붙이려면, 빈 시간을 허용하는지와 기존 기록을 어떤 기준으로 처리하는지 알아야 한다. 화면 사진은 그 규칙을 보여 주지 않는다. 문서에 판단과 확인 방법이 있으면 다음 작업자가 같은 의문을 처음부터 다시 풀 필요가 줄어든다.

해결책은 대화와 코드를 모두 쌓아 두는 일이 아니다. 읽는 사람이 핵심 질문의 답을 찾을 수 있도록 기록을 골라 연결하는 일이다. 작은 프로젝트에서도 “어떤 문제를 풀었는가 → 무엇을 선택했는가 → 어떻게 확인했는가”가 이어지면 설명할 근거가 생긴다.

결과물에 판단의 근거를 붙인다

결과물은 현재의 상태를 보여 준다. 과정 기록은 그 상태에 도달한 이유를 보여 준다. 같은 학습 기록장이라도 한 사람은 AI가 만든 코드를 실행만 했을 수 있고, 다른 사람은 잘못된 시간 입력을 발견하고 규칙을 고쳤을 수 있다. 두 화면이 비슷하더라도 남길 수 있는 설명은 다르다.

과정을 보여 준다는 것은 오래 걸린 작업을 자랑한다는 뜻이 아니다. 코드의 양이나 수정 횟수가 많다고 좋은 판단을 했다고 말할 수는 없다. 중요한 것은 문제와 선택과 확인 사이의 관계다. 작은 요구를 분명하게 정하고, 그 요구에 맞는 선택을 설명하고, 실제 실행 결과로 뒷받침하는 기록이 유용하다.

결과물과 과정 기록은 서로 다른 질문에 답한다
자료	알 수 있는 것	덧붙일 근거
실행 화면	현재 어떤 기능이 보이는가	그 기능이 필요한 문제
완성 코드	현재 어떤 방식으로 처리하는가	그 방식을 선택한 이유
테스트 결과	어떤 사례를 확인했는가	입력과 기대 결과, 실제 결과
수정 기록	무엇이 달라졌는가	발견한 문제와 수정 후 확인

명세는 프로그램이 해야 할 일을 입력과 출력, 예시와 완료 기준으로 적은 약속이다. 포트폴리오에서는 그 약속 전체를 길게 옮기기보다 핵심 규칙과 확인 자료의 위치를 보여 주면 된다. 학습 기록장이라면 “공부 시간은 양의 정수로 받는다”가 규칙이고, “빈 입력과 음수 입력은 기록하지 않고 안내한다”가 확인할 사례가 된다.

테스트는 정한 입력을 넣고 실제 결과가 기대와 맞는지 확인하는 작업이다. “테스트 통과”라는 말만 남기면 무엇을 확인했는지 알 수 없다. “공부 시간에 빈 문자열을 넣었을 때 기록이 추가되지 않는 것을 확인했다”처럼 사례를 남겨야 한다. 확인하지 않은 범위도 적으면 기록의 경계가 보인다. 예를 들어 파일을 여러 사람이 동시에 수정하는 상황은 확인하지 않았다고 쓸 수 있다.

실패 기록 역시 길 필요는 없다. 처음에는 잘못된 입력을 발견하지 못했다는 사실, 어떤 입력에서 문제가 드러났는지, 규칙이나 코드를 어떻게 바꿨는지, 같은 입력으로 다시 확인한 결과를 연결하면 된다. 실패를 감추지 않는 태도와 실패를 분석하는 능력은 함께 드러날 수 있다. 다만 오류 메시지만 붙이고 원인과 후속 확인을 생략하면 읽는 사람이 그 연결을 대신 추측해야 한다.

README를 설명의 출발점으로 만든다

README는 프로젝트를 처음 보는 사람이 읽는 안내 문서다. 흔히 제목과 목록 같은 간단한 표기를 쓰는 마크다운(Markdown) 형식으로 작성한다. 이 장에서는 줄 맨 앞의 ## 를 절 제목의 표시로 사용한다. 예를 들어 ## 문제 아래에는 프로그램이 해결하려는 문제를 적는다.

처음부터 긴 문서를 쓰려고 하면 기록 자체가 부담이 된다. 먼저 네 절을 만들고, 각 절에 실제 프로젝트의 사실을 짧게 적는다. 문제에는 사용자와 불편을, 설계 판단에는 선택과 이유를, 검증 방법에는 재현할 수 있는 확인 절차를, AI 활용 범위에는 맡긴 일과 직접 확인한 일을 담는다.

README의 네 절에 담을 내용
필수 절	답할 질문	학습 기록장의 예
문제	누가 어떤 불편을 겪는가	학생이 공부 시간을 적어도 주간 합계를 알기 어렵다.
설계 판단	무엇을 왜 선택했는가	시간을 정수로 받아 합계 규칙을 단순하게 유지한다.
검증 방법	어떻게 다시 확인하는가	정상 입력과 빈 입력을 각각 넣어 기록 추가 여부를 확인한다.
AI 활용 범위	무엇을 맡기고 무엇을 판단했는가	입력 처리 초안을 맡기고 시간 제한과 오류 처리는 직접 검토했다.

설계는 프로그램의 처리 방식과 구성을 정하는 일이다. 설계 판단을 적을 때는 선택한 방식뿐 아니라 선택에 영향을 준 조건도 남긴다. “정수로 받았다”보다 “처음에는 분 단위 기록만 다루므로 정수로 받았다”가 설명할 내용이 많다. 조건이 달라졌을 때 선택을 다시 검토할 수 있기 때문이다.

결정 기록은 모든 생각을 옮기는 일기가 아니다. 중요한 선택 하나에 대해 후보, 선택, 이유, 한계를 남기는 짧은 메모다. 후보를 실제로 비교하지 않았다면 비교했다고 쓰지 않는다. 처음부터 한 방식을 택했다면 그 사실과 선택 당시의 이유를 적으면 된다.

선택: 공부 시간은 분 단위 정수로 받는다.

이유: 현재 사용자는 하루 공부 시간을 간단히 합산하려 한다.

한계: 초 단위 기록은 다루지 않는다. 그 요구가 생기면 입력과 표시 규칙을 다시 정한다.

이 메모에 실패와 수정이 붙으면 판단의 변화도 보인다. “처음에는 빈 입력을 숫자로 바꾸려다 실행이 멈췄다. 빈 입력을 먼저 확인하도록 바꿨다. 같은 입력으로 다시 실행해 안내가 나오고 기록은 추가되지 않는 것을 확인했다”라고 적을 수 있다. 발견 당시의 입력과 수정 후의 결과가 있어야 다른 사람도 따라 확인할 수 있다.

AI 활용 범위에는 작업 단위를 적는다. “AI 사용함”만으로는 무엇을 맡겼는지 알기 어렵다. “README 문장 초안을 맡겼다”, “테스트 후보를 제안받았다”, “코드의 조건문 설명을 요청했다”처럼 구분한다. 이어서 직접 읽은 부분, 실행한 사례, 받아들이지 않은 제안이 있다면 그 이유를 적는다. AI가 설명한 내용을 그대로 자신의 확인 결과로 바꾸어 쓰지 않는다.

면접에서는 문서의 문장을 외우기보다 한 선택을 근거와 함께 설명하는 연습을 한다. 문제, 선택, 확인, 한계의 순서로 말하면 된다. “정수로 받은 이유는 현재 요구가 분 단위 합계였기 때문이다. 빈 입력에서 문제가 생겨 먼저 검사하도록 고쳤다. 수정 후 같은 입력을 다시 넣었다. 초 단위 기록은 아직 다루지 않는다”는 설명에는 후속 질문을 할 지점이 보인다.

점검표는 설명을 돕지만 실력을 채점하지 않는다

이 장의 프로그램은 README 텍스트를 읽고 네 절이 있는지, 각 절에 비어 있지 않은 줄이 있는지 확인한다. 문서를 제출하기 전에 빠뜨린 항목을 찾는 작은 도구다. 외부 파일을 읽지 않고 프로그램 안의 예시 텍스트를 검사하므로, 별도 준비 없이 실행할 수 있다.

검사 규칙은 좁게 정한다. 앞뒤 공백을 지운 줄이 ## 로 시작하면 절 제목으로 본다. 그 다음부터 다음 절 제목 전까지를 해당 절의 본문으로 모은다. 필수 제목은 표에 있는 이름과 정확히 같아야 한다. 제목이 없으면 “절 없음”, 제목은 있지만 본문이 비어 있으면 “본문 없음”이라고 출력한다.

이 도구는 제목의 뜻을 추론하지 않는다. “해결하려는 문제”라는 제목을 “문제”와 같은 것으로 보지 않는다. 본문에 “나중에 작성”이라는 한 줄만 있어도 내용이 있다고 판단한다. 코드 예시 안의 제목 표시를 따로 구분하지도 않는다. 정한 형식의 짧은 문서를 점검하는 프로그램이며, 일반적인 문서 해석기라고 설명해서는 안 된다.

자동 점검은 절과 본문의 존재를 확인하고 사람은 설명과 실제 작업이 맞는지 확인한다

자동 점검이 통과한 뒤에는 사람이 다시 읽는다. 문제와 설계 판단이 이어지는지, 검증 방법을 실제로 수행했는지, AI 활용 범위가 작업 기록과 맞는지를 살핀다. 프로그램의 확인 개수는 문서 형식의 충족 개수다. 프로젝트의 완성도나 작성자의 실력 점수로 해석하지 않는다.

다음 예시는 검증 방법 절을 일부러 비워 둔다. 나머지 절은 확인되고 검증 방법은 보완 대상으로 나와야 한다. 먼저 예상 결과를 정하고 실제 출력과 비교한다. AI가 이 프로그램의 초안을 작성했더라도, 제목을 찾는 조건과 빈 본문을 판별하는 부분을 읽고 실행 결과를 확인해야 한다. 예시 문서와 출력에 등장하는 숫자는 설명용 가상값이다.

완성 코드

다음 내용을 main.py로 저장한다. Python 3.12 이상에서 표준 기능만 사용하며 외부 패키지, API 키, 네트워크 연결이 필요하지 않다. 실행하면 점검표를 출력하고 바로 끝난다.

required_sections = [
    "문제",
    "설계 판단",
    "검증 방법",
    "AI 활용 범위",
]

readme = """# 학습 기록장
## 문제
학생이 하루 공부 시간을 적어도 주간 합계를 알기 어렵다.
## 설계 판단
공부 시간은 분 단위 정수로 받는다.
빈 입력에서 실행이 멈춰, 빈 입력을 먼저 확인하도록 고쳤다.
## 검증 방법

## AI 활용 범위
입력 처리 초안과 테스트 후보를 AI에 요청했다.
시간 제한 규칙을 직접 정하고 입력 처리 코드를 읽었다.
"""

sections = {}
current_title = ""

for raw_line in readme.splitlines():
    line = raw_line.strip()
    if line.startswith("## "):
        current_title = line[3:].strip()
        if current_title not in sections:
            sections[current_title] = []
    elif current_title != "":
        sections[current_title].append(line)

print("README 필수 절 점검")
passed = 0

for title in required_sections:
    if title not in sections:
        print(f"[보완] {title}: 절 없음")
        continue

    has_content = False
    for line in sections[title]:
        if line != "":
            has_content = True

    if has_content:
        print(f"[확인] {title}: 본문 있음")
        passed += 1
    else:
        print(f"[보완] {title}: 본문 없음")

print(f"확인: {passed}/{len(required_sections)}")
print("이 결과는 절과 본문의 존재만 확인한다.")

줄별 해설

코드는 위에서 아래로 실행된다. 첫 부분은 검사 기준과 예시 문서를 준비하고, 가운데는 문서를 절별로 나누며, 마지막은 결과를 출력한다. 빈 줄은 사람이 묶음을 읽기 쉽게 나눈 것으로 실행할 작업은 없다.

required_sections = [는 필수 제목들을 담을 목록을 만든다. 목록은 여러 값을 순서대로 보관하는 자료다. 이어지는 네 줄은 검사할 제목이며, 마지막 ]는 목록의 끝이다. 출력 순서도 이 순서를 따른다.
readme = """# 학습 기록장은 여러 줄의 문자열을 시작한다. 문자열은 글자를 담는 값이다. 큰따옴표 세 개 사이에서는 줄바꿈도 문자열에 포함된다. 이 줄의 프로젝트 제목부터 닫는 큰따옴표 전까지는 Python 명령이 아니라 검사할 문서 내용이다.
문서의 ## 문제 줄과 다음 본문은 사용자와 불편을 나타낸다. ## 설계 판단 아래 두 줄은 현재의 선택과 수정 경험을 담는다. ## 검증 방법 아래는 비어 있다. ## AI 활용 범위 아래 두 줄은 맡긴 작업과 직접 판단한 작업을 구분한다. 마지막 """가 문자열을 닫는다.
sections = {}는 빈 딕셔너리(dictionary)를 만든다. 딕셔너리는 이름과 값을 짝지어 보관하는 자료다. 여기서는 절 제목을 이름으로, 그 절의 본문 줄 목록을 값으로 보관한다.
current_title = ""는 현재 읽고 있는 절 제목을 빈 문자열로 시작한다. 아직 절 제목을 만나지 않았다는 표시다.
for raw_line in readme.splitlines():는 문서를 줄 단위로 나누고 한 줄씩 반복해서 읽는다. 매번 현재 줄이 raw_line에 들어간다. 아래에서 들여쓴 줄들이 반복할 작업이다.
line = raw_line.strip()는 줄의 앞뒤 공백을 제거한다. 공백만 있는 줄은 빈 문자열이 된다. 줄 가운데의 공백은 유지된다.
if line.startswith("## "):는 줄이 제목 표시로 시작하는지 확인한다. if 아래의 들여쓴 작업은 조건이 맞을 때 실행된다. 샵 두 개 다음의 공백도 검사 규칙에 포함된다.
current_title = line[3:].strip()는 처음 세 글자인 제목 표시를 제외하고 나머지를 가져온다. [3:]은 앞의 세 글자를 건너뛰고 끝까지 가져오는 표기다. 다시 앞뒤 공백을 지워 제목 이름만 남긴다.
if current_title not in sections:는 그 제목이 아직 딕셔너리에 없는지 확인한다. 다음 줄의 sections[current_title] = []는 새 제목에 빈 본문 목록을 연결한다. 같은 제목을 다시 만나면 이미 모은 본문을 지우지 않는다.
elif current_title != "":는 제목 줄이 아니면서 현재 절 제목이 있을 때 실행할 조건이다. elif는 앞선 조건이 맞지 않았을 때 다른 조건을 확인한다. !=는 두 값이 다른지 비교한다.
sections[current_title].append(line)는 현재 절의 본문 목록 끝에 줄을 추가한다. 첫 절 제목 전의 프로젝트 제목은 여기에 들어가지 않는다.
print("README 필수 절 점검")은 출력의 안내 제목을 표시한다. passed = 0은 본문까지 확인된 필수 절의 개수를 처음에 영으로 둔다.
for title in required_sections:는 필수 제목을 정해진 순서로 하나씩 검사한다. 문서에 절이 배치된 순서가 달라도 점검표의 순서는 같다.
if title not in sections:는 필수 제목이 수집되지 않았는지 확인한다. 다음 print는 해당 제목과 “절 없음”을 출력한다. 문자열 앞의 f는 중괄호 안의 값을 문자열에 넣는 표시다.
continue는 현재 제목의 남은 검사를 건너뛰고 다음 제목으로 넘어간다. 없는 절에서 본문을 꺼내려는 일을 피한다.
has_content = False는 이번 절에 내용이 있는지 나타내는 값을 거짓으로 시작한다. False와 True는 각각 거짓과 참을 나타내는 값이다. 절마다 새로 시작해야 앞 절의 결과가 섞이지 않는다.
for line in sections[title]:는 해당 절의 본문 줄을 하나씩 읽는다. if line != "":는 빈 줄이 아닌지 확인한다. 그런 줄을 만나면 has_content = True로 바꾼다. 이후 빈 줄이 있어도 다시 거짓으로 바꾸지 않는다.
if has_content:는 내용이 있다는 값이 참인지 확인한다. 참이면 “본문 있음”을 출력하고 passed += 1로 확인 개수를 하나 늘린다. 이 표기는 현재 값에 하나를 더해 다시 저장한다는 뜻이다.
else: 아래의 출력은 제목은 있지만 내용이 없을 때 실행된다. “절 없음”과 “본문 없음”을 구별하므로 무엇을 보완할지 알 수 있다.
마지막에서 두 번째 print는 확인 개수와 전체 필수 절 개수를 표시한다. len(required_sections)는 목록의 항목 수를 구한다. 마지막 print는 검사 범위를 밝혀 숫자의 뜻을 분명히 한다.

이 프로그램은 본문을 모으는 반복과 모은 본문을 검사하는 반복을 나누었다. 줄을 읽는 중에 모든 결과를 바로 출력하는 방식도 가능하지만, 여기서는 “자료를 모으기”와 “기준에 따라 판단하기”를 따로 읽을 수 있다. 이 선택 역시 README의 설계 판단에 적을 수 있는 내용이다.

실행 결과

터미널에서 다음 명령을 실행한다. 터미널은 글자로 명령을 입력하고 결과를 읽는 프로그램이다. 파일을 저장한 폴더에서 실행한다.

python3 main.py

예상 출력은 다음과 같다. 실행마다 같은 문서와 같은 기준을 사용하므로 출력도 같다.

README 필수 절 점검
[확인] 문제: 본문 있음
[확인] 설계 판단: 본문 있음
[보완] 검증 방법: 본문 없음
[확인] AI 활용 범위: 본문 있음
확인: 3/4
이 결과는 절과 본문의 존재만 확인한다.

검증 방법은 제목이 존재하므로 “절 없음”이 아니다. 그 절의 본문은 빈 줄뿐이어서 “본문 없음”으로 나온다. 이 차이가 코드의 조건과 맞는지 읽어 본다. 실행이 끝났다는 사실과 기대한 결과가 나왔다는 사실은 따로 확인해야 한다.

다음에는 예시 문서의 검증 방법 절에 실제로 수행한 확인을 적고 다시 실행한다. 예를 들어 이 점검기를 검증했다면 “빈 본문과 제목 누락 사례를 각각 실행해 보완 메시지를 확인했다”라고 쓸 수 있다. 실행하지 않은 확인을 이미 수행한 일처럼 적어서는 안 된다. AI에 기록 정리를 맡길 때도 확인된 사실만 제공한다.

다음은 내가 실행해서 확인한 사실이다. 필수 제목이 없을 때는 절 없음이 나왔고, 제목 아래가 빈 줄일 때는 본문 없음이 나왔다. 이 사실만 사용해 README의 검증 방법을 짧게 정리해 달라. 확인하지 않은 사례는 추가하지 말라.

받은 문장을 읽고 실제 출력과 대조한 뒤 문서에 넣는다. 자연스럽게 쓰인 설명도 실행 기록과 다르면 고쳐야 한다. 기록이 먼저 있고 문장이 그것을 정리하는 순서를 유지한다.

실무에서 자주 틀리는 것

제목 문자열이 보이면 절이 있다고 판단한다

아래 코드는 본문에 “검증 방법”이라는 말이 나오기만 해도 참을 출력한다. 검사하려는 것은 단어의 존재가 아니라 정해진 절 제목의 존재다. 두 예시는 각각 따로 실행할 수 있다.

틀린 코드다.

text = "검증 방법은 아직 정하지 않았다."
print("검증 방법" in text)

고친 코드다.

text = "검증 방법은 아직 정하지 않았다."
found = False
for line in text.splitlines():
    if line.strip() == "## 검증 방법":
        found = True
print(found)

첫 코드는 True, 고친 코드는 False를 출력한다. 실제 절 제목을 찾았더라도 본문 검사는 별도로 필요하다.

공백만 있는 본문을 내용으로 센다

문자 수가 있다는 이유만으로 본문이 있다고 판단하면 스페이스와 줄바꿈도 내용이 된다. 문서에서 눈에 보이는 내용이 있는지를 검사하려면 공백을 처리하는 규칙이 필요하다.

틀린 코드다.

body = "   \n"
print(len(body) > 0)

고친 코드다.

body = "   \n"
print(body.strip() != "")

첫 코드는 True, 고친 코드는 False를 출력한다. 완성 코드에서는 각 줄을 읽을 때 앞뒤 공백을 제거한 뒤 빈 줄인지 확인한다.

새 절을 검사할 때 이전 결과를 그대로 쓴다

첫 절에 내용이 있었다고 다음 절에도 내용이 있는 것은 아니다. 확인용 값을 반복 바깥에서 한 번만 초기화하면 앞선 결과가 다음 검사에 남을 수 있다.

틀린 코드다.

bodies = ["문제를 적었다.", ""]
has_content = False
for body in bodies:
    if body.strip() != "":
        has_content = True
    print(has_content)

고친 코드다.

bodies = ["문제를 적었다.", ""]
for body in bodies:
    has_content = False
    if body.strip() != "":
        has_content = True
    print(has_content)

첫 코드는 참을 두 번 출력한다. 고친 코드는 참과 거짓을 차례로 출력한다. 각 절의 판단은 그 절의 본문으로 새로 시작해야 한다.

형식 검사 결과를 프로젝트의 품질로 표현한다

필수 절에 한 줄씩 있다는 사실로 설명의 정확성까지 확인할 수는 없다. 프로그램의 출력도 자신이 실제로 검사한 범위에 맞게 써야 한다.

틀린 코드다.

passed = 4
total = 4
if passed == total:
    print("프로젝트의 품질을 확인했다.")

고친 코드다.

passed = 4
total = 4
if passed == total:
    print("모든 필수 절에 본문이 있다.")
    print("설명과 실제 작업이 맞는지는 사람이 확인한다.")

여기서 숫자는 설명용 가상값이다. 프로그램 이름, README의 소개, 출력 문구가 모두 같은 검사 범위를 말해야 사용자가 결과를 잘못 해석할 가능성이 줄어든다.

한눈에 보기

과정이 보이는 포트폴리오를 만드는 기준
남길 것	짧게 적는 방법	읽는 사람이 확인할 것
문제와 명세	사용자, 불편, 핵심 처리 규칙을 적는다.	결과물이 어떤 요구를 해결하는가
설계 판단	선택, 이유, 적용 조건과 한계를 적는다.	왜 현재 방식을 사용했는가
검증 기록	입력, 기대 결과, 실제 결과를 연결한다.	같은 확인을 다시 수행할 수 있는가
실패와 수정	발견한 사례, 변경 내용, 재확인을 적는다.	문제를 어떻게 판단하고 고쳤는가
AI 활용 범위	맡긴 작업과 직접 확인한 작업을 적는다.	작성자가 무엇을 책임지고 설명하는가
자동 점검	검사 규칙과 검사하지 않는 범위를 밝힌다.	출력의 의미를 어디까지 해석할 수 있는가

설명할 근거가 없는 부분은 다음 학습의 단서가 된다. 설계 이유를 말하기 어렵다면 그 선택을 다시 살펴보고, 검증 방법을 적기 어렵다면 실제 확인을 보충한다. 다음 장에서는 이런 단서를 모아 지금 단계에서 무엇을 더 익힐지 학습 경로로 연결한다.

연습 문제

완성 코드의 예시 문서에서 ## 검증 방법 줄만 삭제한다. 나머지는 그대로 둔다. 어느 출력 줄이 바뀌며, 확인 개수는 어떻게 되는지 먼저 예상하고 실행한다.
검증 방법 절의 본문에 스페이스만 넣었을 때와 “나중에 작성”을 넣었을 때의 차이를 예상하고 확인한다. 두 결과가 프로그램의 한계를 어떻게 보여 주는지 설명한다.
필수 절 목록에 “실패와 수정”을 추가한다. 예시 문서에는 같은 이름의 절과 비어 있지 않은 본문을 추가한다. 기존 검증 방법 절은 비워 둔다. 확인 개수와 전체 개수를 예상한다. 본문에는 실제로 확인한 이 점검기의 실패 사례나 수정 사례를 적는다.
이 점검기를 포트폴리오에 넣는다고 가정한다. “왜 문서를 절별로 모은 뒤 검사했는가”, “AI에는 무엇을 맡길 수 있는가”, “통과해도 무엇을 확인해야 하는가”에 각각 짧게 답한다. 실제 AI 사용 경험이 없다면 사용 계획이라고 밝힌다.

정답과 해설

검증 방법의 출력이 [보완] 검증 방법: 절 없음으로 바뀐다. 확인 개수는 여전히 3/4다. 삭제 전에는 제목은 있고 본문이 없었으며, 삭제 후에는 제목 자체가 없다. 빈 줄은 앞선 설계 판단 절에 포함되지만 이미 비어 있지 않은 본문이 있으므로 그 절의 결과는 달라지지 않는다.
스페이스만 넣으면 앞뒤 공백을 지운 결과가 빈 문자열이어서 “본문 없음”이다. “나중에 작성”을 넣으면 비어 있지 않은 줄이므로 “본문 있음”이며 확인 개수는 4/4가 된다. 그러나 검증 방법을 설명한 것은 아니다. 이 사례는 자동 점검이 내용의 존재만 검사하고 내용의 충분함이나 사실 여부는 판단하지 않는다는 한계를 보여 준다.
확인 개수는 4/5다. 새 절은 제목과 본문이 있어 확인되지만 기존 검증 방법은 계속 보완 대상으로 남는다. 새 필수 제목을 목록 끝에 추가했다면 그 점검 결과도 기존 네 절 뒤에 나온다. “제목 문자열만 찾는 방식은 본문 속 단어를 절로 잘못 판단했다. 제목 줄을 비교하도록 바꾸고 같은 문장으로 다시 확인했다”처럼 실제 실행한 사례를 쓸 수 있다. 이런 입력과 결과를 확인한 뒤 기록해야 한다.
설계 답변의 예는 “본문 수집과 필수 절 판단을 나누면 누락된 절과 빈 본문을 별도로 설명하기 쉬워서다”다. AI 사용 계획의 예는 “확인할 문서 사례와 README 설명 초안을 요청하되, 예상 출력은 코드를 읽어 정하고 실제 실행과 비교하겠다”다. 통과 후 확인할 내용은 “설계 이유가 실제 선택과 맞는지, 검증을 수행했는지, AI 활용 범위가 사실인지”다. 다른 선택을 했더라도 이유와 근거, 검사 범위를 설명할 수 있으면 된다.

과정이 보이는 포트폴리오 - 무엇을 맡기고 무엇을 판단했나

이 장에서 배우는 것

문제 상황

결과물에 판단의 근거를 붙인다

README를 설명의 출발점으로 만든다

점검표는 설명을 돕지만 실력을 채점하지 않는다

완성 코드

줄별 해설

실행 결과

실무에서 자주 틀리는 것

제목 문자열이 보이면 절이 있다고 판단한다

공백만 있는 본문을 내용으로 센다

새 절을 검사할 때 이전 결과를 그대로 쓴다

형식 검사 결과를 프로젝트의 품질로 표현한다

한눈에 보기

연습 문제

정답과 해설

댓글 0