# 스타트업에서의 모던 스태프 엔지니어링 > Clean Markdown view of GeekNews topic #18310. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=18310](https://news.hada.io/topic?id=18310) - GeekNews Markdown: [https://news.hada.io/topic/18310.md](https://news.hada.io/topic/18310.md) - Type: news - Author: [xguru](https://news.hada.io/@xguru) - Published: 2024-12-17T11:11:01+09:00 - Updated: 2024-12-17T11:11:01+09:00 - Original source: [chadxz.dev](https://chadxz.dev/startup/) - Points: 47 - Comments: 3 ## Summary - DevOps는 협업 마인드셋, 반복적이고 수동적인 작업의 자동화, 최신 도구 활용을 통해 고객에게 가치를 빠르게 전달하는 것 - Platform Engineering은 개발자의 인지 부하를 줄이는 기술적 접근법으로 제품 개발 속도와 시스템 안정성을 동시에 높이는 것 - Staff Engineering은 특정 마인드셋이나 기술이 아닌, 조직 내에서 소프트웨어 엔지니어가 맡는 역할 - 스타트업은 낭비할 시간이 없고, 모두가 여러 역할을 수행해야하는 문화적 특성이 있음 - 스타트업에서의 DevOps - 도구를 기준으로 프로세스를 조정하는 것이 최적의 결과 - 커스텀 도구를 최대한 피해야 하며, 지루한 기술을 선택해야 함 - 스타트업에서의 Platform Engineering - 새로운 생산성과 접근법을 개척하는 과정. 무엇을 할 수 있는가보다 무엇을 해야 하는가를 결정하는 것이 중요 - 현재 조직의 문제나 가까운 미래의 문제를 해결하는 작업에 집중 - 스타트업에서의 Staff Engineering - 깊은 기술적 전문성, 넓은 영향력을 추구하는 성향, 비즈니스 문제를 해결하기 위해 필요한 곳에 기꺼이 나서는 태도가 스타트업에 잘 맞음 - 유연함과 주도적 책임감이 스타트업의 Staff+ 엔지니어에게 필수적 - 멘토링과 스폰서십이 중요. 팀의 성장을 촉진하고 조직의 역량을 강화 ## Topic Body - 스타트업 환경에서 DevOps, 스태프 엔지니어링, 플랫폼 엔지니어링 개념을 효과적으로 적용한 사례 공유 - 발표자 Chad McElligott는 Smartrr의 시니어 스태프 엔지니어로, Shopify 기반 구독 및 로열티 서비스를 제공하는 회사 - 스타트업 특유의 문화와 요구사항에 맞춘 엔지니어링 방법론 제안 ### [핵심 개념] #### **DevOps** - DevOps에 대한 정의는 사람마다 다르며, 어떤 이에게는 직책이고, 다른 이에게는 일하는 방식임 - "DevOps as No Ops" 개념은 소프트웨어 엔지니어가 Ops 관련 모든 업무를 스스로 처리하게 만듦 - DevOps는 **협업 마인드셋, 반복적이고 수동적인 작업( [toil](https://news.hada.io/topic?id=388) )의 자동화, 최신 도구 활용을 통해 고객에게 가치를 빠르게 전달하는 것**임 - 클라우드 활용, 인프라 코드화, CI/CD 파이프라인 구축과 같은 기술적 요소뿐만 아니라, 소통과 협업 장벽을 허물어 더 나은 결과를 달성하는 것이 핵심임 #### **플랫폼 엔지니어링** - Platform Engineering은 **개발자의 인지 부하를 줄이는 기술적 접근법**임 - 목표는 제품 개발 속도와 시스템 안정성을 동시에 높이는 것으로, 개발자의 활동을 지원하는 기본적인 구성 요소를 제공함 - 대기업들이 플랫폼 엔지니어링 팀을 구축하여 효율성을 높이고 개발자 경험을 개선하는 사례가 증가하고 있음 - Manuel Pais와 Matthew Skelton의 책 **[Team Topologies](https://teamtopologies.com/book)** 를 통해 대중화되었으며, 엔지니어링 역량 강화의 사례를 다양한 매체에서 확인할 수 있음 #### **스태프 엔지니어링** - 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](https://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html) - **"지루한 기술"을 선택해야 함** - 팀이 익숙하지 않거나 커뮤니티가 부족한 솔루션에 큰 리스크를 걸지 말아야 함 - 문제 발생 시, 온라인에서 해결책을 쉽게 찾을 수 있는 기술을 선택해야 함 - Dan McKinley의 [boringtechnology.club](https://boringtechnology.club/)에서 이 아이디어를 자세히 설명한 강연 확인 가능 #### 스타트업에서의 Platform Engineering - Rebecca Murphey의 [Engineering Unblocked podcast](https://www.unblocked.fm/episodes/mason-jones-zapier/)에서 언급된 내용: - **"기업의 개발자 경험은 그것이 설계되었든 아니든 하나의 제품임"** - 스타트업 규모에서도 여전히 모니터링, 배포, 오류 추적, 로그 확인, 기능 플래그 전환이 필요함 - 중요한 질문은 "이 작업들이 고통스러운가?"임 - **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** - **목적**: 요구사항 명확화 및 팀의 프로젝트 범위와 접근 방식에 대한 합의 도출 - **방법**: - [제공된 템플릿](https://docs.google.com/document/d/1xM3QEo6X0l1SQA_cXa92z5i0u9xpmUfBwsyjQpP1vOQ/edit?tab=t.0#heading=h.zf6oe118xbd3)을 사용해 모든 팀원이 미팅에서 문서를 작성 - **결과**: - 팀의 커뮤니케이션이 개선되었고 프로젝트 초기부터 더 잘 협업하게 됨 - 팀원들은 이 미팅이 **가치 있는 시간**이라고 평가 - 실험 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에 열정을 가진 엔지니어는 자신의 기술과 경험을 통해 큰 기여를 할 수 있음 - 스타트업 환경은 새로운 도전과 배움의 기회로 가득 차 있으며, 이를 통해 엔지니어는 더욱 성장하고 의미 있는 성과를 이끌어낼 수 있음 ## Comments ### Comment 32628 - Author: jhj0517 - Created: 2024-12-23T18:41:52+09:00 - Points: 1 1. 소통이 잘 안될 경우 모노레포 전환을 고려할 것 2. 모든 팀이 서로 추구하는 가치가 무엇인지 공유할 수 있는 시간을 가질 것 (Epic Kickoff Documents) ### Comment 32587 - Author: xguru - Created: 2024-12-22T10:59:24+09:00 - Points: 1 [DevOps에 대한 추도사](https://news.hada.io/topic?id=15604) [DevOps 엔지니어보다 더 많이 돈 버는 플랫폼 엔지니어](https://news.hada.io/topic?id=13537) [스태프(Staff) 엔지니어란 무엇인가?](https://news.hada.io/topic?id=17816) ### Comment 32563 - Author: ragingwind - Created: 2024-12-20T15:58:25+09:00 - Points: 1 앞으로 스타트업에서 필요한 엔지니어링 역활을 잘 정의 한 것 같아요. 이전에 뚜렷한 구분없이 하던 엔지니어링을 잘 정리 한 것 같네요. 스스로도 어떤 엔지니어링을 전담하는지 앞으로 잘하고 싶은지 구체적으로 알 수 있을 것 같네요. 스타트업에서도 체계화 된 엔지니어링을 갖추고 필요한 엔지니어도 잘 뽑을 수 있고요