바이브 코딩이란 - 말로 시키고 눈으로 확인하는 개발

이 장에서 배우는 것

만들고 싶은 프로그램은 있는데, 어디서부터 써야 할지 모를 수 있다. 파일 이름을 정하는 일부터 낯설고, 화면에 보이는 영어 문장이 명령인지 설명인지 구별하기도 어렵다. 이때 인공지능인 AI에게 원하는 일을 말로 설명하면 프로그램의 초안을 받을 수 있다. 다만 초안을 받았다는 사실과 원하는 프로그램을 만들었다는 사실은 다르다.

이 책에서 말하는 바이브 코딩은 원하는 일을 말로 요청하고, AI가 내놓은 결과를 직접 실행하고 확인하며 프로그램을 만드는 방식이다. 코드를 처음부터 모두 외워서 쓰지는 않더라도, 무엇을 시켰고 무엇이 나왔는지는 스스로 설명해야 한다. 이 장에서는 그 작업을 한 바퀴 경험한다.

• 바이브 코딩이라는 말의 배경과 이 책에서 사용하는 뜻을 설명한다.
• AI가 맡을 수 있는 일과 사람이 판단해야 하는 일을 구별한다.
• 요청, 결과, 실행, 확인이 어떻게 이어지는지 이해한다.
• 프로그램이 실행되었다는 사실과 결과가 맞다는 사실을 구별한다.
• 작업 일지를 실행하고, 확인 기록이 빠졌을 때 나오는 경고를 읽는다.

문제 상황

동아리에서 준비물을 나눠 주는 일을 맡았다고 하자. 참석자 수를 넣으면 필요한 꾸러미 수를 알려 주는 작은 프로그램이 있으면 편리하다. 한 꾸러미는 네 사람이 쓰며, 참석자가 다섯 명이면 꾸러미 두 개가 필요하다.

AI에게 “참석자 수로 준비물 수를 계산해 줘”라고 말하자 코드가 나왔다. 코드란 컴퓨터가 수행할 일을 정해진 문법으로 적은 글이다. 그 글을 실행했더니 화면에 숫자가 나타났다. 오류도 보이지 않았다. 이제 일을 마쳤다고 생각하기 쉽다.

하지만 참석자 수가 여덟 명일 때만 실행했다면 어떨까. 네 명씩 정확히 나뉘는 경우에는 맞고, 다섯 명처럼 남는 사람이 생기면 틀리는 프로그램일 수도 있다. 숫자를 표시했다는 사실만으로는 필요한 수량을 계산했는지 알 수 없다. 사람은 실행 전에 기대한 값을 정하고, 실행 후 실제 값과 비교해야 한다.

다른 문제도 있다. 어제는 확인까지 했지만 오늘은 코드를 받은 뒤 다른 일을 하느라 실행하지 않았을 수 있다. 며칠 지나면 어느 작업을 어디까지 했는지 기억이 흐려진다. “만들었다”는 메모 하나에는 요청만 했다는 뜻인지, 실행했다는 뜻인지, 결과까지 확인했다는 뜻인지 드러나지 않는다.

그래서 이 장에서는 작은 작업 일지 프로그램을 만든다. 두 건의 예시 작업을 기록하고, 요청·결과·실행·확인 중 빠진 기록을 찾아 보여 준다. 첫 작업에는 확인 기록이 있고, 두 번째 작업에는 확인 기록이 없다. 두 작업을 나란히 보면 무엇을 남겨야 하는지 구체적으로 이해할 수 있다.

바이브 코딩은 어떻게 등장했나

바이브 코딩(vibe coding)이라는 표현은 2025년 무렵, AI에게 자연어로 지시하면서 프로그램을 만드는 방식을 설명하는 말로 알려졌다. 자연어란 한국어나 영어처럼 사람이 일상에서 사용하는 언어다. 표현 자체는 가볍게 흐름을 타며 만든다는 느낌을 담고 있지만, 실제로 가리키는 작업 범위는 사용하는 사람마다 다르다.

