AI와 배우자 앱을 만들며 겪은 디자인 시행착오

최근 AI 에이전트와 함께 배우자라는 macOS 학습 앱을 만들었다. 공부하고 싶은 주제를 입력하면 AI가 학습 계획과 교재를 만들고, 설명과 시각자료를 함께 보며 공부하는 앱이다. 구현은 주로 Codex에 맡기고, 나는 필요한 기능과 공부하고 싶은 방식을 전달하며 결과를 확인했다.

처음에는 터미널 UI로 시작했다. 하지만 글씨가 작고 화면이 어두워 오래 읽기에는 불편했다. 소프트웨어 공학뿐 아니라 과학이나 역사 같은 주제도 글과 그림으로 공부할 수 있는 앱을 원했다. 읽기 편한 화면이 중요하다고 생각해 SwiftUI를 사용하는 macOS 네이티브 앱으로 옮겨보기로 했다.

그렇게 만든 첫 화면은 마음에 들지 않았다. 앱은 실행됐지만 내가 기대했던 macOS 앱의 느낌과 달랐고, 버튼과 메뉴도 직관적이지 않았다. 실제로 사용해보니 정렬이 어긋나거나 스크롤이 버벅이는 문제도 있었다. 그때부터 화면을 다시 보여주고, 참고 자료를 전달하고, 불편한 부분을 하나씩 설명하기 시작했다.

Liquid Glass 문제에는 기술적인 원인도 있었다

나는 macOS 디자인을 다루는 스킬과 사례들을 전달하고, Apple의 최신 공식 디자인 가이드도 찾아보도록 요청했다. 관련 API를 적용했다는 설명을 받았는데도 일부 버튼은 여전히 이전 스타일로 보였다. 상단과 본문의 세로 경계도 어긋나 있어, 화면을 캡처하고 전체적으로 일관되게 적용됐는지 다시 확인하게 했다.

점검 과정에서 최신 SDK로 코드를 컴파일했더라도 최종 실행 파일은 이전 SDK로 링크된 앱처럼 기록되어 있다는 것이 밝혀졌다. 빌드 과정에서 링크할 SDK를 명시한 뒤에야 시스템 사이드바 버튼, 검색창과 툴바가 새 디자인으로 표시됐다. 코드를 작성할 때 사용한 API와 실제 실행 결과 사이에 차이가 있었던 것이다.

내가 디자인 맥락을 충분히 주지 않은 부분도 있었다. 하지만 이런 문제까지 모두 사용자의 프롬프트 부족으로 설명할 수는 없다고 생각한다. 에이전트가 구현을 맡았다면, 빌드 결과와 실제 화면까지 함께 확인하는 게 자연스럽지 않을까?

불편하다는 말을 구체적인 기준으로 바꾸기

처음에는 화면이 어둡다거나 디자인이 마음에 들지 않는다는 말을 많이 했다. 실제로 그렇게 느꼈지만, 무엇을 어떻게 바꿔야 할지까지 설명하지는 못했다. 화면을 함께 보며 피드백을 이어가니 내가 중요하게 여기는 조건이 조금씩 분명해졌다.

상단 메뉴는 아이콘만 보고 기능을 알아보기 어려웠다. 다른 소프트웨어의 구성을 비교해달라고 요청한 뒤, Apple의 문서 작성 앱 Pages처럼 아이콘에 기능 이름을 함께 표시하는 방식을 골랐다. 새 과정, 읽기 설정과 PDF 내보내기 같은 명령이 화면에서 바로 이해됐으면 했다. 툴바와 앱 메뉴에서도 주요 기능을 쉽게 찾을 수 있도록 정리했다.

글자 크기도 조절할 수 있게 하고, 큰 글씨와 좁은 창에서도 읽을 수 있는지 확인하게 했다. 그 과정에서 하단 탐색 버튼과 본문이 겹치는 문제가 드러나 탐색 영역을 스크롤 아래의 별도 행으로 옮겼다. 막연히 보기 좋게 만들어달라는 요청이, 글자를 키워도 버튼이 본문을 가리지 않아야 한다는 조건으로 바뀐 셈이다.

Anthropic의 프론트엔드 디자인 지침도 안내가 없으면 일부 모델이 일반적인 디자인 패턴으로 수렴할 수 있다고 설명한다. 구체적인 방향을 전달하라는 조언은 내 경험과 연결됐다. 다만 웹이나 iPhone의 디자인 규칙을 그대로 적용하기보다, 이 앱에서는 Mac의 창과 메뉴, 키보드 사용 방식에 맞춰 참고 자료를 선택해야 했다.

실제 사용 흐름을 확인하자 다른 문제가 보였다

배우자는 학습자료를 만드는 앱이다. 고정된 샘플이 보기 좋게 표시되는 것만으로는 충분하지 않았다. 나는 계획 생성부터 교재와 시각자료, 퀴즈, 저장 후 재개와 PDF 내보내기까지 실제 흐름으로 QA하도록 요청했다.

