Dawon ⌨️

Spring에서 X-Forwarded-For 값을 가져오는 2가지 방법

I'mDawon — Sun, 22 May 2022 16:33:08 +0900

결론부터 말하면 두가지 방법이 있다.

1. X-Forwarded-For헤더에 직접 접근하여 가져오는 방법

2. HttpServletRequest의 getAddr()이 클라이언트 IP를 전달하도록 스프링 설정을 하는 방법

API를 호출한 사용자의 IP를 얻기 위해서 HttpServletRequest의 getAddr() 함수를 사용한다. 그러나 API요청이 Forward Proxy에 의해 전달 될 경우 HttpServletRequest의 getAddr() 호출 시 Forward Proxy의 IP가 찍히게 된다.

이런 경우 X-Forwarded-For라는 HTTP 헤더를 통해 프록시 서버를 통해 요청을 전달 받더라도, 진짜 Client IP를 전달 받을 수 있다.

(proxy에서 X-Forwarded-For에 클라이언트 IP를 넣어주겠다는 설정이 있어야 한다. Nginx의 경우 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;)

X-Forwarded-For는 HTTP proxy등을 통해 웹 서버에 접속하는 클라이언트의 IP 주소를 식별하기 위한 표준헤더이다.
문법 : X-Forward-For: <client>, <proxy1>, <proxy2>
- 여러 프록시들을 거칠 때 IP주소들이 차례대로 열거된다. 가장 오른쪽에 있는 IP가 마지막으로 거친 proxy의 IP 주소이다.

여기 까지 되면, X-Forward-For 헤더 값에 접근해서 클라이언트의 IP를 가져올 수 있다.

String ip = request.getHeader("x-forwarded-for");

그런데, 스프링 설정으로 HttpServletRequest의 getAddr()가 호출 되었을때, X-Forwarded-For값이 전달되도록 할 수 있다.

server.forward-headers-strategy=NATIVE

스프링에서 제공하는 ForwardedHeaderFilter를 사용하려면 server.forward-headers-strategy=FRAMEWORK 속성을 사용하면 된다.

서킷브레이커

I'mDawon — Wed, 13 Apr 2022 23:42:14 +0900

서킷브레이커는 뭐고 왜 써야 하는지 짧게 정리한 글입니다.

서킷 브레이커 왜 사용 할까?

Circuit Breaker 직역하자면 회로 차단기라는 뜻을 가지고 있습니다.

MSA환경에서는 서비스들이 모듈로 분리되고, 요청 서비스와 응답 서비스가 있습니다.

서비스 A가 서비스 B를 호출 했을 때, 서비스 B의 상태가 비정상적이라 응답을 해줄 수 없는 경우

서비스 A는 서비스 B의 응답을 계속해서 기다리는 상태가 됩니다.

서비스 B의 장애가 서비스 A까지 전파될 수 있습니다. 이를 방지하기 위해서 서킷 브레이커를 사용합니다.

대표적인 서킷브레이커 라이브러리로는 Resilience4J가 있습니다. 요청 서비스와 제공 서비스사이에 Resilice4J를 두고 통신합니다.

서킷브레이커 패턴

서킷브레이커 패턴은 서비스 A와 서비스 B사이에 서킷브레이커를 두어 서비스 B로 전달되는 요청이 서킷브레이커를 통해 전달되도록 하는 패턴 입니다.

서비스 B가 정상적이라면 서킷브레이커는 서비스 A의 요청을 바이패스하여 서비스 B로 전달해 줍니다.

서비스 B가 비정상적이라면 이를 서킷브레이커가 감지하여 서킷브레이커에서 서비스 A의 호출을 끊습니다.

이러한 경우 서비스 A로 서비스 B의 장애가 전파 되지는 않지만, 정상적인 응답값을 받지 못하게 됩니다.

이러한 처리를 하기 위해 사용되는 것이 Fallback Messaging 입니다. 서비스 B가 정상적으로 응답을 할 수 없는 경우 서킷 브레이커에서 Fallback Messaging을 통해 정해진 룰대로 값을 응답합니다.

결론

MSA에서 모듈간의 장애전파를 막기 위해 서킷브레이커 패턴이 사용된다.
장애 발생시 처리를 위해 FallbackMessaging이 사용되고, 서킷브레이커에서 장애 시 정해진 값을 응답 해 줄 수 있다.
자바의 대표적인 서킷브레이커 라이브러리로는 Resilience4J가 있다.

Spring AOP - Transactional, Async

I'mDawon — Fri, 25 Mar 2022 22:55:50 +0900

Transactional 전파레벨 관련 실험

실험 환경

로컬에서 docker를 띄워 Slave, Master DB를 구성하였다.

Read-Only True시 Slave DB와 연결, Read-Only False시 Master DB와 연결 하도록 구성

Transactional Read-Only False 메소드 안에서 Read-Only True인 메소드가 실행된다면?

호출 한 메소드 (Read-Only False)에서 연결 된 Master DB와의 Connection을 사용한다.
즉, 조회 쿼리 (Read-Only True)도 Slave를 찌르지 않고, Master DB와의 커넥션을 통해 가져오게 된다.

Transactional Read-Only True 메소드 안에서 Read-Only False인 메소드가 실행된다면?

Connection is read-only. Queries leading to data modification are not allowed. 에러 발생

Transaction 전파 레벨

Propagation.REQUIRED
- 스프링의 기본 전파 레벨
- 해당 전파레벨의 메소드를 호출한 곳에서 별도의 트랜잭션이 설정되어 있지 않았다면 트랜잭션을 새로 시작
- 호출한 곳에서 이미 트랜잭션이 설정되어 있다면 기존의 트랜잭션 내에서 로직을 실행
- 예외가 발생하면 롤백이 되고 호출한 곳에도 롤백이 전파

지금까지는 Propagation.REQUIRED로 실행이 되어왔기 때문에, 부모의 트랜잭션 내에서 로직을 실행하였다.

REQUIRED_NEW로 전파레벨을 바꾸어본다면?

예외가 발생하지 않고 별개의 커넥션이 생성되었다.

Propagation.REQUIRED_NEW
- 매번 새로운 트랜잭션을 시작
- 새로운 트랜잭션 안에서 예외가 발생해도 호출한 곳에는 롤백이 전파되지 않음
- 생성된 트랜잭션들은 완전히 독립된 별개의 단위로 작동

Spring AOP - Transactional

@Transactional이 없는 메소드에서 자신의 @Transactional이 붙은 메서드를 실행

JPA의 변경감지가 일어나지 않았다.
변경감지
- Transaction을 Commit하는 순간 영속성 컨텍스트에 있는 엔티티의 변경을 감지
Transaction이 걸리지 않았다.

@Transactional이 없는 메소드에서 외부 @Transactional이 붙은 메서드를 실행

JPA의 변경감지가 일어났다.

트랜잭션의 동작 원리

스프링 @Transactional은 Proxy를 통해 처리 된다.
트랜잭션 어노테이션이 걸려있는 메소드의 클래스의 프록시 객체가 만들어진다.
프록시 객체의 update에서 트랜잭션 비긴, 커밋, 롤백과 같은 작업이 이루어진다.

같은 클래스 내의 메소드를 호출 한 경우 "프록시객체"를 타지 않는다.
자신의 클래스에 있는 update 메소드를 호출한다.

반면 외부에 있는 메소드를 호출했을 때는 프록시 객체를 타게된다.

Async 관련 실험

Read-Only False 메소드에서 @Async로 Read-Only True 메소드를 실행 할 경우

