← Projects
KIWON KIM / SELECTED WORK

GRAVII / FRONTEND PRODUCT SYSTEM

흩어진 화면을
제품 시스템으로.

Gravii는 지갑의 온체인 활동을 개인의 Gravii ID·X-Ray 경험과 파트너의 지갑 집단 분석으로 연결하는 제품입니다. 저는 랜딩에서 두 앱과 내부 운영 화면까지, 각 사용자가 들어와 인증하고 결과를 보는 프론트엔드 흐름을 설계하고 구현했습니다.

ROLE 프론트엔드 엔지니어링 · 제품/UI/UX 디자인 · 제품 기획 · 아키텍처PERIOD 2026.01 — 현재STATUS 개발 진행 중 · 제품 전체 정식 출시 전
Gravii public landing screenshot
GRAVII PUBLIC LANDING gravii.io
01 / CONTEXT

화면보다 먼저,
흐름과 경계를 정했다.

하나의 브랜드 아래 네 앱이 있지만, 사용자·인증 방식·데이터 계약은 서로 다릅니다.

공개 랜딩은 제품을 설명하고 진입을 만들고, 사용자 앱은 지갑을 연결한 개인에게 Gravii ID와 X-Ray를 보여줍니다. 파트너 앱은 지갑 집단 분석 업무를, 별도 내부 화면은 운영을 맡습니다. 저는 팀과 기능·우선순위를 논의하며 이 영역들의 정보 구조와 사용 흐름을 화면으로 구체화했습니다.

담당 범위: 제품 흐름과 UI/UX 설계, 프론트엔드 아키텍처·구현, 인증·API 연결, 상태별 화면 처리. 분석 엔진과 백엔드 API의 구현은 별도 책임입니다.
02 / ARCHITECTURE

네 개의 앱,
경계부터 설계하다.

제가 설계한 핵심은 앱별 사용자와 인증·API 경계를 구분하고, 여러 앱이 함께 써야 할 계약만 공통화한 것입니다.

각 앱의 라우팅과 기능 모듈, 화면 흐름은 해당 앱에 두고, 도메인 타입·API 클라이언트·브랜드 자산은 워크스페이스에서 공유했습니다.

01 / PUBLIC LANDING제품 설명 · 앱 진입 · 대기 명단
02 / USER APP지갑 로그인 · Gravii ID · X-Ray
03 / PARTNER APPGoogle 로그인 · Lens · 분석 업무
04 / BACKOFFICE내부 운영 · 상태 확인 · 관리

DOMAIN TYPES · API CLIENTS · BRAND ASSETS

사용자 지갑 인증과 파트너 Google 인증은 서로 다른 흐름으로 유지했습니다. 프론트엔드는 내부 분석 엔진 대신 제품별 공개 API를 사용해 요청·상태 관리·결과 표현에 집중하도록 경계를 잡았습니다.

03 / USER EXPERIENCE

로그인 다음에는
실제 데이터가 보여야 했다.

지갑 연결은 시작일 뿐입니다. 인증 후 자신의 ID와 분석 결과를 이해할 수 있어야 했습니다.

지갑 서명 인증 뒤 User API에서 Gravii ID를 읽어 프로필을 구성하고, X-Ray의 크레딧·조회 이력·새 분석 요청·결과 상세를 실제 응답에 연결했습니다. API 응답을 화면에 필요한 데이터 형태로 정리하고, 브라우저 요청은 같은 출처의 Next.js 경로로 전달하며 인증 토큰은 서버 세션 쿠키에서 다룹니다.

새 지갑의 ID 생성 대기, 분석 진행 중, 크레딧 부족, 빈 결과와 오류도 화면 흐름에 포함했습니다. Discovery와 Ranking은 아직 실제 데이터가 연결되지 않았음을 구분했고, My Space는 코드에 남겨두되 현재 탐색에서는 숨겼습니다.

  1. 01 / ENTRY랜딩에서 사용자 앱으로 진입
  2. 02 / AUTH지갑 연결·서명 인증과 세션 처리
  3. 03 / USER APIGravii ID 응답을 프로필 화면으로 변환
  4. 04 / X-RAY크레딧·분석 요청·결과와 상태 표시
