개발이 취미인 사람

[CSS] CSS란 무엇인가 — 웹에서 스타일이 입혀지는 원리

RyanSin — Mon, 23 Mar 2026 10:45:17 +0900

개요

CSS(Cascading Style Sheets)는 HTML로 작성된 웹 문서의 시각적 표현을 담당하는 언어입니다. 이 글에서는 CSS가 왜 존재하는지, HTML과 어떤 관계인지, 브라우저가 CSS를 어떻게 처리하는지를 다룹니다.

1. CSS가 없는 웹

CSS를 이해하려면, 먼저 CSS가 없는 상태를 봐야 합니다.

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="UTF-8">
  <title>CSS 없는 페이지</title>
</head>
<body>
  <h1>안녕하세요</h1>
  <p>이것은 CSS가 없는 HTML 문서입니다.</p>
  <a href="#">링크입니다</a>
  <ul>
    <li>항목 1</li>
    <li>항목 2</li>
  </ul>
  <button>버튼</button>
</body>
</html>

이 HTML을 브라우저에서 열면 아무 스타일도 작성하지 않았는데 다음과 같이 보입니다:

<h1>은 크고 굵은 글씨
<p>는 위아래 여백이 있는 문단
<a>는 파란색 밑줄
<ul>은 점 마커가 있는 리스트
<button>은 회색 테두리 버튼

왜? 브라우저가 자체적으로 가지고 있는 기본 스타일(User Agent Stylesheet) 때문입니다. CSS를 하나도 작성하지 않아도 브라우저가 HTML 태그마다 기본 CSS를 적용합니다.

다음 편(01편)에서 태그별 기본 스타일을 상세히 다룹니다.

2. CSS란 무엇인가

한 문장 정의

CSS는 HTML 요소의 "어떻게 보일지"를 정의하는 스타일 언어입니다.

역할 분리

웹은 세 가지 언어가 역할을 나눠 맡습니다.

언어	역할	비유
HTML	구조 (Structure)	건물의 뼈대 (기둥, 벽, 방)
CSS	표현 (Presentation)	인테리어 (페인트, 가구 배치, 조명)
JavaScript	동작 (Behavior)	전기/배관 시스템 (스위치, 엘리베이터)

백엔드로 비유하면:

웹	백엔드 비유
HTML	데이터 스키마 (테이블 구조)
CSS	포맷터/시리얼라이저 (응답을 어떻게 보여줄지)
JavaScript	비즈니스 로직

핵심: HTML은 "무엇이 있는지", CSS는 "어떻게 보이는지"를 담당합니다. 이 분리가 웹의 기본 설계 원칙입니다.

3. CSS의 기본 문법

CSS는 선택자(Selector)와 선언(Declaration)으로 구성됩니다.

/* 선택자 { 속성: 값; } */

h1 {
  color: #2563eb;
  font-size: 32px;
  margin-bottom: 16px;
}

구성 요소	예시	설명
선택자 (Selector)	`h1`	어떤 요소에 스타일을 적용할지
속성 (Property)	`color`	무엇을 바꿀지
값 (Value)	`#2563eb`	어떻게 바꿀지
선언 (Declaration)	`color: #2563eb;`	속성 + 값 한 쌍
선언 블록	`{ ... }`	선언들의 묶음

백엔드 개발자에게 익숙한 형태로 비유하면:

CSS                         JSON
─────────────────           ─────────────────
h1 {                        {
  color: #2563eb;             "color": "#2563eb",
  font-size: 32px;            "fontSize": "32px",
  margin-bottom: 16px;        "marginBottom": "16px"
}                           }

4. CSS를 적용하는 3가지 방법

방법 1: 인라인 스타일 (Inline)

<h1 style="color: #2563eb; font-size: 32px;">제목</h1>

HTML 태그에 직접 작성
우선순위가 가장 높음
재사용 불가, 유지보수 어려움
실무에서는 거의 사용하지 않음 (JS 프레임워크에서 동적 스타일 외)

방법 2: 내부 스타일시트 (Internal)

<head>
  <style>
    h1 {
      color: #2563eb;
      font-size: 32px;
    }
  </style>
</head>

<style> 태그 안에 작성
해당 HTML 파일에서만 적용
소규모 페이지나 프로토타입에서 사용

방법 3: 외부 스타일시트 (External) — 권장

<!-- index.html -->
<head>
  <link rel="stylesheet" href="style.css">
</head>

/* style.css */
h1 {
  color: #2563eb;
  font-size: 32px;
}

별도 .css 파일로 분리
여러 HTML 파일에서 재사용 가능
브라우저 캐싱 가능 (성능 이점)
실무에서 표준 방식

비교 정리

방법	재사용	유지보수	캐싱	실무 사용
인라인	❌	❌	❌	거의 안 함
내부	❌	△	❌	프로토타입
외부	✅	✅	✅	표준

5. 브라우저가 CSS를 처리하는 과정

백엔드의 요청 처리 파이프라인처럼, 브라우저에도 렌더링 파이프라인이 있습니다.

1. HTML 파싱  →  DOM 트리 생성
2. CSS 파싱   →  CSSOM 트리 생성
3. DOM + CSSOM →  Render Tree 생성
4. Layout      →  각 요소의 위치/크기 계산
5. Paint       →  픽셀로 그리기
6. Composite   →  레이어 합성 → 화면 출력

단계별 설명

① HTML 파싱 → DOM 트리

<body>
  <h1>제목</h1>
  <p>본문</p>
</body>

DOM 트리:
body
├── h1
│   └── "제목"
└── p
    └── "본문"

② CSS 파싱 → CSSOM 트리

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

CSSOM 트리:
h1 → { color: blue, font-size: 32px }
p  → { color: gray }

③ DOM + CSSOM → Render Tree

DOM의 각 노드에 CSSOM의 스타일 정보가 결합됩니다. display: none인 요소는 Render Tree에서 제외됩니다.

④ Layout → Paint → Composite

Render Tree를 기반으로 각 요소의 정확한 위치와 크기를 계산(Layout)하고, 픽셀로 그린 뒤(Paint), 레이어를 합성(Composite)하여 화면에 출력합니다.

렌더링 파이프라인의 성능 최적화는 37편에서 자세히 다룹니다.

6. CSS가 필요한 진짜 이유

"HTML만으로 충분하지 않나?" 라는 질문에 대한 답입니다.

이유 1: 관심사의 분리 (Separation of Concerns)

<!-- ❌ HTML에 스타일이 섞인 경우 (1990년대 방식) -->
<font size="5" color="blue"><b>제목</b></font>
<table width="800" bgcolor="#f0f0f0">
  <tr><td>내용</td></tr>
</table>

<!-- ✅ HTML은 구조만, CSS는 스타일만 -->
<h1 class="title">제목</h1>
<div class="content">내용</div>

구조와 표현이 분리되면:

HTML 변경 없이 디자인 변경 가능
같은 CSS를 여러 페이지에 재사용
디자이너와 개발자의 협업이 쉬워짐

백엔드에서 비즈니스 로직과 프레젠테이션을 분리하는 것과 같은 원칙입니다.

이유 2: 일괄 변경

/* 이 한 줄로 사이트 전체의 primary 색상이 바뀜 */
:root {
  --color-primary: #2563eb;
}

CSS 변수(Custom Properties)를 사용하면, 값 하나만 바꿔도 사이트 전체에 반영됩니다. HTML에 인라인으로 색상을 넣었다면? 모든 파일을 열어서 하나하나 바꿔야 합니다.

이유 3: 반응형 디자인

/* 하나의 HTML로 모바일/태블릿/데스크탑 대응 */
.container {
  width: 100%;
  max-width: 1200px;
  margin: 0 auto;
}

@media (max-width: 768px) {
  .container {
    padding: 0 16px;
  }
}

CSS 없이는 화면 크기에 따라 레이아웃을 바꾸는 것이 불가능합니다.

이유 4: 접근성과 사용자 경험

/* 다크모드 대응 */
@media (prefers-color-scheme: dark) {
  :root {
    --bg-color: #1a1a2e;
    --text-color: #e0e0e0;
  }
}

/* 모션 민감 사용자 대응 */
@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition: none !important;
  }
}

CSS는 사용자의 시스템 설정에 따라 자동으로 스타일을 전환할 수 있습니다.

7. CSS로 어디까지 가능한가? (미리보기)

CSS는 단순한 색상/크기 지정을 넘어서 상당히 많은 것을 할 수 있습니다.

가능한 것	설명	관련 챕터
레이아웃 배치	Flexbox, Grid로 자유로운 2차원 배치	13~18편
애니메이션	@keyframes로 로딩 스피너, 페이드 효과	23~25편
반응형 디자인	하나의 코드로 모바일~데스크탑 대응	20~22편
다크모드	CSS 변수만으로 테마 전환	35편
글래스모피즘	backdrop-filter로 유리 효과	30편
CSS만의 인터랙션	:checked, :target으로 토글/아코디언	31편

CSS의 한계

할 수 없는 것	이유	대안
서버 통신	CSS는 표현 언어	JavaScript (fetch)
복잡한 상태 관리	조건문/반복문 없음	JavaScript
DOM 조작	요소 생성/삭제 불가	JavaScript
사용자 입력 처리	이벤트 리스너 없음	JavaScript

결론: CSS는 "보이는 것"에 대해서는 매우 강력하지만, "동작하는 것"은 JavaScript의 영역입니다.

8. CSS의 역사 (간략)

연도	사건	의미
1996	CSS1 발표	폰트, 색상, 정렬 등 기본 스타일링
1998	CSS2 발표	position, z-index, media type 추가
2011~	CSS3 모듈화	Flexbox, Grid, Animation, 변수 등 개별 모듈로 발전
2020~	모던 CSS	container query, @layer, nesting, color-mix() 등

CSS3부터는 하나의 버전이 아니라 모듈별로 독립 발전합니다. "CSS4"는 없고, 각 모듈(Flexbox, Grid, Selectors 등)이 자체 레벨을 가집니다.

CSS의 발전사와 Sass→PostCSS→Tailwind 흐름은 38편에서 상세히 다룹니다.

핵심 정리

개념	설명
CSS의 역할	HTML의 시각적 표현을 담당하는 스타일 언어
핵심 원칙	구조(HTML)와 표현(CSS)의 분리
기본 문법	선택자 { 속성: 값; }
적용 방법	인라인 / 내부 / 외부(권장)
브라우저 처리	HTML→DOM, CSS→CSSOM → Render Tree → Layout → Paint
CSS의 강점	레이아웃, 반응형, 애니메이션, 테마
CSS의 한계	서버 통신, 상태 관리, DOM 조작 → JavaScript 영역

다음 글 예고

[CSS] HTML 태그의 숨겨진 CSS — User Agent Stylesheet 파헤치기

브라우저가 기본으로 적용하는 스타일은 무엇인지, 왜 <div>와 <span>이 다르게 보이는지, reset CSS가 왜 필요한지를 다룹니다.

[Java] 참조 타입의 메모리 저장 방식 - Stack과 Heap의 관계

RyanSin — Fri, 30 Jan 2026 09:00:27 +0900

개요

안녕하세요. 이번 시간에는 Java의 **참조 타입(Reference Type)**이 메모리에 어떻게 저장되는지 알아보겠습니다.

이전 글에서 리터럴에 대해 배웠는데, "기본 타입은 Stack에 값이 저장되고, 문자열은 Heap에 저장된다"는 말을 했었죠? 오늘은 이 개념을 확실하게 이해해볼 거예요!

"Stack에 주소를 저장한다"는 말이 정확히 무슨 의미인지, 왜 ==과 equals()가 다른 결과를 내는지, null은 무엇을 의미하는지 등을 메모리 관점에서 깊이 있게 다뤄보겠습니다.

이 개념을 이해하면 Call by Value, String Pool, Garbage Collection 등의 고급 주제들이 훨씬 쉬워집니다!

개념

기본 타입 vs 참조 타입

Java의 데이터 타입은 크게 2가지로 나뉩니다.

기본 타입 (Primitive Type): 8가지

byte, short, int, long      // 정수
float, double                // 실수
char                         // 문자
boolean                      // 불린

참조 타입 (Reference Type): 기본 타입을 제외한 모든 것

String, Integer, Double      // 클래스
int[], String[]              // 배열
List, Map, Set               // 컬렉션
Person, Car, Animal          // 사용자 정의 클래스

핵심 차이

구분 기본 타입 참조 타입

저장 위치	Stack에 값 직접 저장	Stack에 주소, Heap에 객체
기본값	타입별 다름 (0, false 등)	null
크기	고정	가변
비교	==로 값 비교	==로 주소 비교

1. 기본 타입의 메모리 저장

값이 직접 저장됨

int age = 25;
double height = 175.5;
boolean isStudent = true;

메모리 상태:

Stack (main 스레드)
├─ age = 25         ← 값 25가 직접 저장
├─ height = 175.5   ← 값 175.5가 직접 저장
└─ isStudent = true ← 값 true가 직접 저장

특징:

값 자체가 Stack에 저장됩니다
변수 간 복사 시 값이 복사됩니다

기본 타입 복사 예제

public class PrimitiveExample {
    public static void main(String[] args) {
        int a = 10;
        int b = a;  // 값 10이 복사됨
        
        System.out.println("a = " + a);  // 10
        System.out.println("b = " + b);  // 10
        
        b = 20;  // b만 변경
        
        System.out.println("a = " + a);  // 10 (변경 안됨!)
        System.out.println("b = " + b);  // 20
    }
}

메모리 변화:

[초기 상태]
Stack
├─ a = 10
└─ b = 10  (a의 값이 복사됨)

[b = 20 실행 후]
Stack
├─ a = 10  ← 그대로!
└─ b = 20  ← b만 변경

결론: 기본 타입은 값이 독립적으로 저장되므로 서로 영향을 주지 않습니다.

2. 참조 타입의 메모리 저장

주소를 저장함!

String name = "홍길동";

메모리 상태:

Heap (String Pool)
└─ "홍길동" 객체 (주소: 0x1234)

Stack
└─ name = 0x1234  ← 주소를 저장!

핵심 개념: 참조값(Reference)

참조값: Heap에 있는 객체의 메모리 주소

String str = "Hello";
//     ^^^   ^^^^^^^
//     │     └─ 리터럴 "Hello"는 Heap에 저장
//     └─────── 변수 str은 주소를 저장

비유:

택배 상자(객체) → 창고(Heap)에 보관
송장 번호(주소) → 내 수첩(Stack)에 기록

3. 참조 타입 변수의 동작

예제 1: 객체 생성

public class Person {
    String name;
    int age;
}

public class ReferenceExample {
    public static void main(String[] args) {
        Person p1 = new Person();
        p1.name = "홍길동";
        p1.age = 30;
    }
}

메모리 상태:

Heap
└─ Person 객체 (주소: 0x1234)
   ├─ name → "홍길동" (String 객체도 Heap)
   └─ age = 30

Stack
└─ p1 = 0x1234  ← 주소만 저장!

그림으로 보면:

Stack          Heap
┌─────┐       ┌────────────┐
│ p1  │──────→│Person 객체│
└─────┘       │ name: 홍길동│
              │ age: 30   │
              └────────────┘

예제 2: 참조 복사 (중요!)

public class ReferenceExample {
    public static void main(String[] args) {
        Person p1 = new Person();
        p1.name = "홍길동";
        p1.age = 30;
        
        Person p2 = p1;  // 주소가 복사됨!
        
        System.out.println("p1.name: " + p1.name);  // 홍길동
        System.out.println("p2.name: " + p2.name);  // 홍길동
        
        p2.name = "김철수";  // p2를 통해 변경
        
        System.out.println("p1.name: " + p1.name);  // 김철수 (영향받음!)
        System.out.println("p2.name: " + p2.name);  // 김철수
    }
}

메모리 상태:

Heap
└─ Person 객체 (주소: 0x1234)
   ├─ name → "김철수"
   └─ age = 30

Stack
├─ p1 = 0x1234  ┐
└─ p2 = 0x1234  ┘ 같은 주소!

그림으로 보면:

Stack          Heap
┌─────┐       ┌────────────┐
│ p1  │──┐   │Person 객체│
└─────┘  │   │ name: 김철수│
         └──→│ age: 30   │
┌─────┐  │   └────────────┘
│ p2  │──┘
└─────┘

핵심:

p2 = p1은 주소를 복사합니다
p1과 p2는 같은 객체를 가리킵니다
둘 중 하나로 수정하면 둘 다 영향받습니다!

예제 3: 새 객체 생성

public class ReferenceExample {
    public static void main(String[] args) {
        Person p1 = new Person();
        p1.name = "홍길동";
        p1.age = 30;
        
        Person p2 = new Person();  // 새 객체!
        p2.name = "김철수";
        p2.age = 25;
        
        System.out.println("p1.name: " + p1.name);  // 홍길동
        System.out.println("p2.name: " + p2.name);  // 김철수
        
        p2.name = "이영희";
        
        System.out.println("p1.name: " + p1.name);  // 홍길동 (영향 없음!)
        System.out.println("p2.name: " + p2.name);  // 이영희
    }
}

