내 이력서를 본 사람이
‘사람’이 아닐 수도 있습니다
개발자로 가장 빠르게 취업하는 방법을 알려줍니다.
이 말부터 하면,
기분 나쁠 수도 있을 것 같아요.
저도 처음엔 그랬거든요~
예전에 개발자 채용을 도와주면서, 그리고 지금은 취준생들 프로젝트를 계속 보다 보니까 공통적으로 듣는 말이 있어요.
“이 정도면 괜찮은 거 아닌가요?”
“주변에서는 다 잘 만들었다고 하던데요.”
근데 결과는 비슷합니다. 서류에서 조용히 탈락.
여기서 대부분 이렇게 생각하죠.
근데요, 제가 보기엔 그게 아닌 경우가 훨씬 많아요.
요즘 이력서는 사람이 처음부터 보지 않는 경우가 많습니다. 이건 음모론도 아니고, 특정 회사만의 이야기도 아니에요.
지원자가 많아졌고, 모든 이력서를 사람이 다 읽을 수 없는 구조가 됐어요. 그래서 대부분 이런 과정을 거칩니다.
사람이 아닐 수도 있다는 겁니다.
여기서 문제가 생깁니다.
취준생들이 프로젝트를 설명하는 방식은 대부분 이런 식이에요.
- CRUD 구현
- React + Spring 사용
- 협업 경험
- 열심히 개발
이게 틀렸다는 말은 아니에요. 저도 예전에 똑같이 썼어요.
근데 문제는, 이 설명에는 ‘생각’이 안 보입니다.
기업이 진짜 궁금한 건 이거예요.
코드를 얼마나 잘 짰는지보다, 이런 걸 봅니다.
- 왜 이 문제를 골랐는지
- 다른 선택지는 뭐였는지
- 왜 이 방식을 선택했는지
- 실제로 부딪힌 문제가 뭐였는지
이건 튜토리얼 프로젝트에선 잘 안 나와요. 혼자 만들면 더더욱 안 나옵니다.
프로젝트는 있는데 “이 사람을 왜 써야 하는지”는 안 보이는 상태가 되는 거죠.
이걸 혼자 깨닫기 어려운 이유
이건 실력 문제가 아닙니다.
- 기업은 왜 탈락했는지 말 안 해주고
- 학교나 강의는 “만드는 법”만 알려주고
- 취준생은 계속 혼자서 추측만 합니다
그러다 보면 프로젝트는 늘어나는데, 방향은 계속 틀린 상태가 돼요. 저도 이걸 직접 보고, 듣고, 반복해서 겪으면서 알게 됐어요.
그래서 우리는 이걸 훈련으로 만들었습니다
우리가 만든 4주 프로젝트 챌린지는 “하나 더 만드는 과정”이 아닙니다.
- 문제를 고르는 기준
- 결정을 설명하는 방식
- 기업이 이해하는 언어로 정리하는 법
실무에서 “왜 그렇게 했는지 설명해야 하는 상황”을 미리 겪어보는 거예요.
이 뉴스레터에서는 앞으로
단순 코딩 팁보다 어떤 프로젝트에 어떤 기술을 사용해야 하는지, 서류에서 실제로 갈리는 지점들을 계속 이야기할 겁니다.
요즘 많은 회사들이 준비하고 있는 RAG 프로젝트를 신입/주니어 입장에서 어디까지 이해하고, 어디까지 보여주면 ‘실무 가능성’으로 보이는지 이야기해보려 합니다.
코드를 얼마나 많이 구현했느냐보다, 이 기술을 왜 쓰려고 했는지 설명할 수 있는지가 채용에서는 훨씬 중요하거든요.
“RAG 프로젝트 하나쯤 해봐야 하나?” 생각하고 있었다면, 아마 방향을 잡는 데 도움이 될 겁니다.
아마 읽고 나면 지금까지 했던 프로젝트를 다르게 보게 될 겁니다.
관심 있다면, 아래에서 우리가 어떤 방식으로 프로젝트를 만드는지 볼 수 있어요.
👉 취업용 실전 4주 프로젝트 개발 챌린지 자세히 보기