강의를 100개 들으면 취업이 될까요? 저는 한때 그렇게 생각했습니다. 수강 완료 배지가 쌓일수록 실력도 쌓인다고 믿었는데, 막상 이 개념이 뭔가요?라는 질문 앞에서 말문이 막혔습니다. 그때부터 블로그에 공부 내용을 정리하기 시작했고, 생각보다 훨씬 많은 것이 바뀌었습니다.
IT 취업 블로그 작성 시 개념정리해서 써보면 내가 모른다는 게 보인다
솔직히 이건 예상 밖이었습니다. 강의에서 API를 배울 때는 분명히 이해했다고 느꼈습니다. 그런데 블로그에 API가 뭔지 설명하는 글을 쓰려고 앉으니 첫 문장부터 막혔습니다.
API(Application Programming Interface)란 클라이언트와 서버가 정해진 규칙에 따라 데이터를 주고받는 통신 규약입니다. 여기서 클라이언트란 사용자의 브라우저나 앱처럼 요청을 보내는 쪽을 말하고, 서버는 그 요청을 받아서 데이터를 돌려주는 쪽을 의미합니다. 강의에서 이 흐름을 그림으로만 봤을 때와, 직접 글로 설명하려 했을 때의 체감은 완전히 달랐습니다.
블로그에 개념을 정리하는 행위는 일종의 러버덕 디버깅(Rubber Duck Debugging)에 가깝습니다. 러버덕 디버깅이란 코드의 오류를 찾기 위해 마치 고무 오리 인형에게 설명하듯 문제를 소리 내어 풀어보는 방법인데, 글쓰기도 그와 같은 효과를 냅니다. 설명하려는 순간, 내가 실제로 이해한 부분과 그냥 넘어간 부분이 선명하게 갈립니다.
IT 취업 준비에서 중요한 것은 용어를 많이 아는 것이 아니라, 그 개념을 실제 흐름 속에서 설명할 수 있는 힘입니다. 블로그 정리는 이 설명력을 키우는 데 많은 도움이 됩니다.
IT 업계에서는 지원자의 커뮤니케이션 역량을 중요하게 봅니다. 개념을 아는 것과 설명할 수 있는 것은 다른 능력입니다. 블로그 정리는 그 설명력을 반복해서 훈련하는 과정이라고 저는 생각합니다.
오류기록, 고생한 흔적이 면접 답변이 된다
개발 공부를 하다 보면 하루에도 몇 번씩 오류를 만납니다. 처음에는 그냥 해결하고 넘어갔는데, 시간이 지나니 분명히 3일을 잡아먹었던 오류인데도 그게 뭐였지? 싶어지는 경험을 반복했습니다. 제가 직접 겪어보니 기록하지 않은 경험은 없는 것과 다름없었습니다.
오류 해결 과정을 블로그에 남길 때는 단순히 해결했다는 결론만 적는 것보다, 문제가 발생한 맥락부터 정리하는 편이 훨씬 유용합니다. 저는 보통 아래 흐름으로 기록합니다.
- 어떤 상황에서 어떤 오류가 발생했는지
- 에러 메시지를 분석해서 짐작한 원인
- 시도해 본 방법들과 결과
- 최종 해결 방법과 핵심 원인
- 이 경험에서 얻은 인사이트
예를 들어 CORS(Cross-Origin Resource Sharing) 오류를 처음 만났을 때, 저는 이게 뭔지도 몰라서 한참을 헤맸습니다. CORS란 브라우저가 다른 출처(도메인, 포트)의 서버에 요청을 보낼 때 서버 측에서 이를 허용해주지 않으면 요청을 차단하는 보안 정책입니다. 당시 해결 과정을 블로그에 기록해 뒀더니, 나중에 비슷한 오류가 생겼을 때 제 글을 다시 찾아보게 됐습니다.
기업은 신입에게 완벽한 코드를 기대하기보다, 문제를 만났을 때 어떻게 접근하고 어떻게 해결하는지를 보고 싶어 합니다. 면접에서 어떤 문제를 해결한 경험이 있나요?라는 질문을 받았을 때, 블로그에 남긴 기록을 바탕으로 구체적인 답변을 꺼낼 수 있다는 점은 생각보다 큰 강점이었습니다.
포트폴리오를 보완하는 학습 흔적의 힘
포트폴리오에는 보통 완성된 프로젝트 결과물이 들어갑니다. GitHub 링크, 배포 주소, 기능 목록 정도가 기본입니다. 그런데 결과물만 보면 채용 담당자 입장에서는 이 사람이 직접 만든 건지, 얼마나 이해하고 만든 건지 파악하기가 어렵습니다.
블로그는 그 빈자리를 채울 수 있습니다. 게시판 프로젝트를 만들었다면, 블로그에는 RESTful API(REST 원칙을 따르는 API 설계 방식으로, HTTP 메서드인 GET·POST·PUT·DELETE를 자원 중심으로 구조화하는 방식) 설계를 어떻게 잡았는지, 데이터베이스 스키마를 어떻게 구성했는지, 어떤 오류를 만나고 어떻게 해결했는지를 남길 수 있습니다. 포트폴리오의 한 줄이 블로그 글 하나와 연결되면, 결과물이 훨씬 입체적으로 보입니다.
비전공자나 경력이 없는 준비생에게 블로그는 특히 유용합니다. 실무 경험이 없어도 꾸준히 공부해 온 과정을 시각적으로 보여줄 수 있기 때문입니다. 실제로 국내 IT 채용 시장에서 비전공자 지원 비율이 꾸준히 늘고 있으며, 이에 따라 학습 태도와 자기 주도성을 보여주는 자료의 중요성도 높아지고 있습니다(출처: 한국고용정보원).
이력서에 GitHub 링크와 함께 기술 블로그 링크를 넣는 것은 이제 선택이 아닌 기본에 가까워지고 있습니다. 글의 개수보다는 내 경험과 해석이 담긴 글이어야 한다는 점이 중요합니다. 강의 내용을 그대로 옮긴 글은 채용 담당자도 금방 알아챕니다.
꾸준히 쓰면 공부 습관 자체가 달라진다
IT 공부는 단기 스프린트가 아닙니다. 취업 준비 기간이 6개월을 넘어가면 많은 분들이 방향을 잃거나 무기력해지는 시기를 겪습니다. 저도 그런 시기가 있었는데, 블로그 기록이 그 시기를 버티게 해 준 하나의 축이었습니다.
일주일에 한두 번이라도 배운 내용을 정리하면, 공부의 흐름이 눈에 보입니다. 이번 주에는 어떤 개념을 이해했고, 어떤 기능을 구현했고, 어떤 오류를 만났는지 정리하다 보면 자연스럽게 다음 주에 뭘 해야 할지도 보입니다. 이 과정이 학습 로드맵(Roadmap), 즉 공부 순서와 방향을 스스로 설계하는 힘을 길러줍니다.
또한 글을 쓰는 행위 자체가 메타인지(Metacognition)를 자극합니다. 메타인지란 내가 무엇을 알고 무엇을 모르는지 스스로 파악하는 능력으로, 효율적인 학습에서 핵심 역할을 합니다. 실제로 학습 전략 연구에 따르면, 배운 내용을 자신의 말로 설명하거나 기록하는 행위가 단순 반복 학습보다 장기 기억 유지에 더 효과적인 것으로 알려져 있습니다(출처: 한국교육학술정보원(KERIS)).
독학으로 공부하는 분들에게는 더욱 그렇습니다. 강의나 커리큘럼 없이 혼자 공부하면 어디까지 왔는지, 어디로 가야 하는지 놓치기 쉽습니다. 블로그는 그 흐름을 붙잡아주는 역할을 합니다. 제 경험상 이건 의지력의 문제가 아니라 구조의 문제입니다. 기록이라는 구조가 공부를 지속하게 만들어줍니다.
결국 블로그 정리는 공부를 잘 보여주기 위한 포장이 아닙니다. 내가 얼마나 이해했는지 확인하고, 문제를 어떻게 풀었는지 남기고, 어디까지 왔는지 스스로 점검하는 도구입니다. 지금 당장 완벽한 글을 쓸 필요는 없습니다. 오늘 배운 개념 하나, 오늘 해결한 오류 하나부터 기록하면 충분합니다. 그 기록이 6개월 뒤 면접장에서 가장 구체적인 답변이 되어줄 수 있습니다.