AI 수락 기준 계약 루프

AI에게 기능을 맡길 때 가장 위험한 순간은 구현을 시작하기 전입니다. 요구사항이 “대충 이런 느낌”으로 남아 있으면 AI는 빠르게 코드를 만들지만, 완료 기준은 사람마다 다르게 해석됩니다. 그래서 VIBE 코딩에서는 작업을 시작하기 전에 수락 기준을 계약처럼 고정하는 루프가 필요합니다.

수락 기준 계약 루프는 거창한 문서가 아닙니다. 사용자가 무엇을 할 수 있어야 하는지, 어떤 상태가 성공인지, 무엇이 실패인지, 어떤 검증으로 끝났다고 볼지 한 장으로 정리하는 방식입니다. 이 계약이 있으면 AI 에이전트는 구현 중에 방향을 잃지 않고, 사람은 결과를 감으로 판단하지 않아도 됩니다.

핵심 결론

AI 코딩의 품질은 프롬프트의 화려함보다 완료 기준의 선명함에 더 크게 좌우됩니다. “로그인 화면을 개선해줘”보다 “비밀번호 오류와 네트워크 오류를 다른 문구로 보여주고, 성공 시 이전 페이지로 돌아가며, 모바일 360px에서도 버튼이 접히지 않아야 한다”가 훨씬 안전합니다.

수락 기준은 AI가 지켜야 할 작은 계약입니다. 구현 요청, 검증 방법, 실패 시 되돌릴 조건을 같은 문장 안에 묶으면 결과물의 모호성이 줄어듭니다. 특히 여러 번의 AI 작업이 이어지는 팀에서는 이 계약이 없을 때 같은 기능을 매번 다르게 고치게 됩니다.

좋은 수락 기준은 다음 세 가지를 동시에 답합니다.

왜 중요한가

AI는 빠르게 추론하지만 현장의 암묵지를 자동으로 알지는 못합니다. 결제 버튼은 단순한 버튼이 아니라 재시도 정책, 중복 클릭 방지, 영수증 안내, 실패 메시지, 고객센터 연결까지 포함할 수 있습니다. 사람이 머릿속에만 들고 있는 기준을 AI에게 주지 않으면 구현은 맞아 보여도 운영에서는 빈틈이 생깁니다.

수락 기준 계약은 범위를 줄이는 효과도 있습니다. AI에게 “전체를 개선하라”고 하면 관련 없는 파일과 동작까지 만질 수 있습니다. 반대로 “이 루프에서는 목록 필터의 빈 상태 문구와 정렬 표시만 바꾼다. 데이터 저장 방식과 권한 로직은 건드리지 않는다”라고 쓰면 변경 폭이 작아지고 리뷰가 쉬워집니다.

또 하나의 장점은 검증 비용 절감입니다. 기준이 없으면 리뷰어는 결과물을 보며 요구사항을 다시 만들어야 합니다. 기준이 있으면 리뷰어는 체크박스처럼 확인할 수 있습니다. VIBE 코딩에서는 사람이 모든 코드를 깊게 읽기보다, 위험한 경계와 사용자 결과를 빠르게 확인하는 능력이 중요합니다.

실제 작업 순서

1단계: 사용자 행동을 한 문장으로 잠근다

먼저 기능을 기술 용어가 아니라 사용자 행동으로 씁니다. “검색 상태 관리 개선”보다 “사용자가 검색어를 입력하고 엔터를 누르면 목록이 검색어 기준으로 갱신되고, 검색어가 비어 있으면 전체 목록으로 돌아간다”가 좋습니다. 이 문장은 AI가 구현 중 판단을 잃을 때 기준점이 됩니다.

이 단계에서 역할도 함께 지정합니다. 신규 방문자, 로그인 사용자, 관리자, 모바일 사용자처럼 주체가 달라지면 성공 조건도 달라집니다. 주체가 빠진 요구사항은 대부분 중간에 다시 질문을 만들거나 엉뚱한 기본값을 선택하게 됩니다.

2단계: 성공 조건을 관찰 가능한 문장으로 바꾼다

성공 조건은 눈으로 확인하거나 테스트로 검증할 수 있어야 합니다. “빠르게 동작한다”는 애매합니다. “초기 목록 20개 기준으로 첫 화면이 깨지지 않고, 로딩 중에는 버튼이 중복 제출되지 않는다”처럼 관찰 가능한 조건으로 바꿉니다.

실무에서는 보통 3개에서 7개 정도가 적당합니다. 너무 적으면 품질을 못 잡고, 너무 많으면 한 작업이 커집니다. 기준이 10개를 넘으면 작업을 두 개로 나누는 편이 안전합니다.

