호댕의 iOS 개발

[Widget] 위젯 사용자화 틴트 처리됨(tinted) 대응하기 (위젯이 흰 화면으로만 보인다...)

호르댕댕댕 — Tue, 11 Mar 2025 18:44:40 +0900

틴트 처리됨이 뭐지?

iOS 18에는 홈화면 편집에서 사용자화라는 부분이 새롭게 등장했다.

여기서 앱 아이콘 및 폴더의 색상을 변경할 수 있는 틴트 처리됨 이라는 기능이 새롭게 등장했다.

홈 화면을 롱프레스로 누른 후 좌측 상단 편집 버튼을 누르면 접근이 가능하다.

https://support.apple.com/ko-kr/guide/iphone/iph385473442/ios

iPhone 홈 화면에서 앱 및 위젯 사용자화하기

iPhone의 홈 화면에서 앱 및 위젯의 색상 및 크기를 변경할 수 있습니다.

support.apple.com

안드로이드에선 이전부터 되던 기능들이 이제서야 되는 것이었지만 새로운 기능을 제공하는 것은 좋은 것이지라고 WWDC를 보며 생각을 했었는데...

문제 상황

틴트 처리됨을 통해 틴트 색상을 먹인 사용자의 경우 위젯이 하얀 색으로 아무 콘텐츠도 보이지 않는 문제가 발생했다.

T맵의 위젯처럼 아무 콘텐츠도 보이지 않는데 웃긴건 탭 이벤트는 또 제대로 동작한다. 정말 보여지는 뷰만 문제가 있는 것이다

그렇다면 이 문제는 어떻게 해결하면 좋을까...?

해결방법

widgetAccentable()

애플에선 iOS 16버전부터 적용이 가능한 해결책을 제공해주고 있었다.

https://developer.apple.com/documentation/swiftui/view/widgetaccentable(_:)

widgetAccentable(_:) | Apple Developer Documentation

Adds the view and all of its subviews to the accented group.

developer.apple.com

이는 WidgetKit의 WidgetRenderingMode가 기본인 경우(fullColor) / 틴트 처리된 경우(accented)로 나눠서 다른 색상을 적용해 뷰를 그리게 된다.

이를 상위 뷰에 적용하게 되면 하위 뷰까지 전부 적용된다.

여기서 주의할 점은 한 번 widgetAccentable(true)를 적용하게 되면 추후 widgetAccentable(false)를 적용하더라도 accented를 위한 그룹에서 해당 뷰를 포함한 하위 뷰가 빠지지 않게 된다.

일단은 이걸 적용하게 되면 일차원적인 해결은 가능하다.

단순히 위젯이 텍스트 위주로 되어 있는 간단한 위젯이라면 요것만 적용해주면 잘 해결될 수 있다.

widgetAccentable()을 사용하며 발생했던 문제

뷰가 만약 아래 코드처럼 구성이 되어 있다고 해보자

ZStack {
    Color.black
    CustomView()
    	.foregroundColor(Color.white)
}

아주 간단하게 검은 배경에 흰 배경을 가진 커스텀 뷰가 있는 화면이다. 커스텀 뷰에는 간단한 리스트가 있었다고 가정해보자.

그런데 만약 여기서 widgetAccentable()을 ZStack에 먹인다면?

ZStack {
    Color.black
    CustomView()
    	.foregroundColor(Color.white)
}
.widgetAcceptable()

틴트 컬러를 먹이게 되면

위 미리보기 화면처럼 컨텐츠가 보이지 않고 CustomView 영역 전체가 tint color로 바뀌게 된다.

그래서 이 경우 ZStack을 따로 사용하지 않고, CustomView에 background Color를 주는 방식으로 수정을 했다.

CustomView() // 내부에서 backgroundColor 변경
    .foregroundColor(Color.white)
    .widgetAcceptable()

이렇게 되면 원했던 것처럼 내부 콘텐츠도 제대로 보이게 된다.

ZStack 전체에 걸어주게 되면 하위 뷰 전체에 accent color가 적용되면서 배경에도 accent color가 적용되어 이런 문제가 발생했던 것 같다.

틴트 컬러의 변경이 있을 때마다 즉각적으로 콘텐츠도 이에 맞춰 변경된다.

만약 앱이 iOS 16 미만의 Deployment Target을 가지고 있다면?

앞서 말했듯 widgetAcceptable()의 경우 iOS 16이상부터 지원을 하고 있다.

그렇다고 매번 if #available(iOS 16, *) 이렇게 분기 코드를 만들어 뷰를 만들면 복잡도가 너무 높아진다.

그래서 나는 커스텀 ViewModifier를 활용했다.

struct CustomWidgetRenderingModeModifier: ViewModifier {
    func body(content: Content) -> some View {
        if #available(iOS 16.0, *) {
            content
                .widgetAccentable()
        } else {
            content
        }
    }
}

코드는 간단하다. 내부 body 함수에서 버전 분기를 해서 16 미만인 경우 그대로 원래 뷰를 반환하고, 16 이상인 경우 .widgetAccentable()을 적용하는 코드이다.

틴트 처리됨은 iOS 18부터 제공하는 기능이기 때문에 16부터 버전 분기를 하지 않고 iOS 18을 기준으로 분기를 해줘도 무방할 것 같다.

그럼 .widgetAccentable()을 사용했던 것과 유사하게 사용이 가능하며 버전 분기도 매번 필요하지 않게 된다.

CustomView()
    .foregroundColor(Color.white)
    .modifier(CustomWidgetRenderingModeModifier())

widgetRenderingMode 환경변수

Text에 background를 주는 경우 Text의 영역만큼 TintColor로 채워지는 문제

예시는 카카오맵의 위젯이다.

기존에는 Text가 있고 Background에 색이 칠해져있는 뷰이다.

어떻게 구현되어 있는지는 직접 카카오맵 앱 코드를 확인해보진 않았지만 나도 이와 유사한 문제를 겪게 되었다.

문제의 원인은 이전 ZStack 전체에 .widgetAccentable()을 적용했을 때와 동일한 원인이라고 판단했다.

그렇다면 이걸 해결하기 위해선 내가 직접 accented / fullColor에 따라 각기 다른 뷰를 반환할 필요가 있었다.

그래서 widgetRenderingMode를 사용해야 했다.

WidgetRenderingMode 또한 iOS 16부터 등장했다.

https://developer.apple.com/documentation/widgetkit/widgetrenderingmode

WidgetRenderingMode | Apple Developer Documentation

Constants that indicate the rendering mode for a widget.

developer.apple.com

이는 아래 환경 변수를 통해 가지고 올 수 있다.

@Environment(\.widgetRenderingMode) var widgetRenderingMode

이는 3가지 Case가 존재한다.

.accented : 틴트 적용됨을 선택한 상태
.fullColor : 일반적인 다크모드 / 일반모드를 선택한 상태
.vibrant : 잠금화면 위젯에서만 사용됨

그렇다면 우리는 widgetRenderingMode가 .accented일 때와 아닐 때로 구분해서 서로 다른 뷰를 전달시키면 된다.

(accented일 때에는 Text에 background Color가 없고, 아닐 때에는 있도록)

일단 우리는 홈화면에 띄우는 일반적인 위젯을 보고 있기 때문에 vibrant는 논외로 보자.

그런데 나는 iOS 16 미만의 Deployment Target을 가지고 있다...

그래서 처음에는 이런 계산 프로퍼티를 활용하면 되지 않을까란 생각을 했었다.

@available(iOS 16, *)
private var widgetRenderingMode: WidgetRenderingMode {
    @Environment(\.widgetRenderingMode) var widgetRenderingMode
    return widgetRenderingMode
}

흠.. 그런데 이렇게 하는 경우 항상 widgetRenderingMode가 .fullColor로 반환이 된다...

정확한 이유는 모르겠지만 계산프로퍼티 내부에 환경 변수를 선언하면 제대로 값일 가지고 오지 못했다.

그래서 특정 버전 위에서 사용할 수 있는 커스텀 뷰와 특정 버전 이하에서 사용할 커스텀 뷰를 각각 만들었다.

@available(iOS 16, *)
struct CustomTextOveriOS18: View {
	@Environment(\.widgetRenderingMode) var widgetRenderingMode

	var body: some View {
    	if widgetRenderingMode == .accented {
        	Text("Hello")
                .font(.largeTitle)
                .foregroundColor(.white)
                .background(
                    RoundedRectangle(cornerRadius: 4)
                        .strokeBorder(Color.white, lineWidth: 1) // Color는 tint가 먹혀서 크게 중요 X
                )
        } else {
        	Text("Hello")
                .font(.largeTitle)
                .foregroundColor(.white)
                .background(
                    Color.orange
                )
        }
    }
}

struct CustomText: View {
    var body: some View {
    	Text("Hello")
                .font(.largeTitle)
                .foregroundColor(.white)
                .background(
                    Color.orange
                )
    }
}

그리고 사용할 때 버전 분기를 해서 각 뷰를 반환할 수 있도록 하면 이제 환경변수를 제대로 들고와서 사용자 설정 상태에 따라 뷰를 다르게 그릴 수 있게 된다.

그러면 이런 식으로 Text도 잘 보이면서 틴트도 제대로 먹일 수 있다.

흠... 그런데 만약 정말 background Color가 꼭 필요한 상황이라면..?

아예 해당 부분을 이미지로 대체하거나, background Color에 opacity를 줘야 할 것 같은데 opacity를 주는 방법은 직접 테스트를 해보진 못했다.

widgetAccentedRenderingMode

이미지가 제대로 tintColor가 적용되지 않는 문제

틴트 적용됨을 적용한 경우 이미지가 형태는 보이되 내부 디테일의 차이 없이 동일한 컬러로 채워져 있을 수 있다.

이 경우 사용할 수 있는 것이 바로 widgetAccentedRenderingMode이다. 이는 Image의 인스턴스 메서드로 이미지에서만 사용이 가능하다.

이건 iOS 16부터 사용할 수 있는 다른 것들과 다르게 iOS 18 이상부터 사용할 수 있는 따끈따끈한 함수/구조체이다.

여기서 중요한 점은 만약 Image의 상위 뷰에 .widgetAccentable()을 적용했다면 widgetAccentedRenderingMode 적용이 제대로 되지 않을 수 있다.

https://developer.apple.com/documentation/widgetkit/widgetaccentedrenderingmode

WidgetAccentedRenderingMode | Apple Developer Documentation

Constants that indicate the rendering mode for an in when displayed in a widget in mode.

developer.apple.com

https://developer.apple.com/documentation/swiftui/image/widgetaccentedrenderingmode(_:)

widgetAccentedRenderingMode(_:) | Apple Developer Documentation

Specifies the how to render an when using the mode.

developer.apple.com

.accented : 기본 상태로 이미지 내부 디테일 없이 tint color가 적용된다.

.accentedDeceturated : tint color는 적용되지만, 이미지의 디테일은 유지된다.

.deceturated : 원래 이미지 컬러와 유사하지만 채도가 약간 빠진 것처럼 보이게 된다.

.fullColor : 원래 이미지 컬러 그대로를 보여준다.

틴트 컬러는 적용이 되는 것이 사용자 설정 상태에 맞다고 판단했고 나는 .accentedDeceturated 옵션을 선택했다.

struct ImageView: View {
    var body: some View {
        if #available(iOS 18, *) {
            Image(systemName: "star")
                .widgetAccentedRenderingMode(.accentedDesaturated)
        } else {
            Image(systemName: "star")
        }
    }
}

그래서 코드로 보면 이런 식으로 처리를 했다.

이 정도가 내가 확인했던 문제들과 해결 방법이다.

참고 자료

- https://nemecek.be/blog/206/how-to-support-tinted-home-screen-widgets-in-ios-18

How to support tinted home screen widgets in iOS 18

Marking views to be rendered with colors, handling images and more.

nemecek.be

- https://www.createwithswift.com/adapting-widgets-for-tint-mode-and-dark-mode-in-swiftui/

Adapting widgets for tint mode and dark mode in SwiftUI

Explore the multiple rendering modes of widgets for different device settings with SwiftUI.

www.createwithswift.com

[Appsflyer Push] Safari에서 앱이 설치되고도 앱으로 redirect되지 않는 문제

호르댕댕댕 — Wed, 10 Jul 2024 12:03:44 +0900

오랜만에 블로그 글로 돌아왔습니다.

문제 상황

현재 Safari에 한정해서 앱이 설치되고도 앱으로 redirect되지 않고 항상 앱스토어로 넘어가는 문제가 있었음.

해결방안

해결방안은 의외로 간단했습니다.

Appsflyer OneLink 공식문서에 보면 af_force_deeplink라는 Attribution link parameters가 존재합니다.

iOS는 URI Scheme으로만 앱을 여는데 제한이 있어 해당 파라미터 값을 true로 주면 Safari에서도 앱을 연다는 Alert가 나온 후 앱이 열리게 됩니다.

[Fastlane] Fastlane Match 도입해보기 (계속된 삽질)

호르댕댕댕 — Fri, 19 Apr 2024 17:08:17 +0900

iOS에서 앱을 배포하기 위해선 Code Signing이 필수적이다.

이를 통해 어떤 사람이 해당 앱에 서명을 했는지 식별하고, 서명이 된 이후에는 앱에 변경 사항이 없다는 것을 보증해준다.

(서명은 앱 빌드 & 아카이빙 시 됩니다)

https://help.apple.com/xcode/mac/current/#/dev3a05256b8

To see this page, you must enable JavaScript. Pour afficher cette page, vous devez activer JavaScript. Zur Anzeige dieser Seite müssen Sie JavaScript aktivieren. このページを表示するには、JavaScript を有効にする必要があります。

help.apple.com

즉, 앱을 배포했다면 해당 앱은 해당 버전에선 더 이상 변경 사항이 없다는 것을 보증한다. 그래서 우리는 버그를 만나게 되면 수정 후 다시 심사를 올리고 배포를 하게 되는 것이다.

이를 위해선 Signing Certificate가 사용된다.

