🧑‍🏫 멘토링 일지

Week02. 멘토링 2주차 : 기술적인 도전이란 무엇인가?

🛤️기술스택과 기획 방향이 잘가고 있을까요?

백엔드 프레임워크

💡 결국 스프링을 선택하셨군요

세션 vs JWT

💡 refresh token이 굳이 Redis를 써야한다고 생각한 이유는 무엇이신가요?

• JWT는 서버의 수평적 확장에 더 유연하게 대처할 수 있다.
• session은 연결성이 보장되어야하기 때문에, 클라이언트가 다른 서버와 연결되었을 때 인가가 어려워질 수 있다.
• 요즘 트렌드가 서버가 늘어나는 트렌드이기에, JWT를 고려해보면 좋겠다.

프론트엔드 프레임워크

💡 Nextjs는 React와 함께 씁니다.

• NextJS를 기술스택으로 언급할 때 React와 함께 쓰기

npm vs yarn

💡 지금 yarn에 대해 적어주신 내용은 yarn berry에 대한 내용입니다.

• yarn berry는 아직 호환성이 안맞는 것이 많고, 프론트에서만 사용할 경우 굳이? 라는 생각
• yarn classic 도입은 고려해볼만 하다. 더 빨라질 것임.

현재 프로젝트에서 기술적으로 핵심적인 부분이 무엇으로 보이시나요?

💡 이 부분을 먼저 확실히하면 좋겠습니다. 지금 캠퍼분들께서는 어떤 부분이 핵심이라고 생각하시나요?

• 프론트엔드 : 데이터 시각화, 성능 측정
• 백엔드 : 실시간성 보장

⇒ 차별화가 없어보입니다.

💡 최대한 기술적으로 core한 것을 차별화를 고려해서 정해야합니다. 다른 것들은 core에 접근하기 위한 것이 되어야합니다.

백로그의 마감기한

💡 마감기한이 없으면 이것저것 조금씩 건드리게 되고, 그럼 프로젝트가 효율적으로 진행되지 않을 수 있습니다.

❗스프레드 시트에 마감기한 열이 숨김으로 되어있어서 발생했던 커뮤니케이션 오류였지만, 유의미한 피드백이라고 생각되어서 적어두었습니다.

❓QnA

div vs Canvas vs Svg

💡 성능과 인터랙션이 주요 기준이 될 것 같습니다.

• div, canvas, svg를 정적으로 비교한 실험자료는 신빙성이 떨어진다. canvas를 단순하게 쓴다면 빠르지만 canvas API의 기능을 활용하기 시작하면 느려질 것.

💡 각각을 어떻게 react스럽게 녹여낼 것인가에 대해서 고민이 필요할 것 같습니다.

• 이런 맥락에서 slido는 div를 사용하는 것 같다.
• 다양한 case에 대해서 동적으로 데이터를 보여줄 수 있어야하는데, svg보다 div가 그것에 용이할 것 같다.

기술적 core는 무엇을 고려하면 좋을까요?

💡 어필할 수 있는 차별화된 기술적 포인트

❗기술적 core의 난이도와 의미를 정확하게 짐작하지 못하고 있음.

• 예를 들어, 지금 상태라면 socket 서버를 증설한다고 했을 때, 어떤 방식으로 서로 다른 소켓 서버의 정보를 공유하는 것을 해결할 수 있는가? ⇒ 기술적인 도전
• 다만 이런 인프라적인 도전은 어느정도 정답이 정해져있는 문제 같다.
• 현재는 정답을 정해놓고 쫓아가는 느낌이다.
• 신입이 경험했다면 인상적이겠지만, 코드를 더 잘치는 사람을 뽑을 것 같다.

어떤 것이 백엔드의 기술적 도전일까요?

💡 CRUD를 벗어난 복잡한 작업들 (이게 가능할까? 싶은 것들)

❗예를 들어, 노코드로 웹사이트를 만들 수 있는 툴을 만든다고 생각해본다면 어떻게 구현할 것인가?

• 단순한 CRUD보다는 못하더라도 기술적인 도전을 해본 사람을 더 뽑고 싶을 것 같다.

💡 기술적인 도전과 처음써보는 기술 스택을 써보는 것은 다르다. 기술적인 도전은 ‘코드적인 도전’이다.

• 노동이 아니라 코드적인 도전이 필요하다.

Java와 JS간의 인터페이스 공유

💡 API의 response body를 미리 결정하고 출발하는 것이 좋겠습니다. 그래야 병렬 개발이 가능할 것 같습니다.

• JSON의 스키마를 미리 정하는게 좋다.
• API 명세를 만들 때는 테이블로 만들기보다는 OpenAPI를 쓰면 좋다. Swagger 등에서 테스트하기 좋다.
• 명세가 변경되면 백엔드 코드가 크게 바뀌어야할 수 있다.

