E-1: CS 기술 면접 종합

안녕하세요, 홍순구 튜터입니다. CS 기초 마지막 열두 번째 시간 — 그동안 쌓아 올린 전부를 면접장으로 들고 나가는 종합 정리입니다.

우리는 그동안 네 기둥을 세웠어요. 컴퓨터 구조(A)로 CPU와 메모리가 명령을 처리하는 한 겹 아래를 봤고, 운영체제(B)로 프로세스·스레드·메모리·동기화가 어떻게 자원을 나눠 쓰는지 봤고, 네트워크(C)로 데이터가 계층을 타고 오가는 길을 봤고, 마지막으로 데이터와 자료구조(D)로 트랜잭션과 빅오를 면접 한 입으로 정리했죠. 기둥은 다 섰습니다. 그런데 지난 시간 마지막에 제가 약속한 게 있어요 — 다음엔 이 넷을 따로가 아니라 한 줄기로 엮는다고요. 오늘이 그날입니다.

왜 엮어야 할까요? 면접관은 기둥을 하나씩 따로 묻지 않습니다. "URL을 치면 무슨 일이 일어나나요?" 같은 질문 하나로 네 기둥을 한꺼번에 떠봐요. DNS만 답하면 "그다음은요?"가 꼬리를 물고, 끝까지 막힘없이 풀어내는 사람과 중간에 멈추는 사람이 또렷이 갈립니다. 그래서 오늘은 새 이론을 배우지 않아요. 이미 가진 열한 개의 조각을 면접 시나리오로 꿰는 법, 그리고 꼬리 질문·모르는 질문·내 프로젝트와 잇기까지 — 면접장에 들고 들어갈 마지막 무기를 챙깁니다.

오늘 우리가 걸을 길은 이렇습니다.

   오늘의 여정 — CS 기술 면접 종합

   ① 면접관은 왜 CS 를 묻나 — 좋은 답은 한 줄에서 시작
   ② 꼬리 질문 대비 — "왜?"를 세 번 견디기 (면접 빈출)
   ③ 4축 총정리 ① — 기계 안: 컴퓨터 구조 + 운영체제
   ④ 4축 총정리 ② — 기계 밖: 네트워크 + 데이터·자료구조
   ⑤ 종합 시나리오 — "URL 치면 일어나는 일"로 네 기둥 엮기 (최고 빈출)
   ⑥ 모의 문답 — 면접관이 꼬리를 물 때
   ⑦ 모르는 질문을 만났을 때 — 솔직함과 추론
   ⑧ CS 를 내 프로젝트와 연결해 말하기

①②에서 답하는 법을 잡고, ③④에서 네 기둥 빈출을 한 줄 답변으로 쓸어 담습니다. 그다음 ⑤에서 그 전부를 하나의 시나리오로 엮고, ⑥에서 실전 모의 문답으로 굴려봅니다. 마지막 ⑦⑧에서 막혔을 때와 나만의 무기를 챙기고요.

💡 오늘 수업의 핵심 — "면접관은 외운 단어가 아니라 원리로 추론하는 힘을 본다. 좋은 답은 결론을 먼저 한 줄로 던지고 원리·트레이드오프로 살을 붙이며, 꼬리 질문엔 한 단계 더 깊은 '왜'를 준비한다. 'URL을 치면 일어나는 일' 하나에 컴퓨터 구조·운영체제·네트워크·데이터 네 기둥이 전부 들어 있고, 모르는 질문엔 정직하게 인정한 뒤 아는 것에서 추론으로 다리를 놓는다" 🎯

🎯 학습 목표

• 면접에서 통하는 답변의 골격(결론 먼저 → 원리 → 트레이드오프)을 익히고, 꼬리 질문("왜?"를 세 번)에 한 단계 더 깊은 깊이로 받아냅니다.
• 네 기둥의 면접 빈출 질문(컴퓨터 구조·운영체제·네트워크·데이터/자료구조)에 각각 한 줄 답변으로 답하고, 그 전부를 "URL을 치면 일어나는 일" 하나의 시나리오로 엮어 한 호흡에 풀어냅니다.
• 모르는 질문을 만났을 때의 대처법(정직 + 추론)을 익히고, CS 지식을 내 프로젝트 경험과 연결해 말하는 법을 연습합니다.

Step 1: "면접관은 왜 CS를 묻는가 — 좋은 답은 한 줄에서 시작한다"

면접장에 앉으면 이런 질문을 받습니다. "프로세스와 스레드의 차이가 뭐죠?", "캐시가 왜 빠른가요?", "인덱스를 걸면 왜 조회가 빨라지죠?" 신입 개발자 기술 면접에서 CS 질문은 거의 빠지지 않아요. 그런데 면접관이 이걸 물어서 진짜 보려는 것은 정의를 외웠는지가 아닙니다.

