프로젝트 회고록

Jonnie·2022년 8월 22일
0

프로젝트를 마무리하면서 내가 느낀 감정, 배운 점, 그리고 무엇보다 중요한 다음 프로젝트에서는 꼭 신경 쓰고 싶은 부분을 정리해보고자 한다.

이번 프로젝트는 나에게

큰 고비였다
정신적, 육체적인 피로도가 상당히 높은 프로젝트였다고 생각한다.
처음 써보는 프레임워크, 프로젝트가 처음인 팀원들, 근데 나도 이렇게 본격적인 협업 프로세스는 처음에, 조언을 구할 멘토는 존재하지 않아 막막함까지...
사실 이 글을 본다면 섭섭해 할 수도 있지만 다 완성 못할 수도 있을 것 같다고 하며 웃을 때는 진심으로 허탈하고 다 그만두고 싶었다...

배운 점

  1. Spring boot 전반에 대한 지식
    사실 JAVA에 대한 거부감 + Spring의 악명 높음(?) 때문에 항상 도전을 망설이고 피해왔는데 역시 상황에 닥치니 어떻게든 하게 되어 있다. 다행히 나와 잘 맞는 강의를 찾아서 첫 시작을 수월하게 해낼 수 있었다.
    그래도 해당 강의만으로는 아직 TDD나 더 신경써야 할 부분들을 체크하기에는 부족한 부분이 있으므로 다른 강의를 더 들으며 부족한 부분들을 채워나가야겠다.
  1. 프론트엔드-백엔드 통신에 대한 이해
    기존 프로젝트는 모두 프론트, 백 개발 환경을 통일시켜 별도의 연결과정이 없이 같은 포트에서 실행할 수 있도록 편하게 연결할 수 있었다. 이번에 새롭게 도전하기 위해 현업처럼 완전히 분리시켜 진행해보았는데 생각보다 복잡하고 할 일이 많았다. 그래도 이번 경험을 통해 이제 백엔드 개발을 웹에 의존하지 않고 할 수 있게 된 것 같아서 뿌듯하다.

  2. 문서화의 중요성
    2번과 약간 연결되는데 기존에는 프론트, 백에 대한 명확한 분리가 없이 프로젝트를 진행하거나 캠프와 같이 같은 공간 내에서 프로젝트를 진행하여 말로 해결하는 등 문서화의 중요성을 느끼지 못했다. 그러나 이번 프로젝트에서 명확한 역할 분배에 따라 문서의 중요성이 더욱 커졌고 API 문서나 ERD, Figma 등 다양한 툴을 사용해보았다. 기본적인 협업은 노션 문서로 이루어졌는데 기능 개발이나 에러 해결에 참고한 자료들도 아카이빙 해두니 같은 문제가 발생했을 때 해결하기 좋았다. 전에는 카톡으로 해결했던 적도 있는데 시간이 지나면 무슨 문제였는지, 어떻게 해결했는지 확인하기도 힘들어 이런 협업툴을 활용해 문서화 해둔 것이 이번에 잘한 일인 것 같다.

  1. 좋은 코드를 보는 것의 중요성
    이번에 프로젝트를 참여하며 가장 많이 본 것 중 하나가 다른 프로젝트 팀의 코드였다. 정확히는 구조가 더 맞는 것 같지만...다른 동아리에서 같은 기술 스택으로 진행한 프로젝트 팀을 봤는데 컨벤션부터 프로젝트 구조화, 주석 등 너무 깔끔하게 프로젝트를 진행하여 '아 진정한 팀 프로젝트는 이런 거지!'하는 생각을 많이 하게 되었다. 이를 참고하다 보니 저절로 나도 좋은 코드를 짜기 위해 고민하고 참고하게 되었고, 그 과정에서 많이 배우고 성장했다고 느꼈다. 항상 좋은 코드를 보라고 말만 들어왔는데 그 중요성을 이제야 체감하게 되었다! 그래도 지금이라도 알게 되어서 다행이다:>

