SAI

SAI 라이브 화면 – 입력한 한 문장이 제안이 되고, 근거를 확인해 노트에 담기까지

요약

회의를 듣고 필요한 일을 먼저 제안하는 AI 동료다. 사람이 수락한 제안만 실행하고, 결과만 노트에 남는다.

역할 – UX 흐름 · 디자인 시스템 · 프론트엔드 (3인 팀: 성재용 · 배재용 · 오승빈)

모델이 제안하고, 사람이 수락한다. 그때부터 일이 된다. 사이는 회의를 듣다가 필요한 일을 먼저 제안하고, 수락된 제안만 실행한다. 노트에는 실행된 결과만 남는다.

3인 팀으로 만들었다. 성재용, 배재용, 오승빈 셋이 붙었고 내 몫은 UX 흐름과 디자인 시스템, 프론트엔드였다. 2026 원티드 AI 챔피언십 출품작이다.

흐름은 네 단계다. 발언을 실시간으로 받아쓰고, 대화와 공유 자료를 읽어 지금 필요한 일을 판단하고, 웹 조사와 수치 계산을 하고, 결과를 근거와 함께 제안한다. "예산을 60만 원으로 바꾸면?" 같은 후속 발언은 앞선 논의에 연결해 다시 계산한다.

사람은 대화를 멈추지 않은 채 눈으로 확인하고 손으로 수락한다. 참가자는 같은 방에서 각자의 노트북과 휴대폰으로 한 회의방에 들어오고, 마이크는 한 기기만 켠다.

네 단계를 무엇으로 돌렸나

받아쓰기 – Amazon Transcribe. 발언을 실시간으로 문자로 바꾼다.
판단 – Claude. 대화와 공유 자료를 읽고 지금 필요한 일을 고른다.
조사 – Amazon Nova. 웹에서 자료를 찾아 출처와 함께 돌려준다.
계산 – 코드 실행. 수치는 모델이 암산하지 않고 코드가 계산한다.
프론트엔드 – Next.js, React, TypeScript, Tailwind CSS. 회의방은 데스크톱과 모바일에서 같은 화면을 쓴다.

자료를 찾느라 대화가 끊긴다 – 회의 중에 숫자 하나를 확인하거나 대안을 비교하려면 누군가 화면을 보고, 그동안 대화는 멈춘다.
AI를 쓰려면 맥락을 다시 설명해야 한다 – 챗봇에 물으려면 지금까지의 논의를 요약해 넣어야 한다. 그 요약을 쓰는 동안 회의는 또 멈춘다.

01노트는 스스로 생기지 않는다. 제안, 수락, 그다음이 노트다
대화 중인 사람에게 AI가 마음대로 쓴 글은 확인할 일만 늘린다.
→AI는 먼저 묻고, 수락된 뒤에만 일하고, 결과만 노트에 쓴다. 제안 자체는 노트 본문에 섞이지 않는다.
02근거가 없는 제안은 보여주지 않는다
왜 지금 이것을 묻는지가 보여야 믿고 누른다.
→출처가 된 발화나 자료가 없는 제안은 띄우지 않는다. 답을 기다리는 제안은 동시에 2개까지만 둔다(설계값).
03AI가 만든 것은 빛으로 표시한다
무엇을 AI가 썼는지 분명해야 했다. AI 기본법의 고지 의무도 지켜야 했다.
→AI 생성물은 파란 글로우와 ‘AI 생성’ 배지로 구분한다.
04자료는 사용자를 기다린다
읽고 있는 숫자가 갑자기 바뀌거나 사라지면 읽을 수 없다.
→새 결과는 읽던 카드를 덮지 않고 대기열과 배너로 알린다. 확인되지 않은 값은 지우지 않고 ‘확인 안 됨’ 태그를 붙인다.

그 밖의 결정 두 가지

강조색은 파랑 하나 – 회의 중에는 화면을 흘끗 본다. 종류와 상태는 회색의 명도로만 나누고, 지금 눌러야 할 것만 파랑으로 뒀다. 빨강은 쓰지 않는다.
지금 일어나는 일은 아래 섬 하나에 – 녹음 상태와 알림이 화면 곳곳에 흩어지면 대화를 놓친다. 하단의 캡슐 하나가 녹음 상태와 모든 알림을 담는다. 막힌 동작은 이유와 해결 버튼을 함께 보여준다.

원칙 8가지 – 선 대신 여백, 파랑 하나, AI는 빛, 자료는 사용자를 기다림, 모르는 건 모른다고, 선은 정보가 있을 때만, 그림자는 자르지 않음, 공식 로고는 그대로.
토큰 – primitive → semantic → 컴포넌트의 3단 구조다. 4px 그리드를 쓰고, 그림자는 두 종류만 둔다.
컴포넌트 – 제안 카드(제안 · 진행 · 완료 · 닫힘), 근거 · 계산 · 제안 세 종류의 자료 카드, 회의 섬, 동의 게이트, QR 공유. 자료 카드는 채움의 강도로 확신도를 표시한다.
라이브 스타일 가이드 – 앱 안의 /design-system에서 토큰과 원칙을 그대로 본다.

Figma 파일 불러오는 중

드래그로 이동, 스크롤로 확대 – 실제 Figma 파일입니다.

눈으로 보지 않고 검사로 확인했다.

테스트 – Playwright 테스트 32개를 데스크톱(1440×900)과 모바일에서 실행한다. 콘솔 오류가 하나라도 나면 실패로 본다. axe로 WCAG 2.1 AA를 검사한다.
대비 – 검사에서 기준 미달로 걸린 색을 고쳤다. 보조 글자는 4.49에서 5.05로, 강조색 위 흰 글자는 3.88에서 4.77로 올렸다(실측).
한글 입력 중 단축키 – 키 코드 기준으로 처리했다. 한글을 입력하는 중에도 단축키가 동작한다.

요구사항 분석부터 구현, 테스트, 코드 리뷰까지 Codex와 함께 했다.

실제 모델과 브라우저, DB를 연결한 상태로 돌렸다. 받아쓰기에서 판단, 조사와 계산, 제안까지 네 단계가 한 흐름으로 이어졌다. 견적 비교, 예산이 바뀔 때의 재계산, 고른 항목의 저장까지 확인했다.

먼저 다 만들고 나중에 줄였다. 전체를 한 번 만든 뒤 90개 파일에서 9,000줄 가까이 덜어냈다(산출물). 필수 기능부터 정했다면 그 9,000줄을 쓸 일이 없었다.
대비를 내 눈으로 판단했다. 보조 글자 4.49와 강조색 위 흰 글자 3.88은 화면에서 멀쩡해 보였다. 둘 다 WCAG AA 미달이었고, 검사가 잡아낸 뒤에 고쳤다.