면접관이 보는 건 한 겹 아래예요. 프레임워크 사용법은 누구나 익힙니다. 하지만 "그 코드가 컴퓨터 안에서 실제로 어떻게 도는가"를 아는 사람은 장애를 만났을 때, 성능 문제를 만났을 때 원리에서 답을 끌어냅니다. 면접관은 CS 질문 하나로 "이 지원자가 외운 사람인가, 추론하는 사람인가"를 가늠하는 거예요.

그래서 같은 질문에도 답이 갈립니다.

   같은 질문, 다른 답

   질문: "캐시가 왜 빠른가요?"

   외운 답  →  "캐시는 빠른 메모리입니다."
               (면접관: 그래서 왜 빠른데요? → 막힘)

   원리 답  →  "CPU 바로 옆에 있는 빠른 저장소라,
               자주 쓰는 데이터를 미리 담아두면
               느린 RAM 까지 안 가도 되거든요.
               지역성 덕에 적중률이 90% 를 넘어요."
               (면접관: 꼬리를 물 거리가 생김 → 대화가 이어짐)

좋은 답변의 골격 — 결론 먼저, 그다음 원리

면접 답변에는 통하는 형태가 있습니다. 길게 늘어놓다 길을 잃지 말고, 결론을 먼저 한 문장으로 박은 뒤 살을 붙이세요.

   답변 골격 — 세 박자

   ① 결론 먼저       한 문장으로 핵심을 던진다
        │            "TCP 는 신뢰성, UDP 는 속도입니다."
        ▼
   ② 원리 한 호흡    왜 그런지를 이어 붙인다
        │            "TCP 는 3-way handshake 로 연결을 확인하고
        │             순서·재전송을 보장하느라 느리고,
        │             UDP 는 그걸 생략해 빠릅니다."
        ▼
   ③ 트레이드오프    언제 무엇을 쓰는지로 마무리
                     "그래서 파일 전송엔 TCP,
                      실시간 영상·게임엔 UDP 를 씁니다."

이 세 박자가 몸에 붙으면, 어떤 질문이 와도 당황하지 않습니다. 일단 결론 한 줄을 던지고 시작하면 머릿속이 정리되거든요. 면접관도 두괄식 답을 좋아합니다 — 핵심을 먼저 듣고, 더 궁금하면 파고들면 되니까요.

🎯 면접에서는 이렇게 답하세요

질문: "기술 면접에서 좋은 답변이란 어떤 건가요?" (자기소개 뒤 워밍업으로 자주 나옵니다)

"저는 결론을 먼저 한 문장으로 던지고, 그 뒤에 원리와 트레이드오프로 살을 붙이는 방식을 선호합니다. 예를 들어 'TCP와 UDP의 차이'를 물으시면 먼저 '신뢰성과 속도의 차이'라고 결론을 말하고, 왜 TCP가 신뢰성을 보장하느라 느린지, 그래서 각각 어디에 쓰는지를 이어 붙입니다. 외운 정의를 나열하기보다 원리로 추론하는 모습을 보여드리는 게 핵심이라고 생각합니다."

Step 2: "꼬리 질문 대비 — '왜?'를 세 번 견디기"

면접에서 진짜 변별이 일어나는 곳은 첫 질문이 아니라 꼬리 질문입니다. 면접관은 답을 들으면 곧바로 "왜요?"를 던져요. 그 "왜"를 두세 번 견디면 깊이가 드러나고, 외운 깊이의 끝에서 멈추면 그것도 드러납니다.

한 가지 예로 따라가 봅시다. D-2에서 본 인덱스를 면접관이 물었다고 해볼게요.

   "왜?"를 세 번 파고드는 꼬리 질문 — 인덱스

   면접관: "인덱스를 걸면 왜 조회가 빨라지나요?"
     └─ 1겹  "책 뒤 색인처럼, 전체를 훑지 않고
              바로 위치를 찾으니까요. O(n) 이 O(log n) 으로요."

       면접관: "왜 O(log n) 이죠?"
         └─ 2겹  "인덱스를 B+트리로 만들기 때문입니다.
                  트리를 한 단계 내려갈 때마다 후보가 줄거든요."

           면접관: "트리가 왜 한 단계마다 줄어드나요?"
             └─ 3겹  "각 노드가 가지를 여러 개로 쪼개서,
                      한 번 비교할 때마다 봐야 할 범위가
                      절반(혹은 그 이하)으로 깎이기 때문입니다.
                      그래서 깊이가 데이터 수의 로그에 비례해요."

