이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
코드 중복 문제를 처음 의식한 건 같은 API 호출 패턴이 화면마다 복붙돼 있는 걸 발견했을 때였습니다. 로직이 보이면 바로 추출하는 것이 먼저라고 봐서, 공통 부분을 useApiRequest라는 커스텀 훅으로 묶었습니다. 그런데 추상화를 너무 일찍 하면 요구사항이 달라질 때 오히려 변경 비용이 커지는 경우를 경험했고, 이후엔 세 군데 이상 반복될 때 추출을 고려하는 기준을 팀과 공유하게 됐습니다. 유틸 함수는 순수 함수로 만들어 테스트 가능하게 유지하는 습관이 생겼고, 그게 나중에 단위 테스트를 붙이는 비용을 크게 낮춰줬습니다.
잘못 추상화된 코드가 중복 코드보다 관리하기 더 어렵다는 걸 직접 겪으며 배웠습니다.
코드의 중복을 없애는 것이 항상 옳은 방향이 아니라는 것을 경험했습니다. 비슷해 보이는 두 로직을 하나로 합쳐서 추상화했는데, 나중에 두 로직의 요구사항이 다르게 변경되면서 추상화된 코드에 조건 분기가 계속 추가됐습니다. 처음에 중복을 허용했다면 각각 독립적으로 변경할 수 있었을 텐데, 억지로 합친 결과로 한 쪽을 수정할 때 다른 쪽에 영향이 가지 않도록 항상 확인해야 하는 구조가 됐습니다. 이 경험에서 중복 제거의 기준은 코드가 얼마나 비슷하게 생겼는지가 아니라 두 코드가 같은 이유로 변경되는지를 확인하는 것이 더 중요하다는 것을 배웠습니다. 함께 변경될 코드는 묶고, 다른 이유로 변경될 코드는 분리하는 것이 유지보수 비용을 줄이는 방향이라는 것을 이 경험에서 배웠습니다.
반복되는 로직을 공통 유틸 함수로 만들어 팀에 공유했는데, 예상치 못한 문제가 생긴 경험이 있습니다. 공통 함수가 여러 곳에서 쓰이면서 한 사용처의 요구사항에 맞게 수정하면 다른 사용처에 영향이 생기는 경우가 있었습니다. 처음에 함수를 만들 때 어떤 요구사항을 위한 것인지를 명확히 하지 않았고, 시간이 지나면서 서로 다른 목적으로 같은 함수를 쓰는 상황이 됐습니다. 이후에는 공통 함수를 만들 때 어떤 케이스를 다루는지 명확히 정의하고, 그 범위를 벗어나는 케이스는 별도로 처리하도록 기준을 세웠습니다. 코드 중복을 줄이는 것은 좋지만, 공통 코드가 여러 곳에서 의존하는 코드가 되면 변경 비용이 높아진다는 트레이드오프가 있다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.