PARD의 운영진이 파디들을 위해 기획하고 준비하는 방법.

PARD 3기 운영팀에서 믿음직한 삼촌을 맡고 있는 김진서입니다 :)

그동안 1, 2기에서는 파트장으로서, 세미나를 준비하고 스터디를 진행하며 파트를 운영해 왔습니다. 이번 3기에서는 운영팀으로 파드 전체를 기획, 운영하고 있어요!

이에 따라서 제가 신경 써야 하는 부분들도 좀 달라졌는데요, 파트장이었을 때는 제가 담당한 파트를 열심히 케어해야 했다면, 운영팀인 지금은 특정 파트 뿐만 아니라 파드 전체의 큰 그림을 보아야 하는 것 같습니다.

⬆️ 큰 그림을 보고 있는 운영팀의 모습.

그래서 이 메이커로그에서는 파디 여러분들이 잘 모르는 운영팀의 비하인드 스토리에 대해서 이야기(폭로?)해 보려 합니다!!

먼저 운영진 = 운영팀 + 파트장단임을 알려드립니다 :)

프로세스

일단 운영팀은 매주 회의를 기본 3번씩 합니다..

PARD에서는 하나의 이벤트를 진행할 때마다 다음의 프로세스를 거치는데요, 안건 상정 -> 아이디어 발산 -> 결정 -> Task 분배 -> 실행 -> 검토 -> 피드백 & 회고 순으로 진행합니다. 최근에 있었던 서핑데이를 준비했던 과정을 이 프로세스에 맞춰 보여드리려 합니다!

파드 운영진의 노션과 회의록 일부 대공개..!

안건 상정

서핑데이가 처음으로 논의되었던 3/16 회의록 일부를 가져왔씁니다!

⬆️ 먼저 서핑데이가 무엇인지, 왜 해야 하는지, 어떻게 진행되었는지부터 얼라인 했습니다!

아이디어 발산, 결정

⬆️ 서핑데이 컨텐츠를 발산하는 회의와 시간도 가졌습니다 ㅎ
⬆️ 각자 다른 이모지를 정해서 투표하고 결정까지 했습니다 :) 제 아이디어가 5표를 받은 게 보이네요 ㅎㅎ

Task 분배

⬆️ 6명의 운영팀이 각각 2명씩 Task를 나눠가졌습니다! @조세희 @조환 @김채린 @김성준 @이지애

실행(기획)

⬆️ 성준와 둘이서 열띤 토론을 통해 기획을 해냈습니다 :) 샤라웃 투 @김성준

특히 저에게 있어서 가장 큰 미션과 챌린지는 캠프파디어 조를 짜는 것이었는데요, 최대한 많은 사람들을 만나면서, 조 매칭 방법이 간단해야 했습니다. 그래서 ChatGPT를 통해 알고리즘을 짜보기도 하고, 파이썬으로 프로그램화도 시도해 봤지만(개발자 모드 ON..), 결과는 매우 실망스러웠습니다. ChatGPT가 제약 조건의 우선순위를 이해하지 못하더라구요.. 결국, ChatGPT의 랜덤 Generate로 파디 분들을 무작위로 섞은 후, 이전 차수의 조와 비교하면서, 겹치는 분들을 일일이 손으로 옮겨가며 조를 완성했습니다. 그 과정에서 절대 누락이 있어선 안됐기 때문에 완성하고, 다시 검토하고를 반복하다보니, 조 짜는 데만 약 3시간 넘게 소요했습니다..ㅎㅎ (뭐 알아달라고 하는 건 아니고,,ㅎㅎ 파디 분들의 뒤에서 저를 포함한 운영진들의 이런 수많은 노력들이 있었습니다,,ㅎㅎ 알아주시면 더 좋고,,~)

검토

⬆️ PPT도 성준이가 열심히..ㅎㅎ @김성준

피드백 & 회고

⬆️ 직접 참여하지 않았지만, 뒤에서 지켜보는데 그림이 너무 예뻤습니다 ㅠㅠ

너무 예뻐서 사실 타임랩스도 찍었습니다..ㅎㅎ 혹시 보고 싶으신 분들은 파드 3기 공지 노션에 있는 PARD 기록 페이지 안의 구글 드라이브에서 확인하실 수 있습니다!

