Skip to content

1주차 멘토링

JIN edited this page Nov 3, 2024 · 1 revision

✔️ 결론 및 To Do

멘토링 이후 결론과 챙길 것을 정리하여 업데이트합니다.

  • [ ]
  • [ ]
  • [ ]
  • [ ]
  • [ ]

✔️ 멘토링 아젠다

멘토링 24시간 전에 준비하여 멘토에게 공유합니다.

논의 사항 및 질문

  • eslint로 코드 스타일을 다 같이 통일 하려고 하는데 ‘이런건 이야기 해보면 좋을 것 같다’ 하는 팁이 있을까요?
  • 기획이 어떤지 바로가기
    • 게임처럼 하기 위해서 아이템 관련 기능을 추가하고 친구와의 대결 기능을 추가해보았는데 이외에도 추가해보면 좋을 기능이 있을까요?
  • 소프트웨어 아키텍쳐 디자인 괜찮은가요? 바로가기
  • 기술적 목표를 세워봤는데 추가적으로 시도해보면 좋을 기술적 목표가 있을까요? 바로가기
  • 현재 사용하는 devOps(slack, git, github action ) 이외에 사용해보면 좋을 devOps 추천해주실 수 있을까요? 바로가기
  • 프로덕트 백로그 바로가기
    • 지금 봐도 다 못할 것 같은데 안될 것 같은 기능은 지금부터 확실히 없애고 될 것 같은 기능만 남겨놔야 할까요?
  • 소켓 통신할 때 주의해야할 부분이 있을까요?
  • 피그마 디자인은 어떻게 진행하셨었나요?
  • 프론트엔드 테스트코드에 대해 어떻게 생각하시나요?
  • tdd에 대해 어떻게 생각하시나요?
    • 굳이 tdd를 하지 않고 꾸준한 테스트 코드 작성만 해도 괜찮을지 궁금합니다.
  • TS 처음 써봐서 걱정이 되는데 학습 팁이나 좋은 자료가 있을까요?
  • 주식 차트를 그리는데 chart.js 라는 도구가 있는데 이런 도구를 사용하는게 좋을지 직접 구현하는 방식이 좋을지 고민됩니다.
  • 주식 테이블이 주가 변화할 때마다 업데이트 되기 때문에 관리할 때 어려움이 있을 것 같은데, 대용량 데이터 관리에 있어서 팁이 있을까요?
  • DB 설계와 관련해서…
    • 사용하게 된다면… Redis는 어떤 상황에서 사용하는 것이 좋을까요?

진행상황 및 참고 자료

✔️ 멘토링 내용

멘토링을 진행하며 나눈 이야기가 휘발되지 않게 기록해보세요.

ESLint

  • lint 같은건 개인 취향, 누군가는 불편하다 or 괜찮다 하는 부분이 다 다를 것
  • option을 많이 넣어서 써보긴 했는지?
    • eslint 규칙? 우아한 형제들이었는지, 그런데서 나온 걸 가져와서 이용해본 경험이 있음(진명님)
    • 취향을 타기 때문에 기존에 사용했던 게 있으면 같이 써보고, 막상 써보면 생산성이 저해가 될 수 있는 애들도 있음. (에어비엔비 같은거 적용해놓고 하나씩 빼 본 적이 있음..)
      • 순서가 바뀌어서 에러나는 경우도 존재
  • 쓰다가 너무 불편하거나 하면 빼도 되니까 잘 논의하면서 빼고 넣고 하면서 써보기
  • lint 옵션 뭐가 있는지 정확히 알 필요는 없지만 한번쯤은 읽어보는 것도 괜찮음.
  • 깃모지와 비슷한 느낌?? 깃모지보다는 조금 낫긴 하지만 호불호가 갈려서 은근 불편할 수는 있다는 점.

