ChatGPT Intelligent UI 업데이트와 스팩브릿지, 화면이 달라지는 시대의 스펙

 

이번 주에 ChatGPT에 큰 업데이트가 있었습니다.
Intelligent UI라는 이름의 기능이 GPT-6과 함께 공개되었다는 소식이었어요.
저는 이 소식을 보면서 개인 프로젝트인 스팩브릿지와 자꾸 겹쳐서 생각하게 되었습니다.
오늘은 이 업데이트가 무엇인지 정리하고, 스팩브릿지와의 관계, 그리고 앞으로의 생각을 적어 보려고 해요.

 

보도를 종합하면 핵심은 이렇습니다.
ChatGPT가 글자로만 답하지 않고, 질문에 따라 차트, 버튼, 입력 폼, 계산기 같은 인터랙티브한 요소를 섞어서 답한다는 것이에요.
어떤 형태로 보여 줄지는 질문을 보고 ChatGPT가 정한다고 합니다.
예를 들어 여러 대상을 비교해 달라고 하면 나란히 비교해 주는 화면이 나올 수 있고, 간단한 질문에는 지금처럼 글자로 답하는 식이에요.

필요하면 작은 도구를 즉석에서 만들어 주는 것도 소개되었습니다.
더치페이 계산기 같은 것이 예로 나왔어요.
시각 요소를 줄이는 설정도 가능하다고 알려졌습니다.
다만 제가 본 것은 언론 보도이고 공식 문서를 모두 확인한 것은 아니니, 세부 사양은 공식 안내를 한 번 더 확인하시기를 권해요.

 

제가 흥미롭게 본 점은 "화면이 미리 만들어진 산출물이 아니라, 대화 중에 생성되는 것"이 되어 간다는 점입니다.
지금까지 기획자는 화면을 먼저 설계하고, 개발자가 그 화면을 만들고, 사용자가 그 화면을 쓰는 순서로 일해 왔어요.
그런데 질문마다 화면이 새로 만들어진다면, 설계의 대상이 화면 한 장이 아니라 "화면을 만드는 규칙"으로 옮겨 갑니다.

이 변화는 기획자에게 이런 질문을 던져요.
어떤 상황에서 어떤 형태로 답을 보여 줄지를 누가 정하는가.
생성된 화면이 정책에 어긋나면 누가 어떻게 막는가.
같은 질문인데 매번 다른 화면이 나오면 사용자는 헷갈리지 않는가.

 

생성되는 화면이 늘어나면 기획 문서에 새로 들어가야 할 항목이 생깁니다.
가정해서 예약 서비스에 이런 기능이 붙는다고 해 볼게요.
사용자가 "다음 주 가능한 시간 알려 줘"라고 물으면 달력 형태의 선택 화면이 대화 안에 나타나는 식입니다.

이때 기획서가 정해 두어야 하는 것은 이런 내용이에요.
달력에 보여 줄 수 있는 날짜의 범위, 선택 가능한 시간을 계산하는 규칙, 예약을 확정하기 전 반드시 거쳐야 하는 확인 단계입니다.
화면의 모양은 AI가 정하더라도, 이 규칙은 사람이 정해 두어야 하고 그 규칙이 지켜졌는지 확인할 방법도 있어야 해요.
결국 화면을 그리는 문서에서 화면이 지켜야 할 약속을 적는 문서로 기획서의 무게가 옮겨 가는 셈입니다.

 

지금은 보도를 읽고 생각한 단계라서, 직접 써 보며 확인하고 싶은 것을 목록으로 만들어 두었어요.

• 같은 질문을 다시 해도 비슷한 형태의 화면이 나오는가
• 버튼과 입력 폼이 실제로 동작하는 범위가 어디까지인가
• 시각 요소를 줄이는 설정이 어떻게 반영되는가
• 화면 안에서 한 선택이 이어지는 대화에 어떻게 반영되는가

이 질문에 답을 얻으면 스팩브릿지에서 무엇을 스펙으로 남겨야 할지도 더 분명해질 것 같습니다.

 

스팩브릿지는 실제 개발된 화면 위에서 피드백을 남기고, 그 화면의 정책과 데이터와 API 스펙을 같이 관리하자는 생각에서 출발한 도구입니다.
한 문장으로 하면 화면, 요구사항, 데이터, API를 연결하는 살아 있는 스펙 레이어였어요.

처음에는 이 업데이트가 스팩브릿지의 전제를 흔든다고 느꼈습니다.
화면이 고정되어 있어야 핀을 꽂고 스펙을 붙일 수 있는데, 화면이 매번 생성된다면 붙일 대상이 사라질 수 있으니까요.
탭 처리 때문에 이미 한 번 고생한 터라, 화면 상태가 더 유동적이 되는 것은 쉬운 일이 아니라고 느꼈어요.

그런데 며칠 곱씹어 보니 오히려 반대의 면도 보였습니다.
화면이 유동적일수록 "이 화면이 지켜야 할 규칙"을 따로 남겨 두는 일이 더 중요해지기 때문이에요.
생성되는 화면의 허용 범위와 사용해도 되는 구성 요소, 연결되는 데이터와 API, 지켜야 할 정책은 화면이 어떻게 바뀌어도 남아야 합니다.
스팩브릿지가 연결하려던 것들 중에서, 화면은 바뀌더라도 요구사항과 데이터와 API를 잇는 부분은 오히려 더 필요해질 수 있다고 봐요.

 

아직 정해진 것은 아니고, 생각 중인 방향입니다.

• 스펙의 중심을 "특정 화면"에서 "컴포넌트와 규칙"으로 조금 옮겨 볼 수 있을지 검토합니다.
• 화면을 사람이 만들었는지 AI가 만들었는지와 상관없이, 같은 방식으로 검토하고 스펙과 연결할 수 있는지 살펴봅니다.
• 어노테이션이 고정된 화면뿐 아니라 생성된 화면의 상태까지 담을 수 있을지, 탭 문제와 함께 다시 생각합니다.

조만간 깃허브에 공개할 예정이라는 계획은 그대로 가져가려고 해요.
다만 공개하기 전에 이 방향을 어디까지 반영할지는 더 고민해 보겠습니다.

 

AI 서비스의 화면이 달라진다는 소식은 앞으로도 계속 나올 것 같습니다.
그때마다 기획자가 할 일은 "새 기능을 따라 하는 것"이 아니라 "이 변화가 내가 다루는 문제를 어떻게 바꾸는지" 묻는 일이라고 생각해요.
스팩브릿지를 만들면서 얻은 가장 큰 수확도 아마 이 질문 습관일 것 같습니다.
다음에 이 주제를 쓸 때는 직접 써 본 경험을 더 담아 보겠습니다.