Java 객체 생성 패턴은 어떤걸 쓰는게 좋을까요?

💡 Setter를 지향하고, Builder와 Factory를 사용합니다.

• 객체는 생성된 뒤에는 변경을 최대한 지양하는 것이 좋다.
• 빌더를 사용해서 객체를 생성한 이후에는, 값을 변경할 수 없게 하는 것이 좋다.
• 변수, 특히 객체는 최대한 변경하지 않는 것이 좋다.

Nginx와 Apache 모두 결국은 멀티스레드 아닌가요?

💡 하드웨어 부분의 처리가 아니라, 일을 처리하는 것의 문제입니다.

• 아파치는 매번 쓰레드를 생성한다. 결국 쓰레드 풀이 있다는 것은 쓰레드가 제한되어 있다는 것이고, 이걸 넘어가면 어떻게 될까?
• Apache ⇒ Nginx는 Java ⇒ Webflux의 관계와 동일하다.

저희가 가고있는 프로젝트 방향은 부스트캠프에서 생각하는 프로젝트의 방향과 같을까요?

💡 챌린지 + 스프린트 과정은 전부 팀프로젝트를 위한 기본기의 과정, 프로젝트는 배운 것을 망라하고 집합한 그 이상이 있어야하지 않을까요?

• 기술적인 핵심을 말했던 이유가, 배웠던 것을 총망라해서 무언가를 만드는 것이 아니라 차별화된 무언가가 있어야하기 때문.
• 한 달에 4명이나 되는 프로젝트에서, 기술적인 기본기에 챌린지를 얹어서 남들과 차별화되는 나만의 포인트를 보여주는 것이 최종목적 아닐까?
• 어떤 기술스택을 정하는 것도 같은 맥락이다. 기술적인 도전은 꼬리질문에 대한 답을 할 수 있게 되는 기반이 된다.
• 결국은 ‘왜’가 중요해진다. 답은없다. 근거가 있으면 된다.
• 프로젝트에 디메리트가 될 수 있더라도, 기능을 쳐내고 기술적인 도전을 추가해도 좋을 것 같다.

🏁 마무리

캠퍼분들은 처음 프로젝트 시작과 지금에서 무언가 차이가 생기셨나요?

💡 당장 한 시간전과도 달라졌습니다…. **네. 그게 현실입니다.**

• 협업하는 것은 어려운 것 같습니다. 실무도 그런가요?

  ⇒ 네. 그게 현실입니다.

• 기술선정의 모든 이유를 나누고 싶었는데, 생각보다 정말 세세한 라이브러리까지 나누는게 어렵다는 생각이 들었습니다. svgr(next에서 svg를 사용할 수 있도록 처리해주는 라이브러리) 같은 경우가 그랬습니다.

프로젝트 관점으로 보았을 때, 잘하고 계신 것 같습니다.

💡 커뮤니케이션도 좋고, 열심히 하는 것도 좋지만 잘하는게 중요합니다.

🗣️ 멘토링 이후 논의 : 기술적인 도전 방향 수정

💡 1. 데이터 시각화 (키워드 개수에 대한 시각화, 키워드 연관관계 계산 알고리즘, 키워드 연관관계에 따른 시각화, 키워드 자동완성, 키워드 추천) 2. 근거있는 성능 개선 (FE 웹 페이지 체류시간 도구 - 병목현상 파악 가능, 라이트하우스, 서버 부하테스트 - 많은 클라이언트에서 키워드 추천 요청을 보낸다면?, 이에 따라 성능 개선)

Day 5.5. 멘토링 이후 회의록

Week04. 멘토링 4주차 : 물음표 살인마들

⚠️ 주된 주제

• 이력서 궁금점 나누기

  ⇒ 소설 쓰는 방법

• 개발 과정 중 궁금한 내용들

다음 주 모임 시간

• 금토일 제외, 8시 정도면 괜찮을 것 같습니다.
• 목요일 8시가 좋겠습니다.

📄 이력서에 대해서

❓ 수치 데이터가 아직 안나왔고, 프로젝트가 아직 안끝났는데 어떻게 써야할까요?

• 초안 공유 이후 이야기

❓ 자격증은 어느정도로 써야할까요?

• 자격증은 굳이 중요하지 않다.
• 없는 것보다는 있는게 낫지만, 큰 플러스 요인은 되지 못한다. 실무를 반영하지 못하기 때문.
• 정처기가 마지노선 같다.

❓ 자격증에 대한 부연설명이 있는게 나을까요?

• 더이상 쓰는건 너무 많이 가는거 아닐까요?
• 물어봤을 때 설명하면 될 것 같습니다.

