HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
🧚
[1기]최종 프로젝트 데브코스
/
🍸
[팀15] ShakeNMatch
/
🏸
15조 2주차 프로젝트 진행 현황 (~14일)
15조 2주차 프로젝트 진행 현황 (~14일)
🏸

15조 2주차 프로젝트 진행 현황 (~14일)

Status
기획 + 요구사항
Assign
속성
💥주요
속성 1
🍙 2주차 주요 이벤트: 2021-12-12(일) 오후 4시, 조규현 멘토님과의 커피챗전반적인 코멘트멘토님의 지라 사용에 대한 조언추가적인 조언🍟 프론트▶ 스프린트 진행 상황▶ 구현 사진 첨부 (후훗...)🍞 백엔드▶ 스프린트 진행 상황🍟 DB 관련칵테일/재료 DB 작성 작업을 진행🥙 중간 회고록

🍙 2주차 주요 이벤트: 2021-12-12(일) 오후 4시, 조규현 멘토님과의 커피챗

notion image
조규현 멘토님과의 커피챗을 통해서, 15조의 현재 프로젝트 진척 상황에 대한 전반적인 코멘트를 받았으며, 협업과 관련한 조언을 받았다. 멘토께서 코멘트 해주신 내용을 간단히 정리하자면 아래와 같다.

전반적인 코멘트

  • 프론트와 백엔드가 배포를 빨리 진행해서, 배포 환경에서 개발을 진행하는 것이 좋을 듯 하다.
    • → 이에, 프론트는 12월 13일 (월) 중으로 Vercel을 통해 배포를 먼저 진행하려 한다.
  • 지라를 잘 활용을 못하고 있어서, 서로가 어떤 작업을 하고 있는지 모르는 상태이다.

멘토님의 지라 사용에 대한 조언

  • 최대한 티켓의 코멘트 기능을 많이 이용하면 좋다.
  • 개인이 진행중인 이슈가 2개, 혹은 그 이상인 인원들이 있다. 일반적인 경우에 인원 당 '진행 중' 이슈는 하나가 있어야 할 것 같다. 사람은 한 가지 일밖에 못 하기 때문에.
  • 이슈를 생성하면, 슬랙에도 알림이 가도록 Integeration 기능을 사용하는 것이 좋다.
    • →현재 메일과 연동을 해 놓은 상태이다. 이슈가 생성되면 메일이 온다.
  • Epic 기능을 사용해서 어떤 기능을 집중적으로 구현을 해야 할 지에 대해서 모르는 것 같다. Epic 단위를 지정해보자.
    • → 이제껏 우리는 Epic을 '프론트', '백엔드'로 뭉뚱그려서 설정했었다. 멘토님의 코멘트를 듣고 나서는 앞으로 우리 팀이 3주차에 진행하게 될 API 연동에 초점을 두어, API Epic을 생성해 두고 해당 에픽에 필요한 백로그를 생성해 둔 상태이다.
      → 기존에는 API 관련 논의가 있을 때, 7명 전원이 모여서 살펴봤으나, 이제는 도메인을 분류하여 각자 담당자를 두고, 프론트 담당자와 백엔드 담당자가 1:1로 소통하며 업무를 진행하는 것으로 합의했다.
  • 규현&지은님의 협업 가이드 를 보면서 감을 잡아 보자.
  • 지라의 Workflow 를 세부적으로 나누자
    • → 팀 회의 결과, 현재 워크 플로우를 변경하는 것은 시기 적절하지 않다고 판단, 현재 워크 플로우는 동결하기로 하였다.
  • Story Point 를 작성해서 작업의 대략 완료 시간대를 결정할 수 있다. 포인트에 대응되는 시간 단위를 커스텀으로 설정해 놓을 수 있다. 이것 없이 계획을 짜면, 기능의 대략적인 예상 개발 기간을 산정할 수도 있다.
    • 스토리 포인트를 기반으로 스크럼을 진행할 수 있다. 가령, 오늘은 A 작업을 할 것입니다. 왜냐하면 A 작업의 story point 는 5포인트(5시간) 인데, 오늘 주어진 시간이 5시간 밖에 없기 때문입니다.
      • → 이에 우리 팀은 스토리 포인트 1점을 2시간으로 설정하여 각각 도맡은 이슈들에 대한 스토리 포인트를 명시하기로 했다.
  • 에픽 기능은 프론트, 백엔드와 같이 큰 업무 분담을 하는 곳이 아니다.

