프로젝트에 React Native를 도입할 때 크게 두 가지 방식이 있습니다.
프로젝트를 처음부터 React Native 로 개발한다.
현재 프로젝트에 부분적으로 React Native 를 도입한다.
베트남의 토스앱을 개발하던 때는 운영되는 서비스를 잠시 멈추고 React Native로 새로 개발했었습니다. 그 시점에 앱의 기능이 그렇게 많지 않았기 때문에 가능했었습니다. 하지만 한국에서 서비스 하고 있는 토스앱은 그렇지 않았습니다.
토스의 React Native 도입 배경
토스앱은 사실 크로스 플랫폼을 활용하기 위해 React Native를 도입했던 것은 아니었습니다. 2021년 코로나가 극심할 때 식당이나 카페등 가게에 출입하기 위해  QR인증을 했던 것을 기억하실것입니다. 그 때 QR인증을 위해 나라에서 지정한 업체의 SDK 를 사용해야 했습니다. 그런데 그 업체가 React Native로 된 SDK를 전달해주었고, 그렇게 토스앱에 React Native가 포함되었습니다. 
이후 토스 내부에서도 웹서비스의 화면들을 더 빠르게 로드해야 한다는 요구사항과 겹쳐서 React를 다루는 Frontend 개발자들이 앱에 포함되어 있는 React Native를 살려 크로스 플랫폼 도구로 사용하게 되었습니다.
토스와 비슷하게 많은 회사들이 각자 다른 이유로 운영 중인 서비스를 크로스 플랫폼으로 확장하고자 React Native를 도입하려고 할 것입니다. 이런 경우에 CocoaPods를 사용하지 않고 React Native를 도입하는 방법을 알려드리겠습니다. 
React Native와 의존성 관리 도구
운영되는 앱에 React Native를 도입하기로 결정했을 때 iOS 개발자의 입장을 생각해봅시다. React Native는 기본적으로 CocoaPods로 설치되도록 되어 있어요. 현재 운영하고 있는 서비스가 CocoaPods를  의존성 관리 도구로 사용하고 있다면, 큰 어려움 없이 React Native를 도입할 수 있습니다.
하지만 iOS 개발 환경에는 CocoaPods 외에도 여러 가지의 의존성 관리 도구가 있습니다. 애플의 First Party인 Swift Package Manager 나, Carthage, Rome, 등등이 있습니다. 의존성 관리 도구는 아니지만 프로젝트 설정 관리 도구인 Tuist도 있습니다.
그럼 CocoaPods 외에 다른 의존성 관리 도구를 사용하고 있다면 어떻게 React Native를 도입할 수 있을까요?  사용 중인 의존성 관리 도구와 CocoaPods를 함께 사용해야 합니다. CocoaPods를 사용하고 있지 않다면 CocoaPods를 추가하면 되고, CocoaPods를 이미 병행으로 사용하고 있다면 해당 Podfile에 React Native 관련 의존성을 추가하면 됩니다. 
하지만 이렇게 의존성 관리 도구를 병행하는 것은 좋은 방법이 아닙니다.
왜 의존성 관리 도구를 하나만 써야 할까?
두 가지 이상의 의존성 관리 도구를 사용한다면 각각의 의존성 관리 도구는 각자가 관리하는 의존성들만 Resolve할 뿐, 서로가 관리하고 있는 의존성을 알 수 없습니다. 즉 CocoaPods에서 A라는 라이브러리를 추가하고, Swift Package Manager 에서 A라는 라이브러리를 추가하면 라이브러리 A가 중복됩니다. 

라이브러리 B가 라이브러리 A에 의존하고, 라이브러리 C가 라이브러리 A에 의존한다고 생각해볼게요. 

이때 라이브러리 B를 CocoaPods에, 그리고 라이브러리 C를 Swift Package Manager에 추가하여 관리한다면 다음 그림처럼 됩니다. 

이처럼 라이브러리 A가 중복되고 빌드나 아카이브에 실패합니다. 
이 문제를 해결하기 위해 강제로 B가 A에 의존하지 않도록 해야 합니다. 그러기 위해 해야 하는 작업은 다음과 같습니다.
라이브러리 B 의 레포를 찾아 Fork 한다.
Fork 한 레포에서 podspec 파일을 찾는다.
podspec 파일에서 라이브러리 A에 대한 의존성 항목을 찾아서 삭제한다. 
Podfile에서 라이브러리  B의 레포 경로를 내가 수정한 레포지토리로 지정한다.
이러한 작업을 울며 겨자먹기로 할 수밖에 없습니다. 

