원래 hexisteme notes에 게시되었습니다.

얼마 전 저는 왜 여러분의 바이브 코딩(vibe-coded) 앱이 예상보다 더 나빠 보이는지에 대해 글을 썼습니다. 그 포스트는 원인을 진단했습니다. 이번 글은 실제 업무에서 실제로 효과가 있었던 해결책에 관한 것입니다. 바로 제가 개발 중인 여행 경비 분담 앱의 마스코트를 재디자인하는 것이었습니다.

마스코트는 앱의 얼굴입니다. 온보딩 (onboarding), 설정 (settings), 통계 화면 (stats screen), 지도 (map), 일기 (diary), 정산 보고서 (settlement report), 그리고 5개의 작은 미니 게임 등 20곳 이상의 장소에 등장합니다. 그런데 기존 마스코트는 아무것도 아니었습니다. 원 하나가 머리와 몸통 역할을 동시에 수행했습니다. 다리도 없었고, 손도 없었으며, 눈썹도 없었습니다. 눈은 X자 하나가 전부였습니다. 시각적 정체성(identity)은 색이 들어간 원 하나에 불과했습니다. 그것이 별로라는 것은 알고 있었습니다. 하지만 무엇을 바꿔야 할지는 말할 수 없었습니다.

말은 그림으로 수렴되지 않는다

저는 이 문제에 대해 계속 맴도는 말만 반복했고, 제가 협업하던 AI도 마찬가지였습니다. 더 둥글게? 모자를 씌울까? 눈을 더 크게? 모든 문장이 합리적으로 들렸지만, 그 중 어떤 것도 결정을 내리는 데 도움이 되지 않았습니다. 어느 시점에 저는 실제로 무슨 일이 일어나고 있는지 깨달았습니다. 이것은 정보의 부족이 아니었습니다. 누군가 사실을 찾아올 필요도 없었습니다. 그것은 충실도 (fidelity)의 부족이었습니다. 시각적 결정은 산문 (prose)으로 수렴될 수 없습니다. 왜냐하면 산문은 그 결정이 존재하는 매체가 아니기 때문입니다.

그것이 신호입니다. 토론이 루프를 돌고 더 많은 말이 도움이 되지 않을 때, 당신에게 필요한 것은 더 많은 분석이 아니라 그림입니다. 그래서 저는 논쟁을 멈추고 프로토타입 (prototypes)을 만들었습니다.

더 많은 색조가 아닌, 세 가지 변형

제가 스스로에게 준 규칙은 다음과 같습니다. 팔레트 교체 (palette swaps)가 아니라, 구조적으로 (structurally) 다른 변형을 만드는 것입니다. 다른 실루엣 (silhouette), 다른 해부학적 구조 (anatomy), 정체성을 전달하는 다른 도구. 같은 모양을 다른 색으로 다시 칠하는 것은 아무것도 가르쳐주지 않습니다. 진정으로 다른 세 가지 생명체는 실질적인 선택을 강요합니다.

저는 세 가지를 만들었고, 나란히 놓고 볼 수 있도록 각각을 액션 시트 (action sheet)로 렌더링했습니다:

• A, 젤리빈. 제가 이미 가지고 있던 것의 안전한 진화입니다. UI에 깔끔하게 들어맞지만, 그 존재 자체가 머리 위에 떠 있는 동전 하나에 달려 있습니다. 크기를 줄이면 다시 단순한 구체일 뿐입니다.
• B, 지갑. 사물 의인화(Object personification): 플랩과 스냅 버튼, 바느질이 된 지갑 몸통에, 위로 돈뭉치가 살짝 보이고, 짧은 팔다리를 가진 캐릭터가 지갑 앞면에 얼굴을 가지고 있습니다. 감정 표현에는 두 번째 채널이 생겼습니다. 기분이 좋을 때는 돈뭉치가 더 높이 솟아오릅니다.
• C, 고양이. 게임에 적합한 최대의 표정 표현력을 가졌지만, '재무 관리자'라는 역할은 스카프 하나에 의존하고 있으며, 여행 및 돈이라는 맥락과의 연결고리가 약합니다.

그러고 나서 저는 바라보았습니다. 코드가 아니라 그림을요.

