내 이력서를 본 사람이 ‘사람’이 아닐 수도 있습니다

이 말부터 하면,
기분 나쁠 수도 있을 것 같아요.

저도 처음엔 그랬거든요.

---

“왜 아무 연락이 없지?”

예전에 개발자 채용을 도와주면서
그리고 지금은 취준생들 프로젝트를 계속 보다 보니까
공통적으로 듣는 말이 있어요.

“이 정도면 괜찮은 거 아닌가요?”
“주변에서는 다 잘 만들었다고 하던데요.”

근데 결과는 비슷합니다.
서류에서 조용히 탈락.

여기서 대부분 이렇게 생각하죠.

“아, 내가 실력이 부족한가 보다.”

근데요,
제가 보기엔 그게 아닌 경우가 훨씬 많아요.

---

불편한 얘기 하나 할게요

요즘 이력서는
사람이 처음부터 보지 않는 경우가 많습니다.

이건 음모론도 아니고,
특정 회사만의 이야기도 아니에요.

지원자가 많아졌고,
모든 이력서를 사람이 다 읽을 수 없는 구조가 됐어요.

그래서 대부분 이런 과정을 거칩니다.

• 시스템이 먼저 훑고
• 정리하고
• “볼 만한 것”만 사람에게 올라가요

즉,
당신의 이력서를 처음 판단한 존재는
사람이 아닐 수도 있다는 겁니다.

---

여기서 문제가 생깁니다

취준생들이 프로젝트를 설명하는 방식은
대부분 이런 식이에요.

• “CRUD 구현”
• “React + Spring 사용”
• “협업 경험”
• “열심히 개발”

이게 틀렸다는 말은 아니에요.
저도 예전에 똑같이 썼어요.

근데 문제는,
이 설명에는 ‘사고’가 안 보입니다.

---

기업이 진짜 궁금한 건 이거예요

코드를 얼마나 잘 짰는지보다
이런 걸 봅니다.

• 왜 이 문제를 골랐는지
• 다른 선택지는 뭐였는지
• 왜 이 방식을 선택했는지
• 실제로 부딪힌 문제가 뭐였는지

이건 튜토리얼 프로젝트에선 잘 안 나와요.
혼자 만들면 더더욱 안 나옵니다.

그래서 결과적으로,

프로젝트는 있는데
“이 사람을 왜 써야 하는지”는 안 보이는 상태

가 되는 거죠.

---

이걸 혼자 깨닫기 어려운 이유

이건 실력 문제가 아닙니다.

• 기업은 왜 탈락했는지 말 안 해주고
• 학교나 강의는 “만드는 법”만 알려주고
• 취준생은 계속 혼자서 추측만 합니다

그러다 보면
프로젝트는 늘어나는데, 방향은 계속 틀린 상태가 돼요.

저도 이걸
직접 보고, 듣고, 반복해서 겪으면서 알게 됐어요.

 

👉 [뉴스레터] 취업과 개발 프로젝트 소식을 이메일로 바로 받기

---

그래서 우리는 이걸 훈련으로 만들었습니다

우리가 만든 4주 프로젝트 챌린지는
“하나 더 만드는 과정”이 아닙니다.

• 문제를 고르는 기준
• 결정을 설명하는 방식
• 기업이 이해하는 언어로 정리하는 법

이걸 의도적으로 반복 연습합니다.

실무에서
“왜 그렇게 했는지 설명해야 하는 상황”을
미리 겪어보는 거예요.

 

다음 글에서는
요즘 많은 회사들이 준비하고 있는 RAG 프로젝트를
신입/주니어 입장에서 어디까지 이해하고,
어디까지 보여주면 ‘실무 가능성’으로 보이는지 이야기해보려 합니다.

코드를 얼마나 많이 구현했느냐보다,
이 기술을 왜 쓰려고 했는지 설명할 수 있는지가
채용에서는 훨씬 중요하거든요.

“RAG 프로젝트 하나쯤 해봐야 하나?”
생각하고 있었다면,
아마 방향을 잡는 데 도움이 될 겁니다.

 

단순 코딩 팁보다
어떤 프로젝트에 어떤 기술을 사용해야 하는지,
서류에서 실제로 갈리는 지점들을 계속 이야기할 겁니다.

다음 글에서는
요즘 많은 회사들이 준비하고 있는 RAG 프로젝트를
신입/주니어 입장에서 어디까지 이해하고,
어디까지 보여주면 ‘실무 가능성’으로 보이는지 이야기해보려 합니다.

코드를 얼마나 많이 구현했느냐보다,
이 기술을 왜 쓰려고 했는지 설명할 수 있는지가
채용에서는 훨씬 중요하거든요.

“RAG 프로젝트 하나쯤 해봐야 하나?”
생각하고 있었다면,
아마 방향을 잡는 데 도움이 될 겁니다.

아마 읽고 나면
지금까지 했던 프로젝트를
다르게 보게 될 겁니다.

관심 있다면,
아래에서 우리가 어떤 방식으로 프로젝트를 만드는지 볼 수 있어요.

👉 [취업용 실전 4주 프로젝트 개발 챌린지 참여하기]

 

프로젝트에 참여하면 취업을 더 쉽게 할수 있습니다.