프로젝트에 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로 알아보는 디버깅


모닥불 10화 특집: 캠프파이어 에피소드 🔥
이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요.
"폴더 구조를 설계할 때 꼭 지켜야 할 원칙은?"
"컴포넌트 추상화, 어디까지 해야 더 효율적일까요?
"함수형 프로그래밍은 언제, 왜 사용하는 게 좋을까요?"
사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지!
토스 개발자들이 실무 경험에서 얻은 노하우와 인사이트를 아낌없이 공유합니다!  지금 바로 확인해보세요!

타임스탬프
00:00 인트로
01:20 첫 번째 사연: 폴더 구조는 어떻게 정리해야 협업이 쉬울까요?
06:39 두 번째 질문: 컴포넌트를 어떻게 분리하고, 추상화는 어디까지 해야 할까요?
11:20 변경 사항을 예측해 추상화 하는데 어려움을 겪고 있다면
15:24 세 번째 질문: 유효성 검사는 에러로 보는 것이 맞을까요?
19:57 네 번째 질문: 함수형 프로그래밍이 꼭 필요한가요?

출연진
박서진, 토스 Head of Frontend
문동욱, 토스 Frontend Developer
박건영, 토스증권 Frontend Developer

Frontend Fundamentals ; 변경하기 쉬운 프론트엔드 코드를 위한 지침서
바로가기: https://frontend-fundamentals.com

다른 모닥불 회차 보러가기
EP.7 개발자 리더로서 성장당한 썰
EP.8 Next.js 그만 쓰세요! 면접관이 진짜 원하는 것!?
EP.9 프론트엔드 서비스 최적화? 토스에서는 '이렇게' 합니다!




모닥불 10화 특집: 캠프파이어 에피소드 🔥
이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요.
"폴더 구조를 설계할 때 꼭 지켜야 할 원칙은?"
"컴포넌트 추상화, 어디까지 해야 더 효율적일까요?
"함수형 프로그래밍은 언제, 왜 사용하는 게 좋을까요?"
사전에 접수된 시청자 여러분의 다양한 사연과 질문

모닥불 10화 특집: 캠프파이어 에피소드 🔥

이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요.

사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지!

지금 바로 확인해보세요!

무엇이든 물어보세요 (feat. 프론트엔드 코드, 디렉토리 관리) | EP.10 캠프파이어 특집 상편


디자이너로서 커리어를 시작할 때, 특히 경력이 부족하다면 고민이 많을 수밖에 없죠. “내가 과연 준비가 됐을까?”, “경험도 없는데 이런 회사에 도전해도 될까?” 같은 걱정이 앞서기 마련인데요. 그런 고민 속에서 도전했던 두 디자이너 세린님과 수빈님의 이야기를 들어봤어요.
두 분이 경험한 토스 인턴십은 단순히 보조 업무나 과제 중심의 경험이 아니라, 1인 디자이너로서 제품을 주도적으로 맡을 수 있었던 기회였다고 해요. 4개월이라는 시간 동안 압축적으로 성장하며 과거의 자신을 뛰어넘을 수 있었던 그 이야기, 지금 시작할게요.



Q. 토스 인턴십에는 어떤 분들이 지원하시는지 궁금해요. 두 분은 지원 당시 어떤 상황이셨나요?
세린 : UX 디자인에 흥미를 느껴 공부하던 학생이었어요. 하지만 제 실력으로는 디자이너로 시작하기에 부족하다고 느껴서 고민이 많았죠. 그러다 토스 PD 인턴십 공고를 보고 ‘이건 꼭 도전해야 한다’는 생각이 들었어요. 토스는 제가 꼭 경험해보고 싶었던 회사였거든요. 아직 졸업 전이었지만, 지금 아니면 안 될 것 같다는 마음으로 지원했어요.
수빈 : 저는 원래 산업디자인을 전공했어요. 코로나 이후 제 적성을 고민하다 UX 디자인으로 눈을 돌리게 됐죠. 다른 회사에서 프로덕트 디자이너로 인턴을 하긴 했지만, 주도적으로 문제를 해결하는 경험이 부족하다는 아쉬움이 남았어요. 그래서 더 적극적으로 일할 수 있는 환경을 찾아보다 토스에 지원하게 됐어요.



