서론

필자는 멋쟁이사자처럼 대학 12기 프론트엔드 파트로 참여하였다. 본 포스팅은 동아리 합격부터 아이디어톤, 중앙해커톤 등에 관한 내용을 담고 있다.

원래는 깃허브 블로그 이전 후 글을 작성하려고 하였으나 학업 일정 등이 바빠 진행하지 못하였다. 시간이 더 지나기 전에 블로그(velog)에라도 회고를 남겨야겠다는 생각에 해당 포스팅을 작성하게 되었다.

현재는 깃허브 블로그로 이전하여 해당 포스팅을 옮겨왔다.

멋쟁이사자처럼 대학 12기 합격

혼자 웹 개발 공부를 하면서 제대로 된 프로젝트를 진행해보고 싶다는 생각은 있었지만 개발 지식도 부족한 채로 완전한 프로젝트를 진행하는 것은 무리였다. 또한, 협업을 진행해보고 싶었지만 부트캠프와 같은 곳은 참여하기엔 부담이 있었다.

‘컴퓨터공학과’라고 하면 방 안에서 코딩만 하는 그런 모습이 흔히 연상된다고 하지만 현실에선 협업이 필수이다. 협업을 해야된다는 압박과 협업에 대한 걱정 도중 대학교 내에서 ‘멋쟁이사자처럼’이라는 동아리가 있다는 것을 알게 되었다.

교내 동아리라는 점, 비전공자도 참여할 수 있을만큼의 난이도와 커리큘럼, 아이디어톤 및 해커톤 참가 등의 요소가 마음에 들어 큰 마음을 먹고 신청하게 되었다.

나는 백엔드 파트로 신청을 하였지만, 우연한 기회로 프론트엔드 파트로 합격하게 되었다. 처음 카톡방에 초대되었을 때 생각보다 인원이 많아서 놀랬다. 설렘 반 기대 반인 마음으로 OT를 참가하였다. 좋은 실력과 마인드를 가진 운영진분들 덕분에 활동에 대한 걱정이 기대로 바뀌게 되었던 것 같다.

기획디자인(P&D) / 프론트엔드(FE) / 백엔드(BE) 파트로 나누어 활동을 진행하고, 커리큘럼, 아이디어톤과 해커톤에 대한 계획을 들었을 때 “생각보다 더욱 체계적이고 빠른 일정인데 내가 과연 다 할 수 있을까?”라는 생각을 가장 먼저 했었던 것 같다.

교육 수강 - React

프론트엔드 파트로 React 강의를 수강하였다. 필자는 방학 때 Udemy를 통한 React + express.js 강의를 수강하였던 경험이 있어 강의에 대한 부담감은 약간 줄어든 것 같았다. 물론, 그 때의 기억이 제대로 남아있지는 않았던 것 같다.

1학기동안 매주 화요일, 금요일 저녁 7시-9시에 React 강의를 수강하였다. 프론트엔드 트랙 덕분에 학교에 정말 오랫동안 남아있었던 것 같다.

프론트엔드 교육 과정에 대해서 이야기를 하자면 누구나 충분히 따라갈 수 있는 수준이었고, 매 시간마다 프론트엔드 운영진분들이 돌아다니시면서 도움을 주셨기 때문에 비전공자 아기사자들도 충분히 교육을 수강할 수 있었다.

아이디어톤

내 인생 처음 프로젝트 협업이었다. 동아리에 아는 사람도 많이 없었기에 정말 많이 고민했었다. 또한, 나는 아르바이트때문에 뒷풀이 등에도 참여를 하지 않았기에 “남는 팀에 들어가겠구나”라는 생각을 했었다. 그러던 도중 감사하게도 몇몇 분들이 팀원을 제안해주셨다.

아이디어톤의 주제는 "현대인의 건강(Wellness) 문제 해결"에 관한 내용이었다.

Wellness의 뜻은 ‘육체적 건강’ 뿐만 아닌 ‘정신적, 사회적 건강’을 의미하기도 한다. 따라서, 정말 다양한 주제가 나올 것이라고 예상했었다. 결과부터 말하자면 생각보다 비슷한 프로젝트들이 많이 나온 것 같다.

우선 아이디어톤 회의를 위해 프론트엔드 수업이 끝난 후, 팀 티칭 카페에 가서 첫만남 및 아이디어 PR을 진행하였다.

