brunch

You can make anything
by writing

C.S.Lewis

by 그날그날 Oct 08. 2018

엣시와 콘웨이 법칙 - 데브옵스 핸드북 읽기

#책읽은티내기 #데브옵스 핸드북 #콘웨이법칙 #02

"팀의 구성 방법은 우리가 제작하는 소프트웨어 뿐 아니라 아키텍처와 프로덕션 결과물에도 많은 영향을 미친다. 개발에서 운영으로의 신속한 흐름, 높은 품질과 뛰어난 고객 성과를 달성하기 위해 콘웨이의 법칙을 활용할 수 있도록 팀과 업무를 구성해야한다."

콘웨이 법칙

오늘 주요하게 이야기할 문장은 위와 같습니다. 바로 이어지는 문장을 살펴볼게요.

"만약, 팀과 업무의 구성이 잘못된다면, 팀이 안전하고 독립적으로 일하는 데 있어 콘웨이의 법칙이 방해가 될 것이다. 팀이 서로가 강하게 결합해 각 작업이 완료될 때까지 모두 대기해야 하며, 사소한 변경 사항들이 전체적으로 심각한 결과를 초래할 수도 있다."

콘웨이의 법칙이라는 단어가 몇 번 언급되었는데요, 핵심 내용은 다음과 같습니다.

"모든 시스템은 그 조직의 의사소통 구조와 동일하게 만들어진다."

이 문장을 바탕으로 앞의 인용을 다시 살펴볼까요?

"팀이 서로가 강하게 결합해 각 작업이 완료될 때까지 모두 대기한다. 사소한 변경 사항들이 전체적으로 심각한 결과를 초래한다."

어쩐지 익숙한 광경이 아닌가요?

엣시와 콘웨이 법칙

책에서는 콘웨이 법칙의 사례로 엣시Etsy를 언급합니다.

엣시는 2007년 Sprouter(이하 스프라우터)라는 일종의 프레임워크를 개발, 도입합니다. 그런데 스프라우터는 선한 의도와 다른 결과를 불러옵니다.

(스프라우터라는 프레임워크 혹은 아키텍처에 집중하지 마세요, 누가 개발자 아니랄까봐 ㅎㅎ)

"스프라우터는 프론트엔드 PHP 애플리케이션과 Postgres 데이터베이스 사이에 위치해 데이터베이스 액세스를 중앙 집중화하고, 데이터베이스의 실행을 애플리케이션 계층으로부터 숨긴다. 문제는 비즈니스 로직에 변경 사항이 추가될 때, 개발자와 데이터베이스 팀 간에 심각한 마찰이 발생한다는 점이다."

스프라우터에가 초래할 업무 구조의 변화를 살펴보는게 중요합니다.

"스프라우터는 거의 모든 새로운 사이트의 기능마다 DBA에게 새로운 저장 프로시저 작성을 요구했다. 결과적으로 개발자는 신규 기능 추가를 원할 때마다 DBA에게 도움을 요청해야 했다. 관료주의를 극복하기 위한 노력이 많이 필요한 경우도 종종 있었다."

상황은 점점 더 심해집니다.

"데이터베이스 저장 프로시저도 스프라우터와 밀접하게 결랍되어 있었다. 저장 프로시저가 변경될 때마다 스프라우터도 변경해야 했다. 그 결과 스프라우터는 점차 더 큰 단일 장애 지점이 됐다."

이러한 상황에 대해 엣시의 수석 엔지니어는 "모든 사항이 너무 긴밀하게 결합됐고, 높은 수준의 동기화가 필요했기 때문에 거의 모든 배포 시 작은 장애가 발생한다"고 설명합니다.

처음 스프라우터가 도입되었을 때는 개발팀과 DBA 2팀의 성과가 대단했을 것입니다. 점점 더 자신감이 붙어서 스프라우터를 성장시켰을 것입니다. 스프라우터가 곧 좋은 프로덕트라는 막연한 기대마저 품지 않았을까요? 콘웨이의 법칙은 바로 이 순간부터 흥미로워집니다. 좋은 프로덕트라는 기대가 전혀 다른 모습으로 우리에게 닥쳐올때 말입니다.

