dynamic-ddd 님의 블로그

Tuist Plugin 만들기 + Settings 설정까지 완전 정복!

dynamic-ddd — Sun, 5 Apr 2026 13:51:01 +0900

이 글을 쓰게 된 계기

안녕하세요! iOS 운영진 서원지입니다 ㅋㅋㅋ

Tuist로 모듈화 하다 보면 이런 고민이 생겨요:

"매번 비슷한 코드 반복하기 싫은데... 템플릿화 못 하나?" "환경별로 설정 다르게 하고 싶은데 어떻게 하지?"

그래서 오늘은 Tuist Plugin 만들기랑 Settings 설정을 한 방에 정리해볼게요!

⚠️ 제가 공부하면서 정리한 내용이라 틀린 부분 있을 수 있어요! 잘못된 부분 있으면 편하게 알려주세요

Part 1: Tuist Plugin이란?

Tuist Plugin은 Tuist 환경에서만 작동하는 확장 코드예요.

이걸로 뭘 할 수 있냐면:

플러그인 유형역할

ProjectTemplatePlugin모듈 템플릿 정의 (makeAppModule, makeModule)

DependencyPlugin	내부 모듈 enum 정의 (.Shared(.DesignSystem))
DependencyPackagePlugin	외부 라이브러리 정의 (SPM 설정)

플러그인 디렉토리 구조

Plugins/
├── ProjectTemplatePlugin/
│   └── ProjectDescriptionHelpers/
│       └── TemplateHelpers.swift
├── DependencyPlugin/
│   └── ProjectDescriptionHelpers/
│       └── TargetDependency+Module.swift
└── DependencyPackagePlugin/
    ├── Package.swift
    └── ProjectDescriptionHelpers/
        └── Extension+TargetDependencySPM.swift

플러그인 이름은 자유롭게! 근데 역할별로 명확하게 나누는 게 유지보수에 좋아요.

Tuist.swift에서 플러그인 등록하기

프로젝트 루트에 Tuist.swift 파일 만들어서:

import ProjectDescription
import Foundation

let tuist = Tuist(
    project: .tuist(
        compatibleXcodeVersions: .all,
        swiftVersion: .some("6.0.0"),
        plugins: [
            .local(path: .relativeToRoot("Plugins/ProjectTemplatePlugin")),
            .local(path: .relativeToRoot("Plugins/DependencyPackagePlugin")),
            .local(path: .relativeToRoot("Plugins/DependencyPlugin")),
        ],
        generationOptions: .options(),
        installOptions: .options()
    )
)

Plugin.swift도 필요해요!

각 플러그인 폴더에 Plugin.swift 파일 필수!

// Plugins/DependencyPackagePlugin/Plugin.swift
@preconcurrency import ProjectDescription

let plugin = Plugin(name: "DependencyPackagePlugin")

이거 없으면 Tuist가 플러그인 인식 못 해요 ㅠㅠ

ModulePath로 모듈 경로 관리하기

모듈이 많아지면 경로 관리가 진짜 귀찮아요...

그래서 ModulePath enum으로 계층 구조를 명확하게!

import Foundation
import ProjectDescription

public enum ModulePath {
    case Presentations(Presentations)
    case Core(Cores)
    case Network(Networks)
    case Interface(Interfaces)
    case Domain(Domains)
    case Data(Datas)
    case Shared(Shareds)
}

각 모듈 계층 정의

// App 모듈
public extension ModulePath {
    enum App: String, CaseIterable {
        case iOS
        case iPad

        public static let name: String = "App"
    }
}

// Core 모듈
public extension ModulePath {
    enum Cores: String, CaseIterable {
        case Core

        public static let name: String = "Core"
    }
}

// Network 모듈
public extension ModulePath {
    enum Networks: String, CaseIterable {
        case API
        case Networks
        case Foundations
        case Service
        case ThirdPartys

        public static let name: String = "Network"
    }
}

// Data 모듈
public extension ModulePath {
    enum Datas: String, CaseIterable {
        case Model
        case Repository

        public static let name: String = "Data"
    }
}

// Domain 모듈
public extension ModulePath {
    enum Domains: String, CaseIterable {
        case UseCase
        case DomainInterface

        public static let name: String = "Domain"
    }
}

// Shared 모듈
public extension ModulePath {
    enum Shareds: String, CaseIterable {
        case Shareds
        case DesignSystem
        case Utill
        case ThirdParty

        public static let name: String = "Shared"
    }
}

Path 확장으로 경로 자동화

매번 이렇게 쓰기 싫잖아요?

// ❌ 이렇게 하면 오타나기 쉬움
.relativeToRoot("Projects/Shared/DesignSystem")

Path Extension 만들기!

public extension ProjectDescription.Path {
    // App
    static var app: Self {
        return .relativeToRoot("Projects/\(ModulePath.App.name)")
    }

    // Shared
    static var Shared: Self {
        return .relativeToRoot("Projects/\(ModulePath.Shareds.name)")
    }

    static func Shared(implementation module: ModulePath.Shareds) -> Self {
        return .relativeToRoot("Projects/\(ModulePath.Shareds.name)/\(module.rawValue)")
    }

    // Network
    static var Networking: Self {
        return .relativeToRoot("Projects/\(ModulePath.Cores.name)/\(ModulePath.Networks.name)")
    }

    static func Network(implementation module: ModulePath.Networks) -> Self {
        return .relativeToRoot("Projects/\(ModulePath.Cores.name)/\(ModulePath.Networks.name)/\(module.rawValue)")
    }

    // Domain
    static var Domain: Self {
        return .relativeToRoot("Projects/\(ModulePath.Cores.name)/\(ModulePath.Domains.name)")
    }

    static func Domain(implementation module: ModulePath.Domains) -> Self {
        return .relativeToRoot("Projects/\(ModulePath.Cores.name)/\(ModulePath.Domains.name)/\(module.rawValue)")
    }

    // Data
    static var Data: Self {
        return .relativeToRoot("Projects/\(ModulePath.Cores.name)/\(ModulePath.Datas.name)")
    }

    static func Data(implementation module: ModulePath.Datas) -> Self {
        return .relativeToRoot("Projects/\(ModulePath.Cores.name)/\(ModulePath.Datas.name)/\(module.rawValue)")
    }
}

TargetDependency 확장으로 의존성 간결하게!

// ❌ 이렇게 쓰면 길고 귀찮음
.project(target: "DesignSystem", path: .relativeToRoot("Projects/Shared/DesignSystem"))

// ✅ 이렇게 쓰면 깔끔!
.Shared(implements: .DesignSystem)

Extension 만들기

public extension TargetDependency {
    // Shared
    static func Shared(implements module: ModulePath.Shareds) -> Self {
        return .project(target: module.rawValue, path: .Shared(implementation: module))
    }

    // Network
    static func Network(implements module: ModulePath.Networks) -> Self {
        return .project(target: module.rawValue, path: .Network(implementation: module))
    }

    // Domain
    static func Domain(implements module: ModulePath.Domains) -> Self {
        return .project(target: module.rawValue, path: .Domain(implementation: module))
    }

    // Data
    static func Data(implements module: ModulePath.Datas) -> Self {
        return .project(target: module.rawValue, path: .Data(implementation: module))
    }

    // Core
    static func Core(implements module: ModulePath.Cores) -> Self {
        return .project(target: module.rawValue, path: .Core(implementation: module))
    }
}

사용 예시

let project = Project(
    name: "LoginFeature",
    targets: [
        .target(
            name: "LoginFeature",
            dependencies: [
                .Shared(implements: .DesignSystem),
                .Network(implements: .Service),
                .Domain(implements: .UseCase),
                .SPM.composableArchitecture
            ]
        )
    ]
)

진짜 깔끔해요!

️ Project 템플릿 함수 만들기

makeAppModule - 앱 타겟용

static func makeAppModule(
    name: String = Environment.appName,
    bundleId: String,
    platform: Platform = .iOS,
    product: Product,
    packages: [Package] = [],
    deploymentTarget: DeploymentTargets = Environment.deploymentTarget,
    destinations: Destinations = Environment.deploymentDestination,
    settings: Settings,
    scripts: [TargetScript] = [],
    dependencies: [TargetDependency] = [],
    sources: SourceFilesList = ["Sources/**"],
    resources: ResourceFileElements? = nil,
    infoPlist: InfoPlist = .default,
    entitlements: Entitlements? = nil,
    schemes: [Scheme] = []
) -> Project

생성되는 타겟:

appTarget - 기본 앱 타겟
appDevTarget - Debug 환경용
appStageTarget - Stage 환경용
appProdTarget - Prod 환경용
appTestTarget - 유닛 테스트용

makeModule - 일반 모듈용

static func makeModule(
    name: String = Environment.appName,
    bundleId: String,
    platform: Platform = .iOS,
    product: Product,
    packages: [Package] = [],
    deploymentTarget: DeploymentTargets = Environment.deploymentTarget,
    destinations: Destinations = Environment.deploymentDestination,
    settings: Settings,
    scripts: [TargetScript] = [],
    dependencies: [TargetDependency] = [],
    sources: SourceFilesList = ["Sources/**"],
    resources: ResourceFileElements? = nil,
    infoPlist: InfoPlist = .default,
    entitlements: Entitlements? = nil,
    schemes: [Scheme] = []
) -> Project

makeScheme - 스킴 템플릿

extension Scheme {
    public static func makeScheme(target: ConfigurationName, name: String) -> Scheme {
        return Scheme.scheme(
            name: name,
            shared: true,
            buildAction: .buildAction(targets: ["\(name)"]),
            testAction: .targets(
                ["\(name)Tests"],
                configuration: target,
                options: .options(coverage: true, codeCoverageTargets: ["\(name)"])
            ),
            runAction: .runAction(configuration: target),
            archiveAction: .archiveAction(configuration: target),
            profileAction: .profileAction(configuration: target),
            analyzeAction: .analyzeAction(configuration: target)
        )
    }
}

사용 예시

let project = Project.makeModule(
    name: "LoginFeature",
    bundleId: "com.myapp.login",
    product: .framework,
    settings: .settings(configurations: [...]),
    dependencies: [
        .Domain(implements: .UseCase),
        .Shared(implements: .DesignSystem)
    ],
    schemes: [
        .makeScheme(target: .debug, name: "LoginFeature")
    ]
)

