보안 바이브 체크 통과: 바이브 코딩의 위험성

소개

Databricks에서는 우리의 AI Red Team이 새로운 소프트웨어 패러다임이 예상치 못한 보안 위험을 어떻게 도입할 수 있는지를 정기적으로 탐색합니다. 우리가 최근에 밀접하게 추적하고 있는 추세 중 하나는 "vibe coding"이라는, 생성 AI를 빠르고 캐주얼하게 사용하여 코드를 구축하는 것입니다. 이 방법은 개발을 가속화시키지만, 또한 미묘하고 위험한 취약점을 도입할 수 있으며, 이는 너무 늦게까지 눈치채지 못하는 경우가 많습니다.

이 글에서는 우리의 레드팀 활동에서 얻은 실제 예시를 통해 바이브 코딩이 어떻게 심각한 취약점을 초래할 수 있는지 살펴봅니다. 또한 이러한 위험을 완화할 수 있는 실천 방법을 제시합니다.

Vibe 코딩의 잘못된 접근: 멀티플레이어 게임

vibe coding 위험성을 탐색하는 초기 실험 중 하나에서, 우리는 Claude에게 사용자가 마우스를 사용하여 위에서 보는 카메라 시점에서 뱀을 제어하는 세 번째 인물 뱀 전투 아레나를 만들라고 요청했습니다. vibe-coding 방법론에 따라, 우리는 모델에 프로젝트의 구조에 대한 상당한 제어권을 허용하고, 각 구성 요소를 생성하도록 점진적으로 요청했습니다. 비록 결과적으로 생성된 애플리케이션은 의도한 대로 작동했지만, 이 과정은 심각한 보안 취약점을 우연히 도입했고, 이를 검사하지 않으면 임의의 코드 실행으로 이어질 수 있었습니다.

취약점

뱀 게임의 네트워크 계층은 Python 객체를 pickle을 사용하여 직렬화하고 역직렬화하며, 이 모듈은 임의의 원격 코드 실행 (RCE)에 취약하다고 알려져 있습니다. 결과적으로, 악의적인 클라이언트 또는 서버는 임의의 코드를 실행하는 페이로드를 만들어 게임의 다른 인스턴스에서 보낼 수 있습니다.

아래의 코드는 Claude가 생성한 네트워크 코드에서 직접 가져온 것으로, 네트워크에서 받은 객체가 검증이나 보안 검사 없이 직접 역직렬화되는 문제를 명확하게 보여줍니다.

이런 종류의 취약점은 고전적이고 잘 문서화되어 있지만, vibe 코딩의 특성상 생성된 코드가 "그냥 작동"하는 것처럼 보일 때 잠재적인 위험을 간과하기 쉽습니다.

그러나 클로드에게 코드를 안전하게 구현하도록 요청함으로써, 우리는 모델이 다음과 같은 보안 문제를 적극적으로 식별하고 해결하는 것을 관찰했습니다:

아래 코드 발췌문에서 볼 수 있듯이, 이 문제는 데이터 직렬화를 위해 pickle에서 JSON으로 전환함으로써 해결되었습니다. 서비스 거부 공격을 방지하기 위해 크기 제한도 도입되었습니다.

ChatGPT와 메모리 손상: 바이너리 파일 파싱

다른 실험에서, 우리는 ChatGPT에게 GGUF 이진 형식에 대한 파서를 생성하도록 요청했는데, 이 형식은 안전하게 파싱하기 어렵다고 널리 인식되고 있습니다. GGUF 파일은 C와 C++로 구현된 모듈에 대한 모델 가중치를 저장하며, 우리는 이 형식을 Databricks가 공식 GGUF 라이브러리에서 여러 취약점을 발견한 적이 있기 때문에 특별히 선택했습니다.

ChatGPT는 파일 파싱과 메타데이터 추출을 올바르게 처리하는 작동 구현을 빠르게 만들었으며, 이는 아래의 소스 코드에서 확인할 수 있습니다.

그러나 더 자세히 살펴보니, 안전하지 않은 메모리 처리와 관련된 중요한 보안 결함을 발견했습니다. 생성된 C/C++ 코드에는 확인되지 않은 버퍼 읽기와 형식 혼동의 사례가 포함되어 있었으며, 이들은 모두 악용될 경우 메모리 손상 취약점을 초래할 수 있습니다.

