Swift Mentorship Program 참여 후기

Swift Mentorship Program이 얼마 전에 끝이 나서 이 프로그램에 참여한 후기를 작성해보려고 합니다!

글은 편하게 그냥 써볼게욥

 

그럼 시작해보겠습니다~!

 

Swift와 SwiftUI로 앱을 개발하면서 자연스럽게 Swift open source에도 관심이 생겼다.

Swift가 오픈소스 언어라는 사실은 알고 있었지만, 정작 Swift가 어떤 과정을 거쳐 발전하는지, 오픈 소스 레파지토리에는 어떻게 참여할 수 있는지 알지 못했다.

 

GitHub에서 Swift 관련 레파지토리를 열어본 적은 있었지만 수많은 폴더와 이슈를 보고 있으면 어디서부터 시작해야 할지 막막했다.

그러던 중 Swift Mentorship Program을 알게 됐다.

 

프로그램에 지원하면서 Swift 오픈소스 생태계가 움직이는 방식을 알아보고 싶었다. 낯선 레파지토리를 탐색하는 방법과 contribution의 전체 과정을 배우고, 가능하다면 Apple·Swift repository에 첫 Pull Request도 제출해 보고 싶었다.

Swift Mentorship Program이란?

Swift Mentorship Program은 전세계에 있는 Swift community에 참여하고 싶은 멘티와 경험이 있는 멘토를 연결해 주는 프로그램이다. 그래서 멘토나 멘티가 같은 국적의 사람이 아니라 다른 나라의 사람들이 만나게 된다.

 

참여하기 전에는 구체적이진 않더라도 얼추 커리큘럼과 과제가 있을 것으로 생각했다. Mentor가 매주 공부할 내용을 알려 주고, 그 과정을 따라가다 보면 마지막에는 자연스럽게 open source contribution까지 도달하는 모습을 예상했다.

 

실제로 참여해 보니 내가 생각한 것과는 조금 달랐다.

 

모든 멘티에게 동일한 과제가 주어지는 것이 아니라 각자 관심 있는 주제와 목표를 정해야 했다. 멘토는 정답이나 다음 할 일을 바로 알려 주기보다, 멘티가 스스로 탐색할 수 있도록 자료를 공유하고 질문을 던졌다.(추측하기로는 멘토 성향에 따라서 다를지도..?)

 

따라서 미팅 전에는 그동안 무엇을 살펴봤는지, 어디에서 막혔는지, 다음에는 무엇을 시도해 보고 싶은지 정리해야 했다. 누군가가 정해 준 과정을 따라가는 것이 아니라 내가 학습의 방향을 만들어 가야 하는 프로그램이었다.

어디서부터 해야 하는 거죠..?

프로그램에 참여하기 전에는 오픈 소스 contribution을 상당히 큰 작업이라고 생각했다.

 

성능을 개선하거나 새로운 기능을 구현하고, 눈에 보이는 버그를 해결해야 contribution이라고 생각했다. 그러다 보니 충분한 실력을 갖춘 뒤에야 시작할 수 있는 일처럼 느껴졌다.

 

레파지토리를 어떻게 탐색해야 하는지도 몰랐다.

• Source code를 처음부터 읽어야 할까?
• 어떤 Issue가 첫 contribution으로 적합할까?
• 코드를 수정하기 전에는 무엇을 확인해야 할까?
• 내 변경 사항은 어떤 과정을 거쳐 project에 반영될까?

Swift Forums와 Swift Evolution도 접해 본 적이 없었다. Swift를 사용해 앱은 만들고 있었지만, 새로운 기능이 어디에서 제안되고 어떤 논의를 거쳐 언어에 포함되는지는 알지 못했다.

 

그래서 프로그램을 통해 다음과 같은 경험을 해보고 싶었다.

• Swift open source ecosystem이 움직이는 방식 알아보기
• 낯선 repository를 탐색하는 방법 배우기
• Issue부터 Pull Request와 Review까지 이어지는 과정 경험하기
• 실제 Apple·Swift repository에 첫 Pull Request 제출하기

당시에는 마지막 목표가 가장 중요하다고 생각했다.

