E:\

제11회 빅데이터분석기사 합격 후기

BVM — Fri, 19 Dec 2025 16:07:23 +0900

어떻게 합격하여 이렇게 합격 후기를 작성하게 됐다.

필기는 어찌 한방에 합격했지만 실기는 그렇게 자신이 있진 않았다.

필기에서 공부한 개념들을 실기에서 내가 제대로 코드로 쓸 수 있을까? 라는 의문이 있었기 때문.

그래도 합격했으니 참으로 다행이라고 생각한다.

점수

잘 난 점수는 아니지만...

합격했다는 것이 중요하다!

배경

빅데이터분석기사 공부 시작 전 나의 상황

1. 컴퓨터공학 전공

2. 파이썬으로 필요한 프로그램 작성해 활용한 경험 有

3. 통계 문외한
- 학부 때 통계과목 1학기 수강

그냥 코드 작성에만 좀 익숙한 완전한 노베이스 상태였다.

사용한 교재

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=343937260

2025 이기적 빅데이터분석기사 필기 기본서 | 2025 이기적 빅데이터분석기사 | 나홍석 외

최신 출제기준을 적용한 도서로, 빅데이터분석기사 필기 시험의 출제 경향을 철저히 분석하여 수험생들이 혼자서도 학습할 수 있도록 한 완벽 대비서이다. 시행처인 한국데이터산업진흥원에서

www.aladin.co.kr

필기 교재와 실기 교재를 같이 구매했다.

이 교재를 통해서만 "혼자" 공부했다.

다른 교재나 강의를 구매하지 않았다.

반년을 함께한 이기적 교재로만 해결이 다 됐다!

공부 방법

필기

기간

실제 공부 기간은 1달 정도.

하루에 2시간 정도 공부했다.

시간을 딱 정해서 공부한 게 아니라, '어느 파트까지 오늘 하겠다'라는 기준을 잡고 진행한 것이다.

어떤 날은 그 기준을 크게 잡아, 하루에 8시간 이상 공부하는 때도 있었다.

방법

1회독은 그냥 쭉 진행한다.

아무것도 모르는 상태이므로 끝까지 보면서 얕게나마 기억할 수 있게 한다.

이때, 자기가 뭐에 강하고 뭐에 약한지 어느 정도 인식할 수 있다.

1회독을 마치고 기출이나 모의고사를 1 ~ 2회라도 풀어보며 다시 강점과 약점을 점검한다.

2회독부터 약점 위주로 공략한다.

나의 경우는 2, 3파트가 약점이었는데, 실제로 수식을 적용해 계산하는 파트에서 수식이 기억이 안 나 어려웠고,

머신러닝에 대해 너무 얕고 부정확하게 알고 있는 것들이 독이 되는 부분이 있었기 때문이다.

2회독 이후, 남은 기출과 모의고사를 계속 풀며 깎아나간다.

찍어서 맞춘 문제, 긴가민가했던 문제나 틀린 문제들은, 다음처럼 해당 개념이 책의 몇 페이지에 나와있는지 체크하고 넘어갔다.

강점이 계속 강점일 수 있게 하고, 약점을 계속 보완하며 최종적으로 깎아나간다.

교재에 필기 기출은 물론, 충분한 양의 모의고사가 수록돼 있었다고 생각한다.

https://cbt.youngjin.com/exam/index.php?no=69

이기적 CBT, 영진닷컴

빅데이터분석 기사 필기 답안 표기란 과목명 문항수 합격점수 1 과목 빅데이터 분석기획 20개 60점 2 과목 빅데이터 탐색 20개 60점 3 과목 빅데이터 모델링 20개 60점 4 과목 빅데이터 결과 해석 20개

cbt.youngjin.com

영진닷컴이 제공하는 CBT도 시험 1 ~ 2일 전에 활용했다.

단, 문제 가짓수가 많지 않으므로 너무 많이 활용하는 것은 진짜 실력을 확인하기 어려워질 수 있으므로 지양하는 것이 좋다.

4번 정도까지만 활용하는 것이 좋다고 생각한다.

평가

11회 필기는 2, 3파트가 확실히 어려웠다.
생소한 내용이 많았지만, 공부한 내용도 나왔기 때문에,
개념을 확실히 알고 간다면 충분히 합격을 노릴 수 있다고 생각된다.
계산 문제의 비중이 크지 않기 때문에 기조가 유지된다면,

좀 더 암기에 집중하는 것도 괜찮은 것 같다.

나와 같은 비전공자들은 더 많은 시간을 투자해야 하기 때문에 시간이 매우 부족하다.
공부할 내용이 많고, 유사한 개념들이 많이 등장해 매우 헷갈리게 된다.
나는 조금 급해서 공부를 제대로 못했는데, 2달 정도면 충분한 안전마진인 것 같다.

특히 이번 11회 필기에서 책에서 본 적 없는 개념이 등장했다.

그 문제를 딱 봤을 때의 당혹감이란...
앞으로의 시험 기조에 대한 힌트를 던졌다는 느낌이 든다.

RPG로 비유해 보자면, "모르면 죽어야지" 식의 패턴과 같다.
이런 것까지 완벽하게 공부하기가 어려울 것이다.
하지만, 이번 시험처럼만 나오게 된다면 책에 있는 개념을 확실히 공부하면 문제없을 것이다.
저도 그러한 문제들은 찍고 넘겼기 때문에 우리가 공부한 부분을 더 깊게 파고들면 합격으로 이어진다고 생각한다!

아무리 "모르면 죽어야지"식의 문제가 나온다 한들, 숫자가 많지 않을 것이기 때문이다.

실기

기간

실기도 필기와 유사하게 한 달 정도 공부했다.

공부 구간을 정하고 평균 1 ~ 2시간 정도 공부했다.

부족한 파트를 볼 때는 6 ~ 8시간을 볼 때도 있었다.

방법

1회독은 그냥 쭉 본다.

필기에서 했던 것처럼 얕게라도 기억하게 한다.

N회독은 진행하지 않았는데, 실기 특성상 개념에 대한 N회독은 무의미하다고 생각했기 때문이다.

대신 바로 기출을 풀어보기로 했다.

처음 몇 개의 문제들은 오픈북을 한다는 느낌으로 앞의 개념들을 참고하며 풀었다.

이런 식으로 진행하며 어떤 파트에선 어떤 유형이 주로 나오고, 어떤 패턴이 있는지 파악할 수 있다.

슬기로운 통계생활 빅데이터분석기사 커뮤니티에서 제공하는 정보들도 활용했다.

이기적 실기 교재 구매를 인증하면 추가 자료도 제공하는 것이 좋았다.

그리고, 기출 복원이 사람마다 다르게 진행되는 만큼,

검색을 통해 다양한 실기 복원을 확인하고 풀어보는 연습도 진행했다.

유사한 문제라도 미묘하게 달라지는 부분이 있어, 간접적으로 다양한 풀이 유형을 경험할 수 있게 된다.

난 책에 뭘 쓰면서 한 게 아니라, 다음과 같이 에디터에 주석과 함께 작성하면서 공부했다.

이런 식으로 정리하며 공부했다.

예제는 AI를 통해 작성한 예제고, 체험환경에서 제공하는 문제도 풀이를 저장했다.

각 폴더 내용은 이렇게 정리했다.

이런 식으로 정답 스크립트 파일에 주석과 함께 정리했다.

최초에 푼 후 정답을 확인했을 때 내가 작성한 코드보다 좋은 코드였다면,

기존 내 풀이와 함께 그 코드도 가져와 설명을 추가해 그 코드가 왜 좋은 지도 기록했다.

평가

11회 실기는 평이한 난이도였다고 생각한다.

분명 공부한 내용이었는데도 내가 기억하지 못해서 틀려먹은 문제가 좀 많지만...

이번 회차의 실기를 난도가 높다고 하기엔 무리가 좀 있을 것이다.

복기는 다음 커뮤니티에 잘 돼 있으니 참고한다.

https://lab.statisticsplaybook.com/portal/space/bigbungi/post/i-oe-11isoe-e-e-i-i-e-i-e-i-i-e

슬통LAB - 데이터분석, 통계 커뮤니티

복기 남기고 슬통 할인쿠폰 & 스벅 기프티콘 받자! 안녕하세요, 슬통연구소 빅데이터 분석기사 커뮤니티 운영진입니다. 시험 보시느라 정말 수고 많으셨습니다! 이번 시험에 어떤 문제가 나왔는

lab.statisticsplaybook.com

1유형

1. 온실가스 데이터

연도별 온실가스 배출량 1위 국가를 구하는 문제였는데,

바로 구하는 방법을 기억해내지 못해 억지로 패턴 매칭 코드를 작성해 답을 도출했었다.

이후에 어떤 값의 최댓값을 구하는 부분은 간단하게 진행됐다.

2. 결측치를 대체하고 지정된 값을 구하는 문제

``SimpleImputer``를 사용해 결측치를 처리했다.

3. 거래 데이터 처리

이 문제에서 단 한 곳만 제외하고 나머지 코드는 다 맞게 작성했다.

거래가 취소한 건의 거래액에는 -1을 곱해 음수로 만드는 문제였는데,

``loc``을 안 쓰고 무식하게 음수로 만드려고 하니 동작하지 않았다.

Df[df['canceled'] == True]['amount] = - (df['canceled'] == True]['amount])

이런 식으로 하니까 당연히 동작하지 않는다.

Pandas에선 이러한 체인 인덱싱을 사용해 슬라이싱 후 값을 할당하려고 하면 문제가 생긴다.

``df[df['canceled'] == True]``는 원본 DataFrame df의 복사본(Copy) 일 수도 있고, 뷰(View) 일 수도 있다.

Pandas는 이를 보장하지 않는다.

두 번째 인덱싱 ``(['amount'] = ...)``에 값을 할당하려고 할 때,

Pandas는 할당 대상이 원본 df의 복사본인지 뷰인지 알 수 없으므로,

사용자에게 경고(SettingWithCopyWarning)를 발생시키며 원본 데이터가 변경되지 않을 위험이 있다.
만약 첫 번째 인덱싱 결과가 복사본이었다면, 그 복사본에만 값을 할당하게 되고, 원본 df는 전혀 변경되지 않는다.

이는 ``loc``을 통한 명시적 인덱싱으로 해결해야 한다.

# 'canceled'가 True인 행의 'amount' 열에만 -1을 곱하여 할당
df.loc[df['canceled'] == True, 'amount'] = -df['amount']

분명 공부한 내용이고, 신경 써서 몇 번 확인했던 내용인데도 떠올리지 못해서 틀려버리고 말았다.

``loc``을 사용해야 하는 문제는 계속 나올 가능성이 높다고 생각하므로, 확실히 공부해 두는 것이 좋겠다.

2유형

2유형에 대해선 난 다음의 전략을 사용했다.

"그리드 서치 같은 짓 하지 말고 RF로만 빠르게 작성하고 다른 문제에 시간을 더 투자하겠다."

난 이 전략에 따라 그리드 서치를 실제로 어떻게 활용할지에 대한 고민을 하지 않았다.

데이터에 결측치도 없어서 그냥 빠르게 ``RandomForestClassifier``를 사용해 간결하게 끝냈다.

난 검증 데이터 분할 없이 기본으로 주어지는 학습 데이터 모두를 학습에 사용했다.

나처럼 그냥 탐색 없이 그냥 랜덤 포레스트를 사용한 사람들은 25점을 받았다고 했는데, 나의 경우는 30점이다.

난 아마 분할 없이 데이터를 그대로 다 써서 그랬던 것일지도 모르겠다.

3유형

선형회귀, 상관계수 등을 구하는 문제들이 있는 곳이다.

다 무난한 문제들이었다.

여기서 ttest 문제를 하나 틀렸다.

매장 홍보 전후의 매출 차이에 대한 계수를 구하는 문제였다.

홍보 전의 평균 고객 당 매출은 35000원이었고, 주어진 데이터는 홍보 후의 고객 별 매출 데이터였다.

따라서 이 문제는 다음과 같은 형태로 풀어야 한다.