프론트엔드 팀원을 제외한 나머지 디자인, 백엔드 팀원들은 당시 처음보았기 때문에 꽤 어색하였다. 제대로 인사도 나누지 못한 채 바로 아이디어 PR에 들어갔다. 나는 아이디어 PR도 정확히 어떤 내용인지 몰랐기에 브레인스토밍 형식의 대화인 줄 알았는데 각자 준비해온 내용을 한 명씩 발표를 하면서 그에 대한 질의응답을 받는 형식으로 진행이 되어서 꽤 당황했었다.

물론 내가 생각하고 준비해온 주제였긴 하지만 처음만난 팀원들과 운영진분들 앞에서 첫 번째 순서로 질의응답을 받아야 한다는 등의 요소들에 긴장이 되었다. 덜덜 떨리며 발표를 마무리했었던 것 같다. 질의응답도 받았지만 그 부분도 돌이켜보면 제대로 답을 하지 못하였던 것 같다.

회의를 통해 ‘직장인 취미 동아리 플랫폼’, ‘자녀 감정 솔루션 게임’, ‘혈당 스파이크 측정 및 연계 서비스’, ‘가짜 뉴스 진단 확장 프로그램’ 등 다양한 주제가 나왔었다.

처음에는 '혈당 스파이크 측정 및 밀키트 연계 서비스'를 주제로 정하였다.

그러나 이미 시장에 나와있는 서비스이기도 하며, 꽤나 약점이 많은 서비스였기에 ‘자녀 감정 솔루션 게임’이라는 주제로 방향을 수정하게 되었다. 그러나, 학기 중에 이루어지기도 하였고 예선까지 꽤나 시간이 촉박하였기 때문에 완벽한 준비는 하지 못하였던 것 같다.

아쉽게도 예선에서는 떨어지게 되었다. 그러나, 후회는 없었다. 꽤나 열심히 준비를 했고 오히려 우리 팀원들에 대한 믿음이 더욱 생긴 것 같다. 이 때 디자인의 중요성을 느끼기도 하였고, 우리 팀들도 정말 책임감있게 진행을 한다는 것을 느꼈기에 오히려 해커톤이 더욱 기대되었다.

예선 탈락 후 팀원들과 학교 주변 술집으로 향했다.
그 자리에선 개발 이야기가 아니라 여행, 술자리 등의 주제로 사람 사는 이야기들을 나누며 즐겼던 것 같다. 덕분에 우리는 아이디어톤을 탈락했음에도 더욱 뭉칠 수 있었던 것 같다.

아이디어톤 본선에 대한 결과는 유튜브나 노션 등으로 확인할 수 있었는데, 우리가 회의 때 이야기했던 주제들과 비슷한 주제들이 많아 한편으로는 아쉽기도 하였다. 그러나, 오히려 아이디어톤에서 비슷한 주제가 많이 나온다는 것을 알게 되어, 이후 중앙 해커톤 때는 조금 더 참신하고 좋은 주제를 찾으려고 노력할 수 있는 계기가 된 것 같다.

중앙해커톤

1학기가 끝나고 여름 방학 때 중앙 해커톤을 실시하게 되었다. 해커톤 주제는 아이디어톤과 동일한 Wellness였다.

앞서 언급하였듯이 우리는 주제 변경이 필요했기 때문에 카페에서 만나 주제부터 정하였다. 참신한 주제와 실현 가능한 정도의 범위 내에서 주제를 고민하였다.

우리는 ‘헌혈증 기부 플랫폼’이라는 주제로 ‘Gibble’이라는 서비스를 개발하기로 하였다. 개발 환경은 아래와 같다.

• Front-end : React
• Back-end : Spring
• Configuration Management : Git
• Deployment : AWS EC2
• CI/CD : Git Actions

초반에는 우선 정말 필요한 기능을 중점으로 개발을 진행하는 것에 목표를 맞췄다. 1달이라는 기간이 주어지긴 하지만, 다들 아르바이트 및 개인 일정 등이 있기도 하였기에 개발 범위를 적절히 정했던 것이 가장 좋았던 부분이었기도 한 것 같다.

해커톤 당일, 우선 현장에 도착해서 신원 확인을 한 뒤 이름표와 티셔츠를 나누어주었다.

