[회고] NOW SOPT iOS 파트장 회고 (5) 어떻게 가르칠거야?

이전 글들을 읽어보시면 해당 회고 글이 더 잘 이해가 될거에요!

2024.09.04 - [📝 회고] - [회고] NOW SOPT iOS 파트장 회고 (1) Intro

[회고] NOW SOPT iOS 파트장 회고 (1) Intro

2024.09.04 - [📝 회고] - [회고] NOW SOPT iOS 파트장 회고 (2) 어떤 SOPT를 만들고 싶어?

[회고] NOW SOPT iOS 파트장 회고 (2) 어떤 SOPT를 만들고 싶어?

2024.09.05 - [📝 회고] - [회고] NOW SOPT iOS 파트장 회고 (3) 어떤 iOS 파트를 만들고 싶어?

[회고] NOW SOPT iOS 파트장 회고 (3) 어떤 iOS 파트를 만들고 싶어?

2024.09.08 - [📝 회고] - [회고] NOW SOPT iOS 파트장 회고 (4) 어떤 사람들과 함께하고 싶어?

[회고] NOW SOPT iOS 파트장 회고 (4) 어떤 사람들과 함께하고 싶어?

SOPT에서 세미나란?

지난 글들을 통해서 어떤 SOPT, iOS파트를 만들고 싶었는지 또한 그런 파트를 만들기 위해 누구와 함께 하고 싶었는지에 대해서 회고를 했었다. 모든 인원을 다 뽑게 되면 SOPT에서는 OT를 진행하게 되고 이때부터 활동이 시작하게 된다. 

OT 이후부터 앱잼 전까지는 각 파트는 총 8번의 세미나를 진행을 해야되며, 세미나를 잘 수행하는 것이 파트장이 기수 중 맡게 되는 가장 큰 업무 중 하나이다. 8번의 세미나 중 합동세미나를 제외한 총 7번의 세미나의 자료부터 발표, 과제까지 온전히 파트장 혼자 준비를 해야하며, 해당 세미나를 통해서 솝트의 꽃 장기 해커톤 앱잼에서 파트원들이 각 팀에서 맡은 바 역량을 보여줄 수 있도록 성장의 발판을 놔주는 아주 중대한 역할을 수행하게 된다.

그래서 어떻게 가르칠거야?

1) 세미나 커리큘럼 구성

물론 이전 기수들을 통해서 4명 정도의 팀원들을 이끌고 상호성장한 경험은 있지만, 30여명 되는 파트원들에게 직접 지식을 전달하는 경험을 해본 적이 없는 나였기 때문에 많이 긴장했다. 그래서 더더욱 처음 내가 만들고 싶었던 파트에 초점을 맞추어서 세미나 커리큘럼을 구성하였다.

합동세미나가 시작되기 전 다른 파트와의 협업에서 iOS 개발자로서의 역할을 다할 수 있도록 UI Component를 배치하고 속성을 활용하는 능력, 데이터를 전달하는 방법, 다양한 정보를 보여줄 수 있는 화면을 구현하는 방법, 서버통신을 하는 방법 등을 학습할 수 있도록 배치하였다.

 

합동세미나 이후에는 가치있는 코드를 짜야하는 이유를 시작으로 이를 판단하기 위해서 필요한 지식들을 학습하면서 이 전에 작성한 자신의 코드를 명확한 이유를 가지고 리펙토링할 수 있도록 세미나를 구성하였다.

2) 세미나 자료 제작 및 진행

사실 이 부분이 가장 리소스가 많이 드는 부분이다. 그 이유 중 하나는 '세미나의 밸런스를 유지해야 되기 때문이다!.' 세미나 자료를 제작하면서 아래와 같은 고민들이 생겼었다.

1. 한정된 시간 속 어떤 내용을 어떻게 전달해야 될까?

내가 알고 있는 내용들을 전부 다 발표하여 전달하는 것이 아닌 4시간이라는 한정된 시간 속에서 해당 주차에 중요한 개념들 파트원들이 가장 잘 이해할 수 있는 방식을 고려해야했다. 물론 파트원들이 직접 집요하게 공부하면서 자기껄로 만들어야하는 시간이 필요하긴 하지만, 그 과정을 최대한 재밌고 인상깊게 만드는 것이 중요하다고 생각했다. 

 

