개발스토리

2021 회고

무루뭉 — Thu, 6 Jan 2022 02:08:13 +0900

2021년은 많은 경험을 하고 스스로의 길을 정하게 된 한 해가 된 것 같다.

2021 학교 활동

4학년의 시간을 보냈다. 아무래도 2학기는 인턴 활동으로 학교 생활을 하지 않게 되면서 1학기가 나의 마지막 학교 생활이었다. 사실 비대면이 계속 되면서 제대로 된 학교 생활을 하지는 못해서 아쉽지만 이제는 끝이니까 뭐,,

아무래도 1학기에는 졸업작품(캡스톤)을 만들었던 게 제일 기억에 남았다. 뜻이 맞는 친구들 + 나까지 5명에서 영어 단어 암기를 도와주는 안드로이드 어플을 만들었다. 결과는 A+로 1등을 했던 것 같다.

하지만 과정은 다사다난했던 것 같다. 배포를 목적으로 기획을 진행했고 1개월반-2개월 정도 흐른 상황에서 저작권에 늪에 빠지게 되었다.. 한영사전 API를 당연히 제공해줄 것이라고 생각했던 불찰이었다. 예문이 저작권에 걸려서 API 제공을 안해준단다... 예문이 저작권에 걸릴지는 생각도 못했다. 그래서 다른 API 제공 사이트도 찾아봤지만 베타 버전이라 정확도가 너무 떨어지고, 캠브리지 대학에 메일까지 보내봤다. 하지만 원하는 대로 흘러가지 않아 급히 크롤링으로 대처하기로 했다. 그래도 결과물은 만족스럽게 나왔다.

지금 생각해보면 캡스톤 프로젝트를 할 때 쯤 올 한해에 가장 많이 성장했던 것 같다.

심심하면 시연 영상 한 번 봐주3

https://youtube.com/watch?v=SCJ3Xw6QmJk&feature=share

2021 동아리 활동

2020년부터 많은 외부 활동에 지원을 했지만 모두 떨어졌었다. 오로지 혼자 강의를 듣고 클론 코딩을 하고 있었다. 개발에 대한 방향성을 전혀 잡지 못한 상태에서 마음만 조급했었던 것 같다. 그래서 github 내역도 꾸준히 올렸고, 지금 작성하는 블로그도 시작했다. 그러고 나서 2020 하반기에 동아리 공고에 지원을 다시 시작했다. 내가 지원한 동아리는 모두 붙었던 것 같다.

2021년 상반기에 IT 동아리에 들어가서 노드팀으로 활동을 시작했다. 지금 생각해보면 걱정을 많이 했었던 것 같다. 스스로에게 자신감이 너무 없어서 이게 맞을까..?라는 생각으로 시간을 많이 낭비했던 것 같다. 처음으로 다양한 개발자들과 디자이너들과의 협업을 했었다. 더 열심히 참여했으면 어땠을까라는 아쉬움이 많이 남는 기간이었다. 또 이 기간동안 느낀 것은 아는 것이 있어야 그만큼의 설득력이 있다는 것이었다. 지금 생각해보면 아는 것이 없었기 때문에 용기가 없었던 것 같다.

그래도 얻는 것은 많았다. 처음으로 AWS 비용도 많이 나와서 환불도 받아보고(내 실수로,,ㅎ) 처음으로 앱 스토어에 배포도 해보았다.

2021년 하반기에도 노드팀으로 활동을 이어갔다. express를 통해 개발을 하다가 nest라는 프레임워크를 통해 개발을 했다. 상반기 활동에 아쉬움이 많이 남아 하반기에는 최대한 활발하게 활동하려고 노력했다. 동아리 면접관으로도 참여했다. 면접관으로 참여할 능력은 많이 부족한 것은 알지만 다양한 사람들과 대화를 해보고 싶었다. 그리고 프로젝트 서버팀에서도 리드를 맡아보겠다고 이야기 했다. AWS도 다양한 경험을 해보고 싶어서 API 별개로 역할을 맡게 되었다.

aws, docker, 새로운 프레임워크 등등 조금 알거나 처음 해보는 것들을 도전해보는 과정에서 시간을 많이 투자했던 것 같다. 별개로 더 restful하게 설계하기 위해 다양한 레퍼런스도 찾아보고 적용해봤다. 아쉬웠던 것은 초반에는 코드리뷰가 어느정도 활발히 이루어졌지만 후반 갈수록 느슨해졌다는 것이다.

갈 길은 멀지만 어느정도 내가 성장했다는 것을 알 수 있는 시간이었다. 앱 스토어에 배포도 하고 꾸준히 유지 보수를 하면서 업데이트를 하기로 팀원들끼리 이야기가 잘 되어 꾸준하게 개발할 예정이다.

https://apps.apple.com/kr/app/rrrr/id1558135806

‎Rrrr

‎일상속 지겨운 알람, Rrrr를 통해 일상을 즐겁게! 단순한 기본 알람이 지겨우셨나요? 오늘부터 Rrrr를 통해 나만의 커스텀 알람을 가져보세요. 다양한 문구, 링크를 추가하여 중요한 순간을 인상

apps.apple.com

https://apps.apple.com/kr/app/meetu-%EB%AF%B8%EC%B8%84/id1598412305

‎MEETU (미츄)

‎미츄는 다양한 내 모습을 쉽고 재미있게 소개할 수 있는 온라인 명함 제작 서비스입니다. 명함 제작 템플릿을 이용하여 쉽고 빠르게 나만의 미츄 카드를 제작할 수 있어요. 나의 부캐를 보여

apps.apple.com

2021 인턴 활동

8월부터 12월까지 인턴 활동을 마쳤다.

