ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • AI에게 어디까지 맡길까, 저는 가역성부터 봅니다
    AI Agent 2026. 6. 17. 20:37
    728x90
    반응형

    처음엔 AI한테 매 단계 확인을 받게 했어요.
    "이렇게 할까요?", "이거 합쳐도 될까요?"

    그게 미칠 노릇이었습니다.

    되돌릴 수 있는 사소한 것까지 다 물어보니까, 차라리 내가 직접 하는 게 빠를 지경이었어요.
    확인 한 번 해주는 사이에 흐름이 끊기고요.
    결국 못 참고 기준을 통째로 뒤집었습니다.

    "AI가 잘할 수 있나"를 먼저 묻지 않기로 했어요.
    대신 이걸 봅니다.
    망치면 되돌릴 수 있나.

    되돌릴 수 있으면, 묻지 말고 맡깁니다

    명세 쓰고, 코드 고치고, 테스트 돌리고, 브랜치 따서 작업하고, 로컬에서 합치는 것까지.
    마음에 안 들면 브랜치째 버리면 그만이에요.

    대신 조건이 하나 붙어요.
    되돌릴 수 있는 형태로 남길 것. 뭘 바꿨고 왜 바꿨는지가 눈에 보이면, 나중에 제가 한 번에 되돌리거나 방향을 틀 수 있으니까요.
    그래서 정작 제가 보는 건 잘했는지가 아니에요.
    되돌릴 수 있는 모양으로 끝냈는지죠.

    이 조건을 그냥 좋은 말로 붙인 게 아니에요.
    한 번 데여서 붙은 거예요.
    오픈소스 디자인 도구 비슷한 걸 만들어 달라고 막연하게 던진 적이 있어요.
    "끝까지 밀어"만 붙이고 경계는 안 줬죠.
    에이전트가 확신에 차서 여러 턴을 내리 달리더니, 외부 패키지 수백 개에 수백 메가짜리 프로젝트를 통째로 새로 만들어 왔어요.
    기술적으론 다 돌아갔고 검사도 다 초록이었습니다.
    결과물을 여는데 손끝이 좀 식더라고요.
    다 맞는데, 딱 하나 '이게 맞는 타겟이냐'만 틀렸거든요.
    그래서 전부 버렸어요.
    그때 봤어요.
    자율성을 줘도 WHAT, 그러니까 뭘 만드는지를 안 박아 두면, 에이전트는 엉뚱한 데로 자신만만하게 질주한다는 걸.
    그래서 "버리면 그만"이 되려면, 맡길 때 타겟부터 못 박혀 있어야 해요.

    dry-run이 운영 직전에 잡아준 날

    제일 조심하는 건 운영 DB예요.
    그날도 그랬습니다.

    레코드 2만 2천여 건을 훑어서 비어 있던 필드를 채우는 백필 마이그레이션이었어요.
    운영에 바로 넣기 전에 dry-run으로 먼저 돌렸습니다.
    끝에 검증이 빨갛게 떴어요.
    아직 안 채워진 게 남아 있다고.

    안 눌렀습니다.
    그대로 운영에 넣었으면 절반만 채워진 데이터가 그냥 나갔을 거예요.
    dry-run이 운영 가기 전에 대신 한 대 맞아준 셈이죠.

    그래서 이런 일은 준비까지만 맡깁니다.
    스크립트 짜고, dry-run 돌려서 결과 정리하는 데까지.
    마지막 운영 적용 버튼은 제가 누르고요.

    중요한 건 이게 부탁이 아니라 장치로 박혀 있다는 점이에요.
    우리 마이그레이션 툴은 별도 확인 id 없이는 운영 적용을 아예 막아 둡니다.
    "운영엔 손대지 마" 한 줄로 비는 게 아니라, 운영으로 가는 문 자체가 잠겨 있는 거죠.
    자연어 약속은 에이전트가 흘려들을 수 있어도, 잠긴 문은 못 엽니다.

    그래서 똑같은 "마이그레이션"이라도 갈려요.
    되돌릴 수 있는 건 배포 때 그냥 자동으로 돌게 두고, 위험한 건 수동 runbook 뒤로 빼서 사람이 직접 돌리게.

    알아서 넘기면 안 되는 선

    매번 물을 필욘 없되, 알아서 넘기면 절대 안 되는 선이 있어요.
    손에 꼽아 둡니다.

    제일 위는 방금 그 운영 DB랑 운영 배포고요.
    그 다음이 밖으로 나가는 것 — 메일·문자·알림, 외부 API.
    한 번 발송되면 회수가 안 되니까요.
    공개된 메인 브랜치로 push하는 것, 실제 사용자한테 닿는 피드백, 공유 브랜치 force push나 reset --hard 같은 파괴적인 git도 같은 칸이에요.

    다 클릭 한 번이라 쉬워 보이는데, 나가는 순간 주워 담기 어려운 것들이죠.

    가역성은 시간이 지나면 닫힙니다

    한 가지 더.
    되돌릴 수 있는 창이 영원하지 않아요.

    코드는 배포 전까진 되돌리기 쉽지만, 트래픽을 받기 시작하면 결과가 캐시로, 다운스트림으로 퍼져서 점점 못 되돌리게 됩니다.
    메일은 발송하고 0초 뒤부터 비가역이고요.
    그래서 "되돌릴 수 있나"는 사실 "지금 이 순간, 몇 분 안에 되돌릴 수 있나"에 가깝더라고요.

    그래서 경계는 시작할 때 긋습니다

    제일 중요한 건, 이 선을 일 끝난 다음에 긋지 않는 거예요.
    "일단 해보고 위험하면 말해줘"는 이미 늦습니다.

    그래서 처음 요청할 때 한 줄을 붙여요.
    "로컬 수정·테스트·브랜치 작업은 알아서 해.
    운영 배포·외부 발송·데이터 삭제는 명령만 만들어 두고 멈춰."

    매 단계 묻게 했다가 답답해서 뒤집은 뒤로, 새 일을 받으면 딱 하나만 따집니다.
    이거 망치면, 지금 되돌릴 수 있나.

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

    https://datacook.tistory.com/156

     

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

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

    datacook.tistory.com

     

    728x90
    반응형
Designed by Tistory.