[컨퍼런스] Let's Swift 2022

http://letswift.kr/2022/

LetSwift2022:Swift Playgrounds

처음으로 오프라인 컨퍼런스를 참석했다. 

처음이라 어떤 식으로 진행되나 했었는데 양재 AT 센터 4층 전체를 대관해서 진행됐다! 

 

컨퍼런스는 큰 강의실과 좀 더 작은 강의실 두 군데로 나눠 진행이 됐고, 대부분의 강연은 영상으로 올라오는 것 같다. 

(확실하진 않지만 코드 스쿼드 유튜브에 올라오는 것 같아요...)

https://www.youtube.com/@user-nf9gd7uz9s/videos

코드스쿼드

 

컨퍼런스는 이 순서대로 진행이 됐다. 

확실히 사람들이 SwiftUI와 TCA에 관심이 많아진 것 같았다. 

(그리고 한 번에 이렇게 많은 iOS 개발자를 본 것도 처음이라 신기했고, 다른 사람들이 어떤 기술에 관심을 가지고 있는지에 대해서도 알 수 있었던 좋은 경험이었다)

 

그리고 현대 자동차, 라인, 원티드, 당근마켓, 플로에서도 부스를 운영하며 다양한 굿즈와 채용 관련 내용도 접할 수 있었다. 

 

---

들었던 강연 모두 좋았지만 좀 더 와닿았고, 현재 하는 작업들과 관련된 세션을 정리해보고자 한다. 

 

# Certifiacte와 Provisioning Profile - 강수진님

컨퍼런스에 참여해 가장 먼저 들은 세션이었다. 

 

배포와 빌드를 위해 반드시 필요한 것들로 이름은 익숙하지만 이 둘의 차이는 사실 명확하게 모르고 있었다.

Xcode의 Targets > Signing & Capabilities를 보면 Provisioning Profile과 Signing Certificate를 찾아볼 수 있다. 

그리고 보통 Xcode가 이를 자동으로 관리하도록 체크를 해둔다. 

(이렇게 체크하게 되면 설명에도 나와있지만 Certificate와 Provisioning Profile을 Xcode가 자동으로 생성하고 업데이트하게 된다)

 

우리가 계약을 할 때 사인을 하게 되면 해당 계약이 변경이 불가하다는 것을 서로 간에 합의한 것이 되는데 코드 서명도 동일한 효과이다. 

코드를 디지털로 서명하게 되면, 누가 해당 코드를 작성했는지, 코드가 서명 이후 변경되지 않았는지(무결성)를 보장하게 된다. 

 

이는 '애플'이라는 신뢰하는 기관에서 합법적인 개발자임을 보장해주게 되는 것이다. 

 

우리는 이러한 Certificate를 받기 위해 키체인을 통해 CSR(Certificate Signing Request)를 받게 된다.

공개키와 개인키 관련 내용도 설명해주셨는데 이 부분은 아직 정확히 이해가 안되서 영상이 올라오면 다시 정리를 해봐야겠다. 

 

그리고 Apple Developer Program에 가입을 하고 애플 인증 서명과 받은 개인키가 합쳐져서 서명 인증서가 된다. 

물론 서명 인증서가 있다 하더라도 iOS 기기에서 실행은 불가능하며 앱스토어에 올라간 앱만 실행이 가능하다. 

 

지금까지는 로컬에 인증서와 개인키가 있어야 이런 작업들이 가능했지만 Xcode 13 이후로는 Cloud-managed certificates를 통해 로컬에 인증서와 개인키가 없더라도 이를 관리할 수 있다. 

https://developer.apple.com/help/account/create-certificates/cloud-managed-certificates/

Cloud-managed certificates - Create certificates - Account - Help - Apple Developer

 

느낀 점

사실 아직 정확하게 Signing Certificate와 Provisioning Profile의 관계와 이들이 어떻게 동작하고 있는지는 이해하진 못했지만, 항상 당연하게 사용하던 것들에 호기심을 갖게 해주었던 세션이었다. 

이에 대해선 좀 더 찾아보고 정리를 해보면 배포 및 빌드를 할 때 인증서를 어떻게 처리하고 있는지에 대한 이해도가 올라갈 수 있을 것 같다. 

 

# 테크 스펙으로 모두가 함께 성장하기 - 류성두님

성두님의 발표는 처음 접했는데 굉장히 발표도 잘하시고 전달하시는 내용이 와닿았다. 

 

일단 우리는 Spec이라는 말에는 굉장히 익숙하다. 물론 다양한 스펙의 정의가 존재하겠지만 개발자로 근무를 하며 스펙은 다음과 같다. 

OO 화면에서 편집 버튼을 누르면 편집 화면이 나온다. 

우리는 이를 명세라고도 한다. 

실제로 일을 하면서 기획서에서 항상 접하게 되는 내용이다. 

 

그렇다면 테크 스펙은 대체 뭘까?

위 명세를 토대로 테크 스펙을 작성해보면 다음과 같다. 

OO ViewController에서 editButton으로 touchUpInside 입력을 받으면 EditViewController를 Push하는 이벤트를 출력한다.

간단하게 버튼을 누르고 특정 화면을 띄우는 명세이지만 생각보다 복잡한 테크 스펙이 작성되게 된다. 

 

그렇다면 우리는 왜 테크 스펙을 귀찮게 써야 하는 것일까?

 

