[AI] 커서(Cursor)와 바이브코딩(Vibe Coding)

**커서(Cursor)**는 AI 기반의 코드 에디터입니다. 챗GPT(ChatGPT) 개발사인 OpenAI의 모델을 기반으로 만들어졌으며, 개발자가 코드를 더 빠르고 효율적으로 작성, 수정, 디버깅할 수 있도록 돕습니다.

주요 기능:

• AI 채팅: 에디터 내에서 AI와 대화하며 코드 생성, 수정, 질문에 대한 답변을 얻을 수 있습니다.
• 코드 자동 생성 및 수정: 간단한 명령(프롬프트)으로 원하는 기능의 코드를 만들거나 기존 코드를 개선할 수 있습니다.
• AI 기반 디버깅: 코드의 버그나 오류를 AI가 분석하고 해결책을 제시합니다.
• 문서 참조: 외부 라이브러리나 프레임워크의 문서를 AI가 참조하여 정확한 코드를 작성해 줍니다.

**바이브코딩(Vibe Coding)**은 정해진 문법이나 규칙에 얽매이기보다, 개발자의 '느낌'이나 '감'에 의존하여 직관적으로 코드를 작성하는 스타일을 의미하는 신조어입니다.

이는 종종 다음과 같은 상황에서 사용됩니다.

• 빠른 프로토타이핑: 완벽한 코드보다는 빠른 결과물 확인이 중요할 때, 세부적인 사항을 생략하고 핵심 로직만 빠르게 구현하는 방식입니다.
• 경험 기반 코딩: 숙련된 개발자가 자신의 풍부한 경험을 바탕으로 "이렇게 하면 될 것 같다"는 직관을 따라 코드를 작성하는 경우입니다.

커서(Cursor)와 같은 AI 코드 에디터의 등장은 이러한 '바이브코딩'을 더욱 현실적이고 효율적으로 만들어줍니다. 개발자가 가진 추상적인 아이디어나 '감'을 AI에게 설명하면, AI가 그것을 실제 작동하는 코드로 구체화해 주기 때문입니다. 즉, 개발자의 직관과 AI의 기술력이 결합하여 생산성을 극대화하는 시너지를 낼 수 있습니다.

AI 코드 에디터 **커서(Cursor)**는 공식 웹사이트에서 다운로드할 수 있습니다.

아래 경로를 통해 접속하여 사용하시는 운영체제(OS)에 맞는 버전을 다운로드하세요.

🔗 커서 공식 다운로드 페이지: https://www.cursor.com/download

페이지에 접속하면 Windows, macOS, Linux 등 사용 환경에 맞는 설치 파일을 바로 다운로드 받을 수 있습니다.

https://cursor.com/downloads

[AI] 에인전틱(AgenticAI)와 생성형 AI(Generative AI)

Agentic AI와 Generative AI는 최근 AI 분야에서 중요한 개념이므로, 두 기술을 비교하여 설명해 드릴 수 있습니다.

1. 생성형 AI (Generative AI)

• 정의: 기존 데이터로부터 학습하여 텍스트, 이미지, 오디오, 비디오 등 새로운 콘텐츠를 생성하는 AI 기술입니다.
• 특징:
  • 학습된 데이터의 패턴과 구조를 모방하여 창의적인 결과물을 생성할 수 있습니다.
  • 다양한 분야에서 활용될 수 있습니다. (예: 글쓰기, 그림 그리기, 음악 작곡, 코드 생성 등)
  • 대표적인 모델로는 GPT (텍스트 생성), DALL-E (이미지 생성), Stable Diffusion (이미지 생성) 등이 있습니다.
• 예시:
  • 사용자의 질문에 맞춰 자연스러운 문장으로 답변하는 챗봇
  • 텍스트 설명을 기반으로 이미지를 생성하는 이미지 생성 모델
  • 사용자가 원하는 스타일의 음악을 작곡하는 음악 생성 모델

2. 에이전틱 AI (Agentic AI)

• 정의: 스스로 계획을 세우고, 필요한 도구를 활용하여 목표를 달성하는 AI 시스템입니다. 여기서 "에이전트"는 환경을 인식하고 자율적으로 행동하는 주체를 의미합니다.
• 특징:
  • 복잡한 작업을 여러 단계로 나누어 순차적으로 처리할 수 있습니다.
  • 외부 환경과 상호작용하며, 필요한 정보를 검색하고, API를 호출하는 등 다양한 도구를 활용합니다.
  • 장기적인 목표를 설정하고, 그 목표를 달성하기 위한 전략을 수립할 수 있습니다.
• 예시:
  • 사용자의 요청에 따라 여행 일정을 계획하고 예약하는 여행 에이전트
  • 주식 시장의 데이터를 분석하여 투자 결정을 내리는 투자 에이전트
  • 소셜 미디어에서 사용자의 관심사를 파악하여 맞춤형 콘텐츠를 추천하는 추천 에이전트

비교 요약:

