데브옵스 엔지니어
DevOps Engineer
역할
짠 코드가 서버에 올라가 돌아가기까지의 과정을 자동으로 굴러가게 만드는 엔지니어입니다.
등장 배경
만드는 조직과 돌리는 조직이 따로 있던 시절이 있었습니다. 새 기능을 빨리 내보내는 것이 한쪽의 성과였고, 서버를 흔들지 않는 것이 다른 쪽의 성과였습니다. 두 성과가 정면으로 부딪혔습니다. 코드를 자주 올릴수록 멈출 확률이 올라가니, 운영 쪽은 배포를 한 달에 한 번으로 묶어 두는 쪽이 유리했습니다.
그래서 배포는 금요일 밤의 행사가 됐습니다. 한 달치 변경을 한꺼번에 올리고 새벽까지 지켜보다가, 무언가 잘못되면 그중 어느 변경이 원인인지 찾는 데만 몇 시간을 썼습니다. 절차도 사람 머릿속에 있었습니다. 서버에 접속해 파일을 올리고 몇 가지를 순서대로 실행하는 일을 한 사람만 알고 있어서, 그가 휴가를 가면 그달에는 아무것도 못 내보냈습니다. 문제가 터지면 "제 컴퓨터에서는 잘 됐는데요" 와 "어제까지 서버는 멀쩡했습니다" 가 부딪히고 끝났습니다.
데브옵스는 이 벽을 없애자는 쪽으로 방향을 튼 말입니다. 배포를 조심스럽게 드물게 하는 대신, 작게 자주 하고 잘못되면 빨리 되돌릴 수 있게 만들자는 생각입니다. 그러려면 사람 손으로 하던 일이 전부 자동으로 돌아야 합니다. 데브옵스 엔지니어는 그 자동으로 도는 길을 만들고 관리하는 자리입니다.
하루 업무
코드가 합쳐진 뒤 서버에 닿기까지의 길을 손보고, 그 길 위에서 벌어진 일을 살피는 데 하루를 씁니다.
- 배포가 지나가는 길을 고칩니다. CI/CD는 누군가 코드를 합치면 자동으로 검사하고 문제가 없으면 서버까지 올려 주는 체계입니다. 검사에 5분이 걸리던 것이 20분으로 늘면 개발자들이 합치기를 미루기 시작하므로, 느려진 단계를 찾아 줄이는 일이 꾸준히 붙습니다.
- 인프라를 손이 아니라 글로 관리합니다. 코드형 인프라는 서버 몇 대를 어떤 설정으로 띄울지를 파일에 적어 두고 그 파일대로 만들어지게 하는 방식입니다. 손으로 만든 서버는 왜 그렇게 설정됐는지 아무도 모르지만, 적어 둔 것은 읽을 수 있고 되돌릴 수 있습니다.
- 무슨 일이 벌어지는지 보이게 만듭니다. 관측성은 기록과 지표를 미리 심어 두어 지금 시스템 안의 상태를 밖에서 알 수 있게 하는 일입니다. 여기서 중요한 것은 알림의 기준입니다. 응답이 조금만 느려져도 울리게 해 두면 하루 40건이 쌓이고, 그러면 진짜 장애 알림도 함께 무시됩니다.
- 멈췄을 때 되돌립니다. 롤백은 직전 버전으로 되돌리는 조치입니다. 원인을 찾기 전에 먼저 되돌려 사용자를 돌려놓고, 원인은 그다음에 찾습니다. 온콜 당번이면 밤에도 알림을 받습니다.
- 개발자가 스스로 할 수 있게 만듭니다. 새 환경 하나를 띄우려고 매번 데브옵스에게 요청해야 한다면 그 자리가 병목이 됩니다. 명령 한 줄로 되게 만들어 두고 쓰는 법을 적어 두는 일이 이 자리의 절반입니다.
함께 일하는 사람
거의 모든 직군과 맞닿지만 가장 자주 붙는 쪽은 서버를 짜는 사람들입니다.
백엔드 개발자와는 매일 붙습니다. 새 기능에 필요한 저장 공간이나 외부 연결을 어떻게 띄울지, 부하가 몰릴 때 서버를 자동으로 늘리는 오토스케일링을 어디까지 열어 둘지 같은 것을 같이 정합니다. 프론트엔드 개발자 쪽과는 주로 배포 속도와 미리 확인해 볼 환경을 두고 이야기합니다.
보안 엔지니어와는 권한을 두고 부딪히기 쉽습니다. 개발자가 직접 내보낼 수 있게 열수록 일이 빨라지지만 사고가 날 자리도 넓어집니다. 둘 중 하나를 고르는 대신, 누가 무엇을 했는지 기록에 남게 해 두고 위험한 동작만 한 번 더 확인받게 하는 식으로 맞춥니다.
규모가 작은 회사에서는 이 자리가 여러 몫을 겸합니다. 구성원 마흔다섯 명인 페이지덱에는 안정성을 전담하는 사람도 보안 전담자도 따로 없고, 그 일을 데브옵스 엔지니어 한 명과 백엔드 개발자들이 나눠 집니다. 자리가 갈라지는 때는 대개 한 사람이 두 성격의 일을 함께 못 하게 됐을 때입니다.
실무 용례
"배포 파이프라인이 20분 걸려서 다들 합치기를 미루고 있어요."
자동 검사가 느려진 것이 개발 속도를 떨어뜨리고 있으니 손봐야 한다는 말입니다.
"일단 롤백부터 하고 원인은 그다음에 봅시다."
사용자가 겪는 문제를 먼저 끊고 조사는 나중에 하자는 판단입니다.
"그건 데브옵스에 요청하지 말고 그냥 명령어로 띄우세요."
매번 사람을 거치지 않게 이미 자동으로 만들어 둔 길이 있다는 뜻입니다.
페이지덱도 예전에는 배포가 격주 목요일 저녁 행사였습니다. 2주치 변경이 한꺼번에 올라가니 무언가 어긋나면 어느 변경 탓인지 가려내는 데만 한 시간이 넘게 걸렸고, 그 시간 동안 문서 저장이 간헐적으로 실패했습니다.
데브옵스 엔지니어가 들어온 뒤 한 일은 배포 크기를 줄인 것이었습니다. 검사와 배포를 자동으로 돌게 만들어 하루에 여러 번 올리게 했고, 되돌리는 절차를 버튼 하나로 정리했습니다. 태오가 오후에 고친 것이 30분 뒤 사용자에게 닿습니다. 어긋나도 그 30분 안의 변경 하나만 보면 되니 원인 찾기가 한 시간에서 몇 분으로 줄었습니다.
흔한 오해
서버를 관리하는 사람이라고 읽는 경우가 가장 흔합니다. 인프라를 다루는 것이 맞으니 그렇게 보입니다. 하지만 이 자리의 결과물은 잘 관리된 서버가 아니라 개발자가 스스로 내보낼 수 있는 상태입니다. 요청을 받아 대신 처리해 주는 쪽으로 자리가 굳으면 배포 한 번마다 사람을 기다려야 하고, 그러면 개발자들은 변경을 모아 뒀다가 한꺼번에 내보내게 됩니다. 없애려던 격주 목요일 저녁이 그대로 돌아오는 셈입니다.
데브옵스를 직무 이름으로만 아는 것도 오해입니다. 채용 공고에 그렇게 적혀 있으니 자연스러운 일입니다. 원래 이 말은 만드는 쪽과 돌리는 쪽을 붙여 놓자는 일하는 방식을 가리켰습니다. 그래서 데브옵스 담당을 한 명 뽑아 두고 나머지는 예전처럼 일하면 벽이 옮겨 갈 뿐입니다. 개발팀이 자기 코드가 서버에서 어떻게 도는지 모르는 상태로 남으면, 장애가 났을 때 원인을 아는 사람과 고칠 수 있는 사람이 여전히 다른 사람입니다.
자주 헷갈리는 용어
| 용어 | 무엇을 맡는가 | 데브옵스 엔지니어와의 차이 |
|---|---|---|
| SRE | 서비스 안정성 | 한 달에 몇 분까지 멈춰도 되는지를 숫자로 정하고 그 선을 지키는 데서 출발합니다. 데브옵스가 내보내는 속도를 다룬다면 이쪽은 멈추지 않는 정도를 다룹니다 |
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16