'AI로 무엇을 만들까'보다 훨씬 더 중요한 질문이 있다. '어떤 구조로 검증할 것인가.' 최근 두 개의 사례가 이 질문에 서로 다른 각도에서 같은 답을 내놓고 있어서 주목할 만하다.
첫 번째 사례는 Anthropic의 Generator-Evaluator 루프를 실제로 구현한 실험이다. dev.to에 공개된 Harness Engineering 사례에 따르면, 개발자는 Kiro CLI를 활용해 마케팅 웹사이트를 12번의 반복 끝에 자동 생성했다. 총 소요 시간은 3.5시간, 수동 코딩은 제로였다. 구조는 단순하다. Planner가 스펙을 작성하면, Generator가 코드를 생성하고, Evaluator가 이를 평가한 뒤 피드백을 파일로 남긴다. Generator는 그 피드백을 읽고 다시 생성한다. GAN(Generative Adversarial Network)에서 영감을 받은 이 루프는, 사실 우리가 이미 알고 있는 프론트엔드 개발 흐름—프로토타이핑, 검증, 고도화—을 AI로 구현한 것이다.
이 구조에서 가장 인상적인 부분은 Evaluator가 코드를 읽는 것이 아니라 실제 브라우저로 사이트를 본다는 점이다. Playwright MCP를 통해 localhost:3000에 접속하고, 1440px·768px·375px 세 가지 뷰포트에서 스냅샷을 찍고, 모든 인터랙티브 요소를 클릭한다. 코드 리뷰가 잡을 수 없는 시각적 버그, 반응형 깨짐, 접근성 문제까지 포착하는 것이다. 'AI 에이전트는 레이아웃 버그를 볼 수 없다'는 기존의 한계를 루프 설계 자체로 돌파한 셈이다.
흥미로운 점은 반복 과정에서 '다듬기(polish)'보다 '방향 전환(pivot)'이 더 큰 점수 도약을 만들었다는 사실이다. 1회차의 generic한 다크 사이트(5점)에서 4회차의 Terminal Noir 스타일(7점)로 점프한 것은 폰트 하나를 바꾼 게 아니라 디자인 방향 자체를 뒤집은 결과였다. 이 구조에는 흥미로운 강제 장치가 숨어 있다. Generator와 Evaluator 모두 'Inter, Roboto, Arial 금지'와 '보라색 그라데이션 금지' 같은 명시적 규칙을 갖고 있다. Generic AI 패턴은 최대 5/10으로 제한된다. AI가 습관적으로 수렴하는 '평균적 결과물'을 구조적으로 막는 것이다.
두 번째 사례는 엔터프라이즈 AI 배포 현장에서 나온 이야기다. dev.to의 Todd Linnertz가 공유한 페이롤 팀 사례는 Generator-Evaluator 루프의 필요성을 다른 방식으로 증명한다. 이 팀은 94% 테스트 정확도를 기록하고 프로덕션에 AI 에이전트를 배포했다. 결과는 70%로 추락. 테스트 데이터셋이 실제 프로덕션 데이터—오탈자, 손으로 그린 메모, 모순된 지시—를 반영하지 못했기 때문이었다. 해결책은 더 좋은 모델이 아니었다. 4주간의 섀도우 테스팅, 즉 에이전트가 실제 데이터를 처리하되 결과를 제출하지 않고 인간이 검토하는 구조를 통해 최종 98%까지 끌어올렸다. 에이전트는 바뀌지 않았다. 에이전트를 감싸는 하네스가 바뀐 것이다.
두 사례가 교차하는 지점에서 프론트엔드 개발자에게 실용적인 통찰이 도출된다. 모델 선택(어떤 LLM을 쓸까)은 전체 작업의 20%에 불과하다. 나머지 80%는 평가 파이프라인, 피드백 루프, 검증 인프라—즉 하네스다. Harness Engineering 사례의 핵심 레슨도 같다. "AI는 자신의 작업을 스스로 평가할 수 없다. Generator와 Evaluator를 분리하라." 같은 컨텍스트를 공유하지 않는 별도의 클린 슬레이트 프로세스로 둘을 나눔으로써 자기 검증의 편향을 제거한 것이다.
프로토타이핑 워크플로우에 이 관점을 적용하면 실천 방향이 구체화된다. v0.dev나 Claude로 UI를 빠르게 생성하는 것 자체는 문제가 없다. 문제는 그 결과물을 검증하는 루프 없이 바로 병합하거나 배포하는 것이다. Playwright 기반의 시각적 스냅샷 테스트, 다양한 뷰포트에서의 자동 검증, 그리고 '이 결과물이 generic하지 않은가'를 판단하는 기준—이것들이 AI 생성 프론트엔드를 실제로 쓸 수 있는 코드로 만드는 인프라다. 도구가 빨라질수록 검증 루프는 더 중요해진다. 속도가 빠른 만큼 잘못된 방향으로도 빠르게 달릴 수 있기 때문이다.
"모델은 엔진이다. 하네스가 그것을 똑바로 달리게 만든다." Harness Engineering 사례의 마지막 문장은 단순한 비유가 아니다. 프론트엔드 개발자가 AI 도구를 진지하게 워크플로우에 통합할 때 가장 먼저 설계해야 할 것이 무엇인지를 정확히 가리킨다. 더 좋은 프롬프트를 찾기 전에, 검증 루프를 먼저 설계하라.