• 생성형 AI는 새로운 콘텐츠를 생성하는 데 초점을 맞추는 반면, 에이전틱 AI는 자율적으로 목표를 달성하는 데 초점을 맞춥니다.
• 생성형 AI는 주어진 입력에 따라 결과물을 생성하지만, 에이전틱 AI는 스스로 계획을 세우고 실행합니다.
• 생성형 AI는 특정 작업에 특화되어 있는 경우가 많지만, 에이전틱 AI는 다양한 도구를 활용하여 복잡한 작업을 수행할 수 있습니다.

두 기술은 상호 보완적으로 사용될 수 있습니다. 예를 들어, 에이전틱 AI가 생성형 AI를 활용하여 특정 작업을 수행하는 시나리오도 가능합니다.

AI 시대의 기술 위축을 피하는 방법

최고의 미래 개발자는, 오늘날의 AI로 인해, 스스로 생각하는 법을 잊지 않은 사람이 될 것임

https://addyo.substack.com/p/avoiding-skill-atrophy-in-the-age

• AI 도구로 인한 생산성 증가는 개발자들의 핵심 기술 쇠퇴(skill atrophy) 위험을 초래함
• AI를 과도하게 의존하면 비판적 사고와 문제 해결 능력이 점점 약화됨
• 디버깅, 아키텍처 설계, 기억력 등 중요한 기술이 점차 퇴화할 수 있음
• AI를 도구로 삼되, 스스로 사고하고 학습하는 습관을 반드시 유지해야 함
• AI와 협력하는 방식으로 사용하면, 생산성과 기술 숙련도를 모두 향상시킬 수 있음

AI 시대에 기술 쇠퇴를 피하는 방법

• 코딩 분야에서 AI 도우미의 부상은 생산성 향상과 함께 기술 쇠퇴(skill atrophy) 위험을 초래함
  • 기술 쇠퇴는 사용 부족이나 연습 부재로 인해 시간이 지남에 따라 기술이 약화되는 현상을 의미함
• 반복적 작업을 AI에 맡기는 것은 유익할 수 있지만, 과도하면 핵심 능력 상실로 이어질 수 있음
• 인지적 오프로드(cognitive offloading) 현상으로 인해, 문서나 튜토리얼을 스스로 학습하는 대신 AI에 의존하는 경향이 강해짐
• 예를 들어, GPS 사용이 길 찾기 능력을 약화시킨 것처럼, AI 자동완성과 코드 생성 기능이 사고력을 저하시킬 수 있음
• AI가 보일러플레이트 코드를 처리해줌으로써 대규모 프로젝트에 도전할 수 있는 기회가 생겼지만, 자동화와 기술 쇠퇴 사이 경계 설정이 중요함

비판적 사고가 희생양이 되고 있는가?

• Microsoft와 Carnegie Mellon 연구팀의 2025년 연구에 따르면, AI 의존도가 높을수록 비판적 사고 감소 현상이 발생함
• AI에 대한 과신은 사람들이 스스로 사고하는 대신 자동 조종 상태로 전환하게 만듦
• 쉬운 작업일수록 더욱 경계를 풀게 되고, 이로 인해 장기적인 독립 문제 해결 능력 감소가 초래됨
• AI 도움을 받는 작업자는 동일 문제에 대해 덜 다양한 해결책을 제시하는 경향이 있으며, 이는 사고력 균질화로 이어짐
• 연구진은 이를 비판적 사고의 저하로 정의함
• 비판적 사고를 저해하는 장벽들
  • 인지적 장벽: 반복적인 작업일수록 AI에 과도하게 의존하는 경향
  • 동기적 장벽: 시간 압박이나 직무 범위 제약으로 깊은 사고를 회피하게 됨
  • 능력적 장벽: AI의 답변을 스스로 검증하거나 개선하는 데 어려움을 느낌
• 한 엔지니어는 12년 경력에도 불구하고 AI의 즉각적 도움으로 인해 스스로를 더 못하는 개발자로 느끼게 되었음을 고백함
  • 문서 읽기 중단: LLM이 즉각 설명해주기 때문에 공식 문서를 읽을 필요성을 느끼지 않음
  • 디버깅 능력 감소: 스택 트레이스나 에러 메시지를 직접 분석하는 대신 AI에 복붙하여 해결하려 함
  • 깊이 있는 이해 상실: 문제를 진정으로 이해하려는 노력 없이 AI 제안만 반복 적용하게 됨
  • 감정적 반응 변화: 과거에는 버그를 해결하는 데서 얻던 기쁨이, 이제는 AI가 5분 안에 답을 못 주면 좌절로 바뀜
• LLM에게 사고를 위탁하면서, 개발자는 장기적 숙련도를 잃고 단기적 편리성을 얻는 교환을 하게 됨"우리는 AI 덕분에 10배 개발자가 된 것이 아니라, AI에 10배 더 의존하게 된 것"
  "우리가 스스로 해결할 수 있는 문제를 AI가 해결하도록 할 때마다, 우리는 장기적인 이해를 단기적인 생산성으로 바꾸고 있음"

