Claude Code와 프롬프트 모의 시나리오

이 절은 두 도메인을 함께 다룬다. Claude Code 설정과 워크플로우가 20퍼센트, 프롬프트 엔지니어링과 구조화 출력이 20퍼센트로, 합치면 시험의 40퍼센트를 차지한다. 비중이 큰 만큼 문항도 넉넉히 풀이한다. Claude Code 쪽에서는 메모리 파일과 권한, 훅의 역할 구분이, 프롬프트 쪽에서는 구조화 출력의 보장 수단과 사고 설정의 최신 사양이 핵심 함정이다.

모의 문항 1 — 프로젝트 규칙을 어디에 두나

상황. 한 팀이 Claude Code로 협업하는데, 모든 팀원이 동일한 코딩 컨벤션과 빌드 명령을 에이전트에게 매번 알려 줘야 하는 불편을 겪는다. 이 규칙이 저장소에 함께 버전 관리되어 모든 팀원에게 자동 적용되게 하려면 어떻게 하는가.

후보. 첫째, 각자 매 세션 시작 시 규칙을 프롬프트로 입력한다. 둘째, 프로젝트 루트의 메모리 파일에 규칙을 적어 저장소에 커밋한다. 셋째, 개인 홈 디렉터리의 사용자 메모리에 적는다. 넷째, 규칙을 외부 위키에 적고 링크만 공유한다.

정답은 둘째다. 프로젝트 메모리 파일은 저장소에 함께 커밋되어 모든 팀원의 세션에 자동으로 적용되므로, 팀 공유 규칙의 정석 위치다. "저장소에 버전 관리되고 모두에게 자동 적용"이라는 제약이 곧바로 프로젝트 메모리를 가리킨다.

오답을 보자. 첫째는 반복 입력이라 자동화가 아니다. 셋째는 사용자 개인 범위라 본인에게만 적용되고 팀에 공유되지 않는다. 프로젝트 범위와 사용자 범위를 바꿔 놓은 보기가 단골 함정이다. 넷째는 위키에 적어도 에이전트가 자동으로 읽지 않으므로 자동 적용 제약을 만족하지 못한다.

모의 문항 2 — 자동 검사를 강제하기

상황. 에이전트가 코드를 수정한 뒤 매번 포매터와 린터를 돌리게 하고 싶다. 에이전트가 자율 판단으로 가끔 빼먹지 않고, 파일을 고칠 때마다 반드시 실행되도록 결정적으로 보장해야 한다. 어떻게 하는가.

후보. 첫째, 메모리 파일에 "수정 후 항상 린트하라"고 적는다. 둘째, 파일 편집 이벤트에 묶이는 훅으로 포매터와 린터를 자동 실행하게 한다. 셋째, 매번 사용자가 직접 린트 명령을 친다. 넷째, 더 똑똑한 모델로 바꿔 빼먹지 않기를 기대한다.

정답은 둘째다. 훅은 특정 이벤트에 결정적으로 묶여 실행되는 결정 코드이므로, 에이전트의 확률적 판단과 무관하게 반드시 동작한다. "결정적으로 보장"이라는 제약이 메모리 지시가 아니라 훅을 가리킨다.

오답을 보자. 첫째는 메모리 파일의 지시는 강한 권고일 뿐 확률적이라 "반드시"를 보장하지 못한다. 메모리 지시와 훅의 차이, 즉 권고와 강제의 차이를 묻는 것이 이 문항의 핵심이다. 셋째는 사람 손이 들어가는 비자동화이고, 넷째는 모델 업그레이드로 보장을 대신하려는 함정이다. 결정적 보장이 필요한 자리에 확률적 수단을 답으로 내미는 보기는 항상 오답이다.

모의 문항 3 — 출력 형식을 보장하기

상황. 한 서비스가 Claude의 응답을 그대로 다운스트림 시스템에 JSON으로 흘려보낸다. 그런데 모델이 가끔 JSON 앞뒤에 설명 문장을 붙이거나 필드를 빠뜨려 파싱이 깨진다. 응답이 지정한 스키마를 반드시 따르게 하려면 어떻게 하는가.