하지만 이런 경우엔 의존성 커스텀 히스토리를 잘 관리해야 합니다. 그렇지 않으면 지뢰가 되어 추후에 문제가 생길 수 있기 때문이에요. 
Swift Package Manager에서 라이브러리 C가 더 이상 필요하지 않아 제거하게 되면 라이브러리 A도 함께 사라지기 때문에 라이브러리 B가 바라보던 라이브러리 A도 사라져 빌드에 실패하게 됩니다. 
나중에 이 히스토리를 모르는 다른 사람이 fork한 레포를 사용하지 않고 원본 레포를 사용한다면 A 라이브러리 중복 문제가 다시 나타나고, 원인을 알기 어려워 시간을 허비하게 됩니다.
이처럼 히스토리를 모르면 해결하기 어려운 문제들이 일어납니다. 그렇기 때문에 히스토리를 잘 관리하거나,  의존성 관리 도구는 하나만 사용하는 것이 좋습니다. 

CocoaPods 없이 React Native 라이브러리 포함하기
지금까지 의존성 관리 도구를 하나만 사용해야 되는 이유를 설명해드렸습니다. 그렇다면 이미 운영 중인 서비스의 의존성 관리 도구로 반드시 CocoaPods를 사용해야 될까요? 이제부터는 CocoaPods를 사용하지 않고 하나의 의존성 관리 도구로 React Native를 도입할 수 있는 방법을 알려드리겠습니다. 
React Native 라이브러리들을 미리 XCFramework로 빌드한 다음에 내 프로젝트에 포함하면 됩니다. 미리 빌드 하는 과정에서 사실은  CocoaPods를 여전히 사용하게 됩니다. 이 방법을 Prebuild 라 부르겠습니다. 
따라해보기
그렇다면 이제 ReactNative를 XCFramework로 빌드 하는 방법을 단계별로 알아보겠습니다.

스크립트를 이용해 프로젝트를 만듭니다.
react_native_prebuild 디렉토리를 생성 후 진입합니다.
mkdir react_native_prebuild
cd react_native_prebuild
프로젝트 생성 스크립트를 만듭니다. 
gem install xcodeproj
echo "require 'xcodeproj'

# 새로운 프로젝트 생성
project = Xcodeproj::Project.new('ReactNativePrebuild.xcodeproj')

# 타겟 추가
project.new_target(:application, 'ReactNativePrebuild', :ios)

# 프로젝트 저장
project.save" > create_project.rb
프로젝트 생성 스크립트를 실행해 프로젝트를 생성합니다.
ruby create_project.rb
react-native를 설치할 package.json을 만듭니다.
{
  "name": "react-native-prebuild",
  "version": "0.0.1",
  "private": true,
  "dependencies": {
    "react": "18.3.1",
    "react-native": "0.76.0", 
    "yarn": "^1.22.2"
  }
}
yarn 등으로 설치합니다. 
yarn 이 없는 경우 
npm install --global yarn.
yarn 으로 빌드
yarn
pod init을 수행합니다.
pod init
podfile을 다음과 같이 수정합니다. 
source 'https://cdn.cocoapods.org/'
platform :ios, '18.0'

# prepare_react_native_project 를 호출하기 위함.
require_relative './node_modules/react-native/scripts/react_native_pods'

inhibit_all_warnings!
prepare_react_native_project!

target 'ReactNativePrebuild' do
  use_frameworks! :linkage => :static

  use_react_native!(
    :path => './node_modules/react-native',
    :app_path => "#{Pod::Config.instance.installation_root}/"
  )

end

post_install do |installer|
  # For ReactNative
  react_native_post_install(
      installer,
      './node_modules/react-native',
      :mac_catalyst_enabled => false
    )

end
pod install로 pod을 설치합니다. 
pod install
React Native 라이브러리들을  XCFramework 로 빌드 하는 스크립트를 작성합니다. 
touch build_xcframeworks.sh
chmod +x build_xcframeworks.sh
빌드 스크립트의 내용은 다음과 같습니다. 
라이브러리를 simulator 용으로 archive 합니다.
라이브러리를 device 용으로 archive 합니다.
라이브러리들의 framework들을 뽑아 XCFramework로 만듭니다.
#!/bin/bash

set -euo pipefail

export SRCROOT=$(pwd)
export WORKSPACE=ReactNativePrebuild
export PROJECT="Pods-$WORKSPACE"

function archive() {
  xcodebuild archive \
    -workspace $WORKSPACE.xcworkspace \
    -scheme $PROJECT \
    -archivePath $SRCROOT/$PROJECT-iphonesimulator.xcarchive \
    -configuration $1 \
    -sdk iphonesimulator \
    -quiet \
    SKIP_INSTALL=NO
  xcodebuild archive \
    -workspace $WORKSPACE.xcworkspace \
    -scheme $PROJECT \
    -archivePath $SRCROOT/$PROJECT-iphoneos.xcarchive \
    -configuration $1 \
    -sdk iphoneos \
    -quiet \
    SKIP_INSTALL=NO
}

function create_xcframework() {
    for framework in $(find $SRCROOT/$PROJECT-iphonesimulator.xcarchive/Products/Library/Frameworks -type d -name "*.framework");
    do
        basename=$(basename $framework)
        framework_name=$(basename $framework .framework)

        xcodebuild -create-xcframework \
            -framework "$SRCROOT/$PROJECT-iphonesimulator.xcarchive/Products/Library/Frameworks/$basename" \
            -framework "$SRCROOT/$PROJECT-iphoneos.xcarchive/Products/Library/Frameworks/$basename" \
            -output "$SRCROOT/Frameworks/$framework_name.xcframework"
    done

    copyCommonFramworks
}

