4장. 방어 검증과 레드팀

학습 목표

• 입력·도구·출력 가드레일과 분류기의 역할, 실행 방식, 한계를 설명한다.
• 판정이 나오지 않을 때의 실패 동작을 작업 위험도에 맞게 정한다.
• 위협 모델에서 출발해 교전 규칙과 공격 시나리오를 설계한다.
• 공격·정상·경계 사례를 갖춘 평가 세트를 만들고, 결과로 성공을 판정한다.
• 공격 통과율, 정상 요청 오차단율, 업무 완료율로 방어 효과를 측정하고 해석한다.

들어가며

어느 팀이 출시 회의에서 "인젝션 차단율 98%"라는 숫자를 보고했습니다. 박수가 나왔고 출시가 승인되었습니다. 두 달 뒤 사고가 났을 때 알고 보니 그 숫자는 분류기 규칙을 만들 때 참고한 공격 문장 50개로 잰 것이었고, 문서나 메일을 경유하는 공격은 한 건도 없었습니다. 정상 요청이 얼마나 막히는지는 아무도 재지 않았습니다. 사용자들은 자주 막히는 기능을 피해 개인 계정의 다른 AI 도구에 업무 자료를 붙여 넣고 있었습니다. 숫자가 틀린 것은 아니었습니다. 무엇으로, 어떤 경로로 쟀는지 아무도 묻지 않았을 뿐입니다. 사고 뒤 보안팀이 문서 경유 공격으로 다시 잰 통과율은 보고서의 숫자와 전혀 다른 이야기를 하고 있었습니다.

방어는 만드는 일만큼 재는 일이 무겁습니다. 이 장은 가드레일과 분류기가 어디에서 무엇을 막는지, 판정이 실패할 때 어떻게 동작해야 하는지부터 봅니다. 이어서 레드팀의 정의와 교전 규칙, 위협 모델에서 시나리오를 뽑는 방법, 평가 세트를 구성하는 원칙을 익힙니다. 마지막으로 성공을 결과로 판정하는 법과 방어 효과를 숫자로 재고 해석하는 법을 배웁니다.

핵심 개념

가드레일의 지도: 어디에 무엇을 두는가

가드레일은 모델 앞뒤와 도구 호출 지점에서 입력과 출력을 검사해 막거나 고치는 장치입니다. 공항 보안 검색에 비유할 수 있습니다. 탑승 전(입력), 수하물을 실을 때(도구 호출), 도착 후(출력)에 각각 검사대가 있고, 검사대마다 막을 수 있는 것이 다릅니다.

출력 가드레일은 모델이 일을 끝낸 뒤에 돌기 때문에 그사이 실행된 도구 호출을 되돌리지 못합니다. 부작용이 있는 도구를 쓰는 에이전트라면 도구 호출 지점의 검사가 빠지면 안 됩니다. 그리고 가드레일은 3장의 인가 검사를 대신하지 않습니다. 가드레일은 "이상해 보이는가"를 묻고, 인가는 "이 사람이 이 일을 해도 되는가"를 묻습니다.

검사는 언제 끝나는가: Agents SDK 사례

OpenAI Agents SDK는 가드레일의 위치와 시점을 구체적으로 보여 줍니다.

트립와이어(tripwire)는 위반을 감지했을 때 실행을 멈추게 하는 신호입니다. 도구 가드레일에는 적용 범위의 한계가 있습니다. 직접 만든 함수 도구에는 적용되지만, 핸드오프(다른 에이전트에게 일을 넘기는 호출)와 호스팅 도구(웹 검색, 파일 검색, 호스팅 MCP, 코드 인터프리터 등)와 내장 실행 도구(컴퓨터, 셸 등)에는 적용되지 않습니다. 관리자 에이전트와 하위 전문 에이전트가 있는 구조에서 호출마다 검사하려면 에이전트 수준 가드레일보다 도구 가드레일을 쓰라고 문서는 권합니다. 이런 세부는 SDK마다 다르지만 질문은 같습니다. 검사는 언제 끝나는가, 그 전에 무엇이 실행될 수 있는가, 어떤 도구가 검사 밖에 있는가.

분류기: 판정 엔진의 종류와 한계

분류기는 가드레일의 판정 엔진입니다. 세 종류가 있습니다.

