vooy의 한 주니어 개발자이자 PM은, 디자이너가 아직 없는 팀에서 AI 에이전트와 함께 메신저 앱의 UI를 빠르게 개선하는 실험을 진행했다. 핵심은 기존 코드와 화면을 그대로 보여주지 않고, 기능 명세만 전달해 새로운 디자인을 만들게 한 것이다. 그 결과 팀 투표를 통한 첫 실험과 기능 중심의 두 번째 실험을 거쳐, 하루 만에 109개 화면 제안을 만들고 약 100개를 실제 앱에 반영했다.

1. 디자이너 없이 성장하던 앱의 문제

글쓴이는 vooy에 합류한 뒤 처음 프로그래밍을 시작한 주니어 개발자다. 당시 vooy에는 첫 프로덕트 디자이너도 아직 합류하지 않았고, 팀원들이 함께 앱의 화면을 만들고 개선해야 하는 상황이었다.

vooy는 사람과 AI 에이전트가 함께 일하는 메신저를 만들고 있다. 사용자는 대화로 일정을 관리하고, 에이전트에게 일상 업무를 맡길 수 있다. 하지만 이런 형태의 메신저는 시장에 정답에 가까운 선례가 많지 않았기 때문에, 다른 서비스의 화면을 그대로 참고하기도 어려웠다.

개발자들은 이미 에이전트를 활용해 빠르게 기능을 만들고 있었다. 기능은 계속 추가됐지만, 화면 경험은 그 속도를 따라가지 못했다. 버튼은 작동해도 어떤 버튼을 먼저 눌러야 할지 직관적이지 않았고, 같은 기능이 화면마다 다른 모습으로 나타났다. 앱이 커질수록 UI 개선은 계속 뒤로 밀렸다.

"앱은 계속 커졌지만, 인터페이스 개선은 계속 미뤄졌다."

글쓴이는 자신의 디자인 실력에도 자신이 없었다. 그래서 말로만 "이 화면을 어떻게 만들까?"를 논의하기보다, 팀이 직접 보고 비교하고 이야기할 수 있을 만큼 많은 화면 시안을 만들기로 했다. 이를 위해 디자인을 생성하는 일과, 여러 시안을 비교·투표할 도구를 모두 에이전트와 함께 만들기로 한다. 🎨

2. 첫 번째 실험: 말하기 전에 화면부터 보여주기

첫 실험의 원칙은 단순했다. "Less talk. More screens.", 즉 말보다 화면을 먼저 꺼내는 것이었다.

팀은 같은 홈, 채팅, 캘린더 화면에 대해 총 15가지 접근 방식을 만들었다. 어떤 시안은 캐릭터를 크게 앞세웠고, 어떤 시안은 정보를 한 화면에 밀도 있게 담았으며, 또 다른 시안은 대화 흐름에 집중했다. 추상적으로 취향을 논하는 대신, 실제 화면을 보며 차이를 구체적으로 말할 수 있게 됐다.

글쓴이는 에이전트에게 디자인 시안과 투표 웹사이트를 만들게 한 뒤, 그날 밤 바로 Vercel에 배포해 팀에 URL을 공유했다. 팀원들은 화면을 살펴보고 5점 척도로 평가했다.

"무엇이 눈에 들어오나요?"

예를 들어 'Soft companion'이라는 시안은 홈 화면에서 캐릭터를 강조하고, 채팅과 캘린더까지 같은 정서를 유지하는 접근이었다.

하지만 점수만으로는 팀원들이 왜 좋아하거나 싫어했는지 알 수 없었다. 그래서 화면 위 특정 지점을 클릭하거나 영역을 드래그해, 해당 위치에 직접 피드백 핀을 꽂을 수 있는 기능을 넣었다.

"6번이 좋아요"에서 멈추지 않고, "캐릭터가 나에게 말을 거는 것처럼 보여서 좋지만, 두 번씩 등장할 필요는 없어요"라고 말할 수 있게 했다.

이 방식은 긍정 의견으로는 무엇을 유지해야 하는지, 부정 의견으로는 무엇을 고쳐야 하는지를 분명히 보여줬다.

3. 화면 위 피드백을 하나의 방향으로 합치기

첫 번째 실험에는 10명이 참여했고, 화면에 직접 남긴 의견은 총 124개였다. 이 중 긍정 피드백은 39개, 부정 피드백은 85개였다. 글쓴이는 이 피드백들을 24개 그룹으로 분류한 다음, 에이전트에게 디자인 의사결정을 반영하도록 맡겼다.

예를 들어 홈 화면의 캐릭터는 눈에 띄는 요소로 유지하되, 여러 곳에 반복해서 등장시키지 않기로 했다.

"눈에 잘 띄되, 반복되지는 않게."

그 결과 홈 상단에는 하나의 큰 캐릭터를 두고, 바로 아래에서 대화로 진입할 수 있도록 구성한 통합 시안이 만들어졌다.

