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기 해커톤, 숏커톤, 새싹톤 등 여러 프로젝트를 경험했고, 그 과정에서 많이 배울 수 있었습니다. 정말 감사한 한 학기였습니다..!

빠르게 실패하기..❗️

안녕하세요, PARD 1기 앱 파트장 김진서입니다!

지난 5월 19~20일 PARD의 큰 활동 중 하나인 숏커톤이 있었습니다.

먼저 우리 파도잡이들 모두모두 숏커톤 정말 고생 많으셨습니다~

저는 '7I DI 7H' 팀으로 참가하였는데, 숏커톤을 진행하면서 느꼈던 점을 좀 나눠보려고 합니다~

아이디어가 아주 중요하다!🤔

아이디어는 팀의 방향성입니다. 원점에서 어느 방향으로 갈지는 아이디에이션에서 결정되는 것 같습니다. 제 경험상.. 해커톤에서는 아이디어가 좋으면 개발이 조금 부족해도 괜찮은 결과물이 나오고, 아이디어가 별로면 개발을 잘해도 쓸만한 결과물이 나오지 않는 것 같습니다.

저희 팀의 경우.. 아이디어가 살짝 부족하지 않았나 싶습니다..ㅎㅎ 최근 유행하는 거지방을 모티브로 "거지촌"을 구상하였지만, 시간에 쫓기다보니 아이디어의 당위성을 확보하는 데에 실패했던 것 같습니다.

소통을 할 때는 납득할 수 있게...🤝

팀원과 의사소통 시에는 왜 그렇게 해야 하고, 왜 그렇게 하지 말아야 하는지를 명확하게 전달해야 합니다. 짧은 해커톤 기간동안 최선의 선택을 하기 위해서는 나의 의사결정을 팀원에게 이해시킬 필요가 있습니다. 내 의견을 강요하는 게 아니라 팩트와 현재 상황에 기반해서, "이러이러한 상황이라 이러이러한 이유로 이렇게 해야 할 것 같습니다. 혹은 이렇게 하면 안될 것 같습니다. 대신 이렇게 하는 건 안될까요?"라는 태도를 가져야 합니다.

개인적으로 이번 숏커톤에서 저 스스로 이 태도가 매우매우 부족했던 것 같습니다. 시간에 쫓겨 정신없이 개발하는 와중에 기획자, 디자이너님께 안된다고만 했지, "왜 안되는지, 다른 대안을 제시"하지도 못했습니다. 리드 개발자로서 많이 부족했던 것 같습니다ㅠ

손이 빨라야 한다.🙌

짧은 해커톤 기간 내에 완성하려면 당연히 손이 빨라야 합니다. 결국 보여지는 것은 생각이 아닌 결과물이기 때문에 생각을 빠르게 구현해 내야 합니다. 당연하죠..?ㅋㅋ

저는 평소에 머리로 생각해놓은 구조와 설계들을 느긋하게 개발하는 스타일이라, 손이 생각을 잘 따라가지 못합니다. 그러다보니 이번 숏커톤에서도 그 문제가 여실히 드러났는데.. 머리로는 이미 완성된 코드 구조를 손으로 타이핑 하는 속도가 따라가지 못하다보니.. 마음이 굉장히 급해지면서 멘탈이 많이 흔들렸던 것 같습니다. 이 때문에 위의 소통 과정에서도 영향을 주었던 것 같습니다..ㅠ 스스로 많은 부족함을 느끼고 있어요..

결국은 시간.. 시간..! 시간!!!⏳

해커톤의 핵심은 시간 관리인 것 같습니다. 위의 모든 문제가 결국 근본적으로 시간에 쫓겼기 때문입니다..ㅠ 사실 저는 매우 느긋한 성격이어서.. 이런 초단기 스프린트가 너무 어려운 거 같아요.. PARD의 헤더이지만, 동시에 숏커톤의 참가자로서 빠르게 실패하기는 제가 경험한 것 같습니다..ㅎㅎ

빠르게 실패하기.. 저의 PARD 1기 숏커톤을 가장 잘 표현하는 말이었습니다..

끝을 향해 달려가는 AI 스터디🔥

안녕하세요! PARD 1기 앱 파트장 김진서입니다.

