프로그래밍 면접질문대비 스터디 1주차

📌 CS 기초

---

Q1. GET과 POST의 차이점에 대해서 설명해보세요.

GET과 POST는 HTTP 메서드로, 가장 큰 차이는 데이터를 어디에 담느냐와 목적에 있습니다.

GET은 데이터를 URL의 쿼리스트링에 담아서 서버에 요청합니다. 주로 데이터를 조회할 때 사용하며, URL에 데이터가 노출되기 때문에 민감한 정보 전송에는 적합하지 않습니다. 또한 브라우저에 캐싱될 수 있고, URL 길이 제한이 있어 대용량 데이터 전송이 어렵습니다.

POST는 데이터를 HTTP Body에 담아서 전송합니다. 주로 데이터를 생성하거나 변경하는 작업에 사용하며, Body에 담기 때문에 URL에 노출되지 않아 상대적으로 안전합니다. 또한 데이터 크기 제한도 없습니다.

정리하면, GET은 멱등성이 있어 같은 요청을 여러 번 해도 결과가 동일하지만, POST는 요청마다 서버 데이터가 달라질 수 있습니다.

 

💡 핵심 키워드: 쿼리스트링 vs Body, 조회 vs 생성, 캐싱, 멱등성

 

get은 주로 데이터를 조회할 때 사용하며 데이터를 url의 쿼리스트링에 담아서 서버에 요청합니다
 url은 노출되는 부분이기때문에 민감한 정보 전송에는 적합하지 않습니다.

post 는 주로 데이터를 생성하거나 변경하는 작업에 사용하며 데이터를 HTTP BODY에 담아서 전송합니다. http body는 url에 노출되지 않아 상대적으로는 안전합니다.

---

Q2. 객체 지향 프로그래밍이란 무엇인가요?

객체 지향 프로그래밍, 즉 OOP(Object-Oriented Programming) 는 프로그램을 객체라는 단위로 구성하는 프로그래밍 패러다임입니다. 현실 세계의 사물을 객체로 추상화하여, 객체들 간의 상호작용으로 프로그램을 설계합니다.

현실 세계의 사물을 객체로 추상화하여, 객체들 간의 상호작용으로 프로그램을 설계합니다.

OOP의 핵심 특징은 4가지입니다.

첫째, 캡슐화는 객체의 데이터와 메서드를 하나로 묶고, 외부에서 직접 접근하지 못하도록 은닉하는 것입니다.

둘째, 상속은 부모 클래스의 속성과 메서드를 자식 클래스가 물려받아 재사용성을 높이는 것입니다.

셋째, 다형성은 같은 인터페이스를 가진 메서드가 객체 타입에 따라 다르게 동작하는 것입니다.

넷째, 추상화는 공통된 특성을 추출하여 불필요한 세부 내용을 숨기고, 핵심만 드러내는 것입니다.

이러한 특성 덕분에 코드의 재사용성, 유지보수성, 확장성이 높아집니다.

💡 핵심 키워드: 캡슐화, 상속, 다형성, 추상화, 재사용성

---

Q3. HTTP와 HTTPS의 차이점에 대해서 설명해보세요.

HTTP는 HyperText Transfer Protocol의 약자로, 클라이언트와 서버 간 데이터를 주고받기 위한 통신 규약입니다.

하지만 HTTP는 데이터를 평문(Plain Text) 으로 전송하기 때문에, 중간에 제3자가 데이터를 가로채면 내용이 그대로 노출됩니다.

HTTPS는 HTTP에 SSL/TLS 프로토콜을 추가한 것입니다.

데이터를 암호화하여 전송하기 때문에 중간에 가로채더라도 내용을 알 수 없습니다. 동작 과정에서는 서버가 CA(인증 기관) 으로부터 발급받은 인증서를 클라이언트에 제공하고, 클라이언트는 이를 검증한 후 대칭키를 생성해 암호화 통신을 시작합니다. 이 과정을 TLS Handshake라고 합니다.

