NDC26 - DAY 2

2026-06-17에 진행한 NDC26에서 인상 깊었던 강연 내용을 기록하였다.

기술 면접은 무엇을 평가하는가

이 정도면 충분하다고 생각했습니다. (면접 전까지는)

발표자 소개

오윤호

• 2005년 넥슨 코리아 입사
• 클래식 RPG 둠바스 프로그래밍팀
• 모바일 게임 AXE 프로그래밍팀
• Project FF 11 프로그래밍팀
• 테일즈M 프로그래밍팀
• 프라시아전기 프로그래밍실
• Project EL 프로그래밍실
• 메이플AX실
• 10년 넘게 넥슨 그룹에서 기술 면접관

안내 사항

본 발표의 모든 내용은 발표자 개인의 의견이며, 소속 조직 및 회사의 공식 입장과는 무관합니다.

목차

• 기술 면접은 무엇을 평가하는가
• 발표자 소개
• 안내 사항
• 목차
• 1. 내용은 좋은 것 같은데, 왜 떨어질까
  • 화려한 포트폴리오와 다양한 기술 스택 경험
  • 무엇이든 만들어 보는 것은 매우 도움이 된다 그 과정에서 배우는 것들이 매우 많다 다만,
  • 단 한 줄이라도…
  • 면접에서 나오는 질문들
  • 면접관이 궁금한 것들
  • 면접관이 평가하는 과정
  • 신입 클라이언트 프로그래머에게 할 수 있는 질문들
  • 경력자에게 기대 하는 것
• 2. 아는 것 말고, 이해하는 것
  • 추상화의 역설, 편리함 뒤에 숨은 내용은?
  • 기본 지식은 한계와 가야 할 길을 알려준다
  • 좋은 프로그래머는 자료구조와 그 관계를 걱정한다
  • Computer Science
  • 결국 내가 개발 할 때 사용하는 것은 개발 언어
  • 그 문제들이 사라진 것이 아니다
  • 엔진을 쓸 줄 아는 것과 이해하는 것은 다르다.
• 3. 그리고, 대 AI 시대
  • AI는 엔지니어링 능력을 대체하지 않는다
  • AI 시대에 잘하는 개발자 = 원래부터 문제 정의와 커뮤니케이션을 잘하는 사람
• 4. 마무리
  • 오늘의 핵심 정리
  • 문제 해결 스토리
  • 친구, 동료의 힘을 빌려 보자
  • 면접의 목표

1. 내용은 좋은 것 같은데, 왜 떨어질까

포트폴리오와 경험이 충분해도 탈락하는 진짜 이유

화려한 포트폴리오와 다양한 기술 스택 경험

• 경험의 양과 범위를 강조한 포트폴리오
• 엔진으로 무엇이든 완성한 경험 (게임 모작, 자작 등)
• 다양한 프레임워크, 라이브러리, 툴 사용 경험

특히 탈락하는 분의 대부분은 양과 범위로 승부하는 경우가 많다.

무엇이든 만들어 보는 것은 매우 도움이 된다 그 과정에서 배우는 것들이 매우 많다 다만,

내가 알고 있는 것을 알고 있는 거로 끝나는 게 아니라 그 과정에서 무엇을 남겼느냐가 핵심이다.

단 한 줄이라도…

• "어떤 기능"을 하는 코드인지 설명할 수 있어야 한다.
• "어떻게" 이 코드가 동작하는지 설명할 수 있어야 한다.
• "장점 및 단점"을 설명할 수 있어야 한다.

이 세 가지를 명확하게 설명할 수 있어야 한다.

면접에서 나오는 질문들

• 기본기를 많이 묻는다.
• 코드의 장점과 단점을 묻는다.

입사하고 나서 배움의 가속이 얼마나 붙을 수 있는지 확인하는 질문이다.
지식이 부족하면 엉성하게 쌓이게 되고 많은 문제가 생기게 된다.

면접관이 궁금한 것들

1. 어째서 그 기능을 만들어야 했는지
2. 어떻게 구현 했는지
3. 그렇게 구현 했을 때의 장점과 단점은?
4. 다른 대안은 없었는지, 다른 대안과 비교한다면?

