boostcampRetrospect

부스트캠프 웹·모바일 7기 멤버십 과정 회고

2022.12.19


boostcamp

챌린지 과정부터 멤버십 과정까지 모두 마무리 되었다. 올해 7기 멤버십은 8월 31일부터 12월 16일까지 진행되었다. 수료 후 진행 된, 12월 19일~20일 이틀 간 진행된 네트워킹데이 행사도 모두 무사히 마쳤다.

멤버십 과정은 챌린지 과정과는 다르게 긴 호흡을 가져가야했다. 코어타임은 10시부터 19시까지로 챌린지와 동일했다. 챌린지 과정에서는 매일매일 새로운 미션을 해결하며 CS 지식을 공부했다면, 멤버십 과정에서는 본격적으로 웹 개발에 필요한 지식을 학습하기 시작했다.

부스트캠프에서는 캠퍼들간의 경쟁의식 보다는 함께 성장하는 경험을 쌓도록 유도하려고 노력했다고 생각한다. 챌린지 기간에는 서로를 평가하는 시간이 있고 이 과정이 멤버십에 영향을 미치지 않을까 하는 생각에 경쟁의식을 떨쳐버릴 수가 없었다면, 멤버십 기간은 최대한 평가로부터의 경쟁의식을 제하려고 했던 것 같다.

8주 간 학습 스프린트를 진행하고, 그룹프로젝트를 6주간 진행하며 기술적으로 단단해지는 경험을 할 수 있었다.

학습 스프린트

챌린지와는 다르게 분야별로 다른 과제가 주어져서 모바일(Android, IOS)분들과는 접점이 없었다. 1주, 2주 단위로 개발해야되는 프로젝트의 요구사항이 Figma로 아름답게 주어졌고, 해당 요구사항에 맞게 개발을 진행했다. 다만, 이 요구사항들을 제한된 기간안에 모두 개발하는 것은 거의 불가능에 가까웠다고 생각한다. 아마도 하루종일 요구사항을 구현하기 위해 코딩을 해야했을것이며 주말 시간까지 사용해야가능했을 것 같다. 그러나, 이 기간에 정말 중요했던 것은 요구사항을 모두 구현하는 것이 아니라 학습하는 것 이었다. 예를들어, MySQL과 Node.JS을 같이 쓰는 것은 좋지 않다고 하던데, 정말 그럴까? 하는 의문이 든다면 내가 직접 테스트해보고 해당 내용을 공유하는 식의 학습 과정을 거치는 것이다.

과도한 요구사항이 주어진 것에는 또 다른 목적도 있었는데, 스스로 프로젝트의 스펙을 결정하고 계획을 세우는 경험을 하는 것이었다. 내가 주어진 일정안에 어느정도까지 개발할 수 있을지 판단하는 것은 함께 일하는 동료와의 신뢰를 위해 중요하다고 생각한다. 이 경험은 그룹프로젝트에 잘 활용할 수 있었다.

개인적으로 아쉬웠던 것은, 전체 캠퍼들을 대상으로는 많이 공유하지 못했다는 것이지만, 이를 운영진분들은 예상했던 것인지 매일 아침 이루어지는 스크럼 시간을 통해 4명의 캠퍼들이 서로가 마주하고 있는 문제에 대해 이야기하고, 겪었던 문제를 어떻게 해결했는지 경험을 나누면서 함께 성장할 수 있었다.

각자가 개발한 것을 채점하는 사람은 아무도 없었다. 그럼에도 불구하고 많은 캠퍼들은 스크럼, 피어세션 시간에 코드리뷰, 학습 정리 공유 등을 통해 서로를 성장시켰다.

학습스프린트의 마지막 프로젝트는 페어프로그래밍을 적극적으로 활용하도록 유도했는데, 감사하게도 좋은 페어분을 만날 수 있었고 이 인연은 그룹프로젝트까지 이어지게 되었다. 학습 스프린트 4주차가 넘어가면서 체력적으로 지치게 되었는데 이 시기를 페어프로그래밍을 통해 잘 이겨냈던 것 같다. 함께 계획을 세우고, 어떻게 구현할지 합의하는 과정은 꽤나 즐거웠다.

