본문 바로가기

GDG BE 프로젝트 트랙

GDG 프로젝트 트랙 4기 BE 최종 회고 FIL

7,8 주차 : 
게시글 작성 지역 도메인과 연동
지역 인증과 각 지역 테이블 DB가 완성됨에 따라, 게시글 CUD 기능을 수정했다.
 
S3 uploader 설정
스프링의 의존성 주입 기능을 잘 활용해서 로컬 환경, 배포 환경에 따라 방식을 다르게 해서 구축했다.
그냥 연결하면 되는 줄 알았는데 기존에 그냥 외부 사이트 이미지 url을 넣는 식으로 주먹 구구식 구현을 한 탓에, 이미지 파일을 S3 서버에 올리고 객체 url을 받아오는 구조로 바꾸면서 많은 파일들의 수정이 있었다.
 
S3 액세스 키를 넣는 김에 기존 서버의 환경설정 파일도 수정했다. 기존에는 yml 파일에 키를 작성했는데, .env파일에 실제 키를 작성하고 yml 파일에서 가져오는 형태로 바꾼 후 수정 사항 반영을 위해 다시 docker compose를 재실행했다. 
 
이후에는 프론트에서 화면과 기능을 붙이고 연동하면서 발생하는 오류를 서로 소통하면서 계속해서 수정하는 과정이었다. 여러 수정이 있었다. 그 중 가장 오래걸렸던 수정은 DB 상에서는 삭제 되었는데 S3 상에서는 삭제되지 않는 파일(Orphan 파일) 오류였다. 원인은 트랜잭션 수행 중 오류가 발생해 트랜잭션 롤백이 일어나는 것이었고, 살펴보니 게시글 수정 이미지 파일 변경 로직에 문제가 있어 로직을 수정해 해결했다.
또한 프론트에서 현재 로그인한 사용자의 좋아요, 스크랩 표시 상태관리를 위해, 현재 로그인한 사용자의 좋아요, 스크랩 여부 필드를 추가해달라고 해 마감일 새벽에 긴급하게 진행했다. DTO에 필드 2개 추가하고 나머지 조회 메서드 조금 수정해주고 CurrentUser로 유저 id 정보 받아와서 테이블 조회하면 뚝딱할 줄 알았는데, 기존에 조회 로직에서 인자를 CurrentUser가 아니라 Httpservlet으로 받아오고 있어서 보안과 설계적인 이슈로 같이 수정했다. 생각보다 많은 파일을 수정하느라 결국 덕분에 그 날 아침 9시에 로컬 테스트에서 문제 없는 걸 확인하고 재배포할 때까지 잠을 자지 못했다. (신기하게도 머지 충돌은 안 났음!)
심지어 데모데이 직전에 프로필 이미지 기본 수정이 안 되는 문제가 발견되서 급하게 수정하기도 했다. 그래도 이건 S3에 직접 이미지를 넣어주고, 프론트와 API 명세를 다시 맞춰보니 간단하게 해결되었다.
CI/CD를 구현하지 않은 죄로 이 모든 수정에 수동 재배포를 반복했다... 그래도 생체 재배포로 3분 컷하는 경지에 이를 수 있었다.
 
발표 준비
발표 준비할 때 고민이 많았다. 최종 데모데이인데 사업 시연처럼 해야하는지, 사용한 기술에 대한 설명이나 기술적인 난관 극복에 초점을 맞춰야 하는지 말이다. 다른 동아리의 데모데이 발표자료를 레퍼런스로 참고하면서, 전자에 초점을 맞추되, 후자를 간단하게 언급하는 식으로 최종 결정해 발표를 준비했다.
 


 
 
그렇게 많은 밤샘 끝에 드디어 프로젝트가 끝이 났다. (위에선 생략했지만 주에 3,4회씩 만나 작업하고 마지막에 다가와서는 밤새거나 하루 2,3시간 자는 일이 비일비재했다.)
일단 프론트, 백엔드 모두 배포까지 성공했고, 기본적인 기능들은 굴러간다는 점에서 칭찬하고 싶다. 특히 프론트의 경우 지도에 경로와 게시글 화면을 같이 연동해서 띄우는 것이 정말 어려웠을 것 같은데 너무나 잘 구현해 주셨다. 또 오류가 발생했을 때에도 프론트 분들이 천천히 하시라고 편안하게 대해주시고 새벽에도 서로 오류 수정하기도 해서 마음 편히 작업할 수 있었던 것 같다. 
 
백엔드를 처음 하면서 익히게 된 것들이 많았던 것 같다.
일단 여러 백엔드의 여러 기술이나 이슈들에 대해 알게 되었다. 최근에 it 연합 동아리에 지원하면서 면접 준비할 겸
프로젝트 하면서 어떤 기술을 활용했고, 기술적 난관들을 어떤 식으로 해결해왔는지를 정리 중인데 프로젝트 트랙에 참여하기 전보다 확실히 성장했음을 여실히 느낄 수 있었다.
N+1 문제, 트랜잭션 롤백 등 백엔드에서 자주 발생하는 문제들도 경험할 수 있었다.(동시성 문제는 아직 경험 못 했음)
JPA, QueryDSL, Docker, AWS EC2, AWS ECR, AWS S3 등 용어로만 들어본 기술들을 실제로 써보고 도메인 설계 및 개발, 배포까지 일련의 과정을 경험하면서 백엔드 프로젝트의 전체 과정을 경험해 볼 수 있어서 좋았다.
 