http-nio-8080-exec-1 쓰레드와, task-1 (@Async)쓰레드가 생성되었다.
그리고 각 쓰레드마다 커넥션이 새로 생성되었으며 Transactional Read-Only 설정에 따라 Master, Slave로 연결이 되었다.

@Async Read-Only False 메소드에서 Read-Only True 메소드를 실행

task-1 쓰레드가 생성되었다.
해당 쓰레드에서 가져온 커넥션 (Read-Only False 이기 때문에 Master)로 Read-Only True 메소드인 getUser()가 실행되었다.

Read-Only True에서 @Async Read-Only Ture 메소드 실행

기존 쓰레드 http-nio-8080-exec-2의 커넥션과 task-2의 커넥션이 별도로 생성된다.
둘 다 Read-Only True여서 Slave DB와 연결되었다.

Spring AOP - Async

일반 메소드에서 @Async 붙은 메소드를 실행 (같은 클래스)

세 메소드가 전부 http-nio-8080-exec6 스레드에서 실행된다.
같은 클래스 내에서 실행한 @Async가 무시되었다.

@Async 붙은 메소드에서 @Async 붙은 메소드를 실행 (같은 클래스)

세 메소드가 전부 task-3 스레드에서 실행된다.
같은 클래스 내에서 실행한 @Async들이 무시가 되었다.

결론

같은 클래스 내에서 AOP로 동작하는 어노테이션들 (Transactional, Async)의 호출을 주의하자

[Java]LocalDateTime, OffsetDateTime, ZonedDateTime, Instant

I'mDawon — Wed, 16 Mar 2022 21:41:16 +0900

타임스탬프를 RFC 3339의 형태로 보내 달라는 요구사항을 받았다. 그리고 어떤 값은 밀리세컨드 단위까지, 어떤 값은 세컨드 값 까지만 전달해 달라는 요구사항을 받았다. 어카지?

ISO 8601

날짜와 시간과 관련된 데이터 교환을 다루는 국제 표준
https://ko.wikipedia.org/wiki/ISO_8601

RFC 3339

ISO 8601을 인터넷 프로토콜로 어떻게 다룰지 규정한 RFC
RFC 3339에서는 'T'의 생략을 허용하지 않고, 날짜와 시간 사이의 공백을 허용한다.

ISO 8601과 RFC 3339의 차이

UTC 시간대를 기준으로 여러 포맷이 사용 될 수 있지만 대부분 아래와 같은 형태 일 것이다.

2020–08–28T09:20:26.187+09:00

LocalDateTime(LocalDate, LocalTime)

현재 로컬의 시간 정보

//서울
System.out.println(LocalDateTime.now());
2022-03-16T21:26:25.495803

//몬트리올
System.out.println(LocalDateTime.now());
2022-03-16T08:23:38.556553

컴퓨터의 시간을 그대로 나타내주고 있음

OffestDateTime

타임존에 대한 정보를 가지고 있다...!

System.out.println(OffsetDateTime.now());
2022-03-16T21:29:11.227296+09:00

ZonedDateTime

OffestDateTime에서 ZoneRegion에 대한 정보까지 포함
+09:00 시간대에 서울특별시-대한민국 말고도, 중국 칭다오나 일본 후쿠오카 같은 지역도 포함된다.

System.out.println(ZonedDateTime.now());
2022-03-16T21:39:36.821077+09:00[Asia/Seoul]

Instant

유닉스 시간 : POSIX 시간이나 Eporch 시간이라 부르기도 한다.
- 1970년 1월 1일 00:00:00 협정 세계시 (UTC)로 부터의 경과 시간을 초로 환산하여 표현한 것 이다.
- 자바의 System.currentTimeMillis() 현재의 유닉스 시간을 밀리초로 반환한다.

System.out.println(Instant.now());
System.out.println(Instant.ofEpochMilli(System.currentTimeMillis()));
//2022-03-20T16:32:04.204752Z
//2022-03-20T16:32:04.204Z
//현재 한국은 2022-03-21 01:32

now()로 하면 나노초 단위까지 계산 밀리초 단위 까지 계산하려면 ofEpochMili()를 사용한다.

초 단위 까지만 표기하기

System.out.println(OffsetDateTime.now().withNano(0));
//2022-03-21T01:32:04+09:00

withNano(0)시 밀리세컨드 또한 사라진다.
OffsetDateTime은 밀리초단위는 컨트롤을 못한다...;

밀리 세컨드 단위 까지 표현하기

System.out.println(OffsetDateTime.ofInstant(Instant.ofEpochMilli(Instant.now().toEpochMilli()), ZoneId.systemDefault()));
System.out.println(OffsetDateTime.ofInstant(new Date().toInstant(), ZoneId.systemDefault()));
//2022-03-21T01:32:04.204+09:00
//2022-03-21T01:32:04.204+09:00

Date도 시간을 currentTimeMillis로 가지고 있다.

    public Date() {
        this(System.currentTimeMillis());
    }

기존 LocalDateTime을 OffsetDateTime으로 변경하기

System.out.println(localdateTime);
System.out.println(localdateTime.atOffset(OffsetDateTime.now().getOffset()));

//2022-03-21T01:44:52.083033
//2022-03-21T01:44:52.083033+09:00

atOffset을 활용해서 offset을 붙혀 줄 수 있다.

[Java]컬렉션(Collections) 정리

I'mDawon — Thu, 2 Dec 2021 20:56:42 +0900

컬렉션 프레임워크 란?

다수의 데이터를 쉽고 효과적으로 처리할 수 있는 표준화된 방법을 제공하는 클래스의 집합을 의미한다.
자료구조와 알고리즘을 구조화 하여 클래스로 구현해 놓은 것

https://techvidvan.com/tutorials/java-collection-framework/

구분	종류	중복 허용	순서 존재	정렬 여부	THREAD-SAFE
LIST	ArrayList	O	O	X	X
	LinkedList	O	O	X	X
	Vector	O	O	X	O
SET	HashSet	X	X	X	X
	Linked HashSet	X	O	X	X
	TreeSet	X	X	O	X
MAP	HashMap	X	X	X	X
	Linked HashMap	X	O	X	X
	Hashtable	X	X	X	O
	TreeMap	X	X	O	X

List는 중복이 가능하고, 순서가 있는 데이터의 집합이다.

ArrayList - 특정 원소 조회가 많은 경우 사용하는 것이 좋다.
- 배열을 이용하여 만든 리스트
- 기본 크기는 10이지만 원소가 늘어나면 더 큰 배열에 옮긴다.
- 인덱스로 조회가 가능하므로, 인덱스만 알면 해당 데이터를 빠르게 조회 할 수 있다.
- 삽입, 삭제를 하면 그 뒤에 있는 데이터를 뒤로 밀거나 앞으로 당겨야 하기 때문에 느리다. (O(N))

LinkedList - 조회보다 삽입/삭제가 많은 경우에 사용하는 것이 좋다.
- 노드와 포인터를 이용하여 만든 리스트이다.
- 특정 원소를 조회하는 경우 첫 노드 부터 순회해야 하기 때문에 ArrayList에 비해 느리다.
- 포인터로 각각 노드들을 연결하고 있어서, 삽입/삭제가 빠르다.
  - 단순히 기존 포인터를 끊고 새로운 노드에 연결하면 되기 때문이다.
  - 그러나 중간에 데이터를 삽입, 삭제 할 경우 그 데이터까지 순차적으로 조회해야 하기 때문에 O(N)의 시간복잡도를 가진다.