이는 Xcode Project의 Target에서 있는 Signing & Capabilities 탭에서 확인해볼 수 있다.

요게 제대로 되어 있지 않으면 빌드 시 컴파일 에러가 발생한다.

(요건 가끔 예제 코드를 받아서 실행시키다보면 만나게 됩니다)

하지만 이런 인증서는 배포의 경우 최대 3개까지만 사용이 가능하다.

즉 프로젝트를 진행하는 인원이 3명이 넘게 되면 이제 인증서에 대한 관리가 빡세지는 것이다.

이외에도 모두가 인증서를 각각 가지고 만료 일자가 되면 갱신도 해줘야 한다.

물론 갱신 같은 작업은 엄청 간단하기 때문에 엄청나게 부담은 아니다. 다만 팀이 커지게 되며 Certificate / Provisioning Profiles를 개별적으로 관리하는 것은 분명한 한계를 지닌다.

(위에서 봤던 인증서 개수의 제한이 가장 명확한 한계점)

이런 상황에서 Fastlane을 사용한다면?

Fastlane match를 사용하면 일단 1개의 certificate와 provisioning profile을 공유해서 사용할 수 있다.

이렇게 하면 팀 전체가 Certificate와 Provisioning Profile의 싱크를 맞출 수 있고, 여기서 발생할 수 있는 문제를 최소화할 수 있다.

(~~다만 나는 설정하는데 꽤나 많은 시간이 걸려서 문제가 최소화된 건지는 잘 모르겠다 ㅎㅎ...~~)

Fastlane에선 certificate와 provisioning profile을 저장하는 공간을 3가지로 제공하고 있다.

Google Cloud
Amazon A3
Git Repository

여기서 나는 가장 많이 사용되는 Git Repository를 활용했다.

그림으로 보면 이런 식으로 Git Repository를 통해 팀이 사용하는 Certificate와 Provisioning Profile을 관리할 수 있는 것이다.

https://codesigning.guide/

Code Signing Guide for Teams

A new approach to code signing A best practices guide on how to manage certificates and provisioning profiles in your development team. Wait, what is code signing? Code signing is required on iOS when distributing your app to customers. It assures that you

codesigning.guide

Fastlane에선 아래와 같은 기능을 사용할 수 있다고 말하고 있다.

Git을 사용해서 모든 팀 멤버들에게 iOS / macOS 키와 profile의 싱크를 맞출 수 있음
인증서와 profile을 생성하고 저장하는 모든 어려운 작업을 처리
새로운 기기에서도 빠르게 Code signing을 설정할 수 있음
여러 target과 bundle identifier가 있는 앱을 작동시킴
다른 서드파티 서비스 없이 file과 Git repo를 관리할 수 있음
✨ Provisioning profile은 항상 일치하는 certificate와 매치가 됨
만료되거나 유효하지 않은 경우 존재하는 profile / 인증서(certificate)를 쉽게 리셋시킬 수 있음
♻️ --force 옵션을 사용해 모든 장치에서 provisioning profile을 자동으로 갱신
다수의 Apple 계정과 팀을 지원할 수 있음

그렇다면 어떻게 사용할까?

지금까지 왜 Fastlane match를 활용해야 하는지와 사용했을 때 얻을 수 있는 이점에 대해 살펴봤다.

하지만 사용할 수 없다면 앞선 내용들은 모두 무용지물이니 요 부분이 가장 중요할 것이다.

요 작업을 하면서 대부분의 사람들은 docs에 나온대로 뚝딱뚝딱 잘 만 하던데 나는 기존 프로젝트에 도입을 해서 그런지, 내가 이런 인프라 설정이 약한 것인지는 모르겠지만... 정말 많은 시행착오를 겪었다.

(아직도 완전히 해결된 것은 아니다... 이게 어떤 사람은 에러 없이 잘 되는데 어떤 사람은 또 안되는 경우도 있고 해서...)

기본적인 Fastlane 설치 방법은 fastlane Docs에 잘 나와있긴 하다.

Setup - fastlane docs