import scipy.stats as stats
import pandas as pd

# 예시 데이터 생성
# data = pd.read_csv("data.csv")['purchase_amount']
data = [36000, 37000, 34500, 38000, 35500, 36500, 37500, 34000, 39000, 36000]

# 기존 알려진 평균 (홍보 전)
popmean = 35000

# 1. 정규성 검정 (데이터 수가 적을 경우 수행, n > 30이면 생략 가능하기도 함)
# 귀무가설: 데이터가 정규분포를 따른다.
# p-value > 0.05 이면 정규성 만족으로 간주 -> t-test 진행
stat, p_val_norm = stats.shapiro(data)
print(f"Shapiro P-value: {p_val_norm:.4f}")

# 2. 일표본 t-검정 (One-Sample t-test) 수행
# stats.ttest_1samp(데이터, 비교할_평균)
# 기본값은 양측 검정(two-sided). (단순 차이 확인)
t_statistic, p_value = stats.ttest_1samp(data, popmean)

print(f"T-statistic: {t_statistic:.4f}")
print(f"P-value: {p_value:.4f}")

# 3. 결과 해석 (유의수준 0.05 기준)
if p_value < 0.05:
    print("귀무가설 기각: 홍보 후 구매 금액은 35,000원과 유의미한 차이가 있습니다.")
else:
    print("귀무가설 채택: 홍보 후 구매 금액은 35,000원과 차이가 있다고 보기 어렵습니다.")

주어진 비교 데이터가 평균 하나밖에 없는 상황에서 어떤 걸 써야 할지 제대로 기억하지 못했다.

그래서 난 억지로 평균이 35000인 같은 크기의 배열을 생성해 "독립표본 T-검정"으로 풀었다.

따라서 오답일 수밖에 없었다.

3유형에서 20점을 얻은 것을 보면 다른 2개 문제는 다 제대로 정답을 제시한 것 같다.

실기에서 중요한 것

help()와 dir()의 사용법

나는 VSCode와 같은 자동완성이 지원되는 에디터에서 코드 작성을 연습했다.

그렇기에 연습 과정에서 ``help()``와 ``dir()``라는 함수를 사용할 일이 일절 없었다.

하지만, 시험 환경에선 그런 기능이 일절 없기 때문에 패키지나 함수 이름이 잘 기억이 안 나면,

무조건 저것들로 찾아야 한다.

나도 시험 이틀 정도 전부터 자동완성 없이 문제를 푸는 연습을 했다.

기존에 연습하면서 어떤 패키지가 어디에 있고, 함수 이름이 뭐고 정도는 대강 알았기 때문에 큰 문제는 없었다.

막상 실제 시험장에 가 보니 애매한 경우가 좀 있었는데, 저 함수들로 잘 해결할 수 있었다.

어떤 일이 있어도 이 함수들의 사용은 잘 이해하고 가야 하겠다.

시험 시작 전 환경에서 연습하기

시험 시작이 10시일 때, 9시 30분부터 컴퓨터를 켜고 환경을 점검할 수 있다.

이때 그냥 멍하게 있는 것이 아니라, ``help()``같은 함수들을 사용하며 감각을 익혀야 한다.

패키지들을 불러와서 잘 동작하는지도 확인해 보자.

나도 긴장에 좀 가물가물하다가 저 시간을 활용해서 정신을 좀 차리고 시험장 환경에 적응했던 것 같다.

이 시간에 여러 코드를 작성해 테스트해 보면서 나름대로 준비를 한 것이 꽤 도움이 됐다.

시험 대비 자료 정리

시험 전까지 계속 머리에 넣기 위해 개념 등을 정리한 자료를 AI를 통해 만들었다.

# [기본 데이터 처리]
import pandas as pd
import numpy as np

# [데이터 전처리]
from sklearn.preprocessing import LabelEncoder, OneHotEncoder, MinMaxScaler, StandardScaler
from sklearn.impute import SimpleImputer

# [모델링 & 평가]
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier, RandomForestRegressor
from sklearn.metrics import f1_score, roc_auc_score, accuracy_score, mean_squared_error, r2_score

# [통계 검정 - scipy]
from scipy import stats
stats.ttest_ind, stats.ttest_rel, stats.ttest_1samp # (T-test)
stats.chi2_contingency # (카이제곱)
stats.f_oneway # (ANOVA)
stats.shapiro, stats.kstest # (정규성 검정)
stats.wilcoxon, stats.kruskal # (비모수 검정)
stats.pearsonr # (상관분석)

# [통계 분석 - statsmodels]
import statsmodels.api as sm
from statsmodels.formula.api import ols, logit, glm

# 3-2. 범주형 (최빈값)
# strategy='most_frequent' (최빈값)
imputer_cat = SimpleImputer(strategy='most_frequent')
df[['cat_col']] = imputer_cat.fit_transform(df[['cat_col']])

# [Tip] 모든 컬럼을 한 번에 채우고 싶을 때 (df[:] 사용)
# df[:] = ... 하면 컬럼명/인덱스 유지하면서 값만 교체됨 (매우 유용!)
imputer = SimpleImputer(strategy='mean')
df[:] = imputer.fit_transform(df)

df_train[:] = imputer.fit_transform(df_train)
df_test[:] = imputer.transform(df_test)

# 4. [Expert] 그룹별 결측치 대치 (9회 기출 패턴)
# 예: '학과'별 '성적'의 평균으로 결측치 채우기
# transform('mean')은 그룹별 평균을 원래 데이터 인덱스에 맞춰 확장해줌
df['score'] = df['score'].fillna(df.groupby('major')['score'].transform('mean'))

# 5. 삭제
df = df.dropna()

# 라벨 인코딩 (범주형 -> 수치형)
from sklearn.preprocessing import LabelEncoder
le = LabelEncoder()
df['category_col'] = le.fit_transform(df['category_col'])

# 원-핫 인코딩 (주의: Train/Test 컬럼 개수 불일치 해결 필수!)
# [Method 1] 자동 변환 (편리함): 문자열(object) 컬럼 자동 감지
X_train = pd.get_dummies(X_train)
X_test = pd.get_dummies(X_test)

이런 식으로 내용을 꽉 채운 마크다운 문서를 만들고, ``pdf``로 변환해 폰에 저장 후 시험장까지 이동하며 공부했다.

확실히 정리된 자료가 있으니까 좋았다.

공부하면서 아차 싶었던 것들을 한 곳에 정리해 두니 좀 덜 까먹게 되더라.

단순히 자료 정리뿐만 아니라, 공부하면서도 AI의 덕을 많이 봤다.

단순히 "이렇게 해야 정답이다"가 아니라, "왜 이걸 써야만 하는지"에 대해 까지 자세하게 알려주니 공부하기 매우 좋았다.

후기

얼떨결에 준비하게 된 빅데이터 분석기사, 아는 게 없으니 쉽지 않았다.

달랑 책 두권만 사서 공부해서 다 한방에 합격했으면 가성비가 꽤 좋았던 것 같다.

정말 다 한방에 넘겨서 참으로 다행이긴 하다...

잘 몰랐던 통계 개념들도 공부하게 된 것이 좋은 경험이었다고 생각한다.

시험도 좀 변해야 할 것 같다.

시험이라는 것의 의도에 대해선 충분히 공감하고 이해하지만,

AI까지 등장해 실생활에 깊이 침투한 상황에서 자동완성 같은 것도 사용하지 못하게 하는 것은 아쉽다는 생각이 든다.

터미널 환경에서도 Neovim 같은 것들을 사용해서 편리한 개발을 할 수 있는 시대이다.

TL;DR: 자동완성 정도는 해줘도 되지 않나?

이렇게 정처기에 이어, 빅분기까지 따면서 쌍기사가 됐다.

솔직히 이 필드에서 쌍기사가 얼마나 메리트가 있나 싶지만...

따 둬서 나쁠 건 하나도 없을 것이다.

이걸 계기로 AI와 관련한 일을 하게 될지도 모르고 말이다.

AI로 MSA 서버 만들어 보기 #4 : Write-Behind

BVM — Tue, 9 Dec 2025 17:11:15 +0900

1. 컨셉

단순한 서버는 "DB 트랜잭션이 끝나야만 유저에게 OK를 보낸다"는 Write-Through 방식을 많이 사용한다.

하지만, 이는 DB가 병목이 될 경우 전체 서버의 반응성을 크게 저하할 수 있다.
Write-Behind (Write-Back) 패턴은 이를 해결할 수 있다.

Memory First: 메모리(또는 빠른 캐시인 Redis)에 먼저 쓰고, 유저에게 즉시 OK를 준다.
Disk Later: 실제 견고한 저장소(RDBMS)에는 별도의 워커가 천천히, 모아서 기록한다.
본 서버는 이 패턴을 Redis Streams를 통해 구현했다.

2. 아키텍처

Decoupling: 채팅 로직(Fast)과 저장 로직(Slow)이 완벽히 분리된다.
Peak Load Handling: 트래픽이 폭주하면 Redis Stream에 데이터가 쌓일 뿐, 서버의 응답 속도는 느려지지 않는다.

3. 생산자 구현 (`emit_write_behind_event`)

서버 코드(server/src/chat/chat_service_core.cpp)에서 이벤트를 발행하는 부분이다.

void ChatService::emit_write_behind_event(const std::string& type, 
                                          const std::string& session_id,
                                          ...) {
    // 1. 데이터 준비 (Key-Value Vector)
    std::vector<std::pair<std::string, std::string>> fields;
    fields.emplace_back("type", type);
    fields.emplace_back("ts_ms", std::to_string(now_ms));
    fields.emplace_back("session_id", session_id);
    // ... (user_id, room_id 등 추가 필드)
    // 2. Redis Stream XADD (Non-blocking)
    // "stream:events" 라는 키에 데이터를 append 한다.
    // maxlen을 설정하여 스트림이 무한히 커지는 것을 방지한다. (Ring Buffer 효과)
    redis_->xadd("stream:events", fields, nullptr, 100000 /*maxlen*/, true /*approx*/);
}

특징:
- JSON Free: 문자열 파싱/생성 비용을 줄이기 위해 Redis의 Native Map 구조를 사용한다.
- Fire and Forget: xadd의 결과를 기다리지 않거나, 실패해도 로그만 남기고 넘어간다 (서버 동작이 우선).

4. Redis Stream

서버가 사용하는 주요 Redis Stream 커맨드이다.

Command	Usage	Role
`XADD key * field value ...`	Producer	스트림 끝에 새 항목 추가. ID는 자동 생성(`timestamp-sequence`).
`XREADGROUP GROUP g1 CONSUMER c1 BLOCK 2000 STREAMS key >`	Consumer	컨슈머 그룹 `g1`의 멤버 `c1`이 되어, 아직 아무도 안 읽은(`>`) 메시지를 읽어옴. 없으면 2초 대기.
`XACK key g1 id ...`	Consumer	"처리 완료" 서명. 이 처리가 되어야 PEL(Pending Entries List)에서 제거됨.

5. 소비자 구현 (The Worker)

현재 구현체는 독립 프로그램 (wb_worker)으로 제공된다.

scripts/smoke_wb.ps1을 통해 빌드 및 간단한 스모크 테스트를 수행할 수 있다.

흐름 (`wb_worker`)

Fetch: XREADGROUP으로 배치 단위(예: 100개)로 이벤트를 가져온다.
Transform: 이벤트 타입(type=chat_msg)에 따라 적절한 SQL(INSERT INTO messages ...)을 생성한다.
Batch Insert: DB 부하를 줄이기 위해 INSERT를 한 번의 트랜잭션으로 묶어서 실행한다 (Bulk Insert).
Acknowledge: DB 커밋이 성공하면 XACK를 날려 Redis에서 해당 항목을 처리 완료로 마킹한다.

6. 문제 대응

"메모리에만 썼는데 서버가 죽으면 어떡하지?"

