[LG CNS 6기] 31일차 TIL - 특강 / DevOps Tools — Git, Docker, AWS EC2, GitHub Actions

김승진·2026년 9월 10일

LG CNS AM 6기 TIL

목록 보기

40/46

DevOps Tool인 Git부터 GitHub Actions, Docker, AWS EC2까지, 코드가 커밋되고 나서 서버에 배포되기까지의 전체 흐름을 도구별로 훑었다.

DevOps는 개발과 운영을 합치는 것이 아니라, 개발자가 운영까지 고려하고 운영자가 개발 흐름을 이해하면서 도구로 그 과정을 자동화하는 문화라고 배웠다. 그 핵심이 CI/CD다.

빌드→테스트→배포를 사람이 손으로 하나씩 하지 않고 자동화한다는 게 핵심이었다.

Working Directory → (git add) → Staging Area → (git commit) → Local Repository → (git push) → Remote Repository로 이어지는 흐름을 정리했다.

git branch -M main: 예전엔 기본 브랜치명이 master였는데, master/slave라는 표현 문제로 요즘은 main으로 바꿔서 쓴다.
git push -u origin main: -u(upstream)를 한 번 걸어두면 그다음부터는 git push만 써도 같은 브랜치로 올라간다.
git fetch는 원격 변경사항을 받아오기만 하고 병합은 안 하고, git pull은 fetch + merge를 한 번에 한다. 그래서 작업 시작 전엔 항상 git pull부터 하는 습관이 필요하다.
커밋 메시지는 1줄 제목, 빈 줄, 그 다음 설명 순서로 쓰고, 나중에 주간보고에 그대로 쓸 수 있을 만큼 구체적으로 적는 게 좋다고 하셨다.
git reset으로 과거 커밋 시점으로 돌아갈 수 있다.

my-devops-project 레포로 init → add → commit → .gitignore → push까지 전체 흐름을 직접 실습했다.

Container: 호스트 컴퓨터 안에서 독립적으로 격리되어 돌아가는 미니 컴퓨터
Image: 컨테이너를 만드는 설계도. 읽기 전용이라 수정하려면 새 이미지를 만들어야 한다.
docker run은 docker create + docker start를 합친 명령어이다.
Dockerfile에서 RUN은 이미지를 만드는 과정에서 실행되는 명령이고, CMD/ENTRYPOINT는 그 이미지로 컨테이너가 시작될 때 실행되는 명령이라 시점이 다르다.
JDK는 JRE(실행 환경) + 개발 도구라서, 빌드할 땐 JDK가 필요하지만 실행만 할 땐 JRE로도 충분하다.
실습에서는 빌드 스테이지와 실행 스테이지를 나누는 멀티스테이지 빌드 방식으로 프론트/백엔드 샘플(devops-front, devops-backend)을 각각 이미지로 만들고 컨테이너로 띄워봤다.

온프레미스(서버를 직접 사서 운영)와 비교해서, AWS는 필요할 때 켜고 끄면 되는 방식이라는 차이를 먼저 짚었다.
IAM: 계정별 접근 권한을 관리하는 시스템
EC2: AWS가 빌려주는 가상 서버.
키 페어(.pem)는 그 EC2에 접속할 때 쓰는 열쇠.
보안 그룹은 EC2 앞에 쳐놓은 울타리 같은 개념으로, 어떤 포트로 들어오는 트래픽을 허용할지(인바운드)와 나가는 트래픽을 허용할지(아웃바운드)를 정한다.

Jenkins는 별도 서버를 직접 구축해야 하는데, GitHub Actions는 GitHub에 내장된 기능이라 서버를 따로 안 만들어도 된다는 게 가장 큰 차이였다.

흐름은 커밋·푸시 → GitHub Actions가 감지해서 정의해둔 워크플로우 실행(빌드→테스트→배포) → 배포된 최신 코드로 서버 재실행이다.

github-actions-study 레포에서 .github/workflows/*.yml을 직접 만들어서, push할 때마다 정의한 step들이 순서대로 실행되는 걸 Actions 탭에서 확인했다. ${{ secrets.내이름 }} 형태로 민감한 값은 Secret으로 등록해서 코드에 그대로 노출되지 않게 하는 것도 실습했다
devops-service(스프링 부트 프로젝트)로는 실제 CI/CD를 두 가지 방식으로 만들어봤다.
1. EC2에 직접 SSH로 접속해서 git pull + 빌드까지 EC2 안에서 실행하는 방식 — 가장 단순하지만 운영 서버의 성능을 빌드 작업이 갉아먹는다는 단점이 있다.
2. (최종) GitHub Actions 안에서 빌드까지 끝내고, 결과물(jar 파일)만 scp로 EC2에 전달한 뒤 EC2에서는 그 jar를 실행만 하는 방식. EC2는 빌드 부담이 없고, 필요한 값들은 application.yml을 .gitignore로 빼두고 GitHub Secret으로 관리했다.

직접 해본 것:

my-devops-project 레포로 git init~push 전체 흐름 실습
Docker로 프론트/백엔드 샘플 프로젝트 각각 이미지 빌드 후 컨테이너 실행, 브라우저로 접속 확인
AWS EC2 인스턴스 생성, 보안 그룹 포트 설정, .pem 키로 SSH 접속
github-actions-study 레포에서 워크플로우 단계별로 늘려가며 Actions 탭에서 실행 로그 확인
devops-service를 EC2 직접 빌드 방식 → GitHub Actions 빌드 후 scp 전달 방식으로 전환하고, 실제 EC2에서 재배포되는 것까지 확인