모두의 TOY RPROJECT : SIDE PROJECT 어디까지 가봤니? 방문 후기

슬기로운 인턴생활을 방문한지 며칠 지나지 않고 두 번째로 구글 스타트업 캠퍼스를 방문하게 되었습니다!

GDG Seoul에서 주최한 [ 모두의 TOY RPROJECT : SIDE PROJECT 어디까지 가봤니? ] 였습니다 :)

총 8개의 세션이 세션마다 20-30분씩 진행되었습니다.

중간중간 밖으로 나와서 모든 세션을 듣지 못해서 들은 세션만 내용을 공유하려고 합니다.

발표 중간중간에 필요하다고 생각한 내용만 적었습니다. 중간중간 소제목이 기억나지 않아 임의로 붙인 제목도 있습니다.

최고의 이벤트 플렛폼을 향하여, and beyond / 진겸님(Festa!)

 

Festa! 바로가기

Festa!의 탄생과 과정

1. Festa!의 탄생
   • GDG에서 웹 스터디를 마치고 다시 모임
   • 컨퍼런스를 모아두고 간편하게 결제할 수 있는 통합 시스템이 없음
     • 컨퍼런스계의 Jira를 만들자고 생각
   • 회사에서 써보지 못한 기술을 사용해보고 싶었음
