데브옵스 엔지니어로 4년 일하고 있는데, 요즘 드는 생각은 개발자가 아닌 엔지니어 직군은 성과내기가 어렵다고 생각이 든다. 당연한 말일 수 있다. 서비스를 출시하기 위해 사업,기획,개발이 필수요소인데 엔지니어는 옵션이기 때문이다. 엔지니어가 옵션이라는 말은 기분 나쁘게 들릴 수 있지만 서비스가 있어야 엔지니어링이 필요하기 때문에, 아직까지 내 생각은 엔지니어는 옵션이다.
개발자와 엔지니어의 정의는 어렵지만 이 글에서 말하는 개발자는 프로그래밍을 통해 서비스를 만드는 사람을 말한다. 그리고 엔지니어는 개발자가 만든 서비스를 배포하고 서비스 성능을 향시키기 위한 서버 튜닝, 모니터링 시스템 구축 등 서비스 운영을 위해 일하는 사람을 말한다. 엔지니어는 아쉽지만 서비스가 성장하고 있거나 크지 않으면 없어도 된다. 서비스가 잘되야 엔지니어링을 할 수 있기 때문이다. 그리고 요즘 클라우드 기술이 잘 되어 있어 개발자가 엔지니어가 하는 일을 커버할 수 있다.
서비스 출시를 위해 사업,기획,개발은 무조건 필요하다. 어떤 사업을 정해야 할지 기획을 하고 기획을 해야 개발을 할 수 있기 때문이다. 따라서 규모가 큰 곳은 사업팀, 기획팀, 개발팀 서비스를 출시하고 개선하기 위해 항상 있는 팀이다.
사업팀, 기획팀, 개발팀은 서비스 반응에 따라 성과가 매겨진다. 서비스 반응이 안좋으면 성과가 낮거나 서비스 반응이 높으면 성과를 높게 받는다. 또는 서비스 반응이 없더라도 서비스 발전의 미래가 보인다면 좋은 성과를 받는다.
반면, 엔지니어 성과는 어떠할까? 눈에 보이지 않기 때문에 성과를 매기기도 애매하다. 그래서 아직 짦은 사회생활 경험한 내가 생각에는 엔지니어 성과는 대부분 보통이다. 잘해도 보통, 못해도 보통이다.
엔지니어 영향이 가장 주목을 받는 시기는 역설적이게도 서비스 성능이 떨어지거나 장애가 났을 때다. 2024년 7월에 주목받은 장애는 마이크로소프트 블루스크린이다. 보안업체인 크라우드스트라이크 제품 영향으로 마이크로소프트 블루스크린이 발생했다. 여기서 재밌는 점은 크라우드스트라이크 1장짜리 보고서이다. 1장짜리 보고서의 절반은 개선 할 내용이 있었는데 서비스 기능 개발내용은 없고 엔지니어에 관련된 내용만 있었다. 모니터링 시스템을 강화하고 테스트할 수 있는 환경을 강화하고 배포 시스템을 강화하겠다는 내용이 있었다.
이처럼 엔지니어의 영향을 사람 또는 회사가 느끼려면 장애가 나야된다고 생각한다. 그렇지 않으면 엔지니어들이 일하는지 티가 나지 않는다. 물론 일부로 장애가 나야된다는 뜻은 아니다. 의도하지 않게 장애가 났을 때 엔지니어 영향이 보인다는 의미이다.