Part 2: Settings 설정 완전 정복

여기서부터가 진짜 중요한 부분이에요!

환경별로 설정 다르게 하고 싶을 때 Settings.swift를 활용합니다.

commonSettings 함수

환경별로 중복되는 설정을 재사용하기 위한 유틸 함수:

private static func commonSettings(
    appName: String,
    displayName: String,
    provisioningProfile: String,
    setSkipInstall: Bool
) -> SettingsDictionary {
    return SettingsDictionary()
        .setProductName(appName)
        .setCFBundleDisplayName(displayName)
        .setOtherLdFlags("-ObjC -all_load")
        .setDebugInformationFormat("dwarf-with-dsym")
        .setProvisioningProfileSpecifier(provisioningProfile)
        .setSkipInstall(setSkipInstall)
}

설정 항목 설명

메서드설명

setProductName실행 파일 이름 (PRODUCT_NAME)

setCFBundleDisplayName	홈 화면에 표시될 앱 이름
setOtherLdFlags	Objective-C 런타임 로딩 설정
setDebugInformationFormat	.dSYM 생성 (크래시 추적용)
setProvisioningProfileSpecifier	서명에 사용할 프로파일
setSkipInstall	아카이브 대상 포함 여부

appMainSetting - 앱 전용 빌드 설정

public static let appMainSetting: Settings = .settings(
    base: SettingsDictionary()
        .setProductName(Project.Environment.appName)
        .setCFBundleDisplayName(Project.Environment.appName)
        .setMarketingVersion(.appVersion())
        .setASAuthenticationServicesEnabled()       // Apple 로그인
        .setPushNotificationsEnabled()              // 푸시 알림
        .setEnableBackgroundModes()                 // 백그라운드 모드
        .setArchs()
        .setOtherLdFlags()
        .setCurrentProjectVersion(.appBuildVersion())
        .setCodeSignIdentity()
        .setCodeSignStyle()
        .setSwiftVersion("6.0")
        .setVersioningSystem()
        .setProvisioningProfileSpecifier("match Development \(Project.Environment.bundlePrefix)")
        .setDevelopmentTeam(Project.Environment.organizationTeamId)
        .setCFBundleDevelopmentRegion()
        .setDebugInformationFormat(),

    configurations: [
        //   Debug
        .debug(
            name: .debug,
            settings: commonSettings(
                appName: Project.Environment.appName,
                displayName: Project.Environment.appName,
                provisioningProfile: "match Development \(Project.Environment.bundlePrefix)",
                setSkipInstall: false
            ),
            xcconfig: .relativeToRoot("./Config/dev.xcconfig")
        ),

        //   Stage (QA용)
        .debug(
            name: "Stage",
            settings: commonSettings(
                appName: Project.Environment.appStageName,
                displayName: Project.Environment.appName,
                provisioningProfile: "match Development \(Project.Environment.bundlePrefix)",
                setSkipInstall: false
            ),
            xcconfig: .relativeToRoot("./Config/qa.xcconfig")
        ),

        //   Release
        .release(
            name: .release,
            settings: commonSettings(
                appName: Project.Environment.appName,
                displayName: Project.Environment.appName,
                provisioningProfile: "match AppStore \(Project.Environment.bundlePrefix)",
                setSkipInstall: false
            ),
            xcconfig: .relativeToRoot("./Config/realse.xcconfig")
        ),

        //   Prod (실제 배포)
        .release(
            name: "Prod",
            settings: commonSettings(
                appName: Project.Environment.appProdName,
                displayName: Project.Environment.appName,
                provisioningProfile: "match AppStore \(Project.Environment.bundlePrefix)",
                setSkipInstall: false
            ),
            xcconfig: .relativeToRoot("./Config/realse.xcconfig")
        )
    ],
    defaultSettings: .recommended
)

base 설정 항목 정리

항목설명

setProductName빌드 타겟의 실행 파일 이름

setCFBundleDisplayName	디바이스에 표시되는 앱 이름
setMarketingVersion	사용자에게 보이는 앱 버전
setASAuthenticationServicesEnabled	Apple 로그인 활성화
setPushNotificationsEnabled	푸시 알림 권한
setEnableBackgroundModes	백그라운드 fetch, location 등
setArchs	아키텍처 설정 (arm64)
setCurrentProjectVersion	빌드 넘버
setCodeSignIdentity	서명 인증서
setCodeSignStyle	Automatic or Manual
setSwiftVersion	Swift 버전 고정
setDevelopmentTeam	Apple Developer Team ID
setDebugInformationFormat	.dSYM 생성 여부

Configuration별 구성

구성용도xcconfig

.debug개발용, 디버깅dev.xcconfig

"Stage"	QA/테스트용	qa.xcconfig
.release	내부 릴리즈용	release.xcconfig
"Prod"	실제 App Store 배포	release.xcconfig

Stage, Prod는 Tuist 기본 enum이 아니라 문자열로 직접 지정해야 해요!

활용 팁

Prod와 Release를 분리하는 이유

CI 파이프라인 분리: release는 내부 테스트, prod는 실제 배포
설정 분기: 앱 이름, 아이콘, API 엔드포인트 등 다르게 가능

xcconfig 활용

# dev.xcconfig
API_BASE_URL = https://dev-api.myapp.com
FEATURE_FLAG_DEBUG = YES

# release.xcconfig  
API_BASE_URL = https://api.myapp.com
FEATURE_FLAG_DEBUG = NO

민감한 정보는 .gitignore에 추가하거나 암호화된 저장소에서 관리하세요!

✅ 전체 정리

Plugin 정리

항목내용

Plugin 구조ProjectTemplatePlugin, DependencyPlugin, DependencyPackagePlugin

ModulePath	enum 기반 모듈 경로 관리
Path 확장	.Shared(implementation:) 등으로 경로 자동화
TargetDependency 확장	.Shared(implements:) 등으로 의존성 간결화
템플릿 함수	makeAppModule, makeModule, makeScheme

Settings 정리

항목내용

공통 설정 추출commonSettings() 함수로 중복 제거

코드 기반 설정	Git으로 추적 가능
환경별 분리	Debug, Stage, Release, Prod
xcconfig 연동	민감한 설정 외부 파일로 관리

마무리

Tuist Plugin이랑 Settings 설정, 처음엔 좀 복잡해 보이는데...

한 번 세팅해두면 진짜 편해요!

특히:

ModulePath + Path Extension = 경로 오타 방지
TargetDependency Extension = 의존성 선언 깔끔
makeModule 템플릿 = 새 모듈 추가 쉬움
Settings 분리 = 환경별 빌드 설정 명확

[iOS] Tuist를 쓰면서 Asset 코드 생성은 직접 만들기로 한 이유

dynamic-ddd — Sat, 28 Mar 2026 18:47:59 +0900

들어가며

안녕하세요, 사이드 프로젝트 DDD 동아리의 iOS 운영진 은표입니다.

iOS 프로젝트를 하다 보면, Tuist를 통해서든 다른 방식으로든 모듈화를 한 번쯤 고민하게 됩니다.

저는 Tuist를 사용하여 프로젝트 모듈화를 진행해봤는데요, 처음에는 정말 만족스러웠습니다.

git rebase 할 때 .pbxproj 파일 충돌도 나지 않고, 프로젝트 전체 구조를 내가 작성한 코드에 맞춰 알아서 잘 생성해주니까요.

그런데 프로젝트를 진행하다 보니 문득 이런 생각이 들었습니다.

Asset 접근할 때 내가 쓰고 있는 방식이 진짜 좋은 방법이 맞나?

처음에는 별생각이 없었습니다.

Tuist의 generate 과정에서 자동으로 만들어지는 코드를 통해 Asset에 접근하면 오타도 줄고, 자동완성도 되고 꽤 편했으니까요.

하지만 프로젝트를 진행할수록 조금씩 거슬리기 시작했습니다.

Asset을 하나 추가하고 나서 바로 화면에서 확인하고 싶은데 Asset 접근 코드를 생성하는 과정이 tuist generate 에 묶여있어 생각보다 자주 작업 흐름이 끊기게 됩니다.

특히 최근에는 buildable folders를 적극적으로 활용하면 관리가 훨씬 편해지는 부분이 있는데, 정작 Tuist를 사용하면 이 장점을 살리지 못하게 됩니다.

그래서 이 문제를 저는 어떤 고민을 했고 최종적으로, 어떻게 결정했는지에 대한 과정을 공유드리려고 합니다.

해결책 찾기

가장 먼저 떠오른건 Xcode나 Asset Catalog가 기본으로 제공하는 자동 생성 기능을 적극적으로 활용하는 방법이었습니다.

이 방식은 단일 앱 타겟에서는 꽤 만족스럽게 쓸 수 있습니다.

기본적인 사용성도 괜찮고, 별도 도구 없이 시작할 수 있다는 장점도 분명합니다.

다만 프로젝트 구조가 조금만 복잡해지면 또 다시 아쉬움이 생깁니다.

예를 들어 Asset을 담아놓은 모듈이 따로 있고, 그걸 여러 모듈이 공통으로 참조하는 구조라면 이야기가 달라집니다.

특히 dynamic framework 같은 형태에서는 접근 제어나 번들 처리, 사용 방식에서 미묘하게 불편한 부분이 생기기 시작합니다.

자동으로 만들어주긴 하는데, 결국 제가 원하는 방식으로는 쓰지 못하게 되더라구요.

다시 옛날으로..?

그러다보니 옛날에 쓰던 라이브러리들이 다시 떠오릅니다.

R.swift 와 SwiftGen

사실 이쯤 되면 이 둘은 꽤 현실적인 선택지입니다.

이미 많은 팀에서 사용해왔고
문자열 기반 접근보다 훨씬 안전하고
빌드 전에 코드를 생성한다는 흐름도 직관적입니다

그래서 그냥 다시 쓸까? 했는데, 막상 다시 보니 완전히 마음에 들지는 않았습니다.

이유는 기능 부족이 아니라, 생성되는 코드의 형태였습니다.

어떤 팀은 메서드 기반 접근이 더 명확하다고 느낄 수 있습니다.
그런데 어떤 팀은 static property 중심의 API를 훨씬 더 선호합니다.