코드 리뷰로는 잡을 수 없는 버그

지갑의 첫 렌더링에는 diff를 읽는 것만으로는 절대 찾을 수 없는 문제가 있었습니다: 팔이 다처럼 보였습니다. 그 작은 캐릭터는 팔이 없고 네 개의 다리를 가진 것처럼 보였죠.

원인은 한 줄에 있었습니다. 팔의 회전 기준점(rotation anchor)이 anchor: .bottom — 즉 손가락 끝 부분으로 설정되어 있어, 팔이 어깨를 중심으로 회전하는 것이 아니라 손을 중심으로 회전하고 있었던 것입니다. 어깨 부분이 고정된 손가락 끝 주위를 휘두르고 있었습니다. 이는 완전히 평범하고 그럴듯해 보이는 값의 코드였습니다. .bottom은 정상적인 기준점입니다. 소스코드 어디에도

제가 그 안에 있을 때, 거의 회귀(regression)를 일으킬 뻔했습니다. 마스코트의 초기화자(initializer)는 expression이라는 매개변수를 받는데, 저는 이 expression이 _표정(facial expression)_을 의미한다고 가정하고 있었습니다. 어차피 얼굴을 재구축할 예정이었기 때문에, 저는 그것을 삭제하려고 했습니다.

삭제하기 전에 호출 지점(call sites)들을 검색해 보았습니다. expression은 전혀 얼굴과 관련이 없었습니다. 그것은 언어, 지도, 통계, 일기, 소비, 또는 Pro를 위한 작은 표시자인 화면 컨텍스트 배지 채널(screen-context badge channel)이었고, 여덟 개의 호출 지점들이 이 값을 전달하고 있었습니다. 이것을 삭제하면 제가 변경하는 얼굴과는 아무 관련이 없는 여덟 군데의 기능이 조용히 고장 났을 것입니다.

배운 점은 따분하지만 계속 임대료를 내게 만듭니다: 매개변수의 계약(contract)을 변경하기 전에는 모든 호출 지점을 읽으세요. 이름은 의미에 대한 추측일 뿐이고, 호출 지점들이 바로 그 의미입니다. 저는 배지를 유지했고, 몸통의 흔들림과 분리하여 둘 다 더 명확하게 보이도록 했습니다.

지갑을 선택한 이유

저는 B, 즉 지갑을 선택했습니다. 이유는 한 문장으로 요약됩니다: 실루엣만으로도

렌더링 결과물을 좋아하는 것만으로는 증거가 될 수 없습니다. 결정을 내리기 전에, 만약 선택이 틀렸다면 무엇을 _관찰(observe)_하게 될지 — 즉 반증 사례(falsifiers) — 를 적어두었고, 그 후 실제 앱에서 이를 확인했습니다. 큰 화면을 위해 시뮬레이터(iPhone 17 Pro Max, iOS 26.3)에서 빌드 및 실행하였으며, 추가로 idle, wave, stunned, laugh 상태에 걸쳐 28, 36, 44, 64, 96pt 크기로 프로덕션 마스코트를 렌더링하는 헤드리스 사이즈 래더(headless size ladder)를 사용했습니다.

• "지갑이 작은 크기에서는 읽을 수 없고 직사각형처럼 보인다." 발생하지 않았습니다. 지갑은 36pt와 44pt에서 명확하게 읽을 수 있습니다 — 덮개(flap), 지폐, 스티치, 그리고 사지(limbs)가 모두 식별 가능합니다. 리스트 행(List rows)은 44pt이므로 안전합니다. 오직 28pt에서만 산호색 덩어리(coral blob)로 퇴화하며, 28pt는 단 하나의 지점, 즉 단일 게임 액센트(game accent)에서만 나타났습니다. 저는 그 한 곳을 36pt로 높였습니다.
• "미니게임에서 감정이 식별 불가능하다." 부분적으로 사실입니다. 감정은 64pt 이상에서 명확하며, 공통 패배 마스코트는 72pt이므로 결정적인 순간에는 문제가 없습니다. 하지만 28~36pt의 작은 게임 액센트에서는 도발(taunt)과 웃음(laugh), 기절(stunned)이 흐릿해집니다 — 얼굴이 몸에 비해 작기 때문입니다. 이는 사전에 등록된 리스크였으며, 저는 계획된 크기 상향과 함께 이를 수용했습니다.
• "여행 맥락이 상실된다." 여전히 해결되지 않은 상태입니다. 지갑은 돈을 의미하지, 여행을 의미하지는 않습니다. 현재로서는 온보딩(onboarding)과 헤더 카피(header copy)가 텍스트로 여행 맥락을 전달하고 있으며, 저는 추측하기보다 실제 사용자 피드백을 위해 이 문제를 남겨두기로 했습니다.