Getting started with fastlane for iOS Setup Xcode for fastlane xcode-select --install Installing fastlane fastlane can be installed in multiple ways. The preferred method is with Bundler. fastlane can also be installed directly through Homebrew (if on macO

docs.fastlane.tools

그리고 기본적으로 fastlane에 대한 기본 셋팅은 이전 프로젝트에 되어 있어서 GemFile / FastFile, AppFile, MatchFile은 설정이 되어 있었다.

기본적인 과정은 공식 문서를 참고해주세요.
아래는 굵직하게 이슈가 있거나 정리해봄직 한 부분을 정리했습니다

새롭게 공용 Certificate & Provisioning Profile을 생성

1. Fastlane 설치

fastlane 설치는 아래 명령어로 간단하게 진행했다.

brew install fastlane

그리고 기분좋게 fastlane match init을 해서 match 설정을 시작하려 하자마자 에러 발생

2. 터미널에 Fastlane match init 명령어 호출

이제 match를 시작하기 위해 요 명령어를 호출했다.

하지만 시작부터 에러 발생 ㅎㅎ....

fastlane match init 시 발생 에러 (Unable to locate Xcode. Please make sure to have Xcode installed on your machine)

Xcode를 현재 2개 사용 중이라 발생했던 에러였다.

15.3에선 Archive로 ipa 파일 추출할 때 강제 종료되는 버그가 있어서 15.2로 다운그레이드 후 다른 프로젝트와 Swift Tool 버전이 맞지 않아 15.3도 따로 사용하고 있었는데 요것 때문에 발생한 에러였다.

Unable to locate Xcode. Please make sure to have Xcode installed on your machine 해결 방안

Xcode > Preference > Location에서 현재 프로젝트에서 사용 중인 Xcode로 변경해주면 에러 해결

여기서 Command Line Tools를 현재 사용 중인 버전에 맞게 골라주면 된다.

여기가 15.3 버전 Xcode로 되어 있어 문제가 발생한 것이었고 이렇게 수정해주고 나면 문제없이 명령어 실행이 됐다.

이후 나오는 것은 일단 자신의 상황에 맞는 옵션 선택만 해주면 잘 됐다.

(저장 위치, 레포 주소 요런 것들을 잘 적어주시면 됩니다)

3. AppFile 확인

Appfile에선 아래와 같은 내용들을 작성한다.

app_identifier : 현재 앱에서 사용 중인 Bundle Identifier
apple_id : 현재 공용으로 생성한 Apple 계정
team_id : Apple Developer에 로그인 후 밑으로 쭉 내리면 멤버십 세부 사항에 있는 팀 ID

itc_team_id : AppStoreConnect에 로그인 후 (링크)를 누르면 확인이 가능합니다. 이렇게 하면 JSON 형식의 데이터를 확인할 수 있는데 여기서 contentProviderId를 확인하면 됩니다.

4. 기존 Provisioning Profile 삭제

최대 3개까지만 사용이 가능하고 이제 더 이상 개인 계정이 아닌 공용 계정을 사용할 예정이기 때문에 기존 Provisioning Profile을 제거하는 것을 권장하고 있습니다.

이는 아래 명령어를 사용하면 아주 쉽게 삭제가 가능하다.

fastlane match nuke development // 개발용
fastlane match nuke appstore // 배포용

흠... 삭제는 아주 쉽게 가능하다.

여기서 username을 묻는데 요건 공용으로 만든 개발자 계정을 입력해주면 된다.

그리고 사용할 passphrase(비밀번호)를 묻는다. 요건 추후 팀원들이 인증서와 Provisioning Profile을 불러올 때에도 사용이 되니 꼭 잘 기억해놓자!!!

그런데 비밀번호를 입력할 때 문제가 생겼다.

bad decrypt
Couldn't decrypt the repo, please make sure you enter the right password!

아니 이름만 보면 무슨 비밀번호가 잘못 됐다는 것인데 아무리 해봐도 안된다.

Couldn't decrypt the repo, please make sure you enter the right password! 해결 방안

저번에 한 번 fastlane match를 도입하다가 계속 안돼서 방치하던 레포를 그대로 사용했더니 발생한 에러였다. 이유는 모르겠지만 저번과 동일한 비밀번호를 사용하면서 이 문자열을 입력했는데 계속 저런 에러가 발생했고 아예 레포를 지우고 다시 동일한 이름으로 레포를 생성했더니 해결이 됐다.

이렇게 기존 Provisioning Profile도 삭제 완료!

5. 여러 app identifier 사용 중인 경우 이에 대한 대응 (+ multi target)

현재 앱은 OneSignal Extension / Widget을 사용하고 있는 Multi target 앱이었고, 거기다가 Debug / Release 따로 app identifier를 쓰고 있다보니 조금 더 복잡했다.

여기서 target / identifier에 맞게 인증서를 생성해야 했다.

https://docs.fastlane.tools/actions/match/#handle-multiple-targets:~:text=Handle%20multiple%20targets

match - fastlane docs

type Define the profile type, can be appstore, adhoc, development, enterprise, developer_id, mac_installer_distribution, developer_id_installer development

docs.fastlane.tools

요 부분에서도 약간 막혔지만 이건 공식 문서에 설명이 나와있었다.

인증서를 생성하는 명령어는 다음과 같다.

fastlane match development // Debug
fastlane match appstore // Release

하지만 이렇게 하면 AppFile에 등록한 Bundle Identifier에 해당하는 인증서만 생성된다.

즉 현재 앱에선 Debug와 Release의 Bundle Identifier가 다른데 동일하게 인증서가 생성되는 것이다.

이렇게 되면 안된다!!

fastlane match appstore -a tools.fastlane.app

그럴 땐 요런 식으로 -a를 붙이고 해당하는 Bundle Identifier를 적어주면 된다.

이렇게 하면 일단 새로운 공용 계정 Certificate와 Provisioning Profile을 등록할 수 있다.

6. Xcode 설정 변경

글 초반에 말했듯 Xcode Project의 Target에서 있는 Signing & Capabilities 탭에서 Certificate와 Provisioning Profile에 대한 설정을 할 수 있다.

Automatically manage signing 체크 해제
적합한 Provisioning Profile 선택

Xcode 설정 변경도 추가로 해줘야 하는데 이는 새로운 컴퓨터에서 추가한 Certificate와 Provisioning Profile을 받을 때 좀 더 문제가 생겼고 개선한 부분이 있어 뒤에 조금 더 추가적인 내용이 존재한다.

이렇게 빌드하니 잘 됐기 때문에 흠.. 생각보다 쉽게 됐는데 생각했다.. 하지만 아직 갈 길이 멀었다.

다른 컴퓨터에서 인증서를 받고 이에 대한 처리

1. Certificate & Provisioning Profile을 Git 레포에서 불러오기

불러오는 명령어 자체는 간단하다.

fastlane match development --readonly // Debug
fastlane match appstore --readonly // Release

--readonly를 붙이지 않으면 새로운 인증서를 다시 생성하기 때문에 이미 생성이 됐다면 read only로 불러와야 한다.

'Error Cloning certificates repo, please make sure you have read access to the repository you want to use' issue 에러 발생

이 경우 토큰이 없어서 접근하지 못하는 문제이다.

파란색으로 나온 부분처럼 다시 레포를 clone한 뒤 username(이전에 설정한 공용 ID를 사용)와 passphrase(Github 상에서 token 재생성 후 확인)을 적어주니 정상적으로 Git Repository에서 Certificate와 Provisioning profile을 받아올 수 있었다.

'wrong final block length' and 'password has been deleted' issue 에러 발생

항상 발생하는 에러는 아닌 것 같았다. 2개의 다른 컴퓨터에서 시도를 했는데 1개는 정상적으로 넘어갔고, 다른 1개만 문제가 발생했다.

MatchFile에 환경 변수를 설정하여 아예 비밀번호 관련 입력을 하지 않도록 했다.

username("개발자 계정 입력")

ENV['MATCH_PASSWORD'] = "이전에 입력했던 passphrase 입력"

이렇게 해놓으면 MATCH_KEYCHAIN_PASSWORD라는 키값으로 passphrase가 입력된다.

그리고 ENV의 키 값을 넣을 때 작은 따옴표를 써야 했다.

공식문서에서도 작은 따옴표를 사용하고 있어서 요게 맞는 것 같다. (구글링하다보면 가끔 큰 따옴표를 쓰는 경우가 있던데... 잘못 쓴건가..)

일단 요렇게 MatchFile을 통해 문제는 해결!

공식문서에서는 암호화를 권장하긴 했는데 일단 올라가는 Github 레포지토리가 애초에 private으로 되어 있어서 크게 문제가 없을 것으로 판단했고 일단 저렇게 작업을 해서 해결을 했다.

https://ios-development.tistory.com/1164

[fastlane] fastlane 환경변수 사용 방법 (.env.default 사용하여 가장 간단한 match 사용방법, Certificate 갱

Fastlane match란? Certificate, Provisioning Profile을 특정 git 레포에 저장해놓고 개발자들 사이 or ci/cd 때 쉽게 관리할 수 있는 기능 mathc명령어를 통해 terminal에서 Apple 개발자 사이트에 접속하여 Certificate

ios-development.tistory.com

'wrong final block length' and 'Couldn't decrypt the repo, please make sure you enter the right password!' issue 에러 발생

이 경우 위 방법을 사용했을 때에도 동일하게 에러가 발생했다.

이때 MatchFile에서 환경변수 설정한 부분에서 키값의 작은 따옴표를 다시 작성해줬더니 잘 동작했다.

흠... 작은 따옴표의 인코딩 에러로 인해 문제가 발생했던 것 같다.

'No matching provisioning profiles found for {Provisioning Profile name}' issue 에러 발생

이 경우는 -a로 app identifier를 지정해주면 된다. AppID로 지정해놓은 것과 받아오는 인증서 간 차이가 있는 경우 발생하는 문제이다.

하지만 요 경우는 에러 문구가 발생했다고 해서 잘못된 인증서가 오거나, 인증서를 못 받는 문제 자체는 없었다.

그래도 말한대로

fastlane match appstore --readonly -a tools.fastlane.app

이런 식으로 올바른 identifier를 지정해주면 해당 에러는 사라지게 된다.

2. Xcode Project의 Target에서 있는 Signing & Capabilities 탭에서 Provisioning profile 다운로드

No matching provisioning profiles found and can not create a new one because you enabled readonly. Check the output above for more information. 에러 발생

Xcode > Target > 프로젝트 > Build Setting > Signing > Code Signing Identity에서 Debug / Release 모두 각각 지정해줌

(기본 설정은 Auto로 되어 있음)

제대로 provisioning profile을 지정하지 못하는 것 같아서 수동으로 지정을 해놓았더니 해당 문제는 해결이 되었다.

요것도 1 곳에선 제대로 해결이 되었는데 1 곳에선 제대로 해결이 되지 않아 추가 검토는 필요하다.

Provisioning profile "{Bundle ID}" doesn't include the currently selected device "{기기 이름}" (identifier {UUID}). 에러 발생

인증서를 Fastlane으로 관리한 이후 추가된 기기의 경우 위 에러가 발생하며 빌드가 되지 않는 문제가 있었다.

인증서에 등록된 기기 리스트에선 현재 빌드를 하려는 기기의 UUID가 존재하지 않기 때문에 에러가 발생하는 것이다.

1. Apple Developer에서 Device 등록

2. 개발용 / 배포용 등에 대해 인증서를 갱신한다.

fastlane match development  --force_for_new_devices true -a {Bundle ID}

흠... 매번 기기를 등록할 때마다 이렇게 번거롭게 추가를 해줘야 하나...?

(혹시 다른 방법을 알고 계신 분들은 알려주세요ㅠㅠ)

일단 요렇게 하면 다른 새로운 테스트 기기에서도 빌드가 가능해진다.

아직 완전히 해결을 하진 못했지만 그래도 1곳에선 새로운 컴퓨터에서 생성한 인증서를 받는 것까지 완료해서 오류에 대한 기억이 가물가물해지기 전에 작성해봤다.

다른 글에선 쉽게 쉽게 하시는 것 같던데... 진짜 너무 많은 예외 케이스를 만나서 빡셌다...

자료도 많이 없고 어디서 문제가 생겼는지 명확히 말해주지를 않다보니 디버깅이 쉽지 않았다.

그래도 직접 해보며 왜 fastlane을 써야 하고 어떻게 써야 하는지 좀 더 감이 온 것 같다.

아직 Fastfile을 능숙히 설정하여 CI / CD까지 적용하진 못했지만 말이다...

나처럼 도입에 애를 먹고 계신 분들이 계시다면 도움이 되었으면 좋겠다

[Firebase Crashlytics] dSYM 누락 - Crashlytics에서 --버전의 dSYM 누락을 감지했습니다.

호르댕댕댕 — Wed, 17 Apr 2024 15:02:05 +0900

크래시리틱스를 사용하다보면 dSYM 누락을 감지했습니다. 라는 경고를 마주칠 수 있다. Firebase에선 이 파일을 기반으로 어떤 코드에서 에러가 발생했는지 확인하기 때문에 누락이 발생했으면 해당 버전에선 아예 어디서 에러가 발생했는지 확인할 방법이 없다.

그래서 이런 경고가 발생하면 반드시 dSYM을 추가해줘야 한다.

dSYM 파일은 뭘까?

이는 컴파일러가 우리가 짠 소스 코드를 기계어로 변환할 때 생성이 되며(앱 Archiving 시 생성), 기계어와 소스코드 라인을 매핑하는 정보를 가지고 있다.

즉, 이 파일이 있어야 어떤 소스코드에서 문제가 발생했는지 알 수 있는 것이다.

이는 각각 고유한 UUID로 구분이 되어 있다.

왜 누락되는 것일까?

https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports?hl=ko&platform=ios#check-input-files-setup

Crashlytics 대시보드에서 읽을 수 있는 비정상 종료 보고서 받기 | Firebase Crashlytics

5월 14일, Google I/O에서 Firebase를 다시 만나보세요. 지금 등록하기 의견 보내기 Crashlytics 대시보드에서 읽을 수 있는 비정상 종료 보고서 받기 컬렉션을 사용해 정리하기 내 환경설정을 기준으로

firebase.google.com

Xcode 15부터 구성이 최신 상태가 아니라면 아래 오류가 발생할 수 있다고 한다.

error: Info.plist Error Unable to process Info.plist at path ...

그리고 파일 위치를 좀 더 명확하게 나타내야 하기 때문에 링크에 있는 것처럼 경로를 설정해줘야 한다.

그럼 어떻게 dSYM 파일을 받을 수 있을까?

예전에는 AppStoreConnect에서 빌드 파일의 메타 데이터 쪽에 dSYM을 다운로드할 수 있도록 되어 있었지만 현재는 사라진 상태이다.

따라서 이 방법은 사용할 수 없다.

일단 dSYM 파일을 받기 위해선 Xcode > Window > Organizer에 들어가서 확인할 수 있다.

이런 식으로 아카이빙이 완료되면 나오는 화면과 동일하다.

그럼 저기 보이는 Download Debug Symbols 누르면 되겠네? 라는 마음이 샘솟는다.

몇몇 블로그에서도 동일하게 안내를 해주고 있다.

오잉 그런데 내가 해보니 아래와 같은 에러가 발생한다.

혹시 아카이빙 문제인가 해서 다른 아카이브된 버전도 테스트해봤으나 역시 동일한 Alert가 나왔다.

그럼 어떻게 하면 좋을까?

일단 받고자 하는 아카이빙된 곳을 우클릭해서 Show in Finder를 누른다.

그러면 이런 식으로 날짜 별로 아카이빙한 기록이 나오고 xcarchive 파일을 확인할 수 있다.

거기서 또 우클릭 후 패키지 내용 보기를 선택하면 dSYM 파일을 확인할 수 있다.

여기서 있는 dSYM 파일을 압축해서 Firebase Crashlytics에 올려주면 된다.

이때 주의할 점은 dSYM 파일들은 각각 고유한 UUID를 가지고 있기 때문에 반드시 배포했을 때 아카이빙했던 파일을 올려줘야 한다.

UUID가 다를 경우 Firebase에서 누락 경고가 사라지지 않는다.

(다만 여기서 UUID를 미리 확인하는 방법은 찾지 못했다... 혹시 아시는 분 계신다면 알려주세요 )

[유데미 강의 후기] 개발자 영어

호르댕댕댕 — Mon, 15 Apr 2024 17:11:03 +0900

현재 9기로 참여 중인 글또에서 유데미 강의를 지원해주셔서 내가 수강했던 강의, 개발자 영어에 대한 후기를 남긴다.

(좋은 기회 주신 글또, 유데미 모두 감사합니다!)

https://www.udemy.com/course/devenglish/?couponCode=24T3FS41524

왜 이 강의를 듣게 되었나?

일단 개발자들은 싫든 좋든 개발을 하다보면 영어를 반드시 만나게 된다.

모르는 내용, 헷갈리는 내용을 구글링할 때
- 스택오버 플로우
- 구글링
- ChatGPT 활용
직접 개발을 할 때 (네이밍, 주석 등등)
이미 개발된 오픈 소스 코드를 확인할 때

심지어 ChatGPT를 쓸 때에도 한글로 검색할 때보단 영어로 질문하고 답변을 받는 것이 좀 더 좋은 답변을 받는 경우도 왕왕 있었다.

프로그래밍과 영어는 어떻게 보면 뗄래야 뗄 수 없는 관계인 것이다.

나도 지금까지 계속 영어를 공부했지만 어느새 구글 번역기로 돌려서 확인하는 나 자신을 보며 해당 강의 제목을 보자마자 혹했다...

더군다나 유데미에서 강의까지 지원해주신다니..! 바로 신청을 하게 되었다.

개발자 영어는 무슨 강의인가?

강의에선 왜 개발자가 영어를 공부해야 하는지부터 여러 개발 관련 문서를 어떻게 읽는지 개발에서 중요한 네이밍과 주석을 어떤 식으로 달면 좋은지, 어떻게 정보를 습득하고, 좋은 질문과 답변은 어떤 것인지 소개를 해준다.

이외에도 ChatGPT를 어떻게 사용하면 좋은지 RestfulAPI에서 네이밍을 어떻게 하는 것이 좋을지 등 조금 더 실용적인 부분에 대해서도 설명을 해주신다.

당연한 것이지만 이 강의를 듣는다고 해서 영어 실력이 갑자기 올라가고 이런 일은 없다.

다만 개발자의 입장에서 왜 영어를 공부해야 되고 이를 활용할 수 있는 다양한 상황들과 여러 꿀팁(관련 사이트)들을 집약적으로 전달해주신다.

특히 기술 뉴스를 접할 수 있는 다양한 곳도 알려주셔서 좋았다.

https://news.ycombinator.com/

Hacker News

news.ycombinator.com

https://www.reddit.com/

Scan this QR code to download the app now Or check it out in the app stores

www.reddit.com

https://justfive.news/

Just Five News · Latest News

Just 5 latest headlines of the world you need right now.

justfive.news

레딧은 검색할 때 종종 볼 수 있는 곳이라 이미 알고 있었지만 Hacker News나 Just Five는 처음 접했다.

회사에선 GeekNews에 글이 올라오면 슬랙으로 알림을 주고 있어 여기만 확인을 했었는데 역시 다양한 곳들이 있었다.

https://news.hada.io/

GeekNews - 개발/기술/스타트업 뉴스 서비스

개발 뉴스, 기술 관련 새소식, 스타트업 정보와 노하우, 세상의 재미난 것들을 좋아하는 사람들을 위한 뉴스 사이트. 이메일 뉴스레터/트위터/슬랙 봇으로 구독 가능

news.hada.io

이렇게 좋은 정보들을 실제 시니어 개발자 분이 잘 정리해서 알려주셔서 만족스러운 강의였다.

(단, 영어 자체를 다룬다기 보단 이를 활용해 어떻게 사용하면 좋을지에 좀 더 포커스가 되어있다)

글또 프론트엔드 / 모바일 반상회를 다녀오고

호르댕댕댕 — Fri, 5 Apr 2024 17:29:15 +0900

4월 4일, 어제 글또에서 진행하는 프론트엔드 / 모바일 반상회를 다녀왔다.

신청을 제 때 못했었는데 양해해주신 성윤님 정말 감사합니다

감사하게도 잡플래닛에서 공간 대여를 해주셔서 잡플래닛 사무실도 잠깐 구경할 수 있었다. 이전에 취업할 때 잡플래닛 많이 사용했었는데 뭔가 더 반갑고 신기한 느낌.. ㅎㅎㅎ

아래처럼 굿즈(글또 + 잡플래닛)도 준비해주셨다.

간단하게 잡플래닛 소개도 해주셨는데 AI 팀을 따로 운영 중인 것도 신기했고, 잡플래닛이 현재 사용 중인 기술스택(레이아웃은 FlexLayout / PinLayout / Then)도 들을 수 있어 좋았다.

(현재 회사도 일정 부분 비슷한 서비스를 진행 중이라 어떤 기술을 사용하고 어떻게 일하는지 좀 더 관심있게 봤다)

1부 발표.

View를 대하는 클라이언트 개발자의 자세 (신해나라님)

클라이언트 개발자라면 User Application (프론트엔드 / 모바일 + Flutter, React Native) 개발을 할 것이고 그렇다면 대부분 뷰를 개발하고 있을 것이다.

나 또한 클라이언트 개발자로서 항상 뷰를 다루고 있었지만 `뷰`라는 것 자체에 고민을 크게 해본 적은 없었는데, 개발하면서 놓치기 쉬운 접근성 같은 것들을 언급해주시며 `뷰`에 대해 조금 더 생각해볼 수 있었던 세션이었다.

일단 View는 어플리케이션과 사용자가 만나는 인터페이스로 사용자에게 정보를 제공하고, 사용자에게 정보(User Interaction)를 다시 받는다.

신해나라님은 크게 2가지 관점으로 뷰를 말씀해주셨다.

사용자 관점에서의 뷰

뷰 만큼이나 빈번하게 사용하는 말이 바로 UI / UX인데 여기서 UX는 단순히 사용자가 느끼는 경험 정도로만 생각했다.

User Experience의 줄인 말이니 말이다. 물론 틀린 말은 아니지만 좀 더 세부적으로 UX에 대해 설명을 해주셨다.

UX를 말할 때 한 번쯤은 언급되는 이미지라고 하셨는데... 부끄럽지만 어제 처음 봤다

그래도 UX를 말할 때 다양하게 고려해야할 부분을 잘 설명해주는 이미지라고 생각해서 가져왔다.

신해나라님은 아래 4가지 측면에서 UX 적으로 고려할 수 있다고 말씀주셨다.

어떤 사용자가
어떤 환경에서
가장 필요한 것을
가장 좋은 방법으로

요런 가치들을 잘 제공하고 있으면 좋은 UI / UX라고 볼 수 있을 것이다.

하지만 여기서 우리 클라이언트 개발자가 기여할 수 있는 부분은 여전히 Surface 단, 즉 뷰를 개발하는 것이다.

어쨌든 대부분의 업무 플로우가 기획자가 제공하는 기획을 토대로 개발이 되기 때문이다.

그렇기 때문에 할 수 있는 것들 2가지를 말씀주셨다.

사용성 개선하기

옆에 이미지와 같은 더보기 버튼이 존재한다고 생각을 해보자. (SF Symbol ellipsis 이미지)

저 이미지 영역만큼 딱 맞게 버튼을 생성한다면 탭 이벤트를 인식하는 영역이 너무 작을 것이고 그렇다면 사용성이 떨어질 것이다.

그래서 여기에 패딩을 넣어서 탭 이벤트 영역을 넓힌다면 사용성이 좀 더 개선이 될 수 있을 것이다.

접근성 개선하기

접근성은 애플에서도 강조하는 부분이긴 하나.. 항상 제대로 안되고 있는 부분이긴 했는데 말씀해주셨다.

일단 접근성이란 장애인에 한정되어 사용하는 것이 아닌 모든 사람에게 적용이 되는 부분이다.

소음이 심한 상황
일시적으로 깁스 등을 해서 제약이 생긴 경우
운전 중인 경우

이런 상황들에선 신체를 자유롭게 사용하지 못하는 환경에 처할 수 있으며 이런 상황은 모든 사람들이 겪을 수 있는 부분이기 때문이다.

따라서 요런 부분까지 신경을 써줄 때 조금 더 나은 UX가 될 수 있을 것이다.

개발자 관점에서의 뷰

어떻게 뷰를 개발하는지에 대해 말씀해주셨다.

요즘 안드로이드, iOS 가릴 것 없이 핫한 선언형 UI부터 클린 아키텍쳐 등 말이다.

특히 공통된 뷰는 커스텀으로 만들어서 처리를 하는 것을 권장하셨다.

아무래도 공통된 부분을 분리해놓지 않고 있다가 해당 뷰에서 공통적인 변경 사항이 생긴다면 커스텀이 되어 있지 않은 경우 사용하는 곳을 전부 찾아서 다 바꿔줘야 하기 때문이다.

이 부분 역시 공감이 되는 부분이었다. 한 번 커스텀을 잘 해놓으면 사용하는 사람들도 편하고 리팩토링 내성도 갖게되니 말이다.

개발자 관점에서의 뷰의 핵심은 경험치를 많이 쌓는 것이었다.

다양한 뷰를 직접 많이 개발해본다면 조금 더 좋은 뷰를 빠르게 개발할 수 있게 되기 때문이다.

클라이언트 개발자라면 뷰를

많이 개발해보고
기본 컴포넌트도 많이 사용해보자 (좋은 기본 컴포넌트들이 많다. 어떻게 구현이 되어 있을 지도 생각해보자)

미래의 클라이언트 개발자

그러면서 요새 유튜브 주제로도 많이 올라오는 AI 시대에 클라이언트 개발자에 대해 말씀해주셨다.

다른 직종들의 경우도 오히려 반복 작업의 경우 아직 사람들이 하는 경우가 많고 오히려 창의적인 것을 요구하는 예술, 음악 쪽에서 AI가 활약하고 있는 경우도 많기 떄문에 오히려 클라이언트 개발자는 수명이 더 길수도 있지 않을까 말씀해주셨다.

그리고 Vision OS도 등장하면서 새로운 형태의 것을 요구하는 클라이언트 개발자가 생길 수도 있고 말이다.

Vision OS는 나도 관심이 있고, 최근 컨퍼런스에서 종종 시도해보시는 분들도 계시던데... 역시 SwiftUI를 좀 더 공부해야 하나 싶다 ㅎㅎ

그러면서 미래 클라이언트 개발자들은 아래 일을 할 수 있지 않을까 언급해주셨다.

앱 배포 (시기 결정)
뷰 이슈 대응
기종별 호환성 검사
새로운 View 프레임워크가 나온 경우 이를 AI에 데이터 학습 시킴

항상 내가 하는 일과 맞닿아 있고, 알고는 있었지만 깊게 신경쓰진 못했던 부분을 다시 한 번 듣고 상기할 수 있다는 측면에서 되게 좋았다! 그리고 특정 플랫폼에 묶이지 않고 모두가 잘 들을 수 있는 발표를 너무 잘 준비해주셔서 좋았다.

기술 블로그를 위한 SEO (정종윤님)

https://wormwlrm.github.io/2023/05/07/SEO-for-Technical-Blog.html

기술 블로그를 위한 SEO - 재그지그의 개발 블로그

개인 기술 블로그에 적용한 SEO 방법들을 소개하고, 그 결과물을 공유합니다.

wormwlrm.github.io

요건 발표 제목만 보고 정말 관심이 갔던 부분이었다...

블로그에 140개 정도 글을 올렸지만 아직 조회수가 너무 미비했기 때문이다...

물론 기술 블로그에 글을 올리는 것이 내가 이해한 것을 글로써 정리하며 이해도를 높이는 목적도 있겠지만 가장 큰 이유는 내가 알게된 지식을 다른 사람들에게 잘 공유하기 위해서이니 요런 상황이 조금 더 아쉽게 다가왔다...

구글 서치 콘솔 추가한 뒤로는 그래도 조금 나아지긴 했지만 많은 수치는 아니다.

그래서 종윤님은 어떻게 SEO 작업을 하셨는지 더욱 궁금해졌다.

(내용적인 부분은 이미 종윤님이 블로그에 잘 정리해주셔서 확인해보시면 좋을 것 같습니다! 저는 이해한 것 기반으로 요약해볼게요...!)

SEO는 검색 엔진 최적화로, 검색 엔진으로부터 웹사이트나 웹페이지에 대한 웹사이트 트래픽의 품질과 양을 개선하는 과정이다.

여기서 개선할 수 있는 부분을 3가지로 나눠서 말씀해주셨다.

온 페이지 SEO : 콘텐츠의 구성요소를 개선
- 양질의 콘텐츠 제작
  - 직접 경험
  - 주제에 대한 이해도가 높은가
  - 작성자가 얼마나 저명한가
  - 위 모든 것을 종합해서 믿을 수 있는가
- 분량은 콘텐츠 품질에 직접적인 영향을 주진 않음
- 다루고자 하는 주제를 나의 관점에서 바라본 콘텐츠로 제작
- HTML 태그 수정 (타이틀 태그 / 메타 태그 / OG 태그 - 미리보기)
테크니컬 SEO : 크롤링이 잘되게 하고 인덱스를 생성하기까지 과정 개선
- 사이트 맵 (웹사이트 구조가 담긴 XML 파일) → 티스토리는 기본 제공
- RSS : 최근 발행한 컨텐츠 정보 → 티스토리도 제공
- 라이트하우스 점수 향상
- 구글 서치 콘솔에 등록
- 네이버 서치 어드바이저에 등록
오프 페이지 SEO
- 백링크(다른 사람들이 내 글의 링크를 자신의 콘텐츠에 넣었을 때)가 많을수록 평판이 좋다고 평가 (SNS에 올리는 것이 효과 좋음)
- 기술 블로그는 평일 오전 9~10시 오후 2~4시에 가장 트래픽이 많음

여기서 가장 효과가 좋았다고 느끼시는 부분은 SNS 공유라고 하셨다!

역시 초기에는 다른 사람들이 많이 볼 수 있도록 직접 홍보를 하는 방법이 효과적인 것 같다.

사이트맵 / RSS는 일단 기본적으로 제공되는 기능을 사용하고 있고 구글 서치 콘솔과 네이버 서치 어드바이저의 경우 이미 등록을 해놔서 요 부분에선 크게 개선할 부분은 많지 않다고 생각이 들었다.

(사이트맵, RSS는 다시 한 번 점검해보긴 해야겠다)

콘텐츠의 양질 향상의 경우 종윤님의 포스팅을 보니 반성하게 되었다.

사실 지금까지의 포스팅은 단순히 특정 정보를 보고 요약 정리를 하는 내용이 많았다 보니 콘텐츠의 질이 약간 떨어지고, 어디서든 볼 수 있는 정보이지 않았나 싶다.

앞으로는 이런 부분도 고민하면서 작성을 해봐야겠다. 그리고 부끄럽지만 링크드인에서도 글 작성 후 홍보를 해봐야겠다.

2부 네트워킹 + 레크리에이션

오랜만에 카훗으로 퀴즈를 했다 ㅎㅎㅎ

진짜 이거 어떻게 아나 싶은 문제들이었는데 다른 팀들은 엄청 잘 맞추신... ㅋㅋㅋ 대단하시다는 생각이 들었다.

(스티브잡스의 생일은? 약간 이런 느낌의 문제들이었다 ㅎㅎㅎ 오히려 이런 문제라 부담이 적어서 좋았다!)

레크리에이션이 끝나고는 네트워킹을 진행했다.

내가 속했던 팀에는 따로 iOS 분은 안 계셔서 그 부분은 아주 조금 아쉬었지만 그래도 평소에 이야기를 잘 해보지 못했던 백엔드, Flutter, 프론트엔드 개발자 분들과 이야기를 해볼 수 있어서 좋았다.

처음에 다짜고짜 이야기하려면 어렵기 때문에 주제도 개인별로 제공해주셨다

우리 조에선 아래 주제로 이야기했다.

좋은 커리어란
좋은 코드란
주 100시간 연봉 50억, 주 20시간 연봉 5천

좋은 커리어는 사실 아직 잘 모르겠다... 나도 아직 만 1년 반 정도된 주니어 그 자체이고...

나는 성장 관점에서 커리어를 보고 있었는데 다들 나보다 연차도 높으시고, 오히려 다른 분야의 개발을 병행하는 커리어 등을 고민하고 계신 분들도 있었다.

커리어를 너무 편협한 시각으로 보고 있었나라는 생각도 들었지만, 현재 내 연차에선 지금의 고민이 맞는게 아닐까 싶기도 했다.

아직 iOS 내에서도 못 해본 것들이 너무 많고 공부할 것도 아직 많기 때문에...

좋은 코드의 경우 하고 계신 분야와는 다르게 대부분 단순하고 가독성이 좋은 코드로 의견이 모아졌다.

(과도한 추상화는 오히려 독이 될 수도 있는 이야기도 나눴다)

그리고 돈이 되는 코드가 좋은 코드라는 말씀도 해주셨다.

주 100시간 연봉 50억, 주 20시간 연봉 5천, 이 주제는 앞선 주제보다는 좀 더 가벼운 주제였다 ㅎㅎㅎㅎ

나는 주 100시간까지 할 체력은 안된다는 생각에 후자지만... 전자는 폭발적인 성장이 가능할 것 같기도 하다. 물론 바쁘다고 좋은 코드를 잘 짜고 있다는 아니지만 말이다.

iOS 개발자가 아닌 개발자 분들과 이야기를 나눈 것은 회사를 제외하곤 없었는데 좀 더 다양한 관점을 배울 수 있었던 좋은 기회였다.

역시 세상은 넓고 고수는 많다.. ㅎㅎㅎ

글또 덕분에 인사이트도 얻고 다른 분들의 생각도 들을 수 있었던 정말 좋은 기회였다.

[iOS] Privacy Manifests 대응

호르댕댕댕 — Fri, 29 Mar 2024 21:17:59 +0900

갑자기 이런 메일을 받았다면...?

24년 3월 13일 이후로 배포 시 프로덕트에 Privacy Manifests가 누락되어 있다면 애플에서 메일을 보내게 된다.

Hello, We noticed one or more issues with a recent submission for App Store review for the following app: {앱 이름}

Version {현재 배포 버전}
Build {등록해놓은 빌드 버전}

Although submission for App Store review was successful, you may want to correct the following issues in your next submission for App Store review. Once you’ve corrected the issues, upload a new binary to App Store Connect.

ITMS-91053: Missing API declaration - Your app’s code in the
{어디에 어떤 API에 대한 Privacy Manifest가 누락되었는지 설명}

May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit:
https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api
. Apple Developer Relations

24년 5월 1일까지 이에 대한 대응을 반드시 해야 한다고 하고 있기 때문에 대응은 필수적이다.

이에 대한 내용은 이미 23년 WWDC Get Started with privacy manifests에서 다룬 적이 있어 해당 내용을 정리하면서 어떤 식으로 대응하고 있는지를 기록하고자 한다.

https://developer.apple.com/videos/play/wwdc2023/10060

Get started with privacy manifests - WWDC23 - Videos - Apple Developer

Meet privacy manifests: a new tool that helps you accurately identify the privacy practices of your app's dependencies. Find out how...

developer.apple.com

Get Started with privacy manifests

개인 정보 보호는 개인의 권리로써 잘 보장되어야 하기 때문에 Apple에선 이를 좀 더 투명하고 잘 관리하기 위해 Privacy Nutrition Label과 App Tracking Transparency를 잘 관리하기 위한 Privacy Manifests를 도입했다.

물론 기존에도 앱 스토어 상에 Privacy Nutrition Labels를 제공하고 있었고 App Tracking Transparency를 사용해 데이터를 추적하는 것을 사용자가 제어할 수 있도록 했다.

AppTrackingTransparency의 경우 AppTrackingTransparency를 import하여

ATTrackingManager.requestTrackingAuthorization

요 함수를 통해 사용자에게 제어할 수 있는 Alert를 보여준다.

그런데 요걸 좀 더 투명하게 관리하기 위해 Privacy Manifests가 등장한 것이다.

사용자의 개인 정보를 써드파티 라이브러리를 통해 관리하는 경우가 꽤 있는데 이제는 써드파티 라이브러리에서 App Privacy 파일을 통해 어떤 데이터를 수집하고 있는지 명확히 밝히도록 해야 한다.

여기서 사용하는 데이터 타입 / 데이터 타입이 사용되는 방식 / 사용자에게 연결되어 있는 데이터인지 / App Tracking Transparency 정책에 정의된 대로 데이터를 추적하고 있는지 등을 기재해야 한다.

아래처럼 말이다.

이러한 정보는 Xcode15부터 아카이빙을 하고 난 이후 Generate Privacy Report를 통해 한 눈에 확인할 수 있다.

여기서 앱 전체적으로 어떤 Privacy Nutrition Label을 사용했는지 한 번에 PDF 형식으로 report를 만들어서 보여준다.

Privacy Nutrition Label의 경우 아래 문서에서 리스트를 확인할 수 있다.

https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_data_use_in_privacy_manifests

Describing data use in privacy manifests | Apple Developer Documentation

Declare the data collected by your app or by third-party SDKs.

developer.apple.com

AppStore Connnect에서 앱의 개인 정보 보호 세부 정보를 제공할 때 해당 보고서를 참고하면 써드파티에서 사용 중인 개인정보까지 누락없이 작성하는데 도움이 될 것이다.

그리고 일부 써드파티 SDK의 경우 사용자 추적 권한을 부여하지 않더라도 개인정보를 추적할 수 있다. 이때 수동으로 앱 추적을 비활성화해야 하는데 iOS 17부턴 요런 도메인을 Privacy Manifest에 등록해놓으면 AppTrackingTransparency를 거절한 경우 자동으로 해당 도메인에 대한 연결을 차단하여 이런 엣지 케이스를 방지할 수도 있다.

이는 개발자가 인지하지 못하고 있을 수 있기 때문에 Xcode Instrument의 Network에서 Points of Interest를 통해 이를 찾을 수 있도록 도와준다.

https://developer.apple.com/documentation/xcode/detecting-when-your-app-contacts-domains-that-may-be-profiling-users

Detecting when your app contacts domains that may be profiling users | Apple Developer Documentation

Use Instruments to assess whether your app or its third-party SDKs connect to domains that may profile users.

developer.apple.com

위 문서에서 어떻게 이런 도메인을 찾을 수 있는지에 대한 방법이 좀 더 자세하게 나와있다.

(내가 확인했을 때에는 우리 앱에선 발견하지 못했다. 그래서 정확히 어떤 상황일 때, Network instrument에 잡히는지는 확인하지 못했다)

그리고 Apple에선 필수로 사용 이유를 밝혀야 하는 API 목록에 대해서도 언급을 했다.

https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api

Describing use of required reason API | Apple Developer Documentation

Ensure your use of covered API is consistent with policy.

developer.apple.com

이는 알게 모르게 앱 내에서 사용하고 있는 경우가 많아 왠만하면 전부 이를 밝혀야 했다.

위 문서에선 아래 API 리스트를 언급하고 있다.

File timestamp APIs
System boot time APIs
Disk space APIs
Active keyboard APIs
User defaults APIs

해당 API를 사용했다면 반드시 App Privacy를 만들어서 어떤 API를 사용했는지 밝히고 사용한 이유를 기재해야 한다.

그런데 여기서 이유가 다양했는데 실제로 Xcode 상에선 해당 이유가 전부 있진 않았다. 최대한 사용한 이유에 부합하게 작성을 해놓긴 했는데 만약 리젝을 당한다면 다음 콘텐츠에 이를 작성해보고자 한다.

그래서 어떻게 대응을 해야 하는데?

이 부분이 가장 중요하고 궁금한 부분일 것이다.

현재 대응 중이고 아직 애플에서 명확한 피드백을 받지 못해서 이렇게 대응하는 것이 불확실하긴 하다.

일단 애플에선 앱 개발자는 다음과 같은 대응이 필요하다고 했다.

써드파티 SDK에 privacy manifests 요청
App Store Connnect에서 Xcode Privacy Report를 통해 정확한 Privacy Nutrition Labels 제공
tracking domain을 선언하고 required reason API를 사용하고 있는지 확인 후 사용한다면 이를 Privacy Manifest에 기재

써드파티 SDK에 privacy manifests 요청

일단 애플에서 아래 링크에 기재된 라이브러리는 요청이 필요하다고 기재를 해놨다.

https://developer.apple.com/support/third-party-SDK-requirements/

Upcoming third-party SDK requirements - Support - Apple Developer

Feedback Assistant Submit feedback, report bugs, and request enhancements to APIs and developer tools. Send us feedback

developer.apple.com

생각보다 흔히 사용되는 라이브러리들 대부분 이름이 올라가 있다.

RxSwift, Snapkit, Alamofire, Firebase 등등 말이다.

이미 다양한 외국 개발자들이 요청을 해놓은 경우가 많다.

내가 찾아본 지원 현황은 아래와 같다.

지원 현황 (2024.03.27 기준)

Firebase : v 10.22.0에 대응
Google Sign in : 이슈(링크)만 올라오고 아직 대응 X

Support App Privacy Manifest · Issue #341 · google/GoogleSignIn-iOS

Is your feature request related to a problem you're having? Please describe. Apple required App Privacy manifests until 2025. So GoogleSignIn-iOS SDK that contains an app privacy manifest must be s...

github.com

KakaoOpenSDK : ~~추후 업데이트 시 공지사항(링크)을 남겨주겠다는 게시글만 존재 (제공 예정이라 함)~~ -> v2.22.0 이상부터 지원

App Store 앱 제출을 위한 개인정보 보호 관련 업데이트(매니페스트) 대응 문의

안녕하세요~ 카카오로그인API를 사용중인 개발자 입니다. 애플에서 “App Store 앱 제출을 위한 개인정보 보호 관련 업데이트(매니페스트)” 공지를 하였는데요~ https://developer.apple.com/kr/news/?id=3d8a9y

devtalk.kakao.com

Kingfisher : v 7.9.0에 대응
Moya : Moya는 따로 대응 예정이 없다고 했고 Alamofire는 v 5.9.0에 대응
- Alamofire를 추상화한 라이브러리인 만큼 Alamofire만 지원하면 되나 싶긴 한데 요 부분도 배포 후 피드백을 받아 추가 진행 예정
Facebook : 이슈(링크)만 올라오고 아직 대응 X
SnapKit : v 5.7.0에 대응
SwiftyJSON : 3/20 대응 커밋이 올라왔으나 아직 배포 X
Swinject : 3/27 대응 커밋이 올라왔으나 아직 배포 X
Then : 이슈(링크)만 올라오고 답변 X

일단 리스트에 없는 써드파티 라이브러리들도 사용 중인 것들은 찾아봤다.

Firebase, Kingfisher, Alamofire, Snapkit은 이미 대응을 해줬고 아직 대응 예정이라는 답글만 달아놓은 곳들도 꽤나 많았다.

지원 현황을 트래킹하면서 라이브러리 업데이트가 필요할 것 같다.

따로 정리한 페이지도 존재한다!

https://apnspush.com/privacy-manifest-sdks#all-86-required-sdks-and-status-in-supporting-privacy-manifest

Apple's Privacy Manifest: 86 third-party SDKs required to add Privacy Manifest and Signature | APNsPush

Apps uploaded to App Store Connect must be built with Xcode 15 for iOS 17, iPadOS 17, tvOS 17, or watchOS 10, starting April 29, 2024. Starting in spring 2024, you must include the privacy manifest for any SDK listed below when you submit new apps in App S

apnspush.com

앱 내 대응

이미 메일을 받은 경우 해당 required reason APIs를 사용한 이유와 어떤 API를 사용했는지를 App Privacy 파일에 기재해주면 된다.

그리고 Network Instrument를 통해 tracking domain으로 등록할 도메인이 있는지 확인해주고 어떤 개인정보를 어떤 목적으로 사용했는지 Privacy Nutrition Label에 기재를 해주면 된다.

아직 1차 대응만 진행한 예정이고 요렇게 대응해도 부족한 부분이 있을 수 있기 때문에 추후 상황에 따라 필요한 내용을 추가로 정리해볼 예정입니다.

적어놓은 업데이트된 라이브러리 및 앱 내 대응만 했는데도 현재 관련 메일은 오지 않고 있는 상황입니다!

(라이브러리에 모두 대응할 필요는 없는건가...?)

[iOS] 테스트 코드(유닛 테스트, Unit Test)에 대하여

호르댕댕댕 — Sat, 2 Mar 2024 15:20:19 +0900

최근 회사에서 테스트 코드를 지속적으로 추가해주고 있고, 멋쟁이 사자처럼에서도 테스트 코드 관련해서 발표를 진행해서 테스트 코드에 대해 한 번 정리해보고자 한다.

일단 테스트 코드는 채용공고를 보더라도 심심치 않게 보이기도 하고 막연히 테스트를 짜면 좋다는 생각을 가지고 있지만, 못짜는 경우도 많다.

테스트가 필요한 이유

그럼에도 테스트는 왜 필요할까?

물론 앱 규모가 작다면 매번 직접 시뮬레이터나 실기기에서 실행을 해보면서 원하는 동작이 정상적으로 작동하는지 테스트할 수도 있을 것이다. 오히려 이렇게 하는게 더 빠를 수도 있다.

하지만 이렇게 하면 한계는 존재한다.

버그나 예상하지 못한 사이드 이펙트가 발생했더라도, 어디서 발생했는지 바로 알 수 없음
앱이 커지고 리팩토링이 지속적으로 발생할 경우 직접 실행하는 것으로 모든 버그와 사이드 이펙트를 확인하는 것은 쉽지 않음
- 가능하다고 해도 너무 많은 시간이 걸림

이런 상황에서 테스트가 잘 짜여져 있다면 위 한계를 해소할 수 있을 것이다.

처음에 짜는 데에는 시간이 훨씬 더 걸리겠지만 앱이 커질 수록 테스트가 있다면 버그나 사이드 이펙트를 찾는데 효율적이다. 이를 통해 안정적인 확장이나 리팩토링이 가능하게 된다.

그리고 이건 테스트를 짜보면서 느낀 부분인데 Testable한 코드를 짜기 위해선 의존성에 대해 고민할 수 밖에 없다.

테스트가 필요한 인스턴스를 만들기 위해 여기에 연결된 객체들의 인스턴스를 생성해서 주입하든 목으로 대체를 하든 방법이 필요하다.

이때 의존성이 너무 복잡하게 엮여있다면 테스트를 하기도 어렵기 때문에 의존성을 잘 관리하는 부분도 필요하다고 느꼈다.

(이건 테스트가 필요한 이유라기 보단 테스트를 짜면서 오는 부수적인 장점인 것 같다)

즉, 안정적인 프로덕트의 유지 보수를 위해선 테스트 코드가 필요하다.

테스트의 종류

요건 테스트에 대해 검색해보면 많이 보이는 그림이다.

우리가 XCTest 프레임워크를 통해 기본적으로 만든 테스트는 대부분 유닛테스트이고 피라미드 위로 올라갈 수록 점점 사용자가 사용하는 것과 유사해지며 테스트하는 범위가 많아져서 자동적으로 테스트의 수는 줄어든다.

(테스트의 수는 줄어들고 커버하는 코드 자체는 많아진다)

엔드 투 엔드 테스트: 프로덕트 전체 플로우를 사용자 액션과 유사하게 테스트
통합 테스트: 여러 개의 모듈, 소프트웨어를 결합하여 함께 작동하는 방식의 테스트
유닛 테스트: 객체, 메서드 등 프로덕트의 개별 구성 요소를 테스트

Unit Test 추가하기

Unit Test를 추가하는 것 자체는 아주 간단하다.

새롭게 프로젝트를 생성하는 경우

새로 프로젝트를 생성하는 경우는 아래처럼 Include Tests를 체크한 후 생성을 해주면 Test Target이 자동으로 추가된다.

이미 생성된 프로젝트에 테스트를 추가하는 경우

아래 이미지처럼 빨간색으로 표시된 부분을 눌러주면 된다.

좌측 Navigator에서 Show the Test Navigator를 선택한 후 좌측 최하단의 + 버튼을 눌러 New Unit Test Target을 선택해주면 된다.

새로 Test를 만들면 어떻게 되어 있을까?

import XCTest

final class GitPracticeTests: XCTestCase {
    override func setUpWithError() throws { }

    override func tearDownWithError() throws { }

    func testExample() throws { }

    func testPerformanceExample() throws {
        measure { }
    }
}

import XCTest

https://developer.apple.com/documentation/xctest

XCTest | Apple Developer Documentation

Create and run unit tests, performance tests, and UI tests for your Xcode project.

developer.apple.com

일단 자동으로 XCTest를 import하고 있다.

이는 테스트를 위한 프레임워크로 특정 조건이 충족되었는지 확인 후 이를 기록하게 된다.

기록된 내용은 Show the Test Navigator / Show the Report Navigator에서 확인이 가능하다. (요 부분은 이후 내용에서도 다룰 예정)

XCTestCase

https://developer.apple.com/documentation/xctest/xctestcase

XCTestCase | Apple Developer Documentation

The primary class for defining test cases, test methods, and performance tests.

developer.apple.com

테스트 케이스, 방법, 성능 테스트를 정의하기 위한 기본 클래스이다.

setUpWithError

https://developer.apple.com/documentation/xctest/xctest/3521150-setupwitherror

setUpWithError() | Apple Developer Documentation

Provides an opportunity to reset state and to throw errors before calling each test method in a test case.

developer.apple.com

테스트를 시작하기 위해 필요한 의존성 등을 준비함 (각 테스트가 시작하기 전 호출)

tearDownWithError

https://developer.apple.com/documentation/xctest/xctest/3521151-teardownwitherror

tearDownWithError() | Apple Developer Documentation

Provides an opportunity to perform cleanup and to throw errors after each test method in a test case ends.

developer.apple.com

각 테스트가 끝나고 설정한 값들을 다시 초기화함

그래서 이를 그림으로 표현하자면 이런 식으로 매번 테스트가 시작되기 전 / 후로 실행이 되게 된다.

왜 매번 테스트를 위한 준비를 새롭게 하고 다시 없애는 것일까?

각 테스트는 서로 영향을 주고 받지 않아야하기 때문이다.

테스트 검증을 할 때 특정 객체의 프로퍼티를 통해 하는데 여러 함수에서 해당 프로퍼티를 사용하고 있다면?

함수의 호출되는 순서에 따라서 프로퍼티의 값이 달라질 수 있다.

테스트를 실행하는 순서에 따라 테스트의 성공 여부가 매번 바뀐다면 이는 테스트의 신뢰도를 떨어뜨리는 원인이 될 것이다.

그러므로 테스트를 할 때 기본적으로 새롭게 인스턴스를 만들고 테스트가 끝나면 이를 초기화하는 과정으로 설계가 됐다고 생각한다.

유닛 테스트는 기본적으로 어떻게 이뤄지나?

테스트의 예상 값과 결과 값을 비교하는 방식으로 이뤄진다.

이때 XCTest 프레임워크의 XCTAssert~ 함수들을 사용해 결과를 검증하게 된다.

(XCTAssertEqual, XCTAssertTrue, XCTAssertNoNil 등 다양함)

func add(number1: Int, number2: Int) -> Int {
    number1 + number2
}

func test_add_two_number() {
    let number1 = 1
    let number2 = 3

    let result = add(number1: number1, number2: number2)
    let expectation = 4

    XCTAssertEqual(result, expectation)
}

Test는 새로운 타겟이다?

테스트를 생성해보면 알겠지만 Test는 기존 프로덕트와는 다른 새로운 타겟이다.

따라서 기존 코드의 객체나 함수가 open / public으로 선언되어있지 않다면 이에 접근 자체가 불가능하다.

필요에 따라 접근 제어자를 open / public으로 선언하는 것은 전혀 문제가 되지 않겠지만 테스트 타겟에서 접근하기 위해 접근제어자를 더 높은 수준으로 올리는 것은 옳지 않다.

기존에 외부로 드러나지 않아도 되는 코드를 노출시켜야 하기 때문이다.

설계 시 은닉화를 염두해두고 설계를 한 코드를 높은 수준의 접근 제어자로 올리게 되면 해당 함수나 객체가 외부에 사용될 수 있고, 이는 불필요한 의존 관계를 생성하기 때문에 옳지 않다.

그래서 Apple은 @testable를 제공한다.

@testable

프로젝트의 빌드 옵션을 보면 Enable Testability를 보면 Debug는 yes라고 되어 있다.

이는 컴파일을 할 때 Xcode에 자동으로 enable-testing 플래그를 두고 internal 보다 높은 접근 제어자의 경우 open으로 높여서 외부에서 접근이 가능하도록 한다.

(fileprivate, private으로 선언한 경우 이는 접근제어자가 유지)

이렇게 되면 코드의 수정 없이 테스트 코드 타겟에서 기존 프로덕트 코드에 접근이 가능하게 되며, 간단하게 프로덕트 코드를 테스트할 수 있게 된다.

@testable import {프로덕트 모듈 이름}

사용할 때에는 위 코드처럼 사용을 하면 된다.

단위 테스트 구성

Given - When - Then 패턴

AAA 패턴도 존재하지만 요게 좀 더 직관적으로 이름이 이해되기 때문에 해당 패턴을 주로 사용했다.

func add(_ number1: Int, _ number2: Int) -> Int {
    number1 + number2
}

func test_add_two_number() {
	// Given
    let number1 = 1
    let number2 = 3

	// When
    let result = add(number1, number2)

	// Then
    let expectation = 4

    XCTAssertEqual(result, expectation)
}

Given : 해당 유닛테스트를 위해 필요한 값이나 객체 등을 준비
- setUpWithError는 공통적으로 준비해야 될 부분을 작성하고 여기선 개별적으로 필요한 것들을 준비시킨다
When : 테스트할 메서드 실행
Then : 실행한 메서드의 결과를 검증

이름과 설명을 보면 어느정도 직관적으로 와닿을 것이다.

모든 테스트에 Given / When / Then이 포함되지는 않아도 된다. (Given 같은 경우 상황에 따라 빠질 수도 있음)

이렇게 일정 패턴을 정해두고 테스트 코드를 작성하면 추후 테스트를 확인하거나 다른 사람들이 해당 테스트를 볼 때 가독성이 올라가서 테스트가 코드에 대한 안내를 하는 역할도 좀 더 충실히 할 수 있다.

sut

테스트 코드 예시를 보면 sut라는 단어를 본 적이 있을 것이다.

이는 Swift에서만 사용되는 것이 아니며 소프트웨어 전반에서 공통적으로 사용되는 용어이다.

System Under Test의 줄인말로 테스트를 하게 되는 객체를 정의하게 된다.

즉, 테스트할 대상(객체)인 것이다.

sut의 경우 해당 테스트 전반에서 필요하기 때문에 대부분 setUpWithError에 생성하고 tearDownWithError에서 초기화하는 식으로 구성된다.

테스트 코드 네이밍

네이밍은 항상 어렵다...

테스트는 프로덕의 가이드 라인이 될 수 있기 때문에 네이밍을 잘 하는 것도 중요하다.

언제 메서드가 성공 / 실패를 하고 메서드를 어떻게 사용하면 되는지 테스트 코드를 보면 쉽게 알 수 있는데 네이밍까지 이해하기 좋게 되어 있다면 이런 역할을 더욱 잘 해낼 수 있을 것이다.

비 개발자들이 봤을 때에도 명확히 어떤 행동을 하는지 이해할 수 있는 네이밍
- 엄격하게 네이밍 규칙을 정해두는 것보다는 최대한 이해하기 쉬운 네이밍이 더 나을 수 있음
  (개인적으론 테스트 코드는 예외적으로 한글로 네이밍해도 괜찮은 경우가 있었음)
test는 앞에 항상 붙어야 함
카멜케이스가 아닌 스네이크 케이스로 표기

요 정도를 염두해두고 최대한 이해하기 쉬운 네이밍을 고민해보는 것이 필요한 것 같다.

다양한 방면에서 검증

프로덕트에 문제가 있음에도 테스트가 이를 발견하지 못한다면 이를 거짓 음성이라고 한다.

이는 테스트의 신뢰도를 낮추고, 테스트를 점점 사용하지 않는 길로 갈 수 있는 매우 안 좋은 현상이다.

따라서 테스트를 구성할 때 Then 절을 다양한 방면으로 검증해보는 것이 필요하다.

(테스트가 실패하는 경우도 테스트를 해보는 것이 좋다)

이렇게 하다보면 개인적으로 생각해보지 못했던 사이드 이펙트나 결과도 고민해볼 수 있어 앱 내 버그를 최소화할 수 있다고 생각한다.

이래서 TDD(Test Driven Development)가 나오지 않았나 싶다.

물론 나도 실제 개발에서 TDD를 적용해서 개발을 한 경험은 없지만 이렇게 테스트로 미리 함수나 객체가 실패하는 경우부터 성공하는 경우까지 고려를 하고 개발을 하면 앱의 안정성이 엄청 올라갈 수 있고, 설계에서도 좀 더 좋은 설계가 나올 수 있다고 생각하기 때문이다.

(나는 개발의 속도가 더뎌진다는 측면에서 도입을 해보진 못했다. 따라서 이 부분은 실제 적용하다보면 얻게 되는 장점과 단점에 대해 깊이있게 생각하지 못했을 수 있다)

Test Coverage

테스트 코드가 기존 프로덕트 코드를 얼마나 실행하고 있는지를 나타낸다.

이를 통해 현재 테스트 코드가 프로덕트를 얼마나 검증하고 있는지 알 수 있다.

Test Coverage는 위 이미지의 역할 정도를 한다.

커버리지가 높다고 항상 좋은 것은 아니지만 낮다면 테스트를 추가할 필요가 있다는 것이다.

커버리지는 Show the Report Navigator에서 확인이 가능하다.

이는 Edit Scheme을 선택한 후

Test Plans를 선택한다.

여기서 Configurations 탭을 선택하면 Code Coverage가 on으로 되어 있다.

확인하는 방법이 Xcode가 업데이트를 하면서 이런식으로 변경이 되었다.

비동기 함수 테스트

네트워크 요청같은 작업을 했다면 이에 대한 테스트 코드를 짤 수도 있을 것이다.

이런 네트워크 요청은 다른 스레드에 작업을 시키고 작업 종료를 기다리지 않고 다음 작업을 실행하는 비동기 작업이다.

그래서 기존처럼 테스트를 하다보면 요렇게 통과를 하긴 한다.

하지만 XCTAssert~ 쪽에 브레이크 포인트를 걸어놓고 실행을 시켜보면 브레이크 포인트가 걸리지 않는다.

비동기 작업이기 때문에 작업이 끝나고 실행되는 completionHandler가 호출되기 전에 test_network 함수가 끝나버리면서 검증을 하지 않고 테스트가 통과했다고 나오는 것이다.

즉, 테스트가 제대로 되지 않은 것이다.

XCTestExpectation

이때 사용할 수 있는 것이 XCTestExpectation이다.

https://developer.apple.com/documentation/xctest/xctestexpectation

XCTestExpectation | Apple Developer Documentation

An expected outcome in an asynchronous test.

developer.apple.com

이는 이런 식으로 활용할 수 있다.

일단 XCTestExpectation 인스턴스를 선언한 후 테스트 검증 부분에 조건이 모두 충족한 경우 fulfill 함수가 호출되도록 한다.

그리고 fulfill 함수가 호출될 때까지 wait 함수를 통해 해당 XCTestExpectation를 기다리게 하면 된다.

이렇게 하면 비동기 함수도 테스트가 가능하다.

하지만 이 방식은 외부 환경인 네트워크에 의존적인 테스트이며 테스트에 걸리는 시간도 엄청 길다는 단점이 있다.

네트워크 요청의 경우 기본적인 동기 함수들에 비해 시간이 엄청 오래 걸리기 때문이다.

그래서 이런 방식은 가능은 하긴 하나 권장되는 방식은 아니다.

다른 테스트에 영향을 받지 않도록 하는 것처럼 테스트는 무결성을 지녀야 하기 때문이다.

그래서 사용할 수 있는 방법이 Test Double을 활용하는 것이다.

Test Double

테스트는 외부 환경에 의해 결과가 바뀌어선 안 된다
빠르게 실행될 수 있어야 한다.

위 두 조건을 충족하는 테스트를 짜기 위해 Test Double을 활용할 수 있다.

Moya와 Alamofire 같은 외부 라이브러리를 사용한다면 방법이 달라질 수도 있다.

하지만 기본적인 개념 자체는 동일하며 이번 포스팅에선 URLSession을 기반으로 설명하고자 한다.

Mock과 Stub

Mock의 경우 행동 검증이다. ex) URLSession의 dataTask 함수 동작을 대체
Stub의 경우 상태 검증이다. ex) 통신을 통해 오는 데이터 자체를 대체