이름표를 받고 현장에 들어간 순간 대회장 규모에 놀랬고, 사람들이 아직 다 도착하지 않았음에도 엄청 많아서 두 번 놀란 것 같다.

나는 사진을 많이 찍지 않아서 현장 사진이 많이 남아있지 않다.

아래의 현장 사진은 우리 대학교 테이블 위치에서 이벤트 부스 쪽만 찍은 것이며 뒤쪽으로 정말 많은 사람들이 있었다. 현장 사진은 멋쟁이사자처럼 인스타나 유튜브, 홈페이지 등에서 더욱 생생하게 확인이 가능하다.

우리는 개발이 완료한 상태로 도착하였기에 12시 자료 제출까지 시간이 많이 남았다. 이벤트 부스에서 다양한 체험도 하였다. 나는 운이 좋게도 한 부스에서 1등에 당첨되어 키보드 키캡을 받을 수 있었다. 그러나, 키보드 키캡을 받았을 때 뒷 쪽 다른 부스에서 “1등!”이라는 소리가 들렸고 그 분은 에어팟을 받으셨다. 절대 아쉬워서 쓰는 글이 아니라 이벤트 부스에서 남았던 일이라 쓰는 것 뿐이다. 아니다.

간식도 사오고 팀원들과 놀기도 하다보니 마감 1시간 전 쯤이 되었고 운영진분들께서 각 팀들을 돌아다니면서 테스트를 진행하였다.

그런데 여기서 가장 큰 문제가 발생했다.

null 이나 빈 공백을 여러 개 입력하였을 때, 그대로 제출이 되어버린다는 치명적인 오류였다. 프론트엔드에서는 react-hook-form 라이브러리를 사용하여서 validation에 관한 부분을 구현하였는데, 어떤 페이지는 유효성 검증이 제대로 구현이 되어있고 또 다른 페이지는 제대로 구현이 안 되어있었다.

매번 확인하고 유효성 검증을 추가해서 구현했다고 생각했었는데 협업이다 보니 이런 부분에 있어서 제대로 소통이 되지 않았던 것 같고, 당연히 확인의 미흡도 있었던 것 같다. 시간이 정말 얼마 남지 않았던 시점에서 너무나도 큰 오류 발생에 다른 팀원 분들에게 미안함을 느꼈다. 당장 급하게 수정을 시작하였다.

여기서도 한 가지 추가적인 문제가 있었는데, 바로 대회 장소에서는 와이파이 및 핫스팟이 잘 안 된다는 점이었다. 이걸 대비해서 운영진분께서 사전에 테더링 방법을 가르쳐주셔서 나는 문제없이 오류 수정이 가능해서 급하게 오류 수정 후 11시 55분 쯤까지 다 고쳐서 제출하였다. 정말 당황스럽기도하고 미안하기도 하였다.

어찌저찌 제출을 하고나니 시간은 12시가 되었다. 12시부터 새벽 1시까지 배달음식을 시켜먹고, 4시까지는 네트워킹 시간이었다.

배달음식으로는 치킨을 먹었었는데 오류 수정을 하며 너무 당황해서인지 그렇게 잘 넘어가지도 않았고 밤이 되니 오히려 힘이 들어 치킨도 잘 넘어가지 않았다. 혹여나 해커톤에 참가할 계획을 둔 독자라면 차라리 샌드위치나 아이스크림과 같은 간단한 음식을 시키길 추천한다.

네트워킹 시간에서는 다른 팀들의 작품을 자유롭게 감상하고, 설명해주는 시간이었다. 우연히 지나가다가 다른 팀들의 작품을 보고 말을 걸 수도 있었고, 메신저를 통해 원하는 대학끼리 만날 수도 있었다.

우리는 무대 앞쪽 제일 가장자리에 있었기 때문에 맥주를 받으러 가시거나 자유롭게 돌아다니시는 다른 분들에게 많은 관심을 받은 것 같기도 하다. 우리도 다른 팀들의 작품을 보러갔을 때 정말 참신하기도 하고 기술적으로도 대단하다는 생각이 드는 작품도 많이 마주쳤다.

어떤 팀들은 팜플렛이나 단체 티셔츠, 명함, 스티커 등을 만들어 홍보하기도 하셨는데 예상치도 못한 부분이라 대단하다는 생각이 들었다. 개발자는 방에서 코딩만 한다는 이야기는 확실히 거짓말이다.

