이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
풀스택 솔루션을 개발할 때 가장 먼저 고려하는 것은 프론트엔드와 백엔드의 책임 경계입니다. 어디서 어떤 로직을 처리할지 명확하지 않으면 같은 로직이 양쪽에 중복되거나, 한쪽이 너무 비대해지는 문제가 생깁니다. 팀 프로젝트에서 유효성 검사를 프론트에서만 하다가 악의적인 요청을 백엔드가 걸러내지 못하는 문제를 경험했고, 이후 백엔드에서도 검증하는 구조로 수정했습니다.
상태 관리도 풀스택에서 복잡한 부분인데, 서버 상태와 클라이언트 상태를 어디에 두느냐에 따라 캐시 무효화 방식이 달라집니다. 인증 흐름도 설계 초기에 결정해야 할 요소인데, 세션 기반과 토큰 기반의 선택이 이후 모바일 지원 여부나 스케일 전략에 영향을 줍니다. 한계는 아직 대규모 풀스택 서비스를 처음부터 설계해본 경험이 없다는 점입니다. 풀스택 솔루션은 기술 선택보다 경계와 흐름을 먼저 설계하는 것이 나중의 수정 비용을 줄이는 결임을 배웠습니다.
풀스택 솔루션을 고려할 때 개발 초기에는 프론트·백 선택에 집중하는 경향이 있었는데, 한 프로젝트를 배포하고 운영해보면서 운영 스택도 처음부터 고려해야 한다는 것을 배웠습니다.
로컬에서 잘 돌아가던 서비스가 배포 환경에서 환경변수 누락이나 포트 충돌로 동작하지 않는 일이 생겼고, 이때 로그가 없어서 원인을 찾는 데 오래 걸렸습니다. 이후로는 배포 환경에서 기본 로그 수집과 헬스체크 엔드포인트를 처음부터 넣는 것을 원칙으로 삼았습니다.
기술 스택 선택보다 중요한 것은 팀이 그 스택의 운영 방식을 이해하고 있느냐는 점입니다. Docker로 컨테이너화하면 환경 일관성이 높아지지만, 컨테이너 내부에서 문제가 생겼을 때 디버깅 방법을 모르면 오히려 더 막힌다는 것을 경험했습니다. 기술 스택은 팀이 배우고 운영할 수 있는 범위 안에서 결정하는 것이 실제 서비스에서 더 안전한 선택이라는 생각이 남아 있습니다.
풀스택 기술 스택을 고를 때 가장 후회한 선택이 ORM 결정이었습니다. 초기에 SQL을 직접 쓰기 불편하다는 이유로 ORM을 넣었는데, 쿼리가 복잡해지면서 ORM이 생성하는 SQL이 의도와 달리 N+1 쿼리를 내보내는 상황이 됐습니다.
원인을 파악하기 위해 ORM이 실제로 어떤 SQL을 실행하는지 로그를 찍어보는 설정을 추가했는데, 그때서야 ORM을 쓴다고 DB 최적화를 고민하지 않아도 되는 게 아니라는 것을 체감했습니다.
지금은 기술 스택을 고를 때 그 기술이 내부에서 무엇을 하는지 최소한 한 단계는 들여다볼 수 있는지를 함께 고려합니다. 편리한 추상화 계층이 실제로 어떻게 동작하는지 이해하지 못하면 문제가 생겼을 때 막히는 자리가 더 깊어진다는 것이 이 경험에서 남은 결입니다. 풀스택 솔루션에서 기술 선택은 개발 속도만큼 디버깅 가시성도 기준으로 삼아야 한다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.