AI가 코드를 짜는 시대, 이제 프로젝트마다 ‘Verification Skill’이 필요하다

AI 코딩 도구가 빠르게 발전하면서 소프트웨어 개발 방식도 크게 달라지고 있다.

Cursor, Claude Code, Codex, Gemini CLI 같은 도구를 사용하면 이제 몇 줄의 요구사항만으로 상당한 양의 코드를 만들 수 있다. 간단한 기능이라면 몇 분 만에 화면과 API까지 완성되는 경우도 있다.

하지만 AI 코딩을 오래 사용하다 보면 곧 다른 문제가 보이기 시작한다.

코드를 만드는 속도보다, 그 코드가 실제로 제대로 동작하는지 확인하는 일이 더 큰 병목이 된다.

AI가 코드를 작성한 뒤 사람이 앱을 실행하고, 버튼을 눌러보고, 에러 로그를 확인하고, 다시 AI에게 수정 요청을 보내는 구조라면 개발 속도가 아무리 빨라져도 검증 단계에는 여전히 사람이 묶여 있다.

이 문제를 해결하려는 흥미로운 접근법이 최근 pstack에서 제시되고 있다.

pstack은 개발자 Lauren(@poteto)이 AI 에이전트를 활용한 엔지니어링 작업을 위해 만든 개인적인 Skill 세트다. 작성자는 이를 높은 품질을 유지하면서 대규모 코드 변경을 처리하기 위한 엔지니어링 체계로 소개한다.

그중에서도 가장 중요한 개념이 바로 Verification Skill이다.

---

AI 코딩의 진짜 병목은 ‘작성’이 아니라 ‘검증’이다

일반적인 AI 코딩 흐름을 생각해보자.

예를 들어 AI에게 다음과 같이 요청한다.

회원가입 화면을 만들어줘.

이메일 인증을 지원하고,
가입이 완료되면 대시보드로 이동하게 해줘.

AI는 상당히 빠르게 코드를 작성할 수 있다.

하지만 코드가 만들어진 뒤에는 확인해야 할 것이 많다.

컴파일은 정상적으로 되는가?

앱은 실행되는가?

회원가입 버튼은 실제로 동작하는가?

잘못된 이메일 주소는 차단되는가?

회원가입 API는 정상적으로 호출되는가?

사용자 정보는 DB에 저장되는가?

가입 후 대시보드로 이동하는가?

기존 로그인 기능은 깨지지 않았는가?

AI가 코드를 아무리 빠르게 생성해도 결국 사람이 이 모든 항목을 확인해야 한다면 구조는 다음과 같다.

AI
↓
코드 작성
↓
사람이 실행
↓
사람이 문제 발견
↓
AI에게 수정 요청
↓
AI가 수정
↓
사람이 다시 확인

여기서 병목은 AI가 아니라 사람이다.

pstack이 Verification을 중요하게 보는 이유도 여기에 있다.

pstack의 설명에서 Verification은 에이전트가 자신의 작업을 스스로 확인할 수 있는 능력을 의미한다. 에이전트가 작업 결과를 검증할 수 있다면 사람이 매번 반복 루프에 들어가지 않아도 에이전트가 작업을 계속 진행할 수 있다.

결국 목표는 다음 구조다.

CODE
 ↓
RUN
 ↓
OBSERVE
 ↓
VERIFY
 ↓
FAIL
 ↓
FIX
 ↓
RUN
 ↓
VERIFY
 ↓
PASS

AI에게 단순히 코드를 작성하는 능력만 주는 것이 아니라,

작성 → 실행 → 관찰 → 판단 → 수정

까지 하나의 폐쇄 루프(Closed Loop)로 만드는 것이다.

---

Verification Skill이란 무엇인가

Verification Skill을 단순한 테스트 코드라고 생각하면 이해하기 어렵다.

더 정확하게 표현하면 다음과 같다.

Verification Skill은 AI 에이전트가 특정 프로젝트를 실행하고, 조작하고, 관찰하고, 정상 동작 여부를 판단하기 위해 사용하는 프로젝트 전용 검증 인터페이스다.

예를 들어 프로젝트 내부에 다음과 같은 구조를 만들 수 있다.

