RSS Feed of hoon.blog

[QueryDSL] QueryDSL 사용 시 NPE가 발생했을 때 해결하기

Sat, 20 Apr 2024 00:00:00 GMT

[들어가며]

프로젝트를 진행하면서 동적 쿼리를 작성할 일이 많아 QueryDSL을 도입하면서 발생했던 NullPointerException 오류를 해결하면서 배웠던 내용을 정리하고자 작성하게 되었다.

java.lang.NullPointerException: Cannot read field "id" because "sidepair.domain.project.QProjectMember.projectMember.project.feedContent.feed" is null

[도메인 구조]

하나의 피드 본문(FeedContent) 정보에 대해서 하나의 프로젝트(Project)가 생성될 수 있고, 하나의 프로젝트에 대해서 여러 개의 프로젝트 대기 멤버(ProjectPendingMembers)가 생길 수 있다는 것이다.

위 문제를 발견하게 된 테스트 코드는 아래와 같다.

@Test
void 카테고리_조건_없이_주어진_피드_이전의_데이터를_참가중인_인원이_많은순으로_조회한다() {
    ...

    final Feed serviceFeed1 = 노드_정보를_포함한_피드를_생성한다("서비스 피드", creator, serviceCategory);
    final Feed serviceFeed2 = 노드_정보를_포함한_피드를_생성한다("서비스 피드2", creator, serviceCategory);
    final Feed commerceFeed = 노드_정보를_포함한_피드를_생성한다("이커머스 피드", creator, commerceCategory);
  
    final Project serviceFeed1Project = 프로젝트를_생성한다(serviceFeed1.getContents().getValues().get(0), creator);
    final Project serviceFeed2Project = 프로젝트를_생성한다(serviceFeed2.getContents().getValues().get(0), creator);
    final Project commerceFeedProject = 프로젝트를_생성한다(commerceFeed.getContents().getValues().get(0), creator);

    // serviceFeed1 : 참가인원 0명
    // serviceFeed2 : 참가인원 1명
    final List<ProjectMember> serviceFeed2ProjectMembers = List.of(
            new ProjectMember(ProjectRole.LEADER, LocalDateTime.now(), serviceFeed2Project, creator));
    projectMemberRepository.saveAll(serviceFeed2ProjectMembers);

    // commerceFeed : 참가인원 2명
    final List<ProjectMember> commerceFeedProjectMembers = List.of(
            new ProjectMember(ProjectRole.LEADER, LocalDateTime.now(), commerceFeedProject, creator),
            new ProjectMember(ProjectRole.FOLLOWER, LocalDateTime.now(), commerceFeedProject, follower));
    projectMemberRepository.saveAll(commerceFeedProjectMembers);

    final FeedCategory category = null;
    final FeedOrderType orderType = FeedOrderType.PARTICIPANT_COUNT;

    // when
    final List<Feed> firstFeedRequest = feedRepository.findFeedsByCategory(category, orderType,
            null, 2);
    final List<Feed> secondFeedRequest = feedRepository.findFeedsByCategory(category, orderType,
            serviceFeed2.getId(), 10);

    ...
}

코드가 상당히 복잡하지만 별거없다. 그냥 피드를 생성하고, 피드에 대한 참가인원을 추가하는 코드이다. 해당 코드는 아래와 같이 구현이 되어 있다.

@Override
public List<Feed> findFeedsByCategory(final FeedCategory category, final FeedOrderType orderType,
                                            final Long lastId, final int pageSize) {

    return selectFrom(feed)
            ...
            .where(
                    lessThanLastId(lastId, orderType)
           	)
            .fetch();
}

private BooleanExpression lessThanLastId(final Long lastId, final FeedOrderType orderType) {
    ...
    final NumberPath<Long> projectMemberFeedId = projectMember.project.feedContent.feed.id;
    return participantCountCond(projectMemberFeedId.eq(feed.id))
            .lt(participantCountCond(projectMemberFeedId.eq(lastId)));
}

인자로 받은 lastId (현재는 피드의 PK 값이 들어오고 있다.)에 해당하는 피드의 참여자 수보다 더 적은 참여자 수를 구하는 피드를 구하는 쿼리이다.

[NPE가 발생할 지점을 찾아보기]

처음에 이 오류를 접했을 때는 아래와 같은 예외 메시지 중에서 단순하게 이 부분에만 집중을 했었다. sidepair.domain.project.QProjectMember.projectMember.project.feedContent.feed is null

그래서 projectMember를 저장한 후에 피드에 대한 정보가 제대로 저장이 안 되어 있나 싶어서 findAll로 찾아보았다.

final List<ProjectMember> projectMembers = projectMemberRepository.findAll();
assertThat(projectMembers.get(0).getProject().getFeedContent().getFeed().getId()).isNotNull();
assertThat(projectMembers.get(1).getProject().getFeedContent().getFeed().getId()).isNotNull();
assertThat(projectMembers.get(2).getProject().getFeedContent().getFeed().getId()).isNotNull();

NPE니까 당연히 feed의 id 값이 Null이 되어서 테스트가 실패하겠지?라고 생각하였다.

하지만 테스트가 놀랍게도 성공한 것을 볼 수 있었다. 그래서 값 자체는 제대로 들어갔겠구나 싶어서 다른 방향을 탐색해보았다.

[QueryDSL의 객체 그래프]

final NumberPath<Long> projectMemberFeedId = projectMember.project.feedContent.feed.id;

문제가 발생했던 라인은 정확하게 위 라인이었다. 어떠한 값이 들어가고 말고의 문제를 떠나서, 객체 그래프를 탐색할 때 뭔가 문제가 있을 것 같다는 생각이 들었다. 그래서 열심히 구글링을 해본 결과, 아래와 같은 글을 발견하게 되었다.

NullPointerException on QueryDSL where clause

그리고 답변 내용에서 말해 주신 공식 문서를 한 번 읽어보았다.

By default Querydsl initializes only reference properties of the first two levels. In cases where longer initialization paths are required, these have to be annotated in the domain types via com.mysema.query.annotations.QueryInit annotations. QueryInit is used on properties where deep initializations are needed.

기본적으로 QueryDSL은 초기 2단계의 레벨에 있는 프로퍼티만 초기화하게 된다. 만약 그 이상의 path를 초기화하고 싶다면 @QueryInit 어노테이션을 통해서 직접 지정해줄 수 있다. 한 번 우리의 문제 상황에 적용해보자.

@QueryInit

@QueryInit의 경우 기본적으로 @Entity 어노테이션이 붙어 있는 클래스의 필드에 대해서 적용이 가능하다. 내부 인자로 초기화하고 싶은 path를 지정해줄 수 있으며, *을 통해 와일드카드를 통해서도 지정이 가능하다.

먼저, @QueryInit을 지정하지 않았을 때의 큐파일을 디버깅해보았다. (QProject)

QProject -> QFeedContents -> QFeed(null)

확인해보면 Project에서 QFeedContent까지의 값은 잘 가져오지만, QFeed에 대해서는 정의가 되어 있지 않은 것을 볼 수 있다. 여기서 QFeed 값이 null로 정의되었기 때문에 탐색이 불가능했던 것이다.

public class ProjectMember {

   ...

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "project_id", nullable = false)
    @QueryInit(value = {"feedContent.feed"})
    protected Project project;
}

그래서, 위와 같이 ProjectMember 엔티티가 Project 엔티티를 정의한 필드에 @QueryInit을 정의해주었다. 이렇게 되면 QProject이 초기화될 때 FeedContent와 Feed 정보까지 함께 초기화가 가능할 것이다. 참고로, 내부 value의 값은 project 엔티티가 참조하고 있는 실제 필드명으로 작성해야 한다.

이런 식으로 잘못된 필드 값을 입력하게 되면 컴파일 타임 때 오류가 발생한다.

project가 실제로 의존하고 있는 필드명으로 작성해야 한다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "project_id", nullable = false)
@QueryInit(value = {"feedContent.*"})
protected Project project;

추가적으로, 이렇게 와일드카드로 명시해도 잘 동작한다.

QProject -> QFeedContents -> QFeed

수정 후에 다시 디버깅을 진행해보면 이번에는 feed에 대한 정보도 잘 채워진 것을 확인할 수 있다

테스트도 정상적으로 통과한다.

+) 추가적으로, 이렇게 @QueryInit을 특정 필드에 적용하고 나면 기존에 잘 돌아가던 쿼리들이 안 돌아갈 수도 있다. 나 같은 경우에는 비슷한 다른 쿼리에서 오류가 발생했었는데, 2단계 레벨에 있는 필드에 대해서 NPE가 발생했었다.

비슷한 오류지만 projectMember -> member -> email (VO여서 단계에 반영하지 않는 것 같다. 공식문서에서 명시 되어 있듯이 3단계는 반영되지 않는것 같다.)에 대해서 오류가 발생한 것이었다. @QueryInit을 달지 않았을 때는 3단계까지 잘 갔었는데, 명시적으로 어노테이션을 지정해주니까 이렇게 된 것 같다.

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "project_id", nullable = false)
@QueryInit(value = {"feedContent.feed"})
protected Project project;

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "member_id", nullable = false)
@QueryInit(value = {"email"})
protected Member member;

그래서 member 필드에 대해서는 이렇게 email에 대해서도 정의를 해주었다.

[정리]

@QueryInit 어노테이션을 직접 사용해보니 더 자세히 알게 된 것 같다. 사실 해결 방법은 아주 간단했는데 처음 마주한 오류여서 해결하는 데 시간이 오래 걸렸다.

[Spring] @SpringBootTest에서 지연 로딩 사용하기 - no Session 방지하기

Mon, 15 Apr 2024 00:00:00 GMT

[들어가며]

이번 프로젝트에서 E2E 테스트 환경을 구축하기 위해서 @SpringBootTest를 통해 테스트 코드를 작성하고 있는데, 아래와 같은 오류를 만나게 되었다.

failed to lazily initialize a collection of role: sidepair.domain.feed.FeedContent.nodes.values: could not initialize proxy - no Session

상황은 아래와 같다. (추후 코드로 더 잘 살펴볼 예정이다.) A라는 생성 API와 B라는 조회 API가 있을 때, 팀 내에서 기능을 세분화한 다음 각자 개발을 진행하다 보니 B를 개발하는 시점에 A라는 API가 없어, 통합 테스트 때 repository를 의존하여 직접 save를 하게 되었다.

하지만, save 후 반환된 엔티티의 객체를 조회할 때 지연 로딩을 사용하다 보니 트랜잭션이 필요하게 되었는데, 테스트 메서드에서는 repository를 호출하는 시점에서만 트랜잭션이 걸리고, 해당 객체를 사용하는 시점에는 트랜잭션이 없어 영속성 컨텍스트가 없는 상태가 된 것이다. 그러다 보니 세션 정보가 없어 지연 로딩을 사용할 수 없다는 오류가 발생하게 되었다.

당시 이 오류를 처음 접했을 때는 테스트 메서드의 트랜잭션이 없어서 발생한 문제니까, A api가 merge 된 이후에 작업하셔도 충분할 것 같았지만, 곰곰이 생각해보니 이게 과연 옳은 해답인가? 라는 생각이 들었다.

앞으로도 이런 테스트 상황이 생길 텐데, 그럴 때마다 이럴 수는 없기 때문에 이번에 공부하면서 새로운 방법을 적용하게 되었다.

[엔티티 소개]

현 문제 상황에서 필요한 간단한 엔티티 다이어그램이다. 피드 (Feed)는 피드 내용들(FeedContents)에 대해서 1:N 관계를 맺고 있으며, 각 피드 내용(FeedContent)은 피드 노드들(FeedNodes)에 대해서 또 다시 1:N 관계를 가지고 있다.

이를 코드로 봤을 때는 대략적으로 아래와 같이 구성된다.

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
public class Feed extends BaseCreatedTimeEntity {
     ...

    @Embedded
    private FeedContents contents = new FeedContents();
    
    ...
}

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class FeedContent extends BaseUpdatedTimeEntity {

    ...

    @Embedded
    private final FeedNodes nodes = new FeedNodes();

   ...

    public FeedNodes getNodes() {
        return nodes;
    }
}

@Embeddable
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class FeedNodes {

    @OneToMany(fetch = FetchType.LAZY, cascade = {CascadeType.PERSIST, CascadeType.MERGE}, mappedBy = "feedContent")
    private final List<FeedNode> values = new ArrayList<>();

    ...
    
    public List<FeedNode> getValues() {
        return new ArrayList<>(values);
    }
}

여기서 봐야하는 점은, 피드(Feed) - 피드 본문(FeedContent)과 피드 본문(FeedContent)과 피드 노드(FeedNode) 모두가 LAZY 전략을 사용하고 있다는 것이다.

[문제 상황]

아래의 테스트 코드는 @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)을 통해서 통합 테스트 환경을 구축한 상태에서 진행된다.

@Test
void 테스트() throws JsonProcessingException {
    ...

    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));

    final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
    final List<FeedNode> 피드_노드들 = 피드_본문.getNodes().getValues(); // Here!
    ...
}

private FeedContent 피드로부터_본문을_가져온다(final Long 피드_아이디) {
    final Feed 피드 = feedRepository.findById(피드_아이디).get();
    return feedContentRepository.findFirstByFeedOrderByCreatedAtDesc(피드).get();
}

코드의 첫 라인을 보면 피드를_생성한다(); 메서드를 통해 피드 아이디를 반환받고 있다. 여기서는 실제 API call을 진행하고 있기 때문에 실제로 생성된 피드의 아이디만을 반환받는다. 반환받은 아이디를 바탕으로 피드 엔티티를 얻어오기 위해 findById()를 통해 피드 엔티티를 조회해오며, 여기서 가장 최근에 생성된 피드 본문 엔티티를 가져오기 위해 한 번 더 조회를 진행한다.

물론, 피드 엔티티로부터 가장 최근의 피드 본문을 받아오는 방법도 있겠지만, 현 프로덕션 코드에서는 해당 부분이 필요하지 않았고, 만약 그렇게 코드를 작성했다면 본문을 가져오는 과정에서부터 오류가 발생했을 것이다. 또한, 현재 작성한 부분은 생성 API가 아직 만들어지지 않은 상태로 조회 API를 만들다 보니 생성을 위한 엔티티를 만드려고 '피드 노드들' 엔티티를 조회해온 코드여서 추후 생성 API가 만들어진다면 제거될 부분이긴 하다

cf. findFirst~() 메서드에서는 트랜잭션이 어딨을까?

public interface FeedContentRepository extends JpaRepository<FeedContent, Long> {

    Optional<FeedContent> findFirstByFeedOrderByCreatedAtDesc(final Feed feed);
}

feedContentRepository의 경우 위와 같이 JpaRepository를 상속받고 있다.

이때, JpaRepository 인터페이스의 구현체인 SimpleJpaRepository 클래스를 가면 위와 같이 @Transactional이 붙어 있는 것을 볼 수 있다. 그렇기 때문에 해당 메서드가 호출하는 시점에 대해서만 트랜잭션이 걸려있게 되는 것이다.

기본적으로 스프링에서 영속성 컨텍스트는 트랜잭션과 생명주기가 동일하기 때문에, feedContentRepository로부터 조회해온 FeedContent는 트랜잭션이 종료되면서 영속성 컨텍스트의 관리 범위에서도 함께 벗어나게 된다. 현재 피드 본문 엔티티는 준영속 상태가 되었음을 기억하자.

final List<FeedNode> 피드_노드들 = 피드_본문.getNodes().getValues(); // Here!

다시 돌아와서, here! 이라고 특정된 부분을 보자. 해당 부분이 오류가 발생하는 지점이다. 피드 본문으로부터 노드에 대한 정보를 가져오려고 할 때 오류가 발생한 것이다.

public List<FeedNode> getValues() {
    return new ArrayList<>(values);
}

노드에서 getValues() 메서드를 호출하면 values()에 대한 접근이 일어나게 되는데, 이때 아래와 같은 일들이 발생한다.

read() 라는 메서드를 따라 들어가다 보면, 어떠한 초기화 작업이 처음에 발생하는 것을 볼 수 있다.

그리고, 지연 로딩 작업을 세션으로부터 컬렉션 정보를 초기화하는 것을 볼 수 있다. 상위의 주석을 잘 읽어보면, 초기화가 불가능할 때 LazyInitializationException이 발생함을 볼 수 있다.

그리고, 해당 메서드를 타고 들어가면 session 정보가 없을 때 외부의 트랜잭션을 사용할 수 있는지 판단하는데, 사용 불가능하기 때문에 (allowLoadOutsideTransaction=false) 하단의 else 구문으로 제어가 내려가게 되어 오류가 발생하게 된다.

참고로, allowLoadOutsideTransaction의 경우 제일 처음 세션 정보를 세팅해줄 때 위의 메서드에서 적용된다. 세션 정보로부터 지연 로딩임에도 트랜잭션을 사용할 수 있는지 정보를 받아오는 것 같다.

그렇다면 트랜잭션 정보가 있으면 되는 게 아닐까? 한 번 천천히 해결해나가보자.

그냥 @Transactional을 붙이면 되지 않나?

@Test
@Transactional // 트랜잭션!
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));

    final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
    final List<FeedNode> 피드_노드들 = 피드_본문.getNodes().getValues(); 
    ...
}

 private FeedCategory 피드_카테고리를_저장한다(final String 카테고리_이름) {
    final FeedCategory 피드_카테고리 = new FeedCategory(카테고리_이름);
    return feedCategoryRepository.save(피드_카테고리);
}

트랜잭션이 없어서 생긴 문제라면, @Transactional을 붙이면 된다고 생각할 수 있다. 여기서 아까 예제와 다르게 피드에 대한 카테고리 생성 메서드가 추가된 것을 볼 수 있는데, 오류가 발생한 포인트이기 때문에 넣어두었다. 카테고리의 경우 생성하는 API가 없기 때문에 (나중에 admin 기능을 추가하면 넣을 예정이었다.) 위와 같이 직접 save를 해준다.

하지만, 정말 뜬금없이 NPE가 발생하는 것을 볼 수 있다. 이는, 응답값이 제대로 반환되지 않으면서 response header 값이 제대로 내려오지 않았기 때문이다.

실제로 해당 로그의 상단으로 올라가보면, 위와 같이 카테고리에 대한 Exception이 발생한 것을 볼 수 있다.

이는, 피드 생성 API가 호출되면서 create 하는 과정에 request body 값으로 받은 피드 카테고리 아이디에 대한 유효성을 검증하게 되고, 해당 로직에서 카테고리 정보가 존재하지 않아 발생한 오류이다.

분명 위에서 피드_카테고리를_저장한다() 메서드를 통해 저장을 했는데, 이게 어떻게 된 일일까? 이는, @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOMPORT) 때문이다. 이전에 테스트 컨텍스트에 대한 블로그 글을 읽은 적이 있는데, 그때 randomport 옵션에 대해 이와 같이 커멘트를 봤었다.

만약 @SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)을 사용하게 된다면 실제 웹 환경이 구성 되기 때문에 다른 컨텍스트 정보를 지정하게 되면 다른 웹 서버가 띄워지게 된다.

random_port 옵션을 지정하게 되면 별개의 스레드에서 컨테이너가 실행된다는 것이다. = 즉, 프로덕션 코드에서 작성한 메서드의 스레드와 @SpringBootTest의 메서드의 스레드가 다르다는 의미이다.

기본적으로 @Transactional이 붙게 되면 작업 스레드는 커넥션 풀에서 Connection 객체를 가져와서 사용하게 되는데, 스레드가 달라지게 되면 사용하게 되는 Connection이 달라지게 된다. 즉, 트랜잭션이 아예 달라지게 되는 것이다. 그렇기 때문에 프로덕션 코드가 실행되는 피드 생성 API의 스레드 입장으로서는 테스트 메서드인 피드카테고리를생성한다() 스레드가 하는 일을 인식하지 못하기 때문에 카테고리에 대한 정보를 받아올 수 없는 것이다.

여기서 한 가지 실수를 했는데, 콘솔상으로는 쿼리가 발생하길래 계속 insert가 된다고 생각했었다. (IDENTITY 전략으로 인해)

하지만, 실제로 DB에 가서 확인해보니 결과가 저장되지 않았었고, 아마 쿼리만 발생한 것 같다고 추측된다. (트랜잭션 시작 후 커밋이 되지 않은 상태라고 보는 게 더 정확할 것 같다.)

@Transactional을 제거하면 위와 같이 레코드가 저장된다. (트랜잭션이 없으니 바로 DB에 저장)

그러면 이 문제를 어떻게 해결해야 할까? RANDOM_PORT를 사용하지 않게 되면 E2E 테스트의 의미가 없고, API call로 대체할 수 없는 상황이다.

지연 로딩이 필요한 시점에서만 트랜잭션을 생성하기 - 메서드 분리하기

근본적인 문제는, 지연 로딩을 하는 시점에 트랜잭션이 존재하지 않아 조회를 해올 수 없었던 것이다. 그렇다면 조회하는 시점에 새로운 트랜잭션을 생성해주는 건은 어떨까?

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final List<FeedNode> 피드_노드들 = 피드_노드들을_반환한다(액세스_토큰, 카테고리, 노드1, 노드2);
    
    ...
}


@Transactional // 트랜잭션!
public List<FeedNode> 피드_노드들을_반환한다(final String 액세스_토큰, final FeedCategory 카테고리, final FeedNodeSaveRequest 노드1,
                                        final FeedNodeSaveRequest 노드2) {
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));

    final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
    return 피드_본문.getNodes().getValues();
}

하지만, 위 코드는 동작하지 않는다. 이는 기본적으로 @Transactional은 Spring AOP를 사용하여 구현되기 때문이다.

이때 크게 2가지의 특징이 존재한다.

타겟 클래스를 상속하여 프록시 객체를 생성하기 때문에 상속 자체가 불가능한 private 메서드에 대해서는 적용 불가
동일한 클래스의 내부 메서드를 호출하게 되면 프록시를 호출하지 않고 대상 객체를 직접 호출하게 되어 적용 불가

위 코드에서는 2번의 경우, 내부 메서드를 사용했기 때문에 트랜잭션을 적용할 수 없는 것이다. 그렇다면, 내부 메서드 대신에 외부 클래스를 활용하면 되지 않을까?

지연 로딩이 필요한 시점에서만 트랜잭션을 생성하기 - 클래스 분리하기

@Component
@TestConstructor(autowireMode = AutowireMode.ALL)
public class FeedTestHelper {

    private final FeedRepository feedRepository;
    private final FeedContentRepository feedContentRepository;

    public FeedTestHelper(final FeedRepository feedRepository,
                             final FeedContentRepository feedContentRepository) {
        this.feedRepository = feedRepository;
        this.feedContentRepository = feedContentRepository;
    }

    @Transactional(readOnly = true)
    public List<FeedNode> 피드_노드들을_조회한다(final Long 피드_아이디) {
        final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
        return 피드_본문.getNodes().getValues();
    }

    private FeedContent 피드로부터_본문을_가져온다(final Long 피드_아이디) {
        final Feed 피드 = feedRepository.findById(피드_아이디).get();
        return feedContentRepository.findFirstByFeedOrderByCreatedAtDesc(피드).get();
    }
}

피드 노드를 조회하기 위한 별도의 Helper 클래스를 생성해준다. 피드_본문 엔티티가 detached 상태가 되지 않도록 조회를 해오는 시점의 메서드부터 helper 클래스에 두었으며, 본문으로부터 노드 정보를 지연로딩을 통해 가져와서 반환하도록 만들었다.

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));
    
    // Here!
    final List<FeedNode> 피드_노드들 = feedTestHelper.피드_노드들을_조회한다(피드_아이디);
    ...
}

그리고 기존의 테스트 코드에서 helper 클래스를 통해서 노드를 조회해왔다.

하지만, 위 방법은 매우 찝찝하다. 지연로딩이 필요한 코드마다 이렇게 테스트 클래스로 분리해야 하기 때문이다. 만약 테스트하는 케이스가 정말 많아진다면 그럴 때마다 helper 클래스에 메스드가 엄청나게 늘어나게 될 것이다. 이는 전혀 개발자답지 못한 해결 방법이기 때문에 다른 방법을 모색할 필요가 있다.

지연 로딩이 필요한 시점에서만 트랜잭션을 생성하기 - 함수형 인터페이스 활용하기

필요할 때마다 helper 클래스의 메서드로 분리하는 게 아니라, 트랜잭션이 필요한 로직에 대해서만 외부 클래스에서 실행되도록 만들 수는 없을까? 즉, 메서드를 인자로 넘겨서 어떠한 곳에서 처리하고 싶은 것이다.

자바에서는 메서드를 파라미터로 전달하기 위해서 람다식을 활용할 수 있다. 우리는 인자로 넘긴 값으로 List를 받아야 하기 때문에 T를 반환하는 시그니처를 가진 함수형 인터페이스를 하나 설정할 수 있다.

@FunctionalInterface
public interface TransactionalTask<T> {
    T execute();
}

함수형 인터페이스란? 오직 1개의 추상 메서드를 가지는 인터페이스. 여기서 추상 메서드란, 자식 클래스에서 반드시 오버라이딩 해야 사용할 수 있는 메서드이다.

그리고, 트랜잭션이 필요한 작업을 도와준다는 의미로 하나의 헬퍼 클래스를 생성하도록 하자.

@Component
public class TransactionHelper {

    @Transactional(readOnly = true)
    public <T> T getResult(final TransactionalTask<T> task) {
        return task.execute();
    }
}

헬퍼 클래스에서는 TransactionTask 타입의 어떠한 람다식을 받아서, 해당 람다식을 @Transactional이 걸린 상태로 실행해주는 역할을 진행한다. 이제 이 헬퍼 클래스를 활용하게 되면 아래와 같이 테스트 코드를 작성할 수 있다.

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));
            
    final List<FeedNode> 피드_노드들 = transactionHelper.getResult(new TransactionalTask<List<FeedNode>>() {
            @Override
            public List<FeedNode> execute() {
                final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
                return 피드_본문.getNodes().getValues();
            }
        });
    ...
}

transactionHelper 클래스의 getResult() 메서드의 인자로 함수형 인터페이스의 추상 메서드인 execute()의 익명 클래스가 들어간다. 그리고, 해당 구현체에 피드 본문을 조회하여 피드 노드를 반환하는 로직을 넣었다.

익명 클래스

클래스의 선언과 인스턴스화를 동시에 진행할 수 있는 클래스로, 이름이 없는 클래스라 익명 클래스라고 부른다.

이때, 익명 클래스의 경우 람다로 축약할 수 있기 때문에 아래와 같이 더 간결하게 리팩터링을 진행할 수 있다.

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));
            
    final List<FeedNode> 피드_노드들 = transactionHelper.getResult(() -> {
    	final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
    	return 피드_본문.getNodes().getValues();
    });
    
    ...
}

최종적으로 실행해보면 위와 같이 테스트 코드도 잘 실행되는 것을 볼 수 있다!