메모리 상태:

Heap
├─ Person 객체 (주소: 0x1234)
│  ├─ name → "홍길동"
│  └─ age = 30
│
└─ Person 객체 (주소: 0x5678)
   ├─ name → "이영희"
   └─ age = 25

Stack
├─ p1 = 0x1234  ← 첫 번째 객체
└─ p2 = 0x5678  ← 두 번째 객체 (다른 주소!)

핵심: new를 사용하면 새 객체가 생성되어 독립적입니다!

4. == vs equals() 완벽 이해

== 연산자: 주소 비교

public class ComparisonExample {
    public static void main(String[] args) {
        String s1 = "Hello";      // 리터럴
        String s2 = "Hello";      // 같은 리터럴
        String s3 = new String("Hello");  // new 객체
        
        System.out.println(s1 == s2);  // true
        System.out.println(s1 == s3);  // false
    }
}

메모리 상태:

Heap
├─ String Pool
│  └─ "Hello" (0x1234)
│
└─ new String 객체 (0x5678)

Stack
├─ s1 = 0x1234  ┐
├─ s2 = 0x1234  ┘ 같은 주소!
└─ s3 = 0x5678    다른 주소!

== 비교:

s1 == s2  →  0x1234 == 0x1234  →  true
s1 == s3  →  0x1234 == 0x5678  →  false

equals() 메서드: 내용 비교

System.out.println(s1.equals(s2));  // true
System.out.println(s1.equals(s3));  // true (내용이 같음!)

equals() 비교:

s1.equals(s2)  →  "Hello".equals("Hello")  →  true
s1.equals(s3)  →  "Hello".equals("Hello")  →  true

비교 정리

연산자 비교 대상 결과

==	주소 (참조값)	같은 객체인가?
equals()	내용 (값)	값이 같은가?

실전 예제

public class PersonComparison {
    public static void main(String[] args) {
        Person p1 = new Person("홍길동", 30);
        Person p2 = new Person("홍길동", 30);
        Person p3 = p1;
        
        // == 비교 (주소)
        System.out.println(p1 == p2);  // false (다른 객체)
        System.out.println(p1 == p3);  // true (같은 객체)
        
        // equals 비교 (내용) - equals 오버라이드 필요
        System.out.println(p1.equals(p2));  // false (오버라이드 안 함)
    }
}

메모리:

Heap
├─ Person("홍길동", 30) - 0x1234
└─ Person("홍길동", 30) - 0x5678  ← 다른 객체!

Stack
├─ p1 = 0x1234  ┐
├─ p2 = 0x5678  │ 다른 주소!
└─ p3 = 0x1234  ┘ p1과 같은 주소!

5. null의 의미

null = 참조가 없음

String str = null;

메모리 상태:

Heap
(비어있음)

Stack
└─ str = null  ← 아무것도 가리키지 않음

그림으로:

Stack
┌─────┐
│ str │──X (가리키는 것 없음)
└─────┘

null 예제

public class NullExample {
    public static void main(String[] args) {
        String str = null;
        
        // NullPointerException 발생!
        // System.out.println(str.length());
        
        // null 체크 필수
        if (str != null) {
            System.out.println(str.length());
        } else {
            System.out.println("str은 null입니다");
        }
        
        // null 할당
        Person p = new Person();
        p = null;  // 더 이상 객체를 참조하지 않음 → GC 대상
    }
}

기본 타입은 null 불가!

int x = null;      // 컴파일 에러!
boolean b = null;  // 컴파일 에러!

Integer x = null;  // OK! (참조 타입)
Boolean b = null;  // OK! (참조 타입)

6. 배열의 메모리 저장

배열도 참조 타입!

int[] arr = {10, 20, 30};

메모리 상태:

Heap
└─ int[] 배열 객체 (0x1234)
   ├─ [0] = 10
   ├─ [1] = 20
   └─ [2] = 30

Stack
└─ arr = 0x1234

배열 복사 예제

public class ArrayExample {
    public static void main(String[] args) {
        int[] arr1 = {10, 20, 30};
        int[] arr2 = arr1;  // 주소 복사!
        
        System.out.println("arr1[0]: " + arr1[0]);  // 10
        System.out.println("arr2[0]: " + arr2[0]);  // 10
        
        arr2[0] = 100;  // arr2를 통해 변경
        
        System.out.println("arr1[0]: " + arr1[0]);  // 100 (영향받음!)
        System.out.println("arr2[0]: " + arr2[0]);  // 100
    }
}

메모리:

Heap
└─ int[] 배열 (0x1234)
   ├─ [0] = 100
   ├─ [1] = 20
   └─ [2] = 30

Stack
├─ arr1 = 0x1234  ┐
└─ arr2 = 0x1234  ┘ 같은 배열!

7. 메서드 파라미터 전달

기본 타입 전달

public class ParamExample {
    static void change(int x) {
        x = 100;
        System.out.println("메서드 내부: " + x);  // 100
    }
    
    public static void main(String[] args) {
        int num = 10;
        change(num);
        System.out.println("메서드 외부: " + num);  // 10 (변경 안됨!)
    }
}

메모리:

[change 호출 전]
Stack (main)
└─ num = 10

[change 호출]
Stack (main)
└─ num = 10  ← 그대로!

Stack (change)
└─ x = 10  ← 복사된 값

참조 타입 전달

public class ParamExample {
    static void change(Person p) {
        p.name = "김철수";
        System.out.println("메서드 내부: " + p.name);  // 김철수
    }
    
    public static void main(String[] args) {
        Person person = new Person();
        person.name = "홍길동";
        
        change(person);
        System.out.println("메서드 외부: " + person.name);  // 김철수 (변경됨!)
    }
}

메모리:

Heap
└─ Person 객체 (0x1234)
   └─ name = "김철수"

Stack (main)
└─ person = 0x1234

Stack (change)
└─ p = 0x1234  ← 같은 주소 복사!

핵심: 주소가 복사되므로 같은 객체를 가리킴 → 객체 내부 수정 가능!

자세한 내용은 [Call by Value vs Call by Reference] 글을 참고하세요!

8. 실전 예제

예제 1: 학생 정보 관리

class Student {
    String name;
    int score;
    
    Student(String name, int score) {
        this.name = name;
        this.score = score;
    }
}

public class StudentExample {
    public static void main(String[] args) {
        // 학생 2명 생성
        Student s1 = new Student("홍길동", 90);
        Student s2 = new Student("김철수", 85);
        
        // s3는 s1과 같은 학생
        Student s3 = s1;
        
        // s1의 점수 변경
        s1.score = 95;
        
        System.out.println("s1 점수: " + s1.score);  // 95
        System.out.println("s2 점수: " + s2.score);  // 85
        System.out.println("s3 점수: " + s3.score);  // 95 (s1과 같음!)
    }
}

메모리:

Heap
├─ Student("홍길동", 95) - 0x1234
└─ Student("김철수", 85) - 0x5678

Stack
├─ s1 = 0x1234  ┐
├─ s2 = 0x5678  │
└─ s3 = 0x1234  ┘ s1과 같은 객체!

예제 2: null 체크의 중요성

public class NullCheckExample {
    static void printLength(String str) {
        // 나쁜 예
        // System.out.println(str.length());  // NullPointerException 위험!
        
        // 좋은 예
        if (str != null) {
            System.out.println("길이: " + str.length());
        } else {
            System.out.println("str이 null입니다");
        }
    }
    
    public static void main(String[] args) {
        String s1 = "Hello";
        String s2 = null;
        
        printLength(s1);  // 길이: 5
        printLength(s2);  // str이 null입니다
    }
}

예제 3: 배열과 참조

public class ArrayReferenceExample {
    public static void main(String[] args) {
        int[] original = {1, 2, 3, 4, 5};
        int[] copy = original;  // 주소 복사
        
        // 진짜 복사 (새 배열 생성)
        int[] realCopy = new int[original.length];
        for (int i = 0; i < original.length; i++) {
            realCopy[i] = original[i];
        }
        
        // 또는 Arrays.copyOf() 사용
        // int[] realCopy = Arrays.copyOf(original, original.length);
        
        original[0] = 100;
        
        System.out.println("original[0]: " + original[0]);  // 100
        System.out.println("copy[0]: " + copy[0]);          // 100 (영향받음)
        System.out.println("realCopy[0]: " + realCopy[0]);  // 1 (영향 없음!)
    }
}

핵심 정리

1. 기본 타입 vs 참조 타입

기본 타입: Stack에 값 직접 저장
참조 타입: Stack에 주소, Heap에 객체

2. 참조 복사의 의미

Person p1 = new Person();
Person p2 = p1;  // 주소 복사!

p1과 p2는 같은 객체를 가리킴
→ 하나를 수정하면 둘 다 영향받음

3. == vs equals()

연산자 기본 타입 참조 타입

==	값 비교	주소 비교
equals()	-	내용 비교

4. null의 의미

String str = null;  // 아무것도 가리키지 않음

참조가 없다 = null
기본 타입은 null 불가!

5. 메모리 구조

Stack (Thread별 독립)
├─ 지역 변수
│  ├─ 기본 타입: 값 직접
│  └─ 참조 타입: 주소만
└─ 메서드 호출 정보

Heap (모든 Thread 공유)
├─ 객체 (new로 생성)
├─ 배열
└─ String Pool

마무리

이번 시간에는 참조 타입의 메모리 저장 방식에 대해 알아봤습니다.

특히 "Stack에 주소를 저장하고 Heap에 객체를 저장한다"는 개념을 정확히 이해하는 것이 중요합니다. 이 개념을 알면:

==과 equals()의 차이를 이해할 수 있습니다
왜 참조 복사가 위험한지 알 수 있습니다
null이 무엇을 의미하는지 알 수 있습니다
Call by Value의 원리를 이해할 수 있습니다

다음 시간에는 이 개념을 바탕으로 String & String Pool에 대해 깊이 있게 알아보겠습니다!

꼭 실습을 통해 학습하신 걸 추천드리겠습니다!!

참고 자료

[Java] 리터럴(Literal)이란? - 변수와 값의 차이 완벽 이해

RyanSin — Thu, 29 Jan 2026 09:00:34 +0900

개요

안녕하세요. 이번 시간에는 Java의 가장 기초적이지만 중요한 개념인 **리터럴(Literal)**에 대해 알아보겠습니다.

"리터럴이 뭔가요?"라고 물어보면 많은 개발자들이 명확하게 설명하지 못하는 경우가 많습니다. 하지만 리터럴은 Java 프로그래밍의 가장 기본이 되는 개념이에요!

특히 String Pool, 메모리 구조, 참조 타입 등을 이해하려면 리터럴 개념을 정확히 알아야 합니다. 오늘은 "코드에 직접 적는 값"인 리터럴에 대해 쉽고 명확하게 정리해보겠습니다.

개념

리터럴(Literal)이란?

"소스 코드에 직접 입력한 값 그 자체"

다시 말해, 우리가 코드를 작성할 때 **"직접 적는 데이터"**를 리터럴이라고 합니다.

쉬운 비유

레시피: "설탕 100g을 넣으세요"
        ^^^^
        이 100g이 "리터럴"

코드: int sugar = 100;
                  ^^^
                  이 100이 "리터럴"

1. 리터럴 vs 변수

기본 개념

int age = 25;
//  ^^^   ^^
//  │     └─── 리터럴 (값 그 자체)
//  └───────── 변수 (값을 담는 그릇)

변수: 값을 담는 그릇 (상자)
리터럴: 그릇에 담을 값 (물건)

예제로 이해하기

public class LiteralExample {
    public static void main(String[] args) {
        // 변수 선언과 리터럴 할당
        int number = 100;        // 100이 리터럴
        double pi = 3.14;        // 3.14가 리터럴
        char grade = 'A';        // 'A'가 리터럴
        String name = "홍길동";   // "홍길동"이 리터럴
        boolean isTrue = true;   // true가 리터럴
        
        // 연산에서의 리터럴
        int sum = 10 + 20;       // 10과 20이 리터럴
        
        // 메서드 호출에서의 리터럴
        System.out.println("Hello");  // "Hello"가 리터럴
    }
}

메모리 관점

int x = 10;

Stack 메모리:

Stack
└─ x = 10  ← 10(리터럴)이 변수 x에 저장됨

리터럴 10은 컴파일 시점에 처리되어 변수 x에 직접 저장됩니다.

2. 타입별 리터럴 표기법

2-1. 정수 리터럴

public class IntegerLiteral {
    public static void main(String[] args) {
        // 10진수 리터럴
        int decimal = 100;
        
        // 16진수 리터럴 (0x 또는 0X로 시작)
        int hex = 0x64;          // 100과 같음
        
        // 8진수 리터럴 (0으로 시작)
        int octal = 0144;        // 100과 같음
        
        // 2진수 리터럴 (0b 또는 0B로 시작)
        int binary = 0b1100100;  // 100과 같음
        
        // long 타입 리터럴 (L 또는 l 접미사)
        long bigNumber = 100L;
        
        // 가독성을 위한 언더스코어 (Java 7+)
        int million = 1_000_000;  // 백만
        
        System.out.println(decimal);   // 100
        System.out.println(hex);       // 100
        System.out.println(octal);     // 100
        System.out.println(binary);    // 100
    }
}

주의사항:

int x = 100;   // OK
int y = 100L;  // 컴파일 에러! long을 int에 넣을 수 없음
long z = 100;  // OK, 자동으로 long으로 변환됨

2-2. 실수 리터럴

public class FloatingLiteral {
    public static void main(String[] args) {
        // double 타입 리터럴 (기본)
        double d1 = 3.14;
        double d2 = 3.14d;      // d 접미사 (생략 가능)
        double d3 = 3.14D;
        
        // float 타입 리터럴 (f 또는 F 접미사 필수!)
        float f1 = 3.14f;
        float f2 = 3.14F;
        
        // 지수 표현
        double scientific1 = 1.23e2;   // 1.23 × 10² = 123.0
        double scientific2 = 1.23e-2;  // 1.23 × 10⁻² = 0.0123
        
        System.out.println(d1);          // 3.14
        System.out.println(scientific1); // 123.0
    }
}

주의사항:

float f = 3.14;   // 컴파일 에러! double을 float에 넣을 수 없음
float f = 3.14f;  // OK! f 접미사 필수

2-3. 문자 리터럴

public class CharLiteral {
    public static void main(String[] args) {
        // 일반 문자 리터럴 (작은따옴표 '')
        char c1 = 'A';
        char c2 = '가';
        char c3 = '1';
        
        // 유니코드 리터럴
        char unicode = '\u0041';  // 'A'와 같음
        
        // 이스케이프 시퀀스
        char newLine = '\n';      // 줄바꿈
        char tab = '\t';          // 탭
        char backslash = '\\';    // 역슬래시
        char singleQuote = '\'';  // 작은따옴표
        
        System.out.println(c1);       // A
        System.out.println(unicode);  // A
        System.out.println("Hello" + newLine + "World");
        // 출력:
        // Hello
        // World
    }
}

주의사항:

char c1 = 'A';    // OK, 문자 1개
char c2 = 'AB';   // 컴파일 에러! 문자는 1개만
char c3 = "A";    // 컴파일 에러! 큰따옴표는 String

2-4. 문자열 리터럴 (중요!)

public class StringLiteral {
    public static void main(String[] args) {
        // 문자열 리터럴 (큰따옴표 "")
        String str1 = "Hello";
        String str2 = "안녕하세요";
        String str3 = "123";      // 문자열!
        
        // 빈 문자열
        String empty = "";
        
        // 여러 줄 문자열 (Java 13+)
        String multiLine = """
            첫 번째 줄
            두 번째 줄
            세 번째 줄
            """;
        
        // 이스케이프 시퀀스
        String escaped = "Hello\nWorld";  // 줄바꿈
        String quoted = "그가 말했다: \"안녕\"";  // 큰따옴표
        
        System.out.println(str1);     // Hello
        System.out.println(escaped);
        // 출력:
        // Hello
        // World
    }
}

문자 vs 문자열:

char c = 'A';      // 문자 (작은따옴표)
String s = "A";    // 문자열 (큰따옴표)

// 타입이 완전히 다름!

2-5. 불린 리터럴

public class BooleanLiteral {
    public static void main(String[] args) {
        // boolean 리터럴은 true와 false 두 개뿐!
        boolean isTrue = true;
        boolean isFalse = false;
        
        // 조건문에서 자주 사용
        if (true) {
            System.out.println("항상 실행됨");
        }
        
        // 비교 연산 결과는 boolean
        boolean result = (10 > 5);  // true
        
        System.out.println(isTrue);   // true
        System.out.println(result);   // true
    }
}

주의사항:

boolean b1 = true;   // OK
boolean b2 = 1;      // 컴파일 에러! Java는 1을 true로 변환 안 함
boolean b3 = "true"; // 컴파일 에러! 문자열은 boolean 아님

2-6. null 리터럴

