AI 코딩 도구를 팀에 도입하고 나서 가장 먼저 나오는 질문은 대개 이것이다. "속도가 얼마나 빨라졌나요?" 그런데 몇 달 지나면 다른 질문이 나온다. "이 코드, 누가 책임지나요?"
dev.to에 공개된 두 개의 실험이 이 질문에 각각 다른 각도로 답한다. 하나는 AI 생성 코드의 사후 품질 게이트를 설계한 aislop 프로젝트고, 다른 하나는 코드 생성 이전 단계인 명세(specification)를 승인 게이트로 삼은 Specification-Driven Development(SDD) 실험이다. 두 접근은 방향이 반대처럼 보이지만, 결론은 같은 곳을 가리킨다. AI가 코드를 생성하는 워크플로우에서 품질은 자동으로 보장되지 않으며, 그것을 설계하는 건 여전히 사람의 몫이다.
핵심 이슈: AI 생성 코드의 '조용한 실패'
aislop을 만든 이유는 단순하다. AI가 작성한 코드는 "명백히 틀린" 경우보다 "그럴듯해 보이지만 문제인" 경우가 훨씬 많다. 컴파일은 된다. 테스트도 통과한다. 리뷰어의 눈에도 이상해 보이지 않는다. 그런데 프로덕션에서 에러가 조용히 삼켜지고, 타입 캐스팅이 as any로 묻히고, TODO 스텁이 실제 데이터처럼 동작한다.
aislop이 포착하는 패턴들은 대부분 "에이전트가 프롬프트를 완료하는 데 최적화"된 결과물이다. 예외 처리 블록이 빈 배열을 반환하도록 작성되어 있으면, 동기화 실패와 데이터 없음이 동일하게 보인다. 기존 린터는 이 차이를 구분하지 못한다. 범용 린터는 인간이 작성한 코드의 패턴을 기준으로 설계되어 있기 때문이다. aislop은 이 틈새를 좁히기 위해 AI 에이전트 특유의 실패 패턴만 전담해서 탐지한다.
맥락 해석: 게이트의 위치가 비용을 결정한다
SDD 실험은 다른 방식으로 같은 문제를 풀었다. 개발자 Oleg Timkiv가 공개한 이 실험의 핵심 전제는 이렇다. 코드가 아니라 명세가 개발의 첫 번째 산출물이어야 한다. 분석 → 설계 → 구현의 세 단계를 두고, 각 단계 사이에 인간 승인 게이트를 강제로 삽입했다. AI는 다음 단계를 진행하기 전에 반드시 멈춰야 한다.
실험에서 가장 의미 있는 장면은 분석 단계가 리젝된 순간이었다. AI가 분석 문서에 EF Core, PostgreSQL 같은 구체적인 구현 기술을 명시해버린 것이다. 이건 '무엇을' 해야 하는가가 아니라 '어떻게' 할 것인가를 분석 단계에서 결정해버린 셈이다. 수정에 걸린 시간은 몇 분. 만약 이 결정이 코드 레벨에서 발견됐다면 서비스를 재설계하는 비용이 됐을 것이다.
두 실험을 나란히 놓으면 게이트의 위치가 비용을 결정한다는 원칙이 선명해진다. aislop은 코드 생성 이후, PR 머지 이전에 게이트를 설치한다. SDD는 코드 생성 이전, 명세 승인 단계에 게이트를 설치한다. 이상적인 AI-First 워크플로우라면 두 게이트를 모두 운영해야 한다. 명세 레벨에서 설계 오류를 잡고, 코드 레벨에서 AI 특유의 잔재를 걸러낸다.
시사점: 개발자의 역할이 이동하고 있다
SDD 실험은 개발자의 역할 변화에 대해서도 솔직하다. 오늘의 개발자는 코더가 아니라 요구사항을 분석하고, 기술 명세로 번역하고, AI와 협업하면서 아키텍처 정합성을 유지하는 역할로 확장되고 있다. 소규모 팀에서는 분석가, 아키텍트, QA의 경계가 흐려지고 개발자가 그 전부를 감당하게 된다.
aislop이 CI 파이프라인에 삽입되는 구조도 같은 맥락이다. aislop ci --changes --base origin/main을 CI에 연결하는 건 기술적으로 간단하다. 하지만 그 전에 팀이 먼저 합의해야 할 것이 있다. 어떤 패턴을 허용하고 어떤 패턴을 블록할 것인지, 자동 수정을 허용할 범위는 어디까지인지, 게이트를 통과 못 한 코드의 처리 책임은 누구에게 있는지. 도구는 그 합의를 집행할 수 있지만, 합의 자체는 팀이 설계해야 한다.
한 가지 냉정한 지적도 필요하다. SDD 실험 자체는 아직 성숙한 방법론이 아니다. 승인과 STALE 처리가 수동 컨벤션에 의존하고 있고, 테스트 없이는 인수 기준이 문서로만 남는다는 한계를 저자 스스로 인정한다. aislop 역시 프로덕션 도입 전에 팀의 코드 스타일과 얼마나 충돌하는지 검증이 필요하다. 두 도구 모두 '즉시 도입해서 해결'이 아니라 '팀 맥락에 맞게 조율해야 할 구조'에 가깝다.
전망: 품질 설계는 AI 워크플로우의 필수 레이어다
AI 코딩 도구는 속도를 팔지만, 품질을 팔지는 않는다. 속도는 에이전트가 책임지고, 품질은 워크플로우 설계가 책임진다. aislop이 말하는 것처럼 "AI 코딩 에이전트는 여기 남아 있을 것이므로, 코드 품질 도구도 그에 맞게 진화해야 한다"는 전제는 이제 팀 단위 설계 원칙이 됐다.
앞으로 AI-First 팀에서 테크 리드가 설계해야 할 품질 레이어는 세 층위로 나뉜다. 명세 단계의 승인 게이트, 코드 생성 이후의 AI 특화 정적 분석, 그리고 이 모든 것을 뒷받침하는 검증 가능한 테스트. 이 세 층위 없이 AI 도구를 팀에 푸는 것은 속도를 얻는 대신 품질 부채를 나중에 갚겠다는 선택이다. 그 부채는 조용히, 그리고 누적적으로 쌓인다.