이 차이는 사소해 보여도, 코드베이스 전체에서는 꽤 크게 남습니다.

예를 들어 저는 아래 같은 형태가 더 읽기 좋다고 느꼈습니다.

let image: UIImage = Asset.Image.Home.banner

이런 스타일은 사용성 자체도 깔끔하고, 생성 규칙도 단순한 편입니다.
반대로 어떤 생성 도구는 이와 조금 다른 형태를 기본으로 내보냅니다.

물론 그게 틀렸다는 건 아니지만, 팀 스타일과 안 맞으면 결국 또 래핑하거나 적응해야 합니다.

그러다 보니 생각이 조금씩 바뀌었습니다.

기성 도구를 어떻게든 맞춰 쓰는 것보다, 옛날과 달리 성능이 기가 막힌 LLM도 있겠다 필요한 만큼만 직접 만드는 게 더 낫지 않을까?

✅ 최종 결정

결국은 커스텀 스크립트를 만들기로 했습니다.

비슷한 고민을 먼저 해본 팀들의 사례를 찾아보면, 생각보다 많은 팀이 결국 커스텀 스크립트 쪽으로 가 있었습니다.

방식은 단순합니다.

Asset 폴더를 스캔하고
이름 규칙에 맞춰 코드를 생성하고
실제 Asset이 존재하는지 확인하는 테스트도 같이 만든다

그리고 작업자는 아래와 같은 명령 하나만 실행합니다.

make generate_asset

이 방식이 좋았던 이유는 아주 명확했습니다.

첫 번째는 tuist generate에 덜 의존할 수 있다는 점입니다.
Asset 하나 추가할 때마다 프로젝트 생성 타이밍을 다시 의식하지 않아도 됩니다.

두 번째는 생성되는 API를 팀 스타일에 맞출 수 있다는 점입니다.
이름 규칙, 폴더 구조 반영 방식, 접근 형태, 공개 범위까지 전부 우리가 정할 수 있습니다.

세 번째는 예외 처리도 우리가 결정할 수 있다는 점입니다.
예를 들어 app_Icon와 appIcon처럼 코드 생성 시 이름이 충돌하는 경우를 어떻게 처리할지, 특정 폴더는 생성 대상에서 제외할지 같은 규칙도 넣을 수 있습니다.

즉, 이 시점부터는 기성 도구가 얼마나 완벽하냐보다 우리 팀이 어떤 개발 경험을 원하느냐가 훨씬 중요해집니다.

✍️ 마무리

이번 경험을 통해 느낀 건, Asset 접근 방식도 결국 팀의 개발 경험을 설계하는 문제라는 점이었습니다.

특히 저에게는 tuist generate에 계속 의존하는 흐름이 생각보다 큰 마찰로 다가왔고, 그 과정에서 “무엇을 쓸까?”보다 “우리는 어떤 흐름으로 작업하고 싶은가?”가 더 중요한 질문이라는 걸 체감하게 됐습니다.

또 하나 흥미로웠던 점은, 예전 같았으면 직접 스크립트를 만든다는 선택이 꽤 무겁게 느껴졌을 텐데 지금은 그렇지 않다는 점입니다.

반복적인 코드 생성이나 초안 작성은 LLM의 도움을 받으면 훨씬 빠르게 시작할 수 있고, 그 덕분에 팀은 정말 필요한 규칙과 API 모양을 정하는 데 더 집중할 수 있게 됐습니다.

아쉽게도 이번 글에서는 예시 코드를 크게 다루지 않았습니다.
중요한 건 구현 디테일보다는, 각 팀이 원하는 사용 방식과 생성 흐름을 먼저 정하는 일이라고 생각했기 때문입니다.

정답이 하나로 정해져 있다고 생각하지는 않습니다.
어떤 팀에는 Tuist 기본 기능이 더 잘 맞을 수도 있고, 어떤 팀에는 R.swift나 SwiftGen이 더 나은 선택일 수도 있습니다.

다만 한 가지는 분명했습니다.

이번 글에서는 tuist generate를 예로 들었지만, 특정 도구의 기본 기능이 팀의 워크플로우와 어긋나기 시작하는 순간, 그 의존성을 줄이기 위한 작은 도구를 직접 만드는 선택도 충분히 현실적이라는 점입니다.

그리고 그때부터 중요한 건 무엇을 쓸까? 보다 우리는 어떤 흐름으로 일하고 싶은가? 라는 질문이었습니다.

비슷한 고민을 하고 계신다면, 파이썬으로 작은 생성 스크립트를 한 번 직접 만들어서 사용해보시길 권장합니다.
생각보다 금방 만들 수 있고, 한 번 팀 스타일에 맞게 돌아가기 시작하면 왜 직접 만들고 싶어졌는지 금방 체감하게 됩니다.

긴 글 읽어주셔서 감사합니다.

✍️ 작성자: 은표

직군: iOS Developer
GitHub: https://github.com/honghoker

[Android] java.io.stream에 대한 고찰

dynamic-ddd — Sun, 15 Mar 2026 01:26:42 +0900

들어가며

안녕하세요! ✋

사이드 프로젝트 동아리 DDD에서 Android 개발자로 활동하고 있는 오세민입니다.

이번 글에서는 Java 개발을 하다 보면 반드시 마주치게 되는 주제,
Stream, InputStream, OutputStream의 설계 철학에 대해 이야기해보려고 해요.

특히,

Stream이라는 개념이 왜 존재하는지
왜 입력과 출력이 분리되어 있는지
flush()와 close()는 왜 필요한지

이런 질문들을 중심으로
"왜 이렇게 설계되었을까?"라는 질문에서 시작해 보려고 합니다.

Stream은 뭘까요

Stream이라는 단어를 처음 들으면 Java 8의 Stream API가 떠오를 수도 있어요.
하지만 여기서 이야기하는 Stream은 그것보다 훨씬 근본적인 개념이에요.

Stream은 "데이터의 흐름(Flow)"을 추상화한 구조예요.

Java의 설계 철학은 이래요.

모든 입출력은 Stream을 통해 이루어진다.

파일이든, 네트워크든, 디바이스든
동일한 방식으로 다룰 수 있도록
데이터를 '흐름(Stream)'이라는 개념으로 통일한 거예요.

그래서 Stream을 이렇게 정리할 수 있어요.

Stream = "JVM ↔ OS 간 데이터 통로"

JVM이 OS의 입출력 시스템(파일, 네트워크, 디바이스 등)과 통신하기 위한
통일된 인터페이스라고 보면 돼요.

실제로는 어떤 리소스와 연결될까요

Stream이라는 하나의 추상화 아래에는
실제로 다양한 리소스가 연결되어 있어요.

실제 리소스	Stream 구현체	OS 레벨 매핑
파일	`FileInputStream` / `FileOutputStream`	file descriptor (fd)
네트워크 소켓	`SocketInputStream` / `SocketOutputStream`	socket fd
파이프	`PipedInputStream` / `PipedOutputStream`	pipe fd
메모리	`ByteArrayInputStream` / `ByteArrayOutputStream`	JVM heap 메모리

파일을 읽든, 소켓으로 데이터를 보내든,
코드에서 다루는 방식은 동일해요.

이게 바로 Stream이라는 추상화가 가져다주는 힘이에요.

↔️ 왜 InputStream과 OutputStream으로 나뉘어 있을까요

Java는 Stream을 단방향(one-way)으로 설계했어요.

클래스	방향	주요 메서드
`InputStream`	입력 (read)	`read()`, `read(byte[])`
`OutputStream`	출력 (write)	`write()`, `flush()`, `close()`

이렇게 분리한 이유는 명확해요.

데이터 흐름의 책임을 명확히 하고,
예측 가능한 I/O를 보장하기 위해서예요.

"이 Stream은 읽기만 한다" 또는 "이 Stream은 쓰기만 한다"가
코드 레벨에서 명확하게 드러나는 거예요.

양방향 통신이 필요한 Socket 같은 경우에도
내부적으로는 InputStream + OutputStream 쌍으로 처리해요.

"데이터는 한 방향으로만 흐른다"는 철학을 일관되게 지키는 거예요.

️ 왜 추상 클래스로 설계했을까요

InputStream과 OutputStream은 인터페이스가 아니라 추상 클래스예요.

그 이유는 이래요.

파일, 네트워크, 메모리 등
다양한 데이터 소스를 동일한 인터페이스로 다루기 위해서예요.

구조를 보면 이렇게 생겼어요.

            InputStream / OutputStream  ← 추상화 계층 (Closeable)
                         │
     ┌───────────────────┼─────────────────────┐
     │                   │                     │
FileInputStream     SocketInputStream     ByteArrayInputStream
(fd 기반)            (fd 기반)              (메모리 기반)

모든 Stream은 동일한 추상 메서드를 통해 동작하지만,
각 구현체는 자신이 다루는 리소스(fd, socket, memory)에 따라
실제 I/O 방식을 다르게 정의해요.

덕분에 우리는 "이게 파일인지 소켓인지"를 신경 쓰지 않고
동일한 코드로 데이터를 읽고 쓸 수 있어요.

Closeable을 상속한 이유가 뭘까요

Stream이 OS 리소스와 연결된 이상,
그 통로(fd)는 커널에 의해 관리되며 유한한 리소스예요.

Closeable을 상속한 이유는 명확해요.

Stream이 열리면 OS에 리소스가 등록되고,
close()는 그 리소스를 OS에 반납해요.

단계별로 보면 이래요.

단계	동작	대응되는 OS 동작
Stream 생성	OS에 `open()` syscall 호출	fd 할당
데이터 I/O	`read()`/`write()` 호출	커널 버퍼를 통한 I/O
`close()` 호출	OS에 `close(fd)` syscall	fd 해제, 커널 리소스 반납

그래서 close()는 이렇게 이해하면 돼요.

close() = "JVM이 OS에게 이제 이 통로(fd)를 닫아도 좋습니다"라는 신호

close()를 호출하지 않으면
fd가 계속 열린 채로 남아서 리소스 누수(resource leak)가 발생해요.

이건 단순히 메모리 문제가 아니라,
OS 레벨의 리소스 고갈로 이어질 수 있는 심각한 문제예요.