3단계: 비목표를 명시한다

AI 작업에서 비목표는 수락 기준만큼 중요합니다. 이번 변경에서 하지 않을 일을 적어두면 불필요한 리팩터링과 디자인 변경을 막을 수 있습니다. 예를 들어 “이번 작업에서는 인증 흐름, 데이터 모델, 결제 금액 계산을 변경하지 않는다”처럼 씁니다.

비목표는 팀 리뷰에도 도움됩니다. 리뷰어가 “왜 이 부분은 그대로 두었나”라고 묻기 전에 작업 범위가 이미 합의되어 있기 때문입니다. 작은 루프를 유지하려면 비목표가 반드시 있어야 합니다.

4단계: 검증 명령과 수동 확인을 분리한다

자동 검증과 수동 확인은 서로 대체재가 아닙니다. 자동 검증은 회귀를 잡고, 수동 확인은 사용자가 실제로 보는 흐름을 확인합니다. AI에게는 “관련 테스트를 통과시킨 뒤, 화면에서 빈 상태와 오류 상태를 직접 확인한다”처럼 두 축을 모두 요구해야 합니다.

검증 명령을 쓸 때는 작업에 필요한 최소 범위부터 시작합니다. 작은 글 수정에는 스키마 검증이 충분할 수 있고, UI 변경에는 해당 컴포넌트 테스트와 브라우저 확인이 필요할 수 있습니다. 무조건 모든 검증을 돌리는 것보다 변경 종류에 맞는 검증을 정하는 것이 운영적으로 더 좋습니다.

5단계: 보류 조건을 만든다

AI가 작업 중 코드 변경이 필요 없는 줄 알았는데 렌더러 수정을 요구하는 문제가 발견될 수 있습니다. 이때 계속 밀어붙이면 작업 범위가 커집니다. “스키마 변경, 인증 변경, 공통 컴포넌트 변경이 필요하면 구현을 멈추고 보고한다”처럼 보류 조건을 둡니다.

보류 조건은 실패를 의미하지 않습니다. 오히려 좋은 자동화는 멈춰야 할 때 멈춥니다. VIBE 코딩의 목표는 AI가 모든 것을 끝내는 것이 아니라, 위험한 확장을 알아차리고 사람에게 넘기는 것입니다.

상황별 예시

목록 필터 기능

요청 문장: 사용자가 카테고리를 선택하면 목록이 해당 카테고리만 보여주고, 선택을 해제하면 전체 목록으로 돌아간다.

수락 기준:

• 기본 진입 시 전체 항목이 보인다.
• 카테고리 선택 시 선택된 카테고리 이름이 화면에 표시된다.
• 결과가 없으면 빈 상태 안내가 보인다.
• 새로고침 후에도 선택 상태가 유지된다면 주소에 필터 값이 보여야 한다.
• 모바일 화면에서 필터 버튼이 겹치지 않는다.

비목표:

• 항목 저장 구조는 바꾸지 않는다.
• 추천 정렬 알고리즘은 바꾸지 않는다.

검증:

• 관련 목록 테스트를 실행한다.
• 브라우저에서 기본, 선택, 빈 상태를 확인한다.

오류 메시지 개선

요청 문장: 사용자가 제출에 실패했을 때 원인별로 다른 안내를 보여주고, 다시 시도할 수 있는 행동을 제공한다.

수락 기준:

• 필수 입력 누락은 입력칸 근처에서 설명한다.
• 네트워크 실패는 재시도 가능한 안내로 보여준다.
• 권한 부족은 사용자가 다음에 할 수 있는 행동을 알려준다.
• 성공 메시지와 오류 메시지가 동시에 보이지 않는다.
• 같은 오류가 반복되어도 화면이 중복으로 늘어나지 않는다.

비목표:

• 서버의 권한 판정 방식은 바꾸지 않는다.
• 디자인 시스템 전체 색상은 바꾸지 않는다.

검증:

• 각 오류 상태를 재현한다.
• 화면 문구가 사용자에게 직접 도움이 되는지 확인한다.

AI에게 넘기는 최종 작업 지시서

좋은 지시서는 짧지만 빠진 경계가 없습니다. 예시는 다음과 같은 구조로 만들면 됩니다.

목표: 사용자가 저장 버튼을 눌렀을 때 성공, 입력 오류, 네트워크 실패를 구분해 이해할 수 있게 한다.