이 2가지 개념은 혼용되어서 사용하는 경우들이 종종 있고, 나 또한 그런 경험이 있어 잘 분류하고 사용하는 것이 중요하다.

1. URLSession 추상화하기

일단 URLSession을 MockURLSession으로 대체해서 사용해야 하기 때문에 이를 한 번 추상화해놓는 것이 좋다.

예제에선 URLSession의 dataTask 함수만 프로토콜에 정의해놓고 사용했는데 추가로 반드시 정의해야 하는 함수가 존재한다면 미리 정의를 해놓아도 무방하다.

import Foundation

protocol URLSessionProtocol {
    func dataTask(
        with request: URLRequest,
        completionHandler: @escaping @Sendable (Data?, URLResponse?, Error?) -> Void
    ) -> URLSessionDataTask // 기존 dataTask 함수와 동일
}

extension URLSession: URLSessionProtocol { }

2. 이를 사용하는 객체 생성

추상화한 URLSession을 사용할 수 있는 객체를 생성한다.

이를 초기화할 때 Mock으로 대체해서 사용하도록 구현한다.

예제를 위한 코드로 누락된 에러 처리나 좀 더 나은 에러 처리 방식이 존재할 수 있습니다.

import Foundation

final class NetworkManager {
    private let urlSession: URLSessionProtocol
    