세 가지 중 두 가지는 발생하지 않았거나 감내할 수 있는 수준이었고, 남은 하나는 명시된 계획과 함께 정직하게 열려 있는 상태입니다. 이것은 나중에 제가 방어할 수 있는 결정입니다. 무엇이 이 결정을 실패하게 만들지 미리 적어두었기 때문입니다.

검증 표면조차 검증이 필요하다

좋은 상기 사항이기에 한 가지만 더 덧붙입니다. 시뮬레이터에서 이 모든 것을 확인하는 동안, 모든 이모지가 토푸 박스(tofu box) — 즉 작은 "?" 사각형 — 로 렌더링되었습니다. 저의 첫 본능은 버그를 배포했다는 것이었습니다.

그렇지 않았습니다. grep을 실행해 보니 어디에도 커스텀 폰트가 없었습니다. 모든 이모지는 시스템 폰트의 일반 Text를 통해 처리되고 있었습니다. 이는 실제 기기에서는 Apple Color Emoji로 폴백(fallback)되어 정상적으로 렌더링된다는 것을 의미합니다. 토푸(tofu) 현상은 iOS 시뮬레이터 런타임의 아티팩트(artifact)였습니다. 즉, 제품 버그가 아니라 해당 시뮬레이터 빌드에 이모지 폰트가 단순히 로드되지 않았던 것입니다. 마스코트 자체는 순수 SwiftUI 도형(shapes)으로 구성되어 있어 모든 크기에서 정상적으로 보였습니다.

교훈: 검증하는 표면(surface) 또한 당신에게 거짓말을 할 수 있습니다. 한 번의 렌더링은 팔(arms)에 대한 진실을 말해주었지만, 또 다른 렌더링은 이모지에 대해 거짓을 말했습니다. 당신은 자신이 어떤 표면을 보고 있는지 알아야 합니다.

시각적 결정을 위한 효과적인 루프

이 경험을 통해 도출된 핵심 루프는 다음과 같습니다:

1. 충실도(fidelity)와 정보의 차이를 진단하십시오. 논의가 겉돌고 더 많은 말이 도움이 되지 않는다면, 그것은 충실도의 문제입니다. 토론하지 말고 렌더링하십시오.
2. 색조(tint)를 바꾸지 말고, 세 가지 구조적 변형(structural variants)을 만드십시오. 색상이 아닌, 실루엣과 해부학적 구조(anatomy)를 다르게 해야 합니다.
3. 코드를 리뷰하기 전에 먼저 렌더링하고 확인하십시오. AI는 자신이 그린 것을 볼 수 없으며, 당신 또한 디프(diff) 상에서는 볼 수 없습니다. 스크린샷이 실측값(ground truth)이며, 소스 코드는 그렇지 않습니다.
4. 컨트랙트(contract)를 건드리기 전에 호출부(call sites)를 grep 하십시오. 파라미터의 이름은 추측일 뿐이지만, 그 사용처는 의미 그 자체입니다.
5. 선택이 틀렸음을 증명할 수 있는 요소를 미리 등록하고, 실제 크기에서 확인하십시오. 사진이 마음에 든다는 것만으로는 증거가 될 수 없습니다.

전편에서는 왜 '바이브 코딩(vibe-coded)'된 UI가 생각보다 더 나쁘게 나오는지 설명했습니다. 이것이 그 해답입니다. 볼 수 없는 코드를 리뷰하는 것을 멈추고, 볼 수 있는 그림을 렌더링하기 시작하십시오.

더 많은 노트는 hexisteme.github.io/notes에서 확인할 수 있습니다.