❓ 교육과정에 대한 설명은 어떨까요?

• 이건 부연설명이 조금 있는게 나을 것 같다.

• 자격증은 취득하면 끝이지만, 교육 과정은 프로젝트를 진행했으며 과정이 더 중요하기 때문.

• 가장 중요한 것은 프로젝트를 어떻게 했는지가 중요한 것 같다.

  ⇒ 뭘 배웠고, 어떤 프로젝트를 했는지

❓ 프로젝트에서 협업에 관련된 경험에도 관심이 생길까요?

• 관심이 가지만, 그래도 기술적인 질문을 하게 된다.
• 신입의 면접질문이라면, 커뮤니케이션 관련된 정보로 이해할 수 있을 것 같다.
• 그 이상으로는 딱히 물어보지 않을 것 같다.

❓ 버전관리는 커뮤니케이션일까요 기술일까요?

• 둘 다 아닐까요?
• 생각보다 버전관리가 어려웠습니다. 배포 / 나의 코드 / 남이 실행시키는 나의 코드가 달랐다.
• 문제상황과 풀이과정과 결과를 보여주는게 좋을 것 같다.

❓ 요구사항과 명세, 기획에 대해 주도적인 태도는 어필이 될까요?

• 도움은 되겠지만, 기술이 99%를 차지한다.

🗣️ 프로젝트 기여 항목에 대해서

• 무조건 숫자로 쓰지 않더라도, 기술에 대해 문제를 인식하고 도전과 과정, 결과를 설명하는 것이 중요하다.
• 단순히 프로젝트에 대한 정보만 쓰면, 읽는사람이 정보를 얻기가 어렵다. 상세하게 쓰는 것이 좋다.

❓ 왜 라이브러리를 사용하지 않았는가?에 대한 질문이 올 수 있는가?

• 그 반대가 훨씬 많겠다.

❓ 왜 라이브러리 안썼는가?에 대한 걱정을 안해도 될까요?

• 제한적인 기능을 담은 라이브러리를 만듬으로써, 라이브러리의 동작을 알기 위해 했다.
• 오히려 만들어보았으니, 차이가 어떤게 있는가에 대해 잘 답변할 수 있을 것 같다.

❓ 탐구정신에서 점수를 받게되는걸까요?

• 원리를 모르면, 라이브러리를 쓴 것과 다를바 없다.
• 실제 라이브러리의 동작 원리를 알았을 때, 그때서야 강점이 된다.

❓ 기획단계에서의 문제 인식과 접근에 대해 적는건 어떨까?

• 기능을 구현한 이유와 맥락을 기술적으로만 설명하기가 어려웠기 때문 (ex. ~~한 서비스라서 ~~한 기술을 도입해보았습니다.)

• 기획적인 배경이 모두 기획적인 배경이 아니다. (ex. 웹소켓 ⇒ short polling으로 넘어갈 때, 이정도의 실시간성이 보장할 필요가 없었다.)

• 다만, 이력서는 너무 세세하고 많은 내용을 적지 않는 것도 중요하다.

  ⇒ 이력서를 보고 궁금해져야하기 때문

  ⇒ 회사에서 누군가를 만날 때, 가장 먼저 보게 되는 부분

  ⇒ 내가 가장 어필하고 싶은 부분을 이력서에 써야한다. + 불필요한 것은 덜어내기

  ⇒ 이걸 아는 것이 중요하다.

❓ 어떤게 어필되면 좋을까요?

• 일단은 기술적인 고민들

  ⇒ 나는 생각하고 개발한다. 라는 것을 보여줘야한다.

• 어떤 문제 상황에서 어떤 기술을 써서, 어떤 성과가 있었는지, 왜 했는지

  ⇒ ex. JS만 쓰다가 TS를 도입한 경우

  ⇒ TS를 왜 도입했는가? TS를 통한 런타임 안정성과 개발 편의성

  ⇒ 여기에 대한 파생 질문이 나온다. 기존의 JS는 어떻게 했는가?

  ⇒ 이 과정과 거기에서의 어려움을 공유하여, 단순한 개발을 넘어서 제품의 라이프사이클을 이해하고 있는지에 대해 어필해야한다.

❓ 눈에 띄는 이력서에는 어떤 요소가 있을까요?

• 생각 과정이나 문제 해결같은 예시가 있을까요?

• 일단은 너무 똑같은 CRUD 프로젝트만 했다면 별 생각이 나지 않는다.

  ⇒ 받아도 rm -rf 조차 하지 않고 잊혀진다.

  ⇒ 특별하고 독창적인 경험이 좋다.

  ⇒ ex. webRTC를 이용해서 뽀모도로 타이머를 화상버젼으로 만들었다.

  ⇒ 내가 하고 싶은 프로젝트가 있어야 깃헙을 열어보게 되는 것 같다.

