쉽게 설명하는 29CM Architecture Manifesto

💡 영상

쉽게 설명하는 29CM Architecture Manifesto

세미나 내용

빠른 성장, 그러나…

• 지금까지 잘해왔다는 것이 이후에도 잘할 것이라는 것을 보장하는 것은 아니다. 지금까지의 결과는 과거 시점과 과거 실행에 따른 결과일 뿐이고, 우리가 앞으로 어떻게 행동하고 어떻게 실행 했을때 좋은 결과를 낼 수 있는 가를 보장하는 것이 아니다.
• 이제는 고객의 기대치, 다양한 요구사항, 늘어나는 트래픽에 맞는 새로운 구조가 필요하다.
• 특정 시점에서는 다음 단계의 성장을 지원하기 위해 매우 근본적인 것들을 해야 한다.
  • 기존 트래픽, 성능 30%, 60% 향상 시키는건 기존 설계에서 가능하다. 그러나 트래픽이 몇배로 되는걸 버티기 위해서 개발방식, 구조등을 바꿔야 한다.

3주년의 잠 못 이루는 밤

• 더 빠르게, 더 정확하게 개발하려면?
  • 일치된 목표, 일치된 의사 결정의 기준으로 최대한 주도적으로 일하는 팀 만들기
• 29CM Architecture Manifesto의 필요성
  • Software Architecture + 추가하는 목표와 의사 결정의 기준을 제시

29CM Architecture Manifesto가 추구하는 목표

Impact

• 비즈니스 가치가 큰 서비스를 빠르게 출시할 수 있는 서비스 구조를 가져야 한다는 것 = 지속적으로 고객 가치를 만들어 낸다는 것
• 고객은 관심 없다. 오직 본인의 관심사 말고는
• 기술을 관심이 있는게 아니라, 고객이 관심이 있는 건 29cm에 들어왔을때 콘텐츠 상품이 무엇인지, 좋은 가격으로 상품을 자기에게 줄수 있는지를 원한다.
• 우리의 서비스는 고객이 원하는 것을 지속적으로 만들어 낼수 있는 구조를 만드는것이 중요하다.
• 우리는 오로지 고객을 위해 존재한다.
• 외부에 신기술이 나오면 신나지만, 중요한건 고객이 원하는지 좋아하는지, 고객이 경험을 발전시킬수 있는지를 체크해야 한다.
• 고객한테 중요한 개발을 할 수 잇고 운영할 수 있어야 하는게 목표가 되어야 한다고 생각한다.
• 고객이 원하는 것을 빠르게 그래야 우리가 살아남는다.
• Impact를 위한 기술
  • 지금까지는 microservice를 활용하여 Impact를 이루어왔다
  • 앞으로는
    • EDA & Event Streaming 기반으로 통신 구조로 변경하기.
    • 실시간 이벤트 파이프라인
    • 실시간 추천엔진

Reliabililty

• 대량의 트래픽을 안정적으로 처리 하면서도 시스템의 장애나 버그가 발생하지 않는 서비스 구조를 가져야 한다는 것 = 고객이 원하는 기능은 계속 만들면서도 서비스의 안정성은 높게 유지 해야 한다는 것
• 고객은 냉정하다. 떠나면 그만.
• 고객 Voc에서 강한 의견을 주는 분들이 있다. 그런 분들은 고맙다. 그러지 않은 분들은 말도 안하고 앱지우고 나간다. 그냥 떠나는 사람들이 무섭다. 서버 장애가 많이 발생하고 길게 발생하면 사람들은 다 떠날꺼다.
• 고객이 원하는 기능은 계속 만들고 장애가 발생하면 안된다. 라고 봐야 한다.
• 안정성을 높인다는 것은
  • SPOF(Single Point Of Failure)를 지속적으로 제거하는 것
  • 특정 영역의 장애가 전체 장애로 이어지지 않게 하는 것