그룹 프로젝트

우리 팀은 조별과제 희망편을 제대로 맛봤다고 할 수 있다. 각자가 주도적으로 아이디어를 제시하고, 서로의 의견을 존중하며 진행했던 아름다운 과정 속에서 한 가지 어려웠던 부분이 있다면, 명확한 기술적 의사소통이었다. 그러나 이 문제는 명확한 단어 선택 노력과 문서화 과정을 통해 해결할 수 있었다. 때로는 디자인을 보면서 이야기하기도 하고, 코드나 백로그, 작성했던 테크스펙 등 우리가 문서화했던 다양한 내용들을 활용하며 각자가 생각하고 있는 기술적 구현 과정을 다른 사람에게 유용하게 전달할 수 있었다.

1. 기획 및 설계

피그마 링크 Figma Design

결과적으로 우리는 최초 기획과 거의 똑같은 결과물을 세상에 보여주게 되었다. 성공적인 프로젝트를 진행하기 위해 중요한 것은 프로젝트의 시작인 기획이라고 생각한다. 기획 과정에서 우리 프로젝트의 목표는 무엇인가를 명확히 정해두고, 주요하지 않은 스펙이라면 과감하게 잘라내는 과정을 거쳐서 프로토타입을 만들 수 있었다. 6주라는 기간 중에 첫 주는 기획 및 프로젝트 초기설정, 마지막주는 테스트 및 데모데이 준비로 인해 개발에만 온전히 사용할 수 있는 시간은 4주밖에 되지 않았다. 4주라는 짧은 기간 동안 구현할 수 있는 적정량의 스펙을 결정한 후, 백로그와 테크 스펙을 작성하게 되었다.

  • 로고 디자인 프로젝트를 대변할 수 있는 로고를 찾기 위해 다양한 AI 서비스를 활용했지만 마음에 딱 와닿는 로고가 없었다. 아이패드에 깔려있는 Procreate를 활용해서 이것 저것 디자인을 해보다가, 아래와 같은 로고를 만나게 되었고 다행히 팀원들이 만족해주었다.

    서비스 약어인 PRV를 모두 담고, 동시에 논문에 대한 인용관계를 보여주는 서비스임을 의미하도록 했다.

2. 테크 스펙과 백로그 활용

테크 스펙은 우리 프로젝트의 목표와 목표가 아닌것은 무엇인지, 목표 달성은 어떻게 확인할 것인지 팀원 간 의견을 일치시키는 용도로 사용할 수 있었다. 전반적인 프로젝트 진행 계획을 가볍게 작성해놓았는데, 해당 계획에 맞추어 프로젝트를 진행할 수 있었다.

백로그의 작성 목적은 할일을 분배하고 우선 순위가 높은 항목부터 처리하기 위해서였다. 코드 리뷰는 FE와 BE 구분 없이 진행했지만, 코드를 작성할 때는 거의 FE와 BE가 나눠져서 진행하게 되었다. 백로그는 프로젝트가 진행되면서 작성 누락되었던 작업들에 대해 추가하면서 진행했고, 백로그 이름을 PR명으로 하는 Ground Rule을 정했다. dev 브랜치에 머지될 때는 Squash merge하여 커밋 이력을 백로그 항목으로 지정하였고, dev / main 브랜치에 머지될 때마다 배포되도록 CI/CD 환경을 구축했다.

