강의 한 번만 더 듣고 시작해야지. 저도 이 생각을 정말 많이 했습니다. 기초가 흔들리는 것 같아서, 프로젝트를 시작하기 전에 조금만 더 공부해 두자는 마음이었습니다. 그런데 그 조금만 더가 쌓이다 보니 어느 순간 몇 달이 지나 있었습니다. 완벽주의가 성실함처럼 느껴지지만, IT 취업 준비에서는 오히려 발목을 잡는 경우가 많습니다.
IT 취업 완벽주한 준비를 기다리다 실행 지연이 될 수 있다.
기초를 더 다진 뒤 프로젝트를 해야 한다는 말, 틀린 말은 아닙니다. 기반이 없으면 코드를 짜다가 막혔을 때 이유를 알 수 없으니까요. 그런데 이 생각이 지나쳐지면 문제가 됩니다. 제가 직접 겪어봤는데, 완벽한 기초 상태란 게 사실 도달점이 없습니다. 알면 알수록 모르는 것이 보이는 구조라서, 언제 이제 됐다고 느끼기가 어렵습니다.
개발 공부는 이론을 먼저 완성한 뒤 실전에 적용하는 순서로 흘러가지 않습니다. 실제로는 뭔가를 만들다가 막히고, 그 막힌 지점에서 개념을 찾아보면서 이해가 깊어지는 방식에 가깝습니다. JavaScript를 예로 들면, 조건문과 반복문을 따로 외우는 것보다 간단한 할 일 목록(To-do list) 기능을 직접 구현해 보면서 이벤트 핸들러(Event Handler), 즉 사용자 입력에 반응하는 코드 덩어리를 연결해 보는 편이 훨씬 빠르게 체화됩니다.
백엔드도 마찬가지입니다. REST API(Representational State Transfer API)란 클라이언트와 서버가 데이터를 주고받기 위한 통신 규약으로, 요즘 웹 서비스 대부분이 이 방식을 씁니다. 이걸 이론으로만 정리하려고 하면 끝이 없습니다. 간단한 게시판을 만들면서 요청과 응답 흐름을 직접 손으로 따라가 보는 것이 이해도 빠르고, 나중에 면접에서 설명할 말도 생깁니다. 제 경험상 이건 좀 다릅니다. 이론 정리만 한 시기보다 부족하더라도 직접 만들어본 시기에 훨씬 많이 배웠습니다.
완벽주의를 줄이면서 실행력을 높이려면 이런 기준이 도움이 됩니다.
- 핵심 기능 하나를 먼저 완성하고, 이후에 오류 처리와 디자인을 순서대로 보완한다
- 공부 단위를 이번 주에 이벤트 처리와 배열 메서드로 작은 기능 만들기처럼 작게 나눈다
- 막히면 멈추지 말고 일단 구현하고, 이유는 나중에 찾아본다
고용노동부가 발표한 청년 취업 실태 조사에 따르면, IT 직군 신입 취업자 중 다수가 완성도보다 실행 경험이 취업에 더 도움이 됐다고 응답했습니다(출처: 고용노동부). 완벽한 준비보다 작은 실행이 실제 현장에서 더 높이 평가된다는 점은, 단순한 위로가 아니라 데이터로도 나타납니다.
포트폴리오와 지원 타이밍을 놓치지 않으려면
완벽주의가 두 번째로 독이 되는 지점은 포트폴리오와 지원 타이밍입니다. 처음부터 쇼핑몰이나 커뮤니티처럼 규모 있는 프로젝트를 만들려다 중간에 방향을 잃고 포기하는 경우를 주변에서 많이 봤습니다. 솔직히 이건 예상 밖이었습니다. 큰 프로젝트가 인상적일 것 같아서 의욕 있게 시작했는데, 구현 범위가 넓어질수록 오류가 쌓이고 결국 포트폴리오에 아무것도 올리지 못하는 상황이 생깁니다.
신입 포트폴리오에서 기업이 실제로 보는 것은 완성도 높은 서비스가 아닙니다. 지원 직무와 연결되는 기능을 직접 구현했고, 그 과정에서 어떤 문제를 어떻게 해결했는지 설명할 수 있는지가 핵심입니다. 프런트엔드(Frontend) 지원자라면, 여기서 프런트엔드란 사용자가 직접 보고 조작하는 화면 영역을 담당하는 개발 분야를 말합니다. 작은 영화 검색 페이지라도 API 연동, 상태 관리(State Management), 반응형 레이아웃 처리가 있다면 충분히 경험으로 인정됩니다. 여기서 상태 관리란 사용자 입력이나 서버 응답에 따라 화면이 어떻게 바뀌는지를 코드로 제어하는 방식을 뜻합니다.
백엔드(Backend) 지원자도 마찬가지입니다. 백엔드란 서버, 데이터베이스, 비즈니스 로직 등 사용자 눈에 보이지 않는 서버 측 처리를 담당하는 분야입니다. 간단한 게시판이라도 회원가입, 로그인, DB 연동, 예외 처리(Exception Handling) 흐름을 설명할 수 있다면 좋은 경험이 됩니다. 예외 처리란 오류가 발생했을 때 서비스가 멈추지 않도록 대응하는 코드 구조를 말하는데, 이 부분을 설명할 수 있다는 것 자체가 신입에게는 차별화 포인트가 됩니다.
지원 타이밍도 같은 맥락입니다. 포트폴리오가 더 좋아지면 넣겠다는 생각이 반복되면 지원은 계속 뒤로 밀립니다. 한국고용정보원의 분석에 따르면 IT 직군 신입 채용에서 서류 검토 기간은 평균 2~3주 내외로, 지원 시점이 늦을수록 피드백을 받고 보완할 기회 자체가 줄어듭니다(출처: 한국고용정보원). 이력서를 써보고, 서류 결과를 확인하고, 면접 질문을 경험해야 내가 어느 지점에서 부족한지 실제로 알 수 있습니다. 공부만으로는 그 부분이 보이지 않습니다.
면접 준비에서 답변보다 솔직하고 구체적인 답변이 더 중요하다
면접 준비도 마찬가지입니다. 모든 질문에 완벽한 답변을 외우려다 보면, 실제 면접에서 예상외 질문이 나왔을 때 더 당황합니다. 제가 직접 겪어봤는데, 외운 문장보다 실제 프로젝트에서 겪은 오류를 구체적으로 말했을 때 면접관의 반응이 훨씬 좋았습니다. 저는 문제 해결 능력이 뛰어납니다 보다 API 응답 오류가 생겼을 때 HTTP 상태 코드를 확인해 원인을 찾았습니다가 훨씬 설득력 있습니다. 여기서 HTTP 상태 코드란 서버가 요청을 어떻게 처리했는지를 숫자로 알려주는 응답 코드로, 404는 페이지 없음, 500은 서버 오류를 뜻합니다.
완벽한 준비가 된 뒤 지원하겠다는 생각은, 완벽한 상태가 오면 지원하겠다는 말과 같습니다. 그 상태는 좀처럼 오지 않습니다. 작은 프로젝트를 완성하고, 기록하고, 부족한 상태로 지원하면서 보완하는 과정 자체가 준비의 일부입니다. 저는 그 순서를 바꾸고 나서야 공부와 프로젝트, 지원 준비가 조금씩 연결되기 시작했습니다.
완벽주의를 내려놓는 것은 대충 하자는 뜻이 아닙니다. 완성 가능한 단위로 나누고, 실제 결과물을 만든 뒤 계속 개선하자는 뜻입니다. 신입에게 필요한 것은 처음부터 완성된 실력이 아니라, 부족하더라도 직접 해보고 설명하고 개선하는 태도입니다. 작게 시작하고, 기록하고, 지원하면서 부족한 점을 채워나가는 방식이 IT 취업 준비에서는 훨씬 현실적입니다.