❓ 프로젝트에 대한 요약을 할 때, 기획적인 요약이 중요한지 기술적인 요약이 중요한지?

• 일단 이력서를 받는 사람은 프로젝트를 모르니, 기획적인 요약 한 줄 요약이 필요할 것 같다.
• 기술적인 요약은 프로젝트 설명에서 어필해야겠다.

🗣️ 노션 이력서는 비추드립니다.

• 노션은 흔히 페이지를 나눠서 쓰게되는데, 이 UX가 굉장히 좋지가 않다.

❓ 그럼 템플릿으로 쓰면 어떨까요?

⇒ 공백이 느는게 별로인 것 같다.

⇒ pdf 한 페이지로 뽑는게 좋은 것 같습니다.

❓ 좋았던 템플릿이 있으셨을까요?

• 템플릿보다 내용이 좋은 것 같습니다.

• 다만 사람인이라던가 엑셀이라던가 이런 것은 지양해주세요.

• 성장과정 쓰지 마세요.

• 쓰고 싶다면 나를 나타낼 수 있는 한 줄을 정리해서 쓰는게 좋다.

• 장난스러운 한 줄은 괜찮은데, 그건 유머감각이 뛰어날때만

• 개발 성향이나 철학이 녹아들어간 한 줄이라면 좋다.

  ⇒ 가치관을 볼 수 있어서

❓ 그렇다면 그런 철학을 뒷받침해줄 수 있는 내용이 이력서에 있어야할까요?

• 굳이 필요없다. 보통 면접의 자기소개 시간 때 풀어내면 될 것 같다.
• 자기소개는 보통 그런가보다 하고 넘긴다.
• 검토는 보통 인사팀 뿐만 아니라, 실무자들도 보기 때문.

❓ 기술보다는 성향에 가까운 기술관련 활동을 적어도 괜찮을까요?

• 그냥 썼나보다 할 것 같다. 굳이 쓸 필요 없을 것 같다.
• 보통 면접에서 성향을 확인하기 때문에, 필요치 않을 것 같다.
• 보통 면접 이후 컬쳐핏이 있기 때문에 거기서 하면 될 것 같다.
• 기술 면접에서는 대부분 이런 것들을 배제하고 기술만 본다.
• 일단은 기술에 대한 컷을 먼저 넘어야한다.

❓ 와닿는 이력서의 수치들

• 성능 개선이 제일 와닿는다.

• 성능에 대해 디테일한 수치가 있으면 더 좋다. (ex. 10분이 걸리던 것을 1분으로 줄였다.)

• 성능 개선도 맥락이 있어야한다. 테스트에 대한 수치가 신빙성이 있어야하기 때문이다.

• 어차피 성능 개선 했다고 쓰면, 면접에서 물어볼 것이다.

  ⇒ 궁금하게 만드는게 좋다!

❓ 이딴게 성능개선…? 굳이 이런 수치를…?

• 성능개선은 다 괜찮다.

  ❓ 그럼 left top vs transform 같은 기본적인 비교도 써도 괜찮을까요?

  • 프로젝트 내용에 있어서 중요하다고 생각하면 써도 되고, 아니라면 안써도 될 것 같다.

  ❓ 기술보다는 얼마나 핵심기능인가가 중요한걸까요?

  • 이력서에는 뭘써도 좋다. 다만 내가 잘 대답할 수 있는 것이면 된다.
  • 성능개선은 있으면 좋다. 근거가 있어야한다.

• 프로젝트 기여도 수치

⚙️ 기술

❓ 만지지 않은 브랜치의 코드와 충돌이 났다.

• 레포 단위로 찢을 수 있는 것이 한 레포에 들어있다. 그래서일까?
• 브랜치 전략을 잘못 짠게 있는걸까?
• 브랜치 충돌난 건, 그냥 다른 코드를 각자 만져서 충돌난 것 같다.
• 일단, 지금 왜 모노레포를 써야하는지 모르겠다. 레포를 쪼개는게 나아보인다.
• 기능 단위로 레포를 나눠도 괜찮지 않을까?
• 위키는 여러 레포를 합쳐서 위키를 만들 수 있지 않을까? 결국 마크다운으로 관리되는 파일들의 집합인데

❓ 레포지토리와 브랜치 전략 사이의 상관관계가 있을까요?

• 확실히 모노레포에서는 복잡한 브랜치 전략을 쓰기 힘들다. 이에 관련된 전략도 따로 있다.
• 다만 싱글브랜치는 말이 안되는 것 같다. 그럼 Git을 쓰는 이유가 없는 것 같다.

