"타이핑은 끝났다, 엔지니어링은 아니다"
Karpathy가 주말 프로젝트를 AI 에이전트에게 던졌다. IP, 사용자명, 비밀번호, 목표만 주고 30분 뒤 전부 완성. 이게 바이브 코딩의 창시자가 직접 보여준 에이전틱 엔지니어링의 현실이다. geeknews가 소개한 '에이전틱 엔지니어링 시대의 생존 스킬 9가지'에 따르면, 개발자의 99%는 이제 코드를 직접 타이핑하는 대신 에이전트에게 명령하고 감독하는 방식으로 일하고 있다. 문제는, 개발자 60%가 AI를 쓰면서도 실제로 에이전트에게 완전히 위임하는 비율은 0~20%에 불과하다는 것. 이걸 '위임 패러독스'라고 부르는데, 핵심 질문은 하나다. "당신은 에이전트를 신뢰하나요?" 대부분의 답은 아직 "아니오"다.
신뢰는 감이 아니라 설계에서 온다
에이전트를 못 믿는 이유는 능력이 부족해서가 아니다. 우리가 에이전트에게 신뢰를 줄 수 있는 구조를 안 만들었기 때문이다. 실제로 이 글에서 꼽은 9가지 스킬을 보면, 하나같이 '구조 설계'에 수렴한다.
분해 능력(Decomposition): "회원가입 기능 만들어줘" 한 줄 던지면 뭔가 나온다. 내가 원하던 게 아닐 확률도 높다. Claude한테 소크라틱 대화로 5분만 인터뷰를 돌려도 엣지 케이스가 사전 정리된다. 그 5분이 4시간을 아낀다는 건 직접 겪어봐야 안다.
컨텍스트 설계(Context Architecture): AGENTS.md를 잘 쓰는 것도 중요하지만, 코드 아키텍처 자체가 Feature 단위로 잘 설계되어 있으면 에이전트가 컨텍스트를 파악하는 속도가 완전히 달라진다. 플랫 디렉토리에서 헤매던 에이전트가 디렉토리 재구성 하나로 즉각 개선됐다는 경험은, 결국 좋은 아키텍처가 인간만을 위한 게 아니라는 걸 보여준다.
완료 정의(Definition of Done): 에이전트의 "완료"는 내 "완료"와 다르다. CLI 프로젝트를 밤새 돌렸더니 타입 정의만 세팅하고 비즈니스 로직은 빈 껍데기였던 사례가 대표적이다. 두 번째엔 테스트 자체를 에이전트가 자기 편하게 재작성했다. DoD를 명확하게 정의하지 않으면 에이전트는 '완료처럼 보이는 것'을 만들 뿐이다.
테스트 자동화도 AI-First로 재설계해야 한다
dev.to에 소개된 Playwright 스캐폴드 프로젝트는 이 흐름을 테스트 자동화 영역에 그대로 적용한 사례다. 핵심은 .claude/ 폴더 하나다. 프로젝트 루트에 CLAUDE.md와 .claude/skills/ 폴더를 두고, 모든 규칙·패턴·금지 안티패턴을 AI 에이전트가 읽을 수 있는 형식으로 정의해뒀다. Claude Code, Cursor, GitHub Copilot 세 가지 툴 모두 같은 아키텍처로 동작한다. "AI 에이전트가 감독 없이도 올바르게 빌드하고 확장할 수 있도록" 설계된 스캐폴드. 이게 AI-First 테스트 자동화의 방향이다.
여기에 GitHub Copilot CLI의 MCP(Model Context Protocol) 지원이 더해지면 이야기가 더 흥미로워진다. PageBolt MCP를 붙이면 에이전트가 터미널에서 직접 스크린샷을 찍고, 영상을 녹화하고, 배포 후 프로덕션 대시보드를 시각적으로 검증한다. 코드를 짜는 것뿐 아니라 결과물을 눈으로 확인하는 것까지 에이전트가 처리하는 시대다. CI/CD 파이프라인에 이걸 끼워 넣으면 QA 사이클이 절반 이하로 줄어든다.
9개 에이전트로 실제 제품을 출시해보니
dev.to의 Reflectt 팀은 실제로 9개의 AI 에이전트로 제품을 출시했다. 엔지니어링, 디자인, 문서, 전략, 코드 리뷰, 운영까지 역할을 나눴다. 52개 태스크 완료, 56개 PR 머지, 프로덕션 서버 3개. 숫자만 보면 인상적이다. 근데 이 팀이 솔직하게 털어놓은 실패들이 더 값지다.
가장 큰 교훈은 "에이전트는 태스크를 잘 실행하지만, 판단은 못 한다"는 것. 신규 유저 첫 API 호출이 400 에러를 뱉는 것을 아무도 못 잡았다. 출시 콘텐츠는 4번 수정 사이클을 돌렸다. 실제 사람처럼 제품을 써보는 '독사과(dogfooding)'를 아무도 하지 않았기 때문이다. 에이전트 기반 피어 리뷰가 하드코딩된 경로나 접근성 오류를 잡는 건 됐지만, "이 페이지가 실제로 동작하나?"라는 판단은 여전히 인간의 몫이었다.
에이전틱 시대에 개발자가 갖춰야 할 진짜 스킬
이 세 가지 사례를 종합하면 방향이 보인다. AI-First 워크플로우에서 개발자의 역할은 설계자, 감독자, 품질 판단자로 재정의된다.
- 메모리 설계: Claude Code hooks로 세션 종료 시 자동 메모리 추출, 다음 세션 5초 복원. 더 나아가 CLAUDE.md를 git에 체크인해서 팀 전체가 공유하면 개인의 맥락이 팀의 자산이 된다.
- 병렬 관리: 10~15개 세션을 동시에 돌리는 건 ADHD가 아니라 의도된 멀티태스킹이다. CTO가 6개 스쿼드를 매니징하던 경험이 에이전트 병렬 관리와 놀라울 만큼 닮았다.
- 감각(Taste): Chris Lattner의 말처럼 "구현의 자동화가 일어날수록 설계·판단·감각의 중요성이 오히려 높아진다." AI가 만든 60~70점짜리 결과물에서 나머지 20~30%를 채우는 건 여전히 인간의 감각이다.
결국, 에이전트를 믿을 수 있게 만드는 건 개발자다
관찰 가능성(Observability)이 신뢰를 만들고, 신뢰가 위임을 가능하게 한다. 에이전트에게 맡기고 "이상한데... 그냥 두자"가 가장 비싼 판단이다. 20개 파일이 엉킨 채 롤백 불가 상태가 되기 전에, 예광탄 전략으로 처음 적용하는 기술을 빠르게 검증하고 블루프린트를 그려야 한다.
에이전틱 시대에 끝난 건 타이핑이지 엔지니어링이 아니다. 좋은 설계의 레버리지도 커졌지만, 나쁜 설계의 피해도 커졌다. 이 쇼의 주인공은 AI가 아니라 AI를 잘 다루는 엔지니어다. 그리고 그 엔지니어를 키우는 건 팀의 AI-First 문화와 구조적 설계다. 지금 당장 CLAUDE.md 하나 제대로 쓰는 것부터 시작해보자.