본선 진출

그렇게 새벽 시간이 지나가고 점점 텐션이 떨어져가며 몸에는 피로만 가득 쌓였다. 원래는 대구로 내려가는 9시 기차를 예약해놨었지만 몸이 힘들어 최대한 빠른 기차를 타고 내려가고 싶다는 생각 뿐이었다. 다른 대단한 작품을 많이 봐서인지, 아니면 제출 직전 오류 발견 때문인지 본선 진출에 대한 마음이 크게 없어서 그랬던 것 같기도 하다.

어느덧 본선 진출팀 발표의 시간이 왔다. 300여 개의 팀 중에서 8팀만 뽑아 본선 발표를 진행한다. 많은 사람들이 지친 시간대이기도 하였고 속속 첫 차를 타고 갈 준비를 하는 사람들이 많이 보였다. 어떻게 보면 나또한 그 중 한 사람이었을 지도 모르겠다.

본선 진출 팀들이 불리기 시작하면서 환호성이 들리기 시작했다. 네트워킹 시간에 보았던 다른 대학교 팀들이 호명되기도 하였다. 갈수록 우리는 다들 집에 갈 준비를 하는 느낌이었다. 어느덧, 7팀까지 발표가 끝나고 우리 팀끼리는 장난으로 “역시 주인공은 마지막에 등장하는구나”라며 장난을 쳤다. 사회자 분의 “마지막 본선 진출 팀은~” 이라는 멘트가 들렸지만 신경쓰지도 않았다. 그냥 이 첫 차 전쟁에서 빨리 지하철을 타고 대구로 내려갈 수 있을까라는 생각이 더 컸던 것 같다.

그러자 “영남대학교의 두드림팀!”이라는 멘트가 들려왔다.

본인은 사실 영남대학교라는 말이 나왔는데도 신경을 안 쓰고 있어서 우리 팀을 이야기하는 지도 몰랐다. 그러나 귀에 “두드림”이라는 말은 정확히 들어왔고 피곤해하던 우리 팀원들이 다들 소리를 지르며 환호했다. 후에 같은 팀원분이 말하길 우리 대학교까지는 들었어도 당연히 다른 팀이 불리겠지라 생각했다고 한다.

그 순간은 몇 개월이 지난 아직까지도 생각날 만큼 짜릿한 순간이었다. 새벽 4시에 도파민이 터지는 순간이었고 심장이 두근거렸다. “이 1500명 중에 우리가 본선 진출을 했다고?”라는 건 아직도 믿기지가 않는다.

팀장님은 바로 발표를 위해 앞에 나가서 발표 순서 추첨을 하였다. 1번이었다. 왜 하필이면 1번일까라는 생각도 있었고, 어떻게보면 1번이라 다른 팀들이 하는 걸 안 본다는 것이 다행이라는 생각도 있었다.

위 사진은 우리 팀 발표 사진이다. 내가 팀원이었기 때문이 아니라 현장에서 직접봤던 사람으로서, 1500명의 학생들과 심사위원들 앞에서 새벽 4시에 첫 순서임에도 불구하고 발표를 엄청 잘해주었다. 나머지 팀원들드 밑에서 지켜만 볼 뿐인데도 손이 떨리고 심장이 빨리 뛰었다. 감히 내가 이런 표현을 하는 게 맞는 지 모르겠지만 정말 ‘팀장’이라는 사람은 저런 사람이 해야되는구나를 느꼈던 것 같다.

그런데 한 가지 아쉬운 것이 있다. 바로 발표가 끝난 후 심사위원의 질의응답 시간에 내가 같이 나가지 못했던 것이다.

발표 시작 전 진행요원 한 분이 와서 “발표 전에 질의응답 같이하실 분은 미리 단상 옆에 나와서 대기해주세요”라고 하였지만, 너무 떨려서인지 발표 대기하는 사람이 많기 때문에 질의응답 전에 부르면 나오라는 이야긴 줄 알았다.

내가 프론트엔드 파트에서 주도적으로 맡아선 한 부분이 꽤 있어 나 스스로 발표가 있다면 내가 나가서 하는 게 맞을 것 같다는 생각을 했었다. 사실 떨렸다는 말도 어쩌면 내 변명거리인 줄 모르겠다. 질의응답을 같이 해야한다는 것을 알고있음에도 결국엔 내가 나서지를 못한 건 틀림없는 사실이기 때문에 시간이 지나도 정말 부끄러웠다. 또한, 팀장님에게 너무 고마웠고 미안했다.