Redis Persistence: Redis 자체의 AOF (Append Only File) 기능을 켜두면, Redis가 죽었다 살아나도 스트림 데이터는 보존된다.
Consumer Crash:
- 워커가 데이터를 읽어갔는데(XREADGROUP) DB에 넣기 전에 죽었다면?
- XACK를 못 보냈으므로 해당 메시지는 PEL (Pending Entries List)에 남는다.
- 워커가 재가동되면 XREAD ... 0 (또는 XAUTOCLAIM)을 통해 처리되지 않은 메시지를 다시 가져와서 재시도한다. -> At-least-once Delivery 보장.

Trade-offs

Consistency Gap: 아주 짧은 순간(수 ms ~ 수 초) DB와 캐시(메모리) 간의 데이터 불일치가 존재할 수 있다.
Complexity: 시스템 구성 요소가 늘어난다. (Redis 관리, 워커 모니터링 필요)
- 하지만 큰 트래픽을 받는 서버에서 "압도적인 쓰기 성능"을 얻기 위해 이 정도의 복잡도는 충분히 감수할 가치가 있다.

이러면 대충 백엔드 쪽은 간단하게나마 정리됐다.

다른 기능이나 클러스터링을 구현하면 그때 내용을 추가로 보충할 수 있을 것이다.

클라이언트는 ImGui로 다시 작성하고 나면 그 때 글로 정리해 볼 수 있을 것 같다.

AI로 MSA 서버 만들어 보기 #3 : Gateway

BVM — Tue, 9 Dec 2025 15:04:31 +0900

1. 아키텍처 개요

Gateway는 클라이언트와 서버(Game Server) 사이의 Single Entry Point이다.
Nginx나 HAProxy 같은 범용 LB와 달리, 세션의 상태를 파악하고 세션 유지(Stickiness)를 수행하는 커스텀 L7 프록시이다.

서버가 지속적으로 Redis에 하트비트를 보내 살아있음을 알린다.

Gateway는 Redis에서 서버 상태를 읽고 적절히 트래픽을 분산한다.

2. 주요 책임

L7 Load Balancing: 서버들의 부하(접속자 수)를 모니터링하여 최적의 서버로 트래픽을 분산한다.
Session Binding (Stickiness): 유저가 잠시 연결이 끊겼다 재접속해도, 로직 처리를 위해 반드시 이전에 접속했던 서버 인스턴스로 보내준다.
- 지금의 단순한 채팅 서버에선 필요가 없는 기능이긴 하다.
Connection Management: 클라이언트 연결(GatewayConnection)과 백엔드 연결(BackendSession)을 1:1로 매핑하여 관리한다. (Note: 현재 구현은 Connection Pooling이 아닌, 1:1 Bridging 방식)

3. 연결 모델

게이트웨이는 하나의 논리적 클라이언트에 대해 두 개의 물리적 소켓을 유지하고 브릿징한다.

3.1. `GatewayConnection`: Client-Side

클라이언트와 직접 연결되는 소켓.
Hive(I/O Engine)에 의해 관리된다.
패킷이 들어오면 BackendSession으로 send() 한다.

3.2. `BackendSession`: Server-Side

실제 게임 서버와 연결되는 소켓.
GatewayApp 내부 클래스로 구현되어 있다.
패킷이 들어오면 GatewayConnection으로 반사한다.

// gateway/src/gateway_connection.cpp
void GatewayConnection::on_read(const uint8_t* data, size_t length) {
    if (!backend_session_) {
        // 첫 패킷이면(아직 목적지 서버가 없으면) 로드밸런싱 수행
        open_backend_session(); 
    }
    // 패킷 전달 (Forwarding)
    backend_session_->send({data, data + length});
}

4. 로드밸런싱 전략

GatewayApp::select_best_server는 다음 우선순위로 타겟 서버를 결정한다.

Stickiness Check: 이 유저가 원래 있던 서버가 있는가? (SessionDirectory)
Liveness Check: 그 서버가 지금 살아있는가? (BackendRegistry)
Least Connections: 1, 2가 아니라면, 현재 가장 널널한(접속자가 적은) 서버를 선택.

// gateway/src/gateway_app.cpp
std::optional<pair<string, uint16>> GatewayApp::select_best_server(const string& client_id) {
    auto instances = backend_registry_->list_instances();

    // 1. 유저의 기존 서버 확인 (Redis 조회)
    if (auto backend_id = session_directory_->find_backend(client_id)) {
        // ...Alive Check...
        return {host, port}; // Sticky Connection
    }
    // 2. 가장 접속자 적은(Least Connections) 서버 선택
    std::sort(available.begin(), available.end(), [](auto& a, auto& b) {
        return a.active_sessions < b.active_sessions;
    });

    return {available.front().host, available.front().port};
}

5. Session Stickiness

Redis를 활용한 분산 세션 관리 시스템이다.

5.1. The "Split-Brain" Strategy (Cache + Redis)

단순 Redis 조회는 매번 RTT가 발생하여 느릴 수 있다. SessionDirectory는 Local Mutex Cache와 Redis를 혼용한다.

Layer	역할	특징
L1: Local Cache	`std::unordered_map`	락이 걸려있지만 가장 빠름. 짧은 TTL.
L2: Redis	`set_if_not_exists` (SETNX)	다른 게이트웨이와 정보 공유. Single Source of Truth.

// gateway/src/session_directory.cpp
std::optional<std::string> SessionDirectory::find_backend(const std::string& client_id) {
    // 1. 로컬 캐시 확인
    {
        std::lock_guard lk(mutex_);
        if (cache_.has(client_id)) return cache_.get(client_id);
    }

    // 2. Redis 확인 (Cache Miss)
    auto value = redis_->get("gateway/session/" + client_id);
    if (value) {
        // 캐시 채우기 (Read-Repair)
        update_cache(client_id, *value);
    }
    return value;
}

Design Decision: 게이트웨이 인스턴스가 여러 대여도, 유저는 어떤 게이트웨이로 접속하든 항상 자신의 서버로 라우팅된다.

6. 부트스트랩

GatewayApp 생성 시 인프라를 설정한다.

환경 변수	기본값	설명
`GATEWAY_LISTEN`	`0.0.0.0:6000`	클라이언트를 기다릴 주소
`GATEWAY_ID`	`gateway-default`	게이트웨이 식별자 (로그/메트릭용)
`REDIS_URI`	`127.0.0.1:6379`	서버 레지스트리 및 세션 정보 조회용
`METRICS_PORT`	-	Prometheus Exporter 포트

7. 트래픽 흐름

Client Connect: 클라이언트와 TCP 연결이 수립된다. -> GatewayConnection 생성.
First Packet Inspection: 첫 데이터 패킷을 분석한다.
- Login Frame: MSG_LOGIN_REQ 헤더가 보이면 유저 ID를 추출한다.
- Legacy Token: token:client_id 포맷인지 확인한다.
- Anonymous: 둘 다 아니면 익명 접속으로 간주한다.
  - 현재는 무조건 익명 접속으로 진행된다.
Routing: GatewayConnection이 GatewayApp::create_backend_session을 호출한다.
Backend Selection: select_best_server가 Redis를 뒤져서 목적지 서버(예: 10.0.0.4:5000)를 찾는다.
Connect Backend: BackendSession을 만들고 async_connect를 시도한다.
Bridge Established: 연결이 맺어지면, 클라이언트가 보낸 첫 패킷을 백엔드로 flush 한다.
Proxying: 이후 양쪽에서 오는 모든 데이터(on_read)를 상대방에게 send 한다.
- 7.1. Graceful ShutdownGatewayApp은 SIGINT, SIGTERM 시그널을 감지하면 stop()을 호출하여 모든 세션을 정상 종료하고 리소스를 정리한다.

8. Observability

게이트웨이 자체도 모니터링이 필요하다.

Log: 주요 이벤트(Backend Connect/Close, Auth Fail)를 콘솔에 남긴다.
Metrics: http://gateway:9091/metrics
- gateway_sessions_active: 현재 중계 중인 연결 수.

// gateway/src/gateway_app.cpp
metrics_server_ = std::make_unique<MetricsHttpServer>(port, [this]() {
    // 세션 맵의 크기를 실시간으로 반환
    return "gateway_sessions_active " + std::to_string(sessions_.size()); 
});

AI로 MSA 서버 만들어 보기 #2 : Server

BVM — Sun, 7 Dec 2025 20:06:55 +0900

이전에 Core 라이브러리에 대해 설명했다.

여기선 해당 라이브러리를 활용해 작성된 Server에 대해 얘기해 보자.

1. 아키텍처 철학

Server는 "Massively Chat Server"를 지향하며, 다음 3가지 핵심 철학을 지향한다.

Gateway-Centric Architecture:
- 클라이언트는 오직 Gateway(w/ L7 Load Balancer)하고만 연결한다.
- Gateway는 뒷단에 있는 N개의 Server Node 중 하나로 트래픽을 전달한다.
- Effect: 서버 노드 추가/삭제가 자유롭고(Elasticity), 클라이언트는 IP 변경 없이 그대로 사용 가능.
Safety First (Concurrency):
- Global Mutex + JobQueue: 모든 패킷 처리는 I/O 스레드에서 분리되어 JobQueue를 통해 Worker 스레드에서 실행된다.
- Strand per Room: 단일 방(Room)에 대한 처리는 boost::asio::strand를 통해 순차 실행을 보장하여, Lock 경합을 줄이면서도 동시성 문제(Race Condition)를 원천 차단한다.
Hybrid State Management:
- Memory: 빠른 응답을 위해 방 참여자 목록(state_.rooms)은 메모리에 들고 있다.
- Redis: 서버 간 동기화, 서비스 발견(Registry), 세션 스티키니스(Stickiness)는 Redis에 위임(Gateway에서 처리).
- DB (Postgres): 영구 보존이 필요한 데이터(메시지 로그, 유저 정보)는 DB에 저장하되, Write-Behind 패턴으로 지연 기록하여 성능 저하를 막는다.

2. 디렉토리 및 모듈 구조

소스 코드는 ``server/src`` 하위에 기능별로 분리되어 있다.

server/src/
├── app/                  # [Application Layer]
│   ├── bootstrap.cpp     # 서버 구동의 시작점 (main 흐름)
│   ├── config.cpp        # 환경변수 파싱 및 Config 객체 생성
│   ├── router.cpp        # Dispatcher(Opcode -> Handler) 매핑
│   └── metrics_server.cpp# Prometheus 메트릭 수집 서버 (HTTP)
├── chat/                 # [Business Logic Layer]
│   ├── chat_service_core.cpp # ChatService 클래스 공통 로직, 멤버 변수
│   ├── handlers_login.cpp    # 로그인 처리
│   ├── handlers_join.cpp     # 방 입장 처리
│   ├── handlers_leave.cpp    # 방 퇴장 처리
│   ├── handlers_chat.cpp     # 메시지 전송, 귓속말, 슬래시 커맨드
│   ├── handlers_ping.cpp     # Ping/Pong (Liveness Check)
│   └── session_events.cpp    # 세션 종료(Disconnect) 처리
├── state/                # [Distributed State Layer]
│   └── instance_registry.cpp # Redis 기반 서버 인스턴스 등록/조회
└── storage/              # [Infrastructure Layer]
    ├── postgres/         # PostgreSQL 연결 풀 및 Repository 구현
    └── redis/            # Redis 클라이언트 Wrapper

3. 부트스트랩 시퀀스

서버가 시작될 때(``bootstrap.cpp``) 수행되는 **초기화 시퀀스**는 시스템의 핵심이다.

하나라도 실패하면 서버는 뜨지 못한다 (Fail-Fast).

