AI가 만든 화면을 비교하려면, SlopGrid처럼 같은 질문부터 준비할까요?

핵심 요약 (TL;DR)

SlopGrid 제작자는 한국시간 10월 16일 공개한 Show HN 글에서, 코드를 쓰지 않고 여러 모델의 시각적 결과를 비교하는 도구를 바이브코딩으로 만들었다고 밝혔습니다.[1] 첫 웹앱을 만드는 분에게 흥미로운 점은 모델 순위가 아니라 비교 방식입니다. 같은 요구를 주고, 무엇이 달랐는지 직접 볼 수 있는 작은 과제를 만드는 일입니다.

제작자는 어떤 불편을 풀려고 했을까요?

소개 글에 따르면 SlopGrid는 한 번의 요청으로 나온 결과들을 비교하기 위한 도구입니다. 제작자는 휴대폰에서 사용한다며 모바일 화면의 사용성을 중요하게 여긴다고 설명합니다. 텍스트와 이미지뿐 아니라 SVG와 정적 웹사이트 출력도 지원한다고 밝혔습니다.[1] SVG는 도형을 코드로 표현하는 이미지 형식입니다.

제작자는 Simon Willison의 SVG 비교 글들에서 영감을 받았다고 출처를 남겼습니다. 다만 이 도구로 어떤 모델이 가장 좋다는 독립적인 평가가 나온 것은 아닙니다. 자기 작업에 맞는 비교를 직접 만들어 보려는 제작 사례로 읽는 편이 정확합니다.

바이브코딩으로 만들었다는 말은 어디까지 확인됐나요?

확인한 근거는 제작자의 공개 설명입니다. 제작자는 최근 며칠 동안 이 앱을 만들어 사용했다고 말하지만, 어떤 코딩 모델을 썼는지나 전체 개발 기록까지 공개한 것은 아닙니다.[1] 따라서 ‘비개발자가 특정 도구 하나로 완성했다’는 이야기로 넓힐 수 없습니다.

공개 사이트 주소에 대한 응답은 확인했지만, 이번 조사에서는 모델 호출과 결과 생성까지 시험하지 않았습니다.[2] 지원 기능은 제작자의 설명으로 구분하고, 실제 사용성이나 비용은 평가하지 않습니다. 결과 화면을 볼 수 있다는 것과 같은 조건에서 재현된 성능을 확보했다는 것은 다른 이야기입니다.

첫 웹앱에서는 어떤 비교 과제를 만들면 좋을까요?

모델에게 막연히 ‘예쁜 페이지’를 요청하기보다, 동일한 사용자의 행동을 지정해 보세요. 예를 들어 예약 날짜를 고르고 제출하는 화면이라면, 빈 입력 안내와 제출 중 상태, 오류 뒤 다시 입력하는 흐름을 요구사항에 함께 적을 수 있습니다. 이는 SlopGrid에서 직접 실행한 예제가 아니라 독자를 위한 실습 제안입니다.

같은 문장을 각 도구에 전달한 뒤에는 색감보다 먼저 요구한 상태가 존재하는지 살펴보세요. 한 결과에는 오류 안내가 있고 다른 결과에는 없다면, 그 차이를 기록하면 됩니다. 모델 이름만 남기지 말고 요청문, 생성 시점, 사용한 설정과 결과 파일을 함께 보관하는 편이 좋습니다.

한 번 잘 나온 결과로 도구를 골라도 될까요?

SlopGrid가 내세운 한 번의 요청 비교는 관찰의 출발점이지, 모든 개발 작업의 우열을 정하는 시험은 아닙니다. 정적 화면을 만드는 과제와 저장·로그인까지 연결하는 과제는 완료 조건이 다릅니다. 화면이 근사해도 실제 데이터가 남는지까지 확인된 것은 아닙니다.

첫 비교에서 마음에 든 결과를 골랐다면, 같은 입력으로 다시 만들거나 요구사항 하나만 바꾸어 보세요. 결과가 바뀐 이유를 설명할 수 있는 작은 기록이 쌓일수록 도구 선택도 덜 막연해집니다. 비교의 목적을 승자 선정이 아니라 내 앱의 부족한 조건 발견에 두시길 권합니다.

FAQ: SlopGrid가 특정 모델의 우승을 증명하나요?

아닙니다. 제작자는 모델들의 강약에 대한 자신의 감을 개선하는 데 도움이 됐다고 설명합니다.[1] 이를 공인 순위나 모든 프로젝트에 적용되는 결론으로 바꾸지 않습니다.

FAQ: 화면 비교만으로 MVP 검증이 끝나나요?

아닙니다. 화면 비교 뒤에는 버튼 동작, 잘못된 입력, 저장 후 재열기처럼 실제 행동을 확인하는 단계가 남습니다. 직접 확인하지 않은 항목은 통과가 아니라 미확인으로 기록해 두세요.

출처
[1] https://news.ycombinator.com/item?id=50118127
[2] https://slopgrid.com/
관찰: 2026-10-17 KST