이제 스프라우터는 비즈니스 로직이 변경될 때 2개의 계층(개발팀과 DBA 두 팀의 기존 업무)만 변경 되는 것이 아니라 애플리케이션, 저장 프로시저, 스프라우터 3개의 계층이 변경되어야 합니다. 팀은 2팀에서 3팀으로 나뉩니다. 각 팀의 업무 조정, 우선 순위 설정 등으로 인해 프로덕트는 방향성을 잃고, 팀 별 우선순위는 맞지 않고, 대기 시간과 작업 시간은 늘어납니다. 정말 더 나은 프로덕트인가요?

스프라우터를 제거하라

스프라우터 문제는 2009년 엣시에 새롭게 합류하게된 새로운 CTO 차드 디커슨에 의해 차츰 해결됩니다.

차드 디커슨의 해결책은 심플합니다. 스프라우터를 제거하는 것입니다.

차드 디커슨은 데이터베이스의 비즈니스 로직을 스프라우터에서 애플리케이션 계층으로 옮기는 작업을 진행합니다. 이제 개발팀은 데이터베이스를 직접 호출합니다. 이제 비즈니스 로직을 변경하는데 필요한 팀은 세 팀이 아니고 한 팀입니다. 팀 사이의 문제는 줄어들고 업무 핑퐁은 사라집니다. 팀은 안정되고, 작업 생산성은 증가합니다. 다시 보다 나은 프로덕트가 손 끝으로 돌아옵니다.

스프라우터는 2001년 프로덕션에서 제거됩니다. 스프라우터가 개발되고, 제거되는 기간을 살펴보면 흥미로운 점을 발견할 수 있습니다.

스프라우터는 2007년에 도입되어 약 2년간 계속적으로 몸집을 불려나가며 추가-개발이 진행됩니다. 그리고 2009년 부터는 몸집을 축소시키며 점차 제거-개발이 진행됩니다. 결과적으로 제거-개발과정은 2011년에 마무리됩니다.

2년 동안 성장하며 문제가되는 시스템을 제거, 개선하는데 2년이나 걸린 것입니다. 문제와 해결의 기간이 1:1로 매칭되었다니 흥미롭지 않나요?

우리도 이런 문제가 있지만 몇개월이면 될꺼야? 라고 생각하고 있다면 다시 생각해봐야 할 것 같습니다. 문제의 해결은 언제나 예상보다 오래 걸리는 법입니다.

저는 여기에 한 가지 더 궁금한게 있는데, 아쉽게도 책에는 설명되어 있지 않습니다.

어째서 스프라우터 문제는 새롭게 합류한 CTO에 의해 해결된 것일까요? 왜 기존 내부 직원(수석 엔지니어)은 이 문제를 해결하지 못한 것일까요? 내부에서 해결할 수 없는 문제이기 때문에 외부 인원을 불러들인걸까요? 외부 인원을 불러들였더니 내부 문제를 들추어 해결한 것일까요? 이에 대해서는 각자 자신이 몸담은 조직에 대입해 보면 여러가지 흥미로운 이야기가 있을 듯 하네요.

조금 더 자세한 건 2부에서 만나요!

(이 부분은 완전 사견이니 안 읽으셔두 되요)

원래 오늘 저녁 9시부터 10시까지의 목표는 콘웨이 법칙이 뭔지 간단하게 용어만 정리하고 글 발행하기였는데요, 다시 한 번 책 읽다보니 너무 재미있어서 12시까지 늘어졌네요. 좀 졸립네요... 콘웨이 법칙을 조금 더 자세히 살펴보는 내용은 이번 주에 2부로 추가 발행할게요.

브런치 구독도 해주시고 '책읽은 티내기' 페이지도 좋아요 해주세요 : )