개발자 이력서에서 숫자는 얼마나 중요할까?

"숫자를 넣으면 이력서가 좋아진다"는 말은 반만 맞습니다. 숫자는 근거가 있을 때만 힘을 가집니다. 의미 없는 숫자나 설명할 수 없는 숫자는 오히려 신뢰를 떨어뜨립니다. 숫자를 어떻게, 어디까지 쓸지 정리했습니다.

숫자가 도움이 되는 이유

• 일의 크기를 가늠하게 해 줍니다. (얼마나 큰 시스템, 얼마나 많은 사용자)
• 변화의 방향과 정도를 보여 줍니다. (얼마나 좋아졌는가)
• 이야기를 검증 가능한 것으로 만들어 줍니다. 면접에서 "이 숫자는 어떻게 측정했나요?"라는 질문이 자연스럽게 이어집니다.

그래서 숫자는 마지막 장식이 아니라 대화를 시작하는 단서입니다.

쓸 만한 숫자의 네 종류

1. 규모: 처리하는 요청 수, 데이터 양, 사용자 수, 관리하는 서비스 수
2. 개선: 이전과 이후의 변화 (응답 시간, 오류율, 빌드 시간)
3. 빈도: 장애 횟수, 배포 주기, 반복되던 수작업의 횟수
4. 자원: 절감한 시간, 비용, 인력

규모만 있고 내가 한 일이 없으면 "큰 곳에 있었다"는 인상만 남습니다. 내가 한 일과 변화가 함께 있어야 합니다.

숫자에는 기준선이 필요하다

"성능을 50% 개선"은 정보가 부족합니다. 무엇의 50%인지, 원래 얼마였는지, 언제 측정했는지가 없으면 판단할 수 없습니다.

예시(재구성한 문장입니다)

• 약함: API 성능 50% 개선

• 강함: 이벤트 기간 상품 목록 API의 응답 시간이 길어지는 문제를 개선. 평소 대비 느려지던 구간의 응답 시간을 목표 수준 이내로 안정화하고, 부하 시험으로 전후를 비교

두 번째 문장은 수치가 눈에 띄게 크지 않아도 무엇을 어떻게 확인했는지가 보입니다. 기준선과 측정 방법이 있는 작은 숫자가 맥락 없는 큰 숫자보다 낫습니다.

이 숫자는 누구의 몫인가

팀의 성과를 내 성과처럼 적으면 신뢰를 잃을 수 있습니다. 팀의 결과와 내 기여를 구분해 주세요.

• "팀이 서비스 지연 시간을 줄였고, 그중 저는 캐시 구조 설계와 적용을 맡았습니다"
• "월 장애 건수가 줄었고, 이 중 재처리 구조 개선을 제가 설계했습니다"

내 몫이 작더라도 정확하게 쓰는 편이 길게 보면 훨씬 유리합니다.

숫자가 없을 때는

모든 경험에 숫자가 있지는 않습니다. 없는 숫자를 만들어 낼 필요는 없습니다.

• 전후 상태를 말로 설명합니다. (이전에는 수작업이었고, 이후에는 자동화되어 담당자가 따로 챙기지 않게 됨)
• 범위를 씁니다. (수십 개 서비스, 하루 수만 건 등 대략의 크기를 정직하게)
• 채택과 지속을 씁니다. (팀 전체가 쓰게 되었고, 이후에도 유지되고 있음)
• 다른 사람의 반응이 있다면 사실 그대로 씁니다.

피해야 할 것

• 만들어 낸 숫자: 면접에서 근거를 물으면 바로 드러납니다.
• 의미 없는 큰 숫자: "코드 10만 줄 작성" 같은 지표는 일의 가치를 말해 주지 않습니다.
• 측정 방법을 모르는 숫자: 이전 회사에서 들은 숫자를 그대로 옮기지 마세요.
• 기밀 정보: 정확한 매출, 사용자 수 등 공개하기 어려운 값은 비율이나 대략적인 규모로 바꿔 쓰세요.

점검

1. 이 숫자의 기준선(이전 값)은 무엇인가
2. 어떻게 측정했고, 누가 확인할 수 있는가
3. 이 숫자 중 내 몫은 무엇인가
4. 숫자 없이도 변화가 설명되는가
5. 면접에서 이 숫자에 대해 세 번 꼬리 질문을 받아도 답할 수 있는가

숫자는 자신 있게 설명할 수 있는 만큼만 쓰는 것이 가장 강력합니다.