DEVOCEAN

들어가며

안녕하세요. SK텔레콤 AI Assistant iOS팀 김승찬입니다.

저는 에이닷 서비스 내 활용되는 디자인 시스템을 개발 및 관리하고 있습니다.

이번에 신규 디자인 시스템을 구축하면서 많은 기술적 고민들이 있었는데요.

이런 고민들을 해결했던 저만의 방법들을 공유드리기 위해 포스팅을 진행하려고 합니다.

첫번째 주제는 Swift Package Manager를 이용한 안정적인 라이브러리 배포 전략입니다.

포스팅은 다음과 같은 순서로 진행될 예정입니다.

• 라이브러리 배포 전략이 필요한 이유

• Semantic Versioning 이란?

• Swift Package Manager: Dependencies

• Swift @Available attribute

라이브러리 전략이 필요한 이유

UX 컨설팅으로 저명한 Neilsen Norman Group의 정의에 따르면,

디자인 시스템이란 재사용 가능한 컴포넌트와 패턴을 활용하여 대규모 디자인을 관리하기 위한 표준 집합 을 의미합니다.

Design Systems 101 (NN/g)

디자인 시스템이란 무엇인가

다양한 팀에서 공통의 언어를 사용하여 시각적 일관성을 만들기 위해,

저는 AdotCoreDesign 이라는 디자인 패키지를 활용하여 공통 스타일/컴포넌트 인터페이스를 배포하고 있습니다.

에이닷이 업데이트되고 신규 기능이 추가되면서, 디자인 시스템 내부에서도 자연스럽게 변화가 생기게 되는데요.

업데이트 된 디자인 시스템이 여러 프로젝트에서 안정적으로 적용되기 위해서는,

시스템 관리자는 하위 호환성을 고려한 버전 관리 전략을 수립하고 이에 맞는 인터페이스를 제공해야 합니다.

Semantic Versioning 이란?

Semantic Versioning은 패키지의 버전 번호를 어떻게 정하고 올려야 하는지에 대한 규칙과 요구사항을 정리해놓은 버전 관리 방식입니다.

시스템 규모가 커지고, 많은 패키지를 사용할수록 의존성이 중요해지게 되는데요. 이러한 규칙들을 통해 업데이트 된 API 변경 사항을 예상하고 적절하게 버전 관리를 할 수 있습니다.

• 메이저 버전 (1.x.x) : 기존 버전과 호환되지 않게 API가 변경됨.

• 마이너 버전 (x.1.x) : 기존 버전과 호환되면서 새로운 기능이 추가됨.

• 패치 버전 (x.x.1) : 기존 버전과 호환되면서 버그를 수정함.

• 프리 릴리즈 (x.x.x-pre) : (아직 불안정한) 정식 배포 전 버전

Semantic Versioning 을 사용하여 버전 관리를 했을 경우, 개발팀과의 의사소통에는 문제가 없었습니다.

하지만 디자인팀에서도 (Figma 가이드 배포 시) 버전 관리 규칙이 있었기 때문에, 개발 버전에 반영되었는지 확인 시에 어려움이 있었습니다.

(Figma) 2.0.1 버전 반영사항은 (SDK 기준) 1.3.12 버전에 반영되었습니다.

이러한 버전 차이는 앞으로도 더 벌어질 것이라고 판단했고, 개발/디자인 팀 사이의 커뮤니케이션 비용을 늘릴 것이라고 예상했습니다.

그래서 커뮤니케이션 오류를 줄일 수 있도록 major.minor.patch 버전은 동일하게 사용하고,

pre-release 라벨을 통하여 개발 반영사항을 전달하도록 관리하고 있습니다.

이러한 전략을 통해 개발/개발, 개발/디자인 팀 모두와 원활하게 커뮤니케이션 할 수 있었습니다.

Swift Package Manager: Dependencies

Swift Package Manager의 의존성 관리 시에, 앞서 소개드린 Semantic Versioning를 활용하여 버전 관리를 할 수 있습니다.

// Package.swift

let package = Package(
    name: "MyPackage",
    // 의존성 관리
    dependencies: [
        .package(url: "https://gitlab.com/owner/repo", from: "1.0.0"),
    ],
    targets: [
        .target(
            name: "MyPackage",
            dependencies: ["DependencyLibrary"]),
    ]
)