원래 나는 node를 사용해서 서버 개발을 주로 해왔다. 하지만 spring을 사용해 볼 기회가 생겨서 인턴 활동을 결심했다.

데이터 정합성, 무결성 등을 보장해주기 위한 솔루션을 개발하는 팀에서 서버 개발자로 활동을 했다. 자바를 오랜만에 보고 사용해서 그런 지 처음에는 조금 힘들었다. 또한 springboot + jpa를 사용해서 개발을 했는데 jpa가 여태까지 써왔던 orm과는 많이 달랐다. 매커니즘을 이해하기에 어려웠던 것 같다. 퇴근하고 강의듣고 주말에도 개인 공부를 통해 회사가서 적용해보고 했던 것 같다.

이걸 적기 전에도 jpa 공부를 했는데 아직 어렵긴 하다..ㅎ

그래도 내 의견을 많이 이야기 했던 것 같다. 초반에는 세미나도 매 주 진행하고 REST API를 설계하면서 의견 제시도 많이하고 개발 방향성에 대해서도 의견을 많이 제시했다.

현업에서 실제 일하면서 평소 생각하던 느낌과 많이 다른 부분도 있었지만 많은 것을 느끼게 해준 인턴 활동이었던 것 같다.

이 것 말고도 2021년에는 허리디스크가 터져서 구급차에 실려가기도 하고 고생을 좀 많이 했다.

앉아 있어야 하는 직업인데 앉아 있기 힘드니까.. 그래서 한 동안 운동도 하지 못하고 거의 요양했다. 프로젝트 기간에는 어쩔 수 없이 책상에 앉아야 하니 좀 힘들었던 것 같다. 올 해에는 꾸준히 운동을 다시 시작해야겠다. 허리 터지면 일상생활 절대 불가. 그렇게 아픈 경험 하기 힘들 것 같다.

올 해는 또 스프링으로 동아리 활동을 이어간다. 처음 개발을 시작할 때 스프링을 공부했지만 뭔소린지 하나도 모르겠어서 개발의 흥미를 잃지 않으려고 빨리빨리 눈에 보이는 노드를 선택해서 지금까지 공부해왔다. 이제는 스프링을 제대로 다시 시작하려 한다.

그래도 작년을 돌이켜보니 열심히 공부를 했던 것 같다. 아직 부족하지만 올 해도 성장할 수 있는 한 해를 보내기 위해 노력해야겠다. 빠잉

단 건 조회 시 데이터가 없다면..?부터 시작된 이야기

무루뭉 — Fri, 10 Dec 2021 09:02:57 +0900

API를 만들어 내면서 단 건 조회 시 데이터가 없다면 response를 빈 객체로 내려주기로 했다.

아래와 같은 상황을 예시로 두겠다.

한 명의 유저를 조회하는 GET test.com/users/{userId}라는 API가 있다고 보자.

성공적으로 조회가 완료가 됐다면, 아래와 같이 response를 보내주었다.

{
  "success": true,
  "response": { "id": 1, "nickname": "king" },
  "error": null
}

하지만, GET test.com/users/100 즉, 100번의 유저를 조회하려하는 데 100번의 유저가 없다면...??

{
  "success": true,
  "response": { "id": null, "nickname": null },
  "error": null
}

원래는 위와 같이 응답이 내려갔다.

하지만 프론트 쪽에서 판단하기에는 매번 (프론트에서 선언한 변수).response.id가 null인 지를 체크하는 비효율적인 코드가 나왔다.

그래서 아래와 같이 빈 객체를 내려주기로 하였다.

{
  "success": true,
  "response": {},
  "error": null
}

왜 이런 결정을 하였나??

> 모든 api에서 단 건 조회시 데이터가 없을 때 위와 같은 응답을 내려준다면 JS 메서드로 response에 담긴 객체가 비었는 지 아닌 지를 체크하는 공통 로직으로 다룰 수 있다.

대안으로는 어떤게 제안되었는가??

> 별도의 필드로 count를 내려주어 0이라면 데이터가 없다는 걸로 판별하자는 방법도 나왔었다.

그렇다면 아래와 같은 응답이 내려간다.

{
  "success": true,
  "response": { "id": null, "nickname": null },
  "error": null,
  "count" : 0
}

리스트 조회가 아닌 단건 조회에서 0아니면 1로만 이루어진 별도의 필드를 두는 것은 내키지 않았다.

그래서 결국에는 빈 객체로 내려주기로 하였다.

어떤 방식으로 내려주는 가?

여기서부터 삽질이 시작됨...

    @Transactional(readOnly = true)
    @Override
    public UserDto findOneUser(Long userId) {
        Optional<User> user = userRepository.findByUserId(userId);
        return user.map(UserDto::new).orElseGet(UserDto::new);
    }

원래 이런 코드에서 빈 객체가 내려가도록 바꿔야 했다.

하지만 이미 타입이 Optional이 걸려있고, UserDto가 걸려있어 빈 객체랑 타입 불일치가 있다.

여기서부터 무한 고민,,,, 어떻게 바꿀까,,, 어떻게 할까,,, ( 선배 개발자분에게 의견을 여쭤봄.... )

단 건 조회는 API마다 다 있고 데이터가 없는 상황일 때 동일한 처리를 해줘야 한다.

그래서 Exception Handler를 따로 생성해서 처리하기로 했다!

package com.meta.common.exception;


public class NoDataException extends RuntimeException {}

따로 메시지는 날리지 않을 거기 때문에 간단하게 Exception class를 만들었다.

그 다음 ExceptionHandler를 모아둔 파일에 다음과 같이 작성했다.

