leafbird/devnote

프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링. AI를 활용한 개발이 어떻게 진화하고 있는지, 세 가지 키워드로 정리해봅니다.

기술 블로그에 글을 적으려다 보니까, 내용 중간에 간단한 플로우 차트나 다이어그램을 곁들여서 설명을 보강하면 좋겠다는 생각이 들었습니다. 예를 들면 이런거요.

이런거 좀 내맘같이 쉽게 처리해주는 플러그인이 없을까 해서 잠시 찾아보았는데, 잘 안 보이더라고요.
그래서 어제~오늘 ai랑 같이 작업해서 조그만 플러그인으로 정리해 공개했습니다.

openclaw을 집에서 띄워 쓰고 있다가 밀린 업데이트를 여러 개 받았는데, 조금 있으니 대시보드가 제대로 동작하지 않았다. 권한이 없다는 오류가 찍히면서 API 호출이 줄줄이 실패하는 상황.

설정을 잘못 건드렸나 싶어서 이것저것 확인해봤는데, 내 설정 문제는 아닌 것 같았다.

들어가며

지난 글(링크)에서는 Actor 패턴을 MMO 서버에 적용할 때의 두 가지 접근 방식 — Zone 단위의 Coarse-grained 방식과 Object 단위의 Fine-grained 방식 — 을 비교해 보았습니다.

이제 드디어 실제 코드를 살펴볼 차례입니다. 이번 글에서는 현재 프로젝트에서 사용 중인 경량 Actor 구현체의 핵심 구조를 소개합니다. 주로 스레드가 어떻게 운용되는지, 그리고 c#의 비동기 메서드(async/await)로 인해 끊겼다 이어지는 스레드 흐름을 어떻게 다루는지에 대해 적어보겠습니다. 다음 주제들을 하나씩 다뤄볼게요.

• Symmetric 스레드 모델: 역할이 고정된 스레드가 아닌, 모든 스레드가 모든 일을 처리하는 방식
• 메시지 큐와 스케줄링: JobDispatcher를 중심으로 한 작업 분배
• Starvation 방지: readyQueue를 통한 공정한 처리
• 동기/비동기 메시지 분리: await 키워드와 함께 자연스럽게 동작하는 구조

들어가며

지난 글(링크)에서는 POSA 2의 동시성 패턴들 — Reactor, Proactor, Actor — 을 간단하게 소개하고 살펴보았습니다. 이론적 배경을 이해했으니, 이제 실전으로 넘어갈 차례입니다.

근데 이제.. 실제 게임 만들 때 Actor 모델을 어떻게 적용한다는 건가?

이 질문에 정해진 답은 없습니다. 하지만 Actor의 적용 범위에 따라 실제 프로그래머가 코딩하는 환경이나 완성된 시스템의 동작 특성은 제법 큰 차이가 발생합니다. 이번 글에서는 MMO 게임속 상황을 예시로, 두 가지 대조적인 접근 방식을 살펴보겠습니다.

들어가며

동시성 프로그래밍은 현대 소프트웨어 개발에서 피할 수 없는 주제입니다. 멀티코어 프로세서가 보편화되고, 분산 시스템이 일상이 된 지금, 효율적이고 안전한 동시성 처리는 더 이상 선택이 아닌 필수가 되었습니다.

이 글에서는 현재 프로젝트에서 직접 작성해 사용하고 있는 C# Actor 구현체를 소개하기에 앞서, 먼저 Actor 패턴의 이론적 배경을 살펴보고자 합니다. 특히 POSA 2에서 소개하는 동시성 패턴들을 중심으로, Actor 패턴이 어떤 맥락에서 등장했는지 이해해 보겠습니다.

올 해에 가장 잘 했던 기술적 선택을 꼽으라고 한다면
연초에 서비스 환경을 리눅스로 전환하겠다고 결정한 점이다.

아니, 정말로요. 빈 말이 아니고요.

만약에 요즘에 누군가와 사교적인 말하기를 하다가 취미가 무엇이냐는 질문을 받는다면,

요즘 터미널 꾸미는 것에 빠져있어요.

라고 대답할 것 같아요.

회사에서 빌드머신으로 사용중인 맥미니 장비들은 주기적으로 몇가지 관리가 필요하다.

최근에 유니티6로 엔진 업데이트한 이후 빌드머신에 갖가지 이슈들이 생기면서 디스크 용량 체크를 해보던 중이었다.

이거 코드 작업 조금만 하면 만들 수 있겠다는 생각이 들었고, 미루면 아마 영영 실천으로 옮기지 않게 될 것 같아 생각난 김에 바로 만들었다.

매번 터미널을 열 때마다 2 ~ 3초가 걸리는 것은 부담스럽다.

방법을 찾아야 한다.