왜 빠르게 개발하고 적용해야 할까?

왜 빠르게 개발하고 적용해야 할까?

한 번도 고민해 본 적 없는 질문이었다. 처음에 이 질문을 들었을 때 들었던 생각은 "잘해야 하니까?"였다. 빠른 문제 해결, 빠른 피드백이 곧 실력 있는 개발자의 기준이라고 생각했던 것 같다. 하지만 "빠르게 개발하고 적용해야 해!"라고 말하면서 "왜?"를 생각해 본 적이 없었던 것 같다. 항상 주어진 시간 내에 새로운 기능을 내기 위해 개발 속도에 무게를 두고 있어서 "빠르게 개발하고 빠르게 적용해야 한다"는 것을 당연하게 느꼈던 것 같다.

 

이처럼 생각했던 게 틀렸다거나 잘못되었다고 생각하지는 않는다. 개발해야 하는 서비스와 주어진 역할에 충실하다 보니 자연스럽게 이러한 생각을 가지고 있었던 것 같다. 하지만 "잘해야 하니까?"라는 추상적인 대답을 조금 더 구체적인 이유로 설명해 보고 싶었다.

 

뭐만 했다 하면 오류투성이에 각종 버그들은 고쳐지지고 않고 서비스는 계속 그대로라면 아무리 좋은 기획/마케팅이 뒷받침 된다고 해도 사용자는 그 서비스를 다시 이용하지 않는다. 즉 사용자의 이탈을 막기 위해, 더 많은 사용자 유입을 위해, 더 나은 서비스를 위해 결국 수익을 위해 빠른 개발과 적용은 필수라고 생각한다.

 

그러면 항상 빠르게 새로운 기능을 내기 위하는 것이 정답일까?

곰곰이 생각해 보면 항상 "빠르게 개발하고 적용해야 해"라고만 생각하지는 않았던 것 같다. 새로운 기능이 개발되었음에도, Staging 서버에서 충분한 검증을 거쳤음에도 운영 환경에 적용하는 것은 "빨리"가 아닌 "천천히"였다.

 

새로운 기능이 추가되었을 때 서버에 어떤 부하가 생길지 항상 예측해 보고 테스트해야 했다. 즉 시스템의 "안전성"이 최우선이었다.

 

개발과 운영의 좁혀지지 않는 간극

개발과 운영은 우선순위가 다르다. 그래서 "왜 빠르게 개발하고 적용해야 할까?"의 질문에는 정답이 없다고 생각한다. 이렇게 서로 무게를 두고 있는 부분이 달라서 생긴 개발과 운영의 사일로(Silo) 현상을 해결하고자 DevOps라는 방법론 및 문화에 대한 방향성이 제시되었다고 생각한다.

 

다음은 DevOps와 SRE(Site Reliability Engineering)에 대해 주관적인 생각을 빼서 정리해 보려고 한다. (하지만 주관적인 생각이 많이 들어갔다고 한다...)