AI는 빠르다. 그런데 무엇이 그 속도를 실제로 결정하는가?
DailyMood 팀은 Next.js 15·Supabase·Claude를 조합해 풀스택 무드 트래커를 2스프린트 만에 프로덕션에 올렸다. 99% 테스트 커버리지, 4단계 CI/CD 파이프라인, 실시간 동기화까지. 결과만 보면 AI-assisted development의 교과서 같은 성공 사례다.
그런데 이 팀이 실제로 강조한 건 Claude가 코드를 빠르게 생성했다는 사실이 아니었다. 코드를 한 줄도 쓰기 전에 Claude와 함께 PRD를 작성하고, 스키마를 설계하고, 기술 스택을 확정했다는 점이었다. AI를 쓴 게 아니라, AI를 쓸 수 있는 구조를 먼저 만든 것이다. 데이터 페칭은 컴포넌트 안에 두지 않는다는 아키텍처 규칙 하나가 99% 커버리지를 가능하게 했다. AI가 코드를 빠르게 쓸 수 있었던 건 그 규칙이 먼저 있었기 때문이다.
모델이 문제가 아니었다—인터페이스 설계가 문제였다
코딩 에이전트 벤치마크 세계에서는 매주 GPT vs Claude vs Gemini 비교표가 쏟아진다. 모델이 좋아지면 에이전트 성능이 좋아진다는 암묵적 가정 아래서. 그런데 dev.to에 공개된 harness 분석은 이 가정을 정면으로 깼다. Grok Code Fast가 동일 태스크에서 6.7%에서 68.3%로 점프했다. 모델이 바뀐 게 아니었다. edit tool 포맷 하나를 바꿨더니 10배 성능이 나왔다.
기존 str_replace 방식은 모델이 수정할 텍스트를 공백 한 칸까지 정확히 재현해야 한다. 인덴테이션 하나가 틀리면 편집이 실패한다. 새로운 hashline 방식은 파일을 읽을 때 각 줄에 2~3자리 해시를 붙이고, 모델은 텍스트를 재현하는 대신 해시를 참조해 편집 위치를 지정한다. 결과적으로 Grok 4 Fast의 출력 토큰이 61% 감소했다—실패한 편집을 재시도하느라 태우던 토큰이 사라진 것이다.
이 문제를 인지한 Cursor는 편집을 올바르게 적용하기 위해 70B짜리 전용 모델을 별도로 훈련했다. 그게 얼마나 어려운 문제인지를 방증하는 수치다. 해당 분석이 짚은 핵심은 명확하다. 이건 언어 모델 문제가 아니라 인터페이스 설계 문제다. 모델은 무엇을 바꿔야 하는지 이해한다. 다만 그 변경을 harness가 파싱할 수 있는 포맷으로 표현하는 데서 실패한다. 더 큰 모델이 이 문제를 흡수하지 않는다. provider failover, 병렬 태스크 의존성 정렬, 세션 간 상태 영속성—이 모든 인프라 문제는 모델이 커져도 남는다.
AI가 조용히 상황을 악화시킬 때
DailyMood의 성공 사례와 hashline의 인프라 교훈을 놓고 보면, AI-assisted development가 잘 작동하는 그림이 그려진다. 하지만 시니어 프론트엔드 엔지니어 Ricardo Saumeth가 정리한 현장 경험은 반대 방향의 데이터를 제공한다. AI는 때로 속도를 높이는 게 아니라 조용히 상황을 악화시킨다.
그가 열거한 네 가지 실패 패턴은 체크리스트로 쓸 만하다. 첫째, 존재하지 않는 API를 참조하거나 아키텍처에 맞지 않는 패턴을 생성한다. 둘째, 대규모 리팩터에서 컨텍스트를 잃고 타입을 깨뜨리며 '거의 동작하는' 코드를 낸다. 셋째, AI가 코드를 써도 읽기→이해하기→검증하기→테스트→통합의 루프는 개발자가 직접 돌려야 한다. 넷째, 같은 패턴을 반복하거나 다른 것을 고치면서 기존 것을 깨뜨리는 루프에 빠진다. 그의 처방은 단순하다. 프레임을 좁혀라. 거대한 리팩터 대신 이 로직을 헬퍼로 추출해줘처럼 작고 명확한 단위로 쪼개야 AI가 잘 동작한다.
세 사례가 동시에 가리키는 것
세 사례를 겹쳐 보면 하나의 패턴이 보인다. AI가 생산성을 높이는 조건은 항상 설계 선행이었다. DailyMood는 스택과 아키텍처 규칙을 먼저 확정했기 때문에 AI가 빠르게 코드를 채울 수 있었다. hashline은 모델이 아니라 인터페이스 레이어를 설계한 덕에 10배 성능 향상을 얻었다. Saumeth의 경험은 그 설계 없이 AI를 쓰면 어떤 일이 벌어지는지를 보여준다.
이건 AI 도구의 한계를 말하는 게 아니다. 오히려 반대다. AI의 실행 속도가 높아질수록, 그 속도를 제대로 활용하기 위한 구조 설계 능력의 가치가 함께 높아진다. 코드를 생성하는 속도가 병목이 아닐 때, 병목은 어떤 코드를 만들어야 하는지를 결정하는 사람에게로 이동한다.
팀에서 이걸 어떻게 쓸 것인가
테크 리드 관점에서 실천 가능한 시사점은 세 가지다.
첫째, AI 작업 전에 아키텍처 제약을 문서화하라. DailyMood가 '데이터 페칭은 훅에만'이라는 규칙을 먼저 세운 것처럼, AI가 생성할 코드가 따라야 할 구조적 규칙을 먼저 명문화해야 한다. 이건 CLAUDE.md나 .agents/rules 같은 형태로 레포에 박아두는 게 가장 효과적이다.
둘째, harness 레이어를 모델 선택보다 먼저 고민하라. 어떤 에이전트를 붙일지 결정하기 전에, 그 에이전트가 파일시스템·상태·비용을 어떻게 다루는지의 인터페이스를 먼저 설계해야 한다. 모델을 바꾸는 것보다 harness를 손보는 게 실질적 성능 개선을 만들어낼 가능성이 높다.
셋째, AI에게 큰 단위 작업을 던지지 마라. 시니어 엔지니어의 현장 경험이 반복해서 확인하는 사실이다. 작고 명확하게 프레이밍된 태스크일수록 AI의 출력 품질이 올라간다. 이건 AI의 한계가 아니라 AI와 협업하는 방식의 문제다.
전망: 설계 역량이 새로운 시니어리티 기준이 된다
AI 코딩 도구가 성숙할수록, 팀 안에서 가장 중요한 역할은 코드를 잘 짜는 사람에서 AI가 좋은 코드를 짜게 만드는 구조를 설계하는 사람으로 이동하고 있다. 이건 개발자가 덜 중요해진다는 말이 아니다. 오히려 아키텍처 판단, 제약 명문화, harness 설계, 작업 분해 능력—이 모든 것이 AI 시대 시니어리티의 새로운 기준이 되고 있다는 뜻이다.
속도는 AI가 만든다. 방향은 여전히 사람이 잡는다. 그리고 방향을 잡는 사람의 역할은 AI가 빨라질수록 더 커진다.