public class NullLiteral {
    public static void main(String[] args) {
        // null은 "참조가 없음"을 나타내는 특별한 리터럴
        String str = null;
        Integer num = null;
        Object obj = null;
        
        // 기본 타입에는 null 사용 불가!
        // int x = null;  // 컴파일 에러!
        
        // null 체크
        if (str == null) {
            System.out.println("str은 null입니다");
        }
    }
}

3. 리터럴의 타입

기본 타입 리터럴

// 정수 리터럴의 기본 타입은 int
int i = 100;        // OK
long l = 100;       // OK, int → long 자동 변환
byte b = 100;       // OK, int → byte 자동 변환 (범위 내일 때)

// 실수 리터럴의 기본 타입은 double
double d = 3.14;    // OK
float f = 3.14;     // 에러! double → float 불가
float f = 3.14f;    // OK, float 명시

타입 변환 예제

public class LiteralType {
    public static void main(String[] args) {
        // int 범위를 벗어나면 L 필수
        long big = 3000000000L;  // int 범위 초과, L 필수
        
        // byte 범위를 벗어나면 에러
        byte b1 = 127;   // OK
        // byte b2 = 128;   // 에러! byte 범위는 -128~127
        
        // float은 f 필수
        float f = 3.14f;
        
        // char는 작은따옴표
        char c = 'A';
    }
}

4. 리터럴과 메모리

기본 타입 리터럴 - Stack에 저장

int age = 25;
double height = 175.5;

메모리 상태:

Stack
├─ age = 25  ← 리터럴 25가 직접 저장
└─ height = 175.5  ← 리터럴 175.5가 직접 저장

문자열 리터럴 - String Pool(Heap)에 저장

String s1 = "Hello";
String s2 = "Hello";

메모리 상태:

Heap (String Pool)
└─ "Hello" 객체 (0x1234)  ← 리터럴 1개만!

Stack
├─ s1 = 0x1234  ← 주소 저장
└─ s2 = 0x1234  ← 같은 주소!

핵심 차이:

기본 타입 리터럴: 값 자체가 Stack에 저장
문자열 리터럴: Heap의 String Pool에 저장, Stack에는 주소만

이 부분은 다음 글 [참조 타입의 메모리 저장 방식]에서 자세히 다룹니다!

5. 실전 예제

예제 1: 리터럴 구분하기

public class LiteralQuiz {
    public static void main(String[] args) {
        int x = 10;              // 10: 정수 리터럴
        double y = 3.14;         // 3.14: 실수 리터럴
        char c = 'A';            // 'A': 문자 리터럴
        String s = "Hello";      // "Hello": 문자열 리터럴
        boolean b = true;        // true: 불린 리터럴
        
        int sum = x + 20;        // 20: 정수 리터럴
        String msg = s + "World";  // "World": 문자열 리터럴
        
        System.out.println("결과: " + sum);
        //                 ^^^^^^^
        //                 "결과: ": 문자열 리터럴
    }
}

예제 2: 리터럴 타입 주의

public class LiteralTypeError {
    public static void main(String[] args) {
        // 올바른 예
        int i = 100;
        long l = 100L;
        float f = 3.14f;
        double d = 3.14;
        char c = 'A';
        String s = "Hello";
        
        // 컴파일 에러 예
        // float f2 = 3.14;      // 에러! double을 float에
        // char c2 = "A";        // 에러! String을 char에
        // char c3 = 'AB';       // 에러! 문자는 1개만
        // int x = 3000000000;   // 에러! int 범위 초과
        // boolean b = 1;        // 에러! int를 boolean으로
    }
}

예제 3: 문자열 리터럴의 특별함

public class StringLiteralTest {
    public static void main(String[] args) {
        String s1 = "Hello";  // 리터럴
        String s2 = "Hello";  // 같은 리터럴
        String s3 = new String("Hello");  // new 객체
        
        System.out.println(s1 == s2);  // true (같은 리터럴)
        System.out.println(s1 == s3);  // false (다른 객체)
        
        System.out.println(s1.equals(s2));  // true
        System.out.println(s1.equals(s3));  // true
    }
}

실행 결과:

true
false
true
true

왜 이런 결과가 나올까요? → 다음 글 [String & String Pool]에서 자세히 알아봅니다!

6. 리터럴 vs 상수 vs 변수

개념 정리

용어 의미 예시

리터럴	코드에 직접 적은 값	100, "Hello", true
변수	값을 저장하는 공간 (변경 가능)	int x = 10;
상수	값을 저장하는 공간 (변경 불가)	final int MAX = 100;

예제로 이해

public class LiteralVsConstant {
    // 상수 (관례: 대문자 + 언더스코어)
    static final int MAX_VALUE = 100;  // 100이 리터럴
    static final String TITLE = "제목";  // "제목"이 리터럴
    
    public static void main(String[] args) {
        // 변수
        int x = 10;        // 10이 리터럴
        x = 20;            // 변경 가능! 20도 리터럴
        
        // 상수
        final int y = 30;  // 30이 리터럴
        // y = 40;         // 컴파일 에러! 상수는 변경 불가
        
        // 리터럴 직접 사용 (비추천)
        if (age > 19) {    // 19가 리터럴 (매직 넘버)
            // ...
        }
        
        // 상수 사용 (추천)
        if (age > MAX_AGE) {  // 의미가 명확함
            // ...
        }
    }
}

베스트 프랙티스:

// 나쁜 예: 리터럴 직접 사용 (매직 넘버)
if (status == 1) { ... }
if (score > 90) { ... }

// 좋은 예: 상수로 정의
static final int STATUS_ACTIVE = 1;
static final int PASS_SCORE = 90;

if (status == STATUS_ACTIVE) { ... }
if (score > PASS_SCORE) { ... }

7. 컴파일 타임 상수

개념

컴파일 시점에 값이 결정되는 상수

public class CompileTimeConstant {
    // 컴파일 타임 상수
    static final int MAX = 100;
    static final String NAME = "Java";
    
    public static void main(String[] args) {
        // 컴파일러가 직접 값으로 치환
        int x = MAX;  // int x = 100; 으로 컴파일됨
        
        // 상수 표현식도 컴파일 타임에 계산
        int result = MAX * 2;  // int result = 200; 으로 컴파일됨
    }
}

핵심 정리

1. 리터럴이란?

"소스 코드에 직접 입력한 값 그 자체"

int x = 10;        // 10이 리터럴
String s = "Hi";   // "Hi"가 리터럴

2. 타입별 리터럴 표기

타입 표기법 예시

정수	숫자	100, 0xFF, 0b1010
long	숫자 + L	100L
실수	소수점	3.14
float	소수점 + f	3.14f
문자	작은따옴표	'A'
문자열	큰따옴표	"Hello"
불린	true/false	true
null	null	null

3. 메모리 저장

기본 타입 리터럴 → Stack에 값 직접 저장
문자열 리터럴 → Heap의 String Pool에 저장

4. 리터럴 vs 변수 vs 상수

리터럴: 코드에 적은 값 (100, "Hello")
변수: 값을 담는 그릇 (int x = 10;)
상수: 변경 불가 그릇 (final int MAX = 100;)

마무리

이번 시간에는 Java의 가장 기본이 되는 리터럴(Literal) 개념에 대해 알아봤습니다.

리터럴은 단순해 보이지만, 메모리 구조를 이해하고 String Pool, 참조 타입 등을 학습하는 데 꼭 필요한 기초 개념입니다.

특히 문자열 리터럴은 String Pool이라는 특별한 공간에 저장되는데, 이에 대해서는 다음 글에서 자세히 다루겠습니다!

기초를 탄탄히 하면 복잡한 개념도 쉽게 이해할 수 있습니다. 꼭 실습을 통해 학습하신 걸 추천드리겠습니다!!

참고 자료

[Java] Call by Value와 Call by Reference 완벽 이해

RyanSin — Wed, 28 Jan 2026 10:57:52 +0900

개요

안녕하세요. 이번 시간에는 Java의 인자 전달 방식인 Call by Value와 Call by Reference에 대해 알아보겠습니다.

Java를 공부하다 보면 "함수에 객체를 넘겼는데 왜 원본이 바뀌지?", "근데 왜 재할당은 안 되는 거야?"라는 의문이 생기곤 합니다.

특히 "Java는 Call by Value다" vs "Java는 객체는 Call by Reference다"라는 논쟁은 개발자 면접에서도 자주 등장하는 단골 질문입니다.

오늘은 이 혼란스러운 개념을 명확하게 정리하고, 실제 메모리 관점에서 어떻게 동작하는지 깊이 있게 다뤄보겠습니다!

개념

Call by Value란?

함수에 값의 복사본을 전달하는 방식입니다.

함수 내에서 매개변수를 변경해도 원본 변수는 영향을 받지 않습니다.

void change(int x) {
    x = 100;  // 복사본만 변경
}

int num = 5;
change(num);
System.out.println(num);  // 여전히 5

Call by Reference란?

함수에 **변수의 메모리 주소(참조)**를 전달하는 방식입니다.

함수 내에서 매개변수를 변경하면 원본 변수도 함께 변경됩니다.

// C++ 예시
void change(int &x) {  // &는 참조
    x = 100;  // 원본 변수가 100으로 변경됨!
}

int num = 5;
change(num);
cout << num;  // 100 출력

Java는 항상 Call by Value!

핵심: Java의 모든 인자 전달은 Call by Value

많은 사람들이 혼란스러워하는 이유는 **Java가 객체를 다룰 때 "참조값 자체를 복사해서 전달"**하기 때문입니다.

기본 타입: 값 자체를 복사해서 전달
참조 타입: 참조값(주소)을 복사해서 전달

중요한 것은 "복사"라는 점입니다! 원본이 아닌 복사본을 전달하므로 Call by Value입니다.

1. 기본 타입(Primitive Type)의 전달

코드 예시

public class PrimitiveExample {
    static void changeValue(int x) {
        System.out.println("함수 내부 (변경 전): " + x);
        x = 100;
        System.out.println("함수 내부 (변경 후): " + x);
    }
    
    public static void main(String[] args) {
        int num = 5;
        System.out.println("호출 전: " + num);
        changeValue(num);
        System.out.println("호출 후: " + num);
    }
}

실행 결과

호출 전: 5
함수 내부 (변경 전): 5
함수 내부 (변경 후): 100
호출 후: 5

메모리 상태

[호출 전]
Stack (main)
└─ num = 5

[changeValue 호출]
Stack (main)
└─ num = 5

Stack (changeValue)
└─ x = 5 (복사된 값)

[x = 100 실행]
Stack (main)
└─ num = 5 (변경 안됨!)

Stack (changeValue)
└─ x = 100 (복사본만 변경)

결론: 기본 타입은 값 자체가 복사되므로 원본에 영향을 주지 않습니다.

2. 참조 타입(Reference Type)의 전달

여기서부터 헷갈립니다! 차근차근 알아보겠습니다.

2-1. 객체 내부 속성 변경

class Person {
    String name;
    
    Person(String name) {
        this.name = name;
    }
}

public class ReferenceExample {
    static void changeName(Person p) {
        System.out.println("함수 내부 (변경 전): " + p.name);
        p.name = "김철수";
        System.out.println("함수 내부 (변경 후): " + p.name);
    }
    
    public static void main(String[] args) {
        Person person = new Person("홍길동");
        System.out.println("호출 전: " + person.name);
        changeName(person);
        System.out.println("호출 후: " + person.name);
    }
}

실행 결과

호출 전: 홍길동
함수 내부 (변경 전): 홍길동
함수 내부 (변경 후): 김철수
호출 후: 김철수  ← 원본이 변경됨!

메모리 상태

Heap
└─ Person 객체 (주소: 0x1234)
   └─ name = "홍길동"

Stack (main)
└─ person = 0x1234 (참조값)

Stack (changeName)
└─ p = 0x1234 (참조값 복사!)

핵심: 참조값(0x1234)이 복사되어 전달됩니다. 그래서 p와 person은 같은 객체를 가리킵니다!

따라서 p.name을 변경하면 같은 객체를 가리키는 person.name도 변경됩니다.

하지만 이건 Call by Reference가 아닙니다! 왜일까요?

2-2. 객체 재할당 (핵심!)

class Person {
    String name;
    
    Person(String name) {
        this.name = name;
    }
}

public class ReassignExample {
    static void reassignObject(Person p) {
        System.out.println("함수 내부 (재할당 전): " + p.name);
        p = new Person("이영희");  // 새 객체 생성 후 재할당
        System.out.println("함수 내부 (재할당 후): " + p.name);
    }
    
    public static void main(String[] args) {
        Person person = new Person("홍길동");
        System.out.println("호출 전: " + person.name);
        reassignObject(person);
        System.out.println("호출 후: " + person.name);
    }
}

실행 결과

호출 전: 홍길동
함수 내부 (재할당 전): 홍길동
함수 내부 (재할당 후): 이영희
호출 후: 홍길동  ← 원본은 그대로!

메모리 상태 (단계별)

[초기 상태]
Heap
└─ Person 객체 A (주소: 0x1234)
   └─ name = "홍길동"

Stack (main)
└─ person = 0x1234

[reassignObject 호출]
Stack (main)
└─ person = 0x1234

Stack (reassignObject)
└─ p = 0x1234 (복사된 참조값)

[p = new Person("이영희") 실행]
Heap
├─ Person 객체 A (주소: 0x1234)
│  └─ name = "홍길동"
└─ Person 객체 B (주소: 0x5678)  ← 새로 생성!
   └─ name = "이영희"

Stack (main)
└─ person = 0x1234 (변경 안됨!)

Stack (reassignObject)
└─ p = 0x5678 (새 객체를 가리킴)

핵심:

p는 새로운 객체(0x5678)를 가리키게 되었지만
person은 여전히 원래 객체(0x1234)를 가리킵니다
왜? p는 참조값의 복사본이기 때문입니다!

만약 진짜 Call by Reference였다면, person도 새 객체를 가리켜야 합니다.

왜 Java는 Call by Value만 사용할까?

1. 안정성

void dangerousFunction(Person p) {
    p = null;  // 만약 Call by Reference라면?
}

Person person = new Person("홍길동");
dangerousFunction(person);
// Java: person은 여전히 유효 (안전)
// C++: person이 null이 되어 크래시 위험

2. 단순성

// 모든 전달이 같은 방식
void func(int x);        // Call by Value
void func(Person p);     // Call by Value (참조값의)

// C++은 여러 방식을 구분해야 함
void func(int x);        // Call by Value
void func(int &x);       // Call by Reference
void func(int *x);       // 포인터
void func(const int &x); // Const Reference

3. 포인터 제거

C++의 가장 큰 버그 원인:

널 포인터 에러
댕글링 포인터 (해제된 메모리 접근)
메모리 누수

Java는 이런 문제를 원천적으로 차단했습니다.

실전 예제: swap 함수

C++ (Call by Reference 가능)

void swap(int &a, int &b) {
    int temp = a;
    a = b;
    b = temp;
}

int x = 5, y = 10;
swap(x, y);
// x = 10, y = 5 (성공!)

Java (Call by Value만 가능)

// 시도 1: 실패
static void swap(int a, int b) {
    int temp = a;
    a = b;
    b = temp;
}

int x = 5, y = 10;
swap(x, y);
// x = 5, y = 10 (실패!)

// 시도 2: 객체로 감싸기
class IntWrapper {
    int value;
    IntWrapper(int value) { this.value = value; }
}

static void swap(IntWrapper a, IntWrapper b) {
    int temp = a.value;
    a.value = b.value;
    b.value = temp;
}

IntWrapper x = new IntWrapper(5);
IntWrapper y = new IntWrapper(10);
swap(x, y);
// x.value = 10, y.value = 5 (성공!)

언어별 비교

언어 Call by Value Call by Reference 특징

Java	✅ 항상	❌ 불가능	단순하고 안전
C++	✅ 가능	✅ 가능 (& 사용)	유연하지만 복잡
C#	✅ 가능	✅ 가능 (ref 사용)	Java + C++ 절충
Python	-	-	독특한 방식
JavaScript	✅ 항상	❌ 불가능	Java와 유사

핵심 정리

Java의 인자 전달 규칙

1. 기본 타입 (int, boolean 등)
   → 값 자체를 복사해서 전달
   → 원본 변경 불가능

2. 참조 타입 (객체, 배열 등)
   → 참조값(주소)을 복사해서 전달
   → 객체 내부는 변경 가능
   → 변수 재할당은 불가능

3줄 요약

Java는 모든 경우에 Call by Value다
객체의 경우, "참조값"을 값으로 전달한다
객체 내부 수정 가능 ≠ Call by Reference

면접 질문 답변 예시

질문: "Java는 Call by Value인가요, Call by Reference인가요?"

정답:

"Java는 항상 Call by Value입니다. 기본 타입은 값 자체를 복사하고, 참조 타입은 참조값을 복사해서 전달합니다. 따라서 객체 내부를 수정할 수는 있지만, 변수 자체를 다른 객체로 재할당하는 것은 불가능합니다. 이것이 진짜 Call by Reference와의 결정적 차이입니다."

마무리

이번 시간에는 Java의 인자 전달 방식에 대해 알아봤습니다.