❓ 브랜치 전략이 너무 많지는 않나요?

• Trunk Based Development, Git flow, Github flow 정도가 있는 것 같다. 별로 많지는 않은 것 같다.
• 보통 기초가 되는 전략을 회사마다 조금씩 변형해서 쓰고 있다.

🗣️ 깃과 깃허브를 구분하지 못하는 개발자가 많다.

• 깃의 PR을 썼습니다. 라는 말을 할거면 이력서에 안적는게 좋습니다.

  ⇒ 더 나아가, 기초개념에 대한 설명이 틀리면 말에 대한 신뢰가 확 떨어지므로 잘 생각해서 써야합니다.

❓ JPA가 별로입니다. 주로 어떤 것으로 개발하시나요?

• NodeJS or Kotlin Webflux

• 자바 ORM은 뭘 써도 별로다!

  ⇒ JPA만으로는 스키마 내역관리도 못합니다.

  ⇒ ORM을 쓰는 이유는 DB 스키마 내역 관리도 있는데 아쉬운 점이다.

🛤️ 프로젝트 방향성

1️⃣ 인프라적인 해결을 덜어냄.

2️⃣ Websocket ⇒ Short Polling

• stateless의 강점을 느낄 수 있었다.

❗ 그런데, CRUD 이상이라고 말하기가 어렵다고 느꼈다.

• CRUD 구현은 기본으로, API 요청 시간 개선, 쿼리 튜닝, 알고리즘 튜닝, 인스턴스 늘리는 식으로 성능 개선에 집중해보려고 합니다.
• 근거있는 성능 개선이라는 과정을 통해서 같은 CRUD 내에서 좋은 태도를 보여주고자 한다.

❓ 다만 결국 CRUD에서 벗어나진 못한건데, 어떻게 생각하시나요?

• 성능 개선을 위한 부분에서 코드적인 도전이 유의미하지 않을 것 같다.

• 결국 DB쪽으로 가지 않을까? 인덱스와 정규화선에서 정리되지 않을까?

• 부하테스트를 통한 데이터 기반의 의사결정을 보여주는게 나을 것 같다.

  ⇒ 상위 10%, 하위 10%, 평균 응답속도 각각의 데이터를 통해서 각각의 데이터가 무엇을 의미하고 무엇을 개선할 수 있는지?

  ⇒ 병목을 찾아서 성능을 개선하는 것이 중요하다. 단순히 ORM 쿼리의 성능 개선은 유의미한 성능개선이라고 보기 어려울 것 같다.

  ⇒ 인스턴스를 늘리는 것은 기술적인 해결방법이라고 보기는 어려울 것 같다.

❓ Nginx의 활용이나 DB 구조 개선은 어떨까요?

• 이것 이전에 코드적인 개선이 필요하다. 자꾸 인프라로 성능개선을 하려고 한다.
• 코드의 문제를 인프라로 땜빵한다는 느낌을 주면 안된다.
• 인스턴스를 늘리는 것은 개선이 아닌 것 같고, DB 구조를 변경하는 것은 기술적인 개선이라고 볼 수 있는 것 같다.
• 인프라보다 DB 모델링을 개선해보는 것이 더 근본적인 해결방법 아닐까?

❓ 어느정도로 코드로 도전한 뒤 인프라를 시도해봐야한다는 기준이 있을까요?

• 당연히 좋은 CPU에서 문제를 풀면 더 좋은 결과가 나온다. 다만, 이것은 올바른 해결방법이 아니다.
• 시간복잡도 자체를 낮출 수 있는 것이 근본적인 접근이 아닐까?
• 쿼리 실행 계획이 이상할 때의 Query Explain 분석, 시간복잡도의 개선할 수 있는 부분은 없을지 충분히 고민하고 인프라로 넘어가야하지 않을까?
• 신입에게 인프라는 어느 회사에서도 크게 기대하지 않는다. 백엔드의 2차 전직 같은 느낌.

❗ 문제가 터지지 않은 사황에서 프로젝트 소개나 이력서 작성을 위해 기술적인 도전을 정하려다보니, 인프라 같은 정해져 있는 풀이에 접근되는 것 같기도 하다.

• 처음부터 디자인 패턴 공부하려고 하면 와닿지 않는다.
• 필요성을 느낄 때 해나가는 것이 좋다.
• 개발은 일단 만들어보는 것이 좋다.

❓ 테스트 코드는 어떤가요?

• 무조건 짜야한다. 큰 메리트이다.

❓ 코드 커버리지로 수치적인 이야기 해도 될까요?

• 가능하지만, 코드 커버리지로 모든 것을 보장할 수는 없습니다.
• 테스트 코드를 왜 썼을지나, 수치 목표가 왜 있었는지에 대해 고민하면 좋을 것 같다.