PARD의 AI 스터디가 4번 진행되었고, 이제 마지막 1번을 남겨두고 있습니다!

저는 랩 설명회 때문에 마지막 스터디에는 참여하지 못하지만..

그동안 스터디원 모두 고생하셨고, 마무리까지 파이팅입니다~

4주차 스터디에서는 다음의 주제로 진행되었습니다.

AI그림 만들기 WebUI

먼저 성찬님의 주제였던 AI그림 만들기 WebUI는 Stable Diffusion WebUI를 이용하여 이미지를 생성해보는 것이었습니다.

다음의 과정으로 진행되었습니다!

1. 필요한 파일 다운 받기 - CheckPoint, Lora, VAE, Negative Prompt
2. Colab에 Stable Diffusion WebUI 설치
3. 1번에서 다운 받은 4개 모델 구글 드라이브에 업로드

⬆️ 약 4.23GB의 파일을 30분간 업로드 했지만.. 용량 부족.. 내 30분..

• 결국 용량이 폭발한 학교 계정을 두고,, 제 개인 계정으로 전환하여 다시 시도하였습니다.

⬆️ 이 빌드도 15분 걸림...

• 그런데.. 계속 빌드가 되지 않고 404, 504 등 HTTP 에러가 발생하면서 Colab의 런타임이 끊어졌습니다..
• 한 20번 정도 테스트한 결과 런타임이 끊어지기 전에 URL로 접속하여 런타임이 끊어지기 전까지는 이용이 가능한 듯합니다..
• 결국 다른 방법을 찾지 못하고 런타임이 끊어지기 전까지 타임어택을 했습니다..ㅋㅋㅋ

4. WebUI에서 설정

⬆️ Checkpoint, Lora, VAE, Negative prompt까지 모두 설정

• Prompt를 입력한 후 결과 화면
• 문법을 몰라서 그냥 성찬님이 쓰신 Prompt를 그대로 가져다가 사용했습니다.

5. ChatGPT AIRPM -> Prompt 짜는 걸 도와주는 Chrome Extension

6. 완성

• 상당한 퀄리티를 보여주었습니다.
• 계속 빌드에 실패해서 코드를 돌리는 데이만 5시간은 넘게 걸린 것 같습니다..
• Prompt를 어떻게 작성하느냐에 따라 결과가 천차만별입니다. 제대로 사용하려면 문법도 공부를 해야할 것 같습니다.

잘되고 있는 ‘api 복면가왕’ 들의 이모저모 살펴보기

다음은 정훈님의 주제입니다!

1. 구글 IO에서 Bard를 선보였다. (PARD와 이름이 비슷하다.)
2. OpenAI의 ChatGPT에 대항하기 위한 구글의 공격적 조치
3. 현업에서 적용될 수 있는 코딩 실력은 아직 ChatGPT의 압승..
4. PaLM2 모델
5. 폰지사기와 스타트업 → 영업이익이 잘나오는 것처럼 홍보를 하고 이익분배도 잘 해주는데, 실제론 그 배당이 사업을 잘해서가 아니라 후속투자자의 투자금으로 돌려막기 하는 것을 폰지사기라 한다. 실제 그 회사의 최대 상품은 "사업"이 아니라 "지분"이고, "매출"이 아니라 "후속투자" / 스타트업을 폰지사기라고까지 말하고 싶진 않지만, 고객에게 제대로 된 돈을 받지않고 무료서비스 등을 통해 성장하는 것, 이렇게 "잘되는 것"을 홍보하며 비싼 후속투자금을 끌어오는 것, 그리고 이러한 사이클을 반복하며 외형을 키우고 결국 상장을 통해 개미들이 받아주길 바라는 것만 꿈꾸는 곳들은 모두 본질을 피한 돈놀이
6. 구글과 OpenAI를 오픈소스가 빠른 속도로 따라오고 있다.
7. 하면 할수록 어려운게 콘텐츠 비즈니스인듯. ChatGPT로 인해서인지 광고성 콘텐츠들의 범람 때문인지는 몰라도 이제는 콘텐츠 전반이 공해처럼 느껴짐.
8. CNN을 실시간으로 시각화하는 코드 → https://github.com/okdalto/CNN-visualization/blob/main...