또한 HTTPS는 데이터 암호화 외에도 데이터 무결성(전송 중 변조 방지)과 서버 인증(진짜 서버인지 확인)도 보장합니다. 때문에 로그인, 결제 등 민감한 정보를 다루는 서비스에서는 반드시 HTTPS를 사용해야 합니다.

💡 핵심 키워드: SSL/TLS, 암호화, TLS Handshake, CA 인증서, 무결성

 

영지: http는 암호화되지않은 https가 도입된 secure가 붙은 약자로서

http의 데이터를 암호화된 통신 프로토콜이 포함되어있습니다.

좀 더 제3자에게 정보가 노출되지 않을 숭 ㅣㅆ기땜누에

보안에 신경쓴 통신규약

 

? HTTPS 포트번호

HTTP 80 HTTPS 443

 

? 암호화 계층에 대해 간단하게 설명해주세요

TLS Handshake 과정에서 SSL인증서를 서버 공개키로 설정을 하면 클라ㅣ언트가 바아서 검증하고 검증이 끝나면 공개킬호 암호화한 세션키로 전송한 다음에 암호화된 통신을 그떄부터 시작을 해서 핸드쉐이크 해서 연결이 맺어져서 통신이 가능해지는 것

 

? 그럼 HTTP를 사용하는 경우는 뭔가요? HTTPS가 무조건 좋은 거 아닌가요?

서빕스 관점에서는 https가 보안에 상대적으로 좋기 때문에 https를 사용하는 것이 맞다고 보고

서비스가 아닌 내부적으로 런칭이 되지않은 http를 사용하는게 

예전에는 주요 이유가 아마도 인증서 비용과 웹 서버의 부하 때문이었을 것입니다. 하지만 오늘날에는 무료로 인증서를 얻을 수 있고, 클라우드 호스팅도 비교적 저렴합니다. 요즘 방문하는 대부분의 웹사이트는 https를 사용합니다. 더 이상 http만 사용할 이유는 없습니다.

목적에 따라 다르지.
집에서 뭐 테스트하는 거, 별로 안 중요한 거: HTTP
공격자한테 노출될 위험 0인 두 개체 간의 데이터 전송 (예: 별도 네트워크의 두 장치/컨테이너): HTTP
그 외: HTTPS

---

Q4. 자바스크립트는 싱글 스레드인데 어떻게 비동기 처리가 가능한지 설명해보세요.

자바스크립트 엔진은 싱글 스레드로 동작하지만, 비동기 처리가 가능한 이유는 이벤트 루프(Event Loop) 와 Web API 덕분입니다.

구체적으로 설명하면, 자바스크립트 엔진에는 콜 스택(Call Stack) 이 하나 있어서 코드를 순서대로 실행합니다.

그런데 setTimeout이나 fetch 같은 비동기 작업이 들어오면, 이 작업들을 브라우저의 Web API에게 넘깁니다. Web API는 별도의 스레드로 해당 작업을 처리하고, 완료되면 콜백 함수를 태스크 큐(Task Queue) 에 넣습니다.

이벤트 루프는 콜 스택이 비어 있는지 계속 확인하다가, 비어 있으면 태스크 큐에서 콜백을 꺼내 콜 스택에 올려 실행시킵니다.

즉, 자바스크립트 자체는 싱글 스레드지만, 무거운 비동기 작업은 브라우저(또는 Node.js)의 환경에 위임하고, 그 결과만 이벤트 루프를 통해 받아처리하는 구조 덕분에 논블로킹 비동기 처리가 가능한 것입니다.

💡 핵심 키워드: 이벤트 루프, 콜 스택, Web API, 태스크 큐, 논블로킹

 

하연: 자바스크립트 엔진 단독으로 동작하는게 아니라 브라우저나 nodejs같은 런타임 환경

자바스크립트 자체는 싱글스레드이지만 비동기 잡업은 브라우저나 런타임 환경으로 위임됩니다

 

