ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • AI 결과물 검증, 저는 기준부터 먼저 적습니다
    AI Agent 2026. 6. 17. 20:38
    728x90
    반응형

    타입 오류 좀 없애 달라고 했더니, 진짜로 any가 박혀서 돌아왔습니다.

    통과는 했죠.
    빨간 줄이 싹 사라졌으니까요.

    근데 그건 문제를 푼 게 아니라, 문제를 덮은 거였어요.

    그때 깨달았습니다.
    AI 에이전트는 일을 "해결"하려고 해요.
    그래서 가끔 문제를 푸는 대신, 계약을 슬쩍 바꿔버립니다.

    그날 이후로 저는 요청을 던지기 전에 완료 기준과 금지 조건을 먼저 씁니다.

    결과물이 늘면, 리뷰할 표면도 늘어요

    AI를 쓰면 결과물이 빨리 늘어납니다.
    diff, 테스트, README, 마이그레이션 초안, PR 설명까지 한 번에 나오죠.
    처음엔 이 속도가 좋아요.

    근데 사람이 파일 하나 고쳤을 땐 그 파일만 보면 됐는데, 에이전트가 한 번에 여러 개를 고치면 그걸 다 같이 봐야 합니다.
    백엔드는 그나마 나아요.
    들어갈 값, 나올 값이 어느 정도 정해져 있으니까.
    화면이 골치예요.
    같은 화면도 데이터가 비었을 때, 길어졌을 때, 다크모드일 때마다 다르게 깨지거든요.

    무엇을 검증할지가 구현보다 오래 갑니다

    검증을 적을 때, 저는 내부 모양 말고 의도를 적으려고 합니다.

    "이 함수가 세 번 호출돼야 한다" 같은 건 리팩터링 한 번이면 깨져요.
    호출 횟수는 코드를 어떻게 짰느냐의 문제지, 우리가 원한 게 아니니까요.
    반대로 "권한 없는 사용자는 403을 받는다"는 내부를 아무리 갈아엎어도 그대로 남습니다.
    AI는 내부를 자주 바꾸니까, 검증이 내부에 묶여 있으면 자꾸 헛되이 깨지더라고요.

    그래서 이런 문장을 먼저 적어둬요.
    마감된 수업은 신청이 안 된다.
    삭제된 사용자의 토큰은 인증에 실패한다.
    결제 금액은 서버가 계산한 값으로 저장된다.
    구현이 바뀌어도 이건 안 바뀌니까요.

    테스트만으론 부족할 때가 있어요

    검증이라고 하면 테스트부터 떠오르는데, AI 작업에선 그것만으론 모자랄 때가 많습니다.
    한번은 목 데이터로 짠 e2e 테스트 157개가 전부 초록불이었어요.
    다 됐구나 싶었죠.
    그런데 진짜 데이터를 처음 꽂는 순간, 5개가 그 자리에서 터졌습니다.
    초록불 보던 손이 그대로 멈췄어요.
    터진 것들은 목이 구조적으로 못 잡는 종류였습니다.
    인증 제공자가 등록 안 돼서 401, 타임존이 안 맞아서 화면이 어긋나고, 요청 헤더가 경합하면서 깨졌어요.
    내가 만든 픽스처로 통과하는 초록불은 결국 '내 가정이 내 가정과 일치한다'는 말이었던 거죠.
    실제 데이터는 messy하고, 타임존을 가지고 있고, 내 기대를 안 지킵니다.
    그래서 검증은 그 messy한 진짜 데이터로 설계해야 비로소 '완료'가 보여요.
    UI면 화면을 직접 봐야 하고, 배포면 실제 URL을 찔러봐야 하고, 데이터면 다시 읽어 확인해야 하거든요.

    그래서 "어떤 명령을 돌릴지"랑 "어떤 효과를 볼지"를 따로 적어요.
    예를 들어 목록 화면이면 이렇게 넘깁니다.

    이 목록 화면은 항목 텍스트가 길어지면 카드 안에서 글자가 잘립니다. 긴 항목과 짧은 항목이 한 화면에 같이 보이게 고치고, 두 경우를 캡처로 남기세요. 카드 컴포넌트의 공개 동작은 바꾸지 마세요.

    "하지 말 것"도 같이 적습니다

    완료 기준만큼 챙기는 게 금지 조건이에요.

    any 사건처럼, 에이전트는 통과를 위해 기대값을 슬쩍 내리거나 실패를 빈 값으로 덮을 수 있거든요.
    그래서 미리 못을 박아요.
    공개 API 응답 필드는 건드리지 말 것.
    기존 migration은 고치지 말고 새로 만들 것.
    실패를 기본값으로 숨기지 말 것.
    테스트 기대값을 지금 버그에 맞춰 낮추지 말 것.
    잔소리 같지만, 나중에 리뷰에서 쓸 시간을 앞에서 미리 내는 셈이에요.

    받을 보고 형식도 미리 정해 둡니다.
    바뀐 파일, 핵심 변경, 통과한 검증, 확인 못 한 범위, 사람이 봐야 할 결정.
    이 다섯 줄이면 긴 설명을 읽을 필요 없이 믿을지 말지가 보여요.

    일이 앞쪽으로 옮겨가요

    AI가 코드를 더 만들수록 개발자가 할 게 없어질 것 같지만, 저는 좀 다르게 느껴요.

    직접 타이핑하는 시간은 줄고, 대신 앞에서 기준을 적는 시간이 늘어납니다.
    어떤 실패를 막을지, 뭘 건드리면 안 되는지, 뭐가 성공의 증거인지를 먼저 정하는 일이요.

    이게 은근히 귀찮아서 저도 자꾸 미룹니다.
    근데 미룬 날치고, 리뷰가 조용히 끝난 적이 없어요.

    이 글은 'AI 코딩 에이전트를 믿는 법' 시리즈의 한 편이에요.
    위임·검증·하네스·비용 6편을 한 번에 보려면 여기로요.

    https://datacook.tistory.com/156

     

    AI 코딩 에이전트를 믿는 법 — 위임·검증·하네스·비용 6편 정리

    AI가 "완료했습니다" 한 줄로 답할 때, 저는 더 이상 그 말을 안 믿습니다.습관처럼 diff부터 엽니다. 그래서 들킨 적도 많고요. 멀쩡한 보고 뒤에서 엉뚱한 파일이 고쳐져 있던 날, 검증이 전부 초

    datacook.tistory.com

     

    728x90
    반응형
Designed by Tistory.