햄랑

공부했던 것들을 남기는 곳입니다:)

[말랑 퀴즈] 26/09/25 해답

게시:     수정

카테고리:

태그:

제 말랑말랑 퀴즈 생성기는 이곳에서 확인하실 수 있습니다.

말랑말랑 퀴즈 — 해답지 ✅

날짜: 2026-09-25 문제 수: 6문제 총점: 36.7/60 (61점) 🟡 복습이 필요해요

📊 채점 결과

문항 유형 난이도 결과 점수
Q1 서술형 🔴 어려움 🔺 부분 정답 5.5 / 10
Q2 빈칸 🟡 보통 🔺 부분 정답 2.5 / 10
Q3 객관식 🟡 보통 ❌ 오답 0 / 10
Q4 OX 🟢 쉬움 ⭕ 정답 10 / 10
Q5 객관식 🟡 보통 ⭕ 정답 10 / 10
Q6 서술형 · 📌 오답노트 🔴 어려움 🔺 부분 정답 8.7 / 10
합계       36.7 / 60

총평

객관식·OX 중 Q4, Q5는 만점입니다 — 특히 Q5에서 RDBMS/NoSQL의 레코드 구조 차이를 정확히 뒤집어 반박하셨습니다. Q6(오답노트, 3번째 복습)도 8.7점으로 꽤 잘 하셨습니다 — 특히 “링형”과 SPOF/완화 방안은 정확히 짚으셨습니다.

Q3은 아쉽게 오답입니다. A를 “마지막 문단이 틀렸다”며 배제하셨는데, 사실 A가 정답이었습니다 — “인터페이스 위반이 컴파일 타임에 걸러진다”는 말은 앞 문장(다형성이 언제 결정되는가)과는 다른 축의 이야기인데 같은 이야기로 혼동하신 것 같습니다.

Q1·Q2에서 크게 점수가 빠졌습니다. Q2는 답안이 이 문제(Uncopyable 패턴)가 아니라 다른 주제(가상 함수·런타임 다형성)의 내용처럼 보입니다 — 문제를 착각하신 건 아닌지 확인해 보시면 좋겠습니다.

Q1. 🔴 어려움 — 🔺 5.5/10

문제: 템플릿 메타프로그래밍(TMP)에 대해 답하시오.

(1) TMP란 무엇인지 정의하고, 기존에 런타임에서 하던 작업을 컴파일 타임으로 옮겼을 때 얻는 대표적인 이점 두 가지를 쓰시오.

(2) TMP에는 반복(iteration) 의미의 루프가 없다. 대신 무엇을 사용해 반복의 효과를 내는가? 아래 팩토리얼 코드에서 그 메커니즘이 어떻게 나타나는지 설명하시오.

template<unsigned n>
struct Factorial {
    enum { value = n * Factorial<n-1>::value };
};

template<>
struct Factorial<0> {
    enum { value = 1 };
};

(3) BigMatrix result = m1 * m2 * m3 * m4 * m5;처럼 큰 정방행렬 다섯 개를 operator*로 곱하면 어떤 성능 문제가 생기는가? TMP를 응용한 어떤 기법으로 이 문제를 해결하는가?

📝 내 풀이:

(1) 1. 런타임 시점에 계산되던 작업이 컴파일 시점으로 옮겨가 계산할 필요가 없어진다.

  1. 에러가 컴파일 시점에 발생되어 파악하기 쉬워진다.

(2) 템플릿 특수화와 enum을 사용한다. 종료 시점이 템플릿 특수화 0, 구조체 안의 enum 변수를 통해 값을 저장한다.

(3) 한번의 연산마다 생성과 소멸이 발생하게 된다. 중첩 템플릿 기법이라 했던 것 같다. 템플릿을 말 그대로 중첩시켜 연산하는 방식으로 해결한다.

정답:

(1) TMP는 컴파일 도중 실행되는 템플릿 기반 프로그램을 작성하는 일이다

런타임 작업을 컴파일 타임으로 옮기면 선행 에러 탐지(컴파일 중 에러 발견)와 높은 런타임 효율(작은 코드·짧은 실행 시간·적은 메모리)을 얻는다.

(2) 반복 의미의 루프는 없고, 재귀식 템플릿 인스턴스화로 루프 효과를 낸다