이 방식이 등장한 배경에는 요청을 문장으로 받아 코드를 생성하는 AI의 발전이 있다. 예전에도 사람이 쓴 코드를 찾아보거나 일부를 자동으로 채우는 도구가 있었다. 이제는 원하는 동작을 설명하고, 코드 초안을 받고, 실행 중 나타난 문제를 다시 설명하는 대화를 이어 갈 수 있게 되었다. 문법을 하나씩 입력하는 부담이 줄면서 처음 프로그램을 만드는 사람도 작은 시도를 시작하기 쉬워졌다.

그렇다고 사람이 하던 개발 작업 전체가 없어지는 것은 아니다. 프로그램 개발에는 글자를 입력하는 일 외에도 목적을 정하고, 애매한 조건을 구체화하고, 결과가 맞는지 판단하는 일이 들어 있다. AI가 코드를 빠르게 만들어도, 그 코드가 지금 필요한 일을 하는지는 별도로 확인해야 한다.

이 책은 바이브 코딩을 코드를 읽지 않고 계속 맡기는 습관으로 다루지 않는다. 말로 시작하되, 받은 결과를 읽고 실행하고 확인하는 작업으로 다룬다. 처음에는 모든 문법을 설명할 수 없어도 된다. 대신 “이 프로그램은 무엇을 받고 무엇을 내놓는가”, “어떤 예로 맞는지 확인했는가”라는 질문에는 조금씩 답할 수 있어야 한다.

AI에게 “코드를 검토해 줘”라고 다시 요청할 수도 있다. 그 답은 검토할 재료가 된다. 그러나 같은 AI가 “문제없다”고 답했다고 해서 실제 실행과 비교가 끝난 것은 아니다. 확인의 마지막 근거는 실행한 결과와 사람이 정한 기대 결과의 비교다.

AI가 맡는 일과 사람이 맡는 일

작업을 나눌 때는 누가 더 많은 줄을 쓰는지보다 누가 무엇을 결정하는지가 중요하다. AI는 작업 일지를 표현할 코드 구조를 제안하고, 기록이 비었는지 검사하는 함수를 작성할 수 있다. 함수란 이름을 붙여 두고 필요할 때 실행하는 코드 묶음이다. 사람은 일지에 어떤 항목이 필요한지, 무엇이 빠지면 알려야 하는지 결정한다.

작업 일지를 만들 때 AI와 사람이 나누어 맡는 일

작업	AI에게 맡길 부분	사람이 맡을 부분
목적 정하기	목적을 구체화하는 질문 제안	확인 누락을 찾겠다는 목적 결정
초안 만들기	기록 구조와 검사 코드 작성	요청한 항목이 들어 있는지 읽기
실행하기	실행 방법과 예상 결과 설명	자신의 환경에서 실제로 실행하기
결과 확인하기	검사할 예시와 수정안 제안	기대 결과와 실제 결과 비교
수정 받아들이기	수정 코드와 변경 이유 제시	변경 부분 검토와 재실행

예를 들어 AI가 “빈 확인 기록은 완료로 처리했습니다”라고 답했다면 코드가 아무리 깔끔해도 목적에 맞지 않는다. 빈 확인 기록을 찾아 알려 달라는 요구와 반대이기 때문이다. 사람은 문법을 많이 알기 전에도 이 불일치를 지적할 수 있다.

반대로 사람이 “적당히 만들어 줘”라고만 요청하면 AI가 정해야 할 부분이 늘어난다. 기록을 파일에 저장할지, 키보드로 입력받을지, 어떤 문구를 출력할지 모두 추측하게 된다. 이 장의 예제는 입력을 기다리지 않고, 정해 둔 두 기록을 검사한 뒤 바로 끝나도록 범위를 정한다. 매번 같은 결과가 나오므로 처음 실행하는 사람도 책과 자신의 화면을 비교할 수 있다.