기술 쇠퇴의 미묘한 징후들

• AI 의존이 단순한 가설이 아니라 실제로 개발 기술의 약화로 이어질 수 있음
• 몇 가지 뚜렷한 징후를 통해 자신의 기술 쇠퇴 여부를 점검할 수 있음
• 디버깅 포기 현상
  • 에러가 발생할 때 디버거를 사용하거나 스택 트레이스를 직접 읽지 않고, 바로 AI에 의존하는 경향
  • 과거에는 버그를 직접 분석하고 해결하면서 성장했지만, 이제는 그 과정을 AI에 전가하는 경우가 많아짐
  • AI가 해결하지 못하거나 사용할 수 없는 상황에서는, 기본적인 문제 진단조차 어려운 상태에 빠질 위험이 있음
• 이해 없이 복붙하는 코딩
  • 보일러플레이트 코드를 AI가 작성하는 것은 괜찮지만, 왜 그렇게 동작하는지 이해하지 못한 채 복사하여 사용하는 경우 문제 발생
  • 특히 젊은 개발자들은 AI 덕분에 빠르게 코드를 작성하지만, 그 선택의 이유나 예외 처리 방식을 설명하지 못하는 경우가 많음
  • 다양한 대안을 고민하는 과정이 사라지면서 기초적인 사고 훈련이 결여됨
• 아키텍처 및 시스템적 사고력 약화
  • 복잡한 시스템 설계는 단일 프롬프트로 해결할 수 없음
  • 작은 문제를 AI로 해결하는 데 익숙해지면, 고차원적 설계 작업에 대한 두려움이나 회피가 생길 수 있음
  • AI는 특정 컴포넌트나 패턴을 제안할 수 있지만, 성능, 보안, 유지보수성 등 전체 맥락을 이해하는 것은 개발자 본인의 몫임
  • 시스템 수준 사고력을 사용하지 않으면 점차 약화됨
• 기억력 및 회상력 감소
  • 자주 쓰는 API 호출이나 언어 문법조차 기억이 흐려질 수 있음
  • AI 자동완성 기능에 익숙해지면서, 스스로 코드를 작성하는 능력이 약화됨
  • 이는 수학 계산기를 지나치게 의존하는 학생처럼, 기본 계산 능력 상실에 비유할 수 있음
• 시간이 흐름에 따라 일부 기술이 자연스럽게 사라지는 것은 정상적인 현상임
  • 예를 들어, 어셈블리어로 메모리를 직접 관리하거나, 손으로 긴 나눗셈을 하는 능력은 더 이상 필수적이지 않음
  • 하지만 어떤 기술은 유지해야 하고, 어떤 기술은 버려도 되는지 구분하는 것이 중요함
  • 긴급 상황에서 디버깅할 수 있는 능력은 여전히 필수 기술로 간주해야 함
  속도와 지식의 트레이드오프:
  AI는 빠른 답을 제공하지만 (높은 속도, 낮은 학습),
  전통적인 방법(Stack Overflow, 공식 문서)은 느리지만 깊은 이해를 구축해줌
• 즉각적 답변을 좇다가, 진정한 전문가로 성장하는 데 필요한 맥락 이해와 깊이를 놓칠 위험이 있음

AI 과의존의 장기적 위험

• AI 도구에 대한 과도한 의존이 통제되지 않을 경우, 경력상 비판적 사고 위기에 직면할 가능성이 있음
• AI가 대부분의 사고 과정을 대신하게 되면, 도구가 실패하거나 해결하지 못하는 문제에 대해 스스로 대응할 능력을 잃게 됨"AI를 많이 쓸수록 뇌를 덜 쓰게 됩니다. 그러면 AI가 해결할 수 없는 문제에 부딪혔을 때, 당신은 스스로 해결할 수 있는 기술이 있을까요?"
• 실제로 AI 코딩 도우미 장애로 개발자들의 워크플로우가 완전히 멈춘 사례도 발생함
• 자기 실현적 예언(Self-Fulfilling Prophecy)
  • Microsoft 연구팀은 AI에 의한 직업 상실을 걱정하면서도 "무비판적(uncritically)으로 AI를 사용"할 경우, 스스로 경쟁력을 잃게 될 수 있음을 경고함
  • 특히 신입 개발자들은 "어려운 길"을 건너뛰고 빠른 생산성에만 집중하여, 심화 학습 없이 조기에 성장 정체에 빠질 위험이 있음
  • 결과적으로, 스스로 문제를 해결하는 기쁨이나 깊은 이해를 경험해보지 못한 버튼 누르는 인력(button-pushers) 집단이 생겨날 수 있음
  • 이들은 AI에게 질문하는 방법은 능숙할지 몰라도, 정답을 진정으로 이해하지 못하는 상황에 빠질 수 있음
  • AI가 사소하게 틀렸을 때 그 오류를 발견하지 못하고, 버그나 보안 취약점이 코드에 섞여 들어가는 문제도 발생할 수 있음