    init(urlSession: URLSessionProtocol = URLSession.shared) {
        self.urlSession = urlSession
    }

    func fetchData<T: Decodable>(
        url: URL,
        decodingType: T.Type,
        completionHandler: @escaping((Result<T, Error>) -> ())
    ) {
        let request = URLRequest(url: url)
        let task = urlSession.dataTask(with: request) { data, response, error in
            let successStatusCode = 200..<300
            guard
                let httpResponse = response as? HTTPURLResponse,
                successStatusCode.contains(httpResponse.statusCode)
            else {
                if let error {
                    completionHandler(.failure(error))
                } else {
                    let statusCodeError = NSError(
                        domain: "Network",
                        code: 0,
                        userInfo: [NSLocalizedDescriptionKey: "StatusCode Error"]
                    )
                    completionHandler(.failure(statusCodeError))
                }
                return
            }
            
            if let error {
                completionHandler(.failure(error))
            }
            
            if let data {
                let decodedData: T
                do {
                    decodedData = try JSONDecoder().decode(T.self, from: data)
                    
                    completionHandler(.success(decodedData))
                } catch {
                    let decodingError = NSError(
                        domain: "Decoding",
                        code: 0,
                        userInfo: [NSLocalizedDescriptionKey: "Decoding Error"]
                    )
                    completionHandler(.failure(decodingError))
                }
            }
        }
        
        task.resume()
    }
}