❓ 캐시도 인프라적인 해결일까요?

• Redis 같은 캐시 레이어를 쓰면, 인프라적인 해결방안이다.

❓ 백엔드에서 코드적으로 캐시를 구현해보면 어떨까요?

• 대부분의 요청은 HTTP가 캐시를 해줍니다. Redis가 정말 필요할 때가 필요할 것 같습니다.

❓ 프론트엔드 테스트 코드는 어떤가요?

• 유저 시나리오에 기반한게 좋은 것 같습니다.

• 로그인 컴포넌트 렌더링 되는가? 같은거 테스트해도 큰 의미 없는 것 같다.

• 단위 테스트보다는 통합 테스트나 E2E 테스트가 더 유의미한 것 같다.

• 컴포넌트 안에 들어가있는 비즈니스 로직은 단위 테스트가 가능하겠다.

• 테스트 커버리지보다 유의미한 테스트에 집중하는 것이 나을 것 같다.

  ⇒ 분기별 테스트는 가능하더라도 시나리오에 대한 테스트를 보는게 어렵다. 유의미한 유저 시나리오를 가진 테스트가 우선순위가 더 높은 것 같다.

🗣️ 요즘은 인프라를 줄이는 쪽의 방향이다.

• 효율성을 높여서 1억 감소 이런게 목표가 되고 있다.

• 오 그럼 Websocket → Short Polling을 어필하면 좋을 것 같습니다.

• 처음에 인프라로 해결하려다가, 그것보다는 코드의 효율성을 높이는 것이 근본적인 해결책이라고 접근했다는 것을 이력의 한 줄이 될 수 있을까요?

  ⇒ 그럴 것 같습니다. 다만 맥락이 중요할 것 같습니다. ex. 코드나 구조의 개선 없이 돈을 들여 인프라를 늘리는 것은 언젠가 트래픽이 증가했을 때 같은 문제들 낳을 수 있다고 생각해서 이렇게 전환했다.

Week05. 멘토링 5주차 : 성능 측정과 개선 방향

이번 주 어려웠던 점과 궁금증

라이트 하우스가 아닌 성능 측정 방법이 있을까요?

• 실시간으로 충돌을 연산하는 물리엔진의 경우, 라이트 하우스에서 로딩이 안된 것으로 인식하고 있었습니다. 다른 방법이 있을까요?

⇒ 라이트 하우스보다는 어느 정도의 자원을 쓰고 있는가를 보는게 나을 것 같습니다. React debug 등으로 확인해보실 수 있습니다.

실시간 연산의 메모리 사용량은 어디에 기준을 둬야할까요?

• 크롬 개발자 도구로 보았는데 최적화를 한 뒤 다른 사이트와는 큰 차이가 없었습니다.

⇒ 다른 사이트는 통합이 35mb 정도일 것 같다. 다른 사이트와 큰 차이가 없다면 문제가 없을 수 있으나, 다른 사이트가 백그라운드에서 어떤 동작을 하고 있는지에 따라서 다를 것 같습니다.

⇒ 해당 컴포넌트만 독립적으로 측정해봐도 좋을 것 같습니다.

❗충돌을 제대로 처리하지 못하고 있다.

⇒ 예외처리가 추가되어야할 것 같습니다.

⇒ 인터랙션이 그냥 한 점으로 모이고 있다. 다른 다이나믹이 있어야하지 않을까요?

⇒ 모이는 위치에 대한 랜덤성이나 충돌력이 더 커지게 하는등 역동성이 생기면 더 재미있을 것 같습니다.

SEO 점수와 접근성 점수는 높은 점수를 유지해야할까요?

⇒ 실무에서는 컴포넌트가 이미 만들어져 있는 경우가 많아서, 접근성보다는 성능에 더 우선을 두고 있습니다.

❓ 백엔드에서는 무엇을 하고 있나요?

• 기본적인 CRUD API

• 키워드 추천 시스템

• 키워드 소그룹 병합 시스템

  • 키워드 === 소그룹, 스레드 === 소그룹 내의 게시글

  • 소그룹 내의 안정적인 스레드 병합을 위한 배치 프로그램 구현

    ⇒ 큰 코스트가 소모될 것이라 판단, 배치 프로그램을 구현하려고 합니다.

• 쿼리문 튜닝 진행

• 테스트코드 작성 (API 테스트, 단위 테스트)

⇒ 성능 개선은 좋지만, 현재 구조로 어느 정도의 성능이 나오는지를 먼저 보고 우리의 목표를 정하고 성능 개선을 하는게 더 유의미한 성과가 있을 것 같습니다.

