프로그래머스 AI 코딩테스트 준비: AI 답변을 검증하고 수정하는 연습

AI가 그럴듯한 코드를 만들었다고 해서 문제가 해결된 것은 아닙니다. 프로그래머스 AI 코딩테스트를 준비한다면 답변을 받은 뒤 입력 조건을 다시 읽고, 작은 반례로 검증하고, 실패 원인을 근거로 수정하는 연습부터 하세요. 특히 정상 입력의 반환값뿐 아니라 실패 뒤 원본 데이터가 어떻게 남는지 확인해야 합니다.

이 글은 공식 안내에서 확인되는 AI 평가의 방향과 독립적인 코딩 연습을 나눠 설명합니다. 바로 연습하려면 PracHub의 AI 코딩 도구 활용 전략 질문을 열고, 도구를 사용한 이유보다 결과를 검증한 방법부터 답해 보세요.

공식 안내에서 확인되는 범위부터 정하기

공식 사실: 프로그래머스의 AI 역량평가 소개는 문제 해결 과정에서 AI에 프롬프트를 입력하고, 답변을 확인하며, 반복적으로 수정하는 흐름을 설명합니다. 최종 결과와 함께 프롬프트 및 AI 상호작용 기록을 분석한다는 설명도 있습니다. 이는 결과물과 작업 과정을 함께 준비할 이유가 됩니다. 프로그래머스 AI 역량평가 소개

그러나 이 소개만으로 모든 초대 시험의 시간, 언어, 문제 수, 배점, 외부 AI 허용 범위를 확정할 수는 없습니다. 초대장에 적힌 평가 종류와 응시자 안내가 우선입니다. 일반 코딩테스트에서 허용하지 않는 도구를 AI 평가라는 이름만 보고 사용해도 된다고 판단하면 안 됩니다. 여기서 다루는 내용은 사전 연습입니다.

자료를 찾을 때는 서비스 제공자도 구분하세요. CodeSignal의 AI 관련 상품 설명은 프로그래머스의 기능 증거가 아닙니다. 비슷한 제목을 가진 준비 글이라도 도구와 평가가 다르면 사용할 수 있는 결론이 달라집니다. 필요한 내용은 해당 초대의 안내에서 다시 확인하고, 확인하지 못한 항목은 모른다고 기록하세요.

후보자 보고의 경계: 이 글은 같은 모집 주기의 독립적인 응시 후기 두 건으로 실제 전형을 재구성하지 않습니다. 아래 PracHub 질문은 관련 기술을 연습하는 기록이며, 프로그래머스가 앞으로 출제할 문제나 평가 기준을 보증하지 않습니다. 준비에 대한 추론: 안내에서 확인되는 반복 검토 흐름을 연습하려면, 정답 계약과 수정 근거가 보이는 작은 사례가 유용합니다.

AI에게 물어보기 전에 정답 계약을 쓰기

이 글의 원본 합성 연습은 재고 예약 함수입니다. stock은 SKU별 재고이고 requests는 SKU와 수량의 목록입니다. 반환값은 예약 뒤의 새 재고 사전입니다. 호출자가 넘긴 원본 사전은 성공해도 실패해도 바뀌지 않아야 합니다. 잘못된 요청은 ValueError로 거절한다고 정합니다.

수량은 양의 정수여야 하며 True 같은 불리언은 허용하지 않습니다. 같은 SKU가 여러 번 나올 수 있으므로 수량을 먼저 합칩니다. 모든 SKU가 존재하고 합산 수량을 충족할 때만 결과를 만듭니다. 한 항목이라도 실패하면 전체 요청을 거절합니다. 빈 요청은 원본과 값이 같은 새 사전을 반환합니다.

여기서 원자적이라는 말은 이 함수 호출의 계약을 뜻합니다. 메모리 사전을 복사하는 예제는 여러 사용자가 동시에 예약하는 데이터베이스 서비스를 구현하지 않습니다. 실제 서비스라면 재고 변경과 예약 기록을 같은 저장소 트랜잭션으로 처리하거나 동시성 제어를 설계해야 합니다. 이 연습의 결과만으로 그 보장을 주장하지 마세요.

계약을 작성할 때는 입력의 의미까지 정하세요. SKU의 대소문자를 합칠지, 알 수 없는 SKU를 건너뛸지, 수량 문자열을 자동 변환할지는 서로 다른 문제입니다. 여기서는 키를 그대로 사용하고, 알 수 없는 키와 문자열 수량을 거절합니다. 편리해 보이는 정규화가 요청의 의미를 바꾸지 않도록 범위를 고정한 것입니다.