그래서 최대한 모든 개념들을 다양한 일상 속 예시를 바탕으로 설명을 하려고 노력했다.

iOS 개발과 관련된 지식을 많은 사람들이 흥미를 가지는 예시로 비유하면서 설명하였다.

Delegate 패턴을 환승연애에 비유하며, 또 재사용 큐를 패션쇼에 비유하면서 처음 해당 개념을 접했을 때 거부감 없고 흥미를 기반으로 이해를 시작할 수 있도록 노력했다.

Delegate & Protocol의 개념을 환승연애에 비유해서 설명했다.

재사용 큐의 동작원리를 패션쇼에 비유해서 설명했다.

페어프로그래밍과 라이브 코딩 등 다양한 세미나 방식 시도

기존의 세미나 방식은 매주 조를 이루어서 진행하였다. 가장 안정적인 형태이고 4명의 인원이 소통하기에 아주 좋은 시스템이었지만, 해당 주차에 주제에 따라 세미나 방식의 변화를 준다면 이해도를 높일 수 있을 것이라고 생각했다. 

 

가장 대표적인 사례는, 6주차 세미나에서는 페어 프로그래밍 방식으로 세미나를 진행한 것이었다. 직접 생각을 하고 가치 있는 코드에 대해 고민하는 과정에서 4명의 많은 인원보다 짝과 함께 서로 대화를 하고 글로 작성는 것이 더 효과적이라고 판단하였다. 정해진 정답을 따라하는 것이 아닌 서로가 가치있는 코드에 대해서 고민해보고 대화하면서 정답이 없는 문제를 해결하는 모습이 정말 인상적이었고 개인적으로도, 피드백 측면에서도 효과적인 세미나 방식이었다.

동영상 서비스가 종료되어 해당 콘텐츠를 재생할 수 없습니다.

2. 파트원 개개인의 실력적 편차를 극복하고 모두가 최대한 배워가도록 하려면 어떻게 해야할까?

물론 애초에 리쿠르팅 과정에서 실력을 평준화하면 되겠지만, 그것은 나에게 크게 중요한 가치가 아니며 그보다 열정있는 사람들을 뽑아서 성장시키고 싶었고 그것이 내게 해야할 과제라고 생각을 했다. 따라서 1) iOS 개발이 처음인 파트원들은 이해하기 쉽도록, 2) 이미 iOS 개발을 했던 파트원들은 한번 더 깊은 고민을 할 수 있는 내용들을 같이 준비해야겠다고 생각했다.

 

야우쓰 스터디 & 심화세미나

위에서 파트원 개개인의 실력적 편차와 얻고자하는 목적에 따라서 2가지를 시도했는데, 바로 Swift 문법 스터디 '야우쓰'와 심화 세미나였다.

 

야우쓰 스터디는 '야 우리도 쓰위프트 할 수 있어!'의 줄임말로, iOS 개발을 처음 시작하거나, Swift 문법에 대해 좀 더 딥하게 공부하고 싶은 사람들을 대상으로 진행했던 스터디였다. 특히 코드를 읽기 어려워하는 파트원들이 문법 지식을 바탕으로 코드를 이해하는데 초점을 맞춘 스터디였다. Swift 언어에 익숙하지 않은 많은 파트원들이 지원을 하였고, 해당 스터디를 통해서 이유있는 코드를 작성하는데 큰 힘이 되었다고 한다.

 

이미 Swift에 익숙하고 주차별 세미나보다 심화된 내용을 원하는 파트원들을 위해서 각 주차에 다룰 수 있는 심화된 내용의 세미나를 자료와 함께 제공을 하였다 Lookin, Then, Kingfisher처럼 사용하면 편리한 라이브러리부터 Clean Architecure, Design Pattern 등 가치있는 코드를 고민하기 위해 필요한 심화된 개념들을 전하면서 이미 iOS 개발을 할 수 있었던 파트원들에게 더 많은 양질의 자료를 제공하기 위해서 노력했다.

 

3. 정확한 정보를 전달해야 한다 즉, 내가 확실히 알아야 한다.

