지난 기사에서는 딸을 위한 학습 지원 앱에 영어 문장 연습 기능을 추가한 이야기를 썼습니다.

이번에는 미뤄두었던 UI 리뉴얼을 진행했습니다.

제4회에서는 다음으로 영어 회화 레슨 평가에 대해 쓸 예정이었지만, 매일 사용하는 앱이기에 먼저 외관과 사용감을 다듬기로 했습니다.

그리고, 오늘 부활한 Fable 5를 사용하고 싶었기에, 이용 한도를 의식하며 사용해 보겠습니다.

이 기사의 주제는 완성된 UI 그 자체보다, AI에게 어떻게 업무를 분담시켜 만들었는가입니다.

제 환경에서는 Fable 5를 설계 및 방향 설정 역할로, Opus 4.8을 구현 역할로 사용했습니다.

그야말로 Tailwind와 AI의 조합 같지만, 뭐 좋습니다.

제1회에서도 "UI는 앞으로 다듬어 나갈 전제"라고 썼었습니다. 동작하는 것을 우선시하여 외관은 잠정적인 상태로 운영하고 있었습니다.

잠정 UI에는 다음과 같은 상태가 남아 있었습니다.

• Tailwind의 기본 색상을 그대로 사용한 파스텔톤 카드가 나열되어 있을 뿐임
• 이모지를 그대로 화면에 배치함
• 일본어 폰트 지정이 제대로 작동하지 않아 실질적으로 시스템 폰트로 표시됨
• 보상인 스티커를 획득하는 순간에 연출이 거의 없음

특히 마지막 부분이 신경 쓰였습니다. 딸에게 있어 가장 큰 하이라이트는 "어떤 몬스터가 나올까" 하는 순간인데, 그 부분이 조용한 카드 표시로 끝나버렸기 때문입니다.

아이가 몰입할 수 있느냐는 이 하이라이트를 얼마나 잘 만들어내느냐에 따라 크게 좌우된다고 생각했기에, UI를 제대로 작업하기로 했습니다.

이번에는 모든 것을 동일한 모델에 맡기는 것이 아니라, 작업의 성격에 따라 두 가지로 나누어 생각했습니다.

공정	내용	실패했을 때의 리스크	적합해 보이는 모델
설계	사양 이해 · 디자인 방향 설정 · 구현 지시서 작성	방향을 잘못 잡으면 전부 다시 해야 함	최상위 (Fable 5)
구현	지시서대로 코드를 작성	국소적이며 수정하기 쉬움	한 단계 아래 (Opus 4.8)

생각 방식은 간단합니다.

방향을 결정하는 공정은 잘못될 경우 후속 공정이 통째로 낭비됩니다. 여기에는 다소 비용을 들여서라도 현명한 모델에 투자할 가치가 높다고 생각했습니다.

반면, 방향이 확정된 후의 구현은 양이 많은 작업입니다. 파일을 여러 개 수정해야 하므로 토큰을 많이 사용합니다. 여기서는 단가를 낮추고 싶습니다.

"어떤 모델을 쓸까"가 아니라 "어느 공정에 어떤 모델을 투입할까"로 생각하는 정리 방식입니다.

먼저 Fable 5에게 기존 코드와 사양서를 읽게 한 뒤, UI 리디자인 지시서를 한 장의 문서로 작성하게 했습니다.

포인트는 머릿속이나 대화 흐름이 아니라, 파일로 남는 지시서로 만들었다는 점입니다. 이것이 그대로 구현 역할 모델에게 전달할 자료가 됩니다.

지시서에 넣은 주요 항목은 다음과 같습니다.

- 변경해서는 안 되는 범위 (API · 타입 · 저장 처리 · 상태 전이)
- 디자인 토큰 (색상 · 폰트 · 모서리 곡률 · 그림자의 구체적 값)
- 공통 UI 컴포넌트 사양 (버튼, 카드, 평가 스탬프 등)
...

특히 효과적이었던 것은 처음에 **"변경해서는 안 되는 범위"**를 명시하게 한 것입니다. 평가나 이미지 생성 처리, 데이터 저장 관련 부분은 이번에 건드리고 싶지 않았기에 그 부분을 먼저 선을 그어 두었습니다.

실제 지시서에서는 다음과 같은 입도로 "건드려서는 안 되는 것"을 나열하고 있습니다 (발췌).