이것도 contribution이라고요?

프로그램에 참여하고 가장 먼저 달라진 것은 contribution의 크기를 바라보는 기준이었다.

새로운 기능이나 복잡한 bug fix만 contribution인 것은 아니었다. Documentation의 오타를 수정하거나, 모호한 표현을 더 명확하게 바꾸거나, 문제를 재현해 Issue에 정보를 추가하는 일도 project에 기여하는 방법이었다.

 

작아 보이는 변경도 누군가에게는 필요한 일이었다.

 

이 사실을 알고 나니 ‘더 잘하게 된 다음 시작해야 한다’는 부담이 조금 줄었다. 중요한 것은 얼마나 큰 코드를 작성했는지가 아니라 project에 필요한 문제를 발견하고, 기존 규칙에 맞게 개선하는 과정이었다.

 

오픈 소스 contribution을 거창한 결과가 아니라 작은 참여가 이어지는 과정으로 보기 시작했다.

시작을 위한 README와 CONTRIBUTING, Good First Issue

처음에는 레파지토리를 이해하려면 해당 레파지토리의 소스 코드가 어떻게 구성되어 있는지부터 읽어야 한다고 생각했다. 하지만 아무런 기준 없이 코드를 읽기 시작하니 현재 보고 있는 코드가 어떤 역할을 하는지조차 파악하기 어려웠다.

 

내 멘토는 오픈 소스에 접근할 때 먼저 관심 있는 레파지토리를 고르고 해당 레파지토리의 README와 CONTRIBUTING, Good First Issue를 보는 것을 권했다.

관심 있는 repository 찾기
→ README로 project의 목적과 구조 파악
→ CONTRIBUTING으로 contribution 규칙 확인
→ Local에서 build와 test 실행
→ 기존 Issue와 discussion 탐색
→ 접근할 수 있는 작은 contribution 후보 찾기

README와 CONTRIBUTING은 단순한 안내문이 아니었다. Project가 무엇을 해결하는지, 어떤 방식으로 운영되는지, contributor에게 무엇을 기대하는지 알려 주는 첫 번째 지도였다.

 

Local build와 test도 단순한 준비 작업이 아니었다.

변경하기 전의 정상 상태를 알아야 이후에 발생한 failure가 기존 문제인지, 내가 만든 regression인지 구분할 수 있었다. Issue와 discussion을 확인하는 과정에서는 이미 누군가 작업하고 있는지, 어떤 해결 방향이 논의됐는지, 현재 내 역량으로 접근할 수 있는 문제인지 살펴볼 수 있었다.

 

Good First Issue는 수많은 Issue 가운데 첫 contribution 후보를 좁혀 주는 또 하나의 입구였다. 비교적 범위가 작거나 문제의 맥락이 정리되어 있어 처음 참여하는 contributor가 접근해 볼 만한 Issue에 붙는 label이었다. 이 label을 기준으로 후보를 찾은 뒤에는 Issue의 설명과 관련 discussion을 읽고, 이미 담당자가 있는지, 최근에도 논의가 이어지고 있는지, 로컬에서 문제를 재현할 수 있는지를 확인했다.

 

다만 Good First Issue라고 해서 반드시 쉬운 문제라는 뜻은 아니었다. 레파지토리마다 기대하는 배경지식과 개발 환경이 달랐고, 오래전에 등록되어 현재 상황과 맞지 않는 Issue도 있을 수 있었다. Label만 보고 바로 코드를 수정하기보다, 내가 문제를 이해하고 재현할 수 있는지 확인하고 필요하면 maintainer에게 작업 가능 여부를 묻는 과정이 필요했다.

공부할 게 너무 많은데 어디서부터 해야 하지..?

레파지토리를 고르고 문서를 읽으며 build와 test까지 실행했지만, 다음 단계로 쉽게 넘어가지는 못했다.

 

레파지토리에서 모르는 개념을 하나 발견해 공부하면 또 다른 개념이 연결됐다. 무엇부터 공부해야 하는지, 어느 정도 이해해야 실제 contribution을 시작할 수 있는지 판단하기 어려웠다.

 

