36P by xguru 5일전 | favorite | 댓글 1개
  • 스타트업 환경에서 DevOps, 스태프 엔지니어링, 플랫폼 엔지니어링 개념을 효과적으로 적용한 사례 공유
  • 발표자 Chad McElligott는 Smartrr의 시니어 스태프 엔지니어로, Shopify 기반 구독 및 로열티 서비스를 제공하는 회사
  • 스타트업 특유의 문화와 요구사항에 맞춘 엔지니어링 방법론 제안

[핵심 개념]

DevOps

  • DevOps에 대한 정의는 사람마다 다르며, 어떤 이에게는 직책이고, 다른 이에게는 일하는 방식임
  • "DevOps as No Ops" 개념은 소프트웨어 엔지니어가 Ops 관련 모든 업무를 스스로 처리하게 만듦
  • DevOps는 협업 마인드셋, 반복적이고 수동적인 작업( toil )의 자동화, 최신 도구 활용을 통해 고객에게 가치를 빠르게 전달하는 것
  • 클라우드 활용, 인프라 코드화, CI/CD 파이프라인 구축과 같은 기술적 요소뿐만 아니라, 소통과 협업 장벽을 허물어 더 나은 결과를 달성하는 것이 핵심임

플랫폼 엔지니어링

  • Platform Engineering은 개발자의 인지 부하를 줄이는 기술적 접근법
  • 목표는 제품 개발 속도와 시스템 안정성을 동시에 높이는 것으로, 개발자의 활동을 지원하는 기본적인 구성 요소를 제공함
  • 대기업들이 플랫폼 엔지니어링 팀을 구축하여 효율성을 높이고 개발자 경험을 개선하는 사례가 증가하고 있음
  • Manuel Pais와 Matthew Skelton의 책 Team Topologies 를 통해 대중화되었으며, 엔지니어링 역량 강화의 사례를 다양한 매체에서 확인할 수 있음

스태프 엔지니어링

  • Staff Engineering은 특정 마인드셋이나 기술이 아닌, 조직 내에서 소프트웨어 엔지니어가 맡는 역할
  • Senior Software Engineer 이후의 커리어 단계로, 소프트웨어 엔지니어링의 서번트 리더십이라고도 설명할 수 있음
  • Staff+ 엔지니어는 개인 작업뿐만 아니라 조직 전체의 책임을 확장하며, 관리자나 VP와 협업하여 실질적인 실행과 관점을 제공함
  • Will Larson의 책 **Staff Engineer**에서는 Staff 역할을 네 가지 아키타입(Architect, Right Hand, Tech Lead, Fixer)으로 나누어 설명함

[스타트업 문화]

  • 벤처 투자 기반의 스타트업은 성장을 위해 지출이 수익을 초과하는 경우가 많음
  • 투자로부터 확보한 자본을 "런웨이"로 활용해 빠른 성장을 추구하며, 런웨이가 소진되기 전에 성장과 수익성을 달성해야 함
  • 이러한 환경은 두 가지 핵심적인 문화적 특성을 만듦
    • 낭비할 시간이 없음
      • 스타트업에서 시간 낭비는 특히 치명적임
      • 개발팀은 조직의 전략적 목표에 초점을 맞추고, 런웨이 내에서 실행해야 함
      • 각 팀원은 자신의 활동이 목표에 부합하는지 수시로 확인하고, 필요하다면 재조정해야 함
      • 실험이 실패하더라도 학습을 위한 구조를 갖추고 원하는 교훈을 얻었다면 그것은 낭비가 아님
    • 모두가 여러 역할을 수행함
      • 작은 조직에서는 해야 할 일이 많지만, 이를 수행할 사람이 부족함
      • 예를 들어 프론트엔드 개발자는 제품 디자이너, 테크니컬 라이터, 제품 관리자, 품질 보증, 서드파티 통합 담당자 등 다양한 역할을 겸할 수 있음
      • 고객 경험 개선을 위한 새로운 아이디어가 나오면, 이를 제안한 사람이 직접 프로토타입을 제작하거나 실현하는 책임을 지게 될 수도 있음
  • 이러한 문화적 특성은 제품 개발 그룹과 특히 소프트웨어 엔지니어링 리더에게 필요한 역량을 결정함
  • 또한 DevOps, Platform Engineering, Staff Engineering이 스타트업 환경에 어떻게 적응해야 하는지에 대한 힌트를 제공함

