코디잉

리터럴(Literal)이란 무엇이고, 타입은 어떻게 결정될까?

yong_ღ'ᴗ'ღ — Wed, 17 Dec 2025 12:09:29 +0900

자바 기본 문법을 공부하다 보면 ‘리터럴(Literal)’이라는 용어를 접하게 된다.

이번 글에서는 리터럴의 개념과 자바에서 리터럴의 타입이 어떻게 결정되는지를 정리해본다.

리터럴(Literal)이란?

리터럴(Literal)은 코드에 개발자가 직접 작성한 고정된 값 을 의미한다.

int a = 100;
boolean b = true;
String c = "Hello";

위 코드에서

100, true, "Hello"와 같이

코드에 직접 작성된 값들이 모두 리터럴이다.

리터럴 자체는 변하지 않는다.

“값은 바뀔 수 있는 거 아닌가?”

여기서 이런 의문이 든다.

'리터럴 자체는 변하지 않는다고?

그런데 값은 바뀌잖아?"

int a = 100;
a = 200;

위 코드를 보면

a의 값이 바뀌었으니

리터럴도 바뀐 것처럼 느껴질 수 있다.

하지만 실제로는 그렇지 않다.

int a = 100;
//  --  ----
// 변수 리터럴

이후

a = 200;

이 실행되면,

◽ 리터럴 100이 바뀌는 것이 아니라

◽ 새로운 리터럴 200이 변수 a에 할당되는 것이다.

변수의 값은 변할 수 있지만, 리터럴 자체는 변하지 않는다.

정수 / 실수 리터럴의 기본 타입

자바에서는 리터럴의 종류에 따라 기본으로 선택되는 타입이 정해져 있다.

✔ 정수 리터럴

◽ 기본 타입: int

◽ int 범위 내에서는 접미사 없이 사용 가능

int a = 100;

◽ int 범위를 초과하는 값은 l 또는 L을 붙여 long 리터럴로 명시해야 한다.

long b = 3000000000L;

✔ 실수 리터럴

◽ 기본 타입: double

◽ float 을 사용하려면 f 또는 F를 붙여야 한다.

double d = 3.14;
float f = 3.14f;

✔ 기타 리터럴

◽ true, false → boolean

◽ 'a' → char

◽ "Hello" → String

long a = 111; 과 long a = 111L 의 차이

아래 두 코드는 모두 정상적으로 컴파일된다.

long a = 111;
long b = 111L;

그렇다면 이 둘의 차이는 무엇일까?

long a = 111; 은 어떻게 처리될까?

long a = 111;

(1) 111은 정수 리터럴이므로 기본적으로 int 타입으로 해석된다.

(2) int → long 은 자동형변환이 가능하다.

(3) 따라서 컴파일러는 이를 문제없이 허용한다.

이 과정은 컴파일 타임에 타입을 해석하는 단계이며,

리터럴 111을 보고 int 메모리를 잡았다가

long type 변수인 a를 본 후, 다시 long으로 바꾸는 과정은 없다.

실행 시에는 a가 long type 메모리(8byte)를 사용한다.

long b = 111L; 은 무엇이 다를까?

long b = 111L;

◽ 111을 처음부터 long 리터럴로 명시

◽ 컴파일러가 int로 해석하지 않는다.

실행 결과나 성능 차이는 없지만, 타입 의도가 더 명확해진다.

⚠️ 큰 정수 리터럴과 L 접미사

아래 코드는 컴파일 에러가 발생한다.

long a = 3000000000;	// (30억) 컴파일 에러

이유는 간단하다.

◽ 정수 리터럴은 기본적으로 int

◽ 3000000000(30억)은 int 범위를 초과

◽ 컴파일러는 자동으로 long으로 바꿔주지 않는다.

따라서 반드시 다음과 같이 명시해야 한다.

long a = 3000000000L;

✅ 그래서 어떤 방식이 더 나을까?

long a = 111;
long b = 111L;

두 코드는

◽ 실행결과 동일

◽ 성능 동일

◽ 메모리 사용 동일

기술적으로는 동일한 코드이다.

다만 실무에서는

◽ 타입 의도가 명확하고

◽ 값 변경 시 실수를 방지할 수 있기 때문에

L 접미사를 붙이는 방식을 더 선호한다.

정리

◽ 리터럴은 코드에 개발자가 직접 작성한 고정된 값이다.

◽ 변수의 값은 변할 수 있지만, 리터럴 자체는 변하지 않는다.

◽ 자바에서는 리터럴의 종류에 따라 기본 타입이 정해져 있다.