처음에는 "객체는 참조 전달 아닌가?"라고 생각하기 쉽지만, 정확히는 **"참조값의 복사"**라는 점을 기억하세요!

특히 면접에서 이 질문이 나오면:

"Java는 항상 Call by Value다"
"객체 재할당이 안 되는 이유"

이 두 가지를 명확히 설명할 수 있다면 완벽합니다!

실제 코드를 작성하면서 "이 변수는 왜 안 바뀌지?", "저 객체는 왜 바뀌지?"를 생각하다 보면 자연스럽게 이해가 됩니다.

꼭 실습을 통해 학습하신 걸 추천드리겠습니다!!

참고 자료

[Git] - Git Tag - 버전 관리 및 릴리즈

RyanSin — Sat, 27 Dec 2025 20:00:54 +0900

개요

안녕하세요. 이번 시간에는 Git Tag에 대해 알아보겠습니다. Tag는 특정 커밋에 버전을 표시하는 기능으로, 소프트웨어 릴리즈 관리에 필수적입니다. v1.0.0, v2.1.0과 같은 버전 번호를 Git으로 관리하는 방법을 배워보겠습니다. 혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 학습하고 오시는 걸 추천드리겠습니다.

[Git] - Git Stash - 임시 저장 활용법

- Tag란?

Tag는 Git의 특정 커밋에 대한 **참조(reference)**입니다. 주로 릴리즈 버전을 표시하는 데 사용됩니다.

Tag의 용도

✅ 주요 용도:
- 릴리즈 버전 표시 (v1.0.0, v2.1.0)
- 특정 시점의 코드 스냅샷 저장
- 배포 이력 관리
- 다운로드 가능한 릴리즈 생성

  예시:
v1.0.0 → 첫 번째 정식 릴리즈
v1.1.0 → 새 기능이 추가된 마이너 업데이트
v1.1.1 → 버그 수정 패치

Tag의 특징

1. 특정 커밋을 가리킴 (브랜치와 유사)
2. 한번 만들면 이동하지 않음 (브랜치와 다름)
3. 원격 저장소와 공유 가능
4. GitHub에서 자동으로 릴리즈 페이지 생성

브랜치 vs Tag

항목브랜치Tag

이동	새 커밋 생성 시 이동	고정 (이동 안함)
용도	개발 작업	버전 표시
수정	자주 수정됨	거의 수정 안함
예시	main, develop	v1.0.0, v2.0.0

- Tag의 종류

Git에는 두 가지 종류의 Tag가 있습니다.

1. Lightweight Tag (가벼운 태그)

단순히 특정 커밋을 가리키는 포인터입니다.

bash

# Lightweight Tag 생성
git tag v1.0.0

# 특정 커밋에 Tag 생성
git tag v1.0.0 a1b2c3d

특징:

태그 이름만 저장
추가 정보 없음
빠르고 간단
임시 태그나 개인용으로 사용

2. Annotated Tag (주석 태그) - 권장

태그 작성자, 날짜, 메시지 등의 정보를 포함하는 완전한 객체입니다.

bash

# Annotated Tag 생성
git tag -a v1.0.0 -m "첫 번째 정식 릴리즈"

# 특정 커밋에 Tag 생성
git tag -a v1.0.0 a1b2c3d -m "메시지"

특징:

태그 작성자 정보 저장
태그 생성 날짜 저장
태그 메시지 저장
GPG 서명 가능
공식 릴리즈에 권장

Lightweight vs Annotated 비교

항목LightweightAnnotated

생성	git tag v1.0.0	git tag -a v1.0.0 -m "메시지"
정보	커밋만 가리킴	작성자, 날짜, 메시지 포함
사용	임시 태그	공식 릴리즈
권장도	낮음	높음 (권장)

권장: 공식 릴리즈는 항상 Annotated Tag를 사용하세요!

- Tag 생성하기

현재 커밋에 Tag 생성

bash

# Annotated Tag 생성 (권장)
git tag -a v1.0.0 -m "첫 번째 정식 릴리즈"

# Lightweight Tag 생성
git tag v1.0.0

# 긴 메시지로 Tag 생성 (에디터 열림)
git tag -a v1.0.0
# 에디터에서 메시지 작성 후 저장

과거 커밋에 Tag 생성

bash

# 커밋 히스토리 확인
git log --oneline

# 출력
a1b2c3d feat: 사용자 인증 기능 추가
b2c3d4e fix: 로그인 버그 수정
c3d4e5f init: 프로젝트 초기 설정

# 특정 커밋에 Tag 생성
git tag -a v1.0.0 a1b2c3d -m "사용자 인증 기능 릴리즈"

실전 예시

bash

# === 시나리오: v1.0.0 릴리즈 ===

# 1. 현재 상태 확인
git log --oneline -5

# 2. 최종 커밋에 Tag 생성
git tag -a v1.0.0 -m "Release v1.0.0

주요 기능:
- 사용자 인증 (로그인/회원가입)
- 프로필 관리
- 대시보드

버그 수정:
- 로그인 세션 만료 이슈 수정
- UI 반응형 개선"

# 3. Tag 확인
git tag
# v1.0.0

# 4. Tag 상세 정보 확인
git show v1.0.0

- Tag 확인하기

Tag 목록 보기

bash

# 모든 Tag 목록
git tag

# 출력
v1.0.0
v1.1.0
v1.1.1
v2.0.0

# 알파벳 순서로 정렬
git tag --sort=v:refname

# 패턴으로 검색
git tag -l "v1.*"
# v1.0.0
# v1.1.0
# v1.1.1

git tag -l "v2.*"
# v2.0.0

Tag 정보 상세 보기

bash

# Annotated Tag 정보 보기
git show v1.0.0

# 출력
tag v1.0.0
Tagger: RyanSin <ryan@example.com>
Date:   Mon Dec 16 10:00:00 2024 +0900

첫 번째 정식 릴리즈

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0
...

# 간단하게 보기
git tag -n
# v1.0.0    첫 번째 정식 릴리즈
# v1.1.0    새 기능 추가

# 여러 줄 메시지 보기
git tag -n5

Tag가 가리키는 커밋 확인

bash

# Tag의 커밋 해시 확인
git rev-parse v1.0.0

# 출력
a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

# Tag와 커밋 함께 보기
git log --oneline --decorate

# 출력
a1b2c3d (HEAD -> main, tag: v1.0.0) feat: 인증 기능 추가
b2c3d4e fix: 버그 수정

- Tag 삭제하기

로컬 Tag 삭제

bash

# 로컬 Tag 삭제
git tag -d v1.0.0

# 출력
Deleted tag 'v1.0.0' (was a1b2c3d)

# 여러 Tag 삭제
git tag -d v1.0.0 v1.1.0 v1.1.1

원격 Tag 삭제

bash

# 원격 저장소의 Tag 삭제
git push origin --delete v1.0.0

# 또는
git push origin :refs/tags/v1.0.0

# 여러 Tag 삭제
git push origin --delete v1.0.0 v1.1.0

Tag 수정하기

Tag는 한번 만들면 수정할 수 없습니다. 삭제 후 다시 만들어야 합니다.

bash

# 잘못된 Tag 삭제
git tag -d v1.0.0

# 올바른 Tag 재생성
git tag -a v1.0.0 -m "수정된 메시지"

# 원격에 강제 푸시
git push origin v1.0.0 --force

⚠️ 주의: 이미 공개된 Tag를 수정하면 다른 사람들에게 혼란을 줄 수 있습니다!

- Tag 원격 저장소에 푸시하기

Tag는 git push로 자동으로 전송되지 않습니다. 명시적으로 푸시해야 합니다.

특정 Tag 푸시

bash

# 특정 Tag 하나 푸시
git push origin v1.0.0

# 출력
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/username/repo.git
 * [new tag]         v1.0.0 -> v1.0.0

모든 Tag 푸시

bash

# 모든 Tag 한번에 푸시
git push origin --tags

# 출력
Total 0 (delta 0), reused 0 (delta 0)
To https://github.com/username/repo.git
 * [new tag]         v1.0.0 -> v1.0.0
 * [new tag]         v1.1.0 -> v1.1.0
 * [new tag]         v2.0.0 -> v2.0.0

Annotated Tag만 푸시

bash

# Annotated Tag만 푸시 (Lightweight 제외)
git push origin --follow-tags

실전 워크플로우

bash

# === 릴리즈 배포 과정 ===

# 1. 최종 커밋 완료
git add .
git commit -m "chore: v1.0.0 릴리즈 준비"

# 2. Tag 생성
git tag -a v1.0.0 -m "Release v1.0.0"

# 3. main 브랜치 푸시
git push origin main

# 4. Tag 푸시
git push origin v1.0.0

# 또는 한번에
git push origin main --follow-tags

- Tag로 체크아웃하기

Tag로 이동 (읽기 전용)

bash

# Tag로 체크아웃
git checkout v1.0.0

# 경고 메시지
Note: checking out 'v1.0.0'.
You are in 'detached HEAD' state...

# 이 상태에서는 읽기만 가능
# 커밋은 가능하지만 저장되지 않음

Tag 기반으로 브랜치 생성

bash

# Tag를 기반으로 새 브랜치 생성
git checkout -b hotfix-v1.0.1 v1.0.0

# 이제 이 브랜치에서 작업 가능
# ... 버그 수정 ...
git add .
git commit -m "fix: 긴급 버그 수정"

# 새 Tag 생성
git tag -a v1.0.1 -m "핫픽스 릴리즈"
git push origin hotfix-v1.0.1
git push origin v1.0.1

특정 Tag의 코드 확인

bash

# Tag의 파일 보기
git show v1.0.0:src/app.js

# Tag 시점의 전체 파일 목록
git ls-tree -r v1.0.0 --name-only

# Tag 시점의 코드 비교
git diff v1.0.0 v2.0.0

- Semantic Versioning (유의적 버전)

SemVer 규칙

버전 번호는 MAJOR.MINOR.PATCH 형식을 따릅니다.

버전 형식: v주버전.부버전.수버전

예시: v2.4.1
      ↑ ↑ ↑
      │ │ └─ PATCH: 버그 수정 (2.4.0 → 2.4.1)
      │ └─── MINOR: 기능 추가 (2.3.0 → 2.4.0)
      └───── MAJOR: 호환성 없는 변경 (1.x.x → 2.0.0)

버전 증가 규칙

버전증가 시점예시

MAJOR	기존 API와 호환되지 않는 변경	v1.5.3 → v2.0.0
MINOR	하위 호환되는 새 기능 추가	v1.5.3 → v1.6.0
PATCH	하위 호환되는 버그 수정	v1.5.3 → v1.5.4

버전 번호 예시

bash

# 첫 번째 개발 버전
v0.1.0   # 개발 초기

# 베타 버전
v0.9.0   # 거의 완성
v0.9.1   # 베타 버그 수정

# 첫 정식 릴리즈
v1.0.0   # 정식 출시!

# 버그 수정
v1.0.1   # 긴급 버그 수정
v1.0.2   # 추가 버그 수정

# 새 기능 추가
v1.1.0   # 사용자 알림 기능 추가
v1.2.0   # 검색 기능 추가

# 큰 변경
v2.0.0   # 전체 UI 개편 (호환성 깨짐)
v2.0.1   # 버그 수정
v2.1.0   # 새 기능 추가

Pre-release 버전

bash

# 알파 버전 (내부 테스트)
v1.0.0-alpha
v1.0.0-alpha.1

# 베타 버전 (공개 테스트)
v1.0.0-beta
v1.0.0-beta.1
v1.0.0-beta.2

# RC (Release Candidate)
v1.0.0-rc.1
v1.0.0-rc.2

# 정식 릴리즈
v1.0.0

실전 버전 관리 예시

bash

# 프로젝트 시작
git tag -a v0.1.0 -m "초기 개발 버전"

# 기능 추가
git tag -a v0.2.0 -m "로그인 기능 추가"
git tag -a v0.3.0 -m "프로필 기능 추가"

# 베타 테스트
git tag -a v0.9.0-beta -m "베타 버전"
git tag -a v0.9.1-beta -m "베타 버그 수정"

# 정식 출시
git tag -a v1.0.0 -m "정식 출시!"

# 버그 수정
git tag -a v1.0.1 -m "로그인 버그 수정"

# 새 기능
git tag -a v1.1.0 -m "알림 기능 추가"

# 큰 변경
git tag -a v2.0.0 -m "새로운 UI 및 API 변경"

- GitHub Release 만들기

GitHub에서 Tag를 사용해 Release를 만들 수 있습니다.

방법 1: CLI로 Release 생성

bash

# 1. Tag 생성
git tag -a v1.0.0 -m "Release v1.0.0"

# 2. Tag 푸시
git push origin v1.0.0

# 3. GitHub에서 자동으로 Release 페이지 생성됨
# https://github.com/username/repo/releases/tag/v1.0.0

방법 2: GitHub 웹에서 Release 생성

1. GitHub 저장소 페이지 접속
2. "Releases" 탭 클릭
3. "Create a new release" 버튼 클릭
4. Tag 선택 또는 새로 생성
5. Release title 입력 (예: v1.0.0)
6. Release notes 작성
7. 파일 첨부 (선택 사항)
8. "Publish release" 클릭

Release Notes 작성 예시

markdown

## v1.0.0 - 2024-12-16

###   새로운 기능
- 사용자 인증 시스템 (로그인/회원가입)
- 프로필 관리 페이지
- 대시보드 구현

###   버그 수정
- 로그인 세션 만료 이슈 수정
- 모바일 반응형 UI 개선
- 이메일 유효성 검사 버그 수정

###   개선 사항
- API 응답 속도 30% 향상
- 데이터베이스 쿼리 최적화
- 에러 메시지 개선

### ⚠️ Breaking Changes
- 없음

###   의존성
- React 18.2.0
- Node.js 18.x 이상 필요

###   기여자
- @ryan-sin
- @sarah-kim
- @john-lee

**Full Changelog**: https://github.com/username/repo/compare/v0.9.0...v1.0.0

- 실전 릴리즈 워크플로우

전체 릴리즈 프로세스

bash

# === 1. 개발 완료 확인 ===
# 모든 기능이 develop 브랜치에 병합됨

# === 2. Release 브랜치 생성 ===
git checkout develop
git checkout -b release/v1.0.0

# === 3. 버전 번호 업데이트 ===
# package.json, version.txt 등에서 버전 번호 수정
git add .
git commit -m "chore: bump version to 1.0.0"

# === 4. 최종 테스트 ===
# 테스트 실행, 버그 수정

# === 5. main 브랜치로 병합 ===
git checkout main
git merge --no-ff release/v1.0.0
git push origin main

# === 6. Tag 생성 ===
git tag -a v1.0.0 -m "Release v1.0.0

주요 기능:
- 사용자 인증
- 프로필 관리
- 대시보드

버그 수정:
- 로그인 세션 이슈
- UI 반응형 개선"

# === 7. Tag 푸시 ===
git push origin v1.0.0

# === 8. develop 브랜치에도 병합 ===
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop

# === 9. Release 브랜치 삭제 ===
git branch -d release/v1.0.0

# === 10. GitHub에서 Release 생성 ===
# GitHub 웹 인터페이스에서 Release Notes 작성

핫픽스 워크플로우

bash

# === 긴급 버그 발견! v1.0.0 → v1.0.1 ===

# 1. main 브랜치의 Tag에서 hotfix 브랜치 생성
git checkout -b hotfix/v1.0.1 v1.0.0

# 2. 버그 수정
# ... 코드 수정 ...
git add .
git commit -m "fix: 로그인 버그 긴급 수정"

# 3. 버전 번호 업데이트
git commit -m "chore: bump version to 1.0.1"

# 4. main에 병합
git checkout main
git merge --no-ff hotfix/v1.0.1
git push origin main

# 5. Tag 생성 및 푸시
git tag -a v1.0.1 -m "핫픽스: 로그인 버그 수정"
git push origin v1.0.1

# 6. develop에도 병합
git checkout develop
git merge --no-ff hotfix/v1.0.1
git push origin develop

# 7. hotfix 브랜치 삭제
git branch -d hotfix/v1.0.1

- Tag 명령어 정리

bash

# === 생성 ===
git tag v1.0.0                           # Lightweight Tag
git tag -a v1.0.0 -m "메시지"             # Annotated Tag (권장)
git tag -a v1.0.0 커밋해시 -m "메시지"     # 특정 커밋에 Tag

# === 확인 ===
git tag                                  # Tag 목록
git tag -l "v1.*"                        # 패턴으로 검색
git tag -n                               # 메시지와 함께 보기
git show v1.0.0                          # Tag 상세 정보
git log --oneline --decorate             # 커밋과 Tag 함께 보기

# === 삭제 ===
git tag -d v1.0.0                        # 로컬 Tag 삭제
git push origin --delete v1.0.0          # 원격 Tag 삭제
git push origin :refs/tags/v1.0.0        # 원격 Tag 삭제 (다른 방법)

# === 푸시 ===
git push origin v1.0.0                   # 특정 Tag 푸시
git push origin --tags                   # 모든 Tag 푸시
git push origin --follow-tags            # Annotated Tag만 푸시