AI가 제안한 수정도 같은 기준으로 살핀다. 수정 전후의 차이를 보여 주는 비교를 디프(diff)라고 한다. 아직 도구 사용법을 알 필요는 없다. 이 장에서는 바뀐 줄을 나란히 놓고 “확인하지 않음이 확인 완료로 바뀌지는 않았는가”를 읽는 것부터 시작한다. 코드 전체를 새로 받았더라도 바뀐 동작을 찾아보고 다시 실행해야 한다.

요청에서 확인까지 한 바퀴 돌기

작은 프로그램을 만들 때도 네 단계를 구별하면 현재 위치를 알 수 있다. 요청은 원하는 동작을 설명하는 단계다. 결과는 AI가 코드나 설명을 내놓은 단계다. 실행은 그 코드를 컴퓨터에서 실제로 동작시키는 단계다. 확인은 실제로 나온 것을 미리 생각한 결과와 비교하는 단계다.

이번 작업은 다음처럼 요청할 수 있다. 아래 내용은 AI에게 보낼 요청문의 예시이며, 실행할 Python 코드는 아니다.

작업 일지를 보여 주는 Python 프로그램을 main.py 한 파일로 만들어 줘. 작업마다 이름, 요청, 받은 결과, 실행 기록, 확인 기록을 남기고 싶어. 예시 작업 두 개를 코드 안에 넣어 줘. 첫 작업은 모든 기록을 채우고, 두 번째 작업은 확인 기록만 빈 글로 둬. 비어 있는 항목을 경고하고 마지막에 경고가 있는 작업 수를 보여 줘. 입력을 기다리거나 외부에 연결하지 말고, 실행하면 항상 같은 내용을 출력하고 끝나게 해 줘.

요청에 “확인 기록이 비면 경고한다”는 조건이 있으므로, 코드를 받기 전에도 확인 기준 하나를 정할 수 있다. 두 번째 작업에는 확인 누락 경고가 나와야 한다. 첫 번째 작업에는 기록이 모두 있다는 안내가 나와야 한다. 마지막 경고 작업 수는 1이어야 한다.

실행과 확인을 나누는 까닭은 분명하다. 프로그램이 멈추지 않고 끝난 것은 실행에 관한 관찰이다. 확인 누락을 제대로 찾았다는 것은 동작에 관한 판단이다. 실행 중 오류가 없어도 판단 결과는 틀릴 수 있다.

작업 일지는 이 과정을 기억하도록 돕는 도구다. 다만 기록의 내용이 사실인지는 스스로 알아내지 못한다. 확인 칸에 “확인함”이라고만 적어도 빈칸은 아니므로 기록이 있다고 처리한다. 따라서 사람이 무엇을 비교했는지 구체적으로 적어야 한다. 일지가 검사하는 것은 기록의 누락이며, 기록한 작업 자체의 정답 여부는 아니다.

완성 코드

아래 전체를 main.py라는 이름의 파일에 저장한다. Python은 이 파일의 코드를 읽어 수행하는 언어이자 실행 도구다. 이번에는 키보드 입력이나 별도의 입력 파일을 사용하지 않는다. 예시 기록이 코드 안에 들어 있으며, 실행할 때마다 같은 두 작업을 검사한다.

STAGES = (
    ("request", "요청"),
    ("result", "결과"),
    ("execution", "실행"),
    ("check", "확인"),
)

records = [
    {
        "name": "인사 문구 표시",
        "request": "안녕하세요를 한 줄로 보여 줘.",
        "result": "인사 문구를 출력하는 코드를 받음.",
        "execution": "실행 결과: 안녕하세요",
        "check": "기대값 안녕하세요와 실제 출력이 같음.",
    },
    {
        "name": "꾸러미 수 계산",
        "request": "네 명당 한 꾸러미가 필요해.",
        "result": "꾸러미 수를 계산하는 코드를 받음.",
        "execution": "참석자 5명으로 실행함.",
        "check": "",
    },
]


def find_missing(record):
    missing = []
    for key, label in STAGES:
        if record[key].strip() == "":
            missing.append(label)
    return missing


