우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›넛지헬스케어›백엔드›질문 상세
    問
    넛넛지헬스케어백엔드직무 역량2026년 출제

    express와 nest.js를 이용해 REST API를 개발한 경험이 있나요? 그 과정에서 어떤 어려움을 겪었고 어떻게 해결했는지 설명해 주세요.

    답변 미리보기

    팀 프로젝트에서 Express로 REST API 서버를 처음 만들고, 이후 NestJS로 구조를 바꾸는 경험을 했습니다. Express에서는 자유도가 높아서…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    어려움 결을 구체화하는가?
    막연한 결로 답하는지, 어떤 라우팅·검증·예외·성능 결에서 막혔는지 가른 흔적이 답에 있는지 보는 자리입니다. 막연한 결은 깊이가 약해지는 자리입니다.
    骨
    02
    본인 행동이 있는가?
    팀 결로만 답하는지, 본인이 무엇을 가르고 무엇을 굴린 결인지 답에 묻어 있는지 살피는 자리입니다. 본인 결 없는 답은 흐려지는 자리입니다.
    語
    03
    원인을 좇는가?
    증상 결만 답하는지, 로그·테스트·도구 결로 원인을 가른 흔적이 답에 있는지 살피는 자리입니다. 원인 없는 결은 표면적입니다.
    本
    04
    재발 방지를 의식하는가?
    한 번 해결만 답하는지, 테스트·표준·자동화 결로 가른 예방이 답에 있는지 보는 자리입니다. 일회성 결은 자리가 흐려지는 자리입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    넛지헬스케어 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    Express 자유도 → NestJS 구조 전환 + DTO 입력 검증 + 공통 예외 필터 + DB 쿼리 최적화 경험약 70초NestJS DTO 검증 누락으로 DB 오류·ValidationPipe 도입으로 입력 경계 강화 결약 82초에러 응답 파편화 경험·전역 ExceptionFilter로 형식 통일·재발 방지 결약 83초
    Express/NestJS REST API 개발 경험과 어려움
    약 70초

    Express 자유도 → NestJS 구조 전환 + DTO 입력 검증 + 공통 예외 필터 + DB 쿼리 최적화 경험

    팀 프로젝트에서 Express로 REST API 서버를 처음 만들고, 이후 NestJS로 구조를 바꾸는 경험을 했습니다. Express에서는 자유도가 높아서 빠르게 시작할 수 있었는데, 프로젝트가 커지면서 라우팅 구조가 일관성 없이 흩어지는 문제가 생겼습니다. NestJS로 전환하면서 컨트롤러·서비스·모듈 구조가 강제되어 팀원들이 코드를 어디서 찾을지 바로 알 수 있게 됐습니다. 입력 검증에서는 class-validator와 DTO를 활용해서 요청이 잘못된 형식일 때 컨트롤러 로직에 닿기 전에 걸러내는 구조를 만들었습니다. 예외 처리는 공통 필터를 만들어서 에러 응답 형식이 일관되도록 했는데, 그 전에는 에러마다 응답 구조가 달라 클라이언트가 혼란스러워하는 문제가 있었습니다. 성능 측면에서는 응답 속도가 느린 API를 찾아서 DB 쿼리 수를 줄이는 방식을 경험했습니다.

    Express와 NestJS 모두 강점이 있지만, 팀 규모가 커질수록 구조를 강제하는 쪽이 유지보수 비용을 줄이는 경험을 했습니다.

    이 결의 특징
    팀 프로젝트에서 Express로 REST API 서버를 처음 만들고, 이후 NestJS로 구조를 바꾸는 경험을 했습니다. Express에서는 자유도가 높아서 빠르게 시작할 수 있었는데, 프로젝트가 커지면서 라우팅 구조가 일관성 없이 흩어지는 문제가 생겼습니다라는 흔적이 있습니다
    이 결이 통하는 자리
    입력 검증에서는 `class-validator`와 DTO를 활용해서 요청이 잘못된 형식일 때 컨트롤러 로직에 닿기 전에 걸러내는 구조를 만들었습니다. 예외 처리는 공통 필터를 만들어서 에러 응답 형식이 일관되도록 했는데, 그 전에는 에러마다 응는 자리에서 통합니다
    예시 답변 2
    약 82초

    NestJS DTO 검증 누락으로 DB 오류·ValidationPipe 도입으로 입력 경계 강화 결

    NestJS로 전환하면서 DTO 없이 바디를 그대로 DB에 넣다가 형식 오류로 저장 실패가 나는 경험을 했습니다. Express에서는 수동으로 검증하거나 그냥 넘기던 습관이 남아 있었는데, NestJS는 DTO 기반 검증이 되어 있지 않으면 유효하지 않은 데이터가 그대로 들어오는 구조였습니다.

    ValidationPipe와 class-validator를 붙이고 DTO에 `@IsString`, `@IsNotEmpty` 같은 데코레이터를 선언하니 요청 단계에서 잘못된 형식이 걸러지기 시작했습니다. DB까지 닿기 전에 오류가 잡히니 원인 파악이 훨씬 빨라졌습니다.

    이 경험으로 NestJS에서 DTO와 ValidationPipe는 선택이 아니라 입력 경계의 첫 번째 방어선이라는 걸 배웠습니다. 검증이 앞에 있어야 뒤에서 디버깅할 일이 줄었습니다.

    이 결의 특징
    NestJS로 전환하면서 DTO 없이 바디를 그대로 DB에 넣다가 형식 오류로 저장 실패가 나는 경험을 했습니다. Express에서는 수동으로 검증하거나 그냥 넘기던 습관이 남아 있었는데, NestJS는 DTO 기반 검증이 되어 있지 않으면 유효하지 않은 데이터가 그대로 들어오는 구조였습니다라는 흔적이 있습니다
    이 결이 통하는 자리
    Express에서는 수동으로 검증하거나 그냥 넘기던 습관이 남아 있었는데, NestJS는 DTO 기반 검증이 되어 있지 않으면 유효하지 않은 데이터가 그대로 들어오는 구조였습니다. DB까지 닿기 전에 오류가 잡히니 원인 파악이 훨씬 빨라졌습니다. 이 경험으로 NestJS에서 DTO와 Validation는 자리에서 통합니다
    예시 답변 3
    약 83초

    에러 응답 파편화 경험·전역 ExceptionFilter로 형식 통일·재발 방지 결

    Express로 개발할 때 에러 처리를 라우터마다 다르게 짜다 보니 에러 응답 형식이 파편화된 경험이 있습니다. A 라우터는 {error: "message"}, B 라우터는 {message: "..."} 형식으로 내려가고 있었습니다. 클라이언트 개발자가 에러 처리를 매번 다르게 해야 하는 문제가 생겼습니다.

    NestJS로 전환하면서 전역 `ExceptionFilter`를 하나 만들어 모든 예외를 통일된 형식으로 내려보내는 구조를 잡았습니다. { statusCode, message, timestamp } 형식을 고정하니 클라이언트 쪽에서 에러 처리 코드를 단일 로직으로 통일할 수 있었습니다.

    이 경험으로 예외 처리의 일관성은 서버만의 문제가 아니라 클라이언트 개발 경험에도 직접 영향을 준다는 걸 배웠습니다. 표준 하나가 양쪽의 작업을 줄였습니다.

    이 결의 특징
    Express로 개발할 때 에러 처리를 라우터마다 다르게 짜다 보니 에러 응답 형식이 파편화된 경험이 있습니다. A 라우터는 `{error: "message"}`, B 라우터는 `{message: ". "}` 형식으로 내려가고 있었습니다라는 흔적이 있습니다
    이 결이 통하는 자리
    클라이언트 개발자가 에러 처리를 매번 다르게 해야 하는 문제가 생겼습니다. `{ statusCode, message, timestamp }` 형식을 고정하니 클라이언트 쪽에서 에러 처리 코드를 단일 로직으로 통일할 수 있었습니다. 이 경험으로 예외는 자리에서 통합니다
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹왜 그 해결 결을 고르셨나요?
    貳안 통한 시도 경로 결도 있었나요?
    參본인만의 API 결이 있나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 넛지헬스케어 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    넛지헬스케어 · 풀스택
    express나 nest.js를 사용하여 REST API 또는 GraphQL 서버를 개발한 경험에 대해 이야기해 주세요.
    이 질문 보기
    네이버 · 프론트엔드
    NestJS 또는 Node.js 서버 프레임워크를 사용한 경험이 있다면, 어떤 기능을 구현했는지 구체적으로 말씀해 주실 수 있나요?
    이 질문 보기
    세나클소프트 · 백엔드
    RESTful API 개발 경험이 있다면, 어떤 방식으로 설계하고 구현했는지 설명해 주세요.
    이 질문 보기
    배달의민족(우아한형제들) · 데이터·AI 일반
    FastAPI를 사용하여 API 서비스를 개발했던 경험에 대해 구체적으로 설명해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 넛지헬스케어 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기