TMP는 if문 대신 템플릿 특수화로 분기하고, 반복은 없이 재귀로 효과를 낸다. Factorial<5>::value를 요청하면 Factorial<5> → Factorial<4> → … → Factorial<0>까지 재귀적으로 인스턴스화되고, Factorial<0> 특수화가 재귀를 멈춘다.

(3) 곱셈마다 임시 행렬이 생겨 낭비된다 — 표현식 템플릿으로 해결

operator*를 네 번 연쇄 호출하면 매번 임시 행렬 객체가 생성된다. TMP를 응용한 표현식 템플릿(Expression Template)을 쓰면 임시 객체 없이 여러 루프를 하나로 합쳐 성능을 크게 높인다.

🔍 피드백: 논점별로 (1) 2.0 / (2) 1.8 / (3) 1.7을 받아 5.5점입니다.

(1)에서 TMP의 정의(컴파일 도중 실행되는 템플릿 기반 프로그램)를 직접 적지 않으셨습니다. 두 가지 이점(“계산이 컴파일 타임으로 옮겨가 필요 없어짐”, “에러가 컴파일 시점에 발견되어 파악하기 쉬워짐”)은 정답의 “높은 런타임 효율”과 “선행 에러 탐지”에 각각 대응해서 정확합니다.

(2)는 절반만 맞았습니다. “템플릿 특수화”와 “enum”을 언급하신 건 맞지만, 질문이 묻는 핵심인 “반복 대신 무엇을 쓰는가”에 대한 답 — 즉 “재귀”라는 단어가 빠졌습니다. Factorial<n>이 Factorial<n-1>을 참조해서 재귀적으로 인스턴스화되는 것이 반복 효과의 실체이고, 템플릿 특수화(Factorial<0>)는 그 재귀를 멈추는 종료 조건입니다. “특수화가 종료 시점”이라고 쓰신 것 자체는 맞지만, 그 앞에 “무엇이 반복되고 있는지”를 먼저 짚었어야 완전한 답이 됩니다.

(3)도 절반만 맞았습니다. “연산마다 생성과 소멸이 발생한다”는 정답의 “임시 행렬 생성” 문제와 정확히 일치합니다. 다만 해결 기법의 이름은 “중첩 템플릿 기법”이 아니라 “표현식 템플릿(Expression Template)”입니다. “템플릿을 중첩시켜 연산”이라는 설명도 표현식 템플릿의 핵심(임시 객체를 없애고 여러 연산을 하나의 식으로 묶어 한 번에 평가)과는 결이 다릅니다. “~라 했던 것 같다”고 스스로 적으신 만큼, 이 항목(48)의 세 가지 실용 사례(치수 단위 확인, 표현식 템플릿, 정책 기반 설계) 이름을 한 번 더 정리해 두시면 좋겠습니다.

출처: game_dev/cpp/chapter7/2025-11-03-cpp_7_48.md

Q2. 🟡 보통 — 🔺 2.5/10

문제: 빈칸을 채우시오.

컴파일러가 자동으로 만들어주는 복사 생성자·복사 대입 연산자를 막고 싶을 때, 그 멤버 함수를 직접 ① ___(으)로 선언하고 구현은 비워두면 외부에서 복사를 시도해도 막을 수 있다. 다만 이 경우 에러가 컴파일이 아니라 ② ___ 시점에 나서 아쉽다. 이 에러를 컴파일 시점으로 앞당기려면, Uncopyable처럼 복사 연산을 막아 둔 클래스를 ③ ___(으)로 상속하면 된다. Uncopyable은 데이터 멤버가 전혀 없어서 ④ ___(이)라는 최적화 기법이 적용될 여지가 있다.

📝 내 답: 가상 함수, 런타임, 부모, EBO

정답:

① private ② 링크(link) ③ private ④ 공백 기본 클래스 최적화(Empty Base (Class) Optimization, EBO)

해설:

컴파일러가 만든 복사 생성자·복사 대입 연산자를 막는 방법은, 그 멤버 함수를 직접 선언하고 private로 두되 구현은 비워두는 것이다. 멤버 함수·friend가 아니면 호출할 수 없어 외부 복사는 막히지만, 내부에서 실수로 호출하면 구현이 없어 링크(link) 시점에 에러가 난다.

