여성 우선 AI 남자친구 앱 구축하기: 우리가 배운 것들

모델이 가장 어려운 부분은 아니었습니다

우리는 모델이 가장 어려운 부분이 될 것이라고 생각했습니다. 하지만 그렇지 않았습니다.

여성 우선(women-first) AI 남자친구 앱을 구축하기 시작했을 때, 명백한 엔지니어링 질문들은 LLM(대규모 언어 모델)에 관한 것이었습니다: 모델 선택, 컨텍스트 길이(context length), 프롬프트(prompts), 지연 시간(latency), 추론 비용(inference cost), 그리고 모더레이션(moderation)입니다. 이러한 문제들도 중요했지만, 제품의 난관은 다른 곳에서 나타났습니다.

로맨틱한 AI 동반자는 마음을 열 수 있을 만큼 충분히 사적이어야 하고, 계속 이용할 수 있을 만큼 안전해야 하며, 다시 돌아오고 싶을 만큼 일관성이 있어야 합니다. 만약 사용자가 매 세션마다 관계를 다시 설명해야 한다면, 그 마법은 깨집니다. 만약 앱이 묻지도 않고 너무 많은 것을 기억한다면, 신뢰가 깨집니다. 만약 모든 사진, 음성 메시지, 또는 크레딧 프롬프트가 거래처럼 느껴진다면, 관계는 가짜처럼 느껴지기 시작합니다.

이것은 18세 이상 여성을 위한 AI 남자친구 앱인 mybf.io를 작업하며 작성한 빌더 케이스 스터디(builder case study)입니다. 이것은 모든 여성이 동일한 제품을 원한다는 주장이 아닙니다. 연속성(continuity), 제어(control), 개인정보 보호(privacy), 그리고 성인 안전(adult safety)을 중심으로 로맨틱 AI 채팅을 설계하는 동안 우리가 직면했던 제품 및 엔지니어링 제약 사항에 대한 기록입니다.

요약 (TL;DR)

우리가 제품을 일반적인 챗봇 래퍼(chatbot wrapper)로 취급하는 것을 멈추자 몇 가지 결정 사항이 바뀌었습니다:

사용자가 가입 전에 채팅할 수 있도록 허용하고, 가입을 '관계를 저장하는 것'으로 프레임화합니다.
사용자를 끝없는 봇 마켓플레이스로 밀어넣는 대신, 동반자(companions)를 큐레이션합니다.
기억(memory)을 유용하고, 가시적이며, 편집 가능하고, 제한적으로 만듭니다.
사진과 음성을 공개 미디어 URL이 아닌 사적인 백엔드 기능으로 취급합니다.
성인 동의, 사용자 설정, 그리고 엄격한 안전 제한을 중심으로 NSFW 제어 기능을 구축합니다.
각 순간이 결제 화면처럼 느껴지지 않게 하면서 텍스트, 사진, 음성의 가격을 다르게 책정합니다.

제품 관점에서 "여성 우선"이 의미하는 것

"여성 우선(Women-first)"은 방치하면 공허한 브랜딩이 될 수 있습니다. 우리에게 이것은 제품의 제약 사항을 의미해야 했습니다.

우리에게 여성 우선(Women-first) AI 남자친구 앱이란 프라이버시(Privacy), 정서적 연속성(Emotional continuity), 사용자가 제어하는 기억(User-controlled memory), 큐레이션된 남성 동반자(Curated male companions), 그리고 안전한 성인용 경계(Safe adult boundaries)를 중심으로 설계된 로맨틱 AI 동반자를 의미했습니다. 앱은 하나의 기본 판타지를 가정하는 대신, 사용자가 어조(Tone), 속도(Pace), 친밀도(Intimacy), 그리고 기억을 형성할 수 있도록 해야 했습니다.