이제 테스트 코드에서 지연로딩이 필요한 부분에 대해 (then절 같이 응답값을 꺼내어 검증할 때) 이를 잘 사용하면 된다. 오랜만에 함수형 인터페이스 같은 개념을 보다 보니까 헷갈렸는데, 아무쪼록 잘 해결할 수 있어서 다행이다. 꽤 의미있는 트러블 슈팅을 한 것 같아서 재밌었다

추가

더 좋은 방법을 찾게되어서 작성해보고자 한다.

@Autowird
private TransactionTemplate transactionTemplate;

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));
    
    final List<FeedNode> 피드_노드들 = transactionTemplate.execute(new TransactionCallback<List<FeedNode>>() {
            @Override
            public List<FeedNode> doInTransaction(final TransactionStatus status) {
                final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
                return 피드_본문.getNodes().getValues();
            }
        });
    
    ...
}

스프링에서는 이미 TransactionTemplate 이라는 인터페이스를 통해서 제공을 해주고 있었다.. 위와 같이 반환값이 필요한 경우라면 TransactionCallback을 인자로 받으면 된다. 람다를 활용하면 더 축약이 가능하다.

@Autowird
private TransactionTemplate transactionTemplate;

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));
    
    final List<FeedNode> 피드_노드들 = transactionTemplate.execute(status -> {
            final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
            return 피드_본문.getNodes().getValues();
    });
    
    ...
}

지금 보면 직접 만든 transactionHelper와 완전 동일하다고 봐도 무방하다. 그냥 요렇게 사용하는 게 더 좋을 것 같다.

만약, 반환값이 필요없다면 TransactionCallbackWithoutResult를 인자로 받으면 된다.

@Autowird
private TransactionTemplate transactionTemplate;

@Test
void 테스트() throws JsonProcessingException {
    ...
	
    final FeedCategory 카테고리 = 피드_카테고리를_저장한다("이커머스");
    final Long 피드_아이디 = 피드를_생성한다(액세스_토큰, 카테고리.getId(), "피드 제목", "피드 소개글", "피드 본문",
            30, List.of(노드1, 노드2));
    
    transactionTemplate.execute(new TransactionCallbackWithoutResult() {
            @Override
            protected void doInTransactionWithoutResult(final TransactionStatus status) {
                final FeedContent 피드_본문 = 피드로부터_본문을_가져온다(피드_아이디);
                피드_본문.getNodes().getValues();
            }
        });
        
    ...
}

[JPA] 1:N fetchJoin과 limit을 함께 사용하여 발생한 OutOfMemory 문제 해결

Wed, 10 Apr 2024 00:00:00 GMT

[들어가며]

톰캣 성능테스트를 하기 위해 특정 API에 대하여 한 번에 많은 요청을 보냈고, 평소에 잘 동작하던 API가 OutOfMemoryError를 던지면서 모든 요청에 대해 실패하였다. 이 문제를 해결하기 위해 어떤 과정을 거쳤는지 자세히 살펴보자

[문제 상황]

톰캣 성능테스트를 하기 위해 Jmeter를 사용하였고, 1초에 500번의 피드 목록 조회 요청을 보내도록 설정했다. 그런데 500번의 요청이 모두 실패했고, 어떤 에러 메세지가 담겨있는지 확인했다. 메세지는 다음과 같았다.

Handler dispatch failed: java.lang.OutOfMemoryError: Java heap space

상상도 못한 OutOfMemoryError가 발생했다. 이전에는 한 번도 만나보지 못했던 에러였다.

바로 어플리케이션의 로그를 확인했다. 그리고 다음과 같은 경고가 떠 있는 것을 발견할 수 있었다.

[WARN] [http-nio-9000-exec-483] [org.hibernate.orm.query] - HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory

바로 쿼리에 문제가 있었다는 것을 알게되었다. 그럼 피드 목록 조회 요청 때 사용하는 쿼리를 살펴보자!

[엔티티 연관관계]

그 전에 이해를 돕기 위해 엔티티의 연관관계에 대해서 간단하게 설명하면

'피드'와 '피드 태그'라는 엔티티는 1:N 관계이다.
한 '피드'에 대하여 '피드 태그'는 최소 1개부터 최대 5개까지 존재할 수 있다.

문제의 쿼리

무한 스크롤을 위해 피드 목록을 가져올 때 요청받은 사이즈만큼 피드를 전달하는데, 이때 피드와 피드 태그를 모두 반환한다. 피드 태그는 지연 로딩으로 설정해놓았기 때문에, N+1 문제를 방지하기 위해 fetchJoin을 붙여 한 번에 가져오도록 했다.

다음은 실제 QueryDsl로 작성한 쿼리문이다.

피드 태그를 가져오기 위해 leftJoin과 fetchJoin을 한 것을 확인할 수 있다. 그리고 요청받은 사이즈만큼 피드를 조회하기 위해 limit 구문을 추가했다.

그런데 실제 쿼리가 나간 것을 확인해보니 limit 구문이 적용이 되지 않고 있었다.

select
    --...
from
    feed f1_0 
    --...
left join
    feed_tag v1_0 
        on f1_0.id=v1_0.feed_id 
where
    f1_0.status=? 
order by
    f1_0.created_at desc

이유

그 이유는 fetchJoin과 limit을 함께 써서 그렇다. N쪽의 테이블에서 몇 개의 데이터를 가져와야하는지 알 수 없어서 테이블 정보를 모두 가져올 수 밖에 없다는 것이다.

아래 그림과 같이 피드가 존재한다고 하자. 피드 3개를 가져오기 위해 limit 3을 걸었다. 우선 피드 태그에 fetchJoin을 붙이지 않으면 어떤 결과가 나올까?

결과는 피드1 밖에 가져오지 못한다.

그 이유는 피드와 피드 태그를 Join 했기 때문에,

(피드1, 피드 태그1-1) (피드1, 피드 태그1-2) (피드1, 피드 태그1-3)

이렇게 3개의 데이터가 조회되었고, 엔티티로 변환되면서 피드 1개만 반환되는 것이다.

그래서 이 문제를 해결하기 위해 fetchJoin을 사용해서 원하는대로 피드 3개를 받았지만, 앞서 말했던 limit 구문이 적용되지 않는 문제가 생겼다.

피드 태그 테이블을 모두 가져와 메모리에 올려놓고 어플리케이션 단에서 limit 만큼 자르기 때문에, 요청을 한 번에 많이 보냈을 때 Out of Memory 문제가 생겼던 것이다.

해결방법

쿼리를 한 번만 보내서 모든 정보를 가져오자는 욕심을 버리고 쿼리를 두 번 날리도록 수정했다. 이때 @BatchSize라는 어노테이션을 붙여주었다. 이 어노테이션을 붙이면 지정한 size만큼 In절을 이용해 select할 수 있다.

피드 엔티티의 피드 태그 필드에 @BatchSize를 적용했다.

피드를 조회할 때 20개보다 넘게 조회할 일이 없기 때문에 적절하게 사이즈를 20으로 지정해주었다.

그럼 이제 피드 목록을 조회할 때

피드를 지정된 사이즈 만큼 조회하는 쿼리
조회한 피드의 태그를 조회하는 쿼리 이렇게 두 번의 쿼리가 날아간다.

다음과 같이 쿼리가 제대로 나가는 것을 확인할 수 있었다. 기존 쿼리와 다른 점은 첫번째 쿼리에서는 피드 태그를 조회하지 않는다. 따라서 limit 절이 제대로 적용되었다.

이후 두번째 쿼리에서는, 앞서 조회한 피드의 각각의 태그를 조회하는 데, 이때 In절을 이용하여 한번의 쿼리로 모든 피드의 태그를 조회하였다.

Hibernate:
    select
        v1_0. feed_id,
        v1_0.id, v1_0. name
    from
        feed_tag v1_0
    where
        array_contains(?,v1_0.feed_id)

[정리]

1:N 연관관계에서 fetchJoin과 Limit 구문을 함께 쓰지 않도록 조심하자. 또 N+1 문제를 피하기 위해 무작정 fetchJoin을 붙이지말고 신중하게 하자. 실제 쿼리가 어떻게 나가는지도 꼭 확인하는 것이 필요할 것 같다.

[Gradle] Jacoco를 활용하여 테스트 커버리지 설정하기

Thu, 21 Mar 2024 00:00:00 GMT

[들어가며]

이번 프로젝트 CI 플로우 과정 중에서 Jacoco를 활용하여 테스트 리포트를 발행하고, 커버리지를 체크하고 있다. CI에 대한 글은 다음에 완전하게 구축된 이후에 작성하는 게 좋을 것 같아서, 오늘은 Jacoco에 대해서만 가볍게 짚고 넘어가고자 한다.

[Jacoco 설정하기]

Jacoco는, 테스트 코드 커버리지를 분석해주는 자바의 무료 라이브러리이다.Jacoco 플러그인에는 JacocoTestReport와 JacocoTestCoverageVerification Task 등이 존재한다. (여기서는 이 2가지를 위주로 알아보도록 하자.)

JacocoTestReport: 커버리지 결과를 리포트로 저장하는 역할
JacocoTestCoverageVerification: 원하는 커버리지 기준을 만족하는 확인하는 Task

build.gradle 설정해주기 - JacocoTestReport

plugins {
    id 'jacoco'
}

jacoco {
    toolVersion = "0.8.10" // https://www.jacoco.org/jacoco/trunk/doc/changes.html
}

jacocoTestReport {
    dependsOn test
    reports {
        html.required = true
        xml.required = true
    }

    // QueryDSL QDomain 제외시키기
    def QDomains = []

    for (qPattern in '**/QA'..'**/QZ') {
        QDomains.add(qPattern + '*')
    }
    afterEvaluate {
        classDirectories.setFrom(
                // 그 외의 매칭되는 클래스도 제외 대상
                files(classDirectories.files.collect {
                    fileTree(dir: it, excludes: [
                            "sidepair.domain.**.**",
                            "**/*Application*",
                            "**/*Config*",
                            "**/*Dto*",
                            "**/*Request*",
                            "**/*Response*",
                            "**/*Interceptor*",
                            "**/*Exception*"
                    ] + QDomains)
                })
        )
    }
    // 리포트 생성 후 커버리지 체크
    finalizedBy jacocoTestCoverageVerification
}

jacocoTestCoverageVerification {
    // QueryDSL QDomain 제외시키기
    def QDomains = []
    // qPattern = "*.QA","*.QB","*.QC", ... "*.QZ"
    for (qPattern in '*.QA'..'*.QZ') {
        QDomains.add(qPattern + '*')
    }

    violationRules {
        rule {
            // rule 활성화
            enabled = true

            // 클래스 단위로 룰 체크
            element = 'CLASS'

            // 라인 커버리지를 최소 80% 만족
            limit {
                counter = 'LINE'
                value = 'COVEREDRATIO'
                minimum = 0.80
            }
						
            // 마찬가지로 제거 대상 지정
            excludes = [
                    "sidepair.domain.**.**",
                    "**.*Application*",
                    "**.*Config*",
                    "**.*Dto*",
                    "**.*Request*",
                    "**.*Response*",
                    "**.*Interceptor*",
                    "**.*Exception*"
            ] + QDomains
        }
    }
}

tasks.named('test') {
    outputs.dir snippetsDir
    useJUnitPlatform()
    // test 수행 이후 리포트 생성
    finalizedBy jacocoTestReport
}

build.gradle 코드가 상당히 길기는 한데, 그렇게 어려운 내용은 아니다.

plugins {
    id 'jacoco'
}

jacoco {
    toolVersion = "0.8.10" // https://www.jacoco.org/jacoco/trunk/doc/changes.html
}

먼저, jacoco에 대한 플러그인을 설정해주는 부분이다. 현재 스냅샷 버전 제외 가장 최신 버전이 0.8.10이길래 이 버전으로 설치를 해주었다.

jacocoTestReport {
    reports {
        html.required = true
        xml.required = true
    }

    // QueryDSL QDomain 제외시키기
    def QDomains = []

    for (qPattern in '**/QA'..'**/QZ') {
        QDomains.add(qPattern + '*')
    }
    
    ...
}

tasks.named('test') {
    ...
    // test 수행 이후 리포트 생성
    finalizedBy jacocoTestReport
}

jacoco에서 제공하는 테스트 리포트 발행을 위해 사용하는 부분이다. test가 실행된 다음에 리포트를 발행해야 하기 때문에 finalizedBy을 통해서 test 실행 이후 동작하도록 만들었다. finalizedBy는 A task의 성공과 실패에 상관없이 A가 끝나야 B가 실행되기 때문에 주의해서 사용하도록 하자. (성공해야 실행되도록 하려면 dependsOn을 사용한다. 테스트가 실패하더라도 리포트를 발행해야 하기 때문에 여기서는 finalizedBy를 활용하였다.)

이후, xml과 html에 모두에 대해서 리포트를 발행하도록 하였다. 사실 실제로는 html만 보는 경우가 많아서 꼭 xml까지 하지 않아도 된다고 생각한다.

  ...
    
    // QueryDSL QDomain 제외시키기
    def QDomains = []

    for (qPattern in '**/QA'..'**/QZ') {
        QDomains.add(qPattern + '*')
    }
    afterEvaluate {
        classDirectories.setFrom(
								// 그 외의 매칭되는 클래스도 제외 대상
                files(classDirectories.files.collect {
                    fileTree(dir: it, excludes: [
                            "sidepair.domain.**.**",
                            "**/*Application*",
                            "**/*Config*",
                            "**/*Dto*",
                            "**/*Request*",
                            "**/*Response*",
                            "**/*Interceptor*",
                            "**/*Exception*"
                    ] + QDomains)
                })
        )
    }
    finalizedBy jacocoTestCoverageVerification
    
 }

프로젝트에서 현재 QueryDSL을 사용하고 있기 때문에 QueryDSL로 인해 생성된 QDomain이라는 것이 존재한다. 이 친구들이 테스트 커버리지에 들어가게 되면 50% 이하로 커버리지가 안 나오는 기이한 현상이 발생하기 때문에 qDomain은 패턴 매칭을 통해서 제외시켜주었다. 또한, Dto나 Config, Exception 같은 클래스는 테스트할 필요가 없다고 생각해서 제외해두었다.

위 코드에서는 도메인과 인터셉터까지 있는데, 인터셉터는 추후 제거할까 생각 중이다. (충분히 테스트가 가능하니까) 도메인의 경우 테스트를 짜고 있기는 하지만, 나중에 도메인 객체를 전부 작성하게 되면 추가할까 생각 중이다.

마지막으로 리포트를 발행하고 나면 커버리지를 설정할 수 있도록 태스크를 연결해두었다.

이렇게 완성된 리포트의 경우 기본적으로 build/reports/jacoco/test/html 하위에 생성된다.

여기서 jacoco-resources 밑쪽에 있는 index.html이랑 tests 쪽의 index.html 둘로 나뉘어져 있는데, 나오는 정보가 살짝 다르다. 상위에 있는 index.html이 jacoco에 의해서 생성된 리포트이고, 아래의 index.html은 gradle에서 자동으로 만들어주는 것으로 알고 있다.

상위의 index.html의 경우 위와 같이 어느 클래스에서 어떤 파일이 커버리지에 불충족하는지 나오게 된다.

하위의 테스트 리포트는 위와 같이 걸린 시간이나 몇 개의 테스트가 성공하고 실패한지 확인할 수 있다.

build.gradle 설정해주기 - JacocoTestCoverageVerification

jacocoTestCoverageVerification {
    // QueryDSL QDomain 제외시키기
    def QDomains = []
    // qPattern = "*.QA","*.QB","*.QC", ... "*.QZ"
    for (qPattern in '*.QA'..'*.QZ') {
        QDomains.add(qPattern + '*')
    }

   ...
}

이번에는 커버리지에 대한 설정 부분이다. 마찬가지로 QDomain에 대해서는 측정할 필요가 없기 때문에 제거하도록 한다.

 ...
 
 violationRules {
        rule {
            // rule 활성화
            enabled = true

            // 클래스 단위로 룰 체크
            element = 'CLASS'

            // 라인 커버리지를 최소 80% 만족
            limit {
                counter = 'LINE'
                value = 'COVEREDRATIO'
                minimum = 0.80
            }
						
            // 마찬가지로 제거 대상 지정
            excludes = [
                    "sidepair.domain.**.**",
                    "**.*Application*",
                    "**.*Config*",
                    "**.*Dto*",
                    "**.*Request*",
                    "**.*Response*",
                    "**.*Interceptor*",
                    "**.*Exception*"
            ] + QDomains
        }
    }

다음으로는 세부적인 커버리지 룰에 대해서 지정하는 부분이다.

element: 커버리지를 체크할 기준 정하기
BUNDLE: 프로젝트의 모든 파일을 합친 것 (디폴트)
CLASS: 클래스- GROUP: 논리적 번들 그룹
METHOD: 메서드
PACKAGE: 패키지
SOURCEFILE: 소스 파일

나는 클래스 단위로 설정하기 위해 CLASS라고 지정해주었으며, 대부분 클래스 단위로 많이 보시는 것 같다. 좀 더 빡세게 하고 싶다면 METHOD로 해도 될 것 같은데, 그럼 너무 확인하기 힘들지 않을까 싶다.

counter: limit을 통해 지정할 수 있으며, 커버리지 측정을 위한 최소 단위. 자바 바이트 코드의 실행을 기준으로 측정된다.
BRANCH: 조건문 등의 분기 수
CLASS: 클래스 수, 내부 메서드가 한 번이라도 실행되었다면 실행된 것으로 간주한다
COMPLEXITY: 복잡도
INSTRUCTION: Java 바이트코드 명령의 수 (디폴트)
METHOD: 메서드 수, 메서드가 한 번이라도 실행되었다면 실행된 것으로 간주
LINE: 빈 줄을 제외한 실제 코드의 라인 수, 라인이 한 번이라도 실행되었다면 실행된 것으로 간주

여기서 몇 퍼센트의 커버리지를 가졌을 때 빌드 실패를 터트릴 것인지 설정할 수 있다. 나는 조금 더 빡세게 하고 싶어서 LINE 기준으로 80%의 기준을 잡았다. 조금 더 널널하게 하고 싶다면 METHOD로 해도 될 것 같은데, 어차피 모든 분기점에 대해 테스트를 작성하려면 라인으로 하는 게 가장 나을 것 같다고 생각했다.

value: limit을 통해 지정할 수 있으며, 측정한 커버리지를 어떠한 방식으로 보여줄 것인지 정한다.
COVEREDCOUNT: 커버된 개수
COVEREDRATIO: 커버된 비율, 0~1 사이의 수로 1이 100% (기본값)
MISSEDCOUNT: 커버되지 않은 개수- MISSEDRATIO: 커버되지 않은 비율, 0~1 사이의 수로 1이 100%
TOTALCOUNT: 전체 개수

task copyDocument(type: Copy) { (11)
    dependsOn asciidoctor
    from file("build/docs/asciidoc")
    into file("src/main/resources/templates/docs")
}

build {
    dependsOn copyDocument (12)
}

dependencies {
    asciidoctorExt 'org.springframework.restdocs:spring-restdocs-asciidoctor' (13)
    testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc' (14)
}

bootJar {
    dependsOn asciidoctor (15)
    from ("${asciidoctor.outputDir}/html5") {
        into 'templates/docs'
    }
}

커버되지 않은 비율을 보여주는 것보다 커버된 비율을 보여주는 게 도움이 될 것 같다고 생각했다.

minimum: counter 값을 value에 맞게 표현하였을 때의 최소값, 이를 통해서 커버리지 판단의 성공 여부가 결정된다고 볼 수 있다.
기본적으로 표기한 자리수만큼 value가 출력되기 때문에 90%의 커버리지를 원한다면 0.9가 아닌 0.90으로 입력해줘야 한다. 아니면 0.9로 입력하면 0.9x 값을 모두 0.9로 인식한다

나는 우선 80% 정도로 설정하였는데, 90%까지 올릴 생각은 있다.

excludes: 커버리지 측정 시 제외할 클래스를 지정할 수 있다.
패키지 레벨의 경로로 지정해야 하며, 경로에는 *와 ?을 사용할 수 있다.

여기는 아까 테스트 리포트 발행했을 때의 경로랑 동일하게 지정해주면 된다.

실행해보기

Test 실행의 경우 ./gradlew test, ./gradlew clean build로도 실행이 가능하고, intellij를 사용하면 gradle 도구를 활용할 수도 있다.

만약 minimum값에 0. 90을 입력하고 결과를 보면, 아래와 같이 커버리지를 넘지 못했을 때 빌드 실패가 발생하게 된다.

이때는 테스트 리포트 보면서 어디가 부족한지 보고 확인하면서 진행하면 된다.

참고로, Lombok의 어노테이션에 대한 코드 커버리지가 0%로 나오는 문제를 방지하기 위해서 lombok.config를 추가로 설정해주자.

lombok.addLombokGeneratedAnnotation = true

위와 같이 프로젝트의 최상단 경로에 적용해두어야 적용이 된다. 참고로 메서드 단위로 측정을 패스하는 게 없을 때는 커버리지 측정을 원하지 않는 클래스라면 패키지 단위로 묶어두는 게 좋다.

[Spring] Rest-docs 연동하기

Wed, 20 Mar 2024 00:00:00 GMT

[들어가며]

지금은 솔로 프로젝트이지만 다른 프로젝트를 잔행할 때 프론트 팀원과 협업하게 될 경우 필요할것 같았고, 과거 Swagger를 구축해본 경험이 있기도 해서 개인으로 욕심으로 한 번 직접 구축해보고 싶다는 생각이 들어 프로젝트 하는김에 함께 진행하게 되었다.

[Rest-docs는?]

Spring Rest Docs는 Restful 서비스에 대해 정확하고 읽기 쉬운 문서를 생성할 때 도움을 주는 문서 자동화 도구이다. 흔히 백엔드, 프론트엔드가 협업할 때 프론트엔드는 API endPoint를 알고 있어야 해당 API로 요청을 보내서 response를 받아 처리한다. 만약 백엔드 개발자가 API 문서를 수정했다면 프론트엔드 개발자한테 어떻게 알려야 할까? 직접 메신저로 '요구사항이 변경되었어요' 라고 말할 수도 있겠지만, 이는 매우 번거롭다. 만약 프론트엔드 개발자가 당장 수정해야 하는 hotfix 요구사항임에도 메신저를 읽지 못했다면? 혹은, 원하는 시간에 서로 소통할 수 없다면? 하나의 정형화된 문서를 통해서 관리하는 게 훨씬 쉬울 것이다. Swagger를 사용하는 경우도 있고, Rest docs를 사용하는 경우도 있을 텐데 각각의 장단점이 뚜렷하다.

Swagger의 경우 테스트 코드 작성에 부담이 없지만, 프로덕션 코드 자체에 문서에 대한 설정 내용이 어노테이션으로 들어가기 때문에 이 자체가 부담이 될 수 있다. Swagger에서 Rest docs로 전환해야 한다면 프로덕션 코드 자체를 전부 바꿔야 하기 때문이다. 하지만, Rest-docs보다는 비교적 적용하기가 쉬우며, 문서 자체는 우리가 직접 구축할 필요없이 알아서 만들어주고, 직접 테스트를 해볼 수 있는 화면을 제공하기 때문에 프론트엔드 개발자 입장에서는 조금 더 편할 수도 있다.

반면에 Rest-docs의 경우 테스트 코드를 기반으로 하기 때문에 프로덕션 코드에는 영향을 끼치지 않는다. 이 말은 곧, 테스트 코드가 정말 꼼꼼하게 짜여 있어야 한다는 것이다. 성공했을 때, 예외가 발생했을 때 등등... response 값이 변화하여 내려가는 경우에는 웬만하면 테스트 코드를 작성해야 한다. (그렇기 때문에 RestAssured보다 덜 무거운 MockMvc를 활용하는 게 더 낫다고 판단한 점도 있다.) 또한, 스웨거에 비해 구축이 어려운 편이다. 문서 구축 자체는 빌드된 adoc 파일을 직접 조립해야 하고, 프론트엔드 개발자가 직접 테스트해볼 수도 없다. 하지만, 직접 구축하기 때문에 문서 내부에 어떤 내용이 들어갈지 조금 더 세분화하여 개발자가 작성할 수 있다.

개인적으로 규모가 작다면 swagger를 사용해볼만 하다고 생각하지만, 프로덕션 코드 자체를 수정하는 게 찝찝하기 때문에 rest-docs를 조금 더 선호하는 편이다. 한 번 적용해두면 그뒤부터 응용은 쉽기 때문에 처음 러닝커브만 조금 견디면 된다.

[SetUp - build.gradle]

그전에, Rest Docs의 경우 기본적으로 'Asciidoctor'라는 친구를 사용하는데, 이 친구는 일반 텍스트를 처리하면서 HTML 형태로 만들어주는 친구다. 이 친구의 개념 자체가 중요한 건 아니지만, HTML로 문서를 생성하기 위한 일종의 전처리 도구라고 생각하자. 또한, 각각의 테스트 코드가 성공하면 'snippet'이라는 친구가 생성되는데, 이러한 스니펫들을 조립하여 문서를 생성한다고 생각하자.

먼저, build.gradle에 다음과 같은 내용을 추가해야 한다.

plugins {
	id 'org.asciidoctor.jvm.convert' version '3.3.2'
}
configurations {
    asciidoctorExt
}

ext {
    snippetsDir = file('build/generated-snippets')
}
test {
    outputs.dir snippetsDir
}

asciidoctor {
    inputs.dir snippetsDir
    configurations 'asciidoctorExt'
    dependsOn test

    sources {
        include("**/index.adoc")
    }

    baseDirFollowsSourceFile()
}

asciidoctor.doFirst {
    delete file('src/main/resources/templates/docs')
}

task copyDocument(type: Copy) {
    dependsOn asciidoctor
    from file("build/docs/asciidoc")
    into file("src/main/resources/templates/docs")
}

build {
    dependsOn copyDocument
}

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

bootJar {
    dependsOn asciidoctor
    from ("${asciidoctor.outputDir}/html5") {
        into 'static/docs'
    }
}

생각보다 설정해줄 것이 굉장히 많기 때문에 조금씩 나눠서 보도록 하자.

plugins {
    id "org.asciidoctor.jvm.convert" version "3.3.2" (1)
}

configurations {
    asciidoctorExt (2)
}

ext {
    snippetsDir = file('build/generated-snippets') (3)
}

tasks.named('test') {
    outputs.dir snippetsDir (4)
}

Asciidoctor 플러그인을 적용한다.
asciidoctorExt를 프로젝트의 configuration에 추가한다. asciidoctorExt는 Asciidoctor를 사용하여 문서를 생성하고 포맷하는 데 사용하는 플러그인인데, 이를 이용하여 HTML 형식으로 출력할 수 있도록 만든다고 생각하면 된다.
생성된 스니펫들을 어느 위치에 저장할 것인지 지정하는 것이다. (디폴트로 build 폴더 밑에 생성하는 편)
저장한 스니펫 경로가 테스트 결과로 생성되는 디렉터리에 추가되도록 설정하는 것이다. 테스트가 실행될 때 스니펫이 생성되면, 해당 디렉터리에 저장되는 것이다.