이 에러를 컴파일 시점으로 앞당기려면, 복사 연산을 private로 막아 둔 Uncopyable을 private 상속하면 된다. Uncopyable은 데이터 멤버가 없는 빈 클래스라 공백 기본 클래스 최적화(EBO)의 적용 대상이 될 수 있다.

🔍 피드백: ④만 정답이고 나머지 세 곳은 이번 문제(Uncopyable 패턴)와는 다른 주제의 답처럼 보입니다.

  • ① “가상 함수”가 아니라 private입니다. 이 빈칸은 “컴파일러가 자동 생성하는 함수를 어떤 접근 지정자로 선언해서 막는가”를 묻는 것이라 가상 함수와는 관련이 없습니다.
  • ② “런타임”이 아니라 링크(link)입니다. 선언만 있고 정의가 없는 함수를 호출하면 컴파일은 통과하지만 링크 단계에서 “정의를 찾을 수 없다”는 에러가 납니다. 프로그램이 실행된 뒤 발생하는 런타임 에러와는 다릅니다.
  • ③ “부모”가 아니라 private입니다. Uncopyable을 private 상속하면(class HomeForSale : private Uncopyable), 파생 클래스가 기반 클래스의 private 복사 연산에 접근할 수 없어 컴파일 에러가 납니다.
  • ④ EBO는 정확합니다.

혹시 이 문제를 풀 때 다른 단원(가상 함수·런타임 다형성 관련) 내용과 헷갈리신 게 아닌지 확인해 보시면 좋겠습니다. 원문은 game_dev/cpp/chapter2/2025-04-23-cpp_2_6.md(항목 6, “컴파일러가 만들어낸 함수의 사용을 금하자”)입니다.

출처: game_dev/cpp/chapter2/2025-04-23-cpp_2_6.md

Q3. 🟡 보통 — ❌ 0/10

문제: 클래스 기반 프로그래밍과 템플릿 기반 프로그래밍의 인터페이스·다형성 차이에 대한 설명으로 가장 올바른 것은?

  • A. 클래스 기반 설계에서는 인터페이스가 함수 시그너처로 명확히 드러나는 명시적 인터페이스이고, 다형성은 가상 함수를 통해 런타임에 결정된다. 템플릿 기반 설계에서는 인터페이스가 사용 패턴(유효 표현식)으로 추론되는 암시적 인터페이스이고, 다형성은 템플릿 인스턴스화를 통해 컴파일 타임에 결정된다. 두 방식 모두 인터페이스 위반은 컴파일 타임에 걸러진다는 공통점이 있다.
  • B. 템플릿 매개변수 T가 만족해야 하는 조건은 반드시 operator>와 operator!=를 T 자신이 직접 정의하는 것이며, 타입 변환을 통해 간접적으로 만족시키는 것은 허용되지 않는다.
  • C. 암시적 인터페이스는 런타임에 검증되므로, 템플릿이 요구하는 함수가 없는 타입을 넘겨도 일단 컴파일은 되고 실행 중에 에러가 난다.
  • D. 클래스 기반의 명시적 인터페이스는 유연성이 높아 다양한 타입에 재사용하기 쉽고, 템플릿 기반의 암시적 인터페이스는 특정 타입에 고정되어 있어 유연성이 낮다.

📝 내 답: D — A: 마지막 문단이 틀렸다. 클래스는 런타임, 템플릿은 컴파일 / B: 이거는 잘 모르겠다. / C: 암시적 인터페이스는 컴파일 타임. 런타임 시점 에러.

정답: A

해설:

특성 명시적 인터페이스(클래스) 암시적 인터페이스(템플릿)
정의 방식 함수 시그너처로 명확히 사용 패턴(유효 표현식)으로 추론
검증 시점 컴파일 타임 컴파일 타임
특성 런타임 다형성(클래스) 컴파일 타임 다형성(템플릿)
결정 시점 실행 중 컴파일 중

클래스 기반은 명시적 인터페이스 + 런타임 다형성, 템플릿 기반은 암시적 인터페이스 + 컴파일 타임 다형성이라는 대응이 핵심이다. 그리고 암시적 인터페이스도 컴파일 도중에 점검된다는 것이 두 방식의 중요한 공통점이다.

  • B — 실제로 필요한 것은 “if문의 최종 값이 bool과 호환되는가”뿐이다. 타입 변환을 통한 간접 만족도 허용된다.
  • C — 템플릿이 요구하는 인터페이스가 없으면 컴파일 자체가 안 된다.
  • D — 반대다. 암시적 인터페이스(템플릿)가 유연성이 높고, 명시적 인터페이스(클래스)가 특정 타입에 고정돼 유연성이 낮다.