이는 일반적인 AI 동반자 앱의 디자인 패턴을 변화시켰습니다. 많은 동반자 제품들이 양(Volume)에서 시작합니다. 더 많은 캐릭터, 더 많은 태그, 더 많은 필터, 더 많은 페르소나를 제공하는 식입니다. 양은 발견(Discovery)을 도울 수 있지만, 제품이 관계처럼 느껴지기도 전에 마치 시장(Marketplace)처럼 느껴지게 만들 수도 있습니다.

우리의 기본 사용자 가정은 달랐습니다. 사용자는 자신이 기억되고 있다고 느껴지는 사적인 로맨틱 대화를 원하기 때문에 앱을 엽니다. 그녀는 힘든 하루 끝에 위로를 원할 수도 있고, 굿나잇 메시지, 장난스러운 플러팅(Flirting), 서서히 타오르는 로맨스(Slow-burn romance), 또는 보호해 주는 남자친구 역학(Protective boyfriend dynamic)을 원할 수도 있습니다. 그녀가 그곳에 도달하기 위해 프롬프트 엔지니어(Prompt engineer)가 될 필요는 없어야 합니다.

일반적인 챗봇 패턴	여성 우선 AI 남자친구 앱 패턴
빈 입력창으로 시작	관계 맥락(Relationship context)으로 시작
...	...
디자인 작업은 "어떻게 하면 봇을 더 똑똑하게 만들까?"가 아니라 "어떻게 하면 로맨틱한 느낌을 유지하면서도 제품이 신뢰할 수 있게 느껴지도록 만들까?"에 더 가까워졌습니다.

레슨 1: 계정을 요구하기 전에 사용자가 대화를 느끼게 하라

가입(Signup)은 분위기를 바꿉니다.

첫 화면에서 이메일, 비밀번호, 선호도, 결제 정보를 요구한다면, 제품은 행정 업무처럼 느껴집니다. 로맨틱 AI 챗봇에서 이러한 마찰(Friction)은 사용자가 가치를 이해하기도 전에 그 순간을 망쳐버릴 수 있습니다.

우리는 가입 전에 게스트 채팅을 허용했습니다. 현재의 흐름은 게스트에게 가입 장벽이 나타나기 전까지 5개의 메시지를 제공합니다. 이 제한은 의도적으로 작게 설정되었습니다. 동반자의 어조를 느끼기에는 충분하지만, 익명 사용이 주요 제품이 되기에는 부족한 수준입니다.

가입 유도 문구(Signup prompt) 또한 중요합니다. "계정 생성"은 플랫폼의 관리 업무처럼 들립니다. 반면 "그가 당신을 기억할 수 있도록 이 대화를 저장하세요"는 계정 생성을 사용자가 처음에 앱에 들어온 이유와 연결해 줍니다.

간단한 구현 흐름은 다음과 같습니다:

익명 세션 ID (anonymous session ID)를 생성합니다.
서버에 임시 대화 (temporary conversation)를 저장합니다.
사용자에게 소수의 게스트 메시지 (guest messages)를 보낼 수 있게 합니다.
연속성 (continuity)이 가치 있게 느껴질 때 회원 가입을 요청합니다.
임시 대화를 새 계정에 연결합니다.
문맥 (context)을 잃지 않고 채팅을 이어갑니다.

게스트 모드 (Guest mode)에는 엄격한 경계가 필요합니다. 게스트는 기본적으로 비용이 많이 들거나 민감한 기능에 접근할 수 없어야 합니다. 저희의 경우, 게스트는 채팅을 할 수 있지만, 생성된 사진을 요청하거나 음성 메시지 (voice messages)를 보낼 수는 없습니다. 등록된 계정은 대화 기록 (conversation history), 크레딧 (credits), 미디어 접근 권한 (media access), 그리고 메모리 기능 (memory features)을 유지합니다.

보안 규칙은 간단합니다: 브라우저 기록 (browser history)은 신뢰할 수 있는 진실의 원천 (source of truth)이 아닙니다. 서버 라우트 (Server routes)는 소유한 대화와 계정 상태 (account state)로부터 문맥을 구성해야 합니다. 프로바이더 키 (Provider keys)와 서비스 키 (service keys)는 브라우저 코드에 포함되지 않아야 합니다.