[스타트업 문화에 나의 엔지니어링 원칙(Tenet)들 적용하기]

스타트업에서의 DevOps

  • 스타트업에서는 프로세스를 변경하기 쉬움.
    • 인원이 적기 때문에 새로운 행동 방식을 적용하는 데 큰 장애물이 없음
    • 도구를 기준으로 프로세스를 조정하는 것이 최적의 결과를 가져옴
    • 경직된 프로세스를 유지하면 도구를 커스터마이징하거나 추가 소프트웨어를 개발해야 하므로 시간이 낭비됨
  • 커스텀 도구를 최대한 피해야 함
    • 서버리스 인프라, SaaS 도구, 오픈소스 라이브러리 등을 활용하는 것이 바람직함
    • 기술의 일반적인 흐름에 맞추되, 차별화된 경쟁 우위를 제공하지 않는 경우에는 기술을 커스터마이징하지 않아야 함
    • 참고: Martin Fowler의 Utility vs Strategic Dichotomy
  • "지루한 기술"을 선택해야 함
    • 팀이 익숙하지 않거나 커뮤니티가 부족한 솔루션에 큰 리스크를 걸지 말아야 함
    • 문제 발생 시, 온라인에서 해결책을 쉽게 찾을 수 있는 기술을 선택해야 함
    • Dan McKinley의 boringtechnology.club에서 이 아이디어를 자세히 설명한 강연 확인 가능

스타트업에서의 Platform Engineering

  • Rebecca Murphey의 Engineering Unblocked podcast에서 언급된 내용:
    • "기업의 개발자 경험은 그것이 설계되었든 아니든 하나의 제품임"
    • 스타트업 규모에서도 여전히 모니터링, 배포, 오류 추적, 로그 확인, 기능 플래그 전환이 필요함
    • 중요한 질문은 "이 작업들이 고통스러운가?"임
  • Platform Engineering은 스타트업에서 파트타임 역할임
    • 초기에 통합된 테스트 환경이 필요할 수 있지만, 나중에는 우선순위에서 밀릴 수 있음
    • 플랫폼 엔지니어링 역할은 필요할 때만 수행하게 됨
  • 장기적인 플랫폼 프로젝트를 진행할 여유가 없음
    • 대신 작은 단위의 작업을 통해 가치 있는 요소를 구현해야 함
    • 큰 그림과 비전을 팀과 공유하되, 작은 조각들이 어떻게 연결되는지 이해시키는 것이 중요함
  • 스타트업의 플랫폼 작업은 새로운 생산성과 접근법을 개척하는 과정임
    • 기존 소프트웨어에서 최신 도구로의 전환이 아니라 아예 없던 요소를 새로 구축하는 작업이 대부분임
    • 무엇을 할 수 있는가보다 무엇을 해야 하는가를 결정하는 것이 중요함
  • 현재 조직의 문제나 가까운 미래의 문제를 해결하는 작업에 집중해야 함
    • 실무 경험, 엔지니어와의 대화, 회고 피드백, SDLC(소프트웨어 개발 생명 주기) 지표 분석 등을 통해 필요한 작업을 파악해야 함
    • 때로는 플랫폼 작업을 뒤로 미루고 다른 필요 사항에 집중하는 것이 나을 수 있음
    • 유연하게 접근하는 것이 핵심임