출력의 예시도 먼저 만드세요. 재고 A=5에서 A를 두 개씩 두 번 예약하면 새 재고는 A=1입니다. 세 개씩 두 번 요청하면 합계 여섯 개이므로 거절하고 원본은 여전히 다섯 개입니다. 이 두 기대값은 패치가 무엇을 반환하느냐와 관계없이 문제의 계약에서 계산합니다.

그럴듯한 패치를 작은 반례로 읽기

다음은 작성자가 만든 AI 답변처럼 보이는 결함 패치입니다. 특정 AI 모델의 실제 출력이나 응시 화면에서 가져온 코드가 아닙니다. 정상적인 단일 요청에서 작동하는 코드가 어떻게 중요한 조건을 놓치는지 보여주기 위해 작성했습니다.

def flawed(stock, requests):
    for sku, qty in requests:
        if not isinstance(qty, int) or qty <= 0:
            raise ValueError('quantity')
        if sku not in stock or stock[sku] < qty:
            raise ValueError('stock')
        stock[sku] -= qty
    return stock

재고 다섯 개에서 세 개를 예약한 다음 다시 세 개를 요청하면 두 번째 항목에서 예외가 발생합니다. 하지만 첫 번째 차감은 이미 끝났습니다. 호출자에게 거절을 알리면서 원본을 두 개로 남깁니다. 오류 메시지가 있다는 사실은 실패가 안전하게 처리됐다는 뜻이 아닙니다.

앞에서 알려진 SKU를 두 개 예약하고 뒤에서 알 수 없는 SKU를 요청해도 같은 문제가 생깁니다. 단순히 중복 요청을 합산하는 수정만 넣으면 이 두 번째 실패 경로가 남을 수 있습니다. 그래서 반례는 같은 버그를 반복 확인하는 여러 숫자가 아니라 서로 다른 계약 위반을 드러내도록 선택해야 합니다.

불리언도 별도의 반례입니다. Python에서 isinstance(True, int)는 참이므로 이 패치는 True를 수량 하나처럼 취급합니다. 입력 계약이 엄격한 정수라면 type(qty) is int 같은 검사가 필요합니다. 반대로 어떤 문제에서 불리언을 허용한다면 그 계약에 맞춰야 합니다. 타입 검사 자체가 언제나 같은 정답은 아닙니다.

빈 요청은 오류 없이 끝나지만 반환값이 원본 사전과 같은 객체입니다. 호출자가 반환값을 수정하면 원본도 바뀔 수 있습니다. 값의 일치와 객체 공유는 다른 검사입니다. 이 예제에서는 새 결과를 반환하므로 빈 요청에서도 복사본을 만들어야 합니다. 부작용을 확인하지 않으면 정상 사례만으로는 이 문제를 놓칩니다.

수정 요청을 실패 증거로 좁히기

“코드를 더 좋게 만들어 줘” 대신 구체적인 반례를 전달해 보세요. 예를 들어 “원본 {'A': 5}에서 요청 [('A', 3), ('A', 3)]은 거절되어야 하며 원본은 다섯 개여야 한다. 현재 패치는 예외 뒤 두 개가 남는다. 모든 입력 검증과 합산 검사를 마친 뒤 새 결과를 만들어라”라고 적을 수 있습니다.

이 문장은 원본 연습용 프롬프트 초안입니다. 실제 AI를 호출해 개선 효과를 측정한 기록은 아닙니다. 핵심은 길이가 아니라 네 가지 정보입니다. 기대 동작, 관측한 실패, 실패를 일으킨 최소 입력, 허용되는 수정 범위를 함께 제공합니다. AI가 조건을 새로 만들어내지 않도록 계약도 첨부합니다.

공식 검토 지침: GitHub의 AI 생성 코드 검토 안내는 기능 검사와 의도 확인을 함께 다루며, 누락한 제약이나 존재하지 않는 API 같은 오류를 살피라고 설명합니다. 이를 여기서는 계약과 독립 반례를 대조하는 연습으로 적용합니다. 이 문서는 프로그래머스의 시험 규칙을 설명하지 않습니다. GitHub의 AI 코드 검토 안내

수정한 답변이 테스트를 지우거나 계약을 완화하면 원래 요청을 해결한 것이 아닙니다. 부족한 재고를 허용하거나 잘못된 SKU를 조용히 무시하면 표면적으로 예외는 줄어들지만 정답의 의미가 달라집니다. 변경된 조건을 먼저 비교하고, 그다음 구현을 읽으세요. 새로운 예외 처리 코드가 있다는 이유만으로 검토를 종료하지 마세요.