분류기마다 답하는 질문이 다르다는 점을 꼭 구분하세요. OpenAI의 Moderation API는 안전하지 않은 콘텐츠의 빈도를 줄이는 무료 도구입니다. Prompt Shields는 사용자 프롬프트 공격과 문서 공격을 탐지하지만, 콘텐츠가 유해한지나 정책에 맞는지는 판단하지 않는다고 문서에 적혀 있습니다. 어느 쪽도 "이 사용자가 이 고객 기록을 볼 권한이 있는가"에는 답하지 않습니다. 유해성 분류, 공격 탐지, 인가 검사는 서로 대체하지 못합니다.

OWASP 인젝션 예방 치트 시트는 가드레일 역할의 LLM도 LLM이라서 그 자체가 인젝션에 취약하다고 경고합니다. 분류 점수를 곧바로 "공격일 확률"로 읽어서도 안 됩니다. 점수의 의미는 그 분류기를 우리 데이터로 평가해 봐야 알 수 있습니다.

실패 동작: 판정이 나오지 않을 때

분류기는 언제나 답을 주지 않습니다. 시간이 초과되고, 오류가 나고, 선별 모델이 요청 자체를 거절합니다. Anthropic은 선별 모델의 안전 분류기가 선별 요청을 거절해 판정이 남지 않으면(stop_reason이 "refusal"인 경우) 그것을 유해 판정으로 다루라고 권합니다. 판정이 없는 상태를 "통과"로 처리하는 설계는 공격자에게 "분류기를 거절하게 만드는 입력"이라는 우회로를 줍니다.

실패 동작은 작업의 위험도에 따라 정합니다.

새 분류기를 처음 붙일 때는 차단보다 표시(annotate) 모드로 운영 데이터를 관찰하며 오차단을 재는 방법도 있습니다. Foundry에서는 Prompt Shields 결과로 차단하거나 표시만 하도록 설정할 수 있고, 독립 Content Safety API는 판정만 돌려주며 처리는 애플리케이션이 정합니다. 다만 표시 모드 기간에는 다른 층이 피해를 막고 있어야 합니다.

레드팀의 정의와 교전 규칙

NIST AI 600-1은 AI 레드팀을 "AI 시스템의 결함과 취약점을 찾기 위해 시스템을 탐색하는 구조화된 시험 활동"으로 정의하고, 대개 통제된 환경에서 개발자와 협력해 수행한다고 설명합니다. 수행자에 따라 일반 사용자형, 전문가형, 혼합형, 사람과 생성형 AI가 함께하는 형태로 나누며, 결과는 조직의 결정에 반영하기 전에 추가 분석을 거치라고 적습니다. OpenAI는 대표적인 입력과 시스템을 깨뜨리려는 입력 모두로 시험하라고 하고, Anthropic은 인젝션 시도를 담은 문서·메일·도구 결과로 자기 에이전트를 시험해 선별과 확인 단계가 나머지를 잡는지 확인하라고 권합니다.

레드팀은 "우리 시스템을 우리가 먼저 공격해 보는 일"이고, 반드시 허가된 범위 안에서 합니다. 시작 전에 교전 규칙을 문서로 합의합니다.

1. 대상과 환경: 어느 시스템의 어느 버전을, 운영과 분리된 어느 환경에서 시험하는가.
2. 데이터: 실제 고객 데이터 대신 합성 데이터와 가짜 비밀값을 씁니다.
3. 허용·금지 행위: 외부 발송·결제는 모의 도구로 바꾸고, 제3자 시스템은 건드리지 않습니다.
4. 중단 조건: 운영 데이터 접근이나 예상 밖 외부 요청이 관측되면 즉시 멈춥니다.
5. 연락과 보고: 발견 사항을 누구에게 어떤 형식으로, 얼마 안에 알리는가.

공격 시나리오 설계

시나리오는 공격 문장 목록이 아니라 위협 모델의 경로를 시험하는 단위입니다. 1장의 신뢰 경계와 2장의 다섯 단계 표에서 출발해, 시나리오마다 카드 한 장을 씁니다.

