Social Proof is in the Pudding: The (Non)-Impact of Social Proof on Software Downloads

이 논문은 GitHub 에서 별점이나 다운로드 수와 같은 사회적 증거를 인위적으로 조작해도 오픈소스 소프트웨어의 다운로드나 개발자 참여 활동에 유의미한 영향을 미치지 않는다는 것을 두 가지 현장 실험을 통해 규명했습니다.

핵심

이 논문은 **"인기 있는 척 꾸미면, 사람들이 진짜로 그걸 사나?"**라는 아주 흥미로운 질문을 던집니다.

소프트웨어 개발자들이 새로운 프로그램을 선택할 때, 마치 우리가 식당을 고를 때 '인기 메뉴'나 '별점'을 보는 것처럼, GitHub(코드 공유 사이트) 의 '스타 (Star)' 수나 **PyPI(파이썬 패키지 저장소) 의 '다운로드 횟수'**를 보고 판단합니다. 이를 '사회적 증명 (Social Proof)'이라고 하죠.

악의적인 해커들은 이 점을 노려, 가짜 스타나 가짜 다운로드를 사서 악성 소프트웨어를 인기 있는 것처럼 보이게 만들 수 있습니다. 이 논문은 **"그런 가짜 인기 조작이 실제로 사람들의 다운로드 행동을 바꿀까?"**를 실험으로 증명했습니다.

결론부터 말하면, "아니요, 전혀 효과가 없었습니다."

이 복잡한 연구를 일상적인 비유로 쉽게 설명해 드릴게요.

---

1. 실험의 배경: "가짜 줄서기"와 "가짜 별점"

상상해 보세요. 새로운 식당이 생겼는데, 아무도 모릅니다. 그런데 갑자기 그 식당 앞에 가짜 줄이 서 있거나, 가짜 리뷰가 500 개 달렸다면? 우리는 "아, 이 식당이 인기 있나 보다"라고 생각하며 들어갈까요?

연구자들은 두 가지 실험을 했습니다.

• 실험 1 (GitHub 스타): 새로운 파이썬 프로그램 100 개를 뽑아서, 그중 일부에 **가짜 '스타 (좋아요)'**를 20~65 개나 붙여주었습니다. (일부는 연구팀 친구들이 직접 눌러주고, 일부는 인터넷에서 돈을 주고 사서 붙였습니다.)
• 실험 2 (다운로드 횟수): 다른 프로그램들은 실제 다운로드 횟수를 조작했습니다. 가짜 스크립트를 돌려 다운로드 횟수를 5 배나 불려서 인기 있는 척 했습니다.

2. 실험 결과: "줄이 길어도 사람들은 안 들어온다"

결과가 매우 놀랍습니다.

• 스타를 붙였더니? 스타 수가 늘어났지만, 실제 사람들이 그 프로그램을 다운로드한 수는 전혀 변하지 않았습니다.
• 다운로드 횟수를 조작했더니? 다운로드 수가 불어났지만, 그 후로 사람들이 추가로 다운로드한 수는 여전히 변하지 않았습니다.

마치 가짜 줄이 서 있는 식당이 있다고 해서, 실제로 그 식당에 들어가는 손님이 늘어나지 않는 것과 같습니다. 개발자들은 "아, 스타가 많네? 가짜일 수도 있겠다"라고 의심하거나, 단순히 인기만 보고 선택하지 않는다는 뜻입니다.

3. 왜 이런 결과가 나왔을까? (핵심 이유)

연구자들은 두 가지 이유로 설명합니다.

1. 개발자는 '현실적인 위험'을 감수할 수 없다:
   일반인이 옷을 살 때는 "인기 있는 옷이니까 괜찮겠지"라고 생각할 수 있습니다. 하지만 개발자가 코드를 쓸 때는 보안 문제가 생길 수 있습니다. "이 프로그램에 바이러스가 숨어있으면 내 회사 시스템이 다 망가질 수도 있어!"라고 생각하기 때문에, 단순히 '인기 (별점)'만 보고 선택하지 않고 코드를 직접 확인하거나, 문서가 잘 되어 있는지, 누가 만들었는지를 꼼꼼히 따집니다. 즉, 중요한 결정을 내릴 때는 '인기'보다 '실질'을 더 중요하게 생각합니다.