모든 개념을 먼저 공부하려고 하면 끝이 없을 것 같았다. 그렇다고 제대로 이해하지 못한 채 코드를 수정하고 싶지도, 할 수도 없었다.

 

결국 애플 아카데미의 테크 멘토 재성에게 멘토링을 요청했다. 재성과 함께 아카데미에서 사용하는 교육 프레임워크인 Challenge Based Learning(CBL)을 적용해 학습 방향을 다시 정리했다.

 

당시 화이트보드에 적은 질문은 다음과 같았다.

화이트보드에서 다시 세운 질문

 

Big Idea: 오픈소스
Essential Question: 어떻게 하면 오픈소스 기여 과정을 알 수 있을까?

 

이 질문을 바탕으로 조사할 내용도 구체화했다.

1. 특정 repository에 직접 기여해 본다.
2. 직접 open source project를 만들어 본다.
3. Issue → Pull Request, README, Documentation, Swift Package, CI, Testing과 Code Style이 전체 과정에서 어떤 역할을 하는지 조사한다.

막연했던 목표도 조금 더 구체적으로 바뀌었다.

 

Challenge 5에서 하고 있는 개인 프로젝트에 Swift Package를 적용해보면서 오픈 소스 기여 과정에서 필요한 개념들을 익혀가고 오픈 소스에 들어가는 코드들은 어떤 걸 고려하고 작성해야 하는지 직접 경험해보기로 했다.

 

(재성과 CBL 그저 빛...)

직접 Swift Package를 만들어 보자!

Apple Developer Academy의 Challenge 5는 개인 챌린지였다.

 

나는 우선 이 프로젝트에서 앱의 Design System을 Swift Package로 분리해 보기로 했다.

처음에는 단순하게 생각했다.

재사용할 수 있게 분리하면 관리하기 편하고, 성능도 자연스럽게 좋아지지 않을까?

 

직접 분리해 보니 전혀 그렇지 않았고, 내가 생각하는 것과는 많이 달랐다.

 

우선 Product, Target, Module, dependency의 관계를 이해해야 했다. Package 밖에서 무엇을 사용할 수 있도록 공개할지, 접근 제어와 Public API의 경계도 결정해야 했다.

 

Package로 분리했다는 사실만으로 성능이 좋아지는 것도 아니었다. 성능 개선을 말하려면 build와 runtime을 구분하고, 무엇을 개선하려는지와 어떤 조건에서 측정했는지를 함께 설명해야 했다.

 

무엇보다 “이 코드를 다른 사람이 사용한다면 어떨까?”라고 생각하자 이전에는 보이지 않던 문제들이 보였다.

 

한 번 공개한 API와 dependency는 Package를 사용하는 사람의 코드에 영향을 준다. 재사용 가능한 코드를 만드는 것은 편의를 얻는 일인 동시에, 변경에 대한 책임을 갖는 일이었다.

 

이 경험을 통해 공부를 모두 마친 뒤 실전에 들어가는 것만이 방법은 아니라는 것을 알게 됐다. 실제 project에서 문제를 만나고, 그 문제를 따라 필요한 Fundamental을 공부하는 방식도 가능했다.

계속 “왜?”를 달면서 공부해보자

프로그램 후반에는 SwiftUI Diffing과 ForEach의 stable identity를 공부했다.

 

당시 나는 ForEach에서 stable ID를 사용하면 성능에 도움이 된다는 결론을 알고 있었다. 사용법도 알고 있었기 때문에 어느 정도 이해하고 있다고 생각했다.

 

하지만 내 멘토는 그 결론에서 멈추지 않고 계속 질문했다.

• 왜 stable identity가 필요한가?
• SwiftUI는 update 전후의 View를 어떻게 연결하는가?
• View 값이 다시 생성되는 것과 identity가 유지되는 것은 어떻게 다른가?
• Public interface에서 확인할 수 있는 사실은 어디까지인가?
• Framework 내부 구현을 알 수 없다면 무엇을 근거로 설명해야 하는가?

질문에 바로 답하지 못했다.

 

