# Claude API가 CORS 지원을 시작, 클라이언트 측 어플리케이션이 가능해짐

> Clean Markdown view of GeekNews topic #16433. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16433](https://news.hada.io/topic?id=16433)
- GeekNews Markdown: [https://news.hada.io/topic/16433.md](https://news.hada.io/topic/16433.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-08-24T09:31:01+09:00
- Updated: 2024-08-24T09:31:01+09:00
- Original source: [simonwillison.net](https://simonwillison.net/2024/Aug/23/anthropic-dangerous-direct-browser-access/)
- Points: 7
- Comments: 1

## Summary

Anthropic이 JSON API에 대한 CORS 지원을 활성화하여 사용자의 브라우저에서 직접 Claude LLM을 호출할 수 있게 되었습니다. 이로 인해 신뢰할 수 있는 사용자에게 노출되는 회사 내부용 도구나 사용자가 자신의 API 키를 제공하는 "BYOK" 패턴을 구현하는 클라이언트 측 앱 개발이 용이해졌습니다.

## Topic Body

- Anthropic이 JSON API에 대한 CORS 지원을 활성화함  
  - 즉, 이제 사용자의 브라우저에서 직접 Claude LLM을 호출할 수 있음  
- 이 기능은 "anthropic-sdk-typescript: add support for browser usage" PR에 숨겨져 있음  
  - 뒤져보니, 해당 코드에 대한 Anthropic TypeScript SDK의 변경 사항은 새로운 JSON API 기능을 보여줌  
- 다음 HTTP 요청 헤더를 추가하여 Anthropic API에 대한 CORS 지원을 활성화 가능:  
  `anthropic-dangerous-direct-browser-access: true`  
- 이 헤더를 추가하면 브라우저에서 직접 Anthropic 모델에 대한 호출을 할 수 있음  
- API 키를 클라이언트 코드에 포함하면 해당 사이트에 액세스할 수 있는 사용자가 API 키를 훔쳐 대신 요청을 할 수 있기 때문에 Anthropic은 이 기능 추가를 꺼려왔음  
- 그럼에도 불구하고 이 기능에 대한 괜찮은 유스케이스가 몇 가지 있음  
  - 신뢰할 수 있는 사용자에게 노출되는 회사 내부용 도구에는 괜찮음  
  - 또는 사용자가 클라이언트 측 앱에서 사용할 자신의 키를 제공하는 "BYOK(Bring Your Own Key)" 패턴을 구현도 가능   
  
### Haiku - 클라이언트측 앱 예제  
- 간단히 만들어본 Haiku 페이지는 CORS 지원이 필요한 클라이언트 측 앱 예제   
- 웹캠에 대한 액세스를 요청하고, Anthropic API 키를 요청한 다음(브라우저의 localStorage에 저장), 사진을 찍고 Haiku 모델을 사용하여 하이쿠로 바꾸는 간단한 앱임  
- 이전에는 Vercel에서 자체 프록시를 실행하여 Anthropic API에 CORS 지원을 추가해야 했음  
- 이제 새 헤더를 보내도록 앱을 업그레이드했고, 프록시 없이 Anthropic과 직접 통신할 수 있음  
  
```javascript  
fetch("https://api.anthropic.com/v1/messages", {  
  method: "POST",  
  headers: {  
    "x-api-key": apiKey,  
    "anthropic-version": "2023-06-01",   
    "content-type": "application/json",  
    "anthropic-dangerous-direct-browser-access": "true",  
  },  
  body: JSON.stringify({  
    model: "claude-3-haiku-20240307",  
    max_tokens: 1024,  
    messages: [  
      {  
        role: "user",  
        content: [  
          { type: "text", text: "Return a haiku about how great pelicans are" },  
        ],  
      },  
    ],  
  }),  
})  
  .then((response) => response.json())  
  .then((data) => {  
    const haiku = data.content[0].text;  
    alert(haiku);  
  });  
```

## Comments



### Comment 28247

- Author: xguru
- Created: 2024-08-24T09:52:34+09:00
- Points: 1

#### [Hacker News 의견](https://news.ycombinator.com/item?id=41325889)   
  
- 개인적으로 사용자가 자신의 키를 가져오는 웹 앱을 만드는 것을 좋아함  
  - 이 접근 방식은 실행 파일 배포의 편리함과 오픈 소스의 이점을 결합함  
  - 두 가지 웹 앱을 개발해봤음  
    - 마이크 입력을 사용하는 실시간 전사 및 번역 앱  
    - SRT 자막을 다양한 언어로 번역하는 앱  
  - "사용자 키 가져오기" 모델을 선택하는 두 가지 주요 이유  
    - 낮은 유지보수: 많은 소프트웨어를 유지 보수하고 있어 사이드 프로젝트를 유지보수하고 싶지 않음  
    - 낮은 비용: 광고 없이 앱을 배포할 수 있으며, 운영 비용을 낮출 수 있음  
  - 유지보수 부담과 사용자 비용을 최소화하면서 유용한 도구를 만들고 공유할 수 있음  
  
- 사용자가 자신의 키를 가져오는 상황에서는 문제가 되지 않음  
  - 클라이언트 측에서 작업이 이루어지며, 장치나 웹사이트가 손상되지 않는 한 괜찮음  
  - 그러나 개발자가 생산 키를 클라이언트 측에서 사용하는 경우 공격 표면이 증가할 수 있음  
  - 편의성과 성능을 이유로 보안 고려 없이 이 작업을 수행할 수 있음  
  
- JWT를 지원하지 않는 이유를 이해하지 못함  
  - Supabase는 안전한 클라이언트 측 접근을 제공하는 좋은 예시임  
  
- Anthropic과 모든 AI 벤더는 "Login with ___" 기능을 구현해야 함  
  - 사용자가 자신의 AI 리소스를 신뢰할 수 있도록 해야 함  
  - 대부분의 사용자는 API 키를 생성하고 로드하는 것을 번거로워하며 안전하게 관리할 수 없음  
  
- 사용자가 자신의 키를 가져오는 경우 OAuth가 더 나은 솔루션임  
  - 일부 개발자는 실제 키를 프론트엔드에 하드코딩하고 어려움을 겪을 수 있음  
  - OAuth는 더 안전한 솔루션임  
  
- 내부 개발에는 적합할 수 있지만 사용자 대상 앱에는 적합하지 않음