시상식

시상식에서는 우선 본선 진출팀을 다 무대 옆으로 불러내어 대기시켰다. 이름을 부르는 4팀은 올라가서 시상을 하는 형태였고 우리도 앞에 나가서 대기하였다.

참 사람 마음이라는 것이 간사한 게 처음에는 본선 진출에도 욕심이 없었지만, 막상 본선 진출을 하니 수상에 대한 욕심이 생기기 시작했다. 대상, 최우수상까지는 아니더라도 장려상 정도는 받을 수 있지 않을까는 생각을 하였다.

다른 팀들의 아이디어는 주제가 겹치는 부분이 있는 곳도 있었고, 우리 팀이 만든 발표 자료나 구현물 디자인이 너무 좋았기 때문에 그런 욕심이 생겼던 것 같다.

결과는 아쉽게도 수상을 하지는 못하였다. 그러나, 정말 멋쟁이사자처럼 활동의 마지막이라고 할 수 있는 중앙해커톤에서 본선 진출이라는 큰 쾌거를 이루어낸 것은 너무 자랑스럽다.

사용 툴 및 기능에 대한 회고

📌 figma

figma를 사용한 와이어프레임 구성 및 회의 등을 진행을 했었다.

figma가 협업에 있어 굉장히 강력한 툴이라는 것을 알게 되었다. 특히 디자이너가 설계한 디자인에 대한 html, css 코드 추출이 가능하다는 점이 큰 이점으로 작용하였다.

그러나, 완전한 리액트 코드로 추출은 추가 플러그인을 구매하는 등의 작업 등이 필요한 것 같아 제약이 있었고, 요소 간 gap 등에 대한 css 관련 문제가 있기도 하였지만 충분히 잘 활용할 수 있었다. 디자인한 요소를 개발자 모드를 통해 보면 각 요소의 크기, 거리 등이 픽셀 값을 볼 수 있었다.

이를 그대로 복사 붙여넣기해도 되는 경우가 있었지만, 글로벌 스타일 및 전역 변수 등의 설정을 해주어 중복되는 코드 양을 줄이는 것이 좋은 설계라고 생각하여 최대한 줄일 수 있는 부분은 줄여나갔던 것 같다.

📌 git

이전 학기 소프트웨어 설계 수업 등을 통해 git을 사용하여 과제를 제출한 적이 있긴 했지만, 아직 git에 대해 잘 모른다는 것은 당연한 사실이었다.

이번 프로젝트를 통해서 가장 많이 얻어간 것 중 하나가 git이라고 봐도 무방할 정도로 정말 많은 지식을 얻은 것 같다. 협업에 있어서 git을 어떻게 사용을 하는지, 브랜치의 사용과 PR에 관한 내용은 프로젝트를 진행하면서 자연스럽게 체득을 하고 익숙해졌었던 것 같다.

당연하게도 git 관련 문제도 다수 발생하였다. 브랜치를 따로 만들어서 하면 문제가 발생하지 않는 부분들이었지만, 작은 이슈에 대한 수정이나 추가 등안 develop 브랜치에 바로 적용하여서 꽤 많은 문제가 발생했었다.

해당 문제에 관해서는 정말 많은 자료를 찾아보고 테스트해보며 해결해나간 것 같다. 이에 관한 포스팅을 작성하였으니 확인 가능하다.

많이 애를 먹었기도 하였지만, 그만큼 해결을 해나가며 얻은 지식도 많은 것 같다. “일단 해보고 시원하게 망하면 다시는 안 까먹겠지”라는 말이 틀린 말도 아닌 것 같다. 우선은 “일단 해라”가 가장 중요한 마인드인 것 같다.

또한, 우리팀 뿐만 아니라 다른 팀의 리포지토리도 확인을 할 수가 있었기에 git issue나 label 등 다양한 git 활용법을 확인할 수가 있었다.

📌 AWS EC2

