▲

Cloudflare의 AI가 작성한 OAuth 라이브러리 살펴보기

 (neilmadden.blog)
5P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • Cloudflare는 Anthropic의 Claude LLM을 활용해 새로운 OAuth 라이브러리를 개발하고, 프롬프트도 같이 공개했음
  • 라이브러리의 코드 구조는 깔끔하지만 테스트와 보안 검증 측면에서 많은 아쉬움이 존재함
  • CORS와 일부 인증 규격 구현에서 비표준적 또는 위험한 선택이 발견됨
  • 암호화 구현에는 장점이 있지만, 중대한 보안 버그와 프로토콜 오해가 드러남
  • LLM 기반 자동 코딩은 도움이 되나, 실무 수준 보안에는 전문가의 면밀한 검토가 필수임

Cloudflare OAuth 라이브러리의 개요

  • Cloudflare는 OAuth 프로바이더 라이브러리를 Anthropic의 Claude LLM을 활용해 대부분 자동으로 작성함
  • Claude의 출력물은 숙련된 Cloudflare 엔지니어들의 보안 및 표준 준수 검토를 거쳤으며, 커밋 히스토리에서 AI와의 상호작용 과정을 투명하게 공개함
  • 초기 구현 후 Claude의 추가 프롬프트와 결과물 검토를 통해 퀄리티를 보완함
  • AI에만 의존하지 않고, RFC 문서와의 교차 점검 및 핵심 전문가 리뷰가 강조된다고 명시함

전문가의 첫인상 및 코드 분석

  • LLM 코딩 방식 특유로 코드가 단일 파일에 집중되어 있으나, 구조는 일관되고 쓸데없는 주석이 비교적 적음
  • 기능 테스트는 있으나 OAuth와 같은 중요 인증 서비스에 요구되는 수준에는 미치지 못함
    • 필수(MUST/MUST NOT) 사양 체크가 빠진 부분 및 파라미터 유효성 약화가 엿보임

보안 관련 우려 및 번역자 해설

1. CORS 정책 문제 ("YOLO CORS")

  • 거의 모든 오리진을 허용해 동일 출처 정책이 사실상 해제되는 CORS 헤더 세팅이 발견됨
  • 이는 Cloudflare 엔지니어가 LLM이 아닌 사람이 직접 결정한 부분임
  • credentials 기능은 활성화되어 있지 않아 치명적 브라우저 보안 위협은 낮지만, 원인과 목적의 분명성이 미흡함

2. 표준 보안 헤더 미적용

  • HTTP 응답에 X-Content-Type-Options: nosniff 및 HTTP Strict Transport Security 등 핵심 보안 헤더 미적용 현상이 존재함
  • JSON API 특성상 일부 헤더의 필요성이 낮을 수 있으나, 클라이언트/브라우저 취약점 예방 차원에서 적용 필요성이 큼

3. OAuth 표준 미숙지 흔적

  • Public client 지원을 위해 OAuth 2.1에서 폐기된 implicit grant 방식을 구현함
    • 사실 해당 기능은 PKCE나 CORS 완화로 충분히 대체 가능
    • Claude가 implicit grant를 추천한 것으로 보이며, 실제 토큰 발급 단계에서는 제대로 검증하지 않음
  • Basic Auth 처리 미흡: OAuth에서는 특유의 URL 인코딩 방식이 필요한데 이를 누락함
    • 클라이언트 시크릿에 콜론 포함 시 발생할 수 있는 보안 버그 secondary issue
    • 단, 해당 라이브러리는 자체적으로 클라이언트 ID/시크릿을 생성해 형식 통제가 가능한 구조임

4. 토큰 ID 생성 코드의 보안 문제

  • 토큰 ID 랜덤 문자열 생성 방법이 통계적으로 치우침(biased) 이 존재함
    • 엔트로피 감소로 인해 공격이 용이해질 수 있으나, 실질적인 위협은 제한적임
  • "모든 코드 라인이 전문가에 의해 리뷰되었다"는 주장과 달리, 초기 커밋에서 버그가 그대로 존재
    • 첫날 한 명의 개발자가 21번 메인 브랜치에 직접 커밋한 이력 등, 체계적 리뷰 부족을 암시함

