성능 최적화부터 하려는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-10-25

멘토링을 하면서 포트폴리오를 볼 때 가장 자주 마주치는 장면이 있습니다. 사용자가 10명도 안 되는 개인 프로젝트인데, Redis를 붙이고 Kafka를 달고 대용량 처리를 구현했다고 적어둔 이력서입니다. 왜 이 기술을 썼냐고 물어보면 열에 아홉은 똑같이 답합니다. 대용량 트래픽이 몰렸을 때 성능을 최적화하기 위해서라고요.

솔직히 말씀드리면, 면접관은 그 답을 듣는 순간 한숨을 쉽니다. 트래픽이 없는데 도대체 무엇을 최적화했다는 뜻일까요.

측정 없는 최적화는 상상에 불과합니다

실제 멘토링 4주 차에 2년 차 백엔드 멘티가 들고 온 코드가 있었습니다. DB 조회가 느려질까 봐 모든 조회 API 응답을 메모리 캐시에 넣어두었더군요. 응답 시간 측정 지표를 확인해 보니 애초에 쿼리 실행 시간은 4ms에 불과했습니다. 반면 비즈니스 로직 안에서 외부 API를 동기로 호출하느라 800ms가 걸리고 있었습니다.

엉뚱한 곳에 깁스를 한 셈입니다.

도널드 크누스는 이른 최적화가 모든 악의 근원이라고 했습니다. 왜냐하면 측정하지 않은 개발자는 자신의 감을 믿고, 개발자의 직관은 실무에서 90% 이상 빗나가기 때문입니다. 최적화의 첫 단추는 코드를 고치는 게 아닙니다. APM이나 로그로 병목 지점의 정확한 수치를 확인하는 일입니다.

복잡성은 반드시 대가를 청구합니다

기술을 하나 더 얹는 건 쉽습니다. 컨테이너 명령어 한 줄이면 Redis도 띄우고 메시지 큐도 띄울 수 있습니다. 하지만 캐시를 도입하는 순간 캐시 무효화와 데이터 정합성이라는 까다로운 숙제가 따라옵니다. 분산 환경을 만들면 네트워크 지연과 유실 처리가 발목을 잡습니다.

제가 10년 넘게 실무를 하며 200명 넘는 주니어를 지켜보며 배운 사실이 있습니다. 가장 빠른 코드는 실행하지 않는 코드이고, 가장 장애가 안 나는 시스템은 부품이 적은 시스템입니다. 풀려는 문제는 단순한데 아키텍처만 거창한 코드는 실력이 아닙니다. 현업 시니어들은 최신 인프라를 늘어놓는 사람보다, 단일 RDB 인덱스 설계 하나로 초당 수천 건을 단단하게 받아내는 개발자를 훨씬 신뢰합니다.

진짜 실력은 단순함에서 나옵니다

이력서에 화려한 오픈소스 기술 이름을 빼곡하게 채우지 마세요. 그 대신 단 하나의 엔드포인트라도 집요하게 파고든 과정을 보여줘야 합니다.

"JPA N+1 문제를 발견하고 쿼리 호출을 24번에서 1번으로 줄였습니다."
"복합 인덱스를 적용해 200만 건 데이터의 조회 응답을 1.8초에서 0.05초로 단축했습니다."

면접관이 진짜 검증하고 싶은 건 이런 문장입니다. 문제가 정확히 어디에 있었는지, 그걸 어떤 숫자로 측정했는지, 그리고 가장 단순한 방식으로 어떻게 해결했는지입니다. 화려한 기술 뒤에 숨지 마세요. 단순함을 지키며 문제를 끝까지 파고드는 태도가 여러분의 진짜 무기가 됩니다.