개발자 이력서에서 CTO가 가장 먼저 확인하는 것

이력서를 열면 CTO가 가장 먼저 찾는 것은 기술 이름이 아닙니다. "이 사람은 어떤 문제를 맡았고, 어디까지 책임졌는가" 입니다. 기술스택은 그 다음에 확인합니다.

1. 첫 30초에 눈이 가는 곳

이력서는 처음부터 끝까지 꼼꼼하게 읽히지 않습니다. 많은 경우 아래 순서로 훑게 됩니다.

1. 가장 최근 경력의 회사·직무·기간
2. 그 경력에서 맡은 일을 설명하는 처음 두세 줄
3. 숫자나 결과가 있는 문장
4. 마지막으로 기술스택

여기서 "이 사람과 이야기해 볼 만하다"는 느낌이 들면 나머지를 천천히 읽고, 아니면 넘어갑니다. 그래서 가장 중요한 경험이 맨 위에, 가장 먼저 보이는 문장에 있어야 합니다.

2. 기술스택만으로는 구분이 안 되는 이유

Java, Spring, MySQL, Redis, AWS 같은 목록은 많은 백엔드 이력서에서 볼 수 있습니다. 그래서 목록만으로는 사람을 구분할 수 없습니다. 같은 기술을 썼더라도 아래는 서로 다른 경험입니다.

• 이미 만들어진 구조에서 화면에 필요한 API를 추가했다
• 트래픽이 늘면서 느려진 구조의 원인을 찾아 설계를 바꿨다

기술 이름은 어떤 문제를 풀 때 썼는지와 함께 있어야 의미가 생깁니다.

3. 책임 범위가 드러나는 표현

"참여했다"와 "맡았다"는 다릅니다. CTO는 이 단어의 차이를 민감하게 봅니다.

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

• 약함: 결제 모듈 개발에 참여

• 강함: 결제 모듈의 승인·취소 흐름을 설계하고 구현. 장애 시 재처리 기준을 정리해 운영팀과 공유

두 번째 문장에는 내가 결정한 것, 내가 책임진 범위, 다른 사람과 연결된 지점이 모두 있습니다. 팀으로 한 일이라면 팀의 성과를 적되, 그중 내 몫을 분명히 구분해 주세요. 과장하지 않아도 충분히 전달됩니다.

4. 문제 → 판단 → 결과

경험 한 줄을 쓸 때는 세 가지가 연결되는지 확인해 보세요.

• 문제: 무엇이 문제였는가 (예: 주문 조회가 느려 고객 문의가 늘고 있었다)
• 판단: 왜 그 방법을 골랐는가 (예: 캐시 대신 조회 모델을 분리했다 — 데이터 정합성이 더 중요했기 때문)
• 결과: 무엇이 달라졌는가 (예: 평균 응답 시간이 줄었고 문의가 감소했다)

특히 판단이 들어 있는 이력서는 드뭅니다. 그래서 눈에 띕니다. 기술을 고른 이유를 설명할 수 있다는 것은 면접에서도 좋은 신호가 됩니다.

5. 지금 이력서를 점검하는 질문

• 가장 중요한 경험이 첫 화면에 있는가
• "참여", "담당", "지원" 같은 모호한 동사가 많지 않은가
• 내가 직접 내린 결정이 한 군데라도 적혀 있는가
• 결과를 숫자나 변화로 설명했는가 (숫자가 없다면 전후 상태라도)
• 기술 이름이 문제 설명 없이 나열만 되어 있지 않은가

한 가지만 고친다면, 가장 자신 있는 프로젝트 하나를 위 세 요소(문제·판단·결과)로 다시 써 보세요. 나머지 경험을 쓰는 기준도 거기서 생깁니다.