암호화 기능 및 LLM 상호작용 사례

  • 토큰 저장소 암호화 설계는 사람이 주도하고, 구현은 Claude가 지원함
  • 토큰별로 props를 암호화하고, 각 토큰에 대해 대칭키를 래핑하는 방식 적용
  • Claude가 중간에 잘못된 설계를 제안하자, 엔지니어가 의도와 보안 취지를 명확하게 제시하여 수정함
    • 예시: SHA-256 해시를 래핑키로 사용할 경우 드러나는 취약점 지적 후 HMAC 기반으로 변경
    • PBKDF2 제안에 대해 성능상 비효율을 짚고, 32바이트 HMAC 키 적용으로 조정함
  • 이 과정은 AI와 작업할 때 높은 수준의 도메인 지식 필요성을 잘 보여줌
    • 치명적 결함을 비전문가라면 인지조차 어려울 수 있음

총평 및 시사점

  • 첫 버전 임에도 완성도는 무난하나, 실 서비스에 바로 적용하기에는 위험성이 큼
  • OAuth 프로바이더 개발은 본질적으로 매우 까다로운 보안·기능 검증 작업이 필요함
    • 대기업 수준의 수십만 개 자동화 테스트와 다계층 보안 점검이 일반적임
    • LLM 기반 자동 코딩을 “쉽게” 적용할 수 있는 분야가 아님
  • 프로젝트의 커밋 히스토리는 LLM이 어느 수준까지 보조적으로 작동할 수 있는지 흥미롭게 보여줌
    • 단, 일부 결함은 LLM이나 사람 모두가 종종 범하는 실수이며, Stack Overflow 답변 등 기존 커뮤니티에서도 유사하게 발견됨
    • 면밀함과 꼼꼼함이 중요한 코드 영역에서는 AI, 인간 모두 세밀한 주의가 필요함
  • LLM을 활용해 코드를 검토하거나 결과를 신뢰하려면, 직접 구현 경험 및 System 2 사고가 필수적임
    • 단순/비핵심 작업에서는 충분히 LLM에 맡길 수 있지만, 인증이나 보안과 관련된 주요 시스템은 전문가 주도의 설계·구현이 바람직함
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • LLM과 상호작용할 때는 많은 도메인 지식이 필요함을 이번 사례에서 직접적으로 알 수 있음. 예를 들어 Claude가 중간에 만들어 낸 “치명적 결함”을 일반 개발자라면 눈치채지 못할 수 있음. PBKDF2로의 변경을 이상하게 여기는 것도 도메인 전문성 덕분임. 나의 결론은 LLM을 효율적으로 활용하려면 실력 있는 리뷰어와 ‘리더’가 필요한 것임. 만약 해당 주제에 대해 LLM만큼 모른다면, 반드시 비중이 낮거나, 충분히 시간적 여유가 있어야 모든 출력을 검증할 수 있음

    • 앞으로 이런 새로운 환경에서는 도메인 전문가들이 어디에서 생겨나는지 궁금증이 생김. 결국 누가 이렇게 깊이 아는 사람이 될 수 있을지 고민임

    • 사람들이 '잘 모르는 분야에서만 LLM을 쓴다, 전문가라면 직접 코딩한다'는 의견을 들을 때마다 의아함. 오히려 전문가일수록 LLM의 출력을 더 정확히 검토할 수 있고, 내가 원하는 것을 도메인 전문가의 방식에 가깝게 설명할수록 결과물이 좋아짐. 어찌 보면 당연한 일임(LMM이 통계적으로 생성된 텍스트 엔진이기 때문에)

    • LLM은 기본값 추가나, 예외 처리, 각종 우회로를 너무 쉽게 넣는 경향이 있음. 그래서 동작하는 듯 보이지만 실제로는 문제가 있거나 곧 실패할 코드가 쉽게 만들어짐. 내가 쓴 CLAUDE.md에서 여러 차례 이 부분을 강조하려 했는데도 종종 계속 그런 결과가 나옴

    • 나는 LLM으로 k8s 배포 작업을 대부분 처리했음. 빠르게 작동하는 결과를 내긴 하지만, 항상 시크릿을 사용하고 인증 정보를 평문으로 커밋하지 않도록 계속 주지시켜야 했음. 이런 실수는 정말 위험함. 교육용 튜토리얼에서는 기초에 집중하려고 보안을 자주 생략하는데, LLM 훈련 데이터에 그런 사례가 너무 많아서 이렇게 출력되는 것 같음

    • 시간이 지나면 AI 코딩 도구가 도메인 지식을 스스로 조사할 수 있을 것으로 기대함. 이미 나온 일부 ‘AI 연구’ 도구들은 이런 능력이 매우 뛰어나지만, 아직 코딩 도구와 제대로 통합돼 있지는 않음. 연구는 공개 인터넷 뿐 아니라 회사 내부 문서상의 도메인 지식을 참조할 수도 있음. 다만 일부 지식은 사람의 머릿속에만 있으므로 이용자가 직접 전달해줘야 함

  • 최근 Kafka consumer를 AI 도움으로 작성하여 데이터 마이그레이션을 진행함. 이런 단기성, 처음부터 새로 짜는 프로젝트이면서 내가 언어(go)는 꽤 알지만 오랜만에 쓰는 상황에서 AI 활용 효과가 최대치였음. 데이터가 모두 한 topic으로 들어와서 성능 확보를 위해 꽤 복잡한 병렬 처리를 구현했음. 전반적으로 AI 덕분에 약 2배는 빨라진 느낌이었음. 특히 go 문법을 가끔 잊을 때 검색 대신 AI에게 바로 물어본 부분이 도움됐음. 하지만 잠재적 버그가 적어도 4개(그 외로 명백한 버그들은 훨씬 더 많음)나 숨겨져 있었음. Kafka나 멀티스레딩에 익숙하지 않다면 바로 운영에 내보냈을 것도 같음. 대형/장기 프로젝트에서는 10~20% 수준의 개선이 나타남. 최신 모델 기준으로 이런 흐름임. 전체적으로 볼 때 이건 메모리 관리 언어로 전환할 때 얻었던 생산성 증가와 비슷함. PM이 개발자를 대체하는 상상과는 거리가 있음(지난 3년간 변화 속도 기준). 오히려 나의 진짜 걱정은 중간 레벨의 '기술 폭풍'급 개발자가 AI로 인해 10배 효율이 높아지면 미묘한 버그를 찾거나 대응하지 못해 더 위험할 수 있음. 시니어/스태프급 엔지니어가 리뷰 폭주를 감당할 수 없을 것 같음. 그리고 주니어에서 시니어로 성장하는 과정도 더 취약해질까 걱정임. 이미 복붙 프로그래머가 문제인데 AI로 인해 이런 패턴이 더 강화됨. 결국 시장이 해결하겠지만, 수십 년이 걸릴 수도 있다는 불안함

    • AI가 만들어내는 버그는 정말 교묘함. 나도 AI에 멀티스레드 코딩을 시켰다가 미묘한 버그를 실제로 운영에 넣은 적이 있음. 리뷰, 테스트를 해도, 직접 손으로 짰을 때만큼의 집중이 나오지 않음. 당분간 AI가 짠 코드는 취급 시 흔히 있는 버그를 미리 확인하고, 치명적인 영향이 없는 영역에 한정해서 써야 할 필요성 느낌

    • 나 역시 ‘중요한 작업’에서는 10~20% 정도의 개선을 체감함. 진짜 변화긴 하지만 소프트웨어 개발의 본질을 바꾸진 않음. 결국 Brooks의 "No Silver Bullet"(은탄환은 없다) 명제의 재확인

    • 나 역시 "중간급 기술 폭풍" 논점에 동의함. 특히 컨설팅 업계에선 베테랑이 비용 대비 가치가 낮게 취급되곤 하는 현실임. 예전엔 나도 빠르게 작업하는 쪽이었고, 나중에는 비전문가 PM에게 단기적인 해결책의 약점을 설명하느라 힘들었던 경험 있음. 대형 IT 기업은 이런 문제를 빠르게 잡아내겠지만, 현실적으로 금융, 의료 데이터를 다루는 코드는 값싼 단기 계약 인력으로 짜임. 이런 상황은 LLM 등장 전에도 문제였음. 지금은 보안 민감한 개발자들에게 훨씬 더 힘든 시대일 것

    • 생성 코드에서 미묘한 버그를 발견했다고 했는데, 그런 버그를 AI가 생성한 테스트 코드로 자동 검출하면 어떨지 생각됨. 물론 테스트 코드 자체도 버그가 있을 수 있지만, 미래에는 생성 코드보다 테스트 결과만 집중적으로 검토하게 될지도 모를 시나리오가 머리에 그려짐

    • 복잡한 병렬 처리라 했는데, 그건 partition과 consumer-group 활용으로 해결할 수 있는 영역 아닐지 의문 제기

  • LLM을 적극적으로 신뢰하며 ‘절벽에서 떨어지듯’ 무비판적으로 기대고 일하는 사람들을 보면 속이 답답해짐. 완전히 블랙박스에 의존해서 작업하고 검증까지 다 맡기는 건 위험함. 게다가 어마어마한 에너지를 소모하는 구조여서, 사람을 대체하는 핑계로 사용되기도 함. 이런 환경이 인생을 10배 좋게 만든다는 건 솔직히 믿음이 가지 않음

  • 직접 개발했을 때와 남이 만든 결과물(특히 LLM산 코드)을 검증하는 과정을 비교할 때, 인간은 종종 그럴듯한 겉모습에 속아 문제점을 덜 비판적으로 받아들이는 경향이 있음. 코드의 ‘모양새’도 버그 찾기에 큰 영향을 끼침. 이를 검증하려면 코드에 버그를 일부러 끼워넣고 코드 리뷰어들이 이를 찾는지 실험해보는 것도 방법임. 직접 손으로 뭔가를 구현하면 훨씬 더 천천히, 치밀하게 생각하게 되고 세부 사항을 신경 쓰게 됨(그래서 예상치 못한 버그도 발견함). 그래서 학습 목적으론 툴을 직접 ‘토이 버전’으로 짜보는 방법이 가장 좋다고들 추천하는 것임. 인간의 인지 구조와 연결된 이야기임

    • 표면적으로 깔끔해 보이는 코드에서 미묘한 버그를 찾아내는 능력은 많은 리뷰 경험에서 비롯된 냉소와 의심으로부터 나옴. 나 스스로 오랜 시간 리뷰에 할애하다 보니 이제는 무슨 코드든 항상 잠재적 문제를 상정하게 됨. 직접 짠 코드라면 버그가 줄었을지는 모르지만, 내가 직접 작성해도 멍청한 실수를 한 적 많기 때문에 장담은 못함. 오히려 내가 직접 이 라이브러리를 썼을 확률은 낮음(할 일이 너무 많아서 주로 주니어 엔지니어에게 넘어감). 결국 인간이 짠 코드라고 해도 버그가 사라지지는 않는다는 점은 확신함. 오히려 Claude가 만든 많은 버그는 사람이 충분히 저지를 만한 전형적인 수준임. 한편, 지금 시점에서 Cloudflare에서는 LLM 때문에 개발자가 대체되지는 않을 것으로 봄. 인력을 더 뽑는 건 할 일의 양이 아니라 예산이 좌우함. LLM 덕분에 생산성이 오르면 매출 상승이 가능해지고, 더 많은 사람을 채용하는 흐름이 만들어질 수 있음. (물론, 이건 회사 공식 입장이 아닌 개인적 의견임)

  • 기사에서는 불필요한 주석이 많지 않다고 했지만, 실제 코드엔 ‘// Get the Origin header from the request’와 같은 의미 없는 주석이 있음

    • 이런 주석은 LLM을 쓴 티가 나는 증거로, 아무런 의미가 없어 항상 지움

    • 사람한테는 이런 주석이 쓸모 없지만, LLM 입장에서 아래 코드의 기능이 자연어로 같이 기술되어 있으면 이해에 도움이 되는 일종의 로제타 스톤 역할을 할 수도 있다고 추측함. 토큰 소모가 늘어나는 대가일 수 있지만, 실제 LLM이 과도하게 주석 많은 코드에서 더 나은 편집을 하는지 검증해보고 싶기도 함

    • Claude가 이런 쓸모없는, 중복되는 주석을 엄청나게 자주 작성하는 경향이 있다는 경험 공유

  • 제안하고 싶은 건, 코드의 한 branch를 동결해놓고, AI들을 사용해서 한쪽은 취약점을 만들고 숨기려 노력하고, 또 다른 쪽은 이를 찾고 고치는 역할로 배틀하는 실험임. 즉, 체스의 진화 과정을 코드 개발에도 적용해보는 것임

  • 내가 바로 이 라이브러리의 작성자임(정확히는 프롬프트 작성자). Neil만큼은 아니어도 OAuth에 대해 어느 정도는 전문가지만, 그가 코드 리뷰를 해줘서 정말 기쁨. “YOLO CORS” 관련해서 오해가 있었는데, 이건 단순한 초보 실수로 한 게 아님. 이 CORS 설정들은 심사숙고해서 의도적으로 한 것임. OAuth API(토큰 교환, 클라이언트 등록) 엔드포인트와 OAuth bearer token이 필요한 API 엔드포인트에서만 CORS를 비활성화함. 이 엔드포인트들은 브라우저 자격 증명(쿠키 등)으로 인증되지 않아서, 실제로 CORS가 보호하는 것이 아무것도 없다는 판단임. CORS의 본질은 자격 증명을 자동으로 첨부시키지 않는 보안막인데, bearer token은 클라이언트가 명시적으로 첨부해야 하므로 크로스 오리진에서도 안전함. 실제로 나는 예전부터 CORS 스펙 작성자와 논쟁한 경험이 있는데, 브라우저 자격 증명 대신 bearer token을 써야 진짜 안전하다고 주장해왔음. 한편, token ID 생성이 비효율적이라는 지적에 대해선 ‘치명적’까진 아니라고 봄. 보안성 자체는 문제가 없고, 알고리즘을 이후에 자유롭게 바꿀 수 있기 때문임. commit이 한 명에 의해 한 날에 21개 main에 올라간 부분은, git 히스토리 리라이팅 때문에 github에서 날짜가 왜곡돼 나타난 것임. 암호화 구현 칭찬은 정말 고마움. 이건 AI가 만든 게 아니라 내 explicit한 설계 지시가 있었기 때문임

    • "OAuth API에서는 CORS 헤더를 disable한다"고 했는데, 실제로는 CORS 규칙을 비활성화하도록 CORS 헤더를 설정하는 것임. 맥락상 충분히 드러나긴 하지만, 혼동될 수 있으니 보충 설명

    • Cloudflare가 이 라이브러리를 실제 운영에 쓸 계획이 있는지 궁금증

  • 인기 Stack Overflow 답변에도 똑같은 실수가 많고, Claude도 그런 데서 배웠을 걸 생각하면 걱정됨. 보안 구멍이나 실수 자체보다 사회 전반의 지식수가 LLM 등장 이전의 인터넷 인기 답변에서 고정될 수 있다는 점이 특히 무서움

    • 나도 마찬가지로 걱정됨. 사용 중인 일부 서비스에서 “코드 작성에 LLM을 사용하지 않는다”는 점을 공개적으로 밝힌다면 큰 신뢰 포인트가 될 것임

  • ForgeRock에서 OAuth 실장에 수백 개의 보안 버그가 있었고, 수십만 개의 자동화 테스트, 위협 모델링, 최고 수준 SAST/DAST, 전문가 리뷰 등을 모두 해도 이런 결과였음을 보며, OAuth가 정말 까다롭다는 걸 새삼 실감함. 일부에서는 ‘쓰레기장 불’ 같은 구현체라고도 함. 정작 나는 스펙을 읽거나 구현해본 적은 없음

    • Oauth 구현 관여 경험이 있을 때마다 항상 끔찍하게 복잡했다는 체감

    • Oauth는 정말 귀찮고, 너무 많은 니치가 존재함

    • 사실 새로 짠 코드는 항상 버그가 있게 마련임. 복잡할수록 더 확실함. 그래서 기업들은 ‘battle tested(이미 현장에서 검증된)’ 코드와 도구를 쓰려고 함. 농담은 차치하고, Anthropic이 자기네 생성 AI를 자기 코드에 실용적으로 쓰는 방식은 흥미로움. 앞으로 MCP 인증 API에도 사용할지 궁금함

    • “수십만 개의 테스트”란 건 양적 성장일 수밖에 없거나, outright LLM이 만든 거 아닐까 의심됨. 실제로 그걸 누가 관리하는지도 궁금함

  • 사람들이 자신의 프롬프트를 git에 커밋하는 추세가 일반화될지, 아니면 그냥 showcase 성격인지 궁금함

    • 내가 프롬프트를 커밋한 이유는, LLM이 그런 프롬프트로 어떤 결과를 만들어내는지 직접 확인하는 게 너무 큰 인사이트였기 때문임. 다른 사람들도 흥미롭게 볼 거라 생각했고 실제로 그랬음. 참고로, 나도 프롬프트를 ‘잘’ 쓰는 방법은 몰랐고, 그냥 내가 인간 상대로 쓸 때처럼 자연스럽게 적었는데 잘 작동한 느낌임
답변달기