좀 더 상세히 말씀드ㄹ면

settimeout이나 네트워크요청같은 비동기작더을 만나면 

백그라운드로 넘기고 콜스택에서 제거한 이후

작업완료되면 콜백함수를 큐로 보내 대기시킵니다

스택이 비워지면 큐에있던 콜백을 스택으로 올려보내 실행하게됩니다.

큐에도 우선순위가 있다는것

마이크로테스트 큐에들어가고

셋타임아웃은 테스크 큐

이벤트 루프는 마이크로테스크 큐를 비우고 테스크 큐를 처리합니다.

이러한게 중요한 이유는 브라우저환겨에서 js실행과 ui렌더링이 같은 메인 스레드를 공유하기때문인데

무거운 동기작업을 하면 화면을 멈추는 콜백 프로미스 어싱크어웨잇 적절한 비동기처리를 해주어야합니다.

 

? 비동기 처리가 뭔가요?

가스불 하나씩 - 동기처리

가스불 네개 다쓸 수있는데 하나 요리안끝나도 쓸 수있음 - 비동기

비동기는 안기다린다!! 멀티스레드처럼 가스불이 여러개있는거랑은 분리해서 생각해야한다.

기다리지 않

 

? 자바스크립트에서 비동기 처리를 구현하는 방법

setTime out으로 구현할 수 있다고 알고있ㅇ므

settimeout은 비동기를 볼 수 있음

콜백개념이 가장 기본적인 프로미스랑 어싱크어웨잇이 있다.

 

---

📌 백엔드

---

Q5. REST란 무엇인가요?

REST는 Representational State Transfer의 약자로, 웹의 장점을 최대한 활용하기 위한 소프트웨어 아키텍처 스타일입니다.

HTTP를 기반으로 클라이언트와 서버 간의 통신 규칙을 정의합니다.

REST의 핵심 원칙은 크게 6가지가 있는데, 실무에서 중요한 것들을 말씀드리겠습니다.

첫째, 자원(Resource) 기반 URI입니다. 모든 자원은 고유한 URI로 식별되며, 행위가 아닌 명사로 표현합니다. 예를 들어 /users, /users/1 이런 식으로요.

둘째, HTTP 메서드로 행위를 표현합니다. 조회는 GET, 생성은 POST, 수정은 PUT/PATCH, 삭제는 DELETE를 사용합니다.

셋째, 무상태성(Stateless) 입니다. 서버는 클라이언트의 상태를 저장하지 않으며, 매 요청은 독립적으로 처리됩니다.

이런 원칙을 잘 따른 API를 RESTful API라고 하는데, 이를 통해 클라이언트와 서버가 독립적으로 개발되고 확장성이 높은 시스템을 만들 수 있습니다.

💡 핵심 키워드: 자원 기반 URI, HTTP 메서드, 무상태성, RESTful

 

김영재 답변: 
REST란 웹 기반 API를 설계하는 아키텍처이고 자원에 이름을 붙여서 상태를 주고받는 것입니다.

HTTP URI를 통해 자원을 명시하고

GET post put delete등을 통해서 crud를 적용하는 것입니다.

 

? RESTful하지않은 

자원 명시 규칙에 어긋나는 http 메서드 랑 중복되는의미가 들어가ㅓ는 update user find 같은 uri의 일므을 붙이면 restful하지못하다.

 

? PUT PATCH중에 무엇을 쓰는ㄱ ㅓㅅ이 좋을까요

PATCH와 PUT은 자원의 전첼르 바꾸는가 일부를 바꾸는가에 대한 관점 차이인데

크게 차이없다 PATCH 쓰지말라 혼용해서 쓰지말라 통일해서 써라

PUT으로 통일하는 팀도 있고, PATCH를 구분해서 쓰는 팀도 있습니다.
저는 팀 컨벤션에 따르는 게 중요하다고 생각하며, 개인적으로는 단순함을 위해 PUT으로 통일하는 방식도 충분히 합리적이라고 생각합니다."

 

