🍰 [Main Project] 스프린트 2 회고

🌊 [Main Project] 스프린트 2 회고

스프린트 2 기간동안 내가 고려했던 것이 있는데 바로 아래 세 가지다. 이 세가지에 대해 회고하고자 한다.

• 웹 접근성
• Git 전략
• 공통 컴포넌트

 

웹 접근성

우린 스프린트 1 멘토링 때 멘토이신 준프님께서 웹 접근성에 대한 설명을 포함하여 내년부터는 법제화가 된다는 소식을 알려주셨는데, 사실 나는 웹 접근성에 대한 지식이 살짝은 있는 편이었다. 과거에 웹 접근성 PDF문서를 읽어본 적이 있고 처음에 HTML,CSS를 배울 때 웹접근성을 염두해두고 배웠기 때문에 배경색과 글자 색의 색상대비 4.5:1, 헤딩 태그 등, img에 alt값 넣어주기 등 부트캠프 기간 내에 교육과정에도 포함되어 있었고 회사 다닐 때도 접근성 심사를 통과해본 적이 있었기 때문에 알고 있었다.. 접근성.. 생각보다 어렵다는 것을..

 

헤딩 태그를 예로 들면 난 이게 제목이라 생각해서 부여했는데, 가끔씩 이게 제목이 맞나..? 싶을 때가 있었다. 대표적으로 리스트인데 나는 리스트 안에 있는 가계부명과 공유하는 유저도 리스트의 제목 중 일부라고 생각해서 각각 h2와 h3을 부여했었다.

 

 

근데 문제는 여기서 발생했다. 🧐 내 안에 찜찜함이“’가계부명’이 정말 제목이 맞아?”라고 질문을 던지는 것이었다.

왜냐면 “가계부명”이라는 이름 자체는 제목보다는 제목을 설명하는 요소, 라벨 느낌이라고 생각하였다. 그렇다면 공유하는 유저는 어떨까. 사실 우리는 공유하는 유저 아래에 유저 프로필 이미지를 출력하기로 하였다. 그럼 공유하는 유저는 유저 프로필 이미지 리스트의 제목이 맞는 것 같았다..

 

그래서 결론적으로 가계부명은 div, 실제 제목(햄구1의 가계부)는 h2, 공유하는 유저는 h3으로 수정하였다. 이것이 정답일까?🧐하는 의문은 남아있지만 현재 내게 이게 가장 납득되는 제목이었다..

 

이런 점들을 고려해서 하니까 평소에 코드를 치던 것보다 생각이 더 많아져서 시간이 오래 걸렸다. 처음부터 기본 습관으로 잡고 갔으면 수정하지 않았을 텐데 짧게 생각해서 어쩔 수 없이 시간이 들게 된 것이다. 이 점은 아쉽지만 내가 배워나간 점이고 앞으로도 고려하며 작성해야겠다.

 

 

Git 전략

이건 지금 우리 팀원 6명이 모두 고통 받았던 것이다.

우리는 멘토링 전에 git flow와 trunk 전략을 준프님께서 소개해주셨는데 Git 전략 중 trunk 전략을 사용해보기로 하였다.

 

예시는 feed 브랜치인데 feed 브랜치를 fe, be가 각 나눠서 작업해야할 경우엔 분기를 하지만 그렇지 않을 경우엔 기능 브랜치를 하나 만들어 바로바로 trunk에 merge 되는 방식이었다.

 

해당 방법에 대해선 아래에 잘 나와있다.

https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/

Git Flow에서 트렁크 기반 개발으로 나아가기 - 맘시터 기술블로그

 

근데 문제는 우리는 6명 전부 다 git이 미숙하다는 점이었다. trunk 방식은 git이 익숙한 사람이면 정말 빠르게 배포되는 좋은 방식이지만 우리 처럼 git과 개발을 배우고 있는 우리가 사용하게 되니 빨리빨리 main 브랜치에 merge가 되는 장점을 가지고 있는 trunk 방식과는 맞지 않는 일들이 생겼다.

• fe와 be의 개발속도가 각각 달라 어느 한 쪽이 개발 완료가 되어도 trunk로 merge 할 수 없음
• 빠른 merge가 장점인 trunk방식인데.. 우리의 속도가 느려서 전혀 빠르게 merge 되고 있지 않음

🥹 사실 전략의 문제보단.. 우리의 문제였다. 그리고 가장 중요한 이슈가 생겼는데 be에서 배포를 하려고 브랜치를 분리하였는데 client와 server 코드가 서로 꼬여 conflict 오류가 잔뜩 나버린 것이다.. 이 점을 해결하기 위해 be에서 코드를 치지 못 하고 오류 해결만으로 시간을 보내게 되어버린 것이다.

 