• 팀 문화와 조직 역동성
  • 모든 개발자가 AI 도우미만 사용하게 되면, 멘토십과 비공식적 학습(osmosis learning) 이 약화될 수 있음
  • 주니어 개발자들이 동료 대신 AI에 의존하면, 시니어 개발자들이 지식을 전수하기 어려워짐
  • 기초가 약한 주니어들이 많아질 경우, 시니어들은 AI가 만들어낸 오류를 고치는 데 시간을 소모하게 됨
  • 결국 팀은 개별 구성원이 AI에 의존하는 집합체로 전락할 수 있으며, 비판적 리뷰나 공동 품질 유지 문화가 사라질 수 있음
  • 버스 팩터(bus factor) 에 사실상 "AI 서비스 장애"도 포함이 가능함
    • "프로젝트가 무너지려면 몇 명이 버스에 치여야 할까?"
• 아날로그 방식으로 돌아가자는 것이 아니라, AI를 신중하게 사용해야 한다는 경고임
  • AI를 활용하면서도, 작업 그 자체뿐 아니라 사고력 자체까지 아웃소싱하지 않도록 주의해야 함
  • 목표는 AI의 혜택을 최대한 누리되, 동시에 자기 자신의 기술과 사고력을 견고히 유지하는 것임

AI를 목발이 아닌 협력자로 사용하기

• AI 코딩 도우미의 생산성 향상을 누리면서도, 사고력과 기술을 유지하기 위해서는 의식적인 사용 습관이 필요함
• AI를 전능한 답변자가 아니라, 주니어 페어 프로그래머나 러버덕 디버깅 파트너처럼 대해야 함
• 다음은 고려해봐야할 구체적 실천 전략들
• "AI hygiene(위생)" 실천 – 항상 검증하고 이해하기
  • AI의 결과물이 그럴듯해 보여도 무조건 신뢰하지 않고 검증하는 습관을 들여야 함
  • AI가 생성한 함수나 코드에 대해 의도적 테스트를 수행하고, 엣지 케이스를 찾아야 함
  • "왜 이 솔루션이 작동하는가?", "한계는 무엇인가?"를 스스로 질문함
  • AI에게 코드를 줄 단위로 설명하거나 대안 접근법을 요청해 학습에 활용함
  • AI의 답변을 심문하면 수동적인 답변을 능동적인 교훈으로 바꿀 수 있음
• 기본기 훈련 – 때로는 고생도 필요함
  • 매주 일정 시간을 "AI 없는 코딩시간" 으로 설정하여 순수한 수작업으로 문제를 해결하는 시간 확보
  • 경험 많은 개발자들은 "No-AI Day" 를 지정하여 직접 코드 작성, 에러 분석, 문서 검색을 실천함
  • 초기에는 느리고 답답하지만, 시간이 지나면서 자신감과 깊이 있는 이해를 회복할 수 있음
  • AI 없이 꾸준히 코딩하면 기본 실력이 엔트로피로 떨어지는 것을 방지할 수 있음
  • 이는 개발자 두뇌를 위한 크로스 트레이닝과 같음
• AI한테 묻기전에 문제에 스스로 먼저 도전하기
  • 문제를 접했을 때 곧바로 AI에 묻지 않고, 먼저 접근 방법을 고민함
  • 최소한 의사 코드(pseudocode) 나 간단한 아이디어라도 스스로 세워본 후 AI를 활용함
  • 버그가 발생하면 최소 15~30분 정도는 스스로 디버깅해보는 시간을 갖기
  • 이러면 문제 해결 능력을 키울 수 있으며, AI 답변과 자신의 접근법을 비교하며 능동적으로 학습이 가능
• AI를 사용하여 코드 검토를 대체하는 것이 아니라 증강하기
  • AI가 생성한 코드도 인간 동료가 작성한 것처럼 철저히 리뷰함
  • 가능하다면 AI 코드에 대해 인간 코드 리뷰를 병행하여 팀 차원의 품질을 유지함
  • 이를 통해 팀 지식을 루프에 유지하고, AI를 신뢰할 때 단독 개발자가 놓칠 수 있는 문제를 포착함
  • 이는 "AI가 초안을 만들 수는 있지만, 우리가 코드를 소유한다"는 태도를 장려
  • 누가 작성했는지에 관계없이 팀이 저장소에 있는 모든 코드를 이해하고 유지관리 할 책임이 있음
• 능동적 학습 – 후속 질문과 반복 학습
  • AI가 제시한 솔루션이 잘 작동해도, 그 자리에서 학습을 강화하는 시간을 가짐
  • 복잡한 정규 표현식이나 알고리듬을 AI로 작성한 경우, 그 구조를 스스로 설명하거나, AI에 왜 이 방법을 썼는지 질문함
  • AI를 단순 답변 제공자가 아니라, 무한 인내심을 가진 튜터처럼 대화형으로 활용함
    • ChatGPT가 생성한 코드에 대해 "왜 이 방법은 안 돼?" 라고 묻기
  • 이렇게 하면 AI는 단순한 코드 배포자가 아닌 멘토가 됨
