Pam
Pam 블로그 주인장

[BDD] 개발 동아리 만들기 (feat. Brighten Developer Domain)

BDD가 만들어지기까지

동아리 노션

BDD 로고

나는 보안에 큰 뜻이 없지만 대학 신입생 시절부터 모교의 보안 동아리에서 활동했다. 보안에 열정적이지 않았음에도 활동 회원이라면 반드시 해야하는 발표와 기술문서를 매년 수행하며 4년(정확히는 3년 반)의 기간동안 보안 동아리에 속해있던 이유라고 하면, 우리 학교에 있는 기타 다른 개발 동아리보다 해당 보안 동아리에 개발 인재가 많았기 때문이다.

어쩨서 보안 동아리가 풍부한 개발 환경을 가지고 있는가? 사정은 많았지만 축약해서 말하자면 우리 학교에는 개발 공부를 지원해줄만한 환경이 부족했다.

비록 보안동아리에서 활동하고 있었으나, 우리는 개발 스터디를 통해 자신의 분야에 대해 배울 수 있었고, 동아리 홈페이지 제작이라는 큰 프로젝트를 함께할 수 있는 좋은 기회 또한 얻을 수 있었다.

그러나 동아리가 ‘보안 동아리’의 정체성을 굳히기 시작하면서 문제가 생겼다. 정체성을 확실히 하는 것이 나쁜 것은 아니기에 그 정체성에 반하는 ‘개발’에 대한 지원과 관심이 점차 줄어드는 점은 어쩔 수 없었다고 생각한다.

하지만 우리는 개발 공부를 할 곳이 필요했다!

그러나 본교에는 개발자들을 위한 체계와 매력적인 활동이 마련된 곳이 마땅히 없었다. 그렇다면 우리가 만드는 수밖에 없다. 그렇게 만들어진 동아리가 BDD(Bright Developer Domain)이다. 임원진 셋이 함께 기획하고, 주변 인물들을 끌어모아 완성된 웹 개발자와 디자이너들을 위한 커뮤니티이다.

BDD에 대한 본격적인 기획이 시작된 것이 2023년 9월 초이고, 현재 2024년 1월 초이니 벌써 만들어진지 5개월이 지났다. 그동안 총 5개의 스터디가 열렸고, 2개의 프로젝트가 진행 중이며, 첫 번째 세미나가 다가오는 2월에 개최될 예정이다. 처음에는 회원과 임원진에게 모두 잊혀진 동아리가 될까 두려움도 있었으나 결과적으로 어느정도 성장한 동아리가 된 것 같아 안심이다. 이렇게 동아리가 커질 수 있었던 건 다른 두 명의 임원진의 역할이 컸다. 그 둘에게 매우 감사하고 있다.

개발자 동아리, 혹은 커뮤니티를 생각하고 있는 사람들을 위해 BDD가 무엇에 집중했는지에 대해 작성해볼까 한다. 참고로 BDD는 대학교 공식 동아리가 아니기에(공식 동아리 등록을 고려 중이다.) 대학교 동아리 등록과 관련된 지식은 전달할 수 없다는 점을 먼저 밝힌다.


적극적이고 열정있는 임원진

회의록

BDD 개설에 대한 논의는 8월부터 이야기 되었으나 사실 그 이후 대략 한 달간은 방치되었다. 임원진 세명이 모두 학교와 부트캠프 활동 때문에 바빴고, 함께 모일 기회가 없었기 때문이다. 이대로는 영영 잊혀질 것이 뻔했기 때문에 임원진 셋은 매주 동아리 기획 회의를 진행하기로 결정했다.

열정적인 임원진들 덕분에 매 기획 회의에서 새로운 안건이 논의되었고, 그를 기반으로 동아리의 틀을 잡아갔다. 동아리의 방향성 또한 수십번씩 바뀌었다. 어느 정도 동아리의 모양이 잡힌 지금도 회의에는 항상 1시간 30분 정도의 시간이 소요된다. 그만큼 임원진들이 동아리에 많은 관심과 시간을 투자하고, 동아리의 방향에 대해 고민하고 있기에 BDD가 지금만큼 성장할수 있었다고 생각한다. 이는 정말로 다른 두 명의 임원진들의 덕이 컸다.