수락 기준: 성공 시 확인 문구가 한 번만 보인다. 입력 오류는 해당 입력 영역 근처에 보인다. 네트워크 실패는 재시도 가능성을 안내한다. 버튼 중복 클릭은 막는다. 모바일 화면에서 문구와 버튼이 겹치지 않는다.

비목표: 저장 데이터 구조와 권한 판정은 변경하지 않는다.

검증: 관련 테스트를 실행하고 성공, 입력 오류, 네트워크 실패, 모바일 폭을 확인한다.

보류 조건: 공통 폼 렌더러 변경이나 데이터 구조 변경이 필요하면 멈추고 보고한다.

이 정도만 있어도 AI의 작업 결과는 크게 달라집니다. 구현자는 무엇을 해야 하는지 알고, 리뷰어는 무엇을 봐야 하는지 알며, 운영자는 언제 공개해도 되는지 판단할 수 있습니다.

실수와 주의점

첫 번째 실수는 수락 기준을 기능 목록으로만 쓰는 것입니다. “필터 추가, 정렬 추가, 버튼 추가”는 할 일 목록이지 성공 기준이 아닙니다. 반드시 사용자가 보는 결과와 확인 방법을 함께 써야 합니다.

두 번째 실수는 “예쁘게”, “자연스럽게”, “최적화” 같은 단어에 의존하는 것입니다. 이런 단어는 방향은 주지만 완료 기준은 주지 않습니다. 디자인 감각이 필요한 작업이라도 “줄바꿈이 생겨도 CTA가 첫 화면에 남는다”, “카드 제목은 두 줄까지 보인다”처럼 관찰 가능하게 써야 합니다.

세 번째 실수는 검증을 마지막에 즉흥적으로 정하는 것입니다. 검증이 늦게 정해지면 AI는 무엇을 통과해야 하는지 모른 채 구현합니다. 수락 기준을 쓸 때 검증도 같이 써야 합니다.

네 번째 실수는 비목표를 생략하는 것입니다. AI가 좋은 의도로 주변 코드를 정리하다가 작업이 커질 수 있습니다. 특히 인증, 결제, 데이터 저장, 공통 레이아웃처럼 영향 범위가 넓은 영역은 비목표로 잠가두는 편이 좋습니다.

다섯 번째 실수는 실패 조건을 적지 않는 것입니다. 자동화 루프는 성공할 때보다 실패할 때 더 위험합니다. 실패 시 보류, 축소, 되돌림 중 무엇을 할지 미리 정해야 합니다.

검증 체크리스트

작업을 AI에게 넘기기 전에 아래 항목을 확인하세요.

• 사용자 역할이 명확한가?
• 사용자가 보는 행동으로 목표를 썼는가?
• 성공 조건이 화면이나 테스트로 확인 가능한가?
• 기준이 너무 많아 한 번의 작은 루프를 넘어가지 않는가?
• 이번 작업에서 하지 않을 비목표가 있는가?
• 검증 명령과 수동 확인 시나리오가 분리되어 있는가?
• 실패하거나 범위가 커질 때 멈출 조건이 있는가?
• 공개 화면에 내부적인 표현이 들어가지 않는가?
• 리뷰어가 기준만 보고 승인 여부를 판단할 수 있는가?

이 체크리스트를 통과하면 AI 작업은 훨씬 예측 가능해집니다. 특히 초보자는 수락 기준을 쓰는 시간이 아깝다고 느낄 수 있지만, 실제로는 재작업과 되돌림을 줄이는 가장 빠른 방법입니다.

다음 단계

다음 작업부터는 프롬프트를 쓰기 전에 “수락 기준 계약”을 먼저 작성해 보세요. 한 문단 목표, 5개 안팎의 성공 조건, 2개 이상의 비목표, 검증 방법, 보류 조건만 있으면 충분합니다. 이 작은 계약을 반복하면 팀의 VIBE 코딩 품질이 누적됩니다.

처음에는 모든 작업에 완벽한 기준을 만들 필요가 없습니다. 대신 실패가 자주 나는 유형부터 시작하세요. 폼 제출, 목록 필터, 결제 전환, 관리자성 화면, 공개 콘텐츠 발행처럼 사용자가 바로 영향을 받는 작업에 먼저 적용하면 효과가 큽니다.

수락 기준 계약 루프는 AI를 통제하기 위한 문서가 아니라, 사람과 AI가 같은 완료 지점을 보게 하는 협업 도구입니다. 완료 지점이 선명해질수록 AI는 더 빠르게 움직이고, 사람은 더 적은 피로로 더 안전한 결정을 내릴 수 있습니다.