---

Q6. 정규화에 대해 설명해주세요.

정규화란 관계형 데이터베이스에서 데이터 중복을 최소화하고 데이터 무결성을 유지하기 위해 테이블을 설계하는 과정입니다.

목적은 삽입, 수정, 삭제 시 발생하는 이상 현상(Anomaly) 을 방지하는 것입니다.

정규화는 단계별로 이루어집니다.

1NF(제1정규형): 하나의 컬럼에는 원자적인 값(더 이상 나눌 수 없는 값)만 존재해야 합니다. 예를 들어, 전화번호 컬럼에 여러 번호가 들어가면 안 됩니다.

2NF(제2정규형): 1NF를 만족하면서, 부분적 함수 종속을 제거합니다. 즉 복합 기본키에서 일부 키에만 종속된 컬럼을 분리합니다.

3NF(제3정규형): 2NF를 만족하면서, 이행적 함수 종속을 제거합니다. 기본키가 아닌 컬럼이 다른 비기본키 컬럼에 종속되지 않아야 합니다.

다만 정규화를 과도하게 적용하면 조인이 많아져 성능이 저하될 수 있어서, 실무에서는 성능을 위해 의도적으로 중복을 허용하는 역정규화(Denormalization) 를 적용하기도 합니다.

💡 핵심 키워드: 데이터 중복 제거, 이상 현상, 1NF/2NF/3NF, 함수 종속성, 역정규화

---

📌 프론트엔드

---

Q7. 브라우저에서 렌더링 원리에 대해서 설명해보세요.

브라우저의 렌더링 과정은 크게 5단계로 나눌 수 있습니다.

1단계 - 파싱: 브라우저는 서버로부터 받은 HTML을 파싱하여 DOM(Document Object Model) 트리를 생성하고, CSS를 파싱하여 CSSOM(CSS Object Model) 트리를 생성합니다.

2단계 - 렌더 트리 생성: DOM과 CSSOM을 결합하여 실제 화면에 표시될 요소들만 포함한 렌더 트리(Render Tree) 를 만듭니다. display: none인 요소는 렌더 트리에 포함되지 않습니다.

3단계 - 레이아웃(Layout / Reflow): 렌더 트리를 기반으로 각 요소의 위치와 크기를 계산합니다.

4단계 - 페인트(Paint): 계산된 스타일을 기반으로 요소를 실제 픽셀로 화면에 그립니다.

5단계 - 합성(Composite): 여러 레이어를 합쳐 최종 화면을 완성합니다.

추가로, JavaScript가 DOM을 변경하면 리플로우(Reflow) 나 리페인트(Repaint) 가 발생할 수 있어 성능에 영향을 줍니다. 때문에 React 같은 프레임워크는 Virtual DOM을 사용하여 불필요한 렌더링을 최소화합니다.

 

 

1단계 문서파싱

1-1: HTML 파싱 

브라우저는 HTML 문서를 파싱하여 DOM트리(Document Odject Model Tree)를 구성합니다 (DOM트리가뭔가요?)

1-2: CSS 파싱

CSS 파일과 스타일 요소를 파싱하여 CSSOM트리 (CSS Object Model Tree)를 구성합니다.

 

2단계 렌더 트리 생성

구성한 DOM과 CSSOM을 결합하여 렌더트리를 형성합니다.

이 렌더트리는 실제 페이지를 렌더링하는데 필요한 모든 노드와 스타일 정보를 포함합니다.

 

display:none인 요소는 포함하지 않습니다.

visibility:invisible은 공간은 차지하고 보이지 않게만 하기 때문에 렌더 트리에 포함됩니다.

 

3단계 레이아웃 계산

각 노드의 정확한 위치와 크기를 각 속성과 스타일에 따라 어느 위치에 어느 크기로 출력될지 계산합니다

 

4단계 페인트

