231027 코드스쿼드max 자유 프로젝트 3주차 회고

이번주야말로 월요일부터 기능 구현을 들어가려고 했지만 다음과 같은 몇가지 과정이 추가되어 예상보다 일정이 늦어져서 실질적인 구현은 수요일부터 들어가게 되었다.

 

구현이 늦어진 이유

1. API 및 기획적인 부분을 마무리 짓고 스프린트를 정했다. (+ FE)

일을 효율적으로 진행하기 위해서 백엔드 멤버들이 먼저 API를 짜놓고, 프론트 멤버들이 확인해주시기로 했었는데, 거기서 드는 의문점과 조율이 생각보다 길어졌다.

구현에 빠르게 들어가기 위해서 자잘한 부분들은 고민을 길게 하지 않고 넘어가기로 했다.

이 부분에 대해서 호눅스에게 여쭤보니, 우리들이 경험이 부족해서 아직 잘 모르니 정확한 판단이 서지 않는 것이라고, 일단 기능이 돌아가는 것 자체가 중요하기 때문에 기능을 어설프게나마 만들어 놓고, 그 이후에 문제점들을 개선하는 것이 좋겠다는 피드백을 얻었다.

 

또 프론트엔드와 백엔드의 스프린트(프로젝트 진행)를 같이 가져가면 좋을 것 같아서 조율하는 시간을 가졌다.

- 이유1: 브라우저와 서버 사이에 발생하는 에러를 사전에 발견할 수 있다.

- 이유2: 공식적인 프로젝트 마감일은 다음주이기 때문에 다른 프로젝트를 진행하는 코쿼 멤버들에게 하나라도 완성한 기능을 보여줄 수 있다.

2. Entity 설계 시 FK 설정에 대해 모르는 부분이 많아서 고민했다.

(ex. @OneToMany, cascade, mapped, embedded 등등...)

나 혼자 Entity 설계를 했더라면 모르고 넘어갔을 부분이었는데 이안이 알려줘서 가볍게 이해하고 넘어갈 수 있었다.

하지만 확실하게 이해한 것은 아니기 때문에 나중을 위해서는 추가 공부가 필요할 것 같다.

- ERD 작성과 프로젝트 환경 설정은 비교적 빠르게 끝냈다.

3. 코딩 컨벤션을 정해놓았는데, 도중에 변경이 있었다.

- DTO <-> Entity 객체 변경하는 과정에서 정적 팩토리 메서드 패턴을 이용하여 객체를 생성하자고 했었는데, 객체의 생성 책임을 다른 객체에 위임하면 좋을 것 같아서 이전 프로젝트에서 사용했던 mapstruct를 사용하는 것으로 변경을 제안했다.

- mapstruct의 장단점을 자세히 알고 나서 변경하자고 제안하면 좋았을 텐데 잘 모르고 제안한 것이다 보니 자세한 설명 없이 다른 팀원들에게 바꾸자고 이야기 해서 서로 mapstruct에 대해 알아보느라 시간이 걸려서 아쉬웠다.

4. 서브 모듈 적용해보기

application.yml을 기능별로 관리하기 위해 application-dev.yml, application-prod.yml, application-cloud.yml 등등으로 분리해서 사용했다.

이전 프로젝트에서는 보안을 위해 yml을 깃헙에 올리지 않는 대신에 yml에 대한 설정이 바뀌면, 팀 노션에 따로 작성한 yml을 업데이트 하고, 로컬에 있는 yml에 해당 사항을 수동으로 업데이트 했다.

이렇게 관리하다보니 불편함이 생겨 서브모듈에 yml을 넣어 관리하는 것으로 변경했다.

서브모듈은 시오가 만들어서 사용방법을 알려줬는데, 이해하고 적용하는데에 시간이 좀 걸리긴 했지만, 기존에 수동으로 업데이트 하는 방식보다 확실히 편리했다.

5. HTTPS로 배포해보기

