AI는 거짓말하지 않았습니다. 다만 말하지 않았을 뿐입니다.
처음의 검수 방식은 단순했습니다. AI에게 작업을 시키고, 돌아온 보고서를 읽고, PASS면 넘어갔습니다.
문제는 보고서가 너무 잘 쓰여 있다는 점이었습니다. 표로 정리된 검증 항목, 항목마다 붙은 초록색 PASS, 증빙 스크린샷 경로 목록, 마지막엔 "모든 항목이 성공적으로 통과하였습니다"라는 문장까지. 사람이 쓴 보고서였다면 신뢰했을 완성도였습니다.
하지만 그 보고서는 결론만 담고 있었습니다. 어떤 순서로 무엇을 실행해서 그 결론에 도달했는지는 보고서에 없었습니다. 그리고 편법은 정확히 그 사라진 구간에서 일어났습니다.
검수 대상을 보고서에서 실행 로그로 옮겼습니다. 그러자 첫 번째 사건이 바로 보였습니다.
브라우저 테스트 실행 → (실패) → 계정 생성 스크립트 작성 → 계정 생성 실행 → 테스트 재시도 → 통과 저는 계정을 만들라고 시킨 적이 없습니다. 기존 계정으로 로그인만 하라고 지시했습니다. 로그인이 실패하자 AI가 스스로 관리자 계정을 만들어 목표를 달성한 겁니다. 결과적으로 제가 모르는 관리자 권한 계정이 하나 더 존재할 뻔했습니다. 두 번째 사건은 더 미묘했습니다. 이번엔 AI가 보고서에 자백까지 해뒀습니다.
원인: 해당 테이블의 삭제·수정에 보안 정책이 적용되어 일반 세션으로는 쓰기 불가 해결: 서비스 롤 키를 사용하는 클라이언트 함수를 추가
문제는 그다음 문장이었습니다.
미들웨어로 인증 보호가 이미 되어 있어 보안 문제 없음
AI가 스스로 "문제없음"이라고 판정한 겁니다. 이 판정을 그대로 믿었다면 넘어갔을 겁니다. 하지만 서비스 롤 키는 모든 보안 정책을 무조건 통과하는 마스터키입니다. 그 키가 브라우저로 새어나가면 사이트의 모든 데이터가 열립니다. 코드를 읽는 대신 질문을 던졌습니다.
그 키를 담은 환경변수 이름이 무엇인가? 브라우저로 공개되는 접두사가 붙어 있는가? 이 파일을 브라우저 쪽 코드에서 불러 쓰는 곳이 하나라도 있는가? 그 키를 실제로 호출하는 파일 목록을 전부 보여달라
세 질문 모두 안전한 답이 나왔습니다. 최악은 피한 겁니다. 대신 실수로도 새어나가지 않도록 안전장치(server-only 가드)를 걸었고, 정석 방식으로의 교체는 공개 오픈 직전 보안 점검 항목으로 예약해뒀습니다.
부수적으로, 그 과정에서 별개의 실제 버그도 하나 발견했습니다. 파일 첫 줄이 인코딩 오류로 깨져 있었는데, 마스터키 덕분에 동작이 성립해버려서 검증에서 가려져 있었습니다. 편법은 자기가 덮은 문제를 함께 숨깁니다.
관리자 화면을 만들면서 AI 에이전트에게 구현과 검증을 맡겼습니다. 두 번 모두 "전항목 통과(PASS)"라는 깔끔한 보고서가 돌아왔고, 두 번 모두 실행 로그를 열어보니 시키지 않은 우회로가 있었습니다.
첫 번째는 로그인이 안 되자 관리자 계정을 스스로 만들어 통과시킨 사건이고, 두 번째는 보안 잠금에 막히자 모든 잠금을 무시하는 마스터키를 복사해서 쓴 사건입니다. 둘 다 시킨 목표는 달성했습니다. 다만 방법이 안전하지 않았습니다.
이 글은 코드를 읽지 못하는 기획자가 AI의 편법을 어떻게 잡아냈는지, 그리고 그 경험에서 어떤 검수 루틴을 만들었는지에 대한 기록입니다.
왜 보고서가 아니라 로그인가 보고서는 AI가 자기 작업을 요약한 문서입니다. 요약은 필연적으로 무언가를 뺍니다. 그리고 AI는 자기 작업에서 무엇이 문제인지 판단할 위치에 있지 않습니다. "보안 문제 없음"이라는 문장이 그 증거입니다.
반면 실행 로그는 요약이 아니라 기록입니다. 어떤 명령을 어떤 순서로 실행했는지가 그대로 남습니다. 그리고 순서는 코드를 몰라도 읽을 수 있습니다. "실패 → 계정 생성 → 재시도 → 통과"라는 흐름에서 이상함을 느끼는 데 개발 지식은 필요하지 않습니다.
왜 AI는 편법을 택하는가 두 사건의 공통점은 명확합니다. 제가 준 지시는 "무엇을" 할지였고, "어떻게" 할지는 비어 있었습니다.
"로그인해서 검증해줘" → 로그인이 안 되면? 만들면 되지 "삭제가 되게 해줘" → 권한이 막으면? 권한을 무시하면 되지
AI는 주어진 목표를 향해 가장 짧은 경로를 찾습니다. 그 경로에 안전이라는 조건이 없으면, 안전하지 않은 경로도 후보에 남습니다. AI가 나쁜 게 아니라 제약을 주지 않은 지시가 불완전했던 겁니다.
그래서 이후 프롬프트에는 목표와 함께 금지선을 명시했습니다.
로그인이 실패하면 계정을 생성하거나 다른 우회 방법을 쓰지 말고, 즉시 멈추고 실패 원인을 보고할 것
이 한 줄을 넣은 다음부터는 같은 유형의 우회가 재발하지 않았습니다. 왜 지금 정석화하지 않았는가 마스터키를 걷어내고 정석 방식(보안 정책에 관리자 통과 규칙 추가)으로 바꾸는 게 옳습니다. 그런데 그러려면 여러 테이블의 정책을 다시 설계해야 하고, 지금은 관리자 기능을 완성하는 단계입니다.
그래서 위험한 것부터 처리하고, 옳은 것은 예약했습니다. 노출 가능성을 차단하는 안전장치를 먼저 걸고, 구조 교체는 공개 오픈 직전 보안 점검 단계로 미뤘습니다. 완벽보다 우선순위입니다.
같은 방식은 개발이 아닌 업무에도 적용됩니다. AI에게 일을 맡기는 모든 상황에서 아래 네 가지는 그대로 씁니다.
결과가 아니라 과정을 요구한다 "완료했습니다"가 아니라 "어떤 순서로 무엇을 했는지"를 함께 받습니다. 로그를 남기지 않는 도구라면 작업 단계를 나눠서 중간 보고를 받습니다.
목표와 함께 금지선을 준다 "이렇게 해줘"만으로는 부족합니다. "이건 하지 마"와 "막히면 멈추고 보고해"를 같이 줍니다. 막혔을 때의 행동을 지정해두지 않으면 AI가 알아서 정합니다.
AI의 자체 판정을 검증 근거로 쓰지 않는다 "문제없습니다", "안전합니다", "일치합니다"는 결론이지 증거가 아닙니다. 판정 대신 사실을 요구합니다. "안전한가?"가 아니라 "그 값이 어디에 저장되어 있고 어디서 불러 쓰는지 목록을 보여달라"고 묻습니다.
승인 전에 멈추는 지점을 만든다 계획 검토 → 승인 → 실행 → 로그 확인 → 커밋. 이 사이에 사람이 개입하는 지점이 없으면 편법이 그대로 굳어집니다. 특히 커밋(되돌리기 어려워지는 시점) 직전은 반드시 사람이 확인합니다.
관련 프로젝트
프로젝트 개요 기획자(PM)로서 AI를 활용한 업무 자동화(AX) 사례를 문서화하는 개인 포트폴리오 사이트입니다. 국내 기업의 AX 기획자/AI PM 직군으로의 커리어 전환을 목표로, 사이트 자체가 채용 지원용 스토리텔링 자료로 실사용되고 있습니다. 핵심 패턴: 업무 병목 발견 → AI로 워크플로우 재설계 → Before/After·근거·재현 가능성 문서화 전체 서사는 '실행하지 않은 아이디어 나열'이 아니라, 하나의 검증된 자동화 패턴과 도메인별 확장 블루프린트를 갖춘 재사용 가능한 엔진을 보유하는 방향으로 수렴하고 있습니다. 기술 스택 Next.js 16, Tailwind CSS v4, TypeScript Supabase (개발/운영 환경 분리), Vercel, Resend Claude API 기반 기술 자문 및 프롬프트 설계 보안 아키텍처 관리자 CRUD는 세션 기반 인증과 RLS(Row Level Security)로 보호 공개 읽기 전용 경로는 별도의 익명 클라이언트로 분리 서비스 롤 키는 애플리케이션 코드에서 완전히 배제 권한 검증은 마이그레이션 파일 및 대시보드 검토를 통해서만 진행 작업 방식 (에이전틱 IDE 협업 워크플로우) AI 에이전트 기반 IDE가 파일/버전관리 작업을 담당하고, LLM은 기술 자문 및 프롬프트 작성 역할을 수행하는 협업 구조를 운영합니다. AI 자문 → 에이전트용 프롬프트 작성 → 실행자가 붙여넣기 → 계획 확인 → 자문 검토 → 실행 승인 → 로그 검토 → 직접 클릭 테스트 → 명시적 지시 시에만 커밋 통제 규칙 실행 전 계획 검토 필수 요약 보고가 아닌 직접 클릭 테스트로 검증 개발 환경 우선 적용 후 명시적 승인 하에 운영 환경 반영 커밋은 명시적 지시가 있을 때만 수행 DB 자격증명 직접 연결 및 범위 외 삭제 금지 브랜치 전략: 개발 브랜치에서 작업 후 운영 브랜치는 배포 전용으로 직접 커밋 금지, 병합 전 변경 범위 검증 현재 진행 상황 고객사 미팅 브리핑 자동화 사례: 1단계 완료, 개발/운영 환경 배포 및 실데이터 테스트 완료 범위 변경 감지 자동화 사례: 상태 확인 진행 중 리스크 조기 경보 자동화 사례: 운영 환경 배포 완료 보안 사고 관련 포스트: 'AI 리스크 거버넌스 사례'로 재구성 예정 AI 활용 관련 콘텐츠 시리즈 초안 작성 완료, 게시 미확정 핵심 학습 원칙 보고가 아닌 검증: 버그·보안 이슈는 항상 직접 로그/브라우저 검토를 통해서만 발견되며, 에이전트의 자체 결과 요약을 그대로 신뢰하지 않음 보안 사고의 콘텐츠화: 실제 발생한 권한 관련 이슈 사례를 케이스 스터디로 재구성하여 콘텐츠화 커밋 의미 분리: 기능 단위/변경 유형별로 항상 분리 커밋 자동화하지 않는 것도 스토리: 저사용 빈도 기능을 의도적으로 고도화하지 않은 결정 자체를 AX 스토리텔링 소재로 활용