BDD 기획 과정에 대해서는 아래 팀블로그 포스팅에 훌륭하게 설명되어 있으니 궁금한 사람은 읽어보길 바란다.

개발 소모임 ‘BDD’를 만들게 된 과정

회원들의 참여를 유도하라

걱정했던 것과 달리 초기 동아리 인원은 쉽게 모아졌다. 오히려 주변에서 가입 요청이 들어올 정도… 이들은 이전에 언급한 보안 동아리에서 활동하던 개발자들이기도 했다.
이런 초기 동아리, 혹은 그룹에서 가장 두려워하고 경계해야 하는 것은 참여자들에게 잊혀지는 것이라 생각한다. 잊혀진다는 것은 동아리로써의 신뢰성을 잃는다는 것과 일맥상통한다. 아직 동아리 이름을 건 활동이 아무것도 이루어지지 않은 지금, 회원은 자신의 시간을 투자할만큼 동아리를 신뢰할 이유가 없고, 그럴수록 회원에게 잊혀진다는 건 타격이 크다.

설명회

동아리 초기 인원들은 모두 입소문 혹은 임원진들에게 직접 간단한 설명만을 듣고 가입한 사람들로, 동아리의 정체성을 확실히 하기 위해선 이들에게 BDD가 정확히 어떤 동아리인지 설명할 필요가 있었다. 따라서 회원들에게 BDD와 그 내부에서 이루어지는 활동에 대해 설명하기 위한 설명회를 준비했다.

설명회

슬랙 활성화

동아리에 회원들의 관심을 유지시키는 것은 힘든 일이다. BDD는 기획이 한창 진행되는 중인 동아리었고, 회원들이 BDD의 이름을 걸고 할만한 활동이 완성되지 않았다. 이런 상황에서 회원들에게 BDD를 인식시키기 위한 제일 좋은 방법은 BDD 슬랙의 주기적인 접속이라 생각했다.

매주 임원진 회의를 통해 새로운 결정사항에 대한 공지가 올라오긴 했으나 임원진측의 일방적인 메세지로는 접속률을 기대하기 어려웠다. 그리고 의미있는 활동률을 만들기 위해선 회원이 직접 메세지를 올려야 한다 생각했다. 따라서 BDD의 첫번째 공식 활동으로 챌린지가 시작됐다.

갓생챌 시트

첫번째 챌린지로 글쓰기 챌린지와 갓생(생활 규칙 만들기) 챌린지 두 가지가 열렸다. 그 중 내가 진행한 갓생 챌린지는 메세지와 사진으로 자신의 목표를 인증하는 형태로, 인증을 하기 위해선 BDD 슬랙에 접속해 직접 메세지를 남겨야 했다.

게더

image

또한 BDD 전용 게더를 생성해 BDD만의 온라인 공부 공간을 만들었다. 물론 접속하는 사람만 접속하곤 했으나 고정 접속 회원을 만든 것만으로도 의미가 있었다. 참고로 게더-왔다감 채널을 통해 다른 회원들의 접속 상황을 알수 있도록 했는데 상당히 좋아 추천한다.


회원들의 공통 목표를 만들어라

image

당연하지만 위에 설명한 활동들은 BDD의 메인코스가 아니다. 임원진들이 BDD를 개설한 목적은 ‘프로젝트’였다. 프로젝트를 성공적으로 완성하기 위해 신뢰할 수 있는 동료들을 만날 수 있는 곳으로 만들고싶었다.

동아리 운영에 대한 조언을 얻기 위해 교수님과 BDD 임원진(+회원 한 분)끼리 미팅을 가진 적이 있는데, 이때 강조받았던 것이 동아리원 공동의 목표이다. 하나의 목표를 가지는 것으로 동아리원들의 소속감뿐만 아니라 동아리의 매력 또한 얻을 수 있다는 것이다.

