'코드를 짠다'는 행위의 의미가 바뀌고 있다. 프롬프트를 입력하면 3초 만에 함수가 완성되고, 에이전트에게 지시하면 PRD 문서가 자동으로 생성된다. Claude Code를 활용한 워크플로우가 확산되면서, AI는 이제 단순한 자동완성 도구를 넘어 기획·설계·구현·검증을 아우르는 개발 파트너로 자리 잡고 있다. 그런데 이 흐름의 이면에는 불편한 질문이 숨어 있다. "빠르게 생성한 것들을, 나는 정말 이해하고 있는가?"
생성의 흐름: PRD에서 태스크까지 자동화하기
velog에 공유된 Claude Code 워크플로우 사례는 AI 기반 개발 루틴의 구체적인 청사진을 보여준다. 단계는 단순하면서도 체계적이다. 먼저 Claude와 대화 형식으로 서비스 기획 아이디어를 정제하고, @agent-prd-generator를 통해 docs/PRD.md 파일을 자동 생성한다. 이어서 @agent-development-planner가 PRD를 기반으로 ROADMAP.md를 작성하고, 린캔버스(LEANCANVAS.md)까지 파생 문서로 뽑아낸다. 흥미로운 점은 구현 우선순위다. 이 워크플로우는 DB 연동보다 UI/UX 더미데이터 구현을 먼저 권장한다. 기획서가 완벽하게 현실과 맞닿지 않을 수 있기 때문에, 눈에 보이는 화면으로 먼저 방향을 검증하겠다는 프로덕트 사고가 담겨 있다.
여기에 Shrimp Task Manager(MCP)를 더하면 태스크 분해와 실행까지 자동화된다. plan_task로 로드맵을 하위 작업으로 분해하고, execute_task로 개별 구현을 진행한다. verify_task는 80점 이상일 때만 자동 완료 처리한다는 기준까지 내장하고 있다. 즉, '프로젝트 시작 → 규칙 초기화 → 태스크 계획 → 분석 → 반성 → 분해 → 실행 → 검증 → 완료'라는 소프트웨어 개발의 전 사이클을 AI가 오케스트레이션하는 구조다. 개발자는 방향을 설정하고, 판단 지점에서 개입하며, 나머지는 에이전트에게 위임한다.
검증의 경고: 속도가 사고력을 잠식할 때
그런데 dev.to에 올라온 한 시니어 개발자의 고백은 이 흐름에 찬물을 끼얹는다. 그는 AI가 생성한 코드를 후배에게 설명하려다 아무 말도 못했던 순간을 솔직하게 털어놓는다. 타이핑뿐 아니라 사고 자체를 AI에게 위탁해버린 것이다. 그가 1년 동안 잃은 것들의 목록은 구체적이다. 문제를 작은 단위로 분해하는 능력, 배열 메서드를 손으로 쓸 수 있는 근육 기억, 디버깅의 첫 번째 질문을 스스로 던지는 능력, 그리고 무엇보다 자신에 대한 신뢰. 기술 인터뷰에서 Cursor 없이 10분짜리 문제를 45분 동안 헤맸다는 고백은 단순한 개인적 실패담이 아니다. 이건 구조적 경고다.
그의 처방은 AI 포기가 아니다. '계산기처럼 쓰되, 두뇌 대체제로 쓰지 말 것.' 첫 초안은 직접 작성하고, AI가 생성한 코드는 한 줄씩 소리 내어 설명할 수 있어야만 커밋한다는 규칙을 만들었다. 하루 1시간 AI 없는 코딩 세션도 실천 중이다. 이 원칙은 Claude Code 워크플로우와 충돌하지 않는다. 오히려 보완한다. 에이전트가 태스크를 자동 분해해줄수록, 개발자는 각 태스크가 왜 그렇게 분해되었는지를 읽어내는 능력을 더 의식적으로 유지해야 한다.
구조화의 완성: AI 에이전트가 CI를 지킬 때
'빠른 생성'과 '깊은 이해' 사이의 긴장을 구조적으로 해소하는 사례도 있다. dev.to에 공개된 아키텍처 문서 자동화 실험은 Gemini와 Claude Sonnet을 활용한 자율 에이전트가 Google Cloud 기반 수십 개의 마이크로서비스를 스스로 분석해 ARCHITECTURE.md 파일을 계층적으로 생성한 과정을 기록한다. 개발자가 팔굽혀펴기를 하는 동안 에이전트는 서비스 간 의존성을 추적하고, Mermaid 다이어그램을 포함한 구조화된 문서를 저장소에 커밋했다.
진짜 가치는 그다음에 나왔다. 이 아키텍처 문서가 CI 파이프라인의 AI 품질 게이트에 컨텍스트로 주입되자, 기존에는 잡지 못했던 두 가지 심각한 문제가 수 분 만에 발견됐다. 하나는 트레이스 헤더를 삭제하는 미들웨어가 분산 추적 체계 전체를 단절시킨다는 것이었고, 다른 하나는 미디어 처리 서비스가 임시 파일을 GCS에 무기한 축적하고 있어 비용과 보안 리스크가 복합적으로 증가하고 있다는 점이었다. 린터나 개별 코드 리뷰로는 결코 잡을 수 없는 문제들이었다. 코드의 '동작 방식'이 아니라 아키텍처의 '의도'와 충돌했을 때만 보이는 종류의 오류였기 때문이다.
시사점: 생성·이해·검증은 분리될 수 없다
세 가지 사례가 하나의 흐름으로 수렴한다. Claude Code 워크플로우가 보여주는 '빠른 생성', Vibe Coding 비판이 제기하는 '깊은 이해의 필요', 아키텍처 자동화가 증명하는 'AI 기반 구조적 검증'—이 세 단계는 사실 분리될 수 없는 하나의 루틴이다. 생성만 빠르고 이해가 얕으면 기술 부채가 쌓인다. 이해는 있지만 검증 구조가 없으면 시스템 수준의 오류를 놓친다. 그리고 검증 없는 문서는 그냥 파일일 뿐이다.
프론트엔드 개발자 관점에서 실행 가능한 원칙은 세 가지다. 첫째, Claude Code의 PRD·로드맵 자동 생성을 적극 활용하되, 에이전트가 분해한 각 태스크의 의도를 반드시 직접 언어화하는 과정을 습관화하라. 둘째, AI가 작성한 코드는 한 줄씩 설명할 수 있을 때만 머지하는 기준을 팀 레벨의 컨벤션으로 올려라. 셋째, 아키텍처 문서를 '나중에 쓰는 주석'이 아니라 CI 품질 게이트의 입력 컨텍스트로 설계하라. 문서가 코드와 같은 저장소에 살아야 AI 검증이 의미를 가진다.
전망: 설계 능력이 곧 AI 활용 능력이 된다
AI가 생성 속도를 무한히 끌어올릴수록, 개발자의 핵심 역량은 역설적으로 '무엇을 만들지 결정하고, 왜 그렇게 만들었는지 설명하는 능력'으로 수렴한다. Claude Code로 10분 만에 PRD를 뽑아낼 수 있는 세계에서, 그 PRD가 진짜 사용자 문제를 담고 있는지 판단하는 것은 여전히 인간의 몫이다. 에이전트가 태스크를 자동 실행하는 환경에서, 어떤 태스크가 먼저여야 하는지 우선순위를 정하는 것도 마찬가지다. AI는 루틴을 자동화하지만, 루틴의 방향은 설계하는 사람이 책임진다. 빠른 프로토타이핑의 시대에 살아남는 개발자는 '더 빠른 프롬프터'가 아니라 '더 나은 설계자'일 것이다.