2. Festa!를 만드는 과정
   • 결제 시스템은 돈이 오가는 문제이기 때문에 만드는 과정이 굉장히 까다로웠음
     • 아임포트를 사용해서 아임포트가 사업자를 대주고 수수료를 떼어감
   • EDD (이벤트 데드라인에 맞추어 개발하는 것)를 하게 됨
   • 처음에는 정말 재미있었음
     • 의미도 있었고, 회사와 달랐음(이해관계, 주도권이 필요없이 '내 의지'로 가능
     • 일정보다 빨리 진행되고 있다고 생각
   • 데드라인이 다가오자 너무 힘들었음
     • 생각보다 구현하지 못한 기술이나 쌓인 이슈 처리를 하지 못했음
   • 오픈을 했음. 결제가 성공했다는 스샷도 있었지만 오류가 난 스샷도 올라옴
3. 회고와 느낀점
   • 기술적 인사이트
     • 라이브러리, 프레임워크는 미리 정해두는 게 좋음
   • 스스로의 부족함을 느끼게 됨
   • 협업의 어려움에 대해 알게 됨
   • 지킬 수밖에 없는 데드라인 = 발전

새로운 본격적인 시작. 그리고 새로운 문제점들 …

1. Festa 재시작

• Festa!가 일회성이 아니게 됨 → 같이 할 사람을 모음
• 처음부터 다시 만듦
• MVP(언제까지 이걸 만들어야겠다고 목표 설정)이 정말 중요
• 이번에는 역할, 협업 툴도 제대로 정함

1. 현실적인 문제들을 마주치다

• 사업자 문제, 보증보험, 기초 자본금
• 프로젝트 매니징의 어려움(끊임없는 팀플)
• 각종 슬럼프와 빠른 번아웃
• 계속되는 EDD
• 사이드 프로젝트의 한계(인력/시간 부족)

1. 한계 해결법 찾기

• 프로젝트 축소
• 시간을 배로 쏟기 → BUT 이렇게 하면 사이드 프로젝트가 아니게 될 수도 …
  • 가볍게 시작한 프로젝트는 가볍게 끝날 수밖에 없음
  • 개발과 서비스는 다름

The Next Step

• 그래도 Festa는 이벤트를 관리하는 최고의 사이트!
• 지금은 규모 키우기에 집중 중

---

기술에 공유를 더하다 / 권태관님(Daily Dev Blog)

 

Daily Dev Blog 바로가기

사이드 프로젝트?

1. 사이드 프로젝트는

• 회사에서 하는 업무와 별도로 진행
• 개인 또는 팀으로 구성
• 주제, 목표, 일정에 제한이 없음

1. 사이드 프로젝트를 하는 이유

• 내가 필요하기 때문에
• 번뜩이는 아이디어가 있어서
• 새로운 지식을 습득하기 위해서

1. Daily Dev Blog를 만든 이유

• SNS 챙겨보기 힘들어서 + 중간에 딴짓해서
• 중요한 정보, 좋은 글들을 놓쳐서
• 다른 사람의 글들을 보며 자극받고 싶어서
• 블로그 홍보를 하고 싶어서
• RSS 리더 서비스 만들어보고 싶어서

Daily Dev Blog

• 서비스 소개
  • 매일 오전 10시에 어제 등록된 개발 관련 글을 모아서 메일로 보내주는 서비스
• 개발 언어
  • Flask + Python
  • AWS

개발 과정 중 겪었던 문제점

• 너무 느린 메일링
  • 크롤링을 미리 함
  • 스레드와 풀을 사용함
  • 최소한의 인프라로 최대한의 성능을 내고 싶어 여러 방법을 찾음
• 메일 본문에는 CSS, JS가 적용되지 않음
• 구글 SMTP는 하루에 500개만 적용 가능
  • SES를 사용함
• 필터링, 카테고라이징 …

개발하며 느낀점

• 강제 학습을 하게 됨
• 서비스에 대한 책임감을 느끼게 됨
• 경험으로부터 나온 인사이트를 팀에서도 적용할 수 있게 됨

---

전직 리눅스 오타쿠의 사이드 프로젝트 삽질기 / 권순선님(KLDP)

 

KLDP 바로가기

KLDP?

• /. + sf.net 또는 ~ SO + Github + Wikipedia
• 계기
  • 리눅스에 관심을 가지게 됨
• 발전과정
  • 디자인과 기능이 점점 달라지고 추가됨

회고

• 행운이 조금 있었다고 생각
  • 리눅스와 델파이 중 고민하다 리눅스를 팜
• Developer Relatoins를 사이드 프로젝트로 경험함
• 열심히 해야 함
  • 4 * 365 * 8 - 4 * 30 * 2 = 11440시간동안 작업
  • 열약한 환경에서 작업
• 이것저것 하다 보면 문제가 생김
  • 삽질을 하면 됨

---

'비처럼 강물처럼(Backend.AI)'은 듣긴 했으나 딥 러닝에 대한 지식이 없어서 제대로 정리하지 못했습니다. ㅠ_ㅠ

• 투자를 받기 전에는 눈에 보이는 확실한 것을 만드는 게 좋음
• 현재의 행동은 미래의 나에게 영향을 미침
• 만드는 시간만큼 사용하는 사람을 만나보는 게 좋음
• 시작한 후에 끝날 걱정을 미리 하는 것은 좋지 않음

---

눈누의 노란 사춘기는 듣지 못했습니다… ㅠㅠ

---

지속 가능한 사이드 프로젝트를 위한 시행착오 / 옥찬호님(RosettaStone)

 

RosettaStone 바로가기 (Github)

RosettaStone?

• 하스스톤 시뮬레이션

새로운 팀원을 맞이하기

• 새로운 팀원은 구조를 이해하는 데 어려움을 겪음
  • 문서화 굉장히 중요함
  • 이해할 수 있고 기여할 수 있도록 도와줘야 함
    • 튜토리얼, 예제 코드, API 문서화, 프로젝트 기여 방법

동상이몽

• 프로젝트를 더 좋게 만들고 싶어 하는 마음은 같지만 '어떻게?'는 다를 수 있음
  • 얘기를 많이 해봐야 함
  • 진행 상황 공유, 오프라인 미팅

프로젝트 관리의 기준선

• 프로젝트 관리에 최선을 다해야 함
• 판단 근거를 세워놓는 것이 좋음
  • 프로젝트가 잘 빌드 되는가?
  • 꾸준한 커밋을 하는가?
  • 코드 스타일링의 일관성이 있는가?
  • 코드 품질은 잘 관리되고 있는가?
  • 사용 문서가 있는가?
• 방침을 정하는 것도 좋은 방법

---

경쟁이 아닌 상생의 사회를 꿈꾸며 / 김승일님 (모두의 연구소)

 

모두의 연구소 바로가기

모두의 연구소?

• 연구를 만들고, 참여할 수 있음

만들게 된 계기

• 드론을 샀는데 조립 설명서가 없었음
  • 겨우겨우 외국 사이트에서 설명서를 찾음
  • 이걸로 블로그 글도 쓰고, 책도 쓰고, 쇼핑몰도 만들어봄!
  • 결과가 좋음
    • 자기가 하고 싶은 연구를 할 수 있는 연구소를 차리자고 생각하게 됨
• 처음에는 반대가 많았지만 와이프는 허락
• 첫 시작은 공간 대여점
  • 3개의 팀으로 구성
  • (첫 번째 시련) 그러다 쫓겨남
• D. Camp에게 장소 대여받음
  • (두 번째 시련) 하고 싶지만 하는 법을 모르는 사람들이 많아짐
    • 서로 지식 공유를 하기로 함
    • 그러다 이타적인 사람들이 모임
  • (세 번째 시련) 연구보다는 스터디 모임 위주로 …
    • 스터디를 전문으로 하는 풀잎 스쿨을 만듦
• 지금은 50개의 연구모임, 400명의 연구원

---

Service as a Side project / 김석준님(짤봇, QWER.GG)

 

QWER.GG 바로가기

짤봇?

1. 계기

• 매우 많은 사이드 프로젝트 경험이 있음
  • 앱 열풍과 함께 스타트업에 뛰어들게 됨 → 망함
  • 내가 좋아하고 필요한걸 개발하자!

1. 사용 방법

• /짤 - 기본 기능
• /짤추가 - 팀에서만 쓰고 싶은 게 있을 때
• /짤봇 - 도움말

1. 만드는 과정

• 설계 과정을 생각하지 않고 일단 구현을 목표로 (그래도 나름 MSA)
• 빌드 자동화를 하고 싶음 → 젠킨스 사용
• 사양이 낮으면 느리고 계속 켜놓으면 돈 나감 → 고사양으로 쓸 때만 켜놓음
• 설치, 세팅이 귀찮음 → Bitnami로 자동 설치

QWER.GG?

1. 계기

• 기존 롤 프로 리그 일정 사이트가 이상했음
  • 내가 만들어야지!

1. 만드는 과정

• 기능
  • 일정, 경기 시작할 때 알림, 라이브 볼 수 있게
• 어떻게 구현?
  • 크롤링을 사용
  • 열나는 노력으로 소스 확보

1. 구현 후

• 홍보
  • 인벤에 지인이 공유해줌
  • 유튜브로 해설자(빛돌)에게 연락을 함
  • 여기저기서 연락이 옴
• 이제 뭐하지?
  • 여기 저기서 피드백과 기능 추가 제안
• 운영 테스트할 사람이 없으니 데이터라도 쌓자고 결심함 - sentry, ga
• log를 slack에 쌓아둠

꿀팁

• 가급적이면 CI/CD하기
• 디자인은 필수
• 내가 좋아하는 주제로 선택하기
  • 가능하면 크롤링이 가능한 주제가 좋음
• 동료는 내가 필요한 걸 채워줄 수 있는 사람으로
• 느슨하게 오래가는 팀이 좋은 것(같음)
• 부트업 시간이 짧은 기술 선택하는게 좋음
• 피쳐 개발이 쉬운 기술을 선택하는게 좋음
• 단순한 구조를 최대한 유지하는게 좋음

---

후기

정말 유명한 사이드 프로젝트들이 탄생하는 과정과 그 과정에서 겪은 문제들을 생생하게 들을 수 있어서 좋았고, 많은 자극을 받은 것 같다.

GDG에서 주최하는 행사는 처음인데, 기회가 된다면 앞으로 많이 가고 싶다.