asciidoctor {
    inputs.dir snippetsDir (5)
    configurations 'asciidoctorExt' (6)
    dependsOn test (7)

    sources {
        include("**/index.adoc") (8)
    }

    baseDirFollowsSourceFile() (9)
}

asciidoctor.doFirst {
    delete file('src/main/resources/templates/docs') (10)
}

asciidoctor가 할 일을 정의하는 부분이다. 이전에 설정한 스니펫 저장 경로를 입력 디렉터리로 만들어서, asciidoctor가 문서를 생성할 때 어디를 참조할지 지정하는 것이다.
ext에서 구성한 asciidoctorExt를 구성 파일로 사용하도록 만드는 것이다.
문서가 생성되기 전에 테스트가 실행될 수 있도록, test에 종속적이도록 만든다. (test 실행 -> 문서 생성 느낌!)
rest-docs 문서의 경우, .adoc 파일을 바탕으로 생성하게 되는데 이때 source를 지정하게 되면 특정 adoc만 HTML로 만든다. 만약 모든 adoc에 대해 각각 html을 만들고 싶다면 해당 옵션은 제거해도 된다.
특정 .adoc에 다른 adoc을 include 하고 싶을 때 경로를 baseDir로 맞춰주는 역할이다. 나 같은 경우 index.adoc으로 세부 adoc을 로드하도록 만들었기 때문에 이 옵션을 활성화해주었다.
static.docs 파일을 초기화하고 다시 만들도록 설정하는 것이다. 기본적으로는 static 하위에 두는 경우가 많은데, 미션에서 타임리프를 사용하다 보니 templates 폴더 하위로 설정하였다.

task copyDocument(type: Copy) { (11)
    dependsOn asciidoctor
    from file("build/docs/asciidoc")
    into file("src/main/resources/templates/docs")
}

build {
    dependsOn copyDocument (12)
}

dependencies {
    asciidoctorExt 'org.springframework.restdocs:spring-restdocs-asciidoctor' (13)
    testImplementation 'org.springframework.restdocs:spring-restdocs-mockmvc' (14)
}

bootJar {
    dependsOn asciidoctor (15)
    from ("${asciidoctor.outputDir}/html5") {
        into 'templates/docs'
    }
}

asciidoctor 작업한 이후 (dependsOn), build/docs/asciidoc을 보면 상단에서 설정해준 source 옵션에 따라 html이 생기게 된다. 나 같은 경우 프로덕션 코드에서 html에 접근할 수 있도록 하기 위해서 resources/templates/docs에 복사를 진행하였다.
빌드 작업이 copyDocument 이후에 진행되도록 설정한다.
asciidoctorExt configuration을 사용하여 restdocs-asciidoctor 라이브러리에 대한 의존성을 설정한다. 이렇게 하면 .adoc 파일에서 빌드, 생성된 스니펫을 가리키도록 스니펫 속성이 자동으로 구성된다.
MockMVC를 활용하여 rest-docs를 구성할 때 사용한다. (Rest-Assured를 사용하면 spring-restdocs-restassured 사용)
생성된 문서를 jar 파일에 패키징해서 정적 컨텐츠로 제공할 때 사용하는 것이다. asciidoctor에 종속적이도록 만들어서, jar 파일을 빌드하기 전에 문서가 생성되었는지 체크한다. 이렇게 되면 jar 파일이 빌드되기 전에 문서가 생성되고, 생성된 문서는 jar 파일에 포함된다. asciidoctor 진행 이후 문서를 templates/docs로 이동시킨다.

결과적으로 ./gradlew clean build를 진행하게 되면 test -> asciidoctor -> copyDocument -> build 순으로 세팅이 진행된다.

코드에 적용하기 (Junit5 기준)

우선, 테스트할 대상 클래스에 다음과 같은 셋업 작업을 진행해준다. controller가 여러 개라면 공통적으로 사용할 부분은 빼는 것이 좋기 때문에, 나는 별도의 helper 클래스를 생성해두었다.

@ExtendWith(RestDocumentationExtension.class) (1)
public class RestDocsHelper {

    private MockMvc mockMvc;

    private RestDocumentationResultHandler documentationResultHandler;

    @BeforeEach
    void setUp(final WebApplicationContext webApplicationContext,
               final RestDocumentationContextProvider restDocumentationContextProvider) {

        this.documentationResultHandler = MockMvcRestDocumentation.document(
                "{class-name}/{method-name}", (2)
                Preprocessors.preprocessRequest(Preprocessors.prettyPrint()), (3)
                Preprocessors.preprocessResponse(Preprocessors.prettyPrint()));

        this.mockMvc = MockMvcBuilders.webAppContextSetup(webApplicationContext) (4)
                .addFilter(new CharacterEncodingFilter("UTF-8", true)) (5)
                .alwaysDo(MockMvcResultHandlers.print()) (6)
                .alwaysDo(documentationResultHandler) (7)
                .apply(documentationConfiguration(restDocumentationContextProvider)) (8)
                .build();
    }
}

Junit5에서 사용할 수 있으며, Spring Rest Docs의 RestDocumentationExtension 클래스를 사용하여 테스트를 확장시키는 것이다. 어렵게 생각할 필요없이, API 문서를 생성하기 위해 환경을 설정한다고 보면 된다.
문서의 세부 경로를 설정해주는 부분이다. build/generated-snippets 패키지 밑에, class-name 패키지, 그리고 method-name 패키지 하단에 각각의 스니펫이 생성되도록 만드는 설정이다.
사실 이 부분에 나중에 배포될 때를 대비하여 프로토콜 정보나 host 정보도 지정해줄 수 있다. (Preprocessors.modifyUris 활용)
request, response에 대해서 전처리 작업을 해주는 것인데 요청, 응답에 대해 읽기 쉽도록 만들어준다.
각각의 테스트 메서드가 실행되기 전에 공통적으로 실행할 작업을 정의한다. mockMvc에 대해서 설정하는 것을 볼 수 있는데, 이를 통해 Spring REST docs에서 생성된 컨텍스트를 사용하여 API를 테스트할 수 있도록 만들어주는 전초 작업이라고 볼 수 있다.
문서 생성 시 한글이 깨질 수 있기 때문에 이를 위해 인코딩 형식을 지정해주는 부분이다.
처리한 내용에 대해 항상 로깅 작업을 수행하도록 print를 해주는 부분이다.
위에서 설정한 정보들을 항상 적용하도록 만드는 것이다.

[Redis] Redis Cache를 활용한 성능 개선기 (2)

Sat, 16 Mar 2024 00:00:00 GMT

[Spring에서 Redis Cache 도입]

캐시 전략을 선택했으니 이제 프로젝트에 진행할 차례이다. Redis는 다양한 언어를 지원하고 여러 프레임워크에서 Redis를 위한 추상화가 잘 되어있어서 도입하기 굉장히 편하다. 이번 프로젝트는 Spring boot 3.1 버젼 Java 17 버젼이로 이루어져 있으니 이 기준인 점 참고 바란다.

[Redis 설정]

redis를 통해 캐시를 하려면 몇몇 설정들이 필요하다. 위의 설정을 하나씩 살펴보자.

로컬 캐싱의 경우, 객체 자체가 어플리케이션 메모리에 보관되기 때문에 타입 정보가 그대로 유지되고, 객체의 상태가 변하지 않는다. 그래서 직렬화, 역직렬화가 필요하지 않거나 필요한 경우에도 객체의 값이 변하는 걱정은 하지않아도 된다.

하지만 글로벌 캐싱(redis)의 경우, 데이터를 문자열이나 JSON 같은 포맷으로 저장한다. 어플리케이션에서는 이 데이터가 어떤 객체인지 정확하게 모르고, 역직렬화(json -> 객체) 시 타입이 변환되거나 값이 변할 가능성이 생긴다.

그래서 redis를 직렬화, 역직렬화를 위해서 type을 정확하게 알려주는 Custom ObjectMapper를 만들어야할 필요가 있다. Custom ObjectMapper에 대해서 하나씩 살펴보자.

objectMapper.registerModule(new JavaTimeModule());

이 설정은 Java8의 날짜와 시간 API를 지원하기 위해 등록해야한다.

objectMapper.activateDefaultTyping(objectMapper.getPolymorphicTypeValidator(), ObjectMapper.DefaultTyping.EVERYTHING);

이 설정은 보안 상 안전하지 않은 타입의 역직렬화를 방지하는 목적이다. 즉, 외부에서 들어오는 데이터를 역직렬화하여 어플리케이션으로 가져왔을때 이 객체가 안전한 객체인지 확인하고 역직렬화를 진행하도록 하는 것이다. 예를 들어 위험한 명령어(ex -> DB 조작, 파일 삭제 등)가 포함 되어있는 객체가 어플리케이션 내로 들어오면 큰일 나기 때문에 이를 방지하는 것이다. activateDefaultTyping를 통해서 역직렬화할 객체의 화이트리스트를 정의할 수 있고, DefaultTyping을 설정하여 보안을 강화할 수 있다.

하지만 위 설정은 잘못 되어있다. 위 설정은 모든 객체에 대해서 역직렬화를 하겠다는 설정인데 이는 굉장히 위험한 설정이다. 현재는 redis가 private instance에 떠있고 지금 어플리케이션에서만 사용하기 때문에 안전한 객체만이 들어오기 때문에 당장은 문제가 없다. 하지만 redis를 통해 위험한 객체가 들어오면 무방비인 상태이기 때문에 화이트리스트 설정 및 DefaultTyping을 더 안전한 옵션으로 바꿔줘야한다. 내가 일단 이렇게 한 이유는 화이트리스트 객체를 설정하는 효율적인 기준에 대한 학습이 부족하고, 무엇이 안전한지 최선의 방법을 모르기 때문이다. 몇몇 방법을 적용해봤는데, 적용하기 굉장히 까다로워서 코드가 많이 수정되거나, API 스펙이 바뀌는 경우가 발생했다. 깊게 학습한 후에 최선의 방법을 찾아서 변경할 예정이다.

이 부분은 redisCache 설정 관련된 부분이다. ttl을 30분으로 설정하고 Null인 데이터는 캐싱하지 않겠다는 뜻이다. 그리고 위에서 정의한 serializer를 등록해준다.

그리고 Config 파일에 @EnableCaching을 붙혀주면 redis를 이용해 캐싱을 사용할 준비를 마치게된다.

[Spring AOP를 통해 Cache 적용하기]

Spring은 Cache를 AOP를 통해서 프로덕션 코드에 비침투적이고 쉽게 적용할 수 있다. 방법은 다음과 같다.

@Cacheable 어노테이션을 이용하면 해당 메소드에 쉽게 캐시를 적용할 수 있다. 동작 과정은 다음과 같다.

해당 메서드(findRoadmap)이 실행되기 전에 CacheHit를 한다.
캐시가 존재하면 해당 메소드를 실행하지 않고 바로 데이터를 반환한다.
캐시가 존재하지 않으면 해당 메소드를 실행한다.
해당 메소드 종료 후 메소드를 통해 생성된 데이터를 캐시에 넣는다.
데이터를 반환한다.

그리고 몇몇 옵션을 설정할 수 있는데 하나씩 살펴보자.

Value

CacheName을 설정하는 옵션이다. 이는 cache의 식별자로 사용이되며 생명주기가 같은 캐시끼리 같은 이름을 맞추어야한다.

KeyGenerator

캐시에 적용되는 키 값을 생성하는 객체를 설정할 수 있다. key를 설정하는 제일 간단한 방법은 SpEL을 이용하는 것이다. 좀 더 정교하게 키를 생성하고 싶은 경우 해당 옵션을 사용하여 Key를 생성하는 객체를 설정할 수 있다.

CacheManager

메소드마다 사용할 CacheManager를 설정하는 방법이다. 메소드마다 적용하고 싶은 옵션이 다를 수도 있으니 해당 옵션을 통해 직접 CacheManager를 설정하여 메소드에 맞는 설정을 적용할 수 있다.

이외에도 여러가지 옵션이 있으니 필요에 따라 활용하면 된다.

[Spring AOP를 통해 캐시 데이터 정합성 맞추기]

캐시 적용과 마찬가지로 Spring은 AOP를 활용해서 데이터 정합성을 맞출 수 있도록 추상화 되어있다. 방법은 다음과 같다.

@CacheEvict를 통해서 해당 메소드가 실행이 되면, value(cacheName)에 맞는 캐시들이 모두 초기화 되게 하는 옵션이다. 나 같은 경우에는 캐시에 정렬과 페이징이 적용이 되어있어서 어떤 피드 추가, 삭제, 수정이 되면 모든 캐시를 초기화 하도록 해서 데이터 정합성을 맞추었다. 만약 특정 캐시만 삭제하고 싶거나 복잡한 비즈니스 로직이 있으면 해당 어노테이션의 옵션을 사용하던가 직접 AOP를 구현하는 방법을 사용할 수 있다.

[성능 측정]

어플리케이션에 Redis를 적용했으니 얼마나 성능이 개선 되었는지 테스트 해보자. 다음과 같은 환경으로 테스트를 진행했다.

테스트 도구 : postman

테스트 환경 : local

테스트 API : 메인 페이지에 나가는 피드 조회 API를 선택

조건 : 정렬 조건은 최신순, size는 20으로 설정

[Redis Cache 적용 전]

[Redis Cache 적용 후]

[정리]

성능 개선 : 70ms -> 9ms

성능 개선 퍼센트 : 87% 개선

[Redis] Redis Cache를 활용한 성능 개선기 (1)

Fri, 15 Mar 2024 00:00:00 GMT

[들어가며]

프로젝트에 캐싱을 통해서 성능 개선을 하면서 Redis를 사용한 경험을 기록하고자 이 글을 쓰게 되었다.

[캐싱에 레디스를 선택한 이유]

높은 성능 : Redis는 기본적으로 전체 데이터를 메모리에서 관리한다. 데이터 백업 같은 작업은 디스크에 저장하긴 하지만 이는 비동기로 작동하기 때문에 응답 성능에는 거의 영향을 미치지 않는다. 그에 반해 RDB는 기본적으로 데이터를 디스크에서 관리한다. 요즘 RDB들도 메모리를 많이 활용하긴 하지만 결국에는 디스크에 저장된다. 즉, Redis는 RDB와 다르게 Disk I/O가 자주 발생하지 않기 때문에 성능이 몇 배 빠를 수 밖에 없다.
개발 용이성 : 어플리케이션과 연동하기 쉽게 여러 개발 언어를 지원한다. 그리고 다른 NoSQL과는 다르게 문법이 직관적이고, 개발 코드 양 또한 적다. 또한 싱글스레도로 명령을 처리하기 때문에 개발자가 race condition에 대한 걱정을 거의 안해도 된다.

여기까지는 Memcached와 같은 메모리 기반 캐시와 비슷하다. 하지만 Redis는 다음과 같은 차이점을 가지고있다.

다양한 자료 구조: Redis는 자체적인 Collection을 가지고 있다. 단순 String뿐만 아니라 List, Set, Sorted Set, Hash 등 여러가지 자료구조를 가지고 있다. 이를 응용해서 여러가지 요구사항을 효율적으로 처리할 수 있는 장점이 있다.
고가용성(High Availability) : Redis는 단순 Replication 뿐만 아니라, 고가용성을 위해 Sentinel과 Cluster를 지원한다. 이는 하나의 Redis 인스턴스에 오류가 생겨도 개발자의 다른 설정 없이 자동으로 다른 인스턴스로 대체할 수 있도록 해준다. 이를 페일 오버 기능이라고 하고 이 기능을 통해 고가용성을 확보할 수 있게 해준다.

반면에 Redis는 메모리 기반으로 동작하기 때문에 캐싱 데이터의 크기가 할당된 메모리 용량보다 큰 경우에 사용할 수 없다. 그리고 Memcached는 멀티 쓰레드로 작동하기 때문에 Redis보다 성능이 좀 더 좋다고 할 수 있다.

이번 프로젝트에서는 redis로 감당하지 못할 만큼 용량이 엄청나게 큰 데이터를 캐싱할 일이 없다. 그리고 위에 나온 장점을 모두 활용하고, redis를 데이터 저장소처럼 사용하는 경우도 있기 때문에 redis를 도입하기로 결정했다.

[캐싱 전략 선택]

읽기 전략

캐싱 읽기 전략에는 크게 Cache Aside와 Read Through이 있다. 이 둘을 비교해보자.

Cache Aside

Cache Aside 패턴을 위 그림 순서대로 설명하면 다음과 같다.

(1) 캐시에 해당 데이터가 있는지 확인한다(Cache hit). 만약 데이터가 있으면 바로 데이터를 반환한다.
(2) 캐시에 데이터가 없으면(Cache miss) DB에 쿼리를 날려서 데이터를 찾아온다.
(2.2) 데이터를 캐시에 적재한다.

이 패턴의 장점은 캐시에 문제가 생겨도 Application에는 문제가 없다는 것이다. 캐시에 장애가 발생하여서 Cache miss가 발생하여도 그냥 DB로 가서 데이터를 가져오면 된다. 즉, Application의 안정성이 높다.

다만, 캐시가 죽은 경우 순간적으로 DB에 Connection이 쏠려 순간적으로 부하가 걸릴 수 있다는 단점이 있다.

Read Through

Read Through 패턴을 위 그림 순서대로 설명하면 다음과 같다.

(1) 캐시에 해당 데이터가 있는지 확인한다(Cache hit). 만약 데이터가 있으면 바로 데이터를 반환한다.
(3.1) 캐시에 데이터가 없으면 캐시에서 데이터베이스에 접근하여 데이터를 가져온다.
(3.2) 데이터를 반환한다.

이 패턴은 사실 Redis로 구현하기 조금 힘들다. Redis에서 직접 DB에 접근하는 기능이 없는 것 같다. DynamoDB와 DAX를 이용해서 구현이 가능하다고는 한다. cache aside 전략과 차이점은 DB에 접근하는 주체에 있다. Cache에서 DB에 접근하게 되면 Application은 단순하게 Cache와의 Connection만을 유지하면 되므로 부담이 적다.

하지만 Cache가 장애가 생기면 Application 전체에 장애가 발생하는 위험이 있다. 그리고 cache aside 전략과 마찬가지로 데이터 정합성 문제가 발생할 여지가 있다.

Cache Aside를 선택한 이유

두 전략 모두 데이터 정합성에 대한 이슈가 있다. 하지만 이는 데이터 변경/삽입/삭제 시 고려해야하는 문제이므로 선택 기준에서 제외했다. Cache Aside를 사용하게 되면 Application의 안정성을 확보할 수 있다. 그리고 Read Through는 redis로 구현하기가 힘들기도하고, 안정성이 떨어진다. 그래서 Cache Aside 전략을 사용하도록 결정했다.

쓰기 전략

Write-through

Write-throught 패턴을 위 그림 순서대로 설명하면 다음과 같다.

(1) Application에서 쓰기 요청 시 Cache에 데이터를 넣는다.
(2)그 데이터를 그대로 DB에 넣는다.

Write Back(Behind) 패턴

Write Back 패턴은 Write Through와 비슷하지만, cache에서 db로 배치 업데이트를 하는 식이다. 이 패턴도 Cache와 DB와의 정합성을 맞추는데 용이하다는 장점이 있다. 하지만 Cache에 있는 데이터가 아직 DB에 반영되지 않고, Cache가 죽을 경우 데이터가 유실될 위험이 있다.

이 전략 또한 캐싱 하는 데이터가 여러 테이블을 join하는 복잡한 구조의 json 데이터여서 사용하기에 불편했다.

이 패턴은 DB와 캐시가 항상 동기화 되어있어 Cache의 데이터를 최신의 상태로 유지가 가능하다. 데이터 유실이 발생하면 안되는 상황에 유리한 조건이다. 하지만 나의 경우 캐싱 하는 데이터가 여러 테이블을 join하는 복잡한 구조의 json 데이터여서 사용하기에 불편했다.

Write Around 패턴

Write Around 패턴을 위 그림 순서대로 설명하면 다음과 같다.

(1)DB에 데이터를 쓴다.
(2)데이터 조회 시 데이터가 캐시에 있으면 데이터를 반환한다.
(3.1) 데이터가 없을 시 DB에서 데이터를 가져온다.
(3.2) 데이터를 캐시에 적재하고 응답값을 반환한다.

이 패턴의 경우 사실 쓰기 전략이라고 하기 애매하긴 하다. Cache Aside 패턴과 DB에 쓰는 방법을 합친 패턴이라고 볼 수 있다. 가장 직관적이고 효율적인 방법이지만 캐시와 DB와의 데이터 정합성이 맞지 않을 수도 있다는 단점이 있다.

Cache Aside를 선택한 이유

Write Through와 Write Back 패턴은 위에서도 얘기 했듯이 복잡한 데이터를 캐싱하기에 구현이 힘들다. DB 상에서 여러 테이블을 join 하고 어플리케이션에서 가공한 데이터를 캐싱하는데, 단순히 데이터를 넣거나 업데이트 할때 이러한 복잡한 데이터를 변경하기 힘들다. 물론 Event나 AOP를 활용하여 구현할 수 있겠지만, 캐싱에서 변경되는 데이터 대상이 하나가 아니기 때문에 비효율적이라고 느꼈다. 그리고 캐싱이 적용되는 데이터들은 변경이 많지 않은 데이터였기 때문에 굳이 이 전략들을 사용할 필요가 없었다. Write Around는 쓰기 작업 시 단순히 DB에 데이터를 넣기만 하면된다. 동시에 데이터 정합성을 맞추기 위해서 캐싱 되어있는 데이터들을 Redis에서 삭제했다. 이렇게 되면 해당 데이터 조회 시 캐시에 없으므로 DB에서 값을 가져와서 캐시에 적재하고, 그 다음부터는 캐시된 데이터를 사용하게 된다. 내가 선택한 프로세스는 다음과 같다.

쓰기 요청 시 DB에 데이터를 넣음
동시에 Redis에 있는 기존 데이터들 삭제
읽기 요청 시 Redis 확인. 존재하면 바로 반환
존재하지 않으면 DB에서 가져와서 Redis에 적재

캐싱 전략 선택 정리

위와 같은 이유로 읽기 전략은 Cache Aside, 쓰기 전략은 Write Around를 사용했다. 캐싱 프로세스는 다음과 같다.

[읽기]

데이터가 Redis에 존재하는지 확인한다. 존재하면 바로 반환한다.
데이터가 존재하지 않으면 DB에 가서 읽어온다.
읽어온 데이터를 Redis에 적재하고 반환한다.

[쓰기]

데이터를 DB에 저장한다.
Redis에 존재하는 해당 데이터와 관련된 캐시들을 모두 삭제한다.

생각보다 글이 너무 길어져서 1, 2편을 나눴습니다. Spring boot에서 Redis Cache 적용하기를 보려면 다음 글을 참고해주세요!

[Spring] Event로 느슨한 결합 사용하기

Fri, 08 Mar 2024 00:00:00 GMT

[들어가며]

이번 프로젝트를 진행하며 Event를 활용하여 요구사항을 해결한 적이 있다. 그 과정을 기록하고자 이 글을 쓰게 되었다.

[요구사항]

피드를 생성하는 로직이 있다. 이 피드는 각 단계가 있고, 각 단계에 사진 파일이 여러개 저장될 수 있다.

이 로직은 간단해보이지만 다음과 같은 문제점이 있다.

I/O가 실패하여 사진이 없어도 피드 생성 자체는 되어야한다라는 요구사항이 있다.

I/O중 예외가 발생하면 피드 생성 자체가 롤백된다.

각 사진 파일은 I/O가 발생한다. 한 요청에 파일 I/O가 10번이상 발생할 수 있으니 트랜잭션이 굉장히 길게 걸린다.

파일 I/O 후 경로와 같은 메타 데이터를 DB에 저장해야한다.

즉, 파일 I/O하는 서브 로직은 피드 생성이라는 본 로직과 강하게 결합되면 안된다는 결론이 나온다.

[고려한 방법]

다음과 같은 방법을 고려했었다.

스프링 트랜잭션 전파(Spring Transaction propagation) 레벨 활용

Spring의 Transaction propagtion을 활용하여서 피드 생성 트랜잭션과 파일 I/O 트랜잭션을 분리할 수 있다. Progation.REQUIRES_NEW를 이용하면 쉽게 분리할 수 있을 것이다.

하지만 이 방법은 단순히 트랜잭션만 분리한 방법이다. 즉, 두 로직의 결합도를 낮추지는 못한다.

이러한 문제의 일환으로 피드 생성 트랜잭션이 파일 I/O 트랜잭션과 강하게 결합되어있기 때문에 여전히 굉장히 오래 걸린다. 즉, 피드 생성 트랜잭션의 시간이 파일 I/O 트랜잭션에 영향을 받는 것이다.

[해결책]

그래서 생각한 방법은 Spring Event를 활용하는 것이었다. 피드를 생성하는 본 로직에서 특정 Event를 발행하고, EventListener에서 파일 I/O를 하는 방법이다.

다음은 내가 고민했던 부분이다. 여기서는 비동기 Event와 관련된 내용은 설명하지 않는다.

두 로직의 결합도 낮추기

처음에는 다음과 같이 이미지를 저장하는 이벤트인 FeedStepImageSaveEvent를 발생 시켰다.

이 로직은 EventListener에서 비동기로 쓰레드를 새로 생성해서 이미지 저장 로직을 수행하기 때문에 물리적인 의존도는 줄었다고 볼 수있다.

하지만 이미지 저장 로직의 정책이 바뀌어서 이벤트가 변경 되었을때, 피드 저장 로직의 이벤트도 함께 변경이 되어야한다. 어떤 일을 해야 하는 지를 메시지 발행자가 알려주는 경우(Command), 해야하는 일이 변경될 때 메시지 발행자와 수신자 양쪽 모두의 코드가 변경돼야 하기 때문에 높은 결합도가 존재하게 된다.

또한 이미지 저장 로직 자체를 발행하며 이미지 저장이라는 비즈니스 로직을 알고있으니 논리적으로도 결합이 느슨해졌다고 얘기할 수 없다. 즉, 물리적인 의존도는 줄었지만 개념적으로는 의존도가 높은 것이다.

메시지 발행 시 대상 도메인에게 기대하는 목적을 담았기 때문에 의존도가 남아있다. 대상 도메인에게 기대하는 목적을 담았다면, 이는 이벤트라 부르지 않는다고 한다. 이것은 이벤트 시스템을 활용한 비동기 요청이다.

이를 다음과 같이 수정했다.

대상 도메인에게 기대하는 목적을 담는게 아닌 피드 생성 이벤트 자체를 발생시킨다.

FeedCreateEvent를 listen하는 객체에서 이미지를 저장한다.

이렇게 하면 피드 생성이라는 본 로직과 파일 저장이라는 서브 로직의 결합도를 물리적, 논리적, 개념적으로 느슨하게 할 수 있다. 피드 생성 로직은 더 이상 파일 저장 로직에 영향을 받지 않는다.

[정리]