◽ long a = 111;과 long a = 111L;의 실행 결과는 동일하다.

◽ 의도를 명확히 하기 위해 접미사 L을 붙이는 것이 바람직하다.

이 글은 인프런 김영한님의 자바 강의를 듣고,
리터럴과 타입 결정 방식을 이해하기 위해 정리한 내용입니다.

초기화하지 않은 지역 변수를 사용할 수 없는 이유

yong_ღ'ᴗ'ღ — Tue, 16 Dec 2025 09:39:26 +0900

자바에서 지역 변수는 반드시 초기화한 후에 사용해야 한다.

이 규칙은 자바를 처음 배울 때부터 자주 들었지만,

왜 이렇게까지 엄격하게 제한하는지 깊이 생각해보지 않고 넘어갔다.

초기화하지 않은 변수를 사용하면 어떻게 되고, 왜 자바에서는 이를 허용하지 않을까?

❗ 초기화하지 않은 지역변수 사용

자바에서는 초기화하지 않은 지역변수를 읽거나 사용하려고 하면 컴파일 에러가 발생한다.

int local;
System.out.println(local);	// 컴파일 에러

java: variable local might not have been initialized

왜 이런 에러가 발생하는 걸까?

자바 컴파일러는

지역 변수가 사용되기 전에 반드시 초기화되었다고 확실하게 판단할 수 없는 경우,

코드 실행 자체를 허용하지 않는다.

참고: Definite Assignment(확정 할당)

자바 컴파일러는 지역 변수가 사용되기 전에 반드시 초기화되었는지를 컴파일 타임에 정적으로 검사한다. 이 규칙을 Definite Assignment(확정 할당)라고 한다.

"확실하게 판단할 수 없는 경우"란??

int local;

if (condition) {
    local = 10;
}

System.out.println(local);	// 컴파일 에러

위의 코드를 보면,

"condition이 true면 초기화되는데 왜 컴파일 에러 발생하지?"

라고 생각할 수 있다.

하지만 컴파일러 입장에서는

◽ condition이 항상 true라는 보장이 없고,

◽ 따라서 local이 항상 초기화된다고 확신할 수 없다.

그래서 자바 컴파일러는 실행 자체를 허용하지 않고 컴파일 에러를 발생시킨다.

에러 메시지를 다시 보자.

java: variable local might not have been initialized

이것이 바로 에러 메시지에 나오는 "might not have been initialized"

"초기화하지 않았을 수도 있다" 는 의미다.

️ 왜 이렇게 엄격할까?

자바는 실행 중 발생할 수 있는 오류를 가능한 한 컴파일 단계에서 차단한다.

초기화되지 않은 변수를 허용하면,

◽ 어떤 값이 들어있을지 예측할 수 없고

◽ 실행 결과가 환경에 따라 달라질 수 있으며

◽ 디버깅이 매우 어려워진다.

자바는 이런 문제를 실행 시점이 아니라 컴파일 시점에 차단한다.

C/C++ 계열 언어에서는 초기화되지 않은 지역 변수를 사용할 수 있지만, 그 값은 예측할 수 없다.

반면 자바에서는 그러한 상황이 발생하기 전에 컴파일 단계에서 코드 실행을 아예 차단한다.

참고: 지역 변수 vs 멤버 변수

위 규칙은 지역 변수에만 해당한다.

◽ 지역 변수 → 반드시 초기화 필요

◽ 멤버 변수 / 클래스 변수 → 자동으로 기본값으로 초기화

✍️ 정리

◽ 자바에서는 초기화하지 않은 지역 변수를 사용할 수 없다.

◽ 이는 실행 중 오류를 방지하기 위한 컴파일 타임 안전 장치다.

◽ 자바 컴파일러는 "이 변수가 확실히 초기화되었는가?"를 기준으로 코드를 판단한다.

◽ 확실하지 않다면, 컴파일 단계에서 실행 자체를 막는다.

이 글은 인프런 김영한님의 자바 강의를 듣고,
지역 변수 초기화 규칙을 다시 이해하며 정리한 내용입니다.

자바 프로그램은 어떻게 컴파일되고 실행될까?

yong_ღ'ᴗ'ღ — Mon, 15 Dec 2025 22:24:41 +0900

자바 프로그램의 컴파일과 실행 과정

자바 프로그램은 컴파일 단계와 실행 단계를 거쳐서 실행된다.

그동안 이 흐름을 막연하게 알고 있었는데, 다시 공부하고 정리하면서 IDE가 가려주던 실행 과정을 더 명확히 이해할 수 있었다.

전체 흐름