my-app/
│
├── src/
├── tests/
├── package.json
│
└── .agents/
    └── skills/
        └── verify-app/
            │
            ├── SKILL.md
            ├── control-app.ts
            ├── verify.sh
            │
            └── references/
                └── features/
                    ├── README.md
                    ├── auth.md
                    ├── payment.md
                    ├── profile.md
                    └── settings.md

여기에는 크게 두 가지가 들어간다.

Verification Skill

├─ Knowledge
│   ├─ Feature Map
│   ├─ 정상 동작 조건
│   ├─ 테스트 계정
│   ├─ 알려진 예외 사항
│   └─ 기능별 검증 방법
│
└─ Tools
    ├─ App Controller
    ├─ Browser Controller
    ├─ Screenshot
    ├─ Network Log
    ├─ Console
    ├─ API Inspector
    ├─ DB Inspector
    └─ Performance Trace

즉 Verification Skill은 단순한 프롬프트가 아니다.

프로젝트에 대한 지식과 프로젝트를 직접 조작할 수 있는 도구를 함께 제공하는 시스템에 가깝다.

---

AI에게 ‘눈과 손’을 만들어주는 것

Verification Skill에서 가장 중요한 부분 중 하나는 앱을 조작할 수 있는 CLI다.

pstack에서는 이를 Build the Lever라는 원칙과 연결한다.

AI에게 매번 임시 스크립트를 작성하게 하는 것보다 반복적으로 사용할 수 있는 작은 도구를 만들어주는 편이 더 재현 가능하고 효율적이라는 생각이다.

예를 들어 다음과 같은 CLI가 있다고 생각해보자.

control-app doctor

control-app new-session

control-app click login-button

control-app type email "test@example.com"

control-app type password "password123"

control-app click submit

control-app snapshot

control-app screenshot /tmp/login-result.png

control-app network-log

control-app console

control-app trace

이제 AI는 자연어로 브라우저 조작 방법을 매번 고민할 필요가 없다.

필요한 행동을 명령어로 수행하면 된다.

pstack의 예시에서도 Inspection, Navigation, Interaction, Performance, Streaming, Health 등의 기능을 CLI 형태로 구성한다.

이를 기능별로 나누면 다음과 같다.

눈

snapshot
screenshot
components


손

click
type
press
scroll


로그

console
network-log
network-summary


성능 측정

trace
profile
perf-metrics


상태 점검

doctor
cleanup
watch

AI에게 코딩 능력만 주는 것이 아니라,

앱을 볼 수 있는 눈과 조작할 수 있는 손, 상태를 측정할 수 있는 계측기까지 제공하는 셈이다.

---

왜 프로젝트마다 Verification Skill이 필요한가

그렇다면 이런 질문이 생긴다.

하나의 범용 Verification Skill을 만들어 모든 프로젝트에서 사용하면 되지 않을까?

기본적인 브라우저 조작이나 로그 확인 기능은 공통화할 수 있다.

하지만 실제 검증 규칙은 프로젝트마다 크게 다르다.

예를 들어 쇼핑몰이라면 핵심 기능이 다음과 같을 수 있다.

상품 검색
상품 상세
장바구니
쿠폰
결제
주문
배송 조회
환불

반면 암호화폐 지갑이라면 전혀 다르다.

Wallet 생성
Seed Phrase
Network 변경
Balance 조회
Token Transfer
Transaction Signing
DApp Connection
Transaction History

AI가 기능을 검증하려면 단순히 버튼을 누르는 방법만 알아서는 부족하다.

다음 내용을 알아야 한다.

어떤 기능이 존재하는가?

어디에서 기능에 접근하는가?

어떤 상태가 정상인가?

어떤 API가 호출되어야 하는가?

어떤 데이터가 저장되어야 하는가?

실패할 경우 어떤 로그를 확인해야 하는가?

어떤 계정이나 테스트 데이터가 필요한가?

이 정보는 프로젝트마다 다르다.

그래서 현실적인 구조는 다음과 같다.