3겹까지 막힘없이 내려가면 면접관은 "이 사람은 인덱스를 외운 게 아니라 이해했구나" 하고 판단합니다. 보통 꼬리 질문은 2~3겹에서 멈춰요. 그러니 면접 준비는 "정의를 안다"가 아니라 "한 단계 더 깊은 '왜'를 준비한다"가 되어야 합니다.

한 단계 더 — 빈출 개념마다 '왜'의 바닥을 준비

모든 개념을 무한히 파고들 순 없습니다. 대신 빈출 개념 몇 개만 골라, 그 개념의 "왜"를 두세 겹 미리 내려가 두세요. 예를 들면 이런 사슬을 준비합니다.

• "프로세스와 스레드가 왜 다른가" → "스레드는 왜 메모리를 공유하나" → "공유하면 왜 동기화가 필요한가"
• "HTTPS가 왜 안전한가" → "TLS가 어떻게 암호 통로를 만드나" → "그 키 교환은 왜 도청돼도 안전한가"
• "해시 테이블이 왜 평균 O(1)인가" → "그럼 충돌이 나면 어떻게 되나" → "충돌이 많으면 최악 O(n)이 되는 이유는"

이렇게 미리 바닥을 다져두면, 꼬리 질문이 와도 한 칸씩 침착하게 내려갈 수 있습니다.

🎯 면접에서는 이렇게 답하세요

질문: "면접관이 '왜요?'를 계속 물으면 어디까지 답해야 하나요?" (면접 후기에서 가장 많이 나오는 고민입니다)

"저는 빈출 개념마다 '왜'를 두세 겹 미리 준비해 둡니다. 인덱스라면 '색인이라 빠르다'에서 멈추지 않고, 'B+트리라서 O(log n)이고, 트리는 한 단계마다 후보가 줄어서 깊이가 로그에 비례한다'까지요. 꼬리 질문은 대개 2~3겹에서 멈추기 때문에, 한 단계 더 깊은 '왜'를 준비하는 게 외운 사람과 이해한 사람을 가르는 지점이라고 생각합니다. 만약 더 내려가서 모르는 곳에 닿으면, 솔직히 인정하고 아는 데까지 추론으로 잇습니다."

Step 3: "4축 빈출 총정리 ① — 기계 안: 컴퓨터 구조 + 운영체제"

이제 네 기둥의 면접 빈출을 한 줄 답변으로 쓸어 담습니다. 새로 배우는 게 아니라, 그동안 배운 걸 면접용 한 문장으로 압축하는 거예요. 먼저 "기계 안" 두 기둥 — 컴퓨터 구조(A)와 운영체제(B)입니다. 이 둘이 면접에서 가장 깊게 파고드는 영역이에요.

컴퓨터 구조(A) — 빈출 세 개

A의 면접 척추는 "캐시가 왜 빠른가"예요. A-2에서 본 메모리 계층과 지역성을 떠올리면 됩니다 — CPU는 빠른데 RAM이 느린 폰노이만 병목을, 자주 쓰는 데이터를 가까이 둬서 메우는 거죠.

운영체제(B) — 빈출 네 개

B는 모듈이 넷(B-1~B-4)이었던 만큼 빈출도 가장 많습니다. 특히 프로세스 vs 스레드는 면접 1순위예요. "프로세스는 소유, 스레드는 실행"이라는 한 줄을 먼저 던지고, 공유하는 것(코드·데이터·힙)과 따로 갖는 것(스택·레지스터)을 이어 붙이면 깔끔합니다.

🎯 면접에서는 이렇게 답하세요

질문: "프로세스와 스레드의 차이를 설명해 주세요." (운영체제 질문의 1순위)

"프로세스는 독립된 메모리 공간을 가진 자원 소유의 단위이고, 스레드는 그 안에서 코드·데이터·힙을 공유하며 도는 실행의 단위입니다. 스레드는 스택과 레지스터, 프로그램 카운터만 따로 갖죠. 그래서 같은 프로세스의 스레드끼리는 통신이 쉽지만 메모리를 공유하는 만큼 동기화가 필요하고, 프로세스끼리는 독립적이라 안전하지만 컨텍스트 스위칭 비용이 더 큽니다. 크롬이 탭마다 프로세스를 띄우는 건 안정성을, 워드가 멀티스레드인 건 효율을 택한 예입니다."

Step 4: "4축 빈출 총정리 ② — 기계 밖: 네트워크 + 데이터·자료구조"

이제 "기계 밖" 두 기둥입니다. 데이터가 오가는 길인 네트워크(C)와, 그 데이터를 다루는 데이터베이스·자료구조(D)예요.

네트워크(C) — 빈출 네 개

C의 척추는 TCP vs UDP(C-1)와 URL을 치면 일어나는 일(C-3)이에요. 뒤의 것은 오늘 Step 5의 주인공이라 여기선 짧게만 짚고 넘어갑니다.

