[컨퍼런스] AsyncSwift Korea Seminar 002를 참여하고 작성하는 후기

오랜만에 Swift 관련 컨퍼런스를 참여했다.

4개의 Session으로 구성이 되어 있었고 주제는 다음과 같았다. 

• RIBs를 통한 상태 관리 
• why MVVM 
• PR과 코드 리뷰 
• Mock 데이터를 통한 항상 성공하는 테스트 코드 짜기 

 

RIBs를 통한 상태 관리 - 김남현님 | VCNC

사실 RIBs에 대한 이해도가 거의 없다시피 해서 발표 내용에 대해 완전히 이해하진 못했다.

우버에서 설명하는 Ribs 도식

RIBs는 Uber에서 만든 크로스 플랫폼 아키텍처 프레임워크로 iOS 뿐만 아니라 안드로이드에서도 사용 가능한 아키텍처이다. 

(아직 공부해본 적이 없는 아키텍처라 잘못된 내용이 있을 수 있습니다)

• Interactor : 비즈니스 로직이 포함되어 있다. Rx 구독을 수행하고 상태 변경 결정을 한다. 또한 child로 연결할 다른 RIB을 결정한다. 
• Router : 화면 전환 라우팅을 수행한다. 
• Builder : 모든 RIB 구성 클래스를 인스턴스화한다. 이를 통해 다른 RIB 코드는 의존성 주입에 신경 쓸 필요가 없다. 
• View
• Presenter

 

위처럼 트리 구조로 상태 값에 따라 처리를 해주는 구조로 이해했다. 

사실 아직까지 알고리즘에 대한 니즈를 크게 느껴보진 못했었는데 트리 구조를 보면서 이래서 알고리즘을 공부하는 건가 생각도 들었다. 

 

타다의 경우 상태를 반영하는 코드들이 여러 RIB으로 분산되게 되면서 수정이 여러 곳에서 발생했고, 새롭게 코드를 보는 입장에서 도메인 파악이 어렵다는 문제가 있었다고 하셨다. 

 

또한 클라이언트 단과 서버 단에서 상태에 대해 처리를 하며 서로 간 메세지 전달이 지연되어 잘못된 상태가 겹쳐서 오는 문제도 있었다고 하셨다. 그리고 상태를 변경하는 코드가 분산되어 있어 상태 변경에 대한 유닛 테스트를 진행하기도 어려운 점이 있었다고 한다. 

 

그래서 상태 변화 관리 코드를 한 모듈로 모으는 작업을 진행하고 이를 통해 중복 코드와 버그를 줄일 수 있었다고 하셨다. 

 

개인 소감

아직 RIBs에 대한 이해도가 거의 없다시피 해서 발표 내용에 대해 이해를 많이 하진 못했지만 상태 변화가 잦은 경우 RIBs를 도입해보는 것도 괜찮을 것 같다고 느꼈고, RIBs라는 아키텍처가 궁금해졌다. 또한 알고리즘을 공부해볼까 생각이 들었다. 

 

 

Why MVVM? - 권문범님 | 쿠팡 

다음 발표는 MVVM 관련 내용이었다. RIBs 다음에 그래도 익숙한 MVVM 아키텍처가 나와서 반가웠다. 

 

일단 발표는 아키텍처를 정할 때에는 당위성은 존재하지 않고 왜 해당 아키텍처가 필요한지 설명할 수 있어야 한다며 시작했다. 

 

MVC → MVP → MVVM 순으로 발표를 하셨다. 

그러면서 현재 OOP(객체지향 프로그래밍)에서 함수형 프로그래밍으로 트랜드가 이동함에 따라 MVC에서 MVVM으로 트렌드가 바뀌고 있다고 하셨다. 

 

그렇다면 왜 이런 변화가 생긴 것일까?

• 각 코드의 책임과 역할을 명확히 하기 위해 
  UIView
  UIViewController : 기본은 뷰의 라이프사이클을 관리하는 곳 / View의 이벤트에 따로 비즈니스 로직을 정의할 순 있다. 
  Model : 데이터 저장 및 관련 API 호출 
• 선언적 코드를 활용해 동적인 코드를 제어 
  MVC의 경우 함수 호출을 통해 공유 변수 및 외부 변수를 참조하고 변경하는 코드가 많아지면서 런타임에 동적으로 동작하는 코드가 상당히 많아진다. 
  따라서 선언형 프로그래밍을 통해 클로저 형태로 bind를 해서 외부 변수 참조 시 context capturing을 통해 복사해서 사용하는 형태로 변경되고 있다. 
