1/23 (화) Talk - 요약 (1)

2차 팀 리뷰

팀의 목표, 방향성

• 다들 원하는 게 비슷했다.

• 각자 하고 싶은 것들을 모았음.
• 각자의 프로젝트 목표를 받았음.
• ex 호민) 도구를 적게 쓰고, 직접 만들어보기.
• 각자의 주제를 받았음.
• ex 호민) 내 아이디어는 선택 받지 못 했음.

• “어려운 목표에 도전” vs “기술 학습” → 다수결로 결정함

• 사용자 유치하기 → (지속적인 유지보수가 필요할 듯)

• 학습 목표 vs 자소서에 쓸 만한 →

• 주제: 각자 가져와서 구현 가능성 높은 것 고름

2차팀 기술 스택

기본 기술 스택 사용 경험

선호 기술 스택

제안

Next.js 도입해보자

• next 10%, react 10%, next 20%, react 20%, … 느낌으로 가는 게 좋겠다

3차 팀 목표 논의

프로젝트 완성도: 기술 학습 vs 포트폴리오

• 기술 학습 = 필수 기능만 구현

• 포트폴리오 = 완성도 있는
• 진아) 트러블 슈팅 경험
• 성빈) 사용성을 높이기 위한 복잡도 있는 구현
• e.g. 직관적인 표현을 위해 d3 같은 low level 도구를 사용해 시각화
• e.g. 차트 라이브러리의 단순한 차트가 아닌, 지도에 숫자를 표시하는 등
• e.g. 폼 UX를 위해 수동으로 갱신하는 게 아닌 연동되어 자동 갱신되는 필드
• e.g. 전체 예산 분배 폼
• Validation 시 타 필드를 입력으로 해야 하고,
• Update 시 타 필드를 갱신해야 함

• 성빈) (placeholder)

• 호민) (placeholder)
• 러닝 커브 부담은 적다.
• 완성을 못하는 일은 피하고 싶다.

• 희라) (placeholder)
• 러닝 커브 부담은 적다.
• 일정 상 수동 테스트를 할 시간이 많이 필요하다고 느꼈다.
• 일정 관리가 뒷받침되면 공통 컴포넌트는 결론적으로는 좋은 접근이라고 생각한다.

• 진아) (placeholder)
• 러닝 커브 부담이 있다.
• 성빈) 어떻게 할 지 모르겠다면 비슷한 코드에서 시작하면 난도가 크게 낮아진다.

개발 방법론: Waterfall vs Iterative

• 성빈) Iterative 하게 진행해야 한다.
• 빨리 개발하는 게 결과가 빨리 나오고,
• 구체적인 걸 보면 해야 될 것이 식별이 된다.

• 호민) 백엔드도 있어서 좀 진행해봐야 할 것 같다
• 일단 빨리 만들어놓고 리팩토링하고 버그 잡는 게 큰 도움이 됐다
• 버그 eg) 좋아요광클하면서버터짐

• 희라) (placeholder)

• 진아) (placeholder)
• 좀 갠플 위주로 했다.

리뷰 방식

• 성빈) 리뷰 내용은 크게 나누면 (1) 동작이 잘 되는가, (2) 코드 퀄리티
• Iterative 하게 개발할 때 초반에는 퀄리티 리뷰를 생략하는 게 맞다.

• 호민) 리뷰를 안 할 순 없다.

• 희라) 리뷰가 오래 걸리더라도 생략할 수는 없다.
• GitHub 포트폴리오 평가 시 Commit 작성 단위와 PR을 많이 보기 때문이다.

• 진아) (placeholder)

역할 정의 및 분배

• 성빈) 역할 자체가 필요하지 않다고 생각한다.
• 유의미한 역할의 의미가 없던 것 같다.
• 내가 커피챗 회의록 작성했는데 이 역할은 꽤 가치 있었다.
• 이전 팀엔 없었지만, 일정 관리 담당이 있으면 매우 좋다고 생각한다.

• 호민)
• 팀장, 일정관리1, 디자인1, 기록1, 기술1

• 희라) (placeholder)

• 진아) (placeholder)
• 이전 팀에서는 커피챗 일정 잡기, 일정 리마인드, 스크럼 MC, 회의록 서기가 있었다.

개발 시작 시점: 디자인 확정 후 vs 와이어프레임 확정 후

• 성빈) 스펙을 충분히 명세할 수 있는 수준의 low-fi 와이어프레임 선에서 끝내야 한다.
• 디자인이 개발의 병목이 되어선 안 된다고 생각한다. 나중에 바꾸기 어렵지 않다고 생각한다.
• 당연하게도, 하루, 이틀 내에 이상적인 디자인을 완성할 수 있다면 전자가 좋다.

• 호민) (placeholder)
• 2차 팀에서는 디자인이 병목이 되지 않았다. 한 분이 이틀 만에 디자인을 다 했기 때문이다.
• 고수가 없으면 시간이 얼마나 걸릴지 걱정은 된다.