데이터·자료구조(D) — 빈출 네 개

D는 인접 과목(database·data-structures-algorithms)과 겹치는 영역이라, 면접에선 "원리와 트레이드오프로 답할 수 있다"까지가 목표예요. SQL을 직접 짜거나 자료구조를 구현하는 깊이는 그 과목들의 몫입니다. 면접관이 "인덱스를 어떻게 거나요"를 물으면 문법이 아니라 "왜 빨라지고 무엇을 대가로 치르나"로 답하면 됩니다.

🎯 면접에서는 이렇게 답하세요

질문: "TCP와 UDP의 차이를 설명해 주세요." (네트워크 질문의 단골)

"TCP는 신뢰성을, UDP는 속도를 택한 프로토콜입니다. TCP는 통신 전에 3-way handshake로 연결을 확인하고, 순서를 보장하고, 빠진 패킷을 재전송하느라 그만큼 느립니다. UDP는 그 절차를 모두 생략해서 빠르지만 도착이나 순서를 보장하지 않죠. 그래서 끊기면 안 되는 파일 전송·웹 페이지엔 TCP를, 조금 빠져도 실시간성이 중요한 영상 통화·온라인 게임엔 UDP를 씁니다. 참고로 UDP의 빠름 위에 신뢰성을 다시 얹어 만든 게 HTTP/3의 QUIC고요."

Step 5: "종합 시나리오 — 'URL을 치면 일어나는 일'로 네 기둥을 한 줄기로"

오늘의 중심입니다. 지금까지 네 기둥의 빈출을 따로따로 봤죠. 이제 하나의 시나리오 안에 네 기둥을 전부 집어넣습니다. 그 시나리오가 바로 C-3에서 걸었던 "URL을 치면 일어나는 일"이에요. 이 질문이 면접 최고 빈출인 이유가 여기 있습니다 — 면접관은 이 하나로 컴퓨터 구조·운영체제·네트워크·데이터를 한꺼번에 떠볼 수 있거든요.

C-3에서는 이 여정을 네트워크 관점으로 걸었습니다. 오늘은 같은 여정에 나머지 세 기둥의 라벨을 얹어서, 한 단계 한 단계가 어느 기둥을 부르는지 보겠습니다.

   "URL 을 치면 일어나는 일" 에 네 기둥이 전부 들어 있다
   ( [A] 컴퓨터 구조  [B] 운영체제  [C] 네트워크  [D] 데이터·자료구조 )

   ① URL 입력·분해
        │  [A] CPU 가 입력 문자열을 파싱한다
        ▼
   ② DNS 조회
        │  [C] 도메인 이름 → IP, 루트·TLD·권한 서버 계층 질의
        │  [A] 한 번 찾은 결과는 캐시에 담아 다음엔 건너뛴다
        ▼
   ③ TCP 3-way handshake
        │  [C] SYN → SYN+ACK → ACK 로 연결 통로를 연다
        ▼
   ④ TLS 핸드셰이크
        │  [C] https 면 암호 통로까지 얹는다
        ▼
   ⑤ HTTP 요청 전송
        │  [C] "이 자원(페이지) 줘" — GET 요청
        ▼
   ⑥ 서버가 요청을 받는다
        │  [B] 서버 프로세스가 듣고 있다가 요청을 받는다
        │  [B] 스레드 풀에서 스레드 하나가 깨어나 이 요청을 맡는다
        ▼
   ⑦ 서버 앱 로직·DB 조회
        │  [D] 인덱스(B+트리)로 필요한 행을 O(log n) 으로 찾는다
        │  [A] 캐시에 있으면 디스크 안 가고 RAM 에서 바로 돌려준다
        │  [B] DB 응답을 기다리는 동안 스레드는 잠시 대기 상태로
        ▼
   ⑧ HTTP 응답 생성·전송
        │  [C] HTML·CSS·JS·이미지(혹은 JSON)가 돌아온다
        ▼
   ⑨ 브라우저 렌더링
        │  [A] CPU·GPU 가 글자 덩어리를 화면 픽셀로 그린다
        │  [D] HTML 을 DOM 이라는 트리 자료구조로 파싱한다

보이시나요? 주소창에 URL 하나를 친 그 한순간에 — 네트워크가 길을 찾고(C), 운영체제가 서버에서 프로세스·스레드로 요청을 처리하고(B), 데이터베이스가 인덱스로 조회하고(D), CPU와 캐시가 그 모든 계산을 받쳐줍니다(A). 네 기둥이 따로 노는 게 아니라 하나의 흐름 위에서 맞물려 돌아가는 거예요.

