스터디와 프로젝트를 운영하며 느낀점

글을 쓰게 된 이유

비전공자라 아는 개발자가 없다보니 처음에는 직접 스터디나 프로젝트를 만들어 운영했었다. 근데 대부분 흐지부지 되는 경우가 많았고, 결과가 좋지 않았다. 그래서 한동안은 직접 운영하는 것을 멈추고, 멘토링 프로그램이나 커뮤니티, 다른 사람이 진행하는 프로젝트&스터디에 참여하며 경험을 쌓고 배우려고 노력했다.

2주 뒤부터는 그동안 깨달은 점을 바탕으로 보완하여 스터디를 진행해보고자 한다. 이번에는 마무리도 꼭 잘해보고 싶어서 지금까지 운영하거나 참여하면서 배운 점을 정리해보려고 한다.

[모집 + 운영한 스터디]

• 프론트엔드 스터디 + 프로젝트 (프론트엔드 개발자 + 스터디장 )
• 앱 프로젝트 ( 앱 개발자 )
• 웹 프로젝트 ( 프론트엔드 개발자 )
• 카카오톡 코딩테스트 인턴십 스터디 (스터디장)

[참여한 스터디 + 프로젝트]

• 창업동아리 ( 팀장 )
• CS 스터디 ( 스터디원 )
• 앱 프로젝트 ( 백엔드 개발자 + 팀원 )
• 해커톤 ( 백엔드 개발자 + 팀원 )

스터디를 운영하며 느낀 점 & 배운점

1. 스터디의 목적이 분명할수록 얻어가는 게 확실해진다.

• 뭐든 공부하는 게 목적이라면, 모각코와 같은 자유로운 분위기의 스터디도 상관없지만, "CS 지식"이나 "프로젝트 결과물"과 같이 얻고자하는 것이 분명하다면 스터디 목적을 분명하게 하는 게 좋은 것 같다. 공부해야할 게 많다고 한 스터디에서 이것저것 하다보면, 스터디 시간이 길어져서 집중력이 떨어지고 한 활동에서 시간이 초과되면 다른 활동을 할 시간이 줄어들게 된다.
• 각자 발표를 진행하는 스터디일 경우 목적을 고려하여 주제의 범위를 정해두면 좋다.
  • "발표를 준비를 통한 공부"와 "발표 실력 향상"이 목적이라면 주제를 자유로 하는 게 좋은 것 같다. 내가 하고 싶은 주제여야 더 애정을 가지고 준비할 것이니 말이다.
  • 다른 사람의 발표를 들으면서 지식을 공유받고 싶다면, 주제의 범위를 제한해두는 것이 좋은 것 같다. 아무것도 모르는 상태에서는 발표를 들어도 전혀 머리에 들어오지 않기 때문이다. 주제를 제한해두면 발표가 서로 연관성이 있을테니 각자 준비해와도 서로의 발표를 이해할 수 있을 것이다.

2. 목표 운영 기간은 정해두는 게 좋다.

• 뭐든 시간이 갈수록 분위기가 루즈해지는 경향이 있다고 생각한다. 우선 운영 기간을 정해두고 종료된 날 회고하고 정리하는 시간을 가지는 것이 좋을 것 같다. 벌금을 걷었다면 벌금을 정리하고 계속 하고 싶은 스터디원이 있는지 물어보고, 규칙을 보완한다면 점점 더 나은 스터디를 운영할 수 있게 될 것이라 생각하기 때문이다.

3. 벌금은 공부 분위기 유지에 도움이 될 수 있다.

