프로젝트 기간 - 2024년 7월 10일 ~ 2024년 7월 24일
프로젝트 명 - MovieMemo
프로젝트 내용 - 감상한 영화의 리뷰를 작성, 공유하는 사이트 제작 프로젝트
프로젝트 Repo - https://github.com/SeSAC-1st-Project-Team-C/MovieMemo


qvA-BB59BqtUQomMgdpTa-1653035922797

KEEP: 잘한 점

  1. 자유로운 의견 공유
  2. 타인의 코드 이해 노력
  3. 빠른 발표 준비와 괜찮았던 발표
  4. 페이지 세세한 부분까지 신경쓰려는 노력
  5. NCP를 활용한 배포
  6. 기술적인 선택과 개선방안
  7. 문제 해결 과정 발표와 테스트 계정 제공

PROBLEM: 아쉬웠던 점

  1. 기능 추가로 인한 일정 부족
  2. 팀원과의 소통 문제 (온라인이였을 때)
  3. 프론트엔드와 백엔드 코드 합칠 때 문제
  4. 프론트엔드와 백엔드 소통 부족
  5. 스크린샷 발표 자료의 문제
  6. PURE CSS 사용에서 생기는 어려움

TRY: 다음에 챙길 것

  1. 더욱 세밀한 칸반보드 작성으로 일정 공유
  2. 더욱 적극적인 팀원 소통과 일정 공유
  3. 추가 기능 코드 수정 여부에 대한 면밀한 생각
  4. 추가 코드의 양 조절 (열정 컨트롤)
  5. UI 개선
  6. 발표 이미지 적절히 활용
  7. 프로젝트 중간 중간 블로그 작성



2주간 진행했던 1차 프로젝트가 끝났습니다.


저희 팀은 전부 의욕이 넘쳐 무언가를 적용하고 시도하는데는 무리가 없었고 의견 충돌도 적었습니다.
의견 충돌이 난 경우 과반수로 정했고, 모두 큰 충돌없이 의견을 수렴했기에 프로젝트에서 가장 무서운 팀원들과의 내부 다툼이 없었습니다.

물론 면접 요소를 생각하면 한 번쯤 다툼도 괜찮았을거 같은데 우리 팀원들은 언제 이런 사람들을 만나보나 싶을 정도로 성실했고 적극적이여서 좋았습니다.

팀프로젝트는 해봤지만, 처음보는 사람들과 첫 JavaScript 기반의 프로젝트였기에 배운 걸 잘 이용할 수 있을까 걱정도 되었습니다. 하지만 자의적으로 계속 해서 늘린 적지 않은 양과 넉넉하지 않은 일정으로 인해 걱정할 시간조차 없었습니다.
과거 팀프로젝트의 경험으로 일정이 계획한대로 흘러가지 않는다는 것과 항상 변수가 존재한다는 것을 알고 있었고, 그에 대한 생각과 대비도 나름했지만 그 부분에 대해서조차 변수가 있다는 것이 이번에 제일 크게 배운게 아닌가 싶습니다.



