---
title: "서드파티 핵은 쿼크가 아니다 — Old New Thing 댓글에서 벌어진 통합 철학 논쟁"
published: 2025-12-05T22:24:54.000Z
canonical: https://jeff.news/article/475
---
# 서드파티 핵은 쿼크가 아니다 — Old New Thing 댓글에서 벌어진 통합 철학 논쟁

Raymond Chen 블로그 댓글에서 서드파티 프로세스에 원격 스레드를 주입하는 식의 핵을 '쿼크'라 포장하는 관행에 대한 날카로운 비판과, ATM 리부트 루프 같은 실제 사고 사례를 통해 올바른 통합 경계의 중요성을 논함

- Raymond Chen의 Old New Thing 블로그 댓글에서 벌어진 소프트웨어 엔지니어링 철학 논쟁이 꽤 읽을 만함. 핵심은 "서드파티 프로세스에 원격 스레드 주입하는 걸 '쿼크 추가'라고 부르는 순간, 하던 일 멈추고 자기 성찰 좀 하라"는 거임
- "핵을 넣든가 고객을 잃든가"는 거짓 이분법이라는 주장. 진짜 대안은 지원 가능한 동작을 정의하거나, 올바른 경계에서 통합을 고치거나, 실제로 망가진 컴포넌트 쪽에 변경을 요청하는 것
- 쿼크를 추가하면 생기는 일: 문제를 숨기고, 장기 비용은 올라가고, 정의되지 않은 동작을 에뮬레이트하는 코드에 리스크가 전가됨. 서드파티 업데이트 한 번에 전부 깨질 수 있음
- 실제 사례가 살벌함 — "ATM이 리부트 루프에 빠져서 은행이 VISA/MasterCard한테 물린 다운타임 위약금을 배상하라고 요구한 적 있음". 핵의 대가가 이 정도임
- 반론도 있긴 함: 서드파티가 "관심 없음" 또는 "소스코드 잃어버림"이라고 하면 어쩌냐는 건데, 그에 대한 답변이 냉정함 — "흔하다고 올바른 건 아님"
- 15년차 경력자 시각: 서드파티 통합 문제의 대부분은 컴포넌트 사용법을 제대로 이해 못 하거나, 이미 존재하는 유료 컴포넌트 라이선스를 안 사려 하거나, 변경 요청 비용을 안 내려는 데서 옴
- 결국 핵심 질문은 이거임 — "매니저가 다른 개발자가 제안한 엉터리 솔루션을 너한테 위임했을 때, 그냥 쓸 거냐 아니면 '이거 제안한 사람이 직접 짜시죠'라고 말할 전문가적 소신이 있느냐"

## 핵심 포인트

- '핵을 넣든가 고객을 잃든가'는 거짓 이분법 — 지원 가능 동작 정의, 올바른 경계 수정, 망가진 컴포넌트에 변경 요청이 진짜 대안
- 쿼크 추가는 문제를 숨기고 장기 비용을 높이며 정의되지 않은 동작 에뮬레이션 리스크를 전가함
- ATM 리부트 루프로 VISA/MasterCard 다운타임 위약금 배상 사례 등 실제 피해가 발생함

## 인사이트

서드파티 통합 문제의 근본 원인은 대부분 사용법 미이해, 유료 컴포넌트 라이선스 회피, 변경 요청 비용 회피에서 비롯되며 핵으로 우회하면 결국 더 큰 비용으로 돌아옴