• 벌금이 없을 경우, 지각이나 결석, 과제 미제출 등의 일이 빈번하게 생길 수 있다. 그런 일이 지속될 경우 분위기가 흐려질 수 있다. 의지가 약한 편이라 스터디를 통해 어떻게든 공부하는 것이 목적이라면 벌금이 있는 편이 좋은 것 같다.
• 벌금을 둘 것이라면 벌금 항목뿐만 아니라 벌금을 어떻게 쓸 것인지, 보증금에서 차감하는 형식으로 할것인지 아니면 그때그때 걷는 형식으로 할 것인지도 정해두면 좋다. 벌금 발생 상황마다 걷는다고 했을 때는 해당 스터디원이 벌금을 제출하지 않을 경우도 고려해야할 것이다.
• 원하는 스터디 방향에 따라 벌금에 대한 의견이 달라진다고 느껴졌다. 그래서 스터디원을 모집하기 전에 규칙을 정해두고, 동의하는 사람을 모집하는 게 좋다고 생각한다. 스터디를 진행하다가 회의를 통해 결정하게 되면 불만이 생길 수 있기 때문이다. 미리 결정해두고 모집하면, 스터디 방향성에 대한 의견이 같은 사람들과 함께 할 수 있게 될 것이다.

운영 규칙 필수 항목 정리

위의 느낀점들을 종합했을 때, 스터디 운영 규칙에 포함되어야한다고 생각하는 것은 다음과 같다.

1. 운영기간 및 시간
2. 벌금 ( 벌금 유무, 벌금 항목, 관리자, 벌금 처리 방법, 벌금 제출 방식)
3. 모임 날짜, 시간, 장소
4. 모임 진행 방식 ( 몇 시에 어떤 활동을 얼마나 할건지 )
5. 과제 ( 과제 유무, 과제 항목, 제출 방식)
6. 관리 방식 ( 깃허브, 슬랙, 노션, 카카오톡 등)
7. 자료 공유 ( 자료 공유 의무 여부, 공유 방식, 공유 범위 )

프로젝트를 운영하며 느낀점 & 배운점

1. 프로젝트를 진행할 때는 우선순위를 정해두자.

• 모든 것에 대해 우선순위를 정하지는 못해도 필수적으로 구현해야하는 화면과 기능은 정해두는 것이 좋다고 생각한다. 처음 프로젝트를 진행할 때는 별 생각없이 화면 구현은 했는데 서버 연동도 제대로 못해보고 끝날수도 있고, 로그인 기능은 완성했는데 메인 기능을 제대로 구현하지 못하고 끝날수도 있다. 모두 나의 경험담이다...모든 것을 기획대로 완벽하게 끝내는 건 힘들 수 있다. 따라서 우선순위와 목표 기간을 정해두고 어느정도 됐다면 미뤄두는 것도 필요하다고 생각한다. 그리고 시간이 남으면 퀄리티를 높이면 된다.

2. 목표 개발 기간은 정해두는 게 좋다.

• 프로젝트도 마찬가지로 개발 기간을 정해두지 않으면 시간이 갈수록 분위기가 루즈해지고 어느순간부터 흐지부지될 확률이 높다. 나중에 조정하더라도 목표하는 운영 기간은 처음에 정해두는 것이 좋다.
• 목표 기간은 처음부터 길게 잡는 것보다는 짧게 잡아서 집중해서 하고, 그래도 안될 경우 늘리는 게 더 나은 것 같다. 기간이 여유있으면 그만큼 마음에도 여유가 생기고, 진행이 더뎌지는 것 같다. 생각보다 작업 시간이 많이 걸리는 경우가 있기 때문에, 빠르게 집중해서 할 수 있도록 기간을 빡빡하게 잡고 상황에 맞게 조정할 수 있도록 여유를 남기는 것이 더 낫다고 생각한다. (물론 마음에 여유가 좀 없을 수는 있다..자신에 맞는 방법을 찾아보자.)

3. 함께 작업하는 시간이 있으면 속도가 빨라진다.

• 함께 작업하는 시간이 없다면, 시간이 갈수록 의지가 약해지고 그에 따라 진행상황은 더뎌져서 회의날에 회의할 게 거의 없을 수도 있다. 물론 사람에 따라 다르겠지만, 본업이 아닌 이상 일정이 계속해서 미뤄지게 될 확률이 높은 것 같다. 따라서 회의하는 날짜뿐만 아니라 함께 작업하는 시간도 필요하다고 생각한다. 그렇게 되면 바로바로 물어보면서 작업할 수 있고, 작업 시간이 어느정도 보장되기 때문이다.

