'거의 맞는데' 루프에서 탈출하기
AI 보조 프론트엔드 개발을 해본 사람이라면 누구나 이 패턴을 안다. 에이전트가 컴포넌트를 생성하고, 브라우저에서 미리보기를 열면 레이아웃이 미묘하게 어긋나 있다. 버튼 여백이 좁거나, 드롭다운이 모달 뒤로 숨거나, 호버 영역이 엉뚱한 곳에 걸린다. 이걸 고치려면 다시 채팅창으로 돌아가서 "Submit 버튼과 입력 필드 사이 간격이 너무 좁아요"라고 타이핑한다. Stack Overflow 2025 Developer Survey에 따르면 개발자의 84%가 AI 도구를 쓰고 있지만, 66%는 '거의 맞는데' 문제—기능은 되는데 시각적 보정이 필요한 상황—를 핵심 불만으로 꼽았다. 이 루프가 느린 이유는 구조적이다. 개발자는 시각적 관찰을 텍스트로 번역하고, 에이전트는 그 텍스트를 다시 공간적 DOM 이해로 역번역한다. 양방향에서 정보가 손실된다.
에이전트는 브라우저를 볼 수 없다
Claude Code, Cursor, Copilot 같은 AI 코딩 에이전트는 본질적으로 텍스트 세계의 존재다. 파일을 읽고, AST를 분석하고, diff를 생성하는 일엔 탁월하다. 하지만 자신이 생성한 JSX가 브라우저에서 어떻게 렌더링되는지 직접 확인할 방법이 없다. 스크린샷을 넘기는 방식도 있지만, 픽셀 더미에서 CSS 셀렉터를 추론하거나 computed margin 값을 역산하는 건 계산 비용이 높고 오차가 크다. 에이전트에게 필요한 건 "어떻게 보이는가"가 아니라 "무엇인가"다.
Annotation-First: 번역 단계를 없애는 워크플로우
dev.to에 소개된 'Annotation-First UI Pair Programming' 워크플로우는 이 문제를 정면으로 겨냥한다. 핵심 아이디어는 간단하다. 개발자가 문제를 텍스트로 설명하는 대신, 렌더링된 페이지 위에서 직접 요소를 클릭하거나 영역을 드래그해 주석을 남긴다. 에이전트는 그 주석을 구조화된 메타데이터로 읽는다.
개발자가 특정 버튼을 클릭해 주석을 달면 시스템은 다음을 캡처한다: CSS 셀렉터, 전체 DOM 경로(html > body > div.app > main > form > button.submit), 태그명, 바운딩 박스(픽셀 단위 위치와 크기), id·class·ARIA 속성, computed 스타일 값—여기에 개발자의 코멘트와 의도(fix/change/question/approve), 심각도(blocking/important/suggestion)까지 함께 붙는다. 에이전트는 이 JSON 객체를 받아 즉시 소스 코드에서 해당 셀렉터를 찾아 수정한다. "Submit 버튼과 입력 필드 사이가 좁아요"라는 모호한 문장 대신, margin-top: 4px라는 정확한 현재 값과 함께 수정 의도가 전달된다.
onUI: 이 패턴의 오픈소스 구현체
이 워크플로우를 실제로 구현한 도구가 onUI다. GPL-3.0 라이선스의 Chrome/Edge/Firefox 브라우저 익스텐션으로, 두 가지 캡처 모드를 제공한다. Annotate 모드에서는 페이지의 요소를 클릭(Shift-클릭으로 다중 선택)해 의도와 심각도, 코멘트를 입력한다. Draw 모드에서는 직사각형이나 타원 영역을 드래그해 단일 DOM 요소에 매핑되지 않는 레이아웃 문제—여백, 시각적 그룹핑 등—를 표시할 수 있다.
주석 데이터는 로컬에 저장되고, onui-local이라는 MCP(Model Context Protocol) 서버를 통해 에이전트에 노출된다. stdio 방식으로 동작하고, 클라우드 백엔드도 계정도 없다. 데이터는 개발자 머신 밖으로 나가지 않는다. 에이전트가 호출할 수 있는 도구는 8개다: 주석 조회, 페이지별 보고서 생성, 상태·심각도·의도 기반 검색, 개별·일괄 업데이트, 삭제까지. 보고서 출력 수준도 compact(셀렉터+코멘트)부터 forensic(React 컴포넌트 이름, 뷰포트 좌표, 전체 문서 메트릭)까지 네 단계로 나뉜다.
브라우저-에이전트-개발자 삼각 협업 구조
이 워크플로우가 흥미로운 이유는 단순히 '더 나은 피드백 방법'에 그치지 않기 때문이다. 여기서 눈여겨볼 건 브라우저-에이전트-개발자 사이의 협업 구조가 재편된다는 점이다.
기존 구조는 선형이었다. 개발자 → 에이전트 → 코드 → 브라우저 → 다시 개발자. 브라우저는 결과물을 보여주는 수동적 종착점이었다. Annotation-First 워크플로우에서 브라우저는 능동적 입력 인터페이스가 된다. 개발자가 브라우저 위에서 직접 의도를 표현하면, 그 의도가 MCP를 통해 에이전트로 흘러간다. 에이전트는 소스를 수정하고, 브라우저가 다시 렌더링한다. 삼각형의 세 꼭짓점이 양방향으로 연결된 루프다.
이 구조는 dev.to의 또 다른 글—AI 코딩 활용 가이드—이 강조하는 '아키텍트 사고방식'과도 맥이 닿는다. AI에게 전체를 던지지 말고 개발자가 구조를 설계하고 에이전트가 단위 구현을 맡으라는 그 원칙이, UI 레이어에서는 '주석으로 의도를 구조화하고 에이전트가 좌표 기반으로 실행'하는 방식으로 구체화된다.
모바일 제어까지: 협업 구조의 물리적 확장
흥미로운 또 다른 사례가 있다. CC Pocket이라는 오픈소스 Flutter 앱은 Claude Code와 Codex CLI를 스마트폰에서 원격 제어할 수 있게 해준다. WebSocket 브리지를 통해 맥의 에이전트 프로세스를 모바일에서 승인하고, 세션을 시작하고, diff를 리뷰한다. 소파에서, 카페에서, 심지어 침대에서도 에이전트를 모니터링하는 시나리오가 현실이 됐다.
이 두 사례를 나란히 놓으면 흥미로운 그림이 나온다. 에이전트의 활동 공간이 IDE 내부에서 브라우저와 모바일 기기로 확장되고 있다. 개발자가 에이전트와 상호작용하는 인터페이스가 텍스트 채팅에서 렌더링된 UI 위의 공간적 주석으로, 그리고 손 안의 터치 인터페이스로 다양화되고 있다.
실무적 시사점: UI 레이어에서 에이전트의 역할이 바뀐다
이 워크플로우가 프론트엔드 개발 실무에 주는 시사점은 세 가지다.
첫째, 피드백 루프의 언어가 바뀐다. 자연어로 공간 관계를 설명하는 비효율이 줄어든다. DOM 메타데이터라는 에이전트 친화적인 언어로 직접 소통하는 채널이 생긴다.
둘째, 에이전트의 UI 작업 정확도가 높아질 여지가 생긴다. 셀렉터와 computed 스타일, 바운딩 박스가 주어지면 에이전트의 추론 부담이 줄고 수정 정확도가 올라간다. '거의 맞는데' 반복 횟수 자체가 감소한다.
셋째, 디자인-개발 협업 방식에도 영향을 준다. 디자이너가 직접 스테이징 URL에 주석을 달아 에이전트가 읽을 수 있는 피드백을 남기는 시나리오도 충분히 상상 가능하다. Figma 코멘트가 MCP를 통해 에이전트의 작업 큐로 직행하는 미래가 멀지 않다.
전망: 주석이 에이전트의 새로운 인터페이스가 될 수 있다
현재 AI 코딩 에이전트와의 협업 대부분은 여전히 텍스트 채팅 인터페이스에 묶여 있다. 하지만 Annotation-First 패턴은 한 가지 가능성을 시사한다—에이전트와의 대화 인터페이스가 반드시 채팅일 필요는 없다는 것. 개발자가 가장 자연스럽게 의도를 표현할 수 있는 컨텍스트, 즉 렌더링된 UI 위에서 직접 소통하는 방식이 더 효율적일 수 있다.
MCP가 에이전트 생태계의 공통 프로토콜로 자리잡고 있는 지금, 브라우저 주석 레이어를 MCP 서버로 연결하는 이 아이디어는 꽤 현실적인 방향이다. 앞으로 주목할 것은 이 패턴이 onUI 같은 독립 도구로 남을지, 아니면 Cursor나 Windsurf 같은 주류 에이전트 IDE의 내장 기능으로 흡수될지다. UI 레이어에서 에이전트와 대화하는 방법이 근본적으로 바뀌고 있다.