Step	Components	Description
1	`io_context`	Boost.Asio의 핵심 객체. 모든 비동기 작업(Timer, Network I/O)이 여기에 등록된다.
2	`JobQueue`	`server::core::JobQueue`를 생성한다. 네트워크 I/O 스레드가 로직 처리로 바빠지는 것을 막기 위해, 실제 로직은 이 큐를 통해 Worker 스레드로 넘긴다.
3	`ServiceRegistry`	전역 의존성 주입(DI) 컨테이너(`services::set()`)를 초기화한다. 싱글톤 패턴보다 테스트 용이성이 뛰어남.
4	`DB Pool`	PostgreSQL Connection Pool을 생성하고 `health_check()`를 수행한다. DB가 죽어있으면 서버도 시작하지 않는다.
5	`Redis Client`	Redis 연결을 맺고 `PING`을 날려 확인한다. Redis 없이는 서버 구실을 못하므로 필수 체크 항목이다.
6	`InstanceRegistry`	내 서버의 ID와 IP/Port 정보를 담은 `InstanceRecord`를 생성하고, Redis에 등록할 준비를 한다.
7	`Scheduler`	주기적인 작업(Heartbeat, Metric Tick)을 수행할 `TaskScheduler`를 시작한다.
8	`ChatService`	로직의 본체인 `ChatService`를 생성한다. 이때 DB, Redis, JobQueue 객체를 주입받아 완성다.
9	`Dispatcher`	`Opcode`와 `ChatService`의 메소드를 매핑한다. (예: `MSG_CHAT_SEND` -> `chat.on_chat_send`)
10	`Metrics Server`	Prometheus가 긁어갈 수 있도록 별도의 포트에 HTTP 서버를 띄운다. 메인 로직과 스레드가 분리되어 있음.
11	`Acceptor`	실제 클라이언트(또는 Gateway)가 접속할 TCP 포트를 연다.
12	`Workers & Heartbeat`	CPU 코어 수만큼 Worker 스레드를 생성하여 `JobQueue`를 소비하기 시작하고, Redis에 첫 Heartbeat를 전송하여 서비스를 개시한다.

4. 주요 컴포넌트

4.1. `ChatService`

// server/include/server/chat/chat_service.hpp
class ChatService {
    struct State {
        std::unordered_map<string, RoomSet> rooms; // Memory State
        std::unordered_map<Session*, string> user;
    } state_;

    // Core Dependencies
    server::core::JobQueue& job_queue_;
    std::shared_ptr<IRedisClient> redis_;
    std::shared_ptr<IConnectionPool> db_pool_;
};

역할: 서버의 CPU. 모든 로직(로그인, 채팅, 방 관리)을 총괄하고, DB와 Redis 사이를 중재(Mediator Pattern)한다.
Design Patterns:
- Facade: 복잡한 서브시스템을 숨기고, 네트워크 계층에는 on_login, on_chat_send 같은 단순한 인터페이스만 노출한다. Dispatcher는 내부 구현을 알 필요가 없다.
- Mediator: 컴포넌트 간의 복잡한 통신(N:M 관계)을 한 곳으로 집중시킨다. "유저" 객체는 "Redis"를 모르며 당연히 알 필요가 없다. 오직 ChatService를 통해서만 상호작용한다. 이를 통해 결합도를 낮출 수 있다.

4.2. `InstanceRegistry`

// server/src/state/instance_registry.cpp
bool RedisInstanceStateBackend::write_record(const InstanceRecord& record) {
    // 30초 TTL로 내 생존 신고 (Heartbeat)
    return client_->setex("server:registry:" + record.instance_id, 30);
}

역할: "나 살아있다"고 Redis에 주기적으로 알린다. (Heartbeat)
이점: 중앙 관리 서버(Master) 없이도, 모든 서버가 서로의 존재를 알 수 있게 한다. (Peer-to-Peer Discovery) Gateway는 이 정보를 보고 각 서버로 트래픽을 분산시킨다.

4.3. `Dispatcher` (Packet Router)

// server/src/app/router.cpp
dispatcher.register_handler(MSG_CHAT_SEND,
    [&chat](Session& s, std::span<const uint8_t> payload) { 
        chat.on_chat_send(s, payload); 
    });

역할: Opcode(메시지 ID)와 처리 함수(Handler)를 1:1로 매핑한다.
구현: std::unordered_map이나 배열을 사용하여 O(1) 조회 속도를 보장.
특징: 핸들러는 std::function으로 래핑되며, server::app::register_routes 함수에서 일괄 등록된다. 이를 통해 네트워크 레이어(Core)와 애플리케이션 레이어(App)가 분리된다.

4.4. `MetricsServer` (Observability)

// server/src/app/metrics_server.cpp
void MetricsServer::do_accept() {
    // 9090 포트로 들어오는 HTTP 요청을 수동으로 파싱
    if (target == "/metrics") {
        auto snap = runtime_metrics::snapshot();
        // Prometheus 포맷 텍스트 생성
        stream << "chat_job_queue_depth " << snap.job_queue_depth << "\n";
    }
}

역할: Prometheus가 서버 상태를 수집(Scrape)할 수 있는 HTTP 엔드포인트(/metrics)를 제공한다.
이점: 별도의 무거운 웹 프레임워크 없이 boost::asio만으로 가볍게 구현되었다. Main Loop와는 별도의 스레드에서 돌아가므로, 메인 로직이 바빠도 모니터링은 죽지 않는다.

5. 요청 처리 흐름

패킷 하나가 들어왔을 때의 여정을 추적한다.

Network I/O: Session::read_loop가 TCP 버퍼에서 데이터를 읽는다.
Framing: PacketHeader를 파싱하여 패킷을 확실히 식별한다.
Dispatch: router.cpp에 등록된 dispatcher가 Opcode를 확인한다.
Job Enqueue: ChatService::on_chat_send가 호출되지만, 로직을 직접 수행하지 않고 람다(Lambda)로 감싸서 JobQueue에 집어넣고 즉시 리턴한다.
Job Dequeue: Worker 스레드 중 하나가 람다를 꺼내 실행한다.
Logic Execution: 권한 검사, DB 저장, Redis Pub/Sub, 브로드캐스트 패킷 생성이 진행된다.
Send: 결과 패킷들을 Session::async_send 대기열에 넣는다. (IO 스레드가 나중에 모아서 보냄 - Gather Write)

6. 핸들러

6.1. Login Handler (`handlers_login.cpp`)

가장 복잡한 핸들러 중 하나로, 세션의 시작을 알린다.

Logic:
1. get_or_create_session_uuid: 현재 TCP 세션에 고유 UUID(v4)를 부여한다.
2. ensure_unique_or_error: 닉네임 중복 체크. "guest"로 들어오면 자동으로 "guest-a1b2..." 같은 이름을 부여한다.
3. state_.mu Lock: 전역 유저 맵(state_.user)에 (Session Ptr -> Nickname) 매핑을 등록한다.
4. DB Upsert: users 테이블에 접속 기록(IP, 시간)을 남기고, 필요하면 신규 유저 레코드를 생성한다. (Postgres UPSERT)
5. Audit Log: "누가 접속했다"는 시스템 로그를 로비 채팅창에 날린다.
6. Redis Touch: presence:user:{uid} 키에 TTL을 설정하여 "나 온라인이야"라고 표시한다.
7. Write-Behind: emit_write_behind_event("session_login", ...)를 통해 로그인 이벤트를 Redis Stream에 던진다.

6.2. Join Handler (`handlers_join.cpp`)

유저가 방을 옮길 때 호출된다.

Logic:
1. Redis Password Check: 입장하려는 방의 비밀번호를 Redis에서 먼저 조회한다. (Redis가 Master of Truth)
2. state_.mu Lock:
  - 현재 방에서 erase (퇴장 처리).
  - 비밀번호 입력값 검증 (hash_room_password). -> 비밀번호가 없다면 그냥 입장할 수 있다.
  - 새 방에 insert (입장 처리).
  - 만약 이전 방이 비어버렸으면(empty()), 방 객체를 메모리에서 제거함.
3. Broadcasting:
  - 새 방 유저들에게: "XXX님이 입장했습니다." 등 전체 공지를 쏘는 식.
  - Redis Pub/Sub을 통해 모든 서버에 브로드캐스팅된다.
4. Sync Membership: DB memberships 테이블에 (user_id, room_id, role) 정보를 업데이트한다.
5. Snapshot: 클라이언트 UI 갱신을 위해 방 정보, 참여자 목록, 최근 메시지 20개를 한 번에 담은 MSG_STATE_SNAPSHOT을 전송한다.

6.3. Chat & Whisper Handler (`handlers_chat.cpp`)

Regular Chat:
- /로 시작하면 슬래시 커맨드 핸들러로 분기한다. (/refresh, /who 등)
- 권한 확인: 현재 사용자가 해당 방(Room)에 실제로 있는지 state_를 통해 검증한다.
- Fan-out:
  - Local: 내 서버 메모리에 있는 같은 방 유저들에게 async_send.
  - Global: redis_->publish("fanout:room:{room}", msg)로 다른 서버에 있는 유저들에게도 메시지 전달.
- Persistence: DB messages 테이블에 저장한다. 실패해도 채팅은 계속되어야 하므로 try-catch로 감싸고 에러 로그만 남긴다.
Whisper:
- TODO
- 클라이언트를 TUI에서 ImGui를 활용한 GUI로 변환하며 구현할 수도 있다.

6.4. Leave & Disconnect Handler (`handlers_leave.cpp`, `session_events.cpp`)

Leave: 유저가 명시적으로 "나가기" 요청을 한 경우.
- 로직은 Join의 앞부분(퇴장 루틴)과 동일하다.
- 항상 "Lobby"로 강제 이동시킨다. (고아 세션 방지)
  - Lobby가 가장 기본인 방이므로 무조건 여기로 보내야 한다.
Disconnect: 갑자기 랜선이 뽑히거나 강제종료된 경우.
- session_events.cpp의 on_session_close()가 호출된다.
- JobQueue에 정리 작업을 예약한다. (소멸자가 아님! ``shared_ptr`` 수명 관리 중요)
- Redis Presence 키(presence:user:{uid})를 즉시 삭제하지 않고 만료되게 두거나, 명시적으로 지울 수 있다.

7. 데이터 지속성 & Write-Behind

본 서버엔 데이터 쓰기 지연(Write-Behind) 패턴이 있다.

7.1. 흐름

핸들러가 ChatService::emit_write_behind_event() 호출.
이벤트 타입(chat_msg, login, join)과 데이터를 JSON이 아닌 Key-Value 쌍으로 변환.
REDIS XADD stream:events * type chat_msg user bvm ... 명령 실행.
끝. (DB 저장을 기다리지 않음 -> 매우 빠름)

7.2. 컨슈머 (Worker)

별도의 프로세스(또는 스레드)가 XREADGROUP으로 스트림을 읽어와서 Postgres에 INSERT 한다. DB가 일시적으로 느려지거나 죽어도, Redis Stream에 데이터가 쌓일 뿐 서비스는 멈추지 않는다.

현재 Redis는 단일 인스턴스이므로 SPOF이기 때문에 클러스터링이 필요하다.

8. 분산 상태 관리 (Redis)

Redis는 단순 캐시가 아니라 제2의 메모리이다.

server:registry:{id}: 서버 생존 신고 (Heartbeat).
room:users:{room}: 해당 방에 누가 있는지 (Set). user_count 조회용.
room:password:{room}: 방 비밀번호 (Single Source of Truth).
presence:user:{uid}: 유저가 온라인인지 여부.
fanout:room:{room}: 채팅 메시지 Pub/Sub 채널.

9. Configuration & Metrics

9.1. Environment Variables

GATEWAY_ID: 나를 관리하는 Gateway 식별자.
WRITE_BEHIND_ENABLED: 1이면 활성화.
REDIS_URI: tcp://127.0.0.1:6379.
DB_DSN: Postgres 접속 정보.

9.2. Prometheus Metrics (`/metrics`)

chat_session_active: 현재 접속자 수 (Gauge).
chat_job_queue_depth: 처리 대기 중인 작업 수 (Gauge). 위험 신호 감지용.
chat_dispatch_total: 처리한 패킷 총량 (Counter).
chat_db_job_failed_total: DB 저장 실패 횟수 (Counter).

10. TODO

SPOF 처리
- Redis
- Gateway
- PostgreSQL
- 위 셋 다 단일 인스턴스임!
인증 및 보안 관련 구현
k8s를 통한 오케스트레이션

내가 구두로 지시해 AI가 작성한 코드긴 하지만, 그걸 내가 확실하게 짚고 갈 수 있느냐는 다른 문제다.