Verification Core
│
├─ Browser
├─ Screenshot
├─ Network
├─ Console
├─ Database
├─ Trace
└─ Reporting
        │
        ├──────────────┬───────────────┐
        ↓              ↓               ↓
   Project A        Project B       Project C
   Verify-A         Verify-B        Verify-C
        │              │               │
 Feature Map     Feature Map     Feature Map
 Rules           Rules           Rules
 Test Data       Test Data       Test Data

공통 검증 엔진은 재사용하고, 프로젝트별 기능 지도와 판정 규칙만 따로 관리하는 구조다.

이 방식은 프로젝트 수가 많아질수록 효과가 커진다.

---

Feature Map: AI를 위한 프로젝트 지도

Verification Skill의 또 다른 핵심 요소가 Feature Map이다.

pstack에서는 Feature Map을 애플리케이션의 기능과 접근 방법을 에이전트가 쉽게 검색할 수 있도록 정리한 지도 형태의 문서로 설명한다.

예를 들어 인증 기능이라면 다음과 같이 만들 수 있다.

# Authentication

## Features

- Email Login
- Google Login
- Apple Login
- Password Reset
- Logout


## How to reach

Home
→ Profile
→ Login


## Verification

Email Login

1. Login 화면을 연다.
2. 이메일을 입력한다.
3. Password를 입력한다.
4. Login 버튼을 누른다.
5. Dashboard가 나타날 때까지 기다린다.


## Expected

- Login API HTTP 200
- access_token 생성
- Dashboard 표시
- Profile avatar 표시
- Console Error 없음

AI는 이제 로그인 기능 하나를 테스트하기 위해 전체 코드베이스를 다시 검색할 필요가 없다.

auth.md만 보면 된다.

프로젝트가 커지면 Feature Map도 자연스럽게 확장된다.

Feature Map

Auth
├─ Login
├─ Signup
├─ Password Reset
└─ OAuth

Payment
├─ Checkout
├─ Coupon
├─ Refund
└─ Receipt

Profile
├─ Edit
├─ Avatar
└─ Delete Account

Admin
├─ User Management
├─ Analytics
└─ Content Management

pstack 작성자는 Feature Map을 일종의 Materialized Memory라고 표현한다.

프로젝트의 기능과 개발 과정에서 쌓인 의사결정을 AI가 빠르게 활용할 수 있는 형태로 압축해 놓은 기억이라는 의미다.

---

Verification의 핵심은 Expected State다

Verification Skill을 구축할 때 특히 중요한 것이 하나 있다.

단순히 행동만 기록해서는 안 된다.

예를 들어 다음과 같은 검증은 좋지 않다.

로그인 페이지를 열고 로그인해본다.

AI 입장에서 중요한 것은 로그인 행동 자체가 아니다.

무엇이 정상적인 로그인인지 판단하는 기준이다.

따라서 다음처럼 만들어야 한다.

ACTION

/login 이동

email 입력

password 입력

Login 클릭


EXPECTED

/dashboard 이동

HTTP 200

access_token 존재

사용자 avatar 표시

console error 0

Verification은 결국 세 요소로 구성된다.

ACTION
   ↓
OBSERVATION
   ↓
JUDGEMENT

행동만 자동화하면 Automation이다.

행동 결과를 관찰하면 Testing에 가까워진다.

여기에 정상 상태를 판단할 수 있는 기준까지 들어가면 Verification Loop가 완성된다.

---

실제 개발에서는 어떻게 동작할까

간단한 Todo 앱을 예로 들어보자.

현재 앱에는 다음 기능이 있다.

회원가입
로그인
Todo 생성
Todo 완료
Todo 삭제

프로젝트에는 다음 Verification Skill이 들어 있다.

verify-todo/
│
├── SKILL.md
├── control-todo.ts
│
└── references/
    ├── auth.md
    └── todo.md

개발자가 AI에게 요청한다.

Todo에 Priority 기능을 추가해줘.

high / normal / low 세 단계이고
Todo 목록에서도 표시되도록 해줘.

AI가 기능을 구현한다.

그리고 Verification Skill을 이용해 직접 검증한다.

control-todo reset-db

control-todo login test@example.com

control-todo create-todo "Buy milk"