<요약>

1. 진짜는 모두가 알아본다
2. 생각보다 인문학적 소양이 중요하다, 사는 대로 생각하지 말고 생각하는 대로 사는 사람이 되길 🙂
3. 결국은 도메인 지식이다

-> 현재 다방면의 AI 시장이 어떻게 굴러가고 있는지 알 수 있었습니다..! 좀 더 다양한 관점으로 바라볼 수 있었고, 내가 생각하지 못한 관점도 알 수 있었습니다. CNN을 실시간으로 시각화하는 건.. Processing으로 만들었다는데,, 진짜 대단한 것 같습니다.. Processing.. 엄청난 노가다 코딩 툴인데.. 와우😲

AI 언어모델과 인간의 뇌, 교육 혁신

마지막은 현서님의 주제입니다~

<하이라이트>

• 결국 언어는 뇌와 뇌의 연결을 위한 일종의 코드!
• 마음이 잘 통하면 감정 상태와 그림을 나도 똑같이 떠올릴 수 있다.
• AI에게 위임할 때 편할 수 있지만 의존하면 사고의 다양성이 줄어들고 인류의 성장이 더뎌질 것

1. 인공지능을 우리는 개체로 생각하지만, 그게 아니라 네트워크이다.
2. 인간대 인공지능이 아니라, 인류대 인공지능으로 비교를 해야 한다.
3. 인류의 뇌는 구석기 시대와 현재가 같지만, 서로 다른 인간의 뇌가 연결되면서 문명이 발전했다.
4. 딥러닝이 뇌를 어느 정도 본떴는가? - 그것은 비유일 뿐이지 실제로 맞는 말은 아니다
5. 근본적인 차이 : 뇌는 전기신호로만 설명되는 것들이 아니라, 유전적/생화학적 메커니즘이 많아서, 인공지능 신경망에는 그러한 것들이 완전히 들어가지 못했고 인공신경망은 뇌구조에서 착안했지만 뇌와 별개로 발전
6. AI중에 가장 (인간처럼 자연어를 구사하기에) 인간에 가장 가깝다고 느껴지는, 생성 AI : 언어는 우리가 할 수 있는 기억의 한계 → 기억에 남는 시기는 언어를 사용할 줄 알던 시기

챗gpt는 교육혁신의 기회

<하이라이트>

• 위조지폐가 도는 것보다 위험한 일 : 가짜인간, 가짜정보 주입/세뇌/가스라이팅 들이 일어나게 된다면 위험

1. 교육의 목표를 어떻게 설정하느냐에 따라 챗GPT가 도움이 될 수도, 해가 될 수도 있다.
2. AI와 같은 신기술의 본질은 : ‘잘 활용해서 “일상”의 문제를 해결하는 것’이다.
3. 얼마만큼 구체적으로 나의 질문과 요구사항을 표현할 수 있는지에 따라 결과물이 달라지는 생성 AI
4. 뇌가 가장 효율적으로 학습할 수 있는 방식으로 교육 시스템을 바뀌어야 하지 않을까? - 누군가는 잘 활용하는 방법, 누군가는 단점을 찾아내는 방식으로 수업 코스를 해보고 계심
5. 챗gpt , 잘 활용하는 방법은? - 우리가 가진 가능성은, 우리가 가진 도구에 의해 결정된다.
6. AI가 인간은 아니지만 나에게 있어서 인간처럼 느껴져요. 그러면 이 존재와의 인터렉션이 나라는 존재를 어떻게 바꿔 나갈 것인가? 나에게 주는 영향력에 대해 고민해봐야 하지 않을까?

-> 지난주에 제가 가졌던 의문에 대한 답이 바로 “근본적인 차이 : 뇌는 전기신호로만 설명되는 것들이 아니라, 유전적/생화학적 메커니즘이 많아서, 인공지능 신경망에는 그러한 것들이 완전히 들어가지 못했고 인공신경망은 뇌구조에서 착안했지만 뇌와 별개로 발전”인 것 같습니다. 인공신경망에 뇌구조가 완벽 모방된 것이 아니기 때문에 아무리 뉴런 수가 사람보다 많아도, 사람보다 뛰어날 수 없는 것 같습니다. 얼마만큼 구체적으로 나의 질문과 요구사항을 표현할 수 있는지에 따라 결과물이 달라지는 생성 AI → 위의 성찬님 주제를 실제로 해보면서 느낀 점입니다..ㅎㅎ