이 부분도 시오가 담당해 주었는데, 우리는 실제로 서비스를 배포해서 사용자를 모아볼 예정이기 때문에 HTTPS를 적용하기로 했다.

또한 HTTP로 하다가 중간에 HTTPS로 바꾸는 것은 어렵기 때문에 초반에 HTTPS를 적용해놓는것이 좋다는 호눅스의 피드백이 있었기 때문에 처음부터 환경 설정을 해놓으면 좋을 것 같다는 판단이 있었다.

빠르게 끝낼 수 있을 것 같다는 판단이 있었지만, 역시 보안과 관련되었기 때문에 그런지 오류가 많이 발생해서 예상보다 늦어졌다.

하지만 어떻게 보면 그 어렵다는 인프라 설정 및 HTTPS 설정을 3일만에 끝낸 것이므로 대단하다고 생각한다. (시오 짱!)

6. Point 타입을 DB에 저장하는데 에러가 발생했다.

프로젝트 환경 설정을 하는 김에 하나의 기능을 만들어 지표 삼아두면, 다른 기능을 동일한 형식으로 만드는데에 좋을 것 같아서 이안과 함께

검색어 자동완성 목록 조회 기능에 대한 API를 구현했다.

검색어 자동완성 목록 조회 기능은 검색어에 일치하는 공연장 목록을 조회하는 기능인데, 공연장에는 좌표 값(위치정보)이 들어있다.

해당 좌표 값을 저장하는데 Point 클래스를 사용했는데, 조회하는 부분에서 에러가 발생했다.

처음에 사용했던 Point 클래스는 spring boot에서 제공해주는 라이브러리였고 (import org.springframework.data.geo.Point), 에러를 해결하기 위해서는 hibernate가 제공하는 라이브러리(import org.locationtech.jts.geom.Point)를 사용해야했다.

또한 해당 라이브러리를 사용하기 위해서는 build.gradle에 hibernate-spatial에 대한 의존성을 추가해야했는데, 라이브러리 생성이 안되서 한참 헤맸는데 알고보니 버전도 기입해주어야 했다. (implementation 'org.hibernate:hibernate-spatial:6.2.5.Final')

 

고민했던 점

1. 프로젝트를 HTTPS로 배포할 예정인데, 비밀번호를 왜 또 한번 암호화 해야하는가?

우리의 프로젝트에는 로그인 기능이 필요하지 않아 구현하지 않을 예정이다.

그런데 문의 글 작성과 삭제 시에는 비밀번호가 필요한데, 문의 글 삭제 시에는 인증을 위해 비밀번호가 필요하다.

일반적으로는 클라이언트가 서버에 비밀번호를 전달 시, 비밀번호를 암호화 해서 보내는데, HTTPS 자체가 헤더와 바디 모두 암호화 해주는데 왜 비밀번호를 또 한번 암호화를 해야하는지에 대한 의문이 생겼다.

아직 해결되지 않은 의문점이다.

2. 이미지 업로드 하는 API를 분리를 해야하는가?

공연과 공연장 업로드 시, 이미지가 필요하다.

각각의 API에 이미지를 MultiPartFile을 받아서 업로드 하는 방법이 있고, 이미지를 업로드 하는 API를 따로 나누는 방법이 있는데 우리는 후자를 선택했다.

전자는 누락된 file이 있을 수 있고, 누락된 file은 s3에서 관리하기 힘들다는 이유에서이다.

- 이미지 업로드 API를 나누게 되면, 다음과 같은 룰을 넣어 누락된 file이 생기지 않도록 관리할 수 있다.

1) 이미지 업로드 API를 거쳐 S3에 업로드된 이미지는 미등록(unregistered) 상태로 DB에 저장된다.

2) 공연, 공연장 생성 시에 이미지 업로드 API로부터 반환받은 이미지의 Id 리스트를 등록(registered) 상태로 변경한다.

또한 전자는 공연, 공연장 수정 시에 이미지 순서를 바꾸면 해당 API가 복잡해질 가능성도 존재했다.

