망가진 UI를 고치는 최고의 해결책, ShadCN 루프

ShadCN은 가장 널리 사용되는 UI 라이브러리 중 하나이지만 AI 에이전트로 개발할 때 문제가 발생한다. 원샷 랜딩 페이지는 문제없지만 새로운 앱이나 기능을 구현할 때 오류가 발생하고 앱의 다른 부분까지 망가뜨린다. AI 에이전트는 항상 자신의 코드를 테스트하지만 컨텍스트가 커지면 신뢰할 수 없게 되어, 에이전트가 주어진 작업을 완수하도록 보장하는 방법이 필요하다. 이 문제는 새로운 것이 아니라 이미 현재 엔지니어들이 해결하고 있는 문제다.

Anthropic은 에이전트 루프 개념인 RALPH 루프를 사용해서 이 문제를 해결한다. RALPH는 Anthropic이 다른 사람의 기술을 기반으로 구현하고 오픈소스화한 새로운 플러그인이다. 기본적으로 RALPH는 루프이며, Claude Code Hook의 stop hook을 사용해서 Claude가 답변 출력을 멈출 때 초기 프롬프트 파일이 다시 입력되어 반복적으로 작업을 개선할 수 있다. 완료 프로미스(completion promise)라는 개념이 있어서, Claude가 작업이 완료됐다고 느끼면 이 프로미스를 스스로 출력한다. 예를 들어 'complete'라는 단어를 프로미스로 설정하면, 반환 프롬프트에 프로미스가 있을 때 루프가 다시 실행되지 않아 Claude가 원할 때마다 그냥 종료하지 않게 된다.

플러그인을 설치하면 RALPH 루프 명령어, 취소 명령어, 그리고 도움말 명령어 세 가지를 사용할 수 있다. 루프 명령어에서는 에이전트에게 반복적으로 입력될 프롬프트를 제공해야 한다. 때로는 해결할 수 없는 불가능한 작업을 받아서 무한 루프에 빠질 수 있으므로 최대 반복 횟수를 설정하는 게 좋은 관행이다. RALPH 루프에 제공할 수 있는 프롬프트에 대한 좋은 모범 사례가 있는 레포 링크를 제공하며, 이 영상에서는 UI 워크플로우와 관련된 것들만 다룬다.

커맨드 팔레트와 보드 뷰라는 두 가지 기능을 구현하는 예시를 통해 TDD 접근법을 설명한다. 새로운 기능이 앱의 다른 부분을 망가뜨리지 않도록 하려면 테스트부터 시작해야 하며, 이를 테스트 주도 개발(TDD)이라고 한다. Claude Code에게 TDD 구조를 설정해달라고 요청하면 end-to-end 테스트 폴더, UI 문제를 확인할 스크린샷 폴더, 그리고 해당 테스트를 만들어준다. TDD는 코드를 구현하기 전에 테스트를 먼저 작성하는 접근 방식으로, 초기 테스트가 항상 실패하지만 먼저 정교한 테스트를 작성한 다음 그 테스트를 통과하는 데 필요한 최소한의 코드를 작성하고, 완료되면 리팩토링하고 더 많은 기능을 추가하면서 테스트가 여전히 통과하는지 확인한다.

이런 테스트들은 자동화되어 있고 Playwright를 가져와서 시각적 검증에 사용할 수 있다. Playwright MCP를 사용해서 브라우저를 통해 자율적으로 검증하는 것은 아니며, TDD에서는 각 기능적 동작마다 스크린샷을 찍을 수 있다. 예를 들어 기능적 동작이 카드 추가라면 스크린샷은 보드에 카드가 추가된 것을 보여준다. AI 에이전트가 해야 할 일은 그 스크린샷들을 보고 shad cn 컴포넌트들이 구현된 방식에 문제가 없는지 확인하는 것뿐이다. 이런 테스트 파일들은 새로운 것이 추가되거나 기능이 구축되는 동안 모든 동작 요구사항이 충족되도록 보장하며, 스크린샷은 순수하게 UI 검증용으로만 사용한다.

TDD가 이미 있는데도 RALPH 루프가 필요한 이유는 더 큰 작업과 컨텍스트 윈도우가 거의 가득 차게 되면 모델들이 갑자기 작업을 중단하고 지속적인 사람의 입력을 요구하기 때문이다. 원하는 모든 유형의 함수에 대해 미리 테스트를 작성한 다음 루프를 사용해서 무엇을 해야 하는지 지시하면 자율적으로 작업할 수 있다. 어떤 워크플로우를 따라야 하는지 알려주고 언제 프로미스를 출력할 수 있는지 조건을 제공하면 작업을 완료하고 루프를 종료한다. 커맨드 팔레트 기능의 경우 25개의 고유한 테스트를 모두 통과했을 때가 그 조건이었다. RALPH 슬래시 명령어를 사용해서 프롬프트를 제공했으며, 테스트를 실행하고 실패한 후 테스트를 통과시키기 위해 컴포넌트를 구현하는 전체 워크플로우를 명시했다.

