[싸피일기] 1학기 관통 프로젝트 진행 과정 및 회고

 

 

 

 

팀 빌딩 

 

 

 

팀 빌딩을 하기 전, 1분 정도의 자기 소개 시간을 가졌다. 함께 5개월 가까이 공부해온 사람들이기때문에, 나에 대해 길게 소개하는 것보다는 내가 어떤 스타일로 일을 하고자 하는지를 중점적으로 이야기하고자 했다.

 

짧은 기간동안 진행되는 2인 규모의 프로젝트이지만, 무작정 개발하는 것이 아니라 실제 개발하듯이 기획과 설계 과정을 충분히 거치고 싶었다. 협업을 경험하면서 이 부분이 소홀해지면 협업 과정이 더 복잡해질뿐만 아니라 결과에도 아쉬움이 생긴다는 것을 느꼈기 때문이다. 그리고 다른 팀들보다 기획과 설계에 시간을 투자하려는 만큼 9-6 이외의 시간도 개발에 할애할 수 있었으면 했다.

 

 

 

 

 

 

 

프로젝트 일정과 개발 환경

 

 

 

익숙한 프레임워크인 spring boot와 vue3를 기반으로 프로젝트를 진행하되, 오픈 API와 AWS를 접목해보았다. 프로젝트에 사용된 API는 카카오 API, 유튜브 API, GEMINI API 총 세가지였고, AWS EC2에서 프로젝트를 배포하기 위해 NGINX또한 사용되었다.

 

 

 

 

 

 

다른 팀들의 경우 Open AI의 API를 많이 사용하였는데, YOUTUBE API를 활용하는 우리 프로젝트에서는 최신 검색에 강점을 가지고 있는 GEMINI API가 더 어울린다고 생각해 독자적인 길을 걸었다.

 

실제로 더미 데이터 생성을 위해 유튜브 영상을 요청했을 때 챗GPT 3.5는 현재는 재생이 불가능한 영상을 결과물로 제시했는데, GEMINI는 유효하지 않은 URL인지를 바로 확인할 수 있었다.

 

 

 

 

 

 

 

 

또한 서로 간의 소통 및 기록은 노션 워크스페이스를 활용했다. 우리 페어의 경우는 업무 일지도 작성하였는데, 서로 간의 진행 상황을 확인할 수 있어서 협업에 큰 도움이 되었다.

 

 

 

 

 

 

 

프로젝트 기획

 

 

기획 단계에서는 간단한 리서치 및 분석을 바탕으로 요구사항 정의서를 작성하고, 우리 제품을 사용했을 때와 사용하지 않았을 때의 유저 저니맵을 작성하였다.

 

 

 

 

 

제품 요구사항 정의서

 

 

제품 요구사항 정의서에서는 기능적 요구사항을 must / should / could 로 구분하였는데, 이는 실제 우리 프로젝트의 개발 우선 순위에 반영되었다. must와 should로 구분했던 요구사항은 모두 구현하였지만, could에 있던 다크모드나 팔로우/팔로잉 기능의 경우 추후 우리 프로젝트와 어울리지 않는다고 판단하여 구현하지 않았다.

 

 

 

 

 

 

프로젝트 설계 

 

 

기능 명세서까지는 함께 한 자리에서 작성하고, 이후 분업을 위해 와이어 프레임 / ER 다이어그램과 API 명세서로 담당을 구분하여 작성하였다. 작성은 담당자가 하였지만, 중간에 줌회의나 오프라인 회의를 통해 피드백을 꾸준히 주고 받았다.

 

 

 

 

 

 

 

 

 

ER 다이어그램의 경우, 작성하면서 정규화를 적용하기 위해 노력했다. 도메인의 원자성을 지키기 위해 N : M 관계의 테이블의 경우 중계 테이블을 추가하였으며, 유저의 경우 level 컬럼이 유저가 아닌 exp에 대한 종속성을 가지기 때문에 컬럼을 삭제하였다. 

 

 

 

 

 

 

 

 

API 명세서의 경우 HTTP METHOD와 API path, request와 response의 데이터를 중심으로 작성하였다. 실제 개발을 할 때도 항상 API 명세서를 켜놓고 작업을 했다. 개발 전 api 명세서가 잘 잡혀 있으니 프론트와 백이 소통 오류가 날 일이 거의 없어서 편했다. 

 

 

 

 

 

 

 

프로젝트 개발 및 배포

 

 