내가 생각하는 코드보다 더 깔끔한 코드를 대부분의 상황에서 작성해 주기 때문에 좋은 공부가 된다.

다음엔 클라이언트에 대해 얘기해 보자.

AI로 MSA 서버 만들어 보기 #1 : Core

BVM — Wed, 3 Dec 2025 18:02:28 +0900

백엔드란 어렵다.

특히 그게 IOCP라면 더욱더.

네트워크에 대한 지식뿐만 아니라, IOCP에 대해서도 이해가 필요하다.

이전에 ``Boost.Asio``를 통한 서버 공부를 진행했지만, 마음처럼 되지 않았다.

하지만 지금이 어떤 시대인가?
대 AI 시대가 열렸고, 엄청난 성능의 모델이 등장했다.

지금이라면 내가 원하는 형태의 코드를 AI가 작성해 줄 수 있고, 실제로 동작하는 그러한 코드들을 보며 공부할 수 있다.

때는 ``GPT-5``가 갓 나왔을 때. "AI로 ``Boost.Asio``를 기반으로 한 Windows와 Linux 양쪽에서 사용할 수 있는 멀티 플랫폼 서버를 만들어 보자"라고 생각했다.

시작은 ``GPT-5``였지만, ``GPT-5.1``, ``Claude Sonnet 4.5``, ``Gemini 2.5 Pro``, ``Gemini 3.0 Pro``의 다양한 모델을 사용했다.

대부분의 형태는 ``Codex-CLI``를 통해 ``GPT-5``를 사용하며 잡았고, 나머지 모델은 자잘한 작업에 사용했다.

특히 Antigravity가 출시된 이후로는 ``Gemini 3.0 Pro``를 주로 사용하고, 일부 작업은 ``Sonnet 4.5``로 진행했다.

거의 대부분을 과정을 ``구두지시``로 진행했고, AI가 갈피를 못 잡을 땐 직접 손을 댔다.

쓰면서 느끼는 건...

"이야 이거 참 인간 개발자가 많이 필요 없겠는데?"였다.

생성형 AI로 패러다임이 전환된 지 얼마 되지도 않았다.

그런데도 벌써 이런 엄청난 성능이다.

``Gemini 3.0``은 그야말로 게임 체인저다.

나중엔 극소수의 천재 개발자가 이끌어가는 형태를 자연스럽게 상상하게 된다.

그래도 그 시대가 오기 전까진 열심히 공부해 보자.

먼저 프로젝트 전체의 아키텍처부터 확인해 보자.

1. 전체 아키텍처

이런 식으로 구성돼 있다.

MSA를 위한 구색만 갖춘 수준이다.

현재는 Dokcer Compose를 통해 리눅스에 올려서 테스트하고 있다.

나중에 k8s로 넘겨볼지도 모르겠다.

어떻게든 코어 라이브러리를 전반적으로 사용하게 해 꼬임을 방지하고자 했다.

일종의 간단한 서버엔진을 흉내 내 본 것이기도 하다.

일단 여기선 ``Core``에 대해 얘기해 보자.

2. Core

2-1. 아키텍처

Core의 아키텍처를 간략히 표현한 것이다.

서버 코어로써의 최소한의 기능만 하고 있다고 볼 수 있다.

네트워크 / 메모리 / 동시성 관리를 모두 코어의 기능을 통해 수행한다.

서버는 이 코어에 전적으로 의존하고 있다.

3. Network

Network에서 모든 비동기 I/O 처리와 통신을 처리한다.

쌩으로 IOCP를 구현한 것이 아닌, Boost.Asio를 통해 구현되었으므로 ``io_context``에 기반한다.

3-1. Hive

``Hive`` 클래스는 ``io_context``의 수명 주기를 관리하는 핵심 클래스이다

``io_context``는 등록된 작업이 없으면 ``run()``이 리턴되어 종료돼 버린다.

따라서 이를 ``executor_work_guard``를 사용해 종료를 방지한다.

// core/src/net/hive.cpp

Hive::Hive(io_context& io)
    : io_(io)
    , guard_(boost::asio::make_work_guard(io_)) { 
    // make_work_guard를 통해 io_context에 "가상의 작업"을 등록하여,
    // 실제 I/O 작업이 없더라도 run()이 리턴하지 않고 대기하도록 합니다.
}

void Hive::run() {
    // 이 함수를 호출한 스레드는 I/O 이벤트 루프의 워커가 됩니다.
    // 여러 스레드에서 동시에 호출하면 Thread-Pool 기반의 Proactor 패턴이 됩니다.
    stopped_.store(false, std::memory_order_relaxed);
    io_.run();
}

void Hive::stop() {
    // 명시적으로 stop()을 호출해야만 guard가 해제되고 io_context가 종료됩니다.
    // 이는 서버의 Graceful Shutdown을 구현하는 기초가 됩니다.
    guard_.reset();
    io_.stop();
}

``Hive``는 FF14의 서버 에뮬레이팅 프로젝트인 Sapphire에 있는 구조를 가져온 것이다.

https://github.com/SapphireServer/Sapphire/blob/master/src/common/Network/Hive.h

Sapphire/src/common/Network/Hive.h at master · SapphireServer/Sapphire

A Final Fantasy XIV 4.0+ Server Emulator written in C++ - SapphireServer/Sapphire

github.com

3-2. Session

``Session`` 클래스는 단일 TCP 연결의 생명 주기화 통신 처리를 담당한다.

멀티 스레드 환경에서 단일 소켓에 대한 동시 접근은 레이스 컨디션을 유발하고 데이터 정합성을 위협한다.

이를 방지하기 위해 ``mutex``를 사용하게 되지만, 이 또한 레이스 컨디션을 유발한다.

따라서 ``strand``를 사용해 ``Lock-Free``를 구현한다.

``strand``는 해당 세션 바인딩 된 모든 것들이 순차 실행 됨을 보장하기 때문이다.

따라서 명시적인 Lock 없이도 작업을 처리할 수 있게 된다.

// server/core/net/session.cpp

void Session::async_send(BufferManager::PooledBuffer data, size_t packet_size) {
    // asio::dispatch를 사용하여 작업을 strand로 전달합니다.
    // 현재 스레드가 이미 strand 안에 있다면 즉시 실행되고, 아니면 큐에 넣습니다.
    asio::dispatch(strand_, [self = shared_from_this(), data = std::move(data), packet_size]() mutable {
        if (self->stopped_) return;

        // 여기는 strand에 의해 보호되는 영역이므로, Mutex 없이 안전하게 큐에 접근합니다.
        bool kick_write = self->send_queue_.empty();
        self->send_queue_.push({std::move(data), packet_size});

        if (kick_write) {
            self->do_write();
        }
    });
}

그리고 성능을 위해 메모리 처리에도 신경 써야 하는데, 이때 특히 복사 비용에 대한 고민이 필요하다.

``Session``은 별도 버퍼 관리 클래스와의 연계를 통해 ``Zero-Copy``에 가깝도록 했다.

Read
- ``BufferManager``에서 할당받은 버퍼를 ``async_read``에 직접 제공하여, 커널에서 유저로의 복사 외의 추가 복사를 방지한다.
Write
- 직렬화된 데이터가 담긴 ``PooledBuffer``의 소유권을 큐로 이동시켜 복사를 방지한다.

// server/core/net/session.cpp

void Session::do_read_header() {
    // 메모리 풀에서 버퍼를 하나 가져옵니다. (O(1))
    read_buf_ = buffer_manager_.Acquire(); 

    // 소켓이 이 버퍼에 직접 데이터를 쓰도록 합니다.
    asio::async_read(socket_, asio::buffer(read_buf_.get(), server::core::protocol::k_header_bytes),
        asio::bind_executor(strand_, [this, self](const error_code& ec, std::size_t n) {
            if (!ec) {
                // ... 헤더 디코딩 ...
                do_read_body(header_.length);
            }
        }));
}

3-3. Protocol & Packets

서버와 클라이언트 간의 통신은 명확하게 정의된 패킷(Packet) 단위로 이루어진다.
TCP는 스트림 기반 프로토콜이므로 데이터의 경계가 없지만, 애플리케이션 레벨에서는 메시지 경계가 필요하다.
이를 위해 Length-Prefixed 방식을 변형한 헤더 구조를 사용한다.

1) Packet Structure

모든 패킷은 14바이트의 고정 길이 헤더와 가변 길이 바디로 구성된다.
네트워크 전송 시에는 표준인 Big-Endian 엔디안을 따른다.

Offset	Field	Type	Description
0	Length	uint16	바디 데이터의 길이 (헤더 제외)
2	MsgID	uint16	메시지 식별자 (Opcode)
4	Flags	uint16	압축, 암호화 여부 등의 플래그
6	Sequence	uint32	패킷 순서 보장 및 중복 방지
10	Timestamp	uint32	전송 시간 (Latency 측정용)

이러한 구조는 다음과 같은 이점을 제공한다.

명확한 경계: Length 필드를 통해 다음 패킷의 시작 위치를 정확히 알 수 있다.
보안성: 바디를 읽기 전에 헤더를 먼저 검증하여, 비정상적으로 큰 패킷이나 잘못된 프로토콜을 사전에 차단할 수 있다.
관측성: Sequence와 Timestamp를 통해 패킷 유실이나 지연 시간을 추적할 수 있다.

2) Packet Processing Flow

패킷 처리는 Double-Read 전략을 취한다.
즉, 헤더를 먼저 읽고(14바이트), 그 결과에 따라 바디를 읽는다.

// core/src/net/session.cpp

void Session::do_read_header() {
    // 1. 14바이트 고정 길이 헤더 읽기 요청
    asio::async_read(socket_, asio::buffer(read_buf_.get(), 14),
        [this](const error_code& ec, size_t n) {
            if (!ec) {
                // 2. 헤더 디코딩
                server::core::protocol::decode_header(read_buf_.get(), header_);

                // 3. 유효성 검사 (너무 큰 패킷 차단)
                if (header_.length > MAX_PAYLOAD) {
                    stop(); 
                    return;
                }

                // 4. 바디 읽기 시작
                do_read_body(header_.length);
            }
        });
}

void Session::do_read_body(size_t body_len) {
    if (body_len == 0) {
        // 바디가 없는 패킷(예: Ping)도 처리 가능
        dispatch(header_.msg_id, {});
        do_read_header();
        return;
    }

    // 5. 바디 길이만큼 읽기 요청
    asio::async_read(socket_, asio::buffer(read_buf_.get(), body_len),
        [this](const error_code& ec, size_t n) {
            if (!ec) {
                // 6. 핸들러로 전달
                dispatch(header_.msg_id, read_buf_);

                // 7. 다음 패킷 대기
                do_read_header();
            }
        });
}

3) Dispatcher

수신된 패킷은 Dispatcher를 통해 적절한 핸들러로 전달된다.
std::unordered_map을 사용하여 O(1) 속도로 핸들러를 찾으며, 예외가 발생하더라도 해당 세션만 종료되도록 격리하여 서버 전체의 안정성을 보장한다.

// core/src/net/dispatcher.cpp

bool Dispatcher::dispatch(uint16_t msg_id, Session& s, span<const uint8_t> payload) {
    if (auto it = table_.find(msg_id); it != table_.end()) {
        try {
            it->second(s, payload); // 핸들러 실행
            return true;
        } catch (...) {
            // 핸들러 오류가 서버 전체를 죽이지 않도록 방어
        }
    }
    return false;
}

3-4. Flow Control (Backpressure)

비동기 서버에서 가장 흔히 발생하는 문제는 Producer-Consumer 속도 불균형이다.
클라이언트의 인터넷 상태가 좋지 않아 데이터를 빨리 받지 못하는데, 서버가 계속해서 데이터를 보낸다면 어떻게 될까?
Session의 송신 큐(Send Queue)에 데이터가 무한히 쌓이다가 결국 OOM(Out Of Memory)으로 서버가 죽게 된다.

이를 방지하기 위해 송신 큐에 한계점(High Watermark)을 설정하고, 이를 초과하면 가차 없이 세션을 끊어버리는 Backpressure 메커니즘을 적용했다.

// core/src/net/session.cpp

