데브옵스 스터디 7~8장

김동영·2025년 6월 8일

데브옵스 스터디

목록 보기
4/7

7장

콘웨이의 법칙을 고려한 조직 및 아키텍처 설계 방법

  • 콘웨이 법칙
    소프트웨어 구조에 맞춰 팀 구조가 정해진다.
    소프트웨어 구조 <.. 팀 구조
  • 콘웨이 법칙을 활용할 수 있게 팀과 업무를 구성해야 한다.

엣시에서의 콘웨이의 법칙

  • 스프라우터
    • 어플리케이션과 DB 를 연결하는 최초 기술
    • 기능 변경에 따라 계속 변경해야함.(프로시저 변경, 어플 변경 등)
  • ORM
    • Object Relational Mapping
    • 어플리케이션, DB 간 추상화하여 기술의 변화를 줄임.

조직의 아키타입

  • 기능 지향 조직
    • 기존 회사의 조직 문화 => 기능 중심의 팀 조직
  • 시장 지향 조직
    • 고객의 요구사항을 대응하기 위한 조직
    • 데브옵스 최적의 조직

과도한 기능 지향(비용 최적화)에 따른 문제

  • 기능 지향 팀이 모두 최고 성능을 발휘하면 병목 현상이 발생한다.
    => 연관 관계가 있는 팀인 경우 두 팀 모두 최대치의 일을 한다면 앞의 팀이 뒤의 팀에 영향을 받을 수 밖에 없다.

시장 지향 팀 활성화하기(속도 최적화)

  • 기능 중심의 효과를 줄이고 시장 지향성을 활성화해야 한다.
    • 기능 중심 = 비용 최적화
      전문가가 모든 관계 업무를 대응함 => 비용 절감
    • 시장 지향성 = 속도 최적화
      특정 서비스의 고객 니즈 기준 대응으로 서비스 만족도를 올린다.

기능 지향 작업 만들기

  • 기능 중심이어도 서비스 팀이 필요한 업무를 빠르게 대응할 수 있다면 이상적인 조직 구조를 가져갈 수 있다. => 높은 신뢰 문화가 필요, 시스템 별 작업 여유가 있음.
  • 조직 구조가 아니라 사람들의 능력과 습관을 개발

테스팅, 운영, 보안은 모든 사람의 일상 업무다

  • 높은 성과를 내는 조직은 팀의 모든 구성원을 목표를 공유한다.
    => 개인적인 느낌: 팀 내 일은 관심을 가지고 집단지성을 발휘해야 한다?

모든 팀원이 제너럴리스트가 되게 하라

  • 소수의 프로페셔널은 병목현상을 일으킨다. => 사일로의 원인
  • 다수의 제너럴이 되어 순환 근무가 가능하도록 한다.
  • 고정 마인드셋 => 성장 마인드셋 변경/육성이 필요함.

프로젝트가 아닌 서비스와 제품에 투자하라

  • 프로젝트 단위로 투자할 경우, 개발 인력이 운영을 담당하지 않아 운영에 필요한 지식을 습득할 수 없으며, 나아가 고객의 니즈를 만족시킬 수 없다
    => SI, SM?

콘웨이의 법칙에 따라 팀의 경계를 설정하라

  • 소규모 팀이 독립적으로 생산성을 발휘할 수 있도록 소프트웨어를 분리하여 과도한 커뮤니케이션을 줄이고 단일 팀으로 서비스를 온전히 제공할 수 있도록 조정해야 한다.

개발자 생산성과 안정성을 위해 느슨하게 결합된 아키텍처를 구축하라

  • 느슨한 결합을 위해 도메인의 경계를 설정하고(바운디드 컨텍스트), 이를 바탕으로 서비스 지향 아키텍처를 설계하여 서비스 간 영향도를 줄이고 각자의 개발/배포를 독립적으로 수행할 수 있도록 해야 한다.

팀 규모를 작게 유지하라(피자 두판의 법칙)

  • 팀 규모를 일정 이하(예, 8명) 으로 유지하여 아래의 효과를 얻는다
    • 서비스 성장률 제한
    • 시스템 발전 속도 제한
      => 시스템를 지속적으로 이해할 수 있도록 함.
    • 핵심 비즈니스 지표 설정
      => 자율적으로 목표를 달성할 수 있도록 한다.

결론

  • 아키텍처 설계가 잘못되면 팀 구조 및 조직 설계가 잘못될 수 있다.
    => 어떤 서비스보단, 누가 관리하는지 가 중요하다.

8장

일상 업무와 운영을 통합해 퇴상의 결과를 얻는 방법

개발자의 생산성 향상을 위한 공유 서비스를 생성하라.

  • 중앙 집중식 플랫폼과 도구를 활용하여 업무 효율성을 올릴 수 있다.
    예) 클라우드 상품 사용 => 내부 서비스: 넷트릭
  • 도구를 사용하되, 도구 개발 팀에 의존하지 않도록 한다.

운영 엔지니어를 서비스 팀에 포함하라

  • 운영 엔지니어를 팀에 포함시켜, 의사소통 과정을 줄이고 업무 이해도를 올린다.

서비스 팀마다 운영 연락 담당자를 지정하라.

  • 엔지니어 포함이 불가능하다면, 연락 담당자를 별도 지정하여 업무 싱크를 맞춘다.

개발 팀의 정기적 업무 활동에 운영을 통합하라.

  • 개발 팀의 스크럼 등 개발 업무는 운영에도 영향을 미치는 경우가 많다.
  • 개발 팀 업무 협의에서 운영 팀의 관점을 실시간으로 피드백받아 합리적인 선택을 하고 진행할 수 있다.

결론

  • 운영 업무는 중요하고 유기적인 만큼, 일상 업무와 통합하여 의사소통 과정을 줄이고 꾸준한 개발이 필요하다.
  • 이를 위해 운영 담당자와 원활한 소통이 필요하다.
profile
k8s, 프레임워크와 함께하는 백엔드 개발자입니다.

0개의 댓글