docker와 k8s

개요 백엔드 시스템을 gRPC 기반의 MSA로 구성을 완료하고, 각 코드 베이스가 분리되었으므로 이를 관리하기 위한 수단으로 docker-compose와 k8s 둘을 비교하고 선택하기 위한 인사이트를 공부한 포스트이다. Docker Docker란? 운영체제는 하드웨어를 직접적으로 다루는 커널과, 그 외의 부분으로 구성되어있다. 일반적인 소프트웨어는 이러한 운영체제를 통해 간접적으로 하드웨어를 동작하게 만들 수 있는데, 도커 엔진은 이러한 운영체제 그 중에서도 Linux 운영체제를 기반으로 동작한다. Linux 운영체제의 커널 외의 부분을 컨테이너 안에 같이 구성하고, 도커 엔진이 Linux 커널과 컨테이너를 연결해준다. 이렇듯 운영체제 전체를 가상화하는 VirtualBox 등과 다르게 커널 외의 부분만 컨테이너 안에 넣어 같은 컴퓨터 안의 독립된 격리환경을 만들기에 상대적으로 가볍다. 또한 Linux 운영체제를 기반으로 환경을 구성하기에 윈도우 등에서 도커를 사용할 때 wsl이나 Hyper-V 등이 설치되야 하는 것이다. Docker의 구성 Docker Image와 Container 도커는 기본적으로 이미지라는 읽기 전용 파일을 통해 컨테이너를 생성한다. 그렇다면 이 이미지라는 것이 정확히 어떤 역할을 수행해주는 것일까? 우리가 DockerFile 등의 Build를 정의하는 파일들을 보면 RUN, FROM, COPY, ADD 등 다양한 명령들로 어떤 파일을 복사해올지, 어떤 걸 설치할지 등을 정의할 수 있다. 이러한 명령이 하나 실행될 때마다 도커는 Layer라는 각 명령이 실행된 후의 파일 시스템의 스냅샷을 저장한다. 이렇게 명령어 별로 스냅샷인 Layer를 기록하기에 같은 명령어 구조를 공유하는 이미지가 많으면 이미지를 저장하는 용량을 줄일 수 있는 소소한 팁이 있다. 도커 이미지에서 RUN 명령에 pip를 엄청 뭉쳐서 실행하는 경우가 있는데, RUN을 각각 따로 실행해버리면 Layer 저장량이 많아지기에 한꺼번에 설치를 해버리는 것이다. 즉 중복된 Layer의 용량을 절약할 수 있는 점과, Layer가 많아지면 저장공간이 더 필요한 점을 각각 따져서 도커파일을 구성하는 것이 좋다. 즉 이런 구성으로 컨테이너 : 우리가 실제 도커를 실행하는 시스템 이 시작되는 시점의 스냅샷이 이미지의 역할이다. 그런데 이러한 Layer는 이미지에만 존재하지 않는다. 우리가 실제 격리된 환경을 구현하는 Container에서 Layer가 존재한다. 물론 차이는 존재한다. Docker Image의 Layer는 읽기전용으로 한번 빌드가 완료된 후 수정되지 않는다. 하지만 Container별로 존재하는 Layer는 writable Layer를 각각 갖는다. 스냅샷 이후의 수정사항을 새로운 Layer로 저장하는 것이다. 여기서 어떤 강점이 보일까? 사전에 파일을 복사하고, 다른 프로그램을 설치하고 빌드라는 과정의 결과인 스냅샷을 복사할 필요 없이 모든 컨테이너가 하나의 이미지로 공유가 가능한 점이다. Pytorch 등 무거운 라이브러리를 사용하면 이미지의 용량이 10GB가 넘어가기도 하는데, 이런 이미지를 사용하는 컨테이너를 n개 띄워도 하나의 이미지로 공유하여 사용이 가능한 것이다. 우리가 흔히 이미지를 틀러 컨테이너를 찍어낸다라는 비유가 있는데, 사전에 공유되는 스냅샷을 만드는 과정과 저장한 결과를 모두 컨테이너가 공유하여 자기 자신들의 수정사항을 반영하는 Writiable Layer로 가볍게 찍어낼 수 있기 때문에 이러한 비유가 있는 것이다. 이러한 기능을 구현하는 근간은 Linux의 UnionFS(Union File System)이다. 또한 도커는 만들어진 container를 기반으로 이미지를, 이미지를 컨테이너로, 컨테이너 재실행, 허브에 올리기 등 이미지와 컨테이너를 기반으로 다양한 명령을 가지는데 구조는 아래와 같다. 다만 도커 허브로 이미지를 가져올 때, 베이스 이미지의 코드를 수정하여 공격하는 기법도 존재하므로, 항상 베이스 이미지를 신뢰할 수 있는 사용자에 이미지를 사용하도록 하자. Docker-Compose 도커 컨테이너를 생성할 때, 볼륨, 네트워크, 호스트 자원할당, 환경변수 설정 등 다양한 설정을 하나의 컨테이너를 생성하고 실행할 때 사용할 수 있다. 이러한 컨테이너를 일일히 명령어로 적는 것은 힘들기 때문에 이를 한꺼번에 yaml 파일로 정리해서 실행할 수 있게 만든 것이 docker compose 이다. Docker-Compose 기능을 활용하여 얻을 수 있는 이점은 아래와 같다. 컨테이너 단위로 실행하는 것이 아닌, 여러 개의 컨테이너가 모인 Application 단위로 정의 및 관리가 가능하다. 서비스간 자동으로 네트워크를 연결해주고, 서비스를 실행할 때 depends_on 옵션으로 실행 순서(의존관계)의 정의도 가능하다. docker-compose.dev , docker-compose.prod 등으로 설정파일을 여러개를 만들어 실행 가능하다. 동일한 서비스의 컨테이너를 여러 개 띄울 수 있다. Compose의 설정 파일 정리 주 항목 명령어 이름 설명 services 컨테이너를 정의한다 networks 도커 네트워크를 정의한다 volumes 볼륨을 정의한다 secrets 각 비밀이 보장되어야하는 정보들이 기록된 파일을 이름을 붙여서 저장할 수 있게 한다 서비스 정의 항목 명령어 이름 설명 구체적인 옵션 CLI 대체 여부(docker run 기준) image 해당 서비스가 어떠한 이미지를 사용할지를 결정 이미지 이름:이미지 버전 CLI에 고정으로 사용 networks 해당 서비스가 어떠한 도커 네트워크에 속할지를 결정 x –net build 해당 서비스가 어떠한 Dockerfile을 빌드하여 사용할지를 결정 context : 해당 도커 빌드 시작 폴더 위치를 지정, dockerfile : 어떤 도커파일로 빌드할지를 결정 x volumes 스토리지 마운트를 결정 여러개 지정 가능 -v, –mount ports 호스트와 연결될 포트를 지정 호스트 포트번호:컨테이너 포트번호 -p environment 환경변수 설정 여러개 지정 가능 -e depends on 다른 서비스에 대한 의존 관계 설정(먼저 실행되야 하는 서비스) 여러개 지정 가능 없음 restart 컨테이너 종료 시 재시작 여부를 설정 1. no (재시작 x) 2.always (항상 재시작) 3. on-failure (프로세스가 0 외의 상태로 종료될 시 재시작) 4. unless-stopped (종료시 재시작 x, 그 외엔 재시작) 없음 command 커맨드 시작 시 기존 커맨드를 오버라이드 실행될 명령 CLI에 고정으로 사용 container_name 실행될 컨테이너의 이름을 지정 x –name dns DNS 서버를 명시적으로 지정 x –dns env_file 환경설정 정보를 기재한 파일을 로드 x 없음 entrypoint 컨테이너 시작 시 ENTRYPOINT 설정을 오버라이드 x –entrypoint links 네트워크 없이 컨테이너를 다른 컨테이너와 연결되어 사용하게 해줌, etc/hosts/ 에서 각 컨테이너의 ip를 확인 가능 여러개 지정 가능 x external_links 컴포즈 외부의 컨테이너와 연결되어 사용하게 해줌 여러개 지정 가능 –link extra_hosts 컨테이너 내의 /etc/hosts/에 외부 호스트 정보를 추가, DNS를 지정할 때, 특정 IP를 도메인으로 매핑할 떄 사용 “host.docker.internal:host-gateway” 를 지정해야 외부 DNS 서버를 통해 통신 가능하다, 여러개 지정 가능 –add-host secret 사전에 구성된 secret에 서비스가 접근하도록 한다, /run/secrets 디렉토리에서 secret 이름으로 접근 여러개 지정 가능 x logging 컨테이너의 로그가 어떻게 저장될지 옵션을 설정한다 1. json-file : 컨테이너 내부에서 자체적으로 저장 2. syslog : 각 서비스의 로그를 통합해서 관리하는 서버로 전송 3. none : 로그 저장 안함 x kubernates k8s란? 쿠버네티스란 오케스트레이션 도구의 일종으로, 오케스트레이션 도구는 여러 개의 호스트를 가지는 서버를 관리할 떄 쓰이는 도구이다. Docker compose와 같은 도구는 여러개의 컨테이너를 한꺼번에 띄울 수는 있지만, 만약 물리적인 서버가 여러대라면 이 작업을 반복해서 수행하고, 여러개의 물리적 서버를 통합 관리할 수는 없다. 이러한 상황에 도움을 주는 도구가 쿠버네티스와 같은 오케스트레이션 도구이다. k8s의 구성 1. 노드 마스터 노드 : 컨테이너를 직접 실행시키진 않지만 각 워커 노드를 관리하여 이상적인 상태(컨테이너 개수, 볼륨 개수)를 유지하도록 관리하는 주체 워커 노드 : 실제 컨테이너가 실행되는 주체, 도커 등의 엔진 프로그램이 필요하다. 2. 관리 단위 포드(pod) : 컨테이너 하나 혹은 여러 개로 이루어진 같은 로컬 네트워크 ip, 포트 번호, 생명주기를 공유하는 쿠버네티스의 최소 관리 단위이다. docker compose 등을 보면 컨테이너끼리 link 등을 통해 묶여있는데 실제로 어플리케이션에서는 하나의 컨테이너만 사용되는게 아닌, 여러개의 컨테이너가 모여 하나의 서비스를 구성한다. nginx, 로깅, metric 컨테이너 등은 실제 핵심 로직 컨테이너와 함께 움직인다. 이러한 밀접하게 연결된 컨테이너들을 하나의 관리 대상으로 만들어 줄 수 있는게 pod라는 단위이다. 서비스(service) : 같은 구성을 가지는 pod들을 여러개 모은 단위를 서비스라고 한다. 여러 개의 pod가 여러 개의 워커 노드(물리적 서버)에 존재하더라도 한꺼번에 관리해주는 단위이다. 서비스는 고정적인 ip 주소(cluster ip)를 부여받으며 같은 구성의 pod에 로드밸런서 역할을 수행해준다. 하지만 서비스가 분배하는 통신은 한 워커 노드 안으로 국한되며, 워커 노드간의 분배는 실제 로드밸런서 혹은 인그레스(ingress)가 담당한다. 이들은 마스터 노드도 워커 노드도 아닌 별도의 노드에서 동작한다. 디플로이먼트(deployment)와 레플리카세트(replicaset) : pod의 수를 관리하는 주체이다. 정의파일에 의해 정의된 pod의 수에 따라 실제 pod의 수를 줄이고 늘린다. 이런 ReplicaSet의 관리하는 동일한 구성의 pod를 Replica라고 부른다. Deployment는 Pod의 Deploy를 관리하는 요소로, Pod가 사용하는 이미지 등의 정보를 가지고 있다. ReplicaSet은 이러한 Deployment와 함께 사용된다. 결론 쿠버네티스같은 오케스트레이션 시스템은 기본적으로 서버가 여러개가 필요할 정도로 대규모 트래픽이 필요한 서비스에서 제 역할을 할 수 있는 시스템이다. 현재 우리의 백엔드 서버는 하나의 물리적 서버를 가지고 있으며, MSA로 나눠진 AI 컨테이너 등의 로깅 수집, 자동 재시작 등의 필요한 기능은 Docker Compose 내부의 설정만으로도 어느정도 대체가 가능하기에, 현재 시스템에는 k8s 채택을 미루기로 결정하였다. 참고자료 1. 도커 컴포즈 정리 블로그 글 2. 그림과 실습으로 배우는 도커와 쿠버네티스 3. 도커 secret에 대해 4. 도커 logging 옵션에 대하여 5. 도커 syslog 서버 구축