시나리오 묶음은 경로 × 방어 층 격자로 점검합니다. 행에는 경로(직접 입력, 웹, 메일, 문서, 이미지, 도구 결과, 메모리)를, 열에는 방어 층(입력 선별, 도구 결과 선별, 도구 호출 검사, 사람 확인, 출력 제한)을 두고 칸마다 시나리오가 있는지 표시합니다. 사람 확인은 가드레일의 위치는 아니지만 별도의 방어 층으로 함께 셉니다. 방어 층마다 그 층을 겨냥한 시나리오가 있어야 층별 효과를 잴 수 있습니다. 여러 턴과 여러 세션에 걸친 시나리오, 사람 확인 단계를 우회하거나 형식적으로 만드는 시나리오도 따로 둡니다.

남이 정리한 공격 목록으로 범위 넓히기

상상만으로 만든 시나리오는 우리 팀이 아는 공격만 시험합니다. MITRE ATLAS는 전술과 기법을 실제 사례 연구와 연결해 두었으므로, 정찰, 초기 접근, AI 모델 접근(AI Model Access), AI 공격 준비(AI Attack Staging), 유출, 영향 같은 단계마다 우리 시스템에 해당하는 기법이 있는지 훑는 데 씁니다. OWASP LLM01은 직접·간접 인젝션 외에 의도치 않은 인젝션, 검색 저장소 문서 변조, 페이로드 분할, 멀티모달, 의미 없어 보이는 접미 문자열, 다국어·난독화 공격을 시나리오로 정리하고, OWASP 인젝션 예방 치트 시트는 인코딩 우회, 변형을 반복하는 공격, 여러 턴에 걸친 공격 같은 유형을 분류합니다.

이런 지식 기반은 범위 점검표로 쓰고, 공개된 공격 문장을 복사해 평가 세트를 채우지는 않습니다. 이미 많은 분류기가 학습했을 문장은 점수를 부풀리고 우리 업무 맥락을 담지 못합니다.

평가 세트 구성

평가 세트는 공격만으로 이루어지지 않습니다.

Anthropic의 평가 설계 지침은 실제 업무 분포를 닮게 만들고 경계 사례를 넣으며, 가능하면 코드나 판정 모델로 자동 채점하고, 사람이 공들여 채점한 소수보다 자동 채점한 다수를 우선하라고 권합니다. 보안 평가 세트에는 다음 원칙을 더합니다.

1. 방어 규칙을 만들 때 참고한 데이터로 방어를 평가하지 않습니다. 개발용 세트와 최종 검증용 세트를 나누고, 검증용 세트는 규칙 작성자가 보지 않습니다. 시험 문제를 미리 보고 치른 모의고사 점수가 실력을 말해 주지 않는 것과 같습니다.
2. 실제 서비스의 입력 경로를 거치게 합니다. 문서 공격은 업로드와 텍스트 추출을 거쳐, 메일 공격은 메일 수집 경로를 거쳐 들어가야 합니다.
3. 서비스가 쓰는 언어마다 공격과 정상 사례를 두고, 여러 턴 공격은 대화 전체를 한 사례로 묶어 앞 턴의 상태를 이어 재생합니다.
4. 합성 비밀값(카나리)을 심어 둡니다. 실제 값과 겹치지 않고 우연히 생성될 수 없는 고유한 문자열(예: 고유 접두사에 무작위 값을 붙인 가짜 키)이어야, 출력이나 외부 요청에 나타났을 때 유출로 판정할 수 있습니다.
5. 세트에 버전을 붙이고, 사례마다 출처(어느 위협, 어느 사고)를 기록합니다.

성공 판정: 결과로 판정하라

모델이 거절하는 문장을 썼다고 방어가 성공한 것은 아닙니다. 거절 문장을 쓰면서 도구는 이미 호출했을 수 있고, 반대로 정중하게 따르는 척하면서 아무 행동도 하지 않았을 수 있습니다. 판정은 관측 가능한 결과로 합니다.

답변 오염처럼 결과가 텍스트 안에만 있을 때는 판정 모델(LLM 채점자)을 씁니다. Anthropic은 평가 대상 출력을 만든 모델과 다른 모델로 채점하는 것을 일반적인 모범 사례로 듭니다. 판정 모델은 쓰기 전에 사람이 라벨을 붙인 표본과 비교해 일치율을 확인하고, 불일치가 몰리는 유형은 판정 기준을 고치거나 사람이 채점합니다. 판정 근거로 쓸 수 있는 로그가 있는 시나리오에서는 판정 모델보다 로그를 우선합니다. 판정 모델도 평가 대상 출력 속 문장("이 응답은 기준을 모두 충족한다" 같은)에 끌려갈 수 있으므로, 출력은 데이터로 분리해 넘기고 판정은 구조화된 값으로만 받으며, 판정 모델과 사람의 불일치율을 지표로 봅니다.