function copyCommonFramworks() {
  cp -R $SRCROOT/Pods/hermes-engine/destroot/Library/Frameworks/universal/hermes.xcframework $SRCROOT/Frameworks/hermes.xcframework
}

function clean() {
    rm -rf $SRCROOT/$PROJECT-iphoneos.xcarchive
    rm -rf $SRCROOT/$PROJECT-iphonesimulator.xcarchive
    rm -rf Pods
    rm -rf node_modules
}

function build_and_create_frameworks() {
    local configuration="Release"
    rm -rf build
    yarn
    pod install
    archive $configuration
    create_xcframework
    clean
}

function initDirectory() {
    rm -rf $SRCROOT/Frameworks
    rm -rf $SRCROOT/Sources
    mkdir $SRCROOT/Frameworks
    mkdir Sources
    touch Sources/dummy.swift
}

initDirectory
build_and_create_frameworks 
ruby ./generate_package_swift.rb
package.swift 를 생성하는 스크립트 파일 generate_package_swift.rb 를 만듭니다.
touch generate_package_swift.rb
frameworks_dir = 'Frameworks'

frameworks = Dir.entries(frameworks_dir).select { |entry| entry.end_with?('.xcframework') }

framework_names = frameworks.map { |f| File.basename(f, '.xcframework') }

package_swift_content = <<~SWIFT
  // swift-tools-version:5.6
  import PackageDescription

  let package = Package(
      name: "PrebuiltReactNativeFrameworks",
      platforms: [
          .iOS(.v11)
      ],
      products: [
          .library(
              name: "PrebuiltReactNativeFrameworks",
              targets: ["PrebuiltReactNativeFrameworks"]
          )
      ],
      targets: [
          // 메인 타겟: 모든 프레임워크를 포함
          .target(
              name: "PrebuiltReactNativeFrameworks",
              dependencies: [
SWIFT

framework_names.each_with_index do |name, index|
  comma = index < framework_names.size - 1 ? ',' : ''
  package_swift_content << "                  \"#{name}\"#{comma}\n"
end

package_swift_content << <<~SWIFT
              ],
              path: "Sources/",
              sources: ["dummy.swift"],
              linkerSettings: [
                  .linkedLibrary("objc"),
                  .linkedLibrary("c++"),
                  .linkedLibrary("c++abi"),
                  .linkedFramework("JavaScriptCore", .when(platforms: [.iOS])),
              ]
          ),
SWIFT

framework_names.each_with_index do |name, index|
  comma = index < framework_names.size - 1 ? ',' : ''
  package_swift_content << <<~SWIFT
          .binaryTarget(
              name: "#{name}",
              path: "Frameworks/#{name}.xcframework"
          )#{comma}
  SWIFT
end

package_swift_content << <<~SWIFT
      ]
  )
SWIFT

File.open('Package.swift', 'w') do |file|
  file.write(package_swift_content)
end

puts "Package.swift 파일이 성공적으로 생성되었습니다."

build_xcframeworks.sh 스크립트를 를 수행하여 XCFramework들과 package.swift를 생성합니다.swift build 명령어로 완성된 package.swift가 잘 생성되었는지 확인해보면 좋습니다. 
완성된 Swift Package를 운영중인 프로젝트에 추가합니다.

React 가 import 되는것을 확인합니다. 


Prebuild의 장점
iOS 개발자에게 가장 큰 적은 빌드 시간입니다. 프로젝트의 복잡성이 증가할수록 빌드 시간도 기하급수적으로 증가합니다. 그래서 iOS 개발자에게 좋은 코드란 읽고 이해하기 좋거나 기능의 추가, 수정이 용이하는 등 아키텍처 측면에서 아름다운 것 외에도 빠르게 빌드 되는 코드라는 중요한 요소가 있습니다. 
CocoaPods를 이용해 React Native를 추가한다면 라이브러리들의 버전을 Resolve하는 시간, Fetch하는 시간이 걸리게 되고 첫 빌드 시 React Native 코드도 함께 빌드되어야 실행을 해볼 수 있습니다. 이론상 CocoaPods로 추가된 코드들은 처음 한 번만 빌드 되고 증분 빌드 시엔 다시 빌드 되지 않지만, 알 수 없는 원인으로 다시 빌드 시간이 소요되는 경우도 있습니다. 또한 Clean Build를 할 경우 명백하게 다시 빌드 시간이 소요됩니다.
만약 이 빌드 시간이 사라질 수 있다면 어떨까요? 예를 들어 1분의 시간이 절약되면, 하루 평균 checkout 횟수 * 개발자 수 의 시간이 매일 절약됩니다. 평균 checkout 횟수가 5회이고 개발자가 10명일 경우 하루에 50분의 시간이 절약되고, 한 달이면 1000분으로 16시간이 절약됩니다. 하지만 1분에서 멈추지 않고, 2분이 줄어들고 개발자가 20명이면 한 달에 4000분, 즉 66시간이 절약되게 됩니다. 