이 과정을 통해 홈·채팅·캘린더 등을 포함한 6개 화면의 하나의 앱 초안이 완성됐다. 투표 도구를 만들고, 피드백을 모으고, 이를 디자인으로 통합하는 데는 단 하루면 충분했다.

"화면이 눈앞에 있으니, 우리가 바꾸고 싶은 것이 빠르게 분명해졌다."

에이전트를 사용했기 때문에, 논의만 하고 끝나는 것이 아니라 결정 사항을 곧바로 다음 앱 버전에 반영할 수 있었다. 이 실험은 화면을 많이 만들고, 팀이 직접 평가하며, 구체적인 피드백을 다음 디자인으로 연결하는 방식의 가능성을 보여줬다.

4. 두 번째 실험: 코드를 읽는 에이전트와 디자인하는 에이전트를 분리하기

첫 번째 실험으로 큰 방향은 정했지만, 앱 개발이 계속되는 동안 화면은 더 많아졌고 UI의 작은 어색함도 누적됐다. 비슷한 설정 화면인데 여백이 달랐고, 버튼마다 시각적 중요도가 제각각이었으며, 한 문장으로 충분한 설명이 여러 번 반복됐다. 각각은 사소해 보여도, 전체적으로는 앱을 일관성 없게 만들었다.

글쓴이는 다시 에이전트로 UI를 개선하려 했지만 중요한 문제를 발견했다.

"에이전트가 자기 코드베이스를 보는 순간, UI의 독창성은 급격히 떨어진다."

에이전트가 기존 코드를 읽으면, 이미 존재하는 컴포넌트·화면 경계·정보 순서를 출발점으로 삼는다. "처음부터 디자인해 달라"고 요청해도 결국은 같은 화면 틀 안에서 간격이나 색상만 다듬게 되는 경우가 많았다.

이는 코드 안에 두 종류의 정보가 섞여 있기 때문이었다.

• 제품이 반드시 해야 하는 일: 메시지 전송, 전송 실패 후 재시도, 상태 갱신 등
• 현재 UI가 그 기능을 표현하는 방식: 입력창의 위치, 오류 표시 방식, 버튼의 모양과 위치 등

전자는 유지해야 하지만, 후자는 얼마든지 새롭게 설계할 수 있다. 그런데 코드 전체를 넘기면 둘 다 함께 전달돼, 기존 UI의 틀에서 벗어나기 어려워진다.

그래서 팀은 에이전트의 역할을 분리했다. 한 에이전트는 기존 앱과 코드를 조사하고, 다른 에이전트는 기존 화면을 보지 않은 채 새 화면을 디자인한다. 두 에이전트 사이에는 기능 명세서만 전달된다.

"화면이 아니라 기능을 넘겨라."

5. 기능 명세를 계약으로 삼아 새 화면을 만들기

조사 에이전트는 기존 코드와 실제 화면에서 각 기능의 사용자 행동, 데이터, 상태, 제약 조건, 의존성 등을 추출했다. 그리고 각 기능에 ID를 붙였다.

예를 들어 F-EX01은 메시지 전송이 실패했을 때 사용자가 재시도할 수 있게 하는 기능이다. 이 명세에는 재시도 시 필요한 메시지 ID와 대화 ID, 전송 상태, 중복 전송을 막아야 한다는 제약 등이 포함된다.

"실패한 메시지를 다시 전송한다. 재시도 결과에 따라 전송 상태를 갱신한다."

반면 디자인 에이전트에게는 다음과 같은 정보가 전달되지 않았다.

• 기존의 색상
• 레이아웃
• 컴포넌트 이름
• 버튼 위치
• 기존 화면의 구조
• 기능이 구현된 코드 경로

기능 ID와 원본 코드의 연결 관계는 별도 파일인 features-sources.md에 보관했고, 디자인 에이전트는 이 파일을 받지 않았다. 코드 경로나 파일명조차 기존 UI로 되돌아가는 단서가 될 수 있기 때문이다.

"소스 맵은 분리해 둔다."

디자인 에이전트가 받는 features.md는 일종의 입력 계약(input contract) 이 됐다. 이 에이전트는 "메시지 재시도 기능이 필요하다"는 사실은 알지만, 그 버튼이 원래 어디에 있었는지는 알지 못한다. 따라서 재시도 기능을 어떤 화면에서, 어떤 방식으로 보여줄지는 새롭게 판단할 수 있다.

새 출발점은 기존 구현이 아니라 기능과 외부 레퍼런스였다. 디자인 에이전트는 서비스 이름과 마스코트 같은 최소한의 브랜드 자료를 받고, Mobbin MCP를 통해 대화 목록, 캘린더 정보 밀도, 빈 화면 안내 방식 등을 조사했다. 그리고 기존 컴포넌트에 기능을 억지로 맞추는 대신, 기능에 맞는 패턴을 조합해 화면을 구성했다.

이후 새 디자인이 완성되면, 기존의 기능 ID를 새 화면에 다시 연결했다. 예를 들어 F-EX01이 새 대화 화면의 어디에서 재시도 기능으로 제공되는지 확인하는 식이다.