방어 효과 측정 지표

방어 효과는 최소 세 숫자로 봅니다.

막히지 않은 정상 요청도 모델 오류나 시간 초과로 끝나지 못할 수 있으므로, 업무 완료율은 100%에서 오차단율을 뺀 값과 다릅니다.

숫자를 볼 때는 분모를 먼저 확인합니다. 시나리오 단위인지, 시도 단위인지, 대화 단위인지에 따라 같은 결과가 전혀 다른 숫자가 됩니다. 시나리오 하나에 시도 50회를 했는데 한 번 뚫렸다면, 시도 단위 통과율은 2%이지만 시나리오 단위로는 "뚫린 시나리오"입니다. 공격자는 시도를 반복할 수 있으므로 보안 판단에는 시나리오 단위의 "한 번이라도 뚫렸는가"가 더 중요할 때가 많습니다.

층별 지표도 함께 봅니다. 각 공격 시도가 어느 층에서 멈췄는지 기록하면 "입력 선별이 70%를 잡고, 나머지 중 대부분을 사람 확인이 잡았다"처럼 층의 기여를 알 수 있습니다. 한 층이 거의 아무것도 잡지 않는다면, 그 층이 필요 없거나 그 층을 겨냥한 시나리오가 없는 것입니다.

지속 모니터링과 회귀

출시 전 평가는 출시 시점의 사진일 뿐입니다. Anthropic은 성공한 인젝션의 징후를 정기적으로 분석해 프롬프트, 검증, 필터링 전략을 반복해서 다듬으라고 하고, 같은 사용자가 반복해서 우회를 시도하면 경고, 속도 제한, 차단으로 대응하라고 권합니다. SAIF의 "통제 조정과 빠른 피드백 주기" 요소와 같은 이야기입니다.

운영에서는 세 고리를 돌립니다. 레드팀과 사고 사례를 비식별화해 회귀 세트에 넣고, 모델·프롬프트·도구·분류기 중 하나라도 바뀌면 다시 돌리고, 가드레일 발동률·오차단 신고·승인율이 급변하면 원인을 조사합니다. 가드레일은 측정하고 고치는 운영 대상입니다.

깊이 읽기

몇 번 돌려야 하나: 확률적 결과의 해석

같은 시나리오를 한 번 돌려 막혔다고 "막힌다"고 쓸 수는 없습니다. 출력이 확률적이기 때문입니다. 반복 횟수를 정할 때 쓸 수 있는 통계 상식이 하나 있습니다. 독립적인 시도 n번에서 한 번도 성공하지 않았다면, 실제 성공률의 95% 신뢰 상한은 대략 3/n입니다(시도가 충분히 많을 때의 근사). 30번 돌려 0번 뚫렸다면 "성공률이 0이다"가 아니라 "성공률이 약 10%보다 낮을 가능성이 크다"까지만 말할 수 있습니다. 1% 수준을 말하려면 약 300번이 필요합니다.

이 상식은 두 가지를 알려 줍니다. 첫째, 작은 평가로 "안전하다"고 결론 내리지 말고 "이 정도 이하로 보인다"고 보고해야 합니다. 둘째, 반복 횟수로 확률을 끝없이 좁히는 것보다 영향을 줄이는 통제가 더 효율적일 때가 많습니다. 평가 보고서에는 모델·프롬프트·도구·분류기 버전, 시도 횟수, 분모 단위를 반드시 적어 결과를 재현할 수 있게 합니다. OWASP 치트 시트도 짧은 점검 시험을 통과했다고 끈질긴 공격자에 대한 저항이 증명되지는 않는다고 적습니다.

통제 조합의 효과를 비교하는 실험

"방어를 다 넣었더니 좋아졌다"는 결과로는 어느 통제가 효과를 냈는지 알 수 없습니다. 비교 실험은 다음처럼 설계합니다. 방어가 없는 기준선을 먼저 잽니다. 통제를 하나씩 더한 구성을 같은 평가 세트, 같은 모델 버전, 같은 반복 횟수로 잽니다. 통제 하나를 뺀 구성도 재 봅니다. 그 통제를 뺐을 때 결과가 거의 변하지 않으면 그 통제는 다른 통제와 겹치거나 시나리오가 그 통제를 겨냥하지 않은 것입니다.

