개발개굴

[JPA] 영속성 컨텍스트

개발개굴 — Sun, 13 Jul 2025 20:33:05 +0900

JPA(Java Persistence API)를 이해하는 데 있어 가장 중요한 개념은 영속성 컨텍스트(Persistence Context)입니다. 영속성 컨텍스트는 엔티티의 생명주기를 관리하고 데이터베이스 접근을 최적화하는 핵심적인 역할을 수행합니다.

이 글은 영속성 컨텍스트를 통해 JPA의 내부 동작을 이해하기 위해 작성되었습니다.

1. 엔티티 매니저 팩토리와 엔티티 매니저

JPA 애플리케이션은 데이터베이스와의 연결을 관리하고 엔티티를 조작하기 위해 엔티티 매니저 팩토리와 엔티티 매니저를 사용합니다.

// 엔티티 매니저 생성 (영속성 컨텍스트 생성)
EntityManager em = emf.createEntityManager();

// 트랜잭션 시작
EntityTransaction transaction = em.getTransaction();
transaction.begin();

// ...엔티티 조작...

// 트랜잭션 커밋
transaction.commit();

EntityManagerFactory는 애플리케이션 실행 시점에 단 하나만 생성되는 객체
데이터베이스 연결 정보, JPA 설정 등을 바탕으로 EntityManagerFactory에 의해 EntityManager가 생성
EntityManager는 실제 엔티티를 저장/조회/수정/삭제 하는데 사용되며, 영속성 컨텍스트에 접근하는 통로 역할
(내부적으로 데이터베이스 커넥션을 사용하여 데이터베이스에 접근)

2. 영속성 컨텍스트와 엔티티의 생명 주기

엔티티를 영구적으로 저장하는 환경이라는 논리적인 개념으로, EntityManager가 생성될 때 함께 생성됩니다.

영속성 컨텍스트 내에서 4가지 상태를 가지는 엔티티를 관리합니다.

엔티티의 생명주기

2.1. 비영속 (New/Transient)

// 객체를 생성
Member member = new Member();

영속성 컨텍스트와 전혀 관계가 없는 새로운 상태
객체를 생성했지만 아직 EntityManager에 저장되지 않음

2.2. 영속 (Managed)

// 객체를 영속화
em.persist(member);

영속성 컨텍스트에 관리되는 상태
persist()를 통해 영속 상태로 전환되거나, 데이터베이스에서 조회되어 영속성 컨텍스트에 로드
영속 상태의 엔티티는 1차 캐시에 저장되며, Dirty Checking(변경 감지)의 대상

** Spring Data JPA의 save() 메서드는 새로운 엔티티라면 내부적으로 em.persist()를 호출

2.3. 준영속 (Detached)

// 영속성 컨텍스트에서 분리
em.detach(member);

영속성 컨텍스트에 저장되었다가 분리된 상태
detach()를 호출하거나, 트랜잭션이 종료되면 발생

2.4. 삭제 (Removed)

// 삭제 상태로 전환
em.remove(member);

영속성 컨텍스트에서 삭제된 상태
remove()를 호출하여 삭제 상태로 전환

3. 영속성 컨텍스트의 이점

3.1. 1차 캐시

영속성 컨텍스트 내부에 존재하는 캐시 공간

// 1차 캐시에 저장됨
em.persist(member);

// 1차 캐시에서 조회
Member findMember = em.find(Member.class, "member1");

persist()를 통해 영속성 컨텍스트에 저장된 객체를 다시 조회하면 DB가 아닌 컨텍스트에서 조회
만약, 1차 캐시에 없다면 DB에서 조회 후 1차 캐시에 저장 (이때, 바로 영속 상태가 됨)
동일한 트랜잭션 내에서 엔티티의 동일성을 보장하며, 반복적인 읽기 작업의 성능 향상

3.2. Dirty Checking(변경 감지)

// 영속 엔티티 조회
Member memberA = em.find(Member.class, "memberA");

// 영속 엔티티 데이터 수정
memberA.setUsername("hi");
memberA.setAge(10);

// 자동으로 UPDATE 쿼리를 실행합니다.

1차 캐시 안의 영속 상태 엔티티와 스탭샷을 비교하여 변경을 감지하여, JPA가 자동으로 변경된 내용을 감지하여 데이터베이스에 반영
JPA는 flush()를 통해 transaction.commit() 호출 시점에 변경 감지, 쓰기 지연 SQL 저장소에 등록, 저장소의 쿼리를 데이터베이스에 전송하게 되는데, 이러한 트랜잭션을 지원하는 쓰기 지연 (Transcation Wirte-Behind)을 통해 모든 쿼리들을 데이터베이스에 한 번에 전송하는 배치 처리로 성능 향상과 데이터 정합성을 유지

3.2.1. @Transactional(readOnly = true)와 Dirty Checking

@Transactional(readOnly = true)는 단순히 읽기 전용 설정이나, Master/Slave 데이터베이스 환경에서 읽기 전용 DB로의 읽기 작업 분산 처리 외에도, JPA의 영속성 컨텍스트 동작에 관여하여 성능을 최적화하는 역할을 합니다.

@Transactional(readOnly = true)
public void updateMember(Member member) {
    member.setName("Changed Name");
    // 트랜잭션 커밋 시점에도 UPDATE 쿼리 발생 X
}

트랜잭션에 readOnly를 true로 적용하면, JPA는 해당 트랜잭션이 읽기 전용임을 인지하고 Dirty Checking를 수행하지 않음
스냅샷 저장 생략과 변경 감지 로직 건너뛰기를 통해 불필요한 스냅샷 비교 및 메모리 사용을 줄여 성능을 향상

[참고]
https://www.inflearn.com/course/ORM-JPA-Basic

자바 ORM 표준 JPA 프로그래밍 - 기본편 강의 | 김영한 - 인프런

김영한 | JPA를 처음 접하거나, 실무에서 JPA를 사용하지만 기본 이론이 부족하신 분들이 JPA의 기본 이론을 탄탄하게 학습해서 초보자도 실무에서 자신있게 JPA를 사용할 수 있습니다., 실무에서도

www.inflearn.com

[Spring] 비동기 환경에서 ThreadLocal 관리

개발개굴 — Sun, 25 May 2025 19:24:52 +0900

해당 포스팅은 비동기로 동작하는 스프링 프로젝트 환경에서 안전한 Context 전파 전략을 도입하기 위한 ThreadLocal과 InheritableThreadLocal 고찰에 대한 내용입니다.

1. 문제 배경

시스템에서 사용자 요청 시 고객 정보를 ThreadLocal에 저장하고, 요청 처리 전체 과정에서 일관되게 유지하고자 함
하지만, 비동기 작업 또는 스레드 풀 환경에서는 ThreadLocal의 한계로 인해 고객 정보가 전파되지 않거나, 누수/섞임 등의 문제가 발생 가능.

2. InheritableThreadLocal 도입 고려 및 문제 분석

InheritableThreadLocal은 자식 스레드가 생성될 때 부모 스레드의 값을 자동으로 복사한다는 장점을 가지고 있습니다.

2.1. InheritableThreadLocal의 내부 구조

public class AccountContext {
    public static final InheritableThreadLocal<AccountInfo> accountThreadLocal = new InheritableThreadLocal<>();
}

Thread-Main.inheritableThreadLocals
↳ key: accountThreadLocal → value: AccountInfo@0x123
Thread-Sub.inheritableThreadLocals
↳ key: accountThreadLocal → value: AccountInfo@0x123

userThreadLocal은 static으로 전역 1개
각 스레드는 자신의 ThreadLocalMap을 가짐
ThreadLocalMap의 key는 동일한 userThreadLocal 인스턴스
이 구조로 인해, 같은 키로 다른 스레드의 값을 구분해서 접근 가능

2.2. 문제점 및 한계

1) 값은 복사되지만 참조가 공유됨

mainThread → subThread로 전파 시, 값은 복사되지만 같은 객체 참조를 가짐.
즉, 자식 스레드에서 객체 내부 값을 변경하면, 부모에게도 영향을 미침.

ThreadLocalMap
- mainThread : AccountInfo@0x123
- subThread : AccountInfo@0x123

2) 객체 자체를 새로 생성하면 부모/자식 값이 분리

자식 스레드에서 new AccountInfo(...)로 새로운 객체를 set하면 부모와는 다른 값으로 분리됨.
그러나 이를 위해선 개발자가 명시적으로 객체를 새로 생성해야 하며, 자동 전파의 의미가 퇴색됨.

3) 메모리 관리 문제