• 희라) 적어도 충분히 구체적인 와이어프레임이 필요하다.
• 2차 팀에서는 디자인이 병목이 되지 않았다.
• 디자인 정의가 없이 간다면 일관되지 않은 UI로 개발하게 되고, 마지막에 일관된 UI를 만들기에는 작업량이 크고 놓칠 것 같다.

• 진아) (placeholder)
• 2차 팀에서는 디자인이 병목이 되지 않았다.
• 각 페이지를 맡아 함께 디자인을 했다. 한 분이 일관성을 잡아줬다. 오래 걸리지 않았다.

작업 범위 설정: 큰 범위만 vs 세부적인 스펙까지

• 세부적인 스펙 = 겹칠 수 있는 부분은 코드 단위로 구현 방식을 협의하고 들어가기

• 성빈) 호민님 의견과 비슷

• 호민) 페이지 별로 나눴음. 구현 속도가 다르니 다른 분들의 세부적인 스펙을 끌어다 작업했다.
• 기획을 얼마나 꼼꼼하게 하느냐에 따라 다름

• 희라) (placeholder)

• 진아) 얘기를 하면 좋을 것 같긴 하다.

작업 순서: 컴포넌트 우선 vs 페이지 우선

• 성빈) primitive가 모두 있는 ui framework 사용했다.

• 진아, 호민, 희라) primitive부터 처음부터 만들었다.

• 호민) (placeholder)
• 했는데, 계속 수정하지 않았냐?
• 공통 컴포넌트가 없이 시작하면 버튼 같은 기본 컴포넌트부터 중복이 발생해 비효율적이다.

• 성빈) ui framework 써서 문제가 없었다.

• 희라) (placeholder)
• 2차 팀에선 오히려 디자인 시스템 만드는 게 목표였다.
• 공통 컴포넌트 단에서 어떻게 쓸지 예상하고 기능을 집어넣었다
• 작업 들어가지 전에 공통 컴포넌트를 추출했다.
• 컴포넌트 구현이 끝나고 페이지 구현에 들어갔다.
• 컴포넌트 구현이 페이지 구현의 병목이지만
• 페이지 구현의 효율성은 매우 높았다.

• 진아) (placeholder)

작업 현황 추적 및 관리

• 성빈) (placeholder)
• 작업 추적 관리는 매우 필요하다고 생각한다.

• 호민) (placeholder)
• 2차 팀에서는 회의를 많이 했다
• 각자 구현하는 건데, 이 사람들이 무슨 작업을 하는지 공유가 잘 안돼서
• 어떤 업무를 진행하고 있는지 파악하고 있어야 관리가 되어서 회의를 많이 했음.
• 서로의 작업 현황을 알아야 누가 할지 스케줄링할 수 있다
• 주간으로 스프린트 작성
• Task 전/후에 완성이 가능한지 지속적으로 트래킹
• 효과적인데 비용도 많이 든다.

• 희라) (placeholder)
• 2차 팀에서는 스프린트를 한다고 했지만 안 했다. 일정 관리가 아쉬웠다.
• 스프린트 회고를 안 하니 계속 미뤄졌다.
• 좀 많이 필요하다고 생각한다.

• 진아) (placeholder)
• 2차 팀에서는 3,4 일에 한 번씩 스프린트 진행했다.
• 하루 날 잡아서 PR 올리고 리뷰했다.
• 11시까지 코드 리뷰하고 고치고 병합했다.
• 이 방식이 꽤 괜찮았다.

데일리 스크럼의 기능

• 성빈) (placeholder)
• 2차 팀에서는 시작할 때, 끝날 때 머할지 머했는지 공유했다.

• 호민) (placeholder)
• 2차 팀에서는 daily scurm 했다.
• 오전, 오후로 2번 했다.

• 희라) (placeholder)
• 2차 팀에서는 결정 사항, 문제 해결하는 시간 가졌다.

• 진아) (placeholder)
• 2차 팀에서는 open, closing scrum에서 진행 상황, 이슈 얘기했음. 짧은 스프린트 좋았다.
• PR, code review 는 평소에도 했다.
• merge는 스프린트 날에만 했다.
• 한 분이 화면 공유하면서 같이 QA했다.

Storybook 사용

• 성빈) 컴포넌트 우선 개발 시에는 매우 좋을 거 같은데 그게 아니면 쓸 필요 없을 것 같다.

• 호민) (placeholder)
• 2차 팀에서 도입하지는 않았다.
• 시간이 많이 잡아먹힐 우려가 있다.
• 명확한 세팅을 해오면 괜찮을 것 같다.

• 희라) (placeholder)
• 2차 팀에선 Storybook 좋았다.
• 스토리북에 env 배포 이슈가 있었다.

• 진아) (placeholder)
• 2차 팀에선 시간 우려 때문에 사용하지 않았다.