• 인프라가 좋지 않을까? But, 이건 백엔드의 유의미한 키워드를 모르는 것일 수도 있을 것 같다.

  ⇒ 신입에게 인프라적인 지식을 요구하지는 않는다. 현업 경험이 중요한 포지션 중 하나. ⇒ 신입에게는 데이터 베이스 기초 역량, CS 지식, 네트워크 기본 역량등을 더 중요하게 보며, 이것이 사실 인프라와 연관이 많다.

  ⇒ 기술적인 난이도가 높지 않더라도, 코드를 꾸준히 리팩토링 하거나 프로젝트를 꾸준히 한 경험이 더 중요하다.

  ⇒ 코딩을 잘하는지. 방치되지 않고 코드를 유지/보수 하고 있는가?

  ⇒ 백엔드의 특정 영역의 전문성을 보여주기 보다는, 현재 프로젝트나 코드의 품질을 높이기 위한 노력을 보여주는게 나을 것 같다. CS나 DB 역량은 깊이 들어가기보다는 전공 지식 수준에서 보여주는 것이 나을 것 같다.

⇒ DB는 질의문, 네트워크는 데이터의 흐름. 웹 전반이 어떤 식으로 이루어져 있는지 ⇒ 면접 질문들을 한 Depth 더 들어갔을 때가 실제로 지원자 판단의 기준이 된다.

⇒ 프론트도 같을까요?

⇒ 프론트 / 백 모두 신입 때 요구되는 역량은 비슷하다. 기술이 다른 것일 뿐 역량은 비슷하다. 채용과정에서 백엔드는 알고리즘 테스트를 보는 경우가 더 많고, 프론트는 과제를 보는 경우가 더 많다.

⇒ 선택하기 나름. 팀 프로젝트에서만 할 수 있는 경험이 있다. 유지보수나 코딩 습관을 보여주기 위해 정할 필요는 없을 것 같다.

⇒ 프로젝트 볼륨이 커서 마감까지 빡빡하게 구현을 하는건 지양하는 것이 좋다.

⇒ 주제보다는 과정이 더 중요할 것 같다. 도메인을 어떻게 풀어냈는지, 어떤 고민을 했는지 보여주기.

⇒ 보통은 큰 기능 단위로 나눈다. 그러나 한 사람이 하나를 작업하기 보다는 여럿이 작업(예를 들어 프론트 백엔드의 협업)해보는게 좋지 않을까 싶다.

• 칼 같이 정한다 vs 진행하면서 정한다.

⇒ 상황에 따라 조금씩 다르다. 보통은 대략적으로 정해놓는다. 어떤 통신 규약을 쓰는지에 따라서도 다르다.

• 주고 받을 데이터 형식?

⇒ 주로 백엔드에 의해서 결정이 된다. 프론트에서 특정한 요구사항이 없다면 백엔드에서 개발해서 프론트에게 전달해준다.

⇒ 기능 의존성은 기능별로 해결해야하는 문제이다.

⇒ git 사용할 때, remote에 올라가는 코드를 rebase하고 push 하거나 force push 하면 안된다.

⇒ 작업하다가 pull 받으려고 했더니 엄청나게 꼬이게 된다. remote에 올라가는 코드는 rebase해서 하면 안되고, 새로운 커밋으로 만들어서 push 해야한다.

⇒ 중간중간 하는게 나을 것 같다. 근데 하다보면 어쩔 수 없이 하게 된다.

⇒ 플랫폼이 무엇인가? : nCloud 써야할 것 같습니다.

⇒ AWS 추천드립니다. 현업에서 대부분 쓰며, 구현할 때 참고자료나 best practice가 많다.

⇒ 사람이 수동으로 코드를 실행시켜야하는 정도만 아니면 괜찮을 것 같다.

⇒ github action으로 자동 배포. k8s를 꼭 쓸 필요는 없을 것 같다.

⇒ 문제 해결의 경험(배포 자동화 등)이 더 중요할 것 같다.

⇒ 우리가 어떤 문제를 가졌고, 그것을 해결하기 위해서 선택했다라는 흐름이 맞다.

⇒ 거기에 대해서, 여러 도구가 있는데 왜 꼭 그 도구를 선택했는지에 대한 근거를 설명하는게 맞을 것 같다.

⇒ 도구를 결정함에 있어서 여러가지 선택지를 비교해보는 것이 중요하겠다.

⇒ 역량에 따라 다를 것 같다. 내가 생각한 개발 기간 * 1.5를 해봅시다.

⇒ 중간중간 리팩토링을 한다고 치면, 2주 정도에 개발할 수 있는 분량을 하는 것이 좋을 것 같다.

⇒ 한 분야만 경험해도 상관 없을 것 같다.

⇒ 분야를 어느정도 이해하고 있다. 를 보여주면 될 것 같다.

⇒ 풀스택을 뽑는 경우는 많지 않아서 한 분야에 집중하는게 나을 것 같다.