비즈니스 로직에서 분리되어야하는 부분이 있을 때 비동기 Event를 고민할 수 있다. 위 내용에서 EventListener 부분에서 Message Queue를 활용하면 시스템 자체를 분리할 수 있다.

[Spring] 커스텀한 multipart/form-data 요청 받기

Thu, 07 Mar 2024 00:00:00 GMT

[들어가며]

프로젝트를 진행하며 쉽지 않은 요구사항을 기술적으로 해결한 사례에 대해서 기록하고자 이 글을 쓰게 되었다.

[요구사항]

피드를 생성하는 API를 만들어야하는데 다음과 같은 특이한 요구사항이 있다.

요구사항을 정리하면 다음과 같다.

피드는 여러개의 단계를 가질 수 있다. 단계의 수는 가변적이다.

각 단계는 0~2개의 사진 파일을 가질 수 있다. 즉, 사진의 수도 가변적이다.

피드 생성에 필요한 다른 데이터는 json 형식으로 넘어온다.

위 요구사항을 하나의 API로 해결해야한다.

[고려한 방법들]

다음과 같은 방법들을 고려했었다.

API 분리

처음에는 이 정도로 큰 요청은 분리를 하는게 맞다고 생각했다. 애초에 API 설계가 잘못되었다는 생각이 들었고, 한번에 해결하기에는 너무 무거운 API라고 생각이 들었다. 그래서 다음과 같은 API 설계로 변경하려고 했다.

피드 생성에 필요한 다른 데이터를 통해 피드를 일단 생성하는 API. 이 요청에서는 사진 파일을 제외한 모든 피드를 생성한다.

생성된 피드의 각각의 단계에 0~2개의 사진 데이터를 받는 API. 이 요청은 각 단계마다 각각 받거나, 한번에 모두 받는 것 둘 다 고려했다.

이런 API는 다음과 같은 문제점을 가지고 있다.

완성되지 않은 피드를 생성한다.

2번 API를 각 단계마다 각각 사진 데이터를 받는 형식으로 사용하면, 하나의 피드를 생성하는데 여러번의 API 호출을 해야한다는 문제점이 있다. 만약 그 사이에 해당 피드에 접근하게 되면 완성되지 않은 피드를 사용자가 보게된다. 한번에 모두 받는 방식도 여전히 이러한 문제점이 발생할 여지가 있다.

어차피 무거운 요청인 것은 변하지 않는다.

2번 API를 각각의 단계에 해당하는 모든 사진을 한번에 받도록하면 원래 API랑 다를게 없다. 원래 API는 2번 API에 단순히 피드 생성에 필요한 json data만 더 받는 것이다. API의 크기의 차이가 아주 미미하다.

기존의 문제점을 해결하지 못하면서 오히려 다른 기술로 해결할 수 있는 여지를 없애는 방법이다.

`@RequestPart` 활용

@RequesetPart를 활용할 생각을 해봤지만 애초에 불가능하다. @RequestPart는 name으로 구분지어서 json data, 각 단계의 사진들을 받는다. 하지만 각 단계들이 가변적이다. 그래서 애초에 요청을 만들 수가 없다.

[해결]

요구사항 자체를 변경하거나, Spring에서 제공하는 file 매핑 기술을 사용하지 못한다. 그래서 요청을 다음과 같이 정의하고 Argument Resolver에서 Native한 Request를 받아서 직접 매핑해주기로 했다.

multipart/form-data는 name을 key(unique할 필요 없음) data를 value로 하는 테이블 형식과 비슷하다. 그래서 요청을 다음과 같이 받을 수 있다.

jsonData라는 name으로 피드 생성에 필요한 데이터를 받는다.

각 단계의 이름을 name으로 사진 파일을 받는다. name이 같을 경우 해당 단계의 다른 사진으로 인식하여 한 단계의 여러개의 사진을 받을 수 있다. 만약 0개의 사진을 가지고있는 단계의 경우(위 사진의 step2), 그냥 해당 단계를 name으로 가지는 열을 만들지 않으면 된다.

그리고 Arument Resolver에서 원하는 객체 형태로 매핑을 해주고, handler로 넘겨주면 된다.

FeedSaveArgumentResolver.java

실제로는 더 복잡하게 동작을 하지만 본 메소드는 위와 같다.

controller 부분은 다음과 같다.

FeedController.java

[정리]

요청 자체가 복잡한 API를 Argument Resolver에서 Native한 Request를 직접 만져서 해결할 수 있다. 요청이 복잡하더라도 겁먹지 말고 Argument Resolver를 적극 활용해보자.

JWT 토큰에 대해서 알아보자

Wed, 06 Dec 2023 00:00:00 GMT

[들어가며]

이번 프로젝트를 진행하면서 토큰을 이용한 인증/인가에서 jwt를 사용하게 되었다. 그 과정에서 알게된 jwt의 특성과 경험을 기록하기 위해 이 글을 쓰게 되었다.

[JWT란?]

JWT는 JSON Web Token의 줄임말로, 두 개체(ex -> 서버와 서버) 사이에 정보를 안전하게 전송하기 위한 토큰 인증 방법이다. 이는 RFC 7519에 정의 되어있고 토큰 인증 방식에서 많이 사용되는 방법이라고 볼 수 있다.

jwt가 안전한 이유는 jwt토큰 자체가 디지털 서명이 되어있기 때문이다. 비밀키를 알고있어야 jwt가 유효한지 알 수 있기 때문에 중간에 토큰이 오염이 되지 않았음을 보장할 수 있다.

[JWT 토큰 구조]

JWT는 Header, Payload, Signature로 나눠진다. 각각에 대해서 알아보자.

Header
- 헤더는 일반적으로 토큰 유형(JWT)과 사용 중인 서명 알고리즘 두 부분으로 구성된다. 토큰 전체의 메타 정보 같은 느낌으로 다른 정보가 추가적으로 들어갈 수 있다. 이 부분은 단순히 Base64Url을 사용해서 인코딩 되어있다. 그래서 어디서든지 디코딩이 가능하다. 그러므로 민감한 정보가 들어가면 안된다. jwt.io에서 헤더를 복호화 시켜보면 다음과 같다.
Payload
- 페이로드는 토큰의 두 번째 부분으로 클레임을 포함한다. 클레임은 엔티티(일반적으로 사용자) 및 추가 데이터에 대한 설명이다. 클레임에는 등록, 공개, 비공개 클레임 세 가지 유형이 있다. 보통 토큰이 발행한 주체(issuer), 토큰의 수신자(recipient), 토큰의 발행시간, 토큰의 만료시간 등이 포함된다.
- 등록된 클레임 : 등록된 클레임은 유용하게 클레임을 제공하기 위해 권장되는 클레임 집합이다. 필수는 아니지만 jwt 토큰을 유용하게 쓰려면 이 정도 클레임은 포함하라고 하는 권장 사항 정도이다. 구성 요소는 다음과 같다.
```
- iss: 토큰 발급자 (issuer)
- sub: 토큰 제목 (subject)
- aud: 토큰 대상자 (audience)
- exp: 토큰의 만료시간 (expiraton)
- nbf: Not Before 를 의미하며, 토큰의 활성 날짜와 비슷한 개념
- iat: 토큰이 발급된 시간 (issued at)
- jti: JWT의 고유 식별자로서, 주로 중복적인 처리를 방지를 위한 목적
```
- 공개 클레임 : JWT 사용자에 의해 정의될 수 있는 클레임의 집합이다. 충돌되지 않는 이름을 가지고 있어야하며, 이를 위해서 IANA JSON 웹 토큰 레지스트리에 정의하거나 충돌 방지 네임스페이스를 포함하는 URI로 정의해야 한다. 즉, JWT 사용자들 사이의 약속이다.
- 비공개 클레임 : 양 측간에 (보통 클라이언트 <->서버) 협의하에 사용되는 클레임 집합이다. 공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용할때에 유의해야한다. 토큰에서 제공할 추가적인 정보를 줄때 이용된다. payload 또한 Base64Url로 인코딩 되어있기 때문에 민감한 정보를 포함하면 안된다.
Signature
- 시그니처는 마지막 부분으로 디지털 서명을 담당한다. 이 서명은 헤더의 인코딩값과, 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬를 하여 생성합니다. 비밀키가 있어야만 이 부분을 풀 수 있으며, 비밀키는 서버에서 안전하게 보관되어야한다.

[JWT를 이용한 인증/인가 방식]

JWT를 이용한 인증/인가 방식에는 여러가지가 있지만 가장 일반적인 방식은 다음과 같다.

적절한 회원이 로그인 요청을 한다.

서버에서는 회원의 정보(id, password)가 적절한지 확인하고, 적절하다면 RefreshToken과 AccessToken을 발행한다.

로그인된 회원만 사용할 수 있는 API인 경우 Authentication Header에 AccessToken을 담아서 보낸다.

서버에서는 이 토큰이 유효한지 확인만 진행한다. 토큰 자체로 유효성 검사를 할 수 있기 때문에 DB를 가져온다는 등의 수고는 안해도 된다.

AccessToken 토큰이 만료되었을 경우 RefreshToken으로 재발행을 한다.

AccessToken이 만료되었을 경우, RefreshToken을 서버로 전달하여 AccessToken과 RefreshToken을 재발행한다. 만약 RefreshToken이 유효하다면 사용자는 토큰들을 재발행 받을 것이다.

이때, RefreshToken은 DB 시스템에 저장을 한다. RefreshToken은 단순히 유효함을 확인하는 것이 아니고 따로 저장을 해두어서 사용을 한다.

인증 방식은 Session 인증 방식과 비슷하다. 차이가 있다면 AccessToken을 활용함으로써 DB와 연결되는 네트워킹 횟수가 주는 것이다. 만약 유효하지 않다면 401을 던진다.

[CS] SHA-256 + Salt

Wed, 06 Dec 2023 00:00:00 GMT

[들어가며]

프로젝트를 진행하며 SHA-256 단방향 암호화를 진행하면서 발생하는 문제점을 인식하고 해결한 과정에 대해 기록하고자 이 글을 쓰게되었다.

[SHA-256이란?]

SHA-256은 SHA-2(Secure Hash Algorithm 2)의 한 형태로, 암호학적 해시 함수의 집합 중 하나이다. 여기서 256은 이 알고리즘이 생성하는 해시 값의 비트 길이이다. 암호학적 해시 함수란 임의의 크기를 입력 받아 그 길이의 고유한 문자열로 변환하는 함수이다. 암호학적 해시 함수는 다음과 같은 특징을 가지고 있다.

Preimage resistance (원상 저항성): 해시 결과(해시 값)로부터 원래의 입력 값을 찾아내는 것이 불가능하다. 즉, 해시 값만 가지고는 원래 데이터를 알아낼 수 없다.
Second preimage resistance (제2원상 저항성): 주어진 입력 값에 대해 동일한 해시 값을 생성하는 다른 입력 값을 찾아내는 것이 어렵다.
Collision resistance (충돌 저항성): 두 개의 임의의 다른 입력 값이 동일한 해시 값을 생성하는 것, 즉 충돌이 발생하는 것이 어렵다.

위의 특징 때문에 고유하고 안전해서 단방향 암호화에서 많이 사용된다. 하지만 SHA-256도 뚫릴 수 있는 가능성이 있다.

[SHA-256의 약점]

해시 함수는 어쩔 수 없이 동일한 입력에 대해 항상 동일한 출력을 생성한다. 즉, 누가 암호화하던 동일한 입력이라면 동일한 출력이라는 것이다. 이러한 약점을 활용해서 해커들은 SHA-256를 통해 생성된 해시 값을 따로 저장해두고, 일치하는 값을 확인한다. 이를 레인보우 테이블이라고 한다.

레인보우 테이블(Rainbow Table)

레인보우 테이블은 암호학적 해시 함수를 통해 생성된 해시 값을 역으로 추척해서 원래의 데이터(일반적으로 패스워드)를 찾아내기 위한 방법 중 하나이다.

레인보우 테이블은 미리 계산된 해시 값과 그에 해당하는 원래의 데이터를 대응시킨 테이블을 의미한다. 이 테이블은 많은 양의 디스크 공간을 차지하지만, 빠르게 해시 값을 '크래킹'할 수 있게 해준다.

사람이 하나하나 확인하는 것은 어렵지만 이를 컴퓨터로 진행한다면 금방 찾을 것이다. 그렇다면 이에 대한 대응책은 뭘까?

[대응책 - Salting]

솔팅(Salting)은 암호화된 정보, 특히 사용자의 비밀번호에 추가적인 무작위 데이터를 더하는 방식을 말한다. 이 추가적인 데이터는 '솔트(Salt)'라고 부르며, 해시 함수에 들어가는 입력값을 변경해 해시 결과를 달리하는 역할을 한다. 이렇게 되면 레인보우 테이블에 대한 공격을 거의 대부분 방어할 수 있다.

하지만 솔팅의 단점은 사용자에 대한 솔트를 서버가 가지고있어야한다. 즉, 서버는 암호화된 비밀번호와 솔트 모두 가져야한다. 그만큼 비용이 크다는 것이다.

솔팅은 패스워드의 보안성을 향상시키는 매우 좋은 방법이다. 하지만 당연하게도 솔팅만으로는 충분하지 않으며, 다른 보안 조치와 함께 사용한다. 예를 들어, 강력한 해시 알고리즘을 사용하거나, 해시를 여러 번 적용하는 등의 방법 등이 있다.

[우테코] 프리코스 4주차 회고

Mon, 20 Nov 2023 00:00:00 GMT

4주 차 온보딩 github

[들어가며]

이번주 미션은 처음 보는 형태의 미션이었다. 이메일 형태의 미션이어서 현업에서 개발자가 받을 수 있을 만한 내용의 메일이기도 하고, 내가 진짜 현업에서 일하고 있는 개발자가 된것 같은 기분이 들게 되는 미션이어서 매우 흥미로웠다. 이번 주의 목표는 저번주와 비슷한 클래스(객체)를 분리하는 연습을 조금 더 해보는 것이 었다. 저번주에 진행한 과제에서 생각해보면 단일 책임 원칙이나, 모듈화나 응집성을 높이지 못한것 같아 아쉬운 부분이 많았는데 이번 주도 같은 목표이다보니 더 연습해 볼 수 있어서 좋았던 것 같다. 미션을 받고 가장 먼저 한 일은 이번 주도 역시 3주차 공통 피드백을 확인했다.

[연관성이 있는 상수는 static final 대신 Enum을 활용한다.]

가장 먼저 눈에 들어온 것은 “연관성이 있는 상수는 static final 대신 Enum을 활용한다.”라는 내용이었다. 저번 주는 로또의 등수를 Enum을 활용했었는데, 이번 주 미션에서는 연관성이 있는 상수가 어떤게 있을지 고민해 보았다.

가장 먼저 떠오른 부분은 메뉴였다. 메뉴 Enum을 사용하여 메뉴와 가격을 관리하는 것은 가독성과 유지보수성을 향상시킬 수 있었고, 메뉴의 가격은 Enum 내부에서 적절하게 캡슐화되어 있어서, 외부에서 직접 변경이 어렵게 된다.

또 어떤 부분이 Enum으로 될 수 있을지 고민해 보았는데, Badge 와 ErrorMessage 부분을 만들어 보았다. 모두 값이 자주 변하지 않고, 연관성이 있다고 생각해서 만들었다. 만들어 보니 확실히 가독성이 많이 좋아지고, Enum은 클래스로 정의되기 때문에 내부에 작은 기능을 하는 메서드를 만들어 사용해 보니 단순한 상수 그룹 이상의 기능을 만들 수 있다고 느꼈다.

[테스트 코드도 코드다.]

다음 인상 깊었던 부분은 “테스트 코드도 코드다”라는 내용이었다. 테스트 코드가 중요하다는 말은 익히 들어서 알고 있었지만, 나는 우테코 이전에 테스트 코드를 작성해 보지 않았다.

일단 가장 큰 이유는 어떻게 작성해야할 지 감이 잡히지 않는 것이었다. 혼자 블로그나 강의를 보며 작성해봤지만, 쉽지 않았던 기억 때문에 습관이 안된것 같다. 하지만 우테코 프리코스를 시작한 이후로 테스트 코드를 작성해보고, 확실히 많은 것을 느낄 수 있었다.

가장 좋은 점은 테스트 코드를 작성 후에 코드 리팩토링을 하다보면 거침 없이 할 수 있다는것이다. 전에 테스트 코드를 작성하지 않고, 리팩토링을 진행 할 때는 코드를 작성하면서 많이 망설이던 모습이 떠오른다. 이걸 고쳤다가 안되면 어떡하지? 라는 생각을 가장 많이 했던 것같다.

하지만 지금은 테스트 코드를 작성 하다보니, 확실히 코드에 문제가 있더라도 어떤 부분에서 문제가 생겼는지, 빠르게 알아차릴 수 있고, 더 나아가 유지보수성이 많이 좋아진다고 느낀다. 돌아와서 “테스트 코드도 코드다.” 부분에서는 테스트 코드의 리펙토링의 중요성을 보여주고 있었다. 특히 이번 주도 저번 주에 공부 했던 @ParameterizedTest 와 @ValueSource 를 사용해서 단순히 파라미터의 값만 바뀌는 경우를 처리해 주려고 노력했고, 가독성이 좋은 테스트코드를 작성하기 위해 노력했는데, 아직 많이 어려운것 같아 꾸준한 연습이 필요할 것 같다.

[단위 테스트하기 어려운 코드를 단위 테스트하기]

이번에 Order라는 클래스를 생성하면서 createOrder 메서드를 테스트하려고 했는데 InputView.getOrder()와 printPreviewPhrase를 직접 호출 하고, 테스트 불가능한 정적 메서드 호출로 인해 단위 테스트가 쉽지않았었다.

리팩토링하여 createOrder 메서드가 외부 의존성을 직접적으로 호출하지 않게 되었고, 대신, createOrderItems 내에서 필요한 의존성을 주입받아 사용하도록 바꿨다. 입력 및 출력 동작은 InputView와 OutputView에 캡슐화되어 있고, 테스트에서는 이를 Mock으로 대체하여 특정 입력값과 출력값을 쉽게 테스트할 수 있게 바꿨다.

주문 생성 및 관련된 동작들이 각자의 클래스에 모듈화 했기 때문에, 특정 기능을 수정할 때 다른 부분에 영향을 미치지 않도록 하였고, 안전하게 변경할 수 있게 되었다. 특히, createOrderItems 메서드에서 OrderItem 클래스를 사용하여 주문 항목을 캡슐화 하면서 유닛 테스트가 더 쉬워질 수 있었다.

정적 메서드 사용을 최소화하고 의존성 주입을 통해 테스트 가능한 코드를 작성하는 중요성을 깨닫게 되었고, 코드의 신뢰성을 향상시키고 유지 보수를 용이하게 만들기 위해 코드를 작성할 때부터 테스트 가능성을 고려하는 것이 중요하다고 생각된다.

[클래스(객체)를 분리하는 연습]

저번주 미션에서도 클래스를 분리하여 비지니스 로직과 UI로직을 분리해서 코드를 작성했지만, 이번주는 더 작게 나누려고 노력해봤다 출력을 담당하는 OutputView 에서 주문 정보를 출력하는 OrderOutputPrinter와 할인 정보를 출력하는 DiscountOutputPrinter로 나누어 주었고, Order 클래스에서 메뉴 이름과, 수량을 담는 OrderItem 클래스도 나누려고 노력했다.

다른 클래스들도 최대한 단일 책임원칙에 맞게 분리하려고 노력했다. 클래스를 분리함으로써 각 클래스는 자체적인 역할을 수행하게 되어 응집도가 높아졌고, 각 클래스는 특정 기능이나 역할을 담당하므로 코드를 이해하고 유지보수하기가 훨씬 쉬워진것 같았다.

또 단위테스트를 작성하면서 각 클래스는 독립적으로 테스트할 수 있기 때문에 특정 기능에 대한 테스트 케이스를 간편하게 작성 할 수 있었다. 하지만 클래스를 분리하면 각 클래스 간의 의존성을 적절히 관리해야 할 것 같았다. 너무 많은 의존성이 발생하면 결합도가 높아져서 코드 변경이 어려워질 것 같고, 처음에 많은 시간이 소요 되서 많은 연습이 필요할 것 같다.

[프리코스 4주 후 느낀점]

프리코스를 진행하며, 내가 부족한 부분에 대해서 더 자세히 알게된 것 같다. 지금까지 개발을 공부 하면서 이런 온보딩 형식의 미션을 접할 기회가 많이 없어서 처음에는 어색하기도 하고, 어려움을 많이 느꼈지만 이제는 “이런식으로 공부하면 정말 빠르게 성장 할 수 있겠구나!” 라는 생각이 든다.

정말 재미있게 몰입할 수 있었고, 타 교육을 진행한 5개월 보다 많은 양을 배울 수 있었던 시간이었다고 확실히 알 수 있었다. 프리코스를 진행하면서 우테코 본 과정에서는 얼마나 많은걸 배울 수 있을까? 라는 생각과 함께 우테코에 대한 열망이 더 많이 생겼다.

이후 목표

- TDD의 가치를 더 깊이 이해하고, 새로운 기능을 추가하거나 기존 코드를 리팩토링할 때 테스트 코드를 우선 작성하도록 연습해야한다. 이를 통해 안정적이고 견고한 코드를 작성하는 습관을 들여야한다.
- 코드의 가독성과 유지보수성을 높이기 위해 꾸준한 노력을 기울여야한다. 가독성이 좋고 간결한 코드 작성을 위해 코드 리뷰와 연습 통해 더 많은 클린 코드 습관을 습득하고 적용해야 한다.
- 객체지향 프로그래밍의 원칙과 패턴에 대한 학습을 지속하고, 실제 프로젝트에서 이를 적용해보려고 한다. 클래스 설계와 객체 간의 관계를 더욱 효과적으로 다루기 위해 노력하여 코드의 유연성과 확장성을 향상 시켜야한다.
- 블로깅을 통해 지식을 공유하며 함께 성장하는 기회를 더욱 많이 찾아봐야한다. 다양한 의견, 경험을 공유하고, 다른 개발자들과 소통하며 성장의 기반을 다지려고한다.

[우테코] 프리코스 3주차 회고

Fri, 10 Nov 2023 00:00:00 GMT

3주 차 온보딩 github

[들어가며]

처음 과제를 진행할 때 저번주에 진행했던 레이싱 게임에 비해서 확실히 난이도가 상승했다고 생각했다. 요구사항들이 꽤 추가 되어 있었고, 당연히 구현은 더 오랜시간이 걸렸다.저번주와 마찬가지로 테스트 코드를 미리 작성하는 TDD 방식은 아직 익숙 하지 않아 꾸준한 노력이 필요하다고 생각한다. 가장 먼저 피드백으로 제공해주신 내용을 확인하면서, 학습테스트를 통해 JUnit 학습하기 문서를 가장 먼저 읽어 보았고, 메일서 목표로 주어진 내용인 테스트코드와 리팩토링을 중점적으로 연습하려고 노력했다.

[도메인 로직에 대한 단위 테스트를 작성하는 연습]

가장 먼저 단위테스트를 작성하는 연습을 하기 위해서는 도메인 로직에 대한 단위 테스트가 무엇인지 파악하는게 먼저였다. 구글링과 GPT에 질문해보면서 어떤 내용의 테스트 인지 파악해본 결과 특정 함수, 또는 클래스와 같은 도메인 로직의 작은 부분에 대해 수행되는 테스트라는 설명이 많았다. 피드백과 함께 제공된 문서를 보며 String 클래스에 대해서 먼저 작성해보려고 나는 문자열 정수를 받았을 때 “,”로 split하고 List로 바꿔 주는 클래스를 만들어서 처음에는 assertEquals 로 비교해서 맞는지 검증해보았다.

테스트 작성 연습을 위해 검증을 해보면서 assertEquals , containsExactly, contains 차이에 대해서 이해하는데 많은 도움을 받았고, 더불어 Set Collection에 대한 테스트 공부를 하면서 진행했던 @ParameterizedTest를 사용하면서 @ValueSource를 함께 사용하면서 코드를 제거하고 한번에 많은 케이스를 테스트하는 과정에서 처음 사용해 보았는데 많은 도움이 되었다. @ValueSource에 대해서 알게된점은 매번 배열의 인수 하나를 메서드 매개 변수에 할당 한다. 예를 들어 @ValueSource(strings = { "500", "0" }) 이 경우 총 2번 전달한다. 또 short,byte,int,long,float,double,char,String,Class 유형만 전달할 수 있었고, 매번 테스트 메서드에 하나의 인수만 전달할 수 있었다. null을 인수로 전달할 수 없다는 정보도 알게 되었다. null을 인수로 전달 받기 위해서는 ValueSource가 아닌 NullSource를 이용해서 단일 null값을 전달 할 수 있다. 기본 데이터 유형의 경우는 null을 전달 받을 수 없기 때문에 EmptySource을 사용하여 빈 값을 전달 할 수 있다고 한다.

많은 정보를 Guide to JUnit 5 Parameterized Tests 문서를 통해 알게 되었고, 더 많은 내용을 테스트 코드에 직접 적용해보기 위해 더 많은 공부가 필요하다고 느꼈다. 또 다른 테스트들을 진행하면서 수익률 계산에 맞지 않는 경우가 있어서 확인 해보니, 내 처음 코드에서는 총 상금에서 로또의 구입금액까지 빼고있어서 오류가 발생한 부분이 있었다. 단위 테스트로 작게 만들다 보니 작은 기능에서 문제가 생겼을 때 빠른 피드백을 받을 수 있었고, 어떤 기능에 문제가 생겼는지 한번에 알아보기가 편해진 것 같았다. 또 리팩토링을 진행하면서 한번 진행할 때 마다 한번씩 테스트 케이스가 정상적으로 통과하는지 확인하다보니 리팩토링중에도 오류가 발생하거나 원하는 결과가 나오지 않았을 때 테스트 코드로 인해 더 빠른 리팩토링을 경험 할 수 있었다.

[클래스(객체)를 분리하는 연습]

확실히 저번 주 미션에서도 진행했던 부분이어서 어떤식으로 분리하고 메서드를 줄일 수 있을지 생각하면서 코드를 작성하다 보니, 처음부터 작은 메서드를 만들려고 노력하고 있는 나를 확인 할 수 있었다. 그래도 구현을 마치고 보니 많은 요구사항에 맞지않는 코드들이 너무 많았고, 최대한 더 읽기 편하고 메서드가 하나의 기능만 수행하도록 만들고 싶었는데, 생각보다 어려운 부분이 많았다.

특히 예외 처리 부분에서 재입력을 받다보니 while문 안에 try-catch문까지 들어가니까 정말 보기 힘들었다. 그래서 예외처리 메서드를 최대한 나누고 do-while문에서 예외처리메서드 안에 인수를 넣어서 보기 좋게 바꾸려고 노력했다. 상수 부분에서도 아직 어떤 부분을 상수로 만들어야 할지 감이 잘 잡히진않는다. 하지만 가장 많이 사용되고 있다고 느끼는 로또의 가격부분과 로또의 1~45 부분, 로또 숫자의 개수를 상수로 처리 해줬는데 확실히 가독성이 좋아졌고, 어떤 숫자인지 내 코드를 처음보는 사람도 알 수 있었다면 좋겠다는 생각으로 진행했다. 확실히 1주차 보다는 코드가 많이 좋아졌다고 느끼는데 공부하다보면 아직 많이 부족하고, 배울게 정말 많다고 느껴진다. 더 노력하는 4주차가 되었으면 좋겠다.