3. MockURLProtocolClass 만들기

import Foundation

final class MockURLProtocol: URLProtocol {
    static var requestHandler: ((URLRequest) throws -> (HTTPURLResponse, Data) )?

    override class func canInit(with request: URLRequest) -> Bool {
        return true // request를 처리할 수 있는지 확인하는 부분, Mock이므로 항상 가능하도록 선언
    }

    override class func canonicalRequest(for request: URLRequest) -> URLRequest {
        return request // 동일한 Request인지 확인하고 캐시 작업을 하는 부분인데 여기도 바로 request 전달
    }

    override func stopLoading() { } // request를 호출하는 작업이 중지되며 이후 동작을 정의

    override func startLoading() { // URLProtocolClient로 어떻게 request를 처리할 지 정의
        guard let handler = MockURLProtocol.requestHandler else {
            return
        }
        do {
            let (response, data)  = try handler(request)
            client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)
            client?.urlProtocol(self, didLoad: data)
            client?.urlProtocolDidFinishLoading(self)
        } catch  {
            client?.urlProtocol(self, didFailWithError: error)
        }
    }
}

가장 초반에 선언된 requestHandler는 나중에 Request를 받아서 어떻게 처리할 지 정의해주면 된다. (Stub 데이터를 보내도록)

override한 4개 함수는 공식 문서 상에서 반드시 Subclass에서 정의해야 하는 메서드로 나와 있으나, 없어도 실행이 정상적으로 되긴 했다.

일단 Mock 데이터를 간편하게 처리할 수 있도록 따로 캐시 작업 없이 항상 request를 처리하도록 구현해놓았다.

4. 결과로 나올 Stub 파일 생성