ThreadLocalMap은 각 스레드마다 존재
mainThread에서 ThreadLocal.remove() 해도 자식 스레드의 값은 여전히 남아 있음.
자식 스레드에서 직접 remove하지 않으면 메모리 누수 위험 존재

4) 스레드 풀 환경에서는 값이 전파되지 않음

InheritableThreadLocal은 스레드 생성 시점에만 값 복사됨.
스레드 풀은 기존 스레드를 재사용하기 때문에, 새로 생성되지 않으면 값이 전파되지 않음.
- 일반적으로 비동기 동작을 위해서 스레드 풀을 만들어서 사용.

3. InheritableThreadLocal 보완 시도 및 한계

3.1. 불변 객체 사용

내부 상태가 바뀌지 않도록 설계
- 이미 값이 복사되어 들어 있으면 새로 생성 불가능하도록 처리
- setter 모두 제거, final 필드 사용

3.2. 전파 시 수동 복사

자식 스레드 생성 시, 수동으로 복사된 객체를 설정

3.3. 명시적 remove() 처리

자식 스레드가 종료되기 전에 ThreadLocal.remove() 호출로 메모리 누수 방지

하지만, 해당 방법들은 결국 라이프 사이클을 직접 관리할 수 없으니, 아래와 같은 한계가 여전히 남아있습니다.

자동 전파의 의미가 퇴색됨
의도치 않은 값의 복사에 대해선 명시적 remove 처리가 어려움

따라서, 스레드 풀 사용 환경에서 InheritableThreadLocal 사용 말고 다른 방법을 찾아보았습니다.

4. 결론: TaskDecorator + 일반 ThreadLocal

4.1. TaskDecorator를 활용하여 ThreadLocal값을 유지

일반 ThreadLocal 사용
TaskDecorator를 통해 부모 스레드의 값을 수동으로 복사
작업 종료 후 finally에서 remove()를 수행하여 GC 유도

public class AccountContextTaskDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(Runnable runnable) {
        AccountInfo context = AccountContext.get(); // ThreadLocal에서 값 복사
        return () -> {
            try {
                AccountContext.set(context); // 복사한 값 설정
                runnable.run();              // 원래 작업 실행
            } finally {
                AccountContext.clear();      // 누수 방지를 위해 remove()
            }
        };
    }
}

4.2. ThreadPool이 해당 TaskDecorator를 사용하도록 등록

@Configuration
public class AsyncConfig {

    @Bean(name = "asyncExecutor")
    public ThreadPoolTaskExecutor asyncExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(2);                  // 기본 쓰레드 수
        executor.setMaxPoolSize(8);                   // 최대 쓰레드 수
        executor.setQueueCapacity(100);                // 대기 큐 크기
        executor.setThreadNamePrefix("async-thread-"); // 쓰레드 이름 prefix
        executor.setTaskDecorator(new AccountContextTaskDecorator()); // 커스텀 TaskDecorator 등록
        executor.initialize();
        return executor;
    }
}

결과적으로, 아래와 같이 안전하게 고객 정보를 관리할 수 있습니다.

명확하게 Context 생명주기를 관리
비동기 환경에서도 사용자 정보를 안전하게 전파 가능
GC 누수를 방지

5. 테스트 코드

해당 코드는 위와 같은 결과를 도출하기 위해 진행한 테스트 코드입니다.

