안녕하세요, 배준수입니다. v1.0.0에 이어 바로 이것저것 더 손봤습니다. v1.1.0에서 바뀐 점입니다. 새로 생긴 것 상단에 공지 메뉴가 생겼습니다. 이 글 같은 공지들을 모아서 볼 수 있어요. 카테고리(공부·로그 등) 페이지에 글이 너무 많아 무거웠는데, 이제 처음엔 30개만 보여주고 ‘더보기’ 로 이어서 볼 수 있게 했습니다. 정리한 것 예전 부트캠프(정글) 시절 글 76개를 ‘로그’ 카테고리 안의 jungle 시리즈로 옮겨 정리했습니다. 이제 로그에서 시리즈 필터로 골라 볼 수 있어요. (글 주소는 그대로입니다) 안 보이지만 개선한 것 검색이 더 가벼워졌습니다. 검색 인덱스에서 중복 데이터를 걷어내 크기를 약 40% 줄였어요(전문 검색 기능은 그대로). 빌드 환경/설정도 최신에 맞춰 정리했습니다. 읽어주셔서 감사합니다. 🙌

안녕하세요, 배준수입니다. 오랜만에 블로그를 이것저것 손봤습니다. 이번 개선분부터는 버전을 붙여서 관리하기로 했어요. 그 시작인 v1.0.0에서 바뀐 점들을 정리합니다. 새로 생긴 것 최근 글 N 표시 최근 7일 안에 올라온 글은 제목 옆에 주황색 N 뱃지가 붙습니다. 새 글이 있는 카테고리 메뉴 옆에도 작게 N 이 뜨니, 어디에 새 글이 올라왔는지 한눈에 보실 수 있어요. 카테고리 안에서 시리즈로 걸러 보기 공부·로그·프로젝트·일상 같은 카테고리에 들어가면 글이 전부 쏟아져 나왔는데, 이제 상단에 시리즈 필터 버튼이 생겼습니다. 예를 들어 ‘공부’에서 algorithm, MySQL 처럼 원하는 시리즈만 골라 볼 수 있습니다. 이미지 크게 보기 본문 이미지를 클릭하면 원본을 새 창에서 크게 볼 수 있습니다. 도표나 코드 캡처를 볼 때 편해졌어요. 다듬은 것 목차 링크에 마우스를 올리면 커서가 손가락 모양으로 바뀌도록 했습니다. 상단 메뉴 순서를 정리했습니다: 홈 → 소개 → 공부 → 로그 → 프로젝트 → 일상 → 검색 → 아카이브. 게임 개발(Godot) 글을 ‘프로젝트’로 옮겼습니다. 안 보이지만 중요한 것 그동안 글 750여 개가 한 폴더에 전부 쌓여 있어서 관리가 힘들었는데, 카테고리/시리즈 폴더로 정리했습니다. 다행히 기존 글 주소(URL)는 하나도 바뀌지 않았으니, 북마크나 검색 링크는 그대로 쓰셔도 됩니다. 앞으로도 틈틈이 다듬어 나가겠습니다. 읽어주셔서 감사합니다. 🙌

오늘 한 것 Godot 4.7 설치 (Homebrew) 첫 프로젝트 세팅, 씬(.tscn)과 스크립트(.gd) 연결 확인 클릭하면 자산이 오르는 간단한 UI 예제 제작 자산이 랜덤(50/50)으로 오르내리는 슬롯머신으로 발전 씬 전환(은행 페이지) + 전역 상태(Autoload) 도입 상태 메시지(“돈을 벌었다!” / “돈을 잃었다!”) 표시 추가 tutorials/, docs/ 폴더로 프로젝트 구조 정리 1. 스크립트와 씬 씬(Scene): 화면에 나타나는 것. 버튼, 라벨 등을 배치해두는 선언적 파일(.tscn). 스크립트(Script): 동작, 변수, 로직 등 실제 코드(.gd). 2. 노드 vs 변수 변수: 값 하나를 담는 상자. 노드: 객체(라벨, 버튼, 관리자 등). 따라서 자신만의 속성과 함수를 가짐. 씬 정의 파일(.tscn) 내에 정의되어 있음. Autoload: 노드를 전역으로 등록. project.godot 파일에서 등록 가능. 3. Autoload (싱글톤) 씬이 바뀌어도 사라지지 않는 전역 저장소. 실제 정체는 전역 노드. 전역 변수는 전역 노드의 속성으로 관리되는 것. 4. 멀티 씬 씬이 여러 개면 씬끼리 변수를 공유해야 할 수 있음. 전역 노드를 하나 설정하고, 그 노드의 속성들을 전역 변수로 쓰는 방식을 이용 (= GameState.gd를 Autoload로 등록해서 GameState.money를 여러 씬이 공유). 5. 씬 전환 1 get_tree().change_scene_to_file("res://tutorials/scenes/Bank.tscn") get_tree(): 씬 관리자(SceneTree 객체) 반환. 씬 관련 함수는 씬 관리자만 호출할 수 있음 (change_scene_to_file()은 SceneTree의 메서드이므로 get_tree()로 그 객체를 먼저 가져와야 호출 가능). 6. $이름 get_node("이름")의 축약형으로, 이름이 ‘이름’인 노드를 찾아오라는 검색 명령임 (변수 선언이 아님). 나중에 노드 참조가 많아지면 아래처럼 해두면 자동완성/타입 체크가 편함: 1 @onready var status_label: Label = $StatusLabel 프로젝트 구조 1 2 3 4 5 6 7 8 tutorials/ ├── scenes/ │ ├── Main.tscn # 자산 표시, 돈넣기(슬롯머신), 은행가기 버튼 │ └── Bank.tscn # 자산 표시, 대출받기, 돌아가기 버튼 └── scripts/ ├── Main.gd ├── Bank.gd └── GameState.gd # Autoload로 등록된 전역 자산 상태 실습 Godot 에디터 사용법. 아래 파일 시스템에서 Scene을 추가 후 Command + b로 디버거 실행 ...