우리는 그렇게 새벽에 긴급회의를 진행하였고, 🧐

결론적으론 server 폴더가 있는 브랜치, client 폴더가 있는 브랜치를 각각 나누기로 하고 각각의 폴더는 서로의 브랜치에서 과감하게 삭제하였다..

 

이렇게 결국 따로 배포를 진행하였고, 이 것에 대해 2번째 멘토링 시간에 준프님께 이러한 일을 겪었으며 이렇게 하기로 하였다고 말씀드렸는데 우리가 결정지은 방식에도 아주 큰 문제가 있었다.

 

이 방법은 서로의 폴더가 분리되어 있기 때문에 local test를 진행할 수 없다는 문제가 생긴 것이다. 🥹

이 점을 지적 받고 다시 2차 새벽회의를 하여 가장 익숙한 git flow 전략으로 결국 돌아가게 되었다.. 정말 계속해서 많이 돌아갔지만 이 일들을 경험삼아 우리 팀원 모두 1단계 정도는 성장하지 않았을까? 싶다.

 

사실 나는 이렇게 git 전략을 계속 바꾸면서 만약 면접관이 우리 메인프로젝트 깃을 보았을 때 부정적인 이미지를 갖게 되지 않을까.. 라는 걱정이 되었다. 하지만 이것도 지금 아니면 할 수 없는 일이라고 생각하였다. 준프님께서 여럿이 있을 때 할 수 있는 경험은 돈 주고도 못 하는 경험이라고 말씀해주셨다. 나는 그 부분을 정말 동감하고 있어 이 경험을 소중히 하기로 했다..

 

공통 컴포넌트

 

사실 제목은 공통 컴포넌트로 붙이긴 했는데, 공통 컴포넌트, 공통 함수.. 기타 등등 모두!

사실 우리 팀원들은 아주 훌륭하게 컴포넌트와 함수를 작성해주었는데 나도 작업을 하다 보니 그런 것들이 굉장히 많이 필요하였다우리는 처음 작업을 시작 할 때 input 정도만 디자인 컴포넌트를 생성하고 각각 파트를 맡아 작업을 시작하였는데, 공통화된 부분이 아직 merge가 안되서 그 부분을 뺴고 코드 작성을 하니 자꾸 미완성이 된 기분이라 찜찜했다.. 사실 이게 맞는거 같긴한데.. 그래서 공통 컴포넌트는 브랜치를 따로 파서 작업 후 PR을 부탁드리고 그렇게 진행이 되갔는데, 처음부터 이런 공통화된 작업을 프론트끼리 합의하에 먼저 만든 후 작업을 시작했어야 했나..? 라는 의문이 들었다.. 그리고 괴로웠다.. 어떤게 맞는 방식일까..

 

근데 어제 멘토링을 하다가 준프님이 아주 기깔나는 해결책을 주셨다🧐

 

 

👊 바로 물리로 해결하는 것이다.

물론, 공통컴포넌트 작업을 할 수 있다면 그렇게 하는게 맞지만, merge 될 수 없을 땐 그 파일만 전달 받아 내 로컬에 만들고 사용하는 것이다. 나는 이 방법이 팀원들의 git이 꼬일 수 있다는 걱정 때문에 절대 하면 안된다! 라고 생각했는데 어떤 작업을 하든 효율성 있게, 유연한 사고를 하는 것이 중요하다는 것을 느꼈다.

마치며...

 

어제 멘토링을 하다가 준프님께서 아주 좋은 말씀을 해주셨다.

 

누군가 실수를 해도 특정인의 문제가 아닌 조직의 문제로 가져가야한다.
그 실수를 성장 자양분으로 삼아야한다. 개인의 탓을 하면 그 개인은 나중에 과감하게 도전할 수 없다.

 

이건 git 실수를 하는 신입에 대해 이야기를 할 때 말씀해주신 것인데, 정말 맞는 말씀이라고 생각 했다. 난 아직 입사도 안해서 이런 얘기 하기엔 너무 먼 이야기지만, 나도 이전에 회사를 다녔을 땐 내게도 부사수가 있었고 그때 내 스스로가 이런 행동을 하는 사수 였을까? 라는 생각이 든다. 나는 사수 없이 회사를 다녀서 무조건 잘 해주려고 노력 하긴 했는데 그럼에도 부족한 면은 있었던 것 같다.

 

내 실수에 당당하면 안되지만, 실수를 겁먹지 말고 도전하는 것을 두려워하지 않는 것이 개발자가 가져야하는 기본 소양 아닐까 생각 한다.