이 GGUF 파서에서는 검사되지 않은 입력과 안전하지 않은 포인터 산술로 인해 여러 메모리 손상 취약점 이 존재합니다. 주요 문제점은 다음과 같습니다:

1. GGUF 파일에서 정수나 문자열을 읽을 때 충분한 경계 검사가 이루어지지 않음 이러한 문제는 파일이 잘려나가거나 악의적으로 조작되었을 경우 버퍼 오버리드나 버퍼 오버플로우를 초래할 수 있습니다.
2. 안전하지 않은 메모리 할당, 예를 들어 검증되지 않은 키 길이에 1을 더해 메타데이터 키에 대한 메모리를 할당하는 것. 이 길이 계산은 정수 오버플로우를 일으켜 힙 오버플로우를 초래할 수 있습니다.

공격자는 가짜 헤더, 키 또는 값 필드에 대한 매우 크거나 음수의 길이, 그리고 임의의 페이로드 데이터를 가진 GGUF 파일을 조작하여 이 문제 중 두 번째를 악용할 수 있습니다. 예를 들어, 키 길이가 0xFFFFFFFFFFFFFFFF (최대 부호 없는 64비트 값)인 경우, 검사되지 않은 malloc() 이 작은 버퍼를 반환하지만, 이후 memcpy() 는 여전히 그 이후에 쓰여서 전형적인 힙 기반 버퍼 오버플로우를 일으킵니다. 마찬가지로, 파서가 유효한 문자열이나 배열 길이를 가정하고 메모리에 읽어들이는데 사용 가능한 공간을 검증하지 않으면 메모리 내용이 유출될 수 있습니다. 이런 결함들은 임의의 코드 실행을 달성하는 데 사용될 수 있습니다.

이 문제를 검증하기 위해, 우리는 ChatGPT에 악의적인 GGUF 파일을 생성하고 취약한 파서에 전달하는 증거 개념을 생성하도록 요청했습니다. 결과 출력은 프로그램이 매핑된 메모리 페이지의 끝에 도달하고 그 이후에 매핑되지 않은 페이지에 쓰려고 할 때, 경계를 벗어난 메모리 접근으로 인해 세그멘테이션 오류를 일으키며, 이는 memmove 함수 내에서 프로그램이 충돌하는 것을 보여줍니다. 프로그램이 매핑된 메모리 페이지의 끝에 도달하고 그 이후의 매핑되지 않은 페이지에 쓰려고 할 때 충돌이 발생합니다. 이는 경계를 벗어난 메모리 접근으로 인해 세그멘테이션 오류를 유발합니다.

다시 한번 우리는 ChatGPT에게 코드를 수정하는 데 대한 제안을 요청했고, 그것은 다음과 같은 개선 사항을 제안할 수 있었습니다:

그런 다음 우리는 업데이트된 코드를 가져와서 개념 증명 GGUF 파일을 전달했고, 코드는 변형된 레코드를 감지했습니다.

다시 말해, 핵심 문제는 ChatGPT가 기능적인 코드를 생성하는 능력이 아니라, 바이브 코딩에 내재된 캐주얼한 접근 방식이 생성된 구현에서 위험한 가정을 눈치채지 못하게 했다는 것입니다.

보안 완화를 위한 프롬프팅

보안 전문가가 코드를 검토하여 취약점이 없는지 확인하는 것에 대한 대체제는 없지만, vibe 코딩 세션 동안 위험을 완화하는데 도움이 될 수 있는 몇 가지 실용적이고 소요 시간이 적은 전략들이 있습니다. 이 섹션에서는 코드의 보안성을 크게 향상시킬 수 있는 세 가지 간단한 방법을 설명합니다. 이 게시물에 제시된 각 프롬프트는 ChatGPT를 사용하여 생성되었음을 보여주며, 이는 어떤 바이브 코더라도 광범위한 보안 전문 지식 없이도 효과적인 보안 지향적 프롬프트를 쉽게 생성할 수 있음을 보여줍니다.

일반적인 보안 지향 시스템 프롬프트

첫 번째 방법은 일반적인, 보안 중심의 시스템 프롬프트를 사용하여 LLM을 처음부터 안전한 코딩 행동으로 유도하는 것입니다. 이러한 프롬프트는 기본 보안 지침을 제공하여 생성된 코드의 안전성을 향상시킬 수 있습니다. 우리의 실험에서는 다음과 같은 프롬프트를 사용했습니다:

언어 또는 애플리케이션 특정 프롬프트