• 앞으로는
  • 서비스군별 데이터베이스 분리
  • 카나리 배포 구조 구현
    • 신규 feature를 배포 시, 약간의 트래픽만 전달하여 안정성을 검증하는 방식이다.
    • 안정성을 검증되면 전체 트래픽을 신규 feature로 간다.
    • 이러한 구조가 완성되면 Core 서비스 배포가 안정화가 되며, 개발자들의 심리적 안정감이 확보가 된다.

Productivity

• 팀의 확장과 변화에서도 팀 전체의 생산성을 높은 수준으로 유지하고 확장 가능한 팀 문화와 업무 환경을 만들어야 한다는 것 = 팀원의 추가, 팀의 변화 과정에서도 언제나 높은 생산성을 유지해야 한다는 것
• 동료가 늘어나도 팀 역량은 늘어나지 않을 수 있다. 늘어난만큼 의사 소통 비용과 비효율은 증가한다.
• (제가 생각하는) 팀 역량 공식은
  • 팀 전체 역량(C) = 구성원의 평균 역랑(A) * 구성원의 수(B) * 팀 생산성 (D)
  • 팀 생산성이란 우리가 일하는 방식, 의사소통 하나의 업무를 할 때 여기저기 모든 팀에 가서 소통하는 것이 힘들다. 그걸 해결 하기 위해 채널을 만드는 것이다. 혹은 케미, 시너지, 팀웍 모두 여기에 포함된다. 팀 생산성은 1 이하가 될수도 있다. 그래서 구성원의 수가 늘어난다고 해서 배로 늘어나는게 아니다. 즉, 팀 생산성이 낮으면 팀 전체 역량이 낮아진다.
• 앞으로는
  • 표준 구현 가이드 고도화 & 정책
    • 60명 이상의 개발자가 제각각의 스타일대로 서비스를 구현한다면, 프로젝트마다 개발 방식과 구현 원칙이 제각각이라면, 심지어 하나의 프로젝트 내에서도 구간별로 구현 원칙이 다르다면, 높은 생산성을 기대할 수 없다.
    • 팀 생산성을 위해서는 지켜야 한다.
      • 도메인의 표현, 패키지 구조, 의존관계 방향성, 네이밍, DIP 등…
    • 표준 구현 가이드에서 강조하는 것은 가독성!
      • 좋은 코드는 읽기 쉬워야 한다.
      • 코드의 쓰기 작업은 20%, 읽기 작업은 80%
      • 처음 보는 개발자도 이해하기 쉬워야 한다
      • 심지어 개발자가 아니어도 이해할 수 있어야 한다.
    • 대표적인 두 가지 오해
      • 표준 구현을 강제하면 개발자의 창의성이 제한된다.
        • 창의성을 원하는 개발자는 형식적인것들이 정해진다면 비지니스 고객 가치를 위해 개발하는 것에 시간을 쓰길 원한다.
      • 시간이 충분히 주어질수록 품질 높은 코드가 만들어진다.
  • 구조화된 로그 수집 체계 구축
  • 개발자 포털 구축

마무리

마지막 질문

여기까지 모두 들었을때 마지막 질문을 남겨본다.

하드코딩은 나쁜 것인가?

후기

약 MAU가 200만이 넘는 서비스의 한해의 목표를 알수 있었던 세미나의 영상이였습니다. 이정도 규모의 엔지니어링의 목표를 들어본 경험은 없었지만, 듣고 난 뒤에 내가 생각하는 개발자의 방향과 비슷하다고 생각했다.