class AccountContextTest {
    static class AccountInfo {
        private String name;
        public AccountInfo(String name) {
            this.name = name;
        }
        public String getName() {
            return name;
        }
        public void setName(String name) {
            this.name = name;
        }
    }
    private static final InheritableThreadLocal<AccountInfo> accountThreadLocal = new InheritableThreadLocal<>();
    @DisplayName("자식이 필드를 변경하면 부모의 필드도 같이 변경됨")
    @Test
    void testInheritableThreadLocal_change_field_same() throws InterruptedException {
        // mainThread에서 값 셋팅
        AccountInfo accountInfo = new AccountInfo("main");
        accountThreadLocal.set(accountInfo);
        System.out.println("[" + Thread.currentThread().getName() + "] main이 설정 => " + accountThreadLocal.get().getName());
        // subThread에서 필드 값 변경
        Thread sub = new Thread(() -> {
            AccountInfo inherited = accountThreadLocal.get();// 부모로부터 참조 복사됨
            System.out.println("[" + Thread.currentThread().getName() + "] main에서 물려받음 => " + accountThreadLocal.get().getName());
            inherited.setName("sub");
            System.out.println("[" + Thread.currentThread().getName() + "] sub가 변경함 => " + accountThreadLocal.get().getName());
        });
        sub.start();
        sub.join();// subThread 종료 대기// mainThread에서 다시 값 조회 (자식이 변경한 값 확인)
        System.out.println("[" + Thread.currentThread().getName() + "] main도 변경됨 => " + accountThreadLocal.get().getName());
        // 결과: 변경되어 있어야 함
        assertThat(accountThreadLocal.get().getName()).isEqualTo("sub");
    }
    @DisplayName("자식이 객체를 변경하면 자식만 변경됨")
    @Test
    void testInheritableThreadLocal_change_object_diff() throws InterruptedException {
        // mainThread에서 값 셋팅
        AccountInfo accountInfo = new AccountInfo("main");
        accountThreadLocal.set(accountInfo);
        System.out.println("[" + Thread.currentThread().getName() + "] main이 설정 => " + accountThreadLocal.get().getName());
        // subThread에서 객체 변경
        Thread sub = new Thread(() -> {
            System.out.println("[" + Thread.currentThread().getName() + "] main에서 물려받음 => " + accountThreadLocal.get().getName());
            AccountInfo subAccountInfo = new AccountInfo("sub");
            accountThreadLocal.set(subAccountInfo);
            System.out.println("[" + Thread.currentThread().getName() + "] sub에 새로운거 넣음 => " + accountThreadLocal.get().getName());
        });
        sub.start();
        sub.join();
        // mainThread에서 확인
        System.out.println("[" + Thread.currentThread().getName() + "] main은 그대로 => " + accountThreadLocal.get().getName());
        // 결과: 변경X
        assertThat(accountThreadLocal.get().getName()).isEqualTo("main");
    }
/**
     * accountThreadLocal과 스레드 풀
     *@throwsInterruptedException     */
    @DisplayName("스레드 전파 후 main스레드 먼저 종료시 ThreadLocal값이 살아있음")
    @Test
    void testInheritableThreadLocal_main_terminate_sub_alive() throws InterruptedException {
        ExecutorService executor = Executors.newFixedThreadPool(1);
        // MainThread에서 설정
        accountThreadLocal.set(new AccountInfo("main"));
        System.out.println("[" + Thread.currentThread().getName() + "] set name = main");
        // 비동기 실행 (InheritableThreadLocal은 스레드 생성 시만 복사되므로 주의)
        executor.submit(() -> {
            // 이 쓰레드는 풀에서 재사용되므로 InheritableThreadLocal이 null일 수 있음
            AccountInfo accountInfo = accountThreadLocal.get();
            System.out.println("[" + Thread.currentThread().getName() + "] inherited? " + (accountInfo != null ? accountInfo.getName() : "null"));
            try {
                try {
                    Thread.sleep(3000);// 오래 걸리는 작업
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                System.out.println("[" + Thread.currentThread().getName() + "] 작업 완료, 읽은 값 = " + accountThreadLocal.get().getName());
            } finally {
                // 꼭 정리해줘야 함!
                accountThreadLocal.remove();
                System.out.println("[" + Thread.currentThread().getName() + "] ThreadLocal 정리 완료, 읽은 값 = " + accountThreadLocal.get());
            }
        });
        // main은 바로 응답 (remove)
        System.out.println("[" + Thread.currentThread().getName() + "] 작업 완료, 읽은 값 = " + accountThreadLocal.get().getName());
        accountThreadLocal.remove();
        System.out.println("[" + Thread.currentThread().getName() + "] remove 완료");
        System.out.println("[" + Thread.currentThread().getName() + "] remove 완료, 읽은 값 = " + accountThreadLocal.get());
        // main 대기
        Thread.sleep(4000);
        executor.shutdown();
    }
    @DisplayName("스레드 풀에서 꺼내온 스레드는 값이 복사 안됨")
    @Test
    void testInheritableThreadLocal_pool_no_inherit() throws InterruptedException {
        ExecutorService executor = Executors.newFixedThreadPool(1);
        // MainThread에서 설정
        accountThreadLocal.set(new AccountInfo("main"));
        System.out.println("[" + Thread.currentThread().getName() + "] set name = main");
        // 2번 실행 -> 1번은 새로 생성, 2번은 꺼내와서 사용
        for(int i=0;i<2;i++) {
            int cnt = i;
            executor.submit(() -> {
                try {
                    AccountInfo accountInfo = accountThreadLocal.get();
                    if (cnt == 0) {
                        System.out.print("첫번째는 새로 생성됨 => ");
                    } else {
                        System.out.print("두번째는 풀에서 꺼내옴 => ");
                    }
                    System.out.println("[" + Thread.currentThread().getName() + "] inherited? " + (accountInfo != null ? accountInfo.getName() : "null"));
                } finally {
                    accountThreadLocal.remove();
                }
            });
        }
        accountThreadLocal.remove();
        Thread.sleep(1000);
        executor.shutdown();
    }
    @DisplayName("스레드 풀 사용 시 TaskDecorator로 복사 후 실행, finally에서 remove 확인")
    @Test
    void testInheritableThreadLocal_sub_finally_remove() throws InterruptedException, ExecutionException {
        ExecutorService executor = Executors.newFixedThreadPool(1);
        accountThreadLocal.set(new AccountInfo("main"));
        System.out.println("[" + Thread.currentThread().getName() + "] 셋팅된 값 = " + accountThreadLocal.get().getName());
        Runnable originalTask = () -> {
            try {
                System.out.println("[" + Thread.currentThread().getName() + "] 복사된 값 = " + accountThreadLocal.get().getName());
            } finally {
                // 꼭 remove 해줘야 메모리 누수 방지됨
                accountThreadLocal.remove();
                System.out.println("[" + Thread.currentThread().getName() + "] remove 완료, 읽은 값 = " + accountThreadLocal.get());
            }
        };
		// TaskDecorator처럼 context 전달
        Runnable decoratedTask = () -> {
            AccountInfo parentContext = accountThreadLocal.get();
            accountThreadLocal.set(parentContext);// 상속처럼 복사
            originalTask.run();
        };
		// 실행
        executor.submit(decoratedTask).get();
		// Main context도 정리
        accountThreadLocal.remove();
        System.out.println("[" + Thread.currentThread().getName() + "] remove 완료, 읽은 값 = " + accountThreadLocal.get());
        assertThat(accountThreadLocal.get()).isNull();
        executor.shutdown();
    }
}

[참고]

[Java] 스레드 로컬(ThreadLocal)과 상속 가능한 스레드 로컬( InheritableThreadLocal)에 대하여
ThreadLocal의 내부 동작 방식은 java.lang 소스코드를 참고하여 분석

[Spring] Feign Client란?

개발개굴 — Fri, 3 Nov 2023 14:09:28 +0900

프로젝트를 진행하다 Spring 서버에서 외부 API와 통신하는 서버 to 서버 통신을 하게되는 경우가 발생합니다.

이러한 경우에 사용할 수 있는 Feign Client에 대해 알아보겠습니다.

Feign Client 란?

Feign Client를 한마디로 정리하자면 Netflix에서 개발된 Http Client Binder입니다. Spring Boot 환경에서 다른 서버의 Api를 호출하기 위해 사용하게 됩니다.

아래와 같이 단순하기 때문에 비즈니스 로직에 더 집중할 수 있게 도와줍니다.

장점

HTTP API를 균일하게 바인딩하여 복잡성을 줄임
RestTemplate방식과 WebClient방식보다 단순
웹 서비스 클라이언트를 쉽게 작성할 수 있음
- Interface를 작성하고 Annotaion을 선언하면 끝
- Jpa가 실제 쿼리를 작성하지 않고 Interface만 지정하여 쿼리 실행 구현체를 자동으로 만드는것과 유사함

이러한 장점들로 인해 비즈니스 로직에 더 집중할 수 있게 도와줍니다.

OkHttp

Feign에서 제공하는 Http Client 중 1개
- 비동기 / Non-Blocking 사용하기 위해 설정
- 기본 설정은 HttpUrlConnection
Rest Api, Http 통신을 간편하게 구현할 수 있도록 다양한 기능을 제공해주는 라이브러리
HTTP 요청과 응답을 생성하고 처리하는 기본 기능을 제공
- 헤더, 바디 등의 세부 사항을 수동으로 제어할 수 있음
- 요청 및 응답에 대한 세밀한 제어가 가능
Java와 같은 JVM 기반 시스템에서 동작

Feign Client 예시 코드

실제 Feign Client를 활용해 외부 API를 호출하는 로직을 작성해보겠습니다. 테스트를 위해선 Json 무료 가상 Rest API 서버인 JSONPlaceholder를 사용하겠습니다.

GET https://jsonplaceholder.typicode.com/users/1

https://jsonplaceholder.typicode.com/

JSONPlaceholder - Free Fake REST API

{JSON} Placeholder Free fake API for testing and prototyping. Powered by JSON Server + LowDB. Tested with XV. Serving ~2 billion requests each month.

jsonplaceholder.typicode.com

우선 build.gradle파일을 통해 Dependency를 설정해야합니다.

의존성

ext {
	set('springCloudVersion', "2021.0.5")
}

dependencies {
	implementation 'org.springframework.cloud:spring-cloud-starter-openfeign'
    	implementation 'io.github.openfeign:feign-okhttp'
}

dependencyManagement {
	imports {
		mavenBom "org.springframework.cloud:spring-cloud-dependencies:${springCloudVersion}"
	}
}

예시 코드

Client Interface와 FallbackFacory Class를 생성합니다.

FallbackFacory란?

Feign에서 제공하는 기능 중 하나로, 서비스 간 통신 중에 에러가 발생할 때 대체 동작을 정의하기 위해 사용
예외가 발생하면 해당 인터페이스의 백엔드 구현 대신 FallbackFactory에 정의된 메소드 호출

package com.example.demofeign.api.test.feign;

import org.springframework.http.MediaType;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

import java.util.Map;

@FeignClient(name = "testApi", url = "https://jsonplaceholder.typicode.com", fallbackFactory = ApiClientFallbackFactory.class)
public interface ApiClient {

    @GetMapping(value = "/users/{userNo}", consumes = MediaType.APPLICATION_JSON_VALUE, produces = MediaType.APPLICATION_JSON_VALUE)
    Map getTestData(@PathVariable String userNo);
}

package com.example.demofeign.api.test.feign;

import lombok.extern.slf4j.Slf4j;
import org.springframework.cloud.openfeign.FallbackFactory;
import org.springframework.stereotype.Component;

import java.util.Map;

@Slf4j
@Component
public class ApiClientFallbackFactory implements FallbackFactory<ApiClient> {
    @Override
    public ApiClient create(Throwable cause) {
        return new ApiClient() {
            @Override
            public Map getTestData(String userNo) {
                log.error("testData Fallback reason was: " + cause.getMessage(), cause);
                return null;
            }
        };
    }
}

다음으로 ApiClient를 호출하는 TestService를 생성합니다.

package com.example.demofeign.api.test.service;

import com.example.demofeign.api.test.feign.ApiClient;
import com.example.demofeign.api.test.model.response.ApiResponse;
import com.fasterxml.jackson.databind.ObjectMapper;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.stereotype.Service;

import java.util.Map;

@Slf4j
@Service
@RequiredArgsConstructor
public class TestService {

    private final ApiClient apiClient;
    private final ObjectMapper objectMapper;

    public ApiResponse getTestData(String userNo) {
        Map testData = apiClient.getTestData(userNo);
        ApiResponse apiResponse = objectMapper.convertValue(testData, ApiResponse.class);
        log.info("TestData: {}", apiResponse);
        return apiResponse;
    }
}

마지막으로 TestService를 호출 테스트해볼 TestController를 생성합니다.

package com.example.demofeign.api.test.controller;

import com.example.demofeign.api.test.model.response.ApiResponse;
import com.example.demofeign.api.test.service.TestService;
import lombok.RequiredArgsConstructor;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RequiredArgsConstructor
@RestController
@RequestMapping("/api")
public class TestController {
    private final TestService testService;

