링크드인에서 본 정말 좋은 글 아카이브.
이 글은 Amazon S3를 12년간 이끌어온 한 리더가 복잡한 시스템을 대규모로 운영할 때 **“팀이 어떻게 일하는가”**가 얼마나 중요한지를 강조하며, 특히 **Principal Engineer(수석 엔지니어)**의 역할과 이를 최적화하기 위한 Roles Framework(역할 프레임워크)에 대해 설명하는 내용입니다. 아래는 그 내용을 한국어로 번역한 것입니다:
저는 Amazon S3에서 약 12년간 일해 왔으며, 그 과정에서 배운 가장 큰 교훈 중 하나는 복잡한 시스템을 대규모로 운영할 때는 팀이 어떻게 일하는지에 대해 깊이 고민해야 한다는 것입니다. 단순히 무엇을 만드는지를 파고드는 것만으로는 부족합니다. 팀이 어떻게 운영되는지를 끊임없이 설계하고, 반복하고, 개선해야 합니다.
잠재력은 어디에나 존재하며, 리더라면 그것을 발견하고 끌어올리는 것이 당신의 책임입니다. 저는 오브젝트 및 파일 스토리지, 스트리밍 및 메시징, 그리고 새로운 Amazon Q Developer의 Windows/VMWare/메인프레임 마이그레이션 등 다양한 팀에 놀라운 엔지니어링 인재들이 있습니다. 저는 엔지니어, 특히 Principal Engineer가 최대한의 영향력을 발휘할 수 있도록 지원합니다.
Amazon에서 **Principal Engineer(수석 엔지니어)**는 매우 고위 엔지니어입니다. 그들은 코드의 방향을 설정하고, 엔지니어링 및 운영 문화에 영향을 주며, 비용 구조 및 제품 로드맵에 실질적 기여를 합니다. 그들은 AWS Builders Library에서 배운 점을 공유합니다. 이 글을 읽고 계시다면 반드시 한번쯤 들어가 보시길 추천합니다. Clare Liguori, David Yanacek, Colm MacCárthaigh, Marc Brooker, Becky Weiss, Joe Magerramov 같은 뛰어난 엔지니어들이 AWS 서비스 규모에서의 경험을 나누고 있습니다.
조직 리더로서 저 역시 Andrew Warfield 같은 Distinguished Engineer들에게 사업 전반에 대한 인사이트를 자주 구합니다. 하지만 이들의 시간은 매우 제한적이며, Principal Engineer 자신도 어떻게 하면 비즈니스에 가장 큰 영향을 줄 수 있을지 고민하게 됩니다. 이런 배경에서 저는 **2016년에 ‘Principal Engineer Roles Framework’**를 만들기 시작했습니다.
Roles Framework의 시작
2016년, S3의 원년 멤버이자 전 Amazon CTO였던 Allan Vermeulen이 팀에 잠시 복귀했습니다. 그는 뛰어난 기술력뿐 아니라, 다양한 수준의 엔지니어들과 소통하는 능력이 탁월합니다. 그가 프로젝트 상태에 따라 유연하게 역할을 바꾸는 모습을 보면서 큰 영감을 받았고, 그가 했던 다양한 역할을 정리하게 되었습니다. 그 후 Principal Engineers들과 논의하여 이 프레임워크를 만들고, S3/Glacier 팀에서 공식적으로 활용하게 되었죠.
이 프레임워크를 사용하면서 우리는 Principal Engineer의 영향을 극대화할 수 있었습니다. 예를 들어, 한 엔지니어가 오랜 기간 Catcher 역할만 수행하고 있었다면, 다른 엔지니어를 Catcher로 육성하고 해당 Principal Engineer는 Guide 역할로 전환시켰습니다. 또, 한 Principal Engineer가 여러 프로젝트에 Participant로 참여하느라 Sponsor 역할을 할 시간이 없었던 사례도 있었습니다. 그에 따라 역할 재조정을 했죠. 어떤 프로젝트는 아무도 Catalyst 역할을 하지 않아 진척이 없었는데, 해당 역할을 지정하자 1년 동안 정체되던 아이디어가 단 4개월 만에 구체화되기도 했습니다.
Principal Engineer Roles (역할 정의)
Sponsor
프로젝트 또는 프로그램 리더. 의사결정이 지체되지 않도록 책임을 집니다. 여러 팀 간 조율과 제품 정의, 조직적 정렬을 포함한 종합적 결과에 대한 책임을 가집니다.
동시에 1~2개의 프로젝트만 맡을 수 있을 정도로 많은 시간 소요
종종 관리자 외에 뛰어난 엔지니어가 맡기도 함
Guide
기술적 방향을 주도하며, 디자인 문서나 예시 코드 등을 통해 패턴을 제시합니다.
제품 또는 설계 전반에 영향
Sponsor와 달리 제품 정의보다는 기술 방향에 집중
동시에 1~2개 프로젝트까지만 가능
Catalyst
새로운 아이디어를 현실화합니다. 단순 아이디어 제공이 아니라, 프로토타입과 설득, 인력 배정까지 책임집니다.
모호하지만 야심찬 문제에 필요
프로젝트가 본궤도에 오르면 역할은 종료
Tie-Breaker
의견이 갈릴 때 결정을 내리는 역할. 각 입장의 뉘앙스를 깊이 이해하고, 배경까지 설명하며 결론을 내리는 신중한 판단력이 필요합니다.
한순간의 역할로, 결론이 나면 종료
항상 Tie-Breaker가 되면 병목 현상이 생길 수 있음
Catcher
위기에 처한 프로젝트를 정상 궤도로 되돌리는 역할입니다. 빠르게 문제를 분석하고 실질적 해결책을 제시해야 합니다.
일시적인 역할이지만 너무 자주 하면 성장 기회가 줄어듦
이 역할은 다른 엔지니어에게도 학습 기회 제공 가능
Participant
특정 리더십 역할 없이 프로젝트에 참여합니다.
능동적(코드, 리뷰 등) 또는 수동적(회의 참석) 참여
너무 많은 프로젝트에 Participant로 있으면 집중력 분산 위험
Roles Framework의 활용법
자신이 어떤 역할을 주로 수행하고 있는지 분석하세요. 예: 캘린더 색상으로 Catcher는 파란색, Participant는 빨간색 등 지정
다른 리더 및 PE들과 논의해 시간 투자 대비 영향도를 점검
이 프레임워크를 통해 역할 기대치를 명확히 공유하고, 성장 기회를 분배
신호에 주목하세요: 팀이 Tie-Breaker를 원하는지, Sponsor가 필요한지를 상황을 통해 감지
Roles Framework의 조직 효과
S3 같은 대규모 분산 시스템은 엔트로피와 싸우는 구조입니다. 프레임워크는 엔지니어링 조직에서도 이러한 엔트로피에 대응하는 도구입니다.
PE의 역할을 명확히 하고 의도적으로 설정함으로써, 팀 전체의 성장과 서비스 품질 향상에 기여할 수 있습니다.
원글
https://www.linkedin.com/pulse/principal-engineer-roles-framework-mai-lan-tomsen-bukovec-142df