이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
아키텍처를 처음부터 설계할 때 가장 먼저 한 것은 도메인 개념을 코드 구조에 반영하는 것이었습니다. 기능 단위가 아닌 비즈니스 경계를 기준으로 모듈을 나누면 나중에 서비스를 분리하거나 기능을 추가할 때 영향 범위가 좁아졌습니다.
컴포넌트 간 의존 방향도 초기에 명확히 했습니다. 순환 의존이 생기면 변경이 한쪽에서 다른 쪽으로 전파되기 때문에, 의존 방향을 단방향으로 강제하는 규칙을 설계 초기에 정했습니다. 규칙을 어기는 코드는 리뷰 단계에서 차단했습니다.
확장성 검토는 지금 필요한 것과 6개월 뒤 필요할 것을 구분해 접근했습니다. 먼 미래를 위한 과도한 설계보다 당장 명확한 확장 방향만 반영하고, 나머지는 그때 판단하는 방식이 더 실용적이었습니다.
졸업 프로젝트에서 백엔드 서버를 하나의 애플리케이션으로 먼저 빠르게 만들었는데, 기능이 늘어나면서 배포할 때마다 전체를 다시 올려야 하는 문제가 생겼습니다. 인증·알림·조회 기능이 하나의 코드베이스에 섞여 있어서 알림 기능 하나를 수정해도 인증 관련 테스트 전체를 다시 돌려야 했습니다. 결국 기능별로 세 개의 서비스로 나눴는데, 이미 의존 관계가 뒤엉켜 분리하는 데 일주일이 걸렸습니다. 처음부터 변경 빈도가 다른 기능을 의식해서 경계를 잡았다면 훨씬 쉬웠을 거라는 걸 돌아봤습니다. 지금은 제로베이스 설계를 할 때 변경 빈도와 배포 단위를 먼저 그려보는 편입니다.
팀 프로젝트에서 처음 기술 스택을 선정할 때 저는 최신 프레임워크를 쓰고 싶었는데, 팀원 중 절반이 그 기술을 써본 적이 없었습니다. 고민 끝에 온보딩 비용을 선택 기준 중 하나로 넣기로 했습니다. 팀 전체가 빠르게 기여할 수 있어야 개발 속도가 나온다는 판단이었습니다. 결국 팀원 대부분이 아는 기술로 코어를 짜되, 익숙한 코드베이스 안에서 새 기술을 작은 모듈 하나에 실험적으로 도입했습니다. 이 방식 덕분에 2주 만에 팀 전원이 코드 리뷰에 참여할 수 있었습니다.
설계 기준에 기술 역량과 팀 속도를 함께 넣는 것이 실제 프로젝트에서 얼마나 중요한지 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.