공동 트랙을 들으며 정말 관심이 있었고 감사했던 게 AWS EC2를 통한 배포 강의였다. 요즘 단순히 구현 코드에 관한 내용은 많은 자료나 공식문서, GPT 등으로 찾아보는 게 가능하다고 생각하지만, 배포와 같은 부분들은 자료를 찾아보아도 이해하기가 힘들고 정말 막막하다. 다행히도 운영진분들께서 방학 때 따로 강의 시간을 마련해주셔서 강의를 들을 수 있었다.

이후 Git Actions를 통한 CI/CD에 대한 내용도 나오겠지만, 이러한 강의들을 방학 때 운영진분들께서 직접 시간을 내셔서 강의를 진행해주셨다. 이후에 운영진분들이 방학 때 다른 할 일도 있어 얼마나 바쁘다는 것을 알게되었을 때 더욱 감사하다는 생각을 했다.

혼자서 개발을 진행하다보면 localhost를 통한 접속이 일반적이기에, 배포를 하여 고유한 IP로 접속이 가능하다는 것이 너무 신기하고 뿌듯하다는 느낌이 들었다. 외부 리소스를 드디어 사용 해본다는 느낌이 들었다.

그 외에도 AWS의 다양한 서비스 Route53, RDS, Certification Manger 등의 다양한 서비스에 대한 이야기를 들을 수 있었고, VPC와 같은 시스템 아키텍쳐에 관한 내용도 들을 수 있었다.

나에게는 코딩을 넘어 개발 식견을 넓혀준 소중한 경험이었다.

📌 git actions

공동 트랙 강의에서 배포 뿐만 아니라 CI/CD에 관한 내용을 들을 수 있었다. CI/CD가 무엇인지 유튜브를 보고 개념 정도만 알고 있었는데 실제로 적용을 시켜보니 얼마나 중요하고 유용한 서비스인지 알 수 있었다.

다른 개발 지식에 비해 혼자 찾아보는데 가장 큰 한계가 있는 것 같은 부분이라고 생각한다. 이러한 부분을 강의를 통해 들을 수 있다는 것은 정말 감사하였다.

프론트엔드 팀원들도 프로젝트를 다 처음해보았기 때문에 git actions를 통한 CI 과정이 없었다면 개발이 더욱 막막했을 것 같은 느낌이 들었다.

📌 스프레드시트 SRS

가장 우선적으로 주제에 대한 요구사항 명세서 작성부터 시작하였다. 혼자 개발할 때는 SRS를 적을 일이 거의 없기 때문에 이 작업도 처음이었다. 모든 개발이 완료된 시점에서 SRS을 중요성을 정말 뼈저리게 느끼는 것 같다. 역시 모든 프로젝트는 기본이 중요하다. 초반에 설계를 어떻게 하는가에 따라 나중의 결과물에도 영향을 끼친다.

2학기 소프트웨어 공학 설계 수업에서 “소프트웨어란 건축과 같은 물리적인 활동과 달리 Risk가 적을 것 같지만, 빈번한 수정이 발생하게 되면 Risk 발생 확률이 증가하게 된다”는 말을 들은 적이 있다. 어떻게 보면 당연한 이야기같지만 프로젝트 진행에 있어 핵심을 관통하는 말이다. 초반 설계가 제대로 되지 않아 많은 수정이 발생하게 되면 그 만큼의 비용이 발생한다. 오히려 이미 시작을 하였기때문에 많은 결과물들이 쌓여있어 더욱 수정이 어려워진다는 것을 느꼈다.

📌 Jira

우리는 Jira를 일정관리 툴로 사용하였다. 앞서 SRS를 작성한 뒤 각 스프린트로 일정을 나누어 진행하였기 때문에 더욱 체계적으로 진행할 수 있었다고 생각한다. 이는 곧 PR의 제목 타입으로 사용하기 하였으며 굉장히 도움이 되었다. 프로젝트 진척도 파악 등도 용이하였다.
빠르게 진행되어야 했던 프로젝트인만큼 애자일 개발 방법론을 잘 적용하여 프로젝트를 진행한 것은 큰 경험이었다.

마지막으로 모든 것을 돌아보며

중앙해커톤을 끝으로 멋쟁이사자처럼의 주요 활동은 끝이 났다. 본선 진출이라는 기대 이상의 결과를 얻었고, 좋은 사람들과 많은 개발 지식과 인사이트를 얻을 수 있었기에 정말 만족하는 활동이었다.

