기업이 성능 엔지니어링 팀을 왜·어떻게 구성하는지, 그 ROI(비용 절감·지연 시간 감소·확장성/신뢰성 향상·엔지니어링 속도)를 설명하고 언제 몇 명을 채용해야 하는지에 대한 경험 기반 가이드를 제공한다.
저는 컴퓨터 성능 분야의 리더로서 여러 회사로부터 성능 엔지니어링 팀을 어떻게(그리고 왜) 구성해야 하는지 질문을 받아 왔습니다. 이 주제는 폭넓게 유용하다고 생각해 제 조언을 여기 공유합니다.
미국의 대형 테크 기업들은(같은 의미의 다른 직함을 쓰기도 하지만) 인프라 비용과 서비스 지연 시간이 과도하게 커지지 않도록, 그리고 피크 부하에서 서비스가 신뢰성 있게 동작하도록 보장하기 위해 성능 엔지니어를 채용합니다. 새로 만들어진 성능 팀은 첫 1~2년 동안 상용 성능/관측(Observability) 도구를 이미 사용 중인 회사에서도 인프라 지출을 절반 으로 줄일 만큼의 최적화를 찾아내는 경우가 많습니다. 성능 엔지니어는 그런 도구만으로는 할 수 없는 훨씬 많은 일을 합니다. 개발 팀 및 벤더와 함께 구축, 테스트, 디버깅, 튜닝을 수행하고, 새로운 성능 솔루션의 도입을 이끌며, 도구가 놓칠 수 있는 깊은 최적화까지 찾아냅니다.
저는 과거 넷플릭스의 성능 엔지니어링 팀에서 일했습니다. 넷플릭스는 수십만 대의 AWS 인스턴스 위에서 돌아가는 대규모 테크 소비자(consumer) 서비스입니다. 지금은 인텔(대형 테크 벤더)에서 인텔 및 고객사를 위해 비슷한 일을 하고 있습니다. 이 분야의 리더로서 저는 여러 회사의 성능 팀 및 성능 업무를 수행하는 인력과도 폭넓게 교류해 왔습니다. 이 글에서는 이 팀들이 무엇을 하는지, 그리고 언제 이런 팀 구성을 고려해야 하는지를 설명하겠습니다. 2부에서는 예시 채용 공고, 전문 분야, 조언, 함정, AI에 대한 코멘트, 그리고 성능 팀을 채용할 수 없을 때 무엇을 해야 하는지까지 다루겠습니다.
인텔 같은 하드웨어 벤더 입장에서는 성능 엔지니어 채용을 정당화하기 쉽습니다. 매출에 가장 큰 영향을 미치는 요소가 경쟁사 대비 성능 우위이기 때문입니다. 하지만 이 글의 초점은 벤더가 아닌, 비용과 지연 시간(특히 이상치)을 낮추기 위해 이런 인력을 채용하는 ‘기술 의존도가 높은’ 일반 기업들입니다(예: 은행, 통신, 국방, AI, 테크 기반 기업, 그리고 백엔드 컴퓨팅/AI에 연간 100만 달러 이상을 쓰는 누구든).
핵심 ROI는 인프라 비용 절감, 지연 시간 감소, 확장성 및 신뢰성 개선, 더 빠른 엔지니어링입니다. 비용 절감만으로도 성능 팀을 정당화할 수 있고 팀 규모 산정에도 도움이 되므로 이를 깊게 다루겠지만, 다른 ROI들도 고려할 가치가 있으며 회사의 성장 단계에 따라서는 더 중요할 수도 있습니다.
적절한 규모의 성능 팀이라면 튜닝과 제품/기술 도입을 통해 연간 510%의 비용 절감을 목표로 해야 합니다. (적절한 규모는 ‘언제 채용할까’ 섹션에서 설명합니다.) 많은 대기업에서는 5%면 “좋은” 성과, 10%면 “훌륭한” 성과로 여깁니다. 실제로 이를 달성한다는 것은 인프라 일부 구간에서 1580% 같은 큰 승리를 찾아내고, 그것이 전체로는 5~10%로 반영되는 형태일 수 있습니다.
성과는 누적됩니다. 매년 5% 절감을 달성하는 팀은 5년차에 28% 절감(복리처럼)이 됩니다. 연 2%처럼 소박한 수치도 시간이 지나면 유의미해집니다. 누적 수치는 커질 수 있지만, 장기적으로 팀을 유지하려면 매년 새로운 절감 기회를 계속 찾아야 하며, 항상 다음 5~10%에 집중해야 합니다.
회사가 이 일에 투자하는 이유는 비용 절감만이 아닐 수도 있습니다. 특히 고객에게 비용을 전가하는 비슷한 테크 기반 서비스를 제공하는 기업이라면, 더 나은 비용/성능 비율을 제공함으로써 경쟁 우위를 확보하는 것이 목적일 수 있습니다.
이전에 성능 엔지니어를 둔 적이 없는 조직은, 첫 1~2년 동안 ‘낮은 과실(low-hanging fruit)’이 충분해 인프라 비용을 절반(50%)까지 줄이는 것도 가능합니다. 이는 인력 수, 전문성 수준, 이미 다른 인력(시니어 개발자, SRE)이 수행 중인 성능 작업의 정도, 커스텀 코드 비중, 스택의 복잡성과 변동성에 달려 있습니다.
구체적인 성과를 공개적으로 공유할 수 있다면 좋겠지만, 보통은 다음처럼 보일 것입니다:
“올해 우리는 회사의 인프라 지출을 연 6,000만 달러에서 5,700만 달러로 5% 줄이는 데 기여했습니다. 게다가 사용자 기반이 3% 성장했기 때문에, 실제로는 사용자당 비용(cost-per-user)을 8% 절감하여 올해와 향후 모든 해에 걸쳐 연 500만 달러를 절약했습니다.”
하지만 이런 수치는 회사 성장, 재무 건전성, 비공개 인프라 할인 등 민감한 정보를 노출할 수 있어 재무적으로 민감한 정보로 취급되는 경우가 많습니다. 성능 엔지니어로서 저는 백엔드 서비스에서의 퍼센트 단위 개선은 공개적으로 말할 수 있지만, 이를 달러 금액으로 환산해 말하긴 대개 어렵습니다. 그러면 다른 회사들이 성능 엔지니어링의 가치를 이해하는 데 도움이 덜 됩니다.
실리콘밸리에서는 인력이 회사 간 이동을 자주 하고 최신 관행이 입소문으로 퍼지기 때문에 이 문제가 덜하지만, 먼 나라들에서는 인프라 지출이 충분히 큰 회사가 있어도 성능 엔지니어링이 아직 거의 존재하지 않기도 합니다.
위 예시에서 ‘총 8% 개선’은 보통 다음처럼 구성될 수 있습니다:
개발자/SRE enablement와 벤더 도입에서는 성능 팀이 직접 성과를 내는 것이 아니라 다른 팀과 벤더가 성과를 내도록 ‘가능하게’ 합니다. 예를 들어 넷플릭스에서 일할 때 우리는 개발자들이 매일 사용하는 플레임 그래프 “셀프 서비스” 애플리케이션을 만들고 유지했으며, 매년 여러 제품 도입 작업을 수행했습니다. 이런 부분도 성능 팀 ROI로 고려되어야 합니다.
서비스의 응답 시간(지연 시간)을 줄이는 것은 성능 엔지니어링의 큰 부분입니다. 평균 지연 시간, 99퍼센타일 지연 시간, 이상치 지연 시간을 분석하고, 지연 시간 SLA/SLO를 만족시키며, 교란(perturbation)이나 피크 사용 중에도 허용 가능한 지연 시간을 보장하는 일을 포함합니다.
앞서 설명한 비용 최적화 중 많은 것들은 평균 지연 시간도 줄이지만, 지연 시간 변동성이나 이상치는 남을 수 있습니다. 예를 들어 5분에 한 번 실행되는 시스템 작업은 비용이나 CPU 사용량이 미미할 수 있지만, 잠깐 애플리케이션을 교란해 지연 시간 이상치를 유발할 수 있습니다. 이런 문제는 다른 방식으로 디버깅하며, 모니터링, 로그, 분산 트레이싱, 시스템 레벨 트레이싱, 패킷 로그, 커스텀 임시(ad-hoc) 도구 등을 사용하곤 합니다.
때로 높은 지연 시간은 요청 유형 자체 때문일 수도 있습니다(시스템은 정상이나, 사용자가 느린 작업을 요청함). 또는 부하의 자연스러운 결과(대기열 이론, tail latency)일 수도 있습니다. 또 다른 경우에는 소프트웨어 스택 여러 계층 간의 복잡한 상호작용이나, 여러 네트워크 엔드포인트 간 상호작용에서 비롯되기도 합니다.
관련된 여담: 성능 안티패턴 중 하나는, 어떤 성능 문제를 디버깅하려고 모니터링 도구를 설치했는데 그 도구가 주기적으로 작업을 수행하면서 애플리케이션 지연 시간 이상치를 유발하는 경우입니다. 그러면 회사는 문제를 하나 더 얻게 됩니다. 팁: 모든 모니터링 에이전트를 꺼 보고 문제가 사라지는지 확인해 보세요.
지연 시간은 최종 사용자 경험 개선의 핵심 요소이지만, 처리량(throughput)과 병렬성(parallelism)도 관련 지표입니다.
부하가 걸린 시스템은 지연 시간이 지수적으로 증가하거나, 연쇄 장애(cascading failure)로 인해 장애나 서비스 중단으로 이어질 수 있습니다. 성능 엔지니어는 커스텀 부하 발생기(load generator)와 벤치마크로 자원 확장성을 시험하고, 시스템 전 영역을 분석 도구로 살펴 병목을 찾아 해결합니다. 성능 엔지니어는 확장성 한계를 측정하는 것에 그치지 않고, 제한 요인이 무엇인지와 이를 해결해 더 확장하려면 어떻게 해야 하는지도 설명할 수 있어야 합니다.
안정적이고 성능이 좋은 서비스는 회사에 대한 신뢰를 쌓아 고객 성장을 더 빠르게 만들 수 있으며, 엔터프라이즈 SLA/SLO를 만족하기 위한 요구사항일 수도 있습니다.
제가 선 마이크로시스템즈(벤더)에서 겪은 확장성 이야기를 하나 공유하겠습니다. 목표는 스토리지 시스템에서 업계 1위 처리량을 달성하는 것이었고, 이를 위해서는 100만 IOPS를 넘어야 했습니다. 예상 병목은 회전 디스크였습니다. 저는 자체 부하 발생기와 분석 도구를 만들어 분석했고, 놀랍게도 실제 병목은 CPU 인터커넥트였습니다. 인터커넥트는 AMD HyperTransport 1이었고, AMD는 HT3와 더 빠른 CPU가 탑재된 새 시스템 보드를 보내왔습니다. 설치했는데… 성능이 동일했습니다. 제 분석이 틀렸다고 생각해 낙담했지만, 알고 보니 AMD가 실수로 HT1 보드를 보낸 것이었습니다. 이후 진짜 HT3 보드를 받자 성능이 최대 75%까지 증가했습니다!
CPU 인터커넥트(존재할 때)는 기업들이 보통 확인하지 않는 수많은 구성 요소 중 하나이며, 상용 관측 도구도 이런 것들은 확인해 주지 않습니다.
성능 엔지니어는 개발자의 코드베이스 밖의 구성 요소를 담당해 개발자가 본업에 집중하도록 해주고, 더 큰 성능 예산을 제공하여 비용이 큰 기능도 더 빨리 도입할 수 있게 합니다. 초기 단계 기업에서는 이 ROI가 가장 중요할 수도 있는데(때로 engineering velocity 라고도 부릅니다), 구체적으로는 다음과 같습니다:
외부 성능 방해 요소 제거: 개발 팀이 자기 코드베이스에서는 매우 빠르게 개발하고 있어도, 라이브러리, 커널, 하이퍼바이저, 하드웨어 구성 요소에서 성능 문제를 만나면 새로운 영역과 분석 도구를 익히느라 속도가 떨어질 수 있습니다. 또는 누군가 해커뉴스에서 본 새로운 성능 기술을 평가해야 할지 고민할 수도 있습니다. 이런 성능 활동을 성능 팀으로 오프로딩하면 개발자는 코드에 집중하며 속도를 유지할 수 있습니다. 이는 OS, 배포, 신뢰성 이슈를 SRE/DevOps 팀에 오프로딩하는 것과 유사합니다.
비싼 프로젝트 실패를 우회: 좋은 성능 엔지니어는 소프트웨어와 하드웨어 스택(리눅스 커널 포함) 내부를 잘 압니다. 많은 개발자는 그렇지 않고 대부분의 경우 그럴 필요도 없습니다. 하지만 그 때문에 개발자가 잘못된 가정에 기반한 아이디어를 제안하기도 합니다(실제로 매우 흔합니다). 성능 엔지니어링 팀과 1시간 미팅하는 것만으로 몇 달의 엔지니어링 노력을 아낄 수 있습니다. 개발자가 아이디어 A와 B를 설명하면, 성능 팀이 “A는 안 되고 이유는 이렇고, B는 괜찮아 보이며 우리가 도울 수 있다”라고 말하는 식입니다. 1시간에 몇 달을 절약하는 셈이죠.
예로, 수년 전 한 대형 테크 회사에서 ‘성능이 10배 좋아질 것’이라는 믿음으로 새로운 이벤트 기반 코딩 프레임워크를 도입하자는 제안을 분석한 적이 있습니다. 제 분석 결과 실제 이득은 10% 미만 이었습니다. 프로젝트는 중단되었습니다. 이는 전사 코드를 모두 재작성해야 하는 프로젝트(1년 걸릴 것으로 예상)를 막았고, 제 경력에서 가장 큰 성능 ‘승리’ 중 하나였습니다. 퍼센트로 측정되는 승리가 아니라 절약된 엔지니어링 시간으로 측정된 승리였습니다.
가속 도구 개발: 앞서 언급했듯 성능 팀은 개발자가 사용 가능한 커스텀 관측 도구를 만들어 이슈를 더 빨리 발견하고 개발을 가속할 수 있습니다. 예를 들어 저는 여기에서 AI 플레임 그래프에 대해 글을 써 왔는데, 이는 커널과 하드웨어 내부를 활용해 구축한 것입니다.
기능 도입 가속: 비용과 지연 시간을 줄이면 제한된 인프라/지연 시간 예산 내에서 더 많은 일을 할 수 있어 서비스의 역량을 확장하거나, 요청당 더 많은 처리를 욱여넣을 수 있습니다. 어떤 회사는 기능 추가에 비용 한도를 두기도 하므로, 최적화 작업이 기능 승인을 가능하게 만들기도 합니다. 이런 작업은 신뢰성과 낮은 지연 시간, 경쟁력 있는 비용/성능을 유지하면서 경쟁사보다 빠르게 기능을 도입하게 해줍니다.
벤더가 아닌 테크 소비 기업 기준으로 요약하면 다음과 같습니다.
A. 새 소프트웨어/하드웨어 제품을 테스트·디버깅·튜닝하여 성능 개선점을 찾고, 전사 도입을 추진한다.
예: 새로운 클라우드 인스턴스 타입, 언어 런타임, JVM 버전, JVM 서브시스템(새 GC 알고리즘이나 컴파일러: Graal vs c2), 시스템 라이브러리(glibc vs tcmalloc 등), 커널(Linux vs BSD) 및 버전, 컴파일러(gcc, llvm, icc), 프로세서 기능(AVX, QAT 등), 하드웨어 가속기 등. 최신 기술이 주장하는 성능을 실제로 내도록 모든 것을 디버깅하고 수정·패치하는 데 몇 달이 걸릴 수도 있습니다.
B. 다른 팀이 성능 개선을 찾는 데 사용할 수 있는 커스텀 분석 도구 등 사내 성능 솔루션을 개발한다.
예: Prometheus와 Grafana 기반 커스텀 모니터링, 원클릭 플레임 그래프, eBPF 기반 분석 도구. 모두 오픈소스 기반이지만, 로컬 환경에서 동작하게 하고 기존 도구와 통합하며 다른 팀에 사용법을 교육하고 유지보수할 사람이 필요합니다.
C. 워크로드 병목과 지연 시간 이상치를 식별·감소시키기 위해 딥다이브 분석을 수행한다.
예: 코드 프로파일러(CPU 플레임 그래프), 분산 트레이서(OpenTelemetry 및 제품), 애플리케이션 로그, 시스템 카운터(리눅스: sysstat), 시스템 트레이서(리눅스: eBPF, Ftrace, perf), 정적/동적 계측(리눅스: kprobes, uprobes), 디버거(gdb 등), 하드웨어 카운터(리눅스: perf), 드물게는 하드웨어 명령어 트레이싱. SSH 세션에서 라이브 디버깅을 많이 하며, 효율적으로 근본 원인을 찾기 위한 방법론을 따릅니다. 이를 위해 커스텀 도구(미니 부하 발생기, 관측 도구 등)를 개발해야 할 때도 있습니다.
D. 튜너블 파라미터와 구성 선택을 통해 소프트웨어/하드웨어를 최적화한다.
예: 시스템 튜너블(리눅스: sysctl), 네트워크 튜너블(소켓 옵션, qdisc), 디바이스 튜너블, 런타임 튜너블(Java -XX:*), 라이브러리 설정, 환경 변수 등. (C)와 마찬가지로 SSH 접근이 필요하고, 슈퍼유저 권한이 필요할 가능성이 큽니다.
E. 개발 팀(내부/외부)과 협업해 개발 초기에 확장 불가능한 솔루션을 조기에 잡고, 이후 성능 개선을 제안하거나 테스트한다.
예: 수평 확장 시 네트워크 링크를 포화시킬 통신 계층을 조기에 식별; 개발자가 좋은 최적화 아이디어가 있지만 구현이 잘 안 되어 도움 필요; 회사가 쓰는 소프트웨어에 성능 관련 PR이 있지만 2년 동안 방치되어 있고, 충돌 해결·테스트·머지 설득을 해줄 사람이 필요.
F. 새로운 성능 기술에 대한 POC(개념 증명) 데모를 만든다.
예: Linux eBPF와 io_uring은 핫패스 커널 기반 가속기로 개발되면 큰 성능 개선을 제공할 수 있지만, 회사에 유효함을 보여주는 최소한의 POC를 누군가 만들어야 합니다. 이런 기술은 개발자가 혼자 시도하기엔 보통 너무 난해합니다.
G. 내부/외부 코드에 대해 직접 성능 개선을 개발한다.
예: 성능 엔지니어는 적절한 사람에게 요청하는 것만으로도 많은 일을 하지만, 때로 회사에 필요한 Linux/런타임/DB 성능 수정 작업을 코딩할 시간이 아무에게도 없어서 성능 엔지니어가 직접 맡기도 합니다. 우리는 여러 언어를 계속 오가므로 전업 개발자만큼 빠르진 않고, 새 코드베이스의 커미터가 되면 추가(그리고 시간 많이 드는) 검토를 받는 것이 일반적입니다.
H. 용량 계획(capacity planning): 구매 가이드, 모니터링할 메트릭 선정, 병목 예측.
예: 하드웨어 구매를 위한 모델링 및 성능 특성화, 자원 사용률 모니터링으로 용량 이슈 예측(요즘은 개발자/SRE가 모니터링 도구로 하기도 함), 모니터링 도구에서 알림 및 오토스케일링 룰로 감시할 최적의 메트릭 제안, 비즈니스 부서와 협업해 실용적인 SLA/SLO 정의.
I. 지식 공유로 엔지니어링 역량을 끌어올린다.
예: 개발자가 더 효율적인 소프트웨어를 만들도록 성능 교육 제공; 팀 간(사일로) 성능 학습 내용을 전달하는 연결 고리 역할을 해 재작업과 재발견을 방지.
J. 성능 솔루션 구매를 안내하는 사내 전문성을 제공한다.
예: 관측성, 텔레메트리, eBPF 같은 주제에 대한 사내 전문성은 상용 제품을 평가할 때 기능과 오버헤드 비용을 판단하는 데 도움을 줍니다. 어떤 것이 사실상 Prometheus+Grafana(혹은 제 오픈소스 eBPF 도구)를 ‘정장 입혀’ 파는 것인지도 알아볼 수 있습니다. 전문성이 없으면 바가지를 쓰기 쉽고, 도입한 도구가 제공하는 이득보다 더 큰 인프라 비용 증가를 유발할 수도 있습니다(오버헤드가 10%를 넘는 것도 봤습니다).
(A)에서 말한 ‘새 제품 테스트’를 조금 더 풀어보면: 다른 인력은 README대로 구성한 뒤 부하 테스트를 돌리고 결과를 경영진에게 공유하곤 합니다. 이런 일을 전담하는 “성능 테스터(performance tester)”를 따로 채용하는 회사도 있습니다. 성능 엔지니어는 같은 기술로도 더 많은 것을 얻습니다. 테스트 중에 분석기를 함께 돌려 제한 요인이 무엇인지 이해하는(“능동 벤치마킹(active benchmarking)”) 방식으로 접근하고, 추가로 5%, 50% 혹은 그 이상의 성능을 끌어내도록 튜닝합니다. 또 제한 요인이 의도하지 않은 대상일 수도 있음을 발견합니다(예: 실제로는 캐시 계층을 테스트하고 있었다든가). 어떤 성능 테스트든 제한 요인에 대한 설명이 동반되어야 합니다. 설명이 없으면 테스트를 분석하지 않았고 결과가 엉터리일 수 있음을 드러낼 뿐입니다. 단순히 “왜 결과가 두 배가 아니죠?”라고 물어보면 됩니다.
여담: “CPU bound”는 설명이 아닙니다. (a) 클럭 속도, (b) 스레드 풀 크기, (c) 코어 수, (d) 메모리 버스(커널은 이를 %CPU 카운터에 오해를 불러일으키게 포함시키기도 함), 또는 다른 것(전력, 발열, CPU 서브시스템 병목) 중 무엇을 말하는 건가요? 각각 회사가 취할 액션이 달라집니다(예: (a) 더 빠른 프로세서; (b) 더 많은 스레드; (c) 더 많은 코어; (d) 더 빠른 메모리/더 큰 캐시/NUMA 감소/zero copy 같은 소프트웨어 기법). 이건 일반론일 뿐입니다. CPU bound 워크로드의 코드 자체도 비효율을 찾기 위해 분석되며, 때로는 명령어 수준까지 들여다봅니다.
일상적으로 성능 엔지니어는 깨진 빌드를 고치고 워크로드를 구성하는 데도 많은 시간을 씁니다. 왜냐하면 새로운 패치와 최신(bleeding-edge) 소프트웨어 버전을 가장 먼저 테스트하는 사람이기 때문입니다.
여기까지는 ‘기술을 소비하는’ 회사에 대한 이야기였습니다. ‘기술을 판매하는’ 벤더의 성능 엔지니어링은 설계 모델링, 프로토타입/개발 중인 SW/HW 분석, 경쟁 벤치마킹, 새 제품 릴리스의 회귀(regression) 방지 테스트, 판매 전후 성능 분석 지원 등을 포함합니다. (이는 Systems Performance 2판 1장에서 더 자세히 설명합니다.)
제가 만난 대부분의 회사는 프로젝트와 개인에 흩어진 형태로 이미 어떤 성능 작업을 하고 있습니다. 하지만 전사적으로 모든 것을 깊게 들여다보는 중앙 성능 엔지니어링 팀은 아직 없는 경우가 많습니다. 그러면 관심이 군데군데만 미치고, 어떤 영역은 괜찮지만 다른 곳은 부족하거나 아예 비어 있게 됩니다. 중앙 성능 팀은 전체를 보고 잠재 ROI에 따라 우선순위를 정합니다.
성능 엔지니어링 팀을 언제부터 전사적으로 만들기 시작해야 하는지, 그리고 팀 규모를 어떻게 산정할지에 대한 대략적인 규칙을 몇 가지 제시합니다(끝의 단서 참고).
첫 엔지니어는 낮은 과실을 일부 찾아내며, 회사 지출이 연 100만 달러를 넘기기 시작하면 충분히 비용 대비 효과가 있어야 합니다. 이후에는 연 1,000만~2,000만 달러마다 성능 엔지니어 1명을 추가하고, 주니어:시니어 비율을 3:1로 유지하는 것을 고려하겠습니다.
여기서 사용하는 값은 성능 엔지니어의 역량, 환경의 복잡성, 성능 개선을 얼마나 공격적으로 추진하고 싶은지에 따라 달라집니다. 연 2,000만 달러 지출에서 연 5% 개선이면 직원 1명당 100만 달러 절감(인건비 제외)입니다. 반면 연 1,000만 달러 지출이라면 직원 1명당 100만 달러 절감을 위해 매년 10% 개선을 달성해야 합니다.
지출이 계속 커지면 인력을 계속 늘리게 되고, 그렇게 되면 낮은 과실이 줄어들어 일을 하기가 더 어려워진다는 점도 고려해야 합니다. 하지만 사이트 규모와 복잡성도 커지면서, 해결해야 할 새로운 성능 이슈도 계속 생깁니다. 또한 대규모에서는 더 작은 퍼센트의 개선도 큰 임팩트를 가지므로, 성장하는 성능 팀은(어느 정도 한계까지는) 계속 비용 대비 효과적일 것이라 기대합니다. (제가 본 가장 큰 팀은 대략 150명 수준에서 멈추는 경향이 있었습니다.)
관측성 제품에 연 100만 달러를 쓰고 있다면, 성능 엔지니어링 팀에도 연 100만 달러를 쓸 수 있습니다(예: 좋은 인력 3~4명). 관측성 제품에 연 5만 달러만 쓰고 있다면 그 비용으로 성능 엔지니어를 채용하긴 어렵지만, 컨설턴트를 부르거나 성능 교육 및 컨퍼런스 참석 비용을 지불할 수는 있습니다.
인력이 시간이 지나며 인프라 비용을 절반으로 줄일 수 있다고 기대한다면, 보통 인스턴스/서버 수에 따라 함께 증가하는 모니터링 비용 절감만으로도 새 인력의 비용을 상쇄할 수 있습니다. 그리고 이 엔지니어들은 인프라 지출 자체를 적극적으로 줄이므로, 총 절감액은 훨씬 더 큽니다.
어떤 소규모 회사나 스타트업은 백엔드 컴퓨팅보다 커피에 더 많은 돈을 쓴다고 말하며, 미미한 비용 절감을 위해 제한된 개발자 시간을 낭비하고 싶지 않다고 합니다. 하지만 새로운 고객이 몰려오면 확장성 문제에 부딪혀 지연 시간이 너무 높거나 신뢰성이 일관되지 않아 고객을 잃기 시작할 수 있습니다. 보통 그때가 성능 엔지니어링에 투자하기 좋은 시점입니다.
다음은 벤더가 아닌 회사에서의 성능 엔지니어링 작업에 관한 글 예시입니다:
이 목록에 Bank of America, Wells Fargo, JPMorgan Chase, CitiGroup도 추가하고 싶습니다. 링크드인에서 “performance engineer” 직함을 가진 인력이 많다는 것은 찾을 수 있지만, 그들의 작업에 대한 공개 글은 찾기 어렵습니다. 중앙 성능 엔지니어링 팀의 정본(canonical) 목록도 있으면 좋겠지만, 조직도 데이터는 온라인에서 찾기 어려울 수 있고, 직원들이 항상 “성능 엔지니어”라고 자신을 부르지도 않습니다. 주목할 다른 키워드는 insights, monitoring, _observability_이며, 어떤 곳은 단지 “support engineer”라고 부르기도 합니다.
또한 이 글에서 다루지 않았지만, 하드웨어/소프트웨어/클라우드 벤더(Intel, AMD, NVIDIA, Apple, Microsoft, Google, Amazon, Red Hat 등)와 성능 솔루션 회사에서도 성능 엔지니어링이 많이 이뤄지고 있습니다. 이 글에서는 벤더가 아닌 회사를 중심으로 다루고자 했습니다.
전 세계적으로 성능 엔지니어링에 종사하는 사람이 얼마나 되는지에 대한 구체적 데이터는 본 적이 없습니다. 제 추정은 다음과 같습니다:
링크드인이 엔터프라이즈 접근 권한이 있다면 더 나은 추정치를 제공할 수도 있습니다.
성능 엔지니어링 팀을 채용해야 하는 이유는 인프라 비용 절감, 지연 시간 감소, 확장성과 신뢰성 개선, 더 빠른 엔지니어링 등 다양합니다. 비용 절감만으로도 팀 채용을 정당화할 수 있습니다. 왜냐하면 팀은 매년 5~10% 비용 절감을 목표로 해야 하고, 이것이 수년에 걸쳐 누적되면 훨씬 큰 절감(5년 후 28%~61%)이 되기 때문입니다.
이 글에서는 성능 엔지니어가 하는 일을 설명하고 채용에 대한 규칙을 제시했습니다:
A) 인프라 지출이 연 100만 달러를 넘으면 1명, 이후 연 1,000만~2,000만 달러마다 1명 추가.
B) 성능 인력 지출은 관측(모니터링) 제품 지출과 같거나 그 이상이어야 함.
또한 이미 성능 작업에 집중하는 시니어 개발자나 SRE가 있을 가능성이 크며, 그만큼 새로 필요한 성능 엔지니어 수가 줄어들 수 있다는 점을 기억하세요.
저는 인프라에 연 수백만 달러를 쓰면서도(단지 성능 테스팅 역할은 있어도, 성능 엔지니어링과는 다릅니다) 성능 엔지니어 역할이 없는 회사에 다니는 사람들을 만나 왔습니다. 이 글이 회사들이 성능 엔지니어링의 가치를 이해하고, 언제·몇 명을 채용해야 하는지 이해하는 데 도움이 되길 바랍니다.
좋은 성능 엔지니어를 채용하는 것은 쉽지 않습니다. 전문 분야이고 인재 풀이 제한적이기 때문입니다. 2부에서는 성능 엔지니어링 팀을 채용하거나 교육하는 방법, 예시 채용 공고와 팁, 그리고 성능 팀을 채용할 수 없을 때 무엇을 해야 하는지에 대해 논의하겠습니다.
피드백과 제안에 감사드립니다: Vadim Filanovsky(OpenAI), Jason Koch(Netflix), Ambud Sharma(Pinterest), Harshad Sane(Netflix), Ed Hunter, Deirdre Straughan.
