1주 1스프린트 16회차 회고

이번 스프린트는 새우깡 스프린트다. 5개의 에픽을 진행했다.

순번	구분	에픽	시작 스프린트	에픽 완료 여부
1	웹사이트	1일 ?개 알고리즘 문제 풀기	1회차
2	스터디	회사 스터디	1회차
3	책	Real MySQL 8.0 1권	13회차
4	인프런	스프링 배치 - Spring Boot 기반으로 개발하는 Spring Batch	12회차
5	프로젝트	URL 단축 서비스 프로젝트 (four days)	16회차

 

반응형

 

1. 1일 ?개 알고리즘 문제 풀기

총 9개 문제를 풀었다. 백준, 프로그래머스 문제를 섞어서 풀었는데, 아래 문제가 어려웠다. 오늘(2023-03-25) 기준으로 백준 티어는 실버 2다(백준 티어와 프로그래머스 레벨은 계속 바뀐다).

 

나는 파이썬으로 stack을 일부 구현해서 문제를 풀었다. 이 과정에서 범위를 벗어나지 않게 하고 창고 가운데 웅덩이가 생기지 않도록 하는 것이 어려웠다. 문제를 풀고 다른 분들의 풀이를 보니 stack을 사용하지 않은 풀이도 꽤 있었다(코드 길이도 짧더라..).

2304번: 창고 다각형

 

2. 회사 스터디 & 3. Real MySQL 8.0 1권

Real MySQL 8.0 (1권) - YES24

이번 스프린트에서는 8.4장부터 8장 끝까지 학습하고 스터디를 진행했다. 원래 토요일 오전에 온라인으로 진행하는데, 이번 주는 목요일 점심시간을 활용해 회사 회의실에서 진행했다.

 

지난 스터디와 마찬가지로 각자 학습한 내용을 바탕으로 서로의 생각을 공유했다. 아래 목록은 책을 읽고 정리한 내용 중 일부다.

• MySQL 서버의 전문 검색 인덱스는 불용어 처리, 어근 분석과 같은 두 가지 과정을 거쳐 색인 작업이 수행된다.
  • 불용어 처리 : 검색에서 필요 없는 단어를 모두 필터링해서 제거한다.
  • 어근 분석 : 단어의 뿌리인 원형을 찾는 작업이다. MySQL 서버에서는 오픈소스 형태소 분석 라이브러리인 MeCab을 플러그인 형태로 사용할 수 있다. 이를 활용해 한글을 분석할 수 있다.
• 칼럼의 값을 변형해서 인덱스를 구축해야 하는 경우 함수 기반 인덱스를 활용할 수 있다. 함수 기반 인덱스는 가상 칼럼을 이용하는 방법과 함수를 이용하는 방법이 있다.
• 함수 기반 인덱스를 활용할 때는 반드시 조건절에 명시된 표현식을 그대로 사용해야 한다. 만약 표현식이 같은데 옵티마이저가 인덱스를 사용하지 않는다면 콜레이션이 같은지 확인하자.
• MySQL에서 InnoDB 스토리지 엔진만 지원하는 클러스터링 인덱스는 프라이머리 키에만 적용된다.
• 클러스터링 인덱스는 프라이머리 키로 검색할 때 처리 성능이 좋고 모든 세컨더리 인덱스가 프라이머리 키를 가지고 있으므로 인덱스만으로 작업이 처리될 수 있는 경우가 많다는 장점이 있다. 하지만 모든 세컨더리 인덱스가 프라이머리 키를 가지고 있으므로 프라이머리 키 값의 크기가 크면 전체적으로 인덱스의 크기가 커진다. 또한 세컨더리 인덱스로 검색할 때 프라이머리 키를 찾고 프라이머리 키로 다시 한번 검색해야 하므로 처리 성능이 낮다는 단점이 있다.
• 프라이머리 키는 AUTO-INCREMENT보다는 업무적인 칼럼으로 생성해라.
  • 이 부분은 아직 고민하고 있다. 내 생각에는 상황에 따라 프라이머리 키를 업무적인 칼럼 또는 AUTO-INCREMENT와 같은 의미 없는 값으로 설정하는 것이 맞아 보인다. 책에서는 특정 칼럼이 크더라도 업무적으로 해당 레코드를 대표할 수 있다면 해당 칼럼을 프라이머리 키로 설정하는 것이 좋다고 설명한다. 다만 앞에서 살펴본 프라이머리 키 값의 크기가 클 때 발생하는 문제와 비즈니스 로직에서 사용되는 데이터가 프라이머리 키로 설정되고, 이를 외래키로 사용하는 경우 발생하는 문제가 있으므로 충분히 고민한 후에 결정을 내릴 필요가 있을듯 하다.