❓ 어느 부분이 큰 코스트라고 느껴지셨나요?

⇒ Index가 걸려있는 특정 Key값들을 업데이트 시켜주는건데, 어떻게 해서 큰 코스트로 계산되었는지 궁금합니다.

• ex) 여러 커뮤니티에서 한 게시판 당, 500~1000개의 게시글이 있을 때 5개의 키워드를 병합한다면 큰 코스트가 발생할 수 있다고 생각했습니다.

❓ 구체적인 결과가 있나요?

• 현재는 단순히 병합될 수 있도록 만들어두었고, 이후 테스트 예정입니다.

⇒ 먼저 현재의 5000개의 업데이트가 DB에서 시간이 얼마나 걸리는지 확인하고 해결법을 정하는게 낫지 않을까요?

❓ 배치 프로그램을 통해 우리가 얻고자하는 성능 이점은 어느정도인가요?

• 현재 soft delete로 키워드 병합을 만들고, 배치 프로그램을 통해서 실제 병합은 다른 시간대에 진행하려고 합니다. 속도보다는, 유저가 병합 중인 그룹에 들어왔을 때 겪을 불편을 해소하여 UX를 개선하기 위함이 더 큽니다.

⇒ 접근이 잘못된 것 같습니다. ‘스레드가 바라보고 있는 키워드’ 테이블을 만들어서, 어느 키워드를 바라보고 있는지 수정하는게 효율적이지 않을까요?

• 이 수정이 발생하는 시간을 이후에 할 수 있도록 하려고 했습니다.

⇒ 키워드를 단순히 집합으로 본다면, 물리적으로 병합하는 것이 아니라 스레드를 바라보는 집합을 옮기면 되지 않을까요? 배치 프로그램으로 미루어서 물리적으로 병합할 필요가 있을까요?

❓ 그룹 테이블을 만들고 키워드를 Foreign Key로 사용하면 되지 않을까요?

• 그렇게 구현할 경우, 스레드의 Foreign Key가 바뀌지 않아서 스레드만으로 읽기가 가능한 것이 아니라 키워드 테이블까지 확인해야해서 이런 문제해결을 고민했습니다. 이정도 제약사항이라도 해도 문제가 있을까요?

⇒ 스레드 테이블에서 스레드들을 가져오는 것이 아닌, 키워드 그룹테이블을 만들어서 해당 키워드 그룹테이블에 속한 스레드를 조회하는 방법은 어떨까요?

⇒ 현재는 5,000건이라고 하지만, 나중에 100,000건이라고 한다면 물리적인 병합보다는 이쪽이 나을거라고 생각합니다.

💨 혹시 지금 취업 시장이 많이 추울까요?

⇒ 실제로 많이 춥고, 뽑는 회사보다 내보내는 회사가 더 많습니다. 현재는 타이밍이 아니지 않나 싶습니다. 그래도 개발자가 다행인 것이, 개발자는 그나마 채용을 하지만 타 직군은 채용이 아예 없습니다. 그래도 우리는 열린 공고에 지원합니다.

🫖 기업 미팅 티타임에서 무슨 얘기하나요? 무슨 이야기를 해야하나요?

⇒ 어떤 포지션을 원하는지, 회사의 인재상 등등 컬쳐핏을 보는 자리이니, 편안히 가도 좋습니다.

• 면접과 아예 상관이 없는걸까요?

⇒ 아예 없지는 않습니다.

🧪 테스트코드 작성

• API 테스트, 단위 테스트를 구현하고 있습니다. 특히 API 테스트 중에 다른 기능과 의존성을 가지는 기능의 경우 API를 호출해서 해야할까요? 백엔드 메서드를 가지고 만들면 될까요?

⇒ 애초에 다른 기능과의 의존성을 가지면 안됩니다. DB 종속적인 부분은 무조건 Mocking을 하는 것이 낫습니다.

• API 테스트도 마찬가지일까요?

⇒ 단위 테스트에서 비즈니스 로직에 대한 검증이 끝나야한다고 생각합니다.

⇒ API 검증은 결국 거기에서 발생하는 에러 케이스를 검증하는 것, 결국 API는 각 함수 실행의 결과로 발생하기 때문에 단위 테스트로 충분히 검증이 가능하다.

👥 팀프로젝트 소개 피드백

• 실제로 이력서 검토하는 시간은 1분 정도

• 핵심기능과 도전과제 부분에서, 그래서 뭘 했는데? 라는 것 밖에 생각이 안난다.

