1.2 채용 담당자는 블로그에서 무엇을 보는가

이력서와 포트폴리오를 제출하면 채용 과정이 시작된다고 생각하기 쉽습니다. 하지만 대부분의 기업은 사람이 이력서를 읽기 전에 자동화된 시스템으로 먼저 걸러냅니다. 수천 통의 지원서를 사람이 일일이 읽을 수 없기 때문입니다. 이 관문을 통과해야 비로소 사람의 눈에 닿습니다.

관문을 통과한 뒤에도 문제는 남아 있습니다. 이력서에 "React 능숙"이라고 적혀 있어도, 채용 담당자는 그것을 어디까지 믿어야 할지 판단하기 어렵습니다. 팀 프로젝트에서 실제로 무엇을 했는지, 포트폴리오의 코드를 본인이 작성한 것인지 확인할 방법이 마땅치 않습니다. 이때 블로그가 힘을 발휘합니다.

블로그는 채용 과정에서 이력서가 말해주지 못하는 부분을 보여줍니다. 이 절에서는 화려한 포트폴리오가 왜 신뢰받지 못하는지, 채용 담당자가 블로그에서 구체적으로 무엇을 확인하는지를 살펴봅니다.

1.2.1 포트폴리오의 한계, 블로그의 강점

채용 담당자들 사이에서 포트폴리오에 대한 신뢰가 낮아지고 있습니다. 이유는 단순합니다. 누가 실제로 만들었는지 확인할 수 없기 때문입니다. 부트캠프나 학원에서 같은 커리큘럼으로 만든 포트폴리오는 비슷한 결과물이 나올 수밖에 없습니다. 팀 프로젝트라면 개인의 기여도를 파악하기가 더 어렵습니다. 디자인이 화려한 포트폴리오 사이트를 만드는 데 몇 주를 투자하는 지원자도 있지만, 채용 담당자는 그 화려함에 큰 의미를 두지 않습니다.

기술 채용 분야에서 오래 활동해 온 개발자 jojoldu는 이렇게 말합니다. "채용 담당자들은 포트폴리오를 신뢰하지 않습니다. 누가 실제로 만들었는지 확인할 수 없기 때문입니다." 실제로 많은 채용 담당자가 화려한 UI보다 Github 계정과 기술 블로그를 먼저 확인합니다. 코드 저장소와 블로그는 본인이 직접 작성한 것이라는 신뢰가 상대적으로 높기 때문입니다. "한 줄이라도 직접 짠 코드를 보려고 합니다. UI의 화려함보다 코드 품질을 중시합니다." jojoldu의 이 말은 채용 현장의 시선을 잘 보여줍니다.

포트폴리오와 블로그의 차이는 "결과물"과 "과정"의 차이입니다. 포트폴리오는 완성된 결과를 보여줍니다. 블로그는 그 결과에 도달하기까지의 고민, 시행착오, 판단 근거를 보여줍니다. 채용 담당자가 알고 싶은 것은 "무엇을 만들었는가"보다 "어떻게 문제를 해결했는가"입니다. 블로그는 이 질문에 직접 답합니다.

간단한 게시판 프로젝트를 예로 들어 봅니다. CRUD 기능만 갖춘 게시판은 포트폴리오로 눈에 띄지 않습니다. 하지만 그 게시판을 만들면서 겪은 문제와 해결 과정을 블로그에 기록하고, 코드에 테스트를 작성하고, 버전 관리를 꼼꼼히 했다면 상황이 달라집니다. 프로젝트의 규모가 아니라 개발자의 태도가 드러나기 때문입니다.

미완성된 대형 프로젝트보다 작지만 완성도 있는 프로젝트가 더 좋은 평가를 받습니다. 끝까지 해냈다는 사실 자체가 마무리 능력의 증거입니다. 게시판의 데이터베이스 선택 과정, 인증 방식을 결정할 때 고려한 점, 배포하면서 겪은 문제 등을 블로그에 한 편씩 기록하면 작은 프로젝트도 풍성한 포트폴리오가 됩니다.