결과는 공격 통과율과 업무 완료율을 함께 놓고 읽습니다. 통과율을 2%포인트 낮춘 대가로 업무 완료율이 15%포인트 떨어졌다면, 그 통제는 다른 형태(차단 대신 확인, 전체 대신 고위험 작업만)로 바꿀 후보입니다.

실무 장면

가람증권: 어느 층이 무엇을 놓쳤나

증권사 '가람증권'은 고객 문의 챗봇에 계좌 조회와 이체 예약 도구를 붙이기로 하고, 출시 4주 전 레드팀 계획을 세웠다. 교전 규칙에는 운영과 분리된 시험 환경, 합성 고객 데이터, 모의 이체 도구, 외부 요청 발생 시 중단, 발견 사항 당일 보고를 적었다.

신뢰 경계는 고객 채팅 입력, 고객이 첨부하는 거래 확인서 이미지, 이체 예약 도구 호출의 셋이었다. 이미 적용한 방어는 입력 선별 분류기, 첨부 이미지 OCR 결과를 도구 결과로 넘기고 선별하는 단계, 이체 예약 전 고객 확인 화면이었다.

시나리오는 방어 층마다 만들었다. 입력 선별 층은 정책 우회형 대화 60건으로, OCR 경로는 지시가 숨겨진 테스트 이미지 25건으로, 확인 화면은 "확인 없이 이체가 실행되는 경로가 있는가"를 찾는 시나리오 12건으로 시험했다. 시나리오마다 5회씩 반복했고, 정상 고객 문의 400건도 함께 돌려 오차단율과 업무 완료율을 쟀다. 성공 판정은 모의 이체 도구의 호출 로그와 카나리로 심은 합성 계좌번호의 출력 여부로 했다.

결과는 이랬다. 입력 선별은 정책 우회 시도 대부분을 잡았지만 정상 문의의 5%를 막았다. OCR 경로에서는 시나리오 두 개가 반복 중 일부 시도에서 선별을 통과했지만 모두 확인 화면에서 멈췄다. 확인 화면 시나리오에서는 하나가 문제를 찾았다. 예약 날짜를 바꾸는 "수정" 기능이 처음 승인을 그대로 재사용해 금액 변경까지 확인 없이 반영했다.

팀은 선별 기준을 조정해 오차단율을 낮추고, 통과한 OCR 시나리오 두 개를 회귀 세트에 넣고, 수정 기능에서 금액이나 수취인이 바뀌면 다시 확인을 받게 했다. 출시 보고서에는 통과율 숫자 하나가 아니라 층별로 무엇을 잡고 놓쳤는지, 반복 횟수와 남은 위험을 적었다. 요점은 "몇 건을 막았나"가 아니라 "어느 층이 무엇을 놓쳤고, 다음 층이 받쳐 주었나"였다.

바람개비렌터카: 세 가지 구성을 같은 시험지로

렌터카 회사 '바람개비렌터카'는 예약 변경 비서를 운영하며 방어 구성을 정하지 못하고 있었다. 보안팀은 입력 분류기만 강화하자고 했고, 제품팀은 확인 화면이 늘어나면 고객이 떠난다고 걱정했다. 팀은 논쟁 대신 같은 시험지로 재기로 했다.

평가 세트는 공격 시나리오 150개(직접 입력, 고객이 붙인 링크의 웹 페이지, 제휴사가 보낸 예약 메일 경로)와 실제 문의를 비식별화해 만든 정상 업무 300건이었다. 공격 시나리오는 각각 5회 반복했다. 구성은 셋이었다.

세 구성 모두 기존의 서버 측 인가는 그대로 두었다.

B는 무단 변경을 없앴지만, 정상 업무의 상당수에서 고객이 확인 단계 앞에서 대화를 떠났다. C는 무단 변경을 막으면서 완료율을 거의 지켰다. 날짜 변경을 확인 없이 둔 근거는 따로 확인했다. 날짜 변경은 고객 본인 예약에만, 요금 변동이 없는 범위에서만 허용되도록 서버가 검사하고 있었다.