저랑 성준이가 기획하고, 준비했지만 제가 제일 힐링되는 시간이었던 것 같아요. "나 개발도 좋지만, 이런 행사 기획, 운영도 좋아하네?!"를 깨달을 수 있었습니다 ㅋㅋ

서핑데이가 끝난 후, 파디분들의 날카롭고, 선명한 솔직함에 기반한 피드백을 모두 확인했습니다 :) 서핑데이를 열심히 준비했지만, 부족했던 부분이 분명 있었습니다. 하지만, 운영진들은 모자란 점을 투명하게 공유하고, 함께 보완하는 PARD의 문화를 만들기 위해, 다음 4기를 위해, 항상 피드백을 받고 기록과 데이터를 남기며, 회고하고 있어요.

PARD는 할 때마다 새롭습니다. 기수마다 분위기도 다르고, 매번 새로운 도전을 하고, 배웁니다. 그러나 기록을 남겨놓지 않고, 회고하지 않으면, 결국 남는 것은 아무것도 없습니다. 랩실에서 캡스톤을 하면서, 졸업이 가까워질수록 더 많이 느끼는 것 같아요..ㅠㅠ 성장하기 위해 회고하고, 기록과 데이터를 남기기를 생활화하는 파디 여러분들이 되었으면 좋겠습니다! 파디분들의 성장과 경험을 위해 노력하고, 준비하는 운영진들이 될 테니, 열심히 성장하고, 경험하는 파디가 되셨으면 좋겠습니다 :)

스피드런 모드 업데이트 비하인드

안녕하세요, Drop the Ball 개발자 김진서입니다!

어제 Drop the Ball의 스피드런 모드가 업데이트 되었습니다!

업데이트 내용과 그 과정에 있었던 일을 적어보려고 합니다 ㅋㅋ

계속해서 관심 가져주시는 분들께 정말 감사드립니다 :)

스피드런 모드?

스피드런 모드는 공들의 최종 단계인 볼링공까지 얼마나 빠르게 만드는지를 측정하는 모드입니다! Game over 시까지 끝나지 않는 기존 점수 모드와 달리 Clear가 존재하고, 평균 10분 내외로 짧게 즐길 수 있는 모드입니다! :)

화면에 있는 모드 Switch를 다음과 같이 SpeedRun Mode로 선택하신 후, 플레이하시면 됩니다!

개발 완료

처음에는 여유롭게 출시할 예정이었는데, @송예찬 기획자님의 독촉과.. 모드를 개발하다 보니 생각보다 금방 완료가 되어서 약 19시에 바로 배포를 했습니다.

배포 검토 신청 후 2분만에 승인이 된 저는 신나서 PARD 운영진 단톡방에 먼저 공유를 했습니다. 이때부터가 시작이었어요..😭

첫 오류 발견

이로부터 약 20분 뒤.. 첫 실수를 발견하였습니다..ㅠ 현재 기록과 최고 기록을 비교해서 현재 기록이 더 좋을 경우 최고 기록으로 저장을 해야 하는데, 비교하는 구문을 넣지 않아서 현재 기록이 좋든 나쁘든 최고 기록으로 저장해버리는 것이었습니다..😱

설레발을 쳤던 저는 30분만에 코드를 수정하고 재배포를 했습니다😢

약 20시에 배포 승인이 되었습니다 :) 그렇게 한숨 돌리고 있었는데..

테스트 코드를 그대로 올렸다..?!

20분 뒤.. @김현서 디자이너님께 연락이 왔습니다😱

테스트 중 Clear를 빠르게 보기 위해 중간단계인 풋살공이 완성되면 기록을 비교하고 저장하게 했었는데요, 그걸 기억하지 못하고 그대로 배포해버렸습니다..

다시 빠르게 수정해서 5분만에 재배포가 되었습니다. 이제야 끝났나 싶어 잘 되는지 접속을 해 보았는데..

초기 값 문제..?!

이게 웬 걸.. 공도 안 뜨고, 점수, 모드 기록 다 작동을 하지 않았습니다..😱

⬇️ 너무 경황이 없어 기록을 남기지 못해 당시 상황을 재연했습니다..

