curl

2 개의 포스트

aws4분 읽기큐레이션 요약

Amazon Bedrock에서 OpenAI GPT-5.5, GPT-5.4 모델 및 Codex 시작하기 | Amazon Web Services

OpenAI GPT-5.5·GPT-5.4와 Codex가 Amazon Bedrock에서 정식 제공되어, Responses API를 통해 추론·코딩·에이전트 작업을 수행할 수 있게 되었습니다. GPT-5.5는 최고 난도의 작업에, GPT-5.4는 가격 대비 성능이 중요한 작업에 적합합니다. 모든 처리는 선택한 Bedrock 리전 내에서 수행되며, 좌석 라이선스 없이 토큰 사용량 기준으로 과금됩니다. ## Amazon Bedrock에서 제공되는 모델과 Codex - GPT-5.5와 GPT-5.4는 코딩, 추론, 에이전트 워크플로, 복잡한 전문 업무에 최적화되어 있습니다. - GPT-5.5는 가장 어려운 고객 업무를 위한 고성능 모델입니다. - GPT-5.4는 성능과 비용의 균형을 중시하는 용도에 적합합니다. - OpenAI의 코딩 에이전트인 Codex도 Bedrock에서 사용할 수 있습니다. - 대규모 코드베이스 작성, 리팩터링, 디버깅, 테스트, 검증 지원 - Codex App, CLI, Visual Studio Code·JetBrains·Xcode 통합 제공 - 모든 모델 추론은 Amazon Bedrock의 Responses API를 통해 처리 ## Responses API를 통한 모델 호출 - OpenAI SDK, `curl` 등으로 Bedrock의 `bedrock-mantle` 엔드포인트를 호출할 수 있습니다. - Python SDK 설치: ```bash pip install -U openai ``` - 인증 및 엔드포인트 환경 변수 설정: ```bash export OPENAI_BASE_URL="https://bedrock-mantle.us-east-2.api.aws/openai/v1" export OPENAI_API_KEY="<BEDROCK_API_KEY>" export BEDROCK_OPENAI_MODEL_ID="openai.gpt-5.5" ``` - Python에서는 `client.responses.create()`를 사용합니다. - 요청에 다음과 같은 설정을 지정할 수 있습니다. - `reasoning.effort`: 추론 수준 - `text.verbosity`: 응답의 상세도 - `developer` 메시지: 모델의 역할과 응답 지침 - 예시에서는 AWS 지식이 풍부한 소프트웨어 엔지니어 역할을 부여하고, 여러 리전에 걸친 초당 10만 요청 규모의 AWS 아키텍처를 생성하도록 요청합니다. - `curl`을 사용하면 `/responses` 엔드포인트에 JSON 요청을 직접 전송할 수 있습니다. ## Responses API가 적합한 경우 - 모델이 여러 턴의 대화 상태를 관리해야 할 때 - 호스팅 도구나 함수 도구를 사용해야 할 때 - 여러 도구를 조합하는 복잡한 오케스트레이션이 필요할 때 - 백그라운드 작업이나 장시간 실행되는 작업을 처리할 때 ## Codex를 Bedrock에 연결하는 방법 - Codex CLI, Codex App 또는 VS Code 확장을 설치해 Bedrock을 모델 추론 경로로 사용할 수 있습니다. - 두 가지 인증 방식을 지원합니다. - `AWS_BEARER_TOKEN_BEDROCK`에 Bedrock API 키 설정 - AWS SDK 자격 증명 체인 사용 - `AWS_BEARER_TOKEN_BEDROCK`가 설정되어 있으면 Codex가 이를 우선 사용하고, 없으면 AWS SDK 자격 증명 체인으로 전환합니다. ```bash export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key> ``` - `~/.codex/config.toml`에서 리전과 모델 제공자를 설정합니다. ```toml model = "openai.gpt-5.5" model_provider = "amazon-bedrock" [model_providers.amazon-bedrock.aws] region = "us-east-2" ``` - 사용할 수 있는 모델 ID에는 다음이 포함됩니다. - `openai.gpt-5.5` - `openai.gpt-5.4` - `openai.gpt-oss-120b` - `openai.gpt-oss-20b` - 데스크톱 앱이나 VS Code 확장에서 사용할 환경 변수는 `~/.codex/.env`에 저장할 수 있습니다. - 설정 파일을 변경한 뒤에는 앱이나 확장을 재시작해야 합니다. - Codex CLI에서는 `/status` 명령으로 현재 모델과 연결 상태를 확인할 수 있습니다. ## 지연 시간과 확장성 - 실제 사용자가 느끼는 지연 시간은 모델의 기본 속도뿐 아니라 다음 요소의 영향을 받습니다. - 추론 수준 - 출력 길이 - 도구 호출 횟수 - 백그라운드 실행 여부 - 리전 및 할당량 - 요청 제한(throttling) - 프롬프트 크기 - 캐시 적중 여부 - GPT-5.5는 우선 `reasoning.effort="medium"`으로 시작하는 것이 권장됩니다. - GPT-5.4는 기본값인 `none`에 의존하기보다 애플리케이션 요구사항에 맞춰 추론 수준을 명시하는 것이 좋습니다. - Bedrock의 차세대 추론 엔진은 수요 변화에 맞춰 용량을 빠르게 확보하도록 설계되었습니다. - 수요가 급증하면 요청을 즉시 거부하기보다 큐에 넣어 처리하는 방식으로 안정적인 워크로드 운영을 지원합니다. ## 리전, 데이터 보존, 과금 - 고객이 선택한 Bedrock 리전 내에서 모든 처리가 이루어지므로 데이터 레지던시 요구사항을 충족할 수 있습니다. - 제공 리전은 다음과 같습니다. - GPT-5.5: 미국 동부(오하이오) - GPT-5.4: 미국 동부(오하이오), 미국 서부(오리건) - 향후 지원 리전은 AWS의 전체 리전 목록에서 확인할 수 있습니다. - 개발자 좌석 라이선스나 인원별 약정 없이 토큰 사용량 기준으로 과금됩니다. 실무에서는 먼저 GPT-5.5를 중간 추론 수준으로 테스트하고, 비용과 성능의 균형이 중요하면 GPT-5.4와 명시적인 추론 설정을 비교하는 것이 좋습니다. Codex를 사용할 때는 리전, 인증 방식, 모델 ID를 설정 파일에 고정하고 `/status`로 연결 상태를 확인하면 운영 중 문제를 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)
gitlab원문

19.0 Omnibus-GitLab FIPS 패키지에서 curl 제거 (새 탭에서 열림)

GitLab은 2026년 5월 출시 예정인 19.0 버전부터 Omnibus-GitLab FIPS 패키지 내부에 자체 빌드하여 포함하던 `curl`을 제거합니다. 앞으로 FIPS 환경의 사용자들은 GitLab이 제공하는 번들 대신 사용 중인 Linux 배포판의 `curl` 패키지를 직접 활용하게 되며, 이는 기존의 OpenSSL 라이브러리 관리 방식과 동일한 모델로 통합되는 것입니다. 이번 변경을 통해 GitLab은 패키지 유지보수의 효율성을 높이고, OS 수준의 암호화 라이브러리와의 호환성을 강화하고자 합니다. ### 기술적 배경 및 변경 사유 * **OpenSSL 1.x 지원 중단:** 최신 버전인 `curl 8.18.0`부터 OpenSSL 1.x 환경에서의 컴파일 지원이 중단되었습니다. 이로 인해 Amazon Linux 2나 AlmaLinux 8(RHEL 8 기반)과 같이 구형 라이브러리를 사용하는 환경에서 기존 방식의 패키징을 지속하기 어려워졌습니다. * **FIPS 관리 모델의 일관성:** FIPS 패키지는 이미 배포판의 암호화 라이브러리를 링크하여 사용하고 있습니다. `curl` 또한 이와 동일한 방식으로 전환함으로써 보안 및 관리 모델의 일관성을 확보합니다. * **유지보수 및 보안 강화:** OpenSSL 3.0 이상을 사용하는 최신 배포판을 포함한 모든 FIPS 패키지에 이 변경 사항을 적용하여 전체적인 보안 관리 체계를 개선합니다. ### 적용 대상 및 일정 * **적용 시점:** 2026년 5월 21일 출시되는 GitLab 19.0 버전 및 이후의 패치 릴리스부터 적용됩니다. * **영향 범위:** 모든 Omnibus-GitLab FIPS 패키지 사용자가 대상입니다. * **사용자 조치:** GitLab 인스턴스 자체의 동작 방식은 변하지 않으므로 즉각적인 기능 설정 변경은 필요하지 않으나, 시스템 환경에 대한 점검이 권장됩니다. ### 보안 관리 책임의 변화 * **보안 업데이트 주체 변경:** 이제 GitLab은 FIPS 패키지용 `curl`의 보안 패치를 직접 배포하지 않습니다. 사용자는 운영체제(OS)에서 제공하는 업데이트를 통해 `curl`의 최신 보안 상태를 유지해야 합니다. * **취약점 스캐닝 결과:** 보안 스캐너는 더 이상 GitLab 번들 버전이 아닌, 호스트 OS에 설치된 `curl` 패키지를 기준으로 취약점을 식별하게 됩니다. FIPS 환경에서 GitLab을 운영 중인 관리자는 19.0 업데이트 이후 `curl` 관련 보안 취약점 대응이 운영체제 패키지 관리 프로세스에 포함되도록 관리 절차를 재점검해야 합니다. 특히 시스템 보안 스캔 결과가 OS 패키지 상태를 반영하게 되므로, 정기적인 OS 업데이트를 통해 최신 보안 패치를 적용할 것을 권장합니다.