Gravii user app development screenshot
Gravii 사용자 앱의 개발 화면 · 화면에 보이는 데이터가 모두 라이브라는 뜻은 아닙니다.
04 / PARTNER EXPERIENCE

데모 화면을
업무 흐름으로 옮기다.

주소 목록을 넣고 분석 결과까지 내려가는 실제 업무 흐름을 Lens에 만들었습니다.

Google 로그인과 Partner API 인증 뒤 계정 상태·플랜에 따라 진입 화면을 정합니다. Lens에서는 CSV나 지갑 주소 목록을 정리해 분석 풀을 만들고, 진행 상태를 확인한 뒤 집계 결과에서 지갑 목록과 상세 분석으로 이동하도록 연결했습니다.

목록의 필터·정렬·페이지 이동을 데이터 구조에 맞춰 구현했습니다. 인증과 Lens는 실제 API를 사용하고, 일부 대시보드·분석 화면은 미리보기 데이터임을 표시합니다.

  1. 01 / AUTHGoogle 로그인·Partner API 인증
  2. 02 / INPUTCSV·주소 목록 입력값 정리
  3. 03 / LENS분석 풀 생성·진행 상태 확인
  4. 04 / RESULTS집계에서 지갑 목록·상세로 탐색
Earlier Gravii Lens prototype
아래 화면은 Lens의 이전 프로토타입입니다. 현재 구현된 화면이나 실제 분석 결과로 제시하지 않습니다.
05 / PRODUCT ENTRY

랜딩도 제품의
첫 번째 단계.

제품 설명에서 로그인 후 경험까지, 사용자가 다음 행동을 알 수 있어야 했습니다.

공개 랜딩과 파트너 소개 화면을 각 앱으로 이어지는 진입 경로로 설계했습니다. 개인은 지갑을 연결해 무엇을 볼 수 있는지, 파트너는 주소 목록으로 어떤 분석을 시작할 수 있는지를 먼저 이해하도록 정보 순서를 잡았습니다. 대기 명단 등록과 유입 정보 전달도 이 흐름에 포함하고, 팀과 제품 우선순위를 논의하며 화면 구성과 작업 순서를 조정했습니다.

PUBLIC LANDING / EXPLAINUSER APP / CONNECTPARTNER APP / ANALYZE
06 / DESIGN & IMPLEMENTATION

시각 언어도
재사용 가능한 규칙으로.

브랜드의 표현과 앱의 정보 가독성을 함께 고려해 화면을 디자인하고 구현했습니다.

색상·타이포그래피·컴포넌트·모션의 사용 기준과 공통 브랜드 자산을 정리하고, 데스크톱·모바일 레이아웃을 만들었습니다. 인증·로딩·빈 결과·오류처럼 실제 API와 제품 상태에 따라 필요한 화면도 설계했습니다. 디자인을 넘겨받아 옮기는 방식이 아니라 구현 과정에서 제약을 확인하며 계속 다듬었습니다.

Gravii design-system exploration, not shipped UI
디자인 탐색안 · 실제 배포 화면 아님
07 / OUTCOME & BOUNDARY

출시 전에도
남는 결과.

랜딩, 사용자 앱, 파트너 Lens와 내부 운영 화면의 역할을 분리하고 프론트엔드 구조와 데이터 흐름을 연결했습니다. 사용자 앱의 지갑 인증·Gravii ID·X-Ray와 파트너 앱의 인증·Lens는 실제 API에 연결되어 있습니다. 제품 전체는 아직 정식 출시 전이므로 성장·전환 성과를 주장하지 않습니다.

Gravii 공개 사이트 보기 ↗
Gravii · Kiwon Kim