맺음말
이상 의존성 관리 도구를 하나만 사용해야 하는 이유, CocoaPods를 사용하지 않고 React Native를 iOS 환경에서 이용하는 방법, Prebuild를 사용하였을 때의 장점에 대해서 알아보았습니다. 이 방법을 사용하여 여러분도 의존성 관리 도구를 여러 개 사용하지 않고, 더 빠르게 빌드할 수 있길 바랍니다. 


프로젝트에 React Native를 도입할 때 크게 두 가지 방식이 있습니다.
프로젝트를 처음부터 React Native 로 개발한다.
현재 프로젝트에 부분적으로 React Native 를 도입한다.
베트남의 토스앱을 개발하던 때는 운영되는 서비스를 잠시 멈추고 React Native로 새로 개발했었습니다. 그 시점에 앱

토스와 비슷하게 많은 회사들이 각자 다른 이유로 운영 중인 서비스를 크로스 플랫폼으로 확장하고자 React Native를 도입하려고 할 거예요. 이런 경우에 CocoaPods를 사용하지 않고 React Native를 도입하는 방법을 알려드릴게요.

CocoaPods 없이 React Native 개발하기

웹과 유사한 개발 경험을 제공하는 React Native, 디버깅 경험은 과연 어떨까요? 토스에서 자체 디버깅 도구를 만들어 생산성을 끌어올리게 된 과정을 소개합니다.

잃어버린 생산성을 찾아서, React Native로 알아보는 디버깅

Simplicity는 더 나은 사용자 경험을 만들기 위해, 토스가 치열하게 고민해온 과정을 나누는 디자인 컨퍼런스예요. 우리의 실험과 시도들이 사용자 경험을 고민하는 다른 디자이너들에게도 영감이 되기를 바라며 시작했어요. 
2021년부터 토스 디자인 챕터가 정기적으로 개최하고 있죠. 내용뿐 아니라 메시지를 어떻게 전달할지도 늘 중요하게 여겼기 때문에, 2023년부터는 유튜브 영상이 아닌 웹 기반 인터랙티브 사이트로 전환해 운영하고 있어요.

지속 가능한 컨퍼런스 만들기
디자인 챕터에게 심플리시티는 거의 종합 예술에 가까운 프로젝트예요. 운영, 디자인, 개발, 대본, 촬영, 녹음, 홍보까지—모든 과정이 고도화된 협업으로 이루어지죠.
한 번으로 끝나는 행사가 아니라, 매년 반복되는 시즌제 컨퍼런스이기 때문에 ‘지속 가능성’이 정말 중요한 주제였어요. 매년 퀄리티와 지속 가능성 사이의 균형을 고민해야 했죠. 그 과정에서 많은 부분을 효율적으로 만들어왔지만, 촬영만큼은 늘 어려운 과제였어요.
촬영을 하려면 대본이 완성되어야 하는데, 그 과정만 무려 두 달이 넘게 걸려요. 내부 피드백, 법무·보안·개인정보 검토를 거치며 수차례 수정되고, 최종적으로는 발표자 톤에 맞춰 구어체로 다시 다듬어야 하거든요. 대본이 늦어지면 촬영도 늦어지고, 전체 일정이 밀리기도 하죠.
그런데 이게 끝이 아니에요. 혹여라도 대본상의 문제를 나중에 발견하게 되면, 다시 촬영을 해야 해야 하거든요. 촬영은 디자인 챕터의 전문 영역이 아니라 항상 외부 전문가나 다른 팀의 도움을 받아야 하는 구조적 제약도 있었죠. 



더 큰 문제는, 발표 경험이 익숙하지 않은 연사들에게도 부담이 컸다는 거예요. 실제로 워크숍에서 연사자들이 가장 꺼리는 일로 “발표하기, 촬영하기, 녹음하기”를 꼽았을 정도였죠. 컨퍼런스인데, 발표가 가장 하기 싫다니—아이러니하죠?
그래서 자연스럽게 이런 질문이 생겼어요
지속가능한 컨퍼런스를 만들기 위해서는, 
촬영 프로세스부터 바꿔야 하지 않을까?



AI 아바타가 발표한다면
그래서 이번 시즌에는 새로운 방식을 시도했어요. AI 아바타가 발표를 대신해보는 실험이었죠. 혹시 눈치채신 분 계실까요?
간단할 거라고 생각했지만, 막상 해보니 쉽지만은 않았어요. AI 서비스들의 한국어 지원이 매끄럽지 않아서, 자연스러운 음성을 만들기가 어려웠거든요. 그래서 여러 번 테스트를 거쳐, 최적의 방법을 찾아냈어요.

