프로젝트 관련 Q&A

Q1. 진행한 프로젝트를 핵심만 담아 간략하게 설명해주세요. (30초 이내-5문장?)

• CheQuiz는 ‘개발지식 점검 서비스’ 입니다. 개발관련 퀴즈세트를 자유롭게 풀어보고, 나아가 문제를 출제할 수 있는 서비스입니다. 코딩테스트 이외의 개발지식을 정량적으로 측정할 수 있는 서비스가 없다는 문제를 해결하고자 하였고, 특정 주제에 대해 퀴즈를 맞추며 해당 지식에 대한 이해도를 정량적으로 측정할 수 있습니다. 공부의 재미를 주기 위하여, 2d 캐릭터와 경험치 제도를 통해 문제를 맞출 수록 성장하는 게임요소를 도입한 것도 하나의 특징입니다.
• 코딩테스트 이외의 개발 지식, 게임적 특성 → 프로젝트 point
• 제일 앞 부분 + 기간이랑 사람 수를 넣어주면 좋을 것 같다. (어땠어요? 호 불호?)
• 뒷 부분: 주요기능은 ~고, 저는 ~것을 담당했습니다.
• 면접관이 다음 질문을 편하게 할 수 있어서 흐름상 좋다고 생각

• CHEQUIZ는 퀴즈를 통해 개발 지식을 측정할 수 있는 서비스입니다. 개발 관련 퀴즈들을 해결하고, 문제를 직접 만들면서 해당 지식을 알고 있는지 체크를 할 수 있도록 하였습니다. 또 게임적인 특징들을 서비스에 반영하여 퀴즈를 풀면서 재미를 느낄 수 있고, 개발자가 성장도를 정량적으로 확인할 수 있도록 하였습니다. + 내가 담당한 부분 (퀴즈 풀기, 퀴즈 해결 후 결과 페이지)
• 확실히 아는 서비스인데, 강약?이 없다보니 확 포인트 캐치가 안되는 느낌?
• 레벨 시스템 + 경험치를 도입했다는 내용이 들어가면 좋을 듯

• <러북>은 여러 책의 인상깊은 문구를 보고 취향에 맞는 책을 고를 수 있는 독서 공유 서비스입니다. 어떤 내용의 책을 읽고는 싶지만 특정한 책을 고르기 힘들때, 문구를 먼저 보고 자신이 끌리는 책을 고를 수 있습니다. 많은 사이트에서 책을 검색할 때 책 제목을 검색해서 들어가야만 문구를 확인해야하는데 그런 번거로움을 줄일 수 있다는 장점이 있습니다.. 평소 책에 관심은 있지만 어떤 책을 읽으면 좋을지 모르던 사람, 또 서로 흥미있는 분야에 대해 의미있는 대화를 나누어보고 싶은 사람들 모두에게 도움을 줄 수 있습니다.
• 약간 ppt 발표 느낌
• ~~를 목적으로 만들었다.

• <러북>은 책을 좋아하는 사람들이 모여 자신이 읽은 책을 서로 공유하는 독서 커뮤니티 플랫폼이에요. 유저들은 본인이 읽은 책을 ‘문구’를 통해 공유하고 게시물 안에서 댓글을 통해 해당 책에 관해 서로 소통할 수 있어요. 단순히 책에 대한 정보를 공유하는 것보다 책을 읽고 자신이 느낀 점, 인상깊은 구절을 공유하면서 그 책을 모르던 유저도 책을 읽고 싶게끔 만들어서 책에 대한 접근성을 향상 시킬 수 있는 플랫폼이 될 수 있어요.
• 깔끔
• 개발관련 1줄이 들어가면 좋을 듯.

피드백

• 해당 질문은 더 가볍게 던질 가능성이 높다.
• 짧고 간결한 1~2줄이 더 좋을 것 같다는 생각도 든다.

Q2. 해당 스택은 왜 사용하게 되었나요?

• CheQuiz
• typescript, React, ContextAPI, emotion, webpack
• Slack, github(Zenhub)

• Luvook
• 개발: React, ContextAPI, emotion, storybook
• 커뮤니케이션: Notion, Discord, Slack
 

