OPEN
WEEK 04 · AI LEARNING

Vibe Coding을 넘어
UX를 검증 가능한 시스템으로

Prompt Engineering · Context Engineering · Harness Engineering · Loop Engineering · Graph Engineering

PCHLG

배송지 변경 사례로 사용자 문제 → Flow → 상태 → 검증 → 개발 전달을 연결하는 60분

WHY ENGINEERING?

“화면 만들어줘”가 실패하면
어느 UX 설계 층을 고쳐야 할까?

배송지 변경
“편하게”
→
과업 누락사용자·상황·성공이 불명확
근거 누락문의·퍼널·정책 미연결
상태 누락로딩·오류·복구 미정의
감각적 수정검증·종료 기준 부재
전달 충돌Flow·상태·API 불일치

화면 한 장의 문제가 아니다. 사용자 과업 전체를 검증 가능한 UX 시스템으로 설계해야 한다.

SIX RESPONSIBILITIES × FIVE ENGINEERING STAGES

다섯 엔지니어링 단계는
사람의 여섯 운영 역할을 구현한다

PROMPT
ENGINEERING
① 사용자 과업 계약사용자·상황·과업·비목표·성공을 정의한다.어떤 문제를 맡길까?
→
CONTEXT
ENGINEERING
② 근거 선택
③ 근거 갱신문의·퍼널·정책·현재 Flow를 연결한다.무엇을 믿고 판단할까?
→
HARNESS
ENGINEERING
④ UX 검증 환경화면·상태·예외·인터랙션 누락을 검사한다.무엇을 실행해 확인할까?
→
LOOP
ENGINEERING
⑤ 근거 기반 개선관찰·수정·재검증·중단 조건을 정한다.무엇을 바꾸고 멈출까?
→
GRAPH
ENGINEERING
⑥ 개발 전달 운영선후·병렬·합류·반려·승인 규칙을 정한다.어떻게 만들고 전달할까?

FROM UX TASK TO DELIVERY · A SPATIAL METAPHOR

과업에서 전달 시스템으로
UX 설계 범위가 확장된다

Prompt배송지 변경이라는
사용자 과업을 고정한다산출물 · UX Task
→
Context사용자 근거와 정책을
Flow 노드에 연결한다산출물 · Flow v1
→
Harness화면·상태·행동을
프로토타입으로 검사한다산출물 · State Spec
→
Loop관찰·수정·재검증으로
경험을 수렴시킨다산출물 · Tested Prototype
→
GraphFlow·상태·구현의
의존·합류·승인을 설계한다산출물 · Dev Handoff
강의용 누적 비유과업 → 근거 → 상태 → 검증 → 전달엄격한 기술 계층이나 성숙도 순위가 아니라, 한 UX 사례에서 책임 범위가 넓어지는 흐름이다.
01

Prompt Engineering

AI에게 어떤 사용자 문제를 맡길까?

Prompt Engineering은 화면을 주문하는 일이 아니라 사용자·상황·과업·범위·성공 기준을 UX 작업 계약으로 정하는 일이다.

1요청2근거3검증4개선5전달

ONE UX CASE · CHANGE DELIVERY ADDRESS

모호한 화면 요청을
사용자 과업으로 바꾼다

BEFORE · 화면 주문
“배송지 변경 화면을
편하게 만들어줘.”
누가·언제·무엇을 성공해야 하는지 알 수 없다.
→
AFTER · UX 작업 계약

이사 후 첫 주문 고객이 결제 중 이전 주소를 발견했을 때, 장바구니를 잃지 않고 새 주소를 등록하고 배송 가능 여부를 확인한 뒤 결제로 돌아가는 모바일 흐름을 설계한다.

1요청2근거3검증4개선5전달

A UX TASK IS A SMALL CONTRACT

좋은 Prompt는 다섯 질문에
한 번에 답한다

사용자 이사 후 처음 주문하는 고객
상황 결제 직전 이전 배송지를 발견
과업 새 주소 등록 후 결제로 복귀
비목표 결제수단·쿠폰 흐름은 변경하지 않음
성공 입력 유지·배송 가능 확인·새 주소 반영
  1. 1누구의 문제인가?
  2. 2어떤 상황인가?
  3. 3무엇을 완료해야 하나?
  4. 4무엇은 바꾸지 않나?
  5. 5무엇을 보면 성공인가?
1요청2근거3검증4개선5전달

LAYER CHECK · PROMPT

화면을 만들기 전에
과업이 정의됐는가?

