구글이 Gemini 3.7 Flash를 발표한 지 불과 3주 만에 Gemini 3.8 Flash를 내놨다. 코딩·추론·에이전트 작업 성능을 다시 한 번 끌어올렸고, 장기 소프트웨어 엔지니어링 벤치마크 DeepSWE v1.1에서는 대형 프론티어 모델 대부분을 앞질렀다. 함께 공개한 Gemini 3.8 Flash Cyber는 취약점 탐지와 자동 패치에 특화됐는데, 구글 내부 테스트에서 기존 상용 모델 대비 2.6배 더 정확한 패치 코드를 생성했다고 테크월드가 보도했다.
여기서 잠깐 멈춰야 한다. 모델 성능이 빠르게 오른다는 건 좋은 소식이다. 그런데 그 좋은 소식이 팀 입장에서 항상 편한 소식은 아니다. AI가 더 많은 코드를 더 빠르게 쏟아낼수록, 그 코드를 검증하는 부담은 팀에게 고스란히 쌓인다. 모델은 3주 만에 업그레이드되지만, 팀의 리뷰 역량은 3주 만에 업그레이드되지 않는다.
이 문제를 정면으로 건드린 사례가 하나 있다. 개발자 Urjit Upadhyay가 dev.to에 공개한 Proofline이라는 순수 Python 정적 분석 도구다. Zero Dependency Hackathon 2026 출품작인데, 출발점이 흥미롭다. "AI 생성 코드를 리뷰하다 보니 기존 린터가 잡지 못하는 게 있더라." 기존 린터는 문법 오류, 포매팅, 미사용 변수 같은 걸 잡는다. 근데 Proofline이 던지는 질문은 다르다. "이 변경의 blast radius는 얼마나 되고, 우리는 그걸 얼마나 확신할 수 있나?"
Proofline은 Python 표준 라이브러리의 ast 모듈만으로 코드를 파싱해 함수·클래스·호출 관계를 추적한다. NetworkX 없이 인접 리스트로 호출 그래프를 직접 구현했고, GitPython 없이 SHA-256 해시 비교로 변경 파일을 감지한다. 기술적 재치보다 더 눈에 띄는 건 설계 원칙이다. 동적 디스패치처럼 정적 분석으로 확신할 수 없는 케이스에 대해 도구는 결과를 PROVEN, INFERRED, UNKNOWN 세 등급으로 구분해 표시한다. 확실하지 않으면 확실한 척하지 않는다. 이게 AI 생성 코드 검증 도구가 가져야 할 태도의 핵심이다.
도구 하나로 모든 걸 해결할 수 없다는 건 Proofline 개발자 본인도 인정한다. 메타프로그래밍이 많거나 런타임 동작에 의존하는 프로젝트에서는 정적 분석의 한계가 명확하다. 그럼에도 이 접근이 의미 있는 이유는, AI 생성 코드 리뷰에 '변경 영향 범위'라는 새로운 레이어를 추가했기 때문이다. Ruff나 Flake8이 코드의 형식을 보는 도구라면, Proofline은 코드의 파장을 보는 도구다. AI-First 워크플로우에서 두 종류의 게이트가 모두 필요하다.
그런데 도구를 아무리 잘 갖춰도 조직이 따라오지 않으면 반쪽짜리다. KB국민은행의 사례가 그래서 흥미롭다. 국민은행은 이환주 행장을 포함한 경영진 50여 명을 대상으로 Microsoft Copilot 실습 교육을 직접 설계해 진행했다. 외부 위탁 없이, 2027년 사업계획 초안을 AI와 함께 작성하는 실전형 프로젝트로 구성했다. 행장이 직접 손으로 프롬프트를 입력했다는 게 핵심이다.
이환주 행장의 말이 정확하다. "리더가 먼저 AI를 실제 업무에 활용하고 효과를 체감해야 조직 전체에 AI 활용 문화가 빠르게 확산될 수 있다." AI 전환 프로젝트가 실패하는 가장 흔한 패턴 중 하나가 현장 직원들에게만 도구를 쥐여주고 경영진은 보고서로 받아보는 구조다. 이 경우 도구는 도입되지만 문화는 바뀌지 않는다. 국민은행이 선택한 하향식(Top-Down) 접근은 그 반대다. 국민은행은 여기서 멈추지 않고 사업그룹별 AI 전담 조직 'AI CoE'를 신설하고, 조직·개인 평가에 AI 활용 측정지표를 반영했다. 온보딩이 아니라 내재화를 목표로 설계한 것이다.
세 가지 소식을 나란히 놓으면 하나의 흐름이 보인다. 모델 성능 향상 → AI 생성 코드의 검증 필요성 증가 → 조직 전체의 AI 역량 내재화. 이건 순서대로 일어나는 게 아니라 동시에 대응해야 하는 문제다. Gemini 3.8이 더 많은 코드를 더 빠르게 만들어내는 지금, 팀은 그 코드의 blast radius를 추적할 도구를 갖추고 있는가? 그리고 그 도구를 실제로 쓰게 만드는 문화가 조직 안에 자리 잡고 있는가?
테크 리드로서 솔직하게 말하자면, 모델 벤치마크는 참고하되 거기에 흥분하는 시간을 줄이고 검증 파이프라인 설계에 그 에너지를 쏟는 게 맞다. AI가 만든 코드를 AI가 검증하는 루프(Gemini 3.8 Flash Cyber의 방향)는 분명히 가능성이 있다. 하지만 그 루프가 신뢰할 수 있으려면 PROVEN과 INFERRED와 UNKNOWN을 구분하는 판단력이 팀 안에 먼저 쌓여야 한다. 도구는 팀의 판단력을 대체하는 게 아니라 확장하는 것이다.
AI 코드가 많아질수록 팀이 먼저 바꿔야 할 건 워크플로우가 아니다. AI가 만든 것과 우리가 확신하는 것 사이의 간극을 직시하는 습관이다. 그 습관을 도구로 보조하고, 문화로 굳히는 것 — 그게 AI-First 팀 리빌딩의 실제 순서다.