저는 컨설팅 회사에서 소프트웨어 엔지니어로 일하고 있으며, DevOps 업무도 일부 수행하고 있습니다. 최근에는 DevOps에 전념하는 직무를 제안받았는데, 플랫폼 작업을 즐기긴 하지만 전임으로 소프트웨어 개발을 포기하고 DevOps만 하는 것이 맞는지 고민됩니다. DevOps로 전환한 소프트웨어 엔지니어분들이 계시다면, 후회는 없으셨는지, 긍정적인 경험이었는지 궁금합니다.
개인 프로젝트에서는 코딩을 즐기지만, 직업적으로는 반복적인 루틴에 지루함을 느꼈습니다. 매일 Jira 티켓을 열고, 기능이나 버그를 구현하고, 푸시하는 일상이 반복됐죠. DevOps에서는 매일 새로운 과제가 주어집니다. 기존 프로세스를 자동화하고, 새로운 솔루션을 현재 시스템에 통합하거나, 새로운 언어를 위한 파이프라인을 구축하는 등의 작업이죠.
또한, “프로덕션 서버 다운!”, “데이터베이스 응답 없음”, "보안 침해 가능성!"과 같은 긴급 상황이 발생할 때, 모든 기술과 지식을 동원하여 문제를 해결하는 데서 오는 해방감을 느낍니다.
3 Likes
DevOps 역할에서는 여전히 소프트웨어를 작성할 기회가 많습니다. 저는 백엔드 소프트웨어 엔지니어에서 인프라/DevOps로 전환한 지 5년이 되었고, 한 번도 후회한 적이 없습니다. 해결하는 문제가 더 흥미롭고 도전적이며, 전체적으로 더 나은 엔지니어가 되었다고 느낍니다.
4 Likes
말씀해주신 고민은 많은 소프트웨어 엔지니어들이 어느 시점에서 한 번쯤 겪는 자연스러운 질문입니다. 특히 플랫폼 엔지니어링과 DevOps가 점점 중요해지는 상황에서는 더더욱 그렇습니다. 결론만 먼저 말씀드리면, DevOps로 전환하는 선택 자체는 옳고 그름이 아니라, “내가 어떤 방식으로 기술 경력을 설계하고 싶은가”의 문제에 더 가깝습니다.
실제 업계에서 소프트웨어 엔지니어가 DevOps나 플랫폼 엔지니어링 쪽으로 커리어를 전환하는 사례는 꾸준히 많고, 상당수는 이를 긍정적으로 평가합니다. 이유는 DevOps가 단순한 배포 자동화가 아니라, 개발·운영·인프라·아키텍처를 모두 연결해주는 기술의 중심축이기 때문입니다. 서비스가 어떻게 만들어지고, 어떻게 배포되고, 어떻게 운영되며, 어떤 문제가 실제 환경에서 발생하는지를 가장 입체적으로 경험할 수 있는 분야이기도 합니다. 이런 관점에서 DevOps로 전환한 엔지니어들은 오히려 “제품이 실제로 살아 움직이는 전체 생명주기”를 경험할 수 있다는 점을 가장 큰 장점으로 꼽습니다.
반면, 소프트웨어 개발을 온전히 놓고 DevOps만 하는 것이 맞는가에 대한 고민도 충분히 현실적인 질문입니다. 다만 DevOps가 소프트웨어 개발과 완전히 분리된 영역은 아니라는 점을 강조하고 싶습니다. 좋은 DevOps 엔지니어는 자동화 파이프라인, 빌드 시스템, 배포 툴, 운영 플랫폼을 설계할 때 오히려 개발자보다 더 많은 코드를 작성하고 더 깊은 설계 역량을 요구받습니다. DevOps가 “개발을 포기하는 길”이라기보다, “개발을 더 넓은 맥락 속에서 바라보는 역할”에 가깝습니다. 개발 역량은 DevOps에서 오히려 강력한 경쟁력이 됩니다.
결정의 기준은 결국 세 가지에 수렴합니다.
개발을 통한 문제 해결이 더 즐거운가, 아니면 시스템 전체를 안정적으로 굴러가게 만드는 플랫폼적 사고가 더 즐거운가.
둘 중 무엇이 앞으로의 커리어에서 당신이 더 오래 즐기고 성장할 수 있는 방식인가.
그리고 DevOps가 지금의 시장 흐름에서 어떤 기회를 제공할 수 있는가.
만약 두 영역이 모두 흥미롭다면, 굳이 둘 중 하나를 완전히 포기할 필요도 없습니다. 많은 플랫폼 엔지니어는 “코딩하는 DevOps”, “개발자 경험(DevEx)을 만드는 엔지니어”, “제품 개발과 운영을 모두 이해하는 기술 중개자”로 자리 잡으며 오히려 더 독보적인 역할을 수행합니다.
8 Likes
안녕하세요…! 정말 인사이트 있는 글 감사드립니다. 저는 컴공으로 학부 졸업한 학생인데, 실제로 제가 나아가야할 길에 대해 도움을 받은 것 같습니다… 기준에 대해도 제시해주셔서 감사합니다!! 잘 고민해보겠습니다. 덕분에 많이 알아갑니다 
6 Likes
안녕하세요.
저는 시스템 개발로 시작해 프론트엔드와 백엔드를 거쳐, 쿠버스트로넛 인증을 취득한 뒤 현재는 DevOps 업무를 하고 있습니다.
개발은 ‘나무를 심는 것’을 좋아한다면,
DevOps는 ‘숲 전체를 바라보는 것’을 좋아한다면 잘 맞는 분야인 것 같아요.
(물론 개발자도 숲을 보지 않는다는 의미는 아닙니다!)
각 역할마다 나름의 재미가 있지만, 결국 가장 중요한 건 성장과 행복인 것 같아요.
6 Likes
아하 .. 시각이 다르군요 성장과 행복도 잊지 않겠습니다!! 감사합니다!!
4 Likes
권재환님 답변 감사합니다.
DevOps가 다루는 개발은 일반적인 애플리케이션 개발과 결이 조금 다르게 흘러갑니다. 기존 개발자가 서비스 기능을 구현하는 데 집중한다면, DevOps는 그 기능이 실제 환경에서 안정적으로 움직일 수 있도록 전체 구조를 설계하고, 운영과 배포 과정 자체를 코드화하는 방향으로 개발 역량을 확장하게 됩니다.
이 과정에서 필요한 기술이 꽤 구체적이고, 전통적인 소프트웨어 개발보다 적용 범위가 더 넓다는 점이 오히려 매력적입니다.
가장 먼저 필요한 부분은 자동화를 실제 코드로 구현하는 능력입니다. 단순한 스크립트 수준이 아니라, CI/CD 파이프라인을 하나의 제품처럼 설계하고, 빌드·보안 검사·테스트·배포·롤백까지 하나의 흐름으로 엮는 개발 역량이 필요합니다. GitHub Actions나 Jenkins, Tekton 같은 플랫폼을 거의 프로그래밍 언어처럼 다루게 되고, 반복되는 패턴을 모듈화해 재사용 가능한 구조로 만드는 능력도 자연스럽게 요구되죠.
운영을 코드로 옮기는 부분도 중요합니다. 예를 들어 Kubernetes 기반 환경에서는 단순 YAML 작성 수준을 넘어서 Helm, Kustomize, 혹은 직접 Operator나 Controller를 개발해야 하는 경우도 많습니다. 이때는 Go나 Python 같은 언어로 “운영 로직을 자동화하는 프로그램”을 짜는 셈이라, 개발자 경험이 매우 큰 강점으로 작용합니다.
여기에 Terraform이나 Pulumi 같은 IaC 도구로 인프라 자체를 코드화하는 능력이 더해지면 클러스터 생성과 네트워크 구성부터 모니터링 스택 설치까지 모든 과정을 하나의 리포지토리에서 관리할 수 있게 됩니다.
다음으로 관측성과 운영 메트릭을 다루는 개발 감각이 필요합니다. Prometheus, Grafana, Loki, OpenSearch 같은 스택을 직접 다루면서 알람 규칙을 조건에 맞게 만들거나, 서비스별 지표 수집 로직을 코드화하는 능력이 요구됩니다. 애플리케이션 개발에서는 “동작하는 기능”이 핵심이었다면, 여기서는 “시스템 전체가 어떻게 보이고, 어떤 문제를 드러내며, 어떻게 자동으로 대응할 수 있는가”가 개발의 주제가 됩니다.
요약하자면 DevOps가 하는 개발은 기능 구현이 아니라 “플랫폼을 만드는 개발”에 가깝습니다. 서비스가 어떻게 빌드되고, 어떤 환경에 배포되고, 어떤 방식으로 모니터링되고, 장애가 생기면 어떤 자동화가 작동해야 하는지까지 전체 생태계를 하나의 살아 있는 시스템으로 설계하는 과정이죠.
그래서 DevOps 경력이 쌓이면 자연스럽게 개발 역량도 확장되고, 문제를 다루는 스케일이 훨씬 넓어지는 경험을 하게 됩니다.
이런 기반 위에서 MLOps, LLMOps, AgentOps, AIOps 같은 분야로 넘어가면, 기존에 익힌 자동화·인프라·관측 기술이 그대로 재활용되며 확장됩니다. 모델 학습 파이프라인을 만들거나, LLM 서빙 구조를 자동화하고, 멀티 에이전트 시스템의 실행 환경을 설계하거나, 운영 문제를 AI가 스스로 판단하도록 만드는 개발로 이어지죠.
결국 DevOps에서의 개발 경험은 AI 운영 시대에 가장 자연스럽게 확장되는 경로라고 볼 수 있습니다.
그리고 이 부분이 중요한데, 결국 경로를 선택하는 기준은 기술이 아니라 기질, 기쁨의 방향, 삶에서 추구하는 목적에 더 가깝습니다.
어떤 사람은 복잡한 도메인 로직을 설계하거나 새로운 기능을 만드는 과정에서 큰 만족을 느끼고, 어떤 사람은 시스템 전체가 매끄럽게 흘러가는 구조를 만들어낼 때 가장 몰입하게 됩니다. 누군가는 하나의 제품을 깊게 파고드는 걸 좋아하고, 누군가는 여러 팀과 시스템이 얽힌 환경을 조율하며 전체 퍼즐을 맞추는 순간에 큰 보람을 느낍니다.
지금의 고민은 사실 기술 선택이 아니라, “내가 어떤 흐름에서 가장 오래 집중력을 유지할 수 있는가”, “어떤 유형의 문제를 풀 때 스스로 살아 있는 느낌을 받는가”, “다음 10년 동안 어떤 역할에서 성장의 기쁨을 느낄 수 있는가”에 가깝습니다.
기질과 삶의 목적이 기능 개발과 더 잘 맞을 수도 있고, 시스템과 플랫폼을 다루는 개발과 더 잘 맞을 수도 있습니다. 어느 쪽이든 옳고 그름이 있는 선택이 아니라, 앞으로의 시간을 어디에 두었을 때 자신의 성향이 가장 빛날지를 고르는 과정이라고 보는 편이 더 자연스럽습니다.
8 Likes
WoW ^^
마지막 부분은 모든 직무에 해당되는 이야기인 것 같네요.. 약간 울컥하고 갑니다 ㅠㅠ
2 Likes