면접에서 "URL을 치면 무슨 일이 일어나나요?"를 받으면, 잘하는 사람은 이 전체 골격을 먼저 한 호흡에 던지고(Step 1의 두괄식!), 면접관이 파고드는 단계를 깊이 설명합니다. "DNS요"에서 멈추지 않고 "DNS로 IP를 찾고 → TCP·TLS로 연결하고 → HTTP로 요청·응답하고 → 렌더링한다"를 통째로 말한 뒤, 면접관이 "DNS가 느리면요?" 하고 꼬리를 물면 거기서 캐시(A)로, "서버는 그동안 뭐 하나요?" 하면 프로세스·스레드(B)로 내려가는 거죠.

🎯 면접에서는 이렇게 답하세요

질문: "브라우저에 URL을 입력하면 화면이 뜨기까지 무슨 일이 일어나나요?" (기술 면접 최고 빈출)

"크게 일곱 단계입니다. 먼저 URL을 분해하고, DNS로 도메인을 IP로 바꾸고, 그 IP의 서버와 TCP 3-way handshake로 연결을 연 뒤, https면 TLS로 암호 통로까지 얹습니다. 그다음 HTTP 요청을 보내면 서버가 받아서 — 운영체제 관점에선 스레드 하나가 요청을 맡고 — 앱 로직을 돌리고 DB를 인덱스로 조회해 응답을 만들어 돌려주죠. 마지막으로 브라우저가 받은 HTML을 DOM 트리로 파싱하고 화면에 렌더링합니다. 이 한 흐름에 네트워크·운영체제·데이터베이스·컴퓨터 구조가 전부 들어 있어서, 어느 단계든 더 깊이 파고들 수 있습니다."

Step 6: "모의 문답 — 면접관이 꼬리를 물 때"

Step 5에서 전체 지도를 그렸으니, 이제 그 위에서 실전 대화가 어떻게 굴러가는지 봅시다. 면접은 일문일답이 아니라 하나의 답에서 꼬리가 뻗는 대화예요. 아래는 "URL을 치면 일어나는 일"에서 시작해 네 기둥을 넘나드는 모의 문답입니다. 면접관이 어떻게 파고들고, 좋은 답이 어떻게 받아내는지 따라가 보세요.

   모의 면접 — "URL 을 치면 일어나는 일" 에서 시작

   면접관: URL 을 치면 무슨 일이 일어나죠?
   지원자: (전체 골격을 한 호흡에 던진다)
           DNS → TCP·TLS → HTTP 요청 → 서버 처리 → 응답 → 렌더링입니다.

     면접관: DNS 조회가 매번 일어나면 느리지 않나요?       ← 꼬리 1 [C→A]
     지원자: 그래서 캐시를 씁니다. 한 번 찾은 도메인→IP 는
             브라우저·OS·리졸버에 잠시 담아 두고 다음엔 건너뜁니다.

       면접관: 그 캐시는 컴퓨터 어디에 있나요?              ← 꼬리 2 [A]
       지원자: 계층마다 다른데, CPU 가 자주 쓰는 데이터를
               빠르게 꺼내는 원리는 똑같습니다. 가까운 빠른
               저장소에 미리 둬서 느린 곳까지 안 가게요.

     면접관: 서버는 요청을 받으면 그동안 뭘 하나요?          ← 꼬리 3 [C→B]
     지원자: 서버 프로세스가 듣고 있다가, 스레드 풀에서
             스레드 하나가 깨어나 이 요청을 맡습니다.

       면접관: 요청이 동시에 만 개 오면요?                  ← 꼬리 4 [B]
       지원자: 스레드 풀 크기가 한계라, 다 못 받으면 큐에서
               대기하거나 거절합니다. 스레드를 무한히 늘리면
               컨텍스트 스위칭 비용으로 오히려 느려지고요.

     면접관: 서버가 DB 를 조회할 때 느리면 어떻게 하죠?      ← 꼬리 5 [B→D]
     지원자: 먼저 인덱스가 걸렸는지 봅니다. 없으면 풀 스캔
             O(n) 이라, 인덱스로 O(log n) 으로 줄입니다.
             그래도 느리면 자주 찾는 결과를 캐시에 둡니다.

한 질문에서 시작해 C → A → B → D를 자연스럽게 넘나들죠? 각 꼬리 질문의 답이 사실 Step 3·4에서 정리한 그 한 줄 답변들입니다. 그래서 네 기둥을 따로 외우는 것보다 하나의 시나리오로 엮어 두는 게 실전에서 강한 거예요 — 면접관이 어디를 찔러도, 지금 어느 기둥에 서 있는지만 알면 그 기둥의 답으로 내려가면 되니까요.

핵심은 흐름을 잃지 않는 것입니다. 꼬리 질문이 깊어져도 "지금 나는 URL 여정의 어느 단계, 어느 기둥에 있다"는 위치 감각만 있으면 길을 잃지 않아요.

