스타트업에서의 모던 스태프 엔지니어링
(chadxz.dev)- 스타트업 환경에서 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 네이티브 시크릿 접근 방식도 보류
- 애플리케이션은 monolith 구조로 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) 프로세스를 통해 낭비를 제거하고 가치를 빠르게 전달
- 애자일 프로세스를 통해 팀이 지속적으로 개선하도록 교육
-
CALMS 원칙: 협업(Collaboration), 자동화(Automation), 린(Lean), 측정(Measurement), 공유(Sharing)
결론
- 팀의 프로세스를 실험적으로 개선하면서 생산성과 협업이 크게 향상됨
- 저비용, 고효율의 개선 사항으로 팀 전체의 개발 경험이 개선됨
- 자신만의 프로세스를 비판적으로 검토하고 개선할 여지를 찾아볼 것을 강력히 권장
[마무리]
- 스타트업 환경에서 일하면서 다양한 문제를 해결하고 솔루션을 실현하는 과정에 전문성과 열정을 모두 발휘할 수 있음
- 시간 제약이 존재하기 때문에 실용주의적 접근을 배양하는 좋은 기회가 되며, 회사 초기 단계에서 큰 영향력을 미칠 수 있음
- 현대적인 소프트웨어 엔지니어링 접근 방식을 적용해 회사의 성공 기반을 마련할 수 있음
-
Staff Engineering과 스타트업
- Staff Engineer는 넓이와 깊이 모두를 갖춘 경험이 요구됨
-
스타트업은 Staff+ 엔지니어가 기술적 지식을 확장하고 새로운 영역을 탐구할 수 있는 기회를 제공함
- 예시: 백엔드 엔지니어가 React나 BigQuery와 같은 기술을 배울 수 있음
-
Platform Engineering과 스타트업
- 스타트업에서의 Platform Engineering은 규모에 따라 달라짐
- 1:1 커뮤니케이션을 통해 개발자의 페인포인트를 파악하고, 작은 프로젝트로 개발자 경험(DevEx)을 개선할 수 있음
- 빠른 피드백 루프를 구축해 개발 프로세스를 개선하고, 개발자들이 미래에 스스로 문제를 해결할 수 있도록 도와야 함
- 소프트웨어 개발 생명주기(SDLC) 의 기본 사항을 업계 표준 도구와 기법으로 충족시키는 것이 중요함
- 스타트업에서는 Platform Engineering이 전담 업무가 아니라 필요에 따라 적용하는 기술적 접근법임
- "기업의 개발자 경험은 하나의 제품"이라는 점을 명심하고, 이를 설계하는 데 시간을 할애해야 함
-
DevOps와 스타트업
- DevOps는 스타트업에서도 매우 중요한 역할을 함
- 문화, 프로세스, 도구를 통해 고객에게 가치를 더 빠르게 전달하고, 더 나은 작업 환경을 만드는 것이 핵심임
- DevOps를 통해 회사의 효율성을 높이고 협업 문화를 정착시키는 과정은 매우 보람찬 일임
- 스타트업에서 DevOps에 열정을 가진 엔지니어는 자신의 기술과 경험을 통해 큰 기여를 할 수 있음
- 스타트업 환경은 새로운 도전과 배움의 기회로 가득 차 있으며, 이를 통해 엔지니어는 더욱 성장하고 의미 있는 성과를 이끌어낼 수 있음
앞으로 스타트업에서 필요한 엔지니어링 역활을 잘 정의 한 것 같아요. 이전에 뚜렷한 구분없이 하던 엔지니어링을 잘 정리 한 것 같네요. 스스로도 어떤 엔지니어링을 전담하는지 앞으로 잘하고 싶은지 구체적으로 알 수 있을 것 같네요. 스타트업에서도 체계화 된 엔지니어링을 갖추고 필요한 엔지니어도 잘 뽑을 수 있고요