23.10.16(월) ~ 23.11.23(목)까지 1차 스터디를 진행하고 23.11.24(금) ~24.01.26(금)까지 2차 스터디기간으로 진행하는 이론기간이 시작되었다.

1차 스터디 기간에는 프론트 엔드에 관련된 강의와 과제가 제공되었고, 2차 기간에는 백엔드 에 관련된 강의와 과제가 제공되었다.
첫 스터디를 진행하고 이론과정간에는 스터디 방식을 자꾸 바꾸어 보면서 진행했다.
스터디를 진행해본 경험이 있지만 이론을 진행하면서도 6명에게 모두 도움이 되는 방향을 확립하려고 노력하는 과정이였다고 생각한다.

1차 스터디

첫번째 방식

스터디 시작시에 모집하고 나서 팀원들과 처음으로 정했던 스터디 방식은 아래와 같았다. 이론과정이 얼마나 오래걸리고 과제의 비중을 얼마나 놓을지에 대한 감을 잡기 위해서 스터디의 비중을 좀 낮추면서도 중요한 스터디를 꾸준히 진행하고자 다른 스터디와 좀 널널하게 일정을 잡았다.

`매일` 강의, 개인 공부 내용 정리(18:00 ~ 19:00)
→ 매일 들은 강의 진행률 & 과제 진행률 발표
→ 강의에 대해 의아했던 점이나 잘 이해가 안되는 부분에 대해 토의 후 해결이 안된 경우 오피스 아워 활용
→ 프로젝트에 대해 추가했으면 하는 기능이나 구현 방법이 궁금한 부분을 공유, 질의응답

`수요일` 알고리즘 문제 풀이(프로그래머스)
→ 동일한 문제를 40분의 제한시간내에 풀이 후 각자의 풀이방법을 공유

`주1회` CS 스터디
→ 통일된 주제를 선정후 주제에 대해 각자 조사한 발표자료를 가지고 발표

수정된 방식

`수요일` 알고리즘 문제 풀이(프로그래머스)

- 6명의 수준이 달라서 3 / 3의 팀으로 조 편성
- A팀 (LV2 수준의 2문제) / B팀 (LV1, LV0 수준의 문제 2~3문제)

`주1회` CS 스터디

- web개발에 관련된 기술 스택중 각자가 관심있었던 주제를 선정 후 각자의 조사를 통해 발표 & 질의응답

`매일` 알고리즘 1문제

- 과제가 없는 기간동안 코어 타임의 모든 시간을 강의만 듣다보니 집중력 하락 TIL 발표시에 주제 부족
- 중간에 코드를 작성하고 직접 고민하는 시간을 부여함으로서 집중력과 성취도를 높이기 위해 도입

알고리즘 수정 사항

팀원간의 난이도 조절

스터디를 진행하면서 가장 어려움을 겪은 부분은 사람마다의 실력과 경험이 다르다는 부분이었다. 특히 알고리즘 문제 풀이를 하거나 문제를 선정하는데 어려움을 많이 겪게 된거 같다. 그래서 우리 팀은 높은 레벨의 3명과 조금 낮은 레벨의 3명으로 조를 나누어서 각각의 문제를 선정하고 풀이하는 방식으로 진행되었다.

문제 풀이 빈도

이론기간에 구름 측에서 제공해주는 강의들만 듣다보면 집중도가 떨어지기도 하고 코드에 대한 이해도를 높이기 위해서 알고리즘 문제 풀이 빈도를 1일 1회로 증가시켰다. 이를 통해서 중간에 코드를 작성하고 고민하는 시간을 부여함으로써 집중도와 성취도를 높일 수 있었다.

CS 스터디 수정사항

CS 스터디의 경우에는 본래는 동일한 주제를 공부해오는 방식으로 각자가 조사해온 부분에 대해 크로스 체크와 이해도를 높일 수 있을 거라고 생각했었다. 그래서 하나의 공통된 주제를 선정했었으나, 진행해본 결과 생각보다 겹치는 내용이 너무 많아서 아쉬움을 팀원들이 있었다.
그래서 대주제를 정하고 거기에 대한 소주제를 각각 선정해서 조사해오는 방식으로 수정했다. ex) WEB(대주제) → 쿠키와 세션, CORS, 브라우저에 naver.com을 치면 일어나는 일, Docker, Rest, DeadLock