프로그래밍 언어나 애플리케이션 컨텍스트가 미리 알려져 있을 때, 다른 효과적인 전략은 LLM에 맞춤형, 언어 특정 또는 애플리케이션 특정 보안 프롬프트를 제공하는 것입니다. 이 방법은 직접적으로 작업에 관련된 알려진 취약점이나 일반적인 함정을 대상으로 합니다. 눈에 띄는 것은, 이러한 취약성 클래스를 명시적으로 인식할 필요조차 없다는 것입니다. 왜냐하면 LLM 자체가 적절한 시스템 프롬프트를 생성할 수 있기 때문입니다. 우리의 실험에서, 우리는 ChatGPT에 다음의 요청을 사용하여 언어별 프롬프트를 생성하도록 지시했습니다:

보안 리뷰를 위한 자기성찰

세 번째 방법은 코드 생성 직후에 자기 반성적인 검토 단계를 포함하는 것입니다. 처음에는 특정 시스템 프롬프트를 사용하지 않지만, LLM이 코드 구성 요소를 생성하면 출력이 모델로 다시 입력되어 보안 취약점을 명확하게 식별하고 해결합니다. 이 접근법은 모델의 내재된 능력을 활용하여 처음에 놓칠 수 있는 보안 문제를 감지하고 수정하는 데 사용됩니다. 우리의 실험에서는 원래의 코드 출력을 사용자 프롬프트로 제공하고 다음 시스템 프롬프트를 사용하여 보안 검토 과정을 안내했습니다:

경험적 결과: 보안 작업에서 모델 행동 평가

각 프롬프팅 접근법의 효과를 정량적으로 평가하기 위해, 우리는 PurpleLlama의 사이버보안 벤치마크 테스트 스위트에서 보안 코딩 벤치마크를 사용하여 실험을 진행했습니다. 이 벤치마크에는 vibe 코딩 워크플로우와 직접적으로 관련된 시나리오에서 LLM이 안전하지 않은 코드를 생성하는 경향을 측정하기 위해 설계된 두 가지 유형의 테스트가 포함되어 있습니다.

• 명령 테스트: 모델은 명시적인 지시에 따라 코드를 생성합니다.
• 자동완성 테스트: 모델은 주어진 이전 컨텍스트에 따라 후속 코드를 예측합니다.

이 두 시나리오를 모두 테스트하는 것은 특히 유용합니다. 왜냐하면, 일반적인 vibe 코딩 세션 동안 개발자들은 종종 먼저 모델에게 코드를 생성하도록 지시한 다음, 문제를 해결하기 위해 이 코드를 모델에 다시 붙여넣는 것이므로, 이는 지시와 자동완성 시나리오를 밀접하게 반영하기 때문입니다. 우리는 Claude 3.7 Sonnet과 GPT 4o 두 모델을 Secure Coding Benchmark에 포함된 모든 프로그래밍 언어에서 평가했습니다. 다음 플롯은 시스템 프롬프트가 없는 기준 시나리오에 비해 각각의 세 가지 프롬프팅 전략에 대한 취약한 코드 생성률의 백분율 변화를 보여줍니다. 음수 값은 개선을 나타내며, 이는 프롬프트 전략이 불안전한 코드 생성률을 줄였음을 의미합니다.

Claude 3.7 Sonnet 결과

Claude 3.7 Sonnet으로 코드를 생성할 때, 제공된 세 가지 프롬프트 전략 모두 개선을 가져왔지만, 그 효과는 크게 달랐습니다:

• 자기 반성 이 전반적으로 가장 효과적인 전략이었습니다. 이는 명령 시나리오에서 평균 48%, 자동완성 시나리오에서 평균 50%의 불안전한 코드 생성률을 줄였습니다. Java, Python, C++과 같은 일반적인 프로그래밍 언어에서 이 전략은 취약성 비율을 대략 60%에서 80%까지 눈에 띄게 줄였습니다.
• 언어별 시스템 프롬프트 도 의미 있는 개선을 가져왔으며, 두 가지 평가 설정에서 평균적으로 37%와 24%의 불안전한 코드 생성을 줄였습니다. 거의 모든 경우에서 이러한 프롬프트는 일반적인 보안 시스템 프롬프트보다 더 효과적이었습니다.
• 일반적인 보안 시스템 프롬프트 는 평균적으로 16%와 8%의 적절한 개선을 제공했습니다. 그러나 다른 두 가지 접근법의 효과가 더 크기 때문에, 이 방법은 일반적으로 추천되는 선택이 아닐 것입니다.

자기 반성 전략이 취약점을 가장 크게 줄였지만, LLM이 생성하는 각 개별 컴포넌트를 검토하는 것은 때때로 어려울 수 있습니다. 이런 경우에는, 언어별 시스템 프롬프트를 활용하는 것이 더 실용적인 대안을 제공할 수 있습니다.

GPT 4o 결과

• 자기성찰 은 다시 한번 전반적으로 가장 효과적인 전략이었으며, 명령 시나리오에서 평균 30%, 자동완성 시나리오에서 평균 51%의 불안전한 코드 생성률을 줄였습니다.
• 언어별 시스템 프롬프트 도 매우 효과적이었으며, 두 시나리오에서 평균적으로 불안전한 코드 생성을 약 24% 줄였습니다. 눈에 띄는 것은, 이 전략이 때때로 GPT 4o를 사용한 명령 테스트에서 자기성찰을 능가했다는 것입니다.
• 일반적인 보안 시스템 프롬프트 는 Claude 3.7 Sonnet보다 GPT 4o와 더 잘 작동했으며, 명령 및 자동완성 시나리오에서 각각 평균 13%와 19%의 불안전한 코드 생성률을 줄였습니다.

전반적으로, 이러한 결과는 목표 지향적인 프롬프팅이 LLM으로 코드를 생성할 때 보안 결과를 향상시키는 실용적이고 효과적인 접근법임을 명확하게 보여줍니다. 프롬프팅만으로는 완전한 보안 솔루션이 아니지만, 코드 취약성을 줄이는 데 의미 있는 기여를 하며, 특정 사용 사례에 따라 쉽게 맞춤화하거나 확장할 수 있습니다.

보안 전략이 코드 생성에 미치는 영향

이러한 보안 중심의 프롬프팅 전략을 적용하는 실제적인 타협점을 더 잘 이해하기 위해, 우리는 그들이 LLM의 일반적인 코드 생성 능력에 미치는 영향을 평가했습니다. 이 목적을 위해, 우리는 HumanEval 벤치마크를 사용했는데, 이는 LLM의 기능적인 Python 코드를 자동완성 컨텍스트에서 생성하는 능력을 평가하기 위해 설계된 널리 인정받은 평가 프레임워크입니다.

위의 표는 시스템 프롬프트가 없는 기준선에 비해 각 보안 프롬프트 전략에 대한 HumanEval 성공률의 백분율 변화를 보여줍니다. Claude 3.7 Sonnet의 경우, 세 가지 완화 방법 모두 기준 성능을 일치시키거나 약간 향상시켰습니다. GPT 4o의 경우, 보안 프롬프트는 성능을 적당히 감소시켰지만, Python 특정 프롬프트는 기준 결과와 일치했습니다. 그러나 이러한 상대적으로 작은 차이에 비해 취약한 코드 생성을 크게 줄이는 이러한 프롬프팅 전략을 채택하는 것은 실용적이고 유익합니다.

에이전틱 코딩 어시스턴트의 부상

점점 더 많은 개발자들이 전통적인 IDE를 넘어서 새롭고, AI가 통합된 환경으로 이동하고 있습니다. 이 환경은 깊이 통합된 에이전트 지원을 제공합니다. Cursor, Cline, Claude-Code 와 같은 도구들이 이러한 신흥 파도의 일부입니다. 이들은 자동 완성을 넘어서 linters, 테스트 러너, 문서 파서, 심지어 런타임 분석 도구까지 통합하며, 이 모든 것을 LLM을 통해 조정하여 정적인 copilot 모델보다는 에이전트처럼 작동합니다.

이러한 보조 도구들은 전체 코드베이스에 대해 추론하고, 지능적인 제안을 하며, 실시간으로 오류를 수정하도록 설계되었습니다. 원칙적으로, 이런 상호 연결된 툴체인은 코드의 정확성과 보안성을 향상시켜야 합니다. 그러나 실제로는, 우리의 레드 팀 테스트에서 이러한 보조 도구가 복잡한 로직을 생성하거나 리팩토링하거나, 입력/출력 루틴을 처리하거나, 외부 API와 인터페이스할 때 보안 취약점이 여전히 존재함을 보여줍니다.

