개발자 면접에서 프로젝트 설명을 하다 보면 의외로 많은 지원자가 기능 설명까지는 잘하지만, 왜 그 기술을 사용했는지 묻는 순간 답변이 짧아집니다. 게시판을 만들었습니다, React를 사용했습니다, Spring Boot로 API를 구성했습니다, MySQL에 데이터를 저장했습니다까지는 말할 수 있지만, 왜 React였는지, 왜 Spring Boot였는지, 왜 이 구조로 나누었는지, 다른 방법과 비교해 본 적이 있는지 질문을 받으면 준비한 문장이 흔들리는 경우가 많습니다. 프로젝트를 만들었다는 사실은 있지만, 선택 과정이 정리되어 있지 않은 것입니다.
이 질문은 지원자를 곤란하게 만들기 위한 질문이 아닙니다. 면접관은 기술 이름을 외웠는지보다 프로젝트를 얼마나 이해하고 있는지, 선택에 어떤 판단근거가 있었는지, 실무에서 문제를 바라보는 사고방식이 있는지를 확인하려고 합니다. 신입 개발자에게 완벽한 아키텍처 판단을 기대하는 것은 아닙니다. 하지만 본인이 사용한 기술과 구조에 대해 최소한의 이유를 설명할 수 있어야 합니다. 이번 글에서는 개발자 면접에서 기술 선택 이유를 왜 묻는지, 그리고 이 질문이 프로젝트이해, 판단근거, 실무사고와 어떻게 연결되는지 정리해 보겠습니다.
개발자 면접에서 기술 선택 이유는 프로젝트이해를 확인하는 질문입니다
- 기능을 만들었다는 말만으로는 이해도가 보이지 않습니다
개발자 면접에서 프로젝트 질문이 나오면 많은 지원자가 구현한 기능을 중심으로 설명합니다. 회원가입 기능, 로그인 기능, 게시글 작성 기능, 검색 기능, API 연동 기능처럼 기능 목록을 나열하는 방식입니다. 기능 설명은 당연히 필요합니다. 하지만 기능을 만들었다는 말만으로는 프로젝트를 얼마나 이해하고 있는지 충분히 드러나지 않습니다. 같은 게시판 프로젝트라도 어떤 사람은 강의 예제를 따라 만든 수준일 수 있고, 어떤 사람은 요청과 응답, 데이터 저장, 예외 처리, 화면 흐름까지 이해하고 만들었을 수 있습니다.
기술 선택 이유를 묻는 질문은 이 차이를 확인하는 데 도움이 됩니다. 예를 들어 왜 이 프로젝트에 React를 사용했는지 묻는다면 단순히 많이 쓰이기 때문입니다라고 답하는 것보다, 화면에서 사용자 입력과 목록 상태가 자주 바뀌기 때문에 컴포넌트 단위로 UI를 나누고 상태 변화를 관리하기 위해 사용했습니다라고 답하는 편이 더 좋습니다. 이 답변에는 기술 이름뿐 아니라 프로젝트의 화면 구조와 데이터 흐름을 이해하고 있다는 근거가 들어 있습니다.
- 프로젝트 목적을 이해해야 기술 선택도 설명할 수 있습니다
기술 선택 이유를 설명하려면 먼저 프로젝트 목적을 알아야 합니다. 어떤 문제를 해결하려고 만든 프로젝트인지, 어떤 기능이 핵심인지, 사용자가 어떤 흐름으로 서비스를 이용하는지 정리되어 있어야 기술 선택도 자연스럽게 나옵니다. 목적이 불분명하면 기술 선택 답변도 추상적으로 흐르기 쉽습니다. 예를 들어 단순한 투두리스트 프로젝트라고 해도 목적에 따라 설명이 달라집니다. 상태관리와 렌더링 흐름을 이해하기 위한 프로젝트라면 React를 선택한 이유가 사용자 입력과 목록 상태 변화를 컴포넌트 단위로 확인하기 위해서가 될 수 있습니다. 백엔드 API와 데이터 저장 흐름을 연습하기 위한 프로젝트라면 Spring Boot와 MySQL을 선택한 이유가 REST API 구조와 관계형 데이터 저장 흐름을 이해하기 위해서가 될 수 있습니다. 같은 프로젝트처럼 보여도 목적이 다르면 기술 선택 이유도 달라집니다.
- 프로젝트이해는 기능 목록을 외우는 것이 아닙니다. 프로젝트가 어떤 목적을 가지고 있고, 사용자가 어떤 흐름으로 기능을 사용하며, 데이터가 어디에서 생성되고 어디에 저장되는지 설명할 수 있어야 합니다. 이 이해가 있어야 기술 선택 이유도 단순한 유행어가 아니라 프로젝트 맥락 안에서 설명됩니다.
- 면접에서 기술 선택 이유를 묻는 것은 이 기술을 완벽하게 알고 있는지 확인하려는 질문만은 아닙니다. 오히려 본인이 만든 프로젝트의 구조를 이해하고 있는지, 사용한 기술을 프로젝트 목적과 연결할 수 있는지 확인하는 질문에 가깝습니다. 신입이라도 이 정도의 연결은 준비해야 합니다.
- 실제 답변에서 프로젝트 이해도의 차이가 납니다
예를 들어 면접에서 왜 React를 사용했나요라는 질문을 받았다고 해보겠습니다. 약한 답변은 React가 많이 쓰여서 사용했습니다 정도로 끝나는 것입니다. 조금 더 나은 답변은 컴포넌트 기반으로 화면을 만들 수 있어서 사용했습니다입니다. 하지만 더 좋은 답변은 프로젝트에서 검색어 입력, 필터링 결과, 상세 화면 전환처럼 화면 상태가 자주 바뀌는 부분이 있었습니다. 그래서 화면을 컴포넌트 단위로 나누고 상태 변화를 관리하기 위해 React를 사용했습니다. 특히 검색어 입력값과 목록 렌더링을 분리하면서 상태관리 흐름을 이해하는 데 도움이 되었습니다라고 말하는 것입니다.
이 답변은 단순히 React의 장점을 말하는 것이 아닙니다. 프로젝트 안에서 React가 왜 필요했는지 설명하고 있습니다. 면접관 입장에서는 이 지원자가 기술을 이름으로만 알고 있는지, 실제 프로젝트 안에서 어떤 역할로 사용했는지 이해하고 있는지 구분할 수 있습니다. 개발자 면접에서 기술 선택 이유가 중요한 이유도 바로 여기에 있습니다.
- README에도 선택 이유가 보이면 신뢰도가 올라갑니다
기술 선택 이유는 면접에서만 필요한 것이 아닙니다. 포트폴리오 README에도 간단히 정리해 두면 좋습니다. 사용 기술 목록만 적는 것보다 각 기술을 왜 사용했는지 한두 문장으로 적어두면 프로젝트이해가 더 잘 드러납니다. 예를 들어 Spring Boot는 REST API 구조와 계층 분리를 연습하기 위해 사용했고, MySQL은 회원과 게시글 데이터를 관계형 구조로 저장하기 위해 사용했으며, GitHub Actions는 배포 자동화 흐름을 이해하기 위해 사용했다고 정리할 수 있습니다.
이렇게 적어두면 면접 준비도 쉬워집니다. README에 선택 이유가 정리되어 있으면 예상 질문을 만들 수 있고, 답변도 프로젝트 흐름에 맞게 준비할 수 있습니다. 반대로 README에는 기술 이름만 나열되어 있고 면접에서 이유를 묻는다면 즉석에서 답변을 만들어야 하기 때문에 말이 흔들릴 가능성이 큽니다. 기술 선택 이유는 프로젝트를 만든 뒤 마지막에 떠올리는 것이 아니라, 프로젝트를 진행하면서 계속 기록해 두는 것이 좋습니다.
기술을 고른 판단근거가 있어야 답변의 깊이가 달라집니다
- 판단근거 없이 선택하면 유행 기술 나열로 보입니다
개발 공부를 하다 보면 요즘 많이 쓰이는 기술을 먼저 따라가고 싶어 집니다. React, Next.js, Spring Boot, NestJS, Docker, AWS, PostgreSQL처럼 채용공고에서 자주 보이는 기술을 보면 모두 포트폴리오에 넣고 싶어질 수 있습니다. 하지만 기술을 많이 사용했다고 해서 무조건 좋은 프로젝트가 되는 것은 아닙니다. 오히려 왜 사용했는지 설명하지 못하면 유행 기술을 억지로 붙인 것처럼 보일 수 있습니다. 면접관이 기술 선택 이유를 묻는 이유는 이 기술을 선택한 판단근거가 있는지 확인하기 위해서입니다. 프로젝트 규모, 기능 요구사항, 학습 목표, 팀원 숙련도, 데이터 구조, 배포 환경, 유지보수 가능성 같은 요소를 고려했는지 보는 것입니다. 신입 개발자가 모든 요소를 깊게 판단하기는 어렵지만, 적어도 이 프로젝트에서 이 기술이 어떤 역할을 했는지는 설명해야 합니다.
- 좋은 판단근거는 비교에서 나옵니다
기술 선택 답변을 더 깊게 만들려면 비교가 필요합니다. 꼭 여러 기술을 모두 사용해봐야 한다는 뜻은 아닙니다. 최소한 내가 선택한 기술과 다른 선택지가 어떤 차이가 있는지 생각해 보는 것이 중요합니다. 예를 들어 프런트엔드에서 React를 선택했다면 단순 HTML, CSS, JavaScript만으로 구현할 때와 비교해 어떤 점이 달랐는지 말할 수 있어야 합니다. 백엔드에서 Spring Boot를 선택했다면 단순 Java 콘솔 프로그램이 아니라 웹 API 구조를 만들기 위해 어떤 점이 필요했는지 설명할 수 있어야 합니다.
판단근거는 정답을 맞히는 문제가 아닙니다. 면접관은 지원자가 실무자처럼 완벽한 기술 비교를 하기를 기대하지 않습니다. 대신 프로젝트 상황을 보고 나름의 기준을 세웠는지, 선택의 이유를 말할 수 있는지, 선택 후 생긴 장단점을 이해하고 있는지 확인합니다. 그래서 선택 이유는 장점만 말하는 것보다 한계까지 함께 말할 때 더 설득력 있게 보입니다.
- 판단근거는 기술의 유명함보다 프로젝트 요구사항에서 나와야 합니다. 예를 들어 상태 변화가 많은 화면이라 React를 사용했다, 관계형 데이터가 필요해 MySQL을 사용했다, API 요청과 응답 구조를 연습하기 위해 Spring Boot를 사용했다처럼 프로젝트 맥락이 들어가야 합니다. 많이 사용해서 선택했다는 답변은 출발점이 될 수는 있지만 충분한 근거가 되기는 어렵습니다.
- 기술 선택에는 장점뿐 아니라 한계도 포함됩니다. 예를 들어 Docker를 사용했다면 실행 환경을 통일할 수 있다는 장점이 있지만, 처음 설정 과정에서 Dockerfile과 포트 매핑을 이해하는 데 어려움이 있었다고 말할 수 있습니다. 이런 답변은 기술을 무조건 좋게만 보는 것이 아니라 실제 사용 경험을 바탕으로 이해하고 있다는 인상을 줍니다.
- 실제 답변에서 판단근거가 보이는 방식
예를 들어 면접에서 왜 MySQL을 사용했나요라는 질문을 받았다고 해보겠습니다. 약한 답변은 데이터베이스가 필요해서 사용했습니다 정도입니다. 조금 더 나은 답변은 회원 정보와 게시글을 저장하기 위해 사용했습니다입니다. 하지만 더 좋은 답변은 프로젝트에서 회원과 게시글, 댓글처럼 관계가 있는 데이터를 다뤄야 했기 때문에 관계형 데이터베이스를 사용했습니다. MySQL은 학습 자료가 많고 SQL로 데이터 조회 조건을 직접 확인하기 좋아서 선택했습니다. 다만 처음에는 테이블 관계와 외래키 설정이 익숙하지 않아 게시글과 댓글 관계를 다시 설계했고, 그 과정을 README에 정리했습니다라고 말하는 것입니다.
이 답변에는 선택 기준, 프로젝트 요구사항, 학습 이유, 어려웠던 점, 보완 과정이 들어 있습니다. 단순히 MySQL을 사용했습니다보다 훨씬 깊이가 있습니다. 판단근거가 있다는 것은 기술을 완벽하게 안다는 뜻이 아닙니다. 오히려 왜 선택했고, 사용하면서 무엇을 배웠고, 어떤 한계를 느꼈는지 설명할 수 있다는 뜻입니다.
- 판단근거는 프로젝트 회고에서 더 선명해집니다
기술 선택 이유는 프로젝트 시작 전에만 정리하는 것이 아닙니다. 프로젝트를 진행한 뒤 회고하면서 더 분명해질 수 있습니다. 처음에는 단순히 많이 쓰이는 기술이라 선택했더라도, 실제로 사용해 보면서 어떤 장점이 있었는지, 어떤 부분이 어려웠는지, 다음에는 어떤 기준으로 선택할 것인지 정리할 수 있습니다. 이 회고가 있으면 면접 답변이 훨씬 자연스러워집니다. 예를 들어 처음에는 React를 많이 사용한다고 해서 선택했지만, 프로젝트를 진행하면서 컴포넌트 분리와 상태관리의 필요성을 이해하게 되었다고 말할 수 있습니다. 처음에는 Spring Boot를 사용해보고 싶어서 선택했지만, 실제로는 컨트롤러, 서비스, 리포지토리 계층을 나누면서 백엔드 구조를 이해하는 데 도움이 되었다고 정리할 수 있습니다. 이렇게 답변하면 단순한 선택이 아니라 학습 과정이 드러납니다.
프로젝트 회고에는 기술 선택 이유, 사용하면서 좋았던 점, 어려웠던 점, 다음 프로젝트에서 바꾸고 싶은 점을 함께 적어두면 좋습니다. 이 내용은 포트폴리오에도 들어갈 수 있고, 면접에서 기술 선택 이유를 물었을 때 답변의 근거가 됩니다. 저는 이런 회고가 있는 프로젝트가 훨씬 신뢰가 보인다고 생각합니다.
기술 선택을 비교해 설명하는 과정이 실무사고로 이어집니다
- 실무에서는 기술 선택이 항상 조건과 연결됩니다
실무에서 기술을 선택할 때는 단순히 좋아 보여서 고르지 않습니다. 프로젝트 규모, 일정, 팀원의 숙련도, 유지보수 가능성, 성능 요구사항, 기존 시스템과의 연동, 배포 환경 등을 고려해야 합니다. 신입 개발자가 이 모든 요소를 완벽하게 판단할 수는 없습니다. 하지만 포트폴리오 프로젝트에서도 작은 기준을 세워보는 연습은 필요합니다. 이 연습이 실무사고의 시작이 됩니다.
면접에서 기술 선택 이유를 묻는 것은 지원자가 이런 사고방식을 조금이라도 가지고 있는지 확인하는 질문입니다. 예를 들어 작은 개인 프로젝트에 너무 많은 기술을 넣었다면 왜 그 기술들이 필요했는지 설명할 수 있어야 합니다. 반대로 간단한 기술만 사용했다면 프로젝트 목표에 맞게 의도적으로 단순하게 구성했다는 설명도 가능합니다. 중요한 것은 선택의 이유가 프로젝트 조건과 연결되어 있는지입니다.
- 실무사고는 장단점을 함께 보는 태도에서 나옵니다
기술을 선택할 때 장점만 보는 것은 초보 단계에서 자주 나타나는 모습입니다. React는 좋습니다, Spring Boot는 많이 씁니다, Docker는 실무에서 필요합니다처럼 말하면 틀린 말은 아니지만 답변이 얕아질 수 있습니다. 실무사고가 보이려면 장점과 함께 적용 조건, 한계, 보완 방법을 같이 말할 수 있어야 합니다.
예를 들어 Docker를 사용한 프로젝트라면 실행 환경을 통일하고 배포 연습을 하기 위해 사용했다고 말할 수 있습니다. 동시에 처음 설정 과정에서 이미지 빌드, 포트 매핑, 환경변수 관리가 어려웠고, 작은 프로젝트에서는 설정 비용이 더 크게 느껴졌다고 말할 수도 있습니다. 이런 답변은 기술을 무조건 좋게만 보지 않고, 상황에 따라 판단하려는 태도를 보여줍니다.
- 실무사고는 거창한 시스템 설계 경험에서만 나오는 것이 아닙니다. 작은 프로젝트에서도 왜 이 기술을 사용했는지, 다른 방법은 무엇이 있었는지, 사용하면서 어떤 한계가 있었는지 정리하면 실무적인 사고가 드러납니다. 신입 개발자에게 필요한 것은 완벽한 판단보다 기준을 세우려는 태도입니다.
- 기술 선택 답변에서는 사용한 기술을 자랑하기보다 프로젝트 조건과 연결하는 것이 중요합니다. 이 기술을 썼다는 말보다 이 프로젝트에서는 이런 기능과 구조가 필요했고, 그래서 이 기술을 선택했으며, 사용하면서 이런 점을 배웠다고 말해야 합니다. 이 흐름이 있으면 답변이 훨씬 실무적으로 들립니다.
- 실제 실무사고가 보이는 답변 예시
예를 들어 면접에서 왜 Docker를 사용했나요라는 질문을 받았다고 해보겠습니다. 약한 답변은 Docker가 실무에서 중요하다고 해서 사용했습니다 정도입니다. 조금 더 나은 답변은 실행 환경을 맞추기 위해 사용했습니다입니다. 하지만 더 좋은 답변은 팀 프로젝트에서 각자 로컬 환경이 달라 서버 실행 과정에서 문제가 반복되었습니다. 그래서 실행 환경을 통일하고, 의존성 설치 과정을 줄이기 위해 Docker를 적용했습니다. 처음에는 Dockerfile 작성과 포트 매핑에서 어려움이 있었지만, README에 실행 방법을 정리하면서 팀원이 같은 환경에서 실행할 수 있도록 개선했습니다라고 말하는 것입니다.
이 답변은 실무사고가 보입니다. 기술을 사용한 이유가 프로젝트 상황에서 나오고, 문제를 해결하기 위해 선택했으며, 사용 과정에서 생긴 어려움과 개선까지 설명하고 있습니다. 신입 개발자라도 이런 답변을 준비하면 단순히 기술 이름을 나열하는 지원자와 차이가 생깁니다.
- 기술 선택 이유는 다음 프로젝트의 기준이 됩니다
기술 선택 이유를 정리하는 습관은 한 번의 면접 답변을 위한 것이 아닙니다. 다음 프로젝트를 더 잘 설계하기 위한 기준이 됩니다. 처음 프로젝트에서는 단순히 많이 쓰이는 기술을 따라 사용할 수 있습니다. 하지만 사용 후 회고를 하면 다음에는 더 나은 선택을 할 수 있습니다. 어떤 기술은 프로젝트 규모에 비해 과했고, 어떤 기술은 유지보수에 도움이 되었고, 어떤 기술은 학습 목적에는 좋았지만 실제 기능에는 꼭 필요하지 않았다는 판단이 생깁니다.
이 과정이 쌓이면 포트폴리오의 수준도 달라집니다. 단순히 여러 기술을 사용한 프로젝트가 아니라, 기술 선택과 구조 설계에 대한 생각이 보이는 프로젝트가 됩니다. 면접에서도 이 프로젝트에서는 학습 목적상 이 기술을 사용했지만, 실제 서비스라면 이런 조건을 추가로 고려할 것 같습니다라고 말할 수 있습니다. 이런 답변은 신입 수준에서도 충분히 좋은 인상을 줄 수 있습니다.
개발자 면접에서 기술 선택 이유를 묻는 질문은 결국 지원자의 생각을 확인하는 질문입니다. 어떤 기술을 썼는지보다 왜 썼는지, 어떻게 사용했는지, 사용하면서 무엇을 배웠는지, 다음에는 무엇을 다르게 할 것인지가 중요합니다. 이 질문에 답할 수 있으면 프로젝트는 단순 결과물이 아니라 지원자의 사고 과정을 보여주는 자료가 됩니다.
- conclusion
개발자 면접에서 기술 선택 이유를 묻는 이유는 단순히 기술 이름을 확인하기 위해서가 아닙니다. 이 질문은 지원자가 프로젝트를 얼마나 이해하고 있는지, 선택에 어떤 판단근거가 있었는지, 실무 상황처럼 조건을 비교하고 설명할 수 있는지 확인하는 질문입니다. 신입 개발자에게 완벽한 기술 비교나 아키텍처 설계를 기대하는 것은 아니지만, 본인이 사용한 기술에 대해 최소한의 이유와 경험은 설명할 수 있어야 합니다. 지금 포트폴리오를 준비하고 있다면 각 프로젝트마다 사용 기술 목록 옆에 이유를 한두 문장씩 적어보는 것이 좋습니다. 왜 이 기술을 선택했는지, 어떤 기능에서 사용했는지, 사용하면서 어려웠던 점은 무엇인지, 다음 프로젝트에서는 무엇을 다르게 하고 싶은지 정리해야 합니다. 이 네 가지를 적어보면 면접 답변의 기본 틀이 만들어집니다.
제가 여러 개발자 면접 답변을 보면서 느낀 것은, 기술을 많이 사용한 사람보다 선택 이유를 설명할 수 있는 사람이 더 신뢰 있게 보인다는 점입니다. 단순히 React, Spring Boot, MySQL, Docker를 사용했다는 말은 누구나 할 수 있습니다. 하지만 이 프로젝트에서 왜 필요했고, 어떤 문제를 해결했으며, 사용하면서 무엇을 배웠는지 설명하는 사람은 프로젝트를 실제로 이해하고 있다는 인상을 줍니다. 기술 선택 이유는 포트폴리오를 더 깊게 만들고, 면접 답변을 더 구체적으로 만들며, 실무사고를 보여주는 중요한 연결점입니다. 프로젝트를 만들 때마다 기술을 사용한 이유를 기록해 보는 것이 좋습니다. 그 기록이 쌓이면 면접에서 기술 선택 이유를 묻는 질문은 부담스러운 질문이 아니라, 본인의 프로젝트 이해도와 판단력을 보여줄 수 있는 기회가 됩니다.