자바 소스 코드(Hello.java)는 javac 컴파일러를 통해 바이트코드 파일(Hello.class)로 컴파일된다.

이후 java 명령을 실행하면 운영체제가 JVM 프로세스를 실행하고, JVM은 Hello.class 파일을 로드하여 내부에서 실행한다.

즉, 자바 프로그램을 실행한다는 것은
.class 파일을 직접 실행하는 것이 아니라
JVM을 실행하고 그 안에서 class 파일을 실행하는 것을 의미한다.

️ 컴파일 단계 (javac)

자바 소스 코드는 javac 컴파일러를 통해 컴파일된다.

javac 파일명.java
# 예: javac Hello.java

이 과정에서 다음과 같은 작업이 수행된다.

◽ .java 파일이 .class 파일로 변환된다.

◽ 자바 소스 코드는 JVM이 이해할 수 있는 바이트코드로 변환된다.

◽ 문법 오류, 타입 오류 등을 포함한 컴파일 타임 오류를 미리 검출할 수 있다.

◽ 주석과 같은 소스 코드 수준의 메타 정보는 제거된다.

컴파일 단계의 목적은

실행 전에 최대한 많은 오류를 잡고, JVM이 실행할 준비를 마치는 것이다.

▶️ 실행 단계 (java)

컴파일된 .class 파일은 java 명령을 통해 실행한다.

java 클래스명
# 예: java Hello

이 명령을 실행하면 다음 순서로 동작한다.

(1) 운영체제가 JVM 프로세스를 실행한다.

(2) JVM은 Hello.class 파일을 로드한다.

(3) 로드된 바이트코드를 실행한다.

⚙️ JVM의 실행 방식 (인터프리터 & JIT)

JVM은 바이트코드를 실행할 때

인터프리터 방식과 JIT(Just-In-Time) 컴파일 방식을 함께 사용한다.

(1) 처음 실행될 때

◽ 인터프리터가 바이트코드를 한 줄씩 해석해서 실행한다.

◽ 빠르게 실행을 시작할 수 있지만 성능은 상대적으로 낮다.

(2) 실행 중 (Hot Spot 판단)

◽ JVM이 자주 실행되는 코드를 감지한다.

◽ 해당 코드를 JIT 컴파일을 통해 기계어로 변환한다.

(3) 이후 실행

◽ 해석 없이 컴파일된 기계어로 바로 실행된다.

◽ 실행 성능이 향상된다.

즉, 하나의 코드는 실행 생애 동안

해석 → JIT 컴파일 → JIT 코드 실행

이 흐름을 모두 거칠 수 있다.

✨ IDE가 해주는 일

IntelliJ와 같은 IDE에서 실행 버튼(Run)을 누르면, 컴파일과 실행 과정을 모두 자동으로 처리해준다.

◽ 내부적으로 javac, java 명령을 실행

◽ 컴파일된 .class 파일은 out 디렉토리에 생성

.class 파일은 바이트코드로 구성되어 사람이 직접 읽기 어렵지만,

IDE는 이를 디컴파일하여 원본 자바 소스 코드와 유사한 형태로 보여준다.

디컴파일된 코드는 실제 소스 코드가 아니며, 주석이나 일부 정보는 포함되지 않는다.

이 글은 인프런 김영한님의 자바 강의를 듣고,
자바 프로그램의 컴파일과 실행 과정을 다시 이해하며 정리한 내용입니다.

[항해 Lite 백엔드 1기] 회사 병행하며 10주 항해 솔직 후기

yong_ღ'ᴗ'ღ — Sun, 10 Aug 2025 23:52:15 +0900

‍ 나는,

올해로 백엔드 개발 경력 1년 차를 넘긴 개발자로, 그동안 풀스택 개발을 경험했지만, 현재는 운영 업무를 맡고 있다.
마음 한켠에는 "기본기가 부족하다"는 생각이 늘 있었고, 여러 곳에서 많이 볼 수 있는 TDD, Redis, Kafka, 대용량 트래픽 처리, 아키텍처 설계 같은 주제들을 직접 경험해 보고 싶었다.

시작 전 고민 & 항해 Lite 선택 이유

퇴근 후 집에 오면 "공부해야지"라는 생각은 가득했지만, 막상 실행으로 옮기는 건 쉽지 않았다. 공부할 건 정말정말 많고, 어떤 것부터 시작해야 할지도 막막했다.

예전부터 항해 플러스를 해볼까 고민했지만, 직장과 병행하기엔 빡세 보이는 커리큘럼과 금액 때문에 망설여졌다..ㅎㅎ

그러던 중 퇴근 후 + 주말에 유연하게 참여할 수 있는 항해 Lite가 나왔고, 바로 참여를 결심했다.