• 학습 일지 및 "AI 어시스트" 목록을 기록하기
  • AI에 반복적으로 묻는 주제를 기록하여 지식 공백을 파악함
  • 예를 들어, CSS에서 div 정렬이나 SQL 쿼리 최적화를 반복해서 묻는다면, 해당 주제를 집중 학습함
  • 플래시카드나 짧은 연습 문제를 만들어 반복 학습하여 장기 기억으로 전환함
  • 다음에 비슷한 문제에 직면하게 되면 AI 없이 문제를 풀어보고 그 방법을 기억하는지 확인해 볼 것
  • AI를 첫 번째 해결책이 아닌, 마지막 안전망으로 사용하는 태도를 유지함
• AI와 페어 프로그래밍하기
  • AI를 질문 처리 API처럼 대하는 대신, 페어 프로그래밍 파트너처럼 대화함
  • 예를 들어, 내가 함수 초안을 작성하고 AI에게 개선점을 제안받거나, 반대로 AI가 초안을 작성하면 내가 수정함
  • 대화 예시: "이 함수는 작동하는데, 더 명확하게 리팩토링할 방법이 있을까?"
  • 이렇게 하면 당신이 운전석에 앉아있게 함. 단순히 답변을 소비하는게 아니라, AI가 기여할 수 있도록 큐레이션하고 지시
  • AI를 감독이 필요한 주니어 개발자로 취급하고, 최종 책임자는 인간 개발자임을 명확히 함
• 이런 습관을 통해 AI 사용은 순수한 이득이 되며, 스스로의 능력도 잃지 않게 됨
• 실제로 AI를 활용하여 생소한 코드를 설명하거나, 복잡한 케이스로 AI를 시험하는 과정은 개인 기술 향상에도 매우 유익함
• 예를 들어, AI를 사용하여 익숙하지 않은 코드를 설명하면 지식을 심화할 수 있고, 까다로운 사례로 AI를 당황하게 만들면 테스트 사고방식을 향상시킬 수 있음
• 핵심은 수동적 소비자가 아니라 능동적 사용자로 남는 것임

결론: 날카로움을 유지하기

• 소프트웨어 산업은 AI 기반 코드 생성의 시대를 향해 가속 중이며, 이제 되돌릴 수 없는 흐름이 됨
• 이러한 도구를 받아들이는 것은 불가피할 뿐만 아니라, 대체로 이득이 되는 일임
• 그러나 AI를 워크플로우에 통합하면서, 각자 기계에게 양보할 것과 스스로 유지해야 할 것 사이에서 신중한 선택이 필요함

• 코딩을 사랑한다면, 단순히 빠르게 기능을 출시하는 것뿐 아니라, 문제를 해결하는 장인정신과 즐거움도 유지해야 함

• AI를 능력 증폭기(amplifier) 로 활용하되, 대체자(replacement) 로 만들지 말아야 함
• AI가 반복 작업을 대신할 수 있도록 하고, 그 freed-up 시간을 창의적이고 복잡한 작업에 투자함
• 그러나 기초 기술이 퇴화하지 않도록 주의해야 하며, 항상 "어떻게"와 "왜"를 탐구하는 호기심을 유지해야 함
• 디버깅 본능과 시스템 사고력을 계속 갈고닦아야 하며, AI가 제시하는 지름길만 탐색해서는 안 됨
• "간단히 말해서, AI를 당신의 목발이 아닌 협력자로 삼을 것"

• 성공하는 개발자는 인간적 직관과 경험을 AI의 초능력과 조화롭게 결합할 줄 아는 사람일 것임
  • autopilot이 있거나/없거나 상관없이 코드베이스를 탐색할 줄 아는
• 자기주도적 연습과 도전을 통해, fancy한 도구가 실패하거나 새로운 문제에 직면해도 스스로 문제를 해결할 수 있어야 함
• "AI가 당신을 대체할까봐 걱정하지 말고, 당신을 대체 불가능하게 만드는 기술을 키우지 않는 것에 대해 걱정할 것"
• "AI가 제공하는 답변을, 엔지니어의 마음으로 이해해야 한다"는 원칙을 항상 지키면, AI 열풍에 타면서도 쓸려가지 않을 것

• 보너스
  • 다음에 AI가 기능 전체를 코딩해줄 때 유혹을 느낀다면, 스스로 직접 일부를 작성해보라는 신호로 받아들여야 함
  • 놀랍게도 많은 것을 기억하고 있고, 다시 직접 손으로 코딩하는 기쁨을 느낄 수 있음
  • AI를 생산성 향상의 도구로 삼되, 능동적으로 기술을 연마하는 습관을 절대 멈추지 말아야 함

