29CM 기술블로그 - Medium

시작에 앞서
22년 9월 즈음에 The Delivery Hero Reliability Manifest 라는 문서를 우연히 읽게 되었다. 이 문서에는 서비스를 개발하고 운영하는 팀의 원칙과 이를 위한 세세한 가이드가 적혀있었는데, 해당 문서를 읽고 난 이후에는 그 동안 내가 가지고 있었던 막연한 불안감이 무엇이었는지를 명확히 알게 되었다.
서비스가 지속적으로 성장하기 위해서는 장기적인 관점에서 시스템이 갖춰야하는 구조와 팀이 추구하는 가치를 명문화하여 모든 구성원이 이를 높은 수준으로 이해하고 있어야 하는데 지금까지는 이를 위한 고민과 투자를 충분히 하지 못했었고, 서비스의 규모가 커지고 그에 맞게 팀의 규모도 커져가는 상황에서 팀의 방향성을 명확하게 정의하지 않았던 것이 내 스스로를 힘들게 했던 것 같다. 물론 20년 9월부터 29CM 의 MSA 아키텍처 로드맵이라는 제목으로 문서를 작성하고 팀 내에 공유한 적은 있지만, 아키텍처와 규약을 넘어서 팀이 추구하는 목표와 일하는 방식, 장기 로드맵에 대한 명문화된 문서는 존재하지 않았던 상황이다.
Architecture Manifesto?
Architecture Manifesto 는 이러한 문제 의식을 기반으로 만들어진 문서이다. 본 문서에는 지속적으로 성장하는 시스템을 구축하고 운영하는데 필요로 하는 다양한 요소를 담았는데, 크게 보면 서비스의 구성과 동작 원리, 시스템 간의 관계를 표현하는 1) 소프트웨어 아키텍처와 팀이 추구하는 목표와 의사 결정의 기준을 제시하는 2) 팀 운영 원칙이 담겨 있다.
오늘은 29CM 의 시스템과 엔지니어링 팀이 지속적으로 성장하기 위해 꼭 필요했던 29CM 의 Architecture Manifesto 의 일부 영역을 소개하고자 한다. (29CM 의 Architecture 가 추구하는 목표) 
이 글을 통해 시스템과 팀이 커져가는 상황에서 남모를 고민을 하는 개발 리더 분들에게 작은 위로와 도움이 되었으면 한다.
29CM 의 Architecture 가 추구하는 목표
1. Impact
Impact 는 “29CM 의 Architecture 는 비즈니스 가치가 큰 서비스를 빠르게 출시할 수 있는 서비스 구조를 가져야 한다” 는 의미이다.
고객이 원하는 기능을 지속적이면서 빠르게 출시할 수 있는 서비스 구조를 만들고 유지해야만 시장 경쟁에서 살아남을 수 있다. 이를 이루기 위한 과정은 쉽지 않겠지만 아키텍처에 대한 평가는 결국 고객 가치를 얼마나 크고 빠르게 만들어낼 수 있는가로 결정될 수 밖에 없다.
1–1. Impact 에 대한 생각
기술적으로 아무리 뛰어난 서비스를 만들더라도 그것이 고객에게 만족을 줄 수 있는 것이 아니라면 그 서비스는 언젠가는 죽게 된다. 실제로 고객을 생각하지 않고 자기만족에만 빠진 기술 혁신 서비스가 고객에게 외면을 받았던 사례는 역사적으로 정말 많다. (좀 더 지켜봐야겠지만 요즘에는 메타버스가 그러한 사례가 되지 않을까 생각한다)
내가 정말 좋아하는 요리하시는 방송인 두 분이 있는데 그 분들은 백종원님, 이연복님이다. 예전에 두 분의 장사하시는 태도가 완전히 동일하다면서 누군가가 올린 방송 캡쳐본을 우연히 본 적이 있는데, 나도 그 캡쳐본을 보면서 감동했던 적이 있다.
이 분들은 모두 손님의 입장에서 생각하고 매 순간 손님이 원하는 것을 만들어내기 위해 노력하는 것을 볼 수 있다. 손님이 원한다면 그 날 준비했던 메뉴조차도 다른 메뉴로 바꾸어버리고, 그것도 모자라 그 음식을 직접 먹어보고 손님처럼 생각하면서 본인의 음식을 살핀다. 이는 모두 손님을 위한 생각이자 행동이다.
고객들은 우리가 개발하고 운영하는 서비스에서 사용된 개발 언어와 프레임워크가 무엇인지는 관심이 없다. 서비스에 적용된 기술이 요즘 유행하는 기술인지 아닌지도 전혀 관심이 없다. 고객들은 그저 해당 서비스를 통해서 자신들이 얻을 수 있는 가치가 무엇인지, 그 가치가 내게 필요한 것인지, 내가 만족할 수 있는지만 생각한다. 
그리고 고객의 선택을 받지 못하는 서비스는 언젠가는 죽게 된다.
29CM 의 서비스와 아키텍처도 이와 같다고 생각한다. 29CM 는 고객의 가치를 만들기 위해 존재해야 하고 항상 고객에 집중해야 한다. 높아지는 고객의 눈높이에 맞춰서 다양한 기능을 크고 빠르게 만들 수 있는 서비스 구조를 가져야 한다.
1–2. Impact 를 위한 24년 이후의 계획
지금까지 29CM 가 Impact 를 추구하기 위해 선택했던 기술 아키텍처는 마이크로서비스 전환으로 볼 수 있다. (마이크로서비스 전환을 통해 29CM 가 얻었던 다양한 이득은 다음의 영상 에서 확인할 수 있다)
그리고 24년 이후의 Impact 관점에서 진행할 기술 아젠다는 크게 3가지이고, 이는 다음과 같다. (키워드만 제시하고 각 항목별 상세한 설명은 생략한다)
EDA & Event Streaming
실시간 이벤트 파이프라인
실시간 추천
이는 기존의 아키텍처에서는 대응하기 어려웠던 고객의 다양한 요구사항을 빠르게 처리하면서도, 기존 시스템이 제공하는 가치를 크게 뛰어넘기 위해 필요하다고 생각하는 것들이다.
29CM 는 고객이 필요로 하고 고객에게 큰 가치를 줄 수 있는 다양한 기능과 기술을 만들어갈 예정이다.
2. Reliability
Reliability 는 “29CM Architecture 는 대량의 트래픽을 안정적으로 처리하면서도 시스템의 장애나 버그가 발생하지 않는 서비스 구조를 가져야 한다.” 는 의미이다.
29CM 의 성장 속도를 생각할 때 급격하게 증가하는 트래픽을 온전히 처리하면서도 서비스의 안정성을 높은 수준으로 유지하는 것은 쉽지 않은 도전이다. 하지만 서비스의 안정성이 떨어져서 장애가 빈번하게 발생한다면 고객의 이탈은 필연적으로 발생할 수 밖에 없고, 이는 기업 경쟁력의 약화로 이어지게 된다. 고객 만족을 위한 신규 기능 런칭만큼 서비스의 안정성도 높은 수준으로 유지되어야 한다.
2–1. Reliability 에 대한 생각
가끔 농담처럼 말하지만 서비스에 장애가 발생하지 않게 하는 가장 확실한 방법은 코드 배포와 같은 서비스의 변화를 일으키지 않는 것이다. 장애라는 것은 결국 정상 상태의 서비스에서 특정한 변화가 추가되었을 때 발생하는 것인데, 코드 배포만큼 서비스에 큰 변화를 주는 것은 없기 때문이다. 덤으로 고객의 트래픽을 크게 증가시키는 대형 프로모션과 같은 위험한 실행도 하지 않는 것이 장애 예방에 도움이 된다.
하지만 29CM 는 장애 예방을 위한 중요한(?) 원칙을 어기고 고객을 위한 코드 배포와 프로모션을 지속적으로 실행하고 있다. 29CM 에서는 코드 배포 횟수가 월 기준으로 200 회 정도 되고, 많을 때에는 500 회 이상 진행된 적도 있다. 그러면서도 SLO Level 을 99.85% 이하로 내려가지 않도록 매번 관리하고 있다. (이 수치는 6개월에 6시간 30분 이하의 장애만을 허용한다는 것을 의미한다)
서비스 안정성과 장애 대응에 대해서 이야기할 수 있는 주제가 많지만, 이러한 내용을 한 마디로 정리해본다면 서비스 안정성을 올리는 과정은 Single Point Of Failure (이하 SPOF) 구조를 점진적으로 줄여가는 것, 특정 영역의 장애가 전체 장애로 이어지지 않도록 하는 것 이라고 생각한다.
SPOF 는 해당 지점에 장애가 발생했을 때 전체 서비스의 장애로 이어지는 지점을 말한다. 우리는 이러한 SPOF 구간을 줄이기 위해 Load Balancer 와 같은 기술을 통해 여러 대의 인스턴스에 부하를 분산시키기도 하고, 마스터 데이터베이스에 Replication 을 걸어서 혹시 모를 데이터베이스 장애를 대비하기도 한다.
마이크로서비스에서는 특정 서비스의 장애가 다른 서비스의 장애로 전파될 가능성이 크다. 동기식 API 호출에서 원격 호출 응답에 대한 timeout 설정을 누락하여 응답 대기 시간이 무한대로 설정되어 있는 경우, 장애로 인하여 원격 호출의 응답이 돌아오지 않을 때 이를 호출하는 서비스들의 요청 쓰레드가 block 되는 상황이 이어지고, 이는 결국 서비스 전체의 장애로 이어지게 된다.
서비스 안정성을 올리기 위한 다양한 실행 요소가 있겠지만, 서비스의 SPOF 구간을 줄여가는 것과 특정 서비스에서의 장애가 전체 서비스의 장애로 전파되지 않도록 하는 것을 주요한 원칙으로 삼고 실행하는 것이 중요하다고 본다.
2–2. Reliability 를 위한 24년 이후의 계획
24년 이후의 Reliability 관점에서 진행할 기술 아젠다는 크게 3가지이고, 이는 다음과 같다.
서비스군별 데이터베이스 분리
카나리 배포 구조 적용
레거시 아키텍처 제거
이 중에서 카나리 배포만 짧게 설명한다면 다음과 같다.
카나리 배포는 신규 feature 를 배포할 때, 배포 직후에는 신규 feature 에 약간의 트래픽만 넣고, 이후 안정성이 검증되면 트래픽을 점진적으로 늘려가는 배포 방식을 말한다.
카나리 배포는 신규 feature 안에 버그가 숨어있더라도 아주 일부의 트래픽만 이슈를 겪을 것이기 때문에, 신규 feature 를 한 번에 전체 배포하는 방식보다는 서비스의 안정성을 유지하는데 도움이 된다. 그리고 feature 배포를 진행하는 개발자들에게도 심리적인 안정감을 제공할 수 있는 장치가 된다.
24년 1월의 29CM 는 SLO 99.85% 를 넘어 99.915% 를 유지하고 있고, 고객의 수와 서비스의 규모가 커지고 있는만큼 해당 목표 수치도 점진적으로 올려가면서 서비스를 운영할 생각이다.
3. Productivity
Productivity 는 “29CM 는 엔지니어링 구성원의 확장이 팀 전체의 생산성으로 이어지는 업무 환경을 가져야 한다” 는 의미이다.
성숙한 팀 문화와 환경이 갖춰진 엔지니어링 팀은 신규 구성원의 합류가 곧장 팀 전체의 생산성 향상으로 이어질 수 있다. 그렇기 때문에 팀의 확장과 변화 과정에서도 팀 전체의 생산성을 높은 수준으로 유지할 수 있는 팀 문화와 업무 환경을 만들고 이를 계속 유지해야 한다. 이를 위해서는 서비스의 Architecture 와 조직 구조, 커뮤니케이션 방식과 소프트웨어 도구, 팀의 목표 설정과 협업 방식 등과 같은 다양한 요소를 고려해야 한다.
3–1. Productivity 에 대한 생각
엔지니어링 팀이 서비스를 설계하고, 개발하고, 운영할 수 있는 역량의 총합을 엔지니어링 팀 전체의 역량이라고 할 때, 이를 단순하게 공식화하면 다음과 같다.
팀 전체 역량 = 구성원의 평균 역량 * 구성원의 수
이렇게 볼 때 팀 전체의 역량을 올리는 방법은 구성원의 역량을 올리거나 구성원의 수를 늘리는 것이다. 이 중에서 구성원의 수를 늘리는 방법을 한번 생각해봤으면 한다.
사실 단순하게 구성원의 수가 늘어난다고 해서 해당 팀 전체의 역량이 빠르게 올라가지는 않는다. 새로운 구성원이 새롭게 합류한 팀에서 적응할 시간이 필요하고, 기존의 다른 구성원과의 합을 맞추는 시간도 필요하기 때문이다. 그리고 구성원의 수가 늘어날수록 의사소통 비용이 증가하고 관리포인트도 증가하기 때문에 팀 전체 역량이 기대만큼 늘어나지 않을 수 있다. 즉, 팀 전체 역량 공식은 아래와 같이 약간의 수정이 필요하다고 본다.
팀 전체 역량 = 구성원의 평균 역량 * 구성원의 수 * 팀 생산성 수준
구성원이 늘어난만큼 역량이 증가하는 팀이라면 팀 생산성 수준은 1 이 될 것이고, 팀 생산성 구조가 잘 잡혀있는 팀이라면 1 이상의 값이 될 수도 있다. 반대로 팀 생산성 구조가 잘 잡혀있지 않으면 1 보다 작은 값의 팀 생산성을 가질 수도 있다고 본다. 중요한 것은 팀의 생산성을 높게 유지할 수 있는 팀 구조와 의사 소통 방식, 업무 방식을 잘 정의하고 이에 맞게 팀을 운영해야 한다는 것이다.
팀 토폴로지 라는 책은 팀 구조를 최적화하고 구성원들의 자율성과 몰입을 높은 수준으로 유지하는데 도움이 되는 내용을 잘 전달하는 책이라고 생각한다.
3–2. Productivity 를 위한 24년 이후의 계획
지금까지 29CM 가 Productivity 를 추구하기 위해 선택했던 제품팀 구조는 스쿼드라는 목적 조직을 중심으로 한 제품 개발과 운영이었다. 이는 고객이 필요로 하는 도메인을 중심으로 다양한 직무로 구성된 Cross Functional Team 을 만들고, 그 팀 안에서 요구사항 정의와 제품 개발, 서비스 운영을 독립적으로 실행하는 방식을 말한다. 그리고 각 스쿼드의 업무 효율을 올리고 시스템 전체에서 필요로 하는 기능 개발과 운영을 위한 Platform Team 을 별도로 두어 스쿼드에서 커버하기 어려운 영역을 전담하도록 했다. 
이러한 팀 구조를 가져가게 되면 구성원들에게 높은 책임과 권한이 부여되기 때문에 팀 내에서 빠른 실행과 의사결정이 가능하게 되고, 길게 보면 팀 단위의 역량이 향상되는 효과를 얻게 된다.
24년 이후의 Productivity 관점에서 진행할 목표 일감은 상당히 많지만, 그 중 3가지를 고른다면 아래와 같다.
표준 구현 가이드 고도화 & 정착
구조화된 로그 수집 체계 구축
개발자 포털 구축
이 중에서 표준 구현 가이드 고도화 & 정착에 대해 짧게 설명한다면 다음과 같다.
표준 구현 가이드는 개발자들이 지켜야 하는 코드 구현에 대한 원칙과 상세한 구현 방안을 정리한 문서이다. 이러한 문서는 아직 백엔드 파트에만 존재하지만 24년 이후에는 영역을 넓혀 프론트엔드와 모바일 파트에서도 정리해볼 예정이다.
사실 팀 레벨로 표준 구현 가이드를 만들고 이를 높은 수준으로 지켜가게끔 하는 것이 과연 맞는 실행인지에 대한 고민을 했었던 적이 있다. 자칫 개발자들의 자율성과 창의성을 해치는 실행이 될 수도 있고, 표준 구현 가이드에서 제시하는 방법 말고도 더 나은 구현 방법이 계속 나올 수도 있다고 생각했기 때문이다. 그러나 점점 늘어나는 개발 구성원들을 생각할 때, 또 일관되지 않은 개발 방식으로 구현된 프로젝트의 수가 늘어날 때의 이슈를 생각할 때, 표준 구현 가이드를 만들고 지키게 하는 것이 맞지 않을까 라는 생각도 하게 되었다.
이후 22년 5월에 발간된 구글 엔지니어는 이렇게 일한다 라는 책을 읽고서 그간의 고민은 모두 내려놓을 수 있게 되었다. 아래 문장은 해당 책 내용의 일부분이다.
“코드베이스의 스타일과 기준이 일관되면 코드를 작성하는 엔지니어와 읽는 이들은 ‘어떻게’ 표현하느냐가 아닌 ‘무엇을’ 수행하느냐에 집중할 수 있습니다.” (8장 스타일 가이드와 규칙, 211p)
맞는 말이다. 표준이 정해지고 모두가 이를 지키기 위해 노력하면 형식이 아닌 문제 해결에 좀 더 집중할 수 있게 되고, 일관성이 가져다 주는 규모의 확장을 이룰 수도 있게 된다. 인력이 늘어날 때에도 비교적 빠르게 온보딩이 가능하고, 도구의 도움을 받기도 쉬워진다.
반대로 60명 이상의 개발자가 제각각의 스타일대로 서비스를 구현한다면? 20개가 넘는 프로젝트마다 개발 방식과 구현 원칙이 제각각이라면? 심지어 하나의 프로젝트 내에서도 구간별로 구현 원칙이 다르다면? 당연하겠지만 이런 환경에서 코드를 구현하고 운영해야 하는 개발자들은 높은 생산성을 가져가기 어려울 것이다.
코드와 관련된 작업에서 쓰기에 투자되는 시간은 20% 밖에 되지 않는다. 나머지 80% 는 이미 작성된 코드를 읽고 분석하는 데 쓰이기 마련이다. 그만큼 코드에서의 가독성은 중요하고, 가독성은 일관된 구현 원칙에서 만들어진다.
앞으로 29CM 는?
29CM 는 고객에게 새로운 취향을 제안하고 감도 높은 브랜드를 소개한다. 이를 통해 다른 이커머스 플랫폼에서는 제공하지 않는 독특한 고객 만족을 제시하고, 이러한 29CM 을 사랑하는 고객분들이 점점 늘어나고 있다. 그리고 이러한 고객 만족을 위해 다른 팀과 더불어 엔지니어링 팀이 존재한다고 생각한다.
뛰어나고 헌신적인 동료들의 도움으로 지금까지는 제법 잘해왔다고 생각하지만, 과거에 잘해왔다는 것이 이후에도 잘할 것이라는 것을 보장하지는 않는다. 점점 커지는 고객의 기대치, 다양한 요구사항, 늘어나는 트래픽을 충분히 감당할 수 있는 29CM 의 서비스와 팀을 만들기 위해서는 팀 전체가 일치된 목표를 가지고 일관된 의사 결정을 기준 삼아 최대한 주도적으로 일할 수 있는 환경을 만들어야 한다고 생각한다. 그리고 이번에 소개했던 Architecture Manifesto 를 함께 다듬고 보완해가면서 다양한 도전의 상황을 해결해가려고 한다.
29CM 화이팅 ^^
29CM Architecture Manifesto was originally published in 29CM TEAM on Medium, where people are continuing the conversation by highlighting and responding to this story.

29CM Architecture Manifesto

댓글