⇒ 완성도 높은 기능과, 그에 담기는 기술적 고민이 더 중요하다.

거주 지역

• 멘토님 : 성수
• 대호님, 승민님 : 서울
• 성현님 : 하동
• 나 : 논산

주말 vs 평일

• 성현님 : 평일 선호
• 승민님 : 무관
• 대호님 : 무관
• 멘토님 : 평일 점심
• 나 : 평일 점심 (캠프 일정 없을 때)

⇒ 목요일 (11월 10일) 점심 즈음, 성수

⇒ 프로젝트를 함에 있어서 수많은 갈등과 문제에 부딪히게 될 것 같은데, 끝까지 잘해내시면 좋겠습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  ⇒ 네. 그게 현실입니다.

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

Day 5.5. 멘토링 이후 회의록

⇒ 유의미한 차이는 아니라고 생각합니다.

⇒ 초당 처리량이 nodeJS가 우월합니다.

⇒ 설계에 따라 다릅니다.

⇒ 리액트를 쓴다면 왠만하면 Canvas API를 사용하지 않는 것이 좋다. 만약 쓴다면 canvas ctx를 ref등으로 관리하는 것이 좋을 것 같다.

⇒ ref는 DOM에 대한 참조값을 가진다.

⇒ 직접 VDOM에 접근하는 방법이 없다. 다만 리액트 컴포넌트 자체를 참조값으로 받아온다면 어떻게 될지 모르겠다. ref는 참조값을 life cycle로 당겨오는 것이다.

⇒ 요새는 state나 ref, redux도 없이 서버 상태를 사용한다.

⇒ 중앙관리할 필요가 없을 뿐이다.

⇒ 글자는 다양한 시각화가 가능하지만 버블차트는 한정적이지 않을까요?

⇒ 구현의 영역이 아닐까? 차트로 느껴지지 않게끔, 차트로 보여줄 때부터 동적인 시각화를 주면 좋을 것 같다. 어떤 식으로 인터랙션을 줄 것인지 고민하는 것이 좋을 것 같다.

⇒ 소켓은 연결성이 있기 때문에 물리적 커넥션의 제약이 생길 수 밖에 없다.

⇒ 서버 증설로 서버 대수가 늘거나 줄때도 문제이다. 이 때 웹소켓을 쓰면 중개서버가 필요해진다. 그래서 차라리 HTTP Polling을 사용한다.

⇒ 장애 대응도 마찬가지이다.

⇒ 최근 HTTP/3를 통해서 handshake나 header로 발생하는 오버헤드 문제도 해결되었다.

⇒ 서비스마다 다를 것 같습니다.

⇒ SSE는 단방향이라서 비교 대상이 아닌 것 같습니다.

⇒ 유저의 고유값을 가져야하는데, 웹이 이것을 하기가 어렵다.

⇒ 발행구독으로 하는 것은 서버끼리 통신에서도 많이 쓴다.

⇒ pivot 한다면 어떤 식으로 메리트를 줄지 고민해보면 좋겠습니다.

⇒ 아쉽지만 현실입니다. 받아들이세요.

⇒ 공채는 가르칠 사람, 수시는 일할 사람을 뽑습니다.

⇒ 흥미로우면 봅니다.

⇒ 내가 잘하면 문제없습니다. 실력을 키웁시다.

⇒ 내가 고민해봐야만 대답할 수 있는 것들을 준비합시다.

• 이력서 궁금점 나누기

  ⇒ 소설 쓰는 방법

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

• 금토일 제외, 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을 썼습니다. 라는 말을 할거면 이력서에 안적는게 좋습니다.

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

• NodeJS or Kotlin Webflux

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 기본적인 CRUD API

• 키워드 추천 시스템

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

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

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

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

• 쿼리문 튜닝 진행

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

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

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

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

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

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

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

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

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

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

• 그렇게 구현할 경우, 스레드의 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 분기는 나중에 테스트 하기도 힘들어서 최대한 안써주는게 좋다.

• 불필요한 할당 줄이기

• 일단 이 기회에 브랜치를 나누면 좋겠습니다.
• 처음 백엔드에서 프론트엔드 폴더가 pull 된 시점이 공통 조상이라서, 그때까지 돌아가서 커밋을 바꿔야합니다.

• 그건 사파의 방법입니다. 정통 방법은 당시의 커밋을 변경해서 frontend 폴더가 추가되었다는 과거를 수정하는 것입니다.
• rebase 하면 할 수 있습니다.
• 근데 이것도 누군가의 local에서 merge 되거나 push 되면 다시 터질 수 있다.

⇒ git flow나 github flow를 공부하시거나, 모노레포를 사용하신다면 모노레포 관리 도구를 찾아봐도 좋을 것 같습니다.

⇒ 모노레포가 대부분의 시간을 merge conflict 하는데 쓴다는 것이 괜히 나온 말이 아닙니다.