후보. 첫째, 프롬프트에 "JSON만 출력하라"고 강하게 지시한다. 둘째, 구조화 출력의 형식 지정 설정에 JSON 스키마를 넘겨 응답이 스키마를 따르도록 강제한다. 셋째, 응답을 받은 뒤 정규식으로 JSON 부분만 뽑아낸다. 넷째, 출력을 받아 파싱이 실패하면 다시 요청한다.

정답은 둘째다. 구조화 출력에서 출력 형식 설정에 JSON 스키마를 지정하면 응답이 그 스키마를 따르도록 보장되어, 설명 문장이 섞이거나 필드가 빠지는 일이 구조적으로 막힌다. "반드시 스키마를 따르게"라는 제약이 구조화 출력 설정을 가리킨다. 여기서 시험이 노리는 함정은 따로 있다. 형식을 옛 방식의 응답 형식 필드로 지정하려는 보기를 섞어 두는 것이다. 최신 사양에서 형식 지정은 출력 형식 설정을 통해 이뤄지므로, 구식 필드명을 고르면 오답이다.

오답을 보자. 첫째는 자연어 지시라 확률적 준수에 그쳐 보장이 안 된다. 셋째와 넷째는 사후 보정과 재시도로, 동작은 하지만 추가 지연·비용이 들고 근본적으로 형식을 보장하지 못한다. 사후 처리로 형식 문제를 메우려는 보기는 보장이 필요한 맥락에서 함정이다.

모의 문항 4 — 사고 설정의 최신 사양

상황. 복잡한 추론이 필요한 작업에서 모델이 더 깊이 생각하도록 확장 사고를 켜려 한다. 한 팀원이 예전 자료를 보고 사고 예산 토큰 값과 함께 온도, 상위 확률 샘플링 값을 같이 지정한 설정을 들고 왔다. 최신 모델 기준으로 어떤 설정이 옳은가.

후보. 첫째, 사고를 적응형으로 켜고 별도의 예산 토큰이나 샘플링 인자를 지정하지 않는다. 둘째, 사고 예산 토큰을 크게 지정하고 온도도 함께 낮춘다. 셋째, 상위 확률 샘플링 값을 조정해 사고 깊이를 제어한다. 넷째, 온도를 0으로 고정해 사고를 결정적으로 만든다.

정답은 첫째다. 최신 모델에서 확장 사고는 적응형 방식으로 설정하며, 모델이 작업 난도에 따라 사고량을 스스로 조절한다. 동시에 예산 토큰, 온도, 상위 확률 같은 샘플링 인자는 최신 모델에서 제거되었으므로 지정하지 않는다. 옛 자료에 남아 있는 이 인자들을 그대로 끌고 온 보기가 바로 이 문항의 함정이다.

오답을 보자. 둘째, 셋째, 넷째는 모두 제거된 인자를 지정하려는 보기다. 예전 사양에서 쓰이던 사고 예산 토큰이나 온도, 상위 확률 조정을 답으로 내미는 것은 최신 사양을 모르고 옛 자료를 외운 응시자를 거르는 전형적 출제다. 사고는 적응형만, 샘플링 인자는 지정 안 함이 정답의 뼈대다.

정리

• 팀이 공유하고 저장소에 버전 관리되어 자동 적용되어야 하는 규칙은 프로젝트 메모리 파일에 두며, 사용자 범위와 프로젝트 범위를 바꿔 놓은 보기는 함정이다.
• 결정적으로 보장되어야 하는 자동 검사는 이벤트에 묶이는 훅으로 처리하며, 메모리 지시는 권고일 뿐이라 반드시를 보장하지 못한다.
• 출력 형식을 반드시 보장해야 하면 구조화 출력의 형식 설정에 JSON 스키마를 넘기며, 옛 응답 형식 필드를 고르거나 사후 보정으로 메우는 보기는 오답이다.
• 확장 사고는 최신 모델에서 적응형으로만 설정하고 예산 토큰·온도·상위 확률 같은 제거된 인자는 지정하지 않으며, 옛 인자를 끌고 온 보기가 함정이다.
• 결정적 보장이 필요한 자리에 확률적 수단을, 자동화가 필요한 자리에 사람 개입을, 최신 사양 자리에 구식 인자를 내미는 보기는 이 도메인의 반복되는 오답 패턴이다.