🎯 면접에서는 이렇게 답하세요

질문: "꼬리 질문이 예상 못 한 방향으로 가면 당황하지 않나요?" (압박 면접 대비 질문)

"꼬리 질문이 깊어져도 제가 지금 어느 맥락에 서 있는지를 놓치지 않으려 합니다. 예를 들어 'URL을 치면'에서 시작했다면, DNS를 묻든 서버 처리를 묻든 그게 전체 여정의 어느 단계인지를 먼저 떠올립니다. 그러면 네트워크에서 컴퓨터 구조로, 운영체제로 질문이 넘어가도 같은 흐름 위에서 답할 수 있습니다. 모르는 지점에 닿으면 솔직히 인정하고, 아는 단계에서 추론으로 잇습니다. 당황해서 흐름을 놓치는 것보다 침착하게 위치를 잡는 게 중요하다고 생각합니다."

Step 7: "모르는 질문을 만났을 때 — 솔직함과 추론"

면접을 준비할수록 두려운 건 모르는 질문입니다. 그런데 분명히 말씀드릴게요 — 모든 걸 아는 신입은 없습니다. 면접관도 그걸 압니다. 그래서 모르는 질문은 "지식의 양"이 아니라 "모를 때 어떻게 행동하는가"를 보는 질문이에요. 여기서 오히려 점수를 딸 수 있습니다.

가장 나쁜 건 지어내는 것입니다. 모르는데 아는 척 단정하면, 꼬리 질문 한 번에 무너지고 신뢰를 통째로 잃어요. 면접관은 그 분야 전문가라 지어낸 답을 대번에 알아봅니다.

좋은 대처는 세 박자예요.

   모르는 질문 대처 — 세 박자

   ① 솔직하게 인정      "그 부분은 정확히는 모르겠습니다."
        │               (지어내지 않는다 — 신뢰의 출발)
        ▼
   ② 아는 것에서 출발   "다만 제가 아는 것에서 추론해 보면,"
        │               (관련된 원리·개념으로 다리를 놓는다)
        ▼
   ③ 추론으로 잇기      "~ 원리상 이렇게 동작하지 않을까 싶습니다.
                        맞는지 확인해 보고 싶습니다."
                        (열린 태도로 마무리)

예를 들어 들어본 적 없는 기술을 물었다고 해봅시다. "그 기술은 써본 적이 없습니다. 다만 이름과 맥락으로 추론하면, 아마 캐싱 계층의 한 종류 같은데 — 자주 쓰는 데이터를 가까이 두는 원리라면 제가 아는 캐시와 비슷하게 동작할 것 같습니다. 정확한 동작은 찾아보고 싶네요." 이렇게 답하면, 모르는 걸 인정하면서도 추론하는 사고력과 배우려는 태도를 동시에 보여줍니다.

면접관이 진짜 보는 게 이거예요. 모르는 기술은 입사 후에 배우면 됩니다. 하지만 모르는 걸 만났을 때 추론으로 다리를 놓는 힘은 쉽게 안 길러지거든요. 그게 있는 사람은 어떤 새 기술 앞에서도 무너지지 않으니까요.

🎯 면접에서는 이렇게 답하세요

질문: "혹시 ○○○에 대해 아시나요?" (들어본 적 없는 기술이 나왔을 때)

"그건 직접 다뤄본 적이 없어 정확히는 모르겠습니다. 다만 이름과 맥락으로 추론해 보면, ○○○일 것 같은데 — 제가 아는 △△ 원리와 비슷하다면 이렇게 동작하지 않을까 싶습니다. 확실하진 않으니 입사 후 꼭 확인해 보고 싶습니다. 모르는 부분을 솔직히 말씀드리는 게 맞다고 생각했습니다."

Step 8: "CS를 내 프로젝트와 연결해 말하기"

마지막 무기입니다. 지금까지 네 기둥의 원리를 정리했죠. 그런데 면접에서 가장 강한 답은 원리에 내 경험이 붙은 답이에요. "캐시는 자주 쓰는 데이터를 가까이 둡니다"는 누구나 말합니다. 하지만 "제 프로젝트에서 조회가 느려서 자주 보는 데이터를 캐시에 뒀더니 응답이 빨라졌습니다"는 그 사람만 말할 수 있어요.