flush는 단순히 "버퍼를 비우는 것"이 아니에요

flush()를 "버퍼를 비운다"고만 알고 계신 분이 많을 거예요.
하지만 조금 더 정확하게 말하면 이래요.

flush() = "지연된 I/O를 즉시 수행하여
논리적 상태와 물리적 상태를 일치시키는 행위"

데이터는 여러 단계의 버퍼를 거쳐요.

[앱 코드] → [JVM 버퍼] → [OS 커널 버퍼] → [디스크/네트워크]

계층	flush 대상	대표 메서드
JVM 버퍼	`BufferedOutputStream`	`flush()`
OS 버퍼	`FileDescriptor`	`sync()` (fsync(fd))

flush()는 "현재 계층의 데이터를 다음 계층으로 강제 전송(commit)"하는 역할을 해요.

쉽게 말하면,

flush() = "이제 진짜로 보내라"

JVM 버퍼를 OS 커널로,
OS 버퍼를 디스크로 내보내는 타이밍 제어 수단이에요.

네트워크 통신에서 flush()를 빼먹으면
데이터가 버퍼에 머물러서 상대방에게 도착하지 않는 경우도 있어요.

그래서 flush()는 데이터 일관성을 보장하는 중요한 메서드예요.

설계 철학을 한눈에 정리하면요

항목	의미
Stream	데이터 흐름(Flow)의 추상화. JVM ↔ OS I/O의 논리적 통로
InputStream / OutputStream	OS의 read/write 개념을 분리하여 표현
Closeable	OS 리소스(fd, socket 등)를 명시적으로 해제하는 계약
`flush()`	지연된 I/O를 즉시 커밋하여 데이터 일관성 보장
단방향성	데이터 흐름의 책임과 안정성을 확보하기 위한 구조
추상화 목적	파일, 네트워크, 메모리 등 모든 I/O를 일관된 인터페이스로 다루기 위함

✅ 정리해보면 이렇습니다

Stream은 "JVM과 OS 사이의 통로"예요
InputStream과 OutputStream은 그 통로를 통해 데이터를 "읽고/쓰는 방향"을 정의해요
flush()는 데이터를 다음 계층으로 커밋하는 시점 제어 도구예요
close()는 OS 리소스를 해제하는 명시적 종료 신호예요

결국 Stream은 "I/O를 일관된 추상화로 표현한 계약(Contract)"이며,
Java의 일관성과 안전성 철학을 가장 잘 보여주는 구조예요.

무엇을 쓰느냐보다
왜 이런 구조가 존재하는지 이해하는 게 더 중요해요.

I/O는 조용히 동작하지만,
문제가 생기면 고치기 어렵거든요.

긴 글 읽어주셔서 감사합니다.

레퍼런스

이 글을 정리하면서 실제로 참고한 자료들이에요.

요즘 주니어 디자이너에게 더 중요해진 능력: 툴 vs 사고력

dynamic-ddd — Sun, 8 Mar 2026 19:55:21 +0900

안녕하세요!

DDD에서 디자인 운영진을 맡고 있는 이윤경입니다.

오늘은 Ai시대에 생각하는 디자이너로 살아남기위한 글을 가져왔습니다!

디자인을 시작하면 가장 먼저 배우는 것은 보통 툴입니다.
프로그램과 AI를 얼마나 잘 다루는지가 실력의 기준처럼 느껴지기도 합니다

이제 ‘툴을 잘 쓰는 디자이너’만으로는 경쟁력이 되기 어렵습니다.
“툴을 잘 쓰는 디자이너”보다 “생각을 할 수 있는 디자이너”가 더 중요해지고 있습니다.

서론. 툴 실력은 기본값이 되어버렸다

예전에는 손이 빠르고 기술이 많은 디자이너가 경쟁력이 있었습니다.
하지만 지금은 상황이 많이 달라졌습니다.

디자인 툴의 진입 장벽이 낮아졌고
온라인 강의와 유튜브, 다양한 템플릿이 넘쳐나며
AI 툴까지 등장했습니다

이제 ‘툴을 다룰 줄 안다’는 것은
강점이라기보다 기본 조건에 가깝습니다.

툴은 배우면 익숙해질 수 있지만, 문제를 어떻게 바라보는지는 쉽게 배워지지 않습니다.

이미지 출처: Pinterest

AI 시대에 더 중요해진 사고력

AI는 이미 이미지 생성, 레이아웃 제안, 색상 추천까지 해주고 있습니다.
앞으로 툴을 ‘조작하는 능력’은 더 빠르게 자동화될 가능성이 큽니다.

그렇다면 디자이너는 무엇을 해야 할까요?

무엇을 만들지 결정하고
어떤 방향이 맞는지 판단하며
그 결과를 평가하는 역할입니다

이 영역은 여전히 AI보다 사람이 더 잘할 수 있는 부분입니다.

즉, AI 시대의 디자이너는
손이 빠른 사람이 아니라 판단을 잘하는 사람이 되어야 합니다.

본론. 사고력이란 무엇일까?

디자인에서 말하는 사고력은 ‘아이디어가 많은 것’이나 ‘감각이 좋은 것’을 의미하지 않습니다.

디자이너의 사고력은 보통 문제를 구조적으로 바라보는 능력에 가깝습니다.

조금 더 풀어보면, 사고력은 다음 세 단계로 나누어 볼 수 있습니다

1) 현상을 문제로 바꾸는 능력

이미지 출처: Writing - Material Design

사고력의 시작은 “불편하다”는 말을 그대로 받아들이지 않는 데서 출발합니다.

예를 들어 “결제 페이지가 불편해요”라는 피드백이 있다면,
툴 중심 사고는 → “그럼 UI를 조금 더 간략하게 바꿔야겠다.”라고 생각합니다.

반면 사고 중심 접근은 → “왜 불편할까?”라고 질문합니다.
버튼이 잘 안 보이는 걸까? 정보가 너무 많아서 헷갈리는 걸까? 신뢰가 가지 않는 걸까? 화면이 느리게 느껴지는 걸까?

같은 피드백이라도 원인을 어떻게 나누어 보느냐에 따라 방향은 달라집니다.
디자이너의 사고력은 문제를 디자인 이전 단계에서 정의하는 능력에 가깝습니다.✏️

2) 선택에 이유를 붙이는 능력

이미지 출처: Buttons - Material Design

디자인에는 정답이 없다고 말하지만, 이유 없는 선택은 설득력이 없습니다.
사고력이 있는 디자이너는 이렇게 말합니다.

“이 버튼을 크게 만든 이유는 모바일 화면에서 가장 중요한 행동이기 때문입니다.”
“이 단계에서 리뷰를 보여준 이유는 결제 직전에 불안을 줄이기 위함입니다.”

반대로 사고력이 부족하면 설명이 이렇게 바뀝니다.

“그냥 이게 예뻐 보여서요.” “원래 이렇게들 해서요.”

즉, 사고력의 차이는 결과물이 아니라 설명 방식에서 드러납니다.

3) 결과를 해석하는 능력

이미지 출처: 모두의 연구소

사고력은 디자인을 만드는 순간에 끝나지 않습니다. 출시 이후에도 계속 이어집니다.

사용자가 어디에서 멈추는지 어느 지점에서 많이 이탈하는지 예상과 다른 행동을 보였는지
이런 부분들을 다시 살펴보아야 합니다.

이때 “디자인이 실패했습니다”라고 말하기보다는,
“세운 가설이 틀렸구나”라고 해석할 수 있는지가 중요합니다.

사고력이란 결과를 감정이 아니라 데이터와 관찰을 통해 이해하는 힘이라고 볼 수 있습니다.

결론. 사고력은 재능이 아니라 훈련이다!

많이 오해하는 부분이
“사고력은 타고나는 것 아니야?”라는 질문입니다.

하지만 사고력은 감각보다는 습관에 더 가깝습니다.

다음과 같은 질문을 평소에 자주 던지는 디자이너는 자연스럽게 사고력이 쌓이게 됩니다.

이 화면에서 사용자는 뭘 할까?
왜 여기서 멈출까?
이 문구는 오해를 만들지 않을까?
내가 이 사용자라면 기분이 어떨까?

이것은 특별한 재능이라기보다, 관점을 반복하는 연습에 가깝습니다.

마무리하며 ...

이미지 출처: Pinterest

툴 실력은 화면 위에서 바로 드러납니다.
하지만 사고력은 화면 뒤에서 조용히 작동합니다.

AI 시대에 디자이너로 살아남는 힘은
무엇을 만들지 판단하고, 그 이유를 스스로 설명할 수 있는 사고력에 있습니다

Tuist 모듈 자동화 CLI 자동화 만들기

dynamic-ddd — Wed, 25 Feb 2026 15:18:53 +0900

tuisttool.swift 만든 썰 - Tuist 명령어 치다가 손가락 아파서 만듦

이 글을 쓰게 된 계기

안녕하세요! iOS 운영진 서원지입니다 ㅋㅋㅋ

Tuist 쓰다 보면 이런 거 계속 치잖아요:

tuist generate
tuist fetch
tuist clean
tuist generate

하루에 몇 번을 치는지 모르겠어요... 손가락 아파 죽겠음

그래서 그냥 CLI 도구를 만들어버렸습니다!

만들고 싶었던 기능들

tuist generate, fetch, clean 등 한 방에 실행
새 모듈 만들 때 의존성 선택지 자동으로 보여주기
Modules.swift, SPM.swift 파싱해서 뭐 있는지 알아서 찾기
도메인 모듈이면 Interface 폴더도 자동 생성

이거 다 구현했어요! ㅋㅋㅋ

명령어 정리

./tuisttool.swift generate      # tuist generate
./tuisttool.swift fetch         # tuist fetch
./tuisttool.swift build         # clean + fetch + generate (한 방에!)
./tuisttool.swift clean         # tuist clean
./tuisttool.swift reset         # DerivedData + 캐시 싹 지우고 generate
./tuisttool.swift moduleinit    # 새 모듈 만들기 + 의존성 자동 삽입

build 이거 진짜 편해요. 세 개 따로 안 쳐도 됨!

핵심 구현 포인트

1. 쉘 명령 실행하는 함수

func run(_ command: String, arguments: [String] = []) -> Int32
func runCapture(_ command: String, arguments: [String] = []) throws -> String