(KEEP) 먼저 이번 프로젝트에서 이런 점이 좋았습니다.

  1. 팀장 중심이 아닌 각자의 생각과 의견을 아주 자유스럽게 공유할 수 있었던 부분이 좋았습니다.
    제가 생각하는 팀장의 역할은 경험에 대한 공유와 적극적인 일정 피드백, 의견 조율 그리고 함께하는 코드 고민 등이라고 생각했습니다. 팀장인 제가 생각하는 부분이 맞다고 생각이 들더라도 잠시 주장은 미루고, 다른 의견은 없는지 더 좋은 방식은 없을 지에 대해 함께 생각해보려고 노력했습니다.

  2. 타인의 생각과 코드를 이해해 볼 수 있었던 경험이 좋았습니다.
    단순히 코드를 작성하고 PR하고 문제없으면 MERGE하고에 그친 것이 아닌 왜 이렇게 작성하였는지 그로 인해 바뀌는 점이 무엇인지에 대해 생각하고 MERGE하려는 부분이 좋았습니다.

    이런 생각들을 SLACK에 작성하여 남겨서 함께하려고 했고, 리더님이 댓글도 달아주셔서 더 힘이 났습니다.

    스크린샷 2024-07-26 231141

  3. 빨랐던 발표 준비와 괜찮았던 발표가 좋았습니다.
    빠듯한 일정이었지만 구체적인 계획이 있었고 그 순서대로 진행했으며, 평소 코드를 왜 이렇게 짜려고 했는지에 대한 생각들이 겹쳐 발표 준비는 문제가 없었으며 준비에 시간도 많이 걸리지 않았습니다.

  4. 세세한 부분도 챙기려고 했던 노력을 했습니다.
    궁극적으로 사용자 입장에서 제작하려고 했습니다. 개발자 입장에서 단순히 만난 오류 페이지더라도 또한 개발자 입장에서 자주 만나는 메세지더라도 사용자가 사용할 때 알 필요가 없는 내용들, 완성도가 떨어져 보이게 만드는 세세한 부분을 챙기려고 노력했습니다.

    예를 들어, 글이 없으면 ‘아직 작성한 리뷰가 없습니다.’ 라는 부분이라던가 지금 시도하려는 기능에 무엇이 부족해서 작동이 원할히 되지 않는지에 대한 안내 (로그인 등) 같은 것들이 있습니다.

    또한, 시연을 위한 더미데이터 작성에도 신경썼습니다.

  5. 처음 NCP를 활용한 배포 성공이 있습니다.
    기존 AWS를 활용한 배포의 경험이 있기에 크게 문제는 없었고 오히려 NCP의 난이도가 더 낮다고 생각이 들었지만 배포만큼 중요한 것은 또 없기에 실수하지 않으려 꼼꼼히 살표 보았습니다.

  6. 기술적인 선택과 개선점
    처음 우리 프로젝트는 영화 정보 API 활용을 가닥으로 잡았을 때, 박스오피스의 순서대로 영화를 표시하려 하였고 포스터 또한 당연히 표시해야했습니다. API 종류는 워낙 많으니 충족하는 API 찾기는 아주 쉬운 문제인 줄 알았습니다만, 우리가 원했던 정보는 각각 다른 API를 사용해야한다는 것을 알게 되었고, 또한 원했던 모든 정보가 있는 API는 서비스가 중지되었음을 알게 되었습니다.

    그렇게 API를 2개 동시에 사용하려 하였으나, 승인을 받는 데 걸리는 시간과 서로 다른 응답 횟수 제한의 문제 등이 많은 문제점이 겹쳐 1개만 사용하는 쪽으로 변경되었습니다.

    타협하여 좋아요를 많이 받는 순서대로 제작 계획이 변경 되었고, 응답 횟수의 문제는 먼저 검색하여 DB에 저장하고 다음 검색 시엔 저장된 DB에서 불러오는 방법으로 구현했습니다. 이로 인해 API 횟수 차감에 대한 문제가 많이 해결되었고 응답속도도 개선되었으며, DB에만 저장했을 시 만약 없는 영화에 대한 업데이트를 수동으로 했어야 했지만, API와 병행함으로써 이 부분도 해결하였습니다.

  7. 문제 해결과정 발표와 테스트 계정 제공한 부분
    개발자의 발표 성격에 맞게 문제 해결과정과 기술 선택 이유 그리고 선택한 기술들의 대략적인 특징, 사용자는 내가 만든 프로젝트를 친절하게 보지 않을 것을 생각한 테스트 계정 제공이 잘한 부분이였습니다.


위와 같은 잘한 점으로 인해 처음 진행한 JavaScript 프로젝트임에도 성공적으로 마무리해 볼 수 있었던 경험이 생겼습니다.