다음 프로젝트에서는..!

  1. 프로젝트 구조는 대략적으로라도 미리 정하자
    이번 프로젝트에서는 듣고 있던 강의 기반으로 진행을 해서 해당 강의의 불필요한 부분까지 계층화되어 프로젝트에 들고 온 게 많았다. 기능별이든 담당자든 폴더 구조에 대해 미리 정하지 않으니 다른 사람 코드에서 참고할 부분도 찾기가 너무 힘들었다...
    마지막에 정리하기는 했으나 결국에는 이것 때문에 꼬였던 것이 많아 다음에는 꼬옥 신경쓰고 싶다.
  1. API 명세는 팀원들과 함께 이야기하며 빠르게 작성하자
    -> 혼자서 작성했더니 시간도 오래 걸리고 깜빡하는 부분도 있어서 프로젝트를 진행하며 계속 신경 쓰였다. 명세 중 이해가 안 되는 부분이 있다는 이야기도 한 번 정도 들어서 다음부터는 꼭 팀원들이랑 협의된 명세를 만들고 싶다
    비대면이라 더욱 이런 부분이 힘들었던 것 같다. 또한 명세를 작성해도 그 존재를 신경 쓰지 않아 더욱 고생한 것이 많으니 같이 하면서 중요성을 일깨우고 시작해도 좋을 것 같다...
  1. Issue, Commit message 등 컨벤션을 두고 지켜가면서 진행하자
    -> 처음에는 어색하고 불편한 작업이라고 생각했는데 누가 어떤 작업을 하고 있는지 알기도 편하고, 버그도 미리 이슈로 만들어두면 좋을 것 같다. 커밋 메시지 컨벤션은 사실 항상 사용하고 싶었는데 이번 프로젝트를 같이 하는 개발팀원들은 개발 자체가 낯설어서 깃 자체를 활용을 어려워했다...언젠가 해야 하겠지만 첫 개발에 깃까지 쓰는 건 처음 개발할 때의 나를 생각해도 조금 벅찬 감이 느껴져서 일단은 그냥 편한 대로 하도록 뒀다. 그래도 같이 백엔드를 맡은 개발팀원은 비슷하게 맞춰서 커밋해줘서 고마웠다. Git을 앞으로 더 협업에 맞게 잘 활용할 수 있도록 미리 이러한 부분도 정해두면 좋을 것 같다.

  2. 프론트 - 백 통신은 충분히 시간을 두고 진행하자
    물론 이번에는 백도 프론트도 모두 초보였기 때문에 더욱 우당탕탕 난리도 아니었지만 포스트맨에서는 정상 작동하는 것이 프론트로만 가면 에러가 터지는 등 문제가 많았다...그 과정에서 백엔드 배포된 DB가 꼬이기도 해서 더욱 문제가 많았던 것 같다. 근데 이 연결할 시간을 3일도 잡지 않고 백엔드 1명, 프론트 1명이 했으니 문제가 많이 생기는 건 당연한 결과였을지도 모르겠다.

지금까지 해온 프로젝트들을 돌이켜 생각해보면 나와 실력이 비슷하거나(=아직 초보거나) 프로젝트 자체가 처음인 사람들과 진행해왔다.
이러한 환경에서 아무것도 없지만 어쨌든 내가 이끌어 가야한다는 부담감을 느끼고 힘들었던 것 같다. (나이나 학번, 경험, 위치 등 때문에 묘한 부담감이 있었다)
다음에 프로젝트를 할 때는 잘하는 사람과 함께 하면서 많은 것을 배우면서 진행해보고 싶다...!
그러려면 더 넓은 곳으로 나가봐야겠지? 도전하자...파이팅!!

벨로그로 옮기고는 처음 쓰는 포스트라 어색하지만 UI가 벨로그가 더 취향이기도 하고 자주 사용하는 노션과 결이 비슷해 손이 많이 갈 것 같다.
티스토리에 쓴 글이 많지는 않지만 그래도 두고 오니 뭔가 아쉽긴 하다..ㅎㅎ 다음에 기회가 되면 유용한 정보만 다시 한 번 벨로그에 정리해봐야겠다.

profile
부딪히며 배우는 백엔드 개발자

0개의 댓글