가장 당연하지만 생각보다 어려운 부분이었다. 내 머릿 속에서는 대충 알고 넘어가도 크게 지장이 없는 부분을 막상 정확한 자료를 통해서 제공하려니까 말로 표현하기 어렵고, 그래서 더더욱 책과 자료들을 찾아 보면서 확실하고 정돈된 언어로 표현하기 위해 노력했던 거 같다.

 

이러한 고민들을 해결하기 위해선 굉장히 많은 시간이 필요할 것이라고 생각했고, 그렇기 때문에 빠르게 세미나 초안을 만들고 거기서 살을 붙여가는 형식으로 세미나를 구성하게 되었다.

 

+) Notion VS Figma 어떤 형식이 더 적합할까?

자료의 퀄리티만큼이나 자료의 형식도 중요하였다. 나같은 경우에는 노션과 피그마를 활용해서 준비를 했었고 각각의 장단점을 아래에 정리해두겠다.

 

	노션	피그마
사용했던 세미나	1,2,3,6주차 세미나	4,6,7,8주차 세미나
장점	- 만들기 쉽다 - 이후에 자료 찾아보기 쉽다.	발표 자료의 형태이기 때문에 세미나를 진행하기는 오히려 편하다.
단점	발표자료의 형태가 아니기 때문에 실제로 세미나를 진행하며 설명하기가 어렵다.	만드는 시간이 오래 걸린다. (이 부분은 내가 피그마의 익숙하지 않아서도 한 몫한다고 본다)
어떤 상황에서 사용하면 좋을지	많은 코드를 활용하는 경우 (첨부하고 설명하기 훨씬 더 편리하다)	개념 지식 혹은 그에 관련된 예시를 전달하는 경우 (시각적으로 집중시킬 수 있다.)

노션 자료

 

피그마 자료

3) 주차별 과제 

해당 주차의 세미나를 잘 이해했는지 확인하며, 직접 코딩을 하면서 자기껄로 만들기 위해서 아래와 같이 4가지의 과제를 진행하였다.
동아리치곤 정말 많은 양이지만, 이렇게 준비를 해야 장기 해커톤 앱잼에서 iOS개발자로서의 책임을 완벽히 수행할 수 있고 또 성취감을 느낄 것이라고 생각해서 아래와 같이 준비를 했다.

과제 형식은 이전 기수들과 굉장히 비슷하나, 내가 고민하고 적용했던 부분만 간단히 공유하려고 한다.

1. 한 개의 Product를 계속 develop할 수 있도록

기존의 과제 프로젝트에서 아쉬웠던 점은 매 주차 구현해야되는 product가 달라서 해당 개념을 코드로 적용하는 정도의 효과만 얻을 수 있었다고 했다. 특히 개발자는 자신의 무엇을 개발하고 구현하는지에 대해 큰 성취감을 느낀다고 생각한 나는, 실습/기본 과제의 Product를 통일하여서 1~4주차동안 클라이언트 개발자로서 앱을 구현하고. 5~8주차동안 자신의 구현한 코드를 리펙토링하는 과정을 통해 2개의 완벽한 앱을 만들 수 있도록 구성하였다.

2. 명예회원들의 코드리뷰를 통해 단단하게 성장하기

현업에서 iOS개발자로서 활동하거나, 이전 기수들을 수료함으로써 파트원들의 관점에서 필요한 코드리뷰를 제공할 수 있는 8명의 명예회원들을 섭외해서 파트원들이 더더욱 양질의 코드리뷰를 받을 수 있도록 시스템을 적용하였다. 특히 이전 기수들에서는 OB회원들이나 iOS개발을 할 줄 알았던 회원들은 아무래도 코드리뷰를 제공하고, 제공받기 어려웠던 상황이었는데, 그들 또한 피드백을 받을 수 있다는 부분에서 많은 긍정적인 피드백을 받을 수 있었다.

느낀점

세미나 자료를 제작하고 4시간이라는 시간동안 세션을 진행하는 것은 정말 많은 리소스가 들었다. 하지만 지식공유자로서 정확하고 이해하기 쉽게 전달하기 위해서 더 열심히 공부하는 과정을 통해 내가 훨씬 더 깊이 배움을 얻을 수 있던 좋은 경험이었다.