### 변경해서는 안 되는 것
- app/api/** 의 모든 루트, 요청/응답 규약
- lib/** (storage / sticker / pokemon / ai / supabase)
...

이렇게 구체적으로 써두면, 구현 역할 모델이 "좋은 의도로" 평가 로직이나 데이터 구조를 건드려 버리는 사고를 방지할 수 있습니다. 반대로 변경해도 좋은 범위 (components/에 UI 컴포넌트 추가, globals.css, 표시 텍스트 등)도 같은 입도로 작성해 두었습니다.

부수적인 효과로, 설계 단계에서 일본어 폰트 지정이 실질적으로 작동하지 않는 버그를 찾아내 주었습니다. 잠정 UI 시절부터 깨닫지 못했던 결함입니다. 손을 움직이기 전에 기존 코드를 읽게 함으로써 잡아낼 수 있었다고 생각합니다.

지시서 안에서는 색상 등을 구체적인 값까지 쓰게 하고 있습니다 (발췌 · 이미지).

배경: 크림 계열의 부드러운 색
본문 글자: 완전한 검은색이 아닌, 약간 부드러운 진한 색
과목 컬러: 히라가나 / 에이고(영어) / 피아노에 따라 색을 구분
...

이렇게 미리 결정해 두면, 구현 담당자가 색상이나 스타일로 고민하는 일이 없어집니다.

방향성이 확정되었기에, 지시서를 전달하여 Opus 4.8에게 구현을 맡겼습니다 (Sonnet 5를 사용했어도 좋았을 것 같습니다).

지시서에 페이즈(Phase)를 나누어 작성해 두었기에, 그 순서대로 진행하도록 했습니다.

페이즈 1 토대 (폰트 수정 · 디자인 토큰 (Design Token) · 공통 부품)
페이즈 2 전체 화면 적용 (홈 · 각 학습 페이지 · 목록 · 상세)
페이즈 3 보상 개봉 연출 등의 마무리

제약 사항과 방향성이 명확했기 때문에, 구현 담당자가 "여기는 어떻게 할까?"라며 망설이는 상황이 적었고, 담담하게 진행할 수 있었습니다. 마지막에는 npm run lint와 npm run build가 통과하는지, 그리고 개발 서버를 띄워 375px 너비(스마트폰 가정)에서 전체 화면이 깨지지 않는지까지 확인하도록 했습니다.

잠정적이었던 화면이 이렇게 바뀌었습니다.

가장 공을 들인 스티커 획득 연출은, 선물이 흔들리고, 빛나고, 카드가 튀어나오는 흐름으로 만들었습니다. 평가가 높을수록 연출이 화려해집니다.

참고로, 스티커 이미지는 캐릭터 요소를 포함하고 있기 때문에, 게재된 캡처 화면에서는 해당 부분에 모자이크 처리를 했습니다. 제1회에서 썼듯이, 생성 이미지는 어디까지나 가정 내에서만 사용하는 것을 전제로 합니다.

역할 분담의 효과는 체감상 좋았습니다. 방향성의 질은 상위 모델로 담보하면서, 양이 많은 구현은 단가가 낮은 모델로 돌릴 수 있었습니다.

다만, 솔직히 말씀드리면, 이번에는 토큰 (Token) 소비량을 실제로 측정하여 비교한 것은 아닙니다. "상위 모델은 단가가 높고 소비가 빠르다"라는 일반적인 경향에 기반한 방침 수준의 판단입니다. 이 부분은 향후 제대로 측정해 보고 싶습니다.

그럼에도 불구하고, 지시서를 파일로 만들어 두는 이점은 몇 가지 실감할 수 있었습니다.

• 나중에 다시 볼 수 있다
• 구현 담당 모델이 바뀌어도 그대로 인계할 수 있다
• 도중에 "이 부분은 방향이 다르다"라고 깨달았을 때, 지시서를 수정한 뒤 다시 만들 수 있다

반면, 주의도 필요하다고 생각했습니다.

이것은 "상위 모델은 필요 없다"라는 뜻이 아닙니다. 설계를 경시하고 구현만 하위 모델에 통째로 맡겨버리면, 방향이 어긋나 결국 재작업을 하게 되기 쉽다고 생각합니다. 어디를 설계로 간주하여 상위 모델에 맡기고, 어디서부터를 구현으로 분리할 것인가 하는 그 경계 설정이 핵심이었습니다.

※ 매번 이 방식이 최선이라고 보지는 않습니다. 계속해서 검증이 필요합니다.

이번에는 미뤄두었던 UI 리뉴얼을, 설계는 Fable 5, 구현은 Opus 4.8이라는 분담으로 진행했습니다.

배운 점을 일반화하자면, AI 코딩에서는 "어떤 모델을 사용할 것인가"뿐만 아니라 "어느 공정에 어떤 모델을 투입할 것인가"에 따라 효율이 달라진다는 것입니다.

Fable 5를 어디에 투입했을 때 가장 효과적인지에 대한 검증은 다른 프로젝트에서도 계속 진행 중입니다. 이번 UI 개수는 그중에서 "설계 · 방향 설정에 사용하면 효과가 좋다"라고 느낀 한 사례였습니다. 이 부분은 계속해서 시도해 보고 싶습니다. 그나저나, Fable 5에게 출력을 시키면 이용 한도가 순식간에 녹아버리네요 😢

다음에는 이 연출이 실제 기기에서 딸에게 어떻게 다가갔는지, 혹은 미뤄두고 있는 영어 회화 레슨 평가 구현 등에 대해 쓸 수 있으면 좋겠습니다.