데이터 분석가 이력서 작성법 - 담당자는 분석했다는 사실을 보지 않습니다

데이터 분석가는 지원자 구성이 유난히 넓은 직무입니다. 통계·산업공학 전공자, 부트캠프 수료자, 마케팅이나 기획을 하다 방향을 튼 사람이 한 공고에 섞여 들어옵니다. 그런데 쌓인 이력서를 열어보면 위쪽은 거의 같은 모양입니다. SQL, Python, Tableau가 나열되고 그 아래 프로젝트 제목과 사용한 모델 이름이 붙습니다. 이 구성에서 담당자가 얻는 정보는 많지 않습니다. 도구 이름은 강의를 한 번 들은 사람도 적을 수 있고, 프로젝트 제목은 무엇을 했는지가 아니라 무엇을 다뤘는지만 알려줍니다. 그래서 담당자는 분석 자체가 아니라 분석의 앞뒤를 읽습니다. 무엇을 알아내려고 시작했는지, 그리고 그 결과로 무엇이 달라졌는지입니다. 이 두 가지가 비어 있으면 아무리 무거운 모델을 썼어도 검증할 방법이 없습니다.

요청을 처리한 사람과 문제를 정의한 사람은 문장에서 갈린다

분석가 이력서에서 연차를 가장 빠르게 드러내는 건 문제 정의입니다. 주니어는 요청받은 추출과 대시보드를 정확히 처리하는 단계이고, 미들부터는 "무엇을 뽑아 달라"가 아니라 "어떤 의사결정을 위해 무엇을 알아야 하는가"를 스스로 세웁니다. 이력서 문장은 이 차이를 그대로 노출합니다. "월별 이탈률을 추출하고 대시보드를 만들었습니다"는 요청 처리의 기록입니다. 같은 일이라도 "해지 방어 캠페인의 대상을 고르기 위해 해지 직전 30일의 행동을 코호트로 나눠 비교했습니다"라고 적으면 분석을 왜 시작했는지가 드러납니다. 담당자는 후자에서 이 사람이 의사결정 테이블에 앉을 수 있는 단계인지를 가늠합니다. 가설을 세웠다면 왜 그 가설이 필요했는지까지 적는 편이 좋습니다. 가설 없이 변수를 다 넣는 것과 가설로 변수를 미리 좁히는 것은 각각 얻는 것과 잃는 것이 다른 선택이고, 그 선택을 설명할 수 있는 사람은 방법을 이해하고 쓰는 사람으로 읽힙니다.

분석 전에도 쓸 수 있는 결론은 결론이 아니다

"다양한 요인이 복합적으로 영향을 미치는 것으로 나타났습니다." 이 문장은 분석을 하기 전에도 쓸 수 있습니다. 이력서에서 가장 자주 보이면서 가장 아무것도 말하지 않는 결론입니다. 결론에는 사용한 방법의 산출물이 들어가야 합니다. 회귀를 돌렸으면 어떤 변수의 계수가 어느 방향으로 유의했는지, 트리 기반 모델이면 변수 중요도 상위가 무엇이었는지, 분류 문제였다면 혼동행렬에서 어떤 오류가 많았는지가 결론에 반영되어야 합니다. "이탈에는 여러 요인이 있었다"가 아니라 "최근 7일 로그인 빈도와 고객센터 문의 이력이 이탈을 가장 크게 설명했고, 이 두 변수로 상위 위험군을 추리는 기준을 만들었다"까지 가야 검증 가능한 문장이 됩니다. 방법론을 고른 이유도 같은 자리에서 읽힙니다. 정규화 계열 모델만 나란히 비교했다면 비교 폭이 좁지 않았는지, 비선형 관계가 자연스러운 데이터인데 선형 모델만 다뤘다면 왜 그렇게 정했는지가 자연스러운 의문으로 남습니다. 다중공선성을 이유로 변수를 떨궜다면 그 변수가 해석에서 어떤 의미였는지 검토한 흔적이 있는 편이 좋습니다. 담당자가 확인하려는 건 정답이 아니라 선택에 근거가 있었느냐입니다.

SQL은 스킬 칸이 아니라 본문에서 증명된다

스킬 목록의 SQL은 거의 모든 지원자에게 있습니다. 그래서 담당자는 본문에서 쿼리를 실제로 짜본 흔적을 찾습니다. 윈도우 함수로 기간별 순위나 누적을 계산했다거나, CTE로 단계를 나눠 복잡한 집계를 정리했다거나, 조인 설계를 바꿔 중복 집계를 잡았다는 서술이 그 흔적입니다. 목록에 이름만 있고 본문에 쿼리 이야기가 전혀 없으면 그 자체가 약점으로 읽힙니다. 대시보드도 마찬가지입니다. 만들었다는 사실은 신호가 되지 않고, 누가 어떤 판단에 썼는지가 신호입니다. "주간 지표 대시보드를 구축했습니다"보다 "영업팀이 매주 우선순위 계정을 고르는 데 쓰도록 지표를 정의하고 대시보드로 넘겼습니다"가 훨씬 많은 걸 알려줍니다. 반복 추출을 셀프서비스로 넘겨 본인의 요청 처리 시간을 줄인 기록도 같은 값을 합니다. 분석가의 일이 요청 대응에서 체계 만들기로 넘어갔다는 증거이기 때문입니다. 지표 정의를 정리한 경험이 있다면 빼지 않는 편이 좋습니다. 중복된 지표를 걷어내고 정의를 통일하는 작업은 화려하지 않지만, 조직의 숫자를 신뢰할 수 있게 만드는 일이라 시니어 방향의 근거가 됩니다.