[개선 해야 할 점]

확실히 테스트 코드작성을 프리코스에서 처음 진행하다보니 나 스스로도 아직 많이 부족함이 느껴진다. 이번주 피드백에서 주어진 테스트 코드 학습 문서를 통해 조금 더 테스트 코드에 대해서 공부해봐야 할 것 같고, 리팩토링에서 메서드 분리나 클래스 분리도 어떻게 해야 좋은 코드가 될지 고민 해봐야한다. 4주차는 조금 더 성장한 코드를 작성 했으면 좋겠다.

[우테코] 프리코스 2주차 회고

Thu, 02 Nov 2023 00:00:00 GMT

2주 차 온보딩 github

[들어가며]

저번주 1주차 과제를 제출 후, 많은 후회가 몰려왔다.

가장 먼저 우테코에서 제시한 2가지의 테스트는 통과할 수 있었다. 하지만 하나의 숫자의 힌트를 얻을 경우 하나의 볼 또는 스트라이크가 출력돼야 한다고 되어 있지만 내 코드에서는 볼과 스트라이크가 하나만 있어도 0 볼, 0 스트라이크와 같이 힌트가 필요하지 않은 부분도 함께 출력된다.

미션 요구사항도 제대로 읽지 않고, 클린코드나 리펙토링, 테스트코드에 관심이 집중되어 있던 모습이 정말 바보같이 느껴지는 하루였다. 이번 프리코스를 포기해야 하나 고민도 해봤지만 아직 남은 프리코스 미션과 시간이 남아있었기도 하였고,

정말 우테코가 정말 간절하기에 계속 진행해 보기로 했다. 진행하며 2주차 미션부터는 요구사항에 대해 더 명확히 분석해야겠다는 다짐을 하게 된 경험이었다.

[미션을 진행하기 전 가장 먼저 한 일]

일단 저번 미션도 그랬지만 역시 처음 해보는 내용이었다. 저번주 반성 내용을 상기하며, 가장 먼저 한 일은 1주차 공통 피드백을 읽어보며 내가 어떻게 흡수해야 할지 생각해 보는 시간을 가졌다.

같은 실수를 반복하지 않기 위해 README에 적혀있는 요구사항을 빠짐없이 체크하려고 노력했다. 그리고 야구게임에 대해 더 고민해보고 싶어 숫자 야구 피드백강의를 시청하였다.

시청하면서 클래스 변수, 인스턴스 변수, 상수에 대해서도 조금 더 쉽게 이해할 수 있었고, 멀게만 느껴졌던 객체지향 프로그래밍에 조금 가까워질 수 있었다.

[테스트 코드 작성]

이번주차의 목표는 함수를 분리하고, 각 함수별로 테스트를 작성하는 것이라고 한다. 가장 먼저 아직 테스트코드를 작성해 본 적이 없어서 메일에 안내되어 있는 대로 StringTest를 확인하였다.

하지만 문제가 StringTest 코드를 봐도 완전히 이해하긴 어려웠다. 그래서 구글링, gpt를 통해 테스트코드에 대해서 공부를 진행했다. 테스트 코드를 먼저 작성하고 그다음에 실제 코드를 작성하는 개발 방법인 TDD로 코드를 작성해야 하나 고민해봤지만, 아직 테스트 코드도 작성하지 못하는데 먼저 작성한다는 일은 막막하다는 느낌이 들어서 기능 구현을 먼저 하고, 테스트 코드를 작성해 보았다.

완전한 테스트코드를 작성한 것은 아니지만 내가 할 수 있는 선에서 작성하도록 노력해 보았다. private 메서드를 테스트할 때 오류가 발생하여 public 으로 메서드를 변경하려고 했는데 그것은 권장하지 않는 방법이라고 한다. 그래서 Wrapper 클래스를 만들어 캡슐화하여 테스트를 진행하게 되었다. Wrapper 클래스를 통해 유지보수성이 좋아졌고, 결합도도 낮아졌다고 느낄 수 있었고, mock 객체를 사용해서 테스트도 할 수 있었다.

[메서드 분리]

이번 미션에서는 1주차 미션에서 적용하지 못했던 MVC패턴을 적용해 보았다. 가장 먼저 controller, model, view 3개의 디렉터리를 생성 후 클래스를 알맞게 만들려고 힘썼다. 그리고 메서드 분리도 최대한 진행해 보면서 메서드 1개에 하나의 작업만 하도록 만들려고 노력해 봤는데, 1주차에 비해 확실히 더 쉽게 나눌 수 있었다.

아직 익숙하진 않았지만 확실히 적용하면서, 각 구성 요소가 독립적으로 동작하기 때문에 각 부분을 수정하거나 확장할 때 더 편했고, 가독성이 많이 좋아진다는 걸 느낄 수 있었다.

[커밋 메시지를 의미 있게 작성하기]

커밋 메시지는 지금까지 헤더만 작성하는 버릇이 있었는데 우테코에서 제공된 커밋 메시지 컨벤션문서를 확인하고 조금 더 의미 있는 커밋메시지를 작성하려고 노력하였다. 기능별로 커밋하면서 어떤 메서드인지 작성하는 노력 하면서 동시에 리팩토링을 진행할 때는 왜 이렇게 바꾸었는지 고민하면서 커밋메시지를 작성하려고 노력하였다.

아직 익숙하진 않지만 계속 컨벤션을 유지하면 협업이나 누군가 내 코드를 볼 때 확실히 도움 받을 수 있을 거라고 생각한다.

[부족하다고 생각하는 점]

일단 테스트 코드가 매우 중요하다고 생각하는데, 이번주 미션에선 아직 TDD방법론을 적용해보진 못했다.

다음 주 미션 때는 적용하기 위해 기능별 테스트코드를 먼저 작성 후 기능에 맞게 동작하는지 확인하면서 코드를 작성해보려고 한다. 그러기 위해서는 확실히 테스트 코드 작성법에 대해서 더 공부해야겠다고 느꼈고, 다음 주는 시간 분배를 조금 더 신경 써서 해야겠다고 생각했다.

[우테코] 프리코스 1주차 회고

Wed, 25 Oct 2023 00:00:00 GMT

1주 차 온보딩 github

[시작하면서]

프리코스 1주 차 온보딩 미션을 진행하면서 느꼈던 부분과 클린 코드 문서를 통해 배웠던 부분을 회고해보려고 한다.

[클린 코드]

부끄럽지만 난 지금까지 개발을 공부하면서 클린코드를 진행한 적이 없다. 처음 알게 된 건 우테코 디스코드 커뮤니티에서 한 지원자분께서 클린코드에 대한 내용을 올려주셨었는데 우테코 PR전 체크리스트라는 github문서였다.

그 문서에는 PR전에 자신의 코드가 클린코드적용이 되어있는지 체크리스트들이 적혀있었는데, 대부분 내가 개발을 진행하면서 처음 접하는 내용들이었다. 코드 작성 전 가장 먼저 코드컨벤션부터 맞추고 진행하였다.

난 문서에서 제시하는 Google Java 코드 컨벤션을 적용하였고, 커밋 전 자동으로 컨벤션을 맞춰주는 플러그인을 설치해서 적용하였다. 문서를 읽으며 가장 궁금했던 부분은 else예약어 부분이었다. 항상 if문을 사용하면 무조건 else도 함께 사용해 왔는데 어떻게 사용하지 않고 작성할 수 있지? 궁금증이 생겨 여러 블로그 글이나 GPT에게 질문해 보며 찾아보았다.

빠른 반환 - number를 조건에 만족하는 즉시 반환되어 중복된 else 문을 사용하지 않을 수 있다.

public class Main {
    public static String checkNumber(int number) {
        if (number > 0) {
            return "양수입니다.";
        }
        if (number < 0) {
            return "음수입니다.";
        }
        return "0입니다.";
    }

    public static void main(String[] args) {
        int number = 5;
        String result = checkNumber(number);
        System.out.println(result);
    }
}

조건부 표현식 - "(조건) ? 참일때의 값 : 거짓일때의 값" 형태로 작성되며, 여기서 중첩된 조건을 간결하게 표현할 수 있다.

public class Main {
    public static String checkNumber(int number) {
        return (number > 0) ? "양수입니다." : ((number < 0) ? "음수입니다." : "0입니다.");
    }

    public static void main(String[] args) {
        int number = 5;
        String result = checkNumber(number);
        System.out.println(result);
    }
}

[테스트 코드]

개발을 공부해보면서 직접 내가 어떤 예외가 발생할지 고민해 보며, 처음으로 작성해 보았다. 어떤 테스트가 적당할지 고민해 봤지만 예외가 발생할 수 있다고 생각되는 부분에서 테스트하기로 하였다.

가장 예외가 발생할 것이라고 생각되는 부분은 사용자의 입력이 올바르지 않을 때였다. 사용자가 게임을 시작하면 입력할 수 있는 건 1~9 범위의 서로 다른 3가지 수밖에 없다. 가장 먼저 3가지 이상의 수를 입력했을 때, 1~9 범위를 벗어났을 때, 중복된 숫자가 있을 때, 숫자가 아닌 다른 문자를 입력했을 때 이렇게 4가지 변수를 생각하고 IllegalArgumentException를 이용해 예외처리를 해주었다. 마찬가지로 게임 재시작 부분에서 1,2가 아닌 다른 수나, 문자를 입력하는 부분도 같은 방법으로 예외 처리를 진행했고, 우테코 초기 테스트에 추가로 내가 부족하다고 느낀 부분을 추가해서 테스트를 진행했다.

하지만 테스트 코드를 제대로 작성해 본 적이 없어서 가독성을 생각하지 못해서 given-when-then을 분리해서 작성하지 못했고, 더 많은 테스트케이스를 생각해내지 못했다. 2주 차부터는 이번주보다 부족하다고 생각되는 부분을 보완하려고 한다.

[마무리]

난 항상 개발을 해올 때 프로그램이 큰 문제없이 돌아가기만 한다면 크게 코드의 재사용성이나 가독성에 대해서 생각해 본 적은 없었다. 하지만 정말 큰 착각이었다.

이번 주를 진행하면서 전에 생각도 해보지 못한 코드의 가독성이나 코드의 재사용성을 높일 수 있는 클린코드에 대한 부분과 테스트 코드의 중요성을 깨닫게 된 것 같다. 확실히 프리코스 전보다 많이 성장한 게 느껴지지만, 아직 부족하다고 생각되는 부분이 너무나도 많다.

다음 주 미션부터는 더 좋은 코드를 만들기 위해 클린코드 진행을 조금 더 확실히 해야겠다는 생각과 테스트코드에서의 given-when-then을 분리한다던가 더 많은 테스트 케이스를 작성해 보고 싶다고 생각한다.

해시 테이블(Hash Table)

Wed, 02 Aug 2023 00:00:00 GMT

해시 테이블(Hash Table)이란?

데이터를 저장하고 검색하는 데 사용되는 자료구조 중 하나. 특히, 데이터를 효율적으로 검색할 수 있도록 설계되어 있다. 해시 테이블은 '해시 함수'라는 함수를 사용하여 데이터를 배열의 인덱스로 변환하고, 해당 인덱스에 데이터를 저장한다.

해시 함수는 데이터의 특정 특성을 활용하여 고유한 해시 값(해시 코드 또는 해시 키)을 생성하는 역할을 한다. 이렇게 생성된 해시 값은 배열의 인덱스로 사용되어 데이터가 해시 테이블 내 어느 위치에 저장되어야 할지를 결정한다.

일반적으로 해시 함수는 입력 데이터와 출력 해시 값의 길이가 다르더라도, 동일한 입력에 대해 항상 동일한 해시 값을 반환해야 한다. 이렇게 해시 함수를 설계함으로써 해시 충돌을 최소화 할 수 있다.

https://velog.io/@syoung125/해시테이블이란

해시 테이블의 특징

빠른 검색과 삽입 : 해시 함수를 사용하여 데이터를 빠르게 찾고 삽입할 수 있다. 평균적으로 O(1)의 시간 복잡도로 검색과 삽입이 가능
해시 충돌 : 서로 다른 데이터가 같은 해시 값으로 매핑될 수 있는데, 이를 해시 충돌이라고 한다. 충돌이 발생하는 경우에 대처할 수 있는 방법들이 있는데, 가장 일반적인 방법은 해시 테이블의 각 버킷에 연결 리스트를 사용하여 충돌이 발생한 데이터를 연결하는 것이다.
공간 효율성 : 해시 테이블은 적은 메모리 공간으로 많은 데이터를 효율적으로 관리할 수 있다.
해시 함수의 선택 : 해시 함수의 선택은 해시 테이블의 성능에 큰 영향을 준다. 좋은 해시 함수는 데이터를 가능한 한 균일하게 해시 테이블에 분배하여 충돌을 최소화해야 한다.

맵 (Map)

Tue, 01 Aug 2023 00:00:00 GMT

맵(Map)이란?

맵은 특정 순서에 따라 키와 매핑된 값의 조합으로 형성된 자료구조이다. 맵은 키-값 쌍의 집합으로, 특정 키를 통해 연결된 값을 검색하고 저장하는 데 사용된다.

https://blog.naver.com/kkkths/221755894067

맵의 특징

유일한 키(Key) : 하나의 키는 맵 내에서 유일해야 합니다. 중복된 키를 허용하지 않는다.
효율적인 검색 : 키를 사용하여 값을 검색하는 과정이 빠르고 효율적이어야 한다. 맵은 일반적으로 해시 테이블(hash table) 등을 이용하여 빠른 검색을 지원
동적 크기 조정 : 맵은 동적으로 크기를 조정하여 새로운 key-value 쌍을 추가하거나 기존 키-값 쌍을 삭제할 수 있어야 한다.
순서 보장 여부 : 일부 맵 구현은 삽입된 순서를 보장하여 데이터를 저장하지만, 다른 구현은 순서를 보장하지 않을 수 있다. 언어 또는 라이브러리에 따라 다를 수 있다.

맵 자료구조는 다양한 프로그래밍 시나리오에서 사용된다. 예를 들어, 데이터베이스 결과를 처리하거나, 카운팅 및 집계 작업, 키워드 검색, 캐시 관리 등에 유용하다.

자바에서 맵 구현

자바에서의 맵 사용 예를 들어보려고 한다.

import java.util.HashMap;
import java.util.Map;

public class ExampleHashMap {
    public static void main(String[] args) {
        // HashMap 생성과 값 추가
        Map<String, Integer> myMap = new HashMap<>();
        myMap.put("apple", 1);
        myMap.put("banana", 2);
        myMap.put("orange", 3);

        // 값 접근
        int appleValue = myMap.get("apple");
        System.out.println("Apple: " + appleValue); // 출력: Apple: 1

        // 값 수정
        myMap.put("banana", 5);

        // 새로운 값 추가
        myMap.put("grape", 4);

        // 특정 키가 맵에 있는지 확인
        if (myMap.containsKey("orange")) {
            System.out.println("Orange exists!");
        }

        // 키-값 쌍 순회
        for (Map.Entry<String, Integer> entry : myMap.entrySet()) {
            String key = entry.getKey();
            int value = entry.getValue();
            System.out.println(key + ": " + value);
        }

        // 키 목록 가져오기
        // (Java 8 이상에서는 keySet() 메서드를 사용하면 더 간단하게 처리 가능)
        for (String key : myMap.keySet()) {
            System.out.println("Key: " + key);
        }

        // 값 목록 가져오기
        for (int value : myMap.values()) {
            System.out.println("Value: " + value);
        }

        // 특정 키 삭제
        myMap.remove("apple");
    }
}

위 예시에서 HashMap을 이용하여 맵을 생성하고, put 메서드를 사용하여 키-값 쌍을 추가하고 수정, get 메서드를 사용하여 특정 키에 대응하는 값을 가져온다. containsKey 메서드로 특정 키가 맵에 있는지 확인, entrySet, keySet, values 메서드를 통해 맵의 키-값 쌍, 키 목록, 값 목록을 순회할 수 있다. 마지막엔 remove 메서드를 사용하여 특정 키를 삭제하는 것을 확인할 수 있다.

우선순위 큐 (Priority Queue)

Tue, 01 Aug 2023 00:00:00 GMT

우선순위 큐란?

각 요소들이 각각의 우선 순위를 갖고있고, 요소들의 대기열에서 '우선 순위가 높은 요소'가 '우선 순위가 낮은 요소'보다 먼저 제공되는 자료구조다. 힙을 기반으로 구현되나 힙과는 다른 개념이다.

힙은 기본적으로 중점이 되는 것이 '최솟값 또는 최댓값 빠르게 찾기'인 반면, 우선순위 큐는 우선순위가 높은 순서대로 요소를 제공받는다.

기본적으로 큐와 유사한 형태를 가지고 있으며, 다만 큐는 데이터가 들어온 순서대로 처리되지만, 우선순위 큐는 우선순위가 높은 데이터가 먼저 처리됩니다. 우선순위 큐는 최댓값이나 최솟값을 빠르게 찾아내는데 유용하게 사용됩니다.

면접을 위한 CS 전공지식 노트

우선순위 큐의 연산

삽입(Insertion): 요소를 우선순위에 맞게 삽입
삭제(Deletion): 우선순위가 가장 높은(또는 낮은) 요소를 삭제
최댓값 또는 최솟값 확인(Peek): 우선순위가 가장 높은(또는 낮은) 요소를 반환하지만 삭제하지는 않는다.

우선순위 큐 알고리즘은 삽입과 삭제 연산 시에 이진 힙의 성질을 유지하는 것이 중요하다. 이진 힙의 성질을 유지하지 않으면 올바른 우선순위 큐로 동작하지 않을 가능성이 있다.

우선순위 큐의 활용

작업 스케줄링(Job Scheduling): 우선순위가 높은 작업을 먼저 처리하기 위해 사용
힙 정렬(Heap Sort): 우선순위 큐를 활용하여 정렬을 수행하는 정렬 알고리즘
Huffman 코딩: 데이터 압축 알고리즘에서 사용되는 특별한 형태의 우선순위 큐

큐 (Queue)

Tue, 01 Aug 2023 00:00:00 GMT

들어가며

큐(Queue)는 데이터를 임시로 저장하고 처리하는 자료구조 중 하나입니다. 이는 데이터를 선입선출(First-In-First-Out, FIFO)의 순서로 다루는 구조이며, 스택과는 반대되는 개념을 가지고 있다. 삽입 및 삭제에 O(1) , 탐색에 O(n)이 걸린다.

큐는 일상 생활에서 줄 서기와 유사한 개념으로 이해할 수 있습니다. 가장 먼저 온 사람이 먼저 서비스를 받는 것과 같이, 큐에 추가된 데이터도 가장 먼저 처리되어 나옵니다. CPU작업을 기다리는 프로세스, 스레드 행렬, 네트워크 접속을 기다리는 행렬, 너비 우선 탐색, 캐시도 같은 개념이다.

https://st-lab.tistory.com/183

트랜잭션과 무결성

Mon, 24 Jul 2023 00:00:00 GMT

들어가며

트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적 기능을 수행하기 위한 작업의 단위를 말하며, 데이터베이스에 접근하는 방법은 쿼리이므로, 즉 여러 개의 쿼리들을 하나로 묶는 단위를 말한다. 트랜잭션은 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 그리고 지속성(Durability) 이라는 특성을 갖는다. 이 네 가지 특성은 트랜잭션의 안전성과 무결성을 보장하는데 중요한 역할을 한다.

트랜잭션의 흐름

트랜잭션 시작 (BEGIN 또는 START TRANSACTION 명령)
데이터베이스 작업 수행 (SELECT, INSERT, UPDATE, DELETE 등)
모든 작업이 성공적으로 수행되면 커밋 (COMMIT 명령으로 트랜잭션 완료)
오류 또는 중단이 발생하면 롤백 (ROLLBACK 명령으로 트랜잭션 취소)

원자성(Atomicity)

트랜잭션은 작업의 모든 단계가 완벽하게 수행되거나 전혀 수행되지 않아야 한다. 예를 들어 트랜잭션을 커밋했는데, 문제가 발생하여 롤백하는 경우 그 이후에 모두 수행되지 않음을 보장하는 것을 말한다. 하나의 원자적인 단위로 묶여있기 때문에 중간 단계의 실패로 인해 데이터베이스가 비일관성 상태에 빠지는 것을 방지한다.

커밋과 롤백(Commit, Roll back)

커밋은 트랜잭션이 성공적으로 완료되어 데이터베이스에 수행한 모든 작업들이 영구적으로 저장되도록 하는 명령이다. 즉, 커밋 명령을 실행하면 트랜잭션 내의 모든 데이터베이스 작업들이 데이터베이스에 반영되고, 이후에는 해당 트랜잭션에서 수행한 변경 사항이 영구적으로 유지된다. 커밋 이후에는 데이터베이스는 일관성을 유지하며, 다른 트랜잭션들도 해당 변경 사항을 볼 수 있게 된다.

커밋

위 그림처럼 update,insert,delete의 쿼리가 하나의 트랜잭션 단위로 수행되고 이후에 데이터 베이스에 영구 저장된다.

롤백은 트랜잭션을 취소하고 트랜잭션 이전의 상태로 되돌리는 명령이다. 즉, 트랜잭션 내에서 오류가 발생하거나 트랜잭션을 중단해야 하는 경우 롤백 명령을 실행하여 이전 상태로 데이터베이스를 되돌린다. 롤백을 실행하면 트랜잭션에서 수행한 모든 변경 사항들이 취소되고, 데이터베이스는 트랜잭션 이전의 상태로 돌아간다. 이후에는 해당 트랜잭션에서 수행한 작업들이 데이터베이스에 영향을 미치지 않은 것처럼 보인다.

롤백

이러한 커밋과 롤백으로 데이터의 무결성이 보장되고, 데이터 변경 전에 변경사항을 쉽게 확인할 수 있고 해당 작업을 그룹화할 수 있다.

트랜잭션 전파

트랜젝션을 수행할 때 커넥션 단위로 수행하기 때문에 커넥션 객체를 넘겨서 수행해야 한다. 하지만 이를 매번 넘겨주기가 어렵기도 하고 귀찮기도 하다. 이를 넘겨서 수행하지 않고 여러 트랜잭션 관련 메서드의 호출을 하나의 트랜잭션에 묶이도록 하는 것을 트랜잭션 전파라고 한다.

@Service 
@Transactional(readOnly = true) 
public class MemberService {
    private final MemberRepository memberRepository;

    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
}

위 코드처럼 @Transactional 애너테이션을 통해 여러 쿼리 관련 코드들을 하나의 트랜잭션으로 처리한다.

일관성(Consistency)

트랜잭션의 시작 전과 끝난 후에도 데이터베이스는 일관된 상태를 유지해야 한다. 즉, 트랜잭션이 실행되기 전과 후에 정의된 규칙과 제약 조건, 허용된 방식을 만족해야 한다. 트랜잭션이 성공적으로 완료된 경우 데이터베이스의 상태가 항상 일관성을 유지해야 한다.

격리성(Isolation)

여러 개의 트랜잭션이 동시에 실행될 때, 각 트랜잭션은 다른 트랜잭션들로부터 독립적으로 수행되는 것처럼 보이도록 격리되어야 한다. 즉, 하나의 트랜잭션이 다른 트랜잭션의 영향을 받지 않고, 서로 간섭하지 않도록 보장해야 한다. 이를 통해 트랜잭션들이 동시에 실행될 때 발생할 수 있는 문제들을 방지하고 데이터 일관성을 보장한다.

격리수준

격리 수준은 SERIALIABLE, REPEATABLEREAD, READCOMMITTED, READ_UNCOMMITTED가 있다. 위로 갈수록 동시성은 강해지고, 격리성은 낮아 지고, 아래로 갈수록 격리성은 강해지고, 동시성은 낮아진다.

팬텀 리드(Phantom Read): 하나의 트랜잭션 내에서 같은 쿼리를 두 번 이상 실행했을 때, 첫 번째 쿼리에 없던 새로운 행이나 레코드가 두 번째 쿼리에서 나타나는 현상을 말합니다. 이는 다른 트랜잭션에 의해 삽입되거나 삭제된 데이터 때문에 발생할 수 있습니다.

예를 들어 사용자 A가 회원 테이블에서 age가 13 이상인 회원들을 조회하는 쿼리를 보냈다는 가정했을 때 결과로 3개의 테이블 을 조회한다고 해보면 그다음 사용자 B가 age가 15인 회원 레코드를 삽입한다. 그러면 3개가 아닌 4개가 조회된다.
반복 가능하지 않은 조회(Non-repeatable Read): 하나의 트랜잭션 내에서 같은 쿼리를 두 번 이상 실행했을 때, 첫 번째 쿼리에서 조회한 데이터와 두 번째 쿼리에서 조회한 데이터가 다른 현상을 말합니다. 이는 다른 트랜잭션에 의해 데이터가 변경되거나 삭제되었을 때 발생할 수 있습니다.

예를 들어 사용자 A가 조회 했을 때 특정 레코드를 조회하고, 그 후에 사용자 B가 동일한 레코드를 수정하거나 삭제하면, 트랜잭션 A는 같은 쿼리를 다시 실행했을 때 이전과 다른 결과를 얻을 수 있다.
더티 리드(Dirty Read): 하나의 트랜잭션에서 아직 커밋되지 않은 다른 트랜잭션의 변경 사항을 읽는 것을 말합니다. 즉, 다른 트랜잭션이 아직 롤백되거나 커밋되지 않았으므로 데이터베이스에 영구적으로 적용되지 않은 값을 읽게 됩니다.

예를 들어 사용자 A가 큰돌의 보석개수 100을 1로 변경한 내용이 커밋되지 않은 상태라도 그 이후 사용자 B가 조회한 결과가 1로 나오는 경우를 말한다.

SERIALIZABLE (직렬화)

가장 높은 격리 수준으로, 트랜잭션이 순차적으로 실행되는 것처럼 보장된다. 다른 트랜잭션에서 데이터를 수정하거나 추가하는 것을 완전히 차단하여 펜텀 리드(Phantom Read)와 반복 가능하지 않은 조회(Non-repeatable Read)를 방지한다. 다른 격리 수준에 비해 더 많은 락(Lock)을 사용하므로 동시성이 떨어질 수 있습니다.

REPEATABLE READ (반복 가능한 읽기)

트랜잭션 내에서 동일한 쿼리를 여러 번 실행해도 항상 동일한 결과를 얻을 수 있다. 반복 가능하지 않은 조회(Non-repeatable Read)는 발생하지 않지만, 펜텀 리드(Phantom Read)가 발생할 수 있다. REPEATABLE READ 격리 수준에서는 트랜잭션이 커밋되기 전까지 다른 트랜잭션에서 해당 데이터를 수정하거나 추가할 수 없도록 락(Lock)을 사용한다.

