11월 15일 (수료생 MeetUp, 화) - boostcampwm-2022/web33-Mildo GitHub Wiki

<김동환 연사님>

  • 기능 개발에’만’ 너무 몰두하지 말자
  • 그러면 무엇을 해야 할까? → 자기가 ‘하고 싶은 것’을 해보자!! → 완성도, 쉽고 편리한 개발, 현업에서는 어떻게 개발할까? 등등…
  • ‘성능 테스트, 무중단 배포, CI/CD 자동화’를 키워드로 진행함
  • 성능 테스트: 별도의 테스트 툴 → 완성도를 올려준다 → [https://velog.io/@znftm97/스트레스-테스트-툴로-성능-측정하기](https://velog.io/@znftm97/%EC%8A%A4%ED%8A%B8%EB%A0%88%EC%8A%A4-%ED%85%8C%EC%8A%A4%ED%8A%B8-%ED%88%B4%EB%A1%9C-%EC%84%B1%EB%8A%A5-%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0)
  • 무중단 배포: 도커 + nginx
  • CI/CD: Github Actions
  • 결과보다 값진 과정! → 스스로 많은 것들을 공부하고, 팀원들과 많은 이야기를 나눌 수 있었다. → 이것들이 나중에 큰 도움이 될 수 있다!
  • 중요한 점은 그룹프로젝트에서 얻어갈 수 있는 것이 무엇인지 곰곰이 생각해보는 것
  • 가장 중요한 것은 ‘대화’이다. → 반드시 개발하고 싶은 부분을 정하자
  • 최대한 기록을 남기고 나면 앞으로 무엇을 해야 할 지 파악하기 쉬워진다.
  • 페어프로그래밍은 생각보다 도움이 많이 된다
  • 그룹프로젝트에서 가장 중요한 것은 바로 ‘부드러운 커뮤니케이션’이다. → 그룹 프로젝트에서 신경을 써주자
  • 중요한 것: 팀원들과 놀러가세요, 잘 쉬는 것도 실력이에요

<김민지 연사님>

  • 그룹프로젝트의 실패 → 문제점이 무엇이었을까? → 서로 배려하느라 솔직하게 말하지 못함, 선택의 기로에서 ‘왜’를 생각하지 못함, 트러블슈팅 기록하지 못함, 구현에만 급급함, ‘이벤트 수집’이라는 주제를 제대로 살리지 못함
  • 괜찮지 않으면 솔직하게 말하자!, 기록하자! 많은 기능보다는 어필할 수 있는 기능이 중요하다!
  • ‘왜 이 기능을 선택했는 지’ 말할 수 있어야 한다!!
  • 기술적인 고민을 하는 것이 중요하다. → 프로젝트가 내세울 수 있는 강점을 꼭 내세워야 한다 (예시: 아키텍쳐)
  • 개발을 하는 데에 있어서 실버불렛은 존재하지 않는다. 아키텍쳐마다 각자의 장/단점이 존재한다. → 기록하고 발전시킬 수 있어야 한다!!
  • 전 기수를 너무 따라하려고 하지 말자…
  • 일단 도전해보자. 도전하지 않으면 아무것도 되지 않는다. 면접 단골 질문에 대해 “기술적으로 가장 어려웠던 점은 무엇인가?” → 기술적인 도전에 실패한다고 해도 얻는 것은 반드시 존재한다!
  • 어려우면 이것을 작은 문제로 나누어보고 차분하게 정리해보자 (예시: A 알고리즘 몰라 → 무엇을 모르는 지 아는 상태이다)
  • 공식문서 → 블로그 순으로 읽어보자
  • 기록! 기록! 기록! (부담을 가지지 말고 기록하자), 간단하게라도 기록해보면 훨씬 빠르게 성장한다
  • 칭찬을 자주 하자!
  • 그룹프로젝트 끝이라고 다 끝난 것은 아니다 → 채용 연계를 위해 준비하자 (스터디 등등..) / 위안이 될 수 있는 관계
  • 가벼운 마음으로 사이드 프로젝트 진행해보기
  • 서로 회사/기술/트렌드/기타 등등에 대해서 얘기를 해보자

<심은석 연사님>

  • 👍🏻
  • 그라운드 룰은 가꾸는 데 의미가 있다 → 그라운드 룰은 영원하지 않아요. 처음에 룰을 세웠을 때와 나중은 달라질 수 있어요. 그러나 너무 자주 변경하게 되면 너무 잦은 회의 때문에 힘들 수 있어요..
  • 히딩크 전략 → 반말, 불필요한 말 줄이기 (저는 안할래요.. )
  • 좋은 아이디어와 좋은 개발을 구분하자
  • 완벽한 계획은 존재하지 않는다.. 시간 제약을 염두해야 하고, 추가적으로 개발하고 싶은 경우에는 프로젝트가 끝난 다음에 진행해도 좋다.
  • 가장 큰 문제는 바로 개발 실력의 격차!
  • 내가 습득하지 못하고, 이해하지 못했다면 그것은 ‘무용지물’이다. → 우리의 목적은 서비스가 아닌 학습이다. 이해하지 못하는 코드는 레거시가 되고 이는 다른 팀원에게 폐가 된다 → 결과적으로 면접 때 할 말이 없어진다. → 말하는 감자가 되어버린다 🥔
  • 문서화는 선택이 아닌 필수!! 사용한 기술은 문서화하자. 특히 새로운 기술은 문서화가 꼭 필요하다! 문서화는 미루면 절대 안된다!
  • 기술 공유는 선택이 아니라 필수이다. 팀 내부에서 기술 공유 시간을 가져야 한다. 기술 공유는 개인의 성장과 프로젝트 성공을 동시에 추구할 수 있다. → 시간 내서 하자!!!
  • 경쟁이 아니라 성장! 스트레스 받지 말자!
  • 모든 것들을 알기에는 힘들기 때문에 조급하지 말았으면..
  • 지치고 힘들 때 동료가 있다는 사실을 잊지 말자!

<정현민 연사님>

  • 멘토링 잘 활용하기 → 우선 친해져라 (실제로 기업에서도 커뮤니케이션의 코스트를 줄이기 위해 팀빌딩을 진행함), 멘토의 조언을 그대로 수용하기 보다는 멘토의 말을 기반으로 나의 생각을 들여다보자. 좋은 질문을 해보자. 좋은 답변을 얻기 위해서는 좋은 질문을 해야 한다.
  • 좋은 질문 → 검색(충분히 구글링을 해보자) / 되새김(질문과 문제에 대해 충분한 배경지식을 익히자, 스스로 문제에 대해 정리하자) / 질문(이전 과정에서 정리한 내용을 기반으로 질문) / 공유
  • 정답이 있는 질문의 경우에는 ‘예/아니오’, 정답이 없으면 최적의 조건을 말할 수 있도록
  • 멘토는 그 회사에서 면접관일 가능성이 높다. 그리고 면접관이 말씀해주신 정보는 값진 정보라고 볼 수 있다. 현업의 정보를 활용해서 가고 싶은 회사 / 가치관에 맞는 회사를 결정할 수 있다.
  • 좋은 기술적 고민과 문제의 해결은 스토리와 같다! → 게시글을 보여주어야 한다 → 페이지네이션 or 무한스크롤 → RESTful API ?? 목록 가상화??
  • 줄거리를 만들게 되면 문제 해결 과정에서 학습했던 과정들을 까먹기가 힘들 것이다.
  • 노드 엣지 공부법 → 노드와 엣지를 기반으로 두 노드 간의 응집도를 높인다. → 결국 쉽게 휘발되지 않도록 한다.
⚠️ **GitHub.com Fallback** ⚠️