def show_journal(items):
    print("작업 일지")
    warning_count = 0
    for number, record in enumerate(items, start=1):
        print(f"\n{number}. {record['name']}")
        for key, label in STAGES:
            value = record[key].strip()
            print(f"{label}: {value or '(기록 없음)'}")
        missing = find_missing(record)
        if missing:
            warning_count += 1
            print(f"경고: {', '.join(missing)} 기록이 없습니다.")
        else:
            print("상태: 네 단계의 기록이 모두 있습니다.")
    print(f"\n전체 {len(items)}건 / 경고 {warning_count}건")


if __name__ == "__main__":
    show_journal(records)

이 코드는 예시 작업의 인사 프로그램이나 꾸러미 계산 프로그램을 실행하지 않는다. 그런 작업을 했다는 예시 기록을 읽고, 빠진 항목이 있는지 검사한다. 따라서 “실행 결과: 안녕하세요”도 실제로 다른 프로그램을 실행해서 수집한 결과가 아니라 이 예제에 미리 적어 둔 문장이다. 자신이 작업할 때에는 직접 관찰한 내용으로 바꾸어야 한다.

또한 이번 일지는 디스크에 새 기록을 저장하는 기능이 없다. 코드를 바꾸지 않고 다시 실행하면 같은 기록이 나온다. 여기서는 저장 기능을 늘리기보다 네 단계의 차이와 누락 경고에 집중한다.

줄별 해설

처음 여섯 줄의 STAGES는 검사할 항목을 순서대로 묶는다. 등호는 오른쪽 값을 왼쪽 이름에 연결한다. 여기서 request, result, execution, check는 프로그램 안에서 항목을 찾는 이름이다. 그 옆의 요청, 결과, 실행, 확인은 화면에 보여 줄 이름이다. 따옴표로 둘러싼 글을 문자열이라고 한다. 소괄호와 쉼표는 여러 값을 하나로 묶는 데 쓰인다.

records부터 닫는 대괄호까지는 두 작업의 기록이다. 대괄호로 묶은 목록을 리스트라고 하며, 여기에 작업 두 개를 차례로 넣었다. 각 작업은 중괄호로 묶은 딕셔너리다. 딕셔너리는 이름과 값을 짝지어 보관한다. 예를 들어 name이라는 이름에는 인사 문구 표시라는 값이 연결되어 있다. 콜론은 이름과 값을 가르고, 쉼표는 다음 항목과 구별한다.

두 작업은 같은 항목 이름을 사용한다. 첫 작업의 check에는 기대값과 실제 출력이 같았다는 문장이 있다. 두 번째 작업의 check에는 따옴표만 있다. 이것은 길이가 0인 빈 문자열이다. 기록이 없다는 상황을 일부러 표현했다. 나머지 항목에는 모두 문자열이 들어 있다.

def find_missing(record):는 빠진 항목을 찾는 함수의 시작이다. record는 이 함수가 검사할 작업 하나를 받는 이름이다. 다음 줄의 missing = []는 빠진 항목 이름을 모아 둘 빈 리스트를 만든다. 함수 아래에서 오른쪽으로 들여 쓴 줄들은 그 함수에 속한다. Python에서는 이 들여쓰기가 코드의 소속을 나타낸다.

for key, label in STAGES:는 네 항목을 차례로 살피는 반복문이다. 첫 차례에는 key가 request이고 label이 요청이다. 다음 차례에는 result와 결과가 들어온다. 반복문 덕분에 비슷한 검사를 네 번 따로 쓰지 않아도 된다.

record[key]는 현재 작업에서 해당 이름의 값을 꺼낸다. 이어지는 strip()은 글 앞뒤의 공백을 제거한 문자열을 돌려준다. 따라서 아무 글자 없이 공백만 넣은 기록도 빈 기록으로 다룬다. ==는 두 값이 같은지 비교한다. 여기서는 앞뒤 공백을 제거한 글이 빈 문자열인지 묻는다.