이제 결과로 전달할 Stub 파일을 생성한다.

이를 선언해두면 매번 PostMan 등을 통해 결과가 어떻게 전달되는지 확인할 수 있어 문서화의 역할도 할 수 있다.

데이터는 JSON 형태로 오는 경우가 많기 때문에 JSON으로 설명을 하자면 이를 위해선 Strings File을 생성한다.

이는 원래 Localize를 위해 존재하는 파일인데 해당 파일 선택 후 .json으로 확장자까지 작성해주면 JSON 파일을 생성할 수 있다.

(이후에 수정해줘도 변경이 되지 않기 때문에 반드시 생성 시 붙여주세요!!)

여기에 결과로 나올 JSON 형식의 데이터를 적어주면 된다.

5. Network 처리 객체 선언

이제는 테스트를 위해 sut로 네트워크 요청을 처리할 객체를 선언해야 한다.

이 작업은 setUpWithError에서 해주면 된다.

let configuration = URLSessionConfiguration.ephemeral
configuration.protocolClasses = [MockURLProtocol.self]
let urlSession = URLSession(configuration: configuration)

sut = NetworkProvider(session: urlSession)

여기서 URLSessionConfiguration.ephemeral은 캐시 / 인증 / 쿠키에 따로 저장소를 사용하지 않는 URLSession 구성이다. 우리는 Mock을 사용할 것이기 때문에 이걸 사용했다.

그리고 protocolClasses로 선언한 MockURLProtocol의 타입 배열을 할당해주고 이를 통해 URLSession을 만들어주면 된다.

6. 이를 활용한 테스트 코드 작성

    func testExample() throws {
        // Given
        let expectation = XCTestExpectation()
        
        guard
            let path = Bundle(for: type(of: self)).path(forResource: "StubRandomNumber", ofType: "json"),
            let jsonString = try? String(contentsOfFile: path)
        else {
            XCTFail()

            return
        }
        
        let data = jsonString.data(using: .utf8)
        let stubResponse = HTTPURLResponse(
            url: URL(string: "https://csrng.net/csrng/csrng.php?min=0&max=50")!,
            statusCode: 200,
            httpVersion: nil,
            headerFields: nil
        )
        
        MockURLProtocol.requestHandler = { request in
            return (stubResponse!, data!)
        }
        
        // When
        sut?.fetchData(url: URL(string: "https://csrng.net/csrng/csrng.php?min=0&max=100")!, decodingType: [RandomNumber].self, completionHandler: { result in
            switch result {
            case .success(let data):
                XCTAssertEqual(data.first?.min, 0)
                XCTAssertEqual(data.first?.max, 50)
                XCTAssertEqual(data.first?.status, "success")
                XCTAssertEqual(data.first?.random, 45)
                
                expectation.fulfill()
            case .failure(let error):
                XCTFail()
            }
        })
        
        wait(for: [expectation], timeout: 0.5)
    }

그리고 Stub 데이터를 불러와서 이를 utf8 형식의 데이터로 변환후 MockURLProtocol의 requestHandler에서 이 데이터를 항상 내보내도록 구현해주면 끝이다!

이를 활용해 테스트를 해보면 네트워크 요청을 직접 하지 않고 Stub으로 선언한 데이터가 항상 반환된다.

여기서 wait 함수에 0.5초를 기다리도록 해놨지만 실제 걸리는 시간 자체는 0.004초로 이전 1초 이상 걸리던 것에 비해 비약적으로 빨라진 것을 확인할 수 있다.

여기까지 테스트 전반에 대해 쭉 정리를 해보았다.

회사에서도 요새 테스트 코드 도입 / 리팩토링을 하며 만질 일이 많았고, 해당 내용을 가지고 멋쟁이 사자처럼에서 발표까지 진행하면서 다시한 번 개념적인 부분을 정리할 수 있어서 좋았다.

https://ho8487.tistory.com/75

[iOS] Networking Test (Stub) + RxSwift

기존 프로젝트를 다시 MVVM + RxSwift로 리팩토링하면서 다시 Networking 작업을 하고 있다. 저번에는 네트워크와 관련된 테스트 코드를 짜지 못했었는데 이번에는 Stub을 이용해 네트워크에 연결되지

ho8487.tistory.com

이전에 작성한 방식은 예전에 사용하던 방식이라 이렇게 작성하게 되면 코드에 warning이 뜨게 되어 개선된 버전으로 Test Double에 해당하는 방식도 변경해봤다.

(이때는 Stub과 Mock도 혼재해서 사용했군...)

Swift로 테스트를 처음 접하시는 분들에게 많은 도움이 되었으면 좋겠다.

더 늦기 전에 작성하는 2023년 회고

호르댕댕댕 — Thu, 15 Feb 2024 18:00:31 +0900

이미 회고를 적기엔 늦은 날짜이지만 더 늦어지면 아예 안 적을 것 같아서 이제와서 23년 회고를 작성한다.

23년은 큰 변동은 없었던 한 해였고, 정말 시간이 어떻게 간 줄 모르게 빠르게 지나간 한 해였다.

그래도 다시 돌이켜보면 많은 것들을 한 한해인 것 같다.

작년 계획 평가

일단 작년 회고 에서 아래 목록을 계획으로 세웠었는데

[회고] 2022년을 돌아보고 앞으로를 계획해보자 (비전공자의 iOS 개발자를 위한 고군분투)

2022년은 정말 새로운 것들이 많았던 해였다. 진짜 2022년은 한마디로 모든 것이 새로운 한 해 이다. 기존 전공인 부동산학과와도 전혀 무관한 일을 하고 있고, 이전에 했던 인턴인 HR 직무와도 거

ho8487.tistory.com

SwiftUI 공부하기 & 프로젝트 시도하기 (60%)
WWDC 일주일에 한 개 이상 보기 (30%, 특정 주제가 필요할 경우 몰아서 봄)
꾸준히 알고리즘 문제 풀기 ❌ (0%)
컨퍼런스 꾸준히 참여하기 (80%)
운동 꾸준히 하기 (100%)
라이브러리 Contributor 도전하기 ❌ (0%)

실천율이 높진 않은 것 같다. ㅎㅎ

SwiftUI는 연말이지만 공부를 시작하긴 했고, 위젯을 구현하면서 회사 프로젝트에서도 간단하게나마 넣어 봤고, 컨퍼런스는 시간이 되는 대로 참석하긴 했으니 애매한 동그라미를 줬다.

운동 하나는 진짜 꾸준히 한 것 같다..

이렇게 보니 올해를 아쉽게 보낸 것 같기도 하다..

그래도 다른 길로 빠져나가서 노수진 님의 슈퍼앱 운영을 위한 확장성 높은 앱 아키텍처 구축 강의를 듣고 스터디 후 직접 RIBs로 앱을 구현해보기도 했고, 일주일에 1개씩 WWDC 영상을 보진 못했지만, 필요한 주제가 있을 때 몰아서 보기는 했다.

당시 계획을 너무 떠오르는 대로 리스트를 나열하고 마무리했다보니 실천도 제대로 되지 않은 것 같다.

이번에는 좀 더 고민해보고 신중하게 계획을 수립해봐야겠다.

그럼 이제 진짜 올해의 회고 시작!!

23년의 학습 (70점)

학습은 꾸준하게 진행을 했지만 조금 더 많은 것들을 학습하고 적용하지 못했다는 아쉬움에 70점 정도를 줬다.

일단 회사 내에서 Widget, Deferred Deeplink, GitHub Actions 등을 새롭게 학습하고 직접 도입해봤고, Core Data도 이전보다 좀 더 심도 있게 사용해봤다. 그리고 특히 메모리 그래프를 확인해보면서 메모리 릭을 해결하여 고질적으로 발생하던 문제를 완전히 해결한 부분이 가장 기억에 남는다.

Diffable DataSource도 다시 학습해보고 사내 발표까지 진행했지만 아직 프로젝트에 직접 도입은 하지 못하였다. 요 부분은 올해 도입을 해서 reload 시 indexPath가 맞지 않아 버그가 나는 부분까지 해결을 해보고 싶다.

이외에도 개인적으로 네트워크, RIBs, SwiftUI에 대해 학습했다.

(Tuist도 잠깐 찍먹 정도 해봤지만 아직은 학습했다고 하기도 민망한 수준)

22년 말에 테스트 코드를 회사에 도입하고 올해는 이를 잘 관리하기 위해 Github Actions를 도입했었는데 현재 새로 등장한 ViewIsAppearing 메서드를 사용하면서 테스트를 위한 가상 머신 빌드가 안되는 문제가 있었다.

Xcode Cloud를 도입하여 이런 부분을 Xcode Cloud에서 할 수 있도록 하고, 빌드도 이를 통해 할 수 있도록 하는 부분을 현재 검토 중인데 요 부분도 잘 학습하여 팀에 기여해보고 싶다!

23년의 활동 (90점)

일단 23년은 멋쟁이 사자처럼 앱스쿨에서 멘토링 활동을 2기에 걸쳐 진행했다. (1기: 22.12 ~23.02 | 2기: 23.07 ~ 23.11)

그리고 Git 관련 특강도 직접 준비해서 진행해봤다.

이전에 발표 연합 동아리를 하면서 다른 사람들 앞에서 발표를 해보는 경험은 꽤 있었지만 개발 관련 내용을 가지고 사람들 앞에서 발표를 하는 것은 처음이었다.

그리고 부끄럽지만 현직자가 알려주는 신입 iOS 개발자 취업 전 필수 역량을 주제로 유튜브 라이브도 진행했다.

(그린을 처음 뵙고 같이 진행했는데 너무 말씀을 잘해주셔서 감사했습니다)

아직 나도 모르는 부분이 많고 부족한 부분이 정말 많지만 그래도 다른 사람들에게 내가 가진 정보를 공유하는 경험이 좋았던 것 같다. 그리고 발표를 하는 것이다보니 블로깅을 할 때보다 훨씬 자료 조사에 시간도 많이 들어갔고, 이를 통해 스스로도 정리가 잘 됐던 것 같다.

이외에도 카카오 퇴근길 밋업, KWDC 23, 리멤버 / 핀다 / 이스트 소프트와 함께하는 개발 모임 등 다양한 컨퍼런스 및 활동을 진행하면서 다른 개발자 분들은 어떻게 개발을 하고 있는지 이야기를 나눠볼 수 있어 좋았다.

그리고 최근 블로깅이 점점 뜸해지는 것이 느껴져서 글또 활동을 시작했다!

(예거와 애플사이다가 추천해주셔서 활동을 시작하게 됐는데 좋은 활동을 소개시켜주셔서 다시한 번 감사드립니다!)

24년에도 꾸준히 개발 관련 활동을 이어 나갈 수 있도록 해야겠다.

23년의 취미생활 (100점)

개발 관련 회고를 하다가 취미생활이 100점이면 오히려 주객전도가 된 느낌이긴 하다...

하지만 23년은 예~전부터 내가 해보고 싶던 것들을 시작했던 한 해라 그래도 이 부분을 빼놓기는 애매했다.

테니스

22년에 테니스를 시작하고 정말 꾸준하게 테니스를 치고 있다. (꾸준보다는 조금 더 과하게 치는 것 같기도 하다)

회사 동료 분이랑 아마추어 대회도 참가해봤다 (물론 예탈로 3경기만에 집에 돌아왔다)

확실히 운동을 하면 머리가 리프레쉬되는 느낌이 있어서 개발에 아예 도움이 안되진 않는 것 같다...! ㅎㅎㅎㅎㅎㅎㅎㅎ

일렉기타

그리고 중학교 때부터 로망이었던 일렉 기타를 시작했다.

드림 기타였던 펜더도 구매하고, 이펙터 보드도 맞추고, 오디오 인터페이스에 스피커까지...

돈은 꽤 많이 깨졌지만... 그래도 오래 전부터 해보고 싶었던 것들이라 행복하다.

독학으로 기타를 쳐오면서 나는 악기에 재능이 없나 했었는데 막상 하니 그렇진 않은 것 같다.

혼자 일본 여행

혼자서 여행, 더군다나 혼자서 해외여행은 난생 처음이었다.

처음이라 기간을 2박 3일로 짧게 잡았었는데 지금까지의 어떤 여행보다 만족스러웠다.

지금까지 자취도 해본 적이 없다보니 혼자 오롯이 시간을 다 쓰는 경험이 없었는데 그런 경험이 너무 좋았다. 내가 먹고 싶은 것, 가고 싶은 것들을 마음 이끌리는 대로 하는 것이 정말 좋았다.

이때부터 일본어를 알면 좀 더 재밌게 다닐 수 있을 것 같아 듀오링고 앱을 통해 일본어 공부도 하고 있다. (현재 92일째 꾸준히 공부중)

24년에도 혼자 여행은 다시 한 번 꼭 해보고 싶다.

내년 계획

테스트 코드 커버리지 늘리고 리팩토링하기
- 테스트 코드 스터디
비즈니스 임팩트가 있는 코드 구현하기
SwiftUI 스터디
iOS 컨퍼런스 1회 이상 참여하기
WWDC 영상 월 1회 보기
블로그 2주에 1번씩 글 작성하기
꾸준히 운동하기 (테니스 대회 본선 진출하기)
혼자 여행가기
꾸준히 일본어 공부하기

Swift를 기반으로 본 SOLID에 대하여 (객체지향 설계 원칙)

호르댕댕댕 — Sat, 3 Feb 2024 10:42:37 +0900

객체 지향 언어를 사용하다보면 반드시 듣게 되는 원칙 중 하나가 바로 SOLID이다.

(Swift도 객체 지향 언어 중 하나인 만큼 SOLID는 공부하면 만나게 되는 것 중 하나이다)

제르시 님이 정리해주신 iOS 면접 질문 리스트 중에서도 SOLID는 등장한다.

https://github.com/JeaSungLEE/iOSInterviewquestions

GitHub - JeaSungLEE/iOSInterviewquestions: ‍ ‍ iOS 면접에 나올 질문들 총 정리