프로젝트 개발과 배포는 KPT  회고 방식으로 정리해보고자 한다. keep은 만족했으며 계속 이어갔으면 하는 부분, problem은 불편을 느껴 개선이 필요한 부분, try는 problem에 대한 해결책으로 관점을 나누어 정리할 것이다.

 

 

 

KEEP 

 

 

1. 테스트를 기반으로 한 신뢰성있는 백엔드 CRUD 구현

 

프로그래밍에서 가장 중요한 것은 뭐니뭐니해도 정확성이라고 생각한다. SWAGGER를 활용해 각 API에 대한 기능 테스트를 진행하면서 개발했고, 개발 이후에도 최대한 테스트 기간을 확보했기 때문에 디버깅을 통해 신뢰성 있는 프로그램을 개발할 수 있었다. 

 

 

 

2. 알고리즘을 활용한 보안 및 성능 개선

 

우선 CS를 공부하면서 프로젝트에 크립토그래피를 적용해보고 싶었는데, KISA에서 배포한 코드를 활용하여 SHA-256 알고리즘을 로그인 및 회원가입에 적용해볼 수 있었다. 또한 유저가 참여한 챌린지에 대해 비디오마다 개별적인 complete 여부가 데이터에 포함되어야 했는데, 이 부분에서 별도의 테이블을 구축하는 대신 비트 마스킹을 적용하여 구현하였다.

 

 

 

3. 외부 API를 활용한 사용자 경험 개선

 

개발에서 나의 주 역할은 백엔드였지만, 외부 API의 경우 CSS를 제외한 프론트까지 맡았다, (CSS의 경우 일관성 있는 적용을 위해 프론트 담당자가 사용한 코드를 그대로 재사용하였다.)

 

처음 기획단계에서는 유저가 영상을 등록할 때 직접 영상의 url을 입력하는 방식으로 구현하고자 했다. 하지만 프로그램을 개발하면서, 이 부분이 사용자에게 굉장히 번거롭게 느껴질 수 있겠다는 생각이 들었다. 그래서 중간에 유튜브 API를 추가하여 사이트 내에서 영상을 검색해 추가할 수 있도록 변경하였는데, 실제로 직접 테스트만 해봐도 훨씬 등록 절차가 간결해졌다는 것을 느낄 수 있었다.

 

또한 영상에 대한 설명을 사용자가 직접 작성하는 것이 아니라, AI가 생성하고 이 결과를 토대로 사용자의 자연어 요청에 따라 영상을 추천받을 수 있도록 GEMINI API를 적용하였다. 마지막으로, 자체적인 회원가입을 원치 않는 유저를 위해 카카오 API를 적용해 카카오 로그인이 가능하도록 했다. 

 

 

 

 

 

PROBLEM AND TRY

 

 

1. MVC 아키텍처에 있어서 컨트롤러와 서비스의 명확한 경계 부족

 

처음 작업한 컨트롤러에서는 데이터에 대한 조작이 어디서는 컨트롤러에서, 어디서는 서비스에서 구현되었다. 이후 컨트롤러의 규모가 커지면서 여러 서비스에 대한 의존성을 주입하게 되었는데, 컨트롤러단에서 구현된 부분에 대해서는 중복된 코드를 작성해야만 했다. 중복된 코드나 오류를 피하기 위해서는 컨트롤러와 서비스의 명확한 역할 구분이 필요하다고 느꼈다.

 

 

 

2, 적절하지 않은 API 키 보관

 

깃허브의 private repository를 이용해서 협업을 했기 때문에, API 키가 하드코딩 되어 있어도 큰 문제는 발생하지 않았다. 하지만 보안을 위해 .env.local이나 config.properties를 활용해 키를 보관하는 습관을 들일 필요가 있다.

 

 

 

 

3. AWS EC2 서버에 구축된 DB

 

ec2 서버에 mysql, springboot, vue까지 모든 프로젝트를 실어두었더니 1기가 램이 버티지를 못해서 퍼지는 경우가 종종 있었다. 급하게 발표날 아침 스토리지를 ram으로 일부 전환해서 사용했지만, 추후 프로젝트 진행시에는 RDS를 이용해 별도의 DB서버를 구축해 서버의 부담을 줄여야 할 것이다.

 

 

 

 

 

 

 

 

 

마무리

 

 

 

 

3주라는 짧은 기간이지만 치열하게 고민했던 프로젝트가 끝났다. 마음대로 되지 않아 속상하고, 체력적으로 힘든 날들도 있었지만 그럼에도 불구하고 즐겁고 행복한 시간이었다.