추가적인 조언

  • 깃에 쓸모없는 커밋이 있지 않은지에 살펴보고, squash 하거나 rebase를 진행하는 것을 날을 잡아서 정리하는 것을 추천한다.
  • API 자동으로 관리해주는 툴에 대해서 Swagger 로 관리하도록 백엔드에서 준비 중이다.
  • 서로가 상대방의 작업을 조금 기다리는 동안, 각자 영역을 리팩토링 하는 것이 좋을 것 같다
  • 변화가 잦을 수 있다는 것을 기억 해주었으면 좋겠다

🍟 프론트

💡
1주차에 작성한 베이스, 컴파운드 컴포넌트를 기반으로 더 복잡한 로직의 도메인과 페이지 컴포넌트들을 제작하는 주였다. - 복잡한 로직이 들어가고, 디자인을 맞추어 스타일도 세세하게 작성해야 했던 까닭에, 각자의 개발 속도의 차이를 확연히 확인할 수 있었던 주였다. - 각자의 속도와 능력치에 맞는 이슈를 생성하고 할당받아 개발을 진행했다. - 개발 속도의 차이로 인해 프로젝트 코드에 대한 이해도에 차이가 나는 것을 방지하기 위해서, 또 더 완성도 있는 컴포넌트 제작을 위해서 코드리뷰를 최대한 엄격하게 시행하였다. - 그 결과 머지가 조금 늦어지긴 했지만, 컴포넌트의 완성도는 높아진 느낌이다.

▶ 스프린트 진행 상황

notion image

▶ 구현 사진 첨부 (후훗...)

notion image
 

🍞 백엔드

▶ 스프린트 진행 상황

백엔드
 
 

🍟 DB 관련

칵테일/재료 DB 작성 작업을 진행

1주차에는 우리가 사용할 데이터들의 형태와 API들에 대한 명세를 했다면, 2주차에서는 이 명세에 따라 데이터들을 구체적으로 수집하여 DB화 하는 작업을 진행했다.
엑셀 표를 프론트와 백엔드가 함께 살펴보며, 데이터 테이블을 채워나갔다. 또한, 실제 데이터를 채우면서 발생할 수 있는 문제에 관하여 긴 논의를 진행하였고, 합의에 도달하였다.
  • SQL에서는 배열 타입이 없는 까닭에, 엑셀에 배열 형태로 작성했던 데이터들을 string 형식으로 서버에 저장하고, 받을 때는 JSON으로 받기로 합의를 했다.
  • 칵테일 레시피에 사용된 재료들을 따로 정리하여 Ingredient 도메인을 위한 DB도 작성하였다.
  • 앞의 두 테이블을 기반으로 바로 서버에 데이터를 입력할 수 있도록 SQL문을 작성했다.
notion image
notion image
notion image

🥙 중간 회고록

KTP 회고 방식으로 중간 회고를 진행해 보면 좋을 것 같습니다.
KTP 회고란 무엇인가?
 