기획

  • 랭킹
    • 주간, 월간 랭킹을 해도 되는데 텀을 짧게짧게 가져가야해서 추가 기능으로 넣는 것이 좋을듯

      (Priority를 낮추는 것도 좋을 것 같다.)

      • 주간은 랭킹 5번, 월간은 1번밖에 못하니까.. 추가 기능으로 넘기자는 뜻. 당장은 급하지 않는 기능이다. (아이디어 자체는 괜찮, 프로젝트 기간이 짧은거 특성상)
  • 주식 아이디어에 대해서..
    • 주식에 대한 공부가 필요..
      • 주식 공부에 대한 열정을 높게 살 것 같다.
        • 문서 보면서 했다고 했더니 문서 진짜로 보면서 했는지 확인해보는 그런 면접 질문도 나왔었음.
        • 수학 관련된 기술을 코드로 표현하는 과정이 필요할 것. 잘 구현해보자
    • 차트 등 다양한 정보를 담은 걸 넣으면 좋을 것 같음. 완성도를 위해서
      • 여러 추세선과 같은 것
      • 단순히 막대그래프만 나타내는게 아닌 것!
      • 주식에 관심을 갖고 구현한 정도에 따라 완성도가 많이 갈릴 듯 하다.
    • 실제로 반영되게 할 수는 없을까? 하는 아이디어
      • 일주일 전 데이터를 불러와서 주가에 영향을 줄 수 있는지 등….
      • 금액이 많아지면(1억원어치, 10억원어치 등…) 당연히 영향을 줄 수 있는건데 게임 내에서는 영향을 주지 못하니까.. 고려가 된다면 고려해보는 것도 괜찮을 것 같다
    • 주식으로 대결은 어떤 방식으로 하는가?
      • 초기에는 대결이 시작한 시점부터 끝나는 시점까지 수익률이나, 금액 등을 가지고 하려고 했으나 대결 시작 전 가지고 있는 자산 등에 영향을 미칠 수 있다고 생각해서 변경.
      • 특정 회사를 골라서 거기에 대한 수익률로 비교하는 방식
      • 그렇다면 대결 머니를 지급해서 그 돈으로만 할 수 있게 해보는 방식은 어떨까?
  • 비기능적 요구사항?
    • 암호화 BE에서 신경 많이 쓰고
    • 모듈화 진짜 어려울테니 잘 고민해보자!
    • 여유가 된다면 반응형까지 고려해보기
    • 데이터는 무조건 데이터가 많을 때로 고려해보기. 주식 같은 경우 웬만한 구조를 버티지 못할 거 같으니 부하 테스트 많이 해보는 것도 괜찮을듯.
  • 아이템은 부가기능이니, 여건이 안된다면 배제하는 것도 괜찮다. 아이디어 자체는 괜찮
    • priority 다시 생각해보기 ⭐⭐⭐⭐
    • 주식에 대한 완성도를 올릴 건지 게임을 위한 부가 기능에 집중할 것인지
    • (멘토님 개인생각) 완성도를 올릴 것을 추천하긴 함. 아이템 부가기능보다 반응형 웹을 생각해보는 것도 괜찮은 선택이 될 지도

⇒ 재미는 있을 것 같지만, 테트리스 하는데만 2주가 걸려서 기간 판단을 잘 해봐야 할 듯. 웹 소켓 관련해서… 이벤트 주고 받는 개념 자체가 있던 상태로 해서 수월했지만 그런게 아니라면! 판단을 더 잘해보자.

⇒ 진짜 필수기능을 더 나눠가지고, 더 확실하게 해보자. . 우선순위 나눈 대로 진행해보되 아까 기획 관련 피드백 준거로 우선순위 조금은 다시 생각해보기!

⇒ 추가는 애매, 지금 있는 것도 적지 않다. // 담당자 정하는 건 도메인 별로 나누는 것도 괜찮.

소프트웨어 아키텍처

  • 괜찮은데!! 부하를 가해보면 아주 높은 확률로 터질 것이다. 이거에 대한 고민을 해야 한다. 서버를 아마 여러 개 띄워야 한다.
  • 사람이 얼마 없으니까 서버 한 대로 해도 되긴 하겠지만~ 여러 개 할 때는 어떻게 할 건지도 고민해보기. (예상 가능한 구조 잡아보기) 그런 관련 기능을 NCloud에서 지원해줄테니까.. (로드 밸런서 같은거) 고민해보면 좋을 것 같다. // 발전 시켜서 할 수 있는 버전 고민해보기.
  • 적어도 두대 정도 띄워보는 걸 추천 (멘토님은 pim2 두개 띄워서 했음, 웹소켓 신경 써보려고)

⇒ 지금은 너무 무난한! 사이드 프로젝트용 구조다.