void Session::async_send(...) {
    // ...
    // 현재 큐에 쌓인 데이터 크기가 설정된 한계(예: 10MB)를 초과하면
    if (queued_bytes_ + packet_size > options_->send_queue_max) {
        log::warn("Send queue limit exceeded; stopping session");
        stop(); // 세션 강제 종료 (보호 차원)
        return;
    }
    // ...
}

3-5. Connection Setup

연결이 맺어지자마자 바로 비즈니스 로직을 수행하지는 않는다.
가장 먼저 MSG_HELLO 패킷을 교환하여 서로의 버전을 확인하고 기능을 협상한다.

Handshake: 서버는 연결 직후 MSG_HELLO를 보내 프로토콜 버전, 지원 기능(압축 등), Heartbeat 주기를 알린다.
Heartbeat: 아무런 통신이 없으면 연결이 죽었는지 알 수 없으므로, 주기적으로 MSG_PING을 보내 연결 생존을 확인한다.

// server/core/net/session.cpp

void Session::start() {
    send_hello();       // 1. 헬로 패킷 전송
    do_read_header();   // 2. 수신 대기 시작
    arm_read_timeout(); // 3. 읽기 타임아웃 타이머 가동 (Zombie Connection 방지)
    arm_heartbeat();    // 4. 하트비트 타이머 가동
}

3-6. Security & Optimization

서버 코어는 강력한 보안과 최적화 기능을 기본적으로 내장하고 있다.

Cipher (AES-256-GCM): OpenSSL 기반의 Cipher 클래스를 제공하여, 데이터의 기밀성과 무결성을 동시에 보장한다. 단순 암호화뿐만 아니라 인증(Authentication)까지 수행하므로 패킷 변조를 원천 차단한다.

// core/src/security/cipher.cpp

std::vector<uint8_t> Cipher::encrypt(std::span<const uint8_t> plaintext, ...) {
    // OpenSSL EVP Interface 사용
    ScopedCtx ctx(EVP_CIPHER_CTX_new());

    // AES-256-GCM 초기화
    EVP_EncryptInit_ex(ctx.get(), EVP_aes_256_gcm(), nullptr, nullptr, nullptr);
    EVP_EncryptInit_ex(ctx.get(), nullptr, nullptr, key.data(), iv.data());

    // 암호화 수행
    EVP_EncryptUpdate(ctx.get(), ciphertext.data(), &out_len, plaintext.data(), ...);
    EVP_EncryptFinal_ex(ctx.get(), ciphertext.data() + out_len, &final_len);

    // Authentication Tag 추출 (변조 방지 핵심)
    EVP_CIPHER_CTX_ctrl(ctx.get(), EVP_CTRL_GCM_GET_TAG, TAG_SIZE, ...);

    return ciphertext;
}

Compressor (LZ4): LZ4 기반의 Compressor 클래스를 제공한다. 압축 효율이 매우 높으며, 이를 통해 대역폭 비용을 획기적으로 절감할 수 있다.

// core/src/compression/compressor.cpp

std::vector<uint8_t> Compressor::compress(std::span<const uint8_t> data) {
    // 압축 후 최대 크기 계산
    int max_dst_size = LZ4_compressBound(static_cast<int>(data.size()));
    std::vector<uint8_t> compressed(max_dst_size);

    // LZ4 기본 압축 수행
    int compressed_size = LZ4_compress_default(
        reinterpret_cast<const char*>(data.data()),
        reinterpret_cast<char*>(compressed.data()),
        static_cast<int>(data.size()),
        max_dst_size
    );

    compressed.resize(compressed_size);
    return compressed;
}

4. Concurrency

``Concurrency`` 클래스는 스레드 관리와 스케줄링을 담당한다.

단순하게 말하자면 병렬 처리를 가능케 하는 클래스이다.

4-1. ThreadManager

``ThreadManager``는 워커 스레드의 생명주기를 관리한다.

실제 로직에서 직접 ``std::thread``를 다루는 일이 없어야 하고, 스레드가 모든 작업을 제대로 처리할 수 있게 관리해 데이터 유실도 방지한다.

// server/core/concurrent/thread_manager.cpp

void ThreadManager::Start(int num_threads) {
    stopped_.store(false, std::memory_order_relaxed);
    threads_.reserve(num_threads);
    for (int i = 0; i < num_threads; ++i) {
        threads_.emplace_back([this] { WorkerLoop(); });
    }
}

void ThreadManager::Stop() {
    bool expected = false;
    if (!stopped_.compare_exchange_strong(expected, true, std::memory_order_acq_rel)) {
        return;
    }

    job_queue_.Stop(); // Pop()에서 대기 중인 워커들을 모두 깨워 종료 신호를 전달합니다.

    for (auto& t : threads_) {
        if (t.joinable()) {
            t.join();
        }
    }
    threads_.clear();
}

// 각 워커 스레드는 JobQueue::Pop()이 nullptr를 반환할 때까지 반복 실행됩니다.
void ThreadManager::WorkerLoop() {
    while (!stopped_.load(std::memory_order_acquire)) {
        Job job = job_queue_.Pop();
        if (!job) { // nullptr 작업이 오면 종료합니다.
            break;
        }
        job();
    }
}

4-2. JobQueue

``JobQueue``는 순차적 실행을 보장하는 FIFO 큐이다.

이는 ``std::mutex``와 ``std::condition_variable``을 사용하는 전형적 Producer - Consumer 패턴이다.

특정 단위마다 ``JobQueue``를 사용해 순서를 보장하고 Lock 관리에서 어느 정도 해방시켜 준다.

// server/core/concurrent/job_queue.cpp

void JobQueue::Push(Job job) {
    {
        std::lock_guard<std::mutex> lock(mutex_);
        jobs_.push(std::move(job));
        // 메트릭 기록: 현재 큐 깊이
        runtime_metrics::record_job_queue_depth(jobs_.size());
    }
    // 대기 중인 워커 스레드 하나를 깨웁니다.
    cv_.notify_one();
}

Job JobQueue::Pop() {
    std::unique_lock<std::mutex> lock(mutex_);
    // 큐에 작업이 들어오거나 종료 신호가 올 때까지 대기합니다.
    cv_.wait(lock, [this] { return !jobs_.empty() || stopping_; });

    if (stopping_ && jobs_.empty()) {
        runtime_metrics::record_job_queue_depth(jobs_.size());
        return nullptr; // nullptr이면 종료 신호로 간주합니다.
    }

    Job job = std::move(jobs_.front());
    jobs_.pop();
    runtime_metrics::record_job_queue_depth(jobs_.size());
    return job;
}

4-3. TaskScheduler

``TaskScheduler`` 지연이나 주기적 실행이 필요한 작업들을 관리한다.

수만 또는 수십만 이상의 타이머가 필요한 서버에서 각 작업마다 ``asio::steady_timer``를 생성해 사용하는 것은 엄청나게 큰 오버헤드가 될 것임이 자명하다.

따라서 단일 ``std::priority_queue``를 사용해 모든 작업들을 관리한다.

// server/core/concurrent/task_scheduler.cpp

void TaskScheduler::schedule(Task task, Clock::duration delay) {
    std::lock_guard<std::mutex> lock(mutex_);
    // 만료 시간(due)을 기준으로 정렬되는 우선순위 큐에 삽입합니다.
    delayed_.push(DelayedTask{Clock::now() + delay, std::move(task)});
}

std::size_t TaskScheduler::poll(std::size_t max_tasks) {
    // ...
    auto now = Clock::now();
    // 현재 시간보다 이전에 만료된 작업들을 모두 꺼내서 실행 대기열(ready_)로 옮깁니다.
    while (!delayed_.empty() && delayed_.top().due <= now) {
        ready_.push(std::move(delayed_.top().task));
        delayed_.pop();
    }
    // ...
}

5. Memory & Utils

5-1. MemoryPool

``MemoryPool``은 고정 크기 메모리 블록의 할당 및 해제를 담당한다.

빈번한 동적 할당은 메모리 파편화를 유발할 가능성이 크다.

``MemoryPool``을 통해 사전에 큰 청크를 할당하고, 그 청크를 쪼개 관리하여 파편화를 방지한다.

그리고 가용 메모리 블록의 포인터들을 스택으로 관리해 O(1)의 접근속도를 보장한다.

// core/src/memory/memory_pool.cpp

class MemoryPool {
    std::vector<std::byte> memoryChunk_; // 실제 메모리가 할당된 공간
    std::stack<void*> freeList_;         // 사용 가능한 블록들의 포인터 스택

    void* Acquire() {
        std::lock_guard<std::mutex> lock(mutex_);
        if (freeList_.empty()) return nullptr; // 풀 고갈
        void* ptr = freeList_.top();
        freeList_.pop();
        return ptr;
    }

    void Release(void* ptr) {
        std::lock_guard<std::mutex> lock(mutex_);
        freeList_.push(ptr);
    }
};

5-2. Dispatcher

``Dispatcher``는 수신된 패킷의 Opcode에 따라 그에 맞는 핸들러 함수를 호출한다.

``std::unordered_map``을 사용하여 O(1)의 Opcode 조회 성능을 보장한다.

``std::span``을 사용해 버퍼 길이를 초과하는 접근을 막는다.

// core/src/net/dispatcher.cpp

class Dispatcher {
    using handler_t = std::function<void(Session&, std::span<const std::uint8_t>)>;
    std::unordered_map<std::uint16_t, handler_t> table_;

    bool dispatch(std::uint16_t msg_id, Session& s, std::span<const std::uint8_t> payload) const {
        if (auto it = table_.find(msg_id); it != table_.end()) {
            it->second(s, payload); // 핸들러 호출
            return true;
        }
        return false; // 알 수 없는 메시지 ID
    }
};

6. Observability

서비스 환경에서의 디버깅과 모니터링을 위한 유틸리티를 제공한다.

6-1. Logging

``server::core::log``를 통해 Thread-Safe 로깅을 제공한다.

싱글톤 패턴을 통해 전체에서 단 하나의 로깅 인스턴스만 사용하도록 한다.

// core/src/util/log.cpp

class AsyncLogger {
public:
    // 로그 메시지를 큐에 넣고 워커 스레드를 깨웁니다.
    // 이 함수는 메인 로직 스레드에서 호출되므로 최대한 빨리 리턴해야 합니다.
    void push(const std::string& msg) {
        {
            std::lock_guard<std::mutex> lock(mutex_);
            queue_.push(msg);
        }
        cv_.notify_one();
    }

private:
    // 생성자는 private으로 선언하여 싱글톤 패턴을 강제합니다.
    AsyncLogger() : stop_(false) {
        // 백그라운드 워커 스레드를 시작합니다.
        worker_ = std::thread([this] { worker_loop(); });
    }

    // 소멸자에서 워커 스레드가 안전하게 종료되도록 대기합니다.
    ~AsyncLogger() {
        // ...
    }

    // 워커 스레드에서 실행될 메인 루프입니다.
    void worker_loop() {
        while (true) {
            std::string msg;
            // ...
        }
    }

    std::mutex mutex_; // 큐 접근을 위한 뮤텍스
    std::condition_variable cv_; // 큐 상태 변경을 알리는 조건 변수
    std::queue<std::string> queue_; // 로그 메시지를 저장하는 큐
    std::thread worker_; // 로그 처리를 담당하는 백그라운드 스레드
    bool stop_; // 스레드 종료를 위한 플래그

    // AsyncLogger 인스턴스를 얻기 위한 friend 함수 선언
    friend AsyncLogger& get_logger();
};

6-2. Metrics

Prometheus에 제공하기 위한 메트릭 수집 인터페이스를 제공한다.

``Counter``, ``Gauge``, ``Histogram`` 인터페이스를 제공한다.

// core/include/server/core/metrics/metrics.cpp

struct NoopCounter final : Counter { void inc(double, Labels) override {} };
struct NoopGauge final : Gauge { void set(double, Labels) override {} void inc(double, Labels) override {} void dec(double, Labels) override {} };
struct NoopHistogram final : Histogram { void observe(double, Labels) override {} };