# === 체크아웃 ===
git checkout v1.0.0                      # Tag로 이동 (detached HEAD)
git checkout -b 브랜치명 v1.0.0           # Tag 기반 브랜치 생성

# === 비교 ===
git diff v1.0.0 v2.0.0                   # 두 Tag 비교
git log v1.0.0..v2.0.0                   # Tag 간 커밋 이력

- Tag 사용 팁

1. 항상 Annotated Tag 사용

bash

❌ 나쁜 예:
git tag v1.0.0

✅ 좋은 예:
git tag -a v1.0.0 -m "Release v1.0.0 - 첫 번째 정식 릴리즈"

2. 의미있는 메시지 작성

bash

❌ 나쁜 예:
git tag -a v1.0.0 -m "릴리즈"

✅ 좋은 예:
git tag -a v1.0.0 -m "Release v1.0.0

주요 기능:
- 사용자 인증 시스템
- 프로필 관리
- 대시보드

버그 수정:
- 로그인 세션 만료 이슈
- UI 반응형 개선"

3. Semantic Versioning 준수

bash

# MAJOR: 호환성 없는 변경
v1.0.0 → v2.0.0

# MINOR: 새 기능 추가
v1.0.0 → v1.1.0

# PATCH: 버그 수정
v1.0.0 → v1.0.1

4. Tag 푸시 잊지 않기

bash

# Tag는 자동으로 푸시되지 않음!
git push origin main
git push origin v1.0.0  # Tag도 별도로 푸시

# 또는 한번에
git push origin main --follow-tags

5. 공개된 Tag는 수정하지 않기

bash

# 이미 배포된 Tag는 절대 수정하지 마세요
# 대신 새로운 버전을 만드세요

# ❌ 나쁜 예:
git tag -d v1.0.0
git tag -a v1.0.0 -m "수정..."
git push origin v1.0.0 --force

# ✅ 좋은 예:
git tag -a v1.0.1 -m "수정 사항 포함"
git push origin v1.0.1

6. CHANGELOG 파일 유지

bash

# CHANGELOG.md 파일에 버전별 변경 사항 기록

## [1.0.0] - 2024-12-16
### Added
- 사용자 인증 기능
- 프로필 관리

### Fixed
- 로그인 버그 수정

### Changed
- API 응답 속도 개선

- 자주 하는 실수와 해결법

실수 1: Tag를 푸시하지 않음

문제: bash

git tag -a v1.0.0 -m "릴리즈"
git push origin main
# Tag는 푸시되지 않음!

해결: bash

# Tag도 별도로 푸시해야 함
git push origin v1.0.0

# 또는 항상 함께 푸시
git push origin main --follow-tags

실수 2: 잘못된 버전 번호

문제: bash

git tag v1.0.0
# 이미 v1.1.0이 있는데...

해결: bash

# 항상 최신 Tag 확인
git tag | sort -V

# 올바른 버전 번호 사용
git tag -a v1.2.0 -m "메시지"

실수 3: Lightweight Tag 사용

문제: bash

git tag v1.0.0  # 정보가 부족함

해결: bash

# 삭제 후 Annotated Tag 재생성
git tag -d v1.0.0
git tag -a v1.0.0 -m "상세한 메시지"

실수 4: 공개된 Tag 수정

문제: bash

git tag -d v1.0.0
git tag -a v1.0.0 -m "수정"
git push origin v1.0.0 --force
# 다른 사람들에게 혼란!

해결: bash

# 새로운 버전 만들기
git tag -a v1.0.1 -m "수정 사항"
git push origin v1.0.1

실수 5: Tag와 브랜치 이름 중복

문제: bash

git tag v1.0.0
git branch v1.0.0  # 혼란 발생

해결 : bash

# Tag와 브랜치는 다른 이름 사용
git tag v1.0.0
git branch release/v1.0.0  # 명확한 구분

마무리

이번 시간에는 Git Tag를 사용한 버전 관리와 릴리즈에 대해 알아봤습니다. Tag는 소프트웨어의 특정 시점을 표시하는 중요한 기능으로, 릴리즈 관리에 필수적입니다. 항상 Annotated Tag를 사용하고, Semantic Versioning 규칙을 따르며, 의미있는 메시지를 작성하는 습관을 들이시기 바랍니다. Tag는 한번 공개하면 수정하지 않는 것이 원칙입니다.

다음 시간에는 Git Reset vs Revert vs Restore에 대해 알아보겠습니다.

[Git] - Git Stash - 임시 저장 활용법

RyanSin — Fri, 26 Dec 2025 20:00:30 +0900

개요

안녕하세요. 이번 시간에는 Git Stash에 대해 알아보겠습니다. Stash는 작업 중인 변경사항을 임시로 저장하는 기능으로, 브랜치 전환이나 긴급 작업 시 매우 유용합니다. 실무에서 자주 사용하는 필수 기능이니 꼭 익혀두시기 바랍니다. 혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 학습하고 오시는 걸 추천드리겠습니다.

[Git] - Pull Request(PR) / Merge Request(MR) 작성법

- Stash란?

Stash는 현재 작업 중인 변경사항을 임시로 저장해두는 Git의 기능입니다. 커밋하지 않은 변경사항을 안전하게 보관하고, 나중에 다시 불러올 수 있습니다.

Stash의 필요성

상황 1: 기능 개발 중인데 긴급 버그 수정 요청이 들어옴
- 현재 작업을 커밋하기엔 아직 완성되지 않음
- 하지만 브랜치를 전환해야 함
- 해결: Stash로 임시 저장!

상황 2: 잘못된 브랜치에서 작업함
- develop에서 작업해야 하는데 main에서 작업 중
- 변경사항을 이동시켜야 함
- 해결: Stash로 저장하고 올바른 브랜치로 이동!

상황 3: pull 전에 로컬 변경사항이 있음
- git pull을 해야 하는데 충돌 우려
- 해결: Stash로 저장하고 pull 후 복원!

Stash 저장 위치

Working Directory    Stash Stack    Repository
 (작업 디렉토리)        (임시 저장소)      (저장소)
      |                   |               |
      | git stash save    |               |
      | ----------------> |               |
      |                   |               |
      | git stash pop     |               |
      | <---------------- |               |

Stash는 스택(Stack) 구조로 관리됩니다. 가장 최근에 저장한 것이 가장 먼저 나옵니다.

- Stash 기본 명령어

1. 변경사항 저장하기

# 기본 stash 저장
git stash

# 또는
git stash save

# 메시지와 함께 저장 (권장)
git stash save "작업 내용 설명"

# 예시
git stash save "로그인 기능 작업 중"

# 출력
Saved working directory and index state On feature/login: 로그인 기능 작업 중

2. Stash 목록 확인하기

# 저장된 stash 목록 보기
git stash list

# 출력 예시
stash@{0}: On feature/login: 로그인 기능 작업 중
stash@{1}: WIP on main: a1b2c3d Update README
stash@{2}: On develop: 결제 모듈 테스트

stash 번호 이해하기:

stash@{0}: 가장 최근에 저장한 stash
stash@{1}: 그 이전에 저장한 stash
stash@{2}: 더 이전에 저장한 stash

3. Stash 내용 확인하기

# 가장 최근 stash의 변경사항 확인
git stash show

# 출력
 src/login.js | 15 +++++++++++++++
 src/auth.js  |  8 ++++++--
 2 files changed, 21 insertions(+), 2 deletions(-)

# 상세 변경 내용 확인 (diff)
git stash show -p

# 특정 stash 확인
git stash show stash@{1}
git stash show -p stash@{1}

4. Stash 복원하기

# 방법 1: pop (복원 후 stash 삭제) - 일반적으로 사용
git stash pop

# 특정 stash를 pop
git stash pop stash@{1}

# 방법 2: apply (복원 후 stash 유지)
git stash apply

# 특정 stash를 apply
git stash apply stash@{2}

pop vs apply 차이:

명령어 복원 stash 보존 사용 시점

pop	✅	❌ 삭제됨	일반적인 경우 (권장)
apply	✅	✅ 유지됨	여러 브랜치에 적용해야 할 때

5. Stash 삭제하기

# 가장 최근 stash 삭제
git stash drop

# 특정 stash 삭제
git stash drop stash@{1}

# 모든 stash 삭제
git stash clear

# 삭제 전 확인
git stash list

- Stash 고급 사용법

1. Untracked 파일도 함께 저장

기본적으로 stash는 추적 중인(tracked) 파일만 저장합니다.

# 새로 생성한 파일(untracked)도 함께 저장
git stash save -u "메시지"

# 또는
git stash save --include-untracked "메시지"

# 예시
echo "새 파일" > new-file.txt
git stash save -u "새 파일 포함하여 저장"

2. 특정 파일만 Stash

# 특정 파일만 stash (Git 2.13+)
git stash push -m "메시지" 파일1 파일2

# 예시
git stash push -m "로그인 파일만 저장" src/login.js src/auth.js

3. Stash를 브랜치로 만들기

stash를 새로운 브랜치로 만들 수 있습니다.

# stash를 새 브랜치로 생성
git stash branch 브랜치명

# 예시
git stash branch feature/stashed-work

# 결과:
# 1. 새 브랜치 생성
# 2. stash 내용이 자동으로 적용됨
# 3. stash가 자동으로 삭제됨

4. Stash를 커밋으로 확인

# stash는 내부적으로 커밋입니다
# stash의 커밋 해시 확인
git stash list --format="%gd: %H"

# 출력
stash@{0}: a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0

- 실전 시나리오

시나리오 1: 긴급 버그 수정

# 상황: feature/payment 브랜치에서 결제 기능 개발 중
# 긴급: main 브랜치의 버그를 수정해야 함

# 1. 현재 작업 저장
git stash save "결제 기능 개발 중"

# 2. 상태 확인 (깨끗한 상태)
git status
# On branch feature/payment
# nothing to commit, working tree clean

# 3. main 브랜치로 이동
git checkout main

# 4. 버그 수정
# ... 버그 수정 작업 ...
git add .
git commit -m "fix: 긴급 버그 수정"

# 5. 다시 feature/payment로 돌아가기
git checkout feature/payment

# 6. 저장했던 작업 복원
git stash pop

# 7. 계속 작업
# ... 결제 기능 개발 계속 ...

시나리오 2: 잘못된 브랜치에서 작업

# 상황: main 브랜치에서 작업했는데, develop에서 했어야 함

# 1. 변경사항 확인
git status
# On branch main
# Changes not staged for commit:
#   modified:   src/app.js

# 2. 현재 작업 저장
git stash save "develop에서 작업해야 하는 내용"

# 3. 올바른 브랜치로 이동
git checkout develop

# 4. 저장했던 작업 복원
git stash pop

# 5. 이제 올바른 브랜치에서 작업 계속
git add .
git commit -m "feat: 새 기능 추가"

시나리오 3: Pull 전에 로컬 변경사항 처리

# 상황: 원격 저장소를 pull 해야 하는데 로컬에 변경사항이 있음

# 1. 현재 작업 저장
git stash save "pull 전 로컬 작업"

# 2. 원격 저장소에서 최신 코드 가져오기
git pull origin develop

# 3. 저장했던 작업 복원
git stash pop

# 4. 충돌이 발생하면 해결
# ... 충돌 해결 ...
git add .

시나리오 4: 여러 브랜치에 같은 수정 적용

# 상황: 같은 버그 수정을 여러 브랜치에 적용해야 함

# 1. 버그 수정 작업
# ... 버그 수정 ...

# 2. 수정 내용을 stash로 저장
git stash save "공통 버그 수정"

# 3. 첫 번째 브랜치에 적용
git checkout feature/login
git stash apply  # apply 사용 (stash 유지)
git add .
git commit -m "fix: 버그 수정"

# 4. 두 번째 브랜치에 적용
git checkout feature/payment
git stash apply  # 같은 stash를 다시 apply
git add .
git commit -m "fix: 버그 수정"

# 5. 세 번째 브랜치에 적용
git checkout feature/profile
git stash pop    # 마지막은 pop으로 stash 삭제
git add .
git commit -m "fix: 버그 수정"

- Stash 워크플로우 전체 예시

실제 개발 과정에서의 stash 사용 예시입니다.

# === 오전 9시: 새 기능 개발 시작 ===
git checkout -b feature/user-dashboard
# ... 코딩 ...
echo "대시보드 컴포넌트" > dashboard.js

# === 오전 11시: 긴급 회의로 인한 작업 중단 ===
git stash save "대시보드 기능 개발 중 - 50% 완성"

# === 오후 2시: 다른 긴급 작업 ===
git checkout develop
git checkout -b hotfix/security-issue
# ... 보안 이슈 수정 ...
git commit -m "fix: 보안 취약점 수정"
git checkout develop
git merge hotfix/security-issue

# === 오후 3시: 원래 작업 재개 ===
git checkout feature/user-dashboard
git stash list
# stash@{0}: On feature/user-dashboard: 대시보드 기능 개발 중 - 50% 완성

git stash pop
# ... 작업 계속 ...

# === 오후 5시: 작업 완료 ===
git add .
git commit -m "feat: 사용자 대시보드 구현 완료"
git push origin feature/user-dashboard

- Stash와 Commit 비교

항목 Stash Commit

목적	임시 저장	영구 저장
공유	로컬 전용	원격 공유 가능
히스토리	포함 안됨	포함됨
메시지	선택 사항	필수
사용 시점	작업 중단 시	작업 완료 시
복원	pop/apply	checkout

언제 Stash를 쓸까?

✅ Stash 사용:
- 작업이 아직 완성되지 않았을 때
- 임시로 다른 작업을 해야 할 때
- 커밋하기에는 너무 작은 변경일 때

✅ Commit 사용:
- 작업이 완성되었을 때
- 의미있는 변경 단위일 때
- 팀원과 공유해야 할 때

- Stash 충돌 해결

stash를 복원할 때 충돌이 발생할 수 있습니다.

충돌 발생 예시

# stash pop 시도
git stash pop

# 충돌 발생!
Auto-merging src/app.js
CONFLICT (content): Merge conflict in src/app.js

충돌 해결 방법

# 1. 충돌 파일 확인
git status

# 출력
Unmerged paths:
  both modified:   src/app.js

# 2. 파일 열어서 충돌 부분 수정
# src/app.js 파일 내용:
<<<<<<< Updated upstream
현재 브랜치의 내용
=======
Stash에 저장된 내용
>>>>>>> Stashed changes

# 3. 충돌 해결 후 저장
# ... 원하는 내용으로 수정 ...

# 4. 스테이징
git add src/app.js

# 5. stash 충돌 해결 완료
# (자동으로 stash가 삭제됨)

# 만약 stash를 유지하고 싶다면
git stash drop  # 수동으로 삭제

충돌 시 안전하게 취소하기

# 충돌이 복잡해서 취소하고 싶을 때
git reset --merge

# stash는 그대로 유지되므로 나중에 다시 시도 가능

- 자주 하는 실수와 해결법

실수 1: Stash를 까먹음

문제:

git stash save "중요한 작업"
# ... 한참 후 ...
# 어디에 저장했더라?

해결:

# 항상 의미있는 메시지와 함께 저장
git stash save "로그인 기능 - 폼 유효성 검사 추가 중"

# stash 목록 확인
git stash list

실수 2: 여러 개의 Stash가 쌓임

문제:

git stash list
stash@{0}: WIP on main
stash@{1}: WIP on develop
stash@{2}: WIP on feature
stash@{3}: WIP on bugfix
# ... 너무 많아!

해결:

# 필요없는 stash 정리
git stash drop stash@{3}
git stash drop stash@{2}

# 또는 특정 stash를 최신으로 만들기
git stash apply stash@{3}
git stash drop stash@{3}
git stash save "정리한 작업"

# 모두 삭제하고 새로 시작
git stash clear

실수 3: Stash 했는데 파일이 사라짐

문제:

git stash save
# 어? 파일이 다 사라졌어!

설명:

Stash는 정상 작동한 것입니다!
- stash는 변경사항을 "임시 보관"하고
- 작업 디렉토리를 "깨끗한 상태"로 만듭니다

복원:

# 바로 복원하면 됩니다
git stash pop

실수 4: Stash Pop 후 충돌 발생

문제:

git stash pop
# 충돌 발생... 어떻게 하지?

주의:

충돌이 발생하면 stash가 자동으로 삭제되지 않습니다!
수동으로 충돌을 해결한 후 drop 해야 합니다.

해결:

# 1. 충돌 해결
# ... 파일 수정 ...
git add .

# 2. stash 수동 삭제
git stash drop

# 또는 처음부터 apply 사용
git stash apply  # 충돌 해결 후에도 stash 유지

실수 5: 잘못된 Stash를 Pop

문제:

git stash pop
# 어? 이게 아닌데...

해결:

# 1. 바로 다시 stash로 저장
git stash save "다시 저장"

# 2. 원하는 stash 찾기
git stash list

# 3. 올바른 stash 복원
git stash pop stash@{1}

- Stash 명령어 정리