@RestControllerAdvice(annotations = {RestController.class, Controller.class})
public class ExceptionHandler {
  @ExceptionHandler
    public ResponseEntity<ApiResult<?>> noDataException(NoDataException e) {
        Object result = new Object();
        return new ResponseEntity<>(ApiUtils.success(result), HttpStatus.OK);
    }
 }

"No serializer found for class ~ and no properties discovered to create BeanSerializer"

직렬화를 해야 하는 데 지금은 가장 원초적인 Object 타입을 두었기 때문에 이 에러를 해결할 방법이 떠오르지 않았다.

그래서 EmptyDto를 따로두었다.

import java.io.Serializable;

public class EmptyDto implements Serializable {}

하지만 같은 에러가 나왔다..! 검색해보니 보통 private 필드를 두고 getter를 안두었거나 하는 등에 문제였다.

나는 어떤 필드도 없다..! 그래서 필드가 없으니..!? 직렬화 시켜줄 게 없다? 라는 생각을 했다.

또 검색,,,검색,,

ㄷㄷㄷㅈ!!

관련 레퍼런스들을 찾아보니 spring.jackson.serialization.FAIL_ON_EMPTY_BEANS 요 설정의 디폴트가 true인 것 같다.

기본값이 유형에 대한 접근자를 찾을 수 없을 때 직렬화를 할 수 없는 유형으로 나타내기 위해 예외가 발생되도록 한다.

값을 false로 바꿔주던가...!하면 된다.

또한, 다양한 어노테이션들로 해결이 가능했다.

import com.fasterxml.jackson.databind.annotation.JsonSerialize;

import java.io.Serializable;

@JsonSerialize
public class EmptyDto implements Serializable {}

import org.codehaus.jackson.annotate.JsonIgnoreProperties;

import java.io.Serializable;

@JsonIgnoreProperties(ignoreUnknown = true)
public class EmptyDto implements Serializable {}

import org.codehaus.jackson.annotate.JsonIgnoreProperties;

import java.io.Serializable;

@JsonIgnoreProperties({"hibernateLazyInitializer", "handler"})
public class EmptyDto implements Serializable {}

등등... 다양한 어노테이션들로 테스트가 다 통과된다...!!

최종 나의 서비스 파일이다.

    @Transactional(readOnly = true)
    @Override
    public UserDto findOneUser(Long userId) {
        Optional<User> user = userRepository.findByUserId(userId);
        return user.map(UserDto::new).orElseThrow(NoDataException::new);
    }

느낀점

> 진짜 다양한 해결 방법이 있다..

> Jackson 라이브러리를 정독해봐야겠다..!

> Optional을 다루는 것이 아직 너무 미숙하다..!

이번 이슈를 통해 배운게 많은듯..!!!

[REST docs error] java.lang.IllegalArgumentException: urlTemplate not found. If you are using MockMvc did you use RestDocumentationRequestBuilders to build the request?

무루뭉 — Tue, 16 Nov 2021 16:05:26 +0900

java.lang.IllegalArgumentException: urlTemplate not found. If you are using MockMvc did you use RestDocumentationRequestBuilders to build the request?

Rest Docs를 적용을 하고 api 문서를 뽑아내는 중에 위와 같은 오류를 만났다.

어쩌다 만났느냐..!?

api 문서를 만들려면 당연히 클라이언트에게 api를 사용하기 위한 모든 정보를 적어서 줘야 한다.

예를 들어 user를 조회하기 위한 api url이 domain/user/{username}이라고 치자.

domain/user는 변하지 않지만 username은 동적이다. joo라는 사용자를 조회할 수도 있고 kim이라는 사용자를 조회할 수도 있다.