기술적 목표

  • FE

    • 최적화가 정말 중요할 것 같음.
    • 정말로 부드러운지, 버벅임이 조금 있는지.. 등등
    • 상태 관리가 빡셀 수 있다. 얼마나 깔끔하게 설계하느냐가 중요할 듯

    ⇒ 라이트하우스 다 찍어보고 (개발자 도구에 Lighthouse 있음, 퍼포먼스 측정 도구 / 반응형 고려할 거면 모바일로도 꼭 측정해보기) 나오는 개선사항을 다 개선해보는 것도 좋을 것 같다. 빌드 개념 등 다양한 개념도 같이 익혀보기. 100점 찍기는 어렵지만~ 상향 시켜보는 방향으로 해보기!

    과정을 다 기록하기(초기에 몇점이었는데 어떤 거 개선해서 몇점까지 올렸다~)

  • BE

    • 아까 말했던 대용량 처리! 부하테스트는 꼭 해보기
  • common

    • 문서화는 커먼에 넣어도 되는데 다른 CI/CD 이런건 인프라로 빼도 될듯!

devOps 추천

  • slack, git, github action 슬랙봇 써서 pr 알림도 다 날라오게 하고 할 수 있으니까… 되게 무난함.
  • 노션만 써서 할 수도는 있음~ (멘토님네 회사는 그렇다네요)
  • 습관화 하는 것 필요!
  • 회사에서도 개인이 직접 카드 옮기거나 하는 것처럼 해서.. 좀 귀찮지만~ 협업을 위해 적응한다고 생각하고 열심히 해보자!

프로덕트 백로그

  • 못할 것 같은거 없앨 필요까진 없지만! 한번 걸러내는 것도 괜찮다.
  • 일차로 무조건 여기까지 되어야 한다! 하는 애들은 판단하기.
  • 대결 기능도 약간 부가 기능이라고 생각하긴 함.
  • 일 통계 내는 기능(랭킹)이랑 주식 관련 기능(검색, 정보확인, 거래 등), 로그인은 필수인 것 같고, 이제 친구 추가 같은 거부터는 다 부가 기능 같다.
  • 아이템은 75점까지는 아닐 것 같다. . . 근데 게임이 주제라서 어떻게 하면 게임을 잘 녹일 수 있을까?! 멘토님의 고민이었네요..ㅎㅎ
  • 일단 6번까지는 무조건 하고!(멘토님이 느끼기에 메인 기능), 밑에는 부가로 생각해보자.
  • 꿈을 펼치라고 말하고 싶지만~ 메인 기능은 다 해야 하는 건 맞으니.. 기능이 어느 정도 자리를 잡았다하면 추가 기능 붙이는거 무조건 좋다~

⇒ 지울 필요는 당연히 없고!! 우선순위 한번 더 생각해서 잘 정해보자

