Hacker News 2026.06.01 39

1994년 마이크로소프트 인턴 면접 문제 네 개, 지금 다시 풀어봐도 명작인 이유

30년 전 MS 면접 문제가 왜 지금 다시 회자될까

지금은 게임 엔진 최적화 전문가이자 "Computer, Enhance!" 시리즈로 유명한 케이시 무라토리(Casey Muratori)가 1994년에 마이크로소프트 인턴 면접에서 받았던 네 가지 프로그래밍 문제를 공개했어요. 30년도 더 된 문제인데 지금 봐도 "아, 이게 진짜 좋은 면접 문제구나" 싶은 명문제들입니다. LeetCode 스타일의 알고리즘 퀴즈가 아니라, 진짜로 프로그래머의 사고방식을 보는 문제거든요.

요즘 코딩 면접이라고 하면 다들 LeetCode Hard 문제를 외워서 푸는 분위기잖아요. 그런데 이 1994년 문제들은 정반대예요. 정답이 하나로 정해져 있지 않고, 어떻게 접근하느냐에 따라 면접관과 끝없이 토론할 수 있는 열린 문제들이에요. 케이시는 이걸 "진짜 엔지니어링을 묻는 문제"라고 표현했어요.

네 가지 문제, 어떤 것들이었나

첫 번째 문제는 링크드 리스트를 뒤집는 함수를 작성하라는 거였어요. 너무 단순해 보이죠? 하지만 면접관은 단순히 답만 보는 게 아니라, 재귀로 풀지 반복문으로 풀지, 메모리 할당은 어떻게 처리할지, 빈 리스트나 노드 하나짜리 리스트는 어떻게 다룰지 같은 엣지 케이스를 깊이 파고들었다고 해요. 코드 한 줄 한 줄에 "왜 이렇게 썼느냐"고 물어보는 거죠.

두 번째는 문자열에서 단어 단위로 뒤집기예요. "Hello World"를 "World Hello"로 바꾸는 건데, 이게 뭐냐면 글자 순서는 그대로 두고 단어의 순서만 뒤집는 거예요. 여기서 핵심은 "추가 메모리를 쓰지 않고 in-place로 할 수 있느냐"였어요. 트릭은 전체 문자열을 먼저 뒤집고, 그다음 각 단어를 다시 뒤집는 방식이에요. 이걸 떠올리려면 문자열을 단순히 char의 배열이 아니라 "공간 위의 데이터"로 볼 수 있어야 해요.

세 번째는 이진 트리를 미러링하라는 문제였어요. 좌우 자식을 모두 뒤집어서 거울에 비친 모양으로 만드는 거죠. 재귀로 풀면 우아하지만, 스택 오버플로우를 막으려면 반복문 + 명시적 스택 또는 큐로도 구현할 수 있어야 한다는 걸 보여줘야 했어요.

네 번째 문제가 가장 인상적인데, 메모리 할당 시스템을 직접 설계하라는 거였어요. malloc과 free를 어떻게 구현할 거냐는 질문이에요. 이건 정답이 없어요. 프리 리스트, 버디 시스템, 슬랩 할당, 풀 할당 등등 수많은 트레이드오프가 있고, 면접관은 지원자가 "무엇을 모르는지"와 "어떻게 추론해 나가는지"를 봤다고 해요.

1994년 면접과 2026년 면접의 차이

케이시가 강조하는 포인트는 이거예요. 그 당시 면접은 "외운 답을 맞히는" 자리가 아니었다는 점이에요. 면접관은 화이트보드 앞에 앉아서 같이 문제를 풀어가는 동료였고, 지원자가 막히면 힌트를 주거나 "그 방향은 왜 그렇게 생각했어요?"라고 되묻는 식이었어요. 그래서 사실 면접이 일종의 페어 프로그래밍 세션 같았다고 합니다.

반면에 요즘 빅테크 면접은 굉장히 표준화돼 있어요. 45분에 미디엄~하드 문제 두 개, 시간 안에 동작하는 코드 + 최적 복잡도까지 도달해야 통과. 사람마다 편차를 줄이고 채용 규모를 키우기 위한 효율적인 선택이지만, 그 대가로 "진짜 엔지니어링 사고력"을 보기 어려워졌다는 비판도 많아요. LeetCode 문제집을 외운 사람과, 실제로 시스템을 설계할 줄 아는 사람이 면접 점수상 구분이 잘 안 되는 거죠.

특히 메모리 할당기 같은 문제는 요즘 코딩 면접에서는 거의 안 나와요. 너무 모호하고, 시간 안에 답을 내기 어렵고, 채점하기도 까다롭거든요. 그런데 시스템 프로그래밍이나 게임 엔진, 임베디드 분야에서는 정확히 이런 사고력이 매일 필요해요. 면접 방식이 산업의 일부 능력만 측정하게 된 거예요.

비슷한 흐름의 다른 회사들

Google도 한때 "맨홀 뚜껑은 왜 둥글까" 같은 추론 문제를 냈다가 지금은 다 없앴어요. 효과가 검증되지 않았다는 이유였죠. 반면 Jane Street, Citadel 같은 퀀트 회사들은 여전히 답이 정해지지 않은 열린 문제를 면접에서 많이 써요. 카르마크가 있던 시절의 id Software나 지금의 Epic Games 같은 게임 엔진 회사들도 "메모리 레이아웃을 어떻게 설계할 거냐" 류의 깊은 시스템 문제를 자주 묻는 걸로 알려져 있어요.

한국에서도 토스, 쿠팡 같은 회사들이 코딩 테스트 + 시스템 디자인을 결합한 면접을 많이 쓰는데, 시스템 디자인 단계에서는 이런 1994년식 열린 토론이 일어나는 경우가 많아요. 결국 좋은 면접은 "답을 아는 사람"이 아니라 "같이 일하면 즐거울 사람"을 찾는 자리라는 본질이 변하지 않은 거죠.

한국 개발자에게 주는 시사점

저년차 개발자라면 LeetCode 연습은 당연히 해야겠지만, 거기서 그치지 말고 "왜 이 자료구조를 쓰는가", "메모리는 어떻게 배치되는가", "이 함수가 호출됐을 때 OS 입장에서는 무슨 일이 벌어지는가" 같은 한 단계 아래 질문을 스스로에게 던져보는 게 큰 도움이 돼요. 케이시가 말하는 "진짜 엔지니어"의 사고방식이 그렇거든요.

그리고 면접관 입장에서 일하시는 분들이라면, 이번 사례가 좋은 참고가 될 거예요. "링크드 리스트 뒤집기" 같은 단순한 문제도 깊게 파고들면 후보자의 사고력을 충분히 볼 수 있어요. 굳이 LeetCode Hard를 가져올 필요가 없는 거죠. 오히려 쉬운 문제로 시작해서 "여기서 메모리가 새면 어떻게 되죠?", "멀티스레드 환경이면요?" 같은 식으로 깊이를 더해 가는 게 훨씬 좋은 신호를 줄 수 있어요.