신입 프론트엔드 개발자 첫 프로젝트 회고

첫 프로젝트가 끝이 났다. 어리바리한 첫 출근부터 시작해서 그동안 사내에서 느꼈던 것들에 대해 블로그 글도 몇개 쓰기도 했다. 요즘 시간이 너무 빠르게 지나가서 한편으로는 불안하다. 개월 수는 늘어나는데 내가 그만큼 성장을 하고 있는지, 올바른 방향으로 나아가고 있는지 모르겠다. 기술적인 부분 외에도 배울 게 참 많다는 것을 느끼는 요즘이다.

 

개발자로서 첫 프로젝트를 끝낸 기념으로 회고 글을 쓰려고 한다. 회사에서도 회고를 진행하긴 했지만 마침 향로님이 블로그에 프로젝트 회고 관련 글을 올려 주시기도 했고, 해당 글에 있는 회고 질문을 내게도 적용을 해보고 싶었다. 그래서 글에 있는 질문을 토대로 조금 바꿔서 작성을 해보려고 한다.

이번 프로젝트 회고에서 이야기했으면 하는 주제가 있나요?

협업 도구

협업 도구들에 대해 팀원들과 많은 대화를 나눴다. '이건 어떻더라', '이건 무료인데 이런 기능까지 있다' 등..그렇게 팀원 수와 사용성을 고려해서 노션을 사용하기로 했다. 처음에는 회의 내용과 프로젝트 관련 내용까지 한번에 관리할 수 있어서 좋아 보였다. 하지만 MR과 동떨어진 이슈관리와 칸반 보드, 이슈가 늘어날 수록 떨어지는 가독성 그리고 프로젝트가 여러개일 때의 유지보수에 대해 의구심이 생기게 되었다. 회의 내용도 보고, 지식 공유(에러 로그)와 팀원들의 프로젝트 진행 상황 등을 한 곳에서 해결하고 싶었지만 결국 다음 프로젝트 관련 내용은 깃랩을 통해 관리하기로 결정했다.

📌 MR(Merge Request)과 PR(Pull Request)의 차이 - 깃랩에선 MR이라 하고, 깃허브에선 PR이라 하는데 그 이유가 궁금했다. 알아보니 MR은 요청받은 사람(assignee)의 최종 액션이 merge이기 때문이고 PR은 첫번째로 하는 액션이 feature branch를 pull 해오는 것이기 때문에 이와 같이 불린다고 한다. 둘 다 다른 브랜치 또는 브랜치의 변경 사항을 가져오고(pull), 기존 코드와 병합(merge)하는 수단임은 같다.

Git Workflow

입사하기 전엔 개인 프로젝트를 위주로 해서 깃 사용에 대해 깊게 생각해본 적이 없다. 이제는 깃을 통해 협업을 해야 하기 때문에 단순히 내 원격 저장소에 코드를 올리는 것이 아니었다. 그래서 rebase도 해보고 정말 많은 시행착오를 겪었다. 여기서도 많은 에러를 마주했는데 해결만 하고 그걸 글로 정리를 못한 게 많이 아쉽다. (중간중간 기록을 해 놓았으면 꽤나 많은 도움이 됐을텐데)

 

현재는 어느 정도 작업흐름이 정해져서 크게 어려움을 느끼고 있진 않다. 간단하게 흐름을 정리 하자면 다음과 같다.

1. upstream repo를 fork한다
2. origin repo에서 feature별 브랜치를 생성해서 작업한다
3. 작업이 끝나면 커밋을 한다
4. origin master로 이동 후 upstream master를 pull 해온다(최신화)
5. 만약 변경사항이 있으면 origin master에 푸쉬한다
6. 다시 feature 브랜치로 이동 후 origin master를 병합한다
7. 만약 conflict가 나면 해결하고 origin feature 브랜치에 푸쉬한다
8. upstream repo에 MR을 생성한다

이렇게 하면 MR 시 충돌날 일도 없고 깔끔하다. 아직은 이 방법이 제일 좋은 방법인 것 같다.(더 좋은 방법이 있다면 댓글로 공유 부탁드립니다. 😆)

MR/Issue 템플릿, Commit 컨벤션

처음엔 MR 템플릿이 없었다. issue 또한 위에서 말했듯이 노션으로 작성했기 때문에 구두로만 적당히 규칙을 정하고 생성했다. MR은 적당한 예시를 끌어와 노션에 적어두고, MR을 생성할 때마다 복붙 해왔는데 한 두번을 넘어 여러 번을 복붙하다 보니 너무 불편했다. 그래서 MR과 issue 템플릿을 만들어서 불편함을 해소했다.

 

