최근 ‘요즘 볼만한 웹소설 없을까?’ 고민하던 차에, 「서포터가 다 해먹음」이라는 작품을 우연히 접하게 되었다. 무료 분량 50화와 쿠키 이벤트의 유혹을 못 이겨 읽기 시작했는데... 결론부터 말하자면, 아쉽다는 느낌이 더 컸다.
📘 작품 개요
제목: 서포터가 다 해먹음
장르: 게임 판타지
무료 분량: 약 50화
이벤트: 무료 + 쿠키 프로모션 진행 중
🧾 간단 평
✔️ 게임 판타지 장르로 가볍게 읽기 좋다
⚠️ 주인공 능력, 설정, 전개 모두 ‘평범’하다
❌ 개연성 부족 + 세계관 혼합이 오히려 마이너스
🧩 이야기의 특징
이 소설은 '게임 속 능력'이라는 익숙한 클리셰를 중심으로 이야기를 풀어간다. 주인공은 주변 인물들을 키우는 것을 재미로 게임을 즐기던 게이머인데 게임속으로 들어가게 되며 이야기가 시작된다. 주인공은 특별히 눈에 띄는 능력은 없고, 그만큼 이입은 쉬웠지만 반대로 주인공의 존재감도 흐릿하다.
세계관은 판타지, 무협, 현대 등의 요소가 뒤섞여 있는데, 그 시도가 설득력 있게 연결되지 못해 몰입에 방해가 되기도 한다. 각 세계관이 ‘짬뽕’된 느낌이 강하고, 서사가 부족해 개연성에 금이 간다.
🧍♂️ 주인공 캐릭터
주인공의 성격이나 행동도 특별한 개성이 없다. 전형적인 ‘무던한 타입’인데, 이마저도 이야기 속에서 어떤 매력 포인트로 작용하지는 않는다. 캐릭터 자체의 설득력이나 매력도가 약하다는 게 아쉽다.
🧠 이런 분들께는 추천
무료 화수 동안 가볍게 볼 웹소설을 찾는 분
복잡한 세계관보다는 클리셰 위주의 편안한 전개를 선호하는 분
‘주인공이 압도적으로 성장하는 맛’을 기대하지 않는 독자
📝 총평
나는 5화까지 읽고 더 이상 흥미가 생기지 않아서 그만 두었지만 가볍게 소모하는 콘텐츠로는 나쁘지 않다. 다만 독창적인 설정이나 짜임새 있는 전개를 기대한다면, 50화 체험 이후 결제는 신중하게 고민해볼 필요가 있을 것 같다.
Spring Boot에서 @Transactional을 사용할 때 한 가지 흔히 겪는 함정이 있습니다. 바로, 같은 클래스 내에서 메소드를 호출하면 트랜잭션이 적용되지 않는다는 점입니다.
이번 포스팅에서는 이 현상이 왜 발생하는지, 그리고 어떻게 해결할 수 있는지 실제 예제를 통해 자세히 알아보겠습니다.
🧪 상황 예제: 트랜잭션이 안 먹는다?
@Service
public class AService {
@Transactional
public void methodA() {
methodB(); // 내부 호출
}
public void methodB() {
// 예외 발생
throw new RuntimeException("예외 발생!");
}
}
이 코드를 보면, methodA()는 @Transactional이 붙어 있어 트랜잭션이 시작되고, 그 안에서 호출되는 methodB()에서 예외가 발생하니 당연히 롤백될 것 같죠?
하지만 실제 실행해보면... 👉 롤백되지 않고 커밋됩니다!
🤔 왜 이런 일이 벌어질까?
이유는 Spring이 @Transactional을 프록시 기반 AOP로 구현하고 있기 때문입니다.
Spring의 트랜잭션 처리 흐름은 이렇게 됩니다:
Spring이 @Transactional이 붙은 클래스를 감싸는 프록시 객체를 만듭니다.
외부에서 해당 메소드를 호출하면 프록시가 감지하여 트랜잭션을 시작합니다.
하지만, 같은 클래스 안에서 메소드를 호출하면 프록시를 거치지 않고 this.method() 형태로 직접 호출하게 됩니다.
따라서 트랜잭션을 적용할 기회를 놓쳐버립니다!
📌 즉, 프록시가 개입해야 트랜잭션이 적용되는데, 내부 호출은 프록시를 생략하므로 적용되지 않음!
💡 쉽게 말해서?
마치 건물 입구에 감시카메라(프록시)가 달려 있다고 생각해보세요.
외부에서 들어오면 감시카메라가 감지해서 트랜잭션을 시작함
하지만 내부에서 옆방으로 이동하면 감시카메라가 그걸 감지 못함 → 트랜잭션 안 걸림
🛠 해결 방법
✅ 방법 1. 메소드를 다른 클래스로 분리
@Service
public class BService {
@Transactional
public void methodB() {
throw new RuntimeException("예외 발생!");
}
}
@Service
public class AService {
private final BService bService;
public AService(BService bService) {
this.bService = bService;
}
public void methodA() {
bService.methodB(); // 외부 호출 → 프록시 적용됨!
}
}
✅ 방법 2. ApplicationContext를 통해 프록시 자신을 가져와 호출
@Service
public class AService {
private final ApplicationContext context;
public AService(ApplicationContext context) {
this.context = context;
}
public void methodA() {
AService proxy = context.getBean(AService.class);
proxy.methodB(); // 프록시를 통한 호출
}
@Transactional
public void methodB() {
throw new RuntimeException("예외 발생!");
}
}
✅ 결론
@Transactional은 프록시를 거쳐야만 동작한다! 내부에서 자기 메소드를 호출하면 프록시를 거치지 않으므로 트랜잭션이 동작하지 않는다.
같은 클래스 내 메소드 간 호출에는 트랜잭션이 적용되지 않는다는 점, 항상 기억하고 설계하시길 바랍니다.
동기란 직렬적으로 작업을 수행하는 방식을 요청을 보낸 후 응답을 받아야지만 다음 동작이 이루어집니다.
즉, 다른 요청을 처리하는 동안 나머지 작업들은 대기 상태가 됩니다.
(출처:https://poiemaweb.com/es6-promise)
동기 실행의 동작 방식 및 처리 순서
콜 스택(Call Stack):
JavaScript 엔진은 현재 실행중인 모든 동기 작업을 콜 스택에 쌓습니다.
콜 스택은 LIFO(Last In, First Out) 구조로 가장 마지막에 추가된 작업이 가장 먼저 처리됩니다.
한 작업이 실행되면, 그 작업이 완료될 때 까지 콜 스택의 맨 위에 위치하며, 완료되면 콜 스택에서 제거됩니다.
블로킹(Blocking):
동기 작업 중 하나가 긴 시간을 필요로 하는 작업일 경우, 그 작업이 완료될 때까지 콜 스택이 차단됩니다.
이로 인해 후속 작업들은 차단 작업이 완료되기 전까지 실행될 수 없으며, UI업데이트나 다른 이벤트 처리가 지연될 수 있습니다.
작업 처리 순서:
작업1이 콜 스택에 들어가서 실행됩니다.
작업1에서 데이터를 서버에서 가져오는 동기작업을 요구하느 경우, 해당 작업이 완료되기 전까지 다음 작업은 실행되지 않습니다.
작업1이 완료되고 콜 스택에서 제거되면, 작업2가 콜 스택에 들어가 실행됩니다.
예시:
console.log('Task 1 시작'); // 콜 스택에 들어감
// 서버에서 데이터를 동기적으로 가져옴 (블로킹)
const data = getDataFromServer(); // 작업이 완료될 때까지 콜 스택 차단
console.log('Task 1 완료'); // 작업 1 완료 후 콜 스택에서 제거
console.log('Task 2 시작'); // 작업 1이 완료된 후 콜 스택에 들어감
doSomethingWith(data); // 작업 2 실행
console.log('Task 2 완료'); // 작업 2 완료 후 콜 스택에서 제거
비동기(Async)란?
비동기란 병렬적으로 작업 수행하는 방식으로 요청을 보낸 후 응답의 수락 여부와 상관없이 다음 작업을 동작하느 방식입니다. 비동기 요청시 응답 후 처리할 콜백함수를 함께 알려주어 작업이 완료되어 응답을 받으면 콜백함수가 호출됩니다.
(출처:https://poiemaweb.com/es6-promise)
비동기 동작 방식
메인 스레드: JavaScript코드가 실행될 때, 동기적으로 실행되는 작업들은 콜 스택(call stack)에서 처리되고 작업이 완료되면, 콜 스택에서 제거됩니다
이벤트 루프:비동기 작업은 바로 콜 스택에 추가되지 않습니다. 대신 해당 작업은 Web API 또는 C++ API에 의해 처리되고, 완료되면 콜백 함수가 테스크 큐(task queue) 또는 마이크로테스크큐(microtask queue)에 추가됩니다.
마이크로태스크 큐(Microtask Queue): Promise의 then, catch, finally 콜백이나 MutationObserver 콜백 같은 더 높은 우선순위를 가진 작업들이 대기하는 공간입니다.
이벤트 루프의 역할: 이벤트 루프는 콜 스택이 비어 있고 실행할 준비가 되었을 때, 태스크 큐 또는 마이크로태스크 큐에서 대기 중인 작업을 콜 스택으로 이동시킵니다. 마이크로태스크 큐의 작업은 태스크 큐의 작업보다 우선 처리됩니다.
비동기 작업 처리 순서
현재 실행 중인 동기 작업이 콜 스택에서 완료되고 제거됩니다.
콜 스택이 비어 있으면, 이벤트 루프는 마이크로태스크 큐에서 작업을 콜 스택으로 이동시켜 실행합니다.
마이크로태스크 큐가 비었을 때, 이벤트 루프는 태스크 큐에서 다음 작업을 콜 스택으로 이동시켜 실행합니다.
이 과정을 통해 JavaScript는 단일 스레드임에도 불구하고 비동기 작업을 효과적으로 관리하고 실행할 수 있습니다. 이러한 메커니즘 덕분에 JavaScript 애플리케이션이 동시성을 가지고 동작할 수 있으며, 사용자 인터페이스를 블로킹하지 않고 부드럽게 작동할 수 있습니다.
이와같이 컬렉션들의 상위 인터페이스로 SequenceCollection, SequencedSet, SequencedMap을 상속받아 사용해서 공통된 기능을 제공합니다.
SequencedCollection
sequencedCollection은 처음과 마지막 요소에 대한 공통된 기능을 제공합니다.
reversed()는 기존 컬렉션에서 iterator()나 forEach(), stream()와 같은 기능에서 역순으로 원소들을 처리할 수 있게 됩니다.
interface SequencedCollection<E> extends Collection<E> {
//기존 컬렉션에서 역순으로 원소들을 처리할 수 있게 됩니다.
SequencedCollection<E> reversed();
//첫번째에 원소를 추가합니다.
void addFirst(E);
//마지막에 원소를 추가합니다.
void addLast(E);
//첫번째 원소를 가져옵니다.
E getFirst();
//마지막 원소를 가져옵니다.
E getLast();
//첫번째 원소를 제거합니다.
E removeFirst();
//마지막 원소를 제거합니다.
E removeLast();
}
SequencedSet
SequencedSet은 중복된 원소를 갖지 않는 sequencedCollection에 해당하는 set입니다.
자바는 이를 JVM에서 처리하도록 해서 키워드를 명시해주지 않아도 JVM이 알아서 논블로킹 처리를 해주기 때문에 편리하게 사용할 수 있습니다.
스프링은 3 버전부터 지원해주는 걸로 알고 있습니다. 자세한 내용은 추후에 포스팅해서 정리하도록 하겠습니다.
3.Record
레코드에 타입 패턴을 함께 적용하여 레코드의 값을 손쉽게 처리할 수 있도록 도와줍니다.
자바 16에서는 instace of 연산자에 타입 패턴을 적용하여 패턴을 매칭시키도록 개선해서 하위 블록에 직접적으로 타입 캐스팅 할 필요가 없어졌습니다.
// Prior to Java 16
if (obj instanceof String) {
String s = (String)obj;
... use s ...
}
// As of Java 16
if (obj instanceof String s) {
... use s ...
}
자바 21부터는 레코드 타입에 대해 보다 간편하게 사용할 수 있도록 변경됩니다.
//Java 16
record Point(int x, int y) {}
static void printSum(Object obj) {
if (obj instanceof Point p) {
int x = p.x();
int y = p.y();
System.out.println(x+y);
}
}
//Java 21
tatic void printSum(Object obj) {
if (obj instanceof Point(int x, int y)) {
System.out.println(x+y);
}
}
위와 같은 패턴 매칭이 개선되어서 기존의 instance of에 if-else문법을 사용하지 않고 스위치 문에서 보다 간편하게 타입여부를 검사할 수 있습니다.
// Prior to Java 21
static String formatter(Object obj) {
String formatted = "unknown";
if (obj instanceof Integer i) {
formatted = String.format("int %d", i);
} else if (obj instanceof Long l) {
formatted = String.format("long %d", l);
} else if (obj instanceof Double d) {
formatted = String.format("double %f", d);
} else if (obj instanceof String s) {
formatted = String.format("String %s", s);
}
return formatted;
}
// As of Java 21
static String formatterPatternSwitch(Object obj) {
return switch (obj) {
case Integer i -> String.format("int %d", i);
case Long l -> String.format("long %d", l);
case Double d -> String.format("double %f", d);
case String s -> String.format("String %s", s);
default -> obj.toString();
};
}
4.Null Check
기존에는 파라미터가 null이면 NPE(NullPointerException)을 던지기 때문에, null에 대한 검사를 외부에서 수행했어야 하지만 자바21부터는 null에 해당하는 케이스를 내부에서 검사할 수 있게 되었다
// Prior to Java 21
static void testFooBarOld(String s) {
if (s == null) {
System.out.println("Oops!");
return;
}
switch (s) {
case "Foo", "Bar" -> System.out.println("Great");
default -> System.out.println("Ok");
}
}
// As of Java 21
static void testFooBarNew(String s) {
switch (s) {
case null -> System.out.println("Oops");
case "Foo", "Bar" -> System.out.println("Great");
default -> System.out.println("Ok");
}
}
5.case 세분화
case문은 여러 값에 대한 검사를 필요로 하기 때문에 상당히 복잡한 구조로 만들 수 밖에 없었지만 자바 21에서는 보기 좋게 변경되었습니다.
// As of Java 21
static void testStringOld(String response) {
switch (response) {
case null -> { }
case String s -> {
if (s.equalsIgnoreCase("YES"))
System.out.println("You got it");
else if (s.equalsIgnoreCase("NO"))
System.out.println("Shame");
else
System.out.println("Sorry?");
}
}
}
// As of Java 21
static void testStringNew(String response) {
switch (response) {
case null -> { }
case String s
when s.equalsIgnoreCase("YES") -> {
System.out.println("You got it");
}
case String s
when s.equalsIgnoreCase("NO") -> {
System.out.println("Shame");
}
case String s -> {
System.out.println("Sorry?");
}
}
}
6. enum개선
가독성이 좋게 enum이 개선되었습니다.
// As of Java 21
sealed interface CardClassification permits Suit, Tarot {}
public enum Suit implements CardClassification { CLUBS, DIAMONDS, HEARTS, SPADES }
final class Tarot implements CardClassification {}
static void exhaustiveSwitchWithoutEnumSupport(CardClassification c) {
switch (c) {
case Suit s when s == Suit.CLUBS -> {
System.out.println("It's clubs");
}
case Suit s when s == Suit.DIAMONDS -> {
System.out.println("It's diamonds");
}
case Suit s when s == Suit.HEARTS -> {
System.out.println("It's hearts");
}
case Suit s -> {
System.out.println("It's spades");
}
case Tarot t -> {
System.out.println("It's a tarot");
}
}
}
// As of Java 21
static void exhaustiveSwitchWithBetterEnumSupport(CardClassification c) {
switch (c) {
case Suit.CLUBS -> {
System.out.println("It's clubs");
}
case Suit.DIAMONDS -> {
System.out.println("It's diamonds");
}
case Suit.HEARTS -> {
System.out.println("It's hearts");
}
case Suit.SPADES -> {
System.out.println("It's spades");
}
case Tarot t -> {
System.out.println("It's a tarot");
}
}
}
ZGC는 짧은 지연 시간과 높은 확정성을 위해 고안된 GC 알고리즘으로 Java 15부터 프로덕션 환경에서 사용할 수 있게 되었다. 약한 세대 가설(Weak Generational Hypothesis)을 따라 대부분의 객체는 금방 죽기 때문에, 금방 죽는 Young 영역과 오래 살아남는 Old 영역을 분리하여 관리하는 것이 좋다. 그래서 Java 21에서는 이러한 방식을 통해 ZGC의 기능을 확장하여 성능을 개선시키고자 하였다. ZGC와 관련된 자세한 내용은 추후의 별도 포스팅을 통해 살펴볼 예정이다.
이후 릴리스에서 Windows 32bit x86 port를 제거하기 위해, 이를 Deprecate 시켰다. 이제 Windows 32bit 용 빌드를 구성하려고 시도할 때 오류 메세지가 표시된다.
$ bash ./configure
...
checking compilation type... native
configure: error: The Windows 32-bit x86 port is deprecated and may be removed in a future release. \\
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1
$
자바는 agent를 통해 애플리케이션 코드를 동적으로 변경하도록 지원해왔고, 이를 통해 애플리케이션을 모니터링하고 관찰하는 많은 방법들이 탄생하게 되었다. 대표적으로 Pinpoint와 같은 도구는 자바 에이전트를 기반으로 바이트 코드를 조작하여 모니터링을 돕는 APM 도구이다.
이러한 자바 애플리케이션을 프로파일링하는 정상적인 방법들은 애플리케이션이 실행될 때 불러와지고, 애플리케이션이 실행되는 중간에 불러와지는 경우가 거의 없다. 따라서 자바 21에서는 실행 중인 JVM에 에이전트가 동적으로 로드될 때 경고를 발행시키도록 수정되었다. 물론 JVM 시작 시에 에이전트를 로드하는 것은 경고를 발생시키지 않는다.
Java21에는 공개 키 암호화를 사용하여 대칭 키를 보호하는 암호화 기술인 KEM(Key Encapsulation Mechanism) API가 도입되었다. 기존의 기술은 무작위로 생성된 대칭 키를 공개 키로 암호화하는 것이지만, 패딩이 필요하고 보안을 증명하기 어려울 수 있다. 대신 KEM은 공개 키의 속성을 사용하여 패딩이 필요 없는 관련 대칭 키를 도출한다.
KEM은 양자 공격을 방어하기 위한 핵심 도구가 될 것이다. 다른 보안 제공업체들은 이미 표준 KEM API에 대한 필요성을 표명했고, 자바 역시 이를 공식적으로 도입하기로 결정하였다.
package javax.crypto;
public class DecapsulateException extends GeneralSecurityException;
public final class KEM {
public static KEM getInstance(String alg)
throws NoSuchAlgorithmException;
public static KEM getInstance(String alg, Provider p)
throws NoSuchAlgorithmException;
public static KEM getInstance(String alg, String p)
throws NoSuchAlgorithmException, NoSuchProviderException;
public static final class Encapsulated {
public Encapsulated(SecretKey key, byte[] encapsulation, byte[] params);
public SecretKey key();
public byte[] encapsulation();
public byte[] params();
}
public static final class Encapsulator {
String providerName();
int secretSize(); // Size of the shared secret
int encapsulationSize(); // Size of the key encapsulation message
Encapsulated encapsulate();
Encapsulated encapsulate(int from, int to, String algorithm);
}
public Encapsulator newEncapsulator(PublicKey pk)
throws InvalidKeyException;
public Encapsulator newEncapsulator(PublicKey pk, SecureRandom sr)
throws InvalidKeyException;
public Encapsulator newEncapsulator(PublicKey pk, AlgorithmParameterSpec spec,
SecureRandom sr)
throws InvalidAlgorithmParameterException, InvalidKeyException;
public static final class Decapsulator {
String providerName();
int secretSize(); // Size of the shared secret
int encapsulationSize(); // Size of the key encapsulation message
SecretKey decapsulate(byte[] encapsulation) throws DecapsulateException;
SecretKey decapsulate(byte[] encapsulation, int from, int to,
String algorithm)
throws DecapsulateException;
}
public Decapsulator newDecapsulator(PrivateKey sk)
throws InvalidKeyException;
public Decapsulator newDecapsulator(PrivateKey sk, AlgorithmParameterSpec spec)
throws InvalidAlgorithmParameterException, InvalidKeyException;
}
Homebrew패키지 매니저를 이용해서 MariaDB Server를 macOS (이전 Mac OS X) 설치할 수 있습니다.
MariaDB Server는 미리 컴파일된 Homebrew "bottle" 패키지로 이용 가능하며, 소스 빌드가 필요 없어 시간을 절약해줄 수 있습니다.
Homebrew 설치 후에는 MariaDB Server 는 다음과 같이 설치 가능합니다.
- brew install mariadb
설치 후에는 다음으로 MariaDB Server를 시작합니다.:
- mysql.server start
MariaDB Server 자동 시작하려면 다음과 같이 Homebrew 서비스 기능을 이용할 수 있습니다. (이 서비스 기능은launchd의 launchctl 유틸리티를 이용합니다) :
- brew services start mariadb
MariaDB Server 시작후에는 사용자 계정으로 로그인하면 됩니다.:
- mysql
또는 루트 계정으로 로그인할 수도 있습니다.:
- sudo mysql -u root
MariaDB 업그레이드
우선 brew 를 업데이트 합니다
- brew update
그리고, 다음과 같이 MariaDB Server를 업데이트 합니다. :
- brew upgrade mariadb
소스로부터 MariaDB Server 빌드
"bottled" MariaDB Server 패키지는 Homebrew로도 가능하지만 소스로부터 MariaDB를 빌드할 수도 있습니다. 이는 bottle 패키지에 포함되지 않은 다른 버전의 특징적인 기능들을 사용하고자 할때 유용합니다.
bottle 패키지에 포함되지 않은 두 개의 컴퓨넌트들은 CONNECT와 OQGRAPH 엔진인데, 이는 비표준 의존성을 가지고 있기 떄문입니다. 이 엔진으로 MariaDB Server 를 빌드하려면 우선,boost와judy를 설치해야 합니다. 2016년 12월 현재, judy는 Homebrew "boneyard" 단계이나 macOS Sierra 상에서 동작합니다. 의존성을 가진 상태로 서버를 빌드 및 설치하려면 다음 단계를 따라주세요.:
또한 Homebrew를 이용하여 MariaDB Server의 프리-릴리즈 버전을 빌드 및 설치할 수 있습니다 (예를 들어, MariaDB Server 10.2, MariaDB Server 10.1의 가장 최신의 GA 버전). MariaDB Server 의 "개발" 버전을 빌드 및 설치하려면 다음과 같이 합니다.:
