이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 내 유틸리티 라이브러리를 처음 만들 때 API 설계가 가장 어려운 지점이었습니다. 내부 구조에 맞춰 인터페이스를 짰더니 사용하는 쪽에서 옵션이 너무 많다는 피드백이 나왔고, 이후에는 외부 인터페이스를 먼저 그리고 내부를 채우는 방식으로 바꿨습니다. 번들 크기는 처음엔 간과했다가 호스팅 앱에서 2배 이상 증가했다는 리포트를 받고 나서야 트리 쉐이킹 구조로 전면 재작성했습니다. 타입스크립트 지원은 처음부터 하는 편이 낫다고 생각합니다. 나중에 .d.ts를 추가하다 보면 실제 동작과 타입 정의가 어긋나는 케이스가 어김없이 생겼습니다.
하위 호환을 유지하면서 기능을 확장하는 게 생각보다 까다롭다는 점도 이 과정에서 처음 체감했습니다.
내부 UI 컴포넌트 라이브러리를 만들 때 처음엔 구현부터 시작하다가 인터페이스를 나중에 맞추는 방식으로 진행했습니다. 그 결과 컴포넌트를 쓰는 쪽에서 props 이름이 직관적이지 않다는 피드백을 받았습니다.
이후엔 실제로 쓰는 코드를 먼저 작성하고, 그 코드가 자연스럽게 읽히는지 확인한 뒤 구현하는 순서로 바꿨습니다. props 이름이 동사인지 명사인지, 기본값이 자연스러운지를 먼저 결정했습니다. 사용하는 쪽의 편의를 먼저 설계하는 것이 라이브러리 설계의 핵심이라는 걸 배웠습니다.
이 경험으로 라이브러리는 만드는 사람 관점보다 쓰는 사람 관점에서 먼저 설계해야 한다고 생각합니다. 쓰는 코드가 자연스러울수록 좋은 라이브러리였습니다.
라이브러리를 개선할 때 가장 어려운 자리는 역호환을 유지하면서 인터페이스를 바꾸는 것이었습니다. 처음 설계가 완벽하지 않아서 props 이름을 바꾸고 싶었는데, 이미 여러 곳에서 쓰이고 있어 한 번에 바꿀 수 없었습니다.
결국 기존 prop을 @deprecated로 표시하고, 새 prop을 함께 지원하는 과도기를 거쳤습니다. 유지 기간을 명시하고 콘솔에 경고를 띄우는 방식으로 팀에 알렸지만, 실제로 마이그레이션을 완료하는 데 예상보다 오래 걸렸습니다.
이 경험으로 라이브러리 설계에서 처음 인터페이스가 얼마나 중요한지 나중에 비용으로 배웠습니다. 처음에 신중한 게 나중에 리팩터링 비용을 낮춥니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.