이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 폼 입력 컴포넌트를 공통 라이브러리로 만들었는데, 처음 설계에서 너무 많은 것을 담으려다가 쓰는 곳마다 props가 복잡해지는 문제가 생겼습니다. 재사용성을 높이려고 옵션을 많이 뒀더니, 어느 팀원도 쉽게 못 쓰는 컴포넌트가 됐습니다. 그 이후 방향을 바꿔 "현재 사용 사례 3개를 커버하는 최소 인터페이스"를 먼저 정의했습니다. 확장성은 처음부터 구현하는 것보다 나중에 추가하기 쉬운 구조를 만드는 방향으로 접근했습니다. 슬롯 패턴을 활용해 기본 동작은 컴포넌트가 처리하되, 커스텀이 필요하면 외부에서 주입할 수 있게 했습니다. 균형을 맞추는 기준은 "이 인터페이스를 처음 보는 팀원이 15분 안에 쓸 수 있는가"였습니다. 복잡성이 이 기준을 초과하면 쪼개거나 단순화했습니다. 이 과정에서 재사용성과 확장성은 처음부터 모두 잡으려 하면 둘 다 잃는다는 걸 배웠습니다.
팀 내 디자인 시스템을 처음 구축할 때, 재사용성과 확장성을 동시에 잡으려다 둘 다 놓친 경험이 있습니다. 버튼 컴포넌트에 variant·size·icon·loading 등 열 개 이상의 props를 몰아넣었는데, 실제 사용 케이스의 80%는 두 가지만 필요했습니다. 이후 API 표면을 의도적으로 좁히는 방향으로 전환했습니다. 현재 사용 중인 케이스 세 가지만 지원하고, 나머지는 slot이나 render prop으로 외부에서 주입하게 열어뒀습니다. 확장성은 처음부터 구현하는 것보다 "나중에 추가하기 쉬운 구조"를 만드는 것을 목표로 삼았습니다. 내부 구현은 변경에 닫혀 있게 하되, 외부에서 동작을 주입하는 경로는 열어두는 방식이었습니다. 균형의 판단 기준은 "기본 케이스를 코드 3줄 이내로 쓸 수 있는가"였고, 이 기준을 넘기 시작하면 인터페이스를 쪼갰습니다. 그 결과 팀원이 컴포넌트를 가져다 쓰는 시간이 줄었고, PR에서 인터페이스 관련 리뷰 코멘트도 눈에 띄게 줄었습니다.
인턴 때 사내 공통 유틸 라이브러리에 기능을 추가하다가 하위 호환성을 깨뜨린 적이 있습니다. 재사용성을 높이려고 함수 시그니처를 변경했는데, 이미 열두 군데에서 쓰이고 있던 함수라 수정 범위가 예상보다 훨씬 컸습니다. 그 경험에서 "나중에 확장할 수 있는 구조"와 "지금 당장 쓰기 편한 구조" 사이의 긴장을 처음 실감했습니다. 이후 공통 함수를 설계할 때는 YAGNI 원칙을 기준으로 삼았습니다.
현재 사용 사례만 지원하는 최소 인터페이스를 먼저 만들고, 확장이 필요한 시점에 옵셔널 파라미터로 추가하는 방식을 택했습니다. 재사용성은 "얼마나 많은 곳에 쓰이는가"보다 "얼마나 쉽게 가져다 쓸 수 있는가"로 판단했습니다. 확장성은 변경 가능성이 높은 부분만 추상화하고, 나머지는 단순하게 유지했습니다.
인터페이스를 좁게 유지하는 것이 오히려 더 오래 살아남는 설계라는 걸 그 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.