3. 의사소통 과정

  • 적극적인 회고 금요일에는 팀내 주간 회고 시간이 있었고, 이 때 KPT 방식을 적용해서 회고를 진행했다. 회고를 진행하며 새롭게 시도할 내용이나 고쳐야할 점들은 적극적으로 그 다음주부터 적용하면서, 모든 팀원이 프로젝트에 애정을 가지고 진행할 수 있었다.

  • 자체 기술공유 FE와 BE로 역할이 구분된 상태로 진행되다보니 팀 내 지식 불균형이 일어나기 시작했다. 새롭게 학습한 내용들은 최대한 개발일지로 남기는 Ground Rule이 있었지만, 그저 글로 작성하는 것 이외에도 해당 내용을 서로에게 설명해주는 시간을 가지면서 지식 불균형을 해소하려는 노력을 했다. 매주 목요일에 이 시간을 가지기로 했으나, 부캠 공식 일정 등으로 인해 한번밖에 가지지 못한 것은 매우 아쉽다.

  • Usecase Diagram 작성 BE 서버 개발 과정에서 외부 API 요청으로 인한 Block을 방지하기 위한 로직이 복잡해지는 상황이 발생했다. 어떤 방식으로 이 문제를 해결할 것인지를 토의하기 위해서는 현재 우리 상황이 무엇인지 설명할 수 있어야했으나, 말로만 표현하기에는 한계가 있다는 것을 느꼈다. 프로젝트 전반에 대한 Usecase Diagram을 그리는 것이 필요하겠다는 멘토님의 조언을 바탕으로 아래와 같은 digram을 작성했고, 이는 우리 BE 서비스를 소개하기에 굉장히 유용했다. Usecase Diagram batch logic

4. 누락한 기능들에 대하여

사실 우리가 하고싶었던 것은 더 많이 있다. 사용자별로 원하는 논문을 가지고 있을 수 있을 수 있게 하고 싶었고, 인용관계 그래프가 그려지는 과정은 아래 그림처럼 순차적으로 그려지는 것을 생각했었다.

graph tree

SSE 활용하거나, 프론트 로직을 일부 수정하면 해당 효과를 줄 수 있지만, Elasticsearch를 활용한 검색결과가 무지 빠른 상황에서 일부러 정보를 느리게 보여주는 것이 우리 프로젝트에서 적절하지 않다는 판단을 내리게 되었다.

검색페이지에서는 검색결과에 대한 세부 필터를 적용하는 것을 생각했으나, '필터를 적용할 때 마다 서버에 검색요청을 다시 보내고 페이지네이션된 결과가 모두 바뀌는 것을 사용자가 원할까?' 라는 고민을 했었다.

시간이 부족하여 여러 사용자들에게 A/B 테스트를 해보지 못했던 것은 아쉽다.

5. 프로젝트를 보완한다면?

현재 Elasticsearch에는 9,282,565 개의 논문 데이터가 저장되어있다. 이는 Request Batch 시스템으로 가져온 결과들인데 Elasticsearch 서버의 용량 부족으로 인해 Request Batch 작동을 중단해놓은 상태이다. 제공받은 크레딧이 제한되어 최소한의 사양으로 서버를 사용하다보니, 샤딩을 적용해볼 수는 없었다.(S3에 백업만 해놓은 상태이다.) 크레딧만 충분하다면 Elasticsearch 부분을 더 최적화해보고 싶다. 검색 로직도 현재는 논문의 제목과 저자의 일치하는 여부를 검색하는데, n-gram이나 fuzziness 로직을 추가하면 더 나은 검색 결과를 제공할 수 있을 것 같다.

6. 기능을 추가한다면?

사용자 별로 논문을 스크랩해놓고 원하는 논문들간의 인용관계를 확인하고, 인용관계 그래프를 SNS에 공유할 수 있는 서비스가 된다면 사용자들이 더욱 재미있게 사용할 수 있을 것 같다.

코어타임 이외에 진행됐던 다양한 행사

  • 부스트 컨퍼런스 (네이버 1784 건물에서 진행되었다. 부캠 기간동안 유일한 오프라인 행사였다.)
  • 접근성 특강
  • 이력서 특강
  • 기획 특강
  • DB 이슈 특강 등등 ... 여러 특강이 있었다. 특강은 대부분 19시 이후에 진행되었고, 몇몇 특강은 개인적인 일정이 있어 참여하지 못하기도 했다.

마무리

6월 30일 전역 후, 거의 바로 부스트캠프에 참여하면서 올 하반기는 부스트캠프와 함께 개발자로서의 역량을 키울 수 있었다. 이제 부스트캠프는 마무리되었고, 현업에서 일할 것만 남아있는데, 취업시장이 상당히 얼어있음을 느낀다. 2023년에는 좋은 기업을 만나서 함께 성장하는 경험을 할 수 있기를 바란다.

참고