사용자·상황·과업·성공을 한 문장으로 말할 수 있는가?
YESFlow v0를 그린다정상 흐름과 확인이 필요한 가정을 표시한다.
NO문제 정의를 보강한다화면부터 만들지 말고 누락된 결정을 확인한다.

다음 판단과업은 정했지만 사용자가 실제 어디서 막히는지는 아직 모른다. 이제 근거를 연결한다.

1요청2근거3검증4개선5전달
02

Context Engineering

어떤 사용자·제품 근거로 판단할까?

Context Engineering은 근거 없는 UX 판단을 줄이도록 사용자 증거·기존 흐름·정책·디자인 시스템을 골라 최신 상태로 연결하는 일이다.

1요청2근거3검증4개선5전달

RELEVANCE OVER VOLUME

자료가 많다고
사용자를 더 잘 이해하는 것은 아니다

선택
현재 UX 결정에 직접 필요한 근거관련성 · 신뢰성 · 최신성으로 고른다.
과거 시안·무관한 조사까지 모두 투입→ 충돌 · 핵심 근거 희석 →문의·퍼널·정책·현재 흐름만 연결

핵심Context의 목표는 최소 길이가 아니라 필요한 근거를 적절한 시점에 제공하는 것이다.

1요청2근거3검증4개선5전달

SHOW USER EVIDENCE

“쉽게”라는 설명보다
사용자가 멈춘 지점을 보여 준다

설명만 제공“사용자는 주소 변경을 어려워해요.”원인과 위치를 알 수 없다
→
권위·버전이 확인된 근거문의 유형 · 결제 퍼널 · 현재 Flow · 배송 정책 · Address Card 규격어떤 결정에 쓰였는지 추적한다

디자이너 번역형용사 대신 사용자가 멈춘 단계·반복한 행동·충돌한 정책을 연결한다.

1요청2근거3검증4개선5전달

DEFERRED LOADING

모든 자료를 먼저 읽히지 말고
필요한 결정에서 불러온다

1 · INDEX근거 지도를 본다리서치·분석·정책·디자인 시스템의 위치와 버전을 확인한다.
→
2 · SELECTFlow 노드와 연결한다현재 결정에 영향을 주는 근거와 제외할 자료를 고른다.
→
3 · LOAD그때 상세를 읽는다주소 입력은 검증 정책을, 오류 상태는 실패 로그를 읽는다.

조건파일·Figma·문서를 실제로 조회할 도구와 권한이 있어야 자동으로 불러올 수 있다.

1요청2근거3검증4개선5전달

ONE UX CASE · EVIDENCE PACK

배송지 변경 Flow에는
이 근거부터 연결한다

address-change/✓ research/key-findings.md✓ analytics/checkout-funnel.csv✓ policy/delivery-serviceability.md✓ flows/current-checkout.fig✓ design-system/address-form.md× archive/old-flow/× unrelated-home-study/
각 자료에 남길 정보
결정
어느 Flow 노드에 쓰는가?
권위
누가 승인한 자료인가?
버전
경로·revision·날짜는 무엇인가?
갱신
무엇이 바뀌면 다시 읽는가?
1요청2근거3검증4개선5전달

KNOWING IS NOT ENFORCING

정책을 읽는 것과
상태를 검증하는 것은 다르다

CONTEXT · 근거를 안다“주소 검증 응답은 최대 3초 걸릴 수 있다.”정책과 제약을 판단 근거로 연결한다.
≠
HARNESS · 실행해 확인한다검증 중 중복 제출 → FAIL로딩·입력 보존·실패 복구가 실제로 동작하는지 검사한다.

다음 질문핵심 과업의 화면·상태·인터랙션 누락을 어떻게 발견할까?

1요청2근거3검증4개선5전달
03

Harness Engineering

흐름의 누락과 위험한 상태를 어떻게 막을까?

Harness Engineering은 도구·권한·검사 환경을 연결해 핵심 과업의 화면·상태·인터랙션·예외 경로가 실제로 동작하는지 확인하는 일이다.

1요청2근거3검증4개선5전달

PROMISE → VERIFIABLE EXPERIENCE

좋은 의도를 부탁하지 말고
실패 상태를 실행해 본다

배송지 변경
검증 중 저장 가능
실패 시 입력 소실
FAIL · 테스트 보류중복 제출 가능
오류 후 입력 소실 · 복귀 불명확
→ 상태 검사 →
배송지 변경
배송 가능 확인
입력 유지·복구 가능
PASS · 사용자 검증 허용로딩 중 CTA 비활성
새 주소 반영 · 결제로 복귀
1요청2근거3검증4개선5전달

