Ashby가 말한 AI 개발, 검증이 새 생산성이다

절반 이상 AI 코드, 하지만 핵심은 비율이 아니다

Ashby Engineering의 AI, Ashby Engineering, and the Future는 2026년 6월 2일 Colin Howe가 쓴 글이다. Ashby는 2025년 8월 이후 production system에 들어가는 신규 코드의 절반 이상이 AI-generated였고, 고객 이슈는 대체로 안정적이었다고 밝혔다. 이 문장은 많은 팀이 보고 싶어 하는 성공 지표다. 하지만 글의 핵심은 "AI가 코드를 많이 쓴다"가 아니라 "검증과 판단의 비중이 커진다"다.

Ashby는 AI가 syntax, glue code, keystrokes 같은 기계적 부분을 가져가고, 엔지니어의 역할은 더 좋은 판단으로 이동한다고 본다. 글은 AI 사용을 강제하지 않고 token usage도 측정하지 않는다고 설명한다. 그 이유는 사용량 KPI가 slop을 유도할 수 있기 때문이다. 이 대목은 한국 기업의 AI 도입에도 중요하다. 대시보드에 "AI 사용률"만 올리면 팀은 실제 품질보다 사용 흔적을 최적화한다.

Weave 채용공고가 보여준 AI 개발 측정 시장, 지루한 언어가 AI 코딩에 강한 이유, Constraint Decay, 코딩 에이전트의 구조 망각 문제는 AI 코딩의 품질 문제가 단순 프롬프트 문제가 아님을 보여줬다. Ashby의 글은 그 운영 답안에 가깝다.

sidekick과 delegate를 구분한다

Ashby는 LLM 사용 방식을 sidekick과 delegate로 나눈다. sidekick mode에서는 AI가 codebase 탐색, 정보 요약, 세부 구현을 돕지만 인간이 대부분의 결정을 내린다. database migration, candidate data handling, security-sensitive code, architecture decision 같은 고위험 작업은 이 모드가 맞다. delegate mode는 blast radius가 작은 prototyping, local tools, operations tools에 적합하다.

이 구분은 단순한 문화 문구가 아니다. AI 코딩의 실제 위험은 모델이 틀리는 것이 아니라 그럴듯하게 틀리는 데 있다. Ashby 글은 "You are responsible for what you ship"이라고 강조한다. AI가 전체 PR을 만들었어도 책임은 엔지니어에게 남는다. 한국 기업에서 이 원칙이 흐려지면 장애 때 책임 소재가 불명확해지고, AI 도입은 곧 감사 리스크가 된다.

Ashby의 인프라는 코드보다 맥락을 중시한다

Ashby는 모든 엔지니어에게 Cursor, Claude Max, Codex, 여러 agent framework 접근 경로를 제공한다고 설명한다. 동시에 linters, DangerJS, CodeRabbit, 자체 코드 리뷰 도구를 함께 쓴다. 특히 흥미로운 것은 GitHub metadata를 SQLite DB로 복제한 저장소다. issues, pull requests, comments를 모두 넣어 LLM 도구가 "이런 버그를 본 적이 있는가" 같은 질문에 GitHub API보다 빠르고 정확하게 답하도록 한다.

이것은 AI 개발 도구의 승부처가 model prompt만이 아니라 context infrastructure임을 보여준다. 좋은 skill 파일, 검색 가능한 과거 의사결정, PR과 이슈의 구조화 데이터가 없으면 AI는 그럴듯한 평균 답을 낸다. 좋은 맥락이 있으면 팀의 과거 판단을 재사용할 수 있다.

Ashby는 customer issue triage에도 AI를 쓴다. 내부 모델이 이슈를 제품팀에 라우팅하고, Claude Code가 incoming bug를 검토해 원인 후보, 상담할 사람, 탐색 경로를 보고한다. 어떤 경우에는 지원팀이 몇 시간 걸릴 일을 10분 안에 해결했다고 한다. 이는 AI가 제품 개발만이 아니라 support, product, engineering 사이의 흐름을 바꾸고 있음을 뜻한다.

검증이 새 생산성이다

글의 가장 실무적인 결론은 "writing is now cheap, verification is the bottleneck"이다. Ashby는 static analysis, frontend unit tests, performance, PII handling, error handling, security에 초점을 둔 자동 리뷰가 더 중요해진다고 본다. 인간 리뷰어는 모든 줄을 보는 human linter가 아니라 변화가 말이 되는지, 고위험 영역이 무엇인지, 추상화가 맞는지를 봐야 한다.

한국 개발 조직은 여기서 두 가지를 바로 적용할 수 있다. 첫째, AI 코딩 도입의 예산을 모델 구독에만 쓰지 말고 테스트 선택, observability, feature flag, 자동 rollback에 써야 한다. 둘째, 리뷰 규칙을 "AI가 쓴 코드는 더 엄격히"가 아니라 "위험도가 높은 변경은 더 엄격히"로 바꿔야 한다. Copilot 토큰 과금, 코딩 에이전트 비용의 현실화에서 비용 문제가 보였다면, Ashby의 글은 품질 운영비를 보여준다.

자주 묻는 질문

Q1: AI 코드 비율을 KPI로 삼아도 되나요?

A: 보조 지표로는 가능하지만 핵심 KPI로는 위험하다. 사용량을 압박하면 품질보다 흔적을 최적화할 수 있다.

Q2: sidekick과 delegate의 차이는 무엇인가요?

A: sidekick은 인간이 결정을 주도하고 AI가 보조하는 방식이다. delegate는 실패 비용이 낮은 작업을 AI에 더 넓게 맡기는 방식이다.

Q3: Ashby가 강조한 인프라는 무엇인가요?

A: linters, DangerJS, CodeRabbit, 자체 리뷰 도구, repo 내 skill 파일, GitHub metadata를 SQLite로 복제한 맥락 저장소다.

Q4: 한국 기업이 따라 하기 어려운 점은 무엇인가요?

A: 도구 접근권보다 문화가 어렵다. 엔지니어가 AI 결과를 이해하고 책임지는 구조가 없으면 도구만 늘어난다.

Q5: 가장 먼저 투자할 곳은 어디인가요?

A: 테스트 선택, 위험 기반 리뷰, 관측성, feature flag, AI가 참조할 수 있는 사내 문서와 이슈 데이터의 구조화가 우선이다.