AI 도구는 설치로 완성되지 않는다.
실전에서 발견한 것을 도구 정의에 다시 써넣는 루프가 생산성의 본체다.

오늘 E2E 테스트를 하면서 스킬을 두 번 고쳤다.
글을 쓰는 이유는 그 루프가 꽤 중요한 패턴이라는 걸 확인했기 때문이다.

TL;DR

  • AI 스킬(룰 파일)은 처음부터 정확하지 않다.
  • 실전이 스킬의 오차를 드러낸다.
  • 발견 → 스킬 수정 → 재실행 루프가 실제 생산성이다.
  • “도구를 잘 설치했다”보다 “도구를 잘 길들이고 있다”가 더 중요한 질문이다.

오늘 한 일

API 마이그레이션 회귀 E2E 테스트였다. PR 하나가 상당 범위의 API 레이어를 교체했고, 영향 페이지를 하나씩 Cursor 브라우저로 직접 검증하는 작업이었다.

스킬이 있었다. E2E 플랜을 어떻게 짜고, 어떤 순서로 실행하고, 어떻게 기록하는지 정의한 파일이다. 몇 주 전에 만들었고, 그 시점까지는 잘 맞았다.

오늘은 두 번 틀렸다.


첫 번째 오차: 샘플 ID가 없었다

플랜 파일에는 쿠폰컬렉션 페이지 테스트 URL을 id=1로 적어뒀다.

/store/coupon-collection/1/products

실제로 API를 치자 404였다. 샘플이 없는 ID였다.

이때 취할 수 있는 선택지는 두 가지다.

  • “환경 문제겠지”하고 다른 걸 하거나
  • 유효한 ID를 직접 찾거나

후자를 택했다. 슬랙에서 coupon-collection URL을 검색하자 동료가 테스트에 쓴 URL이 금방 나왔다. 100001528. API 200, 페이지 정상.

스킬에 이 패턴이 없었다. “ID를 플랜에 명시하라”는 있었지만, “qa 환경의 id=1은 자주 404 — 팀 대화 로그나 테스트 URL에서 실제 ID를 먼저 확보하라”는 없었다.

그날 배운 것 한 줄을 스킬에 썼다.

coupon-collection은 qa id=1이 404인 경우 많음
→ 실행 전 협업 채널 검색으로 coupon-collection/{id} 샘플 확보

두 번째 오차: API 200이 PASS가 아니었다

브랜드 좋아요 버튼을 눌렀다. 네트워크에 POST …/brands/{id}/set 200. 언뜻 PASS처럼 보인다.

사용자가 물었다.

“브랜드나 상품에 대한 좋아요 상태 값을 바꾼 뒤에도, 상태 값을 E2E로 확인해야 하지 않을까?”

맞는 말이었다. API 200은 “뮤테이션이 성공했다”는 것이지, “페이지가 다시 로드됐을 때도 상태가 유지된다”는 것이 아니다. 캐시가 틀어질 수 있고, GET 쿼리가 잘못 연결될 수 있다.

그래서 루틴을 바꿨다.

  1. 브랜드 ♥ off → onPOST …/set 200 확인
  2. 페이지 재진입GET …/brands/{id}만 호출됐는지, set 없이 on 유지인지 확인
  3. 브랜드 ♥ on → offPOST …/unset 200 확인
  4. 페이지 재진입off 유지 확인
  5. 상품 ♥도 동일 루틴

결과:

검증 API UI
brand set POST 200 아이콘 filled
reload GET only on 유지
brand unset POST 200 outline
reload GET only off 유지
product set POST 200 카드 ♥ 수 증가
reload GET+all 수 유지
product unset POST 200 카드 원상복구
reload GET+all 수 원상복구

이걸 전부 확인한 뒤에야 PASS라고 적었다.

스킬에 이 내용을 추가했다.

♥ 클릭 후 API 200만으로 PASS 금지.
→ 재진입(navigate 동일 URL) 후 GET만으로 상태 유지되는지 확인 필수.

왜 이걸 쓰는가

스킬을 두 번 고쳤다. 소소한 일이다. 하지만 여기에 중요한 패턴이 있다.

스킬은 처음에 완성되지 않는다

처음 스킬을 쓸 때는 “지금까지 한 일”을 정리한 것이다. 아직 안 해본 엣지 케이스는 담기지 않는다. 당연한 일이다.

문제는 이 사실을 잊을 때다. 스킬이 있으면 다 해결되는 것처럼 대하는 순간, 스킬이 맞지 않는 상황에서 그냥 지나치게 된다.

실전이 오차를 드러낸다

오늘 두 번의 오차는 실행 중에 발견됐다. 설계 단계에서는 몰랐다.
“쿠폰컬렉션 ID는 테스트용이 있을 것이다”는 가정이 틀렸고,
“API 200이면 충분하다”는 가정도 불완전했다.

이런 오차는 실제로 해봐야 나온다. 코드 리뷰만으로는 안 잡힌다.

발견을 기록해야 루프가 된다

발견하고 그냥 넘어가면 다음번에 또 같은 오차를 만난다. 발견을 스킬에 쓰면, 다음번에는 그 오차가 줄어든다.

실행 → 오차 발견 → 스킬 수정 → 실행

이 루프가 도구의 실제 생산성이다. 도구를 설치하는 것이 아니라 길들이는 것이 차이를 만든다.


은탄환이 없다는 말의 뜻

“AI는 은탄환이 아니다”는 말을 자주 한다. 그 말이 의미하는 것은 두 가지로 나뉜다.

하나는 “그러니까 AI를 과신하지 마라”는 뜻이고,
다른 하나는 “그러니까 스스로 맥락을 관리해야 한다”는 뜻이다.

전자는 경고다. 후자는 전략이다.

스킬을 만들고 쓰고 고치는 루프는 후자에 해당한다. 도구를 쓰지 않겠다는 게 아니라, 도구를 내 상황에 맞게 계속 조정하겠다는 의지다.

오늘 교훈을 한 줄로 압축하면 이렇다.

스킬은 코드처럼 관리해야 한다. 첫 버전이 맞는 일은 없다.


덧: 이 과정에서 AI가 한 일

사실을 말하자면, 오늘 대부분의 실행은 AI 에이전트가 했다. 브라우저를 열고, 버튼을 누르고, 네트워크를 확인하고, 스킬을 고쳤다.

그런데 핵심 판단은 사람이 했다.

  • “상태값 변경 후 검증도 해야 하지 않나?” — 사람
  • “id=1이 아닐 것 같다” — 사람
  • “슬랙에서 찾으면 된다” — 사람

AI는 그 판단을 받아서 실행했다. 실행은 빠르고 정확했다. 하지만 무엇을 검증해야 하는지, 어떤 가정이 틀렸는지, 그 오차를 스킬 어디에 써야 하는지는 사람의 판단이었다.

이게 내가 생각하는 AI와 일하는 방식이다.
도구가 실행하고, 사람이 방향을 잡는다.
그 경계를 명확히 하지 않으면 도구가 방향까지 가져간다.


마치며

E2E 테스트는 끝나지 않았다. content 파트가 남아 있다.

하지만 오늘 두 번 고친 스킬은 내일 content E2E에서 이미 작동한다.
오차를 기록한 루프가 그렇게 조용히 쌓인다.

한 줄 결: 도구는 처음에 완성되지 않는다. 실전에서 길들여진다.