프론트엔드 에이전트(Frontend agents)는 코드를 작성할 수 있습니다. 하지만 그들이 보통 하지 못하는 것은 인터페이스가 실제로 완료되었을 때를 알려주는 것입니다.

에이전트에게 "이 페이지를 세련되게(polished) 만들어줘"라고 요청하면, 대개 무언가를 수행할 것입니다. 카드를 추가하거나, 색상을 부드럽게 만들거나, 모서리를 둥글게 처리한 뒤 승리를 선언할 수도 있습니다. 그 결과물은 그럴싸하게 디자인된 것처럼 보일 수 있지만, 실제 작업인 계층 구조(hierarchy) 유지, 깨진 상호작용(interaction) 수정, 빈 상태(empty state) 처리, 그리고 좁은 뷰포트(viewport)에서도 페이지가 여전히 작동하는지 증명하는 작업은 놓칠 수 있습니다.

모델에게는 사용 가능한 목표가 전혀 없었습니다. "세련된(Polished)"이라는 말은 거의 무엇이든 의미할 수 있기 때문입니다.

팀들은 에이전트에게 더 많은 컨텍스트(context), 더 많은 도구(tools), 그리고 더 많은 실행 권한을 부여함으로써 이 문제를 해결하려고 계속 시도합니다. 하지만 더 넓은 권한이 모호한 성공 조건을 수리해주지는 않습니다. 그것은 단지 에이전트가 더 넓은 범위에서 틀릴 수 있게 만들 뿐입니다.

부족한 것은 피드백 계약(feedback contract)입니다. 즉, 무엇이 좋은 상태인지, 어떤 증거가 유효한지, 그리고 어디에서 여전히 인간이 결정을 내려야 하는지에 대한 공유되고 테스트 가능한 정의가 필요합니다.

취향(Taste)은 제약 조건이 되어야 합니다

대부분의 디자인 피드백은 다른 인간을 위해 작성됩니다.

"이건 너무 평범해요."

"계층 구조(hierarchy)가 어색해요."

"좀 더 깔끔하게 만들 수 있을까요?"

A 디자이너는 이러한 코멘트들이 많은 학습된 컨텍스트를 담고 있기 때문에 이를 풀어낼 수 있습니다. 하지만 에이전트는 이를 CSS를 재배치하라는 개방형 초대장으로 받아들입니다.

그러한 취향을 체크(checks)로 전환하십시오. Hallmark는 이러한 방향성의 흥미로운 사례입니다. 이들은 빌드(building), 감사(auditing), 재설계(redesigning), 연구(studying)와 같은 활동을 분리한 다음, 디자인 안티 패턴(anti-patterns)을 명시적인 게이트(gates)로 인코딩합니다. 저는 하나의 지침 세트가 디자인을 "해결"했는지 여부에는 크게 관심이 없습니다. 유용한 패턴은 에이전트가 막연하게 분위기(vibe)를 놓치는 대신, 이제 체크를 통과하지 못할(fail a check) 수 있다는 점입니다.

이는 동작(behavior)에도 동일하게 적용됩니다. 프로덕션 인터페이스에는 시각적 목표 이상의 것이 필요합니다. 입력(inputs), 출력(outputs), 실패 상태(failure states), 복구(recovery), 그리고 관찰 가능한 이벤트(observable events)에 대한 수락 기준(acceptance criteria)이 필요합니다.

다음 두 지침을 비교해 보십시오:

설정 패널을 세련되고 반응형(responsive)으로 만들어줘.

그리고:

target: account settings panel

design_constraints:
...

두 번째 버전은 마법 같은 느낌이 덜합니다. 좋습니다. 마법은 검토하기 어렵습니다.

아마도 모든 UI 작업마다 작은 사양 언어(specification language)가 필요하지는 않을 것입니다. 마크다운 체크리스트(Markdown checklist)만으로도 충분한 경우가 많습니다. 리뷰어와 에이전트가 동일한 것을 판단하기만 하면 됩니다.

브라우저는 버그의 절반만 보여줍니다

코드만으로 검사하는 방식은 많은 프론트엔드 실패 사례를 이해하기에 좋지 않은 방법입니다.

컴포넌트 자체는 논리적으로 타당하더라도 상속된 스타일(inherited styles), 예상치 못한 콘텐츠, 런타임 상태(runtime state), 컨테이너 너비, 또는 트리 상위의 다른 컴포넌트로 인해 렌더링이 잘못될 수 있습니다. 눈에 보이는 버그는 브라우저에 존재합니다. 하지만 그 원인은 세 단계의 추상화(abstractions) 너머에 있을 수 있습니다.

