신입 개발자 채용을 준비한 한 지원자의 포트폴리오를 검토한 적이 있습니다. 자바와 스프링, 리액트, 데이터베이스, 클라우드까지 여러 기술을 사용했고 팀 프로젝트에서 쇼핑몰 서비스도 완성했습니다. 기술스택만 보면 준비가 충분해 보였지만 회원가입 요청이 어느 단계에서 검증되고 데이터베이스에 저장되는지 질문하자 컨트롤러와 서비스라는 단어만 반복했습니다. 팀 협업 경험도 매일 회의하고 맡은 기능을 완성했다는 설명에서 끝났고, 주문이 두 번 저장됐던 오류를 어떻게 해결했는지는 검색해서 수정했다고 답했습니다. README에는 완성 화면과 기능 목록만 있었으며 코드 리뷰에서 받은 피드백과 수정 후 검증 결과는 남아 있지 않았습니다.
이 사례에서 부족했던 것은 새로운 기술이 아니었습니다. 배운 개념을 코드의 흐름과 연결하는 기본기, 오류 원인을 근거로 좁히는 문제해결 과정, 팀원과 서로 다른 기준을 조정한 협업 경험이 보이지 않았습니다. 신입에게 모든 실무 기술을 완벽하게 기대하기는 어렵지만 현재 아는 범위를 정확하게 설명하고 피드백을 다음 행동으로 바꾸는 모습은 확인할 수 있습니다. 따라서 신입 개발자 채용에서는 기술 이름을 많이 나열하는 것보다 기본 흐름을 이해하고, 프로젝트의 문제를 직접 다루며, 경험을 통해 달라진 행동을 보여주는 준비가 중요합니다.
기본기는 개념을 실제 코드 흐름으로 설명할 때 드러납니다
- 문법을 아는 것과 기능의 처리 과정을 이해하는 것은 다릅니다
신입 개발자가 프로그래밍 언어의 문법을 공부하고 프레임워크를 사용하는 것은 필요합니다. 하지만 채용 과정에서는 특정 문법을 외웠는지만 보는 것이 아니라 코드가 어떤 순서로 실행되고 데이터가 어디에서 들어와 어디로 이동하는지를 설명할 수 있는지 확인합니다.
백엔드라면 화면에서 전달된 요청이 검증과 업무 로직을 거쳐 데이터베이스에 저장되는 흐름을 이해해야 합니다. 프런트엔드라면 사용자의 입력이 상태에 반영되고 API 응답에 따라 화면이 어떻게 달라지는지 알아야 합니다. 기술면접에서 자료구조와 네트워크, 데이터베이스를 묻는 이유도 프로젝트의 문제를 이해하는 기본 토대를 확인하기 위해서입니다.
- 언어 기초는 문법 문제를 푸는 데서 끝나지 않습니다. 조건과 반복, 함수와 객체를 이용해 실제 기능을 구성하고 코드의 실행 순서를 자신의 말로 설명할 수 있어야 합니다.
- HTTP와 네트워크 기초는 용어 암기보다 요청 주소와 방식, 상태 코드, 오류 응답을 프로젝트에서 확인하는 방식으로 학습하는 것이 좋습니다.
- 데이터베이스는 조회문 작성뿐 아니라 테이블의 관계와 제약조건, 트랜잭션을 이해해야 합니다. 잘못된 값과 중복된 데이터가 저장되지 않도록 어느 단계에서 확인할지도 고민해야 합니다.
- Git은 코드를 올리는 용도로만 사용하지 않아야 합니다. 기능 추가와 오류 수정의 변경 이력을 남기고 어느 변경 이후 문제가 발생했는지 추적하는 데 활용할 수 있습니다.
- 중복 이메일이 저장된 회원가입 사례
백엔드를 준비한 지원자는 회원가입 요청을 받으면 이메일 중복 여부를 조회한 뒤 사용자 정보를 저장하도록 구현했습니다. 한 명씩 가입할 때는 정상적으로 동작했지만 비슷한 시각에 같은 이메일로 요청을 보내면 두 요청이 모두 중복되지 않았다고 판단하고 저장을 시도하는 문제가 발생했습니다.
처음에는 저장 전에 중복 조회를 했으므로 충분하다고 생각했습니다. 그러나 조회와 저장 사이에 다른 요청이 들어올 수 있다는 점을 고려하지 않았습니다. 애플리케이션에서 확인하는 로직만으로 데이터의 최종 상태를 보장하기 어려웠습니다.
지원자는 동시에 가입 요청을 보내는 테스트를 만들고 요청 시각과 조회 및 저장 로그를 비교했습니다. 데이터베이스에도 이메일 중복을 막는 제약조건을 추가하고, 저장 과정에서 중복이 확인되면 사용자가 이해할 수 있는 오류 응답으로 변환했습니다. 정상 가입과 순차적인 중복 요청, 동시 요청을 나누어 다시 검증했습니다.
- 기능 중심 설명: 이메일 중복 확인이 포함된 회원가입 기능을 구현했습니다.
- 처리 과정이 보이는 설명: 회원가입 요청을 검증하고 이메일 중복 조회와 비밀번호 처리, 데이터 저장을 담당했습니다.
- 기본기와 판단이 담긴 설명: 저장 전 중복 조회만으로는 동시에 들어오는 요청을 막기 어렵다는 문제를 확인했습니다. 데이터베이스 제약조건을 함께 적용하고 동시 가입 요청에서 하나의 데이터만 저장되는지 테스트했습니다.
이 사례에는 데이터베이스 제약조건과 동시 요청, 오류 처리에 대한 이해가 연결되어 있습니다. 어려운 기술 이름을 추가하지 않아도 하나의 기능을 끝까지 확인한 과정에서 기본기를 보여줄 수 있습니다.
- 이전 검색 결과가 화면을 덮어쓴 사례
프런트엔드를 준비한 지원자는 사용자가 검색어를 입력하면 상품 목록을 보여주는 기능을 만들었습니다. 정상적으로 한 번 검색할 때는 문제가 없었지만 검색어를 빠르게 바꾸면 이전 요청의 결과가 뒤늦게 도착해 현재 입력값과 다른 상품이 표시됐습니다.
처음에는 네트워크가 느려서 발생하는 현상이므로 해결하기 어렵다고 판단했습니다. 하지만 검색어가 바뀔 때 발생한 요청과 응답 시간을 기록하면서 먼저 보낸 요청이 나중에 도착해 현재 상태를 덮어쓰는 것이 원인임을 확인했습니다.
연속 입력에서 요청 횟수를 조절하고 현재 검색 조건과 일치하는 결과만 화면에 반영하도록 수정했습니다. 로딩 중인 상태와 결과 없음, 요청 실패도 구분했습니다. 빠른 입력과 느린 응답, 검색 결과가 없는 상황을 나누어 다시 테스트했습니다.
- 결과 중심 설명: 상품 검색 화면과 API 연동 기능을 구현했습니다.
- 상태 처리가 보이는 설명: 검색어에 따라 API를 호출하고 로딩과 결과 없음, 오류 상태를 구분했습니다.
- 원인 추적이 담긴 설명: 이전 요청이 나중에 도착해 현재 검색 결과를 덮어쓰는 문제를 발견했습니다. 요청과 응답 순서를 확인하고 현재 조건과 일치하는 결과만 반영한 뒤 연속 입력과 응답 지연 상황을 다시 검증했습니다.
프런트엔드 기본기는 화면을 만드는 기술만으로 설명되지 않습니다. 사용자 행동과 비동기 요청, 상태 변화의 관계를 이해하고 예외 상황을 처리하는 경험이 필요합니다.
- CS 지식은 프로젝트에서 필요했던 장면과 연결해야 합니다
기술면접을 준비할 때 운영체제와 네트워크, 데이터베이스의 정의를 암기하기 쉽습니다. 첫 질문에는 답할 수 있지만 프로젝트에서 어디에 적용했는지 질문받으면 설명이 짧아질 수 있습니다.
트랜잭션을 공부했다면 주문 저장과 재고 감소 중 하나가 실패할 때 어떤 문제가 생기는지 확인할 수 있습니다. 인덱스는 조회 속도를 높인다는 정의에서 끝내지 않고 어떤 조건으로 자주 조회했으며 데이터가 늘어날 때 실행 결과가 어떻게 달라졌는지 살펴볼 수 있습니다.
네트워크 지식은 API 요청이 실패했을 때 주소와 포트, 상태 코드, 서버 로그를 확인하는 경험으로 연결할 수 있습니다. 자료구조는 많은 데이터를 저장하고 탐색할 때 어떤 형태를 선택했는지 설명하는 근거가 됩니다.
기본기를 많이 안다는 것은 모든 정의를 외웠다는 의미가 아닙니다. 프로젝트에서 만난 문제를 개념으로 이해하고 코드와 테스트로 확인할 수 있는 상태에 가깝습니다.
협업과 문제해결은 팀에서 기준을 조정한 행동으로 확인합니다
- 협업을 많이 했다는 표현만으로는 개인의 역할이 보이지 않습니다
팀 프로젝트에서 회의를 자주 했고 서로 도우며 서비스를 완성했다는 설명은 협업 분위기를 알려줄 수 있습니다. 그러나 지원자가 어떤 문제를 발견했고 팀원과 무엇을 조정했는지는 확인하기 어렵습니다.
협업 경험에는 서로 다르게 이해한 요구사항과 코드 충돌, API 응답 형식, 일정 변경처럼 구체적인 장면이 필요합니다. 자신의 의견만 관철한 결과보다 팀의 목표와 기술 조건을 확인하고 공통 기준을 만든 과정이 중요합니다.
- 팀 전체가 만든 결과와 자신의 담당 범위를 구분해야 합니다. 직접 구현한 기능과 팀원에게 제공받은 부분, 함께 결정한 기준을 나누면 개인 기여도가 더 정확하게 나타납니다.
- 의견이 달랐을 때는 상대를 설득했다는 결론보다 어떤 자료와 테스트를 기준으로 판단했는지 설명해야 합니다.
- 협업 결과는 회의 횟수가 아니라 변경된 코드와 문서, 테스트 방식에서 찾아야 합니다. API 문서와 코드 리뷰 기준, 일정 조정처럼 팀의 행동이 달라진 근거가 필요합니다.
- 오류 응답 형식을 조정한 팀 프로젝트 사례
팀 프로젝트에서 백엔드는 데이터가 없거나 인증이 실패했을 때 서로 다른 형태의 오류 응답을 반환했습니다. 프런트엔드에서는 모든 실패를 같은 방식으로 처리해 사용자에게 요청에 실패했다는 한 문장만 보여주었습니다.
백엔드 담당자는 화면에서 메시지를 구분하면 된다고 생각했고, 화면 담당자는 응답 형식이 일정하지 않아 처리하기 어렵다고 판단했습니다. 처음에는 서로의 코드가 문제라고 생각했지만 실제 응답을 모아 비교하면서 공통 기준이 없다는 사실을 확인했습니다.
팀은 데이터 없음과 인증 실패, 권한 부족, 서버 오류를 구분하고 공통된 응답 구조를 정했습니다. 백엔드는 상태 코드와 내부 오류 식별값, 메시지를 일관되게 반환했고, 프런트엔드는 각 상황에 맞는 안내와 이동 경로를 연결했습니다. 실패 응답 예시는 API 문서에 추가하고 양쪽 담당자가 함께 테스트했습니다.
- 협업 사실만 담긴 설명: 프런트엔드 담당자와 API를 연동하며 원활하게 소통했습니다.
- 문제 상황이 포함된 설명: 오류 응답이 일정하지 않아 화면에서 실패 원인을 구분하지 못하는 문제를 발견했습니다.
- 조정 과정이 담긴 설명: 실제 응답을 비교해 데이터 없음과 인증 실패, 권한 부족을 구분하고 공통 오류 형식을 제안했습니다. API 문서를 수정한 뒤 담당자와 각 실패 상황을 함께 검증했습니다.
협업 능력은 갈등이 없었다는 사실보다 서로 다르게 이해한 기준을 발견하고 결과물로 조정한 과정에서 나타납니다.
- 주문 알림이 두 번 전송된 문제해결 사례
백엔드 팀 프로젝트에서 주문이 완료되면 사용자에게 알림을 보내는 기능을 추가했습니다. 정상 주문에서는 문제가 없었지만 결제 응답이 늦어져 같은 완료 요청이 반복되면 알림이 두 번 전송되는 현상이 발생했습니다.
처음에는 알림 서비스 자체의 오류라고 생각했습니다. 요청 로그와 주문 상태 변경 기록, 알림 전송 시각을 비교해 보니 동일한 주문 완료 처리가 반복될 때마다 전송 기능이 실행되고 있었습니다.
팀은 이미 완료된 주문에 같은 상태 변경 요청이 들어오면 다시 처리하지 않도록 기준을 정했습니다. 알림 전송 여부도 기록해 같은 주문에서 반복 실행되지 않도록 수정했습니다. 정상 완료와 반복 요청, 결제 실패 후 재시도, 알림 전송 실패 상황을 나누어 테스트했습니다.
- 결과 중심 설명: 주문 완료 알림이 중복 전송되는 오류를 수정했습니다.
- 원인 확인이 보이는 설명: 요청 로그와 주문 상태, 알림 시각을 비교해 동일한 완료 처리가 반복되는 조건을 찾았습니다.
- 재발 방지가 담긴 설명: 이미 완료된 주문에는 같은 상태 변경을 적용하지 않고 알림 전송 여부를 확인하도록 수정했습니다. 반복 요청과 결제 재시도, 전송 실패 상황을 나누어 다시 검증했습니다.
문제해결은 오류를 없앤 결과만으로 판단하기 어렵습니다. 재현 조건과 확인한 근거, 수정 방법, 재검증 결과가 연결되어야 지원자의 접근 방식을 볼 수 있습니다.
- Git 충돌에서 기능이 사라진 사례
두 명의 팀원이 같은 회원정보 수정 화면을 작업하면서 한 명은 화면 배치를 변경했고 다른 한 명은 입력 검증을 추가했습니다. 두 작업을 합치는 과정에서 충돌이 발생하자 나중에 작성된 코드를 그대로 선택했고 입력 검증 기능이 사라졌습니다.
팀은 어느 코드가 최신인지보다 두 변경이 해결하려던 목적을 먼저 확인했습니다. 화면 변경과 입력 검증을 함께 반영하고 정상 입력과 빈 값, 잘못된 이메일 형식을 다시 테스트했습니다.
이후에는 기능별 브랜치에서 작업하고 변경 목적과 테스트 결과를 풀 리퀘스트에 작성했습니다. 충돌이 발생하면 파일의 최종 모양만 보지 않고 각 수정의 의도를 확인하기로 했습니다.
- 기존 협업 방식은 코드를 빠르게 합치는 데 집중했습니다. 충돌한 두 작업의 요구사항을 확인하지 않아 정상 기능이 사라졌습니다.
- 개선 후에는 변경 목적과 영향을 검토한 뒤 코드를 합쳤습니다. 기능별 테스트 결과도 공유해 다른 팀원이 확인할 수 있게 했습니다.
- 이 경험은 Git을 사용했다는 기술 목록보다 충돌을 통해 협업 기준을 수정한 구체적인 근거가 됐습니다.
- 도움을 요청하는 방식도 협업 능력에 포함됩니다
신입은 모든 문제를 혼자 해결하기 어렵습니다. 중요한 것은 막히는 즉시 답을 달라고 요청하거나 오랫동안 혼자 붙잡고 있는 것이 아니라 현재까지 확인한 내용을 정리해 도움을 구하는 것입니다.
오류 메시지와 발생 조건, 예상한 원인, 이미 시도한 방법, 확인이 필요한 부분을 함께 전달하면 팀원도 문제를 이해하기 쉽습니다. 답을 받은 뒤에는 해결 방법을 적용하고 결과를 확인하며 같은 문제가 반복되지 않도록 기록해야 합니다.
모르는 것을 숨기지 않되 아무것도 확인하지 않은 채 질문하지 않는 태도가 필요합니다. 도움을 받은 경험도 어떤 정보를 준비했고 이후 무엇을 이해했는지 설명하면 학습과 협업의 근거가 될 수 있습니다.
성장가능성은 피드백 이후 달라진 행동으로 보여줘야 합니다
- 열심히 배우겠다는 다짐만으로는 변화를 확인하기 어렵습니다
신입 지원자는 실무 경험이 부족하기 때문에 성장가능성을 강조합니다. 빠르게 배우고 회사와 함께 성장하겠다는 표현은 의지를 보여주지만 다른 지원자도 쉽게 사용할 수 있습니다.
성장가능성은 이전에 부족했던 부분을 어떻게 발견했고 어떤 방법으로 보완했으며 이후 행동이 어떻게 달라졌는지에서 나타납니다. 같은 피드백을 반복해서 받지 않기 위해 기준과 습관을 바꾼 경험이 필요합니다.
- 코드 리뷰에서 받은 의견을 해당 코드만 수정하고 끝내지 않아야 합니다. 비슷한 문제가 다른 기능에도 있는지 확인하고 다음 작업에서 적용할 기준을 정하는 것이 좋습니다.
- 기술면접에서 답하지 못한 질문은 정의만 외우지 말고 자신의 프로젝트에서 관련된 장면을 찾아 다시 구현하거나 테스트해야 합니다.
- 프로젝트 실패를 새로운 기술을 몰랐다는 결론으로 끝내지 말고 요구사항 이해와 테스트 부족, 기록 누락처럼 행동 단위로 원인을 나누어야 합니다.
학습 결과는 강의 수료보다 코드와 문서, 테스트의 변화로 보여주는 것이 좋습니다.
- 코드 리뷰 피드백을 검증 습관으로 바꾼 사례
프런트엔드 지원자는 회원가입 화면에서 이메일과 비밀번호 입력값을 각각 처리했습니다. 기능은 정상적으로 작동했지만 비슷한 검증 코드가 여러 위치에 반복되어 수정할 때 일부 화면만 변경되는 문제가 있었습니다.
코드 리뷰에서 중복된 검증 기준을 한 곳에서 관리하는 편이 좋다는 피드백을 받았습니다. 처음에는 해당 회원가입 화면만 정리했지만 다른 프로젝트의 로그인과 회원정보 수정 화면에도 비슷한 문제가 있다는 사실을 발견했습니다.
공통으로 사용하는 검증 규칙과 화면별로 다른 안내를 구분했습니다. 회원가입과 로그인, 정보 수정 화면의 정상 입력과 잘못된 입력을 다시 테스트했습니다. 이후 새로운 입력 화면을 만들 때는 먼저 공통 규칙과 화면별 상태를 나누어 설계했습니다.
- 피드백 중심 설명: 코드 리뷰를 받고 중복된 입력 검증 코드를 수정했습니다.
- 변화가 보이는 설명: 회원가입 화면의 피드백을 다른 입력 화면에도 적용해 검증 기준을 공통으로 정리했습니다.
- 성장가능성이 담긴 설명: 같은 검증 규칙이 여러 화면에 반복돼 일부만 수정되는 문제를 확인했습니다. 공통 규칙과 화면별 안내를 구분하고 관련 화면을 다시 테스트한 뒤 새 기능에서도 같은 기준을 먼저 적용했습니다.
피드백을 한 번 반영한 결과보다 이후 작업 방식이 달라진 점이 성장 근거가 됩니다.
- 기술면접 탈락을 프로젝트 보완으로 연결한 사례
백엔드 지원자는 기술면접에서 인덱스의 개념을 설명했지만 자신의 프로젝트에서 어디에 사용할 수 있는지는 답하지 못했습니다. 면접 후 알고리즘과 데이터베이스 강의를 처음부터 다시 들어야 한다고 생각했습니다.
답변을 복기하면서 정의를 몰랐던 것이 아니라 실제 조회 기능과 연결하지 못했다는 점을 확인했습니다. 주문 내역에서 사용자와 주문 상태, 기간을 조건으로 자주 조회하는 기능을 선택해 데이터가 늘어날 때의 실행 결과를 비교했습니다.
무조건 인덱스를 추가하지 않고 어떤 조건과 정렬이 반복되는지 확인했습니다. 적용 전후의 조회 방식과 결과를 기록하고 데이터가 적을 때는 차이를 판단하기 어렵다는 한계도 정리했습니다.
- 처음에는 인덱스가 조회 속도를 높인다는 정의만 외웠습니다. 프로젝트에서 어떤 조회가 반복되는지와 적용 기준은 설명하지 못했습니다.
- 보완 후에는 주문 내역 조회 조건을 기준으로 검토하고 적용 전후의 실행 결과를 비교했습니다.
- 다음 면접에서는 정의와 함께 프로젝트에서 검토한 위치, 확인한 결과, 작은 데이터 환경의 한계를 구분해 답변할 수 있게 됐습니다.
탈락 경험을 공부량 부족으로만 해석하지 않고 답변과 프로젝트 사이의 연결 부족으로 진단한 사례입니다.
- 모르는 범위를 정확하게 말하는 것도 성장의 출발점입니다
신입은 모든 기술을 실무 수준으로 경험하기 어렵습니다. 면접에서 모르는 질문을 받았을 때 무리하게 정답을 추측하면 후속 질문에서 설명이 흔들릴 수 있습니다.
관련된 개념 중 알고 있는 범위를 먼저 말하고 직접 적용한 경험이 없는 부분은 구분해야 합니다. 이후 어떤 문서와 로그, 테스트를 이용해 확인할 것인지 접근 순서를 설명할 수 있습니다.
프로젝트에서도 구현하지 않은 기능을 경험한 것처럼 표현하지 않아야 합니다. 현재 확인한 범위와 남아 있는 한계를 명확히 적고 다시 진행한다면 무엇을 개선할지 제시하는 편이 신뢰도를 높입니다.
성장가능성은 완성된 사람처럼 보이는 데서 만들어지지 않습니다. 자신의 부족한 부분을 정확하게 인식하고 이를 구체적인 행동으로 바꿀 수 있다는 근거에서 나타납니다.
- 지원 자료에 변화의 흐름을 남겨야 합니다
포트폴리오에는 최종 결과물뿐 아니라 대표적인 개선 과정을 포함하는 것이 좋습니다. 처음 구현한 방식과 발견한 문제, 받은 피드백, 수정 후 검증, 이후 적용한 기준을 연결하면 지원자의 학습 방식을 확인할 수 있습니다.
README에 모든 시행착오를 길게 적을 필요는 없습니다. 목표 직무와 관련된 문제 중 자신의 판단과 변화가 잘 드러나는 사례를 선택해야 합니다. 관련 커밋과 테스트 기록이 있다면 설명의 신뢰성도 높아집니다.
면접에서는 성장했다는 결론부터 말하기보다 이전 행동과 현재 행동의 차이를 보여주는 것이 좋습니다. 같은 유형의 문제가 다시 발생했을 때 무엇을 다르게 했는지를 설명하면 성장가능성이 구체적으로 전달됩니다.
- conclusion
신입 개발자 채용에서는 많은 기술을 아는 사람만 확인하는 것이 아닙니다. 배운 개념을 실제 기능에 적용하고 코드의 흐름을 설명할 수 있는지, 오류가 생겼을 때 근거를 이용해 원인을 좁히는지, 팀과 기준을 조정하며 피드백을 다음 행동으로 바꿀 수 있는지를 함께 살펴봅니다.
현재 자신의 준비 상태는 다음 내용을 중심으로 점검할 수 있습니다.
- 기본기는 정의를 많이 암기했는지가 아니라 요청과 응답, 데이터 저장, 상태 변화가 프로젝트에서 어떻게 연결되는지 설명할 수 있는지를 기준으로 확인해야 합니다. 정상 기능뿐 아니라 잘못된 입력과 권한 부족, 중복 요청도 직접 테스트해야 합니다.
- 협업과 문제해결 경험에는 회의를 많이 했다는 표현보다 서로 다르게 이해한 기준과 발생한 오류, 확인한 자료, 합의한 방법, 재검증 결과가 있어야 합니다. 팀 전체 성과와 자신의 역할도 명확하게 구분해야 합니다.
- 성장가능성은 빠르게 배우겠다는 다짐보다 피드백 전후의 행동 변화로 보여줘야 합니다. 하나의 코드 리뷰와 면접 질문을 다른 기능과 학습에 확장하고 같은 문제가 반복되지 않도록 기준을 만든 경험이 필요합니다.
실제 자료를 검토하면 기술스택은 많지만 회원가입 요청이 어디에서 검증되고 저장되는지 설명하지 못하거나 협업 경험을 원활하게 소통했다는 말로 끝내는 경우가 있습니다. 새로운 기술을 추가하기 전에 현재 프로젝트에서 자신의 판단과 검증이 보이는지 점검해야 합니다.
코드의 흐름을 이해한 경험은 기본기의 근거가 되고, 팀에서 문제를 조정한 기록은 협업 역량으로 이어집니다. 피드백을 다음 프로젝트에 적용한 변화는 면접에서 성장가능성을 보여주는 답변이 됩니다. 신입에게 필요한 것은 완성된 실무자처럼 보이는 과장이 아니라 현재 아는 범위를 정확하게 설명하고 계속 개선할 수 있다는 구체적인 근거입니다.