⇒ 네 문제입니다. 그래서 구조를 같이 짜고 최대한 건드리지 않으면서 협업합니다.

⇒ 굳이라고 생각합니다. 서로의 폴더가 섞이지 않는게 무슨 의미가 있는지 모르겠습니다.

• 저희는 저장소를 나누듯이 브랜치를 나누려고 했던건데 의미없는 시도였을까요?

⇒ 지금처럼 저장소가 하나인 경우였다면 차라리 폴더가 하나였어도 상관 없을 것 같습니다. 프론트엔드를 작업하다가 백엔드 코드를 보게되는 경우도 필요하지 않을까요?

• 실무에서도 코드를 보는 경우가 많이 있나요?

⇒ Swagger 등으로 모든 정보를 표현할 수 없어서 볼 일이 생깁니다.

⇒ release를 당겨오는 것이 아니라, release가 main으로 병합되었을 때 배포되는 것이 맞습니다. 현재 action 설계가 잘못된 것 같습니다.

⇒ 깃허브를 관리하기 쉬워집니다. 이번 일 같은 conflict가 나오지 않습니다.

⇒ 둘이 유사합니다. 차이점이 있다면 모노레포는 각 폴더가 하나의 서비스가 된다는 것입니다.

⇒ 지금과 같이 서비스를 나눌 목적이었다면, 모노레포 관리 전략을 찾아봤으면 좋았겠습니다.

⇒ 아마 main 브랜치만 볼 것 같습니다. 브랜치 전략에 대해 그림이나 설명을 넣어두는게 좋을 것 같습니다.

• 지금 저희 코드가 문제인건지 하드웨어가 부족한건지 모르겠습니다.

⇒ 하드웨어 문제는 아닌 것 같습니다. 로컬에서 돌려보면 좋을 것 같습니다.

• 초당 request 300도 못버티는데 이게 맞을까요.

⇒ 연산을 빼버리고 스프링에서 Hello world를 찍는 것만 돌려서 확인해보면 현재 코드 성능 기준을 확인해볼 수 있을 것 같습니다.

⇒ 아무 것도 없는 Spring, 내 로직이 있는 Spring, 다른 프레임워크를 비교해봐야 제대로 비교할 수 있을 것 같습니다.

⇒ 원래 프로젝트 상황에서 탈주하는 사람이 많습니다.

• 자괴감이 많이 들고 쉽지 않았습니다. 복잡미묘하네요.
• 내가 아직 아무 것도 모른다는 생각이 많이 들었습니다. 일로 하는 개발에 대해 많이 느끼지 않았나 싶습니다. 비행기 날개를 갈아끼우는 느낌이 뭔지 알 것 같았습니다. ⇒ 장기간 프로젝트를 해본 경우는 많지 않으니, 귀한 경험 같습니다.

⇒ 부스트캠프는 수질 검사를 하고 뽑았기 때문에 탈주가 적지 않았나 싶습니다.

• 많은 걸 배우고 많은 걸 느꼈습니다.

• 부트캠프를 한 번 했어서 별로 큰 차이가 없습니다. 그런데 처음에는 욕심 없이 시작했는데, 점점 욕심이 생겨서 재미있게 할 수 있었습니다.

  ⇒ 맞아요. 재미있어야 할 수 있을겁니다. 회사에서도 마찬가지일거에요. 하고 싶은 일이 보인다면 적극적으로 어필하는게 좋다고 생각합니다. 그리고 그런 사람을 다들 더 좋아할 겁니다.

❓ 멘토님은 이 질문을 통해 저희의 무엇을 이해하고 싶으신가요?

⇒ 팀프로젝트는 6주이고, 풀타임이니 개발에 대한 생각에 변화가 궁금해서 여쭤봤습니다. 그 이전까지는 개발에 몰입할 수 있는 시간은 없었을테니, 온전히 개발에 몰입했을 때 무엇을 느꼈는지 회고할 수 있도록 질문을 드렸습니다.

⇒ 프로젝트를 시작할 때에 비해서 다들 한 단계 스텝업을 한 것 같아서 다행입니다. 멘토링의 성과와 줄 수 있는게 있어서 다행이라고 생각했습니다. 이게 끝나면 대부분의 사람들이 부스트캠프라는 보호막 안에 있다가, 보호막이 없는 채용시장에 던져질거라는 걱정이 있었습니다. 누군가는 탈주할 수 있었을텐데, 끝까지 마무리를 하게되어 좋습니다.

⇒ 회사에 궁금한 걸 물어보고, 인사담당자에게 약간의 어필을 하고 오면 됩니다.

⇒ 글로벌로 넘어가세요.

⇒ 신입 때 별로 의미 없는 것 같습니다. 코드없는 기여는 의미없다고 생각합니다. 오타나 번역으로 참여해도 큰 도움이 되지 않습니다. 내가 쓰는 오픈소스나 관심있는 오픈소스에 참여하세요.