control-todo priority "Buy milk" high

control-todo snapshot

정상적인 결과는 다음과 같다.

{
  "title": "Buy milk",
  "priority": "high"
}

하지만 실제 결과가 다음과 같이 나온다고 가정하자.

{
  "title": "Buy milk",
  "priority": null
}

AI는 즉시 차이를 발견할 수 있다.

Expected: high

Actual: null

Network Log를 확인한다.

control-todo network-log

결과가 다음과 같다.

PATCH /todos/42

{
  "title": "Buy milk"
}

여기서 AI는 priority 값이 PATCH Payload에 들어가지 않았다는 사실을 확인한다.

코드를 수정한다.

updateTodo({
  title,
  priority
})

그리고 다시 Verification을 수행한다.

CODE
 ↓
RUN
 ↓
OBSERVE
 ↓
FAIL
 ↓
DIAGNOSE
 ↓
FIX
 ↓
RUN
 ↓
PASS

사람이 중간 과정에 개입하지 않아도 하나의 문제 해결 루프가 돌아간다.

이것이 Verification Skill의 가장 중요한 가치다.

---

그러면 Playwright나 Jest와 무엇이 다른가

Verification Skill을 처음 접하면 이런 의문이 들 수 있다.

결국 Playwright 같은 E2E 테스트 아닌가?

일부 기능은 겹친다.

하지만 역할은 조금 다르다.

Jest는 주로 특정 함수나 모듈의 동작을 검증한다.

Jest
→ Unit Test

Playwright는 정의된 사용자 시나리오를 실행한다.

Playwright
→ E2E Test

Verification Skill은 한 단계 위에서 움직인다.

Verification Skill
        │
        ├─ Jest
        ├─ Playwright
        ├─ API
        ├─ Database
        ├─ Screenshot
        ├─ Network
        └─ Performance Trace

즉 기존 테스트 도구를 대체하기보다 AI가 여러 검증 도구를 상황에 맞게 사용할 수 있도록 연결하는 상위 레이어에 가깝다.

AI가 어떤 기능을 변경했다면,

어떤 테스트를 해야 하는가?

어떤 화면을 확인해야 하는가?

어떤 API를 봐야 하는가?

DB 상태도 확인해야 하는가?

Regression 가능성은 어디에 있는가?

를 Feature Map과 Verification Skill을 통해 판단하게 만드는 것이다.

---

“AI가 동작한다고 말하는 것”과 “동작한다는 증거를 보여주는 것”

AI 코딩에서 앞으로 중요한 변화 중 하나는 결과 보고 방식일 가능성이 높다.

현재 AI 코딩 도구는 보통 이렇게 말한다.

기능 구현을 완료했습니다.

하지만 Verification 기반 개발에서는 다음과 같은 결과가 더 중요해진다.

✓ Build successful

✓ Unit Tests 184 / 184

✓ Login API HTTP 200

✓ Dashboard rendered

✓ Console Error 0

✓ Regression Test passed

✓ Screenshot saved

✓ Performance Trace checked

pstack에서도 신규 기능 개발 예시로 Verification Skill을 이용해 변경 내용을 검증하고, 스크린샷이나 영상으로 증거를 보여주도록 요청하는 방식을 제시한다.

결국 개발 방식이 다음처럼 변화한다.

AI says it works

에서

AI proves it works

로 이동하는 것이다.

---

Verification Skill도 코드처럼 관리해야 한다

Verification Skill은 한 번 만들고 끝나는 문서가 아니다.

프로젝트가 변경되면 Verification도 함께 변경되어야 한다.

새 기능 추가
      ↓
Feature Map 수정
      ↓
Verification Rule 수정
      ↓
Control CLI 수정

예를 들어 결제 기능에 새로운 쿠폰 시스템이 추가됐다면 Feature Map에도 쿠폰 기능이 추가되어야 하고 정상적인 할인 계산 결과도 Verification Rule에 들어가야 한다.

pstack에는 이를 위한 /maintain-verification-skill이라는 개념도 있다.

작성자는 프로젝트 변화가 Verification Skill에 지속적으로 반영될 수 있도록 이를 주기적으로 유지할 것을 권장한다.

