기술은 익혔는데 면접에서 자꾸 막히는 이유를 저도 한동안 이해하지 못했습니다. 프로젝트도 만들고 강의도 들었지만, 막상 “왜 이 기술을 선택했나요?”라는 질문 앞에서는 답이 흐려졌습니다. 돌아보니 취업용 공부와 실무형 공부를 구분하지 못한 것이 문제였습니다. 취업용 공부는 채용 공고, 포트폴리오, README, 면접 답변으로 내 경험을 증명하는 과정이고, 실무형 공부는 협업, 유지보수, 로그 확인, 코드 리뷰처럼 실제 일하는 방식을 익히는 과정입니다. 저는 두 공부를 따로 할 것이 아니라 하나의 프로젝트 안에서 함께 연결해야 한다고 생각합니다. 이 글에서는 그 차이와 실천 방법을 제 경험을 바탕으로 정리해 보겠습니다.
취업용 IT 공부, 채용기준이 먼저다
채용 공고를 열면 요구 기술 스택이 죽 나열돼 있습니다. 프런트엔드라면 JavaScript, React, 반응형 웹 구현 능력 같은 항목들이 눈에 띄고, 백엔드라면 Java, Spring Framework, REST API 설계, SQL 같은 키워드가 반복됩니다. 여기서 REST API란 서버와 클라이언트가 HTTP 프로토콜을 통해 데이터를 주고받는 방식으로, 현재 웹 서비스 개발에서 가장 보편적으로 쓰이는 통신 설계 방식입니다.
취업용 공부의 핵심은 이 채용기준에 맞춰 내 준비 상태를 증명하는 것입니다. 아무리 깊이 공부해도 이력서, GitHub, 포트폴리오에 정리되어 있지 않으면 채용 담당자 눈에 보이지 않습니다. 제가 직접 경험해 봤는데, 게시판 프로젝트 하나를 만들고 “CRUD 구현했습니다 “라고만 적었을 때와, 인증 흐름부터 예외 처리까지 README에 풀어서 적었을 때 반응이 완전히 달랐습니다. CRUD란 데이터를 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)하는 네 가지 기본 연산을 묶어 부르는 용어입니다.
취업용 IT 공부에서 챙겨야 할 결과물을 정리하면 다음과 같습니다.
- 채용 공고 기반으로 기술 스택을 선정한 GitHub 레포지토리
- 프로젝트 목적, 사용 기술, 문제 해결 과정을 담은 README
- 면접에서 “왜 이 기술을 썼는지 “를 설명할 수 있는 근거 문서
- 오류 해결 과정을 기록한 블로그 또는 노션 정리본
면접관이 결과물보다 과정을 더 궁금해한다는 건 단순한 조언이 아닙니다. 실제로 기술 면접에서는 “이 기능을 왜 이렇게 구현했나요? “라는 질문이 “어떤 기술을 썼나요? “보다 훨씬 많이 나옵니다. 취업용 공부는 그 질문에 답할 수 있도록 내 경험을 언어로 정리하는 과정이라고 봐야 합니다.
실무감각은 협업과 유지보수에서 길러진다
실무에 들어가면 가장 먼저 마주치는 현실은 “기존 코드“입니다. 새 기능을 처음부터 만드는 일보다, 이미 돌아가고 있는 서비스의 코드를 읽고 수정하는 일이 훨씬 많습니다. 솔직히 이건 예상 밖이었습니다. 강의나 개인 프로젝트에서는 항상 내가 처음 설계한 코드만 다뤘으니까요.
실무형 IT 공부가 취업용 공부와 가장 크게 다른 지점은 바로 유지보수 가능성과 협업 가독성입니다. 유지보수 가능성이란 지금 당장 기능이 작동하는 것을 넘어, 6개월 뒤 다른 팀원이 코드를 봤을 때 맥락을 이해하고 수정할 수 있는 상태를 말합니다. 변수명 하나, 함수 분리 방식 하나가 다 여기에 해당합니다.
Git 브랜치 전략도 실무감각의 핵심입니다. 브랜치 전략이란 여러 개발자가 동시에 작업할 때 코드 충돌을 최소화하고 배포를 안정적으로 관리하기 위한 Git 사용 규칙 체계입니다. 혼자 프로젝트를 할 때는 main 브랜치 하나에 전부 올리는 경우가 많지만, 실무에서는 기능별로 브랜치를 나누고 코드 리뷰를 거친 뒤 병합합니다. 국내 IT 기업 채용 공고 분석에 따르면 Git 협업 경험 여부를 명시적으로 요구하는 공고 비율이 꾸준히 높아지는 추세입니다(출처: 한국소프트웨어산업협회).
제 경험상 이건 좀 다릅니다. 실무형 공부를 단순히 “더 어려운 기술 배우기 “로 이해하는 분들이 많은데, 실제로는 태도와 습관에 가깝습니다. 오류가 발생했을 때 “안 됩니다 “가 아니라 요청 URL, HTTP 상태 코드, 콘솔 오류 메시지, 서버 응답 내용을 먼저 확인하고 나서 질문하는 것, 그게 실무감각의 출발점입니다. 로깅이란 시스템 동작 중 발생하는 이벤트와 오류를 기록하는 행위로, 장애 원인 분석과 재발 방지에 핵심적인 역할을 합니다. 이 로깅 습관도 혼자 공부할 때부터 들여야 실무에서 자연스럽게 이어집니다.
두 공부를 잇는 실천가이드, 지금 당장 바꿀 것들
취업용 공부와 실무형 공부를 따로 보는 순간 어느 쪽도 제대로 안 됩니다. 포트폴리오만 쫓으면 코드 구조가 엉망이 되고, 실무 감각만 쌓으면 면접에서 설명이 안 됩니다. 제가 직접 써봤는데, 두 가지를 연결하는 가장 효과적인 방법은 프로젝트 하나를 만들 때 처음부터 “실무처럼 “ 기록하는 것이었습니다.
코드 리뷰(Code Review)란 작성한 코드를 다른 사람이 검토하여 오류, 가독성 문제, 개선점을 찾는 과정입니다. 혼자 공부할 때도 깃허브 Pull Request 기능을 활용해 코드를 올리고, 스스로 리뷰 댓글을 달아보는 방식이 실무 감각을 익히는 데 실제로 효과가 있었습니다. 소프트웨어정책연구소 보고서에 따르면 신입 개발자가 실무 적응에 가장 어려움을 겪는 영역 1위가 “기존 코드 파악과 협업 방식“이라는 점은 주목할 만합니다(출처: 소프트웨어정책연구소).
실천 관점에서 지금 당장 바꿀 수 있는 습관은 다음과 같습니다.
- 커밋 메시지를 “수정“, “업데이트“가 아닌 기능 단위로 구체적으로 작성한다
- README에 기능 설명뿐 아니라 겪었던 오류와 해결 방법을 한 섹션으로 넣는다
- 면접 답변을 준비할 때 “무엇을 만들었나 “보다 “왜 그렇게 설계했나 “를 중심으로 정리한다
- 오류가 나면 바로 검색하기 전에 로그와 상태 코드를 먼저 기록하는 습관을 들인다
이 네 가지만 바꿔도 취업용 자료와 실무 감각이 동시에 쌓입니다. 어떤 프로젝트를 하느냐보다 어떤 방식으로 기록하고 설명하느냐가 결국 취업 이후의 적응력까지 결정한다고 봅니다.
두 공부를 연결하는 것은 양을 두 배로 늘리는 게 아닙니다. 지금 하는 프로젝트 하나를 “보여주기용 “과 “실무 연습용 “ 두 기준으로 동시에 점검하는 것입니다. 오늘 만든 커밋 메시지부터 다시 보시길 권합니다. 거기서 이미 차이가 보입니다.