연사자의 음성을 녹음한 뒤, ElevenLabs에서 대본 기반으로 AI 발표 음성을 생성
연사자가 말하는 영상을 촬영해 Heygen에서 AI 아바타를 생성
1번에서 만든 음성을 Heygen에 입력해, AI 아바타가 발표하는 최종 영상으로 출력



기존의 방식이라면 연사자는 발표 내용을 자연스럽게 말하기 위해 여러 번 연습하고, 촬영 중간에 한 번이라도 말을 더듬거나 버벅이면 처음부터 다시 찍어야 했어요. 하지만 이번에는 딱 한 번만 찍어도 AI 아바타를 만드는 데 충분했어요.
촬영 자체도 훨씬 간편해졌어요. AI 아바타 생성을 위한 학습용 데이터로만 쓰이다 보니, 연사자가 회의실에 들어와서 나갈 때까지 30분이면 촬영이 끝났거든요.
덕분에 연사자의 부담은 확 줄었고, 일정도 유연하게 조율할 수 있었어요. 심지어 오픈을 일주일 앞두고도 대본 수정이 가능한 정도였죠.
촬영은 어떻게 했냐고요? 아마 들으면 깜짝 놀라실 거예요. 스튜디오도, 전문 장비도 없었어요. 회의실에서, 아이폰 전면 카메라로, 스노우 앱을 켜고 녹화했거든요. 말 그대로 셀카 찍듯 촬영했죠.
처음에는 전문 장비를 갖춰서 촬영해보기도 했지만, 오히려 익숙하지 않아 결과물이 더 어색하더라고요. 그래서 여러 번 시도해 본 끝에, 지금의 제약 안에서도 원하는 결과를 만들 수 있는 가장 효율적인 방식을 찾아냈어요. 



물론 지금 저희가 만든 AI 아바타가 실제 사람에 비해 어색한 부분도 있지만, 기술이 워낙 빠르게 발전하고 있어서 앞으로 훨씬 더 자연스럽게 될 것 같아요. 그리고 이 방식보다 더 효율적인 방법이 많이 생겨나겠죠.



시청 경험까지 새롭게
이번 시즌에서는 AI 아바타 외에도 시청 경험 자체를 더 나아지게 만들기 위한 변화들이 있었어요.
1. 모바일 최적화
2023년에는 데스크탑으로 시청하는 사용자가 많았지만, 2024년에는 모바일 사용자 비율이 크게 늘었어요.
데스크탑 환경이 아닌 숏폼 형식으로 콘텐츠를 소비하는 게 적합한 것 같았죠. 그래서 이번엔 처음부터 모바일 중심으로 화면과 인터페이스를 설계했어요. “숏츠 보는 것 같았다”고 느꼈다면, 저희가 의도한 바를 정확히 느끼신 거예요. 실제로 데스크탑 디자인은 모바일 디자인을 완성한 이후에 제작되었어요.




2. 콘텐츠 길이 최적화
지난 시즌 평균 시청 시간이 3분 정도였어요. 그래서 이번에는 세션이 너무 길지 않도록 모두 5분 이하로 구성했어요. 짧지만 명확한 메시지를 전하기 위해 이미지 자료나 구성도 더욱 정교하게 다듬었죠. 그래서일까요? 지난 시즌에는 평균 완독률이 12% 정도였는데, 이번에는 51%를 넘었어요.


3. 세션별 특색 강화
커버 이미지, 배경 음악, 메인 컬러까지—각 세션마다 모두 다르게 설정했어요. 음악만 듣거나 커버만 봐도 어떤 세션인지 연상할 수 있도록, 개성과 몰입감을 중요하게 생각했어요.


앞으로의 심플리시티
이번 시즌을 계기로, Simplicity는 단순 온라인 컨퍼런스가 아니라 콘텐츠 플랫폼으로써 더 효율적이고 지속 가능한 형태로 진화했어요.  기존처럼 시즌마다 새로운 사이트를 만드는 방식에서 벗어나, 앞으로는 https://toss.im/simplicity/ 에 시즌별로 콘텐츠가 업데이트될 예정이에요. 
그리고 이 변화는 이번 시즌 4의 주인공이기도 UX플랫폼 조직의 노력으로 만들어졌어요. 
그래픽 디자이너, 인터랙션 디자이너, 플랫폼 디자이너, UX 엔지니어, UX라이터 등 UX 플랫폼 조직의 많은 팀의 협업이 있었기에 가능한 일이었죠. 곧 각 팀의 시선에서 바라본 Simplicity 제작 비하인드도 소개해드릴게요.
이번 저희의 실험을, 부디 재미있게 지켜봐주세요!

심플리시티 시즌 4 보러가기 >



Simplicity는 더 나은 사용자 경험을 만들기 위해, 토스가 치열하게 고민해온 과정을 나누는 디자인 컨퍼런스예요. 우리의 실험과 시도들이 사용자 경험을 고민하는 다른 디자이너들에게도 영감이 되기를 바라며 시작했어요. 
2021년부터 토스 디자인 챕터가 정기적으로 개최하고 있죠. 내용뿐 아니라 메시지를 어떻게 전달할지