우리는 이전 분석과 유사한 보안 중심 테스트에서 Cursor를 평가했습니다. 처음부터 시작하여, 우리는 Claude 4 Sonnet에 다음과 같이 프롬프트했습니다: “메모리에서 파일을 로드하거나 쓸 수 있는 기능을 가진 C로 작성된 기본 GGUF 형식 파서를 작성해주세요.” 커서는 자동으로 웹을 탐색하여 형식에 대한 세부 정보를 수집한 후, 요청된 대로 GGUF 파일 I/O를 처리하는 완전한 라이브러리를 생성했습니다. 결과는 에이전트 플로우 없이 생성된 코드보다 훨씬 더 견고하고 포괄적이었습니다. 그러나 코드의 보안 자세를 검토하는 동안, 아래에 표시된 read_str() 함수에 존재하는 것을 포함하여 여러 취약점이 발견되었습니다.

여기서, str->n 속성은 GGUF 버퍼에서 직접 채워지고, 검증 없이 힙 버퍼를 할당하는 데 사용됩니다. 공격자는 이 필드에 대해 최대 크기 값을 제공할 수 있으며, 이 값이 1씩 증가하면 정수 오버플로우로 인해 0으로 감싸집니다. 이로 인해 malloc() 이 성공하며, 최소한의 할당을 반환합니다(할당자의 동작에 따라 다름), 이는 이후의 memcpy() 작업에 의해 오버런되어, 전형적인 힙 기반 버퍼 오버플로우를 초래합니다.

완화 방안

중요한 것은, 이전에 이 글에서 살펴본 동일한 완화 방법들: 보안 중심의 프롬프트, 자기 반성 루프, 애플리케이션 특정 가이드라인이 이러한 환경에서도 취약한 코드 생성을 줄이는 데 효과적이었다는 것입니다. 당신이 독립적인 모델에서 vibe 코딩을 하든, 전체 에이전트 IDE를 사용하든, 의도적인 프롬프트와 생성 후 검토는 출력물을 보호하는 데 필요합니다.

자기 반성

Cursor IDE 내에서 자기 반성을 테스트하는 것은 간단했습니다: 우리는 단순히 이전의 자기 반성 프롬프트를 채팅 창에 직접 붙여넣었습니다.

이는 에이전트가 코드 트리를 처리하고 취약점을 찾기 위해 반복하고, 식별된 취약점을 수정하기 전에 코드 트리를 처리하도록 트리거했습니다. 아래의 diff는 이 과정의 결과를 우리가 이전에 논의한 취약점과 관련하여 보여줍니다.

.cursorrules 활용 기본적으로 안전한 생성을 위해

Cursor의 더 강력하지만 잘 알려지지 않은 기능 중 하나는 .cursorrules 를 지원하는 것입니다. 소스 트리 내의 파일. 이 구성 파일은 개발자가 코딩 도우미에 대한 사용자 정의 지침이나 행동 제약을 정의하게 해주며, 코드가 생성되거나 리팩토링되는 방식에 영향을 미치는 언어 특정 프롬프트를 포함합니다.

이 기능이 보안 결과에 미치는 영향을 테스트하기 위해, 우리는 .cursorrules 파일을 만들어서, 위에서 언급한 우리의 이전 작업에 따라 C 특정 안전 코딩 프롬프트를 포함시켰습니다. 이 프롬프트는 안전한 메모리 처리, 경계 검사, 그리고 신뢰할 수 없는 입력의 검증을 강조했습니다.

프로젝트의 루트에 파일을 놓고 Cursor에게 GGUF 파서를 처음부터 다시 생성하도록 요청한 후, 원래 버전에 존재했던 많은 취약점들이 미리 피해졌다는 것을 발견했습니다. 특히, 이전에 검사되지 않았던 값들이 str->n 과 같이 사용하기 전에 검증되었고, 버퍼 할당이 크기를 확인하였으며, 안전하지 않은 함수의 사용이 더 안전한 대안으로 대체되었습니다.

비교를 위해, 여기에 파일에서 문자열 유형을 읽기 위해 생성된 함수가 있습니다.

이 실험은 중요한 점을 강조합니다: 보안 코딩 기대치를 직접 개발 환경에 코딩함으로써, Cursor와 같은 도구는 기본적으로 더 안전한 코드를 생성할 수 있습니다. 이는 반응적인 리뷰의 필요성을 줄입니다. 이것은 또한 이 포스트의 더 넓은 교훈을 강화합니다. 즉, 의도적인 프롬프팅과 구조화된 가드레일은 더 복잡한 에이전트 워크플로우에서도 효과적인 완화책입니다.