(PROBLEM) 이렇게 좋았음에도 처음에 언급한 변수가 왜 생긴건지 생각해보니

  1. 주제가 영화 리뷰 사이트였는데 사이트 기본 성격 특성상 기본적으로 챙겨야할 기능들이 기간 대비 애초에 많았고, 의욕이 다들 넘치니 이것 저것 추가하다가 결국 일정에 맞춘 개발을 하기 위해 프로젝트 기간 초반에 기능적인 부분을 줄이는데까지는 그래도 아무 문제가 없었습니다.

    하지만 초반 우선 순위 계획대로 흘러가니 시간적인 여유가 생겼고 다들 함께하는 열정으로 남은 시간에 기본 기능과는 다른 성격의 조금 고도화된 기능을 추가하다보니 시간적으로 빠듯해졌고 물론 일정 내에 계획하였던 거의 모든 기능을 개발하는 것에는 성공하였지만 엄청 바쁜 나날을 보냈습니다.

  2. 팀원과의 소통 부분입니다. (온라인으로 전환)
    팀원과의 소통이 바로 옆에서 진행하는 것과 온라인으로 소통하는 것에 대해 이렇게 차이가 날 줄은 몰랐습니다.

    물론 사정상 도중에 온라인으로 전환하여 참석하신 팀원이 적극적이지 않았다는 것을 뜻하는 것은 아닙니다.
    누구보다 열심히 참여했고 프로젝트 진행에 큰 도움이 되었습니다. 물리적인 소통의 한계에 있어 게더(Gather)를 이용해 잠깐씩 진행한 온라인 마이크 소통으로 어느 정도 상쇄하긴 하였지만, DM으로 소통하는 오프라인과 온라인의 한계는 확실히 있다는 것을 느꼈습니다.

    게다가 고도화된 프로젝트의 기능들을 추가하는 기간에 온라인으로 전환하시게 되어 더욱 힘들었던게 아닌가 생각됩니다. 앞으로 비슷한 일이 발생한다면, 더욱 세밀한 일정 조율과 계획으로 발생할 문제점을 줄어야겠다는 생각이 들었습니다.

  3. 프론트엔드와 백엔드의 코드를 합칠 때 발생하는 문제에 대해 두 번 일하게 된 부분입니다.
    처음 백엔드 코드를 작성하고, 프론트엔드 코드를 작성하면서 백엔드 코드를 연결하는 것이라는 과정에서 문제가 생길 가능성이 아주 높기에 기간을 넉넉히 생각하는 것 까지는 좋았습니다만,

    문제는 기능이 추가되어 추가된 부분에 대해 기존 백엔드 코드와 프론트엔드 코드를 수정하고 그걸 또 합칠때는 시간이 2배 이상이 걸린다는 것이 문제였습니다. 코드 상 기존 코드 대비 비교적 복잡한 로직이 쓰이면서 기존 코드를 수정하는 일이 잦았고 그러기에 시간이 빠듯했졌습니다. 그리고 생각하지 못한 오류들이 계속하여 생겨났습니다.

    단순히 기존 코드는 그대로하고 기능적인 추가 부분으로 접근하면 문제 없을 거란 생각이 빠듯한 일정을 만든게 아닌가라는 생각이 듭니다.

  4. 프론트엔드와 백엔드과의 소통문제입니다.
    팀장 역할을 맡았던 저는 백엔드로 팀프로젝트를 참여해본 경험을 토대로 이번 프로젝트를 진행하다보니 프론트엔드 진행방식에 대해 자세히 알지를 못했고, 알지 못하는 부분이기에 더욱 신경을 쓴다고 노력했음에도 불구하고 프론트엔드 분들과의 소통이 적었던 것 같습니다.

    어디까지 진행되었는지 어떤 문제가 있는지 정도는 여쭤보았지만 그 당시에 저는 너무 각각의 개발에 참견을 한다는 느낌을 줄 것 같아 주저했습니다.

    하지만 다시 돌아간다면 좀 더 면밀히 이야기하고 살펴보고 일정을 맞춰볼 걸 이라는 후회가 남습니다. 팀원을 믿고 같이 진행한다는 느낌은 좋지만 만약 계획과는 다르게 흘러가는 상황이 발생하자 대처할 수 있는 시간이 매우 부족해졌습니다.

    그로 인해 모든 팀원들이 프론트엔드 제작에 힘을 쏟았고 밤낮으로 진행한 결과 성공적으로 마무리 할 수 있었습니다. 마무리할 수 있었던 것에 대한 점은 아주 다행이지만 힘든 나날이 아니었나 생각됩니다.

  5. 성공적인 발표였지만 미흡한 부분
    발표 자체는 전체적인 부분으로 봤을 때 크게 누락된 부분도 없었고 발표자체에 문제는 없었지만, 잘보이지 않는 스크린샷으로 꾸밀 것이 아닌 GIF로 구성할 걸이라는 아쉬움은 남습니다. 또한 제한된 시간의 압박으로 세부적인 소개를 못한 것이 아쉬웠습니다.

  6. 마지막으로 PURE CSS에 대한 생각입니다.
    수강하면서 배운 CSS에 대해 복습과 활용을 목적으로 채택한 PURE CSS였습니다. 사람들의 이목을 끄는 정도의 디자인은 아니더라도, 사용자가 불편하지 않게 만드는 것이 아주 중요하다고 생각하기에 더욱 CSS 프레임워크에 대한 아쉬움이 컸습니다. 더불어 시간이 CSS 프레임워크에 대비하여 매우 많이 걸렸기에 더욱 아쉽습니다.



