이력서는 주장, 기술 블로그는 증거: 엔지니어 경력 문서화 전략

2023년 4월 2일 · ◷ 3분

최근 이력서/포트폴리오를 다시 정리하면서 가장 크게 확인한 문제는 하나였다.

경험은 많은데, 내가 어떤 문제를 어떻게 정의하고 해결하는 사람인지는 잘 보이지 않는다.

Notion의 포트폴리오 메모에는 이미 같은 경고가 있었다.
“문제를 해결한 사례를 블로그에 상세히 기술하고 이력서에 링크로 추가해야 한다.”

Obsidian의 이직 메모에서도 결론은 같았다.

내가 발견한 이력서의 구조적 문제

“무엇을 했다"는 많았지만, 아래 질문에 대한 답이 부족했다.

결국 이력서가 경험 목록으로 읽히면, 채용 담당자는 역량의 깊이를 추론해야 한다. 추론을 요구하면 대부분 실패한다.

로보틱스/실시간 경험은 강점이지만, 정리 방식이 나쁘면 “특정 도메인에만 맞는 사람"으로 보인다. 실제로는 백엔드/운영/실시간/LLM을 가로지르는 문제 해결이 핵심인데, 전달 방식이 이를 가렸다.

“비즈니스 임팩트를 중시한다"는 문장은 많았지만, 사례에서 보이지 않으면 설득력이 없다. 가치관은 선언이 아니라 의사결정 기록으로 증명해야 한다.

내가 적용한 원칙은 단순하다.

블로그 포스트 템플릿도 고정했다.

예를 들어 실시간 스트리밍이나 데이터 파이프라인 같은 작업도, “만들었다"가 아니라 아래처럼 표현해야 이해가 빨라진다.

핵심은 기술 이름이 아니라 문제를 푸는 판단이다.

나는 기술의 순수성보다 제품의 생존 가능성을 먼저 본다. 다만 단기 성과만 보고 운영성을 버리지는 않는다.

즉, 내가 추구하는 엔지니어링은 “멋진 코드"보다 “운영 가능한 성과"에 가깝다.

이력서는 결국 가설이다. “나는 이런 문제를 해결할 수 있다"는 주장이다.

블로그는 그 가설을 검증하는 증명이다. 앞으로는 모든 핵심 경력 항목을 블로그 글로 연결해서, 주장과 증거를 분리하지 않겠다.

이력서의 각 항목은 하나의 블로그 글과 1:1로 연결했다.

이 방식으로 문서를 구성하면, 읽는 사람이 “주장"과 “근거"를 같은 화면에서 검증할 수 있다.

참고: Google Technical Writing 가이드는 핵심 정보 우선 배치와 스캔 가능한 구조를 강조한다. Google Technical Writing

참고: Nielsen Norman Group의 F-pattern 연구는 긴 문서에서 독자가 핵심만 빠르게 훑는 경향을 보여준다. F-Shaped Pattern of Reading on the Web

참고: MIT CAPD의 PAR(Action + Result) 가이드는 성과 근거 중심으로 경력 항목을 작성하는 기준을 제시한다. Resumes: Writing About Your Skills