std::mutex& mu() { static std::mutex m; return m; }
std::unordered_map<std::string, NoopCounter>& counters() { static std::unordered_map<std::string, NoopCounter> m; return m; }
std::unordered_map<std::string, NoopGauge>& gauges() { static std::unordered_map<std::string, NoopGauge> m; return m; }
std::unordered_map<std::string, NoopHistogram>& histos() { static std::unordered_map<std::string, NoopHistogram> m; return m; }
}

// Prometheus exporter가 붙지 않은 초기 단계에서도 공통 metrics API를 호출할 수 있도록
// Noop 객체를 미리 준비해두고, 실제 exporter가 연결되면 즉시 교체되는 구조다.
// 이를 통해 비즈니스 로직은 메트릭 시스템의 유무와 상관없이 항상 동일하게 동작한다.
Counter& get_counter(const std::string& name) {
    std::lock_guard<std::mutex> lk(mu());
    return counters().try_emplace(name).first->second;
}

// ...


// 실제 로직에서 사용할 때
auto& req_count = server::core::metrics::get_counter("requests_total");
req_count.inc(1.0, {{"method", "login"}});

7. 결론

``Boost.Asio``는 정말 엄청난 도구다.

이전에 쌩으로 IOCP 서버를 개발하는 공부를 해 본 입장에서, 개발에 엄청난 편의성을 제공한다.

사실상 패킷 처리, 메모리 관리, 스케줄링, 로깅, 텔레메트리에만 신경을 쓰면 되는 수준이다.

아니 이 정도면 많은 부분인가?

로우레벨에 대해 신경 쓸 부분이 줄었다는 것은 실수를 많이 줄일 수 있다는 뜻이기도 하니 여하튼 좋다.

다음엔 서버에 대한 내용이다.

제11회 빅데이터분석기사 필기 짧은 후기

BVM — Sun, 21 Sep 2025 16:47:58 +0900

내가 이걸 공부하게 될 줄이야.

어쩌다 불가항력으로 인해 공부하게 됐다.

공부해서 손해 볼 건 없지.

언젠간 내 인생에 도움이 되지 않겠나?

6월 즈음에 책을 주문해 공부를 시작했다.

정보처리기사 공부할 때를 생각하고 이걸 빨리 보고 다른 출판사의 교재도 보겠노라 생각했었다.

생각해 보면 내 전공이 전공인 만큼 정보처리기사는 공부 요구량이 대단히 적었다.

게으름 이슈도 있고 통계라곤 대학 시절 1학기만 들은 것이 다였다.

하지만 그것조차 제대로 하지 못했기에 저거 다 보는 것만으로도 벅찼다.

한 마디로 요약하자면 "아는 게 하나도 없는 노 베이스" 상태였다는 것이다.

잘 기억이 나지 않거나 처음 보는 개념들을 열심히 외워야 했다.

CRISP-DM 방법론의 진행 순서는 뭐고 데이터의 품질 지표는 뭐고...

뭐 중간에 익숙한 개념들도 있어서 잠시 쉬는 시간은 있었다.

그렇게 어찌저찌 전체 교재를 다 봤다.

기출과 모의고사도 열심히 풀었고, 출판사에서 제공하는 CBT도 열심히 풀었다.

과락은 1~2번 있었던 것 같다.

그래도 거의 대부분 합격선이었고, 실전도 기출에서 크게 벗어나지는 않을 것이라 생각했다.

모든 문제를 한번 쫙 푸는데 1시간도 걸리지 않았기에 점검할 시간도 충분했다.

그렇게 약간의 자신을 가지고 9월 6일에 시험장으로 향했다.

시험 시작 전에 파본을 확인하는 때에 문제들이 슬쩍 보이는 것을 보니...

"아 씨발 좆된거 같은데?"

라고 생각했다.

그래도 토탈 80문제고, 그건 일부였기에 그건 뭐 그냥 버리는 문제라고 합리화를 하며 시험이 시작됐다.

1과목은 무난했다.

2, 3과목이 문제였다.

책에서 본 적 없는 개념들이 쏟아져 나왔고, 공부한 개념이었지만 기억이 잘 안나는 것도 많았다.

공부한 개념들을 묻는 문제들은 개념에 대한 깊은 이해를 요구했다.

각 개념들의 미묘한 차이까지 확실히 알아야 정답을 제대로 건들 수 있는 문제들이었다고 생각한다.

진짜 문제들은 듣도 보도 못한 것들을 묻는 문제들이었다.

소거법을 쓰기도 어려웠다. 이건 진짜 아닌 것 같다고 생각한 보기를 제외해도 3개 중에서 찍어야 하니까.

전후로 유사한 개념을 묻는 문제도 없었기 때문에 대조도 할 수 없었다.

그래서 2, 3과목은 거의 60% 이상을 마킹하지 못하고 일단 넘어갔다.

이기적 교재의 내용이 부실한 건가? 다른 출판사의 교재엔 이 내용들이 나왔을 수도 있지 않을까?라는 생각을 했다.

4과목은 할만했다.

숨통이 트이는 느낌.

이러면 1과목과 4과목에서 번 점수로 2, 3과목을 커버쳐야 하는 상황.

시험 시간을 거의 최후의 최후까지 쓰며 남은 문제들을 열심히 찍었다.

2번이 너무 많이 나와서 "출제를 장난치듯이 하네"라는 생각도 했다.

시험이 종료되고 나와서 이기적 카페에서 후기들을 확인했다.

확실히 어려웠다는 평.

"음~ 나만 좆박은 게 아니구만~" 이라고 생각했다.

뭐 내가 할 수 있는 게 없으니 그냥 기다리기만 했다.

난 2, 3과목 어디서 과락이 나거나 턱걸이로 합격했으리라 생각했다.

그렇게 19일이 찾아왔다.

전날에 신경이 쓰여서 잠에 들기가 어려웠다.

발표 직전엔 아주 긴장이 되더군.

그렇게 발표 페이지로 들어가니...

어????

이거 뭐지?

상세 결과를 보자.

하~~~~

됐다~~~~

1, 4과목이 내 생각보다 점수가 잘 나왔다.

2, 3과목도 과락에 근접하지 않았다.

턱걸이 합격을 예상했는데, 70점으로 여유롭게 합격했다.

안도의 깊은 한숨이 쫙 나오는 게 아니겠나.

큰 고비를 넘었다는 생각에 기분이 썩 괜찮았다.

아직 실기가 남았지만 공부할 시간은 충분하다고 생각한다.

파이썬이야 뭐 익숙하고 pandas도 사용은 해 봤다.

help 명령어도 쓸 수 있으니 필기보다 할만하지 않겠는가.

한방에 실기 합격까지 가보자.

이기적 교재로 공부하는 것.

나쁜 선택은 아니라고 생각한다.

구매 인증 시 제공하는 자료들도 도움이 됐다.

타 출판사 교재를 본 적은 없지만, 일단 내가 이기적으로 공부해서 합격했으니 된 것 아니겠나?

사실상의 노 베이스 상태로 공부해서 한방에 합격했으니 남에게 추천해 줄 수 있을 것 같다.

이제 보니 짧은 후기가 아닌가?

조금 길어졌다.

[JS] 디스코드 봇에 PLL 정보 출력하게 하기

BVM — Tue, 4 Mar 2025 17:38:15 +0900

KupoBot이라는 FF14 관련한 많은 기능을 제공하는 봇이 있다.

그런데 이것이 요즘은 꽤 답답하다.

시대가 언젠데 슬래시 커맨드도 안되고...

주로 요청하게 되는 정보는 점검과 PLL 관련 정보인데,

아마도 관리자가 직접 정보를 삽입하는 것 같다.

공지가 올라온 지 한참 지났음에도 정보를 가져오지 못한다.

점검 같은 경우는 정규식으로 RSS Feed를 파싱해 최신 점검 정보를 가져오게 해 놨다.

한번 파싱 하면 그걸 저장해 놨다가 재활용한다.

PLL도 그런 식으로 파싱 할 수 있으므로 똑같은 흐름으로 명령어를 만들게 됐다.

1. 그전에 점검 파싱부터

먼저 점검 정보 파싱이 어떻게 이루어지는지 보자.

