Performance Engineering 팀은 무슨일은 하는가? Part1
1. 무엇을 이야기 하고 있나?
-
- 해당 포스팅의 출처는 Brendan Gregg의 최신 블로그 게시물인 “When to Hire Computer Performance Engineering Team (2025) Part 1 of 2” 의 주요 내용을 리눅스 및 오픈소스 시스템 운영 경험이 있는 독자들에게 상세하게 소개한 글이다.
- 자세한 내용은 아래의 참조 링크를 통해서 정독해 볼것을 권고한다.
- 참조:Brendan Gregg : When to Hire Computer Performance Engineering Team (2025) Part 1 of 2
- 저자는 Peformance Engineering 이라는 분야에 있어서 깊은 기술력과 통찰력으로 리눅스 뿐만 아니라 클라우드 그리고 관찰가능성 (Observablity)까지 다양한 방법론을 전파하고 있다.
- 해당 글은 Performance Engineering 팀이 어떤 일을 하는지 그리고 어떻게 기업의 전략에 기여하게 되는지 상세하게 설명하는 첫번째 포스팅이다.
- 인프라 비용 절감: 성능 엔지니어 팀은 매년 인프라 비용의 5 ~ 10% 절감을 목표로 하며, 누적되면 5년 후 28 ~ 60% 규모의 비용 절감 효과를 기대할 수 있다.
- 성능 최적화 역량: 관찰가능성 도구만으로는 놓치기 쉬운 심층 최적화를 수행하며, 커널, 런타임, 네트워크 등 전 영역에서 튜닝과 디버깅을 실행한다.
- 레일시 개선 : 평균 및 99% 응답 시간 최적화, PEAK 시의 지연 및 오차(outliers) 문제 해결 등 사용자 경험 향상에 핵심이다
- 확장성 및 신뢰성 확보 : 성능 엔지니어는 부하 발생 시 병목 지점을 정확히 진단하고 재설계하여 서비스의 안정성과 성장성 확보에 기여
- 개발 생산성 향상 : 다른 팀이 복잡한 튜닝이나 하드웨어/커널 깊숙한 문제에 발목 잡히지 않도록 도와주며, 제안된 설계도 성능 관점에서 검증하고 조언할 수 있다. 예컨대 “한 시간짜리 미팅이 몇 달 간 엔지니어링 시간 절약으로 이어지는 경우”를 Gregg은 강조.
- 도구 및 기술 내재화 : 예를 들어 AI Flame Graphs 같은 고급 관측 도구를 내부화하고 공유할 수 있도록 한다.
- 저자는 Performance Engineer의 역할을 아래와 같으 A부터 J까지 상세하게 정의하고 있다.
- A. 신제품/신기술 평가: 커널, 런타임, 클라우드 인스턴스, 하드웨어 가속기 등의 성능 테스트, 튜닝, 디버깅.
- B. 내부 도구 개발: 사내 Prometheus/Grafana 인프라, Flame Graphs 도구, eBPF 기반 분석 도구 구축 및 유지.
- C. 병목 분석: 프로파일러, 분산 트레이싱(OpenTelemetry), sysstat, eBPF, Ftrace, perf, kprobes/uprobes, gdb 등 다양한 도구를 활용.
- D. 튜닝 적용: sysctl, 소켓 설정, Java 환경변수, 라이브러리 설정 등 성능을 좌우하는 다양한 변수 설정.
- E. 개발팀 협업: 설계 단계에서 비효율적인 구조를 조기에 발견하고 개선 제안.
- F. POC 구현: eBPF, io_uring 등 최신 기술로 성능 특화 기능을 프로토타입으로 시험.
- G. 내부 코드 성능 개선: 직접 라이브러리나 커널 계층 일부를 패치하거나 성능 개선을 구현.
- H. 용량 계획 및 예측: 구매 가이드, 모니터링 지표 정의, SLA/SLO 수립 등 참여.
- I. 교육과 퍼포먼스 리터러시 전파: 개발자 대상 성능 교육, 팀 간 지식 공유.
- J. 도구/제품 평가 지원: 상용 모니터링/관측 도구 구매 전 성능 관점 평가 및 권고
3. 언제, 몇 명을 채용해야 하는가?
- 저자는 실제 사례를 기반으로 경험적인 기준을 통해서 팀의 구성에 대한 실질적인 기준을 제시한다.
- 기준 A: 연간 인프라 비용 1백만 달러 초과 시 1명, 이후 10 ~ 20M당 1명 추가. 선임:주니어 비율은 1:3 정도 추천.
- 기준 B: 관측/모니터링에 1M달러 이상 지출 중이라면 성능 엔지니어 예산도 유사하거나 그 이상으로 고려해볼수 있다.
- 기준 C: 고객 증가시 지연/신뢰성 문제로 성장 한계에 부딪힌 경우, 기술 스타트업이라도 성능 팀 채용 시점이다.
- 이미 SRE나 시니어 개발자가 성능 개선을 일부 하고 있다면, 이를 환산해 계산해야 합니다. 또한 수확 체감 효과가 있어 팀이 커질수록 낮은 레벨의 절감이 가능한 점도 고려한다.
4. 해당 글이 시사하는 점은 무엇인가?
- 이 글은 비용, 성능, 확장성, 생산성이라는 네 축을 모두 고려해 “성능 엔지니어링 팀”의 필요성과 효과를 실질적으로 설명하며, 특히 커널/오픈소스 기반 시스템 운영 경험이 있는 분께는 내부 도구 개발이나 커널/런타임 트레이싱 기반 튜닝 등의 실질적인 역할이 어떤 것인지 상세히 보여준다.
- 리눅스 커널이나 오픈소스 테크를 깊숙이 다루는 환경에서는 이들이 바로 “회사 내부의 리눅스 퍼포먼스 커미터”와 같은 역할을 수행하는 셈이다.
- 향후 Part 2에서는 채용/육성 방법, 직무설명서 샘플, AI 및 외부 인력 활용 전략 등이 이어집니다. 필요하시면 언제든지 저와 함께 그 내용도 기술적으로 깊게 살펴볼 수 있다.
5. 독자로서의 시사점
- 결국은 성능 엔지니어링 팀의 KPI는 비지니스가 성장하고 서비스가 확장됨으로서 기술 내재화를 통한 조직의 운영이 최종 목표가 되어야 한다.
- 그러기 위해서는 기업의 성장과 투자가 지속적으로 이루어져야 하고 이로 인한 경쟁력을 확보하는 것이 주된 목적이 되어야 하겠다.
- 국내에서는 아직 Performance Engineering에 대한 인력 양성이나 조직의 구성 그리고 투자가 이루어지지 않고 있다
- 이것은 결국 규모의 경제를 따라가지 못하는 시장의 규모가 아쉬운 점이 아닐수 없다.
- 클라우드가 도입되고 성능 = 비용 이라는 두마리 토끼를 잡기 위해서 여러가지 방안들을 고려하고 있지만 결국은 그만큼의 서비스의 규모가 확장되지 않는다면 적극적인 팀의 구성을 고려하기에는 무리가 없지는 않아 보인다.
- 그러나 요즘 하이브리드 클라우드를 고려하거나 다시 프라이빗 클라우드를 고려하고 있는 요즘은 다시 성능 엔지니어링에 대한 고민을 충분히 해볼수 있는 시기가 도래하고 있지는 않을까 내심 기대해 본다.