READ COMMITTED (읽기 커밋)

다른 트랜잭션에서 커밋한 변경 사항만 읽을 수 있다. 더티 리드는 발생하지 않지만, 반복 가능하지 않은 조회(Non-repeatable Read)와 펜텀 리드(Phantom Read)가 발생할 수 있다. 일반적으로 가장 기본적으로 사용되는 격리 수준이며, 많은 데이터베이스 시스템에서 기본으로 설정된다.

READ UNCOMMITTED (미허용 읽기)

가장 낮은 격리 수준으로, 다른 트랜잭션에서 아직 커밋되지 않은 변경 사항도 읽을 수 있다. 더티 리드(Dirty Read)가 발생할 수 있으며, 다른 트랜잭션에서 롤백되거나 커밋되지 않은 값을 읽을 수 있다. 데이터 일관성과 무결성이 보장되지 않기 때문에 일반적으로 권장되지 않는 격리 수준입니다.

지속성(Durability)

트랜잭션이 성공적으로 완료되면, 그 결과는 영구적으로 유지되어야 한다. 시스템 장애나 손상된 상태에서도 데이터베이스는 지속적으로 트랜잭션의 결과를 보존해야 한다. 데이터 베이스는 이를 위해 체크섬, 저널링, 롤백 등의 기능을 제공한다.

무결성(Integrity)

데이터의 정확성, 일관성, 유효성을 유지하는 것을 말하며, 무결성이 유지되어야 데이터 베이스에 저장된 데이터 값과 그 값에 해당하는 현실 세계의 실제 값이 일치하는지에 대한 신뢰가 생긴다.

이름	설명
개체 무결성	기본키로 선택된 필드는 빈 값을 허용하지 않는다.
참조 무결성	서로 참조 관계에 있는 두 테이블의 데이터는 항상 일관된 값을 유지해야 한다.
고유 무결성	특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우 그 속성 값은 모두 고유한 값을 가진다.
NULL 무결성	특정 속성 값에 NULL이 올 수 없다는 조건이 주어진 경우 그 속성 값은 NULL이 될 수 없다는 제약 조건이다.

Database 정규화 과정

Sun, 23 Jul 2023 00:00:00 GMT

Image via Shutterstock under license to Frank Andrade

들어가며

정규화 과정은 릴레이션 간의 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 일어나 이를 해결하거나, 저장공간을 효율적으로 사용하기 위해 릴레이션을 여러 개로 분리하는 과정을 말한다.

여기서 말하는 데이터베이스 이상 현상은 예를 들어 회원이 한 가지의 등급을 가져야 하는 상황에서 여러 개의 등급을 가지고 있거나, 데이터를 삭제할 때 필요한 데이터가 같이 삭제되고, 데이터를 삽입하는데 하나의 필드값이 NULL이 되면 삽입이 안 되어서 삽입하기 어려운 현상을 말한다.

정규화는 정규화 원칙을 기반으로 정규형을 만들어가는 과정이며, 정규화된 정도를 정규형으로 표현한다. 기본 정규형은 제 1정규형, 제2 정규형, 제3 정규형, 보이스-코드 정규형(BCNF)이 있고, 고급 정규형으로는 제4 정규형과 제5 정규형이 있다.

정규형 원칙

정규형의 원칙은 데이터베이스 설계에서 데이터의 중복을 최소화하고 데이터의 무결성을 보장하기 위해 정의된 일련의 규칙입니다. 주로 관계형 데이터베이스에서 사용되며, 데이터베이스의 효율성과 유지보수성을 높이는데 도움이 된다.

제1 정규형(1NF)

각 테이블은 원자적인 값만을 포함해야 한다. 즉, 더 이상 나눌 수 없는 단위여야 한다.
각 속성은 하나의 값을 가져야 하며, 여러 개의 값을 포함하는 복합 속성은 허용되지 않는다.

제 1정규형

그림처럼 두두라는 브랜드에 판매 제품이 반바지, 트레이닝복 세트 이렇게 있을 때 이것을 나눠서 반복 속성을 제거하는 것을 볼 수 있다. 구찌라는 브랜드도 마찬가지로 셔츠와 정장세트를 나눠서 반복 속성을 제거해준 것을 확인할 수 있다.

제2 정규형(2NF)

1NF를 만족해야 한다.
기본 키가 아닌 모든 속성들이 기본 키 전체에 대해 완전 함수 종속해야 한다. 즉, 기본 키 중 어떤 부분에도 의존하지 않아야 한다.

제 2정규형

그림을 확인해 보면 기본키인 {브랜드, 제품명}과 정말 종속되어 있는 브랜드번호 릴레이션과 {브랜드, 제품명}에 따른 가격 릴레이션으로 분리되어 있는 것을 확인할 수 있다. 주의점으로는 릴레이션을 분해할 때 동등한 릴레이션으로 분해해야 하고, 정보 손실이 발생하지 않는 무손실 분해로 분해되어야 한다는 점이다.

제3 정규형(3NF)

2NF를 만족해야 한다.
기본 키가 아닌 모든 속성들이 기본 키에 대해서만 종속되어야 한다. 즉, 기본 키가 아닌 속성들 간에는 종속 관계가 없어야 한다.

이행적 함수 종속

이행적 함수 종속

이행적 함수 종속이란 A -> B와 B -> C 존재할 때, 논리적으로 A -> C도 성립하는데, 이때 집합 C가 집합 A에 이행적으로 함수 종속이 되어있다고 말한다.

예를 들어 dudu라는 패션 플랫폼이 있다고 가정하고, 각각의 브랜드의 등급, 수수료율이 정해져 있는 테이블을 아래의 그림과 같이 분해하는 것을 말한다.

제 3정규형

보이스-코드 정규형(BCNF)

모든 결정자(Candidate Key)가 키 전체에 대해 함수 종속되어야 한다.
제3 정규형을 만족하면서 부분적으로 함수 종속되는 문제를 해결한다.

결정자 : 함수 종속 관계에서 특정 종속자(dependent)를 결정짓는 요소이다. 예를 들어 A -> B일 때, A는 결정자, B는 종속자이다.

dudu 플랫폼에서 브랜드별 이벤트를 진행한다고 했을 때, 요구 사항은 다음과 같다고 가정해 보겠습니다.

각 이벤트에 대해 한 명의 고객은 오직 하나의 브랜드의 이벤트만 참여할 수 있다. (ex : 만약 1번 고객이 구찌의 모자 이벤트를 참여했다면, 아미의 모자 이벤트는 참여할 수 없다.)
각 브랜드는 하나의 이벤트만 진행할 수 있다.
하나의 이벤트는 여러 브랜드가 담당할 수 있다.

회원번호 - 이벤트명 - 브랜드의 릴레이션과 함수 종속

위 릴레이션을 보면 {회원 번호, 이벤트명} 또는 {회원 번호, 브랜드}가 후보키가 되며, 만약 나이키라는 브랜드가 신발 이벤트를 진행할 때, 이를 삽입하면 회원 번호가 NULL이 되는 문제가 발생한다.

함수 종속을 확인해보면 브랜드가 결정자지만 후보키가 아니므로 브랜드 속성을 분리해줘야 한다.

보이스 - 코드 정규형을 만족한 릴레이션

위 그림을 확인해 보면 나이키의 신발 이벤트가 정상적으로 들어갔으며 회원 번호와 브랜드. 이벤트명과 브랜드로 잘 나눠진 모습을 확인할 수 있다.

정규형의 원칙을 따르면 데이터의 중복을 최소화하고, 데이터의 일관성과 무결성을 유지할 수 있다. 하지만 과도한 정규화는 성능 저하를 초래할 수 있으므로, 실제 서비스 운영 환경에서는 성능과의 균형을 고려하여 적절한 정규화 수준을 선택해야 한다. 또한, 정규형을 만족하지 못하는 경우에는 데이터의 수정, 삽입, 삭제 시 데이터 무결성을 유지하기 어려울 수 있으므로, 정규형을 따르는 것이 좋다고 생각한다.

ERD에 대한 간단한 설명(Entity Relationship Diagram)

Fri, 21 Jul 2023 00:00:00 GMT

https://gitmind.com/kr/er-diagram-tool.html

ERD 의미

ERD(Entity Relationship Diagram)는 데이터베이스를 구축할 때 가장 기초적인 뼈대 역할을 하며, 릴레이션 간의 관계들을 정리한 것이다. 설계 과정에서 중요한 도구로서 데이터베이스의 구조를 이해하고 분석하는 데 도움을 주며, 데이터베이스의 효율성과 일관성을 유지하고 향상하는 데 기여한다. 또한 팀 간의 협업과 유지 보수를 간편하게 만들어준다. 따라서 프로젝트의 성공을 위해 ERD를 적절하게 활용하는 것이 중요하다. 만약 우리가 서비스를 구축한다고 하면 가장 신경 써야 할 부분이다.

ERD의 중요성

ERD는 시스템의 요구 사항을 기반으로 작성되며 이 ERD를 기반으로 데이터베이스를 구축한다. 데이터베이스를 구축한 후에도 디버깅이나 비즈니스 프로세스 재설계가 필요한 경우에 설계도 역할을 담당한다.

하지만 ERD는 관계형 구조로 표현하는 데이터를 표현할때 유용하지만, 비정형 데이터를 표현할 수는 없다.

비정형 데이터란? 비구조화 데이터를 말하며, 미리 정의된 데이터 모델이 없거나 미리 정의된 방식으로 정리되지 않은 정보다. 이러한 데이터는 일반적인 행-열 구조가 없으며, 데이터베이스나 테이블 등으로 쉽게 정리하거나 저장하기 어렵다.

비정형 데이터는 사람의 언어, 이미지, 비디오, 소셜 미디어 게시물, 웹 페이지 등 다양한 형태로 존재한다.

데이터베이스 구조 시각화

복잡한 데이터베이스 구조를 시각화하여 이해하기 쉽게 도와준다. 개체(Entity)와 개체들 간의 관계를 명확하게 보여주기 때문에 데이터베이스의 구조를 파악하는 데 도움이 된다.

요구 사항 분석

ERD를 작성함으로써 요구 사항을 명확하게 파악할 수 있다. 데이터베이스 설계는 사용자 요구 사항에 기반해 이루어지며, ERD를 통해 개체들의 속성과 관계를 정확히 정의함으로써 프로젝트의 성공 가능성을 높일 수 있다.

데이터 일관성 유지

데이터베이스의 구조를 명확하게 정의함으로써 데이터의 일관성을 유지하는 데 도움이 된다. 올바른 관계를 설정하고 적절한 속성을 지정함으로써 데이터의 중복을 줄이고 무결성을 유지할 수 있다.

데이터베이스 효율성

올바른 ERD를 사용하면 데이터베이스의 성능과 효율성을 향상할 수 있다. 적절한 인덱스를 설정하거나 쿼리 최적화를 수행하는 등 ERD를 기반으로 데이터베이스를 튜닝할 수 있다.

개발자와 협업

ERD는 개발자, 데이터베이스 관리자, 프로젝트 관리자 등 다양한 팀원들 사이의 소통과 협업을 간소화할 수 있다. ERD를 통해 모든 팀원들이 데이터베이스 구조를 쉽게 이해하고 작업할 수 있다.

유지 보수 용이성

데이터베이스가 변경되어야 하는 경우에도 유지 보수를 용이하게 만든다. 데이터베이스 구조를 시각화하고 문서화하면 변경 사항을 파악하고 적용하는 데 도움이 된다.

컴퓨터의 요소

Mon, 17 Jul 2023 00:00:00 GMT

컴퓨터는 CPU, DMA 컨트롤러, 메모리, 타이머, 디바이스 컨트롤러 등으로 이루어져 있습니다.

CPU

CPU란 (Central Processing Unit)의 약자로 중앙 처리 장치라고 부르기도 하며, 제어장치, 레지스터, 산술논리연산장치로 이어져 있습니다. 컴퓨터의 두뇌로서, 명령어를 해석하고 실행하는 역할을 수행합니다. 산술 및 논리 연산, 데이터처리, 제어 등의 작업을 처리합니다.

레지스터(Register)

CPU 내부에 위치한 작고 빠른 기억 장소로, 명령어와 데이터를 일시적으로 저장하는 역할을 합니다. 레지스터는 CPU에서 가장 빠른 액세스 속도를 가지므로, 중앙 처리 장치와 메모리 간의 데이터 이동을 감소시키고 연산 속도를 향상시킵니다. 또한 주소 레지스터, 데이터 레지스터, 명령어 레지스터 등 다양한 유형의 레지스터가 있습니다.

산술 논리 연산장치(ALU, Arithmetic Logic Unit)

산술 연산(덧셈, 뺄셈 등)과 논리 연산(AND, OR, NOT 등)을 수행하는 장치입니다. ALU는 레지스터에서 데이터를 받아서 연산을 수행하고, 그 결과를 다시 레지스터에 저장합니다. 이를 통해 데이터의 처리, 비교, 조작 등 다양한 연산을 수행할 수 있습니다. ALU는 CPU의 핵심적인 구성 요소 중 하나로, 컴퓨터의 계산 능력을 결정하는 요소 중 하나입니다.

제어장치(Control Unit)

CPU의 구성 요소 중 하나로, 컴퓨터 시스템의 모든 동작을 조정하고 제어하는 역할을 합니다. 명령어 해석, 실행, 데이터 전송 등의 작업을 수행합니다. 제어장치는 명령어를 해독하고 실행 단계를 조정하여 다른 하드웨어 구성 요소들이 올바른 순서로 동작하도록 합니다.

https://blog.naver.com/dlaxodud2388/221613076571

CPU의 연산 처리 순서

제어장치가 메모리에 계산할 값을 로드한다. 또한, 레지스터에도 로드
제어장치가 레지스터에 있는 값을 계산하라고 산술논리연산장치(ALU)에 명령
제어장치가 계산된 값을 다시 레지스터에서 메모리로 계산된 값을 저장

인터럽트(Interrupt)

인터럽트란 컴퓨터 시스템에서 발생하는 이벤트로, 어떤 신호가 들어왔을 때 CPU를 잠시 정지시킨 후 우선 순위가 더 높은 작업을 처리하도록 하는 메커니즘입니다. 인터럽트는 외부 장치의 상태 변화나 예외 상황 발생 등 다양한 상황에서 발생할 수 있다.

인터럽트가 발생되면 인터럽트 핸들러 함수가 모여 있는 인터럽트 백터로 가서 인터럽트 핸들러 함수가 실행됩니다. 인터럽트 간에는 우선순위가 있기 때문에 우선순위에 따라 실행됩니다. 인터럽트는 소프트웨어 인터럽트와 하드웨어 인터럽트로 나눌 수 있습니다.

하드웨어 인터럽트

하드웨어 장치에서 발생하는 인터럽트로, 주로 외부 장치가 CPU의 관심이 필요한 작업을 알리는 역할을 합니다. 이때 인터럽트라인이 설계된 이후 순차적인 인터럽트 실행을 중지하고 운영체제에 시스템 콜을 요청해서 원하는 디바이스로 향해 디바이스에 있는 작은 로컬 버퍼에 접근하여 일을 수행합니다. 예를 들어, 키보드 입력, 마우스 클릭, 타이머 등이 있습니다.

소프트웨어 인터럽트

소프트웨어에서 발생하는 인터럽트로, 트랩(trap)이라고 부르기도 하며 주로 프로그램 실행 중 예외 상황이나 특정 이벤트에 응답하기 위해 사용됩니다. 예를 들어, 0으로 나누기 오류, 메모리 보호 오류, 시스템 호출 등이 있습니다.

DMA 컨트롤러

DMA(Direct Memory Access) 컨트롤러는 컴퓨터 시스템에서 데이터를 메모리와 주변 장치 간에 직접 전송하는 데 사용되는 하드웨어 장치입니다. DMA 컨트롤러는 CPU의 개입 없이 데이터 전송을 처리하므로, CPU가 다른 작업에 전념할 수 있도록 합니다.

일반적으로, 데이터를 전송하는 과정에서 CPU는 데이터를 읽어오고, 그 다음 주변 장치로 전송하거나 메모리로부터 데이터를 가져와 주변 장치에 전송하는 역할을 수행합니다. 이렇게 CPU가 직접 데이터 전송을 처리하면 처리 속도가 느려지거나 CPU의 성능이 저하될 수 있습니다.

DMA 컨트롤러는 이러한 문제를 해결하기 위해 도입되었습니다. DMA 컨트롤러는 CPU의 개입 없이 주변 장치와 메모리 간 데이터 전송을 수행합니다. CPU는 DMA 컨트롤러에 전송 작업을 지시하고, DMA 컨트롤러는 주변 장치와 메모리 사이의 데이터 전송을 독립적으로 처리합니다.

메모리(Memory)

메모리는 전자회로에서 데이터나 상태, 명령어 등을 기록하는 장치를 말합니다. 데이터의 읽기와 쓰기 작업을 수행하며, 프로그램과 데이터를 영구적으로 저장합니다.

주 기억장치 (Main Memory)

주 기억장치는 컴퓨터가 실제로 작동할 때 프로그램과 데이터를 저장하는 공간입니다. 주로 랜덤 액세스 메모리(RAM)이 사용됩니다. RAM은 읽기와 쓰기 모두가 가능하며, 전원이 공급되는 동안 데이터를 유지합니다. 주 메모리는 컴퓨터가 작동 중일 때만 데이터에 접근할 수 있으며, 전원이 꺼지면 저장된 데이터가 손실됩니다.

캐시 메모리 (Cache Memory)

캐시 메모리는 CPU가 주로 사용하는 메모리 계층 중 하나로, 주 기억장치와 CPU 사이의 속도 차이를 극복하기 위해 사용됩니다. 캐시는 주로 속도가 빠른 SRAM(Static Random Access Memory)으로 구성되며, CPU가 자주 사용하는 데이터와 명령어를 임시로 저장합니다. 캐시는 CPU에 가까워 데이터 액세스 속도가 빠르며, 주 메모리로부터 데이터를 미리 가져와 CPU의 대기 시간을 줄입니다.

보조 기억장치 (Secondary Storage)

보조 기억장치는 주 기억장치와는 달리 데이터를 영구적으로 저장하는 데 사용됩니다. 주로 하드 디스크 드라이브(HDD) 또는 고체 상태 드라이브(SSD)와 같은 장치를 의미합니다. 보조 기억장치는 주로 대용량 저장 공간을 제공하며, 컴퓨터의 운영 체제, 프로그램, 파일 등을 저장합니다. 보조 기억장치는 주 메모리보다 접근 속도가 느리지만, 비휘발성이므로 전원이 꺼져도 데이터가 보존됩니다.

각 메모리 유형은 속도, 용량, 비용 등의 측면에서 서로 다른 특징을 가지고 있으며, 컴퓨터 구조의 성능과 기능을 결정하는 요소 중 하나입니다.

타이머(Timer)

타이머는 몇 초안에는 작업이 끝나야 한다는 것을 정하고 특정 프로그램에 시간을 제한을 다는 역할을 합니다. 시간이 많이 걸리는 프로그램이 작동할 때 제한을 걸기 위해 존재합니다.

디바이스 컨트롤러(Device controller)

디바이스 컨트롤러는 컴퓨터와 연결되어 있는 입출력 디바이스들의 작은 CPU를 말합니다.

reference : https://blog.naver.com/dlaxodud2388/221613076571 , 면접을 위한 CS 전공지식 노트(저자: 주홍철)

운영체제 (OS)

Mon, 17 Jul 2023 00:00:00 GMT

들어가며

운영체제(Operating System)는 줄여서 OS라고 부르기도 한다. 컴퓨터 시스템에서 하드웨어와 응용 소프트웨어 사이에서 동작하며, 컴퓨터의 자원을 효율적으로 관리하고 제어하는 소프트웨어입니다. 운영체제는 컴퓨터 시스템의 핵심 구성 요소로서, 하드웨어와 소프트웨어 사이의 인터페이스 역할을 수행하며, 사용자와 컴퓨터 시스템 간의 상호 작용을 지원합니다.

우리가 알고 있는 대표적인 운영체제는 Windows, Linux, Mac OSX, iOS 등이 있다.

운영체제의 역할

운영체제는 시스템에서 중요한 역할을 수행하는 소프트웨어입니다. 주요 역할들을 설명해 보겠습니다.

자원 관리 : 운영체제는 컴퓨터의 자원을 효율적으로 관리합니다. 이는 CPU, 메모리, 저장장치, 입출력 장치 등을 포함합니다. 운영체제는 여러 프로세스 또는 작업이 공유 자원을 사용할 수 있도록 조정하고, 자원의 할당과 해제를 관리하여 시스템의 성능과 안정성을 유지합니다.
메모리 관리 : 운영체제는 시스템의 메모리를 관리하여 프로세스가 메모리에 적절하게 할당되도록 합니다. 메모리의 주소 공간을 관리하고, 메모리 할당 및 해제를 처리하여 프로세스가 메모리를 효율적으로 사용할 수 있도록 합니다.
파일 시스템 관리 : 운영체제는 파일 시스템을 관리하여 파일의 생성, 삭제, 읽기, 쓰기 등을 처리합니다. 파일과 디렉터리의 구조를 유지하고, 파일에 대한 접근 권한을 관리하며, 데이터의 안정성을 보장하기 위해 백업 및 복구 기능을 제공합니다.
프로세스 관리 : 운영체제는 실행 중인 프로세스를 관리합니다. 프로세스 스케줄링을 통해 CPU 시간을 공정하게 분배하고, 프로세스의 생성, 종료, 일시 정지, 재개 등을 관리합니다. 이를 통해 다중 작업 환경에서 여러 프로세스가 동시에 실행될 수 있도록 합니다.
입출력 관리 : 운영체제는 입출력 장치를 관리하여 프로세스가 입출력을 수행할 수 있도록 합니다. 입출력 장치의 드라이버를 관리하고, 입출력 작업을 대기시키고 완료된 작업을 처리하여 프로세스와 입출력 장치 간의 효율적인 상호 작용을 지원합니다.
사용자 인터페이스 제공 : 운영체제는 사용자와 컴퓨터 사이의 상호 작용을 위한 인터페이스를 제공합니다. 이는 텍스트 기반 명령 줄 인터페이스(CLI)부터 그래픽 사용자 인터페이스(GUI)까지 다양한 형태일 수 있습니다. 사용자는 운영체제를 통해 프로그램 실행, 파일 관리, 시스템 설정 등을 수행할 수 있습니다.

운영체제의 구조

유저 프로그램(User Program) : 사용자가 작성한 응용 소프트웨어입니다. 운영체제 위에서 실행되며, 사용자의 요구에 따라 특정 작업을 수행합니다. 예를 들면 워드 프로세서, 웹 브라우저, 게임 등이 있습니다.
GUI(Graphical User Interface) : 그래픽 기반의 사용자 인터페이스를 제공하는 운영체제의 구성 요소입니다. 유저가 마우스, 키보드 등을 사용하여 그래픽 환경에서 응용 프로그램을 조작하고 상호 작용할 수 있도록 합니다. 이를 통해 사용자는 유저 프로그램과 운영체제의 다른 요소들을 직관적이고 편리하게 사용할 수 있습니다.
시스템 콜(System Call) : 유저 프로그램이 운영체제의 기능을 사용할 수 있도록 하는 인터페이스입니다. 유저 프로그램은 시스템 콜을 호출하여 운영체제에게 특정 작업을 요청하고, 운영체제는 해당 요청을 처리합니다. 예를 들면 파일 입출력, 메모리 할당, 프로세스 생성 등의 작업을 시스템 콜을 통해 수행할 수 있습니다.
커널(Kernel) : 운영체제의 핵심 부분으로, 가장 중요한 기능을 담당합니다. 커널은 시스템 콜을 처리하고, 프로세스 스케줄링, 메모리 관리, 파일 시스템, 네트워킹 등의 핵심 기능을 수행합니다. 일반적으로 커널은 운영체제의 가장 중요한 부분으로서 메모리 상에 상주하여 실행됩니다.
드라이버(Driver) : 운영체제와 하드웨어 간의 통신을 담당하는 소프트웨어입니다. 각 하드웨어 장치는 운영체제에서 인식하고 제어하기 위해 해당 장치에 대한 드라이버가 필요합니다. 드라이버는 특정 하드웨어와 통신하여 하드웨어의 기능을 사용하고, 운영체제에 필요한 데이터를 전달합니다.
하드웨어(Hardware) : 컴퓨터 시스템의 물리적인 구성 요소입니다. 이는 CPU, 메모리, 저장 장치, 입출력 장치 등 컴퓨터의 실제 기기를 포함합니다. 운영체제는 하드웨어와 상호 작용하여 자원을 관리하고 사용자 요청을 처리합니다.

이러한 요소들은 운영체제의 구조에서 상호 작용하여, 사용자는 GUI를 통해 유저 프로그램을 실행하고, 유저 프로그램은 시스템 콜을 호출하여 커널의 기능을 사용합니다.

커널은 드라이버를 통해 하드웨어와 통신하여 자원을 관리하고, 하드웨어는 운영체제와 상호 작용하여 명령을 수행합니다. 이렇게 함께 동작함으로써 운영체제는 컴퓨터 시스템을 효율적으로 제어하고 사용자에게 필요한 서비스를 제공합니다.

시스템 콜(System Call)

시스템 콜은 유저 모드에서 커널 모드로 전환되어 운영체제의 특권 명령을 실행하고, 그 결과를 유저 프로그램에게 반환합니다.

시스템 콜의 동작 과정을 자세히 알아 보겠습니다.

유저 프로그램 호출 : 유저 프로그램은 운영체제의 기능을 사용하기 위해 시스템 콜을 호출합니다. 시스템 콜은 특정 함수 또는 명령으로 제공됩니다. 예를 들어 파일을 열거나, 메모리를 할당하거나, 프로세스를 생성하는 등의 작업을 수행하기 위해 해당하는 시스템 콜을 호출합니다.
유저 모드에서 커널 모드로 전환 : 시스템 콜은 특권 명령을 실행하기 위해 유저 모드에서 커널 모드로 전환됩니다. 유저 모드에서는 제한된 권한으로 작업을 수행하지만, 커널 모드에서는 운영체제의 모든 권한과 자원에 접근할 수 있습니다. 이 전환은 보안을 위해 운영체제가 관리하며, 전환하는 과정에서 프로세스의 상태와 실행 위치 등이 저장됩니다.
시스템 콜 처리 : 커널 모드로 전환된 후, 시스템 콜을 처리하기 위해 커널 내의 해당하는 함수 또는 서비스 루틴으로 이동합니다. 이는 운영체제의 커널 코드에서 실행됩니다. 시스템 콜은 유저 프로그램에 의해 전달된 매개변수를 확인하고, 필요한 동작을 수행하기 위해 해당하는 서비스를 호출합니다. 예를 들어 파일을 열기 위한 시스템 콜은 파일 이름과 접근 권한 등을 확인하고, 파일 시스템 서비스를 호출하여 파일을 엽니다.
커널 모드에서 유저 모드로 복귀 : 시스템 콜 처리가 완료되면, 커널 모드에서 유저 모드로 다시 전환됩니다. 이때 커널은 처리 결과를 유저 프로그램에게 반환합니다. 반환 값이나 오류 코드 등을 이용하여 유저 프로그램은 시스템 콜 호출 이후의 동작을 결정할 수 있습니다. 예를 들어 파일 열기 시스템 콜은 파일 핸들(식별자)을 반환하여 유저 프로그램이 파일에 접근할 수 있게 합니다.

