TL;DR

  • CCAR-F의 보장 요구사항은 코드 수준의 강제가, 정확도·일관성·형식 요구사항은 프롬프트 수준의 지시가 정답인 구조임.
  • 자체 문제 은행에서 코드 수준 답이 프롬프트 수준 오답보다 정답으로 제시되는 문항은 에이전트 아키텍처와 오케스트레이션에 12개, 프롬프트 엔지니어링에 5개로 분포함.
  • 가이드의 결정론적 메커니즘 권고는 일반론이 아니라 결정론적 준수나 보장된 준수가 필요한 경우에 한정됨.
  • 실패의 결과가 대화 밖으로 나가 비즈니스·안전 문제를 일으키면 보장이 필요하고, 출력 자체의 품질 문제로 끝나면 정확도가 필요함.
  • temperature 0, 모델 변경, 잘못된 범위의 훅(hook)과 같이 실제 메커니즘을 보장 수단처럼 제시하는 오답 유형을 구분해야 함.

이 문제들이 실제로 속한 영역

  • 대부분의 수험생은 이 문제군을 프롬프트 엔지니어링(Prompt Engineering) 및 구조화된 출력(Structured Output)으로 분류함.
  • 스키마 논의와 검증(validation) 어휘가 다뤄지는 영역도 여기에 해당함.
  • 자체 문제 은행에서 코드 수준 답이 프롬프트 수준 오답보다 정답으로 제시되는 문항은 에이전트 아키텍처와 오케스트레이션(Agentic Architecture and Orchestration)에 12개, 프롬프트 엔지니어링에 5개로 분포함.
  • 훅(hook), 선행 조건 게이트(prerequisite gate), 서브에이전트 격리(subagent isolation), 도구 범위 제한(tool scoping) 등이 포함됨.
  • 반대 방향의 분포도 나타남.
  • 프롬프트 수준 답이 정답이고 코드 수준 선택지가 오답으로 표시된 문항의 3분의 2가 프롬프트 엔지니어링에 속함.
  • 따라서 구조화된 출력을 읽으며 이 주제를 복습하면 문구가 정답인 사례는 접하지만 문구가 정답이 아닌 사례 대부분을 놓치게 됨.
  • 반대로 “항상 코드로 강제”를 암기하면 정반대의 오류를 범하게 됨.

가이드 자체의 표현은 조건부임

  • 공식 가이드에서 직접 가져갈 만한 핵심은 결정론적 메커니즘과 프롬프트 지시를 대비할 때 조건이 함께 제시된다는 점임.
  • 훅과 게이트는 “결정론적 준수가 필요한 경우(when deterministic compliance is required)” 및 “비즈니스 규칙이 보장된 준수를 요구하는 경우(when business rules require guaranteed compliance)”에 등장함.
  • 구조화된 출력에 관한 가장 강한 표현인 “스키마를 준수하는 출력을 보장하는 가장 신뢰할 수 있는 접근법”에도 보장(guaranteed)이라는 조건이 포함됨.
  • 가이드는 강제가 일반적으로 더 낫다고 말하지 않으며, 요구사항이 보장을 필요로 할 때 선택하는 수단이라고 설명함.
  • 같은 가이드의 다른 부분에서는 프롬프트 수준 답도 제시함.
  • 정규화 규칙은 스키마와 함께 프롬프트에 포함됨.
  • 퓨샷 예시(few-shot examples)는 형식 일관성을 확보하는 가장 효과적인 기법으로 제시됨.
  • 도구 설명(tool descriptions)은 라우팅 계층이 아니라 도구 선택의 주요 메커니즘으로 제시됨.

작동하는 판별법

  • 요구사항이 보장(guarantee)을 필요로 하는지, 아니면 정확도(accuracy)를 필요로 하는지 질문함.
  • 어떤 일이 절대로 발생해서는 안 되거나 어떤 조건이 항상 유지되어야 하며, 위반이 품질 문제가 아니라 비즈니스 또는 안전상의 실패라면 모델 외부의 강제가 필요함.
  • 어떤 작업을 잘 수행하거나 일관되게 수행하거나 특정 형식으로 출력해야 한다면 프롬프트 문제이며, 인프라스트럭처를 추가하는 것은 잘못된 답임.
  • 둘을 구분하는 신뢰할 수 있는 방법은 요구사항의 표현이 아니라 실패의 결과가 대화 밖에 도달하는지 확인하는 것임.
  • 다운스트림 코드가 분류 결과에 따라 분기함.
  • 삭제 작업이 프로덕션 환경에 영향을 줌.
  • 단계가 되돌릴 수 없는 작업을 커밋함.
  • 실패가 대화 밖으로 빠져나가 다른 곳에 영향을 미치면 보장이 필요함.
  • 실패 비용이 출력 자체가 나쁜 것으로 끝나면 정확도가 필요함.

