O(n²)을 O(n log n)으로 바꾸는 데 이틀을 쓴다. 실제 성능 차이는 0.001초지만, 그게 중요한 게 아니다. 원칙의 문제다.
퍼포먼스 집착자(PERF) 유형은 개발팀에서 가장 수치에 예민한 개발자입니다. 코드가 작동하는 것으로는 충분하지 않습니다. 빠르게 작동해야 합니다. 그리고 그 '빠름'의 기준은 일반인이 느끼기 어려운 마이크로초 단위입니다. 이들의 책상에는 항상 프로파일링 결과 스크린샷과 벤치마크 비교 차트가 있으며, 팀 회의에서 가장 자주 하는 말은 "이 쿼리 실행 계획 보셨어요?"입니다. APM 대시보드가 배경화면이고, p99 레이턴시가 화면에 항상 떠 있습니다.
PERF 유형은 데이터베이스 인덱스, 캐싱 전략, 메모리 관리, CPU 캐시 지역성 같은 개념을 일상 대화에서 자연스럽게 꺼냅니다. 코드리뷰를 할 때도 로직보다 성능을 먼저 봅니다. 루프 안에서 배열 길이를 매번 계산하는 코드를 보면 밤잠을 설칩니다. Redis 캐시 적중률이 95% 아래로 떨어지면 온몸이 반응합니다. p99 레이턴시가 50ms를 넘으면 그날 저녁이 바빠집니다. 이들에게 "충분히 빠르다"는 말은 존재하지 않습니다. 더 빠를 수 있다면 언제나 더 빠르게 만들어야 합니다.
이 유형의 개발자들은 알고리즘 복잡도 분석을 밥 먹듯이 합니다. 새 기능을 구현할 때 가장 먼저 고민하는 것이 "이 방법의 시간복잡도는?"입니다. Big-O 표기법은 이들의 모국어이고, 해시맵과 이진 탐색 트리의 차이는 취침 전 생각하는 주제입니다. 시스템 부하 테스트 결과를 분석하며 보내는 주말이 이들에게는 소소한 행복입니다. 팀원들이 미처 생각하지 못한 트래픽 폭증 시나리오를 미리 대비해두는 것도 이들의 몫입니다. 어느 날 갑자기 언론에 서비스가 소개되어 트래픽이 10배 뛰어도, PERF가 있는 팀은 버텨냅니다.
"코드가 작동한다고 끝이 아니에요. 동시 사용자 100명이 사용해도 작동해야 진짜 코드죠. 성능 테스트 없는 배포는 눈 감고 운전하는 것과 같아요. 지금은 괜찮아 보여도 언젠가 반드시 터집니다."
— PERF 유형 백엔드 시니어 개발자PERF 유형이 팀에 합류한 첫 주. 기존 시스템을 샅샅이 뜯어보는 장면입니다.
서비스가 갑자기 폭발적으로 성장할 때, 미리 대비해둔 PERF 유형 덕분에 팀이 위기를 넘기는 경우가 많습니다. 이들이 만든 쿼리 최적화, 캐싱 레이어, 비동기 처리 구조는 10배 트래픽이 와도 버텨주는 든든한 기반이 됩니다. 복잡한 성능 문제를 프로파일러와 벤치마크로 데이터 기반으로 진단하고 해결하는 능력은 다른 유형이 쉽게 따라하기 어려운 고유한 강점입니다. 데이터베이스 인덱스 전략, 커넥션 풀 관리, CDN 설정, 압축 알고리즘 선택 등 인프라 레벨의 최적화에서도 탁월한 판단력을 보입니다.
현재 트래픽 100명인 서비스에 10만 명 대비 최적화를 하는 것은 시간 낭비일 수 있습니다. 성능 최적화도 실제 병목이 있을 때 하는 것이 훨씬 효율적인 경우가 많습니다. 최적화된 코드는 종종 이해하기 어려워 팀원들의 유지보수 부담이 높아집니다. 가독성과 성능 사이의 균형을 찾고, 지금 당장 필요한 최적화와 미래를 위한 최적화를 구분하는 현실적 판단력이 성장의 핵심 과제입니다.