if는 조건이 맞을 때만 아래의 들여 쓴 코드를 실행한다. 빈 기록이면 missing.append(label)이 해당 항목의 화면 이름을 목록 끝에 붙인다. return missing은 모인 목록을 함수를 부른 곳에 돌려준다. 빠진 항목이 없다면 빈 목록을 돌려준다. 빈 줄은 코드 묶음을 눈으로 구별하도록 돕는다.

def show_journal(items):는 일지 전체를 화면에 보여 주는 함수다. items로 작업 목록을 받는다. print("작업 일지")는 제목을 출력한다. warning_count = 0은 경고가 있는 작업 수를 처음에는 0으로 둔다. 이 변수는 빠진 항목 수가 아니라 경고가 나온 작업 수를 센다.

enumerate(items, start=1)은 작업을 하나씩 꺼내면서 1부터 번호를 붙인다. 반복할 때 number에는 번호가, record에는 작업 하나가 들어온다. 다음 print의 따옴표 앞에 붙은 f는 중괄호 안의 값을 글 속에 끼워 넣겠다는 표시다. \n은 출력할 때 줄을 바꾸므로 작업 제목 앞에 빈 줄이 생긴다.

그 안의 for문은 각 항목의 내용을 출력한다. value에는 앞뒤 공백을 없앤 기록이 들어간다. value or '(기록 없음)'은 value에 글이 있으면 그 글을 쓰고, 빈 문자열이면 괄호 안 안내를 쓴다. 이 줄은 빈 기록을 화면에 알아보기 쉽게 표시한다. 원래 records의 내용을 채우는 동작은 아니다.

missing = find_missing(record)는 앞에서 만든 검사 함수를 실행해 결과를 받는다. if missing:은 빠진 항목이 하나라도 있는지 판단한다. 있으면 warning_count += 1로 경고 작업 수를 하나 늘린다. ', '.join(missing)은 빠진 항목 이름을 쉼표와 공백으로 이어 붙인다. 요청과 확인이 모두 비었다면 요청, 확인이라는 글이 된다.

else는 빠진 항목이 없을 때 실행할 부분이다. 여기서는 네 단계의 기록이 모두 있다는 상태 문구를 출력한다. 이 문구는 기록 내용까지 검증했다는 뜻을 담지 않는다. 반복문이 끝난 뒤의 마지막 print는 len(items)로 구한 전체 작업 수와 경고 작업 수를 보여 준다.

마지막 두 줄은 이 파일을 직접 실행했을 때 show_journal(records)를 호출한다. 지금은 파일 맨 아래에서 전체 작업 목록을 일지 출력 함수에 넘겨 실행을 시작한다고 이해하면 된다. 아래로 읽으면 기록을 준비하고, 함수를 정의하고, 마지막에 그 함수를 실행하는 흐름이다.

실행 결과

터미널은 명령을 글자로 입력하는 창이다. main.py를 저장한 폴더에서 다음 명령을 입력한다. 환경 준비와 폴더 이동 방법은 작업 환경을 다루는 부분에서 자세히 살핀다.

python3 main.py

예상 출력은 다음과 같다. 첫 작업에는 상태 안내가, 두 번째 작업에는 확인 기록이 없다는 경고가 나온다. 작업 사이와 마지막 집계 앞에는 빈 줄이 하나씩 있다.

작업 일지

1. 인사 문구 표시
요청: 안녕하세요를 한 줄로 보여 줘.
결과: 인사 문구를 출력하는 코드를 받음.
실행: 실행 결과: 안녕하세요
확인: 기대값 안녕하세요와 실제 출력이 같음.
상태: 네 단계의 기록이 모두 있습니다.

2. 꾸러미 수 계산
요청: 네 명당 한 꾸러미가 필요해.
결과: 꾸러미 수를 계산하는 코드를 받음.
실행: 참석자 5명으로 실행함.
확인: (기록 없음)
경고: 확인 기록이 없습니다.

전체 2건 / 경고 1건