# === 저장 ===
git stash                              # 현재 변경사항 저장
git stash save "메시지"                 # 메시지와 함께 저장
git stash save -u "메시지"              # untracked 파일 포함
git stash push -m "메시지" 파일명       # 특정 파일만 저장

# === 확인 ===
git stash list                         # stash 목록 보기
git stash show                         # 최근 stash 변경사항
git stash show -p                      # 최근 stash 상세 내용
git stash show stash@{N}               # 특정 stash 확인

# === 복원 ===
git stash pop                          # 최근 stash 복원 및 삭제
git stash pop stash@{N}                # 특정 stash 복원 및 삭제
git stash apply                        # 최근 stash 복원 (유지)
git stash apply stash@{N}              # 특정 stash 복원 (유지)

# === 삭제 ===
git stash drop                         # 최근 stash 삭제
git stash drop stash@{N}               # 특정 stash 삭제
git stash clear                        # 모든 stash 삭제

# === 고급 ===
git stash branch 브랜치명               # stash를 브랜치로 만들기

- Stash 사용 팁

1. 의미있는 메시지 작성

❌ 나쁜 예:
git stash save "임시"
git stash save "작업중"

✅ 좋은 예:
git stash save "로그인 폼 - 이메일 유효성 검사 추가 중"
git stash save "결제 API 연동 - 테스트 코드 작성 전"

2. 주기적으로 Stash 정리

# 일주일에 한 번 정도 확인
git stash list

# 필요없는 것은 삭제
git stash drop stash@{5}
git stash drop stash@{4}

# 또는 필요한 것만 남기고 모두 삭제
git stash clear

3. Stash 전에 Diff 확인

# stash 하기 전에 무엇이 저장되는지 확인
git diff

# 변경사항 확인 후 stash
git stash save "확인한 변경사항"

4. Pop 대신 Apply 사용 고려

# 안전하게 apply로 먼저 확인
git stash apply

# 문제 없으면 수동으로 삭제
git stash drop

# 문제 있으면 다시 reset
git reset --hard

5. 브랜치 전환 전에 항상 확인

# 브랜치 전환 전에
git status

# 변경사항이 있다면
git stash save "브랜치 전환 전 작업"

# 그 다음 브랜치 전환
git checkout other-branch

마무리

이번 시간에는 Git Stash의 사용법에 대해 알아봤습니다. Stash는 작업 중인 변경사항을 임시로 저장하는 매우 유용한 기능입니다. 브랜치 전환, 긴급 작업, pull 전 변경사항 처리 등 실무에서 자주 사용하게 되니 꼭 익숙해지시길 바랍니다. 특히 git stash pop과 git stash apply의 차이를 이해하고, 의미있는 메시지와 함께 저장하는 습관을 들이는 것이 중요합니다.

다음 시간에는 Git Tag - 버전 관리 및 릴리즈에 대해 알아보겠습니다.

[Git] - Pull Request(PR) / Merge Request(MR) 작성법

RyanSin — Thu, 25 Dec 2025 20:00:59 +0900

개요

안녕하세요. 이번 시간에는 협업에서 가장 중요한 Pull Request(PR)와 Merge Request(MR) 작성법에 대해 알아보겠습니다. GitHub에서는 Pull Request, GitLab에서는 Merge Request라고 부르지만 기본 개념은 동일합니다. 혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 학습하고 오시는 걸 추천드리겠습니다.

[Git] - Clone vs Fork 차이점

- Pull Request란?

Pull Request(PR)는 내가 작성한 코드를 프로젝트의 메인 브랜치에 병합해달라고 요청하는 기능입니다. 단순히 코드를 합치는 것이 아니라, 코드 리뷰를 받고 팀원들과 소통하는 협업의 핵심 도구입니다.

PR의 목적

코드 리뷰를 통한 품질 향상
팀원들과의 코드 공유 및 토론
변경 사항에 대한 문서화
자동화된 테스트 실행
프로젝트의 히스토리 관리

GitHub vs GitLab 용어 비교

GitHubGitLab의미

Pull Request (PR)	Merge Request (MR)	병합 요청
Review	Approval	승인
Assignee	Assignee	담당자
Reviewer	Reviewer	리뷰어

이 글에서는 GitHub 기준으로 설명하지만, GitLab도 동일한 방식으로 사용할 수 있습니다.

- PR 생성 전 준비사항

1. 브랜치 전략 이해하기

PR을 만들기 전에 팀의 브랜치 전략을 이해해야 합니다.

main (또는 master)
  ↑
  └─ develop
       ↑
       ├─ feature/login
       ├─ feature/user-profile
       └─ bugfix/header-issue

일반적으로 다음과 같은 브랜치 구조를 사용합니다:

브랜치용도예시