처음 페이지가 렌더링 될 때, 전에 선택해 둔 모드와 최고 점수, 최고 기록을 가져와서 화면에 그려주게 되는데, 첫 접속 시에는 이 데이터들이 존재하지 않아서 undefined된 상태였기 때문이었습니다. 원인을 파악하고, 13분만에 4차 재배포 신청을 하였습니다..😮‍💨

다행히 무려 1분만에 승인이 되었습니다.. 이제 진짜 끝이다 생각하고, 쉬고 있었는데.. 약 3시간 뒤..

최고 기록 초기 값이 잘못 세팅되어 있었다..😱

PARD 운영진 분들 중 또 한 분께 연락이 왔습니다.. 저 캡쳐 화면을 천천히 보면서 생각을 해보니.. 초기 값 세팅이 완전히 잘못 되어 있었음을 깨달았습니다.. 최고 기록 초기 값을 00분 00초 00으로 해놨는데.. 다시 생각해보니 이보다 더 적은 시간은 없는 것이었습니다..ㅋㅋㅋㅋㅋ 현재 기록과 최고 기록을 비교해서 더 적게 걸린 시간을 저장하는데, 00분 00초 00보다 짧은 시간은 없었습니다.. 바로 99분 99초 99를 최고 기록 초기 값으로 수정했고, 5차 재배포를 하였습니다!!

새벽이 다 되어서야 결국 업데이트가 마무리 되었습니다..ㅋㅋㅋㅋㅋ😮‍💨

느낀 점

일단 배포가 되고 나면 실전이다.

작은 실수도 유저에겐 큰 오류로 보일 수 있다는 것을 많이 느꼈습니다.. 업데이트나 배포 신청은 신중의 신중을 기해야 함을 느꼈습니다. 여러 사이드 이펙트를 경험하고 나니 모든 경우의 수와 엣지 케이스들을 잘 커버해야겠다는 생각이 들었습니다. 앱의 규모가 작아서 다행이었지, 큰 프로젝트였다면.. 생각만 해도 심장이 벌렁벌렁하네요. 이번에 배운 실수들을 다음에 반복하지 않도록 노력하려고 합니다!

감사합니다 :)

심심으로 시작하여 트렌딩 프로덕트 1위까지..

안녕하세요, Drop the Ball의 개발자 김진서입니다!
어제 Drop the Ball을 디스콰이엇에 프로덕트로 등록하였습니다!
생각보다 많은 분들이 관심을 가져주셔서 놀랐습니다..ㅋㅋ
먼저 정말 감사의 말씀을 드립니다 :)

첫 시작

첫 시작은 정말 단순한 이유였습니다. 수박게임 유튜브를 보다가 "내가 하면 더 잘할 것 같은데?!"라는 생각으로 게임을 해보려 했으나.. 유료게임이었습니다. 심지어 닌텐도 게임이라 닌텐도도 필요했습니다. 닌텐도가 없는 저는 마침 ReactJS가 좀 질리기도 했고, 웹으로 재밌는 걸 만들어 봐야겠다는 생각으로 시작했었습니다!

스택 선택하기

ReactJS가 질리던 찰나여서 React는 쓰지 않고 만들어 보기로 결심했고, 항상 create-react-app으로 프로젝트를 시작했던 저는 다른 프론트엔드 툴을 찾기 시작했습니다. 그렇게 알게 된 것이 바로 Vite이었습니다. (Vite과 바닐라 JS로 구현했습니다.)

Vite을 통해서 굉장히 빠르게 프로덕트를 빌드할 수 있었습니다. 그리고 수박게임의 물리엔진을 구현하기 위해서 웹 기반의 2D 물리엔진 matter-js를 사용했습니다.

개발 시작

matter-js에서는 wireframes 기능을 제공해서, 스타일을 다 빼고 Body들이 어떻게 움직이고, 동작하는지 쉽게 확인할 수 있었습니다!

여기에 스타일과 이미지를 입혔던 첫 완성 화면입니다.

그리고 첫 배포를 이 상태로 하는 바람에 도메인이 suika-game.swygbro.com이 되었다는 슬픈 이야기가..

여기까지 만들고, 주변 친구들과 학교 사람들에게 홍보를 시작했습니다. 생각보다 다들 반응이 너무 좋았습니다. 실제로 유의미한 이용자 시간도 찍혔습니다.

