🛠️ DevOps·인프라 학습 로드맵

DevOps는 배울 것의 목록이 아니라 범위의 문제 때문에 시작이 어렵습니다. 리눅스, 네트워크, 컨테이너, 빌드 도구, 클라우드 서비스, 모니터링까지 전부 이름은 들어 봤지만 서로 어떻게 이어지는지가 보이지 않고, 그래서 각각을 따로 공부하다가 어느 것도 실제 운영으로 이어지지 않은 채 흐지부지되기 쉽습니다. 게다가 튜토리얼은 언제나 성공 경로만 보여 줍니다. 실무에서 시간을 쓰는 쪽은 배포가 잘 되는 경우가 아니라 배포는 성공했다고 나오는데 서비스가 안 되는 경우입니다.

여기서 한 가지를 먼저 정해 두겠습니다. 자동화는 그 자체로 좋은 것이 아닙니다. 관측 장치 없이 자동화를 늘리면 사람이 확인하던 단계가 사라지면서, 잘못된 변경이 더 빠르게 더 넓게 퍼질 뿐입니다. 그래서 이 로드맵은 눈을 먼저 만들고 손을 나중에 늘리는 순서로 짰습니다. 쿠버네티스 운영자 수준의 클러스터 관리, 서비스 메시, 멀티 클라우드 설계는 일부러 제외했습니다. 서버 한 대에 무슨 일이 일어나는지 설명하지 못하는 상태에서 그 위로 올라가면, 문제가 생겼을 때 어느 층을 의심해야 할지조차 알 수 없게 됩니다. 전체를 도는 데 4~6개월을 잡고, 단계마다 실제로 인터넷에서 접속되는 결과물을 남기십시오.

1단계 — 서버 한 대를 손으로 다뤄 보기

가장 먼저 필요한 것은 리눅스 위에서 무슨 일이 벌어지는지 읽는 능력입니다. 프로세스와 포트를 확인하고, 로그가 어디에 쌓이는지 찾고, 파일 권한과 소유자를 이해하고, 디스크와 메모리 사용량을 보는 정도입니다. 여기에 셸 스크립트로 반복 작업을 묶는 법, SSH로 접속하고 키를 관리하는 법, 그리고 서비스가 부팅 시 자동으로 뜨도록 등록하는 법까지가 이 단계의 범위입니다. 클라우드의 가장 작은 인스턴스 하나를 빌려서 직접 해 보는 편이 어떤 강의보다 빠릅니다.

완료 기준: 접속은 되는데 서비스가 응답하지 않는 서버를 받았을 때, 프로세스가 죽은 것인지 포트가 막힌 것인지 디스크가 찬 것인지를 순서대로 확인해 좁혀 갈 수 있으면 됩니다.
체크포인트: 빈 서버에 웹 애플리케이션 하나를 직접 올려 도메인 없이 IP로 접속되게 만들고, 재부팅한 뒤에도 자동으로 살아나는지 확인해 보십시오.
자주 막히는 곳: 애플리케이션은 정상인데 방화벽이나 보안 그룹에서 포트가 닫혀 있어 접속이 안 되는 상황입니다. 서버 안에서 curl로는 응답하는데 밖에서는 안 되는 경우가 전형적인 신호이고, 이걸 모르면 애꿎은 애플리케이션 코드만 몇 시간씩 들여다보게 됩니다.

2단계 — 실행 환경을 통째로 묶기

같은 코드가 내 노트북에서는 돌고 서버에서는 안 도는 이유의 대부분은 환경 차이입니다. 컨테이너는 그 차이를 이미지 안으로 밀어 넣는 방법입니다. 이미지를 정의하는 파일을 직접 써 보고, 레이어가 어떻게 쌓이고 캐시되는지 이해하고, 볼륨으로 데이터를 밖에 두는 법과 컨테이너끼리 네트워크로 통신하게 하는 법을 익히는 단계입니다. 애플리케이션과 데이터베이스를 함께 띄우는 구성까지 해 보면 감이 잡힙니다.

완료 기준: 다른 사람이 코드를 받아 명령 한 줄로 같은 환경을 띄울 수 있게 만들 수 있고, 컨테이너가 즉시 종료될 때 그 원인을 로그로 확인할 수 있으면 됩니다.
체크포인트: 1단계에서 손으로 올린 애플리케이션을 이미지로 감싸고, 데이터베이스와 함께 뜨는 구성으로 바꿔 보십시오. 컨테이너를 지웠다 다시 만들어도 데이터가 남아 있어야 합니다.
자주 막히는 곳: 상태를 컨테이너 안에 두는 것입니다. 업로드된 파일이나 데이터베이스 파일이 이미지 안 경로에 쌓여 있으면, 배포로 컨테이너를 교체하는 순간 조용히 사라집니다. 배포 직후가 아니라 며칠 뒤에 발견되는 유형의 사고입니다.

3단계 — 사람 손을 거치지 않는 배포 경로 만들기

코드를 올리면 검사가 돌고, 통과하면 이미지가 만들어지고, 그것이 실제 환경까지 가는 경로를 만드는 단계입니다. 도구는 여러 가지지만 구조는 비슷합니다. 저장소의 변경을 신호로 삼아 단계별 작업을 순서대로 실행하고, 각 단계의 성공 여부로 다음 진행을 결정합니다. 여기서 배워야 할 것은 문법이 아니라 어떤 단계를 자동으로 통과시키고 어떤 단계에서 멈출지를 정하는 감각입니다.