프론트엔드 에이전트에게는 시각(sight)이 필요합니다. 에이전트에게 무제한적인 브라우저 제어권을 부여하는 것은 별개의 문제입니다.

peek-cli는 의도적으로 좁은 범위를 설정하여 문서화합니다. 에이전트는 클릭이나 스크립트 주입(script-injection) 권한을 갖지 않고도 이미 열려 있는 브라우저 탭으로부터 스크린샷을 받을 수 있습니다. 관찰(observation)과 행동(action)은 서로 다른 능력(capabilities)이기 때문에 이러한 경계는 유용합니다. 팀은 에이전트에게 브라우저 세션 전체를 즉시 조작하게 허용하지 않고도 에이전트의 진단 능력을 향상시킬 수 있습니다.

하지만 스크린샷은 컨텍스트(context)의 한 계층일 뿐입니다. 스크린샷은 에이전트에게 픽셀이 어떻게 보이는지를 알려줍니다. 하지만 어떤 컴포넌트가 그 픽셀을 생성했는지, 어떤 상태 분기(state branch)가 활성화되어 있는지, 또는 관련 소스(source)가 어디에 있는지는 알려주지 못할 수 있습니다.

Domscribe와 같은 도구들은 문제의 나머지 절반을 지적합니다. 즉, 렌더링된 요소를 컴포넌트 상태(component state) 및 소스 위치(source location)로 다시 매핑하는 것입니다. 시각적 증거는 "무엇이 잘못되었는가?"에 답하고, 구조화된 런타임 컨텍스트(runtime context)는 "어디를 살펴봐야 하는가?"에 답하는 데 도움을 줍니다.

둘 중 어느 것도 다른 하나를 대체하지 않습니다.

이 지점이 바로 많은 에이전트 데모들이 은밀하게 속임수를 쓰는 부분입니다. 그들은 모델이 스크린샷을 보고, 코드를 수정하고, 더 나은 스크린샷을 생성하는 모습을 보여줍니다. 마지막 이미지가 더 좋아 보이기 때문에 루프(loop)가 닫힌 것처럼 보입니다. 하지만 우리는 여전히 상호작용이 제대로 작동하는지, 콘솔(console)이 깨끗한지, 빈 상태(empty state)가 유지되었는지, 아니면 에이전트가 증상을 덮어쓰는 대신 올바른 컴포넌트를 수정했는지 알 수 없습니다.

시각적 확인(Sight)이 도움이 됩니다. 추적 가능성(Traceability)도 도움이 됩니다. '완료 정의(Definition of Done)'에는 이 두 가지가 모두 필요합니다.

증거(Proof)는 산출물(Artifact)이어야 합니다

"완료(Done)"는 에이전트가 보내는 상태 메시지가 아닙니다. 그것은 검토자가 전체 실행 과정을 다시 재생하지 않고도 검사할 수 있는 증거입니다.

프론트엔드 변경 사항의 경우, 해당 번들(bundle)에는 다음과 같은 내용이 포함될 수 있습니다:

• 관련 뷰포트(viewport) 크기에서의 변경 전후 모습
• 실행된 정확한 사용자 흐름(user flow)
• 콘솔 에러(console errors) 및 실패한 네트워크 요청(network requests)
• 통과하거나 실패한 수락 테스트(acceptance checks)
• 보이는 요소(visible element)에서 변경된 소스 코드로 연결되는 포인터
• 에이전트가 완료할 수 없었던 모든 검증 사항

여기서 Hacker News의 ProofShot 토론이 유용한 이유는 댓글들이 스크린샷 그 이상을 요구하기 때문입니다. 사람들은 비디오, 콘솔 출력, 서버 로그, 액션 타임라인(action timelines), 그리고 기존 Playwright 워크플로우와의 중첩에 대해 질문합니다. 그것이 바로 올바른 논쟁 방향입니다. 스크린샷은 증거(evidence)일 수는 있지만, 동작(behavior)에 대한 증명(proof)은 아닙니다.

이러한 구분은 최종 화면이 멀쩡해 보일 때 가장 중요해집니다.

저장 흐름(save flow)이 고장 났더라도 완벽한 스크린샷을 만들어낼 수 있습니다. 접근성 회귀(accessibility regression)가 발생한 페이지도 마찬가지입니다. 시드된 데모 데이터(seeded demo data)에서만 작동하는 컴포넌트도 마찬가지입니다.