Vector - ArrayList와 비슷하게 배열로 만들어진 리스트지만, thread-safe하다.
- 한번에 하나의 스레드만 접근이 가능하다.
- get, put에 모두 syncronized가 걸려있어서 스레드마다 lock이 걸리게 되고, 성능이 ArrayList보다 좋지 않다.
Stack - LIFO(Last-In-First-Out)특성을 가지는 자료구조이다.
- 마지막에 들어온 원소가 처음으로 나가는 특징을 가진다.
- 들어올 때는 push, 나갈때는 pop이라는 용어를 사용한다.

Set은 중복이 불가능하고, 순서가 없는 데이터의 집합이다.

HashSet - 중복을 허용하지 않고, 순서를 가지지 않는다.
- HashSet이 판단하는 동일한 객체란 꼭 같은 인스턴스를 뜻하지 않는다. (동일성)
- HashSet은 객체를 저장하기 전에 먼저 객체의 hashCode() 메소드를 호출한다. 그리고 같다면 equals()로 두 객체리를 비교해서 동등성을 판단한다.

    @Test
    public void hashSetTest() {
        Set<String> hashSet = new HashSet<>();
        hashSet.add("하나");
        hashSet.add("둘");
        hashSet.add("셋");

        System.out.println(hashSet);

        hashSet.add("넷");
        hashSet.add("다섯");

        System.out.println(hashSet);

    }

LinkedHashSet - 중복은 허용하지 않지만, 순서를 가진다.

    @Test
    public void linkedHashSetTest() {
        Set<String> hashSet = new LinkedHashSet<>();
        hashSet.add("하나");
        hashSet.add("둘");
        hashSet.add("셋");

        System.out.println(hashSet);

        hashSet.add("넷");
        hashSet.add("다섯");

        System.out.println(hashSet);

    }

TreeSet - 중복은 허용하지않고, 순서를 가지지 않는다. 그러나 정렬이 되어있다.
- 이진트리를 기반으로 한 Set컬렉션이다.

    @Test
    public void treeSetTest() {
        Set<String> hashSet = new TreeSet<>();
        hashSet.add("하나");
        hashSet.add("둘");
        hashSet.add("셋");

        System.out.println(hashSet);

        hashSet.add("넷");
        hashSet.add("다섯");

        System.out.println(hashSet);
    }

Queue는 FIFO(First-In-First-Out)구조를 가진다.

처음 들어온 원소가 처음으로 나간다는 특징이 있다.
들어올때는 enqueue, 나갈때는 dequeue라고 한다.
PriorityQueue는 우선순위를 가지는 큐로 원소에 우선순위를 부여하여 높은 순으로 먼저 반환한다.
Dequeue는 양쪽으로 넣고 빼는 것이 가능한 큐 자료구조 이다.

Map은 키와 값을 가지고 순서는 기억하지 않으며 키는 중복이 불가능하고, 값은 중복이 가능한 데이터 집합이다.

HashMap은 키와 값을 가지고, 순서는 기억하지 않으며 키는 중복이 불가능하고, 값은 중복이 가능하다.
- key와 value에 null을 허용한다.
- 동기화를 보장하지 않는다.

    @Test
    public void hashMapTest() {
        Map<String, String> hashMap = new HashMap();
        hashMap.put("사과", "apple");
        hashMap.put("포도", "grape");
        hashMap.put("수박", "watermelon");
        hashMap.put("배", "pear");

        System.out.println(hashMap);
    }

HashTable은 HashMap과 동일한 특징을 가지지만 Thread-Safe하여 동기화를 지원한다.
- key와 value에 null을 허용하지 않는다.
- 동기화를 보장한다.
  - get(), put(), remove() 등에 syncronized 키워드가 붙어있다.
LinkedHashMap은 들어온 순서대로 순서를 가지는 Map이다.

    @Test
    public void linkedHashMapTest() {
        Map<String, String> hashMap = new LinkedHashMap<>();
        hashMap.put("사과", "apple");
        hashMap.put("포도", "grape");
        hashMap.put("수박", "watermelon");
        hashMap.put("배", "pear");

        System.out.println(hashMap);
    }

TreeMap은 key를 기준으로 정렬이 되어 저장되는 Map이다.
- 이진트리를 기반으로한 Map이다.
  - 부모 키값을 비교하여 낮은 건 왼쪽에 높은건 오른쪽에 Map.Entry를 저장한다.
  - 그래서 저장시간이 다른 자료구조에 비해 오래 걸린다.

    @Test
    public void treeMapTest() {
        Map<String, String> hashMap = new TreeMap<>();
        hashMap.put("사과", "apple");
        hashMap.put("포도", "grape");
        hashMap.put("수박", "watermelon");
        hashMap.put("배", "pear");

        System.out.println(hashMap);
    }

[Spring]프로토타입과 스코프

I'mDawon — Thu, 2 Dec 2021 17:02:53 +0900

토비의 스프링 vol2 챕터 1.3 프로토타입과 스코프를 읽고 정리한 글 입니다.

스코프

존재할 수 있는 범위
빈 오브젝트가 만들어져 존재할 수 있는 범위이다.

스프링 빈은 기본적으로 싱글톤으로 만들어 진다.

애플리케이션 컨텍스트마다 빈의 오브젝트는 한 개만 만들어진다.
요청이 있을 때마다 매번 애플리케이션 로직을 담은 오브젝트를 새로 만드는 건 비효율적이기 때문이다.
하나의 빈 오브젝트에 동시에 여러 스레드가 접근하기 때문에 상태 값을 인스턴스 변수에 저장해 두고 사용할 수 없다.
싱글톤으로 설정된 빈은 DI, DL시 항상 같은 오브젝트가 리턴됨이 보장된다.
- DL (Dependency Lookup) : 컨테이너에서 getBean()을 통해 조회하는 것,
- 주입 받는 것이 아니라 직접 필요한 의존관계를 찾는 것.

프로토타입 스코프는 컨테이너에게 빈을 요청할 때마다 매번 새로운 오브젝트를 생성해준다.

프로토타입 빈은 IoC의 기본 원칙을 따르지 않는다.
프로토타입 스코프를 갖는 빈은 요청이 있을 때마다 컨테이너가 생성하고 초기화하고 DI까지 해주기도 하지만 일단 빈을 제공하고 나면 컨테이너는 더 이상 빈 오브젝트를 관리하지 않는다.
프로토타입 빈은 생성 후 관리는 전적으로 DI 받은 오브젝트에 달려있다.
- 프로토타입빈을 주입받은 빈이 싱글톤이라면, 이 빈에 주입된 프로토타입 빈도 역시 싱클톤 생명 주기를 따름
- 그러나 주입받은 빈의 스코프가 더 작다면, 프로토타입 빈도 해당 빈과 함께 제거
- 메소드 안에서 사용하고 따로 저장해 두지 않는다면, 메소드가 끝나고 프로토타입 빈도 제거

IoC의 기본 개념은 애플리케이션을 구성하는 핵심 오브젝트를 코드가 아니라 컨테이너가 관리한다는 것이다. 그래서 스프링이 관리하는 오브젝트인 빈은 그 생성과 다른 빈에 대한 의존관계 주입, 초기화(메소드 호출), DI, DL을 통한 사용, 제거에 이르기까지 모든 오브젝트의 생명주기를 컨테이너가 관리한다. 빈에 대한 정보와 오브젝트에 대한 레퍼런스는 컨테이너가 계속 갖고 있고, 필요할
때마다 요청해서 빈 오브젝트를 얻을 수 있다.

프로토타입 빈은 내부에서 스프링의 DI를 통해 빈을 주입받아야 할 경우 사용한다.

