비전공자로 개발자 취업을 준비하던 한 학생은 포트폴리오에 넣을 만한 결과물이 없다며 프로젝트 시작을 계속 미루고 있었습니다. 쇼핑몰이나 커뮤니티처럼 규모가 큰 서비스를 만들어야 한다고 생각했지만, 로그인과 데이터베이스 설계, 결제, 배포까지 한꺼번에 공부하려니 시작 지점조차 정하기 어려웠습니다. 상담 과정에서 완성된 서비스를 목표로 삼기보다 사용자 입력을 받아 오류를 검사하는 기능부터 만들어 보도록 방향을 바꿨습니다. 이메일이 비어 있거나 형식이 맞지 않을 때 저장되지 않도록 처리하고, 정상값과 잘못된 값을 나누어 결과를 확인했습니다.
기능 자체는 단순했지만 그 안에는 변수, 조건문, 사용자 입력, 오류 처리와 테스트가 포함돼 있었습니다. 이후 외부 API 요청에 실패했을 때 안내 문구를 보여주는 화면을 만들고, 두 기능을 연결해 회원별 관심 지역의 날씨를 확인하는 프로젝트로 확장했습니다. 처음에는 따라 작성한 코드만 있었지만 오류가 발생한 상황과 수정 과정을 기록하면서 포트폴리오에 설명할 내용도 생겼습니다. IT 커리어는 거대한 결과물을 한 번에 완성하면서 시작되는 것이 아닙니다. 좁은 범위라도 직접 구현하고 문제를 확인하며 다음 단계로 확장한 과정이 쌓일 때 직무 역량과 성장 가능성을 보여주는 근거가 됩니다.
실습은 작은 기능이라도 확인할 목표가 있어야 합니다
- 결과를 실행하는 것보다 확인할 기준이 먼저입니다
입문자는 강의에 나온 코드를 그대로 작성하고 같은 화면이 나타나면 학습이 끝났다고 생각하기 쉽습니다. 하지만 코드를 따라 입력한 결과와 자신이 조건을 판단해 만든 기능은 다릅니다. 간단한 연습이라도 무엇을 확인하려는지 정해야 문법이 실제 문제와 연결됩니다.
사용자 나이를 입력받아 성인 여부를 표시하는 기능을 만든다면 정상적인 숫자만 넣어서는 충분하지 않습니다. 빈 값, 문자, 음수, 지나치게 큰 숫자가 들어왔을 때 어떤 결과가 나오는지 확인할 수 있습니다. 처음에는 조건문 하나를 연습하는 과제였지만 입력값의 범위와 잘못된 요청을 처리하는 연습으로 넓어집니다.
- 시작하기 전에 구현 목표를 한 문장으로 적어보는 것이 좋습니다. 사용자가 이메일을 입력하면 형식을 확인하고 잘못된 경우 이유를 안내한다는 정도로 정하면 필요한 입력과 결과가 분명해집니다.
- 정상적으로 동작하는 상황과 실패하는 조건을 최소한 하나씩 만들어 봐야 합니다. 성공 화면만 확인하면 실제 서비스에서 발생하는 빈 값, 중복 요청, 네트워크 오류를 다루는 습관이 생기기 어렵습니다.
- 결과가 예상과 다르다면 코드를 전부 지우기보다 콘솔 문구와 입력값, 실행 순서를 확인해야 합니다. 무엇을 보고 원인을 좁혔는지가 이후 문제해결 사례의 핵심이 됩니다.
- 직무마다 의미 있는 연습의 형태가 다릅니다
모든 준비생이 같은 미니 과제를 수행할 필요는 없습니다. 목표 분야에서 자주 다루는 문제를 짧은 작업으로 경험해야 직무 이해와 연결됩니다. 프런트엔드는 화면의 상태 변화와 입력 검증을, 백엔드는 요청과 데이터 저장, 오류 응답을 확인할 수 있습니다.
데이터 직무를 준비하는 사람이라면 CSV 파일을 불러와 그래프를 그리는 데서 멈추지 않고 추출 기준과 계산 결과를 검증해야 합니다. 정보보안 분야라면 로그인 실패 로그를 분류하고 단순한 입력 실수와 반복 공격 가능성을 구분해 볼 수 있습니다. 클라우드와 인프라를 준비한다면 가상 서버 생성보다 SSH 접속, 포트 허용, 실행 로그를 순서대로 확인하는 연습이 도움이 됩니다.
SQL을 공부한 한 지원자는 고객별 구매 횟수를 계산하는 쿼리를 작성했습니다. 실행 결과는 나왔지만 같은 날 결제를 나눠 진행한 고객도 재구매 고객으로 포함돼 있었습니다. 이후 재구매 기준을 서로 다른 날짜의 구매로 다시 정하고 조건을 수정했으며 이전 결과와 차이를 비교했습니다.
- 결과 중심 설명: SQL을 사용해 고객별 재구매율을 계산했습니다.
- 판단이 포함된 설명: 주문 횟수만 기준으로 계산하자 같은 날 나눈 결제도 재구매에 포함됐습니다. 구매 날짜가 다른 경우로 기준을 바꾸고 이전 수치와 비교해 지표가 달라진 이유를 정리했습니다.
- 오류 하나를 해결한 과정도 기술 경험이 됩니다
초보자는 오류가 발생하면 자신이 공부를 못하고 있다고 생각하기 쉽습니다. 그러나 실무에서도 오류를 완전히 피할 수는 없으며 중요한 것은 원인을 확인하고 수정한 뒤 다시 검증하는 능력입니다. 범위가 좁은 연습에서는 코드가 복잡하지 않아 이러한 과정을 관찰하기 좋습니다.
클라우드 서버에 간단한 웹 페이지를 배포한 준비생이 브라우저에서 화면이 열리지 않는 문제를 겪었습니다. 처음에는 서버가 고장 났다고 생각해 인스턴스를 반복해서 재시작했습니다. 이후 서버 상태, 공인 IP, 애플리케이션 실행 여부, 보안그룹의 포트 규칙을 차례로 확인했고 외부 접속 포트가 허용되지 않은 것을 발견했습니다.
포트 규칙을 수정한 뒤 외부에서 다시 접속하고 서버 로그까지 확인했습니다. 단순히 배포에 성공했다는 문장보다 잘못된 판단에서 시작해 장애 구간을 좁힌 흐름이 더 구체적인 자료가 됐습니다.
- 짧은 과제는 반복해서 변형해야 합니다
한 번 완성한 예제를 그대로 보관하면 특정 코드만 기억하게 될 수 있습니다. 입력값이나 조건, 결과 형식을 바꿔 다시 구현해야 배운 개념을 다른 문제에도 적용할 수 있습니다. 학생 점수 계산을 배웠다면 월별 지출 계산으로 바꾸고, 로그인 검증을 배웠다면 회원가입과 비밀번호 변경으로 확장할 수 있습니다.
변형 과정에서 막힌 부분을 기록하면 자신이 개념을 이해한 영역과 예제에 의존한 부분이 구분됩니다. 같은 조건문을 다른 기능에서 사용할 수 있다면 문법을 외운 단계를 넘어 문제에 적용하기 시작한 것입니다.
프로젝트는 여러 실습을 하나의 사용자 흐름으로 연결해야 합니다
- 기능을 많이 모으는 것만으로 결과물이 되지는 않습니다
미니 과제를 여러 개 완성해도 서로 관계없이 나열하면 포트폴리오에서 직무 역량을 전달하기 어렵습니다. 하나의 사용자 문제를 중심으로 기능을 연결하고 입력부터 결과까지 흐름을 만들어야 합니다.
예를 들어 회원가입 검증, 로그인, 게시글 저장을 각각 연습했다면 이를 간단한 학습 기록 서비스로 묶을 수 있습니다. 사용자가 계정을 만들고 로그인한 뒤 공부 내용을 등록하며 자신의 기록만 수정할 수 있도록 구성합니다. 이 과정에서 인증, 권한, 데이터 저장과 오류 처리를 연결하게 됩니다.
한 백엔드 준비생은 회원가입과 게시판 CRUD를 별도의 예제로 보관하고 있었습니다. 이를 하나의 서비스로 연결하자 다른 사용자의 게시글을 수정할 수 있는 문제가 발견됐습니다. 로그인 여부만 확인하고 작성자 권한을 검사하지 않았기 때문입니다. 사용자 ID와 작성자 정보를 비교하도록 수정하고 본인, 다른 사용자, 로그인하지 않은 요청을 나누어 테스트했습니다.
- 기능 나열형 설명: 회원가입과 로그인, 게시판 CRUD를 구현했습니다.
- 흐름이 보이는 설명: 로그인한 사용자가 자신의 학습 기록만 수정하도록 권한을 구분했습니다. 다른 사용자의 게시글 ID로 수정 요청을 보내는 상황을 재현하고 작성자 검증을 추가한 뒤 세 가지 권한 조건을 다시 확인했습니다.
- 프로젝트 규모는 해결하려는 문제에 맞아야 합니다
첫 결과물부터 쇼핑몰 전체를 만들려 하면 상품, 주문, 결제, 배송, 관리자 기능까지 범위가 빠르게 커집니다. 구현한 화면은 많아질 수 있지만 각 기능의 데이터 흐름과 실패 조건을 충분히 확인하기 어렵습니다. 목표 직무에서 보여주고 싶은 역량에 맞춰 범위를 줄이는 편이 효과적입니다.
프런트엔드 지원자라면 여러 페이지보다 상품 검색 화면 하나를 깊게 만들 수 있습니다. 검색어 입력, 결과 조회, 로딩 상태, 빈 결과, API 실패, 재시도를 다루면 비동기 처리와 사용자 흐름을 설명할 수 있습니다. 데이터 지원자는 여러 주제의 차트를 만드는 대신 하나의 지표를 정의하고 추출 기준과 해석을 검증할 수 있습니다.
- 구현하려는 핵심 사용자를 한 명으로 정하면 기능 우선순위가 선명해집니다. 모든 사람을 위한 서비스보다 취업 준비생이 학습 일정을 기록하는 도구처럼 구체적인 상황을 선택하는 것이 좋습니다.
- 반드시 필요한 기능과 있으면 좋은 기능을 나누어야 합니다. 핵심 흐름이 완성되기 전에 채팅, 추천, 통계 같은 부가 기능을 추가하면 구현 범위만 커질 수 있습니다.
- 한 기능마다 정상 상황과 실패 조건을 정리해야 합니다. 저장 성공만 확인하지 말고 빈 값, 중복 데이터, 권한 부족과 서버 오류를 어떻게 처리할지도 살펴봐야 합니다.
- 팀 결과와 개인 역할을 분리해야 합니다
팀 결과물은 협업 경험을 보여줄 수 있지만 자신이 담당한 부분이 보이지 않으면 평가하기 어렵습니다. 서비스 전체 기능을 모두 자신이 구현한 것처럼 설명해서도 안 되고 팀 프로젝트라는 이유로 개인행동을 지나치게 줄여서도 안 됩니다.
예약 서비스 팀에서 한 지원자는 프런트엔드 화면을 담당했습니다. 처음에는 예약 서비스를 만들었다고만 설명했지만 검토 과정에서 API 요청이 처리되는 동안 버튼을 반복해서 누르면 같은 예약이 두 번 전송되는 문제를 직접 해결한 경험이 확인됐습니다. 버튼을 비활성화하고 처리 상태를 표시했으며, 실패 응답을 받은 뒤에도 입력한 날짜와 시간이 유지되도록 수정했습니다.
팀이 완성한 기능, 자신이 작성한 코드, 함께 논의한 기준을 나누어 기록하자 담당 역할과 협업 과정이 함께 드러났습니다. 프로젝트의 크기보다 개인이 판단하고 바꾼 내용을 명확하게 제시하는 것이 중요합니다.
- 배포와 사용자 확인이 다음 개선점을 만듭니다
개인 컴퓨터에서만 실행하면 자신이 예상한 방식으로 기능을 사용하게 됩니다. 외부에 배포하고 다른 사람이 사용하면 설명이 부족한 화면, 예상하지 못한 입력, 실행 환경의 차이를 발견할 수 있습니다.
할 일 관리 서비스를 배포한 준비생은 자신에게는 익숙했던 완료 버튼을 사용자가 삭제 기능으로 오해한다는 피드백을 받았습니다. 버튼 이름과 색상을 수정하고 완료된 항목을 다시 되돌릴 수 있도록 변경했습니다. 모바일 화면에서는 입력창이 버튼에 가려지는 문제도 발견해 화면 배치를 조정했습니다.
피드백을 모두 반영할 필요는 없지만 누구의 어떤 사용 상황에서 문제가 발생했는지 확인해야 합니다. 수정 전후를 비교하고 채택하지 않은 의견의 이유까지 정리하면 단순한 화면 제작을 넘어 사용자 관점의 판단을 보여줄 수 있습니다.
성장기록은 흩어진 경험을 취업 근거로 연결합니다
- 완성된 결과만 남기면 발전 과정이 사라집니다
최종 화면과 소스코드만 남기면 처음에 무엇을 몰랐고 어떤 판단을 거쳐 바꿨는지 알기 어렵습니다. 학습 초기의 부족함을 모두 공개할 필요는 없지만 대표적인 오류와 수정 과정은 남겨두는 것이 좋습니다.
한 준비생은 외부 API에서 받은 데이터를 화면에 표시하면서 응답 구조를 확인하지 않고 예제 코드의 필드 이름을 그대로 사용했습니다. 화면에 값이 나타나지 않자 출력 코드를 여러 번 수정했지만 원인을 찾지 못했습니다. 개발자 도구에서 실제 응답을 확인한 뒤 필요한 데이터가 다른 객체 안에 있다는 사실을 발견했습니다.
이후에는 요청 주소, 응답 상태, 데이터 구조, 화면 반영 순서로 점검하는 기준을 만들었습니다. 처음의 실수는 사라졌지만 확인 순서를 기록했기 때문에 다음 API 연동에서도 활용할 수 있었습니다. 성장기록은 실패를 모아두는 노트가 아니라 판단 기준이 어떻게 달라졌는지 보여주는 자료입니다.
- Git 기록에는 변경 목적이 보여야 합니다
Git을 사용한다고 해서 자동으로 협업과 발전 과정이 드러나는 것은 아닙니다. 수정, 최종, 진짜 최종과 같은 커밋 메시지는 어떤 문제를 해결했는지 알려주지 못합니다. 작업 단위를 작게 나누고 변경 목적을 표시해야 과정을 다시 복기할 수 있습니다.
로그인 기능을 예로 들면 로그인 구현이라는 한 번의 기록으로 끝내기보다 빈 입력값 검증 추가, 만료된 토큰 요청 차단, 실패 메시지 분리처럼 변경 이유를 나눌 수 있습니다. 이후 면접을 준비할 때 커밋을 살펴보면 어떤 문제가 있었고 무엇을 바꿨는지 구체적인 사례를 찾을 수 있습니다.
- 커밋에는 파일 이름보다 해결한 문제를 중심으로 작성하는 편이 좋습니다. 회원 화면 수정이라는 표현보다 중복 이메일 응답에 따른 안내 문구 분리처럼 결과를 예상할 수 있도록 남깁니다.
- 하나의 커밋에 서로 관련 없는 변경을 모두 넣지 않는 것이 좋습니다. 화면 색상 수정과 인증 오류 처리가 분리돼 있으면 각 작업의 목적과 결과를 확인하기 쉽습니다.
- 완벽한 커밋 기록을 만들기 위해 작업을 멈출 필요는 없습니다. 자신이 다시 보았을 때 변경 이유를 이해할 수 있는 수준부터 꾸준히 유지하는 것이 중요합니다.
- README에는 기능보다 판단을 보여줘야 합니다
README에서 기술 스택과 기능 목록만 길게 작성하면 비슷한 결과물과 차이를 만들기 어렵습니다. 프로젝트 목적, 개인 역할, 핵심 흐름, 기술 선택 이유, 대표적인 문제해결, 실행 방법과 남은 한계를 정리해야 합니다.
파일 업로드 기능을 구현한 지원자는 처음에 원본 이름을 그대로 저장했습니다. 같은 이름의 파일을 다시 올리자 기존 자료가 덮어써지는 문제가 발생했고 허용하지 않은 형식도 저장될 수 있었습니다. 이후 저장 이름을 별도로 생성하고 파일 크기와 형식을 검사했으며 중복 이름, 빈 파일, 잘못된 확장자를 나누어 테스트했습니다.
README에는 최종 코드만 넣는 대신 문제 상황, 처음 사용한 방식의 한계, 수정 기준과 검증 결과를 함께 작성했습니다. 단순한 업로드 기능이 데이터 관리와 입력 검증을 고려한 사례로 바뀌었습니다.
- 기록은 면접 답변의 재료가 됩니다
면접을 앞두고 프로젝트를 기억에 의존해 정리하면 기능 이름만 떠오르거나 팀 전체의 결과를 자신의 경험과 혼동할 수 있습니다. 작업 당시 남긴 오류 문구, 커밋, 테스트 결과와 회고를 확인하면 상황과 행동을 구체적으로 복원할 수 있습니다.
- 초기 답변: 프로젝트에서 로그인 기능을 담당했습니다.
- 과정이 담긴 답변: 만료된 토큰으로 API 요청을 보내면 로그인 화면과 오류 안내가 반복되는 현상을 발견했습니다. 응답 상태를 기준으로 인증 정보를 정리하고 로그인 화면으로 한 번만 이동하도록 수정한 뒤 정상 토큰과 만료된 토큰을 나누어 확인했습니다.
두 답변은 같은 기능을 설명하지만 평가자가 확인할 수 있는 정보는 다릅니다. 후자의 답변에는 발생한 현상, 확인한 기준, 수정한 행동과 검증 결과가 들어 있습니다. 평소 기록이 있어야 예상하지 못한 후속 질문에도 실제 행동을 근거로 답할 수 있습니다.
- conclusion
IT 커리어는 처음부터 규모가 큰 프로젝트나 화려한 기술을 사용해야 시작되는 것이 아닙니다. 사용자 입력을 검사하고, SQL 조건을 수정하고, 접속 오류의 원인을 좁히는 짧은 작업도 직접 판단하고 검증했다면 의미 있는 직무 경험이 됩니다. 중요한 것은 단순한 예제로 끝내지 않고 관련 기능을 하나의 사용자 흐름으로 연결하며, 수정한 이유와 결과를 남기는 것입니다.
- 현재 공부 중인 직무에서 일주일 안에 완성할 수 있는 기능 하나를 정해 보세요. 프런트엔드는 입력 검증과 API 실패 처리, 백엔드는 요청값과 오류 응답, 데이터 직무는 추출 기준과 지표 검증처럼 실제 업무와 가까운 항목이 좋습니다.
- 구현 후에는 정상 상황과 실패 조건을 각각 확인해 보세요. 오류가 발생했다면 처음 예상한 원인, 확인한 문구, 수정한 내용, 다시 검증한 결과를 순서대로 남겨야 문제해결 사례가 됩니다.
- 여러 연습이 쌓였다면 하나의 사용자 문제를 중심으로 연결해 보세요. Git에는 변경 목적을 남기고 README에는 개인 역할과 대표적인 개선 내용을 정리하면 포트폴리오와 면접에 함께 활용할 수 있습니다.
실제 포트폴리오를 검토해 보면 경험이 없다고 말하는 준비생도 코드를 다시 살펴보면 직접 해결한 문제가 있는 경우가 많았습니다. 다만 결과 화면만 남아 있어 왜 수정했는지 기억하지 못하거나 너무 단순하다고 생각해 자료에서 제외한 것이 문제였습니다. 규모가 작더라도 상황과 판단, 행동, 검증 결과가 있다면 취업 자료로 발전시킬 수 있습니다. 오늘 완성한 기능 하나가 다음 기능의 기초가 되고, 연결된 결과물이 프로젝트가 되며, 그동안 남긴 기록이 자신의 성장 속도를 설명하는 근거가 됩니다. 결국 커리어의 출발점은 거창한 성과가 아니라 직접 해보고 고치며 남긴 경험입니다.
