Day42

https://velog.io/@dos123789/Day42

배운내용

이번 Day42에서는 카카오 클라우드 환경에서의 실전 배포 자동화(CI/CD) 흐름을 처음부터 끝까지 직접 구성하며, “서비스를 실제로 운영한다”는 관점에서 많은 것을 배웠다.

1) SSH 기반 서버 접근과 배스천 구조 이해

pem 키 권한 설정 (chmod 400)

~/.ssh/config 를 활용한 서버 별칭 관리

Bastion 서버를 통해 Private 서버(Nginx, FastAPI)에 접근하는 구조 이해

실무에서 왜 SSH config가 필수적인지 체감

2) Frontend (React) 자동 배포 파이프라인 구축

GitHub 저장소 생성 및 로컬 프로젝트 연동

GitHub Actions workflow 작성

React 빌드 → Bastion 서버 업로드 → Nginx 서버로 rsync → Nginx reload

Secrets & Variables를 활용한 보안 정보 관리

코드 push → 자동 배포 → 즉시 반영되는 흐름 경험

3) Backend (FastAPI) 자동 배포 구성

GitHub Actions + Bastion + Private Server 구조

appleboy/ssh-action 을 이용한 원격 배포

FastAPI 서버를 systemd 서비스로 등록

git pull → venv 활성화 → 패키지 설치 → 서비스 재시작 자동화

4) CI/CD 보안 정책과 GitHub 인증 방식 이해