• 비즈니스 로직의 방향성을 가시화해서 도메인 파악이 용이
  MVVM 구조를 알고 있다면 비즈니스 로직이 어떻게 흘러가는지 파악하기가 더 쉽다. 
• 동시성 프로그래밍에서 발생하는 Side Effect를 최소화
  MVC나 객체 지향의 경우 공유 자원에 대한 Race Condition이 발생할 가능성이 커진다. 따라서 이전에는 Semaphore나 Lock, 동기를 통해 이를 해결했다. 하지만 ViewModel을 사용하는 경우 Model에 접근하는 통로가 하나라 동기처럼 순차적으로 작동하게 된다. 

 

Swift가 함수형 프로그래밍 언어인 만큼 함수형 프로그래밍에 대한 고민이 필요하다고 하셨고 항상 아키텍처든 기술 스택이든 사용을 할 때 왜 사용하는지 등 왜에 대해 깊이 있게 고민해야 한다고 하셨다. 

 

개인 소감

일단 RIBs보다 친숙한 아키텍처라 확실히 좀 더 이해도가 높았다. MVVM 아키텍처에 대해 좀 더 생각해볼 수 있어서 좋았지만 무엇보다 좋았던 것은 왜에 대해 고민해볼 수 있어 좋았다. 더 나은 개발자가 되기 위해 항상 "왜"를 고민하는 개발자가 되어야 겠다고 생각했다. 

 

코드리뷰  같이 성장하기 위한 성공하는 팀이 되기 위한 도구 - 김우성님 | 29CM

개발 문화는 항상 회사와 팀의 성공을 위한 것이어야 한다고 말씀하시며 발표를 시작하셨다. 

이전 야곰 아카데미에서도 거의 똑같은 내용으로 들었던 발표였지만 워낙 좋았던 발표였고, 이번에도 역시 좋았다. 

 

해당 발표의 큰 골자는 PR은 어떻게 작성해야 하고 코드리뷰는 어떻게 해야할지였다. 

 

29CM에선 PR을 지식 아카이브로 사용하고 있다고 하셨다. 

물론 JIRA / Trello / Asana 같은 칸반보드 형태의 툴을 사용해 히스토리를 남길 수도 있고 Confluence나 Notion같은 위키 툴을 사용해 히스토리를 남길 수도 있지만 툴은 언제든 빠르게 변할 수 있다. 

 

하지만 GitHub은 한 번 정착하게 되면 BitBucket이나 GitLab같은 다른 툴로 이동하기도 쉽지 않고 잘 변경하려고 하지도 않기 때문에 오히려 더 변하지 않는 툴이다. 따라서 29CM에선 GitHub의 PR을 통해 개발 히스토리를 쌓고 계신다고 했다. 

 

툴이 변경된다면 만약 링크를 남겨놔도 미래에 확인할 수 없는 일이 발생할 수 있기 때문이다. 

그러면서 성장이 필요하다고 느끼는 개발자라면 PR과 코드리뷰는 아주아주~ 중요하다고 하셨다. 

 

하지만 PR을 맥락이나 테스트 방법이 부족하게 작성하게 된다면 오히려 팀의 생산성을 낮춘다고 하셨다. 

테스트 방법이나 영상, 스크린샷이 없고 전후 맥락이 부족한 PR의 경우 같이 작업하는 동료들이 이를 파악하기 위해 시간을 쏟아야 해서 오히려 팀의 생산성이 낮아지는 것이다. 

 

또한 PR 단위가 너무 커져도 리뷰에 드는 시간이 지나치게 많이 든다. 

 

그렇다면 좋은 PR은 뭘까?

PR은 기본적으로 글로  리뷰어에게 주는 요청서이다. 

 

1. RxSwift같은 많은 사람들이 잘 알고, 보고 있는 레포에 기여하는 느낌으로 PR을 작성하자. 

2. 스마트폰에서도 리뷰할 수 있는 리뷰를 작성하자 - PR의 단위를 간결하게 하고 맥락도 파악하기 쉽게 작성하자

3. 풍부한 맥락을 적자.

