[해시드와 AI 창업자④] GGUI 개발사 로쿠, AI 에이전트로 ‘실시간 UI’ 생성

GGUI는 이용자가 어린이인지 고령층인지 등 특성과 상황을 분석해, 이에 맞는 화면 구성을 지연 없이 제공하는 것이 특징이다. 또한 AI와 외부 서비스를 쉽게 연동할 수 있는 표준 방식인 MCP(Model Context Protocol) 형태로 제공돼 별도의 추가 개발 없이 바로 도입할 수 있다.

로쿠는 지난해 7월 창업한 뒤 세 차례 피보팅(사업 전환)을 거쳤다. 초기에는 딥테크 분야에 집중했지만, 이용자와 직접 맞닿는 서비스를 만들고 싶다는 판단에 방향을 틀었다. 임완섭 로쿠 대표는 이더리움재단 응용암호학팀 리드 출신으로 이번 프로그램에 펠로우(현업 전문가)로 참여했다. 임 대표를 만나 GGUI 개발 배경과 향후 계획 등에 대한 이야기를 들어봤다.

GGUI는 어떤 기술인가

챗GPT에 “오늘 날씨 어때”라고 물어보면 단순히 문자(텍스트)로만 설명하는 게 아니라, 날씨 정보를 찾고 여러 도구를 호출한 뒤 그래픽 형태로 정리해서 보여준다. 이 같은 UI는 미리 준비돼 있어야 가능한 구조다. GGUI는 사전 준비 없이도 어떤 상황이든 그때그때 필요한 UI를 생성할 수 있도록 만드는 기술이다.

현재 AI 에이전트와의 상호작용은 대부분 문자 기반이다. 하지만 문자만으로는 충분히 풍부한 이용자 경험을 제공하기 어렵다고 보고 있다. 기존 앱, 서비스들도 앞으로는 모두 에이전트 기반 서비스로 진화할 가능성이 크다고 생각한다.

가령 정부24나 국세청 홈택스 같은 사이트에 들어가면 메뉴가 너무 많고 구조도 복잡해서 어디서 무엇을 해야 하는지 헷갈리는 경우가 많다. 지금의 서비스들은 사람 개발자가 UI를 하나하나 설계해 고정된 형태로 만들어놓은 구조다. 그렇기에 메뉴도 많고 수정도 쉽지 않다.

반면 생성형 UI 방식은 별도의 고정 UI를 미리 만들어두지 않아도 된다. 이용자가 필요한 순간에 맞춰 필요한 화면을 즉석에서 생성해 보여주는 방식이다. 같은 일을 하더라도 훨씬 직관적이고 편리한 이용자 경험을 만들 수 있다는 점이 핵심이다.

생성형 UI를 만들어주는 기술은 왜 필요한지

기존 서비스는 이용자가 직접 메뉴를 찾아다니는 방식이다. 가령 정부24에서 인감 등록을 하려면 어떤 메뉴로 들어가야 하는지 검색하고 여러 단계를 거쳐야 한다. 이용자가 서비스 구조를 먼저 이해해야만 원하는 업무를 처리할 수 있는 형태다.

반면 에이전트 기반 환경에서는 이용 방식 자체가 달라진다. 이용자가 “인감 등록을 하고 싶다”고 요청하면 AI 에이전트가 필요한 절차를 이해하고 그 상황에 맞는 입력창이나 신청 화면, 확인 버튼 같은 UI를 실시간으로 생성해서 보여주는 방식이다.

그렇기에 GGUI는 단순히 UI를 자동으로 만들어주는 기술만을 의미하지 않는다. AI가 실제로 작업을 수행하는 과정과 이용자가 보는 화면을 연결해 주는 역할에 가깝다. 챗GPT 안에 정부 민원 에이전트가 있다고 가정하면 텍스트만으로도 업무 처리는 가능하다. 하지만 모든 과정을 텍스트로만 주고받으면 이용자 경험이 복잡하고 불편해질 수 있다. 그래서 상황에 맞는 화면을 즉석에서 생성해 보다 직관적으로 보여주는 것이다.

핵심은 AI가 뒤에서 실제 작업을 수행하고, GGUI는 그 과정을 이용자가 이해하기 쉬운 UI 형태로 바꿔준다는 점이다. 앞으로는 웹사이트나 애플리케이션, 챗GPT 같은 다양한 환경 안에서 AI가 동작하게 될 텐데, 이용자는 복잡한 메뉴를 찾는 대신 원하는 목적만 말하면 되는 형태로 서비스 경험이 바뀔 것이라고 보고 있다.

