개발자 취업을 준비하는 한 비전공자의 학습 자료를 검토한 적이 있습니다. 자바와 파이썬, 자바스크립트 강의를 수강했고 데이터베이스와 알고리즘 문제도 꾸준히 공부하고 있었습니다. 개인 프로젝트로 게시판과 쇼핑몰 화면까지 만들었기 때문에 준비한 양은 적지 않았습니다. 그러나 프런트엔드와 백엔드 중 어느 분야에 지원할 것인지 물었을 때는 취업 가능성이 높은 쪽을 선택하고 싶다고 답했습니다. 게시글 작성 요청이 서버에서 어떤 과정을 거쳐 저장되는지 설명하지 못했고, 화면에서 API 요청이 실패했을 때 사용자에게 무엇을 보여줘야 하는지도 정리되어 있지 않았습니다. 여러 기술을 배웠지만 학습 내용과 프로젝트, 목표 직무가 서로 연결되지 않은 상태였습니다.
이 사례에서 부족했던 것은 전공 지식의 양이 아니었습니다. 방향을 정하지 않은 채 공부 범위를 계속 넓혔고, 배운 개념을 작은 기능에서 검증하지 않았으며, 프로젝트에서도 자신이 해결한 문제를 기록하지 않은 것이 더 큰 문제였습니다. 비전공자 개발자 취업은 전공과목을 모두 따라잡은 뒤 시작하는 과정이 아닙니다. 목표 역할을 먼저 좁히고 필요한 기초를 실제 코드에 적용하며, 발생한 오류와 수정 과정을 포트폴리오로 바꿔야 합니다. 방향설정과 기초학습, 결과물 제작이 하나의 흐름으로 이어져야 준비 기간도 취업에 필요한 경험으로 쌓입니다.
방향설정은 개발자라는 이름보다 해결하고 싶은 문제에서 시작합니다
- 프런트엔드와 백엔드는 반복하는 업무가 다릅니다
개발자를 준비한다고 해서 모든 기술을 같은 수준으로 배워야 하는 것은 아닙니다. 프런트엔드는 사용자가 직접 보는 화면과 입력, 상태 변화, API 응답에 따른 흐름을 구현합니다. 백엔드는 화면에서 들어온 요청을 검증하고 업무 규칙에 따라 데이터를 처리하며 인증과 권한, 저장과 오류 응답을 담당합니다.
같은 회원가입 기능을 만들더라도 확인하는 문제가 다릅니다. 화면 영역에서는 사용자가 이메일 형식을 잘못 입력했을 때 언제 안내할지, 요청 중 버튼을 다시 누르지 못하게 할지, 성공과 실패 상태를 어떻게 보여줄지 고민합니다. 서버 영역에서는 중복 이메일과 비밀번호 처리, 데이터 저장, 인증 정보 발급, 예외 응답을 설계합니다.
- 화면의 작은 변화와 사용자 행동을 관찰하고 수정하는 과정에 관심이 있다면 프런트엔드를 먼저 경험해 볼 수 있습니다. 디자인된 화면을 코드로 옮기는 것뿐 아니라 로딩과 오류, 결과 없음 상태를 다루는 작업도 포함됩니다.
- 요청이 처리되는 순서와 데이터 저장 구조, 인증과 권한을 설계하는 과정이 흥미롭다면 백엔드가 더 잘 맞을 수 있습니다. 화면에 바로 보이지 않는 문제를 로그와 데이터로 추적하는 일이 많습니다.
- 두 분야 모두 코드를 작성하고 오류를 해결하며 다른 담당자와 협업합니다. 디자인 감각이 있으면 프런트엔드, 수학을 잘하면 백엔드라는 단순한 기준만으로 선택하지 않는 것이 좋습니다.
- 디자인 경험을 화면 개발 역량으로 바꾼 사례
시각디자인을 전공한 준비생은 기존 전공을 활용할 수 있다는 이유로 프런트엔드를 선택했습니다. 초기 프로젝트에는 여행 일정 관리 서비스가 있었고 색상과 화면 배치는 깔끔했습니다. 하지만 날짜를 입력하지 않아도 일정이 등록됐고, API 요청이 실패해도 사용자는 성공 여부를 알 수 없었습니다.
이 준비생은 처음에 포트폴리오가 부족해 보이는 이유가 디자인이 단순해서라고 생각했습니다. 그러나 검토 과정에서 부족하게 보인 부분은 화면의 화려함이 아니라 사용자의 입력과 서버 요청을 연결하는 처리였습니다. 디자인 경험이 있어도 상태 변화와 오류 상황을 구현하지 않으면 개발 역량을 확인하기 어려웠습니다.
이후 일정 제목과 날짜를 화면에서 검증하고 요청 중에는 등록 버튼을 비활성화했습니다. 서버 오류와 일정 시간 중복을 서로 다른 메시지로 안내했으며, 사용자가 내용을 수정하고 다시 전송할 수 있도록 화면 흐름을 바꿨습니다. 정상 등록과 빈 입력, 잘못된 날짜, 느린 응답, 반복 클릭을 각각 테스트했습니다.
- 화면 중심 설명: 사용하기 편리한 여행 일정 관리 화면을 제작했습니다.
- 역할이 보이는 설명: 일정 등록 화면을 담당하고 입력값 검증과 API 연동, 로딩 상태를 구현했습니다.
- 직무 역량이 담긴 설명: 반복 클릭으로 같은 일정이 여러 번 요청되는 문제를 발견해 전송 중 버튼을 비활성화했습니다. 서버 오류와 일정 충돌을 구분해 안내하고 정상 입력과 예외 입력을 다시 테스트했습니다.
기존 전공은 단순히 디자인을 잘한다는 설명이 아니라 사용자 행동을 관찰하고 다음 행동을 안내한 근거로 연결됐습니다. 화면 제작 경험이 프런트엔드 문제해결 사례로 바뀐 것입니다.
- 데이터 흐름에 관심을 발견한 백엔드 준비 사례
행정학을 전공한 다른 준비생은 웹 개발 교육에서 화면과 서버를 모두 구현했습니다. 처음에는 결과가 바로 보이는 프런트엔드가 취업 준비에 유리하다고 생각했지만 화면 스타일을 반복해서 수정하는 작업보다 요청이 처리되고 데이터가 저장되는 과정을 이해하는 데 더 많은 시간을 사용했습니다.
게시글 삭제 기능을 만들면서 작성자가 아닌 사용자도 주소를 직접 호출하면 삭제할 수 있는 문제를 발견했습니다. 화면에서 삭제 버튼을 숨겼기 때문에 권한 처리가 끝났다고 생각했지만, API 요청을 직접 보내면 다른 사용자의 게시글도 삭제됐습니다.
화면에 버튼이 보이는지와 서버에서 실제 권한을 확인하는 것은 다른 문제였습니다. 준비생은 로그인한 사용자 정보와 게시글 작성자를 서버에서 비교하고 권한이 없으면 삭제되지 않도록 수정했습니다. 작성자와 다른 사용자, 로그인하지 않은 사용자의 요청을 나누어 테스트했습니다.
- 처음에는 게시글 작성과 수정, 삭제 기능을 구현했다는 결과만 정리했습니다. 누구나 요청 주소를 직접 호출할 수 있다는 점은 고려하지 않았습니다.
- 보완 후에는 화면의 버튼 제어와 서버의 권한 검증을 구분했습니다. 사용자 상태별 요청과 응답 결과도 README에 추가했습니다.
- 면접에서는 백엔드를 선택한 이유를 취업 가능성으로 설명하지 않고 요청과 데이터, 권한 규칙을 설계하는 과정에 더 집중했던 경험으로 말할 수 있게 됐습니다.
- 채용공고와 작은 실습을 함께 비교해야 합니다
직무를 선택할 때 온라인 후기나 유행하는 기술만 참고하면 공부 방향이 자주 흔들릴 수 있습니다. 여러 채용공고에서 실제 담당 업무와 반복적으로 요구하는 기술을 확인하고 작은 기능을 직접 구현해 봐야 합니다.
프런트엔드 공고에서도 서비스 화면과 디자인 시스템, 데이터 시각화, 모바일 웹처럼 업무 비중이 다를 수 있습니다. 백엔드 역시 API 개발과 사내 시스템, 데이터 처리, 배치 작업, 서비스 운영처럼 담당 범위가 달라집니다.
하나의 회원가입 기능을 화면과 서버에서 모두 구현해 보는 것도 좋은 방법입니다. 화면에서는 입력과 로딩, 성공과 실패 상태를 다루고 서버에서는 검증과 중복 확인, 비밀번호 처리, 데이터 저장을 경험할 수 있습니다. 어느 과정에서 더 집중했고 오류가 발생했을 때 어느 영역을 계속 파고들고 싶었는지를 기록하면 방향설정의 근거가 됩니다.
기초학습은 강의 진도보다 작은 기능으로 이해도를 확인해야 합니다
- 모든 CS 과목을 먼저 끝내려고 하면 실습이 늦어집니다
비전공자는 자료구조와 알고리즘, 운영체제, 네트워크, 데이터베이스를 모두 공부한 뒤 프로젝트를 시작해야 한다고 생각하기 쉽습니다. 하지만 적용 경험 없이 개념만 반복하면 무엇을 이해했고 어디가 부족한지 판단하기 어렵습니다.
기초학습은 전공과목 전체를 암기하는 과정이 아닙니다. 자신이 준비하는 기능에서 필요한 개념을 이해하고 코드로 확인하는 과정입니다. HTTP 요청과 응답을 공부했다면 로그인 기능에서 상태 코드와 오류 메시지를 확인하고, 데이터베이스를 배웠다면 중복 데이터와 트랜잭션 문제를 직접 테스트해 볼 수 있습니다.
- 프로그래밍 언어는 문법 문제만 풀지 말고 입력과 조건, 반복, 함수, 객체를 작은 기능에 적용해야 합니다. 코드를 복사하지 않고 처리 순서를 설명할 수 있는지도 확인해야 합니다.
- 네트워크 기초는 용어 암기보다 사용자의 요청이 화면에서 서버까지 이동하는 과정과 연결해야 합니다. 주소와 포트, HTTP 방식, 상태 코드가 프로젝트에서 어디에 나타나는지 살펴보는 것이 좋습니다.
- 데이터베이스는 조회문 작성뿐 아니라 테이블 관계와 제약조건, 데이터 일관성을 이해해야 합니다. 잘못된 값과 중복된 값이 저장되지 않도록 어느 단계에서 확인할지도 고민해야 합니다.
- 자료구조와 알고리즘은 코딩테스트 준비로만 보지 않아야 합니다. 데이터를 어떤 형태로 저장하고 탐색할지, 같은 기능을 더 명확하고 효율적으로 처리할 방법이 있는지 프로젝트와 연결할 수 있습니다.
- 비밀번호 재설정 기능에서 기초 부족이 드러난 사례
백엔드를 준비한 지원자는 사용자가 이메일을 입력하면 비밀번호를 변경할 수 있는 기능을 만들었습니다. 이메일이 데이터베이스에 존재하면 재설정 주소를 전송했고 해당 주소로 들어가 새 비밀번호를 저장했습니다. 정상적인 흐름에서는 기능이 작동했습니다.
그러나 재설정 주소를 여러 번 사용할 수 있었고 시간이 오래 지난 뒤에도 비밀번호를 변경할 수 있었습니다. 다른 사용자가 주소를 알게 되면 계속 사용할 수 있다는 문제가 있었습니다. 준비생은 처음에 이메일을 확인했으니 인증이 완료됐다고 생각했지만 재설정 요청의 유효기간과 사용 여부를 관리하지 않았습니다.
이후 재설정 요청마다 임의의 식별값과 만료 시간을 저장하고 한 번 사용한 값은 다시 사용할 수 없도록 처리했습니다. 존재하지 않는 값과 만료된 값, 이미 사용한 값에는 서로 다른 결과를 반환했습니다. 새 요청을 만들었을 때 이전 요청을 어떻게 처리할지도 기준을 정했습니다.
- 기능 중심 설명: 이메일을 이용한 비밀번호 재설정 기능을 구현했습니다.
- 처리 흐름이 보이는 설명: 재설정 요청마다 식별값과 만료 시간을 저장하고 새 비밀번호로 변경하도록 처리했습니다.
- 검증까지 담긴 설명: 같은 재설정 주소를 반복해서 사용할 수 있는 문제를 발견했습니다. 만료 시간과 사용 여부를 추가하고 정상 요청, 만료된 요청, 이미 사용한 요청, 존재하지 않는 값을 나누어 테스트했습니다.
이 경험을 통해 인증과 데이터 상태, 시간 조건, 오류 응답을 함께 이해할 수 있었습니다. 보안 개념을 암기한 것이 아니라 작은 기능에서 문제가 발생하는 이유와 처리 기준을 확인한 사례입니다.
- 페이지가 바뀌어도 검색 조건이 남았던 화면 사례
프런트엔드를 준비한 지원자는 상품 목록에 검색과 정렬, 페이지 이동 기능을 구현했습니다. 처음에는 각각의 기능이 정상적으로 작동했지만 검색어를 바꾼 뒤 기존 페이지 번호가 유지되면서 결과가 없는 화면이 나타났습니다. 예를 들어 10페이지를 보고 있던 사용자가 검색어를 입력하면 검색 결과는 2페이지만 있는데도 계속 10페이지를 요청했습니다.
준비생은 서버에 검색 결과가 없다고 생각했지만 실제 요청값을 확인하면서 검색 조건이 달라져도 페이지 상태가 초기화되지 않는 사실을 발견했습니다. 검색어와 정렬 기준, 페이지 번호가 서로 어떤 영향을 주는지 정리하지 않은 것이 원인이었습니다.
검색어나 분류 조건이 바뀌면 페이지를 처음으로 이동하도록 수정했습니다. 사용자가 이전 화면으로 돌아왔을 때는 기존 조건을 복원할 수 있도록 주소와 상태의 관계도 정리했습니다. 검색 결과 없음과 잘못된 페이지, API 실패 상황도 구분했습니다.
- 처음에는 검색과 정렬, 페이지 이동 기능을 각각 구현했다고 설명했습니다. 개별 기능은 작동했지만 조건이 함께 바뀌는 상황은 확인하지 않았습니다.
- 보완 후에는 검색어와 정렬, 페이지 상태의 관계를 정리했습니다. 사용자의 행동 순서에 따라 요청값이 어떻게 달라지는지도 기록했습니다.
- 수정 후에는 첫 검색과 조건 변경, 마지막 페이지, 결과 없음, 뒤로 가기 상황을 다시 점검했습니다. 화면 상태를 다루는 기초가 실제 사용자 흐름과 연결됐습니다.
- 오류를 직접 만들어 봐야 개념이 경험으로 바뀝니다
정상적으로 작동하는 기능만 확인하면 배운 개념의 범위를 알기 어렵습니다. 입력값이 비어 있거나 권한이 없는 사용자가 요청하는 상황, 서버 응답이 지연되거나 데이터 저장이 실패하는 상황을 만들어 봐야 합니다.
오류가 발생하면 바로 검색하기 전에 메시지와 로그, 요청값을 먼저 읽는 습관이 필요합니다. 어느 단계까지 정상적으로 처리됐고 어디에서 예상과 달라졌는지를 기록하면 원인을 좁히기 쉽습니다.
기초를 충분히 공부한 뒤 실습하는 것이 아니라 개념과 실습을 반복해야 합니다. 기능에서 설명하지 못한 부분을 발견하면 관련 개념으로 돌아가 학습하고 다시 코드에서 확인합니다. 이 과정이 쌓이면 강의 수강 기록이 면접에서 설명할 수 있는 기술경험으로 바뀝니다.
포트폴리오는 완성 결과보다 문제를 해결한 근거를 보여줘야 합니다
- 프로젝트 개수가 많아도 개인의 판단이 없으면 약해 보입니다
비전공자는 전공 부족을 보완하려고 여러 프로젝트를 포트폴리오에 넣기도 합니다. 게시판과 쇼핑몰, 일정 관리 서비스가 차례로 나오지만 사용 기술과 기능 목록이 비슷하게 반복되면 각 결과물에서 성장한 내용이 보이지 않습니다.
채용 담당자가 확인하려는 것은 프로젝트 수만이 아닙니다. 지원자가 어떤 역할을 맡았고 구현 중 발생한 문제를 어떻게 발견했으며, 해결 방법을 선택한 이유와 수정 후 결과가 무엇인지 살펴봅니다.
- 팀 프로젝트에서는 서비스 전체의 기능과 자신의 담당 범위를 구분해야 합니다. 직접 작성한 코드와 팀원이 제공한 기능, 함께 결정한 기준을 나누면 개인의 기여도가 더 정확하게 나타납니다.
- 대표 프로젝트는 목표 직무와 가장 가까운 결과물을 선택해야 합니다. 화면 개발 지원자는 사용자 흐름과 상태 처리를, 서버 개발 지원자는 요청과 데이터 처리, 인증과 예외 대응을 앞에 배치하는 것이 좋습니다.
- 사용 기술에는 적용 위치와 이유를 함께 적어야 합니다. 기술 이름과 로고만 보여주기보다 어떤 문제를 해결하는 데 사용했는지 설명해야 합니다.
- 파일 접근 권한을 수정한 팀 프로젝트 사례
팀 프로젝트에서 게시글 첨부파일 기능을 담당한 지원자는 로그인한 사용자라면 모든 파일을 내려받을 수 있도록 구현했습니다. 정상적인 게시글에서는 문제가 없었지만 주소에 다른 파일의 식별값을 입력하면 자신이 볼 수 없는 비공개 게시글의 파일도 받을 수 있었습니다.
처음에는 화면에 비공개 게시글이 표시되지 않으므로 안전하다고 생각했습니다. 그러나 API 요청을 직접 보내면서 화면에 링크가 보이지 않는 것과 서버에서 접근을 막는 것은 다른 문제라는 점을 확인했습니다.
지원자는 파일을 조회할 때 로그인 여부만 확인하지 않고 파일이 연결된 게시글의 공개 상태와 작성자, 참여 권한을 함께 검사하도록 수정했습니다. 공개 파일과 비공개 파일, 작성자와 일반 사용자, 로그인하지 않은 사용자의 요청을 나누어 테스트했습니다.
- 결과 중심 설명: 게시글의 파일 업로드와 다운로드 기능을 구현했습니다.
- 역할이 보이는 설명: 파일 저장과 다운로드 API를 담당하고 게시글 상태에 따라 접근 권한을 처리했습니다.
- 문제해결이 담긴 설명: 주소에 다른 파일 식별값을 넣으면 비공개 게시글의 파일도 내려받을 수 있는 문제를 발견했습니다. 파일과 게시글의 관계, 사용자 권한을 서버에서 다시 확인하고 공개 상태와 사용자 유형별 요청을 테스트했습니다.
단순한 파일 기능이 인증과 권한을 구분하고 접근 범위를 검증한 백엔드 경험으로 바뀌었습니다. README에는 문제 발생 조건과 수정 전후 요청 결과, 아직 검토해야 할 파일명 중복과 저장 용량 문제도 함께 정리했습니다.
- 포트폴리오에는 수정 전후의 차이가 보여야 합니다
오류를 해결했다는 문장만으로는 어떤 문제가 있었고 지원자가 무엇을 판단했는지 알기 어렵습니다. 발생 조건과 기대 결과, 실제 결과, 확인한 정보, 적용한 수정, 재검증 결과를 남겨야 합니다.
스크린숏과 코드 전체를 많이 넣는 것보다 핵심 흐름을 짧게 정리하는 것이 좋습니다. 화면 문제라면 사용자 행동과 상태 변화를 보여주고, 서버 문제라면 요청과 로그, 데이터 상태의 변화를 설명합니다.
- 수정 전에는 어떤 조건에서 문제가 나타났는지 적습니다. 항상 발생한 것인지 특정 사용자나 입력, 요청 순서에서만 발생한 것인지 구분해야 합니다.
- 해결 과정에서는 처음 예상한 원인과 실제 원인이 달랐다면 그 차이를 포함합니다. 잘못된 추측도 확인 과정이 분명하면 문제해결 방식을 보여주는 근거가 됩니다.
- 수정 후에는 정상 기능뿐 아니라 오류가 발생했던 조건과 인접 기능을 다시 검증합니다. 변경으로 인해 다른 문제가 생기지 않았는지도 확인해야 합니다.
- README의 기록은 면접 답변으로 연결해야 합니다
포트폴리오를 제출한 뒤 기술면접을 별도의 공부로 생각하면 예상 질문의 정의만 외우게 될 수 있습니다. 면접관은 README에 작성된 기술과 문제를 기준으로 선택 이유와 검증 방법을 추가로 질문할 수 있습니다.
프로젝트 경험은 상황과 자신의 역할, 발견한 문제, 확인 과정, 선택한 해결 방법, 결과, 남은 한계로 나누어 정리할 수 있습니다. 이 구조를 이용하면 기술 질문과 문제해결, 협업 질문에 같은 경험을 다르게 활용할 수 있습니다.
기술 질문에서는 개념의 정의와 프로젝트에서 사용한 이유를 연결합니다. 문제해결 질문에서는 원인을 좁힌 과정과 수정 후 검증을 강조합니다. 협업 질문에서는 팀원과 서로 다르게 이해한 기준을 어떻게 조정했는지 설명할 수 있습니다.
기능을 구현했다는 결과만 남기지 않고 판단과 검증을 기록하면 포트폴리오와 면접준비가 자연스럽게 연결됩니다.
- 완벽한 결과물을 기다리지 말고 현재 경험부터 정리해야 합니다
포트폴리오를 완성한 뒤 지원하겠다고 생각하면 제출 시점이 계속 늦어질 수 있습니다. 새로운 기능과 기술을 추가하기 전에 현재 프로젝트에서 지원 직무와 관련된 근거가 충분한지 확인해야 합니다.
대표 기능 하나라도 입력과 처리 흐름, 오류 대응, 재검증 결과가 있다면 먼저 정리할 수 있습니다. 채용공고와 비교해 부족한 경험을 찾고 지원 과정에서 받은 질문을 다음 프로젝트에 반영하는 방식이 현실적입니다.
비전공자라는 이유로 모든 기술을 갖춘 뒤 지원하려 하지 않아야 합니다. 현재 학습 수준에서 직접 구현하고 설명할 수 있는 범위를 명확하게 보여주고, 부족한 부분은 다음 보완 계획으로 연결해야 합니다.
- conclusion
비전공자 개발자 취업은 전공과목을 모두 따라잡은 뒤 시작하는 과정이 아닙니다. 프런트엔드와 백엔드 중 자신이 해결하고 싶은 문제를 기준으로 방향을 좁히고, 필요한 기초를 작은 기능에 적용하며, 그 과정에서 발견한 문제를 포트폴리오로 남겨야 합니다.
현재 자신의 준비 상태는 다음 내용을 중심으로 점검할 수 있습니다.
- 방향설정에서는 취업 가능성이나 유행하는 기술보다 반복해서 다룰 업무를 비교해야 합니다. 사용자 화면과 상태 변화를 개선하는 일이 맞는지, 요청과 데이터 처리 및 권한을 설계하는 과정이 맞는지 작은 실습으로 확인해야 합니다.
- 기초학습은 강의 진도율보다 배운 개념을 코드로 설명할 수 있는지를 기준으로 삼아야 합니다. 정상 기능뿐 아니라 잘못된 입력과 권한 부족, 요청 실패를 직접 만들어 보고 로그와 데이터로 원인을 추적해야 합니다.
- 포트폴리오에는 기능 목록과 사용 기술만 적지 말고 개인 역할과 오류 발생 조건, 선택한 해결 방법, 수정 후 검증 결과를 포함해야 합니다. README에 남긴 경험은 기술면접과 협업 질문의 답변으로 이어져야 합니다.
실제 자료를 검토하면 강의를 많이 들었지만 회원가입 요청이 어떻게 저장되는지 설명하지 못하거나 화면을 완성했지만 API 실패를 처리하지 않은 경우가 있습니다. 부족한 것은 전공보다 공부와 구현, 설명이 연결된 경험입니다.
기능 하나라도 입력과 처리, 오류, 재검증까지 직접 확인하면 기초학습이 기술경험으로 바뀝니다. 문제를 해결한 기록은 포트폴리오의 근거가 되고 면접에서는 선택과 판단을 설명하는 답변이 됩니다. 비전공자에게 필요한 것은 전공자처럼 보이기 위한 과장이 아니라 자신이 이해하고 구현하고 확인한 범위를 구체적으로 보여주는 준비입니다.