왜 gRPC를 쓰려고 했나 내가 관리하는 서버에는 이커머스 플랫폼에서 발생한 데이터를 저장하고 관리하고 있다. 이 데이터는 여러 프로덕트들과 통신으로 주고받는다. 지금까지는 REST(흔히 쓰는 HTTP API 방식)로 이 데이터를 주고받았는데, gRPC라는 통신 방식으로 옮기면 다음과 같은 이득이 있을 거라 기대했다. 더 빠른 통신 → 리소스 부하와 비용 감소: 통신이 빨라지면 서버가 요청 하나를 처리하는 데 걸리는 시간이 줄고, 그만큼 같은 서버 자원으로 더 많은 요청을 처리할 수 있다. 내부 전용(private) 통신 구조로 인한 통신 비용 감소: gRPC는 외부에 노출되지 않는 private subnet을 이용한 VPC 내부망 통신으로 구현했기 때문에, 이 경로로 오가는 데이터에 대한 통신 비용이 줄어든다. 위성 서비스의 중복 리소스 관리 부담 감소: 1번의 효과로, 데이터를 가져다 쓰는 여러 위성 서비스(주문/리뷰/업셀/푸시 등)가 각자 캐싱이나 재시도 로직 같은 걸 두껍게 만들 필요가 줄어들 거라 예상했다. 기존 REST 통신들을 gRPC로 점차 옮겨가는 작업을 진행하면서, 정말 기대한 대로 빨라졌는지를 실제로 확인해보고 싶었다. 이 글은 그 확인 과정에서 벌어진 일을 정리한 것이다. ...

13-1 교착 상태란 식사하는 철학자 문제 dining philosophers problems 원탁에서 모두가 자신의 오른쪽 포크를 들고 왼쪽 포크를 기다리는 상태 교착상태(deadlock) 자원 할당 그래프 자원 할당 그래프(resource-allocation graph) 출처: https://www.geeksforgeeks.org/operating-systems/resource-allocation-graph-rag-in-operating-system/ 프로세스는 원, 자원의 종류는 사각형 자원 사각형 내의 점은 사용할 수 있는 자원의 갯수 프로세스가 자원을 할당받아 사용 중이라면 자원 내 점 → 프로세스 화살표 표시 프로세스가 자원을 기다리고 있다면 프로세스 → 자원 화살표 표시 교착 상태가 발생한 상황은 보통 자원 할당 그래프가 원의 형태를 띄고 있음. ...

12-1 동기화란 동기화의 의미 동기화(synchronization): 작업들 사이의 수행 시기를 맞추는 것 실행의 흐름을 갖는 모든 것(프로세스, 스레드 등)은 동기화의 대상 실행 순서 제어: 프로세스를 올바른 순서대로 실행하기 상호 배제: 동시에 접근해서는 안 되는 자원에 하나의 프로세스만 접근하게 하기 생산자와 소비자 문제 생산자와 소비자가 동시에 접근해서는 안 되는 자원에 동시에 접근하면 결과값이 매번 달라지거나 이상해진다. 공유 자원과 임계 구역 공유 자원(shared resource): 동시에 실행되는 프로세스가 사용하는 공동의 자원(전역 변수, 파일, 입출력장치 등) ...