async function getMaintData() {
  const feedUrl = "https://jp.finalfantasyxiv.com/lodestone/news/news.xml";
  const now = Date.now() / 1000;

  try {
    const savedData = await loadData();
    if (savedData.MAINTINFO?.end_stamp > now) {
      return savedData;
    }

    const feed = await parser.parseURL(feedUrl);
    const targetItem = feed.items.find((item) => item.title?.startsWith("全ワールド"));
    if (!targetItem) return null;
# ...

모든 FF14의 전체 점검 공지는 「全ワールド」라는 접두어를 가진다.

이를 기반해서 해당하는 점검 피드를 찾는다.

그럼 현재 기준으로 다음의 점검 공지를 찾을 수 있다.

[メンテナンス]全ワールドメンテナンス作業のお知らせ(3/4)

그럼 내용에서 시간 정보를 뽑아내야 한다.

중간 내용은 필요 없고 가장 아래의 시간 정보만 정규식으로 뽑아낸다.

function extractMaintenanceInfo(item) {
  const startTimeRegex = /日　時：(\d{4}年\d{1,2}月\d{1,2}日\(.\)) (\d{1,2}:\d{2})より/;
  const endTimeRegex = /(\d{4}年\d{1,2}月\d{1,2}日\(.\))? ?(\d{1,2}:\d{2})頃まで/;
  const startTimeMatch = item.content.match(startTimeRegex);
  const endTimeMatch = item.content.match(endTimeRegex);
  if (!startTimeMatch || !endTimeMatch) return null;

  // 중복되는 moment.tz 호출을 헬퍼 함수로 분리
  const parseDate = (dateStr, timeStr) =>
    moment.tz(`${dateStr} ${timeStr}`, "YYYY年MM月DD日(ddd) HH:mm", "ja", "Asia/Tokyo").unix();

  const startTime = parseDate(startTimeMatch[1], startTimeMatch[2]);
  const endTime = endTimeMatch[1]
    ? parseDate(endTimeMatch[1], endTimeMatch[2])
    : parseDate(startTimeMatch[1], endTimeMatch[2]);

  return { start_stamp: startTime, end_stamp: endTime };
}

이런 식으로 시간을 뽑아서 유닉스 타임스탬프 형태로 리턴한다.

이걸 바탕으로 디스코드 임베드에 정보들을 넣어 보여주게 된다.

이런 식으로 임베드로 출력하게 된다.

2. PLL도 같은 식으로

PLL은 다음과 같은 형식의 제목을 가진다.

[「第n回 FFXIV PLL」m月dd日（金）放送決定！]

그리고 가장 중요한 건 FFXIV PLL이 포함되는 부분이다.

저 부분은 형태가 바뀌지 않는다.

이걸 통해서 피드에서 PLL 관련 정보들을 가져올 수 있다.

현재 기준으로 다음의 PLL 공지를 확인할 수 있다.

「第86回 FFXIV PLL」3月14日（金）放送決定！

역시 필요한 건 시간 정보뿐이다.

// 회차 번호 추출
const $ = cheerio.load(summary, { decodeEntities: false });
const h3Element = $("h3.mdl-title__heading--lg").first();
let roundNumber = "";
const roundMatch = (h3Element.text() || title).match(/第(\d+)回/);
if (roundMatch) {
  roundNumber = roundMatch[1];
}

// 방송 시작 시각 추출 (전각 괄호 대응)
let start_stamp = null;
const dateRegex = /(\d{4}年\d{1,2}月\d{1,2}日（[^）]+）)\s?(\d{1,2}:\d{2})頃?～/;
const dateMatch = summary.match(dateRegex);
if (dateMatch) {
  // dateMatch[1] = "2025年3月14日（金）", dateMatch[2] = "19:00"
  const dateStrClean = dateMatch[1].replace(/（[^）]+）/, ""); // → "2025年3月14日"
  const finalStr = `${dateStrClean} ${dateMatch[2]}`; // → "2025年3月14日 19:00"
  const parsed = moment.tz(finalStr, "YYYY年M月D日 HH:mm", "Asia/Tokyo");
  if (parsed.isValid()) {
    start_stamp = parsed.unix();
  }
}

정규식을 통해 현재 몇 회 차인지, 진행 시간은 언제인지 추출한다.

let fixedTitle = "제 XX회 프로듀서 레터 라이브 X월 XX일 방송 결정!";
if (start_stamp) {
  const formattedDate = moment.unix(start_stamp).tz("Asia/Seoul").format("M월 D일");
  const roundText = roundNumber ? `제 ${roundNumber}회` : `제 XX회`;
  fixedTitle = `${roundText} 프로듀서 레터 라이브 ${formattedDate} 방송 결정!`;
}

그리고 타이틀을 추출한 정보에 맞게 수정한다.

// 캐싱 만료 시간 설정
const expireTime = Math.floor(now + 12 * 60 * 60);
const newData = {
  PLLINFO: {
    fixedTitle,
    url: link,
    start_stamp,
    expireTime,
  },
};

await saveData(newData);
return newData.PLLINFO;

추후에 현재 저장된 정보가 만료된 것인지 판별하기 위해 만료 시간을 계산해 같이 캐싱한다.

추출한 정보를 통해 점검 정보와 유사하게 이런 식으로 출력할 수 있다.

답답하면 내가 만들면 되는 게 아닌가?

그래서 만들었다.
훨씬 보기도 좋다.

[TIL #35] 데드락에 죽다 살다

BVM — Sun, 15 Dec 2024 20:24:57 +0900

현재 진행 중인 프로젝트는 레이드 컨텐츠 입장을 위해 큐를 사용한다.

최초로 개발하며 개념 검증 시엔 원시적인 큐만 사용했고, 이는 동시성 문제어 이어질 수 있었다.

따라서 Bull을 도입하게 됐다.

하지만 Bull만 도입한다고 되는 것은 아니었다.

Bull 자체의 ``Job``에 대해선 원자적 처리를 보장하지만 그 이외의 부분에 대해선 원자적 처리가 보장되지 않는 상황이다.

각각의 필요한 모든 부분에 대해 명시적으로 락을 걸어 완전한 원자적 처리를 보장해야 했다.

이러한 처리를 위해 async-lock을 도입했다.

// pendingGroups 접근을 안전하게 하기 위한 헬퍼 메서드
async withPendingGroupsLock(fn) {
  return this.pendingGroupsLock.acquire('pendingGroups', fn);
}

위와 같이 락을 걸기 위한 헬퍼를 만들었다.

``fn``의 형태로 함수를 인자로 받는데, 그 함수는 락이 걸린 상태로 동작하게 된다.

await this.withPendingGroupsLock(async () => {
  for (const [groupId, group] of this.pendingGroups.entries()) {
    const allUsersExist = Array.from(group.userIds).every((uid) => sessionManager.getUser(uid));
    if (!allUsersExist) {
      logger.info(`그룹 ${groupId}의 일부 유저가 존재하지 않아 그룹 제거`);
      this.pendingGroups.delete(groupId);
    }
  }
});

이런 식으로 락을 걸어 사용할 수 있다.

하지만 데드락을 항상 조심해야 한다.

임시로 처리되게 한 부분을 좀 더 확실한 형태로 바꾸면서 데드락이 발생했다.

분명 코드만 보면 정상적이었음에도 불구, 프로그램이 더 이상 진행되지 않는 것이다.

로그를 찍어보며 어디에서 진행이 막히는지는 파악했으나, 그 이유를 알 수 없었다.

좀 더 들여다보니 그 이유는 `데드락`이었다.

async acceptUserInGroup(user, groupId) {
    // ...
    
    
    // 유효한 플레이어 모두 수락 처리
    for (const p of actualMatchedPlayers) {
      await this.removeAcceptQueueInUser(p);
      p.setMatched(false);
    }
    
    // ...
  }
  return null;
}

``acceptUserInGroup``을 호출하는 상위 함수엔 이미 ``withPendingGroupsLock``이 걸려있다.

그 상태에서 ``this.removeAcceptQueueInUser``가 정상 진행 시 호출되는데, 여기가 문제였다.

async removeAcceptQueueInUser(user) {
  return this.withPendingGroupsLock(async () => {
    //...
  });
}

이미 잡은 락을 또 잡고 있었다.

이러니 진행이 될 수가 있나...

``removeAcceptQueueInUser``의 락을 제거하고 나니 정상적으로 동작하는 것을 확인할 수 있었다.

이건 에러도 없다.

티를 안 내니 찾기가 쉽지 않다.

동시성 문제라는 것이 정말 만만하지 않다.

사람 잡는 요물이라고 하기에 손색없으리라.

[TIL #34] Docker 및 Docker Compose 올려보기

BVM — Tue, 3 Dec 2024 21:23:10 +0900

도커를 올려보기로 했다.

이미 라즈베리 파이 서버에 인프라가 다 준비돼 있지만,

내가 만져보면서 이해해보고 싶었던 것이기도 했고, 아마존 ECS에 올려보기 위함이기도 하다.

일단 현재 서버는 다음과 같은 상태다.

Node.js 서버
MySQL
Redis
Grafana

그럼 각각의 것들을 다 컨테이너로 만들어 ``Compose``로 묶어서 빌드 후 배포할 수 있어야 하겠다.

먼저 노드 서버를 위한 ``Dockerfile``을 다음과 같이 만들었다.

# Node.js 베이스 이미지 사용
FROM node:20-alpine

# 작업 디렉토리 설정
WORKDIR "작업 디렉토리"

# 패키지 파일 복사 및 의존성 설치
COPY package*.json ./
RUN npm install

# 소스 코드 복사
COPY . .

# 포트 노출
EXPOSE 5555

# 애플리케이션 실행
CMD ["npx", "pm2-runtime", "start", "ecosystem.config.cjs"]

별 다른 특별한 일은 하지 않는다.

다르다면 ``pm2``를 위한 설정이 있다는 것.

그리고 DB 등의 나머지 것들에 대한 설정은 ``docker-compose.yml``에서 이루어진다.

services:
  nodejs:
    build: .
    ports:
      - "5555:5555"
    env_file:
      - .env
    depends_on:
      mysql:
        condition: service_healthy
      redis:
        condition: service_healthy
      mysqld_exporter:
        condition: service_healthy
      redis_exporter:
        condition: service_healthy
      node_exporter:
        condition: service_healthy
    restart: on-failure
    networks:
      - app-network
      
// ...

이런 식으로 필요한 모든 서비스를 컴포즈 파일에 정의했다.

각 DB와 익스포터들에 대해 헬스 체크도 수행하게 했고,

``depends_on``이기 때문에 저것들이 다 올라와야 노드 서버가 올라올 수 있다.

하다 보니 익스포터마저 별개 컨테이너로 빠지게 됐는데, 이게 괜찮은지에 대해선 생각을 좀 해봐야 할 것 같다.

컨테이너가 8개가 돼버렸기 때문...

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['prometheus:9090']

  - job_name: 'mysql'
    static_configs:
      - targets: ['mysqld_exporter:9104']

  - job_name: 'redis'
    static_configs:
      - targets: ['redis_exporter:9121']

  - job_name: 'node'
    static_configs:
      - targets: ['node_exporter:9100']

물론 프로메테우스 설정도 잊지 않았다.

컴포즈로 빌드 후 컨테이너가 올라오는 것을 보자.

컨테이너들도 잘 올라오고 서버가 정상적으로 동작하는 것도 확인할 수 있었다.

물론 그라파나와 프로메테우스도 잘 올라온다.

이전엔 도커와 도커 컴포즈를 남이 말아놓은 걸 "사용"만 해봤었다.

내가 처음부터 구성해서 올리는 건 처음이었는데, 꽤 좋은 경험이었다.

처음엔 어떻게 해야 하나 싶었지만, 계속 보다 보니 보이는 게 생기는 것 같았다.

혹시 모를 에러가 있을 수 있으니 시간을 두고 지켜보며 개선할 수 있을 것이다.

[TIL #33] 마법의 엘리베이터

BVM — Wed, 20 Nov 2024 17:55:54 +0900

https://school.programmers.co.kr/learn/courses/30/lessons/148653

프로그래머스

코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요.

programmers.co.kr

모듈러 뺑뺑이 돌리는 문제.

접근법은 명확한데, 특정 테스트 케이스를 통과하지 못해서 평소보다 많은 시간을 투자했다.

먼저 첫 접근부터.

// 음수층은 없음
// 하지만 음수층이 있는 것 처럼 생각 가능
// 모듈러 지옥

function solution(storey) {
    let total = 0;
    let carry = 0;

    while (storey > 0) {
        let digit = (storey % 10) + carry; // 현재 자릿수 + 캐리

        if (digit <= 5) {
            total += digit; // -1 버튼을 digit번 누름
            carry = 0; // 캐리 초기화
        } else {
            total += (10 - digit);
            carry = 1; // 다음 자릿수로 캐리
        }

        storey = Math.floor(storey / 10); // 다음 자릿수로 이동
    }

    if (carry === 1) {
        total += 1; // 남아있는 캐리 처리
    }

    return total;
}

솔직히 이거면 문제가 없어야 한다고 생각했다.

하지만 문제가 있었고...

당장 질문하기로 가서 유사한 문제를 찾아보자.

아하...

기존 코드대로라면 5를 더하고 20을 더하고 500을 빼기 때문에 12가 나온다.

여기서 필요한 건 다음 자릿수가 5 이상인지도 고려하는 것이다.

445였다면 그냥 5를 빼고, 그다음 자릿수도 5 이하이기 때문에 빼는 흐름이 됐을 것이다.

하지만 8로 5보다 크기 때문에 이 점도 고려가 되어야 한다.

그리고 다음의 설명도 많은 도움이 됐다.

사실 같은 말을 하고 있는 것과 같다.

이 점을 반영하면 다음과 같은 결과가 나온다.

function solution(storey) {
    let answer = 0;
    
    while (storey !== 0) {
        let current = storey % 10; // 현재 자릿수        
        let next = Math.floor((storey % 100) / 10); // 다음 자릿수
        
        if (current > 5) {
            // 현재 자릿수가 5보다 크면 위로 올라가는 게 이득
            answer += (10 - current);
            storey += (10 - current);
        } else if (current === 5 && next >= 5) {
            // 현재 자릿수가 5이고 다음 자릿수가 5 이상이면 위로 올라가는 게 이득
            answer += 5;
            storey += 5;
        } else {
            // 그 외의 경우는 아래로 내려가는 게 이득
            answer += current;
        }
        
        // 다음 자릿수로 이동
        storey = Math.floor(storey / 10);
    }
    
    return answer;
}

층수가 1억 이하기 때문에 큰 부하가 걸리진 않는다.

아무리 문제의 스토리텔링이라도 그렇지 이건 머리에 문제가 있는 게 아닌가?

다른 사람은 어떻게 풀었는지도 함 봐줘야 한다.

그 해법은 다음과 같았다.

function solution(storey) {
    // 기저 조건: 5 미만이면 그대로 반환
    if (storey < 5) return storey;
    
    // 현재 자릿수의 값 구하기
    const r = storey % 10;
    // 현재 자릿수를 제외한 나머지 숫자
    const m = (storey - r) / 10;
    
    // 두 가지 선택지 중 최소값 반환:
    // 1. 아래로 내려가기: 현재 자릿수(r)만큼 내려가고 나머지 숫자(m)에 대해 재귀
    // 2. 위로 올라가기: (10-r)만큼 올라가고 다음 숫자(m+1)에 대해 재귀
    return Math.min(r + solution(m), 10 - r + solution(m + 1));
}

매우 간결한 코드다.

제한 사항은 1억이기 때문에 스택이 터질 일도 없다.

``Math.min()``을 통한 분기도 아까의 설명글에서 설명했던 그대로다.

프로그래머스는 가독성이 나빠도 코드가 짧기만 하면 추앙하는 이상한 사람들이 많은데,

이러한 진짜 간결하고 흐름이 보이는 코드가 좋은 코드가 아닐까.

E:\