(KEEP + PROBLEM = TRY) 다음에는 꼭 빠지지않고 챙겨야할 것

  1. 더욱 세밀하고 면밀한 칸반보드 작성으로 일정 공유
  2. 더욱 적극적인 팀원 소통과 일정 공유
  3. 추후 추가할 기능에 대한 코드 수정 여부에 대한 더욱 면밀한 생각
  4. 기존 계획보다 더 많은 추가 코드에서의 양 조절 (열정 컨트롤)
  5. UI 개선 (+ 디자인 개선)
  6. 발표에 이미지 적절히 활용할 것
  7. 발표 테스트 계정 제공을 인풋에 미리 넣고 제공
  8. 프로젝트 중간 중간 작성하는 블로그



아쉽지만 프로젝트 동안 블로그 작성도 쉬었네요. 이번 프로젝트를 진행하면서 블로그에 작성할 프로젝트 진행 도중에 만난 문제점에 대해 단순히 기록은 해놓았지만, 다음 프로젝트에서는 시간을 만들어서라도 문제가 해결되면 간단하게 블로그 작성이라도 하는 것을 목표로 해야겠습니다.


마지막으로 이 다음으로는 리더님이 말씀해주신 피드백을 남기겠습니다.

이상 회고를 마칩니다.



1차 프로젝트 피드백

전체 피드백 (진행팀 전체)

  • 발표 호흡 빠름 (듣는 이를 배려하는 발표 자세 필요) <X>
  • 개발자 면접이니 기능을 위해 적용한 기술 어필 필요 <O>
  • 파비콘 타이틀 추가 <O>
  • 사용자 경험 입장에서 프로젝트 구현 필요 <O>
  • 빈 부분에 대해 적절한 처리 (표시 안내 등) <O>
  • 테스트 계정 인풋 미리 넣어놓기 (버튼만 누르면 되도록) <O> 인풋은 <X>
  • 프로젝트 완성도는 첫 화면에서 거의 정해짐 <X>
  • 회고 시 트러블 슈팅 및 고민했던 여러 방법 설명 (길게 해도 상관없음) <O>
  • 모바일에서는 스크롤 없애주는 것이 좋음 <O>
  • 메뉴 구성도, 화면 흐름도 어필 필요 <O> 스크린샷 부분은 <X>
  • 주제에 익숙하지 않은 사람도 사용 가능하게 인지할 것 <O>
  • 기술자에게 설명하는 느낌으로 진행<O>
  • 디테일한 부분 (에러 코드 종류) 챙기는 것 중요 <O>
  • 더미 데이터 신경 써서 만들 것 <O>
  • 발표 시 gif 사용 좋음 <X>
  • 테이블 설계 시 고민했던 부분 설명 필요<X>
  • 특정 기술 나열 시 선정 동기 필요 <O>

잘한 점 (팀 피드백)

  • 계정 로그인 (테스트 계정) 제공
  • 기술적인 표현 발표
  • 문제점 해결 방법 발표
  • 대체 이미지 적용
  • 프로젝트 성과 및 이후 계획 발표
  • 관리자 전용 기능 만든 부분

고칠 점 (팀 피드백)

  • 발표자료 무분별한 캡쳐 사용 (보이지도 않음) 테이블 자료, ERD 자료 등
  • 제목 토글 설명 없어 파악하기 힘듬
  • 메인 페이지 대표 리뷰 정보 부족 아쉬움
  • 댓글 박스 눈에 잘 들어오게 인식할 수 있게끔 개선 필요
  • 리뷰 UI 아쉬움 (너무 밋밋함, 기능적으로 괜찮으나 메인 컨텐츠의 UI가 미흡)
  • 신고를 토대로 댓글을 막거나 권한을 빼앗는 작업 자동화 필요 (현재는 수동)
  • 배우 프로필 이미지 추가 (optional)