프로토타입 빈은 코드에서 new로 오브젝트를 생성하는 것을 대신하기 위해 사용된다.
사용자 요청별로 독립적인 정보나 작업 상태를 저장해둘 오브젝트를 만들 필요가 있다.
이 경우 new로도 충분한데, 왜 프로토 타입 빈을 사용할까?
사용자 요청에 따라 매번 독립적인 오브젝트를 만들어야 하는데, 매번 새롭게 만들어지는 오브젝트가 컨테이너 내의 빈을 사용해야 하는 경우 즉, 프로토타입 빈안에서 DI가 필요한 경우 사용한다.
코드에서 일일이 수동으로 DI를 해줄 것이 아니라면 프로토타입빈으로 생성하는 것이 좋다.
매번 새로운 오브젝트가 필요하면서 DI를 통해 다른 빈을 사용할 수 있어야 한다면? -> 프로토타입빈 사용

요청 스코프 빈은 하나의 웹 요청 안에서 만들어지고 해당 요청이 끝날 때 제거된다.

각 요청별로 독립적인 빈이 만들어지기 때문에 빈 오브젝트 내에 상태 값을 저장해 둬도 안전하다.
하나의 웹 요청을 처리하는 동안 참조하는 요청 스코프 빈은 항상 동일한 오브젝트임이 보장된다.

세션 스코프는 HTTP 세션과 같은 존재 범위를 갖는 빈이다.

HTTP 세션은 사용자별로 만들어지고 브라우저를 닫거나 세션 타임이 종료될 때까지 유지되기 때문에 로그인 정보나 사용자별 선택옵션을 저장해두기에 유용하다.
웹 환경에종속적인 HttpSession을 다른 계층으로 넘겨서 사용하게 하는 건 좋지 않다. -> HTTP 세션에 저장되는 정보를 웹 기술에 종속적이지 않은 오브젝트에 담아서 (ex. DTO(?)) HTTP 세션에 직접 접근이 가능한 프레젠테이션과 서비스 계층사이에 주고받아야 한다.
세션 스코프를 이용하면 이런 번거로움 없이도 HTTP 세션에 저장되는 정보를 모든 계층에서 안전하게 이용할 수 있다.

애플리케이션 스코프는 서블릿 컨텍스트에 저장되는 빈 오브젝트이다.

서블릿 컨텍스트는 웹 애플리케이션마다 만들어진다.
웹 애플리케이션마다 스프링의 애플리케이션 컨텍스트도 만들어진다.
드물지만 웹 애플리케이션과 싱글톤 스코프가 다른 경우가 있다.
애플리케이션 스코프도 싱글톤 스코프와 마찬가지로 상태를 갖지 않거나, 상태가 있다고 하더라도 읽기전용으로 만들거나, 멀티스레드 환경에서 안전하도록 만들어야 한다.

스프링 빈 생명주기 메소드로 초기화 메소드와 소멸메서드가 있다.

해당 부분은 초보 웹 개발자를 위한 스프링5 프로그래밍 입문의 내용을 정리하였습니다.

컨테이너가 관리하는 빈 객체의 라이프사이클은 객체 생성 -> 의존 설정 -> 초기화 -> 소멸의 라이프 사이클을 가진다. 스프링 컨테이너는 빈 객체를 초기화하고 소멸하기 위해 빈 객체의 지정한 메서드를 호출한다. 스프링은 다음의 두 인터페이스에 이 메서드를 정의하고 있다.

InitializingBean
DisposableBean

모든 클래스가 위의 인터페이스를 구현하여 사용할 수 있는 것이 아니다. 외부에서 제공받은 클래스에서 사용하고 싶은 경우에는 스프링 설정에서 직접 초기화, 소멸 메서드를 지정할 수 있다.

@Bean(initMethod="connect", destroyMethod="close")
public Client2 client2() {
    Client2 client = new Client2();
    client.setHost("Host");
    return client;
}

혹은 @PostConstruct, @PreDestory 애노테이션을 적용해서 초기화, 소멸 메서드를 지정 할 수 있다.

스프링은 왜 싱글톤을 기본 스코프로 사용할까?

서버 성능에 좋기 때문이다.
IoC컨테이너를 통해 주입받는 싱글톤 스코프 빈은 '동일성'을 보장한다.
스프링이 주로 적용되는 대상은 자바 엔터프라이즈 기술을 사용하는 서버환경이다. 초 당 많은 요청을 받아내야 하고, 요청을 처리하기 위해 컨트롤러 단, 서비스 단, 레포지토리 단으로 많은 계층으로 구성되어있다. 그리고 이 계층 마다 다양한 객체들이 참여하여 협력한다.
그런데 요청이 들어올 때 마다 비즈니스 로직 처리를 위한 객체를 새로 생성한다면? -> 힙 메모리가 꽉 찰 것이다.

멀티 스레드 환경에서 싱글톤은 무상태성으로 만들어져야 한다.

싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다.
다중 사용자의 요청을 한꺼번에 처리하는 스레드들이 동시에 싱글톤 오브젝트의 인스턴스 변수를 수정하는 것은 매우 위험하다.
저장할 공간이 하나 뿐이니 서로 값을 덮어쓰고, 자신이 저장하지 않은 값을 읽어올 수 있기 때문이다.

[DB]트랜잭션 정리

I'mDawon — Thu, 2 Dec 2021 12:57:10 +0900

에이든의 트랜잭션 매커니즘, 샐리, 예지니어스의 트랜잭션 테코톡을 듣고 정리한 글 입니다.

트랜잭션

여러 쿼리를 논리적으로 하나의 작업으로 묶어주는 것
하나의 트랜잭션은 커밋 혹은 롤백된다.
데이터베이스에 저장된 데이터베이스의 무결성과 동시성의 성능을 지키기위해 트랜잭션의 설정이 중요

ACID

트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질
Atomicity
- 트랜잭션은 DB에 모두 반영되거나, 전혀 반영되지 않아야 한다.
- 완료되지 않은 트랜잭션의 중간 상태를 DB에 반영해서는 안 된다.
Consistency
- 트랜잭션 작업처리결과는 항상 일관성 있어야 한다.
- 데이터베이스는 항상 일관된 상태로 유지되어야 한다.
Isolation
- 둘 이상의 트랜잭션이 동시 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없다.
Durability
- 트랜잭션이 성공적으로 완료되었으면 결과는 영구히 반영되어야 한다.
- 커밋이 되었다면, 정전과 같이 예상치 못한 문제가 발생 되었더라도 데이터는 반영된 그대로 남아있어야 한다.

트랜잭션 격리 수준

동시에 DB 접근할 때 그 접근을 어떻게 제어할지에 대한 설정
격리 수준이 높아 질 수록 데이터 정합성은 좋아지나 동시성 성능이 떨어진다.

격리수준

READ-UNCOMMITTED
- 커밋 전의 트랜잭션의 데이터 변경 내용을 다른 트랜잭션이 읽는 것을 허용
READ-COMITTED
- 커밋이 완료된 데이터만 다른 트랜잭션에서 조회가능
- 트랜잭션이 이루어지는 동안 다른 사용자는 해당 데이터에 접근이 불가능하다.
REPEATABLE-READ
- 트랜잭션 범위 내에서 조회한 내용이 항상 동일함을 보장
SERIALIZABLE
- 한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서 접근 불가

	DIRTY READ	NON-REPEATABLE READ	PHANTOM READ
READ UNCOMMITTED	발생	발생	발생
READ COMMITED	없음	발생	발생
REPEATABLE READ	발생	발생	발생 (InnoDB는 없음)
SERIALIZABLE	없음	없음	없음