여기서 독자가 직접 확인할 것은 세 가지다. 첫 작업에 누락 경고가 없는지, 두 번째 작업에 확인 누락 경고가 있는지, 경고 작업 수가 1인지 비교한다. 이 셋이 예상과 같아야 이번 입력에 대한 검사가 끝난다. 화면에 글자가 많이 나왔다는 사실만으로 확인을 대신하지 않는다.

한 번 더 시험하려면 두 번째 작업의 check 값을 공백 세 칸으로 바꾸어 실행해 본다. 출력은 위와 같아야 한다. strip()이 공백을 없앤 뒤 검사하기 때문이다. 바꾸기 전후의 코드를 비교해 check 값만 달라졌는지 살피고 실행한다. 이런 작은 변경과 비교가 AI의 수정안을 검토하는 연습이 된다.

실무에서 자주 틀리는 것

실행했다는 말로 확인 기록까지 채운다

다음은 Python으로 실행할 수 있지만 기록으로는 부족한 예다. 실행 여부만 적어 놓고 확인 칸에도 같은 뜻의 문장을 넣었다. 무엇을 기대했고 무엇이 나왔는지 알 수 없다.

execution = "참석자 5명으로 실행함."
check = "실행했으니 확인 완료."

직접 비교한 뒤에는 아래처럼 고친다. 기대한 값과 관찰한 값이 들어 있어 나중에 읽는 사람도 판단의 근거를 알 수 있다. 실제 출력이 달랐다면 같다고 쓰지 말고 다른 값을 그대로 기록해야 한다.

execution = "참석자 5명으로 실행함. 실제 출력: 2"
check = "기대값 2와 실제 출력 2가 같음."

이 두 줄도 기록을 담는 코드일 뿐 계산기를 시험하는 코드는 아니다. 적힌 문장이 관찰한 사실인지 확인하는 책임은 기록을 작성한 사람에게 있다.

비어 있는 확인 칸을 완료 표시로 덮는다

누락 경고가 거슬린다고 아래처럼 빈칸을 자동으로 채우면 프로그램의 목적이 바뀐다. 실행은 되지만, 확인하지 않은 작업이 기록상으로는 확인한 작업처럼 보인다.

record = {"check": ""}
if record["check"] == "":
    record["check"] = "확인 완료"

빠진 사실을 남기고 알려 주는 쪽으로 고친다. 다음 코드는 기록을 바꾸지 않고 경고만 출력한다. AI가 이런 수정을 제안했을 때에도 어떤 값이 바뀌는지 읽어야 한다.

record = {"check": ""}
if record["check"].strip() == "":
    print("경고: 확인 기록이 없습니다.")

원래 코드의 대입문은 확인 칸의 값을 바꿨고, 고친 코드의 print는 안내를 표시한다. 두 동작은 화면이 비슷해 보여도 기록에 미치는 영향이 다르다.

공백을 글이 있는 기록으로 센다

눈으로 보면 비어 있지만 실제로는 공백이 들어 있는 경우가 있다. 다음 비교는 공백 세 칸과 빈 문자열이 다르기 때문에 경고를 출력하지 않는다.

check = "   "
if check == "":
    print("경고: 확인 기록이 없습니다.")

앞뒤 공백을 제거한 뒤 비교하면 이 경우도 잡을 수 있다. 이 작은 예를 실행해 보면 수정 전에는 출력이 없고, 수정 후에는 경고가 한 줄 나온다. “고쳤다”는 설명을 읽는 것에서 멈추지 않고 달라진 결과를 확인한다.

check = "   "
if check.strip() == "":
    print("경고: 확인 기록이 없습니다.")

이번 완성 코드는 모든 항목이 문자열이며, 필요한 항목 이름이 모두 있다는 조건으로 작성했다. 항목 자체를 지우거나 문자열 대신 다른 종류의 값을 넣는 경우까지 처리하지는 않는다. 프로그램이 확인하는 범위를 알아야 확인하지 않은 범위까지 믿는 일을 줄일 수 있다.

한눈에 보기

한 번의 작업에서 남길 기록과 판단 기준