Q. 경력이 많지 않았던 만큼 걱정도 많으셨을 것 같아요. 어떤 점이 가장 고민이었나요?
세린 : 걱정이 많았죠. UX 실무 경험은 없었고 PM 인턴 경험만 있었거든요. 하지만 입사 전형을 겪으며 토스가 “경력보다 잠재력을 본다”는 걸 느꼈어요. 얼마나 많은 디자인을 해봤는지가 아니라, 문제를 해결하려는 태도와 제품을 바라보는 관점이 훨씬 중요했어요. “경력이 없다면 우리가 만들어 줄게!”라는 느낌이 강했달까요.
수빈 : 저도 비슷했어요. 포트폴리오도 완벽하지 않았고, UI 디자인 경험도 부족했거든요. ‘내가 이 정도로 가능할까?’라는 생각이 들었지만, 면접 과정에서 제게 필요한 질문들을 많이 받으면서 생각이 바뀌었어요. ‘왜 이런 디자인을 선택했는지’, ‘이 문제를 어떻게 풀려고 했는지’를 묻는 질문들 덕분에 제 사고 과정을 돌아볼 수 있었고, 자신감도 얻었어요.
또 저의 경험과 태도를 보여주는 것에 집중했어요. 예를 들어, 제가 사이드 프로젝트를 할 때 발로 뛰며 사용자 인터뷰를 했던 경험이나, 꽃 사진 촬영을 위해 꽃을 직접 사고 팝업으로 판매까지 했던 이야기들을 담았어요.결국, 토스가 원하는 건 현재 스킬보다도 그런 적극적인 태도와 문제를 해결하려는 자세가 아니었을까 싶어요.


Q. 실제로 토스에서 인턴십을 하며 어떤 경험을 하셨나요?
세린 : 대부분의 인턴십은 보조 업무 위주로 진행된다는 인식이 있잖아요. 그런데 토스는 달랐어요. 사일로에 소속된 1인 디자이너로서 제품의 모든 과정을 주도적으로 맡을 수 있었어요. 제가 제안한 디자인이 실제로 제품에 반영되고, 유저 반응을 확인하는 경험은 정말 짜릿했죠. 인턴이라기보다는 정규직처럼 일했던 것 같아요.
수빈 : 저도 가장 놀랐던 점이 인턴에게도 제품 전 과정을 맡긴다는 점이었어요. 데이터 분석가, 개발자, 기획자와 협업하면서 문제를 정의하고 해결책을 제시하는 과정이 정말 재미있었어요. 4개월 동안 수십개의 제품을 디자인하고 결과를 빠르게 확인하며 성장할 수 있었어요. 다른 곳에서는 얻기 힘든 경험을 한 것 같아요. 



Q. 인턴으로서 업무에만 집중하며 성장하기 쉽지 않았을 것 같은데, 어떻게 가능했나요?
세린 : 디자인 챕터와 페어 디자이너의 지원 덕분이에요. 단순히 평가만 하는 게 아니라, 정말 저를 성장시키고 싶어 한다는 진심이 느껴졌거든요. 정기적인 피드백과 방향성 제시 덕분에 고민도 덜 수 있었고요. 또 인턴들은 서로 다른 팀에 배정돼서 경쟁에 대한 스트레스 없이 온전히 자신의 성장에 집중할 수 있었던 것도 큰 도움이 됐어요. 
수빈 : 팀에서 “제품이 꼭 성공하지 않아도 괜찮다. 과정 속에서 배우는 게 더 중요하다”는 말을 자주 해주셨어요. 이 말 덕분에 평가에 대한 부담을 덜고, 제품 자체에 몰입할 수 있었죠. 메이트와 페어 디자이너도 부족한 점은 명확히 짚어주고, 잘하는 점은 확실히 인정해줬어요. 이런 지원 속에서 자신감 있게 일할 수 있었어요.



Q. 마지막으로, 토스 인턴십 지원을 망설이는 분들에게 하고 싶은 말이 있다면요?
세린 : 어차피 해야 할 과정이라면, 토스에 도전해보세요. 취업 준비를 하며 포트폴리오를 만드는 건 누구나 해야 하는 일이잖아요. 그렇다면 토스에 지원해서 면접만으로도 얻어가세요. 포트폴리오를 보완할 힌트를 많이 얻을 수 있을 거예요. 그리고 인턴십에 합격한다면, 4개월 동안 폭발적으로 성장할 수 있어요. 정규직 전환까지 되면 좋고요. 잃을 게 전혀 없는 도전이니 꼭 해보세요!
수빈 : 경력이나 포트폴리오 완성도가 부족해도 괜찮아요. 토스는 실력보다 태도와 성장 가능성을 더 중요하게 봐요. 저도 UX 디자인 경력이 전혀 없었지만, 4개월 동안 엄청난 성장을 경험했어요. 수십 개의 프로젝트를 진행하며 협업하는 방법도 자연스럽게 배웠죠. 망설이지 말고 도전해보세요. 토스에서의 4개월은 다른 회사에서의 1년 이상 가치 있는 경험이 될 거예요. 정말로요!



