저는 vooy에 와서 처음으로 개발을 시작한 신입 개발자예요. 아직 프로덕트 디자이너가 합류하기 전인 팀에서, 동료들과 함께 앱의 화면을 만들고 고쳐가고 있습니다.
우리는 사람과 AI 에이전트가 함께 쓰는 메신저, vooy를 만들고 있습니다.
대화로 일정을 챙기고, 일상의 일을 에이전트에게 맡기는 앱이에요. 이런 메신저는 아직 시장의 익숙한 형태가 정해져 있지 않았고, 그대로 참고할 만한 제품도 많지 않았습니다.
개발자들은 모두 에이전트와 코드를 짰습니다. 기능은 빠르게 늘었지만, 화면을 열어보면 아쉬움이 남았습니다. 버튼은 동작하는데 무엇부터 눌러야 할지 헷갈리고, 같은 기능도 화면마다 다른 얼굴을 하고 있었습니다. 앱은 계속 만들어지는데, 화면을 더 좋게 만드는 일은 자꾸 뒤로 밀렸습니다.
저도 디자인에 자신이 있는 사람은 아니었습니다. 그래서 판단할 수 있는 화면을 많이 만들어 팀과 함께 살펴보기로 했습니다. 시안도, 비교하는 도구도 에이전트와 함께 만들면서요.
가장 큰 변화는 코드를 읽는 에이전트와 화면을 그리는 에이전트를 나누면서 시작됐습니다. 둘 사이에는 기능 정의서만 건넸습니다. 그 방식에 도달하기까지, 두 번의 실험을 했습니다.
디자인 회의 대신, 시안을 투표받았습니다
“어떤 화면이 좋을까요?”라는 질문에 말로 답하기는 어려웠습니다. 그래서 같은 홈·대화·캘린더를 15가지 방향으로 만들어 펼쳤습니다. 누군가는 캐릭터를 크게 보여주고, 누군가는 정보를 빼곡하게 정리하고, 누군가는 대화에 집중했습니다. 눈앞에 화면이 있으니 취향의 차이도 구체적으로 이야기할 수 있었습니다.
긴 준비 기간은 없었습니다. 에이전트에게 시안과 투표 사이트를 만들게 하고, 그날 밤 Vercel에 배포해 URL을 공유했습니다. 팀원들은 직접 화면을 살펴보고 5점 척도로 점수를 남겼습니다.
당신의 눈에는 어떤가요?
당시 15개 시안으로 다시 만든 체험판입니다. 화면 속 대화는 목업입니다.
점수만으로는 이유를 알 수 없었습니다. 그래서 좋거나 아쉬운 부분을 화면 위에서 직접 찍거나 드래그해 의견을 남기게 했습니다. “6번이 좋아요”에서 끝나는 대신, “캐릭터가 나에게 말을 거는 느낌은 좋은데, 한 화면에 두 번 나올 필요는 없어요”까지 들을 수 있었습니다.
긍정적인 의견은 살릴 이유가 되고, 부정적인 의견은 고칠 위치가 됐습니다.
실제로 받은 의견 세 묶음과, 이를 반영한 통합 시안을 함께 놓았습니다.
좋은 이유도, 아쉬운 이유도.
점수에 담기지 않는 이유를 화면 위에 남겼습니다.
10명의 참여
124개의 구체적인 의견
긍정 39부정 85
크게 보여주되, 한 번만.
캐릭터는 홈 상단에 크게 한 번만 남겼습니다. 그 아래에서 바로 대화를 시작하게 했습니다.
10명이 남긴 핀은 124개였습니다. 긍정 의견 39개, 부정 의견 85개.
저는 피드백을 24묶음으로 정리하고, 반영할 방향을 에이전트에게 건네 홈·대화·캘린더 등을 포함한 여섯 화면의 앱 초안으로 합쳤습니다.
투표 도구를 만들고, 피드백을 모으고, 통합 시안으로 옮기는 데 하루면 충분했습니다.
화면을 놓고 이야기하니 무엇을 바꿀지도 금방 선명해졌습니다. 에이전트와 함께라면 그 판단을 곧바로 다음 버전에 담을 수 있었습니다.
코드를 읽는 에이전트와 화면을 그리는 에이전트를 나눴습니다
방향을 정했다고 끝은 아니었습니다. 에이전트와 앱을 개발하는 동안 화면은 계속 늘었고, 그 사이사이에 어색함도 쌓였습니다. 같은 설정인데 간격이 다르고, 버튼의 무게가 제각각이고, 설명 한 줄이면 될 자리에 비슷한 문장이 반복됐습니다. 하나씩 보면 사소하지만, 앱 전체를 놓고 보면 일관성이 무너지고 있었습니다.
이번에도 agent-driven으로 UI를 개선하기로 했습니다.
하지만 에이전트는 자기 코드베이스를 보는 순간 UI 독창성이 크게 떨어집니다.
현재의 컴포넌트, 화면을 나눈 방식, 정보의 순서가 그대로 다음 설계의 기준점이 되기 때문입니다. “새롭게 그려줘”라고 해도 이미 있는 틀 안에서 간격과 색을 고치는 데 머무는 겁니다.
코드에는 두 가지가 섞여 있습니다. 제품이 반드시 해야 하는 일과, 그 일을 지금 화면에 표현한 방식입니다. 메시지를 보내고 실패하면 다시 시도할 수 있어야 한다는 것은 지켜야 할 기능입니다. 입력창을 어디에 놓을지, 실패를 어떤 형태로 보여줄지는 새로 결정할 수 있는 UI입니다. 그런데 코드 전체를 넘기면 이 둘을 함께 물려주게 됩니다.
그래서 프롬프트의 표현보다 에이전트가 읽는 컨텍스트의 경계를 바꿨습니다. 현재 앱을 읽는 조사 에이전트와 새 화면을 그리는 설계 에이전트를 나누고, 둘 사이에는 기능 정의서만 오가게 했습니다.
조사 에이전트는 코드와 실제 화면에서 행동·데이터·상태·제약·의존성을 추출하고, 기능마다 ID를 붙였습니다. 색, 배치, 컴포넌트 이름, 버튼 위치는 인계 문서에서 제외했습니다. 원본 코드와 기능을 연결하는 근거표는 별도 파일로 남기고, 설계 에이전트에게는 전달하지 않았습니다. 기능을 이해하되, 그 기능의 기존 생김새까지 따라가지 않게 하려는 장치였습니다.
화면 대신, 기능을 건넸습니다.
실패한 메시지 다시 보내기
- 할 수 있는 일
- 전송에 실패한 메시지를 다시 보낸다. 재전송 결과에 따라 전송 상태를 갱신하고 …
- 데이터
- 메시지 ID, 대화 ID, 메시지 내용, 전송 상태, …
- 상태·예외
- 전송 중 · 완료 · 실패. 다시 실패해도 작성한 내용은 유지한다. 연결이 끊긴 경우 …
- 제약
- 같은 메시지가 중복으로 전송되지 않아야 한다. 이미 처리 중인 요청이 있다면 …
- 의존
- F-EX02 · 메시지 전송
색·배치·컴포넌트는 지정하지 않습니다.
근거표는 따로 보관합니다.
features-sources.md이 기능이 어느 코드에서 나왔는지 기록하되, 설계 에이전트에게는 건네지 않습니다. 코드 경로도 기존 UI를 따라가는 단서가 되니까요.
같은 ID로 기능을 찾습니다.
화면의 구조는 새로 정합니다. 기능 ID를 새 화면에 연결하면, 모양이 달라져도 빠진 기능을 확인할 수 있습니다.
기능 정의서의 일부를 보여주는 공개용 예시입니다. 실제 문서 형식을 따르되 기능·ID·경로는 바꿨습니다.
이 기능 정의서는 두 에이전트 사이의 입력 계약이 됩니다. 예시의 F-EX01은 “실패한 메시지를 다시 보낼 수 있어야 한다”는 동작을 남깁니다. 재전송을 어디에, 어떤 모양으로 보여줄지는 설계 에이전트가 정합니다. 기존 코드와 캡처 경로도 작업 범위에서 제외해, 기능 정의서에서 출발하게 했습니다.
새 화면의 출발점은 외부에서 찾았습니다. 설계 에이전트에는 기능 정의서와 이름·마스코트 같은 최소한의 브랜드 자료를 건넸습니다. 그리고 Mobbin MCP를 활용해 대화 목록의 정보 순서, 캘린더의 밀도, 빈 화면의 안내 같은 패턴을 직접 조사하게 했습니다. 기존 컴포넌트에 기능을 끼워 넣는 대신, 기능에 맞는 패턴을 찾아 화면을 새로 조립하게 한 것입니다.
설계가 끝나면 같은 기능 ID를 새 화면에 연결합니다. F-EX01이 새 대화 화면의 어디에서 제공되는지 확인하는 식입니다. 표현은 새로 만들어도, 제품이 해야 할 일은 ID로 추적합니다. 이렇게 기능 누락을 살피고 방향을 고른 뒤에야, 구현 에이전트가 기존 코드에 맞춰 옮기도록 했습니다.
이것을 UI 빅뱅이라고 불렀습니다. 기존 구현에 묶여 있던 설계의 출발점을 기능과 외부 레퍼런스로 옮겨, 에이전트가 아예 새 판을 짜게 한 겁니다.
하루 만에 109개 화면을 만들고, 바로 앱으로
저녁에 설계를 시작했습니다. 하루 만에 검토할 수 있는 109개 화면의 시안이 나왔습니다.
여러 방향을 비교하고, 고른 화면을 앱의 흐름과 톤에 맞춰 다듬었습니다.
어디가 달라졌을까요?
따로 있던 알림과 화면 설정을 모으고, 테마와 글자 크기를 한곳에서 조절하게 했습니다.
앱 전반의 UI를 다시 다듬었습니다. 정보의 위계와 표현 방식을 정리하고, 화면을 넘나들어도 하나의 제품으로 느껴지도록 흐름과 톤을 맞췄습니다.
하나씩 고치던 화면을, 한 번에 펼쳤습니다.
이제 저는 “더 예쁘게”라고 주문하는 대신 화면을 보며 골랐습니다. 무엇이 먼저 읽히는지, 다음 행동이 분명한지, 비슷한 기능이 같은 방식으로 보이는지. 좋은 방향을 고르면 그 화면을 다시 에이전트에게 넘겼습니다. 시안을 고르는 일이 곧 다음 개발 작업을 정하는 일이 됐습니다.
고른 화면을, 바로 앱으로.
화면을 고릅니다
나란히 놓인 시안을 보며 더 나은 방향을 고릅니다.
그 화면을 에이전트에게 건넵니다
고른 화면 자체가 다음 개발의 지시서가 됩니다.
실제 앱 코드에 반영합니다
에이전트가 디자인을 앱 코드로 옮기면, 바로 실행해 보고 다시 다듬습니다.
이렇게 정리한 약 100개의 화면을 다음 날 바로 앱 위에 올렸습니다. 물론 에이전트와 함께요.
사실, 제 직무는 PM입니다
PM인 동시에, 개발을 배우는 신입이기도 합니다. vooy에 와서 처음 개발을 시작했고, 지금도 하나씩 열심히 배우며 하루에도 수십 개의 PR을 올리고 있어요.
달라진 건 직함보다 일하는 방식입니다. “이렇게 해주세요”라는 요청을 넘기고 기다리는 대신, 제 생각을 화면에 담고, 피드백을 받고, 실제 앱에 녹이는 데까지 참여하게 됐습니다.
그럴수록 좋은 것을 알아보는 눈이 더 중요해졌습니다. 무엇을 먼저 보여줄지, 다음 행동을 얼마나 자연스럽게 만들지, 앱 전체를 어떤 기준으로 묶을지.
많은 화면을 만들어본 덕분에, 더 깊이 고민해야 할 디자인의 문제가 선명해졌습니다.
오늘도 vooy의 화면은 하루가 다르게 바뀌고 있습니다. 어떤 조직에서는 자기 권한을 넘어선 일로 보일지도 모르지만, vooy에서는 제품을 더 잘 만들고 성장시키는 일이라면 모두가 팔을 걷어붙입니다. 맡은 직무에 머물기보다, 필요한 일을 찾아 직접 해보면서요.
vooy는 곧 App Store와 Google Play에서 만나보실 수 있습니다.
이 실험을 함께 이어갈 프로덕트 디자이너분도 열심히 모시고 있습니다.
디자인 기준을 직접 정하고, 무제한 토큰과 에이전트로 제품에 옮겨볼 수 있어요.
다른 직군의 동료들도 찾고 있고요. 함께 만들어보고 싶다면 편하게 이야기 나눠요.
DESIGN AT VOOY
프로덕트 디자이너를 모시고 있어요
에이전트와 함께 vooy의 화면을 만들어갈 동료를 찾습니다.