‍ ‍ iOS 면접에 나올 질문들 총 정리 . Contribute to JeaSungLEE/iOSInterviewquestions development by creating an account on GitHub.

github.com

항상 공부는 했지만, 막상 말하려 하면 단일 책임의 원칙(Single Responsibility Principle)만 생각나는 SOLID...

이 참에 정리를 해보고자 한다.

물론 SOLID 원칙에 대한 블로그 포스팅은 이미 차고 넘치지만... 스스로도 기록하면서 좀 더 잘 알기 위해 정리를 해보기로 했다.

SOLID 원칙

바로 각각의 원칙으로 들어가기 전에 간단히 SOLID 원칙에 대해 살펴보자.

일단 SOLID는 객체 지향 프로그래밍을 하면서 어떻게 설계하면 좋은 지에 대해 5가지 원칙으로 정리한 것이다.

이를 통해 객체를 좀 더 확장하기 쉽도록 하고 가독성이 좋도록 할 수 있다.

이는 다음 5가지 원칙으로 구성되어 있고 SOLID는 이 원칙들의 앞 글자만 가지고 온 것이다.

Single Responsibility Principle : 단일 책임의 원칙
Open / Closed Principle : 개방 폐쇄 원칙
Liskov Substitution Principle : 리스코프 치환 원칙
Interface Segregation Principle : 인터페이스 분리의 원칙
Dependency Inversion Principle : 의존성 역전의 원칙

Single Responsibility Principle (단일 책임의 원칙)

단일 책임의 원칙은 이름에서도 보이는 것처럼 객체는 하나의 책임만 가져야 한다는 것이다.

즉, 이는 객체를 변경할 이유가 생긴다면 이유는 한 개가 되어야 하는 것이다. 앞서 말했던 것처럼 하나의 책임만 가져야 하기 때문에 해당 책임에 대한 수정이 있을 때에만 객체를 수정해야 한다.

이를 통해 사이드 이펙트를 최소화할 수 있다.

물론 현재 객체의 설계 원칙인 SOLID에 대해 이야기를 하고 있긴 하나 함수 / 모듈에서도 적용이 되는 개념이다.

함수 또한 다양한 책임을 가지고 있으면 해당 함수로 인한 사이드 이펙트가 발생할 가능성도 높아지고 테스트 코드를 작성하기에도 어려움이 있기 때문에 단일 책임의 원칙을 적용시키는 것이 중요하다.

func add(num1: Int, num2: Int) -> Int {
    let answer = num1 + num2
    print(answer)

    return answer
}

예를 들어 2개의 파라미터를 받아서 이를 더해주는 간단한 함수가 있다고 가정해보자.

이때 해당 함수 내부에는 결과값을 print해주는 기능까지 포함되어 있다.

(예제여서 간단한 print를 사용했지만 실제 프로덕트를 만들 때에는 Google Analytics에 결과값을 전달하거나 하는 기능이 있을 수 있다)

그렇다면 하나의 함수가 값을 더하는 기능 외에도 print를 하는 기능까지 2가지 책임이 존재하는 것이다.

따라서 이는 단일 책임의 원칙을 위배했다고 볼 수 있다.

이를 좀 더 넓은 개념으로 객체에 동일시켜도 객체를 캡슐화한 후 설계할 때 1개 이상의 책임을 가지고 있다면 단일 책임의 원칙을 위배하는 것이다.

실제 개발을 하다보면 이를 매번 철저하게 준수하는 것은 쉽지 않다.

책임에 맞게 함수나 객체를 분리해야 하고 이로 인해 개발에 공수가 늘어날 수 있기 때문이다.

하지만 여러 책임이 혼재되어 있는 경우 일단 하나의 객체 / 함수에 들어가 있는 코드의 절대적인 양 또한 증가하게 되면서 가독성이 떨어지게 된다.

또한 앞서 말했던 것처럼 테스트 코드를 작성하는 데에도 어려움이 생긴다.

이를 준수하기 위해선 객체 / 함수를 설계할 때 정확히 추상화 / 캡슐화를 하고 설계를 하는 것도 도움이 되겠지만 러프한 기준을 세워본다면 객체와 함수의 Line 수에 상한을 두는 것도 방법이 될 수 있다.

그래서 SwiftLint에서도 File / 객체 / 함수의 길이에 기본적인 제한을 둔 것이 아닌가 생각이 든다.

https://realm.github.io/SwiftLint/rule-directory.html

Rule Directory Reference

realm.github.io

- File Length

warning	400
error	1000

- Function Body Length

warning	50
error	100

- Type Body Length

warning	250
error	350

Open / Closed Principle (개방 폐쇄의 원칙)

확장에는 열려있고 변경에는 닫혀있어야 한다는 원칙이다.

하지만 이 설명은 나에게 너무 추상적이다... 좀 더 구체적으로 알아보자.

개발을 하다보면 요구사항이 변경되는 경우가 종종(자주...?) 발생한다.

이때 변경으로 인한 비용은 가능한 줄이고(Closed), 기존 구성 요소를 쉽게 확장(Open)하여 재사용이 가능하도록 해야 한다는 것이다.

코드를 통해 좀 더 살펴보자.

class Guitar {
    enum Shape {
        case lespaul
        case strat
    }
    
    let shape: Shape

	init(shape: Shape) {
    	self.shape = shape
    }
    
    func pickUp() -> String {
    	switch shape {
        case .lespaul:
        	return "humbucker"
        case .strat:
        	return "single"
        }
    }
}

Guitar(shape: .lespaul).pickup() // "humbucker"
Guitar(shape: .strat).pickup() // "single"

요렇게 기타 타입에 따라 어떤 픽업이 달려있는지를 보여주는 Computed Property가 있다고 생각해보자.

(요새 기타에 빠져서... 예시도 기타로 들었는데 생소한 용어라도 그냥 요런게 있구나 하고 예시로만 봐주세요~)

만약 Guitar의 Shape에 종류가 추가된다고 가정해보자.

그러면 Shape 열거형에도 값을 추가해야 하고 pickUp이라는 프로퍼티도 수정을 해줘야 한다.

변경 사항이 생겼을 때에는 Closed되어야 하는데 수정이 필요해진 것이다.

따라서 위 코드는 개방-폐쇄 원칙(OCP)을 위배한 사례로 볼 수 있다.

이를 해결하기 위해선 프로토콜을 통해 추상화를 해서 해결 가능하다.

protocol Guitar {    
    func pickUp() -> String
}

class Lespaul: Guitar {    
    func pickUp() -> String {
		return "humbucker"
    }
}

class Strat: Guitar {
	func pickUp() -> String {
		return "single"
    }
}

Lespaul().pickup() // "humbucker"
Strat().pickup() // "single"

이렇게 구현하면 어떤 기타 종류가 추가되든 기존 프로토콜을 수정하지 않고 확장이 가능하다.

Liskov Substitution principle (리스코프 치환의 원칙)

다른 원칙들은 이름을 보면 그래도 어떤 원칙인지 대략 짐작이라도 가는데 요 원칙은 전혀 감이 오지 않는 원칙이다.

위키 백과에선 요렇게 어렵게 설명을 하고 있다.

컴퓨터 프로그램에서 자료형 S가 자료형 T의 서브타입라면 필요한 프로그램의 속성의 변경 없이 자료형 T의 객체를 자료형 S의 객체로 교체할 수 있어야 한다는 원칙

이는 위에서 들었던 기타 예시로 좀 더 풀어서 보자면

기타에는 Lespaul과 Strat 등 하위 타입들이 존재하고 기존 기타를 Strat으로 바꾸더라도 잘 동작해야 한다는 것이다.

즉, 어떤 타입의 기타든 연주라는 기능은 잘 수행이 되어야 하는 것이다.

class Guitar {
    func play() {
        print("딩가딩가")
    }
}

class Strat: Guitar {
    override func play() {
        print("징징징")
    }
}

var guitar = Guitar()
guitar.play() // "딩가딩가"

guitar = Strat()
guitar.play() // "징징징"

부모 클래스 타입인 guitar 프로퍼티가 자식 클래스로 대체되더라도 기본적으로 play는 동작을 잘 하는 것을 볼 수 있다.

이런 식으로 부모 클래스를 자식 클래스로 대체하더라도 정상적으로 동작을 해야 한다는 원칙이 리스코프 치환 원칙이다.

이는 위에서 설명한 개방 폐쇄의 원칙(OCP)와도 관련이 있으며 리스코프 치환 원칙을 위반할 경우 OCP 또한 위반할 가능성이 높아진다.

새로운 하위 타입이 상위 클래스를 대체할 수 없도록 구현이 된다면 계속해서 상위 클래스에 대한 수정이 필요할 것이고 그렇다면 이는 OCP를 위반한 것이기 때문이다.

Interface Segregation (인터페이스 분리 원칙)

객체는 반드시 자신이 이용하는 메서드만 의존해야 한다는 원칙이다. 즉 상속으로 인해 불필요한 구현을 최대한 방지하도록 하는 것이다.

이를 위해선 인터페이스를 너무 큰 단위로 만들지 말고 작게 분리하는 것이 좋다.

protocol Guitar {
    func stroke()
    func arpegio()
}

class Lespaul: Guitar {
    func stroke() { }
    func arpegio() { }
}

class Strat: Guitar {
    func stroke() { }
    func arpegio() { }
}

Swift에선 Interface가 따로 없지만 프로토콜과 유사한 개념으로 볼 수 있다.

그렇다면 만약 드럼처럼 따로 스틱으로 칠 수도 있는 기타가 있다고 가정해보자...

이를 프로토콜로 구현하면 다음과 같을 것이다.

protocol DrumGuitar {
    func stroke()
    func arpegio()
    func beat()
}

class Lespaul: DrumGuitar {
    func stroke() { }
    func arpegio() { }
    func beat() { } // 사용하지 않는 함수도 구현을 해줘야 함
}

class Strat: DrumGuitar {
    func stroke() { }
    func arpegio() { }
    func beat() { } // 사용하지 않는 함수도 구현을 해줘야 함
}

class NewTypeGuitar: DrumGuitar {
    func stroke() { }
    func arpegio() { }
    func beat() { }
}

이렇게 인터페이스를 너무 크게 구현을 해놓는다면 Lespaul과 Strat처럼 사용하지 않는 함수를 저렇게 구현해놔야 한다.

즉, 인터페이스 분리의 원칙을 위반한 것이다.

이는 프로토콜을 쪼개는 식으로 해결이 가능하다.

protocol Guitar {
    func stroke()
    func arpegio()
}

protocol Drum {
    func beat()
}

class Lespaul: Guitar {
    func stroke() { }
    func arpegio() { }
}

class Strat: Guitar {
    func stroke() { }
    func arpegio() { }
}

class NewTypeGuitar: Drum, Guitar {
    func stroke() { }
    func arpegio() { }
    func beat() { }
}

이렇게 프로토콜을 분리해준 후 필요한 프로토콜만 채택하는 식으로 한다면 인터페이스 분리의 원칙을 위배하지 않고 구현이 가능하다.

특히 프로토콜은 상속과는 다르게 다중 채택이 가능하기 때문에 이런 구현이 가능하다.

Dependency Inversion (의존성 역전)

일단 의존성이란 파라미터나 리턴 값, 지역 변수 등으로 다른 객체를 참조할 때 발생한다.

즉, 다른 객체를 사용했다면 일단 의존성이 생긴 것이다.

객체 지향 프로그래밍을 기반으로 프로덕트를 설계한다면 객체 간 소통을 통해 동작을 하기 때문에 이런 의존성은 거의 필수로 발생하게 된다.

기타는 이런 식으로 다양한 구성 요소로 이뤄져 있다.

class GuitarShop {
    let electric: Electric
    let acoustic: Acoustic
    let classic: Classic
}

class Electric {

}

class Acoustic {

}

class Classic {

}

그렇다면 GuitarShop은 High level 객체이고 하위에 있는 Electric / Acoustic / Classic 들은 Low level 객체인 것이다.

그리고 GuitarShop은 Electric, Acoustic, Classic에 의존성을 가지게 된다.

만약 여기서 기타의 종류가 추가된다고 생각해보자. 이렇게 되면 의존성이 점점 많아지고, 그럼 코드의 변경과 확장에 불리해지게 된다.

이를 해결하기 위해 Dependency Inversion을 사용할 수 있다.

class GuitarShop {
    let guitars: [Guitar] = [] // Guitar에만 Dependency를 가지고 있음
    func add(guitar: Guitar) {
    	guitars.append(guitar)
    }
}

protocol Guitar {
    var guitarString: String { get set }
    func play()
}

class Electric: Guitar {
    var guitarString: String = "iron"
    func play() {
    	print("좡좡좡")
    }
}

class Acoustic: Guitar {
    var guitarString: String = "thick iron"
    func play() {
    	print("띵가띵가")
    }
}

class Classic: Guitar {
    var guitarString: String = "nylon"
    func play() {
    	print("띵띵")
    }
}

이런 식으로 되면 High level 객체인 GuitarShop은 프로토콜인 Guitar에만 의존성을 가지고 있고 각각 Electric / Acoustic / Classic에는 의존성을 가지고 있지 않게 된다.

따라서 이후 Guitar 종류가 추가되더라도, GuitarShop은 수정될 필요가 없게 되면서 확장에는 유리하고 코드 변경은 최소화할 수 있게 되는 것이다.

이는 RIBs를 살펴보면 요런 구조로 잘 구현이 되어 있다.

물론 SOLID 원칙을 전부 철저하게 준수하면서 회사에서 개발을 해나가는 것은 정말 쉽지 않다. 이미 의존성이 엄청 엮여있을 수도 있고 빠르게 피쳐를 진행해야 해서 미쳐 적용을 못할 수도 있다.

하지만 막상 정리하고 보니 좋은 코드라고 생각했던 기준들이 대부분 SOLID에 적용이 됐다.

항상 적용은 하지 못하더라도 이를 인지하고 신경을 쓰면서 앞으로 개발을 할 수 있도록 해야겠다.