실제 생성한 아웃박스 패턴 교재에서는 그림과 설명이 맞지 않았다. 그림의 두 묶음은 위아래로 배치됐는데, 본문과 캡션은 왼쪽과 오른쪽으로 설명하고 있었다. 학습자료를 생성했다는 응답만으로는 드러나지 않는 문제였다.

원본은 보존하고 QA 사본에서 설명과 그림 배치를 수정했다. 이후 생성 지침에는 배치가 달라져도 이해할 수 있도록 사례 이름으로 참조하고, 큰 비교 그림은 나누어 설명하도록 보강했다. 지침을 고쳤다고 모든 생성 결과에서 같은 문제가 사라진다는 보장은 없다. 그림이 존재하는지와 설명을 제대로 전달하는지를 함께 살펴봐야 했다.

스크롤 지연도 확인해달라고 요청했다. 위치가 바뀔 때마다 보관함 전체를 갱신하고 저장하던 경로를, 최신 위치를 모았다가 잠시 입력이 없으면 저장하는 방식으로 바꾸었다. 스크롤 위치 변경 1,000회를 입력한 테스트에서 저장은 1,000번에서 한 번으로 줄었다. 다만 실제 스크롤 지연까지 측정한 결과는 아니다. 검증 범위는 프로젝트 QA 기록에 남겼다.

내가 말하는 취향은 무엇이었을까

이번 작업을 하며, AI가 구현을 맡더라도 원하는 경험의 방향을 정하는 데는 아직 사람의 취향과 판단이 필요한 것 아닐까 생각했다. 내가 중요하게 생각한 것은 밝은 배경이나 버튼 모양만이 아니었다. 오래 읽어도 편한 글씨, 알아볼 수 있는 메뉴, 설명과 일치하는 그림이 필요했다. 학습 앱에서 무엇을 우선해야 하는지에 관한 판단이었다.

그렇다고 정렬이 어긋나거나 잘못된 SDK로 링크되는 문제까지 취향으로 묶을 수는 없다. 기능 이름을 어떻게 보여줄지에는 선호와 사용 맥락이 들어가지만, 글자를 키웠을 때 버튼이 겹치는 문제는 수정해야 할 동작이다. 원하는 방향을 정하는 일과 그 방향대로 구현됐는지 검증하는 일을 구분할 필요가 있었다.

DesignPref에서는 모바일 UI를 평가한 전문가들의 선호가 갈렸고, 일부 모델은 여러 사람의 평가를 합쳤을 때보다 개인의 선호 데이터를 사용했을 때 그 사람의 판단을 더 잘 예측했다. 그래픽 디자인을 다룬 TASTE 연구에서도 실험한 범용 모델과 전문가의 평가에 차이가 있었고, 해당 평가 데이터로 학습한 모델은 개선됐다.

macOS 앱에 관한 연구는 아니지만, 내게는 누구를 위한 결과인지와 평가 기준을 분명히 해야 한다는 점으로 읽혔다.

반복한 요청을 다음 작업의 기준으로 남기기

수정이 이어지면서 같은 내용을 앞으로도 매번 설명해야 할지 생각하게 됐다. 최신 Apple 공식 문서를 확인하고, 실제 앱을 실행하고, 생성된 교재와 그림을 함께 검토하라는 요청을 프로젝트 지침과 품질 기준으로 남기도록 했다. 성능 개선도 저장 횟수와 실제 체감 지연을 구분해서 기록하게 했다.

문서와 함께 린트와 공통 검사, 코드의 책임을 나누는 구조도 정리했다. 공통 규칙은 AGENTS.md에 두고, Claude나 Gemini 같은 다른 도구에서도 같은 규칙을 읽을 수 있도록 연결했다. 도구를 바꿔도 제품의 요구사항과 검증 기준을 이어갈 수 있게 한 것이다.

이전에 AI가 작성한 코드를 어디까지 믿을 수 있을까라는 글에서 반복되는 개입을 작업 흐름과 도구로 정리하면 좋겠다고 생각했다. 배우자에서는 화면을 보며 반복했던 요청들이 그 재료가 됐다. 마음에 들지 않는 결과를 보고, 불편함을 설명하고, 대안을 비교하는 과정에서 내가 원하는 앱의 기준을 구체화할 수 있었다.

다음에는 기능 목록과 함께 오래 읽는 화면인지, 어떤 명령을 자주 쓰는지, 어떤 앱의 조작 방식이 익숙한지부터 전달해보려 한다. 한 화면을 먼저 만들어 실제로 사용한 뒤 나머지를 이어가는 방법도 시도해보고 싶다. 이 과정을 스킬로 정리하거나 공개된 관련 스킬을 참고해도 좋을 것 같다. 내가 어떤 결과를 원하고 무엇을 근거로 만족할 수 있는지를 더 잘 설명하는 것이 다음 작업에서 개선하고 싶은 부분이다.