    @GetMapping("/test/{userNo}")
    public ResponseEntity<ApiResponse> test(@PathVariable String userNo) {
        return ResponseEntity.ok(testService.getTestData(userNo));
    }
}

Postman으로 호출결과를 확인하면, 위에 링크와 같이 데이터를 가져온것을 확인할 수 있습니다.

해당 예제 소스 링크입니다.

https://github.com/Jisue/Spring-Boot---Feign-Client

GitHub - Jisue/Spring-Boot---Feign-Client: Feign Client를 정리해보자

Feign Client를 정리해보자. Contribute to Jisue/Spring-Boot---Feign-Client development by creating an account on GitHub.

github.com

[참고]

https://techblog.woowahan.com/2630/

우아한 feign 적용기 | 우아한형제들 기술블로그

{{item.name}} 안녕하세요. 저는 비즈인프라개발팀에서 개발하고 있는 고정섭입니다. 이 글에서는 배달의민족 광고시스템 백엔드에서 feign 을 적용하면서 겪었던 것들에 대해서 공유 하고자 합니다

techblog.woowahan.com

https://kdhyo98.tistory.com/33#google_vignette

[SPRING] feign은 뭘까?

서론 다른 서버와 통신을 하기 위한 API 를 설계 및 개발을 하면서 알게 된 feign에 대해서 정리하기 위해 작성하게 되었다. 그 전까지는 spring에서 다른 서버를 호출해본 적이 없었기 때문에 어

kdhyo98.tistory.com

[네트워크] TCP 연결/해제 과정(3 way handshake & 4 way handshake)

개발개굴 — Sun, 29 Oct 2023 15:56:54 +0900

TCP가 데이터를 전송할때, 신뢰성을 보장하기 위한 연결 성립과 연결 해제 과정에 대해 알아보겠습니다.

https://j-su2.tistory.com/15

[네트워크] TCP와 UDP

TCP와 UDP는 전송 계층에서 통신 활성화를 위해 사용되는 프로토콜입니다. TCP : 신뢰성, 연결 지향적 UDP : 비신뢰성, 비연결성, 실시간 프로토콜이란? 통신 규약으로 컴퓨터 내부에서, 또는 컴퓨터

j-su2.tistory.com

3 way handshake

TCP는 연결을 위해서 3번의 과정을 진행합니다.

클라이언트가 서버에게 SYN 패킷을 보냄 (sequence: X)
서버가 SYN(X)을 받고, 클라이언트로 받았다는 신호인 ACK와 SYN패킷을 보냄 (sequence: Y / ACK: X+1)
클라이언트는 서버의 응답인 ACK(X+1)와 SYN(Y) 패킷을 받고, ACK(Y+1)를 서버로 보냄

*ACK: Acknowledgment(승인), 요청을 확인했다는 응답

*SYN: Synchronize(동시성) Sequence Number, 연결이 이루어지도록 요청하는 의미

4 way handshake

TCP는 모든 통신이 끝난후 연결 해제를 위해 4번의 과정을 진행합니다.

클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보냄
서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보냄 (이때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 됨)
데이터를 모두 보내고, 서버는 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보냄
클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보냄(아직 서버로부터 받지 못한 데이터가 있을 수 있어 TIME_WAIT상태)
- 서버는 ACK를 받을 이후 소켓을 닫음 (CLOESED)
- TIME_WAIT 시간이 끝나면 클라이언트도 닫음 (CLOSED)

[참고]

https://velog.io/@leeesangheee/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC.-TCP-3-way-Handshake

네트워크. TCP 3-way Handshake

TCP 3-way Handshake

velog.io

https://github.com/gyoogle/tech-interview-for-developer/blob/master/Computer%20Science/Network/TCP%203%20way%20handshake%20%26%204%20way%20handshake.md#tcp-3-way-handshake--4-way-handshake

[네트워크] OSI 7 계층

개발개굴 — Wed, 25 Oct 2023 23:20:00 +0900

OSI 7 계층이란?

의미

네트워크 통신이 일어나는 과정을 7단계로 나눈 것으로, 국제표준화기구(ISO)에서 네트워트 간의 호환을 위해서 만든 개방형 시스템 상호 연결 모델의 표준인 네트워크 모델

실제 인터넷에서 사용되는 TCP/IP 는 OSI 참조 모델을 기반으로 상업적이고 실무적으로 이용될 수 있도록 단순화
https://j-su2.tistory.com/134

[네트워크] TCP/IP 4계층

TCP/IP(Transmission Control Protocal / Internet Protocal)란? 현재 수많은 프로그램들이 인터넷으로 통신하는데 있어 가장 기반이 되는 프로토콜로 실제 대다수 프로그램은 TCP와 IP로 통신하고 있습니다. 즉,

j-su2.tistory.com

물리 → 데이터 링크 → 네트워크 → 전송 → 세션 → 표현 → 응용

탄생 배경

네트워크 간의 호환을 위해 탄생한 모델

초기 여러 정보 통신 업체 장비들은 자신의 업체 장비들끼리만 연결되어 호환성이 없었음
따라서 모든 시스템의 상호 연결에 있어 문제가 없도록 표준을 정한것이 OSI 7 계층

장점

흐름을 한눈에 알아보기 쉽고, 이해하기 쉬움
7계층중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들이지 않고도 이상이 생긴 단계만 고칠 수 있음

작동 원리

송신
- 7계층 -> 1계층 송신(전송)시, 각각의 층마다 인식할 수 있는 헤더를 붙여 캡슐화
- 출발지에서 데이터가 전송될 때 헤더가 추가 (단, 2계층에서만 오류제어를 위해 꼬리부분에 추가됨
- 물리계층에서 1, 0 의 신호가 되어 전송매체(동축케이블, 광섬유 등)을 통해 전송

수신
- 1계층 -> 7계층 수신시 헤더를 제거해 디캡슐화

1계층 - 물리계층(Physical Layer)

주로 전기적, 기계적, 기능적인 특성을 이용해서 통신 케이블로 데이터를 전송하는 역할

데이터 단위: 0과1의 비트(BIT)
단지 데이터를 전기적인 신호로 변환해서 전달(데이터가 무엇인지, 어떤 에러가 잇는지 신경쓰지 않음)

구성 요소

리피터: 신호를 증폭해 재전송하는 장치
케이블
허브: 여러 PC를 브로드캐스트를 위한 연결 장치

2계층 - 데이터 링크계층(DataLink Layer)

물리 계층을 통해 송신/수신되는 정보의 오류와 흐름을 관리하여 *안전한 정보의 전달을 수행할 수 있도록 도와주는 역할

데이터 단위: 프레임(Frame)
Mac 주소를 이용해 통신
Point-To-Point 전송
Frame에 MAC 주소를 부여하고 에러검출, 재선송, 흐름 제어
- 주소 할당: 물리계층의 신호를 네트워크 상의 장치에 안착할수 있게함
- 오류 감지: 오류가 포함되면 해당 데이터를 파기
- 순서 제어: 프레임의 순서적 전송
- 프레임 동기화: 프레임의 시작과 끝을 구별하기 위한 동기화

*안전한 정보: 오류나 재전송하는 기능이 존재해 신뢰성 있는 전송을 보장

구성 요소

브릿지, 스위치: 연결된 포트로만 프레임을 전송
이더넷: LAN(근거리 통신망) 구축을 위해 장치를 연결하는 네트워킹 프로토콜

3계층 - 네트워크 계층(Network Layer)

여러 개의 노드를 거칠 때마다 경로를 찾아주는 역할

다양한 길이의 데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당(최적의 경로를 설정)

데이터 단위: 패킷(Packet/Datagram)
전송 계층이 요구하는 서비스 품질을 제공하기 위한 기능적, 절차적 수단을 제공
라우터를 통해 이동할 경로(Route)를 선택하여 주소(IP)를 지정하고, 해당 경로에 따라 패킷을 전달
라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행

구성 요소

라우터 : 경로 설정
IP : 주소 부여
L3 스위치

4계층 - 전송 계층(Transport Layer)

TCP, UDP 프로토콜을 통해 통신을 활성화해 양 끝단의 사용자들 간의 신뢰성있는 데이터를 주고 받게 해주는 역할

데이터 단위: 세그먼트(Segment)
포트를 열어두고, 프로그램들이 전송을 할 수 있도록 제공
신뢰성 있고 효율적인 데이터 전송
- 오류검출 및 복구, 흐름제어와 중복검사 수행
데이터 전송을 위해 Port번호 사용

구성 요소

TCP 프로토콜
UDP 프로토콜

https://j-su2.tistory.com/15

[네트워크] TCP와 UDP

j-su2.tistory.com

https://j-su2.tistory.com/138

[네트워크] TCP 연결/해제 과정(3 way handshake & 4 way handshake)

TCP가 데이터를 전송할때, 신뢰성을 보장하기 위한 연결 성립과 연결 해제 과정에 대해 알아보겠습니다. https://j-su2.tistory.com/15 [네트워크] TCP와 UDP TCP와 UDP는 전송 계층에서 통신 활성화를 위해

j-su2.tistory.com

5계층 - 세션 계층(Session Layer)

양 끝 단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공하는 역할

데이터가 통신하기 위한 논리적 연결을 담당
TCP/IP 세션을 만들고 없애는 책임을 지니고 있음
- IP 데이터의 배달을 처리, TCP는 패킷을 추적하고 관리

구성 요소

API
Socket

6계층 - 표현 계층(Presentation Layer)

데이터 표현에 대한 독립성을 제공하고 암호화하는 역할

전송 데이터의 표현방식 결정
- 코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로 부터 덜어줌
- 데이터 변환, 압축, 암호화 등
- 인코딩이나 암호화 등의 동작이 이루어짐
기능 3가지
- 송신자에서 온 데이터를 해석하기 위한 응용계층 데이터 부호화, 변화
- 수신자에게 데이터 압축을 풀수 있는 방식으로 데이터 압축
- 데이터 암호화/복호화

구성 요소

JPEG
MPEG

7계층 - 응용 계층(Application Layer)

최종 목적지로 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행하는 역할

사용자와 가장 가까운 계층
사용자 인터페이스(UI), 전자우편, 데이터베이스 관리 등의 서비스 제공

구성 요소

HTTP 프로토콜
FTP 프로토콜
DNS

[참고]

https://velog.io/@cgotjh/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-OSI-7-%EA%B3%84%EC%B8%B5-OSI-7-LAYER-%EA%B8%B0%EB%B3%B8-%EA%B0%9C%EB%85%90-%EA%B0%81-%EA%B3%84%EC%B8%B5-%EC%84%A4%EB%AA%85

[네트워크] OSI 7 계층 (OSI 7 LAYER) 기본 개념, 각 계층 설명

네트워크의 기초 OSI 7 계층

velog.io

https://onecoin-life.com/19

[네트워크] OSI 7Layer / 7계층 개념 및 역할, 구조까지 한번에 알아보기

목차 OSI 7 계층이란? OSI 7 계층은 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말하며, 국제표준화기구(ISO, International Organization for Standardization)에서 네트워크 간의 호환을 위해 OSI..

onecoin-life.com

https://github.com/WooVictory/Ready-For-Tech-Interview/blob/master/Network/OSI%207%20%EA%B3%84%EC%B8%B5.md

GitHub - WooVictory/Ready-For-Tech-Interview: 신입 개발자로서 준비를 하기 위해 지식을 정리하는 공간

신입 개발자로서 준비를 하기 위해 지식을 정리하는 공간 ‍ . Contribute to WooVictory/Ready-For-Tech-Interview development by creating an account on GitHub.

github.com

https://shlee0882.tistory.com/110

OSI 7 계층이란?, OSI 7 계층을 나눈 이유

1. OSI 7 계층이란? OSI 7 계층은 네트워크에서 통신이 일어나는 과정을 7단계로 나눈 것을 말한다. 1.1 OSI 7 계층을 나눈이유는? 계층을 나눈 이유는 통신이 일어나는 과정이 단계별로 파악할 수 있

shlee0882.tistory.com

https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-OSI-7%EA%B3%84%EC%B8%B5-%EC%A0%95%EB%A6%AC

OSI 7계층 모델 - 핵심 총정리

OSI 7계층 OSI 7계층은 네트워크 통신이 일어나는 과정을 7단계로 나눈 것을 말한다. OSI 7계층을 나눈 이유는? 흐름을 한눈에 알아보기 쉽고 7단계 중 특정한 곳에 이상이 생기면 다른 단계의 장

inpa.tistory.com

[AWS] CI/CD란?

개발개굴 — Sun, 11 Jun 2023 16:59:09 +0900

최근에 새로운 프로젝트에 들어가며, AWS CodePipeline을 활용해 빌드/배포 자동화 환경을 셋팅하게 되었습니다. 이참에 CI/CD 개념을 자세히 정리하고자 해당 글을 작성하게 되었습니다.

[출처: https://velog.io/@whattsup_kim/CI-CD%EB%9E%80]

CI/CD 란?

지속적 통합(Continuous Integration, CI)과 지속적 제공&배포(Continuous Delivery&Continuous Deployment, CD)의 약자로,

애플리케이션 개발 단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법입니다.

DevOps 엔지니어의 핵심 업무라고 불리기도 하는 CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해줍니다.

CI/CD의 핵심 개념

CI/CD는 *인터그레이션 헬을 해결하기 위한 하나의 솔루션으로 핵심 개념을 다음과 같이 세 가지로 구분할 수 있습니다.

*인터그레이션 헬(Integration Hell): 개발/운영 조직에서 새로운 코드 통합(merge) 과정에서 발생하는 여러가지 문제들로, 통합을 위한 작업으로 수 시간이 소요되며 롤백을 수행하기도 함

CI(Continuous Integration) - 지속적인 통합

새로운 코드 변경 사항이 주기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 통합(merge)되는 것을 의미합니다.

한 프로젝트에 여러명의 개발자가 협업을 하며 개발하는 상황이 있다고 가정해봅시다. 이때, 너무 오랜 주기로 merge를 한다면 충돌 코드가 많아질 수 있고, 또 너무 빈번한 merge를 하자면 귀찮다는 단점이 있습니다. 하지만, 가능한 작은 단위로 나누어 주기적인 통합이 중요하기 때문에 해당 작업을 자동화하여 지속적인 통합을 진행합니다.

장점

여러 개발자가 동시에 작업하며 발생할 수 있는 충돌 문제를 수시로 확인하고 해결할 수 있음
버그를 빠르게 찾아 해결하고, 소프트웨어 품질을 개선 가능
새로운 업데이트 테스트와 출시 시간을 단축시킴

CD(Continuous Delivery & Deployment) - 지속적인 서비스 제공 & 배포

개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리즈하는 것을 의미합니다.

장점

개발자는 배포보다는 개발에 더욱 신경 쓸 수 있도록 도와줌
개발자가 원클릭으로 수작업 없이 빌드, 테스트, 배포까지의 자동화를 할 수 있음

CI/CD 파이프라인

새 버전의 소프트웨어를 제공하기 위해 수행해야 할 일련의 단계를 뜻합니다.

[출처: https://www.redhat.com/ko/topics/devops/what-is-ci-cd]

빌드(Build) : 애플리케이션을 컴파일하는 단계
테스트(Test): 코드를 테스트하는 단계, 이 단계를 자동화하여 시간과 수고를 줄일 수 있음
릴리즈(Release): 애플리케이션을 리포지토리에 제공하는 단계
배포(Delpoy): 코드를 프로덕션에 배포하는 단계
검증 및 컴플라이언스(Validation & Compliance): 빌드 검증 단계는 해당 조직의 필요에 따라 결정되며, 소프트웨어 품질을 보장할 수 있게 해줌

[참고]

https://walkingplow.tistory.com/78

CI/CD의 개념과 차이점

CI/CD의 개념 CI/CD는 애플리케이션 개발 단계를 자동화해 보다 짧은 주기로 통합 및 배포하는 것을 의미합니다. 인터그레이션 헬(Integration Hell)을 해결하기 위한 솔루션으로 지속적인 통합, 지속적

walkingplow.tistory.com

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

CI/CD(CI CD, 지속적 통합/지속적 배포): 개념, 툴, 구축, 차이

CI/CD는 애플리케이션의 통합 및 테스트 단계부터 제공 및 배포까지 애플리케이션 라이프사이클 전체에서 지속적인 자동화와 지속적인 모니터링을 제공하는 것을 뜻합니다.

www.redhat.com

https://www.ciokorea.com/insider/233289

'CI/CD란?' 알기 쉽게 설명한 지속적 통합과 지속적 전달

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는

www.ciokorea.com

https://jud00.tistory.com/entry/CICD%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

CI/CD란 무엇일까?

오늘은 CI/CD에 대해서 작성해보겠습니다. 앞으로는 글을 작성하는데 편한 글씨체로 작성할 생각입니다 :) CI/CD란? CI/CD는 개발자라면 한 번쯤은 다들 들어봤을 만한 단어일 것이다. CI/CD는 애플리

jud00.tistory.com

https://velog.io/@woodonggyu/Deployment-Pipeline-CICD

WHAT IS "CI/CD" ?

본 글에서는 CI/CD 에 대한 기본적인 내용을 다룬다.

velog.io

[프로그래밍 패러다임] SOLID란?

개발개굴 — Tue, 23 May 2023 21:56:52 +0900

객체지향 프로그래밍(OOP)이란?

*객체지향 프로그래밍은 객체들의 집합으로 프로그램의 상호 작용을 표현하며 데이터를 객체로 취급하여 객체 내부에 선언된 메서드를 활용하는 *프로그래밍 패러다임으로 추상화, 캡슐화, 상속성, 다형성이라는 특징을 가지고 있습니다.

이러한 특징들로 인해 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용됩니다.

*프로그래밍 패러다임이란?

https://j-su2.tistory.com/127

[프로그래밍 패러다임] 프로그래밍 패러다임이란?

프로그래밍 패러다임(Programming Paradigm)이란? 프로그래머에게 프로그래밍의 관점을 갖게 해주는 역할을 하는 개발 방법론입니다. 예를 들어 객체지향 프로그래밍 : 프로그래머들이 프로그램을 상

j-su2.tistory.com

*객체지향 프로그래밍(OOP)란?

https://j-su2.tistory.com/35

[프로그래밍 패러다임] OOP와 FP

OOP란? OOP는 Object Oriented Programming의 약자로 객체 지향 프로그래밍을 뜻합니다. class와 object에 기반한 프로그래밍 패러다임(디자인 패턴)으로, 관련된 데이터끼리 묶어서 class를 형성하고 그 안에

j-su2.tistory.com

이러한 객체지향 프로그래밍을 설계할 때는 SOLID 원칙을 지켜주어야 합니다.

SOLID란?

SOLID란 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 패더스가 두문자어 기억술로 소개한 것입니다.

프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들게 해줌
애자일 소프트웨어 개발과 적응형 소프트웨어 개발의 전박적 전략의 일부

S는 단일 책임 원칙, O는 개방-폐쇄 원칙, L은 리스코프 치환 원칙, I는 인터페이스 분리 원칙, D는 의존 역선 원칙을 의미합니다.

단일 책임 원칙(SRP, Single Responsibility Principle)

모든 클래스는 각각 하나의 책임만 가져야 하는 원칙입니다.

변경이 있을 때 파급 효과가 적으면 좋음
예를 들어 객체의 생성 부분과 사용 부분을 분리하는 것

개방-폐쇄 원칙(OCP, Open Close Principle)

유지 보수 사항이 생긴다면 코드를 쉽게 확장할 수 있도록 하고 수정할 때는 닫혀 있어야 하는 원칙입니다.

기존의 코드는 잘 변경하지 않으면서도 확장은 쉽게 할 수 있어야 함
예를 들어 다형성을 활용해 인터페이스를 구현한 새로운 클래스를 하나 만들어 새로운 기능을 구현
역할과 구현의 분리
객체를 생성하고, 연관관계를 맺어주는 별도의 조립/설정자가 필요함

리스코프 치환 원칙(LSP, Liskov Substitution Principle)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 하는 것입니다.

부모 객체에 자식 객체를 넣어도 시스템이 문제없이 돌아가야 함
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면 LSP가 충족되어야 함
예를 들어 컴파일에 성공해도 인터페이스의 기능에 대한 규약을 지키지 않게 구현하다면 LSP를 위반!

인터페이스 분리 원칙(ISP, Interface Segregation Principle)

하나의 일반적인 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 하는 원칙을 말합니다.

인터페이스가 명확해지고, 대체 가능성이 높아짐
예를 들어 자동차는 운전/정비 기능이 있고, 사용자는 운전자/정비사로 분리해두면 정비 인터페이스를 바꿔도 운전자에는 영향을 미치지 않음

의존 역전 원칙(DIP, Dependency Inversion Principle)

DIP의 핵심 원리는 "추상화에 의존해야지, 구체화에 의존하면 안된다" 입니다. 즉, 자신보다 변하기 쉬운 것에 의존하던 것을 추상화된 인터페이스나 상위 클래스를 두어 변하기 쉬운 것의 변화에 영향받지 않게 하는 원칙을 말합니다.

상위 계층은 하위 계층의 변화에 대한 구현으로부터 독립해야 함
구현 클래스에 의존하지 말고 인터페이스에 의존해야 함 (구현체에 의존하게 된다면 변경이 아주 어려워지게 됨)
의존성 주입은 DIP를 따름
역할에 의존하게 해야함

정리하자면, 객체 지향의 핵심은 다형성을 통해 변경에 용이한 개발을 하는 것입니다. 하지만, 다형성 만으로는 OCP, DIP를 지킬 수 없기 때문에 스프링과 같이 객체 지향 설계를 도와주는 프레임워크를 사용해 해결할 수 있습니다.

[출처] 면접을 위한 CS 전공지식 노트

http://www.yes24.com/Product/Goods/108887922

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

디자인 패턴, 네트워크, 운영체제, 데이터베이스, 자료 구조, 개발자 면접과 포트폴리오까지!CS 전공지식 습득과 면접 대비, 이 책 한 권이면 충분하다!개발자 면접에서 큰 비중을 차지하는 CS(Comp

www.yes24.com

https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)

SOLID (객체 지향 설계) - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전.

ko.wikipedia.org

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%EC%9E%85%EB%AC%B8-%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8/dashboard

[무료] 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링 웹 애플리케이션 개발 전반을 빠르게 학습할 수 있습니다., - 강의 소개 | 인프런...

www.inflearn.com

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의

스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., - 강의 소개 | 인프런

www.inflearn.com

[Spring] Mockito란?

개발개굴 — Sun, 21 May 2023 20:47:40 +0900

단위 테스트란?

단위 테스트는 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트입니다. 즉, 하나의 기능이 올바르게 동작하는지 독립적으로 테스트하는 것입니다.

프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하기 때문에 문제 발생 시 정확하게 어느 부분이 잘못되었는지 캐치할 수 있다는 장점이 있지만, 다른 객체와 데이터를 주고 받는 경우에 문제가 발생할 수 있습니다.

예를 들어 Service 계층의 단위 테스트 코드를 작성할 때 보통 다른 객체들과 의존 관계를 맺고 있는 경우가 많습니다. 이때, Bean Container에 주입된 실제 객체들을 가져다 쓰는 방법이 있고, Mockito 프레임워크 등을 활용해 Mock 객체를 만들어서 쓰는 방법이 존재합니다.

Mockito란?

Mockito는 *JUnit Test에서 *Mock을 위한 Java 오픈소스 테스트 프레임워크입니다.

Spring은 여러 객체들 간의 의존성이 생기게 되는데, 이러한 특성은 단위 테스트를 작성하기 어렵게 만듭니다. 따라서 의존성을 해결하기 위해 개발자가 동작을 직접 제어할 수 있는 가짜 객체인 Mock을 생성하여 주입시켜주는 Mockito 라이브러리를 활용합니다.

즉, Mockito는 Mock 객체를 쉽게 만들고, 관리하고, 검증할 수 있는 방법을 제공하는 프레임워크입니다.

*Mock: 진짜 객체와 비슷하게 동작하지만, 프로그래머가 직접 행동을 관리하는 객체

*JUnit: 자바 단위 테스트를 위한 프레임워크

Mockito 시작하기

Dependency 추가

스프링 부트 2.2 이상 버전의 프로젝트 생성시 spring-boot-start-test에서 자동으로 Mockito를 추가해줍니다.

dependencies {
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

직접 추가하기 위해선 mockito-core와 mockito-junit-jupiter가 필요합니다.

mockito-core: mockito가 제공해주는 기본적인 라이브러리
mockito-junit-jupiter: junit 테스트에서 mockito를 연동해서 사용할 수 있는 junit 확장 구현체

// build.gradle
dependencies {
    testImplementation 'org.mockito:mockito-core:3.11.2'
    testImplementation 'org.mockito:mockito-junit-jupiter:3.11.2'   
}

//maven
 <dependency>       
 	<groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>3.1.0</version>
    <scope>test</scope>
</dependency>

<dependency>
	<groupId>org.mockito</groupId>
	<artifactId>mockito-junit-jupiter</artifactId>
	<version>3.1.0</version>
	<scope>test</scope>
</dependency>

JUnit과 결합

Mockito도 테스팅 프레임워크이기 때문에 JUnit과 결합되기 위해 클래스 어노테이션을 붙이는 별도의 작업이 필요합니다.

JUnit4: @RunWith(MockitoJUnitRunner.class)
JUnit5: @ExtendWith(MockitoExtension.class)

SpringBoot 2.2.0부터 공식적으로 JUnit5를 지원함에 따라 @ExtendWith(MockitoExtension.class)를 사용해 결합하게 됩니다.

@ExtendWith(MockitoExtension.class)
class Test {
	// 테스트 작성
}

Mockito 사용하기

우선 테스트 작성에 앞서 Member라는 객체를 조회하기 위한 세팅을 진행합니다.

(편의성을 위해 저는 Lombok을 사용했습니다.)

Member

package com.example.demotest.domain;

import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;

@Getter
@Entity
@AllArgsConstructor
@NoArgsConstructor
@Table(name = "member")
public class Member {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "member_no")
    private Long no;

    @Setter
    @Column(name = "name", nullable = false)
    private String name;

}

Member Entity를 생성

Repository

import com.example.demotest.domain.Member;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface MemberRepository extends JpaRepository<Member, Long> {
}

Member를 조회하기 위한 Repository를 생성

Service

import com.example.demotest.domain.Member;
import com.example.demotest.repository.MemberRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true)
public class MemberService {

    private final MemberRepository memberRepository;

    public List<Member> findAllMember() {
        return memberRepository.findAll();
    }

}

Member List를 조회하는 서비스를 생성

다음으로 MemberService를 통해 Member List를 조회하는 Service Test 예시는 다음과 같습니다.

import com.example.demotest.domain.Member;
import com.example.demotest.repository.MemberRepository;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.Mockito;
import org.mockito.junit.jupiter.MockitoExtension;
import org.assertj.core.api.Assertions;

import java.util.ArrayList;
import java.util.List;

@ExtendWith(MockitoExtension.class)
class MemberServiceTest {

    @InjectMocks
    private MemberService memberService;

    @Mock
    private MemberRepository memberRepository;

    @Test
    @DisplayName("회원 조회 결과 Member 리스트가 반환되어야 한다.")
    void findAllMember() {
        // given
        List<Member> memberList = new ArrayList<>();
        memberList.add(new Member(
                1L,
                "name1"));
        memberList.add(new Member(
                2L,
                "name2"));


        // when
        Mockito.when(memberRepository.findAll()).thenReturn(memberList);
        List<Member> result = memberService.findAllMember();

        // then
        Assertions.assertThat(result).hasSize(2);
        Assertions.assertThat(result.get(0).getName()).isEqualTo("name1");
        Assertions.assertThat(result.get(1).getName()).isEqualTo("name2");
    }
}

@Mock
- Mock객체를 생성
@InjectMocks
- @Mock이 붙은 Mock객체를 @InjectMocks이 붙은 객체에 주입
- Service를 테스트하기 위해서 MemberRespository를 주입받아야 함
Mock 객체 Stubbing
- when() -> memberRepository를 통해 회원 리스트를 조회 했을때
- thenReturn() -> memberList가 return 되어야 함
Test 진행
- Repository에서 조회한 결과와 Service를 통해 조회한 결과를 비교
- 생성한 MemberList의 크기는 2
- 첫번째 값의 이름은 name1
- 두번째 값의 이름은 name2

테스트를 실행 결과 passed가 잘 나옵니다!

작성 코드는 아래 링크를 통해 확인할 수 있습니다.

https://github.com/Jisue/Spring-Test/tree/main/demo-test

GitHub - Jisue/Spring-Test: TDD Study

TDD Study. Contribute to Jisue/Spring-Test development by creating an account on GitHub.

github.com

[참고]

https://mangkyu.tistory.com/145

[Spring] JUnit과 Mockito 기반의 Spring 단위 테스트 코드 작성법 (3/3)

이번에는 Spring 기반의 웹 애플리케이션에서 테스트를 작성하는 방법에 대해 알아보도록 하겠습니다. 1. Mockito 소개 및 사용법 [ Mockito란? ] Mockito는 개발자가 동작을 직접 제어할 수 있는 가짜 객

mangkyu.tistory.com

https://scshim.tistory.com/439

Mockito란? Mockito 사용하기

Mockito란? · Mock 객체를 쉽게 만들고, 관리하고, 검증할 수 있는 방법을 제공하는 프레임워크 - Mock: 진짜 객체와 비슷하게 동작하지만, 프로그래머가 직접 행동을 관리하는 객체 - 공홈 https://site.m

scshim.tistory.com

https://www.nextree.io/mockito/

Mockito를 활용하여 테스트 코드 작성하기

Mockito 란? Mockito란 Java 오픈소스 테스트 프레임워크입니다. Mockito를 사용하면 실제 객체를 모방한 가짜 객체, Mock 객체 생성이 가능해집니다. 개발자는 이 Mock 객체를 통해 테스트를 보다 간단하

www.nextree.io

https://lemontia.tistory.com/951

[junit5] Mock을 이용한 단위 테스트 (@InjectMocks 과 @Mock 차이)

Mockito를 이용하면 좀더 작은 단위까지 테스트가 가능하다. 무엇보다 데이터를 컨트롤해야하는 상황에서 DB연결없이 임의로 주고받을 수 있기 때문에 유용하다. 이번에는 그 테스트에 관한 내용

lemontia.tistory.com

https://velog.io/@hellonayeon/spring-boot-service-layer-unit-testcode

[Spring Boot] Service 계층의 단위 테스트 코드 작성

velog.io

https://velog.io/@sussa3007/Spring-JUnit-Mockito-%EA%B8%B0%EB%B0%98-Spring-%EB%8B%A8%EC%9C%84-%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1

[Spring] JUnit & Mockito 기반 Spring 단위 테스트 코드 작성

단위테스트는 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트다.하나의 모듈이란 각 계층에서의 하나의 기능 또는 메소드로 이해할 수 있다.하나의 기능이 올바르게 동

velog.io

[Server] gRPC란?

개발개굴 — Sat, 7 Jan 2023 18:57:35 +0900

gRPC(Google Remote Procedure Call)란?

gRPC는 Google에서 만든 RPC로 공식 홈페이지에 "A high performance, open source universal RPC framework"라고 정의되어 있습니다. 이를 직역하자면 "고성능 오픈 소스 범용 RPC 프레임워크"입니다.

우선 gRPC등장 이전의 RPC에 대해 먼저 알아보겠습니다.

RPC(Remote Procedure Call)란?

원격 프로시저 호출(RPC)는 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게하는 프로세스 간 통신 기술입니다. 즉, RPC를 이용하면 개발자는 어디서든 원하는 함수를 사용할 수 있습니다.

RPC는 *IPC 기법 중 1개로 클라이언트나 서버는 일반 메소드를 호출하는 것처럼 원격의 프로시저를 호출하여 사용할 수 있습니다.

예를 들어, 다양한 언어와 프레임워크로 개발될 수 있는 *MSA 구조의 서비스처럼 Polyglot한 구조에서는 프로토콜에 맞춰서 통신하려면 복잡하고 비용이 들지만, RPC를 통해 언어에 구애받지 않고, 원격에 있는 프로시저를 호출할 수 있습니다.

Polyglot한 구조

*IPC(Inter Process Communication) 기법: 프로세스 간 정보를 교환하기 위해 통신하는 방법론을 통칭한 것 ex)소켓, RPC, REST 등

*MSA(Micro Service Architecture) : 서비스간의 의존성을 없애고 기능을 쪼개는 것을 중점적으로 설계한 아키텍처

gRPC의 특징과 구조

기존에 많이 사용되던 REST 방식의 경우에는, 표준이 없어 파라미터의 응답이 명시적이지 않았을 뿐 아니라 JSON형태의 데이터를 Serialization하는 비용이 발생한다는 단점이 있었습니다.

이러한 REST의 문제점을 해결하기 위한 대안으로 google사에서 개발한 오픈소스 RPC 프레임워크인 gRPC를 사용할 수 있습니다.

gRPC의 특징

*protocol buffer와 RPC를 사용
최신 버전의 *IDL로 proto3를 사용
SSL/TLS를 사용하여 서버를 인증하고 클라이언트와 서버간에 교환되는 모든 데이터를 암호화
HTTP 2.0을 사용하여 성능이 뛰어나고 확장 가능한 API를 지원

이러한 특징들로 인해 gRPC를 사용하면 Proto File만 배포하여 환경과 프로그램 언어에 구애받지 않고 서로 간의 데이터 통신이 가능해집니다.

*IDL: 정보를 저장하는 규칙 (ex. XML, JSON, Protocol Buffer)

*protocol buffer: 구조화된 데이터를 직렬화하여 XML을 문제점을 개선하기 위해 제안된 IDL

gPRC의 구조

gRPC에서 클라이언트 응용 프로그램을 서버에서 함수를 바로 호출 할 수 있어 분산 MSA를 쉽게 구현할 수 있으며, 서버 측에서는 서버 인터페이스를 구현하고 gRPC 서버를 실행하여 클라이언트 호출을 처리합니다.

[참고]

https://medium.com/naver-cloud-platform/nbp-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EC%8B%9C%EB%8C%80%EC%9D%98-%ED%9D%90%EB%A6%84-grpc-%EA%B9%8A%EA%B2%8C-%ED%8C%8C%EA%B3%A0%EB%93%A4%EA%B8%B0-1-39e97cb3460

[NBP 기술&경험] 시대의 흐름, gRPC 깊게 파고들기 #1

안녕하세요, 네이버 클라우드 플랫폼입니다.

medium.com

https://chacha95.github.io/2020-06-15-gRPC1/

gRPC 1 - gRPC란?

배경지식 gRPC는 Google에서 개발한 RPC(Remote Procedure Call) 시스템입니다. 전송을 위해 TCP/IP 프로토콜과 HTTP 2.0 프로토콜을 사용하고 IDL(Interface Definition language)로 protocol buffer를 사용합니다. gRPC에 대

chacha95.github.io

https://velog.io/@jakeseo_me/RPC%EB%9E%80

RPC란?

분산 네트워크 컴퓨터 환경에서 프로그래밍을 쉽게 할 수 있는 방법을 찾다가...Client to Server 패턴Server를 켬Client는 Server에 데이터 혹은 행동을 요청Server는 요청 받은 내용에 대한 응답을 반환Clie

velog.io

https://ssungkang.tistory.com/entry/WEB-google%EC%9D%B4-%EB%A7%8C%EB%93%A0-RPC-gRPC%EB%9E%80

[WEB] google이 만든 RPC, gRPC란

gRPC란 gRPC는 구글에서 개발한 어디서나 실행할 수 있는 오픈소스 고성능 RPC 프레임워크입니다. RPC는 Remote Procedure Call의 줄임말로 원격 프로시저 호출이라고 합니다. 이는 별도의 원격제어를 위

ssungkang.tistory.com

[네트워크] TCP/IP 4계층

개발개굴 — Thu, 3 Nov 2022 16:59:20 +0900

TCP/IP(Transmission Control Protocal / Internet Protocal)란?

현재 수많은 프로그램들이 인터넷으로 통신하는데 있어 가장 기반이 되는 프로토콜로 실제 대다수 프로그램은 TCP와 IP로 통신하고 있습니다. 즉, 인터넷을 통해 데이터를 보낼 때 주로 TCP와 IP를 이용해서 보냅니다.

이러한 상황에서 데이터을 보낼 때 올바르게 데이터를 전송하기 위해 TCP/IP 4계층을 통해 각 계층마다 책임이 부여되어 계층을 따라서 데이터가 보내지게 됩니다.

OSI 7계층 VS TCP/IP 4계층

OSI 7계층

네트워크 통신이 일어나는 과정을 7단계로 나눈 것
국제표준화기구(ISO)에서 네트워트 간의 호환을 위해서 만든 개방형 시스템 상호 연결 모델의 표준인 네트워크 모델

TCP/IP 4계층

실제로 사용되는 TCP/IP는 OSI 참조 모델을 기반으로 상업적이고 실무적으로 이용될 수 있도록 단순화된 모형
OSI 7계층을 4계층으로 분류하여 적용한 것

*OSI 7계층에 대한 내용은 아래 블로그를 참고하세요

https://j-su2.tistory.com/7

[네트워크] OSI 7 계층

OSI 7 계층이란? 네트워크 통신이 일어나는 과정을 7단계로 나눈 것으로, 국제표준화기구(ISO)에서 네트워트 간의 호환을 위해서 만든 개방형 시스템 상호 연결 모델의 표준인 네트워크 모델 실제

j-su2.tistory.com

TCP/IP 4계층

TCP/IP 4계층은 장치들이 인터넷 상에서 데이터를 주고받을 때 쓰는 독립적인 프로토콜의 집합을 의미합니다.

Application(응용): SMTP, HTTP/HTTPS, FTP, SSH
Transport(전송): UDP, TCP
Internet(인터넷): IPv4/IPv6, ICMP, ARP
Network Access(네트워크 엑세스)

각 계층을 간단하게 설명하기 앞서 TCP/IP 4계층에서 사용되는 용어들을 알아보겠습니다.

용어	설명
캡슐화	송신자가 수신자에게 데이터를 보낼 때 데이터가 각 계층을 지나며 각 계층의 특징들이 담긴 헤더들이 붙여지는 과정 전송계층의 TCP 헤더, 네트워크 계층의 IP 주소 헤더
비캡슐화	수신자측에서 캡슐화된 데이터를 역순으로 제거하면서 응용계층까지 도달하는 것
PDU(protocal data unit)	TCP/IP 4계층을 기반으로 각 계층의 데이터 단위 응용: 메시지 전송: 세그먼트(TCP), 데이터그램(UDP) 인터넷: 패킷 네트워크 엑세스: 프레임(데이터 링크), 비트(물리)

Application 계층

HTTP, SMTP, FTP, SSH가 대표적이며 웹 서비스, 이메일 등 서비스를 실질적으로 사람들에게 제공하는 층입니다.

HTTP(Hypertext Transfer Protocal)

서버와 브라우저간에 데이터를 주고 받기 위해 설계된 프로토콜
지금은 브라우저 뿐만 아니라 서버와 서버간의 통신할 때도 많이 이용
헤더를 통한 확장이 쉬움(다른 값 추가 쉬움)
stateless함(연속적인 상태 값 X)

SSH(Secure SHhell Protocal)

보안되지 않은 네트워크에서 네트워크 서비스를 안전하게 운영하기 위한 암호화 네트워크 프로토콜
AWS EC2 접근: ssh <pem> <user>@<serverIP>

FTP(File Transfer Protocal)

노드와 노드간의 파일을 전송하는데 사용되는 프로토콜
지금은 파일을 암호화해서 전송하는 FTPS, SFTP로 대체
대표적으로 FileZilla라는 SW가 있음

SMTP(Simple Mail Transfer Prototal)

인터넷을 통해 메일을 보낼 때 사용되는 프로토콜
보통 서비스를 운영하면 메일링 서비스를 하게 되는데 node.js를 통해 메일을 보낸다면 이를 통해 보내야함(Nodemailer)

Tansport 계층

TCP와 UDP가 대표적이며 응용 계층에서 받은 메시지를 기반으로 세그먼트 또는 데이터그램으로 데이터를 쪼개고 데이터가 오류없이 순서대로 전달되도록 도움을 주는 층입니다.

TCP

가상회선 패킷 교환 방식: 순서대로 도착
오류검사 매커니즘이 다양함
- 재전송: 시간 초과 하면 다시 전송
- 체크섬: 무결성을 평가
헤더는 20~60 바이트로 가변적
연결 보장 -> 3웨이-핸드셰이크, 4웨이-핸드셰이크
브로드캐스트 지원X
느림

UDP

데이터그램 패킷 교환 방식: 순서 보장 X
오류검사는 단순한 체크섬만 지원
32비트(8바이트)로 고정길이
연결 보장X -> 그냥 데이터 보내서 유지/해제 비용 X
브로드캐스트 지원O
빠름

Internet 계층

IP, ICMP, ARP가 대표적이며 한 노드에서 다른 노드로 전송 계층에서 받은 세그먼트 또는 데이터그램을 패킷화 하여 목적지로 전송하는 계층입니다.

ICMP(Internet Control Message Protocal)

노드와 노드 사이에서 통신이 잘되나를 확인할 때 쓰는 프로토콜 (데이터를 교환하는데 사용되지 않는 프로토콜)
일반적으로 테스팅에 사용됨
독립적인 비연결형 프로토콜

Network Access 계층

링크 계층이라고도 불리며 전선, 광섬유, 무선 등으로 데이터가 네트워크를 통해 물리적으로 전송되는 방식을 정의하는 계층입니다.

[참고]

https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95/dashboard

CS지식의 정석 | CS면접 디자인패턴 네트워크 운영체제 데이터베이스 자료구조 개발자면접 - 인프

국내 1위 "면접을 위한 CS전공지식노트" 저자의 디자인패턴, 네트워크, 운영체제, 데이터베이스 등 CS지식 강의! CS면접에 필요한 모든 개념과 최신 기출을 다룬다!, - 강의 소개 | 인프런...

www.inflearn.com

https://hahahoho5915.tistory.com/15

TCP/IP 4계층(TCP/IP 4 Layer)

TCP/IP (Transmission Control Protocol / Internet Protocol)현재 수많은 프로그램들이 인터넷으로 통신하는데 있어 가장 기반이 되는 프로토콜로 실제 대다수 프로그램은 TCP와 IP로 통신하고 있다. ARPANET이 개

hahahoho5915.tistory.com

https://velog.io/@jehjong/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%B8%ED%84%B0%EB%B7%B0-TCPIP-4%EA%B3%84%EC%B8%B5

[개발자 인터뷰] TCP/IP 4계층

계층 모형TCP/IP 모형은 현재의 인터넷에서 컴퓨터들이 서로 정보를 주고받는데 쓰이는 통신규약(프로토콜)의 모음으로 각 계층은 담당하는 위치마다 처리 역할을 구분해 진행함으로 서로 간의

velog.io