이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
처음 Node.js로 서버를 만들 때 라우터 파일 하나에 DB 쿼리부터 응답 생성까지 다 넣었습니다. 기능이 늘면서 파일 하나가 300줄이 넘어가고, 어디를 수정해야 할지 찾는 데 더 오래 걸렸습니다.
두 번째 프로젝트부터는 라우터, 서비스, 레포지토리 세 레이어를 분리하는 구조로 바꿨습니다. 라우터는 요청을 받고, 서비스에 비즈니스 로직이 있으며, 레포지토리에서 DB를 다루는 방식이었습니다. 처음에는 파일이 많아져서 복잡해 보였지만, 기능을 추가하거나 수정할 때 어디를 봐야 하는지 명확해졌습니다.
이 구조를 선호하는 이유는 어디서 무엇을 책임지는지가 명확해서 팀으로 작업할 때 충돌이 줄어든다는 점입니다. 각 레이어가 독립적이어서 테스트도 쉬워졌습니다. 그 경험이 구조를 먼저 고민하고 코드를 쓰는 습관을 만들어주었습니다.
Node.js 입문 강의를 들으면서 처음엔 모든 코드를 한 파일에 쓰다가 유지보수가 어렵다는 걸 느꼈어요. 강의에서 MVC 패턴을 배우고 나서 직접 프로젝트에 적용해봤습니다.
모델·뷰·컨트롤러를 분리했는데, 모델에서 데이터 형태를 정의하고 컨트롤러가 요청을 처리하는 흐름이 처음엔 과하게 느껴졌어요. 기능이 하나인데 파일이 세 개가 생기는 거니까요. 그런데 기능이 5개가 넘어가면서 구조 없이 짰을 때보다 훨씬 관리가 쉽다는 걸 느꼈습니다.
소규모 프로젝트에는 과한 구조일 수 있지만, 팀이 함께 작업하거나 기능이 계속 추가되는 상황에서는 구조가 없는 것보다 명확히 낫다는 것을 직접 비교해봤어요. 처음부터 구조를 잡는 투자가 나중에 수정 시간을 줄여준다는 걸 배웠습니다. 그 경험이 Node.js 아키텍처를 의식적으로 선택하게 해줬어요.
팀 프로젝트에서 프론트엔드와 백엔드가 동시에 개발하다가 API 응답 형태가 달라서 통합할 때 이틀을 날린 경험이 있어요.
그 이후로는 개발 전에 API 명세를 먼저 문서로 정의하고 합의한 뒤 구현을 시작하는 방식으로 바꿨어요. Node.js 라우팅도 URL 구조와 요청·응답 형태를 먼저 잡아두고, 그 안의 로직을 채워 나가는 순서였습니다. 처음엔 설계하는 시간이 아깝게 느껴졌는데, 실제로 통합 충돌이 없어지니 전체 시간이 줄었어요.
아키텍처 선택보다 팀원과 어떻게 인터페이스를 맞출지가 더 중요하다는 걸 그때 배웠어요. 좋은 설계가 혼자 개발할 때보다 함께 개발할 때 더 빛난다는 것도요. 그 경험이 설계를 협업 도구로 보는 시각을 만들어줬어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.