써드 파티 (Third Party)

장점과 위험

써드 파티 활용의 이점은 분명하다. 바퀴를 다시 발명하지 않아 개발 속도가 빨라지고, 수많은 사용자에게 검증된 코드를 쓰므로 직접 구현보다 품질이 높은 경우가 많으며, 팀은 핵심 비즈니스 로직에 집중할 수 있다. 그러나 외부 코드는 통제할 수 없다는 근본적인 위험이 따른다.

• 보안 위험: 의존 라이브러리의 취약점이 곧 내 서비스의 취약점이 된다. 로깅 라이브러리 하나의 결함이 전 세계 서비스를 위협했던 Log4j 사태가 대표적이다. 악성 코드가 심긴 패키지를 정상 패키지와 비슷한 이름으로 배포하는 타이포스쿼팅(Typosquatting) 같은 공급망 공격(Supply Chain Attack)도 늘고 있다.
• 유지보수 위험: 프로젝트가 방치되거나 하위 호환을 깨는 변경이 나올 수 있고, 심하면 제작자가 패키지를 삭제해 생태계 전체의 빌드가 멈추기도 한다.
• 종속 위험: 특정 외부 서비스에 깊이 결합되면 가격 인상이나 정책 변경에 끌려가는 벤더 종속(Vendor Lock-in)이 생긴다.
• 라이선스 위험: 오픈소스라도 GPL처럼 파생물 공개 의무가 있는 라이선스를 상용 제품에 잘못 쓰면 법적 문제가 된다.

실무에서의 관리 방법

써드 파티 의존성은 도입보다 관리가 본론이다. 첫째, 도입 전에 검토한다. 유지보수 활동이 살아 있는지, 문서와 커뮤니티가 충분한지, 라이선스가 제품과 호환되는지, 기능 대비 크기가 과하지 않은지 본다. 몇 줄이면 직접 짤 수 있는 기능을 위해 의존성을 추가하는 것은 좋지 않은 신호다. 둘째, 버전을 고정하고 추적한다. 잠금 파일(Lock File)로 빌드 재현성을 보장하고, 의존성 취약점 스캔 도구와 자동 업데이트 봇을 파이프라인에 붙여 알려진 취약점이 공개되는 즉시 알림을 받고 대응한다. 업데이트를 오래 미루면 한 번에 올리기 어려워지므로 작은 업데이트를 자주 하는 편이 안전하다. 조직 차원에서는 소프트웨어 자재 명세서(Software Bill of Materials, SBOM)로 어떤 구성 요소를 쓰고 있는지 목록화하는 관행이 확산되고 있다. 셋째, 경계를 만든다. 외부 API나 라이브러리를 코드 전반에서 직접 호출하지 않고 어댑터(Adapter) 계층 뒤에 감추면, 교체가 필요할 때 수정 범위가 그 계층으로 제한된다. 외부 서비스 호출에는 타임아웃과 재시도, 장애 시의 대체 동작을 설계해 외부 장애가 내 서비스 전체를 멈추지 않게 한다.

마지막으로 만들 것인가 살 것인가(Build vs Buy)의 판단 기준이 필요하다. 일반적인 원칙은 제품의 경쟁력을 결정하는 핵심 도메인은 직접 만들고, 결제나 인증처럼 잘 풀린 일반 문제는 외부 솔루션을 쓰는 것이다. 핵심 영역을 외부에 맡기면 차별화 능력을 잃고, 반대로 일반 문제를 직접 구현하면 본질이 아닌 곳에 유지보수 비용을 계속 지불하게 된다. 다만 외부 서비스의 비용 구조, 데이터 소유권, 규제 요건에 따라 판단이 달라질 수 있으므로 일률적인 답은 없다.

면접에서 이렇게 물어본다

• 퍼스트 파티, 세컨드 파티, 써드 파티를 구분해 설명하고 각각의 예를 들어 보라.
• 써드 파티 라이브러리를 도입할 때 어떤 기준으로 검토하는가.
• 공급망 공격이란 무엇이며 어떻게 대비할 수 있는가.
• 외부 API 장애가 서비스 전체로 번지지 않게 하려면 어떻게 설계해야 하는가.
• 써드 파티 쿠키가 제한되는 배경과 그 영향에 대해 아는 대로 말해 보라.