TL;DR

  • 20개가 넘는 화면을 포함하는 다단계 워크플로를 설계할 때는 AI 에이전트에 설계를 맡기거나 화면을 하나씩 구현하는 방식보다 HTML 프로토타입을 먼저 만드는 편이 효과적임.
  • Emm은 에이전트와 사람이 함께 쓰는 로컬 우선 노트 관리자이자 이슈 트래커이며, 클라우드에 연결하지 않고 로컬 에이전트로 작업을 시작할 수 있어야 함.
  • 에이전트에 워크플로 설계를 맡겼을 때는 불필요한 클릭과 페이지 이동이 생겼고, 화면을 하나씩 구현했을 때는 변경에 10~20분씩 걸려 반복 설계가 어려웠음.
  • ChatGPT Desktop으로 전체 모의 애플리케이션을 만든 결과, 여러 화면 환경과 시작 구성을 아우르며 요구 동작과 사용 사례를 명확히 보여주는 프로토타입을 완성하는 데 약 세 시간이 들었음.
  • 복잡한 백엔드 작업이 포함된 사용자 흐름은 HTML 프로토타입으로 다양한 상황을 빠르게 시험한 뒤 한 번에 구현하는 방식이 효과적임.

배경

  • Emm은 에이전트와 사람이 함께 쓰는 로컬 우선 노트 관리자이자 이슈 트래커임.
  • 클라우드에 연결하지 않고도 사용자가 로컬 에이전트로 작업을 시작할 수 있어야 함.
  • 이 조건은 다음과 같은 복잡성을 만듦.
  • 프로젝트는 클라우드에 백업되기 전에 먼저 존재함.
  • 사용자는 여러 프로젝트를 보유할 수 있음.
  • Emm 서버와 동기화하려면 로그인한 사용자가 필요함.
  • 사용자는 로그인한 계정을 바꾸고 싶을 수 있음.
  • 신생 기업인 만큼 첫 사용자 경험은 사업의 성패에 직결될 만큼 중요함.

첫 번째 시도: 에이전트에 워크플로 설계 맡기기

  • Astra에 질문을 하고, 핵심 의사결정을 파악하고, 선택지를 만든 뒤, 명세를 작성하도록 요청했으며 이후 명세의 구현도 맡김.
  • 에이전트는 과거라면 며칠이 걸렸을 기반 작업을 처리했지만, 선택한 흐름에서는 4번의 클릭이면 충분한 작업에 사용자가 7번 클릭해야 했음.
  • 의사결정이 필요하지 않은 페이지로 사용자를 이동시켰으며, 더 적은 페이지로 흐름을 통합할 수 있었음.

두 번째 시도: 화면을 하나씩 만들기

  • 전체 경험을 화면 단위로 구현하는 전략을 택함. 프로젝트 생성부터 클라우드에 올리기, 사용자 초대, 초대 수락 등의 순서로 진행함.
  • 에이전트의 디자인 감각에 기대지 않고 원하는 내용을 구체적으로 지시한 뒤, 구현을 확인하고 피드백을 주고 다음 화면을 요청함.
  • 이 방식도 두 가지 이유로 실패함.
  • 앱 전체가 프레임워크 없이 순수 Rust로 작성돼 있어 간단한 변경에도 에이전트가 10~20분을 소비함. 로그인 흐름의 분기 하나를 추가하는 데도 몇 시간이 걸릴 수 있음.
  • 디자인은 반복적인 과정임. 기본적으로 동작하지만 사용자에게 혼란을 주고 모든 예외 상황을 잘 처리하지 못하는 결과물을 만들었으며, 기존 방식으로 다시 만들려면 8시간 이상이 더 필요함.

세 번째 시도: 성공한 ChatGPT Desktop HTML 프로토타입

  • Herdr 호스팅 Codex에서 ChatGPT Desktop으로 전환하고 전체 모의 애플리케이션을 만들도록 요청함.
  • 프로토타입에서 다룬 화면 환경은 웹 브라우저, 앱, macOS 패스키 팝업, 이메일 등 여러 표면에 걸쳐 있었으며, 특정 표면에 속하지 않는 페이지도 포함함.
  • 서로 다른 시작 구성을 시험할 수 있도록 드롭다운을 선택함.
  • 작업은 반복적이었고 여러 의사결정과 테스트가 필요해 완성까지 꼬박 세 시간이 들었음. 밤 11시 30분 무렵에는 집중력이 떨어진 상태였지만, 최종 프로토타입은 원하는 동작을 명확히 보여주고 모든 사용 사례를 다룸.
  • 이후 에이전트가 밤새 작업을 완료하도록 둠.

교훈

  • 복잡한 백엔드 작업이 포함된 사용자 워크플로를 설계할 때는 AI 에이전트가 HTML로 작동하는 프로토타입을 만들도록 하고, 모든 상황을 빠르게 시험하고 검토한 뒤 한 번에 구현하도록 하는 방식이 효과적임.