이런 IT 동아리를 하게되면 개발자의 SW 간 상호작용을 가장 먼저 떠올리기 쉽지만, 나는 ‘사람’이 가장 먼저 기억에 남는다.

먼저, 운영진분들의 많은 노력과 도움이 없었다면 모든 활동이 힘들었으리라 생각한다. 개발자는 오픈 소스 등의 문화가 활발하고 서로 지식을 공유하는 등의 좋은 문화가 있지만, 사실 내가 배운 것을 남에게 가르쳐준다는 것은 정말 큰 용기이자 베품이라고 생각한다. 학기중, 주말, 방학할 것 없이 아기사자들을 위해 노력한 운영진분들에게 가장 먼저 박수를 드리고 싶다.

다음은 우리 팀원들이다. 우리 팀원들 역시 아는 것을 베푸는 것을 두려워하지 않고 좋은 정보는 공유하고 개발 관련 지식들을 공유해주었다. 또한, 기획디자인 파트는 인원이 혼자이기도 하고, 개발 쪽 지식도 없는 상태에서 혼자 작업을 수행한다는 것이 너무 대단하다고 느꼈고 또 그 결과물이 너무 만족스러워서 놀라웠다. 흔히, 디자이너-개발자 간에 “위로 1px…“과 같은 밈이 있는데 그걸 왜 하는지 이해가 된 것 같다. 우선, 디자인이 사람들의 이목을 집중시키고 발표 자료 등에 있어서도 이러한 실력과 경험이 크게 작용한 것 같다.

한 가지 아쉬운 점이 있다면, 기간이 조금만 더 길었다면 초기 와이어프레임 구성 등의 작업을 통해 기능 동작 과정을 조금 더 자세하게 서술하고, 디자이너-개발자 간 격차를 줄였으면 조금 더 수월한 진행이 되었을 것 같다는 생각이 들기도 했다. 모든 과정이 끝난 뒤, 다시 피그마로 모여 팀원들끼리 프로젝트 회고를 할 때도 똑같이 나왔던 지적사항이었다.

또 중요하게 느꼈던 사항은 ‘소통’이었다. 앞서 서술한 디자이너-개발자 간 격차를 줄이는 것을 포함해서 일단 소통이 굉장히 중요한 것 같다. 특히 비전공자 및 초보 개발자들을 포함하는 이러한 프로젝트에서는 더욱 중요한 것 같다. 소프트웨어 공학에 있어 ‘Communication Cost’라는 용어가 있다. 개발을 진행하며 소통이 안 되면 안 될수록 이 비용은 증가한다고 생각한다. 앞서 SRS에서 언급한 것 처럼 이미 시작한 프로젝트에 소통이 안 되기 시작하면 다시 그 진행 상황을 알려주는데 비용이 발생한다. 또한, 컨벤션과 같은 규칙을 정해두지 않으면 굉장히 큰 비용이 발생한다. 사전에 미리 PR title, PR description, Commit Message. Branch Naming 등에 관한 내용을 합의해놓는 것이 중요하다. 실제 소스코드 작성에 있어서도 코드 리뷰와 같은 활동을 통해 코드 수정을 요청할 수 있긴 하지만 사전에 미리 방향을 맞춰놓는 것이 좋다고 생각한다.

결국 나에게 멋쟁이사자처럼 활동이 뜻깊었냐고 묻는다면 당연히 그렇다라고 답변을 하고 싶다. 또한, 주변에서 고민을 하는 사람이 있으면 해보면 좋을 것이라는 추천을 적극적으로 말해줄 수 있을 것 같다.

현재 나는 원래 백엔드로 지원하였듯이 백엔드 공부를 다시 하고있다. 역시나 어려움이 많다. 그러나, 멋쟁이사자처럼에서 만났던 운영진분들, 팀원들이 나에게는 큰 동기부여이다. 덕분에 배우는 것이 즐겁고, 배우고싶다는 생각이 든다. 아직도 많이 부족한 실력이지만 더 실력을 향상시키는 것이 목표이다.

또한, 내년에 멋쟁이사자처럼의 아가사자가 아닌 운영진으로 참가할 생각이다. 나와 같이 멋쟁이사자처럼 활동을 통해 큰 동기부여와 인사이트를 얻을 수 있는 아기사자들이 또 나왔으면 한다.