• React
• 커뮤니티가 많아 자료를 찾기 쉬운 장점이 있습니다.
• 요것만 말하면 위험하다.
• vue와 달리 view만 담당하다보니 다른 라이브러리와 결합이 유연하다.
• 다른 라이브러리를 많이 사용했다는 건데? 그럼 뭘 썼냐? 그거 vue에서는 안되나
• 위험해!!!! → deprecated
• 프로젝트 기간이 2주였고 팀원들 대부분이 react에 익숙해서 빠른 생산성이 요구되었습니다.
• React, Vue 중 고민 → React가 주력이자, 빠른 생산성 가능하기 때문에 선택

• Context API
• 인: 다른 상태관리 라이브러리의 도입을 고민했지만, 가장 row한 방식의 ContextAPI를 사용하면서, 해당 상태관리 라이브러리에서 처리하지 못하는 문제를 발견했을 때, 이를 해결할 수 있는 라이브러리의 도입을 고민해보자고 생각했다.
• Redux와 고민해보았지만, 생각보다 전역으로 관리하는 데이터가 많지 않았다. 그에 비해 사전에 작성해야 하는 코드 양이 많기 때문에 현재 도입하는 것이 너무 과하다고 생각했다. 해당 부분은 추후 Redux로 대체하는 것이 쉽기 때문에 일단은 ContextAPI를 사용하기로 결정했다.
• redux와 contextAPI 중 고민했지만 Redux가 context API 기반으로 만들어 졌고 데브코스 기간 중 context api로 실습을 배웠기 때문에 2주안에 프로젝트를 완성시키기 위해 사용 (+ redux 공부 시간 줄이기, + 프로젝트 규모가 별로 크지 않음)
• 동영say : 기술스택은 얼만큼 깊이 있게 이해하고 사용했는가 point 따라서 ContextAPI가 주로 마주치게 되는 성능문제를 파악했는지, 어떻게 해결할 수 있는지 까지 언급해주는 것이 best
• 구체적으로 프로바이더가 감싸고 있는 컴포넌트들이 내부적으로 몇 번 렌더링 되는지, 찍어봤는지 물어볼 수도 있다.
• Context 분리 하였는지 (context의 성능을 향상시키기 위한 한가지패턴- 링크🔗)
• state / dispatch → context 2가지 분리
• 하나의 AuthProvider → 상태제공 Context와 상태조작하는 Context로 구분
• 상태관리 최적화 관점에서 reactive programming (rx)
• Q. reactive programming이 react나 vue에 활용되는 예제를 말씀해주세요.

• emotion
Q. 스타일드컴포넌트 왜 사용하셨나요? 사용했을 때 느낀 장점이나 문제가 있었나요?
• className 안써도 되서 → 이거 고민하는 것도 시간적 비용이 큼
• 가독성 측면에서 더 장점이 있다고 생각
• S라는 별도의 네임스페이스를 주어, 함수컴포넌트와 스타일드컴포넌트와 구분했다.
• S.Container
• 해당 컴포넌트에서만 스타일을 정의하여 사이드 이펙트 확률이 적어지고 className이 자동으로 부여되기 때문에 스타일이 겹치지 않고 props 등에 따라 스타일 지정 가능
• 여러가지 컴포넌트가 필요한 상황에서 간단한 컴포넌트들을 빠르게 만들어 낼 수 있다. 여러 곳에서 사용되는 컴포넌트를 가장 기본적인 형태로 만들어놓고 재사용하면서 팀적으로 공통된 컴포넌트 스타일링을 정할 수 있었다.
• emotion 사용시 좋았던 점(장점)
• props 전달 → 다이나믹 스타일 적용 가능
• 따로 파일 안찾고 태그보고서 바로 스타일 확인 가능 했던 부분
• emotion 단점
• babel config를 따로 설정해주어야 하는 단점이 있다
• styled-components랑 비교해서 문법상 불편한 점이 있었다.
code사례 (해결완료-emotion도 가능)

import { Input } from ...

const LoginInput = styled(Input)`
  input.className {
		
	}
`

