SRE와 개발자간 이상적인 협업을 위한 5가지 조언

InfoWorld
프로세스, 품질, 협업을 개선하기 위한 비판적인 피드백과 조언은 IT 실무자 모두에게 중요하다. 애자일 개발팀은 제품 소유자, 비즈니스 관계 관리자, 이해관계자, 고객, 그리고 현재 개발 및 지원 중인 애플리케이션의 최종 사용자로부터 이런 피드백을 받는 경우가 많다. 애플리케이션이 사용하기 어렵거나 동작 속도가 느리거나 워크플로우의 요구 사항을 해결하지 못하면 애자일팀은 이런 비판적인 피드백을 수용해 백로그 우선순위를 조정해야 한다.
 
© Getty Images Bank

개발, 테스트, 프로덕션 환경의 애플리케이션을 지원하는 운영팀의 피드백을 받는 것 역시 이에 못지않게 중요하다. 사이트 안정성 엔지니어(Site Reliability Engineers, SRE)는 프로덕션 애플리케이션의 안정성과 성능을 최종적으로 책임지는 사람으로, 개발팀이 참고할 권장 사항과 피드백을 제공하는 매우 중요한 직책이기도 하다.

개발자는 동료의 입장이 되어 SRE의 책임과 툴, 활동에 대해 생각해야 한다. 애플리케이션을 개선하는 방법과 개발 프로세스, 성능에 영향을 미치는 툴에 대한 현직 SRE의 조언을 모았다.
 

하나의 데브옵스팀으로 SRE와 협업하라

기술 부서에서 SRE는 리더의 지시에 따라 하나의 애자일 개발팀 또는 여러 팀과 함께 작업한다. 대체로 개발자와 개발팀의 수가 SRE보다 훨씬 더 많다. 이처럼 SRE는 여러 영역과 팀에 걸쳐 시간을 분배하는 경우가 일반적이므로, 비즈니스와 많은 애플리케이션의 기술적 세부 사항에 대해 잘 알아야 한다.

부서와 팀의 구조와 관계없이 개발자는 SRE를 같은 목표를 향해 움직이는 팀의 일부로 간주해야 한다. 빅판다(BigPanda)의 현장 CTO인 제이슨 워커는 "프로덕션 사고에 대처하고 성능 문제를 조사하는 데 대부분의 시간을 보내는 SRE와, 다음 버전의 신기능을 만드는 데 대부분의 시간을 보내는 개발자가 서로 목표를 일치시켜야 한다. SRE팀을 만들고 이들이 알아서 모든 문제에 대처하기를 기대하는 것으로는 부족하다. 개발자 역시 함께 프로세스, 툴셋, 마음가짐을 바꾸고 현대화해야 한다”라고 말했다.

이는 곧 실무에서 개발자가 비기능적 문제를 다루고, 어떤 유형의 문제에 대처해야 하는지 SRE의 피드백을 받아야 한다는 것을 의미한다. 필자는 개발팀에 릴리스 속도(velocity)의 30%를 기술 부채, 성능 문제, 보안 공백, 안정성 개선에 투입할 것을 권한다. 가장 중요한 것은 개발자와 테스트 엔지니어, SRE가 하나의 데브옵스팀으로 협업해 더 많은 기능을 더 빨리 출시해야 한다는 압박과 안정성, 성능, 보안을 보장하기 위해 필요한 작업 사이에서 균형을 잡아야 한다는 것이다.
 

인프라, 환경, 구성요소를 이해하라

개발자와 SRE가 파트너가 되면 각각 서로의 역할과 환경을 더 잘 이해해야 한다. 개발자에게 이 말은 애플리케이션 또는 서비스를 설치하거나 실행하는 인프라, 환경, 클라우드 서비스, 애플리케이션 구성요소를 이해하는 것을 의미한다.

무그소프트(Moogsoft)의 유럽, 중동 및 아프리카 지역 CTO이자 제품 전략 부사장인 윌 카펠리는 이에 대해 “개발팀에서 더 ‘유의’해야 한다. 경직된 하향식 개발 프로세스로 돌아가야 한다는 말이 아니라, 개발팀이 프로덕션 환경으로 릴리스하는 구성요소의 동작을 끊임없이 예측하고 관찰하고 대응해야 한다는 것이다. 이 말은 다시 구성요소에서 생성하는 각종 지표와 로그, 트레이스에 적극적으로 AI를 적용해야 한다는 의미이기도 하다”라고 말했다.

이어 "많은 개발팀이 마이크로서비스를 개발하고 테스트를 자동화하고 CI/CD(지속적 통합/지속적 배포)를 활용하고 코드형 인프라로 런타임 환경을 구성하고 있다. 그러나 여전히 개발자는 환경을 이해하고 여러 가지 유형의 문제를 예상해야 한다"라고 덧붙였다.
 

코드와 로그, 메시지, 예외 등을 이해할 수 있도록 만들어라