2. 가짜 인기 시장은 이미 너무 유명하다:
   "GitHub 스타를 팝니다"라는 광고가 인터넷에 떠돌아다니는 것을 개발자들이 이미 알고 있습니다. "별점이 많다고 해서 좋은 게 아니야, 그냥 돈 주고 산 거일 수도 있어"라고 의심하는 눈이 커진 것입니다. 신호 (별점) 가 너무 쉽게 조작 가능해지면, 사람들은 그 신호를 더 이상 믿지 않게 됩니다.

4. 이 연구가 우리에게 주는 교훈

이 연구는 "악성 소프트웨어가 가짜 인기로 사람들을 속일 수 있다"는 공포는 아직 완전히 사라지지 않았지만, 우리가 생각했던 것만큼 가짜 인기 조작이 만능은 아니다는 것을 보여줍니다.

• 플랫폼의 역할: GitHub 같은 사이트는 이제 "별점 수"만 보여주는 게 아니라, "별점이 얼마나 빠르게 늘었는지 (갑작스러운 증가는 가짜일 수 있음)", "실제 코드를 기여한 사람인지" 같은 더 정교한 정보를 제공해야 합니다.
• 우리의 태도: 우리는 '인기'라는 말에 속지 말고, "왜 이 프로그램이 인기 있을까? 진짜 이유를 찾아보자"라고 의심하는 태도가 필요합니다.

요약하자면

"인기 있는 척 하는 가짜 줄 (스타/다운로드) 을 만들어도, 진짜 중요한 결정을 내리는 사람들은 그 줄을 보고 따라가지 않는다."

이 논문은 개발자들이 생각보다 훨씬 똑똑하고, 가짜 인기 조작에 둔감하다는 것을 증명했습니다. 하지만 여전히 해커들이 더 교묘하게, 더 대규모로 조작을 시도할 수 있으므로, 우리는 항상 경계심을 늦추지 말아야 합니다.

기술 요약

1. 연구 배경 및 문제 제기 (Problem)

• 개방형 소스 소프트웨어 (OSS) 와 보안 위협: 상업적 소프트웨어의 상당 부분이 OSS 에 의존하고 있으며, 개발자들은 새로운 문제를 해결할 때 보안 검증이 어려운 상황에서 '소셜 프루프 (Social Proof)' (예: GitHub Star 수, 다운로드 횟수) 를 주요 판단 기준으로 사용합니다.
• 악의적 행위자의 조작 가능성: 이러한 의존성은 악의적 행위자가 소셜 프루프 지표를 조작하여 악성 소프트웨어 (Malware) 를 유포하고 개발자들이 이를 채택하도록 유도할 수 있다는 우려를 낳습니다.
• 연구 질문: 인위적으로 조작된 소셜 프루프 (Star 수 증가, 다운로드 횟수 조작) 가 실제로 개발자의 소프트웨어 채택 행동 (다운로드 및 기여) 을 변화시키는가?

2. 연구 방법론 (Methodology)

저자는 두 가지 현장 실험 (Field Experiments) 을 통해 인과 관계를 규명했습니다.

실험 1: GitHub Star 조작 실험

• 대상: 2023 년 4 월 말에 출시된 새로운 Python 패키지 (PyPI) 와 연결된 GitHub 저장소 622 개.
• 무작위 할당: 100 개를 처리군 (Treatment), 나머지를 대조군 (Control) 으로 무작위 배정.
• 처치 (Treatment) 조건:
  • 저용량 (Low dosage): 연구 네트워크의 사용자를 통해 75 개 저장소에 Star 추가 (중앙값 19 개 증가).
  • 고용량 (High dosage): 25 개 저장소에 시장 (Baddhi Shop) 에서 구매한 Star 50 개 추가 + 네트워크 Star 추가 (중앙값 69 개 증가).
• 측정 지표: PyPI 패키지 다운로드 수 (주요 결과 변수), GitHub 저장소 활동 (Fork, Pull Request, Issue 등).
• 분석 기간: 처치 후 3 개월간 추적.

실험 2: PyPI 다운로드 횟수 조작 실험

• 대상: PyPI 의 50,000 개 패키지 중 최소 5 회 이상 인간 다운로드가 있는 23,916 개 패키지.
• 무작위 할당: 4,814 개를 처리군, 19,102 개를 대조군으로 배정.
• 처치 조건: 처리군 패키지에 대해 스크립트를 사용하여 100 회 다운로드를 수행 (Linehaul 로그에 인간 다운로드로 기록되도록 캐시 우회).
• 측정 지표: 처치 후 추가적인 인간 다운로드 수 및 GitHub 저장소 활동.

3. 주요 결과 (Key Results)