DIRTY READ
- 더티페이지(메모리에는 변경이 되었지만 디스크에는 아직 변경이 되지 않은 데이터)에 있는 데이터를 검색한다. 커밋되지 않은 데이터를 리드하기 때문에 더티리드 후 더티페이지가 롤백이 되면 잘못된 데이터를 읽어온 경우가 되어버린다.
- 아래 예시에서 트랜잭션 A가 트랜잭션을 끝마치지 못하고 롤백한다면 트랜잭션 B는 무효가 된 값을 읽고 처리한다.

NON-REPEATABLE READ
- 같은 트랜잭션 내에서 READ시 값이 다르게 나오는 데이터 불일치 문제
- 하나의 트랜잭션에서 같은 쿼리를 두번 이상 수행할 때, 똑같은 쿼리임에도 다른 결과를 볼 수 있게 되는 현상
- 트랜잭션 중 데이터가 변경되면 문제가 발생할 수 있다.

Phantom Read
- NON-REPREATABLE READ의 한 종류
- 하나의 트랜잭셩네서 일정 범위의 레코드를 두번이상 읽을 때, 똑같은 쿼리임에도 첫번째 쿼리에서 없던 레코드가 두번째 쿼리에서 나타나는 현상

트랜잭션 전파 타입

트랜잭션 경계에서 이미 진행중인 트랜잭션이 있을 어떻게 동작할지 결정하는 것

전파타입

REQUIRED
- 현재 진행중인 트랜잭션이 존재하면 해당 트랜잭션을 사용한다.
- 존재하지 않으면 새로운 트랜잭션을 생성한다.
- 두 메서드가 하나의 트랜잭션으로 실행되기 때문에 어느 메서드에서 문제가 발생해도 실행했던 모든 쿼리가 롤백된다.

SUPPORTS
- 진행중인 트랜잭션이 있다면 트랜잭션을 사용한다.
- 진행중인 트랜잭션이 없다면 트랜잭션 없이 메서드가 정상동작한다.
MANDATORY
- REQUIRED와 달리 진행 중인 트랜잭션이 존재하지 않을 경우 예외가 발생한다.
REQUIRES_NEW
- 항상 새로운 트랜잭션을 시작한다.
- 진행 중인 트랜잭션이 존재하면 기존 트랜잭션을 일시 중지하고 새로운 트랜잭션을 시작한다.
- 새로운 트랜잭션이 종료된 뒤에 기존 트랜잭션이 계속된다.
NOT_SUPPORTED
- SUPPORT와 달리 진행 중인 트랜잭션이 존재할 경우 메서드가 실행되는 동안 트랜잭션을 일시 중지 되고 메서드 실행이 종료된 후에 트랜잭션을 계속 진행한다.
- 트랜잭션을 사용하지 않는 설정
NEVER
- 메서드가 트랜잭션을 필요로 하지 않는다.
- 만약 진행 중인 트랜잭션이 존재하면 예외 발생
NESTED
- 진행 중인 트랜잭션이 존재하면 그 안에 새로운 트랜잭션을 만드는 설정
- 중첩된 트랜잭션 2는 부모인 트랜잭션1의 커밋, 롤백에는 영향을 받는다.
- 트랜잭션2의 커밋 롤백에는 트랜잭션1이 영향을 받지 않는다.

Timeout

@Transactional(timeout=10)

초 단위로 트랜잭션 제한시간을 설정할 수 있는 속성
설정된 시간이 지나면 예외가 발생하며 롤백
따로 설정하지 않으면 timeout 속성은 지정되어 있지 않음

readOnly

@Transactional(readOnly=true)

트랜잭션 작업 안에서 update, insert, delete 작업이 일어나는 것을 방지
해당 옵션을 적용하면 flush 모드가 manual로 설정되어 jpa의 더티체킹 기능 무시 하여 성능향상에 도움을 줌

rollbackFor

@Transactional(rollbackFor=NoSuchElementException.class)

체크예외를 롤백 대상으로 삼고싶을 때 사용한다.
기본적으로 트랜잭션은 런타임 예외와 Error가 발생했을 때만 롤백
체크예외나 예외가 발생하지 않으면 커밋하도록 한다.

noRollbackFor

@Transactional(noRollbackFor={IOException.class, SqlException.class})

롤백 대상인 지정된 런타임 예외를 롤백하지 않고 커밋하도록 한다.

트랜잭션 메커니즘

BEGIN TRAN
UPDATE accounts
SET balance = balance - 10000
WHERE user = '구매자'
SET balance = balance + 10000
WHERE user = '판매자'
COMMIT TRAN

UPDATE accounts SET balance = balance - 10000 WHERE user = '구매자' 쿼리 실행
업데이트에 필요한 데이터를 데이터 캐시에 요청을 하는데, 데이터 캐시에 해당 데이터가 없다.
데이터 파일에서 데이터를 가져와야 한다.
그리고 데이터 캐시에 필요한 데이터가 로드 된다.

User Balance

구매자 10,000
데이터가 로드 된 후, 업데이트를 하면 되는데 그 전에 로그 캐시에 로그를 기록해야 한다.
ReDo로그와 UnDo로그에 기록을 한다.
- ReDo 로그
  - 변경 후의 값을 기록한다.
  - ```
  트랜잭션_1 START
  트랜잭션_1 UPDATE accounts 구매자.balance 0
```
- UnDo 로그
  - 변경 전의 값을 기록한다.
  - ```
  로그_1 accounts 구매자.balance 10000
```
로그 기록 후 데이터 캐시에 있는 값을 변경하면 된다.

User Balance

구매자 0
UPDATE accounts SET balance = balance + 10000 WHERE user = '판매자' 쿼리 실행
판매자의 데이터가 없으므로 데이터 파일에서 데이터 캐시로 로드

User Balance

구매자 0

판매자 0

ReDo로그와 UnDo로그에 기록을 한다.

ReDo로그

트랜잭션_1 START
트랜잭션_1 UPDATE accounts 구매자.balance 0
트랜잭션_2 UPDATE accounts 판재마.balance 10000

UnDo로그

로그_1 accounts 구매자.balance 10000
로그_2 accounts 판매자.balance 0

데이터 캐시의 데이터 업데이트

User Balance

구매자 0

판매자 10000
트랜잭션의 한 단위가 끝났다.

데이터 롤백 시 UnDo로그를 통해 롤백한다.

UnDo를 통해서 역순으로 기록을하게 되면 데이터가 이전 상태로 원복 된다.

로그_1 accounts 구매자.balance 10000
로그_2 accounts 판매자.balance 0

User	Balance
구매자	10000
판매자	0

예상치 못한 오류 발생 시 ReDo로그와 UnDo로그를 통해 복구한다.

ReDo로그를 순차적으로 실행 해서 데이터들을 다시 일관성 있게 만들어 준다.

트랜잭션_1 START
트랜잭션_1 UPDATE accounts 구매자.balance 0
트랜잭션_2 UPDATE accounts 판재마.balance 10000

Undo로그를 역순으로 실행하여 다시 커밋이 되지 않은 것들을 다시 이전 상태로 돌려준다.

로그_1 accounts 구매자.balance 10000
로그_2 accounts 판매자.balance 0

참고

우아한테크코스 글쓰기 아카이브

I'mDawon — Sat, 20 Nov 2021 16:43:48 +0900

[LV.1]우아한테크코스 한달 생활기

매일 만나는 데일리 미팅

