에이전틱 코딩은 라이브러리 선택 기준을 바꾼다. 구현 노동이 가장 비싼 자원이던 시기에는 고수준 라이브러리의 의견을 받아들이는 것이 합리적이었다. 하지만 에이전트가 반복 구현과 수정 비용을 크게 낮추면, unopinionated primitives 위에 제품에 맞춘 얇은 계층을 직접 소유하는 선택이 더 자주 이긴다.
핵심 주장
고수준 라이브러리는 이미 지불된 구현 노동을 패키지로 가져오는 방식이다. 대신 렌더링, 스타일, 상호작용, 생명주기 같은 결정도 함께 가져온다. 요구사항이 라이브러리의 happy path에서 벗어나는 순간 wrapper, custom renderer, workaround가 쌓이고, 결국 직접 구현과 비슷한 비용을 낸다.
반대로 primitives는 계산만 제공하고 제품 결정은 남겨둔다. d3-scale은 값을 픽셀로 바꾸지만 SVG 구조와 툴팁 동작을 정하지 않는다. zod는 스키마 검증을 하지만 폼 UX를 강제하지 않는다. date-fns는 날짜 계산을 하지만 캘린더 컴포넌트를 소유하지 않는다.
판단 기준
| 상황 | 더 나은 시작점 |
|---|---|
| 요구사항이 표준 UI와 거의 같음 | 고수준 라이브러리 |
| 디자인 시스템과 상호작용이 강하게 맞춤형 | primitives + 얇은 계층 |
| 접근성·키보드·스크린리더 edge case가 깊음 | 검증된 컴포넌트 라이브러리 |
| 팀이 에이전트 결과를 리뷰할 전문성이 없음 | 고수준 라이브러리 |
| 팀이 패턴·테스트·리뷰로 소유 코드를 관리 가능 | primitives 기반 구현 |
실무적으로 달라지는 점
“직접 구현”의 비용이 내려간다
예전에는 커스텀 차트 세 개를 직접 만들려면 며칠에서 몇 주가 걸렸다. 이제는 에이전트가 React + SVG + D3 primitives로 초안을 빠르게 만들고, 사람이 디자인·상호작용·테스트를 검수하는 흐름이 가능하다. 따라서 “이미 설치된 라이브러리가 있으니 무조건 쓴다”는 규칙이 약해진다.
소유 계층은 문서와 리뷰가 필요하다
얇은 계층을 소유한다는 것은 유지보수 책임도 소유한다는 뜻이다. 에이전트가 코드를 빨리 만들 수 있어도 팀이 올바른 scale, 접근성, 이벤트 처리, 성능 병목을 판단하지 못하면 부채가 된다. 반복 패턴, 테스트, 코드 리뷰 기준을 함께 만들어야 한다.
모든 의존성을 버리자는 뜻은 아니다
날짜 계산, 색 보간, 스키마 검증, floating UI positioning, 접근성 primitive처럼 edge case가 많은 안정 문제는 검증된 라이브러리를 쓰는 편이 낫다. 버려야 할 것은 의존성 자체가 아니라 제품의 차별적 동작까지 외부 프레임워크의 의견에 묶는 습관이다.
관련 문서
- claude-code — 터미널에서 동작하는 AI 코딩 에이전트
- codex — 파일·도구·워크플로를 자동화하는 AI 에이전트
- ai-agent-tips-graph-engineering — 에이전트 구조를 그래프로 설계하기
- llm-orchestration-tips-framework-choice — LangChain·LlamaIndex·Raw API 선택 기준
- agentic-stack — 코딩 에이전트 간 기억과 스킬을 이식하는 .agent 레이어
참고 자료
- Agentic Coding: Bet on the Primitives — Robin Wieruch (2026-07-31)