.github/workflows/*.yml 이 왜 보호 대상인지 명확히 이해

HTTPS + PAT 방식의 한계와 workflow scope 문제

SSH 인증 방식이 CI/CD에서 사실상 표준인 이유 학습

SSH 키 생성 → GitHub 등록 → remote 변경까지 실무 플로우 정리

5) 실전 트러블 슈팅 경험

workflow 파일 push 차단 문제 원인 분석

FastAPI DB 연결 문제 원인 파악 (API 경로 / 이슈)

“안 된다”에서 끝나는 게 아니라 왜 안 되는지 추적하는 경험

부족한 점 및 보완 계획

1) 배포 구조를 처음부터 설계하는 능력이 부족함

처음에는 “따라 치기” 수준에서 진행

Bastion → Private → 서비스 흐름을 나중에 정리하면서 이해

보완 계획

다음에는 아키텍처 다이어그램을 먼저 그리고 시작

배포 흐름을 글이나 그림으로 설명할 수 있을 정도로 정리

AWS / GCP 환경에서도 동일 구조를 직접 재구성해볼 예정

2) 네트워크·보안 개념에 대한 직관 부족

왜 Bastion을 쓰는지, 왜 SSH가 신뢰되는지 뒤늦게 이해

보안 정책을 “외워서” 처리하려는 습관이 드러남

보완 계획

VPC, Public / Private Subnet, Bastion 패턴 따로 정리

GitHub Actions 보안 모델(PAT vs SSH) 문서 기반으로 재정리

“왜 이런 정책이 존재하는가”를 항상 먼저 생각하기

3) 문제 발생 시 초기 원인 가설 수립이 느림

에러를 보고 바로 해결책을 찾으려는 경향

로그 → 원인 → 검증의 흐름이 아직 자동화되지 않음

보완 계획

트러블 슈팅 시

증상 요약

가능한 원인 리스트업

하나씩 제거
이 구조를 의식적으로 적용

이번 workflow / DB 이슈를 케이스 스터디로 따로 정리

Day43

https://velog.io/@dos123789/Day43-fjodqqng

배운점

배포란 단순히 코드를 서버에 올리는 것이 아니라
코드 수정 → GitHub push → 서버 반영까지의 전체 과정이라는 것을 이해했다.

수동배포를 통해
서버 접속, git pull, 가상환경 활성화, 패키지 설치, 서비스 재시작 흐름을 직접 경험했다.

수동배포는 구조를 이해하기엔 좋지만
반복 작업, 사람 실수, 규모 확장 한계가 명확하다는 것을 느꼈다.

CI는 코드 변경 시 자동으로 테스트·빌드·검증을 수행하는 과정이라는 것을 배웠다.

CD는 CI가 통과된 후
배포까지 자동으로 이어지는 단계라는 것을 이해했다.

GitHub Actions를 이용해
git push만으로 서버 배포가 이루어지는 자동배포 구조를 직접 구성했다.

Bastion 서버를 통해
외부에서 바로 접근할 수 없는 Private 서버에 안전하게 배포하는 구조를 이해했다.

자동배포에서는
사람이 서버에 직접 접속하지 않는 것 자체가 보안이라는 점을 체감했다.

수동배포와 자동배포를 비교하며
실무에서는 자동배포가 사실상 필수라는 점을 알게 되었다.

배포 방식에 따라
서비스 중단 여부, 롤백 난이도, 안정성이 크게 달라진다는 것을 배웠다.

롤링, 블루그린, 카나리, A/B, 리크리에이트 등
대표적인 배포 전략들의 차이와 사용 상황을 구분할 수 있게 되었다.

이번 실습에서 사용한 방식이
리크리에이트 배포라는 것을 명확히 인식했다.

서비스 규모와 중요도에 따라
적절한 배포 전략을 선택해야 한다는 실무 관점을 배우게 되었다.

부족한 점 및 보완 계획

배포 구조를 처음부터 스스로 설계하기보다는
흐름을 따라가며 이해하는 수준에 머물렀다.
→ 다음에는 배포를 시작하기 전에
아키텍처 흐름도를 먼저 그리고 구현하는 연습을 할 계획이다.

Bastion, Private 서버, CI/CD의 역할을
구성 후에야 명확히 이해했다.
→ VPC, Public/Private Subnet, Bastion 패턴을
이론 + 실습으로 다시 정리할 예정이다.

에러가 발생했을 때
원인을 구조적으로 가설화하기보다 결과 위주로 해결하려 했다.
→ 앞으로는
증상 정리 → 원인 후보 → 하나씩 검증하는 방식으로 접근한다.

GitHub Actions 보안 정책(PAT, workflow 제한)을
문제가 생긴 뒤에야 이해했다.
→ CI/CD 관련 인증 방식(HTTPS vs SSH)을
사전에 문서 기준으로 정리해둘 계획이다.

자동배포가 “되게 만드는 것”에 집중하고
왜 이 방식이 실무에서 쓰이는지에 대한 고민이 부족했다.
→ 다음 실습에서는
배포 방식 선택 이유까지 설명할 수 있도록 정리할 것이다.

로그, 모니터링 관점이 거의 없었다.
→ 배포 이후에는
서비스 상태 확인, 에러 로그 확인까지 포함한 배포 완료 기준을 세울 예정이다.

Day44

https://velog.io/@dos123789/Day44-hom1yipk

배운내용

이번 강의를 통해 클라우드 컴퓨팅이 단순히 “서버를 빌려 쓰는 것”이 아니라, 운영 방식 자체가 바뀐 인프라 패러다임이라는 점을 체감했다.
특히 NIST 기준의 정의를 기준으로 보니, 클라우드의 핵심은 기술이 아니라 사용 방식과 책임 분리 구조에 있다는 것이 명확해졌다.

가장 인상 깊었던 부분은 온디맨드 셀프 서비스와 신속한 탄력성이었다.
기존 온프레미스 환경에서는 서버를 하나 추가하는 데도 사전 계획, 장비 구매, 설치 시간이 필요했지만, 클라우드에서는 콘솔이나 API를 통해 몇 분 만에 자원을 생성하고 삭제할 수 있다는 점이 확실한 차이로 느껴졌다.
이 차이가 왜 스타트업과 글로벌 서비스가 클라우드를 선택하는지에 대한 답이라는 생각이 들었다.

또한 IaaS, PaaS, SaaS를 단순한 단계 구분이 아니라 “어디까지 내가 책임지는가”의 관점으로 이해하게 되었다.
IaaS는 인프라 위에서 모든 것을 직접 관리해야 하고,
PaaS는 개발에 집중할 수 있도록 환경을 제공받으며,
SaaS는 사용자는 기능만 쓰고 운영은 전부 서비스 제공자가 담당한다는 구조가 명확해졌다.
이제 서비스 모델을 볼 때 “편리하다”가 아니라 운영 책임의 범위가 먼저 떠오르게 되었다.

배포 모델 부분에서는 퍼블릭과 프라이빗의 단순 비교를 넘어서,
하이브리드와 커뮤니티 클라우드가 실제 산업에서 왜 필요한지 이해하게 되었다.
특히 금융·의료·공공기관처럼 규제가 중요한 환경에서는
퍼블릭 클라우드의 비용 효율성과 프라이빗 클라우드의 보안 요구를 동시에 만족해야 한다는 점이 현실적으로 다가왔다.

IAM과 네트워크 개념(VPC, 서브넷, 시큐리티 그룹)을 통해서는
클라우드 보안이 “막연히 위험하다”가 아니라,
권한과 네트워크를 얼마나 명확하게 분리하느냐의 문제라는 인식이 생겼다.
특히 역할 기반 접근 제어(RBAC)와 시큐리티 그룹의 화이트리스트 방식은
클라우드 환경에서 보안의 기본이 되는 사고방식이라는 점을 배웠다.

부족한점 및 보완 계획

아직 개념을 운영 관점에서 완전히 연결하지는 못했다는 한계를 느꼈다.
예를 들어 IaaS, PaaS, SaaS를 이해는 했지만
“어떤 서비스 규모에서 어떤 모델을 선택해야 하는지”에 대한 판단 기준은 아직 추상적이다.

또한 IAM과 네트워크 개념은 이론적으로는 이해했지만,
실제 서비스 환경에서 권한 설계를 어떻게 하면 과하지도, 느슨하지도 않게 만들 수 있는지에 대한 감각은 부족하다고 느꼈다.
특히 조직/프로젝트/역할이 많아질수록 권한 관리가 어떻게 복잡해지는지는 더 경험이 필요하다고 생각한다.

이를 보완하기 위해 다음과 같이 학습을 이어갈 계획이다.

실제 클라우드 콘솔에서
사용자, 역할, 프로젝트를 직접 나누어보며 IAM 구조를 실습해보기

단순 개념 암기가 아니라
“소규모 서비스 / 트래픽 증가 / 글로벌 서비스” 같은 시나리오별로
IaaS·PaaS·SaaS 선택 기준을 정리해보기

VPC, 서브넷, 시큐리티 그룹을
웹 서비스 아키텍처 다이어그램으로 직접 그려보며 구조를 시각화하기

다음 강의에서는 개념을 아는 수준을 넘어서
왜 이런 구조가 실무에서 표준이 되었는지 설명할 수 있는 상태를 목표로 학습을 이어가고 싶다.

Day45

https://velog.io/@dos123789/Day45-1ynl5c34

배운내용

이번 학습을 통해 트랜짓 게이트웨이, 스토리지, 모니터링·알림 서비스까지
클라우드 인프라가 어떻게 확장되고 운영되는지 전체 흐름을 이해할 수 있었다.
특히 기능을 쓰는 것보다 왜 이런 구조가 필요해졌는지를 생각하게 된 점이 가장 큰 수확이었다.

트랜짓 게이트웨이를 학습하면서 기존 VPC Peering 방식의 한계를 명확히 체감했다.
VPC가 많아질수록 VPC 간 연결이 복잡해지고, 관리 포인트가 분산되면서
네트워크 구조가 스파게티처럼 얽힌다는 문제가 왜 발생하는지 이해하게 되었다.
트랜짓 게이트웨이는 이러한 문제를 해결하기 위해 등장한 중앙 집중형 네트워크 허브라는 점이 인상 깊었다.

중앙 허브를 기준으로 여러 VPC와 온프레미스 네트워크를 연결함으로써
라우팅 정책을 한 곳에서 관리할 수 있고,
네트워크가 확장되더라도 구조가 크게 복잡해지지 않는다는 점에서
대규모 환경에서 사실상 표준 구조가 될 수밖에 없다는 생각이 들었다.

실습을 통해 Attachment와 라우트 테이블 개념도 보다 명확해졌다.
단순히 연결한다가 아니라,
어떤 VPC가 트랜짓 게이트웨이에 붙어 있는지,
CIDR 기준으로 트래픽이 어디로 흘러가는지를
명시적으로 설계해야 정상적인 통신이 가능하다는 점이 중요하게 느껴졌다.
특히 트랜짓 게이트웨이 라우트 테이블과
각 VPC 서브넷 라우트 테이블을 모두 설정해야 통신이 완성된다는 점은
실습을 통해서만 체감할 수 있는 부분이었다.

파일 스토리지와 오브젝트 스토리지를 비교하면서
스토리지는 하나의 개념이 아니다라는 점도 분명해졌다.
파일 스토리지는 여러 VM이 하나의 파일 시스템을 공유해야 하는 상황에 적합하고,
오브젝트 스토리지는 대규모 정적 파일을 URL 기반으로 제공하는 데 최적화되어 있다는 차이를
실습을 통해 명확히 구분할 수 있었다.
특히 파일 스토리지를 여러 VM에 마운트했을 때
하나의 파일이 동시에 공유되는 모습을 보며
공유 스토리지의 역할이 직관적으로 이해되었다.

오브젝트 스토리지 실습에서는
버킷, 객체, 접근 권한, 라이프사이클 개념이 단순 이론이 아니라
실제 운영에서 어떻게 활용되는지 알 수 있었다.
권한을 열지 않으면 URL로 접근할 수 없고,
라이프사이클 설정을 통해 비용과 데이터 관리를 자동화할 수 있다는 점에서
저장보다 운영의 개념이 강하게 느껴졌다.

모니터링과 알림 센터를 통해서는
클라우드 운영에서 사후 대응이 아니라 사전 감지가 왜 중요한지 이해하게 되었다.
CPU 사용량 같은 메트릭 기반 알림이나
VM 재시작 같은 이벤트 기반 알림을 설정함으로써
장애를 빠르게 인지하고 대응할 수 있는 구조가 갖춰진다는 점이 인상 깊었다.
클라우드 운영은 결국 서비스 상태를 얼마나 잘 관찰하고 통제하느냐의 문제라는 생각이 들었다.

부족한점 및 보완 계획

아직 네트워크와 스토리지 구성을 설계 관점에서 바로 그려내는 수준에는 도달하지 못했다고 느꼈다.
실습을 따라가며 이해는 했지만,
아무런 가이드 없이 이 환경에 맞는 구조를 직접 설계해보라고 하면
여전히 망설이게 될 것 같다.

또한 트랜짓 게이트웨이, 라우트 테이블, 시큐리티 그룹이
서로 어떤 책임을 나누고 있는지에 대한 직관이 완전히 자리 잡지는 않았다.
개념은 이해했지만,
잘못 설정했을 때 어떤 문제가 생길지까지 바로 떠올리기에는 경험이 부족하다.

이를 보완하기 위해 다음과 같은 계획을 세웠다.

트랜짓 게이트웨이 기반 네트워크 구조를
다이어그램으로 직접 그려보며 흐름을 시각화 해보기

Day46

https://velog.io/@dos123789/Day46-hzh80gf1

배운내용

용어 암기

부족한점 및 보완 계획

용어 외우기

본 후기는 [카카오엔터프라이즈x스나이퍼팩토리] 카카오클라우드로 배우는 AIaaS 마스터 클래스 3기(B-log) 리뷰로 작성 되었습니다.