돌아보니 내가 알고 있던 것은 원리보다 결과에 가까웠다. 'Stable ID를 사용하면 좋다'는 결론은 기억하고 있었지만, 어떤 과정으로 그런 결과가 만들어지는지 설명하지 못했다.

 

그 뒤부터 새로운 개념을 만나면 알고 있는 결론에 질문을 붙이기 시작했다.

왜 이렇게 되는 거지?
왜 이렇게 설계되었을까?
실제로는 어떤 과정으로 동작할까?
내가 확인한 사실은 어디까지일까?

 

멘토가 바로 정답을 알려 주지 않고 계속 질문했던 이유도 조금씩 이해하게 됐다. 정답을 전달받는 것보다, 질문을 따라가며 내가 알고 있는 내용의 근거를 직접 확인하는 경험이 더 오래 남았다.

프로그램이 끝난 뒤 달라진 것

프로그램에 참여하기 전에는 Pull Request를 제출하면 contribution이 이루어진다고 생각했다.

직접 과정을 살펴보니 그 앞뒤에는 생각보다 많은 일이 있었다.

Repository 이해
→ Contribution 규칙 확인
→ Issue와 discussion 조사
→ 문제 재현
→ Test 작성
→ 최소한의 변경
→ Pull Request와 CI
→ Maintainer의 Review

Contribution은 혼자 정답을 만들어 제출하는 일이 아니었다. 기존 project의 맥락과 설계를 이해하고, 변경이 필요한 이유를 설명하며, test와 review를 통해 다른 사람들과 함께 검증하는 협업 과정이었다.

 

공부하는 방식도 달라졌다.

 

이전에는 API의 사용법이나 ‘이렇게 하면 좋아진다’는 결론을 알면 이해했다고 생각했다. 지금은 그런 결론을 만나면 몇 가지 질문을 더 해본다.

• 왜 필요한가?
• 어떤 전제에서 동작하는가?
• 실제로는 어떤 과정이 일어나는가?
• 어디까지 확인된 사실이고 어디부터 추론인가?
• 작은 code나 test로 직접 확인할 수 있는가?

모든 개념을 공부한 뒤 실전을 시작하려는 생각도 줄었다. 지금은 내가 이해할 수 있는 문제 하나를 선택하고, 그 문제를 따라가며 필요한 개념을 공부하려고 한다.

첫 Pull Request는 아직 남아 있다

프로그램에 참여할 때 목표로 삼았던 첫 Pull Request는 아직 제출하지 못했다.

 

레파지토리를 살펴보고 build와 test를 실행한 뒤, contribution할 Issue를 조사하는 단계까지는 진행했다. 하지만 문제를 재현하고 regression test와 source change를 거쳐 Pull Request를 제출하는 과정은 아직 남아 있다.

 

아쉬움이 없지는 않다. 처음에는 "프로그램이 끝날 때쯤이면 Pull Request 하나 정도는 올려보겠지" 라고 생각했다.

 

하지만 직접 경험해 보니 Pull Request 하나를 제출하는 것보다 그 과정에서 무엇을 확인하고 있는지 이해하는 일이 나에게는 더 필요했다. Repository를 탐색하고, Issue를 분석하고, 문제를 재현하고, test와 review를 거치는 각 단계를 한 번씩 제대로 경험해 보고 싶어졌다.

 

앞으로는 프로그램에서 배운 방법으로 작은 Issue 하나를 끝까지 따라가려고 한다.

Issue 선정
→ Local에서 문제 재현
→ 실패하는 Test 작성
→ 최소한의 수정
→ Pull Request 제출
→ Review 반영

Swift Mentorship Program을 통해 첫 Pull Request를 완성하지는 못했다. 대신 open source contribution이 실제로 어떤 과정으로 이루어지는지 알게 됐고, 그 과정에 접근하는 방법을 배웠다.

 

무엇보다 모르는 문제가 생겼을 때 곧바로 정답부터 찾기보다, 먼저 질문을 만들고 근거를 확인해 보는 경험을 할 수 있었다.

 

이제 남은 일은 그 경험을 실제 contribution으로 끝까지 이어 보는 것이다.