[말랑 퀴즈] 26/10/17 해답
카테고리: MallangQuiz
태그: Quiz
제 말랑말랑 퀴즈 생성기는 이곳에서 확인하실 수 있습니다.
말랑말랑 퀴즈 — 해답지 ✅
날짜: 2026-10-17 문제 수: 6문제 총점: 52.6/60 (88점) ✅ 잘했어요
📊 채점 결과
| 문항 | 유형 | 난이도 | 결과 | 점수 |
|---|---|---|---|---|
| Q1 | OX | 🟢 쉬움 | ⭕ 정답 | 10 / 10 |
| Q2 | 객관식 | 🟡 보통 | ⭕ 정답 | 10 / 10 |
| Q3 | 빈칸 채우기 | 🟡 보통 | 🔺 부분 정답 | 5 / 10 |
| Q4 | OX | 🟡 보통 | ⭕ 정답 | 10 / 10 |
| Q5 | 객관식 | 🟡 보통 | ⭕ 정답 | 10 / 10 |
| Q6 📌 | 서술형 | 🔴 어려움 | 🔺 부분 정답 | 7.6 / 10 |
| 합계 | 52.6 / 60 |
총평
OX 두 문제와 객관식 두 문제를 모두 만점으로 풀었고, 오답 보기마다 왜 틀렸는지 정확히 짚으셨습니다. 반면 Q3(소멸자와 예외)는 std::terminate와 “예외 발생 가능 연산은 일반 함수로 분리한다”는 핵심 용어 두 개를 놓쳤습니다. 오답노트 복습 문제 Q6은 (1)과 (4)의 흐름은 이해하고 계신데, (3)에서 예측/보정이 잘 맞는 조건(50ms 이하)과 100ms를 넘을 때의 문제(움직임 손상)를 기억하지 못했고 (4)의 예시 중 하나가 틀렸습니다.
Q1. 🟢 쉬움 — ⭕ 10/10
문제: 다음 명제가 참(O)인지 거짓(X)인지 판단하라.
string *p = new string[100];로 할당한 배열을delete p;로 해제하면 첫 번째 객체의 소멸자만 호출되고 나머지는 호출되지 않아 정의되지 않은 동작이 발생할 수 있다. 한편typedef string AddressLines[4];처럼 배열 타입을typedef로 감추면 포인터가 배열을 가리킨다는 사실이 드러나므로,delete와delete[]를 혼동할 위험이 줄어든다.
📝 내 답: X. 두번째 줄이 틀렸다. typedef는 오히려 감춰지기에 벡터와 같은 다른 대안을 권장한다.
정답: X
해설:
앞 문장은 맞다. new[]로 할당한 배열을 delete로 해제하면 정의되지 않은 동작이 발생할 수 있다. 그러나 typedef로 배열 타입을 감추면 포인터가 배열을 가리킨다는 사실을 놓치기 쉬워져 delete와 delete[]를 혼동할 위험이 오히려 커진다. 그래서 배열 타입을 typedef로 감추는 것은 피하고, vector나 array 같은 컨테이너를 쓰는 것이 안전하다.
🔍 피드백: 판단(X)과 틀린 위치(둘째 문장), 그리고 대안(vector 등 컨테이너)까지 정확히 짚었습니다. 한 가지 덧붙이면, typedef로 감추면 배열이라는 사실이 드러나지 않아 delete와 delete[]를 혼동할 위험이 커진다는 결과까지 말하면 더 완벽합니다.
출처:
game_dev/cpp/chapter3/2025-06-12-cpp_3_16.md
Q2. 🟡 보통 — ⭕ 10/10
문제: 온라인 게임에서 플레이어가 인벤토리의 아이템을 클릭해 사용하는 흐름에 대한 설명으로 가장 올바른 것은?
- A. 클라이언트는 아이템 ID를 담은 사용 요청만 서버에 보낸다. 서버가 유효한 플레이어인지, 해당 아이템을 갖고 있는지 판단한 뒤 개수를 줄이고, 그 결과를 클라이언트에 통보한다.
- B. 클라이언트가 아이템 보유 여부를 먼저 판단한 뒤, 사용이 가능할 때만 서버에 사용 결과를 보낸다.
- C. 서버는 아이템 개수만 줄이고, 클라이언트에는 아무것도 통보하지 않는다. 클라이언트가 스스로 개수를 계산해 화면을 바꾼다.
- D. 아이템 사용은 중요한 판단이 아니므로 서버를 거치지 않고 클라이언트끼리 직접 처리한다.
📝 내 선택: A
정답: A
해설:
게임 플레이 이외의 네트워킹은 “클라이언트 → 서버: 요청, 서버: 검증 및 판단, 서버 → 클라이언트: 결과 통보” 패턴을 따르며, 모든 중요한 판단은 서버에서 수행한다. 아이템 사용도 서버가 플레이어 유효성과 아이템 보유 여부를 판단하고 개수를 줄인 뒤 “아이템 개수가 N개가 되었다” 등을 클라이언트에 송신한다.
- B: 판단은 클라이언트가 아니라 서버가 한다.
- C: 서버는 개수 변경과 상태 변경 결과를 클라이언트에 송신한다.
- D: 서버를 거치지 않는 것이 아니라 서버가 판단한다.
🔍 피드백: A를 정확히 골랐고, B(결과가 아니라 요청을 보냄), C(서버가 결과를 통보), D(클라이언트에 맡기면 조작 가능) 근거가 모두 해답과 일치합니다.
출처:
server/game_server/5/2026-02-16-game_server_5_7.md
Q3. 🟡 보통 — 🔺 5/10
문제: 빈칸을 채우시오.
C++에서 소멸자와 예외에 대한 설명이다.
- 소멸자에서 던져진 예외가 다른 예외와 충돌하면, C++ 런타임은 ①
___를 호출해 프로그램을 종료시킨다. (함수 이름, 영문 소문자, 괄호는 제외) DBConn의 소멸자 안에서db.close()가 예외를 던질 위험이 있으므로, 사용자가 직접 호출해 예외에 대응할 수 있도록close()를 소멸자와 별개인 ②___로 제공한다. (두 단어)- 그래도 소멸자 안에서 예외가 발생할 수 있다면
try-catch로 잡은 뒤, 로그만 남기고 삼키거나 프로그램을 ③___한다. (두 글자 단어) - 예외는 반드시 ④
___(이)가 처리할 수 있는 곳에서 발생해야 하는데, 소멸자는 그런 곳이 아니다. (누가 처리하는지를 나타내는 한 단어)
📝 내 답: throw, 예외 처리, 종료, 호출자
정답:
① terminate (std::terminate())
② 일반 함수
③ 종료
④ 사용자
해설:
소멸자에서 예외가 밖으로 나가 다른 예외와 충돌하면 std::terminate()가 호출되어 프로그램이 종료된다. 예외가 발생할 수 있는 연산(close())은 일반 함수로 제공해 사용자가 직접 처리하게 하고, 소멸자 안에서는 예외를 삼키든 종료하든 반드시 예외를 잡아야 한다. 예외는 사용자가 처리할 수 있는 곳에서 발생해야 한다.
🔍 피드백: 빈칸당 2.5점입니다. ③(종료)은 맞았습니다. ④는 “호출자”라고 쓰셨는데, 예외를 처리할 수 있는 쪽이라는 같은 개념이라 정답으로 인정했습니다. ①은 throw가 아니라 terminate(std::terminate())입니다. throw는 예외를 던지는 키워드이고, 충돌 시 런타임이 호출해 프로그램을 끝내는 함수가 terminate입니다. ②는 “예외 처리”가 아니라 일반 함수입니다. 예외가 발생할 수 있는 close()를 소멸자와 별개의 일반 함수로 빼내서 사용자가 직접 호출·처리하게 하는 설계입니다.
출처:
game_dev/cpp/chapter2/2025-05-28-cpp_2_8.md
Q4. 🟡 보통 — ⭕ 10/10
문제: 다음 명제가 참(O)인지 거짓(X)인지 판단하라.
시퀀스 다이어그램은 객체 간 메시지를 시간 순서대로 표현하는 데 강점이 있어 통신 프로토콜 설계에 쓰기 좋다. 액티비티 다이어그램은 활동 상태를 타원으로 표현하고 조건 분기도 쓸 수 있어 게임 로직 흐름 설계에 쓰기 좋은데, 시간적 순서는 시퀀스 다이어그램보다 오히려 명확하게 드러난다.
📝 내 답: X. 앞은 맞는데, 시간적 순서는 시퀀스 다이어그램에서 나타난다는 점에서 틀렸다.
정답: X
해설:
앞부분(시퀀스 다이어그램의 강점과 사용 시기, 액티비티 다이어그램의 타원 도형·조건 분기·게임 로직 흐름 설계)은 모두 맞다. 틀린 곳은 마지막이다. 액티비티 다이어그램은 처리 흐름과 로직 표현에는 강하지만 시간적 순서가 불명확하다는 것이 약점이고, 시간적 순서가 명확한 쪽은 시퀀스 다이어그램이다.
🔍 피드백: 판단(X)과 틀린 위치(마지막 부분), 올바른 내용(시간적 순서는 시퀀스 다이어그램)을 모두 정확히 짚었습니다.
출처:
server/game_server/5/2026-02-12-game_server_5_1.md
Q5. 🟡 보통 — ⭕ 10/10
문제: C++ 예외 안전성 보장 수준 중 강력한 보장(strong guarantee)에 대한 설명으로 가장 올바른 것은?
- A. 함수 실행 중 예외가 발생하면 프로그램 상태를 변경하지 않아, 함수가 성공적으로 끝난 상태와 함수 호출 이전 상태, 두 가지 상태만 존재한다.
- B. 함수 실행 중 예외가 발생해도 프로그램을 유효한 상태로만 유지하며, 그 상태가 정확히 어떤지는 예측할 수 없어도 된다.
- C. 함수가 어떤 경우에도 예외를 던지지 않겠다는 보장이다.
- D. 함수 선언에
throw()로 예외 지정을 해 두면 구현과 관계없이 자동으로 제공된다.
📝 내 선택: A
정답: A
해설:
강력한 보장은 예외 발생 시 프로그램 상태를 절대 변경하지 않는다는 보장으로, 호출이 성공하면 완벽히 성공하고 실패하면 호출 이전 상태로 완벽히 되돌아간다. 복사 후 맞바꾸기(copy-and-swap)로 구현할 수 있다.
- B: 기본적인 보장(basic guarantee)에 대한 설명이다.
- C: 예외불가 보장(nothrow guarantee)에 대한 설명이다.
- D:
throw()예외 지정은 예외불가 보장을 제공하지 않는다. 선언은 선언일 뿐 구현이 좌우한다.
🔍 피드백: A를 정확히 골랐고, B(기본적인 보장), C(예외불가 보장), D(throw()는 구현이 좌우)의 근거가 모두 맞습니다.
출처:
game_dev/cpp/chapter5/2025-09-14-cpp_5_29.md
Q6. 🔴 어려움 · 📌 오답노트 — 🔺 7.6/10
문제: RPG에서 플레이어가 바닥을 클릭해 캐릭터를 이동시키는 기능을 만든다. 서버가 이동을 연산하고 클라이언트가 서버가 보낸 이동 정보 메시지로 위치를 추측항법으로 갱신하는 기본 방식에서 출발하여 아래에 답하시오.
(1) 이 기본 방식은 플레이어에게 답답하게 느껴진다. 그 이유를 쓰시오.
(2) 이동 계산을 클라이언트가 먼저 하되 치터(해커)를 막는 방법으로 값 검증과 예측/보정이 있다. 각 방법에서 클라이언트가 서버에 무엇을 보내고, 서버가 무엇을 하는지 쓰시오. 예측/보정에서는 클라이언트가 서버의 응답을 받은 뒤 무엇을 하는지도 쓰시오.
(3) 예측/보정이 잘 맞는 레이턴시 조건과, 레이턴시가 어느 수준을 넘으면 어떤 문제가 생기는지 수치와 함께 쓰시오.
(4) “일단 보여주고 나중에 해결” 방식에서, 레이턴시가 높을 때 행동 연출은 어떤 순서로 진행되는가? 이 방식을 사용한 게임의 예를 두 가지 쓰시오.
📝 내 풀이:
(1) 입력 후 결과를 받기까지 지연이 발생해, 즉각적인 반응이 안된다.
(2) 값 검증에서는 클라이언트가 보낸 값이 유효한 범위인지 확인하고, 그렇지 않다면 거절한다. 예측/보정은 클라이언트가 먼저 예측해서 진행하고, 서버에선 클라이언트에게 받은 데이터를 토대로 서버에서 시뮬레이션하고, 차이가 발생하면 보정시킨다. 클라이언트는 서버에게 받은 보정 데이터를 토대로 업데이트한다.
(3) 100ms 아래의 저지연 환경에서 잘 작동한다.
(4) 행동 애니메이션 먼저 후, 결과를 받으면 수치 조정 및 파티클 발생. 스타크래프트, WOW
정답:
(1) 명령을 서버에 보낸 즉시 캐릭터가 움직이지 않고, 서버에게서 이동 정보 메시지를 받아야 비로소 움직이기 때문이다(왕복 레이턴시만큼 지연됨).
(2) 값 검증: 클라이언트가 계산한 이동 정보를 서버에 보내고, 서버는 그 값이 정상적인 범위인지 검사한다. 예측/보정: 클라이언트는 먼저 캐릭터를 움직이고 명령 정보만 서버에 보낸다. 서버는 명령 정보를 기반으로 캐릭터 이동을 시뮬레이션한 뒤 이동 정보 메시지를 보낸다. 클라이언트는 그 메시지에 따라 자신의 이동(위치)을 보정(재조정)한다.
(3) 레이턴시가 균일하고 낮을 때(50ms 이하) 사용하는 것이 가장 좋다. 레이턴시가 100ms를 넘으면 캐릭터의 움직임이 손상된다(예측/보정은 해킹을 막는 데는 가장 좋다).
(4) 행동 모션(연출의 일부)이 먼저 즉시 시작되고, 서버의 처리 결과가 온 뒤에야 사운드와 이펙트 등 나머지 연출이 발생한다. 사용 예: 스타크래프트, 디아블로 3.
🔍 피드백:
- (1) 2.5/2.5 — 입력 후 결과를 받을 때까지 지연되어 즉각 반응하지 않는다는 핵심이 맞습니다.
- (2) 2.3/2.5 — 예측/보정의 흐름(클라이언트가 먼저 진행 → 서버가 시뮬레이션 → 차이가 있으면 보정 → 클라이언트가 보정 데이터로 갱신)은 정확합니다. 값 검증에서 서버가 범위를 검사해 거절한다는 점도 맞습니다. 다만 값 검증에서 클라이언트가 계산한 이동 정보를 서버에 보낸다는 점과, 예측/보정에서 클라이언트가 보내는 것이 명령 정보라는 점을 명시하면 더 정확합니다.
- (3) 1/2.5 — “저지연 환경에서 잘 작동한다”는 방향은 맞지만, 수치가 50ms 이하(균일하고 낮을 때)여야 하고, 100ms를 넘으면 캐릭터 움직임이 손상된다는 문제가 빠졌습니다. 100ms는 “잘 작동하는 기준”이 아니라 “문제가 생기는 기준”입니다.
- (4) 1.8/2.5 — 행동 연출이 먼저 시작되고 결과가 오면 나머지 효과(사운드·이펙트 등)가 따라온다는 순서는 맞습니다. 예시 중 스타크래프트는 맞지만, WOW는 출처 문서에 없는 예이고 정답은 디아블로 3입니다.
출처:
server/game_server/5/2026-02-14-game_server_5_3.md오답노트:wn-0594c0aa· 2026-09-16 최초 오답 · 이번이 2번째 복습
📌 복습 포인트
- Q3 소멸자와 예외 — 충돌 시
std::terminate()호출, 예외 발생 가능 연산은 소멸자 대신 일반 함수로 제공 →game_dev/cpp/chapter2/2025-05-28-cpp_2_8.md - Q6 클라이언트 이동 예측/보정 — 50ms 이하에서 최적, 100ms 넘으면 움직임 손상, “일단 보여주고 나중에 해결”의 예는 스타크래프트·디아블로 3 →
server/game_server/5/2026-02-14-game_server_5_3.md
댓글남기기