소켓 통신 주의점

  • 은근히 이벤트 관리가 어려움. 꼬이지 않게 하는게 중요하다.
  • 소켓이라는게… (테트리스로 설명) 블럭 회전해서 좌표 하나하나 다 이벤트로 다 쏘고, 블럭 내려오는거 1초마다 하나씩 다 쏘고.. 그런 식으로 했음. 안꼬이게 하는 것만 해도 잘하는 거임
  • 웹 소켓도 있지만 [socket.io](http://socket.io) 써도 됨! 구현하라고 말하고 싶지만 멘토님도 socket.io를 썼다고 하시네요~
  • 소켓은 실시간이긴하나, 시간차로 갔을 때 어떻게 처리할 건지?? 이런 고민 해보는 것도 괜찮을 것 같다.
  • 자료 찾아보기. toss나 우아콘 이런거 보면 소켓 관련 내용이 있던 것 같음. 관심 있으면 찾아보는 것도 좋을 것 같다. ⇒ 트랜잭션 이런 것도 필요할 것 같다. 잘 걸어야 하는데 이거는 토스 컨퍼런스에 있으니 한번 봐도 괜찮을 듯!
  • 여러 컨퍼런스 찾아보면서 기술적인 내용이 있는 레퍼런스 찾아보는 게 좋음

Kafka 이런거 써볼만은 한데 .. 이 프로젝트에서 쓸 필요가 있나?? (멘토님 프로젝트) 메시지 할 때 썼던 것 같음

피그마 디자인 방식

  • 디자인 잘하는 사람이 있어서 그 사람이 해줬던 것 같다.
  • 디자인은 요새 AI 툴도 있으니까~ 참고해보는 것도 좋을 것 같다!
  • 디자인 가이드 만들고…
  • 실제 증권 사이트 레퍼런스로 참고해서 해보는 것도 좋다!
  • 여건이 되면 컴포넌트화해서 margin 이런거 주는 건 괜찮지만…. 시간은 없을 것 같음. 크기같은거는 4의 배수로 하는게 좋을듯(회사 디자이너분들이 이렇게 하신다네요// rem 기본 단위가 16px인데.. 이런거 생각해서 하는걸까요? 갑자기 궁금하네요.)

프론트엔드 테스트 코드

  • 테스트 코드를 잘 안 짜는 편…
  • 테스트 코드 때문에 개발이 늦어지거나 많은 고민은 하지 말자. → 양날의 검 느낌
  • 신입에게 테스트 코드를 잘 기대하지 않을 수도 있음…! (얼마나 잘 짜겠어! 하는 사람도 있음)
  • 어느 정도 기능이 나온 이후에 적용해보는 것도 괜찮을 것 같다.
  • 아니면 진짜 불편함을 겪어서(배포 나갈 때마다/로직이 바뀌어서 자꾸 에러가 나서) 이래서 테스트 적용해본거면 괜찮을듯

TDD

  • TDD 쉽지 않음.
  • 백엔드는 핵심 로직에 대해서는(계산 로직) 작성해도 괜찮다! 그렇지만 덕지덕지 할 필요는 없다.
  • 단위 테스트. 특정 모듈만 테스트 해보고 잘 되는 지 그런 식으로만 해도 괜찮다!
  • 당장 엄청 많은 테스트를 해볼 필요는 없고, 코어 기능만 테스트 해봐라~
  • 찍먹은 나쁘지 않지만 시간을 잡아먹히지 않았으면 좋겠다.

TS 학습 팁

  • 직접 써보면서 공부하는 타입이라… 따로 공부를 해보진 않음. 쓰다보면서 알게 된 케이스
  • 이해가 안가더라도 조금씩 읽어보는게 좋다.
  • 자바스크립트로만 개발하다보면 뭐가 터짐. 타입이 없어서 이유를 알 수 없다..ㅎㅎㅎ 진짜 불편함.
    • api 응답이 왔는데 왜 터졌는지 전혀 모름..ㅎ
    • 원인 알려면 하나씩 타고타고 들어가야해서… 타입이 있으면 무조건 좋은 거 같음.
    • 타스를 잘 쓰기 위해서 많이 써보고 자료도 종종 보고… 그게 좋은 것 같음
    • any/unknown 남발하지 않기. 언노운은 진짜 쓸 일 없고 애니도 웬만해서 쓰지 말자.
      • 타입 너무 모르겠으면 질문해도 좋고, 생활 코딩 강의 봐도 좋다!
  • as 왜 지양??
    • 쓰면 타입스크립트 사용하는 의미가 없다! 이런 느낌이었음
    • 이펙티브 타입스크립트 책인데.. 이유가 나올 것 같음
      • 타입 단언하면 타입 체크 할 수 없음.
      • 타입 선언으로 하면 객체 안에 필요한 name 같은 거 없으면 타입 체크로 에러 걸러주는데 타입 단언해버리면 name 없어도 오류 없다고 뜸! ⇒ 타입스크립트의 이점을 잃어버린 것
      • 속성 추가할 때도 타입 선언은 없는거라고 추가 안된다고 에러 잡아주지만, 타입 단언은 그냥 봐주고 넘어감.
    • 그럼에도 as를 써야 할 때가 있음
      • 라이브러리 타입을 도저히 유추할 수 없는 경우 등…
  • 타입 같은 경우에 무조건 다 붙여줄 필요는 없고 타입 추론 가능한 경우에는 생략해도 괜찮다~

chart.js 사용

  • 예전의 멘토님이었으면 무조건 구현해보라했을 것 같다.
    • 이 부분이 어려운데 이 라이브러리는 어떻게 구현했을까? 하면서 참고하면서 공부할 수도 있지만, 안 써가지고 일주일 붙잡고 있고 이러면 안된다!(팀 협업에 영향을 주면 쓰는 게 낫다.) 2, 3일만에 구현 가능하다하면 구현해봐도 좋을 것 같다. (구현력 기르는 이점은 얻어갈 수 있다.)

      ⇒ 마지노선을 잘 정해서, 하고 싶으면 해봐도 좋다~

      ⇒ 회사에서는 라이브러리를 잘 사용하지 않음. 내부에서만 쓰고(어드민) 디자인 라이브러리는 잘 사용하지 않음.(커스텀의 문제 때문에)

      ⇒ 우리가 나타내려는 디자인의 차트를 잘 구현해주는지 잘 알아보고 쓰면 될듯

      ⇒ chart.js 가 니즈 충족 너무 잘된다? 아니면 시간 상 문제 때문이다? 그런 것도 충분한 답변이 되기 때문에 잘 논의해보자~

    • 라이브러리 쓰는 거 괜찮다. 내가 원하는 대로 예쁘게 커스텀되고 하면 써도 상관 없을 것 같다!

대용량 데이터 관리 팁

  • 주가가 변할 때마다 정확히 어떻게 구현되어있는진 모르겠지만… 주가가 변하는 모든 걸 저장할 필요는 없고, 뭐 5분이다! 그런거면 그 5분에 대한 데이터만 저장하면 됨. 설계에 따라 달라질 것 같다. (매분, 매초는 DB에 저장할 필요 당연히 없다.)
  • 데이터가 얼마나 쌓일 지 모르겠다, (주식 장이 열리는 6시간 30분 ⇒ 390분이니까.. 1분씩 저장한다치면 하루치가 390개인데.. 회사 10개 한다치면 3900개. 이러면 많은 편은 아니라 DB에 저장해도 되긴함)
    • 1년에 한 회사당 14만개 정도(물론 주말이나 공휴일도 빼야 하긴함) * 상장 회사 약 2700건이니까 데이터 1년에 3.8억 정도. 이러면 괜찮을 수 있음 DB에 넣을만 한 것 같다. 엄청 많은 건 아니니까 DB에 넣어도 될 것 같다.
    • 처음에는 유명한 기업 몇 개만 넣어도 될 것 같다. . 비용따라 갈릴 만한 내용
  • 1분 단위 아니고 5분 단위로 해도 괜찮다! 이런 우리만의 제약 사항을 걸어도 괜찮다.

DB 설계 및 Redis 사용

  • Redis는 휘발성이니까, 날아가도 괜찮은 데이터를 넣어야 함! (로그인 세션 처리하면 필요)
    • 서버가 여러 개 나뉘게 될 때 정보를 모아줄 하나의 공간으로 Redis를 많이 사용
  • 랭킹 테이블
    • 스케쥴러 돌려서 하루에 특정 시간에 랭킹 딱! 계산해서 정보 따다닥 올리는 그런거 만들어도 괜찮다.
      • 게임 랭킹 시스템(메이플은 새벽 2시 업데이트인거 같더라고요.. 제가 해봐서 앎)도 스케쥴러로 돌아가는 것 같음. 그런 식으로 해보는 것도 좋다!
  • 채팅은 NoSql 써보는 거 좋음. MongoDB 같은거.. 로그성 데이터는 관계형 DB랑은 크게 안어울려서.. 채팅 같은건 따로 관리하자
    • 데이터 베이스 여러 개 충분히 많이 씀!!
  • 알림도 회사에서는 로그 썼던 것 같은데..
  • 주문하고 거래하고 이런거 멘토님 생각으로는 NoSql에 넣을 것 같음. 한번 더 찾아보는게 좋을 것 같음. 로그성 데이터로 생각한다면 생각할 수 있는 부분이니까!!

⇒ RDB 써보고 좀 느린 거 같다? 이러면 NoSql 써보면 괜찮을 것 같다.

✔️ 체크리스트

1주차 멘토링에서 이야기 나누면 좋을 주제입니다. 우리 팀의 상황은 어떤가요? 팀원 및 멘토와 함께 셀프 체크하고, 그 이유를 작성해보세요. 추가하고 싶은 항목이 있다면 직접 추가해도 좋습니다.

  • 프로젝트 기획과 설계의 뼈대가 나왔다.
  • 프로덕트 backlog가 제작되었다.
  • 서비스 핵심 기능에 대한 완성도의 기준 또는 기술적 목표가 수립되었다.
  • 현실성 있는 계획이 수립되었다.

📜 개발 일지

⚠️ 트러블 슈팅

❗ 규칙

🗒️ 기록

기획
회의록
데일리스크럼
그룹 멘토링
그룹 회고

😲 개별 멘토링

고동우
김진
서산
이시은
박진명
Clone this wiki locally