# “무엇을 만들까”보다 “무엇이 달라져야 하나”

> Outcome, evidence, invariant, non-goal과 acceptance

- Canonical: https://learning.reopt.ai/courses/ai-problem-context/lessons/pc-m1-concept
- Language: ko-KR
- HTML: https://learning.reopt.ai/courses/ai-problem-context/lessons/pc-m1-concept

---

[AI 문제 정의와 컨텍스트 설계](/courses/ai-problem-context) 1. 요청을 문제 계약으로 바꾸기 1 / 9

# “무엇을 만들까”보다 “무엇이 달라져야 하나”

Outcome, evidence, invariant, non-goal과 acceptance
개념 학습 45 XP 9분

AI는 빈칸을 빠르게 채우기 때문에 모호한 요청도 그럴듯한 구현으로 바꿉니다. 문제는 코드가 아니라 잘못 채운 가정입니다. 사용자의 관찰 가능한 변화, 현재 증거, 깨지면 안 되는 불변식, 이번에 하지 않을 범위, 완료를 판정할 증거를 먼저 작성해야 합니다.
Acceptance는 구현과 독립적으로 특정 컴포넌트나 라이브러리 이름이 아니라 입력·출력·상태 전이·실패 응답·성능·접근성처럼 외부에서 확인 가능한 조건을 씁니다. 그래야 여러 구현안을 같은 기준으로 비교할 수 있습니다.

| 계약 요소 | 질문 | 나쁜 대체물 |
| Outcome | 누구의 어떤 행동·결과가 달라지는가? | 기능 목록 |
| Evidence | 현재 문제가 실제라는 증거는? | 추측·관례 |
| Invariant | 어떤 상태·권한·데이터는 보존해야 하나? | 암묵적 기대 |
| Acceptance | 어떤 관측으로 완료를 판정하나? | “잘 작동함” |

- 1 사용자 장면 행위자·상황·현재 마찰·원하는 결과를 한 문단으로 씁니다.

- 2 증거 연결 로그·사용 데이터·재현·정책 중 문제를 뒷받침하는 근거를 붙입니다.

- 3 경계 고정 불변식·비대상·권한·시간·호환성 제약을 분리합니다.

- 4 판정 설계 테스트·화면·지표·운영 증거로 acceptance를 만듭니다.

실무에 남길 기준

- 기능 이름은 solution이고 문제 계약은 사용자 결과와 제약을 설명한다
- 불변식과 비대상은 AI가 합리적으로 보이는 범위 확장을 막는다
- 좋은 acceptance는 서로 다른 구현을 같은 기준으로 반증할 수 있다

이해했어요 · 계속

---

에이전트용 사이트 안내: https://learning.reopt.ai/llms.txt · 사이트맵: https://learning.reopt.ai/sitemap.xml · 문의: https://learning.reopt.ai/contact