내부에서 쓰인 기능들에 대해서 질문을 한다.
그렇게 구현했을 때, 장점만 있지는 않기에 단점도 물어본다.
다른 대안은 없었는지 물어본다.
'어째서' 그리고 '어떻게'를 물어보고 그 과정에서 사고를 추적한다.
질문을 계속 이어가다보면 면접자들이 대답을 못하는 상황까지 간다.

면접관이 평가하는 과정

모르는 부분은 필연적으로 나오게 됨
그 과정에서 알고 있는 다른 지식들을 어떻게 조합해서
논리적 가설을 세우는지 사고의 경로를 평가

신입 클라이언트 프로그래머에게 할 수 있는 질문들

• 신입 클라이언트 프로그래머에게 기대하고, 질문 하는 것

특정 언어를 이용해서 개발해 봄 > 해당 언어의 특성에 대해서 질문
특정 엔진을 이용해서 개발해 봄 > 해당 엔진의 특성에 대해서 질문
어떤 기능을 구현해 봄 > 해당 기능을 구현한 방법과 선택 이유, 해당 방법을 썼을 때의 문제점에 대한 질문

• ex) virtual 함수의 사용 목적은?
• ex) 소멸자에 virtual을 붙이는 이유는?
• ex) 언리얼 엔진에서 GC의 대상은?

단단한 기본기를 가지고 있어서, 실무에서 필요한 다양한 기술 스택을 빠르게 흡수할 수 있는 능력

경력자에게 기대 하는 것

• 경력 프로그래머에게 기대하고, 질문 하는 것

본인의 경험에서 무엇을 배웠고,
그 경험에서의 결정(누구에 의한 것이든)의 장, 단점을 알고 있는지

• ex) 왜 그 방법을 선택했는지 설명할 수 있는가
• ex) 대안과 trade-off 를 함께 고려했는가
• ex) 다시 한다면 무엇을 바꿀지 말할 수 있는가

본인의 경험을 깊이 이해하고, 그 결정의 장단점에서 배움을 얻어 새로운 문제에 적용할 수 있는 능력

2. 아는 것 말고, 이해하는 것

자료구조부터 엔진 내부까지, 설명 가능한 이해

추상화의 역설, 편리함 뒤에 숨은 내용은?

편리함은 그 뒤에 숨겨진 내용에 관심을 가지지 않게 만든다.
생산성은 극도로 높아지지만, 그 결과 다음과 같은 문제가 생긴다.

• 트러블 슈팅의 한계 - 문제가 어디서 발생했는지 추적할 수 없게 된다. 내부를 모르면 표면 증상만 보고 추측에 의존하게 됨
• 사고의 제약 - 도구가 제공하는 방식대로만 문제를 바라보게 된다. "왜 이렇게 동작할까"보다 "어떻게 쓸까"에만 집중
• 내부 복잡도 상승 - 편리한 API 뒤에는 점점 더 큰 복잡도가 쌓인다. 성능, 메모리, 동시성 이슈는 결국 추상화 아래에서 터진다

기본 지식은 한계와 가야 할 길을 알려준다

한계를 알게 해주고, 가야 할 길을 알려준다

• 자료구조와 CS 지식 - 실무 최적화와 트러블슈팅의 핵심 무기
• 개발 언어 - 모든 것을 표현하고 구현하는 방법

위 두 개의 지식을 집중하는 것을 권장한다.
그렇다면 어떠한 환경 속에서도 팀 속도를 따라잡을 수 있다.

좋은 프로그래머는 자료구조와 그 관계를 걱정한다

개발 과정에서 필연적으로 사용 될 수 밖에 없는 자료구조들

std::vector<T>
List<T>
Dictionary<TKey, TValue>
TMap<KeyType, ValueType>

각각의 자료구조를 이해하고 있어야, 언제 어떤 것을 사용 할 지 안다.
그리고 대표적인 자료구조는 한번 구현 해보자

어떻게 쓰는지 질문하면 잘 대답한다.
그러나 어떤 기능을 보여주면서 어떤 자료구조가 알 맞는지 질문하면 60%가 대답을 못 한다.
추상화 되어 있는 내부 구조의 한계도 제대로 살펴보지 않는다.
자료구조를 공부한 다음에 꼭 구현해보길 권장한다.
그렇다면 한계점을 알게 되고 언제, 어떻게 사용할지 알게 된다.