12월 2일에는 무려 5명의 유저 분들이 평균 약 1시간 6분의 이용 시간을 기록했네요..ㄷㄷ

본격적인 개발

MVP 테스트 이후, 본격적으로 개발에 들어갔습니다. 기존 수박게임은 저작권 문제가 생길 것 같아 @송예찬 님의 아이디어와 @김현서 디자이너님을 통해, 지금의 Drop the Ball을 만들 게 되었습니다.

너무 귀엽지 않나요?!

앞으로의 계획

추후 볼링공을 얼마나 빨리 만드는지 겨루는 스피드런 모드의 업데이트를 계획하고 있습니다! 스피드런 모드 업데이트 이후는 비밀입니다..ㅎㅎ 차차 하나씩 풀어보도록 하겠습니다..ㅎㅎ

느낀 점

확실히 프로덕트 메이킹은 동기부여가 중요한 것 같습니다. ReactJS로 여러 공모전, 해커톤에 나가면서 IT 서비스를 만들 땐 유저도 없고, 피드백도 없고, 버그도 없고 계속 개발해야 할 이유가 없었습니다. 정말 수상만을 위해서 개발했던 것 같습니다. 물론 그 시간들이 의미가 없었던 건 아니었지만, 저 스스로 점점 지쳐가는 시간들이었습니다.

이번에 Drop the Ball을 만들며, 친구들과 많은 분들의 피드백과 후기들을 보면서, 할 일은 점점 쌓이고 있지만.. 개발의 즐거움을 다시 찾을 수 있었던 것 같습니다 :) 앞으로도 더 열심히 업데이트 할테니 많은 관심 부탁드립니다! 감사합니다🤣

그리고 아무도 모르게 뒤에서 도와주신 ㅎㅎㅎ @최현종

PAy IT forwaRD

PARD 1기 앱 파트장에서 2기 웹 파트장으로 돌아온 김진서입니다 :)

지난 토요일에 OT를 시작으로 본격적인 2기 활동이 시작되었는데, 새로운 2기 파디들을 만나게 되어서 너무 반갑고 즐거웠습니다!

지난 1기에도 OT 이후 내가 생각하는 협업에 대해서 메이커로그를 작성했었습니다!

지금 보면 정말 못쓴 메이커로그..ㅠ 부끄럽네요..ㅋㅋ

1기를 시작할 때는 사실 협업 경험이 많이 없었습니다. 제 1회 놀이톤, 0기 롱커톤이 전부였었고, 그마저도 협업이 무엇인가에 대해서 느낄 새도 없이 프로덕트를 개발하는 데 급급했었습니다.

PARD 1기를 거치면서, 파트장이었지만 제가 더 많이 배우고, 성장할 수 있었던 것 같습니다! 남은 건 결국 Pay it forward와 협업이었어요.

협업

제가 PARD에서 경험했던 협업은 결국 좋은 결과를 만들어 내야 한다는 것입니다. 그게 목적이고, 목표이니까요. 좋은 결과를 내지 못하고, 좋은 경험이었다로 끝났을 때, 혼자 일할 때보다 더 투자된 리소스가 굉장히 아까웠던 경험을 했습니다. 과정이 좀 좋지 않아도, 결과가 좋으면 과정이 미화되는 부분도 없지 않아 있었습니다. 그렇다고 해서 과정이 중요하지 않다는 게 아닙니다! 소통이 잘 되고, 분위기가 좋으면 능률은 확실히 좋습니다. 과정이 좋으면 결과가 좋을 확률이 높아집니다. 협업을 잘하기 위해서는 오버 커뮤니케이션이 정말 중요합니다. 내가 생각하는 것보다 약 2~3배 더 많은 소통이 필요합니다. 지금까지 내가 뭘 했고, 지금 뭘 하고 있고, 앞으로 뭘 해야 하는지는 당연히 팀원들에게 모두 공유가 되어야 하고, 팀원들이 지금까지 뭘 했고, 뭘 하고 있고, 앞으로 뭘 해야 하는지도 알고 있어야 합니다. 또한 그 일들이 모두 일정대로 진행되기 위해서는 실력도 뒷받침이 되어야 합니다.

PAY IT FORWARD