우아한테크코스는 한 명의 코치와 13~14명 정도의 크루들이 함께 데일리 미팅을 진행한다. 내가 속한 데일리 조는 매일 마스터가 정해진다. 마스터들이 대화 할 주제를 마련해 온다. 코로나때문에 온라인으로 크루들을 만나야 했다. Gather라는 가상공간과 아바타를 이용한 화상 미팅 서비스를 알게 되었다. 그렇게 우리의 모임은 Gather안에서 진행 되었다. 그곳에서 크루들이 만들어 놓은 해변가도 같이 거닐고 OX게임도 진행하였다. 첫 시작 부터 크루들을 못만나는 것이 아쉬웠었다. 그러나 Gather 덕분에 매일 아침을 즐겁게 시작할 수 있었다. 나름 대로 코로나 시국을 잘 헤쳐나가고 있었다!

연극 대신 보라

우아한 테크코스 3기에서는 "연극" 대신 "보이는 라디오"를 하게 되었다. 누구나 한번 쯤 해보지 않을 일을 앞에 두고 겁을 먹은 적이 있을 것이다. 보이는 라디오 미션을 받은 내가 그랬다. 어떻게 해야 할지 모르는 요구사항도 주어졌다. 줌에서 한 사람당 배경을 4번씩 바꾸면서 라디오를 진행해야 한다. 난 줌을 우테코와서 거의 처음 써봤다. 그리고 만난지 일주일 정도 지난 크루들과 보이는 라디오를 준비해야 해야 했다. '잘 할 수 있을까?' 걱정이 앞섰다.

그러나 내 걱정과는 반대로 보이는 라디오는 꽤 성공적으로 끝이 났다. 일단 주제가 빨리 정해 졌다. 그리고 일정시간 상의 후 바로 실전 연습에 돌입했다. 머리를 싸매고 고민하는 시간이 길지 않게 했다. 직접 연습을 하며 대본을 그때그때 대본을 수정했다. 결과는 성공적이었다!

보이는 라디오를 통해 실행의 중요성에 대해 깨닫게 되었다. 무언가를 시작하기 위해 준비하는 기간이 길어질 수록 두려움은 커져간다. 불완전한 완벽주의가 발동하는 것이다. 누구든 완벽하기란 어렵다. 아무것도 하지 않으면 아무것도 일어나지 않는다. 완벽해야 한다는 두려움 그것을 버려야 한다. 그럴 때 빨리 실행을 하는 것은 중요하다. 생각의 미궁 속을 빨리 벗어 날 수 있도록 해주기 때문이다. 이번 보이는 라디오를 통해 행동 하는 것의 중요성을 다시 느끼게 되었다.

페어 프로그래밍

우테코는 짝 프로그래밍이라는 제도가 있다. 짝 프로그래밍은 네비게이터와 드라이버가 있다. 네비게이터는 프로그래밍을 하며 전체적으로 의견을 제시한다. 드라이버는 네비게이터의 안내를 받으며 코드를 작성한다. 드라이버라고 무조건 네비게이터의 말을 따를 필요는 없다. 드라이버 또한 자신의 의견을 말해야 한다. 의미있는 커뮤니케이션을 많이 할 수록 건강한 페어 프로그래밍이 된다!

페어 프로그래밍 전에 실력이 나보다 월등한 페어를 만날까봐 걱정했다. 잘하는 페어를 만나면 나는 많이 배울 수 있다. 그러나 내 페어는 과연 나와의 프로그래밍이 재미있을까 라는 의문이 들었다. 그러나 걱정을 해도 걱정은 없어지지 않는다. 할 수 있는 한 진지하게 미션에 임하기로 하였다. 어느 상황에서도 최선을 다하기로 결심했다!

처음에는 사실 장점이 무엇인지 잘 알지 못했다. 지금까지 총 4번의 페어 프로그래밍을 진행했다. 일단 페어 프로그래밍을 하면 평소보다 말을 5배정도 많이 하게 된다. 그 만큼 상대방과 의사소통을 많이 할 수 있다. 확률적으로(?) 영양가 있는 커뮤니케이션이 발생할 확률도 높다! 그래서 이전 보다 페어 프로그래밍에 대해 긍정적으로 생각하게 되었다.

혼자가 아니라 둘이 미션을 진행하다 보니 의견이 부딪힐 때가 있다. 그 때마다 내 생각을 페어에게 잘 전달해야 한다. 페어 프로그래밍을 하면서 의사소통의 중요성을 정말 많이 깨닫게 되었다. 페어와 대화하면서 논리정연하지 못한 나에게 답답함을 느꼈다. 앞으로 더욱 더 커뮤니케이션을 잘하고 싶다는 생각이 들었다.

제가.. 책을 읽어요

이전에 "개발관련 책을 한권 다 읽은 적이 있는가?"에 대한 질문에 자신있게 답을 못했을 것이다. 시험공부를 위해 급하게 읽었다. 시험을 위해서 빨리 머리속에 지식을 넣어야 했다. 또한 눈앞의 이슈를 해결하기 위해서 슬쩍 찾아본 것이 다였다. 내 것으로 만들기 보다는 휘발성이 짙은 공부를 많이 했었다. 나중에 가면 내가 뭘 공부했는지 설명을 못했다.

"의식적인 연습" 나는 그것을 하지 못하고 있었다. 그냥 흐르는 대로 공부했다고 개발실력이 느는 것이 아니었다. 나 스스로 부족한 것이 무엇인지 찾아야 한다. 그런 다음 그것에 대해 직접 찾아보고 부딪히며 지식을 습득해야 한다.

우테코에서 떠먹여 주는 것 보다 공부에 집중 할 수 있는 환경을 제공해 주겠다고 했다. 이러한 환경조성을 위해 크루들에게 많은 경험을 하게 해주었다. 나는 특히 학습로그와 필독서를 정해 준 것이 많은 도움이 되었다. 우테코를 통해 내 학습 방식이 건강하지 못했음을 깨달았다. 내 학습방식에 많은 변화를 줄 수 있어서 기쁘다.

[LV.2] 우테코에서 찾은 나만의 효과적인 공부법

제가 2021년에 우테코에 있었을 때...

우리는 무언가를 끝냈을 때, "어땠어?" 라는 질문을 받는다. 과거의 나는 갑자기 머리속이 뒤엉키면서 "음.. 재미있었어"와 같은 형식적인 대답을 하곤 했다. 우테코를 시작하고나서 "우테코 어때?"라는 질문을 많이 받았다 . 그때도 "좋아", "많이 배우고 있어"와 같이 짤막한 대답을 했었다.

레벨 1 두번째 미션 부터 학습로그를 작성해야 한다. 학습로그 작성 가이드에서 "메타인지"라는 단어가 자주 나온다. 메타인지란 자신의 생각에 대해 판단하는 능력을 말한다. 나는 학습로그를 어떤 개념에 대해 공부를 했고, 이번 미션에서 어떻게 적용했는지 작성하고 있다. 학습로그를 작성 할 때마다 스스로를 되돌아 봐야 한다. 돌아보는 과정에서 과거의 나에 대한 정리가 되는 동시에 미래의 내가 어떠한 방향으로 나아가야 하는지 생각하게 된다.

학습로그 작성에서 더 나아가 3명의 크루들이 뭉쳐 학습로그 토론을 해야 한다. 토론 시작 전에는 늘 무엇을 말해야 하나 걱정이 앞선다. 앞에서 언급한 것처럼 당황해서 아무 말도 못할 것 같다. 그러나 걱정과 달리 나는 학습로그 토론에서 생각보다 말을 잘했다! 스스로 한번 정리해 본 것에 대해서는 말이 술술 잘 나온다. 여기서 "되돌아 본다"라는 것의 중요성을 다시 한번 깨닫는다.