그러나 흥미롭게도, 이런 방식으로 생성된 코드 트리에 위에서 설명한 자기 반성 테스트를 실행했을 때, Cursor는 생성 과정에서 놓친 일부 취약한 코드를 여전히 감지하고 수정할 수 있었습니다.

보안 도구 통합 (semgrep-mcp)

많은 에이전트 코딩 환경들이 이제 개발 및 리뷰 과정을 향상시키기 위해 외부 도구의 통합을 지원합니다. 이를 수행하는 가장 유연한 방법 중 하나는 Model Context Protocol (MCP)이라는 Anthropic에서 소개한 오픈 표준을 통한 것입니다. 이는 LLM이 코딩 세션 동안 구조화된 도구와 서비스와 인터페이스를 할 수 있게 합니다.

이를 탐구하기 위해, 우리는 Semgrep MCP 서버 의 로컬 인스턴스를 실행하고 이를 Cursor에 직접 연결했습니다. 이 통합은 LLM이 새로 생성된 코드에 대해 실시간으로 정적 분석 체크를 호출할 수 있게 하여, 안전하지 않은 함수 사용, 검사되지 않은 입력, 그리고 안전하지 않은 역직렬화 패턴과 같은 보안 문제를 드러냅니다.

이를 달성하기 위해, 우리는 다음 명령어로 로컬 서버를 실행했습니다: `uv run mcp run server.py -t sse` 그리고 다음 json을 파일 ~/.cursor/mcp.json:에 추가했습니다.

마지막으로, 우리는 프로젝트 내에 다음 프롬프트가 포함된 .customrules 파일을 생성했습니다: “semgrep 도구를 사용하여 생성된 모든 코드의 보안 스캔을 수행하십시오”. 이후에는 원래의 프롬프트를 사용하여 GGUF 라이브러리를 생성하였고, 아래 스크린샷에서 볼 수 있듯이 Cursor는 필요할 때 도구를 자동으로 호출합니다.

결과는 흥미롭습니다. Semgrep는 우리의 GGUF 파서의 초기 버전에서 여러 취약점을 성공적으로 플래그했습니다. 그러나 눈에 띄는 것은 semgrep 자동 리뷰를 진행한 후에도, 자기 반성적인 프롬프팅을 적용하면 정적 분석만으로는 플래그되지 않았던 추가적인 문제들이 여전히 발견되었다는 것입니다. 이에는 정수 오버플로우와 포인터 산술의 미묘한 오용과 같은 엣지 케이스가 포함되었는데, 이는 코드와 컨텍스트에 대한 더 깊은 의미 이해를 필요로 하는 버그들입니다.

이 이중 계층 접근법은, 자동 스캔과 구조화된 LLM 기반의 반영을 결합함으로써 특히 강력했습니다. 이는 통합 도구들이 코드 생성 중 보안에 대한 기준을 높이는 동안, 에이전트 프롬프트 전략이 여전히 전체 취약성 스펙트럼을 잡는 데 필수적이라는 것을 강조합니다. 특히 로직, 상태 가정, 또는 미묘한 메모리 동작을 포함하는 것들입니다.

결론: 바이브만으로는 충분하지 않습니다

Vibe 코딩은 매력적입니다. 그것은 빠르고, 즐겁고, 종종 놀랍게도 효과적입니다. 그러나 보안에 관해서는 직관이나 캐주얼한 프롬프팅에만 의존하는 것은 충분하지 않습니다. AI 주도 코딩이 일반화되는 미래로 나아가면서, 개발자들은 네트워크화된 시스템, 관리되지 않는 코드, 또는 권한이 높은 코드를 구축할 때 특히 의도적으로 프롬프팅하는 방법을 배워야 합니다.

Databricks에서는 생성적 AI의 힘에 대해 낙관적이지만, 위험에 대해서는 현실적입니다. 코드 리뷰, 테스트, 안전한 프롬프트 엔지니어링을 통해, 우리는 우리 팀과 고객을 위해 바이브 코딩을 더 안전하게 만드는 프로세스를 구축하고 있습니다. 우리는 산업계가 속도가 보안을 희생하는 대가가 되지 않도록 비슷한 관행을 채택하도록 권장합니다.

Databricks Red Team의 다른 모범 사례에 대해 알아보려면, 제3자 AI 모델을 안전하게 배포하는 방법 과 GGML GGUF 파일 형식 취약성에 대한 우리의 블로그를 참조하십시오.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)