[우테코] 레벨로그: 레벨3 동안 공부한 내용들을 정리하며

 

 

 

⭐ 레벨3 인터뷰를 준비하며

레벨3은 그간 레벨1, 레벨2와 다르게 팀프로젝트로 진행되었다. 

그간은 좀 강의나 책 내용을 학습하면서 작은 프로젝트에 적용하면서 공부했기 때문에 먼저 개념을 배우고 예제를 풀어나간 느낌이었다면,

레벨3는 프로젝트를 진행하면서 해당 프로젝트에서 적용해야 할 문제점을 위해서 공부를 했달까..? 

더 당장에 필요한 내용을 공부했기 때문에 와닿았던 것 같다. 

 

💋 서비스 기획

✔서비스 기획의 중심점은 페인 포인트

• 팀원들의 모든 상상과 욕심이 합쳐져서 매우 어려운 요구사항이 도출됨. 
• 우리 팀이 마주한 고객의 페인포인트는, 카페 사장 측의 '개성', 그리고 카페 이용 고객의 '편리'에 대한 부분이었음.
• 카페 사장의 개성을 구현하기 위한 자유도를 꽤나 과감히 포기하면서 본격적으로 기능 구현을 시작할 수 있었음.

 

💋 팀 문화

✔ 혼자만의 고민 대신 Discussion 활용

• 개발 도중에 느낀 구조 상의 개선점, 인프라 구성같이 팀원 전체의 논의가 필요한 내용들을 Github Discussion을 통해 논의하고, 기록함.

 

💋 API 설계

✔ API 설계는 재사용성을 고려해서 

• 현재 우테코 프로젝트는 정해진 클라이언트와의 약속된 플레이로, API의 스펙이 화면에 보여지는 내용에 어느정도 의존적일 수밖에 없다고는 생각함. 
• 하지만, 복잡한 요청을 여러 번의 API 요청으로 나누었더니 재사용성이 크게 향상됨. 

✔ 예외 상황에 대한 정의

• 정의한 API의 목적에 따라서 예외 상황으로 규정할 지 여부가 달라짐.
  • 예를 들어, API의 목적이 전화번호로 고객을 '조회'하는 것이라면, 필터링 조건을 통해서 조회가 되지 않은 상황에는 예외라고 규정하기보다는 빈 리스트를 반환하도록 설계함. 

 

💋 도메인, 테이블 설계

✔ 테이블 설계

• 카페 사장이 원하는 때에 리워드 지급 정책을 변경할 수 있다는 가정 하에 테이블이 설계됨.
  • 예) 8개의 스탬프를 찍으면 아메리카노 1개 증정 -> 10개의 스탬프를 찍으면 아메리카노 1개 증정으로 변경
• 한 번 쿠폰을 발급했다면, 유효기간이 만료되기 전까지는 해당 쿠폰의 정책과 디자인을 유지해야 함.
• 위와 같은 주요 특징을 바탕으로, 쿠폰을 새로 발급할 때 당시의 정책과 디자인을 참조 형태가 아닌, 직접 복사해서 넣어놓는 형태로 테이블을 설계함. 

✔ 도메인 설계

• 작성한 테이블 구조를 바탕으로 Entity를 최대한 활용해 도메인으로 사용함.
• Entity에서 최대한 많은 메세지를 직접 처리할 수 있도록 코드를 작성함. 

 

테이블 구조 (참고)

 

💋 테스트 코드 

✔ 테스트 코드 규칙 정하기

• 팀원들과 협의 하에 아래와 같이 규칙을 정함.
  • 인수테스트 - 모두 실제 빈을 사용해서 테스트함
  • Slice Test - 해당 레이어를 제외한 나머지 레이어는 Mocking한 빈을 사용해서 테스트함
  • Repository 테스트 - Data Jpa Test를 사용해서 직접 작성한 메서드에 대해서만 테스트함

✔ 테스트 코드 속도 개선

• Slice Test의 경우, MockBean을 공통으로 사용할 수 있도록 상위 클래스를 만들어서 상속받는 방식으로 활용함.
• 인수테스트의 경우에도, 상위에 web 환경을 정의한 클래스를 생성하고, 상속받는 방식으로 활용함.
• 위와 같은 노력으로 깃허브 액션 기준 테스트 코드 시간이 2초 정도 개선됨. 

✔ 테스트 코드 편의를 위한 작업

• 한글로 메서드 명을 작성했기 때문에 한글과 관련된 warning과 display 관련 어노테이션을 분리함.
• 웹 환경에서 테스트 시에 테스트 간 데이터를 격리하기 위한 BeforeEachCallBack 인터페이스를 활용함.

 

💋 Submodule

• Submodule을 통해서 secret을 담은 설정 파일을 분리해서 관리함. 

 

💋 일정 추정

✔ 매 스프린트마다 기능 개발의 우선순위 정하기

• 우선순위 선정 역시 >페인 포인트<가 가장 먼저 고려해야 할 사항이었음.
  • 디테일은 뒤로 미루고, 페인 포인트를 해결해서 진통제 같은 서비스가 되는 것을 최우선으로 삼음.
• 다음 고려사항은, 사장모드 - 고객모드로 이어지는 한 사이클의 구성이었음.

 

💋 인프라 구성

✔ EC2 서버 할당

• 데이터베이스 서버, 운영 서버, 개발 서버, 인프라 서버로 분리해서 4대의 EC2를 사용함.
• 모든 EC2의 메모리 부족에 대비해 Swap Memory를 할당함. 

 

💋 배포

✔ 배포 자동화

• 깃허브 액션을 사용해서 테스트 통과 여부에 대한 CI를 선행해서, 테스트가 모두 통과해야 코드를 병합할 수 있도록 강제함.
• 인프라 서버 내에서 도커를 통해 젠킨스를 설치했고, CD 과정은 아래와 같은 Stage가 있음.
  • GitHub - 깃허브 웹 훅으로 코드 변경을 감지함 후에 젠킨스 내에서 git pull함.
  • Build - pull할 파일로부터 jar 파일을 빌드함
  • Deploy - 배포 서버로 빌드된 파일을 전송하고, 배포 서버 내에 있는 배포 스크립트 실행을 통해서 jar 파일을 실행함. 

✔  배포 자동화에 장애 발생 대응을 위한 수동 배포 스크립트 작성

• 프로젝트 진행 중에 작동하던 젠킨스에 장애가 발생함.
• 위와 같은 경우가 또 발생할 경우에, 언제든 팀원들이 최신 코드로 재배포를 할 수 있도록 수동 배포 스크립트를 작성함.

 

💋 회원가입 / 로그인

✔  OAuth 2.0

• 간편한 회원 관리를 위해 카카오 로그인 채택
• 리소스 서버로부터 액세스 토큰을 발급받는 것이 목적
• 액세스 토큰을 발급받아 리소스 오너의 리소스에 접근