이력서에 블로그 주소를 포함하면 한 가지 이점이 더 있습니다. 대부분의 기업은 이력서를 자동으로 분류하는 시스템을 사용합니다. Tech Interview Handbook에 따르면, 기업들은 "수천 개의 이력서를 인간의 눈에 도달하기 전에 스크리닝하기 위해 지원자 추적 시스템을 사용합니다." 이 시스템은 정해진 키워드와 형식을 기준으로 이력서를 걸러냅니다. 직무 기술서에 나온 기술 키워드가 이력서에 없으면 사람이 읽기도 전에 탈락합니다.

블로그는 이 자동 시스템을 거치지 않습니다. 면접관이 직접 방문해서 읽는 채널입니다. 이력서에서 미처 보여주지 못한 역량을 블로그에서 보충할 수 있습니다. 이력서에는 "Python, Django, PostgreSQL"이라는 키워드만 적을 수 있지만, 블로그에서는 이 기술들을 사용해 어떤 문제를 해결했는지 구체적으로 설명할 수 있습니다.

초급 개발자에게 이 점은 더욱 중요합니다. 경력이 짧아서 이력서에 채울 내용이 부족할 때, 블로그는 그 빈자리를 메워줍니다. Pragmatic Engineer의 Gergely Orosz는 초급 개발자에 대해 "채용 담당자들은 현재의 완벽한 실력보다 배우려는 자세와 성장 잠재력을 중요하게 봅니다"라고 말합니다. 프로젝트를 완성하고, 오픈소스에 기여하며, 프리랜서 경험을 쌓는 사람이 유리하다는 것입니다. 블로그는 이런 활동을 기록하고 공유하는 가장 직접적인 수단입니다.

다음 그림은 포트폴리오와 블로그가 채용 담당자에게 전달하는 정보의 차이를 보여줍니다.

포트폴리오는 완성된 결과물을 보여주지만, 블로그는 문제를 만나고 해결해 나가는 과정을 보여줍니다. 채용 담당자가 궁금한 것은 "무엇을 만들었는가"보다 "이 사람이 어떤 사람인가"입니다.

정리하면, 포트폴리오는 "이런 것을 만들었습니다"를 증명하고 블로그는 "이런 사람입니다"를 증명합니다. 채용 담당자가 진짜 알고 싶은 것은 후자입니다.

1.2.2 채용 담당자가 블로그에서 확인하는 세 가지

채용 담당자가 지원자의 블로그를 열었을 때, 글 하나하나를 전부 읽지는 않습니다. 짧은 시간 안에 몇 가지를 확인하고 판단합니다. 그 판단 기준을 알면 블로그를 어떤 방향으로 운영해야 할지 명확해집니다.

채용 담당자가 가장 먼저 확인하는 신호

다음 그림은 채용 담당자가 블로그에서 확인하는 세 가지 핵심 항목을 정리한 것입니다.

채용 담당자는 블로그에서 문제 해결 과정, 학습 태도, 코드 품질에 대한 관심을 확인합니다. 각 항목을 구체적으로 살펴봅니다.

채용 담당자가 블로그에서 확인하는 항목은 크게 세 가지입니다.

첫째, 문제 해결 과정입니다. 채용 담당자는 완성된 결과물이 아니라 문제를 만나고, 원인을 파악하고, 해결책을 찾아가는 과정을 봅니다. 예를 들어 "배포 중 메모리 부족 에러가 발생했다. 원인을 분석해보니 이미지 처리 로직에서 메모리 해제가 누락되어 있었다. 이렇게 수정했더니 해결되었다"와 같은 글은 지원자의 실전 능력을 직접 보여줍니다.

이때 정량화된 성과가 있으면 효과가 배가됩니다. "성능을 개선했다"라는 한 줄보다 "응답 시간을 500ms에서 50ms로 단축했다"라는 구체적인 수치가 훨씬 효과적입니다. Tech Interview Handbook에서도 "개별 섹션이 할 수 없는 방식으로 전체 전문 경험을 요약할 수 있는 명확한 성과"를 강조합니다. 블로그는 이력서의 한 줄로는 전달할 수 없는 맥락과 수치를 담을 수 있는 공간입니다.