"표현 방식은 바뀔 수 있지만, ID는 필요한 동작을 추적 가능하게 유지한다."

누락된 기능이 없는지 검토하고 디자인 방향을 선택하면, 마지막으로 구현 에이전트가 새 디자인을 기존 코드베이스에 반영했다. 글쓴이는 이 과정을 'UI Big Bang'이라고 불렀다. 기존 구현이 아니라 기능과 외부 참고 사례에서 출발함으로써, 에이전트가 앱을 다시 디자인할 여지를 만든 것이다. 💥

6. 하루 만에 109개 화면을 만들고 앱에 반영하기

두 번째 실험에서는 저녁부터 디자인을 시작해, 24시간 안에 검토 가능한 109개 화면 제안을 만들었다. 팀은 화면들을 함께 비교하며 앱의 사용자 흐름과 시각적 분위기에 맞춰 방향을 다듬었다.

예를 들어 알림 설정과 디스플레이 설정을 한곳에 모으고, 테마와 글자 크기 조절도 같은 맥락 안에서 찾을 수 있도록 개선했다. 이렇게 앱 전반의 정보 위계, 시각 언어, 화면 이동 흐름을 맞춰서, 사용자가 여러 화면을 오갈 때 하나의 제품을 쓰고 있다는 느낌을 받게 하려 했다.

글쓴이에게 중요한 변화는 "더 예쁘게 만들어 달라"는 막연한 요청 대신, 여러 화면을 보며 명확한 기준으로 선택할 수 있게 된 점이었다.

• 무엇이 먼저 읽히는가?
• 사용자가 다음 행동을 쉽게 이해할 수 있는가?
• 비슷한 기능들이 일관된 모습으로 보이는가?

"디자인을 선택하는 일은 다음 개발 작업을 정의하는 방법이 되었다."

실제 작업 흐름은 다음과 같았다.

1. 여러 화면을 나란히 비교해 더 나은 방향을 선택한다.
2. 선택한 화면 자체를 다음 개발 작업의 브리프로 에이전트에게 전달한다.
3. 에이전트가 화면을 기존 앱 코드에 반영하고, 팀은 실행·검토·수정을 반복한다.

팀은 이 방식으로 만든 화면 약 100개를 바로 다음 날 앱에 적용했다.

"물론 에이전트와 함께였다."

7. 직함보다 중요한 제품 개선의 역할

글쓴이의 실제 역할은 개발자나 디자이너가 아니라 프로덕트 매니저(PM) 다. vooy에 합류한 뒤 처음 코딩을 배웠고, 지금도 매일 배우면서 하루에 수십 개의 PR을 열고 있다고 말한다.

하지만 중요한 변화는 직함이 아니라 일하는 방식이었다. 이전에는 요청을 전달하고 결과를 기다리는 위치였다면, 이제는 스스로 아이디어를 화면으로 만들고, 피드백을 모으고, 앱에 반영하는 과정까지 참여할 수 있게 됐다.

이 때문에 글쓴이는 기술 자체만큼이나 무엇이 좋은지 판단하는 안목이 중요해졌다고 느낀다. 사용자가 무엇을 먼저 봐야 하는지, 다음 행동이 어떻게 자연스러워질 수 있는지, 앱 전체에 어떤 원칙이 일관되게 적용되어야 하는지를 계속 고민해야 한다는 것이다.

"사람들이 무엇을 먼저 봐야 할까? 다음 행동은 어떻게 자연스럽게 느껴지게 할 수 있을까? 어떤 원칙이 앱 전체를 지탱해야 할까?"

vooy의 화면은 지금도 매일 바뀌고 있다. 다른 조직이라면 자신의 역할을 넘는 일처럼 보일 수 있지만, vooy에서는 제품을 더 좋게 만들 방법이 있다면 누구나 역할 구분에 얽매이지 않고 시도한다.

"우리는 해야 할 일을 찾아내고, 직함이 어디에 있든 시도한다."

글의 마지막에서 vooy는 곧 App Store와 Google Play에서 만날 수 있다고 알린다. 또한 이런 실험을 이어갈 프로덕트 디자이너를 찾고 있으며, 에이전트와 충분한 토큰을 활용해 디자인 원칙을 제품에 직접 구현할 사람을 모집하고 있다.

마무리

이 글의 핵심은 AI 에이전트를 단순히 화면을 빠르게 만드는 도구로 쓰는 데 있지 않다. 기존 코드의 제약에서 벗어나기 위해 기능과 디자인 정보를 의도적으로 분리하고, 많은 시안을 팀의 피드백과 선택을 통해 실제 개발 작업으로 연결한 데 있다.

결국 UI Big Bang은 "에이전트가 알아서 디자인하게 하기"보다, 사람이 더 잘 비교하고 결정할 수 있는 환경을 만들고 그 결정을 빠르게 구현하는 방식에 가깝다.