Y Combinator가 올해 스타트업 스쿨 2026 지원 절차에 도입한 'Paxel'이라는 도구를 둘러싼 보안 사례가 공개됐다. 한 지원자가 이 도구의 채점 파이프라인에서 서명 검증이 빠진 취약점을 발견해, 누구든 자신의 점수를 조작해 YC의 랭킹 데이터베이스에 밀어넣을 수 있었다는 내용이다. 제보자는 YC 측 Jared Friedman으로부터 공개 몇 시간 만에 패치 확정과 함께 SF 현장 초대까지 받았다고 밝혔다. 흥미로운 사건이지만, 그보다 실무자에게 유의미한 것은 이 사고가 분산형 애플리케이션 설계에서 반복되는 전형적인 실수를 그대로 보여준다는 점이다.
로컬에서 돌아가는 채점 파이프라인
Paxel의 사용 방식은 단순하다. curl -fsSL https://paxel.ycombinator.com/upload.sh | bash 한 줄이면 설치 스크립트가 시스템을 훑고, 질문을 던지고, 결과 업로드까지 처리한다. Paxel 소개 페이지는 자신의 작업을 시각화하고 '당신의 아키타입은 무엇인가' 같은 재미 요소를 제공한다고 설명한다. 그러나 내부 구조를 뜯어보면 결코 가벼운 도구가 아니다. 302KB짜리 설치 스크립트가 인증, 프로젝트 탐색, git 히스토리 추출, 도커 초기화를 담당하고, 실제 채점은 도커 이미지로 내려받은 루비 앱이 프로젝트별로 수행한다. 이 앱이 LLM을 통해 다섯 개 축에 대해 1~10점과 자유 서술 메모를 매긴다. 제보자에 따르면 지금까지 120만 명 이상의 코더가 이렇게 만들어진 리포트를 YC에 올렸다.
핵심은 이 파이프라인이 상당 부분을 지원자 본인의 컴퓨터에서 돌리는 분산형 구조라는 데 있다. 채점과 집계를 자체 서버에 가두지 않고 클라이언트에서 처리하는 방식은 UX와 비용 측면에서 매력적이지만, 그만큼 결과의 무결성을 암호학적으로 보장하는 장치가 필수가 된다. 바로 그 장치 하나가 빠져 있었다.
nonce는 검증했지만 서명은 없었다
파이프라인은 LLM 프록시가 매 에피소드마다 반환하는 nonce를 LLM 서버와 업로드 서버가 공유하도록 설계돼 있었다. 이론상 nonce는 'LLM이 실제로 산출한 결과만 /v1/results 엔드포인트가 받아들이도록' 보증하는 역할을 해야 한다. 실제로 서버는 nonce가 없거나 유효하지 않은 요청을 거부했고, 한 번 쓰면 소각했다. 여기까지는 정상이다.
문제는 이 nonce가 LLM의 점수와 메모 같은 결과 내용에 대한 서명을 담지 않았다는 점이다. 즉 nonce의 유효성만 확인할 뿐, 그 nonce가 특정 채점 결과에 묶여 있는지는 확인하지 않았다. 결과적으로 유효한 nonce 하나만 확보하면 점수와 메모를 원하는 값으로 바꿔 올릴 수 있었고, 같은 프로젝트라도 점수를 올리면 리포트가 크게 달라졌다. 제보자는 같은 한 줄 설치 방식을 흉내 낸 'paxel-boosted'라는 미러링 도구까지 만들어 배포했고, 공개부터 패치까지 몇 시간 동안 20명 넘는 사용자가 스스로를 상위 1%로 등록했다고 한다.
제안된 수정과 실무적 시사점
제안된 해법은 교과서적이다. LLM에서 서버로 거의 그대로 전달되는 점수·제목 등 필드를 모두 nonce의 HMAC에 함께 말아 넣어, nonce = hmac(request_id)를 nonce = hmac(request_id + 각 축 점수 + ... + title) 형태로 바꾸는 것이다. YC가 실제로 적용해 발표한 패치도 이와 사실상 동일했다. 여기에 더해, 클라이언트가 끝까지 사용하지 않는 채점 세부값·에피소드 제목·메모 같은 필드는 서버만 아는 AEAD 암호나 비대칭 키로 감싸자는 이차 제안도 나왔다. 이는 본질적으로 보안이 아닌 은닉에 가깝지만, 처음부터 적용됐다면 공격자가 무엇을 바꿔야 하는지조차 알 수 없었을 것이라는 지적이다.
이 사례가 특별히 정교한 공격이어서 주목할 만한 것은 아니다. 오히려 '검증한다'와 '무엇을 검증하는가'가 다르다는, 자주 간과되는 구분을 선명하게 드러낸다. nonce 재사용 방지처럼 눈에 보이는 통제는 갖췄지만, 그 토큰이 보호해야 할 실제 페이로드와의 결속이 빠지면 통제 전체가 무력화된다. 클라이언트에 신뢰 경계를 두는 구조를 설계한다면, 서버가 받아들이는 모든 민감 필드가 위·변조 불가능한 서명 안에 포함되는지 반드시 점검해야 한다.
마지막으로 대응 방식도 눈여겨볼 만하다. 제보자는 12일 앞서 이메일로 비공개 제보를 했지만 응답을 받지 못했고, 공개 이후에야 빠른 패치와 소통이 이뤄졌다고 전했다. 제보자 스스로 이것이 숨겨진 이스터에그나 허니팟일 가능성도 열어뒀으나, 파이프라인의 작성 방식으로 볼 때 그렇지는 않아 보인다고 덧붙였다. 취약점 자체보다, 비공개 채널이 막혔을 때 공개 disclosure로만 프로세스가 작동했다는 대목이 조직의 제보 대응 체계를 되돌아보게 한다.