알고 보면 더 재미있어요. 심플리시티 시즌 4의 흥미로운 제작기를 소개합니다.

Simplicity 4 : AI 아바타가 발표하는 온라인 컨퍼런스 제작기

토스 디자인 컨퍼런스 네 번째 이야기, Simplicity 4


일하면서 한 번쯤, 이상을 꿈꿔본 적이 있나요? 
빠른 문제해결이 중요한 토스에서도, 그 너머의 이상을 그리는 사람들이 있어요. 디자이너, 리서처, 라이터, 엔지니어링 등 다양한 분야에서 정교하고 아름다운 UX를 실현하기 위해 새로운 시도를 이어가고 있죠.하지만 현실은 쉽지만은 않아요. 
이번 시즌에서는, 일하는 누구나 꿈꿔본 이상을 현실로 만들기 위해 고군분투한 토스팀의 여정을 들려드려요. 우리는 어떤 고민을 했고, 어떻게 답을 찾았을까요? 
그래픽, 인터랙션, 엔지니어링, UX 라이팅, 리서치, 플랫폼 디자인까지, 총 14개의 이야기가 준비되어 있어요. 잠깐 들여다보실래요?




토스다움을 완성하는 순간들

이토록 아름다운 새로고침 
Graphic Design
화면을 아래로 당기면 나오는 그래픽, Pull To Refresh. 그 짧은 찰나에 아름다움을 담기 위한 고민을 들려드려요.

인터랙션으로 첫인상 만들기 
Interaction Design 
토스를 처음 써보는 외국인에게 토스를 어떻게 소개해야 할까? 모두가 감탄한 온보딩, 그 중심에는 인터랙션이 있었어요.

토스 그래픽 더 토스답게 만들기 
Graphic Design
IT 업계에 3D 그래픽이 넘쳐나는 시대. 토스는 어떻게 '토스다움'을 만들어냈을까요? 그 여정을 보여드려요.

디자인 조직의 개발자들 
Android, FE, iOS 
인터랙션 개발의 매력은 무엇일까요? 아름다움과 감각을 설계하는 세 명의 인터랙션 개발자가 답해드릴게요.




진짜 ‘모두’를 위한 유니버셜 UX

진짜 모두를 위한 금융 
Universal Design
2,800만 명이 쓰는 앱에서 7,000명의 스크린 리더 사용자 경험까지 챙기기 위해, 토스는 어떤 노력을 하고 있을까요?

우리가 몰랐던 시각 장애인의 UX 
UX Research
시각 장애인이 토스를 더 쉽게 쓰려면, 무엇이 달라져야 할까요? 리서치를 통해 얻은 세 가지 인사이트를 공유할게요.




토스가 사용자 경험과 마주하는 법

경험을 수치화하는 방법 
UX Research
사용자가 원하는 기능을 잘 찾는지, 정성적인 경험도 이제 수치로 말할 수 있어요. 토스만의 새로운 기준으로요.

모두가 유저를 만나는 순간까지 
UX Research
일하느라 사용자를 만날 시간이 없다면, 점심시간은 어떨까요? 식사하며 사용자의 목소리를 듣는 토스 팀의 이야기를 들려드릴게요.




UX가 AI를 만났을 때

AI시대에 라이터로 살아남기 
UX Writing
AI는 UX라이터에게 위기이자 기회예요.
다크패턴을 계기로, 라이터에서 프롬프트 엔지니어로 성장한 이야기를 들려드려요.

AI봇을 만들면서 배운 3가지 
UX Research
사용자를 만나기 전에 가볍게 의견을 물어볼 수 있는 AI UT봇. ‘휴리봇’ 을 만들면서 배운 3가지들 알려드릴게요.

토스 그래픽을 10초 만에 그리는 AI 
Graphic Design
‘토스트’를 소개합니다. 인간이 3일 걸려 만드는 3D 그래픽을 10초 만에 만든다니, 퀄리티까지 따라올 수 있을까요? 




익숙함 너머, 본질을 보다

동의 화면도 간결해질 수 있을까 
Interaction Design 
각종 법적 제한 때문에 자유롭지 않은 동의 화면 디자인. 관성을 깨면 얼마나 달라질 수 있을까요?

토스가 디자인툴을 만든 이유 
UX Engineering 
스케치, 피그마, 프레이머… 모두 써봤지만 우리에게 딱 맞는 건 없었어요. 그래서 만들었습니다. 토스만의 디자인 툴, 데우스.

아무도 쓰지 않는 디자인 시스템 
Platform Design
새로운 컴포넌트를 배포했는데, 왜 아무도 안 쓰지? 컴포넌트를 넘어서, 일하는 방식 자체를 바꿔보기로 했어요.


