본문 바로가기
반응형

분류 전체보기118

[리눅스 기초 #75] 리눅스를 넘어 데브옵스 마스터로: 다음 100일을 위한 커리어 로드맵 리눅스 기초 시리즈의 영광스러운 75번째 시간, 그리고 사실상의 대단원을 장식하는 시간입니다! 우리는 지난 75일간 윈도우 위의 WSL2 설치부터 시작해 Docker, Kubernetes, Terraform, Prometheus, 그리고 최근의 FinOps까지 리눅스 생태계의 거대한 산맥을 함께 넘었습니다. 처음에는 ls 명령어 하나에도 당황하던 우리가 이제는 클라우드 비용을 최적화하는 수준까지 올랐습니다.하지만 기술의 세계에는 끝이 없습니다. 리눅스라는 튼튼한 뿌리를 내렸다면 이제는 그 위에 데브옵스(DevOps)라는 울창한 가지를 뻗칠 차례입니다. 오늘은 지난 여정을 갈무리하며, 여러분이 리눅스 마스터를 넘어 시장이 열광하는 시니어 엔지니어로 거듭나기 위한 커리어 로드맵과 다음 100일의 학습 전략을.. 2026. 3. 4.
[리눅스 기초 #74] 인프라도 다이어트가 필요하다: FinOps로 클라우드 비용 90% 아끼는 실전 기술 리눅스 기초 시리즈의 74번째 시간입니다! 지난 시간에는 시스템에 고의로 장애를 주입해 면역력을 기르는 카오스 엔지니어링을 다뤘습니다. 이제 우리 서버는 어떤 풍파에도 견디는 강철 체력을 갖추게 되었죠. 하지만 성이 튼튼해지고 규모가 커질수록 성을 유지하기 위한 '식비'와 '관리비'가 기하급수적으로 늘어나기 마련입니다.클라우드 환경에서 리눅스 서버를 운영하다 보면 성능에만 집중한 나머지, 매달 날아오는 청구서를 보고 경악하는 순간이 옵니다. 오늘은 개발(Dev)과 운영(Ops)을 넘어 재무(Finance)까지 아우르는 데브옵스의 경제학, FinOps(핀옵스)와 그 핵심 전략들을 저의 경험담과 함께 정리해 보겠습니다.1. 나의 경험담: "한 달 월급이 클라우드 비용으로 나갈 뻔한 사연" 최근 제 유튜브 쇼.. 2026. 3. 4.
[리눅스 기초 #73] 완벽한 시스템을 파괴하라: 카오스 엔지니어링(Chaos Engineering)으로 단련하는 서버의 면역력 리눅스 기초 시리즈의 73번째 시간입니다! 지난 시간에는 Istio 서비스 메시를 통해 복잡하게 얽힌 마이크로서비스 간의 통신을 제어하고 가시성을 확보하는 법을 배웠습니다. 이제 우리 시스템은 겉보기에는 완벽한 요새와 같습니다. 자동화되고, 감시되고 있으며, 지능적으로 흐름을 조절하니까요.하지만 '보기에 완벽한 것'과 '실제로 튼튼한 것'은 다릅니다. 평화로운 날에는 잘 돌아가던 시스템이 꼭 중요한 순간에 예상치 못한 곳에서 무너지곤 하죠. 오늘은 우리 시스템의 숨은 약점을 찾아내기 위해 일부러 고장을 일으키는 혁신적인 방법론, 카오스 엔지니어링(Chaos Engineering)을 저의 생생한 경험담과 함께 정리해 보겠습니다.1. 나의 경험담: "멀쩡한 파드를 죽여야만 했던 이유"IT 개발자로 살아가며 .. 2026. 3. 3.
[리눅스 기초 #72] 마이크로서비스의 거대한 미로를 탈출하다: Istio로 구현하는 서비스 메시(Service Mesh)와 트래픽 제어 리눅스 기초 시리즈의 72번째 시간입니다! 지난 시간에는 GitOps와 ArgoCD를 통해 인프라의 주권을 Git에 넘기고, 모든 배포를 선언적으로 관리하는 법을 배웠습니다. 이제 우리 서버는 코드 한 줄로 전 세계 어디든 똑같은 모습으로 배포되는 '불변의 인프라'가 되었습니다.하지만 서비스의 규모가 커지고 수십 개의 마이크로서비스(Microservices)가 서로 얽히기 시작하면, 또 다른 차원의 혼돈이 찾아옵니다. "A 서비스가 왜 B 서비스와 통신을 못 하지?", "어떤 서비스 때문에 전체 시스템이 느려진 걸까?" 같은 질문에 답하기가 점점 어려워지죠. 오늘은 이 복잡한 서비스 간 통신을 투명하게 관리하고 제어하는 데브옵스의 끝판왕 기술, 서비스 메시(Service Mesh)와 그 중심에 있는 Is.. 2026. 3. 3.
[리눅스 기초 #71] 인프라의 주권을 Git에게: GitOps와 ArgoCD로 구현하는 선언적 배포의 정점 리눅스 기초 시리즈의 71번째 시간입니다! 지난 시간에는 서버 인프라가 스스로 몸집을 불리는 클러스터 오토스케일러(CA)를 통해 물리적 한계를 극복하는 법을 배웠습니다. 이제 우리 서버는 트래픽이라는 파도가 몰아쳐도 굳건히 버틸 수 있는 거대한 성이 되었습니다.하지만 성이 커질수록 관리해야 할 방도 많아지는 법이죠. 수십 대의 서버에 일일이 접속해 코드를 업데이트하고 계신가요? 혹은 '누가, 언제, 무엇을' 변경했는지 몰라 장애가 났을 때 범인을 찾느라 혈안이 되어 있진 않나요? 오늘은 모든 인프라의 상태를 Git에 기록하고, 자동으로 동기화하는 데브옵스의 꽃, GitOps와 그 핵심 도구인 ArgoCD를 저의 경험담과 함께 정리해 보겠습니다.1. 나의 경험담: "명령어 한 줄의 실수가 불러온 나비효과".. 2026. 3. 2.
[리눅스 기초 #70] 서버 인프라의 자동 완성: 클러스터 오토스케일러(CA)로 물리 서버까지 지배하기 리눅스 기초 시리즈의 영광스러운 70번째 시간입니다! 지난 시간에는 파드(Pod)의 개수를 유연하게 조절하는 HPA를 통해 트래픽 폭주에 대응하는 법을 배웠습니다. 이제 우리 서비스는 사용자가 몰리면 스스로 분신술을 부리듯 몸집을 불릴 수 있게 되었죠.하지만 여기에는 치명적인 한계가 있습니다. 파드가 늘어나고 싶어도, 그 파드가 발을 딛고 서 있을 '물리 서버(Node)'의 자원이 꽉 차버리면 어떻게 될까요? 파드는 'Pending(대기)' 상태에 빠져 영영 살아나지 못하게 됩니다. 오늘은 인프라 자동화의 최종 단계, 자원이 부족하면 서버(노드)를 통째로 새로 사오고(생성), 남으면 반납하는 클러스터 오토스케일러(Cluster Autoscaler, CA)를 저의 경험담과 함께 정리해 보겠습니다.1. 나의.. 2026. 3. 2.
반응형

티스토리툴바