명백한 지름길이 실패하는 이유

  • 요구사항에서 “절대로(never)”, “항상(always)”, “반드시(must)”를 찾는 방식은 유혹적이지만 작동하지 않음.
  • 자체 문제 은행에서 보장 관련 단어가 등장하는 문항은 코드 수준 답이 정답인 문항의 최대 절반에 불과함.
  • 나머지 문항은 보장 관련 단어 없이 요구사항을 서술함.
  • 반면 프롬프트 수준 답이 정답인 문항 중 최소 하나에는 인용된 시스템 프롬프트 문장 안에 “항상(always)”이 포함됨.
  • 이 단어는 시나리오에 포함된 지시문에 들어 있을 뿐이며, 바로 그 지시문이 평가 대상이라는 점이 함정임.
  • 형용사가 아니라 결과를 읽어야 함.

오답에서 알아볼 만한 세 가지 형태

  • 자체 문제 은행에서 이 문제군의 오답을 직접 분류하면 다음과 같은 형태가 나타남.
  • 보장 수단으로 제시된 프롬프트 문구
  • 가장 큰 차이로 흔한 유형임.
  • 제약을 명확하고 강하게 명시한 지시가 메커니즘이 있어야 할 위치에 놓임.
  • 잘못된 범위에 적용된 실제 메커니즘
  • 실제로 무언가를 강제하는 수단이지만 실패를 막는 범위를 벗어난 위치에 적용됨.
  • 피해가 발생한 뒤 실행되는 이벤트의 훅임.
  • 실제로 필요한 서브에이전트에서 도구를 제거함.
  • 두 번째 호출의 순서를 정할 수 없는 강제 도구 선택임.
  • 실제 메커니즘의 동작에 관한 잘못된 주장
  • 메커니즘 자체는 맞지만 설명된 동작이 아니라는 점에서 발견하기 더 어려운 유형임.
  • 재시도하는 훅, 실제로 존재하지 않는 위치에 구성된 훅, 원본 문서에서 누락 필드를 채워 넣는 엄격한 스키마 등이 해당함.
  • 보장을 대신하는 temperature 0 또는 모델 변경
  • 경험 많은 수험생도 걸리는 별도의 소규모 유형임.
  • 어느 것도 확률을 확실성으로 바꾸지 못함.
  • temperature 0은 일부 일관성 문제에서는 실제 정답이므로 다른 문항에서 효과적인 오답으로 작동함.

복습에 활용하는 방법

  • 이미 풀어 본 이 문제군의 문항을 다시 보면서 선택지를 확인하기 전에 실패의 결과가 어디에 도달하는지 적어야 함.
  • 대화 내부인지, 대화 외부인지 구분함.
  • 이 구분을 정확히 하면 정답 선택지가 대체로 분명해짐.
  • 구분하지 못하면 아무리 반복해서 검토해도 오답이 계속 그럴듯하게 보이게 됨.
  • 오류가 어느 방향으로 나타나는지도 확인해야 함.
  • 정확도 문제에서 인프라스트럭처를 선택하는 것과 보장 문제에서 문구를 선택하는 것은 서로 다른 실수이며, 교정 방법도 다름.
  • 전자는 “우리와 같은 조언”을 포함한 조언 때문에 과도하게 교정했음을 의미함.
  • 후자는 지시가 요청에 불과하다는 점을 아직 내면화하지 못했음을 의미함.
  • 이 문제군의 전체 해설이 포함된 사례는 무료 문제 게시물에 제시됨.

한 문장으로 정리하면

  • 지시는 모델이 어떤 행동을 할 가능성을 바꾸고, 훅·게이트·검증 단계는 시스템이 할 수 있는 행동을 바꿈.
  • 실패가 어디에 도달하는지 읽고 요구사항에 필요한 것이 무엇인지 결정하면 둘을 혼동한 선택지가 드러남.
  • 구조화된 출력 측면과 스키마가 더 이상 도움이 되지 않는 지점은 프롬프트 엔지니어링 및 구조화된 출력 가이드에서 다룸.
  • 이 문제들이 포함된 오케스트레이션 패턴과 더 넓은 영역은 에이전트 아키텍처 가이드에서 다룸.