MvcResult mvcResult = requestGet(baseUrl + "/user/{username}", "joo")
                .andExpect(status().isOk())
                .andDo(document("user-select",
                        pathParameters(
                                parameterWithName("username").description("유저 이름")
                        )

나는 이런 코드로 스니펫을 뽑아 내려고 했다. 하지만 이 글에 제목과 같은 에러를 만난 것이다.

사실 에러 로그를 많이 만나면서 점점 에러 로그를 꼼꼼히 읽고 있었다.

에러 로그 보면 너무 친절하게 알려준다. 그대로 번역해보겠다.

java.lang.IllegalArgumentException: urlTemplate을 찾을 수 없습니다. MockMvc를 사용하는 경우 RestDocumentationRequestBuilders를 사용하여 요청을 작성했습니까?

와우,,, 그냥 MockMvc로 썼으면 RestDocumentationRequestBuilders를 써봐라고 알려준다.

공식문서를 내용을 가져와 보겠다.

더욱 친절하게 알려준다. path parameters를 사용하고 싶으면 RestDocumentationRequestBuilders를 쓰라고!!

그래서 나는 위와 같은 코드에 변경을 줘서 해결했다..!

Spring REST Docs 적용

무루뭉 — Thu, 11 Nov 2021 13:28:14 +0900

전 포스팅에 이어서 이번에는 spring 프로젝트에 적용한 포스팅을 쓴다.

주요 라이브러리 버전

- spring boot 2.x.x

- gradle 6.x

- junit 5

build.gradle

plugins {
    id 'org.springframework.boot' version '2.x.x'
    id 'io.spring.dependency-management' version '1.0.10.RELEASE'
    id 'java'
    // asciidoc 파일을 변환해서, build 폴더에 복사해주는 플러그인!
    id 'org.asciidoctor.convert' version "1.5.6"
}

asciidoctor {
    dependsOn test    // gradle build 시 test -> asciidoctor 순으로 수행
}

bootJar {
    dependsOn asciidoctor    // gradle build 시 asciidoctor 순으로 수행
    from("${asciidoctor.outputDir}/html5") {    // gradle build 시 ./build/asciidoc/html5/ 에 html 파일생성
        into 'static/docs'                        // html 파일이 jar 안의 /static/docs/ 폴더로 복사됨
    }
}

dependencies {
	...
	testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc'
    ...
}

테스트 코드

레퍼런스 들을 찾다보면 @AutoConfigureRestDocs를 사용해서 설정을 하는 데 설정이 적용이 안돼서 보니까 junit5에서는 안먹힌다고 한다..!

@ExtendWith(RestDocumentationExtension.class)를 필수로 넣어줘야 한다.

@ExtendWith(RestDocumentationExtension.class)
@WebMvcTest(controllers = HelloController.class)
public class HelloControllerTest {}

- RestDocumentationExtension

위에 이 녀석이 자동으로 빌드 툴에 맞는 output 디렉터리를 설정한다. 나는 gradle을 사용하므로

build/generated-snippets 경로에 snippet들이 생성된다.

@BeforeEach
    void setup(WebApplicationContext webApplicationContext, RestDocumentationContextProvider restDocumentation) {
        this.mvc = MockMvcBuilders.webAppContextSetup(webApplicationContext)
                .apply(documentationConfiguration(restDocumentation))
                .apply(springSecurity()).build(); // spring secutiry 쓰고있어서 추가함
    }

테스트 코드를 작성하는 방법은 공식문서를 참조하기 바란다. 다양한 메서드들이 있으므로~

https://docs.spring.io/spring-restdocs/docs/2.0.5.RELEASE/reference/html5/#getting-started-using-the-snippets

Spring REST Docs

Document RESTful services by combining hand-written documentation with auto-generated snippets produced with Spring MVC Test.

docs.spring.io

테스트에 성공하면 build/generated-snippets에 .adoc 파일들이 생기는 걸 볼 수 있다.

이제 생성된 스니펫들을 사용하면 된다.

gradle의 경우 src/docs/asciidoc/*.adoc 을 생성해준다. 경로는 지켜주어야 한다.

그리고, 문서 기능을 하기 위해 조합해주면 되는데 공식문서 참조바란다. 나는 참고로 마크다운이랑 비슷한 느낌을 받았다.

이 전에 생성한 스니펫들을 사용하려면 include::{snippets}/~경로~/*.adoc[] 이런식으로 사용하면 된다.

인텔리제이에서는 전용 플러그인이 있으니 바로바로 결과를 확인해볼 수 있다.

잘 작성하고

./gradlew build 하면 build/asciidoc/html5 경로에 api.html이 생성된다. 본인이 생성한 .adoc 파일의 이름으로 .html이 생성된다.

그러고 프로젝트 경로로 들어가 cd build/libs로 가서 java -jar *.jar 한다.

그러고 localhost:8080/docs/api.html 접속하면 생성한 문서가 짠! 하고 반겨 줄 것이다.

<느낀 점>

설정이 복잡하다. 그리고 확실히 테스트 코드를 짜는 능력이 있어야 한다. 테스트 코드를 짜지 않으면 사용 자체를 못하기 때문이다. 아직은 설정하고 간단한 api로 적용만 해봤지만 스웨거가 그립달까? 쉽긴 쉬웠는데...

그래도 스스로의 레벨업을 위해서라면 가면 좋은 방향인 것 같다.

+++

나는 gradle 6버전을 썼다,. 7버전을 쓰면 build error가 뜨는 경우가 있다고 한다.

https://gaemi606.tistory.com/entry/Spring-Boot-REST-Docs-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0

Spring Boot | REST Docs 적용하기 ( + build failed 해결.. )

Spring REST Docs? Asciidoctor를 사용해 RESTful 서비스에 대한 문서를 생성하도록 돕는다. Swagger vs REST Docs Swagger UI Spring REST Docs 실제 코드에 애노테이션을 추가하여 문서가 작성되는 방식 -> 가독..

gaemi606.tistory.com

아래 글 참조하면 될 듯하다. 나도 많이 참조했다.

Spring REST Docs 도입 이유

무루뭉 — Thu, 11 Nov 2021 11:16:10 +0900

회사에서 새로운 프로젝트를 시작하는데 REST API 설계부터 하고 api 문서를 뽑아내기 위해 REST Docs를 적용하기로 했다.

Spring REST Docs?

- Asciidoctor를 사용해서 API 문서를 생성하도록 돕는 것이다.

나는 여러 사이드 프로젝트를 하면서 API 문서를 전달하기 위해 swagger, postman, notion 등을 사용했었다.

이번에는 REST Docs를 적용해야 해서 오랜만에 글을 써본다.

우선 여러 방법으로 api 문서를 뽑아내면서 느낀 점을 간단히 소개해보겠다.

swagger

- 실제 코드에 어노테이션들이 추가 되면서 문서가 생성된다.

- 가독성 측면에서 여러 어노테이션이 달리면 지저분해 보일 수 있다. 실제로 지저분해 보이긴했다.

- 하지만 많이 쓰이는 이유는 쉽기 때문이라고 생각한다.

- 실제 서버가 구동되면서 api를 테스트 해볼 수 있는 것은 큰 장점이라고 생각한다.

postman

- 테스트 코드를 많이 사용하기 전에는 api 테스트를 postman을 통해서 했었다. ( 테스트 코드 작성이 미숙해 아직도 많이 사용 중이긴 함...)

- 직접 테스트를 하면서 api doc을 생성해서 문서를 뽑아내 줄 수 있다.

- 이것 또한 서버가 구동되면 api를 테스트 해볼 수 있다.

- 사실 별다른 단점은 나는 잘 모르겠다.. 있다면 알려주세요ㅎㅎ

notion

- 노션은 좋은 어플리케이션임은 분명하지만 api 문서를 제공한다는 목적에는 부합하지 않는 것 같았다.

- 일일이 쳐줘야 했으며 사실 복붙을 엄청했었음..ㅎㅎ

- 회의록이나, 스프린트 관리할 때는 되게 좋았었음!

그래서 왜 REST Docs를 채택했나!

우선 문서를 자동화하는 것을 원했다. 또한, 깔끔한 api 문서를 원했으며 깔끔한 코드를 작성하기로 하였다.

그리고 test code를 중요시하여 test coverage를 높이기로 했다.

이러한 이유는 REST Docs를 가리켰다. test code를 작성해야 문서를 자동화시켜주기 때문이다.

이는 생산성 저하로 이루어질 수 있지만 test code를 열심히 공부하고 적용할거니까..ㅎㅎ

나는 실제로 문서와 함께 테스트 해볼 수 있는 환경을 원했지만 결국은 api "문서"이기 때문에 여러가지 이유로

채택하게 되었다.

다음에는 REST Docs를 적용하는 포스팅으로 와보겠다! 빠잉~

TestContainer

무루뭉 — Tue, 14 Sep 2021 13:11:21 +0900

테스트 코드를 작성하는 환경을 구축하는 것은 중요하다.

처음에 가장 어렵고, 귀찮고, 시행착오도 많이 겪는 과정이라고 생각한다.

테스트 환경을 구축하는 과정에서 많은 부분을 고려해야 하지만 특히 주의해야할 부분은 "멱등성"이다.

■ 멱등성이란 여러번 연산을 실행해도 결과가 바뀌지 않는 성질을 뜻한다.

HTTP method에서 보자면 POST를 제외하고 나머지는 멱등성을 만족한다.

POST 요청을 반복한다면, 데이터들은 계속해서 추가가 되고, 서버의 응답은 다 다른 응답을 나타낸다. 같은 내용이더라도 서로 다른 데이터이다.

PUT 요청으로 2번 데이터를 수정한다고 치면, 2번 데이터가 없는 경우에는 데이터가 생성될 수 있지만, 이미 존재하면 데이터는 수정이 된다. 계속해서 PUT 요청을 날려도 2번 데이터는 우리가 요청한 데이터 값을 가지고 있다.

DELETE는 데이터가 존재하든, 존재하지 않든 DELETE 요청을 날린 시점에서 사라지게 되므로 우리가 요청한 사항은 이루어졌음을 의미한다.

GET은 같은 데이터를 계속해서 응답하므로 이해가 쉬울 것이다.

우리는 프로젝트를 진행하면서 외부 모듈들을 많이 쓴다. 또한, 서버에 변경 코드들은 계속해서 추가가 되며

이것들을 계속해서 신경쓰며 관리하는 것은 어려우며, 하고 싶지 않을 것이다.

바로 이러한 부분에서 멱등성이 깨지기 쉽다. 멱등성이 깨지게 된다면, 우리가 생각했던 데로 서비스가 굴러가지 않는다.

또한 잘 실행되던 것들이 갑자기 에러 천국으로 변할 수도 있다.

그래서 반드시 테스트 환경 구축과 코드 작성에 있어서는 멱등성을 고려해야 한다.

TestContainer로 멱등성을 유지해보자.

우선, 테스트 환경에서 외부 의존성이 있는 것 중에 가장 기본적인 것은 DB라고 볼 수 있다.

1. 로컬 환경에서 실제 DB를 띄우는 방법

- 이 방법은 실제와 거의 유사한 환경으로 테스트를 할 수 있지만 동시에 여러 테스트가 이루어지거나, 테스트가 끝났음에도 테스트용 데이터가 남아있는 문제들로 멱등성을 관리하기가 어렵다.

- 다른 방법 중 가장 신경써야할 일이 많은 것 같음.

- 협업을 하면서 다른 사람들과 테스트를 동시 수행하면서 의도치 않은 데이터 변경이 일어날 수 있음.

2. in-memory DB를 활용하는 방법

- H2 등을 사용하고 ORM을 통해서 특정 DB와의 종속성을 해결하는 방법이다. 빠르고, 간단하지만 특정 DB에 특화된 기능을 테스트하거나 DDL을 명시할 때 실제 동작과는 다른 SQL을 작성해야한다는 문제가 있다. ( 실제 쿼리 수행과 완벽하게 동작하지 않을 수 있다 -> 가장 단점 같음 ) , 테스트 환경과 개발 환경이 같은 상황에서 테스트하는 것이 중요해보임

- 외부 db 커넥션이 없고, 테스트 수행 후 데이터 롤백이 필요없다는 장점도 있다.

- 개발 사항에 따라 스키마 초기 구성을 최신화해줘야하는데 프로젝트가 커지면 데이터 양이 너무 많다. -> 추가 관리 항목

3. Docker-Compose 활용하는 방법

- 위에 1 , 2번 방법이 아니라도 도커 이미지만 가지고 있다면 테스트 환경을 구축할 수 있다. 이 것도 간편한 방법이지만 docker-compose 파일을 관리해야하는 번거로움이 있다. 또한, random port를 통해 local 포트 충돌 방지 및 병렬 테스트를 어렵게 만든다. 또한, 도커를 올렸다가 내렸다가 하는 과정도 귀찮고, 자칫하면 백그라운드에 남아있어 리소스를 잡아먹을 수도 있다.

4. TestContainer 활용하는 방법

- 테스트 전에 H2, Oracle(예시), Docker Container를 따로 띄우지 않아도 자동으로 테스트할 때 DB Container를 띄어주고 테스트가 종료되면 컨테이너도 같이 종료시켜주는 역할을 한다. 3번 방법과 동작 원리는 같지만, 실제로 설정하는 것은 확 줄어든다.

+++

기존 방식과 다른 점은 test container가 실행된 random port로 접근해서 local port간의 충돌을 방지하고 병렬 test를 가능하게 한다는 점이다.

+++

도커를 사용하면 변화하지 않는 실행환경으로 멱등성을 확보할 수 있다.

서버에 변경을 가하고 싶은 경우에는 그냥 새로운 서버를 구축하고 이미지로 빌드하고 컨테이너를 띄어버리면 된다.

도커를 사용하지 않았을 때에 잦은 업데이트 등으로 멱등성을 보장할 수 없는 경우는 빈번히 발생할 수 있다.

단지, 도커를 자동으로 띄어주고 알아서 내려주는 것만을 장점으로 생각했지만 멱등성이라는 주요 이슈가 있다는 것을 새로 알게 되었다.

TestContainer를 도입하는 것도 괜찮을 것 같다.

참고 : https://riiidtechblog.medium.com/testcontainer-%EB%A1%9C-%EB%A9%B1%EB%93%B1%EC%84%B1%EC%9E%88%EB%8A%94-integration-test-%ED%99%98%EA%B2%BD-%EA%B5%AC%EC%B6%95%ED%95%98%EA%B8%B0-4a6287551a31

java.lang.illegalargumentexception at least one jpa metamodel must be present

무루뭉 — Thu, 9 Sep 2021 14:06:49 +0900

JPA를 사용하고 테스트 코드 작성하는 것을 연습하고 있는데 이런 에러가 떴다..!

에러 로그를 살펴보면 적어도 하나의 jpa metamodel이 필요한 데 없어서 그런것 같다.

이게 무슨 뜻인지 천천히 생각해봤다.

우선 JPA에서는 엔티티들의 생성 및 수정 시간을 자동으로 관리해주는 Auditing 기능이 있다. 나도 이기능을 사용하기 위해 아래와 같은 코드를 작성해둔 상태였다.

이렇게 @EnableJpaAuditing 어노테이션을 테스트들의 가장 기본이 되는 Application 클래스에 등록을 해두면 모든 테스트들이 항상 JPA 관련 Bean들을 필요로 하는 상태가 된다.

즉, @EnableJpaAuditing을 사용하기 위해서는 최소 하나의 @Entity 클래스가 필요하다는 뜻이다.

하지만, 테스트 코드에서는 엔티티를 따로 생성하지 않았기 때문에 발생한 에러였다.

그럼 본 코드에서는 Auditing을 사용하고 테스트 코드에서는 이 설정을 제거하려면 어떻게 하면 될까?

생각하면 간단했다. 나는 테스트 코드에서 @WebMvcTest를 하고 있었고, 이것이 @SpringbootApplication을 스캔하는 데 @EnableJpaAuditing이 함께 있다 보니 같이 스캔되기 때문에 발생하는 것이니 둘을 분리하면 된다고 생각했다.

@WebMvcTest는 일반적인 @Configuration은 스캔하지 않기 때문이다.

테스트 코드를 작성하면서 에러들을 많이 만났다.

하지만 이 에러들을 해결하면서 스프링부트가 편리하지만 어떻게 동작하는 지에 대해

( 예를 들어, 무엇을 자동으로 스캔하고 어떠한 어노테이션을 쓰면 무엇을 필수 구현 해야 하는지..? )

더 생각하게 되고 이해하는 과정을 거치는 것 같다.

++++

더 찾아보니까 위에 방법으로 해도 되지만 @MockBean으로 테스트 클래스에 JpaMetaModelMappingContext를 추가 하는 방법도 있다.

위에 예시 코드처럼 말이다.

하지만, 테스트를 추가할 때 마다 저런 설정을 해주는 것은 좋지 않은 방법이다. 그래서 나는 위에서 말한 첫 번째 방법으로 적용했다.

DefaultSerializer requires a Serializable payload but received an object of type [...]

무루뭉 — Mon, 6 Sep 2021 12:27:25 +0900

스프링 시큐리티를 써서 소셜 로그인을 적용하다가 만난 에러이다...

우선 에러 로그를 그대로 번역하자면 아래와 같다.

"DefaultSerializer에는 직렬화 가능한 페이로드가 필요하지만 [...] 유형의 개체를 수신했습니다"

우선 직렬화 가능한 페이로드가 필요한 것 같다.

[...]에 내가 사용한 dto 폴더를 나타내 주는데 그 dto 파일에서 직렬화를 적용시켜주어야 한다는 의미 같다.

그래서 직렬화에 대해서 또 어떻게 적용할 지 알아보았다.

직렬화란?

■ 자바에서 직렬화란 자바 시스템 내부에서 사용되는 객체 또는 데이터를 외부의 자바 시스템에서도 사용할 수 있도록 바이트 형태로 데이터 변환하는 기술과 바이트로 변환된 데이터를 다시 객체로 변환하는 기술(역직렬화)를 아우른다.

■ 시스템적으로는, JVM의 메모리에 상주되어 있는 객체 데이터를 바이트 형태로 변환하는 기술과 직렬화된 바이트 형태의 데이터를 객체로 변환해서 JVM으로 상주시키는 형태를 이야기 한다.

어떻게 사용할까?

java.io.Serializable 인터페이스를 상속받고, java.io.ObjectOutputStream 객체를 이용한다.

왜 사용할까?

- 직접 데이터를 문자열 형태로 확인 가능한 직렬화 방법

- api나 데이터 변환 시 많이 사용

- 다량의 데이터 직렬화시 csv, json 등으로 많이 사용한다. csv, json이 자바 직렬화는 아니다.

참조 블로그 : https://velog.io/@redcarrot01/TroubleShooting-springboot-DefaultSerializer-requires-a-Serializable-payload, https://techblog.woowahan.com/2551/

이해를 편하게 하기 위해 User 클래스가 있다고 보자.

우선 User 클래스가 엔티티일 경우 User 클래스에 직렬화 코드를 넣으면 안된다.

이유가 뭘까?

- 엔티티 클래스에는 언제 다른 엔티티와 관계가 형성될 지 모른다.

예를 들어, @ManyToMany 등 자식 엔티티를 가지고 있다고 보면, 직렬화 대상에 자식들까지 포함되어야 하니 성능 이슈, 부수 효과가 발생할 확률이 높다.

그렇다면 어떻게 할까?

- 직렬화 기능을 가지 Dto 하나를 추가로 만드는 것이 운영 및 유지보수하는 데 편하다.

위 정보들을 토대로

user 클래스(엔티티)는 냅두고 userDto(예시) 파일을 하나 생성해서 클래스에 implements Serializable을 붙여서 해결했다.

기본 자바 라이브러리만 사용해도 직렬화와 역직렬화를 할 수 있지만, 그에 따른 장단점이 존재하는 듯 보였다.

+ 더 알아보다가 직렬화의 필요성에 관련한 블로그 남긴다

https://hub1234.tistory.com/26

@Bean, @Component, @Configuration

무루뭉 — Tue, 31 Aug 2021 15:26:06 +0900

이 세가지의 어노테이션 뭔지 너무 헷갈려~~ 알아보자잇!

Bean

Bean은 Spring IoC Container가 관리하는 자바 객체, Spring Bean Container에 존재하는 객체를 말한다.

Bean 컨테이너는 DI를 통해 Bean 객체를 사용할 수 있도록 해주는 역할을 한다.

스프링에서 Bean은 보통 Singleton으로 존재한다.

* Singleton : 어떠한 클래스가 최초로 한번만 메모리에 할당되고 그 메모리에 객체를 만들어 사용하는 패턴

또한 스프링의 DI Container에 의해 관리되는 POJO를 Bean이라고 부르고 이러한 Bean들이 스프링을 구성하는 핵심 요소이다.

스프링 빈 정리해보자잇~!

● Spring IoC 컨테이너(또는 DI 컨테이너)에 의해 생성 및 관리된다.

● POJO로써 Spring 애플리케이션을 구성하는 핵심 객체이다.

Spring Bean 구성요소를 알아보자

class: Bean으로 등록할 Java 클래스
constructor-arg: Bean 생성 시 생성자에 전달할 파라미터
scope : Bean을 생성하기 위한 방법
id : Bean 고유 식별자
property : Bean 생성 시 setter에 전달할 인수

다른 Spring Bean 어노테이션 종류

개발을 하다보면 상당히 많은 클래스를 Bean으로 등록하게 된다. 옛날에는 이런것들을 모두 xml을 통해 Bean으로 등록하면서 상당히 시간이 소요되는 번거로운 작업을 했었다. 이러한 번거로움을 덜기 위해서 스프링에서는 어노테이션을 활용해 Bean을 등록해서 사용하는 방법을 제공하고 있다.

이제 스프링 Bean을 등록하는 방법에서 포스팅 제목의 세 가지 어노테이션을 사용한다.

@Bean 어노테이션과 @Configuration 어노테이션

Bean으로 등록하고자 한다면 @Bean 어노테이션을 활용하자.

import com.example.HeaderFilter; 
import com.example.SessionInterceptor; 
import org.springframework.boot.web.servlet.FilterRegistrationBean; 
import org.springframework.context.annotation.Bean; 
import org.springframework.context.annotation.Configuration; 
import org.springframework.core.Ordered; 
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder; 
import org.springframework.web.servlet.config.annotation.InterceptorRegistry; 
import org.springframework.web.servlet.config.annotation.ResourceHandlerRegistry; 
import org.springframework.web.servlet.config.annotation.ViewControllerRegistry; 
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; 
import org.springframework.web.servlet.resource.ResourceUrlEncodingFilter; 
import java.util.Properties; 

// 1개 이상 Bean을 등록하고 있음을 명시하는 어노테이션 
@Configuration 
public class WebMvcConfig implements WebMvcConfigurer {
... 

@Bean 
public ResourceUrlEncodingFilter resourceUrlEncodingFilter() { 
return new ResourceUrlEncodingFilter(); 
 } 

@Bean 
public HeaderFilter createHeaderFilter() { 
return new HeaderFilter(); 
 } 

@Bean 
public FilterRegistrationBean<HeaderFilter> getFilterRegistrationBean() { 
FilterRegistrationBean<HeaderFilter> registrationBean = new FilterRegistrationBean<>(createHeaderFilter()); 
registrationBean.setOrder(Integer.MIN_VALUE); 
registrationBean.addUrlPatterns("/*"); 
return registrationBean; 
 } 

@Bean 
public BCryptPasswordEncoder createBCryptPasswordEncoder(){ 
return new BCryptPasswordEncoder(); 
 }  
}

위 코드에서 볼 수 있듯이 많은 클래스들이 Bean으로 등록된다.

이러한 클래스들을 xml에 일일이 적어서 등록하는 것은 생산력에 큰 영향을 미친다.

그니까 편리하고 빠른 어노테이션을 통해 Bean을 등록하자!

하지만, 임의의 클래스를 만들어서 @Bean 어노테이션을 붙인다고 되는 것이 아니다. @Bean을 사용하는 클래스에는 반드시 @Configuration 어노테이션을 활용해서 해당 클래스에서 Bean을 등록하고자 함을 명시해주어야 한다.

위의 예제도 클래스 위에 @Configuration 어노테이션을 명시해서 해당 클래스에서 1개 이상의 Bean을 생성하고 있음을 명시하고 있다. 그렇기 때문에 @Bean 어노테이션을 사용하는 클래스의 경우 반드시 @Configuration과 함께 사용해야 한다.

추가로 @Configuration 없이도 @Bean만 사용해서 스프링 빈으로 등록이 가능하다. 대신에 메서드 호출을 통해 객체를 생성할 때 싱글톤을 보장하지는 않는다. 그렇기 때문에 스프링 설정 정보를 위해서는 반드시 @Configuration을 사용해주어야 한다.

그리고, 빈의 설정을 담당하는 @Configuration 어노테이션도 내부적으로 @Component를 가지고 있어 @Configuration이 붙은 클래스도 스프링의 빈으로 등록이 되는 것 역시 알아두면 좋다.

@Component 어노테이션

개발자가 직접 개발한 클래스를 Bean으로 등록하고자 하는 경우에는 @Component 어노테이션을 활용한다. 예를 들어, 파일 업로드 등을 처리하기 위해 직접 개발한 코드를 Bean으로 등록하고자 한다면 @Component 어노테이션을 사용하면 된다.

@Bean으로 등록할 수도 있지만 직접 개발한 클래스의 단위를 빈에 등록할 때는 @Component를 통해 해당 클래스를 빈으로 등록함을 노출하는 것이 좋다.

왜냐하면, @Component만 보면 해당 빈이 등록되도록 잘 설정되었는 지를 찾이 않고 확인할 수 있기 때문이다. 반면에 @Bean을 사용하면 해당 메서드를 찾는 번거로움이 생길 수 있다.

추가로 @Component를 이용한다면 메인 또는 앱 클래스에서 @ComponentScan으로 컴포넌트를 찾는 탐색 범위를 지정해주어야 한다. 하지만 스프링 부트를 쓴다면 @SpringBootConfiguration 하위에 포함되어 있어 별도의 설정이 필요 없다.

생각

그냥 신경안쓰고 쓰던 @SpringBootApplication이 사실 @ComponentScan, @Component를 상속받고 있었다.

스프링에서는 신경써서 설정을 해야 하는 번거로움이 있었지만 스프링 부트는 신경 안쓰고 어노테이션을 쓸 수 있어서

편리했었던 것이다. 스프링부트가 편리하지만 그냥 사용하는 것보다 스프링에서 무엇이 편리해졌고 무엇을 내재하고

있는 지 더 알아봐야 겠다.

Service와 ServiceImpl

무루뭉 — Tue, 31 Aug 2021 13:31:49 +0900

다른 프로젝트들을 구경하면 Service 인터페이스와 ServiceImpl 클래스(구현부)를 따로 두어 코딩을 진행하는 경우를 많이 봤다.

왜 굳이 나눌까 궁금해서 서칭을 하고 기록을 남겨볼까 한다.

우선 두 가지로 왜 나누어놓는 지를 알기 위해서는 OOP(객체 지향 프로그래밍)에 대한 이해가 필요하다.

OOP를 완전히 이해하는 것은 어려운 일이지만, 짧게 말하면 '객체'들의 모임이다.

OOP는 프로그램을 유연하고 변경이 용이하게 만들기 때문에 SW개발에 많이 사용된다.

Service와 SeviceImpl은 다형성과 연관이 있다.

다형성이란 하나의 객체가 여러가지 타입을 가질 수 있는 것을 의미하는데, 보통 부모 클래스를 자식이 상속받아 기능을 확장하거나 변경하는 방식으로 사용을 많이 한다.

즉, Service를 부모로 인터페이스로 만들고, 자식으로는 ServiceImpl 클래스가 부모를 상속받아 구현하게 된다.

~Impl이 붙는 것은 개발자들이 따르는 naming convention이다.

그래서 대체 왜 사용할까?

인터페이스는 객체의 사용 방법을 정의한 타입으로도 볼 수 있다. 객체의 교환성을 높여주기 때문에 다형성을 구현하는 데 매우 중요하다. 즉, 개발 코드를 수정하지 않고 사용하는 객체를 변경할 수 있도록 해준다.

클래스 간의 의존 관계를 줄여 결합도를 낮춰주는데도 좋은 방식이다.

느슨한 결합을 뜻하는데 loose coupling이라고 한다. 의존 관계를 최소화해서 기능 변화에도 최소한의 수정으로 개발할 수 있다. 모듈화를 통해 어디서든 사용할 수 있도록 재사용성이 좋다.

스프링의 IOC/DI 기능을 이용해 빈 관리 기능이 사용이 가능하다고 하는데 이 부분은 조금 더 공부해봐야 할 것 같다.

그래서 이런 구조를 그냥 따르면 될까?

다른 블로그를 많이 찾아봤지만, 물론 부정적인 시각도 있었다.

내가 궁금했던 것이 바로 Service 인터페이스와 ServiceImpl이 1:1로 매핑이 된다면 굳이 필요할까? 였다

괜히 하나의 인터페이스가 더 늘어나는 셈인 것 같았다. 그래서 1:1이라면 굳이 인터페이스를 둘 필요가 없다고 생각한다.

단, 1:N 구조에서는 사용하는 것이 좋을 것 같다.

하나의 작업으로 인해 N(N>=2)개 이상의 작업이 수행되거나, 추가될 예정인 경우에는 인터페이스를 따로 두어 관리하는 것이 좋을 것 같다. 추가될 예정인 경우가 애매하다고 보지만 그만큼 자신이 수행중인 업무를 제대로 이해하는 능력 또한 중요한 것 같다.

생각

단순히 남들도 이렇게 하니까~ 라는 생각보다 왜 쓰게 되었는 지 왜 이렇게 많이들 쓰는 지를 이해하고 부정적인 시각도 많이 보면서 사용법을 제대로 익혀가는 것이 좋은 것 같다.