AI 이미지 도구의 어려운 부분은 모델 자체가 아니다

많은 AI 이미지 제품들은 동일한 데모로 시작합니다:

이미지를 업로드한다.
모델을 호출한다.
결과를 보여준다.

이 흐름은 제품 데모에서는 간단해 보입니다. 하지만 실제 애플리케이션에서는 보통 가장 쉬운 부분일 뿐입니다.

어려운 작업은 모델 주변의 모든 것입니다: 사용자가 실제로 무엇을 하려고 하는지 결정하고, 업로드를 이해하기 쉽게 만들고, 느리거나 실패하는 요청을 처리하며, 사용자 신뢰를 유지하고, 제공업체가 지원하는 모든 기술적 옵션을 노출하는 UI를 피하는 것 등이 포함됩니다.

저는 Image to Anime라는 작은 웹 워크스페이스를 개발해 왔는데, 이 프로젝트는 유용한 AI 도구가 대부분 '워크플로우(workflow)' 문제임을 가르쳐 주었습니다.

하나의 명확한 작업부터 시작하라

AI 제품의 첫 번째 버전은 종종 너무 많은 것을 하려고 합니다.

텍스트-이미지 생성, 이미지 편집, 스타일 변환(style transfer), 업스케일링(upscaling), 배경 제거, 모델 선택, 해상도 제어, 품질 설정, 화면 비율 등 길고 긴 고급 옵션들을 포함할 수 있습니다.

기술적으로 이러한 기능들은 인상적입니다. 하지만 사용자 관점에서는 첫 단계를 더 어렵게 만들 수 있습니다.

Image to Anime의 첫 버전은 핵심 작업을 의도적으로 좁게 정의했습니다:

사진이나 일러스트를 가져와 애니메이션 아트로 변환한다.

이 좁은 정의는 거의 모든 디자인 결정에 영향을 미칩니다:

업로드 영역이 가장 중요한 컨트롤입니다.
스타일 선택이 모델 이름보다 더 중요합니다.
결과 미리보기가 긴 설정 패널보다 더 중요합니다.
인터페이스는 사용자에게 근본적인 기술을 이해하라고 요구하기 전에 무언가를 만들도록 도와야 합니다.

이는 고급 컨트롤이 전혀 쓸모없다는 의미가 아닙니다. 단지 API가 노출한다고 해서 추가하는 것이 아니라, 실제 사용자 문제를 해결할 때 추가되어야 한다는 의미입니다.

업로드 영역은 제품의 일부이다

업로드 버튼만으로는 충분하지 않습니다.

사용자는 무엇을 업로드할 수 있는지, 다음에 무슨 일이 일어날지, 그리고 자신의 이미지가 적합한지 이해해야 합니다. 좋은 업로드 경험은 문서가 필요하지 않으면서 이러한 질문에 답합니다.

중요한 세부 사항들:

어떤 파일 형식이 지원되나요?
파일 크기 제한이 있나요?
이미지 미리보기가 즉시 나타나나요?
사용자가 선택한 이미지를 교체할 수 있나요?
파일을 업로드하는 동안 무슨 일이 일어나나요?
업로드가 실패하면 어떻게 되나요?

이미지 변환 도구의 경우, 원본 이미지 또한 창의적인 입력 요소의 일부입니다. 명확한 인물 사진, 눈에 띄는 피사체, 그리고 합리적으로 구성된 이미지가 매우 작거나 심하게 압축된 이미지보다 더 예측 가능한 결과를 생성하는 경향이 있습니다.

이는 단순히 더 나은 문구(copy)만으로는 완전히 해결할 수 있는 제한 사항이 아닙니다. 인터페이스는 사용자가 크레딧을 소모하거나 결과가 나올 때까지 기다리기 전에, 이러한 제한 사항을 초기에 눈에 띄게 만들어야 합니다.

사용자에게 모델 선택을 강요하지 마세요

AI 제품들은 종종 개발자의 구현에서 모델이 중심이기 때문에 모델 선택기를 노출합니다.

하지만 그것들이 항상 사용자의 목표에서 중심인 것은 아닙니다.

대부분의 사용자는 모델 버전, 추론 제공업체(inference providers), 또는 숨겨진 품질 매개변수를 비교하고 싶어 하지 않습니다. 그들은 시각적인 방향을 설명하고 그것에 맞는 결과를 받고 싶어 합니다.

더 간단한 인터페이스도 의미 있는 제어를 지원할 수 있습니다:

시각적 스타일 선택하기.
짧은 창의적 방향 추가하기.
원래 피사체가 인식 가능하게 유지하기.
결과 검토하기.
필요할 때 다시 시도하기.

제공업체(provider)와 모델은 서버 측 구성으로 남겨둘 수 있습니다. 이는 또한 개인 API 키나 제공업체별 요청 세부 정보가 브라우저로 유출되는 것을 방지합니다.

비동기 상태를 명시적으로 만드세요

이미지 생성은 즉각적인 상호작용이 아닙니다. 이를 그러한 것처럼 취급하면 혼란스러운 인터페이스를 만들게 됩니다.

유용한 생성 흐름은 뚜렷한 상태들을 가집니다:

type GenerationState = 
  | "idle"
  | "source-selected"