- 공연, 공연장 수정 시에 이미지를 새로 업로드 하면서 이미지의 순서를 바꾸면 데이터 타입이 섞이는 문제가 발생한다.

위에서 나열한 후자를 선택한 이유가 충분하지 않은 것 같아서 더 명확한 사유를 찾아서 기록하고 싶은데, 이는 구현하면서 해결하면 좋을 것 같다. (뭔가 머릿속에서 정리가 안된다🥲)

3. 카테고리 목록을 DB에 저장해야하는가?

각 레코드의(테이블의 row, 데이터) 목록을 관리하기 위해 카테고리(종류) 목록(테이블에 column이 추가 됨)이 생기게 되었는데, 이를 모두 DB에 저장해서 처리해야 하나? 하는 의문점이 들었다.

ex) 공연장에 들어갈 하이퍼링크의 종류(naverMap, instagram, official, etc...), 이미지 상태의 종류(registered, unregistered, deleted), 문의의 종류(서비스문의, 등록문의, 기타문의) 등등..

이에 대해 호눅스에게 여쭤봤더니 DB에서 관리해야할 특별한 이유가 있으면 DB에 넣어 관리하고, 특별한 이유가 없다면 Java에서 enum으로 관리해도 될 것 같다는 피드백을 얻었다.

때문에 여러가지 카테고리(종류) 중에서도 공연장에 들어갈 하이퍼링크의 종류는, 공연장 조회 시에 하나의 쿼리를 이용해서 하이퍼링크의 순서대로 정렬 후에 반환받기 위해서, DB에 따로 테이블을 만들어 저장하기로 했다.

 

 

4. 관리자의 비밀번호를 DB에 저장하려고 할 때, 꼭 서버를 거쳐서 암호화해서 넣어야 하는가? 직접 암호화해서 DB에 넣는 방법은 없을까?

관리자를 생성하려면 API를 만들어야 하는데, 관리자에 대한 우선순위는 낮기 때문에 (일단 사용자에게 제공 할 서비스 부터 구현해야 함) 해당 API에 대한 구현을 후순위에 넣었다.

하지만 공연장 생성, 공연 생성, 문의 글 생성 시에 관리자가 필요하므로 DB에 직접 관리자를 생성해서 넣어야 한다.

관리자 생성 API 없이(=서버를 거치지 않고) 관리자의 비밀번호를 외부에서 암호화해서 DB에 직접 암호화 된 비밀번호를 넣는 방법이 없을까? 라는 의문점이 들었다.

- DB에 비밀번호를 암호화해서 넣어야 하는 이유: DB가 해킹 될 위험성이 있기 때문.

아직 해결되지 않은 의문점이다.

 

5. N+1 문제 발생

메인 페이지에서 진행중인 공연 목록 조회하는 기능을 구현했는데, JpaRepository를 상속받은 ShowRepository에서 제공하는 기능을 조합하여 공연을 조회하는 조건에 맞는 메서드를 작성했다.

• 공연 시작 시간보다 현재 시간이 빠른 경우 조회
• 공연 종료 시간보다 현재 시간이 빠른 경우 조회
• 10개의 공연 목록을 조회한다.
• 공연 시작 시간이 빠른 순서대로 정렬한다.

공연장에는 포스터 이미지가 FK로 연결되어 있는데, 10개의 공연 목록을 조회하면 포스터 이미지에 대한 select 쿼리가 10개 생기는 것을 확인했다.

다음은 조건에 맞는 3개의 공연이 조회되는 쿼리이다. 3개의 공연에 따라 이미지를 조회하는 3개의 쿼리가 추가되는 것을 확인할 수 있다.

기능 개선보다는 마감 기간 안에 주요 기능을 구현하는 것을 우선순위로 두었기 때문에 해당 문제를 수정하지 못하고 있지만, 추후에 개선해보면 좋을 것 같다.

 