검증과 변경을 분리한 풀이

수정한 함수는 입력을 읽으며 필요한 수량을 합산합니다. 전체 부족 여부를 검사한 뒤 원본을 복사하고 결과에만 차감합니다. 실제 실행 파일의 핵심은 다음과 같습니다. 전체 소스와 결과는 원본 재고 예약 연습 ZIP에 포함합니다.

from collections import Counter

def reserve(stock, requests):
    needed = Counter()
    for sku, qty in requests:
        if type(qty) is not int or qty <= 0:
            raise ValueError('quantity')
        if sku not in stock:
            raise ValueError('unknown sku')
        needed[sku] += qty
    if any(stock[k] < v for k, v in needed.items()):
        raise ValueError('shortage')
    result = stock.copy()
    for sku, qty in needed.items():
        result[sku] -= qty
    return result

이 구현의 검증 순서는 오류 종류를 설명하기도 쉽습니다. 수량과 SKU 검사를 통과한 뒤에만 합계를 판단합니다. 같은 요청이 여러 오류를 포함할 때 어떤 오류를 먼저 반환할지도 API 계약의 일부가 될 수 있습니다. 현재 연습은 거절 여부와 원본 보존을 확인하며 모든 오류 메시지 우선순위를 별도로 규정하지 않습니다.

재고 값은 이미 유효한 비음수 정수라고 가정합니다. 이 가정이 없어지면 재고 자체의 타입과 범위 검사도 필요합니다. 함수가 검증하지 않는 입력을 감추지 말고 설명하세요. 요청 항목의 구조나 SKU 자료형이 완전히 임의라면 또 다른 방어가 필요합니다. 여기서는 두 항목 튜플과 해시 가능한 SKU라는 입력 형식이 주어졌습니다.

복잡도도 조건과 연결해 말하세요. 요청 수를 n, 재고 키 수를 s라고 하면 요청 합산은 n에 비례하고 사전 복사는 s에 비례합니다. 평균적인 사전 연산을 가정하면 시간은 O(n+s)이고 추가 공간도 O(n+s) 범위입니다. 작은 예제가 빨리 끝났다는 관측은 이 분석을 대신하지 않습니다.

수정 전후를 반환값과 상태로 함께 대조하기

원본 로컬 관측: Python 3.12.14에서 여덟 가지 사례를 실행했습니다. 수정한 함수는 기대 반환값 또는 거절 여부와 입력 사전 보존 검사를 모두 통과했습니다. 이는 정의한 작은 사례의 결과이며 실제 시험 플랫폼, AI 모델, 동시 예약 서비스의 동작을 검증한 결과는 아닙니다.

독립 검사는 테스트가 구현을 그대로 따라 하지 않도록 만드세요. 중복 수량의 기대값은 손으로 네 개라고 합산하고, 거절 뒤 원본은 호출 전 스냅샷과 비교합니다. 같은 잘못된 루프를 테스트에 복사하면 코드와 테스트가 함께 틀릴 수 있습니다. AI가 생성한 테스트가 있다면 기대값의 출처도 별도로 검토해야 합니다.

이번 저장된 검사에는 빈 요청에서의 값 일치와 원본 보존이 포함되며, 객체 동일성은 코드의 복사 경로를 읽어 확인합니다. 더 강한 테스트를 만들려면 반환값을 수정한 뒤 원본이 유지되는지도 검증할 수 있습니다. 실행하지 않은 검사를 이미 통과했다고 표현하지 않는 것이 검토 기록의 기본입니다.

검토 기록을 짧고 재현 가능하게 남기기

검토 기록에는 최초 조건, 실패 입력, 실제 상태, 수정 이유, 재실행 결과를 남기세요. “AI 코드를 개선했다”는 설명보다 “부족한 중복 요청에서 예외 뒤 원본 재고가 줄어드는 반례를 찾았고, 전체 검증 뒤 복사본에만 차감하도록 바꿨다”는 설명이 검증 가능합니다. 파일 이름과 실행 환경을 연결하면 다른 사람도 확인할 수 있습니다.

각 수정은 어느 조건을 해결하는지 보여야 합니다. 첫 변경은 불리언 거절, 두 번째는 같은 SKU 합산, 세 번째는 원본 보존처럼 나누어 설명할 수 있습니다. 다만 이 함수에서는 합산과 변경 분리가 함께 실패 안전성을 만듭니다. 수정 단계를 잘게 나눴다고 독립적인 정확성 보장이 생기는 것은 아닙니다.