단단한 삶은 보통의 날들로 이루어진다 지은이: 펄 카츠 옮긴이: 정영은 출판사: 북다 감상 나는 얇고 길게 지속되는 노력이 정말 가치있는 덕목이라고 생각한다. 내가 정글에서 느꼈던 몰입은 삶에 끼치는 영향은 더 클지 모르겠지만 살면서 무언가에 몰입할 수 있는 시기는 그리 많지 않다. 우리는 동시에 많은 것을 신경쓰면서 살아야 한다. 매일 일을 하며, 사랑하는 사람과 무언가를 같이 추억을 쌓아나아야 하고, 가족을 신경쓰며, 재테크도 한다. 친구 관계, 이사 준비, 질병 등 나의 집중을 갉아 먹는 존재는 무궁무진 하다. ...

11-1 CPU 스케줄링 개요 CPU 스케줄링(CPU scheduling): 운영체제가 프로세스들에게 공정하고 합리적으로 CPU 자원을 배분하는 것 프로세스 우선 순위 프로세스의 CPU 사용을 우선순위에 맞추어 처리 입출력 집중 프로세스(I/O bound process) **입출력 작업(입출력 버스트, I/O burst)**이 많은 프로세스 실행 상태보다는 입출력을 위한 대기 상태에 많이 머무름 CPU 집중 프로세스(CPU bound process) **CPU 작업(CPU 버스트, CPU burst)**이 많은 프로세스 대기 상태보다는 실행 상태에 더 많이 머무름 입출력 집중 프로세스 먼저, CPU 집중 프로세스를 그 다음 ...

뭘 고민하고 있는 건지 고객 데이터에 적립금(포인트) 정보를 추가해야 합니다. 선택지는 세 가지예요. 방안 A: 기존 고객 테이블에 INTEGER 컬럼 3개를 추가한다 방안 B-1: 적립금 전용 테이블을 별도로 만들고, 모든 고객과 1:1로 연결한다 방안 B-2: 적립금 전용 테이블을 별도로 만들되, 포인트가 있는 고객만 행을 생성한다 “관심사에 따라 테이블을 분리하는 게 좋은 설계 아닌가?”라는 질문이 자연스럽게 나오는데, 실제로 우리 환경에서 그게 맞는지 수치로 따져보려고 합니다. 아래 그림으로 방안 A와 B의 차이를 먼저 보시면 이해가 쉽습니다. ...

10-1 프로세스 개요 프로세스(process): 실행중인 프로그램 프로세스 직접 확인하기 ps 명령어를 통해 확인 가능 포그라운드 프로세스(foreground process): 사용자가 보는 앞에서 실행 백그라운드 프로세스(background process): 사용자가 보지 못하는 뒤에서 실행 데몬(daemon): 유닉스 체계의 운영체제의 백그라운드 프로세스 서비스(service): 우니도우 운영체제에서의 백그라운드 프로세스 프로세스 제어 블록 PCB(Process Control Block, 프로세스 제어 블록) 프로세스와 관련된 정보를 저장하는 자료 구조 해당 프로세스를 식별하기 위해 꼭 필요한 정보들이 저장 메모리에 있는 커널 영역에서 생성 프로세스 생성 시에 만들어지고 실행이 끝나면 폐기 PCB에 담기는 정보 PID(프로세스 ID, Process ID) 특정 프로세스를 식별하기 위해 부여되는 고유한 번호 레지스터 값 이전까지 사용했던 레지스터의 중간값 프로그램 카운터 등의 레지스터 값 프로세스 상태 입출력장치를 사용하기 위해 기다리는지, CPU를 기다리는지, CPU를 이용하는지 등 CPU 스케줄링 정보 프로세스가 언제, 어떤 순서로 CPU를 할당받았는지 메모리 관리 정보 프로세스가 어느 주소에 저장되어 있는지 베이스 레지스터, 한계 레지스터 값 등 페이지 테이블 정보 사용한 파일과 입출력장치 목록 실행과정에서 특정 입출력장치나 파일을 사용하는지 문맥 교환 프로세스 실행에 대한 중간 정보를 저장해야, 다음 차례가 왔을 때 이전까찌 실행했던 내용에 이어 다시 실행을 재개할 수 있음 문맥(context) 해당 프로세스의 PCB에 표현 문맥 교환(context switching) 기존 프로세스의 문맥을 PCB에 백업하고, 새로운 프로세스를 실행하기 위해 문맥을 PCB로 복구하여 새로운 프로세스를 실행하는 것 프로세스 A 실행 → A 문맥 저장 → B 문맥 로드 → 프로세스 B 실행 → B 문맥 저장 → … 너무 자주 하면 오버헤드가 발생하여 부정적인 효과 프로세스의 메모리 영역 PCB는 커널 영역에 생성 ...