최고의 미래 개발자는, 오늘날의 AI로 인해, 스스로 생각하는 법을 잊지 않은 사람이 될 것임

생성형 AI 프롬프트에 악의적인 요청을 자연어 대신 수학 방정식으로 입력하면, 생성형 AI의 보안 장치를 피할 수 있다는 연구 결과가 공개됐다.  MathPrompt
 
미국 텍사스 대학교 샌안토니오, 멕시코 몬테레이 공과대학교, 미국 플로리다 국제 대학교 연구진이 지난주 발표한 연구에 따르면, 생성형 AI 시스템의 악용 방지를 위한 보안장치가 자연어가 아닌 수학 방정식을 입력하는 방식을 통해 무력화될 수 있는 것으로 나타났다. 연구진은 이를 '매쓰프롬프트'라고 명명했으며, 챗GPT와 같은 대규모 언어 모델의 보안 보호 장치를 피할 수 있다는 점에서 '탈옥' 공격의 한 형태라고 설명했다. 또한 "매쓰프롬프트는 현재 AI 안전 조치를 무력화하는 핵심 취약점"이라고 표현했다.

많은 보안 전문가가 CISO들은 여전히 신중을 기해야 하며, 직원들이 사용하는 LLM 시스템에서 민감한 데이터가 노출되지 않도록 주의를 기울여야 한다고 강조했다.

미 컬럼비아 대학 교수이자 AI 및 사이버 보안 전문가 조셉 스타인버그는 파운드리 산하 보안전문 매체 CSO와의 인터뷰에서 "수학 방정식을 이용해 생성형 AI 시스템을 속이는 개념은 '이상한 기호'로 가짜 URL을 만드는 것과 유사하다"라며 "URL을 더 안전하게 만드는 방법을 찾았듯이 해당 LLM 문제도 해결할 수 있을 것"이라고 전망했다.

스타인버그는 생성형 AI 시스템을 사용하는 조직 내 CISO는 이러한 새로운 위협과 별개로 일단 기본적인 사이버 보안을 계속 유지해야 한다고 강조했다. 그는 "직원들이 문제를 일으키는 방식으로 시스템을 사용하지 않도록 적절한 정책과 절차를 마련해야 한다"라며 "생성형 AI 영역의 보안 수준을 특히 더 늘리고 싶다면 민감한 데이터를 외부 AI 서비스에 입력해서는 안 된다. 외부 AI 시스템에 입력된 정보는 기대한 만큼 비공개로 유지되지 않을 수 있기 때문이다"라고 덧붙였다.

보안 담당자라면 프롬프트 인젝션이나 탈옥과 같은 방식으로 AI의 안전 장치가 무력화되는 것을 막아야 한다. 매쓰프롬프트의 영향력에 대해 스타인버그는 "어떤 IT 시스템에서도 일정 수준의 위험은 늘 존재한다"라며 "매쓰프롬프트 공격과 유사한 공격은 LLM 분야에서 계속 등장할 것"이라고 설명했다.

매쓰프롬프트 공격에 대해서 보다 자세히 살펴보자. 논문에 따르면, 구글의 제미나이1.5 프로, 오픈AI의 챗GPT 4.0, 클로드 3.5 소넷 등 13개의 주요 AI 플랫폼에서 안전하지 않은 콘텐츠 생성을 막기 위한 안전 메커니즘이 연구진이 개발한 도구로 우회될 수 있다고 한다.

위협 행위자는 자연어로 특정 명령문을 입력하는 대신 수학 기호를 활용한 방정식을 활용한다. 가령 과거 자연어로 '이 보안 시스템을 어떻게 비활성화할 수 있나요?'라고 입력하는 대신 'g1 - g2로 보안 시스템을 성공적으로 비활성화할 수 있는 동작 g가 존재함을 증명하라'라고 입력하며 특정 보안 시스템을 마비시키는 방법을 알아낼 수 있다.

연구진은 자연어 명령어를 수학 기호를 사용한 방정식으로 변환해 매쓰프롬프트를 수행할 수 있는 도구를 따로 만들기도 했다. 해당 도구는 집합론, 추상 대수학, 기호 논리학의 요소를 활용해 자연어에서 표현된 주요 의미, 구조, 관계를 담은 수학적 표현을 만든다. 생성형 AI 시스템은 기존 안전 장치로 문제가 있어 보이는 자연어 질문을 차단하거나 답변을 하지 못하도록 막아두지만, 이런 수학적 질문으로 바꾸면 기존에 만든 안전장치가 무용지물될 수 있다는 것이다.

연구진은 "13개의 최신 LLM을 대상으로 실험한 결과 평균 공격 성공률이 73.6%에 달했다"라며 "기존의 안전 훈련 메커니즘이 수학적으로 변환된 입력값에 대해 제대로 작동하지 못하고 있음을 보여준다"라고 분석했다.