package.swift 파일 내부에 dependencies 섹션에서 패키지의 버전을 관리할 수 있습니다. Swift 에서는 다양한 버전 범위 관리 방법을 제공하고 있습니다.

from

.package(url: "https://gitlab.com/owner/repo", from: "1.0.0")

• from 키워드는 특정 버전 이상의 패키지 버전을 사용할 때 사용됩니다.

• 하지만 상위 메이저 버전은 포함되지 않도록 제한합니다.

• 버전 범위: 1.0.0 ≤ version < 2.0.0

range

.package(url: "https://gitlab.com/owner/repo", "1.0.0"..<"2.0.0")

• range를 활용하여 패키지 버전의 범위를 나타낼 수 있습니다.

• 시작 버전 이상, 끝 버전 미만의 범위를 정의합니다.

• 버전 범위: 1.0.0 ≤ version < 2.0.0

exact

.package(url: "https://gitlab.com/owner/repo", exact: "1.0.0")

• 특정 버전만을 사용하도록 제한합니다.

• 패키지의 버전이 반드시 지정된 버전과 일치해야 할 때 사용합니다.

• 버전 범위: 1.0.0

upToNextMinor

.package(url: "https://gitlab.com/owner/repo", .upToNextMinor(from: "1.0.0"))

• 마이너 버전에서만 업데이트를 허용하며, 메이저 버전 변경은 방지합니다.

• 기능 개선과 버그 수정은 적용하면서, 큰 변경 사항은 포함되지 않도록 설정할 수 있습니다.

• 버전 범위: 1.0.0 ≤ version < 1.1.0

upToNextMajor

.package(url: "https://gitlab.com/owner/repo", .upToNextMajor(from: "1.0.0"))

• 마이너 업데이트와 패치 업데이트는 허용하되, 메이저 버전 변경은 허용하지 않습니다.

• 버전 범위: 1.0.0 ≤ version < 2.0.0

branch / revision

.package(url: "https://gitlab.com/owner/repo", branch: "feature-branch")
.package(url: "https://gitlab.com/owner/repo", revision: "d1e2f3g")

• 특정 브랜치나 커밋을 의존성으로 지정합니다.

• 개발 중이거나 실험적인 코드를 사용해야 할 때 유용합니다.

에이닷 앱 내부에서 디자인 업데이트가 잘 적용되었는지 체크해야 하는 경우가 빈번한데요.

이러한 경우에는 branch / revision을 활용하여, 임시로 패키지를 적용해본 뒤에 배포를 하고 있습니다.

기본적인 세팅은 range 방식을 활용하여, 패치 뒤쪽의 rc.x의 업데이트는 적용하면서도 스프린트 내 최종 버전 (ex. 1.1.0) 이상은 넘어가지 않도록 관리하고 있습니다.

Swift @available attribute

아무리 SPM을 통해 철처하게 버전 관리를 한다고 하더라도, major 업데이트는 사용자 입장에서는 항상 당황스러울 수 밖에 없습니다.

특히나 유용하게 사용중이던 API가 업데이트로 제거된다면 매우 곤란한 상황이 생길 수 있습니다.

이러한 변경/제거 시에 사용자가 마음의 준비를 할 수 있도록, swift는 @available 이라는 attribute를 제공하고 있습니다.

해당 attribute 를 이용하여, 빌드 시 런타임에 사용자에게 deprecated 메시지를 전달할 수 있습니다.

@available(*, deprecated, message: "[1.0.0] 버전 이후 제거될 예정입니다.")
func oldMethod() {
    // 1.0.0 이후로는 사용되지 않음
}

공식 문서 기반으로 검색해보니 플랫폼, iOS 버전 별로도 API 가용성 제어가 가능했습니다.

하지만 현재까지 디자인 시스템에서는 iOS 버전에 따른 버전분기를 하고 있지 않기 때문에, 해당 옵션은 추가하지 않고 사용하고 있습니다.

마치며

지금까지 Swift Package Manager를 이용한 안정적인 라이브러리 배포 전략 을 주제로 다양한 버전, 의존성 관리법을 소개드렸는데요.

안정적인 배포 전략을 고민하면서 느꼈던 점은, 체계적인 관리 전략을 도입하는 것도 중요하지만,

함께 일하는 동료들과 이런 전략들을 공유하고 커뮤니케이션 오류를 줄이는 것이 무엇보다 중요하다 이었습니다.

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