성공적인 '축하해요' 회고

축하해요 링크 (2024.08.15 종료 예정)

배포도 완료하고, 파비콘까지 적용한 귀여운 우리 프로젝트의 메인 화면이다. 프리티어이기 때문에, 당분간은 서버를 띄워 둘 예정이다.

성과

이번 발표는 옆 반 사람들도 와서 구경했는데, 우리팀이 발표하고 난 후 모두가 우리팀 얘기만 했다고 한다(우리팀은 2팀이다).

저 카톡을 받고 매우 뿌듯했다.

성공 요인

우리 프로젝트의 성공 요인은 아무래도 '팀원 간의 단합'이지 않을까 싶다. 팀원들끼리 모두 친하고, 자연스레 좋은 분위기 속에서 개발이 이루어졌기 때문이다.

특히, 'clap'이라는 팀 문화 때문에 항상 웃었고, 감정이 상할 일이 생기지 않았던 것 같다.
(그냥 좋은 일이 있으면 clap~ 이라고 외치면서 모두 박수를 쳤다.. 강사님까지 같이 칠 때도 있었다 ㅋㅋㅋㅋ 하루에 박수만 10번은 넘게 친 것 같다)

또한, 발표자가 발표를 정말 잘 해주었다. 모든 팀이 쇼핑몰이라는 주제 하에 개발을 진행하였기 때문에 관리자 페이지, 로그인 로그아웃 등의 기본적인 기능은 모두 동일했다. 시연 때에 모든 팀에서 같은 기능을 설명했기 때문에 자칫하면 발표가 지루해질 수도 있었는데, 빠른 템포와 정확한 딕션으로 발표를 진행해 주었다.

그리고 중간중간 끼워넣은 재미 요소 덕분에 집중력이 흩어지지 않았던 것 같다.
(당일이 회식날이라 '회식 초대 카드'를 만들어서 단톡에 전송, 강사님 생신 축하 카드 시연)

회식 초대 카드

감사하게도 사람들이 방명록도 많이 남겨 주었다.

강사님 생신 카드

멘트를 재미있게 넣었다

개인적으로 노력한 점

클린 코드

controller는 간단하게, service에서는 모든 예외처리 및 기능 구현을 해 주려고 노력하였다. 최대한 각 계층별에서 수행하는 기능을 코드에 녹이려고 노력했다.

또한, 아키텍처에 대한 고민도 많이 하였고(같은 기능은 같은 패키지에, 공통된 것은 따로 빼서 호출해서 사용), 초반 설계 이후 강사님께 가서 피드백도 받았다.

하나의 메소드가 하나의 기능만 수행하도록, 그리고 결합도를 낮추려고 신경을 많이 썼다. 그렇다고 모든 기능을 분리한 것은 아니고 항상 같이 쓰여야 하는 기능은 하나의 메소드에 같이 넣어 주었다.

효율성

ERD 설계 시 조회속도를 많이 따져보았다. 초반에는 각 테이블에 많은 요소가 들어가는 것이 안좋을것이라 생각하여 join을 많이 했었다. 의도적으로 정규화를 한 것이다.

하지만, 실제로는 하나의 DB만 조회하는 것이 속도가 더 빨라 데이터가 중복되더라도 조회가 자주 일어나는 것들은 한 테이블에 같이 저장한다고 한다. 이번 프로젝트에서는 반정규화를 적용시켜 조회 속도를 높였다.

프로젝트에서는 유저의 수와 DB에 저장된 데이터의 양이 많지 않아 프로젝트 수행 시에는 속도 차이가 나지 않아 눈으로 보이는 비교를 해 볼 수는 없었다..ㅠㅅㅠ

보안성

에러 페이지, 예외처리 및 에러처리, git ignore, 환경변수 사용 등 보안에 많이 신경을 썼다. 특히 우리의 축하카드는 카드를 만든 사람이 url을 통해 공유할 수 있었는데, 보는 사람은 로그인 없이 볼 수 있다. 즉, url만 있으면 모두가 접근이 가능한 것이다. 단축 url을 사용하긴 했지만, 단축 url로 접속하면 원본 url이 보인다. 원본 url은 getmapping을 사용하였고, ~/cardId 와 같은 형태였기 때문에 cardId를 변경하면(URL Manipulation) 타인의 카드를 조회할 수 있었다. 그래서 이 url을 암호화하여 사용자에게 보여주고, 암호화 한 url로 get요청이 들어오면 서버에서 복호화하여 보여주도록 하였다.

리팩토링

개발이 끝난 후 나의 코드에 대한 평가를 받고자 강사님께 가서 피드백을 부탁드렸었다. 나는 초반에 모든 상황에 대한 예외 처리를 해 주었었는데, 실무에서는 이렇게 하지 않는다는 피드백을 받아 코드를 리팩토링 해 주었다.

예를 들어, 나는 DTO에서 DB로의 변환을 실패한 경우에도 예외 처리를 해 주었는데, 실무에서는 DB에 저장하는 로직이 너무 당연하게 작동되어야 하는 기능이기 때문에 실패하는 경우가 없도록 초반부터 코드를 작성해야 한다고 말씀해 주셨다.

내가 ErrorCode를 Custom하는 경우는 API를 사용할 때가 대부분이라고 한다. 그래서 아래와 같이 API를 사용하는 부분만 예외처리를 해 주었고, 나머지는 예외처리 로직을 지워 주었다.

최종 소감

그동안 적지 않은 프로젝트를 해 왔지만, 코드 상으로 가장 완성도가 높다고 느껴지는 프로젝트였다. github actions는 처음 해 보았는데, 이마저도 다짜고짜 인터넷을 찾아서 따라하는 것이 아닌, 원리부터 꼼꼼히 이해하며 우리의 프로젝트에 맞게 작성하였기 때문에 지식적으로도 완성도가 높은 것 같다. 다음 프로젝트 때에는 팀원 모두가 리팩토링을 진행하고, 무중단 배포 및 Https 인증서 발급도 진행하여 더 완성도 높은 서비스를 개발 할 것이다.