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

    Node.js 기반 애플리케이션을 개발할 때, 어떤 아키텍처를 선호하고 그 이유는 무엇인가요?

    답변 미리보기

    처음 Node.js로 서버를 만들 때 라우터 파일 하나에 DB 쿼리부터 응답 생성까지 다 넣었습니다. 기능이 늘면서 파일 하나가 300줄이 넘어가고, 어디를…

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

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

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

    問
    01
    선호하는 아키텍처는 무엇인가?
    선호하는 아키텍처에 대한 구체적인 언급이 답에 있어야 합니다. 없으면 면접관이 '그 이유는 무엇인가?'를 추가로 묻는 경우가 자주 보입니다.
    骨
    02
    왜 그 아키텍처를 선택했는가?
    선택한 아키텍처의 장점이나 특징에 대한 설명이 필요합니다. 없으면 면접관이 '다른 선택지는 없었나요?'라고 질문할 가능성이 높습니다.
    語
    03
    경험 기반의 사례가 있는가?
    이전에 경험한 사례가 답에 포함된 흔적이 있어야 합니다. 없으면 면접관이 '어떤 프로젝트에서 사용했나요?'를 추가로 묻는 경우가 많습니다.
    本
    04
    그 아키텍처의 단점은 무엇인가?
    선택한 아키텍처의 단점에 대한 인식이 답에 있어야 합니다. 없으면 면접관이 '어떻게 극복했나요?'라는 질문을 던지는 자리가 자주 보입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    토스 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    라우터·서비스·레포지토리 레이어를 분리한 경험약 90초Express에서 MVC 패턴으로 프로젝트를 구성한 경험약 90초라우팅 설계를 먼저 정의하고 구현에 들어간 경험약 90초
    레이어드 아키텍처 경험
    약 90초

    라우터·서비스·레포지토리 레이어를 분리한 경험

    처음 Node.js로 서버를 만들 때 라우터 파일 하나에 DB 쿼리부터 응답 생성까지 다 넣었습니다. 기능이 늘면서 파일 하나가 300줄이 넘어가고, 어디를 수정해야 할지 찾는 데 더 오래 걸렸습니다.

    두 번째 프로젝트부터는 라우터, 서비스, 레포지토리 세 레이어를 분리하는 구조로 바꿨습니다. 라우터는 요청을 받고, 서비스에 비즈니스 로직이 있으며, 레포지토리에서 DB를 다루는 방식이었습니다. 처음에는 파일이 많아져서 복잡해 보였지만, 기능을 추가하거나 수정할 때 어디를 봐야 하는지 명확해졌습니다.

    이 구조를 선호하는 이유는 어디서 무엇을 책임지는지가 명확해서 팀으로 작업할 때 충돌이 줄어든다는 점입니다. 각 레이어가 독립적이어서 테스트도 쉬워졌습니다. 그 경험이 구조를 먼저 고민하고 코드를 쓰는 습관을 만들어주었습니다.

    이 결의 특징
    처음 Node.js로 서버를 만들 때 라우터 파일 하나에 DB 쿼리부터 응답 생성까지 다 넣었습니다. 기능이 늘면서 파일 하나가 300줄이 넘어가고, 어디를 수정해야 할지 찾는 데 더 오래 걸렸습니다. 두 번째 프로젝트부터는 라우터, 서비스, 레포지토리 세 레이어를 분리하는 구조로 바꿨습니다. 라우터는 요청을 받고, 서비스에 비즈니스 로직이 있으며, 레포지...
    이 결이 통하는 자리
    이 있으며, 레포지토리에서 DB를 다루는 방식이었습니다. 처음에는 파일이 많아져서 복잡해 보였지만, 기능을 추가하거나 수정할 때 어디를 봐야 하는지 명확해졌습니다. 이 구조를 선호하는 이유는 어디서 무엇을 책임지는지가 명확해서 팀으로 작업할 때 충돌이 줄어든다는 점입니다. 각 레이어가
    MVC 패턴 적용
    약 90초

    Express에서 MVC 패턴으로 프로젝트를 구성한 경험

    Node.js 입문 강의를 들으면서 처음엔 모든 코드를 한 파일에 쓰다가 유지보수가 어렵다는 걸 느꼈어요. 강의에서 MVC 패턴을 배우고 나서 직접 프로젝트에 적용해봤습니다.

    모델·뷰·컨트롤러를 분리했는데, 모델에서 데이터 형태를 정의하고 컨트롤러가 요청을 처리하는 흐름이 처음엔 과하게 느껴졌어요. 기능이 하나인데 파일이 세 개가 생기는 거니까요. 그런데 기능이 5개가 넘어가면서 구조 없이 짰을 때보다 훨씬 관리가 쉽다는 걸 느꼈습니다.

    소규모 프로젝트에는 과한 구조일 수 있지만, 팀이 함께 작업하거나 기능이 계속 추가되는 상황에서는 구조가 없는 것보다 명확히 낫다는 것을 직접 비교해봤어요. 처음부터 구조를 잡는 투자가 나중에 수정 시간을 줄여준다는 걸 배웠습니다. 그 경험이 Node.js 아키텍처를 의식적으로 선택하게 해줬어요.

    이 결의 특징
    Node.js 입문 강의를 들으면서 처음엔 모든 코드를 한 파일에 쓰다가 유지보수가 어렵다는 걸 느꼈어요. 강의에서 MVC 패턴을 배우고 나서 직접 프로젝트에 적용해봤습니다. 모델·뷰·컨트롤러를 분리했는데, 모델에서 데이터 형태를 정의하고 컨트롤러가 요청을 처리하는 흐름이 처음엔 과하게
    이 결이 통하는 자리
    데 파일이 세 개가 생기는 거니까요. 그런데 기능이 5개가 넘어가면서 구조 없이 짰을 때보다 훨씬 관리가 쉽다는 걸 느꼈습니다. 소규모 프로젝트에는 과한 구조일 수 있지만, 팀이 함께 작업하거나 기능이 계속 추가되는 상황에서는 구조가 없는 것보다 명확히 낫다는 것을 직접 비교해봤어요. 처음부터 구조를 잡는 투자가
    API 설계 우선
    약 90초

    라우팅 설계를 먼저 정의하고 구현에 들어간 경험

    팀 프로젝트에서 프론트엔드와 백엔드가 동시에 개발하다가 API 응답 형태가 달라서 통합할 때 이틀을 날린 경험이 있어요.

    그 이후로는 개발 전에 API 명세를 먼저 문서로 정의하고 합의한 뒤 구현을 시작하는 방식으로 바꿨어요. Node.js 라우팅도 URL 구조와 요청·응답 형태를 먼저 잡아두고, 그 안의 로직을 채워 나가는 순서였습니다. 처음엔 설계하는 시간이 아깝게 느껴졌는데, 실제로 통합 충돌이 없어지니 전체 시간이 줄었어요.

    아키텍처 선택보다 팀원과 어떻게 인터페이스를 맞출지가 더 중요하다는 걸 그때 배웠어요. 좋은 설계가 혼자 개발할 때보다 함께 개발할 때 더 빛난다는 것도요. 그 경험이 설계를 협업 도구로 보는 시각을 만들어줬어요.

    이 결의 특징
    팀 프로젝트에서 프론트엔드와 백엔드가 동시에 개발하다가 API 응답 형태가 달라서 통합할 때 이틀을 날린 경험이 있어요. 그 이후로는 개발 전에 API 명세를 먼저 문서로 정의하고 합의한 뒤 구현을 시작하는 방식으로 바꿨어요. Node.js 라우팅도 URL 구조와 요청·응답 형태를 먼저
    이 결이 통하는 자리
    처음엔 설계하는 시간이 아깝게 느껴졌는데, 실제로 통합 충돌이 없어지니 전체 시간이 줄었어요. 아키텍처 선택보다 팀원과 어떻게 인터페이스를 맞출지가 더 중요하다는 걸 그때 배웠어요. 좋은 설계가 혼자 개발할 때보다 함께 개발할 때 더 빛난다는 것도요. 그 경험이 설계를 협업 도구로 보
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

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

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

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

    壹다른 아키텍처를 고려하지 않으신 이유가 무엇인가요?
    貳지금 다시 개발한다면 다른 아키텍처를 선택하시겠어요?
    參이 아키텍처의 적용 과정에서 어려움은 없었나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 토스 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

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

    CJ올리브영 · 프론트엔드
    Node.js 기반의 애플리케이션 개발 시 어떤 점을 가장 중요하게 생각하시나요?
    이 질문 보기
    쿠팡 · 백엔드
    백엔드 시스템을 설계할 때 어떤 아키텍처를 선호하고 그 이유는 무엇인가요?
    이 질문 보기
    비즈테크아이 · 솔루션 아키텍트
    어플리케이션 아키텍처를 설계할 때 고려해야 할 주요 요소는 무엇인가요?
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 토스 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기