싸피9기 관통 프로젝트 회고록

💾프로젝트 회고

인생 첫 프로젝트를 진행하면서 10일이라는 짧은 시간에 기획과 설계, 개발을 전부 진행하고 발표까지 진행하면서 많은 아쉬움이 남았던 프로젝트였다. 짧은 시간에 완성도 있는 프로젝트가 나와야 했기에 팀원과의 대화를 통해서 기획을 짧게 가져가고 개발 시작을 빠르게 진행했다.

기획

기획 측면에서 조금 아쉬웠던 부분은 6개월동안 배웠던 기술과 짧은 시간에 구현할 수 있는 건 단순 커뮤니티여서 한정된 아이디어가 굉장히 아쉬웠다. 또한 이번 프로젝트에서는 어떤 기술 스택을 사용할지, 어떤 툴을 사용할 지 전혀 생각을 하지 않고 진행했었기 때문에 중간에 아이디어가 바뀌는 어려움이 생기기도 했었다.

원래 내가 생각했던 기획은 1~2주의 시간이 주어지고 많은 사람들끼리 자료 조사를 통해 아이디어의 실현 가능성, 한계점 등을 논의하고 결정하는 것으로 생각했는데, 그런 부분을 기대했어서 그런지 약간의 아쉬움이 있었던 기획 단계였다.

지금은 2명이서 기획을 진행했지만 2학기에는 6명이서 기획을 진행하기 때문에 조금 더 다양하고 재밌는 아이디어가 나오지 않을까 라는 기대감이 있다.

설계

개발자는 사실 개발보다 DB 설계를 어떻게 하는지가 가장 중요하다고 많이 들었다.

그래서 DB 설계를 제대로 하고 싶었으나, 짧게 배운 DB의 지식과 주어진 시간은 많은 한계에 부딪히도록 만들었다. MYSQL을 사용해서 설계를 진행했지만, 이 당시에는 PK와 FK의 개념과 다대일, 일대일, 다대다의 개념을 이해하고 만든 것이 아니였기 때문에 지금 보면 ERD에서 이해가 안되는 부분이 조금은 있다.

일단 유저 테이블을 보면 PK를 따로 LONG 타입으로 선언한 것이 아니라 유저의 로그인 아이디 자체를 PK 값으로 만들었다. 사실 아이디 자체도 유니크값이기 때문에 당장은 문제가 안되지만, 나중에 유저가 아이디를 바꾼다거나, 로그인의 방식이 다양해질 경우 문제가 생길 것이 분명했다.

또한 다이어그램과 요구사항 정의서도 이번에 처음 써봐서 굉장히 대충 만들면서 진행했다고 생각한다. 지금 생각하면 요구사항 정의서랑 인터페이스 명세서가 진짜 중요하다고 느꼈다. 이걸 잘 만들어놔야 프론트와 백엔드의 소통 충돌이 발생할 확률이 현저히 낮아진다…

개발

원래는 백엔드 개발자를 지망했지만 2인 플젝을 진행하면서 백엔드, 프론트엔드로 파트를 나눌 수가 없었다. 그래서 둘 다 풀스택으로 프론트와 백엔드를 같이 진행했다.

회원가입을 진행할 때 가장 걸렸던 부분은 프로필사진을 업로드 하는 부분이었다.

내가 생각했던 방법은 프로필 사진을 업로드하면 유저의 현재 화면에서도 프로필사진을 보여주고싶었다. 유저가 사진을 업로드하면 백엔드로 axios 요청을 보내고, 해당 사진을 백엔드 로컬에 저장시키고 클라이언트에게 사진 이름을 반환시켜서 미리보기로 보여주게 만들었다.

근데 지금 생각해보니 회원가입도 진행하지 않았는데 왜 로컬에 저장시켰지? 라는 의문이 든다.

사실 미리보기도 프론트 자체에서 처리가 가능할텐데 이 당시에는 그걸 몰라서 2일정도 소요했던 기억이 든다.

또한 삭제로직의 경우 전부 물리적 삭제를 진행했다. 나중에 알고보니 데이터는 중요한 부분이라 기업에서는 대부분 논리적 삭제를 진행하다고 들었다. 사실 아예 데이터를 지우는 게 개발자 입장에서는 굉장히 편하기도 했지만, 언제 이 데이터를 사용할 지 모르니 논리적 삭제를 하는 게 맞다고 생각이 든다.