즉 Verification Skill은 README보다 오히려 테스트 인프라에 가까운 자산이다.

Application
     ↓
Feature Map
     ↓
Verification Skill
     ↓
Agent Capability

프로젝트가 발전하면 Verification Skill도 같이 발전한다.

그리고 Verification Skill이 좋아질수록 AI 에이전트가 프로젝트를 개발하는 능력 역시 좋아진다.

---

앞으로 프로젝트 초기 세팅에 Verification이 포함될 수 있다

지금까지 새로운 프로젝트를 만들 때 개발팀은 보통 다음 환경을 구축했다.

README

Lint

Formatter

Unit Test

E2E Test

CI/CD

Docker

Monitoring

AI 에이전트가 개발 과정의 중요한 구성원이 된다면 앞으로는 여기에 하나가 추가될 수 있다.

README

Lint

Unit Test

E2E Test

CI/CD

Docker

Monitoring

Verification Skill

더 나아가 프로젝트 생성 단계부터 자동화할 수도 있다.

project-init
     ↓
Application 생성
     ↓
Development Environment 설정
     ↓
Test Environment 구성
     ↓
Verification Skill 생성
     ↓
Feature Map 생성

이렇게 되면 Verification 환경은 나중에 붙이는 테스트 도구가 아니라 프로젝트의 기본 개발 인프라가 된다.

---

AI 코딩의 다음 단계는 더 좋은 프롬프트가 아닐 수 있다

AI 코딩이 처음 등장했을 때 관심의 중심은 프롬프트였다.

어떤 프롬프트를 사용하면 AI가 더 좋은 코드를 만들어주는지가 중요했다.

하지만 에이전트가 코드베이스를 직접 수정하고 수십 개의 작업을 병렬로 수행하는 환경에서는 다른 문제가 더 중요해진다.

Prompt Engineering
        ↓

Agent Engineering
        ↓

Verification Engineering
        ↓

Autonomous Software Engineering

AI가 코드를 작성하는 능력이 계속 좋아질수록 오히려 중요한 것은

“어떻게 더 많은 코드를 만들 것인가”가 아니라 “어떻게 AI 스스로 자신의 작업이 맞는지 확인하게 만들 것인가”가 될 가능성이 높다.

Verification Skill은 바로 그 문제를 해결하기 위한 하나의 접근법이다.

---

프로젝트마다 작은 ‘AI 개발 OS’를 만들어라

Verification Skill을 가장 단순하게 정의하면 테스트 자동화처럼 보일 수 있다.

하지만 조금 더 확장해서 보면 의미가 달라진다.

프로젝트마다 다음 정보가 쌓인다.

기능 지도

실행 방법

테스트 계정

정상 상태

실패 패턴

디버깅 방법

API 상태

DB 상태

성능 기준

Regression Rule

그리고 AI는 이 정보를 이용해 개발한다.

                    Developer
                        │
                  Feature Request
                        │
                        ▼
                   Coding Agent
                        │
                   Implementation
                        │
                        ▼
                Verification Skill
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
          UI            API           DB
          │             │             │
          ▼             ▼             ▼
      Screenshot     Network        State
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                     Judge
                        │
               ┌────────┴────────┐
               ▼                 ▼
              PASS              FAIL
               │                 │
               ▼                 ▼
             Report             Fix
                                  │
                                  └──────↺

이 구조가 충분히 발전하면 Verification Skill은 단순한 테스트 파일이 아니다.

AI가 프로젝트를 이해하고 개발하기 위해 사용하는 운영 환경에 가까워진다.

그래서 프로젝트마다 Verification Skill을 하나씩 갖는다는 생각은 꽤 중요한 의미를 가진다.

AI에게 코드를 많이 작성하게 만드는 것보다,

AI가 자신이 작성한 코드가 실제로 동작한다는 사실을 스스로 증명할 수 있게 만드는 것.

AI 에이전트 기반 소프트웨어 개발에서 다음 경쟁력은 아마 이쪽에서 만들어질 가능성이 있다.

코드를 짜는 AI는 이미 많다.

앞으로 필요한 것은,

끝까지 확인하는 AI다.