Vision Driven Design
Simplicity 4는 거창한 해답보다는, 현실 속에서도 이상을 놓지 않으려 한 태도에 대해 이야기 하려고 해요. "정말 이런 게 가능할까?" 싶은 순간에도 끝까지 답을 찾으려고 한 사람들의 이야기. 그리고 그 집요함이 만들어낸 변화를 들려드리고 싶었어요. 토스는 어떻게 상상 속에만 있던 UX를 현실로 만들어냈는지, 그 과정을 함께 즐겨주세요. 

Simplicity 알림 신청하기 >> 

여러분이 가장 기대되는 세션은 무엇인가요? 댓글로 남겨주세요 !


토스 디자인 컨퍼런스 네 번째 이야기, Simplicity 4


일하면서 한 번쯤, 이상을 꿈꿔본 적이 있나요? 
빠른 문제해결이 중요한 토스에서도, 그 너머의 이상을 그리는 사람들이 있어요. 디자이너, 리서처, 라이터, 엔지니어링 등 다양한 분야에서 정교하고 아름다운 UX를 실현하기 위해 새로운 시도를 이어가고 있죠.

토스 디자인 컨퍼런스 Simplicity가 돌아왔어요.

Simplicity 4 : 한 번쯤 이상을 꿈꿔본 모두에게

안녕하세요, 토스 Ads Performance 팀 ML Engineer 김영호입니다.
토스앱 진입 시 확인하실 수 있는 다양한 광고들은 어떤 과정을 거쳐 유저에게 노출될까요? 이 글에서는 토스 광고 추천 시스템의 전체 흐름과 그 안의 머신러닝 활용 방식을 소개해 드리겠습니다.

웹사이트나 앱에서 볼 수 있는 대부분의 광고는 실시간 입찰 방식을 통해 노출됩니다. 매체에서 광고 지면에 노출 기회가 발생하면 해당 정보를 광고주에게 전달하고, 광고주는 기회에 대한 가치를 평가해 자신이 지불할 금액을 산정하여 입찰에 참여하죠. 제출된 입찰가 중 가장 높은 금액을 제시한 광고주의 광고가 최종적으로 해당 지면에 노출됩니다.

실시간 입찰에는 여러 광고 플랫폼이 관여하는데요, 대표적으로 SSP(Supply-Side Platform)와 DSP(Demand-Side Platform)가 있습니다. 이 둘은 실시간 입찰 과정에서 유기적으로 연동되어 매체에 안정적인 수익을, 광고주에는 효율적인 광고 집행 및 성과 최적화를 제공합니다.
SSP: 매체가 보유한 지면을 효율적으로 관리・판매하도록 돕는 플랫폼입니다. 광고 노출 기회마다 자동으로 여러 DSP를 연결하여 최적의 입찰을 유도함으로써 매체 수익을 극대화합니다. 
DSP: 광고주를 대신해 실시간 입찰에 참여하며, 설정된 예산과 목표에 따라 최소 비용으로 최대 광고 성과를 달성하도록 돕는 플랫폼입니다.
토스는 리스트・모먼트 배너 등 다양한 광고 지면을 보유한 매체이자, 토스애즈 플랫폼을 통해 광고주가 토스 앱 내에서 손쉽게 광고를 집행하고 최적화할 수 있는 환경을 제공합니다. 따라서 광고 요청부터 노출까지의 모든 과정이 토스 내에서 이루어지죠.

유저 접속부터 광고 노출까지
유저가 광고 지면이 있는 토스 앱 화면에 접속하면 광고 요청이 발생하고, 입찰을 통해 최적의 광고가 선정되어 노출됩니다. 이 과정은 크게 Targeting, Filtering, Ranking의 세 단계로 이루어지며, 각 단계에서 머신러닝이 활용돼요.

1. Targeting
유저 정보를 기반으로 노출할 광고를 선별하는 과정이에요. 광고주마다 캠페인 목표와 원하는 타겟 유저가 다르기 때문에, 광고 노출 대상인 유저가 설정된 타겟에 포함되는지 확인합니다. 포함되지 않을 경우 해당 광고는 제외돼요.
성별, 연령대, 직업 등의 특성을 바탕으로 유저를 세분화하여 광고를 집행하는 전략을 오디언스 타겟팅(Audience Targeting)이라고 합니다. 광고주는 인구통계학적 정보만으로도 타겟팅 그룹을 만들 수 있지만, 많은 광고주들은 자신의 상품을 구매한 유저와 유사한 특성을 지닌 잠재 고객을 타겟팅하고 싶어하죠.
이러한 니즈를 충족시키기 위해 Lookalike 모델을 활용해 광고주가 타겟으로 설정한 오디언스와 행동 패턴이 유사한 잠재 고객을 찾습니다. 유저의 행동 로그를 학습하거나 Two-tower 모델을 통해 유저와 광고 간의 상호작용을 학습하여 유저 임베딩을 생성하고, 주어진 오디언스와의 임베딩 유사도를 계산해 잠재 고객을 선별해요.


