같은 날 만든 두 기능(회의록 액션 아이템 추출, 미팅 브리핑 체크리스트 수정)이 같은 파일을 공유하고 있었습니다. 커밋을 의미 단위로 나누기 위해 "관련 없는 코드를 임시로 지웠다가, 커밋하고, 다시 복원한다"는 방식을 썼습니다. 복원 후에는 타입체크(tsc --noEmit)만 확인하고 배포로 넘어갔습니다.
실서비스에서 "미팅 브리핑 체크리스트에 수정 버튼이 안 보인다"는 걸 직접 눈으로 확인하고서야 문제를 발견했습니다. 원인은 커밋 분리 과정에서 "임시로 지웠던 코드"가 실제로는 복원되지 않은 채 그대로 커밋된 것이었습니다. 이후 원칙에 "복원 직후 반드시 git diff로 변경량을 재확인한다"는 절차를 추가했습니다.
같은 날 두 가지 기능을 만들었습니다. 회의록 액션 아이템 추출 기능과, 미팅 브리핑 체크리스트 수정 기능이었습니다. 두 기능이 같은 파일을 함께 건드리다 보니, 커밋을 의미 단위로 나누는 과정에서 "관련 없는 코드를 임시로 지웠다가, 커밋하고, 다시 복원한다"는 방식을 썼습니다. 복원 후에는 타입체크(tsc --noEmit)만 확인하고 배포로 넘어갔습니다.
문제는 복원이 온전히 되지 않았다는 사실을 아무도 몰랐다는 데 있었습니다. 타입체크는 문제없이 통과했습니다. 코드 문법 자체에는 오류가 없었기 때문입니다. 그대로 배포까지 나갔습니다.
발견은 실서비스 화면을 직접 확인하면서 이루어졌습니다. "미팅 브리핑 체크리스트에 수정 버튼이 안 보인다"는 걸 눈으로 본 것입니다. 배포 로그도, 빌드 로그도 모두 정상이었습니다. 처음에는 캐시 문제라고 생각해 하드 리프레시와 시크릿 창까지 확인했지만 변함이 없었습니다.
원인을 추적해보니, 커밋을 분리하는 과정에서 "임시로 지웠던 코드"가 실제로는 복원되지 않은 채 그대로 커밋된 것이었습니다. git diff --stat으로 확인했을 때, 원래는 파일 두 개가 함께 바뀌어야 했는데 파일 하나만 변경된 것으로 나온 게 결정적인 단서였습니다.
이 일로 다시 확인한 사실이 있습니다. AI 협업 도구가 "완료했습니다, 검증도 통과했습니다"라고 보고하더라도, 그 검증이 정말로 확인하려던 것을 확인했는지는 별개의 문제입니다. 타입체크는 "문법이 맞는가"를 확인할 뿐, "내가 의도한 코드가 실제로 거기 있는가"는 확인해주지 않습니다.
이후로는 "임시 제거 → 커밋 → 복원" 방식을 쓸 때, 복원 직후 반드시 git diff로 변경량을 다시 확인하는 절차를 원칙에 추가했습니다. 이 워크어라운드 자체를 없앨 필요는 없었습니다. 다만 복원이 끝난 직후, 커밋 전에 변경 라인 수가 원래 의도한 규모와 맞는지 확인하는 단계 하나만 추가하면 동일한 사고를 막을 수 있었습니다. 보고를 그대로 믿는 대신, 직접 눈으로 확인하는 습관이 하나 더 늘었습니다.
타입체크는 문법이 맞는지를 확인할 뿐, 의도한 코드가 실제로 그 자리에 있는지는 확인해주지 않습니다. git diff --stat으로 확인했을 때 원래 파일 두 개가 함께 바뀌어야 했는데 파일 하나만 변경된 것으로 나온 게 결정적인 단서였습니다. AI 협업 도구가 "완료했습니다, 검증도 통과했습니다"라고 보고하더라도, 그 검증이 실제로 확인하려던 것을 확인했는지는 별개의 문제라는 걸 다시 확인한 사건이었습니다.
"임시 제거 → 커밋 → 복원" 워크어라운드 자체를 없앨 필요는 없습니다. 다만 복원이 끝난 직후, 커밋 전에 git diff로 변경 라인 수가 원래 의도한 규모와 맞는지 확인하는 단계 하나만 추가하면 동일한 사고를 막을 수 있습니다. 이 검증 습관은 특정 프로젝트에 국한되지 않고, 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 스토리텔링 소재로 활용