그동안 1년 단위로 회고를 진행해왔는데, 최근 3개월은 여러가지 활동들을 보내서 처음으로 분기별 회고를 작성해보려고 합니다.
1월부터 3월까지 공부한 내용은 다음과 같습니다.
“스프링 DB 1편 - 데이터 접근 핵심 원리” 강의 수강 및 정리
“자바 개발자를 위한 코틀린 입문(Java to Kotlin Starter Guide)” 강의 수강 및 정리
“실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)” 강의 수강 및 실습
“가상 면접 사례로 배우는 대규모 설계 시스템 기초” 책 읽고 정리
스프링과 코틀린에 대해 강의를 통해 학습하고 개인 포스팅으로 정리하는 식으로 진행했습니다. 또한 최근에는 설계 시스템에 관심이 가게 되어서 “가상 면접 사례로 배우는 대규모 설계 시스템 기초” 라는 책을 읽었습니다.
사이드 프로젝트 진행기간: 2023.12 ~ 2024.02
히빗 프로젝트는 백엔드 부분에서의 코드와 구조를 개선하기 위해 혼자서 다시 진행한 프로젝트입니다. 이와 관련된 부분은 다른 포스팅에 이미 작성해둔 게 있기 때문에, 여기서는 생략하겠습니다.
아래 링크를 통해서 더 자세히 확인하실 수 있습니다.
(히빗 V2 업그레이드: 백엔드 개선과 개발자 성장기)
TIL 진행기간: 2024.01 ~ 현재 진행중
TIL 모임은 글또에서 활동하고 계신 NY님이 올린 모집글을 통해 신청하게 되었습니다.
처음 1월에는 Slack 채널에서 비공개로 진행했었는데, 대표적으로 2가지 단점이 보이기 시작했습니다.
슬랙 유료 멤버십을 가입하지 않으면, 3개월 이후에는 블러 처리가 되어서 기록된 내용을 볼 수 없게 됩니다.
온라인 화상회의를 하려면 다른 플랫폼을 이용해야 한다는 점이 있습니다.
무엇보다도 ‘기록’을 열심히 했음에도, 나중에 볼 수 없다는 점이 가장 큰 단점 이었기 때문에, 2월부터는 디스코드로 갈아탔습니다.
디스코드는 무료로 기록도 되었고 내부에서 화상 회의가 가능했기 때문에, 위의 2가지 단점을 모두 커버할 수 있었습니다.
1월에는 6명이서 시작했던 TIL 모임이 이제(3월 기준)는 12명이 되어갔습니다.
2월부터는 TIL 인증 뿐만 아니라, 매주 금요일 혹은 일요일 저녁에 30분 정도 ‘주간 회고’를 진행하면서 KPT 회고를 작성하고, 서로 얘기하는 시간을 가졌습니다.
확실히 이런 TIL 모임을 하니까, 다른 구성원분들로부터 자극을 받고, 스스로 동기부여를 하면서 매일 공부하는 습관을 유지할 수 있었던 점이 좋았습니다.
1월부터 3월까지 3개월 동안 한 결과, 총 60번의 제출 중 41번을 제출하였습니다. 제출하지 못한 날이 꽤 있어서 아쉽긴 하지만, 그래도 제출한 내용 만큼은 현재뿐 아니라 앞으로도 도움이 되는 기술적 지식 또는 경험 위주로 정리하려고 노력했습니다.
이전까지는 1달 단위로 TIL 모임을 운영해왔지만, 앞으로는 분기별로 진행하면서 꾸준히 공부하면서 성장해가는 개발자가 되도록 노력할 예정입니다 😌.
스터디 진행기간: 2024.01 ~ 2024.02
글또에서 활동하고 계신 YH님께서 “이력서, 포트폴리오 개선 스터디원”을 구하신다는 모집글을 보고, 바로 참여하게 되었습니다.
평소에 이력서에 대한 피드백을 동료분들 혹은 저보다 연차가 많은 개발자분들로부터 받아왔지만, 아직도 부족하다고 느끼고 있었습니다. 또한 제가 조금이라도 도움이 드릴 수 있는 부분이 있다면 적극적으로 도와드리고 싶었습니다. 해당 스터디를 통해 더 나은 이력서를 만들고자 참여를 하게 되었습니다.
YH님이 주도적으로 스터디를 이끌어주시면서 어떻게 진행할지 알려주셨고, 더 나은 방법이 있다면 스터디에 참여하는 구성원분들이 의견을 제시해서 조금씩 개선하는 방향으로 나아갔습니다.
피그마를 이용하여 2주마다 총 3개의 버전을 만들면서 이전 대비 더 나아지는 이력서를 만드는 것이 목표였습니다.
2주 간격으로 온라인 회의(Google Meet)를 진행하면서, YH님이 그때마다 필요한 내용들을 Notion에 정리해주셔서 구성원 모두에게 공유하고 얘기하는 시간을 가졌습니다. 해당 스터디 이후에 서류에 합격하는 사람이 있으면, 위와 같이 스터디원 분들이 모두 축하해줬습니다.
스터디 마지막 날에는 이번 모임의 목적을 다시 생각하면서, 부족했던 부분, 좋았던 부분, 개선할 부분들을 정리하는 시간을 가졌습니다. 다음에 또 이력서 스터디를 모집한다면, 지금보다 더 효과를 누릴 수 있지 않을까 생각합니다.
피그마에서 각 직군별로 분류하였고, 본인의 직무에 있는 곳에 이력서를 올리는 식으로 진행했습니다. 그리고 2주 동안 본인의 이력서를 다른 버전으로 업데이트 하는 동시에, 다른 사람의 이력서를 보고 피드백하는 식으로 했습니다.
저는 해당 스터디를 시작하기 전부터 기존의 이력서가 있었고, 스터디를 진행하면서 서류합격 받은 회사들로부터 면접을 진행하고 있었습니다. (이때가 정말 바빴고, 정신없이 시간을 보냈던 것 같습니다 😂)
그렇게 열심히 노력한 결과, 운이 좋게도 한 회사에 최종합격을 받게 되었습니다. 일부 기술 면접 질문에 대해 제대로 답변을 못한 경우도 있었는데, 그러한 부분을 관대하게 넘어가주셨고, 인성 부분에서 좋게 봐주셔서 ‘합격’해주셨다고 생각합니다. 앞으로 새로운 회사에 다니면서 꾸준히 성장해서 더 나은 개발자가 되도록 노력하겠습니다.
글또에 참여하면서, 글을 제출하는 것 외에 글또에 도움이 되는 활동에 참여하고 싶다는 생각이 들었습니다.
그렇게 생각만 하다가 어느 날, 백엔드/인프라 반상회를 위한 준비 위원회 모집 참여글을 확인하게 되었고, 참여 의사를 전달하면서 준비위원회에 합류하게 되었습니다.
첫 미팅은 온라인으로 진행 했고, 두 번째 미팅은 오프라인(우아한형제들, 선릉역 부근)에서 진행되었습니다. 성윤님이 PO 역할로 큰 부분을 잡아주셨고, 세부적인 부분들은 팀을 꾸려서 전개해 나가도록 진행했습니다.
(위는 2시간 정도의 오프라인 회의가 끝나고 찍은 사진 입니다)
저는 굿즈팀에서 키캡을 제작하는 걸 담당했고, 음식팀에서는 TJ님과 메뉴 선정부터 배송 과정까지 기획하는 걸 담당했습니다. 키캡을 제작하면서, 굿즈팀의 YE님께서 디자인 부분을 많이 도와주셔서 일사천리로 끝내서 정말 감사했습니다. 음식팀에서는 TJ님이 적극적으로 임해주셨고, 성윤님이 뒤에서 많은 부분을 도와주셔서 감사했습니다.
결과적으로 키캡은 위와 같이 제작되었습니다.
그리고 굿즈팀의 YE님과 SM님이 포스터를 정성스럽고 이쁘게 만들어주셨습니다. (비록 백엔드 직무이시만, 취미로 디자인을 하시는 YE님 짱입니다..!) 이 외에도 여러 팀에서 본인이 맡으신 부분들을 적극적으로 임해주셔서, 결과적으로 백엔드/인프라 반상회 준비가 문제없이 잘 되었다고 생각합니다.
3월 14일, 반상회 당일 ‘마루 180’이라는 장소에서 100명이 넘는 글또 분들이 오프라인에 참석하면서 오프닝 -> 발표 -> 네트워킹 -> 기념 사진 촬영 으로 진행하게 되었습니다.
백엔드/인프라 반상회를 한 마디로 정리하면, ‘짧지만 강렬했고 즐거웠던 네트워킹 모임이였다’ 입니다.
해당 반상회에 대한 자세한 내용이 궁금하시다면, 승현님이 작성한 포스팅에서 확인하시면 좋을 것 같습니다 ! 여유가 된다면, 저도 이 부분에 대해 나중에 포스팅으로 업로드할 예정입니다.
4월부터는 새로운 회사에서 백엔드 직무로 일하게 되었는데, 우선 회사에 적응을 하면서 도메인과 기술 스택에 빠르게 적응하는 시간이 될 것 같습니다.
그런 다음에, 백엔드 성장에 필요한 기술들을 별도로 공부하면서 지낼 것 같습니다.
(해당 포스팅은 추후에 내용을 추가 및 보완할 예정입니다.)
지금까지 이 글을 읽어주셔서 감사합니다. 😌
글을 작성하는데 걸린 시간: 약 3시간
이 글은 실제 히빗 프로젝트(ver.2)를 혼자서 개발하면서 경험한 내용을 정리한 글입니다.
이와 관련해서 코드에 대한 부분은 PR에 있습니다.
Swagger
는 API 동작을 테스트하는 용도에 더 특화되어 있습니다.
그래서 프론트와 백엔드에서 테스트 유무를 확인할 때는 용이했습니다.
기존 version1 에 개발했던 Hibit은 Swagger
로 API 문서를 만들었습니다.
그러나 Swagger
를 적용하면서 백엔드 코드에 Swagger
와 관련된 어노테이션이 추가되는데, 이로 인해 코드 내부에 기능과 문서가 혼합되어 깔끔하지 않은 코드가 되었습니다.
예를 들어, 게시글을 등록하는 API 부분의 코드는 다음과 같습니다.
기존 version1 - PostController
@Tag(name = "posts", description = "게시글")
@RestController
public class PostController {
private final PostService postService;
public PostController(PostService postService) {
this.postService = postService;
}
@PostMapping("/api/posts/new")
@Operation(summary = "/api/posts/new", description = "매칭 게시글 작성")
@Parameters({
@Parameter(name = "title", description = "제목", example = "디뮤지엄 전시 보러가요"),
@Parameter(name = "exhibition", description = "가고싶은 전시회", example = "오스틴리 전시회"),
@Parameter(name = "exhibitionAttendance", description = "전시 관람 인원", example = "4"),
@Parameter(name = "possibleTime", description = "관람 희망 날짜", example = "[\"2023-12-25\"]"),
@Parameter(name = "openChatUrl", description = "오픈 채팅방 URL", example = "http://kakao"),
@Parameter(name = "togetherActivity", description = "함께 하고싶은 활동", example = "EAT"),
@Parameter(name = "content", description = "상세 내용", example = "오스린리 전시회 보러가실 분 있나요?"),
@Parameter(name = "postImages", description = "게시글 이미지 리스트 URL", example = "[\"image1\", \"image2\", \"image3\"]")
})
public ResponseEntity<Post> save(@Parameter(hidden = true) @AuthenticationPrincipal final LoginMember loginMember, @RequestBody PostCreateRequest request) {
Post post = postService.save(request, loginMember.getId());
return ResponseEntity.status(HttpStatus.CREATED).body(post);
}
}
이런 형태의 코드는 Swagger
를 사용할 때 발생하는 문제를 나타냅니다.
따라서 이러한 이유로 version2 프로젝트에서는 Swagger
보다는 깔끔하고 명료한 문서를 생성할 수 있는, 주로 문서 제공 용도로 사용되는 Spring Rest Docs
로의 전환을 결정하게 되었습니다.
Spring Rest Docs의 특징으로는 다음과 같습니다.
테스트 코드를 통한 API 문서 자동화 도구입니다. (제가 만든 api 명세를 테스트 코드를 작성해서 build하면 문서처럼 보여지는 것)
API 명세를 문서로 만들고 외부에 제공함으로써 협업을 원활하게 합니다.
기본적으로 AsciiDoc
을 사용하여 문서를 작성합니다. (markdown 같은 것)
Rest Docs와 Swagger의 장점과 단점을 비교하면 다음과 같습니다.
Rest Docs
장점
테스트를 통과해야 문서가 만들어진다. (신뢰도가 높다)
프로덕션 코드에 비침투적이다.
단점
코드 양이 많다.
설정이 어렵다.
Swagger
장점
적용이 쉽다.
문서에서 바로 API 호출을 수행해볼 수 있다.
(UI에 대해) 알록달록하게 문서를 작성할 수 있다.
단점
프로덕션 코드에 침투적이다.
테스트와 무관하기 때문에 신뢰도가 떨어질 수 있다. → 실제로 동작하는 것과 문서가 따로 돌 수 있다.
현재 히빗 version2 프로젝트는 아래와 같은 기술을 사용하고 있습니다.
Language
- Java 11
Framework
- Spring Boot 2.7.1, Spring MVC 5.3.2
ORM
- Spring Data JPA 2.7.1, JPA Hibernate 5.6.1
Database
- H2, MySQL 7.4
Build Tool
- Gradle 8.0
Test
- Junit 5, Mockito 4.5.1
Rest Assured
Rest Assured
는 별도의 구성 없이는 @SpringBootTest
로 수행해야 합니다.
@SpringBootTest
는 스프링의 전체 컨텍스트를 로드하여 빈을 주입하기에 속도가 많이 느립니다.
즉, Rest Assured
는 스프링 애플리케이션이 동작하는 실제 환경과 거의 동일한 환경에서 테스트를 진행할 때 사용됩니다.
그래서 @SpringBootTest
을 적용한 RestAssured
는 속도가 느리고, 비용이 많이 듭니다.
MockMvc
반면에 MockMvc
는 @SpringBootTest
와 함께 사용할 수 있고, @WebMvcTest
와 함께 사용할 수도 있습니다.
@SpringBootTest
다르게 @WebMvcTest
는 Controller Layer(=Presentation Layer) 만 테스트 하기에 속도가 빠릅니다.
(@WebMvcTest
사용할 때는 보통 서비스 계층을 Mocking을 하여 작성하기 때문입니다)
결론
만약 통합테스트를 한다면 Rest Assured
가 좋은 선택이지만, Spring Rest Docs로 문서를 작성하는 데에는 MockMvc
가 더 나은 선택이라 생각하여 MockMvc
기반으로 진행하게 되었습니다.
저에게 익숙한 Markdown
이 작성하기 더 편할 수 있지만, Markdown
으로 Rest Docs를 작성하려면 Ruby 프로젝트인 slate가 필요합니다. (include가 되지 않아 별도로 설치해야 합니다)
slate
는 Gradle로 관리되는 프로젝트가 아니기 때문에, 해당 프로젝트를 직접 다운로드 받아서 진행해야 합니다.
이는 곧, slate
에 의존해야만 하는 구조가 되고, Ruby 의존성들이 추가로 생성되면서 빌드 시간이 전체적으로 오래 걸리게 됩니다.
또한 개인적으로 slate
로 만들어진 UI가 저에게 친숙하지 않았습니다.
반면에, Asciidoc
는 문서를 작성할 수 include 기능을 제공하며(Gradle로 관리됨), 표현할 수 있는 문법들이 많이 있습니다.
그리고 UI도 slate
에 비해 깔끔하면서 이뻤습니다.
그래서 Asciidoc
을 사용하기로 했습니다.
MockMvc
, Asciidoc
기반 Rest Docs 설정 - build.gradle
plugins {
id 'java'
id 'org.springframework.boot' version '2.7.10'
id 'io.spring.dependency-management' version '1.0.15.RELEASE'
id 'jacoco'
id "org.asciidoctor.jvm.convert" version "3.3.2" // (1) plugin 추가
}
group = 'com'
version = '0.0.1-SNAPSHOT'
java {
sourceCompatibility = '11'
}
configurations {
compileOnly {
extendsFrom annotationProcessor
}
asciidoctorExt // (2) asciidoctor의 Extention에 대한 configuration 추가
}
repositories {
mavenCentral()
}
dependencies {
// Spring boot
implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'org.springframework.boot:spring-boot-starter-web'
implementation 'org.springframework.boot:spring-boot-starter-validation'
// ...
// spring restdocs (3), (4)
asciidoctorExt 'org.springframework.restdocs:spring-restdocs-asciidoctor'
testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc'
}
ext { // (5) 문서 조각들에 대한 경로를 지정
// 전역 변수
snippetsDir = file('build/generated-snippets')
}
tasks.named('bootBuildImage') {
builder = 'paketobuildpacks/builder-jammy-base:latest'
}
test {
outputs.dir snippetsDir // (6) 테스트에서 테스트가 끝난 결과물을 snippetsDir 에 넣음
useJUnitPlatform()
finalizedBy 'jacocoTestReport'
}
// (7) asciidoctor 태스크에 대한 설정
asciidoctor {
inputs.dir snippetsDir // 불러올 스니펫 위치를 snippetsDir로 설정
configurations 'asciidoctorExt' // Asciidoctor 확장에 대한 설정
sources { // 특정 파일만 html로 만듬
include("**/index.adoc")
}
baseDirFollowsSourceFile() // 다른 adoc 파일을 include 할 때 경로를 baseDir로 맞춤
dependsOn test // test 태스크 이후에 asciidoctor를 실행하도록 설정
}
Asciidocotor
는 Asci 파일을 html 파일로 변환해주는 도구 입니다.
(1) AsciiDoc 파일을 컨버팅하고 Build 폴더에 복사하기 위한 플러그인을 추가합니다.
(2) asciidoctor의 Extention(확장)에 대한 Configuration 구성을 추가합니다.
(3) asciidoctorExt
에 spring-restdocs-asciidoctor 의존성을 추가합니다. 이 종속성이 있어야 build/generated-snippets
에 있는 .adoc
파일을 읽어들여 .html
파일로 만들어낼 수 있습니다.
(4) MockMvc
를 사용하기 위한 spring-restdocs-mockmvc 의존성을 추가합니다.
(5) 생성되는 스니펫들이 생성되는 디렉터리 경로를 설정합니다.
(6) 테스트가 끝난 결과물을 snippetsDir
에 넣습니다.
(7) asciidoctor
태스크에 대한 설정을 합니다.
Preference - Plugins -
AsciiDoc
설치
ControllerTestSupport
@AutoConfigureRestDocs // (1)
@WebMvcTest(controllers = {
MemberController.class,
AuthController.class,
ProfileController.class,
PostController.class
})
@Import(ExternalApiConfig.class)
@ActiveProfiles("test")
public abstract class ControllerTestSupport {
@Autowired
protected MockMvc mockMvc;
@Autowired
protected ObjectMapper objectMapper;
// ...
@MockBean
protected PostService postService; // (2)
}
PostControllerTest
class PostControllerTest extends ControllerTestSupport {
private static final String AUTHORIZATION_HEADER_NAME = "Authorization";
private static final String AUTHORIZATION_HEADER_VALUE = "Bearer aaaaaaaa.bbbbbbbb.cccccccc";
@DisplayName("등록된 게시글을 모두 조회한다.")
@Test
void 등록된_게시글을_모두_조회한다() throws Exception {
// given
Member 팬시 = 팬시();
팬시 = memberRepository.save(팬시);
List<Post> 게시글_목록 = List.of(프로젝트_해시테크(팬시), 오스틴리_전시회(팬시));
PostsResponse response = PostsResponse.of(게시글_목록);
given(postService.findAll()).willReturn(response); // (3)
// when & then
mockMvc.perform(get("/api/posts")
.header(AUTHORIZATION_HEADER_NAME, AUTHORIZATION_HEADER_VALUE)
.accept(MediaType.APPLICATION_JSON)
.contentType(MediaType.APPLICATION_JSON))
.andDo(print())
.andDo(document("posts/find/all/success",
preprocessRequest(prettyPrint()),
preprocessResponse(prettyPrint())
))
.andExpect(status().isOk()); // (4)
}
}
(1) @AutoConfigureRestDocs
어노테이션은 Spring REST Docs를 자동 구성해주는 어노테이션입니다. 이를 적용하게 되면 테스트 케이스 실행시 자동으로 API 문서가 생성됩니다.
@AutoConfigureRestDocs
에 uri 정보가 선언되어 있으면 적용하고, 없으면 기본 설정값으로 적용(2) PostService
의 구현체를 mocking하기 위해 @MockBean
을 선언합니다.
(3) 테스트에서 given 메소드를 사용하여 postService.findAll()
메소드 호출 시 PostsResponse
객체를 반환하도록 설정합니다.
(4) 테스트에서 mockMvc.perform()
메소드를 사용하여 실제 HTTP 요청을 모의로 실행하고, 그 결과를 검증합니다. document 메소드를 통해 요청과 응답을 문서화합니다.
이러한 과정을 통해 Spring REST Docs를 활용하여 API 문서를 생성할 수 있습니다.
오른쪽 Gradle - Tasks - documentation - asciidoctor 실행하면 성공이 되고,
build 안에 posts
폴더가 생기고, find/all/success
폴더 안에 문서 조각들이 생깁니다.
이 다음에 해야할 작업은 문서 조각을 하나로 합쳐서 하나의 문서로 만드는 작업 입니다.
src 폴더 하위에 docs 라는 폴더를 만든 뒤, 그 안에 asciidoc 폴더를 생성한 뒤에 index.adoc
이라는 파일을 만듭니다.
index.adoc
파일 안에 아래와 같이 작성하면 미리보기를 통해 확인할 수 있습니다.
오른쪽 Gradle - build (또는 documentation - asciidoctor)를 눌러주면, 왼쪽 docs 폴더 - asciidoc 폴더 안에 index.html
파일이 생성됩니다.
그리고 Chrome 창으로 열어보면 아래와 같이 API 문서가 나오게 됩니다.
Spring Rest Docs를 Hibit version2 프로젝트에 통합하는 과정을 통해, 초기 설정부터 실제 적용까지의 단계를 체계적으로 이해하게 되었습니다.
이 과정에서 Asciidoc 문법의 기초를 배웠음에도 불구하고, 아직 배워야 할 내용이 많다는 것을 깨달았습니다.
앞으로는 Spring Rest Docs의 활용 방법에 대해 더욱 개방적인 태도로 접근하며, 이를 통해 지식을 확장하고 실무 경험을 축적해 나가겠습니다.
해당 부분에 대한 코드는 Github(PR) 에서 확인할 수 있습니다.
지금까지 읽어주셔서 감사합니다.
글또 9기를 시작하고 4회차가 지난 이후에 글또의 운영진이신 성윤님께서 ‘글쓰기’ 라는 주제로 세미나를 해주셨어요.
해당 세미나에서 다룬 주로 내용은 다음과 같아요.
글쓰기가 어려운 이유
글쓰기의 핵심 요소
글을 쓰는 과정
글쓰기 전략
해당 세미나을 들으면서 지금까지 고수해왔던 저의 글쓰기 방식의 미흡한 부분과 개선점에 대해 고민해보게 되었습니다.
해당 세미나를 듣기 이전에는 저는 아래와 같은 순서로 글을 작성했었어요.
소재 탐색 및 정리 - 평소에 생각나는 주제들을 Notion
에 정리하기
소재 공부 - 블로그에 업로드할 소재에 대해 깊이 있게 공부하기 (관련 도서, 공식문서, 블로그)
글 작성 - 목차를 구성한뒤 글을 작성 -> ChatGPT에게 문장이 자연스러운지 검토받으면서 수정하기
글 업로드 및 퇴고 - 해당 글을 블로그에 업로드 한 뒤에 몇 번의 퇴고를 반복하기
저의 글쓰기 파이프라인을 KPT 회고
로 정리하면 아래와 같아요.
Keep(좋았던 점)
세미나에서 공유해주셨던 글쓰기 파이프라인과 80% 정도 유사해서 신기하면서도 뿌듯했어요.
글을 작성할 때 구조적이면서 이해하기 쉬운 글을 작성하려고 주어진 시간 내에 깊게 공부하고, ChatGPT의 도움으로 업로드 하기 전에 여러번 수정했어요.
Problem(아쉬웠던 점)
2023년 하반기(8월)부터 위의 글쓰기 파이프라인을 적용했기 때문에, 그 이전 글의 퀄리티가 다소 떨어진다고 생각했어요.
제 블로그의 목적은 꾸준함
과 저만의 백과사전
이였기 때문에, 그 만큼 카테고리가 다양해요. 그래서 제 3자가 보기에 혼란스러울 수도 있다는 생각이 들었어요.
2023년에는 187개의 글을 업로드했으나, 양보다 질이 떨어진다는 느낌을 받았어요.
글또에 제출하는 글 하나를 작성하는 데 최소 6시간 ~ 12시간 정도 걸렸어요.
Try(개선할 점)
현재보다 조금 더 구체적인 파이프라인을 구성하여 퀄리티 있는 글을 작성하려고 노력할 예정이에요.
백준, 프로그래머스와 같은 문제 풀이 포스팅은 TIL
이나 다른 곳에 업로드할 계획이에요.
글쓰기 주제를 기술
, 트러블 슈팅 경험
, 회고
, 리뷰
위주로 좁힐 예정이에요.
글이 많거나 이해하기 어려울 경우, 직접 도식화를 그린 뒤에 추가하여 이해를 돕고자 노력할 예정이에요.
2022년부터 현재까지 저의 블로그의 목적이자 글쓰기 전략
은 꾸준함을 증명하고 저만의 백과사전이 되는 것이였어요.
그래서 새로운 무언가를 배울 때, 그게 시간이 지난 이후에도 필요한 지식 또는 경험이라면 포스팅을 작성해서 제 블로그에 업로드를 해왔어요.
저는 블로그에 대해 너무 고민을 많이 하면, 오히려 글을 작성하기가 두렵게 되고, 그게 지속되면 글을 작성 안하게 되더라고요.
그래서 단순하게 생각하는 편인데, 성윤님의 세미나 강연을 보면서 조금은 고쳐야 할 부분이 생겼어요.
글쓰기 파이프라인 개선: 글쓰는 주제에 대한 우선순위를 세우고, 그 기준에 맞게 순서대로 글을 작성하자.
이전의 글쓰기 파이프라인
을 보다 구체적으로 작성해서 퀄리티 있는 글을 작성하자.
주제 범위 좁히기: 글쓰기 주제를 기술
, 트러블 슈팅
, 회고
, 리뷰
위주로 글을 작성하여 일관성을 유지하자.
시간 제한과 몰입도 향상: 시간 제한을 설정해서, 시간안에 최대한 몰입해서 2~6시간 이내로 작성하자.
이해를 돕는 시각 자료 활용: 복잡한 내용은 그림과 같은 시각 자료를 통해 제 3자가 봐도 이해되기 쉬운 글이 되도록 작성하자.
이러한 개선을 통해 더욱 발전된 글쓰기를 해나갈 계획이에요.
최근에 작성한 “히빗 V2 업그레이드: 백엔드 개선과 개발자 성장기“에 대한 글을 수정했어요.
이전에는 제목
과 목차
가 아래와 같이 구성되어 있었어요.
수정하기 전
[제목] : 히빗 프로젝트 Version 1에서 2로의 전환: 백엔드 코드 개선과 개발자 성장의 여정
[목차]
## 과거의 '나'와 현재의 '나'
## version2의 목표
## 개선한 점
// ...
## 느낀점(아쉬운 점)
## Reference
제목
은 “SEO 관점 + 단순 명료하게” 되도록 수정하고, 목차
에 대해서는 서론과 결론에 대한 부분이 부족하다고 느껴 그 부분을 아래와 같이 추가했어요.
수정한 후
[제목] : 히빗 V2 업그레이드: 백엔드 개선과 개발자 성장기
[목차]
## 시작하며 <- 추가됨
## 과거의 '나'와 현재의 '나'
## version2의 목표
## 개선한 점
// ...
## 느낀점(아쉬운 점)
## 마치며 <- 추가됨
## Reference
그리고 포스팅에 대한 내용
은 저만의 말투가 섞여있어서 ‘제 3자가 이해못할 수도 있겠구나’ 생각했어요. 그래서 ChatGPT
를 적극 활용했어요.
ChatGPT
에게 단순히 질문을 던지는 방식보다는 “~~주제에 대해서 나는 아래와 같이 작성했는데, 해당 문장을 읽고 깔끔하고 자연스러운 문장으로 수정해줄래?” 와 같이 원하는 답변이 나올 때까지 구체적으로 질문했어요.
또한, 설명이 부족한 부분은 보충하고 이미지도 도식화해서 추가했어요.
개선할 점을 반영한 글쓰기 파이프라인을 그림으로 표현하면 아래와 같아요.
소재 정하기 - 출/퇴근 시간, 휴일에 어떤 주제를 작성할까 고민하기 / 유레카처럼 갑자기 생각나면 바로 Notion
에 정리하기
소재 보관하기 - 작성할 소재를 Notion
에 정리 + 우선순위에 맞게 배치하기 -> 해당 소재에 대해 깊게 공부하기
초안 작성하기 - 시간 제한과 방해 금지 모드를 설정하고 몰입하여 글을 작성하기 (시간 제한:2시간) -> 글을 어느 정도 작성하면 ChatGPT
피드백 받기
업로드 및 퇴고하기 - 해당 글을 블로그에 업로드 한 뒤에 24시간 이내로 퇴고하면서 지속적인 업로드하기 -> 퇴고할 때 ChatGPT
피드백 받기
글또의 글쓰기 세미나를 듣고 제 글쓰기 프로세스를 정리하고 도식화해봤어요.
현재까지의 개선 사항을 정리했지만, 나중에 개선할 점이 더 있다면 추가적으로 이 포스팅도 업로드할 예저잉에요.
글쓰는 전략과 방법에 대해 자세하게 알려주신 성윤님께 감사의 말씀 전하며 앞으로도 질 높은, 퀄리티 있는 글 작성하기 위해 노력하겠습니다 ! ✍🏻
글 작성하는데 걸린 시간: 3시간
초안 글 작성: 2시간 10분
ChatGPT 피드백 후 정리: 20분
도식화 추가: 20분
이 글은 제가 혼자서 개발한 히빗 (version 2) 에 대한 회고 글입니다. 이전 version 1과 비교하여 어떤 성장을 이루었고, 그 과정에서 어떤 깨달음을 얻었는지 작성했습니다.
히빗 프로젝트 version1에 참가하게된 계기와 회고는 이전에 작성했던 ‘[2023년 회고] 다양한 활동으로 가득한 특별한 한 해’ 글에 있기 때문에, 생략했다.
이번 글은 히빗 프로젝트를 version2로 다시 진행하면서 개선했던 들을 하나씩 알아보고, 느낀점(아쉬운 점)을 작성해보고자 한다.
과거 version1 에 참가했을 때의 내 실력은 아래와 같았다.
2023, 과거의 ‘나’
자바 - 기초적인 개념은 어느 정도 알고 있으나 일부 개념에 대해서는 제대로 대답하지 못하는 수준. 람다 & 스트림을 알지만, 프로젝트에 적용할 수 없었음
스프링 - 김영한님 강의에서 Spring 핵심 원리, Spring MVC 1편, JPA 활용1,2 까지 들었고 복습한 수준
좋은 코드가 무엇이고, 좋은 코드를 만들기 위해 어떻게 작성해야 할지 판별을 못하는 수준
스프링 & JPA 기반 프로젝트에서의 테스트코드를 어떻게 작성해야 해야 하는지 모름
일단 기능 동작만 구현할 수 있을 정도의 실력
히빗 프로젝트(version 1)를 진행하면서, 그리고 끝난 이후에도 과거의 ‘나’의 실력을 성장시키기 위해 아래와 같은 공부를 했다.
2024, 현재의 ‘나’
자바 - ‘자바의 정석’ 책을 통해 빠르게 복습하면서 기본기 튼튼히 잡음. 람다 & 스트림 개념을 공부하면서 프로젝트에 적용할 수 있음
스프링 - 김영한님 강의에서 JPA 기본, Spring MVC 2편, Spring DB 1편를 수강했고, 기본기는 꾸준히 복습했음 -> JPA 정리, Spring 정리
좋은 코드가 무엇인지 알기 위해 우아한 스터디 겨울시즌, “내 코드가 그렇게 이상한가요?” 주제에 참가해서 2달간 공부 및 정리했음
테스트코드가 무엇이고, 스프링 & JPA 기반 프로젝트에서의 테스트코드를 작성하는 방법을 “Practical Testing” 강의를 통해 학습하고 정리했음
간단히 말해, 이전에는 프로젝트에서 개발할 줄 알았지만 깊이있게 학습하지 않았다. 그래서 그러한 약점을 보완하기 위해 꾸준히 공부하면서 부족한 부분을 채워나갔다.
기존의 프로젝트를 version2를 하게된 이유는 내가 제대로 성장했는지 확인하고 싶었고, 기존 version1에 있는 백엔드 코드와 구조를 개선하는 것이였다.
그래서 version1에서 개선하고 싶은 점들을 리스트로 정리한 결과 아래와 같았다.
무분별한 setter 지양하고 하나의 메서드당 하나의 역할만 하도록 리팩터링하기
테스트코드를 도입하여 QA 작업을 자동화하고 Jacoco를 도입하여 코드 커버리지 80% 유지하기
데이터베이스 레플리케이션을 통한 쿼리 성능 개선하기
동시성으로 인한 데이터베이스 정합성이 맞지 않는 문제 해결하기
검색 기능의 개선과 보안 강화하기
게시글 조회에 대한 어뷰징을 막기 위해 조회수를 Cookie에 저장하여 관리하기
기존 API 명세서인 Swagger에서 Rest Docs로 전환하기
version1 -> version2로 개발을 진행하면서 개선한 사항 중 하나는 setter를 사용하지 않고, 단일 책임 원칙을 더욱 철저히 준수하는 것이였다.
초기 버전(ver.1) - PostService
@RequiredArgsConstructor
@Service
public class PostService {
// ...
@Transactional
public Post save(PostSaveDto postSaveDto, Long idx) {
Member member = memberRepository.getById(idx);
postSaveDto.setMember(member);
Post post = postSaveDto.toEntity();
postRepository.save(post);
postHistory postHistory = new postHistory();
postHistory.setPost(post);
postHistory.setOkUsers(new ArrayList<>());
postHistory.setRealUsers(new ArrayList<>());
postHistoryRepository.save(postHistory);
return post;
}
}
개선된 버전(ver.2) - PostService
@Service
@Transactional(readOnly = true)
public class PostService {
// ...
@Transactional
public Long save(final Long memberId, final PostCreateRequest request) {
validateMember(memberId);
Member foundMember = memberRepository.getById(memberId);
Post post = createPost(request, foundMember);
Post savedPost = postRepository.save(post);
return savedPost.getId();
}
}
기존 version1과 version2는 요구 사항이 다를 수 있어 코드상의 차이가 있을 수 있다.
그러나 version1에서는 엔티티 클래스와 비즈니스 로직에서 무분별하게 setter를 사용하고 있다.
왜 setter를 지양해야 할까?
누군가 이렇게 물어본다면, 나는 다음과 같이 2가지 이유를 들 수 있을 것 같다.
JPA에서는 setter를 통해 트랜잭션 안에서 엔티티의 변경 사항을 감지하여 update 쿼리를 수행한다.
즉, setter 메서드는 update
기능을 수행한다.
setter 없이 데이터를 수정하는 방법은 사용한 의도와 의미가 명확한 메서드명을 사용하는 것이 좋다.
예를 들어, 게시글 정보를 변경할 경우 updatePost
라는 메서드를 생성하여 사용하면 setter 메서드 보다 행위의 의도를 더 명확히 할 수 있다.
따라서 setter를 public으로 열어두고 사용하는 것보다는, 변경이라는 의미가 담긴 메서드를 통해 update 처리하는 것이 객체지향적인 접근 방식이라고 본다.
그리고 version2에서는 단일 책임 원칙
을 잘 지키기 위해, 하나의 메서드가 한 가지 일만 하도록 구현했다.
이를 통해 각 메서드의 목적이 명확해지고 코드의 유지보수가 용이해졌다.
자세한 내용은 해당 포스팅에 정리했습니다.
우선 테스트코드에 대한 개념부터 실전까지의 경험을 쌓기위해 “Practical Testing: 실용적인 테스트 가이드” 강의를 들으면서 블로그에 정리해갔다.
해당 강의를 들으면서 동시에 히빗 ver2 프로젝트에도 적용하였고, BDD 기반으로 코드를 작성했다.
(단위 테스트 코드에 대한 자세한 내용은 이전에 작성한 좋은 단위 테스트란? 글에 작성했다)
단위 테스트코드를 작성하면서 동시에 통합 테스트코드를 작성했는데, @MockBean
이라는 어노테이션을 사용했다.
주로 Presentation Layer에서 Business Layer 하위로 Mocking 처리할 때 사용했다.
그리고 토스 유튜브 채널에서 토스뱅크 이응준님이 발표하신 SLASH21 - 테스트 커버리지 100% 영상을 보면서 테스트 커버리지의 여러 이점들을 알게되었고, 하신 말씀 중에 가장 기억에 남는 문구가 아래와 같았다.
테스트가 없으면 리팩터링을 할 수 없고, 리팩터링을 하지 않는 코드는 이해할 수 없게 되며, 이러한 코드는 수정할 수 없다는 확신이 없다. - 토스뱅크 이응준 -
이로 인해 테스트의 중요성을 새롭게 깨달았고, 프로덕션 코드의 품질과 신뢰를 높이기 위해 히빗 ver2 프로젝트에는 코드 커버리지를 80%를 유지하는 목표를 세우고 실천에 옮겼다.
그 결과, 아래와 같이 80% 유지를 할 수 있었다.
해당 내용과 관련된 PR 입니다.
기존 히빗 ver1 프로젝트는 데이터베이스가 1개였다. 그래서 등록, 조회, 수정, 삭제가 모두 하나의 데이터베이스에서 관리되기 때문에 성능적인 면에서 부족한 부분이 있다.
특히 히빗 서비스에서는 주로 등록, 수정, 삭제보다 ‘조회’하는 경우가 많았기 때문에, 조회에 대한 성능을 높이고자 레플리케이션을 도입하기로 했다.
아래와 같이 현재 RDS에 있는 데이터베이스(Source)를 기준으로 하위에 Replica 2개를 추가로 두었다.
그리고 스프링 부트에도 쓰기와 읽기를 분리하기 위해 아래와 같이 DataSource를 구분지었다.
@Configuration
@Profile("prod")
public class DataSourceConfiguration {
@Bean
@Primary
public DataSource dataSource() {
DataSource determinedDataSource = routingDataSource(sourceDataSource(), replica1DataSource(), replica2DataSource());
return new LazyConnectionDataSourceProxy(determinedDataSource);
}
@Bean
@Qualifier(SOURCE_NAME)
@ConfigurationProperties(prefix = "spring.datasource.source")
public DataSource sourceDataSource() {
return DataSourceBuilder.create()
.build();
}
@Bean
@Qualifier(REPLICA_1_NAME)
@ConfigurationProperties(prefix = "spring.datasource.replica1")
public DataSource replica1DataSource() {
return DataSourceBuilder.create()
.build();
}
@Bean
@Qualifier(REPLICA_2_NAME)
@ConfigurationProperties(prefix = "spring.datasource.replica2")
public DataSource replica2DataSource() {
return DataSourceBuilder.create()
.build();
}
}
이후에 성능 테스트로 게시글 조회에 대한 테스트를 진행해본 결과, 2,000명을 기준으로 40TPS 에서 177.8 TPS로 4.4배 증가하였다.
레플리케이션 도입 전
레플리케이션 도입 전
자세한 내용은 해당 포스팅에 정리했습니다.
기존 히빗 ver1 에서 특정 게시글에 대한 조회수 증가에 대해 성능 테스트로 해본 결과, 정합성이 맞지 않는 문제가 생겼다.
서로 다른 사용자 1000명이 해당 게시글을 조회하면, 당연히 1000회가 증가해야 했는데, 아래와 같이 117회의 조회수만 정상적으로 증가된 것을 확인할 수 있다.
이러한 부분을 해결하기 위해 여러가지 방법 중 쿼리(DB atomic operation)을 적용했다.
public interface PostRepository extends JpaRepository<Post, Long> {
@Query("SELECT p FROM Post p WHERE p.id = :id")
Optional<Post> findByIdForUpdate(@Param("id") final Long id);
// ...
@Transactional
@Modifying
@Query("UPDATE Post p SET p.viewCount = p.viewCount + 1 WHERE p.id = :postId")
void updateViewCount(@Param("postId") Long postId);
}
for update
를 통해 조회하지 않고 이렇게 자기 자신의 값을 이용하여 계산한다면, 배타락 덕분에 조회수 개수에 대한 데이터 정합성을 보장할 수 있다.
위 그림에서 보는 것처럼 먼저 실행된 트랙잭션이 update 쿼리를 통해 마치고 커밋 또는 롤백할 때까지 락 획득을 위해 대기하고 있는 방식이다.
해당 내용과 관련된 PR 입니다.
기존 히빗 ver1 에서는 사용자 입력을 그대로 쿼리에 사용할 경우 SQL 인젝션 공격의 위험이 있었고, 특정 키워드가 없는 경우에 대한 처리가 전혀 없었다.
따라서 안전하게 사용자 입력을 처리하여 SQL 인젝션 공격을 방지하고, 빈 입력값에 대해서도 적절히 처리할 수 있는 검색 기능을 구현하는 것을 목표로 두었다.
그리고 특정 키워드로 게시물을 검색하는 기능은 있지만, Page를 사용해서 구현했다.
하지만 총 페이지 수에 대한 값이 필요하지 않다면 Page
대신 Slice
를 적용하는게 성능 개선에 있어서 더 나은 방법을 알게되었다.
해결1. SQL 인젝션 공격과 빈 입력값에 대한 처리를 위해 SearchQuery
클래스 생성
SearchQuery
클래스를 통해 특수 문자 및 SQL 예약어 제거 로직을 구현하였고, 이를 통해 안전한 검색 쿼리 생성이 가능해졌다.```java
public class SearchQuery {
private static final Pattern SPECIAL_CHARS = Pattern.compile(“\[‘”-#@;=*/+]”);
private static final Set
스케일 아웃 / 스케일 업 ⇒ 할 수도 있지만, 10배를 대비해봤자 그 이상이 나오면 장애가 날 거임
왜 Redis 를 선택했을까?
어떤 요구사항인가?
레디스 사용시 고려사항
프로모션 스케줄러를 통해서 뒤로 흘리는 TPS를 조절
하나의 문제점 → 큐 시스템
을 중간에 어떻게 끼워넣지?
주문라우터
를 이용주문라우터
에 있는 해당 Rule을 이용한다.⇒ 이벤트에 영향없이 일반주문은 가능하도록 장애 격리
모니터링 - CloudWatch
10만 이상의 트래픽 경험을 쌓기 위해 해당 영상을 참고하게 되었다.
해당 방식은 2019년 우아한형제들에서 발표한 내용으로 현재(2024) 사용하는 방식과 다소 차이가 있을 수 있다.
또한 기존 Mysql 외에 Redis를 사용하면 비용과 관리도 그 만큼 증가하기 때문에, 상황에 맞게 적절히 사용하는게 엔지니어링의 역할이자 책임인 것 같다.
이 글은 실제 히빗 프로젝트(ver.2)를 혼자서 개발하면서 경험한 내용을 정리한 글입니다.
해당 이슈에서 고민했던 주제입니다.
아래 부터는 ‘히빗 프로젝트(ver.2)’를 히빗2
라고 줄여서 작성했습니다.
일반적으로 조회수의 의미와 중요성에 대해 고민과 여러 검색을 통해 알아본 결과, 몇 가지 핵심적인 질문들을 정리해보았다.
한 사용자가 게시글을 여러 번 접속할 때, 그때마다 조회수를 증가시켜야 할까요?
같은 사용자가 여러 번 접속해도 조회수는 단 한 번만 카운트해야 할까요?
사용자가 하루에 한 번만 조회수를 증가시킬 수 있어야 할까요?
비회원이 게시글을 열람할 경우에도 조회수를 카운트해야 할까요?
회원만이 게시글을 열람할 수 있도록 하고, 그 후에만 조회수를 카운트해야 할까요?
한 사용자가 다양한 장소(다른 IP)에서 접속했을 때, 조회수를 어떻게 처리해야 할까요?
조회수가 높다는 것은 게시글의 가치나 정보의 중요성을 나타낼 수 있기 때문에, 특히 커뮤니티 서비스에서는 이 주제에 대해 심도 있게 고민해볼 필요가 있다. 예를 들어, YouTube 같은 서비스에서는 조회수가 수익 창출과 밀접한 관련이 있어 조회수 관리가 매우 중요하다.
히빗2 서비스의 이전 버전(ver.1)에서는 조회수와 관련된 API를 아래와 같이 구현했다.
적용전: PostController
@RestController
public class PostController {
private final PostService postService;
public PostController(PostService postService) {
this.postService = postService;
}
// ...
@GetMapping("api/posts/{id}")
@Operation(summary = "/api/posts/{id}", description = "게시글에 대한 상세 페이지를 조회한다.")
public ResponseEntity<PostDetailResponse> findPost(@PathVariable(name = "id") Long postId) {
PostDetailResponse response = postService.findPost(postId);
return ResponseEntity.ok(response);
}
}
이 구현 방식은 조회수 중복 방지에 대해 고려하지 않았기 때문에 다음과 같은 문제가 있었다.
비회원도 조회할 때마다 조회수가 증가, 하루에 여러 번 조회 가능
한 사용자가 여러 장소(다른 IP)에서 접속해도 조회수가 접속한 수만큼 증가
조회수가 증가할 때마다 데이터베이스에 업데이트, 이는 많은 사용자들이 특정 게시글을 자주 조회할 경우 데이터베이스에 큰 부하를 유발할 수 있음
이러한 문제를 인식하고, 조회수의 어뷰징을 방지하기 위한 새로운 접근 방식이 필요했다.
어뷰징(Abusing)
이란 의도적인 조작을 통해 조회수나 클릭수를 높이기 위한 일련의 행위
이에 따라 히빗2 서비스에서는 조회수 증가에 대한 새로운 기준을 다음과 같이 설정했다.
조회수 증가는 로그인한 회원에게만 허용된다.
한 회원은 하루에 한 번만 조회수를 증가시킬 수 있다.
조회수 증가에 대한 어뷰징을 막는 방법을 스스로도 고민해보고, 구글링을 해보면서 대략 4가지 방법으로 추리게 되었다.
전체 게시글 조회 페이지에서 클릭
쿠키 사용
IP 또는 Mac Address 사용
DB 이용
결론적으로 히빗2
서비스에서는 쿠키를 사용하기로 했다.
HTTP 요청마다 쿠키를 보내주는데, 만약 쿠키값이 커질 경우 네트워크 트래픽에 부담을 줄 수 있다.
하지만 쿠키 표준안인 RFC 2109에 따르면 쿠키는 300개까지 만들 수 있으며, 최대 크기는 4,096바이트(4KB)이고, 하나의 호스트나 도메인에서 최대 20개까지 만들 수 있다고 한다. 대부분의 브라우저는 표준안보다 더 적은 개수의 쿠키만을 지원한다.
악의적인 사용자가 쿠키를 삭제하여 어뷰징을 할 수 있지만, 히빗2에서는 조회수가 수익 창출이나 주요 비즈니스에 큰 영향을 미치지 않기 때문에 이 방법을 선택했다. 또한, 이 프로젝트가 학습 목적이기 때문에 쿠키를 사용하는 경험도 유용하다고 생각했다.
히빗2 서비스에서는 조회수 관리의 정확성을 높이기 위해 ViewCountManager
라는 새로운 클래스를 도입했다.
이 클래스는 쿠키에 저장된 게시글 조회 로그를 파싱하는 역할이다.
쿠키에는 한 도메인당 최대 20개의 항목만 저장할 수 있는 제한이 있다.
이를 극복하기 위해, ViewCountManager
는 하나의 쿠키에 여러 게시글의 ID를 기록하는 방식으로 조회수 관리 로직을 구현했다.
조회수 관리 :
ViewCountManager
@Component
public class ViewCountManager {
private static final String DATE_LOG_DELIMITER = "&";
private static final String DATE_AND_ID_DELIMITER = ":";
private static final String ID_DELIMITER = "/";
private static final int DATE_INDEX = 0;
private static final int LOG_INDEX = 1;
// <DATE>:1/2/3&
public boolean isFirstAccess(String logs, Long postId) {
Map<Integer, String> dateLogs = extractDateLogs(logs);
int today = LocalDateTime.now().getDayOfMonth();
String todayLog = dateLogs.get(today);
if (Objects.isNull(todayLog)) {
return true;
}
return isLogNonExist(todayLog, postId);
}
private Map<Integer, String> extractDateLogs(String logs) {
Map<Integer, String> dateLogs = new HashMap<>();
String[] logsPerDate = logs.split(DATE_LOG_DELIMITER);
for (String logPerDate : logsPerDate) {
dateLogs.putAll(divideDateAndLog(logPerDate));
}
return dateLogs;
}
private boolean isLogNonExist(String log, Long postId) {
List<Long> loggedPostIds = Arrays.stream(log.split(ID_DELIMITER))
.map(Long::parseLong)
.collect(Collectors.toList());
return !loggedPostIds.contains(postId);
}
private Map<Integer, String> divideDateAndLog(String logPerDate) {
if (logPerDate.isEmpty()) {
return Collections.emptyMap();
}
String[] dateAndLog = logPerDate.split(DATE_AND_ID_DELIMITER);
int date = Integer.parseInt(dateAndLog[DATE_INDEX]);
String log = dateAndLog[LOG_INDEX];
return Map.of(date, log);
}
public String getUpdatedLog(String logs, Long postId) {
if (!isFirstAccess(logs, postId)) {
return logs;
}
Map<Integer, String> dateLogs = extractDateLogs(logs);
int today = LocalDateTime.now().getDayOfMonth();
String updatedLog = appendLog(dateLogs.get(today), postId);
return today + DATE_AND_ID_DELIMITER + updatedLog;
}
private String appendLog(String log, Long postId) {
if (Objects.isNull(log) || log.isEmpty()) {
return Long.toString(postId);
}
return log + ID_DELIMITER + postId;
}
}
이 방식을 사용하면, 로그 문자열은 다음과 같은 형태를 갖는다.
<날짜>:<PostID>/<PostID>/<PostID>&<날짜>:<PostID>/<PostID>&...
이를 통해 날짜에 어떤 포스트가 조회되었는지 추적할 수 있다. 예를 들어, 쿠키에 “27:1/2/3&28:4/5”라는 값이 저장되어 있다면, 이는 27일에 게시글 1, 2, 3이 조회되었고, 28일에는 게시글 4, 5가 조회되었음을 나타낸다.
ViewCountManager
에 대한 테스트 코드를 작성한 결과, 아래와 같이 방문 여부에 따른 값과 다른 게시글을 방문할 때마다 log를 업데이트한 것을 확인할 수 있다.
PostService는 이전에 해당 게시글을 조회하지 않았던 경우에만 조회수를 데이터베이스에 업데이트하는 로직을 구현했다.
적용후:
PostService
@Service
@Transactional(readOnly = true)
public class PostService {
private final PostRepository postRepository;
private final ViewCountManager viewCountManager;
// ...
@Transactional
public PostDetailResponse findPost(final Long postId, final LoginMember loginMember, final String cookieValue) {
if (viewCountManager.isFirstAccess(cookieValue, postId)) { // 해당 게시글에 처음 방문했다면
postRepository.updateViewCount(postId);
}
Post foundPost = findPostObject(postId);
return PostDetailResponse.of(foundPost, loginMember);
}
public String updatePostLog(final Long postId, final String cookieValue) { // 다른 게시글ID를 포함한 로그를 쿠키에 저장
return viewCountManager.getUpdatedLog(cookieValue, postId);
}
private Post findPostObject(final Long postId) {
List<Post> posts = postRepository.findPostById(postId);
if (posts.isEmpty()) {
throw new NotFoundPostException();
}
return posts.get(0);
}
}
PostService
에 대한 테스트 코드로 검증한 결과 정상적으로 나오는 걸 확인할 수 있다.
PostController
에서는 PostService
를 통해 게시글 상세 정보를 가져오고, 쿠키를 업데이트하여 조회 로그를 관리한다.
적용후:
PostController
@Tag(name = "posts", description = "매칭 게시글")
@RestController
public class PostController {
private final PostService postService;
@GetMapping("api/posts/{id}")
@Operation(summary = "/api/posts/{id}", description = "게시글에 대한 상세 페이지를 조회한다.")
public ResponseEntity<PostDetailResponse> findPost(@PathVariable(name = "id") final Long postId,
@AuthenticationPrincipal final LoginMember loginMember,
@CookieValue(value = "viewedPost", required = false, defaultValue = "") final String postLog) {
PostDetailResponse response = postService.findPost(postId, loginMember, postLog);
String updatedLog = postService.updatePostLog(postId, postLog);
ResponseCookie responseCookie = ResponseCookie.from("viewedPost", updatedLog).maxAge(86400L).build(); // 86400L: 1일(24시간)
return ResponseEntity.ok().header(HttpHeaders.SET_COOKIE, responseCookie.toString()).body(response);
}
}
추가적으로 쿠키에 대한 maxAge를 설정하지 않으면 브라우저가 종료될 때 쿠키가 사라지는 문제가 생긴다. 따라서 이를 방지하기 위해 쿠키의 maxAge를 1일(24시간)으로 설정했다.
특정 게시글에 대한 조회 API를 Postman
으로 확인한 결과 아래와 같이 viewedPost
값이 제대로 나오는 것을 확인할 수 있다.
어뷰징 방지를 위해 조회수 증가 기준을 설정하고, 이를 쿠키를 통해 구현하는 과정을 진행했다. 악의적인 사용자가 쿠키를 삭제하여 어뷰징을 할 수 있으나, 현재 히빗2 서비스에서는 조회수가 수익이나 비즈니스에 큰 영향을 미치지 않아 문제가 되지 않는다. 또한, 쿠키에 저장된 정보는 날짜와 게시글 ID에 불과하므로, 정보가 탈취되어도 큰 문제가 없다.
쿠키의 표준에 따라 하나의 도메인에 최대 20개의 쿠키만 저장할 수 있으므로, 대안으로 하나의 쿠키에 "<DATE>/1/2/3/"
같은 형식으로 여러 게시글 ID를 문자열로 저장하고 분할하는 방식을 선택했다.
하지만, 사용자 수가 증가하면 쿠키의 한계에 부딪힐 수 있다.
이를 해결하기 위해 인메모리 데이터 저장소인 Redis를 활용하여 IP나 MAC 주소와 게시글을 key-value 구조로 저장하는 방법을 고려할 수 있으나, 조회수가 현재 서비스에 큰 영향을 주지 않아 이 방법은 채택하지 않았다.
이후에 조회수가 현재보다 더 중요한 가치로 생긴다면, 그때가서 다시 한번 고민해보고 더 나은 개선 방안을 생각해보자.