또한 교수님께 들은 비판점 중 하나가 명확한 목표 없는 광범위한 활동을 경계하란 부분이었다. BDD의 개설 목적이 프로젝트이긴 했으나, 프로젝트 외로도 꽤 많은 양의 활동(세미나, 스터디, 기술문서 등등)이 존재하고 있었기 때문이다. 당연하게 BDD의 목표는 프로젝트 런칭이 되었다. 프로젝트를 동아리의 주 목표로 잡은 만큼 그에 더 많은 시간과 관심을 쏟고 있다. 실제로 프로젝트 기획을 시작한 이후로 본격적인 동아리로 활동하고 있다는 느낌을 강하게 받는다.

그것이 꼭 프로젝트가 아니더라도 동아리를 하나로 유지하기 위해선 동아리원들이 바라볼 하나의 목표가 중요하다 생각된다. 어쩌면 대회 입상일 수도 있겠고, 동아리 홈페이지 제작이 될 수도 있겠다.

이후 프로젝트가 종료된 뒤 교수님과의 미팅 내용과 실제 프로젝트 진행 경험을 비교하며 글을 써보고 싶다.


개발자 외 인원을 배려하라

디자이너와 협업하는 경우 개발자의 사고를 멀리해야한다. BDD는 개발자뿐만 아니라 디자이너와 함께 꾸려나가는 동아리를 목표로 하나, 동아리를 구성하는 임원진 셋은 모두 개발자이다. 동아리를 기획하며 여러 아이디어를 실천에 옮겼으나 사실 프로젝트가 시작하기 전까지 디자이너가 참가할만한 활동이 마땅하지 않았다. 짧게 말해서 BDD는 디자이너들을 방치하고 있었다… 이를 해결하기 위해 임원진 회의에서 열심히 머리를 굴려보았으나 결론적으로 디자이너를 위한 활동은 개발자가 생각할게 아니라는 답이 나왔다.

따라서 디자이너를 위해 BDD에서 무엇을 할 수 있을지 얘기하기 위해 디자이너 두 분에게 대면 모임을 요청드렸다. 이 모임에서 임원진과 디자이너가 직접 만나 궁금했던 사항을 직접 질답하며 많은 의문점이 해소되었다. 물론 지금껏 디자이너를 위한 활동을 준비하지 못한 점에 대해서도 사과드렸다.

아래는 위 모임에서 여쭤본 질문들이다.


  • 한 번에 처리할 수 있는 작업량은은 어느 정도가 적당한가
  • 작업 기간은 어느 정도가 적당한가
  • 웹 디자인 외로도 BDD 내부에서 필요한 디자인을 작업해도 괜찮은가
  • 디자이너 커뮤니티에서도 개발자 커뮤니티처럼 기술문서와 세미나 발표를 하는가
  • 팀 블로그를 작성할수 있는가
  • 어떻게 하면 디자이너들에게 매력적인 동아리가 될 수 있을까


덕분에 개발자와 디자이너들 간 공부 지향점에 대한 차이를 알게 되었고 작업물을 맡길 때에 대한 규칙을 결정할 수 있었다.

꼭 디자이너와 개발자간의 관계에만 국한된 이야기는 아니지만, 개발자가 다수로 이루어진 그룹에서 개발자 외 사람들 소수와 작업할 때 개발자 중심적 사고로 팀을 이끌지 않도록 항상 주의해야한다. 마찰없이 팀을 이끌고 싶고, 다음에 그들과 또 다시 함께 일하고 싶다면 다른 사람들보다 더 신경써주고, 항상 감사하다는 말을 직접 전하자.

혹자는 굳이 그렇게 해서까지(개발자 회원보다 더 많은 신경을 쓰면서까지) 해야하나? 생각할지도 모르겠다. 그러나 사실 이 부분은 개발자에 국한된 이야기가 아니라, 자신과 다른 분야의 사람과 함께 일한다면 당연하게 해야하는 일이라 생각한다.

무엇보다 프로젝트는 개발자들끼지 진행하는 것이 아니기 때문에, 우리가 그들을 배려하는 만큼 그들이 자신이 맡은 일에 더 최선을 다하지 않을까, 하고 생각한다. 아래는 BDD의 디자이너분들이 만들어주신 작업물 중 일부다😄

디자이너 작업물- 로고 디자이너 작업물- 두레