스타트업에서의 Staff Engineering

  • Staff Engineer 역할은 스타트업 환경에 적합함
    • 깊은 기술적 전문성, 넓은 영향력을 추구하는 성향, 비즈니스 문제를 해결하기 위해 필요한 곳에 기꺼이 나서는 태도가 스타트업에 잘 맞음
  • 대규모 조직에서는 "어디에 기술적 부채가 묻혀 있는지 안다"는 표현이 있음
    • Staff Engineer는 이런 지식을 가진 사람을 찾아 정리하고, 앞으로 나아갈 결정을 도출함
    • 스타트업에서는 기술적 부채와 문제가 명확히 드러나 있음
    • Staff Engineer는 이 혼란을 정리하고 장기적으로 조직에 도움이 될 솔루션을 구축함으로써 큰 영향을 미칠 수 있음
  • 스타트업에서는 Staff Engineer가 한 가지 아키타입에 머물 수 없음
    • 조직 규모가 작기 때문에 직접 실행을 포함해 다양한 활동을 수행해야 함
    • 아키텍처 설계, 프로젝트 리딩, 전술적 작업 수행뿐만 아니라 개선 아이디어를 스스로 도출하고 실행해야 함
    • 유연함과 주도적 책임감이 스타트업의 Staff+ 엔지니어에게 필수적인 특성임
  • Staff+ 엔지니어의 중요한 역할 중 하나는 멘토링과 스폰서십
    • 특히 스타트업의 주니어 인재들에게 중요한 지원과 방향성을 제공함
    • Staff Engineer는 이러한 지원을 통해 팀의 성장을 촉진하고 조직의 역량을 강화함

[스타트업에서 모던 스태프 엔지니어링 적용하기]

스토리 1 of 2 - "Improving DevEx by Removing a Merge Freeze"

문제 상황

  • 기존 QA 프로세스:
    • 릴리스 전 2-3일간 **"merge freeze"**를 시행하고 QA 팀이 수동 리그레션 테스트를 진행
    • 발견된 버그는 즉시 수정되어 main 브랜치에 병합
    • 개발자는 새 패치를 빌드하지만 병합 요청을 릴리스 이후까지 보류해야 함
  • 단점:
    • 수동 리그레션 테스트는 느리고 예측 불가
    • 병합 지연으로 merge conflict 발생 빈도가 높음
    • 개발자의 생산성과 협업이 저하됨

해결 방안

  • 인프라 코드를 Monorepo로 통합
    • Terraform 프로젝트를 애플리케이션 코드와 같은 리포지토리에 통합
    • 자동화된 린팅 및 의존성 관리 도구에 연결하여 개발자가 인프라를 더 쉽게 다루도록 유도
  • 모든 환경을 Terraform으로 관리
    • 새로운 환경뿐만 아니라 기존 스테이징 및 프로덕션 환경도 Terraform으로 관리
    • 동일한 인프라 정의에 다른 변수를 적용해 환경 간의 일관성을 유지
  • CI/CD 프로세스 단순화
    • 기존 GitLab Auto DevOps 템플릿은 커스터마이징이 많아 복잡해졌음
    • Auto DevOps를 제거하고 새로운 .gitlab-ci.yml 파일을 명확하게 정의
    • 명령어 대부분을 Makefile로 옮겨 수동 실행도 가능하도록 설계
  • Secrets 관리 개선
    • GitLab과의 결합도를 줄이기 위해 Google Cloud Secrets Manager로 애플리케이션 시크릿을 이동
    • Kubernetes ConfigMap을 자동으로 업데이트하도록 배포 스크립트를 수정
  • 범위에서 제외된 작업
    • 애플리케이션은 monolith 구조로 Kubernetes에서 실행 중
      • 이를 변경하는 작업은 지연과 리스크를 초래할 수 있어 유지
    • Terraform 자동화 파이프라인은 구축하지 않음
      • 상대적으로 인프라 변경이 적어 수동 프로세스 유지
    • Kubernetes 네이티브 시크릿 접근 방식도 보류

결과 및 성과

  • 새로운 테스트 환경을 배포하고 QA 팀이 리그레션 테스트를 독립적으로 수행할 수 있게 됨
  • merge freeze 제거로 개발자가 자유롭게 main 브랜치에 변경 사항을 병합 가능
  • 릴리스 프로세스가 간소화되고 팀 전체의 속도가 개선됨