두 실험 모두 소셜 프루프 조작이 소프트웨어 채택에 유의미한 영향을 미치지 않았다는 결론을 내렸습니다.

• GitHub Star 실험 결과:
  • Star 수를 인위적으로 늘렸음에도 불구하고, 처리군과 대조군 간의 PyPI 다운로드 수에 통계적으로 유의미한 차이가 발생하지 않았습니다.
  • Fork, Pull Request, Issue 생성 등 개발자 참여 지표에서도 유의미한 변화가 관찰되지 않았습니다.
  • 패키지 복잡도 (저장소 크기, 문서 길이) 에 따른 이질적 효과도 발견되지 않았습니다.
• PyPI 다운로드 실험 결과:
  • 다운로드 횟수를 약 5 배 (중앙값 20→100) 늘렸음에도 불구하고, 처치 기간 종료 후 유기적 (Organic) 다운로드 증가를 유도하지 못했습니다.
  • 오히려 처리군의 다운로드 추세가 대조군보다 약간 더 완만해지는 경향 (부정적 계수) 을 보였으나, 이는 통계적 유의성보다는 우연일 가능성이 높습니다.
  • 다운로드 조작이 GitHub 저장소의 Star, Fork 등 다른 지표로 전이 (Spillover) 되지 않았습니다.
• 통계적 검정력 (Power):
  • 실험 설계는 큰 효과 (평균 다운로드의 83% 이상 증가) 를 배제할 수 있을 만큼 충분한 검정력을 가졌습니다.
  • 그러나 상업적 '아스트로터핑 (Astroturfing)' 캠페인 수준으로 강력하고 지속적인 조작이 이루어졌을 경우의 미세한 효과는 검출하지 못했을 수 있습니다.

4. 주요 기여 및 논의 (Contributions & Discussion)

• 이론적 반박: 기존 연구 (Salganik et al., 2013 등) 는 소셜 프루프가 성공을 증폭시킨다고 주장했으나, 본 연구는 소프트웨어 채택이라는 맥락에서는 그 효과가 미미함을 보여줍니다.
  • Elaboration Likelihood Model (ELM): 개발자는 소프트웨어 선택 시 보안과 유지보수 비용 등 실질적 결과를 고려하므로, '주변적 경로 (Peripheral route, 인기 지표)'보다 '중심적 경로 (Central route, 코드 품질, 문서 등)'를 통해 신중하게 평가합니다.
  • 신호 이론 (Signaling Theory): GitHub Star 는 저렴한 비용으로 구매 가능하여 신호의 신뢰도가 하락 (Degradation) 했습니다. 개발자들은 이를 인지하고 Star 수를 신뢰하지 않습니다.
• 플랫폼 설계 시사점:
  • 단순한 인기 지표 (Star 수) 보다는 Star 의 속도 (Velocity), 기여자 활동 이력, OpenSSF Scorecard와 같은 보안 건강도 지표, 그리고 **구 cryptographic 검증 (Build Provenance)**을 통한 공급망 신뢰 구축이 더 중요합니다.
• 윤리적 고려사항:
  • 실험은 플랫폼 사용자의 사전 동의 없이 진행되었으나, 악성 코드 배포나 데이터 유출 없이 공개된 메트릭만 조작하여 윤리적 위험을 최소화했습니다.

5. 결론 및 의의 (Significance)

• 결론: "증거의 부재는 부재의 증거가 아니다" (Absence of evidence is not evidence of absence) 라는 경고를 남기며, 현재 연구된 수준의 조작으로는 개발자 행동 변화가 일어나지 않았지만, 더 강력하고 지속적인 조작이나 AI 기반 코딩 에이전트 (Agentic Coding) 의 등장은 향후 소셜 프루프 조작의 효과를 높일 수 있음을 경고합니다.
• 의의:
  • 소프트웨어 공급망 보안 (Supply Chain Security) 연구에 실증적 데이터를 제공하여, 단순한 인기 지표 조작만으로는 악성 소프트웨어를 성공적으로 유포하기 어렵다는 것을 시사합니다.
  • 플랫폼 운영자 (GitHub, PyPI) 에게는 단순한 숫자 조작 방지를 넘어, 신뢰할 수 있는 공급망 검증 인프라 구축의 중요성을 강조합니다.

이 연구는 개발자들이 기술적 결정을 내릴 때 얼마나 비판적으로 사고하며, 소셜 프루프가 얼마나 취약한 신호인지에 대한 중요한 통찰을 제공합니다.