계산된 레이아웃에 따라 노드를 실제화면에 그립니다. 이때 텍스트, 색, 이미지, 그림자 효과등이 모두 처리됩니다.

 

5단계 페인팅 이후

어떠한 액션이나 이벤트에 따라 수정되면 렌더 트리와 각 요소들의 크기와 위치를 다시 계산하고(Reflow) 다시 출력합니다(Repaint)

이 현상을 줄이기 위해서는 visibility:invisible보다 display:none을 사용하고(공간차지안함)

transform 과  opacity는 Reflow Repaint가 일어나지 않습니다.

따라서 left, right, width, height보다 transform을, visibility보다 display, opacity를 사용하는 것이 도움이 됩니다.

 

완전 최종단계에서 transform 과 opacity를 사용하기 때문에 (2단계에서 일어남) 애니메이션은 transform과 opacity를 사용하는게 성능 면에서 유리하다

 

면접 답변: 

브라우저 렌더링은 HTML, CSS, JavaScript 등의 웹 페이지 자원을 브라우저가 화면에 그리는 과정을 말합니다. 브라우저 렌더링 과정은 HTML문서 파싱하여 DOM트리를 형성하고 CSS문서를 파싱해서 CSSOM트리를 형성하고 DOM트리와 CSSOM트리를 결합하여 렌더트리를 형성합니다. 브라우저는 렌더 트리를 이용해서 각 요소의 크기 위치를 계산하는 레이아웃을 거쳐 화면에 요소를 그리는 페인팅 과정을 거치게 됩니다.

 

? HTML 파싱 중에 스크립트 태그를 만나게 되면 파싱을 멈추고 js가 먼저 실행되는데,

이떄 블로킹되지 않도록 처리하려면 어떻게 해야하는지

 

파싱 블로킹이 되지 않기 위해서는 스크립트 태그를 바디 맨 아래에 두거나

스크립트 태그 안에 defer 라는 속성을 https://weirdsector.tistory.com/55

 

💡 핵심 키워드: DOM, CSSOM, 렌더 트리, Reflow, Repaint, Virtual DOM

 

 

DOM트리

HTML의 각 태그를 노드 객체로 변환하여 계층구조(트리)로 만듭니다.

<!-- 원본 HTML -->
<html>
  <body>
    <h1>안녕하세요</h1>
    <p>반갑습니다</p>
  </body>
</html>

DOM 트리로 변환:

Document
└── html
    └── body
        ├── h1  →  "안녕하세요"
        └── p   →  "반갑습니다"

* JavaScript에서 document.querySelector('h1') 같은 걸 쓸 수 있는 이유가 바로 이 DOM 트리가 만들어졌기 때문

 

CSSOM 트리

CSS파일의 요소에 어떤 스타일이 적용되는지 트리로 표현한 것

body { font-size: 16px; }
h1   { color: blue; }
p    { color: gray; }

CSSOM 트리:

body (font-size: 16px)
├── h1 (color: blue, font-size: 16px 상속)
└── p  (color: gray, font-size: 16px 상속)

* CSS는 상속(Cascading) 이 있기 때문에, 부모에 적용된 스타일이 자식으로 내려가는 것도 CSSOM이 계산

 

왜 두 개를 따로 만드나요?

HTML과 CSS는 역할이 다르기 때문

두 트리를 합쳐서 렌더 트리(Render Tree)를 만들어 그걸 기반으로 출력한다.

 

렌더트리

DOM 트리 + CSSOM 트리 = 렌더 트리
"실제로 화면에 보여줄 것들만" 골라서 스타일까지 붙인 트리

DOM 트리              CSSOM 트리
─────────             ──────────
html                  body
└── body              ├── h1  { color: blue, font-size: 24px }
    ├── h1            ├── p   { display: none }
    ├── p             └── span{ color: gray }
    └── span

           ↓ 결합 (display:none 제외!)

         렌더 트리
         ─────────
         body
         ├── h1   { color: blue, font-size: 24px }
         └── span { color: gray }
         
         ← p는 display:none 이라 렌더 트리에서 제외! ❌