2. Filtering
이 단계에서는 유저에게 제공할 광고 후보를 선별하고, 광고주의 예산 및 광고 품질을 고려한 필터링 과정을 수행합니다.
광고 후보군 선정(Candidate Selection): 유저를 타겟팅하는 수십만~수백만 개의 광고 중에서 사용자가 관심을 가질 만한 광고를 빠르게 선택해야 해요. 모든 광고를 실시간으로 개별 평가하면 지연 시간이 늘고 연산 비용이 크게 증가하므로, 유저의 관심사를 기반으로 광고 후보군을 선별합니다. 이 과정에서는 정확성도 중요하지만 대규모 광고 풀에서 알맞은 후보군을 빠르게 추출하는 것이 중요한데요. 이 단계에서는 주로 Two-tower 모델을 활용해 유저와 광고에 대한 임베딩을 생성하고, 유사도 검색을 통해 관련 광고를 빠르게 탐색합니다.
예산 소진 조절(Pacing): 광고주가 설정한 캠페인 예산을 기간 내에 균등하고 안정적으로 소진하도록 광고 노출 및 입찰을 제어합니다. 과거 입찰 로그를 바탕으로 시간대・요일 등 컨텍스트에 따른 트래픽을 예측하고, 이를 바탕으로 사용 가능한 예산을 산정하고 실시간으로 소진 속도를 조절해요.
노출 빈도 제한(Frequency Capping): 동일한 광고가 한 유저에게 일정 기간 내에 노출될 최대 횟수를 설정하여 광고 피로도를 줄입니다. 하루 최대 3회와 같이 고정 캡을 설정할 수 있지만, 유저의 행동 패턴에 따른 최적 빈도를 예측해 적용할 수 있어요.

3. Ranking
이전 단계에서 선별된 후보 광고의 입찰가를 산출해 노출될 광고를 결정합니다. 입찰가는 매체의 기대 수익을 의미하는 eCPM(effective Cost Per Mille, 1,000회 노출당 비용)으로 표현하며, 이 값을 기준으로 광고 순위를 매겨요. eCPM은 광고주가 클릭당 지불하는 비용(CPC, Cost Per Click)과 광고의 클릭률(CTR, Click-Through Rate)을 기반으로 계산합니다.
eCPM(1,000회 노출당 비용) = CPC(클릭당 지불 비용) * CTR(클릭률) * 1,000
이때 실제 CTR은 광고가 실제로 노출된 후에야 알 수 있기 때문에, 노출 전 단계에서는 유저, 광고, 컨텍스트 정보를 기반으로 CTR을 예측하여 사용합니다. CTR 예측 모델은 광고 ID, 유저 속성 등 고차원의 희소 특징(Sparse Feature) 간의 상호작용을 효과적으로 학습해야 하기 때문에, 주로 FM(Factorization Machine), DeepFM, DCN(Deep & Cross Network) 구조를 사용해요. 
또한, 광고주는 각 노출 기회마다 전환율(CVR, Conversion Rate)을 예측해 입찰가를 조절할 수 있습니다. 전환율이 낮다고 예상되는 상황에서는 클릭당 비용을 낮춰 불필요한 지출을 최소화하고, 전환율이 높다고 예상될 때 클릭당 비용을 높여 경쟁 우위를 차지할 수 있어요. 

결론
앞서 살펴본 광고 노출 과정 이외에도 머신러닝은 광고 운영 전반에서 다양하게 활용될 수 있습니다.
동적 입찰가 조절: 광고주가 설정한 클릭당 비용은 고정된 값이기 때문에 실시간으로 변화하는 경쟁 상황에 빠르게 대응하지 못해요. 이를 보완하기 위해 DQN(Deep Q-Network)와 같은 강화학습 모델을 사용하여 광고 운영 현황에 따라 클릭당 비용을 동적으로 조절함으로써 광고 효율 저하를 방지합니다.
광고 소재 최적화: 사용자에게 노출되는 광고 소재의 성과를 향상시키기 위해 생성형 AI를 활용하여 다양한 소재를 자동 생성・테스트하고 최적의 소재를 찾습니다.

토스애즈는 광고 플랫폼의 기반을 만들어가는 단계로, 광고 시스템 전반에 필요한 머신러닝 모델을 초기부터 설계하고 고도화할 수 있어요. 광고는 머신러닝 모델의 작은 변화가 바로 비즈니스 성과로 이어지는 분야입니다. 다양한 실험을 통해 머신러닝 모델로 비즈니스 성과를 만들어가고 싶으신 분들의 많은 지원을 기다립니다.


안녕하세요, 토스 Ads Performance 팀 ML Engineer 김영호입니다.
토스앱 진입 시 확인하실 수 있는 다양한 광고들은 어떤 과정을 거쳐 유저에게 노출될까요? 이 글에서는 토스 광고 추천 시스템의 전체 흐름과 그 안의 머신러닝 활용 방식을 소개해 드리겠습니다.

웹사이트나 앱에서 볼 수 있는 대부분의 광고