단순히 명세에는 테크 스펙들이 모두 나와 있지 않기 때문에 스펙만으로 일정을 산정하게 되면 정확한 일정을 산정할 수 없게 된다. 

대부분 정확하게 일정 산정을 못하는 경우는 실제 걸릴 시간보다 적은 시간을 산정하여 촉박한 마감 기한을 잡게 된다. 그리고 이는 야근으로 이어지게 된다... 😱

 

그렇다고 기획서를 탓해선 안된다. 

 

기획서에 모든 경우의 수가 담기지 않는 것은 당연하다. 

기획서에서 구멍이 없다는 것은 달리 말하면, 복잡하지 않은 아주 단순한 제품을 만들었다고 볼 수도 있다. 

또 완벽한 기획서를 만들다가 시간이 다 가버린다. 

 

그렇다면 테크 스펙을 어떤 식으로 작성하면 좋을까?

뱅크 샐러드에선 다음과 같은 목차로 테크 스펙을 기술한다고 한다. 

(링크에 테크 스펙에 대해 좀 더 자세하게 기술해놓았다)

뱅크샐러드의 특별한 스펙, '테크 스펙' | 뱅크샐러드

• 요약
• 배경
• 목표
• 목표가 아닌 것
• 계획
• 이외 고려할 사항
• 마일스톤

https://docs.google.com/document/d/1nhozeUvJYKytE_b_9-YP4Fyw0wtykl9haCG4Wwjb9Ws/edit

뱅크샐러드 테크 스펙 템플릿 (외부 공개용)

 

물론 애자일 프로그래밍에선 문서보단 작동하는 소프트웨어를 만들라고 하고 있다. 

하지만 이는 문서가 중요하지 않다는 표현은 전혀 아니다. 

 

이렇게 작성하는 테크스펙은 개발자에게만 국한되서 작성하고 피드백할 수 있는 것이 아니다. 문서화 툴만 있다면 따로 개발 환경을 셋팅할 필요도 없고, 특정 언어에 대한 지식도 필요하지 않다. 

 

문서로 하는 코딩이지만 특정 사람들에게 국한되지 않게 되는 것이다. 

이 테크 스펙을 보고 변수명이나 인터페이스 같은 불확실하고 창의성이 필요한 문제는 개발자 뿐만이 아니라 다양한 사람들이 서로 피드백을 하며 나만 직관적으로 읽힐 수 있는 변수가 아닌, 다른 사람이 봤을 때 직관적인 변수를 작성할 수 있게 된다. 

 

그리고 불확실한 요소들을 다른 사람들과 함께 해결함으로써 보다 정확한 일정 산정이 가능해진다. 

 

결과적으로 테크 스펙은 테스트 코드처럼 작성되게 되고, 마지막으론 테스트코드가 해당 기능을 보장하게 된다. 

 

느낀 점 

최근 업무를 하며 업무 시작 전 업무에서 예상치 못한 문제가 계속 발생하며 업무 기간이 길어진 적이 있었기에 해당 세션이 좀 더 와닿았다. 일정 산정 시 계획을 잡을 때 간단하고 러프하게 잡기 보단 테크스펙을 작성해보자는 생각이 들었다. 

(이렇게 작성을 하더라도 분명 변경될 내용이 있겠지만...)

 

어떻게 하면 좀 더 정확하게 일정을 잡을 수 있을까 고민이 됐었는데 이 방법을 적용해봐도 좋을 것 같다. 

 

---

이외에도 `신뢰할 수 있는 API에 대한 고민과 해법을 찾아서 - 박용권님` / `우당탕탕! Safari Extension에서 Xcode Extension까지 - 이다혜님`, `Modular Architecture w/ Tuist - 김우성님` / `비전공 대졸 경력 0년차 초 주니어의 iOS 개발자로 살아남기 - 권은빈님` / `SwiftUI가 UIKit 품기 vs UIKit이 SwiftUI 품기 - 김예원님` 강연 모두 잘 들었다. 

 

Safari Extension은 처음 접해봤었는데 구글 확장 프로그램처럼 개발이 가능하다는 것을 처음 알게 되어 신기했고, Tuist도 개인 프로젝트에서 한 번 써보자는 생각이 들었다. SwiftUI와 UIKit을 혼용해서 사용하는 방법도 SwiftUI에 대해 공부하며 더 알아보고 싶다는 생각이 들었다. 

 

또 다양한 세션들을 들으며 아직 모르는게 많구나를 더욱 느꼈고, 좀 더 아는 것이 많았다면 느끼는 것이 많았겠다는 아쉬움도 들었다. 

 

오늘 호기심이 생기고 공부해봐야 겠다는 것들은 그냥 넘기지 말고 차근 차근 채워나가야겠다. 

 그리고 스티커를 포함해서 정말 다양한 굿즈도 받아서 좋았다... ㅎㅎㅎ

 

컨퍼런스를 통해 생각하지 못했던 것 / 아예 인지하지 못하고 있던 것 / 애매하게 알고 있던 것들에 대한 자극을 받을 수 있어서 좋았고, 다양한 iOS 개발자들을 만날 수 있어 좋았다. 특히 유명하신 개발자 분들을 직접 보고 테크토크에서 직접 이야기를 들을 수 있어 좋았다.

 

앞으로 오프라인 컨퍼런스도 기회가 된다면 종종 참여해야겠다!! 

 

영상이 올라오면 테스트 코드 관련 세션도 봐야지...!