🔍 피드백: D를 오답으로 정확히 배제하지 못해 최종 선택이 A가 아닌 D가 되었습니다. A에 대한 메모가 혼란의 원인으로 보입니다. “클래스는 런타임, 템플릿은 컴파일”이라고 적으신 것 자체가 사실은 A의 앞부분 내용과 정확히 같은 이야기입니다 — A는 “런타임 다형성 vs 컴파일 타임 다형성”과 “인터페이스 위반이 컴파일 타임에 걸러진다”는 것을 서로 다른 두 가지 사실로 함께 말하고 있는데, 이 둘을 같은 주장으로 여겨 “마지막 문단이 (앞과) 모순된다”고 판단하신 것 같습니다. 하지만 “다형성이 언제 결정되는가”(런타임 vs 컴파일 타임)와 “인터페이스 위반이 언제 발견되는가”(둘 다 컴파일 타임)는 서로 다른 축의 질문이라 모순이 아닙니다. C에 대한 메모(“암시적 인터페이스는 컴파일 타임”)는 오히려 정확한 지적이었는데, 정작 A를 배제하는 데 이 지식이 연결되지 못한 점이 아쉽습니다.

출처: game_dev/cpp/chapter7/2025-10-28-cpp_7_41.md

Q4. 🟢 쉬움 — ⭕ 10/10

문제: 다음 명제가 참(O)인지 거짓(X)인지 판단하라.

분산 처리는 확장성뿐 아니라 안정성에도 도움이 된다. 수직 분산 구조에서 서버 하나가 멈추면 그 서버가 담당하던 기능만 못 쓰게 되고 나머지 기능은 정상 동작하지만, 수평 분산 구조에서는 서버 하나가 멈추면 전체 시스템이 완전히 마비되어 모든 플레이어의 접속이 끊긴다.

📝 내 답: X. 마지막 문단에서 틀렸다. 수평 분산 구조에선 서버 하나만 멈추고, 전체 시스템이 마비되진 않는다.

정답: X

해설:

수직 분산에 대한 설명은 참이지만, 수평 분산에 대한 설명이 틀렸다.

수평 분산의 경우, 중지된 서버에 있는 플레이어들만 접속이 끊어지며, 다른 서버에 접속하면 된다.

서버 하나가 멈춰도 그 서버에 있던 플레이어만 영향을 받을 뿐, 전체 시스템이 마비되는 것은 아니다.

🔍 피드백: 만점입니다. 판단과 근거 모두 정답과 정확히 일치합니다.

출처: server/game_server/9/2026-03-22-game_server_9_11.md

Q5. 🟡 보통 — ⭕ 10/10

문제: 게임 서버의 데이터 저장 방식(RDBMS vs NoSQL)에 대한 설명으로 가장 올바른 것은?

  • A. RDBMS는 필드 구조를 바꿀 때 레코드 개수와 무관하게 즉시 적용되며, 기존 레코드가 1억 개여도 그 필드가 null을 허용하면 서버가 멈추지 않는다.
  • B. RDBMS의 레코드는 리스트·배열 구조의 데이터이고, 필드 구조를 바꾸려면 기존 레코드 전체에 손을 대야 해서(외래 키를 쓰더라도 마찬가지일 수 있다) 점점 복잡해진다. 예를 들어 레코드 1억 개에 필드를 하나 추가하면, null을 허용하더라도 장시간 서버가 멈출 수 있다. 반면 NoSQL은 레코드가 트리나 구조체 형태를 가질 수 있어 이런 제약에서 비교적 자유롭다.
  • C. NoSQL은 레코드가 반드시 리스트나 배열 구조를 가져야 하며, 트리 구조의 데이터는 저장할 수 없다.
  • D. 외래 키를 사용하면 RDBMS에서 필드 구조를 바꾸는 일이 전혀 복잡해지지 않는다.

📝 내 답: B — A: 즉시 적용되지 않고 오래 걸리며, 1억개 필드가 null을 허용한다 해도 서버가 멈춘다. / C: NoSQL은 트리 구조나 구조체 형태이다. / D: 외래 키를 사용하더라도 연관된 DB들이 있으므로 복잡해진다.