적용된 원칙

  • Staff Engineering 원칙
    • 다양한 팀과 협업하며 프로젝트를 리딩
    • "Tech Lead" 역할을 수행하며 프로젝트를 완료로 이끎
    • CI/CD 및 인프라 개선으로 팀의 이해도와 접근성을 향상
  • Platform Engineering 원칙
    • DevOps 프로젝트를 플랫폼 프로젝트로 확장
    • 모든 인프라를 코드로 관리해 환경 간 일관성을 확보
    • 현실적인 트레이드오프를 통해 프로젝트 범위를 조정
  • DevOps 원칙
    • 인프라를 코드로 관리하여 클라우드 인프라를 일관되게 운영
    • 릴리스 프로세스를 개선하고 새로운 도구로 개발 속도를 높임
    • RFC(Request For Comment) 문서 포맷을 도입해 결정 과정의 포용성을 강화

결론

  • QA 팀은 더 안정적인 환경에서 자동화 테스트를 실행할 수 있게 됨
  • 개발자는 merge freeze 없이 지속적인 개발이 가능해졌고 협업이 강화됨
  • 더 나은 툴링과 프로세스를 통해 조직의 생산성이 개선됨
  • 앞으로 프리뷰 환경 구축이나 리그레션 테스트 자동화와 같은 작업을 추가로 진행하고 싶음

스토리 2 of 2 - "Iterating Towards a Productive Engineering Process"

문제 상황

  • 기존 프로세스:
    • 모든 팀원이 하나의 보드에서 작업하며 매일 진행 상황을 공유
    • 많은 사람이 자신의 차례가 아닐 때 집중하지 않고 "체크아웃" 상태였음
    • 기능 개발의 책임이 분산되어 제품 관리자가 최종 책임을 맡는 경우가 많았음
    • 기술 아키텍처에 대한 명확한 이해도 부족
  • 목표:
    • 더 나은 협업과 소프트웨어 개발 프로세스를 구축하기 위해 다양한 실험 진행
  • 실험 1: 단기 기능 팀(Short-lived Feature Teams)
    • 목적: 기능 개발의 전체 라이프사이클에 대한 책임감을 엔지니어에게 부여
    • 방법:
      • 각 기능에 리더를 지정하고, 백엔드, 프론트엔드, QA 등으로 구성된 팀을 조직
    • 결과:
      • 팀원들의 책임감은 개선되었으나, 모든 사람이 리더 역할에 적합하거나 원했던 것은 아님
      • 이후 **"고정 팀 모델"**로 전환하여 **"Squads"**를 구성하고, 각 팀이 자체적으로 계획 및 회고 진행
  • 실험 2: Epic Kickoff Documents
    • 목적: 요구사항 명확화 및 팀의 프로젝트 범위와 접근 방식에 대한 합의 도출
    • 방법:
    • 결과:
      • 팀의 커뮤니케이션이 개선되었고 프로젝트 초기부터 더 잘 협업하게 됨
      • 팀원들은 이 미팅이 가치 있는 시간이라고 평가
  • 실험 3: 그룹 코드 리뷰(Group Code Review)
    • 목적: 코드 리뷰 시간 단축, 코드 논의 활성화, 엔지니어 간 기술 공유
    • 방법:
      • 주 2회 Slack Huddle에서 1시간 동안 코드 리뷰 세션 진행
      • 개발자가 화면을 공유하며 PR을 설명하고, 참여자들이 피드백 제공
    • 결과:
      • 코드 리뷰 소요 시간이 크게 단축되고, Inbox 0 상태를 유지
      • 코드에 대한 논의를 통해 개발자들이 서로 배우고 존중하는 문화가 형성됨
      • 코드 리뷰 외에도 페어 프로그래밍의 장점이 팀에 소개됨