증거는 리스크(risk)에 부합해야 합니다. 간격(spacing) 변경은 두 가지 너비에서의 전후 캡처가 필요할 수 있습니다. 결제(checkout) 변경은 동작 테스트(behavioral tests), 실패 상태(failure-state)에 대한 증거, 그리고 인간의 승인 경계(human approval boundary)가 필요합니다. 이 두 가지를 모두 "브라우저가 잘 보인다"라고 취급하는 것이 바로 정교한 프로토타입이 값비싼 운영 환경의 버그(production bugs)로 변질되는 방식입니다.

실무적인 프론트엔드 피드백 계약

이를 시도하기 위해 새로운 플랫폼이 필요하지는 않습니다. 이미 에이전트에게 주고 있는 작업에 다음 여섯 가지 질문을 추가해 보세요:

1. 어떤 시각적 또는 동작적 제약 조건이 유지되어야 하는가?
2. 어떤 경로(route), 뷰포트(viewport), 데이터 상태(data state), 또는 사용자 상태(user state)가 문제를 드러내는가?
3. 보이는 요소를 런타임 상태(runtime state) 및 코드와 어떻게 추적할 수 있는가?
4. 어떤 정확한 상호작용(interaction)이나 체크가 실행되어야 하는가?
5. 에이전트가 검토를 위해 어떤 증거를 반환해야 하는가?
6. 에이전트가 결정할 수 있는 것은 무엇이며, 무엇이 여전히 인간의 확인을 필요로 하는가?

그런 다음 실패를 명시적으로 만드세요.

만약 에이전트가 경로(route)에 도달할 수 없거나, 상태(state)를 재현할 수 없거나, 검증(verification)을 실행할 수 없다면, 해당 작업은 완료된 것이 아닙니다. 이는 유용한 정보입니다. 에이전트는 억지로 성공적인 요약(green summary)을 만들어내기 위해 추측하는 대신, 작업을 중단하고 누락된 증거를 보고해야 합니다.

이는 도구 선택(tool selection) 또한 더 쉽게 만들어 줍니다.

만약 계약(contract)이 렌더링된 확인(rendered check)만을 요구한다면, 읽기 전용 브라우저 가시성(read-only browser visibility)만으로도 충분할 수 있습니다. 만약 다단계 양식 흐름(multi-step form flow)이 필요하다면, 제어된 브라우저 테스트(controlled browser test)를 사용하십시오. 만약 버그가 컴포넌트 상태(component state)에 의존한다면, DOM-to-source 매핑을 추가하십시오. 만약 리스크가 접근성(accessibility)에 있다면, 접근성 검사(accessibility checks)를 실행하고 실패 사례를 캡처하십시오.

필요한 증거부터 시작하십시오. 그 증거를 생성하는 데 필요한 역량을 부여하십시오. 최대의 자율성(maximum autonomy)을 먼저 부여하고 에이전트가 무엇이 중요한지 스스로 발견하기를 바라며 시작하지 마십시오.

더 많은 권한은 마지막에 부여됩니다

현재의 에이전트 담론은 행동(action)에 집착하고 있습니다: 더 많은 도구, 더 긴 실행 시간, 더 적은 승인, 더 큰 작업들 말입니다.

프론트엔드 품질은 그보다 훨씬 덜 흥미로운 것에 달려 있습니다. 에이전트가 페이지를 변경하기 시작하기 전에, 에이전트와 검토자(reviewer)는 무엇이 성공을 의미하는지에 대해 합의해야 합니다.

일단 그러한 계약(contract)이 존재하면, 더 나은 모델과 더 풍부한 런타임 컨텍스트(runtime context)가 도움이 될 수 있습니다. 브라우저 도구(browser tools) 또한 마찬가지입니다. 더 많은 자율성(autonomy)은 심지어 워크플로(workflow) 내에서 자리를 잡을 수도 있습니다.

하지만 그것이 없다면, 그러한 업그레이드들은 대부분 데모를 더 빠르게 움직이게 할 뿐입니다.

프론트엔드 에이전트를 그가 남긴 증거로 판단하십시오. 인간이 결과를 검토했을 때, 인터페이스가 합의된 완료 정의(definition of done)를 충족했음을 확인할 수 있는가?

그 약속은 자율성보다 작습니다. 하지만 나는 언제나 그 약속을 선택할 것입니다.

Source notes

• Hallmark
• peek-cli
• Vibe Coding을 넘어: AI 프로토타입을 사용자가 신뢰할 수 있는 제품으로 만드는 방법 (Beyond Vibe Coding: How to Turn an AI Prototype Into a Product Users Can Trust)
• Show HN: ProofShot - AI 코딩 에이전트에게 구축한 UI를 검증할 수 있는 눈을 부여하세요 (Show HN: ProofShot - Give AI coding agents eyes to verify the UI they build)
• Domscribe