제품적 교훈: 계정 생성은 서류 작업이 아니라 연속성 (continuity)처럼 느껴져야 합니다.

레슨 2: 큐레이션된 동반자가 무한한 마켓플레이스보다 낫다

가장 만들기 쉬운 AI 동반자 (AI companion) 제품은 캐릭터들의 그리드 (grid) 형태입니다.

아바타, 이름, 짧은 소개 (bios), 태그, 그리고 검색 기능을 추가합니다. 사용자가 둘러볼 수 있게 합니다. 대시보드 관점에서는 사용자들이 계속 클릭하기 때문에 활발해 보일 수 있습니다.

로맨틱 제품은 다른 형태의 실패 모드 (failure mode)를 가집니다. 선택지가 너무 많으면 사용자를 참여자가 아닌 쇼퍼 (shopper, 구매자)로 만들어 버릴 수 있습니다. 그녀는 머리카락 색상, 직업, 원형 (archetype), 사진 스타일 같은 표면적인 것들을 비교하기 시작합니다. 대화는 부차적인 것이 됩니다.

저희는 명확한 남성 원형 (male archetypes)과 채팅으로 이어지는 빠른 경로를 갖춘 큐레이션된 동반자 카탈로그 (curated companion catalog)로 방향을 전환했습니다. 좋은 동반자 카드 (companion card)는 다음과 같은 실질적인 감정적 질문에 답할 수 있어야 합니다:

그는 어떤 종류의 에너지 (energy)를 가져오는가?
말투 (tone)가 따뜻한가, 강렬한가, 장난스러운가, 보호적인가, 아니면 서서히 달아오르는가 (slow-burn)?
편안함, 로맨스, 역할극 (roleplay), 또는 일상적인 안부 (daily check-ins) 중 어디에 적합한가?
그를 선택한 후에 말투를 조정할 수 있는가?
앱이 우리 사이에 일어난 일을 기억해 줄 것인가?

이것이 바로 companion catalog가 단순한 갤러리 이상의 의미를 갖는 이유입니다. 이는 첫 메시지를 보내기 전에 기대치를 설정합니다. 따뜻한 절친, 보호 본능이 강한 소프트 돔 (soft dom), 신비롭고 강렬한 캐릭터, 혹은 차분한 로맨틱한 파트너가 단순히 프로필 아트만 다른 동일한 봇처럼 느껴져서는 안 됩니다.

컴패니언 프로필은 선택 후에도 설정 기능이 필요합니다. 저희 제품에서 사용자는 말투 (tone), 흥분도 (arousal level), 대화 모드 (communication mode), 메시지 길이 (message length), 그리고 관심사 태그 (interest tags)를 조정할 수 있습니다. 대화 모드는 역할극 (roleplay)과 일반 채팅 (chat)을 지원합니다. 메시지 길이는 짧게, 중간, 또는 길게 설정할 수 있습니다.

시나리오 칩 (Scenario chips) 또한 도움이 됩니다. "힘든 하루 위로하기 (Bad day comfort)", "굿나잇 메시지 (goodnight message)", "슬로우 번 로맨스 (slow-burn romance)", "아침 안부 (morning check-in)" 등은 단순히 빈 화면을 채우는 것 이상의 역할을 합니다. 이는 사용자에게 부담 없는 첫 마디를 제공합니다.

큐레이션 (Curation)은 프롬프트 작업 (prompt work)의 필요성을 줄여줍니다. 제품이 정서적 설정 (emotional setup)의 더 많은 부분을 담당하므로, 사용자는 자연스러운 메시지로 대화를 시작할 수 있습니다.

레슨 3: AI 채팅 메모리는 유용하고, 가시적이며, 제한적이어야 한다