---

Q8. SPA에서 라우팅이 어떻게 동작하나요?

전통적인 MPA(Multi Page Application)에서는 페이지를 이동할 때마다 서버에 새로운 HTML을 요청했습니다.

하지만 SPA(Single Page Application) 에서는 최초에 HTML을 한 번만 받고, 이후 페이지 이동은 JavaScript가 직접 화면을 교체하여 처리합니다.

 

SPA 라우팅 방식에는 크게 두 가지가 있습니다.

 

Hash 방식: URL에서 # 뒤의 값이 바뀌어도 브라우저는 서버에 요청을 보내지 않습니다.

왜 서버 요청이 없냐?
# 뒤의 값(해시)은 원래부터 브라우저 내부에서만 사용하는 값이에요.
서버엔 절대 전송하지 않는 게 브라우저의 규칙입니다.

이를 이용해 JavaScript가 # 이후 값을 읽어 화면을 전환합니다. 예) example.com/#/home

 

(React Router의 방식)

History API 방식: HTML5의 history.pushState() API를 사용하여 URL을 변경하되 서버 요청 없이 화면만 바꿉니다.
이 함수는 "URL은 바꾸되 서버에 요청은 보내지 마" 라는 특별한 명령입니다.

React Router가 이 방식을 사용합니다. 예) example.com/home

// 버튼 클릭 시
document.getElementById('menuBtn').addEventListener('click', () => {
  
  // URL을 /menu 로 바꾸지만 서버 요청 ❌
  history.pushState(null, '', '/menu');
  
  // JavaScript가 직접 화면을 교체
  document.getElementById('app').innerHTML = '<h1>메뉴 페이지</h1>';
});

처음 접속: myapp.com
       ↓
서버가 index.html 딱 한 번 전송
(+ React/Vue 앱 전체 JS 코드 포함)
       ↓
이후부터는 JS가 모든 걸 관리

유저: /menu 클릭
       ↓
┌──────────────────────────────────┐
│  React Router가 중간에서 가로챔   │
│  "서버야 잠깐, 내가 처리할게"     │
└──────────────────────────────────┘
       ↓
history.pushState('/menu') → URL만 변경
       ↓
React가 <MenuPage /> 컴포넌트 렌더링
       ↓
서버 요청 없이 화면 전환 완료! ✅

 

새로고침 문제 (중요!)
History API 방식의 함정이 있어요.

유저가 myapp.com/menu 에서 새로고침 누름
       ↓
브라우저: "서버야, /menu 페이지 줘!"
       ↓
서버: "??? /menu 파일이 없는데..." → 404 에러 💥

History API 방식은 URL이 깔끔하지만, 새로고침 시 서버에 해당 경로로 요청이 가기 때문에 서버에서 모든 경로에 대해 동일한 index.html을 반환하도록 설정해야 합니다. 이를 Fallback 설정이라고 합니다.

서버 설정: "어떤 URL로 요청이 와도 index.html 줘"
       ↓
index.html 받음
       ↓
JS 앱이 로드되면서 URL을 보고 /menu 화면 렌더링 ✅

 

💡 핵심 키워드: History API, pushState, Hash 라우팅, index.html Fallback, React Router

 

"SPA는 최초 접속 시 index.html 하나만 받고, 이후 페이지 이동은 history.pushState() API로 URL만 바꾸고 JavaScript가 화면을 교체합니다. 서버 요청 없이 동작하기 때문에 빠르고 부드럽지만, 새로고침 시 서버에서 404가 나지 않도록 모든 경로에 index.html을 반환하는 Fallback 설정이 필요합니다."

---

프로젝트에서 적용한 사례를 1~2문장 연결하자

아는 부분은 자신있게 모르는 부분은 솔직하게

 

 

피드백 추가질문

 

동기 비동기

promise 

async await