Copy of 중간 회고록
Name
Keep (현재 만족하고 있는 부분, 계속 이어가고 싶은 부분, 진행하고 잘 하고 있는 점)
Problem (개선이 필요한 점,잘 못하고 있거나 문제를 겪고 있는 점)
Try (Problem에 대한 해결책, 당장 실행할 수 있는 것들)
승록
- 이번에는 프로젝트 관리 툴로 GithubProjects가 아닌 Jira를 사용헀다. 처음에는 이것저것 연동해야 하고, 사용법도 아직 온전히 익숙치는 않지만, 그래도 차근차근 지라에 익숙해져 가고있다. -컴포넌트 제작은 언제나 마음이 두근거리는 작업이다. 대단한 기능을 가진 컴포넌트는 작은 기능을 가진 컴포넌트들이 유기적으로 모여서 구성되는 것임을 실제로 경험하고 있다. - 코드리뷰를 최대한 꼼꼼히 진행하려고 노력했다. 내 코드에만 매몰된다면 발전이 없음을 너무나도 잘 알기에, 코드리뷰에 신경을 썼다. - 진짜... 이번에 타입스크립트로 리액트 개발을 하게 될 줄은 몰랐다. 자바스크립트랑 리액트도 완벽하게 알지 못하는 내가 그래도 얼레벌레 컴포넌트를 작성하고 로직을 작성하고 있다는 점이 경이롭다. 후들거리는 다리로 다른 팀원들을 따라가려 노력하고 있다. - 가끔은 개발하기 싫고 침대 속에서 나오기 싫은 날이 있는데, 그런 날에는 '쇼핑'을 통해서 개발욕구를 증진시켰다. 그 결과, 지금 내 앞에는 '키크론 k2 적축' 키보드가 있고, 내 노트북에는 외장모니터 허브가 물려져 있다. 다 생산성을 높이기 위한 방법이라구....ㅠ
- 팀원들에게 우리 프로젝트의 전반적인 짜임새와 할 일들에 대해 이야기 나누자는 이야기를 잘 못 한 것 같다. 우리가 앞으로 무엇을 해야 할 지, 각자는 무엇을 해야 할 지에 대해서 명확하게 팀원들끼리 이야기를 나누기는 했지만, 어딘가 구멍이 숭숭 뚫려있는 느낌이었다. 명확하게 이에 대해 문서화를 진행하지 않았던 탓일까? 컴포넌트 설계는 진행을 했는데, 프로젝트 전반에 대해서 치밀하게 어떤 단계를 거치고, 어떤 설정을 해야 하는지에 대해 치밀하게 논의하여 문서화를 해 두지 않았던 것이 그 이유이지 않을까 생각이 든다. 그래서 개발 중에 '어, 맞아 우리 이런 설정 해 놓아야 하는데' 라는 말이 나왔던 것 같다. - RatingStart 컴포넌트 작성에서 너무 많은 자원을 쏟았다. IconToggle 컴포넌트가 아닌, IconButton을 사용해서 개발했으면 정말 5시간 미만으로 걸렸을 작업을 며칠을 쏟아서 고민했다. - 컴포넌트가 어디에서 상태값을 가져야 하는지, 다루는 데이터의 책임소재를 정확하게 산정하여 컴포넌트를 제작하는 것에 미숙하다.내 정신머리. 이번 주는 정신적으로 힘든 주였다. 집중하기가 어려웠다. 첫째는 그놈의 RatingStar 때문이고, 두번째는 개발 외적으로 신경써야 할 부분이 많다는 점이었다. 기록도 하고, 레포의 위키도 작성하고, 명세서도 작성하고, 회고도 작성하고, 어떻게 현업 개발자들은 개발도 하면서 문서화도 하고 블로그도 쓰는지 존경스러울 따름이다. - 코드리뷰를 꼼꼼히 진행하려 노력했지만, '모든 것은 등가교환'. 코드리뷰에 시간을 쏟는 만큼, 내 개발을 위한 시간이 부족해졌고, '그렇게까지 오래 코드리뷰를 한다고?' 라는 생각이 들었다면 '맞다'. 나는 아직 타인의 로직을 이해하는데 익숙하지 않나보다. - 컨디션 관리를 못했다. 감기로 인해 이틀 정도를 날렸다. 거의 매일같이 새벽 4-5시에 잠드는 것으로 인해 생활패턴이 깨진 것도 한 몫을 한 것 같다.
- 개발에 오래 걸릴 것 같은 작업은, 팀원들에게 좀 더 적극적으로 도움을 요청할 것이다. - 지라를 조금 더 적극적으로 활용할 것이다. 정말 좋은 툴인데, 익숙하지 않다는 이유로 너무 소극적으로 사용하고 있던 것은 아닌지 반성해 본다. - 개발이 재밌다. 재밌는데, 더 잘 하고 싶다. 그러려면 공부를 하고 더 많이 만들어봐야 한다. 그런데 그런 기분 있잖아요, 만들기가 두려워지는 기분. 이걸 만들기 시작하면 나는 끝을 봐야하는데, 너무 고통스러울 것 같아서 주저되는 기분. 그런 기분이 들 때는 어떻게 해야할지 모르겠다. - 컨디션 관리를 잘 하자. 적당히 늦게 일찍 자기!
사휘
- 조금 번거롭더라도 팀원들과 사전에 협의한 컨벤션을 최대한 지키고자 했다. - 낭비하는 시간 없이 가능한 대부분의 시간을 프로젝트에 쏟았다. - 개발 도중 모르는 내용이 나오면 그냥 넘어가지 않고, 간략하게나마 별도로 해당 내용을 정리했다.
- 구현에 급급하여, 계획했던 것만큼 코드의 질적인 측면을 충분하게 고민하지 못했다. - 점점 코드의 양이 늘어날 수록 팀원의 코드 리뷰에 시간을 충분히 투자하지 못했다. - 나를 포함하여 팀원들이 조금씩 놓지고 있는 규칙들이 눈에 보였음에도 불구하고, 이를 스크럼 때 이야기하여 신속하게 바로잡지 못했다. - 백엔드 팀원들의 진행 상황을 꾸준하게 파악하지 않았다. - JIRA를 더 연구하여 목적에 맞게 사용하지 않았다.
- 하루 단위로 내가 해야할 일을 보다 구체적으로 계획하고, 매일밤 어떤 내용이 해결되었고 어떤 내용을 보완해야할지 정리한다. - JIRA에서 프론트 업무뿐만이 아니라 백엔드의 업무도 주기적으로 체크한다. - 코드 구현을 시작하기 전에, 내가 만들고자 하는 것에 대해서 충분히 고민하는 시간을 갖는다.
무호
- 컨벤션을 꽤나 타이트하게 잡아가며 프로젝트를 진행하고 있고, 확실히 덕분에 더욱 정돈되고, 서로의 코드를 확인하는데 큰 문제를 못느끼고 있다 - 타입스크립트에 많이 익숙해졌다 - Github Wiki를 통해 내용을 정리하고 있으며 이번 프로젝트로 남을 큰 자원이 될것 같다.
- JIRA와 같은 협업툴을 제대로 활용하지 못했다. 특히 백엔드와의 소통창구로 잘 활용했어야 하는데, 그렇지 못했다 - 조금 더 체계적이게 프로젝트 진척을 진행했더라면 좋았을것 같다. 역할분담이나 분배 과정이 그리 매끄럽지 않아서 내가 무엇을 해야할지, 우리 팀은 무엇을 해야하는지가 명쾌하지 않았다.
- JIRA를 더욱 적극 사용하며, 이슈의 댓글을 통한 백엔드와의 소통을 진행한다. - 지금부터는 조금 더 체계적인 역할분담이 필요해보인다.
상혁
- 전반적인 개발 프로세스에 대해서 잘 알 수 있었고, 타입스크립트가 왜 필요한지, 어떠한 문법을 상황에 맞춰서 사용해야 하는지 알 수 있었다.
- 타입스크립트를 사용하는 것에 있어서 조금은 익숙해진 것 같지만, 처음에는 많은 시간이 걸렸었고 지금도 다른 팀원들에 비하면 상당한 시간이 걸리는 것 같다. - 프로젝트 이전에 개념을 학습하는 시간으로 많은 시간을 소요하였다. - 구체적으로 기한을 정해 놓아도 일정이 계속해서 뒤로 미뤄졌다.
- 개발을 시작하기 전에 불필요한 생각이 너무 많았던 것 같다. 당장 프로젝트 진척도를 위해서 나중에 리팩토링을 하더라도 구현 위주로 맡은 업무를 수행해야겠다.
상순
꾸준히 개발을 하고 있다는 것, 막 개발이 아닌 개발 방향에 대해서 고민하고 개발하는 것
생각보다 개발의 혼선이 있어 개발의 속도가 떨어진다.
우선순위 재설정 및 미비된 개발 부분 보완, 추가 개발 부분 확인해서 집중해서 개발하기
상원
협업개발에 대해 어떻게 해야하는지 알게 된 것 같다.
협업 시 지켜야 할 내용들을 문서화 및 정리를 안해둬서, 팀내 혼동이 와 협업개발에 불편을 초래했다.
문서화 및 스크럼 회의 및 개발 진척도 현황등으로, 현황파악 후 무엇을 이끌어나갈지 프로젝트 기간동안 확인해야 할 것 같다.
재욱
도메인 주도 개발을 통한 협업에 대해 조금 알게된 것 같다.
코딩컨벤션, 어노테이션 설정 등 초기에 말했던 약속이 잘 지켜지지 못 했다.
최종 refactoring을 통해 코딩 컨벤션을 통일시켜야겠다.