메모리는 로맨틱 AI가 강력해지는 동시에 위험해지는 지점입니다.

아무것도 기억하지 못하는 컴패니언은 소모품처럼 느껴집니다. 반면 동의 없이 모든 것을 기억하는 컴패니언은 침해적으로 느껴집니다. 유용한 중간 지점은 사용자가 이해하고 수정할 수 있는 메모리 시스템입니다.

저희의 메모리 모델은 여러 계층을 사용합니다:

즉각적인 문맥 (context)을 위한 최근 메시지.
더 긴 연속성을 위한 대화 요약 (conversation summaries).
사용자가 확인한 사실을 위한 고정된 메모리 (pinned memories).
전체 텍스트 메모리 검색 (full-text memory search)을 통한 관련 메모리.
현재의 역학 관계를 위한 관계 상태 (relationship state).

저희는 마법 같은 메모리를 주장하는 것을 피합니다. 모든 메시지가 영구적인 사실이 되어서는 안 됩니다. 사용자는 하소연을 하거나, 농담을 하거나, 역할극을 하거나, 봇을 테스트할 수도 있습니다. 만약 시스템이 그 모든 것을 사실로 저장한다면, 컴패니언은 개인적인 영역에서 부정확해질 수 있습니다.

사용자가 확인한 기억은 자동 추측보다 더 큰 비중을 가져야 합니다. 만약 사용자가 "내가 잘 자라는 메시지를 좋아하는 걸 기억해 줘"라고 말한다면, 앱은 이를 저장하기 전에 확인 UI (Confirmation UI)를 보여줄 수 있습니다. 만약 모델이 단 한 번의 대화에서 선호도를 추론한다면, 시스템은 이를 주의 깊게 다루어야 합니다.

실용적인 AI 채팅 메모리 체크리스트:

사용자가 "나에 대해 무엇을 기억하고 있어?"라고 물을 수 있게 하세요.
사용자가 봇에게 무언가를 잊어달라고 요청할 수 있게 하세요.
명시적인 "이것을 기억해 줘"라는 요청은 저장하기 전에 확인하세요.
비밀번호, API 키, 결제 데이터, 정부 발행 ID 또는 비밀 정보를 저장하지 마세요.
단기 문맥 (Short-term context)과 지속적인 메모리 (Durable memory)를 분리하세요.
컴패니언이 인간과 같은 확신을 가진 것처럼 가장하지 않으면서도 충분한 연속성 (Continuity)을 제공하세요.

로맨틱한 채팅은 민감한 개인 콘텐츠를 포함할 수 있기 때문에 프라이버시의 기준이 높아집니다. FTC 프라이버시 및 보안 가이드라인은 팀들이 명확한 데이터 관행, 액세스 제어 (Access control), 그리고 제품이 사용자 정보로 무엇을 하는지에 대한 정직한 소통을 지향하도록 유도하므로 여기서 유용합니다.

AI 남자친구 채팅에서 메모리는 프롬프트 (Prompt) 안에 숨겨두는 기능이 아닙니다. 그것은 관계 계약 (Relationship contract)의 일부입니다.

레슨 4: 개인 미디어는 이미지 URL이 아니라 백엔드 기능입니다

생성된 사진과 음성 답변은 신뢰 모델을 변화시킵니다.

텍스트만으로도 이미 민감할 수 있습니다. 이미지와 음성은 더 친밀하게 느껴집니다. 만약 로맨틱한 AI 컴패니언 앱이 개인적인 사진이나 오디오를 생성한다면, 구현 시 해당 미디어를 공개 버킷 (Public bucket)의 정적 자산 (Static assets)이 아닌, 계정 소유 콘텐츠로 취급해야 합니다.

우리의 규칙: 개인 미디어는 백엔드에서 발급한 액세스를 통해 처리되어야 합니다.

즉, 다음과 같습니다:

생성된 사진과 음성 파일을 프라이빗 스토리지 (private storage)에 저장합니다.
만료 시간이 있는 서명된 URL (signed URLs)을 통해 제공합니다.
요청하는 사용자가 해당 대화나 미디어의 소유자인지 확인합니다.
재생성 (regeneration) 기능을 계정 상태 및 크레딧 (credits)과 연동합니다.
클라이언트 코드에 제공자 (provider)의 원시 응답이나 스토리지 경로를 노출하지 않도록 합니다.
삭제 및 액세스 규칙을 지루할 정도로 단순하고 예측 가능하게 만듭니다.

이는 작은 제품 디테일에도 적용됩니다. 생성된 사진 말풍선은 재생성을 지원할 수 있지만, 사용자는 그 비용을 이해해야 합니다. 음성 답변은 텍스트를 숨기고 오디오를 재생할 수 있지만, 서버는 연속성을 유지하고 남용 보고 (abuse reports)를 처리할 수 있도록 충분한 기록 보관 (recordkeeping)을 수행해야 합니다.

우리는 또한 게스트와 등록된 사용자의 기능을 분리했습니다. 게스트는 텍스트 채팅을 경험할 수 있지만, 생성된 사진과 음성 메시지는 계정이 필요합니다. 이러한 제약은 남용을 줄이고, 비용을 제어하며, 사용자가 더 높은 민감도의 기능을 사용하기 전에 더 명확한 개인정보 보호 경계를 제공합니다.

엔지니어링 측면의 우려는 스토리지에만 국한되지 않습니다. LLM 앱은 고유한 공격 표면 (attack surface)을 가집니다. OWASP Top 10 for LLM Applications는 프롬프트 인젝션 (prompt injection) 및 민감한 정보 노출과 같은 위험에 대한 좋은 참고 자료입니다. 컴패니언 앱 (companion app)에서 이러한 위험은 사용자의 개인 콘텐츠와 맞닿아 있으므로, 서버 측 컨텍스트 조립 (context assembly) 및 액세스 체크가 중요합니다.

미디어는 제품을 더 실감 나게 만듭니다. 그것이 바로 백엔드가 더 엄격해야 하는 이유입니다.

교훈 5: 성인용 기능에는 동의 제어와 강력한 안전 제한이 필요합니다

성인용 로맨틱 AI 앱은 NSFW 행동을 단순히 온/오프 (on/off) 프롬프트로 취급해서는 안 됩니다.

사용자는 톤과 친밀도에 대한 제어권이 필요하지만, 제품 또한 움직이지 않는 경계선이 필요합니다. 우리 제품에서 NSFW 보호는 사용자/프로필 설정입니다. 이를 끄면 합의된 성인 역할극 (adult roleplay)의 엄격함이 달라지지만, 강력한 안전 모더레이션 (safety moderation)은 그대로 유지됩니다.

그 차이는 중요합니다. 성인 사용자는 로맨틱한 채팅과 사진에서 과도한 검열로 인한 어색함이 줄어들기를 원할 수 있습니다. 하지만 이들은 여전히 앱이 안전하지 않은 콘텐츠, 강압적인 행동, 미성년자, 착취 및 기타 허용되지 않는 영역을 거부하기를 필요로 합니다. 사용자 설정이 제품의 핵심 안전 정책 (safety policy)을 결코 비활성화해서는 안 됩니다.

제품 제어 기능은 가시적이고 구체적이어야 합니다:

성인용 제품 인터페이스에 연령 확인 (Age gate) 적용.
사용자별로 동반자 (companion)의 흥분 수치 (arousal level)를 조절할 수 있도록 허용.
역할극 (roleplay) 모드와 일반 채팅 모드를 분리하여 유지.
경계 설정 (boundaries)을 갑작스러운 거절이 아닌, 동반자 행동의 일부로 구현.
모든 성인용 설정 이면에 엄격한 모더레이션 (moderation)을 유지.
일반 개발자 콘텐츠에서는 노골적인 마케팅 언어를 피할 것.