감사합니다!

PARD AI 스터디 회고!🤖

2차로 진행된 인공지능 스터디! 1차 보다 한 주제에 대해서 더 깊고, 심도 있는 이야기를 나눌 수 있었던 것 같습니다!

1. Hyper-Scale Model Inference의 최적화 문제
2. 정보기하학
3. 테슬라의 미래전략과 NPU

위의 3가지 주제로 약 1시간 20분의 스터디가 진행되었습니다~🔥

⬆️ 노션에 아카이빙된 이번 주 주제들

내용 요약과 느낀 점

✅ 초대형 추론 모델의 최적화 문제

<내용>

1. LLM Inference는 비싸고 비효율적입니다. 하지만 그것을 감수할 수 있는 근거가 있으며, 현실화된 몇 안되는 AI 모델입니다.
2. LLM Inference를 위한 최선의 방법은 HBM(고대역 메모리) 등을 장착한 A100/H100입니다. 하지만 Scale-Up이 힘듭니다. (HBM 수급, Power, 가격, 수요,…)
3. 이를 해결할 유일한 출구는 모델 압축 기술이고, Quantization / Pruning 등이 많이 연고 되고 있습니다.
4. AI 언어 모델, 경량화 기법, 시스템 소프트웨어 최적화, GPU, 하드웨어 구현, 등등

➡️ 성찬님께서 나눠주신 생각들에서 "Fine-tuning을 잘하는 게 중요한건가?", "굳이 큰 모델을 만들어야 하는가?"라는 질문을 들었을 때, "정말 모델의 size만 커지면 높은 지능 수준을 만들어 낼 수 있을까?"라는 생각이 들었습니다. GPT-3 모델의 parameter 수가 175B. 즉, 약 1750억 개인데, 사람 한 명의 뉴런 수는 일반적으로 1000억 개라고 합니다. GPT-3의 size가 사람보다 더 큰데, 여전히 인간의 지능을 넘지 못했기 때문입니다.

✅ 정보기하 소개

<내용>

1. 머신러닝은 어떻게 동작할까요? 데이터와 모델이 필요합니다!
2. 데이터는 어떻게 만들 수 있나요? 세상의 다양한 데이터 형태를 컴퓨터가 이해할 수 있는 언어로 표현해 냅니다!
3. 모델은 어떻게 만들 수 있나요? 모델을 구성하고 있는 것은 코드들이고, 코드를 구성하고 있는 것은 수식들입니다.
4. 수식은 무엇을 의미하나요? 수식은 저마다의 철학을 담고 있고, 그 철학들은 어떠한 상황 속에서 어떠한 행위를 해내고 싶은 인간의 욕망이 투영된 것입니다.
5. 인공지능 연구자는 어떠한 일을 통해 가치를 창출해내나요? 인공지능 연구자는 기존의 수식들에 담긴 욕망들을 이해하고, 그것을 읽고 활용하는 문해력을 키운 뒤, 관심있는 분야의 문제를 해결하는데 도구로서 인공지능을 사용합니다!

➡️ 딥러닝의 한 신경, parameter는 하나의 수식으로 이루어져 있기 때문에 결국 그 수식 내에 국한될 수 밖에 없다는 것이 인상적이었습니다. 이 부분 때문에 딥러닝이 아직 인간의 지능을 넘지 못하고 있는 것의 원인 중 하나라는 생각이 들었습니다.

✅ 테슬라의 미래전략과 NPU

<내용>

1. Tesla의 Vision : 지속 가능한 에너지로의 전환을 통한 친환경 에너지 사회
2. 화석 연료 대신 재생에너지로 전기를 만들고 저장하고 유통하겠다
3. 전기 자동차를 파는 에너지 회사
4. 사람들이 태양 에너지를 발전, 사용, 저장, 거래하는 길목을 차지하겠다
5. NPU : AI 가속기, AI 반도체라고 부르며, AI 알고리즘 특유의 패턴에 특화된 반도체
6. AI가 Training에서 Inference(추론)의 단계로 넘어갈 때, 많은 양의 전력량이 필요하므로, 비용을 줄이기 위해 NPU가 필요

