AI가 UI를 구축한 후 다음 수정 프롬프트 작성 방법

코딩 에이전트(coding agent)가 원하는 것과 비슷한 화면을 반환합니다. 그런 다음 브라우저를 좁히면 오른쪽 가장자리에서 사라지는 버튼을 발견하게 됩니다. 다음 메시지는 “모바일용으로 고쳐줘” 또는 “반응형으로 만들어줘”일 수 있습니다.

이것은 몇 가지 결정을 열어둡니다. 에이전트가 레이아웃을 대체할 수 있을까요? 컴포넌트를 변경해야 할까요? 어떤 부분이 이미 작동하고 있나요? 성공적인 수정이란 무엇을 의미할까요?

이 모든 질문에 전체 애플리케이션의 명세(specification)를 작성하지 않고도 답할 수 있습니다.

가상의 React 가격 책정 페이지를 사용한 예시를 소개합니다.

데스크톱 너비에서는 페이지에 세 개의 가격 카드와 비교 섹션이 있습니다. 기존 컴포넌트와 색상 팔레트는 허용 가능합니다. 하지만 375 CSS 픽셀 너비에서는 페이지 일부가 뷰포트를 벗어나고 기본 버튼(primary button)이 부분적으로 숨겨집니다.

수정의 목표는 좁습니다: 기존 디자인 선택을 유지하면서 모바일 레이아웃을 사용 가능하게 만드는 것입니다.

재현할 수 있는 실패 설명하기

프롬프트를 작성하기 전에, 문제를 재현하고 실제로 무엇이 보이는지 설명합니다. “기본 버튼이 375픽셀에서 오른쪽 가장자리를 넘어갑니다”라고 말하면 에이전트가 조사할 곳을 제공합니다. “CSS가 잘못되었습니다”는 당신이 확인하지 않았을 수 있는 원인을 주장하는 것입니다.

만약 에이전트가 페이지를 검사할 수 있다면, 경로(route)와 뷰포트 크기(viewport size)를 제공하세요. 만약 그렇지 않다면, 스크린샷을 첨부하고 상호 작용을 설명합니다. 스크린샷은 보이는 증상(visible symptom)을 확립할 수는 있지만, 어떤 요소가 그것을 유발했는지 확립할 수는 없습니다.

명확한 경계로 수정 작성하기

그런 다음 유지하고 싶은 부분과 변경하고 싶은 부분을 분리합니다. 적응하여 사용할 수 있는 수정 예시는 다음과 같습니다:

The pricing page extends past the viewport at 375 CSS pixels wide.
The primary button is partly off screen.

...

뷰포트 크기는 이 예시를 위해 선택되었습니다. 자체 문제를 재현하고 지원하려는 레이아웃을 포함하는 너비를 사용하세요. 이것들은 주장이 아니라 체크포인트입니다.

프롬프트가 구현할 여지를 남겨두는 점에 주목하세요. 그리드 유틸리티를 지정하거나 문제가 카드에서 비롯된다고 가정하지 않습니다. 긴 레이블, 고정 너비 또는 다른 자손 요소가 관련될 수 있습니다. 조사 과정이 원인을 파악하도록 두세요.

또한 페이지 오버플로우(page overflow)와 의도적으로 스크롤 가능한 비교 섹션을 구분합니다. 이 점은 테이블이 휴대폰에서 제공할 수 있는 공간보다 더 많은 공간을 필요로 할 때 중요합니다. 페이지 자체는 뷰포트 내에 머무르면서 테이블만 스크롤되도록 하고 싶을 수도 있습니다.

사라지는 스크롤바를 충분한 증거로 받아들이지 않도록 하세요. 에이전트는 overflow-x: hidden을 적용하고 콘텐츠가 잘려나가게 할 수 있습니다. MDN 문서는 숨겨진 오버플로우가 콘텐츠를 자르는 방식에 대해 설명합니다. 페이지 경계뿐만 아니라 콘텐츠와 컨트롤도 검사하세요.

브라우저에서 결과 확인하기

수정 후, 동일한 실패 사례를 다시 확인하세요. 375픽셀에서는 각 계획을 읽고 기본 액션에 도달할 수 있습니까? 320픽셀에서도 긴 레이블이 여전히 읽기 가능한가요? 비교 섹션이 스크롤된다면 최종 열에 도달할 수 있습니까? 1280픽셀에서 데스크톱 배열이나 팔레트가 예상치 못하게 변경되었나요?

각 너비별로 관찰된 결과를 에이전트에게 요청하세요. '반응형입니다(Responsive now)'는 결론일 뿐입니다. 유용한 보고서는 경로, 치수, 수행한 검사 및 남아 있는 제한 사항을 명시해야 합니다. 브라우저 도구를 사용할 수 없다면, 그렇게 언급해야 합니다. 통과하는 빌드가 버튼이 여전히 보이는 것을 의미하지 않습니다.

다음 수정 범위 좁히기

문제가 하나 남았다면, 그 관찰 내용을 중심으로 다음 수정을 작성하세요:

The page now fits at 375 pixels, but the annual billing label overlaps
the price at 320 pixels. Keep the overflow fix. Adjust that label and
price layout, then recheck both widths and the desktop view.

이러한 결과를 관찰한 후에만 이와 같은 표현을 사용하세요. 이는 유지하고 싶은 진행 상황을 보존하며 에이전트에게 더 작아진 남은 문제를 제공합니다. 화면이 전반적으로 더 좋아 보이는지 묻는 대신, 특정 상호작용과 비교하여 다음 결과를 판단할 수 있습니다.

저는 프롬프트를 작성하고 문맥적 후속 조치를 제안하는 데 도움을 줄 Ahed를 만들고 있습니다. 데모 및 대기 목록이 공개되었으며, 데모는 Mac에서 Codex를 보여줍니다. 일반 대중의 앱 접근은 아직 불가능합니다.