우테코를 진행하면서 "회고"에 대한 얘기를 많이 듣는다. 어떤 크루는 미션이 끝날 때마다 페어와 회고를 한다고 한다. 어떤 크루는 매일 자기가 배운 것을 정리하는 TIL을 작성한다고 한다. 이제 나도 "회고"라는 것을 자주 하고 있다. 여기에는 꼭 내가 무엇을 느꼈는지가 들어가야 한다. 흘러가는 것들을 그냥 두지 않고 의미있게 붙잡아 두는 연습을 하고 있다.

우테코 레벨 1, 레벨2를 거치면서 많은 미션들을 수행했고, 수행하고 있다. 코드리뷰를 받는다. 그리고 많은 수업들이 진행되었고 수업마다 영양가 있는 질문들이 많이 나온다. 그리고 스터디를 진행한다. 테코톡를 듣는다.... 이렇게 우테코 과정 속에서 나는 많은 지식들을 얻는다. 내가 생각하는 공부 방법은 이렇게 지나쳐 가는 것들을 순간에 기록하는 것이다. 그리고 한 번 다시 되돌아 보는 것이다. 그리고 여기서 내가 몰랐던 게 무엇인지, 앞으로 어떤 것을 공부하는지 추려낸다. 매일 양질의 지식을 얻을 수 있는 우테코는 이러한 공부 방법을 진행하기에 최적의 환경이다. 나는 이러한 것들을 놓치지 않고 기록 하고, 다시 되돌아 보고 내 것으로 만들고 있다.

이번 모의 면접에서 받은 인상깊은 피드백이 있다.

"잘 알고 있는 것을 설명할 때와 잘 모르는 것을 설명 할 때 확연히 티가 난다."

다른 사람은 어떨지 몰라도 나는 정리되지 않은 것에 대해 말하는 게 어렵다. 보완할 방법은 계속해서 스스로를 회고하는 것이라는 걸 깨달았다. 앞으로 누군가 나에게 "우테코 어땠어?" 라는 질문을 한다면, 예전과 같이 당황하며 짤막한 대답을 하지 않을 것이다. "제가 2021년에 우테코에 있었을 때..." 로 시작하는 투머치 토커가 될 수 있을 정도로 회고를 해야 겠다!

의식적인 연습 근데 이제 페어를 곁들인

우테코를 시작하기 전에는 피드백을 줄 사람도, 기술에 대해 토론을 할 사람도 주변에 없었다. 무엇이 부족한지, 무엇을 배워야 하는지 혼자 결정했다. 혼자 하니 포기도 쉬워졌다. 눈앞에 문제점을 해결하느라 컴포트 존을 벗어나지 못했다. 조금만 어려우면 다른 방법을 찾거나 그냥 놓아버렸다. 의식적인 연습이 아니라 흘러가는 대로 학습하고 있었다. 그러나 우테코 과정에서 페어 프로그래밍을 하게 되면서 의식적인 연습의 중요성을 느꼈다.

페어 프로그래밍을 진행하면서 "단축키 쓰기"에 대한 의식적인 연습을 강제로 하게 되었다. 예전에 단축키를 잘 사용하지 않았던 터라 처음에는 불편했다. 점차 익숙해지면서 이것만큼 편한게 없구나 라는 걸 알게 되었다. 이제는 단축키를 사용하지 않으면 바로 "아 맞다"를 시전한다. 이제는 단축키를 사용하는 걸 의식하게 되었다! 앞으로는 좀 더 현란하게 단축키를 사용하는 개발자가 되어야 겠다고 다짐 했다.

TDD로 개발하기 또한 페어 프로그래밍을 통해 확실하게 연습할 수 있었다. TDD는 계속 해서 연습해 왔던 부분이긴 하지만, 가끔 나도 모르게 구현부터 시작 할 때가 있다. 그럼 옆에서 페어가 말해준다. "안돼 테스트 코드 먼저 짜야지." 만약 혼자 했었다면 구현을 먼저 하고 있었을 지도 모른다. 페어와 함께해서 기분 좋은 제약이 생기고, 이를 통해 의식적인 연습을 할 수 있었다. 이러한 연습을 마치고 나면 더 나아가고 싶다는 생각이 든다. 그래서 이번 지하철 노선도 미션에서는 "테스트 코드가 다 통과 될 때까지 웹으로 확인하지 않기" 라는 셀프 퀘스트를 만들었다. 이를 통해 이전보다 기능목록 작성을 꼼꼼히 할 수 있었다.

익숙하지 않은 부분을 연습하면 불편할 수 있다. 그러나 무엇이든 익숙해지기 마련이다. 의식적인 연습을 포기 하지만 않으면 된다. 페어 프로그래밍은 이러한 과정에서 내가 포기하지 않도록 도와주었다.

우테코 이전, 혼자서 아무런 목적도 없이 코딩했었던 내가 페어 프로그래밍을 통해 의식적인 연습의 중요성을 깨달았다. 이제는 스스로 아무 생각없이 머물러 있지 않고 의식적인 연습을 통해 컴포트 존을 벗어나는 법을 연마해 나가야 겠다.

[LV.3]팀 프로젝트가 나에게 남긴 것

어떠한 마음가짐으로 팀프로젝트에 임했는가

레벨 3이 시작되고 나서 "함께자라기"라는 책을 읽었다. 전문가일수록 사회적 기술과 사회적 인프라를 중요하게 생각한다는 것이다. 그 중 굉장히 인상깊은 부분이 있었다. 조직 내에서 새로운 기술을 도입하고자 노력하였는데, 조직원들이 수동적이고 보수적이어서 실패하였다는 청중이 있었다. 저자는 그 청중에게 "그 조직원들이 선생님을 좋아하나요?"라는 질문을 했다고 한다. 이 단락을 읽고 머리를 한 대 맞은 듯 멍해졌다. (왜 상처는 나도 받는가.. ) 많은 심리학 책에서 나를 싫어하는 사람은 어디에나 있고 신경쓰지 말라고 한다. 그러나 조직관계에서는 다른 사람들이 나를 좋아하게 하기 위해서 노력해야 하는 것도 현실이다.

팀 프로젝트를 시작 하기 전에는 내가 아직 부족하다는 생각이 많이 들었다. 그래서 "어떻게든 팀에 도움이 되는 사람이 되자"라는 마음가짐이 컸다. 그 중 가장 기본적인 것이 적극적으로 참여하는 것이라고 생각했다. 적극적이려면 지식이 있어야 했다. 그래서 Oauth2, S3등 새로운 기술을 도입하려고 했을 때 미리 한번 연습삼아 구현을 해보고 참여하였다. 또한 서비스 적으로도 의견을 활발하게 내려고 하였다. '이번에 낸 배너 문구를 각자 생각해 보는 건 어때' 라는 의견이 받아 들여져서 기분이 좋았다!

그러나 이번 스프린트에 '약관'작성을 팀끼리 같이 해야하는 일이 있었다. 처음에 나는 약관을 한번도 작성해 보지 않아서 부담스러웠었다. 막상 참여하고 보니 약관을 작성하면서 도메인에 대한 이해도 명확해지고 결제, 환불에 대한 플로우를 명확하게 잡을 수 있었다. 어디에서나 배울 것이 있었다.

집단이 팀은 아니다.

