이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
PnP의 핵심은 node_modules라는 거대한 폴더 자체를 없애려는 것이라고 이해합니다. 기존 방식은 의존성을 실제 파일로 수천 개 풀어 놓는데, 그게 설치가 느리고 용량이 크며 무엇이 진짜 의존인지 흐려지는 문제를 만듭니다. PnP는 파일을 풀지 않고, 어떤 패키지가 어디 있는지를 한 지도로 관리해 그 지도로 바로 찾게 합니다. 그래서 좋아지는 건 설치가 빠르고, 선언 안 한 패키지를 몰래 쓰는 일이 막힌다는 것입니다. 다만 도입 문제가 분명합니다.
node_modules가 있다고 가정하고 만든 도구나 라이브러리가 그 폴더를 못 찾아 깨집니다. 학부 프로젝트에서 일부 도구가 PnP를 몰라 실행이 안 되던 경험이 있어, 그건 호환 설정으로 우회해야 했습니다. 그래서 저는 팀 도구 체계가 PnP를 받아들일 수 있는지부터 확인하고, 안 되면 무리해서 도입하지 않습니다.
저는 PnP를 도입하다 깨져서 제대로 이해했습니다. 설치는 분명히 빨라졌는데, 몇몇 도구가 갑자기 동작을 안 했습니다. 원인을 따라가니 그 도구들이 node_modules 폴더가 그 자리에 있다고 전제하고 파일을 직접 뒤지던 것이었습니다. PnP는 그 폴더를 안 만드니, 전제가 깨진 것입니다. 즉 PnP가 바꾸는 본질은 의존성을 푸는 방식이라, 그 방식을 모르는 도구는 다 영향을 받습니다. 그래서 호환 모드나 도구 패치로 우회했고, 안 되는 일부는 그 작업만 기존 방식으로 분리했습니다. 그 경험에서 PnP의 이득(빠름·유령 의존 차단)은 분명하지만, 도입 비용은 팀이 쓰는 도구 수에 비례한다는 걸 알았습니다. 그래서 저는 도구가 단순한 새 프로젝트엔 적극, 도구가 많은 레거시엔 신중하게 봅니다.
PnP를 저는 무엇을 얻고 무엇을 치르는 거래로 정리합니다. 얻는 건 분명합니다. 설치가 빠르고, 용량이 줄고, 선언 안 한 패키지를 몰래 쓰던 유령 의존이 막힙니다. 이건 의존성을 파일로 풀지 않고 지도로 관리하기 때문에 생기는 이득입니다. 치르는 건 생태계 호환입니다.
node_modules를 전제로 만든 수많은 도구가 적응해야 하고, 적응 안 된 건 우회·패치가 필요합니다. 그래서 도입 판단 기준은 우리가 쓰는 도구들이 이미 PnP를 받아들이는가입니다. 새 프로젝트라 도구가 단순하면 이득이 비용보다 크고, 오래된 큰 프로젝트라 도구가 많으면 비용이 먼저 옵니다. 학부 때 작은 새 프로젝트엔 무난했는데, 도구가 많은 쪽에선 우회만 늘어난 경험이 이 기준의 근거입니다. 신기술이라 덮어놓고가 아니라 도구 생태계가 정당화할 때 도입합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.