정답: B

해설:

관계형 데이터베이스(RDBMS)는 레코드가 리스트나 배열 구조의 데이터다. 필드 구조를 바꾸려면 기존 레코드가 1억 개일 때 그 1억 개 전체에 손을 대야 해서, null을 허용해도 장시간 작동을 멈춘다.

NoSQL은 레코드가 트리나 구조체 형태를 가질 수 있어 이런 제약에서 비교적 자유롭다.

  • A — 반대다. null 허용 여부와 무관하게 장시간 멈춘다.
  • C — 반대다. 트리·구조체 형태가 가능한 쪽은 NoSQL이다.
  • D — 원문은 “외래 키를 사용하더라도 마찬가지일 수 있다”고 말한다.

🔍 피드백: 만점입니다. A·C에 대한 반박은 정답 해설과 정확히 일치합니다. D에 대한 메모(“연관된 DB들이 있으므로 복잡해진다”)는 원문에 직접 나온 표현은 아니지만, “외래 키를 쓴다고 문제가 사라지지 않는다”는 결론 자체는 정확합니다.

출처: server/game_server/8/2026-03-08-game_server_8_1.md

Q6. 🔴 어려움 · 📌 오답노트 — 8.7/10

문제: DB 수평 확장을 위해 유저 DB를 샤드 10개로 나눠 운영하는 상황에 대해 답하시오.

(1) 클라이언트 로그인 시 어느 샤드에 질의를 보낼지 결정하는 과정과, 그때 쓰이는 키의 이름 (2) 일반적인 해시 테이블 방식이 리해시가 큰 이유, 일관된 해시 알고리즘의 재배치 규모, “링형”이라 부르는 이유 (3) 매핑 DB 방식에서 샤드 추가 시 레코드 이동이 필요 없는 이유와, 새로 생기는 위험 및 완화법 (4) 대규모 변경 상황에서 일관된 해시와 매핑 DB 각각의 한계

📝 내 풀이:

(1) 샤드 키를 해시 함수에 전달해 어느 샤드에 보낼지 결정한다. 샤드 키

(2) 해시 함수가 샤드 전체에 대해 배정되어 있기 때문이다. 일관된 해시 알고리즘을 쓰면 1개로 줄어든다. 미리 N만큼의 범위를 배정해두고, 넓은 해시가 0->N->0으로 연결되는 구조를 갖고 있기 떄문이다.

(3) 매핑 DB에는 키와 값만 연결해주면 되기 때문이다. 매핑 DB가 죽어버리는 SPOF가 발생할 수 있기 때문이며, 복제/분산하여 완화한다.

(4) 샤드가 크게 늘어나면 일관된 해시 함수에서 결국 재배치를 여러번하게 되기 때문이다. 매핑 DB는 DB 크기가 증가하며, 병목이 발생한다.

정답:

(1) ID → 해시 함수로 샤드 인덱스를 얻는다 — 이 키를 샤드 키(파티션 키)라고 한다

클라이언트가 ID/PW를 보내면, 서버는 ID를 해시 함수에 넣어 샤드 인덱스를 얻고 그 샤드에 질의한다. 이 키를 샤드 키(파티션 키)라 부른다.

(2) 일반 해시 테이블은 일대일 대응이라 거의 다 흔들린다 — 일관된 해시는 샤드 1개만 재배치, 양 끝이 이어져 “링형”

일반 해시 테이블은 항목이 해시 값에 일대일 대응돼서 샤드 개수가 바뀌면 대부분 리해시해야 한다. 일관된 해시는 해시 값을 많이 고정시켜 샤드 하나가 다수를 담당하게 하므로, 샤드 개수 변동 1개당 샤드 1개만 재배치하면 된다. 양 끝(샤드 3과 1)이 인접한 원형 구조라 링형이라 부른다.

(3) 매핑 DB는 “계산” 대신 “조회”라 추가가 쉽다 — 새 위험은 SPOF, 완화는 매핑 DB 자체의 샤딩

매핑 DB는 입력(키) → 샤드 인덱스를 미리 저장해 두고 조회만 하므로, 샤드 추가 시 새 샤드를 채우기만 하면 된다. 새로운 위험은 매핑 DB가 단일 실패 지점(SPOF)이 된다는 것이며, 매핑 DB 자체에도 샤딩(확장성)을 적용해 완화한다.

