O(n²)을 O(n log n)으로 바꾸는 데 이틀을 쓴다. 실제 성능 차이는 0.001초지만, 그게 중요한 게 아니다. 원칙의 문제다.
퍼포먼스 집착자(PERF) 유형은 개발팀에서 가장 수치에 예민한 개발자입니다. 코드가 작동하는 것으로는 충분하지 않습니다. 빠르게 작동해야 합니다. 그리고 그 '빠름'의 기준은 일반인이 느끼기 어려운 마이크로초 단위입니다. 이들의 책상에는 항상 프로파일링 결과 스크린샷과 벤치마크 비교 차트가 있으며, 팀 회의에서 가장 자주 하는 말은 "이 쿼리 실행 계획 보셨어요?"입니다. APM 대시보드가 배경화면이고, p99 레이턴시가 화면에 항상 떠 있습니다.
PERF 유형은 데이터베이스 인덱스, 캐싱 전략, 메모리 관리, CPU 캐시 지역성 같은 개념을 일상 대화에서 자연스럽게 꺼냅니다. 코드리뷰를 할 때도 로직보다 성능을 먼저 봅니다. 루프 안에서 배열 길이를 매번 계산하는 코드를 보면 밤잠을 설칩니다. Redis 캐시 적중률이 95% 아래로 떨어지면 온몸이 반응합니다. p99 레이턴시가 50ms를 넘으면 그날 저녁이 바빠집니다. 이들에게 "충분히 빠르다"는 말은 존재하지 않습니다. 더 빠를 수 있다면 언제나 더 빠르게 만들어야 합니다.
이 유형의 개발자들은 알고리즘 복잡도 분석을 밥 먹듯이 합니다. 새 기능을 구현할 때 가장 먼저 고민하는 것이 "이 방법의 시간복잡도는?"입니다. Big-O 표기법은 이들의 모국어이고, 해시맵과 이진 탐색 트리의 차이는 취침 전 생각하는 주제입니다. 시스템 부하 테스트 결과를 분석하며 보내는 주말이 이들에게는 소소한 행복입니다. 팀원들이 미처 생각하지 못한 트래픽 폭증 시나리오를 미리 대비해두는 것도 이들의 몫입니다. 어느 날 갑자기 언론에 서비스가 소개되어 트래픽이 10배 뛰어도, PERF가 있는 팀은 버텨냅니다.
PERF 유형이 실제로 비즈니스에 가져오는 가치는 측정 가능합니다. 응답 속도 100ms 감소가 전환율 1% 상승으로 이어지고, 서버 비용을 30% 절감하는 최적화가 연간 수천만 원의 절약으로 이어집니다. 대규모 트래픽 상황에서 서비스가 죽지 않고 버텨낸다는 것은 수억 원의 매출 보호를 의미합니다. 이들의 일은 눈에 보이지 않는 곳에서 큰 가치를 만들어냅니다.
PERF 유형의 도구 박스는 깊습니다. Chrome DevTools의 Performance 탭, Flame Graph 분석, heap dump 디버깅까지 다룹니다. 데이터베이스 쪽으로는 실행 계획(EXPLAIN ANALYZE), 인덱스 설계, 파티셔닝, 샤딩 전략을 이해하고 적용합니다. 네트워크 레이어에서는 HTTP/2 멀티플렉싱, gzip/brotli 압축, CDN 캐싱 전략까지 건드립니다.
PERF 유형의 함정은 조기 최적화입니다. "조기 최적화는 만악의 근원"이라는 말처럼, 이들은 때로 프로덕션에서 한 번도 발생하지 않을 병목을 미리 최적화하는 데 귀중한 시간을 씁니다. 프로파일링 먼저, 최적화 나중 원칙을 항상 지켜야 하지만, 이미 머릿속에서 성능 문제가 보이는 PERF 유형에게 이 원칙은 쉽지 않습니다.
PERF 유형이 팀에서 영향력을 키우려면 성능 개선 결과를 비즈니스 언어로 번역하는 능력이 필요합니다. "p99 레이턴시를 200ms에서 80ms로 줄였습니다"보다 "페이지 로딩이 느려서 이탈하던 사용자 중 15%를 붙잡을 수 있게 됐습니다"로 표현할 때 경영진과 PM의 반응이 달라집니다.
"코드가 작동한다고 끝이 아니에요. 동시 사용자 100명이 사용해도 작동해야 진짜 코드죠. 성능 테스트 없는 배포는 눈 감고 운전하는 것과 같아요. 지금은 괜찮아 보여도 언젠가 반드시 터집니다."
— PERF 유형 백엔드 시니어 개발자PERF 유형이 팀에 합류한 첫 주. 기존 시스템을 샅샅이 뜯어보는 장면입니다.
서비스가 갑자기 폭발적으로 성장할 때, 미리 대비해둔 PERF 유형 덕분에 팀이 위기를 넘기는 경우가 많습니다. 이들이 만든 쿼리 최적화, 캐싱 레이어, 비동기 처리 구조는 10배 트래픽이 와도 버텨주는 든든한 기반이 됩니다. 복잡한 성능 문제를 프로파일러와 벤치마크로 데이터 기반으로 진단하고 해결하는 능력은 다른 유형이 쉽게 따라하기 어려운 고유한 강점입니다. 데이터베이스 인덱스 전략, 커넥션 풀 관리, CDN 설정, 압축 알고리즘 선택 등 인프라 레벨의 최적화에서도 탁월한 판단력을 보입니다.
현재 트래픽 100명인 서비스에 10만 명 대비 최적화를 하는 것은 시간 낭비일 수 있습니다. 성능 최적화도 실제 병목이 있을 때 하는 것이 훨씬 효율적인 경우가 많습니다. 최적화된 코드는 종종 이해하기 어려워 팀원들의 유지보수 부담이 높아집니다. 가독성과 성능 사이의 균형을 찾고, 지금 당장 필요한 최적화와 미래를 위한 최적화를 구분하는 현실적 판단력이 성장의 핵심 과제입니다.
Q. 성능 최적화를 어디서 시작해야 하나요?
반드시 프로파일링부터 시작하세요. Chrome DevTools, py-spy, async-profiler 같은 도구로 실제 병목을 찾은 후 거기서 시작하세요. 추측으로 최적화하면 잘못된 곳에 시간을 씁니다.
Q. 백엔드와 프론트엔드 중 어디 성능이 더 중요한가요?
사용자가 느끼는 성능은 전체 스택의 합산입니다. 일반적으로 프론트엔드 최적화가 체감 성능에 빠른 영향을 주지만, 백엔드 병목이 있다면 프론트가 아무리 빨라도 한계가 있습니다.
Q. PERF 유형이 팀원들과 마찰을 줄이려면?
성능 요구사항을 기능 개발 초기에 정의하세요. 'p99 200ms 이하'처럼 구체적인 기준이 있으면 코드 리뷰에서 감정 소모 없이 객관적으로 이야기할 수 있습니다.
💡 성능 지표를 대시보드에 항상 띄워두고 팀 전체가 볼 수 있게 하세요. 자신의 코드 변경이 성능에 미치는 영향을 실시간으로 보게 되면 팀원들도 자연스럽게 성능을 의식하게 됩니다.