가장 인상깊은 문구는 바로 고객이 원하는 것을 빠르게 그래야 우리가 살아남는다. 이 문구이다. 결국 내가 지금까지 3년 넘게 일을 해 나가면서 가장 뿌듯하고, 가장 인상깊은 경험으로 남은 것은 결국 고객에게 경험을 딜리버리 했을때였다. 그런 경험을 쌓이게 되면서 내가 계속해서 하고 싶은 개발자는 고객에게 좋은 경험을 딜리버리 하는 개발자였다. 최근 프로덕트 엔지니어의 글을 읽은적이 있다. 이 글을 읽고 내가 바라는 개발자로써의 바라는 방향을 얼라인을 할 수 있었고, 그에 따라 세가지의 목표를 세웠다. 1. 기획, 디자인, 데이터, 도메인 등 고객에게 경험을 주는 분야에 대해서 공부해보기. 2. 많은 개발적인 비지니스 로직에 대해서 경험해보기. 3. 사용자의 경험중에 개발자가 놓치면 안되는 것은 성능과 장애다. 성능과 장애는 사용자에게 시간을 뺏는것과 동일하다. 사람이 가장 중요하다고 느끼는것은 시간인데, 따라서 고객 경험이 최악으로 나아갈수 있다. 그러기 때문에 성능, 장애 이 두가지에 대해서 깊게 공부하기. 이다.

이제 내가 2024년에 개발자로써 목표세웠던걸 이 세미나의 세션에서 나왔던것과 연결해봤다. 일단 1번의 Impact분야에서는 고객에게 경험을 딜리버리 하는 것에서 가장 중요한 목표라고 생각했다. 그러기 위해선 어떻게 하면 더 좋은 경험을 줄 수 있는지 나도 같이 고민해볼 수 있었던 시간이였다.

두번째는 Reliabililty이다. 안정성인데, 3번의 개발자가 놓치면 안되는 분야 장애와 연결되어있다고 생각했다. 안정성이 낮은 서비스는 고객에게 시간만 뺏을뿐이다. 아울러 고객은 냉정하다. 떠나면 그만. 이 문구를 이야기 할때 가장 인상깊었다. 말한대로 내가 사용자로써 생각해보면 그냥 안쓸 기능은 바로 그냥 떠나버린다. 그러나 내가 쓰고 싶은데 불편함을 느낀다면 커뮤니티를 찾아보고 또한 사람들에게 계속 질문하고, 정 안되면 제작자에게 여쭤본다. 계속해서 우리는 안정성을 유지해야 한다.

세번째는 Productivity이다. 고객에게 딜리버리 하는 것에서 가장 중요한건 적절한 타이밍이다. 대부분 그 타이밍은 빠르다기 보단 늦을경우가 많다. 왜 그럴까? 생각해보면 생산성이 낮기 떄문이다. 그게 결정의 문제일수도 있고, 레거시로 인해 10분이면 될것이 5시간이 걸렸을수도 있다. 그런 경험을 해보기도 하였다. 또한 그런 생산성의 문제로 안정성이 떨어지는 경험도 있는거 같다. 정해진 부분이 없다 보니 실수할 수 있는 부분들이 생기는 것이다. 굉장히 사소한 실수. 그런 부분들을 방지하는 방향들이 있지 않나. 라는 생각이 든다.

이 세미나를 들으면서 내가 생각한 개발자의 상을 다시 한번 상기시키게 되었다. 차후 나도 이러한 목표들을 가지고 서비스를 만드는 프로덕트 엔지니어가 되는 꿈을 꾸고 한다. 그때와서 이 세미나를 다시 보고 이러한 목표를 가지고 한번 서비스를 만들어 나가고 싶은 생각이 든다.

cf) 마지막질문: 하드코딩은 나쁜것인가?

이에 대한 연사님인 희창님의 생각은 따로 나오지 않았지만, 이 세미나를 듣고 여기서 가장 중요한건은 Productivity에 관점에선 하드코딩은 나쁜것이 아닐까 생각이 든다. 바닥부터 만드는 애플리케이션을 만들때도 실제 코드를 작성하는 것 보다, 내가 어제 왜 이러한 코드를 짰는지 읽어보고 또 생각해본다. 그랬을때 이 하드코딩된 값이 어떤걸 의미하는지가 한눈에 보인다면 시간을 단축시키지 않을까? 가독성의 측면에서 하드코딩은 난 좋지 않다고 생각한다. 하드코딩을 상수로 만드는 시간보다 하드코딩된 값을 알기 위해 알아가는 그 시간이 훨씬더 많은 시간을 쓸것이라고 생각한다. 따라서 하드코딩은 나쁘다.