커맨드 팔레트 기능에서는 UI 오류가 발생할 가능성이 매우 적었기 때문에 문제를 눈치채지 못했다. 하지만 보드 뷰 구현으로 넘어갔을 때 시스템에 큰 실수가 있다는 걸 깨달았다. 같은 프롬프트로 보드 구현을 시작했고 한 번에 모든 요구사항을 완료했지만, 실제로 모든 테스트가 통과하는지 확인하는 동안 성공한 테스트 수가 실제로 감소하는 경우가 있었다. 무언가를 변경해서 다른 것이 망가졌기 때문이며, 이것이 바로 TDD가 정말 중요한 이유다. 주요 문제는 완료됐다고 검증한 후 UI를 확인했을 때 대부분은 올바르게 구현되었지만 일부 UI 오류를 완전히 놓쳤다는 것이다. 스크린샷도 확인했는데 그 스크린샷에도 오류가 나타나고 있었다.

실제로 무엇이 잘못됐는지 분석한 결과 진짜 문제는 프로세스 실패였으며, 특히 UI 수정 측면에서 그랬다. 테스트 파일을 반복해서 실행해야 했기 때문에 모든 테스트를 통과하긴 했지만, 스크린샷 외에는 UI에 대한 특정 테스트가 없었다. 몇 개만 훑어봤고 심지어 본 UI 오류 중 일부를 무시하기도 했으며, 일부 파일은 완전히 무시됐다. 주요 문제는 프로미스 문구를 너무 일찍 출력하고 UI가 실제로 수정되었는지 검증하지 않았다는 것이다. 이를 해결하기 위해 브레인스토밍 세션을 진행했고, 심지어 레포의 프롬프트 작성 모범 사례를 Claude Code에 제공하기도 했다. 결국 UI가 항상 올바르도록 보장할 몇 가지 특정 규칙과 프로세스 변경을 생각해냈다.

메인 프롬프트에서 여러 가지를 변경했는데, 첫 번째는 스크린샷 검증 프로토콜이었다. 각 이미지에 간단한 접두사를 추가해서 Claude가 스크린샷을 읽었는지 아닌지 알려줬지만, 처음 구현했을 때 여전히 모든 이미지를 읽지 않고 몇 개만 읽고 verified를 쓴 다음 일찍 종료했다. 이를 해결하기 위해 모든 스크린샷 이름을 바꾼 후에는 아직 프로미스를 출력하지 말라고 했으며, 작업이 완료됐다고 간주하지 말고 다음 반복에서 완료를 확인하도록 했다. 그래서 최소 두 번의 루프가 실행돼야 하며, 다음 검증에서는 Claude가 모든 파일에 verified 접두사가 있는지 확인한다. 이는 테스트를 변경하고 이미지 검증을 기능 테스트와 분리해야 한다는 의미였다. 다음 반복에서는 모든 이미지에 verified 결과가 있는지 확인하고, Claude가 놓친 게 있으면 다시 보고 출력을 수정한다. 이 변경으로 사소한 UI 오류가 마침내 수정되었고 모든 기능을 올바르게 구현할 수 있었으며, 두 번의 루프로 작업을 완료하고 앱의 모든 주요 UI 오류를 수정할 수 있었다.

수백만 명에게 AI로 구축하는 방법을 가르친 후 이런 워크플로우를 직접 구현하기 시작했으며, 그 어느 때보다 빠르게 더 나은 제품을 만들 수 있다는 걸 발견했다. Automata는 여러분의 아이디어를 실현시켜 주는 서비스로, 앱이든 웹사이트든 만들어준다. 좋은 아이디어가 있지만 구축할 기술 팀이 없는 사람들을 위한 서비스이며, 기술 부조종사 역할을 한다. 수백만 명에게 가르쳤던 동일한 워크플로우를 프로젝트에 직접 적용해서 개발팀을 고용하거나 관리하는 골칫거리 없이 컨셉을 실제 작동하는 솔루션으로 전환한다. hello@automata.dev로 연락하면 되며, 채널을 지원하고 싶으면 슈퍼 땡스 버튼을 사용할 수 있다.