또한 개발자는 SRE팀이 애플리케이션, 서비스, 개발 환경을 이해하도록 도와야 한다. 프로덕션 환경에서 중대한 사고가 발생하면 SRE는 사고 이전과 사고 도중의 모든 모니터링 알림, 로그 메시지, 예외를 검토해야 한다. 이들의 목표는 신속하게 서비스를 복원해 기업과 최종 사용자에게 미치는 영향을 최소화하고 근본 원인을 분석하는 것이다.

따라서 개발자가 이해하기 쉬운 로그 메시지, 예외 또는 코드 주석을 제공하지 않으면 이런 작업은 그만큼 더 어렵게 된다. 빅판다의 워커 역시 "개발자가 다른 사람에게 앱을 전달할 때는 이 앱을 모니터링하는 데 무엇이 필요한지 함께 제공해야 한다. 그렇지 않으면 SRE에게 오류 로그만 전달할 뿐 그 의미는 전달하지 못할 수 있다”라고 말했다.
 

안정성, 성능 및 보안에 영향을 미치는 요소를 명확히하라

한 걸음 더 나아가서, 개발 과정에서 SRE와 협업하는 최선의 방법을 살펴보자. SRE 대비 개발자의 비율이 높은 경우 보통 스프린트에 예정되거나 현재 활성화된 애자일 사용자 스토리의 수도 많기 마련이다. 이런 경우 SRE가 모든 요구사항을 읽고 각각이 가진 운영 측면의 위험을 평가하리라 기대하기는 어렵다.

이런 상황에서는 개발팀과 애플리케이션 아키텍트가 위험도 높은 사용자 스토리와 결함을 정의하고 표시하고 더 적극적으로 추정해 SRE를 도울 수 있다. 필자는 다음과 같은 단계가 포함된 프로세스를 구축했다.
 
  • 아키텍트는 개발팀이 어느 유형의 구현에 대해 안정성, 성능, 보안 플래그를 표시해야 하는지 이해하는 데 도움이 되는 기준을 정의해야 한다.
  • 제품 소유자와 애자일 기술 리드는 이러한 위험 기준을 충족하는 스토리에 레이블을 붙여야 한다. 이슈와 카드에 레이블을 붙이는 작업은 지라 소프트웨어(Jira Software) 및 애저 데브옵스와 같은 애자일 툴로 간단히 할 수 있다. 이렇게 하면 SRE, 아키텍트, 정보보안 담당자가 무엇을 검토해야 할지 더 간단히 파악할 수 있다.
  • 개발팀은 파악된 위험을 기준으로 비기능적 수락 기준을 반영해 애자일 추정을 조정해야 한다.
  • 개발자는 구현 및 위험 유형에 적합한 충분한 예외 처리, 테스트 및 모니터링을 구현해야 한다.
  • 스크럼 마스터는 SRE, 아키텍트 또는 정보보안 담당자가 구현된 위험 교정 수단을 평가할 수 있도록 관련 스프린트 리뷰 참여를 독려해야 한다.

이러한 단계는 비즈니스 목표 달성, 애플리케이션 안정성 보장, 그리고 많은 IT 부서의 가용 인력 한계 사이에서 절충한 결과다.
 

시프트-레프트 테스트를 시행하고 애플리케이션 모니터링에 대해 투자하라

개발 위험을 인식하고 스토리 수준에서 조정 수단을 구현하는 것은 전체적인 위험을 낮추는 효과적인 전략이다. 단, 이 전략은 테스트 대부분을 자동화하고 개발자와 테스트 자동화 엔지니어를 포함한 애자일 팀이 CI/CD 파이프라인에서 적절한 수준의 지속적 테스트를 구현하는 전체적인 시프트-레프트 테스트 개념의 일부가 돼야 한다.

그러나 팬데믹과 원격 근무가 확산하면서 이 수준에서 테스트하기 더 복잡해졌다. 코로나19가 모바일 QA에 미치는 영향에 관한 코비튼(Kobiton)의 최신 설문 결과, 응답자의 55%는 원격 작업 문화에 대한 투자를 언급했으며 50%는 IT 부서가 원격 테스트팀을 운영할 수 있는 툴 도입을 검토해야 한다고 답했다. 또한 원격 근무는 애자일 개발에 영향을 미치며, 데브옵스 문화와 방식을 채택하는 분산 팀은 협업 방식도 그에 맞춰 조정해야 한다.

애자일 개발의 시프트-레프트 테스트와 보안 수단 구현이 최선이지만, 애플리케이션 모니터를 구현하고 빅판다나 무그소프트와 같은 AI옵스 솔루션을 구축하려면 개발팀 지원도 필요하다. 이러한 시스템을 구축하면, 개발팀이 테스트하는 '알려진 세계'와 프로덕션 환경에 영향을 미치는 '알려지지 않은 세계'의 간극을 줄일 수 있다.

정리하면 개발팀은 SRE, 그리고 다른 IT 운영 담당자의 피드백을 충분히 고려해야 한다. 운영 문제가 적을수록 모두가 기능을 구현하고 최종 사용자의 요구를 충족하고 새로운 기술을 접하는 데 더 집중할 수 있다. editor@itworld.co.kr