호눅스와 마지막 미팅

다음주면 공식적으로 코드스쿼드max 과정이 끝난다.

곧 본격적인 백수가 되기 때문에(ㅋㅋ..) 취업에 관한 불안한 점들이 많았는데, 호눅스 덕분에 복잡한 생각들을 좀 정리할 수 있었다.

앞으로 살아가는데 도움이 되는 말씀을 해주셨기 때문에 나도 불안할 때 다시 볼 겸, 간단히 정리해보았다.

 

1. 프로젝트에서 궁금했던 점들 질문

- 1. 카테고리 종류에 대한 테이블을 따로 만들어서 관리해야하나?

→ 명분 있으면 가능, 아니라면 그냥 java에서 enum으로 관리해도 된다.

 

- 2. 공연장 목록이 많아봤자 1000개가 안될 것 같은데, 10만개에 대한 성능 테스트 및 개선을 진행해야하나?

→ 테스트 해 볼 것이 1) 유저가 많을 때, 2) 데이터가 많을 때, 두가지 인데, 이 중에 그나마 테스트 해볼 수 있는 것이 2번이라고 생각되어 추천하셨을 뿐, 학습적인 관점에서 도움이 되리라는 입장이다.

 

- 3. 고민이 많아서 구현이 늦어지는게 걱정이다.

→ 아무거나 돌아가는걸로 일단 구현 먼저 하고, 나중에 개선하면 된다.

 

- 4. 프로젝트를 진행하며 중요한 점.

→ 이 프로젝트에서 무엇을 목적으로 하는가가 중요하다.

→ 내가 이걸 하는 이유! 무엇을 얻어 갈 것인가가 중요하다.

 

2. 취업에서의 고민 거리

1. 아직 취업 할 준비가 안 된 것 같아요. 제가 많이 부족한 것 같아요.

→ 회사 입장에서는 잘하는 애를 뽑는게 아니라 급한대로 고양이 손이라도 빌리는 느낌으로 채용한다. (잘 해야만 한다는 부담 가질 필요 없다)

→ 아직 취업할 준비가 안되었다는 느낌은 평생 가지고 갈 수도 있다.

→ 일희일비하지 말고 꾸준하게 가져가는 것이 좋다.

 

2. 이력서 어떻게 작성해야할지 고민이 돼요.

→ 짧은데 임팩트가 강하게 작성해야 한다. 남들과 비슷한 이력서는 X

→ 많이 보고 많이 쓰는 것이 중요하다.

→ 1) 많이 본다: 책을 읽는다, 남의 코드를 읽는다.

→ 2) 많이 쓴다: 제대로 된 문장으로 쓰는 연습을 하는 것이 중요하다. ex) 기술 블로그, 회고 작성

→ 단점은 숨기고 장점은 부각하는 것이 좋다. 하지만 솔직하게 작성하는 것이 나와 맞는 회사를 찾을 수 있다.

→ 이력서는 꾸미기 나름이다.

 

3. 기타

→ SI도 나쁘지 않다.

→ [책] 코딩인터뷰완전분석 좋다. 공부할 거리들이 많다.

→ 긍정적인 생각을 가지고 가라. 그럼 그 곳에 걸맞은 공부를 하게 되어서, 그 곳에 걸맞은 개발자가 될 수 있다. ex) 라인, 네이버, 카카오 …

 

- (비전공자이지만 네이버에 입사하신) Jane의 어떤 부분을 좋게 보셨는지 궁금해서 질문을 드렸다.

→ 성장이 빠르다, 회사에 도움이 되겠다, 동료들과의 시너지를 잘 낼 수 있겠다.. 등등 이 사람이 열심히 공부 했구나 라는 느낌을 받을 수 있었다.

(학벌, 성실, 꾸준, 성격, 글, 자소서, 잠도 3시간씩밖에 안자고,,, 등등 완벽했지만 실력만이 어엄청 좋아서 좋게 본 것은 아니다.)