지금 우리가 서 있는 변곡점
Anthropic이 Claude Opus 5를 출시하면서 AI 코딩 도구 시장의 지형이 다시 바뀌었다. 아웃소싱타임스가 정리한 것처럼, 반복적 코딩 업무는 Sonnet 5가, 복잡한 설계와 장애 분석은 Opus 5가 적합하다는 '업무별 모델 선택' 프레임이 자리를 잡고 있다. 하지만 여기서 한 발짝 더 들어가면 질문이 달라진다. 어떤 모델을 쓸 것인가가 아니라, 이 모델로 무엇을 설계할 것인가.
세 개의 글감이 동시에 가리키는 방향이 있다. Claude Opus 5라는 더 강력한 모델, AI 에이전트가 포크 비용을 낮췄다는 'Don't Wait. Fork It.'의 주장, 그리고 '존재하지 않는 코드가 최고의 코드'라는 설계 철학. 이 셋은 각각 별개의 이야기처럼 보이지만, AI 코딩 에이전트 시대에 프론트엔드 개발자가 도구를 선택하고 커스터마이징하고 설계해야 하는 방식을 하나의 맥락으로 꿰고 있다.
원칙 1 — 모델은 '목적 함수'로 선택하라
더 강한 모델이 항상 정답은 아니다. Opus 5와 Sonnet 5의 차이는 성능이 아니라 적합한 문제의 구조에 있다. 컴포넌트 반복 생성, 스타일 변환, 보일러플레이트 작성처럼 정답이 명확한 작업에 Opus 5를 투입하는 것은 비용 낭비다. 반면 아키텍처 결정, 모호한 요구사항 해석, 멀티 파일 리팩토링처럼 컨텍스트가 깊고 판단이 필요한 작업에서는 모델 성능 격차가 실질적인 결과 차이로 이어진다.
실용적인 접근은 이렇다. 작업을 세 버킷으로 나눈다—생성(generate), 검토(review), 설계(design). 생성 버킷은 빠르고 저렴한 모델로, 검토와 설계 버킷은 더 강력한 모델로. 중요한 건 이 분류를 팀 레벨의 워크플로우로 명문화하는 것이다. 개발자마다 직관적으로 쓰는 모델이 다르면 비용도 품질도 예측 불가능해진다.
원칙 2 — 포크는 이제 '전략'이 아니라 '전술'이다
dev.to의 'Don't Wait. Fork It.'은 흥미로운 테제를 던진다. 포크가 비쌌던 이유는 아이디어가 아니라 노동이었다는 것. 낯선 코드베이스 4만 줄을 읽고, 빌드를 이해하고, 테스트를 쓰고, 6주 뒤에 리베이스하는—그 고고학적 작업이 진짜 비용이었다. 그리고 그게 정확히 에이전트가 잘하는 일이다.
저자는 T3 Code를 직접 포크해서 세 가지를 추가했다. 커스텀 슬래시 커맨드 디스커버리, 앱 배경 이미지, 프로바이더 모델 필터링. 주목할 건 세 번째가 아니라 두 번째다. 배경 이미지는 생산성을 1초도 올리지 않는다. 하지만 저자는 그걸 정당화하지 않는다. 내가 하루 종일 쳐다보는 도구가 내 것처럼 느껴지는 것 자체가 이유다. 도구와의 관계를 복원하는 행위.
프론트엔드 개발자에게 이 관점이 특히 유효한 이유가 있다. Claude Code, Cursor 같은 에이전트 하네스는 점점 벤더 통제형으로 움직인다. 플러그인 API는 벤더가 열어준 솔기(seam) 안에서만 자유롭다. 솔기 밖은 자유가 없다. 그렇다면 솔기 밖의 필요가 생겼을 때 선택지는 두 가지다—기다리거나, 가져가거나. 에이전트가 포크 비용을 화요일 오후로 줄인 지금, '기다리는 것'의 기회비용이 훨씬 커졌다.
원칙 3 — 에이전트에게 '존재하지 않는 코드'를 설계시켜라
가장 날카로운 통찰은 세 번째 글에서 나온다. dev.to의 'What Is the Best Code?'는 코드 리뷰마다 삭제로 끝났다는 고백으로 시작한다. 컴파일되고, 테스트도 통과하고, 이미 리뷰를 한 번 통과한 코드를 지웠더니—시스템이 강해졌다. 경쟁 조건이 사라지고, 버그 전체 클래스가 표현 불가능해지고, 다섯 함수에 퍼져 있던 의미가 한 곳에서 보였다.
저자가 제시하는 'Existence Ladder'는 단순하지만 강력하다. 새 엔티티를 만들기 전에 일곱 개의 질문을 순서대로 던진다. 이게 꼭 있어야 하나? 이미 있는 건 없나? 구조를 바꿔서 나쁜 상태를 불가능하게 만들 수 있나? 선언으로 해결할 수 없나? 파생시킬 수 없나? 자동으로 반응할 수 없나? 그래도 안 되면 그때 만든다. 6번째 계단인 오케스트레이션—우리가 소유하는 명령형 코드—은 진짜 마지막 수단이다.
이 원칙이 AI 에이전트 시대에 더 중요해지는 이유가 있다. 에이전트는 요청받은 것을 잘 만든다. 'LRU 캐시 클래스 작성해줘'라고 하면 인터뷰 수준의 73줄짜리 구현을 내놓는다—functools.lru_cache가 이미 있다는 걸 언급하면서도. 에이전트는 무엇을 만들지 말아야 하는가를 스스로 결정하지 않는다. 그 판단은 여전히 개발자의 몫이다. 아니, 에이전트가 코드 생산 속도를 올릴수록 이 판단의 중요성은 오히려 커진다.
저자는 'nothing-first' 스킬을 에이전트에 탑재해서 실험했다. 결과는 명확했다. 소유한 엔티티가 49개에서 10개로, 독립적인 장애 경로가 27개에서 7개로, 반복 수동 작업이 19개에서 3개로, 배포 코드 라인이 237줄에서 54줄로 줄었다. 에이전트가 코드를 대량 생산하는 시대일수록, 에이전트에게 '이게 꼭 필요한가'를 먼저 묻게 하는 설계가 팀의 실질적인 안전망이 된다.
세 원칙이 만나는 지점
모델 선택, 포크 전략, 코드 최소화—이 세 원칙은 사실 하나의 질문에 닿아 있다. AI 에이전트에게 무엇을 위임하고, 무엇은 개발자가 직접 판단하는가.
에이전트는 고고학을 대신한다. 낯선 코드베이스를 읽고, 슬래시 메뉴가 어디서 조립되는지 찾고, LRU 캐시를 73줄로 구현한다. 하지만 이 코드베이스를 포크할 가치가 있는지, 이 캐시가 애초에 필요한지, 이 모델이 이 작업에 적합한지는 에이전트가 결정하지 않는다. 타이핑 비용이 싸진 것이지, 판단의 책임이 이동한 게 아니다.
전망: 설계 판단력이 새로운 희소 자원이 된다
도구가 강해질수록 도구를 언제 쓰고 언제 쓰지 않을지를 아는 사람의 가치가 오른다. Claude Opus 5가 코딩의 기준을 다시 그리는 시점에, 프론트엔드 개발자에게 필요한 건 더 많은 AI 활용법이 아니라 무엇을 AI에게 맡기지 않을 것인가에 대한 명확한 원칙이다. 도구는 점점 더 잘 만든다. 설계는 여전히 우리가 한다.