4. 리뷰어가 고민하지 않도록 작성한다. - 리뷰어가 궁금할 수 있을만한 네이밍이나 내용들은 미리 작성자가 리뷰를 작성해 이해하기 쉽도록 한다. 

5. PR 당 코드의 양은 적게, PR 본문의 양은 많게 

 

PR 중심으로 협업하는 팀이 되기 위해선 

1. Git을 여러 방향으로 잘 활용할 수 있도록 하자. 

예시로 보여주신 온보딩에서 안내하는 Git 관련 명령어와 내용들

나 또한 입사 후에 Rebase에 대해 좀 더 파악할 수 있었는데 역시 협업에는 Git이 진짜 중요한 것 같다. 아직 리눅스 명령어와 Git에 대해 모르는 부분이 많아 이 부분에 대해서도 공부를 더 해야겠다고 느꼈다. 

 

2. PR을 빠르게 찾는 것도 생산성과 연관이 있는 만큼 29CM에서는 Alfred WorkFlow를 통해 빠르게 PR을 검색한다고 하셨다. 

3. Git Flow의 간소화

4. 코멘트의 레벨 도입

이는 뱅크 샐러드에서 차용하셨다고 한다. 5개의 레벨을 두고 리뷰가 어떻게 반영되었으면 좋겠는지를 표시하게 된다. 

이는 코드 리뷰 in 뱅크샐러드 개발 문화에서 자세하게 살펴볼 수 있다. 

 

5. PR 레이블을 통해 빠르게 릴리즈가 되어야 하는 피쳐인지 파악

6. 리뷰어와 리뷰이가 확인했는지 파악할 수 있도록 이모지를 사용하고 Resolved를 쓰지 않는다. 

Resolved를 쓰지 않는 이유는 나중에 검색 시에 Resolved로 코멘트가 닫혀있는 경우 찾기가 쉽지 않기 때문

회사에서도 리뷰를 할 때 어떤 식으로 리뷰를 할지 고민을 하다 컨벤션 위주의 리뷰가 되었었는데 이런 기준을 적용해보는 것도 좋겠다고 생각이 들었다. 

 

또한 PR을 통해 공부가 되는 PR이 좋다고 하셨다. 나중에 신규 입사자같이 도메인에 익숙하지 않은 사람이 오더라도 해당 기술이나 도메인을 파악하기 쉽기 때문이다. 

 

개인 소감

저번에 우성님의 발표를 들었을 때도 좋았지만 현업에서 직접 다른 분들과 협업을 하던 중에 다시 발표를 들으니 더 좋았던 것 같다. 몇몇 부분은 다른 분들과 공유하고 적용해봐도 좋지 않을까 생각이 들었다. 

확실히 PR을 잘 작성해놓으면 팀의 성장에도 도움이 되지 않을까 생각이 들었다. 그리고 Git에 대해서도 좀 더 공부를 해야겠다 생각이 들었다. 

 

내일 지구가 멸망해도 테스트는 같게 동작해야 한다 - 김찬우 | 원티드랩

테스트 코드는 확신을 가지고 다음 피처를 만들 수 있도록 하게 해주며 기능 확장 및 수정을 할 때에도 테스트 코드가 있다면 Side Effect이 있는지 확인하기가 보다 쉬울 것이다. 

 

하지만 우리는 불확실한 상황에 대한 테스트를 해야할 때도 있다. 따라서 상황이 변경되게 되면 테스트가 깨지는 문제가 발생할 수 있고 이런 상황에 사용할 수 있는 방법에 대해 설명을 해주셨다. 

 

이전에 블로깅을 하기도 했지만 바로 Mock을 사용하는 것이다. 

이전에 공부했던 내용이긴 하나 발표를 들으며 좀더 정리가 되었다. 

 

코드는 아래 링크에서 확인 가능합니다. 

https://github.com/dacodaco/AsyncSwiftKorea_002

GitHub - dacodaco/AsyncSwiftKorea_002: AsyncSwiftKorea_002 세미나의 발표에 바탕이 되는 프로젝트입니다.

 

 

참고자료

https://www.youtube.com/channel/UCig96hmPxDF4D3II6idDoaw(이전 발표 영상도 찾아보실 수 있어요~)

Async Swift Korea

https://github.com/uber/RIBs/wiki

GitHub - uber/RIBs: Uber's cross-platform mobile architecture framework.

https://blog.banksalad.com/tech/banksalad-code-review-culture/

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드