run(): 그냥 실행만 하면 될 때
runCapture(): 결과 값 받아야 할 때

이거 두 개만 있으면 웬만한 건 다 됨!

2. 모듈 이름이랑 의존성 입력받기

let moduleInput = prompt("모듈 이름 입력")
let moduleName = prompt("생성할 이름 입력")

의존성은 두 가지 방식으로 선택 가능하게 했어요:

SPM: Extension+TargetDependencySPM.swift 파싱해서 목록 보여줌
내부 모듈: Modules.swift에서 enum case 파싱해서 보여줌

직접 타이핑 안 해도 됨! 선택만 하면 됨!

3. Tuist scaffold 실행

let result = run("tuist", arguments: [
  "scaffold", "Module",
  "--layer", layer,
  "--name", moduleName,
  "--author", author,
  "--current-date", currentDate
])

모듈 타입(Presentation, Shared, Core/Domain)에 따라 layer 자동 지정!

4. Project.swift에 의존성 자동 삽입

이게 제일 귀찮았던 부분인데요:

if var content = try? String(contentsOfFile: projectFile),
   let range = content.range(of: "dependencies: [") {
   ...
   content.insert(contentsOf: "  .SPM.alerter", at: insertIndex)
}

모듈 만들고 나서 Project.swift 열어서 의존성 추가하는 거...

이제 자동으로 넣어줌! ㅋㅋㅋ

5. 도메인 모듈이면 Interface 폴더도 자동 생성

도메인 모듈은 Interface 분리하잖아요?

그것도 자동으로 만들어줍니다:

Projects/Core/Domain/MyModule/Interface/Sources/Base.swift

템플릿까지 같이 생성! 손 안 대도 됨!

생성되는 구조

Projects/
└── Core/
    └── Domain/
        └── MyFeature/
            ├── Interface/
            │   └── Sources/
            │       └── Base.swift
            └── Sources/

깔끔하죠? ㅋㅋㅋ

삽질 포인트

파일 파싱할 때 주의

Modules.swift 파싱할 때 정규식 잘못 쓰면 이상한 거 잡혀요.

enum case만 정확히 잡으려고 꽤 고생했음 ㅠㅠ

경로 처리

상대 경로 / 절대 경로 헷갈리면 파일 못 찾음.

FileManager.default.currentDirectoryPath 잘 활용하세요!

마무리

모듈 자주 만드는 분들한테 강추예요!

반복 작업 도구화하면 생산성 확 올라감!

Tuist가 구조화 잘 되어 있어서, 거기에 CLI 도구 얹으면 시너지 대박이에요.

팀원들이랑 같이 쓰면 더 좋고요

저도 계속 기능 추가할 예정입니다!

다음 글 예고: Tuist Plugin 만들기 다뤄볼 예정입니다!

작성자: iOS 운영진 서원지

GitHub: https://github.com/Roy-wonji

[Android] joda‑time, java.time, kotlinx‑datetime에 대하여..

dynamic-ddd — Sat, 14 Feb 2026 17:06:37 +0900

들어가며

안녕하세요! ✋

사이드 프로젝트 동아리 DDD에서 Android 개발자로 활동하고 있는 오세민입니다.

이번 글에서는 개발을 하다 보면 한 번쯤은 꼭 마주치게 되는 주제,
시간과 날짜를 다루는 라이브러리에 대해 이야기해보려고 해요.

특히,

Joda-Time
java.time
kotlinx-datetime

이 세 가지를 중심으로
“왜 이렇게 나뉘어 있을까?”라는 질문에서 시작해 보려고 합니다.

⏰ 시작은 항상 이 의문에서 합니다

Joda-Time은 꽤 범용적인 시간 라이브러리예요.
실제로 오래전부터 많은 프로젝트에서 사용됐고, 지금도 레거시 코드에서는 자주 보입니다.

그런데 Java에는 또 java.time이 있고,
Kotlin에는 kotlinx-datetime이라는 라이브러리가 따로 있어요.

그러다 보면 자연스럽게 이런 생각이 들어요.

Joda-Time으로도 충분히 잘 되는데
왜 Java와 Kotlin은 굳이 시간 라이브러리를 다시 만든 걸까요?

이 글은 이 질문에서 출발해요.
“뭘 써야 할까?”보다는
“왜 이렇게 나뉘게 되었을까?”를 먼저 정리해보려 해요.

️ Joda-Time은 왜 그렇게 많이 쓰였을까요

Java 8 이전을 떠올려보면,
시간을 다루는 기본 API가 썩 친절하지 않았어요.

java.util.Date는 이름과 다르게 날짜/시간 개념이 섞여 있고
Calendar는 mutable하고 사용하기도 불편했어요

이런 상황에서 등장한 게 Joda-Time이에요.

불변 객체
날짜, 시간, 기간 개념의 명확한 분리
타임존을 고려한 설계

그래서 한동안은 “Java에서 시간 다루려면 Joda-Time”이라는 말이 거의 정설처럼 쓰였어요.

그래서 Joda-Time의 현재 위치는요

여기서 흥미로운 사실 하나가 있어요.
Joda-Time의 핵심 개발자와 java.time(JSR-310)의 설계자가 동일 인물이라는 점이에요.

Joda-Time을 만들었던 Stephen Colebourne이
Java 8의 시간 API 설계에도 직접 참여했고,
그 결과물이 바로 java.time이에요.

그래서 구조를 보면 익숙한 이유도 여기에 있어요.
Joda-Time에서 검증된 개념과 설계를 그대로 가져와
Java 공식 표준으로 정리한 게 java.time이기 때문이에요.

이 개발자는 공식 문서와 여러 글에서 분명하게 이야기해요.

Joda-Time은 유지보수 모드이며, 새 코드에서는 java.time을 사용하라

그래서 지금 시점에서 Joda-Time은 이렇게 보는 게 자연스러워요.

기존 레거시 유지보수 → 괜찮아요
새 프로젝트 설계 → 굳이 선택할 이유는 없어요

문제가 있어서 밀려난 게 아니라,
자신의 설계가 표준으로 흡수되면서 역할을 마무리한 라이브러리에 더 가까워요.

Joda-Time이 실패해서 사라진 게 아니라,
성공했기 때문에 java.time으로 이어졌다고 보는 게 맞아요.

Kotlin에서는 왜 또 다른 선택지가 있을까요

여기서 kotlinx-datetime이 등장해요.
이 라이브러리는 Java의 시간 API를 대체하려는 목적이 아니에요.
핵심은 딱 하나예요.

Kotlin Multiplatform에서 공통으로 사용할 수 있는 시간 API

그래서 몇 가지 차이가 있어요.

JVM, Android, iOS, JS에서 공통 사용
Instant, LocalDate 같은 개념은 유지
타임존은 TimeZone을 명시적으로 함께 사용

val instant = Clock.System.now() 
val local = instant.toLocalDateTime(TimeZone.of("Asia/Seoul"))

Java의 ZonedDateTime을 그대로 쓰지 않은 이유도 멀티플랫폼 환경을 고려한 선택이에요.

️ 개념으로 보면 라이브러리는 덜 헷갈려요

시간 라이브러리가 어려운 이유는 문법보다 개념이 섞이기 때문이에요.

개념	의미
Instant	절대적인 시점
LocalDate	날짜
LocalTime	시간
ZonedDateTime	날짜 + 시간 + 타임존
Duration	시간의 양

이 개념은
Joda-Time, java.time, kotlinx-datetime 모두 거의 동일해요.

차이는 “어디에서 쓰느냐”에 더 가까워요.

Android에서는 이렇게 선택해요

minSdk 26 이상

java.time을 그대로 사용하면 돼요.
추가 고민은 거의 없어요.

minSdk 26 미만

이 경우에도 방법은 명확해요.

Core Library Desugaring을 활성화해서
java.time을 백포트해서 사용하는 방식이 가장 안정적이에요.

android {
  compileOptions {
    coreLibraryDesugaringEnabled true
  }
}

dependencies {
  coreLibraryDesugaring(
    "com.android.tools:desugar_jdk_libs:..."
  )
}

실무에서 가장 많이 쓰이는 방식이에요.

Kotlin Multiplatform이라면 선택이 달라져요

공용 모듈에서는 kotlinx-datetime이 현실적인 선택이에요.

그리고 시간 계산은
kotlin.time.Duration이 정말 잘 만들어져 있어요.

5.hours + 30.minutes

읽는 순간 바로 이해된다는 점에서
이건 꽤 큰 장점이에요.

시간 라이브러리에서 가장 중요한 원칙

라이브러리 선택보다 더 중요한 건 이 원칙이에요.

저장과 전송은 항상 Instant로 해요
사람에게 보여줄 때만 날짜와 타임존을 입혀요

이 기준을 지키면

서버와 클라이언트 간 시간 차이
타임존 문제
DST(일광절약시간) 이슈

대부분을 자연스럽게 피할 수 있어요.

✅ 정리해보면 이렇습니다

Joda-Time은 한 시대를 잘 마무리한 라이브러리예요
java.time은 그 설계를 공식 표준으로 만든 결과예요
kotlinx-datetime은 멀티플랫폼을 위한 현실적인 선택이에요

무엇을 쓰느냐보다 왜 이런 타입과 라이브러리가 존재하는지 이해하는 게 더 중요해요.
시간은 조용히 쌓이고, 문제가 생기면 고치기 어렵거든요.

긴 글 읽어주셔서 감사합니다.

레퍼런스

이 글을 정리하면서 실제로 참고한 자료들이에요.

https://www.joda.org/joda-time/

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.time/

[Design] 픽셀을 넘어 공간으로: AI 시대, 디자이너가 XR에 주목해야 하는 이유]

dynamic-ddd — Sat, 31 Jan 2026 00:27:48 +0900

들어가며

안녕하세요!✋

사이드 프로젝트 동아리 DDD에서 디자인 운영진을 맡고 있는 이소현입니다.

DDD는 개발자, 디자이너, PM이 함께하는 사이드 프로젝트 동아리입니다. DDD에서 세 번째 글로 인사드리게 되었습니다.

오늘은 요즘 디자이너들 사이에서 가장 뜨거운 화두인 'AI', 그리고 그 너머의 'Next Generation'에 대해 이야기해 보려 합니다.