단계	남길 내용	끝났다고 판단할 근거
요청	원하는 동작과 조건	무엇을 만들지 설명할 수 있음
결과	받은 코드와 설명의 요점	요청과 결과를 대조함
실행	사용한 예시와 실제 출력	자신의 환경에서 동작을 관찰함
확인	기대 결과와 비교한 내용	같은 점과 다른 점을 기록함
수정 후 반복	바뀐 부분과 재실행 결과	변경을 검토하고 다시 비교함

작업 일지의 경고가 0건이라는 말은 필요한 기록이 비어 있지 않다는 뜻이다. 프로그램의 모든 경우가 맞다는 뜻으로 넓혀 읽으면 안 된다. 사람이 적는 내용이 구체적일수록 일지가 다음 판단에 도움이 된다.

AI와 함께 만드는 작업에서는 코드를 쓰는 시간 일부가 요청하고 판단하는 시간으로 옮겨 간다. 처음부터 많은 문법을 알 필요는 없지만, 받은 답을 실행하고 근거를 남기는 습관은 첫 작업부터 필요하다. 다음에는 AI가 어떻게 이런 답을 만들며, 왜 그럴듯한 답에도 잘못이 섞일 수 있는지 살펴본다.

연습 문제

1. 두 번째 작업의 확인 기록을 채우려 한다. 참석자 5명일 때 기대값과 실제 출력이 모두 2였다면, check에 넣을 문장을 작성하라. 수정 뒤 마지막 집계가 어떻게 바뀔지도 예상하라.
2. 원래 완성 코드에서 두 번째 작업의 execution도 빈 문자열로 바꾸라. 경고 문구와 마지막 경고 작업 수를 먼저 적은 뒤 실행 결과와 비교하라.
3. 첫 번째 작업의 check를 공백 세 칸으로 바꾸고 두 번째 작업은 원래대로 두라. 경고 작업 수를 예상하고, 공백이 왜 빈 기록으로 처리되는지 설명하라.
4. 확인 칸에 “확인 완료”라고 적어 경고가 없어졌다. 이것만으로 꾸러미 계산이 맞다고 판단할 수 있는지 설명하고, AI에게 추가로 요청할 문장을 작성하라.

정답과 해설

1. “참석자 5명에서 기대값 2와 실제 출력 2가 같음.”처럼 입력과 비교 결과를 함께 적는다. 실제로 관찰한 결과를 기록한다는 조건이다. 두 작업 모두 빈 항목이 없어지므로 마지막 줄은 “전체 2건 / 경고 0건”이 된다. 두 번째 작업에도 네 단계의 기록이 모두 있다는 상태 문구가 나온다.

2. 두 번째 작업에는 실행과 확인 기록이 모두 없다. STAGES에 적힌 순서대로 이름을 모으므로 “경고: 실행, 확인 기록이 없습니다.”가 나온다. 마지막 줄은 여전히 “전체 2건 / 경고 1건”이다. warning_count는 빠진 항목이 두 개여도 그 작업에 대해 한 번만 증가하기 때문이다.

3. 마지막 줄은 “전체 2건 / 경고 2건”이다. 첫 번째 작업도 확인 기록이 없는 것으로 처리된다. strip()이 공백 세 칸을 제거하면 빈 문자열이 되고, 빈 문자열과 같다는 비교가 성립한다. 두 번째 작업의 확인도 원래 비어 있으므로 두 작업 모두 경고 대상이다.

4. 판단할 수 없다. 일지는 확인 칸에 글이 있는지만 검사하며 계산의 옳고 그름을 검사하지 않는다. 아래처럼 비교할 예시를 요청할 수 있다. 받은 제안은 직접 실행해 기대값과 비교하고, 코드가 바뀌면 변경 부분도 검토한다.

   네 명당 한 꾸러미가 필요한 계산을 확인하고 싶어. 참석자 4명과 5명일 때 기대값은 각각 1과 2야. 이 두 경우를 실행해 비교할 방법을 제안해 줘. 코드를 수정한다면 어떤 부분이 달라지는지도 설명해 줘.