결과만 기록하는 것은 부족합니다. "인덱스를 추가해서 해결했다"로 끝나면 문제 해결 능력이 드러나지 않습니다. "처음에는 애플리케이션 코드를 의심했다. 프로파일링을 돌려보니 데이터베이스 쿼리에서 병목이 발생했다. 실행 계획을 확인하니 풀 스캔이 일어나고 있었다. 인덱스를 추가하자 쿼리 시간이 10분의 1로 줄었다."처럼 사고의 흐름이 보여야 합니다. 틀린 가설을 세우고 수정해 나가는 과정이 오히려 실력의 증거입니다.

둘째, 학습 태도입니다. 초급 개발자를 채용할 때 현재의 실력만으로 판단하지 않습니다. 배우려는 자세와 성장 가능성을 함께 봅니다. 블로그에 최근 글이 꾸준히 올라오고 있다면 "지금도 학습하고 있는 사람"이라는 인상을 줍니다. 반대로 6개월 이상 새 글이 없으면 "블로그를 관리하지 않는 사람" 혹은 "최근 학습을 멈춘 사람"으로 보일 수 있습니다.

글의 완성도보다 꾸준함이 더 강한 신호입니다. 한 달에 한 편 완벽한 글을 쓰겠다고 벼르다가 결국 한 편도 못 쓰는 것보다, 짧더라도 매주 기록을 남기는 편이 낫습니다. 채용 담당자는 블로그의 최근 글 날짜를 확인합니다. 마지막 글이 1년 전이라면 블로그가 없는 것과 크게 다르지 않습니다.

학습 태도가 잘 드러나는 글에는 공통점이 있습니다. 처음에 가졌던 오해, 삽질 과정, 깨달은 점이 솔직하게 담겨 있습니다. "처음에는 이 기술이 불필요하다고 생각했다. 직접 써보니 이런 상황에서 효과적이었다. 앞으로는 이런 경우에 활용할 생각이다." 이런 구조의 글은 지원자가 경험에서 배우고 관점을 수정할 수 있는 사람이라는 것을 보여줍니다.

셋째, 코드 품질에 대한 관심입니다. 블로그 글에서 코드를 어떻게 다루는지도 평가 대상입니다. 단순히 코드를 붙여넣는 것과, 왜 이렇게 작성했는지 설명하는 것은 다릅니다. 테스트 코드를 작성한 경험, 리팩토링 과정, 코드 리뷰에서 받은 피드백을 반영한 사례 등이 글에 담겨 있으면 코드 품질에 신경 쓰는 개발자라는 인상을 남깁니다.

코드를 다루는 글에서는 "어떤 코드를 작성했는가"보다 "왜 그 방식을 선택했는가"가 중요합니다. 선택의 이유를 설명하는 글은 지원자가 기술적 판단력을 갖췄다는 증거입니다. 대안을 비교하고 트레이드오프를 고려한 흔적이 있으면 더 좋습니다. 예를 들어 "A 라이브러리와 B 라이브러리를 비교했다. A는 성능이 좋지만 학습 곡선이 가파르다. 이 프로젝트에서는 빠른 개발 속도가 우선이라 B를 선택했다."와 같은 글은 기술적 의사결정 능력을 보여줍니다.

어떤 글이 실제로 좋은 인상을 남길까

채용 관점에서 좋은 글은 어려운 주제를 다루는 글이 아니라, 실제 업무에서 부딪힌 문제를 솔직하게 풀어낸 글입니다. 예를 들어 API 응답 속도가 갑자기 느려졌던 경험을 쓴다고 가정해 봅니다. 증상만 적는 대신 "처음에는 서버 부하를 의심했고, 지표를 확인해 보니 정상이었고, 다음으로 데이터베이스 실행 계획을 보다가 인덱스 누락을 발견했다"는 흐름을 적으면 사고 과정이 선명하게 드러납니다. 마지막에 "응답 시간을 3초에서 200ms로 복구했다"처럼 수치까지 덧붙이면 성과가 더 명확해집니다.

학습 기록도 같은 원리로 쓸 수 있습니다. "TypeScript를 일주일 써봤다"는 주제라면, 첫 인상과 마지막 인상을 대비해 쓰는 편이 좋습니다. 처음에는 타입 선언이 번거롭다고 느꼈지만, 며칠 지나며 자동완성과 오류 탐지가 주는 이점을 체감했고, 결국 프로젝트 규모가 커질수록 장점이 커진다는 결론에 도달했다는 식입니다. 이렇게 시간에 따른 관점 변화를 담으면, 단순 요약이 아니라 학습 태도를 보여주는 글이 됩니다.