1차 회고

아래는 스터디가 진행되었던 일정을 작성해보았다. 우리 팀은 1차의 기간동안에 과제를 100% 완료하는 것을 목표로 진행했다.
결과적으로 모두가 과제를 제출하는데 성공했다. 우리팀은 각자의 공부시간을 최대한 확보하면서 스터디 진행을 목표로 했다. 그래서 하루에 1시간 정도 TIL(Today I Laern)시간을 통해서 어떤 알고리즘 문제를 풀었고 강의는 어디까지 들었는지에 대해 이야기를 나누는 시간을 가지곤 했다.

absolute absolute
1차 스터디 진행 캘린더

2차 스터디 회고

absolute absolute
2차 스터디 진행 캘린더

진행 방식

2차 스터디 부터는 백엔드 java(spring)에 대한 강의와 과제가 제공되었다. 우리 팀원들의 대다수가 백엔드를 선호하는 경향이 있어서 다들 열심히하려고 노력했다.

1차에서 여러가지 시행착오를 지나고 스터디 진행방식이 자리잡고 1차 진행 방식과 동일하게 진행되었다.

notion

그리고 구름에서 진행한 1차 스터디 회고 발표를 통해서 다른 스터디 팀들이 어떻게 진행되었는지 확인하고 우리도 적용해보려고 노력했다.

이후 좀 더 깔끔해지고 각자의 공부로그를 작성할 수 있는 페이지가 생성되었고, 노션을 통한 공유가 활발하게 이루어졌다.

discord

이전에는 회의나 자료 공유등을 discord가 아닌 구름 유니버스(zep)에서 진행하였고, 원활하게 진행되기는 했지만, 이야기 내용이나 채팅 내용등이 사라지는 아쉬움이 있었다. 다른 스터디 팀들이 discord로 많이 진행되는 것을 확인하고 우리도 discord를 적용하는 방향으로 수정하였다.

그 이후 TIL시간에 이야기 하면서 자료 공유를 할 수 있었고, 찾아보고 싶을때 discord를 통해서 확인할 수 있었다.

Notion

디스코드 서버(프로젝트 진행까지 여기서 진행했다...)

스터디 회고

좋았던 부분

서로 비슷한 생각을 가진 사람들을 모으려고 했었고 생각보다 좋은 사람들이 팀원들로 들어와서 스터디 진행이 자주 바뀌었어도 다들 열심히 하려고 노력했던 부분이 좋았다.

팀장으로써 조금이라도 많은 정보를 공유하려고 노력했고, 팀원들도 이에 동기부여 받아서 이론기간을 계속 진행할 수 있었던 것 같다.

그리고 TIL 시간에 본인이 진도가 느리거나 아니면 과제 진행이 느리다는 것을 확인 할 수 있는 시간이 있다 보니 자극 받고 계속해서 진행도를 높이려고 노력했다.

아쉬웠던 부분

스터디에 대해 아쉬웠던 부분 보다도 팀장으로써 나에게 아쉬운 부분이 많았던 것 같다. 많은 스터디 경험이 없다보니깐 스터디 방식이 정립되기 까지도 많은 시간이 걸린 편인것 같았고, 팀원간의 케미를 좀 더 이끌어내는 방법에 대해 미숙한 점이 많았던 것 같다.

사실 온라인으로 진행되는 구름톤이지만 팀원끼리 오프라인에서 만나는 빈도수를 늘리면 어땠을까 하는 아쉬움이 많이 남았다. 지방에서 살고 있는 사람이 팀장이다 보니 팀원들간의 오프라인 미팅을 자주 이야기 하지는 못했던 점이 팀원들간의 교류를 제한적으로 만든 경향이 있다고 생각했다.

댓글남기기