대부분의 엔지니어는 이미 AI를 쓴다. 디버깅, 보일러플레이트, 테스트 초안, SQL 쿼리—어떤 형태로든 AI가 워크플로우에 들어와 있다. 그런데 dev.to의 한 글이 더 날카로운 질문을 던진다. "AI를 쓰는가"가 아니라 "AI로 엔지니어링하는가" 라고. 나는 이 구분이 팀 리빌딩을 고민하는 테크 리드에게 지금 가장 실용적인 질문이라고 생각한다.
코드 생성은 쉬운 부분이다
'Most Engineers Use AI. Few Engineer With It.'(dev.to)에서 저자가 꺼낸 핵심은 간단하다. 코드를 생성하는 건 어렵지 않다. 넓은 프롬프트 하나면 그럴싸한 코드가 금방 나온다. 진짜 어려운 건 그 앞과 뒤다. 요구사항을 정의하고, 범위를 좁히고, 제약을 설명하고, 검증 방식을 결정하는 것—그 '지루한 엔지니어링 작업'을 먼저 해야 AI의 출력이 비로소 유용해진다. 프롬프팅이 핵심 스킬이 아니라, 작업을 올바르게 형상화하는 것이 핵심 스킬이라는 말이다.
AI는 출력 속도를 높이지, 검증 품질을 높이지 않는다. 요구사항이 불명확하면 AI는 그 불명확함을 빠르게 코드화한다. 아키텍처가 엉망이면 그 엉망함을 자신 있게 복사한다. 리뷰어가 출력물을 제대로 검토하지 못하면, 속도는 곧 리스크가 된다. AI는 이미 존재하는 엔지니어링 루프를 증폭시킨다. 루프가 좋으면 좋게, 루프가 나쁘면 나쁘게.
4개월간의 실전 루프 설계
Claude Code 도입 경험을 공유한 다른 글(dev.to, 'Have you tried Claude Code?')은 이 루프 설계의 현실적인 모습을 보여준다. 저자는 3년간 묵혀둔 포커 게임 프로젝트를 Claude Code로 다시 시작했다. 처음엔 텍스트 파일로 버그 목록을 관리했다. 사용량 한도에 부딪히면 GitHub Copilot을 병행했고, 무료 모델 한계를 넘기 위해 디자인 문서 팩토리를 만들었다. AI가 제멋대로 형식을 바꾸는 문제를 해결하기 위해 인덱스 넘버링 툴을 만들었고, 결국 FlowGate라는 관리 시스템을 직접 구축했다.
이 4개월의 여정에서 흥미로운 건 도구 자체가 아니다. AI가 틀렸을 때의 증거를 시스템적으로 남기는 구조를 직접 설계했다는 점이다. FlowGate 이전엔 AI가 같은 방식으로 실패해도 몇 번이나 시도했는지 알 수 없었다. 이후엔 거절 횟수가 기록된다. SSE 버그 하나에 조사 단계 11회 거절, 작업 단계 13회 거절. 이 숫자가 생기자 '언제 접근 방식을 바꿀지'를 판단할 수 있게 됐다. 워크플로우를 설계했더니 판단 근거가 생겼다.
코드베이스 자체가 AI에게 보내는 프롬프트다
세 번째 퍼즐 조각은 코드 네이밍이다. 'One Simple Naming Trick That Keeps Vibe-Coded Code From Rotting'(dev.to)은 AI 에이전트가 코드를 생성할 때 기존 코드 구조에서 패턴을 추론한다는 사실을 날카롭게 짚는다. UserService, PaymentManager, OrderProcessor 같은 모호한 이름이 있으면 AI는 다음 기능을 가장 가까운 모호한 컨테이너 안에 자신 있게 집어넣는다. 빠르게.
반면 PasswordResetter, RefundIssuer, OrderCanceller처럼 책임이 명확한 에이전트형 이름(Agentive naming)을 쓰면 AI가 추론하는 경계도 선명해진다. PasswordResetter가 할인 계산을 시작하면 파일을 열기 전에 이미 뭔가 이상하다는 걸 알 수 있다. 이름이 설계의 가드레일이 된다. 저자의 표현을 빌리면 "코드베이스는 이제 프롬프트이기도 하다." 모호한 이름은 모호한 설계를 가르치고, AI는 그 수업을 산업적 규모로 이수한다.
팀에 실제로 적용되는 시사점
세 글을 엮으면 하나의 실용적인 그림이 나온다. AI를 쓰는 팀은 생성 속도에 집중한다. AI로 엔지니어링하는 팀은 세 가지를 설계한다.
첫째, 루프 구조. AI에게 작업을 넘기기 전에 요구사항 → 범위 → 제약 → 검증 기준을 먼저 정의하는 루프. 이 루프 없이 AI는 빠른 출력 머신일 뿐이다.
둘째, 실패 증거 시스템. AI가 틀렸을 때 그 기록이 남아야 한다. FlowGate처럼 정교한 시스템이 아니어도 좋다. PR 코멘트, 작업 로그, 거절 횟수—어떤 형태로든 '몇 번 시도했고 어디서 막혔는지'가 팀에 보여야 접근 방식을 바꾸는 판단이 가능해진다.
셋째, 코드베이스 네이밍 기준. AI 에이전트가 날마다 코드를 읽고 쓰는 지금, 모호한 이름은 기술 부채가 아니라 AI에게 나쁜 설계를 학습시키는 교재다. 에이전트형 네이밍 컨벤션을 팀 표준으로 정착시키는 게 코드 품질 관리의 앞단이 된다.
엔지니어링 판단력이 더 비싸지는 시대
'Most Engineers Use AI'의 저자는 이렇게 말한다. "코드 생성이 싸질수록, 불명확한 요구사항의 비용은 더 비싸진다." 나는 여기에 덧붙이고 싶다. 루프를 설계하지 않은 팀, 실패 증거를 남기지 않는 팀, 코드베이스 네이밍을 방치하는 팀은 AI 도입 이후에 오히려 더 많은 기술 부채를 쌓게 될 가능성이 높다.
AI-First 팀 리빌딩의 핵심은 도구 선택이 아니다. Git이 협업을 바꾸고, CI/CD가 배포를 바꿨듯—AI도 도구 자체보다 그 주변 워크플로우 설계가 팀의 실력을 가른다. 내일 당장 Claude Code를 켜는 것보다, 그 AI가 만든 결과물을 팀이 어떻게 검증하고 어디에 맡기지 않을지를 먼저 결정하는 것이 훨씬 더 AI-First다.