• 처음 봤을 때 드는 생각은 기술적인 도전 과제가, 읽는 사람에게 하여금 너무 포괄적인 느낌을 준다.

  ⇒ 기술 도전 과제의 제목에서 임팩트를 더 주면 좋겠다.

  ⇒ 기능에 대한 내용은 소개로 빼는게 좋겠다. 섹션을 봤을 때 어떤 문제를 해결했는지 명확하지가 않다. ⇒ 어떤 문제가 있었고 왜 그런 선택을 했는지가 제목에서 보이는 것이 좋을 것 같다.

• 읽을 때의 흐름이 명확하지 않다. 읽었을 때, Problem에 나온 문제들의 해결과 과정이 충분히 연결되지 않아서 머릿속에서 정리되지 않는다.

• 지금 내용은 프레젠테이션 내용같다. 이력서나 채용을 위해서는 한 줄을 읽었을 때, 어떤 성과가 있는지 전달되는게 중요하다고 생각한다.

  ex) 물리엔진을 이용한 인터랙티브 버블차트를 구현하여 UX 향상’

• 프로젝트 소개는 괜찮은데, 이력서에서 중요한 부분 같다.

📄 이력서 피드백

• 프로젝트 소개와 이력서 내용이 같다면, 읽는 사람이 읽지 않을 것이다.

• 기술 스킬을 단순 나열하는 건 아무 의미가 없고, 털리기 딱 좋다.

  ⇒ 어디까지 아는지 꼬리 질문 할 것.

  ⇒ 프론트엔드 / 백엔드처럼 파트를 나눠서 어떤 것을 할 수 있는지 적는 것이 나을 것 같다.

  ⇒ 내가 프론트엔드 개발에서 중요하게 생각하는 가치가 무엇인가? 를 적어주는게 좋을 것 같다. ex) React와 TS를 활용하여 재사용성이 높은 프로젝트를 구현할 수 있다.

  ⇒ 이력서는 지원해서 평가받기 위함도 있지만, 면접을 내가 원하는대로 이끌어갈 수 있는 첫번째 관문이다. 내가 할 수 있는 분야와 역량을 구체적으로 적어주는 것이 좋을 것 같다.

• 프로젝트 부분은 정리가 필요할 것 같다.

  ⇒ 구어체로 쓰지 않아도 된다.

  ⇒ 문장을 더 깔끔하게 정리할 수 있다. 말하는 것처럼이 아닌 글로써의 글을 쓰는 것이 좋을 것 같다.

  ⇒ 요약을 해서 문제와 개선이 명확하게 보이는 것이 좋다.

• 프로젝트에서 드러나지 않은, 부스트캠프에서 배운 것이 있다면 적어줘도 좋을 것 같다.

  ⇒ CS를 배웠다거나 등, SQLD 설명처럼 적으면 좋을 것 같다.

❓ 창업경험은 넣는게 좋을까요 빼는게 좋을까요?

⇒ 이력서에 빼서 얻는 것이 무엇이죠?

⇒ 창업을 했다는 것으로 얻은 것은 무엇이죠?

⇒ 대부분이 스타트업일텐데, 넣는 것이 더 이점이 될 것 같습니다.

⇒ 직무나 회사와 유관하게 쓰면 더 좋을 것 같습니다.

⇒ 개발자 이력서 쓰는데 쿠팡맨을 쓴다면 별로겠지만, 창업은 스타트업과 관련이 있으니 좋을 것 같다.

• 부스트캠프에서 얻은 것을 적을 때, 구체적인 것 말고 애매하게 적으면 적어도 괜찮을 것 같다.

  ⇒ 과정을 통틀어서 적는 등. 개인프로젝트로 묶어서 적으면 되지 않을까요?

• 제주도 여행지도 관련해서는 쓰는게 어떨 것 같으신가요?

  ⇒ 자기소개에 예시로 언급하는게 좋을 것 같습니다.

❓ 외부링크 많이 보시나요?

• 깃헙, 블로그는 종종 보는데 노션은 잘보지는 않습니다.
• 자기소개 페이지가 노션이면 종종 눌러보는 수준입니다.

🔍 프로젝트 코드 리뷰

• PR 단위가 너무 크다.

• PR merge는 Squash merge가 낫지 않을까?

• types 파일 쪼개기

  ⇒ 나중에 합시다는 불가능합니다. 처음에 쪼개두어야 할 수 있습니다.

  ⇒ type export / import 씁시다.

• import 컨벤션

  ⇒ 외부 라이브러리 → 타입 → 함수, 컴포넌트들이 일반적인 순서

• 처음보는 사람을 위해 주석 써주기

• community as string 다는 방법으로 해결할 수는 없는지 확인하기

• undefined 배열 올 때, 분기로 가르지 말고 concat을 쓰면 된다.

  ⇒ if / else 분기는 나중에 테스트 하기도 힘들어서 최대한 안써주는게 좋다.

• 불필요한 할당 줄이기