• 일상 생활에서 할 수 있는 자료구조 연습

1. 경기도 행정구 안에 살고 있는 사람들의 목록을 저장하고자 한다면?
   1. 각 행정 시, 군, 구 동 단위로 목록을 추릴 수 있어야 한다.
   2. 사람의 이름으로 검색이 가능해야 한다.
2. 현재 이 공간에 들어온 사람들 간의 관계를 저장하고자 한다면?

Computer Science

언어의 버전은 끊임 없이 올라가고, 게임 엔진도 끊임 없이 발전
프레임 워크는 시대적 흐름에 따라 유행을 타며 계속 바뀜
하지만, 모든 것의 토대가 되는 CS 지식은 수십 년간 변하지 않았고, 현재도 변하지 않고 있음

• CS 지식을 이용해서 문제의 이해와 해결이 가능하다
• ex) 게임 서버에서 사용하는 Thread의 수는 CPU Core의 수에 비례 할까? 왜 그럴까?
• ex) 렌더링 과정에서 Texture의 크기가 2의 거듭제곱인 이유는 무엇일까?
• ex) 남은 메모리보다 작은 공간을 할당하는데 왜 Out of memory 오류가 나는 걸까?
• ex) 부동 소수점 연산을 하는데 왜 같은 식의 결과가 다른 경우가 나올까?

결국 내가 개발 할 때 사용하는 것은 개발 언어

대부분의 게임은 두 언어로 만들어 지고 있음
C++와 C#을 얼마나 잘 알고 있느냐는 내가 만든 결과물의 완성도,
안정성, 성능 모든 것에 영향을 주게 됨
사용해 봤다와 잘 알고 있다(이해하고 있다)는 매우 다른 이야기
언어의 기능들이 왜 나왔고 어떻게 구현됐는지 공부해 보자
ex) 가상함수, 비동기 처리, 템플릿, 제네릭 등

그 문제들이 사라진 것이 아니다

엔진은 수 많은 문제를 “대신” 해결해 주고 있을 뿐, 그 문제가 사라진 것은 아니다.
엔진이 만들어 놓은 추상화에 의해 감춰진 복잡성을 알고 있어야 한계를 만났을 때 우회 할 수 있다.

엔진이 대신 해결해 주는 문제를 찾아보고, 어떻게 해결하고 있는지 알아보자

엔진을 쓸 줄 아는 것과 이해하는 것은 다르다.

Unity

• Garbage Collection이 메모리를 관리 해주고 있으니, 신경 쓰지 않아도 되는걸까?
• MonoBehaviour의 라이프 사이클은 어떻게 동작하지?
• Canvas를 이용한 UI 작업의 주의점은?
• Marshalling이 문제가 되는 이유는 뭘까?
• 리소스 관리는 어떻게 되는 걸까?

Unity Garbage Collection (Mono / IL2CPP)

• Boehm-Demers-Weiser GC: Mark & Sweep, 메모리 영역을 스캔해 포인터로 보이는 값을 모두 참조로 간주
• 관리 힙(Managed Heap)만 대상 - UnityEngine.Native 영역은 별도 관리 해야 함
• 힙은 한 번 커지면 반환되지 않음 (Mono): 피크 사용량이 곧 상주 메모리(중요)

Incremental GC

• Unity 2019+ 옵션: Mark 단계를 여러 프레임에 분할해 GC Spike 완화

할당을 줄이는 것이 정답

• string 처리, boxing, 람다 캡처는 곧 힙 할당 발생
• struct 활용, ArrayPool / ObjectPoll, StringBuilder
• GC.Collect() 강제 호출은 로딩 화면 등 비-실시간 구간에서만

위의 내용은 틀렸다!!! 무엇이 틀렸는지는 스스로 찾아보자!

.NET C# GC

알고리즘

• precise Mark & Sweep + Compaction
• 세대 관리 : Gen0 / Gen1 / Gen2 + LOH

동작 모드

• Workstation / Server, Concurrent / Background GC

메모리 반환

• OS 메모리 반환 가능

Unity GC (Mono / IL2CPP)

알고리즘

• Bohem conservative Mark & Sweep
• Non-generational, Non-compacting > 단편화 발생