다만 생성형 UI에서 가장 중요한 문제는 실제 기능성과 연결돼 있는지 여부다. 화면만 그럴듯하게 생성하는 것은 어렵지 않다. 가령 “등록이 완료됐습니다”라는 UI를 예쁘게 보여줄 수는 있다. 하지만 실제 정부 서버에는 등록이 되지 않았다면 심각한 문제가 된다.

이른바 할루시네이션(환각) 문제다. 실제로는 처리되지 않았는데 화면만 정상적으로 처리된 것처럼 보일 수 있다는 의미다. GGUI의 핵심은 단순히 보기 좋은 화면을 만드는 기술이 아니라 실제 기능 수행 결과와 UI를 정확하게 연결하는 것이다.

GGUI는 시각화된 할루시네이션을 어떻게 해결하나

GGUI는 단순히 UI를 생성하는 기술이라기보다, AI 에이전트 환경에서 발생하는 ‘시각화된 할루시네이션’ 문제를 해결하기 위한 프로토콜이다. 기존 생성형 UI는 화면을 그럴듯하게 만드는 데는 문제가 없다. 가령 ‘인감 등록 완료’와 같은 결과 화면은 얼마든지 생성할 수 있다. 하지만 실제로는 정부 서버에 요청이 전달되지 않았거나, 처리 결과가 반영되지 않았는데도 화면만 성공한 것처럼 보이는 문제가 발생할 수 있다. 이것이 시각화된 할루시네이션이다.

이 문제를 해결하기 위해 GGUI는 단순 UI 생성이 아니라, 세 주체 간의 합의 구조를 전제로 설계된다. 세 주체는 이용자 에이전트, 민원 에이전트, 그리고 GGUI다. 이용자 에이전트는 이용자의 의도를 전달하고, 민원 에이전트는 실제 정부 서버와 연결돼 기능을 수행한다. GGUI는 이 과정에서 단순히 화면을 그리는(만드는) 역할이 아니라, 실제로 수행된 결과와 UI로 표현되는 내용이 일치하는지를 검증하고 조정하는 역할을 맡는다.

가령 이용자가 ‘인감 등록’을 요청하면, 민원 에이전트는 실제로 정부 시스템에 접속해 등록 작업을 수행한다. 이후 GGUI는 그 결과가 실제로 처리된 데이터인지, 다운로드된 파일이 정확한지 등을 확인한 뒤 그에 맞는 UI를 생성한다. 즉 GGUI는 화면을 만드는 도구가 아니라, AI 에이전트가 수행한 실제 결과와 이용자에게 보이는 UI 사이의 일관성을 보장하는 중간 합의 계층이다.

이 같은 구조가 ‘합의 프로토콜(합의 규약)’인 이유는 세 주체가 동일한 결과 상태에 대해 서로 일치해야만 최종 UI가 성립하기 때문이다. 이 과정은 블록체인처럼 신뢰하지 않아도 동일한 결과를 검증할 수 있는 구조를 참고한 설계 방식이다.

GGUI는 AI 에이전트가 실행한 실제 작업 결과를 검증하고 UI로 안전하게 연결해 주는 프로토콜 기술이라고 볼 수 있다. 프로토콜로 동작한다는 점에서 유의미한 건 같은 의도를 지닌 요청에 대해 UI를 효과적으로 캐싱(임시 저장 후 재사용)할 수 있다는 점이다. 가령 “날씨 보여줘”라는 요청이 들어오면 매번 새로 UI를 생성하는 것이 아니라, 이미 만들어진 날씨 UI를 그대로 재사용하면 된다.

UI 생성 자체도 빠르게 이뤄지지만, 캐싱된 UI를 활용하면 훨씬 더 즉각적으로 결과를 보여줄 수 있다. 인감증명서 같은 경우도 마찬가지다. 데이터는 매번 달라지지만 UI 구조 자체는 동일하기 때문에, 한 번 만들어진 인감증명서 UI 양식을 저장해 두고 사용할 수 있다.

GGUI의 경쟁사는

구글은 A2UI(Agent-to-UI)라는 프로토콜을 통해 AI 에이전트가 대화 상황에 맞는 UI를 생성해 이용자에게 전달하는 방식을 제공하고 있다. 앤트로픽은 MCP(AI 연결 규칙)를 통해 AI가 외부 서비스와 데이터에 연결되는 방식을 표준화하고, 이를 기반으로 다양한 형태의 응용 서비스로 확장할 수 있는 구조를 제공하고 있다. 이처럼 글로벌 기술 기업들도 방식은 다르지만, 공통적으로 에이전트 중심 환경에서 UI와 서비스 연결을 표준화하려는 방향성에는 동의하고 있다.