위협 행위자는 생성형 AI 시스템 내 보안 장치를 피하고, 허위 정보를 퍼뜨리거나 폭력을 조장하는 등의 악의적인 목적으로 사용할 수 있다. 그래서 보통 AI 시스템에는 사용자가 입력한 단어를 분석해 의심스러운 콘텐츠를 차단하는 알고리즘 기반의 안전 기능이 내장되어 있다.

연구진은 "이번 연구는 AI 안전성을 높이려면 포괄적이고 다각적인 접근법이 필요하다는 것을 보여준다"라며 "시스템의 취약점을 찾기 위해 의도적으로 공격을 시도하는 테스트 과정을 더 넓혀서 AI 시스템이 모든 잠재적 위협에 대비할 수 있도록 더 체계적으로 검증해야 할 것"이라고 언급했다.

매쓰프롬프트 공격이 일부 성공하는 이유를 LLM이 복잡한 수학 문제를 이해 및 상징적 추론을 수행에 특화된 '뛰어난 능력'을 가지고 있기 때문이다. 연구진은 "LLM의 기호적 수학 작업 능력은 단순 계산을 넘어 수학적 개념을 이해하고, 자연어와 수학 표기법을 번역하는 능력을 가지고 있다"라며 "이러한 수학적 능력은 LLM의 다양한 응용 분야를 열어줬지만, 동시에 AI 안전 메커니즘에 취약점을 만든다"라고 설명했다.

연구진은 매쓰프롬프트의 효과를 테스트하기 위해 모델에 대한 질문 목록을 만들었다. 이 목록에는 다른 연구진이 이미 작성한 유해한 행동에 대한 120개의 자연어 질문 데이터셋이 일부 포함되었다.

테스트 결과, LLM 시스템이 악의적인 요청을 처리할 때, 약 73.6%의 비율로 안전 메커니즘을 우회하고 요청에 응답했다. 다시 말해 악의적인 요청(예: 해킹 방법이나 유해한 정보 요청)을 일반적인 방식으로 입력하면 LLM이 이를 차단하거나 응답하지 않도록 설계되어 있지만, 수학적 표현이나 기호를 사용해 입력하면 LLM이 이를 악의적인 요청으로 인식하지 못하고 응답한 경우가 73.6%였다는 뜻이다. 가장 높은 성공률을 보인 것은 클로드 3의 하이쿠 버전으로 87.5%의 성공률을 기록했고, GPT4가 85%로 그 뒤를 이었다.

구글의 제미나이 1.5 프로에서 매쓰프롬프트 테스트는 안전 시스템을 킨 상태에서 74.2%, 안전 시스템을 끈 상태에서 75%의 성공률을 기록했다. CSO는 구글 측에 매쓰프롬프트와 관련해 추가 의견을 요청했으나, 구글의 대변인은 기사 작성 시점에 회사의 전문가가 부재 중이라고 밝혔다.

https://www.ciokorea.com/news/351159

올해 2분기 국내 스마트폰 시장의 출하량이 약 299만대로 전년 대비 6.8% 성장했다고 IDC가 25일 밝혔다. 경제 불확실성으로 전체 스마트폰 시장의 수요가 위축되고 있는 상황이지만 AI 기능을 탑재한 플래그십 스마트폰의 높은 수요가 지속되고 있다는 분석이다.

이 시장조사기관에 따르면 800달러(USD)이상의 플래그십 제품군의 점유율이 전년 동기 대비 5.3%p 증가한 62.3%를 기록했다. 실시간 번역, 텍스트 요약, 간단해진 검색 등의 AI기술이 별도의 앱 설치 없이 기본 기능에 적용되며 복잡한 과정 없이 이용할 수 있다는 점이 소비자들의 관심을 유발했다는 설명이다. 

이 밖에 주요 브랜드의 5G 플래그십 및 중저가 스마트폰이 출시로 인해 5G 점유율은 89.1%로 상승한 것으로 나타났다.

반면, 국내 폴더블 시장은 전년 대비 크게 감소한 약 6만대를 출하했다. 삼성전자가 3분기 폴더블 신제품 출시를 앞둔 가운데 AI 기능이 적용될 신제품의 기대감이 고조되며 일부 대기 수요가 발생했고 이로 인해 지난 분기에 이어 시장 수요가 급감한 것으로 IDC는 분석했다.

한국IDC에서 모바일폰 시장 리서치를 담당하고 있는 강지해 연구원은 “온디바이스AI 열풍이 가속화되며 시장 경쟁이 치열해지고 있고 전반적인 스마트폰 시장 내 흐름이 AI 스마트폰으로 완전히 옮겨가고 있다. 국내 생성형 AI 스마트폰 2024년 연간 출하량은 950만대를 밑돌 것으로 전망된다”라고 말했다.

IDC가 정의하는 생성형 AI 스마트폰은 정수형식의 8비트 데이터(int-8)를 사용하여 초당 30 TOPS(Tera Operations per Second) 이상의 성능을 갖춘 신경 처리 장치(NPU)를 활용해 온디바이스 GenAI를 보다 빠르고 효율적으로 실행할 수 있는 칩셋(SoC)을 탑재한 모델이다. https://www.ciokorea.com/news/351117