AI의 역설: 정복되지 않을 분야는 없다?

혹시 "AI가 발전하면서 가장 빠르게 대체될 직업 중 하나가 디자이너"라는 이야기를 들어보셨나요?

AI가 등장하기 전, 사람들은 미술이나 음악 같은 예체능 분야만큼은 기계가 절대 범접할 수 없는 영역이라고 믿었습니다. 하지만 인간은 금기시된 영역이라고 생각할수록 더 정복하고 싶어 하나 봐요. 어느덧 Nano Banana, Midjourney 같은 생성형 AI들이 누구보다 빠르게 우리 곁에 찾아왔으니까요.

기술의 발전이 조금은 무섭게 느껴질 수도 있지만, 저는 디자이너가 단순히 '도구를 다루는 사람'에 머물러서는 안 된다'라고 생각합니다. 미래의 디자이너는 AI의 결과물을 비판적으로 해석하고, 그 안에 새로운 의미를 부여하는 사람으로 진화해야 합니다. 불편하더라도 현실을 직시하고 기술을 도구로서 영리하게 활용해야 하죠.

️ 스크린의 해체, 'XR'이라는 새로운 무대

우리는 다음 세대(Next Generation)를 준비해야 합니다. 그래서 저는 XR(eXtended Reality, 확장 현실)에 주목했습니다. XR은 AR(증강 현실), VR(가상현실), MR(혼합 현실)을 아우르는 몰입형 기술입니다. 쉽게 말해 '스마트 글라스'의 세상을 떠올려 보세요. 이미 메타(Meta)와 애플(Apple)이 시장의 문을 열었고, 구글과 삼성은 젠틀몬스터와 함께 새로운 미래를 준비하고 있습니다.

아직은 먼 얘기라고 생각하실 수도 있지만, 우리 일상에 곧 자연스럽게 녹아든 새로운 패러다임을 만날 수 있지 않을까 생각이 듭니다.

스마트 글래스가 일상이 되면 어떤 변화가 일어날까요?

스크린의 확장: 손바닥 안의 디스플레이를 넘어 내가 머무는 모든 공간이 스크린이 됩니다.
인터랙션의 변화: '클릭' 중심에서 사용자의 '시선'과 '손동작'이 핵심 입력 수단이 됩니다.

이러한 변화를 멀티모달 인터랙션(Multimodal Interaction)이라 부르며, 멀티모달은 텍스트, 이미지, 음성, 영상 등 다양한 형태의 데이터를 동시에 인식하고 처리하며 이해하는 인공지능 기술입니다.

https://youtu.be/YPxDjVKxfBA?si=CWhSCPXOjcKPYJko

유튜버 잇섭님의 영상 하나를 첨부드리겠습니다. 영상을 보시면 과거 영화에 미래를 표현해 내기 위해 나왔던 공간에 떠다니는 스크린이 이제는 실제 스마트 글래스를 통해 보이는 디스플레이가 그대로 구현되어 있는 것을 보실 수 있습니다. 화면 안의 구성을 넘어 공간 전체를 인터페이스로 활용하는 공간 디자인(Spatial Design) 또한 디자이너의 새로운 핵심 역량이 될 것입니다.

‍ 디자이너의 문법이 완전히 바뀌는 지점

위 영상에서 보듯, 이제 디자인은 더 이상 평면에 갇혀 있지 않습니다. '디자이너가 가져야 할 새로운 능력'은 크게 세 가지입니다.

실재감을 만드는 감각 설계: 마우스 커서가 없는 세상에서는 사용자의 손짓이 버튼에 닿았는지 인지시키는 것이 중요합니다. 미세한 효과음(Sound)이나 시각적인 떨림(Visual Feedback)을 통해 물리적 촉감이 없는 환경에서도 '실재감'을 만들어내야 합니다.
맥락을 인지하는 영리함: 현실과 가상이 공존하기에 사용자의 안전을 우선해야 합니다. 길을 걷는 사용자에게 시야를 가리는 팝업을 띄우는 것은 위험합니다. 주변의 빛, 사용자의 위치, 현재 행동에 따라 UI의 투명도와 사이즈를 자동으로 조절하는 '맥락 인식 디자인'이 필수적입니다.
픽셀에서 볼륨으로: 이전까지 정해진 규격 안에서 시각적 위계를 잡았다면, 이제는 사용자의 공간과 디지털 오브젝트가 놓이는 '깊이감'과 공간과의 조화를 설계해야 합니다.

‍♀️ 개발자·PM·디자이너, 우리는 어떻게 상생할까?

DDD는 협업 동아리인 만큼, 이 세 직군이 미래에 어떤 역할을 해야 할지 Gemini에게 직접 물어보았습니다.

Future Role in XR Era

디자이너: "이제 픽셀(Pixel)이 아니라 볼륨(Volume)을 설계해야 합니다."

PM: "사용자가 가상 화면에 가로막혀 벽에 부딪히지 않도록 안전한 사용자 여정을 설계해야 합니다."

개발자: "3D 객체를 실제 공간 좌표에 고정(Anchoring)시키는 기술이 필수적입니다."

마무리

결국 AI가 많은 도구를 대신하고, 세상이 급변해도 사용자가 머무는 그 안의 경험을 조율하는 것은 여전히 우리 디자이너의 몫입니다.

Next Generation을 준비하는 동료분들, DDD에서 함께 그 미래를 그려보면 어떨까요? 제가 최근 깊게 빠져있는 이 분야의 이야기가 여러분께 조금이라도 흥미로운 영감이 되었기를 바랍니다.

DDD 13기 크루 모집 중!

DDD는 사이드 프로젝트 동아리로, 책임감 있는 협업을 기반으로 상호간의 인사이트를 공유할 수 있도록 다양한 기회를 제공합니다. 사이드 프로젝트에 관심있는, 열정과 재능이 넘치는 13기 멤버들을 모집하고 있습니다.

모집 링크

- linktr.ee/dddstudy

❗모집 대상
- 프로젝트를 통해 함께 성장하고 싶은 기획자와 디자이너, 개발자

- 격주 토요일 오후 2시 - 6시에 성실하게 참여 가능하신 분.

모집 일정
- 2026년 1월 25일(일) ~ 2월 7일(토)

서류 합격자 발표
- 2월 14일(토) 안내 예정

인터뷰 일정
- 2월 21일(토)~22일(일)

- 온라인으로 최대 1시간 동안 진행

최종 합격자 발표
- 2월 23일(월) 문자로 안내

- 3월 7일(토) 오프라인 OT 진행

[활동 기간]
- 2026.03.07 ~ 2026.06.27
- 서울지역 격주 토요일 오후 2시 - 6시 오프라인 활동

[참여 비용]
- 운영비용 8만원 + 노쇼비용 8만원
- 4개월 동안 모든 비용은 간식비, 장소비, 경품비로 사용되며 노쇼비는 활동이 끝나고 돌려드립니다.

[문의방법]
- 인스타그램 : DM으로 문의
- 이메일 문의: dddstudy1@gmail.com

✍️ 작성자: 이소현

직군: Designer

Tuist 모듈화에 빠져보기

dynamic-ddd — Sat, 24 Jan 2026 17:01:59 +0900

Tuist 많이 사용한 개발자 알려주는 팁

안녕하세요! iOS 운영진 서원지입니다 ㅋㅋㅋ

이 글을 쓰게 된 계기는... 요즘 주니어 개발자분들이 Tuist를 하도 많이 써서요..

저도 그렇고. 거의 모든 프로젝트에서 Tuist를 써봤다 보니 경험 공유해 드리면 좋을 것 같더라고요!

제가 경험한 내용 위주로 작성했습니다. 더 좋은 방법 있으면 편하게 알려주세요

Tuist가 뭐길래 이렇게 난리야?

솔직히 처음 Tuist 접했을 때는 "이게 뭐가 좋은데?" 싶었어요 ㅋㅋ

README 보면 이렇게 쓰여있거든요:

"Xcode Project를 생성하거나 유지보수하거나 상호작용하는 Command Line Tool"

아 네... 뭔 소리인지 1도 모르겠더라고요

대충 분석해 보니까

Xcode 프로젝트 파일을 코드로 관리하는 거더라고요
GUI에서 클릭클릭 하던 걸 Swift 코드로 작성
팀 작업할 때 프로젝트 설정 충돌 안남
모듈화 할 때 진짜 편함

"아~ 이거구나!" 싶어서 바로 도입해 봤는데... 진짜 편하더라고요!

설치부터 해보자 (삽질 경험담 포함)

mise로 설치하기

# 요즘 mise 쓰는 게 트렌드래요
mise install tuist

# 이것만 하면 안되고... (저도 여기서 삽질함 ㅠ)
mise use -g tuist

# 이제야 됩니다!
tuist --version

삽질 포인트: mise install 만 하고 mise use -g 안 하면 command not found 나와요. 저도 여기서 30분 헤맸음

첫 프로젝트 만들기

# 프로젝트 초기화 (여기서 Project.swift 파일 생성됨)
tuist init

# 실제 Xcode 프로젝트 생성 (여기가 핵심!)
tuist generate

# 빌드도 터미널에서 가능
tuist build

# 설정 파일들만 따로 편집
tuist edit

매번 tuist generate 하는 게 좀 귀찮긴 한데... 익숙해지면 괜찮아요!
(나중에는 자동화 만들었어욬ㅋㅋㅋ)

의존성 관리가 진짜 핵심이에요

여기가 진짜 중요한 부분이에요. 저도 처음엔 이해 안 됐는데 몇 번 써보니까 이해되더라고요.

Package.swift에서 모든 걸 관리

Plugin/DependencyPackagePlugin/Package.swift 파일에서 모든 외부 라이브러리를 선언합니다.

@preconcurrency import PackageDescription

#if TUIST
@preconcurrency import ProjectDescription

// 이 부분이 진짜 중요! Firebase 때문에 추가함
let packageSettings = PackageSettings(
  productTypes: [
    "FirebaseCore": .staticLibrary,
    "FirebaseAuth": .staticLibrary,
    "FirebaseFirestore": .staticLibrary,
    "FirebaseAnalytics": .staticLibrary,
    "FirebaseCrashlytics": .staticLibrary,
    "FirebaseRemoteConfig": .staticLibrary
  ]
)
#endif

