2️⃣ 2주차 멘토링 일지

개별 멘토링 기록

김동준 (J032)

이번 주 작업 내용

[FE] live-share를 사용한 페어 프로그래밍으로 페이지 목록 컴포넌트와 에디터 컴포넌트를 함께 구현하는 중입니다. 그러면서 프로젝트 설정, 코드 작성 스타일 등을 맞추고 있습니다.

프론트엔드 분업에 대한 고민

어제, 오늘에 거쳐서 아마 내일까지 페어 프로그래밍을 하게 될 것 같습니다. 어쩌면 분업에 대한 고민을 미루고 있다는 생각도 듭니다.. 서로 의존성이 있는 파일도 있다보니 스토리 단위로 분업 단위를 나누기가 힘든 것 같습니다. 함께 프론트엔드 작업을 하는 예원님과 작업 방식이 다행히 비슷해서 차라리 에픽 단위로 분업해서 동시에 진행하는게 더 나은 방식일지 고민이 됩니다.

같이 고민해봐야할 부분 / 고민이 들어가지 않는 부분을 나눠볼 필요성

비동기적인 개선 시 충돌에 대한 고민

작은 단위의 개선 PR을 계속해서 올리고 싶은데, 작은 코드베이스에서 2명이 함께 작업하다보니 충돌이 날 것 같아서 고민입니다. 특히, 서로의 리뷰가 있어야 머지가 되게 구성해 놓아서 pull만 하는게 아니라 PR까지 확인해야 하는 등 문제가 있습니다. 이렇게 비동기적으로 작업할 때 생길 수 있는 이슈들에 대한 좋은 해결방법이 있을까요?

작은 단위의 PR / 리뷰를 반복해서 수행
의도적으로 충돌을 내본 후 해결해보기

진도에 대한 욕심과 컨디션 조절에 대한 고민

그룹 프로젝트 전에는 짧은 기간 동안 집중해서 작업을 하고, 쉬는 기간을 갖는 방식으로 주로 진행을 했습니다. 그래서 마음같아서는 제가 며칠 밤을 새서라도 많은 것을 해두고 싶은데, 긴 기간 동안 진행하는 프로젝트이다보니 페이스를 계속 조절해야할 것 같아서 고민이 됩니다.

팀의 변수가 되는 건 좋지 않다
휴식/작업의 루틴화 (잘 쉬어야 한다.. 🥲)

김현준 (J075)

이번 주 작업 내용

팀: [FE] 개발환경 설정, 필요한 컴포넌트 작성 / [BE] CI&CD, 배포 환경 조성, 개발환경 설정, 기본 CRUD 작성
개인(~화): NestJS 초기 설정, TypeORM 연결, Config 모듈 설정 (환경변수) - 구현하기로 계획한 API를 나눠서 작업하고, 목요일에 배포 환경에서 합쳐볼 예정

설계 시 어디까지 고려해야 할까?

