📚 [Daily] DevOps 이여기 - SRE ?
Category: Daily | 📅 April 16, 2026
엊그제 일상 카테고리에 기록된 내용을 읽다보니 쓰기로 하고 까먹었던 부분이 있어 다급하게 써 봄.
SRE… 예전 기억을 더듬어 보면 “Devops 의 시대는 가고 SRE 의 시대가 온다 “ 라는 내용도 있어서 그때는 새로운 직군이 만들어 지는 줄 알았다.
예전 내 생각
SE > DevOps > SRE
내 구글 Signature 에도 SRE 라고 되어 있었던 적이 있다.
(SRE 의 ‘E’가 ‘Engineer’ 인 줄 알았던 1ㅅ)
사실 내 잘못이 없을 수 있다. 왜냐면 지금도 뭔가 개발자적인 내용으로 알려주는 사이트가 있는거 보면 ..ㅋ ( 예시, Reddit)
SRE 는 뭐하는 건가?
예전 내 생각을 보면 뭔가 시스템 엔지니어의 확장 영역으로 생각했던 만큼,
운영자가 개발자의 소스를 검증하고 고치는 시스템을 만들던가,
수작업을 통해 고치던가
하는 등의 개발자영역으로 더 접근하는 것으로 보면 될 것 같다.
물론, 이 개념은 요즘 AI Assistant 에서도 컨텍스트 엔지니어링 에 포함되어 있다. (컨텍스트 엔지니어링….. 이것도 써야겠네 ㅋㅋ)
SRE .. (Site Reliability Engineering) … 말 그대로 번역해보면 “사이트의 신뢰도를 높이는 기술” 인데..
사이트의 신뢰도를 높인다라는 의미는 ?
뭐긴 뭐겠나? 버그없고, 멱등성 보장되는 사이트겠지. 그리고 깔끔하고 군더더기 없는 소스 누가봐도 와~ 예쁘다 라고 정리된 소스
이런거 아니겠는가?
예전엔 이렇게 사이트를 만들었다.
- 요구사항 정리
- 기능정리
- 개발
- 2번 기능정리를 분석하지 않음
- 그냥 개발업체 맘대로 해석해서 만듦
- 운영
짧은 기간내에 만들어야 하니 검증은 커녕, 코드 리팩토링? 코딩 컨벤션? 없었던 시절.
저렇게 사이트를 만들고 나서 유지보수 업체가 바뀌면 유지보수를 맡은 업체는 기존 소스 분석에 시간이 걸리니 기존 소스위에 덧붙이는 방법으로 유지보수를 하게 되었고..
이렇게 1년이 지나고 2년이 지나고 .. 한 기능을 맡은 20여줄의 개발 소스는 예외처리 하고 , 없던 유효성 검사 로직 집어넣고 해서 200줄 300줄로 늘어나게 됨.
결국 가벼워야 하는 웹서비스는 무거운 완전군장 형태의 서비스가 되버렸다.
(요즘 대부분의 레거시가 이렇지 않다고 보기 어렵다 -_-;; )
그러니 SRE 에 혹할 수 밖에..
SRE 는 언제 쓰나?
코딩 규칙을 만들고, 그 규칙대로 만들어져 있는지 검증할때 씀. 매번 만들면 귀찮으니, 자동화 하는게 기본.