const Component = styled.div`
	${Input} {
		display: flex;
		...
	}

styled-components 과 emotion, 도대체 차이가 뭔가? (velog.io)
• 동영say
• 제어의 역전 (Inversion of Control) U know? 추가로 찾아서 달아주삼 → 저희팀원에게

동영쓰 답변

• 팀원들에게 설득해보았다. → ~~ 장점을 많이 느꼈다. (공부하면서 보일러플레이트 만듬)
• 능동적인 모습을 보여질 수 있는 포인트

• 인수
: fact의 나열보다는 넓게 던진다면, 인상깊었던 부분 혹은 느낀점을 위주로 말하면 더 몰입될 듯
• 어느정도 과장?story?가 필요할 듯
• 동의합니다
• 좋아요~소개팅 - 매력적인 소재를 던지기 위해 노력, 순발력

Q3. 해당 프로젝트에서 본인이 맡은 역할과 수행한 부분에 대해서 말씀해주세요.

• 기술적 : 자기가 담당한 기능이 ~~~ 했는데, ~~.

• 커뮤니케이션 : ~~ 어떠한 소통 이슈가 있었는데, ~~ 극복하고자 했고, ~~ 효과를 본 것 같다.
• 이게 스토리 만들어내야해요.
• 완전 거짓말은 아니지만, 어느정도 뭔가.
• [chequiz] - 프로젝트 후 리팩토링 확정, 화이트보드 도입, 리뷰시간 고정 (리뷰올라오면 현재 작업 중 작업 최대한 마무리 하고, 30분 이내 리뷰 남기도록), 이슈있을 때 마다 마이크키고 소통하기, 스크럼 종료 전 남아있는 PR 리뷰
• 각색 중간 KPT 회고 결정
• 동기적 커뮤니케이션
• 회고록
• [luvook] - 프로젝트 시 ~~ 어려움이 있었고 극복하려고 했던 시도를 했다.
• 팀장(팀장의 무게,책임감)
• 1.각색 레퍼토리 ( 중간 시도해서 마지막 변화된 병아리)
• 2. 프로젝트 여러 역할에 대한 어려움 / 개선방안 제시
• 일정 관리, 프로젝트 개발 세팅, 팀 프로젝트를 해본 팀원이 없었음
• 개선방향
• 중간회고록
• 최종회고록

• [chequiz]
• 준혁:
• 퀴즈를 푸는 페이지와 풀고나서 결과를 출력해주는 페이지를 담당했다.
• 퀴즈 결과를 보는 페이지 디자인 상, 토글 버튼을 누르면 댓글과 해설을 볼 수 있는 영역이 애니메이션으로 노출이되야 함
• 그러나 각 컴포넌트의 height(댓글의 개수가 유동적)이 유동적이기 때문에 쉽게 height option을 주어 animation을 주기가 어려웠다
• max-height 옵션으로 transition 효과를 줄 수 있는 방식도 있었는데, max-height를 넉넉하게 2000px을 주면 2000px / 시간에 맞는 애니메이션 속도를 가져 height이 작은 컴포넌트들은 애니메이션이 굉장히 어색해 보이는 문제가 있었음
• 해당 부분을 해결하고자 auto-height이라는 리액트 라이브러리를 도입
• QuizResult 동적페이지 구성
• 인수:
• 퀴즈 생성 페이지를 담당
• 제어 컴포넌트/ 비제어컴포넌트 기준 어려움

• [luvook]
• 수경: 소개팅,,
• 순서바꾸면 좋겠다( 이슈 → 절차 )
• 인증 절차가 잇는 부분을 진행 할 때 바로 전에 로그인햇던 사용자의 정보가 나오는 이슈가 있었다. → 호출 부분, context부터, api까지 디버깅 해봄
• → 해결은 interceptor 도입
• axios 인스턴스를 사용할 때
• 인증이 필요없는 인스턴스
• 인증이 필요한 인스턴스를 나누어 api를 모두 연동을 시켰습니다
• context와 연결하면서 사용자 인증 여부를 context에서 확인을 하는데 인증 절차가 잇는 부분을 진행 할 때 바로 전에 로그인햇던 사용자의 정보가 나오는 이슈
• 인스턴스를 생성할 때 토큰을 넣는 방식으로 진행했던 부분이 잘못되었다.
• axios interceptor 도입해서 토큰을 새로 가져올 수 있도록 했습니다.

Q4. 진행하면서 가장 어려웠던 점과 어떻게 극복하려고 했는지 설명해주세요.

• 두 가지 개념을 구분해서 처리

• 인: 커뮤니케이션과 프로젝트 관리 측면, 개발측면(form 처리)

• 4

Q5. 프로젝트의 부족한 점이 있다면? (시간이 주어진다면 어떻게 리팩토링 하고 싶은지)

• 인: 리팩토링 관점(가독성 + server), 기능추가 관련,

• 준혁:
• 기술적: 공통적인 디자인 시스템 부재, 중복되는 부분이 다수 존재

• 러북
• 기술적: 1. 버그 Fix 2. 컴포넌트 분리 3.