IT 커리어 정보207 데이터베이스 기초(개념 이해, 정보 관리, 서비스 구조) 백엔드 개발자를 준비한 한 지원자의 쇼핑몰 프로젝트를 검토한 적이 있습니다. 포트폴리오에는 자바와 스프링, 관계형 데이터베이스를 사용해 회원가입과 상품 주문 기능을 구현했다고 적혀 있었습니다. 하지만 테이블 구조를 살펴보니 주문이 생성될 때마다 회원 이름과 이메일, 주소가 같은 형태로 반복 저장되고 있었습니다. 회원이 주소를 변경하면 이전 주문의 배송지까지 모두 바뀌어야 하는지, 주문 당시 정보를 유지해야 하는지도 정해져 있지 않았습니다. 이메일 중복은 저장 전에 조회하는 코드만 있었고 동시에 같은 이메일로 요청하면 두 건이 저장될 가능성도 있었습니다. 데이터베이스를 사용했다는 결과는 있었지만 정보를 어떤 기준으로 나누고 관계를 만들었는지는 설명하지 못했습니다.이 사례에서 부족했던 것은 복잡한 SQL 문.. 2026. 4. 28. 서버와 클라이언트 관계(요청과 응답, 프런트엔드, 백엔드) 팀 프로젝트에서 게시글 저장 버튼을 눌러도 데이터가 등록되지 않는 문제를 함께 검토한 적이 있습니다. 프런트엔드 담당자는 서버가 응답하지 않는다고 생각했고, 백엔드 담당자는 화면에서 요청값을 잘못 보냈다고 판단했습니다. 두 사람 모두 자신의 코드만 확인하면서 상대 영역의 문제라고 생각했지만 브라우저의 네트워크 기록을 열어 실제 요청과 응답을 비교하지는 않았습니다. 요청 본문을 확인해 보니 화면에서는 게시글 제목을 title이라는 기준으로 보냈지만 서버에서는 다른 항목명을 기다리고 있었습니다. 서버는 필수값이 없다는 오류를 반환하고 있었지만 화면에서는 모든 실패를 같은 문구로 처리해 원인을 알기 어려웠습니다.이 사례에서 필요한 것은 화면 코드와 서버 코드 중 어느 쪽이 더 잘못됐는지를 따지는 일이 아니었습.. 2026. 4. 27. 개발자 포트폴리오(프로젝트 개요, 역할 분리, 문제 해결) 개발자 취업을 준비한 한 지원자의 포트폴리오를 검토한 적이 있습니다. 첫 번째 프로젝트는 약 세 페이지에 걸쳐 서비스 기획 배경과 시장조사, 전체 기능을 설명하고 있었습니다. 팀에서 만든 화면과 API도 모두 소개했지만 지원자가 직접 담당한 부분은 백엔드 개발이라는 한 문장뿐이었습니다. 회원가입과 게시글, 결제, 배포 중 어느 기능을 구현했는지 알기 어려웠고, 가장 힘들었던 문제를 물었을 때는 오류가 많았지만 팀원들과 검색해 해결했다고 답했습니다. 반면 사용 기술의 로고와 완성 화면은 많았어도 어떤 기술을 어디에 사용했고 수정 후 무엇을 검증했는지는 나타나지 않았습니다. 프로젝트 규모는 컸지만 개인의 실력을 판단할 근거가 부족한 상태였습니다.이 사례에서 필요한 것은 프로젝트를 새로 추가하는 일이 아니었습.. 2026. 4. 27. 신입개발자 채용기준(기본기, 협업과 문제해결, 성장가능성) 신입 개발자 채용을 준비한 한 지원자의 포트폴리오를 검토한 적이 있습니다. 자바와 스프링, 리액트, 데이터베이스, 클라우드까지 여러 기술을 사용했고 팀 프로젝트에서 쇼핑몰 서비스도 완성했습니다. 기술스택만 보면 준비가 충분해 보였지만 회원가입 요청이 어느 단계에서 검증되고 데이터베이스에 저장되는지 질문하자 컨트롤러와 서비스라는 단어만 반복했습니다. 팀 협업 경험도 매일 회의하고 맡은 기능을 완성했다는 설명에서 끝났고, 주문이 두 번 저장됐던 오류를 어떻게 해결했는지는 검색해서 수정했다고 답했습니다. README에는 완성 화면과 기능 목록만 있었으며 코드 리뷰에서 받은 피드백과 수정 후 검증 결과는 남아 있지 않았습니다.이 사례에서 부족했던 것은 새로운 기술이 아니었습니다. 배운 개념을 코드의 흐름과 연결.. 2026. 4. 27. 정보보안 직무 준비법(취약점분석, 보안적성, 책임감) 정보보안 취업을 준비한 한 지원자의 포트폴리오를 검토한 적이 있습니다. 웹 취약점 점검 도구로 발견한 결과와 네트워크 분석 화면, 로그인 실패 로그가 여러 장 포함되어 있어 실습을 많이 한 것처럼 보였습니다. 하지만 발견한 취약점이 실제 서비스에 어떤 영향을 줄 수 있는지, 여러 결과 중 무엇부터 조치해야 하는지 질문하자 모두 위험하다는 답변에서 멈췄습니다. 자동 점검 도구에서 높은 위험으로 표시된 항목을 다시 확인하지 않았고, 정상 사용자의 로그인 실수와 의심스러운 반복 접근도 실패 횟수만으로 판단했습니다. 포트폴리오에는 실습 대상의 주소와 계정 정보 일부가 그대로 남아 있어 민감정보를 관리하는 기준도 부족했습니다.이 사례에서 부족했던 것은 보안 도구의 개수가 아니었습니다. 취약점을 발견한 뒤 발생 조.. 2026. 4. 26. Git과 GitHub 차이(버전관리, 협업, 포트폴리오) 개발자 취업을 준비한 한 비전공자의 GitHub 저장소를 검토한 적이 있습니다. README에는 팀 프로젝트에서 회원가입과 게시판, 상품 주문 기능을 구현했다고 적혀 있었지만 커밋 기록은 프로젝트를 마친 날 한 번에 올라온 최종 프로젝트 하나였습니다. 팀원이 담당한 기능과 본인이 작성한 코드도 구분되어 있지 않았고, 오류를 수정하거나 테스트한 과정 역시 확인하기 어려웠습니다. Git과 GitHub의 차이를 물었을 때는 둘 다 코드를 저장하는 프로그램이라고 답했습니다. 프로젝트 폴더를 날짜별로 복사해 보관하다가 어떤 파일이 최신인지 혼동한 경험은 있었지만, Git을 이용해 변경 이력을 관리하거나 이전 상태로 돌아가 본 적은 없었습니다. GitHub도 취업할 때 코드를 올리는 사이트로만 이해하고 있었습니다... 2026. 4. 26. 이전 1 ··· 30 31 32 33 34 35 다음