비밀 값 관리도 이 단계에서 반드시 짚고 넘어가야 합니다. 접속 정보와 키는 저장소나 이미지가 아니라 실행 시점에 주입되어야 하고, 로그에 찍히지 않아야 합니다. 파이프라인 로그는 대개 팀 전체가 볼 수 있습니다.

완료 기준: 방금 배포된 것이 어느 커밋인지 추적할 수 있고, 잘못된 배포를 이전 상태로 되돌리는 절차를 직접 실행해 본 상태면 됩니다.
체크포인트: 저장소에 푸시하면 테스트가 돌고 이미지가 만들어져 서버까지 반영되는 파이프라인을 만들고, 일부러 실패하는 테스트를 넣어 배포가 멈추는지 확인해 보십시오.
자주 막히는 곳: 이미지 태그를 항상 같은 이름으로 덮어쓰는 구성입니다. 그러면 지금 돌고 있는 것이 어느 코드인지 알 수 없고, 되돌리려 해도 되돌릴 대상이 남아 있지 않습니다. 태그에는 커밋을 식별할 수 있는 값을 붙이십시오.

4단계 — 인프라를 문서가 아니라 코드로 남기기

콘솔에서 클릭으로 만든 자원은 한 달만 지나도 누가 왜 만들었는지 알 수 없게 됩니다. 인프라를 선언적으로 기술하고, 그 파일을 저장소에 두고, 변경을 적용하기 전에 무엇이 바뀌는지 미리 확인하는 방식으로 옮기는 단계입니다. 핵심 개념은 세 가지입니다. 원하는 상태를 선언하면 도구가 현재와의 차이를 계산해 채운다는 점, 그 현재 상태를 기록한 파일이 따로 존재한다는 점, 그리고 같은 정의를 여러 환경에 재사용할 수 있다는 점입니다.

이 방식의 진짜 이득은 자동화가 아니라 변경 이력입니다. 지난주에 누가 어떤 설정을 바꿨는지가 코드 리뷰 기록으로 남고, 장애 원인을 인프라 변경에서 찾을 수 있게 됩니다.

완료 기준: 운영 환경과 동일한 구성을 처음부터 다시 만들어 낼 수 있고, 적용 전에 어떤 자원이 새로 생기고 어떤 자원이 지워지는지 읽을 수 있으면 됩니다.
체크포인트: 지금까지 손으로 만든 서버와 네트워크 설정을 코드로 옮기고, 그 정의로 테스트용 환경 하나를 새로 만들었다가 통째로 지워 보십시오.
자주 막히는 곳: 코드로 관리하기 시작한 뒤에도 급하다는 이유로 콘솔에서 직접 설정을 바꾸는 것입니다. 실제 상태와 기록된 상태가 어긋나면 다음 적용 때 도구가 그 변경을 되돌려 버리고, 하필 그 시점이 배포 중일 때가 많습니다.

5단계 — 무너지는 순간을 먼저 알기

여기까지 오면 배포는 빨라졌습니다. 그런데 빨라진 배포는 잘못된 변경도 빠르게 퍼뜨립니다. 이 단계에서 할 일은 시스템이 지금 어떤 상태인지 숫자로 말할 수 있게 만드는 것입니다. 요청량과 에러율과 응답 지연을 지표로 수집하고, 로그를 검색 가능한 형태로 모으고, 하나의 요청이 여러 서비스를 지나갈 때 어디서 시간을 썼는지 추적할 수 있게 합니다.

그다음이 경보 설계인데, 여기서 대부분이 실패합니다. 경보는 사람이 지금 무언가를 해야 하는 상황에만 울려야 합니다. CPU가 잠깐 높다는 이유로 새벽에 울리는 경보가 몇 개만 쌓이면 팀은 곧 모든 알림을 무시하게 되고, 그때부터는 관측 장치가 없는 것과 같아집니다. 사용자가 겪는 증상에 가까운 신호를 기준으로 삼고, 장애 후에는 사람의 실수를 지적하는 대신 같은 실수가 반복될 수 있게 놔둔 구조를 고치는 회고를 남기십시오.

완료 기준: 서비스가 느려졌다는 제보를 받았을 때, 화면을 몇 개 열어 원인 후보를 좁힌 뒤 그 근거를 남에게 설명할 수 있으면 됩니다.
체크포인트: 자신의 서비스에 에러율과 지연 지표를 붙이고 대시보드를 만든 다음, 일부러 장애를 일으켜 경보가 울리기까지 몇 분이 걸리는지 재 보십시오.
자주 막히는 곳: 서버 자원 지표만 보고 있는 것입니다. CPU와 메모리는 멀쩡한데 외부 API 응답이 느려져 전체가 밀리는 상황은 자원 그래프에 거의 드러나지 않습니다.

지금은 미뤄도 되는 것

• 쿠버네티스 심화 운영 — 컨테이너 몇 개를 안정적으로 굴려 본 뒤라야 스케줄러와 자원 제한이 왜 필요한지 이해됩니다.
• 서비스 메시 — 서비스가 여러 개로 늘어 통신 문제가 실제로 생긴 다음에 꺼낼 카드입니다.
• 멀티 클라우드 구성 — 한 곳에서 운영을 안정시키기 전에는 복잡도만 두 배가 됩니다.
• 자동 확장 정교화 — 트래픽 패턴을 몇 달 관찰한 데이터가 있어야 기준을 정할 수 있습니다.

다음에 이어 볼 자료