1. 함께 나눈 이야기
스터디 방향에 대한 여러 의견이 나왔다.
-
1) 담당 챕터 정해서 하루에 한 사람이 개념 발표하기
장점: 담당 챕터에 대해서는 확실히 이해할 수 있다.
단점: 담당 챕터가 아닌 부분에 대해서 공부를 안해올 수 있다. (강제성이 떨어짐) -
2) 당일에 랜덤으로 담당 챕터를 정해서 개념 발표하기
장점: 모든 내용을 이해해 올 수 있다. (강제성 부여)
단점: 랜덤으로 정했을 시 준비가 부족하여 내용을 정확하게 전달하지 못할 수 있다. (시간 효율이 떨어질 수 있음) -
3) 개념을 각자 공부하고, 질문을 선정해서 토의하기
장점: 모든 내용을 이해야지 토의가 가능하기 때문에, 학습의 강제성이 부여 됌
단점: 개념 부분의 이해가 떨어질 수 있다.
모든 것을 만족시키는 진행을 정하는 것은 어려웠다. 왜냐하면 스터디의 목적이 달랐기 때문이다. 어떤 사람은 강제성이 중요했고, 어떤 사람은 학습의 깊이가 중요했다. 토의 시간이 길어지다 보니 사람들이 지쳐보였다. 팀원들이 진행 방향을 잡는데 오랜 시간을 쏟는 것이 무의미하다고 생각할 수 있다고 생각했다. 팀원들에게 방향성을 잡는데 시간이 중요하다고 많은 시간을 투자하자고 얘기했다. 최선의 방향성을 찾는 방법은 시간을 들여서 토의하는 것이라 생각했다. 깊은 이야기가 오가야만 타인의 생각을 이해할 수 있고, 이를 받아들이는 시간 또한 필요하다.
목적성에 대해서 정리를 했고, 팀원들이 가진 목적은 2가지로 좁혀졌다.
한가지는 강제성이고, 다른 한가지는 학습이었다.
처음 토의를 나눌 때, 활용에 대한 토의 방식이 개념 공부 중점이 아니고 활용인 부분이여서 아직 시작해야 하는 단계가 아니라고 생각했던 팀원이 있었다. 하지만 이야기를 나누다 보니 "활용"이라는 단어가 커뮤니케이션의 오류를 불러왔던 것이다.
팀원이 질의 방식이 적합하지 않는 이유에 대해서 들어보니 "활용"이 개발시 활용되는 구체적 코드 활용 방식으로 이해해서 부담을 가졌던 것이다. 하지만 여기서 "활용"은 그 개념의 장단점을 파악한 쓰임에 대한 의미이었다. 그 지점에 대해서 다시 한번 되집었을 때 그 팀원도 질의 방식에 긍정적으로 생각하게 되었고, 우리 스터디는 질의방식으로 진행하기로 결정 되었다.
의견 대립은 커뮤니케이션의 오해일 수도 있다. 그 오해를 찾기 위해서는 토론의 시간이 필요하다.
2. 배운 내용
오늘은 스터디 첫날이여서 진행 방향에 대해 주로 토의했습니다.
때문에, 같이 학습한 내용은 없었습니다.
하지만, 현업자에게 프론트 엔드의 자세에 대해서 들을 수 있었다.
백엔드는 불안하며, 프론트 엔드는 예민해야 한다고 했다.
사람들이 의심없이 사용하게 해야하기 때문에 예민하게 개발 해야 한다고 한다.
프론트 엔드는 커뮤니케이션 능력이 좋아야한다
backend와 디자이너의 취향을 모두 만족시켜야 하기 때문에 그들의 취향을 잘 이해해야 한다.
프론트는 보여지는 것이기 때문에 불가능한 이유에 대해서 정확하게 전달 할 줄 알아야 하기 때문이다.