main/master	배포용 안정 브랜치	main
develop	개발용 통합 브랜치	develop
feature/*	새 기능 개발	feature/login
bugfix/*	버그 수정	bugfix/header-issue
hotfix/*	긴급 수정	hotfix/security-patch

2. 작업 브랜치 생성 및 작업

bash

# develop 브랜치로 이동
git checkout develop

# 최신 상태로 업데이트
git pull origin develop

# 새 브랜치 생성 및 이동
git checkout -b feature/user-authentication

# 작업 진행...
# 파일 수정, 추가 등

# 변경사항 확인
git status

# 스테이징
git add .

# 커밋 (의미있는 메시지 작성)
git commit -m "feat: 사용자 인증 기능 구현

- JWT 토큰 기반 인증 추가
- 로그인/로그아웃 API 구현
- 인증 미들웨어 추가"

# 원격 저장소에 푸시
git push origin feature/user-authentication

3. 커밋 정리하기

PR을 생성하기 전에 커밋을 깔끔하게 정리하는 것이 좋습니다.

bash

# 최근 3개 커밋 합치기
git rebase -i HEAD~3

# 에디터에서 pick을 squash로 변경
# pick abc1234 feat: 로그인 기능 추가
# squash def5678 fix: 로그인 버그 수정
# squash ghi9012 refactor: 코드 정리

# 강제 푸시 (주의: 이미 공유된 브랜치는 피하기)
git push origin feature/user-authentication --force

⚠️ 주의: 다른 사람과 공유하는 브랜치에서는 force push를 피하세요!

- GitHub에서 PR 생성하기

1. PR 생성 페이지 접근

GitHub 저장소에서 PR을 생성하는 방법은 여러 가지가 있습니다:

방법 1: 푸시 직후 노란색 배너 클릭

푸시 직후 저장소 페이지에 나타나는
"Compare & pull request" 버튼 클릭

방법 2: Pull requests 탭에서 생성

1. Pull requests 탭 클릭
2. "New pull request" 버튼 클릭
3. 브랜치 선택

방법 3: 브랜치에서 직접 생성

1. Code 탭의 브랜치 드롭다운 클릭
2. 원하는 브랜치 옆 PR 아이콘 클릭

2. 브랜치 선택

PR을 생성할 때 다음을 명확히 선택해야 합니다

base: develop  ← into (병합될 대상 브랜치)
compare: feature/user-authentication  ← from (내가 작업한 브랜치)

3. PR 제목 작성

좋은 PR 제목 예시:

✅ 좋은 예시:
- feat: 사용자 인증 기능 구현
- fix: 헤더 메뉴 모바일 반응형 버그 수정
- refactor: API 호출 로직을 React Query로 개선
- docs: API 문서에 인증 엔드포인트 추가

❌ 나쁜 예시:
- 작업 완료
- 수정
- Update
- 기능 추가

4. PR 설명 작성

PR 설명은 변경 사항을 명확히 전달하는 중요한 부분입니다.

기본 템플릿:

markdown

## 작업 내용
이 PR에서 무엇을 했는지 간단히 설명합니다.

## 변경 사항
- JWT 기반 인증 시스템 구현
- 로그인/로그아웃 API 엔드포인트 추가
- 인증 미들웨어 추가
- 로그인 페이지 UI 구현

## 테스트 방법
1. `npm install` 실행
2. `npm run dev` 로 서버 실행
3. `/login` 페이지 접속
4. test@example.com / password123 으로 로그인
5. 대시보드 페이지로 리다이렉트 확인

## 스크린샷 (필요시)
![로그인 화면](이미지_URL)

## 관련 이슈
- Closes #123
- Related to #456

## 체크리스트
- [x] 코드 작성 완료
- [x] 로컬 테스트 완료
- [x] 코드 리뷰 준비 완료
- [ ] 문서 업데이트 필요

실제 작성 예시:

markdown

## 작업 내용
사용자 인증 기능을 JWT 기반으로 구현했습니다.

## 변경 사항
### Backend
- `/api/auth/login` POST 엔드포인트 추가
- `/api/auth/logout` POST 엔드포인트 추가
- JWT 토큰 생성 및 검증 로직 구현
- 인증 미들웨어 (`authMiddleware.js`) 추가

### Frontend
- 로그인 페이지 UI 구현 (`/pages/Login.jsx`)
- 로그인 폼 유효성 검사 추가
- 토큰 저장 및 관리 (localStorage)
- Axios 인터셉터에 토큰 자동 포함

## 주요 기술 스택
- JWT (jsonwebtoken)
- bcrypt (비밀번호 암호화)
- React Hook Form (폼 관리)

## 테스트 방법
### 로컬 환경 설정
```bash
npm install
cp .env.example .env
# .env 파일에서 JWT_SECRET 설정
npm run dev
```

### 테스트 시나리오
1. http://localhost:3000/login 접속
2. 테스트 계정으로 로그인
   - Email: test@example.com
   - Password: password123
3. 로그인 성공 후 대시보드로 이동 확인
4. 로그아웃 버튼 클릭 후 로그인 페이지로 이동 확인
5. 인증 없이 /dashboard 접근 시 로그인 페이지로 리다이렉트 확인

## 관련 이슈
Closes #45

## 리뷰 요청 사항
- 보안 관련 부분 특히 신경써서 리뷰 부탁드립니다
- JWT 토큰 만료 시간이 적절한지 확인 부탁드립니다

- PR 옵션 설정

1. Reviewers (리뷰어) 지정

코드 리뷰를 받을 팀원을 지정합니다.

  팁:
- 해당 분야 전문가를 최소 1명 이상 지정
- 팀 규모에 따라 2-3명 정도가 적당
- 모든 팀원을 지정하면 책임이 분산될 수 있음

2. Assignees (담당자) 지정

PR의 책임자를 지정합니다. 보통 본인을 지정합니다.

3. Labels (레이블) 추가

PR의 성격을 표시합니다.

레이블의미예시

feature	새 기능	로그인 기능
bugfix	버그 수정	헤더 버그 수정
hotfix	긴급 수정	보안 패치
documentation	문서 작업	README 업데이트
refactoring	리팩토링	코드 정리
WIP	작업 중	Work In Progress
needs review	리뷰 필요	-

4. Milestone (마일스톤) 설정

특정 버전이나 목표와 연결합니다.

예시:
- v1.0.0 Release
- Q1 2024 Features
- Sprint 15

5. Projects 연결

프로젝트 보드와 연결하여 진행 상황을 추적합니다.

- 코드 리뷰 받기

1. 리뷰 요청 알림

리뷰어가 지정되면 자동으로 알림이 전송됩니다.

2. 리뷰 유형

GitHub에서 리뷰어가 남길 수 있는 피드백 유형:

유형의미아이콘

Comment	단순 의견
Approve	승인 (머지 가능)	✅
Request changes	수정 요청 (머지 불가)	❌

3. 리뷰 코멘트에 응답하기

코멘트 확인:

1. PR 페이지의 "Files changed" 탭 확인
2. 각 코멘트 확인 및 응답
3. 필요시 추가 커밋으로 수정

응답 예시:

markdown

> 이 부분에서 에러 핸들링이 필요할 것 같습니다.

좋은 지적 감사합니다! try-catch 블록을 추가했습니다.
커밋: a1b2c3d

4. 수정 후 추가 커밋

bash

# 리뷰 반영하여 수정
git add .
git commit -m "review: 에러 핸들링 로직 추가"
git push origin feature/user-authentication

# 자동으로 PR에 반영됨

5. 리뷰 완료 후 대응

모든 리뷰가 Approve인 경우:

✅ 머지 준비 완료!

Request changes가 있는 경우:

❌ 요청사항 수정 후 다시 리뷰 요청
- "Re-request review" 버튼 클릭

- PR 머지하기

머지 전 체크리스트

markdown

- [ ] 모든 리뷰가 Approve 상태인가?
- [ ] CI/CD 테스트가 통과했는가?
- [ ] 충돌(Conflict)이 없는가?
- [ ] 최신 base 브랜치를 merge 했는가?
- [ ] 문서가 업데이트 되었는가?

머지 옵션 선택

GitHub에서는 3가지 머지 방식을 제공합니다.

1. Create a merge commit (기본)

bash

# 모든 커밋 이력이 보존됨
# 머지 커밋이 생성됨

git merge --no-ff feature/user-authentication

장점:

완전한 히스토리 보존
브랜치 흐름을 명확히 볼 수 있음

단점:

커밋 히스토리가 복잡해질 수 있음

2. Squash and merge (권장)

bash

# 여러 커밋을 하나로 합침
# 깔끔한 히스토리 유지

git merge --squash feature/user-authentication
git commit -m "feat: 사용자 인증 기능 구현 (#45)"

장점:

깔끔한 커밋 히스토리
하나의 기능 = 하나의 커밋

단점:

세부 커밋 이력이 사라짐

3. Rebase and merge (고급)

bash

# 커밋들을 base 브랜치 위로 재배치
# 선형 히스토리 유지

git rebase develop
git checkout develop
git merge feature/user-authentication

장점:

가장 깔끔한 선형 히스토리
머지 커밋이 생성되지 않음

단점:

히스토리 변경으로 인한 리스크
팀 전체가 이해해야 함

머지 방식 비교표

방식히스토리사용 시점난이도

Merge commit	복잡	브랜치 흐름 유지 필요시	⭐
Squash merge	깔끔	일반적인 경우 (권장)	⭐
Rebase merge	매우 깔끔	선형 히스토리 필요시	⭐⭐⭐

머지 실행

1. PR 페이지 하단의 "Merge pull request" 버튼 클릭
2. 머지 방식 선택 (Squash and merge 권장)
3. 커밋 메시지 확인/수정
4. "Confirm merge" 클릭

머지 후 정리

bash

# 로컬 브랜치로 이동
git checkout develop

# 최신 상태로 업데이트
git pull origin develop

# 작업 브랜치 삭제 (로컬)
git branch -d feature/user-authentication

# 작업 브랜치 삭제 (원격)
git push origin --delete feature/user-authentication

팁: GitHub에서 PR 머지 시 "Delete branch" 옵션을 체크하면 원격 브랜치가 자동 삭제됩니다.

- PR 작성 모범 사례

1. 작은 PR이 좋은 PR

❌ 나쁜 예: 1000줄 변경, 10개 파일 수정
✅ 좋은 예: 200줄 변경, 3-4개 파일 수정

  이유:
- 리뷰어가 집중하기 쉬움
- 버그 발견 확률 증가
- 빠른 피드백 가능

2. 명확한 제목과 설명

markdown

❌ 나쁜 예:
제목: 작업 완료
설명: 요청하신 기능 만들었습니다.

✅ 좋은 예:
제목: feat: 사용자 프로필 이미지 업로드 기능 추가
설명:
- S3 버킷 연동
- 이미지 리사이징 (최대 500x500)
- 지원 포맷: JPG, PNG (최대 5MB)

3. 테스트 포함

markdown

## 테스트
- [ ] 단위 테스트 작성 및 통과
- [ ] 통합 테스트 작성 및 통과
- [ ] 수동 테스트 완료
- [ ] 브라우저 호환성 테스트 (Chrome, Safari, Firefox)

4. 스크린샷/GIF 첨부

UI 변경이 있는 경우 시각적 자료를 첨부합니다.

markdown

## Before / After

### Before
![기존 화면](before.png)

### After
![변경 화면](after.png)

## 동작 영상
![기능 시연](demo.gif)

5. 관련 이슈/PR 연결

markdown

## 관련 이슈
Closes #123
Fixes #456
Related to #789

## 관련 PR
Depends on #100
Blocks #101

6. 체크리스트 활용

markdown

## PR 체크리스트
- [x] 코드 컨벤션 준수
- [x] 테스트 코드 작성
- [x] 문서 업데이트
- [x] CHANGELOG 업데이트
- [ ] 성능 테스트 완료

- PR 템플릿 설정하기

팀에서 일관된 PR을 작성하도록 템플릿을 설정할 수 있습니다.

GitHub PR 템플릿 생성

프로젝트 루트에 .github 폴더를 만들고 템플릿 파일을 추가합니다.

bash

# 디렉토리 생성
mkdir -p .github

# PR 템플릿 파일 생성
touch .github/PULL_REQUEST_TEMPLATE.md

템플릿 예시

markdown

## 작업 내용
<!-- 이 PR에서 무엇을 했는지 간단히 설명해주세요 -->

## 변경 사항
<!-- 구체적인 변경 내용을 나열해주세요 -->
- 
- 

## 테스트 방법
<!-- 리뷰어가 테스트할 수 있는 방법을 설명해주세요 -->
1. 
2. 
3. 

## 스크린샷
<!-- UI 변경이 있다면 Before/After 스크린샷을 첨부해주세요 -->

## 관련 이슈
<!-- 관련된 이슈 번호를 적어주세요 -->
- Closes #
- Related to #

## 체크리스트
- [ ] 코드 리뷰 준비 완료
- [ ] 테스트 완료
- [ ] 문서 업데이트 완료
- [ ] CI/CD 테스트 통과

## 리뷰어에게
<!-- 특별히 확인해주었으면 하는 부분이 있다면 적어주세요 -->

템플릿을 커밋하면 이후 모든 PR 생성 시 자동으로 적용됩니다.

bash

git add .github/PULL_REQUEST_TEMPLATE.md
git commit -m "docs: PR 템플릿 추가"
git push origin main

- Draft PR 활용하기

Draft PR이란?

작업이 완료되지 않았지만 진행 상황을 공유하고 싶을 때 사용합니다.

Draft PR 생성

1. PR 생성 시 "Create pull request" 드롭다운 클릭
2. "Create draft pull request" 선택
3. 작업 완료 후 "Ready for review" 버튼 클릭

Draft PR 활용 시나리오

✅ 이럴 때 사용하세요:
- 작업 방향이 맞는지 미리 확인받고 싶을 때
- CI/CD 테스트를 먼저 돌려보고 싶을 때
- 팀원들에게 진행 상황을 공유하고 싶을 때
- 큰 작업을 진행하며 중간 피드백이 필요할 때

❌ 이럴 때는 피하세요:
- 이미 완성된 코드
- 긴급한 버그 수정

- 실전 예시: PR 전체 플로우

실제 작업 흐름을 처음부터 끝까지 살펴보겠습니다.

시나리오: 회원가입 기능 추가

bash

# 1. 최신 develop 브랜치 업데이트
git checkout develop
git pull origin develop

# 2. 기능 브랜치 생성
git checkout -b feature/user-signup

# 3. 작업 진행
# ... 파일 수정 및 코드 작성 ...

# 4. 커밋
git add .
git commit -m "feat: 회원가입 기능 구현

- 회원가입 폼 UI 추가
- 이메일 중복 체크 API 구현
- 비밀번호 유효성 검사 추가
- 회원가입 성공 시 이메일 발송"

# 5. 원격 푸시
git push origin feature/user-signup

# 6. GitHub에서 PR 생성
# - 제목: feat: 회원가입 기능 구현
# - 설명: 템플릿에 따라 작성
# - 리뷰어: 팀 리더, 백엔드 개발자
# - 레이블: feature, needs review

# 7. 리뷰 받기 및 수정
# ... 리뷰 코멘트에 따라 수정 ...

git add .
git commit -m "review: 비밀번호 정규식 수정"
git push origin feature/user-signup

# 8. 승인 받고 머지
# GitHub에서 "Squash and merge" 선택

# 9. 정리
git checkout develop
git pull origin develop
git branch -d feature/user-signup
git push origin --delete feature/user-signup

- 자주 하는 실수와 해결법

1. Base 브랜치를 잘못 선택함

문제:

main으로 PR을 만들어야 하는데 develop으로 만들었다

해결:

PR 페이지에서 "Edit" 버튼 클릭 → base 브랜치 변경

2. 큰 PR 만들기

문제:

1000줄 변경, 20개 파일 수정
리뷰어가 리뷰하기 어려움

해결:

PR을 여러 개로 분할
- PR 1: 데이터베이스 모델 추가
- PR 2: API 엔드포인트 구현
- PR 3: UI 컴포넌트 추가

3. 커밋 메시지가 엉망

문제:

git commit -m "수정"
git commit -m "ㅇㅇ"
git commit -m "aaa"

해결:

bash

# 커밋 합치고 메시지 수정
git rebase -i HEAD~3
# 에디터에서 squash 선택 및 메시지 수정
git push origin feature-branch --force

4. 충돌(Conflict) 발생

문제:

base 브랜치가 업데이트되어 충돌 발생

해결:

bash

# 방법 1: Merge (권장)
git checkout feature/my-feature
git merge develop
# 충돌 해결 후
git add .
git commit -m "merge: resolve conflicts with develop"
git push origin feature/my-feature

# 방법 2: Rebase (고급)
git checkout feature/my-feature
git rebase develop
# 충돌 해결 후
git add .
git rebase --continue
git push origin feature/my-feature --force

5. PR을 잘못 만들어서 닫음

문제:

실수로 PR을 닫았는데 다시 열고 싶다

해결:

PR 페이지 하단의 "Reopen" 버튼 클릭

- PR 리뷰어를 위한 팁

좋은 코드 리뷰 작성법

1. 구체적으로 작성하기

markdown

❌ 나쁜 예:
"이 부분 고쳐주세요"

✅ 좋은 예:
"이 함수는 200줄이 넘어서 가독성이 떨어집니다.
사용자 검증 로직을 별도 함수로 분리하는 것이 어떨까요?
```javascript
function validateUser(user) {
  // 검증 로직
}
```
"

2. 긍정적인 피드백도 남기기

markdown

  좋은 코드 리뷰:
"에러 핸들링을 꼼꼼하게 처리하셨네요!  "
"이 부분 리팩토링 정말 깔끔합니다!"

3. 질문으로 시작하기

markdown

❌ 명령조:
"이 변수명을 바꾸세요"

✅ 질문형:
"`userInfo` 대신 `userData`가 더 명확할 것 같은데 어떻게 생각하시나요?"

리뷰 우선순위

우선순위항목예시

P0 (Critical)	버그, 보안 이슈	SQL 인젝션 취약점
P1 (Important)	성능 문제, 잘못된 로직	N+1 쿼리 문제
P2 (Normal)	코드 품질, 가독성	변수명, 함수 분리
P3 (Nice to have)	스타일, 취향	코드 포맷팅

마무리

이번 시간에는 Pull Request(PR)와 Merge Request(MR) 작성법에 대해 알아봤습니다. PR은 단순히 코드를 병합하는 도구가 아니라, 팀원들과 소통하고 코드 품질을 높이는 협업의 핵심입니다. 좋은 PR 작성 습관을 들이면 팀 전체의 생산성이 향상됩니다.

다음 시간에는 Git Stash - 임시 저장 활용법에 대해 알아보겠습니다.

[Git] - Clone vs Fork 차이점

RyanSin — Wed, 24 Dec 2025 20:00:09 +0900

개요

안녕하세요. 이번 시간에는 Clone과 Fork의 차이점에 대해 알아보겠습니다. 둘 다 원격 저장소의 코드를 가져오는 방법이지만, 목적과 사용 상황이 다릅니다. 특히 오픈소스 기여를 할 때 Fork를 많이 사용하게 되는데, 정확한 개념을 이해하고 넘어가겠습니다. 혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 학습하고 오시는 걸 추천드리겠습니다.

[Git] - push, pull, fetch 명령어 이해

- Clone vs Fork 한눈에 보기

항목 Clone Fork

정의	저장소를 로컬에 복제	저장소를 내 계정에 복제
위치	로컬 컴퓨터	GitHub (원격)
명령어	git clone	GitHub 웹에서 클릭
원본 연결	origin으로 연결	별도 연결 없음
push 권한	권한 있으면 가능	내 저장소에만 가능
주 사용처	팀 프로젝트, 개인 프로젝트	오픈소스 기여

- Clone이란?

Clone은 원격 저장소를 로컬 컴퓨터에 복제하는 것입니다. 저장소의 모든 파일, 브랜치, 커밋 히스토리가 그대로 복사됩니다.

기본 사용법

# 기본 클론
git clone https://github.com/username/repository.git

# 특정 폴더명으로 클론
git clone https://github.com/username/repository.git my-folder

# 특정 브랜치만 클론
git clone -b develop https://github.com/username/repository.git

# 최신 커밋만 클론 (히스토리 제외, 빠름)
git clone --depth 1 https://github.com/username/repository.git

Clone 후 상태

# 클론 실행
git clone https://github.com/username/my-project.git
cd my-project

# 원격 저장소 확인
git remote -v

# 출력
origin  https://github.com/username/my-project.git (fetch)
origin  https://github.com/username/my-project.git (push)

Clone하면 자동으로 origin이라는 이름으로 원격 저장소가 등록됩니다.

Clone 사용 상황

# 1. 팀 프로젝트 참여
git clone https://github.com/our-team/project.git

# 2. 내 저장소 다른 컴퓨터에서 작업
git clone https://github.com/my-username/my-repo.git

# 3. 오픈소스 코드 살펴보기 (읽기 전용)
git clone https://github.com/facebook/react.git

- Fork란?

Fork는 다른 사람의 저장소를 내 GitHub 계정으로 복제하는 것입니다. 원본 저장소와 별개의 독립적인 저장소가 생성됩니다.

Fork 방법

GitHub에서 원하는 저장소 접속
우측 상단 Fork 버튼 클릭
내 계정 선택
내 계정에 복제된 저장소 생성!

Fork 후 작업 흐름

# 1. Fork한 저장소를 로컬에 클론
git clone https://github.com/MY-USERNAME/forked-repo.git
cd forked-repo

# 2. 원본 저장소를 upstream으로 추가
git remote add upstream https://github.com/ORIGINAL-OWNER/original-repo.git

# 3. 원격 저장소 확인
git remote -v

# 출력
origin    https://github.com/MY-USERNAME/forked-repo.git (fetch)
origin    https://github.com/MY-USERNAME/forked-repo.git (push)
upstream  https://github.com/ORIGINAL-OWNER/original-repo.git (fetch)
upstream  https://github.com/ORIGINAL-OWNER/original-repo.git (push)

Fork 사용 상황

# 1. 오픈소스 기여
# - 원본에 직접 push 권한이 없음
# - Fork 후 내 저장소에서 작업
# - Pull Request로 기여

# 2. 오픈소스 커스터마이징
# - 원본을 기반으로 내 버전 개발
# - 독립적으로 유지보수

# 3. 프로젝트 백업/보존
# - 원본이 삭제되어도 내 Fork는 유지

- 오픈소스 기여 워크플로우

Fork를 활용한 오픈소스 기여 전체 과정입니다.

Step 1: Fork & Clone

# 1. GitHub에서 원본 저장소 Fork (웹에서)

# 2. Fork한 저장소 클론
git clone https://github.com/MY-USERNAME/project.git
cd project

# 3. upstream 설정
git remote add upstream https://github.com/ORIGINAL-OWNER/project.git

Step 2: 브랜치 생성 및 작업

# 1. 최신 상태 동기화
git fetch upstream
git checkout main
git merge upstream/main

# 2. 작업 브랜치 생성
git checkout -b feature/my-contribution

# 3. 코드 수정 및 커밋
# ... 코드 작성 ...
git add .
git commit -m "feat: 새로운 기능 추가"

Step 3: Push & Pull Request

# 1. 내 원격 저장소에 푸시
git push origin feature/my-contribution

# 2. GitHub에서 Pull Request 생성 (웹에서)
# - 원본 저장소의 main ← 내 저장소의 feature/my-contribution

Step 4: 동기화 유지

# PR이 머지된 후, 또는 원본이 업데이트된 경우

# 1. upstream에서 최신 코드 가져오기
git fetch upstream

# 2. main 브랜치 업데이트
git checkout main
git merge upstream/main

# 3. 내 원격 저장소도 업데이트
git push origin main

# 4. 사용 완료된 브랜치 삭제
git branch -d feature/my-contribution
git push origin --delete feature/my-contribution

- Clone만 했을 때 vs Fork 후 Clone

시나리오: React에 기여하고 싶다

Clone만 한 경우:

git clone https://github.com/facebook/react.git
cd react

# 작업 후 push 시도
git push origin main

# 결과: 권한 없음!
ERROR: Permission denied

Fork 후 Clone한 경우:

# 1. Fork (GitHub 웹에서)

# 2. 내 저장소 Clone
git clone https://github.com/MY-USERNAME/react.git
cd react

# 3. 작업 후 push
git push origin my-branch  # 성공!

# 4. Pull Request 생성 (GitHub 웹에서)

- origin과 upstream 이해하기

# origin: 내 원격 저장소 (Fork한 것)
# - push 가능
# - 내가 소유

# upstream: 원본 저장소
# - push 불가능 (권한 없음)
# - 최신 코드 가져오는 용도

자주 사용하는 명령어

# 원본 저장소 최신 코드 가져오기
git fetch upstream
git merge upstream/main

# 또는 한 번에
git pull upstream main

# 내 저장소에 반영
git push origin main

- 실습: 오픈소스 기여 시뮬레이션

실제 오픈소스 기여 과정을 연습해봅시다.

# 1. 연습용 저장소 Fork (GitHub 웹에서)
# https://github.com/octocat/Spoon-Knife

# 2. Fork한 저장소 클론
git clone https://github.com/YOUR-USERNAME/Spoon-Knife.git
cd Spoon-Knife

# 3. upstream 설정
git remote add upstream https://github.com/octocat/Spoon-Knife.git

# 4. 확인
git remote -v

# 5. 브랜치 생성
git checkout -b feature/add-my-name

# 6. 파일 수정
echo "YOUR-NAME was here!" >> contributors.md

# 7. 커밋
git add .
git commit -m "docs: Add my name to contributors"

# 8. 푸시
git push origin feature/add-my-name

# 9. GitHub에서 Pull Request 생성 (웹에서)

- 자주 하는 실수

실수 1: upstream 설정 안 함

# 문제: 원본 저장소 변경사항을 못 가져옴

# 해결
git remote add upstream https://github.com/ORIGINAL/repo.git
git fetch upstream
git merge upstream/main

실수 2: Fork 안 하고 Clone만 함

# 문제: push 권한 없음

# 해결
# 1. GitHub에서 Fork
# 2. 원격 저장소 URL 변경
git remote set-url origin https://github.com/MY-USERNAME/repo.git

실수 3: main 브랜치에서 직접 작업

# 문제: PR 관리가 어려움

# 권장: 항상 새 브랜치에서 작업
git checkout -b feature/my-work
# 작업...
git push origin feature/my-work
# PR 생성

- 명령어 정리

# Clone
git clone <URL>                    # 기본 클론
git clone <URL> <folder>           # 폴더명 지정
git clone -b <branch> <URL>        # 특정 브랜치
git clone --depth 1 <URL>          # 최신 커밋만

# Fork 후 설정
git remote add upstream <원본URL>  # upstream 추가
git remote -v                      # 확인

# 원본 동기화
git fetch upstream                 # 가져오기
git merge upstream/main            # 병합
git push origin main               # 내 저장소 반영

# 브랜치 작업
git checkout -b feature/name       # 브랜치 생성
git push origin feature/name       # 푸시
# GitHub에서 PR 생성

마무리

이번 시간에는 Clone과 Fork의 차이점에 대해 알아봤습니다. Clone은 저장소를 로컬에 복제하는 것이고, Fork는 저장소를 내 GitHub 계정에 복제하는 것입니다. 오픈소스에 기여할 때는 Fork → Clone → 작업 → Push → PR 순서로 진행합니다. upstream 설정을 잊지 말고 원본 저장소와 동기화를 유지하는 것이 중요합니다.

다음 시간에는 Pull Request(PR) / Merge Request(MR) 작성법에 대해 알아보겠습니다.

참고 자료

[Git] - push, pull, fetch 명령어 이해

RyanSin — Tue, 23 Dec 2025 20:00:52 +0900

개요

안녕하세요. 이번 시간에는 Git의 push, pull, fetch 명령어에 대해 알아보겠습니다. 원격 저장소와 로컬 저장소 간에 코드를 주고받는 핵심 명령어들입니다. 각 명령어의 차이점과 사용법을 실습과 함께 살펴보겠습니다. 혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 학습하고 오시는 걸 추천드리겠습니다.

[Git] - 충돌(Conflict) 해결 방법

- push, pull, fetch 개념

세 명령어는 로컬과 원격 저장소 간의 동기화를 담당합니다.

명령어 방향 설명

push	로컬 → 원격	내 커밋을 원격에 업로드
fetch	원격 → 로컬	원격 변경사항 가져오기 (병합 X)
pull	원격 → 로컬	fetch + merge (가져오고 병합)

- git push

git push는 로컬 저장소의 커밋을 원격 저장소에 업로드합니다.

기본 사용법

# 기본 형식
git push <원격저장소> <브랜치>

# 예시: origin의 main 브랜치에 푸시
git push origin main

첫 번째 푸시 (-u 옵션)

# upstream 설정과 함께 푸시
git push -u origin main

# 이후부터는 간단하게
git push

-u (또는 --set-upstream) 옵션은 로컬 브랜치와 원격 브랜치를 연결합니다. 한 번 설정하면 이후 git push만 입력해도 됩니다.

다양한 push 옵션

# 기본 푸시
git push origin main

# 모든 브랜치 푸시
git push origin --all

# 태그 푸시
git push origin --tags

# 특정 태그 푸시
git push origin v1.0.0

# 강제 푸시 (주의!)
git push -f origin main
git push --force origin main

# 더 안전한 강제 푸시
git push --force-with-lease origin main

새 브랜치 푸시

# 로컬에서 브랜치 생성
git switch -c feature/login

# 작업 후 커밋
git add .
git commit -m "feat: 로그인 기능"

# 원격에 새 브랜치 푸시
git push -u origin feature/login

push 거부 상황

- git fetch

git fetch는 원격 저장소의 변경사항을 로컬로 가져오지만, 현재 작업 중인 브랜치에 병합하지 않습니다.

기본 사용법

# 기본 형식
git fetch <원격저장소>

# origin의 모든 브랜치 가져오기
git fetch origin

# 특정 브랜치만 가져오기
git fetch origin main

fetch 후 상태 확인

# fetch 실행
git fetch origin

# 출력 예시
remote: Counting objects: 3, done.
From https://github.com/username/repo
   a1b2c3d..d4e5f6g  main -> origin/main

# 로컬과 원격 차이 확인
git log main..origin/main --oneline

# 변경 내용 확인
git diff main origin/main

fetch vs pull 차이

fetch 활용 예시

# 1. 원격 변경사항 확인하고 싶을 때
git fetch origin
git log HEAD..origin/main --oneline
# 3개의 새 커밋 확인

# 2. 확인 후 병합 결정
git merge origin/main

# 또는 rebase
git rebase origin/main

- git pull

git pull은 fetch + merge를 한 번에 실행합니다. 원격의 변경사항을 가져와서 현재 브랜치에 병합합니다.

기본 사용법

# 기본 형식
git pull <원격저장소> <브랜치>

# origin의 main 브랜치 풀
git pull origin main

# upstream 설정된 경우
git pull

pull 옵션

# 기본 pull (merge 방식)
git pull origin main

# rebase 방식으로 pull
git pull --rebase origin main

# 충돌 시 자동 병합 전략
git pull --strategy-option theirs origin main  # 원격 우선
git pull --strategy-option ours origin main    # 로컬 우선

pull --rebase

일반 pull은 병합 커밋을 생성하지만, --rebase는 선형 히스토리를 유지합니다.

# 일반 pull
git pull origin main
# 결과: 병합 커밋 생성

# rebase pull
git pull --rebase origin main
# 결과: 내 커밋이 원격 커밋 위로 이동

# 기본값으로 설정
git config --global pull.rebase true

일반 pull 결과:

*   Merge branch 'main' of origin
|\
| * 원격 커밋 B
| * 원격 커밋 A
* | 내 커밋 2
* | 내 커밋 1
|/
* 공통 조상

pull --rebase 결과:

* 내 커밋 2 (재생성)
* 내 커밋 1 (재생성)
* 원격 커밋 B
* 원격 커밋 A
* 공통 조상

pull 충돌 해결

# pull 시 충돌 발생
git pull origin main
# CONFLICT (content): Merge conflict in file.js

# 충돌 해결
# 1. 파일 수정
# 2. 스테이징
git add file.js

# 3. 커밋 (일반 pull)
git commit -m "merge: 충돌 해결"

# 3. 또는 rebase 계속 (--rebase 사용 시)
git rebase --continue

- 실전 워크플로우

일반적인 작업 흐름

# 1. 작업 시작 전 최신 코드 가져오기
git pull origin main

# 2. 브랜치 생성
git switch -c feature/new-feature

# 3. 작업 및 커밋
git add .
git commit -m "feat: 새 기능 추가"

# 4. 원격에 브랜치 푸시
git push -u origin feature/new-feature

# 5. (GitHub에서 PR 생성)

# 6. PR 병합 후 로컬 정리
git switch main
git pull origin main
git branch -d feature/new-feature

협업 시 동기화

# 팀원의 변경사항 확인
git fetch origin

# 변경사항 있는지 확인
git status
# Your branch is behind 'origin/main' by 3 commits

# 병합
git pull origin main

# 또는 rebase로 병합
git pull --rebase origin main

# 내 작업 푸시
git push origin main

장기 브랜치 동기화

# feature 브랜치에서 작업 중
git switch feature/long-task

# main의 최신 변경사항 가져오기
git fetch origin main

# 내 브랜치에 반영 (rebase 권장)
git rebase origin/main

# 또는 merge
git merge origin/main

# 충돌 해결 후 계속 작업

- 자주 발생하는 문제

문제 1: push 거부됨

# 오류
! [rejected] main -> main (non-fast-forward)

# 해결
git pull origin main  # 먼저 pull
git push origin main  # 다시 push

문제 2: pull 시 uncommitted changes 오류

# 오류
error: Your local changes would be overwritten by merge

# 해결 방법 1: 커밋하기
git add .
git commit -m "WIP: 작업 중"
git pull origin main

# 해결 방법 2: stash 사용
git stash
git pull origin main
git stash pop

문제 3: fetch 했는데 브랜치가 안보임

# 원격 브랜치 목록 확인
git branch -r

# 원격 브랜치 로컬에 체크아웃
git switch -c feature/login origin/feature/login

# 또는
git checkout --track origin/feature/login

문제 4: 강제 푸시 후 팀원 문제

# 내가 강제 푸시한 경우, 팀원은:
git fetch origin
git reset --hard origin/main

# 주의: 팀원의 로컬 변경사항이 사라짐!

- 명령어 비교 정리

# PUSH: 로컬 → 원격
git push origin main           # 기본
git push -u origin main        # upstream 설정
git push --force origin main   # 강제 (주의!)
git push origin --all          # 모든 브랜치
git push origin --tags         # 모든 태그

# FETCH: 원격 → 로컬 (병합 X)
git fetch origin               # 모든 브랜치
git fetch origin main          # 특정 브랜치
git fetch --all                # 모든 원격 저장소

# PULL: 원격 → 로컬 (fetch + merge)
git pull origin main           # 기본 (merge)
git pull --rebase origin main  # rebase 방식
git pull                       # upstream 설정된 경우

- 언제 무엇을 사용할까?

상황 명령어

내 작업을 공유하고 싶을 때	git push
원격 변경사항을 확인만 하고 싶을 때	git fetch
원격 변경사항을 바로 적용하고 싶을 때	git pull
히스토리를 깔끔하게 유지하고 싶을 때	git pull --rebase
PR 전 최신 상태 동기화	git fetch + git rebase

마무리

이번 시간에는 push, pull, fetch 명령어에 대해 알아봤습니다. 세 명령어는 원격 저장소와 협업할 때 필수적으로 사용됩니다. fetch는 안전하게 확인만, pull은 바로 병합, push는 내 작업을 업로드한다고 기억하시면 됩니다. 특히 pull --rebase는 깔끔한 히스토리 관리에 유용하니 활용해보세요.

다음 시간에는 Clone vs Fork 차이점에 대해 알아보겠습니다.

참고 자료

[Git] - 충돌(Conflict) 해결 방법

RyanSin — Mon, 22 Dec 2025 20:00:18 +0900

개요

안녕하세요. 이번 시간에는 Git 충돌(Conflict) 해결 방법에 대해 알아보겠습니다. 여러 사람이 협업하다 보면 같은 파일의 같은 부분을 수정하는 경우가 발생합니다. 이때 Git은 자동으로 병합하지 못하고 충돌이 발생하게 됩니다. 충돌을 두려워하지 말고, 해결 방법을 익혀두면 자신있게 대처할 수 있습니다. 혹시 이전 시간에 내용을 학습하고 오시지 못 하신 분들은 학습하고 오시는 걸 추천드리겠습니다.

[Git] - Rebase vs Merge 차이점

- 충돌이란?

충돌(Conflict)은 Git이 자동으로 병합할 수 없는 상황을 말합니다. 두 브랜치에서 같은 파일의 같은 라인을 다르게 수정했을 때 발생합니다.

충돌이 발생하는 상황

main 브랜치:
파일: greeting.js
내용: console.log("Hello");  →  console.log("Hello World");

feature 브랜치:
파일: greeting.js
내용: console.log("Hello");  →  console.log("Hello Git");

병합 시도 시:
Git: "둘 중 어떤 것을 선택해야 할지 모르겠어요!" → 충돌 발생!

충돌이 발생하지 않는 경우

# 다른 파일 수정 → 충돌 없음
main:    file1.js 수정
feature: file2.js 수정

# 같은 파일, 다른 라인 수정 → 충돌 없음
main:    file.js 1번째 줄 수정
feature: file.js 10번째 줄 수정

# 같은 파일, 같은 라인 수정 → 충돌 발생!
main:    file.js 5번째 줄 수정
feature: file.js 5번째 줄 수정

- 충돌 발생시키기 (실습)

충돌 상황을 직접 만들어보겠습니다.

# 1. 프로젝트 초기화
mkdir conflict-practice
cd conflict-practice
git init

# 2. 초기 파일 생성
cat << 'EOF' > greeting.js
function greet() {
    console.log("Hello");
}
EOF

git add .
git commit -m "init: 인사 함수 추가"

# 3. feature 브랜치 생성 및 수정
git switch -c feature/update-greeting

cat << 'EOF' > greeting.js
function greet() {
    console.log("Hello Git");
}
EOF

git add .
git commit -m "feat: 인사말을 Hello Git으로 변경"

# 4. main 브랜치에서 같은 부분 수정
git switch main

cat << 'EOF' > greeting.js
function greet() {
    console.log("Hello World");
}
EOF

git add .
git commit -m "feat: 인사말을 Hello World로 변경"

# 5. 병합 시도 → 충돌 발생!
git merge feature/update-greeting

# 출력
Auto-merging greeting.js
CONFLICT (content): Merge conflict in greeting.js
Automatic merge failed; fix conflicts and then commit the result.

- 충돌 파일 구조 이해하기

충돌이 발생한 파일을 열어보면 다음과 같은 구조를 볼 수 있습니다.

function greet() {
<<<<<<< HEAD
    console.log("Hello World");
=======
    console.log("Hello Git");
>>>>>>> feature/update-greeting
}

충돌 마커 설명

마커 설명

<<<<<<< HEAD	현재 브랜치(HEAD)의 내용 시작
=======	구분선
>>>>>>> branch-name	병합하려는 브랜치의 내용 끝

<<<<<<< HEAD
현재 브랜치(main)의 코드
=======
병합하려는 브랜치(feature)의 코드
>>>>>>> feature/update-greeting

- 충돌 해결 방법

방법 1: 수동으로 해결

가장 기본적인 방법으로, 직접 파일을 편집합니다.

# 1. 충돌 파일 확인
git status

# 출력
On branch main
You have unmerged paths.
  (fix conflicts and run "git commit")

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   greeting.js

# 2. 파일 열어서 수정
code greeting.js  # 또는 vim, nano 등

수정 전:

function greet() {
<<<<<<< HEAD
    console.log("Hello World");
=======
    console.log("Hello Git");
>>>>>>> feature/update-greeting
}

수정 후 (원하는 내용으로 선택/수정):

function greet() {
    console.log("Hello World and Git");
}

# 3. 수정 완료 후 스테이징
git add greeting.js

# 4. 커밋
git commit -m "merge: feature/update-greeting 병합 및 충돌 해결"

방법 2: 특정 브랜치 내용 선택

한쪽 브랜치의 내용을 전체 선택할 수 있습니다.

# 현재 브랜치(main)의 내용 선택
git checkout --ours greeting.js

# 병합 브랜치(feature)의 내용 선택
git checkout --theirs greeting.js

# 스테이징 및 커밋
git add greeting.js
git commit -m "merge: feature 브랜치 내용으로 충돌 해결"

방법 3: VS Code로 해결

VS Code는 충돌 해결을 위한 편리한 UI를 제공합니다.

# VS Code로 파일 열기
code greeting.js

VS Code에서 충돌 부분에 다음 버튼이 표시됩니다:

Accept Current Change: 현재 브랜치(HEAD) 선택
Accept Incoming Change: 병합 브랜치 선택
Accept Both Changes: 둘 다 포함
Compare Changes: 변경 사항 비교

방법 4: Git Mergetool 사용

Git에 설정된 병합 도구를 사용합니다.

# mergetool 실행
git mergetool

# 도구 설정 (VS Code)
git config --global merge.tool vscode
git config --global mergetool.vscode.cmd 'code --wait $MERGED'

# 도구 설정 (IntelliJ)
git config --global merge.tool intellij
git config --global mergetool.intellij.cmd 'idea merge $LOCAL $REMOTE $BASE $MERGED'

- 충돌 해결 실습

전체 과정을 다시 실습해보겠습니다.

# 1. 충돌 상태 확인
git status

# 2. 충돌 파일 목록만 확인
git diff --name-only --diff-filter=U

# 3. 충돌 내용 확인
git diff

# 4. 파일 수정 (에디터로)
# greeting.js 파일에서 충돌 마커 제거하고 원하는 내용 작성

# 5. 수정 완료 확인
cat greeting.js
# function greet() {
#     console.log("Hello World and Git");
# }

# 6. 스테이징
git add greeting.js

# 7. 상태 확인
git status
# All conflicts fixed but you are still merging.

# 8. 커밋
git commit -m "merge: greeting 충돌 해결"

# 9. 로그 확인
git log --oneline --graph
# *   a1b2c3d (HEAD -> main) merge: greeting 충돌 해결
# |\
# | * b2c3d4e (feature/update-greeting) feat: 인사말을 Hello Git으로 변경
# * | c3d4e5f feat: 인사말을 Hello World로 변경
# |/
# * d4e5f6g init: 인사 함수 추가

- 병합 취소하기

충돌 해결이 복잡하거나 잘못되었을 때 병합을 취소할 수 있습니다.

병합 중 취소 (커밋 전)

# 병합 취소하고 이전 상태로
git merge --abort

병합 후 취소 (커밋 후)

# 방법 1: reset으로 완전히 되돌리기
git reset --hard HEAD~1

# 방법 2: revert로 되돌리기 (이력 유지)
git revert -m 1 HEAD

- Rebase 중 충돌 해결

Rebase 중 충돌이 발생하면 각 커밋마다 해결해야 합니다.

# 1. Rebase 시작
git switch feature/login
git rebase main

# 충돌 발생!
# CONFLICT (content): Merge conflict in file.js

# 2. 충돌 해결
# 파일 수정...
git add file.js

# 3. Rebase 계속
git rebase --continue

# 4. 다음 커밋에서 또 충돌 발생 시 2-3 반복

# Rebase 전체 취소
git rebase --abort

# 현재 커밋 건너뛰기
git rebase --skip

Merge vs Rebase 충돌 해결 비교

항목 Merge Rebase

충돌 해결 횟수	1회	커밋 개수만큼
취소 명령어	git merge --abort	git rebase --abort
계속 명령어	git commit	git rebase --continue

- 충돌 예방하기

충돌을 완전히 피할 수는 없지만, 줄일 수 있습니다.

1. 자주 동기화하기

# main 브랜치 변경사항을 자주 가져오기
git switch feature/my-feature
git merge main  # 또는 git rebase main

2. 작은 단위로 작업하기

# ❌ 나쁜 예: 일주일 동안 큰 기능 개발 후 병합
# ✅ 좋은 예: 작은 단위로 자주 병합

3. 팀과 소통하기

# 같은 파일을 수정할 예정이라면 미리 공유
# 코드 리뷰를 통해 충돌 가능성 파악

4. 파일 분리하기

# ❌ 하나의 큰 파일에 모든 기능
# ✅ 기능별로 파일 분리

- 복잡한 충돌 해결 팁

충돌 파일이 많을 때

# 충돌 파일 목록 확인
git diff --name-only --diff-filter=U

# 하나씩 해결
git add file1.js
git add file2.js
# ...

# 모든 충돌 해결 후 커밋
git commit

특정 파일을 한쪽으로 통일

# 모든 충돌을 현재 브랜치로
git checkout --ours .

# 모든 충돌을 병합 브랜치로
git checkout --theirs .

# 주의: 신중하게 사용!

충돌 히스토리 확인

# 충돌 원인이 된 커밋 확인
git log --merge

# 파일별 수정 이력 확인
git log -p -- greeting.js

- 충돌 해결 명령어 정리

# 충돌 상태 확인
git status
git diff --name-only --diff-filter=U

# 충돌 내용 확인
git diff

# 충돌 해결 후
git add 파일명
git commit

# 특정 브랜치 선택
git checkout --ours 파일명    # 현재 브랜치
git checkout --theirs 파일명  # 병합 브랜치

# 병합 취소
git merge --abort      # Merge 중
git rebase --abort     # Rebase 중

# Rebase 계속
git rebase --continue
git rebase --skip

# 도구 사용
git mergetool

마무리

이번 시간에는 Git 충돌(Conflict) 해결 방법에 대해 알아봤습니다. 충돌은 협업에서 자연스럽게 발생하는 현상이니 두려워하지 마세요. 충돌 마커를 이해하고, 원하는 내용으로 수정한 뒤 커밋하면 됩니다. 자주 동기화하고 작은 단위로 작업하면 충돌을 줄일 수 있습니다.

다음 시간에는 원격 저장소(Remote) 연결 방법에 대해 알아보겠습니다.

참고 자료

Git 공식 문서 - Basic Merge Conflicts