A MINIMUM UX HARNESS

UX Harness는
네 종류의 증거를 확인한다

1Flow정상·배송 불가·네트워크 실패·뒤로 가기가 연결됐는가?
→
2State기본·입력·오류·검증 중·성공·비활성이 정의됐는가?
→
3InteractionCTA 조건·포커스·입력 보존·복구가 동작하는가?
→
4Prototype핵심 경로를 실제로 누르고 시작점으로 돌아갈 수 있는가?

남기는 증거Flow map · State table · Interaction notes · Prototype link · 자동/사람 검사 결과

1요청2근거3검증4개선5전달

LAYER CHECK · HARNESS

무엇을 자동·반자동·사람 검토로
확인해야 할까?

누락되면 과업이 실패하거나 검증 결과가 왜곡되는가?
YES검사와 Gate를 붙인다기계 판정은 자동화하고 의미·위계·사용성은 사람이 승인한다.
NO탐색 결과로 둔다일회성 시안은 기록하되 강제 장치 구축 비용을 구분한다.

다음 판단Harness는 검사를 실행하고 실패를 보인다. 그 결과로 무엇을 바꿀지는 Loop가 정한다.

1요청2근거3검증4개선5전달
04

Loop Engineering

사용자가 막히면 무엇을 바꾸고 언제 멈출까?

Loop Engineering은 프로토타입 제작·과업 관찰·문제 우선순위화·수정·재검증을 상태와 종료 기준 안에서 반복하는 일이다.

1요청2근거3검증4개선5전달

THE FOUR ESSENTIALS

좋은 UX Loop는
네 질문으로 시작한다

1 · TRIGGER언제 시작?핵심 Flow와 상태 검사가 통과했을 때
→
2 · GOAL어디까지?교육 예시: 5명 중 4명 이상 도움 없이 완료
→
3 · CHECK무엇을 관찰?과업 성공·시간·오류·SEQ·행동 메모
→
4 · STOP언제 멈춤?목표·2라운드·정책 충돌·범위 초과
1요청2근거3검증4개선5전달

SEPARATE MAKING FROM CHECKING

만드는 쪽과 판정 기준을
분리한다

MAKER · 설계 수정근거가 가장 큰 문제 하나를 수정Flow·화면 구조·상태·피드백 중 관찰 결과와 직접 연결된 항목을 바꾼다.
→ 같은 과업 →
CHECKER · 사용자 행동동일한 시나리오로 다시 관찰AI나 디자이너의 자기평가가 아니라 관찰 가능한 행동과 미리 정한 기준이 판정한다.

중요검사자가 반드시 다른 AI일 필요는 없지만, 만든 사람의 느낌과 독립된 판정 기준은 필요하다.

1요청2근거3검증4개선5전달

UX CASE · USABILITY ITERATION

“적용됐는지 모르겠어요”를
과업 성공으로 바꾼다

1차 관찰3/5도움 없이 완료
① 결제 복귀 실패를 확인→② CTA·복귀·반영 피드백 수정→③ 같은 시나리오로 재관찰불합격이면 관찰 근거와 함께 ②로 돌아간다 ↩
교육용 목표4/5+치명 오류 0
성공 · 4/5+ · 치명 오류 0 · SEQ 5/7+재시도 · 목표 미달 + 2라운드 미만중단 · 2라운드 도달 또는 정책 충돌→ 시도·근거·미해결 위험 이관
1요청2근거3검증4개선5전달

LAYER CHECK · LOOP

같은 사용자 과업으로
다시 관찰할 수 있는가?

실패 신호가 다음 설계 행동을 바꾸고 종료 조건이 있는가?
YESLoop를 실행한다변경·관찰 결과·다음 행동·중단 이유를 라운드마다 기록한다.
NO문제 정의로 돌아간다취향 평가를 반복하지 말고 시나리오와 성공 기준을 먼저 정한다.

다음 판단Loop는 한 노드 안에서 수렴한다. 여러 산출물의 선후·합류·전달은 Graph가 맡는다.

1요청2근거3검증4개선5전달
05

Graph Engineering

UX 결과물을 어떤 순서로 만들고 전달할까?

Graph Engineering은 조직도가 아니라 무엇을 먼저 하고, 무엇을 동시에 하며, 어디서 합쳐 누가 승인할지를 작업 관계로 설계하는 일이다.

1요청2근거3검증4개선5전달

ONE UX CASE · FIRST / PARALLEL / JOIN