이번 3번째 데모데이를 하기 전날 거의 새벽 3시까지 팀프로젝트를 하였다. 줌으로 진행되어 목소리가 끊길 때도 많고, 밤이라 피곤하고, 게다가 열대야 까지 있었다. 짜증날 법한 상황이다. 그러나 이상하게도 화가 나지 않았다. 왜 그런걸까? 이 모든 건 우테코에서 받은 회식 쿠폰으로 부터 비롯된 것 같다. 아니면 팀문화로 정한 반말모드의 힘인가? 혹은 우리 팀 모두 즐기게된 게임인 브롤스타즈 덕분 일지도 모르겠다.

우리가 처음 딱 모였을 때는 집단이 었을지도 모른다. 그러나 같이 팀 문화를 고민하고, 서비스에 대해 토론한다. 소소하게는 데일리에서 오늘 먹을 점심을 공유하고 서로가 어떤 MBTI인지 말한다. 이렇게 점차 우리는 팀이 되어가고 있었다. 처음 시작때보다 단톡방이 훨씬 활발해졌다. 메시지로 대화하다가 잘 안풀리면 바로 줌 ㄱㄱ를 외친다. 이러한 것들만 봐도 팀이 되어가고 있는 증거인 것 같다.

[LV.4]내가 꿈꾸는 프로그래머로서의 삶

나는 왜 프로그래머로 일하고 싶을까.

내가 다녔던 학과에서는 2학년 때부터 수업이 영어로 진행된다. 안타깝게도 운영체제, 네트워크, 데이터베이스같이 이해가 중요한 CS 수업들도 영어로 진행되었다. 나는 영어를 잘 못했기 때문에 지식을 어떻게 영어로 잘 서술할 것인지 암기하는 식으로 공부했다. 그때는 따라가기 바빠 공부에 재미를 느끼지 못했다.

그러던 도중 PHP와 데이터베이스를 사용해서 웹페이지를 만드는 수업을 듣게 되었다. 동아리 모집을 하는 웹페이지를 만들었다. 프로젝트를 하는 동안은 시간이 정말 순식간에 사라졌다. 생각대로 잘 안 될 때는 스트레스도 받았지만, 해결되었을 때는 그런 스트레스도 다 날아가 버렸다. 그리고 그때 문득 하루 8시간 정도 일을 하는데 내 삶을 투자해야 한다면 프로그래밍을 직업으로 삼아야겠다는 생각이 들었다.

프로그래머로서 내 목표

프로그래머로서 내 궁극적 목표는 나만의 서비스를 운영해보는 것이다. 우아한테크코스 자기소개서에서는 워홀이나 이민을 한 분들을 위한 커뮤니티 사이트를 만들고 싶다고 적었다. 현재는 생각이 좀 바뀌고 아직 고민중이긴 하지만, 커뮤니티 비슷한 서비스를 먼저 만들어 볼 것 같다.

우아한테크코스 이전에 나는 안드로이드 개발을 했었다. 그리고 안드로이드 공부에서 배운 내용을 적용하기 위해 앱을 만들어서 출시해보았다. 내가 좋아하는 게임인 리그 오브 레전드 관련 앱이었다. 두 앱 모두 활성 기기가 800대 정도로 생각보다 많이 사용주셔서 놀랐다. 그리고 누군가 내가 만든 것을 사용해주는 데에서 오는 기쁨이 매우 컸다. 이 이후에 서버까지 연동해서 서비스를 만들어보고 싶은 욕심이 생겼다. 그러나 서버 구현은 둘째치고, 배포를 어떻게 해야 하는지 방법만 찾아보다가 그렇게 시간이 흘러갔었다.

그러던 도중 우아한테크코스에서 공부를 시작하였다. 우테코 3기 막바지에 온 지금 나는 서버 배포를 할 수 있게 되었다! 예전에 막막했던 것들을 여기서 차근차근 배울 수 있었다. 앞으로 늘 생각만 하고 있던 나만의 서비스 개발을 시작 할 일만 남은건가!

앞으로

우아한테크코스 이전에 나는 무언가를 만드는 데에만 집중했었다. 결과물의 질보다 결과물을 만드는 것에 더 관심이 있었던 것 같다. 우아한테크코스에서 보낸 10개월 동안 '잘' 만든 서비스란 무엇인가에 대해 많은 공부를 하였다. 그런 지식이 이번 팀 프로젝트에 드러나 있고, 앞으로 내가 개발자로서 성장하는 데 많은 도움이 될 것 같다.

그리고 앞으로 나는 회사에 들어가 개발자로서 일을 하게 될 텐데 여기서 내가 어떤 사람이 되고 싶은지 조금 적어보겠다. 팀 프로젝트를 하면서 느낀 것은 결과물에 내 생각, 노력이 많이 반영될수록 적극성이 높아진다는 것이었다. 회사의 서비스에 주인의식을 가지고 적극 의견을 내는 개발자가 되고 싶다. 영양가 있는 의견을 내기 위해서 공부를 꾸준히 해야지..

[테코톡]TCP/IP

I'mDawon — Tue, 9 Nov 2021 19:07:10 +0900

TCP/IP를 주제로 테코톡을 준비하였다.
네트워크를 공부할 때 각각의 계층을 따로따로 공부하는 것 보다 하나의 흐름을 통해 공부를 하면 이해가 쉬웠다.
테코톡에서도 과정을 중심으로 발표를 구성하였다.

TCP 발표자료.pdf

1.51MB

[Spring] Scheduling - CronTask

I'mDawon — Sat, 2 Oct 2021 16:04:24 +0900

@EnableScheduling

Scheduling 관련 Bean들을 등록해 준다.

@Configuration
@EnableScheduling
public class ScheduledConfig {
}

@Scheduled

메서드 위에 @Schedule 어노테이션을 붙혀 해당 로직을 스케줄링 할 수 있다.

@Scheduled(cron = "0 45 20 2 * *")
public String executeWithScheduled() {
    log.info("executeWithScheduled : 매달 2일 저녁 8시 45분");
    return "execute";
}

Cron표기법

초	분	시	일	월	요일	연도
0 ~ 59	0 ~ 59	0~23	1~31	1~12	0~6	생략가능

요일의 경우 0이 일요일이며 6이 토요일이다.
* 는 모든 조건을 뜻한다.
?는 설정값이 없을 때 쓰이며 일, 요일에서만 사용가능하다.
L - 마지막 - 일, 요일에서만 사용가능
W - 가장 가까운 평일을 찾는다. - 일 에서만 사용가능
- 10W
  - 10일이 평일이면 : 10일에 수행
  - 10일이 토요일이면 : 가장 가운 평일인 금요일 9일에 수행
  - 10일이 일요일일때 가장 가까운 평일인 월요일 11일에 수행
# - 몇주 째인지 찾는다. - 요일에서만 사용가능
- 3#2 : 2째주 수요일에 수행

테스트 하기

특정 시간에 스케줄을 걸고 동작하는지 테스트 하는 것은 너무 어렵다..ㅜ @Schedule를 걸면 ScheduleTaskHolder에 Task가 등록되는데, 이 Task에 설정된 값을 비교하는 식으로 테스트를 해야 할 것 같다.

@SpringBootTest
class TestServiceTest {
    @Autowired
    private ScheduledTaskHolder scheduledTaskHolder;

    @Test
    public void testExecuteWithScheduled() {
        String methodName = TestService.class.getName() + ".executeWithScheduled";
        String cron =  "0 45 20 2 * *";

        long count = scheduledTaskHolder.getScheduledTasks().stream()
                .filter(scheduledTask -> scheduledTask.getTask() instanceof CronTask)
                .map(scheduledTask -> (CronTask) scheduledTask.getTask())
                .filter(cronTask -> cronTask.getExpression().equals(cron) && cronTask.toString().equals(methodName))
                .count();


        Assertions.assertThat(count).isEqualTo(1L);
    }
}