동작 모드

• Stop-the-World 또는 Incremental GC (2019+)
• IL2CPP 에서도 동일한 Boehm GC 사용

메모리 반환

• Mono / IL2CPP: 힙이 한 번 커지면 OS 반환?

핵심 차이: 같은 C# 언어를 쓰지만 런타임이 다르다.
세대별 압축 GC vs 보수적 비-압축 GC
Unity의 GC 비용은 .NET 감각으로 추정하면 안 된다.

3. 그리고, 대 AI 시대

AI 시대에 더 중요해지는 질문과 사고 능력

AI는 엔지니어링 능력을 대체하지 않는다

LLM 현재의 현실적 한계 CONTEXT

LLM의 Transformer의 복잡도, 하드웨어의 한계

INFO

context 2배 > 메모리 4배
context 4배 > 메모리 ?배

최적화가 되어 있지 않은 LLM은 1MB 컨텍스트를 유지하기 위해 사용되는 메모리는 TB 단위가 넘는다.

Lost in the Middle, 시작과 끝에 있는 정보는 살아 있으나 중간은 놓치는 경우

Context Contamination Context 사이즈가 커질수록 Attention Score가 희석되어 Hallucination의 증가

Output 크기가 커지면, 인간에 의한 검토가 소홀해질 수 밖에 없음 결국 프로젝트의 크기가 커질수록 완전한 LLM 의존 상태가 되어 버림

기반 지식을 이용한 명확한 프롬프트 지시 처리해야 하는 업무량이 적을수록 작업 성공률이 높아짐 (세분화)

WARNING

~를 하는 코드를 짜줘

TIP

C++ 에서 메모리 단편화를 최소화하는 커스텀 할당자를 적용하고, 멀티스레드 환경에서 안전한 락프리(Lock-free) 자료구조를 사용해 구현해 줘

• 비용 절약
• 작업 시간 절약
• 결과물의 완성도 상승

AI 시대에 잘하는 개발자 = 원래부터 문제 정의와 커뮤니케이션을 잘하는 사람

• 더 중요해진 엔지니어링
• AI가 잘 못 하는 영역에 대한 감각

도메인 특수성이 강한 영역에서 AI는 아직 취약하다. 경계 판단이 실력이다.

• 주니어 프로그래머에게 특히 위험한 함정

AI 코드가 돌아가면 “내가 할 줄 안다”고 착각하기 쉽다.
직접 부딪힌 경험 없이 쌓인 결과물은 내 것이 안 된다.

• AI는 도구, 엔지니어링 능력이 무기

기본기가 없으면 검수도 가이드도 불가능하다.
AI가 틀려도 틀린 줄 모르는 개발자가 된다.

4. 마무리

작은 팁들 그리고 면접의 목표

오늘의 핵심 정리

1. 아는 것 말고, 이해하는 것

사용법이 아니라 동작 원리를 설명할 수 있어야 한다

2. 한계와 트레이드오프까지

왜 그 선택을 했는가, 대안은 무엇이었는가

3. 써봤다 말고, 만들어봤다

자료구조와 핵심 기능은 한 번씩 직접 구현해보자

4. AI는 도구, 본질은 엔지니어링

AI 코드를 평가할 수 있는 사람이 살아남는다

문제 해결 스토리

• 좋은 답변의 구조를 연습하자

1. 문제 - 어떤 문제를 겪어보았는가?
2. 난이도 - 왜 그 문제가 해결하기 어려웠는가?
3. 해결 - 어떻게 해결 했는가?
4. 결과 - 결과는 무엇인가?
5. 회고 - 그 선택의 장, 단점은 무엇인가?

STAR와 CAR 프레임워크 답변 기법
사실 > 판단 > 행동> 결과 > 성찰의 흐름

친구, 동료의 힘을 빌려 보자

내가 만들 때는 적당히 타협 하지만 타인의 눈으로 보면 부족한 부분이 보이기 시작
처음이 어렵고, 두렵지 계속 하다 보면 별 것 아님.

면접의 목표

나와 내 동료등과 함께 일할 새로운 동료를 뽑는 것
면접 내용만으로 평가 했을 때와 우리 조직에 들어와서 함께 한다면을
가정 했을 때 결과가 바뀌는 경우가 있다.