오늘 한 일
오늘 오전에는 튜터님께 이력서 상담을 요청했다.
지난 한 달 동안 여러 형태로 글을 써보고, 내가 넣을 만하다고 생각한 경험들을 정리해서 보여드렸다.
그런데 피드백은 꽤 뼈아팠다.
글에서 역량이 잘 드러나지 않는다.
어떤 일을 나에게 맡겨야 할지 잘 그려지지 않는다.
타이틀도 아쉽고, 내가 정확히 무엇을 했는지 머릿속에 잘 그려지지 않는다는 피드백도 받았다.
처음에는 많이 속상했다.
한 달 동안 계속 생각하고 정리했는데도, 아직 이력서에서 내가 어떤 사람인지 충분히 전달되지 않는다는 사실이 답답했다.
하지만 다시 생각해보니, 이력서는 내가 해온 일을 나열하는 문서가 아니라 읽는 사람이 나에게 어떤 일을 맡길 수 있을지 판단하게 만드는 문서였다.
1. 이력서는 정리부터 하면 오히려 약해질 수 있다
튜터님이 주신 가장 중요한 피드백은 이것이었다.
처음부터 정리된 이력서 형태로 쓰려고 하지 말고, 먼저 일기처럼 길게 써봐라.
나는 그동안 이력서를 쓰면서 처음부터 보기 좋은 문장, 짧은 bullet, 깔끔한 구조를 만들려고 했다.
하지만 그러다 보니 실제로 내가 어떤 상황에서 무엇을 고민했고, 어떤 판단을 했으며, 어떤 역할을 했는지가 충분히 드러나지 않았던 것 같다.
결국 너무 빨리 정리하려고 해서, 오히려 내 경험의 맥락이 사라졌다.
그래서 오늘 오전에는 1년 동안 내가 무엇을 했는지 길게 풀어 써보았다.
정리된 문장으로 바로 가는 것이 아니라, 먼저 내가 실제로 겪은 상황을 있는 그대로 적어보는 과정이 필요했다.
2. 면접에서 답하려면, 먼저 길게 써봐야 한다
이력서는 짧아야 하지만, 내 머릿속 경험까지 짧으면 안 된다.
면접에서는 이력서에 적힌 한 줄에 대해 계속 질문이 들어온다.
- 왜 그 일을 했나요?
- 당시 문제는 무엇이었나요?
- 본인의 역할은 무엇이었나요?
- 어떤 기준으로 판단했나요?
- 결과는 어땠나요?
- 다시 한다면 무엇을 바꾸고 싶나요?
이 질문에 답하려면, 이력서에 들어가는 문장은 짧더라도 그 뒤에 있는 경험은 길게 정리되어 있어야 한다.
그래서 앞으로 이력서를 쓸 때는 먼저 일기처럼 길게 쓰고, 그다음 핵심만 뽑아 이력서에 넣어야겠다.
즉 순서는 이렇게 가야 한다.
- 경험을 길게 풀어쓰기
- 예상 질문 적기
- 내가 한 판단과 역할 찾기
- 맡길 수 있는 일로 정리하기
- 이력서 문장으로 압축하기
3. 이력서는 “내가 한 일”보다 “나에게 맡길 수 있는 일”이 보여야 한다
오늘 가장 크게 남은 말은 이것이었다.
어떤 일을 나에게 맡겨야 할지 잘 모르겠다.
이 말은 단순히 문장이 부족하다는 뜻이 아니라, 내 이력서에서 역량의 방향성이 잘 보이지 않는다는 뜻이었다.
나는 내가 한 일들을 열심히 적었다.
하지만 읽는 사람 입장에서는 “그래서 이 사람은 어떤 문제를 잘 푸는 사람인가?”, “어떤 역할을 맡기면 잘할까?”가 바로 떠오르지 않았던 것이다.
이력서는 내가 해온 일을 기록하는 문서이지만, 동시에 채용 담당자에게는 판단 문서다.
따라서 앞으로는 경험을 쓸 때마다 이렇게 물어봐야 한다.
이 경험은 내가 어떤 일을 맡을 수 있는 사람이라는 걸 보여주는가?
4. 이력서는 전략적으로 넣어야 한다
나는 처음에 개발자 경험이 있으니 IT 회사에 가는 것이 가장 전략적으로 맞겠다고 생각했다.
그런데 튜터님은 브랜딩 업체나 다른 유형의 회사도 가능할 수 있다고 말씀해주셨다.
이 피드백을 들으면서, 내가 너무 “개발자 출신이니까 IT 회사”라는 프레임 안에서만 생각하고 있었을 수도 있겠다는 생각이 들었다.
다만 어떤 회사든 무작정 넣는 것은 전략이 아니다.
예를 들어 내가 글로벌 경험이 거의 없는데 글로벌 PM 포지션에 지원하면, 당연히 설득력이 약할 수 있다.
반대로 내가 가진 강점과 회사가 원하는 역할이 맞는 곳이라면, IT 회사가 아니더라도 충분히 가능성이 있을 수 있다.
즉 지원 전략은 “어디든 넣기”가 아니라, 내 경험이 그 회사의 문제와 어떻게 연결되는지를 보는 것이다.
5. 애자일에 대한 내 감정
오후에는 프로젝트 매니지먼트 강의에서 애자일에 관한 내용을 공부했다.
솔직히 나는 애자일 방법론에 대해 좋은 감정만 있지는 않다.
정확히 말하면 애자일 방법론 자체는 좋은데, 현실에서 적용되는 방식이 아쉬웠던 경험이 많다.
2020년쯤 애자일이 유행하면서 많은 회사가 애자일을 도입하려고 했다.
하지만 개발자 입장에서 경험한 애자일은 종종 이런 모습이었다.
ASAP으로 이 기획 빨리 개발해주세요.
한 달에 한 번은 무조건 기능 배포합시다.
일단 빠르게 만들고 계속 고칩시다.
이런 방식은 애자일이라기보다 사람을 빠르게 소모시키는 방식처럼 느껴졌다.
그래서 나에게 애자일은 한동안 이상적이고 멀게 느껴졌다.
말은 좋지만, 실제로는 개발자를 쥐어짜는 방식으로 쓰이는 경우가 많다고 생각했다.
6. 다시 이해한 애자일
강의를 듣고 나서 애자일을 조금 다르게 이해하게 되었다.
애자일은 단순히 빠르게 개발하고 자주 배포하는 방식이 아니다.
빠르게 변화하는 시장과 고객 요구 속에서, 고객의 목소리를 듣고, 작은 단위로 실험하고, 계속 수정하면서 생존하기 위한 방식이다.
즉 애자일의 핵심은 “빨리빨리”가 아니다.
핵심은 다음에 더 가깝다.
- 고객의 변화를 빠르게 감지한다.
- 작은 단위로 만들고 확인한다.
- 배운 것을 바탕으로 방향을 조정한다.
- 팀이 같은 목표를 보고 움직인다.
내가 싫어했던 것은 애자일이 아니라, 목표 없이 빠른 실행만 강요하는 방식이었을지도 모른다.
오늘의 한 줄
이력서는 내가 해온 일을 정리하는 문서가 아니라, 나에게 어떤 일을 맡길 수 있는지 보여주는 전략 문서다.
그리고 애자일은 빠르게 사람을 몰아붙이는 방식이 아니라, 고객의 변화에 맞춰 팀이 학습하고 조정하는 방식이어야 한다.
앞으로 적용할 것
앞으로 이력서를 다시 쓸 때는 아래 순서로 진행해보려고 한다.
- 경험을 먼저 일기처럼 길게 풀어쓴다.
- 각 경험마다 예상 질문을 함께 적는다.
- 내가 한 행동보다 내가 내린 판단을 찾는다.
- 그 경험이 어떤 역량을 보여주는지 정리한다.
- 이력서에는 회사가 나에게 맡길 수 있는 일 중심으로 압축한다.
- 지원할 회사와 직무에 맞게 경험을 전략적으로 선택한다.
애자일에 대해서도 무조건 거부감을 갖기보다,
그 방법론이 어떤 목표와 맥락에서 제대로 작동하는지 더 구분해서 이해해보고 싶다.