그러다 회사 동기분이 공통시스템개발팀 코드 리뷰 문화 개선 이야기 글을 보여 주셨는데 MR 템플릿이 깔끔해서 해당 템플릿을 사용하기로 했다.

MR 예시 복붙 ➡️ MR 템플릿 생성 ➡️ MR 템플릿 간소화

그리고 커밋은 상황에 맞게 키워드(ADD, DEL)를 정해서 맨 앞에 붙여 주었다. 하지만 키워드가 다양하고 많아서 커밋할 때마다 매번 정리해둔 키워드를 확인하는 불편함이 있었기 때문에 gitmoji를 사용하기로 결정했다. gitmoji는 매번 확인할 필요도 없고 CLI로 바로 커밋이 가능해서 사용하게 되었다.

이게 맞나?

요즘 가장 많은 혼란을 겪고 있는 주제이다.

문제 직면 ➡️ 커피 ➡️ 구글링 ➡️ 어찌저찌 구현 ➡️ 이게 맞나?

회사가 기술 스택 선택이나 여러 면에서 자율성이 좋은 편이다. 최신 기술 스택이나 유명한 기술 스택들을 써볼 수 있지만 그만큼 능동적으로 해결 해야하는 부분이 많다. 그리고 이게 좋은 코드인지, 좋은 설계인지 모르겠다. 좋은 예시를 찾아보기가 힘들다. 그래서 신입 프론트엔드 개발자 셋이 모여 '이게 맞나?'를 외친다.

다음 프로젝트에 대해 궁금한 점/기대되는 점은 어떤게 있나요?

상태관리 라이브러리

작은 프로젝트였지만 상태관리의 필요성을 느꼈다. Mobx와 Recoil 중에 하나를 사용할 것 같다.

Atomic Design

이 디자인 패턴을 사용할 것인지 계속해서 고민하고 서로 의견을 나누는 중이다. 아직 이렇다 할 폴더 구조가 정해지지 않아서 이 부분도 시행착오를 겪어봐야 알 것 같다.

작업 우선순위

작업 우선순위를 어떻게 정해야 할까? 제일 중요한 기능들을 먼저 구현해야 할까? 아니면 그 반대일까?

테스트 코드 작성

나는 테스트 코드 작성을 한번도 해본 적이 없다. Jest라는 테스팅 라이브러리를 사용할 것 같은데 이것도 궁금하다.

이번 프로젝트를 하면서 기억에 남는 일들이 있나요?

구글 리캡차 구현 및 검증

스팸 이메일 차단을 위해 구글 리캡차를 달았다. 처음엔 프론트단에서 모두 해결되는 줄 알고 구현에 성공한 줄 알았다. 하지만 입사동기분(백엔드)께서 테스트를 해보자고 제안하셨고, 동기분이 파이썬으로 스팸 메일 프로그램을 만들어 테스트를 진행하게 되었다. 당연히 막을줄 알았는데 메일 알림이 울렸다. 그때부터 다같이 멘붕에 빠져 일주일 넘게 고생했던 기억이 있다. 결국 검증까지 구현하여 스팸 막는 것을 성공했고 그때 그 기억은 아직도 생생하다.

리액트 폼 다루기

이때 리액트에 대한 이해가 정말 부족하다는 것을 깨달았다. 폼의 유효성 검사 하는 것을 제때 구현하지 못해서 라이브러리의 도움을 받았고, 내 부족함도 많이 느끼게 되었다.

이번 프로젝트를 하면서 가장 의욕/퍼포먼스가 높았을때는 언제인가요? 그땐 왜 의욕/퍼포먼스가 높았었나요?

'개발'하는 느낌을 받을 때 항상 의욕이 높아지는 것 같다. 반복적인 작업이 아닌 진정으로 '개발'하고 있다는 느낌을 받으면 재미있게 느껴지는 것 같다. 그리고 내가 하고 싶은 기능을 개발할 때가 가장 집중이 잘 되는 것 같다.

이번 프로젝트를 하면서 가장 의욕/퍼포먼스가 낮았을때는 언제인가요? 그땐 왜 의욕/퍼포먼스가 낮았었나요?

빠르게 구현해야 할 때, 반복적인 작업일 때 약간 기계적으로 구현하는 것 같다.

과거로 돌아갈 수 있다면, 이번 프로젝트 기간 중 언제로 돌아가고 싶으신가요? 왜 그때로 돌아가고 싶으신가요?

돌아가고 싶지 않다. 충분히 재미있게 했고, 다음 프로젝트가 더 기대가 된다.