저는 혼자 성장하려 할 때보다 Pay it forward를 실천할 때, 더 많은 성장이 일어나는 것을 경험했습니다. Flutter를 혼자 배우고, 공부할 때 어려움이 많았습니다. 내가 아는 선에서만 프로젝트를 개발할 수 있었고, 일정 수준에 도달했을 때, 정체기가 왔었습니다. 그러나 파트장으로서 파디들에게 가르쳐 드리기 위해서 세미나를 준비하고, 질문에 대한 답변을 준비할 때, 더 많은 공부를 할 수 있었고, 더 큰 배움과 성장을 경험했습니다. 2기 파디분들도 혼자 1만큼 성장하려고 애쓰기보다 Pay it forward를 실천하면서 내 옆에 다른 파디들과 함께 2만큼 성장할 수 있는 여러분들이 되었으면 좋겠습니다!

OT를 진행하고 나서, 이번 2기가 정말 많이 기대되는 것 같습니다! 파디분들의 성장과 좋은 협업의 경험을 위해서 저희도 열심히 준비하고, 노력할테니 파디분들도 최선을 다해 따라와 주시면 감사드리겠습니다 :)

어떤 개발자가 되고 싶으니❓❗️

최근 책을 하나 읽게 되었습니다. 바로 박동기 저자님의 "어떤 개발자가 되고 싶니?"라는 책 입니다. 일의 본질과 취업 고민의 해결책을 알려주는 25년 차 현실판 개발자 이야기를 담고 있습니다. 이 책에서 말하고 있는 개발자로서 어떤 마인드를 가져야 하는지, 일을 할 때 어떤 개발 프로세스를 거쳐야 하는지, 어떤 것을 공부해야 하는지를 나누고, 제가 느낀 점을 나누려고 합니다!

개발자의 마인드

개발은 사람을 전제로 하여야 합니다. 개발자는 사람을 존중하는 사랑 기술 이 필요합니다. 디지털 세상에서 펼칠 이 사랑 기술 의 핵심은 아날로그 입자와 디지털 파동을 연결하는 인터페이스가 됩니다. 사랑 기술 과 함께 필요한 것은 배움 기술 입니다.

⬆️ 어떤 개발자가 되고 싶니? 중에서

개발이 사람을 전제로 하여야 한다는 점은 완전 동의합니다. 결국 서비스를 사용하는 유저는 사람이기 때문입니다. 아무리 번지르르하고 멋진 서비스를 만들더라도 사람을 존중하지 않는다면, 위대한 서비스가 될 수 없습니다.

‼️ 디지털 세상에서 펼칠 사랑 기술의 핵심이 아날로그 입자와 디지털 파동을 연결하는 인터페이스가 된다.

정말 멋진 말이라고 생각합니다. 디지털 세계에서 개발되는 우리의 서비스들은 결국 현실 세계를 사는 사람들에게 영향을 주게 됩니다. 사람을 존중하는 사랑 기술 이 베이스로서 디지털과 아날로그의 중간 다리 역할을 할 때, 비로소 그 가치가 빛을 보게 되는 것입니다.

✅ 개발자의 개발 단계는 총 3단계로 구성됩니다. 바로 설계하기 , 구현하기 , 배포와 유지보수하기 입니다.

설계하기

설계는 소프트웨어 요구 명세서(SRS) 작성으로부터 시작됩니다.

SRS (Software Requirements Specification) - 소프트웨어 요구 명세서

1. SRS 작성을 위해 먼저 어떤 부분을 소프트웨어로 개발할지 명확하게 정리할 필요가 있습니다. 소프트웨어로 개발할 필요 없이 더 잘 해결되는 문제라면 당연히 시간과 돈을 투자해서 개발할 필요가 없다는 말과 같습니다. 전체 문제 해결 과정에서 소프트웨어가 개입할 부분을 명확하게 구분지어야 합니다.
2. 그런 다음 클라이언트의 요구사항을 충분히 듣고 파악해야 합니다. 이 요구사항은 몇 번이고 번복되기 때문에 SRS 문서에 반드시 작성해야 합니다. SRS 문서는 건축의 설계 도면과 같습니다. 위의 과정을 거치며 개발 내용을 파악하고 어떻게 구현할 것인지 SRS 문서에 업데이트 해야 합니다. 번복된 요구사항 역시 반영하여 업데이트 하고 버전을 나누어 관리해야 합니다.
3. SRS 문서는 나침반과 같은 존재입니다. 이 나침반이 없으면 배가 산으로 가게 됩니다. 아무리 애자일 방식이어도 설계는 필요합니다. 설계 없이 개발하는 것은 기둥도 세우지 않고 벽돌을 쌓는 것과 같습니다. 그렇지만 SRS를 작성하느라 프로젝트 일정을 맞추지 못한다면, 작성하지 않는 것만 못합니다. 형식적으로 만들지 않는 것이 중요합니다.

