'AI랑 개발하면 빠르다'는 말은 반만 맞다. 정확히는, AI를 시스템으로 쓸 때만 빠르다. Claude와 함께 인증 기능을 논의하다가 어느새 에러 핸들링 리팩토링을 하고 있다면—그건 AI 개발이 아니라 AI와 함께하는 즉흥 연주다. dev.to에 올라온 한 개발자의 워크플로우 회고("From GitHub Issue to Merged PR")는 이 즉흥 연주가 얼마나 비싼 실수인지를 적나라하게 보여준다. 매달 상당량의 Claude 토큰을 소진하면서도 실질적인 피처는 두어 개밖에 못 챙겼다는 고백이 출발점이다.
핵심 이슈: '컨텍스트 드리프트'가 생산성을 잠식한다
문제의 본질은 컨텍스트 드리프트다. 하나의 대화 세션을 길게 이어가면 Claude는 이미 수정된 코드를 기준으로 답변하거나, 존재하지 않는 함수를 참조하는 환각을 일으키기 시작한다. 더 교묘한 문제도 있다. Claude는 자신이 작성한 코드를 리뷰할 때 관대해진다. 자기 패턴에 눈이 멀어 CSRF 누락이나 함수 메타데이터 손실 같은 결함을 그냥 통과시킨다. 이 두 가지—컨텍스트 드리프트와 자기 검토의 맹점—가 AI 개발 워크플로우에서 가장 자주 발생하는 품질 저하 원인이다.
맥락 해석: 세 단계 구조가 해법이다
이 문제를 해결한 워크플로우는 의외로 단순한 원칙 하나에서 출발한다. 먼저 계획하고, 나중에 코딩한다. 구체적으로는 세 가지 요소를 코드 한 줄 쓰기 전에 AI와 합의한다. ① 현재 코드베이스 상태와 최근 변경 사항을 명시하는 컨텍스트 경계, ② 사용 중인 API·배포 파이프라인·테스트 환경을 정의하는 도구 제약, ③ '완료'의 기준을 6개월 후 유지보수 가능성까지 포함해 정의하는 성공 기준. 이 계획 단계는 토큰 비용이 적게 들지만, 이후 단계에서의 재작업을 대폭 줄인다.
그 다음은 세션 경계 관리다. 계획 단계에서 Claude에게 기술 접근법·파일 구조·구현 노트를 담은 프로젝트 브리프를 생성하게 하고, 이 브리프를 저장한 뒤 구현 단계에서 새 세션을 시작한다. 새 세션은 브리프 + 현재 코드베이스 + 단일 이슈 컨텍스트만 받는다. 이렇게 하면 각 세션이 깨끗한 상태에서 시작되고, 컨텍스트 드리프트 자체가 발생할 여지가 없다. 이슈 하나당 세션 하나—이 원칙이 확장성의 핵심이다.
리뷰 단계에서는 크로스 모델 적대적 리뷰를 쓴다. Claude가 작성한 코드를 다른 모델에 붙여넣고, Claude가 썼다는 사실을 언급하지 않은 채 비판적 리뷰를 요청한다. 서로 다른 모델은 서로 다른 맹점을 가지고 있어 한 모델이 놓친 결함을 다른 모델이 잡아낸다. 이것이 'AI가 AI를 검토하는' 가장 실용적인 형태다.
코드 리뷰를 더 체계적으로 만들고 싶다면 dev.to의 "10 Claude Prompts for Faster Code Reviews"가 좋은 레퍼런스다. 핵심 아이디어는 네거티브 제약 프롬프팅이다. 예를 들어 "로직 오류, 널 역참조, 레이스 컨디션, 오프바이원 오류만 찾아라. 포매팅과 네이밍 컨벤션은 무시하라"고 지정하면 Claude는 실제 프로덕션 버그에만 집중한다. 스타일 코멘트 뒤에 진짜 결함이 묻히는 일이 없어진다. 역할 페르소나를 부여하는 방식도 유효하다. "이 코드베이스에서 2년 일한 시니어 엔지니어로서, 6개월 후 팀을 힘들게 할 것들을 직설적으로 지적하라"는 프롬프트는 헤지된 제안이 아니라 의견이 담긴 피드백을 끌어낸다.
시사점: 인프라 오버헤드를 없애야 워크플로우가 완성된다
워크플로우의 마지막 퍼즐은 배포 인프라다. 아무리 계획과 리뷰를 잘 해도, 에이전트를 프로덕션에 올리는 과정에서 샌드박싱·자격 증명 관리·권한 제어·장시간 세션 유지 같은 인프라 문제가 발목을 잡으면 속도는 다시 제자리로 돌아온다. Anthropic이 공개 베타로 내놓은 Claude Managed Agents는 이 병목을 정면으로 겨냥한다. 긱뉴스에 올라온 소개에 따르면, 기존에는 에이전트 개발에 수개월이 걸리던 인프라 작업을 며칠 내 프로토타입에서 프로덕션으로 전환할 수 있게 해준다. Sentry가 버그 탐지부터 PR 생성까지의 플로우를 수개월 걸리던 통합에서 수주 내로 완성한 사례, Rakuten이 각 부문 전문 에이전트를 1주일 내 배포한 사례가 이를 뒷받침한다.
다만 Hacker News 커뮤니티의 반응은 냉정하다. 단일 벤더 의존의 위험성, 다중 모델 혼합이 실제로 더 나은 성능을 내왔다는 실무 경험, 비용 폭주 가능성이 주요 우려로 꼽힌다. "최적의 성능은 여러 회사의 에이전트를 혼합했을 때 나왔다"는 지적은 특히 주목할 만하다. Managed Agents가 제공하는 편의성이 모델 선택의 자유를 희생할 만큼 가치 있는지는 팀의 규모와 요구사항에 따라 달라진다.
전망: '시스템을 만드는 개발자'가 AI 시대의 생산성 격차를 만든다
세 가지 신호가 하나의 방향을 가리킨다. 계획 우선 워크플로우, 크로스 모델 적대적 리뷰, 관리형 에이전트 인프라—모두 AI를 도구가 아닌 시스템의 구성 요소로 취급할 때 효과가 극대화된다. 완벽한 프롬프트를 찾는 게 아니라 실수를 구조적으로 방지하는 반복 가능한 시스템을 만드는 것, 그게 지속 가능한 AI 개발의 핵심이다. 빠른 프로토타이핑이 진짜 빠르려면 그 뒤에 검증과 고도화를 받쳐주는 구조가 있어야 한다. Issue 하나에서 시작해 Merged PR로 끝나는 사이클이 믿을 수 있으려면, 그 과정 전체가 설계되어 있어야 한다.