면접관이 "프로젝트에서 가장 고민한 기술적 결정은?"을 묻는 이유가 여기 있습니다. 추상 지식은 외울 수 있지만, 내 손으로 겪은 문제와 그걸 원리로 푼 경험은 지어낼 수 없거든요. 그래서 CS 지식을 추상으로만 두지 말고, 내 프로젝트의 한 장면과 연결해 두세요.

   추상 지식 → 내 경험으로 잇기

   추상 (누구나)              내 경험 (나만)
   ─────────                 ─────────────
   인덱스는 조회를 빠르게     "목록 조회가 느려서 WHERE 컬럼에
                             인덱스를 걸었더니 응답이 줄었어요"

   트랜잭션은 원자성 보장     "결제와 재고 차감을 한 트랜잭션으로
                             묶어, 하나만 실패해도 함께 롤백되게 했어요"

   캐시는 가까운 데 둬서 빠름  "매번 DB 가던 인기 데이터를 캐시에
                             올려 조회 부하를 줄였어요"

   N+1 은 쿼리 폭발           "목록마다 쿼리가 따로 나가던 걸
                             한 번에 모아 가져오게 바꿨어요"

연결하는 방법은 간단해요. 내 프로젝트를 떠올리며 "여기서 어떤 CS 원리가 쓰였지?"를 되짚는 겁니다. 조회 성능을 고민했다면 인덱스·캐시·빅오가, 동시 요청을 다뤘다면 스레드·동기화·데드락이, API를 설계했다면 HTTP·REST·무상태가 거기 있었을 거예요. 그 장면 하나를 "문제 상황 → 원리로 판단 → 해결 → 결과"로 정리해 두면, 면접에서 그 한 장면이 가장 설득력 있는 답이 됩니다.

이게 우리가 이 과목을 처음 시작할 때 했던 약속이기도 해요. "내가 짠 코드가 컴퓨터 안에서 실제로 어떻게 도는지" 한 겹 아래를 본다는 것 — 그 한 겹이 바로, 내 프로젝트를 원리로 설명할 수 있는 힘입니다.

🎯 면접에서는 이렇게 답하세요

질문: "프로젝트에서 가장 고민했던 기술적 결정을 하나 말씀해 주세요." (프로젝트 면접의 핵심)

"조회 성능을 고민한 적이 있습니다. 목록 화면을 띄울 때 항목마다 쿼리가 따로 나가는 N+1 문제로 응답이 느렸는데, 원인을 보니 연관 데이터를 매번 개별 조회하고 있더군요. 그래서 필요한 데이터를 한 번에 모아 가져오도록 바꾸고, 자주 조회되는 컬럼엔 인덱스를 걸었습니다. 풀 스캔 O(n)이 인덱스 덕에 줄면서 응답이 눈에 띄게 빨라졌어요. 이 경험으로 '왜 느린가'를 빅오와 쿼리 수로 따져보는 습관이 생겼습니다."

마무리

CS 기초의 마지막 시간이자, 이 과목 전체의 마지막 시간입니다. 열두 번의 여정을 함께 걸어주셔서 정말 고생 많으셨어요.

오늘 배운 핵심 세 가지

1. 🎯 좋은 답은 한 줄에서 시작한다 — 결론을 먼저 던지고 원리·트레이드오프로 살을 붙이며, 꼬리 질문("왜?"를 세 번)엔 한 단계 더 깊은 '왜'를 준비합니다.
2. 🎯 네 기둥은 'URL을 치면 일어나는 일' 하나로 엮인다 — 컴퓨터 구조·운영체제·네트워크·데이터가 따로가 아니라, 하나의 시나리오 위에서 맞물려 돌아갑니다. 어디를 찔려도 내 위치만 알면 그 기둥의 답으로 내려갈 수 있어요.
3. 🎯 모르면 솔직하게, 그리고 추론으로 — 지어내지 말고 인정한 뒤 아는 것에서 다리를 놓습니다. 그리고 CS 원리를 내 프로젝트 경험과 이으면 가장 강한 답이 됩니다.

이제 면접장으로

돌아보면 우리는 정말 멀리 왔습니다. 컴퓨터의 구성과 2진수에서 출발해(A), 운영체제가 프로세스·스레드·메모리·동기화를 다루는 법을 봤고(B), 데이터가 네트워크 계층을 타고 오가는 길을 걸었고(C), 트랜잭션과 빅오로 데이터를 다루는 면접 감각을 잡았죠(D). 그리고 오늘, 그 전부를 한 줄기로 엮어 면접장에 들고 갈 무기로 만들었습니다.

이제 여러분은 "내가 짠 코드가 컴퓨터 안에서 실제로 어떻게 도는지" 한 겹 아래를 들여다볼 수 있고, 면접관이 그 한 겹을 물어도 원리부터 풀어 답할 수 있습니다. 외운 단어가 아니라 추론하는 힘으로요.