reference : https://fjvbn2003.tistory.com/306 , https://career-gogimandu.tistory.com/58

PDU (Protocol Data Unit)

Mon, 10 Jul 2023 00:00:00 GMT

PDU의 의미

네트워크의 계층에서 계층으로 데이터를 전달할 때 한 덩어리의 단위를 PDU라고 합니다. PDU는 제어 관련 정보들이 포함된 헤더와 데이터를 의미하는 페이로드로 구성되어 있습니다.

각 계층의 PDU

위 그림처럼 PDU는 각 계층마다 부르는 이름이 다릅니다.

애플리케이션계층 : 메시지
전송계층 : 세그먼트(TCP), 데이터그램(UDP)
인터넷계층 : 패킷
링크계층 : 프레임(데이터링크계층),비트(물리계층)

PDU 중 아래 계층인 bit로 송수신하는 것이 모든 PDU 중 가장 빠르고 효율성이 높습니다. 하지만 애플리케이션계층에서는 문자열을 기반으로 송수신을 하는데, 그 이유는 헤더에 authorization값 등 다른 값들을 넣는 확장이 쉽기 때문입니다.

헤더

헤더란? 저장되거나 전송되는 데이터 블록의 맨 앞에 위치한 보충 데이터를 말합니다. 데이터 전송에서 헤더를 따르는 데이터는 페이로드(payload), 바디(body)로 불리기도 합니다.

예를 들어 e-mail을 보낼 때 텍스트(바디)는 보내는 사람, 받는 사람, 제목, 보내는 시간표, 받는 시간표, 마지막 메일 전송 에이전트 등이 전제되어야 합니다.

헤더 구성은 구문 분석을 위하여 뚜렷하고 모호하지 않은 규격이나 포맷을 따라야 합니다.

TCP/IP 4계층 모델

Sun, 09 Jul 2023 00:00:00 GMT

들어가며

인터넷 프로토콜 스위트는 인터넷에서 컴퓨터들이 서로 정보를 주고받는 데 사용하는 프로토콜의 집합이다. 이를 TCP/IP 4 계층 모델로 설명하거나 OSI 7 계층 모델로 주로 설명하는 경우가 많습니다. 여기서 TCP/IP 4 계층 모델은 OSI 7 계층과는 다르게 통신 프로토콜의 집합으로 계층들은 프로토콜의 네트워킹 범위에 따라 4개의 추상화 계층으로 구성되어 있습니다.

TCP/IP 계층과 OSI 7계층 비교

위 그림을 확인해보면 OSI 계층과 TCP/IP 계층의 다른 점을 몇 가지 확인할 수 있다. 첫 번째는 OSI 계층은 TCP/IP 계층의 애플리케이션계층을 3개로 나누고 있고, 두번째는 링크 계층을 데이터 링크 계층과 물리 계층으로 나누고 있다. 세번쨰는 네트워크 계층을 인터넷 계층으로 부르고 있다는 점입니다.

Application 계층

애플리케이션계층은 FTP, HTTP, SSH, SMTP, DNS 등 응용프로그램이 사용되는 프로토콜 계층이며 웹서비스나 이메일등 서비스를 실질적으로 사람들에게 제공하는 계층입니다.

FTP : 파일 전송 프로토콜(File Transfer Protocol)의 약자입니다. 그 의미를 자세히 살펴보면 기본적으로 '프로토콜' 또는 인터넷 프로토콜은 전자기기가 서로 통신하는 데 필요한 절차나 규칙을 말합니다. FTP는 TCP/IP 네트워크상의 장치가 파일을 전송할 때 사용하는 프로토콜입니다.
SSH : 네트워크 상 다른 컴퓨터의 쉘을 사용할 수 있게 해 주는 프로그램 혹은 그 프로토콜을 의미합니다. SSH를 사용하면 원격에서 네트워크 상의 컴퓨터에 접속할 수 있습니다. 쉽게 말해 보안되지 않은 네트워크 서비스를 안전하게 운영하기 위한 암호화 네트워크 프로토콜입니다. 교환된 대칭 키를 이용해 SSH 서버와 클라이언트 간 모든 통신은 암호화하여 진행되기 때문에, SSH 연결은 매우 안전합니다.
HTTP : HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜입니다. HTTP는 웹에서 이루어지는 모든 데이터 교환의 기초이며, 클라이언트-서버 프로토콜이기도 합니다. 클라이언트-서버 프로토콜이란 (보통 웹브라우저인) 수신자 측에 의해 요청이 초기화되는 프로토콜을 의미합니다.
SMTP : 전자 메일 전송을 위한 인터넷 표준 통신 프로토콜 입니다. 한 메일서버에서 다른 메일서버로 메일을 전송할 때, 송신자의 user agent에서 본인의 메일서버로 메일을 전송할때 SMTP가 사용됩니다. 참고로 SMTP는 HTTP보다 훨씬 더 오래전부터 사용되고 있습니다.
DNS : 전 세계에 배포된 서비스로 www.naver.com 같이 사람이 읽을 수 있는 이름을 192.0.2.1과 같은 숫자 IP 주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 합니다. 인터넷의 DNS 시스템은 이름과 숫자 간의 매핑을 관리하여 마치 전화번호부와 같은 기능을 합니다. DNS 서버는 이름을 IP 주소로 변환하여 도메인 이름을 웹 브라우저에 입력할 때 최종 사용자를 어떤 서버에 연결할 것인지를 제어합니다. 이 요청을 쿼리라고 부릅니다.

Transport 계층

전송계층은 송신자와 수신자를 연결하는 통신 서비스를 제공하고, 연결 지향 데이터 스트림 지원, 신뢰성, 흐름제어를 제공할 수 있으며 애플리케이션 계층과 인터넷 계층 사이에 데이터를 전달할 때 중계 역할을 하는 계층입니다. 대표적으로 TCP와 UDP가 있습니다.

TCP : Transmission Control Protocol의 약자로 패킷 사이의 순서를 보장하고 연결지향 프로토콜을 사용해서 연결하여 신뢰성을 구축하여 수신 여부를 확인가능하며 가상 회선 패킷 교환 방식을 사용합니다.
UDP : User Datagram Protocol의 약자로 패킷 사이의 순서를 보장하지 않고 수신 여부를 확인하지 않으며 단순히 데이터만 주는 데이터그램 교환 방식을 사용합니다.

가상 회선 패킷 교환 방식 VS 데이터그램 교환 방식

가상 회선 패킷 교환 방식 : 데이터를 전송하기 전에 논리적 연결을 설정하게 된다. 이를 가상회선이라 칭한다. 각각의 패킷에는 가상 회선 식별 번호(VCI)가 포함되어 있고, 모든 패킷들을 전송하면 가상회선이 해제되며 패킷들은 전송한 순서대로 도착합니다. (연결 지향)

https://woovictory.github.io/2018/12/28/Network-Packet-Switching-Method/

데이터그램 교환 방식 : 데이터를 전송하기 전 논리적 연결을 설정하지 않고, 패킷들이 독립적으로 전송된다. 이를 데이터그램이라 칭한다. 패킷을 수신한 라우터는 최적의 경로를 선택하여 패킷을 전송하는데, 하나의 매시지에서 분할되어 있는 여러 개의 패킷은 서로 다른 경로로 전송될 수 도 있습니다. (비연결 지향형)

https://woovictory.github.io/2018/12/28/Network-Packet-Switching-Method/

차이점

데이터 그램은 패킷마다 라우터가 경로를 선택하지만, 가상회선 방식은 경로를 설정할 때 한 번만 수행한다.
정해진 시간 안이나 다량의 데이터를 연속으로 보낼 때는 가상 회선 방식이 적합하지만, 짧은 메시지의 일시적인 전송에는 데이터그램 방식이 적합하다.
네트워크 내에 한 노드가 다운되면 데이터그램 방식은 다른 경로를 새로 찾아서 설정하지만, 가상 회선 패킷 교환 방식은 다운된 노드를 지나는 모든 가상 회선을 잃게 된다.

Internet 계층

인터넷 계층은 장치로부터 받은 네트워크 패킷을 IP 주소로 지정된 목적지로 전송하기 위해 사용되는 계층입니다. IP, ARP, ICMP 등이 있고, 패킷을 수신해야 할 상대의 주소를 지정하여 데이터를 전달합니다. 상대가 제대로 받았는지에 대해 보장하지 않는 비연결형적인 특징을 가지고 있습니다.

Link 계층

링크 계층은 전선이나 광섬유, 무선 등을 이용하여 실질적인 데이터를 전달하며 장치 간 신호를 주고받는 규칙을 정하는 계층입니다. 다른 말로는 네트워크 접근 계층이라고 부르기도 합니다.

링크 계층을 물리계층과 데이터 링크 계층으로 나누기도 하는데 물리계층은 무선 LAN과 유선 LAN을 통해 0과 1 로이루어진 데이터를 보내는 계층을 말하며, 데이터 링크 계층은 '이더넷 프레임'을 통해 에러 확인, 흐름제어, 접근제어를 당당하는 계층을 말합니다.

유선 LAN을 이루는 이더넷은 IEEE802.3이라는 프로토콜을 따르며, 양쪽의 장치가 동시에 송수신할 수 있는 방식인 전이중화(full duplex) 통신을 사용합니다. 전이중화 방식은 송신로와 수신로를 나누어 같은 시간에 데이터를 주고받을 수 있습니다. 현대의 고속 이더넷은 전이중화 방식을 기반으로 통신하고 있습니다.

유선 LAN은 과거 CDMA/CD 방식을 사용했었다. 이 방식은 데이터를 보낸 후 충돌이 발생할 시 일정시간 이후에 재전송하는 방식을 말합니다. 전이중화 방식과는 다르게 한경로를 송신과 수신을 함께 보내는 방식이어서 데이터 충돌에 대비해야 했습니다.

광섬유 케이블

광섬유 케이블은 말 그대로 광섬유를 사용하여 만든 케이블을 말합니다. 빛을 이용하여 통신하기 때문에 과거에 사용했던 동축 케이블이나 구리선과는 비교할 수 없을 만큼의 장거리 통신이나 고속의 통신이 가능합니다. 보통 100 Gbps 속도를 내며, 밑의 그림에서 처럼 광섬유 내에서 빛이 반사하면서 반대편 끝까지 가는 원리입니다. 굴절률이 높은 부분을 코어, 낮은 부분을 클래딩이라고 합니다.

광섬유 내부에서의 빛의 이동

Java 조건문

Sat, 08 Jul 2023 00:00:00 GMT

조건문은 말 그대로 주어진 조건식의 결과에 따라 별도의 명령을 수행하도록 제어하는 명령문입니다. 자바에서 사용되는 조건문은 크게 if문과 switch문이 있습니다.

if문

if문은 소괄호 안에는 boolean 값으로 평가될 수 있는 조건식을 넣어주고, 중괄호 안의 실행 블록에는 조건식이 참일 때 실행하고자 하는 코드를 적어주면 된다. 소괄호 안에 조건문이 참(true) 일 때만 주어진 명령문이 실행된다.

참고로 else문은 생략이 가능하다.

public class ifexam {
    public static void main(String[] args) {
        int num1 = 10;
        int num2 = 5;
        int num3 = 10;

        if (num1 == num3) { //if문의 조건식이 참이어서 실행
            System.out.println("num1과 num3은 같습니다.");
        }

        if (num1 == num2) { // if문은 거짓이기 때문에 else문이 바로 실행 되어 "다릅니다." 출력
            System.out.println("같습니다.");
        } else { //else는 if문이 거짓일때 실행
            System.out.println("다릅니다.");
        }

        if (num1 > num3) { //if문은 거짓, else if문은 참이기 때문에 "num2가 num3보다 작습니다." 출력
            System.out.println("num1이 num3보다 큽니다.");
        } else if (num2 < num3) { //else if는 if문이 거짓이고, else if문의 조건식이 참 일경우 실행
            System.out.println("num2가 num3보다 작습니다.");
        }
    }
}

if문의 순서도

switch 문

switch문은 if문과 같은 조건문이지만, 변수가 어떤 값을 갖느냐에 따라 실행문이 선택됩니다. switch 문은 if /else 문보다 가독성이 더 좋으며, 컴파일러가 최적화를 쉽게 할 수 있어 속도 또한 빠른 편입니다.

import java.util.Scanner;

public class switchExam {
    static Scanner num = new Scanner(System.in);

    public static void main(String[] args) {
        String dice = num.nextLine(); //주사위 번호를 입력한다.

        switch (dice) {
            case "1":
                System.out.println("1칸 이동");
                break; //break는 다음 case를 실행하지 않고, switch문 탈출할 수 있습니다.
            case "2":
                System.out.println("2칸 이동");
                break;
            case "3":
                System.out.println("3칸 이동");
                break;
            case "4":
                System.out.println("4칸 이동");
                break;
            case "5":
                System.out.println("5칸 이동");
                break;
            case "6":
                System.out.println("6칸 이동");
                break;
            default: //switch문의 괄호 안 값과 같은 값이 없으면, 여기서 실행문을 실행합니다.
                System.out.println("없는 숫자입니다! " + dice);
                break;
        }
    }
}

Scanner를 이용하여 1 ~ 6의 숫자를 입력 받아 각각의 case에서 출력해 주고 종료되고 있습니다. 만약 1 ~ 6이 아닌 숫자를 받을 경우, "없는 숫자입니다."가 출력되고 종료됩니다.

HTTPS에 대한 간단한 정리

Fri, 07 Jul 2023 00:00:00 GMT

HTTPS의 의미

HTTPS의 사전적 의미는 하이퍼텍스트 전송 프로토콜 보안(HTTPS)은 웹 브라우저와 웹 사이트 간에 데이터를 전송하는 데 사용되는 기본 프로토콜인 HTTP의 보안 버전입니다. HTTPS는 데이터 전송의 보안을 강화하기 위해 암호화됩니다. 이는 사용자가 은행 계좌, 이메일 서비스, 의료 보험 공급자에 로그인하는 등 중요한 데이터를 전송할 때 특히 중요합니다.

모든 웹 사이트, 특히 로그인 자격 증명이 필요한 웹 사이트는 HTTPS를 사용해야 합니다. 크롬 등 최신 웹 브라우저에서는 HTTPS를 사용하지 않는 웹 사이트가 HTTPS를 사용하는 웹 사이트와 다르게 표시됩니다.

HTTPS의 특징

1. 암호화

외부인이 서버와 클라이언트가 주고받는 정보를 탈취할 수 없도록 한다. 서버와 클라이언트가 HTTPS를 사용하면 서로 합의한 방식으로 데이터를 암호화하여 주고받는다. 이때 외부인이 데이터 탈취에 성공하더라도 암호화되어 알아볼 수 없게 된다. 하지만 HTTP는 데이터 암호화가 따로 적용되지 않아서 외부인이 데이터 탈취 시에 쉽게 정보를 확인할 수 있다.

여기서 서버와 클라이언트의 암호화 방식은 대칭키 방식과 비대칭키 방식을 혼용하여 사용한다. 대칭키 방식은 비대칭키 방식 보다 알고리즘이 덜 복잡하여 대칭키를 사용하여 암복호화 하는 편이 컴퓨터에 부담을 덜 줄 수 있기 때문에 서버와 클라이언트가 데이터를 주고 받을 때 사용 합니다. 대칭키 방식은 공통의 비밀키를 공유하여 서로의 데이터를 암호화 복호화할 수 있고, 비대칭키 방식은 각각 공개키와 비밀키(개인키)를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인이 가진 비밀키로 복호화하는 것을 의미합니다.

여기서 대칭키를 주고 받는 상황에서 데이터 탈취가 일어난다면 암호화를 하게 되더라도 복호화될 가능성이 높습니다. 그래서 HTTPS는 대칭키를 주고 받을때는 비대칭키 방식을 사용하도록 되어 있습니다.

2. 인증서

HTTPS는 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있습니다. 인증서는 서버의 신원을 보증하여 접속한 사이트가 가짜 사이트가 아닌 것을 보증합니다. 이때 이를 보증할 수 있는 제삼자를 Certificate Authority, CA라고 부릅니다. CA는 인증서를 발급해 주는 엄격하게 공인된 기관들을 말하는데, 이러한 CA들은 서버의 공개키와 정보를 CA의 비밀키로 암호화하여 인증서를 발급합니다.

tistory의 인증서

인증서를 발급한 CA, 서명에 사용한 알고리즘, 서명, tstory 공개키 정보 등이 들어있는 것을 확인할 수 있습니다. 서버가 클라이언트에게 CA에서 발급받은 인증서를 전달하면 클라이언트는 OS 또는 브라우저에 미리 내장되어 있던 CA 리스트를 통해 브라우저에서 인증된 CA에서 발급받은 인증서인지 먼저 확인했을 때 만약 인증된 CA에서 발급한 인증서가 아니라면 화면에 경고창을 보여주고, 반대로 CA에서 발급한 인증서 일시 브라우저에서 제공된 CA 기관의 공대키로 서버 인증서를 복호화합니다.

Java StringBuilder란?

Wed, 05 Jul 2023 00:00:00 GMT

자바의 문자열은 주로 String을 사용한다. 이 문자열이 1개 이상 있을때, 붙여서 사용하는법에서 가장 간단한 방법은 StringBuilder메서드를 사용하는법이라고 생각한다. 이번엔 StringBuilder의 사용법을 알아보려고 한다.

String result1 = "자바스프링 - ";
String java = "자바";
String Spring = "스프링";
String result = java + Spring;
result1 += java += Spring;
System.out.println(result);  //자바 스프링
System.out.println(result1); //자바스프링 - 자바스프링

⚠ 이런식으로 String 객체끼리 더하는 방법은 메모리 할당과 해제를 발생시키는데, 덧셈 연산이 많아진다면 성능적으로 좋지 않다.

그 이유로는 자바에서 String 객체는 변경 불가능하다. 한 번 생성되면 내용을 바꿀 수 없단 뜻이다. 따라서 하나의 문자열을 다른 문자열과 연결하면 새 문자열이 생성되고, 이전 문자열은 가비지 컬렉터로 들어간다. 문자열을 연결하는 작업은 여러 작업이 발생하고,기존 문자열 값의 길이에 추가된 문자열의 크기를 더한 크기의 새로운 문자열이 생성되는데 이런 작업을 여러번 실행하게 되면 메모리를 많이 잡아먹고,실행시간이 길어진다. 그래서 대안으로 StringBuilder를 많이 사용한다. Stirng은 변경 불가능한 문자열을 생성하지만 StringBuilder는 변경 가능한 문자열을 만들어 준다.

StringBuilder stringBuilder = new StringBuilder();
stringBuilder.append("자바").append("스프링");
        
//String str = stringBuilder;
String str = stringBuilder.toString();

// String에 StringBuilder를 그대로 넣을 순 없다. toString()을 붙여서 형변환을 해준다.
// 두 출력은 같은 값을 출력한다
System.out.println(stringBuilder); //자바스프링
System.out.println(str); //자바스프링

StringBuilder의 객체를 생성한 후, append()의 인자로 연결하고자 하는 문자열을 넣어서 StringBuilder의 객체를 통해 호출한다. 출력 시에는 toString()을 붙여야 하고, String변수에 넣을 때도 같다.

이터레이터 패턴 (Iterator Pattern)

Sun, 02 Jul 2023 00:00:00 GMT

들어가며

이터레이터 패턴은 이터레이터(Iterator)를 사용하여 컬렉션(Collection)의 요소들에 접근하는 디자인 패턴입니다. 이를 통해 순회할 수 있는 여러 가지 자료형의 구조와는 상관없이 이터레이터라는 하나의 인터페이스로 순회가 가능합니다.

이터레이터 패턴 구성 요소

이터레이터 패턴은 주로 다음과 같은 구성 요소로 구성됩니다.

Iterator(반복자): 검색된 요소를 순회하는 역할을 담당합니다. 다음 요소로 이동하거나 현재 요소에 접근하는 방법을 제공합니다.
ConcreteIterator(구체적인 반복자): Iterator 인터페이스를 구현하여 실제로 모음을 순회하는 로직을 구현합니다.
Aggregate(집합체): 객체들의 집합체를 인터페이스입니다. 이 인터페이스를 구현하는 컬렉션 클래스는 iterator() 메서드를 제공하여 ConcreteIterator 객체를 생성합니다.
ConcreteAggregate(구체적인 집적체): Aggregate 인터페이스를 구현하여 실제로 집합을 관리하고 iterator() 메서드를 통해 ConcreteIterator 객체를 생성합니다.

inpa.tistory.com/1075

Iterator 예제 코드

1. Iterator(반복자)

// Aggregate 인터페이스 => 집합체 객체 (컬렉션)
interface Aggregate {
    Iterator<Integer> iterator();
}

2. ConcreteIterator(구체적인 반복자)

// ConcreteAggregate 클래스
class ArrayCollection implements Aggregate {

    // 데이터 집합 (컬렉션)
    private int[] collection;

    public ArrayCollection(int[] collection) {
        this.collection = collection;
    }

    //내부 컬렉션을 인자로 넣어 이터레이터 구현체를 클라이언트에 반환
    @Override
    public Iterator<Integer> iterator() {
        return new ArrayIterator(collection);
    }
}

3. Aggregate(집합체)

// 반복체 객체
interface Iterator<T> {
    boolean hasNext();
    T next();
}

4. ConcreteAggregate(구체적인 집적체)

// ConcreteIterator 클래스
class ArrayIterator implements Iterator<Integer> {
    private int[] collection;
    private int position; // 커서 (for문의 i 변수 역할)
    
    // 생성자로 순회할 컬렉션을 받아 필드에 참조 시킴
    public ArrayIterator(int[] collection) {
        this.collection = collection;
        this.position = 0;
    }

    // 순회할 다음 요소가 있는지 true / false
    @Override
    public boolean hasNext() {
        return position < collection.length;
    }

    // 다음 요소를 반환하고 커서를 증가시켜 다음 요소를 바라보도록 한다.
    @Override
    public Integer next() {
        return collection[position++];
    }
}

`Main`코드

// 클라이언트 코드
public class Main {
    public static void main(String[] args) {

        // 1. 집합체 생성
        int[] arr = {1, 2, 3, 4, 5};
        ArrayCollection collection = new ArrayCollection(arr);

        // 2. 집합체에서 이터레이터 객체 반환
        Iterator<Integer> iterator = collection.iterator();
        
        // 3. 이터레이터 내부 커서를 통해 순회
        while (iterator.hasNext()) {
            int element = iterator.next();
            System.out.println(element);
        }
    }
}

이터레이터 패턴의 장점과 단점

장점

일관된 이터레이터 인터페이스를 사용해 여러 형태의 컬렉션에 대해 동일한 순회 방법을 제공한다.
컬렉션의 내부 구조 및 순회 방식을 알지 않아도 된다.
집합체의 구현과 접근하는 처리 부분을 반복자 객체로 분리해 결합도를 줄 일 수 있다.

단점

클래스가 늘어나고 복잡도가 증가한다.
구현 방법에 따라 캡슐화를 위배할 수 있다.

마치며

컬렉션에 대한 순회 논리를 Iterator에 위임함으로써 코드의 확장성이 증가하고, 새로운 컬렉션을 추가하거나 기존 컬렉션의 내부 구조를 변경해도 클라이언트 코드를 수정할 필요가 없다는 점이 눈에 띄게 좋았다. 이러한 경험을 통해 디자인 패턴이 어떻게 코드의 품질을 향상시키고 유지보수를 용이하게 만드는지에 대해 조금은 더 알게된것 같다.

프록시 서버 (Proxy Server)

Sun, 02 Jul 2023 00:00:00 GMT

프록시서버의 의미

프록시서버는 서버와 클라이언트 사이에서 클라이언트가 자신을 통해 다른 네트워크서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용프로그램을 말합니다.

https://surfshark.com/ko/blog/proxy-server

프록시 서버의 동작원리

프록시 서버는 사용자를 인터넷에서 분리하는 중간서버 역활을 하기 때문에 프록시 서버가 없다면 트래픽이 직접 웹사이트로 흐르게 되고, 프록시 서버를 사용하면 요청한 웹사이트에 이동전에 트래픽이 프록시로 먼저 이동하게 됩니다. 여기서 웹사이트에서의 모든 응답도 프록시 서버에 먼저 갔다가 사용자에게 전달 됩니다.

프록시 서버의 사용

CloudFlare

CloudFlare는 전세계적으로 분산된서버가 있고 이를 통해 어떠한시스템의 콘텐츠전달을 빠르게 할 수 있는 CDN 서비스 입니다. CloudFlare를 사용하여 누릴 수있는 이점으로는 DDOS 공격 방어, HTTPS구축이 있습니다.

프록시 서버를 사용하는 이유

1. 익명성 유지

프록시 서버를 사용하면 웹 요청을 보낼 때 실제 IP 주소를 숨길 수 있습니다. 이는 개인 정보 보호와 익명성을 유지할 수 있도록 도와줍니다. 특히 공용 Wi-Fi 네트워크나 공공 장소에서 인터넷을 사용할 때 개인 정보를 보호하는 데 도움이 됩니다.

2. 지리적 제한 우회

일부 웹 사이트나 온라인 서비스는 특정 지역에서만 이용 가능하도록 설정되어 있습니다. 프록시 서버를 사용하면 자신의 위치를 숨기고 다른 지역으로 연결하여 이러한 지리적 제한을 우회할 수 있습니다.

3. 캐시와 가속

프록시 서버는 인터넷 트래픽을 캐시하여 효율적으로 관리할 수 있습니다. 이는 웹 페이지 로딩 속도를 향상시키고 대역폭 사용을 줄여줍니다. 특히 동일한 내용을 반복해서 요청하는 경우에는 프록시 서버에서 캐시된 데이터를 제공함으로써 웹 페이지의 응답 속도를 크게 개선할 수 있습니다.

보안 및 필터링

프록시 서버는 웹 트래픽을 모니터링하고 보안 위협이나 악성 소프트웨어를 차단하는 데 도움을 줄 수 있습니다. 특히 기업이나 학교에서는 프록시 서버를 사용하여 내부 네트워크 보안을 강화하고 웹 필터링 정책을 적용하는 경우가 많습니다.

콘텐츠 제어

프록시 서버를 사용하면 특정 유형의 콘텐츠에 대한 액세스를 제어할 수 있습니다. 예를 들어, 부적절한 콘텐츠를 차단하거나 특정 웹 사이트에 대한 액세스를 제한할 수 있습니다. 이는 가정이나 조직에서 인터넷 사용 정책을 시행하거나 부모가 자녀의 온라인 활동을 관리하는 데 도움이 됩니다.