세 질문으로 보면
Graph가 쉬워진다

1 · 먼저사용자 문제·근거
Flow 승인정상·예외 경로
2 · 동시에화면 구조 설계
2 · 동시에상태·정책·API 확인
3 · 합류통합 프로토타입·검증
UX 승인개발 전달·PR·QA
검증 실패 → 근거와 함께 해당 Flow·화면·상태 노드로 반려
1요청2근거3검증4개선5전달

GRAPH ≠ MANY AGENTS

Graph의 핵심은 사람·AI 수가 아니라
설계 결정의 의존 관계다

먼저Flow가 승인되기 전에 상세 화면과 구현을 확정하지 않는다.

동시에서로의 결과를 기다리지 않고 수정 범위가 충돌하지 않는 일만 병렬화한다.

합류·승인같은 revision의 Flow·상태·검증 증거가 모이면 UX 책임자가 개발 전달을 승인한다.

노드 계약Owner · Input · Output · Write scope · Success · Handoff · Veto · Stale rule을 기록한다.

1요청2근거3검증4개선5전달

LAYER CHECK · GRAPH

이 작업은 정말
나눠서 연결해야 할까?

먼저·동시·합류 조건과 승인자를 모두 말할 수 있는가?
YESGraph로 연결한다artifact·revision·담당·반려 조건을 정해 개발 전달까지 잇는다.
NO한 흐름으로 유지한다작고 서로 얽힌 일은 한 작업이나 한 Loop가 더 안전하다.

다음 판단Graph는 실패를 어디로 돌려보낼지 연결한다. 재시도 횟수와 다음 수정 선택은 각 노드의 Loop가 정한다.

1요청2근거3검증4개선5전달

THE WHOLE STORY · ONE UX CASE

다섯 단계는 경쟁하지 않고
하나의 UX 결과에 함께 남는다

PROMPT사용자·상황·배송지 변경 과업·성공 기준을 계약한다.

CONTEXT문의·퍼널·배송 정책·현재 Flow·디자인 시스템을 연결한다.

HARNESS화면·상태·예외·인터랙션을 실행 가능한 프로토타입으로 검증한다.

LOOP같은 과업으로 관찰·수정·재검증하고 목표나 한도에서 멈춘다.

GRAPH먼저·동시·합류 조건을 정해 검증 근거와 함께 개발에 전달한다.

FINAL WORKSHOP · 8 MIN

내 UX 과업을 다섯 질문으로
설계하고 바로 실행한다

  1. 1 · 요청누가 어떤 상황에서 어떤 과업을 완료해야 할까?
  2. 2 · 근거어떤 사용자 증거·정책·기존 패턴을 믿을까?
  3. 3 · 검증어떤 화면·상태·예외·행동을 실행해 확인할까?
  4. 4 · 개선어떤 과업과 지표로 재검증하고 언제 멈출까?
  5. 5 · 전달무엇을 먼저·동시에 하고, 무엇이 모이면 누가 승인할까?
완료 예시

요청 이사 후 고객의 주소 변경 후 결제 복귀
근거 문의·퍼널·배송 정책
검증 정상·배송 불가·네트워크 실패
개선 4/5명 이상 또는 최대 2라운드
전달 UX 승인 후 Flow·상태·수용 기준을 개발팀에 전달

FINAL CHECK · NAME THE LAYER

UX 실패의 원인을 보면
먼저 점검할 층이 보인다

화면은 있는데 사용자 과업과 성공이 없다PROMPT

왜 막히는지 사용자·정책 근거가 없다CONTEXT

로딩·오류·복구 상태가 프로토타입에 없다HARNESS

디자이너의 느낌으로 같은 수정을 반복한다LOOP

Flow·상태·API의 최신 결정이 서로 다르다GRAPH

더 긴 프롬프트보다 문제가 생긴 UX 설계 층과 인접 층을 함께 점검한다.

WEEK 04 → WEEK 05

이번 주는 실행을 설계했고
다음 주는 지식을 축적한다

이번 주에 배운 것Prompt · 무엇을 완성할지Context · 어떤 자료를 언제 보여 줄지Harness · 무엇을 확인하고 막을지Loop · 실패 뒤 무엇을 하고 언제 멈출지Graph · 일을 어떻게 나누고 승인할지
→
NEXT · WEEK 05

Obsidian × LLM-WIKI

이번 주의 Context Pack을 대화가 끝나도 사라지지 않는 팀 지식으로 만든다.

사람이 함께 쓰고
AI가 다시 읽는
팀 지식 위키 구축