tech-review · 2025-10-13

nginx의 개요

개요 프론트 엔드 뷰어와, 백엔드 서버를 결합하는 작업을 수행하면서 CORS 오류로 인한 통신후 Body를 못보는 문제, 분명히 통신과 쿠키는 생성되었는데 쿠키를 읽어드리지 못하는 문제 등, 통신 자체는 성공했는데 웹의 자체적인 보안 및 시스템으로 인해 버그가 자주 발생하였다. 웹에 대한 지식이 없이 이런 버그를 고치는 것은 시행착오가 많을 것 같아, cs-note 섹션에 해당 정보들을 정리하려 한다. 웹에 대하여 초창기 웹은 단순히 URI(Uniform Resource Identifier) 을 통해 클라이언트에 리소스를 보내주고, HTML로 규정된 문서 규칙을 통해 문서끼리, 다른 문서를 쉽게 링크를 통해 가져올 수 있는 구조였다. 하지만 웹서버가 발전하며, 웹 서버는 기존의 서버에서, 클라이언트로 HTML 문서를 보내주는 것을 넘어서, 동적으로 움직이고 디자인이 가능한 문서의 송수신, 자원의 송수신을 넘어선 로직의 실행, 클라이언트와 서버 간의 상태의 저장 등 더욱 다양한 역할을 수행해주게 발전되었다. 해당 문서는 이러한 웹에 발전에 따라, 웹에서 구동되는 제품이 구현되기 위한 백엔드의 구성 요소와 도움이 되는 방법론 등을 정리하는 문서이다. 어떻게 통신할 것인가? TODO Resource의 송수신 초창기 웹의 주요 역할은 서버에 저장된 리소스(HTML 문서, 이미지·동영상·오디오 같은 미디어 파일, 데이터 파일 등)를 URI를 통해 탐색하고, 이를 클라이언트로 전달하는 것이었다. 이후 웹은 단순한 파일 전송과 링크 연결을 넘어, HTML로 문서를 표현하고, CSS로 시각적 디자인을 더하며, JavaScript로 동적 기능을 구현하는 방향으로 발전하였다. 최근에는 단순한 정적 파일 전송을 넘어, XML·JSON과 같은 데이터 포맷을 송수신하여 브라우저가 직접 HTML을 생성하거나 동적 데이터 처리를 수행한다. 이러한 내용을 정리해보자. 정적 리소스 HTML (문서 구조) 하이퍼링크(URI 기반 파일 연결) 이미지·미디어 파일 전송 문서의 표현력 강화 & 동적 요소 CSS (스타일·디자인) JavaScript (동적 상호작용) 현대 웹 (데이터 송수신 중심) XML, JSON (데이터 교환 포맷) AJAX (비동기 데이터 요청) TODO 표준화된 데이터 송수신 방식 웹이 단순한 문서 전송을 넘어 다양한 데이터 교환을 필요로 하게 되면서, 서버와 클라이언트 간의 데이터 송수신을 표준화하는 프로토콜이 등장하였다. 이러한 프로토콜은 웹 서비스가 확장될수록 일관성 있는 데이터 접근과 통신 효율성을 보장하는 핵심 역할을 한다. 다룰 내용 예시 : RestAPI, GraphQL, gRPC 클라이언트와 서버의 상태관리 웹이 발전하면서 로그인, 장바구니 같은 기능을 제공하기 위해 서버와 클라이언트는 서로의 상태를 유지할 필요가 생겼다. 이를 위해 상태 관리와 인증 방식이 사용되며, 만약 인증 정보가 유출되면 다른 사용자가 이를 도용해 사칭할 수 있다. 따라서 안전한 인증과 보안 기능이 필수적이다. 인증(Authentication) 대표 기술 세션(Session) + 쿠키(Cookie) 토큰 기반 인증(JWT, OAuth2) 다중 인증(MFA, OTP) 보안(Security) 대표 기술 HTTPS/TLS(데이터 암호화 전송) CSRF/XSS 방어 기법 세션 하이재킹 방지(만료시간, HttpOnly, Secure 옵션 등) 어떻게 배포환경을 파악할 것인가? 어떻게 WAS를 관리할 것인가? 데이터베이스 최적화 ## 참고자료 용어설명 URI URI(Uniform Resource Identifier)란 인터넷에 있는 자원을 어디에 있는지 자원 자체를 식별하는 방법이다. 우리가 어떠한 자원을 식별할 때는 그 자원이 어디에 있는가? 혹은 그 자원을 뭐라고 하는가? 2가지 방법을 통해 식별을 할 수 있다. 이들이 각각 URL(Uniform Resource Locator)와 URN(Uniform Resource Name)이다. 예시 URI : https://example.com:8080/articles/index.html?search=chatgpt#intro Type Context Schema https:// Host example.com Port 8080 Path /articles/index.html Query ?search=chatgpt Fragment #intro 우리는 Host + Port + Path를 통해 어떠한 자원이 어느 서버의 어느 위치에 있는지를 알아낼 수 있으며, 이런게 URL이다. 이런 자원이 만약 어디에서 접근하든 고유한 이름으로 구분 가능하면 URN이다. URI는 이 모든 개념을 포함하며, Fragment처럼 자원의 위치만이 아닌 해당 자원 내부를 가르키는 특정 지점에 대한 정보까지도 URI는 포함할 수 있다. 참고링크 웹 개발자가 봐야할 하나의 지도 강의