생성형 AI가 지루한 작업을 처리하고 오류를 찾는 데 능숙하더라도 프로그래머의 전문성과 직관은 항상 필요할 것이다.

데이터셋(Datasette)의 설립자 사이먼 윌리슨은 “지금이 프로그래밍을 배우기에 더할 나위 없이 좋은 시기”라고 말했다. AI가 코딩을 대신 해줘서가 아니다. 사실 정반대다. 그는 “대규모 언어 모델은 학습 곡선을 평평하게 만들어 젊은 개발자가 더 쉽게 따라잡을 수 있게 해준다”라고 말했다. 코딩하는 방법을 잊어서는 안 되지만, 생성형 AI를 사용해 경력 수준에 관계없이 개발자 경험을 강화할 수 있다.

‘배움에 대한 의지’를 예찬
필자는 생성형 AI에 대한 윌리슨의 견해를 살피는 것을 즐긴다. 그는 이 주제를 사려 깊게 생각하는 개발자다. 오라일리(O'Reilly Media)의 마이크 루키데스 글도 큰 주제에서 핵심을 압축해 설명했기 때문에 읽어볼 만하다. 루키데스는 생성형 AI와 코딩에 대해 “정말 좋은 프롬프트를 작성하기란 생각보다 어렵다”라는 점을 상기시켜 준다. 그는 “프롬프트를 잘 작성하려면 프롬프트의 목적에 대한 전문 지식을 쌓아야 한다”라고 말했다. 다시 말해, 먼저 ‘좋은’ 프로그래머가 돼야 한다.

루키데스는 “AI를 '인간이 얻을 수 없는 전문 지식과 지혜의 보고’로 생각해버리면 이를 생산적으로 사용할 수 없게 된다”라고 조언했다. AWS 코드위스퍼러(CodeWhisperer)나 구글 코디(Codey)와 같은 도구를 효과적으로 사용하기 위해서는 기대하는 결과물을 코칭해야 한다. 그리고 AI에게 개발 문제를 해결하는 방법을 단계별로 알려주려면, 먼저 문제를 깊이 이해하고 AI가 응답하도록 이끌어내야 한다. 

또한 개발자는 AI가 틀렸을 때 이를 평가할 수 있어야 한다. 여기엔 일정 수준의 전문성이 필요하다. 윌리슨이 언급한 것처럼 코딩 어시스턴트가 프로젝트에서 더 활발히 일하고 도와줄 것으로 기대되는 상황이지만, 그렇다고 해서 개발자가 코드를 파악해야 할 필요성까지 없애주진 않을 것이다. 그렇게 되기를 바라는 이도 없을 것이다. 다시 윌리슨의 첫 번째 요점으로 돌아가 본다.

AI를 활용한 코딩 학습
특정 언어, 프레임워크, 데이터베이스 등을 처음 접하는 개발자라면 학습 곡선이 가파를 수 있다. 예를 들어 “세미콜론을 놓쳐서 기이한 오류 메시지가 표시되고, 그 오류를 다시 찾는 데 2시간이 걸리는 경우도 있다”라고 윌리슨은 말했다. 당연히 이러한 점 때문에 학생들은 자신이 프로그래밍을 배울 만큼 똑똑하지 않다고 생각해 배움을 포기할 수 있다.

바로 이 부분에서 AI 어시스턴트가 개입할 수 있다. 윌리슨은 “컴퓨터공학 학위가 없어도 컴퓨터가 지루한 일을 대신 해줄 수 있어야 한다”라고 전했다. 챗GPT 같은 LLM 기반 어시스턴트는 지루한 작업을 자동화할 수 있다. 깃허브(GitHub) 엔지니어 자나 도건은 “사람들은 코드 생성에만 너무 집중한 나머지 LLM이 코드 분석에 유용하다는 사실을 완전히 잊고 있다”라고 강조했다. 모든 작업을 AI가 할 필요는 없다. 윌리슨의 주장에 따르면, 애플리케이션을 만들거나 망치지는 않으나 개발자의 자신감을 떨어뜨릴 수 있는, 개별적이고 지루한 작업을 자동화하는 데 AI를 활용할 수 있다. 코딩 어시스턴트가 지루한 작업을 처리할 수 있음에도 개발자가 프로그래밍의 모든 측면을 배우고 수행할 것을 요구받는 경우에 더 그렇다.

언제나 그렇듯 생성형 AI와 함께 소프트웨어 개발을 시작하는 가장 좋은 방법은, 바로 시작하는 것이다. 이해는 했지만 반복해서 작성할 필요는 없는 간단한 작업부터 자동화해 작게 시작하라. 이렇게 절약한 시간으로 더 까다로운 코딩 문제를 해결하는 방법을 배우는 데 집중할 수 있다. 전문성이 높아지면 이러한 작업도 자동화할 수 있게 될 것이다.

https://www.ciokorea.com/news/311336