이 영상에서 단테는 숙소 검색, 대시보드, 쇼핑몰, 작업 보드, 고객 인박스, 랜딩 페이지 여섯 가지 앱을 Jev만 쓰는 방식, Laya만 쓰는 방식, 그리고 각각에 LLM을 한 번 더 붙이는 방식까지 네 가지로 구성해 직접 사용해 봤습니다. 모델이 프론트엔드 화면 구성을 바꾸게 하고 싶은 개발자, 특히 디자인이 바뀌어도 사용자 상태를 어떻게 지킬지 고민하는 분에게 참고가 됩니다.
실험 구조: 모델은 무엇을 정하는가
먼저 실험의 범위를 분명히 해 둡니다. 카드, 필터, 장바구니, 클릭 동작 같은 부품은 React로 미리 구현해 두었습니다. 모델은 이 부품을 어떻게 배치하고, 어떤 테마와 밀도로 보여 줄지를 결정합니다. 빈 화면에서 앱 코드를 처음부터 작성하게 한 실험이 아닙니다.
흐름은 다음과 같습니다.
- Jev와 Laya에 같은 질문과 선택지를 줍니다.
- 결과를 검증해 화면 명세로 바꾸고, React가 그 명세대로 화면을 그립니다.
- LLM을 붙인 두 경로는 이 명세를 받아 디자인 속성과 문구만 수정합니다. LLM도 실행할 코드를 마음대로 내보내는 구조는 아닙니다.
두 LLM 경로에는 같은 Qwen3 Coder Next와 같은 제공자 설정(Parasail, bf16)을 썼습니다. 처음 생성할 때 Jev의 결과 하나를 'Jev only'와 'Jev + LLM'이 공유하고, Laya 쪽도 마찬가지입니다. 출발점을 따로 뽑아 유리한 화면만 고르는 일을 막기 위해서입니다. 비교 조건으로 Jev는 jev-1.13.0, Laya는 고정된 multilingual 체크포인트를 로컬 MPS에서 돌렸습니다. Laya는 Jev의 오픈소스 대안으로, 자기 컴퓨터에서 직접 실행할 수 있습니다.
디자인을 바꿔도 사용자 상태는 남는다
숙소 앱에서는 숙소 하나를 저장하고 다른 숙소와 함께 비교 목록에 넣었습니다. 저장 버튼과 비교 목록은 앱 상태에 연결되어 있습니다. 이 상태에서 어두운 테마와 사이드바 배치를 요청하자 색과 배치는 바뀌었지만 저장한 숙소와 비교 중인 두 숙소는 그대로 남았고, 모바일 폭에서도 유지됐습니다.
단테는 이것이 모델의 기억력 덕분이 아니라고 짚습니다. React 쪽에서 사용자 선택과 화면 디자인 명세를 따로 관리하도록 구현했기 때문입니다. 모델은 화면을 바꾸고, 앱은 사용자가 하던 일을 이어 갑니다. 기존 서비스에 붙일 때도 이 경계가 필요합니다.
다른 앱에서도 같은 점을 확인했습니다.
- 대시보드: 기간을 7일로 바꾸고 특정 지표 값 767을 확인한 뒤, 오가닉 필터로 거래 두 건 합계 178달러를 남겼습니다. 어두운 디자인으로 바꿔도 기간과 필터가 유지됐습니다.
- 쇼핑몰: 헤드폰과 스피커를 담고 헤드폰 수량을 2개로 바꿔 전체 3개, 합계 527달러가 됐습니다. 밝은 화면과 그리드 배치로 바꾼 뒤에도 장바구니가 그대로였습니다. 결제까지 만든 앱은 아니고, 확인한 범위는 상품 탐색과 로컬 장바구니입니다.
- 인박스: 대화를 열고 답변을 저장한 뒤 해결 처리했습니다. 화면 구성을 다시 요청해도 선택한 대화와 답변, 해결 상태가 남았습니다. 고객과 대화는 모두 샘플이고 실제로 메시지를 보내지 않습니다.
- 랜딩 페이지: 요금을 월간으로 바꾸고 FAQ를 펼치고 작업 공간 이름을 입력했습니다. 디자인 수정 뒤에도 선택한 탭과 요금, 입력값이 유지됐습니다. 반응형 동작은 미리 만든 컴포넌트가 담당하며, 모든 기기 조합을 검증한 것은 아닙니다.
실패를 가리지 않기
첫 생성에서 Jev + LLM 요청 하나가 429 오류로 실패했고, 작업 보드의 Laya + LLM 수정 요청도 429로 실패했습니다. 단테는 이 실패를 성공한 화면으로 덮지 않고 그대로 남겼습니다. 작업 보드에서는 새 디자인이 완성됐다고 말할 수 없지만, 이전 화면과 작업 상태는 유지됐습니다. 실제 서비스라면 모델 호출이 실패해도 사용자가 하던 작업은 사라지지 않아야 한다는 점을 보여 주는 장면입니다.
속도와 요청 반영 비교
촬영과 별도로 고정된 영어 요청 6개를 4가지 방식으로 한 번씩, 총 24개 결과를 얻은 기록이 있습니다. 조건별 1회 실행이라 작은 표본으로 봐야 합니다.
- 서버 처리 시간 중앙값: Laya only 약 159.3ms, Jev only 약 648.0ms
- LLM까지 거친 경로: Jev 쪽 약 3.08초, Laya 쪽 약 2.79초
- 화면을 그리는 시간은 포함하지 않았습니다.
Laya는 이 컴퓨터에 이미 올라온 모델을 썼고 Jev는 네트워크로 API를 호출했으므로 하드웨어와 통신 조건이 다릅니다. 그래서 이 숫자로 모델 자체가 몇 배 빠르다고 일반화하지 않았습니다.
요청 반영 정도는 테마와 배치 같은 속성 7개와 요청한 섹션 포함 여부, 즉 요청당 8개 항목을 검사했습니다. 방식마다 48개 항목입니다. Jev only는 48개, Laya only는 30개가 일치했고, LLM을 붙인 두 경로는 모두 48개가 일치했습니다. Laya의 초기 결과에서 틀린 속성값과 빠진 섹션을 LLM이 고친 것이고, Jev는 처음부터 기준을 만족해 LLM을 붙여도 일치 수가 늘지 않았습니다. 이 수치는 미적 품질 점수가 아니라 응답 값이 요청과 맞는지를 본 것이며, 실행 뒤에 정한 기준이라는 점도 공개했습니다. LLM 단독 대조군이 없으므로 "Jev나 Laya를 앞에 붙이는 편이 LLM 단독보다 낫다"는 주장까지는 할 수 없습니다.
비용은 24개 결과 표본에서 합계 약 0.0023달러였습니다. Jev는 공개 요금으로 추정했고 LLM은 응답에 담긴 비용을 썼으며, 로컬 Laya를 돌린 컴퓨터와 전기 비용은 빠져 있습니다. 실제 촬영에서는 초기 생성과 수정을 합쳐 48개 결과 중 46개가 출력 검증을 통과했고, 실패 2건이 앞서 본 429였습니다. 인박스와 랜딩 촬영부터는 LLM 요청을 하나씩 처리하는 대기열을 넣었기 때문에 앞뒤 촬영 시간을 한 표로 묶어 순위를 매기면 안 됩니다.
내 프로젝트에 붙이는 방법
단테가 제안하는 순서는 이렇습니다.
- 모델이 고를 수 있는 범위를 먼저 정합니다. 사용할 컴포넌트, 배치, 테마를 목록으로 만듭니다.
- 모델 응답을 검증해 화면 명세로 바꿉니다.
- 장바구니나 선택 항목 같은 사용자 상태는 명세와 분리해서 관리합니다.
- Jev나 Laya만으로 요청을 얼마나 지키는지 먼저 보고, 부족한 부분을 LLM이 실제로 고치는지 확인합니다.
필요할 때만 LLM을 호출하는 방식은 다음에 검증할 설계로 남겼습니다. 앱 코드와 입력 조건, 결과 명세, 실패 기록 요약은 jev-frontend-lab 저장소에 공개되어 있고, 모델 API 키는 직접 설정해야 합니다. Jev API는 공식 문서에서 확인할 수 있습니다.
정리
- 이 실험은 미리 만든 React 부품을 모델이 배치·테마·밀도 차원에서 조합하는 구조이며, 앱 코드를 모델이 처음부터 쓴 것이 아닙니다.
- 디자인이 바뀌어도 선택 항목과 장바구니가 유지된 이유는 사용자 상태와 디자인 명세를 분리해 관리했기 때문입니다.
- 작은 표본에서 서버 처리 시간 중앙값은 Laya only 약 159.3ms, Jev only 약 648.0ms였지만, 실행 환경이 달라 모델 속도로 일반화할 수 없습니다.
- 요청 일치 항목은 Jev only 48/48, Laya only 30/48였고, LLM을 붙이면 두 경로 모두 48/48이 됐습니다.
- 429 실패를 숨기지 않았고, 모델 호출이 실패해도 사용자 작업이 남도록 설계하는 것이 중요하다는 점을 보여 줍니다.