4. 실력자와 함께하자!

• 경험과 지식이 부족한 사람끼리 프로젝트를 진행하면 슬프지만 당연하게도 결과물이 원하는대로 나오지않을 확률이 높다. 나는 처음에 의지와 열정만 있으면 될 것이라 생각했지만, 그런 추상적인 감정은 사람마다 기준이 다르고 쉽게 사그라들었다. 함께 공부하며 경험삼아 해보는 것은 물론 좋겠지만, 실력자를 찾아다니면 좋은 코드를 보며 배우게 되고 프로젝트 진행도 수월한 것 같다.
• 안타깝게도 내가 경험과 지식이 부족한데, 실력자가 알아서 도와주겠다며 찾아오는 경우는 없는 것 같다. 경험이 쌓이기 전까지는 프로젝트를 직접 운영하기 보다 동아리나 커뮤니티에 참여해서 경험을 쌓고, 실력자를 찾아다니는 게 삽질을 줄일 수 있는 방법이라고 생각한다.

5. 작업 방식과 공유 방식에 대해 정해두면 갈등을 줄일 수 있다.

• 기획자로 프로젝트에 참여했을 때 와이어프레임과 관련하여 갈등이 있었던 적이 있다. 들어가는 메뉴 뿐만 아니라 레이아웃이나 강조하고 싶은 부분 등 최대한 자세하게 많은 정보를 포함하여 와이어프레임을 제작했는데, 디자인팀에서는 디자인을 생각하는 데 제한이 된다고 의견을 주셨다. 그래서 나는 어떤 식으로 와이어프레임을 제작하면 좋을지 의견을 여쭤봤고, 해당 방향대로 수정했다.
  자신이 만드는 결과물을 사용하게 될 팀원에게 제작 및 전달 방식에 대해 의견을 먼저 물어보고 작업하면 갈등을 피할 수 있을거라는 생각이 들었다. 만약 상관없다고 한다면, 일부만 작업해보고 이런 방향은 괜찮은지 물어보면 좋을 것 같다.
• 개발자라면, Branch, Issu, Commit, Pull Request, 코드 리뷰와 관련하여 규칙을 정해두면 좋을 것이다. Branch 이름을 광범위하게 정하게 되면, 작업 범위가 모호해지고 한 번에 많은 양의 코드를 병합하게 되면서 충돌이 일어날 수 있다. 기능별로 Branch를 나누고 완료되었을 때 병합하는 것이 아직까지는 가장 좋다고 생각한다.

6. 개발자, 디자이너, 기획자가 모두 기획에 참여하면 완성도를 높일 수 있다.

• 창업 동아리에서 앱을 기획했을 때 개발에 대해 전혀 몰랐고 초반에는 개발자가 없어서 좋다고 생각하는 기능은 모두 넣었다. 나중에 개발자를 구하고보니 규모가 너무 커서 모두 제작하기는 힘들 것 같다고 했다. 결국 조정할 수밖에 없었고 그 과정에서 앱의 방향성이 많이 흔들렸던 것 같다.
  개발자, 디자이너, 기획자가 모두 기획에 참여할 때, 실현가능하면서도 완성도 높은 기획이 가능하다는 것을 깨달았다.

마무리

마무리하며 이번에 진행하는 운영체제 스터디 규칙을 첨부해본다.
https://github.com/CS-Challenge/OS-Challenge/wiki/%EC%8A%A4%ED%84%B0%EB%94%94-%EA%B7%9C%EC%B9%99
전공지식이 부족한 것 같다고 생각해서 운영체제, 네트워크, 데이터베이스, 자바&스프링 별로 5주씩 챌린지를 진행해보려 한다. 스터디를 마칠 때면, 기초가 튼튼한 멋있는 신입 개발자가 되어있기를 바란다.