AI 코딩 어시스턴트를 팀에 도입하고 나서 가장 먼저 맞닥뜨리는 벽이 두 개 있다. 하나는 AI가 어제 배운 걸 오늘 또 모른다는 것, 다른 하나는 파이프라인이 터지면 여전히 사람을 깨운다는 것이다. 둘 다 '자동화'라는 단어 아래 묶이지만, 해결 구조는 전혀 다르다. 그리고 이 두 문제를 동시에 풀지 않으면, AI-First 워크플로우는 생산성 도구가 아니라 관리 부채로 쌓인다.
세션이 끝나면 AI는 백지가 된다
dev.to에 공개된 mirrorai 소개 글이 짚는 문제는 단순하지만 날카롭다. Cursor나 Claude Code로 새 기능을 요청하면, AI는 프로젝트가 6개월 동안 쌓아온 컨벤션을 모른다. useRequest() 훅 대신 axios를 직접 임포트하고, 컴포넌트 이름은 제멋대로, 라우터 등록은 누락된다. 문제는 AI 도구가 나빠서가 아니다. 매 세션이 제로베이스에서 시작하기 때문이다. 프롬프트를 더 잘 쓰는 건 해결책이 아니다. AI에게 프로젝트의 영구적인 기억을 심어주는 구조가 필요하다.
mirrorai가 제안하는 접근은 실용적이다. npx mirrorai install 한 줄로 설치하고, /mirror-init을 실행하면 AI가 코드베이스를 직접 분석한다. 파일 패턴이 3회 이상, 파일당 50줄 이상, 80% 이상 유사도로 반복되면 규칙으로 추출된다. 결과물은 Cursor용 .cursorrules, Claude Code용 CLAUDE.md, GitHub Copilot용 .github/copilot-instructions.md 등 각 도구에 맞는 규칙 파일이다. 외부 서버도 없고, API 키도 없다. 분석은 기존 AI 구독 위에서 로컬로 돌아간다.
특히 주목할 부분은 Auto-Execute Rules다. "리스트 페이지 추가해줘"라는 자연어 요청이 들어오면, AI는 CLAUDE.md를 참조해 UserList.vue를 레퍼런스로 쓰고, useRequest()로 데이터를 패칭하고, 라우터에 자동 등록한다. 명시적 지시 없이도 컨벤션이 적용된다. 팀 온보딩 관점에서도 의미가 크다. 신규 팀원이 프로젝트 구조를 파악하기 전에도, AI가 먼저 올바른 패턴으로 코드를 생성해준다. 컨텍스트 지속성이 팀의 암묵지를 외부화하는 도구가 되는 셈이다.
파이프라인이 스스로 고쳐지는 구조
컨텍스트 문제를 풀었다고 해도, 파이프라인 장애는 별개의 전선이다. Microsoft가 Azure Infrastructure Blog를 통해 공개한 Self-Healing CI/CD 아키텍처는 이 문제를 정면으로 다룬다. 핵심은 세 단계 루프다: Observe → Analyze → Act.
작동 방식은 이렇다. Azure DevOps 파이프라인이 실패하면 웹훅이 Azure Function으로 텔레메트리와 빌드 로그를 전송한다. Azure AI Foundry 엔드포인트를 통해 GPT-4o가 로그를 분석하고, 인프라 컨텍스트 안에서 실패 원인을 추론한다. 단순한 에러 코드 매칭이 아니다. "connection refused"라는 메시지가 왜 발생했는지, 백엔드 풀 설정 오류와 어떻게 연결되는지를 추론할 수 있다. 분석 결과는 GitHub PR이나 Azure DevOps 파이프라인 업데이트로 자동 제출된다. 사람은 최종 승인만 하면 된다.
Microsoft가 제시한 구체적 사례는 레거시 로드밸런서 설정을 Azure ILB 규칙으로 마이그레이션하는 시나리오다. 백엔드 풀 IP 한 글자 오타가 배포 전체를 날리는 상황에서, 에이전트가 파이프라인 실행 전에 설정을 스캔하고 불일치를 사전에 잡아낸다. 사후 복구가 아니라 사전 차단이다. 팀이 수일씩 허비하던 트라이얼-앤-에러 디버깅이 구조적으로 사라진다.
두 축을 함께 설계해야 하는 이유
여기서 냉정하게 짚어야 할 것이 있다. 두 도구 모두 전제 조건이 있다.
mirrorai는 일관된 패턴이 이미 코드베이스에 존재할 때 작동한다. 파일마다 다른 방식으로 구현돼 있다면, 분석할 패턴 자체가 없다. 규칙 파일을 생성해도 컨벤션이 충돌하면 AI는 여전히 헤맨다. 역설적으로, mirrorai를 제대로 쓰려면 먼저 코드베이스를 정리해야 한다. 도입 전에 현재 코드베이스의 일관성 수준을 점검하는 게 선행 과제다.
Self-Healing CI/CD는 더 직접적인 전제를 요구한다. Microsoft도 명시적으로 인정했다. "AI 에이전트는 나쁜 엔지니어링 관행을 마법처럼 고치지 않는다—오히려 그것을 더 빠르게 확장한다." 파이프라인이 구조적으로 취약하면, 에이전트는 그 취약성을 더 빠르게 노출시킨다. 테스트 커버리지가 얇으면, 에이전트가 검증 안 된 코드를 더 높은 속도로 배포한다. 이 패턴은 관찰 가능성이 잘 갖춰진 팀에게만 즉각적인 가치를 준다. 로그가 구조화돼 있지 않고, 에러가 컨텍스트 없이 던져진다면, 에이전트가 읽을 신호가 없다.
그리고 Act 단계의 스코프 설계는 신중해야 한다. PR을 여는 에이전트는 복구 가능하다. 프로덕션 파이프라인에 직접 쓰기 권한을 가진 에이전트는 다른 수준의 가드레일을 요구한다. 지금 당장 도입한다면, Act 단계는 PR 생성까지만 위임하고 머지는 사람이 하는 구조가 맞다.
설계 순서가 곧 성패다
두 도구가 함께 가리키는 방향은 하나다. AI-First 파이프라인에서 컨텍스트 지속성과 자가복구는 독립된 기능이 아니라 하나의 설계 문제다. AI가 프로젝트 컨벤션을 기억하지 못하면 코드 품질이 흔들리고, 파이프라인이 그 흔들림을 사람 손으로 잡아야 한다면 자동화의 의미가 없다. 반대로, 파이프라인이 자가복구 루프를 돌아도 AI가 매번 잘못된 코드를 생성하면 고칠 거리만 늘어난다.
실행 순서를 제안하자면 이렇다. 먼저 코드베이스 컨벤션을 정리하고 mirrorai로 규칙을 외부화한다. 그 다음 CI/CD 파이프라인의 관찰 가능성을 높인다—로그를 구조화하고, 에러에 컨텍스트를 붙인다. 그 기반 위에 Self-Healing 루프를 올린다. Act 단계는 PR 생성으로 제한하고, 실제 운용 데이터로 신뢰를 쌓은 뒤 점진적으로 자율성을 확장한다. 도구를 먼저 고르지 말고, 어느 단계에서 어느 결정을 AI에게 위임할지를 먼저 그려야 한다.