let package = Package(
  name: "MyAwesomeProject", // 여기는 본인 프로젝트명으로!
  dependencies: [
    // Firebase (필수템)
    .package(url: "<https://github.com/firebase/firebase-ios-sdk>", from: "10.27.0"),

    // TCA (요즘 핫한 아키텍처)
    .package(url: "<https://github.com/pointfreeco/swift-composable-architecture>", exact: "1.18.0"),

    // Swift Concurrency 관련 유틸들
    .package(url: "<https://github.com/pointfreeco/swift-concurrency-extras.git>", from: "1.1.0"),

    // TCA 화면전환 관리
    .package(url: "<https://github.com/johnpatrickmorgan/TCACoordinators.git>", exact: "0.11.1"),

    // 네트워킹 (직접 만든 거 써봤어요)
    .package(url: "<https://github.com/Roy-wonji/AsyncMoya>", from: "1.1.0"),
    .package(url: "<https://github.com/Roy-wonji/WeaveDi.git>", from: "3.4.0")
  ]
)

Firebase 삽질담

Firebase 쓰시는 분들 주목! 저도 여기서 진짜 많이 삽질했어요...

왜 static library로?

Firebase 그냥 쓰면 링크 에러 나거든요. 특히 모듈화 할 때 진짜 골치아픔.

let packageSettings = PackageSettings(
  productTypes: [
    "FirebaseCore": .staticLibrary,        // 이렇게 static으로!
    "FirebaseAuth": .staticLibrary,        // 안그러면 링크 에러남
    "FirebaseFirestore": .staticLibrary,   // 진짜임...
    // ... 쓰는 Firebase 모듈 다 static으로
  ]
)

꿀팁: #if TUIST 써서 Tuist에서만 이 설정이 적용되게 했어요. 일반 SPM에서는 무시됨!

enum으로 깔끔하게 정리하는 법

매번 TargetDependency.external(name: "긴 이름의 라이브러리") 이렇게 쓰기 싫잖아요? ㅋㅋㅋ

Plugin/DependencyPackagePlugin/ProjectDescriptionHelpers/Extension+TargetDependencySPM.swift 파일 만들어서:

import ProjectDescription

public extension TargetDependency {
  enum SPM {} // SPM용 네임스페이스
}

public extension TargetDependency.SPM {
  // 이렇게 하면 오타도 안나고 자동완성도 됨!
  static let asyncMoya = TargetDependency.external(name: "AsyncMoya", condition: .none)
  static let weaveDi = TargetDependency.external(name: "WeaveDi", condition: .none)
  static let composableArchitecture = TargetDependency.external(name: "ComposableArchitecture", condition: .none)
  static let tcaCoordinator = TargetDependency.external(name: "TCACoordinators", condition: .none)
  static let concurrencyExtras = TargetDependency.external(name: "ConcurrencyExtras", condition: .none)
}

이제 각 모듈에서 이렇게 쓸 수 있어요:

dependencies: [
  .SPM.composableArchitecture,  // 깔끔!
  .SPM.weaveDi,                // 오타 걱정 없음!
  .SPM.asyncMoya              // 자동완성 됨!
]

진짜 편해요!

제가 주로 쓰는 라이브러리들

라이브러리	용도	개인적 평가
ComposableArchitecture	TCA 아키텍처	⭐⭐⭐⭐⭐ (강추!)
ConcurrencyExtras	Swift Concurrency 확장	⭐⭐⭐⭐ (LockIsolated 짱)
Collections	고성능 컬렉션	⭐⭐⭐⭐ (Deque 좋음)
TCACoordinators	화면전환 관리	⭐⭐⭐⭐ (TCA 쓰면 필수)
AsyncMoya	네트워킹	⭐⭐⭐ (직접 만든 거라..)
WeaveDi	DI	⭐⭐⭐ (심플함)

진짜 솔직한 후기

좋은 점들:

한 곳에서 모든 의존성 관리: 진짜 깔끔함
프로젝트 설정 버전관리: Git으로 관리되니까 좋음
팀 작업 시 충돌 없음: Xcode 파일 merge 지옥에서 해방!
빌드 최적화: 모듈별로 빌드해서 빠름

아쉬운 점들:

초기 세팅 복잡: 처음 할 때 좀 헤맸어요
러닝커브: Swift 코드로 프로젝트 설정하는 게 처음엔 어색함
업데이트: 너무 자주 됨

꿀팁들

1. 점진적으로 도입하세요

기존 프로젝트에 갑자기 도입하면 멘탈 터져요. 새 모듈부터 시작하시길!

2. 템플릿 만들어두세요

비슷한 모듈 구조 계속 만들 거면 템플릿 만들어두면 편해요.

3. 캐시 활용하세요

빌드 빨라지려면 캐시 필수예요. Tuist Cloud도 있던데... 아직 안 써봄 ㅋㅋ

마무리

Tuist 진짜 좋은데 처음엔 좀 어려워요. 하지만 한번 익숙해지면 다른 걸로 못 갑니다!

특히 팀 프로젝트할 때 프로젝트 파일 충돌 나는 거 진짜 스트레스였는데, Tuist 쓰고 나서 그런 걱정 없어졌어요.

아직 안 써보신 분들은 토이프로젝트부터 시작해 보세요! 금방 매력에 빠질 거예요 ㅋㅋㅋ

다음 글 예고: Plugin 만들기, 고급 설정들 다뤄볼 예정입니다!

작성자: iOS 운영진 서원지

GitHub: https://github.com/Roy-wonji

[iOS] 당연하게 쓰던 메서드에게 뒤통수 맞아보기

dynamic-ddd — Tue, 6 Jan 2026 03:44:27 +0900

들어가며

안녕하세요, 사이드 프로젝트 DDD 동아리의 iOS 운영진 은표입니다.

이번에 동아리에서 새로운 기수를 맞아 운영진들끼리 여러 팀을 구성하게 되었습니다. 저는 콘텐츠 브랜딩 팀에 소속되어 블로그 글을 작성하게 되었는데요. 마침 제가 첫 글이네요. 부담이 살짝 되기도 합니다 ㅋㅋㅋ

글 주제 선정에 대해서 참 고민이 많았습니다. 요즘 많은 LLM이 시장에 나와있고 궁금한 건 LLM을 통해 웬만해서 다 해결되는 시대라, 점점 가면 갈수록 질문을 할 기회도 적어지고 제가 속해있던 커뮤니티들도 점점 잠잠해지더라구요.

또, 뻔한 주제는 작성하기는 너무 싫었습니다. 클린 아키텍처 같은거요. 헥사고날이면 모를까 개념만으로 존재하고, 각자 구현 방법이 조금씩은 다르니까요. 그렇다고 제가 작성하는 코드가 그렇게까지 클린한 것 같지도 않기도 하구요.

클린한 코드를 작성하는 방법은 다른 멋진 개발자 분들께서 잘 작성해주시니, 저는 이번 글에서는 우리가 평소에 너무나 당연하게 쓰면서 위험이 존재하는 메서드를 하나 소개하고 개선하는 방법을 소개해볼까 합니다.

hackingwithswift 라는 플랫폼을 아시나요? 저는 예전에는 가끔 들어가서 아티클들을 읽었었는데요, 서두에 말씀드렸듯이 LLM이 발전함에 따라 서서히 안보게 되던 플랫폼 중 하나입니다. 오랜만에 갑자기 눈에 들어서 아티클을 하나 읽었는데 이 내용을 조금 더 살을 붙여 공유드리려고 합니다.

본론을 위한 밑밥깔기

서론이 꽤나 길었죠? 제가 생각보다 말이 많네요. 오랜만에 글이란걸 써봐서 그래요 이해해주세요

이제 어떻게 보면 너무 뻔하고 지루한 글을 작성할겁니다. iOS 개발을 조금 하셨거나, 컴퓨터 공학을 전공했다면 너무나 당연한 이야기를 하려고 합니다.

(Objective-C 이야기도 조금 섞여 있으니 아조씨들도 나가지말고 읽어주세요.)

iOS 개발자라면 보통 Swift를 사용하실건데요.

Swift를 사용한다면 어떻게 해서든 자연스럽게 String을 사용하게 됩니다.

여러분은 String이 어떤 구조를 가지고 있는지 아시나요?

Apple 공식 문서

공식 문서를 보면 character들의 모음을 String이라고 부르네요! 근데 Unicode 라는 단어가 나옵니다.

유니코드(Unicode)가 무엇이고 왜 생겨났을까요?

전 세계의 모든 문자를 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 국제 표준

나라나 시스템마다 다른 문자 인코딩 방식(예: ASCII, EUC-KR)을 사용하는데요! (ASCII는 많이들 들어보셨죠?)

다른 시스템끼리 문서 같은걸 주고 받으면 글자가 깨지는 현상을 겪어보신 분들도 계실거에요. 이 문제를 해결하기 위해 유니코드가 생겨났어요!

그래서 유니코드로 어떻게 해결했냐면, 생각보다 간단합니다. 이 세상의 모든 문자, 기호, 이모티콘 등에 고유한 번호를 매겨주는겁니다.

예를 들어, 'A'는 U+0041, '가'는 U+AC00 과 같은 고유한 번호를요!

유니코드를 통해 우리는 한글, 영어, 일본어, 한자, 아랍어 등등등... 대부분의 문자를 하나의 체계로 통합하여 다룰 수 있게 됩니다.

이 고유한 번호들을 바이트로 변환하는 작업을 인코딩이라고 부르며 UTF-8, UTF-16과 같은 방법들이 있습니다. 그 중 UTF-8은 가장 널리 사용되는 방식이죠.

근데 왜 갑자기 유니코드 이야기를 이렇게 길게 했냐구요?

바로 오늘 이야기할 주제가 유니코드로 인하여 발생되는 문제이기 때문입니다.

본론 시작

다들 프로젝트 진행하면서나 코딩테스트 문제를 풀 때 replacingOccurrences(of:with:) 메서드, 한번쯤은 써보거나 본 적 있으시죠? (없어도 있다고 해주세요.)