다시 실행할 때는 실패했던 입력만 확인하지 마세요. 정상 중복 요청과 빈 요청도 유지해야 합니다. 예외 경로를 고치면서 성공 결과를 바꾸거나, 성공 결과를 복사하면서 입력 검사를 빼먹을 수 있기 때문입니다. 회귀 검사는 확인한 계약을 고정하는 장치입니다. 테스트 개수를 늘리는 것보다 서로 다른 실패 원인을 유지하는 것이 중요합니다.

남은 제한도 기록합니다. 이 연습은 잘 형성된 요청 튜플과 유효한 재고 사전을 전제로 합니다. 프로세스 종료, 동시 호출, 저장 실패, 외부 시스템과의 예약 동기화는 다루지 않습니다. 추가 요구가 생기면 예제를 그대로 확대했다고 주장하지 말고 저장소 경계와 실패 모델을 다시 설계해야 합니다.

같은 실패를 다른 입력에서도 설명할 수 있는가

연습을 다시 할 때는 테스트 이름을 읽기 전에 계약에서 결과를 계산해 보세요. 재고가 다섯 개라는 조건과 요청 합계가 여섯 개라는 조건만으로 거절을 결정할 수 있어야 합니다. 코드가 어떤 순서로 요청을 읽는지는 이 결정에 영향을 주면 안 됩니다. 합산 뒤에 한 번 판단하는 이유가 여기 있습니다.

요청 순서를 바꾸는 질문도 유용합니다. [('A', 2), ('Z', 1)]과 [('Z', 1), ('A', 2)]은 둘 다 전체 거절이고 원본은 다섯 개여야 합니다. 결함 패치에서는 앞에 있는 항목에 따라 원본이 달라질 수 있습니다. 수정된 함수는 변경 전에 검증하므로 같은 거절 상태를 유지합니다. 이 비교는 계약에 대한 손검토이며 저장된 여덟 사례 외의 추가 실행 결과로 세지 않습니다.

AI가 복사본을 먼저 만들고 그 복사본에서 차감하는 대안을 제시할 수도 있습니다. 실패 때 원본이 유지된다면 이번 부작용 계약의 일부는 해결합니다. 그러나 합산 필요량과 입력 타입을 어떻게 검사하는지는 여전히 읽어야 합니다. 특정 구현 순서를 외우기보다 반환값, 거절 조건, 원본 보존이 모두 맞는지 평가하세요. 대안이 짧아도 세 조건의 증거는 필요합니다.

검토를 마치는 기준도 구체적으로 정하세요. 계약의 각 항목이 코드의 어느 부분과 어떤 반례로 확인되는지 연결되고, 새 변경이 기존 성공 결과를 깨지 않았으며, 남은 미검증 범위가 기록돼 있으면 이번 연습을 종료할 수 있습니다. “AI도 맞다고 했다”는 별도의 정답 근거가 아닙니다. 같은 도구에 같은 코드를 다시 물어보는 것과 독립적인 기대값을 대조하는 것을 구분하세요.

관련 질문으로 검증 근거를 말하는 연습하기

아래 제목은 확인한 PracHub 질문 페이지에 직접 연결됩니다. 후보자 보고에서 정리된 연습 기록으로 다루되, 특정 프로그래머스 응시자의 실제 출제나 합격 기준으로 해석하지 마세요. 먼저 한 가지 기대 동작과 하나의 반례를 적은 뒤 답변을 준비하세요.

마지막 질문은 HTTP API 연습이므로 재고 사전 함수와 실행 환경이 다릅니다. 그대로 같은 답을 복사하기보다, 잘못된 입력이 어느 경계에서 거절되고 부작용이 언제 시작되는지 적용해 보세요. 각 질문의 실제 요구가 달라지면 독립적인 기대 결과도 다시 만들어야 합니다.

한 번의 연습을 마칠 때는 입력 계약을 말하고, 반례를 실행하고, 수정 전후 상태를 설명할 수 있는지 확인하세요. 프롬프트를 많이 저장하는 것만으로 이 세 가지 능력이 생기지는 않습니다. AI 생성 코드 검증 질문에서 자신의 답변을 검토 기록과 대조한 뒤, 다음 연습에서 새 제약 한 가지를 추가해 보세요.

Sources and Further Reading

• 프로그래머스: AI 역량평가 소개

• GitHub: Review AI-generated code

• PracHub practice record: Explain AI coding assistant usage strategy

자료 확인: 2026-10-07. 실행 결과와 합성 입력은 첨부한 원본 코드·결과 파일에서 대조할 수 있습니다. 응시자별 초대 안내를 대체하지 않습니다. 재고 데이터, 결함 패치, 수정 프롬프트와 실행 사례는 원본 연습 자료입니다.