글로벌 기술 기업 대비 GGUI의 차별점은 무엇인가

초개인화에 초점을 맞추고 있다는 점이다. 이용자가 “인감증명서를 발급받고 싶다”는 요청을 보내면 GGUI는 해당 의도에 맞는 UI를 검색해 적절한 화면을 제공한다. 다만 GGUI는 동일한 의도에 대해 하나의 고정된 UI만 제공하는 것이 아니라, 다양한 버전의 UI를 제공하는 방식을 지향한다.

가령 인감증명서 발급 UI라고 하더라도 나이가 어린 이용자와 고령의 이용자에게 적합한 형태는 각각 다를 수 있다. 문서의 내용 자체는 동일하더라도 디자인이나 버튼 구성, 정보 배치 방식은 달라질 수 있는 것이다.

현재의 앱들이 모두 에이전트 기반 앱으로 전환될 것이라고 생각한다. 해시드에서 자체적으로 개발 중인 에이전트에 GGUI 프로토콜이 도입될 예정이다. 이 과정을 통해 기술 방향성도 보다 명확하게 정립되고 있다. 향후 수익 모델은 GGUI 프로토콜을 도입해 사용하는 경우 서비스형 소프트웨어(SaaS) 이용료를 부과하는 방식이 될 것이다.

바이브코딩 프로그램에는 왜 참여했나

지난해 여름까지만 해도 AI를 소극적으로 사용하는 편이었다. 당시에는 AI가 원하는 수준의 결과물을 잘 만들어주지 못했고, 직접 구조를 짜고 코드를 작성하는 방식이 더 빠르다고 느꼈다.

하지만 같은 해 겨울부터는 AI가 기대 이상의 결과물을 내기 시작하면서 상황이 달라졌다. 개발 방식 자체가 바뀔 정도의 변화를 체감하게 됐다. 그 시점부터 AI를 바라보는 태도도 완전히 달라졌다. 바이브랩스가 시작된다는 이야기를 들었을 때 자연스럽게 참여 의사가 생겼고, 함께할 동료들이 필요하다는 판단도 있었다.

이번 프로그램에 펠로우로 참여했던 이들 중에는 19~20세의 참가자들도 있다. 이들에게서 많이 배우게 되는 부분 중 하나는 사고방식의 차이다.

세상에 존재하는 대부분의 지식을 처음부터 익히지 않은 상태에서 출발했기에, 처음부터 한계를 두지 않는 사고방식을 보여줬다. 그래서 결과적으로 완성도가 다소 떨어지더라도 “일단 만들어보면 된다”는 방식으로 접근하고, 실제로 무엇이든 만들어지는 경험을 했다. 이러한 과정을 지켜보면서 사고방식의 변화에도 영향을 받게 됐다.

바이브코딩이 창업 환경에 어떤 영향을 줄까

앱 시장은 점점 숏츠 시장처럼 변화할 것이라고 본다. 양산형 저품질 앱이 많이 등장하고, 그중 일부만 살아남는 구조가 될 가능성이 크다. 이미 시장에는 앱의 홍수가 시작된 상태다. 그 과정에서 하나의 앱이 잘 터지면 폭발적으로 성장하는 구조가 더 자주 나타날 수 있다고 본다. 이런 환경에서는 개발자나 창업팀이 성장하는 앱에 얼마나 빠르게 붙느냐가 중요한 요소가 될 것이다.

또 하나의 변화는 창업 방식 자체다. 바이브코딩으로 앱 제작이 쉬워지면서 하나의 팀이 하나의 서비스만 만드는 것이 아니라 여러 서비스를 동시에 만들거나 연쇄적으로 창업하는 형태가 늘어날 가능성이 있다.

과거에는 앱 하나를 한 달 안에 출시하는 것만으로도 매우 빠른 속도로 평가받았지만, 이제는 웹사이트 기준으로도 일주일 단위 출시가 가능해지고 있다. 완성도 중심보다는 빠르게 만들고, 많이 시도하고, 그중에서 좋은 것을 발굴하는 방식이 일반적인 흐름이 될 것이라고 생각한다.

글. 바이라인네트워크
<이수민 기자>Lsm@byline.network