무엇보다 10주간의 커리큘럼 구성이 마음에 들었고,
시니어 멘토의 1:1 코드 리뷰 기회

그리고 주차별 과제와 피드백을 통해 성장할 수 있는 구조가 매력적으로 다가왔다.

‘자율적이지만 반드시 제출해야 리뷰를 받을 수 있는’ 시스템 덕분에, 강제성이 적더라도 꾸준히 학습을 이어갈 수 있을 거란 확신이 들었다.

10주간의 항해

1주마다 학습자료/강의 → 공부 → 과제 제출 → 코드리뷰의 흐름을 반복했다.
10주간 열심히 참여해서 모든 과제를 제출하여 ALL PASS 를 받았다 (❁´◡`❁)

Lite 코스는 ‘유연형 1인 부트캠프’이기 때문에, 완벽하지 않더라도 과제를 꼭 제출해 코드 리뷰를 받는 의지가 중요한 것 같다.
자율성이 장점이지만, 의지가 약하면 흐지부지될 수 있다는 점...ㅎㅎ!!! 이건 다른 것도 마찬가지겠지만, 과제를 점점 놓치게 되면 할게 산더미처럼 쌓여 나중에는...많이 힘들어질 수 있다...

(물론 한 번 놓치더라도 다음주에 같이 제출하면, 코드리뷰를 함께 받을 수 있다는 점도 좋았다)

주 단위 진행은 학습과 구현을 병행하기에 딱 적당하고 좋았다.

더 짧으면 너무 버겁고,
더 길면 루즈해질 수 있을 것 같았다.

항해 Lite 코스는 ‘1인 부트캠프’ 방식이라 팀으로 협업하며 진행되는 과정은 없다.

팀 프로젝트나 협업 경험을 원한다면 Lite 보다는 항해 플러스 과정이 더 적절할 듯하다.

물론 디스코드와 같은 소통 채널이 있어서, 동기들과 질의응답을 하거나 정보를 공유하는 교류는 가능하다.

항해 Lite 전/후의 변화

가장 큰 변화는 "이름만 알던 기술들을 직접 구현해본 경험"
교육 전에는 ‘이게 뭔지’ 정도만 알던 기술들이, 교육 후에는 ‘왜 쓰고, 어떻게 구현하는지’로 바뀌었다.

이번 과정을 통해 백엔드 개발자 역량을 한 단계 끌어올릴 수 있었다.

특히 TDD, 아키텍처 설계, 동시성 처리, Redis, Kafka를 활용하며 직접 고민하고 설계해볼 수 있어서 좋았다.

단순히 강의만 듣는 것이 아니라, 실제 서비스 개발 환경에서 발생할 수 있는 문제들을 스스로 고민해보고 해결하며, 익힐 수 있었다.

자가진단 전/후 비교

성장 포인트

혼자였다면 미뤘을 학습을, 일정과 목표를 정해 10주간 항해 성공
다른 수강생들의 과제 및 코드리뷰도 전부 확인 가능 → 다양한 관점에서 학습 가능
Git 잔디를 오랜만에 빽빽하게 채움

수강 팁

과제는 완벽하지 않아도 꼭 제출하기 → 코드리뷰가 진짜 큰 성장 포인트
다른 수강생 코드 리뷰를 꼭 참고하기 → 다양한 접근 방식을 배울 수 있음
질문 많이 하기 → 질문을 많이 못해서 아쉬웠지만, 다른 수강생분들이 한 질문과 답변을 보며 배운 점이 많았음

수강 고민중이라면

커리어에 대한 고민과 학습 의지는 있지만, 혼자 진행하기 어렵다면,
TDD, Redis, Kafka, 대용량 트래픽 처리, 아키텍처 설계를 프로젝트로 경험해보고 싶다면,
내가 작성한 코드를 누군가에게 피드백 받고 싶다면,
퇴근 후 “해야지”만 했다면,

⭐ 10주간 열심히 학습하면 후회 없는 선택이 될 거라 생각합니다. 추천추천⭐

수료생 추천 할인 혜택

아래 코드 입력 시 등록금 5만원 할인받으실 수 있습니다
할인 코드: GoZNrB

9주차 - WIL (Weekly I Learned)

yong_ღ'ᴗ'ღ — Sun, 20 Jul 2025 17:47:27 +0900

9주차 과제

Kafka 도입: 결제 성공 후 처리 로직을 Kafka 메시지 기반으로 비동기 처리하도록 개선

‍♀️ 고민했던 부분

기존 ApplicationEvent → Kafka 기반 구조로 리팩토링

◾ 기존에는 @TransactionalEventListener(phase = AFTER_COMMIT) 기반으로 비동기 이벤트를 처리했음

◾ Kafka를 도입하여, 이벤트들을 Kafka 메시지로 발행하고 별도 Consumer에서 처리하도록 구조 변경

◽ 발행: ReservationService.pay() 성공 시 PaymentSuccessMessage Kafka로 전송
◽ 소비: PaymentSuccessKafkaConsumer.consume()에서 메시지 수신 후 랭킹/토큰/내역 순차 처리

◾ 이벤트 리스너 → 메시지 기반으로 변경하면서 생기는 차이점들을 고려해야 했음

✅ Keep (잘한 점 / 유지할 점)

Kafka 기반 구조로 리팩토링하며 시스템의 확장성과 비동기 분산 처리 구조 경험

이번 주 알게 된 것들

기존 ApplicationEvent → Kafka 기반 구조로 리팩토링 하는 방법
Kafka Producer/Consumer 기본 설정 및 메시지 직렬화 방식 (JsonSerializer, trusted.packages 설정 등)

[혼공컴운]_3주차_Chapter 06 ~ 08

yong_ღ'ᴗ'ღ — Sun, 20 Jul 2025 12:26:36 +0900

책: 『혼자 공부하는 컴퓨터 구조+운영체제』
️ 기간: 3주차
범위: Chapter 06 ~ Chapter 08

Chapter 06 | 메모리와 캐시 메모리

6-1. RAM의 특징과 종류

✅ RAM (Random Access Memory)

실행할 프로그램의 명령어와 데이터가 저장되는 메모리
휘발성: 전원이 꺼지면 데이터가 사라짐
- 비휘발성 메모리 예시: 하드디스크, SSD, CD-ROM, USB 등
RAM 용량이 클수록 더 많은 프로그램을 동시에 빠르게 실행하는데 유리

RAM의 종류

종류	설명	특징
DRAM (Dynamic RAM)	일반적인 RAM	- 주기적으로 새로 저장 필요 - 소비전력이 비교적 낮고, 저렴 - 집적도 높아서 대용량으로 설계하기 용이
SRAM (Static RAM)	캐시 메모리에 사용	- 시간이 지나도 데이터 사라지지 않음 - DRAM보다 빠르지만, 비싸고 집적도 낮음
SDRAM	클럭 신호와 동기화된 DRAM (Synchronous Dynamic RAM)	표준 DRAM보다 성능 개선
DDR SDRAM	Double Data Rate SDRAM	대역폭 2배 넓은 SDRAM, 현재 가장 흔히 사용

6-2. 메모리의 주소 공간

물리 주소 (Physical Address): 메모리 하드웨어 상의 주소
논리 주소 (Logical Address): CPU와 실행 중인 프로그램이 인식하는 주소
논리 주소 → 물리 주소 변환: MMU (Memory Management Unit) 에서 수행

6-3. 캐시 메모리

자주 사용하는 데이터는 메모리보다 더 빠른 캐시 메모리에 보관하여 CPU 성능을 높임
참조 지역성의 원리에 따라 메모리로부터 가져올 데이터를 결정한다.

시간 지역성	CPU는 최근에 접근했던 메모리 공간에 다시 접근하려는 경향이 있다.
공간 지역성	CPU는 접근한 메모리 공간 근처를 접근하려는 경향이 있다.

Chapter 07 | 보조기억장치

✅ 대표적인 보조기억장치

하드디스크 (HDD; Hard Disk Drive)
플래시 메모리 (예: SSD)

RAID (Redundant Array of Independent Disks)

데이터의 안정성이나 높은 성능을 위해 여러 개의 물리적 보조기억장치를 마치 하나의 논리적 보조기억장치처럼 사용하는 기술
주로 HDD나 SSD를 이용하여 구성

Chapter 08 | 입출력장치

장치 컨트롤러

CPU와 입출력장치 간 통신 중개자 역할
오류 검출, 데이터 버퍼링 등 담당 (→ CPU와 I/O 장치 간 속도 차이 해결)

장치 드라이버

장치 컨트롤러가 컴퓨터 내부와 정보를 주고받도록 도와주는 프로그램

[문제 풀이]

연습문제 p.185 - 3번

주로 캐시 메모리로 활용	SRAM
주로 주기억장치로 활용	DRAM
대용량화에 유리	DRAM
집적도가 상대적으로 낮음	SRAM

연습문제 p.205 - 1번

8주차 - WIL (Weekly I Learned)

yong_ღ'ᴗ'ღ — Sun, 13 Jul 2025 20:35:49 +0900

8주차 과제

1. Application Event: 이벤트를 활용하여 트랜잭션과 관심사를 분리하기

2. Asynchronous Design: 대기열 기능에 대해 Redis 기반의 설계를 진행

3. feedback - RedisReservationRankingManager 상수값 외부 설정으로 빼기

4. feedback - redis 분산락 TTL 충분히 길게 줘서 중복실행 확률 낮추기

‍♀️ 고민했던 부분

① Event 활용하여 트랜잭션과 관심사 분리

◾ 기존에는 모든 로직이 ReservationService.pay() 내에 포함되어 있어, 핵심로직과 부가로직이 혼재된 구조였다.

◽ 핵심 로직: 대기열 토큰 검증, 포인트 사용, 좌석 상태 변경
◽ 부가 로직: 예매율 랭킹 갱신, 대기열 토큰 완료 처리, 결제 내역 저장

◾ 위 부가로직은 예외가 발생하더라도 핵심 로직에는 영향을 주지 않아야 했고, 성능과 유지보수 측면에서도 이벤트 기반 처리가 적절하다고 판단했다.

◾ 특히 결제 실패 이력 저장의 경우, 핵심 트랜잭션이 롤백되더라도 반드시 저장되어야 하므로 @Transactional(propagation = REQUIRES_NEW) 로 별도 트랜잭션으로 분리해 처리함.

② Redis로 대기열 기능 구현

◾ Redis ZSET 사용 결정. 무제한 입장을 막기 위해 allowedLimit(ex. 1000명) 설정

◾ 스케줄러 처리 방식

◽ ALLOWED 상태에서 TTL이 지난 토큰은 TIMEOUT으로 변경

◽ WAITING 상태 중 상위 토큰들을 ALLOWED로 전환 (현재 허용 인원 기준)

➡️ 한 번에 너무 많은 대기열을 조회하지 않기 위해 Redis에서 limit × 2 정도만 추출 후 상태 체크

✅ Keep (잘한 점 / 유지할 점)

- @TransactionalEventListener 를 활용해 AFTER_COMMIT 시점에만 부가로직 수행

- 이벤트 리스너를 비동기 처리(@Async)하여 주 쓰레드의 성능 저하 방지

- 예외 발생 시 REQUIRES_NEW 로 실패 이력 저장 → 핵심 트랜잭션의 영향을 받지 않도록 설계

- 예매율 랭킹 / 토큰 상태 변경 / 결제 성공 내역 저장을 각각 이벤트 리스너로 분리하여 단일 책임 원칙 지킴

- 대기열 진입 로직을 별도의 Facade 서비스로 구성하여 토큰 발급 → 대기열 진입 흐름을 하나의 API로 처리

- 토큰 상태값은 RDB에서 관리하고, 큐 순번은 Redis에서 분리 관리하여 상태/순번 책임 분리

❗️Problem (문제점) & Try (해결을 위한 시도)

- JPA dirty checking 기반의 토큰 상태 변경(엔티티 변경만)도 이벤트로 분리하려 했지만, 트랜잭션 범위를 벗어나면 dirty checking이 적용되지 않아 다시 save 호출이 필요함 → 이를 고려해 save 호출을 명시적으로 추가함

- 처음에는 ReservationService가 QueueService를 호출하는 구조로 구현했으나 서비스 간 의존성 문제 발생 가능성 있어서 → Facade 패턴 도입

이번 주 알게 된 것들

- @TransactionalEventListener 의 phase 종류 (BEFORE_COMMIT, AFTER_COMMIT, AFTER_ROLLBACK) 와 각각의 동작 시점

- 서비스 간 호출이 필요할 경우 Facade 계층 사용

[혼공컴운]_2주차_Chapter 05

yong_ღ'ᴗ'ღ — Sun, 13 Jul 2025 16:30:11 +0900

책: 『혼자 공부하는 컴퓨터 구조+운영체제』
️ 기간: 2주차
범위: Chapter 05

Chapter 04 | CPU 성능 향상 기법

✅ CPU 성능을 높이는 방법

클럭 속도 ⬆️
코어 수 ⬆️
스레드 수 ⬆️

클럭(Clock)

CPU 내부에서 작동 타이밍을 맞춰주는 전기 신호
클럭 속도 ↑ → 명령어 사이클 반복 속도 ↑ → 연산 속도 ↑
하지만, 발열 등의 문제로 인해 무작정 높이기엔 한계가 존재

코어(Core)

명령어를 실행하는 부품
하나의 CPU 안에 여러 개의 코어가 탑재된 경우 → 멀티코어 CPU
코어 수가 많다고 무조건 성능이 오르지는 않음!
- 각 코어에 연산 작업이 잘 분배되는게 중요하다.

스레드(Thread)

하드웨어 스레드
- 하나의 코어가 동시에 처리하는 명령어 단위
- 하나의 코어로 여러 명령어를 동시에 실행 가능한 구조 → 멀티스레드 CPU
소프트웨어 스레드
- 하나의 프로그램 내부에서 독립적으로 실행되는 단위
- 기능별로 스레드를 나누면 동시에 실행 가능
  → 1코어 1스레드 CPU도 멀티스레드 프로그램 실행 가능

⭐ 즉,

하드웨어 스레드 = 코어가 처리하는 단위
소프트웨어 스레드 = 프로그램이 처리하는 단위

[문제 풀이]

p.125 확인문제 2번 : 코어

[혼공컴운]_2주차_Chapter 04

yong_ღ'ᴗ'ღ — Sun, 13 Jul 2025 00:50:44 +0900

책: 『혼자 공부하는 컴퓨터 구조+운영체제』
️ 기간: 2주차
범위: Chapter 04

Chapter 04 | CPU의 작동 원리

4-1) ALU와 제어장치

CPU의 주요 구성 요소

ALU (산술논리연산장치): 계산 담당
레지스터: CPU 내부의 임시 저장 공간
제어장치: 명령어를 해석하고 제어 신호를 보냄

ALU (연산 장치)

레지스터로부터 피연산자, 제어장치로부터 제어신호를 전달받음
산술/논리 연산 수행 후 결과 + 플래그를 출력
결과는 레지스터에, 플래그는 플래그 레지스터에 저장
플래그 종류: 부호 플래그, 제로 플래그, 캐리 플래그, 오버플로우 플래그, 인터럽트 플래그 등

제어장치

명령어 해석 및 제어 신호 생성
컴퓨터 부품들을 관리하고 작동시키기 위한 일종의 전기적 신호
CPU 제조사마다 차이 있음
제어장치가 받는 정보: 클럭(clock) 신호, 명령어 레지스터의 명령어, 플래그 값, 제어 버스로 전달된 제어 신호
CPU 내부/외부로 제어신호를 내보냄

4-2) 레지스터

레지스터명	설명
프로그램 카운터 (PC, Program Counter)	- 다음 명령어의 메모리 주소 저장 - 각 명령어 실행 후 자동으로 다음 명령어의 주소로 업데이트
명령어 레지스터 (IR, Instruction Register)	- 현재 실행할 명령어 코드를 저장 - 명령어 레지스터에 현재 명령어 코드가 저장되면 프로그램 카운터는 다음 명령어가 저장된 메모리 주소를 가리킨다.
메모리 주소 레지스터 (MAR, Memory Address Register)	- CPU가 읽거나 써야 하는 데이터의 메모리 주소를 저장 - CPU가 데이터에 접근해야 할 때, 먼저 메모리 주소를 MAR에 저장
메모리 데이터 레지스터(MDR, Memory Data Register) 메모리 버퍼 레지스터(MBR, Memory Buffer Register)	- 메모리에서 읽어온 데이터나 메모리에 저장할 데이터를 임시로 저장 - CPU가 메모리에서 데이터를 읽어올 때, 읽어온 데이터는 먼저 MDR에 저장 - CPU가 메모리에 데이터를 저장해야 할 때, 저장할 데이터는 먼저 MDR에 저장 - CPU와 메모리 사이에서 데이터를 주고받는 임시 저장 공간 역할을 하여 메모리 접근 속도를 향상시키는 데 기여 - MAR이 지정한 주소에 있는 데이터를 저장
플래그 레지스터 (Flag Register)	- 연산결과나 CPU 상태에 대한 부가적인 정보를 저장
범용 레지스터 (GPR, General Purpose Register)	- 데이터 값과 메모리 주소를 모두 저장할 수 있다. - 프로세서가 계산 중에 즉시 사용할 수 있도록 데이터와 메모리 주소를 저장하는 데 사용
스택 포인터 (Stack Pointer)	- 스택 주소 지정 방식에 사용 - 스택의 꼭대기, 즉 스택에 어디까지 데이터가 채워져 있는지를 가리키는 레지스터
베이스 레지스터 (Base Register)	- 변위 주소 지정 방식(Displacement Addressing Mode)에 사용 - 베이스 레지스터의 내용에 변위 값을 더하여 피연산자의 유효 주소를 계산

4-3) 명령어 사이클과 인터럽트

명령어 사이클

일반적으로 인출, 실행, 간접, 인터럽트 사이클을 반복하며 실행된다.

인터럽트

CPU 작업을 방해하는 신호
동기 인터럽트: 우리가 흔히 예외(exception)라고 부르는 것
- ex) CPU가 실행하는 프로그래밍상의 오류
비동기 인터럽트: 주로 입출력장치에 의해 발생하는 인터럽트

[문제 풀이]

p.125 확인문제 2번

플래그 레지스터: 연산 결과 혹은 CPU 상태에 대한 부가 정보를 저장하는 레지스터
프로그램 카운터: 메모리에서 가져올 명령어의 주소를 저장하는 레지스터
범용 레지스터: 데이터와 주소를 모두 저장할 수 있는 레지스터
명령어 레지스터: 해석할 명령어를 저장하는 레지스터

[혼공컴운]_1주차_Chapter 01~03

yong_ღ'ᴗ'ღ — Sun, 6 Jul 2025 22:43:42 +0900

책: 『혼자 공부하는 컴퓨터 구조+운영체제』
️ 기간: 1주차
범위: Chapter 01 ~ Chapter 03

Chapter 01 | 컴퓨터 구조 시작하기

✅ 컴퓨터란?

명령어를 처리하는 기계
컴퓨터 구조는 크게 2가지로 구성됨
1. 컴퓨터가 이해하는 정보: 데이터, 명령어
2. 컴퓨터의 4대 핵심 부품:
  - CPU (중앙처리장치)
  - 메모리 (주기억장치)
  - 보조기억장치
  - 입출력장치

CPU

컴퓨터의 두뇌 역할
명령어를 읽고 → 해석하고 → 실행

주요 구성 요소

ALU (산술논리연산장치)
레지스터
제어장치

메모리

현재 실행되는 프로그램의 명령어와 데이터를 저장하는 부품
프로그램이 실행되려면 반드시 메모리에 저장되어 있어야 한다.
휘발성: 전원 꺼지면 데이터 사라짐
가격 ↑, 저장용량 ↓

️ 보조기억장치

비휘발성 저장장치
전원이 꺼져도 데이터 유지

️ 입출력장치

컴퓨터 외부에 연결되어 컴퓨터 내부와 정보를 교환하는 장치
예: 키보드, 마우스, 프린터 등

시스템 버스

위의 4가지 핵심 부품들이 서로 정보를 주고받는 통로

Chapter 02 | 데이터

✅ 기본 개념

비트: 0과 1로 표현되는 최소 단위
2의 보수: 음수 표현 방식
- ① 0과 1 뒤집기 → ② 1 더하기
- 부호 플래그로 양수/음수 구분

문자 표현

유니코드: 여러 나라의 문자를 광범위하게 표현할 수 있는 통일된 문자 집합
인코딩 방식: UTF-8, UTF-16, UTF-32

Chapter 03 | 명령어

✅ 언어의 분류

컴파일 언어: 컴파일러에 의해 소스 코드 전체가 저급 언어로 변환되어 실행되는 고급 언어
- 예: C
- 오류 1개만 있어도 전체 실패
인터프리터 언어: 인터프리터에 의해 소스 코드가 한 줄씩 저급 언어로 변환되어 실행되는 고급 언어
- 예: Python
- 소스 코드를 한 줄씩 차례로 실행한다. N번째 줄에 오류가 있더라도 N-1번째 줄까지는 수행된다.

⚙️ 명령어 구성

연산 코드 (Operation Code): 수행할 연산 (연산자)
오퍼랜드 (Operand): 연산에 필요한 데이터 or 그 데이터가 저장된 위치 (피연산자)
- 피연산자는 없을 수도, 여러 개일 수도 있음
- 보통은 메모리 주소나 레지스터 이름 형태로 명시

[자료구조] 스택과 큐

자료구조	설명	방식
️ 스택(Stack)	한쪽이 막힌 구조	후입선출 (LIFO) : 나중에 저장한 데이터를 가장 먼저 빼내는 데이터 관리 방식
큐(Queue)	양쪽이 열린 구조	선입선출 (FIFO) : 가장 먼저 저장된 데이터부터 빼네는 데이터 관리 방식

[문제 풀이]

p.51 확인문제 3번

프로그램이 실행되려면 반드시 (메모리)에 저장되어 있어야 합니다.

p.65 확인문제 3번

Q. 1101(2)의 음수를 2의 보수 표현법으로 구하기

1 1 0 1
   ↓      (모든 0과 1 뒤집기)
0 0 1 0
   ↓      (1 더하기)
0 0 1 1

정답: 0011(2)