두 분의 이야기를 통해 토스 인턴십이 단순한 경험을 넘어, 성장의 장을 열어준다는 걸 알 수 있었어요. 경력이나 경험이 부족해도 괜찮아요. 토스는 여러분의 가능성을 믿고, 이를 현실로 만들어주는 곳이에요.이제, 여러분도 토스에서 새로운 여정을 시작해보면 어떨까요? 




Interviewee: 장세린, 강수빈
Interviewer & Editor: 장성연, 유아란






디자이너로서 커리어를 시작할 때, 특히 경력이 부족하다면 고민이 많을 수밖에 없죠. “내가 과연 준비가 됐을까?”, “경험도 없는데 이런 회사에 도전해도 될까?” 같은 걱정이 앞서기 마련인데요. 그런 고민 속에서 도전했던 두 디자이너 세린님과 수빈님의 이야기를 들어봤어요.
두 분이 경험한 토스 인턴십은 단순히 보조 업무

2023년 프로덕트 디자이너 인턴십 후기를 들려드릴게요

토스 인턴십에서 고속 성장할 수 있는 이유


미스터리 디자인 클럽은? 
사용자 경험 속 크고 작은 궁금증을 사용자 리서치, 실험 등 다양한 방법으로 탐구하는 모임이에요. '왜 이렇게 디자인해야 할까?'라는 질문을 시작으로, 관성처럼 굳어진 UX 패턴의 진실을 파헤치며 더 나은 사용자 경험을 찾아가고 있어요. 

타임머신이 있다면 어디로 가보고 싶나요?

다들 고르셨나요? 오늘 미스터리 디자인 클럽에서는 ‘선택지를 고르는 화면’ 디자인에 대해 이야기해볼게요.
“화면 디자인을 하다보면 사용자가 선택지를 고르는 화면을 많이 구성하게 되는데요. 때에 따라 단 하나만 선택되거나, 여러 개를 선택할 수 있는 경우가 있어요. 그럴 때, ‘하나만 선택되는 화면은 당연히 *라디오 버튼으로 디자인 해야하지 않나?’라는 생각이 먼저 들어요. 사용자에게 ‘디자인적 증거’를 줘야겠다는 생각이 들기 때문이에요.” - 토스 프로덕트 디자이너 A
*라디오 버튼이란?  옵션을 선택할 때 사용되는 UI 컴포넌트인데요. 라디오의 물리적 버튼에서 따와 만들어진 PC UI 문법으로, 옵션 중 하나를 선택해야 할 때 PC와 모바일 모두에서 많이 이용되고 있어요. 


A씨를 비롯한 많은 메이커들이 토스의 모바일 디자인 시스템에 라디오 버튼 컴포넌트를 추가하자는 이야기를 꺼내곤 했어요. ‘너무 일반적인 공식이기 때문에’, ‘다른 곳에서 모두 이렇게 하기 때문에’가 그 이유였어요. 
그러나, 모바일 환경에서는 이 형태가 적합하지 않은 면이 있어요. 마우스 포인터로 버튼을 편하게 클릭할 수 있는 PC 환경에는 어울리지만, 손가락 끝으로 탭해야 하는 모바일 환경에서는 작은 원을 정확히 눌러야 할 것 같은 형태가 최선이라 하기 어렵기 때문이에요. 실제로는 레이블을 눌러서 선택할 수 있다고 해도요. 


iOS에서도 원형의 라디오 버튼은 존재하지 않아요. 대신 세그먼티드 컨트롤(Segmented Controls)이라는 컴포넌트를 이용하거나, 위 이미지처럼 체크박스를 사용해 PC의 라디오 버튼과 같은 기능을 구현하고 있어요. 탭 가능한 큰 영역을 제공하고, 미니멀한 스타일을 유지하기 위해 대안을 제시한 거죠. 
이렇듯 모바일에서 최선의 형태가 아님에도 불구하고, ‘하나만 선택되는 화면은 반드시 라디오 버튼을 써야하지 않을까?’라고 많은 분들이 생각했던 거에요. 