이 메서드는 크게 설명드릴게 없습니다. 문자열에서 특정 문자열을 찾아, 원하는 문자열로 바꾸고 싶을 때 사용하죠.

그럼 이 메서드를 사용할 때 어떤 문제가 발생할 수 있는지 한번 볼까요?

let vacation: String = " " // 캐나다와 미국 국기

여기 두 개의 국기 이모티콘으로 이루어진 문자열이 있습니다.

만약 이 문자열에서 있지도 않은 호주 국기( )를 니카라과 국기( )로 바꾸려고 시도하면 어떻게 될까요?

print(vacation.replacingOccurrences(of: " ", with: " "))

우리는 당연히 호주 국기는 없으니까 아무것도 안 바뀌고 " "가 그대로 나오겠지? 싶잖아요?

그런데 결과는 아래와 같이 표시됩니다.

" "

아니 캐나다, 미국 국기였는데 갑자기 중국과 아이슬란드 국기가 튀어나왔어요! 왤까요?

원인 분석

사실 replacingOccurrences(of:with:) 메서드는 Swift Native 메서드가 아니에요.

Objective-C 시절부터 있던 고인물 메서드입니다. 그리고 이 고여버린 메서드는 우리가 앞에서 이야기했던 유니코드를 제대로 이해하지 못하고 처리하지 못합니다.

국기 이모티콘은 사실 두 개의 특수한 유니코드 문자가 합쳐져서 만들어져요.

- 는 'C'와 'A'를 나타내는 특수 문자의 조합입니다.
- 는 'U'와 'S'를 나타내는 특수 문자의 조합이고요.

즉, " "라는 문자열은 내부적으로는 [C, A, U, S] 라는 4개의 특수 문자로 이루어져 있는 셈이죠.

여기서 문제가 발생합니다. 우리가 바꾸려던 호주 국기 는 [A, U] 문자 조합이거든요. Objective-C의 낡은 메서드는 이걸 글자가 아니라 그냥 바이트 덩어리로 보고, "CAUS" 중간에 있는 "AU"를 찾아내버리게 됩니다.

그리고 찾아낸 "AU"를 니카라과 국기 의 조합인 [N, I]로 바꿔치기합니다.

그 결과, 원래 [C, A, U, S] 였던 문자열은 [C, N, I, S] 로 바뀌게 되고,

Swift가 이 새로운 문자 조합을 다시 화면에 표시하려고 보니...

- [C, N]은 중국 국기
- [I, S]는 아이슬란드 국기

로 끔찍한 결과가 나와버린 겁니다.

Swift 좋아.

해결책

다행히 해결책은 정말 너무나 쉽습니다. Swift가 제공하는 최신 네이티브 메서드를 쓰면 됩니다.

사용법도 너무 쉽습니다.

print(vacation.replacing(" ", with: " "))

이 메서드는 설계 단계부터 유니코드를 완벽하게 이해하고 만들어졌기 때문에, 와 를 각각 하나의 의미 단위(글자)로 정확하게 인지합니다.

그래서 그 안에 호주 국기 가 통째로 들어있지 않다는 걸 정확히 알고, 아무것도 바꾸지 않은 채 원래 문자열 " "을 그대로 반환해 주죠.

이게 우리가 상상하고 원했던 결과잖아요?

근데 앞에서 말은 길게 써놓고 해결책은 간단해서 어이없죠?

문제가 하나 있어요. (저한테만 있을 수도)

✨ 최소 지원 버전 ✨

사실 사이드 프로젝트면 문제없는데요, 저희 회사는 iOS 9도 지원하거든요? 아 이거 절대 못쓰죠.

그럼 iOS 15 이하 환경에서는, 한땀한땀 가내수공업 말고 없을까요?

예. 그것이 iOS 개발이니까.

iOS 15 이하 대응해주기

결과만 필요하신 분들을 위해 코드부터 드리고 시작하겠습니다.

코드에 대한 상세 설명은 아래에서 진행할게요!

extension String {
  func replacingCompat(
    _ target: String,
    with replacement: String,
    maxReplacements: Int = .max
  ) -> String {
    if #available(iOS 16.0, *) { // 선택 사항
      return replacing(target, with: replacement, maxReplacements: maxReplacements)
    }

    guard !target.isEmpty, maxReplacements > 0 else { return self }

    var result = ""
    result.reserveCapacity(utf8.count)

    var searchStart = startIndex
    var replaced = 0

    while replaced < maxReplacements,
          let r = range(of: target, range: searchStart..<endIndex) {

      result.append(contentsOf: self[searchStart..<r.lowerBound])
      result.append(contentsOf: replacement)

      replaced += 1
      searchStart = r.upperBound
    }

    result.append(contentsOf: self[searchStart..<endIndex])
    return result
  }
}

replacingCompat(_:with:maxReplacements:)이라는 메서드를 하나 만들었습니다. 이 메서드는 3개의 파라미터를 받습니다.

target: 찾아 바꿀 문자열
replacement: target 대신 들어갈 새로운 문자열
maxReplacements: 최대 몇 번까지 바꿀지 정하는 횟수(기본값은 .max로, 제한 없음을 의미합니다.)

방금 전에 보았던 iOS 16+의 String.replacing(_:with:maxReplacements:)와 동일한 파라미터를 받아 호환되도록 했습니다.

1. 예외 처리 (Early Exit)

본격적인 작업에 앞서, 굳이 실행할 필요가 없는 예외 케이스를 미리 처리합니다.

guard !target.isEmpty, maxReplacements > 0 else { return self }

!target.isEmpty: 찾아야 할 target이 비어있으면 작업을 수행할 수 없으므로 바로 종료합니다.
maxReplacements > 0: 바꿔야 할 횟수가 0번이면 아무것도 할 필요가 없으므로 바로 종료합니다.
return self: 위 조건 중 하나라도 해당되면, 아무것도 바꾸지 않고 원본 문자열(self)을 그대로 반환합니다.

2. 결과 변수 준비 및 최적화

교체 결과를 담을 새로운 문자열을 만들고, 성능을 위해 메모리를 미리 준비합니다.

var result = ""
result.reserveCapacity(utf8.count)

var result = "": 교체 작업의 결과를 차곡차곡 쌓아나갈 새로운 빈 문자열 result를 만듭니다.
result.reserveCapacity(utf8.count): (성능 최적화) result 문자열에 내용이 추가될 때마다 메모리를 새로 할당하는 비효율을 막기 위해, 미리 원본 문자열(self)의 크기만큼 메모리 공간을 예약합니다.

3. 반복문 상태 변수 초기화

반복문을 제어하기 위한 변수들을 설정합니다.

var searchStart = startIndex
var replaced = 0

var searchStart = startIndex: target을 찾기 시작할 위치를 저장하는 변수입니다. 처음에는 당연히 문자열의 맨 앞(startIndex)에서 시작합니다.
var replaced = 0: 지금까지 몇 번 교체했는지 횟수를 세는 변수입니다. maxReplacements와 비교하기 위해 사용됩니다.

4. 핵심 반복문 (target 검색)

target을 찾고 교체하는 핵심 작업을 반복 수행합니다.

while replaced < maxReplacements,
	let r = range(of: target, range: searchStart..<endIndex) {

replaced < maxReplacements: 교체 횟수가 maxReplacements보다 적을 때.
let r = range(of: target, range: searchStart..<endIndex): (핵심 로직) searchStart 위치부터 문자열 끝(endIndex)까지의 범위에서 target을 검색합니다.
- 성공 시: target을 찾으면 그 위치 범위(Range)가 r에 저장되고 while문 안의 코드가 실행됩니다.
- 실패 시: 더 이상 target을 찾지 못하면 nil이 반환되어 while문이 종료됩니다.

5. 찾은 내용 교체 및 상태 갱신 (반복문 내부)

target을 성공적으로 찾았을 때 실행되는 로직입니다.

result.append(contentsOf: self[searchStart..<r.lowerBound])
result.append(contentsOf: replacement)

replaced += 1
searchStart = r.upperBound

result.append(contentsOf: self[searchStart..<r.lowerBound]): result에 (이전 탐색 위치 ~ 방금 찾은 `target`의 시작 위치 바로 앞)` 까지의 문자열을 먼저 붙여넣습니다. (즉, 건드리지 않을 부분을 그대로 복사)
result.append(contentsOf: replacement): 그 다음, target이 있던 자리에 replacement 문자열을 이어서 붙입니다.
replaced += 1: 교체를 한 번 완료했으므로, 횟수를 1 증가시킵니다.
searchStart = r.upperBound: (가장 중요한 부분) 다음 검색은 방금 찾은 target의 끝나는 지점 바로 다음에서 시작하도록 searchStart 위치를 갱신합니다. 이것이 무한 루프와 비효율적인 중복 검색을 막는 핵심입니다.

6. 마무리 및 반환

반복문이 끝나고 남은 부분을 처리한 뒤, 최종 결과를 반환합니다.

result.append(contentsOf: self[searchStart..<endIndex])
return result

result.append(contentsOf: self[searchStart..<endIndex]): while 반복문이 모두 끝난 후, 마지막으로 찾았던 위치부터 문자열의 맨 끝까지 남아있던 부분을 result에 마저 붙여줍니다. (만약 target을 한 번도 못 찾았다면, searchStart는 여전히 startIndex이므로 이 라인에서 원본 문자열 전체가 복사됩니다.)
return result: 이렇게 완성된 새로운 문자열 result를 최종적으로 반환합니다.

‍♂️ 마무리

오랜만에 써보지만 블로그 글 쓰는건 언제나 힘든 것 같습니다. 매번 꾸준히 글 쓰시는 분들 정말 존경합니다.

관련 지식이 크게 없는 분들도 이해시켜드리기 위해서 최대한 상세히 작성은 했지만, 읽으시기 쉬울지는 잘 모르겠습니다.

그래도 조금이나마 도움이 되었으면 좋겠습니다. 아니면 흥미를 느꼈거나 재미라도 있으셨다면 만족합니다.

긴 글 읽어주셔서 감사합니다!

참고

One Swift mistake everyone should stop making today

TL;DR: You should use replacing(_:with:) rather than replacingOccurrences(of:with:)

www.hackingwithswift.com

✍️ 작성자: 은표

직군: iOS Developer
GitHub: https://github.com/honghoker