숫자가 우연이 아니라는 걸 보여주는 자리

분석 결과를 실제 변화와 연결해 적을 때 가장 흔한 함정은 단순 전후 비교입니다. 캠페인을 돌린 뒤 지표가 올랐다는 서술은 계절성이나 같은 시기의 다른 변화에 오염되기 쉽습니다. 통제집단을 두고 비교했는지, 표본 크기를 어떻게 잡았는지, 유의성을 어디까지 확인했는지가 붙으면 그때부터 담당자는 그 숫자를 근거로 읽습니다. A/B 테스트 경험이 없어도 적을 수 있는 것은 있습니다. 실험을 설계해보자고 제안한 기록, 기존 리포트에 비교군을 붙인 기록, 결과 해석에서 다른 설명 가능성을 배제한 과정이 그렇습니다. 실험 문화가 없는 조직에 있었다면 그 조건을 숨기기보다 그 안에서 무엇을 시도했는지를 적는 편이 낫습니다. 반대로 연차에 비해 과한 서술은 검증 단계에서 불리해집니다. 1~2년차 이력서에 모델을 배포해 이탈률을 몇 퍼센트 낮췄고 파이프라인을 단독으로 구축했으며 실험까지 설계했다는 문장이 한꺼번에 들어 있으면, 수치가 붙어 있어도 담당자는 그대로 믿지 않습니다. 실서비스의 배포와 실험은 대개 팀의 인프라와 리뷰 위에서 돌아가기 때문입니다. 본인이 어느 단계를 직접 결정했는지, 예를 들어 검증 설계를 짰는지, 지표 정의를 맡았는지, 모니터링 규칙을 작성했는지를 밝히면 오히려 신뢰가 올라갑니다.

포트폴리오의 무게는 연차에 따라 다르다

데이터 분석은 개인 프로젝트로 증명할 수 있는 범위가 넓은 편입니다. SQL과 통계, 시각화, 그리고 결과를 설명하는 서사까지는 공개 데이터로 충분히 보여줄 수 있습니다. 서울 열린데이터광장이나 국가통계포털의 데이터로 문제 정의부터 행동 제안까지 끝맺은 리포트, 인과추론 기법을 적용해본 사례 분석, 실제로 접속 가능한 대시보드가 신입과 주니어에게는 판단 재료가 됩니다. 반대로 캐글 순위나 강의 실습 노트북을 여러 개 쌓는 것은 판단을 크게 바꾸지 못합니다. 데이터가 이미 정제돼 있고 평가 지표가 고정된 문제를 푼 기록이기 때문입니다. 경력직은 무게가 반대입니다. 이해관계자를 설득해 분석 결과가 실제 의사결정을 움직인 경험, 사내 데이터 품질과 지표 체계를 정리한 경험은 개인 프로젝트로 만들 수 없습니다. 이건 정직하게 회사 경력에서 보여줄 몫이고, 그래서 경력기술서가 본체이며 포트폴리오는 보조 증거가 됩니다. 없는 걸 부풀리기보다 증명 가능한 항목의 완성도를 올리는 편이 서류에서 유리합니다.

정리하면

데이터 분석가 이력서에서 담당자가 확인하는 건 어떤 도구를 다뤘느냐가 아니라 분석의 앞뒤입니다. 어떤 의사결정을 위해 시작했는지, 결론에 방법의 산출물이 들어 있는지, 쿼리와 대시보드가 본문에서 증명되는지, 숫자가 우연이 아니라는 근거가 붙어 있는지입니다. 이 네 가지가 본문에 있으면 스킬 목록은 짧아도 됩니다. 문제는 이런 재료가 이력서를 쓰는 시점에는 대부분 흐릿해져 있다는 점입니다. 그때 어떤 가설을 세웠고 무엇을 근거로 방법을 바꿨는지, 그 분석이 어느 회의에서 어떤 결정으로 이어졌는지는 지나고 나면 복원하기 어렵습니다. GridResume를 만들면서 이 지점을 신경 썼습니다. 평소에 커리어 기록으로 한 줄씩 남겨두면 AI 작성 보조가 그 기록을 문제와 선택, 결과의 흐름으로 정리해 이력서 문장으로 다듬어줍니다. 이력서·포트폴리오 진단에서는 데이터 분석가 기준으로 지금 이력서에서 어떤 신호가 비어 있는지도 짚어드립니다. 도구를 하나 더 배워 목록에 얹는 것보다, 이미 한 분석 하나에 문제 정의와 결론을 붙이는 편이 서류에서는 훨씬 크게 작동합니다.