코드 품질에 대한 관심도 글로 충분히 보여줄 수 있습니다. 코드 리뷰에서 받은 피드백을 정리할 때 "변수명을 어떻게 바꿨는지", "에러 처리를 왜 추가했는지", "그 수정으로 무엇이 달라졌는지"를 문장으로 풀어 쓰면 됩니다. 핵심은 코드 자체보다 판단의 이유를 드러내는 것입니다.

지금 바로 시작하려면 최근에 해결한 기술 문제 하나를 떠올려서, 증상과 원인, 해결 과정, 배운 점을 짧게라도 정리해 봅니다. 완성된 원고가 아니어도 괜찮습니다. 뼈대를 먼저 잡아두면 나중에 문장을 다듬기가 훨씬 쉬워집니다.

채용 관점에서 놓치기 쉬운 포인트

블로그를 채용 관점에서 운영할 때 흔히 하는 실수가 있습니다. 공식 문서의 내용을 그대로 정리하는 것입니다. "React 공식 문서에 따르면 useState는 이렇게 사용합니다"라는 글은 채용 담당자에게 아무런 정보를 주지 못합니다. 공식 문서를 읽을 수 있다는 것 이상의 의미가 없기 때문입니다.

효과적인 글은 자신만의 경험이 담긴 글입니다. 같은 기술을 다루더라도 "useState를 사용하다가 이런 상황에서 이런 문제를 만났고, 이렇게 해결했다"는 글이 훨씬 가치 있습니다. 기술 자체가 아니라 기술을 사용하면서 겪은 자신만의 이야기가 차별점을 만듭니다.

튜토리얼을 따라하고 "잘 동작한다"로 끝나는 글도 피해야 합니다. 따라하면서 막힌 부분, 공식 문서와 달랐던 부분, 자기 프로젝트에 적용하면서 수정한 부분을 추가해야 글에 가치가 생깁니다. 남의 코드를 그대로 베낀 프로젝트는 오히려 역효과입니다. 작더라도 자신만의 문제를 해결한 경험을 기록하는 것이 중요합니다.

블로그 주제가 너무 넓어지지 않도록 주의합니다. 프론트엔드, 백엔드, 인프라, 머신러닝을 한 블로그에서 모두 다루면 어떤 분야의 전문성도 드러나지 않습니다. 지원하려는 직무와 관련된 기술 중심으로 글을 쓰면 해당 분야에 깊이 있는 개발자라는 인상을 줍니다.

Github과 블로그를 연계하면 효과가 커집니다. Github에 올린 코드를 블로그에서 설명하면 코드의 맥락과 의도를 전달할 수 있습니다. 코드만 올리면 "이 사람이 이런 코드를 작성했구나"에서 끝나지만, 블로그에서 왜 이 구조를 선택했는지, 어떤 대안을 검토했는지 설명하면 기술적 사고 과정까지 보여줍니다. 단순한 코드 저장소가 사고 과정의 기록으로 바뀝니다.

블로그 글에 관련 기술 키워드를 자연스럽게 포함하는 것도 도움이 됩니다. 채용 담당자가 특정 기술 이름으로 검색했을 때 블로그가 노출될 수 있고, 해당 기술에 대한 이해도를 간접적으로 보여줍니다. 다만 키워드를 억지로 나열하는 것은 오히려 역효과입니다. 글의 맥락 안에서 자연스럽게 기술 이름이 등장하면 됩니다.

1.2.3 정리

채용 담당자는 블로그에서 문제 해결 과정, 학습 태도, 코드 품질에 대한 관심을 확인합니다. 화려한 포트폴리오보다 자신만의 고민이 담긴 기록이 더 신뢰를 얻습니다. 글의 완성도보다 꾸준함이, 프로젝트의 규모보다 문제를 해결해 나가는 과정이 중요합니다.

참고 문헌

• 주니어 개발자를 위한 취업 정보 - jojoldu
• Tech Interview Handbook - Resume - Tech Interview Handbook
• Advice for Tech Workers to Navigate a Heated Job Market - Pragmatic Engineer