➡️ GPU와 NPU의 사이에서 적절한 합의점을 찾을 필요가 있을 것 같다는 생각이 들었습니다! 범용성만을 추구하면 전력 문제와 더불어 전성비의 손실이 크고, 특화성만을 추구한다면 호환성의 문제가 생길 것이기 때문에 결국 중간 지점에서 어느 한 쪽에 치우치지 않는 구현과 제작이 필요할 것 같다는 생각이 들었습니다! 또 결국 그런 Unit이 살아 남을 수 있을 것 같습니다. 감사합니다 :)

Flutter 마스터를 향해 🌊

1차 세미나 회고 글을 올리고, 굉장히 오랜만에 글을 다시 쓰게 된 것 같습니다. 그동안 더 많이 글을 썼어야 했었는데, 능력부족으로 인한 한계...ㅠㅠ 그래서 세미나가 끝난 지금에서야 다시 글을 쓰고 있습니다.

세미나를 준비하면서

스스로 많은 부족함과 아쉬움을 많이 느꼈던 것 같습니다. Flutter를 1년 넘게 공부했지만, 아직도 잘 모르는 것들이 많았고, 버전이 업데이트 됨에 따라 새로 공부해야할 것들이 넘쳐났습니다. 그럼에도 불구하고 더 노력하게 되었던 것은 PARD의 핵심가치인 "PAY IT FORWARD"가 항상 마음 속에 있었기 때문인 것 같습니다. 그리고 저에게 세미나에만 집중할 수 있는 환경을 만들어 주기 위해 다른 일들을 모두 맡아준 정규 파트장에게 심심한 감사와 박수를.. 정말 열심히 준비했고, 다시 보고, 생각하고 수정하는 과정이었습니다.

⬆️ 치열한 고민의 흔적들..

그리고 이 고민들은..

어떻게 하면 Flutter를 더 쉽게 배울 수 있을까? 어떻게 하면 손실없이 100% 학습 효과를 낼 수 있을까? 어떻게 해야 지루하지 않고 재밌게 진행할 수 있을까? 어떤 피드백을 어떻게 반영해야 할까? 이렇게도 해보고 저렇게도 해봤는데 어떤 방식이 더 적합할까? 어떻게 말하고, 어떤 예시를 들어야 효과적으로 전달이 될까? 또 내가 했던 삽질들은 어떤 식으로 알려주는 게 좋을까? PPT 자료 구성은 어떻게 해야 하고, 텍스트와 이미지, 컨텐츠의 순서와 실습의 비율 등등등... 이 모든 것들은 어떻게 배치해야 가장 효율적일까? ... 의 무한 반복이었습니다.

⬆️ 그리고 최종 결과물.. (이것들을 보고 있으면 뿌듯해짐..ㅎㅎ)

이런 과정 속에서

배운 점들도 정말 많았습니다. 사실 Flutter를 처음 배울 때보다 PARD 세미나를 위한 공부를 하면서 더 많은 공부를 했고, 더 많이 배울 수 있었습니다. 단순히 사용하기 위해 배우는 것과 남들에게 설명하기 위해 배우는 것의 깊이는 엄청난 차이라는 것을 느꼈습니다. 앱 파트의 세미나는 처음 기획하고 생각했던 방향에서 세미나를 거듭하고 피드백을 수용하면서 크게 달라졌습니다. 그리고 이것은 한번 경험해 본 것과 아예 처음 해 보는 것의 깊이와 농도의 엄청난 차이를 보여준 것 같았습니다. 저 스스로나 파디분들 모두 큰 성장을 이룰 수 있었던 경험과 시간이었던 것 같습니다. 이런 고민과 노력이 잘 전달되었기를 바랍니다..ㅎㅎ

지금까지는