tech-review · 2025-09-04

Git의 object와 refs 저장방식

tech-review · 2025-08-17

Git 정리

Git 개요 백엔드 시스템을 개발하면서, 기존의 연구 개발과는 달리 여러 사람이 병렬로 작업을 수행하게 되었다. 이에 따라 Git을 사용하게 되었고, 버전 및 브랜치 관리를 철저히 해야 할 필요성을 절실히 느꼈다. 이에 따라 Git에 대해 정리할 필요성을 느꼈고, 그 첫 번째로 Git의 공간과 파일의 상태에 대해 기초적인 내용을 정리한다. Git이란? Git이란 Version Control System의 일종으로, 소프트웨어 개발 및 협업 프로젝트에서 소스 코드, 문서, 기타 파일의 변경 사항을 추적하고 관리하는 데 사용된다. 혼자 작업하든 팀으로 작업하든, 버전 관리를 도입하면 다음과 같은 장점이 있다: 파일과 프로젝트를 이전 상태로 쉽게 되돌릴 수 있다. 누가 언제 어떤 작업을 했는지 추적할 수 있으며, 문제 발생 시 관련 이력을 확인할 수 있다. 파일을 잃어버리거나 실수로 수정했을 때 쉽게 복구할 수 있다. 서로의 작업을 덮어쓰지 않고 병렬로 작업하며, 변경 사항을 손쉽게 병합할 수 있다. 버전 관리 시스템(VCS)은 Git 외에도 다양한 도구들이 존재한다. 예를 들어 GUI 기반의 간편함을 선호하는 개발자들은 Mercurial을 사용하기도 하고, 코드 외의 리소스까지 통합 관리하는 Perforce (P4V) 도 있다. 하지만 현재까지 가장 널리 사용되는 VCS는 단연 Git이다. Git의 공간 Git은 파일들의 변경 이력을 추적하여 버전을 관리하는 도구다. 그렇다면 파일을 수정할 때마다 Git이 모든 변화를 자동으로 기록하는 것일까? → 그렇지 않다. Git은 우리가 작업하는 디렉토리의 파일 상태를 추적하고, 특정 명령을 실행할 때마다 스냅샷처럼 그 시점의 파일 상태를 기록한다(그러나 저장 방식은 파일을 복제하는 것이 아닌 변화를 기록하는 차이가 존재한다). 이러한 과정에서 Git은 변경된 파일들을 다양한 단계에서 관리한다. Git이 추적하는 파일 상태는 아래와 같은 네 가지 주요 공간을 통해 이해할 수 있다: 1. Working Directory Git으로 관리하기 위해 git init 등을 실행한 후 작업하게 되는 실제 디렉토리다. 이곳은 개발자가 직접 파일을 수정하거나 저장하는 공간이며, Git이 자동으로 버전을 기록하지 않는다. 즉, 파일을 수정하거나 새로 생성해도 git add 또는 git commit 명령을 실행하지 않으면, Git이 버전 이력에는 반영하지 않는다. 2. Staging Area Staging Area는 로컬 저장소에 기록(commit) 하기 전에 Git이 변경 내용을 임시로 저장하는 공간이다. 해당 공간이 존재함으로써 Merge 등의 작업을 수행할 때 충돌을 해결하거나, 한번에 커밋에 어떠한 정보들만 업데이트할지 천천히 파일들을 추가할 수 있다. 메모리 등에 임시로 저장되는게 아닌 별도의 공간에 존재하기에 이런 작업들을 오래 수행할 수 있다. git add 명령을 사용하면, 해당 파일은 Staging Area에 추가된다. Staging Area를 사용하면 원하는 변경 사항만 선택적으로 커밋할 수 있어, 커밋의 목적과 단위를 깔끔하게 분리할 수 있다. 3. Local Repo git commit 명령을 실행하면, Staging Area에 있던 변경 내용이 로컬 저장소에 커밋된다. 이 저장소는 .git 폴더 내부에 존재하며, 모든 커밋 이력, 브랜치 정보, 메타데이터 등을 포함한다. Git은 이곳에 실제 파일 내용뿐 아니라, 이전 버전과의 차이점, 커밋 메시지, 작성 시간, 작성자 등의 정보를 구조화하여 저장한다. 구체적인 .git 폴더의 저장 방식에 대해서는 링크를 참조하자 : 저장방법 로직 4. Remote Repo 로컬 저장소의 커밋 내역을 다른 사람과 공유하려면, git push 명령을 사용하여 Remote Repository로 전송한다. Remote Repository는 GitHub, GitLab, Bitbucket 등의 원격 저장소이며, .git 폴더와 동일한 커밋 이력을 저장하고 관리한다. 원격 저장소를 통해 팀원 간의 협업이 가능해지며, pull, fetch, merge 등을 통해 변경 사항을 주고받을 수 있다. Git의 파일의 상태 Git은 결국 각 파일이 시간에 따라 어떻게 변화해왔는지를 기록하는 도구이다. 이에 따라 각 공간으로 이동하는 것에 더해 Git은 사용자가 명시적으로 실행하는 명령에 따라 각 파일의 상태(state)를 구분하고 관리한다. Git에서 파일이 가질 수 있는 상태는 다음과 같다: Untracked / Tracked → (Unmodified, Modified, Staged) 1. Untracked Git은 파일의 변경 이력을 추적하고 버전을 관리하지만, 한 번도 Git에 추가되지 않은 파일은 Git 입장에서 “변경”이 아닌 “새로운 파일” 일 뿐이다. 즉, Git이 한 번도 기록한 적이 없는 파일은 과거 상태가 없기 때문에 변경 이력을 추적할 수 없다. 이러한 상태를 Untracked 이다. 실제 Git에선 git 프로젝트 내에서 새로운 파일을 생성시켰을 때, 기존의 추적되던 파일을 삭제하였을 때, 또한, .gitignore에 등록된 파일들도 일부러 추적하지 않기 때문에 Untracked 상태로 간주된다. 이는 예를 들어 다음과 같은 경우 유용하다: 대용량 파일로 인해 Git 저장소에 포함시키고 싶지 않은 경우 민감 정보(예: API 키, 비밀번호)가 포함된 파일을 외부 저장소에 업로드하고 싶지 않은 경우 위의 상태 도식과 달리 Tracked 상태의 파일을 삭제하지 않으면서 Untracked로 만들고 싶을 수 있다. 그런 경우 위처럼 git add, unstaged 같은 명령으론 수행할 수 없고 git rm --cached example.txt 라는 명령처럼 실수로 추적한 파일을 local repo와 staging area에서 없앨 수 있다. 2. Staged 위의 공간 설명에서 Staging Area란 공간은 commit을 수행하기 전 기록할 파일의 상태를 임시로 모아두는 공간이다. 이처럼 해당 공간에 파일들이 옮겨졌을 때 해당 파일들은 Staged 상태를 가지게 된다. 만약 Untracked 파일이 Staged 상태가 된다면 그 때부터 추적이 시작되는 것이고, 다시 unstaged하면 Untracked 상태로 돌아간다. 만약 당신이 파일을 Staged 상태로 바꾸고 워크 디렉토리에서 파일을 수정한다면 어떻게 될까? Staging Area에는 git add 시점의 파일 상태가 기록되는 것이다. 즉, 워킹 디렉토리의 파일과 Staged에 기록된 파일이 다른 것이다. 워킹 디렉토리에서 해당 파일을 수정하면, Git은 "Staging Area 버전" ≠ "Working Directory 버전" 인 것을 인식한다. 3. Unmodified Commit을 수행하면, Staging Area의 파일 상태가 Local Repository에 기록된다. 이후 git status 같은 명령이 실행될 때마다 Git은 Local Repo(HEAD) 와 워킹 디렉토리를 비교한다. 두 상태가 완전히 동일하다면 해당 파일은 Unmodified 상태이다. 예를 들어, 파일을 Staged 상태로 변경하고, 추가 수정 없이 commit을 하면 commit 직후 그 파일은 Unmodified 상태로 남는다. 4. Modified 위의 상태처럼 Commit 등을 통해 Staged를 Local Repo로 옮긴 후 추가적으로 워킹 디렉토리에서 파일을 수정했을 때, 해당 파일은 Local Repo와 상태가 다른 Modified 상태가 된다.

tech-review · 2025-08-12

카페인 중독자

Contact

tech-review