장점

SRS 작성은 팀 모두가 행복해지는 길입니다. 프로젝트를 체계적으로 관리할 수 있고, 프로젝트 종결 후 유지 보수가 매우매우 쉬워집니다.

구현하기

실제 코딩에 들어가게 되면, SRS 문서에 기반하여 라이브러리, 엔진, 서버, 클라이언트, 모듈 등의 기능으로 나누어 시작하고, 일정에 맞춰 빠르게 개발하는 것이 관건입니다. 조금만 늦어도 시장에서 성공하지 못할 수도 있습니다. 그래서 소프트웨어 공학이 중요합니다.

소프트웨어 공학의 목적: 최소 비용으로 최단 기간에 개발

볼트와 너트처럼 가져다가 끼워 맞추기만 하면 되는 형태가 가장 이상적입니다. 이 말은 생산성을 항상 고민해야 한다는 것과 같습니다.

프로젝트 규모가 크고, 참여 인원이 많을수록 개발 분야를 나눠 병렬로 개발해야 속도가 빠릅니다. 병렬로 개발할 때는 컴포넌트를 잘 나누고, 인터페이스를 정교하게 정의해야 합니다. 어느 한 쪽이 이 인터페이스를 지키지 않으면 소프트웨어는 거대한 괴물이 됩니다. 그러다 결국 멈추게 되고, 신뢰를 잃게 됩니다. 한 번 신뢰를 잃은 소프트웨어는 회복이 불가능에 가깝습니다.

배포와 유지보수하기

버그를 최소화 해야 합니다. 배포를 하면 SRS 문서와 소스 코드를 버전별로 잘 관리해야 합니다. 배포를 하고 나면 유지 보수는 당연히 필수입니다. 기능 구현에 드는 수고보다 유지 보수에 드는 수고를 줄이는 것이 더 중요합니다. 유지 보수에 드는 수고는 시스템의 복잡성에 비례하므로, 개발은 단순하게 설계하고 구현하는 것이 가장 좋습니다.

개발자가 배워야 할 핵심 기술

위에서 말했던 개발자에게 필요한 2가지 기술 중 다른 하나인 배움 기술 이 필요한 시점입니다.

1. 프로그래밍 언어
2. Data Structure, Algorithms
3. Database
4. 프레임워크, 라이브러리
5. 오픈 소스 프로그램
6. OS
7. 리눅스/유닉스 명령어
8. 테스트
9. 디버깅 스킬
10. 버전 관리 시스템 VCS(Git)
11. 코딩 스타일 가이드
12. 도메인 지식

(참 많기도 하네요..ㅠ)

그래서 나는?

지금까지는 프로젝트를 하면서, 구체적인 설계 없이 개발했습니다. 프로젝트의 규모가 그리 크지 않았기도 했지만, 빨리 코딩하고 싶다는 마음이 많이 앞섰기 때문인 것 같습니다. 책에서는 이런 마음을 경계하고 잘 절제할 줄 알아야 한다고도 했습니다. 앞으로 더 큰 규모의 개발을 하게 될텐데 지금부터 잘 준비하고, 대비해야겠다는 생각이 들었습니다.

개발자는 배워야 할 게 참 많은 것 같습니다. 학교에서 배우는 것도 있지만, 학교에서 가르쳐주지 않는 것들은 실제로 프로젝트를 진행하면서 직접 부딪쳐야 배울 수 있는 것 같습니다. PARD에 들어와서 놀이톤, 0기 해커톤, 숏커톤, 새싹톤 등 여러 프로젝트를 경험했고, 그 과정에서 많이 배울 수 있었습니다. 정말 감사한 한 학기였습니다..!