적용된 원칙

  • Staff Engineering 원칙
    • 엔지니어링 관리자 부재 시 프로세스 개선을 리드
    • 지속적인 개선 문화를 팀에 도입해 애자일 프로세스를 통해 자율적 협업 강화
    • 팀이 정체된 프로세스를 깨고 더 나은 방법을 찾도록 지원
  • Platform Engineering 원칙
    • 도구만이 아닌 프로세스도 플랫폼의 일부로 간주
    • 비효율적인 프로세스는 팀의 생산성을 저해하므로 이를 개선하는 것이 중요
    • 낭비를 제거하는 프로세스 변경이 도구 개선만큼 큰 영향을 미칠 수 있음
  • DevOps 원칙
    • CALMS 원칙: 협업(Collaboration), 자동화(Automation), 린(Lean), 측정(Measurement), 공유(Sharing)
      • 린(Lean) 프로세스를 통해 낭비를 제거하고 가치를 빠르게 전달
    • 애자일 프로세스를 통해 팀이 지속적으로 개선하도록 교육

결론

  • 팀의 프로세스를 실험적으로 개선하면서 생산성과 협업이 크게 향상됨
  • 저비용, 고효율의 개선 사항으로 팀 전체의 개발 경험이 개선됨
  • 자신만의 프로세스를 비판적으로 검토하고 개선할 여지를 찾아볼 것을 강력히 권장

[마무리]

  • 스타트업 환경에서 일하면서 다양한 문제를 해결하고 솔루션을 실현하는 과정에 전문성과 열정을 모두 발휘할 수 있음
  • 시간 제약이 존재하기 때문에 실용주의적 접근을 배양하는 좋은 기회가 되며, 회사 초기 단계에서 큰 영향력을 미칠 수 있음
  • 현대적인 소프트웨어 엔지니어링 접근 방식을 적용해 회사의 성공 기반을 마련할 수 있음
  • Staff Engineering과 스타트업

    • Staff Engineer는 넓이와 깊이 모두를 갖춘 경험이 요구됨
    • 스타트업은 Staff+ 엔지니어가 기술적 지식을 확장하고 새로운 영역을 탐구할 수 있는 기회를 제공함
      • 예시: 백엔드 엔지니어가 React나 BigQuery와 같은 기술을 배울 수 있음
  • Platform Engineering과 스타트업

    • 스타트업에서의 Platform Engineering은 규모에 따라 달라짐
    • 1:1 커뮤니케이션을 통해 개발자의 페인포인트를 파악하고, 작은 프로젝트로 개발자 경험(DevEx)을 개선할 수 있음
    • 빠른 피드백 루프를 구축해 개발 프로세스를 개선하고, 개발자들이 미래에 스스로 문제를 해결할 수 있도록 도와야 함
    • 소프트웨어 개발 생명주기(SDLC) 의 기본 사항을 업계 표준 도구와 기법으로 충족시키는 것이 중요함
    • 스타트업에서는 Platform Engineering이 전담 업무가 아니라 필요에 따라 적용하는 기술적 접근법
    • "기업의 개발자 경험은 하나의 제품"이라는 점을 명심하고, 이를 설계하는 데 시간을 할애해야 함
  • DevOps와 스타트업

    • DevOps는 스타트업에서도 매우 중요한 역할을 함
    • 문화, 프로세스, 도구를 통해 고객에게 가치를 더 빠르게 전달하고, 더 나은 작업 환경을 만드는 것이 핵심임
    • DevOps를 통해 회사의 효율성을 높이고 협업 문화를 정착시키는 과정은 매우 보람찬 일임
    • 스타트업에서 DevOps에 열정을 가진 엔지니어는 자신의 기술과 경험을 통해 큰 기여를 할 수 있음
  • 스타트업 환경은 새로운 도전과 배움의 기회로 가득 차 있으며, 이를 통해 엔지니어는 더욱 성장하고 의미 있는 성과를 이끌어낼 수 있음

앞으로 스타트업에서 필요한 엔지니어링 역활을 잘 정의 한 것 같아요. 이전에 뚜렷한 구분없이 하던 엔지니어링을 잘 정리 한 것 같네요. 스스로도 어떤 엔지니어링을 전담하는지 앞으로 잘하고 싶은지 구체적으로 알 수 있을 것 같네요. 스타트업에서도 체계화 된 엔지니어링을 갖추고 필요한 엔지니어도 잘 뽑을 수 있고요