아쉬운 점들도 당연히 있다. 하지만 아쉬운 점들에서야 말로 배워갈 것들이 많았다.
 
내가 작성하지 않은 코드에 대해 서로 어떤 원리로 구현했는지 많이 공유하지는 못한 점이 아쉬웠다. 서로 기술적으로 소통하면서 가끔 캐치가 늦어질 때의 대부분은 서로 작성하지 않은 코드에 대한 이해 부족인 경우가 많았다. 다음에 프로젝트를 한다면 코드 리뷰를 통해 이 문제를 해결할 수 있지 않을까 싶다.
 
초반에 ERD 설계와 API 명세 작성에 공을 좀 더 들이고 했어야 했는데 그러지 못했던 점이 아쉬웠다. 나중에 구조도 바꾸고, 프론트랑 열심히 소통해서 해결하긴 했지만, 확실히 API 명세가 조금씩 수정되거나 새로운 API가 추가될 때마다 프론트 분들께 미안한 점들이 있었다. 특히 마감 일정이 다가왔을 때 ㅎㅎ. 그래도 개발 일련의 과정을 겪으면서 어떤 일을 할 때 명세가 바뀔 수도 있다는 것들을 깨닫게 되서 앞으로 할 프로젝트에서는 좀 더 이 부분에 있어서는 시행착오를 덜 겪을 수 있을 것 같다. 
 
백엔드 배포가 처음이기도 하고, 힘든 과정이라는 말이 많아서 걱정하느라 프론트 배포 쪽에는 신경을 못 썼다. 솔직히 맨날 프론트 배포는 5분 컷이에요 라는 말을 들어서 얕본 것도 있는 것 같다. 데모데이 전날에 모든 기능 수정을 마치고 프론트 배포를 하면서 프론트 배포도 일찍 일찍 해야한다는 것을 알았다. 일단 로컬과 배포는 환경이 다르다. 환경이 달라지면 알 수 없는 오류가 발생하기도 한다. 마지막에 프론트 배포에 맞춰 백엔드도 CORS 설정을 다시 해서 재배포해야 했는데 하필 그 때 컴퓨터 용량 부족으로 한참 애먹었다.
 
거기에 더해 프론트 쪽에서도 브랜치가 꼬이면서 기존 작업 분이 날라가는 사태도 마지막 날에 발생했었다. 브랜치 관리도 미리 미리 하자. 나중에 하려면 코드가 서로 더 많이 바뀔 때도 있고 골치가 아프다. 그래도 백엔드는 초반에 내가 한 번 로그인/회원가입 코드 건드리면서 했다가 전체적으로 꼬이는 시행착오를 한 번 겪고 다시 밀고 진행했을 때는 서로 작성한 코드는 모듈처럼 사용하는 식으로 해서 큰 문제가 발생하지 않았다. 이건 좀 잘한 듯 ㅋㅋ
 
결론은 앞으로는 마지막 1~2주는 코드 프리즈 하고 여태 발생한 오류를 잡는 것만 해도 충분할 것 같다. 사실 원래 계획에 못해도 3일 정도 코드 프리즈를 염두해두었었는데 다들 마지막에 기능을 조금이라도 더 수정하고 붙이려다 이런 사태가 발생했었다. 다음에 프로젝트를 한다면 의식적으로 데모데이가 1주 앞에 있다고 생각하고 시작하면 좋을 것 같다.
 
하지톤을 보면서 참가자 분들이 로그인/회원가입을 1시간 만에 뚝딱 하시는 것을 보고 신기했다. 물론 어느정도 생략된 보안 수준으로 진행했겠지만, 확실히 내게 그 모습은 인상적인 모습으로 다가왔다.
단순 CRUD 찍어내기, JWT 기반 로그인/회원가입 등은 템플릿 화해서 나중에 해커톤을 가면 뚝딱할 수 있는 사람이 되어야 겠다.
 
또한 이번에 프로젝트를 하면서는 알면서도 잘 적용하지 못했던 것이 있다. 바로 기술을 사용하면서 사용하는 이유가 있어야 한다는 것이다. 솔직히 QueryDSL을 사용했던 이유에는 태그, 지역 필터에 대한 조회 기능을 JPA로 구현하려면 까다로워서 사용했던 것도 있지만, 옛날 프로젝트 피드백이나 해커톤에서 잘하는 분들이 QueryDSL을 사용해서 좋은 기술이니까 나도 써야지 하는 심리도 컸었던 것 같다. 면접을 보면서 확실히 그냥 어떤 기술을 사용하는 지로는 많이 부족하다고 느꼈다. 어떤 기술의 장점과, 그 사이드 이펙트까지 고려할 줄 아는 개발자가 되기 위해 앞으로 의식적으로 생각하고 실천해야겠다. 
 
또한 TDD나 DDD, 대규모 시스템 설계 등 여러 기법들이 많다. 이제 그래도 한 번 백엔드 프로젝트를 경험해 보았으니 이런 기법들을 적용해보면서 진짜 백엔드 고수로 거듭나야겠다.
 
마지막으로 어떤 집단에 가더라도 좋은 영향을 미칠 수 있는 사람이 되어야 겠다고 생각한다. 내가 어디에 소속되어 있고를 따지기 보다는 내가 어디 있더라도 좋은 영향을 줄 수 있는 사람이 되어 열심히 한다면 위치와 상관없이 좋은 결과를 내는 데 무리가 없을 것 같다.