이력서에도 디자인 패턴이 있다.

이력서의 상세 내용을 적을 때 개발처럼 생각하면 좋다.
개발자가 흔히 반복되는 문제를 해결하기 위해 디자인 패턴을 사용하는 것처럼, 이력서에도 패턴이 존재한다.

흔히 이야기하는 STAR 기법은 "어려웠던 일을 있는 그대로 전달하기 위한" 목적으로써 사용하는데,
해당 기법은 "문제 수준이 높은 과제"에서만 잘 먹힌다는 점이다.

특히나 주니어 같은 경우에는 문제의 수준이 높은 경우가 많이 발생하지 않고, 실패가 많을 수도 있다.
그럼 어떻게 고민해보면 좋을까?

디자인 패턴에 대해서도 많은 개발자들이 하는 말이 "디자인 패턴에 코드를 맞추지 말고, 코드를 효율적으로 짜다보면 자연스럽게 디자인 패턴과 맞춰진다" 라고들 한다.
마찬가지로 이력서도 "효율적"으로 작성하면 된다.

어떤 이력서가 효율적일까?
이력서의 목적은 "내가 당신의 회사에 제일 알맞은 인재이다"라는 것을 표현하는 것이다.
그렇기 때문에, 나의 경험을 가장 어필이 될 수 있는 방식으로 표현하는 것이 중요하다.

만약, 복잡한 상황에서 내가 해결책을 찾아서 성과를 냈다면, 위에서 말한 STAR 기법이 가장 효율적이다.
복잡한 상황을 있는 그대로 표현할 수 있기 때문이다.

그렇다고 모든 부분에 STAR 기법을 쓴다면 어떨까?
어떤 항목이 가장 중요한건지 알수 없게 되어 오히려 가독성 면에서 좋지 않을 수 있다.

그렇다면, 실패했던 사례는 어떻게 적는게 좋을까?
만약 내가 특정 프로젝트를 하다가 실패를 했다면, 실패한 사실만으로는 어떤 가치도 전달할 수 없다.
성장하는 사람은 실패를 통해 좀 더 나은 형태로 성장할 수 있는 사람일 것이다.
그러므로, 실패했던 이유와 그 과정을 이야기하고, 그 과정에서 배운점이나, 지금이라면 어떻게 하면 좋을지까지도 적어볼 수 있겠다.
결국 같은 실패를 하지 않는, 성장하는 사람이라는걸 보여주는게 좋다.

그렇다면 복잡한 상황도, 실패했던 상황도 아니라면?
먼저 채용공고를 보고 키워드를 추출해보자.
"원활한 소통"이라는 키워드가 있다면, 내가 가진 경험 중에 원활한 소통을 가능하게 했던 것을 찾아보자.
그리고 "원활한 소통을 할 수 있다는 것"을 제목으로 올리고, 그에 맞는 상황과 경험을 나열해보자.
그럼 키워드만 봐도 우리 회사에 맞는 사람이라는게 느껴지는 이력서가 된다.

그럼 위에 적히지 않은 나머지 이력들은 어떨까?
회사와 너무 동떨어지지 않은 이력 내에서는 목록식으로라도 나열해주면 좋다.
예를 들어 "다국어 처리"에 대한 경험은 공통적인 역량이기 때문에 어떤 회사에서도 나쁘지 않은 경험일 수 있다.
하지만, 특정 도메인에서만 사용되는 역량은 다른 도메인에서 가치를 잃어버리는 경우가 있다.
이런 이력이라면 해당 작업을 통해 "문제해결한 경험"을 STAR 기법으로 적고, 자잘한 경험은 지워버리는 것이 가독성에 좋을 수 있다.

결국 가장 중요한 건, "채용 담당자"의 입장에서 "우리 회사에 맞는 사람이구나!"라는 어필이 되어야한다는걸, 이력서를 적는 내내 잊어버리면 안된다.