AI 페어 프로그래밍의 솔직한 성적표
한 주말, 개인 트레이더 겸 개발자가 Bloomberg급 주식 분석 앱 'StockIQ'를 혼자 완성했다. 10개 페이지, RSI·피보나치·이동평균·캔들스틱 패턴 자동 감지까지—Claude Code를 페어 프로그래밍 파트너로 삼아 빠르게 만들어낸 결과다. 여기까지 읽으면 AI 만능론처럼 들린다. 그런데 이 개발자가 dev.to에 남긴 회고의 핵심은 정반대다. "내가 계속 운전석에 앉아 있어야 했다."
Claude Code가 잘하는 것과 못하는 것
Claude Code는 RSI 계산식, 피보나치 레벨 생성, 이동평균 로직처럼 수학적으로 명확한 코드는 빠르고 정확하게 처리했다. Streamlit 앱의 반복 보일러플레이트—페이지 설정, 사이드바, 세션 상태, 캐시 데코레이터—도 순식간에 생성해 수 시간을 아꼈다. 에러가 났을 때 코드와 스택 트레이스를 붙여 넣으면 대부분 두 번째 시도 안에 진단이 나왔다.
하지만 세 가지 영역에서는 개발자가 직접 결정을 내려야 했다. 첫째, 아키텍처 설계. 10개 페이지를 어떻게 나누고 공통 유틸을 어디에 둘지, Claude Code의 제안은 항상 '어떤 답'이었지 '맞는 답'이 아니었다. 여러 번 방향을 수정해야 했다. 둘째, UX 판단. 장중에 차트를 흘깃 보는 트레이더에게 맞는 정보 밀도는 무엇인가, 시각적 위계는 어떻게 가져가야 하는가—이 판단은 프로토타입 옵션을 낼 수는 있어도 정답을 가리키지 못했다. 셋째, 도메인 지식. 컴포지트 시그널 스코어에서 RSI·MA 포지션·패턴 강도의 가중치를 어떻게 설정할지는 트레이딩 경험에서 나오는 결정이다. yfinance의 레이트 리밋, 상장폐지 엣지 케이스, 인트라데이 타임존 처리 같은 라이브러리별 함정도 직접 파고들어야 했다.
이 경험이 남긴 프레임은 간결하다. "아키텍처와 취향은 내가 소유하고, Claude Code는 타이핑을 가속한다."
샌드박스가 해방시키는 것
속도를 더 올리고 싶다면? Docker Sandbox가 등장한다. 2026년 4월 Docker가 정식 출시한 이 기능은 AI 에이전트를 microVM 안에서 격리해 실행한다. 에이전트가 패키지를 설치하고, 파일을 수정하고, 커맨드를 실행해도 호스트 시스템은 건드리지 못한다. 브라질 개발자 Ralvin이 dev.to에 공유한 실험에 따르면, Gemini와 Claude Code를 Docker Sandbox 위에서 돌렸을 때 구현 속도가 약 50% 향상됐다. 매번 'Allow Once'를 눌러 흐름이 끊기던 마찰이 사라지고, 에이전트가 스스로 이터레이션을 완료한 뒤 PR을 열어두는 경험이 가능해졌다.
중요한 맥락이 하나 있다. Ralvin이 기사에서 강조한 건 속도가 아니라 책임의 이동이다. 샌드박스가 실행 자유를 주는 대신, 개발자는 프로젝트 사양 정의와 아키텍처 설계에 더 많은 시간을 쏟아야 했다. 에이전트는 실행을 가속하지만, 기술적 책임을 대체하지 않는다.
AI가 가장 자주 놓치는 레이어: CSS 선택자
AI 코딩 에이전트가 UX 판단을 못 한다는 말은, 마크업과 스타일 레이어에서도 그대로 적용된다. dev.to의 CSS 고급 선택자 가이드는 이 맹점을 잘 보여준다. AI는 여전히 부모 요소 스타일 변경에 useEffect와 클래스 토글을 작성하거나, SCSS를 6단계 중첩으로 짜는 방식을 기본으로 제안하는 경향이 있다. 그러나 2026년 현재, CSS는 이미 이 문제를 네이티브하게 해결하고 있다.
:has()는 자식 요소의 상태에 따라 부모를 스타일링하는, 20년 숙원의 '부모 선택자'다. fieldset:has(input:invalid) 한 줄이 JavaScript 클래스 토글 로직 전체를 대체한다. :is()는 header h1, header h2, header p 대신 header :is(h1, h2, p)로 반복을 제거한다. :where()는 :is()와 동일하되 특이성(specificity)이 0이어서, 라이브러리나 공유 컴포넌트의 베이스 스타일에 최적이다—미래의 개발자가 !important 없이 쉽게 덮어쓸 수 있다.
이 세 선택자의 공통점은 AI가 제안하기 어려운 맥락적 판단이 필요하다는 것이다. :is()와 :where()의 특이성 차이를 언제 쓸지, body:has(...)처럼 DOM 트리 최상단에서 남용할 때 렌더링 성능이 어떻게 영향받는지—이런 판단은 CSS 레이어에 대한 감각 없이는 내리기 어렵다.
세 사례가 수렴하는 하나의 원칙
세 사례를 나란히 놓으면 하나의 패턴이 보인다. AI 에이전트는 형식적으로 명확한 것—수학 공식, 보일러플레이트, 패키지 설치, 파일 수정—을 가속한다. 그리고 인간은 맥락적으로 옳은 것—아키텍처 설계, UX 판단, 도메인 지식, CSS 특이성 감각—을 결정한다.
흥미로운 건 이 분업이 개발자의 역할을 줄이는 게 아니라 다른 곳으로 이동시킨다는 점이다. StockIQ 개발자는 Claude Code로 타이핑 시간을 줄인 만큼, 컴포지트 시그널의 가중치 설계와 트레이더 UX 판단에 집중할 수 있었다. Ralvin은 Docker Sandbox로 에이전트 실행을 자동화한 만큼, 프로젝트 사양 정의에 더 깊이 투자했다. CSS 선택자를 제대로 아는 개발자는 AI가 생성한 과잉 JavaScript를 한 줄 CSS로 교체할 수 있다.
프론트엔드 개발자의 실전 전략
AI 에이전트와 협업하는 방식은 점점 정교해지고 있지만, 지금 당장 적용할 수 있는 원칙은 단순하다.
강한 의견을 가지고 시작하라. 아키텍처, 컴포넌트 구조, UX 흐름에 대한 명확한 판단 없이 에이전트에게 맡기면 일반적인 앱이 나온다. 내가 먼저 결정하고, 에이전트는 그 결정을 실행하는 구조여야 한다.
CSS 레이어의 감각을 유지하라. :has(), :is(), :where()처럼 AI가 제안하기 어려운 선택지를 내가 먼저 알고 있어야, 불필요한 JavaScript 로직을 걷어내고 성능과 가독성을 동시에 잡을 수 있다.
샌드박스로 실험 비용을 낮춰라. Docker Sandbox 같은 격리 환경은 에이전트에게 더 많은 자율성을 줄 수 있게 해준다. 단, 그 전제는 내가 사양을 명확히 정의했을 때다. 격리가 실행을 자유롭게 만드는 만큼, 설계의 책임은 더 선명하게 개발자에게 돌아온다.
앞으로의 질문
AI 코딩 에이전트는 계속 좋아질 것이다. :has() 사용 시점을 판단하거나, 트레이더 UX에서 정보 밀도를 결정하는 것도 언젠가는 잘할지 모른다. 하지만 지금 이 시점의 현실은 명확하다—에이전트가 잘하는 영역은 빠르게 위임하고, 인간의 판단이 필요한 영역은 더 선명하게 소유해야 한다. AI 협업 생산성은 결국 이 경계를 얼마나 정확하게 인식하고 있느냐에서 갈린다.