프록시 패턴 (Proxy Pattern)

Sun, 02 Jul 2023 00:00:00 GMT

들어가며

프록시 패턴을 설명하기 전 먼저 프록시의 의미부터 설명하겠습니다. 우리는 소프트웨어 기술에서 종종 '프록시'라는 용어를 듣게 되는데 리버스프록시,프록시서버, lazy전략에서 사용되는 프록시객체, 프록시패턴 등등 프록시란 '대리'라는 의미로 프록시에게 어떤 일을 대신시키는 것입니다. 대신 중요한 건 클라이언트 쪽에서 실제 실행시킬 클래스에 대한객체를 통해 메서드를 호출하고 반환 값을 받는지, 대리자 객체를 통해 메서드를 호출하고 반환 값을 받는지 전혀 모르게 처리한다는 것입니다. 예를 들어 보안분야에서, 보안상의 이유로 서버를 외부에 노출시키지 않기 위해 서버와 클라이언트단 중간에서 접점을 담당하는 서버를 보고 프록시서버라고 부릅니다.

https://refactoring.guru/design-patterns/proxy

프록시 패턴

프록시 패턴은 대상 객체에 접근하기 전 그 접근에 대한 흐름을 가로채서 대상 객체 앞단의 인터페이스 역할을 하는 디자인 패턴
이를 통해 객체의 속성. 변환 등을 보완하며 보안, 데이터검증, 캐싱, 로깅에 사용합니다.

클라이언트가 어떤 일에 대한 요청(RealSubject의 request() 메서드 호출)을 하면, Proxy가 대신 RealSubject의 request()메서드 호출을 하고 그 반환 값을 클라이언트에게 전달합니다.

위 그림을 코드로 구현해 보겠습니다.

`Subject.interface`

public interface Subject {
    String request();
}

`RealSubject.class`

public class RealSubject implements Subject {
    @Override
    public void request(){
        return "Proxy Pattern";
    }
}

`Proxy.class`

public class Proxy implements Subject {
    private final RealSubject realSubject = new RealSubject();
    
    @Override
    public String request() {
        return RealSubject.request(); // 프록시가 실제 메소드를 호출한다.
    }
}

`main.class`

public static void main(String[] args) {
    // Subject클래스의 메소드를 호출하는이 아닌 프록시클래스의 메소를 호출한다.
    Subject subject = new Proxy();
    System.out.println(subject.request()); // 내부적으로 Subject의 메소드를 호출한다.
}

위 코드에서 인터페이스를 중간에 두어서 구체클래스들에게 영향을 받지 않도록 구성되어 있고, 직접 접근하지 않고 Proxy를 통해 한번 더 우회하여 접근하게 되어있습니다.

프록시 패턴을 사용하는 이유

1. 흐름을 제어할 수 있다.

https://refactoring.guru/design-patterns/proxy

위 사진처럼 많은 양의 리소스를 필요로 하는 상황에서 DB쿼리가 매우 느려질 수 있다. 이런 상황에서는 지연초기화를 위한 코드 작성을 필요로 하는데 이를 모든 클래스에 직접 넣게 되면 많은 코드중복이 발생하게 된다.

https://refactoring.guru/design-patterns/proxy

위 사진처럼 프록시객체를 사용한다면 프록시객체가 먼저 리소스요청을 받게 되고 흐름을 제어하면서 DB에 쿼리를 날릴 수 있게 된다.

2. 실제 메서드가 호출되기 이전에 필요한 기능(전처리등의)을 구현객체 변경 없이 추가할 수 있다.

코드변경의 최소화

3. 캐시를 사용할 수 있다.

프록시가 내부캐시를 통해 데이터가 캐시에 존재하지 않는 경우에만 주체클래스에서 작업이 실행되도록 할 수 있다.

마치며

프록시 패턴은 중요한 디자인 상황에서 객체에 대한 간접적인 접근을 제공하면서, 프록시는 코드의 변화에 대응하는 데 도움이 되어 유지보수성을 향상시키는데 기여한다. 그러나 동시에 프록시 패턴을 적용할 때는 코드 중복, 복잡성, 그리고 성능 저하와 같은 단점들도 고려해야 한다. 이러한 측면들을 극복하기 위해서는 디자인을 신중하게 계획하고 패턴을 적용할 때의 상황을 명확히 이해해야 한다고 생각한다. 프록시 패턴은 어떤 상황에서는 필수적인 해결책이 될 수 있지만, 언제 사용해야 하는지에 대한 판단이 필요하다.

Git 기본 명령어

Tue, 27 Jun 2023 00:00:00 GMT

Git 저장소 생성

$ git init

기본 브랜치 이름 변경

$ git config --global init.defaultBranch 변경할_브랜치_이름

현재 상태 확인

$ git status

전체 로그 확인

$ git log

Staging area로 파일 이동시키기

$ git add .

저장소 복제 및 다운로드

$ git clone https://github.com/{GITHUB_NAME}/{REPOSITORY_NAME}.git

파일을 Local repository에 저장하고 버전을 기록(commit)

$ git commit -m "message"

Remote repository로 업로드

$ git push origin master

원격 저장소의 변경 내용을 현재 디렉토리로 가져오기 (pull)

$ git pull

Remote repository와 Local repository를 연결

$ git remote --v

브랜치 삭제

$ git branch -d [브랜치명]

현재 브랜치에 다른 브랜치 수정사항 병합

$ git merge [다른 브랜치명]

복사할 코드가 있는 Rmote Repository의 코드를 내 Rmote Repository로 복사

$ Fork

상대의 Rmote Repository 주소를 내 Local Repository와 연결

$ git rmote add pair [상대의 Rmote Repository 주소]

연결된 주소들의 목록 확인

$ git rmote -v

파일 수정

$ nano [파일이름]

수정한 파일을 staging area에 추가 (commit 전)

$ git add [파일이름]

commit이 되지 않은 파일을 폐기

$ git restore [파일이름]

staged된 파일을 이전 상태로 되돌림

$ git restore --staged

Java 문자열(String)

Tue, 27 Jun 2023 00:00:00 GMT

자바에서 String은 텍스트 데이터를 저장하고 조작하는 데 사용되는 클래스입니다. String 클래스는 자바의 내장 클래스로, java.lang 패키지에 속해 있으므로 추가적인 임포트 없이 사용할 수 있습니다. String 객체는 한 번 생성되면 변경할 수 없는 불변(immutable) 객체이기 때문에 문자열을 수정하면 실제로는 새로운 문자열 객체가 생성되는 것이며, 원래의 문자열은 그대로 유지됩니다.

String 객체는 문자열 리터럴로 초기화하거나 new 키워드를 사용하여 생성할 수 있습니다.

String name1 = "Hello!"; // 문자열 리터럴을 사용한 초기화
String name2 = new String("dudu"); // new 키워드를 사용한 생성

출처: https://www.digitalocean.com/community/tutorials/what-is-java-string-pool

String 클래스는 다양한 메서드를 제공하여 문자열을 조작하고 검색하는 데 사용할 수 있습니다. 일반적인 메서드에는 문자열의 길이를 반환하는 length(), 두 문자열을 연결하는 concat(), 특정 문자 또는 문자열을 포함하는지 확인하는 contains(), 문자열을 분할하는 split(), 대소문자 변환을 수행하는 toLowerCase() 와 toUpperCase() 등이 있습니다.

`length()`

문자열의 length() 메서드는 해당 문자열의 길이(문자의 개수)를 반환합니다.

String name1 = "Hello!"; // 문자열 리터럴을 사용한 초기화
String name2 = new String("dudu"); // new 키워드를 사용한 생성

System.out.println(name1.length()); //출력값: 6
System.out.println(name2.length()); //출력값: 4

`concat()`

자바의 concat() 메서드는 문자열(String)에 다른 문자열을 이어붙일 때 사용하는 메서드입니다.

String name1 = "Hello!"; // 문자열 리터럴을 사용한 초기화
String name2 = new String("dudu"); // new 키워드를 사용한 생성
String result = name1.concat(name2); //concat을 이용하여 이어붙임

System.out.println(result); //출력값: Hello!dudu

`contains()`

자바의 contains() 메서드는 문자열(String)이 특정 문자열을 포함하고 있는지를 확인하기 위해 사용되는 메서드입니다. contains() 메서드는 호출된 문자열에 대상 문자열이 포함되어 있는 경우 true를 반환하고, 포함되어 있지 않은 경우 false를 반환합니다.

String name1 = "Hello!"; // 문자열 리터럴을 사용한 초기화
String name2 = new String("dudu"); // new 키워드를 사용한 생성
boolean result = name2.contains("du"); //contains을 이용하여 문자열을 포함하는지 확인

System.out.println(result); //출력값: true

변수를 사용하여 동적으로 포함 여부를 확인할 수도 있습니다.

String name1 = "Hello"; // 문자열 리터럴을 사용한 초기화
String name2 = new String("Hello, dudu"); // new 키워드를 사용한 생성
boolean result = name2.contains(name1); //contains을 이용하여 문자열을 포함하는지 확인

System.out.println(result); //출력값: true

contains() 메서드는 대소문자를 구분하여 문자열을 비교합니다. 따라서 "World"와 "world"는 서로 다른 문자열로 처리됩니다. 문자열을 대소문자 구분 없이 비교하고 싶다면, toLowerCase() 또는 toUpperCase()를 이용하여 대문자 또는 소문자로 통일한 후 contains() 메서드를 사용할 수 있습니다.

String name1 = "Hello"; // 문자열 리터럴을 사용한 초기화
String name2 = new String("Hello, dudu"); // new 키워드를 사용한 생성

//toUpperCase를 이용하여 name2 문자열을 대문자로 변경 후 특정 문자열을 포함하는지 확인
boolean result = name2.toUpperCase().contains("DUDU"); 

System.out.println(result); //출력값: true

Java 정수타입

Sun, 25 Jun 2023 00:00:00 GMT

자바는 정수타입을 4가지 타입으로 나눌 수 있습니다.

byte, short, int, long 4가지이며, 각각의 차지하는 메모리가 다르고, 나타낼수 있는 숫자의 범위가 다르다.

타입	메모리	범위
byte	1byte	-128( $-2^{7}$ ) ~ 127( $2^{7} - 1$ )
short	2byte	-32,768( $-2^{15}$ ) ~ 32,767( $2^{15} - 1$ )
int	4byte	-2,147,483,648( $-2^{31}$ ) ~ 2,147,483,647( $2^{31} - 1$ )
long	8byte	-9,223,372,036,854,775,808( $-2^{63}$ ) ~ 9,223,372,036,854,775,807( $2^{63} - 1$ )

// 각 데이터 타입의 범위에 맞는 값을 할당 
byte  byteNum  = 123;
short shortNum = 12345;
int   intNum   = 123456789;
long  longNum  = 12345678910L;

// 각 데이터 타입의 범위에 벗어난 값을 할당하고 있어 에러가 발생 
byte  byteNum  = 130;
short shortNum = 123456;
int   intNum   = 12345678910;

// 숫자가 길면 언더바로 구분 
int   intNum   = 12_345_678_910;
long  longNum  = 12_345_678_910L;

long타입의 경우에는 값 뒤에 접미사 L,l 을 붙여주어서 구분합니다. (일반적으로 대문자 L을 사용)

Java 정수형의 오버플로우와 언더플로우

Sun, 25 Jun 2023 00:00:00 GMT

코드를 작성 후 실행 중일때, 타입의 정해진 범위를 넘는 경우가 발생할 수 있다.

예를 들어 byte타입의 경우 127까지 표현 가능하지만, byte타입이 127을 넘을 결우 오버플로우가 발생한다.

반대의 경우 byte타입이 -128보다 값이 적을경우에 최소값을 넘기 때문에 언더플로우가 발생한다.

//정수 오버플로우, 언더플로우의 예시
public static void main(String[] args) {

    byte Of = 125;
    byte Uf = -125;

    byte result = (byte) (Of + 10);
    byte result2 = (byte) (Uf - 10);

    System.out.println(result); // 오버플로우 발생 : -121
    System.out.println(result2); // 언더플로우 발생 : 121

}

컴파일 에러가 발생하지 않았지만, 제대로된 값을 얻지 못했다. 그 이유는 byte형의 범위를 넘었기 때문이다. 올바른 값을 얻기위에서는 byte타입이 아닌 int타입이어야 한다.

정수형의 오버플로우와 언더플로우는 컴파일러가 오버플로우, 언더플로우를 무시해서 잘못된 값이 저장되기 때문에 발생한경우 알아보기 힘들어서 매우 위험하다. 정해진 연산을 처리하면서 잘못된 결과로 프로그램의 오작동을 발생할수 있고, 보안에 취약한 부분을 내포하게 된다.

오버플로우와 언더플로우를 피하는 안전한 코딩법

언어 ・ 플랫폼별 정수 타입의 범위를 확인하여 사용
정수형 변수를 연산에 사용하는 경우 결과 값의 범위를 체크하는 모듈을 사용
외부입력값을 동적 메모리 할당에 사용하는 경우, 변수값이 적절한 범위 내에 존재하는지 값인지 확인

타입별 범위 확인

각 타입별 허용 범위는 각 타입별 클래스의 MINVALUE(최소값), MAXVALUE(최대값) 메소드를 통해 타입의 범위를 확인할 수 있다.

System.out println"char: " + (int)Character.MIN_VALUE + " ~ " + (int) Character. MAX_VALUE) ;

System.out.println("byte: " + Byte.MIN_VALUE + " ~ " + (int)Byte.MAX_VALUE) ;

System.out.println("short:" + Short. MIN_VALUE + " ~ " + Short. MAX_VALUE) ;

System.out.println("int: " + Integer MIN_VALUE + " ~ " + Integer.MAX_VALUE) ;

System.out.println("long: " + Long.MIN_VALUE + " ~ " + Long.MAX_VALUE) ;

System.out.println("float: " + Float. MIN_VALUE + " ~ " + Float.MAX_VALUE) ;

System. out. println("double:" + Double. MIN_VALUE + " ~ " + Double. MAX_VALUE) ;

결과

char: 0 ~ 65535
byte: -128 ~ 127
short: -32768 ~ 32767
int: -2147483648 ~ 2147483647
Long: 9223372036854775808 ~ 9223372036854775807
float: 1.4-45 ~ 3.4028235E38
double: 4.9E-324 ~ 1.7976931348623157E308

☕️Java 개발 환경 구축 (2)

Wed, 10 May 2023 00:00:00 GMT

이번 글에서는 IntelliJ 설치를 해보려고 합니다.

IntelliJ는 IDE 중 하나로 stackOverflow 커뮤니티의 매년 개발자 설문조사 실행하는데 "전 세계 개발자에게 인기 있는 개발툴 TOP 5"에 들어갈 정도로 많이 사용하는 IDE 중 하나로 알고 있다.

IntelliJ의 장단점

1. IntelliJ 다운로드에 접속 후 다운로드

2. IntelliJ 아이콘을 화살표 방향대로 드래그

☕️Java 개발 환경 구축 (1)

Tue, 09 May 2023 00:00:00 GMT

오늘은 자바의 개발 환경을 구축하기 위해 JDK 설치와 IntelliJ 설치해보려고 한다.

Mac M1 사용중이기 때문에 Mac 기반으로 작성 되었습니다.

JDK는 Zulu openJDK 사용
IntelliJ는 Community Edition 사용

Zulu openJDK의 장점

멀티 플랫폼 지원: Zulu OpenJDK는 Windows, macOS, Linux 및 다른 운영 체제에서 실행할 수 있다. 이는 Java 프로그램을 개발하고 배포하는 데 있어서 대규모 시스템에서 이식성이 높은 솔루션을 제공한다.
Java SE 호환성: Zulu OpenJDK는 Java SE의 최신 버전과 호환된다. 이는 Java SE API와 플랫폼 특성을 모두 지원하며 Java SE에서 작성된 코드가 Zulu OpenJDK에서 작동할 수 있도록 한다.
안전한 애플리케이션 개발: Zulu OpenJDK는 Java 애플리케이션에서 발생할 수 있는 보안 취약점을 예방하는 기능을 제공한다. 이는 Java 애플리케이션 개발자들에게 높은 수준의 보안성을 제공합니다. 또한 Zulu OpenJDK는 업데이트와 유지보수가 지속적으로 이루어지며, Azul Systems는 기술 지원과 컨설팅 서비스를 제공하므로 개발자들이 안심하고 Java 애플리케이션을 개발할 수 있도록 도와준다.

1. Zulu openJDK 다운로드 페이지 접속 후 Java의 버전, OS, Architecture 를 선택

2. dmg를 선택하여 다운로드

3. 다운로드 완료 후 실행 하시고 오른쪽 박스 클릭

4. 계속 눌러주면 설치 완료

🤩 4. 그 외 팁들

Sun, 04 Apr 2021 00:00:00 GMT

파비콘은 어떻게 변경하나요?

static/favicon.png 에 파비콘 파일이 위치해 있습니다. 이미지 파일을 대체하면 파비콘을 변경할 수 있습니다.

만약 파비콘 파일의 이름을 변경하고 싶다면, gatsby-config.js 파일의 gatsby-plugin-manifest 에서 icon 속성을 변경하셔야합니다.

Utterance 가 제대로 작동하지 않아요.

http 환경에서는 Utterance 가 제대로 작동하지 않을 수 있습니다. 여러분의 웹사이트를 https 환경으로 제공하세요.

OG Image 를 설정하고 싶어요.

/static 디렉토리의 og-image.png 파일을 여러분이 원하는 이미지 파일로 대체하세요.

다른 질문이 있으신가요?

이 문서에 댓글을 달거나 gatsby-starter-hoodie 레포지토리에 이슈를 열어주세요. 여러분의 참여가 gatsby-starter-hoodie 를 더욱 발전시킵니다. 감사해요 😎.

🤔 3. 작성 가이드

Sat, 03 Apr 2021 00:00:00 GMT

1. 포스트 추가하기

contents/post 경로에 새로운 마크다운 파일을 생성하여 여러분의 글을 추가할 수 있습니다.

1-1. 포스트 파일 구조

새로운 문서를 추가하는 방법에는 두가지가 있습니다. 첫번째는 디렉토리 없이 문서를 생성하는 방법입니다. 만약 여러분이 Javascript 에 관한 문서를 생성한다면, about-javascript.md 파일을 contents/posts 디렉토리에 추가할 수 있습니다.

두번째 방법은 먼저 디렉토리를 생성한 뒤, 디렉토리 안에 index.md 파일을 추가하는 것 입니다. 이 방법은 문서 내에 여러 이미지 파일 등 부수적인 파일 여러개가 포함되었을 때 유용합니다.

첫번째 방법으로 생성한 파일명이나, 두번째 방법으로 생성한 디렉토리 이름은 웹사이트에서 고유의 주소를 갖습니다. https://siteURL/about-javascript 와 같이요.

1-2. Frontmatter

마크다운은 문서의 메타데이터인 Frontmatter 라 불리는 정보를 가지고 있습니다.

---
title: "🤔 3. 작성 가이드"
description: "어떻게 글을 작성하고 추가할까요?"
date: 2021-04-03
update: 2021-04-03
tags:
  - hoodie
  - writing-guide
series: "gatsby-starter-hoodie 로 블로그 시작하기"
---

위는 지금 여러분이 읽고 있는 문서의 Frontmatter 입니다. title 과 date 는 필수 값입니다. 띄어쓰기를 포함된 문자열을 입력할 때에는 따옴표로 감싸는 것을 추천합니다.

1-3. 마크다운 작성하기

만약 Frontmatter 까지 작성했다면, 여러분은 그 아래에 마크다운 문서를 작성하면 됩니다. gatsby-starter-hoodie 는 대부분의 마크다운 문법을 지원합니다. 마크다운 작성 방법을 알고 싶다면, Github 의 Mastering Markdown 문서를 참고하세요.

2. 코드 하이라이팅 & Katex

2-1. 코드 하이라이팅

Prism.JS 에 기반한 코드 하이라이팅이 제공됩니다.

예시

Javascript

console.log("Hello, world!")

Python

print("Hello, world!")

그 외 더 많은 언어를 제공합니다. 제공되는 언어를 확인하고 싶다면, Prism.js 웹사이트 를 참고하세요.

2-2. Katex

Katex 문법을 지원하여 복잡한 수식도 쉽게 표현할 수 있습니다.

인라인 모드

$E = m c^{2}$

블럭 모드

\int_{0}^{\infty} f(x) dx

3. 글에 이미지 추가하기

상대경로를 이용하여 쉽게 이미지를 추가할 수 있습니다. 디렉토리를 생성하고 그 안에 index.md 를 추가하여, 글을 추가하는 방법으로 작성해야 이미지 관리가 쉽습니다.

샘플 이미지 캡션

이미지는 Lazy Loading 으로 로드되어, 빠른 초기 문서 로딩 속도를 확보할 수 있습니다.

⚠ 이미지의 모든 확장자는 소문자여야합니다.

4. 태그

Frontmatter 의 태그를 통해 쉽게 문서를 분류하고 검색할 수 있습니다. 여러분의 모든 태그는 https://siteUrl/tags 경로에서 확인하고, 검색할 수 있습니다.

5. 시리즈

여러분이 연관된 여러개의 문서를 작성할 때 시리즈를 사용할 수 있습니다. Frontmatter 에 작성된 시리즈가 같은 문서끼리 묶여 문서 상단에 리스트로 표시됩니다. 시리즈는 일련의 순서가 있는 문서들을 작성할 때 유용하게 사용할 수 있습니다. 시리즈는 문서의 작성 날짜 순서대로 정렬됩니다.

현재 문서는 gatsby-starter-hoodie 로 블로그 시작하기 라는 시리즈로 설정되어 있습니다.

🚀 2. 빠르게 시작하기

Fri, 02 Apr 2021 00:00:00 GMT

아래 단계를 따라서 여러분의 블로그를 시작하세요. 굉장히 쉬워요 😉.

1. Gatsby 사이트 생성

컴퓨터에 node.js 와 gatsby-cli 가 설치되어 있어야합니다.

$ npx gatsby new my-hoodie-blog https://github.com/devHudi/gatsby-starter-hoodie

2. 개발 서버 시작

$ cd my-hoodie-blog
$ npm run start

이제 localhost:8000 으로 여러분의 블로그를 접속할 수 있습니다.

3. Github 레포지토리 생성

Utterance 댓글 위젯은 Github 이슈 시스템 기반입니다. 따라서 각 블로그 별 Github 레포지토리가 필요합니다. 또한 여러분이 Github Pages 혹은 Netlify 로 블로그를 배포하길 원한다면, Github 레포지토리는 필수입니다.

만약 Github 레포지토리를 생성하는 법을 모른다면, Github 공식 문서 를 참조하세요.

원격 레포지토리 등록

git remote add origin https://github.com/{YOUR_GITHUB_NAME}/{YOUR_REPOSITORY_NAME}

4. blog-config.js 작성

module.exports = {
  title: "MY BLOG",
  description: "Hello, This is my blog",
  author: "YOUR NAME",
  siteUrl: "https://myblog.com",
  links: {
    github: "https://github.com",
    facebook: "https://www.facebook.com",
    instagram: "https://www.instagram.com",
    etc: "https://www.google.com/",
  },
  utterances: {
    repo: "{YOUR_GITHUB_NAME}/{YOUR_REPOSITORY_NAME}",
    type: "pathname",
  },
}

gatsby-starter-hoodie 는 blog-config.js 라는 설정 파일을 제공합니다. 이 파일에서 블로그 정보, 작성자 프로필, Utterance 설정 등을 작성할 수 있습니다. 여러분 블로그 설정에 맞게 blog-config.js 를 설정하세요. 하지만, utterances.type 속성은 수정하지 않는 것을 권장합니다.

프로필 이미지 변경

static/profile.png 에 위치한 이미지 파일을 원하는 이미지 파일로 교체하세요. 만약 파일명을 변경하고 싶다면, src/components/Bio.jsx 의 소스코드를 수정해야합니다.

5. 포스트 추가

마크다운 포스트는 contents/posts 경로에 위치해있습니다. 해당 경로에서 글을 작성할 수 있습니다. 여기를 클릭하여 더 자세한 글 작성 방법을 확인하세요.

6. 블로그 배포하기

6-1 Netlify 를 통해

A Step-by-Step Guide: Gatsby on Netlify 문서를 참조하여, Netlify 를 Github 레포지토리와 연결할 수 있습니다. 이 과정은 어렵지 않습니다.

Github 레포지토리와 연결이 되었다면, Github 레포지토리에 변경사항이 발생할 때 마다 자동으로 여러분의 블로그에 배포됩니다.

6-2. Github Pages 를 통해

상황 1

레포지토리 이름이 {YOUR_GITHUB_NAME}.github.io 형태일 경우, 아래 명령어를 실행해주세요.

$ npm run deploy-gh

상황 2

레포지토리 이름이 {YOUR_GITHUB_NAME}.github.io 형태가 아닐 경우, 아래 명령어를 실행해주세요.

$ npm run deploy-gh-prefix-paths

만약 위와 같은 경우 gatsby-config.js 에서 pathPrefix 를 여러분의 레포지토리 이름으로 바꿔야합니다.

6-3. 다른 플랫폼

$ npm run build

위 명령어로 Gastby 웹사이트를 빌드할 수 있습니다. 빌드 결과물은 /public 에 저장됩니다. /public 디렉토리를 여러분이 사용하는 플랫폼의 배포 명령을 통해 배포해주세요.

7. 커스터마이징

프로젝트 구조

아래 프로젝트 구조를 참고하여 커스터마이징 할 수 있습니다 🙊.

├── node_modules
├── contents
│   └── posts // your articles are here
├── public // build outputs are here
└── src
    ├── assets
    │   └── theme // theme config is here
    ├── components
    │   └── Article
    │       └── Body
    │           └── StyledMarkdown
    │               └── index.jsx // markdown styles are here
    │   ...
    ├── fonts // webfonts are here
    ├── hooks
    ├── images
    ├── pages // page components are here
    ├── reducers
    ├── templates // post components are here
    └── utils

🎇 1. gatsby-starter-hoodie 에 대하여

Thu, 01 Apr 2021 00:00:00 GMT

gatsby-starter-hoodie 에 대하여

gatsby-starter-hoodie 는 기술 블로그를 작성하기 위해 개발된 Gatsby 테마입니다. 마크다운과 많은 프로그래밍 언어의 코드 하이라이팅, 그리고 Katex 문법을 지원합니다. 또한 태그와 시리즈를 통하여 쉽게 게시물을 분류할 수 있습니다.

다크모드를 지원하는 깔끔한 디자인의 gatsby-starter-hoodie 로 여러분의 블로그를 시작하세요.

주요 기능

마크다운
코드 하이라이팅
Katex 문법
다크모드 (OS 환경설정과 연동)
태그 분류
시리즈 분류
반응형 웹
SEO
Utterance (댓글 위젯)

시작

빠르게 시작하기 문서에서 블로그를 세팅하세요.