그래프같이 생긴 구조를 RDB로 모델링하기 위해 개인적으로도, 팀적으로도 많은 고민을 했었습니다.
이 과정에서 materialized path, closure table 과 같은 키워드도 공부해보고 다방면으로 생각해봤는데, 일단은 그래프 탐색같은 테크닉이 당장 필요하지는 않으니 간단하게 노드/엣지로 나누어 저장하자고 결론을 내리고 위와 같이 설계했습니다.
챌린지와 학습 스프린트를 거치면서 완벽한 설계는 없으니 빠르게 검증하자 는 쪽으로 마인드가 바뀌었는데, 그룹프로젝트를 하다보니 다시금 고민이 되기 시작했습니다.
기획할 때는 자꾸 기술적으로 구현 가능한가? 에 초점을 두게 되고, 개발/설계 할 때는 기획적으로 무언가 추가 되었을 때 바로 대응할 수 있는 구조인가? 에 초점을 두게 되니 악순환의 반복이라는 생각이 듭니다.
그룹 프로젝트다 보니 혼자서 검증할 수 있는 부분이 한정적이기도 하고, 그냥 진행했다가 설계 미스를 발견했을 때 팀적으로 짊어져야 하는 리스크 (시간 측면이라던지, 내가 팀 스케줄을 딜레이 시켰다는 심리적인 측면이라던지…) 가 걱정되기도 하는 것 같습니다. → 이렇게 적다보니까 생각을 너무 많이 하는 것 아닌가 하는 생각도 드네요 → ~~이것 조차도 생각이긴 한데~~
참고?: [BE 개발 스택 & 기술적 고민](https://www.notion.so/BE-846dd31d832545e482039559dd510b4f?pvs=21) (접근 권한이 있으신지 모르겠네요… 개발 스택에 대해 조사하고 고민했던 부분을 정리했던 문서입니다.)

엔지니어링 관점에서 풀기 주어진 시간이 생각보다 많지 않다 → 유연한 설계는 사실상 거의 불가능하지 않을까 기술적 도전을 위해 feature monster를 만들지 말자

협업, 잘하고 있는걸까?
- 사실 아직도 협업 이 무엇인지 잘 깨닫지 못했다는 생각이 듭니다. 분업 이랑 다른게 무엇인지 잘 모르겠습니다.
  - 하나의 목표를 위해 작업을 나누고 각자 책임을 다해 수행한 뒤 합친다 → 분업
  - 분업 중 지속적으로 의견을 교환한다? → 협업?
- 1주차 기획 후 2주차로 접어 들면서 모여서 회의 후, 각자 일감을 맡아 작업하고, 스크럼 때 공유하는 과정을 거쳤는데, 이게 적합한 일하는 방식 인가에 대한 고민이 있습니다.
- 일례로 위 ERD 설계 같은 경우는 제가 혼자 해보고, 스크럼 이후 BE 팀원들에게 공유하면서 같이 문제점을 생각해보자고 했었는데, 어찌 보면 이게 일방향 소통이 될 수 있지 않을까 생각했었습니다. (각자 차분히 고민해볼 시간도 부족했고, 제 설계가 각자의 사고 흐름을 막았을 수도 있기에)

웅덩이에 있는 물을 물통에 담는다면? 분업은 모여서 각자 웅덩이에서 물통에 담기 → 개인의 성과는 높지만 팀의 성과는 거의 없다 협업은 둘이 물을 옮기고 한 명은 물통에 담는다 → 함께 목표 달성을 위해 창의적인 해결 ”지식 전파와 공유”

공통된 팀의 목표 → 구체적으로 결정해야 한다 솔직한 개인의 목표와 욕구를 모아서 팀의 목표를 만들어야 한다 → 목표와 방향의 일치, 소통의 투명 → 설계의 유연함 토픽이 왜 나왔을까: 아직 목표가 확실하지 않으니까

민서진 (J097)

이번 주 작업 내용

- 팀: [FE] 개발환경 설정, 필요한 컴포넌트 작성 / [BE] CI&CD, 배포 환경 조성, 개발환경 설정, 기본 CRUD 작성
- 개인
    - (화): NCloud 초기 설정
    - (수): API 구현
        - 페이지, 노드 삭제
        - 페이지, 노드 추가
        - 페이지 업데이트

고민

협업방식이 처음, 어느 코드까지 건드려도 되는 걸까?

초반은 같은 코드를 건드릴 가능성이 높음
- PR을 짧게 여러번 남기기 → 작업단위를 짧게
- 짧은 주기로 리뷰 받기
- 수정한 부분이 텀이 짧아야 충돌을 수정하는 것이 쉽다
- 어떤 부분을 구현할지 따로 알려주기
- 파일 하나에 너무 많은 구현체들이 모여있는 것이 아닌가 고민해보기

협업

협업 그 자체
- 분업 → 굳이 소통 필요 X
- 협업을 하기 위해서는 목표와 방향 일치
  - 소통을 최대한 많이 해야함 : 내일 스크럼으로 미루지 말자
    - 얘기를 해야하는 일 자체가 또다른 일정
    - 애둘러서 말하지 않고 직접 얘기해서 소통해야한다
    - 지금 상태를 바로바로 공유하자
- 문서화
  - 사소한 것 조차도 문서화를 해야 나중에 협업에 도움이 된다
  - 가장 이상적인 상황은 문서화가 잘되어있어 FE에서도 파악 가능
  - 평가가 아니라 피드맥이 자주 이뤄줘야
  - 개인의 목표를 투명하게 드러내야된다
  - 부끄럽다 하더라도 끄집어내야한다
  - 개인의 목표를 모아서 팀의 목표를 정해야한다
    - 개인의 목표를 성취하기 위해 노력 → 팀의 목표 성취에 도움이 될 것
    - 이기적인 목표를 달성하기 위해서 최선을 다했을 때 팀의 목표를 정한다고 치면 그 이기적인 활동은 뭘까
    - 나의 목표: 프로젝트에 충분히 기여했다는 감정을 느낄 수 있게하기 - 배포 → 출시 - 일찍 배포하고 피드백을 받으면서 운영하기 - 적극적으로 의견을 내고 소통하기
    - 보완해야될 부분
      - 개개인이 생각하는 개개인 목표를 말해라
        
        개인의 목표가 살짝 상충한다
        
        나의 목표, 팀의 목표를 정의하고 서로 의사결정, 판단이 필요할 때 그 부분을 우선할 것
      - deploy → 사용자 피드백 부분은 좋다
        
        자잘한 feature보다는 핵심가치에 집중할것
      - 아직 팀이 그렇게까지 서로 소통이 되는 느낌이 아님
        
        협업에 방해될 수도 있다
        
        팀원들에게 설득해서 말하고 싶은데 무시당할 것 같다, 역량이 우스워보일 것 같다 등의 생각
        
        서로를 잘 몰라서 안정감이 낮은 상태라는 뜻
        
        상대방과 서로 좋은 관계여야 한다
        
        심리적 안정감을 높여야한다 ⇒ 분발할 것!!
      - 내가 push를 했더니 방해한다는 염려 → 서로 그냥 소통하면 되는 문제