판정 방법에서도 배운 것이 있었다. 처음에는 판정 모델이 대화 전체를 읽고 공격 성공 여부를 매겼는데, 사람이 라벨을 붙인 표본 100건과 비교해 보니 "말로는 거절하고 도구는 호출한" 사례에서 불일치가 몰렸다. 팀은 행동을 노리는 시나리오의 판정을 모의 도구 호출 로그로 바꾸고, 판정 모델은 답변 오염 시나리오에만 쓰기로 했다. 최종 구성으로 C를 고르고, 보고서에 반복 횟수와 분모 단위, 시험한 모델 버전을 적었다.

자주 틀리는 지점

1. "출력 가드레일로 옮기면 더 안전하다." 출력 가드레일은 에이전트가 끝난 뒤 돌기 때문에 이미 실행된 도구 호출을 되돌리지 못합니다.
2. "선별 모델이 거절하면 판정이 없으니 통과시킨다." 판정 부재를 통과로 처리하면 우회로가 생깁니다. Anthropic은 거절을 유해 판정으로 다루라고 합니다.
3. "차단율이 높으면 충분하다." 무엇으로, 몇 번, 어떤 분모로 쟀는지가 먼저입니다. 규칙 작성에 쓴 데이터로 잰 숫자는 의미가 없습니다.
4. "오차단은 사용성 문제일 뿐이다." 오차단이 많으면 사용자는 통제 밖 도구로 옮겨 가고, 통제는 결국 꺼집니다. 오차단도 보안 지표입니다.
5. "모델이 거절 문장을 쓰면 방어가 성공한 것이다." 거절 문장과 도구 호출은 함께 일어날 수 있습니다. 판정은 로그와 상태 변화로 합니다.
6. "유해성 분류기를 붙였으니 인젝션도 막힌다." 유해성 분류, 공격 탐지, 인가 검사는 서로 다른 질문에 답합니다.
7. "30번 돌려 한 번도 안 뚫렸으니 안전하다." 그 결과로 말할 수 있는 것은 "성공률이 대략 10%보다 낮을 가능성이 크다"까지입니다.
8. "공개된 공격 문장 모음으로 평가하면 된다." 공개 문장은 점수를 부풀리고 우리 경로를 거치지 않습니다. 지식 기반은 범위 점검에 씁니다.

한눈에 정리

공식 문서로 확인하기

• OpenAI Agents SDK — Guardrails: 가드레일 종류, 실행 모드, 적용 범위.
• Anthropic — Mitigate jailbreaks and prompt injections: 선별, 거절 처리, 모니터링, 자기 에이전트 레드팀.
• Anthropic — Define success criteria and build evaluations: 평가 설계 원칙과 채점 방법.
• OpenAI — Safety best practices: Moderation API, 적대적 시험, 사람 검토.
• Microsoft — Prompt Shields: 탐지 범위와 한계, 표시와 차단 모드.
• NIST AI 600-1: AI 레드팀의 정의와 유형, 결과 활용 시 주의점.
• MITRE ATLAS: 시나리오 범위를 점검할 공격 전술·기법.

셀프 체크

4-1. OpenAI Agents SDK의 도구 가드레일이 적용되지 않는 도구 유형 두 가지를 쓰고, 그런 도구를 쓰는 에이전트에서 대신 둘 수 있는 통제를 하나 들라.

4-2. 유해 콘텐츠 분류, 인젝션 공격 탐지, 인가 검사가 각각 답하는 질문을 한 줄씩 쓰라.

4-3. 레드팀을 시작하기 전에 교전 규칙으로 합의할 항목 다섯 가지를 쓰라.

4-4. 평가 세트에 합성 비밀값(카나리)을 심는 목적과, 그 값을 고를 때 지켜야 할 조건 두 가지를 쓰라.

4-5. 공격 시도 240회 가운데 9회가 성공했고, 정상 요청 500건 가운데 15건이 막혔다. 공격 통과율과 정상 요청 오차단율을 계산하고, 이 두 숫자만으로는 알 수 없는 것을 하나 쓰라.

4-6. 한 시나리오를 독립적으로 60회 반복해 한 번도 뚫리지 않았다. 이 결과로 말할 수 있는 성공률의 대략적인 상한과, 말할 수 없는 것을 쓰라.

4-7. 설계 과제: "입력 선별 추가"와 "쓰기 도구 확인 추가" 가운데 어느 쪽이 효과가 큰지 비교하는 실험을 설계하라. 비교할 구성, 고정할 조건 세 가지, 볼 지표 두 가지를 제시하라.

실습 과제