저희 헤더들이 열심히 이끌어왔지만, 앞으로의 PARD 활동은 파디 여러분들 한 분 한 분이 이끌어 가면서, 함께 만들어 가는 1기가 되었으면 좋겠습니다! 지금까지 정말 수고 많으셨고, 또 이번 주에 있을 기디개 연합 세미나를 시작으로 숏커톤과 롱커톤도 잘 참여해주시면 더욱 좋을 것 같습니다!ㅎㅎ 롱커톤 아이디어도 많이많이 내 주세요~! 감사합니다 :)

1차 세미나...

OT를 지나 정식으로 세미나가 시작되었습니다!

역시 파디님들 앞에 서는 것은 쉽지 않았습니다..

일단 후반부에 루즈해졌던 세미나를 묵묵히 들어주신 저희 앱 파디님들께 심심한 사과의 말씀과 감사의 말씀을 전해드립니다..

준비를 한다고 했으나 이것도 알려드리고 싶고, 저것도 알려드리고 싶은 마음이 과하게 앞서서 내용만 너무 비대해져 버린 세미나가 되었습니다. 세미나를 진행하면서도 저 스스로 지루하게 느껴졌는데, 파디님들은 얼마나 힘드셨을까요..ㅋㅋㅋ

이렇게 한 가지를 배웠고, 이를 반복하지 않기 위해 파디님들의 피드백을 적극 반영한 세미나로 개편하고 준비하고 있습니다! 지루한 정보 전달 내용은 줄이고, 세미나 주제와 내용에 대해 깊게 생각해 볼 수 있는 시간, 직접 체험해 볼 수 있는 시간을 더 늘리기 위해 노력하고 있습니다!

그럼에도 불구하고 아직 부족한 부분이 보이실 수도 있습니다..ㅎㅎ 그런 부분이 있다면 너그러운 양해를 부탁드리고,, 가감 없는 솔직한 피드백을 언제든지 주시면 감사드리겠습니다! 저는 파디님들의 의견을 agile하게 받아들일 준비가 되어 있어요! 부담 없이 피드백과 의견, 질문을 나눌 수 있는 앱 파트, PARD가 되었으면 좋겠습니다! 파도와 파디가 함께 만들어 가는 PARD 1기이니까요 ㅎㅎ

다시 한 번 죄송하다는 말씀과 감사하다는 말씀을 드립니다.. 더 성장하고, 발전된 앱 파트장이 되겠습니다 ㅎㅎㅎ

PARD를 시작하면서

안녕하세요, PARD 1기 앱 파트장 김진서입니다!

OT 회고

어제 PARD 1기의 공식적인 활동이 시작되었습니다. 앱 파트장으로서 OT를 준비하고, 진행하면서 기대와 설렘 반, 걱정 반이었던 것 같습니다. 파트원 분들을 만난다는 기대와 PARD의 첫 출발이라는 설렘, 그리고 '파트원들 앞에서 잘 말할 수 있을까?'라는 걱정이었습니다. 주목 공포증이 있는 저로서는 파트원들 앞에 서는 것부터가 큰 도전이기 때문입니다. 그렇지만 최근 제가 깨달은 것은 먼저 걱정하기보다 일단 부딪쳐보기, 도전하기 입니다. 그리고 실천하기 위해 노력하고 있습니다. 아직 부족하지만, 더 열심히 준비하고 노력해서 완벽히 극복해낼 겁니다! 어제 정식으로 파트원 분들과 만났고, 인사를 나눴습니다. 정말 좋은 파트원들을 만나 앞으로 1기의 활동이 더 기대되고, 기다려지는 것 같습니다! :)

협업?

제가 생각하는 협업 은 한 마디로 정의하자면 경험치를 쌓는 것 입니다. 구체적으로 소통의 경험치를 쌓는 것과 개인 역량의 경험치를 쌓는 것으로 나눌 수 있을 것 같습니다. 협업을 잘한다 라는 것은 목표한 것을 얼마나 이뤄냈는가? 가 결정한다고 생각하는데, 공동의 목표와 개인적 목표로 나눌 수 있을 것 같습니다. 제 기준에서! 공동의 목표는 소통의 성장인데, 소통이라는 것은 혼자 하는 것이 아니기 때문입니다. 그리고 개인적 목표는 역량의 성장입니다. 소통이 잘 이루어지고, 팀 구성원의 좋은 실력이 있다면 좋은 결과는 자연스럽게 따라오게 될 겁니다!