여러분은 앞서 어떤 선택을 하셨나요? 
그리고, 다른 사용자들은 어떻게 선택했을까요? 


세 가지 유형의 질문을 준비해 UT를 진행했어요. 
유형 1️⃣: 앞서 여러분이 선택한 ‘타임머신’ 질문처럼, 서로 배타적이어서 여러 개를 선택할 수 없는 것이 있어요. 
유형 2️⃣: ‘최근 1년간 감상한 콘텐츠를 선택하라’는 것처럼, 대부분 여러 개를 선택할 만한 질문이 해당돼요. 
유형 3️⃣: 단일 혹은 중복 모두 선택할 수 있는 질문이 해당돼요. 
질문에서는 ‘모두 선택’, ‘하나만 선택’ 등 선택 개수를 안내하지 않았어요. 또한, 일반적인 공식과는 반대로, ‘하나만 선택’일 땐 체크박스, ‘중복 선택’일 땐 라디오 버튼을 주어 사용자가 어떻게 선택하는지 관찰했어요. 

미스터리 디자인의 진실  
대부분의 사용자들은 버튼의 모양과 상관 없이 질문에 따라 답을 선택했어요 (15명 중 13명) 
유형 1에서는 하나를, 유형 2에서는 여러 개를, 그리고 유형 3에서는 선택하고 싶은 만큼 선택한 건데요. 
그렇게 선택한 이유가 무엇인지 물었을 때, 질문 자체에 집중해서 대답했어요. “나는 올빼미형 인간이다”, ‘”최근 1년간 영화, 드라마, 예능을 모두 봤다” 이렇게요. 유형 2나 3에서 ‘여러 개를 선택해도 되는지’ 묻는 분들이 계셨지만, 이들 또한 “질문에서 ‘중복 선택’이라는 말이 없어 헷갈린다”고 말했어요. 버튼의 모양을 언급하며 질문해도, 이 모양으로 인해 헷갈렸다고 말한 경우는 거의 없었어요. 
물론, 모든 사용자가 라디오 버튼의 역할을 모른다는 것은 아니에요. 인터뷰의 의도를 설명하고 버튼의 모양에 대해 물었을 때, ‘설문 조사, 시험’ 등에서 본 것 같다고 답한 분들도 계셨어요. 그럼에도 불구하고, 유형 1에서는 하나를, 유형 2에서는 여러 개를 선택했고 어색하게 느끼지 않았다고 했어요. 
결론: 동그란 라디오 버튼을 쓰지 않는다고 해서, 사용자의 선택에 문제가 되지 않아요. 
사용자는 버튼의 모양이 아닌 맥락에 더 큰 영향을 받기 때문이에요. 
위 예시에서는 단 하나의 질문이 전체 맥락이 되지만, 실제 제품 내에서는 이전 화면, 라이팅, 설명글 등 훨씬 다양한 것이 사용자의 맥락이 될 수 있어요. 중요한 것은 사용자가 선택해야 할 개수를 자연스럽게 이해할 수 있도록, 최선의 UI로 친절한 맥락을 제공하는 것이에요. 실제로 토스 앱 내 화면으로 UT를 진행했을 때, 사용자는 더욱 명확하게 선택했어요. 버튼의 모양과 상관 없이 하나를 묻는 질문에서 하나를, 여러 개를 묻는 질문에서 여러 개를 선택했죠.  
모바일에서도 반드시 동그란 라디오 버튼을 써야한다고 생각했다면, 오래된 공식에 따르고 싶었던 디자이너의 관성일 수 있어요. 중요한 것은, ‘반드시 그래야 하는 것’은 사실 그렇지 않을 수 있다는 거예요. 

여러분은 어떻게 생각하시나요? 댓글로 의견을 남겨주세요. 





미스터리 디자인 클럽은? 
사용자 경험 속 크고 작은 궁금증을 사용자 리서치, 실험 등 다양한 방법으로 탐구하는 모임이에요. '왜 이렇게 디자인해야 할까?'라는 질문을 시작으로, 관성처럼 굳어진 UX 패턴의 진실을 파헤치며 더 나은 사용자 경험을 찾아가고 있어요. 

타임머신이 있다면 어디로 가보고 싶나요?

다들 고르