마지막으로 한 가지만 당부할게요. 면접은 시험이 아니라 대화입니다. 모든 걸 완벽히 답하려 하지 말고, 아는 건 원리로 풀고 모르는 건 솔직히 인정하며 추론으로 잇는 — 그 침착한 태도가 결국 가장 좋은 인상을 남깁니다. 오늘 챙긴 무기를 믿고, 자신 있게 면접장에 들어가세요. 그동안 정말 고생 많으셨습니다. 응원하겠습니다!

과제

오늘 배운 면접 대비 무기를 실제로 손에 쥐어보는 과제입니다. 머리로 아는 것과 입으로 막힘없이 나오는 것은 전혀 다르니, 반드시 소리 내어 연습해 보세요.

[기초] 네 기둥 빈출, 한 줄 답변으로 직접 써보기

Step 3·4에서 정리한 빈출 질문 중 네 기둥에서 하나씩(컴퓨터 구조·운영체제·네트워크·데이터/자료구조) 골라, 각각 Step 1의 답변 골격(결론 먼저 → 원리 → 트레이드오프)으로 한 줄 답변을 직접 작성해 보세요. 교안의 표를 그대로 베끼지 말고, 반드시 내 말로 다시 써보는 것이 핵심입니다. 다 쓴 뒤엔 소리 내어 읽으며 어색한 곳을 다듬어 보세요.

[응용] "URL을 치면 일어나는 일" 5분 스크립트

Step 5의 통합 다이어그램을 보지 않고, "URL을 치면 일어나는 일"을 처음부터 끝까지 내 말로 설명하는 5분짜리 스크립트를 작성해 보세요. 각 단계마다 어느 기둥(A·B·C·D)이 일하는지 라벨을 붙이는 것이 조건입니다. 완성했다면 빈 화면이나 거울을 보고 실제로 5분간 소리 내어 말해 보고, 막히는 단계가 어디인지 표시해 두세요. 그 막히는 단계가 여러분이 가장 보강해야 할 곳입니다.

[심화] 꼬리 질문 3겹 + 모르는 질문 시뮬레이션

두 가지를 묶어 연습합니다. ① 빈출 개념 하나를 골라(예: 인덱스, 캐시, 데드락, HTTPS) "왜?"를 세 번 파고든 답변 사슬을 직접 만들어 보세요(Step 2의 인덱스 예시처럼 1겹 → 2겹 → 3겹). ② 그 사슬의 3겹 끝에서 일부러 모르는 지점에 닿았다고 가정하고, Step 7의 세 박자(인정 → 추론 → 열린 태도)로 받아내는 답변까지 써보세요. 가능하면 스터디원과 면접관·지원자 역할을 바꿔가며 실제로 주고받아 보면 가장 효과적입니다.

생각해볼 주제

정답이 하나로 떨어지지 않는 질문들입니다. 혼자 고민해도 좋고, 스터디원과 토론해도 좋습니다. 면접에서 "이 지원자, 깊게 생각해 봤구나" 하는 인상을 남기는 단골 주제들이에요.

1. "모른다"고 말하는 것과 추론으로 끝까지 답하려는 것 — 그 경계는 어디일까?

Step 7에서 모르는 질문엔 솔직하게 인정하라고 했습니다. 그런데 너무 빨리 "모르겠습니다"를 던지면 준비 부족으로 보이고, 모르는데 끝까지 추론으로 우기면 허세로 보입니다. 어디까지가 정직한 추론이고, 어디부터가 위험한 허세일까요? 면접관 입장에서 "솔직해서 좋다"와 "준비가 안 됐다"를 가르는 기준은 무엇일지 생각해 보세요.

2. CS 원리를 정확히 외운 사람과, 내 프로젝트로 체화한 사람 — 면접관은 누구를 더 신뢰할까?

한 지원자는 교과서적 정의를 토씨 하나 안 틀리고 답합니다. 다른 지원자는 정의는 조금 더듬지만 "제 프로젝트에서 이 문제를 이렇게 겪고 이렇게 풀었다"고 말합니다. 둘 중 누가 더 좋은 평가를 받을까요? 그리고 이상적으로는 둘을 어떻게 함께 가져가야 할지, 면접 준비 전략의 관점에서 고민해 보세요.

3. "URL을 치면 일어나는 일" 같은 종합 질문이, 단편 지식 질문보다 변별력이 높은 이유는?

면접관은 "DNS가 뭔가요?" 대신 "URL을 치면 무슨 일이 일어나나요?"를 즐겨 묻습니다. 단편 지식은 외우면 답할 수 있지만, 종합 질문은 그렇지 않죠. 종합 시나리오 질문이 지원자의 무엇을 더 잘 드러내기에 변별력이 높을까요? 그리고 이런 질문에 강해지려면 평소 공부를 어떤 방식으로 해야 할지, 오늘 배운 "엮어서 이해하기"와 연결해 생각해 보세요.