• 유니크 인덱스와 유니크하지 않은 세컨더리 인덱스의 검색 성능은 큰 차이가 없다. 하지만 쓰기 작업은 유니크 인덱스가 느리다. 중복 체크를 해야 하기 때문이다.
• MySQL에서 외래키는 InnoDB 스토리지 엔진에서만 사용할 수 있다.

 

내가 만든 퀴즈

1. 유니크 인덱스는 유니크하지 않은 세컨더리 인덱스보다 쓰기 속도가 왜 느린가요?

중복된 값이 있는지 체크하는 과정이 있기 때문입니다.

 

4. 스프링 배치 - Spring Batch 기반으로 개발하는 Spring Batch

스프링 배치 - Spring Boot 기반으로 개발하는 Spring Batch - 인프런 | 강의

이번 스프린트에서는 '섹션 7. 스프링 배치 청크 프로세스 이해'를 들었다.

 

드디어 Chunk와 ItemReader, ItermWriter, ItemProcessor에 대한 내용이 시작됐다. 회사에서 운영 중인 배치 프로그램이 대부분 ItemReader, ItemWriter, ItemProcessor로 코드가 작성되어 있어서 이 부분이 아주 궁금했다. 이번 섹션에서는 이론 강의를 통해 간략한 내용이 소개되었고 실습을 진행했다.

 

5. URL 단축 서비스 프로젝트 (four days)

토이 프로젝트를 시작했다. 서비스의 메인 기능은 URL 단축 기능이다. 작년에 취업을 준비할 때 URL 단축 서비스를 활용해 자기소개서에 기재할 포트폴리오 URL을 줄여서 사용하고는 했다(자기소개서 글자 수 제한 때문에..). 당시에 포트폴리오 수정이 꽤 잦아서 포트폴리오 버전별로 단축 URL을 만들어야 했는데, 이 점이 좀 불편했다. 그래서 URL 단축 서비스를 만들어서 서버에서 원본 URL만 바꿔주면 단축 URL을 새로 생성할 필요 없이 사용할 수 있겠다고 생각했었다. 그래서 이번 기회를 통해 URL 단축 서비스를 만들어보려고 한다.

 

UI는 웹 브라우저 확장 프로그램을 활용하려고 한다(web 먼저 만들 예정). 크롬, 웨일 등이 확장 프로그램을 제공하는데, 이를 활용하면 간편하게 URL을 단축할 수 있는 기능을 지원할 수 있을 것 같다. 단축 기간은 4일이다(96시간). 아직 전체적인 아키텍처는 고민 중이지만 조금씩 만들어가면서 이론 정도만 공부하고 프로젝트에 활용하지 못했던 카프카, 스프링 웹 플럭스, AWS, 앵귤러, 파이썬 등을 활용하려고 한다.

 

이번 스프린트에서는 자바 17과 스프링 부트 3으로 core 서버 프로젝트 환경을 세팅하고 URL 객체를 설계했다. URL 객체를 설계하는 과정에서 TDD를 활용했는데, 이전에 공부한 기억을 더듬어서 진행했다(TDD는 아래 책으로 학습했다).

테스트 주도 개발 시작하기 - YES24

 

이번 기회를 통해 TDD를 활용해봤는데, URL 객체를 설계하는 데 도움이 된 것 같다. URL 객체가 가져야 할 기능과 데이터를 고민하는 과정에서 테스트를 추가하고 기능을 검증했다. 이를 통해 머릿속으로 생각한 URL 객체를 코드로 잘 작성한 것 같다(아닐 수 있음).

 

다만 개발 속도가 조금 느린 것 같아서 프로젝트 진행이 더디지 않을까 걱정이 되는데.. 이 부분은 프로젝트를 진행하면서 테스트에 대해 학습하고 코드를 작성하다 보면 개선이 되지 않을까 싶다.

 

* URL 클래스

GitHub - four-days/core-server

 

* URL 테스트 클래스

GitHub - four-days/core-server