면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
팀 프로젝트에서 Vue 기반 관리자 도구의 초기 폴더 구조를 설계한 적이 있습니다. 저는 기능이 늘어나도 파일을 찾기 쉽도록 도메인 단위로 폴더를 나누고, 공통 UI 컴포넌트는 별도 디렉터리로 분리했습니다. 처음에는 팀원들이 굳이 이렇게까지 나눠야 하냐는 반응이었지만, 개발 중반에 팀원이 추가로 합류했을 때 이 구조 덕분에 온보딩 시간이 하루 만에 끝났다는 피드백을 받았습니다. 설계 초기에 들인 시간이 이후 협업 속도를 결정한다는 것을 이 경험으로 배웠습니다.
백엔드 프로젝트에서 Java로 계층을 나누는 설계를 해본 경험이 있었는데, 이후 Vue 프로젝트에서도 비슷한 원칙을 적용했습니다. 화면 로직과 API 호출 로직을 분리하고, 상태 관리를 별도 모듈로 두어 컴포넌트가 화면 표현에만 집중하도록 설계했습니다. 이 구조 덕분에 API 응답 형식이 세 차례 바뀌는 동안에도 컴포넌트 코드는 거의 수정할 필요가 없었고, 수정 시간도 평소보다 절반 이하로 줄었습니다. 언어는 달라도 관심사를 분리한다는 설계 원칙은 동일하게 적용된다는 것을 확인했습니다.
소규모로 시작한 Vue 프로젝트가 기능이 늘어나며 컴포넌트마다 상태를 따로 관리해 데이터가 어긋나는 문제가 생겼습니다. 화면을 넘나들 때마다 값이 초기화되는 버그가 반복되자 저는 전역 상태 관리 도구를 도입하기로 했습니다. 다만 모든 상태를 한곳에 몰아넣지 않고 화면 단위 상태와 전역 상태를 명확히 구분하는 기준을 세워 팀 규칙으로 문서화했습니다. 이 기준을 공유한 뒤로는 상태 불일치 버그 발생 건수가 한 달 새 절반 이하로 줄었습니다. 설계는 지금 편한 방법이 아니라 나중에 덜 고생하는 방법을 고르는 일이라는 것을 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.