gac라는 CLI 도구가 있다. Git diff를 읽어서 Conventional Commits 형식의 커밋 메시지를 자동으로 써준다. fix stuff, update again, pls work—누구나 한 번쯤 본 그 커밋들을 AI가 대신 정리해준다는 아이디어다. 설치는 npm install -g gac-cli 한 줄이면 끝이고, 이후엔 그냥 gac만 치면 된다. 편리하다. 실용적이다. 그리고 바로 이 지점에서 진짜 질문이 시작된다.
AI는 커밋을 쓰고, 코드를 짜고, PR을 올린다. 그런데 팀은 왜 더 힘들어졌나.
2025년 기준 개발자의 84%가 AI 코딩 도구를 쓴다. 그런데 같은 기간 AI 생성 코드에 대한 신뢰도는 40%에서 29%로 오히려 떨어졌다(Stack Overflow Developer Survey 2025, ShiftMag 2025). 채택률은 올라가는데 신뢰도는 내려가는 이 역설—이게 지금 AI-First 전환을 밀어붙이는 모든 팀이 마주한 실제 현실이다. 도구를 도입했는데 팀이 더 피곤해졌다면, 문제는 도구가 아니다. 도구를 둘러싼 시스템이 없는 것이다.
빠른 코드와 좋은 제품 사이의 간극
'바이브 코딩의 환상'이라는 글은 이 간극을 구조적으로 해부한다. AI 코딩의 문제는 "코드를 못 짠다"가 아니다. 정확히는 "실행되는 코드"에 최적화되어 있지, "사람이 원하는 제품"에 최적화되어 있지 않다는 것이다. RLVR 기반 학습 구조에서 AI는 코드가 실행되면 보상을 받는다. 그 결과 과도한 try-except, fallback 로직, 방어 코드가 쌓인다. 겉으로는 돌아가는데 내부는 기술 부채 덩어리인 코드베이스가 만들어진다.
Karpathy가 말한 AJI(Artificial Jagged Intelligence) 개념이 여기서 정확하게 들어맞는다. AI가 잘하는 영역과 못하는 영역의 경계가 들쭉날쭉하다는 뜻인데, 현재 AI의 약한 부분은 코드 문법이 아니라 taste, 제품 감각, 암묵적 상식이다. 세종대왕 맥북 프로 환각처럼, 인간이라면 즉시 알아차릴 '이상함'을 최신 모델도 놓친다. 바둑은 이기면 그만이지만, 소프트웨어는 사람이 돈을 낼 제품이어야 한다. 그 판단을 AI에게 위임할 수 없다는 것이 지금의 현실이다.
신뢰 공백을 메우는 것이 시니어의 새 일
dev.to의 'Harness Engineering Is the New Senior Developer Skill'은 이 문제를 다른 각도에서 짚는다. 개발자가 AI 도구를 설치하고, 코드를 생성하고, 눈으로 훑어보고, 배포한다. 프로토타입엔 통한다. 프로덕션에서 깨진다. 세 번 롤백하면 신뢰가 무너지고, 다섯 번이면 팀리드가 "이거 왜 쓰냐"고 묻기 시작한다. 문제는 모델이 아니다. 모델의 출력을 검증하고, 위험한 행동을 제한하고, 지난 실수를 기억하는 시스템—하네스가 없는 것이다.
시니어 엔지니어의 레버리지 포인트는 지난 6년간 네 번 바뀌었다. 좋은 코드 작성 → 좋은 프롬프트 작성 → 좋은 컨텍스트 큐레이션 → 그리고 지금은 좋은 하네스 구축이다. 각 단계는 이전 단계를 대체하지 않고 흡수했다. 여전히 코드를 잘 써야 하고, 프롬프트도 잘 짜야 한다. 하지만 지금의 레버리지 승수는 하네스 레이어에 있다. LangChain이 같은 모델, 같은 프롬프트, 같은 컨텍스트 윈도우에서 하네스 세 가지만 바꿔 Terminal Bench 2.0 점수를 52.8%에서 66.5%로 끌어올린 사례가 이를 증명한다. 모델이 병목이 아니었다. 하네스가 병목이었다.
테크리드가 지금 당장 설계해야 할 것
하네스를 버전 컨트롤에 커밋하면 팀 전체가 같은 검증 루프, 같은 제약, 같은 메모리를 공유한다. 스태프 엔지니어 한 명의 오후 반나절 작업이 개발자 10명의 매일 컨텍스트 재구축을 대체한다. OpenAI Codex 팀이 엔지니어 3명으로 1,500개 PR을 처리한 원리가 여기 있다.
실용적으로 정리하면 테크리드가 지금 설계해야 할 것은 세 가지다.
첫째, AI 생성 코드의 검증 루프를 시스템화하라. 코드 리뷰가 구현의 버그를 잡는다면, 하네스 리뷰는 구현을 만드는 시스템의 버그를 잡는다. PostToolUse 훅으로 파일 편집 후 ESLint를 자동 실행하는 것처럼, 규칙은 "권고"가 아니라 "강제"가 되어야 한다. CLAUDE.md에 "테스트 먼저 돌려라"고 써놓는 것과, 훅으로 강제하는 것은 압박 상황에서 전혀 다른 결과를 낳는다.
둘째, AI가 못하는 영역을 팀의 설계로 채워라. gac가 커밋 메시지를 자동화하는 것은 좋다. 하지만 어떤 변경이 의미 있는 커밋인지, 그 커밋이 팀의 맥락에서 무엇을 말해야 하는지—그 판단은 아직 사람 몫이다. AI가 "실행 성공"에 최적화되어 있다면, 팀은 "제품 판단"을 명시적으로 설계해야 한다. 코드 리뷰에 "이 코드가 사용자가 원하는 것을 하는가"를 체크리스트로 넣는 것이 그 시작이다.
셋째, AI 도구 도입 이후의 역할을 재정의하라. 개발자가 AI 출력을 눈으로 훑어보고 승인하는 역할로 전락하면 신뢰는 떨어지고 책임은 흐릿해진다. "AI 코드를 검증하는 사람"이 아니라 "AI가 올바른 방향으로 작동하는 시스템을 설계하는 사람"으로 역할을 재정의해야 한다. 이것이 2026년 시니어 엔지니어의 실제 직무 기술서다.
전망: 간극은 줄지만, 판단 설계는 남는다
GPT-5.5, 그 이후 모델들이 나오면서 AI의 제품 감각과 암묵지 간극은 점점 줄어들 것이다. 어쩌면 커밋 메시지뿐 아니라 PR 설명, 아키텍처 결정의 이유까지 AI가 초안을 잡는 날이 생각보다 빨리 올 수 있다. 하지만 그 시점이 오더라도 "무엇을 만들어야 하는가"에 대한 판단 환경을 설계하는 일은 사람이 해야 한다. AI가 실행을 담당하는 세계에서 팀의 경쟁력은 실행 속도가 아니라 판단의 품질에서 결정된다.
AI가 커밋을 쓰는 건 편리하다. 문제는 그 커밋들이 쌓여 만들어지는 코드베이스의 방향이 어디를 향하는가다. 그 방향을 잡는 것—그게 지금 테크리드가 도구 도입 이후에 설계해야 할 진짜 일이다.