(4) 일관된 해시는 “대규모 변동 시 결국 많은 리해시”, 매핑 DB는 “샤드 제거·재구성 시 매핑 정보 자체의 대량 이동” — 다른 이유

일관된 해시는 샤드가 크게 늘거나 줄면 여러 샤드에 걸쳐 재분배해야 해서 결국 많은 리해시가 필요하다. 매핑 DB는 샤드 추가는 가볍지만 제거나 재구성 시 매핑 DB 자체의 대량 레코드 이동과 유저 DB 반영이 필요하다 — 매핑 정보를 저장해 둔 구조 자체를 고쳐야 하는 비용이다. 두 한계는 같은 이유가 아니다.

🔍 피드백: 논점별로 (1) 2.5 / (2) 2.0 / (3) 2.4 / (4) 1.8을 받아 8.7점입니다. 세 번째 복습인데 확실히 이전보다 많이 나아졌습니다.

(1)은 만점입니다. 과정과 이름 모두 정확합니다.

(2)는 거의 맞았지만 첫 부분이 아쉽습니다. “1개로 줄어든다”와 “0→N→0으로 연결되는 링 구조”는 정답과 정확히 일치합니다. 다만 “일반 해시 테이블이 왜 리해시가 큰가”에 대해 “해시 함수가 샤드 전체에 배정되어 있기 때문”이라고 쓰신 부분은 다소 모호합니다 — 정확한 이유는 항목이 해시 값에 일대일로 대응되어 있어서, 샤드 개수(나누는 수)가 바뀌면 대부분 항목의 대응 관계 자체가 달라지기 때문입니다.

(3)은 거의 만점입니다. SPOF와 완화 방안(분산 = 매핑 DB 샤딩)을 정확히 짚으셨습니다. “키와 값만 연결해주면 된다”는 것도 매핑 DB가 “계산”이 아니라 “조회” 기반이라는 정답의 핵심과 통합니다.

(4)는 첫 부분은 정확하나 매핑 DB 쪽 설명이 원문과 결이 다릅니다. “매핑 DB는 DB 크기가 증가하며 병목이 발생한다”고 쓰셨는데, 정답이 말하는 매핑 DB의 진짜 한계는 크기 증가로 인한 단순 병목이 아니라, 샤드를 제거·재구성할 때 매핑 DB 자체에서 대량의 레코드 이동이 필요하다는 것입니다. “대규모 변경 상황”이라는 질문의 조건에 맞춰, “커지면 느려진다”보다는 “재구성 비용이 크다”는 쪽으로 답을 연결해 보시면 좋겠습니다.

출처: server/game_server/9/2026-03-26-game_server_10_2.md 오답노트: wn-1da60a18 · 2026-09-09 최초 오답 · 이번이 3번째 복습

📌 복습 포인트

  • Q1 TMP의 반복 메커니즘과 표현식 템플릿 — 반복 대신 재귀식 템플릿 인스턴스화를 쓰며, 특수화는 그 종료 조건. 행렬 곱 최적화 기법의 정확한 이름은 표현식 템플릿(Expression Template) → game_dev/cpp/chapter7/2025-11-03-cpp_7_48.md
  • Q2 Uncopyable 패턴 처음부터 다시 보기 — private 선언(링크 에러) → private 상속(컴파일 에러) → EBO. 다른 단원(가상 함수·런타임 다형성)과 섞이지 않도록 주의 → game_dev/cpp/chapter2/2025-04-23-cpp_2_6.md
  • Q3 “다형성이 언제 결정되는가”와 “인터페이스 위반이 언제 발견되는가”는 다른 질문 — 전자는 클래스=런타임/템플릿=컴파일로 다르고, 후자는 둘 다 컴파일 타임으로 같다 → game_dev/cpp/chapter7/2025-10-28-cpp_7_41.md
  • Q6 매핑 DB의 대규모 변경 한계 (오답노트, 4번째 복습 예정) — 단순 “크기 증가·병목”이 아니라 샤드 제거/재구성 시 매핑 정보 자체의 대량 이동이 핵심 → server/game_server/9/2026-03-26-game_server_10_2.md

MallangQuiz 카테고리 내 다른 글 보러가기

댓글남기기

참고