...

각 상태는 다른 UI 응답을 필요로 합니다.

업로드 중에는 사용자가 소스 파일이 준비되고 있음을 알아야 합니다. 생성 중에는 일반적인 “로딩 중...” 레이블을 표시하기보다 창의적인 작업 과정을 설명하는 메시지를 보여주어야 합니다. 성공 후에는 명확한 미리보기와 다운로드 액션이 필요합니다. 실패했을 경우에는 사용자에게 설명과 합리적인 다음 단계가 제공되어야 합니다.

이는 사용자가 API 요청 자체를 경험하지 않기 때문입니다. 그들이 경험하는 것은 기다림, 불확실성, 그리고 피드백입니다.

주제는 유지하되, 모든 픽셀은 아닐 필요는 없다

사진을 애니메이션으로 변환하는 도구(photo-to-anime tool)가 픽셀 단위의 완벽한 보존을 약속해서는 안 됩니다. 결과물은 새로운 해석이기 때문입니다.

동시에, 사용자들은 일반적으로 중요한 요소들이 인식 가능한 상태로 유지되기를 기대합니다:

얼굴 특징(facial features)
헤어스타일(hairstyle)
포즈(pose)
의상(clothing)
구도(framing)
주요 배경 요소(major background elements)

이것은 유용한 제품 목표를 만듭니다: 시각적 언어를 변경하면서 정체성과 구도를 보존하는 것입니다.

또한, 이것은 솔직한 제품 경계선도 만듭니다. 다양한 소스 이미지와 스타일은 다른 결과를 낳습니다. 좋은 인터페이스는 모든 결과물이 원본과 동일할 것이라고 암시하기보다는, 다시 시도하거나 짧은 지침을 추가하기 쉽게 만들어야 합니다.

결과 영역은 차분하게 유지해야 한다

결과 영역은 사용자들이 도구가 작동했는지 여부를 결정하는 곳입니다.

여기는 출력물 자체와 경쟁해서는 안 됩니다. 많은 카드, 기술 메타데이터(technical metadata), 모델 세부 정보가 결과 평가를 어렵게 만들 수 있습니다.

정적인 이미지 워크플로우의 경우, 결과 표면은 몇 가지 요소만 필요합니다:

제한된 이미지 미리보기(contained image preview)
명확한 성공 또는 실패 상태(clear success or failure state)
다운로드 액션(download action)
다른 시도를 시작하는 방법(a way to start another attempt)

여기서도 시각적 일관성이 중요합니다. 비어 있거나, 처리 중이거나, 실패한 상태는 관련 없는 화면이라기보다는 같은 작업 공간의 일부처럼 느껴져야 합니다.

크레딧과 실패는 제품 동작 방식이다

만약 생성이 크레딧을 소모한다면, 크레딧 시스템은 사후 고려 사항으로 취급될 수 없습니다.

클라이언트는 빠른 피드백을 위해 잔액을 확인할 수 있지만, 서버가 최종 청구를 강제해야 합니다. 실패한 제공자 요청이 사용자 잔액을 조용히 소모해서는 안 됩니다. 시스템은 청구에 대한 권위 있는 기록과 적절할 때 이를 환불할 수 있는 실패 경로를 필요로 합니다.

이는 단순히 결제 문제가 아닙니다. 이는 사용자 신뢰의 일부입니다.

제품이 비용과 실패를 이해하기 쉽게 만들 때, 사용자는 창의적인 도구를 다시 시도할 가능성이 더 높습니다.

제가 여전히 배우고 있는 것들

이 프로젝트는 의도적으로 작게 유지되고 있습니다. 나중에 추가될 수 있는 많은 기능들이 있습니다:

더 많은 스타일 레퍼런스
강화된 편집 컨트롤
배치 생성(batch generation)
이미지 히스토리
더 많은 내보내기 옵션
원본과 결과물 간의 더 나은 비교

하지만 기능을 추가하는 것이 자동으로 진전을 의미하지는 않습니다. 새로운 컨트롤 하나하나는 결정, 상태(states), 유효성 검사(validation), 그리고 유지보수를 추가합니다.

더 유용한 질문은 다음과 같습니다:

이것이 사용자가 불확실성을 줄여 의도한 시각적 결과에 도달하는 데 도움을 주는가?

그 질문이 다음에 어떤 AI 기능을 추가할 수 있는지 묻는 것보다 더 가치 있었습니다.

마지막 생각

모델은 중요하지만, 제품의 한 부분일 뿐입니다.

성공적인 AI 이미지 워크플로우에는 명확한 역할(job), 사려 깊은 업로드 경험, 명시적인 비동기 상태(asynchronous states), 솔직한 기대치, 신뢰할 수 있는 실패 처리, 그리고 이미지에 주의를 집중시키는 결과 영역이 필요합니다.

목표는 기술을 숨기는 것이 아닙니다. 기술을 이해하기 쉽게 만드는 것입니다.

제가 Image to Anime에서 탐구하고 있는 방향이 바로 그것입니다: 먼저 하나의 집중된 워크플로우에 초점을 맞추고, 창의적인 프로세스를 진정으로 개선할 때만 더 많은 기능을 추가하는 방식입니다.